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

1. 2-1 软件过程模型

A. 软件过程(Software Process)

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

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

2. 软件过程的目的

3. 黑盒过程与白盒过程

a) 黑盒存在的问题

b) 白盒优点

软件过程的典型阶段
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)

(2) 优点

i) 应用数学分析方法,歧义性、不完整性、不一致性等问题更容易被发现和改正,目的是“提供无缺陷的软件”

(3) 缺陷

i) 形式化数学方法难以理解,可视性太差,对开发人员技能要求较高

ii) 构造形式化模型是一件非常耗时的工作,成本也很高

iii) 软件系统中的某些方面难以用形式化模型表达出来(如用户界面)

(4) 应用场合

i) 对可靠性和安全性要求较高的一些关键系统,在真正被投入使用之前,需要严格保证100%的正确。传统的方法靠人去验证,难以奏效

ii) 太过于理想化,因此仅停留在理论研究中,实践中很少使用

b) 基于复用的软件过程

(1) 主要思想是复用(reuse

(2) 针对一个新的软件系统,不是完全从一无所有开始入手,而是通过使用已有的软件单元(称为“软构件”)来构造系统

(3) 主要过程

i) 需求分析

ii) 体系结构设计

iii) 构件获取(购买、重新开发)

iv) 构件修改与测试

v) 构件组装

vi) 集成测试;

c) 敏捷过程模型(Agile)

C. 软件过程的典型阶段

1. 1.Dream(提出设想)

2. 2.Investigation(深入调研)

3. 3.Software Specification(需求规格说明)

4. 4.Software Design(软件设计)

5. 5.Software Implementation(软件实现)

6. 6.Software Deployment (软件部署)

7. 7.Software Validation(软件验证)

8. 8.Software Evolution(软件演化)

2. 2-2 敏捷过程与方法

A. 敏捷开发(Agile)

1. 理念:敏捷核心思想;

2. 优秀实践:敏捷的经验积累

3. 具体应用:能够结合自身灵活应用才是真正的敏捷。

4. 本质:以快速的增量和迭代方式进行软件开发

B. 敏捷软件开发宣言

1. 敏捷宣言遵循的原则

a) 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户

b) 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势

c) 要不断交付可用的软件,周期从几周到几个月不等,且越短越好。

d) 项目过程中,业务人员与开发人员必须在一起工作

e) 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。

f) 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈

g) 可用的软件是衡量进度的主要指标

h) 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度

i) 对技术的精益求精以及对设计的不断完善将提升敏捷性。

j) 要做到简洁,即尽最大可能减少不必要的工作,这是一门艺术

k) 最佳的架构、需求和设计出自于自组织的团队

l) 团队要定期反省如何能够做到更有效,并相应地调整团队的行为

2. 归纳
   小步快跑,及时反馈

a) 不强调文档,转向强调可运行的软件片段

b) 开发者与客户之间频繁沟通

c) 快速开发,快速反馈,快速修改, 增量交付

d) 连续不断的短周期迭代

e) 不看重形式和工具,看重“人”和内容,保持简洁。

C. 敏捷过程模型(agile process model)

1. 敏捷方法是一种以人为核心、迭代、循序渐进的增量开发方法。在软件项目的敏捷开发中,软件项目的构建被切分成多个子项目(迭代),每个子项目的成果都经过测试,具备集成和可运行的特征。也就是说,把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

2. 敏捷软件开发的核心—迭代开发
   迭代开发是有节奏的小步快跑,但建立在坚实的质量基础上

a) 迭代开发的关键要点

(1) 每一次迭代都建立在稳定的质量基础上,并做为一下轮迭代的基线,整个系统的功能随着迭代稳定地增长和不断完善;

(2) 每次迭代邀请用户代表(外部或内部)验收,提供需求是否满足的反馈;

(3) 迭代推荐采用固定的周期(一般2-4周),迭代内工作不能完成,应当缩减交付范围而不是延长周期

b) 迭代开发的优势

(1) 通过将高技术风险的需求在早期迭代里实现,有助于尽早暴露问题和及时消除风险

(2) 通过提供功能渐增的产品,持续从客户获得反馈,根据反馈及时调整,使最终产品更加符合客户的需要

(3) 通过小批量减少排队,提供更灵活、快速的交付能力

(4) 平滑人力资源的使用,避免出现人力资源瓶颈

3. 敏捷开发:快速反馈

a) 将项目分成若干个迭代周期,每个迭代周期结束都能立即反馈。通过不断的沟通,还能减少理解上的偏差,配合反馈, 减少误解,从而降低修正错误的代价。且每个迭代周期的结束都能接受验证,从而能快速的适应变化,及时的适应新的需求,保证产品的正确性。

b) 适应变化,利用多层次反馈不断调整以逼近目标

c) 利用多层次反馈手段,在变化的环境中让团队准确地了解与目标的差距,不断调整自身行为,并逐步逼近勒心

4. 敏捷开发:快速交付

