软件项目管理规范研究

软件项目管理规范研究（精选七篇）

软件项目管理规范研究 篇1

关键词：软件开发,项目管理,配置管理,质量管理,风险管理,人员管理

1. 前言

随着信息技术的飞速发展, 软件产品的规模也越来越庞大, 个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。

中心为加强中心软件开发管理, 制定此管理规范。

2. 软件项目管理的组织模式

软件项目可以是一个单独的开发项目, 也可以与产品项目组成一个完整的软件产品项目。如果是订单开发, 则成立软件项目组;如果是产品开发, 则成立软件项目组和产品项目组 (负责市场调研和销售) , 组成软件产品项目组。

中心成立项目管理委员会, 项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。

(1) 项目管理委员会

项目管理委员会是中心项目管理的最高决策机构, 由中心总经理、副总经理、财务总监、技术总监、各事业部总经理组成。主要职责如下:

对项目立项、项目撤消进行决策;

任命项目管理小组组长、项目评审委员会主任、项目组组长.

(2) 项目管理小组

项目管理小组对项目管理委员会负责, 由中心管理人员组成。主要职责如下:

组织项目阶段评审;

保存项目过程中的相关文件和数据;

(3) 项目评审小组

项目评审小组对项目管理委员会负责, 下设开发评审小组和产品评审小组, 由中心技术专家和市场专家组成。主要职责如下:

对项目可行性报告进行评审;

对市场计划和阶段报告进行评审;

对开发计划和阶段报告进行评审;

项目结束时, 对项目总结报告进行评审。

(4) 软件产品项目组

软件产品项目组对项目管理委员会负责, 下设软件项目组和产品项目组。软件项目组和产品项目组分别设开发经理和产品经理。成员由中心技术人员和市场人员构成。主要职责是:根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。

3. 软件项目管理的内容

从软件工程的角度讲, 软件开发主要分为六个阶段:需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。

本规范将软件配置管理、软件质量管理、软件风险管理及开发人员管理四方面内容导入软件开发的整个阶段。

3.1 编写《软件项目计划书》

项目组成立的第一件事是编写《软件项目计划书》, 在计划书中描述开发日程安排、资源需求、项目管理等各项情况的大体内容。

3.2 软件配置管理

软件配置管理简称SCM (Software Configuration Management的缩写) , 是在团队开发中, 标识、控制和管理软件变更的一种管理。

软件配置管理分为版本管理、问题跟踪和建立管理三个部分。

常用的配置管理软件有VSS, CVS, Rational ClearCase等, 本中心采用VSS作为配置管理软件。

3.3 软件质量管理

随着软件开发的规模越来越大, 软件的质量问题显得越来越突出。软件质量的控制不单单是一个软件测试问题, 在软件开发的所有阶段都应该引入质量管理。

(1) 软件质量保证计划

在进行软件开发前, 需要有一个《软件质量保证计划》, 包括评审和审计标准、测试标准、管理控制等内容。

(2) 质量管理的基本原则

控制所有过程的质量;

过程控制的出发点是预防不合格;

质量管理的中心任务是建立并实施文件化的质量体系;

持续的质量改进;

有效的质量体系应满足顾客和组织内部双方的需要和利益;

定期评价质量体系;

搞好质量管理关键在于领导。

(3) 软件评审

软件评审并不是在软件开发完毕后进行评审, 而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误, 如果这些错误不及时发现并纠正, 会不断地扩大, 最后可能导致开发的失败。

(4) 软件质量认证体系

ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证标准部分。它从管理职责、质量体系、合同评审、设计控制、文件和资料控制、采购、顾客提供产品的控制、产品标识和可追溯性、过程控制、检验和试验、检验/测量和试验设备的控制、检验和试验状态、不合格品的控制、纠正和预防措施、搬运/贮存/包装/防护和交付、质量记录的控制、内部质量审核、培训、服务、统计系统等几个方面对软件质量进行了要求。

(5) 测试

软件测试是软件开发的一个重要环节, 同时也是软件质量保证的一个重要环节。所谓测试就是用已知的输入在已知环境中动态地执行系统 (或系统的部件) 。测试一般包括单元测试、模块测试、集成测试和系统测试。

3.4 软件风险管理

软件项目管理存在着风险, 如果我们提前重视风险, 并且有所防范, 就可以最大限度减少风险的发生。进行风险管理是有效的手段。

(1) 风险的分类

根据风险内容, 我们可以将风险分为项目风险 (成本提高, 时间延长等) 、技术风险 (技术不成熟等) 、商业风险 (销售问题等) 、战略风险 (中心的经营战略发生了变化) 、管理风险 (中心管理人员是否成熟等) 、预算风险 (预算是否准确等) 等。

另外, 还可以将风险分为已知风险 (如员工离职等) 、可预报风险 (从以往经验得出可能有风险的) 和不可预知风险。

(2) 风险的识别

风险识别的有效方法是建立风险项目检查表, 主要涉及以下几方面检查:

产品规模风险检查

业务影响风险检查

与客户相关的风险检查

过程风险检查

技术风险检查

开发环境风险检查

与人员的模式和经验有关的风险检查

(3) 风险评估

风险评估主要从下面七个方面进行:

发生的可能性

发生的结果 (影响)

建立一个尺度表示风险可能性 (如, 极罕见、罕见、普通、可能、极可能)

描述风险带来的后果

估计对产品和项目的影响

确定风险评估的正确性

根据影响排定有限队列

另外, 要对每个风险的表现、范围、时间做出尽量准确的判断。

(4) 风险的评价

对风险的评价主要依据三个因素:风险描述、风险概率和风险影响, 从成本、进度及性能三个方面对风险进行评价。

(5) 风险的驾驭和监控

风险的驾驭与监控主要要靠管理者的经验来实施, 风险驾驭和监控的策略如下:

与在职人员协商, 确定流动原因。

项目开始时, 作好人是会流动的准备, 采取一些措施确保人员一旦离开时, 项目仍能继续。

制定文档标准, 并建立一种机制, 保证文档及时产生。

对所有工作进行细微详审, 使更多人能够按计划进度完成自己的工作。

对每个关键性技术人员培养后备人员。

在考虑风险成本之后, 决定是否采用上述策略。

3.5 人员管理

在进行人力资源管理时, 我们往往重视招聘、培训、考评、薪资等各个具体内容的操作, 而忽视了其中的风险管理问题。其实, 每个企业在人事管理中都可能遇到风险, 如招聘失败、新政策引起员工不满、技术骨干突然离职等等, 这些事件会影响中心的正常运转, 甚至会对中心造成致命的打击。我中心是高新技术企业, 由于对人的依赖更大, 所以更需要重视人力资源管理中的风险管理。

