软件项目开发规范与管理控制.docx

《软件项目开发规范与管理控制.docx》由会员分享，可在线阅读，更多相关《软件项目开发规范与管理控制.docx（18页珍藏版）》请在第壹文秘上搜索。

1、软件项目设计和开发控制管理规范xxmxxxx科技有限企业1引言错误!未定义书签。错误!未定义书签。错误!未定义书签。错误!未定义书签。1. 1目的1.2 定义和缩写词1.3 参照资料2管理错误！未定义书签。2.1 机构错误!未定义书签。2.2 任务错误!未定义书签。2.3 职责错误!未定义书签。2.4 接口控制错误!未定义书签。2.5 实现错误!未定义书签。2.6 合用的原则、条例和约定错误!未定义书签。2.6.1指明错误!未定义书签。2.6.2内容错误!未定义书签。3软件配置管理活动错误!未定义书签。3.1配置标识错误!未定义书签。3.L1基线错误!未定义书签。3.1.2代码、文档错误!未定

2、义书签。3.2 配置控制错误!未定义书签。3.3 配置状态的记录和汇报错误!未定义书签。3.4 配置的检查和评审错误!未定义书签。4工具、技术和措施错误!未定义书签。5对供货单位的控制错误!未定义书签。6记录的搜集、维护和保留错误!未定义书签。7附录：配置管理报表及其格式错误!未定义书签。7.1 软件问题汇报单（SPR）错误!未定义书签。7.1.1 配置管理人员填写内容错误!未定义书签。7.1.2 1.2配置管理状态错误!未定义书签。7.1.3 配置管理申请人员填写的内容.错误!未定义书签。7.2 软件修改汇报单（SCR）错误!未定义书签。1引言1.1 目的本条必须指出特定的软件配置管理计划的

3、详细目的I。还必须描述该计划所针对的软件项目（及其所属的各个子项目）的名称和用途。1. 2定义和缩写词应当列出计划正文中需要解释的而在GB/T11457中尚未包括的术语的定义，必要时，还要给出这些定义的英文单词及其缩写词。2. 3参照资料列出要用到的参照资料，如：a.本项目的经核准的计划任务书或协议、上级机关的批文；b.属于本项目的其他已刊登的文献；c.本文献中各处引用的文献、资料，包括所要用到的软件开发原贝人列出这些文献的标题、文献编号、刊登日期和出版单位，阐明可以得到这些文献资料日勺来源。2管理必须描述负责软件配置管理的机构、任务及其有关的接口控制。2.1 机构必须描述在各阶段中负责软件配

4、置管理日勺机构。描述内容如下：a.描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构；b.阐明项目和子项目与其他有关项目之间的关系；c.指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的）互有关系。2.2 任务描述在软件生存周期各个阶段中的配置管理任务以及要进行的评审和检查工作，并指出各个阶段的阶段产品应寄存在哪一类软件库中（软件开发库、软件受控库或软件产品库）。3. 3职责必须描述与软件配置管理有关的各类机构或组员I向职责，并指出这些机构或组员互相之间的关系。A.指出负责各项软件配置管理任务（如配置标识、配置控制、配置状态记录以及配置的评审与检查）的机构的职责;B

5、.指出上述机构与软件质量保证机构、软件开发单位、项目承接单位、项目委托单位以及顾客等机构的关系；C.阐明由本计划第2.2条指明日勺生存周期各个阶段日勺评审、检查和审批过程中的顾客职责以及有关日勺开发与维护活动；D.指出与项目开发有关的各个机构的代表的软件配置管理职责；E.指出其他特殊职责，例如为满足软件配置管理规定所必要的同意规定。1.4 接口控制本条应当描述：a.接口规格阐明标识和文档控制的措施；b.对已交付的I接口规格阐明和文档进行修改的措施；c.对要完毕的软件配置管理活动进行跟踪的措施；d.记录和汇报接口规格阐明和文档控制状态日勺措施；e.控制软件和支持它运行的硬件之间的接口日勺措施。1

