1、软件开发管理者手册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 制定软件开发/管理计划 .9
2、2.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
3、.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 自动化度量分析(“软件管理环境
4、”) .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
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 介绍本手册希望成为关于软件开发管理方法和工具方面的一个便利的参考。我们的方法是提供关于以下内容的简明信息: 什么方法和工具可以达到目的 何时应用它们 如何应用它们 项目管理者可在什么地方找到背景材料和更详细的资料这里的管理
6、方法和工具包括那些在软件工程实验室(SEL)(参考 1)已经被证明了有效的那些方法和工具。在被SEL监测的飞机动力环境中的软件项目的特征在附录一中有描述。具体应用包括姿态确定和控制、轨道调整、机动计划和一般性任务分析。1.1 手册概述本文档包含按管理主题组织的七个章节:第一章描述了本手册的目的、组织和目标读者。对软件生命周期和关键开发活动进行了概述。第二章讨论了关于软件管理中的组织和计划方面的基本管理概念。The production of the 软件开发管理计划被详细的介绍了。第三章描述了资源估计和分配。提供了估计规模、成本和人力的技术,给出了项目进度安排和人员组织分配的工作指南。第四章概
7、述了一个软件项目中关键文档和交付项的内容、时间选择和评估。第五章讨论了软件验证、测试和认证方面的管理问题。第六章总结了在对一个软件项目的监视和控制中使用的管理度量和工具。进展的关键指示器和报警信号,以及对应的纠正性度量被一起列出。第七章同时描述了项目评审的一般功能和五个主要的评审的特殊实现。对项目进行审计的工作指南也进行了介绍。最后是附录、词汇表和参考,以及文献目录。1.2 目标读者本文档的目标读者是软件管理者,如在手册中定义的,可能是行政或技术管理者。行政管理者对软件开发进行全面管理,保证在预算之内按时交付满足需求的软件。在SEL环境中,一个政府技术长官或助理技术代表(ATR)通常承担这一任
8、务。典型地,这位管理者不参与对程序员和分析员的日常技术管理。行政管理者主要参与下面列出的活动:软件开发管理者手册第 5 页 共 68 页 组织项目(第二章) 估计需要的资源(第三章) 估计成本(第三章) 评估文档和交付项(第四章) 监视进展(第六章) 评估评审和审计的结果(第七章) 认证最终结果(第五章)技术管理者负责对开发人员的直接管理。在SEL环境中这一职务经常由一个承包管理者担任,在某些项目中,一个政府管理者也可能担任这个角色。这个人参与一部分行政管理者的活动,尤其是与监视开发进展有关的内容。技术管理者的活动如下: 建立和执行软件开发/管理计划(第二章) 估计成本(第三章) 安排项目进度
9、(第三章) 组织项目人力资源(第三章) 领导文档和交付项的生产(第四章) 使用自动化管理工具(第六章) 监视开发进展(第六章) 管理技术人员(第六章) 保证软件质量(第五章) 为评审做准备(第七章)另外一种读者可能担任某种特殊外围职能的人员。例如在进度评审和审计项目是作为外部评审员。政府管理者应该注意这本手册和主要的NASA/GSFC标准没有冲突。1.3 软件生命周期软件开发的过程经常被模型化为一系列阶段,这些阶段定义了软件生命周期。在飞行动力学环境中,生命周期被定义为如下的阶段: 需求定义 需求分析 概要设计 详细设计 实现 系统测试 验收测试 维护和运行如图1-1 所示,阶段将软件生命周期
10、划分为互相不重叠的顺序的时间周期。但是,刻画每个一个阶段的活动(activities )可能在其他阶段被进行。例如,尽管在分析需求中的大多数的与人相关的活动是在需求分析阶段发生的,一些活动延续到了后续的阶段中。软件开发管理者手册第 6 页 共 68 页例子:在实现极端的末尾(第四条虚线),大约46%的人力被包含到系统测试中;大约 15%正准备验收测试;大约7%处理需求变更和问题;大约12%进行设计修改;大约20% 在进行编码、代码阅读、单元测试和集成变更。这个数据只是代表了在SEL进行的项目的一个例子。生命周期阶段是软件管理者重要的参考点。例如,在监视一个项目中,管理者可能发现在某个阶段的项目
11、条件的关键指示器在其他阶段不可获得。项目进展的里程碑对评审、文档和交付项很关键,因为它们标志了阶段之间的转换。管理工具和资源估计可以被应用仅在一定的阶段,因为它们的使用依赖于特殊信息的可获得性。在需求定义阶段,一个由分析员和开发人员组成的小组识别以前开发的可被重用的子系统并提交一个重用建议。在这个建议的指导下,需求定义小组准备 需求 文档,并完成 功能规格说明 的一个草案。这个阶段的结束以 系统需求评审( SRR)为标志, 在这个控制点上系统的需求被评估。在需求分析阶段中,开发小组对每个规格说明进行分类并进行功能分析或面向对象分析。与需求定义小组一起工作,开发人员解决含糊的、矛盾的和将被确定的
12、(TBD)的规格说明,产生一个 功能规格说明 文档的最终版本和一个 需求分析报告 。这个阶段的结束以 软件规格说明评审( SSR) 为标志, 在这个控制点上分析的结果被评估。已建立基线的功能规格说明形成了在需求定义小组和软件开发小组之间的一个合同,并且是详细设计阶段的起点。在这个阶段中,开发小组的成员产生一个 概要设计报告 ,软件开发管理者手册第 7 页 共 68 页在这个报告中他们定义软件系统的体系结构和规范化主要的子系统、输入/输出接口和处理模式。 概要设计评审( PDR) ,标志着本阶段的结束,提供了对设计的评估。在详细设计阶段,在概要设计阶段被定义的系统体系结构被精化到子程序的层次。开
13、发小组完整地描述用户输入、系统输出、I/O文件和模块间接口。一个实现计划被建立,描述一系列的构造和发布,最终实现被交付的软件系统。对应的文档,包括完整基线图表,组成了详细设计文档。在 关键设计评审( CDR) 中,详细设计被平谷以确定详细设计的深度和完整性对进行编码是否已经充分。在实现(编码、单元测试和集成)阶段,开发小组使用详细设计文档对所有要求的模块进行编码。系统随着新模块被编码、测试和集成不断成长。开发人员也要修订和测试被重用的模块并将它们集成到系统中。当所有编码被集成和相关的支持文档(系统测试计划和用户指南的草案)编写完成后,实现阶段就结束了。 系统测试阶段包括根据系统测试计划进行的端
14、到端系统能力的功能性测试。开发小组检验完整集成的系统并产生一个初步的 系统描述 文档。系统测试计划所要求的测试的成功完成标志本阶段的结束在验收测试阶段中,独立于软件开发小组的验收测试小组检验已完成的系统以确定原始的需求是否被满足。验收测试在所有验收测试计划中规定的测试都被成功的运行后结束。 用户指南 和 系统描述 的最终版本被发表,运行就绪评审在开始运行支持之前对系统是否已经为运行作好了准备进行评估。维护和运行阶段在验收测试结束时开始。系统变成了维护和运行小组的责任。在这个阶段的活动依赖被开发的软件的类型。对一些支持软件,维护和运行阶段可能非常活跃,因为用户要求的变化很频繁。1.4 跨越阶段的
15、活动在飞行动力学环境中,重用和原型是在几个生命周期阶段中的关键活动。在需求定义和需求分析阶段,重用分析被进行以确定现有软件的哪些主要的片段(子系统)可以被用在要开发的系统中。在设计阶段,开发人员通过独立地检验每个可重用元素来执行一个对分析的验证。在概要设计阶段,开发人员研究主要的组件来确定它们是否可以被直接或修改后重用。从一个可重用软件库(RSL)中抽取单独的单元在详细设计阶段被进行。一个最终的重用活动发生在系统测试阶段的末尾,在这个时间,开发人员选择开发软件的片段作为准备包含到RSL中的候选者。原型活动通常在需求分析时开始,在详细设计阶段末尾结束。一个原型是系统、系统组件或系统功能的早期试验
16、模型,具备足够的能力以用来建立或精练需求或验证关键的设计概念。在飞行动力学环境中,原型一般被用来规避由于采用未知的新技术产生的风险。 图1-2显示了这两类活动在SEI环境中的跨度。软件开发管理者手册第 8 页 共 68 页本手册中的管理方法和工具与从需求定义到验收测试阶段相关,参考2包含一个更详细的生命周期阶段和活动的解释。2 第二章 组织和计划成功的软件管理的关键是产生一个现实的、可用的计划,然后按照它去执行。组织和计划的早期关键环节建立了有效项目管理和控制的基础。2.1 项目的组织为了启动项目,管理者必须对项目的范围有一个清晰的理解,并建立控制的基础。主要的初始关注事项与澄清需求、交付项和
17、组织框架有关。通过解决下述四类问题,管理者将对会影响项目计划的关键元素有一个了解:识别需求 系统必须具备哪些功能? 系统将如何被运行? 系统的边界可见吗? 工作定义以什么形式存在? 当前的工作定义可理解吗? 项目以来外部事件和活动吗?识别产品和交付项 哪些文档、程序和文件被指定为可交付的产品? 它们中哪些必须被交付? 交付项的格式是什么,例如打印拷贝或在磁盘上? 谁将接到交付项和谁验收最终产品? 哪些标准将被用来评判最终产品是否能通过验收?控制准备软件开发管理者手册第 9 页 共 68 页 对项目状态有定期报告的时间表吗? 对影响系统范围的需求变更的处理程序是什么? 哪些评审是必须被进行的?
18、会影响项目成功的技术或管理风险有哪些? 使用哪些度量指标来评估项目的健康情况?建立一个组织身份 客户、开发人员和支持小组中谁是关键人物? 不同的组是否理解了他们的工作范围和职责? 开发在什么地方进行? 使用什么开发环境? 对开发环境的访问级别有什么要求?2.2 制定软件开发/管理计划在很多环境中,软件管理计划和软件开发计划是分离的政策文档,有不同的定位。管理计划面向管理和控制的更广泛的方面,例如项目级资源消耗监控和配置控制委员会(CCB)的职能。开发计划更集中在软件生产的方法和路线上,例如测试策略和程序设计方法。尽管两种计划之间存在这些差异,它们在一些内容上是相同的。在SEL的飞行动力学环境中
19、,两个计划被合并成了一个文档软件开发/管理计划。尽管本章其余部分描述了一个单一的合并计划的内容,读者可根据实际需要将它分解成两个计划。在每种情况下,本章中的各项内容必须被正式地处理,以获得项目的成功。 软件开发/管理计划提供了组织和管理软件项目的一种有纪律的途径。一个成功的计划充当: 重要问题的一个结构化检查列表 项目组织的一致的文档 一个基线化的参考,根据它对与实际项目性能和经验进行比较 被使用的管理方法的一个详细说明 通过在生命周期的早期完成计划,管理者对组织开发工作的关键步骤变得熟悉 估计资源 建立进度表 组织人力 设置里程碑计划应集中在对被进行的项目来说唯一的或被定制的信息上。如果技术
20、标准、工作指南或程序将被应用到项目的某个方面,计划应引用相关的文档,而不是再详细的叙述它。计划的编写可以在关于项目定义和范围的信息可获得后立即开始。计划应该在需求分析阶段结束后完成,除了仅在后续阶段才能获得的信息。如果在软件开发/管理计划中软件开发管理者手册第 10 页 共 68 页的条目因为某种理由被省略了,管理者应指明谁将提供信息和在什么时间提供。计划的拷贝应该提供给所有层面的项目管理和技术人员。图2-l描述了推荐的软件开发/管理计划的格式和内容,包括几个对本手册其他章节的引用。格式意在作为一个指南。根据具体的应用环境,对条目的不同解释和添加新内容也是恰当的。软件开发/管理计划以斜体表示的
21、章节描述了在项目生命周期中定期被添加到计划中的材料。其他章节必须被修订和重新发行,如果环境要求在方法上有显著的变化。标题页:文档编号、项目和任务名称、报告标题和报告日期前导页:文档标识号、项目和任务名称、报告标题、客户名称、准备人、合同和任务编号,报告日期目录.1. 介绍1.1 目的:项目目的的简要陈述1.2 背景:项目产生的软件在整个系统中的位置1.3 组织结构和职责1.3.1 项目人员:对开发小组将如何组织活动和人员以完成项目的阐述和图表:被分派人员的类型和数量、汇报关系和小组成员的权利和责任(见第三章 关于团队构成的工作指南)1.3.2 接口小组:列出接口小组、联系点和小组职责2. 问题
22、陈述:对关键需求、完成需要的步骤、必须做的步骤(已编号)和与其他项目的关系(如果有)的简要说明3. 技术路线3.1 重用策略:对当前计划中重用来自现有系统软件的描述3.2 假设和约束:工作必须遵守和条件和行为方式3.3 预期的和未解决的问题:会影响工作和预期的对每个阶段的影响3.4 开发环境:目标开发机器和编程语言3.5 活动、工具和产品:对每个阶段,用一个矩阵显示a) 要进行的主要活动b) 要应用的开发方法和工具c) 阶段的产品(见第四章)包括任何唯一的途径方法和活动3.6 构造策略:在哪个构造中系统的那些部分将被实现和基本理由,在详细设计的末尾和和每个构造结束后被更新4. 管理方法4.1
23、假设和约束:影响管理的因素,包括项目的优先级4.2 资源需求:对所需资源的估计表或清单,包括系统规模的估计(新的和重用的LOC和模块)、每个阶段的人力需求(管理人员、编程人员和支持人员)、培训需求和计算机资源(见第三章)。包含所使用的估计的方法和基本原理。被更新的估计在每个阶段末尾被增加到计划中。4.3 里程碑和进度:要做的工作、谁做和何时完成的清单。包括开发生命周期 (阶段和结束完成日期)、构造/发布日期、交付日期、与外部开发的软件和硬件集成的日期。要交付给客户的数据、信息、文档、软件、硬件和外部实体提供的支撑系统等的清单和交付日期,以及评审进度(内部和外部的)。在每个阶段末尾更新的进度被添加到计划中4.4 度量:一个按阶段显示哪些度量被收集,来捕获项目数据以便进行历史分析,和被用来监视项目进展