软件过程改进

软件过程改进（精选12篇）

软件过程改进 篇1

随着社会的进步以及经济的发展, 软件的规模不断加大, 其复杂度也在不断提高, 导致软件的开发与过程管理困难重重, 软件项目出现成本超支、进度拖延以及质量较低等情况。就目前而言, 中小软件企业在软件过程管理中, 其存在一系列的问题, 如难以控制任务完成进度, 难以控制需求, 软件质量难以控制, 软件版本混乱等, 导致软件质量和交付受到严重影响, 降低了软件的满意度。为了有效改变这种现状, 中小软件企业对软件过程改进、管理以及规范等方面采取了辅助手段, 如CMM/CMMI认证、质量管理体系的建立等, 从而促进中小软件企业的可持续发展。

1 中小软件企业软件过程管理概述

1.1 中小软件企业特点分析

在我国软件产业中, 中小软件企业占据着较大的比例, 其主要特点是熟悉行业需求, 能够对优势业务领域加以有效把握, 执行力高, 管理快捷清晰, 组织结构简洁, 响应速度快等。但是中小软件企业也存在一定的劣势, 其具有较高的维护成本, 总收入中软件销售收入占据的比例低, 经验到制度的转化程度不高, 依赖性强, 制度约束力不高, 人员流动性高以及人力资源不足等。

1.2 软件过程概念

软件过程主要指的是软件开发人员在对软件以及相关的产品进行开发与维护时, 其形成的方法、实践、行为以及变化过程。一般在对软件过程进行管理时, 必须要确保软件产品的质量, 加强其开发与维护过程的质量, 将方法, 工具以及人员进行有机结合, 从而确保软件产品的质量, 提高管理的水平。

2 中下软件企业软件过程管理的改进方法

2.1 加强质量保证与配置管理

一个软件项目的配置项包括该项目的所有相关资料, 如安装程序、工具、代码以及文档等, 配置管理良好是保证软件一致性的重要前提。因此对配置管理进行合理计划, 并对配置管理软件进行恰当选择, 统一管理软件版本, 制定基线配置项变更控制流程, 能够确保软件开发与管理过程的合理性, 提高软件过程管理以及软件产品的质量。在改进软件过程时, 中小软件企业可以从以下几个方面进行考虑:一是在对软件进行测试时, 侧重于控制和检查软件产品的质量, 并且在保证质量的同时, 严格检查和控制软件过程。二是质量保证由专人进行, 从项目计划以及阶段成果等方面进行检测, 对质量问题进行跟踪和记录, 从而有效提高软件产品的质量, 确保产品质量的维护性以及延续性。

2.2 选择重点, 优先突破

在对软件过程进行改进时, 必须要对其重点领域进行选择, 循序渐进。由于软件过程改进是对现有的软件开发与管理过程进行改善, 这对于企业管理人员以及开发人员而言, 具有较大的难度。因此在软件过程改进过程中, 企业可以有针对性地选择改进重点, 逐渐突破, 从而确保软件改进过程的合理性以及科学性。此外, 从软件开发过程而言, 软件企业不同, 使得软件项目开发的过程也不尽相同, 在软件开发过程中, 其编码、设计以及需求等阶段受企业开发人员的综合能力、知识经验以及企业自身的技术水平的影响, 因此必须要对软件过程的相关部分进行重点选择, 有效突破。

2.3 加强自评估

中小软件企业为了保证软件过程的完整性以及规范性, 往往会对软件过程进行盲目改进, 无法对自身软件过程的阶段和水平进行全面清晰的分析, 导致实施的效果低下。因此, 中小软件企业在对自身的软件过程进行改进时, 必须要加强自评估, 有效采用某磐软件度量方法, 利用定量和定性相结合的方式, 提高软件过程状态的评价。此外, 中小软件企业可以在组织内部对岗位的人员进行不同选择, 确保全体人员能够参与到软件的评估过程中, 从而保证软件过程的合理性和准确性。

2.4 重视个体软件过程改进

开发人员作为软件企业中的主体, 其工作计划的恰当性、缺陷率、时间利用率和编码质量的高低等都会影响组织软件过程和软件质量。因此为了提高开发人员的工作效率, 确保软件过程的管理质量, 必须要重视个体软件过程的改进工作。一般个体软件过程具有完整的规程、表格以及方法, 其能够对软件开发人员的工作方式进行改进、管理和控制, 对开发人员计划、管理和度量自身的工作具有指导作用。个体软件过程改进能够对时间利用的情况进行记录, 从而有效掌握时间利用率以及工作的效率;同时能够利用管理缺陷, 有效控制软件缺陷, 并提高相关人员的工作能力。

2.5 合理利用辅助工具

一般而言, 软件过程管理及其改进在很大程度上属于管理的过程, 需要遵守一定的规则, 充分合理利辅助工具, 能够有效提高软件过程管理的水平和质量。就目前而言, 软件企业常用的软件类别包括缺陷管理工具、软件测试工具、配置管理工具以及项目管理工具等, 这些工具具有完善和强大的功能。因此企业能够从自身的实际情况出发, 对这些软件工具进行合理选择与利用, 从而提高软件过程管理的水平, 增强企业的综合竞争实力, 实现企业的可持续发展。

3 结束语

一般来说, 软件过程改进是一个循序渐进的过程, 中小软件企业必须要不断积累和丰富自身的经验, 对软件过程管理进行持续改进。同时, 中小软件企业在对软件过程进行管理和改进时, 必须要加强质量保证与配置管理, 选择重点, 优先突破, 加强自评估, 重视个体软件过程改进, 合理利用辅助工具, 从而提高软件过程管理的水平, 实现自身的可持续发展。

参考文献

[1]楚书来, 于文新.小规模软件企业软件过程管理与改进策略研究[J].黑龙江科技信息, 2012, 02:199-200.

[2]田丽从, 李铁牛, 彭宏.中小型企业软件过程改进方法研究[J].计算机应用与软件, 2011, 04:208-211.

[3]李楠.我国中小软件企业实施CMM改进软件过程的研究[J].中国城市经济, 2011, 26:129-130.

[4]马小龙.一种中小型软件企业软件过程改进框架研究[J].电脑与电信, 2010, 10:38-39.

软件过程改进 篇2

基于EVMS的软件过程改进

软件项目通常会遇到项目花费超出预算、项目完工日期拖延等问题而导致软件质量下降甚至项目失败,为了提高软件质量、减少项目风险,人们提出了一系列的项目管理方法,实绩价值管理系统EVMS(Earned Value Manage-ment System)就是由美国国防部和国家标准学会建立的一个项目管理系统.本文介绍了EVMS的.作用、历史、概念以及计算方法,最后结合软件过程改进的自底向上模型提出了软件企业应用EVMS管理项目的基本步骤以及组织关系.

作 者：赵昊翔 潘金贵 作者单位：南京大学软件新技术国家重点实验室,南京大学计算机科学与技术系,南京,210093刊 名：计算机科学 ISTIC PKU英文刊名：COMPUTER SCIENCE年，卷(期)：31(11)分类号：关键词：挣得值(EV) 实绩价值管理系统(EVMS) 自底向上软件过程改进模型

软件过程评审的轻量级实践 篇3

关键词：软件质量；评审；度量；持续改进

1引言

软件评审是软件质量管理中的关键一环，而在实际的评审过程中，常常出现因为参与评审的专家不能全部到位而在评审时拉壮丁，评审先变科普会、再变批斗會，以及其他一般会议中常见的如迟到、议题偏离等原因，导致评审会议效率不高。

如何提供评审的效率？以下跟大家分享软件过程评审的轻量级实践。

2评审定义

软件评审，是指在软件开发过程中，由参与评审的人员对软件开发文档或代码进行评审或检查，目的是帮助查找缺陷和改进点。

根据评审的内容特点，评审活动可分为管理类评审和技术类评审。

管理类评审：与管理相关的评审活动，如立项评审、项目计划评审、里程碑评审、结项评审等。管理评审方式包括：会议、会签、审批三种；

技术类评审：与技术相关的评审活动，如需求评审、概要设计评审、详细设计评审、代码走查、测试用例评审等。技术类评审主要方式为技术评审会议和组内会议两种方式。

3评审角色

参与评审会的主要角色：被评审人、评审组织者、评审组长、会议记录人、公司归档人。

评审组长一般由领导和专业负责人组成，评审组长需提供明确的评审结论。会议记录人一般由项目组内及组外（如测试负责人）两人承担，以上人员如有无法参加的情况，需指明代理人，代理人承担相应职责。

4评审流程

软件评审内容：

1）检验产品是否满足以前的规范，如需求或设计文档；

2）识别产品相对于标准的偏差；

3）向作者提出改进建议；

4）促进技术交流和学习。

下表为轻量级评审实践中总结的一页纸规程。

1）必须评审的阶段/文档：需求、设计。

2）评审项说明：需求须是需求说明书；设计包括原型设计，概要、详细和数据库设计说明书。

3）评审约定：文档以公司的组织财富库中的模板为基准。

4）主要参会角色：领导、专业负责人及项目相关人员。

5）所有参会人员须签到。会议纪要发送前需抄送给项目负责人及QA审核。评审组织者审核会议纪要时，需提供发现缺陷数、会议时间等量化数据，并负责将会议结论发送参会人员及抄送领导。评审结果为有条件通过的，需一周内修改完成再次发邮件给参会人员确认；对于评审不通过的，项目组须两周内发起复审申请。

6）对于评审发现的问题，会议记录人需跟踪问题状态直到关闭。

7）对于质量专委会工作中发现的典型事件，公司实行奖惩。

5评审要点

在评审时，对如下评审要点会重点关注，也往往在这些评审点更容易发现较多的问题：

1）使用了新技术，方法，工具的组件

2）关键的架构性的组件

3）难以理解，却又必须准确和优化的复杂逻辑或算法

4）具有危险失败模式的组件，而且是任务、可靠性、安全性关键的

