软件项目管理（CMM）经验谈

编者按：

CMM认证是当今IT界最热的话题之一，这表明中国软件企业已开始重视与软件项目管理有关的问题了。为了了解国内软件企业对软件项目管理的认识程度以及他们在软件项目管理方面的具体做法，日前，记者采访了开思、东方通、瑞星三家纯软件公司的相关负责人。三家公司中，东方通业已开始按照CMM规范进行软件开发。在采访中，三家公司的负责人分别介绍了各自企业在软件项目管理方面的经验。开思公司的产品总监石宏峰先生还为记者详细讲解了开思公司的《产品部开发规范》。

经过整理，我们将东方通和瑞星两家公司的负责人在采访中所说的主要内容刊登于此。我们相信，其具有一定的认识价值。另外，我们将开思公司《产品部开发规范》的一部分也刊登于此——我们并不认为开思的规范就是最好的规范。对软件项目管理而言，普适性是不存在的，好坏是相对的，适用不适用才是绝对的——我们相信，其具有一定的参照价值。

加强相关教育和培训

朱律玮（东方通科技首席软件设计师）

杨桦（东方通科技总经理助理）

东方通科技从去年底开始为参加CMM认证（二级）做准备。拟议中正式参评的时间是今年11月。在这之前我们会请国内咨询公司的有关专家和国外的评估师进行两次预评估。

半年多来，我们觉得一切还算顺利。起初我们担心编程人员会有抵触情绪——因为每完成一天的工作或一道工序或一个项目后都要做记录、编文档、写报告，较之以前，工作量无疑是增加了——后来看看，大家对执行CMM规范还是理解的、支持的。

按照CMM规范开展工作后，到目前为止，公司的运营成本是增加了——因为要增加管理人员、撰写文档也需要人手——但从长远看，其会带来降低成本、提高质量、提高用户满意度等好处。对此，我们确信不疑。

与国外相比，我们在软件工程管理方面的差距不仅表现为管理体制、管理方法、管理思想的陈旧，整个软件业的落后才是根源。

个人英雄主义情结、喜欢单打独斗是我们的民族性之一，其在软件人才身上表现得尤为明显，已成为中国软件企业做大的一个瓶颈。造成这种状况的原因，除了国内软件业的发展水平不高、软件项目规模不大和软件企业管理者自身素质不高外，还有很重要的一点，即与软件工程管理有关的教育内容几乎没有。在国外，PSP和GSP均为软件专业学生的必修课，可在国内，这两门课在学校里至今还没有开起来。国外施行的是定岗培训，比如撰写文档就是一门专业课，专门有人修它，毕业后拿它来“安身立命”，国内则是大家过独木桥，统统都学写程序。应该说，目前国内同行对软件工程管理的重要性已有了一定的认识，但在相关人员的培训上下的力气仍远远不够。

其实人才才是最关键的。现在软件业最缺的人才之一就是产品经理，他们是软件工程管理的主角。产品经理必须具备以下素质：具有长期的软件开发经验——般来讲，要在8年以上；了解用户的需求；对产品熟、对市场熟——他可以不了解一个产品的底层技术，但必须了解其功能，能把握其发展方向；具有协调能力。总之，产品经理并不一定非常聪明，并不需要在某一方面特别突出，但要八面玲珑。这样的人才太难找了。东方通的产品经理都是自己培养的。

CMM规范并非只适用于大型软件企业，其也适用于中小型企业。CMM规范只是一个框架、纲要性质的东西。企业在落实它时要细化一次；企业将其落实到具体的某个项目时，要再细化一次；中小企业可以不像大型企业那样将CMM规范细化得那么细，够用就好，不要教条。

实施CMM规范、通过CMM认证有如下一些好处：确定工作流程和方式，从而使产品的质量和开发的可延续性有了保证；可以提高企业在用户中的信誉度，增加企业与强势公司竞争的筹码；可以承接国际大公司的外包项目———美国公司愿意找印度公司来承接其外包项目，就是因为印度公司对CMM规范普遍比较重视，通过CMM认证的软件企业也多；公司不再受制于人，人走了，事照做，这是一个公司成熟的表现。

软件商业化的必要手段

谈文明（北京瑞星科技股份有限公司研发部经理）

