软件开发过程软件生命周期.docx

软件开发过程软件生命周期.docx

《软件开发过程软件生命周期.docx》由会员分享，可在线阅读，更多相关《软件开发过程软件生命周期.docx（13页珍藏版）》请在冰点文库上搜索。

软件开发过程软件生命周期

软件生命周期

SoftwareDevelopmentLifeCircle

文件状态：

[]草稿

[√]正式发布

[]正在修改

文件编号：

QUANTA-SEP-Process-10

当前版本：

1.0

版本历史

版本/状态

作者

参与者

日期

摘要

1.0

余成军

2008-9-26

新建

版权信息

本文件内容由海口量子网络科技有限公司开发部负责解释

本文件的版权属于海口量子网络科技有限公司

任何形式的散发都必须先得到海口量子网络科技有限公司的许可

【目录】

1概述5

1.1编写目的5

1.2适用范围5

1.3术语和缩写5

1.4参考资料5

2输入5

3输出5

4角色和职责6

5生命周期模型6

5.1瀑布模型6

5.1.1瀑布模型的软件开发阶段6

5.1.2瀑布模型的特点及优缺点6

5.2快速原型开发模型8

5.2.1快速原型开发模型的软件开发阶段8

5.2.2快速原型开发模型的特点及优缺点8

5.3渐进交付模型9

5.3.1渐进交付模型的软件开发阶段9

5.3.2渐进交付模型的特点及优缺点9

5.4循环迭代模型10

5.4.1循环迭代模型的软件开发阶段10

5.4.2循环迭代模型的特点及优缺点10

6项目对软件开发周期模型的选择11

7裁剪指南13

1概述

1.1编写目的

在公司建立此文件，以规范公司所有开发过程，并为公司所有项目提供选择软件开发周期模型的指南，使得所有项目能依据项目的特点和现实情况，选择合适的软件开发周期模型，提高项目的效率，减少开发成本，保证软件质量。

1.2适用范围

本文件适用于公司所有软件开发项目。

1.3术语和缩写

术语和缩写

解释

备注

1.4参考资料

参考文件

备注

CMMIV1.1

2输入

输入制品

备注

项目特性

3输出

输出制品

备注

《过程剪裁报告》

4角色和职责

角色

职责

项目经理

负责根据项目特性并和生命周期选择指南挑选项目生命周期。

5生命周期模型

5.1瀑布模型

5.1.1瀑布模型的阶段图示

5.1.2瀑布模型的阶段描述

需求分析阶段

根据项目范围进行软件系统需求分析的活动，将用户问题域的描述，转化成解决域的描述，给后续的系统设计和开发工作提供依据。

典型工作产品是《用户需求说明书》和《需求规格说明书》。

详细介绍参见需求开发和管理过程。

设计阶段

将需求分析的结果，用概念来实现和验证，这是解决域的概念阶段，为后续的开发工作提供蓝图和指导。

典型工作产品是《体系结构设计说明书》和《数据库设计说明书》。

详细介绍参见系统设计过程。

实现阶段

按设计结果构造系统的阶段。

包括编码，单元测试，代码集成和集成测试工作。

此阶段将完成系统的构造。

典型工作产品是源代码和《单元测试用例》《集成测试用例》《单元测试报告》《单元测试报告》。

详细介绍参见系统实现过程。

系统测试阶段

系统构造完成后，验证构造的系统是否符合客户的需要的阶段。

包括系统测试计划工作，系统测试用例编写，执行系统测试工作。

典型工作产品是《系统测试用例》《系统测试总结报告》。

需要指出的是系统测试阶段并不是完全等实现阶段结束后才开始。

它的早期活动甚至开始于需求分析阶段。

具体说，系统测试计划在项目开发综合计划制定时开始编制；系统测试用例在需求分析基线后。

详细介绍参见系统测试过程

软件发布阶段

系统测试完成后，将软件交付客户，并对客户进行培训，同时客户要组织对系统进行验收测试的阶段。

典型工作产品是《用户手册》《安装维护手册》和《安装维护手册》。

详细介绍参见软件发布过程。

5.1.3瀑布模型的特点及优缺点

特点

