项目管理 1

学习内容

Ø 认识毕业项目

Ø 软件企业项目常见的团队和角色

Ø 软件工程相关知识

Ø 各种软件项目文档

Ø 项目计划的制定

能力目标

Ø 认识毕业项目的地位和重要性

Ø 了解软件企业的团队构成

Ø 了解和项目开发相关的软件工程知识

Ø 了解项目文档及构成

Ø 掌握使用Project制定项目计划

本章简介

这是一次实战演习，但我们保证这次实战还原了企业开发的真实环境。想知道企业中是怎样开发一个项目的么？想知道真正的项目开发包括哪些阶段么？想知道项目开发的常见进程安排（软件模型）么？想知道在真正的项目开发中什么样的人才更有价值么？请随我们经历项目开发的全过程，亲自历练，亲身体验这一切的项目过程，获得企业开发需要的最宝贵的经验。

本章是毕业设计项目的开始，其中我们将明确本次毕业设计的目标，明确本次毕业设计的日程安排，明确毕业设计中的小组分工和角色安排，同自己所在组的组员一起讨论和实践。我们还将学习制定软件开发计划的目的、原则和步骤，然后选择自己所在小组要完成的二年项目命题，最后一起来用Microsoft Project工具制定自己二年项目的项目计划。

 

核心技能部分

1.1 毕业设计安排

1.1.1 毕业项目在就业中的重要性

学习中的时间，总是行进的很快。转眼间学员们已经在AAA软件学院经过了一年多的辛苦努力。在这段艰苦而又充实的时光中，我们学习了各种知识，可能大家会认为自己的能力已经很强——毕竟比起刚来的那段日子，我们学到了十几门不同概念、不同方向的技术。现在的我们，能够熟练地打开IDE，在很短的时间内，飞快地敲写一两个我们认为能够证明自己技术的案例，很多学员就此认为，我们的能力已经很强。学员们是否忽略了什么呢？

多年的教育经验表明，这个时期的学员，的确容易忽略某些东西，即是否能够将所学知识融会贯通，是否学会了解决实际问题的思维方法。于是，很多人到企业才发现自己还有很多不会的东西。尤其是知识的深度和熟练程度比不上那些有工作经验的人员。

如何弥补这个差距，提升实力呢？

与其在正式应聘时被公司婉拒，不如应聘前做好实力提升的工作。面试时如果达不到公司的要求，是不可能得到预期的职务的。想进入企业后再去提升能力，这样的机会已经越来越少。过去的口头禅：“给我一个机会，我将还你一个奇迹”，现在已经变成了一句空口号。因为随着软件业求职人员的逐渐增多，可供选择的软件人才也越来越多，每个公司现在都有足够的资本去这样认为：过去没有累积实力的人，将来也很难表现实力。所以，现在的软件公司对应聘开发岗位的人员要求，往往都增加了“一年或多年的工作经验”这一项。

那么企业希望招聘有项目经验的开发人员，主要是基于哪些方面考虑的呢？

(1) 来之能战，来了就能干活。一个人把做过的事情“再重复一遍”是很轻松的事情。一般企业会给新人一个适应期，这点倒不是最重要的。

(2) 战之能胜，写出的代码很规范，能根据模版书写简单文档，不犯初级错误。如果你在以前的经验中，把常见的错误都犯一遍了，就能在实际工作中下意识地避免，不蹈覆辙，能够解决开发过程中的常见错误。只有真正地做过一个项目才有可能知道在项目中会遇到什么样的问题，人们可能会犯什么样的错误，什么地方是应该注意的，什么地方不需要花费太多精力。其实很多问题都不仅仅是技术层面的问题，这些问题只有经过亲自历练才能体会。

(3) 主动沟通，勇于负责。不会就问，遇到问题不自己闷着。自己在做什么，是什么进度，要主动报告给项目团队的负责人。也要主动了解别人在做什么，不做重复性劳动。学习并锻炼与各种类型、各种性格的团队成员合作的能力。就事论事，不以自己的喜好妄自论断，不把个人情绪带到工作中。

以上这三点，其实也就是我们所说的“项目经验”了。如果一个开发人员能够满足这三点要求，我们就认为他具有了“至少一年的项目经验”。

项目经验不是通过简单的“教”和“学”就能学到的。不下水永远学不会游泳，项目经验只有亲自参与项目，从点滴历练中积累。知识、技术和技能是其中的一个侧面，更重要的是人与人之间在责任和义务这个主题上的交流。现在，我们的毕业项目给了我们这样一个机会，一个在全真实战环境下帮助你获得项目经验的机会。

1.1.2 毕业设计的目标

1. 什么是项目

我们现在要开发一个软件项目。那么什么是项目呢？

小周每天8:30上班，17:30下班是不是项目？神舟9号飞船探月是不是项目？2008年奥运会的举办是不是项目？

项目，其实是一个MBA课程中管理学方面的概念。项目具有如下几个特征：

(1) 项目的一次性。一次性是项目区别于其他任务（比如：组装汽车）的基本特征。这意味着每个项目都有它的特殊之处，不存在两个完全相同的项目。

(2) 项目目标的明确性。项目作为一类特别设立的活动有其明确的目标，一般由成果性目标和约束性目标组成。其中，成果性目标是项目的来源（比如：给中国电信的一套计费系统）；约束性目标又称为限制条件，是实现成果性目标的客观条件（比如，项目开发过程中要遵循国家法律法规）和人为约束目标（比如：项目组成员的去留和项目的最后期限）的统称。项目最主要的约束目标为时间和成本。

(3) 项目的整体性。项目是为实现目标而开展任务的集合，它不是一项项孤立的活动，而是一系列活动的有机组合，从而形成的一个完整的过程。强调项目的整体性也就是强调项目的过程性和系统性。

通过以上几点的定义，我们看，小周每日按时上下班这一事件，因为不具有项目的“一次性”特征，不属于项目的范畴；而神舟9号飞船探月则具有典型的项目特征；2008年的北京奥运会，虽然浩大，但是也可以从中辨识出项目的诸多特征。

项目的特征属性是项目所固有的，是区别于其他活动的根本所在。学员们在毕业设计完成的过程中，要时刻注意项目这几个特征，在约定的时间内完成一个高质量的项目！

2. 毕业设计的目标

通过两个学期，一个学年课程的学习，我们已经学习并掌握了网页开发、数据库、Java软件开发等技能，这一切都是为现在的毕业项目所准备的。

通过完成毕业设计项目，我们不仅可以积累项目经验、行业经验、团队开发的经验，还可以学到实用软件工程的知识。

一般在公司，我们做什么项目只能“服从经理安排”，可现在每个小组可以从教员老师提供的项目选择中选择适合自己小组的项目或者自己小组感兴趣的项目来实践。 

通过参与并完成毕业设计，你能够：

(1) 积累到项目经验。

