完整的变更管理流程

前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇完整的变更管理流程范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。

完整的变更管理流程范文第1篇

 

面向协作开发的软件配置与变更实验属于我校软件工程专业核心课《软件开发过程实战》，在第6学期开设，该实验是《软件开发过程实战》课程的最重要内容之一。学生在实验中针对真实的项目案例通过分组协作、精心设计以及完整的实践过程，达到深刻理解软件配置与变更管理的概念、熟练掌握相关软件平台与工具、切实增强动手能力与创新意识的目的。该实验连同《软件工程过程》等6门专业核心课程是软件工程专业近年来进行的所有课程、教学方法和考试等改革的中心，自2010年以来得到了教育部、山东省以及学校的一系列教学和实验改革项目的支持，共计十余项。

 

该实验项目“打破课程界限”、将多门软件工程核心课程知识融入一个完整的实验过程，实现了以课本为中心到以实践为中心的转变，达到了课程指导实践、理论知识在实践中还原的教学效果。该实验从2010年开设以来，已有软件工程专业5界四百多名学生受益，学生的功能实践能力和创新意识得到明显提高，相关学生获得省级以上科技活动奖励四十多项;学生的就业率得到持续提升，从2009年的71.43%提升至2015年的98.7%，且就业层次明显改善。该实验及相关课程建设也得到了教育部相关专家的肯定，认为我们施行的“基于项目的教育与学习”是实现软件人才工程能力培养的重要途径，是高校进行软件工程教学改革发展的基本方向。该实验项目作为《软件开发过程实战》的重要组成部分，在软件工程专业培养方案中具有更加重要的地位，作为提高学生工程实践能力和创新思维的重要实践环节将长期存在。

 

一、实验构建的目的及意义

 

通过该面向协作开发的软件配置与变更实验的开设，旨在达到以下主要目标：(1)加深学生对软件配置与变更管理这一软件工程专业重要知识域的理解与掌握，特别是通过实验使学生明确区分并熟练掌握项目区域、时间线、迭代、流、组件、变更等核心概念及其相互之间的逻辑关系;(2)切实增强学生在协作式软件开发过程中对软件配置与变更理论的应用能力，对相关工具平台的熟练操作水平;(3)提高学生的团队合作、团队管理能力，培养学生自主学习、自主设计的能力以及脚踏实地、开拓创新的精神。

 

该实验项目是我校软件工程系列核心课程的重要实验之一，通过该项目的建设不仅进一步完善实验体系、规范实验流程、提升实验质量，更将形成示范性的精品实验，为本课程其他实验以及类似课程实践环节的建设提供有益的参考与借鉴。

 

二、实验构建的理念和设计思想

 

该实验以CDIO工程教育理念为指导，深入贯彻“做中学”原则和“基于项目的教育和学习”方法[1，2]。实验过程把《软件项目管理》、《软件工程过程》、《软件质量工程》以及《软件测试与维护》等4门课程中有关软件配置与变更的知识点融入到一个完整的实践过程中，要求学生在实验中自行设计场景、践行升华理论、增强动手能力[3]并培养协作和创新意识，从而解决了“工程理论来源于实践，在实践中还原”的教学难题。

 

该实验设计包括一个逐步递进、结构完整的综合实践过程，学生随着实验的深入将逐步接受、运用相关的理论知识，并通过实验总结实现对知识掌握、技术运用的提升，实验方案的主要内容设计包括：(1)软件配置与变更场景设计，每个小组基于各自既定的项目案例，设计能够涵盖所有典型变更流程的场景及规划;(2)软件配置管理过程，依据规划配置开发流和组件、基础代码等资源、团队个人空间和开发任务等;(3)软件变更实施过程，协作完成变更任务开发、代码的交付与接受、检入与检出、冲突及解决等内容;(4)软件配置与变更的监控过程，从团队、成员个人、工作项和工件等角度进行项目的监控;(5)实验总结，撰写实验报告，总结所用知识点及过程状况等。

 

三、教学方法、手段及考核体系

 

1.团队协作式实验方式与企业标准化实验流程。实验中以学生意愿为主，组织学生建立了学生项目团队，采取全员参与、角色扮演、协作学习、研论教学、交流共享等多种形式，使学生成为认知的主体、知识的主动建构者。参照企业模式组建的项目团队，以学生自愿为原则，由学生按照4至5人的规模组成;每个学生都参与到团队中，依据个人愿望和能力至少扮演一个团队角色，在重点完成自己的职责任务基础上，进行交流协作，使得每个人最终都达到课程的教学目标。

 

