关于软件文档

软件文档知多少？ （来源于网络）
如今，软件开发越来越复杂，软件功能也越来越丰富。而几乎所有成熟的商业软件，都是靠一个开发团队齐心协力的血汗结晶。“罗马不是一天建成的！”，当我们震撼于Microsoft Windows的惊世巨著的同时，也道听途说了微软公司软件工程是如何的完善规范。的确，集数百名员工几年的共同努力之大成，软件项目管理的成败是控制开发成本的关键环节。这里面，少不了贯穿其中的重要步骤----软件文档。
　　软件文档可以分为开发文档和产品文档两大类。
　　开发文档包括：《功能要求》、《投标方案》、《需求分析》、《技术分析》、《系统分析》、《数据库文档》、《功能函数文档》、《界面文档》、《编译手册》、《QA文档》、《项目总结》等。
　　产品文档包括：《产品简介》、《产品演示》、《疑问解答》、《功能介绍》、 《技术白皮书》、《评测报告》、《安装手册》、《使用手册》、《维护手册》、 《用户报告》、《销售培训》等。
一、开发文档
　　1. 《功能要求》--来源于客户要求和市场调查，是软件开发中最早期的一个环节。客户提出一个模糊的功能概念，或者要求解决一个实际问题，或者参照同类软件的一个功能。有软件经验的客户还会提供比较详细的技术规范书，把他们的要求全部列表书写在文档中，必要时加以图表解说。这份文档是需求分析的基础。
　　2. 《投标方案》--根据用户的功能要求，经过与招标方沟通和确认，技术人员开始书写《投标方案》，方案书一般包括以下几个重要的章节：
　　前言--项目背景、公司背景和业务、技术人员结构、公司的成功案例介绍等。
　　需求分析--项目要求、软件结构、功能列表、功能描述、注意事项等。
　　技术方案--总体要求和指导思想、技术解决方案、软件开发平台、网络结构体系等。
　　项目管理--描述公司的软件开发流程、工程实施服务、组织和人员分工、开发进度控制、软件质量保证、项目验收和人员培训、软件资料文档等。
　　技术支持--公司的技术支持和服务介绍、服务宗旨和目标、服务级别和响应时间、技术服务区域、技术服务期限、授权用户联系人等。
　　系统报价--软、硬件平台报价列表、软件开发费用、系统维护费用等。
　　项目进度--整个项目的进度计划，包括签署合同、项目启动、需求分析、系统分析、程序开发、测试维护、系统集成、用户验收、用户培训等步骤的时间规划。
　　3. 《需求分析》--包括产品概述、主要概念、操作流程、功能列表和解说、注意事项、系统环境等。以《功能要求》为基础，进行详细的功能分析(包括客户提出的要求和根据开发经验建议的功能)，列出本产品是什么，有什么特殊的概念，包括那些功能分类，需要具备什么功能，该功能的操作如何，实现的时候该注意什么细节，客户有什么要求，系统运行环境的要求等。这里的功能描述跟以后的使用手册是一致的。
　　4. 《技术分析》--包括技术选型、技术比较、开发人员、关键技术问题的解决、技术风险、技术升级方向、技术方案评价，竞争对手技术分析等。以《需求分析》为基础，进行详细的技术分析(产品的性能和实现方法)，列出本项目需要使用什么技术方案，为什么，有哪些技术问题要解决 ，估计开发期间会碰到什么困难，技术方案以后如何升级，对本项目的技术有什么评价等。
　　5. 《系统分析》--包括功能实现、模块组成、功能流程图、函数接口、数据字典、软件开发需要考虑的各种问题等。以《需求分析》为基础，进行详细的系统分析(产品的开发和实现方法)，估计开发期间需要把什么问题说明白，程序员根据《系统分析》，开始在项目主管的带领下进行编码。
　　6. 《数据库文档》--包括数据库名称、表名、字段名、字段类型、字段说明、备注、字段数值计算公式等。以《系统分析》为基础，进行详细的数据库设计。必要时可以用图表解说，特别是关系数据库。
　　7. 《功能函数文档》--包括变量名、变量初植、功能，函数名，参数，如何调用、备注、注意事项等。以《系统分析》为基础，进行详细的说明，列出哪个功能涉及多少个函数，以便以后程序员修改、接手和扩展。
　　8. 《界面文档》--包括软件外观、界面素材、编辑工具、文件名、菜单、按钮和其它界面部件的要求，这里与软件完成后的运行界面是一致的。
　　9. 《编译手册》--包括服务器编译环境、操作系统、编译工具、GNU的C++编译器版本信息、目录说明、程序生成、源程序文件列表、Makefile配置及其相关程序的对应关系列表。客户端的编译过程、编译结果、编译示例、编译环境、操作系统、编译工具、源文件列表和制作安装程序的过程。
　　10. 《QA文档》--包括产品简介、产品原理、产品功能列表、功能描述、功能流程、执行结果、数据库结构、测试要求等，提供给软件测试人员使用。
　　11. 《项目总结》--包括项目简介、项目参与人员和开发时间、项目风险管理过程、项目功能列表、项目结构特点、技术特点、对项目的升级建议、对以后的项目的建议、人员素质情况等。
二、产品文档
　　1. 《产品简介》--包括公司背景、产品概念、适用范围、产品功能、功能特点、运行要求和公司联系地址。
　　2. 《产品演示》--包括公司简介、产品背景、产品描述、产品特点、产品作用、适用范围、使用分析、功能模块、解决问题、合作伙伴、成功案例等。一般用Power
point或者VCD录制软件实现。
　　3. 《疑问解答》--列出用户关心的问题和处理方法。用于解答软件的操作功能和解决用户的疑难问题。
　　4. 《功能介绍》--以《需求分析》为书写基础，包括软件介绍、软件结构、功能列表、功能描述和公司联系地址。
　　5. 《技术白皮书》--以《技术分析》为书写基础，包括功能实现、技术选型、关键技术问题的解决、技术方案特点、技术升级方向等。
　　6. 《评测报告》--第三方权威评测报告。包括评测目的、评测范围、评测环境、评测内容、实测数据、性能表现、结果分析和评测总结等。
　　7. 《安装手册》--包括系统环境、运行平台、产品安装过程、初始环境设置、安装记录等。
　　8. 《使用手册》--包括产品简介、功能列表、功能描述和解释、功能操作、客户服务和联系方式等。
　　9. 《维护手册》--包括产品简介、系统须知、初始环境设置、系统配置、数据管理和备份、技术问题解答和联系方式等。
　　10. 《用户报告》--包括产品简介、购买时间、使用目的、使用时间、使用地点、实施过程、出现问题和解决、产品总结和建议等。
　　11.《销售培训》--包括项目简介、产品功能、产品特点、商业优势、系统运行环境、适用范围、目标客户等。
****************************************************************************************
//**************************************************************************************
****************************************************************************************
概说概要设计怎么做

