摘要: 本文运用沃菲尔德教授的复杂性工作程序对广州某软件公司软件项目管理过程从复杂性科学的角度进行了分析，包括描述、诊断、设计及实现四个子过程，归纳出该公司软件项目管理关键问题和要点。最后，结合东西方管理哲学探讨了软件过程改进的实施，包括软件过程改进的三个层次和软件过程改进的知识支持结构。

关键词: 软件、通用设计科学、复杂性工作程序、软件过程、软件项目管理、知识支持结构

美国乔治?梅森大学集成科学现代研究所（Institute for Advanced Study in the Integrative Sciences，IASIS，George Mason University）的沃菲尔德(J.N.Warfield)提出了复杂性工作程序(Work Program of Complexity) [1,2,4-8,10]，它是结构复杂性科学(Structural Complexity of Science)的主要成果，包括两个主要部分：（1）发现（Discovery）复杂性；（2）解决（Resolution）复杂性。具体还可以细分为四个子过程：描述（Description）过程、诊断（Diagnosis）过程、设计（Design）过程、实现（Implementation）过程。描述和诊断构成发现部分，设计和实现构成解决部分。

软件过程(Software Process)是用来生产软件产品的一系列工具、方法和实践。软件过程改进(SPI)的目标是在按计划生产出软件产品的同时改进组织生产更好产品的能力。显然有效地软件过程必须考虑涉及到的所有需要的任务、工具、方法、技能、培训以及对人的激励，其基础是软件项目管理[3,10]。

广州市某软件公司创建于1995年，是广州市高新技术企业。本文按照软件过程改进的复杂性工作程序对其软件项目管理过程从复杂性科学的角度进行了分析。

1 描述软件过程

1.1 软件过程的基本活动

软件项目一般按照接受委托、需求分析、概要设计、实现、验证与确认五个阶段进行（图1）。

（1）接受委托。包括售前和调研过程，形成需求调研报告和可行性研究报告，内部下达软件开发任务书；（2）需求分析。将调研的结果转化成需求规格说明书。这是软件工程管理的基线，是验收的最重要的依据，需要经过确认才能生效；（3）概要设计。主要工作是概要设计和数据库设计;（4）构建。在概要设计的基础上细化，要贯彻系统需求和设计思路，同时需要遵守相应的编码规范、界面设计规范、接口规范的约束；（5）验证与确认。按照给定的依据验证系统，包括系列的测试活动、试运行和评价，形成项目测试分析报告、试运行报告、验收报告和项目开发总结报告。

1.2 软件过程活动的认知障碍

缺乏合理组织的开发组常常以程序员为主，仔细分析这些程序员的工作中存在的问题：(1) 前期跟着感觉走，后期跟着操作员的零散意见走（需求描述不充分，项目无计划）；(2) 冥思苦想，边想边做，还要写文档（项目无计划，过程不规范）；(3) 苦苦琢磨，缺少指导，后期发现系统难以对接（过程不规范，无评测手段）；(4) 项目完工后，发现项目亏本（项目无计划，无评测手段）。他们感觉到疲倦、痛苦、迷茫，毫无成就感（复杂性），这些现象非常普遍。

2 诊断软件过程

某软件公司认为软件项目管理有以下六个目标努力：（1）可移交性。文档化、规范化能有效地解决这一问题；（2）计划性。横向和纵向的多个事件靠计划串起来，良好的计划能统一团队行动，提高对项目的控制能力；（3）沟通性。为了快捷、有效地传递消息，项目组需要认真考虑如何设计项目中的沟通规则；（4）主动性。项目经理在项目期间始终要处于主动地位，担任起项目“导演”的角色。尤其在客户定制类的开发项目中更应时刻掌握主动权，不能被用户牵着鼻子走；（5）质量稳定性。要加强质量成本意识，加强质量成本分析，使预防成本、鉴定成本、内部损失与外部损失之和最小化；（6）企业知识管理。尽量做到不犯相同的错误，不重复投入，知识最大范围的共享，成果尽量再用。

3 设计软件过程

按照CMM的组织模型，设立SEPG（软件工程过程组，类似于技术组）、SQA（质量保证组）和SEG（软件工程组），形成立法、监督和执法的制衡体系。该公司已经开发出了比较完整的正式的软件过程管理文档，并建立了知识管理中心。

3.1技术组

技术组的特点：（1）包含了SEPG组的职能；（2）不直接承担完整的项目任务；（3）掌握企业的核心技术，管理着企业的技术储备。

