软件工程案例分析

《软件工程案例分析》由会员分享，可在线阅读，更多相关《软件工程案例分析（450页珍藏版）》请在装配图网上搜索。

1、,*,单击此处编辑母版标题样式,,单击此处编辑母版文本样式,,第二级,,第三级,,第四级,,第五级,,软件工程案例分析,陈天洲,,浙江大学计算机学院,,软件特征（1）,最根本的：软件是一种逻辑元素而不是物理元素,,软件是开发出的，而不是用传统的方法制造出来的,,软件不会被用坏,,时间,失败概率,一般产品的浴盆曲线,,软件特征（2）,时间,失败,,概率,软件失败概率实际曲线,软件失败概率理想曲线,,软件特征（3）,工业界已经走向了标准化装配时代，然而绝大多数软件还是定制出来的。,,科学计算函数库（60年代）,,重用数据结构,,重用组件,,,,成本结构发生了巨大的变化,一次性的制造成本,,介质成本

2、的可忽略性－,逻辑产品,,不可回逆的投入,,维护成本的增加,,服务是质量要素中的重点,,,软件危机,“软件危机” 是1958年在NATO会议上作为一个正式的议题被提出来,,软件项目不成功的例子比比即是：,,1999 年 10 月，耗资 1.25 亿美元的 NASA 的火星气象卫星失踪（公,英制转换）,,软件危机,一些数据：,,大约,70％,的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间,20％到50％,，,90％,以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高,,美国政府审计局：只有不到2％的合同定购软件在发布时具有可用性——,98％以上的项目都失败了,,软

3、件危机,一种看法,,“,两难境地（Crunch Mode）,”：处于两难境地的项目面临无法达到最初目标的威胁（费用、进度表、功能性等），而项目团队努力想跨越困境。,,“我们正处于两难境地，在半夜之前是不会回家”,,“,死亡行军（Death March）,”：用来描述其进度表几乎不可能完成的项目。,,“这是一个死亡行军项目，我希望自己不要参与进去”,,软件危机,更准确的说法：,慢性痛苦,（chronic affliction) Suggested by Prof. Daniel Tiechrow, University of Michigan,,尽管忍受痛苦，但是软件依然在我们这个世界起着越来

4、越重要的作用，但是如果能够医治痛苦，那么软件业将发展得更加健康。,,软件危机的主要特征,软件开发周期大大超过规定日期;,,软件开发成本严重超标;,,软件质量难于保证,,,软件成功的标准,用户在,用,,用户可很,容易,做完要做的事,,,失败的根本原因：,,开发人员写出的东西达不到,,用户要求,(,人的问题,.,技术问题,),,规模,,复杂性,,生产率,软件技术面临的问题,,,Exchange2000,Windows,2000,项目经理,25人,约250人,开发人员,140人,约1700人,测试人员,350人,约3200人,例:,•,Windows95有1000万行代码,,,•,Windows20

5、00有5000万行代码，,,3000多个工程师，几百个小团队。,,,Exchange2000和 Windows2000开发人员结构,,“软件工程案例分析”课程,与其它软件专业课的区别,(1) 立足于系统的整体。,,(2) 系统分析、系统设计、,,测试及维护的方法实践。,,(3) 构筑一个软件系统，实践,,软件开发全过程。,,用户,分析员,程序员,系统分析员的地位,,“一个好的工业，应有一套良好的标准来配套”,软件工业化生产过程应具备的特点,,明确的工作步骤,,详细具体的规范化文档,,明确的质量评价标准,,,软件产品的标准化,软件开发过程的标准化,,软件工程技术的两个明显特点,,强调规范化,,

6、强调文档化,,新世纪软件产业的趋势,网络化趋势：,计算机与通信的融合趋势,,万维网,智能网络,,服务化趋势：,“打包式”软件,,“服务式”软件,,全球化趋势,,中国软件产业发展主要问题,,产业规模小、集中度低,,产业竞争力弱，缺乏核心技术,,市场秩序较为混乱，盗版严重,,制约软件产业发展的因素,软件开发规范与标准,,知识产权环境,,知识结构,,公司体制,,项目与项目管理,项目是什么,,没有例行的任务,,需要计划,,特定的目标需要满足或者特定的产品需要生成,,项目有一个预定义的时间范围,,工作不仅仅是为自己，也是为他人,,工作中有些特性,,工作分为若干阶段,,项目完成需要资源,,项目是大型的

7、或者复杂的,,项目管理是什么,,项目管理是在项目活动中应用知识，技能，工具和技术来,满足项目需求,的,过程,，它通过初始化，计划，执行，控制和结束等,活动,来完成。,,软件项目与,软件项目管理,软件项目的特征,,不可见,,复杂性（以每一单位货币来看）,,灵活性：软件去适应人或组织而不是相反,,一致性,,软件项目管理,,为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。,,软件项目的活动,需求分析,,描述,,设计,,编码,,校验,,安装,,维护,,支持,,软件项目分类,按软件类别,,信息系统：与组织接口,,嵌入式系统：接口是机器,,操作

8、系统是一个信息系统还是嵌入式系统？,,有些项目是为了生成某一产品，而某些项目的进行是为了达到某些目标。许多软件项目分为两个阶段，第一阶段是,目标驱动,，第二阶段再生成真正的,软件产品,。,,从系统的角度看软件项目,一个项目关注于生成一个系统和/或将一个旧系统转换为一个新系统,,系统，子系统和环境,,开放和封闭系统,,项目失败的一个原因是技术人员不能够开放系统和立即接受外界的变化。,,部分优化,,例如：可能很高效，但是难于修改,,社会技术系统,,软件项目属于此类,,软件项目中的人员,项目影响者(stakeholders),,项目小组内部：,,项目小组外部，但是在同一组织内：,,项目小组和组织外部