制定了以企业标准化项目开发过程为主线的标准实验流程，模拟实战开发，实现“以验证实践为中心到以实际项目为中心的转变”。目标是使学生能够在近乎企业真实场景之下，使用行业先进的设计工具、开发环境进行实战训练，系统化、规范化地实施学生工程能力培养。

 

2.先进的协作式软件交付平台。采用了业界最新的IBM Jazz软件协作交付平台，使得在实验中学生团队不同的角色和工作环节之间，工作任务能够自动流转，工件信息自动传递，工作数据和过程自动记录、自动收集和汇报，全生命周期的可追踪性自动建立。从而使学生实现了软件交付过程中人员、项目、工具和流程的整合。

 

3.过程化多角度的考核评价体系。实验考核方法综合考虑了学生实验过程的平时表现(通过Jazz平台)、分组答辩和实验报告，过程监控10%+分组答辩*50%+实验报告*40%。其中“过程监控”是通过IBM的Jazz平台进行实时的监控和评分;“分组答辩”是教师给本组一个分数，该组内，由项目经理负责给该组成员打分，组员的平均分不能超过教师给该组打的分数;“实验报告”根据文档的完整性、规范性、系统性进行评分，反馈结果用于暑假小学期的软件项目实训。

 

四、实验设备和环境建设

 

实验项目在“IBM软件工程联合实验室”(与IBM共建)开展。近几年，学校在实验室建设方面投入了大量的资金，硬件设施得到了明显改善，完全按照国家相关标准进行建设。软件方面，我们购置了一整套IBM全程体验软件工程最佳实践和协作的Jazz平台来实施基于项目驱动的软件配置与变更实验，包括需求定义工具RRC和需求管理分析工具Doors;软件建模分析工具RSA;测试管理平台RQM、软件功能自动化测试工具RFT、压力测试工具RPT;协作平台RTC。

 

同时，实验室也非常注重文化和安全制度建设。强调合作与创新，美化实验室的学习环境，突出浓郁的知识探索氛围，培养学生良好的实验习惯等。此外，也明确了所有实验人员的岗位职责，使得实验室安全管理工作有章可循。

 

五、总结

 

作为我校软件工程专业核心课《软件开发过程实战》最重要的内容之一，面向协作开发的软件配置与变更实验在提高学生的工程实践能力和创新意识方面起到了重要的作用，该实验主要的创新点有以下几个：

 

1.一体化实验内容设计、独立的实验实施过程。一方面，本实验项目中进行的软件配置与变更实验内容采用了本课程中一致的项目案例，做到全程一体化设计;另一方面，该项实验又包含了完整的实验环节和过程，具有相对独立性，可单独开设、独立实施;

 

2.实验方法和形式上，贯彻“基于项目的教学”和“开发驱动的实践”，采用团队式协作开发方式，实现了从以“课本为中心”到“以项目为中心”、以“课堂为中心”到“以项目开发为中心”、以“教师为中心”到“以学生为中心”的转变，激发了学生自主学习和实践的积极主动性，增强了学生的工程实践能力。

 

3.实验技术和手段上，引入了IBM的最新软件交付平台及配置与变更管理工具，采用Scrum敏捷过程模板和企业标准化的实践流程，体现出较好的先进性和规范性。

完整的变更管理流程范文第2篇

关键字： 机载处理系统; 需求工程; 需求获取; 嵌入式系统

中图分类号： TN911?34 文献标识码： A 文章编号： 1004?373X（2014）24?0065?03

Study and exploration of requirement engineering method of airborne integrated processing system

WANG Ming， XIE Wen-tao， ZHANG Lei， GAO Yang，

（Aeronautical Computing Technique Research Institute， Xi’an 710068， China）

Abstract： Focusing on airborne processing system， the contents， characteristics and difficulties of requirement development and management in requirement engineering are illustrated in this paper. The key points in requirement engineering of complicated airborne embedded systems are pointed out. The research directions of requirement development and management are proposed in combination with the application characteristics of the airborne comprehensive processing system.

Keywords： airborne processing system; requirement engineering; requirement acquirement; embedded system

0 引 言