(2) 积累到行业经验。

(3) 积累到团队开发经验。

(4) 学习到实用软件工程知识。

1.1.3 毕业设计的日程安排

本次毕业设计，我们将分为两个阶段来进行。

在企业中开发一个项目的时候，肯定不是上来就开始编写代码的，一般在正式开发前有一个启动和准备的阶段。在这个阶段组建软件开发项目队伍，对项目组成员进行业务上（让开发人员了解将要开发的系统的功能）和技术上的培训，确保大家都能以最好的状态投入到正式的开发工作中。

我们的毕业设计也这样组织。

首先，在第一阶段让大家准备好，无论是从技术上，还是团队上都准备好。在第一阶段结束的时候，小组中的每一个人都要能够熟练地运用我们提供的技术框架实现简单的增删改查功能。在这个阶段大家要互相帮助，基础好的同学要主动帮助同组有困难的同学，基础一般的同学更要积极主动，好好利用这个阶段追上大家！

然后，在第二个阶段中全力完成项目。

1.2 分组和组内分工

明确了毕业设计的目标和日程安排后，你一定迫不及待地想动手开始项目了吧？别着急，二年的项目，我们是通过团队组织，分工合作来完成的。下面，我们首先来认识什么是团队。

1.2.1 什么团队

有人说，团队就是一群人合作做一件事情。仅仅这样就行了么？答案是否定的。在我们这里，团队的定义应该是：团队是一个由少数成员组成的小组，小组成员有着共同的目标，具备相辅相成的技术或技能，有共同的评估和做事的方法，他们共同承担最终的结果和责任。

大海航船，难免会遭到激流与逆风的袭击。在激烈的市场竞争中，软件公司运营同样会有不测风云，比如国家政策的变化，公司骨干力量的突然出走等，都会给企业重重的一击。所以，每个公司都在进行着各种各样的建设，以增强公司的实力，保持公司可持续发展。在这当中，公司团队精神的培养是至关重要的。什么是团队精神，可谓是众说纷纭，我们认为，团队精神就是公司上下目标一致、共同奋斗、共同进退的精神。就如航行于大海中的舰队，有智慧的舰长的统一指挥，有勇敢船员的群策群力，在这艘船上，每一个人都发挥着重要的作用，所有的人都不可或缺。因此，优秀的企业家都深深地懂得团队精神的重要，任何一个成功的企业都有一个与企业文化一脉相承的团队精神。所以说，团队精神是软件产业发展的必然要求。

1.2.2 软件项目常见的团队和角色

现在你在备受团队精神鼓舞的同时，也许在想这样的问题：在毕业设计项目中我应该属于什么样的团队呢？

下面，我们先给出三种常见的软件开发团队组织结构。

第一种：小型软件公司团队组织结构。如图1.1.1所示，在小型软件公司中，人员配置精简实用。由项目经理直接带领开发经理、质量保障工程师、开发工程师和测试工程师来完成项目。

 

图1.1.1 小型软件公司团队组织结构

这种组织结构的好处在于分工灵活，但同时每个人也是一个“多面手”，例如，开发经理既要有很强的技术，也要有相应的管理经验；软件工程师除了进行程序开发，也要懂得数据库设计开发，并且要了解一些软件测试知识。而且通常，一个人会担负多个角色，团队中的每个人几乎都要担负软件工程师和测试工程师的职责。

第二种：微软公司团队组织结构。如图1.1.2所示，微软公司的团队组织结构可以说是相当完善了，在这种组织结构中，各团队人员分工很细致，而且职责明确，人员之间的接口明确。不过，构建这种项目团队的成本是很高的。

 

图1.1.2 微软公司团队组织结构

第三种：大型软件公司团队组织结构，如图1.1.3所示，在这种组织结构中，人员配置比较齐备，计划/需求/设计/开发/测试/验收各个阶段都有专人负责。但同时人员组织分成了四层，比起小型软件公司团队组织结构来，管理上增加了困难。

 

图1.1.3 大型软件公司团队组织结构

1.2.3 毕业设计项目的团队组织形式

在本次毕业设计中，鉴于我们面临的项目，比起大型的应用系统来规模还比较小，我们的团队组织形式将采用第一种，即小型公司团队组织结构。其中每个角色的职责定义如下：

(1) 项目经理（Project Manager，PM）：项目负责人。一般来讲，项目经理的职责包括：承担责任；需求管理；协调、组织、解决团队问题；控制进度、获取并调配资源（分配任务）；召集会议；做出决定；风险控制，解决危机；考核团队成员。在我们的毕业设计中，项目经理（小组长）要协调组织大家完成项目，定期检查大家的进度等。

(2) 开发经理（Team Technology Leader，TTL）：团队技术负责人。一般开发经理的职责包括：负责架构设计（技术决策）；参与需求管理；在技术上训练并指导团队；召集技术会议；组织团队培训；记录团队成员技能提升等。在我们的毕业设计项目中，开发经理要主动帮助技术上有困难的同学，但不能代替对方完成任务。

(3) 质量保障工程师（Quality Assurance，QA）：一般负责配置管理，有效地控制各种项目文档和代码当前版本的唯一性；按照发布计划获得并发布版本，提交测试等。负责过程控制和质量保证的相关工作。

(4) 开发工程师（Software Engineer，SE）：按照需求规格说明书的描述和项目规范开发程序代码，实现功能，修正开发过程中产生的缺陷。

(5) 测试工程师（Testing Engineer，TE）：按照需求规格说明书的描述和项目规范对发布的版本软件进行黑盒测试，发现并报告软件缺陷，督促开发工程师修正缺陷。

在本次课程中，我们将对班级成员进行分组，分组规则即小组任务如下：

(1) 每个小组4人（特殊情况下可以3人或5人）。

(2) 每个小组所有成员都承担开发工程师（SE）和测试工程师（TE）的职责。

(3) 每个小组都设置一个项目经理（PM，小组长）、开发经理（TTL，技术负责人）和一个质量保证工程师（QA，负责配置管理、SVN的使用）。

 

1.3 软件工程相关概念

知道了项目是什么，了解了软件开发中常见的团队组织结构，对于指导我们高质量地完成项目帮助不小，但是仅仅了解这些还有些欠缺，软件开发归根结底是工程学上的一种常见的生产活动，要认识清楚软件开发全过程，并更好地指导我们开发出高质量的软件产品，我们还需要认识软件开发过程中的各种规律和常识，这就需要我们初步掌握一些软件工程方面的概念和知识。

下面，我们就软件项目开发周期、常见的软件项目开发模式、项目开发进度和风险管理，以及软件开发过程的文档等方面，系统地介绍一些基本的软件工程常识。

1.3.1 软件项目开发的周期

