项目策划及需求分析

工程筹划及需求分析经验交流提纲工程筹划〔35分钟〕需求分析〔35分钟〕讨论〔20分钟〕工程筹划工程筹划的重要性工程筹划相关内容工程筹划参考案例工程筹划的重要性

从软件实施成功率谈起－软件工程成功率调查结果

怎样才算是一个成功的工程？工程筹划的重要性

W理论Everystakeholder〔涉众〕isawinner〔获胜者〕客户、用户、工程经理、开发者、维护者、软件企业相关人员。。。。工程筹划的重要性

工程成功的十大关键因素中第一位：清楚地界定工程范围及制定工程方案从工程管理角度：三个阶段工程筹划的重要性

一个完善的工程方案可以使失败的概率降到最低，以最大限度的保证在预期的期限内取得预期的效果工程筹划的重要性

工程筹划工程筹划的重要性工程筹划相关内容工程筹划参考案例工程筹划内容软件质量保证需求工程过程活动软件配置管理工程管理分析实现测试交付工程筹划相关内容

为什么要制定工程开发方案？方案赶不上变化？没有充足的条件制定可行的方案？方案变更是合理的；关键在于如何使变更可控；结论：方案变更是在正常不过的工程筹划相关内容

谁来制定工程方案？结论：方案应由所有的涉众制定工程筹划相关内容

制定几份工程方案？结论：两个协调的方案并行；工程筹划相关内容

工程筹划工程筹划的重要性工程筹划相关内容工程筹划参考案例工程筹划筹划前筹划中筹划后定义工程目标 a、工程可交付的结果列表 b、制定工程最终完成及中间里程碑的截至日期 c、交付结果必须满足的质量准那么 d、工程不能超过的本钱限制工程筹划定义工程前提 a、工程是否依赖其他人员； b、工程是否有其所需的资源； c、本钱对工程多重要，谁有权增加工程预算； d、工程的风险是否根本可控；工程筹划工程筹划筹划前筹划中筹划后选择软件开发过程模型

工程筹划系统分析软件需求分析设计编码测试FullSystemIncrement1Increment2Increment3瀑布模型增量模型螺旋模型RAD模型RUP

工程筹划软件开发过程模型 软件开发过程对客户是个黑匣子

工程筹划『让客户参加到软件过程中来，认识我们地软件开发过程模型』『软件企业成熟，必须引导要求客户成熟』资源、工作量、进度、及本钱估算『相关案例见下文』工程筹划安排进度、确定里程碑工程筹划结论：『确定里程碑、快速实现阶段成果，增加成就感，凝聚力，提高客户满意度，客户』分配资源、商讨承诺工程筹划工程筹划筹划前筹划中筹划后方案的执行，及对方案的执行做出反响；交流沟通的重要性；工程方案要不断展开和修正；工程筹划工程筹划工程筹划的重要性工程筹划相关内容工程筹划参考案例参考案例过程相似，结果截然不同的案例我们又是怎么做的？一、前提条件二、引言三、问题提出四、从软件过程看“需求〞五、需求文档的书写前提条件在这里只讨论需求的开发需求管理〔如基线〕都不在讨论之列引言方法论本身源于实践方法论没有绝对的真理，只有绝对的实际方法论限于环境，不同的环境有不同的方法论！方法论不能绝对对的遵循，我们要学会了解方法论、优化方法论，才能更好的为我们效劳问题提出的开发中，特别是根底套件的开发过程中，我们不得不再次思考以下几个问题：什么是软件需求？需求文档中应该有那些内容？需求写到什么程度？

