软件项目范围计划课件

第二篇项目计划第2章范围计划软件需求管理任务分解定义任务分解的类型任务分解的过程案例分析第二篇项目计划第2章范围计划软件需求管理范围计划进度计划成本计划核心三计划——成本基准，进度基准一、软件需求管理软件需求需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。范围计划核心三计划——成本基准，进度基准一、软件需求管理软软件需求的层次业务需求用户需求功能需求系统需求非功能性需求质量特性约束和假设软件需求规格软件需求的层次业务需求用户需求功能需求系统需求非功能性需求质需求管理的重要性需求管理的重要性项目失败的原因分析No.Top10FactorsAVG1Inadequaterequirementsspecification4.52Changesinrequirements4.33Shortageofsystemsengineers4.24Shortageofsoftwaremanagers4.15Shortageofqualifiedprojectmanagers4.16Shortageofsoftwareengineers3.97Fixed

-pricecontract3.88Inadequatecommunicationsforsystemintegration3.89Insufficientexperienceasteam3.610Shortageofapplicationdomainexperts3.6Scale:5=VerySerious3=Serious1=NoSeriousSource:Carnegie-MellonUniversity,SoftwareEngineeringInstitute项目失败的原因分析No.Top10FactorsAVG1需求工程是指应用工程化的方法、技术和规格来开发和管理软件的需求。需求工程需求工程的目标是获取高质量的软件需求。以系统化、条理化、可重复的方法和技术进行与需求相关的活动，从而提高需求活动和过程的可管理性，降低需求开发和管理的成本。需求工程分为需求开发和需求管理。需求工程是指应用工程化的方法、技术和规格来开发和管理软件的需需求工程需求管理需求开发需求获取需求分析需求规格说明需求验证变更管理需求工程过程需求工程需求管理需求开发需求获取需求分析需求规格说明需求验证需求获取阶段的任务可能是软件开发中最困难、最关键、最易出错和最需要交流的活动。需求获取用户要求