中国软件产业发展时间不长，虽然已有部分技术达到国际水平，但由于商业环境还不够完善，在软件技术的商业化与软件工程管理等方面，与国际同行相比，还存在差距。

只有率先将技术先进的产品推向市场的公司才会赢得利润。在瑞星，技术商品化已被当作一种制度，它有助于提高整个企业的素质。

瑞星意识到在充满竞争的环境中要获得成功，天才人物是必不可少的，但他们并不是全部。目前，一个软件工程的成功更多地要依靠科学家、工程师、制造人员和销售人员的协同努力。

在软件商业化的过程之中，建立规范化的易于操作的软件开发行为规范是首先要做的工作。针对杀毒软件的特点，瑞星专门设计了瀑布模型结合增量模型的开发方式，即将项目分阶段来实现。首先实现市场最需求的核心功能，然后在此基础上继续开发，每个单独的阶段都采用瀑布模型的开发方式。

具体地说，一个基本的软件开发流程包括需求阶段、系统设计阶段、详细设计阶段、编码阶段、单元测试阶段、集成测试阶段、系统测试阶段、软件发布软件维护阶段。其中决定软件开发成功与否的关键阶段是：软件需求管理、软件计划管理、软件质量管理和软件配置管理。

为了在用户和处理用户需求的软件项目组之间达成共识（用户由最终用户、高层领导、销售人员和市场调研人员组成），“软件需求规格说明书”是必不可少的。经过正式的评审和确认，其将成为后续工作的基础。

软件项目的实施过程是根据软件项目的资源、约束条件和执行能力确定的，因此需要制定合理的软件工程管理计划，这是项目经理的职责之一。项目经理应定期检查“项目开发计划书”，按照当前项目开发的实际情况，对其进行调整。 为了保证每一个软件产品都合乎需求，需要设立一个负责项目监督和协调的SQA。其会对软件产品是否符合定义好的软件过程中的相应部分进行审查、复审和测试。公司高层主管应该定期参与、评审SQA的活动。

软件配置管理是指在整个工程期间对项目的所有软件配置项进行规范化管理。如采用版本控制软件对软件配置项版本进行版本控制，采用基线管理方法对变化进行控制，即在遵循软件工程标准的基础上对整个软件进行控制和管理，维护其完整性、一致性和可跟踪性。

瑞星努力营造的是一个广泛的网络，研发、制造、销售、分销和服务，连续进行。围绕着产品、市场和开发阶段而不是单纯的技术来组织各项工作。为了这个目的，标准操作是必不可少的。

附录：开思公司《产品部开发规范》 （摘要）

说明：第一部分为《目录》，从中可以看出开思公司《产品部开发规范》的整体架构；第二部分为《开发规范概述》，从中可以看出开思公司在软件项目管理方面的一些具体做法。

1 目 录

1 目的

2 开发规范概述

2．1 应用项目管理管理开发过程

2．2 标准的阶段性开发工作

2．2．1 总体规划

2．2．2 项目立项

2．2．3 需求分析

2．2．4 系统分析

2．2．5 系统设计

2．2．6 编码实现

2．2．7 项目测试

2．2．8 文档制作

2．2．9 项目验收

2．2．10 项目版本化发布

2．3 项目组织

3 开发工作规范

3．1 总体规划阶段

3．1．1 项目需求报告

3．1．1．1 工作定义

3．1．1．2 前序工作及输入成果

3．1．1．3 具体工作内容

3．1．1．3．1 资料收集（可选）

3．1．1．3．2 资料研究（可选）

3．1．1．3．3 项目需求报告编制

3．1．1．3．4项目需求报告讨论准备

3．1．1．3．5 项目需求报告讨论

3．1．1．3．6 项目需求报告修改

3．1．1．3．7 项目需求报告验收

3．1．1．4 参与者及职责

3．1．1．5 输出成果及后序工作

3．1．2 技术可行性实验（可选）

3．1．3 项目计划书

3．2 项目立项

3．2．1 立项申请

3．2．2 项目立项评估

3．2．3 项目进度计划

3．2．4 项目立项审批

3．3 需求分析

3．3．1 资料收集

3．3．2 需求分析编制

3．3．3 讨论准备

3．3．4 需求分析讨论

3．3．5 需求分析修改