6、.5 实现应当规定实现软件配置管理计划的重要里程碑，例如：a.建立配置控制组；b.确定各个配置基线；c.建立接口控制协议;d.制定评审与检查软件配置管理计划和规程；e.制定有关的软件开发、测试和支持工具的配置管理计划和规程。1.6 合用的原则、条例和约定2. 6.1指明本条必须指明所合用的软件配置管理原则、条例和约定，并把它们作为本计划要实现的一部分；还必须阐明这些原则、条例和约定要实现的程度。3. 6.2内容必须描述要在本项目中编写和实现的软件配置管理原则、条例和约定，内容可如下：a.软件构造层次树中软件位置的标识措施；b.程序和模块的命名约定；c.版本级别的命名约定；d.软件产品的（标识措

7、施；e.规格阐明、测试计划与测试规程、程序设计手册及其他文档的标识措施；f.媒体和文档管理的标识措施；g.文档交付过程；h.软件产品库中软件产品入库移交或交付的过程;1.问题汇报、修改祈求和修改次序的处理过程；j.配置控制组日勺构造和作用；k.软件产品交付给顾客的验收规程；1 .软件库的操作，包括准备、存储和更新模块的措施；Dl.软件配置管理活动的检查；n.问题汇报、修改祈求或修改次序的文档规定，指出配置修改的目的）和影响；o.软件进入配置管理之前的测试级别；P.质量保证级别，例如，在进入配置管理之前，验证软件满足有关基线的程度。3软件配置管理活动本章必须描述配置标识、配置控制、配置状态记录与

8、汇报以及配置检查与评审等四方面的软件配置管理活动的需求。1.1 配置标识1.1.1 基线本条必须详细阐明软件项目的基线（即最初同意的配置标识），并把它们与本计划第2.2条描述的生存周期的特定阶段相联络。在软件生存周期中，重要有三种基线，它们是功能基线、指派基线和产品基线。对于每个基线，必须描述下列内容：a.每个基线的项（包括应交付的文档和程序）；b.与每个基线有关的评审与同意事项以及验收原则；c.在建立基线欧J过程中顾客和开发者的参与状况。例如，在产品基线中，要定义的元素可以包括：a.产品的名字和规则；b.产品标识编号；c.对每一种新交付的版本，要给出版本交付号、新修改日勺描述、修改交付的措施

9、、对支持软件的修改规定以及对有关文档的修改规定；d.安装阐明；e.已知的J缺陷和故障；f.软件媒体和媒体标识。1.1.2 代码、文档本条必须描述本项目所有软件代码和文档的标题、代号、编号以及分类规程。例如，对代码来说：a.编译日期可以作为每个交付模块标识的一部分；b.在构造模块源代码的次序行号时，应使它适合于对模块作深入的修改。3.2配置控制必须描述在本计划第2.2条描述的软件生存周期中各个阶段使用的修改同意权限的级别；必须定义对已经有配置的修改提议进行处理的措施，其中包括：a.详细阐明在本计划第2.2条描述的I软件生存周期各个阶段中提出修改提议日勺程序（可以用注上自然语言的流程图来体现）；b

10、.描述实现已同意的修改提议（包括源代码、目的代码和文档时修改）的措施；c.描述软件库控制的规程，其中包括存取控制、对于合用基线的读写保护、组员保护、组员标识、档案维护、修改历史以及故障恢复等七项规程；d.假如有必要修补目的代码，则要描述其标识和控制的措施。对于各个不同样层次的配置控制组和其他修改管理机构，本条必须：a.定义其作用，并规定其权限和职责；b.假如已构成机构，则指明该机构的领导人及其组员；c.假如还没有构成机构，则阐明怎样任命该机构的领导人、组员及代理人；d阐明开发者和顾客与配置控制组的关系。当要与不属于本软件配置管理计划合用范围的程序和项目进行接口时，本条必须阐明对其进行配置控制的

