软件项目管理参考文档

《软件项目管理参考文档》由会员分享，可在线阅读，更多相关《软件项目管理参考文档（86页珍藏版）》请在装配图网上搜索。

1、个人微薄系统个人微薄系统项目管理文档项目管理文档小组成员分工及组长打分小组成员分工及组长打分班级学号姓名承担工作组长打分10 分教师打分0718200792104李鑫范围计划、文档整合、PM10 分0726200792084秦宇进度计划8.4 分0727200792366宁珠风险计划、配置管理计划、集成计划7.7 分0718200792286黄金虎成本计划9.5 分0726200792210陆金执行控制过程、软件项目结束8.5 分0721200792388张雪娇质量计划、人力资源计划、沟通计划、合同计划8.7 分评语个人微薄系统个人微薄系统项目管理文档项目管理文档 2010 年 11 月 7

2、日星期日目录1.引言引言.- 7 -1.1 编写目的.- 7 -1.2 范围.- 7 -1.3 项目简介.- 7 -1.4 开发背景.- 7 -1.5 缩写说明.- 8 -1.6 参考资料.- 8 -2.项目概述项目概述.- 8 -2.1 工作内容.- 8 -2.2 交付项.- 9 -2.3 非交付项.- 9 -3.项目任务范围项目任务范围.- 9 -4.项目目标项目目标.- 10 -5.项目实施策略项目实施策略.- 10 -5.1 项目管理策略.- 11 -5.2 软件开发策略.- 11 -6.计划结构计划结构.- 11 -7.项目组织结构项目组织结构.- 15 -8.项目生存期：项目生存期

3、：.- 21 -8.1 对生存期模型的选择.- 21 -9.项目管理对象项目管理对象.- 25 -9.1 阶段一：可行性研究.- 25 -9.2 阶段二：需求分析.- 25 -9.3.阶段三：总体设计.- 26 -9.4.阶段四：详细设计.- 27 -9.5.阶段五：系统实现.- 28 -9.6阶段六：测试.- 28 -9.7.阶段七：运行和维护.- 28 -9.8.贯穿于项目的文档管理.- 29 -10项目风险管理项目风险管理.- 31 -10.1、项目风险管理的目的.- 31 -10.2、项目风险管理的组成.- 31 -10.3、风险的种类.- 31 -10.4、定义风险参数.- 34 -

4、10.5、风险管理策略.- 35 -10.6、风险管理角色及职责.- 35 -10.7、个人微薄项目中风险的识别.- 35 -10.8、风险的控制.- 36 -10.9 风险监控 .- 37 -10.10、微薄项目的风险管理.- 37 -11项目估算项目估算.- 39 -12 项目时间计划项目时间计划.- 43 -12.1 序言 .- 43 -12.2 任务分解.- 44 -12.3 项目进度计划 .- 45 -12.4 甘特图 .- 47 -13 关键资源计划关键资源计划.- 48 -13.1 序言 .- 48 -13.2 关键资源列表及说明 .- 49 -14项目设施工具计划项目设施工具计

5、划.- 50 -14.1.项目实施工具计划表.- 50 -14.2.设施工具操作要求.- 52 -15项目质量计划项目质量计划.- 53 -15.1 组织机构.- 53 -15.2 职责.- 54 -15.2.1 高层管理 .- 54 -15.2.2 项目的质量保证人员 .- 54 -15.2.3 项目经理.- 55 -15.3.质量目标.- 55 -15.4.质量策略.- 56 -15.5.软件质量保证.- 57 -15.5.1 SQA 活动图 .- 57 -15.5.2 角色 .- 58 -15.5.3 进入准则 .- 59 -15.5.4 输入.- 59 -15.5.5 活动 .- 59

6、 -15.6.质量控制活动.- 65 -15.7不符合性问题处理.- 66 -15.8.记录的收集、维护和保存.- 67 -16.配置管理计划配置管理计划.- 67 -16.1 配置管理的目的.- 67 -16.2 软件项目管理的职责及角色.- 68 -16.3 命名规范 .- 70 -16.4 主要配置项如下：.- 70 -17、项目管理评审、项目管理评审.- 75 -18、项目度量计划、项目度量计划.- 83 -18.1规模度量规模度量.- 83 -18.2时间度量.- 83 -18.3需求变更度量.- 84 -19、沟通计划、沟通计划.- 85 - 1.引言引言1.1 编写目的编写目的主

7、要为保证整个项目能够按时，保质，保量的完成，每个人在项目开发中都能够发挥自己的作用，使整个软件开发过程顺利，平稳，有序的进行，提供有效的进度参考。1.21.2 范围范围本文档适用于个人微薄系统这一软件项目。1.31.3 项目简介项目简介1.3.1 项目名称个人微薄系统1.3.2 产品标识个人微薄系统 ，缩写 My Blog，版本号：1.01.41.4 开发背景开发背景彰显个性、展示自我、为广大网友提供和一个交流和展示的平台。在网络交流日益频繁的今天，一个成熟的微薄系统可以更加方便于网友之间的互相交流、传递信息。成熟有效、功能完善的 My Blog 系统，它主要包括：身份验证、浏览微薄、发表微薄

8、、发表评论、微薄管理、等几大模块。1.51.5 缩写说明缩写说明SQA： 软件质量保证（Software Quality Assurance）QA： 质量保证（Quality Assurance）SEPG： 软件工程过程组（Software Engineering Process Group）SPI： 软件过程改进（Software Process Improve）SCM： 软件配置管理（Software Configuration Management）PM： 项目经理（Project Management）SM： 高级经理（Senior Management）1.61.6 参考资料参考资料