摘要：
  本文是在概要设计实践和学习中的一些心得与学习笔记，希望与大家分享，如有不妥之处欢迎指正。
  关键字：
  概要设计，结构化，OOD
  正文：
  在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。
  一、问题的提出
  概要设计写什么？概要设计怎么做？
  如何判断设计的模块是完整的？
  为什么说设计阶段过于重视业务流程是个误区？
  以需求分析文档还是以概要设计文档来评估开发工作量、指导开发计划准确？
  结构化好还是面向对象好？
  以上问题的答案请在文章中找。
  二、概要设计的目的
  将软件系统需求转换为未来系统的设计；
  逐步开发强壮的系统构架；
  使设计适合于实施环境，为提高性能而进行设计；
  结构应该被分解为模块和库。
  三、概要设计的任务
   制定规范：代码体系、接口规约、命名规则。这是项目小组今后共同作战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，大家就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。
  总体结构设计：
  功能（加工）－>模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现；
  模块层次结构：某个角度的软件框架视图；
  模块间的调用关系：模块间的接口的总体描述；
  模块间的接口：传递的信息及其结构；
  处理方式设计：满足功能和性能的算法
  用户界面设计；
  数据结构设计：
  详细的数据结构：表、索引、文件；
  算法相关逻辑数据结构及其操作；
  上述操作的程序模块说明（在前台？在后台？用视图？用过程？······）
  接口控制表的数据结构和使用规则
  其他性能设计。
  四、概要设计写什么
  结构化软件设计说明书结构（因篇幅有限和过时嫌疑，在此不作过多解释）
  任务：目标、环境、需求、局限；
  总体设计：处理流程、总体结构与模块、功能与模块的关系；
  接口设计：总体说明外部用户、软、硬件接口；内部模块间接口（注：接口≈系统界面）
  数据结构：逻辑结构、物理结构，与程序结构的关系；
  模块设计：每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；
  运行设计：运行模块组合、控制、时间；
  出错设计：出错信息、处错处理；
  其他设计：保密、维护；
  OO软件设计说明书结构
  1 概述
  系统简述、软件设计目标、参考资料、修订版本记录
  这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分，将解释设计是怎么来实现这些的。
  2 术语表
  对本文档中所使用的各种术语进行说明。如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。
  3 用例
  此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。
  4 设计概述
  4.1 简述
  这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）
  4.2 系统结构设计
  这部分要求提供高层系统结构（顶层系统结构、各子系统结构）的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。
  4.3 系统界面
  各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。
  4.4 约束和假定
  描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。
  另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型以及这样导致的约束。
  实现的语言和平台也会对系统有约束，同样在此予以说明。
  对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。
  5 对象模型
  提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。所有对象之间的关联必须被确定并且必须指明联系的基数。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。
  6 对象描述
  在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。
  为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。
  对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。
  对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。
  7 动态模型
  这部分的作用是描述系统如何响应各种事件。一般使用顺序图和状态图。
  确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。
  7.1 场景（Scenarios）
  对每个场景做一则条目，包括以下内容：
  场景名：给它一个可以望文生义的名字
  场景描述：简要叙述场景是干什么的以及发生的动作的顺序。
  顺序图：描述各种事件及事件发生的相对时间顺序。
  7.2 状态图
  这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。
  8 非功能性需求
  五、概要设计怎么做
  结构化软件设计方法：
  详细阅读需求规格说明书，理解系统建设目标、业务现状、现有系统、客户需求的各功能说明；
  分析数据流图，弄清数据流加工的过程；
  根据数据流图决定数据处理问题的类型（变换型、事务型、其他型）；
  通过以上分析，推导出系统的初始结构图；
  对初始结构图进行改进完善：所有的加工都要能对应到相应模块（模块的完整性在于他们完成了需求中的所有加工），消除完全相似或局部相似的重复功能（智者察同），理清模块间的层次、控制关系，减少高扇出结构，随着深度增大扇入，平衡模块大小。
  由对数据字典的修改补充完善，导出逻辑数据结构，导出每种数据结构上的操作，这些操作应当属于某个模块。
  确定系统包含哪些应用服务系统、客户端、数据库管理系统；
  确定每个模块放在哪个应用服务器或客户端的哪个目录、哪个文件（库），或是在数据库内部建立的对象。
  对每个筛选后的模块进行列表说明。
  对逻辑数据结构进行列表说明。
  根据结构化软件设计说明书结构对其他需要说明的问题进行补充说明，形成概要设计说明书。
  OO软件设计方法：
  在OOA基础上设计对象与类：在问题领域分析（业务建模和需求分析）之后，开始建立系统构架。
  第一步是抽取建立领域的概念模型，在UML中表现为建立对象类图、活动图和交互图。对象类就是从对象中经过“察同”找出某组对象之间的共同特征而形成类：
  对象与类的属性：数据结构；
  对象与类的服务操作：操作的实现算法；
  对象与类的各外部联系的实现结构；
  设计策略：充分利用现有的类；
  方法：继承、复用、演化；
  活动图用于定义工作流，主要说明工作流的5W（Do What、Who Do、When Do、Where Do、Why Do）等问题，交互图把人员和业务联系在一起是为了理解交互过程，发现业务工作流中相互交互的各种角色。
  第二步是构建完善系统结构：对系统进行分解，将大系统分解为若干子系统，子系统分解为若干软件组件，并说明子系统之间的静态和动态接口，每个子系统可以由用例模型、分析模型、设计模型、测试模型表示。软件系统结构的两种方式：层次、块状
  层次结构：系统、子系统、模块、组件（同一层之间具有独立性）；
  块状结构：相互之间弱耦合
  系统的组成部分：
  问题论域：业务相关类和对象(OOA的重点)；
  人机界面：窗口、菜单、按钮、命令等等；
  数据管理：数据管理方法、逻辑物理结构、操作对象类；
  任务管理：任务协调和管理进程；
  第三步是利用“4＋1”视图描述系统架构：用例视图及剧本；说明体系结构的设计视图；以模块形式组成包和层包含概要实现模型的实现视图；说明进程与线程及其架构、分配和相互交互关系的过程视图；说明系统在操作平台上的物理节点和其上的任务分配的配置视图。在RUP中还有可选的数据视图。
  第四步是性能优化（速度、资源、内存）、模型清晰化、简单化（简单就是享受）。
  六、概要设计的原则
  总体原则和方法：由粗到细的原则，互相结合的原则，定性分析和定量分析相结合的方法，分解和协调的方法和模型化方法。
  要系统考虑系统的一般性、关联性、整体性和层次性。
  分解协调：目的是为了创造更好的系统。系统分解是指将一个复杂的系统分解为若干个子系统，系统协调一是系统内协调，即根据系统的总结构、总功能、总任务和总目标的要求，使各个子系统之间互相协调配合，在各个子系统局部优化基础上，通过内部平衡的协调控制，实现系统的整体优化；
  屏蔽抽象：从简单的框架开始，隐含细节；
  一致性：统一的规范、统一的标准、统一的文件模式；
  每个模块应当有一个统一命名的容易理解的名字；
  编码：由外向内（界面－>核心）；
  面向用户：概要设计是对于按钮按下后系统“怎么做”的简要说明；
  模块、组件的充分独立性、封闭性；
  同时考虑静态结构与动态运行；
  每个逻辑对象都应当说明其所处物理对象（非一一对应）；
  每个物理对象都有合适的开发人员，并且利于分工与组装。（详细说明见本人另一篇文章：系统构架设计应考虑的因素）；
  确立每个构架视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口；
  软件构架与使用的技术平台密切相关，目前常用的平台有J2EE、.NET、CORBA等等，因此具体的软件构架人员应当具备使用这些平台的软件开发经验；
  通过需求功能与设计模块之间的列表对应，检查每个需求功能是否都有相应的模块来实现，保证需求功能的可追溯性和需求实现（模块）的完整性，同时可以检查重复和不必要的模块。
  在需求调研分析过程中对业务处理过程了解的完整性和准确性非常重要。调查了解清楚所有的业务流程才能设计出适合各流程业务节点用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，设计成独立的模块，充分考虑他们与其他各种业务对象模块的接口，在流程之间通过业务对象模块的相互调用实现各种业务，这样，在业务流程发生有限的变化时（每个业务模块本身的业务逻辑没有变的情况下），就能够比较方便地修改系统程序模块间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块调用规则即可。
  七、概要设计的重要输出
  编码规范：信息形式、接口规约、命名规则；
  物理模型：组件图、配置图；
  不同角度的构架视图：用例视图、逻辑视图、进程视图、部署视图、实施视图、数据视图（可选）；
  系统总体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系；
  两个不可忽视的输出：
  与需求功能的关系：对于需求中的每一个功能，用哪一层、哪个模块、哪个类、哪个对象来实现（一对多关系）；反过来，应当说明将要创建的系统每一层、每个模块、每个对象、每一个类“做什么”，他们是为了帮助实现哪些功能（一对多关系）。（需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计或得到项目WBS其误差范围也是比较大的。更为重要的原因是，需求往往不是编码工作分解的准确依据，因为一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，因此只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次WBS，并估计较为准确的整体项目规模。）
  逻辑与物理位置：每个对象在逻辑上分别落在哪一层、哪个模块、哪个类；在物理上每个模块、每个对象、每一个类放在哪个应用服务器或客户端的哪个目录、哪个文件（库），或者是建立在数据库管理系统中的什么东东（过程、函数、视图、触发器等等）。
  八、结构化与面向对象方法特点比较
  1. 从概念方面看，结构化软件是功能的集合，通过模块以及模块和模块之间的分层调用关系实现；面向对象软件是事物的集合，通过对象以及对象和对象之间的通讯联系实现；
  2. 从构成方面看，结构化软件＝过程＋数据，以过程为中心；面向对象软件＝（数据＋相应操作）的封装，以数据为中心；
  3. 从运行控制方面看，结构化软件采用顺序处理方式，由过程驱动控制；面向对象软件采用交互式、并行处理方式，由消息驱动控制；
  4. 从开发方面看，结构化方法的工作重点是设计；面向对象方法的工作重点是分析；但是，在结构化方法中，分析阶段和设计阶段采用了不相吻合的表达方式，需要把在分析阶段采用的具有网络特征的数据流图转换为设计阶段采用的具有分层特征的结构图，在面向对象方法中则不存在这一问题。
  5. 从应用方面看，相对而言，结构化方法更加适合数据类型比较简单的数值计算和数据统计管理软件的开发；面向对象方法更加适合大型复杂的人机交互式软件和数据统计管理软件的开发；
  参考文献：
  《实用软件工程》第二版，郑人杰、殷人昆、陶永雷等著
  《微软项目：求生法则》Steve McConnell著，余孟学译
  《软件工程：实践者的研究方法》（第5版）Roger S.Pressman著
  《软件构架实践》SEI软件工程译丛，林·巴斯著
  《RUP2000》电子版；
  《UML与系统分析设计》张龙祥著；
  《面向对象的分析与设计》杨正甫著；
   本文作者邮箱：[e-mail]或[e-mail]
  欢迎指正