技术组的职能： (1) 技术标准：制订技术标准与规范，形成企业内部统一的技术语言，有利于新手学习、技术交流和团队间的互相支援；(2) 技术积累：编制技术规划，有计划地引进新技术和组织研发，加强技术储备，并实现技术共享，评估和提升企业的技术实力；(3) 知识复用：管理技术成果和知识库，保证最大限度的复用，缩短开发周期；(4) 人员素质：组织技术培训和技术交流，负责技术考核，加快人员素质提高；(5) 技术把关：组织技术评审，作好项目的技术把关和方案审核(图2)。

技术组的岗位：（1）技术经理：技术规划，技术考核和制订技术管理制度；（2）系统分析员：负责技术分析，方案审核和项目评审；（3）研发工程师：负责开发公共组件；（4）档案管理员：管理产品库、共享模块库、知识库和题库。很多企业的规模难以建立该小组，可以由部门经理、档案管理人员、某些技术高手组成虚拟团队。当然，效果通常要差一些。

3.2 开发组

按照技术再分成若干常规专业技术不同的小组，如网络技术、Java技术、VB技术和PB技术等，待具体的项目开展时，再由项目经理根据项目的技术需求临时组合成项目组。项目组的组织非常重要，需要根据项目的规模与技术特点具体分析决定。必要时，可以设立项目总监职务，担负项目总控、跨组织协调和策略管理的职责。

3.3 质保组

质量保证的具体目标视具体项目而定，在质量保证投入与质量损失之间取得平衡，树立质量成本观念和客户满意度意识，把握好质保工作的方向，将问题消除在前期。质量是开发出来的，不是测试得来的。影响质量的因素诸多，主要在开发过程质量、测试工具、测试方法、测试人员素质、测试环境和设计质量等方面。通过过程、技术和人员的有机集成来实现了软件过程绩效模型中的过程管理主题。

4 实施软件过程改进

4.1 充分利用现成资源

企业积累的可再用资源(组件、技术、方法、文档模板、近似的案例、业务专家和成员的经验等)，都是开发小组可以利用的现成资源，项目管理者要善于利用这些资源，特别是善于挖掘隐含资源，以缩短开发周期。

4.2 加强计划性

要在重视计划的同时，也加强对各种变化的管理，就可以得到计划带来的两大好处：（1）减少不确定因素。（2）有助于提高效率。

4.3 控制项目中的各种变化

项目组完全按照计划完成整个项目的可能性非常小，讲计划而回避变化也是行不通的。要控制项目朝着有利的方向变化，预防不利变化，消除恶性循环。

4.4 加强需求管理

大部分项目的失败是因需求不清楚造成的。需求分析的目的是弄清需求，确认需求，明确边界，减少因需求不确定的返工。获取需求的步骤如下：（1）选人。选择合适的需求调研人员，对于整个需求的质量保证关系重大。需求调研和分析人员必须具备丰富的有较好经验和相关专业的知识；（2）调研。先要把握整体，然后再了解细节，采取自顶向下的路线展开。从横向来看，要按照业务流程从下游到上游倒推(先输出再输入)调研。采取多种调研方式获取需求效果会更好，如表格填写、面对面交流等；（3）成文。编写需求规格说明书；（4）确认。确认需求，双方签字形成有效的依据；（5）变更管理。管理需求变更，填写需求变更单，得到确认，形成需求跟踪说明书。

4.5 沟通管理

要使沟通产生应有的效果，尽量采用e-mail或电话等形式，以提高沟通效率。对于共同的决议和必须作为重要依据的沟通内容，要尽量采用传真等书面形式沟通，以提高沟通的质量。

4.6文档策略

可以从以下几方面加强文档的管理工作：(1) 规范性。建立统一的文档语言规范，建立文档的编、审、批、发布、变更规则。建立完整的文档交付清单，让项目计划人员从中挑选；(2)易学性。建立文档编写指南，与文档模板一起让开发人员共享，增强文档的易学性；(3)可读性。多用图表，采用从粗到细，由表及里的表达形式。提高文档的粒度。方便监理、评审和质保等人员的参与。按照文档的用途和读者(开发、使用、培训、实施、销售、售后服务和测试等人员)的职业特点和专业特点编写文档，减少误解和费解；(4) 可移植性。注意文档的结构，方便移植到其它项目；(5) 工具支持。采用文档工具(如：UML类工具等)自动产生文档；(6) 持续改进。指导编写文档的人员不断改进文档编写方法。

4.7 知识管理

项目中要注重总结、分析、提炼有用知识存档。表1是知识管理的分类和举例，有助于开展知识管理。知识的存在形式：文书档案(文件、手册和图纸中的知识)、人脑中的隐性知识、固化的过程知识(凝聚在产品、工作过程、经营过程中，并被在不断运用的制度和方法)。