9、：如客户,,不同的项目影响者有不同的目标，因而项目领导者需要能够协调这些目标。Boehm和Ross提出软件项目管理的,“W理论”,，该理论关注于所有各方都能从项目种获益因而对项目的成功都有兴趣。（W代表Everyone a Winner）,,软件开发面临的挑战,处理最终日期（deadlines）(85%),,处理资源约束（83％）,,与任务小组有效的沟通（80％）,,从小组成员处得到承诺（74％）,,建立可测量的milestone（90％）,,处理变化（60％）,,得到团队公认的项目计划（57％）,,从管理层得到承诺（45％）,,处理冲突（42％）管理销售商和子项目承包商（38％）,,项目经理

10、面临的挑战,估计和计划,,缺少质量标准和度量,,缺少组织决策的指南,,缺少使进度可视化的技术,,角色定义,,不正确的成功准则,,缺少标准,,项目成员面临的挑战,工作的不正确的描述,,IT的管理失误,,缺少应用领域的知识,,缺少及时的文档,,前续任务没有及时完成——包括设备没及时提供,,用户与技术员之间缺乏交流,,缺少质量控制,,软件环境的改变,,Deadline压力,,软件项目常见错误,选自《快速软件开发》,,产品相关的错误,,需求镀金：项目具有比实际需求多得多的性能,,功能蔓延：项目平均会有25%的需求变更（Jones 1994）,,开发人员的镀金：开发人员着迷于新技术,,又推又拉的交易：经

11、理在批准项目进度顺延时又加入了新的功能,,研究导向的开发,,软件项目常见错误（续）,过程中的错误,,缺乏计划,,过于乐观的计划,,在压力下放弃计划,,缺乏足够的风险管理,,承包人导致的失败,,在模糊的项目前期浪费时间,,前期活动不合要求,过程中的错误,,设计低劣,,缺少质量保证措施,,缺少管理控制,,太早和过于频繁的集成,,项目估算时遗漏必要的任务,,追赶计划,,鲁莽编码,,软件项目常见错误（续）,技术相关的错误,,银弹综合症: 过于相信以前没有采用过的技术的宣传,,过高估计了新技术或方法带来的节省量,,项目中间切换工具,,缺少自动的源代码控制手段,,,软件项目常见错误（续）,人员相关的错误,

12、,挫伤积极性,,人员素质低,,对有问题的员工失控,,英雄主义,,项目后期加入人员：“火上加油”,,办公环境差,,开发人员与客户之间发生摩擦,,不现实的预期,,软件项目常见错误（续）,缺乏有效的高层对项目的支持,,缺乏各种角色的齐心协力,,缺乏用户介入,,政治高于物质,,充满想像：“项目组没人真正相信他们能够按给定的计划进度完成项目，但他们认为如果每个人能够努力工作，并且不出现问题，他们可能会很幸运地按时完成任务。,,软件项目常见的错误,试分析以下故事中的项目所存在的错误：,,,一天，一位年青人被选来“写”一个用在自动化制造设备上的程序。选择他的理由很简单：他是技术小组中唯一参加过编程培训的人。

13、他懂得汇编语言和Fortran语言，但是他不知道软件工程，更不知道软件计划和跟踪方面的知识。,,软件开发过程模型选择,,主要内容,项目实施的方法选择问题,,识别项目中的高风险,,软件开发过程模型的选择,,可选择的模型,,软件开发项目过程的选择,,软件开发方法,,,项目实施的方法选择,技术选择,,技术选择将影响：,,开发人员的训练需要,,人员招聘,,开发环境——硬件和软件,,系统维护安排,,方法选择,,方法选择将影响：,,开发人员组合,,实施的进度安排,,开发策略选择,,项目实施的方法选择,步骤：,,分析目标驱动还是产品驱动,,分析项目其他特征,,面向数据还是面向控制,,通用还是专用,,是否需要

14、专用工具支持的专门技术,,是否有特殊的安全性要求,,对软硬件有何要求,,识别项目中的高风险,,产品不确定性,：,系统需求理解,的准确性。用户在开始时有可能对系统应该什么样都无法确定。在某些环境中，精确而有效的需求描述可能迅速变得过时。,,过程不确定性,：在项目开始时需要,选择方法或过程模型,，或者一种新的工具，任何对原先采用的开发方法的变化都将引入不确定性,,资源不确定性,：项目进行中,资源的数量,可能发生变化,,软件开发过程模型的选择,开发一个软件需要选择,开发策略,（包括过程，方法和工具）以及,通用阶段,，这些策略和阶段被称为,过程模型,,“过程”：相关联的活动,,过程模型的选择基于项目和

15、应用的特性，使用的工具和方法，所需要的控制方法和交付物。,,软件生存周期,(Software Life Cycle),,软件产品或软件系统从设计、投入使用到被淘汰的全过程,,软件生存期的阶段划分,,可行性研究与计划,,需求分析,,总体设计,,详细设计,,实现,,集成测试,,确认测试,,使用和维护,软件生存周期,《计算机软件开发规范》,上游,下游,,新的国际标准定义的软件生存过程（,1995 ISO/IEC 12207,）,软件生存期过程,支持过程,组织过程,主要过程,获,,取,,过,,程,供,,应,,过,,程,开,,发,,过,,程,运,,行,,过,,程,维,,护,,过,,程,文,,档,,

16、编,,制,,过,,程,配,,置,,管,,理,,过,,程,质,,量,,保,,证,,过,,程,验,,证,,过,,程,确,,认,,过,,程,联,,合,,评,,审,,过,,程,审,,核,,过,,程,问,,题,,解,,决,,过,,程,管,,理,,过,,程,基,,础,,设,,施,,过,,程,改,,进,,过,,程,培,,训,,过,,程,,,只考虑,,编写程序,,涉及整个,,软件生存,,周期,扩展到,软件工作的范围,,软件开发全部过程、活动和任务的,结构框架,。,,直观表达软件开发全过程,,明确规定要完成的主要,活动、任务和开发策略,,也称为：,,软件过程模型,,软件生存周期模型,,软件工程范型,软件开发模型