文件驱动的，主要工作成果是通过文档从一个阶段传递到下一个阶段；

项目按照一定顺序的步骤进行，通过划分阶段，建立里程碑，在一个阶段结束时进行检查，以判断是否可以开始下一阶段工作，如果检查的结果是项目还未准备好进入下一阶段，它就停留在本阶段，直到当前阶段工作完成；

优点

具有清晰的阶段结构，便于项目的跟踪、管理；

如果前期需求非常清晰、完整、稳定，则瀑布模型，则目标明确，项目计划将非常清晰，便于计划实现；

通过阶段性的检查，及早发现问题，提高产品质量，降低下阶段的成本；

由于需求稳定，基线也稳定，以下阶段的工作能很好地被定义，需求容易实现和管理；

缺点

要求前期的需求清晰、完整、稳定，但很多项目很难达到，这需要花大量的成本；

缺乏应变能力，当需求变动时，项目进度将受到影响，管理成本将增加；

缺乏灵活性，当本阶段工作进行当中，发现上一阶段的缺陷，将很少也很难能回退，例如在编码阶段，设计经常需要变更；

通常，在设计阶段，才发现需求问题；在编码阶段，才能发现需求和设计问题；在测试阶段，才大量发现需求、设计、编码的问题；

缺乏用户反馈，直到软件运行时，才能知道用户的满意程度；

软件在最后阶段才实现，导致很多缺陷可能到软件运行时才被发现，其修改工作极其庞大，项目成本大幅增加，进度严重拖后；

由于都是文件驱动，要求文档质量很高，项目成员要有很好的共同理解力；

大量文件产生，任何变动或缺陷，可能导致大幅度修改文档，其副作用可能使一些文件流于形式，完全与现实不符；

5.2快速原型开发模型

5.2.1快速原型模型的阶段图示

5.2.2快速原型模型的阶段描述

快速原型阶段

在客户对系统需求不明确的情况下，通过开发系统的原型或者界面的原型让客户对未来的系统有一个直观的认知，剔除在需求沟通中的很多障碍，有利于得到客户真实的需要。

典型工作产品是系统原型和界面原型。

其他阶段

同瀑布模型。

5.2.3快速原型开发模型的特点及优缺点

特点

开始时，根据基本概念快速建立原型，通过反复的用户回馈和原型修改，逐渐与用户达成一致；

在用户确认的原型的基础上，按照瀑布方式进行实际的软件开发；

优点

一开始，通过原型与用户达成一致理解，使需求更加明确，大大减少日后软件发布后，与用户需求不符的风险，同时，用户能较早地看见实体，帮助其提出切实的需求；

在用户确认的原型的基础上，开发的整个过程，能与用户有较好的交互；

不需大量的文档，以最简单方式和最小的成本代价快速建立原型；

快速原型模型仍然是一种瀑布模式，其优点与瀑布模型相同，同时能补救瀑布模型中需求不确定导致的缺陷

缺点

原型开发的周期较长，反复多次而不知道什么时候结束，项目的计划无法明确；

可能导致直接修改原型代码，作为软件的提交版本，跳过真正的需求定义、设计的过程，使软件质量有潜在缺陷，项目管理、跟踪难以保证；

要采用适当的建立原型工具，否则工作量将很大，对建立原型的人员的要求很高；

仍然缺乏应变能力，若后期需求经常变动时，其缺陷同瀑布模型；

与瀑布模型相同，阶段是很难回退，发现并纠正上阶段的缺陷，将要花费较大成本；

与瀑布模型相同，是文件驱动，要求文档质量很高，项目成员要有很好的共同理解力；大量文件产生，任何变动或缺陷，可能导致大幅度修改文档，其副作用可能使一些文件流于形式，完全与现实不符；

5.3渐进交付模型

5.3.1渐进交付模型的阶段图示

5.3.2渐进交付模型的阶段描述

需求定义阶段

是瀑布模型需求分析阶段和快速原型模型快速原型阶段的结合。

目的是尽可能多的挖掘客户核心的、重要的需求，以期对后续的设计形成相对稳定的依据。

总体设计阶段

同瀑布模型的设计阶段。

