软件项目过程质量

软件项目过程质量（精选11篇）

软件项目过程质量 篇1

摘要：基于以研发项目软件需求作为独立问题的思路, 提出通过问题管理的方式, 实现软件需求和软件设计过程的有效结合。并结合公司实际工作项目实践, 以问题跟踪工具DevTrack为基础, 提出了一种提升中小型软件项目过程质量的方式。实践表明这种方式能有效提高项目需求管理水平, 细化项目管理节点。

关键词：问题管理,DevTrack,软件项目过程质量

引言

目前, 计算机软件的规模和复杂度在不断增长, 国内软件企业也纷纷引入软件项目管理的理念。但国内软件企业对于软件项目的认知, 在一定程度上盲目多于理性、理论多于实践。在软件项目开发过程中, 从项目立项到推出完整产品, 需求的控制和软件缺陷的管理都直接影响到软件的进度和质量。软件项目管理为了监督和跟踪项目, 一般都会要求引入需求变更控制流程和缺陷跟踪管理流程。一般大型软件项目都会为这两个流程制定专门的管理规范, 并引入专门的工具, 例如Rational的系列工具。在中小型软件项目中, 通常都会引入缺陷管理工具, 但是对需求控制一般要求不会太严格, 管理流程也相对放松, 通常都是通过文档管理来控制需求变化。而缺陷管理主要用来确保每个被发现的缺陷都能够被有效处理, 使用得比较好的才会有目的地用工具进行缺陷数据的收集和分析。实际使用中, 在跟踪项目计划时, 需求变更工具和缺陷跟踪管理提供的数据也是项目管理人员用来确定项目状态的重要依据。在项目时间有一定跨度、需求变化较大的情况下, 项目计划会需要不断修改, 最后是项目计划跟在实际情况后面修订, 原来制定的项目计划难以细化和落实, 只能停留在纸面上, 失去了计划的意义。而开发项目中隐藏的缺陷也随着需求的变动不断增加。软件产品即使最终推出, 也难以保证其达到预期质量, 更不用提获得足够的客观数据来提升软件项目过程质量。

1 软件项目现状分析

该公司面对的是特殊客户, 整个研制过程按照客户规定, 在研制合同确立以后, 要经过方案论证、初样研制、正样研制阶段, 经过客户试验合格, 最终才能实现设计定型。尽管每一步都有完整的评审过程, 评审也都要邀请外部专家参与, 但由于时间和环境等原因, 往往难以达到客户和公司期望的效果。这样控制质量完全依赖大节点的评审, 让软件缺陷难以提前得到验证和修订, 一直到试验阶段才会比较集中地暴露出来, 这时修正, 工作量比设计前期增大, 而其它成本也大大上升。而对项目管理人员来说, 由于节点时间长, 对项目的动态和实际进展, 主要是通过项目会议来把握项目计划。这样, 除了依靠经验以外, 很难有什么合适的手段, 更难以做到精确掌握。对于项目开发过程中的项目需求和缺陷的控制, 很难进行有效管理。尤其是随着这两年公司业务的快速发展, 公司总部分成本部和新园区办公, 又新增多处外地研发中心, 对项目管理方式的改进有着迫切的需求。经过分析, 同一般商业软件项目相比, 该公司软件项目具有以下一些特点:

(1) 项目数目多, 而大部分项目规模较小, 但是对研制过程必须经过的阶段要求严格, 时间较长, 全部流程完成平均时间在两年以上;

(2) 项目起始阶段, 除了硬件样机性能指标, 客户其他需求一般都不清晰, 公司也缺乏一个有效的需求开发和控制机制。由于开发过程时间长, 中间其它需求变化会比较大, 有时客户需求变化有一些随意性, 并且客户需求基本都要遵从;

(3) 一般应用于嵌入式环境, 调试环境比较差, 对于界面等要求相对较低, 但是和硬件紧密结合;

(4) 在产品定型以前, 一般样机很少, 通常只能满足开发调试和现场试验需要, 难有条件做系统的黑盒测试。

2 软件项目管理改进

基于公司的软件项目现状, 提出一种新的思路。一个软件项目源头就在需求, 整个项目开发过程就是为了有效地实现这些软件需求。在出现实际设计不符合需求时, 就要通过缺陷管理来解决问题, 使设计和需求相符合。而需求变更和新增需求过程, 也是由于需求变化, 导致设计不能和需求相一致, 给软件项目带来新的设计变化要求。如果把项目按照需求分解成一系列问题, 实际的软件设计也就是把这些需求问题细化, 软件编码就是对需求问题做出具体化解答。因此, 如果把需求当作一系列需要解决的问题, 整个项目开发过程就是这样一个问题求解的过程, 项目管理就是合理地调配资源, 来配合实现问题求解。缺陷管理工具针对发现的具体程序缺陷, 都有一套完整的闭环流程, 一般都包含从“缺陷提交”, 到“缺陷分配”, 再到“缺陷解决”, 最后到“回归验证”的过程。工具还会提供强大的统计和报表输出功能, 对历史过程也会有完整的记录保留。缺陷管理工具在流程追踪上的优势是很明显的。而从问题管理的角度来看, 和需求问题相比, 缺陷就是一类范围定义得很清晰的问题。如果能够通过缺陷管理工具实现问题的分解和关联, 一个项目软件设计的进度管理、需求管理、故障—管理等都可以在缺陷管理工具上结合起来控制完成。

3 DevTrack功能简介

为了实现上述基于问题的管理模式在对目前比较流行的商用和开源软件进行多方比较后, 最终选择了TechExcel公司的DevTrack来实施。DevTrack的基本理念就是基于问题驱动, 和我们的上述想法非常吻合。在DevTrack中, 可以把开发过程组织成项目, 项目可以分解成一系列任务, 这些任务又由工作流程有效地组织起来。对于复杂的项目, 可以分解成几个子项目, 然后对子项目执行任务分解。任务是项目管理中最小单位, 可以分成三类:基于新需求的任务;需求修正类型的任务;产品缺陷类型的任务。这样一个软件系统设计要解决的问题, 就和软件项目管理中的一个个任务对应起来, 可以通过DevTrack这样一个工具来实现底层的结合。

软件系统设计需求和DevTrack中软件项目分解任务的对应关系DevTrack可以基于状态或基于事件跃迁触发工作流程的流转。不只是处理任务, 流程中发生的各种事件, 如状态改变、增加附加信息、任务延迟预警、任务延迟等, 都可以设置为触发源。所有事件都有多种灵活的告知机制可选。DevTrack的功能都基于灵活定制来设计, 项目相关的内容都可以由管理员根据需要定制。和软件项目过程密切相关的主要有两项:

(1) 定义项目的成员结构, 对成员组别和相关的权限、技能、成本等信息实行管理, 还可以根据工作任务动态计算工作负荷。

(2) 定制项目的工作流程, 对于复杂的项目, 可以分解成几个子项目, 对每个子项目定义自己的工作流程。此外, DevTrack还提供了和多种配置管理软件的接口, 可以实现无缝连接。出于费用方面的考虑, 试点项目选择了开源的Subversion。利用DevTrack的集成接口, 在Subversion上进行的操作, 和DevTrack的内部动作一样, 可以方便地触发内部流程。

4 项目实践

公司挑选了一个典型项目来作为试点, 项目主要开发人员在新园区, 而测试人员、客户代表以及项目管理人员位于本部, 硬件服务器和网络配置等主要设施也在本部。管理员首先配置了项目工作流程, 对项目设置了任务处理流程、故障处理流程。为与公司管理制度配合, 增加了工作的月计划流程, 月计划流程通过和前述任务处理及故障处理流程关联来实现。在项目执行过程中, 按照如下模式来执行:

(1) 项目管理员设置项目基本内容、项目成员。在本项目中, 项目人员划分成项目经理、测试经理、项目管理员、开发人员和测试人员五种角色组, 每组设置恰当人选, 其中部分人同时属于两个组;并对应不同开发阶段设置了项目状态, 对每种角色, 在不同状态设置了不同的权限。

(2) 在项目起始阶段, 对应系统需求文档, 没有设立子项目, 直接分解出不同的项目任务, 并下达给对应的开发人员组的责任人。

(3) 开发人员通过配置管理工具提交设计文档和设计代码的同时, 测试人员会得到通知, 并可以启动测试流程。

(4) 测试人员如果认为设计有问题, 可以提出故障, 启动一个新任务, 通过故障处理流程和项目经理指配给责任开发人员。

(5) 开发过程中间经过评估, 发现需要新增需求, 项目经理就通过任务处理流程来处理。出现需求变更的情况, 在工具中对原任务做出说明后, 任务提前返回项目经理处, 在变更以后, 重新进行处理。整个过程会通过DevTrack自动记录下来。

(6) 项目运行过程中, 项目管理员随时通过DevTrack报表统计项目状态、任务处理、需求变化等状况, 并产生报告。还可以按照任务和缺陷的数目、变化趋势、处理情况等, 设置各种预警条件, 自动产生各种项目状态提示。

结束语

目前试点项目已经基本完成, 这种模式得到了成功应用, 取得了预期的效果:

(1) 由于需求和任务对应关联增强, 对于需求变化情况和需求变更评估变得更为有效;

(2) 细化了控制节点, 项目管理人员也对项目状态有了更清晰的掌握;

(3) 相比过去的方式, 项目运转的流程更清晰, 获取了更多有效的项目流程信息, 对提升后续的项目软件流程控制有借鉴作用;

(4) 更丰富的报表和项目流程与电子邮件的紧密结合, 提升了项目内部人员之间以及项目内外人员之间的沟通效率。

实际中发现这种方式在项目成员绩效和项目人员工时考核上也有一定作用, 但在资源管理和成本控制等方面, 必须和项目管理计划等结合才能更好地发挥作用。

参考文献

[1][美]凯西·施瓦贝乐.IT项目管理, 王金玉时郴译[M].北京:机械工业出版社, 2002.

[2]AlanM Davis.Using RequirementManagement To Speed Delivery of HigherQualityApp lica-toins[Z].Rational Soft2ware Corporation, 1995.

