论文部分内容阅读
[摘 要]针对本单位军用型号软件数量多、进度紧、开发平台不统一以及软件开发人员能力呈梯度模式分布的实际情况，基于GJB 5000A《军用软件成熟度模型》，研究适用于本单位的软件需求管理过程，提高人员执行效率，确保型号软件质量，促进组织级过程积累，提高本单位软件工程化研制能力。
[关键词]军用型号软件；GJB 5000A；需求；管理；软件工程化
doi：10.3969/j.issn.1673 - 0194.2015.18.122
[中图分类号]TP311 [文献标识码]A [文章编号]1673-0194（2015）18-0-02
0 引 言
随着国际关系局势日益严峻，近年来，军用型号软件项目数量剧增，且功能不断扩充，但军用软件运行的高可靠性、安全性仍是保证部队作战的首要战略指标。在软件研发团队人员及水平相对固定的情况下，按照以往过多依赖于个人能力和“游击队”式的开发模式，不但不能满足型号软件工程化管理要求，并且为软件后期运行维护带来了极大隐患，故需要对软件研制过程各项活动进行分析及把关，提高交付软件质量，保证交付进度。通过梳理，近年来军用型号研制过程中出现的质量问题，主要原因有如下几方面：第一，部分软件后期由于与相关系统的接口需求分析不明确造成软件运行错误；第二，开发方过度承诺，后期需求变更无法控制且版本混乱；第三，大多数系统和软件项目的投入，有一半以上纯属浪费；第四，用户提供给开发方的需求清单不能反映真实需求；第五，系统测试阶段发现的错误，80%是由不正确的需求或遗漏的需求造成的；第六，项目主管对需求分析和定义的基本原理和重要性缺乏认识，忽视对需求的投入；第七，缺乏有效的需求分析工具支持需求分析和需求管理。
与传统的、有形的、可描述清晰的以及可具体检测的硬件生产制造需求相比，软件需求具有模糊性、变化性和主观性的特点。正因为软件需求的这些特点，对于一个软件项目的开发来讲，最困难的部分就是准确说明软件需求，在用户和开发团队之间建立对需求的共同理解，维护需求与各阶段工作产品达到一致性，并控制需求的变更。由此可见，软件需求分析及实现作为项目研制最重要的一个组成部分，对其过程管理的好坏很大程度上决定了软件开发的成败。
1 基于GJB 5000A建立本地化的需求管理模型
通过多年探索和研究发现，在运用GJB 9001B实现对软件研制各阶段产品进行有效考核的基础上，借助GIB 5000A可帮助军工单位加强软件研制过程管控，满足软件工程化要求，确保软件研发进度及质量。GJB 5000A-2008《军用软件研制能力成熟度模型》是参照《软件能力成熟度模型》（CMMI）1.2版制定的。其目的是帮助军用软件研发组织对软件研制过程进行管理和改进，增强开发与改进能力，它为改进一个组织的软件开发过程提供了单一的集成化框架，二级分为7个过程域，各域继相互独立又相辅相成。其中需求管理是一个单独的过程域，主要由5个专用实践来描述。这5个专用实践围绕着“管理需求”这个专用目标开展，如图1所示是基于GJB 5000A的需求管理模型。
1.1 软件需求管理基本过程定制
根据我所型号软件工程化大纲要求及软件研制具体流程，对需求管理过程进行了本地化定制，其中，专用实践SP1.1和SP1.2在实际执行过程中关联性较强，且时间较集中，采用“需求的理解和承诺”活动来描述，重点细化明确了需求提供者准则，将型号项目组定位为用户方，软件研究室定位为开发方，系统总体及软件生产人员定位为软件部署和维护人员；考虑到以往软件研制过程“重代码轻文档”的弊端，对系统需求的颗粒度划分原则进行了定义，并将其细化入《软件任务书评审要素表》及《软件任务书检查表》具体条目，为确保软件需求的可追溯落到实处奠定了基础。在订制过程中，随着对体系的理解不断加深，也采用了使用替代实践的方式简化本地化执行步骤，如为了简化需求承诺的流程使其具有可操作性，裁剪掉了软件需求承诺单，用软件评审结论报告签署页及软件任务书审签流程替代；将需求管理计划并入软件项目开发计划，确保需求管理过程策划与项目开发主计划的一致性。
SP1.4和SP1.5所关注的内容，贯穿软件研制过程的各个阶段，且存在前后依赖关系，执行时间点为阶段工作完成时和需求发生变更时，故采取用“需求跟踪”活动来描述，航天科技集团北京航天发射技术研究所（以下简称我所）软件多为非独立工作模式，主要运行于整个CAN总线通信网络或以太网通信网络中，与其他软件有频繁的数据交互，故在需求跟踪实践中，除了关注软件本身的功能、性能在各级工作产品中完成情况，也强调与相关联软件的通信接口即横向需求的追踪，对于软件需求输入中非技术类条目的追踪，在项目管理PMC过程域中通过项目例会及相关评审活动实现。对于需求追踪的形式制定了需求正反向追踪记录表—需求跟踪矩阵—项目问题追踪表—项目问题报告及纠正单的统一化流程处理方式。并明确需求追踪不一致性的发现渠道，除软件项目组成员，还包括第三方测试人员、利益相关方、项目QA人员及同行专家。
由于SP1.3需求的变更对后续软件质量、顾客满意度、批产及运行维护过程都有很大影响，故对需求变更活动，进行了强化说明，并细分具体的操作步骤。通过软件需求变更情景划分定义了不同的软件需求变更流程，对于研制过程中产生的变更，按照软件更改申请单提交—型号指挥批准（SCCB组长）—软件更改研制—软件回归测试—版本升级受控流程来实现，对于软件外场参加大型试验及运行维护时发生地变更，按照填写软件需求沟通备忘录，填写外场软件状态更改记录单—例外放行情况确认—补录技术偏离单、软件更改申请单及更改单—入库受控流程实现。
1.2 适用于不同生存周期模型的需求管理过程
随着软件编程语言、运行环境的扩展，结合型号研制进度紧、用户需求变更频繁的特点，传统的瀑布模型已经不能满足目前多型号软件并行开发的局面，通过梳理我所型号软件研制特点，结合《QJA 30A（2013）航天型号软件工程化要求》中定义的航天软件研制类型，对新研软件进行了分类，除传统瀑布模型外，充分借鉴敏捷开发方法，结合航天企业文化特点，新增原型开发模型、迭代模型及增量模型，可单独使用也可组合使用，并可在定义模型基础上根据型号研制阶段特点对模型进行衍生及细分，覆盖各型号软件研制任务，可根据软件开发人员能力梯度及项目组成员组成选用不同的开发模型。 对于迭代模型及原型开发模型中迭代阶段的需求开发及实现，采用需求沟通备忘录及需求正反向追踪表确保需求的可追踪性，弱化需求变更的流程控制，迭代过程中软件版本入开发库管理，当迭代阶段完成后，回归瀑布模型研制模式，严格遵守软件需求变更流程，必要时需形成软件更改影响域分析报告，并通过会议评审，确保需求更改的可行性。
1.3 软件需求过程管理过程与其他过程域的集成
基于GJB 5000A的软件工程化建设是一个各个过程域相互影响、共同促进的过程，软件需求管理过程的不断推进也离不开相关过程域的支持。主要有：需求变更对项目策划过程的影响，将需求的变更转化为进度偏差，根据进度偏差超阈值的多少来进行合适的计划变更；需求变更需要依赖测量与分析过程统计相关数据，方便项目研制过程中项目负责人宏观把握需求状态的情况，也为组织级生存周期模型选型指南及决策支持提供了保证；配置管理过程为需求承诺及变更输入的有效性提供了支持，确保了软件需求追踪及变更活动不是无源之水。
2 软件需求管理平台建设
由于软件规模庞大造成的需求颗粒较多，对需求追踪及变更的有效性带来了实际执行困难，采用以往的Excel表格填写方式，不但严重耗费一线技术人员的时间和精力，而且不能保证追踪的有效性，久而久之，需求管理的执行有效性下降，以往项目运行的各种弊端重新凸显。我所与相关单位合作，尝试研发订制了软件需求管理工具，经试用，对提高人员效率，确保需求管理执行落到实处起到了促进作用。如：采用需求影响域分析，自动对变更工作产品的需求追踪关系进行分析，对于未变更的需求项，工具自动继承与上级工作产品的追踪关系，对于变更的功能项，用红色在需求跟踪矩阵中标注出来，需求管理人员只需根据红色标注索引即可对更改需求项的追踪关系重新定义，即可完成新一轮的需求追踪活动，工具会自动生成新版本的需求跟踪矩阵；针对表格化的需求跟踪矩阵不直观分析困难的特点，采取需求追踪关系图的表现形式，一列代表一个阶段的工作产品，列与列之间通过连线表现相关工作产品的追踪关系，当需求发生变更时，需求管理人员只需直接拖动并改变连线即可实现对追踪关系的重新定义。当发生需求追踪不一致情况时，只需根据本阶段需求实现要素与之前各阶段工作产品的需求项关联情况，逐级检查出中间环节未追踪上或未实现的需求条目。效果如图2所示。
3 结 语
通过为期1年的GJB 5000A二级全面运行，我所型号软件工程化水平有了显著提高，并实现了各型号软件均能够按期交付，靶场无低层次质量问题出现，EPG组对本地化流程及管理模式也有了更深层次的理解。在现有本地化需求管理过程的基础上，深化体系的本地化订制，使其与本单位实际情况更加贴合，促进执行力度。
第一，简化需求正反向追踪记录表，在各阶段软件设计文件中体现，无需再生成表单，简化设计人员的工作量，避免了多处产生同一张表带来内容不一致的隐患；
第二，对不同生存周期模型的需求管理活动的测量项进行梳理和定义，对于采用敏捷方法开发的软件弱化对需求变更情况的统计，加强对软件质量问题及研制进度的测量与分析；
第三，区分使用不同编程语言实现的软件需求跟踪力度，对于非代码行实现的软件可根据项目实际情况只追踪至模块和线程；
第四，在进行软件项目策划及需求定义时应充分考虑对软件重用构件库的建设，即对同一类软件的需求开发应本着重用的原则，具体体现在需求、接口、界面的重用需求定义，避免同类软件对同一功能模块进行的反复定义—开发—验证。
[关键词]军用型号软件；GJB 5000A；需求；管理；软件工程化
doi：10.3969/j.issn.1673 - 0194.2015.18.122
[中图分类号]TP311 [文献标识码]A [文章编号]1673-0194（2015）18-0-02
0 引 言
随着国际关系局势日益严峻，近年来，军用型号软件项目数量剧增，且功能不断扩充，但军用软件运行的高可靠性、安全性仍是保证部队作战的首要战略指标。在软件研发团队人员及水平相对固定的情况下，按照以往过多依赖于个人能力和“游击队”式的开发模式，不但不能满足型号软件工程化管理要求，并且为软件后期运行维护带来了极大隐患，故需要对软件研制过程各项活动进行分析及把关，提高交付软件质量，保证交付进度。通过梳理，近年来军用型号研制过程中出现的质量问题，主要原因有如下几方面：第一，部分软件后期由于与相关系统的接口需求分析不明确造成软件运行错误；第二，开发方过度承诺，后期需求变更无法控制且版本混乱；第三，大多数系统和软件项目的投入，有一半以上纯属浪费；第四，用户提供给开发方的需求清单不能反映真实需求；第五，系统测试阶段发现的错误，80%是由不正确的需求或遗漏的需求造成的；第六，项目主管对需求分析和定义的基本原理和重要性缺乏认识，忽视对需求的投入；第七，缺乏有效的需求分析工具支持需求分析和需求管理。
与传统的、有形的、可描述清晰的以及可具体检测的硬件生产制造需求相比，软件需求具有模糊性、变化性和主观性的特点。正因为软件需求的这些特点，对于一个软件项目的开发来讲，最困难的部分就是准确说明软件需求，在用户和开发团队之间建立对需求的共同理解，维护需求与各阶段工作产品达到一致性，并控制需求的变更。由此可见，软件需求分析及实现作为项目研制最重要的一个组成部分，对其过程管理的好坏很大程度上决定了软件开发的成败。
1 基于GJB 5000A建立本地化的需求管理模型
通过多年探索和研究发现，在运用GJB 9001B实现对软件研制各阶段产品进行有效考核的基础上，借助GIB 5000A可帮助军工单位加强软件研制过程管控，满足软件工程化要求，确保软件研发进度及质量。GJB 5000A-2008《军用软件研制能力成熟度模型》是参照《软件能力成熟度模型》（CMMI）1.2版制定的。其目的是帮助军用软件研发组织对软件研制过程进行管理和改进，增强开发与改进能力，它为改进一个组织的软件开发过程提供了单一的集成化框架，二级分为7个过程域，各域继相互独立又相辅相成。其中需求管理是一个单独的过程域，主要由5个专用实践来描述。这5个专用实践围绕着“管理需求”这个专用目标开展，如图1所示是基于GJB 5000A的需求管理模型。
1.1 软件需求管理基本过程定制
根据我所型号软件工程化大纲要求及软件研制具体流程，对需求管理过程进行了本地化定制，其中，专用实践SP1.1和SP1.2在实际执行过程中关联性较强，且时间较集中，采用“需求的理解和承诺”活动来描述，重点细化明确了需求提供者准则，将型号项目组定位为用户方，软件研究室定位为开发方，系统总体及软件生产人员定位为软件部署和维护人员；考虑到以往软件研制过程“重代码轻文档”的弊端，对系统需求的颗粒度划分原则进行了定义，并将其细化入《软件任务书评审要素表》及《软件任务书检查表》具体条目，为确保软件需求的可追溯落到实处奠定了基础。在订制过程中，随着对体系的理解不断加深，也采用了使用替代实践的方式简化本地化执行步骤，如为了简化需求承诺的流程使其具有可操作性，裁剪掉了软件需求承诺单，用软件评审结论报告签署页及软件任务书审签流程替代；将需求管理计划并入软件项目开发计划，确保需求管理过程策划与项目开发主计划的一致性。
SP1.4和SP1.5所关注的内容，贯穿软件研制过程的各个阶段，且存在前后依赖关系，执行时间点为阶段工作完成时和需求发生变更时，故采取用“需求跟踪”活动来描述，航天科技集团北京航天发射技术研究所（以下简称我所）软件多为非独立工作模式，主要运行于整个CAN总线通信网络或以太网通信网络中，与其他软件有频繁的数据交互，故在需求跟踪实践中，除了关注软件本身的功能、性能在各级工作产品中完成情况，也强调与相关联软件的通信接口即横向需求的追踪，对于软件需求输入中非技术类条目的追踪，在项目管理PMC过程域中通过项目例会及相关评审活动实现。对于需求追踪的形式制定了需求正反向追踪记录表—需求跟踪矩阵—项目问题追踪表—项目问题报告及纠正单的统一化流程处理方式。并明确需求追踪不一致性的发现渠道，除软件项目组成员，还包括第三方测试人员、利益相关方、项目QA人员及同行专家。
由于SP1.3需求的变更对后续软件质量、顾客满意度、批产及运行维护过程都有很大影响，故对需求变更活动，进行了强化说明，并细分具体的操作步骤。通过软件需求变更情景划分定义了不同的软件需求变更流程，对于研制过程中产生的变更，按照软件更改申请单提交—型号指挥批准（SCCB组长）—软件更改研制—软件回归测试—版本升级受控流程来实现，对于软件外场参加大型试验及运行维护时发生地变更，按照填写软件需求沟通备忘录，填写外场软件状态更改记录单—例外放行情况确认—补录技术偏离单、软件更改申请单及更改单—入库受控流程实现。
1.2 适用于不同生存周期模型的需求管理过程
随着软件编程语言、运行环境的扩展，结合型号研制进度紧、用户需求变更频繁的特点，传统的瀑布模型已经不能满足目前多型号软件并行开发的局面，通过梳理我所型号软件研制特点，结合《QJA 30A（2013）航天型号软件工程化要求》中定义的航天软件研制类型，对新研软件进行了分类，除传统瀑布模型外，充分借鉴敏捷开发方法，结合航天企业文化特点，新增原型开发模型、迭代模型及增量模型，可单独使用也可组合使用，并可在定义模型基础上根据型号研制阶段特点对模型进行衍生及细分，覆盖各型号软件研制任务，可根据软件开发人员能力梯度及项目组成员组成选用不同的开发模型。 对于迭代模型及原型开发模型中迭代阶段的需求开发及实现，采用需求沟通备忘录及需求正反向追踪表确保需求的可追踪性，弱化需求变更的流程控制，迭代过程中软件版本入开发库管理，当迭代阶段完成后，回归瀑布模型研制模式，严格遵守软件需求变更流程，必要时需形成软件更改影响域分析报告，并通过会议评审，确保需求更改的可行性。
1.3 软件需求过程管理过程与其他过程域的集成
基于GJB 5000A的软件工程化建设是一个各个过程域相互影响、共同促进的过程，软件需求管理过程的不断推进也离不开相关过程域的支持。主要有：需求变更对项目策划过程的影响，将需求的变更转化为进度偏差，根据进度偏差超阈值的多少来进行合适的计划变更；需求变更需要依赖测量与分析过程统计相关数据，方便项目研制过程中项目负责人宏观把握需求状态的情况，也为组织级生存周期模型选型指南及决策支持提供了保证；配置管理过程为需求承诺及变更输入的有效性提供了支持，确保了软件需求追踪及变更活动不是无源之水。
2 软件需求管理平台建设
由于软件规模庞大造成的需求颗粒较多，对需求追踪及变更的有效性带来了实际执行困难，采用以往的Excel表格填写方式，不但严重耗费一线技术人员的时间和精力，而且不能保证追踪的有效性，久而久之，需求管理的执行有效性下降，以往项目运行的各种弊端重新凸显。我所与相关单位合作，尝试研发订制了软件需求管理工具，经试用，对提高人员效率，确保需求管理执行落到实处起到了促进作用。如：采用需求影响域分析，自动对变更工作产品的需求追踪关系进行分析，对于未变更的需求项，工具自动继承与上级工作产品的追踪关系，对于变更的功能项，用红色在需求跟踪矩阵中标注出来，需求管理人员只需根据红色标注索引即可对更改需求项的追踪关系重新定义，即可完成新一轮的需求追踪活动，工具会自动生成新版本的需求跟踪矩阵；针对表格化的需求跟踪矩阵不直观分析困难的特点，采取需求追踪关系图的表现形式，一列代表一个阶段的工作产品，列与列之间通过连线表现相关工作产品的追踪关系，当需求发生变更时，需求管理人员只需直接拖动并改变连线即可实现对追踪关系的重新定义。当发生需求追踪不一致情况时，只需根据本阶段需求实现要素与之前各阶段工作产品的需求项关联情况，逐级检查出中间环节未追踪上或未实现的需求条目。效果如图2所示。
3 结 语
通过为期1年的GJB 5000A二级全面运行，我所型号软件工程化水平有了显著提高，并实现了各型号软件均能够按期交付，靶场无低层次质量问题出现，EPG组对本地化流程及管理模式也有了更深层次的理解。在现有本地化需求管理过程的基础上，深化体系的本地化订制，使其与本单位实际情况更加贴合，促进执行力度。
第一，简化需求正反向追踪记录表，在各阶段软件设计文件中体现，无需再生成表单，简化设计人员的工作量，避免了多处产生同一张表带来内容不一致的隐患；
第二，对不同生存周期模型的需求管理活动的测量项进行梳理和定义，对于采用敏捷方法开发的软件弱化对需求变更情况的统计，加强对软件质量问题及研制进度的测量与分析；
第三，区分使用不同编程语言实现的软件需求跟踪力度，对于非代码行实现的软件可根据项目实际情况只追踪至模块和线程；
第四，在进行软件项目策划及需求定义时应充分考虑对软件重用构件库的建设，即对同一类软件的需求开发应本着重用的原则，具体体现在需求、接口、界面的重用需求定义，避免同类软件对同一功能模块进行的反复定义—开发—验证。