17、,,问题求解的一般过程,问题求解的一般过程,,,,,,,实际问题并不能简单划为四个阶段，各个阶段会在问题的不同层次上同时并存,,软件开发实际上是一个“混沌”（chaos）过程,问题定义,方案集成,技术开发,现状,,A.编码修正模型,Code and Fix,,Code like Hell(鲁莽编码),,从一个大致的想法开始工作，然后经过非正规的设计、编码、调试和测试方法，最后完成工作,可能有可能没有的规范,发布（可能）,,编码修正模型,好处：,,成本可能很低,,只需要很少的专业知识，任何写过程序的人都可以,,对于一些非常小的、开发完后就会很快丢弃的软件可以采用,,对于规模稍大的项目，采用这种模

18、型是很危险的,,B.瀑布模型（Waterfall Model,),所有过程模型的祖宗,,项目从开始到结束按照一定的顺序执行,,瀑布模型是,文档驱动,的，各个阶段不连续也不交叉,,B.,瀑布模型,,(,Waterfall Model,),可行性研究与计划,需求分析,设计,编码,运行维护,测试,定义,,阶段,开,,发,,阶,,段,维护阶段,适应场合？,,优缺点？,,瀑布模型的适用场合,有一个,稳定产品定义,和很,容易被理解的技术解决方案,时，纯瀑布模型特别合适,,对一个定义得很好的版本进行,维护,或将一个产品,移植平台,，瀑布模型也特别合适。,,纯瀑布模型能够,降低管理费用,，因为你可以预先完成所

19、有计划。,,对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以,用顺序方法处理问题,。,,在,质量需求高,于成本需求和进度需求的时候，它尤为出色。,,当开发队伍的,技术力量比较弱,或者缺乏经验时，瀑布模型更为适合。,,瀑布模型缺点,纯瀑布模型在项目开始时，在设计工作完成前和代码写出来前，,很难充分描述需求,。,,瀑布模型最主要问题是,缺乏灵活性,。必须在项目开始前说明全部需求。但这恰恰是非常困难的。,,按照传统瀑布模型开发软件的特点,阶段间具有顺序性和依赖性。,,推迟实现的观点。,,每个阶段必须完成规定的文档;,,每个阶段结束前完成文档审查,及早改正错误。,,C.瀑布模型变种：V

20、型模型,该方法是对瀑布模型的修正，强调了验证活动,可行性研究,用户需求,系统设计,程序设计,编 码,程序测试,系统测试,用户接受,评价,修正,,修正,,修正,,修正,,,D. 瀑布模型变种：生鱼片模型,把阶段重叠起来的瀑布模型,,起源于日本硬件开发模型（富士通—施乐）,软件概念,需求分析,架构设计,详细设计,编码和调试,系统测试,,生鱼片模型的特点和缺点,传统的瀑布模型,强调,阶段之间,最小,重叠,，而生鱼片模型,强调大幅度重叠,，即在需求分析完成之前就可以进行架构设计和部分详细设计,,纯瀑布模型强调在任意两个阶段交接时，,文档,从一个团队交给另一个,完全隔离,的团队，但是如果一个团队完成各

21、个阶段任务时，可以没有那么多,文档,。,,问题：缺点是什么？,,生鱼片模型因为阶段重叠，因而,里程碑不明确,，很难有效地进行过程跟踪和控制。,,E. 瀑布模型变种：具有子项目的瀑布模型,纯瀑布模型的问题：必须完成全部架构设计后才能进行详细设计，但是，整个系统中有些部分可能有些特殊性，可以有自己的步骤，即将这些部分划分为子项目。,,问题：该模型有何问题？,,这种方法的主要风险是,相关性,无法预料。,,F. 瀑布模型变种：能够降低风险的瀑布模型,纯瀑布模型：要求在开始,架构设计前,，必须,将用户的所有需求都搞清楚,，但是实际中是很困难的。,,可降低风险的瀑布模型是在顶端，即,需求分析和架构设计阶段

22、引入螺旋,以便降低风险。,,螺旋中，,先开发一个用户界面原型,，采用系统情节串联图版（system storyboarding）引导用户提出需求，记录用户与系统的交互操作方式，或者采用其它需求获取方法。,,G.快速原型模型（,Rapid Prototype Model,）,,建造/修改,,原型,用户测试,,运行原型,听取用,,户意见,原型范型,,原型模型,需求分析,原型开发,最终系统设计,原型评价,最终系统实现,用户,,反馈,,分析定义,,系统需求,生成,,原型,系统,,设计,程序,,设计,编码,测试,运 行,,和维护,原型化,含原型化的,,软件生存期,采用原型模型的软件生存周期,,原型法的

23、分类,原型是项目系统中的一个方面或者多个方面的工作模型。,,抛弃型原型,：用于试验某些概念，试验完系统将无用处,,进化型原型,：原型系统不断被开发和被修正，最终它变为一个真正的系统。,,原型法的优点,从实践中学习(Learning by doing),,改善的沟通,,改善的用户参与,,使部分已知的需求清晰化,,展示描述的一致性和完整性,,可能可以减少文档,,减少了维护成本,,特征约束（利用工具构造原型可以将某些特性落到实处，而非在纸上写的那样容易失误）,,试验是否能产生期待的结果,,原型法的缺点,用户有时误解了原型的角色，例如他们可能误解原形应该和真实系统一样可靠,,缺少项目标准，进化原型法有