[3]TechExcel Incorporation.DevTrack6User Guide[Z].Te2chExcel Incorporation, 2005.

[4][美]威伊格斯.软件需求, 陆丽娜等译[M].北京:机械工业出版社, 2000.

软件项目过程质量 篇2

质量保障措施

质量保障措施包括项目质量管理保障措施和软件开发质量保障措施两方面。

1.1.1

项目质量管理保障措施

1、资深的质量经理与质保组

针对本项目，将派遣资深的质量经理参与质量保证组（简称SQA组）。SQA组负责确保项目遵守质量保证体系的标准要求，确保遵循项目计划书中描述的要求，确保交付的软件及其文档以及非交付的软件在需求、设计及管理等诸多方面的质量。

2、全程参与的质量经理

质量经理，即质量保证组组长，监控项目成员的软件活动，并对软件产品与可适用的标准、过程和软件开发计划的符合性进行评价，为双方项目领导小组监控项目的软件生产提供适当的可视性。

3、合理的质量控制流程

质量经理负责对项目进行监控与分析，将结果报告给由双方高层人员组成的项目领导小组。项目经理批准发布给用户的所有文档和软件，必须得到质量经理的复核和批准。

质量管理规范

质量经理的工作依据为行业标准、客户方约定的管理规范和公司的管理规范，工作方式为编制质量计划、过程和产品检查、评审和审计、问题上报等。

服从工程监理

鉴于本项目的专业性和复杂性，如本项目中标，XXX将在系统建设、安装调试和验收等各环节严格服从专业监理公司的全过程监控，以保证整个项目的质量。

加强协调管理

由于本试点工程参加建设单位较多，需要统一协调与配合。如本项目中标，xxxx将积极配合、充分协调项目参与各方的关系，提高工作效率，团结一致共同建设本项目。

严格合同和计划管理

本项目内容复杂，如本项目中标，为保证工程建设的质量和建成后运行的质量，在施工各环节将严格加强合同管理和计划管理，严格按合同及工作计划进行施工，确保工作质量。

重视培训

由于本项目内容复杂，专业程度较高，如本项目中标，xxxxx将把培训工作贯穿到整个建设过程中。本项目的培训不能按照传统的培训方式在项目完成后进行，在工程设计、施工阶段采用边设计施工边培训的方式，以便用户更快使用本系统，同时保证工程少出偏差，保证工程质量。

1.1.2

软件质量保障措施

软件质量保障措施包括对项目资源的保障，对质量管理过程的保障和对产品质量的技术保障。

（一）对软件产品的测试

软件测试是对软件产品质量保障最重要的措施之一。

测试是评价检查质量目标实现的重要手段，过程如下：

软件质量评价过程与测试活动的关系如下图所示：

软件项目过程质量 篇3

【关键词】过程方法；软件质量管理；信息化；管理平台；设计；分析

在软件技术开发与软件设计应用中，最为关键并且重要的问题之一就是对于开发设计软件以及软件技术质量的保障与成本控制实现。近年来，随着软件技术与软件开发设计应用的不断发展进步，对于软件工程的研究发展也有了很大的进步，但是在软件技术质量保证与成本控制方面的问题一直没有很好的得到解决。基于过程的软件质量管理方法技术，就是在这样的发展背景与需求下，逐渐在信息化发展实际中进行应用实现的。基于过程的软件质量管理最早是由美国软件行业在上世纪80年代初期进行提出并应用的，它实际上就是将软件技术的改进发展与软件开发设计过程的改进之间同步进行与实现，通过对于软件技术开发与设计过程的控制，实现对于软件技术质量的管理控制，这样一来不仅对于软件技术和软件应用发展有着积极的作用，而且在一定程度上也推动了社会信息化的发展进步。

1.基于过程的软件质量管理与技术概述

1.1基于过程的软件质量管理含义分析

基于过程的软件质量管理通常也被称为是过程管理方法，对于软件质量的过程管理提出与实现，最早是由美国软件行业在上世纪80年代，以进入以过程为中心的软件技术以及软件产品的开发利用时代为标志。随着美国软件行业中以过程为中心的软件产品、技术的开发利用发展，基于过程的软件质量管理方法以及管理平台在实际开发应用中越来受到欢迎，并且基于过程的软件质量管理平台开发设计的相关要求准则等，也随之出现并发展起来。在对于基于过程的软件管理平台设计建立要求准则中，以美国CMM以及PSP、TSP管理平台的设计应用实现最具有代表性和意义。

通常情况下，对于基于过程的软件质量管理平台与方法中，过程一词多被解释为将输入方式转化为输出方式的一组相互关联或者是相互作用的活动。对于软件产品以及技术的设计实现以及管理过程，又被按照一定的规律关联分解为软件工程过程以及软件管理过程、软件支持过程等三大过程类型。其中，软件工程过程主要是指软件产品以及技术的开发、生产、设计实现过程，包含对于软件技术与产品的需求分析以及编码设计、系统测试等过程步骤；而软件管理过程主要是指对于软件工程的管理维护过程，包含对于软件产品、技术的开发、生产、设计应用等的管理以及维护实施等，比如对于软件开发项目的策划、跟踪监控以及质量保证管理过程等；最后，软件过程中的支持过程主要是指对于软件技术以及产品的开发、设计、生产利用进行支持的过程行为，包括对于软件产品与技术的评审以及培训、度量等过程。在软件工程开发设计以及应用管理过程中，建立相关系统平台，实现对于软件工程系统化与自动化管理控制实现，是在现代信息化发展情况下，进行软件质量管理的有效方法与途径措施。

1.2基于过程的软件质量管理技术概述

在应用过程管理方法，对于软件质量进行管理实现的实际应用过程中，主要的软件过程质量管理技术有CMM软件过程质量管理技术以及PSP、TSP软件过程质量管理技术等，此外，还包含ISO9000系列的软件过程质量管理应用技术，以及IEC15504要求标准下的软件过程质量管理技术。

其中，CMM、PSP以及TSP软件过程质量管理应用技术，是由一家软件工程研究机构研究提出的基于过程的软件质量管理系统模型平台。CMM软件过程质量管理系统模型平台主要是在对于CMMI系统模型结构与人力资源管理思想理念、以及软件开发生产技术、产品相互融合的情况下，最终形成一个完整的CMM管理系统与体系，实现对于软件质量管理过程中的人与技术、管理过程三个方面的管理控制实现。而ISO9000标准系列的软件过程质量管理技术一种由国际标准化研究组织研究提出的通过过程方法实现对于软件工程质量管理的技术方法，它在许多国家和地区的信息化发展中有广泛以及普遍的应用实现，尤其是在政府以及工业发展、信息技术研究领域的应用实现更为突出。

2.基于过程的软件质量管理在信息化中的应用分析

2.1信息化过程中的软件质量管理问题

随着社会信息化的不断发展，信息化发展过程中出现的矛盾问题也越来越多，比如信息化的建设发展各自为政、信息化重复建设和信息化建设成果垄断等问题，在信息化发展的过程中越来越突出。作为社会信息化建设与发展的重要基础和核心部分，软件的开发利用以及发展不仅对于社会信息化的建设发展有着重要的影响作用，更是对于国家生产力水平以及综合实力情况也有着很大的影响。

根据社会信息化发展与软件质量管理的情况来看，目前，在信息化发展过程中，软件质量的管理也存在着一定的问题，首先表现在对于软件质量管理的意识比较缺乏，软件质量管理的重视程度不够。其次，在社会信息化发展过程中，对于计算机软件产品的开发设计与利用过程中，过分重视对于软件技术产品以及项目的开发设计进度、数量等问题，而忽视对于软件产品质量以及软件开发设计过程的控制管理。再次，在进行软件技术以及产品的开发设计过程中，所运用的软件产品与技术的开发设计质量管理体系相对比较落后，并且对于同一个软件产品与技术的开发设计转包现象比较严重，通常存在有多个软件开发方，这对于软件质量的管理以及软件开发的发展进步都十分不利。最后，在进行软件质量管理过程中，缺乏有效的软件质量控制管理体系，也是信息化发展中软件开发设计与管理中的重要问题，如下图1所示。

2.2基于过程的软件质量管理在信息化中的应用

在社会信息化发展中，基于过程的软件质量管理方法，就是通过对于软件需求过程以及软件设计过程等的质量控制与管理实现，同时对于软件的编码以及测试、维护等，基于过程质量控制管理的方式，实现对于软件质量的控制管理实现。具体质量控制管理方式如上图2所示。

首先，在基于软件质量控制管理的软件需求过程的质量管理中，应注意从对于客户管理以及目标控制、需求范围的控制、需求筛选等方面，进行软件需求过程的质量控制与管理实现，保证软件技术与产品的质量。其次，对于软件设计过程的质量管理控制，主要就是根据软件需求分析情况，对于软件总体结构的设计过程与质量进行控制管理，以实现软件过程设计的目标。再次，对于软件编码过程中质量控制管理，主要是通过对于软件编码的过程进行规范，以及做好相应的软件编码代码审查、单元测试的控制与管理；在软件测试过程中，做好软件的单元测试以及集成测试、系统测试三个部分的测试，并对于测试过程进行控制管理，保证软件测试过程质量符合要求。最后，在进行软件产品以及技术的维护过程中，应注意针对不同的软件维护类别，对于软件技术与产品进行改进，以满足客户对于软件产品的需求。总之，基于过程的软件质量管理，就是要结合软件技术以及产品开发设计实现的过程，对于过程方法进行控制管理实施，从而实现对于软件产品的质量管理。

3.结束语

总之，质量管理是企业管理工作中的关键与重要内容部分。而基于过程的软件质量管理更是现代软件质量管理的重要趋势方向，进行方面的应用分析，具有很大的必要性与重要性意义。

【参考文献】

[1]王可平，陈阳，柳园园.软件测试管理自动化解决方案与实践[J].指挥信息系统与技术，2010（4）.

[2]杨建强，吴育材.基于RFID技术的辣椒制品质量管理系统设计[J].计算机光盘软件与应用，2011（14）.