*****************************************************************************************
*****************************************************************************************
软件配置管理计划示例

计划名 CADCSC软件配置管理计划
项目名 中国控制系统CAD工程化软件系统
项目委托单位
代表签名 年 月 日
项目承办单位
代表签名 年 月 日
1 引言 1．1 目的
本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。
软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。
1．2 定义
本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。
1．3 参考资料
GB/T 11457 软件工程术语
GB 8566 计算机软件开发规范
GB 8567 计算机软件产品开发文件编制指南
GB/T 12504 计算机软件质量保证计划规范
GB/T 12505 计算机软件配置管理计划规范
CADCSC 软件质量保证计划
2 管理 2．1 机构
在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。 软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。
2．2 任务
在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第3.2条中详细规定。
2．3 职责
在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下：
A． 组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责；
B． 软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范；
C． 项目的专职配置管理人员检查在作配置更改时的质量保证措施；
D． 各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；
E． 用户代表负责反映用户对配置管理的要求，并协助检查各类人员对软件配置管理计划的执行情况；
F． 项目专职的配置管理人员协助组长开展各项软件配置管理活动，负责审查所采用的配置管理工具、技术和方法，并负责汇总、维护和保存有关软件配置管理活动的各项记录。
2．4接口控制
对各类接口进行严格、合理的控制，是软件配置管理中最重要的任务之一。整个软件项目及其各子系统都必须对进行严格的控制。在工程化软件系统中，主要的接口有如下五类：
A． 用户界面：用户界面是指各子系统与设计人员、用户或维护人员之间的操作约定。同时还指实现这些操作约定的物理部件的功能与性能特性。
B． 系统内部接口：系统内部接口是指各子系统在集成为一个总的软件系统时的各种连接约定。
C． 标准程序接口：标准程序接口是指各应用子系统与标准子程序库（包括宿主计算机系统已有的库程序）之间的调用约定。
D． 设备接口：设备接口是指各子系统与各种设备（包括终端和其他各种输入/输出设备）之间的连接约定。
E． 软件接口：软件接口是指各个子系统与宿主计算机上的系统软件以及与调用本软件的其它软件系统之间的连接约定。 以上五类接口是一个软件系统各项配置的重要组成部分。对接口修改进行合理的控制，是软件配置管理的重要任务之一。这五类接口都涉及到CADCSC软件系统的全局，因此，当要求对这五类接口中的任一类接口进行修改时，都必须办理正规的审批手续，最后要经项目总体组批准。具体的审批程序将在本计划的第3.2条中规定（可参阅表1）。
表1 两类修改的审批程序
步骤 A类修改的审批程序 B类修改的审批程序
1 发现问题，填写软件问题报告单 发现问题，填写软件问题报告单
2 项目组长评审 项目组长评审
3 软件配置管理小组评审 子系统配置管理人员评审
4 项目总体组批准 子系统负责人批准
5 修改配置并填写软件修改报告单 修改配置并填写软件修改报告单
6 项目组长评审 项目组长评审
7 软件质量保证小组评审 子系统质量保证人员评审
8 总体组批准 项目的软件配置管理小组与子系统负责人共同批准并报项目总体组备索
2．5 软件配置管理计划的实现
在实现软件配置管理计划的过程中，要特别注意实现以下三个里程碑：
A． 建立软件配置管理小组：在项目总体组批准软件配置管理计划之后，立即成立软件配置管理小组；
B． 建立各阶段的配置基线：随着CADCSC软件系统及其所属各子系统的任务书的评审和批准，建立起功能基线；随着总体组编写的《CADCSC软件需求规格说明书》的批准，建立起指派基线；随着CADCSC工程化软件系统的集成与系统测试的完成，建立起产品基线。
C． 建立软件库：在本项目所属的各个子系统的研制工作的开始，就建立起各个子系统的软件开发库，并在本项目配置管理小组的计算机上建立起有关该系统及其子系统的软件受控库。以后在每个开发阶段的结束，建立各个子系统的新的开发库，同时把这个阶段的阶段产品送入总的软件受控库，并在各个子系统的计算机上建立软件受控库的副本。软件受控库必须以主软件受控库为准。当全部开发工作结束，在配置管理小组的计算机上建立起软件产品库，并在各子系统的计算机上建立软件产品库的副本。
2．6 适用的标准、条例和约定
除应奠定本计划第1.3条中指出的参考资料以及本计划中的其他章条所作的各项规定外，还应该遵守如下标准、条例和约定：
A． 软件开发库、软件受控库与软件产品库的操作规程与管理规程；
B． 系统、子系统、模块和程序单元的命名约定；
C． 文档和测试用例的命名和管理规程。
这引起命名约定、操作规程与管理规程应由CADCSC项目技术组负责制订，并应认真听取各子系统项目负责人的意见，最后报项目总体组审批。在执行过程中，如果发现某些条款需要修改，则必须办理正规的审批手续，最后要经项目总体组批准。具体的审批程序将在本计划的第3.2条中规定。
3 软件配置管理活动
3．1 配置标识
3．1．1 文档
所有为本项目编制的文档，都要符合GB 8567中的规定。CADCSC软件系统及其所属的各个子系统所编写的文档数目，可根据GB 8567的规定作适当的剪裁。剪裁方案由技术组提出建议，报总体组批准。
3．1．2 程序
所有属于本项目的程序、分程序、模块和程序单元，都要按照由项目技术组制订，且经总体组批准的软件系统的命名约定的规定来标识。
3．1．3 各类基线
所有属于本项目及其各子系统的各类基线，首先要按照任务书、软件需求规格说明书的规定确定其技术内容，然后按照软件系统的上述命名约定的规定来标识。
3．2 配置控制
软件配置的更改管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。配置控制的要点如下：
A． 修改批准权限；对本项目各个子系统及其专用支持软件的功能基线、指派基线、产品基线及其集成系统的任何修改（称为A类修改），都必须通过项目配置管理小组讨论，并必须经总体组批准；对本项目各个子系统及其专用支持软件的其他阶段产品的任何修改（称为B类修改），都必须通过本项目各个子系统的配置管理人员审查，并经项目的软件配置管理小组与各个子系统负责人的共同批准并报项目总体组备案。
B． 修改审批程序：上述两类修改的审批程序如表1。
C． 修改控制工具：修改控制工具是协助软件配置管理人员进行配置控制的有效手段。
3．3 配置状态审计
利用软件问题报告单和软件修改报告单对项目子系统及其支持软件的配置状态进行追踪。对软件问题报告单和软件修改报告单的追踪应由软件配置管理工具自动实现，用户可通过该软件系统对其进行查询。 注：本计划在此处应给出软件问题报告单与软件修改报告单的具体格式，并作出必要的说明。鉴于本计划拟采用附录B（参考件）中建议的格式，因而这两个报告单的格式及其说明可参阅附录B。
3．4 配置的检查和评审
项目软件配置管理小组要对所有由第三方提供的软件进行物理配置检查；对本项目及其各个子系统的每一个新的释放进行功能配置检查和物理配置检查；对宿主计算机系统所提供的软件和硬件配置要每隔半年检查一次；在软件验收前要对宿主计算机系统、各个子系统及其专用支持软件的配置进行综合检查。
在软件开发周期各阶段的评审与检查工作中，要对该阶段所进行的配置管理工作进行必要的评审和检查。应该进行评审与检查的内容与次数，由CADCSC软件质量计划规定。配置修改的审批程序按本计划第3.2条的规定处理（见表1）。
4 工具、技术和方法
在软件的开发过程中，与软件配置有关的工具有软件测试工具、软件配置管理工具、文档辅助生成工具与图形编辑工具等到三种。
A． C软件测试工具：它支持用C语言编写的模块的静态分析、结构测试与功能测试。主要功能为：协助测试人员判断程序结构与变量使用情况是否有错；给测试人员提供模块语句覆盖C0和分支覆盖率C1的值、并显示未覆盖语句和未覆盖分支的号码及其分支谓词，给出不同测试用例有效性的表格；同时提出功能测试的有效情况，并协助组织最终交付给用户的有效测试用例的集合。
B． 软件配置管理工具：它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织；支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的涉及范围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理。
C． 文档辅助生成工具与图形编辑工具：它主要协助用户绘制描述程序流程与结构的DFD图与SC图、绘制描述软件功能（输入、输出关系）的曲线以及绘制描述系统特性的一些其他图形，同时还可生成若干与CADCSC软件文档编制大纲适应的文档模板。用户利用这个工具的正文与图形编辑功能以及上述辅助功能，可以比较方便地产生清晰悦目的文档，也有利于对文档进行更改，这有助于提高文档的编制质量。
有关这些工具的详细需求可参阅这三项工具的需求规格说明书中的规定。
5 对供货单位的控制
CADCSC项目所属的各个子系统开发组如果需要从软件销售单位购买、委托其他开发单位、从开发单位现存软件库选用或从项目委托单位或用户的现有连锁反应加中选用软件时，则在选用前应向CADCSC总体组报告，然后由CADCSC总体组组织"软件选用评审小组"进行评审、测试与检查，只有当演示成功、测试合格后才能批准使用。如果只选用其中部分内容，则按等待开发软件的处理过程办理，此时CADCSC总体组不予预。在进行上述工作过程中，软件配置管理人员要进行下列工作：
A． 项目的软件配置管理小组要参加对上述四类由间接供货单位提供的软件的物理配置检查； 这些软件的功能配置检查由项目的软件质量保证小组负责。
B． 在这些软件送入软件受控库与其他软件成分进行组装之前，软件配置管理小组要对其存放媒体和配置标识进行认真的审查。
C． 由软件质量保证小组审查选用的上述四类软件，必须经过正式的验收手续，并由项目技术管理小组负责人批准，然后置于软件配置管理小组的控制之下。 6 记录的惧维护和保存在本项目及其所属的各个子系统的研制与开发期间，要进行各种软件配置管理活动。准确记录、及时分析并妥善存放有关这些活动的记录，对这些软件的下沉运行与维护工作十分有利。在软件配置管理小组中，应有专人负责收集、汇总与保存这些记录。
A． 基础上组装系统、各个子系统、专用支持软件及选用软件的功能基线、指派基线与产品基线要送入软盘或磁带，至少必须一式两份且存放在两个不同的地点。这些记录应该每6个月拷贝一次，以免意外损伤与自然老化。
B． 上述这些软件的文档也应送入软盘或磁带，至少必须工式两份且存放在两个不同的地点，并应有一份打印的硬拷贝。磁媒体应该每隔6个月拷贝一次，以免意外损伤与自然老化。
C． 软件产品的源程序、测试数据、测试报告及其他有关文档，除了按A、B规定妥善存放外，要在项目结束后再保存2年，或在条件成熟时转交给这些软件产品的生产系统。
注：具体保存年限要根据项目的性质与开发单位的任务来确定，此处仅作为一个示例。
D． 上述这些软件的各项配置的个性状态、评审记录与修改历史，要作为这些软件的历史记录来保存，目前可用打印硬拷贝一式两份存放，有条件时再转移到在线光学存储媒体中。
E． 鉴于处理版权或清理财务的需要，本软件系统的各项配置可能要求存放5~7年，但由于我国对这些问题尚无明确的规定，因此，有关本条款的具体规定待将来有必要与可能时再作修改与补充。