9、1马瑞新 等： 2.0 程序设计案例教程 ，清华大学出版社 2009年版；2刘伟琴、黄广华：Web 程序设计（第四版） ，清华大学出版社 2008 年版；2.项目概述项目概述个人微薄是一个较为复杂的网络交流系统，在工程建设过程中，需要一套全面的、高效的工程管理方法来辅助，以对工程中的项目、合同、预算执行、财务收支、资产情况、档案情况进行管理，并将这些情况定期统计、汇总、发布。2.12.1 工作内容工作内容按照项目所包括的知识领域，以及项目整个的生命周期，我们把项目分成项目立项，项目计划，项目执行和控制，项目结束四个阶段。项目的立项里我们要成立项目小组，选出项目经理（组长） ，小组成员，然后召开

10、全部成员参加的项目组成立会，初步确定每个人在项目中的角色。然后要根据项目需求任务书，对项目进行可行性分析。在需求阶段 ，要进行需求的调研，确认，需求分析等工作，这个阶段工作结束要完成需求规格说明书与客户确认。在设计阶段，要完成系统的总体设计和详细设计，并完成总体设计和详细设计说明书。同时要编写系统说明书，用户使用说明书等。在编码阶段，要编写相应的程序组件并分别进行单元测试。在测试阶段，要根据完成的测试计划，编写测试用例，进行系统的各项测试，形成系统的测试报告。 在部署阶段，主要实际完成整个系统产品并的部署，保证系统上线运行，并进行系统维护。2.22.2 交付项交付项软件需求规格说明书系统概要设

11、计说明书系统详细设计说明书程序代码系统测试方案和测试用例产品用户说明书等2.32.3 非交付项非交付项主要软件开发过程文档和中间产品：用例图，用例文档，项目计划，类图和时序图等。3.项目任务范围项目任务范围个人微薄系统项目需要完成的任务大致分为身份验证、微薄功能两大部分，微薄功能包括浏览微薄、发表微薄、微薄管理、等几大模块，身份验证功能包括登录、提示重新登录、未注册用户注册。用户注册又包含添加头像这一可选功能。浏览微薄功能包括浏览微薄、发表评论、评星级、排序、播放背景音乐。发表微薄功能包括添加背景音乐这一可选功能。微薄管理功能包括删除已有微薄、修改微薄。图 3.1 是项目任务的范围图示。F个人

12、博客系统F1身份验证F2.1浏览博客F2.2发表博客F2.3博客管理F1.1登录F1.3登录失败提示F2博客功能F1.2用户注册F1.2.1选择上传头像F2.1.1浏览文章F2.1.2评星级F2.1.3评论F2.1排序F2.2.1选择添加背景音乐F2.3.1删除已有博客F2.3.2修改现有博客4.项目目标项目目标微薄是本世纪才出现的一种新型的网络交流模式，但是因为其种种特性，使得它在短短 10 年之内迅速发展。本微薄系统实现了传统微薄系统的所有功能，并且有了很多改进，可以说此系统已经站在了微薄系统的最前列，代表了微薄系统的新高度。在越来越网络化的今天，微薄已经成了一种潮流，有了本系统，您可以：

13、在网上注册本系统，实时发布自己的微薄，也可以浏览别人发表的自己感兴趣的微薄。5.项目实施策略项目实施策略项目实施策略是确定如何实施项目以达到项目目标的策略。根据微薄系统的性质及特殊要求，确定了以下策略：5.15.1 项目管理策略项目管理策略项目管理过程遵循公司质量体系中关于项目管理过程的规范。根据项目计划中的评审点进行跟踪和管理，并根据结果对项目计划进行适当的调整。评审采用定期评审，阶段评审和事件评审相结合的方式。按周发布项目简报，通报项目的进展情况及其他相关情况。5.25.2 软件开发策略软件开发策略采用 OO 技术逐步构造系统。产品按阶段提交。开发实施过程采用公司的复用技术，同时遵循公司质

14、量体系中关于项目实施过程的规范。质量保证策略 质量管理过程遵循公司质量体系中关于项目质量管理过程的规范。加强对项目参与人员的质量保证概念的培训。加强对过程的控制，重点确定该项目中需控制的过程。加强对产品规范的审计，重点确定该项目中需要审计的产品。实施完整的软件配置管理。6.计划结构计划结构项目计划组成结构图：计划名称对应部分简要描述范围计划项目人物范围确定项目的范围，为制定其他计划打下基础。范围管理是项目实施的依据和变更的输入，另外还包括对可交付成果落实到个人上的分解，即项目分解结构（WBS），通过 WBS 清楚明确地组织并定义了整个项目的范围，以及该项目的参与者各自的分工。成本计划项目估算成

15、本计划是对完成项目所需费用的估计和计划，是项目计划中的一个重要组成部分。软件成本估算是成本管理的核心，是预测开发一个软件系统所需要的总工作量的过程。软件成本估算以从软件计、需求分析、设计、编码、单元测试、集成测试到接受测试等这些过程所花费的代价为依据，对完成项目所需要的所有费用进行估算。进度计划项目时间计划进度计划是从时间的角度对项目进行规划。时间是一种特殊的资源，以其单向性、不可重复性、不可替代性而有别于其他资源，因此进度计划也是项目计划中最难、最重要、最核心的部分。在进度计划中，首先根据任务分解的结果（WBS）再进一步分解出主要的任务（活动），确立任务（活动）之间的关联关系，然后估算出每个

16、任务（活动）需要的资源、历时，最后编制出完整的进度计划（如进度表）。风险计划项目风险分析风险计划是在项目进行过程中不断对风险进行识别、评估、制定策略、监控风险的过程，它是项目管理中最容易被忽略而且最难以管理的环节。通过风险识别、风险分析和风险评价去认识项目的风险，并以此为基础合理的使用各种风险应对措施，管理方法、技术和手段对项目的风险进行有效的控制，妥善处理风险事件造成的不利后果，以最小成本保证项目总体目标的实现。人力资源计划项目组织结构人是软件项目中最重要的因素，因此软件项目人力资源管理计划也是项目计划中根本的一项计划。人力资源管理是保证参加项目的人员能够被最有效使用所需要的过程，是对项目组