4. 其它相关文档及模板

参见[计算机软件产品开发文件编制指南]GB8567-88, 编制其他相关文档:

可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、数据库设计说明书、测试计划、用户手册等。

5. 结论

集团客户部软件开发管理规范, 通过对成本、人员、进度、质量、风险等进行分析和管理, 有效地保证中心软件开发项目按照预定的成本、进度、质量顺利完成。

参考文献

[1]计算机软件产品开发文件编制指南GB8567-88

软件版本管理规范 篇2

第一章 目的

本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。

1.第二章 适用范围

所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。

2.第三章 职责

配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。

此岗位可由开发或测试人员兼任。

3.第四章 内容

4.1.版本管理对象

包括但不限于：

 项目总体计划

 可行性研究报告

 开发计划

 需求说明书  需求设计原型

 设计说明书

 系统开发变更申请单

 系统管理手册

 用户操作手册

 培训计划

 培训记录

 源程序

 支持系统运行的配置文件

 存储过程脚本

 测试计划

 测试用例

 测试脚本

 测试报告

 上线计划

 上线申请

 版本维护日志

4.2.配置库的目录结构

每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。配置库目录结构规划：

┠tags(发布)

┃ ├v1.0.0_T1_2016909 ┃ ├v1.0.0.33899_T1_20161009 ┃ ├v1.0.0_R1_20161109 ┃ ├v1.1.0_T1_20170109 ┃ └v1.1.0_R1_20170209 ┠trunk(主版本)┃ └projectA ┃ ├src ┃ ├MY_MOOC ┃ ├doc ┃ ├tool ┃ ├。。

┖branches(分支)├SY_ABC ├TJ_ABC ├WH_MOOC

其中，项目内部的目录结构：

|–projectA |–src（保存该项目的源程序）

|–doc（保存项目相关文档）

|–000.项目管理（保存项目过程管理相关文档）

|–010.项目计划（保存项目计划相关文档）

|–020.项目需求（保存项目需求相关文档）

|–030.系统设计（保存项目设计相关文档）

|–030.系统测试（保存项目代码测试相关文档）

|–040.系统实施（保存项目部署实施相关文档）

|–050.系统运维（保存项目运维文档，包括培训、用户手册等）

|–060.技术资料（保存项目技术文档，包括第三方技术资料等）

|–。。（保存项目过程管理相关文档）

|–tool（包括该项目特定的开发、编译、测试等工具）

4.3.分支(branch)

建议使用分支来协同不同职能小组对同一个配置库的使用，可按照以下方式进行分支的管理。

解决方案建立三个分支，包括主版本开发(trunk)、分支版本开发(branches)和发布(tags)。

 主版本开发

是所有分支版本的基准版本，主版本的开发分支。开发部门开发使用。

 分版本开发 主版本的分支版本，供开发部门开发使用。开发工程师如果以主版本为基准，进行软件项目开发，要先将trunk目录下的代码分支到branches目录的一个子目录，在那里对代码进行开发。多个主版本的分版本可通过在branches顶级目录创建多个分支目录来区分。

 发布

测试和发布专用分支，该分支代码不允许任何形式的修改。每个经过测试后的不同版本的代码做快照放到此分支文件夹下。

4.4.权限管理

应对配置库的访问权限进行管理，确保软件系统的完整性和安全性。建议按如下方式进行管理。

4.4.1.开发工程师

仅拥有自己所属项目的add file、delete file、check out、check in权限，无目录创建和删除权限。开发工程师若想创建目录，需向配置库管理员申请。

4.4.2.测试工程师

拥有每个项目的测试分支的add file、delete file、check out、check in权限，无目录创建和删除权限，对于其他分支只有只读权限。

4.4.3.配置库管理员

拥有全部权限，但增删项目和增删目录需要有项目负责人批准。

4.4.4.其他人员

若需要配置库访问权限，需经技术总监或经技术总监授权的项目经理批准，由配置库管理员分配权限。

4.5.版本管理

应对软件系统的版本进行管理，确保版本的准确性和可追溯性。建议按如下方式进行管理。

4.5.1.版本维护

软件工程各阶段产生的各种文档和代码，应及时并统一上载到配置库由配置库管理员统一管理。对于要修改的配置项，应从配置库中检出（check out）后修改，修改完毕后及时检入（check in），并填写修改的原因和内容。配置项的历史版本应保存在配置库中。

4.5.2.分支迁移

从开发分支到测试分支的迁移，由开发工程师操作。迁移的时机有：

1.当开发负责人提交测试申请时；

2.开发过程中进行测试，修改好一个或多个bug，需要测试工程师验证时。

从测试分支到发布分支的迁移，由配置库管理员操作。迁移的时机有：

1.当开发组提交上线申请时。

对于每个项目从测试分支到发布分支的迁移，配置库管理员要建立分支迁移日志，并详细记录。

4.5.3.版本升级

软件系统迁移到发布分支后，生成新的版本。

每个系统新的版本不仅以分支形式存在于配置库中，并且要以独立压缩包形式备份。版本的命名规则为，version N1.N2.N3[.N4][_][T/R5]_YYYYMMDD 1.N1是系统编号。当项目整体重新设计时，N1加1，基数为1 2.N2是模块编号。当模块重新设计时，N2加1，基数为0

3.N3是功能编号。当项目增加某一功能，或某一功能需要修改时，N3加1，基数为0

4.N4是BUG编号。当项目的BUG被修复时，N4加1，基数为0

5.T/R5中的T/R分别对应Test/Release。当项目发布时为R，当项目提交测试时为T，T/R5数值基数为0，以发布/测试提交顺序递增加1。

6.YYYYMMDD代表生成版本的实际年月日，如：20160202 4.5.4.版本基线定义

公司首次采用版本管理规范时，可以采取下列方法定义一个基线版本。

获取各项目最新的源程序、配置文件和文档，形成发布分支、测试分支和开发分支。

对每个项目的提测和发布分支都生成一个版本基线，如：Version1.0.0_R1_20160202。

4.6.第五章 版本提交准则

4.6.1.提交之前先更新

更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己测试之后，谨慎地提交。

如果在修改的期间其他同事也更改了同一个文件，那么update更新时会自动进行合并，如果修改的是同一行或者二者修改差异过大，那么合并时会产生冲突。这种情况就需要同之前的开发人员联系，两人一起协商解决合并冲突。解决合并冲突之后，还需要两人一起测试，以保证解决冲突之后，各自的程序不会受到影响。

在更新时注意所更新文件的列表，如果提交过程中产生了更新，则需要重新编译并且再次完成单元测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免合并错误导致代码有错。

4.6.2.保持原子提交

