软件工程-第2章复习总结

1. 2-1 软件过程模型

A. 软件过程(Software Process)

是指软件生命周期所涉及的一系列相关过程,由关于软件项目的阶段、状态、方法、技术和开发、维护软件的人员以及相关Artifacts(计划、文档、模型、编码、测试、手册等)组成。是软件整个生命周期中从需求获取，需求分析，设计，实现，测试，发布和维护一个过程模型。软件过程不仅涉及工程开发，而且还涉 及工程支持和工程管理。

1. 软件过程定义以下内容

3. 黑盒过程与白盒过程

a) 黑盒存在的问题

软件过程的典型阶段
1.Dream(提出设想)
2.Investigation(深入调研)
3.Software Specification(需求规格说明)
4.Software Design(软件设计)
5.Software Implementation(软件实现)
6.Software Deployment (软件部署)
7.Software Validation(软件验证)
8.Software Evolution(软件演化

B. 典型的软件过程模型

1. 瀑布模型
   是软件开发的系统化的、顺序的方法
   也叫做鲑鱼模型(salmonmodel》:向前一阶段回溯,很难,
   特点： ?上一个阶段结束,下一个阶段才能开始; ?每个阶段均有里程碑和提交物; ?上一阶段的输出是下一阶段的输入; ?每个阶段均需要进行V&V; ?侧重于文档与产出物;

a) 优点——
追求效率

(1) 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导;

(2) 简单、易懂、易用、快速;

(3) 为项目提供了按阶段划分的检查点,项目管理比较容易;每个阶段必须提供文档,而且要求每个阶段的所有产品必须进行正式、严格的技术审查。

b) 缺点——
过于理想化

(1) 实际的项目大部分情况难以按照该模型给出的顺序进行,而且这种模型的迭代是间接的,很容易由微小的变化而造成大的混乱。

(2) 经常情况下,客户难以表达真正的需求,而这种模型却要求如此,这种模型是不欢迎具有二义性问题存在的。

(3) 客户要等到开发周期的晚期才能看到程序运行的测试版本,而在这时发现大的错误时,可能引起客户的惊慌,而后果也可能是灾难性的。

(4) 采用这种线性模型,会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去,有可能花在等待的时间比开发的时间要长。称之为“堵赛状态”

2. 增量过程模型

a) 增量模型 (Incremental)
增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。

(1) 软件被作为一系列的增量来设计、实现、集成和测试,每一个增量是由多种相互作用的模块所形成的提供功能的代码片段构成。

(2) 本质:以迭代的方式运用瀑布模型

i) 第一个增量往往是核心产品:满足了基本的需求,但是缺少附加的特性;

ii) 客户使用上一个增量的提交物并进行自己评价,制定下一个增量计划,说明需要增加的特性和功能;

iii) 重复上述过程,直到最终产品产生为止

(3) 优点

i) 在时间要求较高的情况下交付产品:在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品,对客户起到“镇静剂”的作用;

ii) 人员分配灵活:如果找不到足够的开发人员,可采用增量模型:早期的增量由少量人员实现,如果客户反响较好,则在下一个增量中投入更多的人力

iii) 逐步增加产品功能可以使用户有较充裕的时间来学习和适应新产品,避免全新软件可能带来的冲击

iv) 因为具有较高优先权的模块被首先交付,而后面的增量也不断被集成进来,这使得最重要的功能肯定接受了最多的测试, 从而使得项目总体性失败的风险比较低

(4) 困难

i) 每个附加的增量并入现有的软件时,必须不破坏原来已构造好的东西

ii) 同时,加入新增量时应简单、方便 ——该类软件的体系结构应当是开放的

iii) 管理人员须有足够的技术能力来协调好各增量之间的关系;

iv) 但是,仍然无法处理需求发生变更的情况

b) 快速应用开发RAD (Rapid Application Development)
侧重于短开发周期(一般为60~90天)的增量过程模型,是瀑布模型的高速变体,通过基于构件的构建方法实现快速开发
多个团队并行进行开发,但启动时间有先后,先启动团队的提交物将作为后启动团队的输入

(1) 缺点

i) 需要大量的人力资源来创建多个相对独立的RAD团队;

ii) 如果没有在短时间内为急速完成整个系统做好准备,RAD项目将会失败

iii) 如果系统不能被合理的模块化,RAD将会带来很多问题

iv) 技术风险很高的情况下(采用很多新技术、软件需要与其他已有软件建立集成、等等),不宜采用RAD

