chap2-软件生存期

软件生命周期模型

瀑布模型/改进的瀑布模型 虽然瀑布模型仍然存在很多的问题有待解决，但瀑布模型仍然是最展本的和最效的?种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求-〉分析-〉设计?〉编码-> 测试的阶段进行，每-个阶段都可以定义明确的产出物和验证准则.瀑布模型在每?个阶段完成后都可以组织相关的评审和验证，只有在评审通过后才能够进入到下-个阶段. 由于需要对每?个阶段进行验证，瀑布模型要求每?个阶段都有明确的文档产出，对于严格的瀑布模型每?个阶段都不应该重叠,而应该是在评审通过，相关的产出物都己经基线后才能够进入到下?个阶段. 瀑布模型的优点仍然是可以保证整个软件产品较高的质量，保证缺陷能够捉前的被发现和解决. 采用瀑布模型可以保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性?但对于前期需求不明确,而又很难短时间明确淸楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目，需求设计和开发人员往往在项目开始后就会全部投入到项目中，而不是分阶段投入，因此采用瀑布模型会导致项目人力资源过多的闲置的情况,这也是必须要考虑的问题. 很多人往往会以进度约束而不选择瀑布模型，这往往是?个错误的观点.导致这种情况的?个关键因素往往是概念需求阶段人力不足.冈此在概念需求阶段人力能够得到充分保证的情况下，瀑布模型和迭代模型在开发周期上并不会存在太人的差别.反而是很多项目对于迭代或嫩捷模型用不好，为了赶进度在前期需求不明确，没有经过?个总体的架构设计情况下就开始编码，后期出现大量的返工而严重影响进度. 架构设计是软件开发中?个重要的关注点.因此在RUP中也捉及到软件开发要以架构为核心.因此在架构设计完成后系统会彼分为相关的f?系统和功能模块.每个功能模块间的接口都可以定义淸楚.在这种情况下，当模块B的详细设计做完成后往往就没有必妥等到其它模块的详细设计都妥完全作完才开始编码，冈此在架构设计完成后可以将系统分为多个模块并行开发，每个模块仍然遵循先设计和编码测试的瀑布模型思路.这是瀑布模型的?种最重要的改进思路，也可以说这是?种增量开发的模型.

软件生命周期模型

软件生命周期模型 .软件生命周期对于一个软件的研制，从问题的提出，经过开发、使用、维护、修订，直到最后终止使用而被另一软件所取代，就像是一个生命体从孕育、出生、成长到最后消亡，软件的这个状态变化的过程称为生命周期(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)渐进模型从一组简单的基本用户需求出发，首先建立一个满足基本要求的原型系统。通过测试和运行原型系

软件项目管理生存期模型实例

合同登记编号： 生存期模型选择 项目名称：西安财经学院实验室管理系统 委托人（甲方）：西安财经学院 研究开发人（乙方）：赵哲 签订地点：西安市 签订时间：2012年1月1日 有效期限：2012年1月1日至2012年5月20日 西安市技术市场管理办公室

针对本项目的开发特点，参考企业的生存期模型说明和软件过程体系，决定采用增量式模型如图1所示： 理由如下： 1）西安财经学院实验室管理系统的全部功能分成通用功能和日常业务管理功能两大类，因此可以先基于通用功能做出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。 2）在西安财经学院实验室管理系统需求中，要求系统具有可扩充性。若使用增量模型，可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性，直至产生最终完善的产品。 3）“系统要求有可扩充性，可以再现有系统的基础上，可以在前台加挂其他功能模块”----也说明用户可能会增加新的需求。 4）应该从最基础的应用做起，逐步扩充其应用，所以选用增量模型来西安财经学院实验室管理系统系统。 5）本项目具备增量式模型的其他特点： ● 项目复杂程度为中等； ● 预计开发软件的成本为中等； ● 产品和文档的再使用率会很高； ● 项目风险较低。 生存期中各阶段的定义如下： 项目规划阶段 阶段目标：根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。 项目规划 需求分析 设计 增量 1 增量 2 增量 3 增 量 4 增量 5 系统测试 产品提交

GBT 8566-2007 信息技术 软件生存周期过程