24、点像编码修正,,缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制,,额外的花费：研究结果表明构造一个原型可能需要10%额外花费,,运行效率可能会受影响,,原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。,,从另外的角度看待原型,从中学到什么？,,学生经常会做一些软件作业，这些作业被称为原型，,,问题：这些原型和软件系统原型是否相同？,,但是作为一个原型必须：描述他们希望从中学到的东西，规划原型评价的方法，报告从原型中真正学到的内容。,,在不同的阶段，原型具有不同的作用。,,原型起作用的程度,,实物模型（Mock-ups）,,仿真交互,,部分模型：水平，垂直（某些

25、特性构造详细原型,）,,H.演化模型,增量模型(Incremental Model),,,螺旋模型(Sprial Model),,H.1 增量模型(递增模型),先完成一个系统子集的开发，再按同样的开发步骤增加功能 (系统子集),如此递增下去直至满足全部系统需求。,,系统的总体设计在初始子集设计阶段就应作出设想。,,分析,设计,编码,测试,分析,设计,编码,测试,分析,设计,编码,测试,分析,设计,编码,测试,增量1,增量2,增量3,增量n,增量1,,交付客户,增量2,,交付客户,增量3,,交付客户,增量n,,交付客户,日历时间,…..,H.1 增量模型,,风险,,分析,工程,,实施,用户通

26、信,用户,,评估,产品维护项目,产品增强项目,新产品开发项目,概念开发项目,计划,建造及发布,H.2 螺旋模型,,螺旋模型的优缺点,优势：随着迭代的增加（成本的增加），风险程度随之降低,,缺陷：比较复杂，需要责任心，专注和管理方面的知识。,,H.3,,WIN-WIN螺旋模型,在螺旋模型中，通过与客户的通信获取客户的需求，实际上，客户的需求与最终确定的需求是不一致的，客户与开发者之间需要进行协商，最终达到双赢的局面。,,Boehm提出的WIN-WIN螺旋模型中，客户与开发者之间需要,,识别系统或子系统的关键stakeholders,,确定涉及者的“win conditions”,,对这些条件进行

27、协商获得互赢条件,,WIN-WIN螺旋模型,WIN-WIN螺旋模型还引入了三个过程的里程碑，被称为定位点（Anchor points）,,生命周期目标（life cycle objectives）:定义每个主要活动的目标,,生命周期体系结构（life cycle architecture）:定义系统和软件的体系结构目标,,初步操作能力（initial operational capability）:定义软件安装，发布目标。,,I. 并行开发模型,并行开发模型（concurrent development model）又被称为并行工程（concurrent engineering）（By Dav

28、is and Sitaram）,,软件开发中的所有活动可能,同时并存,，但是都处于不同状态中,,并行开发模型定义了活动从一个状态转化为另一个状态的事件,,并行开发模型,None,Awaiting changes,Under revision,Under review,Baselined,Done,Under development,Analysis activity,,并行开发模型,并行过程模型经常被用于开发C/S系统。该系统的活动可以被分为系统维和部件维。,,系统维:包含设计，装配和使用三个活动,,部件维:包含设计和实现两个活动,,并发性表现在两个方面：,,系统和部件的活动同时发生,,各个部

29、件可以并行设计和开发,,“基于版本发布”的特点,V,1.0,功,,能,时间,,,,V,2.0,V,1.1,,Trade-off Decision,(,折中决定,),,√,,√,,,,,√,,可 靠 性,发布日期,,功 能,,最优,约束范围,可接受,正确的,Trade-off,决定,,J. 面向对象模型,喷泉模型(Fountain Model),,可重用部件组装模型 (构件集成模型 Component Integration Model),,分析,设计,,实现,测试,集成,演化,J.1 喷泉模型,,喷泉模型特点,主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征,,

30、J.2 可重用部件组装模型,(构件集成模型),使用重用技术的软件工程模型,,构件,(,components),：,可重用的软件成份,,可复用性,（,Reusability,）,,集成化软件开发环境,（,ISEE,）,,用户,,通信,计划,产品开发及发布,用户,,评估,风险,,分析,标志候,,选构件,查找,,构件,若存在则,,提取构件,若不存在则,,构造构件,进行下,,一次迭代,将新构件,,存入库中,可重用部件组装模型,,基于构件的软件工程(CBSE)过程模型,,构 件 开 发,,分析 设计 编程 测试,领域分析,系统,,测试,构件提交,领域专家经验,现有系统资料,领域构,,件需求,构件/

31、构架库,领域构架,领,,域,,构,,件,,,系统,,开发,系统专用构件,应用,,系统,构件生产线,领域构架,领域构件,问题域,用户需求,系统生产线,系 统 组 装,,分析 设计 编程,构架细化,专,,用,,构 件,,开,,发,,分析 设计 编程 测试,,软件生产线,应用构件,,提取车间,构件生,,产车间,标准规范 与 质量保证,1,基础构件，,2,功能构件,,3,接口构件，,4,用户界面构件,应用,,构件库,构件库,组装,,车间,领域,,1,领域,,2,应用,,系统,...,1,2,3,4,,转换,模型,(,Transformational Mo

32、del,),,,净室模型,(,Cleanroom,Model,),K.形式化方法模型,,K.1 转换模型,形式化,,规格说明,与需求比,,较后修正,,形式化开发记录,变换,n,变换,2,变换,1,测试,系统需求,目标系统,,形式化规格语言及其变换技术,基于模型的规格说明及其变换技术,,基于代数结构及其变换技术,,基于时序逻辑的规格说明和验证技术,,基于可视形式化技术,,K.2 净室模型(形式化的增量开发模型),基于思想,：,,力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或“洁净”的状态下实现软件的制作。,,三个关键技术,,置于统计过程控制之下的增量开发,,基于函数的规范、设计、验证,