为确保在需要时可以随时回溯代码版本，每次提交的代码只能包含实现一个独立、完整功能所必需的代码，不能夹带提交其他与此功能不相关的代码。为尽早提交，也可以将此独立、完整功能分解为若干小细节功能，分别开发并提交所必需的代码，但必须确保多次提交的功能代码组合在一起，完全实现此独立、完整功能。

仅提交自己修改的部分，最好不要一下子将整个项目提交。

每完成一个独立、完整的功能后，最好尽早提交，以免后续更改时出现bug，无法恢复到正常代码。

每次提交的间歇尽可能地短，以几个小时的开发工作为宜。我们提倡多提交，也就能多为代码添加上保险。为做到尽早提交，在开发功能模块的时候，先将功能分解成一个个独立的、不可再分割的小细节功能，分别完成。每完成一个并通过单元测试，就提交一次。在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。

4.6.3.不要提交本地自动生成的文件

一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件屏蔽提交（例如Eclipse中的.classpath文件等，Visual Studio中的.suo文件，Debug,Release,Obj等编译文件夹及其下文件，以及其他的一些自动生成，同编译代码无关的文件）。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件，如果不小心签入了，需要从配置库中删除，以免其他同事在更新后就可能与本地的环境冲突从而影响大家的工作。

4.6.4.不要提交不能通过编译的代码

代码在提交之前，首先要确认自己能够在本地编译通过，并且代码在提交前已经通过自己的单元测试。

如果在代码中使用了第三方类库，要把相应类库文件统一存储在代码相应目录中并提交，以免项目组成员中有些成员可能没有安装相应的第三方类库，从而在更新代码后引起代码运行错误。

4.6.5.不要提交自己不明白的代码

代码在提交之后即被项目成员所分享。如果提交了不明白的代码，自己看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保对这个代码有一个很清晰的了解（必要时应有对应文档说明）。

4.6.6.并行开发（同一模块）前沟通

如果开发小组采用并行开发模式开发同一模块功能，在开发前，需要对协作开发进行合理的工作计划与任务分配，让小组成员相互间了解对方的工作计划与工作内容。这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时也能够在和成员的交流中发现自己之前设计的不足，完善自己的设计。4.6.7.对提交更新的信息采用明晰的标注

如果提交空的标注或者不确切的标注将会让项目组中其他的成员不了解此次签入动作的背景情况（如新增/修改签入的原因是什么？新增/修改什么内容？），项目经理无法通过提交的标注信息，清晰的掌握开发工作进度细节进度。没有清晰标注，甚至会对回溯代码版本造成影响。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。统一的标注格式为：

签入动作+””+”#” +标识ID+”;”+签入内容+[“;”]+[签入原因] 签入动作：

+：表示增加了功能（新增功能）

*：表示对某些功能进行了更改（修改功能）

-：表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽（删除功能）

^：表示修正bug（修复功能缺陷）

！：优化功能代码的执行性能（代码性能优化）

标识ID：

ID值是从项目开发计划中的WBS任务分解表中获取，对应具体功能编号。

签入内容：

对新增/修改/删除 的内容进行简单描述

签入原因： 对修改/删除 的原因进行简单描述

示例：

+ #62235；新增房源审核功能

* #62236；将房源审核的二级审核修改为一级审核；为缩短业务流程长度，提高业务响应速度

-#62237；删除多余功能；房源审核由二级审核改为一级审核后删除无用功能

软件项目成本管理的问题和对策研究 篇3

关键词 软件项目；成本管理；问题；对策

中图分类号：F715.53 文件标识码：A 文章编号：1671-489X（2007）12－0068-03

Study on Problems and Measures of Software Project Cost Management//Cai Xuebing

Abstract Combining the real-life situation, this thesis analyses the problems exist in software project management, put forward proper countermeasures to those problems, which aims to improve the management of project in software enterprises according to their own feature.

Key words Software project；Cost management；Problem；Countermeasure

Author’s address School of Economics & Management, Guangdong University of Technology, Guangzhou 510006

软件企业是我国高新技术产业的重要组成部分，软件项目管理和成本控制已经成为软件企业积蓄财力，增强竞争力的核心手段。软件项目成本管理就是根据企业的情况和项目的具体要求，利用公司既定的资源，在保证项目的进度、质量达到客户满意的情况下，对软件项目成本进行有效地组织、实施、控制、跟踪、分析和考核等一系列管理活动，最大限度地降低项目成本，提高项目利润，实现客户、公司、员工三赢，获得更稳定的客户群、更多的公司利润和更稳定的项目队伍。但是，当前国内软件企业在项目成本管理方面比较薄弱，项目经常出现有订单无利润、客户不满意、员工有怨言等现象。本文针对软件项目成本管理过程中存在的问题进行分析和探讨，并提出相应的对策。

1 软件项目成本管理中存在的主要问题

1.1 项目人员经济观念不强，公司缺乏一套行之有效的成本管理体制

目前，我国软件项目人员大多具有软件开发专业技术背景，但是普遍缺乏经济观念，成本意识淡薄，特别是项目不单独核算的企业，项目经理职能更偏重于技术而非管理，简单地将项目成本管理的责任归于财务部门。同时，软件公司通常缺乏行之有效的成本控制和激励体制。很多只是简单的规章制度，至于由谁做、何时做、做到什么程度都没有提及，实际运作起来难度很大。在项目内部，每个成员只从自己的职责角度考虑，项目成本居高不下。如何由“人治”过渡到“法治”，建立一套体制，在项目成本管理中非常重要。另外，项目人员常常在接到软件项目时没有认真做好项目的需求分析，没有认真了解客户的真正需求，为了把项目拿下来，口头上统统答应客户的要求，并没有在合同里把条款细化、量化。而往往客户的需求也是停留在比较笼统的概念上，很难明确化，实际操作起来时，项目不能满足客户的要求，客户就会不断提出新的要求，这时候要更改项目就必须付出很高的代价。例如国寿广州公司委托某软件公司开发代理人综合管理系统时，在项目的需求分析中，国寿信息部只提出相对笼统的概念，软件公司为了尽快拿到此项目，就全部答应，在合同里也没有细化条款。结果在系统做出来以后，总是难以全部满足最初需求，以致项目一再变更，软件公司为此付出很大的代价。

1.2 项目的过程编制薄弱

一些项目成本预算和估算的准确度差，失去控制标准。在项目管理中，相关的管理部门通常要求项目经理做出项目的估算或预算，并以此为标准，进行项目的控制和考核。但在实际工作中，由于项目具有一次性和不确定性的特点，以及项目经理自身的经验和水平的限制，使项目估算或预算的准确性很差，一有变化，项目经理就追加项目预算。预算频频变更，最终失去了项目的控制标准，成本控制也流于形式。等到项目结束时，实际成本和初始计划已经大相径庭。

