第2章 软件项目范围计划

第2章范围计划软件需求管理任务分解定义任务分解的类型任务分解的过程案例分析范围计划进度计划成本计划——成本基准，进度基准需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。业务需求用户需求功能需求系统需求非功能性需求质量特性约束和假设软件需求规格No.Top10FactorsAVG1Inadequaterequirementsspecification4.52Changesinrequirements4.33Shortageofsystemsengineers4.24Shortageofsoftwaremanagers4.15Shortageofqualifiedprojectmanagers4.16Shortageofsoftwareengineers3.97Fixed-pricecontract3.88Inadequatecommunicationsforsystemintegration3.89Insufficientexperienceasteam3.610Shortageofapplicationdomainexperts3.6Scale:5=VerySerious3=Serious1=NoSeriousSource:Carnegie-MellonUniversity,SoftwareEngineeringInstitute需求工程是指应用工程化的方法、技术和规格来开发和管理软件的需求。需求工程的目标是获取高质量的软件需求。以系统化、条理化、可重复的方法和技术进行与需求相关的活动，从而提高需求活动和过程的可管理性，降低需求开发和管理的成本。需求工程分为需求开发和需求管理。需求工程需求管理需求开发需求获取需求分析需求规格说明需求验证变更管理需求获取阶段的任务可能是软件开发中最困难、最关键、最易出错和最需要交流的活动。用户要求扩展需求基线需求软件需求目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、软硬件环境、现有运行系统等具体情况和客观信息。确定需求计划确定项目范围确定调查对象收集用户需求确定非功能性需求和约束条件需求获取需要从用户提供的大量信息中分析和理解用户的真正需求(做什么)，而应剔除实现方式(怎么做)。需求分析是为最终用户所看到的系统建立一个概念模型(逻辑模型)，是对需求系统地抽象描述。需求分析的基本任务是分析和综合已收集到的信息，在于透过现象看本质，找出需求信息之间的内在联系和可能的矛盾，提炼、分析和仔细审查已收集到的需求信息，找出真正系统的需求，以确保项目相关人员对需求都有唯一的理解。需求分析建立的逻辑模型反应的是业务运作流程，而不是技术开发流程。当前系统物理模型逻辑模型目标系统物理模型逻辑模型模型化抽象化例化具体化导出理解需求表达需求需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。需求规格说明书是需求工程的最终输出，以文档的形式确定用户需求和逻辑模型。1）需求规格是软件设计和实现的基础；2）需求规格是测试和验收的重要依据；3）需求规格为软件维护提供重要信心。1）正确性：所有需求规格的说明应在开发中满足；2）一致性：信息在需求规格描述一致，不发生矛盾；3）功能性：从实现中分离功能，即描述要“做什么”而不是“怎样实现”；4）规范性：采用一定的规格说明语言，无二义性；5）完整性：如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中；6）可行性：规格说明应该包括系统运行环境；7）抽象性：规格说明应该是一个认识模型；8）开放型：规格说明应该容许不完备性并允许扩充。1.引言2.5设计限制1.1目的2.6假设和依赖1.2文档约定3.需求规格1.3预期读者3.1功能需求1.4产品范围3.2逻辑模型1.5参考文献3.3数据字典2.项目概述3.4性能需求2.1项目背景3.5安全性需求2.2项目目标3.6接口需求2.3用户类3.7其他需求2.4运行环境附录需求是正确的吗？需求是一致的吗？需求是完全的吗？需求是实际可行的吗？需求是必要的吗？需求是可检验的吗？需求是可跟踪的吗？最后的签字1）控制对需求规格基准的变动；2）保持项目计划与需求的一致；3）控制单个需求的更改；4）管理需求、需求之间的联系以及需求与设计的关系；5）跟踪需求变更的状态。需求管理是为有效地控制和管理需求变更等所进行的活动。需求管理的主要任务就是在开发人员在与提出更改的请求者协商的基础上，评估需求变更带来的潜在影响及其可能的成本和费用，然后实施更改，以及有效地管理需求规格说明书和跟踪更改需求的状态。1.确定需求变更控制过程2.建立变更控制委员会(SCCB)3.进行需求变更影响分析4.跟踪所有受需求变更影响的工作产品5.建立需求基准版本和需求控制版本文档6.维护需求变更的历史记录7.跟踪每项需求的状态8.衡量需求稳定性9.管理和控制需求基线的过程10.需求变更控制系统一个正式的文档，说明如何控制需求变更建立变更审批系统变更申请需求方开发方忽略选择变更方式SCCB评估项目经理自行决定评估结果拒绝接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划软件基线产品修改申请单申请人张三申请日期2010-03-24项目名称软件项目管理系统阶段名称系统设计文件名称RCR-PM-01.doc,RCR-PM-02.doc修改内容1）修改测试流程控制：将2个角色，3个渠道流，改为3个角色，4个渠道流，详见RCR-PM-01.doc2）增加开发人员技能信息库管理，详见RCR-PM-02.doc验证意见同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更可以推迟到下一个版本实施验证人李四验证日期2010-03-30SCCB李四，王五，赵六填表人张三需求跟踪是指编制每个需求与系统元素之间的联系(可跟踪信息)的文档，其中系统元素包括：其他需求、体系结构、设计部件、测试文档等。可跟踪信息分类：需求-源可跟踪性：与说明该需求的人或文档连接；需求-理由可跟踪性：和理由描述连接；需求-需求可跟踪性：和依赖于该需求的需求连接；需求-体系结构可跟踪性：与实现系统连接；需求-设计可跟踪性：与特定组件连接；需求-界面可跟踪性：与外部系统界面连接。Workpackages：WBS的最低层次的可交付成果任务分解的过程：将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。任务分解的结果：WBS（任务分解结构）。WBS：面向可交付成果的。系统子系统子系统子系统模块模块模块模块模块模块模块模块模块是面向可交付成果的对项目元素的分组，组织并定义了整个项目范围，不在WBS中的工作就不是该项目的工作是一个分级的树型结构，是对项目由粗到细的分解过程。工作结构每细分一个层次表示对项目元素更细致的描述WBS的最低层次的可交付成果工作包应当由唯一主体负责这一交付成果可以分配给另外一位项目经理进行计划和执行,或者通过子项目的方式完成“变化计数器”系统版本比较找出增删行统计增删行统计总行标记修改记录修改预处理文件比较结果处理增加代码删除代码增加行数删除行数参照具有类比性的项目(具有相同或相似的周期和工作细目要求)的WBS。使用应用领域内标准或半标准的WBS作为模板参考使用。与类比所参照的WBS不同，模板更具有抽象性，在任务分解时需根据指导说明来开发项目的WBS。“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数1.确认并分解项目的组成要素2.确定分解标准3.确定分解是否详细4.确定项目交付成果5.验证分解的正确性(建立编号)系统1子系统2子系统3子系统1.2模块1.3模块1.1模块2.2模块3.3模块2.1模块2.3模块3.1模块3.2模块WBS任务名称工期开始时间完成时间1项目计划6工作日2010年3月8日2010年3月13日2软件开发44工作日2010年3月15日2010年5月8日2.1需求分析6工作日2010年3月15日2010年3月20日2.2总体设计9工作日2010年3月22日2010年3月31日2.3详细设计9工作日2010年4月1日2010年4月13日2.4应用程序编码18工作日2010年4月14日2010年5月6日2.5驱动程序编码30工作日2010年3月29日2010年5月6日2.6软件测试18工作日2010年4月14日2010年5月6日2.7软件审核2工作日2010年5月7日2010年5月8日3机构设计7工作日2010年3月18日2010年3月25日4硬件设计49工作日2010年3月15日2010年5月14日4.1硬件前期工作12工作日2010年3月15日2010年3月27日4.2原理图6工作日2010年3月15日2010年3月20日4.2.1原理图设计5工作日2010年3月15日2010年3月19日4.2.2原理图审核1个工作日2010年3月20日2010年3月20日4.3PCB21工作日2010年3月26日2010年4月21日4.3.1PCB画图和封装10工作日2010年3月29日2010年4月10日4.3.2PCB与机构沟通10工作日2010年3月26日2010年4月8日4.3.3BOM表4工作日2010年3月29日2010年4月1日4.3.4BOM器件采购12工作日2010年4月2日2010年4月17日4.3.5PCB制版采购7工作日2010年4月14日2010年4月21日4.4电路板制作10工作日2010年4月22日2010年5月5日4.4.1SMT5工作日2010年4月22日2010年4月27日4.4.2电路板焊接4工作日2010年4月28日2010年5月4日4.4.3电路板测试1个工作日2010年5月5日2010年5月5日4.5软硬件集成4工作日2010年5月10日2010年5月13日4.6产品初期验收1个工作日2010年5月14日2010年5月14日学生管理系统规划需求设计编码测试提交按照生存期分解：按照产品组成分解：1.1招生管理1.2分班管理1.3学生档案管理1.4学生成绩管理分解标准要统一，不能同时使用两种标准进行分解1.最底层的要素是否是实现目标的充分必要条件2.最底层要素是否有重复的3.每个要素是否清晰完整定义4.最底层要素是否有定义清晰的责任人,是否可以进行成本估算和进度安排1.WBS分解的规模和数量因项目而异、因项目经理而异2.收集与项目相关的所有信息3.参看一下类似的项目的WBS,与相关人员讨论4.可以参照模板5.最低层是可控的和可管理的，但是避免不必要的过细，最好不要超过7层，6.软件项目推荐分解到40小时的任务7.每个Workpackage必须有一个提交物8.定义任务完成的标准9.每个WBS必须有利于责任分配10.可以准备WBS的字典11.最后与相关人员进行评审WBS编号：名称：主题目标：描述：完成的任务：责任者：完成的标识：备注：提供了项目范围基线,是范围变更的重要输入为评估和分配任务提供具体的工作包进行估算和编制项目进度的基础对整个项目成功的集成和控制起到非常重要的作用FF1配置管理F2故障管理F3安全管理F4性能管理F3.2F3.3F3.1F3.4F4.2F4.3F4.5F4.6F4.7F4.4F4.1F4.7.1F4.7.2标识项模块说明F1.1获取网络资源数据F1.2将资源数据存入数据库F1.3获取网络资源信息F1.4观察网络资源F1.4.1依类型分类观察网络资源F1.4.2依状态分类观察网络资源F1.5观察逻辑网F1.6观察资源状态F1.7修改网络资源的状态F1.8依条件检验网络使用情