33、,统计测试和软件认证,,净室模型,盒结构,,规约,需求,,收集,形式化,,设计,正确性,,验证,代码,,检查,测试计划,统计性,,使用测,,试,验证,增量 #1,盒结构,,规约,需求,,收集,形式化,,设计,正确性,,验证,代码,,检查,测试计划,统计性,,使用测,,试,验证,增量 #2,盒结构,,规约,需求,,收集,形式化,,设计,正确性,,验证,代码,,检查,测试计划,统计性,,使用测,,试,验证,增量 #1,.,,.,,.,.,,.,,.,.,,.,,.,.,,.,,.,,L. 阶段交付,阶段交付持续地在确定的阶段向用户展示软件。,,和渐进原型不同，在阶段交付的时候，你

34、明确地知道下一步要完成什么工作。阶段交付的特点是不会在项目结束的时候一下交付全部软件，而是在项目整个开发过程中持续不断地交付阶段性成果。,,阶段交付,软件概念,需求分析,构架设计,阶段1：详细设计，编码，调试，……,阶段2：详细设计，编码，调试，……,,阶段交付的优缺点,优点：项目结束交付全部成果前，分阶段将有用的功能交付给用户。,,缺点：如果管理层面和技术层面上缺乏仔细规划，工作就无法进行。,,使用阶段交付的注意点：,,必须确定每一阶段的交付是对用户有用的,,必须确保考虑了不同产品组成部分的技术依赖关系,,M. 面向进度的设计,类似于阶段交付，但是面向进度的设计生命周期模型在开始的时候不必知

35、道究竟能达到何目标，但是要确保最后的,期限,。,,该模型的关键是要,按优先级别划分系统特性并规划开发阶段,，保证前面的阶段具有高优先级的特性，低特性具有低优先级别。,,是否采用这种方法决定于你是否对系统目标具有足够的信心，如果有信心，则没必要采用这种方法。,,N.渐进交付,渐进交付是一种跨越了渐进原型和阶段交付两种模型的过程模型。,,基本过程：开发一个产品的版本，展示给用户，根据反馈改善产品。,,如果计划满足用户的绝大部分需求，渐进交付与渐进原型差不多，如果计划满足少量的需求，渐进交付就和阶段交付差不多。,,渐进原型，强调的是系统看得见的样子，再回来堵漏洞，渐进交付中，最初的重点是系统核心和底

36、层系统功能,。,,渐进交付,软件概念,需求分析,构架和内核设计,开发一个版本,并入用户反馈,交付该版本,开发一个版本,交付最终版本,,确定渐进交付目标的一种方法,价值成本比,,软件开发方法,,软件开发过程遵循的方法和步骤,,几种典型的开发方法：,,模块化方法（,modular method,）,,,结构化方法,,,面向数据结构方法,,,面向对象方法,,软件开发需要项目管理,软件开发是个系统工程,,需要资源的协调,,软件开发过程的选择与项目的协调紧密相关,,,项目管理、工具、技术、流程与组织,,,主要内容,回顾,,软件项目实施的方法选择,,软件开发过程模型的选择,,软件开发方法,,项目管理,,项

37、目管理基本概念,,实施项目管理的工具与技术,,项目管理的流程,,项目管理的流程特征（产品／项目／软件项目）,,项目管理组织结构,,软件项目管理的流程,,,• 建立不现实的最终期限,,• 不断变更的客户需求,,• 对努力的低估,,• 可预见和不可预见的风险,,• 技术的困难性,,• 项目成员的沟通不畅通,,• 项目管理不利,为什么项目会失败?,,People,— 项目成功的最重要因素,,Product,— 建立的软件,,Process,— 框架活动集合和得到工作的软件工程任务,,Project,— 实现产品所需要的所有工作,The 4 P’s,,软件梯队,被解决问题的难易程度,,代

38、码和功能点形成的结果程序的规模,,梯队的生存周期,,问题被模块化的程度,,被建立系统所需要的质量和可靠性,,发布日期的严格性,,项目的社会化程度（沟通程度）,选择软件项目梯队结构所要考虑的因素,,...,,建立范围—陈述性描述，约束问题表达,,分解—建立功能性分割,问题定义,,发现项目的关键,系统为什么被开发?,,做什么? 什么时候?,,谁对某一功能负责?,,他们组织定位在哪里?,,从技术和管理上工作怎样被做?,,多少资源需要 (e.g., 人, 软件, 工具, 数据库)?,Barry Boehm,,形式的风险分析,,经验成本和进度估算,,基于度量的项目管理,,价值跟踪（Earned valu

39、e tracking）,,质量目标下的跟踪,,人要意识到项目管理,关键实践,,什么是项目,项目是什么,,没有例行的任务,,需要计划,,特定的目标需要满足或者特定的产品需要生成,,项目有一个预定义的时间范围,,工作不仅仅是为自己，也是为他人,,工作中有些特性,,工作分为若干阶段,,项目完成需要资源,,项目是大型的或者复杂的,,什么是项目管理,项目管理是在项目活动中应用知识，技能，工具和技术来,满足项目需求,的,过程,，它通过初始化，计划，执行，控制和结束等,活动,来完成。,,项目生命周期,项目生命周期定义一个项目的,开始,与,结束,。,,项目生命周期定义的阶段顺序通常包括某些技术转移或“握手”(

40、hand off)，如从需求到设计，从构造到运行，但是在风险允许下，也可以下一阶段提前进行，这种重叠的阶段被称为快速跟踪(fast tracking)。,,项目生命周期通常定义：,,各个阶段需要完成的技术工作；,,每个阶段需要涉及的人。,,项目生命周期,绝大多数项目生命周期有一些共同的特点，如成本和人员消耗的变化曲线。,,,,,,,项目生命周期与产品生命周期是不同的。,,,项目中的人员,项目影响者(stakeholders),,项目小组内部：,,项目小组外部，但是在同一组织内：,,项目小组和组织外部：如客户,,不同的项目影响者有不同的目标，因而项目领导者需要能够协调这些目标。Boehm和Ros