机载综合处理系统作为载机平台中最重要的核心系统之一，为载机提供一套系统的综合处理与公共计算资源;包括处理、存储、控制、接口管理、信息交换等功能。对于机载综合处理系统这种愈来愈复杂的网络化嵌入式系统的研制，就必须重点把握需求，从需求获取、需求采集、需求管理、需求前期的建模分析和后期基于需求的验证等全生命周期各个需求相关环节进行管控，必须针对此类产品建立一套完整的理论和方法，以及完整的体系化的工具链。本文研究了复杂机载综合处理系统的需求工程的理论、思路和方法。

1 机载综合处理系统需求工程

机载综合处理系统需求工程是系统生命周期的第一阶段，需求工程通俗讲是指该系统应该做什么，而不是该怎么做。机载综合处理系统需求获取需要三个不同相关方的协作：开发者（研制单位），客户（主机单位），用户（设备使用者）。规范详尽的产品需求来自早期非正式的粗略的概念和想法，不断结合三个相关方的需求和约束，历经多次分析、验证和迭代形成最终的系统需求。

机载综合处理系统需求，是指主机用户解决机载应用的若干问题或达到机载综合处理应用目标所需要的条件或能力，该条件或能力须有由一套满足相关约定、标准级规范的系统实现。

机载综合处理系统需求工程需要回答如下问题：

（1） 如何定义鉴别某个机载综合处理系统的目的：什么是内部系统（机载综合处理系统内部的架构、通信网络、组成、性能等），什么是外部系统（机载综合处理系统对外功能、交联接口、数据通信、环境适应性、成本等）;

（2） 机载综合处理系统需求获取过程中有哪些错误：系统不能支持用户工作（系统功能失效）、功能缺失或错误（部分功能不能实现或工作结果与预期不一致）、纠错需要付出巨大代价（纠正出现的错误，所需要付出的物料、人力、周期等巨大的代价）。

机载综合处理系统需求工程（RE）面向硬件和软件两个方面[1]，目标是形成系统需求规范，包括两大部分：需求开发（RD）和需求管理（RM），如图1所示。其中需求开发包括获取、分析、沟通、形成文档、确认生效;需求管理包括：变更控制、版本控制、状态追踪、追溯。

图1 需求工程的组成

机载综合处理系统需求工程的输入：

（1） 预期系统的一个模糊想象，即某系统或子系统产品的研制协议或成品开发协议;

（2） 协议中的承研单位、主机单位等各自利益的相关方规定;

（3） 完整的问题陈述，即对机载综合处理系统要求的完整描述。

机载综合处理系统需求工程的输出：

（1） 一套尽可能完整的规范，即最终的系统级产品的系统规范或研制规范;

（2） 完全覆盖所有问题，即所有相关需求均已捕获，研制规范或系统规范完整覆盖了所有陈述的问题;

（3） 完全且精准的定义每一条需求，无遗漏，无歧义。

需求工程的三个维度目标[2]，如图2所示。

图2 需求工程的三个维度目标

规范（Specification）：开发尽可能完全的需求规范，包括成本计划;

表达（Representation）：提供综合完整的所有方面的表现：非正式，半正式，正式的需求;注意这几种表达之间的转换问题;

一致（Agreement）：完成与最终规格公共的一致，期间允许有个人的意见。

2 机载综合处理系统需求开发

机载综合处理系统的需求开发的重点是需求获取和需求分析。

需求获取和需求分析的区别及关系如图3所示。

图3 需求获取和分析的区别及关系

对于机载综合处理系统的需求获取工作，必然需从问题陈述开始，问题陈述是由客户面向系统层面描述问题（主机面向载机应用层面）。

2.1 机载综合处理系统产品的问题陈述

（1） 所处的位置和当前的情势：机载综合处理系统产品所属载机分系统位置（航电、机电、飞控、辅助动力控制、或者全机深度综合系统等）和当前有哪些现有条件;

（2） 新系统所应提供的功能：机载综合处理系统产品本身应该提供的功能，以航电为例，可包括任务综合、导航控制、显示控制、存储能力、对外接口等;

（3） 系统的开发环境：机载综合处理系统产品本身开发所限定的系统级、子系统级、部件级的硬件及软件开发环境;

（4） 客户希望的可交付形式：协议约定的机载综合处理系统产品的交付形式，一套系统、或一台整机，随机设备、随机资料等;

（5） 交货日期：约定的交付日期;

（6） 一套接受的标准：规定了机载综合处理系统产品研制所必须遵循或建议遵循的一套标准，包括质量过程标准、软硬件设计标准、过程及最终验证标准等。

2.2 影响机载综合处理系统产品问题陈述优劣的因素