扩展需求基线需求软件需求目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、软硬件环境、现有运行系统等具体情况和客观信息。需求获取阶段的任务可能是软件开发中最困难、最关键、最易出错和需求获取过程确定需求计划确定项目范围确定调查对象收集用户需求确定非功能性需求和约束条件需求获取需要从用户提供的大量信息中分析和理解用户的真正需求(做什么)，而应剔除实现方式(怎么做)。需求获取过程确定需求计划确定项目范围确定调查对象收集用户需求需求分析需求分析是为最终用户所看到的系统建立一个概念模型(逻辑模型)，是对需求系统地抽象描述。需求分析的基本任务是分析和综合已收集到的信息，在于透过现象看本质，找出需求信息之间的内在联系和可能的矛盾，提炼、分析和仔细审查已收集到的需求信息，找出真正系统的需求，以确保项目相关人员对需求都有唯一的理解。需求分析建立的逻辑模型反应的是业务运作流程，而不是技术开发流程。需求分析需求分析是为最终用户所看到的系统建立一个概念模型(逻需求分析模型当前系统物理模型逻辑模型目标系统物理模型逻辑模型模型化抽象化例化具体化导出理解需求表达需求需求分析模型当前系统物理模型逻辑模型目标系统物理模型逻辑模型需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。需求规格需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。需求规格说明书是需求工程的最终输出，以文档的形式确定用户需求和逻辑模型。1）需求规格是软件设计和实现的基础；2）需求规格是测试和验收的重要依据；3）需求规格为软件维护提供重要信心。需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求1）正确性：所有需求规格的说明应在开发中满足；2）一致性：信息在需求规格描述一致，不发生矛盾；3）功能性：从实现中分离功能，即描述要“做什么”而不是“怎样实现”；4）规范性：采用一定的规格说明语言，无二义性；5）完整性：如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中；6）可行性：规格说明应该包括系统运行环境；7）抽象性：规格说明应该是一个认识模型；8）开放型：规格说明应该容许不完备性并允许扩充。软件需求规格的原则1）正确性：所有需求规格的说明应在开发中满足；软件需求规格的规格文档参考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.5设计限制1.1目的2.6需求是正确的吗？需求是一致的吗？需求是完全的吗？需求是实际可行的吗？需求是必要的吗？需求是可检验的吗？需求是可跟踪的吗？最后的签字需求验证需求是正确的吗？需求验证1）控制对需求规格基准的变动；2）保持项目计划与需求的一致；3）控制单个需求的更改；4）管理需求、需求之间的联系以及需求与设计的关系；5）跟踪需求变更的状态。需求管理需求管理是为有效地控制和管理需求变更等所进行的活动。需求管理的主要任务就是在开发人员在与提出更改的请求者协商的基础上，评估需求变更带来的潜在影响及其可能的成本和费用，然后实施更改，以及有效地管理需求规格说明书和跟踪更改需求的状态。1）控制对需求规格基准的变动；需求管理需求管理是为有效地控制确定需求变更控制过程建立变更控制委员会(SCCB)进行需求变更影响分析跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性管理和控制需求基线的过程需求变更控制系统一个正式的文档，说明如何控制需求变更建立变更审批系统需求变更控制确定需求变更控制过程需求变更控制变更申请需求方开发方忽略选择变更方式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李四，王五，赵六填表人张三软件基线产品修改申请单申请人张三申请日期2010-03-24需求跟踪是指编制每个需求与系统元素之间的联系(可跟踪信息)的文档，其中系统元素包括：其他需求、体系结构、设计部件、测试文档等。需求跟踪可跟踪信息分类：需求-源可跟踪性：与说明该需求的人或文档连接；需求-理由可跟踪性：和理由描述连接；需求-需求可跟踪性：和依赖于该需求的需求连接；需求-体系结构可跟踪性：与实现系统连接；需求-设计可跟踪性：与特定组件连接；需求-界面可跟踪性：与外部系统界面连接。需求跟踪是指编制每个需求与系统元素之间的联系(可跟踪信息)的二、任务分解定义Workpackages：WBS的最低层次的可交付成果WBS(WorkBreakdownStructure)任务分解的过程：将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。任务分解的结果：WBS（任务分解结构）。WBS：面向可交付成果的。二、任务分解定义Workpackages：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

在程序的头部增加修改纪录清单类型1.

变化计数器三、任务分解的方法参照具有类比性的项目(具有相同或相似的周期和工作细目要求)的WBS。类比模板使用应用领域内标准或半标准的WBS作为模板参考使用。与类比所参照的WBS不同，模板更具有抽象性，在任务分解时需根据指导说明来开发项目的WBS。三、任务分解的方法参照具有类比性的项目(具有相同或相似的周期第2章软件项目范围计划自上而下“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数自上而下“变化计数器”系统文件比较预处理增加代码结果处理统计自下而上“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数自下而上“变化计数器”系统文件比较预处理增加代码结果处理统计确认并分解项目的组成要素确定分解标准确定分解是否详细确定项目交付成果验证分解的正确性(建立编号)任务结构分解(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子系统2子系统3子系统1.2模块1.3WBS任务名称工期开始时间完成时间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任务名称工期开始时间完成时间1项目计划6工作日201WBS与OBS（组织分解结构）WBS与OBS（组织分解结构）学生管理系统分解标准规划需求设计编码测试提交按照生存期分解：按照产品组成分解：1.1招生管理1.2分班管理1.3学生档案管理1.4学生成绩管理分解标准要统一，不能同时使用两种标准进行分解学生管理系统分解标准规划按照生存期分解：按照产品组成分解：1最底层的要素是否是实现目标的充分必要条件最底层要素是否有重复的每个要素是否清晰完整定义最底层要素是否有定义清晰的责任人,是否可以进行成本估算和进度安排检验分解结果的标准最底层的要素是否是实现目标的充分必要条件检验分解结果的标准WBS分解的规模和数量因项目而异、因项目经理而异收集与项目相关的所有信息参看一下类似的项目的WBS,与相关人员讨论可以参照模板最低层是可控的和可管理的，但是避免不必要的过细，最好不要超过7层，软件项目推荐分解到40小时的任务每个Workpackage必须有一个提交物定义任务完成的标准每个WBS必须有利于责任分配可以准备WBS的字典最后与相关人员进行评审WBS指南WBS分解的规模和数量因项目而异、因项目经理而异WBS指南WBS字典内容WBS编号：名称：主题目标：描述：完成的任务：责任者：完成的标识：备注：WBS字典内容WBS编号：名称：主题目标：描述：完成的任务：提供了项目范围基线,是范围变更的重要输入为评估和分配任务提供具体的工作包进行估算和编制项目进度的基础对整个项目成功的集成和控制起到非常重要的作用WBS意义提供了项目范围基线,是范围变更的重要输入WBS意义网管系统（图表）分解实例FF1配置管理F2故障管理F3安全管理F4性能管理F3.2F3.3F3.1F3.4F4.2F4.3F4.5F4.6F4.7F4.4F4.1F4.7.1F4.7.2网管系统（图表）分解实例FF1F2F3F4F3.2F3.3F标识项模块说明F1.1获取网络资源数据F1.2将资源数据存入数据库F1.3获取网络资源信息F1.4观察网络资源F1.4.1依类型分类观察网络资源F1.4.2依状态分类观察网络资源F1.5观察逻辑网F1.6观察资源状态F1.7修改网络资源的状态F1.8依条件检验网络使用情况F1.9显示拓扑图F1.10建立通道标识项模块说明F1.1获取网络资源数据F1.2将资源数据存入GeorgeandMartha计划与家人和朋友举行一次特殊的野餐活动,以庆祝Martha的升职和他们35周年的结婚纪念.Martha是工程师,George是会计.他们有两个非常活泼的确孩子,Mary13岁,Thomas17岁.经过过去几年的发展,家里不断壮大,无论是时间和金钱上的需要都在增加,所以他们已经逐渐成为非常好的计划能手,最近他们又通过了PMP的认证考试,所以他们非常清楚对于这样野餐活动也需要开发一个WBS.WBS实例GeorgeandMartha一次野餐会GeorgeandMartha计划与家人和朋友举行一次特序号任务持续时间工作人员1开始02做冰茶15George3准备三明治10Martha4准备水果2Martha5准备篮子2Martha6收拾毛毯2George7收拾运动服3Martha8装车4George9加油6George10开车去野餐营地20Martha11结束0序号任务持续时间工作人员1开始02做冰茶15George3准需求确认需求变更控制WBS四、案例分析“校务通系统”项目任务分解需求确认四、案例分析“校务通系统”项目任务分解第二篇项目计划第2章范围计划软件需求管理任务分解定义任务分解的类型任务分解的过程案例分析第二篇项目计划第2章范围计划软件需求管理范围计划进度计划成本计划核心三计划——成本基准，进度基准一、软件需求管理软件需求需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。范围计划核心三计划——成本基准，进度基准一、软件需求管理软软件需求的层次业务需求用户需求功能需求系统需求非功能性需求质量特性约束和假设软件需求规格软件需求的层次业务需求用户需求功能需求系统需求非功能性需求质需求管理的重要性需求管理的重要性项目失败的原因分析No.Top10FactorsAVG1Inadequaterequirementsspecification4.52Changesinrequirements4.33Shortageofsystemsengineers4.24Shortageofsoftwaremanagers4.15Shortageofqualifiedprojectmanagers4.16Shortageofsoftwareengineers3.97Fixed

-pricecontract3.88Inadequatecommunicationsforsystemintegration3.89Insufficientexperienceasteam3.610Shortageofapplicationdomainexperts3.6Scale:5=VerySerious3=Serious1=NoSeriousSource:Carnegie-MellonUniversity,SoftwareEngineeringInstitute项目失败的原因分析No.Top10FactorsAVG1需求工程是指应用工程化的方法、技术和规格来开发和管理软件的需求。需求工程需求工程的目标是获取高质量的软件需求。以系统化、条理化、可重复的方法和技术进行与需求相关的活动，从而提高需求活动和过程的可管理性，降低需求开发和管理的成本。需求工程分为需求开发和需求管理。需求工程是指应用工程化的方法、技术和规格来开发和管理软件的需需求工程需求管理需求开发需求获取需求分析需求规格说明需求验证变更管理需求工程过程需求工程需求管理需求开发需求获取需求分析需求规格说明需求验证需求获取阶段的任务可能是软件开发中最困难、最关键、最易出错和最需要交流的活动。需求获取用户要求

扩展需求基线需求软件需求目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、软硬件环境、现有运行系统等具体情况和客观信息。需求获取阶段的任务可能是软件开发中最困难、最关键、最易出错和需求获取过程确定需求计划确定项目范围确定调查对象收集用户需求确定非功能性需求和约束条件需求获取需要从用户提供的大量信息中分析和理解用户的真正需求(做什么)，而应剔除实现方式(怎么做)。需求获取过程确定需求计划确定项目范围确定调查对象收集用户需求需求分析需求分析是为最终用户所看到的系统建立一个概念模型(逻辑模型)，是对需求系统地抽象描述。需求分析的基本任务是分析和综合已收集到的信息，在于透过现象看本质，找出需求信息之间的内在联系和可能的矛盾，提炼、分析和仔细审查已收集到的需求信息，找出真正系统的需求，以确保项目相关人员对需求都有唯一的理解。需求分析建立的逻辑模型反应的是业务运作流程，而不是技术开发流程。需求分析需求分析是为最终用户所看到的系统建立一个概念模型(逻需求分析模型当前系统物理模型逻辑模型目标系统物理模型逻辑模型模型化抽象化例化具体化导出理解需求表达需求需求分析模型当前系统物理模型逻辑模型目标系统物理模型逻辑模型需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。需求规格需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。需求规格说明书是需求工程的最终输出，以文档的形式确定用户需求和逻辑模型。1）需求规格是软件设计和实现的基础；2）需求规格是测试和验收的重要依据；3）需求规格为软件维护提供重要信心。需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求1）正确性：所有需求规格的说明应在开发中满足；2）一致性：信息在需求规格描述一致，不发生矛盾；3）功能性：从实现中分离功能，即描述要“做什么”而不是“怎样实现”；4）规范性：采用一定的规格说明语言，无二义性；5）完整性：如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中；6）可行性：规格说明应该包括系统运行环境；7）抽象性：规格说明应该是一个认识模型；8）开放型：规格说明应该容许不完备性并允许扩充。软件需求规格的原则1）正确性：所有需求规格的说明应在开发中满足；软件需求规格的规格文档参考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.5设计限制1.1目的2.6需求是正确的吗？需求是一致的吗？需求是完全的吗？需求是实际可行的吗？需求是必要的吗？需求是可检验的吗？需求是可跟踪的吗？最后的签字需求验证需求是正确的吗？需求验证1）控制对需求规格基准的变动；2）保持项目计划与需求的一致；3）控制单个需求的更改；4）管理需求、需求之间的联系以及需求与设计的关系；5）跟踪需求变更的状态。需求管理需求管理是为有效地控制和管理需求变更等所进行的活动。需求管理的主要任务就是在开发人员在与提出更改的请求者协商的基础上，评估需求变更带来的潜在影响及其可能的成本和费用，然后实施更改，以及有效地管理需求规格说明书和跟踪更改需求的状态。1）控制对需求规格基准的变动；需求管理需求管理是为有效地控制确定需求变更控制过程建立变更控制委员会(SCCB)进行需求变更影响分析跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性管理和控制需求基线的过程需求变更控制系统一个正式的文档，说明如何控制需求变更建立变更审批系统需求变更控制确定需求变更控制过程需求变更控制变更申请需求方开发方忽略选择变更方式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李四，王五，赵六填表人张三软件基线产品修改申请单申请人张三申请日期2010-03-24需求跟踪是指编制每个需求与系统元素之间的联系(可跟踪信息)的文档，其中系统元素包括：其他需求、体系结构、设计部件、测试文档等。需求跟踪可跟踪信息分类：需求-源可跟踪性：与说明该需求的人或文档连接；需求-理由可跟踪性：和理由描述连接；需求-需求可跟踪性：和依赖于该需求的需求连接；需求-体系结构可跟踪性：与实现系统连接；需求-设计可跟踪性：与特定组件连接；需求-界面可跟踪性：与外部系统界面连接。需求跟踪是指编制每个需求与系统元素之间的联系(可跟踪信息)的二、任务分解定义Workpackages：WBS的最低层次的可交付成果WBS(WorkBreakdownStructure)任务分解的过程：将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。任务分解的结果：WBS（任务分解结构）。WBS：面向可交付成果的。二、任务分解定义Workpackages：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

在程序的头部增加修改纪录清单类型1.

变化计数器三、任务分解的方法参照具有类比性的项目(具有相同或相似的周期和工作细目要求)的WBS。类比模板使用应用领域内标准或半标准的WBS作为模板参考使用。与类比所参照的WBS不同，模板更具有抽象性，在任务分解时需根据指导说明来开发项目的WBS。三、任务分解的方法参照具有类比性的项目(具有相同或相似的周期第2章软件项目范围计划自上而下“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数自上而下“变化计数器”系统文件比较预处理增加代码结果处理统计自下而上“变化计数器”系统文件比较预处理增加代码结果处理统计总行标记修改记录修改版本比较找出增删行统计增删行删除代码增加行数删除行数自下而上“变化计数器”系统文件比较预处理增加代码结果处理统计确认并分解项目的组成要素确定分解标准确定分解是否详细确定项目交付成果验证分解的正确性(建立编号)任务结构分解(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子系统2子系统3子系统1.2模块1.3WBS任务名称工期开始时间完成时间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任务名称工期开始时间完成