[软件工程]软件生存周期过程与管理————(2020.6.29学习笔记）

本文链接：https://blog.csdn.net/qq_37704442/article/details/107028322

第一节软件生存周期过程概述

软件生存周期(SDLC，软件生命周期)
是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。
一般来说，软件生存周包括计划、开发、运行三个时期，每一时期又可分为若干更小的阶段。计划时期的主要任务是分析用户要求，分析新系统的主要目标以及开发该系统的可行性。开发时期要完成设计和实现两大任务具体。具体分为需求分析、概要设计、详细设计、编码、测试。其中编码和测试是软件开发期的最后两个阶段。运行时期是软件生存周期的最后一个时期，软件人员在这一时期的工作，主要是做好软件维护。
基本过程
指那些与软件生产直接相关的活动集。
（1）获取过程
（2）供应过程
（3）开发过程
（4）运行过程
（5）维护过程
开发过程
软件开发者所从事的一系列活动和任务。将一组需求转换为一个软件产品或系统。
（1）过程实现
（2）系统需求分析
（3）系统体系结构设计
（4）软件需求分析
（5）软件体系结构设计
（6）软件详细设计
（7）软件编码和测试
（8）软件集成
（9）软件合格性测试
（10）系统集成
（11）系统合格性测试
（12）软件安装
（13）软件验收支持
过程实现
（1）选择合适的生存周期模型
（2）选择相应的标准、方法、工具和程序设计语言
（3）制定实施开发计划
（4）可以使用一些非交付的软件项。
系统需求分析
（1）建立系统需求规格说明
（2）对系统需求进行评估
a) 有关获取方面需要的可追踪性
b) 有关获取方面需要的一致性
c) 可测试性
d) 系统体系结构设计的可行性
e) 运行与维护的可行性
系统体系结构设计
（1）建立系统的顶层体系结构
（2）对体系结构及每一项的需求进行评估
a) 系统需求的可追踪性
b) 与系统需求的一致性
c) 所使用的设计标准和方法的适宜性
d) 软件项满足其所分配的需求的可行性
e) 运行与维护的可行性
软件需求分析
（1）建立软件需求规格说明
a) 功能与能力的规格说明
b) 该软件项的外部接口
c) 合格性需求
d) 有关安全的规格说明
e) 有关保密的规格说明
f) 人因工程的规格说明
g) 数据定义和数据库需求
h) 用户文档
i) 用户操作与执行需求
j) 用户维护需求
（2）对软件需求进行评估
a) 对系统需求和系统设计的可追溯性
b) 与系统需求的外部一致性
c) 内部一致性
d) 可测试性
e) 软件设计的可行性
f) 运行和维护的可行性
（3）联合复审
软件体系结构设计
（1）把对软件项的需求转变为一种体系结构
（2）对该软件项的外部接口和各构件之间的接口进行顶层设计
（3）进行数据库的顶层设计
（4）编制用户文档的最初版本
（5）为软件集成定义初步的测试需求文档
（6）对软件项的体系结构、接口和数据库设计进行评估
（7）实施联合评审
支持过程
是指有关各方按他们的目标所从事的一系列支持活动集。支持活动有助于提高系统或软件产品的质量。
（1）文档过程
（2）配置管理过程
（3）质量保证过程
（4）验证过程
（5）确认过程
（6）联合评审过程
（7）审计过程
（8）问题解决过程
支持过程—配置管理过程
应用管理上、技术上的规程来支持整个软件生存周期的过程。
（1）过程实现：编制配置管理计划
（2）配置标识
（3）配置控制：标识并记录变更请求
（4）配置状态统计：编制管理记录和状态报告
（5）配置评价
（6）发布管理和交付
组织过程
与软件生产组织有关的活动集。
（1）管理过程
（2）基础设施过程
（3）培训过程
（4）改进过程
组织过程—管理过程
（1）启动与范围定义
（2）规划
（3）测量
（4）执行与控制
（5）评审与评价
（6）结束处理
ISO/IEC系统与软件工程-软件生存周期过程12207-2008
2个过程类、7个过程组、43个过程。
“系统语境的过程”和“软件开发的过程”。
（1）协议过程组
（2）项目过程组
（3）技术过程组
（4）组织上项目使能过程组
（5）软件实现过程组
（6）软件支持过程组
（7）软件复用过程组

第二节过程描述

过程描述
过程→活动→任务
供应过程
活动1：机遇标识
活动2：供应方投标
任务1：需求评审
任务2：做出有关投标或接受合同的决定
任务3：准备一份提案
活动3：合同协商
任务1：与获取方就提供的软件产品或服务，协商合同条文
任务2：请求对合同的修改，作为变更控制机制的一个成分。
活动4：合同执行
任务1：进行获取需求评审
任务2：定义或选择一个适合项目范围、粒度和复杂性的生存周期模型。

……
3. 软件实现过程
活动：软件实现策略
任务1：开发人员选择合适的生存周期模型
任务2：实施人员
任务3：实施人员选择合适的标准、方法、工具和编程语言
任务4：开发进行该过程活动的计划
任务5：对不用交付的软件项的处理。
4. 软件需求分析过程
5. 软件体系结构设计
6. 软件验证过程
7. 软件确认过程

