软件工程方法.ppt

软件工程方法,主要内容,1.软件产品及其特点2.软件工程过程及过程模型3.软件项目管理4.面向过程的软件工程方法5.面向对象的软件工程方法6.软件的质量保证体系8.计算机辅助软件工程（CASE）,软件产品及其特点,什么是软件？,能够完成预定功能和性能的可执行的指令；使得程序能够适当地操作信息的数据结构；描述程序的操作和使用的文档。,软件特点,软件是逻辑的而不是物理的产品；软件是由开发或工程化形成的，而不是传统意义上的制造产生的；软件不会”磨损”，但会退化。尽管目前已经进入到基于部件组装的时代，但是绝大多数软件是客户定制方式生产的。,软件发展的历史,早期阶段：（50年代初-60年代中期）面向批处理有限的分布自定义软件第二队段：（60年代中期-70年代末）多用户实时数据库软件产品,软件发展的历史,第三阶段：（70年代中期-80年代中期）分布式系统嵌入”智能”低成本硬件消费者的影响第四阶段：（80年代中期-现在）强大的桌面系统面向对象技术专家系统人工神经网络并行计算网络计算机,软件面临的问题,硬件的发展一直超过软件的发展，使得我们建造的软件难以发挥硬件的所有潜能。我们建造新程序的能力远远不能满足人们能新程序的需求，同时我们开发新程序的速度也不能满足商业和市场的要求。计算机的普遍使用已使得社会越来越依赖于可靠的软件。如果软件失败，会造成巨大的经济损失，甚至有可能给人类带来灾难。我们一直在不断努力建造具有高可靠性和高质量的计算机软件。拙劣的设计和资源的缺乏使提我们难以支持和增强已有软件。,软件工程过程及过程模型,软件工程过程及过程模型,过程规定了所有的主要处理活动过程使用资源，服从一套约束（如时间进度），并产生中间和最终产品。过程可能由许多子过程（它们通过某种方式联接在一起）组成。过程可能被定义为一个过程层次，这样组织起来以便每个子过程有它们自己的过程模型。每个处理活动都有其入口和出口，以便我们知道活动何时开始与结束。活动以一定次序组织起来，以便一个活动相对其他活动应该何时开始清楚。每个过程有一套指导原则来解释每项活动的目标。约束或控制可以应用到一项活动、资源或产品。例如，预算或进度可能限制一个活动可占时间的长度，或者，一件工具可以限制资源利用的方式。软件开发过程有时称为软件生命周期（software life cycle），因为它描述了一件软件产品的生命：从它的概念到实现、交付、使用、和维护。,软件工程过程的阶段,需求分析和定义系统设计程序实现单元测试综合测试系统测试系统交付维护,软件过程模型（SOFTWARE PROCESS MODEL）,瀑布模型（Waterfall Model）V模型（VModel）原型模型（prototyping Model）操作规格（Operational Specification）模型转换模型（Transformation Model）增量开发（Incremental Developmevt）反复开发（iteraeive development）,瀑布模型（Waterfall Model）,每个过程活动相联系的便是里程碑和可交付物，以便项目经理能评估项目实际的项目很少按照该模型给出的顺序进行。用户常常难以清楚地给出所有需求。用户必须有耐心开发者常常被不必要地耽搁,瀑布模型（Waterfall Model）,瀑布模型（Waterfall Model）,V模型（VModel）,V模型是瀑布模型的变种 V模型左侧与右侧的联接暗示如果在验证和确认期间发现问题，那么V的左侧能被重新执行来修改并改进需求。设计和编码。,原型模型（prototyping Model）,原型模型容许快速地建设起系统的全部或部分的理解或澄清。总目标是减少开发中的风险或不确定。,操作规格模型（Operational Specification）,通过演示系统的行为的方式来评价或执行系统需求。操作规格模型允许功能和设计合并,转换模型（Transformation Model）增量开发（Incremental Developmevt）,最初的项目风险和最初的项目需求,重新评估项目计划 成本 工作计划范围/内容,第N次迭代的计划成本计划,访问第N次,消除 风险,重新评估项目风险,第N次迭代的开发成本的开支和 质量保证系统,针对最高的风险确定使用范例的工作计划,第N次迭代,转换模型（Transformation Model）,前期迭代的结果 最近的风险估计 可控的资源(包括模型,代码和 测试数据),新发布说明更新的风险评估可控的资源,初始计划,需求分析,分析和设计,开发实现,测试,准备新发布,选定的使用方案,软件项目管理,软件项目的度量软件项目计划软件项目的风险管理进度安排及跟踪,软件项目的度量,项目度量,项目度量的目的是双重的。首先，这些度量能够指导进行一些必要的调整以避免延迟，并减少潜在问题及风险，从而使得开发时间减到最少。其次，项目度量可在项目进行的基础上评估产品质量，并且可在必要时修改技术方法以改进质量。,软件测量,产品的直接测量，包括产生的代码行（line of code LOC)、执行速度、内存大小及某段时间内报告的缺陷。产品的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性及,面向规模的度量,每千行代码（KLOC）的错误数每千行代码（KLOC）的缺陷数每行代码（LOC）的成本每千行代码（KLOC）的文档页数每人月错误数每人月代码行（LOC）每页文档的成本,面向功能的度量,加权因子测量参数计数简单平均复杂用户输入数*345=用户输出数*457=用户查询数*346=文件数*71015=外部界面数*5710=总计数值FP=总计数值*（0.65+0.01*Fi)其中Fi(i=1到14）取值0-5,面向功能的度量,Fi:1.系统需要可靠的备份和复原吗?2.需要数据通信吗?3.有分布处理功能吗?4.性能很关键吗?5.系统是否在一个已有的、很实用的操作环境中运行?6.系统需要联机数据项吗?7.联机数据项是否需要在多屏幕或多操作之间切换以完成输入?8.需要联机更新主文件吗?9.输入、输入、文件或查询很复杂吗？10.内部处理复杂吗?11.代码需要被设计成可复用的吗?12.设计中需要包括转换及安装吗?13.系统的设计支持不同组织的多次安装吗?14.应用的设计方便用户修改和使用吗?,面向功能的度量,每个功能点（FP）的错误数每个功能点（FP）的缺陷数每个功能点（FP）的成本每个功能点（FP）的文档页数每个人月完成的功能点（FP）数,扩展的功能点度量,复杂度加权因子测量元素 低 平均 高内部数据结构*7+*10+*15=外部数据*5+*7+*10=用户输入数*3+*4+*6=用户输出数*4+*5+*7=用户查询数*7+*4+*6=变换*3+*10+*15=变迁*n/a+*n/a+*n/a=3D函数点指数,软件项目计划,项目估算,估算是一门科学，也是一门艺术估算软件开发工作的资源、成本及进度需要：经验以前完成项目中有用的信息当仅存在定性的数据时进行定量测量的勇气,项目的不确定性,对项目计划中的不确定性产生重大影响的因素复杂性项目的规模结构不确定性的程度历史信息的可用程度,项目计划的目标,项目计划的目标是提供一个框架，使得管理者能够对资源、成本及进度进行合理的估算，并随着项目的进展不断更新项目计划的目标是通过一个信息发现的过程实现的,软件的范围,软件项目计划的第一个活动是确定软件范围软件范围包括：功能、性能、约束条件、接口及可靠性功能包括：系统将做什么？系统将在何时做？有几种操作方式？系统能在何时、怎样被改变或增强？,软件的范围,性能包括：对执行速度，响应时间，或转出有限制？约束条件系统可占用多少物理空间有几种类型的用户 每种类型用户的技术水平怎样,软件的范围,接口包括：转入来自一个或多个别的系统？转出至一个或多个别的系统？有用于格式化数据的规定的方式？,软件的范围,可靠性：系统必须检测并隔离故障失败间的平均时间规定为多少对一次失败后重启系统的最大时间,获取软件范围的信息,获取软件范围的信息的方法：座谈会、问卷调查第一组与项目无关的问题主要集中于用户、总体目标及利益上谁提出了关于这项工作的要求谁将会使用这个解决方案成功的解决方案将获得什么利益是否有其他的解决方案,获取软件范围的信息,第二组问题：进一步了用户对于解决方案的想法你（用户）认为一个成功的解决方案所产生的“好的”输出应该具有什么特征？这个解决方案针对什么问题？你能给我演示（或描述）一下该解决方案被实现的方式？,获取软件范围的信息,最后一组问题：主要集中于会议的效果你是回答这些问题的最合适的人选吗？你的回答是否是“正式的”？我提的问题与你要解决的问题相关吗？我是否问了太多的问题？是否还有其他人能够提供更多的信息是否还有其他我应该问你的问题？,资源,软件计划的第二个任务是估算完成软件开发工作所需的资源：开发环境：硬件及软件工具可复用构件人员,软件项目估算,软件成本及工作量的估算永远不会是一门精确的科学。人员、技术、环境、策略等是影响软件最终成本及开发所需工作量的主要因素。为了可靠地估算成本及工作量：将估算拖延到项目的最后阶段。基于已经完成的类似的项目进行估算。使用简单的“分解技术”来进行项目成本及工作量的估算。使用一个或多个经验模型进行软件成本及工作量的估算。,软件项目估算,软件项目估算的准确性取决于以下因素：计划者是否适当地估算待建造产品规模的程度。把规模估算转换成人的工作量、时间及成本的能力项目计划反映软件项目组能力的程度产品需求的稳定性及支持软件工程工作的环境,软件规模估算,四种估算问题规模的方法（由Putnamt Myers 92年提出)：“模糊逻辑”法功能点法标准构件法修改法,“模糊逻辑”法,要点：计划者必须说明应用软件的类型建立其定性的规模估算在最初的范围内精化该估算利用个人的经验和项目历史数据库功能点法：,标准构件法与修改法,标准构件法要点：软件由若干不同的“标准构件”组成估算出每个标准构件的出现次数使用历史数据来确定每个标准构件交付时的大小修改法要点：项目中包含对已有软件的使用，但该软件必须做某种程度的修改。估算必须完成的修改数目及类型。,估算误差的原因,有时各种估算之间存在着巨大的差别，原因是项目的范围未能被充分理解，或被计划者误解。基于问题的估算技术中所使用的生产率数据对于该应用是不合适的，或是太陈旧了，或是被误用。解决方案：确定引起差别的原因，重新估算，并调和各种估算的结果。,基于过程的估算,估算一个项目的最常用的技术是基于使用的过程进行估算，即，将过程分解为相对较小的活动或任务，再估算完成每个任务所需的工作量。要点：建立问题功能及相关的过程活动例子见P82,经验估算模型,计算机软件的估算模型使用由经验导出的公式来预测工作量，工作量是LOC或FP的函数。支持大多数估算模型的经验数据是来源于一个有限的项目样品集。没有任何估算模型能够适用于所有类型的软件及所有的开发环境。这种模型得出的结果必须谨慎使用。,估算模型的结构,典型的估算模型是通过对以前的软件项目中收集到的数据进行回归分析而导出的。这种模型的总体结构具有如下形式：E=A+B*（ev)C文献中提出了许多面向LOC的估算模型：E=5.2*(KLOC)0.91 Walston-Felix模型E=5.5+0.73*(KLOC)1.16 Bailey-Basili模型E=3.2*(KLOC)1.05 Boehm的简单模型E=5.288*(KLOC)1.047 Doty模型，在KLOC9E=-13.39+0.0545FP Albrecht&Gaffney模型E=60.62*7.728*10-8FP Kemerer模型E=585.7+5.12FP Maston、Barnett&Mellichamp,COCOMO模型,由Boehm81年在其经典著作“软件工程经济学”中提出的，称为：构造性成本模型。Boehm的模型层次具有以下形式：模型1：基本COCOMO模型，将软件开发工作量（及成本）作为程序规模的函数进行计算，程序规模以估算的代码行来表示。E=abKLOCbb D=cbEdb模型2：中级COCOMO模型，将软件开发工作量（及成本）作为程序规模及一组“成本驱动因子”的函数来进行计算。E=aiKLOCbi*EAF模型3：高级COCOMO模型，包含了中级模型的所有特性，并结合了成本驱动因子对软件工程过程中每一步骤的影响的评估。,软件方程式,软件方程式是一个多变量模型，它假设在软件开发项目的整个生命周期中的一个特定的工作量分布。E=LOC*B0.333/P3*(1/t4),小结,软件项目的估算包括：需要多长时间需要多少工作量需要多少人员需要多少资源（硬件及软件）包含的风险,小结,范围说明能够帮助计划者使用一种或多种技术进行估算，这些技术主要分为两大类：分解和经验建模。分解技术需要划分出主要的软件功能，接着估算实现每一功能所需的程序规模或人月数。经验技术使用根据经验导出的公式来预测工作量和时间。软件项目估算永远不会是一门精确的科学，但将良好的历史数据与系统化的技术结合起来能够提高估算的精确度。,风险管理,被动和主动的风险策略,风险:没有办法消除的缺陷。被动的风险策略：最多是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们。主动的风险策略：早在技术工作开始之前就已经启动风险管理。标识出潜在的风险，评估它们出现的概率及产生的影响，且按重要性加以排序，然后软件项目组建立一个计划来管理风险。风险的特征：不确定性、损失,风险分类,项目风险：指潜在的预算、进度、人力（工作人员及组织）、资源、客户及需求等方面的问题以及它们对软件项目的影响。技术风险：指潜在的设计、实现、接口、验证和维护等方面的问题。规约的二义性、技术的不确定性、陈旧的技术及”先进的”技术。商业风险：开发了一个没有人真正需要的优秀产品或系统（市场风险）开发的产品不再符合公司的整体商业策略（策略风险）建造了一个销售部门不知道如何去卖的产品由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）没有得到预算或人力上的保证（预算风险）,识别风险,识别风险是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。标识风险的一个方法是建立风险条目检查表：产品规模与要建造或要修改的软件的总体规模相关的风险 商业影响与管理或市场所加诸的约束相关的风险客户特性与客户的素质以及开发者和客户定期通信的能力相关的风险过程定义与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险开发环境与用以建造产品的工具的可用性及质量相关的风险建造的技术与参与工作的软件工程师的总体技术水平及项目经验相关的风险,风险预测,建立风险表评估风险影响风险评估,风险缓解、监控和管理计划（RMMM计划）,I.引言1.文档的范围和目的2.主要风险综述3.责任A.管理者B.技术人员II.项目风险表1.中止线上的所有风险的描述2.影响概率及影响的因素III.风险缓解、监控和管理N.风险#N,A.缓解I.一般策略II.缓解风险的特定步骤B.监控I.被监控的因素II.监控方法C.管理I.意外事件计划II.特殊的考虑IV.RMMM计划的迭代时间安排表V.总结,项目进度安排及跟踪,项目延迟的原因,一个不现实的截止期限客户需求发生变化对工件量估计不足未将风险考虑项目计划事先无法预计的技术困难事先无法预计的人力困难由于项目组成员间的交流不畅面导致的延期项目管理者未发现进度拖后，未能采取适当的措施,项目管理者的目标,一个大型项目可以分解成许多小的活动。项目管理者的目标是定义所有项目任务，识别关键任务，然后跟踪关键任务的进展以保证“一天一次”的发现进度拖延情况。管理者必须建立一个具有一定详细程度的进度表，使得项目管理者能够监督进度，并控制整个项目。,项目进度安排的两种视角,基于计算机系统的最终发布日期已确定，在此约束下将工作量分布在预先确定的时间框架内假定大致的时间界限已讨论过，但是最终发布日期是由项目开发组设定，且在对软件进行仔细分析之后定义最终发布日期,项目进度安排的原则,阶段划分相互依赖性时间分配工作量确认定义责任定义结果定义里程碑,人员与工作量间的关系,随着项目规模的增加，必然涉及到更多的人员参与随着项目人员的增加生产率呈下降的趋势原因是人与人之间通讯,为项目定义任务集合,过程模型都是由一个任务集合组成的，它使得项目组可以定义、开发和维护计算机软件。一个任务集合包括一组软件任务、里程碑和产品没有一个普遍适用于所有软件项目的任务集合,软件项目的分类,概念开发项目为探索某些新的商品概念或新技术的应用新应用开发项目根据特定的客户需求而承担的项目应用增强项目对现有软件进行可察觉的功能、性能或界面的修改应用维护项目对现有软件进行纠错、适应或扩展再工程项目为了全部或部分重建一个现人系统而承担的项目,项目定义的严格度分类,原则：软件过程的严格度随项目的规模和性质不同而采用不同的严格度要求，但所有项目必须经一种能够按时得到高质量的发布产品的方式来实施严格度的划分：随意的：只需一个最小的任务集合，交保护任务性活动最小化结构化的：在项目中将使用过程框架。框架活动和适用于这种项目类型的相关任务以及为保证高质量所需的保护必活动将得到应用严格的：项目将按严格规程要求应用于项目，所有保护性活动都将被采用快速反应的：只应用了那些为保护软件系统质量所必须完成的任务,严格度适应性准则,项目的规模潜在的用户数量任务的关键性应用程序的寿命需求的稳定性客户与开发者之间通信的容易程度应用技术的成熟度性能约束嵌入式/非嵌入式特性项目人员配置再工程因素,计算任务集合选择因子的值,1）根据项目的特点，给予相应适应性准则适当的等级分2）复审赋予每个适应性准则的加权因子，0.8-1.23）计算：等级分数*加权因子*条目点乘数放入乘积栏中4）计算“乘积”栏中所有条目的平均值（TSS）见P113 图7-1 TSS 1.2 随意的 1.0 TSS 3.0 结构化的 2.4 TSS 严格的,选择软件工程任务,概念开发项目的主要任务：确定概念范围初步的概念计划技术风险评估概念证明概念实现客户对概念的反应,主要任务求精,首先，为主要任务定义项目宏观进度表然后，将宏观进度表精化来创建一个详细的项目进度表,定义任务网络,“任务网络”是一个项目的任务流程的图形表示,I.1确定概念范围,I.2概念计划,I.3B技术风险评估,I.4概念证明,I.5B概念实现,集成A,B,C,I.3A技术风险评估,I.3C技术风险评估,I.5A概念实现,I.5C概念实现,进度安排,两种可以用于软件开发的项目进度安排方法：程序评估和复审技术（RERT）关键路径方法（CPM）两种方法利用以下信息驱动工作量的估算产品功能的分解适当的过程模型的选择项目类型和任务集合的选择,进度安排,两种方法都提供项目工作量划分的工具能够支持：确定关键路径通过使用统计模型为单个任务建立最有可能的时间估算计算为特定任务定义其时间“窗口”的边界时间,时间表和进度跟踪,时间表：输出结果为甘特图（Gantt Chart)进度跟踪和控制：定期举行项目状态会议评估所有在软件工程过程中所进行的复审的结果确定正式的项目里程碑是否在预定日期内完成比较项目表中列出的各项任务的实际开始日期与计划开始日期与戈者进行非正式会谈，获取他们对项目进展及可能出现的问题的客观评估,甘特图,项目计划,软件工程过程中的每一步骤都应该产生可以被复审，并能作为后续步骤的基础工作产品软件项目计划是一种面向广大读者的简短文档在软件管理者、技术人员和客户间传达项目范围和资源信息定义风险并提出有关风险管理技术的建议定义管理复审的成本和进度为与项目相关的所有人员提供软件开发的整体方法概述如何保证质量及变化的管理软件项目计划大纲,软件项目计划大纲,I.引言A.计划的目的B.项目的范围和目标1.范围说明2.主要功能3.性能问题4.管理及技术约束II.项目估算A.用于估算的历史数据B.估算技术C.工作量、成本和持续时间的估算III.风险管理策略A.风险表B.对需管理的风险的讨论C.每个风险的RMMM计划1.风险缓解2.风险监控,3.风险管理(意外事件计划)IV.进度A.项目工作细分结构B.任务网络C.时间表(甘特图)D.资源表V.项目资源A.人员B.硬件和软件资源C.特殊资源VI.人员组织A.项目组结构(如果需要)B.管理报告VII.跟踪及控制机制A.质量保证和控制B.变化管理和控制VIII.附录,面向过程的软件工程方法,需求分析及分析建模软件设计,需求分析及分析建模,软件需求分析,需求分析任务是发现、求精、建模和规约的过程需求分析可被划分成5个工作阶段：问题分析问题评估和方案综合建模规约复审,分析原则,必须表示和理解问题的信息域必须定义软件将完成的功能必须表示软件的行为（作为外部事件的结果）必须划分描述信息、功能和行为的模型，从而使得可以以层次的方式提示细节分析过程应该从要素信息移向细节实现,三个模型,信息模型E-R图或IDEF1图功能模型数据流图或IDEF0图行为模型状态图,软件需求规格说明,A.引言A1.目的A2.文档约定A3.预期的读者和阅读建议A4.产品范围A5.参考文献B.综合描述B1.产品的前景B2.产品的功能B3.用户类型和特征B4.运行环境B5.设计和实现上的限制B6.假设和依赖C.外部接口需求C1.用户界面C2.硬件接口C3.软件接口C4.口通信接口,D.系统特性D1.说明和俦级D2激励/响应序列D3.功能需求E.其它非功能需求E1.性能需求E2.安全设施需求E3.安全性需求E4.软件质量属性E5.业务规则E6.用户文档F.其它需求附录A:词汇表附录B:分析模型附录C:待确定问题的列表,软件设计,设计的重要性,软件设计处于软件工程过程中的技术核心位置设计是将一个实际问题转换成相应的解决办法的主动过程。所谓设计也可以是对一种解决办法的描述 目标是生成一个随后要构造实体的一种模型或表示设计是我们能将用户需求准确地转化为完整的软件产品或系统的唯一方法。软件设计是所有软件工程和软件维护步骤的基础。,设计的内容,设计阶段产生数据设计、体系结构设计、接口设计和过程设计。数据设计将分析时创建的信息域模型变换成实现软件所需的数据结构。结构设计定义了程序的主要结构元素之间的关系。接口设计描述了软件内部、软件和协作系统之间以及软件同人之间如何通信。过程设计将程序体系结构的结构元素变换为对软件构件的过程性描述。,设计质量的评估,设计应该展示一种层次性组织，从而可以指导使用软件元素间的控制。设计应该模块化，即逻辑地划分成完成特定功能和子功能的构件。设计应该既包括数据抽象，也包括过程抽象。设计应该导出具有独立功能特征的模块。设计应该导出降低模块和外部环境间复杂连接的接口。设计应该通过使用由软件需求分析过程中获得的信息导出要驱动的可重复的方法。,设计原则,设计过程不应该受“隧道视野”的限制。设计对于分析模型应该是可跟踪的。设计不应该从头做起。设计应该缩短软件和实现之间的距离。设计应该表现出一致性和集成性。设计应该构造成适应修改。设计应该使得即使遇到异常的数据、事件或操作条件时也能平滑、轻巧地降级。设计不是编码，编码也不是设计。在创建设计时就应该能够评估质量，而不是在事情完成之后。应该复审设计以减少概念性（语义性）错误。,设计概念,抽象：在解决设计问题时，可以给出许多抽象级别，在最高的抽象级别中，解决方案使用问题环境的语言来进行概括性的描述；在低一些的抽象级别中，会有更加面向过程的倾向；最后在最低的抽象级别中，用能够直接实现的方式描述解决方案。软件工程过程中的每一步骤都是软件解决方案抽象级别上的求精。求精：求精是一种自顶向下的设计策略。程序的体系结构是通过过程细节的逐步层次精化开发，层次结构逐步地分解功能的宏观声明，直至形成程序设计语言的语句。求精是一个推敲的过程。从高抽象级别定义的功能描述开始，在后续的求精过程中提供越来越多的细节。,模块化设计,模块化：软件被划分成独立命名和可独立访问的被称为模块的构件，它们集成到一起满足问题的需求。软件通过划分可将程序设计的复杂性大大降低。极限情况无限制地划分软件，那么开发它所需的工作量会变得小到可以忽略。但随着划分模块数量的增加，模块集成的工作量会急剧上升。因此开发过程中存在一个模块划分的合理区间，即最小成本区域。（见P243）,定义模块方法的五个标准,1）模块可分解性。如果一种设计方法提供了将问题分解成子问题的系统化机制，它就能降低整个系统的复杂性，从而实现一种有效的模块化解决方案。2）模块可组装性。如果一种设计方法使现存的（可复用的）设计构件能被组装成新系统，它就提供一种不一切从头开始的模块化解决方案。3）模块可理解性。如果一个模块可以作为一个独立的单位（不用参考其他模块）被理解，那么它就易于构造和修改。4）模块连续性。如果对系统需求的微小修改只导致对单个模块，而不是整个系统的修改，则修改引起的副作用就会被最小化。5）模块保护。如果模块内出现异常情况情况，并且它的影响限制在模块内部，则错误引起的副作用就会被最小化。,结构划分,程序结构应该被水平和垂直地划分水平划分为每个主要程序功能定义了分离的模块结构分支。其优点：产生易于测试的软件。产生易于维护的软件。产生副作用更小的传播。产生易于扩展的软件。主要功能相互分离，修改变得更加简单。缺点：水平划分常常通过模块接口传递更多的数据，使程序流的整体控制复杂化,结构划分,垂直划分：常常称为因子划分要求发生在程序体系结构中，且工作应该自顶抽下分布，项层模块应该执行控制功能，而少作实际处理工作，在层次结构中位于低层次的模块应该是工作者，它们完成所有的输入、计算和输出任务。,模块设计的方面,数据结构：决定信息的组织、访问方法、关联程度、可替换的处理方法软件过程：软件过程着重于每个模块单个的处理细节，过程必须提供处理的精确定义，包括事件的顺序、准确的决策点、循环操作信息隐蔽：模块应该设计成其中包含的信息对不需要这些信息的其他模块是不可访问的,有效的模块设计,模块化设计降低了设计的复杂性，方便了修改，并且通过鼓励系统的不同部分的并行开发简化了实现。功能独立性：功能独立性是模块化和抽象及信息隐蔽概念的直接产物。将软件设计成每个模块完成需求的一个特定子功能，并且从程序结构的其他部分观察时具有简单的接口。内骤耦合,确定设计的五种方法,模块化分解：在把功能分配到各个组成部分(component)的基础上进行构造。设计者开始于功能的顶层描述上，然后在较低的层次上说明各组成部分是如何组织的以及各部分是如何关联的面向数据的分解：这种设计是基于外部数据结构的。顶层描述总体的数据结构，而底层描述所包含的数据元素及它们之间的关系这些细节。面向事件的分解：这种设计是基于系统必须处理的事件和有关事件是怎样改变系统状态的信息。顶层描述是将各种各样的状态分类，而较低层次是描述状态转换是怎样发生的。有外向内的设计：这种黑盒方法是基于用户对系统的输入。也就是说，顶层描述列出所有可能的用户输入，而较低层次的描述是对于用户的这些输入(及可能产生的输出)，系统要做什么的描述。面向对象的设计：这种设计将对象类和它们之间的相互关系关联起来。顶层是对每一个对象类型的描述，而在较低层次上是对象的属性、行为的描述和对象是怎样和另一个对象相关联的解释。开发所需工作量的主要因素。,面向对象的软件工程方法,软件的质量保证体系,CMM,应美国联邦政府评估软件供应商的能力的要求，由美国卡内基梅隆大学软件工程研究院推出的能力成熟度模型；将软件企业的生产能力划分为5个成熟度等级，等级愈高的企业，其软件过程的可见度愈好、软件过程的可控性愈高、产品性能的预见行以及软件项目的风险评估亦愈来愈准确。企业的生产能力以及产品质量也就愈来愈高；强调企业软件生产过程的持续改进；此外CMM也不仅仅应用于软件开发组织内,它也可作为认证机构的认证工具和用户考核一个企业是否达到其所要求的能力的依据。,CMM家族,CMM集成产品集SA-CMM（软件获取能力成熟度模型）：用于单位获取和采购基于软件的应用系统的软件过程SE-CMM（系统工程能力成熟度模型）：描述一个单位为保证实现一个好的系统工程的主要元素IDEAL模型；一个单位用于启动、规划和实现过程改善措施蓝图的模型，概括了建立一个成功的过程改善项目的必要步骤。,CMM 的五层体系结构,CMM结构,成熟度级别,关键过程区域,关键惯例,CMM五级特征,初始级：企业一般不具备稳定的软件开发与维护的环境。常常在遇到问题的时候，就放弃原定的计划而只专注于编程与测 试。可重复级：建立了管理软件项目的政策以及为贯彻执行这些政策而定的措施。基于过往的项目的经验来计划与管理新的项目。定义级：有关软件工程与管理工程的一个特定的、面对整个企业的软件开发与维护的过程的文件将被制订出来。同时，这些过程是集成到一个协调的整体。这就称为企业的标准软件过程。定量管理级：企业对产品与过程建立起定量的质量目标，同时在过程中加入规定得很清楚的连续的度量。作为企业的度量方案，要对所有项目的重要的过程活动进行生产率和质量的度量。软件产品因此具有可预期的高质量。优化级：整个企业将会把重点放在对过程进行不断的优化。企业会采取主动去找出过程的弱点与长处，以达到预防缺陷的目标。同时，分析有关过程的有效性的资料，作出对新技术的成本与收益的分析，以及提出对过程进行修改的建议。,PSP,使用自底向上的方法来改进过程，向每个软件工程师表明过程改进的原则，使他们能够明白如何有效地生产出高质量的软件。为基于个体和小型群组软件过程的优化提供了具体而有效的途径。其研究与实践填补了CMM的空白。,个体软件过程PSP的演化,TSP,致力于开发高质量的产品，建立、管理和授权项目小组，并且指导他们如何在满足计划费用的前提下，在承诺的期限范围内，不断生产并交付高质量的产品。,实现TSP方法需要具备的条件,整个软件开发小组至少应在CMM的第二级（可重复层）。全体软件开发人员必须经过PSP的培训。开发小组成员应在2到20个人之间。,CMM、PSP和TSP组成的软件过程框架,CMM,PSP,TSP,原则,技能,费用,期限,组织级能力,高质量的产品,个人的技能,建立,生产并交付,建立,CMM对企业的要求和帮助,基于CMM模型的软件成熟度实践要求要求尽量采用更加规范的开发标准和方法;使用更加科学和精确的度量手段;选择更便于管理和使用的开发工具.因此造成了整个工程的可重构性、可分解性和最优化；明确了整个项目中必要和不必要的工作；明确了整个项目的风险,以及各个阶段进行评估的指标与应急措施,ISO9000与CMM的关系,ISO9000相当于CMM二级和三级的一部分内容(有人称为2.5级)CMM和ISO9000认证本身没有优劣之分CMM是一个动态的过程对于预算、项目周期管理等ISO9000涉及不够的内容，CMM有所覆盖,ISO9000与CMM的区别,ISO9000是通用的国际标准,适用于各类组织。CMM是美国军方为评价软件供应商的质量水平,委托SEI开发的一个评价模型,只用于软件业。CMM更详细,更专业。ISO9000只建立了一个可接受水平，而CMM是一个具有五个水平的评估工具。ISO9000聚焦于供应商和用户间的关系，而CMM更关注软件的开发过程。,TickIT-欧洲的规则,是根据ISO9000认证软件开发组织的体系(system)是为软件的需要对ISO9000的诠释(interpretation)包括对审核员的表现和竞争力的一组标准要求包括对审核员标准化培训的课程包括审核员注册的程序(scheme)从事TickIT认证的认证机构的认可制度,ISO9000认证,ISO9000：机构必须经过认可人员必须取得注册经认可的认证中心可发证书结论只有通过或不通过,CMM认证(1),CMM：评审员由SEI认定授权每隔两年重新评定一次资格基本要求是：至少年软件开发质量保证经验至少两年软件项目管理经验评估框架同ISO9000类似结果报SEI评定结果有五个等级,CMM认证(2),目前全球通过CMM五级的企业已有23家印度通过CMM5级的企业就有15家CMM在中国 北京鼎新信息系统开发有限公司ASDC(中国首家通过CMM2级评审)沈阳东大阿尔派软件股份有限公司(成功通过CMM2级评审)摩托罗拉中国软件中心(通过国际CMM顶级5级认证)联想软件事业部(通过CMM2级),TickIT认证,TickIT：机构必须取得UKAS(英国皇家认可委员会)的认可审核员必须是TickIT审核员(经过专门的认可)其它基本同ISO9000一致,软件企业的认证与认可选择,在数量上，软件、计算机及相关企业采用ISO9000认证的为最多。欧洲的企业较多地采取TickIT/ISO9001认证 的方式。申请CMM认证的多为美国的公司或者是有美国背景的公司。在已取得CMM认证的企业当中，以CMM级居多，能够达到级的企业寥寥可数，甚至、级的都不多,计算机辅助软件工程(CASE),计算机辅助软件工程：CASE,CASE工具帮助软件工程管理者和实践者完成与软件过程相关的每一个活动。CASE结构组成,CASE Tools,Integration Framework,Portability Services,Operating System,Hardware Platform,Environment Architecture,CASE工具的分类（1）,业务过程工程工具过程建模与管理工具项目计划工具风险分析工具项目管理工具需求跟踪工具协调和管理工具文档工具,CASE工具的分类(2),质量保证工具数据库管理工具软件配置管理工具分析和设计工具原型和仿真工具界面设计和开发工具原型工具编程工具Web开发工具和集成与测试工具等,