项目策划及需求分析.ppt

《项目策划及需求分析.ppt》由会员分享，可在线阅读，更多相关《项目策划及需求分析.ppt（91页珍藏版）》请在三一办公上搜索。

1、,项目策划及需求分析经验交流,提纲,项目策划（35分钟）需求分析（35分钟）讨论（20分钟）,项目策划,项目策划的重要性项目策划相关内容项目策划参考案例,项目策划的重要性,从软件实施成功率谈起,软件项目成功率调查结果,怎样才算是一个成功的项目？,项目策划的重要性,W理论Every stakeholder（涉众）is a winner（获胜者）,客户、用户、项目经理、开发者、维护者、软件企业相关人员。,项目策划的重要性,项目成功的十大关键因素中第一位：清楚地界定项目范围及制定项目计划从项目管理角度：三个阶段,项目策划的重要性,一个完善的项目计划 可以使失败的概率降到最低，以最大限度的保证在预期的

2、期限内取得预期的效果,项目策划的重要性,项目策划,项目策划的重要性项目策划相关内容项目策划参考案例,项目策划内容,软件质量保证,需求,项目过程活动,软件配置管理,项目管理,分析,实现,测试,交付,项目策划相关内容,为什么要制定项目开发计划？计划赶不上变化？没有充足的条件制定可行的计划？,计划变更是合理的；关键在于如何使变更可控；,结论：计划变更是在正常不过的,项目策划相关内容,谁来制定项目计划？,结论：计划应由所有的涉众制定,项目策划相关内容,制定几份项目计划？,结论：两个协调的计划并行；,项目策划相关内容,项目策划,项目策划的重要性项目策划相关内容项目策划参考案例,项目策划,策划前策划中策划

3、后,定义项目目标a、项目可交付的结果列表b、制定项目最终完成及中间里程碑的截至日期c、交付结果必须满足的质量准则d、项目不能超过的成本限制,项目策划,定义项目前提a、项目是否依赖其他人员；b、项目是否有其所需的资源；c、成本对项目多重要，谁有权增加项目预算；d、项目的风险是否基本可控；,项目策划,项目策划,策划前策划中策划后,选择软件开发过程模型,项目策划,瀑布模型,增量模型,螺旋模型,RAD模型,RUP,项目策划,软件开发过程模型软件开发过程对客户是个黑匣子,项目策划,让客户加入到软件过程中来，认识我们地软件开发过程模型 软件企业成熟，必须引导要求客户成熟,资源、工作量、进度、及成本估算相关

4、案例见下文,项目策划,安排进度、确定里程碑,项目策划,结论：确定里程碑、快速实现阶段成果，增加成就感，凝聚力，提高客户满意度，客户,分配资源、商讨承诺,项目策划,项目策划,策划前策划中策划后,计划的执行，及对计划的执行做出反馈；交流沟通的重要性；项目计划要不断展开和修正；,项目策划,项目策划,项目策划的重要性项目策划相关内容项目策划参考案例,参考案例,过程相似，结果截然不同的案例,我们又是怎么做的？,一、前提条件二、引言三、问题提出四、从软件过程看“需求”五、需求文档的书写,前提条件,在这里只讨论需求的开发需求管理（如基线）都不在讨论之列,引言,方法论本身源于实践方法论没有绝对的真理，只有绝对

5、的实际方法论限于环境，不同的环境有不同的方法论！方法论不能绝对对的遵循，我们要学会了解方法论、优化方法论，才能更好的为我们服务,问题提出,的开发中，特别是基础套件的开发过程中，我们不得不再次思考以下几个问题：什么是软件需求？需求文档中应该有那些内容？需求写到什么程度？,从软件过程看需求,自上而下、逐步求精,获取市场或用户需要或潜在需要,了解具体使用者习惯和业务,定义软件的功能、展现方式及性能要求,对软件内部结构的设计,程序设计及代码编写,发布,需求,需求,设计,设计,不同的组织对它的范围有不同的解释,什么是“需求”,I E E E软件工程标准词汇表（1 9 9 7年）中定义需求为：（1）用户解

6、决问题或达到目标所需的条件或权能（C a p a b i l i t y）。（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。,什么是“需求”,实际上我们认为“需求”这个词汇是个相对概念对需求的理解和范围划分要从涉众是谁来看待 如，对开发人员来说的“需求”对于客户而言就是“设计”,写好需求的前提,做好需求的前提是，让同一个团队对“需求”的理解达成共识,需求的三个层次,业务需求,用户需求,功能需求,功能需求规格说明书,在开发中我们认为需求有三个层次,问题焦点,我们要为设计或开发人员提供一份什么样的 功能

