《[计算机软件技术基础(第三版)麦中凡 苗明川 何玉洁]第十二章 软件工程过程与软件工程管理》由会员分享，可在线阅读，更多相关《[计算机软件技术基础(第三版)麦中凡 苗明川 何玉洁]第十二章 软件工程过程与软件工程管理（82页珍藏版）》请在金锄头文库上搜索。
1、1,12.1 软件工程概述 1968年软件业界和科学工作者提出了软件工程的概念：任何软件都应当和其他产业的产品一样，由专业人员制作(软件中是系统分析员、高级程序员、程序员)，以系统的、工程的方法开发制作，并提供全方位的售后服务管理(不能因开发者离开、调走而无人管)。 所谓系统的方法，是任何产品都有其创意、开发、生产、调试、使用、维护、退役的全过程，而不是只考虑其中的一部分。如果按照系统的规范或标准进行开发，就可能大幅度提高软件生产力，就如同工业生产取代手工作坊。 所谓工程方法，是指要有工程规范和工程管理。工程产品不要求绝对完善，只要求在给定时间、给定的经费和当前技术条件下符合规范的要求的最佳。
2、工程管理要考虑到可行性、计划性、投入/产出、费用/效益。,第十二章 软件工程过程与软件工程管理,2,软件工程以系统工程的方法制作软件产品，它包括: 软件的系统(生存期)模型； 与此模型相对应的各种规范和标准； 为达到这些规范、标准的方法和工具； 软件生产、交付、使用、维护的全面管理。,3,软件工程的提出，导致了对软件本质的研究。软件不仅仅是可运行的程序系统，为了维护和适应市场技术的发展，它必须有全套完整的文档，所以软件=程序+文档。 软件开发方法学的研究是软件技术发展最活跃的因素。所谓方法学(Methodology)，是一组规范了的方法，按这组方法施行，可以得到较为理想的结果。把这组方法标准化
3、就是软件开发标准。 有了软件规范和标准，软件工具才有市场。软件工具从最初的编译器、连接器、加载运行的必备工具(现在已纳入操作系统范畴)到测试排错工具、格式美化器，到当今可执行的规范说明语言、模型描述代码自动生成工具等。以“软件开发软件”的大量自动工具的出现，构成了良好的软件开发环境(Environment)，即开发和运行工具集的总称。这些集成工具的互联和集成(在单一的界面上可以方便、灵活地使用这些工具)及其支持的软、硬件就构成了软件开发平台(Flat)。,4,12.2 软件工程过程 12.2.1 软件过程活动 过程是活动的序列。先看看软件工程过程有哪些活动内容。 对于软件，ISO 12207生
4、存周期标准建议的过程如图12.1所示。 除了主过程、支持过程、辅助过程是为概念清晰而设的“虚”过程而外其他十二个过程都是要人们实实在在去做的过程。上一章讲的六种活动只是主过程中与技术有关的活动。需求定义可用于获取、供应过程的技术方面(获取还要加上投标、签约等非技术活动)。运营过程不在上章活动之列。,5,软件过程与软件质量 软件过程和程序设计中算法过程非常类似，只不过前者是人们的工程活动，后者是机器的动作(语句)。以活动(语句)的先后刻画时序，活动(语句)可以嵌套，可以并行，活动中的活动是子过程(嵌套子程序调用)。由算法过程对程序质量的重要性可以推断为某个项目排定的软件过程，即项目计划，对软件质
5、量的影响的重大。软件过程是人的活动，有项目追踪，可以中途调整。,6,软件过程有了缺陷一般表现为窝工、返工，如某几个人早已完成模块的单元测试，另一些人的单元测试调不出来，导致无法进行集成调试。再如，需求变了，一些人几个星期的工作白废。造成软件工程延误的原因是多方面的： 人员不胜任 培训不足或高手离职，新手适应周期太短； 问题估计不足 项目固有的问题，开始时看简单了，评估草率； 需求变动过频 用户主义太多，多头决策，缺乏交流； 工具配套不齐 工具、基础设施因到货、培训等各种原因不能正常使用； 信息不足 需求分析时收集信息缺乏某些关键数据； 管理漏洞 某些地方改了，其他人不知道或争议迟迟不决； 决策
6、缺陷 分析模型和顶层设计决策有误，模块相互制约； 人员组织缺陷 只相信高手，不能团结整体，交流太少和薪酬不当； 标准规范不当 选用超前和落伍规范； 过程模型不当 项目计划一开始就脱离实际，调度追踪时人为添乱,7,12.2.2 软件过程模型 严格讲来，本节讨论的是软件开发的过程模型，是上节讨论的主过程或叫关键活动域的模型。 瀑布模型 软件生存周期必经的阶段和软件的开发过程(活动已排定)应该是两个概念。早期软件工程就把它作为开发的过程模型，而且给它严格规定：一个阶段(子过程)完了之后必须做正式技术评审(FTR)；评审后的文档，必须经过正式手续才能改动；做完一个阶段才能开始下一阶段。以为这种“步步为
7、营”的思想能解决大型软件的开发问题。,8,其理论依据是错误发现得越早，改正的费用越小。最后阶段发现第一阶段的错误改正的费用呈几何级数增加(有统计数据表明)。所以它的图示(本书已多次画出，此处不再重复)如同多级瀑布，层层下流，一次完成，隐含的意思是水不能上流。除了编码和详细设计可以反复之外，其余一律不反复。 自瀑布模型在20世纪80年代初随软件工程推出之后，软件规模、质量、开发速度大幅度提高，软件工程学才为人们接受，并作为软件专业的必修课程。然而，20世纪80年代中期以这种模型开发的技术、规范工具都已成熟，其效用反倒没有转型(从结构化程序设计到软件工程)时显著，越严格成本/效益越差。,9,原型模
8、型 原型(Prototyping)的基本思想是尽早拿出反映业务过程核心技术的样板让用户试用一下，修改或补充了需求再接着开发。它基本上按瀑布模型划分阶段：分析设计编码测试交付，但评审后，允许多次反复。哪里有问题就从哪里开始反复，中心思想是早拿出可见的东西与客户磋商。找一个或几个最有代表性的子系统快速编码测试，所以也叫快速原型(Rapid Prototyping)。,10,原型开发导致对开发工具强烈的需求，一体化(即集成)的分析、设计、编码、测试、排错、文档工具，以及跨阶段工具(例如，将流程图自动转换成源代码模型；测试中改了一个错误名字自动把本项目所有文档中该错误名字改正等)大量产生。没有大量计算
9、机辅助软件工程工具(CASE Tools)的支持，原型模型只能是一种理想模型，成不了常用的方法。,11,螺旋模型 随着大量CASE工具涌现，开发一次原型不像手工时代那样费时。此时理解到用户的需求不是一次能说清楚的。开发总有冒险性，要加强与用户通信，增加风险分析。1988年Boehm提出软件开发的螺旋(Spiral)模型，它把软件过程描绘为用户通信计划风险分析做工程(原型) 构造与发布用户评审周而复始的六种活动，即所谓的框架活动。每一框架活动又可细化为若干任务。这种模型对大型新产品特别有效。例如，市售Word、Excel、Lotus Notes等，它们从概念开发最初产品开发产品增强开发产品维护改
10、进，是一个延绵不断的过程。除非退役，否则没有定型，不断改进。只有按里程碑(就是下一次的基线)发布，如Word 5.0、11.0、12.0这种模型成为当前软件开发过程的主流模型。螺旋模型的框架活动如图12.3所示。,12,螺旋模型,13,构件组装模型 面向对象和基于构件包的软件要重用大量构件，这些构件是适用于某个领域的(例如建筑、财经、商场、电信等)。它将以前开发并使用良好的构件规范化之后放入项目库。这类软件的开发过程当今也用螺旋模型，只是把做工程和构造及发布合成一个步骤。风险分析后，转入客户评价。步骤如下： (1) 先标识本项目需要什么构件； (2) 库中查找构件或相似的构件； (3) 如果可
11、用转(4)，否则自行开发或修改，确认后入库； (4) 构造为新系统； (5) 测试、确认。,14,速应用开发模型 有许多信息系统已相当成熟，但新的应用要求极短时间开发出来(6090天)，只能全部利用可重用构件(90%)，其开发技术一般采用第四代技术(4GT)，例如用PB或Delphi做基于数据库的应用。快速应用开发(Rapid Application Development，简称RAD)模型是一线性模型，如图12.4所示。 快速应用开发模型RAD有以下步骤: (1) 业务模型。回答的问题是：以什么信息驱动业务过程运作? 要生成什么信息? 谁生成它? 信息流的去向? 由谁处理? 可以辅之以数据流
12、图。 (2) 数据模型。为支持业务过程的数据流，找出后自然可以求精得到数据对象集合。定义数据对象的属性以及与其他数据对象的关系构成数据模型，可辅之以E-R图,15,快速应用开发模型,16,(3) 处理模型。回答的问题是如何使数据对象在信息流中完成各个业务功能。要描述数据对象的增加、修改、删除、查找，即细化数据流图中的处理框。 (4) 应用程序生成。利用第四代语言(4GL)写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成、构造出整个应用系统。 (5) 测试与交付。由于大量重用，构件一般不用单元测试，只做系统测试，但新创建的构件还是要做单元测试的。 显然，RAD模型的过程
13、缺点也是明显的，它只能在已有构件上做文章，难于提高性能。此外也不适于高风险的项目。,17,12.2.3 一个实用的应用开发过程模型 2000年微软在其解决方案框架(MSF，Microsoft Solution Framework)中提出了自己的应用开发过程模型。该模型综合了瀑布模型和螺旋模型的优点。 受瀑布模型的启发导出基于里程碑的过程，加强了阶段评审，增强了项目的可预断性。参照螺旋模型组织过程，保持了迭代的灵活性，有利于创造。简化了螺旋次数，以发布为中心作一次回环(展开了即线性过程)，传统的开发活动(分析、设计、编码、测试)大部分压缩到一个子过程内，子过程内部活动可以迭代。,18,MSF应用
14、开发过程模型如图12.5所示。从图中看出，它和螺旋模型相近，只是简化为由四个子过程构成的一个回环，以一次发布为终结，下次发布再重复。每个子过程以里程碑分隔，里程碑标识阶段完成，并做成果评审，不通过不往下走。各子过程要做的工作如下：只是简化为由四个子过程构成的一个回环，以一次发布为终结，下次发布再重复。每个子过程以里程碑分隔，里程碑标识阶段完成，并做成果评审，不通过不往下走。各子过程要做的工作如下：,19, 创意(Envisioning)过程 在此期间，小组和客户一起定义业务需求和项目的总目标，即这一次发布要达到什么目标，以前景认可里程碑(方框表示)为其终结，表明小组和客户已就项目的总目标达成一
15、致。 计划(Planning)过程 在此期间，小组和客户一起定义小组要做出什么，以及什么时候怎么做。以项目计划认可里程碑为其终结，表明项目的客户和项目关键的当事人已就要交付出什么东西，以及什么时候交付达成了一致。 开发(Developing)过程 在此期间，小组实现了所有的交付物(软件代码和各种文档)，已按项目预计的范围做完。以范围完成里程碑为其终结，表明本项目软件的所有特征均已开发完成，产品成型并就绪于外部测试和定型。 稳定化(Stabilizing)过程 此间，小组不做大量的开发而是消除所有已发现的问题，以项目发布里程碑为其终结，此后产品可移交给使用方的运营小组。,20,MSF过程模型采用
16、两种里程碑： 主里程碑 即图12.5所示的四种里程碑，表征从一个阶段到另一个阶段的转移，责任角色也随之转移。主里程碑为小组成员、客户、最终用户同步交流交付物及其预期质量(期望值)创造了一个机会，也是各方人员(项目的开发者、支持和桌面帮助人员)一次交流演练的机会，也是关键当事人做同步交流的一个机会。做完主里程碑文档则表示小组与客户及相关人员就做法上达成了一致。,21, 临时里程碑 如果项目工作量大，可以将工作分段成可检测的片断，MSF提出了每一主里程碑之间设置临时里程碑的建议。临时里程碑的作用与主里程碑一样，有利于同步对齐，但比主里程碑灵活，项目组可根据项目性质、大小、类型选用。临时里程碑的建议如下： 创意阶段 组建核心开发组；前景文档草案；风险评估文档草案； 计划阶段 功能规范草案；项目计划草案；项目总调度草案； 开发阶段 按项目特点分若干个内部发布； 稳定化阶段 贝塔测试；零瑕疵完成；安装部署完成；黄金(随时)发布。 微软还建议了内部发布周期，其模型如图12.6所示。