5）具有多个异常条件或失败模式的组件

6）不易测试的异常处理代码

7）打算复用的组件

8）将作为其他组件的模型或模板的组件

9）影响产品多个部分的组件

10）复杂的用户界面

11）由缺乏经验的开发者创建的组件

12）具有高复杂度的代码模块

6结束语

对于智力高密集型的企业来说，最大的成本是人力成本。在评审实践中，我们还注重采用多种实际工具和手段，如针对阶段评审的注意积累检查清单；还有些评审是以在线的形式进行的，对于评审中量化项，可通过系统平台进行在线确认；对于代码评审，先利用一些业内工具进行预审；对于存在严整分歧的问题，会另外组织小型的专题会议进行讨论以便解决问题。通过以上轻量级的实践，提供人员利用效率，做好项目成本管控。

通过提高评审会的效率，不但确保了软件的质量，而且实施成本较低，在团队实施中非常容易推广。

通过提高评审会的效率，也加强了组织的度量，包括项目及项目团队的数据度量，为组织升级到CMMI4、CMMI5级的高成熟度奠定了数据和质量的基础。

当然，在以上的评审实践过程中，我们还在不断积累的评审专家信息、评审高风险点、评审度量项以及最佳实践场景等组织资产财富，为组织的持续改进保驾护航。

参考文献

[1]项目管理协会，《项目管理知识体系指南》，2009

[2]CMMI Product Team，《CMMI? for Development， Version 1.3》，2010

[3]Mark C. Paulk，《A Comparison of ISO 9001 andthe Capability Maturity Model forSoftware》，1994

作者简介：张萍，信息系统项目管理师，多年软件开发、质量管理经验，目前在福建国源通信技术有限公司南京分公司负责质量管理工作。

夏仲钟，多年项目管理经验，目前在福建国源通信技术有限公司南京分公司负责项目管理工作。

张坤，多年软件开发与设计经验，目前在福建国源通信技术有限公司南京分公司负责软件的设计和开发工作。

软件过程改进 篇4

软件管理工程的发展, 经历了从20世纪70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代, 到20世纪90年代中期, 以CMM模型的成熟和日益为市场接受为标志, 已经进入以过程成熟度模型CMM、个体软件过程PSP和团队软件过程TSP为标志的以过程为中心的时代, 而软件发展第三个时代, 即软件工业化生产时代, 以20世纪90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础, 已经渐露端倪。

1 小规模企业软件过程管理现状

1.1 小规模软件企业特点。

小规模的软件企业或软件开发机构的数量在我国软件产业中占据很大的比重, 其突出的特点主要表现在具有灵活机动、响应速度快, 组织结构简洁、管理清晰快捷、执行力高, 把握优势业务领域、熟悉行业需求等方面。但具备这些优势的同时, 兼具有人力资源不足、人员流动性高, 规范程度不高、制度约束度低, 对于人的依赖性较高, 经验到制度的转化程度较低, 软件销售收入占总收入的比重较低、维护成本较高等缺点, 这也是小规模软件企业在管理过程中不容忽视的重要问题。

1.2 小规模软件企业应对策略。

如何最大限度地避免这些问题的产生呢, 除了一些不能改变的客观因素外, 软件过程管理与改进策略研究在其中占得分量也越来越重, 也越来被人重视和研究。提升软件过程的管理水平日益成为工业界和学术界共同的关注点, 软件过程管理是提高生产效率和保证软件质量的一个重要方法。在产品开发的整个生命周期中包括一系列复杂的活动, 和其他管理过程类似, 现代软件过程管理工作也逐渐趋向复杂。根据企业的实际情况和发展需求, 优化流程, 努力提升人们在过程中的工作能力, 从而提升产品质量、提高生产率并降低成本, 这是软件过程改进的目的。

具体到软件过程来讲, 软件开发组织经常会遇到诸如项目经常会延期, 任务完成进度难以控制、开发人员不会编写和利用软件文档、需求难以控制, 疲于应付需求的变更、软件质量难以保证、软件版本混乱、没有有效的项目管理方法和实践指导等问题, 从而影响软件质量与交付, 引发客户抱怨, 满意度降低。针对普遍存在的这些管理与技术问题, 大多数软件开发组织已意识到应当在软件过程规范、管理、改进方面采取一系列改进措施和辅助手段, 如当前业界比较流行的建立质量管理体系、进行CMM/CMMI认证等。

1.3 我国小规模软件企业的现状。

目前国内专门从事软件开发的企业有数千家, 而这些软件企业主要以中小规模为主。根据有关统计数据结果分析, 主要组成结构为:50人以下的企业占55%;50~200人的企业占42%;1000人以上的企业为数不到3%。这些中小软件企业一般具有一些共同的特点, 这些特点将直接影响中小软件企业采取什么样的方式来实施软件过程改进活动。软件过程是指软件开发人员开发和维护软件以及相关产品 (如项目计划、设计文档、代码、测试用例和顾客手册) 的一套行为、方法、实践以及变化过程软件过程管理的重要前提是:软件产品质量的好坏主要取决于开发和维护该产品所使用的软件过程质量。有效的软件过程可将人员、工具和方法进行有机结合。作用对象:软件及其相关产品包括:活动、方法实践和革新。

2 软件过程管理及其改进策略

2.1 选择重点, 优先突破。

软件过程改进应选择重点领域, 循序渐进。因为软件过程改进是要在一定程度上颠覆软件企业现有的软件开发和管理过程, 因此对于已经习惯了固有的工作模式的项目经理、开发人员甚至是企业管理者来说, 大规模的改动相反会起到适得其反的效果。因此应该从企业的软肋出发, 逐渐突破, 在一些重点领域, 让企业尝到过程改进的“甜头”, 从而更好的推进组织级的软件过程改进。

从软件开发过程的角度来讲, 不同的软件企业都有不同的开发过程, 而且不同的软件项目也会采用不同的开发过程, 而开发过程中的需求、设计、编码等阶段, 较大程度上依赖于企业自身的技术实力和开发人员的知识、经验及综合能力。而软件过程改进的核心和重点在于管理, 因此本文建议将以下几个方面作为软件过程改进的重点领域。

2.1.1 注重项目计划与软件测试工作。

项目计划是项目成功的关键, 许多项目的失败都是由于计划制定得不合理或者计划执行不到位而引起的。项目计划应对项目进行合理的规模、成本、工作量等方面的估算, 正确的估算是制定项目计划的前提;根据项目自身特点与项目组人力资源状况进行一定粒度的分解。确保每项分解后的任务均可对应到相对比较适合完成这项任务的项目成员;项目任务要充分并行, 提高人力资源的利用率;计划安排应留有一定余地, 避免出现前松后紧的情况;面对项目计划变更应进行合理评估, 考虑到所有可能会受到影响的因素。

软件质量是软件企业核心竞争力的首要体现, 而软件测试则是软件质量的重要控制措施。规范软件测试过程, 将对软件质量的提高起到重要作用。软件测试应由独立的软件测试团队执行, 只有这样才能保证软件测试的公正与客观;软件测试计划应尽早制定, 软件测试应尽早进行, 软件需求确定之后, 就应该开始制定软件测试计划;软件缺陷应规范管理, 确保所有缺陷都分配到人;结合使用各种软件测试方法;不应忽视软件性能方面的测试与调优。

2.1.2 注重配置管理与质量保证。

一个软件项目的所有相关资料, 如文档、代码、工具、安装程序等均可作为该项目的配置项。良好的配置管理可以确保软件的一致性。而对于规模较大的并行开发项目来讲, 配置管理尤为重要。应做好配置管理计划, 选择合适的配置管理软件;对于软件版本进行统一管理, 确保多个开发人员协同开发不发生冲突;对于基线配置项的变更应制定变更控制流程, 使整个开发与管理过程可追溯可跟踪。

软件测试侧重于对软件产品的质量检查和控制, 质量保证则侧重于对软件过程进行质量检查和控制。产品和过程是一个软件项目成功的必不可少的两个重要因素, 其中产品质量是短期、项目级的影响因素, 而过程质量是长期、组织级的影响因素。质量保证也应由专门的人员进行;主要对项目计划、项目里程碑、阶段成果等进行质量检查, 记录和跟踪质量问题;质量保证人员可以由软件测试人员兼任, 以平衡人力资源的使用;质量保证人员应客观、公正的进行工作。对于以上四个过程领域的改进方法, 本文建议首先从建立规范人手, 然后在规范的实施过程中, 逐步进行修订和完善。一个规范通常由角色职责、工作流程、文档模板、工具支持等四部分组成:具有不同职责、权限的执行人员, 按照既定的工作流程进行相关的工作活动, 并将T作过程记录以文档的形式保存下来, 辅以一定的管理工具, 方可保证其工作产品的质量并使其具有延续性和可维护性, 这也正是建立规范的主要目标。同时, 在规范的范畴内, 所有人员遵循同样的行为准则, 能够更好的进行沟通。

2.2 结合优秀的软件过程元素。

CMM/CMMI是目前业界进行软件过程改进的首选模型, 其实CMM/CMMI已成为事实上的标准。世界各国的软件企业纷纷遵循CMM/CM-MI建立起软件过程规范, 积极进行CMM/CMMI的认证。然而如前文所述, 我国的中小软件企业未必适合完全按照CMM/CMMI来进行软件过程改进, 反而可以结合众多软件过程模型, 从自身的实践中总结出一套适合自己的软件过程改进模式。RUP (Rational Unified Process, 统一过程) 的迭代思想和XP (eXtreme Programming, 极限编程) 的测试驱动开发方法即可以尝试引用到企业当前的软件过程中来。

2.3 重视个体软件过程改进。

开发人员是一个软件企业组中最小的开发主体, 开发人员编码质量的高低、工作计划是否恰当、时间利用率的高低、缺陷率的高低等均会对软件质量以及组织的软件过程产生重要影响。因此, 个体软件过程 (PSP, Personal Software Process) 的概念被提了出来, 相应的也出现了个体软件过程改进这一概念。