和工程学的概念对比，研究软件工作的特点进一步打开了我们的眼界。当我们全面分析软件各个“工序”的工作时，就应该认识到程序编写只是软件工作的一个部分。在这道工序的前后均有更重要的“工序”。正如任何其它事物一样，他们从发生、发展到成熟，以至衰亡，都有一个历史发展的过程。计算机软件的生存期（Life Cycle）则包括：计划、需求分析、设计、程序编写、测试和运行维护六个步骤。这些步骤的主要任务概括如下：

(1) 计划（Planning）：确定要开发软件的总目标，给出它的功能、性能、可靠性以及接口等方面的设想。研究完成该项软件任务的可行性，探讨解决问题的方案。并且对可供使用的资源（如计算机软、硬件、人力等）、成本、可取得的效益和开发的进度做出估计，指定完成开发任务的实施计划（Implementation Plan）。

(2) 需求分析（Requirement Analysis）：对开发的软件进行详细的定义。这包括软件人员和用户共同讨论决定，哪些需求是可以满足的，并加以确切地描述。写出软件需求说明书（Software Requirement Specifications）或功能说明书（System Function Specifications）以及初步的系统用户手册（System User’s Manual），提交管理机构评审。

(3) 软件设计（Software Design）：设计是软件工程的技术核心。在设计阶段中设计人员要把已确定了的各项需求转换成一个相应的体系结构，结构中每一组成部分是意义明确的模块，每个模块都和某些需求相对应，即所谓概要设计（Preliminary Design）。进而对每个模块要完成的工作进行具体的描述，以便为程序编写打下基础，即所谓详细设计（Detail Design）。所有设计中的考虑都应以设计说明书的形式加以详细描述，以供后继工作使用并提交审查。

(4) 程序编写（Coding，Programming）：把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的“源程序”。这步骤的工作也称为编码。自然，写出的程序应该是结构良好，清晰易读的，且与设计相一致的。

(5) 测试（Testing）：测试是保证软件质量的重要手段，其主要方式是在设计测试用例的基础上检验软件的各个组成部分。首先进行单元测试（Unit Testing）以发现模块在功能和结构方面的问题，其次将已测试过的模块组装起来进行组装测试，最后按所规定的需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付给用户使用。

(6) 运行和维护（Run and Maintenance）：已交付的软件投入正式使用，便进入运行阶段。这个阶段可能持续若干年甚至几十年。软件在运行中可能由于多方面的原因，需要对它进行修改。其原因可能有：运行中发现了软件中的错误需要修正；为了适应变化了的软件工作环境，需做适当变更；为增强软件的功能需作变更等。

下图1.1.4给出了软件生存期的瀑布模型。这个模型表明，在生存期中任何一个软件都要按顺序经历上述六个步骤，如同瀑布流水，逐级下落。然而，在工程实践中，为了确保软件产品的质量，每个步骤完成以后都需要进行复查，如果发现了问题就应停止前进，沿着所经历的步骤返工。这就构成了图中各步骤间的向上流线。下图还指明了六个步骤可以划分为三个阶段，即软件定义、软件开发和软件维护。

 

图1.1.4 软件生存期的瀑布模型

图1.1.4为我们展示了软件项目开发中软件生存周期的概念，在表示软件生存期的同时，该图还为我们引出了“瀑布模型”的概念。什么是瀑布模型呢？瀑布模型，其实是常见的软件项目开发模型中的一种。软件开发模型，指定了软件生存期的各个阶段的先后顺序和时间分配。下面，我们就来看看，除了瀑布模型以外，到底还有哪些常见的软件项目开发模型。

1.3.2 常见的软件项目开发模型

最早出现的软件开发模型是1970年提出的瀑布模型。该模型给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，投入使用。瀑布模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的需求等缺点。

下面我们列出一些典型的开发模型及其使用条件：

1. 边做边改模型（Build-and-Fix Model）

遗憾的是，许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

 

图1.1.5 边做边改模型

在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模化的开发来说都不能令人满意。

2. 瀑布模型（Waterfall Model）

1970年Winston Royce提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

 

图1.1.6 瀑布模型

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

(1) 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；

(2) 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

(3) 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

3. 快速原型模型（Rapid Prototype Model）

快速原型模型第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。

 

 

图1.1.7 快速原型模型

通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

4. 增量模型（Incremental Model）

增量模型又称演化模型。与建造大厦相同，软件也是一步一步建造起来的，在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。

 

图1.1.8 增量模型

增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：

(1) 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

(2) 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。

5. 螺旋模型（Spiral Model）

1988年，Barry Boehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

 

图1.1.9 螺旋模型

螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

(1) 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

(2) 风险分析：分析评估所选方案，考虑如何识别和消除风险；

(3) 实施工程：实施软件开发和验证；

(4) 客户评估：评价开发工作，提出修正建议，制定下一步计划；

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

(1) 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。

(2) 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。

(3) 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

6. 喷泉模型（Fountain Model）

喷泉模型，又称为面向对象的生存期模型，OO模型。

 

图1.1.10 喷泉模型

喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。

7. 混合模型（Hibred Model）

过程开发模型又叫混合模型（hybrid model），或元模型（meta-model）。把几种不同模型组合成一种混合模型，并允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。

8. 敏捷开发

虽然我们在上面列出了众多的软件开发模型，但是其中产生历史最悠久，使用最普遍的还是瀑布模型及其简单的变型。随着软件工程理论的发展和新的软件开发思想的产生，以瀑布模型为代表的经典的软件开发模型，正在逐步的被以敏捷开发为首的新的软件开发思想和方法所代替。

那么，什么是敏捷开发呢？瀑布模型中，如果需求变更比较频繁，初期付出众多工作量的需求、设计常常被不断返供，进而又引发编码返工，造成成本上升。敏捷开发解决这个问题的方法很简单：减少早期对需求、设计的投入，尽量早让产品“可运行”，以便让客户提出反馈意见。但要避免这种方法被用过头，比如放弃了必要的需求和设计就得不偿失了。正确的做法是：在渐进式开发、渐进式交付的同时，做渐进式需求和设计。我们避免的是需求和设计的返工，而不是需求和设计活动本身。

下面列出敏捷开发过程中的一些重要思想：

(1) 并行创建模型。由于每种模型都有其长处和短处，没有一个模型能够完全满足建模的需要。敏捷建模者会发现在任何时候，同时进行多个模型的开发工作，要比单纯集中于一个模型要有效率的多。

(2) 创建简单的内容。应该尽可能的使模型（需求、分析、架构、设计）保持简单，但前提是能够满足项目组中相关的其他人员（project stakeholder）的开发需要。

(3) 小增量建模。采用增量开发的方式，可以把大的工作量分成能够发布的小块，每次的增量控制在几个星期或一两个月的时间内，促使你更快的把软件交付给用户，增加了开发的敏捷性。