一些项目缺乏成本绩效的分析和跟踪，缺乏将成本数据和工作量联系的对比数据。项目成本管理中，通常将预算和实际数值进行对比，没有将预算、实际成本和工作量、进度联系起来，考虑实际成本和工作量是否匹配、价值成本等问题。例如一个项目成本花费到总预算的1/3，而进度却是预计进度的1/4，工作量是总工作量的 1/5，这就说明项目成本控制存在问题。如果不采取措施，照此下去，项目一定会超出预算。

1.3 缺乏质量成本、工期成本、资金成本、风险成本的管理和控制

质量成本是指为保证和提高软件质量而发生的一切必要费用，以及因未达到质量标准而蒙受的经济损失。质量成本分为内部故障成本（如返工、停工等引起的费用）、外部故障成本（如保修、索赔等引起的费用）、质量预防费用和质量检验费用等4类。保证质量往往会引起成本的变化，但不能因此把质量与成本对立起来。长期以来，我国软件企业未能充分认识到质量和成本之间的辩证统一关系，习惯于强调软件质量，而对项目成本关心不够，造成质量虽然有了较大提高，但增加了提高质量所付出的质量成本，使经济效益不理想，企业资本积累不足。相反，一些项目经理片面追求经济效益而忽视质量，虽然就单个项目而言，利润指数可能提高，但是因质量标准而付出的额外质量成本，既会增加成本支出，又会对企业信誉造成很坏的影响。

工期成本是指为实现项目工期目标而采取相应措施所发生的一切费用。工期目标是项目管理3大主要目标之一，软件企业能否实现合同工期往往会引起成本的变化。我国软件企业常对工期成本的重视不够，虽然对项目工期有明确的要求，但对工期与成本的关系很少进行深入研究，普遍认为越早越好，有时会盲目地赶工期要进度，造成项目成本的额外增加。

资金成本是指资金的一切费用。由于公司一般项目都是由公司提供资金支持的，因此每个软件项目很少考虑现金流的状况，以及项目投入给公司带来的资金压力和项目本身的资金成本。在以项目为主的软件企业中，项目收入是公司资金流入的主要来源，项目的支出也是公司资金流出的主要内容，所有项目的资金流扣除期间费用后就是公司的资金流。因此，项目的资金流对公司的资金会产生重大的影响。现金流是公司的血脉，特别是对于中小软件公司，如果项目的资金流出现问题，可能会导致公司经营的瘫痪和夭折。

风险成本是指项目的不确定因素导致的项目风险。在项目成本管理中，很少考虑项目风险和潜在的风险成本，而风险一旦出现，会对项目的成本造成巨大的冲击。

2 软件项目成本管理中存在的问题的对策分析

2.1 树立全员经营意识，建立规范的成本管理体制

软件企业必须加大对从项目管理人员到普通员工的经营教育，强化经营意识。根据公司和项目本身的特点，制定有针对性的项目成本管理办法和流程。这些管理办法应该是责任到人、切实可行的具有较强操作性的办法，使项目的成本控制有法可依、有章可循、有据可查。每个项目都要有成本控制的目标——项目预算，都要严格做WBS（工作任务分解），在落实任务的同时，也要落实完成任务所需要的成本预算，并且逐级负责，层层落实。项目经理是项目成本管理的领导，这就形成一个以项目经理为核心的成本管理体系。同时用一定物质奖励去刺激，使每个人的工作、成本和项目的效益挂钩，彻底打破过去那种干好干坏一个样，干多干少一个样的格局，调动职工的积极性和主动性，使大家共同为项目的成本管理献计献策。另外，要做好项目的需求分析，真正了解客户的需求，尽量把客户的每一条要求量化、细化，并明确写入合同，避免以后因客户不断提出新的要求而增加项目成本。

2.2 加强项目过程管理和监控

要进行有效的项目成本估算和预算。项目预算是项目分配资源的计划，也是控制的标准，在项目成本管理中具有重要作用。成本估算和预算是对完成项目各项任务所需要的资源成本的近似估算。在实际工作中通常有3种成本估算方法：（1）自上而下估算。项目经理利用以前类似的项目的实际成本作为基本依据，通过经验做出判断项目整体成本和各个子任务的成本预算。此方法通常在项目的初期或信息不足时进行，需要项目经理有较高的水平和经验。（2）自下而上估算。将项目任务分解到最小单位——工作包，对项目工作包进行详细的成本估算，通过各个成本汇总将结果累加起来得出项目总成本。由于项目相关人员都参与项目的预算，这种方法最为准确，同时避免预算争议，但是耗用的管理成本会相应增加。（3）参数估算。这是一种建模统计技术，如回归分析和学习曲线。此方法需要数据的积累，根据同类项目的管理状况和成本数据，建立模型，在遇到同类项目时可以直接套用。

此3种方式可以根据公司的实际情况和项目的特点使用一种或同时使用。有效的成本估算和预算涉及到各方面的通力合作，需要项目人员进行有效的沟通。另外，即使最好的专家也不可能使预算和实际成本完全一致，因此项目应该预留一定的不可预见成本5%－10%，作为应急项目成本。

2.3 从质量成本、工期成本、资金成本、风险成本管理上要效益

质量成本管理的目标是使4类质量成本的综合达到最低值。一般来说，质量预防费用起初较低，随着质量要求的提高会逐渐增加，当质量达到一定水平再要求提高时，该项费用就会急剧上升。质量检验费用较为稳定，不过随着质量的提高也会有一定程度的增长。而质量损失则不然，开始时因质量较差，损失很大，随着产品质量不断改进，该项损失逐步减少。因此，必须找到一个质量成本最低的点。正确处理质量成本中几个方面的相互关系，即质量损失（内、外部故障损失）、预防费用和检验费用间的相互关系，采用科学合理、先进实用的技术措施，在确保质量达到设计要求水平的前提下，尽可能降低软件项目成本。同时，不能单纯为了提高企业信誉和市场竞争力而出现质量过剩的现象，导致出现完成工作量不少，经济效益低下的被动局面。