3. 演化过程模型 (Evolutionary model)
   软件系统会随着时间的推移而发生变化,在开发过程中,需求经常发生变化,直接导致产品难以实现; 严格的交付时间使得开发团队不可能圆满完成软件产品,但是必须交付功能有限的版本以应对竞争或压力; 很好的理解和核心产品与系统需求,但对其他扩展的细节问题却没有定义。 在上述情况下,需要一种专门应对不断演变的软件过程模型, 即“演化过程模型”。

a) 螺旋模型 (Spiral)

(1) 螺旋模型沿着螺线旋转,在四个象限内表达四个方面的活动

i) 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制;

ii) 风险分析:分析所选方案,考虑如何识别和消除风险

iii) 实施工程:实施软件开发

iv) 客户评估:评价开发工作,提出修正建议

(2) 出发点

i) 开发过程中及时识别和分析风险,并采取适当措施以消除或减少风险来的危害

(3) 优点
结合了原型的迭代性质与瀑布模型的系统性和可控性,是一种风险驱动型的过程模型

i) 采用循环的方式逐步加深系统定义和实现的深度,同时更好的理解、应对和降低风险

ii) 确定一系列里程碑,确保各方都得到可行的系统解决方案

iii) 始终保持可操作性,直到软件生命周期的结束

iv) 由风险驱动,支持现有软件的复用

(4) 缺陷

i) 适用于大规模软件项目,特别是内部项目,周期长、成本高

ii) 软件开发人员应该擅长寻找可能的风险,准确的分析风险,否则将会带来更大的风险

b) 原型模型 (Prototype)

(1) Throwaway prototyping(抛弃式原型)

(2) Evolutionary prototyping(演化式原型)

(3) 优点:

i) 提高和改善客户/用户的参与程度,最大程度的响应用户需求的变化

(4) 缺点

i) 为了尽快完成原型,开发者没有考虑整体软件的质量和长期的可维护性,系统结构通常较差

ii) 可能混淆原型系统与最终系统,原型系统在完全满足用户需求之后可能会被直接交付给客户使用

iii) 额外的开发费用

(5) 快速原型法的步骤
Step 1：双方通过沟通，明确已知的需求，并大致勾画出以后 再进一步定义的东西。
Step 2：迅速策划一个原型开发迭代并进行建模，主要集中于 那些最终用户所能够看到的方面，如人机接口布局或者输出 显示格式等；
Step 3：快速设计产生原型，对原型进行部署，由客户和用户 进行评价；
Step 4：根据反馈，进一步细化需求并调整原型；
Step 5：原型系统不断调整以逼近用户需求
c) 本质:循环、反复、不断调整当前系统以适应需求变化

d) 演化过程模型的目的

(1) 需求的变更频繁,要求在非常短的期限内实现,以充分满足客户/用户要求、及时投入市场

e) 存在的问题

(1) 由于构建产品所需的周期数据不确定,给项目管理带来困难

(2) 演化速度太快,项目陷入混乱;演化速度太慢,影响生产率

(3) 为追求软件的高质量而牺牲了开发速度、灵活性和可扩展性

4. 其他过程模型

a) 形式化过程 (Formal model)
使用严格的数学形式来刻画每一阶段的产物(需求、设计、程序、测试)
应用一系列形式化方法在各阶段的产物之间进行自动/半自动的转换

(1)

(4) 敏捷软件开发是以短周期迭代为核心,包含团队、工作件、管理和技术优秀实践的集合

(5) 对敏捷常见的误解

i) 误解一:敏捷开发意味着可以不需要文档、设计和计划

ii) 误解二:敏捷只是一些优秀实践,或者是优秀实践的结合

iii) 误解三:敏捷只适合于小项目开发;

iv) 误解四:敏捷只会对研发产生改变;

v) 误解五:管理者不需要亲自了解敏捷,只需要管理上支持就可以了;

vi) 误解六:引入敏捷只需要按照既定的步骤做就可以了

vii) 误解七:敏捷是CMM的替代品,是另一种流程;

viii) 误解八:敏捷只注重特性的快速交付,在敏捷下架构不重要了

b) 极限编程XP
XP (eXtreme Programming) (Kent Beck)

(1) 一种最广泛应用的敏捷开发方法

(2) XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法,开发人员和客户可以非常清楚地发现进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程

(3) 极限编程是一个轻量级的、灵巧的软件开发方法

(4) 极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性;

(5) 降低因需求变更而带来的成本

(6) 极限编程XP (eXtreme Programming)的特点

i) 增量和反复式的开发—-一次小的改进跟着一个小的改进

ii) 反复性,通常是自动重复的单元测试,回归测试

iii) 结对程序设计和开发

