软件项目产品质量管理(精选12篇)
软件项目产品质量管理 篇1
高质量的软件系统, 是信息化建设的基础与前提, 而且, 许多系统用在生死攸关的场合, 软件中一点小小的错误, 可能导致不可估量的损失。例如, 1981年, 1/67的时间偏差导致了航天飞机发射失败。1986年, 1台Therac25机器由于软件出现了问题, 导致这台机器忽略了数据校验, 致使两名医院病人死亡。这些惨痛的教训说明, 信息化建设进入各行各业, 软件的质量至关重要。在软件研发项目中认真抓好质量管理, 并加强有关软件项目质量管理的研究是摆在我们面前的重要课题。而影响软件项目质量的因素有很多, 通常有:人的因素、项目研发的各个过程、测试的局限性、质量管理的困难、质量管理未能给予足够的重视、软件人员的传统习惯、开发规范、开发工具的支持不够等。以下结合我的实际工作对如何提高软件质量谈谈具体的管理策略、思维和做法。
1. 高素质软件人才战略
影响软件项目质量的因素主要是“人、过程、技术”。首先要明确的是这三个因素中, 人是第一位的。我始终认识到软件行业中人才的重要性以及人才在软件质量的重要作用, 特别是领头人的作用。一个项目的主管、开发经理、实施经理对项目的把控水平、相互之间的沟通、协调、配合, 以及项目中其它人员之间的合作, 是项目质量保证的关键。为此要充分调动项目成员的积极性、主动性, 激发其工作热情和责任感。除了采用目标激励、信任激励、职务激励等精神激励外, 还要采取相应的物质激励手段, 人事部门应制定比较公平、公正、有效率的薪金激励体系。由于软件开发行业的特殊性, 还应十分重视人员素质提高与技术学习和交流, 积极提倡和鼓励人员参与软考和各类认证考试以及职称评审, 这样可以在公司内形成了十分良好的积极进取向上的科研与学习气氛, 有效地提高各成员业务水平。
2. 项目研发各阶段的质量确保
a、需求分析
需求分析是研发人员对系统需要做什么和怎样做的定义过程。从系统分析的经验来看, 这个过程往往是个循序渐进的过程, 一次性对系统形成完整的认识是非常困难的。只有不断地和客户领域专家进行交流确认, 方能逐步明了用户的需求。从系统研发的过程得知, 系统分析时犯下的错误, 会在接下来的阶段被成倍的放大, 越是在研发的后期, 纠正分析时犯下的错误所花费的代价越是昂贵, 也越发影响系统的工期和系统的质量。所以需求分析一定要做好、做细, 确保需求分析的准确性, 并做好需求变更风险评估与需求变更记录。
b、系统设计
优良的体系结构应当具备可扩展性和可配置性, 而好的体系结构则需要好的设计方法, 自然设计选型成为了系统设计首要的工作, 究竟是采用哪种设计方法好呢?
对于设计选型不能一概而论, 需要针对项目的结构、项目的特征和用户的需求来分析, 同样也要考虑到参与项目小组成员的素质。除设计选型, 更有一个容易被忽视的问题, 就是公共类研发。公共类研发不仅能够减少工作中的重复工作, 降低研发成本, 更重要是可以使程序结构更加科学, 软件质量提高。这需要我们在设计阶段通过对用户需求的仔细研究, 尽可能的识别出公共类, 并进行定义, 指定专人负责设计, 通知其他设计人员, 以减少重复工作, 保证软件质量。
c、实现
实现也就是代码的生产过程。这里不但包括代码的产生, 同时也包括测试用例的产生。针对上一阶段提供周详设计, 程式员开始编码并且调试程式。好的编程习惯是程序代码质量的保证。程序员在编写代码时, 要思路清晰, 认真负责, 好的程序是高内聚、低耦合, 同时也是条理分明, 结构科学的, 同时程式员调试完程式, 提交测试人员进行程式正确性检测。同时在对测试出现的问题进行修改时, 要考虑周详。曾经有一个项目, 程序员在修改问题时, 一不小心, 改错了, 不仅原来问题没解决, 反而引起更多其它问题, 造成一时不小的混乱。
d、文档管理
保存适度的文档, 使其真正为项目的质量提供保证。详细、准确的文档, 不仅可以记录软件项目开发过程中一些重要事件, 同时, 当发生人员变动时, 仍可保证软件项目按原定计划保质保量进行, 减少对人员的的依赖性。
3. 加强测试
为了提高软件质量, 要十分重视测试工作。通常情况下测试能够分为如下几种类型, 如:正确性测试、功能性测试、性能测试、安全测试和系统测试等。测试是程序进行正常运行之前的最后一道关口, 一定要把好此关, 充分、详细地做好各类测试, 以免正式运行后, 发现太多问题, 引起用户的反感, 从而引发信任危机, 阻碍项目的有序推进。
当然测试不可能发现所有潜在的问题, 一些小的功能或操作方面的问题在使用过程中一段时间会出现, 这是不可避免的, 需要向使用人员事先进行说明, 但是大的功能性问题不应该进行正式运行阶段。
加强软件质量管理的做法还有很多, 对其中的一些细节本文也不再讨论。当然, 质量管理的内容与做法也要与时俱进, 要针对不同的项目采取不同的最适合本项目的方法, 以便取得最好的效果。
摘要:本文列举了各种影响软件项目质量的因素, 详细分析了其对质量影响的程度, 着重指出在各种因素中人是第一位的, 并进一步说明质量管理的内容与做法也要与时俱进, 要针对不同的项目采取不同的最适合本项目的方法。
关键词:质量,需求,设计,测试
参考文献
[1]《IT执行力---IT项目管理实践》作者:刘慧, 陈虔等编著, 电子工业出版社出版.
[2]《IT项目管理》作者: (美) 凯西.施瓦尔贝著, 邓世忠等译, 机械工业出版社出版.
软件项目产品质量管理 篇2
1.1目的
本计划的目的在于对所开发的软件规定各种必要的质量保证措施,以保证所交付的软件能够满足项目预定需求,能够满足本项目总体组制定的且经领导小组评审批准的该软件系统需求规格说明书中规定的各项具体需求。
软件开发项目组在开发软件系统所属的各个子系统(其中包括为本项目研发或选用的各种支持软件、组件)时,都应该执行本计划中的有关规定,但可根据各自的情况对本计划作适当的剪裁,以满足特定的质量保证要求,剪裁后的计划必须经项目组相关负责人批准。1.2管理 1.2.1机构
在本软件系统整个开发期间,必须成立软件质量管理小组负责质量保证工作。软件质量保证组和项目负责人及各领导组必须检查和督促本计划的实施。系统的软件质量保证人员有权直接向各领导组报告该项目的软件质量状况。系统的软件质量保证人员应该根据对项目的具体要求,制订必要的规程和规定,以确保完全遵守本计划的所有要求。1.2.2任务
软件质量保证工作涉及软件生存周期各阶段的活动,应该贯彻到日常的软件开发活动中,而且应该特别注意软件质量的早期评审工作。因此,对于所负责系统,要按照本计划的各项规定进行各项评审工作。软件质量保证小组要参加所有的评审与检查活动。评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。在软件开发过程中,要进行如下几类评审与检查工作:
a.阶段评审:在软件开发过程中,要定期地或阶段性地对某一开发阶段或某几个开发阶段的阶段产品进行评审。在软件及其所属各子系统的开发过程中,应该进行以下三次评审:第一次评审软件需求、概要设计、验证与确认方法;第二次评审详细设计、功能测试与演示,并对第一次评审结果复核;第三次是功能检查、物理检查和综合检查。
阶段评审工作要组织专门的评审小组,原则上由项目总体小组成员或特邀专家担任评审组长,评审小组成员应该包括项目所有成员、质量保证人员、和上级主管部门的代表,其他参加人员视评审内容而定。
每一次评审工作都应填写评审总结报告(RSR)、评审问题记录(RPL)、评审成员签字表(RMT)与软件问题报告单(SPR)等四张表格。
b.日常检查:在软件的工程化开发过程中,各子系统应该填写项目进展报表,即软件进展报表表头、软件阶段进度表、软件阶段产品完成情况表、软件开发费用表等四张表格。项目组杨大亮或其他领导通过项目进展季报表发现有关软件质量的问题。
c.软件验收:必须组织专门的验收小组对软件系统及其所属各个子系统进行验收。验收工作应该满足各业务部门、领导部门及相关使用部门的需求,质量管理小组验收内容应包括文档验收、程序验收、演示、验收测试与测试结果等几项工作。而公司领导层、业务部门验收软件的功能演示成果及使用手册等。1.2.3职责
在项目的软件质量保证小组中,其各方面人员的职责如下: a.组长全面负责有关软件质量保证的各项工作;
b.全组负责有关阶段评审、项目进展报表检查以及软件验收准备等三方面工作中的质量保证工作;
c.项目的专职配臵管理人员负责有关软件配臵变动、软件媒体、文件控制以及对软件提供商的控制(在系统使用相关正版软件厂商提供的产品时生效)等三方面的质量保证活动;
d.全组负责测试复查和文档的规范化检查工作;
e.用户体验师反映用户的质量要求,并协助检查各类人员对软件质量保证计划的执行情况; f.项目的专职质量保证人员协助组长开展各项软件质量保证活动,负责审查所采用的质量保证工具、技术和方法,并负责汇总、维护和保存有关软件质量保证活动的各项记录。1.3文档 1.3.1基本文档
为了确保软件的实现满足认可的需求规格说明书中规定的各项需求,软件开发项目组至少应该编写以下八个方面内容的文档: a.软件需求规格说明书(SRS);
b.软件设计说明书(SDD),对一些规模较大或复杂性较高的项目,应该把本文 档分成概要设计说明书(PDD)与详细设计说明书(DDD)两个文档; c.软件测试计划(STP); d.软件测试报告(STR); e.用户手册(SUM); f.源程序清单(SCL); g.项目实施计划(PIP); h.项目开发总结(PDS)。1.3.2其他文档
除了基本文档之外,对于尚在开发中的软件,还应该包括以下四个方面的文档:
a.软件质量保证计划(SQAP); b.软件配臵管理计划(SCMP); c.项目进展报表(PPR); d.阶段评审报表(PRR)。
注:前面两个文档由项目组制订,属于管理文档,项目组应充分考虑执行计划中规定的条款。后面两类文档属于工作文档,就是本计划的2.2中提到的四张阶段评审表与四张项目进展季报表,项目组按照规定要求认真填写有关内容。1.3.3文档质量的度量准则
文档是软件的重要组成部分,是软件生存周期各个不同阶段的产品描述。验证和确认就是要检查各阶段文档的合适性。评审文档质量的度量准则有以下六条: a.完备性:所有承担软件开发任务的项目,都必须按照GB 8567(是国家标准局的指南文档,名称叫《计算机软件产品开发文件编制指南
》)的规定编制相应的文档,以保证在开发阶段结束时其文档是齐全的。b.正确性:在软件开发各个阶段所编写的文档的内容,必须真实地反映该阶段的工作且与该阶段的需求相一致。
c.简明性:在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确简练,适合各种文档的特定读者。
d.可追踪性: 在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性。文档的可追踪性包括纵向可追踪性与横向可追踪性两个方面。前者是指在不同文档的相关内容之间相互检索的难易程度;后者是指确定同一文档某一内容在本文档中的涉及范围的难易程度。
e.自说明性:在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。文档的自说明性是指在软件开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品的能力。
f.规范性:在软件开发各个阶段所编写的各种文档应该具有良好的规范性。文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。1.4评审和检查
对新开发的或正在开发的各个子系统,都要按照GB 8566(计算机软件开发规范)的规定认真进行定期的或阶段性的各项评审工作。就整个软件开发过程而言,至少要进行软件需求评审、概要设计评审、详细设计评审、软件验证和确认评审、功能检查、物理检查、综合检查以及管理评审等八个方面的评审和检查工作。在软件及其所属各个子系统的开发过程中,把前七种评审分成三次进行。在每次评审之后,要对评审结果作出明确的管理决策。下面给出每次评审应该进行的工作。1.4.1第一次评审
第一次评审会对软件需求、概要设计以及验证与确认方法进行评审。a.软件需求评审(SRR)应确保在软件需求规格说明书中规定的各项需求的合理性。
b.概要设计评审(PDR)应评价软件设计说明书中的软件概要设计的技术合适性。c.软件验证和确认评审(SV&VR)应评价软件验证和确认计划中确定的验证和确认方法的合适性与完整性。1.4.2第二次评审
第二次评审会要对详细设计、功能测试与演示进行评审,并对第一次评审结果进行复核。如果在软件开发过程中发现需要修改第一次评审结果,则应按照《软件配臵管理计划》的规定处理。
a.详细设计评审(DDR)应确定软件设计说明书中的详细设计在满足软件需求规格说明书中的需求方面的可接受性。
b.编程格式评审应确保所有编码采用规定的工作语言,能在规定的运行环境中运行,并且符合GB 8566中提倡的编程风格。在满足这些要求之后,方可进行测试工作。
c.测试工作评审应对所有的程序单元进行静态分析,检查其程序结构(即模块和函数的调用关系和调用序列)和变量使用是否正确。在通过静态分析后,再进行结构测试和功能测试。在结构测试中,所有程序单元结构测试的语句覆盖率Co必须等于100%,分支覆盖率C1必须大于或等于85%。要给出每个单元的输入和输出变量的变化范围。各个子系统只进行功能测试,不单独进行结构测试,因而要登录程序单元之间接口的变量值,力图使满足单元测试的C1和Co准则的那此测试用例在子系统功能测试时得到再现。测试工作评审要检查所进行的测试工作是否满足这些要求。特别在评审功能测试工作时,不仅要运行变量的等价值,而且要运行变量的(合法的和非法的)边界值;不仅要运行开发组给出的测试用例,而且要允许运行其他相关人员、评审人员选定的采样用例。1.4.3第三次评审
第三次评审会要进行功能检查、物理检查和综合检查。这些评审会应在集成测试阶段结束后进行。
a.功能检查(FA)应验证所开发的软件已经满足在软件需求规格说明书中规定的所有需求。
b.物理检查(PA)应对软件进行物理检查,以验证程序和文档已经一致、并已做好了交付的准备。
c.综合检查(CA)应验证代码和设计文档的一致性、接口规格说明之间的一致性(硬件和软件)、设计实现和功能需求的一致性、功能需求和测试描述的一致性。1.5软件配臵管理
对工程化软件系统的各项配臵进行及时、合理的管理,是确保软件质量的重要手段,也是确保该软件具有强大生命力的重要措施。有关工程化软件的配臵管理工作,可按软件项目组编写的《软件配臵管理计划》。在软件配臵管理工作中,要特别注意规定对软件问题报告、追踪和解决的步骤,并指出实现报告、追踪和解决软件问题的机构及其职责。1.6工具、技术和方法
在项目所属的各个子系统(其中包括有关的支持软件)的研制与开发过程中,都应该在各自的软件质量保证活动中合理地使用软件质量活动的支持工具、技术和方法。这些工具主要有下列三种:
a.软件测试工具。它支持用java语言编写的模块的静态分析、结构测试与功能测试。主要功能为:协助测试人员判断程序结构与变量使用情况是否有错;给测试人员提供模块语句覆盖率Co和分支覆盖率C1的值,并显示未覆盖语句和未覆盖分支的号码及其分支谓词,给出不同测试用例有效性的表格;同时提出功能测试的有效情况,并协助组织最终交付给用户的有效测试用例的集合。b.软件配臵管理工具。它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织;支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的涉及范围;同时还应支持软件配臵管理小组对软件配臵更改进行科学的管理。c.文档辅助生成工具与图形编辑工具。它主要协助用户绘制描述程序流程与结构的DFD图与SC图、绘制描述软件功能(输入、输出关系)的曲线以及绘制描述控制系统特性的一些其他图形,同时还可生成若干与软件文档编制大纲相适应的文档模块板。用户利用这个工具的正文与图形编辑功能以及上述辅助功能,可以比较方便地产生清晰悦目的文档,也有利于对文档进行更改,还有助于提高文档的编制质量。1.7媒体控制
为了保护计算机程序的物理媒体,以免非法存取、意外损坏或自然老化,工程化软件系统的各个子系统(包括支持软件)都必须设立软件配臵管理人员,并按照软件项目小组制订的、且经领导层批准的《软件配臵管理计划》妥善管理和存放各个子系统及其专用支持软件的媒体。1.8记录收集、维护和保存
软件开发项目质量管理措施探讨 篇3
关键词:软件开发;质量管理;措施
一、软件开发项目质量管理的原则及必要性
(一)软件开发项目质量管理的原则。在我国企业发展的过程中,对软件的依赖程度越来越高,由此也促使企业对软件质量的要求逐渐提升。软件企业在开发软件的过程中,已经充分的认识到了软件质量的重要性,因此,在进行软件开发时,会严格的按照相关的原则来进行,进而有效的保证质量要求。一般来说,软件开发时应该遵循的原则主要包含三点:第一,尊重客户需求原则,软件开发的目的就是为了满足客户的需求,因此,这是最基本的原则,同时,在与客户合作的过程中,要以互利为基础,将质量管理贯彻到软件开发过程的始终;第二,建立完善的质量管理体系原则,质量管理并不单单针对某一个软件开发项目,而是包含所有,因此,通过质量管理体系的构建,保证软件开发项目均具备较高的质量,实现良性循环;第三,重视软件开发团队精神原则,软件开发团队是软件开发项目顺利实施的保障,当团队精神比较好时,软件开发项目的质量就会比较高,因此,在进行质量管理时,必须要重视团队精神。
(二)软件开发项目质量管理的必要性。现如今,我国的软件开发行业已经发展的比较繁荣,软件开发技术也已经发展的比较成熟,软件开发行业属于知识密集型的行业,软件开发人员所具备的智力水平、知识水平都比较高,在进行软件开发的过程中,影响因素比较多,这都会在不同程度上影响软件的质量,由此,质量的保证就是一个比较困难的问题。如果前期开发的软件质量比较差,那么在投入使用之后,后期的维护、运营等成本都会增加,同时,还存在着安全隐患,甚至会带来不可预估的影响,基于此,软件开发项目的质量管理工作十分的重要。
二、软件开发项目质量管理措施
(一)对项目的过程进行合适的定义。软件开发项目的过程并不单单指软件产品的开发,还包含软件产品的维护。随着企业现代化的发展,企业管理中特别重视过程管理工作,通过过程管理,有效的提升了管理的效果和水平。企业在实行过程管理时,会受到外部环境或者组织模式变化的影响。基于此,软件开发项目过程的顺利实施,就需要利用过程管理的思想来保证,根据项目的实际情况,结合企业的发展,优化软件开发流程,同时保证软件开发的功能能够满足客户的需求。对于每一个设计阶段,都需要对其计入和退出条件进行明确的定义,进而有效的开展质量管理,提升软件开发的质量。
(二) 明确项目需求。所谓项目需求,就是指客户的需求,当客户需求非常明确时,软件开发项目所具备的成功率就会比较高,相反,成功难度就比较大。在实际的软件开发过程中,经常会发生用户需求改变的情况,从而对软件项目开发产生比较严重的影响。鉴于此项问题的存在,项目需求的明确是在软件开发之前所必须要进行的管理工作,首先,在与客户进行沟通时,应将客户的需求明确、详尽的填写在说明书中,避免开发人员误解行为的出现;其次,当客户的需求发生变化时,开发人员要与客户及时的进行沟通,并保证沟通的有效性,从而保证软件开发的顺利进行;最后,当用户的需求存在不明确的地方时,采取暂缓开发的政策,同时尽早的对这部分的需求进行明确。
(三)代码走查。软件开发周期比较长,在开发的过程中,会由多个开发人员同时进行,对于自身所负责的开发部分,开发人员要在每周固定的时间讲解代码,这样一来,开发人员可以对自己代码的质量有所了解,并根据他人的意见和建议优化自己的代码,提升软件开发的质量。
(四)对软件产品进行检测。在对软件产品进行检测时,主要包含两种检测,一种是集成检测,一种是系统检测,检测的主要内容有功能、安全性、用户界面、安装等,一般来说,在进行测试时,需要软件产品在模拟环境中运行,通过检测,保证软件产品无任何的缺陷。
结论:对于软件产品来说,质量是非常重要的,因此,在进行软件开发时,就需要进行质量管理。在对软件开发项目进行质量管理时,应该保证整个过程的管理,同时,质量管理工作还需要在充分满足客户需求的基础上来进行,通过检测、代码走查等手段,保证软件开发项目的质量,从而有效地开发出高质量的软件产品。
参考文献:
[1] 张成功.基于CMMI的软件开发质量管理问题研究[J].信息通信,2015,10(03):154.
软件企业项目的质量管理 篇4
1. 代码质量
编码质量是应用软件的高性能运行的关键, 主要指代码编写不规范或者程序不合理。例如类方法, 类变量, 类名称等命名的不规范;项目工程结构, 包结构的不合理, 代码注释过少, 没有异常情况处理等这些问题会对后期维护工作增加难度, 甚至发生异常时程序会中断, 而且一旦有人员变化也给交接工作也带来困难。所以我们应该重视编码质量。
2. 系统性能
系统需达到稳定高效实用、数据更新及时方便、数据调用快捷准确、操作维护简便、数据组织合理、可扩展性和兼容性良好的目标。由于对编码质量的忽视往往在系统上线之后进入正式的运行环境表现出死机, 内存溢出, 响应速度很慢等问题, 也常常引起客户的抱怨。
3. 功能性质量
功能性质量是衡量是否与用户需求相匹配的程度, 如果有用户所需必要功能并没有完成, 那么用户也不会满意。它主要表现在系统设计与原始需求有出入, 在沟通过程中由于双方理解不一致造成系统开发完成之后与客户需求偏差较大, 系统不能满足客户日常使用的需要, 有的甚至是客户明确提出过但在实际开发过程中由于技术难度问题没有实现, 种种原因的后果可能都会造成客户对系统不满意甚至于影响项目尾款的顺利结算。
二、对项目质量管理中产生问题的有效措施
1. 制定合理的计划
(1) 质量管理计划针对具体的项目, 一般由PPQA人员针对所负责的项目制定质量计划, 包括过程活动质量检查计划、参与技术评审的计划、参与产品测试的计划等。质量计划的目的是确保项目的质量目标都能达到。根据ISO9001要求为实现质量目标, 应遵循以顾客为中心、领导作用、全员参与、过程方法、管理的系统方法、持续改进、基于事实的决策方法、互利的供方关系等8项质量管理原则。
(2) 项目计划编制过程, 项目计划是项目管理的基础, 计划的制订与跟踪是贯穿于项目生命周期中持续不断的工作。在项目计划的编制过程中, 按照公司的计划管理过程域的要求, 与项目组的PPQA人员共同针对本项目的实际情况, 对组织级的项目定义过程进行了必要的裁减, 形成本项目的已定义过程, 将项目的整体过程分为项目管理、工程过程、支持过程三大类, 其中每一大类又包含若干具体的过程, 按照项目的各个已定义过程, 同时参照历史项目经验数据, 我组织了专家组对项目各个过程的规模、工作量、成本、工期、资源等进行了估算, 在估算数据的基础上编制了科学、合理、周密的项目总体计划与项目进度表。在项目总体计划中, 对项目目标、项目范围、项目组织、项目监控等措施进行了明确, 并定义了各里程碑的完成时间点以及主要的交付物。项目计划初稿完成后, 我提交计划评审申请至公司项目管理部, 由其组织高层经理、项目经理、客户代表、项目成员以及其它所有受影响的项目干系人共同正式评审计划, 并在评审通过后由高层经理对该计划进行了批准, 使所制订的项目计划获取所有各方的正式承诺, 并纳入计划基线的管理。
2. 加强项目执行
此阶段主要的工作是要按照预先制定的项目计划, 利用项目团队组织机构和工作程序, 领导项目团队开展各项工作, 管理和协调各利益相关者的关系, 成功地将项目计划投入实施。在项目管理中, 制定出一个科学、合理的项目计划, 只是为项目的科学管理提供了可靠的前提和依据, 但并不等于项目的管理就不再存在问题。在项目实施过程中, 由于外部环境和条件的变化, 往往会造成实际情况与项目计划发生偏差, 如不能及时发现这些偏差并加以纠正, 项目管理目标的实现就一定会受到影响。所以, 必须实行项目计划控制。我在实施过程中对实施情况不断进行跟踪检查, 收集有关实际项目的信息, 比较和分析实际的项目进度、成本、质量与计划存在的偏差, 找出偏差产生的原因和解决办法, 确定调整措施后再予以实施。
3. 加强软件项目的测试
(1) 软件测试的重要性
在系统开发完成之后, 怎样检验一个系统的可靠性, 怎样保证系统运行的稳定性, 怎样保证系统能够满足用户的真正需求等等这些都需要经过软件测试来验证, 我公司也有软件测试执行标准, 测试计划、测试用例等由软件测试人员编写, 编写完成后组织相关人员进行评审, 评审通过后才进行测试, 确保了测试的规范性和正确性。软件测试是软件开发过程中的一个重要环节, 软件测试贯穿与系统开发过程的每一个阶段。软件测试所起到的作用是——能够确保在软件开发过程中, 能够及时发现问题, 方便开发人员及时修改和调整。只有加强软件测试才能保证系统更稳定, 更符合用户需求。
(2) 软件测试的方法
为了提高软件质量, 要十分重视软件的测试工作, 成立了专业的测试小组, 编写测试计划、准备测试用例。开发人员在开发完成每个模块后都要严格的进行单元测试, 严格根据程序内部结构进行, 测试完成后形成单元测试报告。系统开发完成后需要联合各个模块进行联调, 负责各自模块的人分别测试对方的系统功能, 测试完成后形成集成测试报告。最后需要搭建模拟真实环境, 进行系统测试, 在这个环节中需要严格模拟实际情况, 包括性能的测试, 模拟实际的用户数同时访问系统, 检查系统稳定性与相关性能指标, 测试完成后形成系统测试报告, 交有项目管理委员会评审, 评审通过后开始部署上线工作。
4. 强化人员培训
(1) 业务需求培训
在项目开发启动之前项目经理要给项目组内各个成员讲解系统需求、要实现的功能, 以及应该达到的质量目标, 项目工期, 各自的任务分配, 担当的职责角色。只有当业务需求培训完成后才能顺利的开展下一步工作, 虽然浪费了一些时间但是会使后期的项目开发过程进展的更顺利。业务需求培训是很关键的, 只有项目组成员都熟悉了客户需求, 才能保障系统开发的成功。
(2) 技能培训
经验欠缺的开发人员缺少丰富的软件的开发知识, 在实际开发过程中不知道如何进行系统性能优化, 不清楚如何做到简洁的代码实现完整的功能。在开发过程中应该由项目组长或者架构师来给项目成员培训系统的整体架构与相关技术, 比如当前流行的J2EE架构, 还包括具体的实现技术。
三、结论
我们的软件企业应该积极的学习先进国家的管理理念与技术, 以项目管理为基础, 以质量管理为核心, 着重抓好项目计划制定与实施、软件测试、人员培训等方面的措施, 将项目质量管理体系尽早落实到实际的管理工作当中。
摘要:本文以某某科技股份有限公司以及当前软件企业所面临的主要问题为研究对象, 从项目管理理论和软件开发过程两个角度来探讨我国软件企业发展状况和与存在的问题, 利用理论联系实际的方法对当前软件企业普遍存在的问题进行分析与研究并提出有效的解决方案。
关键词:项目管理,项目质量管理,项目计划
参考文献
软件项目的配置管理 篇5
[摘要]:
2004年6月,我作为项目经理开始参与某航空公司航空票务系统项目的开发,主要负责系统的组织规划实施开发与项目管理,该系统具有严格的安全,稳定,时实高效和可靠性能要求,该系统由票务管理系统和呼叫中心系统两部分组成,呼叫中心系统主要实现电话,传真和短信业务,票务管理系统是整个系统的核心,采用了struts+hibernate+spring主流WEB应用框架,实现了WEB应用服务器websphere与协作应用服务器lotus domino 的高度集成.随着软件系统的日益复杂化和用户需求,软件更新的频繁化,配置管理在软件项目中显得越来越重要了。本文以该项目为例,结合作者时间,主要通过在项目前期,做好需求调研,总体设计和详细设计并制定完整的配置管理计划。在该项目全过程中规范化配置管理,注意员工培训并加强沟通与协调,来实施项目的配置管理。目前,该系统已开发完毕,正式投入运行,状况良好,受到客户一致好评。
[正文]:
2004年6月,2004年6月,我作为项目经理开始参与某航空公司航空票务系统项目的开发,主要负责系统的组织规划实施开发与项目管理,当然还做一些编码工作,主要是公用基础代码和核心代码的编写与维护。航空票务系统是将呼叫中心系统和票务管理系统有效的结合起来,采用先进的CTI技术和语音板卡技术,充分利用电话,短信,传真,因特网等信息化手段,解决航空公司的机票销售问题,规范了业务流程,强化了内部管理,与电子商务的完美结合,使应用系统功能更加完善,提高了整个航空业务的工作效率。其中,票务管理系统包括:客户管理,机票管理,票证管理,销售管理,财务结算,调度管理,远程营业部(代理商/分销商)管理,系统管理八大功能模块,并统一于服务器端软件模块。呼叫中心系统由电话呼叫系统,短信分发系统,传真呼叫系统三部分组成。票务管理系统是整个系统的核心,采用了struts+hibernate+spring主流WEB应用框架,实现了WEB应用服务器websphere与协作应用服务器lotus domino 的高度集成,在本次开发中,我把它视为整个项目的重点
由于考虑到寒假和春运期间将会是旅客的高峰期,客户要求系统必须在12月底前交付,项目开发周期为6个月,为此我做了如下安排:前4个月主要集中精力用于开发票务管理系统,后两个月主要完成票务管理系统和呼叫中心系统的集成以及项目收尾工作
随着软件系统的日益复杂化和用户要求,软件更新的频繁化,配置管理逐渐成为软件生命周期中的主要控制过程。在软件开发过程中,扮演越来越重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面,同时对软件开发过程的客观管理,即项目管理也有重要的支持作用。在该系统项目中,我主要使用intersolv公司的pvcs配置管理工具,并通过在项目前期作好需求调研,总体设计和详细设计并制定完整的配置管理计划。在项目全过程规范化配置管理,注意员工培训并加强沟通与协调等方法和策略来实施配置管理。项目前期做好要求调研,总体设计和详细设计,并制定完整的配置管理计划。
项目计划阶段,我对需求分析,总体设计和详细设计这三项活动工期安排如下:需求分析12天,总体设计和详细设计总共20天,时间尽量充足。在做需求调研的时候,我要求一定要和客户充分沟通,深入挖掘客户的隐性需求。不仅要实现客户需求的功能,在界面上也要让客户满意,为此我们作出了航空系统的虚拟界面,让客户对系统 有一个感官上的整体了解,在需求分析完成工作之后,我们还通过小组会议的形式进行了确认和评审。并邀请客户方代表参与。最终的《需求规格说明》我们也要求客户方代表一定要签字确认。在总体设计和详细设计过程中,我们尽量使用适合本项目团队特点的工具和技术,并充分考虑其先进性和成熟性。在设计完成之后,我们仍旧对其进行了评审,总结和讨论,对争议比较大的地
方交公司资深专家审核评定。
配置管理计划的制定也使配置管理中不可少的一步,它能有效的指导后期配置管理工作。在本项目中,配置管理计划由配置管理员完成,我只做一些审核工作,软件资源配置管理计划,配置项目计划,交付计划,备份计划,CCB审批计划等....总之,我认为项目前期做好以上铺垫工作可以减少变更,对后面一些工作可以说是水到渠成。同时,一个比较完整的计划,也可以避免不必要的项目反工,而且项目管理员的工作也会比较好做一些。项目全过程规范化配置管理。
开发过程中,对文档修改非常麻烦,在配置管理中,对任何一配置项的修改都可能导致版本的变化。因此,对配置管理规范化势在必行,在本项目中,我要求配置标识一定要规范,必须独立命名配置项,配置对象的标识要充分考虑命名对象间存才联系。在配置管理中,项目组成员要各司其职,不得越权操作,同时还要根据自己的权限操作配置项。我的工作在配置管理中主要是:定制开发子系统,定制访问控制,制定常用策略,制定集成里程碑,进行系统集成.....而配置管理员的职责主要是:创建配置序,为项目成员分配权限,对存储库进行日常备份恢复等...软件开发人员主要根据项目的开发配管理策略,创建,修改和测试工件等。软件生存期内全部软件配置是软件产品的真正代表,必须保持精确,软件工程中某一阶段的变更都会引起软件配置的变更,对这种变更也必须做到严格规范的控制和管理。为此,我做了如下规定:处于工作状态的产品开发人员可对其修改,而作为基线进入配置库的产品,则不允许开发人员对其进行修改。在本项目中,我们还成立了临时CCB,由项目经理,用户代表,软件质量控制人员,配置管理员5人组成。我们要求对于用户提出的变更请求要严格按照变更控制流程处理。在用户提交更多请求后,开发人员对其进行评价,并产生变更报告。在由变更控制委员会〈CCB〉作出决定是否进行变更。通过批准,就重新检出变更的配置项,建立测试基准程序,并执行质量保证和测试活动,必须通过CCB的鉴定审批后,方可实施变更。
注意员工培训并加强协调与沟通。
项目组成员大多来自不同部门,对项目环境还不熟悉,为了能实施配置管理系统,我建议公司对项目组成员进行相关培训。针对配置管理员,我们要求他学习配置管理工具管理相关的内容。针对开发人员,主要学习配置管理工具与开发相关的常用操作。针对全体人员,要让他们了解配置管理策略和流程,以及如何与开发管理,项目管理相结合。同时,我要求项目组成员要加强协调和沟通。可以使用PVCS,通过ressionmanger文档共享和连锁机制。Tracker与电子邮件的集成,加强项目成员之间的沟通,做到有问题及时发现,及时修改,及时通知,但又不额外增加很多的工作量,这样有助于营造一个和谐,公平,竞争的气氛和环境。
论软件项目的进度管理 篇6
关键词医保通系统项目进度管理
2013年6月,笔者作为项目经理参加了某保险公司医保通系统建设,主要职责是项目管理。“医保通系统”是指保险公司通过信息化手段和医院之间搭建的信息平台。医保通系统在省级公司建立医保通中心端,搭建数据库和应用服务平台,医保通前端设在医院。系统的主要功能包括:客户入院申报;探访核实的信息录入;处方信息采集和上传;处方审核;理赔金结算;统计分析功能。医保通项目历时6个月,于2013年12月成功上线。
该系统开发中,我主要担任项目管理工作。软件开发进度管理是一项软件开发项目管理的一个重要内容,有效的进度管理是保证软件开发项目如期完成的重要环节,在医保通系统开发过程中,我采用合理估算项目工期、工作量和技术难度,制定出项目的进度计划表;制作项目周报,及时了解项目进度,适时进行调整和动态控制;采用CPM法,识别关键任务,允许一些任务并行以及组件的复用等方法来保证项目如期完成。
一、合理估算项目工期、工作量和技术难度,制定出项目的进度计划表
首先制定项目日程主计划,内容包括项目在定义阶段、实现阶段、验证阶段、确认阶段的里程计划及主要成果物。
其次制定详细的进度表,先进行项目的工期的精确估算。在工期估算方面,我们主要采用基于公司项目估算参考表,如模块复杂度划分参考表、功能点代码行转换参数表、功能点生产率参数表、缺陷参考基准表、工作量分布参数表,对项目所需要实现的每一个功能模块在项目生命周期的每个阶段的基准规模、需求定义/设计/测试占阶段人天比例、评审占阶段人天比例、bug修复占阶段人天比例、模块规模(FP)、模块规模(LOC)进行详细的估算,同时估算出项目组每一位成员在项目生命周期的每个阶段以人天为单位的工作量,形成项目估算明细表。依据项目估算明细表,汇总统计出每一阶段/任务工作量、缺陷、详细的进度安排(包含每一阶段的开始时间、结束时间)、人员投入安排,制定出项目进度计划表。
最后在project中参照项目进度计划表相关数据填写各阶段工时值时形成项目甘特图。
二、制作项目周报,及时了解项目进度,适时进行调整和动态控制
在project中项目的计划开始、完成时间就是比较基准时间,它在项目计划做好后即可保存起来。项目开始、完成时间随项目成员反馈的任务进度进行更新,两者比较形成项目进度偏差。因此利用project的任务视图和资源视图可以随时看出目前项目进度、资源、成本与计划是否存在偏差。
每周利用project采集项目进度数据填写入度量计划表所列项目进度、里程碑进度差异等内容,按照《标准度量指标定义》中制定的度量方法和度量公式,计算度量结果,并对度量结果进行分析形成度量分析表,寻找偏差,采取行动调整偏差。综合project中反映出的项目的风险和问题形成项目周报,项目周报的主要内容有:项目进展概况、本周任务工作完成情况、下周任务计划、项目目前存在的问题和风险、度量分析表。每周举行项目例会,分析项目周报列出的进度风险和问题。
三、采用CPM法,识别关键任务
允许一些任务并行以及组件的复用采用CPM法,识别出项目的关键任务,允许关键任务以外的其他任务在机动期内收缩。而关键任务的收缩不得超过一周。当遇到关键任务延期时,就会召集大家开会,讨论找出项目延期的原因,并由主要责任人签字,把这种责任作为业绩考核的依据与工资挂钩。
四、结束语
CMMI的软件项目质量管理研究 篇7
关键词:CMMI,质量管理,创新,框架
1 基于CMMI的软件项目管理改进
1.1 需求调研
软件项目中没有非常标准的规范, 在需求调研过程中的测试人员、开发人员、系统设计人员都必须要具备一定的相关工作经验, 协助需求小组与客户进行需求调研与访谈, 要让他们在第一时间了解需求信息, 这样在执行项目各部分的时候可以更加深刻地了解软件系统, 防止部分人员在执行期间由于思路不清晰而出现问题。
1.2 制定需求管理计划
内容主要包括:需求管理的制度和方案、需求管理需要的管理工具、管理人员、所属责任。其中需求管理人员负责需求跟踪方案、培训计划、审批需求管理计划等。除此之外, 还应成立需求管理小组, 安排专人负责, 对需求小组成员进行培训。
1.3 需求分析
需求分析的过程比较复杂, 通常有以下步骤:
第一, 需求确认。严格遵照需求规格说明, 与技术人员、客户一起商讨, 通过讲解的方式确认真实需求, 最终让客户方的主管领导或者负责人签字确认。
第二, 管理需求变更。软件项目中的需求会随时发生变化, 如果草率确定下来, 随着开发的不断深入以及客户业务的变化, 需求是不能得到满足的。就此提出几点建议:首先, 需求变更申请一定要通过书面形式提出, 并由客户方负责人签字确认。收到需求变更申请以后, 应当先由项目组经理与客户方负责人协商, 如果协商失败的话, 组织相关人员开会讨论, 最终确认以后签字。其次, 对项目的设计和开发做出相应的调整。
第三, 在审核需求变更的过程中, 项目经理应通知项目的各小组 (包括开发组、设计组、测试组) , 以开会讨论的方式对影响范围及工作量进行评估。
第四, 需求跟踪。需求跟踪包括编制每个需求各类元素之间的联系文档, 这些元素包括体系结构、测试用例、源代码模块、帮助文件等。由此可见, 如果对需求进行跟踪采用手工操作方式的话是非常耗费体力的。因此, 我们可以充分应用TD管理工具来进行, 该工具可把需求定义、设计、开发、测试组成一个相互联系的整体。
2 基于CMMI组建的软件项目质量管理框架
开发人员的能力往往都是体现在团队的力量上, 技术层面主要是通过开发方法与软件工具的应用来集中体现的, 而软件过程成熟度则主要体现在对软件开发过程的自我改善能力和控制能力上。鉴于此, 我们应当以建立稳定、有效的软件过程为核心来应用有效软件开发工具, 从而真正控制软件的质量。图1是基于CMMI的层次, 结合软件项目管理的特点所组建的质量控制关键框架。
3 总结
CMMI已经得到广泛应用, 已经成为改善企业软件质量管理的重要方法之一, 我们应当加大宣传力度, 积极倡导各中小企业使用这种模型加强公司管理, 公司管理得好就可以大大提高自身的竞争力, 从而在激烈的市场竞争中处于有利位置。
参考文献
[1]刘冠男.基于CMMI的软件项目质量管理研究——以可人软件公司为例[D].北京:中央民族大学, 2013.
[2]李铃.项目质量管理方法在电信IT项目中的应用研究[D].南京:南京邮电大学, 2011.
[3]张仲雷.基于CMMI的软件项目质量管理框架[J].中小企业管理与科技, 2009, (27) :106—107.
[4]陈强.软件开发配置管理系统的设计与实现[D].大连:大连理工大学, 2009.
软件项目产品质量管理 篇8
1 软件质量与软件项目质量
电信企业要想应对市场的挑战就必须转变经营模型, 而转变经营模型则必须具有帮助企业提高经营绩效的软件, 这一点已经成为许多电信企业的共识, 很多电信企业的管理者也都意识到了软件质量的重要性, 因此投入大量的人、财、物以开发高效的软件系统。然而值得注意的是, 企业开发软件 (电信企业一般将软件开发的任务外包给专业的软件企业) 的过程是一个复杂的项目, 该项目的质量并不等同于项目所开发软件的质量。软件质量是指软件产品能够满足客户需求的所有特征和性能的总和, 而软件项目质量则是软件开发过程中所涉及的各项工作的质量, 即对所开发软件质量的保证程度。电信行业的基础设施建设需要耗费很大的成本, 因此对软件质量的过高要求必然会增加企业的经营负担。从这个意义上讲, 对于电信业而言, 电信企业软件项目质量管理的目的就在于通过软件开发过程的管理确保所开发软件的适用性, 实现以较少的成本投入研发适合企业经营的软件产品。
2 电信业软件项目质量管理
软件项目质量管理的涵义是确定软件项目的质量方针、目标和职责, 并通过质量计划、质量保证与质量控制各项工作确保软件开发项目中各项工作的质量, 进而保证所交付的产品满足客户的需求。
2.1 质量计划
对于软件项目质量管理而言, 必须先制定出一套较为完善的质量计划, 才能够以较大的概率完成软件项目质量管理的目标。制定软件项目质量所依据的应该是企业对与项目质量所制定的的战略目标。我国企业采取的等级结构一般都是典型的金字塔型结构, 管理者特别是高层管理者的理念与意识对于企业的各项工作能够产生非常大的影响。从这个意义上讲, 质量计划应该是电信企业与软件企业高管层的责任, 而软件项目的质量就应该是由企业高管层所规定的关于项目质量的战略规划以及工作的方向。
软件项目质量计划的目的是确保软件项目的质量, 因此就涉及到了衡量软件质量的问题, 即判断质量计划中的项目质量是否已经达到较高的标准。对于这一问题, 软件开发企业通常所采用的做法通常是与行业内项目质量的均值作比较, 以此判断本项目的质量能否达到行业内的平均标准。
2.2 质量保证
质量保证的一般含义是为了证明项目能够达到有质量的标准而在质量体系中所进行的工作。因此, 质量保证工作必须确保项目涵盖了能够达到质量要求的所有工作。若质量保证工作确定项目已经满足要求, 则可以继续进行下一个环节的工作, 即质量控制, 反之, 则要先完善项目质量计划工作。
对于软件项目而言, 质量保证的具体内容包括几个方面: (1) 具有清晰的软件需求分析。需求分析是软件达到客户要求的基本评价标准, 也是软件项目质量评价的基本依据, 因此, 必须确保软件项目具有清晰、可行的需求分析。 (2) 具有科学的软件项目质量体系与质量标准。需求分析是判断软件质量的标准, 而根据前文所述, 软件质量是否达标只是评价软件项目质量的基本标准。因此, 但仍然有必要从多个维度建立、健全软件项目的质量体系以及质量标准。特别是对于电信企业而言, 所面对的市场具有很大的不确定性, 有鉴于此, 电信企业软件的项目质量更需要建立、健全质量评价体系, 制定完善的评价标准。 (3) 具有完成项目所必需的各种资源。电信企业的基础设施建设需要耗费大量的成本, 电信企业的软件项目也同样需要大量的人、财、物等资源。因此, 在质量保证工作当中需要确定企业具有达到项目质量标准所必需的各种资源, 以保证软件项目能够达到其预定的标准。
2.3 质量控制
质量控制工作是指评价项目成果是否符合相关的质量标准, 并且当项目成果未达到标准时, 对其原因进行分析并找到解决的方法。当项目的成果达到质量标准时相关产品就可以交付使用了, 反之, 则需要对质量计划与质量保证两项工作进行改进, 以保证项目成果能够符合相关规定。
具体到软件项目, 质量控制包括两项具体的工作: (1) 判断所开发的软件是否达到客户所指定的标准, 若已经达到, 则可以继续开发, 反之, 则要对产品进行改进, 保证产品能够满足客户需要。 (2) 判断项目的成本与进度执行是否达到质量计划中的标准, 若已经达到, 则项目可以继续进行;反之, 就要判断, 是质量计划制定得过高, 抑或是具体的执行工作还有待改进以及怎样改进。
上述这两项工作实际上都是反馈控制 (即事中控制) , 即在软件开发项目的执行过程当中对开发工作的绩效进行判断。电信行业的市场特征使得电信行业的软件项目具有较大的不确定性, 采用事前控制的策略是较为困难的, 而事后控制策略对于当前正在进行的项目并没有太大的实际价值, 若当前的软件项目在执行过程中已经产生成本浪费, 使用事后控制策略不能及时发现问题进而采取措施。因此, 在质量控制工作当中应该采用反馈控制策略对各项工作进行合理的规划。
3 结语
电信业软件项目质量管理对于电信企业以及与之合作的软件企业的发展都有很大的意义, 相关企业的管理者应该给予充分的重视。在具体的项目质量管理工作中相关企业的领导者要根据企业对于项目质量的战略目标制定合理的质量计划, 通过质量保证工作确定项目涵盖了能够帮助达成质量计划的所有工作, 并通过质量控制工作对产品以及项目的成本与进度进行反馈控制, 以此提升项目的质量, 即所开发软件满足客户需求的基础上, 做到节约项目成本、加快项目进度。
摘要:电信行业日益激烈的竞争使得其对于高质量的软件有了更大的需求, 而电信行业的特点也使得电信业软件项目质量管理工作更为复杂。本文首先厘清了软件质量与软件项目质量的不同涵义, 进而根据电信行业的特点, 从质量计划、质量保证以及质量控制这几个方面论述了在电信业软件项目的执行过程中提高项目质量所应该注意的问题以及需要完成的工作。
关键词:软件,项目质量管理,电信
参考文献
[1]卢有杰, 王勇译.项目管理协会, 项目管理知识体系指南 (第3版) [M].北京:电子工业出版社, 2005.
软件项目产品质量管理 篇9
依照ISO9126信息技术标准中定义:1) 软件:与计算机系统的操作有关的程序、规程、规则及任何与之有关的文档。2) 软件产品:指定支付给用户的软件实体。3) 软件质量:与软件产品满足明确或隐含需求的能力有关的特征和特性的总和。4) 软件质量特性:用以描述和评价软件产品质量的一组属性。一个软件质量可被细分成多级子特性。通过功能性、可靠性、易用性、效率、维护性、可移植性这六个特性可以判断一个软件产品是否为高质量产品。
软件质量管理, 是确定软件产品的质量目标, 制定实现这些目标的计划, 以及为了满足顾客和最终用户的需要和希望而监控和调整软件计划、软件工作产品、活动与质量目标的过程。
二、软件项目监督与软件开发周期概述
软件工程生命周期分为立项、启动、需求分析、设计、编码、测试、上线、验收、运行和维护10个阶段。
软件开发的周期分为启动、需求分析、设计、编码、测试、上线六个阶段。
目前, 对大部分企业来说, 项目立项、项目验收由信息化项目主管机构组织实施。运行和维护由系统运管部门监督实施。软件项目监督是指企业设立的对软件开发过程进行监督的项目管理人员。其职责就是对过程管理、质量管理、变更管理及文档管理过程进行监督与评价、沟通与协调, 协助用户建设一个高质量的、具有可持续生命力的软件系统。
三、过程管理
过程管理的重点是各个阶段的评审。项目监督负责组织各阶段评审工作和文档归档工作, 监督各方对评审结果签字确认。过程管理流程图如图1所示。
各阶段评审内容如表1所示。
四、质量管理
4.1需求管理。据统计, 如果在需求分析阶段发生的需求变更对项目带来的额外工作量是5的话, 那么在系统设计和编码阶段发生的需求变更对工作量增加分别是20和100, 由此可见, 需求管理是质量管理最重要的环节, 需求做好了, 项目就成功了一半。需求常见问题是需求不确定、过多或变更频繁。主要原因:一是用户方和承建方之间信息的不对称, 挖掘实际需求比较困难;二是用户方和承建方在需求调研阶段调研分析的不够全面、不够深入。对用户方来说, 一是可能表述的较模糊;二是随着项目的推进对原来模糊的需求有了新的认识提出需求变更或提出新的需求。对于承建方来说主要是因为不熟悉用户方业务照成的理解的偏差。
项目监督在需求阶段的职责就是: (1) 组织行业专家对用户业务需求进行梳理, 和不同层面、不同部门的用户充分沟通, 尽可能在需求分析阶段通过多种手段消除“需求的不确定性”; (2) 对于过多的需求, 要帮助用户方和承建方分清轻重缓急, 设定优先级; (3) 组织用户方和承建方梳理、分析需求, 有效解决需求的变更频繁问题, 对于不可避免的需求变更需进行需求变更论证并做好相关文档的版本更新管理。
4.2评审管理。评审的目的就是及时发现缺陷、提高软件开发质量、减少软件开发的时间和费用。软件开发的每个阶段在其实施结束后, 都要组织技术评审或专家确认, 通过确认后方可进行软件开发下一个阶段的实施工作;数据库逻辑结构设计应经信息标准专家评审通过, 才能组织实施;如果评审未通过, 需提交整改方案。
4.3沟通管理。根据项目进展情况组织相关人员及有关专家召开项目周例会、月度例会, 检查项目是否发生偏差, 进度是否滞后, 是否存在问题, 讨论并制定解决方案, 布置下一步工作并编写会议纪要, 进行会议通报, 作为下一步工作的指导。
五、变更管理
所有变更都必须遵循变更控制流程进行控制并提交《软件开发项目变更申请书》, 所有变更都需由项目监督组织用户和有关专家审核通过方可实施。变更后, 受到影响的活动和相关的文档都要进行相应的变更, 以保持一致性。
六、文档管理
在系统上线阶段至少需提交以下7种技术文档:《软件需求说明书》 (附:计划要点表、需求评审表) ;《系统设计说明书》 (附:系统设计评审表) ;《数据库设计说明书》 (附:数据库逻辑结构字典) ;《测试设计说明书》;《用户手册》;《项目测试总结报告》 (附:缺陷记录和跟踪表、测试结果确认表) ;《项目开发总结报告》。
软件开发过程中所产生的技术资料、产品均应以电子和纸质形式存在, 项目验收后, 由项目建设单位或信息化工作管理部门负责项目文档的归档。
结束语
“三分技术、七分管理”, 在信息系统建设中建立合理的监督机制比人才、技术更为重要的因素。软件项目监督的实施在提高软件项目的开发质量方面起到了积极的作用。今后还需加大软件项目监督力度, 使项目监督参与到整个软件工程生命周期中。另外, 加强项目监督人员项目管理理论知识的培训对于提高软件项目开发质量是很有必要的。
参考文献
[1]苏秦, 何进, 张涑.软件过程质量管理[M].北京:科学出版社, 2008.
[2]朱少民.软件质量保证和管理.北京:清华大学出版社, 2007.
[3]李金海.项目质量管理[M].天津:南开大学出版社, 2006:29-30, 59-85, 153-158.
软件项目产品质量管理 篇10
关键词:计划,实施,检查,总结,软件,质量,管理
软件质量控制是软件企业和开发团队能够成功地开发出满足客户需求的软件产品的有力保证。它贯穿于软件项目开发过程的各个环节, 涉及到软件开发的各个部门。只有在软件开发的各个阶段, 对软件开发过程的所有活动及所涉及的各个组织和人员都实行严格的质量控制, 才能够保证软件开发过程的正确性和有效性, 最终才能生产出高质量的软件产品。
软件质量控制的方法主要有目标问题度量法、风险管理法和PDCA循环法。本文主要讨论PDCA循环法的内涵、PDCA循环法对软件项目质量管理的控制参数及PDCA循环法在软件项目质量管理过程中的实施。
1 PDCA循环法的内涵
PDCA循环法中的PDCA是英文计划 (Plam) 、实施 (Do) 、检查 (Cheor) 、总结 (Actiom) 四个单词第一个字母的组合, 它是由美国质量管理专家Deming博士提出来的, 所以又称为Deming循环。
PDCA可用四个阶段 (计划、实施、检查和总结) 八个步骤来说明, 这四个阶段构成了一个完整的圆环。
1.1 P (Plan) 阶段——计划阶段。
这个阶段的工作内容包括四个步骤:第一步, 分析现状, 找出存在的质量问题;第二步, 分析产生质量问题的各种影响因素;第三步, 找出影响质量的主要因素 (称为主因或要因) ;第四步, 针对影响质量的主要因素, 制定对策和计划。计划和对策的拟订过程必须明确以下几个问题:a.Why (为什么) , 说明为什么要制定各项计划和措施。b.Where (哪里干) , 说明在什么地点进行。c.What (干到什么程度) , 说明要达到的目标。d.Who (谁来干) , 说明措施的主要负责人。e.When (何时完成) , 说明完成措施的时间。f.How (怎样干) , 说明如何完成此项任务。
以上六点, 也称为“5W1H”技术。
1.2 D (Do) 阶段———实施阶段。这个阶段只有一个步骤:第五步, 实施计划, 即按照计划的要求去做, 执行计划采取的措施。
1.3 C (Check) 阶段———检查阶段。第六步, 检查效果, 即根据计划的要求, 检查实施执行的结果, 看是否达到预期的目的。
1.4 A (Action) 阶段———总结阶段。
这个阶段包括两个步骤:第七步, 总结经验, 巩固成绩。根据检查的结果进行总结, 把成功的经验和失败的教训纳入有关的标准、规定和制度中, 指导今后的工作;第八步, 把没有解决的问题或新出现的问题转入下一个循环。
2 PDCA循环法对软件项目质量管理的控制参数
在软件项目质量管理过程中, 对软件产品产生影响的参数有三类:产品、过程和资源。PDCA循环法对这三类参数进行综合的调节和平衡。
2.1 产品。
产品是软件开发过程所产生的结果, 它可以是软件生命周期中某一过程的任何输入和输出, 也可以是对最终产品的需求、最终产品本身、开发过程中产生的任何中间产品。如软件系统、软件开发计划、系统规格说明、软件设计文档、差错报告、测试结果等。
2.2 过程。
过程是为完成开发、维护和为保证软件质量所进行的管理和技术活动。如项目立项申请、资源选择、监控开发进展、配置管理、开发初样、设计评审等。
2.3 资源。
资源是为得到要求质量的软件产品, 在实施过程时所使用的时间、资金、人和设备。如软件开发设备、软件测试设备、系统硬件、资金等。
PDCA循环法通过计划来确定质量目标, 定义质量控制参数;通过实施来开发质量, 度量质量控制参数;通过检查来评估质量, 评估质量控制参数;通过总结来提高质量, 改变质量控制参数。
3 PDCA循环法在软件项目质量管理过程中的实施
软件项目开发阶段分成预开发、开发和维护三个阶段。
3.1 预开发阶段。
预开发阶段是指系统开发之前所发生的与系统的获得有关的一切活动。客户通常要完成建立需求的研究、发布招标请求、进行资源选择、与系统开发者签订合同等一系列活动。
客户的工作体现在下列PDCA循环中:a.计划:计划要采用的质量控制过程;在可用资源、已认识到的风险或困难、经验和资金的基础上, 制定选择开发组织的标准;选择已获得证实的、效果较好的软件工程技术工具和方法。b.实施:制定开发招标提案请求包, 包括软件功能和质量需求规格说明、任务描述、资源选择的标准、招标书评价的指导、进度计划数据和将来应提交的产品的要求等。c.检查:检查招标提案请求包的质量, 必要时采取措施进行改进, 并针对不同开发组织对招标提案请求包的反应情况, 对照选择的标准, 选择一个开发组织。d.总结:根据对开发组织、开发过程的选择以及已认识到的风险和困难、可用资源等情况, 提出改善质量控制的计划。
开发组织针对招标提案请求包作出反应, 工作体现在下列PDCA循环中:a.计划:提出要开发的中间产品。b.实施:开发自己的技术提案, 阐明将使用的技术及所拥有的技术工艺。c.检查:提出检查软件质量、纠正产品中缺陷的方法。d.总结:根据检查结果, 提出改善质量控制的计划。
3.2 开发阶段。
开发阶段是指从软件产品开发开始, 到移交产品且客户对软件性能予以肯定为止。这一阶段的PDCA循环活动有:a.计划:开发者根据需求和风险, 提出详细的开发过程、要求使用的资源以及要得到的产品。b.实施:由开发组织执行开发计划。c.检查:开发组织和客户共同检查计划与预期得到的结果的一致性。d.总结:开发组织根据检查结果, 审查并重新认识风险, 作为下一个循环的基础。
3.3 维护阶段。
维护阶段是修复软件缺陷、提高软件性能的阶段。这一阶段的PDCA循环活动有:a.计划:制定处理缺陷的计划。b.实施:处理缺陷, 或根据需求变化提高软件性能。c.检查:开发维护目标是否已经达到。d.总结:根据检查结果, 审查并总结。
由此可见, “计划-实施-检查-总结”这几个基本要素, 在每个软件开发阶段都要不止一次地、循环地应用, 以实现那个阶段的质量目标。在每一个阶段, PDCA循环活动各形成一个小循环。而从整个产品的开发来看, 预开发阶段是这四个基本要素中的“计划”, 在开发阶段和维护阶段, “实施”计划的各种开发或维护活动, 同时进行“检查”, 若发现不满足需求, 则要采取“总结”措施。这是一个大循环过程。PDCA循环法就是这样一个大环带小环, 大环套小环, 周而复始的过程。在软件项目质量管理过程中, PDCA每经过一次循环, 一些问题就会得到解决, 软件质量水平和管理水平就得到了不断的改进和提高。
参考文献
[1]朱少民.软件质量保证和管理[M].北京:清华大学出版社2, 007.
[2] (以) 加林 (Galin, D.) .软件质量保证[M].王振宇等, 译.北京:机械工业出版社2, 004.
软件项目管理中的风险控制 篇11
【关键词】项目管理;风险控制;威胁;机会
一、引言
软件项目风险控制是软件项目管理的重要内容。在进行软件项目风险控制时,需辩识风险,评估它们出现的概率及产生的影响,然后建立一个规划来管理风险,所以在软件项目研究的可行性分析和方案认证时,加强软件项目方案风险分析是十分必要的
二、风险管理的目的
(一)有效的风险管理可以提高软件项目的成功率。(二)与团队成员一起进行风险分析可以让实施人员对困难有充分估计,对产生的风险有心理准备,可大大提高项目组人员信心。(三)有效的风险管理便于在项目实施过程汇总能抓住工作重点,集中于重大风险,将工作由被动救火转变为主动防范。
三、风险识别有以下几种方法
风险管理的主要目标是预防风险,软件项目风险是指软件在开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目实施的影响。软件项目风险会影响项目计划的实现,如果项目风险变成现实,就有可能影响项目的进度,增加项目的成本,甚至使软件项目不能实现。所以,在项目实施中 需对项目风险进行识别,方法有以下几种:
(一)头脑风暴。有关项目成员、专家、客户等各方人员组成小组,一起讨论所有可能的风险;(二)专家访谈。向软件开发领域的专家或有经验的人员了解IT项目管理中遇到具体困难。(三)历史资料。通过查阅数据移植项目的历史资料了解可能出现的问题。(四)检查表。将可能出现的问题列出清单,可以对照检查潜在的风险。(五)评估表。根据以往上线的IT项目进行总结,通过调查问卷等多种方式判别风险类型。
软件风险管理的最终目标并不是识别和分析。针对软件开发中的每一个风险,特别是高危险度的软件风险,风险管理还需要对它们进行有效的控制。包括 制定风险管理计划:针对各个重要风险制定风险管理计划,并确保它们的一致性;化解风险,执行风险管理计划,以缓解或消除风险;监控风险,监控风险化解的过程。
四、怎样的风险导致软件项目的失败?
软件开发过程中面临各种选择。风险因素介于确定和不确定性之间,风险受到行为、地点、思想、观念等诸多因素的改变。
软件开发中的风险指软件在实施开发过程中可能对最终结果造成的伤害或损失。风险来自于项目实施的过程中,意味着,风险产生的不确定性,如:
(一)已经开始的项目,在未结束之前便放弃;(二)所开发的项目并没有达到预期效果,无法完全提供设计的功能;(三)项目开发时间比预计延长较多;(四)项目开发需求不断增加;(五)项目开发需求不断增加;(六)验收;
开发技术、用户需求以及其他与项目有关的因素的改变将会对按时交付和总体成功产生什么影响;对于采用何种方法和工具,需要多少人员参与工作的问题,我们应如何选择和决策;软件质量要达到什么程度才是“足够的”。当没有办法消除风险,甚至连试图降低该风险也存在疑问时,这些风险就是真正的风险了。在我们能够标识出软件项目中的真正风险之前,识别出所有对管理者和开发者而言均为明显的风险是很重要的。
五、如何进行有效的风险管理
在进行软件项目风险管理时,需识别出潜在的风险,评估风险出现的概率、产生的影响,并按重要性进行分级,其次建立完善的计划来管理风险。风险管理的主要目标是预防风险,并不是所有的风险均能预防。所以需建立一个意外事件计划,便于在出现意外事件时能以可控、有效的方式做出反应。
风险管理目标的实现包含三个要素。
第一,必须在项目计划书中写下如何进行风险管理;第二,项目预算必须包含解决风险所需的经费,如果没有经费,就无法达到风险管理的目标;第三,评估风险时,风险的影响也必须纳入项目规划中。
六、如何进行风险辨识
识别风险是系统化地辨别已知的、可预测的风险,在可能时避免这些风险,且当必要时控制这些风险。根据风险内容,我们可以将风险分为:
(一)产品规模风险:与软件的总体规模相关的风险。(二)商业影响风险:商业风险影响到软件开发的生存能力。商业风险含五大主要风险:策略风险:开发的产品不符合公司的整体商业策略;预算风险:预算或人力没有保障。市场风险:开发的软件产品没有人需要;销售风险:软件开发后没有企业、公司愿意使用;管理风险:由于重点的转移或人员的变动而失去了高级管理层的支持的风险;(三)过程定义风险:在软件开发过程中的相关风险。(四)开发环境风险:与开发工具的可用性及质量相关的风险。(五)技术风险:技术风险是指在设计、实现、接口、验证、维护技术的不确定性、陈旧的技术等方面存在的风险。技术风险威胁到软件开发的质量及交付的时间,如果技术风险变成现实,则开发工作可能变得很困难或根本不可能。(六)人员数目及经验带来的风险:与参与工作的软件工程师的总体技术水平及项目经验相关的风险。在具体的软件项目风险识别时,可以根据实际的项目情况对风险分类。但简单的分类并不一定精确,某些风险根本无法预测。
七、风险估算
进行风险辨识后,需要风险估算,风险估算从以下几个方面评估风险:
(一)建立一个标尺,以反映风险发生的可能性;(二)描述风险带来的后果;(三)评估风险对项目实施及结果产生的影响;(四)评估风险整体精确度,避免产生误解。
因为软件项目实施需要开发新的技术,或使用已验证过的技术和产品,这些技术不容易达到成熟、定型的程度。而且大型项目的研发需长时间、大规模的组织、协调工作,漫长的研制周期等,都会带来不确定性因素。这些因素的存在使软件项目能否按照预定计划、费用、进度完成研制任务存在很多不确定因素,不能确定是否能研制成功,存在很大的失败风险。所以在项目实施过程中对项目方案进行风险分析是十分必要的。对辨识出的风险需进行进一步的确认,即假设某一风险出现后,分析是否有其他风险并存,或假设这一风险不出现,会产生什么情况,然后确定主要风险出现最坏情况后,如何将此风险的影响降低到最小,同时确定主要风险出现的数量及时间顺序。在进行风险分析时,最重要的是对不确定性的风险程度和损失程度进行评估。为此,需考虑风险的类型。识别风险的方法是建立风险清单,清单上需明确列出在不同时间可能碰到的风险,而且必须对风险清单进行时时维护,更新风险清单,并向所有实施人员公开,鼓励项目组的每一位成员勇于发现问题并及时发出警告,风险清单给项目管理提供了一种简单的风险预测技
八、软件风险管理的总结
软件项目产品质量管理 篇12
根据GB/T19000-ISO9000 (2000) 的定义, 质量管理是确立质量方针及实施质量方针的全部职能及工作内容, 并对其工作效果进行评价和改进的一系列工作。戴明理论、朱兰理论、全面质量管理等都给了我们很好的理论指导, 但在实际项目工作中, 我们仍然需要根据实际项目情况考虑如何真正做好质量管理。
二、模块化的软件开发项目中的质量管理
所谓模块化的软件是指把整体软件按功能分块, 多个块可以组成实现一系列功能, 开发完成后, 很多类似的业务功能应用就可以在前台配置完成, 减少了重复的开发工作。模块化的软件开发和一般的软件开发的区别在于牵一发而动全身, 其质量管理也难于一般的软件开发项目。在模块化的软件开发除了加强计划的制定跟踪外还要做到以下几点, 以提高软件产品质量。
2.1 加强关键点沟通确认。需求分析人员需要加强与需求提出人的沟通, 理清需求提出的根本原因, 从整体考虑需求的合理性, 减少需求变更的可能性。对于可能冲突的需求要提前分析, 沟通过程中避免就一个问题不断的确认, 而是要采用引导式的沟通, 帮助需求提出人进一步完善需求, 提高需求分析结果的质量。
需求分析人员参与软件开发设计, 避免开发人员对需求理解有误, 也便于对设计影响进行评估。
对需求分析设计结果需要相关人员签字确认, 从源头加深相关人员的重视。
单元测试完成后邀请需求提出人参与功能体验, 确保设计出来的结果是其想要的。集成测试时可以邀请更多的用户参与体验, 并反馈意见和建议。
2.2 加强开发、测试人员对关键业务需求的理解。模块化功能需求的开发要求开发人员对关键业务需求加强理解, 如果对关键业务没有整体的了解, 在设计开发时很大可能无法达到预期, 更可能调整了部分程序导致原先已实现的关键功能失效。测试人员如果对业务不够了解, 将无法达到测试效果。
2.3 加强关联功能考虑总结。模块化的设计确实能减少开发工作, 有效实施类似的业务需求, 但是其功能关联性也显而易见, 所以在需求分析、设计、开发时都需要认真考虑其关联的影响, 并对其进行总结。
集成测试的时候尤其要设计完成关联混合场景的测试, 对测试出来的问题并不是一发现就进行单个处理, 而是首先要查看是否有关联的问题, 理清问题产生的原因和可能的影响, 根据问题的影响和紧急程度, 再考虑处理, 这样才能提高问题处理的质量。
测试的数据量也是一个指标, 很多时候不到一定量级, 有些问题是不肯暴露的。压力测试是一个不错的选择, 模块化的设计特点在于一个功能的影响可能会牵扯到多个前台业务, 提前发现问题, 提高系统性能是必须的, 是保障软件开发质量的一部分。可用和好用绝对是很大的区别。
2.4 加强文档质量管理。需求分析、设计、开发、测试文档不仅要有, 更重要的是关注文档的质量。好的文档可以帮助需求分析人员和开发人员更好的处理需求。文档是项目人员沟通的可寻依据、是开发人员开发过程中需要使用的重要文档。仅是凭借我们的大脑来记录和分析很容易出现问题, 再者从现今的互联网市场情况来看, 开发人员的流动性是非常高的, 缺乏问题就意味着对人的依赖性加强, 一旦关键人员离职, 对项目开展的影响是很大的, 对于模块化的软件开发项目更是如此。
2.5 加强监控报表和日志的开发。在软件开发设计中需要提前考虑事后控制, 对于关键功能需要考虑如果出了问题, 如何第一时间发现。这就需要把关键的信息都要记入日志, 开发监控报表, 设立监控机制活着自动邮件提醒机制, 以便能及时发现问题、解决问题, 提高用户满意度。
质量管理是一个持续的过程, 很多顺手而为的事情也会直接影响最终的质量。事实上很多时候说容易, 做到却很难, 进度影响、管理要求、部门协调配合等都会对项目的质量管理造成影响。很多时候不要去抱怨, 而是要适时根据新条件, 新环境去调整, 在有限的条件下保障软件开发的质量。
摘要:随着信息技术项目的增多, 项目管理工作越发的引人重视, 质量管理工作是其中的一部分, 其贯穿整个项目过程。过去的软件开发很少考虑功能复用, 通常是每个功能需求都需要通过代码开发来完成, 而现在更多的是模块化开发, 本文就模块化的软件开发项目质量管理过程中一些注意点加以阐述。
关键词:质量管理,软件开发,模块化
参考文献
[1]张友生, 陈志风.信息系统项目管理师考试全程指导[M].清华大学出版社, 2009, 8.
【软件项目产品质量管理】推荐阅读:
软件项目的质量管理09-19
论软件项目的质量管理09-08
软件项目过程质量09-26
软件项目的项目管理12-11
软件项目需求管理论文06-06
软件项目的沟通管理06-26
发展软件项目管理07-08
软件项目管理活动07-26
软件项目管理分析08-02