工期成本管理的目标是正确处理工期与成本的关系，使工期成本的总和达到最低值。工期成本表现在2个方面，一方面是项目经理为了保证工期而采取的措施费用；另一方面是因为工期拖延而导致的业主索赔成本，这种情况可能是由于外部因素引起的，也可能是内部因素所造成的，如停工、窝工、返工等，因此所引起的工期费用，可称为工期损失。一般来说，工期越短，工期措施成本越小；但当工期缩短至一定限度时，工期措施成本就会急剧上升。而工期损失则不然，因外部因素引起的工期损失，其损失额度相应较小，通常情况下不予赔偿或赔偿额度较小，该部分工期损失可不予考虑；因项目内部因素造成的工期损失，随着时间的推移、经验的积累会逐渐减少。综合工期成本的各种因素，就会找到一个工期成本为最低的理想点，这一点也就是工期最短并且成本最低的最优点。由于外部环境条件及合同条件的制约，保证合同工期和降低成本是一个十分艰巨的任务，因此必须正确处理工期成本的2个方面的相互关系。在确保工期达到合同条件的前提下，尽可能降低工期成本，切不可为了提高企业信誉和市场竞争力，盲目抢工期赶进度，增大项目成本，导致项目亏损。

对于项目现金流的控制，可通过项目的财务现金流分析，判断项目资金收支的时间、资金亏口的时间，便于提前准备资金。同时积极从客户方催款，以便支付各种费用，使得现金的流入大于流出。产品投资项目可采用投资回收期、净现金流来控制。

通过主动的风险控制，防患未然，避免和减少损失。根据拟建软件项目的具体情况，有选择性地进行经济模型盈亏平衡分析、敏感性分析和概率分析、合同控制等。软件项目的各种经济活动，都是以合同或协议的形式出现。如果合同条款不严谨，容易留下漏洞，造成己方蒙受损失时应有的索赔条款不能成立，产生不必要的损失。所以必须细致周密地订立严谨的合同条款。首先，要有相对固定的经济合同管理人员，并且精通经济合同法规有关知识，必要时应持证上岗；其次，要加强经济合同管理人员的工作责任心；三是要制定相对固定的合同标准格式。项目合同基本上有以下几类：软件开发合同、技术服务合同、采购合同、分包合同、劳务合同等。各种合同条款在形成之前应由业务部门参与定稿，使各项条款的内涵清楚，严谨不漏。

3 总结

软件项目管理规范研究 篇4

关键词：OPC,COM,工业控制,规范

1、引言

OPC(OLE for process control)规范的第一个版本是1996年秋颁布的,在短短的3年时间里,得到越来越多工控领域硬件、软件制造商的承认和支持。它实际上已经成为工业控制软件公认的标准。世界上一些著名的工业控制硬件、软件制造公司,对其产品都提供了OPC的支持,从而形成了工控领域的一个共识:不提供OP C支持,必将限制其市场。本文主要叙述OPC的内容及其给工业控制带来的巨大便利,旨在引起国内工业自动化领域研究机构和厂家的注意和思考,使产品更有生命力。

2、OPC介绍

OPC(OLE for process control)规范是OPC基金组织倡导的,工业控制和生产自动化领域中使用的硬件和软件的接口标准。OPC技术规范由OPC基金会进行维护、升级、产品认证和进行技术支持。OPC规范包括数据访问服务器接口规范、历史数据访问服务器接口规范、事件与报警服务器接口规范、批处理服务器接口规范、OPC DA服务器接口规范和XML DA服务器接口规范等一系列标准规范。它是由全世界范围内自动化领域中处于领导地位的硬件和软件开发商,在Microsoft的合作下协作制定的,并且已经得到越来越多客户和硬软件制造商的认可。OPC规范在短短的几年里发展如此之快,得益于OPC技术内涵。它基于Microsoft的OLE/COM和DCOM技术,包括了自动化应用中使用的一整套的接口、属性和方法的标准。Microsoft是OPC基金组织的发起成员之一,它把它的OLE/CO M等新技术带给了OPC基金组织。OPC技术主要用来解决按照标准的方法完成软件或设备之间数据交换的问题。COM/DCOM技术定义了分布式系统中软组件如何交互和共享数据,这已被证明:在Windows(NT)环境中,应用程序间数据交换的最有效最先进的技术。借助这些Microsoft的技术,OPC规定了与不同过程控制设备交互的统一的接口,而不用考虑过程中使用的控制软件和设备。

接口,简而言之即提供给客户应用程序的功能的使用方法。OPC规范通常包括两套接口:定制接口和自动接口。规范详细说明了这些COM接口,但并没有提供接口的实现细节,OPC服务器具体实现接口的功能。服务器具体确定了可以存取的设备和数据,数据单元(data Item)以何种方式命名以及对具体物理设备存取数据的细节,并且通过OPC标准接口开放给外部程序。像所有的COM实现一样,OPC的结构是客户机服务器模式。各个OPC客户程序通过OPC标准接口对各OPC服务器管理的设备进行操作,而不需关心服务器的实现细节及设备内部的具体细节。服务器组件提供并管理那些到OPC对象的接口。图1所示为OPC接口、OPC服务器及O PC客户应用的联系。

现在成熟并发布的OPC规范主要包括数据存取规范、报警和事件处理规范以及历史数据存取规范。广义而言,数据存取服务器包括三种对象:服务器、组和数据单元。OPC服务器对象负责维护服务器的信息,而且是OPC组对象的容器。组对象维护自己的信息并提供容纳和逻辑上组织OPC数据单元的架构。数据单元(对象)提供与数据源的连接。与数据单元相对应的是一个值(value)、品质(qual ity)和时间标签(timestamp)。关于报警和事件处理规范,它明确了特定事件和报警条件下通知OPC客户应用的机制。它为OPC客户提供的功能有:确定O PC服务器支持的事件类型,得到特定事件的发生信息;还有OPC服务器实现的存取和操作条件。历史数据存取规范所支持的服务器类型主要有:简单的趋势数据服务器,复杂的数据压缩和分析服务器。

OPC的设计目的最重要的是即插即用,也就是采用标准方式配置硬件和软件接口。一个设备可以很容易地加入现有系统并立即投入使用,不需要复杂的配置,且不会影响现有的系统。系统中的信息也可以很方便地分散至众多支持OPC的软件应用当中,如维护、监督、操作显示和文档管理等应用。

3、OPC带来的巨大好处

和用于字处理的标准打印机驱动和用于数据库存取的ODBC给各自的领域带来深远影响一样,OPC标准的制定为工控领域带来了变革。不仅是用户,连同硬件制造商和软件开发商都可从中得到巨大的利益。以前的过程监控中硬件和软件的设置情况如图2所示。

各种应用软件都必须提供这三种设备的驱动程序,即需要12个驱动程序维持系统的正常运行,而且各软件间不能相互通信。因为各个软件来自不同的开发商,具有不同的相互独立的对同一设备的驱动程序,所以多个软件也不能同时对同一个设备存取数据,否则可能造成系统的瘫痪。同时,某一个设备的升级要求该设备的所有驱动程序升级,否则隐患无穷。这样的一个系统要想长期维护,工作量可想而知。

OPC规范的引入,使得过程控制的硬件软件配置可以由图3表示。

