软件项目管理大作业20111632郑雯.doc

《软件项目管理大作业20111632郑雯.doc》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、在线书店管理系统软件项目管理方案学号：班级：计软111班姓名：郑雯指导教师：韦灵完成时间：2014年6月20日1需求管理11.1需求管理的内容11.1.1需求管理的特定实践11.1.2需求管理的管理流程11.2需求变更控制21.3需求管理工具61.4需求规格72任务分解92.1任务负责与分配102.2项目范围管理113规模估算163.1成本估算164项目进度194.1定义活动194.2活动排序204.3PERTChart(PERT图)214.4活动时间估计244.5项目进度安排244.5工具使用265质量计划275.1质量计划编制275.2质量保

2、证活动285.3产品审计295.4过程评审295.5测试计划296配置计划306.1配置管理人员组成306.2配置控制306.3配置审核和审计317风险计划317.1风险识别,评估与风险规划327.2风险分析表327.3风险应对措施348团队管理358.1软件团队管理概述358.2软件项目团队368.3沟通时间安排379项目度量379.1度量指标389.2数据收集3810集成项目3910.1项目集成计划3911跟踪控制4011.1项目分析4011.2阶段评审报告模板4112系统测试4212.1测试的目的与目标4212.2测试方法4212.3测试用

3、例4312.4测试结论4413项目结束4413.1项目终止4413.2收尾工作4513.3最后评审4513.4项目总结461需求管理需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工作之间的可追踪性。1.1需求管理的内容1.1.1需求管理的特定实践需求管理包含5个特定实践，如图1所示。5.标识项目工作与需求的不一致性1.获得对需求的理解需求管理4.维护对需求的双向可

4、追溯性3.管理需求变更2.获取对需求的承诺双向溯源矩阵图1:需求实践示意图①获得对需求的理解。在初步整理需求的基础上，项目小组和用户代表通过初步的分析讨论，对当前项目的需求达成共识，并在需求列表中作相应记录。②获取需求承诺。通过项目参与者的书面承诺，建立各方或各项工作的基准。③管理需求变更。维护变更历史，为调整与控制提供数据。④在需求变更后维护对需求的双向可追溯性。从软件可维护性的角度提出管理要求。⑤标识项目工作(包括计划和产品)与需求的不一致性。若发现不一致性，即启动纠正措施。1.1.2需求管理的管理流程　上述5个特定实践，可归结为以下3项活动

5、，即需求确认、需求跟踪和需求变更。　　(1)需求确认包括图1中第1、2两个特定实践。由开发方和客户共同对主要需求文档“软件需求规格说明书”进行评审，双方达成共识后作出书面承诺，使需求文档具有商业合同效力。由此可见，需求确认实际上包含了两个重要工作：需求评审和需求承诺。其中需求承诺是双方对通过正式评审后的“软件需求规格说明书”作出的共同承诺。承诺书的格式如下：本“软件需求规格说明书”是建立在双方对需求的共同理解基础之上的，我们同意后续的开发工作根据该“软件需求规格说明书”进行。如果需求发生变化，我们将按照“需求变更流程”执行，即需求的变更将导致双方

6、重新协商成本、[[资源]]和进度等。项目经理签字:　　　[[客户]]或客户代表签字:该承诺书将附在“软件需求规格说明书”后，一同存档保存。(2)需求跟踪包括图1的第4、5两个特定实践，即维护对需求的双向可追溯性和标识项目工作与需求的不一致性。为了有效地检验最终软件产品能否满足所有需求，对项目的需求要进行跟踪管理。跟踪的目的，是建立与维护“需求一设计一编程一测试”之间的一致性，确保所有工作成果都符合用户需求。为此可采用需求大纲中的需求跟踪矩阵，对每个需求追踪到实现该需求的设计、编码以及测试案例，从而验证该软件产品是否实现了所有需求，是否对所有需求进

7、行过测试。1.2需求变更控制需求变更要进行控制，严格防止因失控而导致项目混乱，出现重大的风险。1.2.1需求变更的利弊　　随着项目的进展，用户和开发方对需求的了解越来越深入，原先的需求文档很可能存在错误或不足。另一方面，市场会发生变化，原先的文档也可能跟不上当前的市场需求。可见需求变更总是不可避免的，有些是为了修正缺陷，有些属于增强功能。　　对项目开发小组而言，变更需求通常意味着要调整资源、重新分配任务，并修改前期的工作成果，有时要付出较大的代价。如果动不动就变更需求，某些项目也许永远不能按时完成。为此，需求变更必须遵守利大于弊的原则，并做到：　

8、　①为避免出现失控等风险，对纳入基线以前的需求文档，可通过正常的check—in和check—out进行更改。而纳入基线以后的需求文档，