但其重点关注，系统架构和内核的设计。

实现阶段

这是一个循环的开发过程。

每个循环相当于一个小瀑布。

每次循环都必须事先定义清楚要实现的需求和发布版本包含哪些内容。

软件提交阶段

同瀑布模型的软件发布阶段。

这时软件全部完成的发布阶段。

5.3.3渐进交付模型的特点及优缺点

特点

是快速原型模型和阶段交付模型的一个结合；

不需要一开始就要求需求明确，在一个基本需求上就可以先开发一个软件产品版本（非原型，应类似于模型），再通过用户的反馈和需求的逐渐明朗，修改软件直至用户满意；

优点

适应于在开始阶段需求完全不明朗的项目，只需一个核心的需求就能着手开发；

继承阶段交付模型的优点，可以把较独立的模块不同迭代阶段开发，先开发核心部分，在逐渐开发外围部分，分阶段测试，并及早把有用的功能交到用户手上尽早使用，提出反馈意见和明确需求，则可以在下阶段进行有效地修改；

项目经理可以自由调整每次迭代的工作层面（即不需每次都必须详细设计到编码到测试），可根据需求和修改量决定本次迭代从什么阶段开始，只做哪些工作；

缺点

需求的不断变更，文档的不断修改，要求项目经理具有较强的分析、管理和控制能力，应避免对一个变更不加分析、控制就随意修改，导致迭代没完没了，文档的修改成为泛滥而被抛弃；

如果管理和技术上缺乏仔细的规划，效果可能适得其反；

5.4循环迭代模型

5.4.1循环迭代模型的阶段图示

5.4.2循环迭代模型的阶段描述

策划阶段

对项目范围作初步划分。

规划每个迭代相对应的项目范围。

实施阶段

每次迭代相当于一个完整的小项目。

软件发布阶段

同瀑布模型的软件发布阶段。

这时软件全部完成的发布阶段。

5.4.3循环迭代模型的特点及优缺点

特点

类似于渐进交付模型，但其开始阶段的需求更加不明确，甚至只有一些核心理念，在逐步试探和摸索中完成项目，适合于自研项目；

不需要一开始就要求需求明确，在一个基本需求上就可以先开发一个软件产品版本（非原型，应类似于模型），再通过测试和效果分析，再规划下一次迭代的工作，直至软件达到要求；

优点

适应于在开始阶段需求完全不明朗的项目，只需一个核心的需求就能着手开发；

继承渐进交付模型的优点，可以把较独立的模块在不同迭代中开发，先开发核心部分，在逐渐开发外围部分，分阶段测试，并及早发现软件问题，则可以在下次迭代进行有效地修改，同时需求也逐渐清晰和完整；

项目经理可以自由调整每次迭代的工作层面（即不需每次都必须严格的需求分析到总体设计到详细设计到编码到测试），可根据需求和修改量决定本次迭代从什么阶段开始，只做哪些工作，或较快速地进行新一轮的迭代；

缺点

同样，需求的不断变更，文档的不断修改，要求项目经理具有较强的分析、管理和控制能力，应避免对一个变更不加分析、控制就随意修改，导致迭代没完没了，文档的修改成为泛滥而被抛弃；

如果管理和技术上缺乏仔细的规划，效果可能适得其反；

6项目软件开发周期模型的选择

作为一个项目的主要计划，选择合适的软件开发周期模型对项目的成功影响很重要，恰当的模型可以使项目流程化，并帮助项目经理一步一步接近目标。

如果选择了适宜的模型，就可以提高开发速度，提升质量、加强项目跟踪和控制、减少成本、降低风险，或者改善用户关系。

错误地选择软件开发周期模型，必定会导致工作拖沓、劳动重复、无谓的浪费和遭受挫折。

不选择软件开发周期模型也导致同样的结果。

以上列出的7种软件开发周期模型，只是基本模型，并没有一个完全符合某些项目的模型，也没有一个完全不符合某些项目的模型，关键在于项目经理如何分析项目的具体情况，权衡利弊，从中选择一个合适的模型，或者创造性地结合多个模型或进行变形，形成独特的项目开发过程。

参见《过程剪裁报告》生命周期选择指南。