软件项目计划.ppt

软件项目计划.ppt

《软件项目计划.ppt》由会员分享，可在线阅读，更多相关《软件项目计划.ppt（96页珍藏版）》请在冰豆网上搜索。

chapter_50软件开发项目管理软件开发项目管理chapter_51RoadMapRoadMap项项目结束目结束项目项目执行控制执行控制项项目计划目计划项目项目初始初始第二篇第二篇软件项目计划chapter_53没有计划的情况没有计划的情况时间资源投入开发工作计划性工作协调性工作chapter_54有计划的情况有计划的情况时间资源投入开发工作计划性工作协调性工作chapter_55计划的重要性计划的重要性qPMI：

项目成功的法宝：

q计划、计划、计划q计划是通向项目成功的路线图q范围计划、进度计划、成本计划是核心计划chapter_56项目进度计划项目进度计划chapter_57编制计划的三步曲编制计划的三步曲q任务分解（WBS）-范围基准q成本估算q资源、进度安排成本基准，进度基准chapter_58RoadMap合合同同计计划划风风险险计计划划沟沟通通计计划划人人力力计计划划质质量量计计划划成成本本计计划划时时间间计计划划集集成成计计划划范范围围计计划划项项目目结结束束项项目目执执行行控控制制项项目目计计划划项项目目初初始始chapter_59软件项目管理软件项目管理第第22章章软件项目范围计划软件项目范围计划chapter_510软件项目的范围软件项目的范围n1、软件项目的范围是指对项目包括什么、软件项目的范围是指对项目包括什么与不包括什么的定义，即项目的需求。

与不包括什么的定义，即项目的需求。

n2、软件项目的范围计划包括需求管理和、软件项目的范围计划包括需求管理和任务分解两部分。

任务分解两部分。

chapter_511本章要点本章要点q一、软件需求的定义q二、需求管理q三、任务分解过程q四、任务分解方法q五、任务分解检验q六、案例分析chapter_512关于软件需求关于软件需求q需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样功能，达到什么性能。

q软件人员要准确理解用户的要求，将用户非形式需求陈述转化为需求定义，再由需求定义转化到相应的需求规格说明（SRS）过程。

chapter_513软件需求主要包括三个层次软件需求主要包括三个层次n1、业务需求：

反映了组织机构或客户对系统、业务需求：

反映了组织机构或客户对系统、产品高层次的目标要求，由管理人员或市场产品高层次的目标要求，由管理人员或市场分析人员确定。

分析人员确定。

n2、用户需求：

描述了用户通过使用本软件产、用户需求：

描述了用户通过使用本软件产品必须要完成的任务，一般是用户协助提供。

品必须要完成的任务，一般是用户协助提供。

n3、功能需求：

定义了开发人员必须实现的软、功能需求：

定义了开发人员必须实现的软件功能，使用户通过使用此软件能完成他们件功能，使用户通过使用此软件能完成他们的任务，从而满足了业务需求和用户需求。

的任务，从而满足了业务需求和用户需求。

chapter_514软件需求规格软件需求规格n软件需求规格充分描述了软件系统应具有软件需求规格充分描述了软件系统应具有的外部行为，描述了系统展现给用户的行的外部行为，描述了系统展现给用户的行为和执行的操作等。

它包括功能需求、非为和执行的操作等。

它包括功能需求、非功能需求、产品必须遵守的标准、规范和功能需求、产品必须遵守的标准、规范和合约等等。

合约等等。

n开发人员可据此设计软件，实现必要的功开发人员可据此设计软件，实现必要的功能。

能。

chapter_515软件需求的层次图示软件需求的层次图示业务需求用户需求功能需求软件需求规格非功能性需求质量特性约束和假设系统需求chapter_516本章要点本章要点q一、软件需求定义q二、软件需求管理过程q三、任务分解过程q四、任务分解方法q五、任务分解检验q六、案例分析chapter_517需求管理的重要性需求管理的重要性chapter_518需求管理的重要性需求管理的重要性n在以往失败的软件项目中，以往失败的软件项目中，80%是由于需是由于需求分析不明确造成的。

求分析不明确造成的。

n有效的需求管理可以使在开发后期和整个有效的需求管理可以使在开发后期和整个维护阶段的返工的工作量大大减少。

维护阶段的返工的工作量大大减少。

chapter_519项目项目失败的原因分析失败的原因分析No.Top10Factors平均值平均值1Inadequaterequirementsspecification不充分的需求规范4.52Changesinrequirements需求的改变4.33Shortageofsystemsengineers缺乏系统工程师4.24Shortageofsoftwaremanagers缺乏了解软件特性的经理人4.15Shortageofqualifiedprojectmanagers缺乏合格的项目经理4.16Shortageofsoftwareengineers缺乏软件工程师3.97Fixed-pricecontract固定价合同3.88Inadequatecommunicationsforsystemintegration系统集成阶段,交流与沟通不充分3.89Insufficientexperienceasteam团队缺乏经验3.610Shortageofapplicationdomainexperts缺乏应用领域专家3.6Scale:

5=VerySerious3=Serious1=NoSeriousSource:

