项目管理说明书2

1、北京师范大学珠海分校管理学院项目管理说明书开发聊天软件生存期中的各阶段定义如下：项目规划阶段阶段目标： 根据初步的需求分析，确定项目的规模、时间计划和资源需求输入： 要求文本，过程： 项目规划，计划确认输出： 项目计划需求分析阶段阶段目标： 确定客户的需求输入： 项目计划，SOW过程： 需求获取，需求分析，需求控制输出： 原型系统，需求规格设计阶段阶段目标： 总体系统结构设计输入： 原型系统，需求规格过程： 总体设计输出： 系统设计说明书，数据库结构定义增量1实现阶段目标： 实现系统的登录功能输入： 系统设计说明书，数据库结构定义过程： 详细设计，编码，代码走查，代码评审，单元测试输出： 详细

2、设计说明书，源代码，可运行版本-1增量2实现阶段目标： 实现系统的聊天功能输入： 系统设计说明书，数据库结构定义过程： 详细设计，编码，代码走查，代码评审，单元测试输出： 详细设计说明书，源代码，可运行版本-2增量3实现阶段目标： 实现系统的信息管理功能输入： 系统设计说明书，数据库结构定义过程： 详细设计，编码，代码走查，代码评审，单元测试输出： 详细设计说明书，源代码，可运行版本-3增量4实现阶段目标： 实现系统的文件传输管理功能输入： 系统设计说明书，数据库结构定义过程： 详细设计，编码，代码走查，代码评审，单元测试输出： 详细设计说明书，源代码，可运行版本-4集成测试阶段目标： 通过集

3、成环境下的软件测试输入： 测试计划，测试用例过程： 集成测试，系统测试输出： 系统软件包，测试报告，产品说明书产品提交阶段目标： 产品可投入使用输入： 系统软件包过程： 产品提交输出： 验收报告2）资源配置情况：人力资源： n 1个管理人员n 2个开发人员n 4个测试人员n 2个设计人员n 2个需求人员设备资源：u 3台电脑u 1台服务器2.4项目工作任务分解概览:详细说明：1.01.11.21.31.41.51.61.71.82.4.2项目结构分解结构图分解描述工作分解结构代号开发聊天系统项目 1.0可交付成果1实现系统的注册功能1.1可交付成果2实现系统的登录功能 1.2可交付成果3 实现

4、系统的发送信息功能1.3工作包1实现系统的发送聊天信息功能工作包2实现系统的发送文件功能工作包3实现系统的发送请求功能可交付成果4实现系统的接收信息功能1.4可交付成果5实现系统的组管理功能1.5工作包1 实现系统的新建组功能工作包2实现系统的删除组功能可交付成果6实现系统的联系人管理功能1.6可交付成果7实现系统的聊天记录管理功能1.7工作包1实现系统的聊天记录查看功能工作包2实现聊天记录导出功能可交付成果8实现系统的个人信息管理功能1.8工作包1实现系统查看个人信息功能工作包2实现系统更改密码功能2.4.3责任分配矩阵活动人员项目经理甲需求人员甲设计人员甲开发人员甲测试人员甲调研RA立项R

5、C需求ARCI设计ACRI编码AR测试AAICR实施RAA维护AR收尾RIIIIR（responsible）负责A（accountable）有责C（consult）咨询I（inform）通知三、风险管理3.1 风险识别过程根据项目的生命周期罗列出主要风险和次要风险，如表3-1所示：项目周期内容主要风险次要风险调研项目需求方整理需求、调研需求不明确风险立项项目需求方提出立项申请，项目管理方立项审批立项风险、技术风险和计划风险协调风险、组织人才风险、责任心风险、政策环境风险需求项目需求方需求细化，开发方完成需求分析，功能分析需求风险，资源风险，系统规模风险和进度风险人力资源风险、协调风险、责任心风

6、险、稳定性风险、经济风险设计项目开发方进行系统设计管理风险、相关性风险和进度风险协调风险、人力资源风险、责任心风 险和稳定性风险编码技术人员完成软件编码、代码检查技术风险、进度风险协调风险、人力资源风险、责任心风险、系统稳定 性风险测试技术人员完成功能测试技术风险、相关性风险协调风险、保障性风险、人力资源风险、责任心风险实施制定上线计划，完成软件运行计划风险、技术风险、进度风险、合作风险，资源风险、管理风险协调风险、保障性风险、人力资源风险、责任心风险维护进行软件日常维护需求风险，资源风险，系统规模风险协调风险、保障性风险、责任心风险、系统稳定性 风险收尾关闭项目费用风险保障性风险表3-1：项

