软 件 工 程Software Engineering

主讲：喻钧

课程的教学和学习方式

本课程采用知识性学习和案例式学习并重的方式进行

学习形式：

1. 课堂知识点学习；

2. 课堂案例交流； 3. 课后案例作业；

4. 课后自我练习题； 5. 补充材料阅读

课程评分方法 (Grading Policies)

（作业 + 实验） 30% + 期末考试 70%

= 总评 100%

教材 (Text Book)

Software Engineering

Second Edition

软 件 工 程

影印版 第 2 版

Shari Lawrence Pfleeger

高等教育出版社 · Prentice-Hall, Inc.

Theory and Practice

理论与实践

参考书目 (References)

软件工程导论（第三版） 张海藩 清华大学出版社（ 199

7 ）

实用软件工程 （第二版）郑人杰、殷人昆、陶永雷 清华大学出版社（ 1996 ）

References

Fundamentals of Software Engineering

Carlo Ghezzi, Mehdi Jazayeri,

Dino Mandrioli

Prentice-Hall, Inc. (1991)

软件工程—实践者的研究方法（第 5版） 

    （美） Roger S.Pressman    译者：梅宏    机械工业出版社（ 2002 ）

其它参考资料

系统 /软件工程研究与实践论坛 http://www.sweforum.net

UML 软件工程组织 http://www.uml.org.cn/

IT 之源 http://www.iturls.com/

UML 之源 http://www.umlchina.com

软件工程协会 http://www.sei.cmu.edu/

科学文献索引 http://citeseer.nj.nec.com/

本讲的内容相关知识点介绍：

1. 软件产品：对相关知识点做一些了解

理解学习基线：

2. 软件工程：构成软件工程基本要素和框架

课堂案例介绍：

3. 案例介绍和启动准备

PART ONE why knowledge of SE is important to practitioners and researchers

Chapter 1 Why SE? The Evolving Role of Software

In the early days: User Computer Software = “Place a sequence of instructions together to get the computer to do something useful”.

In late 1950’s: Computer became cheaper and more common High level languages were invented

ProgrammerUser Computer

In early 1960’s: Very few large software projects were done by some experts.

PART ONE

In middle to late 1960’s:

Truly large software systems were attempted.

Case 1. 美国 IBM 公司在 1963 年至 1966 年开发的 IBM360 机的操作系统。这一项目花了 5000 人一年的工作量，最多时有 1000 人投入开发工作，写出了近 100 万行源程序。据统计，这个操作系统每次发行的新版本都是从前一版本中找出 1000 个程序错误而修正的结果。 这个项目的负责人 F. D. Brooks 事后总结了他在组织开发过程中的沉痛教训时说：“…正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。…程序设计工作正像这样一个泥潭，…一批批程序员被迫在泥潭中拼命挣扎，…谁也没有料到问题竟会陷入这样的困境…”。 IBM360 操作系统的历史教训成为软件开发项目的典型事例为人们所记取。

Software Crisis !

-- NATO Conference, Garmisch, Germany, 1968

Or maybe Chronic Affliction is more

accurate?

PART ONE

What is Software ?

Software is a set of items or objects that form a configuration that includes

instructions (computer programs) that when executed provide desired function and performance,

data structures that enable the programs to adequately manipulate information, and

documents that describe the operation and use of the programs.

AND MORE …（ Characteristics of software） Software is developed or engineered, it is not manufactured in the classical sense.

High quality is achieved through good design

Depend on people

Require the construction of a “product”

PART ONE

Software doesn’t wear out.

Failurerate

Time

Infant mortality Wear

out

Failure curve for hardware

idealized curve

change

increased failurerate due to side effects

actual curve

But it does deteriorate!

There are no software spare parts

Although the industry is moving toward component-based assembly, most software continues to be custom built.

PART ONE

Dramatic improvements in hardware performance

Profound changes in computing architectures

Vast increases in memory and storage capacity

Wide variety of exotic input and output options

More sophisticated and complex computer-based systems

Today(Evolving role of software)

Software =Product (information transformer)