考试国标知识点（二）：GB/T 8566-2007 信息技术软件生存周期过程 本标准为软件生存周期过程建立了一个公共框架，以供软件产业界使用，它包括在含有软件的系统、独立软件产品和软件服务的获取期间以及在软件产品的供应、运行和维护期间需应用的过程、活动和任务。软件包括软固件的软件部分。 本标准了描述了软件生存周期过程的体系结构，但并未规定如何实施或执行各过程中包含的活动和任务的细节。 本标准并不打算规定要产生的文档的名称、格式或编写内容。 本标准并不规定一个特定的生存周期模型或软件开发方法。 术语： 协定：确定将要建立的工作关系的期限和条件。 审核：由授权人员对软件产品和过程进行的独立评估，以便评估与需求的依从性。 评价：系统地确定一个实体项目满足其规定准则的程度 固件：硬件装置和作为只读软件驻留在硬件装置中的计算机指令或计算机数据的组合，该软件不能在程序控制下方便地修改。 合格性认定：证实一个实体是否能够完成规定需求的过程 合格性需求：为了证明一个软件产品依从其规格说明且可以在其目标环境中使用，该软件产品必须满足的一组准则或条件。 合格性测试：由开发方进行并由需方见证的测试，以证明软件产品符

合其规格说明，并可以在其目标环境中使用。 确认：通过检查和提供客观证据来证实针对某一特定预期用途的需求已经得到满足 验证：通过检查和提供客观证据来证实规定需求已经得到满足。 验证：验证检查某样东西是否符合之前已定好的标准，如：文档评审，要检查的东西是文档，检查标准就是文档的评审标准，又如：测试软件，要检查的东西就是软件，检查的标准就是软件的规格说明，包括功能说明，性能要求等。 确认：检查软件在最终的运行环境上是否达到预期的目标。一般来说，就是调试、验收测试等，这些工作都是在真正的软件需要运行的环境上进行的，在最终环境上运行软件，确保软件符合使用要求。 其实确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。而验证更多的是从开发方的角度来做评审、测试来验证产品的需求、架构设计等方面是否和用户要求的一致 验证是代表你是否正确的做事情，而确认代表你是否做了正确的事情本标准把软件生存周期中可能执行的活动分为5个基本过程、9个支持过程和7个组织过程，每一生存周期过程划分为一组活动，每一活动进一步划分为任务 5个基本过程： 1、获取过程：为需方而定义的活动，启动，招标，合同，对供方监督，验收等 2、供应过程：为供方而定义的活动，启动，准备投标，签订合同，

数据库设计阶段和软件项目生命周期对比教学内容

数据库设计的基本步骤： 1.需求分析阶段： 准确了解与分析用户需求（包括数据与处理），是整个设计过程的基础，是最困难、最耗费时间的一步。这个不用多说吧？ 2.概念结构设计阶段： 是整个数据库设计的关键,通过对用户的需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。从实际到理论。 3.逻辑结构设计阶段： 将概念结构转换为某个DBMS所支持的数据模型,对其进行优化。优化理论。 4.数据库物理设计阶段： 为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。选择理论落脚点。 5.数据库实施阶段： 运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果,建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。理论应用于实践。 6.数据库运行和维护阶段： 数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。理论指导实践，反过来实践修正理论。

释：软件生存周期各个阶段活动定义_普通__行业透视_eNet硅谷动力商用软件 频道 首先讲一下软件生存周期的定义，即以需求为触发点，提出软件开发计划的那一刻开始直到软件在实际应用中完全报废为止可以认为是一个完整的软件生存周期，软件生存周期的提出是为了更好的管理、维护和升级软件。其中更大的意义在于管理软件开发的步骤和方法。它把整个的软件生存时间看作是一个整体，以时间的推移和软件开发的工作重心之间作为划分点，把软件开发和维护的工作细分为若干个相对独立的部份，从而更好的控制软件的开发进度和难度，同时也十分有利于降低软件的出错频律，协调各个部门间的工作配合和责任分配。 软件生存周期的各个阶段的划分并没有一成不变的法则，不同的开发方式、软件种类、软件规模和开发环境都会在不同程度上影响软件生存周期各阶段的划分，但无论最终把生存周期如果根据自己的实际情况进行划分，都是旨在更好的利用手中的资源（主要指人力资源、软件资源、技术资源和源码资源），降低软件的开发风险、复杂度和开发成本（主要以开发的时间和投入资源为衡量标准），要做到最好的对软件生存周期各阶段进行划分，就必须遵循一条基本的原则，那就是在各阶段的任务应尽可能的相对独立，同一阶段各项任务的性质应尽可能的相同，从而达到降低每个阶段任务的复杂度，减少不同阶段任务之间的联系。这样做对软件项目开发的组织管理是十分有必要的，同时对最终的软件项目开发成功是不可或缺的。 尽管软件的生存周期各阶段的划分没有一个明确的法则，但就一般性而言，软件生存周期包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编写代码、软件测试和软件维护等活动（有的文档资料和开发项目把概要设计和详细设计合在一起，统称为软件设计或设计），这些活动的每一个可以说是软件开发过程中必须要经历的，所以我们应该将它们按照项目的划分合理的安排到各个阶段里面去。 既然软件开发周期这么重要，无论对软件项目最终开发是否能取得成功或是对软件管理和资源投入，我们就应当充份的了解周期里各个活动的定义和任务，才能合理，准确，客观的安排每一阶段的工作，以下就对各种活动的定义和任务做一下