PSP是一种用于控制、管理和改进软件开发人员的个人工作方式的过程, 它包含一套完整的方法、表格和规程, 用来指导开发人员如何计划、度量和管理自己的工作。个体软件过程改进可以首先从计划管理、缺陷管理、时间管理等几个方面入手, 同时可以配合任务检查单等工具。通过锻炼个人工作估算和计划能力, 提高对工作任务的驾驭程度;通过管理缺陷, 提高个人以及整个项目对于软件缺陷的控制程度;通过记录和分析时间利用情况, 来掌握工作效率以及时间利用率等方面的一些基础指标;任务检查单, 则可以与计划管理和缺陷管理搭配使用, 有利于个人工作任务的管理。

2.4 重视自评估。

软件企业经常会盲目地进行软件过程改进, 在没有明确自身软件过程处于何种阶段、何种水平的情况下, 贪大求全地建立了一整套软件过程规范, 而实施效果却差强人意。因此, 在进行软件过程改进之前, 以及在进行持续改进的过程中, 对自身软件过程进行自评估是非常必要的。软件过程自评估主要采用调查问卷的方式, 另外可以结合某磐软件度量的方法, 通过定性和定量相结合的方式, 形成当前软件过程状态的评价。调查问卷方式, 需要设计关于软件过程现状的调查问卷, 这些问卷可以是针对某个过程领域的, 也可以是针对整个软件过程的。然后在组织内部选择不同岗位的人员参与一次评估, 根据问卷调查结果, 得出相应的结论。

2.5 适当利用辅助工具。

软件过程管理与改进的本质是一个管理的过程, 管理就需要遵守规则。利用软件工具进行软件过程管理是软件企业普遍采用的方式。目前在软件企业应用较多的软件类别有项目管理工具、配置管理工具、软件测试工具、缺陷管理工具等, 这些工具一般都是针对某一个过程领域, 具有强大、完善的功能, 企业可以根据自身需要选择相应的工具进行辅助管理。但美中不足的在于, 适合于中小软件企业进行整个软件过程管理的轻量管理工具还不多见, 有些厂商的工具配置复杂、价格高昂, 令中小企业望而却步。

结语

软件过程改进不是一蹴而就的过程, 软件企业需要在不断的积累中持续改进。通过实践总结, 本文提出了几点通用的软件过程管理与改进策略, 旨在为我国中小软件企业的软件过程改进工作提供参考。当然, 对于每种策略的具体实施, 本文并未提出深入的方法, 如基于RUP、XP、CMMI等软件过程模型相结合的软件项目实践、PSP中的软件度量方法、软件过程管理与评估系统的试用与持续完善等, 均是我们下一阶段的重点研究和实践方向。

参考文献

[1]郭莹, 杨美红, 杨萍, 等.中小软件企业软件过程管理与改进策略[J].计算机与数字工程, 2009 (2) .

[2]刚家林, 崔巍.中小软件过程管理模型的研究[J].中国科技博览, 2010 (31) .

[3]闫振兴, 郑骏.软件缺陷度量与软件过程管理方法研究[J].计算机与数字工程, 2010 (8) .

[4]王海阳.软件过程管理及其成本的平衡[J].计算机系统应用, 2005 (3) .

[5]钱懿, 庄长远.软件企业过程管理支持系统的研究[J].电脑知识与技术, 2010 (1) .

软件过程RUP初探 篇5

韩瀛

(天津财经学院信息系 300222)

摘要：本文介绍了Rational统一过程(RUP)的主要内容，包括开发阶段、迭代过程和核心工作流等，并简要评述了其在软件项目开发中的优越及不足之处。

关键词：统一过程 里程碑

迭代 核心工作流

Abstract: This paper discuss the important contents of the Rational Unified Process, including Development Phase, Iteration Process, Core Workflows and so on. Additionally, giving some comments about its advantages and weaknesses in the software projects development.

Key Words: Unified Process, Milestone, Iteration ,Core Workflows

一 前言

