《毕业设计（论文）基于MP、RUP的软件过程研究.doc》由会员分享，可在线阅读，更多相关《毕业设计（论文）基于MP、RUP的软件过程研究.doc（20页珍藏版）》请在三一办公上搜索。
1、摘 要随着计算机的应用和普及，计算机的性能逐年增强，用户对运行于计算机和因特网上的软件的功能和性能的渴望也随之增加，用户希望更好更复杂更快的软件来满足他们的需要；与此同时，市场的激烈竞争迫使现代软件企业必须更快地生产出用户需要的复杂软件。这样导致了软件危机的出现。面对软件危机Rational公司推出的RUP软件开发过程和微软公司推出的MP软件开发过程在软件开发方面都取得了很大的成功。然而MP、RUP方法的提出并未真正的解决软件危机，同时人们希望通过追求寻找解决软件危机的最佳方法。针对现代软件产业所处的困境，鉴于现有的软件工程领域的软件生命周期模型在解决软件开发问题方面存在的局限性，本文提出了M
2、RUP软件开发过程，MRUP过程是基于对MP、RUP的研究，并针对其中的一些局限提出的一种新的软件过程。关键字：微软过程；RATIONAL统一过程；MRUP过程；研究目 录第一章 绪论31.1研究背景31.2 研究意义和目的41.3研究内容6第二章、MP方法的介绍62.1微软过程概述62.2生命周期72.3人员72.4方法72.5产品92.6四要素之间的关系92.7本章小结9第三章、RUP的介绍103.1RATIONAL统一过程概述103.2 RUP的过程结构113.3 RUP的动态结构113.4 RUP的静态结构153.5本章小结15第四章 MRUP软件过程模式164.1MRUP的概述164
3、.2MRUP过程模式的生命周期及相关错误的规避164.3MRUP过程模式的人员164.4MRUP过程模式方法174.5MRUP过程模式的产品184.6 MRUP过程模式的生命周期、人员、方法与产品四要素间的关系184.7本章小结18第五章 总结与展望18总结18展望19致 谢19参考文献19第一章 绪论1.1研究背景1946年，世界上第一台电子计算机诞生在美国宾夕法尼亚大学的摩尔学院，由此拉开了计算机软件的发展史。从宏观角度而言，计算机软件发展主要经历了以下三个阶段。（1）第一阶段程序设计阶段20世纪60年代以前还没有软件开发的说法，那时只有程序设计的概念，最多在写出程序后配有程序结构说明各使
4、用说明。经典的程序设计方法为“程序设计=数据结构+算法”。（2）第二阶段软件工程阶段20世纪70年代以来，人们认识到软件的工作不能仅限于编写程序，软件开发工作在程序编写之前和之后还有很多重要的工作不能忽略，例如需求分析、测试、维护等等。在总结“软件危机”教训后，人们认识到并建立软件工程的思想。软件工程摒弃了认为只有充满编程技巧的程序才能高水平地发挥个人才能的观念，强调程序的可读性、可理解性、可测试性和易修改性等工程化的原则。（3）第三阶段软件过程阶段从20世纪90年代开始，人们更加强软件开发的效率、软件的质量以及软件开发相关的管理工作，建立了“软件过程”的概念。软件过程不仅包括软件开发过程，还
5、包括了支持性、管理性过程。到目前为止，人们对软件工程的研究主要是对软件生命周期模型的研究。典型的生命周期模型包括瀑布模型、演化模型、螺旋模型、喷泉模型等。（1）瀑布模型瀑布模型规定了软件生命周期各阶段的不同活动，包括定义阶段的项目计划和需求分析，开发阶段的设计、编码和测试，维护阶段的运行维护。这些活动自上而下，相互衔接，呈线性图状，如同瀑布流水，逐级下落。但此模型适用于用户需求明确、稳定的软件项目。（2）演化模型演化模型包括两大步骤：第一步进行试验开发，得出产品“原型”，其目标在于弄清软件需求并探索其可行性；第二步在原型基础上开发出较为满意的软件产品。因此演化模型又称为原型模型。演化模型减少了
6、软件因需求不明确给开发工作带来的风险。（3）螺旋模型螺旋模型沿螺线旋转，每旋转一圈都历经笛卡儿坐标系中四个象限的四个方面活动制订计划、风险分析、实施工程及客户评估。螺线自内向外每旋转一圈便开发一个更为完善的新的软件版本。采用的是一种自上而下的工作方式。螺旋模型将瀑布模型和演化模型进行结合，同时加入了这两种模型中都忽略的风险分析，可应用于指导客户需求不太稳定的软件开发以及大型软件开发中。（4）喷泉模型相对于螺旋模型，喷泉模型引入了“面向对象的分析设计方法”。此模型由于各阶段均采用了“对象”这一统一范式，整个过程看起来像喷泉从喷出到落下再喷出的周而复始过程产生的光滑水柱，属自底向上的工作方式。相对
7、螺旋模型而言，喷泉模型除具有模型的“迭代演化”特点外，还具有软件过程各阶段的无缝衔接性，并且对软件复用和软件生命周期内多项开发活动的并行与集成提供了支持。这四种模型均对软件过程中各过程阶段的活动密切关注，而对过程活动的执行者及分工、过程中使用的方法和工具、过程中各阶段的目标等方面的论及则很少甚至没有。因而，用于指导软件开发实践时，表现出较差的可操作性。1.2 研究意义和目的软件生命周期模型未能改变现代软件产业整体处于困境的现状，且不同的软件开发项目在不同的方面有着不足和缺陷，并且不幸的是，有太多的项目最终失败了，但是我们可以从这项目中找出一些共同的症状：对于最终用户的需求理解不够准确。对需求的
8、变更束手无策。脆弱的架构。软件质量低劣。测试的不充分导致对项目的缺陷发现比较晚。软件性能令人无法接受。拙劣的进度计划和评估。缺乏资源。不具备项目管理方法。缺少管理层的支持。一个不可靠的构造和发布过程。尽管不同的项目以不同的方式失败，但是似乎大多数的失败是由于以下几点根本原因综合造成的：特别的需求管理。模糊和不精确的交流。程序模块互不兼容，及不易扩展。过度复杂。未检测出需求、设计和实现之间的不一致性。测试不足。对项目状况的评估过于乐观。未解决存在的风险。对变化无法掌控。为了解决上面的软件问题。它需要一个过程来集成软件的许多方面，它需要一个通用的方法，该方法能：（1）提供应如何对整个开发团队的开发
9、活动进行组织指导。（2）综合指导单个开发人员和开发团队。（3）规定开发成果是什么。（4）提供监控和衡量一个项目中的产品和活动的标准。一个定义良好且管理良好的过程是区别成效卓著的项目和不成功项目之间的重要指标。“MRUP开发过程”正是我们在软件开发上面临的难题的解决之道。“MRUP开发过程”是在MP与RUP的基础上对软件开发过程的一种研究，利用此方法对提高一个软件企业的过程能力，及时且高质的完成软件开发，进而提高企业的综合能力都有深远的意义。1.3研究内容本文的研究内容主要包括以下几个部分：介绍MP方法理论，并对其中的一些优缺点进行阐述。学习和研究RUP过程，提出了RUP方法的优缺点。基于MP、
10、RUP提出了MRUP方法，并且依次从生命周期、人员、方法、产品等方面对其进行了描述。第二章、MP方法的介绍2.1微软过程概述微软公司是世界上最大的、也是最成功的软件公司之一，其产品涵盖多个领域。但微软公司并未通过CMM认证，也并未宣称自己使用过RUP和其它过程。微软公司有自己的软件开发过程，且其过程被几十年实践证实是非常行之有效的。到底微软过程是一个怎么样的过程呢？微软解决方案框架（Microsoft solution Framework , MSF ）回答了以上问题。MSF是微软顾问咨询部于1994年根据微软公司成功的产品开发经验总结、设计而成的框架体系，该设计该框架体系的目的是帮助企业提升
11、利用IT技术解决商务问题的能力。经过不断的改进和发展，微软将公司内部的产品开发人员、顾问咨询人员以及微软公司全球的客户和合作伙伴在项目设计。开发各管理方面经过实践检验的、可重复、可借鉴的成功经验都集成到MSF之中，从而为不同规模的组织结构和不同类型的IT项目提供从项目组织规划和产品发布管理的全方位指导和帮助，是一套高效、灵活、可扩展的软件开发管理体系。MSF是一个框架结构的经验知识库，它包括以下方面的内容。企业结构设计方案。项目开发准则。应用程序模型。企业信息基础设施的实施方法。其中项目开发准则中的过程模型和组织模型分别是从软件过程中的过程、人员及组织、方法、产品等不同方面阐述了MSF的一些经
12、验，而这些方面实质构成了一套软件过程模式，即微软过程（Microsoft process, MP）模式。2.2生命周期微软过程的每一个生命周期发布一个递进的软件版本，各生命周期持续、快速地循环。每个生命周期分为五个阶段，分别是：构想阶段、计划阶段、开发阶段、稳定阶段和发布阶段。且分别结束于前景和范围得到认可、项目计划得到认可、项目范围内的所有产品特性开发完成、可发布版本准备就绪和产品发布完成这五个主要的里程碑。这五个阶段均涉及产品管理、程序管理、开发、测试、发布各角色及其活动，并且在每个阶段之间都设立了缓冲时间。2.3人员微软过程根据项目组中的所有职能将人员划分六种角色，分别是产品管理角色、程
13、序管理角色、开发角色、测试角色发布管理角色。由产品经理、程序经理、开发工程师、测试工程师、用户体验人员和发布管理人员担任。项目组中虽然多个角色可合并由一个个体担任，但项目组内的开发人员不兼任其他角色，也不会让两个有明显利益冲突或制约关系的职能角色合并。且这六种角色中他们的关系是对等的。在人员管理上，要求所有的成员都参与设计，共同决策，共同管理。让大家都有明确的目标，阐述产品的前景，让所有成员都有了解产品前景，并对其有清晰的认识和明确的认同，使每一位成员能以自己为产品的美好前景贡献力量而感到自豪。把每个角色的人员划分成多个小型的、多元化的项目组，每个小型的项目组人数控制在10个以下，且每个项目组
14、成员在同一地点办公，以方便交流与沟通。2.4方法微软通常采用“同步稳定产品开发法”。典型项目的生命周期包括三个阶段：计划阶段：完成功能的说明和进度表的最后制定开发阶段：写出完整的源代码稳定化阶段：完成产品，使之能够批量生产（Roll Out）在开发和稳定化阶段的所有时间中，一个项目通常会将2/3的时间用于开发，1/3的时间用于稳定化。这种里程碑式的工作过程使微软经理们可以清楚地了解产品开发过程进行到了哪一步，也使他们在开发阶段的后期有能力灵活地删去一些产品特性以满足进度要求。并且针对每个阶段的活动均提出了一些行之有效的方法和技术。2.4.1计划阶段主要是做以下事情：（1）.把你准备做什么样一个
15、产品搞清楚，这个产品有什么特性。（2）.这个产品有没有市场，用户为何需要这个产品以及该产品的走势。（3）.这个产品大概是个什么样子，是否有个大概的原型展示方便高层决策。（4）.设计的功能，目标，优先级，大概的进度。微软在这个计划阶段保存了很多可行性研究分析和产品规划的内容在里面，更多的是一个产品规划的内容。2.4.2开发阶段开发阶段的计划对三四个主要的里程碑版本都逐个分配一组特性，规定出特性的细节和技术上的相关性，记录下单个开发员的任务以及对进度的估计。在开发阶段中，开发员在功能性说明的指导下写源代码，测试员写出测试项目组以检查产品的特性与工作范围是否正常，用户体验人员则编写出文档草案。当测试
16、员发现错误时，开发员并不是留待以后处理，而是马上改正，并在整个开发阶段内使测试不断地、自动地进行。这就改善了产品的稳定性并且使版本发布日期更易估计。当达到项目中的一定阶段点后（40%时），开发员就试图“锁定”产品的主要功能要求或特性，从此，只允许小范围的改动。如果在此点之后开发员想作大的改动，他们必须与程序经理以及开发经理进行讨论协商，也许还要征求产品部门经理的意见。(这里有两点，一个是提倡及早的发现缺陷和持续的集成，一个是后期严格的对需求变更进行控制）一个项目是围绕着3或4个主要的内部版本，或“里程碑子项目”来组织开发阶段的。一般用2至4个月来开发每一个主要的里程碑版本。每个版本都包括其自身
17、的编码、优化、测试以及调试活动。项目为意外事故保留总开发1/3的时间，即“缓冲时间”。(应该说1/3时间是足够多的，一般研发项目很难预备这么足够的Buffer)。当对最后一个主要的里程碑版本做了测试与稳定化之后，产品就要进行“外观固定”，即确定产品的主要用户界面，如菜单、对话框以及文件窗口等。此后有关用户界面将不再进行大的改动，以免引起同步修改相应文档的困难。2.4.3稳定化阶段稳定化阶段着重于对产品的测试与调试。项目在此阶段尽量不再增加新的功能，除非是竞争产品或者市场发生了变化。稳定化阶段也包括了缓冲时间，以应付不可预见的问题或者延迟。在软件的开发流程中，软件的测试与开发是一种“矛与盾”的关
18、系，互为补充，缺一不可。在微软，可能这种关系发挥到了极至：有时开发部门与测试部门互相较着劲，开发经理和测试经理的地位是相同的，有时甚至测试经理的地位甚至凌驾于开发经理之上，但他们之间没有根本的利益冲突，只有一个共同的目标：将产品的质量提高。为了保证产品的质量，微软一直采取零缺陷管理、手工测试与自动测试相结合、内部测试与外部测试相结合的原则。2.5产品微软过程的产品主要包括各类文档、源代码、可执行文件以及相应的文档代码。且微软过程提出了以产品特性及优先级指导整个项目。2.6四要素之间的关系在微软过程中，生命周期的进度、方法、人员及方法工具等项目资源、产品的功能与性能三者之间存在一种相互制约的均衡
19、三角形关系。均衡三角形的任意一边的改变将导致另外一边或两边的变化。产品的开发关键是在进度、资源、产品功能与性能三者之间寻找一个最佳的均衡。2.7本章小结微软过程是一套比较完整的软件过程模式，作为一种针对商业环境下具有有限资源和有限时间限制的项目的软件过程模式，它综合了诸多软件过程模式的优点，并且在人员及其组织过程中的方法等方面提出了独具特色的、操作性很强的实践规范，是一套优秀的成功项目开发实践经验总结。但是，微软过程也存在某些缺陷，如对方法和工具的选择、产品的优先级等方面的论述不够全面，并且有的原则本身也存在问题。 第三章、RUP的介绍3.1Rational 统一过程概述Rational统一过
20、程（Rational Unified Process, RUP）是由Rational公司推出的一种软件过程产品，其目标是：按照预先制定的时间计划和经费预算，开发高质量的软件产品以满足用户的需求。RUP提高了团队生产力。对于所有的关键开发活动它为每个团队成员提供了能使用准则、模板、工具指导来进行访问的知识基础，而通过对相同知识基础的理解，无论你是进行需求分析、设计、测试、项目管理或配置管理，均能确保全体成员共享相同的知识、过程和开发软件的视图。RUP的活动创建和维护模型。并且能对大部分开发过和提供自动化的工具支持。此过程以适合于在范围项目和机构的方式捕捉了许多现代软件开发过程的最佳实践部署。RU
21、P包括6项最佳实践： （1）迭代式开发。在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程以可以执行版本结束，可以鼓舞开发人员。（2）管理需求。确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用以被证明是捕获功能性需求的有效方法。（3）基于组件的体系结构。组件使重用成为可
22、能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。（4）可视化建模。RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。（5）验证软件质量。在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。（6）控制软件变更。迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之
23、中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。3.2 RUP的过程结构RUP软件开发生命周期是一个二维的软件开发模型（见图2.1）。纵轴代表核心工作流是静态的一面，横轴代表时间显示过程动态的一面，用周期、阶段、迭代、里程碑等名词描述。图2.1 RUP的二维结构过程3.3 RUP的动态结构软件的生命周期被分解为周期，每一个周期工作在产品新的一代上，RUP将周期分为四个个的阶段先启阶段、精化阶段、构建阶段、产品化阶段。每个阶段终结于良好定义的里程碑某些关键决策必须做出的时间点，因此关
24、键目标必须达到。3.3.1先启阶段先启阶段的目标是为系统建立业务用例和确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。它包括识别所有用例和描述一些重要的用例。业务用例包括验收规范、风险评估、所需资源估计、体现主要里程碑日期的阶段计划。本阶段具有非常重要的意义，在这个阶段中，关注的是整个项目进行工程中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，先启阶段的时间可能很短。（1）主要目标本阶段的主要目标有：明确软件系统的规模和边界条件，包括运作前景、验收标准以及希望产品中包括和不包括的内容。识别系统的关键用例。对比一些主要场景，展示至
25、少一个备选构架。 评估整个项目的总体成本和进度。评估潜在的风险。准备项目的支持环境。(2)产出本阶段的产出有：蓝图文档：核心项目需求、关键特色、主要约束的总体蓝图。原始用例模型（完成10%-20%）。原始项目术语表原始业务案例，包括业务的上下文、验收规范，成本预计。原始的风险评估。一个或多个原型。（3）里程碑先启阶段结束时到达第一个重要的里程碑，即生命周期目标里程碑，其评审标准是：风险承担者就范围定义、成本/日程估计达成共识。以客观的主要用例证实对需求的理解。成本/日程、优先级、风险和开发过程的可信度。被开发体系结构原型的深度和广度。实体开支与计划开支的比较。如果无法通过这个里程碑，则项目可能
26、被取消或者仔细地重新考虑。3.3.2精化阶段精化阶段是四个阶段中最关键的阶段，精化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。在此阶段，可执行的结构原型在一个或多个迭代过程中建立，依赖于项目的范围、规模、风险和先进程度。工作必须至少处理初始阶段中识别的关键用例，关键用例揭示了项目主要技术的风险。（1）主要目标精化阶段的主要目标：确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度。处理在构架方面具有重要意义的所有项目风险。建立一个已确定基线的构架，它是通过处理构架方面重要的场景得到的，这些场景通常可以显示项目的
27、最大技术风险。制作产品质量构件的演进式原型，也可能同时制作一个或多个可放弃的探索性原型，以减小特定风险。证明已建立基线的构架将在适当时间、以合理的成本支持系统需求。 建立产品的支持环境。（2）产出本阶段的产出是：用例模型补充捕获非功能性要求和非关联于特定用例要求的需求。可执行的软件原型。经修订过的风险清单和业务案例。总体项目的开发计划，包括在致的项目计划，显示迭代过程和对应的审核标准。指明被使用过程更新过的开发用例。（3）里程碑精化阶段结束时到达第二个重要的里程碑，即生命周期架构里程碑，其评审标准如下：产品前景和需求是稳定的。架构是稳定的。可执行原形表明已经找到了主要的风险元素，并且得到了妥善
28、解决。构建阶段的迭代计划足够详细和真实，可以保证工作继续进行。构建阶段的迭代计划有可靠的估算支持。所有涉众一致认为，如果在当前架构环境中执行当前计划来开发完整的系统，则当前的前景可以实现。实际的资源耗费与计划相比是可以接受的。3.3.3构建阶段在构建阶段，所有剩余的构件和应用程序功能被开发并集成为关品，所有的功能被详尽地测试。主要目标：优化资源和避免不必要的报废与返工，以最大限度的降低成本。快速达到足够好的质量。快速完成有用的版本完成所有所需功能的分析、开发和测试。迭代式、递增式地开发出随时可以发布到用户群的完整产品。确定软件、场地和用户是否已经为部署应用程序作好准备。 使开发团队的工作实现某
29、种程度的并行。（2）产出特定平台上的集成产品。用户手册。当前版本的描述。（3）里程碑构建阶段结束时到达每三个重要的里程碑，即最初操作性能的里程碑其评审标准应回答：该产品的发布版本是否足够稳定和成熟，是否可部署在用户群中?所有涉众是否己准备好将产品发布到用户群?实际的资源耗费与计划的相比是否仍可以接受?3.3.4产品化阶段产品化阶段是将软件产品交付给用户群体。（1）主要目标：进行Beta测试，使其能够达到用户的期望。 Beta测试和旧系统接并轨。转换操作数据库。培训用户和维护人员。市场营销、进行分发和向销售人员进行新产品介绍。具体部署相关活动。 调整活动，如进行调试、性能或可用性的增强。根据产品
30、的完整前景和验收标准，对部署基线进行的评估。实现用户的自我支持能力。在涉众之间达成共识，即部署基线已完成且与前景的评估标准一致。（2）里程碑产品化阶段结束时到达第四个重要的里程碑，即产品发布里程碑，其评审的应能对以下问题进行回答：用户是否满意？实际的资源耗费与计划相比是否可以接受？3.4 RUP的静态结构3.4.1模型元素开发流程定义了“谁”“何时”“如何”做“什么事”。即角色、活动、产品、工作流程，四种主要的建模元素来表达RUP。角色定义了明确行为和责任的个人和团队。活动是指由工作角色完成的工作，通常有明确的目标。产品是由过程产生、修改或使用的信息。工作流程描述了一系列活动执行的顺序，以及这
31、些活动能关生价值的结果。3.4.2核心工作流RUP的9个核心工作流是：业务建模，理解待开发系统所在的机构及其商业运作，确保所有人员对它有共同的认识，评估待开发系统对结构的影响；需求，定义系统功能及用户界面，为项目预算及计划提供基础；分析与设计，把需求分析结果转换为分析与设计模型；实现，把设计模型转换为实现结果，并做单元测试，集成为可执行系统；测试，验证所有需求是否已经被正确实现，对软件质量提出改进意见；部署，打包、分发、安装软件，培训用户及销售人员；配置与变更管理，跟踪并维护系统开发过程中产生的所有制品的完整性和一致性；项目管理，为软件开发项目提供计划、人员分配、执行、监控等方面指导，为风险管
32、理提供框架；环境，为软件开发机构提供软件开发环境。3.5本章小结RUP是一种具有二维结构和面向对象的软件开发过程方法，由四个阶段和九个核心工作流组成。这四个阶段通过时间来进行组织，是过程的生命特征，体现了开发过程的动态结构，主要以目标、产出和里程碑对其进行介绍。而九个核心工作流主要以内容组织为活动，体现了开发过程的静态结构，且以活动、产品、工作者和工作流程对其进行描述。RUP的用例驱动、以架构为中心、迭代和增量的过程，这三大特点让RUP在很多地方优于其它软件过程。但是RUP也存在着诸多的缺点，比如：大量文档，详细的计划:在基本工作之上存在大量的过程和时间开销。强调关注于诸多的规则，造成了一定程
33、度上的对人员的忽视。第四章 MRUP软件过程模式4.1MRUP的概述MRUP过程是基于MP、RUP而提出来的一种新型的软件开发过程，主要从软件的生命周期、人员、方法、产品这四个要素及他们之间的相互关系对软件过程进行了描述。4.2MRUP过程模式的生命周期及相关错误的规避MRUP软件过程模式在大型的软件开发项目中，为适当的避免项目的风险，生命周期中采用RUP中的迭代与增量的二维过程结构为主要的框架，每个生命周期采取四个连续的阶段，每个阶段要据需要细分为一次或多次迭代。每次迭代经历业务建模、需求、分析设计、实现、测试、部署、配置各变更管理、项目管理、环境工作流程中的若干项，并在每个阶段增设缓冲时间
34、，以降低进度压力和风险。而对于小型的软件开发，如：资源有限、时间进度限制比较多的小型项目时，最佳软件过程主要采取可采用微软过程中的五阶段模型，且可以根据需要对一些过程中的不必要事件进行裁剪（减少中间产品的输出），可以有效的节约时间，加快进度和提高资源的利用率。在生命周期中通常会出现对项目的生命周期进度计划过于乐观和进度落后的情况。我们首先应该在早期进行预防，比如在生命周期的每个阶段加上一次的缓冲时间。且对于难以实现的进度要求进行坚决地、同时技巧性地顶住压力，据理力争。同时如果时间是无法改变的，可以对软件过程模式四大要素中的其他三要素进行调整，争取能找到一个平衡点，来满足客户的需求。4.3MRU
35、P过程模式的人员软件公司的差别可能有各种各样的，但最大的应该是人的差别，重视人的作用，以人为本是一个企业成功的关键。在最佳软件过程中的人员及组织管理主要采用微软过程中的矩阵结构的模式。4.3.1人员的分配及角色安排把项目组的人员分成产品管理、程序管理、开发、测试、用户体验与发布管理六种角色，一个人员或一组成员可以担任多个角色，但是两个明显有利益冲突或冲突的角色不能由同一个或同一组人员担任。在地位上各种角色是平等的，并且针对不同的角色进行好任务分配，使之责、权、利，能够清晰明了，避免部门间的扯皮。同时对各项目小组的人员进行控制，最好在10人以下，这样使使小组能进行更好的交流和管理。另外在人员的角
36、色安排上根据个人的特点合理的安排其职务，比如有创意的人安排在开发上，细心的人安排测试方面，争取避人所短，用人所长。4.3.2人员的选取和激励人员的素质直接影响到一个项目的质量，在这里我们更推荐专家式的管理，从事并管理一个行业必需对一个行业有所了解，甚至精通。这样才能使得被自己所管理的人员不至于敷衍了事。且能在手下遇到问题时能够更好的解决。同时对项目的时间进度的把握能够更加的客观。至于人员的激励包括物质和精神两个层面。1、物质方面的激励主要包括高薪、奖金、股权、舒适的工作环境和合理的工作时间及假期。作为软件过程开发人员，一般都是高素质的人才，这样的人更加的重视精神层的激励。2、精神层面的激励主要
37、包括受重视和尊重的程度、对从事工作的兴趣程度、个人技术技能得以提高的机会、个人得以升迁的机会。比如：在薪酬方面，工作人员不仅关注自己的实际收入而且容易在乎自己的相对收入，即：把自己的收入与同事同一时期的收入进行比较，如果相对比（实际收入/同事的收入）等于1就觉得很公平，否则就觉得不公平。类似现象是工作过程中经常遇到同时也是负责人必须处理的问题。因为这类问题处理的恰当与否对工作人员地工作积极性有着严重的影响，从而影响软件开发的进度与软件的质量。4.4MRUP过程模式方法4.4.1关于需求分析方面构建用户模型以获取需求，在此阶段通过以一个可见的、可触摸的、可操作的用户模型展示在用户的面前，使用户能
38、更清楚的了解项目，并且积极引导客户的参与，通过其不断反馈来修改原型，以争取能够更清楚的了解用户的需求，并且使客户了解项目人员。在自己开发新软件时可以通过对客户的细分，最大程度的满足各种不同客户的需求。针对于变化则采取前期欢迎变化、后期稳定需求，即：先基线化后冻结的策略，使自己在后期不至于因为需求的更改造成时间进度的拖延，甚至无法完成工作。4.4.2关于工具的选择、实现与测试选择比较成熟的、适合自己的、而且被许多厂家实践证明是非常有效的工具对工作质量和工作效率的提高都很有帮助。在编译代码时就要注意到代码的运行效率、安全性、稳定性、可理解性、可维护性等多个方面。并且建立源代码的管理库，每日进行检查
39、和编译，持续更新和集成。把高要求的“零缺陷”的观念引入到软件的质量管理当中，并且把手工测试与自动测试、内部测试与外部测试相结合的方法去进行测试。4.4.3关于设计方面首先根据实际情况（时间、费员、人员、技术等利益的全面衡量）确定是自己建造、复用还是外包，例如：企业根据自身的流程，把自己不愿意做的和自己做不好的工作包给别人。其次，对各种方式必须要有一定的了解，例如：自己建造有利于提高开发人员的水平；而对于自己因缺少技术而外包的软件，可以节约成本，减少风险。4.5MRUP过程模式的产品MRUP过程对各种中间产品和最终产品进行分类，对内和对外产品进行分类，对类的产品应该简洁明了，能使内部人员了解就行
40、，这样便于节约时间。而对外产品我们应该从用户的角度出发，为用户着想，尽可能做到详细，易理解，易操作。在产品的开发中，可以对产品的类型优先级进行排列，比如：可以工作的软件比文档更能解决实际需要。重视工作软件的创建而非文档的制作。而对于最终的产品，就从产品的质量性能和功能规模两个方面进行度量。由于功能特性是产品竞争力的主要表现，所以强调尽早确定产品功能特性，以产品优先级指导整个项目。在质量方面要求低缺陷率、性能方面的可读性、易维护性、健壮性、可扩展性等等。总之产品功能规模和质量特性的控制应与项目人员投入、资金投入和进度要求相适应。4.6 MRUP过程模式的生命周期、人员、方法与产品四要素间的关系在
41、MRUP过程模式中的生命周期、人员、方法与产品四要素之间始终遵循着微软过程中的均衡三角形关系，一个元素的变更直接影响到其他元素中的一个或多个的变化。要想发布一个符合客户需求的产品，主要要求在时间、项目人员与方法工具等资源、产品的功能与性能之间找到一个最佳的平衡点。4.7本章小结MRUP综合了MP、RUP两种软件过程，并且针对他们存在的一些不足进行了改进，在生命周期上，它针对不同类型项目提出了不同解决方案；在人员管理上，提出了以人为本的准则；在方法上，对其研究和使用做出了全面的分析；在产品上，产品的分类和优先级的提出使工作人员对产品能更好的把握。且通过实践证明，MRUP过程的应用能够帮助软件公司
42、更好的开发软件。第五章 总结与展望总结本文的研究目标是通过对MP、RUP的学习，总结出一种实用的软件过程模式。在MP的学习过程中，我们了解到微软过程特别重视人的因素，从不同的角度对人员进行了描述，充分发挥人的主观能动性。而在RUP的学习当中，我们感觉到，无论是以用例驱动，以架构为中心，还是增量和迭代，都在重视过程的研究，使过程更清楚明了，以降低风险。而在软件的开发过程当中，应该全面的进行考虑，人和方法一样重要，忽视谁的作用都会为之付出沉重的代价。而本文基于软件过程的四要素及它们之间的相互关系提出了MRUP过程。MRUP过程综合了MP、RUP的优点，避免了它们的缺陷。并且根据实际情况，对项目的类
43、型进行了分类，这样更加有利于方法的实施。展望自从软件危机出现以来，许多大型的软件公司都致力于寻找新的方法来解决这种尴尬处境，据统计，现在软件项目中，顺利完成的仅仅只占总项目的16%，不论是MP、RUP还是MRUP过程，虽然有着许多的优点，但在这种软件开发成功率普遍低下的情况下人们需要在软件开发应用上不断完善，不断的总结经验，才能更好的开发出受到用户喜爱的软件。目前在软件开发中，有着许多的方法，各自有总各自存在的道理，也有一定的适用环境。但是可以预测，但是随着人们对过程方法应用经验的越来越丰富，软件开发将会出现更加实用的方法。致 谢首先，我要衷心的感谢 老师，本论文是在 老师的悉心指导下完成的。
44、 老师对本论文的选题、总体结构及论文的内容给予了详尽的指导，并且提出了宝贵的意见，正是他严格的要求和严谨的治学态度令本人有了论文研究的方向和最终的研究成果。导师渊博的知识、宽阔的胸襟和谦虚谨慎的人生态度深深的感召和影响着我，让我终生受益。其次，感谢计算机系的全体老师们，感谢他们四年以来对我孜孜不倦的教侮和无私的帮助。再次，感谢我的同学，在学习和写作中对我进行了大量的帮助和支持，在与他们进行交流的过程中，给了本人许多的灵感和建议。最后，感谢本论文所引用的参考文献的作者和出版社。参考文献1 金敏 主编. 高级软件开发过程. 北京: 清华大学出版社，20052 郑人杰 主编. 软件工程（高级）. 北
45、京: 清华大学出版社，19993 Robert L. Class. Software Runaways，Lessons Learned from Massive Software Project Failures. Englewood Cliffs，NJ: Prentice Hall，1998 4 Edward Yourdon. Death March，The Complete Software Developers Guide to Surviving“Mission Impossible”Projects. Englewood Cliffs，NJ: Prentice Hall，19985
46、Rational Software Corporation. Rational Unified Process（Chinese）version 2000.02. 10.18, 20006 Rational Software Corporation. Rational Unified ProcessBest Practices for Software Development Teams. A Rational Software Corporation White Paper, 20007 Ivar Jacobson，Grady Booch，James Rumbaugh (美)著，周伯生等译.
47、统一软件开发过程. 北京: 机械工业出版社，20028 Philippe Kruchten（美）著，周伯生等译. Rational统一过程引论. 北京: 机械工业出版社，20029 陈宏刚等著. 软件开发过程与案例. 北京: 清华大学出版社，200310 陈宏刚等著. 软件开发的科学与艺术. 北京: 电子工业出版社，200211 Pete McBreen. Software Craftsmanship. Reading，MA: Addison Wesley Publishing Company，200112 Frederick P. Brooks（美）著，汪颖译. 人月神话. 北京: 清华大学出版社，200213 Grady Booch，James Rumbaugh，Ivar Jacobson（美）著，邵维忠等译. UML用户指南. 北京：机械工业出版社，200214