(4) 和他人一起建模：结对编程。当有目的建模时我们会发现，建模可能是为了了解某事，可能是为了同他人交流想法，或是为了在项目中建立起共同的愿景。这是一个团体活动，一个需要大家有效的共同工作才能完成的活动。我们会发现开发团队必须共同协作，才能建立一组核心模型，这对我们的项目而言是至关重要的。例如，为了建立系统的映像和架构，需要和同组成员一起建立所有人都赞同的解决方案，同时还要尽可能的保持它的简单性。大多数时候，最好的方法是和另一些人讨论这个问题。

(5) 使用最简单的工具。大多数的模型都可以画在白板上，纸上，甚至纸巾的背面。这样做是因为大多数的图表都是可以扔掉的，它们只有在你画出模型并思考一个问题的时候才有价值，一旦这个问题被解决了它们就不再有意义了。

(6) 永远也别忘了用迭代的方法开发软件（这是大多数项目的标准做法），也别忘了建模只是众多任务中的一个。做一会儿建模、做一会儿编码、做一会儿测试（在其它的活动之中进行）。

 

1.3.3 项目开发的进度管理

1. 为什么需要进度管理

在软件项目的管理者眼中，软件项目有三个目标：质量、进度和成本。在1997年有研究机构曾对Dr. Frame美国项目管理协会成员的438位项目工作人员进行过一次调查，调查的结果如下：

(1) 质量方面（符合需求和项目规范的程度）

Ø 相差甚远者29%。

Ø 完全达到规范要求51%。

Ø 实际执行超出规范要求20%。

(2) 进度方面

Ø 严重拖期35%。

Ø 一定程度拖期34%。

Ø 按时完成22%。

Ø 一定程度提前8%。

Ø 大量提前1%。

(3) 成本方面

Ø 严重费用超支17%。

Ø 一定程度费用超支38%。

Ø 安全按预算执行27%。

Ø 一定程度费用结余12%。

Ø 大量费用结余6%。

从上面的数据我们可以看到，大多数的软件项目都不能在预定的成本范围内按时按量地完成，这是和软件项目自身的特点有关系的。

首先，软件项目进度的“可视度”不如传统项目。比如一个项目，一个任务分配下去后，过了一段时间，我们去问开发人员，“完成多少了？”开发人员说，“还有一天就做完了。”过了一天又问，回答说，“下星期一提交”。到了下星期一再问，可能回答说，“再两三天吧，有两个Bug（系统缺陷）要改过来……”

一个包含了几百个任务点的项目，你能一眼看出来进度是多少么？当前是进度超前了还是滞后了？

其次，软件项目质量的“可视度”不如传统项目。请看这个场景：开发人员终于把这个模块完成并提交了。这是问开发人员，“做的是否符合需求？”开发人员回答说，“严格符合！”结果一测试，漏洞百出，又多花了一个星期修改。

为什么会出现上面的差错？因为软件项目的真实进度保存在开发人员的大脑中。如果不采用专门的测试和追踪技术，我们很难直观地看到软件项目进行了多少，完成的质量如何。即使我们可以了解某个功能点，某个模块的进度，我们又如何获得整体进度的信息呢？

我们怎样能知道系统是否可以如期交付呢？

当项目可能延期时，我们可以采取哪些措施来挽救呢？

要解决这些问题，我们就需要做软件项目进度管理。

2. 什么是进度管理

首先，对项目开发过程进行进度追踪有个前提，就是明确的软件计划。

在制定软件开发计划的时候，要注意制定软件开发计划的“有效追踪原则”，要求每个计划中的任务点都要确定几日内完成。这样我们就能及时地发现哪个任务点延期提交了，从而做出调整。

其次，我们要明确一个概念：怎样才算一个任务点“完成”了。

如果单凭开发人员一句话：“开发完成了”，就是真的完成了么？

事实不是这样的。一般地，一个任务点，当开发工程师完成编码后首先要自己运行程序，检查程序实现的功能点是否符合需求，代码是否符合规范。如果不符合就修改程序，直到自己满意了，再将工作成果提交到版本控制服务器上（如SVN）。这时候，我们只认为这个任务的进度是50%。

项目组按照发布计划定期将项目程序发布到测试服务器上，供测试工程师测试。如果测试出Bug（正确的说法应该是软件“缺陷”），将创建“缺陷报告”，要求开发工程师修改，这时我们认为这个任务点的进度是80%。最后等业务负责人（可能是项目经理、需求工程师、业务咨询或客户经理）确认验收，这时候才算这个任务点真正完成了。

进度管理不仅要对软件项目的进度负责，而且要对产品质量和成本负责。做出来的东西没用，或者入不敷出，软件产品的意义就失去了。

最后，当发现进度异常时，我们可以通过采取一些措施，把进度拉回正常的轨道上。

对软件项目的进度进行检查和监控，从而发现可能的或已经发生的进度滞后问题并采取措施调控，以保证软件项目的进度、成本和软件产品的质量，减少损失的管理活动，称为软件项目的进度管理。

3. 如何进行进度管理

软件项目进度管理的管理技术和有效实践包括以下几点：

(1) 在获得开发工程师的承诺的基础上指定合理可行的软件开发计划。这是前提。

(2) 随时获得每个任务点以及整体项目的进度数据。

对每个任务点的完成情况进行追踪，随时了解每个任务点的进度数据。然后再根据各个任务点的权重，就可以计算出整体项目的进度。比如，某项目包含A、B、C和D四个任务点。权重各为25%。A、B开发工程师已经提交，正在测试，进度为50%；C已经经过了项目经理的确认，进度为100%；D还在开发规程中，进度为0%。那么项目的整体进度就是：

50% × 25% + 50% × 25% + 100% × 25% + 0 × 25% = 50%。

就是说，开发工作只完成了一半！虽然4个任务点已经“完成”了3个，但有两个未通过测试，所以进度并不像表面看上去那么乐观。使用Microsoft Project工具可以轻松地得到这方面的信息。在规模不大的项目中，我们使用Microsoft Excel表格中的公式功能也可以做到自动计算项目的整体进度。

(3) 优先保证“关键路径”上任务点的完成。

由于在不同任务点之间存在着前后制约的关系，在某些任务点完成之前，特定的任务点是无法开始开发的。比如：在分层开发的过程中，在DAO类没有开发完成前，业务逻辑类的开发是无法开始的。这样系统中存在先后关系的任务点就能串成一条条线，单条线上的任务点一定要“依次”完成，而且每个任务点都有工时的要求（在几天之内完成）。这些线中最长的一条就决定了项目开发至少所需要的时间，这条线称为项目的“关键路径”。

如果关键路径上的某个任务点延期，会造成其后一系列任务的延期，因此要优先保证完成关键路径上的任务点。

(4) 当进度异常时，我们可以采取的措施包括“快速跟进”和“赶工”。

当两项（或多项）任务可以同时进行的时候，那就增加人手，让两项（或多项）任务同时进行，从而加快项目进度，这称为“快速跟进”。由于多项任务同时进行，增加了沟通和控制管理的难度，也容易带来风险。