软件过程是指实施于软件开发和维护中的阶段、方法、技术、实践及相关产物(计划、文档、模型、代码、测试用例和手册等)的集合。行之有效的软件过程可以提高开发软件组织的生产效率、提高软件质量、降低成本并减少风险。目前市场上领先的`软件过程主要有RUP(Rational Unified Process)

、OPEN Process和OOSP(Object-Oriented Software Process)。

RUP具有较高认知度的原因之一恐怕是因为其提出者Rational软件公司聚集了面向对象领域三位杰出专家Booch、Rumbaugh和Jacobson，同时它又是面向对象开发的行业标准语言――标准建模语言(UML)的创立者。RUP是由

Objectory过程演化而来，其初始版本为5.0，先后经历了5.1、5.11、5.5等版本直到最新的Rational Unified Process版本。本文主要讨论RUP的主要内容和特点。

二 RUP的二维开发模型

RUP

可以用二维坐标来描述。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone);纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)

浅谈软件工程过程模型的选择 篇6

关键词：软件工程；技术开发；模型

中图分类号：TP311文献标识码：A文章编号：1007-9599 (2010) 13-0000-01

The Choice of Software Engineering Process Model

Tan Changgeng,Yan Lin

(Software Institute,Central South University,Changsha410013,China)

Abstract:This paper describes several common software engineering process model,such as the waterfall model,spiral model,prototype model,concurrent development model.For the model selection should be based on standard software as defined by the process,refer to specific projects with the characteristics and resources of the state.

Keywords:Software engineering;Technology development;Model

随着软件技术的不断创新和发展，越来越多的软件系统逐步被提出来，软件工程化管理的思想已经应用于开发实践过程当中，一些软件工程模型也相继被提出。软件工程过程模型是一种策略，这种策略是由软件工程师在具体的实践工程活动当中设计并提炼出来，能够覆盖软件过程的基本阶段，确定设计的方法、过程及工具。

一、瀑布模型

1970年，Royce提出了第一个软件过程模型——瀑布模型。它属于线性顺序模型，结构简单、清晰，适用于需求较为明确的情况，包括软件的需求分析和设计、代码生成测试及维护。但是瀑布模型没有反馈环，难以完善和满足用户的需求；另外对于一些中小型项目，设计和开发人员往往在项目的初期便投入全部资本，没有制订每个阶段合理的资金投入计划，造成了人力资源闲置的现象。虽然瀑布型模型有很多亟待解决的问题，但是这种模型方式仍旧是最基本、最有效的可供软件开发生命周期的模型。瀑布型模型的过程严格按照需求—分析—设计—编码—测试的步骤进行，每个阶段都要定义明确的产出物及验证准则。瀑布模型在每个阶段完成以后都能够组织相关的评审以及验证，只有评审通过后方可进入到下一阶段。正是由于每个阶段需要验证，瀑布模型则要求每个阶段必须具有明确的文档产出，每个阶段都不能重叠。瀑布型模型的优点表明了它仍旧可以保证软件产品具有较高的质量；保证提前发现和解决存在的缺陷；保证软件系统在整体上具有充分的把握，从而保证系统具备良好的可维护性和扩展性。

这里需要说明的是，很多人由于进度约束而不去选择瀑布模型，这是错误的观点。造成这种现象的主要原因是在概念需求阶段的人力不足。如果能够保证人力充足的情况下，瀑布模型和后来出现的迭代模型在开发周期上没有明显的差别，反而是瀑布模型更适合于相许的需求，这种为了赶进度而在前期不明确的情况下，没有经过整体的构架设计便开始编码，容易导致后期出现大量的返工，从而严重影响进度。

二、螺旋模型

螺旋模型遵循了瀑布模型的模式，随着项目成本的逐渐增加，风险性则逐渐减小。有利于已有软件的重用，有助于把软件质量作为软件开发的重要目标，主要适用于开发的大规模软件项目，包括对制定计划、实用工程，风险分析和用户评估，主要缺点是对于风险评估比较困难。

螺旋模型较为复杂的地方在于对项目尽责、专心及知识渊博的管理。针对每一次的迭代，都要制定出非常清晰地目标，分析出关键风险和可以在计划中验证、测试的交付物不是件很容易的事情。螺旋模型每一次迭代仅仅包含了瀑布模型的某一个或者两个阶段。比如第二次迭代的重点是需求，则第三次迭代的总体设计以及后续设计则为设计开发计划。所以，这与RUP的迭代模型是有较大区别的，RUP要求精益求精的完成各项步骤而不仅仅是完成某一个阶段，它的每次迭代都包括需求—设计—开发—测试等各环节的活动，这是与螺旋模型最大的区别。

三、迭代模型

迭代模型能够较早得到用户的反馈，不断的测试和整合，是项目短期里程碑。主要适用于系统需求不稳定的情况，所包含的活动与瀑布模型一样，包括软件的需求分析和设计、代码生成测试及维护。主要缺点是迭代周期难以规划出每次迭代的内容以及所要达到的目标。迭代模型是指在进行较大规模的项目任务时，将迭代开发分为若干次，第一次迭代完成项目各阶段的基本业务，但是不包含较为复杂的业务和逻辑，通过第二个功能则针对相关的逻辑和业务逐渐补充完整并进行细化。迭代模型并不代表并行，每次迭代的过程仍旧需要遵循需求—设计—开发等规律和过程。其周期长度一般根据项目的周期和规模而定，一般小型的项目一周一次迭代，大型的项目2-4周一次迭代。因此，若没有高素质的构架师，很难对每次迭代的内容和目标进行很好的规划，并验证相关的产出和交付。由此看来，迭代模型虽然能够较好的满足互用对于需求的变化，但是由于其复杂性，的确是一个很难真正做好的模型。

四、原型模型

原型模型能够快速实现一个可以实际运作的系统初步模型，适用于有结构的系统或者需求不明确的系统，包含活动与瀑布模型相似，缺点也是不带反馈环，基本上是顺序的第一个系统，及原型系统常常被抛弃。原型模型一般不单独采用，往往是与瀑布模型和迭代模型一起使用。螺旋模型可以看作是瀑布模型+原型+迭代+风险的一种生命周期模型；迭代模型的每一个迭代周期的产出都可以被看作下一个迭代周期的精化原型；对于瀑布模型，在需求阶段我们就可以为界面和操作建立模型，在形成模型后再与用户进行沟通和确认。如果用户对于信息系统没有使用经验，恰巧系统分析人员也没有很多的需求分析经验及挖掘经验的同时，需求分析以及调研的过程需要一个很好的启发过程。原型模型则是很好的启发方法，可以迅速地挖掘用户的需求并与用户达成一致，避免在签字时发现需求并不是客户所满意的东西。

参考文献：

[1]樊学东.软件工程过程模型及其选择[N].西安外事学院学报,2008,12,4

[2]董剑利.基于产品线体系结构的软件工程过程模型研究[J].计算机工程与设计,2008,6

软件外包企业的过程改进分析 篇7

随着全球经济一体化的发展, 软件行业作为一种特殊的服务业得到了迅速的发展。全球一体化程度越深入, 这个行业就有越来越多的“全球化”概念, 软件外包是软件全球化环境下, 软件生产在全球进行资源有效配置的必然产物。著名的Gartner研究公司就大胆预测, 在2007年到2010年期间, 中国将成为世界上最大的外包市场。

全球公认的行业标准———SEI的软件能力成熟度模型 (CMMI模型) , 是软件企业期望吸收更多先进的行业经验, 提高软件开发能力, 提高软件管理水平, 并通过CMMI的评估和定级来获得一个进入全球市场的“门槛”。

1 软件外包企业过程改进的特点

国内的软件外包企业大部分承接外包项目是编码、测试及部分的设计, 较少涉及到需求阶段。如果IT行业存在一个食物链, 我们从事的外包项目处于食物链下游, 通常属于应用程序开发这一类型, 是这个市场进入门槛最低、重复性劳动最多、利润空间最低的一部分。这也是是发包方———美国、日本、欧洲各国出于知识产权、核心技术保护等考虑, 像微软总裁比尔·盖茨2005年6月29日在东京的日本商业协会发表演讲就曾表示:“美国和日本的IT公司不应该把核心业务外包出去”。

因此我们国内越是专业从事软件外包服务的企业, 在引入软件能力成熟度模型 (CMMI模型) 来实施的时候越容易遇到以下问题, 换言之我们在做过程改进的中的劣势存在以下几个方面。

1.1 过程经历的“先天不足”

项目组没有经历完整软件生命周期的经验, 尤其是需求阶段和产品交付验收阶段。而软件能力成熟度模型 (CMMI模型) 中的项目策划、集成项目管理这两个过程域就明确要求项目要选择项目的生命周期模型, 组织过程定义过程域还要求实施的企业从组织层面来定义组织内部的生命周期模型, 从成熟度3的要求看还需要进行过程裁剪。那如果某些外包项目仅仅是一个编码工作, 怎样识别自己的生命周期模型呢, 还能做怎样的过程裁剪?

1.2 质量保证的权利不完整

项目组不能整体把握工作产品的质量指标, 阶段产物的最终质量验证是发包方来评定, 在进行验证、确认、过程和产品的质量保证等过程域的实施是难以完整有效判断的;甚至有些长期从事软件外包的项目组会依赖客户、放弃评价的权利———对日外包企业的项目组尤其明显。

1.3 项目管理的自主度、可控度不全面

项目经理仅能为接到的任务来进行项目策划、跟踪、控制, 项目管控的深入度和全面性是打折扣的, 也就是说没有能力进行自主的全面的项目管理;尤其是发现项目组的一些问题时要明确判断是内部问题还是发包方问题并不好把握, 更难去进行原因分析。

1.4 无法接触最终客户

项目组由于没有原始需求, 不接触产品的最终客户, 即使是能接触到用外语描述的需求文档;由于对国外行业不熟悉、甚至语言能力影响到我们对需求的理解, 让我们的程序编写人员、测试人员难免在业务转换和处理中“行差踏错”。虽然承接对日外包项目中不少日方企业重视业务培训、写出了粒度很高的设计文档, 但软件产品是为客户提供服务的工具, 缺失客户信息和面对面的沟通, 一旦技术上遇到难题、实现上有困难, 我们只能放弃某些功能、降低质量要求。

但我们的软件外包企业相对于从事国内项目的企业来讲, 也有不少优势, 简单来说包括:

(1) 及时接触了发包方的先进管理经验。不少企业的项目组接受日本、欧美企业进行的管理技术培训;尤其是目前不少日本企业与中国的外包企业合作后, 联合成立中国研发中心、工程师培训基地等, 派人给中国企业人员进行如PMP培训, 管理工具培训等。

(2) 足够的数据积累。数据度量项目丰富, 涉及到工作量、进度、缺陷、问题、风险、成本、生产效率等, 并能进行一定的项目数据分析。

(3) 服务意识良好, 用户至上。从事外包的企业无疑更明确用户是“衣食父母”, 因此对于用户需求的响应及时性和有效性、确保用户满意度等方面一定是放在第一位, 并且落实到每个成员的实践活动中。

(4) 全员质量意识。质量控制、管理等工作不再是为了某些认证或检查, 也不是应付客户要求, 而真正落全体成员的全面实践中。

(5) 重视沟通管理。由于发包方所在国的某些行业与我国的业务差异性、文化的差异、语言差异, 我们的外包企业并没有回避, 反而更加重视沟通管理;通常都非常明确地建立沟通对应人、沟通响应时间规则, 小到邮件发送中的接受人、抄送人, 大到重大变更管理, 都尽量做到了过程管理、透明管理。

2 软件外包企业过程改进的实施建议

基于上述的优劣势分析, 笔者在此就软件外包企业的过程改进给出几点实施建议:

(1) 拿来主义。就像鲁迅先生倡导的真正的拿来主义要求一样, 外包企业要将发包方的管理经验、管理模式、先进技术、服务意识等学回来并转换成内部的体系或过程;更远一步的发展, 则是充分利用我们政府鼓励和支持企业自主创新的政策和支持措施, 创造自己的产品品牌。这里不得不回顾到印度经验———很多印度的软件企业逐步从应用程序开发、商业流程外包等, 跨入咨询服务领域。

(2) 辨别过程改进的主角。过程改进一定是我们自己内部的需要, 不是为了拿到一个“门槛”的认可, 不是为了客户的需要, 从内部找到真正改进的动力, 识别我们已有过程、需改进过程, 开发出具有软件外包行业特点的过程体系、生命周期模型、裁剪模型等。

(3) 评估模型上另壁蹊径。当前主流的评估模型都选择了CMMI for Development V1.2 (开发模型) 的阶段式评估, 但某些专业化程度很高、或者承接项目仅限于编码或测试某个单一阶段的企业, 是否可以考虑CMMI for Development V1.2的连续式评估, 只是选择当前专注的某些过程域来深入实施或评估呢?

此外CMMI还有CMMI for Services (服务模型) 和CMMI for Acquisition (采购模型) , 某些从事服务外包的企业其实考虑等待CMMI for Services (服务模型) 的发布后来推行和评估, 具体可以参考SEI的模型介绍, 本文就不做描述。

3 结束语

综上所述, 目前的软件外包企业在从事过程改进时是极具特点的, 从企业的业务发展和过程改进的深入度来说, 我们确实需要关注自己的优劣势所在, 分析和总结实施措施, 形成外包行业的竞争优势。

摘要：分析了软件外包的背景状况;结合相关经验来重点关注从事软件外包企业在过程改进中的实施优势和劣势, 期望能为软件外包企业在实施过程改进中整理思路, 分析自己改进的状况;为软件外包企业提出了过程改进的实施建议。

关键词：过程改进,软件外包,CMMI,沟通

参考文献

[1]软件业的生存之道Michael A.Cusumano (ISBN:7121010895) , 2006.

[2]Dennis M.CMMI精萃—实用集成化过程改进导论, Ahern/Aaron CL (ISBN:704016059) , 2005.

[3]SEI CMMI for Development, Version1.2 (CMU/SEI-2006-TR-008) h-ttp://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html.

[4]CMMI for Acquisition, Version1.2CMU/SEI-2007-TR-017 () http://www.sei.cmu.edu/publications/documents/07.reports/07tr017.html.

[5]Roger S.Pressman.软件工程—实践者的研究方法 (第5版) [M].北京:机械工业出版社, 2002.

[6]崔启亮.正视软件本地化的差距[J].计算机世界, 2003 (11) .

软件项目过程分析 篇8

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.

试析软件开发过程中的软件测试 篇9

关键词：计算机软件,软件工程,软件测试

在软件刚开始发展的那段时期,测试被认为是毫无技术含量的“猴子的工作”。由于测试在当时完全不受重视,拥有最好的开发过程的开发人员也马上就撞上了质量墙。而在后来的软件发展过程中,又不断有无数知名的计算机软件故障被新闻大肆报道,如因为节约空间省略年份前两位导致在2000年损失几十亿美元的千年虫事件,又如未检测一个接口导致一个数据位的错误设定最终导致的火星登录事故,又如诺顿杀毒软件病毒库更新误杀Windows系统文件的赛门铁克事件。尽管已经有了无数教训,但由于软件错误或缺陷造成的悲剧仍然每天都在上演。而现在,软件测试实际上是被广泛认定为一项需要高超技术能力的行业。之所以称为“行业”是因为软件测试不再向过去那样可有可无,而是在软件开发过程中发展成必不可少的一部分。

1 软件测试的定义、目的

对于软件测试,著名学者Glenford J.Myers认为首先应该认定软件是有错误的,但之后可以通过软件测试去找出这些错误。他还就此提出一些重要的观点,这些观点也可以看作是测试的目标或定义。

测试是为了证明程序有错误,而不是证明它无错误。好的测试用例在于它能发现以前没有发现的错误。成功的测试是发现了以前从未发现过的错误的测试。

软件测试的目的如下:

(1)以最少的时间和人员成本,系统地去发现软件中存在的错误和缺陷。测试的目标就是成功地暴露程序的错误,因此,如果正确实施了测试,就能发现软件中存在的错误。

(2)通过测试证明软件的功能与需求规格说明书的要求相吻合。

软件测试与软件质量息息相关,简言之,软件测试是软件质量的保证。通过测试来发现错误并将其修正,最大程度上规避软件发布后由于潜在缺陷和隐患带来的商业风险是我们所最看重的。

2 软件测试的分类

2.1 基于测试技术的划分

2.1.1 静态测试

静态测试是指在不运行程序的情况下,依靠人工走程序进行分析,也就是平时写小程序时的测试方法。静态测试对软件的需求文档、设计文档及源码等进行检查,主要包括走查、需求确认等。

2.1.2 动态测试

动态测试是让程序运行起来的检查方式,研究程序运行后的外部表现和执行结果。

2.1.3 白盒测试

白盒测试是指通过分析程序的内部结构,检测和寻找问题。在进行白盒测试时,要对程序内部如何运行了如指掌,选出少量“最有效的”测试数据与预期结果进行比对。白盒测试主要包括语句覆盖、判定覆盖、条件覆盖及其中一些组合。

2.1.4 黑盒测试

黑盒测试是与白盒测试互补的方法,它只注重程序的外部表现,而忽略程序的内部执行过程。通过对程序功能的分析,可以发现与白盒测试不同的错误。

2.2 基于测试实施组织的划分

2.2.1 开发方测试

开发方测试是指开发商通过已有的人力和设备资源,站在开发者的角度对软件是否能满足需求规格说明书和软件设计说明书的测试,测试后需要能够提供客观证据证实软件的确通过了开发方测试。

2.2.2 用户测试

在用户所处环境下,安装运行软件,并让用户真实体验软件是否能达到自己的期望要求。用户在使用后,可以提出对软件的改进意见,并对软件进行评价。

2.2.3 第三方测试

第三方测试又叫独立测试,由不属于开发方及用户方的第三方组织对软件进行的测试,通常是在模拟用户使用软件的环境中进行测试。

2.3 基于开发阶段的划分

2.3.1 单元测试

单元测试又称为模块测试,是通常与编码发生在同一个阶段,可以运用人工测试和计算机测试(依靠驱动程序和存根程序)两种方法,对程序模块进行正确性检验的测试工作。单元测试需要从程序的内部结构出发设计测试用例,即采用白盒测试方法,可以对多个测试模块并行测试。

2.3.2 集成测试

集成测试在单元测试之后进行,是将所有的已测模块组装起来的同时进行测试。集成测试着重测试模块间的协调和通信,即模块的接口。此外,每当一个新的模块作为集成测试的一部分加入总体的时候,软件会产生一些变化,这时需要适当地做一些回归测试。

2.3.3 确认测试

确认测试用来检测与证实软件是否满足软件需求说明书中规定的要求。该测试是在用户积极参与下对软件满足所有功能的、行为的和性能的需求的最终保证,其中发现的往往是系统需求说明书中的错误。在确认测试过程中仅使用黑盒测试技术。

2.3.4 系统测试

系统测试是在完全真实的软硬件环境中检查软件系统能否正确地被安装、配置、连接和运行,确定程序最终能满足用户的需求。

3 软件测试的特性

3.1 重要性

软件测试可以保证最终设计出的软件满足需求说明和设计说明并且最终可以成功且稳定地运行,因为这其中任何一个环节出现问题都会在软件测试阶段表现出来。如果测试没有通过,则说明软件确实是在某些方面存在问题。在软件开发过程中,用在测试上的花销要在30%~50%。如果把软件维护阶段考虑在内的话,测试花销会有些降低。但考虑到维护也是软件的再开发及多次开发,其中也包含很多的测试工作。因此,通过对这部分数据的调查得出结论,软件测试在整个软件生命周期需要50%以上的时间和经济成本。总结起来就是,一个好的测试是项目成功的保证,可以大大降低将来的解决错误的成本,发现项目存在甚至潜在的众多问题。而一个不好的测试会影响软件的性能,导致在维护阶段花费巨额成本,甚至影响软件公司的名誉。

3.2 复杂性

软件测试是非常复杂的,因为软件只有在所有可能的路径下输入一切可能的数据全部执行一遍(即穷举测试),才能发现所有错误。但一般情况下,这是不可能发生的。

黑盒法是穷举输入测试,但输入的情况无穷无尽,不仅要考虑正确输入,还要考虑各种错误输入,才能保证程序的健壮性。白盒法是穷举路径测试,而程序的路径数不胜数,难免出现遗漏。而在遗漏的那些路径中,就可能存在着潜在的错误。

3.3 经济性

程序测试能证明存在错误,而不能证明不存在错误。在实际测试中,穷举测试工作量巨大,根本行不通。这说明一切的软件测试都是不彻底的。但软件工程的目标是,充分利用有限的人力、资源、时间尽最大可能进行最高质量的测试。这其中,可以通过对测试部分的轻重缓急排序进行不同程度的测试、研究测试策略等方法降低测试的花销。

4 软件测试的准则

4.1 正面和反面测试都有助于降低风险

正面测试是简单地验证软件是否向其所宣传的那样工作,这对于大家来说很容易理解,但市面上还是经常出现存在各种错误的软件,原因就是“没人测试过这个问题”。而反面测试则是验证确保不会在用户在正常业务使用中破坏。相比于正面测试,它更容易被忽略,还更需要测试人员的创造力。

4.2 静态和运行测试都有助于降低风险

现在大多数软件测试都必须运行程序代码才能完成,但一些人已经开始注意到这样一个事实----软件开发过程中会产生大量文档,如果对这些文档进行静态测试,就可以在没有开始编码前就大幅度地减少运行错误的数目。

4.3 自动测试工具有助于降低风险

在过去几年中,随着自动化性能测试工作变得越来越成熟,人们已经开始在条件允许的情况下尽量考虑用测试工具逐渐代替各种手工测试。

4.4 把最大的风险放在最先测试

当面临有限的测试人员、有限的测试工具和有限的测试时间的时候,就必须保证有足够多的测试资源用来至少把最大的商业风险测试好。

4.5 把最常用的业务行为放到第二个来测试

当测试了最大风险之后,就该选择测试最常用的那些业务行为。根据80/20法则(80%的业务行为由20%的系统功能提供),要确保将工作重点放到20%最重要的系统功能上。

4.6 统计分析错误发生模式和其他错误特征是预测测试完成的重要手段

到现在为止,还没有任何人能宣称他可以对任何规模稍大的商业软件系统进行完全的测试。那么测试人员怎么知道何时测试工作算完成呢?事实上,根据Weibull分布模型,测试人员在预测软件实现中应该发现的错误总数时,可以把误差范围控制在10%~20%。

4.7 像用户使用软件那样来测试软件

所有测试都应该能追溯到用户需求,这一准则看起来是那么的理所当然,但笔者认为,这是软件测试的灵魂。

4.8 测试不只是要花钱,也是一种投资

测试能带来明显好处,不仅能够降低商业风险,还可以大大降低将来维护的工作量,更是对软件的一种长远投资。

5 软件测试的步骤

如图1所示。

6 软件测试的现状、前景

对于软件测试行业的现状,有以下几点:企业越来越重视软件测试,但企业内测试人员所占比例仍然很低。测试行业越来越受人欢迎,但测试人员的实际水平却不尽如人意。这种矛盾反映出软件测试目前是一个巨大的人才缺口,但真正有能力填补这个缺口的人却不多。

对于该行业的前景,Harry Robinson在2004年就曾预测过软件测试的未来,他持有以下的观点:测试的方法日趋完善,测试用例会时常更新,机械化测试将被大量应用;开发人员会加入测试团队,测试与开发的界限将开始模糊,客户反馈都将成为测试的一部分。

7 结语

软件测试是软件生命周期中至关重要的一环,而软件测试行业可以说是“道路是曲折的,前途是光明的”。在所在的大连理工大学国家示范型软件学院进行调查,大部分本科生对软件测试了解甚少,甚至还有很多认识误区,认为测试是浪费时间,每次做项目在测试部分也都是草草了事,结果导致程序在交接后出现各种意想不到的错误

参考文献

[1]芦阳.云计算及其带来的机遇与挑战[J].电脑编程技巧与维护,2013,(2):104-105.

[2]陈明.软件测试.北京:机械工业出版社,2011.

[3]Gerald D.Everett、Raymond McLeod,Jr..Software Testing(Testing Across the Entire Software Development Life Cycle).北京:清华大学出版社(译),2008.

软件过程改进 篇10

GIS工程学来源于系统工程学, 软件工程学和地理信息科学的结合。系统学、系统工程学、软件工程学、地理信息科学都是其理论基石。GIS设计是利用软件工程的思想, 结合GIS软件开发的特点和开发目标, 制定GIS软件开发的项目计划, 并对软件的用户需求和可行性进行分析, 从而设计软件的技术实现方案, 最后对软件进行实施和维护。

2 软件工程

在了解软件工程之前先介绍软件危机, 它是一种现象, 是落后的软件生产方式无法满足迅速增长的计算机软件需求, 从而导致软件开发与维护过程中出现的一系列严重问题的现象。

软件工程是多学科、跨学科的一门学科, 它借鉴了传统工程学的原理和方法, 同时应用了计算机科学、数学、工程科学和管理科学的很多理论与知识, 以求高效地开发高质量软件。从20世纪60年代软件工程学的产生到现在, 软件工程演变了三代。分别是20世纪70年代以结构化分析、结构化设计和结构化编程的第一代软件工程又称传统软件工程;20世纪80年代以研究面向对象分析和设计的第二代软件工程又称对象工程;20世纪90年代以组件技术的研究发展而来的第三代软件工程又称组件工程。软件工程代与代之间没有鸿沟, 他们不仅交叉重叠, 也携手并进。

3 软件过程模型以及其在GIS设计的作用

软件过程是按照软件项目的进度、成本和质量要求, 开发和维护软件所必需的一系列有序活动的集合。软件工程模型是按照工程化的思想设计提出的指导策略, 是一个覆盖整个软件生存周期全部活动和任务的结构框架, 这个框架给出了软件开发活动各阶段之间的关系, 相应的工作方法与步骤。

3.1 瀑布模型

瀑布模型 (Waterfall Model) 又称生存周期模型。是由W.Royce于1970年提出来的, 也称为软件生存周期模型。其核心思想是按工序将问题化简, 采用结构化的分析与设计方法, 将逻辑实现与物理实现分开。

3.1.1 瀑布模型的原理

瀑布模型是一种线性模型, 软件开发的各项活动严格按照线性方式进行, 每一项开发活动均以上一项的活动结果为输入对象, 实施该项活动应完成的内容, 给出该项活动的工作结果作为输出传给下一项活动, 对该项活动实施的工作进行评审。若工作得到确认, 则继续进行下一项活动, 否则返回前项, 甚至更前项的活动进行返工。

3.1.2 瀑布模型在GIS设计的作用

由于瀑布模型是一种以文档作为驱动的模型;阶段之间存在有序性和依赖性;将逻辑设计与物理设计清楚的划分开, 尽可能的推迟程序的物理实现;具有质量保证的观点;清晰的提供了软件开发的基本框架的特点使其在软件工程中占有重要地位。

瀑布模型一般适用于功能完整、性能明确、无重大变化的GIS软件系统的开发。但同时也应注意瀑布模型因为过早的考虑程序实现, 常常导致大量返工;它的阶段间的依赖特征会导致工作中发生“阻塞”状态, 如果大的错误在软件生存周期的后期才发现, 将导致灾难性的后果;它各阶段之间的大量规范化文档和严密评审增加了项目工作量;缺乏灵活性, 特别是无法解决软件需求不明确或不准确的问题, 因此其应用具有一定局限性。

3.2 快速原型模型

快速原型模型 (Prototyping Model) 是在用户不能给出完整、准确的需求说明, 或者开发者不能确定算法的有效性、操作系统的适用性或人机交互形式等许多情况下, 根据用户的一组基本需求, 快速建造一个可运行的软件, 然后进行评估。同时也使开发者对将要完成的目标有更好的理解, 再进一步精化、调整原型, 使其满足用户的要求。

3.2.1 快速原型模型基本原理

快速原型模型从需求分析开始, 软件开发者和用户一起定义软件的总目标, 说明需求, 并规划出定义的区域, 然后快速设计软件中对用户可见部分的表示。快速设计导致了原型的建造, 原型由用户评估, 并进一步求精, 逐步调整原型使之满足用户需求, 这个过程是迭代的。详细过程:第一步, 弄清用户的基本信息需求;第二步, 开发初始原型系统;第三步, 用原型系统完善用户/设计者的需求;第四步, 修改和完善原型系统。

3.2.2 快速原型模型在GIS设计的应用

由于快速原型模型使系统更易维护、用户交互更友好;能得到良好的需求定义, 比传统的生存周期法好很多, 使开发者与用户充分交流, 以改进原先设想的、不尽合理的系统;可降低总体开发费用, 节约开发时间。

快速原型模型比较适合低风险和柔性较大的GIS软件系统的开发。但同时也应注意避免对于开发者不熟悉的领域把次要部分当作主要框架 (模型效应) ;原型的迭代不收敛于开发者预先的目标;它不太适合嵌入式软件、实时控制软件、科技数值计算软件的开发。

3.3 螺旋模型

螺旋模型 (Spriral Model) 是B.Boehm于1988年提出的。螺旋模型将瀑布模型与原型的迭代特征结合起来, 并加入两种模型均忽略了风险分析, 弥补了两者的不足。

3.3.1 螺旋模型的基本原理

螺旋模型可以看做是连接的弯曲了的线性模型。螺旋模型沿着螺线旋转, 在笛卡尔坐标的四个象限上分别表达了四个方面的活动, 即:制定计划, 确定软件目标, 选定实施方案, 弄清项目开发的限制条件;风险分析, 分析所选方案, 考虑如何识别和消除风险;实施工程, 实施软件开发;用户评估, 评价开发工作, 提出修正建议。

3.3.2 螺旋模型在GIS设计的应用

由于螺旋模型是一种风险驱动模型, 为项目管理人员及时调整管理决策提供了方便, 进而可降低开发风险;特别强调原型的可扩充性, 原型的进化贯穿了整个软件生存周期, 这将有助于目标软件的适应能力;原型可看做形式的可执行的需求规格说明书, 易于为用户和开发人员的共同理解。

螺旋模型支持需求不明确, 特别是较高风险的大型GIS软件系统的开发。但同时需要注意要求构造的原型的总体结构、算法、程序、测试方案应具有良好的可扩充性和可修改性;如果每次迭代的效率不高, 会导致迭代次数过多, 将会增加工作量和成本并有可能推迟提交时间;它要求开发队伍水平较高;它是出现较晚的新模型, 不如瀑布模型普及。

3.4 增量模型

增量模型 (Incremental Model) 融合了瀑布模型的基本成分和原型模型的迭代特征, 其实质就是分段的线性模型。

3.4.1 增量模型的基本原理

增量模型采用随着日程时间的进展而交错的线性序列, 每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时, 第一个增量往往是核心的产品, 也就是说第一个增量实现了基本的需求, 但很多补充的特征还没有发布。用户对每一个增量的使用和评估, 都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复, 直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

3.4.2 增量模型在GIS设计的应用

由于增量模型每次增量交付过程都可以总结经验和教训, 有利于后面的改进和进度控制;每个增量交付一个可操作的产品, 便于用户建立好模型做出反应, 易于控制用户需求;任务分配灵活, 将风险分布到几个更小的增量中, 降低了项目失败的风险。

增量模型适合初期的需求不够确定或需求会有变更的GIS软件系统开发。但同时需要注意至始至终需要用户亲密配合, 以免影响下一步进程;要避免把难题往后推, 首先完成的应该是高风险和最重要的部分;要避免退化为边做边改模型, 从而使软件的控制失去整体性;由于一些模块必须在另一个模块之前, 必须定义良好的接口。

3.5 面向对象的软件过程模型

传统的软件开发过程大多建立在软件生存周期概念的基础上, 螺旋模型、原型模型、增量模型等实际上都是从瀑布模型拓展或演变而来的, 通常把它们称为传统的软件过程模型。

面向对象的软件开发过程的重点放在软件生存周期的定义阶段。这是因为面向对象方法在开发早期就定义了一系列面向问题域的对象, 建立了对象模型。整个开发过程统一使用这些对象, 并不断地充实和扩展对象模型。

3.5.1 构件复用模型

面向对象技术将事物实体封装成包含数据和数据处理方法的对象, 并抽象为类。构件 (component, 也译为组件) 是软件系统中有价值的、几乎独立的并可替换的一个部分, 它在良好的定义体系结构语境内满足某项清晰的服务功能, 可以通过其他接口访问他的服务。经过适当的设计和实现的类也可以成为构件, 在基于构件的软件开发中, 软件由构件装配而成。

构件复用模型如图1-1所示, 它融合了螺旋模型的特征, 本质上是演化的, 并且支持软件开发的迭代方法, 它是利用预先包装好的软件构件的复用为驱动构造来应用程序。首先标识候选类, 通过检查应用程序操纵的数据及实现算法, 并将相关的算法和数据封装成一个类。把以往软件工程项目中创建的类存于一个类库或仓库中, 根具标识的类, 就可搜索该类库。如果该类存在, 就从类库中提取出来复用。如果该类不存在, 就采用面向对象方法开发它。以后就可以使用从库中提取的类及为了满足应用程序的特定要求而建造的新类。进而完成待开发应用程序的第一次迭代。过程流程后又回到螺旋, 最后进入构件组装迭代。

统一过程模型 (Rational Unifi ed Process, RUP) 具有较高知名度的原因之一恐怕是因为其提出者Rational软件公司聚集了面向对象领域三位杰出专家Booch、Rumbaugh和Jacobson, 同时它又是面向对象开发的行业标准语言——标准建模语言 (Unifi ed Modeling Language, UML) 的创立者, 是目前最有效的软件开发过程模型。

3.5.2. 1 统一过程模型的基本原理

统一过程首先建立了整个项目的不同阶段, 包括初始阶段、细化阶段、构造阶段、交付阶段。同时每个阶段中又保留了瀑布模型的活动, 这里称为工作流, 即从需求、分析到设计和实现、测试等活动。所以, 可以将其理解为一个二维坐标, 工作流是一个竖坐标, 阶段构成了横坐标。但是, 二维坐标不是统一过程的主要思想, 它的主要思想是每个竖坐标表示的活动可能会产生多次迭代, 每个迭代会随着横坐标 (阶段) 的进展而产生变更, 最终逐渐减少甚至消失, 如图1-2所示。四个阶段, 九个核心工作流, 十大要素。

3.5.2. 2 统一过程模型开发过程各个阶段的里程碑

RUP中软件生命周期在时间上被分解为四个顺序阶段, 每个阶段结束于一个主要里程碑。初始阶段结束时是第一个重要里程碑:生命周期目标里程碑。主要成果有:项目蓝图文档、初始的用例模型、初始的项目术语表、业务用例模型。细化阶段结束时是第二个重要的里程碑:生命周期结构里程碑。主要成果有:系统架构基线、UML静态模型、UML动态模型、UML用列模型、修订的风险评估、修订的用例、修订的项目计划、可执行的原型。构造阶段结束时是第三个重要的里程碑:初始功能里程碑。主要成果有:可运行的软件系统、UML模型、测试用例、用户手册、发布描述。在交付阶段的终点是第四个里程碑:产品发布里程碑。主要成果有:可运行的软件产品、用户手册、用户支持计划。

RUP十大要素包括:开发前景;项目计划;标识和减小风险;分配和跟踪任务;检查商业理由;设计组件构架;对产品进行增量式的构建和测试;验证和评价结果;管理和控制变化;提供用户支持。

3.5.2. 3 统一过程模型在GIS设计的应用

由于RUP中的每个阶段可以进一步分解为一次迭代。与瀑布模型比较, 统一软件过程模型具有降低了在一个增量上的开支风险;加快了整个开发工作的进度;迭代过程的这种模式使适应需求的变化更容易;它的迭代模型建立了简洁和清晰的过程结构, 为开发过程提供较大的通用性。

统一软件过程模型非常适合GIS软件系统的开发。但是我们需注意的是RUP只是一个开放过程, 并没有涵盖软件过程的全部内容, 例如它缺少关于软件运行和支持等方面的内容;没有支持多项目开发结构, 这在一定程度上降低了在开放组织内大范围实现重用的可能。

3.6 敏捷开发过程

“敏捷”一词意味着快速、简单、灵活。敏捷开发过程强调以人为本, 注重编程中人的自我特长发挥。强调软件开发的主体是程序, 文档是为软件开发服务的, 不是开发的主体。敏捷开发特别重视客户参与开发, 因为开发者不是客户业务的专家, 所以一定要客户来阐述实际的需求细节。编制周密的计划是为了最终软件的质量, 但是为了要适应客户需求的不断变化, 计划和设计要不断调整。

敏捷就是“快”, 要快就要充分发挥每个人的个性思维, 个性思维的增多会造成软件开发规范性、一致性和可复用性的下降, 因此把敏捷开发与传统的“瀑布式”开发有机地结合。支持敏捷开发过程的极限编程就是强调交流、简单、反馈和勇气。另外并不是所有的GIS软件项目都适合敏捷开发, 例如, 难以分解的大型GIS应用软件、需要分布式开发的应用GIS软件等不适合敏捷开发。

4 GIS设计的未来展望

至上世纪90年代GIS进入产业化的阶段发展以来, GIS已经是一个全球拥有超过十万开发人员和数十亿美元的产业。世界各国已经设计出大量实用化的地理信息系统, 常见的GIS软件已经超过400种。当今国内外GIS的重要发展趋势是将地理信息系统融入国家信息化和知识经济的主体, 为资源环境问题的研究提供高技术手段, 形成新的经济增长点, 提高国家的安全能力。为此在未来仍需要大力发展业务化的GIS运行系统, 提高GIS的应用水平和效益。

由于GIS软件不同于一般程序, 它的一个显著特点是规模庞大, 而且程序复杂性将随着程序规模的增加呈指数上升。因此现有的计算机软件工程方法也不完全的适用于GIS设计, 未来还需要工程师和系统分析人员在GIS项目工程实施过程中进行研究与探索, 努力发展适用的GIS软件开发方法。

摘要：GIS从20世纪60年代问世以来已经经沥了近60个春秋的飞速发展。但随着GIS软件数量的飞速增长和软件规模的扩大, GIS软件危机情况已日益严重, GIS设计也将面临更大的挑战。笔者结合软件工程学的理论和思想, 通过合理的选用软件过程模型来为GIS设计提供思路。

关键词：软件工程,GIS工程学,GIS设计,软件过程模型

参考文献

[1]李满春, 任建武, 陈刚, 周炎坤.GIS设计与实现[M].北京:科学出版社, 2006.

[2]李伟波, 刘永祥, 王庆春.软件工程[M].武昌:武汉大学出版社, 2010.

[3]刘光, 刘小东.地理信息系统二次开发实例教程[M].北京:科学出版社, 2004.

[4]吴洁明, 方英兰.软件工程实例教程[M].北京:清华大学出版社, 2010.

[5]俎晓芳.浅析统一软件开发过程与GIS软件开发[J].内江科技, 2006, 27 (6) :103-104.

[6]郭建文, 冯敏, 李新.统一软件过程与地理信息系统的应用开发[J].遥感技术与应用, 2003, 18 (6) 422-428.

关于软件开发过程成本控制的探讨 篇11

关键词：软件开发过程；成本控制；系统软件

中图分类号：TP271

1 项目评估环境所存在的问题

为对统一性的项目考核标准进行建立，企业应该评估软件开发过程，其目的就是借助于评估编制该项目的目标责任成本预算，以便对项目效益指标进行测算。之后按照所进行评估的结果对于软件开发过程进行确立，使得利润指标与其他的经济指标进行明确。在长期的实践过程当中，必须高度重视一下问题：一是有着不统一的软件开发过程评估依据。有着很多的比较低成本管理水平的企业对于自己的成本定额予以建立，在评估软件开发的过程当中，必须按照相关的行业定额实施，这样就导致有着不统一的收费标准，对于评估结果的准确性造成比较严重的影响；二是有着比较强的随意性在软件开发过程的评估思路和方法。部分企业在实施评估的过程当中选用的方法是成本倒挤，可是这对于公正与客观的原则违背，使得所得到的评估结果准确率比较低、说服力比较弱，这对于考核落实评估结果产生不利的影响；还有的企业则是在实施评估的过程参照同类，这样就不能够紧密的结合评估过程和项目现场实际，导致存在着一定程度的走马观花的现象。

2 软件开发环境所存在的问题

通常来说，在软件开发所签订的评估结果与目标责任合同，这提供依据与标准软件开发生产环节的成本管理，企业必须要将此确立为行为的准则，将工程特点与施工组织方式做到有效结合，合理分解指标责任成本预算，从而把责任分解与量化到个人与小组当中，做到对成本核算的认真组织，使得对于成本开支进行严格控制，做到对于成本考核与分析的定期实施，以便做好相应的成本管理工作。基于当前的情况来看，从实际工作过程来看，部分软件开发的企业主要存在着以下问题：

2.1 有着薄弱的成本核算基础工作

长期以来，很多的企业并没有做到自己的成本核算制度建立，有着过于简单的成本核算对象，这样就导致认为的将成本核算环节予以简化，或者是有着不配比的归集和分配成本费用，导致存在着不对应的预算成本与实际成本两者之间，这对于成本考核与分析的需要不能够进行满足。

2.2 整个成本管理流于形式，所具备的制度约束显得不到位

在受到不断下降的硬件成本价格的影响，使得逐步上升与信息技术相关的组织成本与人力成本。按照惯例来看，组织成本与人力成本往往可以达到直接成本的三倍至四倍的水平，可是所谓的这些组织成本与人力成本的现实情况是，在信息技术投资的议案当中并不能够充分的做到预算，从某种程度上来看，这就恩呢该个在对绝大多数的软件开发项目的实施过程当中的成本“攀升”的现象进行解释。所谓的直接软件开发成本则是指那些由于实现与运行新技术所产生的费用。

（1）直接成本的类别。通常来说，软件开发过程当中的直接成本的类别主要有环境运行成本、硬件成本、直接成本、不可干扰的材料供应、文件服务器，开发软件、打印机、软件成本、终端，网络软件、数据库软件、咨询支持，成本项目的安装与调试，硬件设施安装，应用新软件而重新对业务流程设计，连接网络，经常性支出，低值易耗品，网费以及电费等。

（2）间接人力成本组合。在软件开发过程当中成本控制的间接人力成本组合，其主要包含着间接人力成本、人事部门支出、员工培训、所有权成本、管理资源、管理时间、管理投入、员工时间、员工奖励等。

（3）间接组织成本。在软件开发过程当中的间接组织成本主要包含着间接组织成本项目、机构重组、机会成本与风险、隐性阻力、生产率下降、组织资源负荷、商业运作再策划等。

从这可以了解到，虽然项目成本管理过程当中的控制生产部门直接成本显得特别重要，可是企业对利润提高的关键就是对于其他部门直接成本与间接成本予以控制。

而对于软件开发成本的分类与构成进行了解之后，那么就可以有效与合理的方法做好成本控制。所谓的项目成本工作则是在实施软件开发的过程当中，借助于项目成本管理的开展，从而将项目的实际成本控制在项目预算范围之内的一项管理工作。而在开展的项目当中，按照项目实际所发生的成本的情况对于原先的成本估算最好不断的修正，而且对于预测项目最终成本等工作都归纳入项目成本控制的工作范畴之内。要想全面控制软件开发成本的实现，其最为根本的任务则是要对项目各个方面的变更与变动情况进行控制，以及严密监控项目成本的事前、事中、事后。

3 实施过程控制

3.1 软件开发经理必须在每周结束之前按照软件开发计划当中的单项任务完成百分比，对于单个人员的工作量评表进行更新，公司软件开发管理人员对于挣值工作量予以计算。

3.2 按照软件开发组织结构的特征，所有开发过程當中可能有多个部门的人员参加，多个部门的人员可能参加多个项目；公司成本会计制定了一个公司所有项目工作量汇总表，由生产部门综合员根据每月项目经理统计出的项目组织人员工作量，汇总出本部门参加该项目中人员工作量后提交公司成本会计。

3.3 公司成本会计根据单个项目的工作量计算出人工工资，加上本月本项目支出的差旅费，业务接待费及运杂费，计算出本年1月分开始累计到本月底为止的每个项目的实际成本，提交公司项目管理负责人。

3.4 公司项目管理负责人根据项目计划，工程实话进度和项目组每月平均人数，计算出项目的计划成本，实际成本和挣值。项目管理培训

4 控制过程预警

软件开发项目实施进度预警：根据挣值管理，计算软件开发项目的成本差异，进度差异和项目成本计划超出率，对软件开发项目的实施进度出现异常的进行预警。

计划成本（BCWS）：生产部门计划完成任务的项目直接成本。

挣值（BCWP）：生产部门实际完成任务的项目直接成本。项目管理论坛

实际成本（ACWP）：直接计入生产部门的项目直接成本。

项目成本差异：CV=BCWP-ACWP

CV<0：表示执行效果不佳，即超支。

CV>0：表示实际消耗人工低于预期值，即有节余或效率高。

CV=0：表示实际消耗人工等于预期值。

项目进度差异：SV=BCWP-BCWS

SV>0：表示进度提前。

SV<0：表示进度延误。

SV=0：表示实际进度与计划进度一致。

5 结论

软件开发项目过程成本是软件开发企业最关心的事，要求项目团队想方设法降低项目成本，项目团队，尤其是项目经理要对项目中各种成本的组成有清醒的认识。软件开发项目中成本的不确定性要大，因而也对成本控制提出了更高的要求，但只要运用适当的方法，迅速合理地进行成本控制是完全可以按计划完成的。

参考文献：

[1]高禹.软件开发采用的一些基本思维方法[J].浙江海洋学院学报（自然科学版），2007（02）.

[2]陈玲萍.软件开发生命周期各阶段的应用软件安全性测试[J].企业科技与发展，2010（08）.

[3]程永利.挣值法在软件项目中成本与进度控制的研究与应用[J].电脑学习，2010（03）.

[4]任永昌，邢涛.基于挣值管理的软件开发成本控制方法的研究[J].中国管理信息化（综合版），2007（10）.

作者简介：杨跃，女，江南机电设计研究所，本科，助理工程师，研究方向：项目管理，产品价值工程研究。

软件过程改进 篇12

1. 什么是软件总线:

计算机软件总线与我们通常所说的计算机硬件不同, 它是虚拟的, 并不真实存在, 区别如计算机硬件和计算机软件一样, 但是可以具有与计算机硬件总线相类似的功能。

计算机软件总线是一种虚拟总线, 又称软总线;这组软总线可以为多种语言编写的多种不同种类型不同功能的程序, 即软件的部件服务。计算机软件总线也是一类软件, 与其它软件的区别在于, 它通常表现为一个接口界面——为各种软件构件组成连接用的通用标准平台。计算机软件总线是一组标准的软件模块, 它为计算机操作系统、各种软件的功能部件提供数据传输, 并为这些软件提供虚拟共享的通道和接口界面。

软件总线是为保证软件系统建设过程规范性和系统应用中的适用性以及扩展性而提出的一种设计思想。

2. 软件总线的基本功能

一般来说, 软件总线一般要完成4个基本功能;

(1) 通信功能, 是软件总线的最重要的功能, 众所周知, 我们通常所说的任何形式的信息在计算机硬件都只能以0, 1表示, 而硬件总线就是将由各种信息如:数据、控制信号转化而成的0, 1序列在其上按照一定规则有序、有效传输, 来完成计算机或用户要求的各项功能。同样的软总线也必须通过这种数据传输, 将操作系统、软件功能部件库等之间能够双向相互通信。

(2) 调度管理功能, 这部分功能由专门的调度管理模块完成。调度功能主要是负责实现软件构件库的管理, 完成软构件在操作系统上的调用、安装和卸载。

(3) 管理控制功能, 一般由相应的管理控制模块实现。管理软总线的管理控制功能主要是解决对软总线的合理分配、有效使用等问题。

(4) 接口功能, 主要是解决保证软件总线与不同语言编写的软件所构成的软件组合体通信、数据传送的构件接口问题。

二、基于软件总线的软件开发方法

1. 传统软件开发方法:

在传统软件方法体系中, 首先要做的是软件可行性研究, 其目的在于用最小的代价在尽可能短的时间内确定该软件项目的开发价值以及可能性。其次是做需求分析, 主要是对用户的要求进行细致的调查分析, 并将其转化为完整的需求定义, 再转化到相应形式的功能规约。再进行概要设计, 即把软件需求转换为软件表示, 把逻辑模型变换为物理模型, 描述软件的总的提醒结构。在详细设计阶段的基础之后, 继而进行编码, 将详细设计得到的处理过程的描述转换为基于计算机语言的程序。最后对软件进行测试, 此阶段的基本任务是根据软件开发各阶段的文档资料和程序内部结构, 设计一组测试用例, 找出软件中潜在的各种错误和缺陷。软件投入使用后就进入软件维护阶段, 由于供使用是软件开发的目的, 所以一般使用中也最容易发现软件所存在的问题, 所以通常情况下维护是软件生命周期中最长的阶段。

2. 基于软件总线的软件开发方法

随着科技日新月异的进步, 用户对软件的信息交互的实时性、效率、性能的要求越来越高, 同时也对软件开发的速度提出了更高的标准。软件总线体系结构的灵活性等特点, 使得复杂软件系统开发更容易实现, 易于软件的扩展、优化, 满足了时代的需求。

在基于软件总线的软件开发中, 开发工作将重点主要放在对软构件库的收集和软插件的制作上。其流程一般为——分析软构件功能、设计软插板、组装软插件, 大致框架理念完成之后再对细节部分的实现进行一一检验、落实, 然后进行对软件的部署和管理。

3. 基于软件总线的软件开发方法的优势

从上面对传统软件开发的介绍可以发现这种软件开发方式存在几大的缺陷:软件开发的时间长、效率低、过程复杂、需多次测试、软件系统维护性与拓展性低。所以找到一个既保证软件质量又能使软件开发简便化、短工期化, 是开发人员也是开发商们迫切的追求。软件构件化和软件总线的概念也因此应运而生。基于软总线的软件开发敏捷, 将可复用的软件构件在软总线从一个项目转到另一个项目发挥作用, 达到活灵活用、快捷开发的目的。

基于软件总线的软件开发, 不仅将会解决传统软件开发的不足, 如:开发时间长、效率低、易出错等问题。像计算机硬件开发过程一样, 随着基于软件总线的软件开发的各种标准的制定, 软件开发将不断走向大规模集成化方向, 基于软总线的软件开发也会带给软件行业一次革命性的进步与改变, 那时软件开发将会主要是两道程序构成:高科技软件模块的制造、简单的软件模块组装, 而这两部分工艺将分开进行, 即一旦所需的软件模块全面, 那么再按所需要的功能进行组装, 就会省下大量的人力、物力, 大大提高软件的生产效率。

三、基于软件总线的软件开发过程

1. 传统件开发过程

软件开发是指编程人员根据用户的要求或其它应用要求下, 建造出软件系统或者系统中的应用软件的过程。传统的软件开发过程一般包括:需求捕捉, 需求分析, 软件设计, 功能实现和软件测试等步骤。下图反映了传统软件开发的简要流程:

2. 基于软件总线的开发过程

与传统软件开发流程的繁琐不同, 软构件的开发、构件在软件的组装仅只两步是基于软件总线的软件开发的主要的程序, 大大简化了软件开发的复杂性。为了便于开发和增强适用性, 通信以及其它通用性较强的模块应与总线的接口标准一致, 才能让构件集成到系统环境中, 可以“即插即用”的特性, 提高软件开发的速度, 由于只是组装没有对构件更改, 也能减少传统软件开发过程出错现象。

基于软总线的软件开发主要经过如下几个流程:

(1) 按传统的软件工程方法, 对将要开发的软件进行系统的研究分析, 然后根据得出系统的数据来确定该软件所需处理的功能。

(2) 接着, 依据上面所得出结论得出将需用到的软构件的类型, 再根据它们将要实现的用途制定各种构件应具备的功能。

(3) 基于以上分析研究结论, 规划所需软构件。

(4) 之后, 制造对所缺的标准软构件。

(5) 将软构件组装成为具备相应功能的组件, 再将这些组件组装成所需的软件。

(6) 测试完成的软件和性能是否与所要求相一致, 若一致则投入使用, 若有差异则进行改进, 之后再测试, 直到与目标一致为止。

下图反映了基于软件总线软件开发的流程:

3. 在基于软总线的软件开发中应注意的问题:

(1) 软构件大小, 尽量只让每一个软构件实现单一的功能, 最好不要为了实现繁多功能而使其粒度太大。若每个构件功能相对单一, 能够增加软件插板的适用性, 有助于软件总线控制软构件库。

(2) 数据库访问, 授予指定软构件相应的数据库访问权限, 让其实现整个软件对数据的访问, 以保证访问数据库的安全性。

(3) 对于软构件, 如需自己制作软构件, 则须按一定标准进行, 构件的一致性有利于软构件在组装时更加方便, 而且也能增加其适用性, 以便以后用户于其它软件开发。

(4) 在组装时, 尽量全面考虑软件未来将会面临的各种情况, 保证软件的适用性、灵活性。

(5) 另外, 对于数据库的设计, 一般在软件开发之前完成。

(6) 最后, 对整体软件系统进行测试, 测试成功即可投入使用。

四、结语

在硬件开发已经达到至高点的时候, 软件开发还仍具有很大的发展前景, 基于软总线的软件开发是对传统软件开发的一次巨大改革, 也是当前计算机软件的热点研究议题, 将会成为未来软件开发的主流。基于软总线的软件开发, 具有“即插即用”、开发快捷、灵活等特点, 因而大大改进了软件的开发技术, 降低了开发成本, 降低了系统的开发难度, 提高了系统的搭建效率和灵活扩展能力。

参考文献

[1]张海藩.《软件工程导论 (第四版) 》[M].清华大学出版社, 2003.107-109.

[2]郑人杰, 殷人昆, 陶永雷.《实用软件工程 (第二版) 》[M].清华大学出版社, 1999.6-9.

[3]王光平.软件总线研究[J]计算机工程与应用, 2003;36 (3) :39-40

[4]陈兆良, 张世琨, 王立福.基于构件的商业领域软件开发平台的构造软件学报, 2002, 13 (1)

[5]张世琨, 张文娟, 常欣等.基于软件体系结构的可复用构件制作和组装[J]软件学报.2001, 12 (9) :1351-1359

[6]沈坚, 杜华荣.基于分布式组件对象模型的软件总线结构及其实现[J]昆明理工大学学报.2002, 27 (5) :55-58