Ch可重复性管理.ppt

Ch可重复性管理.ppt

《Ch可重复性管理.ppt》由会员分享，可在线阅读，更多相关《Ch可重复性管理.ppt（79页珍藏版）》请在冰豆网上搜索。

Chapter5.可重复性管理,“加强纪律性，革命无不胜。

”,可重复性？

虽然没有两场完全一样的战争，但是军事家们同样可以总结出历次战争过程的共性。

通过对战例的总结，获得了面对新战争环境下如何能够利用已有战例经验和教训，设计出“可重复”的战争过程。

“纪律性”是任何军事组织所强调的第一个共性。

铁的纪律是实现“可重复”的基础。

工业化生产的最高境界就是产品生产的可重复性。

具有组织纪律、能够进行大规模生产的产业工人是传统工业生产的基础。

当今对于制造业，可重复生产的最佳途径是无人值守工厂。

ProcessCategories,Management,Organizational,Engineering,Levels/,1Initial,2Repeatable,3Defined,4Managed,5Optimizing,AdHocProcesses,IntegratedSoftwareManagementIntergroupCoordination,RequirementsManagementSoftwareProjectPlanningSoftwareProjectTrackingandOversightSoftwareSubcontractManagementSoftwareQualityAssuranceSoftwareConfigurationManagement,OrganizationProcessFocusOrganizationProcessDefinitionTrainingProgram,SoftwareProductEngineeringPeerReviews,SoftwareQualityManagement,QuantitativeSoftwareManagement,TechnologyChangeManagementProcessChangeManagement,DefectPrevention,CMMLevel2KeyProcessAreas,RequirementsManagement需求管理（RM）,SoftwareProjectPlanning软件项目策划（SPP）,SoftwareConfigurationManagement软件配置管理（SCM）,SoftwareQualityAssurance软件质量保证（SQA）,SoftwareSubcontractManagement软件子合同管理（SSM）,SoftwareProjectTrackingandOversight软件项目跟踪和监督（SPTO）,RequirementsManagement需求管理（RM）,需求管理,软件需求总是不清楚的。

有人把需求的获取看作一个知识获取或学习的过程。

需求的典型输入是一个想法（idea），理想的输出是软件规范说明（Specification）。

一旦一个软件需求能够用形式化语言描述清楚，软件的需求就变得100%清楚了。

需求的获取过程,客户的抱怨：

“我们不知道我们需要的软件是什么，我们只知道你所交付的软件不是我们所需要的，此软件不好用。

”,Requirementsreaders,用户需求,客户经理系统最终用户客户工程师开发方的经理系统体系结构师,系统需求,系统最终用户客户工程师软件开发人员系统体系结构师,软件需求文档,软件开发人员系统体系结构师客户工程师（参考）,需求类型,读者,RequirementsManagement-Purpose,1.需求管理的目的建立客户和项目开发者之间的共同理解（commonunderstanding）2.就客户需求，建立和维护与客户之间的协议（合同）此协议（合同）表示为：

systemrequirementsallocatedtothesoftware.“customer”既可以解释为系统工程组、市场组、企业内部的一个部门，也可以解释为外部客户。

协议要包括技术和非技术性需求协议作为建立、策划、执行、追踪软件项目整个生命周期活动的基础,系统需求分析/设计,HWCI测试,瀑布模型中的需求,系统设计,硬,件,研,制,软,件,开,发,功能基线,分配基线,系统集成和测试,产品基线,软件需求分析,制造,详细设计,初步设计,硬件要求分析,验收/移交,概要设计,详细设计,编码CSU测试,CSC集成和测式,CSCI测试,发,用户需求,系统需求,软件需求,分配的需求,分配的需求,3.系统需求的分配通常，软件只是系统的一部分。

即使是在软件密集的系统中，仍然是这样的。

必须把系统的要求分配给软件需求、硬件需求、以及人（或其他）的操作需求：

这样的分配过程，在大系统研制过程中，往往不是有软件工程组决定的（例如，是由系统工程小组分配的）。

因此，许多情况下，软件工程组不能决定和控制这种分配。

在项目的约束条件下，软件工程组要采用适当的步骤，保证系统分配给软件的需求被表达、编写成正式文档、并控制其变更。

SystemRequirements系统需求,HardwareRequirements硬件需求（项）,SoftwareRequirements软件需求（项）,HumanRequirements操作人员需求（项）,需求管理的目标,1）控制分配需求以建立软件工程和管理所使用的基线。

通常系统工程组会将模糊的需求，或者，只要硬件没法实现的，都交给软件实现。

高估软件的能力，并带来风险。

需求不清晰、以及今后的不断变更造成项目的失败。

建立基线，掌握“类似”的需求，从而达到“可重复”。

2）软件计划、工作产品和活动与分配需求相一致。

开发计划往往会偏离实际的软件需求，直接依据项目经理或客户要求，定义进度和工作产品。

需求与项目的可重复性,需求是项目的最基本输入，也是决定项目之间是否具有类似的基本依据。

当需求清晰后，我们就能对项目的规模、问题领域、大致的软件体系结构、人员所需、时间进度、软件质量要求（包括功能和非功能性）有一个大概的了解。

找出“类似”项目，达到可重复！

一旦需求是非常不稳定的（在开发过程中，不断变更），以前的项目经验就失去意义。

项目的“可重复性”就成为空话！

顺利到达目的地的最快、最安全的路线是你最熟悉的路线！

对功能性需求的理解，可以澄清许多问题，例如：

1）软件需求文档中的用例图（usecases）和部署图能让我们了解未来的系统如何使用和部署。