iv) 在程序设计团队中与用户交互(在场的客户)

v) 软件重构

vi) 共享的代码所有权

vii) 简洁

viii) 反馈

ix) 可以忍受的速度

(7) 极限编程的核心价值

i) 沟通(Communication)、简单(Simplicity)、反馈(Feedback)、勇气(Courage)、尊重(Respect)

(8) XP的核心实践方法

i) XP Planning:计划阶段

ii) XP Design:设计阶段

iii) XP Coding & Testing:编码与测试阶段

(a) 结对编程(Pair Programming)
结对编程的优点：每人在各自独立设计、实现软件的过程中不 免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流， 程序各方面的质量取决于一对程序员中各方面水平较高的那一位。 这样，程序中的错误就会少得多，程序的初始质量会高很多，这样 会省下很多以后修改、测试的时间。
– 在开发层面，结对编程能提供更好的设计质量和代码质量，两人合 作能有更强的解决问题的能力。
– 对开发人员自身来说，结对工作能带来更多的信心，高质量的产出 能带来更高的满足感。
– 在心理上, 当有另一个人在你身边和你紧密配合，做同样一件事情 的时候, 你不好意思开小差, 也不好意思糊弄。
– 在企业管理层面，结对能更有效地交流，相互学习和传递经验，能 更好地处理人员流动。因为一个人的知识已经被其他人共享
c) SCRUM (Ken Schwaber)
敏捷过程模型的典型代表:Scrum

(1) 整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint(冲刺),每个Sprint的建议长度是2到4周。

(2) scrum的四个重要阶段

i) 找出完成产品需要做的事情

ii) 决定当前的冲刺需要解决的事情

iii) 冲刺Sprint

iv) 每日站会

(3) Scrum中的角色

i) Summary
是为了保护“猪”这种角色,兼顾“鸡”的感受,从而确保整个项目正常交付
产品负责人 Product Owner
Scrum Master
Scrum团队
利益相关者(客户,提供商)
经理

ii) 产品负责人 Product Owner

iii) Scrum Master

iv) Scrum团队

v) 利益相关者(客户,提供商)

vi) 经理

(4) Scrum的三个工件

i) 产品列表 Product Backlog

(a) 根据用户价值进行优先级排序的高层需求

ii) 产品列表 Product Backlog

(a) 要在冲刺中完成的任务的清单

iii) 产品增量 Increment

(a) 最终交付给客户的内容

(5) Scrum中的六项活动

i) 冲刺 Sprint

ii) 发布计划会议(Release Planning Meeting)

iii) 计划会 Sprint Planning Meeting

(a) 每个冲刺之初,由产品负责人讲解需求,并由团队负责人进行估算

iv) 每日立会 Daily Standup Meeting

(a) 团队成员站着开会

(b) 强迫每个人向同伴报告进度, 迫使大家把问题摆在明面上:

? 启动每日构建

(d) 用简明的图表展现整个项目的进度,这个图最好放在大家工作的环境中,或者每天传达给各个成员

i) 任务墙(Task Board)

ii) Sprint Burndown Chart(燃尽图)

v) 评审会 Review Meeting

vi) 反思会/回顾会 Retrospective Meeting

D. 软件开发过程模型的比较

1. 瀑布模型:将全部需求以整体方式向前推进,无迭代;——基本模型

2. 增量模型:将需求分成多份,串行推进,无迭代;——串行的瀑布

3. RAD模型:将需求分成多份,并行推进,无迭代; ——并行的瀑布

4. 原型模型:迭代; ——基本模型

5. 螺旋模型:按瀑布阶段划分,各阶段分别迭代(原型+风险分析); ——原型+瀑布

6. 敏捷模型:将需求分成尽量小的碎片,以碎片为单位进行高速迭代。 ——增量+迭代

3. 2-3 软件项目管理

A. 若干基本概念

1. 项目(Project

a) 为创建某种特定的产品或服务而组织或设计的临时的、一次性的行动,通过执行一组活动,使用受约束的资源(资金、人、原料、能源、空间等)来满足预定义的目标。

2. 项目管理(Project Management, PM

a) 有效的组织与管理各类资源(例如人),以使项目能够在预定的范围、质量、时间和成本等约束条件下顺利交付(deliver)。

3. 软件项目的特征

a) 软件产品的不可见性

b) 项目的高度不确定性

c) 软件过程的多变化性

d) 软件人员的高技能及其高流动性

B. 项目管理在限定的资源和时间内涉及的关键因素

1. 人员

a) 产品经理 项目经理
项目(技术)管理者:计划、激励、组织和控制软件开发人员;
高级管理者:负责定义业务问题