软件生存周期模型-瀑布模型

作业要求:除课件中介绍的几种软件生存周期模型，请详细介绍其他一种或几种生存周期模型，也可以是在实践开发过程中使用某种模型的心得体会，或者是针对某种模型的意见建议等。 1.瀑布模型 1.1.瀑布模型定义 瀑布模型也称“线性顺序模型”。瀑布模型规定了各项软件工程活动，包括：制定开发计划，进行需求分析和说明，软件设计，程序编码，测试及运行维护。并且规定了它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落。 由于需要对每一个阶段进行验证，瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠,而应该是在评审通过，相关的产出物都已经基线后才能够进入到下一个阶段。 1.2.瀑布模型特点： 瀑布模型提供了软件过程模型的基本模板。强调了每一阶段活动的严格顺序。 瀑布模型是一种整体开发模型，程序的物理实现集中在开发阶段的后期，用户在最后才能看到自己的产品。

瀑布模型的优点是可以保证整个软件产品较高的质量,保证缺陷能够提前的被发现和解决。采用瀑布模型可以保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性。 瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。 缺点就是不够灵活。但对于前期需求不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目,需求设计和开发人员往往在项目开始后就会全部投入到项目中,而不是分阶段投入,因此采用瀑布模型会导致项目人力资源过多的闲置的情况,这也是必须要考虑的问题。 1.3.使用心得 虽然瀑布模型存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段进行,每一个阶段都可以定义明确的产出物和验证准则.瀑布模型在每一个阶段完成后都可以组织相关的评审和验证,只有在评审通过后才能够进入到下一个阶段。 很多人往往会以进度约束而不选择瀑布模型,这往往是一个错误的观点.导致这种情况的一个关键因素往往是概念需求阶段人力不足.因此在概念需求阶段人力能够得到充分保证的情况下,瀑布模型和迭代模型在开发周期上并不会存在太大的差别.反而是很多项目对于迭代或敏捷模型用不好,为了赶进度在前期需求不明确,没有经过一个总体的架构设计情况下就开始编码,后期出现大量的返工而严重影响进度. 架构设计是软件开发中一个重要的关注点.因此在RUP中也提及到软件开发要以架构为核心.因此在架构设计完成后系统会被分为相关的子系统和功能模块.每个功能模块间的接口都可以定义清楚.在这种情况下,当模块B的详细设计做完成后往往就没有必要等到其它模块的详细设计都要完全作完才开始编码,因此在架构设计完成后可以将系统分为多个模块并行开发,每个模块仍然遵循先设计和编码测试的瀑布模型思路.这是瀑布模型的一种最重要的改进思路,也可以说这是一种增量开发的模型。图示如下：

校务通生存期模型案例

案例说明-《校务通管理系统》的生存期模型 针对本项目的开发特点，参考企业的生存期模型说明和软件过程体系，决定采用增量式模型如下图，理由如下： 1．校务通系统的全部功能分成通用功能和日常业务管理功能两大类，因此可以先基于通用功能作出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。 2．在校务通系统需求规格中，要求系统有可扩充性。若使用增量模型，可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。如：“关于教师档案，比照所提供资料设计，现在也没有一个成形的东西”；资源库系统只提到“应提供一个标准的资源库解决方案。”这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性。直至产生最终完善的产品。 3．“系统要求有可扩充性，可以在现有系统的基础上，通过前台就可加挂其它功能模块”。也说明用户可能会增加新的需求。 4．对一个管理方式已经比较成熟的学校，要完全舍弃原有的管理方式，用校务通系统替代全部管理，这是不实际的。所以，可以从最基础的做起，逐步扩充其应用，所以选用增量模型来开发校务通系统。 5．本项目具备增量式模型的其他特点 a)项目复杂程度为中等。 b)预计开发软件的成本为中等。 c)产品和文档的再使用率会很高, d)项目风险较低 图:项目生存期模型