硬件制造商只用开发出符合OPC规范的驱动程序,即图中的服务器,就可以一劳永逸,因为这个服务器为所有支持OPC标准的OPC客户软件所用。这个系统可以很方便地进行修改和升级,增加一个设备(当然提供了OPC服务器),所有的软件都可以与其进行数据交互。以前,用户在设计一个自动控制系统时,选择硬件软件,限制因素太多,考虑因素也多。找到真正满足需要的设备后,可能因为自己的软件不支持而倍感苦恼,或者放弃选择,用一个并不太合适的设备来代替,或者请软件开发商开发出这种设备的驱动程序。而现在用户可以不受限制地选择硬件和软件,选择真正满足自我要求的设备。

各个厂商提供的OPC服务器,都以同一种方式工作,这使得用户只要学会一种服务器的使用,便掌握了所有的使用。以往,用户在学会所选软件程序的定制工具箱后,要改用另一种软件,必须重新学习这种特定软件的工具箱。这不仅浪费了用户的时间,也增加了用户的培训费用开支。

对于一个工业现场,如果测点和控制点增加或改变,对原来的系统来说,所需的工作量很大,而符合OPC规范的控制系统则很容易实现,尤其是大的工业现场,对系统进行长期地监控、配置优化以及节省维护费用的优势更为突出。

对于软件开发商而言,不再费神于开发各种硬件设备的驱动程序,而是把精力和时间集中在增加和完善软件的功能上,使自己的软件更易被用户接受和使用。对于硬件设备制造商,再也不必担心自己的产品因为没有为某些软件提供驱动程序而被用户所忽视或放弃。一次编写的驱动程序(OP C服务器),可以被所有的应用软件所用。不仅节省了各种I/O驱动程序的开发费用,而且可以让制造商集中精力生产更易于用户使用的、功能完善的硬件。

4、OPC的发展

OPC规范的第一个版本是在1996年秋颁布的,几年里OPC规范得到了巨大的发展和补充。OPC基金组织成员也由开始的5个扩大到现在的212个(至1999年9月),而且世界上主要的自动化系统和仪表的生产商像Sun和Intellution都在其中。组织成立的初衷就是要开发一个开放的、易实现的、即插即用的标准,这些目标已部分实现。Microsoft不仅是这个组织的参与者和技术后盾,每年还在Microsoft的总部召开一次OPC基金组织年会,该组织的成员可以预阅OLE/COM和其他Microsoft技术的新发展。最终用户也被鼓励加入O PC组织,一些用户也的确参加了规范制定和技术上的复查过程。这些都促进了OP C规范的发展和完善。OPC规范制定的主要目标是将规范尽快地应用于工业实际。在此指导思想下,多数开发商关心的区域首先开始了规范的制定。目前发布的3个规范为:数据存取规范、报警和事件处理规范以及历史数据存取规范。其他的像安全性、批量控制以及报警和事件的历史数据存取,这些功能的标准正在酝酿和制定中,相信在不久的将来就会发布。

5、结论

基于COM技术的OPC技术规范在短短几年内获得了极大的发展,并得到了国际上自动化领域领先厂商的广泛支持。采用OPC技术规范的产品实现了工业自动化系统中软件之间的互操作和无缝集成,以及现场监测、控制设备的即插即用,为该领域的硬件、软件厂商及最终用户带来了直接和明显的经济利益。符合OPC规范的硬件、软件产品开始大量地开发并得到广泛应用,支持OPC技术开发的各种开发工具正在不断地得到完善,OPC前景一片光明。目前工控产品的OPC支持性能已经成为其综合性能的一个重要方面。国内的工控硬软件制造商要抓住时机,抓紧跟上世界先进技术的发展,开发符合OPC规范的产品,保证产品市场的生命力。

参考文献

[1]OPC Foundation.OPC Over View,Version1.0,1998

网上纳税申报软件管理规范(试行) 篇5

【发布日期】2010-07-19 【生效日期】2010-11-01 【失效日期】 【所属类别】政策参考 【文件来源】国家税务总局

网上纳税申报软件管理规范（试行）

第一章 总 则?

第一条 为规范网上纳税（费）申报软件开发与服务，加强对软件开发与服务单位（以下简称开发服务商）的监管，确保纳税人申报的电子涉税数据准确、完整和安全，特制定《网上纳税申报软件管理规范》（以下简称管理规范）。

第二条 网上纳税申报软件分为低保型纳税申报软件、商品化纳税申报软件和纳税人自行开发纳税申报软件。

低保型纳税申报软件，是指税务机关免费为纳税人提供、符合相关规定、满足基本要求的纳税申报软件。

商品化纳税申报软件，是指市场上开发服务商根据相关规定开发的，纳税人自愿选用并享有配套服务的纳税申报软件。

纳税人自行开发纳税申报软件，是指纳税人自行研发符合相关规定的纳税申报软件。

第三条 根据国家法律法规和税收政策，国家税务总局制定和修订统一的网上纳税申报业务标准（以下简称业务标准），并及时向社会发布。

业务标准之外税（费）申报，由省税务机关依据业务标准增补相应的内容，并报国家税务总局备案后及时向社会发布。

第四条 低保型纳税申报软件,由国家税务总局组织开发和维护，免费提供给纳税人使用。商品化纳税申报软件和纳税人自行开发纳税申报软件，由开发服务商和自行开发纳税人自行组织开发和维护。

第五条 税务机关应对开发服务商服务质量进行约束和监督。?

第二章 网上纳税申报软件评测 ?

第六条 国家税务总局负责对开发服务商进行评测及监管。开发服务商应当具备以下条件：

（一）较强的综合实力：专职软件开发人员不少于30人，技术服务人员不少于50人。

（二）软件开发管理能力：软件能力成熟度（CMMI）达到3级以上。

（三）软件支持服务能力：拥有集软件升级维护保障、远程客户服务呼叫中心、本地化上门服务于一体的完善的支持服务体系。

（四）有参与税务信息化或国家大型信息化建设项目的经验。

第七条 网上纳税申报软件的具体评测由国家税务总局自行组织或委托、联合第三方测评机构实施。

第八条 国家税务总局定期发布评测公告，开发服务商根据公告向国家税务总局提出评测申请。

第九条 评测合格的网上纳税申报软件及开发服务商目录由国家税务总局向社会公布，各地税务机关必须在目录中选择使用，选定后由省税务机关上报国家税务总局备案。未通过评测的软件各级税务机关不得选用。

第十条 国家税务总局不定期对在用网上纳税申报软件进行抽检。

第三章 服务与权益保障 ?