（1） 机载综合处理系统产品所面临的情势和亟需解决的问题;

（2） 若干系统级的应用场景的描述;

（3） 初始需求：功能需求、非功能需求、约束（伪需求）;

（4） 项目计划：包括系统最终交付期在内的用户关注的重要里程碑;

（5） 目标环境：交付系统必须执行一套详尽系统测试检验的环境;

（6） 客户接受标准：系统测试检验的标准。

3 功能需求和非功能需求

功能需求：描述系统和其环境交互作用，与具体实现无关，机载综合处理系统产品的功能需求主要描述该系统承担的功能、与载机其他系统的接口互联、数据通信及对外承担功能，与产品本身的具体内部组成、体系架构、实施方案、组件选型均无关[3]。

非功能需求（A类最典型）：

（1） 用户看见的与功能行为不直接相关的方面（表象）。

（2） 可靠性，安全性、维修性、测试性、综合保障性、性能、有效性、可用性、支持能力、适应性。

伪需求（B类非功能需求）：系统运转时受到客户或环境的影响、法律需求、设计和实现约束，如容错能力、高低温适应性、电子兼容性等环境适应性能力;

项目需求（C类非功能需求）：产品研制预算经费、合同额、交付日期等。

对于机载综合处理系统产品来讲，系统架构、实现技术、开发方法、开发环境、实现语言、重用性等通常都不是需求[4]。功能及非功能需求的树状图如图4所示。

图4 功能需求及非功能需求的树状图

4 机载综合处理系统需求管理

需求管理包括：变更控制、版本控制、状态追踪、追溯。

需求管理，实际是管理需求变更的若干过程，开发过程中的连续的变更带来的诸多困难问题。其主要关注点包括：管理需求间关系，管理需求优先级，管理不同文档间的从属性（需求文档，需求规格，研制系统过程中其他文档），管理需求一致性变更[5]。

需求管理涉及的过程包括：变更和追溯，没有追踪性则无法有效管理需求。追溯性含义：谁提出的需求，为什么存在需求，需求与什么相关，如何将需求与其他信息关联（系统设计、实现、用户文档）。

（1） 威者工具支撑

需求管理工具包括：采集、存储、大数据量信息的维护;

为支撑需求管理而定制设计的不同的可用工具;

适用与需求工程的其他工具：配置管理系统、邮件系统、共享工作区。

（2） 需求管理工具支持功能

用于存储数据的数据库系统;

用于文档分析和生成的工具：构建需求数据库，生成需求文档;

帮助确保变更完全落实的变更管理工具;

帮助需求工程师找到系统需求间依赖关系的追踪工具。需求管理各环节关系如图5所示。

图5 需求管理各环节关系

5 研究方向

根据需求工程的理论，针对机载综合处理系统需要建立需求开发和需求管理两部分集成定制工具，必将极大的提高此类复杂嵌入式系统的研制水平。

（1） 集成定制需求开发工具。需要建设定制的基于模型的需求建模分析仿真的相关的需求开发工具，整合多个需求建模分析工具，建成适应机载综合处理系统产品特点的需求建模仿真分析专用的集成工具，解决工具分散孤立的问题，使之能对系统的各种特性进行需求分析[6]，最终形成完整的需求建模、分析、仿真的规范流程和完整工具链。

（2） 集成定制需求管理工具。需要建设定制面向全生命周期的需求管理相关工具，整合多个需求相关环节的工具，建成适应机载综合处理统级产品特点的需求采集管理工具，能形成完整的需求采集管理模板和管理流程以及完成的工具链，形成贯穿全生命周期的基于需求的信息化管理能力。

6 结 语

本文结合机载综合处理系统产品的应用特点，系统地介绍了需求工程所涉及的需求开发和需求管理两部分内容的理论和特点，分别介绍两部分工作中各自的重点难点以及指导依据，并且提出了针对机载综合处理系统这类复杂系统产品在需求开发和需求管理两个方面所需集成定制的工具链。

参考文献

[1] GONG Yi?fan， PU Xiao?bo， LIU Jun， et al. Rapid prototype design method in avionics system based on UML [J]. Journal of System Simulation， 2007， （4）： 749?753.

[2] 赵立军.基于SysML的需求分析研究[J].计算机技术与发展，2011，21（12）：145?147.

[3] 刘剑，王智学.基于本体的需求获取方法研究[M].北京：清华大学出版社，2005.

