软件过程与模型思维脑图思维导图

过程模型简单，执行容易；缺点是无法适应变更。

在软件开发的过程中，需求不发生或发生很少变化，并且开发人员可以一次性获取到全部需求。

软件开发人员具有丰富的经验，对软件应用领域很熟悉。

软件项目的风险较低。瀑布模型不具有完善的风险控制机制。

是“快速”。开发人员应该尽可能快地建造出一个原型系统，以加速软件开发过程，节约软件开发成本。

是获知用户的真正需求，一旦需求确定了，原型将被抛弃。

有助于获取和理解用户需求；

尽早发现软件中存在的错误；

支持项目需求的动态变化。

不能支持风险分析；

开发者为了使一个原型快速运行起来，往往在实现过程中采用折衷的手段。

已有产品或产品的原型，只需客户化的工程项目；

简单而熟悉的行业或领域；

有快速原型开发工具；

进行产品移植或升级开发者在不了解的应用领域开发；

客户不清楚其所开发的软件项目的最终目标。

基于瀑布模型的渐增模型

基于原型的快速原型模型

增量式开发是指在软件开发过程中，先开发主要功能模块，再开发次要功能模块，逐步完善，最终开发出符合需求的软件产品。

当产品不能在限定时间完成时，提供了先推出核心产品的途径。

逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品。

当需求变更时，需要重新完成的分析和文档数量比较少。

在开发过程中更容易得到客户对于已完成的开发工作的反馈意见。

更快速地交付和部署有用的软件给客户成为可能。

人员分配灵活，刚开始不需投入大量人力资源。

软件体系结构必须是开放的。

模型本身是自相矛盾的。整体——独立构件。

不同的构件并行进行有可能加快工程进度，有时无法集成到一起。

整个过程是不可见的。管理人员需要定期交付成果来掌握进度。

随着新的增量的添加，系统结构趋向于降级。

迭代地进行软件产品开发;

需求获取、设计、编码和测试活动之间会有大量重叠;

如果需求的任何阶段出现缺陷，会使该需求返回到前面的阶段;

开发人员能够在任何时候演示当时产品所具有的功能;

可以降低在项目后期发现重大缺陷的风险。

有助于获取用户需求，加强对需求的理解。

尽早发现软件中的错误。

支持需求的动态变化。

支持风险分析，可降低或者消除软件开发风险。

适合于需求动态变化，难以确定开发风险的系统。

螺旋模型开发的成败，很大程度上依赖于风险评估的成败。

需要开发人员具有相当丰富的风险评估经验和专门知识。

需求不能完全确定，同时又存在技术、资金或开发时间等风险因素的大型开发项目。

喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。

迭代是指各阶段需要多次重复，例如，分析和设计阶段常常需要多次、重复进行，以更好的实现需求。

无间隙性是指各个阶段之间没有明显的界限，并常常在时间上互相交叉，并行进行。

该模型的各个阶段没有明显界限，开发人员可以同步进行开发。

多次反复地增加或明确目标系统，降低了错误的可能性。

由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，不利于项目的管理。

要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

在确定需求之后，开发人员开始从现有的组件库中筛选合适的组件，并对组件功能进行分析。

在对组件分析之后，开发人员可能适当修改需求来适应现有组件，也可能修改组件或寻找新的组件。

组件筛选完成之后，开发人员需要根据需求设计或使用现有的成熟开发框架复用这些组件，一些无法利用现有组件的地方，则需要进行单独的开发，新开发的组件在经历时间考验之后也会加入到组件库中。

最后将所有组件集成在一起，进行系统测试。

基于统一软件开发过程模型所构造的软件系统，是由软件构件建造而成的。这些软件构件定义了明确的接口，相互连接成整个系统。

在构造软件系统时，RUP采用架构优先的策略。软件架构概念包含了系统中最重要的静态结构和动态特征，架构体现了系统的总体设计。

统一软件开发过程模型适用的范围极为广泛，但是对开发人员的素质要求较高。

个体与交互高于过程和工具；

可运行软件高于详尽的文档；

与客户协作高于合同谈判；

对变更及时响应高于遵循计划。

在项目计划阶段，需要建立合理和简洁的用户故事。

在设计系统的体系架构时，可以采用CRC（Class，Responsibility，Collaboration）卡促使团队成员共同努力。

在代码编写阶段，为了保证代码的质量，可以采用结对编程以及在编码之前构造测试用例等措施。

在代码测试方面，开发人员有责任向用户证明代码的正确性，而不是由用户来查找代码的缺陷。合理的测试用例及较高的测试覆盖率是极限编程项目测试所追求的目标。