a) 适应变化,小批量是快速交付的关键

b) 我们首先要做的是尽量早地、持续地交付有价值的软件来使客户满意。

c) 经常性的交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好

5. 敏捷开发:“客户是逐步发现真正需求”

a) 期望客户一开始就想清楚真正要的东西是不现实的。

b) 我们应当通过不断的向客户交付可用的产品,启发客户逐步发现真正的需求。

6. 对比:敏捷方法 vs 传统方法

a) 敏捷更符合软件开发规律

b) 敏捷对生产率、质量、满意度、成本有明显改进

7. 敏捷过程:细节

8. 敏捷过程中最重要的因素:人

9. 敏捷软件开发典型场景

10. 目前广泛使用的敏捷开发方法论

a) Summary
极限编程XP
SCRUM (Ken Schwaber)

(1) XP & Scrum

(2) Scrum偏重于过程 XP偏重于实践

(3)

(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. 为什么软件需要演化?

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

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

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

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

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

2. 什么是软件演化?

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)

(3) 软件维护的成本

i) 软件的维护成本极其昂贵

(a) 业务应用系统:维护费用与开发成本大体相同

(b) 嵌入式实时系统:维护费用是开发成本的四倍以上

(4) 软件维护的典型困难

i) 软件维护中出现的大部分问题都可归咎于软件规划和开发方法的缺陷

ii) 造成困难的根本原因

(5) 不好的维护所造成的代价

(6) 遗留系统

i) 定义
已经运行了很长时间的、对用户来说很重要的、但是目前已无法完全满足要求却不知道如何处理的软件系统

ii) 特点

(a) 现有维护人员没有参与开发

(b) 不具备现有的开发规范

© 文档不完整,修改记录简略

iii) 更换遗留系统(Legacy System)是有风险的

iv) 变更遗留系统的问题

b) 软件再工程(Software Re-engineering)

(1) 为了修改软件缺陷或增加新的功能而对软件进行的变更

B. 软件配置管理(SCM)

1. 软件配置管理的背景

2. 软件开发过程中面临的困境

3. 缺乏管理所造成的问题

a) 軟件生产达不到规模化u

b) 缺少有效的通信机制

c) 成员间缺少沟通

d) 人员流动

4. 硬件配置

5. 软件配置

a) 由在软件工程过程中产生的所有信息项构成,它可以看作该软件的具体形态(软件配置项)在某一时刻的瞬间影像。

b) 软件配置管理(Software Configuration Management, SCM)

6. 软件配置管理的含义

a) “协调软件开发从而使得混乱减到最小的技术称为软件配置管理。 它是对开发团队正在开发软件的修改进行标识、组织和控制的技术,目的是使错误量降至最低,并使生产率最高。

b) “配置管理能够系统的处理变更,从而使得软件系统可以随时保持其完整性,因此称为 “变更控制”,可以用来评估提出的变更请求,跟踪变更,并保存系统在不同时间的状态。

7. 软件配置管理的特点

a) SCM贯穿整个软件生命周期与软件工程过程

8. 软件配置管理的目标

a) 标识变更

b) 控制变更

c) 确保变更的正确实现

d) 向开发组织内各角色报告变更

e) 总结:当变更发生时,能够提高适应变更的容易程度,并旦能够减少所花费的工作量。

9. SCM的基本元素

a) 配置项(Configuration Item, CI)

(1) 输出信息可以分为三个主要类别
这些项包含了所有在软件过程中产生的信息,总称为软件配置项(SCI
SCI是软件全生命周期内受管理和控制的基本单位, 大到整个系统,小到某个硬件设备或软件模块
SCI具有唯一的名称标识和多个属性

i) 计算机程序(源代码和可执行程序)

ii) 描述计算机程序的文档(针对技术开发者和用户)

iii) 数据(包含在程序内部或外部)

(2) 配置项之间的依赖关系

i) 整体-部分关系

ii) 关联关系

(3) 配置项的演变图

b) 基线(Baseline)
已经通过正式评审和批准的软件规格说明或代码, 它可以作为进一步开发的基础,并且只有通过正式的变更规程才能修改它

(1) 在软件配置项成为基线之前,可以迅速而随意的进行变更

(2) 一旦成为基线,变更时需要遵循正式的评审流程才可以变更

(3) 因此,基线可看作是软件开发过程中的“里程碑”

c) 配置管理数据库(CMDB)

(1) 配置管理数据库(CMDB)(也称“SCM中心存储库”),用于保存与软件相关的所有配置项的信息以及配置项之间关系的数据库。

(2) CMDB的功能

i) 存储配置项及其之间的关系

ii) 版本控制

iii) 相关性跟踪和变更管理

iv) 需求跟踪

v) 配置管理

vi) 审核跟踪

d) 备件库(Definitive Hardware Store, DHS)

e) 最终软件库(Definitive Software Library, DSL)

10. SCM总结

C. 持续集成

1. 敏捷开发的一项重要实践

2. 价值

3.