项目管理说明书_(2)

北京师范大学珠海分校管理学院

项目管理说明书

——开发聊天软件

生存期中的各阶段定义如下： 项目规划阶段

阶段目标： 根据初步的需求分析，确定项目的规模、时间计划和资源需求

输入： 要求文本，

过程： 项目规划，计划确认 输出： 项目计划

需求分析阶段

阶段目标： 确定客户的需求 输入： 项目计划，SOW

过程： 需求获取，需求分析，需求控制 输出： 原型系统，需求规格

设计阶段

阶段目标： 总体系统结构设计 输入： 原型系统，需求规格 过程： 总体设计

输出： 系统设计说明书，数据库结构定义

增量1实现

阶段目标： 实现系统的登录功能

输入： 系统设计说明书，数据库结构定义

过程： 详细设计，编码，代码走查，代码评审，单元测试

输出： 详细设计说明书，源代码，可运行版本-1

增量2实现

阶段目标： 实现系统的聊天功能

输入： 系统设计说明书，数据库结构定义

过程： 详细设计，编码，代码走查，代码评审，单元测试 输出： 详细设计说明书，源代码，可运行版本-2

增量3实现

阶段目标： 实现系统的信息管理功能

输入： 系统设计说明书，数据库结构定义

过程： 详细设计，编码，代码走查，代码评审，单元测试 输出： 详细设计说明书，源代码，可运行版本-3

增量4实现

阶段目标： 实现系统的文件传输管理功能 输入： 系统设计说明书，数据库结构定义

过程： 详细设计，编码，代码走查，代码评审，单元测试 输出： 详细设计说明书，源代码，可运行版本-4

集成测试

阶段目标： 通过集成环境下的软件测试 输入： 测试计划，测试用例 过程： 集成测试，系统测试

输出： 系统软件包，测试报告，产品说明书

产品提交

阶段目标： 产品可投入使用 输入： 系统软件包 过程： 产品提交 输出： 验收报告 2）资源配置情况：

人力资源：

 1个管理人员  2个开发人员  4个测试人员  2个设计人员  2个需求人员

设备资源：

 3台电脑  1台服务器

2.4项目工作任务分解

2.4.1概览

:

详细说明：

2.4.2项目结构分解结构图

2.4.3责任分配矩阵

R（responsible）负责 A（accountable）有责 C（consult）咨询 I（inform）通知

三、风险管理

3.1 风险识别过程

风险因素识别方法：头脑风暴法；

头脑风暴法：将项目成员聚集在一起，通过头脑风暴会议，产生一个潜在风险因素的清单。在会议过程中，不能对他人的观点作评价和批判，也不采取强压措施促使大家保持一致，鼓励所有成员畅所欲言，提出意见，而不用承担任何风险。最后将各位成员的意见分析归纳总结，最终的得到 7项主要风险因素清单。如表3-2所示： 序号 A B C D

风险因素 需求分析不准确 需求变更 缺少用户支持 设计方案出现偏差

沟通风险 人力资源风险 进度风险

描述

需求内容表述不清，导致需求容易发生变化，技术人员对需求内容理解错误，需求分析出现错误等。 由于客户提出的需求不明确造成需求不断变更，甚至项目范围扩大，成本上升，进度延迟；

用户积极配合项目开展对项目成功至关重要，需要授权执行项目给用户执行； 设计方案、功能设计出现错误，功能设计考虑不周全，变更计；

技术人员与需求人员之间，或技术人员之间的沟通出现问题，影响了项目实施的协同性作用； 人员流动特别是技术骨干力量流失。

由于项目范围不断扩大或者人员安排等导致的项目延期，不能到期完成项目的问题 表3-2：项目风险因素

E F G

3.2风险可能性和后果分析

对项目风险进行定性分析，定性风险分析是一种对风险和条件进行定性分析，并按影响大小排列它们对项目目标的影响顺序的分析方法。根据项目的潜在风险影响来对项目风险进行分类，如表3-3所示：

将风险分为三个等级：高风险、中等风险、低风险；根据表3-2的分类，绘制风险影响矩阵，如图3-4所示：

后果

高

中

低

3.3风险应对

针对风险定性分析的结果，来实施已经获得统一和资金支持的风险应对措施，以降低 IT 项目的风险的消极作用。在风险规划风险应对的过程中，需要根据风险的优先级来制定应对措施。险应对策略包括风险回避、转移、减轻、接受、开拓、分享、提高等。

（1） 需求分析不准确与需求不断变更