第十一条 纳税人选用商品化纳税申报软件，应当与开发服务商签订合同。开发服务商应当免费提供网上纳税申报软件，并提供按年和按次两种收费服务项目，由纳税人自愿选择服务项目，不服务不得收取费用。

第十二条 开发服务商应当公告服务项目和收费标准。开发服务商收费标准，应当随着推广规模的逐步扩大而逐年降低。

第十三条 开发服务商应当提供优质服务，其配套服务的主要内容应包括：咨询、软件升级维护、现场技术支持等。

第四章 数据传输质量与保密 ?

第十四条 网上纳税申报软件，应当采用必要的安全认证措施，解决网上纳税申报的身份识别问题，各地税务机关不得强制纳税人有偿使用。

第十五条 开发服务商应保障其软件能按照税务机关的要求，及时、完整、准确地传输纳税申报电子数据。

第十六条 开发服务商必须遵守国家保密规定，保证纳税人电子申报数据安全，不得对纳税人的纳税申报电子数据有任何泄密行为。

第五章 日常运行维护 ?

第十七条 低保型纳税申报软件，由国家税务总局负责督促选定的开发服务商进行软件升级，并及时公布。

第十八条 商品化纳税申报软件由开发服务商根据税务机关发布的业务标准及时升级，并提供给纳税人使用。

第十九条 自行开发的纳税申报软件的纳税人根据税务机关发布的业务标准及时升级。

第六章 法律责任 ?

第二十条 凡开发服务商发生下列情形之一者，按管辖权限由相应的省税务机关责令限期整改。给纳税人造成损失的，由开发服务商按照合同协议承担赔偿责任。

（一）未按照国家税务总局规定的业务标准和补充说明，及时进行申报软件修改升级，给纳税人造成损失或经抽检不合格的；

（二）未按照合同协议规定的标准提供服务和收取服务费用的；

（三）纳税人投诉反映强烈，经核查属实并造成重大影响的；

（四）纳税人满意度达不到各地税务机关制定的具体标准的。

第二十一条 凡开发服务商发生下列情形之一者，按管辖权限由相应的省税务机关责令其退出网上纳税申报技术服务市场，并及时上报国家税务总局备案和向社会公布。给纳税人造成损失的，由开发服务商按照合同协议承担赔偿责任。

（一）网上纳税申报软件经评测不合格，一个月内修改后再次评测仍不合格的；

（二）将纳税人纳税申报电子数据向第三方泄露经核查属实的；

（三）限期整改仍不合格的。

第七章 附 则 ?

第二十二条 本管理规范由国家税务总局负责解释，于2010年11月1日起施行。

基于客户的软件项目风险规避研究 篇6

摘 要:软件项目开发成功率低是软件行业的共识,主要是因为在软件开发过程中众多的风险因素造成。文章拟从以客户为中心的软件开发思想,以客户为主导的角度研究软件项目风险的规避行为,降低软件项目的风险。

关键词:软件项目;以客户为中心;风险

中图分类号:F407.672 文献标识码:A文章编号:1006-8937(2009)24-0036-02

信息技术的发展促进了软件产业的飞速发展,使得软件产品在众多领域的应用越来越重要。然而,软件产品的开发成功率相对于其它工程项目产品要低得多,这主要是由于软件产品的特殊性造成的,软件产品的特殊性使得软件项目在开发过程中具有众多的风险因素,而且风险因素错综复杂。

从软件项目风险管理的研究成果来看,风险辨识和评估的研究比较丰富和深入,而软件项目风险因素的识别、评估的最终目的是为了能够制订科学的风险管理和控制方法,从而有效地进行软件项目风险管理。然而,如何在风险辨识与评估的基础上采取风险规避行为,文章从以客户为中心的软件开发思想出发,提出基于客户满意度的软件开发能够在一定程度上减少软件项目的风险,即在软件开发过程中,客户满意度越高软件项目成功的概率越大。

1全生命周期的客户风险

以客户为中心的软件项目开发思想是敏捷软件项目管理中的核心思想,时刻与客户保持合作关系,使得客户能参与到软件项目开发中。由于软件是一种特殊的逻辑产品,不具备实体的可见性,它是由经过智力劳动而产生出来,具有特殊物质的复杂事物,因此在软件开发过程中将有众多的不确定因素存在,如客户需求不断变化。采用以客户为中心的软件开发更适用于软件行业,Ilieva et al.(2004)等人在研究敏捷开发中发现:客户在软件开发过程中对开发进程监控,使得项目在签收时受到客户的高度评价,即项目成功。但是Tore Dyb与Torgeir Dings?yr(2008)指出客户在敏捷开发中表现出不持续性将对项目带来更大的风险[1]。

客户风险主要是客户对中间产品或最终产品的不满意,或客户的意见未被采纳或更改,造成产品最终无法满足客户的要求;客户对规划、原型和规格的审核决策周期比预期的长;客户提供的组件质量欠佳等。客户风险体现在软件项目生命周期中的各个阶段。

软件项目在其生命周期中,分为以下四个阶段:需求分析阶段、制定方案阶段、实施阶段与结束项目阶段。

①需求分析阶段。对于软件项目组织来说,该阶段需精确识别客户的真实需求,因此项目组织必需密切与客户沟通,在将收集到的信息加以汇总时对不明确之处反馈于客户,以期客户解答。此阶段中,若客户不予以配合或不完全表达其意思,则软件项目必定失败。项目组织在需求分析过程中,需要时时以客户为中心,使得客户能够顺利方便地参与到项目中,做好软件项目工作的第一阶段。因此,与客户的沟通程度、客户的参与程度将是客户风险在该阶段的体现。

②制定方案阶段。该阶段项目团队的主要任务就是与客户一起制定一个以前期明确的需求、双方的资源、项目开始实施的时间约定、项目费用限制等为基础的具有可操作性的项目计划,从本阶段开始争取客户全面参与项目的管理,需要双方共同考虑项目实施的具体计划落实和风险规避。

③实施项目阶段。此阶段为项目成功的主要阶段,伴随着项目工程的推进,在前两个阶段中不确定性的事件可能会成为该阶段的主要事件,客户在本阶段也会因为外界环境的变化而使得第一阶段中的需求发生改变,如客户所处公司的环境。此时项目团队应实时对客户满意度进行评估,实时了解客户的需求。在本阶段中,客户风险体现在原需求的改变、项目进度达不到客户需要、软件项目的成本、软件项目的质量(如软件界面设计)等。若此阶段项目团队不能与客户密切沟通与合作,客户风险将导致项目的夭折。

④结束项目阶段。此阶段也可以称为软件产品验收阶段,软件项目经理将软件产品交付客户使用。客户对软件产品的满意程度将直接决定是否签收该软件产品,如果客户对软件产品不满意,意味着软件产品的开发失败,修改软件产品将需要更多的成本与时间。因此,客户对产品的质量、成本控制、项目是否延时等问题都将成为影响客户满意度的因素。