3．3．6 需求分析验收

3．4 系统分析

3．4．1 系统分析准备

3．4．2 确定问题域

3．4．3 需求建模

3．4．4 建立分析对象模型

3．4．5 系统分析合并

3．4．6 系统分析测试

3．4．7 系统分析修改（测试后）

3．4．8 系统分析验收

3．5 系统设计

3．5．1 系统设计准备

3．5．2 界面设计

3．5．3 建立设计模型

3．5．4 系统设计合并

3．5．5 对象持久化设计

3．5．6 详细设计

3．5．7 系统设计测试

3．5．8 系统设计修改（测试后）

3．5．9 系统设计验收

3．6 编码实现

3．6．1 编码准备

3．6．2 编码

3．6．3 编码单元测试（测试工作）

3．6．4 单元测试后编码修改

3．6．5 编码联调

3．6．6 集成测试（测试工作）

3．6．7 集成测试后编码修改

3．6．8 系统测试（测试工作）

3．6．9 系统测试后编码修改

3．6．10 编码验收

3．7 项目测试

3．7．1 系统分析测试

3．7．2 系统设计测试

3．7．3 项目测试方案

3．7．4 单元测试

3．7．5 集成测试

3．7．6 系统测试

3．8 文档编制

3．8．1 开发文档整理

3．8．2 用户文档编制

3．8．3 宣传资料编写

3．9 项目验收

3．10 项目版本化发布 4 项目工作总结

4．1 项目任务数

4．1．1 总任务数

4．1．2 阶段任务数

4．2 输出成果

2 开发规范概述

2．1 应用项目管理管理开发过程

产品部接受的各种开发任务均以项目形式出现，包括：新产品开发，产品维护（错误修改、功能增强、缺陷完善等），产品客户化开发及维护等，全程使用项目管理方法进行控制和管理。

根据项目规模和难易有大、小，繁简之分。每个项目的完成周期要控制在6个月以内，项目规模控制在60个人月内。过大的项目需要拆分成多个小的项目来完成。30个人月以上的项目称为大项目，10个人月以内的项目称为小项目。 每个项目要根据具体情况拆分成工作阶段，即里程碑，以便对项目进度的有效控制与检测。

2．2 标准的阶段性开发工作

2．2．1 总体规划

全面规划项目工作的内容，确定目标市场、技术指标和应用要求，划定项目工作范围和交付成果，明确项目实现的总体设想和实施方案；确定项目中的新技术的可行性；明确项目需要用到的各种资源，估算项目的工作量和成本。

2．2．2 项目立项

产品部对要进行的开发项目进行立项申请，提交项目资料。由公司的有关人员对项目进行一系列的风险评估。

通过风险评估的项目，由产品部进行详细进度计划安排，落实时间进度、资源（人员／设备、内部／外部）、技术、资金和费用等，相关资源和资金使用计划要详细列出。

最后所有的项目申请资料、风险评估报告及产品进度计划都要报给公司上级领导审批，进行立项评审。

立项通过的项目才能进入正式的开发工作。

2．2．3 需求分析

根据项目需求报告界定的工作范围和应用方案的设计思路，进一步深入细化应用方案，描述将要开发出计算机系统中包含的各项业务是如何做的，及业务流程、相关理论、运算公式、原理、业务数据、单据报表格式等。

2．2．4 系统分析

根据项目需求分析，对将要建立的满足用户需求的计算机系统进行分析。在系统分析过程中采用面向对象分析技术（OOA）划分需求的问题域，对每一个问题域进行分析和抽象，对其中的事物和它们之间的关系产生正确的认识，找出描述问题域及其系统责任所需的类及对象，定义这些类和对象的属性与服务，以及它们之间所形成的结构、静态联系和动态联系。最终产生一个符合用户需求，并能够直接反映问题域和系统责任的面向对象的分析模型。

2．2．5 系统设计

根据项目需求分析和系统分析，针对具体实现中的人机界面、数据存储、任务管理等内容，运用面向对象设计技术（OOD）进行系统设计。主要包括UI设计、对象设计和数据库表设计。

2．2．6 编码实现

根据系统设计的结果，运用面向对象的方法进行程序编码（OOP）以实现系统设计的内容。