b) 高级管理者:负责定义业务问题

c) 项目(技术)管理者:计划、激励、组织和控制软件开发人员;

d) 开发人员:拥有开发软件所需技能的人员

(1) 系统分析员;系统架构师;设计师;程序员;测试人员;质量保证人员

e) 客户:进行投资、详细描述待开发软件需求、关心项目成败的组织/人员

f) 最终用户:一旦软件发布成为产品,最终用户就是直接使用软件的人。

g) 软件开发团队的组织方式

(1) 一窝蜂模式 (chaos team):没有明确分工,存活的时间一般都不长。

(2) 主治医师模式: (Chief-Programmer Team, surgical team)

i) 手术台上,有一个主刀医师,其他人 (麻醉、护士、器械) 各司其职,为主刀医师服务。

ii) 首席程序员 (Chief-programmer) 处理主要模块的设计和编码,其他成员从各种角度支持他的工作 (backup programmer, admin, tool-smith, specialist

iii) 主治医师模式的退化: 学校里,软件工程的团队模式往往退化为“一个学生干活, 其余学生跟着打酱油”

iv) 明星模式 (Super-star model)

(3) 社区模式 (Community Model):

i) 由很多志愿者参与,每个人参与自己感兴趣的项目,贡献力量

ii) “社区” 并不意味着“随意”, 一些成功的社区项目(例如开发和维护Linux 操作系统的社区)都有很严格的代码复审和签入的质量控制

iii) 开源社区(Open Source Project

iv) 好处是“众人拾柴火焰高”, 但是如果大家都只来烤火, 不去拾柴; 或者捡到的柴火质量太差, 最后火也熄灭了

(4) 交响乐团模式 (Orchestra)

i) 人多,门类齐全,各司其职,各自有专门场地,演奏期间严格遵循纪律

ii) 演奏靠指挥协调,各自遵循曲谱(工作流程)

iii) 演奏的都是练习过多次的曲目,重在执行

iv) 类似于“工厂”,严格遵循预订的生产流程,“规格严格”

(5) 爵士乐模式 (Jazz Band)

i) 演奏时没有谱子,没有现场指挥,平时有arranger(编曲)起到协调和指导作用

ii) 模式:主乐手先吹出主题,其余人员根据这个主题各自即兴发挥;主乐手最后再加入,回应主题,像是对曲子的总结

iii) 强调个性化的表达,强有力的互动, 对变化的内容有创意的回应”

iv) 类似于一群天才构成的敏捷团队, “功夫到家”,率性而为。

(6) 功能团队模式 (feature team)

i) 具备不同能力的同事平等协作,共同完成一个项目开发;

ii) 在这个项目完成之后, 这些人又重新组织,和别的角色一起去完成下一个功能, 他们之间没有管理和被管理的关系。

(7) 官僚模式 (bureaucratic model)

i) 成员之间不光有技术方面的合作和领导,同时还混进了组织上的领导和被领导关系,跨组织的合作变得比较困难。

2. 过程

a) Step 1: 选择合适的软件过程模型

(1) 存在多种过程模型

(2) 各过程模型适用不同类型的软件项目

b) Step 2: 根据所选的过程模型,对其进行适应性修改

c) Step 3: 确定过程中应包含的工作任务列表

d) 工作分解结构(WBS

(1) 项目管理里通常使用“工作结构分解(Work Breakdown Structure, WBS)”作为过程分解的工具

(2) WBS:通过分层的树型结构来定义和组织工作任务之间的分解关系,自顶向下,逐级细分;

3. 产品

a) 软件产品是指向用户提供的计算机软件、信息系统或设备中嵌入的软件或在提供计算机信息系统集成、应用服务等技术服务时提供的计算机软件。

b) 软件产品、产品分解结构(PBS)

(1) PBS:通过分层的树型结构来定义和组织项目范围内的所有产出物(产品),自顶向下,逐级细分;

(2) 产出物:项目结束时需要提交的最终产品,在项目之初就可以准确的预计

(3) 产品分解结构(PBS)是通过树状结构反映产品的各类部件,每类部件在结构中仅出现一次

4. 工具

C. 项目（project ）

1. 项目关注的四个方面

a) 范围(Scope)

b) 时间(Time

c) 成本(Cost)

d) 质量(Quality)

2. 项目管理的主要任务

a) 项目可行性分析与估算

b) 项目进度安排

c) 项目风险管理

d) 项目质量管理

e) 项目跟踪与控制

3. W5HH原则

D. 可行性分析与估算