从软件过程看需求自上而下、逐步求精获取市场或用户需要或潜在需要了解具体使用者习惯和业务定义软件的功能、展现方式及性能要求对软件内部结构的设计程序设计及代码编写发布需求需求设计设计不同的组织对它的范围有不同的解释什么是“需求〞IEEE软件工程标准词汇表〔1997年〕中定义需求为：〔1〕用户解决问题或到达目标所需的条件或权能〔Capability〕。〔2〕系统或系统部件要满足合同、标准、标准或其它正式规定文档所需具有的条件或权能。〔3〕一种反映上面〔1〕或〔2〕所描述的条件或权能的文档说明。什么是“需求〞实际上我们认为“需求〞这个词汇是个相对概念对需求的理解和范围划分要从涉众是谁来看待如，对开发人员来说的“需求〞对于客户而言就是“设计〞写好需求的前提做好需求的前提是，让同一个团队对“需求〞的理解达成共识需求的三个层次业务需求用户需求功能需求功能需求规格说明书在开发中我们认为需求有三个层次问题焦点我们要为设计或开发人员提供一份什么样的《功能需求规格说明书》？编写需求是软件开发过程中最难的吗？需求的重要性有一点可以肯定：设计和编写代码的代价是远远大于编写各种需求文档的代价。编写各种需求文档这里将着重讨论《功能需求规格说明书》何时产生详细的<<功能需求规格说明书>>？我们能不能在需求阶段提供详细的<<功能需求规格说明书>>？编写各种需求文档根本要求：明确需求不是设计：需求强调的是产品是怎样，而不是产品是怎样设计和构造。描写功能需求的时候应把系统或子系统看作是黑盒，描述他的响应和行为。而黑盒内部相关的结构和工作原理应留给开发人员去设计。如，软件部件相关的格式，存储应该由设计实现。编写各种需求文档定义：软件的功能及是对用户各种需求的抽象不同的软件功能对事物的抽象层度不同，所以在需求阶段描述的详细度可能不同一、分清工程类型1、定制化工程〔定制MIS)2、产品开发类工程3、技术研究类工程1、定制化工程〔定制MIS)简单的抽象〔某一个业务〕业务需求：如<<业务分析>>文档、<<工程范围>>文档用户需求:如<<用户使用场景描述>>功能需求:如<<功能需求规格说明书>><<数据字典>>〈需求说明书和概要设计有些类似〉2、技术研究类工程高层次抽象〔某一类根底技术〕需要有大量的业务分析，理论研究，技术实验，才能规划出其功能。同时需求来源不是用户，而是开发者或开发商。在需求阶段只能描述出要做什么样的事，而无法直接提出什么样的软件功能来完成什么事。所以在需求中只能描述其特性和技术指标具体的软件功能那么不涉及前提条件<<市场需求文档>>、其主要描述描述市场前景、商业模式、潜在收入、定价、本钱、合同、销售方式等等如<<业务分析>><<用户使用场景描述>>大量的场景描述<<功能需求>>初步版本迭带次数更多很多开发产品的公司对功能的设计一般是在设计阶段进行如易用性设计之后才能确定《功能需求归和说明书》3、产品开发类工程前提条件简单的说：关系到对事务认识的直接性和间接性由功能提出和软件功能实现的直接性和间接性我们来划分那些该在需求中和设计中实现文档项的局部说明例子，某字处理软件，业务需求“用户能有效的纠错正文档中的拼写错误〞用户需求“找到一个文档中的单词错误，并提供一个错误列表，用户可以通过该列表进行替换单词"功能需求“拼写检查器，高亮度提示错误词，替换对话框进行替换操作，与错词最相进的单词列表显示〞设计那么可能是描述实现以上功能，程序要怎么架构"如要实现语法分析器，词汇缓冲池、词汇检索引擎，单词分析器，错误类比引擎，高亮显示等等，以及更细粒度的划分和设计〞。文档项的局部说明业务需求：描述提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求业务流程描述及分析，软件处理描述。

用户需求：获取和描述了用户使用产品必须要完成的任务。功能需求：功能需求定义了开发人员必须实现的软件功能,举IEEE的一个例子。根据不同工程，对功能需求的细化程度不同

*<<数据字典>>：与数据模型之间的差异,数据字典只是描述业务过程相关的数据工程，而非具体软件开发时的数据库模型

需求优先级每项需求必须用优先级进行排序对于产品，我们要规划其长远特性，并对哪些是下一版本实现的做出标识需求迭代和分包对于大系统需求是一个迭代的过程。我们不能简单的把需求分为客户需求和功能需求，我们要注意的是我们的需求分析的过程，分析过程是一种方法论，过程的好坏直接影响到最终需求的质量。所以大工程的需求会划分多个阶段，每个阶段需求分析的层次不同细致层度不同，是一种自上而下逐步求精的过程，不同的软件工程需求的迭代次数也不尽相同。END提纲工程过程认证PDSPOSSPCMMOssp为组织及标准，pdsp为工程定义。工程管理流程范例工程管理机构范例工程筹划与跟踪工程筹划需求管理工程跟踪工程筹划估计：工作细分DELPHI方法简介管理工作量估计进度及里程碑制订风险预估估计目标估计目标：寻找估算和实际情况的交汇点合理的估计是准确的进度、有效方案的根底可靠估计的障碍