Vehicle for delivering a product (OS, network, tools)

The same questions are still asked today:

Why does it takes so long to get software finished?

Why are development costs so high?

Why can’t we find all the errors before we give the software to customers?

Why do we continue to have difficulty in measuring progress as software is being developed?

PART ONE

Case 2. 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 in’s and out’s of assembler language and Fortran, but nothing about software engineering and even less about project scheduling and tracking. 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. I’m probably close to 75 percent finished.” The boss smiled. “That’s really terrific,” he said. He then told the young engineer to keep up the good work and plan to meet again in a week’s time.

*If you’re wondering whether this story is autobiographical, it is!

PART ONE

A week later the boss called the engineer into his office and asked, “Where are we?” “Everything’s going well,” said the youngster, “but I’ve run into a few small snags. I’ll get them ironed out and be back on track soon.” “How does the deadline look?” the boss asked. “No problem,” said the engineer. “I’m close to 90 percent complete.” If you’ve been working in the software world for more than a few years, you can finish the story. It’ll 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.

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 software support.

Managers —— evaluate, track progress, ......

Programmers —— communicate to each other

Maintainers —— VITAL!

PART ONE

Case 3. 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: Project requirements continually change, but change can be easily accommodated because software is flexible.

PART ONE

Reality: The impact of change is shown by the figure.

Definition Development After release

1x

1.5-6x

60-100x

Cos

t of

cha

nge

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.”

PART ONE

Case 4. 某公园有一游船码头，负责人希望开发一游船管理系统，要求如下： 当游客租船时，管理员输入 S表示租船周期开始；当游客还船时，管理员输入 E表示租船周期结束。一天结束时，要求系统打印出租船次数和平均租船时间。

Algorithm:Number = Total_time = 0;Get Message;While ( ! End_of_stream ) { if (Code == S) { Number ++; Total_time = Start_time; } else Total_time += End_time; Get Message;}Print Number;If (Number) Print Total_time / Number;

新要求：输出一天中的最长租用时间。新要求：将报告分上午和下午输出。新要求：当通信线路出问题时，能从计算中删除一切不完整的租船信息。

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 it’ll take you to get done.” Industry data indicate that between 60 and 80 percent of all effort expended on a program will be expended after it is delivered to the customer for the first time.

Myth: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.

Reality: Software engineering is not about creating documents. It is about creating quality. Better quality leads to reduced rework. And reduced rework results in faster delivery times.

PART ONE

Software Poses Challenges

How do we ensure the quality of the software that we produce?

How do we meet growing demand and still maintain budget control?

How do we upgrade an aging "software plant?"

How do we successfully institute new software technologies?

1.1 What is Software Engineering?

Solving Problems

Problem

Analyzing

Attention: the small ones’ relationships

Synthesis

Any problem_solving technique must have two parts:

Analyzing the problem to determine its nature;

Synthesis the solution based on the analysis.

To help us solve a problem,we use a variety of methods, tools, procedures, and paradigms.

A method or technique is a formal procedure for producing some result.

A tool is an instrument or automated system for accomplishing something in a better way.

A procedure is a combination of tools and technique that,in concert,produce a particular product.

A paradigm represents a particular approach or philosophy for building software.

Where does the software engineer fit in?

Computer Science Customer

theories Computer functions

problem

Software engineering

Tools and techniques to solve problems

1.2 How Successful Have We Been?

Software engineering is about designing and developing high_quality software.

But software is not without its problems.

Sidebar 1.1 Terminology for describing bugs

BUG: is a mistake in interpreting a requirement,a syntax error in a piece of code,or the (as-yet-unknown) cause of a system crash.

FAULT:occurs when a human makes a mistake,called an error,in performing some software activity.A single error can generate many faults,and a fault can reside in any development or maintenance product.

FAILURE:is a departure from the system’s required behavior.It can be discovered before or after system delivery,during testing,or during operation and maintenance.

1.3 What Is Good Software

What we mean by high-quality?

Sidebar 1.2 Perspective on Quality

Garvin describes quality from five different perspective:

The transcendental view,where quality is something we can recognize but not define