17、织所储备的人力资源开展的一系列科学规划、开发培训、合理调配、适当激励等方面的管理工作，是项目组织各方面人员的主观能动性得到充分发挥，做到人尽其才，事得其人、人事相宜，同时保持项目组织高度的团结性和战斗力，从而成功地实现项目组织的既定目标。关键资源计划关键资源计划关键资源计划是对项目所需关键资源根据生存期阶段所做的计划。关键资源包括引起竞争的人力和设备资源。设施工具计划设施工具计划实施工具计划是对项目开发所需的设备和支持工具所做的计划。质量管理计划质量管理计划质量管理计划主要是确定项目应达到的质量标准，以及决定如何满足质量标准的计划安排和方法；依据公司的质量方针、产品描述以及质量标准和规则等制定

18、出实施策略，其内容全面反映用户的需求，为质量小组成员有效工作提供指南，也为项目相关人员了解在项目进行中如何实施质量保证和控制提供依据。合适的质量标准是质量计划的关键。配置管理计划配置管理计划软件配置管理计划用来确定软件配置管理的解决方案，软件配置管理的解决方案涉及面很广，将影响软件软件开发环境、软件过程模型、配置管理系统的使用者、软件产品的质量和用户的组织机构。该计划由配置管理者负责制定，它是软件配置管理规划过程的产品，并在整个软件项目开发过程中作为配置管理活动的依据进行使用和维护。沟通计划沟通计划保证项目成功必须进行沟通，为了有效的沟通，需要创建一个沟通计划。沟通计划决定项目相关人的信息和沟

19、通需求：谁需要什么信息、什么时候需要、怎样获得、选择的沟通模式什么时候采用书面沟通和什么时候采用口头沟通、什么时候使用非正式的备忘录和什么时候使用正式的报告等等。7.项目组织结构项目组织结构对项目组织结构的选择在项目组织结构的选择上，由于几种组织结构的适用条件对于项目组目前的情况来讲都有一定程度的符合，因此对各个组织结构优缺点的权衡成为了人力资源计划的一个难题，下面对各个组织结构的优缺点进行一下比较：1以职能部门作为承担项目任务的主体，可以充分发挥之职能部门的资源集中优势，有利于保障项目需要资源的供给和项目可交付成果的质量。在人与那的使用上具有较大的灵活性。2职能部门内部的技术专家可以被该部门

20、承担的不同项目共享，节约人力，减少了资源的浪费。3同以职能部门内部的专业人员便于相互交流、相互支援，对创造性地解决技术问题很有帮助。同部门的专业人员易于交流知识和经验，项目成员事业上具有连续性和保障性。职能型优点4当有项目成员调离项目或离开公司，所属职能部门可以增派人员，保持项目的技术连续性。5项目成员可以将完成项目和完成本部门的职能工作融为一体，可以减少因项目的临时性而给项目成员带来的不确定性。1客户利益和职能部门的利益经常发生冲突，职能部门会为本部门的利益而忽视客户的需求，精力只集中于本职能部门的活动，项目及客户得到利益往往得不到优先考虑。2当项目需要多个职能部门共同完成，或者一个职能部门

21、内部有多个项目需要完成时，资源的平衡就会出现问题。3当项目需要由多个部门共同完成时，全力分割不利于各职能部门之间的沟通交流、团结协作。项目经理没有足够的权利控制项目的进展。缺点4项目成员在行政上仍隶属于各职能部门的领导，项目经理对项目成员没有完全的权利，项目经理需要不断地同职能部门经理进行有效的沟通以消除项目成员的顾虑。当小组成员对部门经理和项目经理都要负责时，项目团队的管理常常是复杂的，对这种双重报告关系的有效管理常常是项目最重要的成功因素，而且通常是项目经理的责任。适用条件适用于主要由一个部门完成的项目或技术比较成熟的项目。分析职能型组织结构能够方便同班成员或者相互熟悉的成员（即下面的小组

22、内成员）间进行交流和支援，有利于各小组内成员进行沟通；而且各小组内的成员还能够继续一起完成现阶段的其他任务，并运用相似的技术进行后续其他项目的开发。但该项目组的成员来自不同班级，总人数较少，成员互相之间的了解也较少，因此这种组织结构难以平衡各小组的资源，不利于小组间信息的传递，完成各部分任务所需要的工作量与小组的成员数不均衡，从而对人员的管理与任务分配造成很大困难。1项目经理对项目可以全权负责。可以根据项目需要随意调动项目组织的内部资源或者外部资源。2项目型组织的目标单一，完全以项目为中心安排工作，决策的速度得以加快，能够对客户的要求做出及时响应，项目团队精神得以充分发挥。有利于项目的顺利完成

23、。3项目经理对项目成员有全部权利，项目成员只对项目经理负责，避免了职能型项目组织下项目成员处于多重领导、无所适从的局面，项目经理是项目的真正、唯一的领导者。优点4组织结构简单，易于操作。项目成员直接属于同一个部门，彼此之间的沟通交流简介、快速，提高了沟通效率，同时也加快了决策速度。1每一个项目型组织，资源不能共享，即使某个项目的专用资源闲置，也无法应用于另外一个同时进行的类似项目，人员、设施、设备重复配置，会造成一定程度的资源浪费。2公司里各个独立的项目型组织处于相对封闭的环境之中，公司的宏观政策、方针很难做到完全、真正的贯彻实施，可能会影响公司的长远发展。3在项目完成以后，项目型组织中的项目

24、成员或者被拍到另一个项目中去，或者被解雇，对项目成员来说，缺乏一种事业上的连续性和安全感。缺点4项目之间处于一种条块分割状态，项目之间缺乏信息交流，不同的项目组很难共享知识和经验，项目成员的工作会出现忙闲不均的现象。适用条件适用于开拓性等风险较大的项目或进度、成本、质量等指标有严格要求的项目；不适合人才匮乏或规模小的企业。项目型分析由于该项目具有很大的临时性，项目组的成员也是从不同的班级集中到一起，因此项目型组织结构利于团队的建设以及小组人员与任务的分配；另外该组织结构简单易操作，而且目标单一，特别适用于这种零散的人员调度，同时很大程度上方便了成员间整体的沟通交流，加快了决策速度。由于这个项目

