目录
5.1 软件工程概述
软件开发/过程模型:瀑布模型、演化模型、螺旋模型、喷泉模型等
软件开发方法:面向数据流、面向数据结构、面向对象
5.1.2 软件工程基本原理(7个)
1. 用分阶段的生命周期计划严格管理(软件的整个生存周期中应该制定并严格执行六类计划)
项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划
2. 坚持进行阶段评审(每个阶段都应进行严格的评审,以便尽早发现在软件开发过程中所犯的错误)
3. 实现严格的产品控制(主要实行基准配置管理)
4. 采用现代程序设计技术(既可以提高软件开发的效率,也可以降低软件维护的成本)
5. 结果应能清楚地审查(根据软件开发的总目标及完成期限尽量明确地规定开发小组的责任和产品标准,从而使所得到的结果能够清楚地审查。)
6. 开发小组的人员应少而精
7. 承认不断改进软件工程实践的必要性
5.1.3 软件生存周期(7个)
1. 可行性分析与项目开发计划
主要内容:确定软件的开发目标及可行性。
参与人员:用户、项目负责人、系统分析师
产生文档:可行性分析报告、项目开发计划
2. 需求分析
主要内容:准确地确定软件系统必须做什么,确定软件系统的功能、性能、数据和界面等要求,从而确定系统的逻辑模型。
参与人员:用户、项目负责人、系统分析师
产生文档:软件需求说明书
3. 概要设计
主要内容:将确定的各项功能需求转换成需要的体系结构,明确软件的模块组成、模块的层次结构、调用关系、存储的数据、数据的结构、数据关系等。
参与人员:系统分析师、软件设计师
产生文档:概要设计说明书
4. 详细设计
主要内容:对每个模块完成的功能进行具体描述,将功能描述转变为精确的、结构化的过程描述。包括模块的控制结构、先后执行顺序、判定条件等,并用相应工具表示出来。
参与人员:软件设计师、程序员
产生文档:详细设计文档
5. 编码
主要内容:将每个模块的控制结构转换成计算机可接受的程序代码。
6. 测试(保证软件质量的重要手段)
主要内容:在设计测试用例的基础上检查软件的各个组成部分。
参与人员:另一部门(或单位)的软件设计师或系统分析师
产生文档:软件测试计划、测试用例、软件测试报告
7. 维护(软件生存周期中时间最长的阶段)
主要内容:软件运行过程中可能由于各方面的原因需要对它进行修改。
5.1.4 软件过程(2个)
1. 能力成熟度模型(CMM)- Capability Maturity Model
成熟度级别 | 主要特点 | |
初始级(Initial) | 杂乱无章、混乱、无明确定义的步骤 | |
可重复级(Repeatable) | 建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性,有必要的过程准则来重复以前在同类项目中的成功。 | |
已定义级(Defined) | 管理和工程方面的软件过程已经文档化、标准化,并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。 | |
已管理级(Managed) | 制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。 | |
优化级(Optimized) | 加强了定量分析,通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。 |
2. 能力成熟度模型集成(CMMI)
是若干过程模型地综合和改进,是支持多个工程学科和领域的、系统的、一致的过程改进框架,能适应现代工程的特点和需要,提高过程的质量和工作效率。提供了两种表示方法:
-- 阶段式模型:结构类似与CMM,关注组织的成熟度。(1)初始的:过程不可预测且缺乏控制。(2)已管理的:过程为项目服务。(3)已定义的:过程为组织服务。(4)定量管理的:过程已度量和控制。(5)优化的:集中于过程改进。
--连续式模型:关注每个过程域的能力,能力等级可以独立地应用于任何单独的过程域,任何一个能力等级都必须满足比它等级低的能力等级的所有准则。6个能力等级有(1)CL0:未完成的。(2)CL1:已执行的。(3)CL2:已管理的。(4)CL3:已定义级的。(5)CL4:定量管理的。(6)CL5:优化的。
5.2 软件过程模型
1. 瀑布模型
将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型,包括需求分析、设计、编码、测试、运行与维护。规定了由前至后、相互衔接的固定次序,如同瀑布流水逐级下落,如图5-2。V模型是瀑布模型的变体,描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。实际上是执行了一系列测试(质量保证活动)。V模型提供了一种将验证确认活动应用于早期软件工程工作的方法。
优点:容易理解,管理成本低,强调开发的阶段性早期计划及需求调查和产品测试。
不足:客户必须能够完整、正确和清晰地表达他们的需要;在开始的两个或3个阶段中,很难评估真正的进度状态;当接近项目结束时,出现了大量的集成和测试工作;直到项目结束之前,都不能演示系统的能力。对项目风险的控制能力较弱。
2. 增量模型
融合了瀑布模型的基本成分和原型实现的迭代特征,假设可以将需求分段为一系列增量产品,每一增量可以分别开发。随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”。第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能,这个过程在每一个增量发布后不断重复,直到产生了最终的完善产品。强调每一个增量均发布一个可操作的产品。
优点:1. 具有瀑布模型的所有优点;2. 第一个可交付版本所需要的成本和时间很少;3. 开发由增量表示的小系统所承担的风险不大;4. 版本发布快,可减少用户需求的变更;5. 运行增量投资(在项目开始时,可以仅对一个或两个增量投资)。
不足:1. 若没有对用户的变更要求进行规划,产生的初始增量可能会造成后来增量的不稳定;2.若需求不稳定和完整,增量可能需要重新开发和发布;3.管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
3. 演化模型
演化模型是迭代的过程模型,适用于对软件需求缺乏准确认识的情况。典型的有原型模型和螺旋模型。
-- 原型模型:1. 适合于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时,采用该方法比较好。2. 不必满足目标软件的所有约束,其目的是能快速、低成本地构建。迅速开发出一个让用户看得见、摸得着的系统框架。3. 原型可分为探索型原型、实验型原型、演化型原型。
-- 螺旋模型:1. 将瀑布模型和演化模型结合起来,加入两种模型均忽略的风险分析,弥补不足。2. 分为四个螺旋周期,制定计划-风险分析-实施工程-用户评估。3. 适用于庞大、复杂且具有高风险的系统。4. 支持用户需求的动态变化,降低软件开发的风险。5. 要求开发人员具有相当丰富的风险评估经验和专门知识。6. 过多的迭代次数会增加开发成本,延迟提交时间。
4. 喷泉模型
以用户需求为动力,以对象作为驱动,适合于面向对象的开发方法,克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。使开发过程具有迭代性和无间隙性。(允许各开发活动交叉、迭代地进行,各阶段没有明显界限)
优点:提高软件项目的开发效率,节省开发时间。
不足:开发过程需要大量的开发人员,不利于项目的管理,且要求严格管理文档,审核难度大。
5. 基于构建的开发模型
6. 形式化方法模型
7. 统一过程(UP)模型
-- 用例和风险驱动,以架构为中心,迭代并且增量。由UML方法和工具支持。定义了4个技术阶段及其制品,并由主要里程碑所终止—— 起始阶段(生命周期目标)、精化阶段(生命周期架构)、构建阶段(初始运作功能)、移交阶段(产品发布)。
-- 典型代表是RUP。RUP是UP的商业扩展,完全兼容UP,但比UP更完整、更详细。
8. 敏捷方法-尽可能早地、持续地对有价值的软件的交付
-- 极限编程(XP):轻量级(敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。
(4大价值观)沟通、简单性、反馈、勇气;(5个原则)快速反馈、简单性假设、逐步修改、提倡更改、优质工作;(12个最佳实)...
-- 水晶法(Crystal):不同的项目需要一套不同的策略、约定、方法论。
-- 并列争求法(Scrum):使用迭代的方法,按需求的优先级别实现产品。
-- 自适应软件开发(ASD):6个基本原则。
-- 敏捷统一过程(AUP):采用“在大型上连续”以及“在小型上迭代”的原理构建软件系统。采用经典的UP阶段性活动(初始、精化、构建和转换),提供一系列活动,使团队为软件项目构想出一个全面的过程流。每个AUP迭代执行建模-实现-测试-部署-配置及项目管理-环境配置6大活动。
5.3 需求分析
1. 软件需求
功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密要求、可靠性要求、软件成本消耗与开发进度需求、其他非功能性要求。
2. 需求分析原则
--