[4] 王智学.基于能力的复杂系统需求分析[C]//江苏省系统工程学会军事系统工程委员会第十届学术年会论文集.南京：江苏省系统工程学会，2008：125?128.

完整的变更管理流程范文第3篇

负载超额、变更未经测试、流程设置不合理、缺乏相关培训、遗忘操作规程……权威数据显示，在造成系统停机的原因中，软硬件故障只占20% 的比例，而人为错误、系统架构和应用程序故障所占比重高达80%。

IBM全球服务部大中华区金融事业服务总监余兆祥坦言，国内企业在实施IT系统时，很多时候道理是清楚的，但实施中因为过去既有的包袱让理想无法实现。CIO不是只告诉整个企业什么是高可用性（计算机系统的可用性是通过系统的可靠性和可维护性来度量的。工程上通常用平均无故障时间(MTTF)来度量系统的可靠性，用平均维修时间(MTTR)来度量系统的可维护性），还有一个任务是怎么样把愿景用可实施的方式表达出来、落实下去。CIO有两个任务，一是要把不同层面的期望值弄清楚，二是用一套方法落实TSA（全面高可用性）。

在当今这个高速发展的信息化时代，IT 系统的可用性已逐渐成为企业把握市场机会的重要工具，过去银行买机器的投资非常大，要求的标准非常高，事实证明结果还是不尽如人意的。为什么不尽如人意呢？因为过去做项目在采购的行为上比较缺少从全面、整合的角度去思考问题，IT技术过去只是依靠某一个元件、一个CPU或者一个服务器，但这被证明并不能完全支持高可用性。也就是说，今天整个IT系统如果不能从各个环节去考虑，包括硬件、软件、网络、服务、运营去思考可用性的问题的话，常常会以偏概全、挂一漏万。

余兆祥分析说，高可用性已经是老生常谈的话题。但IBM发现，其实董事长、银行行长、CIO想的可用性跟科技部负责人想的可用性，甚至包括运营老总想的可用性是不一样的。怎么样去用一套东西服务不同人的要求，这是首先要解决的问题。

如何让高可用性落地呢？余兆祥认为，保障系统的高可用性，不但关系到IT系统的每个环节，而且需要在正确的战略目标指引下，建立完整的结构衡量体系和标准管理体系，其关键在于IT系统、应用流程、组织管理和业务发展之间的集成管理与平衡。

从程序来看，第一步，必须得从咨询开始，就是要自建企业现在的IT环境以及TSA要达到的目标。

第二步就是要建立Management Processes（管理流程），一个IT的环境不能没有一个完整的、成熟的管理体系，全世界的经验告诉我们，所有硬件的投资，如果背后没有一个很好的Management Processes，这个投资会事倍功半。

第三步是建立Operationl Processes（运营流程），很多企业有很好的硬件、软件以及完整的管理方法。但是真正的操作员在实施运营、每天做运营服务的时候，没有遵循一个标准的运营模式和守则，或者有了运营守则没有彻底地执行。

第四步是建立IT的基础架构，包括硬件、软件、中间件。

问题测试：你的企业IT需要高可用性吗？

是否需要IT系统24×365 地持续运行？

是否迫切需要将IT系统的宕机风险降到最低，并能从系统中断状态下迅速恢复？

是否需要全面完善系统架构，提高IT系统的安全性和可用性？

是否需要优化系统管理架构，提升IT管理能力？

是否需要改进系统运行管理框架，变被动服务为主动服务？

是否需要从技术和管理两方面提高IT系统随需应变的能力？

完整的变更管理流程范文第4篇

【关键词】电力调度；流程；调度业务；应用系统

引言

在电力系统中，电力调度机构是电力企业管理生产运行的中枢部门，肩负着保障电网的安全、稳定、经济运行的重要任务。近年来，由于电力行业的快速发展，电网结构的日趋复杂，供电质量标准的不断提高，电力调度机构需处理的业务也日益增长。如新投运方案审批、设备变更审批、检修停电计划申请等各种调度业务不断的增多，传统调度管理方式已经难以适应不断发展的电网的需要。传统调度管理方式主要采用人工操作模式，如手工开票、人工送审、电话通知等，这种工作方式易造成工作效率低、准确性差、职责不明确、耗时长等弊端，因此开发一套的电力调度业务流程管理系统，提高调度管理质量和效率是十分必要的。

1、系统功能