需求不明确引起需求不断变更，需求不断变更也会造成需求分析不准确。用户过度期望与需求分析不准确也存在类是的关系。需求风险对项目产生各种影响，项目风险管理人员必须在早期进行重点预防，加强需求沟通，业务分析师需要在项目前期全新投入工作，尽量明确每一项需求的内容、范围、要求。

（2） 进度风险控制

项目进度缓慢会影响项目的成本，如果项目导致系统上线延迟，可能影响业务开展，还可能造成系统质量问题。进度控制的目标是了解项目的当前状态，了

可能性

解导致进度变更的因素。确定进度是否已经发生变更，以及当前发生变更时，管理好这些变更。控制项目进度的变更首先要确保所编制的项目进度符合时机，要使用纪律手段来控制项目的进度，并且要由领导来强调按照进度开展项目的重要性。虽然许多工具和技术可以帮助进行进度控制，但是项目经理需要格外重视人事管理问题。项目失败不是业务编制的 PERT 不好，而是因为人事管理的失败。

（3） 交流与沟通 用户的需求沟通、与团队成员的合作沟通都将对项目产生重大的影响。只有双方建立良好的沟通与协作机制，才能努力完成项目的目标，只有建立有效的项目信任沟通机制，才能避免在需求分析、系统设计、系统评价标准、项目验收标准、项目质量等方面可能出现的分歧与失误。实施软件项目是外包双方互相配合、共同合作的过程。

四、成本估算 分析

软件开发成本估算主要指软件开发过程中所花费的工作量及相应的代价。 不同与传统的工业产品，软件的成本不包括原材料和能源的消耗，主要是人的劳动的消耗。另外，软件也没有一个明显的制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此，软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、集成测试到认证测试，整个开发过程所花费的代价作为依据的。

对此项目的估算以客观量化估算，主要计算人工成本。所得数据使用比较估算法，利用从网上所查得的软件类过去基本工资对现在的工资进行估算。参考construx软件公司的史蒂文提出的软件项目分为六个部分：体系构造；详细设计；编码和调试；开发者测试；系统整合；系统测试。 COCOMO模型(constructive cost model) 先使用cocomo模型对项目成本做大概估算 COCOMO模型中用到以下变量：

DSI-------源指令条数。不包括注释。1KDSI = 1000DSI。

MM-------开发工作量（以人月计） 1MM = 19 人日 = 152 人时 =1/12 人年 TDEV-----开发进度。(以月计) 本软件适用于组织型模型

组织型(organic): 相对较小、较简单的软件项目。开发人员对开发目标理解比较充分，与软件系统相关的工作经验丰富，对软件的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（

基本COCOMO模型估算工作量和进度的公式如下 工作量： MM = r*(KDSI)c 进度： TDKV = a(MM)b

其中经验常数 r, c, a, b 取决于项目的总体类型。 基本COCOMO模型

通过统计63个历史项目的历史数据，得到如下计算公式。

根据经验法估计工作量为1KDSI左右，则工作量MM计算为2.4=45.6人天=364.8人时。

4.1对项目工作量进行估算：

估算软件大小使用策略：以功能点为基础，估算问题大小。 开发一个功能点需要5个人天的工作量，那么该项目的工作量就可以通过以下公式计算出来：

项目工作量=4*13=52人天

与cocomo模型所估算量45.6人天相比，结果相近。对项目日期做保守估算，

使用功能点估算时间52人天做成本预算。

4.2对项目所需资源、各阶段工作量进行估算

使用参数模型法进行估算

参数模型法：提供一个估算方程，它把软件某一属性的度量作为输入，软件的工作量和工作进度则是输出。成本算法模型提供了对工作量和工作进度的直接估算，有两种主要类型：1数学模型，核心部分往往是一个估算方程，该方程以影响开发成本的某些项目因素作为输入，输出的是项目开发的工作量和工作进度；2检索表，根据一定的规则对软件对象进行分类，然后以每一种类型提供工作量或工作进度的平均值作为参考，适用于软件项目分解的较低层次。

4.3瀑布模型生命周期各阶段

4.4以1.12做个人时间乘数，对项目周期估算

以1.12为个人时间乘数，调整项目所需时间为52*1.12=58人/天

4.5项目成本估算

五、进度估算

5.1 项目活动进度估算表

5.2 项目活动紧前活动及估计历时

5.3 使用Microsofit Project 软件 5.3.1 使用软件建立甘特图