41、s提出软件项目管理的“W理论”，该理论关注于所有各方都能从项目种获益因而对项目的成功都有兴趣。（W代表Everyone a Winner）,,软件项目管理定义,软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。,,软件项目包含的活动,需求分析,,描述,,设计,,编码,,校验,,安装,,维护,,支持,,应用项目管理方法开展软件开发,项目的可行性分析,,需求开发与需求管理,,软件项目工作量估算,,软件项目计划与资源分配,,软件项目监控,,风险管理,,软件质量管理与软件开发规范,,软件项目中的人员管理,,软件配置管理,,项目可

42、行性分析与评估,,,内容安排,可行性分析的内容,,项目范围管理,,技术评估,,经济评估,,风险评估,,可行性报告,,项目建议书,,需求建议书,,可行性分析,目的,,“说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性；评述为合理地达到开发目标可能选择的各种方案”。,,GPS监控系统的投资失误,,做什么？近期目标？,,人员配备，怎样整合,,需求调研问题,,开发费用问题,,风险规避,,顶新国际集团：在投资新产品时,,1400万：全国28个城镇居民消费习惯调查,,700 万：委托28个城镇社会科学院进行全国七大区域总体经济投资环境的分析,,任务,,了解客户要求及现实环境，从技术、经济和社会

43、因素研究并论证软件项目可行性，编写可行性报告，制定初步项目开发计划,,“,什么都不做,”永远是一个可考虑的方案,,可行性分析的内容,项目范围,,策略评估,,技术评估,,经济评估,,风险评估,,项目范围管理内容,保证项目,包括并且仅仅包括,需要包括的内容。它由以下步骤组成：,,初始化：对项目或阶段,授权,,范围计划：开发一个作为将来项目决策基础的,书面,的范围声明,,范围定义：将,项目交付物细分,为更小的，更易管理的元件,,范围校验：形式化项目范围的接受条件,,范围变更控制：控制项目范围的变更,,范围的含义,“范围”包含产品范围和项目范围,,产品范围：产品或服务的特点和功能,,项目范围：为了生产

44、具有特定特点和功能的产品所需要的工作,,软件范围,软件项目计划的第一项任务就是确定软件的工作范围，即,软件的用途及对软件的要求,。因此，应从管理角度和技术角度出发，确定明确的可理解的软件项目范围。,,软件范围的叙述,明确给出,定量的,数据（例如，同时使用该软件的用户数目，发送表格的长短，最大允许响应时间等）,,指明,约束条件和/或限制,（例如，产品成本限制了存储的容量）,,叙述某些,质量,因素（例如，给出的算法是否容易理解、是否使用Ada语言等）,,软件范围的估计,软件范围包括功能、性能、限制、接口和可靠性。,,功能：,,软件功能评价，并进行适当细化,,功能分解，满足未来成本和进度估算要求,,

45、性能,,包括处理和响应时间的需求。,,约束条件：,,外部硬件、可用存储或其他现有系统对软件限制。,,功能、性能和约束必须在一起进行评价。,,当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级。,,如果功能保持相同而性能可变，则开发软件所需的工作量和成本将有显著的差异。,,价值驱动的电子商务分析方法,,,,,业务流程,,模型,,,业务概念,,模型,策略,规划级,结构级,实施级,电子商务技术层,业务策略的概念结构,,,概念建模,协商建模,价值驱动流程建模,,,资,源,价,值,配,置,伙,伴,网,络,价,值,链,构,架,信,息,策,略,发,布,渠,道,客,户,信,任,客,户,关,系,企

46、,业,能,力,价,值,建,议,目,标,客,户,产,品,与,服,务,创,新,R,e,v,e,n,u,e,,M,o,d,e,l,价,值,结,构,收,入,模,型,收,益,/,损,失,资,产,、,财,务,电子商务概念模型,,初始化,初始化(Initiation),,正式授权一个新项目或者决定一个已有项目继续进行下一阶段,,项目是由于下面一些原因产生的：,,市场需要（新性能汽车）,,业务需要（培训中心新课程设计）,,客户需要（客户定制产品）,,技术进步（如计算机技术进步）,,法规需要（污染处理）,,社会需要（政府水处理系统）,,初始化,输入：,,产品描述,,策略计划：企业的战略计划,,项目选择准则（经济

47、回报，市场回报，公共形象）,,历史信息：以前项目的结果和性能,,工具和技术,,项目选择方法,,专家判断,,输出：,,项目章程（授权项目的正式文档，包括业务需求，产品描述）,,项目经理指派,,约束,,假设,,范围计划,范围计划是将生成产品的项目工作（项目范围）,逐步细化,的过程。,,输入：,,产品描述,,项目章程,,约束,,假设,,工具和技术,,产品分析,,利益成本分析(Benefit/Cost Analysis),,备选方案（brainstorming or lateral thinking),,专家判断,,范围计划,输出,,范围声明（Scope Statement)，包括,,项目理由：Pro

48、ject Justification(Business need),,项目产品:概述,,项目交付物：project deliverables,,项目目标: 判断项目是否成功的定量准则,,支持细节（包括假设和约束）,,范围管理计划,,,范围定义,范围定义涉及到将主要的项目交付物细分以：,,提高成本，周期和资源估计的准确性,,定义性能度量和控制的基线,,便于清晰定义责任分配,,范围定义正确与否将影响项目的节奏，进度，生产率和项目人员的士气。,,范围定义,输入,,范围声明,,约束,,假设,,其它计划输出,,历史信息,,工具和技术,,WBS(Work breakdown structure)模板,,分

49、解技术,,策略评估中的模块管理,模块管理（Programm management),,“模块是一组协调管理的项目，通过将项目组成模块，将获得比单个管理项目更大的效益。”——D. C. Ferns,,有效的模块管理需要有一个模块目标，项目必须根据模块目标来选择,,在大的组织中，将可能有模块管理的机构，例如模块主管或者模块经理,,即使没有专门的组织来管理模块，项目的选择也需要根据组织的整个业务目标来评价,,策略评估的内容,目标：提出的系统对组织目标具有怎样的贡献？例如它是否能够增加市场份额？,,IS计划：提出的系统如何与IS计划相适应？它将替换或者与那些系统接口？它与将来开发的系统有何交互关系？,