白山电力调度业务流程管理系统根据调度业务实际工作的需要，本着为切实服务基层、服务安全生产、服务管理工作的原则，建立一个完整的网络管理系统。该系统不依赖原有办公平台，采用独立的数据存储，只需要分配独立的WEB地址，并且可以作为一个独立模块内嵌于公司网站，实现调度业务流程审批管理，该系统需实现以下4点功能：

（1）调度业务流程管理全过程网络化，提高审批效率，降低人员劳动强度。

（2）提高调度业务流程管理的规范性、标准性，明确责任。

（3）对调度各部门信息集中处理，避免信息孤岛情况，同时信息资源按用户权限共享，保障信息安全。

（4）实时对调度业务流程审批进展进行浏览，为生产决策提供实时时效的信息。

2、系统设计方案

白山供电公司在企业内部局域网建立一个网络化应用系统，将日常调度业务审批融入到该调度流程管理系统中，提高调度办公效率。

2.1系统模式

该系统采用B/S（浏览器/服务器）体系结构，前台采用JSP技术实现。该系统应具有以下特点：

（1）以企业内部局域网为基础，实现调度业务流程网络化审批管理。

（2）系统采用高性能服务器，多台客户机通过网络与服务器相联。服务器端操作系统采用Windows Server。

（3）数据库采SQL server 2008。数据库安装在服务器上，客户机通过浏览器访问服务器，共享服务器上的数据。

（4）系统设置多级用户权限，数据按用户权限实现分级共享，保障了数据的完整性和安全性[3]。

2.2系统结构

系统数据库安装在专用服务器上，数据库服务器为客户机处理信息和存储数据，各客户机通过局域网与服务器相连，共享存在服务器上的数据库数据。网络结构如图1所示。

3、系统的基本管理模块及主要功能

白山电力调度业务流程管理系统根据白山调度生产实际工作的需求，围绕调度工作的重点，提供了包括新设备投运方案、设备变更、设备运行方式及参数变更、运行方式票等共9个子系统模块组成，全面覆盖了调度生产的流程管理业务，为生产管理带来了极大的便利，并提高了工作效率和质量，使调度管理进一步规范化。模块介绍：

3.1新设备投运方案审批

该模块流程由运行方式专工拟稿、调度所长签署审批意见、主管局长签署审批意见、抄送至部门负责人、下发至运行单位等环节组成，每个环节完成后才传送至下个环节。分别在调度所长，主管局长同意前，发现错误可以返回上一环节进行修改，同意后，便进行下一环节，最后直到抄送至相关运行单位。用户使用各自的用户名和密码登录系统后，系统将根据本人的权限情况，不同程度地开放其对新设备投运方案处理的功能。各级管理者能方便地通过管理系统对调度操作流程的进展情况进行查询，实现对调度工作的在线监督和指导。

3.2设备检修票审批

该模块流程由生产单位、检修计划专工、运行继保专责等主要部门或负责人完成。通过一系列审核修改和安全技术校验步骤，最后发至调度室，自动排版打印，形成检修票，然后归档保存（见图2）。各级用户完成对检修票审批的相应工作，设备检修票编号由系统生成，无法修改。

以上是该系统两种流程模块功能的简单介绍。调度业务流程管理系统操作方便快捷，用户只需要根据系统提示，完成相应的内容填写和操作便可以进入下一流程环节。

4、结论

完整的变更管理流程范文第5篇

关键词:质量管理;软件开发;应用

Application of Quality Management in Software Development

ZHU Yan, WANG Fang, YANG Yu

(Jiangsu Suzhou Power Supply Company, Suzhou 215004, China)

Abstract: With the high-speed development of software industry, overtime and over-budget of software development have become the most concern to the software industry. In order to effectively manage software development, some companies also introduced an important post, quality management, to manage and get feedback of the project information in time, thus all important trouble can be controlled in early stage, and a lot of manpower, resource and finance will be saved.

Key words: quality management; software development; application

随着社会信息化水平的不断提高,随之带来的信息市场竞争激烈。企业为了求生存,在市场竞争中处于不败之地,满足客户要求则成为各行各业的首要责任。如今的IT项目,软件工程倍受关注,而软件的质量更是重中之重,因此,要求企业对质量管理加强认识。目前,软件质量管理基本使用定性指标,软件质量保证理论侧重于解决组织和管理的流程问题[1]。