编码过程就是用具体的数据结构来定义对象的属性，用具体的语言来实现服务流程图所表示的算法。在对象设计阶段形成的对象类和关系最后被转换成特殊的程序设计语言、数据库或者硬件的实现。

2．2．7 项目测试

对系统分析、系统设计、程序编码等运用面向对象的方法进行测试（OOT）。项目的测试工作贯穿项目的整个开发过程。主要包括：分析（OOA）测试、设计（OOD）测试和编码（OOP）测试，以及集成测试和系统测试。

2．2．8 文档制作

跟随项目开发过程应产生的文档主要包括三类：

（1）开发文档：分析、设计、编码、测试以及各种开发管理文档等资料；

（2）用户文档：在线帮助，安装指南，使用手册，技术手册，培训教材等；

（3）宣传资料：产品介绍资料，产品白皮书，产品宣传PPT，演示光盘等。

2．2．9 项目验收

对完工的项目按照验收步骤进行验收。验收过程中对项目的情况给予评价。

2．2．10 项目版本化发布

对验收通过的项目进行版本控制，整理项目版本包含的内容并版本化，发布产品发布通告。

2．3 项目组织

每个项目指定一个项目经理进行管理，同时指定一个分析、设计人员（来自分析设计组）负责对技术问题的管理。当任务涉及到多个职能组的工作时（有些项目可能只涉及单一的职能组），由项目经理根据项目工作安排与职能组的组长进行协调，由职能组的组长来协助安排本组承担的项目工作，指定组内人员来完成相关工作。项目经理根据各职能组长的安排汇总编制整个项目的进度计划，并根据最终形成的项目计划对项目进行控制和管理。

项目进行过程中需按照项目管理的要求对项目进行跟踪、总结，各职能组的人员要对这些工作给予积极的支持和配合。产品委员会（或产品部内部）不定期组织人员对项目进行审查，确保项目的进度和质量。

项目完工后需要由产品委员会组织对项目进行验收。

 

第二篇：软件项目失败经验总结

项目失败经验总结

1、在项目初期没有进行风险的管理探讨，项目远景定义和功能集合的详细定义。

当项目走了很远，出现很多问题的时候，领导总算想起要做一个边界定义，但这个时候已经迟了，项目已经变得不可控制。

经验总结：

由于客户一般对计算机不是很了解，和他们交流是用软件行业的专业俗术语，他们根本就不懂，如果用文档也很难把需求写得那么明白，而且文档很多的话，客户都看烦了，很不直观。

如果让客户一看就可以看出这个就是他们想要的，我认为最好的方式就是做系统原形（界面的功能模拟）。

系统原形应该在需求分析师的指导下完成，当然开发只是界面的功能模拟，没有底层代码的实现。这样做的目的有三个好处，一是客户很直观的看到他们的系统是什么样子的以及怎么操作，二是这些开发的成果是可以二次利用的，三是可以更好的激发客户的需求。

2、不注重用户参与。

没有一开始就让用户参与详细需求的制定的做法，大部分都是靠需求采集人员的猜想，猜想往往和实际有差距，造成系统功能不切合实际，与项目实际需求差距大，运行效果差。

经验总结：

项目的开始和结束用户是需要一直参与进来的，我们每做个可以运行的功能等就需要和用户交流，这样可以避免很多风险也可以尽早发现需求的误解的等等。

需求调研前期的《信息化规划》、《目标与范围》和需求调研末期的《软件开发需求规格说明书》都要跟客户签字确认，这样既能保证我们所理解的需求就是客户所要的，也使得项目末期跟客户验收时有据可依。

3、集团化以后，项目经理没有意识到信息化核心问题是管理变革问题，还跟着原来的思路开发软件。

在组织架构、权限、供应商等方面与力和集团理解不一致，没有分别按组织进行区分。

经验总结：

要根据企业业务需求制订策略,调整软件组织结构, 详细设计软件各组织架构之间的逻辑关系，做好这些最基础的功课，避免信息化项目成为无本之木。

4、软件开发人员、设计人员能力的低下、项目经理的管理能力不足。

低素质开发人员由于没有接触过实际业务，无法跟客户沟通，甚至害怕客户提出需求，总是担心客户

第1页，共5页

