软件过程管理总结.doc
《软件过程管理总结.doc》由会员分享，可在线阅读，更多相关《软件过程管理总结.doc（9页珍藏版）》请在冰点文库上搜索。
大纲：
第1章软件过程规范
1、软件过程：
过程的定义、软件过程的分类和组成、软件过程定义的层次性
2、过程规范：
过程规范的涵义、内容、影响及作用
3、软件生命周期的过程需求：
理解ISO/IEC15504所定义的软件过程的5大需求，并进一步理解其子过程
4、软件生命周期标准：
了解ISO和IEEE两大软件生命周期标准体系
5、软件过程建模：
掌握软件过程模型的定义，了解软件过程模型
第2章软件过程成熟度
1．过程成熟度标准：
掌握软件过程能力、软件过程性能、软件过程成熟度的概念，了解成熟和不成熟软件过程的特点
2．能力成熟度模型：
重点掌握CMM，了解其起源，掌握其基本内容和结构。
理解CMMI的目标
3．过程成熟度级别：
理解CMM/CMMI成熟度的5个等级及其过程特征，了解CMMI过程域
4．软件过程框架：
了解软件过程环境中的活动，掌握软件过程环境内容、软件组织的层次，掌握组织、过程和环境的关系，了解软件过程文化。
掌握PSP/TSP和CMM组成的软件过程框架
第3章软件过程的组织管理
1．组织过程的焦点：
了解组织过程焦点的基础、活动和评估
2．组织过程定义：
理解组织过程定义的概念、了解软件过程定义基础、掌握剪裁标准软件过程指南和准则
3．PSP过程框架和成熟度模型：
理解PSP概念、原则和思想，掌握PSP过程框架及其成熟度模型并能在实际中实施
4．TSP结构和启动过程：
理解TSP概念、原则和思想，掌握TSP结构及其启动过程和工作流程
第4章软件过程的需求管理
1．需求管理的模型和流程：
理解软件需求的三个不同层次和需求过程系统模型
2．需求开发：
了解需求获取的过程和方法，掌握基于用例的需求获取和分析方法
3．需求管理：
掌握需求管理流程，并能结合实际案例运用所学知识进行分析
第5章软件过程的技术管理
1．软件过程的技术架构：
理解软件过程的技术架构定义、层次、内容，了解软件资源管理
2．软件过程的问题分析和决策方法：
掌握系统分析过程逻辑结构、了解原因分析和缺陷分析、决策分析与决定
3．软件过程的技术路线：
掌握软件项目过程的技术解决流程的主要内容，了解其过程
4．知识传递：
掌握知识传递的有效方法
第6章软件过程的项目管理
1．软件配置管理：
掌握SCM的定义和变更控制流程，了解软件配置管理中经常使用的一些基本概念
2．软件项目开发计划：
理解WBS的内涵，掌握WBS的分解步骤、工作编码，并能进行实际分解。
掌握软件项目估算的概念，理解规模、成本、进度估算，重点掌握进度估算。
网络图的形式及特点，并能结合实际项目制定开发计划。
3．项目风险评估：
风险的概念、分类，了解风险识别、风险评估、风险计划、风险控制与管理过程，结合实际项目进行风险管理。
4．项目跟踪和监督：
项目跟踪包括的内容，项目跟踪的基本步骤。
了解项目过程的跟踪和控制。
第7章软件过程的质量管理
1．质量管理概述：
理解三种不同的管理方式，软件的质量。
2．软件质量方针和计划：
掌握质量计划的输入因素，质量计划的制定步骤，质量计划的方法和技术。
3．软件评审过程和方法：
掌握评审的入口条件包含的内容，软件评审流程的6个步骤。
掌握常用的软件评审方法，并能在软件开发过程的不同阶段应用。
掌握好的缺陷管理系统的特点，了解缺陷发展趋势图、缺陷分布图，掌握鱼骨图分析法，并能结合项目画出完整的鱼骨图。
了解两种比较常见的缺陷预防方法。
了解质量度量的主要作用和其所包括的主要度量的含义。
掌握PSP中预防缺陷的三种方法。
第8章软件过程的集成管理
1．集成项目管理
理解软件过程的项目综合管理和软件产品的集成管理不同，掌握软件项目集成的主要内容和集成管理流程的子阶段以及集成管理活动中所使用的主要工具
2．集成项目的合成计划：
了解合成项目涉及的管理内容，掌握组间协调的最佳实践。
3．产品集成的过程管理：
理解产品集成的3个阶段，了解产品集成的管理流程。
4．集成产品开发模式：
掌握IPD概念和核心思想以及IPD的过程框架模式。
第9章软件过程的评估和改进
1．过程模型的剪裁：
掌握3种不同类型的过程剪裁，掌握CMMI模型的两种表示法。
了解过程模型剪裁的基本用途。
2．软件过程度量：
掌握过程度量的内容和过程度量流程，了解过程度量的方法，掌握过程度量技术。
3．过程评估参考模型：
了解ISO/IEC评估模型的内容构成、评估方法、评估等级，掌握了解ISO/IEC评估模型的3种应用模式。
理解Bootstrap、Trillium评估模型。
4．过程评估：
理解过程评估的目标，评估输入、输出所包括的信息，了解评估内容和范围。
掌握评估类型、评估方式、评估方法
5．过程改进的模型和方法：
重点掌握IDEAL模型和6Sigma方法
6．组织和技术革新：
了解其相关内容
7．软件过程改进的实施
理解过程改进的原则和策略，了解过程改进的组织支持和改进计划，掌握过程改进的具体实施步骤。
第10章软件过程的管理实践
1．IBM-Rational业务驱动开发的过程管理：
理解RUP的迭代过程
2．微软公司的软件开发过程模式
了解微软过程模型的5个阶段，了解MSF的团队模型和MSF过程模型应用。
掌握MSF过程模型的特点。
3．敏捷模型的软件过程管理：
掌握敏捷建模的原则和最佳实践
4．面向构件的软件过程：
掌握CBSP的主要思想以及主要阶段
5．软件过程的自定义体系：
了解CMM/CMMI、RUP、MSF、Agile和CBSP模式各自的特点
软件过程规范
1.过程：
一组将输入转化为输出的相互关联或者相互作用的活动，由输入，实施活动和输出三个环节组成。
（名词解释）
2.软件过程定义的三个层次：
公共软件过程模型和标准（CMM,ISO12207/15504）→组织的标准软件过程→项目所定义的软件过程
3.公共软件过程模型和标准:
是指（CMM,ISO/IEC15504,ISO/IEC12207）等过程规范或标准
4.软件过程管理的目的：
最大限度的提高软件产品的质量和软件开发过程的生产率。
软件开发过程的生产率依赖于三个因素：
过程，人和技术
5.软件过程建模型：
描述了软件过程要素（活动，资源，角色和过程产品）以及这些要素之间的关系。
方法有UML方法IDEF3方法Agent方法
6.基于SOA（面向服务架构）的软件过程模型包含了支持完成SOA生命周期的部署、监控、和管理所需的技术，其过程包含三个层次识别层规范层实现层
7.软件过程模型:
瀑布式软件开发过程螺旋式软件开发过程
8.软件生命周期的标准最具代表性的两类ISO标准体系，IEEE标准体系
9.选择IEC12207软件生命周期过程
组织过程：
培训过程管理过程改进过程基础设施过程
支持过程：
文档编制过程配置管理过程质量保证过程验证过程确认过程联合评审审核问题解决过程（与ISO/IEC15504基本相同）
基本过程：
获取过程供应过程开发过程运行过程维护过程
ISO/IEC15504软件过程评估标准
管理过程：
项目管理质量管理风险管理自合同管理
支持过程：
文档编制配置管理过程质量保证过程验证工作产品确认工作产品联合评审审核解决问题
组织过程：
业务规划定义过程改进过程提供有技能的人员提供软件工程架构
工程过程：
系统分析和设计软件需求分析开发软件设计软件设计实施集成并测试软件集成并测试软件系统系统与软件的维护
10简答ISO/IEC15504提供了三种模式满足软件组织在过程上的需求
（1）能力确定模式.帮助评估并确定一个潜在的软件供应商的能力
（2）过程改进模式。
帮助提高软件开发过程的水平
（3）自我评估模式。
帮助判断是否有能力承接新项目的开发
客户—供应商过程：
软件获得客户需求管理提供软件操作软件提供客户服务
第一章软件过程成熟度
1.软件过程成熟度:
对具体软件过程进行明确定义、管理、度量、和控制的有效程度。
（名词解释）
2.掌握软件过程能力:
软件过程本身具有的按预定计划生产产品的固定能力，或者遵循软件过程能够实现预期结果的程度
3.软件过程性能：
遵循软件过程所得到或软件过程执行的实际结果。
4.CMMI过程域：
描述过程管理的某一方面的内容，包括目标、活动、和最佳实践，对应用于国际标准ISO-12207或者ISO-15504的子过程进行管理。
5.个体软件过程PSP：
基于软件工程思想，软件技术和专业方法，帮助软件开发团队中的个人---软件工程师改善个人能力和素质的组织过程
6.团队软件过程TSP：
建立在个体软件过程之上，致力于开发高质量的产品，建立、管理和授权项目小组，改善开发团队过程，提高开发团队能力的指导性框架。
7.不成熟软件过程的特点（简答）
a）软件过程能力低，不能按预定计划开发出客户满意的产品，项目拖延、费用大大超出预算已成惯例。
b）过程性能的不可预见性，对进度和预算估计、产品质量的目标缺乏历史数据和有效方法的客观基础，开发的进度、成本和产品的质量都难以预测。
c）过程的不可视性，软件过程缺乏定义、缺乏文档和缺乏跟踪，在整个软件过程中，不清楚每个阶段进出的标准、执行的方法和规则。
d）过程的不稳定性，实际的、具体的操作过程是在一个项目开始后临时拼凑而成，每个项目都不一样。
e）过程的被动性、缺乏改进的主动性
8.CMM（能力成熟度模型）的基本内容和结构
9.CMM/CMMI提供了一个框架，将软件过程不同的成熟度分为5个等级（P38课本）
初始级：
过程缺乏定义，无秩序，缺乏开发和维护软件所需的稳定环境
可重复级/受管理级：
可以看到一个按计划执行的并且阶段可控的、规范化的软件开发过程（针对项目本身而不是整个组织）
已定义级：
具有良好的文档化、标准化，使软件过程具有可视性、一致性、稳定性和可重复性，软件过程被集成为一个有机的整体.通过裁剪组织的标准软件过程来建立自定义的软件过程.
已管理级对软件产品和过程进行有效的定量控制和管理
优化级：
不断改善组织的软件过程能力和项目的过程性能。
追求新技术，实现软件开发中的方法和技术的革新
10.软件过程环境中的活动：
软件过程实施，软件过程评估，过程改进，过程架构
11.软件过程环境内容:
不同的过程对象（个人，团队，客户，第三方）。
不同的过程层次（组织过程，项目过程，团队过程，个体过程）。
过程资源的差异（人力，软硬件）。
过程文化的差异（以客户为中心，以产品为中心）。
开发类型不同（新产品，构件重用，产期产品）。
12.软件组织的层次：
软件个体，软件团队，软件组织
13.组织、过程和环境的关系:
软件组织是过程的核心，过程是由组织定义的，过程环境也是由组织建设和维护的
13.软件过程文化：
（1）过程文化三种类型：
过程至上（组织、质量和效率都服从于过程，适合于要求高可靠性高质量的软件产品如军事系统，核电站控制系统以及航空航天软件系统）；以过程为焦点（让过程服从于质量和效率，对于一般软件系统）；过程起辅助作用，人决定一切
（2）敏捷过程文化：
强调以满足客户需要，创造客户价值为首要目标,以人为本,注重个人及互动。
14.基于组织目标的PSP/TSP/CMM三者的关系（p54课本）
CMM提供平价组织的能力识别优先改善需求和追踪改善进展的管理方式
PSP有助于CMM目标的实现
TSP向组织展示如何应用CMM的原则和PSP的技能去生产高质量产品
第二章软件过程的组织管理
1.组织过程焦点目的是建立软件组织对软件件过程活动的责任，包括促进并保持对软件过程的了解、协调、制定、维护、评估以及改进的活动
基础:
执行约定（组织过程焦点的组织方针以及特别分配的关键责任），执行能力（组织和项目实施软件过程的先决条件，指提供资源，分派责任和人员培训）
活动：
目的在于创造一种环境，使组织能够间距离和维护一个软件过程改进的方法学。
评估：
（1）度量和分析
（2）验证实施
2.组织过程定义:
由负责软件过程活动的组织单元（软件过程工程组）在组织层上定义的软件过程。
包括制定和维护组织的标准软件过程以及相关的软件过程财富。
软件过程定义基础软件过程元素（主要的软件过程元素如项目估计元素，软件设计元素；支持的软件过程元素如配置管理，文档编制；组织的软件过程元素），组织标准软件过程（基于所有软件项目的共用的软件过程），项目定义软件过程
3.PSP过程框架和成熟度模型（P66课本）
4.TSP结构和启动过程
TSP概念：
团队软件过程，致力于开发高质量的产品，建立，管理，和授权项目小组，改善开发团队过程，提高开发团队能力的框架
原则：
遵循定义好的过程并得到快速反馈学习很重要；高效团队的协同工作；面临实际问题时讨论分析并最终得到有效的解决方案，让团队开发人员受益匪浅
思想：
如何规划和管理一个软件开发团队；如何制订团队工作所需要的策略；如何定义和确定团队中每个角色的职责；如何为团队中每个成员分配不同的角色；团队及其不同角色在整个开发过程的不同阶段应该做些什么，如何更好地发挥作用；在如何协调团队成员之间的任务，并跟踪报告团队整体的任务进度；采用哪些方法提高团队的协作能力。
掌握TSP结构及其启动过程（p76）
工作流程：
策略和计划；需求（完成需求规格说明书：
对产品要完成的功能进行详细、清晰的描述）；设计和实现；测试和后期维护
第4章软件过程的需求管理
1.需求开发——包括需求获取、需求分析、编写需求规格说明、验证需求四个阶段
2.掌握需求管理流程，并能结合实际案例运用所学知识进行分析
需求管理——是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。
需求管理活动包括
-定义需求基线
-评审需求变更并评估每项需求变更对软件产品的影响从而决定是否实施它。
-以一种可控制的方式将需求变更融入当前的软件项目。
-让当前的项目计划和需求保持一致。
-估计变更所产生的影响并在此基础上协商新的约定
-实现通过需求可跟踪对应的设计、源代码和测试用例。
在整个项目过程中跟踪需求状态及其变更情况。
3.需求获取方法（访谈和调研,专题讨论会,脑力风暴,场景串联）
案例1：
某公司“船代”项目的需求开发
（1）需求调研前的准备
安排项目干系人;制订调研计划;分析项目的关键环节;制订调研策略
（2）实施需求调研
了解外部客户和本行业目前总体状况;了解本项目涵盖的业务的流程和部门结构;绘制业务流程图和部门结构图;现状分析;找出关键因素
（3）提出未来的设计方案，编写需求规格说明
系统功能划分;系统业务流程图，并附文字说明;系统业务环节的数据项、数据采集方式、数据间内在联系分析;部门调整方案，部门职责重新定位;系统与其他系统的集成方案
案例2HRMS（HumanResourceManageSystem）的系统为例，介绍需求的开发和管理过程。
HRMS系统中的需求分类
需求分类
编号
系统典型需求
功能需求
（Functional）
1
招聘人员：
用户可以通过招聘人员
2
申请职位：
Web用户可以填写信息申请职位
3
查看职位申请信息：
Web用户可以查看职位申请信息
4
处理职位申请：
管理员可以处理职位申请
5
修改申请人信息：
管理员可以修改申请人的信息
……
可用性
（Usability）
1
对于熟悉公司原系统的用户新系统应易于操作
2
系统应支持Internet环境
3
系统应给用户提供在线指南
……
可靠性
（Reliability）
1
系统应该在任何时间都能工作，若是出现故障，
必须要在一个小时之内修复
2
系统应能支持用户在指定的时间备份资料
……
1
管理系统必须支持公司内部员工和web用户同时访问，
并且支持同时在线人数不低于100人
2
系统的响应时间不超过4秒
……
1
支持多用户访问系统
2
一般用户只能查看和修改自己的信息不能看到其他人的信息
3
公司的下级员工不能查看上级员工的信息
4
公司的上级员工可以查看下级员工的信息而不能修改
……
1
系统采用B/S结构，用户可以通过Internet访问系统
2
培训系统可以在所有流行的浏览器（如Navigation,IE）
上正常显示
……
需求分析
本项目采用原型分析方法和用例分析方法相结合来进行需求分析，以用例分析方法为主，对于每个UseCase，创建用户接口说明文档和Usecase报告，同时建立这个用例的原型。
其中各个角色描述如下：
角色1:
员工（Employee）角色2:
雇用经理（HiringManager）角色3:
部门经理（DepartmentManager）角色4:
上级（Superior）角色5:
分区经理（DivisionManager）
角色6:
运行官（OperationHead）角色7:
申请人（Applicant）角色8:
人力资源经理（HRManager）角色9:
培训经理（TrainingAdministrator）角色10:
培训中心经理（TrainingCenterAdministrator）
用例分析;编写UseCase报告
为系统中的每个用例编写UseCase报告，则系统分析与设计人员可以更加清晰的掌握系统架构。
需求变更管理
建立需求基准版本和需求控制版本文档。
所有的需求文档都要进行版本控制，文档要包含文档类型、名称、创建者、创建时间、修改者、修改时间、版本号、评审人员等信息。
在开发HRMS中，提交的需求文档包括用户界面说明文档、UseCase报告、Glossary文档、软件开发计划、UseCase模型调研以及补充说明。
所有的文档采用统一的编号规则和命名规则。
文档编号规则；文档命名规则
案例3：
需求变更的代价:
Steven的烦恼
A:
Steven主要犯了几个错误：
（1）没有明确的授权。
事先应该明确客户方有权提出变更申请的人员和实施方有权受理变更的人员，并要控制双方人数。
这样做才可以对变更有整体的控制。
绝不能进行“私下交易”，授权可以显着减少变更，特别是那些因内部看法不同而导致的反复变更。
（2）对变更没有进行必要的审核。
并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。
比如案例中提到的界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。
另外，对于核心模块的修改要严格审核把关，否则会引起全局问题，案例中提到的“擅自修改核心模块”造成的事故就是因为没有审核而造成的。
（3）对变更的影响没有评估。
变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让客户了解变更的后果，并与客户一起做判断。
案例中客户最后的质问正是因为没有事前告诉客户变更的影响造成的。
（4）应该让客户确认是否接受变更的代价。
在评估代价并且与客户讨论的过程中，可以请客户一起做判断：
“我可以修改，但您能接受后果吗？
”。
上述步骤完成后，要等客户确认变更再组织实施变更的相关工作。
变更要按配置管理的规定执行，确保所有交付物的一致性和完整性。
同时，对所有的变更要跟踪和验证，确保都按要求完成了。
最后，要特别提醒的是：
要在项目开始就对项目组和客户进行宣传和培训，让所有成员都理解变更控制的重要意义；在项目过程中要对变更控制的执行情况进行审计，发现违反规定的事件要严肃处理，否则过程很快就会失效。
综上所述，变更控制的目的是管理变化。
变更控制对项目成败有重要影响，事前要明确定义，事中要严格执行。
实施变更之前有四个重要控制点：
授权、审核、评估和确认；在实施过程要进行跟踪和验证，确保变更被正确执行
B:
如何应对
需求一定要分类管理;需求必须分优先级;需求必须文档化;需求一旦变化，就必须对需求变更的影响进行评估;需求管理必须与需求工程的其他活动紧密整合
第5章软件过程的技术管理
1.软件过程是围绕软件的基本过程---软件工程过程开展的，从软件需求分析开始，经过系统架构设计、程序设计、编码、测试以及部署各个环节，完成软件产品的开发
2.掌握系统分析过程逻辑结构（p104）、了解原因分析和缺陷分析、决策分析与决定
决策分析：
按照所建立的评判标准，对所确立的候选方案作出选择和优化
评判方法主要是运用概率模型和决策理论进行模型分析、实验/测试验证
第6章软件过程的项目管理
1.掌握SCM的定义和变更控制流程，了解软件配置管理中经常使用的一些基本概念（p126）
2.项目成本的组成
直接成本：
人力成本;硬件设备;软件费用-------------间接成本:
项目管理成本;一般管理成本
3.制定项目计划
工作分解结构表（WBS）基于可交付成果的划分
上层一般为可交付成果为导向;下层一般为可交付成果的工作内容
基于工作过程的划分---------上层按照工作的流程分解;下层按照工作的内容划分
软件配置管理定义：
软件配置管理过程是在整个软件生存期中实施管理和技术规程的过程，它标识、定义系统中的软件项并指定基线；控制软件项的修改和发行；记录和报告软件项的状态和修改申请；保证软件项的完整性、协调性和正确性以及控制软件的存储、处理和交付。
风险管理：
软件风险是有关软件项目、软件开发过程和软件产品损失的可能性。
软件风险又可区分为软件项目风险、软件过程风险和软件产品风险。
案例：
教育管理系统项目（wbs基于可交付成果）
（1）
（2）风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。
下面主要关注软件开发中的主要风险，但是这只是项目风险中的一部分，在资金、预算、合同等方面都存在风险。
软件在需求分析阶段、设计阶段、实现阶段以及测试维护阶段等，会出现不同的风险。
需求分析阶段的风险：
是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。
需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级级地放大，因此本阶段的风险最大
设计阶段的风险：
设计本身的风险主要来自于系统分析人员。
分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。
设计阶段蕴涵的另一种风险来自于设计文档。
文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正
开发测试阶段的风险：
源代码书写的规范性，可读性是该阶段的主要风险来源。
维护阶段的风险：
在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。
体系结构方面的风险:
在实现上，对开发人员的技术要求，以及在实现良好的软件构架和稳定的组件方面，也存在风险性。
软件体系结构影响到软件的如下质量因素：
软件的可伸缩性；软件的可维护性：
软件易用性：
项目管理中的风险：
软件是否能够按工期的要求完成；软件需求的调研是否深入透彻；软件的实现技术手段是否能够同时满足性能要求；软件质量体系是否能够被有效地保证
风险管理贯穿于整个项目生命周期。
风险管理包括三个阶段：
风险标识别、风险量化以及风险规避。
和其他的软件项目一样，在教育管理系统项目中也存在着许多风险。
我们将风险影响划分为四级，从高到低为:
一级、二级、三级、四级，级别越高，表示风险
升级会员 