生存期中的各阶段定义如下： 项目规划阶段 阶段目标：根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。 输入：合同文本 SOW 过程：项目规划，计划确认 输出：项目计划 需求分析阶段 阶段目标：确定客户的需求 输入：项目计划，SOW 过程：需求获取，需求分析，需求控制 输出：原型系统，需求规格 设计阶段 阶段目标：总体系统结构设计 输入：原型系统，需求规格 过程：总体设计 输出：系统设计说明书，数据库结构定义 增量1实现 阶段目标：实现系统的通用功能 输入：系统设计说明书 数据库结构定义 过程：详细设计,编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本－1 增量2实现 阶段目标：实现系统的招生管理功能 输入：系统设计说明书 数据库结构定义 过程：详细设计,编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本－2 增量3实现 阶段目标：实现系统的学生日常管理功能 输入：系统设计说明书 数据库结构定义 过程：详细设计,编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本－3 增量4实现 阶段目标：实现系统的教务管理功能 输入：系统设计说明书 数据库结构定义 过程：详细设计,编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本－4 增量5实现 阶段目标：实现系统的教师辅助功能 输入：系统设计说明书 数据库结构定义 过程：详细设计,编码，代码走查，代码评审，单元测试

5种项目生命周期模型

5种项目生命周期模型 1.项目生命周期定义 2.一个完整的项目生命周期一般分为：计划、需求分析、设计、编码、测试、发布、实施以及运行维护阶段。 参见下图标准过程： 3.软件过程模型是从项目需求定义直至经使用后废弃为止，跨越整个生存期的系统开发、运营维护所经历的全部过程、活动和任务的结构框架。 4.软件过程模型一般分为：瀑布模型、原型模型、螺旋模型、增量模型。 5. 5种项目生命周期模型 a.瀑布模型： 1) 特点 l 阶段间具有顺序性和依赖性：必须等前一阶段的工作完成之后，才能开始后一阶段的输入。对本阶段工作进行评审，若得到确认，则继续下阶段工作，否则返回前一阶段，甚至更前阶段。只有前一阶段输出正确，后一阶段才能正确。 l 推迟实现的观点：在编码之前，设置了需求分析与设计的各个阶段，分析与设计阶段的根本任务规定在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。 l 质量保证的观点： 每个阶段都坚持两个做法： 规定文档，没有文档就没有完成该段任务。 每个阶段结束前都要对完成的文档进行评审，以便尽早发现问题，改正错误。 2) 缺点 l 依赖于早期进行的唯一的一次需求调查，不能适应需求的变化； l 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； l 风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。 3) 适用项目

l 需求清晰明了且时间要求宽松的软件开发项目； l 规模小，需求简单，功能单一的项目 4) 阶段划分 计划阶段 需求阶段 设计阶段 编码阶段 测试阶段 发布阶段 实施阶段 运行维护阶段 b.原型模型： 原型模型快速建立起来的可以在计算机上运行的程序，他所能完成的功能往往是最终产品能完成的功能的一个子集。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品，这个产品只实现部分功能。原型最重要的是为了确定用户的真正需求。 原型模型在克服瀑布模型缺点、减少由于软件需求不明确给开发工作带来风险方面，确有显著效果。软件系统的原型常用有以下形式： 抛弃型：开发原型为了获取需求，在原型开发之后，已获取了更为清晰的需求信息，原型无需保留而废弃； 渐进型：原型作为软件最终产品的一部分，可满足用户的部分需求，进一步在此基础上开发，则可增加需求，实现后再交付使用； 1) 特点 l 用户需求不完全或不确定；

软件生命周期模型优缺点

软件生命周期模型优缺点 瀑布模型把每个阶段当成瀑布中的一个阶梯，强调由上而下，互相衔接、逐级下落， 固定次序。 优点：开发阶段清晰，便于评审、审计、跟踪、管理和控制 缺点：不可逆或很难可逆 问题会积累，错误会传递发散扩大，导致成本和质量失控 快速原型模型（原型模型）快速原型模型的第一步是快速建立一个能反映用 户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。 优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险 缺点：所选用的开发技术和工具不一定符合主流的发展，快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。 增量模型增量模型也称为渐增模型。增量模型融合了瀑布模型的基本成分和原型实 现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性系列产生软件的一个可发布的增量。 优点：人员分配灵活，开始不用投入大量的人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。增量能够有计划的管理技术风险。 缺点：由于各个构件是逐渐并入已有的软件体系结构中，所以加入构件必须不破坏以构好的的系统部分，这需要软件具备开放式的体系结构。 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改的模型，从而使软件过程的控制失去整体性。 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。 螺旋模型螺旋模型采用一种周期性的方法来进行系统开发。 优点：设计上的灵活，可以在项目的各个阶段进行变更。 以小的分段来构建大型系统，使成本计算变得简单容易。 客户始终参与每个阶段的开发，保证了项目部偏离正确方向以及项目的可控性。 缺点：建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。 喷泉模型喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对 象技术的软件开发项目。 优点：需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。 缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。