[3]赖伏虎，陈少英，洪嘉铭，裘以冰，赵淑媛.基于Web2.0技术的病案质控信息化探讨[J].中国卫生质量管理，2009（1）.

[4]岳宏，王艳军.信息化技术在护理质量管理中的作用[J].医疗装备，2010（5）.

[5]王青，李明树.基于SPC的软件需求度量方法[J].计算机学报，2003（10）.

软件项目过程分析 篇4

1 技术架构

技术架构可重可轻,它将直接涉及到安装运行环境,从而影响到软硬件成本,同时对项目组成员要求不同,从而影响项目进度,由于主流.Net和J2EE架构中,J2EE灵活性高,以下以J2EE平台进行架构考虑。

如果系统同时在线用户数目不大,操作方式不复杂(不会涉及远程调用,服务器集群,异步消息处理),项目规模不大(数据库结构表数目在100个以下),就一定不要使用EJB,也就是不要把Application Server引入。如情况相反,则往往需要应用系统分层实现策略。分层是实现一个健壮的复杂的现代软件系统的前提,一般的系统都必须考虑数据持续层、业务实现层、请求控制层和显示层。理清这个层次结构有助于设计阶段制定架构的实现,从而保证整个系统的结构清晰。以下是可供参考的策略。

1.1 数据持续层

当前数据库大都是关系型数据库,在面向对象设计语言下,使用O/R Mapping工具好像是很自然,如果架构中使用了Application Server,大家自然的选择是EntityBean,其容器事务管理方面确实很大优势。另外一个比较好的持续层方案是JDO和Hibernate工具,他们都支持通过POJO(Plain Old Java Object)进行O/R Mapping。他们实际上只是一组Java Class的工具类,不需Application Server支持。O/R Mapping技术在项目规模比较大的情况下,可以大大减少一个对象增删改的SQL语句数量,加快开发速度和质量,但对于小型项目却未必需要考虑,完全可以使用一个SQL执行工具完成访问数据库工作,Apache下开源项目Common里有个DbUtils就是一个好选择,所有SQL语句可以写在一个文本配置文件里,便于修改。

1.2 业务实现层

在使用Application Server时,毫无疑问使用Session Bean处理业务,同时为每个Session Bean提供一个Business Delegate是一个不错的设计,为客户端隐藏调用细节。在轻量级情况,就用普通Java Class就可以了,业务层的设计主要在于相似业务的重用,一般做法把一些可重用方法提取到基类,例如得到数据连接,执行查询SQL和没返回的SQL,关闭数据连接,可以为各种类型的数据库操作在基类提供方法,而具体业务子类只要使用这个基类方法即可。

1.3 控制层

控制层负责接受请求,校验访问权限,调用业务对象,保存结果,分发视图,如果在大项目里,建议使用Apache下的Struts框架,当要注意合理使用,有必要进行合适的扩展。但不管是否使用Struts作为控制层框架,基于MVC的实现必须有如图1这样的思路。

Business是业务实现,Action负责提取请求中数据以适应Business的接口,读取结果以合适的结构返回给客户,运用Command模式进行设计,SecurityManager负责访问控制,同时对Action池进行管理,提高性能。而控制器Controller就只要按需要从池里面取适当的Action执行其Run方法,然后Forward到某个视图,一个Jsp页面,View再把结果显示给用户。

1.4 显示层

显示层的任务是显示数据,不关心数据的取得过程,视图关心如何显示,一个布局页面,这个页面Include具体特定视图是一种好的设计。特定视图显示风格需要统一,可以提供封装特定形式的显示代码,如表格,文字环绕风格等,提供如分页等公共功能组件。

以上架构将在后续设计实现阶段不断细化,直至完成一个架构基线。

2 开发过程规范

开发过程规范或模型,例如,瀑布开发模型,快速开发模型,迭代开发模型,甚至是极限编程。项目的开发过程规范的衡量标准有一个有利于,即是否有利于项目进展,任何软件过程制品都要经过这个标准检验。如果不是有利于项目进度,如果不能帮助推动项目进度,一概不做。基于迭代的开发模型是许多现代开发模型的核心,其适应性很强,是值得推荐贯彻的过程思想。由于软件一步到位基本是不可能的,为了应付各种变化,只能步步为营,做多少算多少,知道多少需求就实现多少,同时最快地反馈给最终用户,所以上面提到选择一个灵活的架构和优秀的设计是非常重要的。以下是一个基于迭代开发思想(XP和RUP等快速开发模型都基于这样思想)的实用的软件过程建议。

2.1 项目需求