如果任务处在关键路径上，或由专人负责的，别人无法插手，那采取快速跟进的方法就不适合。这时候也只好让任务负责人加班了，这种方式称为“赶工”。赶工会带来成本的增加（总要付加班费、吃加班餐或提供配套的福利吧）。

人的精力毕竟是有限的，“快速跟进”的方式看上去更容易做到一些。因此在做项目计划的时候就要考虑这方面的需要。不要将某个任务点分配给“专人”来完成，在兼顾效率的基础上尽可能地让开发人员互相了解其他人的工作内容，以便需要的时候可以互相顶换。

(5) 项目进度再紧张，也要“以人为本”。

如果软件项目进度太紧，参与的人都很疲惫，纷纷离开项目组，那就得不偿失了。

因为当项目结束的时候，一个默契合作、士气高涨的团队将是项目的重要收获之一。有的时候，甚至比项目的成败还要重要。是把人拼光了赢得战斗的胜利，还是保全实力，以利再战，这本来就是很难抉择的事情。当然，追求胜利在软件开发过程中使我们生存的根本，但也千万不要眼中只有胜利而无其他。

(6) 身处项目组中的“我”，要怎样做？

如下Excel表格表达了我们项目进度的一种管理方式。图中的表格是用来进行进度管理的。每个任务点有三个状态：未开始、延期和已完成。通过修改功能点的状态信息，就可以自动计算出每个人的总体进度和整个项目的总体进度。

 

图1.1.11 进度管理表格

我们在项目中要发挥自己最大的主观能动性。让自己从项目中有所收获，而且乐在其中。人都有被认同的渴望，都有提升自身价值的需要，我们要调整自己的心态，从每各项目中都得到提升和自我价值的彰显。

即使在最险恶、最无助的环境中，也不要放弃对战友的责任。在这个世界上，没有不需要流血牺牲便能获得的胜利，没有不需要熬煎等待便获得的成功，没有不需要誓死奋争便获得的自由。“扎实做事便成功，努力专心便胜利，持之以恒便卓越”，是永恒的主题。

1.3.4 项目开发的风险管理

1． 为什么需要风险管理

风险总是伴随着利益，风险越大利益也就越大。我们不鼓励铤而走险，但我们也不会见了风险就挥动白旗。如果一个企业只做有把握的事，也就意味着它绕开了所有利益，其结局只能是：颗粒无收。在软件项目中，风险是回避不了的。

风险不会因为我们没有看到或者装作没有看到就不存在了。我们不应该惧怕风险，但也不要无知到忽视它。和故事中的旧船航海一样，软件项目中同样存在各种各样的风险。

Ø 进度落后：合同上签订今年9月项目验收，现在都8月底了，测试人员刚刚把厚厚的一打Bug清单交给项目经理。整个项目组在剩下的时间里通宵达旦的修改都未必能完工。

Ø 需求膨胀：客户已经在需求规格说明书上签字了，项目稳扎稳打地进行着，项目组已经完成了概要设计，正准备开始详细设计。这时，客户突然发来了一封邮件，要求将系统的一些主要功能大改。

Ø 人员流失：小王前两天情绪低落，大家都没有在意，今天早晨上班的时候小王突然向项目经理提交了辞职信。小王可是项目组的主力，他走了之后，项目组中无人能接手他的工作。

上述这些风险中，有的可以让项目组一时手忙脚乱，有的可以使整个项目全盘皆输。所以我们要学会识别风险，管理风险。这，也是从事我们这个行业必修的基本功之一。

2． 什么是风险管理

首先，我们先明确一下风险和风险管理的概念。

Ø “确定”，是指所有信息都是可用的，对结果的预言比较有把握。

Ø “不确定”，即没有信息，对可能的结果一无所知。

Ø “风险”，一种不确定的事件或条件，一旦发生会对项目产生正面或负面的影响，它既包括对项目目标的威胁，也包括对这些目标进行提高的机会。即“确定”中可能出现的“不确定”。软件项目最常见的风险是：需求膨胀或变更，还有就是人员变动。人员变动包括人走，也包括人来。新人加入团队在一定时间内肯定会造成效率的损失。

Ø “风险管理”，就是对风险进行识别、分析和应对的过程。

所以，软件项目风险管理工作的主要内容就是：对项目中的不确定因素进行识别、分析、指定应对措施，并进行跟踪控制，以提高软件项目的成功几率。

3． 如何进行风险管理

软件项目的风险管理是一个相对专业的管理领域，有着一整套的理论和方法。

这些风险管理技术包括风险识别技术、风险定性分析技术、风险定量分析技术、常见的应对策略和记录、跟踪的方法。

(1) 风险识别技术：显然，对风险进行管理的前提是识别风险。对于已经识别的风险，我们可以制定计划进行管理；对于未知风险，那无法管理。我们可以借助文件审核、按照清单逐项检查、尽量收集信息（以头脑风暴、访谈、SWOT等方式）、做假设分析，以及采用专门的图解技术（如因果图、系统流程图、影响图）等方法来发现风险。

(2) 风险定性分析技术：对已经发现的风险，还要进行分析，从发生的概率和如果发生造成的严重后果来分类、排序。

(3) 风险定量分析技术：对每项风险的发生概率和影响，以及整个项目的整体风险程度进行数值分析。常采用的方法包括访谈、敏感性分析、蒙特卡罗分析和决策树等。

(4) 应对策略：常见的应对策略有4种。

Ø 回避（Avoidance）：比如缩小范围，某些不重要的功能先不实现了，保证核心业务的稳定运行；比如增加资源（一般情况下指增加人手）；比如用熟悉的方法，如果大家都更熟悉MS SQLServer，那就先别用Oracle。

Ø 转嫁（Transference）：比如本公司（或部门）擅长做金融行业的项目，新签到的项目包含“人力资源管理”的内容，本公司（或部门）不擅长，那就签订分包合同，包给擅长的公司（或部门）做。

Ø 减轻（Mitigation）：当大方向难以扭转的时候，多一份努力就离正轨近一些。比如项目很难按期交付，逾期1天需要向客户赔付2万元。那就一方面尽可能加快项目开发，尽可能提早完成；同时积极同客户进行商务谈判，求得谅解，请求客户同意降低赔付金额。

Ø 接受（Acceptance）：对于“不可抗拒”的情况，只能“尽人事，安天命”。如果客户方数据非常宝贵，作为维护合同的重要内容，我们有保护客户方数据的义务。这时候火山、地震、洪水、飓风、战争等情况就是我们可能面对的风险。当然，几率太小的不需要纳入管理。我们对无法抗拒的威胁还是有事情可做的，那就是制定应急计划，规划好当事情真正发生了，我们有哪些可以做。比如上面的情况，我们可以设定数据库每天自动备份到另外一块磁盘，每周进行一次异地备份。这样，我们虽然不能阻止火山的喷发，但即使火山喷发了，我们也有避免（或降低）损失的办法。我们“接受”我们改变不了恶劣天气的事实，但是如果我们准备好了恶劣天气来临时的应对措施，就能尽可能地降低损失。

