软件开发管理者手册

软件开发管理者手册Revision 1NOVEMBER 1990National Aeronautics and Space AdministrationGoddard Space Flight CenterGreenbelt， Maryland 20771SOFTWARE ENGINEERING LABORATORY SERIESSEL-84-101软件开发管理者手册第 2 页 共 68 页目录1 介绍 41.1 手册概述 41.2 目标读者 41.3 软件生命周期 51.4 跨越阶段的活动 72 第二章 组织和计划 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 测试管理工作指南 315.8 认证 326 第六章 度量和重要的管理工具 346.1 度量 346.2 管理度量和它们的使用 356.2.1 源代码增长比率 366.2.2 工作量数据 376.2.3 系统规模估计 396.2.4 计算机使用 40软件开发管理者手册第 3 页 共 68 页6.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.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 参考 68软件开发管理者手册第 4 页 共 68 页1 介绍本手册希望成为关于软件开发管理方法和工具方面的一个便利的参考。我们的方法是提供关于以下内容的简明信息： 什么方法和工具可以达到目的 何时应用它们 如何应用它们 项目管理者可在什么地方找到背景材料和更详细的资料这里的管理方法和工具包括那些在软件工程实验室（SEL）（参考 1）已经被证明了有效的那些方法和工具。在被SEL监测的飞机动力环境中的软件项目的特征在附录一中有描述。具体应用包括姿态确定和控制、轨道调整、机动计划和一般性任务分析。1.1 手册概述本文档包含按管理主题组织的七个章节：第一章描述了本手册的目的、组织和目标读者。对软件生命周期和关键开发活动进行了概述。第二章讨论了关于软件管理中的组织和计划方面的基本管理概念。The production of the 软件开发管理计划被详细的介绍了。第三章描述了资源估计和分配。提供了估计规模、成本和人力的技术，给出了项目进度安排和人员组织分配的工作指南。第四章概述了一个软件项目中关键文档和交付项的内容、时间选择和评估。第五章讨论了软件验证、测试和认证方面的管理问题。第六章总结了在对一个软件项目的监视和控制中使用的管理度量和工具。进展的关键指示器和报警信号，以及对应的纠正性度量被一起列出。第七章同时描述了项目评审的一般功能和五个主要的评审的特殊实现。对项目进行审计的工作指南也进行了介绍。最后是附录、词汇表和参考，以及文献目录。1.2 目标读者本文档的目标读者是软件管理者，如在手册中定义的，可能是行政或技术管理者。行政管理者对软件开发进行全面管理，保证在预算之内按时交付满足需求的软件。在SEL环境中，一个政府技术长官或助理技术代表（ATR）通常承担这一任务。典型地，这位管理者不参与对程序员和分析员的日常技术管理。行政管理者主要参与下面列出的活动：软件开发管理者手册第 5 页 共 68 页 组织项目（第二章） 估计需要的资源（第三章） 估计成本（第三章） 评估文档和交付项（第四章） 监视进展（第六章） 评估评审和审计的结果（第七章） 认证最终结果（第五章）技术管理者负责对开发人员的直接管理。在SEL环境中这一职务经常由一个承包管理者担任，在某些项目中，一个政府管理者也可能担任这个角色。这个人参与一部分行政管理者的活动，尤其是与监视开发进展有关的内容。技术管理者的活动如下： 建立和执行软件开发/管理计划（第二章） 估计成本（第三章） 安排项目进度（第三章） 组织项目人力资源（第三章） 领导文档和交付项的生产（第四章） 使用自动化管理工具（第六章） 监视开发进展（第六章） 管理技术人员（第六章） 保证软件质量（第五章） 为评审做准备（第七章）另外一种读者可能担任某种特殊外围职能的人员。例如在进度评审和审计项目是作为外部评审员。政府管理者应该注意这本手册和主要的NASA/GSFC标准没有冲突。1.3 软件生命周期软件开发的过程经常被模型化为一系列阶段，这些阶段定义了软件生命周期。在飞行动力学环境中，生命周期被定义为如下的阶段： 需求定义 需求分析 概要设计 详细设计 实现 系统测试 验收测试 维护和运行如图1-1 所示，阶段将软件生命周期划分为互相不重叠的顺序的时间周期。但是，刻画每个一个阶段的活动（activities ）可能在其他阶段被进行。例如，尽管在分析需求中的大多数的与人相关的活动是在需求分析阶段发生的，一些活动延续到了后续的阶段中。软件开发管理者手册第 6 页 共 68 页例子：在实现极端的末尾（第四条虚线），大约46%的人力被包含到系统测试中；大约 15%正准备验收测试；大约7%处理需求变更和问题；大约12%进行设计修改；大约20% 在进行编码、代码阅读、单元测试和集成变更。这个数据只是代表了在SEL进行的项目的一个例子。生命周期阶段是软件管理者重要的参考点。例如，在监视一个项目中，管理者可能发现在某个阶段的项目条件的关键指示器在其他阶段不可获得。项目进展的里程碑对评审、文档和交付项很关键，因为它们标志了阶段之间的转换。管理工具和资源估计可以被应用仅在一定的阶段，因为它们的使用依赖于特殊信息的可获得性。在需求定义阶段，一个由分析员和开发人员组成的小组识别以前开发的可被重用的子系统并提交一个重用建议。在这个建议的指导下，需求定义小组准备 需求 文档，并完成 功能规格说明 的一个草案。这个阶段的结束以 系统需求评审（ SRR）为标志， 在这个控制点上系统的需求被评估。在需求分析阶段中，开发小组对每个规格说明进行分类并进行功能分析或面向对象分析。与需求定义小组一起工作，开发人员解决含糊的、矛盾的和将被确定的（TBD）的规格说明，产生一个 功能规格说明 文档的最终版本和一个 需求分析报告 。这个阶段的结束以 软件规格说明评审（ SSR） 为标志， 在这个控制点上分析的结果被评估。已建立基线的功能规格说明形成了在需求定义小组和软件开发小组之间的一个合同，并且是详细设计阶段的起点。在这个阶段中，开发小组的成员产生一个 概要设计报告 ，软件开发管理者手册第 7 页 共 68 页在这个报告中他们定义软件系统的体系结构和规范化主要的子系统、输入/输出接口和处理模式。 概要设计评审（ PDR） ，标志着本阶段的结束，提供了对设计的评估。在详细设计阶段，在概要设计阶段被定义的系统体系结构被精化到子程序的层次。开发小组完整地描述用户输入、系统输出、I/O文件和模块间接口。一个实现计划被建立，描述一系列的构造和发布，最终实现被交付的软件系统。对应的文档，包括完整基线图表，组成了详细设计文档。在 关键设计评审（ CDR） 中，详细设计被平谷以确定详细设计的深度和完整性对进行编码是否已经充分。在实现（编码、单元测试和集成）阶段，开发小组使用详细设计文档对所有要求的模块进行编码。系统随着新模块被编码、测试和集成不断成长。开发人员也要修订和测试被重用的模块并将它们集成到系统中。当所有编码被集成和相关的支持文档（系统测试计划和用户指南的草案）编写完成后，实现阶段就结束了。 系统测试阶段包括根据系统测试计划进行的端到端系统能力的功能性测试。开发小组检验完整集成的系统并产生一个初步的 系统描述 文档。系统测试计划所要求的测试的成功完成标志本阶段的结束在验收测试阶段中，独立于软件开发小组的验收测试小组检验已完成的系统以确定原始的需求是否被满足。验收测试在所有验收测试计划中规定的测试都被成功的运行后结束。 用户指南 和 系统描述 的最终版本被发表，运行就绪评审在开始运行支持之前对系统是否已经为运行作好了准备进行评估。维护和运行阶段在验收测试结束时开始。系统变成了维护和运行小组的责任。在这个阶段的活动依赖被开发的软件的类型。对一些支持软件，维护和运行阶段可能非常活跃，因为用户要求的变化很频繁。1.4 跨越阶段的活动在飞行动力学环境中，重用和原型是在几个生命周期阶段中的关键活动。在需求定义和需求分析阶段，重用分析被进行以确定现有软件的哪些主要的片段（子系统）可以被用在要开发的系统中。在设计阶段，开发人员通过独立地检验每个可重用元素来执行一个对分析的验证。在概要设计阶段，开发人员研究主要的组件来确定它们是否可以被直接或修改后重用。从一个可重用软件库（RSL）中抽取单独的单元在详细设计阶段被进行。一个最终的重用活动发生在系统测试阶段的末尾，在这个时间，开发人员选择开发软件的片段作为准备包含到RSL中的候选者。原型活动通常在需求分析时开始，在详细设计阶段末尾结束。一个原型是系统、系统组件或系统功能的早期试验模型，具备足够的能力以用来建立或精练需求或验证关键的设计概念。在飞行动力学环境中，原型一般被用来规避由于采用未知的新技术产生的风险。 图1-2显示了这两类活动在SEI环境中的跨度。软件开发管理者手册第 8 页 共 68 页本手册中的管理方法和工具与从需求定义到验收测试阶段相关，参考2包含一个更详细的生命周期阶段和活动的解释。2 第二章 组织和计划成功的软件管理的关键是产生一个现实的、可用的计划，然后按照它去执行。组织和计划的早期关键环节建立了有效项目管理和控制的基础。2.1 项目的组织为了启动项目，管理者必须对项目的范围有一个清晰的理解，并建立控制的基础。主要的初始关注事项与澄清需求、交付项和组织框架有关。通过解决下述四类问题，管理者将对会影响项目计划的关键元素有一个了解：识别需求 系统必须具备哪些功能？ 系统将如何被运行？ 系统的边界可见吗？ 工作定义以什么形式存在？ 当前的工作定义可理解吗？ 项目以来外部事件和活动吗？识别产品和交付项 哪些文档、程序和文件被指定为可交付的产品？ 它们中哪些必须被交付？ 交付项的格式是什么，例如打印拷贝或在磁盘上？ 谁将接到交付项和谁验收最终产品？ 哪些标准将被用来评判最终产品是否能通过验收？控制准备软件开发管理者手册第 9 页 共 68 页 对项目状态有定期报告的时间表吗？ 对影响系统范围的需求变更的处理程序是什么？ 哪些评审是必须被进行的？ 会影响项目成功的技术或管理风险有哪些？ 使用哪些度量指标来评估项目的健康情况？建立一个组织身份 客户、开发人员和支持小组中谁是关键人物？ 不同的组是否理解了他们的工作范围和职责？ 开发在什么地方进行？ 使用什么开发环境？ 对开发环境的访问级别有什么要求？2.2 制定软件开发/管理计划在很多环境中，软件管理计划和软件开发计划是分离的政策文档，有不同的定位。管理计划面向管理和控制的更广泛的方面，例如项目级资源消耗监控和配置控制委员会（CCB）的职能。开发计划更集中在软件生产的方法和路线上，例如测试策略和程序设计方法。尽管两种计划之间存在这些差异，它们在一些内容上是相同的。在SEL的飞行动力学环境中，两个计划被合并成了一个文档软件开发/管理计划。尽管本章其余部分描述了一个单一的合并计划的内容，读者可根据实际需要将它分解成两个计划。在每种情况下，本章中的各项内容必须被正式地处理，以获得项目的成功。 软件开发/管理计划提供了组织和管理软件项目的一种有纪律的途径。一个成功的计划充当： 重要问题的一个结构化检查列表 项目组织的一致的文档 一个基线化的参考，根据它对与实际项目性能和经验进行比较 被使用的管理方法的一个详细说明 通过在生命周期的早期完成计划，管理者对组织开发工作的关键步骤变得熟悉 估计资源 建立进度表 组织人力 设置里程碑计划应集中在对被进行的项目来说唯一的或被定制的信息上。如果技术标准、工作指南或程序将被应用到项目的某个方面，计划应引用相关的文档，而不是再详细的叙述它。计划的编写可以在关于项目定义和范围的信息可获得后立即开始。计划应该在需求分析阶段结束后完成，除了仅在后续阶段才能获得的信息。如果在软件开发/管理计划中软件开发管理者手册第 10 页 共 68 页的条目因为某种理由被省略了，管理者应指明谁将提供信息和在什么时间提供。计划的拷贝应该提供给所有层面的项目管理和技术人员。图2-l描述了推荐的软件开发/管理计划的格式和内容，包括几个对本手册其他章节的引用。格式意在作为一个指南。根据具体的应用环境，对条目的不同解释和添加新内容也是恰当的。软件开发/管理计划以斜体表示的章节描述了在项目生命周期中定期被添加到计划中的材料。其他章节必须被修订和重新发行，如果环境要求在方法上有显著的变化。标题页：文档编号、项目和任务名称、报告标题和报告日期前导页：文档标识号、项目和任务名称、报告标题、客户名称、准备人、合同和任务编号，报告日期目录.1. 介绍1.1 目的：项目目的的简要陈述1.2 背景：项目产生的软件在整个系统中的位置1.3 组织结构和职责1.3.1 项目人员：对开发小组将如何组织活动和人员以完成项目的阐述和图表：被分派人员的类型和数量、汇报关系和小组成员的权利和责任（见第三章 关于团队构成的工作指南）1.3.2 接口小组：列出接口小组、联系点和小组职责2. 问题陈述：对关键需求、完成需要的步骤、必须做的步骤（已编号）和与其他项目的关系（如果有）的简要说明3. 技术路线3.1 重用策略：对当前计划中重用来自现有系统软件的描述3.2 假设和约束：工作必须遵守和条件和行为方式3.3 预期的和未解决的问题：会影响工作和预期的对每个阶段的影响3.4 开发环境：目标开发机器和编程语言3.5 活动、工具和产品：对每个阶段，用一个矩阵显示a) 要进行的主要活动b) 要应用的开发方法和工具c) 阶段的产品（见第四章）包括任何唯一的途径方法和活动3.6 构造策略：在哪个构造中系统的那些部分将被实现和基本理由，在详细设计的末尾和和每个构造结束后被更新4. 管理方法4.1 假设和约束：影响管理的因素，包括项目的优先级4.2 资源需求：对所需资源的估计表或清单，包括系统规模的估计（新的和重用的LOC和模块）、每个阶段的人力需求（管理人员、编程人员和支持人员）、培训需求和计算机资源（见第三章）。包含所使用的估计的方法和基本原理。被更新的估计在每个阶段末尾被增加到计划中。4.3 里程碑和进度：要做的工作、谁做和何时完成的清单。包括开发生命周期 （阶段和结束完成日期）、构造/发布日期、交付日期、与外部开发的软件和硬件集成的日期。要交付给客户的数据、信息、文档、软件、硬件和外部实体提供的支撑系统等的清单和交付日期，以及评审进度（内部和外部的）。在每个阶段末尾更新的进度被添加到计划中4.4 度量：一个按阶段显示哪些度量被收集，来捕获项目数据以便进行历史分析，和被用来监视项目进展软件开发管理者手册第 11 页 共 68 页和产品质量（见第六章和参考3）。如果标准度量被收集，对相关标准和过程要进行引用。描述任何对本项目具有唯一性的度量和数据收集4.5 风险管理：每种技术和管理风险的陈述，以及如何规避风险。在每个阶段末尾根据新发现的风险进行更新。5. 产品保证5.1 假设和约束：对采用的质量控制、配置管理类型和深度有影响的因素5.2 质量保证（QA）：分阶段的保证软件开发过程和产品的质量所用的方法和标准。对那些不是从公开发表的方法和标准派生出来的，要提供被引用的合适的文档。针对本项目的创新的或唯一的保证和承诺质量的手段被明显地描述。指定人员承担项目中的QA职责，并定义他地职能和分阶段产品。5.3 配置管理（CM）：显示被控制的产品，被使用的工具和过程的表格，保证系统配置的完整性和一致性。当系统受控时，变更如何申请、谁进行变更等等。唯一的程序被详细描述。如果标准的CM实践被应用，要提供相关文档的引用。指定人员负责项目的配置管理，并描述这个角色。在每个新阶段开始之前根据此阶段详细的配置管理程序被更新，包括命名转换、CM目录指定、RSL等。6. 引用7. 计划更新历史：来自每次更新的开发计划前导页，指示哪些部分被更新了2.3 软件开发/管理计划的执行计划只有被遵守才能成为一种有效的管理工具。管理者必须通过以下工作领导和控制计划的执行： 维护计划 测量进展和性能 辨认危险信号 采取纠正措施来解决问题在每个开发阶段或构造结束时，管理者应该重新估计包含在计划中的项目规模、工作量和进度。早期的估计不能从计划中删除。它们提供了软件开发历史需要的计划执行的记录（第四章）。从这个信息，企业可以确定哪些估计方法有效和应当被再次使用。当它被有效地维护时，开发计划记录了软件开发工作目前地策略。通过提供一个对项目统一的刻画，如果在团队领导发生变化时，计划可能会没有价值。对计划显著的修订不应当被看作是正常的维护工作。应该在保证写出一个现实的计划上下工夫，而不是不断地修改它以满足真实的决定经验。例如，技术路线或使用的方法学的主要变动仅应该在非常必要时发生。通过测量进展，管理者发现开发/管理计划是否有效。第六章提到的测量数据的类型应该被收集和维护，作为项目状态的记录。测量数据单独对保证计划的有效性是不充分的，但是通过将这些数据和类似项目的正常数据相比较，一些评估是可行的。第三章提供了与实际项目数据进行比较需要的资源和工作方面的工作指南。项目历史数据库的使用（第六章）是测量进展的另一种管理工具。软件开发管理者手册第 12 页 共 68 页3 第三章 成本估计、进度安排和人力组织本章描述了管理和估计项目所需资源的方法。两个最关键的资源是开发力量和时间。软件管理者关心的是完成项目需要多少时间和在整个开发周期中需要什么样的人力资源水平。人力和时间使用本章描述的方法进行估计。整个开发周期中的人力规模和组成被考虑。为估计一些额外的重要成本因素，如计算机使用和系统文档等提供了工作指南。参考4提供了软件成本估计的背景知识和基本原理。一个劝告性的注释应用到贯穿本章的成本因素上。在附录中总结的值反映了SEL在飞行动力学环境中的经验。本手册的读者应该评估这些总结指标对你处的开发环境的适应性和有效性。一个谨慎的计划将首先使用这里的值作为一个大致的估计并开始收集数据（见参考3）来获得代表读者你自己环境的成本因素。3.1 估计开发成本和进度对生命周期每个阶段中期望的进度消耗和工作指出的一个理解对管理者是关键的。图l-l和表3-l表述这些分布，如它们反映被SEL监视的项目。因为开发软件的成本经常用单位工作的形式（如人月、人日等）来表示以避免通货膨胀和薪水的差异的影响，成本和工作在本章中会被交替使用来计算人力资源的支出。表 3-1. 时间进度和工作在各阶段的分布阶段 时间进度的百分比 工作量的百分比需求分析 12 6概要设计 8 8详细设计 15 16实现 30 40系统测试 20 20验收测试 15 10尽管它最不确定，最初估计从很多方面来讲是最重要的。它发生在如此早的时期（一般是在需求定义之后）以致强烈诱惑人们忽视它。这样做是个错误。进行初始估计对引导管理者考虑关于开发任务的规模和复杂性的各种不同因素具有积极的意义。最初估计为估计过程播下了火种，作为一个参考值与后面的估计进行对比。考虑这个单一的角色，以下步骤被建议来获得一个最初估计 尽可能深的分解需求。分解单元在这个点上比较合适的是子系统 对每个分解单元，识别与以前开发的功能单元的相似性 系统和使用任何历史规模数据可以从这些已经完成的系统获得 对与以前的项目关系不强的分解单元使用个人经验来估计单元的规模 将所有分解单元的结果相加形成整个软件的规模估计（用LOC） 从历史数据和个人经验，估计工作效率（用LOC/人月）软件开发管理者手册第 13 页 共 68 页 用规模估计除以工作效率得到一个用人月表示的工作量的估计 应用不确定概率到规模和工作量估计得到一个可能值的范围估计（见图3-1和表3-2）.在进行了初始估计后，最少五次重新估计（编号为2到6，见图3-1）被规定。这些重新估计的详细内容见表3-2。它们在生命周期过程中在不断增长的粒度上进行。来自图3-1的不确定性被在表3-2中的细节替代，因为它们在将单独的估计转化为估计值范围的重要性。在表3-2 中的估计因子代表对SEL监视的典型开发项目的平均值。当管理者识别与常见开发条件有显著差异的问题、过程或环境的特定方面时，这些估计应该被调整（在不确定性概率被应用之前）。例如，当系统中的很多模块由于特殊的功能（例如，图形生成）而不寻常的大或者小时，它们的估计规模应该基于先前已被开发的有相似功能的模块进行。此外，任何可能严重影响为完成项目所需的工作量的条件：新的和不熟悉的程序设计语言的使用、由一个完全没有经验的团队进行开发，或者新的和不熟悉的计算机系统的使用。这些条件中的一些的作用被SEL进行了估计。表3-3提供了推荐的根据所处理问题的复杂性对工作量估计的调整百分比。表3-4提供了提供了根据开发团队经验的不同级别对工作量的调整表3-2. 在开发中重新估计规模、成本和进度的程序估计点 需要的数据 规模估计 成本（工作量）估计进度/人力估计 a 不确定性（概率） b需求分析结束时 子系统数目 每个子系统使用了11000SLOCc每个子系统使用3000小时 d使用83个星期/子系统/人 d 0.75概要设计结束时 单元数 每个单元使用了190SLOCc每个单元使用52个小时 d使用1.45个星期/子系统/人 d 0.40详细设计结束时 新的和深入修改的模块的数量（N）重用单元数量（R）（简单的修改或直接使用） e计算被开发的单元数=N=0.2R使用被开发的SLOC=200*被开发的单元数每个被开发的SLOC使用0.31小时 d使用0.0087周/被开发的SLOC/人 d0.25实现结束时 按SLOC统计的当前规模添加26%到当前的规模（因为在测试添加43%到已扩展的工作量上（为完添加54%到已扩展的时间进度上（为完成时间）0.10软件开发管理者手册第 14 页 共 68 页扩展到日期的工作量扩展到日期的时间进度中的增长） 成的工作量）系统测试结束时 扩展到日期的工作量最终产品规模被达到了添加11%到已消耗的工作量上（为完成的工作量）添加18%到已扩展的时间进度上（为完成时间）0.05注释：参数值是从三个姿态着陆支持系统：GOES、GRO和COBE推导来的。A） 值是根据全职人员的平均工作周数作出的，包括对假期、离职等的考虑（1864 hours/年）。提供的值即可以被用来确定进度，也可以被用来估计人力水平，依赖于哪个参数被提供.B） 对规模和工作量估计：上限 = （规模或工作量估计） x （1.0 + 不确定性），下限 = （规模和或工作量估计）/ （1.0 + 不确定性）. 为允许TBD需求、人员调整等，保守的管理实践规定使用的估计必须在估计值和它的上限之间。例如，SEL管理者一般在为被估计的系统作计划时从PDR到项目结束过程中，考虑需求变更，会对规模估计增加 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 工作量乘子10 0.58 0.66 0.84 1.02 1.41 2.6A）小组成员对此类应用的平均经验年限，并根据成员的重要性或参与程度进行加权。应用经验被定义为软件开发管理者手册第 15 页 共 68 页先前在类似项目的工作经验。成员的参与度被定义为某个成员在项目上所占的时间站整个项目时间的比例3.2 项目人力组织尽管人员的平均水平被工作量估计所提供，对人力组织的三个方面有更具体的工作指南：团队组织、人力模式和团队构成。典型的人力组织框架在第六章被提供。表3-5提供了根据团队领导者经验的团队规模的工作指南。表3-6是团队组成，列出了推荐的高级程序员和分析员的百分比表3-5. 团队规模指南团队领导：最少的经验年限 a技术 组织 领导包括团队领导在内的最大团队规模6 4 3 7 25 3 1 4 24 2 0 2 1技术：使用经验（需求定义、分析、开发、维护和运行）组织：组织和团队开发方法学方面的经验领导：作为团队领导或管理者的经验例子：一个没有领导经验的团队领导不应被要求管理超过三个人的队伍。一个七到九人的团队应该提供一个有六年技术经验的企业骨干人员作为领导表3-6. 开发小组构成指南项目类型 环境类型 高级人员的百分比 分析员的百分比旧 旧 25-33 25-33旧 新 33-50 25-33新 旧 33-50 33-50新 新 50-67 33-50项目和环境类型是旧的是指开发小组对它们平均有两年以上的经验高级人员指有5年与开发相关的活动的经验分析员指在问题定义和应用（项目类型）解决方案方面培训或教育背景的人3.3 其它软件开发成本对其他软件开发成本因素的估计和工作指南：计算机使用、 系统文档、软件移植、软件重用和软件维护。软件开发管理者手册第 16 页 共 68 页3.3.1 计算机使用的成本这个成本可以根据系统规模进行表达。CPU时间的总小时数估计H，在一个NAS 8040环境中是H = 0.0008L，其中 L是源代码行数。运行数量的估计R，在相同的环境中是R = 0.29L。图3-2和3-3显示了在整个生命周期中的计算机使用软件开发管理者手册第 17 页 共 68 页3.3.2 系统文档的成本文档成本包括在表3-2的成本估计中。对一个给定软件开发项目的文档的平均质量可以使用公式P = 120 + 0.026 L进行估计，其中 P是文档业数， L是源代码行数。这个成本覆盖一个需求分析报告、设计文档、系统描述和用户指南。对一个分离的文档任务，每页4人小时可以被用来估计系统文档的总成本。3.3.3 软件移植的成本移植意味着修改现有的软件使它能在新的计算机系统上运行。在任何移植项目中测试将占总工作量的一个高百分比。表3-7提供了移植高级语言编写的软件的成本占原始开发成本的百分比。表3-7. 移植软件的成本相对成本 a 测试工作量 b系统关系FORTRAN ADA FORTRAN ADA新代码 c兼容 d 10-16 5-11 55-70 36-40 0-3相似 e 15-18 10-15f 45-55f 30-35f 4-14不相似 g 20-40 18-30 40-50 25-30 15-32A）占原始开发成本的百分比B）占总移植成本的百分比Percent of total rehosting cost.C）新编写或需要深入修改的代码的百分比D）兼容：系统被设计为插上即用E）相似：一些关键的体系结构特征（例如字长）是共享的，另一些是不同的F）数据来自参考 5G）不相似：体系结构和组织方面的主要特征有差异3.3.4 重用软件的成本可重用的模块应该在设计阶段被识别。如表3-8所示，重用一个模块的估计成本依赖于变更的程度。表3-8. 重用软件的成本模块分类 被修改和增加的模块代码的百分比 对开发一个新模块的相对成本新 100 100深度修改 25 100轻微修改 1-25 20旧 0 20软件开发管理者手册第 18 页 共 68 页3.3.5 软件维护的成本软件维护指发生在软件被交付之后的三种类型的活动：纠正在运行过程中发现的缺陷，改进或增加功能的扩充和根据运行环境的改变（例如新的操作系统）调整软件。预期的维护成本依据被交付的软件的质量和运行环境的稳定性不同会变化很大。在被SEL监视的环境中，FORTRAN系统的很大比例的维护是花费在扩充系统上。这包括修改现存的组件、重新测试、重新生成和重新认证软件。几乎没有新组件被增加，新文档一般也不被产生。平均年维护工作量占原始系统总开发成本（人小时）的1%到23%。覆盖项目周期的总维护成本从1.5到24人年/百万LOC（见参考6）。因为维护工作量变化范围如此之大，SEL建议年维护成本的估计应根据项目类型进行调整。在估计一个开发周期短（少于4年）且稳定的系统的年维护量时，SEL使用总开发成本的5% 。大型、长周期的系统的年维护量用开发成本的15% 进行估计。4 第四章 关键文档和交付项文档和交付项提供了一个不断前进的系统描述和充当关键的进展指示器。它们是软件管理者们关注的中心，因为它们标志着生命周期阶段之间的转换。下列文档和交付项是软件管理者特别关注的： 需求和功能规格说明/测试计划 运行概念文档/用户指南 软件开发/管理计划/系统描述 需求分析报告/软件开发历史 概要设计报告 详细设计文档产品和支撑文件和工具一个软件开发项目的文档和交付项是生命周期阶段的核心。图4-l显示了每个阶段什么时候应当被完成。在某些情况下，初步的版本被准备，接下来被更新。对生命周期中的任何点，软件管理者可以确定哪些文档和交付项应当被准备。本章提供了推荐的文档内容，同时提供了对完成的文档进行评估的管理工作指南软件开发管理者手册第 19 页 共 68 页4.1 建议的文档内容对每个文档给出了建议的格式和内容（见图4-2 到4-10），除了在第二章单独描述的软件开发/管理计划。文档的实际内容可能与这里提供的大纲有很大的变化。应用环境的特殊特征可能需要管理者在选择最合适和有效的材料上进行判断。这种灵活性在研究下面的图4-2时，应当被理解。需求和功能规格说明本文档由需求定义小组产生，作为需求定义阶段的关键产品。它经常被发布为多卷的形式：卷1定义需求、卷2包含功能规格说明，卷3 提供数学规格说明。文档先于 SRR被分发。功能规格说明在需求分析过程中被更新并随着SSR建立基线。1. 介绍a. 项目的目的和背景b. 文档的组织形式2. 系统概述a. 系统整体概念b. 期望的运行环境（硬件、外设等）c. 显示外部接口和数据流的系统的高层视图d. 高级别需求的概述3. 需求：功能性、运行相关的（接口、资源、性能等）和数据方面的需求a. 高层次需求及它们的派生需求的编号列表（派生需求是不显式地在需求文档中被调出，而是代表约束、限制，或者为实现其他显式说明的需求而必须被满足的隐含内容）b. 对每个需求：（1） 需求编号和名字（2） 需求的描述软件开发管理者手册第 20 页 共 68 页（3） 需求的参考来源，或它是从哪个显式需求派生来的（4） 与其他主要功能或外部实体的接口（5） 性能规格说明：频率、响应时间、准确性等4. 功能规格说明a. 显示系统功能层次结构的论述和视图b. 每个主要子系统的基本功能的描述和数据流图c. 使用的常用约定的描述（数学符号、测量单位等等）d. 每个基本的功能描述（1） 输入（2） 流程：对这个功能如何工作的详细描述（3） 输出（4） 候选的重用软件的识别（5） 验证满足相关需求的验收标准（6） 数据字典：标识名字、数据结构、值域范围、类型等5. 映射功能规格说明到需求：同时也区分与同类型项目标准需求不同的项目特有的需求6. 数学规格说明：在实现计算功能中使用的公式和算法的描述a. 每种主要算法的概述b. 每个主要算法的详细公式运行概念文档本文档通过根据运行方法和场景从用户的观点描述系统的行为提供了一个对系统自顶向下的视图。它应当由系统分析员在需求定义阶段结束时提供给开发小组。建议的内容如下：1. 介绍，包括系统的目的和背景a. 系统的整体概念b. 系统概述以及说明外部接口和数据流的高层次图表c. 说明系统功能分层结构的详细描述和图表d. 文档的组织形式2. 运行环境，对系统运行环境的描述和高层次图表a. 运行场景的概述b. 系统配置的描述和图表（硬件和软件）c. 操作人员职责的描述3. 运行模式a. 系统运行模式的详细描述（例如，紧急与正常， 启动与运行中）b. 在每种模式中要处理的数据的容量和频率c. 在每种模式下操作的顺序、频率和类型（例如批处理或交互）4. 每个主要功能的操作性描述或者系统中的对象a. 每个主要运行场景的描述和高层图表，说明所有输入、输出和关键控制顺序b. 输入数据的描述，包括格式和限制。在接受输入数据之前显示功能状态的屏幕示例（即显示方式、菜单、弹出窗口等）也应被包含c. 处理流程：功能如何工作的高层次描述d. 输出数据的描述，包括格式和限制，在处理完输入数据后显示结果的示例屏幕（即显示方式、菜单、弹出窗口等）也应被包含e. 在处理过程中产生的状态和提示消息的描述，包括用户对任何重要消息响应的工作指南软件开发管理者手册第 21 页 共 68 页5. 需求跟踪矩阵：将每个运行场景映射到需求需求分析报告这个报告由开发小组在需求分析阶段结束时提供。它总结了需求分析的结果并建立了一个开始概要设计的基础。建议的内容如下：1. 介绍：项目的目的和背景、系统的整体概念和文档概述2. 重用建议：关键的重用候选者和系统的体系结构观念3. 运行概述：在需求分析阶段工作进行过程中更新运行概念a. 更新运行场景b. 运行模式：包括在每种模式下要处理的数据的容量和频率、操作的顺序和类型等等。c. 更新输入、输出和消息的描述4. 规格说明分析a. 指定到需求和功能规格说明的分类的总结（强制的、派生的、“ 愿望列表”、仅是信息的、或TBD）b. 有疑问的规格说明：对冲突、含糊、不灵活、不可测试和TBD需求和规格说明的识别和讨论c. 尚未解决的需求/运行问题，包括准备解决它们的日期d. 数学算法的分析5. 系统约束a. 硬件可用性：运行速度、内存、外设等b. 操作系统限制c. 支撑软件限制6. 开发假定7. 成本和进度方面的风险。这些风险应包含与TBD或变更的需求相关的风险和技术风险8. 解决技术风险需要进行的原型工作，包括每项工作的目标和进度9. 数据流或面向对象图型：所有对需求进行的功能分解或面向对象分析的结果10. 在图表中显示的更新了的处理，数据流和对象的数据字典概要设计报告这份报告由开发小组作为概要设计阶段的主要产品提供。它提供了系统的功能描述并形成了编写详细设计文档的基础。建议的内容如下：1. 介绍：项目的目的和背景，系统整体概念，和文档概述2. 设计概述a. 设计驱动者和它们的重要性顺序（例如性能、可靠性、硬件、内存考虑、操作系统限制、编程语言等）b. 重用组件分析的结果和重用策略c. 对替代设计的评价和鉴定d. 被选择的系统设计的详细描述和高层次图表，说明了硬件接口、外部数据接口子系统之间的互连和数据流e. 子系统与需求之间的跟踪矩阵f. 设计状态（1 ）约束、关注点和问题的清单，以及它们对设计的影响（2 ）假设条件清单，以及如果这些假设不成立时对设计可能的影响（3 ） TBD需求清单，以及对它们对系统规模、所需工作、成本和进度的评估（4 ） ICD状态（5 ）原型工作的状态软件开发管理者手册第 22 页 共 68 页g. 开发环境3. 运行概述a. 运行场景/脚本（为每个主要产品产生一个）。包括产品的形式、容量和产生的频率。面板和显示方式应当被注释来说明可以有哪些不同的选择，并被跟踪到子系统b. 系统性能考虑4. 每个子系统或主要的功能分解的设计描述：a. 子系统的详细描述和高层次图表，包括每种处理模式的界面、数据流和通讯协议b. 输入和输出的高层次描述c. 对操作者重要的处理的详细描述：根据控制点、被执行的功能和获得的结果指定输入和动作（正常和异常的，即错误处理和恢复）d. 扩展到子系统驱动者以下两层的结构图或面向对象图表e. Prologs（说明模块的目的、操作、参数次数、外部引用等; Ada项目应提供对系统中主要对象的包规范）和每个模块贯穿在子系统驱动者之下的第一个层次的程序设语言 （PDL） （因为尺寸的原因，Prologs和PDL 通常被以分离的形式发布）5. 每个内部和外部界面的数据接口：a. 描述，包括名字、功能、频率、交叉索引、单位和计算机类型、长度、表示形式b. 格式（1 ）文件的组织和描述（即数据文件、磁带、等等）（2 ）结构布局、采样、记录、传输的格式（3 ）存储需求详细设计报告本文档是详细设计阶段的主要产品。为完成这个文档，开发小组更新来自概要设计的相似的材料并增加更详细的内容。建议的内容如下：1. 介绍：项目的目的和背景，系统整体概念，和文档概述2. 设计概述a. 设计驱动者和它们的重要性顺序b. 重用策略c. 被选择的系统设计的详细描述和高层次图表，说明了硬件接口、外部数据接口子系统之间的互连和数据流d. 组件与需求和功能规格说明之间的跟踪矩阵e. 设计状态（1 ）约束、关注点和问题的清单，以及它们对设计的影响（2 ）假设条件清单，以及如果这些假设不成立时对设计可能的影响（3 ） TBD需求清单，以及对它们对系统规模、所需工作、成本和进度的评估（4 ） ICD状态（5 ）原型工作的状态f. 开发环境3. 运行概述a. 运行场景/脚本b. 系统性能的考虑4. 每个子系统或主要的功能分解的设计描述：a. 子系统的整体能力b. 在每个模块中对处理过程的假定和限制软件开发管理者手册第 23 页 共 68 页c. 子系统的详细描述和高层次图表，包括每种处理模式的界面、数据流和通讯协议d. 输入和输出的高层次描述e. 对操作者重要的处理的详细描述：根据控制点、被执行的功能和获得的结果指定输入和动作（正常和异常的，即错误处理和恢复）f. 扩展到子程序层次的结构图或面向对象图表，说明接口、数据流、交互控制、交互性输入和输出，以及硬拷贝输出g. 内部存储需求，即在所有处理模块中的数据排列方式、尺寸和容量的描述，以及处理的隐含限制h. 详细的输入和输出规格说明（1）处理控制参数，例如NAMELISTS（2）图形化显示的精确复制品（3）硬拷贝输出的精确复制品i. 描述系统的和用户的活动有关的错误消息的编号列表j. 全局数据结构的描述k. 每个单元的Prologs或Ada包规范和PDL（通常用分离的形式存放）5. 数据接口：更新概要设计报告中的描述测试计划构造/发布（BUILD/RELEASE）测试计划 有系统测试小组在详细设计阶段中准备 设计用来测试在软件开发/管理计划中定义的每个构造或发布的功能容量（完整软件系统的功能子集）和识别限制在实现阶段，在单元测试和每个构造/发布的集成完成之后立即由系统测试小组执行分析测试计划 在实现阶段之前由将使用系统的系统分析员准备 设计用来帮助开发人员验证复杂数学或空气动力学计算的结果 单元级别的测试由开发人员在系统实现阶段执行；端到端的测试作为系统测试的一部分系统测试计划 在实现阶段由系统测试小组准备 设计用来验证在需求文档中说明的系统的端到端的处理能力和识别限制 在系统测试阶段由系统测试小组执行验收测试计划 由验收测试小组在需求定义阶段之后起草，以需求和功能规格说明文档为基础 设计用来证明系统与需求和功能规格说明的符合性 在验收测试阶段由验收测试小组执行测试计划大纲1. 介绍，包括目的、测试的类型和级别，以及进度2. 映射每个需求和功能规格说明到一个或多个测试用例的跟踪矩阵3. 每个测试的测试描述（通常不要超过1到2页）a. 测试的目的，即被测试的需求或特定的能力软件开发管理者手册第 24 页 共 68 页b. 输入的详细规格说明c. 需要的环境，例如所需的数据集合、必要的计算机硬件d. 运行程序，即如何执行测试e. 输出的详细规格说明，即期望的结果f. 确定测试结果是否可接受的标准g. 对结果讨论的部分，即为解释与期望结果的背离，识别背离的原因或证明背离的理由用户指南开发小组在实现阶段开始准备用户指南。条目1和2 ，条目3的部份内容，是对来自详细设计文档的材料的更新，尽管一些需要重写一些内容来使用户更容易理解。在实现阶段结束时要完成一个草稿，并在系统测试阶段被评估。在验收测试阶段开始时，用户指南的一个更新的版本被提供给验收测试小组来评估。对错误进行校正，并在阶段结束时产生一个最终版本。建议的内容如下：1. 介绍a. 系统概述，包括目的和背景b. 文档的组织c. 系统的详细描述和高层次图表，说明硬件接口、外部数据接口、软件体系结构和数据流2. 运行概述a. 运行场景/脚本b. 显示、窗口、菜单、报表等的分层结构的概述c. 系统性能的考虑3. 每个子系统或主要功能的描述a. 子系统的整体能力b. 在每种模式种处理的假定和限制c. 子系统的详细描述和高层次图表，包括接口、数据流和每种处理模式的通讯协议d. 输入和输出的高层次描述e. 根据控制点、被执行的功能和获得的结果来说对操作者指定的输入和行动关键的处理的详细描述（同时包括正常和异常的情况，即错误处理和恢复）f. 对交互性子系统，按照被产生的顺序排列的显示的摹本g. 按照被产生的顺序排列的硬拷贝输出的摹本，并注明什么参数控制它h. 编号了的消息的清单，伴随系统的和用户的行动的解释。要注明产生消息的子程序4. 执行的需求a. 资源：系统和子系统的详细描述、高层次图表和表格（1） 硬件（2） 数据定义，即数据分组和命名（3） 外部空间考虑数据存储和打印输出（4） 内