25、各模块间的耦合度较低，不需要小组间大量的信息共享；而且项目组内有着统一的交流方式（临时的网上讨论组），各项决策规定可以第一时间直接反映给项目成员；更兼此项目本来就是一次独立的开发，与其他项目在人员和技术上没有紧密的联系，因此项目成员在项目完成后都已经有足够的准备和清楚的打算。然而这种组织结构也在一定程度上破坏了原有的一些成员关系（比如同班的成员），需要这些成员重新建立起新的沟通交流机制。1专职的项目经理负责整个项目，以项目为中心，能迅速解决问题。在最短的时间内调配人才，组成一个团队，把不同职能的人才集中在一起。2多个项目可以共享各个职能部门的资源。在矩阵管理中，人力资源得到了更有效地利用，减少

26、了人员冗余。研究表明：一般使用这种管理模式的企业比传统企业少用 20%的员工。3既有利于项目目标的实现，也有利于公司目标方针的贯彻。优点4项目成员的顾虑减少了，因为项目完成后，他们仍然可以回到原来的职能部门，不用担心被解散。而且他们能有更多机会接触自己企业的不同部门。1容易引起职能经理和项目经理权利的冲突。2资源共享也能引起在项目之间的冲突。矩阵型缺点3项目成员有多位领导，即员工必须要接受双重领导，因此经常能体会到焦虑与压力。当两个经理的命令发生冲突时，他必须能够面对不同指令形成一个综合决策来确定如何分配他的时间。同时，员工必须和他的两个领导保持良好的关系，应该显示出对这两个主管的双重忠诚。适

27、用条件适用于管理规范、分工明确的公司或者跨职能部门的项目分析矩阵型组织结构综合了职能型组织结构和项目型组织结构一定的优点，以项目为中心，即可以充分利用各部分的资源，又放宽了职能对项目成员的限制，而且项目的方针决策也能够方便直接地传递给项目成员。然而由于参与项目的总人数本来就非常少，另外由于此项目各模块间的松耦合，不需要领导间过多的协调配合，因此这种交叉调配人员的方式实现起来不具备足够的可行性，落实在这个项目上也有些大材小用。权衡各组织结构的优缺点，经过详细的分析，由于项目的临时性乃至项目组的临时性是在这个项目人员组织准则角度上最突出的特点，因此，为了充分利用项目型组织结构对于此类人员及项目在团

28、队组织上的突出优势，此项目即采用了项目型组织结构。组织结构图如下：简要说明：该项目组共有 6 名成员。总负责人，即项目经理由李鑫担任。项目组向下又细分为软件开发小组（由 6 名成员共同组成，负责人为秦宇） 、质量保证小组（负责人为陆金，组员为宁珠） ；由于此项目需求不是特别明确，而且经常需要功能扩充，因此单独成立了一个需求分析与软件测试小组（负责人为张雪娇，组员有李鑫、秦宇） 。各小组职责如下：项目组负责项目的组织和规划。负责项目计划制定和维护。负责项目的跟踪和管理。负责资源的分配和协调活动。负责各组织和计划之间的协调活动。软件开发小组负责项目的软件开发，包括设计、编码、单元测试。负责产品质量

29、控制的工作。负责配合质量保证的活动，如系统测试、文档编制等。配合产品验收的相关活动。质量保证小组负责项目过程和产品规范的制定。负责项目过程的质量保证活动，其中包括过程评审和产品评审。需求分析与软件测试小组负责分析频繁变更的需求，并将需求反映到系统应实现或改变的功能上。负责系统进行集成测试。负责对每一个变化的需求进行阶段性测试。8.项目生存期：项目生存期：8.1 对生存期模型的选择对生存期模型的选择该项目的特点此项目需求比较模糊，在开发过程中极有可能发生需求的变更，即使在开发结束后，也常常需要功能上的扩充，面向的用户群体相当广泛，不同的用户都有可能提出该系统针对某一类群体的改进意见和要求。项目组

30、内部对此系统的认识也不够统一，对大量辅助功能及新增功能有不同的看法，需要在基本的核心功能完成之后，随着项目的进行，由项目经理进一步收集用户及成员的想法意见进行决策。用户及成员都需要在短时间内得到一个系统最初的版本，对其进行评价并在后续的开发上对其定位，并得出更多明确的需求。在项目本身的开发上，为了使系统锦上添花，会用到许多开发人员也并不熟悉的技术，这可能需要开发人员进一步的学习后，再对系统进行改进。针对该项目的这些特点，权衡各个生存期的适用条件，该项目组选用了增量式模型来开发此系统。增量式模型的特点如下：可以避免一次性投资太多带来的风险，将主要的功能或者风险大的功能首先实现，然后逐步完善，保证

31、投入的有效性。可以更快地开发出可以操作的系统。可以减少开发过程中用户需求的变更。一些增量可能需要重新开发（如果早期开发的需求不稳定或者不完整） 。可见，增量式模型充分迎合了该项目的特点，并且提供了多种途径解决项目中的一些难题。该项目的生存期模型如下：生存期中各阶段的描述如下：阶段项目规划阶段目标根据合同和初步的需求分析，确定项目的规模、时间计划和资源需求输入合同文本，SOW过程项目规划，计划确认输出项目计划阶段需求分析阶段目标确定客户的需求输入项目计划，SOW过程需求获取，需求分析，需求控制输出原型系统，需求规格阶段设计阶段目标总体系统结构设计输入原型系统，需求规格过程总体设计输出系统设计说明

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