(5) 记录、跟踪：对于每个可能发生的危险，我们都要予以记录，并随时对风险的状况进行追踪。下面就是一个用于风险记录和追踪的表格的示例，如图1.1.12所示。

 

图1.1.12 风险记录和追踪

这样，我们就可以把风险管理落到实处，使之真正地发挥作用。

1.4 软件开发过程中的文档

1.4.1 什么是文档

软件文档（document）也称文件，通常指的是一些记录的数据和数据媒体，它具有固定不变的形式，可被人和计算机阅读。它和计算机程序共同构成了能完成特定功能的计算机软件（有人把源程序也当作文档的一部分）。我们知道，硬件产品和产品资料在整个生产过程中都是有形可见的，软件生产则有很大不同，文档本身就是软件产品。没有文档的软件，不能称为软件，更谈不上是软件产品。软件文档的编制（documentation）在软件开发工作中占有突出的地位和相当的工作量。高效率、高质量的开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用软件，对于充分发挥软件产品的效益有着重要意义。

1.4.2 文档的分类

文档在软件开发人员、软件管理人员、维护人员、用户以及计算机之间的多种桥梁作用可以从下图1.1.13中看出。

 

图1.1.13 软件开发文档的桥梁作用

软件开发人员在各个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依据，这个作用是显而易见的。软件开发过程中软件开发人员需制定一些工作计划或者工作报告。管理人员则可以通过这些文档了解软件开发项目安排、进度、资源使用和成果等。软件开发人员需为用户了解软件的使用、操作和维护提供详细的资料，我们称此为用户文档。以上三种文档构成了软件文档的主要部分。我们把这三种文档所包括的内容都列在下图1.1.14中。其中列举了十三种不同的文档，下面是这些文档的简要说明。

 

图1.1.14 软件文档的三种分类

(1) 可行性研究报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施的方案，说明并论证所选定实施方案的理由。

(2) 项目开发计划：为软件项目实施方案制定出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。项目开发计划应提供给管理部门，并作为开发阶段评审的参考。

(3) 软件需求说明书：也称软件规格说明书，其中对所开发软件的功能、性能、用户界面及运行环境等做出详细的说明。她是用户与开发人员双方对软件需求取得共同理解的基础上达成的协议，也是实施开发工作的基础。

(4) 数据要求说明书：该说明书应给出数据逻辑描述和数据采集的各项要求，为生成和维护系统数据文卷做好准备。

(5) 概要设计说明书：该说明书是概要设计阶段的工作成果，它应该说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计奠定基础。

(6) 详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。

(7) 用户手册：本手册详细描述软件的功能、性能和用户界面，使用户了解如何使用该软件。

(8) 操作手册：本手册为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。

(9) 测试计划：为做好组装测试和确认测试，需为如何组织测试指定实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则，测试结果允许的偏差范围等。

(10) 测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明。对测试结果加以分析，并提出测试的结论意见。

(11) 开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告。报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。

(12) 项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力。此外还需要对开发工作做出评价，总结出经验教训。

(13) 维护修改建议：软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响估计作详细的描述，写成维护修改建议，提交审批。

以上这些文档是在软件生存期中，随着各阶段工作的开展适时编制。其中有的仅反映一个阶段的工作，有的则需跨越多个阶段。下图1.1.15给出了各个文档应在软件生存期中的哪个阶段编写。

 

图1.1.15 软件生存期各阶段编制的文档

1. 文档说明的问题

上述13种之多的文档，最终要向软件管理部门，或者是用户回答以下的问题：

Ø 哪些需求要被满足，即回答“要做什么？”

Ø 所开发的软件在什么环境中实现以及所需要的信息从哪里来，即回答“从何处？”

Ø 某些开发工作的时间如何安排，即回答“何时做？”

Ø 某些开发（或维护）工作打算由“谁来做？”

Ø 某些需求是怎么实现的？

Ø 为什么要进行那些软件开发或维护修改工作？

上述13个文档都在一定程度上回答了这六方面的问题。文档所回答的问题见图1.1.16。

 

图1.1.16 文档所回答的问题

1.5 软件开发计划

通常的软件项目都是以组建团队为项目启动的第一件事情，接下来要做的就是制定项目计划。

做计划的时候，我们可以根据以往的经验，估计这个项目要用多少人，多少时间。然后作一个详尽的安排出来，具体到哪个人哪天做什么事情。这样，我们可以按照这个计划有条不紊地完成项目，公司也可以按时地把资源（主要是人员、服务器等）分配给项目组。

计划，在软件开发中起到冷静、理智地分析项目完成状况，分担项目完成压力的作用。假如你有个很紧的“最终期限”，但是只要你做了计划，并且计划显示你能够在期限前完成，那么你就会在很紧张的气氛中开始第一项任务，并且尽可能地保证质量。毕竟，（计划显示）你有足够的时间。这正是使计划实现的重要因素。恐惧和没有细致的行动方案，只会造成思维迟钝、出错、沟通崩溃。

我们做计划的原因是：

(1) 确保我们一直在做需要做的事情中最重要的那件。

(2) 我们需要和他人合作。

(3) 当发生意外事件时，需要知道对以上两条会造成什么样的影响。

(4) 计划可以帮助我们有效地协调使用资源，帮助我们对项目进行有效地控制，及时地发现问题，解决问题。

管理学上有一则有名的公式：管理 = 计划 + 追踪 + 调控。计划是管理活动开展的前提。这个公式离我们不远，无论我们做什么事情，利用这个公式都可以规范我们的工作。

一个好的计划是把事情做好（完成项目）的前提，在此基础上，我们还要不断地确认（追踪）关键事件（里程碑）的完成情况，看事情是否按安排在进行，如果有意外发生，要立即想办法解决（调控）。

1.5.1 制定软件开发计划的步骤

同样作为项目，软件项目与工程项目却有很大的不同，他们有以下不同点：

(1) 软件项目的“可视性”不如工程项目。

(2) 软件项目的复杂度大大超过工程项目。

(3) 软件项目需要有创造性的智力劳动，更难预测和控制。

下面我们就以“软件开发计划”为例，学习软件项目中计划是如何制定的。

制定一个成功的软件开发计划，要遵循特定的步骤。制定软件开发计划的步骤如下：

(1) 划分任务点。

一个项目可以看作是一个大任务，将大的任务进行分解，一直到我们可以估计的程度，就可以做出项目计划。把大任务分解成多个小任务，可以帮助我们进行更加精确的估计，暴露出在其他情况下可能没有想到的工作活动，并且保证可以完成更加精确、细密的状态跟踪。

