《软件项目管理大作业20111632郑雯》由会员分享，可在线阅读，更多相关《软件项目管理大作业20111632郑雯（49页珍藏版）》请在金锄头文库上搜索。
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.3 PERT Chart (PERT 图)214.4活动时间估计244.5项目进度安排244.5工具使用265 质量计划275.1 质量计划编制27
2、5.2质量保证活动285.3产品审计295.4过程评审295.5测试计划296 配置计划306.1 配置管理人员组成306.2 配置控制306.3配置审核和审计317 风险计划317.1 风险识别,评估与风险规划327.2风险分析表327.3风险应对措施348 团队管理358.1软件团队管理概述35 8.2软件项目团队368.3沟通时间安排379 项目度量379.1 度量指标389.2 数据收集3810 集成项目3910.1项目集成计划3911 跟踪控制4011.1项目分析4011.2 阶段评审报告模板4112系统测试4212.1测试的目的与目标4212.2测试方法4212.3测试用例4312
3、.4测试结论4413 项目结束4413.1项目终止4413.2 收尾工作4513.3 最后评审4513.4 项目总结461 需求管理需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工作之间的可追踪性。1.1 需求管理的内容1.1.1 需求管理的特定实践需求管理包含5个特定实践，如图1所示。5.标识项目工作与需求的不一致性1.获得对需求的理解需求管理 4.维护对需求的双向可追溯性3.管理需求变更2.获取对需求的承诺
4、双向溯源矩阵 图1:需求实践示意图获得对需求的理解。在初步整理需求的基础上，项目小组和用户代表通过初步的分析讨论，对当前项目的需求达成共识，并在需求列表中作相应记录。获取需求承诺。通过项目参与者的书面承诺，建立各方或各项工作的基准。管理需求变更。维护变更历史，为调整与控制提供数据。在需求变更后维护对需求的双向可追溯性。从软件可维护性的角度提出管理要求。标识项目工作(包括计划和产品)与需求的不一致性。若发现不一致性，即启动纠正措施。1.1.2 需求管理的管理流程上述5个特定实践，可归结为以下3项活动，即需求确认、需求跟踪和需求变更。(1)需求确认包括图1中第1、2两个特定实践。由开发方和客户共同
5、对主要需求文档“软件需求规格说明书”进行评审，双方达成共识后作出书面承诺，使需求文档具有商业合同效力。由此可见，需求确认实际上包含了两个重要工作：需求评审和需求承诺。其中需求承诺是双方对通过正式评审后的“软件需求规格说明书”作出的共同承诺。承诺书的格式如下：本“软件需求规格说明书”是建立在双方对需求的共同理解基础之上的，我们同意后续的开发工作根据该“软件需求规格说明书”进行。如果需求发生变化，我们将按照“需求变更流程”执行，即需求的变更将导致双方重新协商成本、资源和进度等。 项目经理签字 : 客户或客户代表签字:该承诺书将附在“软件需求规格说明书”后，一同存档保存。(2)需求跟踪包括图1的第4
6、、5两个特定实践，即维护对需求的双向可追溯性和标识项目工作与需求的不一致性。为了有效地检验最终软件产品能否满足所有需求，对项目的需求要进行跟踪管理。跟踪的目的，是建立与维护“需求一设计一编程一测试”之间的一致性，确保所有工作成果都符合用户需求。为此可采用需求大纲中的需求跟踪矩阵，对每个需求追踪到实现该需求的设计、编码以及测试案例，从而验证该软件产品是否实现了所有需求，是否对所有需求进行过测试。1.2需求变更控制需求变更要进行控制，严格防止因失控而导致项目混乱，出现重大的风险。1.2.1需求变更的利弊随着项目的进展，用户和开发方对需求的了解越来越深入，原先的需求文档很可能存在错误或不足。另一方面
7、，市场会发生变化，原先的文档也可能跟不上当前的市场需求。可见需求变更总是不可避免的，有些是为了修正缺陷，有些属于增强功能。对项目开发小组而言，变更需求通常意味着要调整资源、重新分配任务，并修改前期的工作成果，有时要付出较大的代价。如果动不动就变更需求，某些项目也许永远不能按时完成。为此，需求变更必须遵守利大于弊的原则，并做到：为避免出现失控等风险，对纳入基线以前的需求文档，可通过正常的checkin和checkout进行更改。而纳入基线以后的需求文档，更需按照预定的变更控制规程，确保快速、顺利和有序地进行变更。遵照如图2所示的需求变更流程来处理。下文将具体介绍这一流程。开始需求变更申请书提交变
8、更申请书需求分析说明书书面化变更需求评估需要变更的影响变更审批审批通过? F根据变更修改相关工作产品 T变更验证需求评审结束 图2:需求变更流程1.2.2 需求变更的流程需求变更通常按变更申请一审批一更改一重新确认的流程进行。(1)变更申请此时的状态为“请求变更”。首先由申请人提交需求变更申请书，其内容应该包括：变更源类型。指引起变更的原因类型，可分为需求变更、设计变更、代码优化、用户文档优化和计划变更等。变更优先级。依据变更的重要性、紧迫性和对关键业务的影响程度和对系统安全性和稳定性的影响程度，可分为critical、high、middle和low等4级。变更标志。分为新增、修改和删除。变更
9、影响分析。包括变更影响的工作产品和负责人，对工作量和进度的影响，发生风险的可能性与影响程度，以及需要回测的范围。可能影响的工作产品。包括项目计划、需求文档、概要设计文档、详细设计文档、源代码和程序、测试计划和测试案例以及用户文档。上述申请书应由项目经理进行评估，其内容包括：该需求变更在技术上是否可行。对工期、成本、质量的影响。首先评估单个模块工期的影响，即实现该需求变更需要的成本和工作量；然后评估实现该需求变更对整体工期工作量和成本的影响。(2)变更审批按照影响的大小由不同的负责人审批。对影响小的变更，由项目经理直接审批。对影响大的变更，提交软件变更控制委员会(Sottware Change
10、Control Board，SCCB)审批。项目SCCB仍无法决定的变更，再提交高层SCCB决定。所谓影响大的变更一般包括下列情况：变更影响的模块数超过10个或超过50，或者可能影响软件系统的框架。变更会影响对客户的承诺。变更会带来“高”或者“高中”程度的风险。如果审批请求未通过，则该变更请求结束。(3)变更修改如果需求变更已审批通过，应指定相关的责任人对产品进行修改，并指定人员对更改后的产品进行审核。还应在产品列表中记录具体修改的产品名称、修改描述和是否完成修改的状态。包括：1.应及时更新相应的需求大纲和需求分析说明。2.如果影响项目计划的内容，修改项目计划，以反映需求的变更。3.如果影响到
11、概要设计文档、详细设计文档、源代码和程序、测试计划和测 试案例或者用户文档，它们也需要被及时更新。4.如果影响到测试，还需要进行回归测试。5.如果对文档进行修改，需在修改历史表格中注明修改人、修改时间以及修 改原因。6.如果对原文件修改过大，必要时项目经理可以重新组织工作产品的评审。7.如果对代码进行修改，需要导出编译申请表，通知编译和测试。(4)变更关闭如果修改后不需要进行测试，则当所有产品全部修改完成时，由最后完成修改的人关闭该变更。如果变更修改后提交测试，则由测试人员负责该变更是否最后关闭：1.如果测试未通过，则返回修改者继续修改。2.如果所有工作产品全部修改完成，并且测试通过，关闭该变
12、更。图3为需求变更的状态转换图，从中可看到各种需求变更状态的转换。新增变更请求 PM PM接受变更 拒绝变更变更关闭 图3:需求变更状态转换图1.2.3 需求变更的数据项为了确切记录需求变化，还需登记如表1所示的变更数据列表。数据项名称定义项目名称和ID变更所在项目的名称和ID 变更阶段需求阶段，设计阶段，编码，测试和验收阶段。不同阶段的需求变更请求对整个项目开发的影响也不同变更优先级每个变更的相对重要性变更标志变更的状态变更原因描述简单描述提出变更的原因变更内容描述对变更的内容进行简单描述相关的变更请求是否有相关的变更请求，如果有，指定相关的变更请求变更的状态信息包括变更请求人，更变批准人，
13、当前负责人，变更关闭人，请求日期，审批日期，期望解决日期以及关闭日期变更影响分析基于影响工作产品对变更的影响进行分析变更处理分析所影响的工作产品列表以及各工作产品对变更的处理状态表11.3 需求管理工具 在软件规模很小的时候，人们采用文档文件的方式来存储软件需求规格说明书和其他文档。在一些小规模的软件系统开发中，人们也还这样做。但是，随着各种计算机应用系统越来越复杂，软件规模也越来越庞大。这时传统的基于文档文件存储需求的方式越来越显露出它的局限性，主要体现在：1.手工维护大量文档文件十分困难。2.很难保持文档与现实的一致。3.通知受变更影响的设计人员是手工过程。4.不太容易做到为每一个需求保存附加的信息。5.很难在功能需求与相