1、管理者/客户的压力2、总体确定后直接分配给工程成员3、缺乏历史数据4、混乱的估计方法5、太理想主义6、无视了必要的活动7、过高的估计自己的能力8、打折扣9、即使完成了需求分析，对需要工作量的了解也在50%以下软件工程估计的波浪原那么 方案在阶段实施之前，每个阶段都是一个“新〞工程 工作量和本钱的估计来源于滚动的WBS元素 每个成功的阶段实施之后，估计将会越来越软件工程估计方法详细阶段估计 1.从下至上方法 2.以WBS元素为根底 3.最好由实际做这项工作的人来估计工程初始阶段： 1.从上至下的工程估计 2.基于工程定义、需求和高层设计 3.方法：功能点、代码行和德尔菲法工作细分前提一：软件工程过程系统分析软件需求分析设计编码测试FullSystemIncrement1Increment2Increment3瀑布模型增量模型螺旋模型RAD模型工作细分前提二：识别工作产品WorkProductsProjectPhases&ActivitiesDefinitionDesignCodingTestingSASTPSRAHLDDDITPCUTITSTDOCRELCustomerReqtsSpecXSoftwareReqtsSpecXHigh-LevelDesignSpecXDetailDesignSpecXCodeXSystemTestPlanXXIntegrationTestPlanXUnitTestPlanXUnitTestReportXIntegrationTestReportXSystemTestReportXUserManual-PreliminaryXUserManual-FinalXReleaseNotesXInstallationTopeX工作细分〔WBS〕表WBS级别工作包2过程3模块4子模块5功能点任务描述工作产品

技术方面

管理和支持方面

WBS制订的方法和技巧1、使用过程模型作为第一层的根底2、将第一层细分，定义低层的元素3、在详细阶段方案时定义最后一层元素4、最后一层元素定义完成之后，完成TDF《任务描述表》5、管理活动也同样技术活动一样定义6、有些管理活动无法细分，只要有一定程度的努力即可TDF〔任务描述表〕责任人:所需技能:前期任务:工期:本钱:时间:估计提交的产品:任务描述:WBS#:任务名称:阶段:工程名称:WBS在实际工程中的使用惯例1、工程经理负责划分第一、二层2、应注意尽量不要遗漏测试、安装实施、验收等3、随着阶段方案的开发，模块负责人具体细化4、WBS细化后应符合2周〔80小时〕原那么5、一般情况下工程组成员直接投入工程的时间只占70%~80%，任务的评审应留出适当时间工程筹划估计：工作细分DELPHI方法简介管理工作量估计进度及里程碑制订风险预估DELPHI方法简介方案→碰头会→个人准备→估计会→得出结果→完成估计是估计的一种方法2.专家小组针对WBS或任务列表估计3.是不记名的、记录的、评审的和讨论的估计4.重复该过程直到达成一致意见DELPHI方法简介第4轮第3轮第2轮第1轮50100150200第4轮第3轮第2轮第1轮50100150200专家讨论、匿名投票，直到一致DELPHI方法简介第4轮第3轮第2轮第1轮50100150200第4轮第3轮第2轮第1轮50100150200专家意见不一致，那么取平均值、同时记录最好和最坏值DELPHI方法简介多轮投票的退出条件 1.完成4轮估计 2.估计的范围已经聚集在一个可接受得很窄 的范围之内

3.接近会议结束时间〔2小时〕 4.参与者已经不愿再进一步修改自己的估计DELPHI方法简介WBS活动估计#1变更#1变更#2变更#3估计结果假设前提

总计：工程筹划估计：工作细分DELPHI方法简介管理工作量估计进度及里程碑制订风险预估管理工作量估计SQA：一般占全部技术开发量的5%SCM：一般占全部技术开发量的5%工程管理：一般占全部工作量的20%管理预留：根据工程的特点制订，一般为20%管理工作量估计例：工程预算开发工作量1000小时配置管理〔5%〕50质量保证〔5%〕50其它〔培训〕24工程管理〔20%〕220总的审定预算：1344管理预留〔20%〕270总的工程预算：1614小时工程筹划估计：工作细分DELPHI方法简介管理工作量估计进度及里程碑制订风险预估甘特图WEEKHours12345678910Activity1Activity5Activity4Activity6Activity9Activity2Activity7Activity10Activity3Activity8网络图开始ACFDGBH结束E里程碑制订根据WBS细分，制订工程里程碑明确工程里程碑内应完成的WBS每个WBS有其对应的里程碑定义获取价值〔EV〕曲线获得值〔EV〕技术使估算本钱和工程进度结合起来EV提供了一般工程活动的度量衡 工程活动的价值一般用人小时本钱或