软件生命周期管理

软件生命周期(SDLC，Systems Development Life Cycle,SDLC)是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。 七个阶段 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期（软件生命周期）。 软件生命周期 把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。通常，软件生存周期包括可行性分析、项目启动、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动，可以将这些活动以适当的方式分配到不同的阶段去完成。 可行性分析

此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。 主要交付物有《项目规划书》、《立项报告》、《可行性研究报告》。项目启动 项目启动会、人员到位，初步分工、搭建开发环境、准备项目管理工具。 项目管理工具：可采用Project和JIRA结合管理。 Microsoft Project (或MSP)是一个国际上享有盛誉的通用的项目管理工具软件，凝集了许多成熟的项目管理现代理论和方法，可以帮助项目管理者实现时间、资源、成本的计划、控制。 JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。

软件项目生命周期模型

软件项目生命周期模型 当一个软件产品在没有规格说明或主要设计的情况下被开发时，开发者往往不得不重新对产品编码多次直到他们得到正确稳定的产品。这种开发模型就是编码-修 补模型。 开发者们首先开发出一个产品的最初版本给客户验收，然后开发团队开发一个新的版本再次给客户验收。这个过程一直持续到客户感觉产品满意为止。 这种开发模型有几个缺点。最重要的缺点是存在于需求，设计和实现中的错误要到整个产品被构建出来后才能被发现。如果因为客户的验收，已经完成的模块需要重大的改变，那么整个开发的时间和花费将会大得多。编码-修补模型对于大于 100行代码的软件系统来说是个很坏的选择。另一个缺点就是这种模型开发出来的 产品很难去理解和维护，因为他们缺乏任何需求和设计文档。 因为这种模型没有包括编码前的开发阶段，所以它不被认为是一个完整的生命周期模型。然而在某些场合这种简单的方式非常有用。对于需求非常简单和容易明白，软件期望的功能行为容易定义，实现的成功或失败容易检验的工程可以使用这种模型。 瀑布模型 直到十九世纪八十年代早期，唯一被广泛接受的模型就是瀑布模型。 瀑布模型包括了全部的开发阶段（需求，规格说明，设计，实现，集成，操作和维护）。这些阶段被安排成一定的顺序。当每个阶段完成了，它将被检验和测试，也就是说每个阶段在被认为完成之前必须由软件质量保证小组认可。 瀑布模型的主要特征是它支持下一个阶段到上一阶段的反馈。假如，原是设计阶段的一个错误在实现阶段被发现。在瀑布模型中，设计所需的改变被输入设计阶段的第二次迭代，在工作继续之前这些改变需要被调整和经历一个额外的检验步骤。所有后继的阶段必须适应设计的改变。 一个正式反馈机制的出现保证了开发周期中的调整可以在最小破坏的范围内得到解决。然而瀑布模型有个重要的潜在缺陷。这种模型依赖详细的文档同客户关于软件的需求功能达成一致意见。因为它需要技术能力去明白详细的软件规约，可能会出现客户与开发者对软件理解不同的风险。这会导致开发者开发出的软件满足了规格说明，但是那不是客户所期望的。 快速原型模型 瀑布模型假设大多数，并不是所有的需求分析和规格说明发生在代码编码和模块测试之前。这个假设当客户缺少技术知识，不能写出一份详细的需求清单或者不能完全参与到需求分析过程时就没有作用了。快速原型模型快速创建一个软件系统原型。它可能包括期望功能或用户界面的一个子集，但是它可能在范畴，健壮性，性能和平台方面受限。 快速原型的优点是它可以使用户集中精力参与到需求的讨论中来。即使客户缺乏技术知识用软件工程术语来描述需求，客户也能够谈论用户界面，它是怎么样组织的，它提供了什么功能等等。如果开发者能够创建一个将要被开发系统的工作模型，

软件生存周期模型及特点