1. 可行性分析与估算

a) 在项目开始之前,必须预先估计三件事情

(1) 需要多少工作量

(2) 需要多少时间

(3) 需要多少人员

b) 此外,还必须预测所需要的资源(硬件和软件)以及蕴含的风险;

2. 确定范围

a) 范围(Scope)
描述了将要交付给最终用户的功能和特性、输入输出数据、用户界面、系统的性能、约束条件、接口和可靠性等,以及期望的时间、成本目标;

b) 两种方法

(1) 与所有项目成员交流之后,写出对软件范围的叙述性描述;

(2) 用户签字确认

(3) 由最终用户开发一组用例

c) 注意

(1) 并不是客户所有的需求都“来者不拒”,需要分别对待

3. 可行性分析

a) 技术可行性:

b) 经济可行性

c) 时间可行性

d) 资源可行性

4. 软件项目估算

a) 到目前为止,因为变化的要素太多,所以对软件的估算从来没有达到精确。

b) 但是,估计得越精确,项目成功的可能性就越高。

c) 方法:

E. 项目进度计划与监控

1. 项目进度计划

a) 是指在确保合同工期和主要里程碑时间的前提下,对设计、采办和施工的各项作业进行时间和逻辑上的合理安排,以达到合理利用资源、降低费用支出和减少施工干扰的目的。

2. 绘制任务进度安排图

a) 项目管理里通常采用甘特图(Gantt Chart)来描述任务的进度安排。

3. 资源、产出与里程碑

a) 将资源(resources)分配给任务

b) 明确产出结果(outcomes)

c) 明确里程碑(milestones)

4. 项目进度跟踪

a) 项目进度表只是提供了一张进度路线图,在实际执行过程中,需要定期对其进行跟踪和控制,以决定是否需要对进度计划进行调整。

5. XP/Scrum敏捷开发中的进度计划与监控

4. 2-4 软件演化与配置管理

A. 软件演化

1. 为什么软件需要演化/li>

a) 软件在使用过程中,新的需求不断出现

b) 商业环境在不断地变化

c) 软件中的缺陷需要进行修复

d) 计算机硬件和软件环境的升级需要更新现有的系统

e) 软件的性能和可靠性需要进一步改进

2. 什么是软件演化/li>

a) 软件演化:是指在软件生命周期内进行系统维护和系统更新的动态行为,修正和改善软件进入使用期后暴露出的问题,以适应需求等的不断变化。

3. 软件演化的Lehman定律

a) 持续变化(continuing change)

b) 复杂度逐渐增大(increasing complexity)

c) 软件演化的核心问题是:如何使软件系统适应外界的变化,软件演化过程是软件演化和软件过程的统一。

4. 软件演化的处理策略

a) 软件维护(Software Maintenance)
为了避免软件退化而对软件的一部分进行重新设计、编码和测试,提高软件的可维护性和可靠性等
软件变更通常发生在局部,不会改变整个结构

(1) (ANSI/IEEE)
在软件产品发行和被投入运行使用之后对其的修改,以改正错误,改善性能或其他属性,从而使产品适应新的环境或新的需求

(2) 软件维护的类型

i) 纠错性维护:修改软件中的缺陷或不足

(a) 在软件交付使用后,因开发时测试的不彻底、不完全,必然会有部分隐藏的错误遗留到运行阶段。

(b) 这些隐藏下来的错误在某些特定的使用环境下就会暴露出来

? 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用,应当进行的诊断和改正错误的过程就叫做改正性维护。

ii) 适应性维护:修改软件使其适应不同的操作环境,包括硬件变化、操作系统变化或者其他支持软件变化等

(a) 在使用过程中,外部环境(新的硬、软件配置)和数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)可能发生变化。

(b) 为使软件适应这种变化,而去修改软件的过程就叫做适应性维护。

iii) 完善性维护:增加或修改系统的功能,使其适应业务的变化

(a) 在软件的使用过程中,用户往往会对软件提出新的功能与性能要求。

(b) 为了满足这些要求,需要修改或再开发软件,以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性

? 这种情况下进行的维护活动叫做完善性维护

iv) 预防性维护:为减少或避免以后可能需要的前三类维护而提前对软件进行的修改工作

(a) 为了提高软件的可维护性、可靠性等,为以后进一步改进软件打下良好基础。

(b) 定义为“采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编制和测试”

v) 实践表明,在几种维护活动中,完善性维护所占的比重最大,即大部分维护工作是改变和加强软件,而不是纠错

(a) 软件维护活动所花费的工作占整个生存期工作量的70%以上

(b)

来源：S焱殿下