项目策划及需求分析

项目策划及需求分析经验交流提纲项目策划（35分钟）需求分析（35分钟）讨论（20分钟）项目策划项目策划的重要性项目策划相关内容项目策划参考案例项目策划的重要性从软件实施成功率谈起－Cancelled26%On－Time29%Late45%软件项目成功率调查结果怎样才算是一个成功的项目？项目策划的重要性•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方法简