6有哪些生存周期模型？各有什么特点？ （1）瀑布模型 瀑布模型（Waterfall Model）是1970年由著名软件工程专家Winston Royce提出的，直到20世纪80年代早期，它一直视为已被广泛采用的软件开发模型。瀑布模型将软件生存周期中各活动（制定计划、需求分析、系统设计、编码、测试和维护）规定为依线性顺序的若干阶段，各项活动自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 瀑布模型的特点： <1>瀑布模型具有顺序性和依赖性,即后一阶段工作必须在前一阶段工作完成后才能开始。 <2>推迟实现的观点；把逻辑设计与物理设计清楚地划分开，尽可能推迟物理模型的实现，这是瀑布模型的重要指导思想。 <3>质量保证的观点。瀑布模型强调的是优质，即每一步都循序渐进，及早消除隐患，从而保证软件质量。 <4>致命缺点是只有做出精确的需求分析，才能取得预期的结果。由于各种客观、主观的原因，需求分析往往不很精确，常常给日后的开发带来隐患。 （2）原型模型 原型模型（Prototype Model）又称为演化模型，主要针对实现不能完整定义需求的软件项目开发而言。它是以一个“样品”为雏形，通过不断改进、完善样品，使得最后得到的产品就是客户所需要的。主要思想：先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。 原形模型的特点： <1>开发人员和用户在“原型”上达成一致。这样可以减少设计中的错误和开发中的风险，以及对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。 <2>缩短开发周期，加快工程进度。 <3>降低成本。 <4>原型模型的缺点：当告诉用户，还必须重新生产该产品时，用户是很难接受的。这往往给工程继续开展带来不利因素。 （3）增量模型 在增量模型（Incremental Model）中，软件被视为一系列的增量构建来设计、实现、集成和测试。增量模型是把整个软件系统分解为若干个软件构件，开发过程中，逐个实现每个构件，实现一个构件，展示一个构件。如果发现问题可以及早进行修正，逐步进行完善，最终获得满意的软件产品。 增量模型特点： <1>增量模型是一种非整体开发的模型。软件在该模型中是“逐渐”开发出来的，开发出一部分，向用户展示一部分，让用户及早看到部分软件，及早发现问题。或者先开发一个“原型”软件，完成部分主要功能，展示给用户征求意见，然后逐步完善，最终后的满意的软件产品。 <2>该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。 <3>缺点：要求软件具有开放的结构是这种模型固有的困难，可能会导致设计差、效率低、维护难。 （4）螺旋模型 1998年，Barry Boehm发表了“螺旋模型（Spiral Model）”，它将瀑布模型和快速原型模型集合起来，强调其他模型所忽视的风险，特别适合于大型复杂系统。该模型分为4个环

软件生存周期模型的特点,及实践中采用的模型

软件生存周期模型的特点,及实践中采用的模型 软件生存周期模型是描述软件开发过程中各种活动如何执行的模型。软件生存周期模型确立了软件开发和演绎中各阶段的次序限制以及各阶段或机动的准则，确立开发过程所遵守的规定和限制，便于各种活动的协调，便于各种人员的有效通信，有利于活动重用，有利于活动管理。常见的软件生存周期模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。 （一）瀑布模型 特点： ●阶段间的顺序性和依赖性 ●推迟实现的观点 ●质量保证的观点（文档驱动性） 优点 ?可强迫开发人员采用规范的方法 ?严格地规定了每个阶段必须提交的文档 ?要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证 缺点 ?周期长：顺序推进，环环审查 ?需求难以准确把握(不能准确提出和沟通、不能快速适应变化的需求)，导致返工甚至推倒重来 ?无法预测新引入模块的影响 ?最终的形式难以预料 ?不适合需求模糊的系统 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是

瀑布开发名称的由来。 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。 （二）演化模型（适用于大型软件的开发） 优点 ?能在较短的时间内向用户提交部分功能的构件； ?逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，减少一个全新软件可能给用户带来的冲击。 缺点 ?增量构件的划分依赖于系统功能的构成和软件开发人员的经验； ?要求软件系统的体系结构具有高度的可扩充性和开放性。 演化模型是一种全局的软件(或产品)生存周期模型。属于迭代开发风范。 模型可以表示为：第一次迭代(需求->设计->实现->测试->集成)->反馈->第二次迭代(需求->设计->实现->测试->集成)->反馈->…… 即根据用户的基本需求，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称之为原型，然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，最终可得到令用户满意的软件产品。采用演化模型的开发过程，实际上就是从初始的原型逐步演化成最终软件产品的过程。演化模型特别适用于对软件需求缺乏准确认识的情况。 （三）螺旋模型 螺旋模型的每一个周期都包括需求分析、风险分析、工程实现和评审4个步骤。螺旋模型主要适用于内部开发的大规模软件项目。当风险过大时，可方便的终止项目。 特点

软件生存周期过程

《信息技术软件生存周期过程》——ISO/IEC 12207与GB/T 8566