的需求会增加自己的工作量，不愿配合。导致无法理解真正的需求，也无法改进系统功能。

设计人员能力的低下，设计系统结构时过于定制，系统的可扩展性较弱，给后期维护带来巨大的负担和维护成本的激增。

当出现严重问题时，项目经理没有根据现阶段状况重新评价需求分析结果、开发人工数估算、设计结果等就匆忙采取头痛医头、脚痛医脚的措施，致使问题更严重。

经验总结：

实行双项目经理制度：为开发项目设定两个项目经理岗位，一个负责技术岗位，另一个负责管理岗位。 目前，国内的软件开发企业的项目经理一般都是一名，而且是技术出身的占绝对多数，他们主要擅长的是技术研发，在管理方面先天不足，这不利于项目风险管理和控制。通过增加专门的管理经理岗位，可以弥补技术出身的项目经理的不足，提升软件开发项目的管理水平。而且这样的经验也已得到了国外业界大多企业的认可。

技术岗位：负责技术框架的稳定性和可扩充性、质量的保证、风险的预测以及数据库的设计，模块测试、接口测试、白盒测试等；

对于该项目具体需要多少人员、时间；到底需要什么层次技能的程序组组长和具体开发人员给出详细的计划；

对程序组每周具体的开发目标的进行检测验收，保证开发进度。以及其它需要考虑的问题等，如网络速度，服务器访问量，数据库查询优化，都需要整体考虑。

管理岗位：掌握行业知识、项目的前期调研、需求分析、功能模块架构设计、人员的管理、实施计划的安排执行和跟踪。提交《目标与范围》和需求调研末期的《软件开发需求规格说明书》。

一个项目在前期的工作非常重要，就算是一个错误的话，后面有再强大的开发团队也是白搭。我们还是一个年轻的团队，很需要公司来培养这样的人才，如果是遇到项目，再招外来人员来担当这样的工作，风险是可想而知的。

而且这样的人员肯定是从项目实战中成长起来的，不是有其他软件项目管理经验的人员或者技术开发人员转过来就可以做好的，更不是从书本或者参加某些培训就可以学到的。

5、一味的追求快速开发，时间进度。

每天都加班加点地工作，造成人员流动的扩大以及工作效率的降低。最后无论客户，还是开发人员，都想早点结束项目。

经验总结：

项目中有个不变的金三角法则，即时间、功能和资源。我个人的意见是用我们的实际能力按照一个正常的进度去做，一个项目在功能、时间和资源一定的情况下，没有捷径可以走的，必须一步一个脚印。

6、胡子眉毛一把抓，不分主次。

整个项目没有指定里程碑或规定设计评审期，没有计划什么时间节点完成某一个组织或部门的信息化评审后，再进行下一个阶段的开发计划与实施。摊子铺得太大，软件人员和准备严重不足。

经验总结：

第2页，共5页

根据企业不同的发展阶段，按照规划逐步深入，这样一方面可以避免投资的盲目性，另外一方面在前期的投入收到效果后，再进行下一阶段投入的同时，员工和企业领导也容易接受，软件人员的压力也会相对减少。

7、开发结果不验收测试，开发技术水平低下。

开发结果没经过测试就给客户上线使用，造成报表的数据很多对不上账目，已经打印出来的报表，过几天再打印数据就不一样了。

由于项目经理没有明确要求技术水平，寄希望于员工自己努力，造成打印的单据上，‘毛重’减去‘皮重’ 不等于‘净重’的情况。

经验总结：

必须做好充分准备的开发计划，对于该项目具体需要多少人员、时间；到底需要什么层次技能的程序组组长和具体开发人员给出详细的计划。

8、没有项目总结会议，不重视项目质量。

软件从实施开始就产生了很多问题，但遗憾的是从开始到结束没有组织过一个项目总结会议，问题日积月累，最后导致项目失败。

不重视项目质量。在代码和数据库设计中时间投入很少，这些工作本来就是比较抽象的，需要不断的研究和推敲才能设计好的，但是我们为了时间进度，很快就赶出来了。

经验总结：

每日必须召开项目总结会议，随时捕获风险，当日事当日毕。

软件开发初期的时候，就开始猛抓质量，而不是走“先上线、后优化”的项目常规实施方法。若发现质量不合格的地方，就让开发人员重新返工。

