CMM课程笔记及作业

思考题（一）：1、试举例说明过程的各个要素；2、为什么要进行需求管理，需求管理的主要任务是什么？3、CMM 2级的一个关键过程域，为什么不称“软件需求管理”，而称“需求管理”。

4、为什么要作风险管理，要在什么时候作？5、你是否有在项目中因未作风险管理而遭受孙数的教训？是什么风险，应怎样对待？6、你认为在自己的组织中实施软件评审的主要障碍和实际困难是什么？7、简要说明软件质量保证工作的主要任务。

思考题（二）8、举出软件配置管理失误的实例、教训在哪里，加以分析。

9、变更管理的要点是什么？10、人们普遍认为软件企业实施ISO9000标准不应以是否获证论成败，那么应根据什么？11、八项质量管理原则具有鲜明的实践性和指导性，请结合自己的实践，表明对其中1－2项原则的体会。

12、软件企业按ISO9000标准监理质量管理体系最难解决的问题是什么？思考题（三）13、CMM的KPA为什么要规定五个共同特征？它和目标目标有什么关系？这一设置方法对其他领域的管理有普遍意义吗？14、SEPG、SQA、SCM、SCCB人员的职责是什么？15、在LPA SPE中对软件工程项目要做的工作规定了要求，这些要求必要吗？合理吗？可行吗？目标：1、理解软件过程的概念2、理解软件过程存在的问题及过程改进的意义3、掌握软件工程管理的基本概念和方法4、掌握ISO9000及CMM2、3级的要求基础：1、先修课－软件工程掌握软件工程的基础知识和软件开发方法2、参加过软件开发工作具有软件开发的实践经验3、参加过软件管理工作具有软件项目管理的实践经验教训比经验更可贵特点：1、实践性2、年轻3、文化―――――――――――――――――――――――――――――――――――――――内容：1、软件工程与软件过程2、软件工程管理专题需求管理软件风险管理软件评审软件质量和质量保证软件配置管理3、ISO9000：2000标准4、软件能力成熟度模型CMM－问题的提出－能力成熟度－CMM结构－2、3的关键过程域RM OPFSPP OPDSPTO TPSSM ISMSQA SPESCM ICPR－CMM应用－CMM I简介参考资料：1、Carnejie Mellon University, software engineering InstituteThe capability Maturity Model guidelines for inprobing the software process reading ma Addison-wesley 1994(CMM 1．1版文本，网上可见)2、郑人杰等，课本3、能力成熟度模型（CMM）：软件过程改进指南，刘孟仁等，电子工业出版社200不4、郑人杰等，软件工程高级教程，清华大学出版社――――――――――――――――――――――――――――――――――教学形式1、讲课―――――笔记（*部分）－重点黄色标记2、课后阅读3、思考、讨论4、作业题考试1、时间：11月2日上午9：00－12：002、形式：开卷笔试，独立完成，不得交流3、要求：a)在讲课范围内b)CMM 1.1文本的理解和使用软件工程和软件过程内容一、发展二、焦点三、软件开发流程四、软件生存期五、软件过程一、发展―――程序设计语言Programming LanguageALGOL60 机器语言FORTRAN 汇编语言COBOLBASIC―――软件Software 1960 程序、文档、数据―――软件危机引出软件工程1、软件开发工程化1968 NATO2、软件开发阶段与瀑布模型3、软件工程标准二、焦点―――目标少资源、高效益在人力投入、开发期、成本、质量诸方面求得最佳―――风险需求：不明与变更人员流动软件知识产权保护不存在绝对缺陷的软件产品―――成功的标志如期完成预算内完成达到质量要求（需求和期望）软件业和制造业的差异§――设计――§――生产――§§运输§§仓储§功能度（缺图例）三、软件开发流程（图二）四、软件生存期Life Cycle―――软件生存期的概念―――软件生存期模型瀑布模型计划－需求分析－设计－编码－测试－运行/维护定义阶段―――开发阶段――――运行阶段XXXXXX五、软件过程1、过程思维―――什么是过程将输入转化为输出的一组彼此相关的资源和活动（资源：人员、资金、设施、设备、技术和方法等）为达到一个预期的目的所实施的一系列不扎欧，例如，软件开发过程－IEEE－SDT－610一组将输入转化为输出的相互关联或相互作用的活动―――ISO9000―――过程的作用过程应支持业务目标，服务于目的的要求过程的实施把机构、管理者、人员和技术基础设施汇聚起来―――过程思维一个群体为了追求某个目标，把每个人的精力和活动汇聚在一起，用对过程的共同理解去考虑问题过程思维和传统的任务思维有着本质的差别―――所有产品的生产都是经历生产过程而得到的―――生产的每个阶段可视为生产过程的子过程，它可分为：直接过程：如市场调研、产品设计、生产制作、检验、包装、储存等；间接错成（支持过程）：如检验手段的控制、不合格品的控制、人员培训、质量审核等――－过程要素：输入、输出、活动、任务（作业）、资源、测量与验证（☆）、效果：增值―――过程间的关系包容邻接交错（部分重叠）并行2、软件过程―――对软件过程的认识尚未摆脱软件危机的困惑项目大、负责、要求高用户对软件产品不满意；软件开发超支、超期、质量不佳频繁发生软件缺陷引发的系统事故。