7、目的生命周期及其风险风险因素识别方法：头脑风暴法；头脑风暴法：将项目成员聚集在一起，通过头脑风暴会议，产生一个潜在风险因素的清单。在会议过程中，不能对他人的观点作评价和批判，也不采取强压措施促使大家保持一致，鼓励所有成员畅所欲言，提出意见，而不用承担任何风险。最后将各位成员的意见分析归纳总结，最终的得到 7项主要风险因素清单。如表3-2所示：序号风险因素描述A需求分析不准确需求内容表述不清，导致需求容易发生变化，技术人员对需求内容理解错误，需求分析出现错误等。B需求变更由于客户提出的需求不明确造成需求不断变更，甚至项目范围扩大，成本上升，进度延迟；C缺少用户支持用户积极配合项目开展对项目成功至

8、关重要，需要授权执行项目给用户执行；D设计方案出现偏差设计方案、功能设计出现错误，功能设计考虑不周全，变更计；E沟通风险技术人员与需求人员之间，或技术人员之间的沟通出现问题，影响了项目实施的协同性作用；F人力资源风险人员流动特别是技术骨干力量流失。G进度风险由于项目范围不断扩大或者人员安排等导致的项目延期，不能到期完成项目的问题表3-2：项目风险因素3.2风险可能性和后果分析对项目风险进行定性分析，定性风险分析是一种对风险和条件进行定性分析，并按影响大小排列它们对项目目标的影响顺序的分析方法。根据项目的潜在风险影响来对项目风险进行分类，如表3-3所示：对项目风险分类序号风险因素后果可能性A需求

9、分析不准确高高B需求变更高中C缺少用户支持低中D设计方案出现偏差高中E沟通风险中中F人力资源风险高低G进度风险中高表3-3 项目风险因素分类将风险分为三个等级：高风险、中等风险、低风险；根据表3-2的分类，绘制风险影响矩阵，如图3-4所示：后果 低 中 高高GA可能性中CEB、D低F图3-4 项目风险矩阵3.3风险应对针对风险定性分析的结果，来实施已经获得统一和资金支持的风险应对措施，以降低 IT 项目的风险的消极作用。在风险规划风险应对的过程中，需要根据风险的优先级来制定应对措施。险应对策略包括风险回避、转移、减轻、接受、开拓、分享、提高等。（1） 需求分析不准确与需求不断变更需求不明确引起

10、需求不断变更，需求不断变更也会造成需求分析不准确。用户过度期望与需求分析不准确也存在类是的关系。需求风险对项目产生各种影响，项目风险管理人员必须在早期进行重点预防，加强需求沟通，业务分析师需要在项目前期全新投入工作，尽量明确每一项需求的内容、范围、要求。（2） 进度风险控制项目进度缓慢会影响项目的成本，如果项目导致系统上线延迟，可能影响业务开展，还可能造成系统质量问题。进度控制的目标是了解项目的当前状态，了解导致进度变更的因素。确定进度是否已经发生变更，以及当前发生变更时，管理好这些变更。控制项目进度的变更首先要确保所编制的项目进度符合时机，要使用纪律手段来控制项目的进度，并且要由领导来强调按

11、照进度开展项目的重要性。虽然许多工具和技术可以帮助进行进度控制，但是项目经理需要格外重视人事管理问题。项目失败不是业务编制的 PERT 不好，而是因为人事管理的失败。（3） 交流与沟通用户的需求沟通、与团队成员的合作沟通都将对项目产生重大的影响。只有双方建立良好的沟通与协作机制，才能努力完成项目的目标，只有建立有效的项目信任沟通机制，才能避免在需求分析、系统设计、系统评价标准、项目验收标准、项目质量等方面可能出现的分歧与失误。实施软件项目是外包双方互相配合、共同合作的过程。四、成本估算分析 软件开发成本估算主要指软件开发过程中所花费的工作量及相应的代价。 不同与传统的工业产品，软件的成本不包括

