软件质量岗位职责(通用10篇)
软件质量岗位职责 篇1
软件质量在软件开发中占有重要的地位, 在软件开发的各个阶段必须给予高度的重视, 否则会影响软件的使用。软件质量的度量可以采用相关的技术模型, 通过具体的指标得以反映。软件的复杂性与软件的质量有密切的关系。结构简单的软件, 对于保证软件的质量有很大的帮助作用, 所以在进行软件设计时, 应当尽量保证设计简单的软件结构。软件的可靠性是软件质量的反映。从某种意义上说, 软件的可靠性高说明软件的质量高, 软件的可靠性可以通过有关指标和模型反映出来。在软件开发中, 要保证软件的质量, 因此应当尽量避免软件错误, 其中, 有些避免不了的错误应当采用软件容错的技术进行解决。
2 软件质量问题分析
软件不同于硬件, 软件不会用坏, 不存在零件更换问题, 但不允许存在误差, 不能发生错误, 否则后果十分严重。医疗系统中的软件错误可能造成生命危险, 银行系统中的软件错误会使金融混乱, 航空管理系统中的错误会造成飞机失事。例如, 美国在一次发射火箭的实验中, 由于飞行计划程序里漏掉一个连字符而导致了火箭实验的失败。任何企业都需要有效的管理方法, 软件企业需要的管理方法又与其他类型的企业不同。
在国内软件企业管理的经验比较少, 人员也比较缺乏, 没有形成一个有效的体系。国际上流行的软件过程的认证方法 (如, IS09000和SW-CMM) 在国内虽然已引起足够的认识, 但通过认证的情况并不理想。在这种情况下, 软件企业承担大型软件工程和系统设计、开发、集成能力相对较弱, 并造成在国际市场上处于不利的竞争地位。当前, 软件质量问题比较多, 其主要原因是软件企业管理水平跟不上。
3 影响软件质量的因素
软件的正确性、可靠性和安全性是影响软件质量的三个重要因素。根据Mc Call等人提出的软件质量度量模型, 正确性是指程序满足其规格说明和完成用户任务目标的程度。正确性的评价准则包括:可跟踪性、完整性和一致性;可靠性是指程序在要求的精度下, 能够完成其规定功能的期望程度。可靠性的评价准则包括:容错性、准确性、一致性、模块性和简洁性;安全性则是对软件的完备性进行评价的准则之一, 指控制或保护程序和数据机制的有效性, 比如对于合理的输入, 系统会给出正确的结果, 而对于不合理的输入程序则予以拒绝等。在1985年ISO建议的软件质量度量模型中, 正确性和安全性是软件质量需求评价准则 (SQRC) 中的两条准则, 前者包括软件质量设计评价难则 (SQDC) 中的可跟踪性、完备性和一致性, 后者则包括其中的存取控制和存取审查。而Mc Call模型中的可靠性因素则体现在可容性准则和可维护性准则中。其他的影响软件质量的主要因素有:
1) 可测试性:程序容易测试的程度。
2) 适应性:修正和改进系统所需要的工作量的大小。
3) 可维修性:诊断和改正系统错误所需要的工作量大小。
4) 效率:为了完成预定的任务, 系统耗费资源的程度。
5) 可理解性:理解和使用该系统的容易程度。
6) 可用性:系统在完成预定功能时令人满意的程度。
7) 风险性:按预定的成本和进度开发出系统, 并为用户所满意的程度。
4 改进软件质量保证的技术
4.1 软件复用技术
由于封装和继承的特性, 面向对象方法比其他软件开发方法更适于支持软件复用。封装意味着可以将表示构件的类看做黑盒子。用户只需了解类的外部接口, 即了解它能够响应哪些消息, 相应的对象行为是什么。继承是指在定义新的子类时, 可利用可复用构件库中已有的父类的属性和操作。当然, 子类也可以修改父类的属性与操作, 或者引进新的属性与操作。构件的用户不需要了解构件的实现细节。
4.2 容错技术
所谓“容错”, 就是在出现有限数目的硬件或软件故障的情况下, 系统仍可提供连续正确执行的内在能力。容错和避错是不同的, 容错主要是针对版本中的故障向系统提供保护。组成容错软件的每一个版本的程序设计也要求尽量采用避错技术, 防止单版本领繁出错。但在容错系统的单版本设计时, 避错技术的应用要考虑成本分配上的合理性, 以使总体上符合效益成本比最大的要求。软件容错的目的是屏蔽软件故障, 恢复因出错而影响的运行进程。尽管对于整个这类系统来说, 由于硬件 (包括软件载体) 瞬时干扰引起的故障也能起到一定的屏蔽作用, 但它和专门设计的、以软件为手段实现硬件容错的系统是不同的。软件容错的实现需要硬件的保证和协同。如果软件容错配合以合理的硬件冗余, 可以起到比各自单独考虑容错更好的作用。
4.3 软件工程标准化
在开发一个软件时, 需要有多层次、不同分工的人员相互配合;在开发项目的各个部分以及各开发阶段之间, 也都存在着许多联系和衔接。把这些错综复杂的关系协调好, 需要有一系列统一的约束和规定。在软件开发项目取得阶段成果或最后完成时, 还需要进行阶段评审和验收测试。投入运行的软件, 其维护工作中遇到的问题又与开发工作有着密切的关系。软件的管理工作则渗透到软件生存期的每个环节。所有这些都要求提供统一的行为规范和衡量准则, 使得各种工作能有章可循。
4.4 软件过程评估与改进
软件过程是软件生存期中的一系列相关的过程, 又称为软件生存期过程。过程是活动的集合, 活动是任务的集合。任务是将输入变换为输出的操作。活动的执行可以是顺序的、重复的、并行的、嵌套的。软件过程的考虑主要针对软件生产和管理。为了得到满足要求的软件产品, 不但需要有好的开发方法, 还需要有好的工程支持和工程管理。就是说, 软件过程不仅要有工程观点, 还应有系统观点、管理观点、运行观点和用户观点。
软件质量保证和全面质量管理的思想是一致的, 都指出了不应该只在一个环节上, 比如测试环节来保证软件质量, 我们需要建立众多的辅助流程, 全面地去改进、控制软件流程来保证软件质量。
参考文献
[1]李康荣.Web软件质量层次分析评价方法研究[J].微计算机信息, 2010 (3) :25-26.
[2]宋志秋, 钱英军.基于CMM的软件过程方法研究[J].经济研究导刊, 2010 (1) :251-252.
[3]张旭, 王鹏, 习媛媛, 等.单元测试在软件质量保证中的应用研究[J].煤炭技术, 2010 (6) :185-186.
[4]陈周天.浅谈软件的可靠性[J].黑龙江科技信息, 2010 (10) :65-66.
[5]邢小英.基于软件Agent技术的软件质量保证研究[J].宁波工程学院学报, 2010 (2) :59-62.
[6]吴晓姝.浅谈软件开发过程中的软件质量保证[J].电大理工, 2010 (1) :48-50.
电子政务系统软件质量评价软件 篇2
本项目通过对外部质量的研究结合电子政务系统的特点构建出电子政务系统软件的质量评价模型,并引入六西格玛质量管理理论作为质量评价模型各个指标的度量标准。给予各个评价指标适当的权重,结合指标数据和相应的权重进行计算,最终得出电子政务系统的评价分数。
关键词:电子政务;六西格玛;质量评价模型;外部质量
中圖分类号:TP393.08
本课题依据中国国家标准化管理委员会发布的软件工程产品质量标准对电子政务系统软件的外部质量进行分析、评价和处理,外部质量是基于外部视角的软件产品特性的总体,即当软件执行时,典型地是在模拟环境中用模拟数据测试时,使用外部度量所测量和评价的质量。通过对外部质量的研究结合电子政务系统的特点就可以构建出电子政务系统软件的质量评价模型,采用基于质量评价模型的电子政务系统软件的测试数据作为输入数据,并引入六西格玛质量管理理论作为质量评价模型各个指标的度量标准,量化各个指标。参考电子政务标准化指南和电子政务系统总体设计要求,给予各个评价指标适当的权重,结合指标数据和相应的权重进行计算,就可以得出电子政务系统的评价分数和等级。
1 需求分析
1.1 系统业务功能
本系统分为系统事件流程,客户事件流程和管理员事件流程三个功能集合。系统事件流程分为系统登陆、用户个人信息修改、系统退出、客户注册四个功能。客户事件流程分为系统信息提交、评价信息提交、系统成绩计算、评价成绩查询四个功能。管理员事件流程分为客户管理、评价系统管理、评价项目管理三个功能。
1.2 主体模型分析
1.2.1 外部质量指标。本质量评价模型主要通过对电子政务系统的外部质量的考察而设立指标。外部质量指标是从用户使用角度去总结软件产品特性,并加以分类和细化,制定相关的考核等级和标准。
1.2.2 权重分析法。不同外部质量指标对于评价体系的意义是不同的,指标的权重可以在决策中相对重要程度综合度量在主观评价和客观反映。
1.2.3 六西格玛质量管理理论。西格玛在统计学中用来表示标准偏差,用"σ"度量质量特性总体上对目标值的偏离程度。六西格玛流程能力(短期)可解释为每百万个机会中有3.4个出错的机会,即合格率是99.99966%。
2 系统设计
2.1 总体设计
2.1.1 模型指标设计。(1)功能性。包括准确性,适用性,互操作性,安全保密性,指在指定条件下使用时,电子政务系统提供满足明确和隐含要求的功能的能力;(2)可靠性。包括容错性,成熟性,易恢复性,指在指定条件下使用时,电子政务系统维持规定的性能级别的能力;(3)易用性。包括易操作性,易理解性,易学性,指在指定条件下使用时,电子政务系统被理解、学习、使用和吸引用户的能力;(4)维护性。包括易分析性,易改变性,稳定性,易测试性,指电子政务系统可被修改的能力。修改可能包括纠正、改进或软件对环境、需求和功能规格说明变化的适应;(5)可移植性。包括适应性,共存性,易替换性,指电子政务系统从一种环境迁移到另外一种环境的能力。
2.1.2 成绩计算方法。第一步,对每个指标的度量值采用六西格玛质量管理度量理论进行评分,
具体实现方法如下:
√ 当Xi=1时,Pi=100,说明该评价度量指标完全合格;
√当0.9999966≤Xi<1时,Pi=90,说明该评价度量指标达到六西格玛质量标准。
√当0.9999767≤Xi<0.9999966时,Pi=80,说明该评价度量指标达到五西格玛质量标准。
√当0.999379≤Xi<0.9999767时,Pi=70,说明该评价度量指标达到四西格玛质量标准。
√当0.9933193≤Xi<0.999379时,Pi=60,说明该评价度量指标达到三西格玛质量标准。
√当0≤Xi<0.9933193时,Pi=0,说明该评价度量指标达不到最低标准,不合格。
其中,Xi为第i项评价度量指标的度量值,Pi为第i项评价度量指标经过六西格玛质量管理度量理论处理后的值。
第二步,采用综合评分分析法计算出经质量评价模型度量后的系统总得分,
公式为I=∑PiWi(1≤i≤n)
其中,Pi为第i项评价度量指标经过六西格玛质量管理度量理论处理后的值,Wi为第i项评价度量指标的权重,I为该系统的总得分。
第三步,算出该系统的总权重和,公式为II=∑Wi(1≤i≤n)
其中,Wi为第i项评价度量指标的权重,II为该评价模型的总权重和。
第四步,用系统总得分除以总权重和,就可以得出该系统的百分制得分。公式为S=I/II
其中,I为该系统的总得分,II为该评价模型的总权重和,S为该系统的百分制得分。
4 总结和展望
电子政务系统质量评价软件的实现重点是质量评价模型的构建。本系统的质量评价模型主要通过对电子政务系统的外部质量的考察而设立指标,从功能性、可靠性、易用性、维护性和可移植性五个方面进行考察。每个方面都设置一系列度量指标,从不同角度考察电子政务系统在该方面的综合表现。度量指标由于评价软件的特性不同,其重要性是不一样的。我们参考电子政务标准化指南和电子政务系统总体设计要求,根据电子政务系统的特点设计出不同指标的权重,设计出真正考察电子政务系统质量的评价模型。
度量指标是评价的工具,是反映评价对象属性的指示标志;指标体系,则是根据评价目标和评价内容的要求,构建的一组相关指标,据以搜集评估对象的有关信息资料,两者缺一不可。基于电子政务系统的软件特性,我们可以把电子政务系统软件的测试数据作为度量的对象。对应电子政务系统质量评价模型中的各个指标,收集相关的测试数据作为质量评价软件的输入数据,通过度量标准定量得出该评价指标的优劣。本质量评价模型采用六西格玛质量管理理论作为指标的度量标准,提高了电子政务系统质量评价系统的科学性、先进性。
本软件的初步开发工作已基本完成,后续优化阶段已经在准备当中。提高软件的访问性能,优化质量评价模型,提高系统的安全性和可靠性等问题将在下阶段的开发过程中解决。通过对本软件特性和功能的认识,我们相信本电子政务系统质量评价软件一定会为我国电子政务事业做出应有的贡献。
参考文献:
[1]GB/T 16260.1-2006/ISO/IEC9126-1.Software engineering-Product:Quality model[S],2006.
[2]GB/T 16260.2-2006/ISO/IEC9126-2.Software engineering-Product:External metrics[S],2006.
[3]GB/T 16260.3-2006/ISO/IEC9126-3.Software engineering-Product:Interior metrics[S],2006.
[4]GB/T 16260.4-2006/ISO/IEC9126-4.Software engineering-Product:Quality metrics[S],2006.
[5]GB/T 21064-2007.System general design requirements for electronic government[S],2006.
[6]杨安.电子政务规则与案例解析[M].太原:山西人民出版社,2005.
作者简介:王梦雷(1985.12-),男,天津人,助理工程师,本科,研究方向:系统架构设计。
软件项目经理岗位职责 篇3
2、负责项目的技术框架设计和技术方案确定,协调处理项目相关的技术难点问题;
3、负责设计、细化和实施项目开发计划,按时按质完成预定的目标;
4、成功带领项目组成员,完成相关软件的设计、开发、测试工作;
5、根据开发日程,合理安排人员的进度,协调各种资源保证项目的顺利推进;
6、随时把握项目中存在的风险,制定对策。
软件质量岗位职责 篇4
0前言
计算机软件在运行过程中难免会出现一些故障, 有一些软件故障是由于软件本身质量问题而导致的, 提高软件开发质量也是减少软件故障的一个较为有效的方法。对于软件系统建立一个比较通用的质量评价模型已成为一个研究热点, 基于此提出面向领域的一种软件质量评价模型构建方法, 对于提高软件质量, 评价软件系统具有积极的作用。
1 软件故障分析
1.1 产生软件故障的原因
计算机软件系统运行所需环境各不相同, 如果用户的计算机设备及软件配置不能达到软件需要, 就容易发生功能性故障。结合软件维护实际情况分析, 软件故障产生原因主要有下列几个:一是内核文件丢失或系统配置出现错误;二是程序受计算机病毒破坏而不能正常运行;三是设置CMOS参数不正确;四是内存管理中存在一些冲突;五是计算机软硬件不兼容;六是由用户操作不当造成的。
1.2 软件故障分析方法
综合分析产生上述软件故障的原因, 可将软件运行环境分为三个层次接口, 与此相对应也可将故障分为用户接口、硬件接口、软件接口三类接口故障。当计算机发生故障时可采取观察法、对比法、更换法等判断故障是由于硬件还是软件引起的, 并确定故障源。排除软件故障过程中也要考虑软件运行环境是否满足要求, 依次分析用户接口、硬件接口、软件接口大都可确定故障原因并进行解决。对软件故障重复性进行验证, 注意软件故障发生的操作顺序及状态。软件使用过程中要定期进行备份, 避免软件发生故障时损失重要数据。
2 软件质量评价模型
2.1 领域质量评价模型
领域软件质量评价模型是由抽取标准模型中符合目标领域的特性项与抽象目标领域系统的领域特征项相结合而形成的。该模型基于标准模型进行剪裁与扩展, 仍具有属性、特性、子特性三层结构。在对目标领域系统进行评价过程中, 要将领域通用模型实例化才能转化为目标领域质量评价模型。
由于领域软件需求一般分为可选和必备两种, 因此在该模型中待评价的每层元素也同样分为可选和必备。领域质量评价通用模型的所有项都是可选, 对于目标领域质量评价模型具体到实例化时, 要对各项关系性质进行确定。该模型建模步骤如下:一是将标准模型中的特性项抽取出来, 结合目标领域特点, 对标准模型中符合目标领域软件的度量、特性及子特性项抽取出来;二是根据目标领域需求构建框架, 输入软件及领域知识, 软件目标领域实例及有关文档由领域专家进行分析, 以确定必备与可选需求, 可与上步骤同时进行将领域需求框架进行输出;三是特征抽象, 基于领域专家分析领域需求框架, 辅助评测专家对领域特征进行抽象;四是特征映射, 抽取特性、子特性、属性项及领域特征要向通用模型进行映射, 至此具有领域功能性、可靠性、易用性、领域效率、领域维护性、领域可移植性的目标领域软件质量评价模型构建完成。
2.2 质量评价
领域质量评价模型要进行有效性验证, 结合软件根据评价需求、规定评价、设计评价、执行评价等步骤对待评软件系统实施评价。评价需求确立时, 要结合评价参照的质量评价模型进行确定。采用专家评定与三角模糊数层次分析法对各特征值进行赋权, 对同层次对象要由多个领域专家进行两两之间的比较, 采用三角模糊数形式对相对重要程度进行表示, 多个比较矩阵可取其平均值作为被比较对象建立模糊比较矩阵。模糊数对应的截集矩阵要通过隶属函数进行求解, 其中各元素可作为模糊数的置信水平确定的一个置信区间, 并对乐观水平进行设定后转化为判断矩阵。然后对判断矩阵最大特征值及对应特征向量进行求解, 以判断验证矩阵是否一致。如果存在不一致情况, 要对判断矩阵进行调整, 否则可将特性向量向权重向量进行归一。
3 结语
综上, 本文提出的面向领域质量评价的一个通用模型, 提出的评价方法需要在实际应用中不断进行完善。该模型可用于对软件质量评价的一个有效手段, 基于该模型对常用软件系统进行客观评价, 评价结果符合应用实际, 说明此模型可作为软件系统的评价基准, 使用面向领域的质量模型对目标领域软件质量进行评价具有可行性, 可以使评价公正客观且准确, 对于提高软件开发质量, 促进信息产业发展都具有十分重要的意义。
参考文献
[1]雷祥, 张少华, 任凌云, 王彦理.D-P算法的改进及其在飞行轨迹回放中的应用[J].软件, 2012, 33 (9) :149-150
[2]吴小帆.CIN-SCF系统可视化信令跟踪工具的设计与实现[J].软件, 2013, 34 (8) :78-81
[3]Kwong C K, Bai H.A Fuzzy AHP approach to the determination of importance weights of customer requirements in quality function deployment[J], Journal of intelligent manufacturing, 2010.5
关于软件质量提高的探讨 篇5
关键词:软件质量;评价;标准;提高
中图分类号:TP311.5
1 软件质量的评价标准
软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。影响软件质量的主要因素,可划分功能性、可靠性、易用性和安全性。
1.1 功能性。是与一组功能及其指定的性质有关的一组属性,这里的功能是指满足明确或隐含的要求的那些功能。性能不仅仅是指软件的运行速度而已,通常意义上是指软件的时间-空间效率。性能优化的关键工作是找出限制性能的因素可以通过优化数据结构、算法和代码来提高软件的性能。是与一组规定或潜在用户为使用软件所需做的努力,和对这样的使用所做的评价有关的一组属性我们要做的是从量化的角度改善软件工程,最终改善软件质量。
1.2 可靠性。是指在特定的时间和条件下,该种软件能够平稳维持其性能、能力有关的一组属性。是指在一定的环境下,在给定的时间内,系统不发生故障的概率。也是在异常情况下,软件能够正常运行的能力。有些开发者往往不能分辨出异常情况,以至于导致可靠性降低。对于软件来说,可靠性包括容错能力以及出现问题之后的自我恢复能力就,如何提高软件的可靠性是开发者的义务。
1.3 简便易用性。是指用户使用软件的容易程度。来保证“界面友好”、“方便易用”。易用性表示该软件的所有工作成果在用户使用过程中易读、易理解,这种情况下,在软件投入使用之后可以提高团队开发效率,降低维护代价。
1.4 安全性。安全性是指信息安全,是指改软件产品在互联网信息大融合的情况下防止系统被非法入侵的能力。开发商和客户愿意为提高安全性而投入的资金是有限的,现代软件产品有很多都采用“增量开发模式”,不断推出新版本,以此来获取增值利润。但在追求利益的同时一定要保证可扩展性,可扩展性是系统设计阶段重点考虑的质量属性之一。
2 关于提高软件质量的注意事项
2.1 软件的性能,软件研发在进行需求调研时,不但应该更多的获取功能或者业务的要求,而且对于客户在软件系统响应或者并发等方面的要求,可以据此定义出软件系统的性能方面的要求.这些要求在实现过程中应该具体的被表现在开发,测试等文档中.而且针对此类性能需求的深入分析。
2.2 软件系统维护,扩充方面的需求.在进行系统功能调研和分析时,要对客户业务的规模,以及客户的发展等各方面情况有更清楚了解.可以根据这些信息更好的进行软件功能点划分,硬件设备选型等工作.軟件系统如何能更好的实施也是软件质量非常重要的一个环节。
2.3 非功能性的需求很多时候需要考虑硬件以及网络方面的成本。针对这些问题需要与客户进行良好的沟通,设定合理的非功能性目标,在成本与质量方面要有良好的平衡。
2.4 提高软件质量是整个研发团队的任务,每个小组都应该为这个目标做更多的工作.但现实的软件研发过程中往往简单的将软件质量问题归咎于软件测试或质量保证部门.软件测试不可能发现所有的软件缺陷,要想提高软件的质量,那么整个团队要付出更多的努力.研发过程中越早进行质量的控制,软件质量就会越好.整个团队强烈的软件质量意识,是保证软件软件质量的关键。
3 保证软件质量的几点措施
如何保证软件的质量,从一个企业的长远发展来说,首先应当从流程抓起,不断规范和完善软件产品的开发过程。这是从根本上解决质量问题,提高工作效率的一个关键手段。
3.1 质量改进需要花费成本,因此改进的途径需要视不同公司的规模等多方面综合进行考虑。满足业务需求,提高用户体验满意度,没有了不切实际的需求和质量要求,那么团队确保质量的能力也就提高了,质量标准的定义还要考虑时间、资源、预算等因素。中型以上的较大的软件公司可以实施CMM体系。
3.2 提高需求分析和设计方面的技术,加强文档化工作。一个高的质量要求需求规格说明书足够详细,以便产品可以根据这些规格说明书进行定量的分析,对于一个企业要想获得长期的发展,必须加强文档化工作;加强编程规范工作;进行适当的测试工作,建议进行单元测试和系统测试;实施配置管理工作,加强版本控制;开展走读、评审和检视活动,尤其要加强代码走读,建议进行每日交叉走读活动;进行简单的度量分析获得。
3.3 软件产品的开发同其它产品的生产有着共同特性,即需要按一定的过程来进行生产。对于软件开发来说,要保证软件的质量,需要掌握多方面的技术,包括分析技术、编码技术、和测试技术等,流水线生产方式被证明是一种高效且能够比较稳定地保证产品质量的一种方式。不同的人员被安排在流程的不同位置,最终为着一个目标共同努力,极大的提高工作效率。
3.4 软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中,这就形成了软件工程过程,简单的说就是开发流程。流程和成功不是等价的,软件流程从策划到实施的思维来定义开发过程,它根据不同的产品特点和以往的成功经验来确定流程。按照流程进行开发可以使得我们减少不必要的错误和隐患,有效的提高产品质量。
3.5 软件质量预测是发现那些模块容易出错,提高软件质量。传统的手工测试很难覆盖软件的全部功能点,手工测试的效率低,并且由于人工操作可变性较大容易造成对测试工作的懈怠,使测试质量降低,软件测试的目的是要发现软件中的错误。通过自动化测试工具的合理使用,可以提高测试的可重复性,缩短测试周期,将核心功能点重点测试,以此来杜绝关键缺陷,降低出现问题后的影响,以免影响到软件整体质量。
3.6 软件的使用者是用户,因此应从用户的角度来不断提高软件质量,软件应满足用户的业务需求,尽可能的与客户沟通获取需求,除了完成需求调研的任务外,同客户有深入的沟通和良好的客户关系也是一个及其有益的收获。既不将质量目标定得太高,根据时间,资源和预算客观情况定义合适的软件质量标准,让用户满意。
3.7 确保从需求获取开始,项目就朝正确的方向迈进,减少总体工作量。尽量在软件开发生命周期的前段时间减少软件缺陷,避免在后期来消灭缺陷,那样耗费的时间和精力更多。让每个人都知道质量的重要性,从心理上更注重代码质量,就会更用心写出高质量的软件。
3.8 对于软件开发来说,要保证软件的质量,需要掌握多方面的技术,包括分析技术、设计技术、编码技术和测试技术等等。参照简明清晰的设计编写代码,容易测试和返工,也更容易诊断和修复缺陷。
优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程,即优化执行步骤。
3.9 根据业务需求调整团队和个人的工作目标,并纳入质量考核体系,实施严格的奖惩措施,刺激开发人员的工作效率和工作质量。根据团队成员的执行表现给予适当奖励。
4 结束语
提高软件质量是一项团队运动,整个团队强烈的软件质量意识,是保证软件软件质量的关键,软件质量必须贯穿整个软件的开发生,通过软件初期的质量保证来减少返工次数,不断提高用户满意度,其中作为管理人员要对软件质量进行综合考评,并通过各种手段进行激励团队提高质量,做到软件质量和用户满意度的提高。
参考文献:
[1]刘建辉.提高软件质量的方法研究[D].中国地质大学,2005.
[2]梅宏,王千祥,张路.软件分析技术进展[J].计算机学报,2009(32).
[3]石柱,何新贵.模糊软件质量综合评价[J].系统工程与电子技术,2002(24).
软件工程师岗位职责 篇6
2.负责培训及培养软件开发团队的人员,提升开发技术水平;
3.负责制定软件开发项目管理的制度;
4.根据需要不断修改完善软件;完成程序测试;负责公司各下属单位软件开发的指导、技术支持。负责建立健全软件开发、应用、管理的制度;
5.跟踪落实各项目公司信息化系统应用情况,定期梳理;制定系统运行考核指标;针对系统应用情况提出改进完善方案;定期向业务部门了解需求变更情况和新增信息化需求;
浅论软件开发的质量控制 篇7
[关键词]软件开发;软件工程;质量控制
[中图分类号]TP311.5
[文献标识码]A
[文章编号]1672-5158(2013)05-0168-01
一、软件开发过程的问题分析
(1)不能明确分析软件的需求。软件的需求是决定软件质量的一个非常关键的因素,如果不能够准确明了的分析软件需求,就达不到软件应有的效果,从而不能真正满足客户的要求。然而软件的需求不是显而易见的,它需要软件开发人员和客户或者业务人员之间进行充分有效地沟通和交流,使得在软件开发一开始就能够将需求提得既明确又充分,这样才能为以后的工作打好基础,避免在一开始就偏离了软件开发的方向。在设计开发的过程中也要不断与客户进行沟通和交流,及时按照客户的意见调整软件,才能提高软件开发的质量。
(2)软件开发工作不规范。由于软件质量许多指标不能量化,因此,软件开发的质量好坏也没有办法直接考核软件开发人员的责任,这样就致使软件开发人员不会很重视软件开发的质量,往往更关心项目开发的成本和进度。此外,软件开发人员没有制定软件开发计划或者并不能按照软件开发的计划进行工作,为了赶进度经常跨阶段进行开发工作,这样就没法保证软件开发过程的科学性和系统性,软件开发的质量也不能得到保证。软件开发管理人员和技术人员也会影响软件开发的质量。软件开发工作需要他们之间进行频繁的沟通和交流,倘若不能及时沟通,对开发过程中出现的不同认识和误解等等问题不能及时消除,就势必会影响到软件产品的质量。此外,软件开发人员在开发过程中一旦出现流动,就会给软件开发工作带来很大的影响,也不利于提高软件产品的质量。
二、提高软件开发质量方法和对策
1 软件产品质量控制方法。
(1)软件工程方法。软件工程的基本方法就是把软件开发过程划分为若干个阶段,在每个阶段开发过程中都设置不同的目标、成本、时间等验收标准,在前一阶段工作通过验收后才能开始下一阶段的工作,这样就会达到提高软件开发的质量的目标。软件工程将开发过程分为软件生产方法、需求分析、软件设计、软件生产工具、测试、验证与确认、评审和管理等8个阶段,每个阶段都以软件质量控制为核心,规范每个操作流程,从而提高软件开发产品的质量。
(2)ISO9000-3标准。ISO9000系列标准原本并不能直接用于管理软件制作,而是为制造硬件产品而制定的标准。后推行的ISO9000-3标准为使软件产品达到质量要求,要求软件开发机构建立质量保证体系,明确供需双方的职责,针对所有可能影响软件质量的各个因素都要采取有力措施,作出如何加强管理和控制的对策和措施。ISO9000-3标准叙述了需方和供方应如何进行有组织的质量保证活动,规定了从双方签订开发合同到设计、实现以至维护整个软件生存期中应当实施的质量保证活动,但并没有规定具体的质量管理和质量检验方法和步骤。
(3)cMM认证。CMM是一种专门针对软件产品开发及服务的高效管理方法,强调软件开发过程的不断改进和提高,在软件企业中引入CMM,有助于解决软件开发过程中质量控制方面出现的问题。CMM不仅对软件企业工程能力进行评估,更着重于软件开发过程的管理,强调“对软件开发过程进行持续的改进”。CMM通过优化企业开发流程,改善现有的规范、团队配合工作方法,来弥补软件企业对某个项目经理或开发工程师的单纯依赖。软件能力成熟度模型重点是从组织管理方面研究评估软件生产过程,从而提高软件质量。
2 软件开发质量控制对策。
(1)合理规划并严格按照计划执行。在进行软件开发之前首先要制定一个提高软件开发质量的保证计划,在开发过程中严格按照计划执行,不急于抢进度,保证软件开发的质量。建立文档记录需要跟踪的工作以及保证软件开发质量所需要的信息。
(2)坚持软件评审制度。坚持软件评审是保证软件质量的重要方法,软件开发过程按阶段可大致分为软件需求分析、软件设计、编码和单元测试、软件部件测试、软件验收六个阶段。软件评审工作要贯穿于软件开发的整个过程中,在软件开发的各个阶段都要进行评审,当前软件开发阶段的工作成果达到计划要求以后才能开始下阶段的工作。评审工作可以以会议的形式组织开展,会议要各方面人员都要参加,包括客户、软件管理人员以及软件开发人员等等,通过会议进行沟通交流,最终给出评审结果。
(3)采用先进的软件设计技术和方法。在软件开发过程中应尽量采用先进的设计技术和方法,如面向对象和基于构件的方法,来提高软件设计产品的质量。面向对象的方法优点是能够提高软件的重复利用性,将错误和缺憾最小化,还有利于用户的参与,能够很好的提高软件产品的质量。基于构件的开发方法又称为“即插即用编程”方法,构件可以向软件供应商购买,也可以自行开发,而且可以重复多次使用,然后将编制好的构件插入到设计好的框架中去,从而形成一个大型的软件。如果某个构件不符合开发的要求,可以对某个构件进行修改,不会对其他构件造成影响,也不会影响到整个系统功能。
(4)软件质量控制的关键——软件测试。在软件开发过程中,软件测试也是软件质量控制的关键,软件测试主要包括单元测试、集成测试、确认测试和系统测试。在开发的每个阶段都要通过测试,如果测试结果与预期结果不一致,就要查找出软件中存在的问题,针对问题提出解决方案,不断改进软件质量。通过软件测试不仅可以寻找出软件中存在的与软件客户需求不一致的错误和缺陷,还可以节省大量的时间和人力,确保软件开发的质量。开始测试之前要制定好测试计划,确定好测试的范围方法等等。在测试过程中要做好记录,详细记录每个测试过程中的数据,而且每个阶段测试的结果都要进行存档,如果测试过程中出现错误,就要编写错误问题的报告,经过调试解决所发现的问题以后才能进行下阶段工作。
(5)注重文档管理。目前很多软件开发商都忽视了软件开发过程中的文档管理,其实文档管理在软件开发过程中起着非常重要的作用,在软件开发的过程中建立并保存文档,有利于软件的使用和维护,有益于软件质量的提高。文档管理要贯穿于整个软件开发的全过程,即软件在每阶段的开发、测试、评估都要保存相关的文档,这样有利于软件的开发和维护,出现了错误有章可循,有助于软件开发质量控制。
(6)客户要参与到软件开发中去。软件客户要参与到软件开发的全过程中去,在开发之初对软件的需求不是很明确的情况下,要加强与软件开发人员的沟通和交流,不断了解自身更深层次的需求。软件开发需要多方参与,尤其是软件客户方面的人,在需求调查和分析阶段,软件客户要将自己的需求和软件开发人员进行有效地沟通,使得软件开发人员能够最大限度的了解客户需求,才能按照需求目标开发出令客户满意的软件。在软件测试和评审阶段,客户应按照自己的需求对设计开发的软件进行检测和评审,提出自己的意见和建议,以便在得出结论以后能够尽快及时的得到修正。软件开发人员对于客户提出的意见和建议要按照要求进行修改和完善,及早与用户进行沟通,避免影响验收。
参考文献
[1]张天宇.《中小型软件开发质量控制研究》.《微电子学与计算机》.2004
软件质量度量分析与研究 篇8
关键词:软件质量,度量,质量度量模型,度量验证
在过去几十年里,因为软件的质量问题而导致整个系统发生失效的事例屡见不鲜,进而给人类生命安全和环境造成了巨大的损失。20世纪80年代,美国有两个系统,耗资5600万美元的Univac联合航空订票系统和耗资2.17亿美元的高级后勤系统都因在交付使用后发现不满足要求而被迫进行重新研制[1];而在1996年6月,在阿丽亚娜5号火箭首次发射后不到一分钟的时间内,就因为软件故障问题致使火箭发生了爆炸,导致了巨大的经济损失和相应计划的延迟[2]。因此软件的质量问题已引起了人们的极度重视,软件质量的度量问题自然也得到重视。
由于计算机技术、数据融合技术、网络技术和通信技术的飞速发展,人们对软件性能及功能提出的要求也越来越高,度量软件质量已成为一个迫切需要解决的问题。如何通过选择合适的软件质量指标体系、确定软件质量的量化过程和方法来进行客观性地度量,对于评价软件的质量是关键的一步,进而对于减少软件失效的发生和提升软件的总体质量也是具有极其重要的意义。
1 对软件质量模型的认识
1.1 软件质量及定义
至今为止,软件质量还没有一个统一的、惟一的定义,不同的组织或应用可能会有不同的定义。ANSI/IEEE Std 729—1983定义软件质量为:与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体[3];M.J.Fisher给出的定义为:表征计算机软件卓越程度的所有属性的集合。由此可知,软件质量的优秀程度与反映软件各项功能、性能需求的特性及其组合紧密相关,如果针对软件本身设计出来的质量特性能够满足各种要求和反映软件质量需求,则说明软件产品的质量等级比较高。结合各种定义,软件质量反映了以下三个方面的问题:1)显式的软件需求,包括用户方、交办方等提出来关于软件的功能需求、性能需求等,这是软件质量度量最基础的需求;2)隐式的需求,在软件生命周期中其中有一部分需求并没有明确提出来,如可维护性等;3)软件的整个开发过程还必须按照一定的方法,规范来进行,缺少这些,就无法指导软件开发人员的各种开发活动,开发秩序会变得杂乱无章,软件质量也就得不到一定的保证。
综上以上的定义和最新的研究可以将软件质量定义为:软件所具有的能够满足功能和性能需求、遵循一定的开发准则和规范以及符合隐含的一些规定需求的本质。
1.2 软件质量度量模型
软件度量工作自1958年Rubey和Hurtwick首次提出软件度量学概念[4]至今,大体经历了三个阶段。1976年,Boehm等人从可移植性、可使用性、可维护性三个方面来定量的评价软件质量为第一阶段;第二阶段以1978年Mc Ca1l等人从“产品运行、产品修正和产品转移”提出的质量度量模型即“质量要素———评价准则———度量”为标志。但是实践证明通过该模型不同缺陷的反馈信息可能相同,以致指标的制定及其定量的结果难以评价。随后,国际标准化组织(ISO)[5]于1985年和1993年先后提出了多项关于软件质量度量技术的工作报告,其提出的软件质量度量模型将软件度量工作带入了第3个发展阶段。
通过对这三个模型的深入研究发现,这三个模型都着重分析了软件质量属性的影响因素,这些模型研究的对象主要是软件产品,即在软件质量属性和软件设计、编程的特性之间建立关联映射[6]。这些模型可以帮助加深对软件特性的研究,有利于分析和建立特定软件系统的质量特性及其特性组合。但是这些质量度量模型都存在一定的局限性,每个模型都是针对软件本身提出来的,通用性比较强,在应用到具体的软件系统评估中,并不能很好地反映软件所具有的特殊性。因此,如今很多模型都是根据自己的需求来开发建立的,虽然软件自身的性质给模型的确定带来了一定的困难,但是总的提升还是有的。文献[7]就指出了一种基于全局和局部质量标准的框架,降低了模型建立的难度;文献[8]中指出了从领域报告问题、用户关键情况和用户满意度等级三个方面来寻找度量元,利用数据统计分析的方法加强了软件质量的管理。这些方法的开发和应用都为软件质量特性和模型的设计提供了很好的引用和借鉴。
2 软件质量的度量研究
2.1 软件质量度量过程
软件的度量过程主要可以分为五个步骤进行:1)确定软件的质量度量需求。这一步是软件质量度量最为前提和基础的一步,主要活动包括设计可能的质量因素集合,优化并确定这一因素集合和建立软件质量模型。2)确定软件质量度量元。这是软件度量过程较为关键的一步,度量元选取的好坏直接影响着质量评估的结果。首先在基于软件质量度量框架的基础之上,将质量特性分解成度量元;继而执行度量元的成本效益分析,根据其结果调整优化已选度量元集合。3)执行软件质量度量。包括定义度量数据收集过程并且收集数据、根据已有数据计算度量值等环节。需要注意的是,采集的数据应该基于正确定义的度量和模型,从而保证数据的正确性、准确性和精度;因此,在收集数据之前,应当设定数据采集的目标,并且定义有意义的问题[9]。4)分析软件质量度量结果。通过分析比较收集的度量数据与目标值,发现两者之间的区别。确定那些不可接受的度量值,详细分析那些数值偏离关键值的度量元并依据分析结果重新设计软件质量度量。5)软件质量度量的验证。验证的目的就是为了证明通过软件产品和过程度量可以预测具体的软件质量因素值。验证的过程中,在运用相关的验证方法和标准的前提下,必须确定软件质量因素样本和度量样本,然后执行对度量的统计分析,检验度量的作用是否实现。整个具体过程如图1所示。
2.2 软件度量的验证与预测
软件度量的验证是软件度量领域另一个非常重要的话题,因为实际上软件度量的认同取决于软件度量是否能作为软件质量特性的预报器,如果能,度量验证的目的也就达到了[10]。
从软件产品度量验证实质来分析,具体反映了以下三个问题:1)软件产品度量必须量度本应该量度的内容,例如耦合度量量度耦合性等。2)软件产品度量和一些重要的外部度量存在关系,例如可维护性和可靠性的量度。3)软件产品度量能促进现有的度量水平的提升,这种提升意味着将会产生降低度量收集的复杂性以及提高预测错误的可能性等等优势。
在进行软件度量验证时,我们必须注意软件度量的外部验证和内部验证的区别,内部验证考虑同态,也就是说,做用户想要的度量。软件度量的外部验证考虑量度是否和软件品质属性(外部变量)有关系。文献[11]和文献[12]应用算法验证进行度量的外部验证,而Zuse等人采用的是所谓原子修正进行度量的外部验证,原子修正可以看作对顺利量表的必要条例。软件度量广泛使用的外部验证概念相对于外部特征是相互关系的考虑。文献[13]也从内部验证和外部验证的角度出发,提出了利用理论验证和经验验证相结合的方式来对已存在的五个有关面向对象设计的质量因素的度量集进行验证。软件组织可以利用这种方法尽早确定高风险的软件模块、构建设计和编程计划与方针以及进行系统级的预测。具体方法如图2所示。
最近的研究表明,验证软件产品度量的方法的质量越来越受到人们的关注。主要基于两个原因:1)应用于软件工程度量验证的一些一般实践在科学性方面令人难以接受;2)对于有效的工程管理和可靠合理的经验研究,有效的测试和验证是必须的。因此,必须对那些来出自于研究室的度量的有效性进行验证,才可能达到准确性和科学性。更需注意的重点是软件度量验证不只是一次的事,它是一个需要重复验证的连续过程。
2.3 软件质量度量方法与进展
2.3.1 面向结构度量方法
较早出现的度量是建立在结构化程序设计和模块化思想基础上的,分析的对象包括程序的控制流图,实现中的操作复杂性,方法间的传递耦合和流程耦合等。其中影响比较大的有McCabe提出的循环计数复杂度度量,直到今天历经改进,仍然被实践者所采纳。McCabe 1976年提出了环形复杂度(cyclomatic complexity)理论,该理论以图论为基础,通过分析程序的控制流图来获得程序的复杂度,为度量程序逻辑复杂性提供了一种很好的方法。
2.3.2 面向软件复用的度量
20世纪90年代后期,软件复用的研究兴起。复用的度量主要包括可复用性度量和复用度量[14]。可复用性度量主要用来判定一个构件的可复用性和质量,复用度量主要用于判定复用对生产率、质量和开发时间的作用,它可以在不同级别上进行度量,包括构件级、产品族级、项目级和机构级。目前面向复用的度量大致可分为以下4大类:经济模型类、成熟度模型、复用比率模型以及复用潜力度量模型。
2.3.3 面向对象度量方法
软件度量进一步作的开展主要在80、90年代,尤其是在90年代,软件度量的研究获得了空前的发展。1989年,Morris研究讨论了面向对象应用程序的度量,Bieman讨论了在面向对象条件下软件重用的度量问题。1993年中国台湾学者J-Y Chen和J-F Liu提出chen&liu方法[15],从操作性、复杂性、重用性、类的属性等八个方面去度量面向对象软件。1994年Chidamber和Kemerer发表论文对面向对象度量提出了基于继承树的一套面向对象度量方法[16]被称为C&K度量方法,主要用来量度与对外部质量属性的影响有关的面向对象设计的复杂性[17]。1995年,brito等人针对面向对象属性提出的一套称之为MOOD的度量算法集[18],它从封装性、继承性、耦合性和多态性等四个方面给出了面向对象软件六个度量指标。1998年,Nesi和Querci提出了一种新的软件复杂度和大小度量方法[19]。
到了2000年,Arlene F提出一种预测点度量方法,这种方法基于对象和他们的特征,建立一种适合预测工作量和跟踪生产力的方法,核心是每类加权方法数(Weighted Methods per Class WMC)[20]。2001年,Victor和Daily提出了一种基于构件点的度量方法叫SPECTRE的方法[18],用于预测开发任务时间和模块规模。2003年,Washizaki等提出了一种可重用组件的度量方法,用于度量面向对象组件的易理解性和可重用性。同年,Hastings和Sajeev介绍了一种新的Vector Size Measure(VSM)方法,用于在软件生命周期的早期度量软件规模,软件分类,软件开发结果等[21]。2005年Gyimothy等提出一种基于经验的面向对象度量方法,该方法能有效地实现对源码的bug预测度量。同年,Del Bianco等采用经验断言的方法,扩展了功能点度量方法,并将其应用到面向对象度量中。
3 展望
毫无疑问,软件度量是提高软件品质的一个重要方法。只有通过软件度量,才能确定软件产品所具有的属性组合与所希望的符合程度。Dieter Rombach,曾在巴黎说到过(现在他在美国软件工程实验室(SEL)工作):我们现在不再是问我们是否应该度量,而是怎么样度量。尽管过去软件度量领域做了许多的研究,但还有许多问题未解决。
首先,目前还没有成熟的度量方法,大多度量方法适用性不强,且有些还存在着度量过程客观性差,度量结果不准确的问题;
其次,国际上还没有统一的软件度量标准,很多标准针对的范围比较小,并不能满足软件质量度量的整体要求。
将来,理论开发(对现实的假定)变得越来越重要,相关和归约分析需要考虑讨论度量比例,外部变量对软件度量验证确认是未来需要研究的课题。利用测量理论的公理有助于更好理解软件品质和成本估计后潜在的内容;同时,针对现有问题进行深入的研究和分析,探求符合需要的理论方法和开发工具将对未来度量领域的发展起到重要的促进作用。
4 结束语
软件实施顾问的岗位职责描述 篇9
1、负责制定软件项目客户的实施计划,保证项目能按计划顺利完成;
2、对新客户的业务需求进行调研分析、并制定业务解决方案;
3、负责系统上线前的安装配置、测试和用户培训;
4、给客户提供合理化建议,优化使用效果,协调与客户的关系;
5、跟踪客户需求,为客户提供相应解决方案,对需求进行反馈,完善产品功能。
任职资格:
1、大专以上学历,计算机、信息管理相关专业;有相关软件实施经验者优先。
2、熟悉SQL Server、MySQL等数据库;
如何提高软件开发管理质量 篇10
进入21世纪以来, 随着信息技术的迅猛发展和应用的广泛普及, 计算机软件以及一些嵌入式软件的规模也在逐渐壮大, 软件管理显得愈发重要, 需要逐步规范。如果软件管理跟不上, 将很难实现技术的超越, 要想开发出优秀的软件产品, 必须加强软件开发的科学管理, 这是当前我国软件发展面临的重大问题。目前, 在软件开发管理方面我们可以借鉴软件能力成熟度模型, 研究如何高效率、高质量、低成本地开发软件产品。
2 软件能力成熟度模型
2.1 概念
软件研制能力成熟度模型由美国国防部委托软件工程研究所 (SEI) 开发, 用于评价软件研制单位的质量保证能力。该标准通过对国内外许多大公司的实践验证, 效果十分明显, 已被国际上广泛采用。该标准是一个软件产品开发的模型, 从关注整个软件研制体系的角度出发, 提供了一个软件研制过程改进的参考模型, 描述了一组有效过程的特征, 提供了一组最佳的实践, 它的主要关注点体现在生产率、性能、成本、相关方满意度等方面。软件成熟度模型的核心思想是, 为了使软件开发更加科学化、标准化、使企业能够更好的实现其商业目标, 特将软件开发看作是一个过程, 并根据这一原则对软件开发和维护进行过程的监控和研究。软件能力成熟度概念的引入, 使一个特定过程得到了更加清晰的定义、管理、测量和有效控制, 解决了路径的问题。
2.2 主要内容
软件能力成熟度模型采用分级表示法, 按照预先确定的过程域集来定义组织的改进路径, 并用成熟度等级进行表示, 该标准将组织的软件研制能力成熟度分为五个等级, 其中1级 (或ML1) 称为初始级, 2级 (或ML2) 称为已管理级, 3级 (或ML3) 称为已定义级, 4级 (或ML4) 称为已定量管理级, 5级 (或ML5) 称为优化级。图1给出了软件研制能力成熟度的五个等级。
成熟度等级描述的是一个已定义的、组织过程改进的进化过程。当组织的某个等级达到要求时, 表示组织过程的一个重要部分已经成熟, 并为它进入下一个成熟度等级做好了准备。成熟度等级根据与每组已预先定义过程域相关的专用目标和共用目标是否达到要求, 判定组织是否满足相应的成熟度等级。在五个成熟度等级中, 每一个等级是实现下一个成熟度等级的基础。
3 软件研制过程中存在的问题
在软件开发过程中, 通常存在的问题主要体现在以下方面:
(1) 项目策划不足。主要表现为, 项目组成员拿到一个软件任务时, 对于这项任务的难易程度、工作量和代码规模估计不足, 对项目开发过程中可能存在的风险识别不充分, 利益相关方的参与范围不明确, 对项目组成员需要达到的技术水平认识不到位, 工作项不够细化等, 从而导致项目的延期交付等问题比较突出, 给企业的经济利益和声誉等带来损失。在实际工作中, 我们经常碰到这样的例子, 在软件需求评审阶段, 项目经理没有将用户纳入到相关方需要参与的计划中, 从而用户没有参与需求的评审, 可能导致开发方对某些指标理解与用户的意图不一致, 从而使得开发的过程中没有完全满足用户的要求, 当用户验收发现这一问题时为时已晚。
(2) 程序文档管理不充分。程序文档是开发人员与用户重要的交流渠道, 是用户使用和维护系统的重要依据, 是项目组知识积累的过程, 也是软件工程开发的依据和项目成果的重要组成部分, 因此监督开发人员编写程序文档是项目经理或者软件经理管理项目成果的重要内容。在项目进程中, 项目组成员都没有认识到文档管理的重要性, 程序文档的整理被安排到项目终止阶段完成, 而没有与开发工作同步, 致使文档不完备, 给系统移交以及用户维护带来了许多计划外的工作量。同时, 如果文档编写不规范, 编写质量比较差, 没有体现软件开发中的必要要素, 评审把关不严, 而最初的软件开发人员离职或者离岗, 就可能给后续继任者带来开发上的困难, 导致任务工期的延长或者软件维护上的困难。有相当一部分的软件开发人员偏爱编写代码, 但是不关注整理软件文档, 即使按照任务要求编写了必要的文档, 编写质量也不高, 经常缺少或者漏掉文档中必要的元素, 这将导致其他成员根据该文档获得的资料较少, 从而不利于项目的传承。举个大家比较容易忽视的一个例子, 在设计文档中, 对于数据的定义是无符号还是有符号的, 则在使用过程中需要注意的事项是不一样的, 如果设计师设计的是有符号的, 而代码编写人员按照无符号编写, 则数据范围明显不同。
(3) 成本核算的有效性不足。对于一项大型的、长周期的软件项目, 其费用和规模也相对较大, 因此, 在软件开发过程中, 就必须重视软件开发的成本问题。目前, 很多企业对软件开发的成本缺乏管理, 对于开发一个软件实际需要的成本没有一个有效的数据进行支撑, 导致成本核算存在问题。如果一个团队开发一个项目, 总共用了半年的时间, 但这半年是大家经常加班加点完成的, 那么开发这个项目的实际的工作量就不能用半年的时间来计算, 必须将成员的这种勤勉的程度和精力计算进去, 才能得到一个比较合理的结果。如果之前项目的成本核算是不科学或者是无效的, 则当企业再接到一个软件项目时, 将很难提供一个接近实际项目的软件规模和所需要的总工作量等数据。
4 借鉴成熟度模型解决存在的问题
在软件研制能力成熟度等级1级也即初始级中, 软件开发通常都是随意的和无序的。在这个过程中, 软件能否开发成功主要依赖于开发人员的技术水平和勤奋程度, 而不依赖于项目的组织。而项目的组织或者企业的组织通常不提供支持开发的稳定环境。虽然处在这种随意、无序的环境下, 成熟度等级1的组织也能生产可用的产品, 提供可接受的服务;但是, 预算和进度等问题常常超出他们可控的范围。在成熟度等级2级即已管理级中, 组织的项目能够确保软件开发过程按照既定的方针进行策划执行, 这些项目为了产生受到控制的工作产品, 往往聘用有专业技能的人员。在成熟度等级2级, 在已定义的时间点管理者能够见到工作产品的状态和服务的交付, 工作产品受到了适当的控制, 工作产品和服务能够满足一定的标准和规范。针对上文中提到的问题, 我们可以通过学习借鉴软件研制能力成熟度模型来制定有效的方法和措施, 使得软件的管理变得更科学有效。
(1) 项目策划管理。在软件研制能力成熟度模型中, 有一专门过程描述项目策划需开展的工作和各项工作的细化程度, 并建议采用估计值的方法对工作量进行估计, 给出了估计时需考虑的各种因素, 主要有:项目的需求、项目的范围、已经确定的任务和工作产品、技术实现途径、产品的规模和复杂性等。在项目策划阶段要求项目经理或者软件经理将各种因素进行综合考虑, 根据项目实际情况采用不同的估计方法对项目的规模和工作量进行估计, 从而对计划进行细化管理, 同时要有能力识别项目开发过程中可能存在的风险, 如需求不明确或可能发生变更, 相关方提供的材料不能按时到位等, 经理人员要能给出风险发生时相应的有效应对措施, 以使风险对项目带来的影响降到最低。另外, 在项目策划阶段还要考虑项目组成员的技术水平能否胜任所开展的工作, 如果能力与工作之间存在差距, 需考虑需不需要对其进行培训、培训内容是什么、在何时开展培训等。
(2) 文档管理。软件研制能力成熟度模型要求软件的开发设计要按照标准规范开展, 软件的需求文档、设计文档以及测试文档等都给出了标准的要求, 使软件开发人员在进行相关文档的编制时有据可循, 不会漏掉必要的要素, 同时要素的编制也要按照通过审批的标准性规范进行编写, 每人都按照标准进行工作, 就不会存在人员差异带来的文档质量的差异。标准中不仅要求文档编制按照一定的标准进行编写, 同时要求在软件开发的各个阶段开展该阶段文档的编制和评审。例如, 在需求开发阶段要完成需求规格说明的编写和评审, 在设计阶段要完成设计文档的编写和评审等, 不能等到项目结题再统一补充, 这可解决文档编制不充分、不完整或者不准确带来的计划外问题。
(3) 成本核算管理。软件研制能力成熟度模型提出了测量分析的概念, 主要规定了测量分析的目标, 测量项, 分析技术, 测量数据的采集、存储、分析以及报告和客观的结果等内容。该活动能够支持客观的策划和估计, 对照已经制定的计划和目标, 跟踪项目的实际绩效, 将测量的结果纳入到组织资产库中, 从而成为以后要增加的过程中所需要的基础材料。这项活动需要项目组成员的全员参与, 项目经理或者软件经理要及时与项目组成员收集项目进展情况的信息, 项目组成员也要定时对自己的工作量进行总结和整理, 及时上报经理人员, 各方在整个项目的开发阶段, 能够及时掌握项目动态, 了解该项目不同阶段所花费的工时和工作量等。企业对每个项目测量到的信息进行收集、整理、成库, 可以很好地指导后续项目策划工作的实施。
5 结语
软件开发管理过程中的项目策划、文档管理以及对各种数据的测量分析等, 是软件开发管理的必要手段和过程, 这些过程的开展直接关系到项目能否按计划、按标准开展, 可以遵循成熟度模型提高软件开发管理质量。
摘要:在介绍软件能力成熟度模型及主要内容的基础上, 详细分析了当前我国软件开发管理中在项目策划、文档管理以及成本核算等方面存在的主要问题, 提出了遵循成熟度模型提高软件开发管理质量的方法。