7、需求规格说明书？,编写需求是软件开发过程中最难的吗？,需求的重要性,有一点可以肯定：设计和编写代码的代价是远远大于编写各种需求文档的代价。,编写各种需求文档,这里将着重讨论功能需求规格说明书,何时产生详细的？,我们能不能在需求阶段提供详细的？,编写各种需求文档,基本要求：明确需求不是设计：需求强调的是产品是怎样，而不是产品是怎样设计和构造。描写功能需求的时候应把系统或子系统看作是黑盒，描述他的响应和行为。而黑盒内部相关的结构和工作原理应留给开发人员去设计。如，软件部件相关的格式，存储应该由设计实现。,编写各种需求文档,定义：软件的功能及是对用户各种需求的抽象,不同的软件功能对事物的抽象层度不同

8、，所以在需求阶段描述的详细度可能不同,一、分清项目类型,1、定制化项目（定制MIS),2、产品开发类项目,3、技术研究类项目,1、定制化项目（定制MIS),简单的抽象（某一个业务）业务需求：如文档、文档用户需求:如功能需求:如需求说明书和概要设计有些类似,2、技术研究类项目,高层次抽象（某一类基础技术）需要有大量的业务分析，理论研究，技术实验，才能规划出其功能。同时需求来源不是用户，而是开发者或开发商。在需求阶段只能描述出要做什么样的事，而无法直接提出什么样的软件功能来完成什么事。所以在需求中只能描述其特性和技术指标具体的软件功能则不涉及,前提条件,、其主要描述描述市场前景、商业模式、潜在收入

9、、定价、成本、合同、销售方式等等 如大量的场景描述初步版本迭带次数更多很多开发产品的公司对功能的设计一般是在设计阶段进行如易用性设计之后才能确定功能需求归和说明书,3、产品开发类项目,前提条件,简单的说：关系到对事务认识的直接性和间接性 由功能提出和软件功能实现的直接性和间接性我们来划分那些该在需求中和设计中实现,文档项的部分说明,例子，某字处理软件，业务需求“用户能有效的纠错正文档中的拼写错误”用户需求“找到一个文档中的单词错误，并提供一个错误列表，用户可以通过该列表进行替换单词 功能需求“拼写检查器，高亮度提示错误词，替换对话框进行替换操作，与错词最相进的单词列表显示”设计则可能是描述实现

10、以上功能，程序要怎么架构如要实现语法分析器，词汇缓冲池、词汇检索引擎，单词分析器，错误类比引擎，高亮显示等等，以及更细粒度的划分和设计”。,文档项的部分说明,业务需求：描述提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求业务流程描述及分析，软件处理描述。用户需求：获取和描述了用户使用产品必须要完成的任务。功能需求：功能需求定义了开发人员必须实现的软件功能,举IEEE的一个例子。根据不同项目，对功能需求的细化程度不同*：与数据模型之间的差别,数据字典只是描述业务过程相关的数据项目，而非具体软件开发时的数据库模型,需求优先级,每项需求必须用优先级进行排序对

11、于产品，我们要规划其长远特性，并对哪些是下一版本实现的做出标识,需求迭代和分包,对于大系统需求是一个迭代的过程。我们不能简单的把需求分为客户需求和功能需求，我们要注意的是我们的需求分析的过程，分析过程是一种方法论，过程的好坏直接影响到最终需求的质量。所以大项目的需求会划分多个阶段，每个阶段需求分析的层次不同细致层度不同，是一种自上而下逐步求精的过程，不同的软件项目需求的迭代次数也不尽相同。,END,提纲,项目,过程,认证,PDSP,OSSP,CMM,Ossp为组织及规范，pdsp为项目定义。,项目管理流程范例,项目管理机构范例,项目策划与跟踪,项目策划需求管理项目跟踪,项目策划,估计：工作细分