12、原材料和能源的消耗，主要是人的劳动的消耗。另外，软件也没有一个明显的制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此，软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、集成测试到认证测试，整个开发过程所花费的代价作为依据的。 对此项目的估算以客观量化估算，主要计算人工成本。所得数据使用比较估算法，利用从网上所查得的软件类过去基本工资对现在的工资进行估算。参考construx软件公司的史蒂文提出的软件项目分为六个部分：体系构造；详细设计；编码和调试；开发者测试；系统整合；系统测试。COCOMO模型(constructive cost model) 先使用coc

13、omo模型对项目成本做大概估算COCOMO模型中用到以下变量：DSI-源指令条数。不包括注释。1KDSI = 1000DSI。MM-开发工作量（以人月计） 1MM = 19 人日 = 152 人时 =1/12 人年TDEV-开发进度。(以月计)本软件适用于组织型模型组织型(organic): 相对较小、较简单的软件项目。开发人员对开发目标理解比较充分，与软件系统相关的工作经验丰富，对软件的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（<50000行） 估算公式：基本COCOMO模型估算工作量和进度的公式如下工作量： MM = r*(KDSI)c 进度： TDKV = a(MM)b

14、其中经验常数 r, c, a, b 取决于项目的总体类型。基本COCOMO模型通过统计63个历史项目的历史数据，得到如下计算公式。方式rCAb组织型2.41.052.50.38半独立型3.01.122.50.35嵌入型 3.61.22.50.32总体类型工作量进度组织型MM = 2.4*(KDSI)1.05TDKV = 2.5(MM)0.38半独立型MM = 3.0*(KDSI)1.12TDKV = 2.5(MM)0.35嵌入型MM = 3.6*(KDSI)1.20TDKV = 2.5(MM)0.32根据经验法估计工作量为1KDSI左右，则工作量MM计算为2.4=45.6人天=364

15、.8人时。4.1对项目工作量进行估算： 估算软件大小使用策略：以功能点为基础，估算问题大小。开发一个功能点需要5个人天的工作量，那么该项目的工作量就可以通过以下公式计算出来： 项目工作量=4*13=52人天与cocomo模型所估算量45.6人天相比，结果相近。对项目日期做保守估算，使用功能点估算时间52人天做成本预算。4.2对项目所需资源、各阶段工作量进行估算使用参数模型法进行估算参数模型法：提供一个估算方程，它把软件某一属性的度量作为输入，软件的工作量和工作进度则是输出。成本算法模型提供了对工作量和工作进度的直接估算，有两种主要类型：1数学模型，核心部分往往是一个估算方程，该方程以影响开发成

16、本的某些项目因素作为输入，输出的是项目开发的工作量和工作进度；2检索表，根据一定的规则对软件对象进行分类，然后以每一种类型提供工作量或工作进度的平均值作为参考，适用于软件项目分解的较低层次。人力资源估算设计人员2人需求人员2人开发人员2人测试人员4人4.3瀑布模型生命周期各阶段瀑布模型生命周期各阶段立项阶段2.0%需求阶段5.0%计划阶段6.0%设计阶段22.0%开发阶段22.0%系统测试阶段25.0%用户验收阶段11.0%结项阶段7%4.4以1.12做个人时间乘数，对项目周期估算以1.12为个人时间乘数，调整项目所需时间为52*1.12=58人/天生命周期各阶段项目所占比重工时数人/天参与角

17、色参与人数天数立项阶段2.0%1.16项目经理11.16需求阶段5.0%2.9需求人员21.45计划阶段6.0%3.48项目经理13.48设计阶段22.0%12.76设计人员26.38开发阶段22.0%12.76开发人员26.38系统测试阶段25.0%14.5测试人员43.625用户验收阶段11.0%6.38测试人员甲需求人员甲项目经理甲41.595结项阶段7.0%4.06全体成员41.015项目周期（天）25.0854.5项目成本估算工种人数参考数据（元/月）估算成本设计人员2人800016000需求人员2人500010000开发人员2人600012000测试人员4人450018000项目经