摘要对于保证软件质量，提高软件工程能力,关键是科学地建立和管理软件工程过程。ISO/IEC12207 《信息技术一软件生存周期过程》总结了有关研究成果,描述了软件生存期的各个过程及其关系,成为当前关于软件质量管理和软件过程评估与改进方面国际标准的主要参照文献,也是美国、欧洲共同体等发达国家软件工程标准的基本参照文献。我国也发布了等同于国际标准的国标GB/T 8566。 1 ISO/IEC 12207 1.1 ISO/IEC 12207的主要内容 ISO/IEC 12207的主要内容是对软件生存期过程给出了明确的定义。它将软件生存期过程分为3类，即基本类过程、支持类过程和组织类过程，总共定义了17个过程；每个过程包含若干活动，总共74项活动；每个活动是一组相互协调的作业，总共232个作业。作业表示为某种要求、自我说明、建议或可允许的活动。 基本生存周期过程 基本生存周期过程是构成软件生存周期主要部分的那些过程，这些过程启动并执行软件产品的开发、操作或维护，含有5个过程。 l获取过程：定义需方（即获取一个系统、软件产品或软件服务的组织）的活动。 l供应过程：定义供方（即向需方提供系统、软件产品或软件服务的组织）的活动。 l开发过程：定义开发者（即定义和开发软件产品的组织）的活动。

l操作过程：定义操作者（即在计算机系统运行环境中为用户提供操作服务的组织）的活动。 l维护过程：定义维护者（即对软件产品进行维护服务的组织）的活动，这个过程包括系统移植和换代。 支持生存周期过程 支持过程是对另一个过程提供支持的过程。被支持的过程根据需要采用支持过程，并与该过程结合，帮助软件项目获得成功，并提高质量。支持生存周期过程包括8个过程。 文档开发过程：定义对某生存周期过程所产生的信息进行记录的活动。 配置管理过程：定义配置管理活动。 质量保证过程：定义保证软件产品和过程符合规定要求，遵守一定计划的活动。 验证过程：定义需方、供方或独立的第三方对软件产品进行验证的活动。这些验证活动的深度由软件项目的性质决定。 确认过程：定义需方、供方或独立的第三方对软件产品进行确认的活动。 联合评审过程：定义对某项活动的状态和产品进行评价的活动。这一过程可由任何双方共同采用，其中一方（评审方）评审另一方（被评方）。 审计过程：定义对是否符合要求、计划和合同进行确定的过程。这个过程可由任何双方采用，其中一方（审计方）审计另一方（被审方）的软件产品或活动。 问题解决过程：定义对开发、操作、维护或其他过程中发现的问题（包括不一致性）进行分析与排出的过程。 组织生存周期过程

OPD-3-01 软件开发生命周期模型

本资料仅供内部使用！ 软件开发生命周期模型 东南融通集团 2006年4月30日

软件开发生命周期文件编号：OPD-3-01 版本：B 修改记录

目录 1目的 (1) 2范围 (1) 3软件开发生命周期模型 (1) 3.1.1标准V-瀑布生命周期(SVW) (2) 3.1.2V-瀑布生命周期为关键产品(VC) (3) 3.1.3阶段V-瀑布生命周期(V4) (5) 3.1.4阶段V-瀑布生命周期(V3) (6) 3.1.5编码和修正生命周期(C&F) (7) 3.1.6阶段交付模型 (8) 3.1.7交叠瀑布模型 (9)

1目的 描述组织范围内使用的软件开发生命周期模型； 2范围 本文档主要描述软件项目开发生命周期模型,适用于集团内部研发项目、为客户开发系统的项目、推广移植的项目、维护项目等。 3软件开发生命周期模型 每种模型都用图形的方式来描述，显示了它们应用的阶段和阶段评审检查点。描述了在何种条件下使用该模型，需要注意风险和应用裁剪的指导。 每一幅图都指出了运用于该模型的阶段和阶段评审检查点。用粗体和斜体表示的阶段评审检查点推荐要有高层经理参加。所有的阶段评审检查点都要由项目经理签字。 主要阶段: ●项目售前/定义(PD) ●项目立项/启动(PI) ●需求分析和计划(RA&P) ●概要设计(HLD) ●详细设计(DD) ●编码和单元测试(CUT) ●集成测试(IT) ●系统测试(ST) ●发布/上线(REL) ●关闭(CLS) 阶段评审检查点 ●顾客签字(CUSTSO) ●开始(KO) ●需求签字(RSO) ●架构签字(ASO) ●设计签字(DSO) ●编码签字(CSO) ●功能完成(FC) ●系统完成(SC) ●发布完成(RC) 利用这节提供的细节来最终选择软件开发生命周期的模型。对大多数的项目，从前面的部分表格来看可能有不止一种适合的模型。利用本节所详细描述的模型，有适应或裁剪地最终

