软件生命周期模型指南
*修订类型分为：A－ADDED，M－MODIFIED，D－DELETED。
目录
1.前言 (1)
2.目的 (1)
3.使用范围 (1)
4.名词和缩写 (1)
5.角色和职责 (1)
6.瀑布模型 (1)
6.1. 瀑布模型定义 (1)
6.2. 瀑布模型示意图 (2)
6.3. 阶段工作概要说明 (3)
6.3.1. 项目立项阶段 (3)
6.3.2. 需求开发阶段 (3)
6.3.3. 设计阶段 (3)
6.3.4. 实现阶段 (3)
6.3.5. 集成阶段 (3)
6.3.6. 技术测试阶段 (3)
6.3.7. 业务验收阶段 (4)
6.4. 瀑布模型优缺点 (4)
6.5. 瀑布模型适用项目 (4)
7.迭代模型 (4)
7.1. 迭代模型定义 (4)
7.2. 迭代模型示意图 (5)
7.3. 迭代、瀑布与增量三者之间的区别 (5)
7.4. 采用迭代模型的优点 (7)
7.5. 迭代模型适用项目 (7)
8.选择项目生命周期模型 (7)
8.1. 明确项目特点 (7)
8.2. 选择项目的生命周期模型 (8)
9.相关文件 (8)
1.前言
软件生命周期是指软件产品或软件系统从产生、投入使用到被淘汰的全过程。在计算机技术发展的初期，人们把软件开发简单地理解为编写程序，随着软件复杂性的增长，人们认识到软件开发活动应划分为项目立项、需求开发、设计、实现、集成、技术测试、业务验收等若干个活动去进行，并将这些活动以适当的方式分配到不同的阶段中去完成。
软件生命周期模型是描述软件开发全部过程、活动和任务的结构框架。本文主要介绍瀑布模型和迭代模型两种常见的生命周期模型。
2.目的
建立适用于数据中心软件开发的生命周期模型，分类汇总和统计各类生命周期模型指标和数据，指导项目组进行项目生命周期规划。
3.使用范围
本文适用于数据中心所有软件发项目。项目组在进行项目策划时，可根据本指南中各模型的特点、优缺点和项目实际情况，选择项目的生命周期模型。
4.名词和缩写
5.角色和职责
6.瀑布模型
6.1.瀑布模型定义
瀑布模型是广泛采用的一种生命周期模型，又称线性模型。瀑布模型一般包括制定计划、需求分析、软件设计、程序编写、软件测试、运行维护等基本活动，并规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型满足以下特征：
1)上一项活动的工作成果是下一项活动的输入；
2)利用上一项活动的输入来完成当前活动所需的工作内容；
3)当前活动的工作内容需要进行验证，如果验证通过，则该结果作为下一
项活动的输入，继续进行下一项活动，否则返回前项；
4)强调文档的作用，并要求每个阶段都要仔细验证。
采用瀑布模型的项目需依照瀑布模型定义的各阶段顺序实施项目，每一个阶段的工作产品都是下一个阶段工作的输入，项目必须有明确的里程碑，在每个里程碑点都要进行里程碑评审。
瀑布模型中，每个阶段完成后，可以在下一个阶段修改上一个阶段的工作产品，但是必须按照基线变更进行管理。如果发生变更，需要回溯前面所有阶段的工作产品，以使工作产品保持一致。
6.2.瀑布模型示意图
图1. 瀑布模型示意图
6.3.阶段工作概要说明
6.3.1.项目立项阶段
包括项目立项和项目计划两部分内容，项目立项阶段需完成立项审批和发布、建立定义项目活动的一组计划等，项目计划必须纳入基线管理。具体活动可按照《项目计划过程》进行。
6.3.2.需求开发阶段
包括进行业务需求获取和整理，对需求进行分析与问题确认、完成《需求规格说明书》的编写和评审等。需求开发阶段必须保证项目干系人在项目实施过程中始终保持对需求一致的理解和承诺，需求开发阶段的输出物必须纳入基线管理。可建立需求里程碑，具体活动按照《需求开发过程文件》、《需求管理过程文件》进行。
6.3.3.设计阶段
项目组根据已基线化的需求文档进行软件架构、数据库、界面、接口和功能实现设计。设计阶段可细分为总体设计、详细设计两个部分，输出《设计说明书》。如果符合决策分析入口条件，设计阶段还需按照决策分析过程完成方案选型。设计阶段必须保证设计和需求的一致性，其输出物必须纳入基线管理。可建立设计里程碑，具体活动按照《设计过程文件》、《决策分析过程文件》进行。
6.3.4.实现阶段
实现阶段包括编码、代码审查、单元测试、集成测试等。实现阶段必须保证代码实现与设计的一致性，输出通过单元测试的可运行程序。可建立实现里程碑，具体活动按照《实现过程文件》进行。
6.3.5.集成阶段
集成阶段包括编写《项目集成方案》、建立并维护集成环境与测试环境、完成项目集成、更新测试环境等。具体活动按照《集成过程文件》进行。
6.3.6.技术测试阶段
测试阶段包括设计测试用例、测试程序、测试数据、执行系统测试和回归测试，编写测试报告等。测试阶段的输出物必须纳入基线管理。可建立测试里程碑，具体活动按照《技术测试过程文件》进行。
6.3.
7.业务验收阶段
包括设计业务验收测试用例、执行业务验收测试、编写业务验收测试报告和用户操作手册等。具体活动按照《业务验收测试过程文件》进行。
6.4.瀑布模型优缺点
该模型的优点：
1.为软件开发工作提供一种结构化、有序的方法；
2.使用简单，每一个阶段的工作清晰明了；
3.可以及早发现问题，降低项目的阶段成本；
4.利于进行过程控制，每个阶段的可见性较强；
5.过程记录比较完整，且易于维护。
该模型的缺点：
1.各个阶段之间产生大量的文档，极大的增加了项目的工作量；
2.项目从开始到发布可运行版本需要较长的周期，用户直到项目开发后期
才能了解产品的真实面目和质量，从而增加了开发的风险；
3.早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的
后果，项目返工风险较大，例如当发生需求遗漏时。
6.5.瀑布模型适用项目
1.产品定义（或项目需求）和技术方案非常明确，开发人员对用户的需求
有很好的了解，需求变更较少；
2.对质量的要求高于对成本和进度的要求；
3.开发队伍技术力量较弱或缺乏经验；
4.维护项目。
7.迭代模型
7.1.迭代模型定义
早在20世纪50年代末期，软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型（stagewise model）”。迭代模型是RUP（Rational Unified Process，统一软件开发过程，统一软件过程)推荐的周期模型。
在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程，至少包括需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
迭代模型满足以下特征：
1)每次迭代都包括很多的开发活动（需求、分析、设计、实现等），每次
迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集；
2)每一个后续迭代都建立在前一个迭代基础以使系统得到完成和发展，直
至最终软件产品完成；
在迭代模型中，往往以项目涉及的需求为项目目标，以风险来驱动项目发展，以项目要求达到的状态为基线或里程碑，通过把项目最终满足的需求应达到的最终状态划分成各个基线（或里程碑）状态。
在迭代模型中，每个迭代的周期是较短的。一般不建议超过3周，常采用2周为一个迭代，小项目往往会采用1周为一个迭代。只有较短的迭代周期，才具有规避失败风险的成本承受力，才能在较短的时间内快速调整项目进度的方向。过长的迭代周期，往往会使迭代失去规避风险的作用。
7.2.迭代模型示意图
图2. 迭代模型示意图
7.3.迭代、瀑布与增量三者之间的区别
瀑布模型：瀑布模型是一个五阶段的线性模型，由需求开发阶段、设计阶段、实现阶段、测试阶段和发布阶段组成。
增量模型：适用于项目需求较为明确，市场需求紧迫，需要快速向客户提供部分功能的项目。在增量模型中，需要对需求进行分类，明确各版本实现的需求，然后先后完成各版本的设计开发。
迭代模型：适用于需求还不是很明确，市场需求又较为紧迫的情况，通过多次迭代来不断完善需求与项目产出，每次迭代对已明确的一部分需求进行设计开发。
图3.瀑布、迭代和增量三个模型的区别在这三个模型之中，迭代与增量比较容易混淆，特举例说明如下：
假设现在要开发A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间，则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二次增量完成C,D功能。而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐渐细化补充完整相关的业务逻辑。在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的基础功能都已经完成。
7.4.采用迭代模型的优点
1、降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损
失只是这一个开发有误的迭代的花费。每次迭代完成时都会生成一个经
过测试的可执行文件，这样就可以核实是否已经降低了目标风险。
2、降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定
风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
3、加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们
的工作会更有效率。
4、由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续
阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容
易些。
7.5.迭代模型适用项目
1、在项目开发早期需求可能有所变化。
2、分析设计人员对应用领域很熟悉。
3、高风险项目。
4、用户可不同程度地参与整个项目的开发过程。
5、使用面向对象的语言或统一建模语言（Unified Modeling Language，
UML）。
6、使用CASE（Computer Aided Software Engineering，计算机辅助软件
工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具）。
7、具有高素质的项目管理者和软件研发团队
8.选择项目生命周期模型
8.1.明确项目特点
为明确项目特点，请回答下列问题，每个问题只能选择一个答案：
1、此项目的用户需求是：
已经得到很好的理解并文档化的
可能会发生变化（比如，由于新的技术或任务）
没有被很好的理解
2、资金和人员准备情况：
已经一次到位
逐步到位
3、用户是否同意阶段性交付功能需求？
是
否
4、原来的系统(如果存在的话)能否逐步淘汰：
一次性全部淘汰
分步淘汰
逐渐淘汰
5、项目一次完成，规模、工作量是否太大？
是
否
6、项目一次完成，是否太复杂（新技术，多个组织配合，异地开发）？
是
否
7、核心技术是否容易发生变化？
是
否
8、项目是否有很高的风险？
是
否
9、风险的估计基于：
在工作陈述中估计的高风险
在项目策划过程中的详细风险分析活动
8.2.选择项目的生命周期模型
识别出项目特点后，项目经理综合考虑瀑布模型和迭代模型的特点、优缺点等，选择项目的生命周期模型。
如果无法决定采用何种生命周期模型，可视情况进入决策分析过程，利用结构化的方法选择出适合项目的生命周期模型。
9.相关文件
《项目管理办法》、《项目计划过程》、《需求管理过程文件》、《需求开发过程文件》、《设计过程文件》、《决策分析过程文件》、《实现过程文件》、《集成过程文件》、《技术测试过程文件》、《业务验收测试过程文件》。
瀑布模型/改进的瀑布模型 虽然瀑布模型仍然存在很多的问题有待解决，但瀑布模型仍然是最展本的和最效的?种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求-〉分析-〉设计?〉编码-> 测试的阶段进行，每-个阶段都可以定义明确的产出物和验证准则.瀑布模型在每?个阶段完成后都可以组织相关的评审和验证，只有在评审通过后才能够进入到下-个阶段. 由于需要对每?个阶段进行验证，瀑布模型要求每?个阶段都有明确的文档产出，对于严格的瀑布模型每?个阶段都不应该重叠,而应该是在评审通过，相关的产出物都己经基线后才能够进入到下?个阶段. 瀑布模型的优点仍然是可以保证整个软件产品较高的质量，保证缺陷能够捉前的被发现和解决. 采用瀑布模型可以保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性?但对于前期需求不明确,而又很难短时间明确淸楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目，需求设计和开发人员往往在项目开始后就会全部投入到项目中，而不是分阶段投入，因此采用瀑布模型会导致项目人力资源过多的闲置的情况,这也是必须要考虑的问题. 很多人往往会以进度约束而不选择瀑布模型，这往往是?个错误的观点.导致这种情况的?个关键因素往往是概念需求阶段人力不足.冈此在概念需求阶段人力能够得到充分保证的情况下，瀑布模型和迭代模型在开发周期上并不会存在太人的差别.反而是很多项目对于迭代或嫩捷模型用不好，为了赶进度在前期需求不明确，没有经过?个总体的架构设计情况下就开始编码，后期出现大量的返工而严重影响进度. 架构设计是软件开发中?个重要的关注点.因此在RUP中也捉及到软件开发要以架构为核心.因此在架构设计完成后系统会彼分为相关的f?系统和功能模块.每个功能模块间的接口都可以定义淸楚.在这种情况下，当模块B的详细设计做完成后往往就没有必妥等到其它模块的详细设计都妥完全作完才开始编码，冈此在架构设计完成后可以将系统分为多个模块并行开发，每个模块仍然遵循先设计和编码测试的瀑布模型思路.这是瀑布模型的?种最重要的改进思路，也可以说这是?种增量开发的模型.
软件生命周期模型选择及WBS分解指南 一、概述 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为“软件生命周期”。软件生命周期模型，通俗说就是，软件开发过程中所遵循的模式，即把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。 软件生命周期模型和项目开发过程有非常紧密关系，它是经过多次实践总结出来适合于不同项目使用的经典、有效的软件开发方法，它按照软件生命周期的各个阶段划分任务，依照一定的规则和步骤，有效地进行软件开发。 选用恰当的软件生命周期模型进行软件开发，可以提高产品质量；降低项目管理难度；缩短开发进度；便于项目状态跟踪；为过程改进和度量提供基线；改善组织级的过程弱势，提高过程能力成熟度级别。 为了便于分类汇总和统计各种生命周期模型的指标和数据，结合公司软件开发过程的实际，我们选择了常用的几种基本模型进行了描述，项目开发小组在进行项目策划时，可以根据模型的适用前提、优缺点和项目的实际需要进行选择，并在《项目实施计划》中，参加评审。 二、软件生命周期模型 常用的软件生命周期模型有：瀑布模型、迭代模型、增量模型、原型模型等。 以上所提到的件生命周期模型病不存在孰优孰劣的问题，每一种模型在实际工作中都有所应用。只要选择了最适合的，并按照此模型的流程来开发软件，都会取得成功。 需要强调的是，不管采用什么模型，项目实施中有四项活动是必不可少的——需求、设计、编码和测试。不管是有意识还是无意识，这些活动都会出现在项目过程中。这也是最重要的四项活动，其他的活动其实都是为这些活动服务的，不管是配置管理、风险管理，还是评审等等。 以下对各种常用的软件生命周期模型的设计思想、WBS划分（Work Breakdown Structure，即工作分解结构）、优缺点、使用范围进行分析。
第二章产品清洁生产 第一节生命生命周期评价的理念 生命周期评价的理念 生命周期评价 Life Cycle Assessment Life Cycle Analysis （一）定义 国际环境毒理学与化学学会（SETAC）：通过识别和量化能源和材料的消耗和废物的排放，评价产品(和服务)在其生命周期中的环境负荷，并提出预防和改进措施。 评价面向产品整个生命周期，包括原材料的获取和加工、生产、运输分配、使用、维护和再使用、循环再生、以及处理处置。 国际标准化组织(ISO)：生命周期评价是对一个产品系统的生命周期中的输入、输出及潜在环境影响进行的综合评价。 美国环保局(EPA)：通过对特定产品、过程或服务的整个生命周期的分析，对产品或活动进行整体评价的概念或方法。 生命周期评价包括三个组成部分－清单、影响和改进，是一个交互式发展的程序。 Procter & Gamble公司：显示产品制造商对其产品从设计到处置全过程中造成的环境负荷承担责任的态度，是保证环境确实而不是虚假地得到改善的定量方法。 美国3M公司：在从制造到加工、处理乃至最终作为残留有害废物处置的全过程中，检查如何减少或消除废物的方法。 （二）特点 全过程化 定量化 体现环境保护手段由简单、局部、粗放向复杂、全面、精细方向发展的趋势。 （三）分类 概念型LCA：定性的清单分析评估环境影响，不宜作为公众传播和市场促销的依据，但可以帮助决策人员认识哪些产品在环境影响方面具有竞争和优势。 简化型或速成型LCA：涉及全部生命周期，但仅限于简化的评价，着重主要的环境因素、潜在环境影响等，多用于内部评估和不要求提供正式报告的场合。 详细型LCA：包括目的和范围确定、清单分析、影响评价、结果解释4个阶段。 （四）生命周期评价的发展 生命周期评价是20世纪70年代初至90年代发展起来的理论。当前生命周期评价已形成了基本的概念框架和技术框架。 国际标准化组织（ISO）-负责生命周期评价理论的完善和方法的国际标准化工作。 1、起源 生命周期评价起源于20世纪60年代末70年代初美国开展的一系列针对包装品的分析、评价，当时称为资源与环境状况分析（REPA）。 标志：1969年美国中西部资源研究所(MRI)开展的可口可乐饮料包装瓶评价。 起源阶段的特征： (1)由工业企业发起，秘密进行，研究结果作为企业内部产品开发与管理的决策支持工具。--可口可乐玻璃瓶转向塑料瓶。《SCIENCE》发表文章（1976年4月）。 (2)大多数研究的对象是产品包装品。 (3)采用能源分析方法。由于能源分析方法在当时已比较成熟，而且很多与产品有关的污染物排放显然与能源利用有关。 2、发展 随着20世纪70年代末到80年代中期出现的全球性固体废弃物问题，资源与环境状况分析法(REPA)逐渐成为一种资源分析工具。 这时期的REPA着重于计算固体废弃物产生量和原材料消耗量。 发展阶段的特征： (1)政府积极支持和参与。欧洲经济合作委员会开始关注生命周期评价，要求工业企业对其产品生产过程中的能源、资源以及固体废弃物排放进行全面的监测与分析。(2)案例发展缓慢，方法论研究兴起。REPA缺乏统一的研究方法论，分析所需的数据常常无法得到，对不同的产品采取不同的分析步骤，同类产品的评价程序和数据也不统一。这些都促进对评价方法的研究。 3、趋于成熟 80年代末以后，区域性与全球性环境问题日益严重，可持续发展思想的普及以及可持续行动计划的兴起，促使大量的REPA研究重新开始。 REPA涉及研究机构、管理部门、工业企业、产品消费者，但是使用REPA的目的和侧重点各不相同，所分析的产品和系统也变得越来越复杂，急需对REPA的方法进一步研究和统一。 1989年荷兰“国家居住、规划与环境部（VROM）”针对传统的“末端控制”环境政策，首次提出了制订面向产品的环境政策。提出了要对产品整个生命周期内的所有环境影响进行评价；同时也提出了要对生命周期评价的基本方法和数据进行标准化。 1990年“国际环境毒理学与化学学会(SETAC)”首次主持召开有关生命周期评价的国际研讨会，首次提出了“生命周期评价”的概念。在以后的几年里，SETAC主持和召开了多次学术研讨会，对生命周期评价理论与方法进行了广泛研究。 1993年SETAC根据在葡萄牙的一次学术会议的主要结论，出版了一本纲领性报告：“LCA纲要：实用指南”。该报告为生命周期评价方法提供了一个基本技术框架，成为生命周期评价研究出现飞跃的一个里程碑。 目前生命周期评价在方法论上还不十分成熟。SETAC和ISO 积极促进生命周期评价方法论的国际标准化研究。 ISO14040标准《生命周期评价-原则与框架》已于1997年颁布，该标准体系目的是对生命周期评价的概念、技术框架及实施步骤进行标准化。 欧洲、美国、日本等国家和地区制定了一些促进LCA的政策和法规，如“生态标志计划”、“生态管理与审计法规”、“包装及包装废物管理准则”等。因此，这一阶段出现了大量LCA案例，如日本已完成数十种产品的LCA，丹麦用3年时间对10种产品类型进行了LCA等。 1996年，第一份专门关注生命周期评价的学术期刊《International Journal of Life Cycle Assessment》
编码：SHZIM-O-OPD-P02 xxxx技术股份有限公司 生命周期模型选用指南
更改控制页
目录 1目的 (1) 2范围 (1) 3模型介绍 (1) 3.1瀑布模型 (1) 3.1.1模型说明 (1) 3.1.2模型分析 (1) 3.2迭代模型 (2) 3.2.1模型说明 (2) 3.2.2模型分析 (3) 3.3快速原型模型 (3) 3.3.1模型说明 (3) 3.3.2模型分析 (4) 3.4精简模型 (4) 3.4.1模型说明 (4) 3.4.2模型分析 (5) 3.5V模型 (6) 3.5.1模型说明 (6) 3.5.2模型分析 (6) 4模型选择 (8) 4.1模型选择原则 (8) 4.2项目分类 (8) 4.3模型选择指南 (9)
1目的 描述适合公司现状、可供项目选择的组织级生命周期模型。 2范围 公司所有软件项目。 3模型介绍 3.1瀑布模型 3.1.1模型说明 图1 瀑布模型 对于需求比较明确的项目，可以使用瀑布模型进行项目开发，每个阶段的输入都是依靠上一个阶段的输出，每个阶段内都需要完成与最终产品相关的所有工作。 3.1.2模型分析 优点：
1.可以明确划分项目的各个阶段，便于管理； 2.项目成员只需要在被安排的阶段开展项目工作，不需要全程参与； 3.阶段工作内容清晰，降低了开发难度。 缺点： 1.对项目的启动条件要求较高； 2.若出现需求不明确或设计开发技术瓶颈，将会影响后续阶段的工作启动； 3.最终产品提交给用户确认的时间比较晚，存在一定的风险。 3.1.3模型参照 参见《瀑布模型》。 3.2迭代模型 3.2.1模型说明 图2 迭代模型 通常有许多项目不能在需求开发阶段提供准确的需求，对于这样的项目，可以选择迭代开发模型，将能够确定的需求分析确定下来。之后便可以对这部分确定的需求进行系统设计、编码和测试。整个项目可以进行多次迭代的过程，一般情况下迭代的起点从需求开发开始，然后进行设计、编码和测试，但是有时候也可能出现从设计或编码阶段安排新的迭代过程。
XXX有限公司 生命周期模型描述
目录 1简介 ....................................................................................................................................................................... I 目的 ........................................................................................................................................................................... I 适用范围 ................................................................................................................................................................... I 术语表 ....................................................................................................................................................................... I 2过程概述 ............................................................................................................................................................. II 3生命周期模型描述 ............................................................................................................................................. II 3.1V字模型............................................................................................................................................................ II 3.1.1概述 ............................................................................................................................................................ II 3.1.2阶段定义 ................................................................................................................................................... III 3.1.3适用情况 ................................................................................................................................................... III 3.1.4优点 ........................................................................................................................................................... IV 3.1.5缺点 ........................................................................................................................................................... IV 3.1.6本企业适合项目类型 ............................................................................................................................... IV 3.2中等简化V字模型.......................................................................................................................................... I V 3.2.1概述 ........................................................................................................................................................... IV 3.2.2阶段定义 ..................................................................................................................................................... V 3.2.3适用情况 ..................................................................................................................................................... V 3.2.4优点 ............................................................................................................................................................. V 3.2.5缺点 ............................................................................................................................................................. V 3.2.6本企业适合项目类型 ................................................................................................................................. V 3.3最简化V字模型............................................................................................................................................... V 3.3.1概述 ............................................................................................................................................................. V 3.3.2阶段定义 ................................................................................................................................................... VI 3.3.3适用情况 ................................................................................................................................................... VI 3.3.4优点 ........................................................................................................................................................... VI 3.3.5缺点 .......................................................................................................................................................... VII 3.3.6本企业适合项目类型 .............................................................................................................................. VII 3.4瀑布模型 ......................................................................................................................................................... V II
1 生命周期评价方法的概念和起源 生命周期评价(LCA)是一种评价产品、工艺或活动，从原材料采集，到产品生产、运输、销售、使用、回用、维护和最终处置整个生命周期阶段有关的环境负荷的过程。它首先辨识和量化整个生命周期阶段中能量和物质的消耗以及环境释放，然后评价这些消耗和释放对环境的影响，最后辨识和评价减少这些影响的机会。 生命周期评价(LCA)最早出现于二十世纪60年代末、70年代初，当时被称为资源与环境状况分析(REPA)。作为生命周期评价研究开始的标志是1969年由美国中西部资源研究所针对可口可乐公司的饮料包装瓶进行的评价研究，该研究使可口可乐公司抛弃了过去长期使用的玻璃瓶，转而采用塑料瓶包装。随后，美国ILLIN0IS大学、富兰克林研究会、斯坦福大学的生态学居研究所以及欧洲、日本的一些研究机构也相继开展了一系列针对其它包装品的类似研究。这一时期的工作主要由工业企业发起，研究结果作为企业内部产品开发与管理的决策支持工具。1990年由国际环境毒理学与化学学会(S ETAC)首次主持召开了有关生命周期评价的国际研讨会，在该次会议上首次提出了生命周期评价(Life Cycle Assessment，LCA)的概念。在以后的几年里，SETAC又主持和召开了多次学术研讨会，对生命周期评价（LCA)从理论与方法上进行了广泛的研究，对生命周期评价的方法论发展作出了重要贡献。1993年SETAC根据在葡萄牙的一次学术会议的主要结论，出版了一本纲领性报告“生命周期评价(LCA)纲要：实用指南”。该报告为LCA方法提供了一个基本技术框架，成为生命周期评价方法论研究起步的一个里程碑。 2 生命周期评价方法的主要内容 1993年SETAC在“生命周期评价纲要：实用指南”中将生命周期评价的基本结构归纳为四个有机联系的部分：定义目标与确定范围、清单分析、影响评价和改善评价，如图1所示。
软件生命周期模型 .软件生命周期对于一个软件的研制，从问题的提出，经过开发、使用、维护、修订，直到最后终止使用而被另一软件所取代，就像是一个生命体从孕育、出生、成长到最后消亡，软件的这个状态变化的过程称为生命周期(life cycle)。软件生命周期的演化具有阶段性，依据一定的原则，可以把软件生命 周期划分为若干不同阶段，相邻的阶段既相互区别又相互联系，每个阶段都以 其前一阶段的工作成果作为本阶段工作的基础。软件生命周期的划分有助于软 件开发和管理人员根据不同阶段的特点进行软件开发及其管理。软件开发的经 验表明，软件开发越到后期，改正前期开发工作的失误越困难，因此在软件开 发工作中应该对软件开发工作的阶段性给予充分认识，在前期工作不无分的前 提下不应过早地进入软件开发的下一阶段。依据不同的原则对软件生命周期的 划分也不同，《软件工程国家标准--计算机软件开发规范》(GB8566-88)中将软件生命周期划分为8个阶段：可行性研究与计划、需求分析、概要设计、详细 设计、实现(包括单元测试)、组装测试(集成测试)、确认测试、使用和维护。 本书按照人们所习惯的粗分方法把上面8个阶段划分为计划、开发和维护3个 阶段，在概述其他两个阶段的基础上重点介绍软件的开发过程。2.软件开发方 法在规定的投资规模和时间限制内，实现符合用户需求的高质量软件是软件开 发的目标，为实现这一目标，人们根据软件开发的特点，提出了多种软件开发 策略。通过不同的软件开发模型阐明从问题提出到最终软件实现，软件开发工 作过程的阶段性任务分解，并规定了每一个阶段的目标、任务以及工作结果的 表达形式。常见的软件设计模型有：瀑布模型(waterfall model)、渐进模型(increamental model)、演化模型(evolutionary model)、螺旋模型(spiral model)、喷泉模型(fountain model)、智能模型(intelligent model)等。这里介绍其中的3种。(1)瀑市模型瀑市模型1970年由W.Royce提出，其开发过程 依照固定顺序进行，各阶段的任务与工作结果如图1所示。该模型严格规定各 阶段的任务，上一阶段任务输出作为下一阶段工作输入。此模型适合于用户需 求明确、开发技术比较成熟、工程管理严格的场合使用，其缺点是：由于任务 顺序固定，软件研制周期长，前一阶段工作中造成的差错越到后期越大，而且 纠正前期错误的代价高。图1瀑布型开发过程(2)渐进模型从一组简单的基本用户需求出发，首先建立一个满足基本要求的原型系统。通过测试和运行原型系
生命周期模型及选择指南 Version 1.1 文档名称：ZD-MMI-Guidelines-生命周期及模型选择指南-V1.1
修订历史记录
目录 1 目的和范围 (1) 2 生命周期可选模型简介 (1) 2.1 瀑布模型 (1) 2.1.1 标准瀑布模型 (1) 2.1.2 V模型 (3) 2.1.3 中等简化V字模型（V4模型） (5) 2.1.4 最简化V字模型（V3模型） (6) 2.2 原型模型 (8) 2.2.1 原型模型的形式 (8) 2.2.2 特点 (8) 2.2.3 缺点 (9) 2.2.4 适用项目 (9) 2.2.5 阶段划分 (9) 2.3 螺旋模型 (10) 2.3.1 特点 (10) 2.3.2 适用项目 (11) 2.3.3 阶段划分 (11) 2.4 增量模型 (11) 2.4.1 特点 (12) 2.4.2 适用项目 (12) 2.4.3 阶段划分 (12) 2.5 迭代模型 (13) 2.5.1 特点 (14) 2.5.2 适用情况 (15) 2.5.3 迭代分类 (15)
3 生命周期模型选择指南 (16) 3.1 生命周期模型选择特性指标 (16) 3.1.1 需求清晰性、完整性、稳定性 (16) 3.1.2 项目规模 (16) 3.1.3 项目类型 (17) 3.1.4 技术复杂度 (17) 3.1.5 可重用性 (18) 3.1.6 重用已有产品 (18) 3.2 生命周期模型选择决策参考 (18) 3.3 生命周期模型与特性指标对应关系 (19) 3.4 生命周期选择 (20) 附录：标准项目生命周期图 (21)
在CMMI的各种构件中，只有目标是必需的，实践是期望的，子实践是解释说明的。所以首先要满足模型里每个目标的要求，目标的达成是根据实践的执行情况来判断的，模型里给出的实践是可以替换的。只要能达成目标，采用什么实践都是可以的。 静态测试是相对于动态测试而言的，静态测试是不动态执行程序代码而寻找程序中可能存在的错误或评估程序的过程。相对于动态测试而言，静态测试成本更低，效率更高。因为静态测试可以在软件开发生命周期的早期就发现缺陷和问题，从而减少返工的成本。 对过程改进的一大疑虑是担心丧失灵活性。反对过程改进的人，总是拿“活学活用”当作挡箭牌，其实这几个字应该有次序的，即先学、后用、再活。 过程改进的目标是寻求制度和灵活的恰当平衡，其中制度乃是灵活之本。 丹明（Deming）：“质量由满足需求的能力组成。” 左兰（Juran）：“质量就是适于使用。” 克罗斯比（Ceosby）：“质量意味着符合基于用户需要而制定出来的要求。” 关于选择生命周期模型的最后的总结 1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型. 2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型. 3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型 4.在需求不稳定情况下尽量采用增量迭代模型 5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布 6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型 7.对于全新系统的开发必须在总体设计完成后再开始增量或并行. 8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型. 9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则.
5种项目生命周期模型 1.项目生命周期定义 2.一个完整的项目生命周期一般分为：计划、需求分析、设计、编码、测试、发布、实施以及运行维护阶段。 参见下图标准过程： 3.软件过程模型是从项目需求定义直至经使用后废弃为止，跨越整个生存期的系统开发、运营维护所经历的全部过程、活动和任务的结构框架。 4.软件过程模型一般分为：瀑布模型、原型模型、螺旋模型、增量模型。 5. 5种项目生命周期模型 a.瀑布模型： 1) 特点 l 阶段间具有顺序性和依赖性：必须等前一阶段的工作完成之后，才能开始后一阶段的输入。对本阶段工作进行评审，若得到确认，则继续下阶段工作，否则返回前一阶段，甚至更前阶段。只有前一阶段输出正确，后一阶段才能正确。 l 推迟实现的观点：在编码之前，设置了需求分析与设计的各个阶段，分析与设计阶段的根本任务规定在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。 l 质量保证的观点： 每个阶段都坚持两个做法： 规定文档，没有文档就没有完成该段任务。 每个阶段结束前都要对完成的文档进行评审，以便尽早发现问题，改正错误。 2) 缺点 l 依赖于早期进行的唯一的一次需求调查，不能适应需求的变化； l 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； l 风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。 3) 适用项目
l 需求清晰明了且时间要求宽松的软件开发项目； l 规模小，需求简单，功能单一的项目 4) 阶段划分 计划阶段 需求阶段 设计阶段 编码阶段 测试阶段 发布阶段 实施阶段 运行维护阶段 b.原型模型： 原型模型快速建立起来的可以在计算机上运行的程序，他所能完成的功能往往是最终产品能完成的功能的一个子集。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品，这个产品只实现部分功能。原型最重要的是为了确定用户的真正需求。 原型模型在克服瀑布模型缺点、减少由于软件需求不明确给开发工作带来风险方面，确有显著效果。软件系统的原型常用有以下形式： 抛弃型：开发原型为了获取需求，在原型开发之后，已获取了更为清晰的需求信息，原型无需保留而废弃； 渐进型：原型作为软件最终产品的一部分，可满足用户的部分需求，进一步在此基础上开发，则可增加需求，实现后再交付使用； 1) 特点 l 用户需求不完全或不确定；
软件生命周期模型优缺点 瀑布模型把每个阶段当成瀑布中的一个阶梯，强调由上而下，互相衔接、逐级下落， 固定次序。 优点：开发阶段清晰，便于评审、审计、跟踪、管理和控制 缺点：不可逆或很难可逆 问题会积累，错误会传递发散扩大，导致成本和质量失控 快速原型模型（原型模型）快速原型模型的第一步是快速建立一个能反映用 户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。 优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险 缺点：所选用的开发技术和工具不一定符合主流的发展，快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。 增量模型增量模型也称为渐增模型。增量模型融合了瀑布模型的基本成分和原型实 现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性系列产生软件的一个可发布的增量。 优点：人员分配灵活，开始不用投入大量的人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。增量能够有计划的管理技术风险。 缺点：由于各个构件是逐渐并入已有的软件体系结构中，所以加入构件必须不破坏以构好的的系统部分，这需要软件具备开放式的体系结构。 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改的模型，从而使软件过程的控制失去整体性。 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。 螺旋模型螺旋模型采用一种周期性的方法来进行系统开发。 优点：设计上的灵活，可以在项目的各个阶段进行变更。 以小的分段来构建大型系统，使成本计算变得简单容易。 客户始终参与每个阶段的开发，保证了项目部偏离正确方向以及项目的可控性。 缺点：建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。 喷泉模型喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对 象技术的软件开发项目。 优点：需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。 缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
软件生命周期 软件生命周期规定了一个项目软件开发的过程框架，包括：1、项目的阶段划分；2、各个过程域的活动在阶段内的配置（即阶段内所需完成的活动）；3、阶段产出物及其状态。 软件生命周期模型是组织定义的标准软件生命周期，各项目在实施的过程中可以选择最适合本项目情况的模型并在此基础上依据项目特点进行裁剪，定义项目的生命周期过程。 目前已定义的生命周期模型包括： ?瀑布模型 ?迭代模型 瀑布型生命周期模型 1.简介 瀑布型生命周期模型是一种严格按照需求->设计->实施->交付四个阶段进行软件开发的模型，并且在各个阶段结束时要经过严格的评审，只有当能够确认一个阶段的开发成果是正确的时才能够进行下一阶段的开发。 在瀑布模型的四个阶段中，除了分别完成其本阶段所定义的活动之外，都必须进行项目管理、质量保证、配置管理和测试活动，这四个活动的过程贯穿整个瀑布型软件生命周期。 2.结构
3.阶段 3.1需求阶段 3.1.1目标 需求阶段的目标是为了确保与客户在系统的工作内容和范围（即系统“要做什么”和“不做
什么”）方面达成一致，并建立需求的基线，为项目开发计划的进一步细化提供基础。 3.1.2主要活动 需求阶段的主要活动包括： ?需求获取：搜集客户的需要、期望、约束和接口，分析业务特性，形成用户需 求 ?需求分析：对所有候选的需求进行分析，形成软件的功能需求，并排列优先级 ?需求评审：客户（或客户的代表）、高级经理和项目组共同评审需求文档，并 达成一致意见 ?建立需求基线 ?定义系统的用户界面 ?完成系统测试计划 ?调整和细化对项目规模、工作量、成本的估计 ?根据收集的需求重新分析和评估项目的风险，并制定相应的规避和缓减策略 ?完成WBS（Work Breakdown Structrue，工作分解结构），写入SDS，并 细化设计阶段的SDS ?完成设计阶段的SQAP 3.1.3产出物 需求阶段的产出物包括（灰色部分为演进的产出物，白色部分为新增产出物）：
目录 1。项目的 (2) 2。范围 (2) 3。义务 (2) 4。工作程序 (2) 4。1个公司定义的软件生命周期模型 (2) 4。2软件学生救期间模型的选择标准 (2) 4.2.1瀑布模型选择标准 (2) 4.2.2增量模型选择标准 (2) 4.2.3快速原型选择标准 (3) 4.3软件生命周期模型 (3) 4.3.1瀑布模型 (3) 4.3.2增量模型 (4) 4.3.3快速原型制作模型 (4) 4.4各个阶段的任务，活动，工作产品和质量控制 (6) 4.4.1标准 (6) 4.5软件生命周期定制指南 (8) 4.5.1裁缝指南 (8) 5，参考 (9)
1。目的 指导项目团队在制定项目开发计划的阶段选择适合项目特征的生命周期，并能够按照软件生命周期定义的工作流程进行工作。 2.面积 此过程适用于新开发的软件项目。 3.责任 软件项目经理负责根据项目的特征选择适当的生命周期。 4.工作程序 4.1公司定义的软件生命周期模型 软件生命周期的定义可能会有所不同，具体取决于软件项目特征的标识和所选的软件开发模型。公司计划推荐的软件生命周期模型如下： 1.瀑布模型 2.增量模型 3.快速原型模型 4.2软件学生救期间模型的选择标准 定义适用的软件生命周期是软件项目计划的基本点，也是标准化项目管理的重要手段。因此，在定义项目的软件生命周期时，应首先根据每个项目的特征和选择标准从此规范中选择合适的软件生命周期模型，然后定制适用于该项目的软件生命周期定义。。 4.2.1瀑布模型选择标准 1.用户一开始就给出了明确的需求，并且需求在开发过程中没有改变或很少改变； 2.分析设计人员熟悉应用领域； 3.低风险项目（熟悉目标和发展环境）； 4.用户应用环境稳定； 5.用户除要求外很少参与开发工作； 6.用户接受该程序的运行版本只能在项目的后期开发阶段获得。 4.2.2增量模型选择标准 1、在整个项目开发过程中，用户需求可能会发生变化； 2、客户分阶段接受交货； 3.分析设计人员对应用领域不熟悉或难以完全掌握； 4.中或高风险项目（太紧的项目，可以分阶段提交，或者不熟悉系统目标和开发环境的项 目）； 5.用户需要参与整个软件开发过程； 6.使用面向对象的语言或第四代语言。
刘小备如何做项目－关于生命周期模型 2009-04-18 03:38:57| 分类：程序文摘| 标签：|字号大中小订阅 关键字: 软件工程生命周期模型 摘自：这里 文章不错，至少是从理论的角度，用通俗的语言讲述了软件工程木常见的“原型法、编码-修改法、传统瀑布、改进瀑布、增量、螺旋、RUP、XP”等软件过程。值得学习！ 进行完软件估计后，刘小备开始启动下一阶段的工作选择软件生命周期，可供软件生命周期模型这么多，有原型法、编码-修改法、传统瀑布、改进瀑布、增量、螺旋、RUP、XP，还有什么“V”模型、“W” 模型，到底选择哪一种呢？刘小备想起来头大，索性就不想了，直接去找昔日故交孔小明，如今的孔小明已经是“孔氏项目管理咨询有限公司”的总经理，毕竟有前些年大大小小几十个项目的丰富经历，再加上孔小名扎实的软件开发理论功底，经过孔小明咨询的项目都取得了成功，虽然公司只有十几个人，“孔氏项目管理咨询有限公司”在业界也小有名气了，孔小明早就把他的羽毛扇送到博物馆去了，不离手的是有蓝牙/WLAN/GSM/GPRS/WCDMA的多模智能手机，代步的两轮车也换成了“奔驰2008”。刘小备到“孔氏项目管理咨询有限公司”时，正赶上孔小明给一家叫什么“新盛”的系统集成公司新接的一个千万级的项目做咨询结束，对方的公司老总握着孔小明的手不放，技术总监和项目经理也一脸崇拜的看着孔小明，孔小明很客气的把他们送走，然后转身把刘小备请进办公室。还没坐下刘小备就直奔主题（以下是两个人的对话，刘小备用刘代替，孔小明用孔代替） 刘：孔总，虽然我也做过几个项目，但对于生命周期模型一直也没有搞清楚孰优孰劣，所以在选择时往往是跟着感觉走，今天来就是想把这个问题彻底弄清楚，一劳永逸。 孔：在讲各种生命周期模型前，我想强调一下，任何项目，不管采用什么模型有四项活动都是必不可少的。不管是有意识还是无意识，这些活动都会出现在项目过程中。 刘：哪四项活动？ 孔：就是需求、设计、编码和测试。这也是最重要的四项活动，其他的活动其实都是为这些活动服务的，不管是配置管理、还是风险管理、还是评审等等。 刘：哦！这个问题没有考虑过，不过你说出来再一想确实是这么回事。 孔：生命周期的定义咱们就不讨论了，我直接就常用的模型的优缺点和使用条件进行说明。 刘：太好了！ 孔：我先说第一种：编码-修改模型。也称Code And Fix方法，是历史最悠久一种模型，从人类开始写程序的第一天这种模型就出现了，我们每个人开始学写程序时也不自觉的采用了这种模型。 刘：这个我知道了。这种模型没有规划、没有控制、开发过程混乱，软件质量完全依靠程序员个人的能力，后期基本不能维护，尤其是有人员变动，这应该是造成上世纪70年代软件危机的主要根源。 孔：即便在现在，这种模型也很有市场的，很多的中小型公司采用的仍然是这种开发模型。 刘：那是不是说，这个模型应该彻底的抛弃？ 孔：那到不尽然。毕竟个人在开始学习编程时，这种方法是一个很好的选择，即使对于企业也不是完全不可取，比如有些项目对质量要求不高，但需要把东西攒起来，否则就丢单，这时如果在四平八稳的好好的规划和设计，那么到时候“黄瓜菜都凉了”。
实验一比较4种生命周期模型优缺点 一、实验目的与要求 比较4种生命周期模型优缺点及适用背景 二、实验内容 分析每一种生命周期模型优缺点、利用Internet搜索相关软件项目所使用生命周期模型并分析特点，从而更进一步的了解各生命周期模型的适用背景 1.瀑布模型： 背景：在20实际80年代之前，瀑布模型一直被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。 特点： A.阶段间具有顺序性和依赖性：必须等前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。 B.推迟实现的观点：瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这个两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要指导思想。 C.质量保证的观点：软件工程的基本目标是优质、高产。瀑布模型的每个阶段都应坚持两个重要做法： a.每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准 确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维 护的重要依据。 b．每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。 总之，瀑布模型胡完全依赖于书面的规格说明。 D．可强迫开发人员采用规范的方法；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。 缺点： A.各个阶段产生的文档时维护软件产品时必不可少的，没有文档的软件几乎是不可能 维护的。 B.瀑布模型是由文档驱动的，在可运行的软件产品交付给用户之前，用户只能通过文 档来了解产品是什么样的。 C.由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品 不能真正满足用户的需要。 2.快速原型模型 背景：快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型模型的第一步是快速建立一个能反馈用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……一旦用户认为这个圆形系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件便可以满足用户的真实需求。 特点：