客户提供部分或者调研部分,可以详细整理,理出条条框框最重要,需求分析过程是针对特别的需求进行分析,对于一些普通的增删操作,不用做大量文档,需求分析结果要求出文档有:Key Abstract或者说叫Domain Model类图,罗列所有可能的对象和关系,由此一般可以映射到数据库设计。面向对象软件开发是以对象驱动的,所以Key Abstract类图是非常重要的。接下来的其他制品,如数据库设计,页面设计,都将依赖于他。在需求分析阶段,页面设计工作应该同步进行,页面设计结果可以作为原型(Mock Up反馈给软件客户。

2.2 项目设计

设计阶段进一步细化我们的核心类图,和数据库设计,给出复杂业务的相关流程图和文字描述。在这个阶段,架构设计必须已经提前完成,架构设计一般是取一个简单但能涉及到系统各个部位技术的业务。一般数据库系统,用户登陆管理是一个好的选择,因为用户登陆涉及数据库操作,会话管理,权限管理,从页面到数据持续都会涉及到。然后详细设计和实现这样一个业务,这个设计和实现就被当成是其他业务设计和实现的样板,是为架构基线。架构基线一般都是第一次迭代时完成的,架构基线里将会产生很多通用类库,很多抽象基础类,以提供其他业务实现使用,所以架构基线历时会比较长,而且必须经过严格测试。可以说当架构基线完成后,其他业务将可以在此基础上大大加快速度。

2.3 项目实现

实现阶段主要规范的是代码风格,文件,类,方法命名约定,同时保证没有脱离给定的架构实现。同时单元测试代码应该随着实现的完成而产生,比如在Main函数里写针对该类的方法测试代码是好的选择。

以上是迭代过程模型的一次迭代过程,一般控制一次在两周左右完成,架构基线迭代周期可以长一些,而且也不要刻意追求每次迭代的过程阶段完整性。

3 质量保证规范

质量保证规范有很多借鉴的标准,如ISO CMM,但在现实中往往只要借鉴一部分就可以了,质量保证的核心内容是配置管理和Review评审。配置管理中首先选择一个合适的版本控制服务器,CVS绝对值的推荐。然后是代码的管理,规划好目录结构是很重要的,这个工作常常被忽略,目录结构树能让人马上找到自己想要的,所有与项目有关的资料都该在这个目录下,这个目录除了源代码外还应该包括:文档,运行测试环境。特别提一下源代码目录的规范,一般是按模块分文件夹,再在子文件里按架构的层次分,比如web、Controller、model、ado、EJB等,文件夹不要用大写。

编写一个编译脚本非常重要,虽然开发工具都带编译调试功能,但编译脚本可以方便实现自动化编译,而且不依赖于开发工具。例如C的Make,java可以用ANT,不需要很多时间学习,却可以大大提高项目配置管理的质量。基于编译脚本就可以要求小组成员每天上班checkout代码,然后运行脚本,每天下班必须Commit修改的代码然后update得到最新代码再编译,项目build工程师可以在一定时间运行脚本,发布一个milestone的版本,同时给CVS打上tag,提交给测试人员。这些就是所谓Nightly Build过程,Milestone Release。Milestone版本可以直接提交给客户,让其提供最直接的反馈,以实现项目在可控可见的范围内进行。甚至可以在合同里跟客户约定milestone,跟客户的费用支付直接挂钩,这样可以大大降低风险,也可以让客户完全有信心,保证项目不会偏离客户需求。这就是持续集成,XP极限编程的精髓所在。

软件质量保证的核心应该就是Review,包括代码Review,文档Review。每个制品(文档或者代码实现)产生后,必须经过第二者或者第三者的评审,评审主要是文档是否表达足够清晰,是否符合小组习惯格式。代码实现主要是看代码实现是否符合技术架构的框架,是否重用了公共方法,代码句法是否是符合规范,注释和可读性是否符合要求。Review保证了技术框架不会因为功能越来越多而变得越来越乱,越来越偏离其既定规范,而且代码评审也常常能够发现一些很隐蔽的Bug。

4 小结

本文总结了一个J2EE项目开发过程,汇集了一个项目中会涉及到的各方面的知识,希望可以为一些新组建的项目组提供参考。项目中遇到的情形往往各有各不同,而采取的应对方法也可以不尽相同,保持项目管理的灵活机动始终是重要的。既要坚持一个稳定的项目开发制度,又不能教条地遵守种种规则。

参考文献

[1]覃征.软件项目管理[M].北京:清华大学出版社,2004.

[2]Jalote P.Software project management in practice.北京:清华大学出版社,2005.

[3]张青.软件项目工程管理[M].成都:电子科技大学出版社,2006.

[4]郭宁,周晓华.软件项目管理[M].清华大学出版社,2007.

软件项目过程质量 篇5

为加强病案首页填写质量控制，拟引入病案首页填写过程质量监测系统。具体要求如下：

一、根据国家卫计委的病案首页质量填写标准及HQMS、卫生统计等病案首页信息上报平台的要求，系统需要具有比较完备的、由相关专家研发制定的、针对病案首页填写项目的逻辑矫错知识库，并能不断完善、升级。

二、系统需要与医院使用的海泰电子病历系统对接，在医生填写病案首页时，正式提交之前进行逻辑校验，并提示错误项目及内容，矫正后方可提交。确保病案首页填写的完整性、普通项目逻辑校验的正确性。

三、系统具有可持续发展、不断更新升级的能力。

四、系统可根据医院需求，完成定制设计，并将医院定制设计的内容加上“太和医院”的标志，确保医院的知识产权。

浅谈展会项目的过程质量管理 篇6

按照PMPBOK的定义，项目质量管理是为了确保项目达到客户所规定的质量要求所实施的一系列管理过程。包括质量规划、质量控制和质量保证等。而对于展会而言，由于商业展会属服务类产品，而服务又不同于一般商品有明确的质量标准，展会的质量管理主要分为两种：展会效果，服务质量管理和展会管理过程质量管理。鉴于本文主要探讨的是对展会过程的管理，因此展会效果、服务质量管理在此就不再做阐述。

由于展会提供的是一种服务，其运作过程不涉及任何生产制造、物流与库存这样的环节，仅以项目相关人员的文字工作、沟通工作等形式实现任务的执行和完成，由此，我们可以引入过程质量管理模型来实现对过程的质量控制和改进。这一模型是基于这样的假设，即展会主办机构记录了他们的远景、使命和关键成功因素(CSF)。有了这些档案，就可以将驱动展会的过程识别出来，并可以用评分分级系统和CSF联系起来。在这一分级系统下，对每个展会过程评定一个从A(优秀的)到E(原始的)等级。首先，我们将展会中涉及的过程加以罗列、编号和评级，并将CSF也加以罗列和编号，然后识别哪些过程影响哪些csF并用x做出标记。

根据汇总按照评级来识别出亟待改进的过程包括P2(评级最低)、P1、P5、P7、P8、P9、P12(评级次低)，分析这一结果就能识别需要改进的地方以及思考如何改进并按照重要性对这些改进进行排序，从而优先处理亟待解决的部分。

现代质量管理的一项基本准则是：质量是规划、设计出来的，而不是检查出来的。因此，展会质量管理关键的两步骤：

1前期进行质量规划。考虑到展会的周期特性以及同类可比性，通过采用基准对照的工具，以历史数据作为参考系。设定一套度量标准，ID纵列代表需要质量控制的过程，等级纵列列出历史数据并增加一列“质量标准”纵列以及“实际等级”表明需要达到的质量等级和当年实际实施等级，以便在过程执行中，对各项过程严密监控和质量核对。

需要补充的是，各过程实际等级评定需要再细分为子过程，并在对子过程加权平均后得出该过程的评级，例如财务控制。

通常，也可使用其他质量规划工具，帮助更好地界定情况并有助于更有效地规划质量管理活动，这些工具包括集思广益、关系图、立场分析、名义组技术、模块图、流程图和优先排序矩阵等，这里就不再做介绍了。

2实施质量控制。监视项目的具体结果，确定其是否符合相关的质量标准，并判断如何杜绝造成不合格结果的根源。由于展会不同于普通商品，它有严格的时间限定，因此质量控制更多的需要预防可能出现的偏差以及在出现偏差之始及时纠偏。如以P3展会招商、宣传为例，通过整理历史数据，可以图表的形式，反映出各个月份的展会招商、宣传过程下销售子过程的情况。

软件项目设计过程管理探讨 篇7

1.1 软件设计过程的内涵

软件的设计过程是指软件工程人员为了获得特定功能与性能的软件产品, 而在一系列软件的支持下所进行的软件开发工程活动。简而言之, 软件设计过程就是将需求转变为软件表达的过程。

那么如何将需求转变为了软件表达呢?这里首先要明确的是什么是需求。这里所说的需求, 主要包含功能需求和性能需求, 在一些特定的软件项目开发过程中, 可能还需要进行数据需求的分析。只有明确了软件系统的功能需求、性能需求和数据需求, 才能够有针对性地进行软件项目的开发设计。其次, 还需要明确的是软件设计过程一般分为两步, 第一步是初步设计。所谓初步设计就是将之前所分析的软件系统的性能需求、功能需求和数据需求转换为数据表或者软件框架只有确定了数据表或者将软件框架, 才能够在此基础上进行有针对性的特定功能开发与实现;第二步是详细设计。所谓详细设计, 就是指将之前所建立起来的数据表和软件框架, 逐步求精和细化, 最终实现软件系统所要求的功能或者性能转变为具体的数据结构或者软件算法, 而且其中每一个细化过程中出现的数据结构或者软件算法, 都需要配以合适的软件界面进行显示, 以提供良好的人机交互桌面, 并且要将软件界面和数据结构、软件算法时刻保持统一, 以提高软件项目的整体一致性和系统性。

1.2 软件设计流程

要想做好对软件项目的过程管理, 首先必须明确软件的设计流程。因此, 这里首先对软件项目开发的流程进行简要分析。

软件设计过程一般很难用文字语言表述完整清楚, 目前也没有统一的表达能够说清楚软件开发的过程, 但是结合以往的开发经验, 现在的软件工程师都已经清楚认识到, 目前开发出来的支持数据流图、层次式输入输出结构图等相较于传统的流程图能够更加精确、清晰地反映出软件项目开发的需求和框架细化精确的层次步骤。

概括来说, 软件设计的一般流程可以分为以下几个步骤:

(1) 需求分析。首先需要对软件系统进行需求分析, 正如上文所分析, 需要进行功能需求分析、性能需求分析和数据需求分析。

(2) 子系统分离。在明确系统需求的基础上, 需要对整个软件系统进行子系统的划分, 只有对一个大型软件项目系统进行合理的分割, 甚至是分割成若干软件算法或者数据结构等, 才能简化软件设计系统的复杂性。

(3) 层次优化设计。为分割后的每一个子系统进行层次设计, 并且需要明确不同子系统之间的层次关系, 为各个层次之间的数据流进行导向设计。

(4) 软件框架结构设计。根据系统的层次关系, 确定软件系统的框架结构, 并在此基础上确立数据表的结构, 为整个软件系统的功能实现和数据表达奠定技术基础。

(5) 数据表设计 (包含算法设计) 。结合系统的功能需求, 为数据表达设计合适的算法, 既要实现系统指定的功能, 同时还要满足系统的相关性能要求和质量验收标准。

(6) 界面设计 (包含操作设计) 。为整个软件系统设计合理的人机交互界面, 包括人机操作交互设计及其操作响应的设计, 都包含在此步骤中。通过界面设计完成数据表达和软件算法的外封装, 将封装接口留给用户自行使用或者进行二次开发。

(7) 整体测试。根据所设计的软件框架结构、数据表结构、软件算法以及界面操作功能, 结合系统需要实现的功能需求和性能需求, 对整个软件进行白盒测试与黑盒测试, 确保整体质量达到预期的设计要求。这里需要说明的是, 设计阶段的测试主要是功能性单步调试, 需要待软件整体功能完成后才能够进行各功能的单元测试及系统集成测试。

2 软件项目设计过程的管理建议与措施

2.1 对软件项目的进度、质量和成本进行全过程跟踪管理

软件项目开发最在乎无非是项目的进度、质量和成本, 因此要实现对软件项目的过程管理, 就必须以软件项目的进度、质量和成本作为突破口, 对软件项目的进度、质量和成本实施全过程监控管理, 才能够实现对软件项目的全过程管理。具体来说, 对软件项目的进度、质量和成本实施全过程监控管理, 可以从以下几个方面着手:

2.1.1 合理设置软件项目的里程碑标志

按照软件开发计划的进度安排, 为软件项目的开发进度设置阶段性里程碑标志, 也可以进一步细化为大里程碑和小里程碑。确定了里程碑, 软件开发的每一阶段也就确定下来了, 可以依据每一阶段的软件开发, 为软件项目配备合适的人力资源、软件开发资源以及必要的技术支撑等, 就能够按阶段实现软件的开发设计工作。按照软件开发计划的进度, 细化分配到每个编程人员软件模块完成时间表。由项目负责人监督项目进度, 并与开发小组上报的日报、周报进行核对, 及时更正项目进度偏差。倘若由于某一环节时间发生偏差, 项目负责人也可以对里程碑适当进行调整, 从而保证进度管理的灵活性, 也从另一个方面保证软件项目开发的质量。

2.1.2 进行阶段性单元测试

为了保证软件开发的质量, 需要在开发的过程中进行阶段性测试, 包括功能测试、性能测试、容错测试以及安全测试等等。这里所说的阶段性测试主要是指单元测试。要按照软件设计开发的进度进行相应的单元测试, 因为每一阶段都有不同的测试内容和测试目的, 应该在软件开发设计的相应阶段之前就确定好测试的手段、方法以及相关测试报表。如果测试成功, 则可以顺利进入到下一里程碑阶段;如果测试失败, 则应当详细分析导致失败的原因, 指出功能测试或者性能测试的缺陷, 同时完成测试报表, 以供后向通道的测试。如有必要, 应当对系统发生失败的测试项目逐条语句进行单步调试, 直至完成阶段性测试。

2.1.3 对软件开发费用进行控制

一般而言, 当软件系统的功能需求和性能需求分析完毕后, 只要确定好系统的里程碑标志, 即可确定软件系统开发的相关资源, 严格来说软件系统的开发成本基本也已经明确了, 因此对于软件开发的可预见性成本的控制是不难的, 关键是在开发过程中, 需要对一些不可预见性的成本开支进行严格控制, 如设计更改、人员调整等等, 这些因素都有可能导致软件系统开发的成本大幅上升。因此, 软件系统的成本管理重点是要控制不可预见性的成本费用。

项目经理或者项目负责人正确的决策是减少项目不可预见费用的重要因素, 错误的决策会导致项目部分返工, 甚至于项目方案变动, 造成人力物力的浪费。

2.2 对软件设计过程进行监理, 重在沟通

过去软件系统的开发过程管理存在着一个误区, 就是重管理轻监理。在这样的管理方针下, 很多软件工程师在实际开发设计过程中会感觉束手束脚, 最后不是质量打了折扣, 就是开发周期一拖再拖, 管理效果差强人意。因此, 要加强对软件设计过程的管理, 就必须改变这一传统的管理手段, 对设计过程重在监理, 强调沟通, 发挥效率, 真正为软件设计的过程去服务, 而不是去管理。

沟通主要包括跟用户进行沟通和开发团队内部的沟通。开发团队与用户沟通在需求分析阶段要做到最大可能的到位, 用户方的技术人员和用户方的高层在需求理解上经常会不一致, 在项目开发过程中会提出需求变更或者添加功能需求, 用户方的高层之间也会有不同的意见。因此正确全面地把握用户需求, 才能做出最正确的决策, 拿出最经济有效的方案。

开发团队的沟通管理重在监理, 对软件设计过程的人力、周期、质量、资金等等进行监理, 当发生偏差时就进行自上而下的沟通, 再自下而上进行信息反馈, 这样既不会束缚软件工程师的手脚, 同时对于软件设计本身而言, 其质量、进度和成本在经过有效的沟通和反馈之后, 依然在项目管理轨道上行进。

需要说明的是, 这里强调的沟通并不是指出现问题, 大家坐下来讨论问题出现的原因, 然后提出解决的办法和措施, 这样无疑是耽误了软件设计的周期。这里所强调的沟通, 实际上是指当监理人员发现软件设计开发过程中某一指标或者某些指标发生了偏离, 与项目协调员或者项目专员进行沟通, 由项目专员与软件工程师进行沟通协调, 在进行设计的过程中实现自下而上及自上而下的双向信息流通。

2.3 对软件设计过程中产生的设计文档严格要求, 对开发过程记录严加管理

软件设计过程中产生设计文档、记录, 必须按照软件工程开发规范, 与实际的代码一一对应。一套高水平的规范文档, 可以将在项目中的开发人员由于各种原因离岗带来的项目进度损失、人力资源损失都记录在内, 这样新来的开发人员看着文档就可以接替这个岗位的工作。对软件设计开发过程实行文档管理, 不仅仅是为了防范岗位接替带来的损失, 更重要是依靠完善的文档管理, 能够对软件开发设计过程中的任意一个环节都可以进行回顾、监测;在强调弱化管理、加强监控的软件过程管理模式的同时, 只有依靠文档管理, 才能够最终实现对软件开发设计过程细致入微的管理。

2.4 软件设计模型选取和注意项目积累

开发团队在经过一段时期的开发后, 有了一定项目经验和技术积累。当新的项目需求与以前的项目需求很接近时, 可以采用原型法开发, 列出需求变化的部分和新增的功能、要删掉的功能, 这样可以沿用前项目的开发文档 (当然要根据项目修改) 和开发方案、思路、技术, 进行快速有效的开发。新开发的项目成功后又可以作为以后项目的原型, 这也是软件构件重用的基本思路, 这样能够利用积累下来的软件模型、程序代码和开发经验, 实现高效的组装式的软件开发程式, 大大降低后续软件开发的出错率, 极大地提高后续软件开发的稳定性与可靠性。

2.5对软件设计过程中的部分软件功能模块化以供复用

软件模块复用是软件快速高效开发中经常用到的, 对某特定行业、特定需求, 特别约定俗成的软件功能需求尽量提出来设计成软件模块。将软件开发设计重复使用的一部分称之为软件构件, 这是近几年来逐步盛行的一种高效、低成本的软件开发模式。重复使用某一软件构件, 首先需要明确该软件构件定义中所使用的技术标准和规范, 倘若连技术标准语规范都无法明确, 那么很难保证利用该软件构件开发出来的软件具有全局统一的技术规范, 从而软件的可靠性也无法得到保证。因此, 确定构件使用的技术标准与规范, 对于软件构件的应用也是基础技术保障。

3结束语

软件的开发设计已经逐渐成为第三产业中越来越重要的分支, 同时软件开发设计水平也标志着一个国家的计算机自主知识创新能力和水平。因此, 我国目前也逐步加大了对软件产业的投资, 从目前全国各地普遍兴建软件产业园就可以看出软件产业的强劲发展势头。要想做大做强软件产业, 质量是关键, 管理是根本。因此本文详细探讨了软件项目开发的过程管理, 给出了具体的过程管理建议与措施, 对于进一步提高软件开发设计的过程管理水平具有较好的指导借鉴意义。当然, 更多的软件过程管理措施还有待于广大软件工程师在实际开发设计过程中共同努力才能够最终得以落实, 并实现我国软件产业的快速、健康发展。

参考文献

[1]王长峰.IT项目管理案例与分析[M].北京:机械工业出版社, 2008.

[2]唐毅鸿, 杨朝晖, 刘倩羽.软件性能工程[M].北京:机械工业出版社, 2003.

[3]张文清.软件开发过程项目管理的研究[D].北京:首者经济贸易大学, 2005.

[4]吴吉义.软件研发中的项目质量管理过程研究[J].微型机与应用, 2007 (6) .

高校软件项目开发过程管理 篇8

进入21世纪, 随着软件工程学科的发展, 人们对软件开发过程管理的认识越来越深刻。管理是影响软件开发项目全局的因素, 而技术只影响局部, 许多问题不是出在不懂怎么做, 而是没有安排好, 做的次序不对, 或不知道如何做得更好。有效的软件过程管理, 有助提高软件的开发效率和生产质量, 降低生产成本。

目前软件开发深入各个领域, 高校作为国家重要的科研基地, 承担了大量的软件开发任务。高校软件开发组织不同于常规意义上的软件开发组织, 在软件开发过程上有其自身的特点和要求, 企业中已应用成熟的软件开发管理方法并不完全适用。为了适应这种特点, 必须结合高校实际, 对企业中软件开发过程管理方法做出适当的更改和调整。

1、高校软件项目开发的特点

高校软件项目开发多由教师和学生组织成临时团队协作完成, 其主要特点如下:

1.1 创新性强、研究性强, 项目难度大。

高校所涉及的软件项目, 和一般企业不同, 多属于前沿性的研究课题, 探索成分较多, 软件开发过程中, 需要查阅大量文献, 即时关注国内外研究动态, 软件需求经常变化, 修改较多。

1.2 开发团队成员新手多、人员流动大、管理经验欠缺。

教师和学生是高校软件项目开发的主力, 他们虽然有较好理论水平, 但实践经验非常不足, 对软件整个生存周期的管理体会不深, 管理意识薄弱。

1.3

高校软件开发项目和企业相比, 对于开发成本、用户意见、进度等方面的控制不如企业那样严格。

1.4 高校软件项目开发过程中, 经常会忽略测试阶段的工作。

开发人员的兴趣多集中在功能的实现上, 而对软件运行的性能关注不多, 预先测试工作很少, 这就造成事后不得不耗费大量力气去弥补。

2、高校软件项目开发的过程管理改进

基于上述特点, 笔者结合实际, 根据自己的实践工作经验, 对于高校软件项目开发过程的管理, 提出如下改进措施:

2.1 团队管理

团队管理要有纪律性, 分工明确, 责任清晰。可基于项目开展工作, 尽量采用扁平化的组织结构, 角色简洁, 不必要的角色设置及时删除并做优化调整。

2.2 文档管理

高校软件项目开发团队往往是基于某个课题成立的临时组织, 流动性大, 文档管理的不完善非常不利于知识的流动和传播。CMM作为软件过程管理的工业标准, 它的各个关键过程域对于文档的要求都严格细致, 高校软件项目开发过程中, 引入C M M过程规范可以有效保证文档管理的完整规范性, 但CMM管理复杂, 实际应用中, 需适当裁剪, 具体来说, 可以在开发的各个阶段设置几个结束点, 在这几个结束点上, 编写严格的规范的文档书写标准, 在结束点之前, 流水帐一样记录下所做所想, 将有关信息用更自由方式记录保存, 在某个阶段结束之后, 花一定时间来创建和对文档格式化, 只保留关键节点的文档, 从而有效节省文档开发工作量, 提高工作效率。

2.3 计划管理

项目启动之前, 应有大致实施计划。项目实施过程中, 项目负责人要不断对照原有计划进行工作调整。高校软件项目开发需求变更频繁, 同时, 软件开发自身的难度大复杂性大等特点也要求计划制订时不能跨越太长时间段, 要立足当前, 逐步推进, 逐步细化。高校软件项目开发在时间性上的要求要比企业弱一点, 要保证有充足时间完成研究过程, 但这并不是说高校软件项目开发就无时间限制, 在开发过程中, 可每隔两周进行一次小会讨论, 制订未来两周内详细的研究开发计划, 并对未来三个月内的工作做粗略规划, 下次计划的制订要紧密结合上次计划完成情况, 及时调整。

2.4 开发过程管理

在开发工作具体开始之前, 要制定详细的开发工作流程, 高校软件项目开发流程主要包括下面几个阶段:需求分析、系统设计、编码测试、收尾四个阶段。

2.4.1 需求分析阶段管理

和企业不同, 高校软件项目开发的需求除部分来源于客户需求, 更多的, 则来源于一些研究性课题研究的需要。这也导致高校软件项目开发的需求分析管理和企业有很大不同。高校软件项目开发的需求包括问题求解和需求确定两个部分。问题求解部分主要的工作是构思的形成、构思的筛选和概念的形成与评估, 其中, 牵涉大量国内外文献的研究和综述, 在构想确立的过程中要经常开会讨论, 由专家对构想进行初步评估, 全部审核通过后, 需由负责人撰写详细的问题求解报告, 在此过程中搜集整理的资料随同报告分类保存。需求确定阶段则针对问题求解报告, 编写详细的需求计划书, 有条件的情况下, 可采用一些快速开发工具针对需求设计开发原型, 开发原型应包括核心功能和关键难点的实现, 设计尽量的简单, 不求完善, 软件原型的设计可帮助预测需求的合理性, 以最快的速度得到需求反馈。需求分析书在最初设计时并不要求过分细致, 要抓住重点, 力求简单易懂, 在最终文档交付之前, 可进行多次迭代开发以尽可能的减少实际开发中的更改。

2.4.2 系统设计阶段管理

通用的建模工具如U M L可帮助进行系统整体设计。系统的分析报告应包括以下几个要点:系统整体的功能模块框架体系, 系统中的用户权限分析、系统整体运行流程和系统的数据结构构建体系, 此外, 还应包括关键难点的技术实现可行性。良好的系统设计可有效降低编码过程中的返工问题。

2.4.3 编码和测试阶段管理

高校软件项目开发中编码阶段, 最大不足是代码编写不规范, 变量函数的命名各成体系, 没有正式标准, 注释部分描写不清, 这就造成代码可读性差, 严重降低代码重用性。高校软件项目开发的另一大不足是对测试重视不够, 这就很难保证软件产品的质量和性能。结对编码对改善上述不足有很好效果, 由两人结对进行代码开发, 一人负责代码功能的实现, 另一人负责代码的可读性和运行的正确性和完善性。这样可有效提高代码编写速度, 使编写者更有信心, 同时可保证未来代码运行的正确性, 发现问题及时修改, 避免把所有问题积累到最后再做处理。在此阶段, 文档书写可以少一些, 关键部分有记录即可, 但代码要书写规范, 语句尽可能的精简清晰, 可读性可理解性要强。源代码的管理也是该阶段的一个重要工作, 常用的配置管理软件, 如CVS等可有效控制和管理版本的更改变动, 全过程配置管理, 有利于项目内统一的编码、测试, 保持一致性。

2.4.4 收尾阶段管理

在团队解散前, 收尾工作要做好, 整个过程中的文档和最终软件成果指定专人整理归类, 为后续开发和维护打下良好的基础。

2.5 跟踪管理

在软件项目开发过程中, 项目负责人的角色很重要, 要及时跟踪团队资源变更情况, 跟踪项目执行的范围和进展情况, 确定未做的有多少, 已完成的有多少。

2.6 培训管理

高校软件项目开发中, 可依据实际采用内外部培训、自我培训、专家指导等多种形式。培训内容要按具体情况展开, 一般来说, 新人培训应该包括组织内部已经形成的制度和纪律, 软件文档编写约定, 软件开发流程中的各项验收和管理标准, 团队的组织结构角色分工, 除此外, 可结合具体项目制订项目入门的快速指南。通过共同分析项目的目标和管理规范的必要性, 使分配的任务得到新加入的开发人员的认可, 有利于工作积极性的调动。

2.7 支持开发全过程的网络管理平台的构建

在有条件的情况下, 建立基于网络的软件开发全过程的协同工作平台可有效帮助提高软件开发过程的管理, 特别是对高校软件项目开发来说, 可在一定程度上解决开发团队缺少固定时间地点所造成的沟通缺失, 更好的保管归类开发过程的文档, 方便查询, 同时使团队成员对开发过程中的规范性有更深刻的理解。

3、结语

总之, 高校软件项目开发过程管理, 需从自身固有的特性出发, 一方面, 要逐步建立和完善规范化的管理模型, 另一方面, 在实际操作上, 要从现有环境和条件出发, 在项目不同阶段、不同团队和不同模块采用灵活多样的方法, 以期获得最佳的实践效果。

摘要：高校软件项目开发具有创新性强、变更频繁, 开发人员新手多、管理经验欠缺、流动性大等特点。其过程管理, 既要参照软件企业常用管理方式保证规范性, 同时又需结合自身特性赋予更多灵活性, 在开发的各个阶段, 需采取多种方式综合管理, 以平衡各方效益。

关键词：软件开发管理,敏捷管理,软件过程改进

参考文献

[1]张海藩.软件工程导论 (第五版) [M].北京:清华大学出版社, 2008

[2]萨默维尔, 程成, 陈霞.软件工程 (原书第8版) [M].北京:机械工业出版社, 2007

[3]唐俐威.软件开发的敏捷管理方法研究[D].哈尔滨:哈尔滨工业大学, 2006

应用软件过程质量分析和控制 篇9

关键词：软件过程,软件质量,模型,方法

1 引言

中国经济和社会发展处在重要的战略机遇期。中国政府提出要以信息化带动工业化,以工业化促进信息化,走以科技为先导的新型工业化发展道路。信息产业成为国民经济的基础产业、支柱产业和先导产业。信息化是一项复杂的工程,而应用软件处于整个信息化的顶层,涵盖整个信息系统工程的应用部分。信息化建设中无论是网络建设还是服务器配置,最终的目标还是为了应用软件的应用,应用软件是整个信息系统工程的最终表现形式,并最终实现用户的业务目标。所以,应用软件实施的成功与否,直接关系到信息化的成功,应用软件才是信息化建设中的重中之重。

应用软件的建设一般是周期长、知识密集、高风险的系统工程,其复杂性既由于技术的复杂,又由于协调的复杂,而且当两者结合起来以后,其复杂性就尤其突出。应用软件的实施重点就是保障软件的质量,而应用软件的质量是最难衡量的,首先,应用软件是知识密集型的脑力劳动,由于每个人的能力不同,导致了软件的质量无法简单的衡量;其次,软件最终的形式是一些程序代码,由于业务流程繁杂,而且容易受运行环境的影响,所以不能通过一般简单的感观评估的方法进行质量保证;最后,应用软件开发是一个系统的过程,最注重过程的质量保证,如果问题在最后时刻发现,往往项目已经与事无补。所以,如何有效的保障应用软件的质量一直是一项复杂的课题。

2 应用软件的过程质量分析

由于应用软件的复杂性,分析软件的质量,首先要分析软件开发的过程,建立软件过程的质量模型,然后才能对应用软件的过程质量进行控制分析。由于目前的软件的开发模式很多,如线性顺序模型(The Linear Sequential Model )、原型实现型模型(The Prototyping Model)、快速开发模型(Rapid Application Development Model)、渐近式软件开发模型(Evolutionary Software Process Model)等模型,各种开发模式的不同,导致应用软件的开发过程也存在差异。所以,如果分模型进行软件的过程分析,是非常复杂的。幸好ISO(国际标准化组织)为我们定义了通用的软件工程生命周期,来适应不同的开发模型。在软件工程生命周期中,开发过程如图1所示。由于他是一个通用模型,我们可以在这个模型的基础上分析应用软件的过程质量。

从图中我们可以分析软件过程把软件质量的形成过程分成如下几个阶段:

(1)软件需求分析阶段。这是软件开发过程中最重要的内容,他是应用软件质量的开始,也是应用软件质量的基础,

(2)软件设计阶段。本阶段包括软件的结构设计和软件的详细设计。他决定了软件开发的程序框架,同时,他也要与软件的需求相对应,所以也是应用软件质量控制的重点。

(3)软件编码和测试。本阶段包括应用软件的编码过程和软件的单元测试过程。他最直接的影响软件的质量,同时,单元测试也是后面其他各种测试的基础。

(4)软件集成和软件合格性测试。本阶段主要进行软件模块的组装,同时,对软件各模块之间的功能进行测试。所以,本阶段决定了各模块之间是否能协同工作的质量。

(5)系统集成和系统合格性测试。本阶段主要是对软件在真实环境下的运行情况进行测试,以保障软件质量,以适应他运行的环境。

(6)软件验收。本阶段主要是对软件进行验收,从整体的角度对软件进行分析和评价。

从模型中,还有系统需求分析和系统结构设计阶段,这个过程由于是涉及到系统级的需求分析和系统级的结构设计,超出了本文研究的应用软件的范围,所以本文暂时不对他进行分析。但系统需求分析和系统结构设计对整个系统的质量有很大的影响,尤其是大型系统内各系统的接口、数据资源共享问题,所以,系统需求分析和系统结构设计对系统质量的形成是非常重要的。

针对应用软件质量的形成过程,我们对软件质量的控制主要体现在过程中的质量控制,同时,我们在建立应用软件质量的过程控制模型时还需要考虑质量控制的成本,必须在最关键的地方建立质量控制。所以,我们建立应用软件质量的过程控制模型如图2所示。

控制模型分析如下:

(1)软件需求分析阶段:主要的质量控制手段包括需求过程质量保证,需求评审。

(2)软件设计阶段:主要的质量控制手段包括设计评审。

(3)软件编码和测试阶段:主要的质量控制手段为软件的单元测试。

(4)软件集成和软件合格性测试阶段。主要的质量控制手段为软件合格性测试。

(5)系统集成和系统合格性测试阶段:主要的质量控制手段为系统合格性测试。

(6)软件验收支持阶段:主要的质量控制手段为软件验收测试。

3 应用软件质量的过程控制指标分析

形成应用软件质量的过程控制模型后,需要具体的对过程控制指标进行分析,具体指标分析如下:

3.1 应用软件需求分析阶段

本阶段是软件开发过程的起始阶段,是后面各个阶段的基础,所以本阶段的质量要求非常高。具体手段包括需求过程质量保证和需求评审。

需求过程质量保证主要控制点包括:总体计划是否合理,是否有配置管理计划、需求调研工作计划。调研过程是否按计划进行,调研方法是否合理,是否有调研问题跟踪记录、需求变更流程是否完备,需求是否用户确认等。

需求评审主要控制点包括:需求文档是否描述了详细的功能与能力规格说明,包括性能、物理特性和软件项执行的环境条件。是否描述了验收需求、安全需求、数据需求等内容。是否描述了用户文档、用户操作与执行需求、用户维护需求、易用性需求等内容。另外,需要评审需求文档是否与合同有可追溯性和一致性,与业务目标和系统建设目标是否一致等。

3.2 应用软件设计阶段

设计阶段是关系到后面开发质量的重要环节,同时,他也起到承上启下的作用,即把用户的需求与真实的程序语言关联起来。设计阶段重要的质量控制手段就是应用软件的设计评审。主要分析的内容包括与软件需求的可追溯性和一致性,所采用的设计方法和标准的适宜性;后期开发、运作与维护的可行性等。

设计阶段在进行设计评审的过程中,除了运用和需求评审一样的审核手段外,还有一些技术手段来进一步确定软件设计,主要如表1:

3.3 软件编码和测试阶段

本阶段的质量控制手段主要是软件单元测试,软件单元测试的对象是可独立编译或汇编的程序模块。单元测试在开发阶段后期同步进行。软件单元测试的目的是检查每个软件单元能否正确地实现设计说明中的功能、性能、接口和其他设计约束等要求,发现单元内可能存在的各种差错。

软件单元测试一般应符合以下技术要求:对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试;每个软件特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖;测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值;在对软件单元进行动态测试之前,一般应对软件单元的源代码进行静态测试;语句覆盖率达到100%;分支覆盖率要达到100%;对输出数据及其格式进行测试。

3.4 软件集成和软件合格性测试阶段

本阶段的质量控制手段主要是软件合格性测试或者软件集成测试,测试的目的是检验软件单元之间、软件单元和已集成的软件系统之间的接口关系,并验证已集成软件系统是否符合设计要求。

软件合格性测试一般应符合以下技术要求:软件要求的每个特性应被至少一个正常的测试用例和一个被认可的异常测试用例覆盖;测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值;应逐项测试软件设计文档规定的软件的功能、性能等特性;应测试软件之间、软件和硬件之间的所有接口;应测试软件单元之间的所有调用,达到100%的测试覆盖率;应测试软件的输出数据及其格式;应按设计文档要求,对软件的功能、性能进行强度测试。

3.5 系统集成和系统合格性测试。

本阶段主要进行系统集成,所以,本阶段的软件基本成熟,需要通过系统合格性测试(系统测试)对软件的质量进行全面的检验。

系统合格性测试一般应符合以下技术要求:系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖;测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值;应逐项测试系统/子系统设计说明规定的系统的功能、性能等特性;应测试软件配置项之间及软件配置项与硬件之间的接口;应测试系统的输出及其格式;应测试运行条件在边界状态和异常状态下,或在人为设定的状态下系统的功能和性能;应测试系统访问和数据安全性;

本阶段的质量控制由于是对整个系统的检验,所以,一般根据质量特性的要求,对不同的实际问题应外加相应的专门测试。具体的测试内容如表2所示。

3.6 软件验收阶段

本阶段主要目的是让用户确认软件的质量,所以,验收测试也成为交接软件前的最后一道质量保证手段。验收测试的目的是在真实的用户(或称系统)工作环境下检验完整的软件系统是否满足软件开发技术合同(或软件开发任务书)规定的要求。质量手段几乎同系统合格性测试,只不过由用户来实施,侧重点更注重业务的测试。

4 结论

综上所述,通过应用软件质量过程控制的分析,我们可以得到应用软件过程质量控制的手段和指标。通过实施过程控制手段,可以有效的保证软件的质量。当然,本文提供的只是一个软件过程质量的通用模型和通用的指标,对于具体的项目,需要剪裁使用,如小项目可能只选取比较关键的指标和控制手段,对于大项目或对某方面(如安全)要求比较高的软件,可能还需要在此基础上添加一些控制点。总之,只有通过应用软件质量的过程控制,才能保证软件的过程质量,才最终保证软件的整体质量。

参考文献

[1]冯惠,王宝艾,韩红强.GB/T8566《信息技术软件生存周期过程》新版标准说明[J].信息技术与标准化,2006,(08):40-44.

[2]ISO/IEC12207-1995,Information technologe-Software life cycleprocesses[S].

[3]赵晶华,苏秦.软件需求变更过程质量管理及控制初探[J].计算机应用研究,2004(07):31-33.

软件项目过程质量 篇10

1.1 核心思想及模型框架

RUP可以适应小型软件项目开发的需要,但在小型项目中成功应用RUP的关键是剔除不需要的工件,选择合适的工件子集并保持这些工件非常简明。开发小型项目的时候,可以从RUP出发,并结合敏捷软ARUP结合了RUP严谨周密的过程框架和灵活多样的敏捷过程的思想,在整体框架上遵循了RUP的分阶段逐步演进的主导思想,在成本控制与核心实践上继承了敏捷方法的思想精髓。ARUP既是利用敏捷思想对RUP过程的适当剪裁,也是利用RUP思想对敏捷过程的合理扩充。ARUP是以用户为中心,需求驱动,小增量迭代,快速满足变更的有序的开发过程。

1.2 角色设计

ARUP软件开发过程的角色设置如下:①项目负责人;②客户代表;③系统分析师;④系统设计师;⑤系统开发人员;⑥系统测试人员。

ARUP最突出的特点是把客户纳入到软件项目的主要人员里面来,专人专职。项目开发中各种活动的执行需要担任不同角色的人员进行分工合作,一个角色可以包括许多人员,一个人也可以承担不同的角色。在ARUP中定义的角色,在实际开发中可根据需要在其中进行选择。

1.3 里程碑与过程阶段设计

根据RUP的软件过程框架并结合敏捷方法的特点,将ARUP的软件生命周期分为4个阶段:系统规划阶段、详细设计阶段、迭代开发阶段、产品交付阶段,分别对应4个里程碑:规划里程碑、详细设计里程碑、初步可使用里程碑、产品支付里程碑。生命周期模型如图1所示。

(1)规划阶段。是ARUP生命周期4个阶段中的第一个阶段,主要目标是确定项目的可行性,确定项目成功的核心与关键点并确定项目的范围,这一阶段主要沿用RUP的初始阶段的主要活动,并且要求在规划阶段不求面面俱到,抓住重点,抓住主要矛盾,对项目范围以及项目整体形成清晰的认识。规划阶段有4个主要任务:①确定系统的概貌及主要参与者;②确定系统的主要功能点;③模拟实现一个最为可行的体系结构解决方案(原型);④对系统的成本、进度等作出评估。

(2)详细设计阶段。详细设计阶段是ARUP生命周期的第二个阶段。详细设计阶段的目标是确定并创建系统体系结构的基准线,为系统生命周期的后两个阶段建立稳定的基础。在详细设计阶段要完成下面3个主要的任务:①更加深入细致的描述系统用例;②确定系统体系结构并建立体系结构的基线;③进一步精确费用预算和项目进度。

(3)迭代开发阶段。迭代开发阶段是ARUP生命周期的第三个阶段,迭代开发阶段的主要任务是通过详细设计、实现以及测试来充实一个完整的系统。要达到此目标,我们为ARUP过程设计了如下重要的实践环节:①根据系统的架构基线设计安排项目组人员;②建立完善的配置管理体系;③保持系统体系结构的稳定性;④按照需求的优先级制定迭代计划;⑤描述剩余的用例以及其他用户需求;⑥采用重构策略完善设计;⑦加强单元测试和集成测试;⑧频繁交付并不断反馈。

(4)产品交付阶段。产品交付阶段的主要目标是确保软件基本上满足用户的需求,圆满完成用户制定的系统功能。具体要完成的任务如下:①系统测试;②培训用户和维护人员;③完成产品验收测试,向用户交付产品;④通过得到的经验改进未来的项目。

2 ARUP的实例研究

2.1 项目背景

长沙邦创公司自动化办公系统是一个基于该公司内部网络环境的办公系统,提供了公司内部所有办公人员利用该系统进行文件发布、信息共享与传递、信息管理。项目开发时间3个月,属于典型的小型项目。

2.2 第一次迭代

规划阶段,拥有的主要工件有:一个经批准的业务案例、风险清单、初步项目计划、项目验收计划(其接受的标准是直接由客户做出的)、精化阶段迭代计划、初始用例模型。系统设计师在精化阶段,根据.net开发的特点决定采用多层软件架构。

根据系统软件架构的复杂程度选择构建阶段用到的开发工具.在精化阶段建立了测试环境并且开发测试,系统开发过程中使用的自动化测试工具为N Unit。在这个阶段中经过客户调研,确定了粗粒度的业务模型并通过了复审。

实际开发过程中,精化阶段只用了一周时间。最终,精化阶段产生的主要工件包括:粗粒度业务模型、软件构架文档、构建过程迭代计划;构建阶段,项目经理根据精化阶段的用例模型,确定第一次迭代要完成的功能。然后建模员建立系统模型,将各个要实现的构件组织成包。各个包中是详细的构件设计,每个构件由1个或多个类构成,整个系统模型是以“类—构件—包”的形式设计组装的。实施员根据系统模型进行代码编写和测试,构建阶段在第一次迭代过程中用了4周的时间,经过2次小的迭代。在构建阶段的迭代过程中产生的主要工件为业务模型和系统模型、构件、部署计划、产品化阶段迭代计划。

产品化阶段的重点是部署,部署最终在客户方完成。软件开发过程必须集中处理向用户发布高质量软件的所有必需活动,这个阶段中,构建软件的工作远远多于编写代码的工作。

2.3 第二次迭代

在经过了第一次迭代后,下一个迭代即第二次迭代过程中可以采取同样的步骤。经过使用第一次迭代的系统后,发现存在以下问题:①界面操作不方便;②应提供安全的网上数据传输;③对于输入数据的一些格式需要加入一些提示,减少用户输入的出错几率。

把这些作为第二次迭代的目标,进行第二次迭代。界面的改变由客户、开发人员、设计人员共同来完成,直至达到客户的要求为止。增加的新功能按照第一次迭代中的过程,重新进行开发。

2.4 实例开发总结

本系统开发过程以ARUP为指导,采用了两次迭代完成了项目。在项目成功交付后,做了一些统计及总结工作,并与另外一个2005年初采用结构化生命周期法开发的项目相比较。其中,有4个人同时在这两个项目中进行开发。如表1所示。项目于2008年8月4日启动,在2008年11月7日交付第一个版的可用系统。与其它阶段相比,构建阶段花费了更多的时间。这种情况通常发生在一开始并不清晰需求,需要在项目期间不断澄清的项目中。经比较可以看出,采用ARUP开发项目可以缩短开发周期并减少开发人员工作量。

3 结束语

RUP和敏捷软件开发方法的目标对象和适用环境各不相同,在理解其精神实质和基本原理的基础上灵活运用,根据项目和团队的实际情况剪裁出适合的过程体系,对团队生产率和产品质量有显著的影响。ARUP是RUP和敏捷软件的适当结合,它采用迭代式开发,吸收了RUP过程中设计与文档的特点,又遵守了敏捷软件开发中的快速开发、重构、测试驱动开发等原则。一方面适合了小型软件项目开发的实际情况,不必使开发者陷入过分设计而导致开发进度缓慢的困境,最终达到进行快速、和谐开发系统的目的。

参考文献

[1]Rational软件公司.Rational Unified Process[EB/OL].[2000-02- 20].Http://www.rational.com.

[2]Abrahamsson P,Salo O,Ronkainen J,et al.Agile softwaredevelopment: review and analysis[EB/OL].http://www.inf.vtt.fi/pdf/publications /2002/P478.pdf,2006-03-18.

[3]孙晓阳.RUP在中小型软件项目开发上的应用[D].长春:吉林大学学位论文,2004.

全过程软件开发质量管理 篇11

软件开发是个系统性工程, 瀑布模型的软件开发过程包括需求分析阶段, 设计阶段, 编码阶段, 系统测试阶段和beta测试阶段。

软件需求分析是软件产品开发生命周期的第一个阶段, 需求分析的任务就是解决“做什么”的问题, 就是要全面地理解用户的各项需求, 并准确的表达所接收的用户需求。软件需求分析的输出是需求说明书。需求分析在不同阶段, 面向不同的读者输出不同类型的需求说明书, 分别有市场需求说明书, 包需求说明书和系统需求规格说明书。

2 面向不同的读者输出不同类型的需求说明书

需求说明书需要具备完整性, 准确性, 一致性, 无歧义性和可验证性。需求完整性要求要包含所有的功能性需求和非功能性需求。需求分析人员要和用户充分沟通, 了解用户的业务场景、业务范围、业务逻辑以及用户对软件的使用预期。需求分析人员可能还需要施加适当的需求引导, 有些用户对于软件的一些特性, 比如一些性能特性, 软件规格, 软件运行环境要求等等缺少认识, 需求分析人员需要主动和用户确认这些问题。

需求准确性要求需求分析人员捕获的需求要和用户期望一致的。实际上需求一次做充分、准确很难, 软件产品如果能快速做出原型, 基于原型和用户再沟通, 往往能起到较好效果。另外, 需求的准确性还要求在需求编写过程中要避免使用“等等”, “各种”这些泛指词汇, 对需要软件支持的多种特性需要明确枚举, 或者准确界定范围。

需求的一致性指不同的功能描述需要保持一致。需求一致性首先至少需要逻辑上保持一致, 另外良好的需求应该对类似的业务处理保持一致的处理接口和顺序, 使得整个系统形成一个有机整体。

需求的可验证性是指要求的功能需求或者非功能需求指标是可测试的或者可衡量的。不可验证的需求是没有意义的。可验证性要求需求的各种指标避免出现“国际一流”, “国内领先”这种主观词汇, 指标需要量化描述。

需求无歧义性是指需求表达是明确的, 含义是唯一的。即便需求理解正确, 但编写的需求说明书可能还会有歧义, 一方面可能是人员本身语言组织问题, 另一方面也在于自然语言本身具有多义性, 所以在开发系统需求规格说明书时, 可以采用UML这种图形语言, 能较好消除需求歧义性。

3 软件架构和设计

需求开发完成以后, 根据需求要求进行软件架构和设计。软件设计根据设计的层次不同, 分为架构设计, 概要设计和详细设计。

软件设计决定软件产品的结构, 层次, 模块划分和逻辑接口。软件设计要考虑软件的“可用性”、“健壮性”、“可扩展性”、“一致性”以及“安全性”。“可用性”要求按设计实现的软件产品是满足基本业务需求的, 这是软件设计的最基本要求。“健壮性”需要考虑软件运行时的容错处理、异常处理。在软件运行出错时能有自我修复能力, 并且需要保证尽可能不影响用户的正常业务。“可扩展性”要求设计要考虑软件后续可能的需求要求, 这有个“度”的权衡。考虑“可扩展性”既不要过度设计, 把一些遥远的, 理想的, 可能根本不会去实现的需求考虑进去, 无谓增加了设计的复杂性;也不能做一天和尚敲一天钟, 设计的软件结构无法较好适应需求的变化。软件设计的“一致性”体现两个方面, 一方面是和需求规格能对应, 保持需求可追溯;另一方面软件设计包括的三个层面设计接口上需要保持一致。“安全性”是指在设计阶段就需要考虑软件的安全问题, 在软件结构上和规范上需要避免引入安全漏洞。总之, 良好的软件设计应该是结构清晰、逻辑分明的。软件设计虽然比较复杂, 设计人员需要有一定的积累和知识, 但好在软件行业已经发展这么多年, 先辈们也积累总结了若干软件架构设计的方法和模式, 比如软件架构的4+1视图法, 若干设计模式。软件设计要学会利用好这些成熟的方法和模式。

4 软件编码

软件编码是对软件设计的代码实现。软件编码要求开发人员使用某种或者几种计算机语言, 按设计规定的结构和逻辑实现需求说明书规定的功能特性。实践说明编码阶段是引入缺陷最密集的阶段, 做好编码阶段质量控制意义重大。可以从如下几个方面对编码质量进行控制:

(1) 代码规范。软件开发是个团体协作过程, 需要一个统一的规范来约束大家的编码风格一致。编码规范除了使提高代码可读性外, 也能规避一些常见的编码错误, 这对团队中的新手比较有帮助。

(2) 代码检查。代码检查传统方式是代码走读, 代码走读是在模块代码完成以后, 由其他一个或者几个同事一起和作者走读代码, 一般是作者给走读人员做代码讲解, 走读人员直接看代码分析是否存在问题。敏捷软件开发提倡的结对开发也是一种实时的代码检查方式。

(3) 利用代码检查工具。现在有些代码分析工具已经比较智能了, 能分析出多种类型的编码错误并支持多种编程语言, 不少工具也已经有较好的准确性。使用代码检查工具能极大提高效率。

(4) 模块自测。开发人员自测一般是白盒测试, 开发人员对模块代码逻辑清楚, 有能力设计各种测试用例以覆盖代码各个分支。对模块进行自测也是对开发人员的基本要求。

(5) 集成测试, 也称组装测试或者联合测试, 开发人员各自负责的模块完成以后, 按设计的业务数据流程验证各个模块之间的接口。

5 软件产品开发过程中的测试阶段

完成编码以后, 进入软件产品开发最后一个阶段测试阶段, 测试阶段可细分为系统测试阶段和beta测试阶段。

系统测试是指在企业内部的测试环境中模拟实际用户场景进行测试, 执行系统测试的角色一般是独立的测试人员。从心理学上分析, 开发人员和测试人员测试的目的是不同的, 开发人员做自测和集成测试是为了验证软件的正确性, 而测试人员相反, 测试的目的是为了发现软件的错误。所以这两种测试都是必要的, 互补的。需要注意的是, 系统测试的依据是需求说明书, 一般是参考产品包需求说明书和系统需求规格说明书。系统测试直接目的是保证软件产品符合需求说明书要求。

系统测试需要注意测试的全面性, 测试需要有个全面的指导性文档, 这个文档叫测试大纲, 测试大纲规定了测试需要覆盖的范围和衡量指标, 测试大纲根据需求说明书来来编写。测试大纲的内容需要覆盖需求说明书里规定的功能性需求和非功能性需求, 保证系统测试的完整性。

系统测试需要先编写测试用例, 测试人员测试需要严格按照测试用例进行测试, 避免测试的随意性。测试用例需要覆盖测试大纲里规定的测试内容。设计测试用例有几种方法:

(1) 等价类分法:等价类分法是将测试空间划分成若干个子集, 并且满足每个子集中的任一数据对揭露程序中的缺陷都是等价的, 这些子集就叫做等价类或者叫等价子集。通过对测试空间划分等价类并针对每个等价类设计测试用例, 能保证在有限的测试用例情况下尽可能覆盖所有可能的测试空间。

(2) 边界值法:是一种补充等价划分的测试用例设计技术, 它不是选择等价类的任意元素, 而是选择等价类边界的测试用例。采用边界值法的意义在于:通过长期的测试工作经验总结, 大量的错误是发生在输入或输出的边界上。

(3) 因果图法:是一种利用图解法分析输入的各种组合情况, 从而设计测试用例的方法, 它适合于检查程序输入条件的各种组合情况。

此外, 软件系统测试需要重视应用自动化测试, 特别是软件开发采用迭代开发时, 功能回归测试占用大量的测试投入, 而这类重复性测试是比较适合做自动化测试。自动化测试能很大程度上解放测试人力, 并且能保证每个测试软件版本基本功能得到充分测试。软件系统安全和业务安全近年来也越来越得到关注, 系统测试也需要考虑对软件产品的安全性测试。

软件产品在完成系统测试以后, 有的还需要进行Beta测试。Beta测试由软件的最终用户们在一个或多个客户场所进行, Beta测试是软件产品发布前在实际客户环境的一种验证。在Beta测试用户的选择一般要考虑客户环境要具备有典型性, 这样才能保证软件产品在不同的环境性得到有针对性验证。另外在客户关系方面也需要考虑, Beta测试的产品毕竟还不是最终的发布产品, 可能还存在一些缺陷, 需要客户关系比较好, 对产品缺陷有一定容忍度。

6 结语

总之, 在软件产品开发生命周期每个阶段都需要重视本阶段的质量控制, 在开发周期各个阶段的流转时, 对前阶段的输出结果可以做常规性评审, 阶段流转要有明确的质量要求, 在评审时需要评估符合要求后才允许进入下一阶段。严格的质量控制利于尽可能把质量问题都在本阶段发现和解决, 避免缺陷放大效应带来的人力和成本浪费, 从而提高软件开发效率, 开发出高质量并符合用户需求的软件产品。

摘要：质量管理是软件开发管理的一个重要方面, 软件开发过程缺陷具有放大效应。本文对瀑布模型软件开发各个阶段所进行的质量管理进行研究, 说明各个阶段应该进行质量控制的方法和目标, 通过全过程质量管理以实现软件产品开发的高效管理。

关键词：软件质量,全过程质量管理,缺陷放大,质量控制

参考文献

[1]李炳森.软件质量管理[M].北京:清华大学出版社, 2013.