2）哪些需求的实现难度大、风险大？

通过对非功能性需求的理解,可以澄清许多问题，例如，1）对开发环境、运行环境的理解，能让项目组估计出软件的难度。

2）对行业标准等的理解，可以掌握足够的项目知识，建立与客户的共同理解。

3）对编程语言、数据库等要求的理解，可以清楚对人力资源的要求。

项目的类似性,通过对功能和非功能性需求的理解，我们能够知道所谓的“类似项目”类似在哪些方面，例如，编程语言、用户的行业背景、数据库、软件规模、人力资源、进度、软件缺陷率的要求等。

特别是非功能性的要求，对于确定项目之间是否具有可比性，起着决定性的作用。

例如，实验室使用的求解微分方程的软件与运载火箭上求解微分方程软件，在功能上是一样的。

但是软件质量和运行环境的差别，造就了后者比前者要付出几十倍的费用代价。

例：

针对非功能性需求的改进,EngineeringIngegneriaInformatticaSPA意大利的一家大型软件工厂，420员工，1994年营业额3500万ECU。

目的解决预算的准确性方法扩展开发理念，增强正式说明书中非功能需求（例如易用性、可靠性、可移植性）说明，使得这些因素对软件造成的影响可以在整个开发过程中被跟踪建立自我加强型的生命周期，了解这些因素的影响，从而更好地制定评估和项目计划。

例：

针对非功能性需求的改进,商业收益实验的6个项目，从最初的25%预算误差减少到8%（方法只用于不小于250000ECU的项目）,将非功能性需求文档化,基于以前的经验计划合适的活动,精确费用预算和资源分配,培训客户关于软件质量的问题展示软件能力,项目管理和利润率改进,从需求到开发活动映射的相关知识,SoftwareProjectPlanning软件项目策划（SPP）,项目策划,策划的目的和目标“项目策划”的目的在于建立并维护规定项目各项活动的计划。

“项目策划”包括制订项目计划、与共益者（stakeholders）进行适当交流并且就计划达成一致和维护计划。

“策划工作”是从那些规定产品和项目的需求开始，包括对工作产品和作业的属性及所需资源进行评价、协商各项承诺、拟订进度，以及识别和分析项目风险。

项目计划的开发过程,优化级-不断改进,项目策划中的问题,制定一个项目计划的关键是对产品规模、资源、时间进度的估计。

COCOMO最初发表于1981年巴里勃姆（BarryBoehm）软件工程经济学一书中，作为在软件项中估算工作量、成本以及时间进度表的模型。

巴里勃姆于1981年在该公司担任软件研究与技术总监。

COCOM是基于对TRW飞机制造公司的63个项目的研究。

这些项目所包含的代码量从2000行到10000行，包含的编程语言从汇编语言到PL/I。

这些项目采用瀑布模型进行软件开发，这种开发模式是在1981年时主流的软件开发模式。

1997年开始研发“COCOMOII”，并最终于2001年发表于软件成本估算：

COCOMO模型方法,项目开发中的交流方式,软件的工程管理,项目的组织结构,1972年，首次在IBM使用,矩阵式的组织结构,S,E,M1,M2,M3,M4,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,Requirements,Design,Coding,Integration/testing,Delivery,以瀑布模型为基础的项目计划网络图例,M:

评审点T:

工程任务,关键路径,时间进度,活动时间线,员工工作分配,4,/,7,1,1,/,7,1,8,/,7,2,5,/,1,/,8,8,/,8,1,5,/,8,2,2,/,8,2,9,/,8,5,/,9,1,2,/,9,1,9,/,9,T,4,T,8,T,1,1,T,1,2,T,1,T,3,T,9,T,2,T,6,T,1,0,T,7,T,5,张三,李四,Anne,Mary,Jim,风险管理,Boehm的十个顶级风险项（RiskItem）人员流失（Personnelshortfalls）不实际的进度和财政预算开发错误的软件功能开发错误的用户界面种金子不断的需求更改外部完成的任务的不满足外部提供部件的不满足实时性能不满足过分强调计算机科学的能力,计划的可重复性,简单的计算往往是不可行的。

简单公式：

所需人天=工作量/工作效率并假：

设员工随时可用实际上企业的管理者不希望员工没事做一个员工可能要同时做多个项目员工的风险是最大的风险可重复：

预计到一系列的风险考虑到各种资源等参考原先成功项目的经验吸取失败项目的教训,SoftwareProjectTrackingandOversight软件项目跟踪和监督（SPTO）,项目跟踪与监督,软件项目跟踪和监督要达到的目标为：

1）依据软件项目计划跟踪实际结果和性能。

2）在实际结果和性能明显偏离软件计划时，采取纠正措施并加以管理，直到结束。

3）受影响的组和个人同意对软件承诺的更改。

按照（文档化的）估计、承诺和计划，跟踪和评审软件各阶段完成的情况和结果，并根据实际完成情况和结果调整这些计划。

“软件项目计划”是跟踪软件活动、通报状态和修订计划的依据。

项目管理者需要监控软件项目活动的状态。

特别是在项目计划规定的里程碑和基线处，一定要将实际完成的软件规模、工作量、成本和进度与计划进行比较，以准确判断实际进展情况。

跟踪的准确性,从软件的开发角度来看，大多数情况下，0%和99%的完成，其效果几乎是一样的。

提升软件开发过程可见性的方法是，在0%与100%之间设立合理的刻度（度量指标），用更精确的指标让管理者更清楚实际的进展情况。

下面的