The user view,where quality is fitness for purpose

The manufacturing view,where quality is conformance to specification

The product view,where quality is tied to inherent product characteristics

The value-based view,where quality depends on the amount the customer is willing to pay for it

For a software product,we must consider its quality in three aspects:

The quality of the product

The quality of the process

The quality in the context of the business environment

1.4 Who Does Software Engineering?

Builds system

customer Sponsors system development

Users system

userdeveloper

$$ needsContractual obligation

needs

Software system

1.5 A System Approach

A system is a collection of objects and activities,plus a description of the relationships that tie the objects and activities together

The Elements of a System---- Activities and Objects

an activity is something that happens in a system

an object or entity is the element that is involved in the activity

First name Postal code

Middle name Salary per hour

Last name Benefits per hour

Street address Vacation hour accrued

City Sick leave accrued

State

Relationships and the System Boundary

we can think of the system at which we are looking as having a border or boundary. Some item cross the boundary to enter our system, and others are products of our system and travel out for another system’s use.

A system is a collection of things: a set of entities, a set of activities, a description of the relationships among entities and activities, and a definition of the boundary of the system

computer

Date validation calculation printing

mail

Pay information

Pay checks

System boundary

Interrelated Systems

Because very few system are independent of other systems, the concept of boundary is important, and we should know what is within and without the system and what crosses the boundary.

In addition, it is possible for one system to exist inside another system. If so, we can concentrated on a small piece of what is really a much larger system

Reporting system for data

Data management system for collected data

Communication system from remote sites to central

Calculation system for remote data

Remote data collection system

1.6 An Engineering Approach

Building a house

Determining and analyzing the requirements

Producing and documenting the overall design of the house

Producing detailed specification of the house

Identifying and designing the components

Building each component of the house

Testing each component of the house

Integrating the components making final modifications after the residents have moved in

Continuing maintenance by the residents of the house

Building a system

Requirements analysis and definition

System design

Program design

Writing the program

Unit testing

Integration testing

System testing

System delivery

maintenance

1.7 Members of the development team

Requirements analysis and definition

ANALYST

DESIGNER

System design

PROGRAMMER

Program design

Program implementation

Unit testing

Integration testing

System testing

TESTER

System delivery and maintenanceTRAINER

1.9 Information Systems Example

Piccadilly Television Airtime Sales

Advertising agencies

Audience measurement

bureaus

Program suppliers

Broadcasting board

Piccadilly management

Production companies

Copy transmission instructions Campaign

requirements

Selected spots

Spot upgrade request

Agency invoice

Agreed campaign

Ratecard

Suggested campaign

Preemption warning

Upgrade confirmation

Television ratings report

New programProgram

purchase agreement

Programming rules

Program transmission

schedule

Revenue report

Sales target

instruction

Commercial copy

recording

Program transmission

schedule

1.10 Real-time Example

学期项目 :Loan Arranger

计划：全部同学共分为 10 组，每组 8 人，每一个小组推选一位负责人，作为项目经理。项目经理有权利对小组其它的人员进行具体的角色分工和人事调整。每组人员的角色可为： 1. 项目经理 2. 系统分析人员 3. 系统设计人员 4. 系统实施人员 5. 系统测试人员

要求： 项目经理负责：组织、分工、控制进度 ; 对每次组员成绩有 5

分浮动调整权； 项目经理奖罚：引起过半数组员不满，则改选；

带领全组顺利完成任

务，总评 +10 。小组成员：在项目经理的统一协调下完成项目，

根据完成的质量来决定最后的成绩。

内 容1. 需求规格说明书（书面）2. 总体设计报告 （演讲）3. 推出 v1.0 （现场验收）4. 推出升级版（现场验收）5. 面向对象分析练习题一道（演讲）6.推出期末最终版并制作案例总结报告（现场验收和演讲）

目 的 体验软件工程各阶段的主要工作，特别注意吸取教训；

学会与他人合作，培养团队精神，单干户将得不到成绩。

从现在开始，谁也不知道我们的项目会不会成功，但是请牢记：目标、交流与合作、内省