a、需求分析

需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的经验来看，这
个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户
领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下
的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费
的代价越是昂贵，也越发影响系统的工期和系统的质量。

解决系统分析错误的方法我们公司通常采用邀请用户参与进行需求评定，然后对其用户的
意见由质保成员跟踪检测是否纳入需求规格说明书，同时与用户签字确认形成需求基线，交由
配置管理员放入配置管理库。

虽然尽早的邀请用户参与，仍然避免不了项目进行中用户的需求变更请求。对于开发过程
存在的需求变动，我们要求用户填写变更申请单发送给项目配置管理员，在通过配置配置员转
交质保小组，负责组织专家小组和项目组成员一起讨论实施变更的可行性及实施后所带来的影
响，小的变更则直接记录入变更记录原因分析项和风险项栏，大的变更则需要形成正式的变更
报告，无论那种变更都需要对相应的文档实施同步变更（包括需求规格说明书、详细设计文、
安装手册、操作手册等）。但是对于无法实现或是变更会带来巨大的影响而将导致进度的延
期，这时，我们将变更报告提交给用户或邀请用户进行协调会议，讨论变更取舍问题或是项目
进度变更问题。

决定变更之后，由项目经理组织实施变更，测试人员检测变更结果，而质保小组成员监督
变更实施过程并协助配置管理员对变更后的成果物进行版本控制。变更实施完后，上线前还需
要指定人员协助用户一同测试并由用户签字后同意方可上线。

b、系统设计

优良的体系结构应当具备可扩展性和可配置性，而好的体系结构则需要好的设计方法，自
然设计选型成为了系统设计首要的工作，究竟是采用哪种设计方法好呢？

对于设计选型不能一概而论，需要针对项目的结构、项目的特征和用户的需求来分析，同
样也要考虑到参与项目小组成员的素质，如果其中大部分都没有从事过面向对象的设计且项目
进对紧迫，这样没有多余的时间来培训小组成员来掌握面向对象的设计方法，尽管众所周知面
向对象设计方法的优势，我们还是不如采用面向过程的方式（除用户指定开发设计方式外）可
以减少项目承担的技术风险。

我们公司有过一个项目，用户指定需要采用面向对象分析、设计和开发，且开发周期短，
在无赖的情况下，项目小组只能选用面向对象的软件开发过程，由于项目小组很少从事过面向
对象的开发，经验缺乏，导致项目上马后项目进度延误，项目没有达到预期的效果。

针对此次开发，我们分析其原因，发现小组成员在开发过程中对于新技术互相交流少，各
自有各自的理解和想法，造成理解上的不一致性，导致工作重复性高，滞后项目进度。建议解
决方法是项目组成员采用集中办公，分块学习，学习的成果马上向项目相关人员发布，再由配
置管理员对其发布的文档进行整理、规类放入配置库以供大家共享。这样方便大家的互相学
习，减少重复的工作。在这次开发中我们公司从管理人员、设计人员到开发人员都汲取了很多
教训，同时经过此次项目的开发，小组成员也积累了丰富的面向对象的开发经验。

除设计选型，还有一个容易被忽视的问题，就是公共类开发。公共类开发可以减少工作中
的重复工作，降低开发成本。这要求我们再设计阶段通过对用户需求的仔细研究，尽可能的识
别出公共类，并进行定义指定专人负责设计通知其它设计人员，以减少重复工作。对于项目组
提供的设计文档，由质保小组组织技术专家、项目组设计人员、开发人员和测试人员对其设计
文档的评审，检测设计文档对其下一阶段工作的可行性，及时发现设计中可能存在的错误，降
低项目开发风险，同时确保设计文档能为开发人员、测试人员提供切实的指导。对于可复用的
设计进行提取作为公共库设计和开发，提供项目组或整个公司重用。最后交由配置管理员进行
设计文档的版本控制。

c、实现

实现也就是代码的生产过程。这里不仅包括代码的产生，同时也包括测试用例的产生。针对
上一阶段提供详细设计，程序员开始编码并且调试程序，测试人员则根据设计进行测试用例的
设计，设计出来的用例需要得到项目组成员认可由项目经理审核通过才能进入配置库。同时程
序员调试完程序提交测试人员进行程序正确性检测。

d、文档管理

文档维护主要是配置管理小组的工作。文档从用途上分主要分为内部文档和外部文档。

内部文档包括： 项目开发计划； 需求分析； 体系结构设计说明； 详细设计说明； 构
件索引； 构件成分说明； 构件接口及调用说明； 组件索引； 组件接口及调用说明； 类索
引； 类属性及方法说明； 测试报告； 测试统计报告； 质量监督报告； 源代码； 文档分类
版本索引； 软件安装打包文件。

外部文档主要包括： 软件安装手册； 软件操作手册； 在线帮助； 系统性能指标报
告； 系统操作索引。

如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项
目的进度，这仍然是一个比较难解决的问题。解决此问题，其核心仍然是个"度"的问题。在本
项目的开发中，配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。当有文档
模板后需要书写文档的人员只剩下"填空"的工作，从某种意义上讲，书写文档的速度会加快。
如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完
成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复
审通过后方可以正式提交，进入软件配置管理的循环中。

配置管理小组真正核心的工作是对文档的组织管理。根据文档的不同，文档的来源也不
同，有些是通过质量保证小组经过复审之后转交给配置管理小组，有些则会直接从文档的出处
到达配置管理小组。文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对
单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到
后百分之十的时候起到拉动项目的作用。

从以往做大项目的经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文
档要稍慢，但随着项目的进展，各个部门需要配合越来越多，开发者越来越需要知道其他人员
的开发思路和开发过程，才能使自己的开发向前推进。一个明显的例子就是系统整合，或者某
些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。

3、系统维护质量保证

在我们公司，维护小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项
目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。所以通常项目维
护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，而且与
客户也不陌生，以便能够以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问
题，全部由维护小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制
流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通
过测试后方可提交用户。

维护小组的人员基本上是按项目跟进的。当一个项目刚刚交付用户时，在维护小组有较多
的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。