导图社区 软件项目管理
- 53
- 2
- 0
- 举报
软件项目管理
自考专科“软件项目管理”课程代码01336教学大纲，软件项目是以软件为产品的项目，软件产品的特质决定了软件项目管理和其他领域的项目管理有不同之处。
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材，使用前请自行确认授权范围。
- 教学大纲
- 相似推荐
- 大纲
软件项目管理
第一章 软件项目管理导论
一、软件项目(重点)
定义
软件项目是以软件为产品的项目，软件产品的特质决定了软件项目管理和其他领域的项目管理有不同之处
特征
抽象性
缺陷检测的困难性
高度的复杂性
缺乏统一规则
二、软件项目管理（重点）
概念
在软件项目活动中运用一系列知识、技能、工具和技术，以满足软件需求方的整体需求
知识体系
集成管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理
主要内容
1、需求管理
2、结算与进度管理
3、配置管理
4、风险管理
5、质量管理
6、资源管理
过程
1.启动软件项目
2.制定项目计划
3.跟踪及控制项目计划
4.项目计划
5.评审项目计划
6.编写管理文档
特征
综合性、创造性、时间性
6 要素
范围、时间、成本、质量、组织、客户满意度
生命周期
项目从开始到结束，一般包括启动阶段、计划阶段、实施阶段、和结束阶段
三、软件工程框架（次重点）
目标
生产正确、可用及具有经济效益的产品
正确性指软件产品达到预期功能的程度
可用性指软件基本结构、实现和文档为用户可用的程度。
具有经济效益指软件开发、运行的整个开销满足用户要求的程度。
活动
生产一个最终满足需求且达到工程目标的软件产品所需要的步骤
1、问题定义
2、可行性研究
3、需求分析
4、总体设计
5、详细设计
6、实现
7、确认
8、支持
原则
选取适宜的开发模型
采用合适的设计方法
提供高质量的工程支持
重视开发过程的管理
软件工程模型
是组织软件工程活动的方法
用一定的流程将各个活动连接起来
用规范的方式操作全过程
如同工厂的生产线
常见的软件工程模型
线性模型
快速原型模型
螺旋模型
渐增式模型
第二章 软件项目需求管理
一、概念（次重点）
定义
需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等。
需求是指明必须实现什么的规格说明，它描述了系统的行为、特性或属性
需求是在开发过程中对系统的约束。
需求层次
从问题求解过程来看
1、原始问题描述
2、用户需求
3、系统需求
4、软件设计描述
二、需求开发（重点）
四个阶段
需求获取
编写前景
确定需求开发过程用户群分类选择产品代表
确定用例
联系会议
分析用户工作流程确定质量属性检查问题报告
需求重用
需求分析
绘制关联图
创建开发原型分析可行性确定需求优先级为需求建立模型
编写数据字典应用质量功能调配
规格说明
采用软件需求规格说明模板指明需求来源为每项需求注上标号记录业务范围创建需求跟踪能力矩阵
需求验证
确定系统合格的验收标准
需求验证步骤
1.审查需求文档
2.依据需求文档编写测试用例
3.编写用户手册
4.确定产品验收合格的标准
需求验证的内容
1. 有效性
2. 一致性
3. 完备性
4. 现实性
5. 可检验性
6. 可跟踪性
7. 可调节性
8. 可读性
规格说明书SRS
Software Requirement Specification
功能规格说明
需求协议
系统规格说明
基本含义
精确地阐述了一个软件系统必须提供的
功能
性能
所要考虑的限制条件
是对外部行为和系统环境接口的描述性文档
系统环境
软件
硬件
通信端口
人
三、需求管理（重点）
目标
使软件需求受控，并建立供软件工程和管理使用的需求基线
使软件计划、产品和活动与软件需求保持一致
原则
1. 需求一定要分类管理
2. 需求必须分优先级
3. 需求必须文档化
4. 需求一旦变化，就必须对需求变更的影响进行评估。
5. 需求管理必须与需求工程的其他活动紧密整合。
活动
变更控制 建议需求变更并分析其影响,作出是否变更的决策
版本控制 确定单个需求和 SRS的版本
需求跟踪 定义对于其他需求及系统元素的联系链
需求状态 定义并跟踪需求的状态
变更
建立变更控制委员会
变更委员会是一个承担软件项目风险的小组，负责需求变更的管理工作，需求变更的一切最终裁决都由其完成。
变更
变更描述
始于一个被识别的需求问题或是一份明确的变更提议。
在这个阶段，要对问题或变更提议进行分析，以检查它的有效性，进而产生一个更明确的需求变更提议。
变更分析
要对被提议的变更产生的影响进行评估。
变更成本的计算不仅要估计对需求文档的修改,在适当的时候还要估计系统设计和实现的成本。
一旦分析完成，就有了对此变更是否接受的决策意见。
变更实现
一旦在变更分析阶段得到了肯定的结论，即要接受变更，变更实现阶段就开始了。
实现变更时，需求文档及系统设计和实现都要进行修改。
四、软件需求质量评价（一般）
质量度量9元素
1. 正确性
2. 无歧义
3. 完备性
4. 一致性
5. 根据重要性和稳定性分级
6. 可验证性
7. 可修改性
8. 可跟踪性
9. 可理解性。
第三章 软件项目成本管理
一、软件项目成本估算的概念(次重点)
项目规模
即软件的程序量。软件规模是软件成本的主要影响因素，对软件规模的估计要从软件的分解开始。
成本的度量单位
为完成·项目而支付的货币量
概念
准确定义项目范围、估算项目、支出等工作，并在项目过程中通过一系列监控手段和方法努力减少和控制成本费用支出
PERT 估计
计划评审技术（Program Evaluation and Review Technique,PERT）
是20世纪50年代末美国海军部开发北极星潜艇系统时为协调3000多个承包商和研究机构而开发的，是用于项目进度规划的一种技术。其理论基础是假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。PERT可以估计整个项目在某个时间内完成的概率。后来，学者们将其引入到软件规模估计的应用中来。
计划评审技术（PERT）可以估计整个项目在某个时间内完成的概率。多应用于研究与开发项目，更注重对各项工作安排的评价和审查。
二、软件项目成本估算的方法(重点)
常用的成本估算方法
专家判定
专家判定就是与一位或多位专家商讨，专家根据自己的经验和对项目的理解对项目成本做出估算，由于单独一位专家可能会产生偏差，因此最好由多位家进行估算。
类比法
类比法就是把当前项目和以前做过的类似项目比较，通过比较获得其工作量的估算值该方法需要软件开发组织保留有以往完成项目的历史记录。
自顶向下
自顶向下的估算方法从软件项目的整体出发，即根据将要开发的软件项目的总体等性，结合以前完成项目积累的经验，推算出项目的总体成本或工作量，然后按比例分配到各个组成部分中去。
自底向上
自底向上估算把待开发的软件逐步细化，直到能明确工作量，由负责该部分的人给出工作量的估算值，然后把所有部分相加，就得到了软件开发的总工作量。
算法模型
根据模型中变量的依存关系，可把模型分为静态模型和动态模型，在静态模型中，用个唯一的变量（如程序规模）作为初始元素来计算所有其他变量（如成本、时间），且所用计算公式的形式对于所有变量都是相同的，在动态模型中，没有类似静态模型中的唯一基础变量，所有变量都是相互依存的。
三、软件项目成本监控(重点)
含义
软件项目成本监控包括定期的项目成本统计、核算、监控预算完成情况，偏差分析和预算调整
赢得值分析法
赢得值（Earoed Value，也称挣值或盈余值）分析法是一种能全面衡量项目成本、进度的整体方法，以资金已经转化为项目成果的量来衡量，是一种完整和有效的项目监控指标和方法
（1）累计计划成本额或称计划投资额（Budgeted Cost of Work Scheduled，BCWS）
（2）赢得值或完成投资额（Budgeted Cost of Work Performed，BCWP）
（3）实际成本额（Actual Cost of Work Performed，ACWP）。
第四章 软件项目进度管理
一、软件项目进度管理过程（次重点）
基本概念
项目活动定义即是进一步定义项目范围，该工作成果即是督促项目团队制订更加详细的WBS(83)和辅助解释。该过程的目标是确保项目团队对他们作为项目范围中必须完成的所有工作有一个完整的理解。
项目活动之间的几种关系
强制依赖关系，项目工作固有的特性，有时也被称为硬逻辑关系，如编码完成后才能进行测试。
自由依赖关系，如项目团队内部制定的开发模式为瀑布模型，即只有需求分析全部结束后才能开始系统设计，但由于这种关系可能带来副作用，因此项目组在制订相应规范时应注意项目待征。
外部依赖关系，项目与非项目活动之间的关系，如软件项目的交付上线可能会依赖客户环境准备情况。
二、网络图（重点）
概念
用网络分析方法编制的进度计划称为网络图，是20世纪50年代末发展起来的、一种编制大型工程进度计划的有效方法；是用来计算活动时间和表达进度计划的管理工具，是一种显示活动顺序的技术，它用图形直观地显示项目各项活动之间的逻辑关系和排序，网络图有节点型网络图（单代号网络图）和箭线型网络（双代号网络图）两种基本类型。
网络图的绘制
关键路径
在网络图中，从发点开始，按照各个任务的顺序，连续不断地到达收点的一条通路称为路径。
关键路径：在各条路径上，完成各个任务的时间之和是不完全相等的。其中，完成各个任务需要时间最长的路径称为关键路径。
网络优化
对给定的软件项目绘制网络图，就得到一个初始的的进度计划方案。但通常还要对初始计划方案进行调整和完善，确定最优计划方案。
(1)时间优化 根据对计划进度的要求，缩短项目完成时间，有如下两种方式： 采取技术措施，缩短关键任务的持续时间。 采取组织措施，充分利用非关键任务的总时差，合理调配技术力量及人、财、物等资源，缩短 关键任务的持续时间。
(2)时间一费用优化 时间一费用优化所要解决的问题，是在编制网络计划过程中，研究如何使项目交付时间短，费 用少；或者在保证既定交付时间的条件下，所需的费用最少；或者在限制费用的条件下，交付时间 最短。在进行时间一费用优化时，需要计算在采取各种技术组织措施之后，项目不同的交付时间所 对应的总费用。使项目费用最低的交付时间称为最低成本日程。编制网络计划，无论是以降低费用 为主要目标，还是以缩短项目交付时间为主要目标，都要计算最低成本日程，以提出时间一费用的 优化方案。网络优化的思路与方法应贯穿网络计划的编制、调整与执行的全过程。
三、甘特图（重点）
定义
甘特图（Gantt Chort）又称横道图，是各种任务活动与日历的对照图。
表示方法
它用水平线段来表示任务的工作阶段，其中线段的长度表示完成任务所需要的时间，起点和终点分别表示任务的开始和结束时间。
运用甘特图表示项目进度
四、项目历时估计（重点）
工期估算的方法
（1）专家评审形式，由经验丰富的专业人员进行分析和评估。
（2）模拟估算，使用以前类似的活动作为未来活动工期的估算基础，计算评估工期。
（3）定量型的基础工期，当产品可以用定量标准计算工期时，则采用计量单位为基础数据整体估 算。
（4）保留时间，在工期估算中预留定比例的冗余时间以应付项目风险。随着项目的进展，冗余时 间可以逐步减少。
应用 PERT 估算项目历时
1）、系统任务分解;
2）、估算任务完成时间;
3）、估算项目历时;
4）、根据上面的结果，可以得出正态分布曲线;
5）、案例总结: 实际大型项目的历时估算和进度控制非常复杂，往往需要将CPM和PERT结合使用，用CPM求出关键路径，再对关键路径上的各个任务用PERT估算完成期望和标准差，最后得出项目在某一时间段内完成的概率。
步骤
将系统分解为几个主要的活动，然后给出下列三个数据
a：完成活动最少需要时间 m：完成活动最可能时间 b：完成活动做多需要时间
计算每个活动的期望完成时间和标准差
期望时间计算公式：T=(a+4m+b)/6
标准差公式：(b-a)/6
最终期望时间：每个活动的期望时间相加
最终标准差：每个活动的标准差开平方之和的二分之一次幂
例：（1.33^2+0.67^2+3.67^2+1.67^2）^1/2
五、编制软件项目进度计划（重点）
基本步骤
（1）项目的目标，用来描述做什么，为谁做，何时做，以及项目成功结束的标准。
（2）WBS把项目分解为可直接操作的元素。
（3）资源配置是根据经验和相应的规则，确定各部分需要的资源。
（4）进度安排是根据资源配置情况和项目的实际背景，制订项目的进度。
第五章 软件项目风险管理
一、概述（重点）
风险概念
风险是损失的可能性
属性
可能性
损失
风险管理的概念
是一种涉及社会科学、工程技术、系统科学和管理科学的综合性多学科管理手段
它是涵盖风险识别、分析、计划、监督与控制等活动的系统过程
是一项实现项目目标机会最大化与损失最小化的过程
风险管理的意义
1）、通过风险管理可以使决策更科学，从总体上减少项目风险，保证项目目标的实现。
2）、通过风险识别，可加深对项目和风险的认识和理解，分析各个方案的利弊，了解风险对 项目的影响，以便减少或分散风险。
3）、通过风险分析提升项目计划的可信度，改善项目执行组织内部和外部之间的沟通。
4）、使编制的应急反应计划更有针对性。
5）、能够将处理风险的各种方式有效组织起来，在项目管理中增加主动。
6）、为以后的规划与设计工作提供反馈，以便采取措施防止与避免风险造成的损失。
7）、为制订项目应急计划提供依据；有利于抓住与利用机会。
8）、可推动项目管理层和项目组织积累风险资料，以便改进将来的项目管理方式和方法。
软件风险的类型
1)、人力资源风险;
2)、需求风险;
3)、项目接口风险;
4)、设计风险;
5)、管理风险；
6)、开发过程风险；
7)、项目集成与测试风险。
二、风险识别（重点）
概念
风险识别，是寻找可能影响项目的风险以及确认风险特性的过程。
风险识别活动的参加人员
项目组成员
风险管理人员
学科专家
客户
项目的其他管理人员以及外聘专家等
风险识别的目标是：辨识项目面临的风险，揭示风险和风险来源以及记录风险信息。
过程
风险识别过程是将项目的不确定性转变为风险陈述的过程
进行风险评估
系统地识别风险
风险定义及分类
确定风险驱动因素
将风险编写为文档
常见的软件风险
1)、人力资源风险;
2)、需求风险;
3)、项目接口风险;
4)、设计风险;
5)、管理风险；
6)、开发过程风险；
7)、项目集成与测试风险。
常用方法
风险识别方法与技术：风险识别有很多行之有效的方法，主要有核对清单、头脑风暴法、Delphi法、会议法及匿名风险报告机制等
三、风险分析（次重点）
过程
风险分析的过程包括确定风险的类别、找出风险驱动因素、判定风险来源、确定风险度量标准、预测风险造成的后果和影响以及评估风险的等级以便对风险进行高低排序等。
1）.定义风险度量准则；
2）.预测风险影响；
3）.评估风险；
4）.风险排序；
5）.制订风险计划。
技巧与工具
因果关系分析法
决策分析法
差距分析法
Pareto分析法
敏感分析法
四、风险应对（重点）
策略
避免
转移
缓解
按受
研究
储备
退避
应对过程
1、对触发事件做出反应
2、执行风险计划
3、对照计划，报告进展
4、修正与计划的偏差
第六章 软件项目配置管理
一、概述（重点）
软件配置项的定义
软件配置项(Software Configuration Item,SCI)是为了配置管理的目的而作为一个单位来看待的软件要素的集合。
基线的定义
基线(Baseline）是开发过程的里程碑，以一个或多个软件配置项的交付为标准；基线由通过正式审评的软件配置项组成，是进一步开发的基础，基线只有通过正式的变更控制过程才能改变。
软件配置管理的定义
软件配置管理是软件项目运作的一个支撑平台，它将项目干系人的工作协同起来，实现高效的团队沟通，使工作成果及时共享，这种支撑是贯穿在项目的整个生命周期中的。
二、配置管理过程（重点）
配置管理包含的基本过程
计划配置管理
开发配置管理方案
配置控制
状态审计
软件配置管理活动
包括管理软件配置管理和执行软件配置管理两项活动，通过执行它们，就能够实现软件配置管理的目标。
软件配置管理组织和职责
进行软件配置管理，必须建立相应的组织以落实职责。根据软件项目规模的大小和参与人员的多少,职责可以由一人、几人甚至整个组织来承担。软件配置管理的基本职责由配置经理、模块主管和变更控制委员会等承担。
配置管理的功能
配置标识
配置控制
配置状态报告
配置审核
基线变更管理过程
基线管理应具有两个基本功能。其一是对基线进行适当控制，禁止任何未经批准的变更。确定新基线前，必须用新基线的试行版本对每个建议的变更进行测试，以确保各个变更之间不会相互矛盾。为避免变更带来更多的问题，通常还需要一个综合的回归测试流程，即要求对处于试用期的新基线定期进行回归测试，确保项目在该点进行的所有变更都不会导致其他问题。这个过程一般要使用以前用过的测试用例。
基线审核过程
实施基线审核，则要保证基线化软件工作产品的完整性和一致性，且满足其功能要求。
配置项名称、配置项标识、版本号、一致性、完整性、备注
三、配置审核（重点）
概念
配置审核根据需求标准或合同协议检验软件产品配置，验证每个软件配置项的正确性、一致性、完备性、有效性、和可追踪性，以判定系统是否满足需求。
配置审核的目的是检验是否所有的软件产品都已产生，是否被正确地识别和描述，是否所有的变更要求可以根据确定的软件配置管理过程和程序解决。
内容
配置审核包括两方面的内容，即配置管理活动审核与基线审核。配置管理活动审核用于确保项目组成员的所有配置管理活动都遵循已批准的软件配置管理方针和规程。实施基线审核，则要保证基线化软件工作产品的完整性和一致性，且满足其功能要求。
种类
过程审核
功能审核
物理审核
质量系统审核
第七章 软件项目资源管理
一、人力资源管理（重点）
主要内容
人力资源规划的过程
团队组织和分工
人力资源计划的平衡
团队建设
建立沟通机制、培训与学习型组织氛围
二、软件资源管理（次重点）
基本概念
在软件开发的过程中，可以尽可能重复使用以前开发活动中曾经积累或使用过的软件资源，这些软件资源被称为可复用软件资源。可复用软件资源不仅包括源代码,还包括软件开发方法、需求规格说明、设计结构、开发工具、支撑环境、测试分析数据和维护信息等。
软件资源的复用方式
软件资源的主要复用方式有源代码复用、目标代码复用、设计结果复用、分析结果复用、类模块复用和构件复用。
第八章 软件项目质量管理
一、软件质量概述（次重点）
含义
用户认为是软件运行可靠，不死机，界面友好，系统运行速度快，结果正确，产品交付及时以及服务好。软件开发人员认为质量好的软件应该是技术上没有差错，符合标准及规范的要求，技术文档齐全正确，并且系统容易维护。
特性
功能性、可靠性、易用性、高效性、可维护性和可移植性
质量成本的概念
软件质量保证
在软件中专业检察员的身份就是软件质量保证人员，软件质量保证人员从事的工作就是软件质量保证活动。
目标
（1）通过适当的监控系统及其开发过程来保证软件质量。
（2）确保软件及其开发过程与已定的标准和规程要求完全一致。
（3）确保能及时发现产品、过程和标准的任何不足并提醒管理者注意，以便及时弥补。
二、软件评审（次重点）
概念
软件评审又称技术评审或同行评审，它是指由开发人员的技术同行在项目实施的各个阶段进行的有组织的软件浏览、文档与代码审读活动，验证工作是否符合预定的标准，其目的是协助软件开发人员在项目早期找出工作的错误。
实施
1.确定参加评审的人员
2.人员培训
3.评审准备
4.分发评审材料，评审员审读评审材料
5.评审会议
6.评审报告
评审成功的关键
1）、应为评审及改正评审发现的问题预留项目资源；
2）、评审应以发现问题为重点；
3）、保证评审的技术化；
4）、制订检查单和标准；
5）、限制会议人数，并且坚持事先做准备；
6）、对所有的评审者进行有意义的培训。
三、软件测试（重点）
概念
软件测试是指为了寻找软件缺陷而执行程序的过程。测试的目的是尽可能发现软件的快陷，而不是证明软件正确。
过程
制订测试计划
组建测试团队
设计与开发测试用例
执行测试
报告测试结果
类型
单元测试、集成测试、功能测试、回归测试、验收及安装测试、Beta测试、配置测试、兼容性测试、语言测试、易用性测试、
原则
(1) 完全测试程序是不可能的；
(2）软件测试需要由专门的测试人员完成；
(3) 从一开始就执行测试；
(4) 打破对测试的过分依赖；
(5) 为软件测试提供适当的资源；
(6) 注意“杀虫剂"现象；
测试用例的开发
测试覆盖技术
单元测试中的路径选择
黑盒测试中的路径覆盖
四、软件缺陷跟踪（一般）
缺陷预防原则
1）程序员必须对自己的错误作出评价。
2）反馈是缺陷预防的基本组成部分。
3）能解决所有问题的“万灵丹”是不存在的。
4）过程改进必须是整个软件开发过程的有机组成部分
缺陷预防步骤
1.缺陷的发现与报告
2.缺陷原因分析
3.缺陷预防行动
4.预防反馈
5.改进过程以预防缺陷
五、质量认证体系（一般）
ISO9000 的概念
ISO9000 不是指一个标准，而是涉及质量保证与质量管理活动的一族标准的总称
ISO9000 的质量管理原则
以客户为关注焦点
领导作用
全员参与
过程方法
管理的系统方法
持续改进
基于事实的决策方法
与供应商互利的关系。
六、能力成熟度集成模型 CMMI（一般）
CMM 的基本内容
模型等级，关键过程域
CMMI 的表示方法
第九章 Rational 统一过程
一、什么是Rational统一过程
1. RUP是一种软件工程化过程
他提供了在开发组织中分派
任务
责任
方法
目标
在可预见的预算前提下，以合理的进度，开发出满足用户需求的高质量软件产品；
2. RUP还是由Rational公司（2003年被IBM收购）开发和维护的一套过程产品
包括
工作指南
模板
工具
帮助开发团队提高生产力
用来创建和维护软件开发过程中各种工件
3. RUP还是统一建模语言（UML）的使用指南
UML是一种用于交流用户需求、系统设计和系统架构的工业标准语言
4. RUP本身是可配置的过程
二、核心概念
1. 架构
是关于捕获最高系统高级层级结构的策略
定义
系统在其所处环境中的最高层次概念（IEEE）
构成（4+1视图）
视图
逻辑
（功能需求）当采用面向对象的设计方法是，逻辑视图是对象模型
开发
描述软件在开发环境下的静态组织，质量属性有可扩展性、可重用性、可移植性、易理解性
处理
描述系统的并发和同步方面的设计，质量属性有易用性、性能、可伸缩性、持续可用性、鲁棒性、安全性
物理
（安装和部署需求）描述软件如何映射到硬件，反映系统在分布方面的设计。
由第五个用例视图整合到一起
2. 工作流程
一系列预定义的活动
1.核心工作流程
定义
在整个项目中与主要“关注领域”相关的活动的集合
9大核心工作流
业务建模
需求
分析设计
实施
测试
部署
配置与变更管理
项目管理
环境管理
2.工作流程明细（图）
展示核心工作流程所涉及的角色、输入和输出工具以及要执行的活动之间的相互关系
3. 角色
定义了在软件开发组织中，个人或协同工作的多人小组的行为和职责
代表项目中个人承担的任务，并定义如何完成任务；
角色、活动、工件的关系
每个角色要执行相互联系的活动，这些活动紧密相关，在功能上互相补充，所以最好由同一个人来执行，因而也就归属于同一个角色
活动与工件密切相关
工件是活动的输入和输出，并提供活动之间的通信机制。
4. 活动
定义了角色执行的工作；
活动是参与项目的角色为提供符合要求的工件而进行工作
5.步骤
构思步骤
角色了解任务的实质
收集并检查输入工件
规划输出结果
有查找行为者、查找用例、说明行为者和用例的交互方式三个细化步骤
执行步骤
角色创建或更新某些工件
有将用例和行为者打包、在用例图中显示用例模型、生成用例模型的概览细分步骤
复审步骤
角色按某些标准检查结果，有评估结果细分步骤；
6. 工件
是工作流程的产品，是单个角色的职责；
表现形式：
模型
模型元素
文档
源代码或某种构件
可执行程序
三、6个最佳实践
“最佳实践”是指在商业中综合运用，并能够解决软件开发根本问题的策略
1. 迭代式的软件开发
优点：减小了项目风险、更容易对需求变更进行控制、高度的可重用性、项目小组可以在开发中学习、更佳的系统总质量。
2. 需求管理
1. 在RUP中进行需求管理的意义
定义：正在构建的系统必须符合的条件或具备的功能；
优点：更好地控制复杂项目、提高软件质量和客户满意度、降低项目成本和延迟、增强团队中的交流；
2. RUP捕获和描述需求的方法
用例方法：针对每一个参与者，用例仅描述系统为这些参与者提供了什么样的服务，或者说系统是如何被这些参与者使用的；
用例能够用于发现每个用户需要的功能，避免冗余功能，从而有效确定系统的范围和行为，使整个系统的业务为每个用户提供最大的价值；
3. “4+1视图”帮助捕获和描述需求
逻辑视图
关注功能
开发视图
关注程序包
处理视图
关注进程、线程和对象等运行时概念，以及相关并发、同步和通信等问题
物理视图
关注目标程序及其依赖的运行库和系统软件最终如何安装或部署到物理及其，以及如何部署及其和网络来配合软件系统的可靠性、可伸缩性等要求
3. 使用基于构件的架构，以架构为中心的过程
说明
用例对RUP起着驱动作用；
RUP关注早期开发、将健壮的、可执行的系统架构作为基线；
RUP基于构件开发；
构件是实现清晰功能的模块，包括子系统，它完成一个明确的功能有着明确的界限，并且能够集成到一个定义良好的架构中；
基于构件开发的方式：
（1）在定义一个模块化的架构时，要确定、分离、设计、开发和测试已成型的构件，这些构件可以分布测试并逐渐集成，最终成为完整系统；
（2）可以为很多普遍存在的问题提供共同解决方法的构件，可以被开发成可复用的构件，这些可复用的构件要比纯粹的公用程序或类库的集合大和多，形成了一个组织中复用的基础，提高了整个软件的生产率和质量；
（3）支持软件构件概念的基础结构在商业上也取得了成功，这促进了用于不同领域的现成商业构件的发展，开发人员可以购买并集成商业构件，而不用自行开发；
RUP支持构件开发的方式：
（1）迭代方法允许开发人员逐渐确定构件；
（2）利用系统架构的概念，可以使开发团队明确整个系统的架构；
（3）在分析和设计中将用到如包、子系统和层这样的概念来组织构件和指定接口；
（4）开始对独立构件组织测试，随后将逐渐扩大到对更大的集成构件进行测试；
4. 可视化软件建模
工业级标准UML是成功进行可视化软件建模的基础；
UML是一种图形语言，用来将软件密集型系统的工件可视化、具体化，构造并记录这些工件；
UML提供一种规划系统蓝图的标准方法；
5. 验证软件质量
质量应该基于可靠性、功能、应用和系统性能，并根据需求来进行认证；
RUP帮助计划、设计、实现、执行和评估这些测试类型；
质量评估内建于过程和活动，包括全体成员，使用客观的度量和标准，并且不是事后型的或单独小组进行的分离活动；
6. 控制软件变更
变更管理密切关注开发组织的需求，它是对需求、设计和实现中的变更进行管理的一种系统性方法，他也涵盖一系列重要的活动；
四、RUP的二维结构
1. 动态结构：阶段和迭代时间轴
1. 初始阶段
用来为系统建立商业案例和确定系统的边界，也就是获得项目的基础，重点是业务建模工作流程和需求工作流程。
里程碑：生命周期目标里程碑，用来评估项目的基本可行性；
2. 细化阶段
目标是分析问题领域，建立比较健全的架构基础，编制项目计划，淘汰项目中最高风险的元素；
生命周期架构里程碑，为系统架构建立管理基线，并使项目团队能够在构造阶段调整规模；
3. 构造阶段
目标是阐明剩余的需求，并基于已建立基线的架构完成系统开发；
里程碑：最初操作性能里程碑，确定产品是否已经可以部署到Beta测试环境；
4. 移交阶段
当基线已经足够完善，可以部署到最终用户领域中，则进入移交阶段；
重点是确保最终用户可以使用软件；
里程碑：产品发布里程碑，确定是否达到目标，或者是否需要开始另外一个开发周期；
2. 静态结构：工作流程轴
4类主要建模元素：角色、活动、工件、工作流程；
五、核心工作流程
代表所有角色和活动的逻辑分组情况
核心工程工作流程：业务建模、需求工作、分析和设计、实现工作、测试工作和部署共六个工作流程；
核心支持工作流程：配置和变更管理、项目管理、环境共三个工作流程
1. 业务建模工作流程
1. 业务建模工作流程的目的
了解目标组织的结构及动态特性；
了解目标组织中当前存在的问题并确定改进的可能性；
确保客户、最终用户和开发人员就目标组织达成共识；
导出支持目标组织所需的系统需求；
2. 业务建模工作流程的说明
在一次迭代中，系统分析员将评估目标组织的状态；
如果系统分析员任务不需要完整的业务模型，只需要领域模型，他将采用该工作流程的另一种路径领域建模；
如果系统分析员决定不对目标组织中当前业务流程进行大的更改，那么只需将这些流程制作成流程图，并推导出系统需求；
如果进行业务建模的目的是改进或重建现有业务，则需要对当前业务和新业务进行建模；
如果进行业务建模的目的是从零开始开发一种全新业务，那么需求预想新业务，并构件该新业务的模型，就要跳过“说明当前业务”这一步；
2. 需求工作流程
1. 需求工作流程的目的
项目干系人在系统的工作内容方面达成一致；
使系统开发人员能够更清楚地了解系统需求；
为计划迭代的技术内容提供基础；
为估算开发系统所需成本和时间提供基础；
定义系统的用户界面，重点是用户的需要和目标；
定义系统边界；
2. 需求工作流程的说明
开发人员可以根据开发系统的不同以及在开发生命周期当中所处的位置，选择不同的路径完成这个工作流程；
3. 需求工作流程同其他工作流程的关系
业务建模工作流程提供了以为规则、业务用例模型和业务对象模型；
在需求工作流程中创建的用例模型和词汇表是分析设计工作流程中的主要输入工件；
测试工作流程对系统进行测试，以便验证代码是否与用例模型一致；
环境工作流程用于开发和维护在需求股那里和用例建模中使用的支持性工作；
管理工作流程用于制订项目计划，并制订需求管理计划及各次迭代计划；
3. 分析和设计工作流程
分析和设计是需求和实现之间的桥梁；
目的在于将需求转换为未来系统的设计；
是软件架构师的职责；
4. 实现工作流程
1. 实现工作流程的目的
对照实施子系统的分层结构定义代码结构；
以构件的方式实施类和对象；
对已开发的构件按单位进行测试；
将各实施单位完成的结构集成到可执行系统中。
2. 实现工作流程的说明
建立实施模型
制订集成计划
实施构件
集成子系统
集成系统
5. 测试工作流程
1. 测试工作流程的目的
核实对象之间的交互；
核实软件的所有构件是否正确集成；
核实所有需求是否已经正确实施；
确定是否存在缺陷并确保在部署软件之前将缺陷解决；
2. 测试工作流程的说明
制订测试计划：确定和描述要实施和执行的测试；
设计测试：确定、描述和生成测试模型及其工件；
实施测试：实施测试过程；
集成测试：确保各构件组合在一起后能够按既定意图协作运行，并确保增量构件的行为正确；
系统测试：确保整个系统按既定意图运行；
评估测试：生成并交付测试评估摘要。
6. 部署工作流程
描述那些为确保最终用户可以正常使用软件产品而进行的活动，是开发环境的最后一环；
1. 部署工作流程的目的
成功的生成版本，将软件分发给最终用户；
2. 部署工作流程的说明
制订部署计划：确保最终用户可成功地使用产品；
编写支持材料：不同职位的人员有效使用新系统所需的培训材料；
管理验收测试：确保产品在发布之前进行了充分的测试；
生成部署单元：为进行beta测试而创建或根据其成熟度为最终产品而创建；
Beta产品测试：创建Beta程序；
管理验收测试：确保产品在发布之前进行了充分的测试；
包装产品：说明创建市售产品所需的活动；
提供下载站点：让用户能够通过互联网下载软件；
7. 配置和变更管理工作流程
描绘了如何在多个成员组成的项目中控制大量的工件；
8. 项目管理工作流程
1. 项目管理工作流程的目的
为软件密集型项目提供管理框架；
为项目的计划、人员配备执、执行和监测提供实用的准则；
为管理风险提供框架。
2. 项目管理工作流程的说明
初始阶段：由构思新项目开始管理工作流程；
开发计划制订：判断争取资金还是放弃；
下一次迭代：要改进和实现的需求；
迭代评估标准复审，对迭代测试计划进行复审；
管理迭代的同时，监控项目中执行每天、每周和每月的立项项目管理任务；
最后迭代完成时：进行主要里程碑复审；
迭代评估和验收复审之后，将在评估项目规模和风险中重新检查前景、风险列表和商业理由；
9. 环境工作流程
1. 环境工作流程的目的
给软件开发组织提供如那件开发环境；
2. 环境工作流程的说明
在项目的早期迭代中，将通过执行准备项目环境来启用工作流程。
第十章 敏捷软件开发
（一）敏捷软件开发的诞生
1. 传统的软件过程成为过去
1970年的瀑布模型弊端：过分强调软件开发的顺序性，导致要到开发后期用户才能看到软件的模样，为软件开发增加了极大的风险；没有迭代和反馈，导致无法应对客户的需求变化；带来了极大的变更成本。
2. 新的软件工程过程发展失控
有非常多的约束、非常多的工具已经非常多的方法和步骤；
降低了团队的开发效率，使得进度延期，预算超支；
降低了团队的响应能力，使得团队经常创建错误的产品。
3. 敏捷软件开发诞生
2001年17位专家讨论各种轻量级软件开发方法学；
4. 敏捷软件开发特点
强调程序员和业务专家、用户之间的紧密协作、面对面的沟通，这种方法比书面文档更有效；
能够很好地根据需求的变化编写代码；
频繁的交付新的软件版本；
采用紧凑和自组织的软件开发团队；
更注重个体在软件开发种的作用。
（二）敏捷软件开发宣言
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
（三）敏捷宣言遵循的原则
最重要的是通过尽早和持续交付有价值的软件满足客户需要；
欢迎需求变化，即使在开发后期；
经常交付可以工作的软件，时间跨度越短越好；
业务人员和开发人员应该在整个项目过程种始终在一起工作；
围绕斗志高昂的人进行软件开发；
最有效率最有效果的信息传达方式是面对面交谈；
可以工作的软件是进度的主要度量标准；
提倡可持续开发；
不断追求卓越的技术和良好的设计；
尽可能减少工作量；
最好的都源于自组织的团队；
每隔一段时间进行总结。
（四）对比其他的方法
对比迭代方法：两者都强调较短的开发周期提交软件，迭代开发每个周期更新代码和文档，工作量大，容易出现代码和文档不匹配的问题，敏捷开发时间更短，强调高度协作，看重可以工作的软件而不是文档。
对比瀑布式开发：瀑布式自由度低，变化难以调整，代价高；敏捷刚好相反。
（五）敏捷软件开发的适用性
组织文化必须支持协商讨论；
人员彼此信任；
人少而精；
程序员所做决定得到认可；
环境设施满足成员间快速沟通的需要。
（六）极限编程概述
是敏捷开发中最著名的一个过程和方法，供中小型开发团队用于开发需要快速变化的软件。
1. 价值观
简单
交流
反馈
勇气
2. 原则
快速反馈
简单性假设
拥抱变化
高质量的工作
3. 行为
倾听
测试
编码
设计
4. 实践
客户作为团队成员
用户故事
短交付周期：迭代计划、发布计划
测试驱动的开发方法：极限编程的重要特点
验收测试
结对编程
集体所有权
持续集成
可持续的开发速度
开放的工作空间
计划游戏
提倡简单的设计
时常对现有代码进行重构
隐喻
5. 小结
极限编程是一组简单、具体的实践；
（七）Scrum
1. 一个简单的框架
是一个敏捷开发框架，是一个增量迭代的开发过程。
2. Scrum过程
1. Scrum过程
更新产品订单、冲刺计划会议、每日训话、冲刺增量、冲刺检验、冲刺追溯；
2. Scrum的3个角色，3项活动，3种工具，1个冲刺
3. 3个角色
产品负责人（Product Owner）：负责维护产品订单的人；
Scrum主管（Scrum Master）：负责团队运作；
Scrum团队（Scrum Team）：负责产品交付。
4. 3项活动
冲刺计划会议（Sprint Planning Meeting）：根据产品负责人制订的产品或项目计划在冲刺的开始时做准备工作；
每日站立会议（Daily Scrum Meeting）：项目状况会议；
冲刺评审会议（Sprint Review Meeting）：为了进行持续的过程改进；
5. 3种工具
产品订单（Product Backlog）：根据商业价值排序和涵盖所有客户需求的产品特性列表；
冲刺订单（Sprint Backlog）：冲刺计划会议上产出的一个产品特性列表；
燃烧进度表（Burn-down Chart）：是一个公开展示的图表，在冲刺长度上显示每天的进展，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目，是一个反映工作量完成状况的趋势图，是对工程进度进行控制的有效工具。
6. 自适应的项目管理
频繁的风险评估和应对措施；
通过每日站立会议，让计划和模块开发保持透明，让每一个人知道谁负责什么，以及什么时候完成；
以冲刺评审会为主要形式，频繁召开利益所有人会议，以跟踪项目进展，保持项目开发的节奏；
没有问题会被藏在地毯下。
7. Scrum较传统开发模型的优点
能尽快的相应变化；
小结
目标：给客户交付最大可能的价值；
敏捷软件开发是一种面临迅速变化的需求快速开发软件能力；
敏捷软件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法；
极限编程是敏捷软件开发中最著名的一个过程和方法；
Scrum是目前应用最广的敏捷软件开发方法。
第十一章 将 6A 管理引入软件开发
（一）6б的故事
1. 初探6б
1986年摩托罗拉公司的Bill Smith 提出；
属于质量管理范畴
旨在生产过程中降低产品及流程的缺陷次数，防止产品变异，提升品质；
含义：百分之三点四的缺陷率，采用定义、测量、分析、改进和控制等五个步骤过程改进方法，质量改进所需的各种工具方法；
2. 6б在摩托罗拉诞生
《6б机械设计公差》文件提出了如何减少或消除缺陷；
3. 6б在通用电气获得巨大成功
节约了成本，增加了利润；
（二）6б理论基础
1.平均值屏蔽了问题，波动成了焦点
如果仅统计数据的平均值，以整体衡量，往往就把存在的问题隐藏起来了
2. “波动”问题的数学描述
1. 对波动的描述
随机变量的取值与均值的差，称为偏差，反映了波动；
2. 对过程能力的描述
过程能力是值过程加工质量方面的能力，这种能力标识过程稳定的程度；
3. 对缺陷的描述
单位产品平均缺陷数DPU：反映了产品上缺陷多少，是客户能够量化的质量指标；
DPO表示每个机会的平均缺陷数；
DPMO表示每百万个机会的平均缺陷数；
DPU是对不合格平吕这种传统描述方法的深化，而DPMO是对DPU的深化；
4. 对过程绩效的描述
用首批合格率和最终合格率来评价过程的绩效；
核心思想：建立在过程的某一个环节中输出与输入之比的基础上；
具有直观性，忽略了周转时间、全面质量和生产成本；
3. 6б的数学含义
一百万次机会中仅有3.4个缺陷；
4. 其他术语
1. 关键质量要素（CTQ）
指客户对产品或服务的重要要求标准，一般都是可以量化的指标。
2. 关键产品特性（KPC）
这些特征在偏差范围内发生波动，就会对产品的质量、性能或制造带来显著的影响
3. Pareto图
帮助分类并筛选出最重要的因素；
（三）6б管理
6б管理是一项以客户为中心，以数据为基础，以追求完美目标的管理方法
6б管理的实施条件：只有把6б作为企业经营管理的中心环节，使其成为一种规范化的工作体系，才能有效的实施6б管理；
6б管理的组织形式：倡导者->黑带大师->黑带->绿带
6б的改进模型——DMAIC：定义、测量、分析、改进、控制五个阶段；
（四）使用6б改善软件开发过程
1.项目启动和问题定义阶段
保证在客户部门中有一个项目主办人
与主办人一起对项目应用SMART标准，审查项目的目标
确定初步需求
确定需求，尤其是确定需求的优先次序
2. 系统分析
了解当前的业务流程
确定需求
区分需求的优先次序
确定可能的过程改进
确定对最高优先级需求具有最大影响的改进
建立一个详细的未来流程图
估计建立过程改进的影响和风险
完成需求规格说明
3. 系统设计
6б管理要求在系统设计阶段，客户要积极参与；
4. 构造
构造是改进阶段的组成部分，是实现解决方法和改进过程的步骤，其中一个重要的工作就是缺陷预防；
5. 测试和质量保证
论证开发人员已经理解并满足了客户需求；
论证实际的人员可以实际使用该系统；
6. 交付和维护
客户培训
交付软件产品和用户文档
生产数据转换和导入
项目评价