2风险规避模型建立

在软件项目全生命周期中,客户风险时刻存在。为了达到客户满意度,采用一般风险管理中常用的规避风险的四个策略:“避免”、“转移”、“接受”、“遏制”和“深入探讨”。所谓“避免”策略是指通过改变产品设计或开发过程,避免或消除风险可能造成的严重后果。“转移”策略常用于保险分担或合同分担,风险出现的概率并没有因此而降低,但是降低了风险出现后某一方遭受损失的程度。“接受”策略指听任风险的自然发展,一方面不需付出风险控制成本,另一方面也没有消除风险可能的危害。“遏制”策略通常有两条途径,一条是加强高风险因素的薄弱环节,降低风险发生的概率;另一条是调整设计方案或管理方法,减轻风险出现后的影响后果。“深入探讨”策略是为掌握风险的具体特性而开展的各项活动,以便取得更多的信息,使风险决策更为科学和明智。

软件项目开发的过程中,软件项目团队与客户保持密切联系,共同处理风险。文章中采用这个四个策略的优先级顺序评估客户对软件项目风险处理的接受程度,达到客户的心理接受风险程度,即客户对软件项目的满意程度。

3 结语

在项目管理过程中,项目的三个主要控制要素:成本、质量、进度。这些要素是每个项目管理中不可获缺的,在软件项目中也不例外。在软件项目中,这三个要素在不同的阶段具有不同的权重,而且其中的任何一个要素的滞后都将带来客户的不满。

浅谈计算机软件开发的规范化 篇7

关键词 计算机 软件 开发 规范化

中图分类号：TP3 文献标识码：A

0前言

现代信息技术的发展和应用，为加快我国市场的信息化进程起到了强有力的推动作用。然而信息化的发展，完全取决于计算机软件开发的技术水平。因此，在满足时代发展需要的基础上，加快软件开发的专业人才建设，才是当前需要面临的重大课题。任何的企业想要求发展都必须满足规范化，而软件开发对规范化的要求显然更高，软件开发是否规范，将决定着软件的存在寿命。信息工具已经成为人们当前不可或缺的重要工具，只有提高计算机软件开发的规范化，才能适应当前计算机产业发展的需要。因而，增强计算机软件开发的规范化，有利于提升我国计算机产业在全球市场的竞争力。

1计算机软件开发规范化的意义及现状

软件开发的规范化，是实现计算机软件正常并有效运行的前提，它将影响着计算机产业的整体发展并影响着我国软件行业的综合竞争力。

重视加强计算机软件开发的规范化，是要求开发者在特定环境内，基于满足软件的性能需要，对软件的开发和实际应用做出必要的说明，并完善软件的用户需知。要实现计算机软件开发的规范化，就要分析软件的应用环境，对用户的需求进行详细了解，来明确软件开发的规则。

当前我国的软件开发技术已经达到了一定的水平，但仍有着极大的发展空间，充满着机遇与挑战，并且也存在着一些问题，尤其是对软件的检测方面规范性不高，容易导致在计算机软件开发的过程中遗留漏洞，这主要表现在几个方面：

第一、 软件的检测程序不规范，检测报告含糊笼统，没有对所检测出的具体状况进行详细的登记划分。比如在检测中，发现错误，便按照固有的描述模式进行描述，严重缺乏针对性和专业性，缺乏建设性意见，出现问题便相互推诿，导致软件的质量受到严重影响。

第二、 软件的具体检测过程不清楚，无法通过检测报告直观详细地了解软件检测的环境以及过程，这无疑会为软件的调整增加困难，更影响了软件开发部门对软件的修改。

2计算机软件的开发标准

计算机软件的开发，主要包括开发的概要描述和具体的设计流程，是软件设计的重要组成部分。一般来讲，在实际的操作过程中，软件的设计开发，具有结构化的特点。软件的开发是建立在用户的需求的基础上，并结合当前的市场环境，进行具体分析，形成设计的构造流程以及应用风格等。有着特定的研发标准，才能使计算机软件的开发规范化。

首先，概要的设计标准，是要依据软件的实际应用的功能来制定，使设计能够满足应用的各个模块，并且使之建立联系，对各个模块的接口等做出定义。通过功能强大的数据库，设定软件的应用范围，提出合理的检测模式。整个系统的概要设计作为软件结构的构造标准，保证软件开发的合理性。对各个接口要进行详细的注解，建立服务于功能系统的数据库，所设计的系统须囊括软件产品的所有信息。还要注意明确各个模块的性能和联系，以及接口的控制性能，以保证软件检测系统的全面性。

其次，在软件开发过程中，设计研发的标准是基于概要的设计来进行，要秉着充分细化概要设计的理念，使得各功能模块更加系统、更加精细化。软件设计的研发标准，需围绕算法和内部结构两大方面来制定规范。

3计算机软件检测的规范化

软件检测的规范化程度取决于软件检测环境是否规范化，只有建立良好的软件检测环境，才能保证软件检测的规范化。因此，软件检测的技术部门应该加强对检测人员的技术支持。目前我国软件检测方面，已经基本实现自动化，摆脱了传统的人工检测模式，检测工具已经日益完善。因此更要加强软件在运行周期的检测频率，保证软件的应用质量。除了前期的检测，更要为用户提供相应的操作说明等。检测过程也要有用户代表参与进行，对各个功能模块详细测试，将结果存档，最后再次对整个软件进行整体测试，确认并分析、评估。

4计算机软件维修的规范化

软件维修是保证软件运行质量的重要手段，维修的规范化就是要求维修人员要按照严格的维修规范来进行，并保证维修之后的软件达到正常运行。在保证解决问题的基础上，降低软件维修带来的负面效应。并尽量在客户的监督下进行，对整个维修过程要进行详细记录，便于日后产品研发有着更多的分析依据。

5结论

计算机技术如今得以全面普及，因此对于计算机软件的开发要求也达到了新的高度，并将随着科学技术水平的不断进步发展，与时俱进。所以，计算机软件开发的规范性也应倍受重视，唯有加强要求，才能使计算机技术更好地适应市场经济发展的需求，为进一步提升我国信息水平国际化的竞争力，做出应有的贡献。

参考文献

[1] 王浩.探析计算机软件开发的规范化[J].计算机光盘软件与应用，2012（09）：19-22.

[2] 赵明亮.计算机应用软件开发技术[J].黑龙江信息科技，2013（26）：59-63.

[3] 王雪，马铁民.计算机软件开发课程设计项目化方案初探[J].辽宁行政学院学报，2012（05）：33-35.