50、,组织结构：新系统对目前的部门和组织结构有何影响？例如一个新的订单处理系统是否与目前的销售与库存控制的功能相重叠？,,MIS:系统将在组织的何层次上提供何种信息？它将以何种方式对现存管理信息系统进行补充何提高？,,人员：系统将以何种方式影响人力水平何现存雇员的技术？它对组织整个人员开发策略有何影响？,,情形：系统将使客户对组织的态度有何变化？是否采用一个自动化的系统将与提供友好的服务相冲突？,,策略评估中的业务管理,业务管理,,选定的项目将成为业务的一部分，项目将对资源产生竞争,,竞争中对业务的调整是必要的,,技术评估,技术的成熟程度,,实验室技术,,经过中试的技术,,已经工业化应用的技术,,

51、市场需求,,显在,,潜在：转化为显在的条件,,竞争态势：,与竞争技术相比，所采用技术的优势及缺陷,,技术转换成本,,支撑体系与条件：原料、销售网络、用户体系、政策,,技术发展趋势及所采用技术的发展前景,,技术方案选择,要考虑的制约条件,,需求制约：现存的需求结构及需求结构可能的变化,,资源制约：资金、人力资源、自然资源、其它要素,,环境制约：经济技术环境、社会文化环境、自然环境,,选择原则,,经济性原则：以最小的投入取得最好的效果,,发展原则：发展的前景及适应发展的能力,,兼容性原则：与原有经济、技术、环境、社会的兼容性,,相关效果原则：相关的经济、技术、环境、社会效果,,选择视角,,技术先进

52、性,,技术适用性,,经济分析,开发所需要的成本和系统运行所需要的成本与得到的效益的比较,,识别出项目进行中所需要的所有成本和效益并对其进行聚集,,将成本和效益用单元来表达,,成本分为,,开发成本,,安装成本,,运行成本,,经济分析,效益,,直接效益,,可见的间接效益,,不可见的效益,,经济分析,净收益（Net Profit):项目的净收益是在项目生命周期内总的收入与总的成本的差。,,没有考虑时间因素,,回收期限（Payback Period）：将初始投资收回的期限,,忽略了整个项目的盈利空间,,经济分析,投资回报(Return on investment):也被称为回报率(accounting

53、 rate of return)(ARR),,ROI=（平均年收益/总投资）×100,,例如项目1：ROI=10,000/100,000*100=10%,,缺点：,,没有考虑时间因素,,该回报率易与银行利率混淆,,,经济分析,净现率(Net Present Value),,考虑了时间因素,,对将来的收益打一个折扣,,“拿在手里的钱才是真正的钱”,,如果假定年折扣率为10％，那么明年的100元等于现在手中的91元，后年的100元等于现在的83元,,目前值＝t年的值/(1+r),t,,系统开发和每年运行费用举例,1.系统开发费用（一次）,,人员：,,.,2名系统分析员(,450小时/名,45美元/

54、小时,),$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,000,,30个用户，三天

55、的内部培训课程 $,10,000,,物资：,,复印 $,500,,磁盘、纸张等消耗品 $,650,,,系统开发和每年运行费用举例,购买硬件、软件：,,20,台工作站,Windows,软件,,,$,1,000,,20,台工作站内存升级,$,8,000,,网络软件,$,17,500,,20,台工作站办公软件产品,$,20,000,,系统开发总费用,$161,670,,系统开发和每年运行费用举例,2.年运行费用（每年）,,人员：,,维护程序员/分析员(250小时/年,42美元/小时) $10,5

56、00,,网络管理员(300小时/年,50美元/小时) $15,000,,购买硬件、软件升级：,,硬件 $5,000,,软件 $6,000,,物资和杂项 $3,500,,每年总运行费用 $40,000,,可行性研究的步骤,,(1)复查确认系统目标、规模,,(2)研究正使用系统工作流程,,(3)导出新系统高层逻辑

57、模型,,(4)重新定义问题,,(5)导出和评价供选择的方案,,(6)推荐可行的方案,,,(7)草拟开发计划,,(8)编写可行性研究报告，送审,,可行性分析,可行性分析报告的格式,,可行性研究报告的编写提示,,GB 8567-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

58、 工作负荷,,3.3 费用开支,,3.4 人员,,3.5 设备,,3.6 局限性,,可行性研究报告的编写提示,4 所建议的系统,,4.1 对所建议系统的说明,,4.2 数据流程和处理流程,,4.3 改进之处,,4.4 影响,,4.5 局限性,,4.6 技术条件方面的可行性,,可行性研究报告的编写提示,5 可选择的其它系统方案,,5.1 可选择的其它系统1,,5.2 可选择的其它系统2,,......,,,可行性研究报告的编写提示,6 投资及收益分析,,6.1 支出,,6.2 收益,,6.3 收益/投资比,,6.4 投资回收周期,,6.5 敏感性分析,,可行性研究报告的编写提示,7 社会条件方面

59、的可行性,,7.1 法律方面的可行性,,7.2 使用方面的可行性,,项目建议书,起源：组织内部认识到需要利用信息技术,,改进目前的业务运行,,改进目前的信息系统,,开发新的产品,,目的：,,使管理层能够作出项目决策,,准备招标书,目的：,,从客户的角度全面地、详细的论述，为了达成确定的需求应需要作何准备,,一份招标书应当是全面的，能提供足够详细的信息，以使承约商或项目团队能针对顾客的需要相应地准备一份最优的招标书,,招标书,招标书中需要提供工作表述,,招标书中必须包括客户要求，此要求中规定了规格和特征,,招标书应当说明客户期望承约商或项目团队提供什么样的交付物,,招标书中应当列举客户供应条款,