11、措施。假如这些软件的修改需要其他机构在配置控制组评审之前或之后进行评审，则本条必须描述这些机构的构成、它们与配置控制组的关系以及它们之间的互有关系；本条必须阐明与特殊产品（如非交付的软件、现存软件、顾客提供的软件和内部支持软件）有关的配置控制规程。3. 3配置状态的记录和汇报本条必须：a.指明怎样搜集、验证、存储、处理和汇报配置项的状态信息；b.详细阐明要定期提供的汇报及其分发措施；c.假如有动态查询，要指出所提供的动态查询的能力；d.假如规定记录顾客阐明的特殊状态时，要描述其实现手段。例如，在配置状态记录和汇报中，一般要描述的;信息有：a.规格阐明的状态；b.修改提议的状态；c.修改同意的汇

12、报；d.产品版本或其修改版的状态；e.安装、更新或交付时实现汇报；f.顾客提供的产品（如操作系统）的状态;g.有关开发项目历史的汇报。4. 4配置的检查和评审本条必须：a.定义在软件配置管理计划的第2.2条所定义的软件生存周期的特定点上执行的检查和评审中软件配置管理计划的作用；b.规定每次检查和评审所包括的配置项；c.指出用于标识和处理在检查和评审期间所发现的）问题日勺工作规程。4工具、技术和措施必须指明为支持特定项目日勺软件配置管理所使用的软件工具、技术和措施，指明它们的目的，并在开发者所有权的范围内描述其使用措施。例如，可以包括用于下列任务的工具、技术和措施：a.软件媒体和媒体文档的标识；

13、b.把文档和媒体置于软件配置管理的控制之下，并把它正式地交付给顾客。例如，要给出对软件库内的源代码和目的代码进行控制的I工具、技术和措施日勺描述；假如用到数据库管理系统，则还要对该系统进行描述。又如，要指明怎样使用软件库工具、技术和措施来处理软件产品的交付。c,编制有关程序及其有关文档的修改状态的文档。因此必须深入定义用于准备多种级别（如项目负责人、配置控制小组、软件配置管理人员和顾客）的管理汇报的工具、技术和措施。5对供货单位的控制供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购置时、其他开发单位开发时或从开发单位现存软

14、件库中选用的软件能满足规定的软件配置管理需求。管理规程应当规定在本软件配置管理计划的执行范围内控制供货单位的措施；还应解释用于确定供货单位的软件配置管理能力的措施以及监督他们遵照本软件配置管理计划需求日勺措施。6记录的搜集、维护和保留本章必须指明要保留的（软件配置管理文档，指明用于汇总、保护和维护这些文档的措施和设施（其中包括要使用的后备设施），并指明要保留日勺期限。7附录：配置管理报表及其格式7.1 软件问题汇报单（SPR）在系统的运行与维护阶段对软件产品的任何修改提议，或在软件开发时任一阶段中对前面各个阶段的阶段产品的任何修改提议，都应填入软件软件问题汇报单。软件问题汇报单位的格式见表Io

15、7.1.1 配置管理人员填写内容表中A、B、C、P和状态等项目是由负责修改控制的配置管理人员填写的。表中其他各项即D、E、F、G、H、I、K、N和0各项是由发现问题的人或申请配置管理的人填写的，他也许还要填写J、L和M三项内容。前四项内容日勺意义如下：A是由配置管理人员确定的登记号，一般按汇报问题的先后次序编号；B是由配置管理人员登记问题汇报的日期；C是发现软件问题的日期；P是填写若干补充信息和修改提议。有关配置管理七种状态的含义在下面解释。7.1.2 配置管理状态状态一栏提成七种状况，现分别阐明如下：1体现软件问题汇报正被评审，已确定采用什么行动；2体现软件问题汇报已由指定的开发人员去进行维护工作；3体现修改已经完毕、测试好，正准备释放给主程序库；4体现主程序库已经更新，主程序库修改的重新测试尚未完毕；5体现已经进行了复测，但发现问题仍然存在；6体现已经进行了复测，已经顺利完毕所做的修改，软件问题汇报单被关闭（维护已完毕