18、理190009000每月成本（元）65000项目期为1个月，总成本（元）65000五、进度估算5.1 项目活动进度估算表序内容时间11立项12需求13计划24完成各个功能模块的具体设计5完成各个功能模块的编码工作6完成软件的测试57完成软件的正常运行8完成软件的维护工作59完成该软件设计的项目报告5.2 项目活动紧前活动及估计历时描述紧前活动估计历时A1立项无2A2需求A12A3计划A24B1系统的登录功能计划A31B2系统的聊天功能计划B22B3系统的信息管理功能计划B32B4系统的文件传输管理功能B32C1系统的登录功能编码B11C2系统的聊天功能编码B2、C12C3系统的信息管理功能编码

19、B3、C22C4系统的文件传输管理功能编码B4、C32D1系统的登录功能测试C11D2系统的聊天功能测试C2、D11D3系统的信息管理功能测试C3、D21D4系统的文件传输管理功能测试C4、D31E完成软件的正常运行D41F完成软件的维护工作E1G结项F25.3 使用Microsofit Project 软件5.3.1 使用软件建立甘特图依据项目活动紧前活动及估算历时表，输入“活动项目”、“工期”、“开始时间及完成时间”、“紧前活动”。最后得出甘特图，如上图所示。5.3.2使用软件建立资源工作表： 依据人员资源估算表输入“资源名称”及“标准费率”等，建立资源工作表如上图所示。5.3.3 使用软

20、件查看网络图六、项目的沟通与评审 项目评审的主要目的是根据项目计划对项目的执行活动进行检查，及时发现问题，研究解决对策，纠正偏差，保证项目的顺利实施。项目交流计划分为如下几类“ 每天17：:00的沟通交流 定期评审 阶段评审 事件评审 各类交流评审安排见表：评审类型评审周期评审要点相关人员日例会每天17:00-17:301. 不限定主题和内容，随意交流2. 共享经验，避免错误项目组所有人定期评审每周五1. 本周工作进度2. 问题及对策3. 资源协调4. 下周工作安排项目经理开发经理测试经理阶段评审阶段结束1. 本阶段计划执行情况2. 质量评审结果3. 产品审计结果4. 下阶段计划修正项目经理开

21、发经理测试经理事件评审当事件可能影响计划的执行1. 事件性质和影响范围2. 事件处理方案的讨论3. 修改计划的评审事件项目经理开发经理测试经理七、项目收尾和终止7.1 项目的验收 开发聊天软件项目收尾阶段的验收主要是依据其大小、性质、特点进行验收，由于验收环节较多、内容繁杂，因而验收管理的程序也相对复杂，最终对于本项目按照了大型软件建设开发验收程序进行了验收管理，详见如图 7-1 所示。开发聊天软件项目 准备验收材料 项目团队自检 提交验收申请书和验收资料 初审 正式验收 签署验收合格文件 项目移交 图7-1 开发聊天软件项目验收管理程序总的来说，开发聊天软件项目的验收管理，主要是在软件已经完

22、成以后，对前期项目或者软件的评价验收。在验收过程中需要对软件进行功能测试和性能调测，其中功能测试主要是看系统软件功能是否和需求定义中所描述的功能相吻合；而性能的调测主要是从系统反映速度、反映能力和系统功能强大方面的考虑。另外，发聊天软件项目的验收还需要包括对软件的运行，因为程序的测试是一个复杂的过程，需要大量的测试才能够测定系软件是否真的全面满足开发软件的需求，只有经过一段时间的试运行才能最终决定软件是否满足人们的需求。7.2 项目的评估开发聊天软件项目在验收阶段的评估，是用户接收方还对照需求分析中的“需求规定”对软件进行详细的评估。评估主要内容包括：i. 是否实现项目目标开发符合需求的聊天软件；ii. 是否遵循项目进度；iii. 是否在预算成本内完成项目；iv. 项目进度过程中出现的突发问题以及解决措施是否合适，问题是否得到解决；v. 从该项目的实践中可以的大哪些经验和教训。7.3 项目文件归档项目的终结需要大量的书面工作，主要的工作有：（1） 鉴别未完成的工作和工序；（2） 核对所有任务和活动的相关记录是否准确、齐备；（3） 确认所有与项目收尾相关的资料是否完整；（4） 检查项目管理计划中的工作是否实际完成；（5） 完成资料的整理工作，为项目的最终移交做准备。