知识管理的任务：建立知识贮备、改进知识获取方式、改善知识环境和管理知识资产。设置知识库管理岗位，负责收集和整理知识。建立知识网络，随时为需要的项目组提供查询。集思广益，充分利用组织中的隐性知识。图3说明了实施软件项目管理的关键问题和要点。

5 软件过程改进实施的探讨

本文经过认真思考，结合中国实际情况，对软件过程改进的知识支持结构提出若干观点（图4和图5），起抛砖引玉之用。显然，软件过程改进的基础就是软件项目管理。

5.1软件过程改进的三个层次

（1）任务管理 (项目组级)：专注于项目组内部的管理，强调预见性和可控性。将项目大任务划分成便于控制的任务单位，按照时间和人(或小组)落实这些任务，形成开发计划和派工单，然后监督任务的执行情况。

（2）资源管理 (组织级)：将项目当成企业积累的活动，重视整个组织的价值，特别关注效益问题，配以相应的资源策略。只有这样，才能将资源充分挖掘并形成最佳搭配，让资源(包括外部资源、隐含资源)最大限度地发挥作用，获得最好的投入产出比，并将项目产生的新知识沉淀下来，使资源得到充分利用。

（3）关系管理 (环境级)：将项目当成建立各方紧密关系的纽带，使项目成员从中得到精神价值。制订个性化的项目策略，不仅能满足于开发任务和企业效益的需要，还能使得项目各方面人员的感觉良好。通过项目做好与客户、员工、分包方、供应商的关系，可以增强团队凝聚力，提高参与者的成就感。

5.2软件过程改进的知识支持结构

图5是软件过程改进的知识支持结构，什么是支持结构？它由带文字的方框和连接方框的箭头构成。如果有一条路径从某个方框指向某个路径另一端的方框，那么下面的方框就支持路径另一端的方框。这就是理解本支持结构的基本规则。“支持”是关键，说明你可以从更低级的方框找到开发上面方框的信息[8]。

追求“三成”。“客户满意、企业满意、参与者满意”，即系统成功地研制出来并交付客户使用、成本合理、参与者有成就感(成果、成本和成就感，简称“三成”)，这样的项目管理改进工作能在软件企业中开花结果，应验了“得道者多助”的古训，也符合“事理-物理-人理”。软件过程复杂性工作程序、软件过程改进知识技术（包括PMI的项目管理知识体系（Project Management Body of Knowledge，PMBOK, http://www.pmi.org/）, 戴明的PDCA质量环以及IEEE的软件工程知识体系（Software Engineering Body of Knowledge, SWEBOK, http://www.swebok.org/）、软件企业模型和项目商业运作见文献[5-12]。所谓知识融合（深度集成）是指东方管理哲学、西方管理哲学、感性行为和理性逻辑的知识集成包括互补和融合，也包括整体思维和分析思维，形象思维和逻辑思维，演绎方法和归纳方法等的互补和融合，这里的知识既有言传性知识也有意会型知识,以及知识的社会化、外部化、组合化和内部化，系统直觉、知识融合和知识运用见文献[13-14]。

逐步制订标准、规范、管理制度，遵循软件开发的规律。制定的制度应能根据具体项目的实际情况取得合理剪裁，并资源得到充分挖掘和使用。同时，制度的制定还应注意人员的特长最佳组合，抓住各方面人员在项目中的心理需求并尽量满足，做到人员积极参与，有效配合。只有这样，项目管理水平将得到逐步提高。制度的制定当中，规律为“天理”，具体情形为“地形”，结合人的需求(物质需求和精神需求)，统称为“天、地、人”，符合中国古代的“三元”。

“三成”指明软件过程改进的方向（战略级），“三元”说明了软件过程改进的途径（战术级），前面提到的“三级”将项目侧重面分为任务、资源、关系三个档次，作为评价软件过程改进水平的等级划分原则。

管理软件过程复杂性要把复杂问题通过实质化而变为抽象化（例如：软件过程复杂性命题等），抽象化问题通过交互认知过程而变为具体化（例如：软件过程改进复杂性工作程序等），具体化问题通过不断学习过程而变为结构化（例如：项目管理知识体系和软件工程知识体系等），结构化问题可通过项目管理商业运作来实现企业的商业目标（例如：软件企业结构模型等）。东方管理哲学、西方管理哲学、感性行为和理性逻辑的知识融合可能就是软件过程改进的基础和关键。换言之，隐性知识的社会化。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号