33、详细设计，编码，代码走查，代码评审，单元测试输出详细设计说明书，源代码，可运行版本-4阶段增量 5 实现目标实现系统的在线聊天功能输入系统设计说明书，数据库结构定义过程详细设计，编码，代码走查，代码评审，单元测试输出详细设计说明书，源代码，可运行版本-5阶段集成测试目标通过集成环境下的软件测试输入测试计划，测试用例过程集成测试，系统测试输出系统软件包，测试报告，产品说明书阶段产品提交目标产品可投入使用输入系统软件包过程产品提交输出验收报告9.项目管理对象项目管理对象9.1 阶段一：可行性研究阶段一：可行性研究管理任务：要有技术预言工作和项目规划工作，这个工作相当于整个项目的蓝图，给整个项目指明

34、了方向。质量保证任务：项目要达到什么目标，采用什么技术，开发方案，运营方案，开发时间，开发人员等等都需要做全面的考虑，以供领导者进行决策。基线产品：可行性研究报告，项目开发计划。9.2 阶段二：需求分析阶段二：需求分析管理任务：这个阶段了解项目的整体需求，可能需要某个领域的专家来进行透彻的需求分析。有了细致的需求分析，才能让整个项目的开发不至于走弯路。需求分析阶段在整个项目中占据非常重要的地位。需求分析结束后，就要把需求文档里的模块拆分成小的功能点。质量保证任务：需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认

35、识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。解决系统分析错误的方法通常采用邀请用户参与进行需求评定，然后对其用户的意见由质保成员跟踪检测是否纳入需求规格说明书，同时与用户签字确认形成需求基线，交由配置管理员放入配置管理库。 虽然尽早的邀请用户参与，仍然避免不了项目进行中用户的需求变更请求。对于开发过程存在的需求变动，我们要求用户填写变更申请单发送给项目配置管理员，在通过项目配置管理员转交质保小组，负

36、责组织专家小组和项目组成员一起讨论实施变更的可行性及实施后所带来的影响，小的变更则直接记录入变更记录原因分析项和风险项栏，大的变更则需要形成正式的变更报告，无论那种变更都需要对相应的文档实施同步变更（包括需求规格说明书、详细设计文、安装手册、操作手册等） 。但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期，这时，我们将变更报告提交给用户或邀请用户进行协调会议，讨论变更取舍问题或是项目进度变更问题。 决定变更之后，由项目经理组织实施变更，测试人员检测变更结果，而质保小组成员监督变更实施过程并协助配置管理员对变更后的成果物进行版本控制。变更实施完后，上线前还需要指定人员协助用户一同测试并

37、由用户签字后同意方可上线。 基线产品：软件需求说明书，数据要求说明书，测试计划书。9.3.阶段三：总体设计阶段三：总体设计管理任务：包括数据库设计和程序设计相结合。当然所有的设计都是围绕前面需求文档里提到的功能进行设计。做这个设计的一般是软件架构师，软件架构师不但懂业务，懂需求，更要懂得程序设计的关联性，预言性，前瞻性，扩展性等等特性。质量保证任务：优良的体系结构应当具备可扩展性和可配置性，而好的体系结构则需要好的设计方法，自然设计选型成为了系统设计首要的工作，究竟是采用哪种设计方法好呢？ 对于设计选型不能一概而论，需要针对项目的结构、项目的特征和用户的需求来分析，同样也要考虑到参与项目小组成

38、员的素质，如果其中大部分都没有从事过面向对象的设计且项目进对紧迫，这样没有多余的时间来培训小组成员来掌握面向对象的设计方法，尽管众所周知面向对象设计方法的优势，我们还是不如采用面向过程的方式（除用户指定开发设计方式外）可以减少项目承担的技术风险。 基线产品：总体设计说明书，数据库设计说明书，开发进度报表。9.4.阶段四：详细设计阶段四：详细设计管理任务：分模块的设计会让我们设计起来可以相对容易些，可以把关注的点放到模块上，但是需要设计人员有整体意识，全局意识，每个模块直接的关系都要搞的很清楚。数据库的设计要非常的详细，需要考虑到每个表的每个字段怎么应用，最重要的是各个表直接的关系，怎么处理，一

39、定要非常的详细，数据库设计的越详细越好，对后面的开发会越清晰，越少犯错误。质量保证任务：如小组成员在开发过程中对于新技术互相交流少，各自有各自的理解和想法，将造成理解上的不一致性，导致工作重复性高，滞后项目进度。建议解决方法是项目组成员采用集中办公，分块学习，学习的成果马上向项目相关人员发布，再由配置管理员对其发布的文档进行整理、归类放入配置库以供大家共享。这样方便大家的互相学习，减少重复的工作。在这次开发中从管理人员、设计人员到开发人员都汲取了很多教训，同时经过此次项目的开发，小组成员也积累了丰富的面向对象的开发经验。 除设计选型，还有一个容易被忽视的问题，就是公共类开发。公共类开发可以减少

40、工作中的重复工作，降低开发成本。这要求我们再设计阶段通过对用户需求的仔细研究，尽可能的识别出公共类，并进行定义指定专人负责设计通知其它设计人员，以减少重复工作。对于项目组提供的设计文档，由质保小组组织技术专家、项目组设计人员、开发人员和测试人员对其设计文档的评审，检测设计文档对其下一阶段工作的可行性，及时发现设计中可能存在的错误，降低项目开发风险，同时确保设计文档能为开发人员、测试人员提供切实的指导。对于可复用的设计进行提取作为公共库设计和开发，提供项目组或整个公司重用。最后交由配置管理员进行设计文档的版本控制。 基线产品：详细设计说明书，用户手册，操作手册，开发进度报表。9.5.阶段五：系统