依据项目活动紧前活动及估算历时表，输入“活动项目”、“工期”、“开始时间及完成时间”、“紧前活动”。最后得出甘特图，如上图所示。 5.3.2使用软件建立资源工作表：

依据人员资源估算表输入“资源名称”及“标准费率”等，建立资源工作表如上图所示。

5.3.3 使用软件查看网络图

六、项目的沟通与评审

项目评审的主要目的是根据项目计划对项目的执行活动进行检查，及时发现问题，研究解决对策，纠正偏差，保证项目的顺利实施。项目交流计划分为如下几类“

每天17：:00的沟通交流 定期评审 阶段评审 事件评审

七、项目收尾和终止 7.1 项目的验收

开发聊天软件项目收尾阶段的验收主要是依据其大小、性质、特点进行验收，由于验收环节较多、内容繁杂，因而验收管理的程序也相对复杂，最终对于本项目按照了大型软件建设开发验收程序进行了验收管理，详见如图 7-1 所示。

图7-1 开发聊天软件项目验收管理程序

总的来说，开发聊天软件项目的验收管理，主要是在软件已经完成以后，对前期项目或者软件的评价验收。在验收过程中需要对软件进行功能测试和性能调测，其中功能测试主要是看系统软件功能是否和需求定义中所描述的功能相吻合；而性能的调测主要是从系统反映速度、反映能力和系统功能强大方面的考虑。另外，发聊天软件项目的验收还需要包括对软件的运行，因为程序的测试是一个复杂的过程，需要大量的测试才能够测定系软件是否真的全面满足开发软件的需求，只有经过一段时间的试运行才能最终决定软件是否满足人们的需求。

7.2 项目的评估

开发聊天软件项目在验收阶段的评估，是用户接收方还对照需求分析中的“需求规定”对软件进行详细的评估。

评估主要内容包括： i. ii. iii. iv.

是否实现项目目标——开发符合需求的聊天软件； 是否遵循项目进度； 是否在预算成本内完成项目；

项目进度过程中出现的突发问题以及解决措施是否合适，问题是否

得到解决；

v.

从该项目的实践中可以的大哪些经验和教训。

7.3 项目文件归档

项目的终结需要大量的书面工作，主要的工作有： （1） 鉴别未完成的工作和工序；

（2） 核对所有任务和活动的相关记录是否准确、齐备； （3） 确认所有与项目收尾相关的资料是否完整； （4） 检查项目管理计划中的工作是否实际完成； （5） 完成资料的整理工作，为项目的最终移交做准备。 7.4 项目终止

撰写《项目终期报告》，至此，项目完工。

八、团队绩效考核

绩效考核与总结：撰写这份报告从策划到实施最后完成可以作为一个成功的项

目。在开始做第一部分“项目概述”与第二部分“项目范围确定”时，由于首次做项目，大家并不了解应该做的相关内容，采用的方法为小组成员一起讨论，最后由一人总结。在进行后面的内容的撰写时，发现第一部分所缺尚多，而重新进行修改，补充的相关的重要内容，包括WBS图及责任分配等。才使整个项目清晰明了。对下一步的项目编写起到指导作用。后面的部分分工到个人，四人小组再分为两人一组进行，便于管理及分配任务，具体分配为：张冰洁，李颖欣负责四、五；林颖愉，连心负责三、六、七节内容。最后组长做总结及团队绩效考核。所有成员均能在规定的时间完成规定的任务。

通过完成这份报告，首先了解了一个项目策划所需具备的基本内容，前期对项

目总体的确定及规划的重要性。本组项目中间就经历过由于前期规划不明确，导致后期计划报告无法继续编写。继而初步意识到完成一个项目策划所要考虑项目面临的风险和方方面面的变动，在项目实施中，需要对项目的进度进行监控，当面临变化是需及时调整计划。这就需要整个计划有一定的弹性，在面临变化时有更改和喘息的空间。否则一经更改，后面的计划需要全部重新做，甚至有可能因为无法面对变化而被迫终止，成为一个失败的项目。而项目实施中，是经常面临这种变化的。但是好的完善的项目计划则可以在一定程度上通过完善的计划，周到的考虑，最大程度的避免这种大的变动，以达到在预期内完成规定内容。要达到这个目标最重要的就是对成本和风险的估算是否准确。总之，完成统筹一个项目需要计划人员对项目有相当高的了解并能进行正确的估测，项目管理并不是一件简单的事，想做好项目管理不仅需要学很多知识，还要善于利用这些知识做规划与决策。