软件工程案例分析课件.ppt

软件工程案例分析,陈天洲浙江大学计算机学院,软件特征（1）,最根本的：软件是一种逻辑元素而不是物理元素软件是开发出的，而不是用传统的方法制造出来的软件不会被用坏,软件特征（2）,软件特征（3）,工业界已经走向了标准化装配时代，然而绝大多数软件还是定制出来的。科学计算函数库（60年代）重用数据结构重用组件,成本结构发生了巨大的变化,一次性的制造成本介质成本的可忽略性逻辑产品不可回逆的投入维护成本的增加服务是质量要素中的重点,软件危机,“软件危机”是1958年在NATO会议上作为一个正式的议题被提出来软件项目不成功的例子比比即是：1999年10月，耗资1.25亿美元的NASA的火星气象卫星失踪（公英制转换）,软件危机,一些数据：大约70的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20到50，90以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高美国政府审计局：只有不到2的合同定购软件在发布时具有可用性98以上的项目都失败了,软件危机,一种看法“两难境地（CrunchMode）”：处于两难境地的项目面临无法达到最初目标的威胁（费用、进度表、功能性等），而项目团队努力想跨越困境。“我们正处于两难境地，在半夜之前是不会回家”“死亡行军（DeathMarch）”：用来描述其进度表几乎不可能完成的项目。“这是一个死亡行军项目，我希望自己不要参与进去”,软件危机,更准确的说法：慢性痛苦（chronicaffliction)SuggestedbyProf.DanielTiechrow,UniversityofMichigan尽管忍受痛苦，但是软件依然在我们这个世界起着越来越重要的作用，但是如果能够医治痛苦，那么软件业将发展得更加健康。,软件危机的主要特征,软件开发周期大大超过规定日期;软件开发成本严重超标;软件质量难于保证,软件成功的标准,用户在用用户可很容易做完要做的事失败的根本原因：开发人员写出的东西达不到用户要求(人的问题.技术问题),规模复杂性生产率,软件技术面临的问题,例:Windows95有1000万行代码Windows2000有5000万行代码，3000多个工程师，几百个小团队。,Exchange2000和Windows2000开发人员结构,“软件工程案例分析”课程与其它软件专业课的区别,(1)立足于系统的整体。(2)系统分析、系统设计、测试及维护的方法实践。(3)构筑一个软件系统，实践软件开发全过程。,用户,分析员,程序员,系统分析员的地位,“一个好的工业，应有一套良好的标准来配套”,软件工业化生产过程应具备的特点明确的工作步骤详细具体的规范化文档明确的质量评价标准,软件产品的标准化,软件开发过程的标准化,软件工程技术的两个明显特点,强调规范化强调文档化,新世纪软件产业的趋势,网络化趋势：计算机与通信的融合趋势万维网智能网络服务化趋势：“打包式”软件“服务式”软件全球化趋势,中国软件产业发展主要问题,产业规模小、集中度低产业竞争力弱，缺乏核心技术市场秩序较为混乱，盗版严重,制约软件产业发展的因素,软件开发规范与标准知识产权环境知识结构公司体制,项目与项目管理,项目是什么没有例行的任务需要计划特定的目标需要满足或者特定的产品需要生成项目有一个预定义的时间范围工作不仅仅是为自己，也是为他人工作中有些特性工作分为若干阶段项目完成需要资源项目是大型的或者复杂的项目管理是什么项目管理是在项目活动中应用知识，技能，工具和技术来满足项目需求的过程，它通过初始化，计划，执行，控制和结束等活动来完成。,软件项目与软件项目管理,软件项目的特征不可见复杂性（以每一单位货币来看）灵活性：软件去适应人或组织而不是相反一致性软件项目管理为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。,软件项目的活动,需求分析描述设计编码校验安装维护支持,软件项目分类,按软件类别信息系统：与组织接口嵌入式系统：接口是机器操作系统是一个信息系统还是嵌入式系统？有些项目是为了生成某一产品，而某些项目的进行是为了达到某些目标。许多软件项目分为两个阶段，第一阶段是目标驱动，第二阶段再生成真正的软件产品。,从系统的角度看软件项目,一个项目关注于生成一个系统和/或将一个旧系统转换为一个新系统系统，子系统和环境开放和封闭系统项目失败的一个原因是技术人员不能够开放系统和立即接受外界的变化。部分优化例如：可能很高效，但是难于修改社会技术系统软件项目属于此类,软件项目中的人员,项目影响者(stakeholders)项目小组内部：项目小组外部，但是在同一组织内：项目小组和组织外部：如客户不同的项目影响者有不同的目标，因而项目领导者需要能够协调这些目标。Boehm和Ross提出软件项目管理的“W理论”，该理论关注于所有各方都能从项目种获益因而对项目的成功都有兴趣。（W代表EveryoneaWinner）,软件开发面临的挑战,处理最终日期（deadlines）(85%)处理资源约束（83）与任务小组有效的沟通（80）从小组成员处得到承诺（74）建立可测量的milestone（90）处理变化（60）得到团队公认的项目计划（57）从管理层得到承诺（45）处理冲突（42）管理销售商和子项目承包商（38）,项目经理面临的挑战,估计和计划缺少质量标准和度量缺少组织决策的指南缺少使进度可视化的技术角色定义不正确的成功准则缺少标准,项目成员面临的挑战,工作的不正确的描述IT的管理失误缺少应用领域的知识缺少及时的文档前续任务没有及时完成包括设备没及时提供用户与技术员之间缺乏交流缺少质量控制软件环境的改变Deadline压力,软件项目常见错误,选自快速软件开发产品相关的错误需求镀金：项目具有比实际需求多得多的性能功能蔓延：项目平均会有25%的需求变更（Jones1994）开发人员的镀金：开发人员着迷于新技术又推又拉的交易：经理在批准项目进度顺延时又加入了新的功能研究导向的开发,软件项目常见错误（续）,过程中的错误缺乏计划过于乐观的计划在压力下放弃计划缺乏足够的风险管理承包人导致的失败在模糊的项目前期浪费时间前期活动不合要求,过程中的错误设计低劣缺少质量保证措施缺少管理控制太早和过于频繁的集成项目估算时遗漏必要的任务追赶计划鲁莽编码,软件项目常见错误（续）,技术相关的错误银弹综合症:过于相信以前没有采用过的技术的宣传过高估计了新技术或方法带来的节省量项目中间切换工具缺少自动的源代码控制手段,软件项目常见错误（续）,人员相关的错误挫伤积极性人员素质低对有问题的员工失控英雄主义项目后期加入人员：“火上加油”办公环境差开发人员与客户之间发生摩擦不现实的预期,软件项目常见错误（续）,缺乏有效的高层对项目的支持缺乏各种角色的齐心协力缺乏用户介入政治高于物质充满想像：“项目组没人真正相信他们能够按给定的计划进度完成项目，但他们认为如果每个人能够努力工作，并且不出现问题，他们可能会很幸运地按时完成任务。,软件项目常见的错误,试分析以下故事中的项目所存在的错误：一天，一位年青人被选来“写”一个用在自动化制造设备上的程序。选择他的理由很简单：他是技术小组中唯一参加过编程培训的人。他懂得汇编语言和Fortran语言，但是他不知道软件工程，更不知道软件计划和跟踪方面的知识。,软件开发过程模型选择,主要内容,项目实施的方法选择问题识别项目中的高风险软件开发过程模型的选择可选择的模型软件开发项目过程的选择软件开发方法,项目实施的方法选择,技术选择技术选择将影响：开发人员的训练需要人员招聘开发环境硬件和软件系统维护安排方法选择方法选择将影响：开发人员组合实施的进度安排开发策略选择,项目实施的方法选择,步骤：分析目标驱动还是产品驱动分析项目其他特征面向数据还是面向控制通用还是专用是否需要专用工具支持的专门技术是否有特殊的安全性要求对软硬件有何要求,识别项目中的高风险,产品不确定性：系统需求理解的准确性。用户在开始时有可能对系统应该什么样都无法确定。在某些环境中，精确而有效的需求描述可能迅速变得过时。过程不确定性：在项目开始时需要选择方法或过程模型，或者一种新的工具，任何对原先采用的开发方法的变化都将引入不确定性资源不确定性：项目进行中资源的数量可能发生变化,软件开发过程模型的选择,开发一个软件需要选择开发策略（包括过程，方法和工具）以及通用阶段，这些策略和阶段被称为过程模型“过程”：相关联的活动过程模型的选择基于项目和应用的特性，使用的工具和方法，所需要的控制方法和交付物。,软件生存周期(SoftwareLifeCycle)软件产品或软件系统从设计、投入使用到被淘汰的全过程软件生存期的阶段划分可行性研究与计划需求分析总体设计详细设计实现集成测试确认测试使用和维护,软件生存周期,计算机软件开发规范,上游,下游,新的国际标准定义的软件生存过程（1995ISO/IEC12207）,软件生存期过程,支持过程,组织过程,主要过程,获取过程,供应过程,开发过程,运行过程,维护过程,文档编制过程,配置管理过程,质量保证过程,验证过程,确认过程,联合评审过程,审核过程,问题解决过程,管理过程,基础设施过程,改进过程,培训过程,只考虑编写程序,涉及整个软件生存周期,扩展到,软件工作的范围,软件开发全部过程、活动和任务的结构框架。直观表达软件开发全过程明确规定要完成的主要活动、任务和开发策略也称为：软件过程模型软件生存周期模型软件工程范型,软件开发模型,问题求解的一般过程,问题求解的一般过程实际问题并不能简单划为四个阶段，各个阶段会在问题的不同层次上同时并存软件开发实际上是一个“混沌”（chaos）过程,问题定义,方案集成,技术开发,现状,A.编码修正模型,CodeandFixCodelikeHell(鲁莽编码)从一个大致的想法开始工作，然后经过非正规的设计、编码、调试和测试方法，最后完成工作,可能有可能没有的规范,发布（可能）,编码修正模型,好处：成本可能很低只需要很少的专业知识，任何写过程序的人都可以对于一些非常小的、开发完后就会很快丢弃的软件可以采用对于规模稍大的项目，采用这种模型是很危险的,B.瀑布模型（WaterfallModel),所有过程模型的祖宗项目从开始到结束按照一定的顺序执行瀑布模型是文档驱动的，各个阶段不连续也不交叉,B.瀑布模型(WaterfallModel),可行性研究与计划,需求分析,设计,编码,运行维护,测试,定义阶段,开发阶段,维护阶段,适应场合？优缺点？,瀑布模型的适用场合,有一个稳定产品定义和很容易被理解的技术解决方案时，纯瀑布模型特别合适对一个定义得很好的版本进行维护或将一个产品移植平台，瀑布模型也特别合适。纯瀑布模型能够降低管理费用，因为你可以预先完成所有计划。对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题。在质量需求高于成本需求和进度需求的时候，它尤为出色。当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。,瀑布模型缺点,纯瀑布模型在项目开始时，在设计工作完成前和代码写出来前，很难充分描述需求。瀑布模型最主要问题是缺乏灵活性。必须在项目开始前说明全部需求。但这恰恰是非常困难的。,按照传统瀑布模型开发软件的特点,阶段间具有顺序性和依赖性。推迟实现的观点。每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。,C.瀑布模型变种：V型模型,该方法是对瀑布模型的修正，强调了验证活动,可行性研究,用户需求,系统设计,程序设计,编码,程序测试,系统测试,用户接受,评价,修正,修正,修正,修正,D.瀑布模型变种：生鱼片模型,把阶段重叠起来的瀑布模型起源于日本硬件开发模型（富士通施乐）,软件概念,需求分析,架构设计,详细设计,编码和调试,系统测试,生鱼片模型的特点和缺点,传统的瀑布模型强调阶段之间最小重叠，而生鱼片模型强调大幅度重叠，即在需求分析完成之前就可以进行架构设计和部分详细设计纯瀑布模型强调在任意两个阶段交接时，文档从一个团队交给另一个完全隔离的团队，但是如果一个团队完成各个阶段任务时，可以没有那么多文档。问题：缺点是什么？生鱼片模型因为阶段重叠，因而里程碑不明确，很难有效地进行过程跟踪和控制。,E.瀑布模型变种：具有子项目的瀑布模型,纯瀑布模型的问题：必须完成全部架构设计后才能进行详细设计，但是，整个系统中有些部分可能有些特殊性，可以有自己的步骤，即将这些部分划分为子项目。问题：该模型有何问题？这种方法的主要风险是相关性无法预料。,F.瀑布模型变种：能够降低风险的瀑布模型,纯瀑布模型：要求在开始架构设计前，必须将用户的所有需求都搞清楚，但是实际中是很困难的。可降低风险的瀑布模型是在顶端，即需求分析和架构设计阶段引入螺旋以便降低风险。螺旋中，先开发一个用户界面原型，采用系统情节串联图版（systemstoryboarding）引导用户提出需求，记录用户与系统的交互操作方式，或者采用其它需求获取方法。,G.快速原型模型（RapidPrototypeModel）,建造/修改原型,用户测试运行原型,听取用户意见,原型范型,原型模型,分析定义系统需求,生成原型,系统设计,程序设计,编码,测试,运行和维护,原型化,含原型化的软件生存期,采用原型模型的软件生存周期,原型法的分类,原型是项目系统中的一个方面或者多个方面的工作模型。抛弃型原型：用于试验某些概念，试验完系统将无用处进化型原型：原型系统不断被开发和被修正，最终它变为一个真正的系统。,原型法的优点,从实践中学习(Learningbydoing)改善的沟通改善的用户参与使部分已知的需求清晰化展示描述的一致性和完整性可能可以减少文档减少了维护成本特征约束（利用工具构造原型可以将某些特性落到实处，而非在纸上写的那样容易失误）试验是否能产生期待的结果,原型法的缺点,用户有时误解了原型的角色，例如他们可能误解原形应该和真实系统一样可靠缺少项目标准，进化原型法有点像编码修正缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制额外的花费：研究结果表明构造一个原型可能需要10%额外花费运行效率可能会受影响原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。,从另外的角度看待原型,从中学到什么？学生经常会做一些软件作业，这些作业被称为原型，问题：这些原型和软件系统原型是否相同？但是作为一个原型必须：描述他们希望从中学到的东西，规划原型评价的方法，报告从原型中真正学到的内容。在不同的阶段，原型具有不同的作用。原型起作用的程度实物模型（Mock-ups）仿真交互部分模型：水平，垂直（某些特性构造详细原型）,H.演化模型,增量模型(IncrementalModel)螺旋模型(SprialModel),H.1增量模型(递增模型),先完成一个系统子集的开发，再按同样的开发步骤增加功能(系统子集),如此递增下去直至满足全部系统需求。系统的总体设计在初始子集设计阶段就应作出设想。,分析,设计,编码,测试,分析,设计,编码,测试,分析,设计,编码,测试,分析,设计,编码,测试,增量1,增量2,增量3,增量n,增量1交付客户,增量2交付客户,增量3交付客户,增量n交付客户,日历时间,.,H.1增量模型,风险分析,工程实施,用户通信,用户评估,产品维护项目,产品增强项目,新产品开发项目,概念开发项目,计划,建造及发布,H.2螺旋模型,螺旋模型的优缺点,优势：随着迭代的增加（成本的增加），风险程度随之降低缺陷：比较复杂，需要责任心，专注和管理方面的知识。,H.3WIN-WIN螺旋模型,在螺旋模型中，通过与客户的通信获取客户的需求，实际上，客户的需求与最终确定的需求是不一致的，客户与开发者之间需要进行协商，最终达到双赢的局面。Boehm提出的WIN-WIN螺旋模型中，客户与开发者之间需要识别系统或子系统的关键stakeholders确定涉及者的“winconditions”对这些条件进行协商获得互赢条件,WIN-WIN螺旋模型,WIN-WIN螺旋模型还引入了三个过程的里程碑，被称为定位点（Anchorpoints）生命周期目标（lifecycleobjectives）:定义每个主要活动的目标生命周期体系结构（lifecyclearchitecture）:定义系统和软件的体系结构目标初步操作能力（initialoperationalcapability）:定义软件安装，发布目标。,I.并行开发模型,并行开发模型（concurrentdevelopmentmodel）又被称为并行工程（concurrentengineering）（ByDavisandSitaram）软件开发中的所有活动可能同时并存，但是都处于不同状态中并行开发模型定义了活动从一个状态转化为另一个状态的事件,并行开发模型,None,Awaitingchanges,Underrevision,Underreview,Baselined,Done,Underdevelopment,Analysisactivity,并行开发模型,并行过程模型经常被用于开发C/S系统。该系统的活动可以被分为系统维和部件维。系统维:包含设计，装配和使用三个活动部件维:包含设计和实现两个活动并发性表现在两个方面：系统和部件的活动同时发生各个部件可以并行设计和开发,“基于版本发布”的特点,V1.0,功能,时间,V2.0,V1.1,Trade-offDecision(折中决定),可靠性,发布日期,功能,最优,约束范围,可接受,正确的Trade-off决定,J.面向对象模型,喷泉模型(FountainModel)可重用部件组装模型(构件集成模型ComponentIntegrationModel),分析,设计,实现,测试,集成,演化,J.1喷泉模型,喷泉模型特点,主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征,J.2可重用部件组装模型(构件集成模型),使用重用技术的软件工程模型构件(components)：可重用的软件成份可复用性（Reusability）集成化软件开发环境（ISEE）,用户通信,计划,产品开发及发布,用户评估,风险分析,标志候选构件,查找构件,若存在则提取构件,若不存在则构造构件,进行下一次迭代,将新构件存入库中,可重用部件组装模型,基于构件的软件工程(CBSE)过程模型,构件开发分析设计编程测试,领域分析,系统测试,构件提交,领域专家经验,现有系统资料,领域构件需求,构件/构架库,领域构架,领域构件,系统开发,系统专用构件,应用系统,构件生产线,领域构架,领域构件,问题域,用户需求,系统生产线,系统组装分析设计编程,构架细化,专用构件开发分析设计编程测试,软件生产线,转换模型(TransformationalModel)净室模型(CleanroomModel),K.形式化方法模型,K.1转换模型,形式化规格说明,与需求比较后修正,形式化开发记录,变换n,变换2,变换1,测试,系统需求,目标系统,形式化规格语言及其变换技术,基于模型的规格说明及其变换技术基于代数结构及其变换技术基于时序逻辑的规格说明和验证技术基于可视形式化技术,K.2净室模型(形式化的增量开发模型),基于思想：力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或“洁净”的状态下实现软件的制作。三个关键技术置于统计过程控制之下的增量开发基于函数的规范、设计、验证统计测试和软件认证,净室模型,L.阶段交付,阶段交付持续地在确定的阶段向用户展示软件。和渐进原型不同，在阶段交付的时候，你明确地知道下一步要完成什么工作。阶段交付的特点是不会在项目结束的时候一下交付全部软件，而是在项目整个开发过程中持续不断地交付阶段性成果。,阶段交付,软件概念,需求分析,构架设计,阶段1：详细设计，编码，调试，,阶段2：详细设计，编码，调试，,阶段交付的优缺点,优点：项目结束交付全部成果前，分阶段将有用的功能交付给用户。缺点：如果管理层面和技术层面上缺乏仔细规划，工作就无法进行。使用阶段交付的注意点：必须确定每一阶段的交付是对用户有用的必须确保考虑了不同产品组成部分的技术依赖关系,M.面向进度的设计,类似于阶段交付，但是面向进度的设计生命周期模型在开始的时候不必知道究竟能达到何目标，但是要确保最后的期限。该模型的关键是要按优先级别划分系统特性并规划开发阶段，保证前面的阶段具有高优先级的特性，低特性具有低优先级别。是否采用这种方法决定于你是否对系统目标具有足够的信心，如果有信心，则没必要采用这种方法。,N.渐进交付,渐进交付是一种跨越了渐进原型和阶段交付两种模型的过程模型。基本过程：开发一个产品的版本，展示给用户，根据反馈改善产品。如果计划满足用户的绝大部分需求，渐进交付与渐进原型差不多，如果计划满足少量的需求，渐进交付就和阶段交付差不多。渐进原型，强调的是系统看得见的样子，再回来堵漏洞，渐进交付中，最初的重点是系统核心和底层系统功能。,渐进交付,软件概念,需求分析,构架和内核设计,开发一个版本,并入用户反馈,交付该版本,开发一个版本,交付最终版本,确定渐进交付目标的一种方法,价值成本比,软件开发方法,软件开发过程遵循的方法和步骤几种典型的开发方法：模块化方法（modularmethod）结构化方法面向数据结构方法面向对象方法,软件开发需要项目管理,软件开发是个系统工程需要资源的协调软件开发过程的选择与项目的协调紧密相关,项目管理、工具、技术、流程与组织,主要内容,回顾软件项目实施的方法选择软件开发过程模型的选择软件开发方法项目管理项目管理基本概念实施项目管理的工具与技术项目管理的流程项目管理的流程特征（产品项目软件项目）项目管理组织结构软件项目管理的流程,建立不现实的最终期限,不断变更的客户需求,对努力的低估,可预见和不可预见的风险,技术的困难性,项目成员的沟通不畅通,项目管理不利,为什么项目会失败?,People项目成功的最重要因素Product建立的软件Process框架活动集合和得到工作的软件工程任务Project实现产品所需要的所有工作,The4Ps,软件梯队,被解决问题的难易程度代码和功能点形成的结果程序的规模梯队的生存周期问题被模块化的程度被建立系统所需要的质量和可靠性发布日期的严格性项目的社会化程度（沟通程度）,选择软件项目梯队结构所要考虑的因素.,建立范围陈述性描述，约束问题表达分解建立功能性分割,问题定义,发现项目的关键,系统为什么被开发?做什么?什么时候?谁对某一功能负责?他们组织定位在哪里?从技术和管理上工作怎样被做?多少资源需要(e.g.,人,软件,工具,数据库)?,BarryBoehm,形式的风险分析经验成本和进度估算基于度量的项目管理价值跟踪（Earnedvaluetracking）质量目标下的跟踪人要意识到项目管理,关键实践,什么是项目,项目是什么没有例行的任务需要计划特定的目标需要满足或者特定的产品需要生成项目有一个预定义的时间范围工作不仅仅是为自己，也是为他人工作中有些特性工作分为若干阶段项目完成需要资源项目是大型的或者复杂的,什么是项目管理,项目管理是在项目活动中应用知识，技能，工具和技术来满足项目需求的过程，它通过初始化，计划，执行，控制和结束等活动来完成。,项目生命周期,项目生命周期定义一个项目的开始与结束。项目生命周期定义的阶段顺序通常包括某些技术转移或“握手”(handoff)，如从需求到设计，从构造到运行，但是在风险允许下，也可以下一阶段提前进行，这种重叠的阶段被称为快速跟踪(fasttracking)。项目生命周期通常定义：各个阶段需要完成的技术工作；每个阶段需要涉及的人。,项目生命周期,绝大多数项目生命周期有一些共同的特点，如成本和人员消耗的变化曲线。项目生命周期与产品生命周期是不同的。,项目中的人员,项目影响者(stakeholders)项目小组内部：项目小组外部，但是在同一组织内：项目小组和组织外部：如客户不同的项目影响者有不同的目标，因而项目领导者需要能够协调这些目标。Boehm和Ross提出软件项目管理的“W理论”，该理论关注于所有各方都能从项目种获益因而对项目的成功都有兴趣。（W代表EveryoneaWinner）,软件项目管理定义,软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。,软件项目包含的活动,需求分析描述设计编码校验安装维护支持,应用项目管理方法开展软件开发,项目的可行性分析需求开发与需求管理软件项目工作量估算软件项目计划与资源分配软件项目监控风险管理软件质量管理与软件开发规范软件项目中的人员管理软件配置管理,项目可行性分析与评估,内容安排,可行性分析的内容项目范围管理技术评估经济评估风险评估可行性报告项目建议书需求建议书,可行性分析,目的“说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性；评述为合理地达到开发目标可能选择的各种方案”。GPS监控系统的投资失误做什么？近期目标？人员配备，怎样整合需求调研问题开发费用问题风险规避顶新国际集团：在投资新产品时1400万：全国28个城镇居民消费习惯调查700万：委托28个城镇社会科学院进行全国七大区域总体经济投资环境的分析任务了解客户要求及现实环境，从技术、经济和社会因素研究并论证软件项目可行性，编写可行性报告，制定初步项目开发计划“什么都不做”永远是一个可考虑的方案,可行性分析的内容,项目范围策略评估技术评估经济评估风险评估,项目范围管理内容,保证项目包括并且仅仅包括需要包括的内容。它由以下步骤组成：初始化：对项目或阶段授权范围计划：开发一个作为将来项目决策基础的书面的范围声明范围定义：将项目交付物细分为更小的，更易管理的元件范围校验：形式化项目范围的接受条件范围变更控制：控制项目范围的变更,范围的含义,“范围”包含产品范围和项目范围产品范围：产品或服务的特点和功能项目范围：为了生产具有特定特点和功能的产品所需要的工作,软件范围,软件项目计划的第一项任务就是确定软件的工作范围，即软件的用途及对软件的要求。因此，应从管理角度和技术角度出发，确定明确的可理解的软件项目范围。,软件范围的叙述,明确给出定量的数据（例如，同时使用该软件的用户数目，发送表格的长短，最大允许响应时间等）指明约束条件和/或限制（例如，产品成本限制了存储的容量）叙述某些质量因素（例如，给出的算法是否容易理解、是否使用Ada语言等）,软件范围的估计,软件范围包括功能、性能、限制、接口和可靠性。功能：软件功能评价，并进行适当细化功能分解，满足未来成本和进度估算要求性能包括处理和响应时间的需求。约束条件：外部硬件、可用存储或其他现有系统对软件限制。功能、性能和约束必须在一起进行评价。当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级。如果功能保持相同而性能可变，则开发软件所需的工作量和成本将有显著的差异。,价值驱动的电子商务分析方法,业务流程模型,业务概念模型,策略,规划级,结构级,实施级,电子商务技术层,业务策略的概念结构,概念建模,协商建模,价值驱动流程建模,电子商务概念模型,初始化,初始化(Initiation)正式授权一个新项目或者决定一个已有项目继续进行下一阶段项目是由于下面一些原因产生的：市场需要（新性能汽车）业务需要（培训中心新课程设计）客户需要（客户定制产品）技术进步（如计算机技术进步）法规需要（污染处理）社会需要（政府水处理系统）,初始化,输入：产品描述策略计划：企业的战略计划项目选择准则（经济回报，市场回报，公共形象）历史信息：以前项目的结果和性能工具和技术项目选择方法专家判断输出：项目章程（授权项目的正式文档，包括业务需求，产品描述）项目经理指派约束假设,范围计划,范围计划是将生成产品的项目工作（项目范围）逐步细化的过程。输入：产品描述项目章程约束假设工具和技术产品分析利益成本分析(Benefit/CostAnalysis)备选方案（brainstormingorlateralthinking)专家判断,范围计划,输出范围声明（ScopeStatement)，包括项目理由：ProjectJustification(Businessneed)项目产品:概述项目交付物：projectdeliverables项目目标:判断项目是否成功的定量准则支持细节（包括假设和约束）范围管理计划,范围定义,范围定义涉及到将主要的项目交付物细分以：提高成本，周期和资源估计的准确性定义性能度量和控制的基线便于清晰定义责任分配范围定义正确与否将影响项目的节奏，进度，生产率和项目人员的士气。,范围定义,输入范围声明约束假设其它计划输出历史信息工具和技术WBS(Workbreakdownstructure)模板分解技术,策略评估中的模块管理,模块管理（Programmmanagement)“模块是一组协调管理的项目，通过将项目组成模块，将获得比单个管理项目更大的效益。”D.C.Ferns有效的模块管理需要有一个模块目标，项目必须根据模块目标来选择在大的组织中，将可能有模块管理的机构，例如模块主管或者模块经理即使没有专门的组织来管理模块，项目的选择也需要根据组织的整个业务目标来评价,策略评估的内容,目标：提出的系统对组织目标具有怎样的贡献？例如它是否能够增加市场份额？IS计划：提出的系统如何与IS计划相适应？它将替换或者与那些系统接口？它与将来开发的系统有何交互关系？组织结构：新系统对目前的部门和组织结构有何影响？例如一个新的订单处理系统是否与目前的销售与库存控制的功能相重叠？MIS:系统将在组织的何层次上提供何种信息？它将以何种方式对现存管理信息系统进行补充何提高？人员：系统将以何种方式影响人力水平何现存雇员的技术？它对组织整个人员开发策略有何影响？情形：系统将使客户对组织的态度有何变化？是否采用一个自动化的系统将与提供友好的服务相冲突？,策略评估中的业务管理,业务管理选定的项目将成为业务的一部分，项目将对资源产生竞争竞争中对业务的调整是必要的,技术评估,技术的成熟程度实验室技术经过中试的技术已经工业化应用的技术市场需求显在潜在：转化为显在的条件竞争态势：与竞争技术相比，所采用技术的优势及缺陷技术转换成本支撑体系与条件：原料、销售网络、用户体系、政策技术发展趋势及所采用技术的发展前景,技术方案选择,要考虑的制约条件需求制约：现存的需求结构及需求结构可能的变化资源制约：资金、人力资源、自然资源、其它要素环境制约：经济技术环境、社会文化环境、自然环境选择原则经济性原则：以最小的投入取得最好的效果发展原则：发展的前景及适应发展的能力兼容性原则：与原有经济、技术、环境、社会的兼容性相关效果原则：相关的经济、技术、环境、社会效果选择视角技术先进性技术适用性,经济分析,开发所需要的成本和系统运行所需要的成本与得到的效益的比较识别出项目进行中所需要的所有成本和效益并对其进行聚集将成本和效益用单元来表达成本分为开发成本安装成本运行成本,经济分析,效益直接效益可见的间接效益不可见的效益,经济分析,净收益（NetProfit):项目的净收益是在项目生命周期内总的收入与总的成本的差。没有考虑时间因素回收期限（PaybackPeriod）：将初始投资收回的期限忽略了整个项目的盈利空间,经济分析,投资回报(Returnoninvestment):也被称为回报率(accountingrateofreturn)(ARR)ROI=（平均年收益/总投资）100例如项目1：ROI=10,000/100,000*100=10%缺点：没有考虑时间因素该回报率易与银行利率混淆,经济分析,净现率(NetPresentValue)考虑了时间因素对将来的收益打一个折扣“拿在手里的钱才是真正的钱”如果假定年折扣率为10，那么明年的100元等于现在手中的91元，后年的100元等于现在的83元目前值t年的值/(1+r)t,系统开发和每年运行费用举例,1.系统开发费用（一次）人员：.2名系统分析员(450小时/名,45美元/小时)$40,500.5名系统开发人员(275小时/名,36美元/小时)$49,500.1名数据通讯专家(60小时/名,42美元/小时)$2,400.1名数据库管理员(30小时/名,42美元/小时)$1,260.2名技术写作者(120小时/名,25美元/小时)$6,000.1名秘书(160小时/名,15美元/小时)$2,400.2名在转换期间数据输入人员$49,500(40小时/名,12美元/小时),系统开发和每年运行费用举例,培训：三天的开发人员内部培训课程$7,00030个用户，三天的内部培训课程$10,000物资：复印$500磁盘、纸张等消耗品$650,系统开发和每年运行费用举例,购买硬件、软件：20台工作站Windows软件$1,00020台工作站内存升级$8,000网络软件$17,50020台工作站办公软件产品$20,000系统开发总费用$161,670,系统开发和每年运行费用举例,2.年运行费用（每年）人员：维护程序员/分析员(250小时/年,42美元/小时)$10,500网络管理员(300小时/年,50美元/小时)$15,000购买硬件、软件升级：硬件$5,000软件$6,000物资和杂项$3,500每年总运行费用$40,000,可行性研究的步骤,(1)复查确认系统目标、规模(2)研究正使用系统工作流程(3)导出新系统高层逻辑模型(4)重新定义问题(5)导出和评价供选择的方案(6)推荐可行的方案(7)草拟开发计划(8)编写可行性研究报告，送审,可行性分析,可行性分析报告的格式,可行性研究报告的编写提示GB8567-88计算机软件产品开发文件编制指南,1引言1.1编写目的1.2背景1.3定义1.4参考资料,可行性研究报告的编写提示,2可行性研究的前提2.1要求2.2目标2.3条件、假定和限制2.4进行可行性研究的方法2.5评价尺度,可行性研究报告的编写提示,3对现有系统的分析3.1数据流程和处理流程3.2工作负荷3.3费用开支3.4人员3.5设备3.6局限性,可行性研究报告的编写提示,4所建议的系统4.1对所建议系统的说明4.2数据流程和处理流程4.3改进之处4.4影响4.5局限性4.6技术条件方面的可行性,可行性研究报告的编写提示,5可选择的其它系统方案5.1可选择的其它系统15.2可选择的其它系统2.,可行性研究报告的编写提示,6投资及收益分析6.1支出6.2收益6.3收益/投资比6.4投资回收周期6.5敏感性分析,可行性研究报告的编写提示,7社会条件方面的可行性7.1法律方面的可行性7.2使用方面的可行性,项目建议书,起源：组织内部认识到需要利用信息技术改进目前的业务运行改进目前的信息系统开发新的产品目的：使管理层能够作出项目决策,准备招标书,目的：从客户的角度全面地、详细的论述，为了达成确定的需求应需要作何准备一份招标书应当是全面的，能提供足够详细的信息，以使承约商或项目团队能针对顾客的需要相应地准备一份最优的招标书,招标书,招标书中需要提供工作表述招标书中必须包括客户要求，此要求中规定了规格和特征招标书应当说明客户期望承约商或项目团队提供什么样的交付物招标书中应当列举客户供应条款招标书中可以表述出客户对需要的确认招标书中可以提到客户想要用的合同类型,招标书,表述出客户想用的付款方式表述出项目完成所需的进度计划提供有关承约商申请书的格式和内容安排支持客户希望潜在承约商提交申请书的最后期限可能包括评价标准可能会指出客户所拥有的可用于此项目的资金量。,案例分析,宁波市第五次全国人口普查办公室的宁波市人口地理信息系统地理空间分析、人口统计与分析一体化宁波人口普查、日常管理、统计与分析的数字化、可视化人口信息存储、管理与分析，建立规范化的空间地理信息与人口信息统一管理、分析、统计、发布、录入、更新与维护对空间数据和人口数据的快速采集、建库、维护、查询、管理、显示、输出、统计分析、共享与发布功能,案例分析,性能要求满足宁波全部市县人口的数据存储不同县区都可以调用数据，操作数据保证调查高峰操作响应的人机交互保证数据统计的响应时间,案例分析,限制要求Windows平台客户端服务器选用Intel服务器存储RAID，保证存储安全与DOMINO办公系统可以实现接口，可以抽取数据报表,需求开发与需求管理,主要内容,从一个故事看软件开发的实际问题需求管理的困难性管理需求的目的软件需求特性需求工程如何获取需求需求规格说明需求管理工具,软件开发面临的实际问题,软件开发面临的实际问题,软件开发面临的实际问题,为什么？,需求？,什么是需求,需求为用户解决问题或达到目标所需的条件或权能系统或系统部件要满足合同、标准、规范和其它正式规定文档所需具有的条件或权能一种反映上述条件或权能的文档说明,举例,系统必须提供基于PPPoE协议的用户接入模式产品应当提供机架式安装，并提供两个千兆以太网端口系统使用的用户是信息中心和网络管理员系统在运行时必须提供自动数据备份功能,简要的解释,需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整文档，该文档详细地说明了产品“必须或应当”做什么。如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。,需求管理的困难性,需求不总是显而易见的，而且它可来自各个方面。需求并不总是能容易用文字明白无误地表达。存在不同种类的需求，其详细程度各不相同。如果不加以控制，需求的数量将难以管理。需求之间相互关联，而且需求也和软件工程流程中的其他可交付工件有关。需求有唯一的特征或特征值。例如，它们的重要性和容易满足的程度都各不相同。需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。需求会变更。,为什么要管理需求,为什么要管理需求？避免失败就是一个很充分的理由。提高项目的成功率需求管理带来其他好处StandishGroup的CHAOS报告进一步证实了与成功项目关系最大的因素是良好的需求管理。,什么是软件需求,从软件开发过程看软件需求开发,从软件发展周期看软件开发过程,计算机系统,人员,硬件,软件,数据,传输机构,执行机构,（剧作家、导演）,（舞台,剧本,演员,道具）,软件开发全过程,活动任务,系统需求分析系统结构设计软件需求分析建立软件需求评价软件需求联合评审软件结构设计软件详细设计软件编码和测试软件集成软件鉴定测试系统集成系统鉴定测试软件安装软件验收支持,软件开发过程,定义（IEEE-STD-610）用户为解决某个问题、或为实现某一目标，要求软件必须满足的条件或能力。软件需求的三个层次业务需求用户需求功能需求和非功能需求,软件需求的层次性,软件系统需求(1),系统需求,分配,软件工程组,硬件系统需求(2),其它成分系统需求(n),软件需求,客户,最终用户,系统工程组,系统需求分配,业务需求,业务说明,使用实例,用户需求,功能需求,约束条件,非功能需求,软件需求规格说明,软件需求的层次,需求的层次性,项目视图与范围文档,其它非功能需求,UseCase文档,软件需求规格说明,非功能需求,过程需求：交付需求，实现需求，遵循的标准性能需求：速度，容量，可靠性外部需求：互操作性，伦理性，机密性，安全性，使用要求,非功能软件需求,系统需求ACCS应能使汽车保持在预期车速的2KMH范围内行驶,分配给硬件的需求硬件应能使车速在规定的精确度1.5KMH范围内,分配给软件的需求软件应能在车速超出预期车速0.5KMH时给硬件加/减速命令,软件需求软件应能：读入当前车速值计算当前车速与预期车速之差若差值0.5KMH给出加/减速命令,汽车限速系统ACCS的需求分配,分配需求的实例,产生不合格需求的原因,产生不合格的需求说明的原因无足够的用户参与，原因感到与用户合作不如编写代码有意思因为开发人员觉得已经明白用户的需求了用户需求的不断增加模棱两可的需求不必要的特性过于精简的规格说明忽略了用户分类不准确的计划,优秀需求具有的特性,正确性无二义性必要性完整性，完备性可行性，可实现性可验证性划分优先级,制定目标的原则,SMARTSpecial,Measure,Agree,Realistic,Time特指,可量测,一致认同感,现实的,实在的,时间,需求工程,什么是需求工程把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程的结构图,1需求工程需求开发需求管理,获取需求,分析需求,定义需求,验证需求,需求变更控制,需求跟踪,需求状态跟踪,需求文档版本控制,需求开发,需求管理,需求工程,需求工程的构成,需求开发过程,需求开发：通过调查与分析，获取用户需求并定义产品需求。需求调查：通过各种途径获取用户需求信息（原始材料），产生用户需求说明书。需求分析：对各种需求信息进行分析，消除错误，刻画细节。常见分析方法“问答分析法”和“建模分析法”两类。需求定义：根据需求调查和需求分析结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。,需求管理过程,需求管理：在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求确认：开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求跟踪：通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更控制：依据“变更申请审批更改重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。,用户/系统,市场,管理者,初始需求,变更的需求,获取,分析,定义,验证需求,控制需求变更,需求规格说明,项目环境,需求开发,需求管理,（1）获取需求确定目标用户、服务对象明确用户代表用户培训了解实际业务和业务需求（2）分析需求分清功能需求、性能需求、使用需求必要性可行性,需求开发,（3）定义需求编写软件需求规格说明（SRS）作用要求：完整、正确、可行