41、实现阶段五：系统实现管理任务：编码的时候，需要考虑采用什么技术来处理。是采用框架还是用自己团队开发一个技术架构，需要项目的技术领导者进行探讨，并有必要对这些结构进行一些性能方面的测试。编码主要是把前面分析的功能点一一进行实现。质量保证任务：实现也就是代码的生产过程。这里不仅包括代码的产生，同时也包括测试用例的产生。针对上一阶段提供详细设计，程序员开始编码并且调试程序，测试人员则根据设计进行测试用例的设计，设计出来的用例需要得到项目组成员认可由项目经理审核通过才能进入配置库。同时程序员调试完程序提交测试人员进行程序正确性检测。 基线产品：模块开发卷宗，开发进度报表。9.6阶段六：测试阶段六：测试

42、管理任务：一个大型的项目必须经过功能测试和性能测试，两个测试阶段。功能测试主要针对项目的需求阶段设计出的需求文档进行测试。性能测试主要是对整个编码完成的项目进行性能方面的测试，测试整个项目是不是经得起高并发，高负载的影响。质量保证任务：需要很多轮的测试工作。需要及时生成测试分析报告，以达到岁项目整体的质量把握。基线产品：测试分析报告，开发进度报表，项目开发总结报告。9.7.阶段七：运行和维护阶段七：运行和维护管理任务：其实测试工作和运营可以同时进行，运营主要看这个项目需要什么样的运营方案进行支持。质量保证任务：维护小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从

43、项目中尽快的解脱出来以便投入到下一个项目的开发中。所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。 维护小组的人员基本上是按项目跟进的。当一个项目刚刚交付用户时，在维护小组有较多的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。基线产品：用户手册，操作手册，项目开

44、发总结，维护记录。9.8.贯穿于项目的文档管理贯穿于项目的文档管理此外，贯穿于整个项目开发过程之中的至关重要的项目管理对象是：文档管理。文档维护主要是配置管理小组的工作。文档从用途上分主要分为内部文档和外部文档。 内部文档包括： 项目开发计划； 需求分析； 体系结构设计说明； 详细设计说明； 构件索引； 构件成分说明； 构件接口及调用说明； 组件索引； 组件接口及调用说明； 类索引； 类属性及方法说明；测试报告； 测试统计报告； 质量监督报告； 源代码； 文档分类版本索引； 软件安装打包文件。 外部文档主要包括： 软件安装手册； 软件操作手册； 在线帮助； 系统性能指标报告； 系统操作索引。

45、如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项目的进度，这仍然是一个比较难解决的问题。解决此问题，其核心仍然是个度的问题。在本项目的开发中，配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。当有文档模板后需要书写文档的人员只剩下填空的工作，从某种意义上讲，书写文档的速度会加快。如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。 配置管理小组真正核心的工作是对文档的组织管理。根据文档的不同，文档

46、的来源也不同，有些是通过质量保证小组经过复审之后转交给配置管理小组，有些则会直接从文档的出处到达配置管理小组。文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。 从以往做大项目的经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，各个部门需要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发过程，才能使自己的开发向前推进。一个明显的例子就是系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确

47、性和高效性。 10项目风险管理项目风险管理10.1、项目风险管理的目的、项目风险管理的目的风险是指在项目进行过程中可能发生的事件，这些事件将会对项目按预期时间，资源和预算完成产生重大影响。风险管理的目标是在潜在问题发作以前就标志它们，这样就可以在生命周期中可以适时地计划和启用风险处理活动。10.2、项目风险管理的组成、项目风险管理的组成风险管理风险评估风险控制风险识别风险优先级风险分析风险管理计划风险化解风险监控10.3、风险的种类、风险的种类分清风险的种类有利于更好的对项目进行风险管理。10.3.1 资源风险10.3.1.1 组织对该项目是否有足够的支持（包括管理人员、测试员、QA 和其他外

48、部的相关各方） 。 这是否是该组织尝试过的最大项目。 软件工程是否有明确定义的流程？需求记录和管理。10.3.1.2 资金完成项目所需的资金是否到位。是否为培训和指导分配了资金。 是否有预算限制使得系统必须以固定的成本交付，否则将被取消。 成本估算是否准确10.3.1.3 人员是否可以获得足够的项目工作人员。 他们是否具备合适的技能和经验。 他们以前是否在一起工作过。他们是否相信项目会成功。 是否可以找到用户代表来担任复审员。 是否可以找到领域专家。 10.3.1.4 时间时间表制定得是否现实。 是否可以为了满足时间表而对功能进行规模管理。 对交付日期的要求有多严格。 是否有时间“把工作做好”

49、 。10.3.2 业务风险如果竞争对手抢先将产品推向市场怎么办。 如何确保有足够的资金。系统的预计价值是否大于预计成本？（考虑货币的时间价值和资金的成本） 。 如果无法同关键的供应商签定合同怎么办。10.3.3 技术风险10.3.3.1 规模风险成功是否能够被评测。是否有关于如何评测成功的协议。需求是否相当稳定并得到了充分的了解。项目规模是固定不变还是在不断扩展。项目开发的时间范围是否太短、不够灵活。10.3.3.2 技术风险技术是否已经过证明。重复使用目标是否合理。工件必须要使用一次后才能被重复使用。 构件可能要在若干次发布后才能变得稳定，以致无需重大变更即可复用。 需求中的事务量是否合理。

50、事务比率的估计值是否可靠？这些估计是否过于乐观。数据量是否合理？当前可用的框架是否能够保存这些数据，或者，如果需求使您相信工作站或部门系统将成为设计的一部分，那么是否能够在这些地方合理地保存数据。 是否有特殊或苛刻的技术需求。成功是否依赖于新的或未经试验的产品、服务或技术？是否依赖于新的或未被证明的硬件、软件或技术。对于与其他系统（包括企业以外的系统）的接口是否存在外部依赖性？是否存在必需的接口或必须创建它们 。是否存在极不灵活的可用性和安全性需求（例如“系统必须永远不出现故障” ） 。系统的用户是否对正在开发的系统类型没有经验。 应用程序的大小或复杂性，或者技术的新颖性是否导致了风险的增加。