软件质量模型早期由McCall 提出,在此基础上,国际标准化组织(ISO)提出软件质量的三层模型[2-3]。软件项目的质量管理主要包括:质量计划编制、质量保证和质量控制三个过程域。质量计划是根据项目的立项文档,对具体的计划执行情况进行裁减,其内容全面反应用户的要求,为质量小组成员提供了工作指南,为整个项目组成员提供了工作标准和工作依据,为确保项目质量提供了坚实的基础。质量保证则是贯穿整个项目全生命周期的有计划和有系统的活动,经常性地针对整个项目质量计划的执行情况进行评估、检查与改进等工作,向管理者或其他方提供信任,确保项目质量与计划保持一致。质量控制必须对阶段性的成果进行测试、验证,而很多失败的软件开发案例正是由于在测试中发现了先天存在的、无法修复的缺陷,这更说明了质量管理在软件开发中的重要性[4]。

1 未实施质量管理的劣势

公司在软件开发方面逐步向正规化发展,以前在软件开发方面比较随意,存在的缺点主要有:很能全面考虑技术难点,影响项目开发的整体进度;没有规范统一格式的开发代码,开发人员编写的代码风格迥异;技术文档在项目开发过程中没有统一管理,导致项目开发杂乱无章等问题。考虑到以上问题,公司在软件开发方面增强管理力度,软件开发的质量管理也逐渐提入公司的日程。

2 质量管理的优点

公司在软件开发方面采用质量管理,带来很多优点,提高公司的工作效率与收益。质量管理的优点具体如下:

2.1 保证项目进度

项目进度与项目计划是否一致直接决定软件开发是否顺利。一个合理的项目计划对项目开发尤为重要,而要制定合理的项目计划,与项目计划制定者从事类似工作的经验有直接关系。经验丰富的项目计划者可以预见潜在的风险,在问题细节上也考虑得更周全,更能保证项目进度和计划的一致性。图1是某个项目的项目计划实施情况。

项目计划制定初期,由质量管理小组召开项目计划评审会,讨论项目计划的可行性,对计划中不合理的地方进行修改完善,并由质量管理人员对其结果跟踪,以确保项目计划完整性和可行性,完善的计划交由配置管理人员进行管理。

计划实施过程中,计划并不是固定不变的。当发生变化时,质量管理小组报告项目经理,由项目经理负责对计划进行维护。使项目按新调整后的计划正常进行,并且尽量让开发进度赶上原先的项目计划。项目计划以里程碑为界限,将整个开发周期划分为若干阶段。里程碑在项目开发过程中有着很重要的作用,每个里程碑都要有阶段性的成果交付,同时可以根据里程碑将项目计划作动态调整。

2.2 项目开发过程中监管

2.2.1 需求

需求分析是指理解用户需求,就软件功能与客户达成一致,估计软件风险和评估项目代价,最终形成开发计划的一个复杂过程。在此过程中,用户是处在主导地位,需求分析工程师和项目经理要负责整理用户需求,为软件设计打下基础。在开发过程中,开发前期犯下的错误,会在开发后期被累积和放大,时间越久,纠正错误所花费的代价越昂贵,也越发影响系统的工期和系统的质量。解决这些错误的方法时通常采用邀请用户参与进行需求评定,用户的意见由质量管理员跟踪。即所有需求的实现过程都得到跟踪、监督与验证;所有需求的变化都得到控制、理解和处理[5-6]。

虽然在需求调研期间积极地和用户沟通,但仍然避免不了项目进行中用户的需求,如变更请求。由质量管理小组组织讨论实施变更的可行性及实施后所带来的影响,无论哪种变更都需要对相应的资料实施同步变更。若变更会带来巨大影响而导致项目进度的延期,项目组需要将变更报告提交给用户并同用户进行协调,讨论变更的取舍问题或是项目进度变更问题。决定变更之后,质量管理成员监督变更实施过程并协助配置管理员对变更后涉及的资料进行版本控制。

2.2.2 设计

优良的体系结构应当具备可扩展性和可配置性,而良好的体系结构则需要优秀的设计方法,因此,设计选型成为了系统设计首要的工作。对于设计选型需要针对项目的结构、项目的特征和用户的需求来分析,同时还要要考虑到参与项目开发的小组成员的整体素质。例如,项目经理选择的设计方法具有明显的优势,但项目组部分成员并不是十分熟悉这种设计方法,而且在时间评估上没有考虑到某些程序员的学习适应期。在这个项目的开发过程中,存在了严重的项目延期问题,由此可以看出,设计方法的选择对项目开发的重要性,尽管有些设计方法有明显的优势,但是熟悉的设计方法能为项目的开发节省许多时间,正确的选择可以减少项目承担的技术风险。设计方法的选择需要由质量管理小组组织讨论,确定设计方法更具有可操作性,确定后项目组根据设计方法实施。