软件项目生存期模型确定实验1

南京信息工程大学实验（实习）报告 实验名称软件项目生存期模型确定实验（实习）日期 9.30 得分指导教师徐旦华系计算机与软件学院专业软件工程年级班次姓名学号 一、实验目的 1. 学习软件项目生存期模型的内容及特点；重点掌握预测型生存期模型及迭代型生存期模型、增量型生存期模型及敏捷模型的内容。 2.掌握各生存期模型的特点及项目适用范围。 3.学习利用所学知识，分析软件项目特性，确定合适的生存期模型。 二、实验内容 对仓库管理系统确定生存期模型。软件项目基本情况如下：甲方对软件项目开发时间要求是２０１９年１１月－２０２０年４月，请根据软件项目具体内容分析项目特性，根据己方资源，确定采用的生存期模型，要求给出项目分析过程，详细给出选择某生存期模型的理由，并给出生存期各阶段的相应的任务。 三、实验结果 （1）选择增量模型原因 1.首先，甲方要求的系统为仓库管理系统，时间为半年，而仓库管理系统全部功能大致可以分为：人员管理和货物管理两大部分，因此可以先基于这两个部分做出一个最小的使用版本，再逐渐根据用户使用的反馈来添加一些新的功能，有助于下一阶段的开发，也大大地减少了开发的风险。 2.对于仓库管理系统，可能存在货物变动，或者人员变动，因此应该默认要求系统有可扩充性。使用增量模型，可以保证系统的可扩充性，用户明确了一部分需求，但仍然有一部分隐藏的需求需要在后序的使用中慢慢反馈，进而添加或者修改功能。 3.对于一个管理方式可能已经固化的企业，要舍弃原有的仓库管理方式，用该系统完全代替是不太容易实现的，因此可以先完成基础的版本，逐步通过实际的使用来扩充应用，所以我选用了增量模型来研发仓库管理系统。 4.本项目具备增量模型的一些特点： 完成期限要求严格的产品；对于市场和用户把握不是很准，需要逐步了解 （2

案例说明-《校务通管理系统》的生存期模型

《校务通管理系统》的生存期模型 针对本项目的开发特点，参考企业的生存期模型说明和软件过程体系，决定采用增量式模型如下图，理由如下： 1．校务通系统的全部功能分成通用功能和日常业务管理功能两大类，因此可以先基于通用功能作出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。 2．在校务通系统需求规格中，要求系统有可扩充性。若使用增量模型，可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。如：“关于教师档案，比照所提供资料设计，现在也没有一个成形的东西”；资源库系统只提到“应提供一个标准的资源库解决方案。”这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性。直至产生最终完善的产品。 3．“系统要求有可扩充性，可以在现有系统的基础上，通过前台就可加挂其它功能模块”。也说明用户可能会增加新的需求。 4．对一个管理方式已经比较成熟的学校，要完全舍弃原有的管理方式，用校务通系统替代全部管理，这是不实际的。所以，可以从最基础的做起，逐步扩充其应用，所以选用增量模型来开发校务通系统。 5．本项目具备增量式模型的其他特点 a)项目复杂程度为中等。 b)预计开发软件的成本为中等。 c)产品和文档的再使用率会很高, d)项目风险较低

生存期中的各阶段定义如下： 项目规划阶段 阶段目标：根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。 输入：合同文本 SOW 过程：项目规划，计划确认 输出：项目计划 需求分析阶段 阶段目标：确定客户的需求 输入：项目计划，SOW 过程：需求获取，需求分析，需求控制 输出：原型系统，需求规格 设计阶段 阶段目标：总体系统结构设计 输入：原型系统，需求规格 过程：总体设计 输出：系统设计说明书，数据库结构定义 增量1实现 阶段目标：实现系统的通用功能 输入：系统设计说明书 数据库结构定义 过程：详细设计,编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本－1 增量2实现 阶段目标：实现系统的招生管理功能 输入：系统设计说明书 数据库结构定义 过程：详细设计,编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本－2 增量3实现 阶段目标：实现系统的学生日常管理功能 输入：系统设计说明书 数据库结构定义 过程：详细设计,编码，代码走查，代码评审，单元测试 输出：详细设计说明书，源代码，可运行版本－3 增量4实现 阶段目标：实现系统的教务管理功能 输入：系统设计说明书