51、是否存在对国家语言支持的需求。是否可能设计、实施和运行该系统？某些系统只由于太大或太复杂而无法正常工作。 10.3.3.3 外部依赖性风险该项目是否依赖于其他（平行的）开发项目。成功是否依赖于市售产品或外部开发的构件。成功是否依赖于开发工具（设计工具、编译器等）和实施技术（操作系统、数据库、进程间通信机制等）的成功集成。您是否有替代计划，可以在没有这些技术的情况下交付项目。10.3.4 进度风险功能是否无限追加。计划是否过于乐观。是否缺乏计划。在压力下是否放弃计划。是否追赶计划。10.4、定义风险参数、定义风险参数风险参数可用于评估、分类和划分风险的优先级；该项目将发生的可能性的等级划分为：非

52、常可能发生，可能发生，几乎不可能发生 3 个级别。将对项目的影响程度划分为：非常严重影响，严重影响，中等影响，微弱影响 4 个级别。相应的表格如下：发生的可能性对项目的影响程度名称等级名称等级非常可能发生3非常严重影响4可能发生2严重影响3几乎不可能发生2中等影响2微弱影响110.5、风险管理策略、风险管理策略有三种主要的策略：*风险规避：使其不再受到该风险的影响。 *风险转移：让其他方（客户、厂商、银行、其他主体等）承担该风险。*风险接受：决定将该风险当作意外事件来接受。监测风险征兆，并制定应急计划，以确定在风险发生时将采取何种行动。10.6、风险管理角色及职责、风险管理角色及职责（1）项目

53、经理项目经理对风险管理工作负全部责任。（2）项目组开发人员项目组开发人员将被要求作为项目风险分析组的成员，对项目工作中存在的风险进行分析，并整理成书面材料。（3）SQASQA 经理将定期对风险管理工作开展情况进行评审，确保所开展的风险管理工作符合组织的要求。10.7、个人微薄项目中风险的识别、个人微薄项目中风险的识别根据风险识别的分类标准可以识别出个人微薄项目中存在的风险，如下：资源风险完成该项目所需的资金受到一定的限制，人员的培训指导资金不到位，存在一定资金风险；参与项目的部分人员没有一起工作过，也存在着一定的人员风险；此外，交付日期的严格要求导致项目存在时间风险。业务风险由于软件行业的飞速

54、发展，竞争对手可能抢先将产品推向市场，故存在着业务风险。技术风险客户可能随时提出需求和对项目的改进，需求的不稳定性和项目规模的不断扩展，可能导致项目存在规模风险。进度风险功能的无限追加，在强大的压力下放弃计划都造成了项目的进度风险。10.8、风险的控制、风险的控制1控制方法（1）风险管理计划重点是制定一个计划，以处理在排位靠前的高风险项。风险管理计划每阶段/迭代重新评估一次。风险监控时选取风险管理计划中没有关闭的前 10 大风险进行监控即可。每阶段/迭代启动时，选取“风险管理计划”中处于“监控”状态的前 10 大风险，用于本阶段/迭代的周例会上进行跟踪和监控（注意：周例会时只监控阶段/迭代启动

55、时监控的前 10 大风险） 。（2）风险的化解避免风险（即：不要做冒险的活动）将风险从系统的一部分转移到另一部分（可能对于系统的其他部分此风险不会发生或发生时影响不大）购买关于风险的信息（例如：做实验性项目，请咨询专家等）消除风险的根源接受风险（如果风险后果较小，而处理它可能代价很大，滚动处理可能是最有效的途径）发布风险（将风险发布给相关涉众，如：管理者、市场人员、客户特别注意策略等）控制风险制定风险无法化解时的“风险应急计划”分配额外的资源来处理风险为处理风险留出额外的时间记住风险（为将来的项目积累）10.9 风险监控风险监控（1）周例会检查风险在周工作例会上，项目经理需要跟踪项目的风险。根

56、据风险列表，逐一分析前 10 大风险，确认已经风险状态是否“发生”或“关闭” ；如果风险发生则启动“风险应急计划”或项目组协商解决办法，必要时 PM请求相关高级管理者解决已发生的风险，并且 PM 负责在风险管理计划中将此条风险标示为“发生” 。如果风险已经消除，则 PM 负责在风险管理计划中将此条风险标示为“关闭”。统计每项风险的停留时间(周数)。10.10、微薄项目的风险管理、微薄项目的风险管理个人微薄项目的主要风险是开发人员对客户需求不是很熟悉，另外，客户要求的进度比较紧，而且具体需求不是很明确，客户可能随时提出需求和对项目的改进，需求的不稳定性和项目规模的不断扩展，可能导致项目存在规模风

57、险。功能的无限追加，在强大的压力下放弃计划都造成了项目的进度风险。下面的这个风险列表就是通过一系列的风险识别、风险评估、风险应对，等到的微薄项目的风险列表。排序输入风险事件可能性影响风险值风险应对措施1客户的SOW需求不明确，增加需求，导致需求蔓延3391采取加班的方法2修改计划去掉一些任务3与客户商量延长一些时间2WBS复杂模块的技术难关236对复杂模块进行外包3合同进度要求紧，合同金额有限236可以请一些实习的学生做辅助工作,一来成本不高,二来可以加快进度.4WBS供货商、外包商的质量问题133多选择几个可以作为备份的外包商和供应商5历史项目信息开发人员的流动1331注意项目团队的沟通，及

58、时了解开发人员的动态2控制好项目过程中的文档3.从其他的项目组借调人员4从外部招聘有过此类开发经验人员6规模成本估算项目的特殊性，成本估算不准确122让有类似项目经验的小组成员对成本估算审查7 质量计划软件达不到质量指标，软件性能欠缺122对每一个里程碑进行严格的质量审查8计划进度要求紧，时间紧迫133采取加班的方法可以请一些实习的学生做辅助工作11项目估算项目估算声明项目规模估算使用 Delphi 法进行估算，具体步骤如下：协调人向小组成员提供项目规格和估计表格；协调人召集小组讨论与规模相关的因素；小组成员匿名填写迭代表格；协调人整理出一个估计总结，以迭代表的形式返回各成员；协调人召集小组会

