软件和软件工程.ppt

1 第1章 软件和软件工程 什么是软件? 2 软件是： (1)指令的集合(计算机程序)，通过执行这 些指令来满足预期的特征、功能和性能需求； (2)数据结构，使得程序可以合理的利用信 息； (3)文档描述，用来描述程序操作和使用。 Late 1950s: 软件危机 （Software Crisis) In the early days: “Software” = “Place a sequence of instructions together to get the computer to do something useful”. User Computer Computer became cheaper and more common High level languages were invented ProgrammerUser Computer easier Early 1960s: Very few large software projects were done by some experts. Middle to late 1960s: Truly large software systems were attempted. 例: 美国IBM公司在1963年至1966年开发的 IBM360机的操作系统。这一项目花了5000人一 年的工作量，最多时有1000人投入开发工作， 写出了近100万行源程序。据统计，这个 操作系统每次发行的新版本都是从前一版本中 找出1000个程序错误而修正的结果。 这个项目的负责人F. D. Brooks事后总结了他 在组织开发过程中的沉痛教训时说：“正像 一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣 扎，陷得越深，最后无法逃脱灭顶的灾难。 程序设计工作正像这样一个泥潭，一批批程 序员被迫在泥潭中拼命挣扎，谁也没有料到 问题竟会陷入这样的困境”。IBM360操作系 统的历史教训成为软件开发项目的典型事例为人们 所记取。 Software Crisis ! 在计计算机软软件开发发和维护过维护过程中所遇到的一系列 严严重问题问题 项目没有被很好地理解；计划不周，最终导致 进度拖延。 例1. In the late 1960s, a bright-eyed young engineer* was chosen to “write” a computer program for an automated manufacturing application. The reason for his selection was simple. He was the only person in his technical group who had attended a computer programming seminar. He knew the ins and outs of assembler language and Fortran, but nothing about software engineering and even less about project scheduling and tracking. *If youre wondering whether this story is autobiographical, it is! 问题出在哪里？ His boss gave him the appropriate manuals and a verbal description of what had to be done. He was informed that the project must be completed in two months. He read the manuals, considered his approach, and began writing code. After two weeks, the boss called him into his office and asked how things were going. “Really great,” said the young engineer with youthful enthusiasm, “This was much simpler than I thought. Im probably close to 75 percent finished.” The boss smiled. “Thats really terrific,” he said. He then told the young engineer to keep up the good work and plan to meet again in a weeks time. A week later the boss called the engineer into his office and asked, “Where are we?” “Everythings going well,” said the youngster, “but Ive run into a few small snags. Ill get them ironed out and be back on track soon.” “How does the deadline look?” the boss asked. “No problem,” said the engineer. “Im close to 90 percent complete.” If youve been working in the software world for more than a few years, you can finish the story. Itll come as no surprise that the young engineer stayed 90 percent complete for the entire project duration and only finished (with the help of others) one month late. 例2： In the early 1980s, the United States Internal Revenue Service (IRS) hired Sperry Corporation to build an automated federal income tax form processing system. According to the Washington Post, the “system has proved inadequate to the workload, cost nearly twice what was expected and must be replaced soon” (Sawyer 1985). In 1985, an extra $90 million was needed to enhance the original $103 million worth of Sperry equipment. In addition, because the problem prevented the IRS from returning refunds to taxpayers by the deadline, the IRS was forced to pay $40.2 million in interest and $22.3 million in overtime wages for its employees who were trying to catch up. In 1996, the situation had not improved. The Los Angeles Times reported on March 29 that there was still no master plan for the modernization of IRS computers, only a six-thousand-page technical document. Congressman Jim Lightfoot called the project “a $4-billion fiasco that is floundering because of inadequate planning” (Vartabedian 1996). Myth: If we get behind schedule, we can add more programmers and catch up. Reality: Software development is not a mechanistic process like manufacturing. In the words of Brooks, “adding people to a late software project makes it later.” 1.软件危机 没有充分的文档资料(documentation) Myth: The only deliverable for a successful project is the working program. Reality: A working program is only one part of a software configuration that includes programs, documents, and data. Documentation forms the foundation for successful development and, more important, provides guidance for the software maintenance task. VITAL! 人与人的交流比写程序困难得多。 Managers evaluate, track progress, Programmers communicate to each other Maintainers 软件可靠性(reliability)缺少度量的标准，质 量无法保证。 如何保证软件产品的质量，是非常复杂困难 的问题。特别对于规模庞大的软件，如：. The software supporting the American space shuttle consists of 3 million lines of code, including computers on the ground controlling the launch and the flight; there were one hundred thousand lines of code in the shuttle itself in 1985. President Reagans proposed Strategic Defense Initiative (SDI) is estimated to require 10 to 100 million lines of code. Many computer scientists and software engineers continue to believe there is no way to write and test the software to guarantee adequate reliability. 软件难以维护 (maintainability) 不易升级(evolvability) Myth: Once we write the program and get it to work, our job is done. Reality: Someone once said that “the sooner you begin writing code, the longer itll take you to get done.” Industry data indicate that between 50 and 70 percent of all effort expended on a program will be expended after it is delivered to the customer for the first time. Better management Different team organizations Better languages & tools Uniform coding conventions 必须意识到：“软件” 编程，它有自己的 生命周期 (life cycle)。大型软件系统的开发与 其它工程项目如建造桥梁、制造飞机、轮船等 的开发是同理的。 “软件工程”(Software Engineering)：采用工程的概念,原 理，技术和方法来开发和维护软件 NATO Conference , Garmisch , Germany , 1968. 解决问题的想法： 软件与硬件不同的特征？ n软件是设计开发的，而不是传统意 义上的生产制造的。 n软件不会“磨损”。 n虽然整个工业向着基于构件的构造 模式发展，然而大多数软件仍是根 据实际的顾客需求定制的。 15 磨损vs.退化 16 失效率 变更点 由于变更的副作用而导致 失效率提高 实际曲线 理想曲线 时间 软件应用领域（7个 ） n系统软件 n应用软件 n工程/科学软件 n嵌入式软件 n产品线软件 nWeb应用软件 n人工智能软件 17 面临新的挑战 n开放计算无线网络将促使普适计算、分布式计算的实现。 n网络资源万维网成为一个计算引擎和内容提供平台。 n开放源码 系统应用程序的源代码对外开放。 n其他 （参见第31章） n数据挖掘 n网格计算 n认知机 n纳米技术软件 18 遗留软件 n软件必须进行适应性调整，以满足新的计算 环境和技术的需求。 n软件必须升级以实现新的商业需求。 n软件必须扩展使之具有与更多现代系统和数 据库的互操作能力。 n软件必须进行改建使之能适应多样化的网络 环境。 19 在几十年前开发，不断被修改以满足商 业需要和计算平台变化的软件系统。 为什么一定要变更? WebApps的特性 - I n网络密集型：WebApp 驻留在网络上，服务 于不同客户群体的需求。 n并发性：大量用户可能同时访问WebApp 。 n无法预知的负载量：WebApp的用户数量每天 都可能有数量级的变化。 n性能： 如果一位WebApp用户必须等待很长 时间（访问、服务器端处理、客户端格式化 显示），该用户就可能转向其他地方。 n可用性：尽管期望百分百的可用性是不切实 际的，但是对于热门的WebApp，用户通常要 求能够24/7/365（全天候）访问。 20 WebApps的特性 - II n数据驱动：许多WebApp的主要功能是使用超媒体向最终 用户提供文本、图片、音频及视频内容。 n内容敏感性：内容的质量和艺术性仍然很大程度上决定了 WebApp的质量。 n持续演化：传统的应用软件是随一系列规划好的时间间隔 发布而演化的，而Web应用则持续地演化。 n即时性：尽管即时性也就是将软件尽快推向市场的迫切 需求是很多应用领域的特点，然而将WebApp投入市场 可能只是几天或几周的事。 n安全性：由于WebApp是通过网络访问来使用的，因此要 限制访问的最终用户，即使可能也非常困难。 n美观性：不可否认，WebApp的用户界面和外观很有吸引 力。 21 软件工程 n几个事实: n在制定软件解决方案之前，必须尽力解决问 题 n设计已成为关键活动 n软件必须保证高质量 n软件需具备可维护性 n种子定义（Bauer）： n（软件工程是）建立和使用一套合理的工程 原则，以便经济地获得可靠的、可以在实际 机器上高效运行的软件。 22 软件工程 nIEEE 定义(p.7) 软件工程是：（1）将系统化的、规范的、可量化的方 法应用于软件的开发、运行和维护，即将工程化方法应 用于软件。（2）在(1)中所述方法的研究。 n软件工程包括过程、方法和工具。 n过程定义了一个框架，是有效实施软件工程必不可少的 。 n方法为构建软件提供技术上的解决方法。 n工具为过程和方法提供自动化（或半）的支持 23 一种层次化技术 24 Software Engineering a “quality” focusa “quality” focus process modelprocess model methodsmethods toolstools工具工具 过程过程 方法方法 质量关注点质量关注点 软件工程 一种过程框架 25 过程框架过程框架 框架活动框架活动 工作任务 工作产品 里程碑和可交付成果 QA 检查点 普适性活动普适性活动 过程框架活动(5个) n沟通（理解利益相关者的项目目标） n策划（定义和描述软件项目计划） n建模 n需求建模需求模型 n软件设计设计模型 n构建 n编码 n测试 n部署（交付给用户） 26 普适性活动（8个） 帮助软件团队管理和控制项目进度、质 量、变更和风险 n软件项目跟踪和控制 n风险管理 n软件质量保证 n技术评审 n测量 n软件配置管理 n可复用管理 n工作产品的准备和生产 27 适应过程模型 软件过程并不是教条的法则，不同项目所采用的 项目过程可能有很大不同 n活动、动作和任务的总体流程，以及它们之间相互依赖关系 n在每一个框架活动中，动作和任务细化的程度 n工作产品的定义和要求的程度 n质量保证活动应用的方式 n项目跟踪和控制活动应用的方式 n过程描述的详细程度和严谨程度 n客户和利益相关者对项目参与的程度 n软件团队所赋予的自主权 n队伍组织和角色明确程度 敏捷过程模型强调项目的灵活性，并在一 些基本原则的指导下，采用非正式的方 式执行软件过程。 28 实践的精髓 nPolya 建议： 1.理解问题（沟通分析）。 2.计划解决方案（建模和软件设计）。 3.实施计划 （代码生成）。 4.检查结果的准确性（测试和质量保证）。 29 理解问题 n谁将从问题的解决中获益？也就是说， 谁是利益相关者？ n什么是未知的？哪些数据、功能、特征 和行为是解决问题必需的？ n问题可以划分吗？是否可以描述为更小 、更容易理解的问题？ n问题可以图形化描述吗？可以建立分析 模型吗？ 30 计划解决方案 n以前曾经见过