《软件项目开发规范与管理控制.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体现软件问题汇报已由指定的开发人员去进行维
16、护工作；3体现修改已经完毕、测试好，正准备释放给主程序库；4体现主程序库已经更新，主程序库修改的重新测试尚未完毕；5体现已经进行了复测，但发现问题仍然存在；6体现已经进行了复测，已经顺利完毕所做的修改，软件问题汇报单被关闭（维护已完毕）；7体现留待后来关闭，因问题不是可重产生的，或者是属于产品改善方面的，或者只具有很低的优先级等等。7.1.3 配置管理申请人员填写的内容在软件问题汇报单中，属于配置管理申请人填写的各项内容的意义如下：D、E两项是项目和子项目0U名称，F是该子项目时代号，这应按配置标识的规定来命名代号；阶段名和汇报人的姓名、住址和等的含义是显而易见日勺；G体现问题属于哪首先的，是
17、程序的问题还是例行程序的问题，是数据库的问题还是文档的问题，是功能性修改还是性能改善性修改问题，也也许是它们的某种组合；H体现子例行程序/子系统，即要指出出现问题日勺子例行程序名字，假如不知是哪个子例行程序，可标出子系统名，总之，尽量给出细节;I是修订版本号，指出出现问题的子例行程序版本号；J是媒体，体现包具有问题的子例行程序的主程序库存储媒体的标识符；K是数据库，体现当发现问题时所使用的数据库标识符；1.是文档号，体现有错误的文档的编号；M体现出现错误的重要测试实例的标识符；N是硬件，体现发现问题时所使用的计算机系统的标识;O是问题描述/影响，填写问题征候的详细描述，假如也许则写明实际问题所
18、在，还要给出该问题对未来测试、界面软件和文档等的影响。7.2 软件修改汇报单（SCR）对软件产品或其阶段产品的任何修改，都必须通过评审、同意后才能重新投入运行或作为阶段产品释放。这一过程用软件修改汇报单（softwarechangereport）给以记录。软件修改汇报单0格式表2。当收到了软件问题汇报单之后，配置管理人员便填写软件修改汇报单。软件修改汇报单要指出修改类型、修改方略和配置状态，它是供配置控制小组进行审批日勺修改申请汇报。表中各项内容的意义如下：A是登记号，它是配置修改小组收到软件修改汇报单时所作的编号;B是配置管理人员登记软件修改汇报单的日期；C是已经准备好软件修改汇报单、可以对
19、它进行评审的时间；D、E和F的意义与软件问题汇报单中的ID、E和F日勺意义相似；G填写被处理的软件问题汇报单日勺编号，如该编号中提出的I问题只是部分处理，则在填写时要在该编号后附以字母P（Part体现部分之意）；H指出是程序修改、文档更新、数据库修改还是它们的组合，假如仅是指出顾客文档的缺陷则在解释处作上记号；I是修改的详细描述，假如是文档更新，则要列出文档更新告知单的编号；假如是数据库修改，则要列出数据库修改申请的标识号;J是同意人，经同意人签字、同意后才能进行修改；K是语句类型，程序修改中波及到的语句类型包括：输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类（如数据传送、寄存语
20、句）；1.是程序名，指被修改注程序、文档或数据库注名字。假如只规定软件修改汇报单做解释性工作，则注反复软件问题汇报单给出的名字;M指目前注版本/修订本标识；N指修改后的新版本/修订本标识；。指数据库，假如申请数据库修改，这里给出数据库日勺标识符；P是数据库修改申请号DBCR；Q指文档，即假如规定文档修改，则在这里给出文档日勺名字；R是文档更新告知单编号DUT；S体现修改与否已经测试，指出已对修改做了哪些测试，如单元、子系统、组装、确认和运行测试等，并注明测试成功与否；T指出在软件问题汇报单中给出日勺问题描述与否精确，并回答是或否；U是问题注释，精确地重新论述要修改日勺问题；V指明问题来自哪里，
21、如系统设计规格阐明书、软件需求规格阐明书、概要设计阐明书、详细设计阐明书、数据库、源程序等；W阐明完毕修改所需要的资源估计，即所需要日勺人月数和计算机终端时数;X指出所要进行修改的类型，由执行修改的人最终填写。修改类型重要有适应性修改、改善性修改以及计算错误、逻辑错误、输入和输出错误、接口错误、数据库错误、文档错误以及配置错误等的修改；Y是提出对软件问题进行修改日勺人员或单位；Z是完毕软件问题修改的人员或单位。表1软件问题汇报单（SPR）子例行程序/子系统：Il修改版本号：I媒体：J数据库：K文档：L测试实例：M硬件：N问题描述/影响：O附注及修改提议：P表2软件修改汇报单（SCR）软件修改汇报单登记号A登记日期B年月日发现日期C年月日项目名D子项目E代号F响应哪些SPR：G修改类型X修改申请人Y修改人Z修改：H程序口数据库口文档口解释口修改描述：I同意人：J改动:语句类型：KI/O计算口逻辑口数据处理口程序名：L老版本号：M新版本号：N数据库：ODBCR：P文档：QDUT：R修改已测试否：S单元子系统组装确认运行成功否：SSPR的问题论述精确否？T是口否口附注：U问题来自：V系统设计规格阐明书口需求规格阐明书口设计阐明书口数据库口程序口资源来自：W人工数：（单位：人日）计算机时间：（单位：小时）