60、,招标书中可以表述出客户对需要的确认,,招标书中可以提到客户想要用的合同类型,,招标书,表述出客户想用的付款方式,,表述出项目完成所需的进度计划,,提供有关承约商申请书的格式和内容安排,,支持客户希望潜在承约商提交申请书的最后期限,,可能包括评价标准,,可能会指出客户所拥有的可用于此项目的资金量。,,案例分析,宁波市第五次全国人口普查办公室的宁波市人口地理信息系统,,地理空间分析、人口统计与分析一体化,,宁波人口普查、日常管理、统计与分析的数字化、可视化,,人口信息存储、管理与分析，建立规范化的空间地理信息与人口信息统一管理、分析、统计、发布、录入、更新与维护,,对空间数据和人口数据的快速采集

61、、建库、维护、查询、管理、显示、输出、统计分析、共享与发布功能,,案例分析,性能要求,,满足宁波全部市县人口的数据存储,,不同县区都可以调用数据，操作数据,,保证调查高峰操作响应的人机交互,,保证数据统计的响应时间,,,案例分析,限制要求,,Windows平台客户端,,服务器选用Intel服务器,,存储RAID，保证存储安全,,与DOMINO办公系统可以实现接口，可以抽取数据报表,,,需求开发与需求管理,,,主要内容,从一个故事看软件开发的实际问题,,需求管理的困难性,,管理需求的目的,,软件需求特性,,需求工程,,如何获取需求,,需求规格说明,,需求管理工具,,,软件开发面临的实际问题,,软

62、件开发面临的实际问题,,软件开发面临的实际问题,,为什么？？？,需求？？？,,什么是需求,需求为用户解决问题或达到,目标,所需的条件或权能,,系统或系统部件要满足合同、标准、规范和其它正式规定文档所需具有的,条件,或权能,,一种反映上述条件或权能的,文档说明,,举例,系统必须提供基于PPPoE协议的用户接入模式,,产品应当提供机架式安装，并提供两个千兆以太网端口,,系统使用的用户是信息中心和网络管理员,,系统在运行时必须提供自动数据备份功能,,简要的解释,需求来源于用户的一些,“需要”,，这些“需要”被,分析、确认,后形成,完整文档,，该文档详细地说明了产品,“必须或应当”,做什么。,,如果只

63、有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。,,需求管理的困难性,需求,不,总是,显而易见,的，而且它可来自各个方面。,,需求并,不,总是能容易用,文字明白,无误地,表达,。,,存在,不同种类的需求,，其,详细程度,各,不相同,。,,如果不加以控制，需求的,数量将难以管理,。,,需求之间,相互关联,，而且需求也和软件工程流程中的其他可交付工件有关。,,需求有,唯一的特征或特征值,。例如，它们的重要性和容易满足的程度都各不相同。,,需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。,,需求会,变更,。,,为什么要管理需求,为什么要管理需求？,,避免失败就是

64、一个很充分的理由,。,,提高项目的成功率,,需求管理带来其他好处,,Standish Group 的 CHAOS 报告进一步证实了与成功项目关系最大的因素是良好的需求管理。,,什么是软件需求,从软件开发过程看软件需求开发,,从软件发展周期看软件开发过程,时期,,年代,,阶段,,涉及,,注重,,主要使用语言,,标准,,模型,,初期,,50-60,,程序设计,,点,,编程,,技巧,,ALGOL,,FORTRAN,,COBOL,,BASIC,,,,,,中期,,70-80,,软件开发,,线,,结构化,,模块化,,PASCAL,,,GB8566,,软件开发,,规范,,,瀑布,,,原型,,现代,,9

65、0-,,软件过程,,面,,过程,,能力,,C,C++,,JAVA,,VB、VC,,,ISO/IEC,,12207,,软件生存期过程,,,ISO9000,,,螺旋,,,CMM,,,计算机系统,,人员,硬件,软件,数据,传输,,机构,执行,,机构,（剧作家、导演）,（舞台,剧本,演员,道具）,软件开发全过程,,,,,活动－任务,,⑴系统需求分析,,⑵系统结构设计,,⑶软件需求分析,,建立软件需求,,评价软件需求,,联合评审,,⑷软件结构设计,,⑸软件详细设计,,⑹软件编码和测试,,⑺软件集成,,⑻软件鉴定测试,,⑼系统集成,,⑽系统鉴定测试,,⑾软件安装,,⑿软件验收支持,,软件开发过程,

66、,⑴,,定义（IEEE-STD-610）,,用户为解决某个问题、或为实现某一目标，,,要求软,件必须满足的条件或能力。,,⑵ 软件需求的三个层次,,业务需求,,,用户需求,,,功能需求和非功能需求,,软件需求的层次性,,软件,,系统需求(1),系统需求,分配,软件工程组,硬件,,系统需求(2),,其它成分,,系统需求(n),,软件需求,客户,最终用户,系统工程组,系统需求分配,,业务需求,业务说明,使用实例,用户需求,功能需求,约束条件,非功能需求,软 件 需 求 规 格 说 明,软件需求的层次,,需求的层次性,,业务需求,项目视图与范围文档,用户需求,质量属性,系统需求,功能需求,约束条件,其它非功能需求,Use Case文档,软件需求规格说明,,非功能需求,,过程需求：交付需求，实现需求，遵循的标准,,性能需求：速度，容量，可靠性,,,外部需求：互操作性，伦理性，,,机密性，安全性，,,使用要求,,非功能,软件需求,,系 统 需 求,,ACCS应能使汽车保持在预期车速的,,2KM,,H范围内行驶,分配给硬件的需求,,硬件应能使车速在规定的精确度,,1.5KM,,H范