Carnegie-MellonUniversity,SoftwareEngineeringInstitutechapter_520需求管理中的问题举例需求管理中的问题举例q需求的隐含错误q需求不明确、含糊q用户不断增加需求、变更需求q用户刁难q开发人员的镀金chapter_521软件需求管理的过程软件需求管理的过程需求分析需求分析编写需求规格编写需求规格需求验证需求验证需求获取需求获取需求变更需求变更需求确认需求变更chapter_522需求工程基本任务需求工程基本任务（分析记录软件需求的学科分析记录软件需求的学科）需求工程需求工程需求管理需求管理需求开发需求开发需求获取需求获取需求分析需求分析需求规格说明需求规格说明需求验证需求验证变更管理变更管理chapter_523本章要点本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更chapter_524需求获取图示需求获取图示chapter_525需求获取需求获取n需求获取是通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。

chapter_526需求获取需求获取用户要求扩展需求基线需求软件需求chapter_527什么是基线需求什么是基线需求n基线需求是项目的原始需求，是经过批准基线需求是项目的原始需求，是经过批准的需求部分，作为需求管理和定义项目范的需求部分，作为需求管理和定义项目范围的基础围的基础chapter_528需求获取的活动需求获取的活动1、了解客户方的所有用户类型，确定系统整体目标、了解客户方的所有用户类型，确定系统整体目标2、对用户进行访谈和调研，、对用户进行访谈和调研，P46，特别是需求专题讨，特别是需求专题讨论会（头脑风暴）论会（头脑风暴）3、需求分析人员对收集到的用户需求做进一步的分、需求分析人员对收集到的用户需求做进一步的分析和整理析和整理4、将调研的用户需求以适当方式呈交给用户方和开、将调研的用户需求以适当方式呈交给用户方和开发方相关人员。

发方相关人员。

5、注意：

识别真正的客户、正确理解客户的需求、注意：

识别真正的客户、正确理解客户的需求、具备强的忍耐力和清晰的思维、说服和教育客户。

具备强的忍耐力和清晰的思维、说服和教育客户。

chapter_529头脑风暴（Brainstorming）n头脑风暴（Brainstorming）是由美国奥斯本提出的，一种激发集体智慧产生和提出创新设想的思维方法。

n头脑风暴（Brainstorming）指一群人（或小组）围绕一个特定的兴趣或领域，进行创新或改善，产生新点子，提出新办法。

n有时候，我们独自一人比在小组里更有创造力！

事实上，你也可以独自进行头脑风暴，来获取更多的创意。

自己进行头脑风暴自由简单，而且独立的头脑风暴可以提升你的思考方式。

chapter_530本章要点本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更chapter_531需求分析定义需求分析定义q需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。

chapter_532需求分析模型需求分析模型chapter_533需求分析应执行的活动需求分析应执行的活动在很多情况下，分析用户需求与获取用户需在很多情况下，分析用户需求与获取用户需求并行的，两者有相似的步骤，区别在于前者采求并行的，两者有相似的步骤，区别在于前者采用可视化模型来描述用可视化模型来描述n1、以图形表示的方式描述系统的整体结构，包括、以图形表示的方式描述系统的整体结构，包括系统的边界与接口系统的边界与接口n2、通过原型、页面流或其他方式向用户提供可视、通过原型、页面流或其他方式向用户提供可视化界面，用户可以对需求评价化界面，用户可以对需求评价n3、以模型描述系统的功能项、数据实体、外部实、以模型描述系统的功能项、数据实体、外部实体、实体间的关系、实体间的转换等内容体、实体间的关系、实体间的转换等内容n4、常采用让用户参与开发、开发用户界面原型、常采用让用户参与开发、开发用户界面原型、需求讨论会议、专家评审的策略需求讨论会议、专家评审的策略chapter_534本章要点本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更chapter_535需求规格需求规格q需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书（SRS）q需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。

q需求规格说明书以一种开发人员可用的技术形式陈述了一个软件产品所具有的基本特征。

它相当于软件开发的图纸。

qSRS的编写可以参考需方提供的工作陈述（SOW）的有关信息进行。

两者都是很重要的文档。

chapter_536软件需求规格说明的原则软件需求规格说明的原则qq从现实中分离功能，即描述要从现实中分离功能，即描述要“做什做什么么”而不是而不是“怎样实现怎样实现”qq采用一定的规格说明语言采用一定的规格说明语言qq如果被开发软件只是一个大系统中的如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在一个元素，那么整个大系统也包括在规格说明的描述之中规格说明的描述之中chapter_537qq规格说明应该包括系统运行环境规格说明应该包括系统运行环境qq规格说明应该是一个认识模型规格说明应该是一个认识模型qq规格说明应该容许不完备性并允许扩规格说明应该容许不完备性并允许扩充充qq见见P49P49的例子的例子chapter_538需求需求规格文档参考规格文档参考1.引言2.系统定义3.应用环境4.功能规格5.性能需求6.产品提交7.实现约束8.质量描述9.其它10.签字认证chapter_539本章要点本章要点q一、软件需求定义q二、软件需求管理过程q需求的获取q需求分析q编写需求规格q需求验证q需求变更chapter_540需求验证需求验证n需求规格提交后，开发人员需要与客户对需求需求规格提交后，开发人员需要与客户对需求分析的结果进行验证，以需求说明（分析的结果进行验证，以需求说明（SOW）为）为输入，通过符号执行、模拟或快速原型等途径，输入，通过符号执行、模拟或快速原型等途径，分析需求规格分析需求规格（SRS