项目管理把工作任务的这种划分叫做“工作分解结构（Work Breakdown Structure, WBS）”，它是一种逐步明确和解决问题的基本思路，一个庞大的，模糊不清的任务或者问题肯定难以解决，只有把它细分成可以看清楚的、明确的小任务或者工作项才能够明确，并加以管理。

制定项目计划，必须制定一个工作分解结构（即使是非IT方面的工作项目也是如此），这是前提，基于此才谈得上真正意义上的实施和控制。

(2) 分配资源。

划分好任务点后，接下来就要给每个任务点指定人手和必需的设备、物资了。完成任务必需的人手、设备和物资统称为“资源”。

由于现在只是计划阶段，并不是真正的分配资源，但我们可以从全局的角度看一下资源分配是否合理，到需要的时候资源是否能够到位。从而避免资源过度使用或浪费的情况。

我们分配资源（主要是人手）的时候，不仅要指定“谁”，还要明确完成某个任务点的开始时间和结束时间。

项目计划中的每个计划项都要明确：“什么任务”、“谁”和“完成任务的起止时间”。

完成这步工作后，我们能够知道这个项目需要多少人，多少时间完成了。项目计划开始实施后，我们还要逐项追踪，看看是否按计划执行了，如果有出入要及时调整。

那是不是说到这步我们已经完成项目计划的制定了呢？还不是，我们还缺少至关重要的一步，那就是获得开发工程师承诺。

(3) 获得开发工程师承诺。

项目经理制定计划的时候更多地是依靠自己的经验，他可能安排一个开发工程师用1个工作日完成“合同变更”的详细设计文档。基本上这是合理的。但开发工程师可能有自己的特殊情况，比如刚入职，对技术框架和业务都不太熟悉。需要先阅读相关文档，或者还没有从另外一个项目中完全撤出来，只能将50%的时间投入到这个项目上等等。

如果项目经理只凭自己的主观判断制定计划的话，那这样的计划在实施的时候阻力会很大。这就要求开发工程师本人对项目经理或开发经理分配给自己的任务表示同意，也就是“做出承诺”。

但一般情况下，当一个团队长期合作，彼此了解的时候，不再需要逐项确认计划是否合理。但项目经理（或开发经理）制定出开发计划后都会在正式发布前留一个反馈的时间，以便提前发现计划中不合理的部分并进行调整。

但一旦开发计划发布并开始实施后，就要严格遵守。开发工程师就要对自己承担的任务负责。

1.5.2 制定软件开发计划的原则

制定软件开发计划除了要遵循特定的步骤外，还要遵守一定的原则。

(1) 有效追踪原则

有效追踪原则是对任务点的划分而言的，指的是在划分任务点时，粒度要适中。

粒度太大，追踪的效果就差；粒度太小，效率就太低。一般软件开发任务点所用的工时控制在1~3个工作日是比较适中的。

(2) 共同参与原则

不是项目经理（PM）一个人的事件，需要相关人员一同参与。

项目相关人员要共同估计工作量，并做出承诺。

一般概念中，任务安排和计划是经理的事，员工只管执行就是了。但在软件开发中采取更合理的做法是：制定计划时相关人员也参与进来。这在制定计划的“获得参与人员承诺”步骤中可以体现出来。

当一个计划涉及很多人、很多事的时候，我们必须采用一个有效的工具来帮助我们制定计划。下面我们就来学习使用Microsoft Project 2003来为“权限管理系统”制定项目计划。

1.5.3 使用Project工具制定“权限管理系统”项目计划

Microsoft Office Project Professional 2003是Microsoft提供的企业管理工具产品的一员，是一个专业的项目管理软件。它可以帮助我们管理项目，用于安排任务，制定计划和分配资源，还可以监视项目的进展和进度，以图形化的方式显示哪些工作完成了、哪些还没有完成以及完成的百分比，以有效地组织和跟踪任务和资源，使项目在预算范围内按时完成。

下面，我们使用Project Professional 2003制定“权限管理系统”项目计划。

我们首先看一下项目的需求。

盛世西游科技发展有限公司项目组人员组织结构图如图1.1.17所示。

最近公司承接了一个权限管理系统项目，项目组5个人中，除项目经理唐三藏外，其余4人每个人在图中所示的原角色的基础上再担任软件工程师和测试工程师两个角色。

 

图1.1.17 盛世西游科技发展有限公司项目开发组人员组织结构图

客户对系统的要求如下：

权限管理系统应能进行用户管理和角色管理，能为角色分配权限，同时也能将角色赋予用户。

开发经理孙悟空通过与用户沟通，并对需求进行分析，明确了以下需求：

权限管理系统整体上分为4个模块：用户登录模块、用户管理模块、角色管理模块和生成菜单模块。其中，用户管理模块包括增加用户、删除用户、修改用户、查询用户、查看用户和角色分配6项功能。而角色管理模块包括增加角色、删除角色、修改角色、查询角色、查看角色和权限分配6项功能。

盛世西游科技发展有限公司项目组5位成员开始共同参与，用Project Professional 2003制定权限管理系统项目开发计划。

1. 使用Project Professional 2003创建项目文件

要在Project Professional 2003中创建项目计划，可执行以下步骤：

(1) 创建项目文件

准备项目日程的第一步是创建项目文件。

1) 启动Microsoft Project Professional 2003。

2) 新建一个项目，以“[权限管理系统]项目计划”为名保存此文件。

此项目文件名为“[权限管理系统]项目计划.mpp”，在窗口的左边出现“任务”窗口，指导项目创建的过程，相当于一个向导，如图1.1.18所示。

 

图1.1.18 新建项目“[权限管理系统]项目计划”

(2) 填写项目信息

在创建项目文件之后，便可使用文档记录项目的相关信息。为此，需要在“属性”对话框的“摘要”选项卡中填写详细信息。

1) 选择“文件”à“属性”命令，在弹出的对话框中选择“摘要”选项卡。

2) 添加表1-5-1中的信息。

表 1-5-1 权限管理系统项目详细信息

属性对话框如图1.1.19所示。填写完成后，单击“确定”按钮。

 

图1.1.19 “权限管理系统”项目计划属性

2. 划分任务点

创建项目任务是输入项目中的“活动”。默认情况下，任务以“天”为单位。

将表1-5-2中的任务全部添加到任务列表中，最终效果如图1.1.20所示。

表 1-5-2 创建任务并制定任务工期

 

图1.1.20 创建任务并指定任务工期

图1.1.20中，创建好项目任务，分配好各任务工期后，在任务表格的右端，出现了包含有蓝色条状图形的进度表示图：甘特图。

注意：

 (1) 创建子任务

一项任务可拆分为多个小任务或子任务。为“权限管理系统”项目的“3. 详细设计”任务添加表1-5-3中的两个子任务。

表1-5-3 创建任务并制定任务工期

