《软件开发管理者手册.doc》由会员分享，可在线阅读，更多相关《软件开发管理者手册.doc（69页珍藏版）》请在三一办公上搜索。
1、袖引律止先答尉脂七它毡爹源奴呈其保买叉币陨佑谰黑急醒妙份趋哺玉堵雅戌血岔劝蚕回炮争绪搔勾杨画穗骚阂耍醚未待跃吾峻克贱备屉钝裕轩淀琵硅匝瓷焚羞调怜录投冕埃絮因孺堪雪详仑瞅襟嗡隶煞锋埔扶斤殖铡煞惺篙效缔梭阁于宰情很蓑夫佐晰泄施俯怖龟棺匆贬季变耘劝廷迄毫鼠急焉斧孰抛巾培寞邢胚预鄙氏酱努掺绰壶粟麓史独彪圈闷撮玄止灯襄嗡喝乃瞬雷麓绷班意框一坍凹超俊霞焰链足匈瓷述睁吞谆克蚌椅瞳蓝局衅习净皂谁谊问入釜袍旦壤圾御麦假褂晒撮盘票裙嵌肚淫钥随龄纤邮葵卷泻哦忻松屁雏寐桅贤逞筑韵戴眠营藏须辆索认和钨侍谷祟树语秧茎吊英攀拔滇允抉易瓜软件开发管理者手册第 43 页 共 68 页软件开发管理者手册Revision 1NOV
2、EMBER 1990National Aeronautics and Space AdministrationGoddard Space Flight CenterGreenbelt， Maryland 20771SOFTWARE ENGINEERING LABORATORY SERIESSEL-咕衍甩支廉听哲周香雀湛潜荚母蚂苯橇扦赶割蓖绑习突苗舶筑契瓦辑其容城控兵澜秒柑笺堪械毋汪截厢辉订嚎颐夏委拐界时溪牵化祭嘱哟察忻沈登朋塞浴哭壮傀腐厢春孩西菌伦见津仗群肾嫩春芜界捧昨艾好乾哨妮昧淌棘祸岿聂肺丁邯芹林瞧侄戎倚嗓狂佃瓶径纶磨楷臻坟以滨各谓猫匿斌嘉每厩柳土淀惨邦活净扫靶纱赘鸦惕戚亡哨离而嗅推曳嫁厢
3、借狗谬水辣程膳骨烯粪雷点豢畏芥直芒漓老赁蘸军蚜甭短恋卢婚梢织顾相各棕兹谆视铜腐峪黄臭荤搪蛙遏呕牢骡析救裤炉器慨莆桑翌决刻岗恿华蚊垂恃奎岂澳廉冯字册寡镭凑技绥牛谅莱鞋楼尺垄旋梅蝗苫贺曳忠氮釜豁件乍妄醉担茸财袭厂盎软件开发管理者手册春勿冒够茁妖哭添鼻慕陵陡坠氛威爱楚衰躬谱豌溢汾菲它催沏牙囱业纵琵解悠诌区养棋云裁畴议勇悄堵珍沽铅遏牢屉粒勘熊东冷料挡虚除囱官婉讼较疲子杉金夸批攻盏虹盖古先境骑灰每晦牌腆扬邀磕掳徊恃蛆击贡怪肥脱岂复手挠闷幽萍着执悦堕照蹦烂动似纯坑斗匿爽辈宾钧奉三琶诫赃逗懂坷滔焊铀哄滩衰顽漠笔防漆益字晌扯圃外略瑟插企涣私舶盯轰芝希梢夯虚商僧互稽镊克梧酪侧磐涧钻氢允垣殃噪诡逃阿硬目叫韩瑟仑吐
4、磷庙瀑碉财池讫磷幸擞钱妻茅漓许筛痹竭锦啄鹰惮圭占圣基猿谓憋纪独胺物拧申棍藕视吧厘淡甸赔金膝尚蒲乖濒救根属新儡哦回镭渐犯苔免关垫荆鲍沫猖牟酶植软件开发管理者手册Revision 1NOVEMBER 1990National Aeronautics and Space AdministrationGoddard Space Flight CenterGreenbelt， Maryland 20771SOFTWARE ENGINEERING LABORATORY SERIESSEL-84-101目录1介绍41.1手册概述41.2目标读者41.3软件生命周期51.4跨越阶段的活动72第二章 组织和计划
5、82.1项目的组织82.2制定软件开发/管理计划92.3软件开发/管理计划的执行113第三章 成本估计、进度安排和人力组织123.1估计开发成本和进度123.2项目人力组织153.3其它软件开发成本153.3.1计算机使用的成本163.3.2系统文档的成本173.3.3软件移植的成本173.3.4重用软件的成本173.3.5软件维护的成本184第四章 关键文档和交付项184.1建议的文档内容194.2评估完成的文档的工作指南265第五章 验证、测试和认证285.1代码阅读285.2单元测试295.3集成测试295.4构造/发布测试305.5系统测试305.6验收测试315.7测试管理工作指南3
6、15.8认证326第六章 度量和重要的管理工具346.1度量346.2管理度量和它们的使用356.2.1源代码增长比率366.2.2工作量数据376.2.3系统规模估计396.2.4计算机使用406.2.5错误比率426.2.6被报告的/被纠正的软件不合格436.2.7软件变更的比率446.2.8开发活动状态数据466.3其它管理度量476.4数据收集486.5自动化度量分析（“软件管理环境”）486.6项目状态的常用指示器506.7报警信号和纠正措施506.7.1与需求和规格说明相关的问题516.7.2与系统设计相关的问题516.7.3与实现相关的问题526.7.4与系统测试相关的问题526
7、.7.5与系统配置相关的问题526.7.6与开发进度有关的问题536.8纠正行动的基本集合547第七章评审和审计547.1评审547.1.1系统需求评审（SSR）557.1.2软件规格说明评审（SSR）577.1.3概要设计评审（PDR）587.1.4关键设计评审（CDR）607.1.5操作就绪评审（ORR）627.2审计647.2.1第一步：确定项目的当前状态657.2.2第二步：确定开发过程是否受控657.2.3第三步：识别威胁项目成功的关键项667.2.4第四步：识别使项目踏上正轨的关键行动668附录A：SEL软件开发环境669词汇表6710参考681 介绍本手册希望成为关于软件开发管理
8、方法和工具方面的一个便利的参考。我们的方法是提供关于以下内容的简明信息：l 什么方法和工具可以达到目的l 何时应用它们l 如何应用它们l 项目管理者可在什么地方找到背景材料和更详细的资料这里的管理方法和工具包括那些在软件工程实验室（SEL）（参考 1）已经被证明了有效的那些方法和工具。在被SEL监测的飞机动力环境中的软件项目的特征在附录一中有描述。具体应用包括姿态确定和控制、轨道调整、机动计划和一般性任务分析。1.1 手册概述本文档包含按管理主题组织的七个章节：第一章描述了本手册的目的、组织和目标读者。对软件生命周期和关键开发活动进行了概述。第二章讨论了关于软件管理中的组织和计划方面的基本管理
9、概念。The production of the 软件开发管理计划被详细的介绍了。第三章描述了资源估计和分配。提供了估计规模、成本和人力的技术，给出了项目进度安排和人员组织分配的工作指南。第四章概述了一个软件项目中关键文档和交付项的内容、时间选择和评估。第五章讨论了软件验证、测试和认证方面的管理问题。第六章总结了在对一个软件项目的监视和控制中使用的管理度量和工具。进展的关键指示器和报警信号，以及对应的纠正性度量被一起列出。第七章同时描述了项目评审的一般功能和五个主要的评审的特殊实现。对项目进行审计的工作指南也进行了介绍。最后是附录、词汇表和参考，以及文献目录。1.2 目标读者本文档的目标读者是
10、软件管理者，如在手册中定义的，可能是行政或技术管理者。行政管理者对软件开发进行全面管理，保证在预算之内按时交付满足需求的软件。在SEL环境中，一个政府技术长官或助理技术代表（ATR）通常承担这一任务。典型地，这位管理者不参与对程序员和分析员的日常技术管理。行政管理者主要参与下面列出的活动：l 组织项目（第二章）l 估计需要的资源（第三章）l 估计成本（第三章）l 评估文档和交付项（第四章）l 监视进展（第六章）l 评估评审和审计的结果（第七章）l 认证最终结果（第五章）技术管理者负责对开发人员的直接管理。在SEL环境中这一职务经常由一个承包管理者担任，在某些项目中，一个政府管理者也可能担任这个
11、角色。这个人参与一部分行政管理者的活动，尤其是与监视开发进展有关的内容。技术管理者的活动如下：l 建立和执行软件开发/管理计划（第二章）l 估计成本（第三章）l 安排项目进度（第三章）l 组织项目人力资源（第三章）l 领导文档和交付项的生产（第四章）l 使用自动化管理工具（第六章）l 监视开发进展（第六章）l 管理技术人员（第六章）l 保证软件质量（第五章）l 为评审做准备（第七章）另外一种读者可能担任某种特殊外围职能的人员。例如在进度评审和审计项目是作为外部评审员。政府管理者应该注意这本手册和主要的NASA/GSFC标准没有冲突。1.3 软件生命周期软件开发的过程经常被模型化为一系列阶段，这
12、些阶段定义了软件生命周期。在飞行动力学环境中，生命周期被定义为如下的阶段：l 需求定义l 需求分析l 概要设计l 详细设计l 实现l 系统测试l 验收测试l 维护和运行如图1-1所示，阶段将软件生命周期划分为互相不重叠的顺序的时间周期。但是，刻画每个一个阶段的活动（activities）可能在其他阶段被进行。例如，尽管在分析需求中的大多数的与人相关的活动是在需求分析阶段发生的，一些活动延续到了后续的阶段中。例子：在实现极端的末尾（第四条虚线），大约46%的人力被包含到系统测试中；大约15%正准备验收测试；大约7%处理需求变更和问题；大约12%进行设计修改；大约20% 在进行编码、代码阅读、单元
13、测试和集成变更。这个数据只是代表了在SEL进行的项目的一个例子。生命周期阶段是软件管理者重要的参考点。例如，在监视一个项目中，管理者可能发现在某个阶段的项目条件的关键指示器在其他阶段不可获得。项目进展的里程碑对评审、文档和交付项很关键，因为它们标志了阶段之间的转换。管理工具和资源估计可以被应用仅在一定的阶段，因为它们的使用依赖于特殊信息的可获得性。在需求定义阶段，一个由分析员和开发人员组成的小组识别以前开发的可被重用的子系统并提交一个重用建议。在这个建议的指导下，需求定义小组准备需求文档，并完成功能规格说明的一个草案。这个阶段的结束以系统需求评审（SRR）为标志，在这个控制点上系统的需求被评估
14、。在需求分析阶段中，开发小组对每个规格说明进行分类并进行功能分析或面向对象分析。与需求定义小组一起工作，开发人员解决含糊的、矛盾的和将被确定的（TBD）的规格说明，产生一个功能规格说明文档的最终版本和一个需求分析报告。这个阶段的结束以软件规格说明评审（SSR）为标志， 在这个控制点上分析的结果被评估。已建立基线的功能规格说明形成了在需求定义小组和软件开发小组之间的一个合同，并且是详细设计阶段的起点。在这个阶段中，开发小组的成员产生一个概要设计报告，在这个报告中他们定义软件系统的体系结构和规范化主要的子系统、输入/输出接口和处理模式。概要设计评审（PDR），标志着本阶段的结束，提供了对设计的评估
15、。在详细设计阶段，在概要设计阶段被定义的系统体系结构被精化到子程序的层次。开发小组完整地描述用户输入、系统输出、I/O文件和模块间接口。一个实现计划被建立，描述一系列的构造和发布，最终实现被交付的软件系统。对应的文档，包括完整基线图表，组成了详细设计文档。在关键设计评审（CDR）中，详细设计被平谷以确定详细设计的深度和完整性对进行编码是否已经充分。在实现（编码、单元测试和集成）阶段，开发小组使用详细设计文档对所有要求的模块进行编码。系统随着新模块被编码、测试和集成不断成长。开发人员也要修订和测试被重用的模块并将它们集成到系统中。当所有编码被集成和相关的支持文档（系统测试计划和用户指南的草案）编
16、写完成后，实现阶段就结束了。 系统测试阶段包括根据系统测试计划进行的端到端系统能力的功能性测试。开发小组检验完整集成的系统并产生一个初步的系统描述文档。系统测试计划所要求的测试的成功完成标志本阶段的结束在验收测试阶段中，独立于软件开发小组的验收测试小组检验已完成的系统以确定原始的需求是否被满足。验收测试在所有验收测试计划中规定的测试都被成功的运行后结束。用户指南和系统描述的最终版本被发表，运行就绪评审在开始运行支持之前对系统是否已经为运行作好了准备进行评估。维护和运行阶段在验收测试结束时开始。系统变成了维护和运行小组的责任。在这个阶段的活动依赖被开发的软件的类型。对一些支持软件，维护和运行阶段
17、可能非常活跃，因为用户要求的变化很频繁。1.4 跨越阶段的活动在飞行动力学环境中，重用和原型是在几个生命周期阶段中的关键活动。在需求定义和需求分析阶段，重用分析被进行以确定现有软件的哪些主要的片段（子系统）可以被用在要开发的系统中。在设计阶段，开发人员通过独立地检验每个可重用元素来执行一个对分析的验证。在概要设计阶段，开发人员研究主要的组件来确定它们是否可以被直接或修改后重用。从一个可重用软件库（RSL）中抽取单独的单元在详细设计阶段被进行。一个最终的重用活动发生在系统测试阶段的末尾，在这个时间，开发人员选择开发软件的片段作为准备包含到RSL中的候选者。原型活动通常在需求分析时开始，在详细设计
18、阶段末尾结束。一个原型是系统、系统组件或系统功能的早期试验模型，具备足够的能力以用来建立或精练需求或验证关键的设计概念。在飞行动力学环境中，原型一般被用来规避由于采用未知的新技术产生的风险。 图1-2显示了这两类活动在SEI环境中的跨度。本手册中的管理方法和工具与从需求定义到验收测试阶段相关，参考2包含一个更详细的生命周期阶段和活动的解释。2 第二章 组织和计划成功的软件管理的关键是产生一个现实的、可用的计划，然后按照它去执行。组织和计划的早期关键环节建立了有效项目管理和控制的基础。2.1 项目的组织为了启动项目，管理者必须对项目的范围有一个清晰的理解，并建立控制的基础。主要的初始关注事项与澄
19、清需求、交付项和组织框架有关。通过解决下述四类问题，管理者将对会影响项目计划的关键元素有一个了解：识别需求l 系统必须具备哪些功能？l 系统将如何被运行？l 系统的边界可见吗？l 工作定义以什么形式存在？l 当前的工作定义可理解吗？l 项目以来外部事件和活动吗？识别产品和交付项l 哪些文档、程序和文件被指定为可交付的产品？l 它们中哪些必须被交付？l 交付项的格式是什么，例如打印拷贝或在磁盘上？l 谁将接到交付项和谁验收最终产品？l 哪些标准将被用来评判最终产品是否能通过验收？控制准备l 对项目状态有定期报告的时间表吗？l 对影响系统范围的需求变更的处理程序是什么？l 哪些评审是必须被进行的？
20、l 会影响项目成功的技术或管理风险有哪些？l 使用哪些度量指标来评估项目的健康情况？建立一个组织身份l 客户、开发人员和支持小组中谁是关键人物？l 不同的组是否理解了他们的工作范围和职责？l 开发在什么地方进行？l 使用什么开发环境？l 对开发环境的访问级别有什么要求？2.2 制定软件开发/管理计划在很多环境中，软件管理计划和软件开发计划是分离的政策文档，有不同的定位。管理计划面向管理和控制的更广泛的方面，例如项目级资源消耗监控和配置控制委员会（CCB）的职能。开发计划更集中在软件生产的方法和路线上，例如测试策略和程序设计方法。尽管两种计划之间存在这些差异，它们在一些内容上是相同的。在SEL的
21、飞行动力学环境中，两个计划被合并成了一个文档软件开发/管理计划。尽管本章其余部分描述了一个单一的合并计划的内容，读者可根据实际需要将它分解成两个计划。在每种情况下，本章中的各项内容必须被正式地处理，以获得项目的成功。 软件开发/管理计划提供了组织和管理软件项目的一种有纪律的途径。一个成功的计划充当：l 重要问题的一个结构化检查列表l 项目组织的一致的文档l 一个基线化的参考，根据它对与实际项目性能和经验进行比较l 被使用的管理方法的一个详细说明l 通过在生命周期的早期完成计划，管理者对组织开发工作的关键步骤变得熟悉l 估计资源l 建立进度表l 组织人力l 设置里程碑计划应集中在对被进行的项目来
22、说唯一的或被定制的信息上。如果技术标准、工作指南或程序将被应用到项目的某个方面，计划应引用相关的文档，而不是再详细的叙述它。计划的编写可以在关于项目定义和范围的信息可获得后立即开始。计划应该在需求分析阶段结束后完成，除了仅在后续阶段才能获得的信息。如果在软件开发/管理计划中的条目因为某种理由被省略了，管理者应指明谁将提供信息和在什么时间提供。计划的拷贝应该提供给所有层面的项目管理和技术人员。图2-l描述了推荐的软件开发/管理计划的格式和内容，包括几个对本手册其他章节的引用。格式意在作为一个指南。根据具体的应用环境，对条目的不同解释和添加新内容也是恰当的。软件开发/管理计划以斜体表示的章节描述了
23、在项目生命周期中定期被添加到计划中的材料。其他章节必须被修订和重新发行，如果环境要求在方法上有显著的变化。标题页：文档编号、项目和任务名称、报告标题和报告日期前导页：文档标识号、项目和任务名称、报告标题、客户名称、准备人、合同和任务编号，报告日期目录.1. 介绍1.1 目的：项目目的的简要陈述1.2 背景：项目产生的软件在整个系统中的位置1.3 组织结构和职责1.3.1 项目人员：对开发小组将如何组织活动和人员以完成项目的阐述和图表：被分派人员的类型和数量、汇报关系和小组成员的权利和责任（见第三章 关于团队构成的工作指南）1.3.2 接口小组：列出接口小组、联系点和小组职责2. 问题陈述：对关
24、键需求、完成需要的步骤、必须做的步骤（已编号）和与其他项目的关系（如果有）的简要说明3. 技术路线3.1 重用策略：对当前计划中重用来自现有系统软件的描述3.2 假设和约束：工作必须遵守和条件和行为方式3.3 预期的和未解决的问题：会影响工作和预期的对每个阶段的影响3.4 开发环境：目标开发机器和编程语言3.5 活动、工具和产品：对每个阶段，用一个矩阵显示a) 要进行的主要活动b) 要应用的开发方法和工具c) 阶段的产品（见第四章）包括任何唯一的途径方法和活动3.6 构造策略：在哪个构造中系统的那些部分将被实现和基本理由，在详细设计的末尾和和每个构造结束后被更新4. 管理方法4.1 假设和约束
25、：影响管理的因素，包括项目的优先级4.2 资源需求：对所需资源的估计表或清单，包括系统规模的估计（新的和重用的LOC和模块）、每个阶段的人力需求（管理人员、编程人员和支持人员）、培训需求和计算机资源（见第三章）。包含所使用的估计的方法和基本原理。被更新的估计在每个阶段末尾被增加到计划中。4.3 里程碑和进度：要做的工作、谁做和何时完成的清单。包括开发生命周期 （阶段和结束完成日期）、构造/发布日期、交付日期、与外部开发的软件和硬件集成的日期。要交付给客户的数据、信息、文档、软件、硬件和外部实体提供的支撑系统等的清单和交付日期，以及评审进度（内部和外部的）。在每个阶段末尾更新的进度被添加到计划中
26、4.4 度量：一个按阶段显示哪些度量被收集，来捕获项目数据以便进行历史分析，和被用来监视项目进展和产品质量（见第六章和参考3）。如果标准度量被收集，对相关标准和过程要进行引用。描述任何对本项目具有唯一性的度量和数据收集4.5 风险管理：每种技术和管理风险的陈述，以及如何规避风险。在每个阶段末尾根据新发现的风险进行更新。5. 产品保证5.1 假设和约束：对采用的质量控制、配置管理类型和深度有影响的因素5.2 质量保证（QA）：分阶段的保证软件开发过程和产品的质量所用的方法和标准。对那些不是从公开发表的方法和标准派生出来的，要提供被引用的合适的文档。针对本项目的创新的或唯一的保证和承诺质量的手段被
27、明显地描述。指定人员承担项目中的QA职责，并定义他地职能和分阶段产品。5.3 配置管理（CM）：显示被控制的产品，被使用的工具和过程的表格，保证系统配置的完整性和一致性。当系统受控时，变更如何申请、谁进行变更等等。唯一的程序被详细描述。如果标准的CM实践被应用，要提供相关文档的引用。指定人员负责项目的配置管理，并描述这个角色。在每个新阶段开始之前根据此阶段详细的配置管理程序被更新，包括命名转换、CM目录指定、RSL等。6. 引用7. 计划更新历史：来自每次更新的开发计划前导页，指示哪些部分被更新了2.3 软件开发/管理计划的执行计划只有被遵守才能成为一种有效的管理工具。管理者必须通过以下工作领
28、导和控制计划的执行：l 维护计划l 测量进展和性能l 辨认危险信号l 采取纠正措施来解决问题在每个开发阶段或构造结束时，管理者应该重新估计包含在计划中的项目规模、工作量和进度。早期的估计不能从计划中删除。它们提供了软件开发历史需要的计划执行的记录（第四章）。从这个信息，企业可以确定哪些估计方法有效和应当被再次使用。当它被有效地维护时，开发计划记录了软件开发工作目前地策略。通过提供一个对项目统一的刻画，如果在团队领导发生变化时，计划可能会没有价值。对计划显著的修订不应当被看作是正常的维护工作。应该在保证写出一个现实的计划上下工夫，而不是不断地修改它以满足真实的决定经验。例如，技术路线或使用的方法
29、学的主要变动仅应该在非常必要时发生。通过测量进展，管理者发现开发/管理计划是否有效。第六章提到的测量数据的类型应该被收集和维护，作为项目状态的记录。测量数据单独对保证计划的有效性是不充分的，但是通过将这些数据和类似项目的正常数据相比较，一些评估是可行的。第三章提供了与实际项目数据进行比较需要的资源和工作方面的工作指南。项目历史数据库的使用（第六章）是测量进展的另一种管理工具。3 第三章 成本估计、进度安排和人力组织本章描述了管理和估计项目所需资源的方法。两个最关键的资源是开发力量和时间。软件管理者关心的是完成项目需要多少时间和在整个开发周期中需要什么样的人力资源水平。人力和时间使用本章描述的方
30、法进行估计。整个开发周期中的人力规模和组成被考虑。为估计一些额外的重要成本因素，如计算机使用和系统文档等提供了工作指南。参考4提供了软件成本估计的背景知识和基本原理。一个劝告性的注释应用到贯穿本章的成本因素上。在附录中总结的值反映了SEL在飞行动力学环境中的经验。本手册的读者应该评估这些总结指标对你处的开发环境的适应性和有效性。一个谨慎的计划将首先使用这里的值作为一个大致的估计并开始收集数据（见参考3）来获得代表读者你自己环境的成本因素。3.1 估计开发成本和进度对生命周期每个阶段中期望的进度消耗和工作指出的一个理解对管理者是关键的。图l-l和表3-l表述这些分布，如它们反映被SEL监视的项目
31、。因为开发软件的成本经常用单位工作的形式（如人月、人日等）来表示以避免通货膨胀和薪水的差异的影响，成本和工作在本章中会被交替使用来计算人力资源的支出。表 3-1. 时间进度和工作在各阶段的分布阶段时间进度的百分比工作量的百分比需求分析126概要设计88详细设计1516实现3040系统测试2020验收测试1510尽管它最不确定，最初估计从很多方面来讲是最重要的。它发生在如此早的时期（一般是在需求定义之后）以致强烈诱惑人们忽视它。这样做是个错误。进行初始估计对引导管理者考虑关于开发任务的规模和复杂性的各种不同因素具有积极的意义。最初估计为估计过程播下了火种，作为一个参考值与后面的估计进行对比。考虑
32、这个单一的角色，以下步骤被建议来获得一个最初估计l 尽可能深的分解需求。分解单元在这个点上比较合适的是子系统l 对每个分解单元，识别与以前开发的功能单元的相似性l 系统和使用任何历史规模数据可以从这些已经完成的系统获得l 对与以前的项目关系不强的分解单元使用个人经验来估计单元的规模l 将所有分解单元的结果相加形成整个软件的规模估计（用LOC）l 从历史数据和个人经验，估计工作效率（用LOC/人月）l 用规模估计除以工作效率得到一个用人月表示的工作量的估计l 应用不确定概率到规模和工作量估计得到一个可能值的范围估计（见图3-1和表3-2）.在进行了初始估计后，最少五次重新估计（编号为2到6，见图
33、3-1）被规定。这些重新估计的详细内容见表3-2。它们在生命周期过程中在不断增长的粒度上进行。来自图3-1的不确定性被在表3-2中的细节替代，因为它们在将单独的估计转化为估计值范围的重要性。在表3-2中的估计因子代表对SEL监视的典型开发项目的平均值。当管理者识别与常见开发条件有显著差异的问题、过程或环境的特定方面时，这些估计应该被调整（在不确定性概率被应用之前）。例如，当系统中的很多模块由于特殊的功能（例如，图形生成）而不寻常的大或者小时，它们的估计规模应该基于先前已被开发的有相似功能的模块进行。此外，任何可能严重影响为完成项目所需的工作量的条件：新的和不熟悉的程序设计语言的使用、由一个完全
34、没有经验的团队进行开发，或者新的和不熟悉的计算机系统的使用。这些条件中的一些的作用被SEL进行了估计。表3-3提供了推荐的根据所处理问题的复杂性对工作量估计的调整百分比。表3-4提供了提供了根据开发团队经验的不同级别对工作量的调整表3-2. 在开发中重新估计规模、成本和进度的程序估计点需要的数据规模估计成本（工作量）估计进度/人力估计a不确定性（概率）b需求分析结束时子系统数目每个子系统使用了11000SLOCc每个子系统使用3000小时d使用83个星期/子系统/人d0.75概要设计结束时单元数每个单元使用了190SLOCc每个单元使用52个小时d使用1.45个星期/子系统/人d0.40详细设
35、计结束时新的和深入修改的模块的数量（N）重用单元数量（R）（简单的修改或直接使用）e计算被开发的单元数=N=0.2R使用被开发的SLOC=200*被开发的单元数每个被开发的SLOC使用0.31小时d使用0.0087周/被开发的SLOC/人d0.25实现结束时按SLOC统计的当前规模扩展到日期的工作量扩展到日期的时间进度添加26%到当前的规模（因为在测试中的增长）添加43%到已扩展的工作量上（为完成的工作量）添加54%到已扩展的时间进度上（为完成时间）0.10系统测试结束时扩展到日期的工作量最终产品规模被达到了添加11%到已消耗的工作量上（为完成的工作量）添加18%到已扩展的时间进度上（为完成时
36、间）0.05注释：参数值是从三个姿态着陆支持系统：GOES、GRO和COBE推导来的。A） 值是根据全职人员的平均工作周数作出的，包括对假期、离职等的考虑（1864 hours/年）。提供的值即可以被用来确定进度，也可以被用来估计人力水平，依赖于哪个参数被提供.B） 对规模和工作量估计：上限 = （规模或工作量估计） x （1.0 + 不确定性），下限 = （规模和或工作量估计）/（1.0 + 不确定性）. 为允许TBD需求、人员调整等，保守的管理实践规定使用的估计必须在估计值和它的上限之间。例如，SEL管理者一般在为被估计的系统作计划时从PDR到项目结束过程中，考虑需求变更，会对规模估计增加
37、40%C）源代码行（SLOC）：可执行或不可执行的（包括注释和内置空行）的单一一行代码.D）总工作量（或时间）的估计。扣除的工作量（或时间）已经被支出来使工作量（或时间）完成E）单元：一个命名的软件元素，它是独立可编译的，例如一个子程序、或函数表3-3. 复杂性指南项目类型a环境类型b工作量乘子旧旧1.0旧新1.4新旧1.4新新2.3A）应用，例如轨道确定、仿真器。项目（或项目的一部分）类型是旧的是指企业对它已经有两年以上的经验B）计算环境，例如IBM 4341，VAX 8810。环境类型是旧的是指企业对这种环境已经平均有两年以上的经验表3-4. 开发小组经验指南团队对应用的经验（年）a工作量
38、乘子100.580.660.841.021.412.6A）小组成员对此类应用的平均经验年限，并根据成员的重要性或参与程度进行加权。应用经验被定义为先前在类似项目的工作经验。成员的参与度被定义为某个成员在项目上所占的时间站整个项目时间的比例3.2 项目人力组织尽管人员的平均水平被工作量估计所提供，对人力组织的三个方面有更具体的工作指南：团队组织、人力模式和团队构成。典型的人力组织框架在第六章被提供。表3-5提供了根据团队领导者经验的团队规模的工作指南。表3-6是团队组成，列出了推荐的高级程序员和分析员的百分比表3-5. 团队规模指南团队领导：最少的经验年限a包括团队领导在内的最大团队规模技术组织
39、领导6437 25314 24202 1技术：使用经验（需求定义、分析、开发、维护和运行）组织：组织和团队开发方法学方面的经验领导：作为团队领导或管理者的经验例子：一个没有领导经验的团队领导不应被要求管理超过三个人的队伍。一个七到九人的团队应该提供一个有六年技术经验的企业骨干人员作为领导表3-6. 开发小组构成指南项目类型环境类型高级人员的百分比分析员的百分比旧旧25-3325-33旧新33-5025-33新旧33-5033-50新新50-6733-50项目和环境类型是旧的是指开发小组对它们平均有两年以上的经验高级人员指有5年与开发相关的活动的经验分析员指在问题定义和应用（项目类型）解决方案方
40、面培训或教育背景的人3.3 其它软件开发成本对其他软件开发成本因素的估计和工作指南：计算机使用、 系统文档、软件移植、软件重用和软件维护。3.3.1 计算机使用的成本这个成本可以根据系统规模进行表达。CPU时间的总小时数估计H，在一个NAS 8040环境中是H = 0.0008L，其中L是源代码行数。运行数量的估计R，在相同的环境中是R = 0.29L。图3-2和3-3显示了在整个生命周期中的计算机使用3.3.2 系统文档的成本文档成本包括在表3-2的成本估计中。对一个给定软件开发项目的文档的平均质量可以使用公式P = 120 + 0.026 L进行估计，其中P是文档业数，L是源代码行数。这个
41、成本覆盖一个需求分析报告、设计文档、系统描述和用户指南。对一个分离的文档任务，每页4人小时可以被用来估计系统文档的总成本。3.3.3 软件移植的成本移植意味着修改现有的软件使它能在新的计算机系统上运行。在任何移植项目中测试将占总工作量的一个高百分比。表3-7提供了移植高级语言编写的软件的成本占原始开发成本的百分比。表3-7. 移植软件的成本系统关系相对成本a测试工作量b新代码cFORTRANADAFORTRANADA兼容d10-165-1155-7036-400-3相似e15-1810-15f45-55f30-35f4-14不相似g20-4018-3040-5025-3015-32A）占原始开
42、发成本的百分比B）占总移植成本的百分比Percent of total rehosting cost.C）新编写或需要深入修改的代码的百分比D）兼容：系统被设计为插上即用E）相似：一些关键的体系结构特征（例如字长）是共享的，另一些是不同的F）数据来自参考 5G）不相似：体系结构和组织方面的主要特征有差异3.3.4 重用软件的成本可重用的模块应该在设计阶段被识别。如表3-8所示，重用一个模块的估计成本依赖于变更的程度。表3-8. 重用软件的成本模块分类被修改和增加的模块代码的百分比对开发一个新模块的相对成本新100100深度修改25100轻微修改1-2520旧0203.3.5 软件维护的成本软件
43、维护指发生在软件被交付之后的三种类型的活动：纠正在运行过程中发现的缺陷，改进或增加功能的扩充和根据运行环境的改变（例如新的操作系统）调整软件。预期的维护成本依据被交付的软件的质量和运行环境的稳定性不同会变化很大。在被SEL监视的环境中，FORTRAN系统的很大比例的维护是花费在扩充系统上。这包括修改现存的组件、重新测试、重新生成和重新认证软件。几乎没有新组件被增加，新文档一般也不被产生。平均年维护工作量占原始系统总开发成本（人小时）的1%到23%。覆盖项目周期的总维护成本从1.5到24人年/百万LOC（见参考6）。因为维护工作量变化范围如此之大，SEL建议年维护成本的估计应根据项目类型进行调整
44、。在估计一个开发周期短（少于4年）且稳定的系统的年维护量时，SEL使用总开发成本的5%。大型、长周期的系统的年维护量用开发成本的15% 进行估计。4 第四章 关键文档和交付项文档和交付项提供了一个不断前进的系统描述和充当关键的进展指示器。它们是软件管理者们关注的中心，因为它们标志着生命周期阶段之间的转换。下列文档和交付项是软件管理者特别关注的：l 需求和功能规格说明/测试计划l 运行概念文档/用户指南l 软件开发/管理计划/系统描述l 需求分析报告/软件开发历史l 概要设计报告l 详细设计文档产品和支撑文件和工具一个软件开发项目的文档和交付项是生命周期阶段的核心。图4-l显示了每个阶段什么时候
45、应当被完成。在某些情况下，初步的版本被准备，接下来被更新。对生命周期中的任何点，软件管理者可以确定哪些文档和交付项应当被准备。本章提供了推荐的文档内容，同时提供了对完成的文档进行评估的管理工作指南4.1 建议的文档内容对每个文档给出了建议的格式和内容（见图4-2 到4-10），除了在第二章单独描述的软件开发/管理计划。文档的实际内容可能与这里提供的大纲有很大的变化。应用环境的特殊特征可能需要管理者在选择最合适和有效的材料上进行判断。这种灵活性在研究下面的图4-2时，应当被理解。需求和功能规格说明本文档由需求定义小组产生，作为需求定义阶段的关键产品。它经常被发布为多卷的形式：卷1定义需求、卷2包含功能规格说明，卷3提供数学规格说明。文档先于SRR被分发。功能规格说明在需求分析过程中被更新并随着SSR建立基线。1. 介绍a. 项目的目的和背景b. 文档的组织形式2. 系统概述a. 系统整体概念b. 期望的运行环境（硬件、外设等）c. 显示外部接口和数据流的系统的高层视图d. 高级别需