―――认识的转变软件产品的质量很大程度上取决于软件过程（人员、技术、过程位于三角形顶点，质量生产率位于中心）关注点的转移（软件产品－软件过程）3、ISO /IEC 12207软件生存期过程标准简介―――软件生存期过程－基本过程（获取过程、供应过程、开发过程、运行过程、维护过程）－支持过程（文档编制过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审核过程、问题解决过程）－组织过程（管理过程、基础设施过程、改进过程、培训过程）2003年10月12日星期日（第二课）软件需求和需求管理内容：1、软件需求2、需求工程3、需求变更4、需求变更控制要求5、需求变更控制实施6、可追溯性管理一、软件需求1、系统需求分析（图1、系统需求分配）2、软件需求（1）定义（IEEE－STD－610）用户为解决某个问题，或成为实现某一目标，需求软件必须满足的条件和能力。

（2）软件需求的三个层次业务要求用户要求功能和非功能要求非功能需求：过程需求：交付需求，实现需求，遵循的标准性能需求：速度，容量，可靠性外部需求：互操作性，伦理性，机密性，安全性，使用要求图2软件需求的层次（参见书P59）（3）质量功能展开（QFD－Quality Function Development）客户要求：常规需求：客户明确提出期望需求：并未明确提出的潜在需求兴奋需求：客户未想到，若实现客户感到意外（4）分配需求的实例（图三）（P58 图）3、CMM 2级关键过程域需求管理（KPA RM）中对软件需求的解释：分配需求（allocated requirements）：分配给软件的系统需求（1）分配需求包括（P57－58）第3点――影响和确定软件项目活动的非技术性需求（在合同条款中规定），如：要交付的产品交付日期里程碑――软件的技术需求，如：最终用户、操作人员、支持或集成的功绩性能需求设计的约束条件编程语言界面要求――用于确认软件产品满足分配需求的验收准则（2）分配的需求应当是以软件来实现是可行的，而且是适合的已得到清晰二正确的阐述相互之间是一致的可以测试的同时，分配需求应当：被管理和控制（如必要课纳入软件项目配置管理）是制定软件开发计划SDP的基础是指定软件需求的基础（3）与分配需求相关的组软件估算组系统工程组系统测试组软件质量保证组SQA合同管理组文档支持组软件工程组二、需求工程1、需求工程＝需求开发＋需求管理图4需求工程的构成（参见P60 图）图5需求开发和需求管理（参见P60 图）2、需求开发（参见P61）（1）获取需求确定目标用户、服务对象明确用户代表用户培训了解实际业务和业务需求（2）分析需求分清功能需求、性能需求、使用需求……必要性可行性（3）定义需求编写软件需求规格说明（SRS）作用要求：完整、正确、可行、无歧意、可验证形式：图表文字（4）验证需求三、需求变更1、难于完全避免图6 需求的变更（参见P61 图3.6）2、需求变更原因分析1)单纯的用户因素2)市场形式变化3)系统因素4)工作环境和要求变化5)需求开发的缺陷需求分析、定义和评审不充分与用户沟通不够3、需求变更对软件开发的影响1）使变更前开发工作和成果失效2）返工成为被迫采取的对策3）工作量及资源投入的增加使开发成本提高4）项目完成时间后延4、需求变更失控可能导致的后果（1）未受控的需求变更引起需求和实现不一致图P62（2）受控的需求变更使需求和实现一致图P62（3）5、需求变更风险的策略（1）与用户充分沟通与用户共同明确确定的需求的意义表（参见P63表）向用户说明需求不确切或频繁变更对开发工作的冲击使用户理解过多变更最终对用户不利（2）与用户共同确定需求，作为合同附件，签字生效（3）合同中含有对需求变更的条款（4）采用原型方法开发，或螺旋模型开发（5）项目计划中适当留有余地（时间进度、人力投入、费用等）（6）严格实施变更控制四、需求变更控制要求1、变更控制的策略（1）所有需求变更必须遵循需求变更控制规程实施变更规程：procedure 5W1H什么任务描述什么目的、目标何时环节何处谁责任人如何作步骤以上文档化（2）需求变更提出后是否被接受，应由专门的组织－变更控制委员会（CCB－Change Control Board）审查决定（3）不得以任何理由删除和修改需求变更的原是文件（4）应将已接受的需求变更通知到所有相关人员（5）已接受的需求变更应能追溯到批准的变更请求（6）对项目的需求赋予状态属性，以利于需求变更的控制2、需求变更影响的控制按CMM2级RM KPA的要求，由于分配需求的变更导致软件计划、工作产品和活动的变更，都应对其作：识别评价风险分析编制文档制定计划传达给受影响的小组和人员跟踪直至结束3、变更控制的步骤（1）提出变更请求（2）审理变更请求，进行变更影响评估、评估内容包括：变更所需人力投入变更对原计划安排的影响估计变更引起的成本增加（3）批准变更请求（4）取得用户的认可（5）修订项目计划（6）实施变更（7）验证变更图8（参见P64图3.8）五、需求变更控制实施1、需求变更请求（1）内容申请号变更说明变更类别……..（2）需求变更请求实例（表三需求变更请求）参见P65表格2、表四需求变更累积表参见P66表格3、需求控制流（1）需求状态及其演变软件需求在后继阶段开发工作中将逐步展开，加以实现在不同的开发阶段软件需求以不同的像是进行着状态的演变。