1) 在任务“3. 详细设计”下方添加表1-5-3中的两个任务。

2) 选中新添加的两个任务，在右键菜单中选择“降级”子菜单。这就创建了两个子任务，如图1.1.21所示。

 

图1.1.21 创建子任务

(2) 前置任务

任务列表中的“前置任务”可用于设置任务的相关型，即制定任务的执行顺序，如图1.1.22所示，任务2“1. 需求分析”必须在任务3“2. 概要设计”前完成，则将任务3的前置任务设置为“2”。同理，将任务5的前置任务设置为“3”，将任务6的前置任务设置为“5”。

 

图1.1.22 为任务设定“前置任务”

3. 为项目分配资源

我们在前面介绍过，资源可以是用于执行一项任务必需的设备、物资或人员。在软件开发过程中，最主要的资源就是人员。

资源一般分为如下两类：

Ø 材料资源：只用于完成一项任务的消耗品

Ø 工时资源：指按照工作时间来计算的资源，例如人员以及执行任务所需的设备。

资源的度量单位：

Ø 对于工时资源，最大单位表示该资源可用于项目的时间，使用百分比定义的。例如，拿项目开发组长唐三藏这个“工时资源”来说，唐三藏总的工作时间为100%（最大单位）。

Ø 在向任务分配资源时，分配单位是“该资源可以用在任务上的时间”占“该任务所需总时间（100%）”的百分比。例如，要求孙悟空和白龙马两人共同完成需求分析任务（100%），并且孙悟空使用50%的时间做设计，白龙马也使用50%的时间做设计。

(1) 排定资源

为了将资源分配到任务点，我们首先要在项目中定义资源。列一下项目中我们将用到哪些资源，并设定这些资源的相关属性。在Project 2003中进行如下操作。

1) 选择“视图”à“资源工作表”命令，出现“资源工作表”视图。

2) 将表1-5-4中的信息添加到“资源工作表”中。

表1-5-4 创建任务并制定任务工期

添加结果如图1.1.23所示。

 

图1.1.23 为项目排定资源

(2) 为项目分配资源

1) 在任务列表中，选择任务“1. 需求分析”。

2) 选择“工具”à“分配资源”命令。

3) 将孙悟空和白龙马分配给任务“需求分析”，每人的单位都是50%。如图1.1.24所示。

 

图1.1.24 为任务“1. 需求分析”分配资源

4) 将“权限管理系统”项目的其余任务分配资源，如图1.1.25所示。

 

图1.1.25 为其余任务分配资源

4. 设置项目里程碑

要设置项目里程碑，我们首先要了解里程碑的概念。什么是里程碑呢？

里程碑本来是指标志公路及城市郊区道路里程的碑石。每一千米设一块，用以计算里程和标志地点位置。我们在路上行走的时候，会不时地在沿途观看路标，我们便知道还有多少路或多少时间才能够到达终点。

在软件项目开发中，里程碑是标志项目重大事件的参照点，用于识别项目日程中的重要阶段。

一般在需求分析阶段完成后，我们需要对需求进行一次评审。评审组由项目组成员与客户代表团两组人员组成，到时客户方会对需求规格说明说进行确认，不明确的地方由项目经理做出解释。

需求评审通过称为“需求确认”，此时我们认为“需求确认”就是一个里程碑。因为这对于客户和项目组的意义都是很重大的。对客户，是要让客户知道“我们项目组已经完全理解你要做什么了”，快签字确认吧；对项目组，意味着“客户已经确认需求了，我们可以开始动手做设计了”。这个里程碑是一个明确的分界点，代表着需求分析阶段的结束，设计阶段的开始。

里程碑并不消耗项目的时间，将任务的工期设置为零（0）可创建里程碑。下面我们就来在“权限管理系统”项目中创建“需求确认”这个里程碑。

1) 选中任务“2. 概要设计”。

2) 选择“插入à新任务”命令，将新任务命名为“需求确认”。

3) 将任务“需求确认”工期设置为0，如图1.1.26所示。注意，此任务在甘特图上的图形为菱形。

 

图1.1.26 为项目设置里程碑

 

 

 

任务实训部分 

实训任务1：甘特图

训练技能点

Ø 甘特图的绘制

需求说明

继续权限管理系统工作计划甘特图的绘制。

实现思路

(1) 分析权限管理系统的功能需求

(2) 确定每个阶段的工期

(3) 确定每个具体功能的工期

(4) 绘制权限管理系统工作计划甘特图

关键步骤

绘制权限管理系统工作计划甘特图，如图1.2.1所示。

 

图1.2.1 权限管理系统甘特图

实训任务2：为甘特图添加里程碑

训练技能点

Ø 为工作计划甘特图添加里程碑

需求说明

给“实训任务1”中的权限管理系统工作计划甘特图添加里程碑

实现思路

(1) 为“需求评审”阶段添加里程碑

(2) 为“设计评审”阶段添加里程碑

(3) 为“代码评审”阶段生成里程碑

(4) 为“测试评审”阶段生成里程碑

关键步骤

给“实训任务1”中的权限管理系统工作计划甘特图添加里程碑，如图1.2.2所示。

 

图1.2.2 为项目生成里程碑

实训任务3：为项目绘制工作计划甘特图

训练技能点

Ø 甘特图

Ø 需求分析

需求说明

选定自己的毕业设计项目。将权限管理系统作为自己项目的一个模块，编写自己项目的工作计划甘特图。

实现思路

(1) 选定自己小组的毕业项目

(2) 为毕业项目制定项目计划

(3) 为毕业项目做需求分析

(4) 根据需求分析为自己小组的毕业项目书写需求设计说明书

 

 

巩固练习

一、 选择题

1． 下列选项中，属于毕业设计目标的有：（）

A. 积累到行业经验

B. 积累到团队开发经验

C. 积累到产品经验

D. 学习到实用软件工程知识

2． 在Y2毕业设计中，我们小组的团队组织结构为：（）

A. 大型软件公司团队组织结构

B. 微软团队组织结构

C. 小型软件公司团队组织结构

D. 惠普团队组织结构

3． 在Project 2003中，默认情况下，任务以（）为单位。

A. 小时

B. 分

C. 天

D. 星期

4． 下列不属于经典软件项目开发模型的有：（）

A. 瀑布模型

B. 快速原型模型

C. 增量模型

D. 敏捷开发

5． 甘特图中的菱形表示：（）

A. 项目里程碑

B. 超过最大许可时间的任务

C. 包含子任务的关键任务

D. 延迟的任务

二、 操作题

为自己小组选定的毕业项目的工作计划甘特图添加里程碑，分别添加需求评审、设计评审、代码评审和测试评审等里程碑事件。

 

文章来源: aaaedu.blog.csdn.net，作者：tea_year，版权归原作者所有，如需转载，请联系作者。

原文链接：aaaedu.blog.csdn.net/article/details/73302930