9、软件版本发布周期频繁。

几乎每天都需要进行一次版本更新，有时候1天更新几次。更新完成后，客户无法登陆，软件功能无法使用，以前录入的数据看不见等情况。让客户怨声载道，骂声一片。

经验总结：

发布周期为1周1次或2周1次，在版本更新前，必须做好充分的测试，方可交给客户使用。

10、不重视客户体验，缺少抵御风险的奖励机制。

系统不以客户为中心,不能提高业务部门的工作效率,忽视了客户体验；通常10分钟能完成的工作，工作人员操作软件1小时才能完成。

很多时候加班是没有加班费的，并且在实施过程中又没有任何奖励。所以，员工认为是这套系统拖累了他。虽然项目对公司有益，对他个人就没有多少好处了。

第3页，共5页

经验总结：

公司应该拿出一部分预算，有计划有规模地组织用户进行测试，对操作员给出的体验意见做好详细的记录，并给予充分的重视，对其中有用的软件改进意见给出相应的奖励。做好足够的风险应对计划，抵御这种影响所带来的对系统本身的顺利实施以及实施人员的信心和工作激情的冲击。

11、缺少数据风险意识。

在系统的并行阶段，没有统一的基础数据，如材料编码、单据标准等。数据录入的缺少合理安排，缺少数据风险意识。

用户总是反映报表数据与#4@p单据帐目对不上，录入的#4@p数据丢失了。

软件系统是一个高度集成的系统，一个环节的出错将可能导致一系列的错误，所以，对数据的准确性提出了很高的要求。

经验总结：

必须制定《公司基础信息编码》，搭建了整个信息化制度。在项目实施过程中，针对类似的问题也不能光靠人工对账减少错误，而应该采取一定的控制措施，利用系统设置，做好问题的预防措施。比如我们可以建立每日审账制度，在系统中进行设置，每天录入完成的票据都进行核对，核对完成后进行锁账。 出台《操作规程》，《操作员奖惩办法》等等，规避风险。

12、不注重细节。

天下大事，必做于细。1%的错误往往会导致100%的失败。力和项目在开发的时候，仅仅是满足于“软件可以使用”或“功能能够实现”的情况，并没有关注到每个设计、每次改动、每天的操作。

经验总结：

在此对之前开发过程中一些可以改进的细节列出，进行总结，在今后的开发中将进行改进。

（1）软件每一个打开的窗体都应该写上标题，而不能是默认的标题。

（2）操作按钮位置、操作顺序必须一目了然。

（3）软件的功能都加上快捷键，使它适应不同操作习惯的用户。

（4）每一个窗体都加上“关闭”快捷键，当用户需要关闭窗体时，只需要点“ESC” 键就可以退出，

方便用户的操作。

（5）所有输入文本框都必须按照用户的业务要求进行排列，使用户可以更快更好地输入数据。

（6）进入系统以及退出系统时，如果程序执行比较耗时的代码，应该给出个提醒，而不能让用户傻

等，最好放到线程中处理，不能让主线程出现假死状态。

（7）用户登陆的窗口，应该自动帮用户记住用户名，用户可以自己确定是否要记住密码。

（8）复杂的查询条件，错误提示之后，原来的输入是否都还保存？如果都没有了，用户要再输入一

遍会很烦。

（9）查询错误或无结果，必须有提示。

（10）下拉框中的数据必须有排序。

（11）系统中的各种提示必须要合理，不能有误导用户的情况。

当然，还有许多需要注意的技术和非技术的细节问题，往往我们技术人员觉得不重要的东西偏偏是用户觉得最重要的。我相信，在软件开发的过程中，你只有琢磨你的用户是怎么想的，你才能使我们的软件

第4页，共5页

更加完美，付出得越多，得到的越多。

13、没有结果的结束。

我们几乎听不到有人出来说项目失败了，我们听到的是延期、暂停、取消等等形容词，但是其实，我们其实应该承认，我们有做了一个失败的项目。

经验总结：

我们花了钱，项目失败了，但至少应该买到教训。

项目的成败是变数多多，既有技术的，也有管理的，也有关系的，既有自身的，也有客户的，但是只要我们把我们可以控制的做好了，至少这个项目成功了一半。

第5页，共5页