现代软件工程专题1

专题一：软件工程现状及其发展
1. 2. 3. 4. 5. 6. 7. 软件发展现状 软件危机 软件风险 软件工程及其发展阶段 软件工程框架 软件开发模型 软件发展趋势（软件产业化）
一、软件发展现状
（1）已经存在大量正在运行的软件。 金融、电信、航空航天等
（2）软件的应用范围不断扩大。商务、交通、家电等，软件无处不在。 （3）软件的规模与复杂性持续增加
二、软件危机
1.什么是软件危机？
指在计算机软件开发和维护过程中所遇到的一系列问题。
（1）软件开发无计划性：不能正确估计软件开发成本和进度，无 法估计工作量，难于控制开发进度。 （2）软件需求不充分：需求是设计的基础，需求不充分直接导致 软件产品不可靠，满足不了用户的需求，甚至无法使用。 （3）软件开发过程无规范性：各行其是，没有文档。
1968-2000：软件效率、质量、进度、预算无法控制。
一、软件发展现状
问题：
1.没有“计算机”和“软件”，世界会是什么样子？ 人们的生活已经无法离开计算机软件。 2.如何更多、更快、更方便、更好地开发出软件？ 工程化地管理软件开发。（1968年NATO提出软件工程的概念） SE：倡导以工程的原理、原则和方法进行软件开发， 以期解决当时出现的“软件危机”。 3.如何重用过去的经验呢？ 软件体系结构风格、设计模式、部件等。 4.在分布式网络环境下如何提高软件的适应能力呢？ CORBA、COM/DCOM、JavaBean等；EAI。
a. b. c.
3.2 风险分析
• 第三步：风险评估：要考虑风险间的相 互作用。（第二步考虑的是单个风险的影响）
考虑各种风险的综合影响后，对已识别风险发生的 可能性及其后果给出最终的量值； 标明风险优先程度，以便予以适当安排； 考虑其它可替代的方案，寻求可以避免风险的基本 方法。
a. b. c.
3.3 风险评估步骤
四、软件工程及其发展阶段
• 软件工程是一类求解软件的工程，它应用计算机 科学、数学（用于构造模型和算法）和管理科学 （用于计划、资源、质量和成本等的管理）等原 理，借鉴传统工程（用于制定规范、设计范型、 评估成本、权衡结果）的原则和方法，创建软件 以达到提高质量、降低成本的目的。
• 软件工程是一门指导计算机软件开发和维护的工 程学科。
风险管理的时机：
1) 已经发现存在重要的软件风险； 2) 这些风险可能影响项目的目标； 3) 这些风险将使系统花费大量的运行费用及支持费 用； 4) 这些风险是可能防止的。
3.4 风险管理
•
1)
风险管理的任务：
2)
3)
制定风险计划：风险管理计划—RMP和风险排除计划—RA （version）P。（确定风险可接受目标；调整新的“对照风 险”；寻求可替代的解决方案。） 进行风险控制：执行风险计划中体现风险排除策略的控制机制。 （确定风险排除策略：后果、时间和频率；确定风险排除战术： 建立在软件工程过程基础上；建立风险管理计划：有关工作编 入文档｛风险状态估计RES说明项目的总体状况，风险管理计 划RMP说明如何在一个项目中施行风险分析和管理程序，风险 排除计划RAP是排除风险的详细计划｝。） 对风险进行监管：监管软件工程过程和产品，确定风险排除策 略是否达到预期目标，是否有可能进一步改进风险排除计划， 为控制新的风险提供一些必要的决策信息等。
六、软件开发模型
• 软件生命周期：制定计划、需求分析和 定义、软件设计、程序编写、软件测试、 运行/维护等六个步骤。 • 软件开发模型：是从软件项目需求定义 直至软件经使用后废弃为止，跨越整个 生存期的系统开发、运作和维护所实施 的全部过程、活动和任务的结构框架。
6.1 瀑布模型
6.1 瀑布模型
三、软件风险
常见的软件风险类别：进度、经费、性能、组织、 管理、人事、过程、方法、工具等。如下例证：
• 进度过分紧迫； • 预算过分紧张； • 性能过分的超群，软件可靠性要求 过高； • 人员缺乏经验，组织结构不适宜； • 期望过高而不现实； • 没有明确或理解合同的条款； • 软件规模估计不恰当； • 管理部门缺乏经验； • 风险分析和管理不恰当； • 缺乏政策性支持； • • • • • • • • 不熟悉技术或过程； 不熟悉必要的硬件； 需求不一致（或定义不充分）； 需求不断变动； 软件开发计划不恰当； 软件开发过程模型不适用； 缺乏软件工程技术和方法； 缺乏自动化工具的支持；
5.3 软件工程原则
• 软件工程的四条基本原则： 1、采取适宜的开发模型，控制易变的需求； 2、采用合适的设计方法：需要软件模块化、抽象 与信息隐藏、局部化、一致性以及适应性等，需 要合适的设计方法的支的支持。 4、重视开发过程的管理：有效利用可用的资源、 生产满足目标的软件产品、提高软件组织的生产 能力等。
• 1970年，W.Royce提出瀑布模型。 • 特征：活动的输入来自上一活动的输出；完成该 项活动的内容；活动的输出传给下一活动；对活 动的实施工作进行评审。 • 适合：需求明确的任务。 • 优点：以项目的阶段评审和文档控制为手段有效 地对整个开发过程进行指导，从而保证了软件产 品及时交付，并达到预期的质量要求。 • 缺点：成品时间长；缺乏灵活性。
软件工程 目标维
合算性 正确性 可用性
开发范型 设计方法 软件工程 原则维 支持过程 管理过程
需 设
实
确
支
软件工程 活动维
求 计
现
认
持
5.1 软件工程目标
• 目标：生产具有正确性、可用性以及开销适宜 的软件产品。
正确性：软件产品达到预期功能的程度。 可用性：软件基本结构、实现及文档为用户可用的程 度。 开销适宜：软件开发、运行的整个开销满足用户要求 的程度。 决定了：软件过程、过程模型和工程方法的选择。
非常大规模系统：从50万行增加到1000万行，扩大了20倍；
复杂性：a.子系统数目越来越多； b.计算机应用从数值计算开始发展到几百万条指令的大型企业 业务应用，再发展到几千万终端用户直接交互工作的网络应用。
（4）出现了大量与软件相关的标准。CORBA、UML、XMI、TMN等。 （5）软件危机仍然存在（软件脱节）
四、软件工程及其发展阶段
• 软件工程经历了30多年的历史，其发展大致可 以划分为两个阶段：
1、60年代末～80年代初 状况：软件系统的规模、复杂性以及在关键领域的广泛应 用，促进了软件开发过程采纳工程化的方法进行管理。 研究：开发模型、支持工具、开发方法。 成果：瀑布模型、结构化语言（pascal等）、结构化方法、 各种管理方法（如费用估算、文档复审）。 事件：前期主要研究系统实现技术；后期则开始强调管理 和软件质量。 焦点：软件项目
收集信息：主要依靠过去的经验和一些著名的案例， 考虑类似的因素并进行常识性的判断。（如需求变 动的风险）判断收集到的信息是否有用。 信息分类：如：有风险（经常发生的情况）、可预 见的风险（较高概率发生）、不可预见的风险（事 前很难预料），原因可分为：缺乏信息、管理和时 间等。
a.
b.
3.2 风险分析
• 第二步：估计每个风险的大小及其出现的可 能性：度量风险的后果和严重程度。
选择一种度量尺度：命名尺度、序次尺度、坐标尺度、比 例尺度等； 将待估计的风险信息（叙述性、定性、定量三种类型）与 度量尺度相对应，确定风险等级； 消除风险估计中的主观判断的偏差。（缺乏可以用来进行 判断风险的信息，只能凭自己的观念和偏好进行主观理解， 与客观情况必然存在着偏差。）
四、软件工程及其发展阶段
• 近几年： 研究从过程管理转向产品开发，更加注重新 的程序开发范型和软件生产。
范围：面向agent语言、复用技术、需求分析规 格说明的形式化研究、高智能高自动化的 CASE成为热点。
五、软件工程框架
• 软件工程的框架是由软件工程目标、软件工程活 动和软件工程原则三个方面的内容构成的。
• 什么是“对照风险”呢？
对照风险是一组单个风险的集合，也可是对 项目造成最大损害的一个或多个风险。 对照风险考虑了风险间可能发生的耦合或复 合情况。 对照风险说明了在把系统作为整体条件下， 风险会造成系统失败或成功的概率。
3.4 风险管理
• • 风险管理的本质：制定防止风险的计划，并监
管风险。（风险是不可能消除的，只能防止）
四、软件工程及其发展阶段
2、80年代初～现在 状况：“软件工厂”的概念已经提出。 研究：软件生产技术，特别是软件复用技术和软件生产管 理的研究和实践。 成果：提出了具有广泛应用前景的面向对象方法和相关的 编程语言。 事件：软件过程改进。在工业实践中建立起一种量化的评 估程序，判定软件组织成熟的程度。 焦点：软件过程
3.1 风险估计
？是否所有项目都要进行风险分析。
No,风险分析成本较高，只有当软件的成本、性能、作用、 与其他系统间的关系对于重要的系统有比较大的影响时， 即软件的风险对整个系统的成败有关键影响时，才有必要 进行风险分析和管理。
风险估计的步骤
1.明确项目的目标、策略、可以使用的方法和资源； 2.保证项目的目标和结果是可度量的，并标明使用的资源； 3.制定项目成功的标准集合；（见下页） 4.根据估计的结果确定是否进行风险分析。
三、软件风险
• 实践证明： 项目规模越大，问题越复杂，资源、 成本、进度等因素的不确定性就越大， 承担项目所冒的风险也越大。
（因为：项目越大，了解项目的时间越长，系统状态的 确定越长，而风险正是介于确定与不确定之间、无知 和完整知识之间的。）
风险是软件开发不容忽视的潜在的不 利因素，可能损害软件开发过程和质量。
5.2 软件工程活动
• 活动：生产一个最终满足需求且达到工程目标的 软件产品所需要的步骤。
1、需求： 问题分析：需求获取和定义，又称软件需求规约。 需求分析：生成软件功能规约。 2、设计： 概要设计：建立整个软件的体系结构，包括子系统、模 块以及相关层次的说明、每一模块的接口定 义等。 详细设计：产生程序员可用的模块说明，包括每一模块 中数据结构说明及加工描述。 3、实现： 把设计结果转换为可执行的程序代码。 4、确认： 贯穿整个开发过程，对完成的结果进行确认，保证产品 满足用户的要求。 5、支持： 修改和完善活动。