当前位置:文档之家› 项目管理说明书.doc

项目管理说明书.doc

北京师范大学珠海分校管理学院项目管理说明书——开发聊天软件生存期中的各阶段定义如下:项目规划阶段阶段目标:根据初步的需求分析,确定项目的规模、时间计划和资源需求输入:要求文本,过程:项目规划,计划确认输出:项目计划需求分析阶段阶段目标:确定客户的需求输入:项目计划,SOW过程:需求获取,需求分析,需求控制输出:原型系统,需求规格设计阶段阶段目标:总体系统结构设计输入:原型系统,需求规格过程:总体设计输出:系统设计说明书,数据库结构定义增量1实现阶段目标:实现系统的登录功能输入:系统设计说明书,数据库结构定义过程:详细设计,编码,代码走查,代码评审,单元测试输出:详细设计说明书,源代码,可运行版本-1增量2实现阶段目标:实现系统的聊天功能输入:系统设计说明书,数据库结构定义过程:详细设计,编码,代码走查,代码评审,单元测试输出:详细设计说明书,源代码,可运行版本-2增量3实现阶段目标:实现系统的信息管理功能输入:系统设计说明书,数据库结构定义过程:详细设计,编码,代码走查,代码评审,单元测试输出:详细设计说明书,源代码,可运行版本-3增量4实现阶段目标:实现系统的文件传输管理功能输入:系统设计说明书,数据库结构定义过程:详细设计,编码,代码走查,代码评审,单元测试输出:详细设计说明书,源代码,可运行版本-4集成测试阶段目标:通过集成环境下的软件测试输入:测试计划,测试用例过程:集成测试,系统测试输出:系统软件包,测试报告,产品说明书产品提交阶段目标:产品可投入使用输入:系统软件包过程:产品提交输出:验收报告2)资源配置情况:人力资源:⏹1个管理人员⏹2个开发人员⏹4个测试人员⏹2个设计人员⏹2个需求人员设备资源:◆3台电脑◆1台服务器2.4项目工作任务分解2.4.1概览:详细说明:1.01.1 1.2 1.3 1.4 1.5 1.6 1.7 1.81.3.1 1.5.11.3.2 1.3.3 1.5.21.7.11.7.21.8.11.8.22.4.2项目结构分解结构图2.4.3责任分配矩阵R(responsible)负责A(accountable)有责C(consult)咨询I(inform)通知三、风险管理3.1 风险识别过程风险因素识别方法:头脑风暴法;头脑风暴法:将项目成员聚集在一起,通过头脑风暴会议,产生一个潜在风险因素的清单。

在会议过程中,不能对他人的观点作评价和批判,也不采取强压措施促使大家保持一致,鼓励所有成员畅所欲言,提出意见,而不用承担任何风险。

最后将各位成员的意见分析归纳总结,最终的得到7项主要风险因素清单。

如表3-2所示:序号风险因素描述A 需求分析不准确需求内容表述不清,导致需求容易发生变化,技术人员对需求内容理解错误,需求分析出现错误等。

B 需求变更由于客户提出的需求不明确造成需求不断变更,甚至项目范围扩大,成本上升,进度延迟;C 缺少用户支持用户积极配合项目开展对项目成功至关重要,需要授权执行项目给用户执行;D 设计方案出现偏差设计方案、功能设计出现错误,功能设计考虑不周全,变更计;E 沟通风险技术人员与需求人员之间,或技术人员之间的沟通出现问题,影响了项目实施的协同性作用;F 人力资源风险人员流动特别是技术骨干力量流失。

G 进度风险由于项目范围不断扩大或者人员安排等导致的项目延期,不能到期完成项目的问题表3-2:项目风险因素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): 相对较小、较简单的软件项目。

开发人员对开发目标理解比较充分,与软件系统相关的工作经验丰富,对软件的使用环境很熟悉,受硬件的约束较小,程序的规模不是很大(<50000行)估算公式:基本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 项目活动紧前活动及估计历时D3 系统的信息管理功能测试C3、D2 1D4 系统的文件传输管理功能测试C4、D3 1E 完成软件的正常运行D4 1F 完成软件的维护工作 E 1G 结项 F 25.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.从该项目的实践中可以的大哪些经验和教训。

相关主题