12、DELPHI方法简介管理工作量估计进度及里程碑制订风险预估,估计目标,估计目标：寻找估算和实际情况的交汇点合理的估计是准确的进度、有效计划的基础,可靠估计的障碍,1、管理者/客户的压力 2、总体确定后直接分配给项目成员 3、缺乏历史数据 4、混乱的估计方法 5、太理想主义 6、忽视了必要的活动 7、过高的估计自己的能力 8、打折扣 9、即使完成了需求分析，对需要工作量的了解也 在50%以下,软件项目估计的波浪原则,计划在阶段实施之前，每个阶段都是一个“新”项目工作量和成本的估计来源于滚动的WBS元素每个成功的阶段实施之后，估计将会越来越,软件项目估计方法,详细阶段估计1.从下至上方法2.以WB

13、S元素为基础3.最好由实际做这项工作的人来估计,项目初始阶段：1.从上至下的项目估计2.基于项目定义、需求和高层设计3.方法：功能点、代码行和德尔菲法,工作细分前提一：软件工程过程,瀑布模型,增量模型,螺旋模型,RAD模型,工作细分前提二：识别工作产品,工作细分（WBS）表,WBS制订的方法和技巧,1、使用过程模型作为第一层的基础2、将第一层细分，定义低层的元素3、在详细阶段计划时定义最后一层元素4、最后一层元素定义完成之后，完成TDF任务描述表5、管理活动也同样技术活动一样定义6、有些管理活动无法细分，只要有一定程度的努力即可,TDF（任务描述表）,责任人:,所需技能:,前期任务:,工期:,

14、成本:,时间:,估计,提交的产品:,任务描述:,WBS#:,任务名称:,阶段:,项目名称:,WBS在实际项目中的使用惯例,1、项目经理负责划分第一、二层2、应注意尽量不要遗漏测试、安装实施、验收等3、随着阶段计划的开发，模块负责人具体细化4、WBS细化后应符合2周（80小时）原则5、一般情况下项目组成员直接投入项目的时间只占70%80%，任务的评审应留出适当时间,项目策划,估计：工作细分DELPHI方法简介管理工作量估计进度及里程碑制订风险预估,DELPHI方法简介,计划碰头会个人准备估计会得出结果完成估计是估计的一种方法2.专家小组针对WBS或任务列表估计3.是不记名的、记录的、评审的和讨论

15、的估计4.重复该过程直到达成一致意见,DELPHI方法简介,第4轮第3轮第2轮第1轮,50 100 150 200,专家讨论、匿名投票，直到一致,DELPHI方法简介,第4轮第3轮第2轮第1轮,50 100 150 200,专家意见不一致，则取平均值、同时记录最好和最坏值,DELPHI方法简介,多轮投票的退出条件1.完成4轮估计2.估计的范围已经聚集在一个可接受得很窄 的范围之内3.接近会议结束时间（2小时）4.参与者已经不愿再进一步修改自己的估计,DELPHI方法简介,项目策划,估计：工作细分DELPHI方法简介管理工作量估计进度及里程碑制订风险预估,管理工作量估计,SQA：一般占全部技术开

16、发量的5%SCM：一般占全部技术开发量的5%项目管理：一般占全部工作量的20%管理预留：根据项目的特点制订，一般为20%,管理工作量估计,例：项目预算开发工作量1000 小时配置管理（5%）50质量保证（5%）50其它（培训）24项目管理（20%）220 总的审定预算：1344管理预留（20%）270 总的项目预算：1614 小时,项目策划,估计：工作细分DELPHI方法简介管理工作量估计进度及里程碑制订风险预估,甘特图,网络图,里程碑制订,根据WBS细分，制订项目里程碑明确项目里程碑内应完成的WBS每个WBS有其对应的里程碑,定义获取价值（EV）曲线,获得值（EV）技术使估算成本和项目进度结

17、合起来EV提供了一般项目活动的度量衡项目活动的价值一般用人小时成本或人天表示当活动完成之后，活动的价值才获得了通过EV分析，对项目的成本和进度能有一个直观的了解,建立项目基线,将任务预算和时间进度联合起来,建立项目基线,将任务预算和时间进度联合起来,按照项目基线计算获取价值,建立获取价值曲线,0,50,100,150,200,250,300,350,400,1,2,3,4,5,BCWS,进度（周）,累积成本（小时）,项目策划,估计：工作细分DELPHI方法简介管理工作量估计进度及里程碑制订风险预估,风险矩阵,风险识别,项目计划构成内容,项目计划大纲项目任务书相关文档项目组织结构开发过程工作细分风险估计时间进度安排获得价值基线资源附录,