59、，讨论较大的估计差异；成员复查估计总结并在迭代表上提交另一个匿名估计；重复 4-6， 直到达到一个最低和最高估计的一致。附 Delphi 法规模估计迭代表。Delphi 法规模估计迭代表项目名称：估计日期：估计者：估计轮次：代码行（LOC）周期（月）工作量（人月）结果：费用（元）理由：项目规模估算经过小组内部讨论得出项目规模估算如下：项目名称：个人微薄系统规模预测： 代码行：15,000 LOC 周期：1 月 工作量：6 人月 费用：￥5530 元项目进度估算任务完成时间负责人资源备注需求讨论2010.6.15李鑫2 开发人员参与项目规划2010.6.18李鑫全体人员参与需求确定2010.6.

60、22李鑫全体人员参与设计2010.6.26黄金虎3 开发人员参与项目实施2010.7.9黄金虎全体人员参与有待细化测试2010.7.14宁珠3 开发人员参与部署2010.7.15张雪娇2 开发人员参与交付2010.7.20秦宇项目执行期间可根据实际完成情况申请延期。附延期申请表。项目名称：项目代号：项目所处阶段：第 阶段（ ）申请时间： 年 月 日原计划时间： 年 月 日申请延期至： 年 月 日申请延期的理由（逐条列出）：申请人签字：项目经理意见不同意延迟，理由：同意延迟至： 年 月 日签字：项目成本估算声明 由于涉及到的小组成员没有实际开发的经验，在薪酬结算方面没有可供参照的标准，因此在这里

61、采用统一的￥30.00 人天。成本估算任务名称工时成本估算个人微薄系统111 人天￥5530.00设备损耗31 工作日￥1000.00 需求讨论2*2 人天￥120.00 软件规划6*2 人天￥360.00 需求开发6*4 人天￥720.00 设计4*4 人天￥480.00 实施6*13 人天￥2340.00 测试3*5 人天￥450.00 部署2*1 人天￥60.0012 项目时间计划项目时间计划 12.1 序言序言 本计划以项目初期估算为蓝本，尽量实现所有成员在整个项目过程中都能得到相关技能的锻炼，根据现有成员的特点，制定了任务分配。若在计划执行过程中遇到不可控困难，可向项目经理提出申请延

62、期。项目开始前可根据个人意愿进行小幅度任务调整，申请人需填写任务申请表。计划开始后除极特别因素外，不予重新调整。 12.2 任务分解任务分解项目任务分解编码表编码任务名称备注R000 000需求讨论初步确定需求P000 000软件规划制定项目计划P100 000项目规划P200 000计划评审M000 000需求开发细化需求M100 000用户界面设计M200 000用户需求评审M300 000修改需求、界面M400 000编写需求说明M500 000需求验证D000 000设计完成项目设计工作D100 000概要设计D200 000数据库 ER 图编制、建库D300 000设计评审C000

63、000实施实际开发C100 000用户管理C100 100用户注册C100 200用户注销C100 300账号登陆C100 400个人信息管理C200 000文章管理C200 100写新文章C200 200删除文章C200 300编辑文章C200 400查看文章C300 000评论管理C300 100新建评论C300 200删除评论C300 300查看评论C300 310按文章查看评论C300 320按评论者查看评论C400 000界面实现C500 000整合T000 000测试对项目进行测试T100 000功能模块测试T200 000系统集成测试T300 000环境测设V000 000部署发

64、布并交付12.3 项目进度计划项目进度计划任务代码工期开始时间结束时间资源个人微薄系统31 工作日2010-6-152010-7-15 R000 0002 工作日2010-6-152010-6-16李鑫，黄金虎 P000 0002 工作日2010-6-172010-6-18全体开发人员 P100 0001 工作日2010-6-172010-6-17李鑫，黄金虎 P200 0001 工作日2010-6-182010-6-18李鑫，黄金虎，宁珠，张雪娇，秦宇，陆金 M000 0004 工作日2010-6-192010-6-22全体 M100 0001 工作日2010-6-192010-6-19宁珠

65、 M200 0001 工作日2010-6-192010-6-19秦宇，李鑫 M300 0001 工作日2010-6-202010-6-20黄金虎，宁珠 M400 0001 工作日2010-6-212010-6-21李鑫 M500 0001 工作日2010-6-222010-6-22陆金，张雪娇 D000 0004 工作日2010-6-232010-6-26黄金虎，陆金，秦宇，张雪娇 D100 0002 工作日2010-6-232010-6-24黄金虎，陆金 D200 0001 工作日2010-6-252010-6-25秦宇，张雪娇 D300 0001 工作日2010-6-262010-6-26

66、黄金虎，秦宇 C000 00013 工作日2010-6-272010-7-9李鑫，黄金虎，宁珠，张雪娇，秦宇，陆金 C100 0006 工作日2010-6-272010-7-2 C100 1004 工作日2010-6-272010-6-30秦宇，黄金虎，李鑫，陆金 C100 2002 工作日2010-7-12010-7-2秦宇 C100 3004 工作日2010-6-272010-6-30秦宇，黄金虎，李鑫，陆金 C100 4002 工作日2010-7-12010-7-2秦宇 C200 00011 工作日2010-6-272010-7-7 C200 1005 工作日2010-7-12010-7-5宁珠，陆金 C200 2005 工作日2010-7-12010-7-5宁珠，陆金 C200 3003 工作日2010-7-62010-7-8宁珠 C200 4003 工作日2010-6-272010-6-29宁珠 C300 0008 工作日2010-7-12010-7-8 C300 1005 工作日2010-7-12010-7-5黄金虎，李鑫 C300 2005 工作日2010-7-12010