第三节应用说明

是对标准“ISO/IEC系统与软件工程-软件生存周期过程12207-2008”的应用说明。

系统和软件
软件是整个系统的组成部分。
区分系统需求分析和软件需求分析。
与《ISO/IEC系统生存周期15288》的关系
当系统中包括非常重要的非软件因素时，要应用《ISO/IEC系统生存周期15288》。
组织层和项目层
项目可能由组织执行
过程之间的时序关系
没有明确过程、活动、任务之间的时间依赖的序列。
支持活动之间的迭代和再现。
过程分解
把过程划分为一些小的“片段”
生存周期模型和阶段
剪裁

第四节软件生存周期模型

瀑布模型
系统需求
软件需求
需求分析
设计
编码
测试
运行
自上而下具有相互衔接的固定顺序。
每一阶段的输入，即工作对象以及本阶段的工作成果，作为输出传送到下一阶段。
瀑布模型的贡献：
（1）在决定系统怎样做之前存在一个需求阶段，它鼓励对系统做什么有一个规约。
（2）在系统构造之前有一个设计阶段，它鼓励规划系统结构
（3）每一阶段都有评审，允许获取方和用户的参与
（4）前一步作为下一步被认可的、文档化的基线
瀑布模型存在的问题：
（1）要求客户能够完整、正确和清晰地表达他们的需求，并要求开发人员一开始就理解这一应用。
（2）由于需求的不确定性，使设计、编码和测试阶段都可能发生延期，并且当项目接近结束时，出现了大量的集成和测试工作。
（3）在开始的阶段中，很难评估真正的进度状态，并且直到项目结束之前都不能演示系统的功能。
（4）在一个项目的早期阶段，过分地强调了基线和里程碑处的文档，并可能需要花费更多的时间用于建立一些用处不大的文档。
增量模型
增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。

增量模型适用于“技术驱动”的软件产品开发。
优点：
采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户，对客户起到镇静剂的作用。此外，增量能够有计划地管理技术风险。
缺点：
增量模型存在以下缺陷：
1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
3. 演化模型
演化模型是一种全局的软件（或产品）生存周期模型。属于迭代开发方法。
该模型可以表示为：第一次迭代(需求->设计->实现->测试->集成)->反馈->第二次迭代(需求->设计->实现->测试->集成)->反馈->……
即根据用户的基本需求，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称之为原型，然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，最终可得到令用户满意的软件产品。采用演化模型的开发过程，实际上就是从初始的原型逐步演化成最终软件产品的过程。演化模型特别适用于对软件需求缺乏准确认识的情况。
演化模型主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。实际上，这个模型可看作是重复执行的多个“瀑布模型”。
“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。
演化模型的优点：
（1）任何功能一经开发就能进入测试以便验证是否符合产品需求。
（2）帮助导引出高质量的产品要求。如果没有可能在一开始就弄清楚所有的产品需求，它们可以分批取得。而对于已提出的产品需求，则可根据对现阶段原型的试用而作出修改。
（3）风险管理可以在早期就获得项目进程数据，可据此对后续的开发循环作出比较切实的估算。提供机会去采取早期预防措施，增加项目成功的机率。
（4）大大有助于早期建立产品开发的配置管理，产品构建（build ），自动化测试，缺陷跟踪，文档管理。均衡整个开发过程的负荷。
（5）开发中的经验教训能反馈应用于本产品的下一个循环过程，大大提高质量与效率。
（6）如果风险管理发现资金或时间已超出可承受的程度，则可以决定调整后续的开发，或在一个适当的时刻结束开发，但仍然有一个具有部分功能的，可工作的产品。
（7）心理上，开发人员早日见到产品的雏型，是一种鼓舞。
（8）使用户可以在新的一批功能开发测试后，立即参加验证，以便提供非常有价值的反馈。
（9）可使销售工作有可能提前进行，因为可以在产品开发的中后期取得包含了主要功能的产品原型去向客户作展示和试用。
演化模型的缺点：
（1）如果所有的产品需求在一开始并不完全弄清楚的话，会给总体设计带来困难及削弱产品设计的完整性，并因而影响产品性能的优化及产品的可维护性。
（2）如果缺乏严格的过程管理的话，这个生命周期模型很可能退化为一种原始的无计划的“试－错－改”模式。
（3）心理上，可能产生一种影响尽最大努力的想法，认为虽然不能完成全部功能，但还是造出了一个有部分功能的产品。
（4）如果不加控制地让用户接触开发中尚未测试稳定的功能，可能对开发人员及用户都产生负面的影响。
4. 螺旋模型
螺旋模型（Spiral Model）采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:：

软件过程
螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。在实践中，螺旋法技术和流程变得更为简单。迭代方法体系更倾向于按照开发/设计人员的方式工作，而不是项目经理的方式。螺旋模型中存在众多变量，并且在将来会有更大幅度的增长，该方法体系正良好运作着。

喷泉模型
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。

喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。