2软件生存周期与软件过程
软件工程第二章-软件过程
编码
运行 时期
1. 瀑布模型
瀑布模型(waterfall model)是软件工程最早的范例，
也称经典生命周期，它提出了一个系统的、顺序的软 件开发方法，从用户需求规格说明开始，通过计划、 建模、构建和部署的过程，最终提供一个完整的软件 并提供持续的技术支持。
沟通 项目启动 需求获取 策划 项目估算 进度计划 项目跟踪
… 框架活动 # n 动作 # n.1 任务集 …… 动作 # n.m 任务集 工作任务、工作产品、 质量保证点、项目里程碑
工作任务、工作产品、 质量保证点、项目里程碑
只有一种软件过程吗？
软件过程的种类很多，区别主要体现在几个方面： 组成过程的各个活动(包括普适性活动)、动作和任务，及其相互依 赖的关系都可能不同； 动作和任务的细化程度可能不同； 工作产品的定义和要求可能不同； 质量保证活动的应用方式可能不同； 项目跟踪和控制活动的应用方式可能不同； 过程描述的详细程度和严谨程度可能不同； 客户和利益相关者对项目参与的程度可能不同； 软件团队所赋予的自主权可能不同； 队伍组织和角色的明确程度可能不同。
下优先级进行增量开发：
第一个增量实现基本的文件管理、编辑和文档生成功能
； 第二个增量实现更加完善的编辑和文档生成功能； 第三个增量实现拼写和文法检查功能； 第四个增量完成高级的页面布局功能； ……
增量模型的特点
增量过程模型综合了线性、并行、演化三种过程流的
特征。
对于每个增量，使用的是线性过程流；
过程流
过程流(process flow)：描述了在执行顺序和执行时
间上，如何组织框架中的活动、动作和任务。 大致有四大类不同的过程流：
医疗器械软件生存周期过程讲解
集成测试的严格程度和与集成测试有关的文件的详细程度应当和与器械有关的风险、器械对有潜在危 害作用的软件的依赖性、及在较高风险器械功能方面特定软件项的作用相当。例如，虽然所有的软件项都 应当进行测试，但对安全性有影响的软件项应当受到更直接，彻底和详细的测试。
2.7 软件系统测试
要求通过验证已经成功实现的软件要求，以验证软件的功能性。 软件系统测试证实软件具有规定的功能性。这项测试是对根据软件需求建立的程序功能性和性能进行 验证。 软件系统测试集中在功能(黑盒)测试，虽然可能需要使用白盒测试方法来更有效地完成某些测试，如 启动压力条件或缺陷、以及增加条件测试的代码覆盖率。测试类型和测试阶段的组织是灵活的，但对于需 求覆盖率、风险控制、适用性以及测试类型(如缺陷测试、安装测试、压力测试)应该被证明并以文档形式 记录下来。 软件系统测试是对集成软件的测试，可在模拟的环境里，在实际的目标硬件上，或在整个的医疗器械 上进行。 当对软件系统做出更改(即使是小的更改)时，应当决定回归测试的程度(不仅仅是个别更改的测试)以 确保没有引人非预期的副作用。此项回归测试(以及不全面重复软件系统测试的理由说明)应当进行策划并 形成文档。
2.6 软件集成和集成测试
要求策划并将软件单元集成为软件项集合，以及将软件项集成为软件项的较高级集合，并验证所形成 的软件项按照预期运行。
集成方法的范围可从非递增的集成到任何形式的递增集成。安装的软件项的性质规定所选择的集成方 法。
软件集成测试集中在传递数据和控制软件项的内部和外部接口间的交汇。外部接口是那些和包括操作 系统软件在内的其他软件和医疗器械硬件的接口。
ch10 软件工程
四、测试的基本步骤
模块测试 组装测试
系统测试
五 软件测试方法
软件测试方法分为两类： 静态分析和动态测试 1.静态分析方法 指以人工的、非形式化的方法对程序 进行分析和测试。 桌前检查 代码会审 步行检查
2.动态测试方法
通过选择适当的测试用例，执行程序。 常用的方法： 1）白盒法
分析程序的内部逻辑结构，注意选择适当的 覆盖标准，设计测试用例，对主要路径进行尽 可能多的测试。
软、硬件失效情况的对比
失效率 失效率 实际曲线 时间 理想曲线 时间 软件失效率曲线
硬件失效率曲线
硬件失效率曲线，是一U型曲线（即浴盆曲线）。软件 失效率曲线，它没有U型曲线的右半翼。因为软件不存在磨
损和老化问题，然而存在退化问题。
三、软件的分类
1、按照软件功能划分
系统软件 — 如操作系统、设备驱动程序等。 支撑软件（实用软件） — 协助用户开发的工具软件，如编 辑程序、程序库、图形软件包等。 应用软件 — 如工程与科学计算软件、CAD/CAM软件、CAI软 件、信息管理系统等。
二、软件测试的特点
1、软件测试的开销大
按照Boehm的统计，软件测试的开销大约占总成本的 30%-50%。例如：APPOLLO登月计划，80%的经费用于 软件测试。
2、不能进行“穷举”测试
只有将所有可能的情况都测试到，才有可能检查出所有的 错误。但这是不可能的： 例：程序P有两个整型输入量 X、Y，输出量为Z，在32位机 上运行。所有的测试数据组（Xi，Yi）的数目为： 1毫秒 执行1次，共需5亿年。
1963年美国飞往火星的火箭爆炸，造成1000万美元的损失。 原因是FORTRAN程序： DO 5 I=1，3 误写为：DO 5 I=1 . 3 1967年苏联“联盟一号”载人宇宙飞船在返航时，由于软件 忽略一个小数点，在进入大气层时因打不开降落伞而烧毁。
软件开发过程生命周期模型
软件开发过程生命周期模型一、序言生命周期指软件开发全部过程、活动和任务的结构框架。
软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。
目前软件开发实践中使用的各种生命周期模型，都是下面这些基本组成部分的不同的排列与组合。
•市场分析，可行性研究，与项目定义•需求分析•设计（概要设计和详细设计）•编码实现•测试•使用与维护主要有以下几种模型：• 1.瀑布模型（waterfall model）• 2.演化模型（evolutionary model）• 3.螺旋模型（spiral model）二、瀑布模型瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作，形如瀑布流水，最终得到软件产品。
如图所示：优点：a.强调开发的阶段性；b.强调早期计划及需求调查；c.强调产品测试。
缺点：a.依赖于早期进行的唯一一次需求调查，不能适应需求的变化；b.由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；c.风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会下表是瀑布模型中各个阶段的主要工作，及相应的质量控制手段。
阶段主要工作应完成的文档应完成的文档质量控制手段系统需求1．调研用户需求及用户环境2．论证项目可行性3．制定项目初步计划1．可行性报告2．项目初步开发计划1．规范工作程序及编写文档2．对可行性报告及项目初步开发计划进行评审需求分析1．确定系统运行环境2．建立系统逻辑模型3．确定系统功能及性能要求4．编写需求规格说明、用户手册概要、测试计划5．确认项目开发计划1．需求规格说明2．项目开发计划3．用户手册概要4．测试计划1．在进行需求分析时采用成熟的技术与工具，如结构化分析2．规范工作程序及编写文档3．对已完成的4种文档进行评审三、演化模型该模型主要针对事先不能完整定义需求的软件开发。
用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。
IVDR法规第二次软件指导与培训
2 风险评价 均提交
分析导致危险情况的潜在原因，可以从以下几个方 面考虑： a. 功能说明不正确或不完整； b. 软件功能中存在缺陷； c. SOUP 失效造成（列明SOUP 项供应商发布的版 本与使用的 SOUP 项版本的区别）； d. 硬件失效或其他软件缺陷； e. 合理的可预见的误用。 [Class B, C]
软件开发过程
4 软件详细设计 [Class B, C] 概述软件所用开发方法（如面向过程、面向对象、 敏捷开发等）、编程语言、开发测试环境（含软 硬件设备、开发测试工具、网络条件、云计算）， 其中开发测试工具明确名称、完整版本、开发商； 提供开发测试的人员总数、时长、工作量（人月 数）、代码行总数的概数。
（4）物理拓扑 基于软件设计规范文档提供软件的物理拓扑图（含 云计算），依据物理拓扑图详述软件/组成模块、 通用计算平台、医疗器械硬件产品/部件、必备软 件之间的物理连接关系，包括全部外围设备。 （5）运行环境 明确软件正常运行所需的典型运行环境，包括硬件 配置、外部软件环境、必备软件、网络条件。其中， 硬件配置包括处理器、存储器、外设器件等要求； 外部软件环境包括系统软件、通用应用软件、通用 中间件、支持软件，注明全部软件的名称、完整版 本、补丁版本，使用“兼容版本”而非“以上版 本”、“更高版本”；若适用，必备软件明确名称、 型号规格、发布版本、注册人；网络条件包括网络 架构（如BS架构、CS架构、混合架构）、网络类 型（如广域网、局域网、个域网）、网络带宽等要 求。 若使用云计算，明确云计算的名称、服务模式、部 署模式、配置以及云服务商的名称、住所、服务资 质。
4 软件验证 [Class A, B, C] 除应验证修改部分外，还应进行回归测试。 5 软件发布 [Class A, B, C] 可以将软件系统重新发布，也可以作为一个修改包 进行发布。 6 用户告知 [Class A, B, C] 对于变更后的软件，应根据当地法规的要求，将以 下内容通知用户和监管机构： a. 已发布软件存在的问题以及不更改的后果； b. 变更的内容以及如何进行升级。
软件工程(概论)生存期和开发模型-作业2
2.3 软件开发模型
4．模型的优点 开发阶段清晰，便于评审、审计、跟踪、管理和控制。
5．模型的缺点 传统的项目组织方法是按顺序完成每个工作流程，即瀑布式生命周期。瀑布
只能一个个台阶地往下流，不可能倒着往上流，这就是它致命的缺点。 瀑布式生命周期通常会导致在项目后期，出现“问题堆积”，更可怕的是，错
一阶段（活3）动用的户输使入用，环继境续很进稳行定下；一阶段的活动，否则返回上一阶段修改。 （4）用户除提出需求以外，很少参与开发工作。
2．模瀑型布的模特型点认为：项目经理或软件管理人员，只要控制好每级台阶的高度 （和1宽）度里，程在碑每或个基台线阶驱处动设，立或里者程说碑文或档基驱线动，；并组织好对基线的评审与审 （计2，）就过可程以逆控转制性好很项差目或的者开说发不成可本逆、转进，度因和为质根量据。上游的错误会在下游进行
误的传递会采取发散扩大的方式。
瀑布模型反馈环
CMM/CMMI采取阶段评审和不符合项(Noncompliance Items)的动态跟踪制度， 只有前一阶段不符合项全部改正，才允许开发人员进入后一阶段工作。
不符合项，就是在评审中发现的问题项，它不同于Bug。对于这些不符合项，软 件管理部门要列出表格，记录在案，确定责任人，限定改正时间，动态跟踪到底 。
可行性研究的结果是负责人作出是否继续进行这项工程的决定的重要依据。 可行性研究以后的各个阶段，将需要投入多少相应的人力物力。 及时终止不值得投资的工程项目，可以避免更大的浪费。
2.2 软件工程过程
3. 需求分析
这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须 具备哪些功能。产生《需求规格说明书》。
信息技术软件生存周期程介绍
在计算机技术不断发展和应用的过程 (guòchéng)中，软件的规模越来越大，软 件已经不再是个体产品而是成百上千人 合作劳动的成果；软件开发，也从注意 技巧发展为注重管理，软件开发过程 (guòchéng)从目标管理转向过程(guòchéng) 管理
第八页，共139页。
1.1.3 软件(ruǎn jiàn)工程与软件(ruǎn jiàn)过程管理
第二十五页，共139页。
a) 文档编制过程——为记录生存周期过程所产 生的信息而定义的活动；
b) 配置管理过程——定义配置管理活动； c) 质量保证过程——为客观地保证软件产品和
过程符合规定的需求(xūqiú)以及已建立的计 划而定义的活动。联合评审、审核、验证和确 认可以作为质量保证技使用； d) 验证过程——根据软件项目需求(xūqiú)，按 不同深度（为需方、供方或某独立方）验证软 件产品而定义的活动；
第二十二页，共139页。
基本过程是： a)获取过程——为获取系统、软件产品或软件服务的组织即
需方而定义的活动； b)供应过程——为向需方提供系统、软件产品或软件服务的
组织即供方而定义的活动； c)开发过程——为定义并开发软件产品的组织即开发方而定
义的活动； d)运作过程——为在规定(guīdìng)的环境中为其用户提供运
第二十一页，共139页。
2.1 生存(shēngcún)周期基本过程
生存周期基本过程包括5个过程，这些 过程供各主要参与方在软件生存周期期 间使用。主要参与方是参与或完成软件 产品开发(kāifā)、运作或维护的组织。 这些主要参与方有软件产品的需方、供 方、开发(kāifā)方、操作方和维护方。
第十七页，共139页。
2.0 导引 在解决“软件危机”的过程中，许多
第2章 软件生存期模型
2.3 增量模型
➢ 增量模型如图所示。
2.3 增量模型
• 增量模型的优点
(1)能在较短时间内向用户提交可完成一些有用的工作产品， 即从第1个构件交付之日起，用户就能做一些有用的工作。
(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适 应新产品，从而减少一个全新的软件可能给用户组织带来 的冲击。
在维护和开发之间并没有本质区别。
2.4 螺旋模型
• 螺旋模型的缺点
➢ 螺旋模型是风险驱动的，因此要求软件开发人员 必须具有丰富的风险评估经验和这方面的专门知 识，否则将出现真正的风险：当项目实际上正在 走向灾难时，开发人员可能还以为一切正常。
2.4
➢ 多数场合，软件开发过程是沿螺旋线的路径连 续进行的。
2.6 统一过程
• 统一过程的阶段
③ 构造阶段。构造阶段是建立系统，构造信息系统 的第1个具有操作质量的版本，以能够交付给客户 进行测试的版本结束，有时称为测试版本。
④ 移交阶段。移交阶段包含测试时期，以发布完 整的系统而终止，其目标是确保信息系统真正满 足客户的需求。
2.6 统一过程
• 主要工作产品
➢ 原型建造模型和螺旋模型既是迭代模型，又是进 化模型。
➢ 实践中，客户利用迭代或增量模型尽快开发第一 个版本的软件制品，占领市场的有利商机，然后 再逐步扩展系统功能，不断推出后续版本。
2.5 喷泉模型
• 喷泉模型是典型的面向 对象生命周期模型。
➢ “喷泉”一词体现了迭 代和无间隙特性。图中 代表不同阶段的圆圈相 互重叠，这明确表示两 个活动之间存在重叠。
2.3 增量模型
• 采用增量模型需注意的问题
软件生存周期模型
中间版本1
D
C/T
I/AS
R
D
中间版本2
C/T
I/AS
中间版本n
D
C/T
I/AS
可能的信息流 R：需求 C/T：编码/测试 D：设计 I/AS：安装和验收支持
图1-5 渐增模型示意
1.2 渐增模型
• 在开发每个中间版本时，开发过程中的活动和任务顺序地或部 分平行地使用。当相继的中间版本在部分并行开发时，开发过 程中的活动和任务可以在各中间版本间平行地采用。
工作版本作版本2
R2
D
C/T
I/AS
工作版本n
Rn
D
C/T
I/AS
信息流 (细化) R：需求 C/T：编码/测试 D：设计 I/AS：安装和验收支持
图1-6 演化模型示意
1.3 演化模型
• 对所有的中间版本，开发过程中的活动和任务通常接同一顺序被重复使用。维 护过程和运作过程可以与开发过程平行地使用。获取过程、供应过程、支持过 程和组织过程通常与开发过程平行地使用。
1.1 瀑布模型
• 瀑布模型在大量的实践中也暴露了不足和问题。例如，由于固定顺序，前期阶 段工作中所造成的差错，越到后期阶段所造成的损失和影响也越大，为了纠正 它而花费的代价也越高，尽管技术人员小心翼翼，但这种情况还是会经常发生。 因此，在评价瀑布模型时，应考虑以下的相关风险：
– 需求未被充分理解。 – 系统太大而一次不能做完所有的事。 – 事先打算采用的技术迅速发生变化。
1.3 演化模型
• 演化模型 (图1-6) 也是通过构造系统的各个可执行的中间版本来开发系统的， 但是，与渐增模型的区别是承认需求不能被完全了解，且不能在初始时就确定。 在该模型中，需求一部分被预先定义，然后在每个相继的中间版本中逐步完善。 该模型中，每个中间版本在开发时，开发过程中的活动和任务顺序地或部分重 叠平行地被采用。
软件生存周期过程控制规定(新)
软件生存周期过程控制规定XXX公司修改记录（A-新增，M-修改，D-删除）目录1.目的 (4)2.范围 (4)3.职责 (4)4.术语 (4)4.1未知来源软件(SOUP) (4)4.2版本 (4)4.3软件安全性级别 (4)5.程序 (5)5.1 软件开发策划 (5)5.2软件需求分析 (7)5.3 软件体系结构设计 (9)5.4软件详细设计 (10)5.5软件单元的实现和验证 (10)5.6软件集成和集成测试 (12)5.7软件系统测试 (12)5.8软件发行 (14)5.9软件维护过程 (15)5.10软件风险管理过程 (16)5.11软件配置管理过程 (17)5.12软件问题解决过程 (18)6.相关文件 (21)7.相关记录 (21)1.目的规定了医疗软件的生产周期要求，为安全设计和维护提供了包括必要活动和任务的生存周期过程的规定。
2.范围适用于本公司医疗软件开发和维护的过程控制。
3.职责4.术语4.1未知来源软件(SOUP)已开发且通常可得到的，并且不是为用以包含在医疗器械内而开发的软件项（也通常称为成品软件），或者以前开发的、不能得到其开发过程足够记录的软件。
4.2版本某一配置项的已标识了的实例。
4.3软件安全性级别按照软件系统引起的危害对于患者、操作者或其他人员的可能影响，赋予每个软件系统一个软件安全性界别（A、B或C）。
A级：不可能对健康有伤害或损坏；B级：可能有不严重的伤害；C级：可能死亡或严重伤害。
5.程序5.1 软件开发策划项目经理应制订软件开发计划，以实施适合于所开发软件系统的范围、规模和软件安全级别的软件开发过程的活动。
在计划中应完整地规定软件开发生存周期模型，并说明以下各项：（1）用于软件系统开发的过程；（2）各项活动和任务的交付物；（3）系统需求、软件需求、软件系统测试和在软件中实施的风险控制措施之间的可追溯性；（4）软件配置和更改管理，包括位置来源软件配置项和用于支持开发的软件；（5）在生存周期各个阶段的软件产品、交付物和活动中发现的用于处理问题的软件问题解决方案；（6）对于C级软件，应包括或引用开发有关的标准、方法和工具；（7）对于B级、C级软件，应包括集成软件项（包括SOUP）并在集成过程中完成测试；（8）下列验证信息：•需要验证的交付物；•每个生存周期活动所要求的验证任务；•对交付物进行验证的里程碑；•验证交付物的验收准则。