第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〕跟踪需求变卦的形状。需求管理需求管理是为有效地控制和管理需求变卦等所进展的活动。需求管理的主要义务就是在开发人员在与提出更改的恳求者协商的根底上，评价需求变卦带来的潜在影响及其能够的本钱和费用，然后实施更改，以及有效地管理需求规格阐明书和跟踪更改需求的形状。确定需求变卦控制过程建立变卦控制委员会(SCCB)进展需求变卦影响分析跟踪一切受需求变卦影响的任务产品建立需求基准版本和需求控制版本文档维护需求变卦的历史记录跟踪每项需求的形状衡量需求稳定性管理和控制需求基线的过程需求变卦控制系统一个正式的文档，阐明如何控制需求变卦建立变卦审批系统需求变卦控制变卦恳求需求方开发方忽略选择变卦方式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(WorkBreakdownStructure)义务分解的过程：将一个工程分解为更多的任务细目或者子工程，使工程变得更小、更易管理、更易操作。义务分解的结果：WBS〔义务分解构造〕。WBS：面向可交付成果的。WBS实例系统子系统子系统子系统模块模块模块模块模块模块模块模块模块是面向可交付成果的对工程元素的分组，组织并定义了整个工程范围，不在WBS中的任务就不是该工程的任务是一个分级的树型构造，是对工程由粗到细的分解过程。任务构造每细分一个层次表示对工程元素更细致的描画WBS定义WBS的最低层次的可交付成果任务包该当由独一主体担任这一交付成果可以分配给另外一位工程经理进展方案和执行,或者经过子工程的方式完成Workpackages定义三、义务分解的类型图表类型“变化计数器〞系统版本比较找出增删行统计增删行统计总行标志修正记录修正预处置文件比较结果处置添加代码删除代码添加行数删除行数清单类型1.

变化计数器1.1

比较两个版本的程序1.1.1

预处置1.1.2

文件比较1.1.3结果处置1.2找出修正后的程序中添加和删除的代码行1.2.1找出添加的代码行1.2.2

找出删除的代码行1.3

统计修正后的程序中添加和删除的代码行数1.3.1统计添加代码行数1.3.2统计删除代码行数1.4统计总的代码行数1.5设定标志以指示修正的次数1.6在程序的头部添加修正纪录三、义务分解的方法参照具有类比性的工程(具有一样或类似的周期和任务细目要求)的WBS。类比模板运用运用领域内规范或半规范的WBS作为模板参考运用。与类比所参照的WBS不同，模板更具有笼统性，在义务分解时需根据指点阐明来开发工程的WBS。自上而下“变化计数器〞系统文件比较预处置添加代码结果处置统计总行标志修正记录修正版本比较找出增删行统计增删行删除代码添加行数删除行数自下而上“变化计数器〞系统文件比较预处置添加代码结果处置统计总行标志修正记录修正版本比较找出增删行统计增删行删除代码添加行数删除行数确认并分解工程的组成要素确定分解规范确定分解能否详细确定工程交付成果验证分解的正确性(建立编号)义务构造分解(WBS)步骤WBS编号系统系统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日WBS与OBS〔组织分解构造〕学生管理系统分解规范规划需求设计编码测试提交按照生存期分解：按照产品组成分解：1.1招生管理1.2分班管理1.3学生档案管理1.4学生成果管理分解规范要一致，不能同时运用两种规范进展分解最底层的要素能否是实现目的的充分必要条件最底层要素能否有反复的每个要素能否明晰完好定义最底层要素能否有定义明晰的责任人,能否可以进展本钱估算和进度安排检验分解结果的规范WBS分解的规模和数量因工程而异、因工程经理而异搜集与工程相关的一切信息参看一下类似的工程的WBS,与相关人员讨论可以参照模板最低层是可控的和可管理的，但是防止不用要的过细，最好不要超越7层，软件工程引荐分解到40小时的义务每个Workpackage必需有一个提交物定义义务完成的规范每个WBS必需有利于责任分配可以预备WBS的字典最后与相关人员进展评审WBS指南WBS字典内容WBS编号：名称：主题目标：描述：完成的任务：责任者：完成的标识：备注：提供了工程范围基线,是范围变卦的重要输入为评价和分配义务提供详细的任务包进展估算和编制工程进度的根底对整个工程胜利的集成和控制起到非常重要的作用WBS意义网管系统〔图表〕分解实例FF1配置管理F2缺点管理F3平安管理F4性能管理F3.2