软件系统开发与软件工程方法34370.pptx
第七章 软件系统开发与软件工程方法软件系统开发与软件工程方法 n n一、软件危机n n二、软件工程一、软件危机1、软件开发的发展历程 19601970198019902000 早期早期 第二阶段第二阶段 第三阶段第三阶段 第四阶段第四阶段面向批处理面向批处理 多用户多用户 分布式系统分布式系统 强大的桌面系统强大的桌面系统有限的分布有限的分布 实时实时 嵌入嵌入“智能智能”面向对象技术面向对象技术自定义软件自定义软件 数据库数据库 低成本硬件低成本硬件 专家系专家系统 开发者开发者=使用者使用者 软件产品软件产品 人工神经网络人工神经网络 并行计算并行计算 网络计算机网络计算机一、软件危机2、软件危机 1 1）案例思考）案例思考11FAA的失败项目的失败项目 20世世纪纪80年年代代中中期期，更更换换空空中中交交通通控控制制系系统统已已成成为为美美国国联联邦邦航航空空管管理理局局（FAA）非非常常优优先先的的任任务务。1989年年IBM公公司司获获得得更更换换该该系系统统的的合合同同，截截止止期期为为2001年年，预预计计投投入入25亿亿美美元元。由由于于面面临临着着极极苛苛刻刻的的需需求求，该该软软件件项项目目是是已已进进行行的的最最复复杂杂的的项项目目之之一一。例例如如，交交通通控控制制系系统统必必须须具具备备全全局局完完整整性性并并且且每每周周7天天，每每天天24小小时时不不能能停停止止工工作作，甚甚至至在在升升级级时时或或正正常常维维护护时时，也也不不允允许许有有停停顿顿时时间间。任任何何错错误误的的数数据据都都会会引引起起重重大大伤伤亡亡，任任何何停停机机均均会会导导致致世世界界范范围围的的出出行行延延误误或或潜潜在在的的危危险险。该该系系统统的的反反应应时时间间不不能能超超过过2-3秒秒。此此外外，该该系系统统设设计计时时必必须须考考虑虑到到允允许许私私人人飞飞机机驾驾驶驶员员继继续续使使用用旧旧设设备备，并并要要求求软软件件能能在在未未来来移移植植到到更更新新的的硬硬件件设设备备上上。当当IBM获获得得该该合合同同后后，该该系系统统的的主主要要花花费费为为软软件件开开发发，用用于于硬硬件件的的投投入入仅仅为为8万万美美元元。1993年年，负负责责该该项项目目的的IBM子子公公司司IBM联联邦邦系系统统公公司司被被IBM卖卖给给了了Loral公公司司。到到1994年年，该该系系统统已已花花费费了了23亿亿美美元元，但但尚尚未未提提交交系系统统的的任任何何程程序序段段，而而此此时时估估算算整整个个系系统统的的花花费费将将增增至至50亿亿美美元元。1994年年底底，FAA不不得得不不承承认认该该项项目目失失败败并并进进行行调调查查。作作为为调调查查的的结结果果，FAA取取消消或或修修改改了了系系统统的的四四个个主主要要部部分分。面面临临当当前前空空中中控控制制系系统统存存在在的的隐隐患患，FAA不不得得不不订订购购了了一一套套作作为为权权宜宜之之计计的的系系统统，由由另另一家公司开发。一家公司开发。你认为该项目的失败反映了什么问题？失败的主要原因可能是什么？你认为该项目的失败反映了什么问题？失败的主要原因可能是什么？FAA为什么选择取消和修改的方式而不是增加资源和生产力的方式？为什么选择取消和修改的方式而不是增加资源和生产力的方式？FAA对此项目调查总结出的原因为以下几条：FAA并没有明确掌握某些系统功能的需求。制定了过于急躁的开发和实现计划（包括费用与进度的估计）在给定的软件复杂度下，没有考虑到开发商的生产力，尤其是早期阶段需要投入的资源。在在人人月月神神话话一一书书中中，Brooks将将过过去去30年年大大型型软软件件项项目目的的开开发发比比喻喻为为史史前前陷陷入入沥沥青青坑坑的的巨巨兽兽。恐恐龙龙、猛猛犸犸、剑剑齿齿虎虎等等动动物物在在焦焦油油中中挣挣扎扎，然然而而挣挣扎扎得得越越激激烈烈，就就陷陷得得越越快快，最最终终都都沉沉到到了了坑坑底底。过过去去的的大大型型软软件件项项目目中中，大大多多数数开开发发出出了了可可运运行行的的系系统统不不过过只只有有极极少少数数满满足足了了目目标标、进进度度和和预预算算的的要要求求。表表面面上上看看起起来来没没有有任任何何一一个个单单独独的的问问题题会会导导致致困困难难，每每个个问问题题都都能能获获得得解解决决，但但这这些些问问题题纠纠缠缠和和积积累累在在一一起起时时，团团队队的的行行动动就越来越慢，并且很难再看清问题的本质。就越来越慢，并且很难再看清问题的本质。1995年美国的商业软件失败统计：一、软件危机2、软件危机 案例思考案例思考22遗传遗传信息信息库库建建设设 在在正正在在建建设设的的遗遗传传信信息息库库如如，假假设设你你要要开开发发一一个个管管理理软软件件。你你并并不不是是一一个个生生物物遗遗传传方方面面的的专专家家，甚甚至至对对此此方方面面的的知知识识一一窍窍不不通通，你你该该如如何何入入手手？要要使使该该项项目目成成功功，你你认认为为应应该该有哪些保障条件？有哪些保障条件？你的问题是什么：对遗传信息的管理需要什么条件：了解遗传信息的表示和管理流程如何实现：与遗传领域的专家交流。障碍是什么：难以沟通与交流。可能因误解产生错误的需求描述。一、软件危机2、软件危机 软件项目为什么会失败？软件项目为什么会失败？软件项目失败的核心问题在哪里？答案只有一个：复杂性。软件要解决的问题本身是复杂的开发人员一般不是该问题领域的专家软件规模要求多人参与，而不同专业领域的人的交流是困难的软件规模使得既要理解系统整体结构又要把握细节比较困难。n例例:Windows9595有有10001000万行代码万行代码 Windows20002000有有50005000万行代码万行代码Exchange2000和和 Windows20002000开发人员结构开发人员结构Exchange2000 Windows2002000 0项目经理项目经理25人人约约250人人开发人员开发人员140人人约约1700人人测试人员测试人员350人人约约3200人人一、软件危机2、软件危机 2 2）软件神话）软件神话 1管理神话神话：有关软件开发的理论和方法已经很丰富，有很多可用的标准与规范，因而可以保证软件开发的顺利进行。现实：理论与方法在大多数实践中并没有得到真正的应用。使用者并没有对这些理论与方法建立正确的认识。神话：已经有很多强大的开发工具和先进的计算机硬件，这些可以保证软件开发的质量与效率。现实：这些工具并没有得到合理的应用。神话：如果我们落后于进度，可以通过增加人手来赶上。现实：向一个已经延迟的项目增加人手，只会使延迟的项目更加落后除非项目中不需要交流。生一个孩子10个月，无论有多少人。一、软件危机2、软件危机 2 2）软件神话）软件神话 1管理神话神话：通过把软件项目外包给实现强大的软件开发公司可以保证软件的成功。现实：再专业的软件公司，不了解客户的需求和业务流程，也不可能顺利完成软件开发项目。改正一个问题需付出的代价需求分析结构设计详细设计编码集成测试系统测试现场改正一个问题的估计费用改正一个问题估计的工作量20200200010005.02.50.050.5(美元)(人天)一、软件危机2、软件危机 2 2）软件神话）软件神话 2客户神话神话：有了目标系统的一般性描述就可以写程序了，细节可以逐步完善。现实：糟糕的系统定义是项目失败的主要原因。关于问题域、功能、行为、性能、接口、设计约束以及确认标准的形式化的、详细的描述是必要的，这些内容只能通过客户与开发者之间的交流才能确定。神话：软件需求是经常变更的，而这些变更可以容易的被满足，因为软件是灵活的。现实：软件需求确实是容易变更的，但变更的代价将随软件开发的进度不同而有很大的差异。如果重新项目早期的问题定义，需求变化则很容易被调节，而项目后期需求变更的代价可能是致命的。一、软件危机2、软件危机 2 2）软件神话）软件神话3实践者的神话神话：软件是艺术，软件开发是个人的舞台。现实：50年代可能是，现在不是。神话：一旦写完了程序并能正常运行，我们的工作就结束了。现实：越早开始写代码，软件开发花费的时间就越长。统计表明60%到80%的工作量是花在将软件第一次交付给客户以后发生的。神话：程序真正运行以前，没有办法评估其质量。现实：高质量的实现来自高质量的设计。从项目一开始就必须进行技术评审。神话：项目的成功来自于可运行程序的提交。软件开发过程中的文档是不必要的，延缓项目进度的东西。现实：软件项目的成果包含很多内容，文档是成功开发的基础，也是软件质量的保证。好的开发质量降低了重复劳动，从而提高了效率，导致更短的交付时间。一、软件危机2、软件危机 3 3）软件危机及主要表现）软件危机及主要表现软件危机指在计算机软件开发和维护过程中所遇到的一系列严重问题软件开发不能满足日益增长的需求；难以维护不断增长的已有软件。1成本与进度的估计成本与进度的估计2用户需求与产品不一致用户需求与产品不一致3软件可靠性差软件可靠性差4可维护性差可维护性差5文档资料不完整文档资料不完整6软件成本比例不断上升软件成本比例不断上升7开发生产率相对停滞开发生产率相对停滞一、软件危机2、软件危机 3 3）软件项目成败的因素分析）软件项目成败的因素分析1）失败项目的主要原因）失败项目的主要原因1用户需求不完整、被误解或经用户需求不完整、被误解或经常变化常变化2有限的用户参与有限的用户参与3缺少行政支持缺少行政支持4缺少技术支持缺少技术支持5项目计划不充分项目计划不充分6目标不明确目标不明确7没有足够的资源（客户没有提没有足够的资源（客户没有提供供/开发者不具备相应生产力）开发者不具备相应生产力）2）成功项目的主要原因）成功项目的主要原因1大量的用户参与大量的用户参与2上层管理人员的支持上层管理人员的支持3完整、详细的项目计划完整、详细的项目计划4符合实际的工作进度与里程碑符合实际的工作进度与里程碑5开发人员的培训、交流开发人员的培训、交流6良好的工作环境、团队协作机制良好的工作环境、团队协作机制一、软件危机2、软件危机 3 3）消除软件危机的思路）消除软件危机的思路1正确的观念正确的观念a)软件不是程序软件不是程序软件是逻辑产品而不是实物产品软件是逻辑产品而不是实物产品软件的功能依赖于硬件和软件的运行环境以及人们对它软件的功能依赖于硬件和软件的运行环境以及人们对它的操作的操作软件特征：软件特征：功能的多样性功能的多样性 实现的多样性实现的多样性 能见度低能见度低 软件结构合理性差软件结构合理性差智力密集及知识产权保护智力密集及知识产权保护b)软件开发不是个体劳动软件开发不是个体劳动软件设计的复杂性软件设计的复杂性一、软件危机2、软件危机 3 3）消除软件危机的思路）消除软件危机的思路2正确的过程管理与控制正确的过程管理与控制u软件开发技术软件开发技术:软件开发方法软件开发方法 软件开发过程软件开发过程 软件工具和软件工程环境软件工具和软件工程环境 u软件工程管理软件工程管理:软件管理软件管理 软件经济软件经济 软件心理软件心理二、软件工程1、软件工程 将工程管理思想引入软件开发过程：将工程管理思想引入软件开发过程：u 转变对软件的认识：转变对软件的认识：上升上升 程序程序 系统系统u 转变思维定式：转变思维定式：上升上升 程序员程序员 系统工程师系统工程师 (系统分析员系统分析员)n 工程化训练工程化训练二、软件工程1、软件工程 将工程管理思想引入软件开发过程：将工程管理思想引入软件开发过程：用户用户分析员分析员程序员程序员“一个好的工业，应有一套良好的标准来配套”软件的工业化生产过程应具备的特点：软件的工业化生产过程应具备的特点：n明确的工作步骤明确的工作步骤n详细具体的规范化文档详细具体的规范化文档n明确的质量评价标准明确的质量评价标准软件产品的标准化软件产品的标准化软件产品的标准化软件产品的标准化软件开发过程的标准化软件开发过程的标准化软件开发过程的标准化软件开发过程的标准化u 强调规范化强调规范化u 强调文档化强调文档化软件工程技术的两个明显特点：软件工程技术的两个明显特点：二、软件工程1、软件工程 Fritz Bauer在在NATO会议上给出会议上给出的定义：的定义：“软件工程是为了经济地获软件工程是为了经济地获得可靠的和能在实际机器上高效得可靠的和能在实际机器上高效运行的软件而确立和使用的健全运行的软件而确立和使用的健全的工程原理（方法）。的工程原理（方法）。”二、软件工程1、软件工程 IEEEIEEE【IEE83】给出的软件工程给出的软件工程定义：定义：“软件工程是开发、运行、软件工程是开发、运行、维护和修复软件的系统方法。维护和修复软件的系统方法。”二、软件工程1、软件工程 IEEEIEEE【IEE93】给出了一个更给出了一个更加综合的定义：加综合的定义：“将系统化的、规范的、可将系统化的、规范的、可度量的方法应用于软件的开发、度量的方法应用于软件的开发、运行和维护的过程，即将工程化运行和维护的过程，即将工程化应用于软件中。应用于软件中。”二、软件工程1、软件工程 软件工程是应用计算机科学、数学及管理软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴传统工科学等原理开发软件的工程。它借鉴传统工程的原则、方法，以提高质量，降低成本为程的原则、方法，以提高质量，降低成本为目的。目的。软件工程所包含的内容不是一成不变的，而是软件工程所包含的内容不是一成不变的，而是软件工程所包含的内容不是一成不变的，而是软件工程所包含的内容不是一成不变的，而是随着人们对软件系统的研制开发和生产的理解随着人们对软件系统的研制开发和生产的理解随着人们对软件系统的研制开发和生产的理解随着人们对软件系统的研制开发和生产的理解不断发展变化不断发展变化不断发展变化不断发展变化，应该用发展的眼光看待。应该用发展的眼光看待。应该用发展的眼光看待。应该用发展的眼光看待。二、软件工程1、软件工程软件工程是一种层次化的活动，软件工程是一种层次化的活动，a)质量质量软件工程的根基与目标软件工程的根基与目标b)过程过程建造一个高质量软件所需完成任务的框架建造一个高质量软件所需完成任务的框架c)方法方法提供了如何建造软件的技术手段提供了如何建造软件的技术手段d)工具工具为过程和方法提供自动或半自动化的支持为过程和方法提供自动或半自动化的支持（CASE）工具工具方法方法过程过程质量焦点质量焦点二、软件工程2、软件工程一般视图 工程：对技术（或社会）实体的分析、设计、构造、验证和管理。首先工程：对技术（或社会）实体的分析、设计、构造、验证和管理。首先工程：对技术（或社会）实体的分析、设计、构造、验证和管理。首先工程：对技术（或社会）实体的分析、设计、构造、验证和管理。首先工程：对技术（或社会）实体的分析、设计、构造、验证和管理。首先工程：对技术（或社会）实体的分析、设计、构造、验证和管理。首先要问题的问题：要问题的问题：要问题的问题：要问题的问题：要问题的问题：要问题的问题：要解决什么问题？要解决什么问题？要解决什么问题？要解决什么问题？要解决什么问题？要解决什么问题？实体的什么特征能解决这个问题？实体的什么特征能解决这个问题？实体的什么特征能解决这个问题？实体的什么特征能解决这个问题？实体的什么特征能解决这个问题？实体的什么特征能解决这个问题？如何设计该实体？如何设计该实体？如何设计该实体？如何设计该实体？如何设计该实体？如何设计该实体？如何构建该实体？如何构建该实体？如何构建该实体？如何构建该实体？如何构建该实体？如何构建该实体？如何控制和避免构建过程中的错误？如何控制和避免构建过程中的错误？如何控制和避免构建过程中的错误？如何控制和避免构建过程中的错误？如何控制和避免构建过程中的错误？如何控制和避免构建过程中的错误？如何在用户要求修改、适应和增强时长期地支持这些实体？如何在用户要求修改、适应和增强时长期地支持这些实体？如何在用户要求修改、适应和增强时长期地支持这些实体？如何在用户要求修改、适应和增强时长期地支持这些实体？如何在用户要求修改、适应和增强时长期地支持这些实体？如何在用户要求修改、适应和增强时长期地支持这些实体？定义阶段：做什么定义阶段：做什么定义阶段：做什么定义阶段：做什么定义阶段：做什么定义阶段：做什么开发阶段：如何做开发阶段：如何做开发阶段：如何做开发阶段：如何做开发阶段：如何做开发阶段：如何做支持阶段：应对变化支持阶段：应对变化支持阶段：应对变化支持阶段：应对变化支持阶段：应对变化支持阶段：应对变化项目跟踪与控制项目跟踪与控制项目跟踪与控制项目跟踪与控制技术评审技术评审技术评审技术评审质量保证质量保证质量保证质量保证软件配置管理软件配置管理软件配置管理软件配置管理文档管理文档管理文档管理文档管理复用管理复用管理复用管理复用管理测试管理测试管理测试管理测试管理风险管理风险管理风险管理风险管理支持活动支持活动软件工程框架可可用用性性性性性性确确正正合合算算选取适宜的开发模型选取适宜的开发模型采用合适的设计方法采用合适的设计方法提供高质量的工程支持提供高质量的工程支持重视软件工程的管理重视软件工程的管理基基本本过过程程原则原则 目标目标 过过 程程支支支支持持持持过过过过程程程程组组组组织织织织过过过过程程程程软件过程评估软件能力成熟度软件能力成熟度软件能力成熟度软件能力成熟度CMMCMMCMMCMM1-1-1-1-初始级：没有过程定义，个人能力。初始级：没有过程定义，个人能力。初始级：没有过程定义，个人能力。初始级：没有过程定义，个人能力。2-2-2-2-可重复级：基本项目管理过程，跟踪费用可重复级：基本项目管理过程，跟踪费用可重复级：基本项目管理过程，跟踪费用可重复级：基本项目管理过程，跟踪费用与进度，有必要的规范以重复类似项目的成与进度，有必要的规范以重复类似项目的成与进度，有必要的规范以重复类似项目的成与进度，有必要的规范以重复类似项目的成功。功。功。功。3-3-3-3-定义级：过程管理文档化、标准化、集成定义级：过程管理文档化、标准化、集成定义级：过程管理文档化、标准化、集成定义级：过程管理文档化、标准化、集成化。使用统一的文档化的组织过程认可的方化。使用统一的文档化的组织过程认可的方化。使用统一的文档化的组织过程认可的方化。使用统一的文档化的组织过程认可的方法开发和维护软件。法开发和维护软件。法开发和维护软件。法开发和维护软件。4-4-4-4-管理级：对软件过程与产品质量进行详细管理级：对软件过程与产品质量进行详细管理级：对软件过程与产品质量进行详细管理级：对软件过程与产品质量进行详细地定量地收集与评估地定量地收集与评估地定量地收集与评估地定量地收集与评估5-5-5-5-优化级：通过定量反馈不断进行过程优化优化级：通过定量反馈不断进行过程优化优化级：通过定量反馈不断进行过程优化优化级：通过定量反馈不断进行过程优化与改进。与改进。与改进。与改进。二、软件工程3、软件开发过程软件生命周期 软件产品或软件系统从设计、软件产品或软件系统从设计、投入使用到被淘汰的全过程。投入使用到被淘汰的全过程。软件生存期的阶段划分(1)(1)可行性研究与计划可行性研究与计划(2)(2)需求分析需求分析(3)(3)总体设计总体设计 (4)(4)详细设计详细设计(5)(5)实现实现(6)(6)集成测试集成测试(7)(7)确认测试确认测试(8)(8)使用和维护使用和维护二、软件工程3、软件开发过程软件开发模型 软件开发模型是软件开发全部过程、软件开发模型是软件开发全部过程、活动和任务的活动和任务的结构框架结构框架。它能直观。它能直观表达软件开发全过程，明确规定要表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。完成的主要活动、任务和开发策略。软件开发模型也常称为：软件开发模型也常称为：软件过程模型软件过程模型 软件生存期模型软件生存期模型 软件工程范型软件工程范型二、软件工程2、软件开发过程瀑布模型 可行性研究与计划可行性研究与计划需求分析需求分析设计设计编码编码运行维护运行维护测试测试定义定义阶段阶段开开发发阶阶段段维护阶段维护阶段按照传统瀑布模型开发软件的特点1.1.阶段间具有顺序性和依赖性。阶段间具有顺序性和依赖性。2.2.推迟实现的观点。推迟实现的观点。3.3.每个阶段必须完成规定的文档每个阶段必须完成规定的文档;每个阶段结束前完成文档审查每个阶段结束前完成文档审查,及早改正错误。及早改正错误。二、软件工程2、软件开发过程原型模型 建造建造/修改修改 原型原型用户测试用户测试运行原型运行原型 听取用听取用 户意见户意见采用原型模型的软件生存周期分析定义分析定义系统需求系统需求生成生成原型原型系统系统设计设计程序程序设计设计编码编码测试测试运运 行行和维护和维护原型化原型化含原型化的含原型化的软件生存期软件生存期二、软件工程2、软件开发过程增量模型 先完成一个系统子集的开发，先完成一个系统子集的开发，再按同样的开发步骤增加功能再按同样的开发步骤增加功能 (系统子集系统子集),),如此递增下去直至如此递增下去直至满足全部系统需求。满足全部系统需求。系统的总体设计在初始子集设计系统的总体设计在初始子集设计阶段就应作出设想。阶段就应作出设想。分析分析 增量模型设计设计 编码编码测试测试 分析分析 设计设计 编码编码测试测试 分析分析 设计设计 编码编码测试测试 分析分析 设计设计 编码编码测试测试 增量增量增量增量1 11 1增量增量增量增量2 22 2增量增量增量增量3 33 3增量增量增量增量n nn n 增量增量增量增量1 11 1交付客户交付客户交付客户交付客户 增量增量增量增量2 22 2交付客户交付客户交付客户交付客户 增量增量增量增量3 33 3交付客户交付客户交付客户交付客户 增量增量增量增量n nn n交付客户交付客户交付客户交付客户日历时间日历时间日历时间日历时间.风险风险分析分析工程工程实施实施用户通信用户通信用户用户评估评估产品维护项目产品维护项目产品维护项目产品维护项目产品增强项目产品增强项目产品增强项目产品增强项目新产品开发项目新产品开发项目新产品开发项目新产品开发项目概念开发项目概念开发项目概念开发项目概念开发项目计划计划计划计划建造及发布建造及发布建造及发布建造及发布2 2、软件开发过程、软件开发过程螺旋模型螺旋模型V1.01.0功功能能时间时间时间时间V2.02.0V1.11.1二、软件工程进一步开发进一步开发实现和集成阶段实现和集成阶段运行状态运行状态实现阶段实现阶段计划阶段计划阶段面向对象分析阶段面向对象分析阶段需求阶段需求阶段维护期维护期2 2、软件开发过程、软件开发过程喷泉模型喷泉模型2、软件开发过程组件模型与软件生产线应用构件应用构件提取车间提取车间 应用应用构件库构件库构件生构件生产车间产车间 构件库构件库组装组装车间车间领域领域 1 1领域领域 2 2应用应用系统系统.1 12 23 34 41 1基础构件，基础构件，2 2功能构件功能构件 3 3接口构件，接口构件，4 4用户界面构件用户界面构件