公共类开发要求项目组成员在设计阶段通过对用户需求的仔细研究,尽可能的识别、提炼出公共类,并进行定义。公共类应该具有通用性、可复用性,对公司和个人都是有利的,对项目组成员是一种学习的机会,另外可以为公司节约大量的成本和缩短工期。公共类开发后由质量管理小组把关,确认没问题后交由配置管理员保存入库,方便开发人员长期使用。

2.2.3 实现与测试

系统实现也就是软件代码的编写过程,这里不仅包括代码的产生,同时也包括测试用例的产生。开发人员针对项目组之前的详细设计,程序员编写代码,调试代码。每个阶段质量管理小组都要对项目组进行管理,在编码过程中检查项目组的开发代码,有问题直接让开发人员修改。测试人员不仅要测试软件的功能是否完整,还要测试软件的性能。软件的性能也直接影响到软件开发的成败,为了避免重头再来,项目组必须要重视性能测试。

测试人员则根据系统设计编写测试用例和测试计划。测试用例和测试计划都需要经过质量管理员组织的评审会评审。测试人员按照测试计划和测试用例,对项目进行测试,并把测试出来的问题及时反馈给项目组,项目组根据测试问题的严重级别,修改程序代码。只有当程序员调试完程序,测试通过并通过质量管理小组审核后,才可交给用户测试、验收。

2.2.4 维护

系统维护由维护人员担任,负责保证客户的使用质量。维护人员不仅要了解项目的技术核心内容,同时也要与客户沟通。这样当用户提出维护问题时,才能根据具体情况判断出问题的根源。筛选出是用户的使用方法问题、环境问题等普通原因,还是确实是程序的BUG、程序的修改问题。如果没有指定的维护人员,那么项目组的开发成员可能会一直被老项目影响,没办法专心投入新项目,从而形成一种人员浪费。当维护人员发现是程序缺陷,需要修改时要走变更控制流程。大的修改由开发人员对已的程序修改,并由质量管理小组对整个修改过程作变更控制,修改结束后由测试小组测试通过后新版本交付用户。小的修改由维护人员实施,同时变更所涉及到的一切资料。

2.3 保证项目文档

项目开发过程中的文档对整个项目来说也是不可或缺的。一个软件项目没有了文档,就好像迷路的人没有了地图,遇到问题时就没依据可循。

在质量管理还没成型,项目组人员还没习惯写文档时,会觉得写文档是浪费时间,不写各类文档直接进入编码阶段可以直接切入主题,肯定比写文档的进度快。但随着项目的逐渐深入,各种问题也接踵而来,需要部门间配合的工作也越来越多。一个大的项目是一个团体合作的工作,需要了解其他人员的技术方向和开发思路。当某些环节需要相互配合时,就能显现出文档管理的重要性。

编写文档并不是项目组成员随心所欲、自由发挥的,而是经过质量管理小组、软件组负责人及相关业务人员讨论得出公共模板,每个文档都有标准模板,这样编写文档的速度也会很快。有了完整的项目文档,就不会因为项目开发人员的辞职而耽误开发进度,减少了整个项目组对某个重要开发人员的依赖性,也减少了软件开发的风险成本;有了完整的项目文档,给项目后期的维护工作带来了便利。

文档管理的归档工作是由配置管理小组负责的。重要文档是由质量管理小组审查合格后提交给配置管理小组的。做一个大的项目,必须要有完整的项目文档做支持。

3 结束语

从软件开发的实际情况可以证明,优质的质量管理可以节约大量的人力、物力和财力,同时可以保证软件的质量。实践证明,软件工程项目的成败与否,一般与项目的管理直接相关,而与技术的关系。要想做一盘“完美”的软件大餐,质量管理的作用是不言而喻的。

参考文献:

[1] Silva R N,Murray G W.Low cost quartz rate sensors applied to tactical guidance IMUs[C].Proceeding of the IEEE Position,Location and Navigation Symposium,1994:37-42.

[2] 胡小平.自主导航理论与应用[M].长沙:国防科技大学出版社,2002:194-203.

[3] 陈哲.捷联惯导系统原理[M].北京:宇航出版社,1986:143-147.

[4] 匡启和.RTLinux环境下导航系统的设计与实现[J].导航,2001:37(4):58-60.