SSD9: Software Specification, Testing, and SSD9: Software Specification, Testing, and MaintenanceMaintenance

Course Resource:Course Resource:

My email address:My email address:xiongqw@gmail.comxiongqw@gmail.com

Web site for this course materialsWeb site for this course materialshttp://www.icarnegie.com/http://www.icarnegie.com/

Web site for this course information: Web site for this course information: http://c4se.51.net/se/index.htmhttp://c4se.51.net/se/index.htm

Time for questioning and answering:Time for questioning and answering:1.Before or after class1.Before or after class2.When do practice in lab2.When do practice in lab

Lecture and practice arrangement Lecture and practice arrangement

周数周数 内容 周数周数 内容11 上课上课 1010 上机练习上机练习22 上课上课 1111 上课上课33 上课上课 1212 上机练习上机练习44 上机练习上机练习 1313 上课上课55 上课上课 1414 上机练习上机练习 //测试测试66 上机练习上机练习 1515 上课上课77 上课上课 1616 上机练习上机练习88 上机练习上机练习 //测试测试 1717 上课上课99 上课上课 1818 上机练习上机练习 //测试测试

Overview ---- about our courseOverview ---- about our course This course is an introduction to This course is an introduction to software engineeringsoftware engineering.. Including the principles and practices that contribute to Including the principles and practices that contribute to

producing producing betterbetter software software making software development more making software development more predictablepredictable and and economicaleconomical. .

You will learn about You will learn about how software development practices have changed in the last few how software development practices have changed in the last few

decades(decades( 面向过程 面向过程 – – 面向对象面向对象 )) the different phases that a software product goes through. the different phases that a software product goes through.

You will studyYou will study specific techniques for improving the quality of products, for each specific techniques for improving the quality of products, for each

phase of software developmentphase of software development You will read about You will read about

the interactions and expectations of groups and organizations that the interactions and expectations of groups and organizations that participate in the software development process. participate in the software development process.

course organizationcourse organization

The course is organized into The course is organized into eighteight units, each with several sections. units, each with several sections.

All units have All units have a multiple-choice quiz (sum. 8 )a multiple-choice quiz (sum. 8 ) a practical exercise (but the first unit, sum. 9). a practical exercise (but the first unit, sum. 9).

The exercises are part of the project for the course and lead The exercises are part of the project for the course and lead you to create a software product from start to finish. you to create a software product from start to finish.

There are also There are also threethree in-class exams. in-class exams.

Prerequisites Prerequisites

SSD4 User-Centered Design and TestingSSD4 User-Centered Design and Testing SSD7 Database SystemsSSD7 Database Systems

Course Textbook Course Textbook The required textbook for the course is:The required textbook for the course is:

Schach, Stephen. Schach, Stephen. Object-Oriented and Classical Object-Oriented and Classical Software EngineeringSoftware Engineering. 6th ed. 6th ed

Reference booksReference books 软件工程：实践者的研究方法（第软件工程：实践者的研究方法（第 66 版）版） , , （美）（美） ROGER S.PRESSMAN ROGER S.PRESSMAN 软件工程导论（第四版） 软件工程导论（第四版） ,, 张海藩 张海藩 人月神话 人月神话 , , （美）（美） Frederick P. BrooksFrederick P. Brooks ，， Jr. Jr. MySQLMySQL 使用指南使用指南 Java/jdbcJava/jdbc 程序设计程序设计 大量专门针对开发各阶段的技术与方法书籍大量专门针对开发各阶段的技术与方法书籍

需求工程需求工程 OOA/OODOOA/OOD 编程实践编程实践 个人个人 // 小组过程小组过程 测试测试 …………

Assigned ReadingAssigned Reading

A complete list of A complete list of SSD9 Required ReadingsSSD9 Required Readings has has been compiled for your reference.been compiled for your reference.

SSD9 Required Readings SSD9 Required Readings Section Sixth Edition Fifth Edition1.2 1.1 1.1 1.3 1.2–1.10 1.2–1.61.4 1.11 1.7 and 2.1 2.1 3.1–3.2  2.1.2 3.3–3.4, 10.1–10.4 2.2, 2.3, and 10.1 2.1.3 3.5 2.4 2.1.4 3.6 2.5 2.1.5 3.7 2.6 2.1.6 3.8 2.7 2.2 2.1–2.8  2.2.1 2.9.1 3.1

SSD9 Required Readings SSD9 Required Readings Section Sixth Edition Fifth Edition2.2.2 2.9.2 3.22.2.3 2.9.3, 10.12–10.14 3.3, 10.3–10.7 2.2.4   3.4 2.2.5 2.9.5 3.6 2.2.6 2.9.6 3.7 2.2.7   3.8 2.2.8 2.10 3.9 3.1.1 11.1–11.2 11.1–11.23.1.2 11.3 11.3 3.1.3 11.7 11.6 3.2 11.6 11.5

SSD9 Required Readings SSD9 Required Readings Section Sixth Edition Fifth Edition4.1.1 12.1–12.2 12.1 4.1.2 12.3–12.4 12.2–12.34.1.3 12.5 12.4 4.1.4 12.6 12.5 4.3.1 12.5.1 12.4.15.1.1 7.1–7.3 7.1–7.3 5.1.2 13.1–13.9 13.1–13.7 5.1.4 13.12 13.8 5.1.5 13.10–13.11, 13.14 13.10–13.11 6.1.1 8.1–8.6 8.1–8.66.1.2 14.1–14.2 14.1–14.2

SSD9 Required Readings SSD9 Required Readings Section Sixth Edition Fifth Edition6.1.3 14.3–14.4 14.3–14.4 6.2.1 14.10–14.13.1 14.6–14.8.1 6.2.2 6.2, 14.14 6.2, 14.96.2.3 6.5, 14.13.2, 14.16, 14.25 6.5, 14.8.2, 14.11, 15.126.2.4 14.15–14.19 14.10–14.146.3 14.6, 14.20 15.1–15.36.4 6.4, 14.21–14.22 6.4, 15.4–15.56.5 5.4–5.10, 14.24.1–14.24.2 5.4–5.10 and 15.6–15.8

7.1   2.2.2, 2.3.2, 2.4.2, 2.5.2, 2.6.2, 2.7.2

7.5 9.9 9.9

SSD9 Required Readings SSD9 Required Readings Section Sixth Edition Fifth Edition8.1 15.1–15.3, 15.6 16.1–16.3, 16.68.2 15.4, 15.7–15.8 16.4, 16.7–16.88.3 15.5 16.58.4 15.9–15.11 16.9–16.11

The purpose of SSD9 is for students to LearnThe purpose of SSD9 is for students to Learn1.1. the principles and practices for the principles and practices for producing better producing better

softwaresoftware and for making software development more and for making software development more predictable and economicalpredictable and economical

2.2. to examine critically the different phases of a software to examine critically the different phases of a software product's life cycleproduct's life cycle

3.3. various approaches to software designvarious approaches to software design4.4. the role of software architecture in software designthe role of software architecture in software design5.5. structured systems analysis, object-oriented analysis structured systems analysis, object-oriented analysis

(OOA), and object-oriented design (OOD) (OOA), and object-oriented design (OOD) 6.6. the different types of software testing, documentation, the different types of software testing, documentation,

and maintenance techniques and maintenance techniques 7.7. to design and build Internet-based software projects of to design and build Internet-based software projects of

significant scalesignificant scale8.8. acquiring experience in all phases of the software acquiring experience in all phases of the software

product life cycle product life cycle

Students successfully completing SSD9 will be able toStudents successfully completing SSD9 will be able to

I. Produce(I. Produce( 做出各类成果做出各类成果 )) 1.   Software systems based on 1.   Software systems based on customer requirementscustomer requirements 2.   Scope descriptions(2.   Scope descriptions( 功能范围描述功能范围描述 ) and ) and

requirements checklistsrequirements checklists （需求对照表） （需求对照表） by choosing a by choosing a suitable development modelsuitable development model

3.   Unified Modeling Language (UML) diagrams 3.   Unified Modeling Language (UML) diagrams illustrating the illustrating the use casesuse cases identified for the software identified for the software productproduct

4.   Use case scenarios(4.   Use case scenarios( 用例情形用例情形 ) for ) for normalnormal and and abnormalabnormal use cases use cases

5.   A class list for a product using the noun extraction5.   A class list for a product using the noun extraction（名词提取） （名词提取） techniquetechnique

Students successfully completing SSD9 will be able toStudents successfully completing SSD9 will be able to

I. Produce(I. Produce( 做出各类成果做出各类成果 )) 6.   Class diagrams(6.   Class diagrams( 类图类图 ) and state transition diagrams) and state transition diagrams

(( 状态转移图状态转移图 ) using the UML notation) using the UML notation 7.   Sequence diagrams7.   Sequence diagrams （顺序图） （顺序图） and collaboration and collaboration

diagramsdiagrams （协作图） （协作图） using UMLusing UML 8.   Detailed class diagrams, object interface 8.   Detailed class diagrams, object interface

specifications, and skeletal Java class files(specifications, and skeletal Java class files( 使用使用 javajava 实实现基本框架现基本框架 )) 9.   Detailed code documentation using Javadoc9.   Detailed code documentation using Javadoc 10.   Project implementation plans, test plans, and 10.   Project implementation plans, test plans, and

documents at every phasedocuments at every phase 11.   A final software system for demonstration11.   A final software system for demonstration

Students successfully completing SSD9 will be able toStudents successfully completing SSD9 will be able to

II. UseII. Use （运用）（运用） 1.   OOA and OOD techniques1.   OOA and OOD techniques 2.   Entity-relationship (ER) modeling techniques2.   Entity-relationship (ER) modeling techniques 3.   The MySQL database system and Java Database 3.   The MySQL database system and Java Database

Connectivity (JDBC) for a projectConnectivity (JDBC) for a project 4.   Javadoc to produce documentation4.   Javadoc to produce documentation 5.   Techniques for improving the quality of artifacts for 5.   Techniques for improving the quality of artifacts for

each phase of software developmenteach phase of software development

Students successfully completing SSD9 will be able toStudents successfully completing SSD9 will be able to

III. Knowledgeably DiscussIII. Knowledgeably Discuss 1.   Specification techniques that address the various 1.   Specification techniques that address the various

software engineering principlessoftware engineering principles 2.   Computer-aided software engineering (CASE) 2.   Computer-aided software engineering (CASE)

technologytechnology 3.   Code reuse and design reuse3.   Code reuse and design reuse 4.   Managing maintenance: fault reports, fault 4.   Managing maintenance: fault reports, fault

prioritizationprioritization 5.   Maintenance of object-oriented software5.   Maintenance of object-oriented software

Students successfully completing SSD9 will be able toStudents successfully completing SSD9 will be able to

IV. Hold Positions as Software EngineersIV. Hold Positions as Software Engineers Those who certify in this course will be able to Those who certify in this course will be able to (a) develop software systems using modern software (a) develop software systems using modern software

engineering principles; engineering principles; (b) (b) make decisionsmake decisions about selecting the appropriate life- about selecting the appropriate life-

cycle model for software development; cycle model for software development; (c) develop (c) develop documentsdocuments required by each life cycle of the required by each life cycle of the

software development process; software development process; (d) develop test plans(d) develop test plans and acceptance test plans(and acceptance test plans( 验收测验收测试计划试计划 )) for complex software projects. for complex software projects.

Unit 1. Overview of Software Engineering Unit 1. Overview of Software Engineering

1.11.1 Software Challenges and Myths  Software Challenges and Myths 1.21.2 History and Evolution  History and Evolution 1.31.3 Life Cycle and Economy  Life Cycle and Economy 1.41.4 Terminology  Terminology

Assessments Assessments Multiple-Choice Quiz 1 Multiple-Choice Quiz 1

1.1  Software Challenges and Myths 1.1  Software Challenges and Myths

In this module we will briefly surveyIn this module we will briefly survey some of the challenges to be faced when developing some of the challenges to be faced when developing

softwaresoftware some of the some of the misconceptionsmisconceptions about software development about software development

that have sprung up over the relatively short history of that have sprung up over the relatively short history of large-scale software production.large-scale software production.

过来人会告诉你过来人会告诉你………… anyone anyone who has participated in developing who has participated in developing

software productssoftware products of any significant size or of any significant size or complexity will tell you two things. complexity will tell you two things.

1.1. if there is something you can count on, it is that it will if there is something you can count on, it is that it will take you take you longerlonger to finish than you expect. to finish than you expect.

2.2. even when you think the product is completed, even when you think the product is completed, problems will still be lurking("problems will still be lurking(" 潜伏潜伏 ") that testing will ") that testing will not have found. not have found.

Past and presentPast and present In the old daysIn the old days, people used to say that whatever time , people used to say that whatever time

estimate you thought was reasonable, you should estimate you thought was reasonable, you should （（ ×3, ×3, × 10× 10 ）） . . software development manager think:software development manager think:

development delays, and errors found after delivery can incur unacceptable development delays, and errors found after delivery can incur unacceptable losses:losses:

additional (unexpected) costs additional (unexpected) costs greatly diminished customer satisfaction(greatly diminished customer satisfaction( 满意度满意度 )) and confidence(and confidence( 信任信任

度度 ))

In today‘sIn today‘s competitive environment competitive environment getting a product to market getting a product to market on timeon time and with as and with as few residualfew residual

“bugs”(“bugs”( 残留的缺陷残留的缺陷 )) as possible can mean the difference as possible can mean the difference between the between the successsuccess and and failurefailure of a product, or even a company. of a product, or even a company.

软件危机软件危机 软件危机软件危机

是指在计算机软件的开发和维护过程中所遇到的一是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。系列严重问题。 2020 世纪世纪 6060 年代末至年代末至 2020 世纪世纪 7070 年代初，年代初，““软件软件危机危机””一词在计算机界广为流传。一词在计算机界广为流传。 事实上，几乎从计算机诞生的那一天起，就出事实上，几乎从计算机诞生的那一天起，就出现了软件危机，现了软件危机， 到了到了 19681968 年在原西德年在原西德 GarmishGarmish 召开的召开的 NATONATO的的国际软件工程会议国际软件工程会议上才被人们普遍认识到。上才被人们普遍认识到。 正是这次会议，“软件工程”正式提出并被接正是这次会议，“软件工程”正式提出并被接受。受。

软件危机的表现 － 软件成本日益增长软件危机的表现 － 软件成本日益增长 计算机发展的早期计算机发展的早期

大型计算机系统主要是被设计应用于非常狭窄的大型计算机系统主要是被设计应用于非常狭窄的军事领域军事领域。。 研制计算机的费用主要由研制计算机的费用主要由国家财政提供国家财政提供，研制者，研制者很少很少考虑到考虑到研制代价研制代价问题。问题。

随着计算机市场化和民用化的发展随着计算机市场化和民用化的发展 代价和成本代价和成本就成为投资者考虑的最重要的问题之一就成为投资者考虑的最重要的问题之一

2020 世纪世纪 5050 年代，年代， 软件成本在整个计算机系统成本中所占的比例为软件成本在整个计算机系统成本中所占的比例为 10%-20%10%-20% ，，主要是硬件成本太高。主要是硬件成本太高。 计算机计算机硬件硬件随着技术的进步随着技术的进步 (( 晶体管的发明、集成电路晶体管的发明、集成电路 )) 、生、生产规模的扩大，产规模的扩大，价格却不断下降价格却不断下降 随着软件产业的发展，软件成本日益增长。随着软件产业的发展，软件成本日益增长。 软件成本在计算机系统中所占的比例越来越大。软件成本在计算机系统中所占的比例越来越大。

软件危机的表现 － 软件成本日益增长软件危机的表现 － 软件成本日益增长 到到 2020 世纪世纪 6060 年代中期年代中期

软件成本在计算机系统中所占的比例已增长到约软件成本在计算机系统中所占的比例已增长到约 50%50% 而且没有维持这个数字，该数字还在不断地递增，而且没有维持这个数字，该数字还在不断地递增，

以下是一组来自美国空军计算机系统的数据：以下是一组来自美国空军计算机系统的数据： 19551955 年占年占 18%18% ，， 19701970 年达到年达到 60%60% ，， 19751975 年达到年达到 72%72% ，， 19801980 年达到年达到 80%80% ，， 19851985 年达到年达到 85%85% 左右左右

为什么会有这么高的比例为什么会有这么高的比例 人力成本增加，智力劳动之前了人力成本增加，智力劳动之前了 软件规模越来越大软件规模越来越大 结构越来越复杂结构越来越复杂

软件危机的表现 － 开发进度难以控制软件危机的表现 － 开发进度难以控制 由于软件是逻辑、智力产品，软件的开发需建由于软件是逻辑、智力产品，软件的开发需建立庞大的逻辑体系，这是与其他产品的生产不立庞大的逻辑体系，这是与其他产品的生产不一样的。一样的。

例如例如：工厂里要生产某种机器，在时间紧的情况下：工厂里要生产某种机器，在时间紧的情况下可以要工人加班或者实行可以要工人加班或者实行““三班倒三班倒””，而这些方法都，而这些方法都不能用在软件开发上。不能用在软件开发上。 在软件开发过程中，用户需求变化等在软件开发过程中，用户需求变化等各种意想各种意想不到的情况不到的情况层出不穷，层出不穷，

软件开发过程软件开发过程很难很难保证按预定的计划实现保证按预定的计划实现 给项目计划和论证工作带来了很大的困难给项目计划和论证工作带来了很大的困难

软件危机的表现 － 开发进度难以控制软件危机的表现 － 开发进度难以控制 BROOKBROOK 曾经提出：曾经提出：““在已拖延的软件项目上，在已拖延的软件项目上，增加人力只会使其更难按期完成增加人力只会使其更难按期完成””。。

软件系统结构复杂，各部分附加联系极大，盲目增软件系统结构复杂，各部分附加联系极大，盲目增加软件开发人员加软件开发人员并不能成比例地提高并不能成比例地提高软件开发能力。软件开发能力。 相反相反随着人员数量的增加，人员的组织、协调、通随着人员数量的增加，人员的组织、协调、通信、培训和管理等方面的问题将更为严重。信、培训和管理等方面的问题将更为严重。

许多重要的大型软件开发项目，由于离预定目许多重要的大型软件开发项目，由于离预定目标相差甚远不得不宣布失败标相差甚远不得不宣布失败 例如：例如： IBM OS/360IBM OS/360 和世界范围的军事命令控制系统和世界范围的军事命令控制系统

（（ WWMCCSWWMCCS ），在耗费了大量的人力和财力之后，），在耗费了大量的人力和财力之后，宣布失败。宣布失败。

软件危机的表现 － 软件质量差软件危机的表现 － 软件质量差 软件项目即使能按预定日期完成，结果却不尽人意。软件项目即使能按预定日期完成，结果却不尽人意。

例如：例如： 19651965 年至年至 19701970 年，美国范登堡基地发射火箭多次失败，年，美国范登堡基地发射火箭多次失败，绝大部分故障是由应用程序错误造成的。绝大部分故障是由应用程序错误造成的。 程序的一些微小错误可以造成灾难性的后果，程序的一些微小错误可以造成灾难性的后果，

例如：美国发射一枚阿脱拉斯火箭，火箭飞离地面几十英里高例如：美国发射一枚阿脱拉斯火箭，火箭飞离地面几十英里高空开始翻转，地面控制中心被迫下令炸毁。后经检查发现是飞空开始翻转，地面控制中心被迫下令炸毁。后经检查发现是飞行计划行计划程序里漏掉了一个连字符程序里漏掉了一个连字符。。 一个小小的疏漏造成了这支价值一个小小的疏漏造成了这支价值 18501850万美元的火箭试验失败。万美元的火箭试验失败。　　　　

在在““软件作坊软件作坊””里，里， 缺乏工程化思想的指导，程序员几乎总是习惯性地缺乏工程化思想的指导，程序员几乎总是习惯性地以自己的想以自己的想法去代替用户对软件的需求法去代替用户对软件的需求，， 软件设计带有随意性，很多功能只是软件设计带有随意性，很多功能只是程序员的程序员的 "" 一厢情愿一厢情愿““ 造成软件不能令人满意。造成软件不能令人满意。

软件危机的表现 －软件维护困难软件危机的表现 －软件维护困难 正式投入使用的软件，正式投入使用的软件，总是存在总是存在着一定数量的错误，着一定数量的错误， 在不同的运行条件下，软件就会出现故障，因此需要维在不同的运行条件下，软件就会出现故障，因此需要维护。护。

由于在软件设计和开发过程中，没有严格遵循软件开发标准，由于在软件设计和开发过程中，没有严格遵循软件开发标准，各种各种随意性很大随意性很大，没有完整的真实反映系统状况的记录文档，，没有完整的真实反映系统状况的记录文档，给软件维护造成了巨大的困难。给软件维护造成了巨大的困难。 特别是在软件使用过程中，原来的开发人员可能因各种原因特别是在软件使用过程中，原来的开发人员可能因各种原因已经离开原来的开发组织，使得软件几乎不可维护。已经离开原来的开发组织，使得软件几乎不可维护。

软件修改是一项很软件修改是一项很““危险危险””的工作，的工作， 对一个复杂的逻辑过程，哪怕做一项微小的改动，都可能引对一个复杂的逻辑过程，哪怕做一项微小的改动，都可能引入潜在的错误入潜在的错误 常常发生常常发生““纠正一个错误带来更多新错误纠正一个错误带来更多新错误””的问题，从而产生的问题，从而产生副作用。副作用。

资料表明资料表明，工业界为维护软件支付的费用占全部硬件和，工业界为维护软件支付的费用占全部硬件和软件费用的软件费用的 40%-75%40%-75% 。。

1976–1981 data1976–1981 dataMaintenance constitutes 67% of total costMaintenance constitutes 67% of total cost

软件危机的原因 －用户需求不明确软件危机的原因 －用户需求不明确 从软件危机的种种表现和软件作为逻辑产品的从软件危机的种种表现和软件作为逻辑产品的特殊性可以发现软件危机的原因特殊性可以发现软件危机的原因 用户需求不明确问题主要体现在四个方面：用户需求不明确问题主要体现在四个方面：

在软件开发出来之前，用户本人也不清楚软件的具在软件开发出来之前，用户本人也不清楚软件的具体需求；体需求； 用户对软件需求的描述不精确，可能有遗漏、有二用户对软件需求的描述不精确，可能有遗漏、有二义性、甚至有错误；义性、甚至有错误； 在软件开发过程中，用户还提出修改软件功能、界在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求；面、支撑环境等方面的要求； 软件开发人员对用户需求的理解与用户本来愿望有软件开发人员对用户需求的理解与用户本来愿望有差异。差异。

软件危机的原因 －缺乏正确的理论指导软件危机的原因 －缺乏正确的理论指导 缺乏有力的方法学和工具方面的支持。缺乏有力的方法学和工具方面的支持。 由于软件不同于大多数其他工业产品，其开发由于软件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。地依赖于开发人员高度的智力投入。 过分地依靠过分地依靠程序设计人员在软件开发过程中的程序设计人员在软件开发过程中的技巧和创造性技巧和创造性，，

加剧软件产品的加剧软件产品的个性化个性化，也是发生软件危机的一个，也是发生软件危机的一个重要原因。 重要原因。 所以，软件开发团队中不需要“个人英雄主所以，软件开发团队中不需要“个人英雄主义”！义”！

软件危机的原因 －软件规模越来越大软件危机的原因 －软件规模越来越大 随着软件应用范围的增广，软件规模愈来愈大。随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，大型软件项目需要组织一定的人力共同完成，

多数管理人员缺乏开发大型软件系统的经验，多数管理人员缺乏开发大型软件系统的经验， 多数软件开发人员又缺乏管理方面的经验。多数软件开发人员又缺乏管理方面的经验。

各类人员的信息交流不及时、不准确、有时还各类人员的信息交流不及时、不准确、有时还会产生误解。会产生误解。 软件项目开发人员不能有效地、独立自主地处软件项目开发人员不能有效地、独立自主地处理大型软件的理大型软件的全部关系全部关系和和各个分支各个分支，因此容易，因此容易产生疏漏和错误。产生疏漏和错误。

软件危机的原因 －软件复杂度越来越高软件危机的原因 －软件复杂度越来越高 软件不仅仅是在规模上快速地发展扩大，而且软件不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。其复杂性也急剧地增加。 软件产品的特殊性和软件产品的特殊性和人类智力的局限性人类智力的局限性，导致，导致人们无力处理复杂问题人们无力处理复杂问题 所谓所谓 ""复杂问题复杂问题 "" 的概念是的概念是相对的相对的，一旦人们，一旦人们采用先进的组织形式、开发方法和工具提高了采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前。的问题又摆在人们的面前。

如何克服软件危机如何克服软件危机 人们在认真地研究和分析了软件危机背后的真人们在认真地研究和分析了软件危机背后的真正原因之后，得出了正原因之后，得出了

人们面临的不光是技术问题，人们面临的不光是技术问题，更重要的是管理问题更重要的是管理问题。。管理不善必然导致失败管理不善必然导致失败 开始探索用工程的方法进行软件生产的可能性，开始探索用工程的方法进行软件生产的可能性，即用现代工程的概念、原理、技术和方法进行即用现代工程的概念、原理、技术和方法进行计算机软件的开发、管理和维护。计算机软件的开发、管理和维护。 于是，计算机科学技术的一个新领域于是，计算机科学技术的一个新领域 ---- 软件工软件工程诞生了。程诞生了。　　　　

如何克服软件危机如何克服软件危机 软件工程是软件工程是

用工程、科学和数学的原则与方法研制、维护计算机软件的用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法。有关技术及管理方法。 软件工程包括三个要素：软件工程包括三个要素：

（（ 11 ）方法。软件工程方法为软件开发提供了）方法。软件工程方法为软件开发提供了““如何做如何做””的技的技术，是完成软件工程项目的技术手段；术，是完成软件工程项目的技术手段； （（ 22 ）工具。软件工具是人类在开发软件的活动中智力和体）工具。软件工具是人类在开发软件的活动中智力和体力的扩展和延伸，为软件工程方法提供了自动的或半自动的力的扩展和延伸，为软件工程方法提供了自动的或半自动的软件支撑环境；（工欲善其事，必先利其器）软件支撑环境；（工欲善其事，必先利其器） （（ 33 ）过程。软件工程的过程则是将软件工程的方法和工具）过程。软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。综合起来以达到合理、及时地进行计算机软件开发的目的。

迄今为止，软件工程的研究与应用已经取得很大成就，迄今为止，软件工程的研究与应用已经取得很大成就，它在软件开发方法、工具、管理等方面的应用它在软件开发方法、工具、管理等方面的应用大大缓解大大缓解了软件危机造成的被动局面。了软件危机造成的被动局面。

QuestionsQuestions ？？ So many Whys……So many Whys……

Why are the costs of software development so Why are the costs of software development so high? high? In part, because software development frequently goes In part, because software development frequently goes

over the estimated time limits. over the estimated time limits. why does it take so long to get programs why does it take so long to get programs

finished? finished? Why do we have difficulty measuring Why do we have difficulty measuring

development progress?development progress? why can we not find all errors before we deliver? why can we not find all errors before we deliver?

Anwser for Whys……Anwser for Whys…… We do not We do not have have a simple answera simple answer because because

the software process is a the software process is a complexcomplex one, one, involving multiple parties involving multiple parties Each have different objectives(Each have different objectives( 实现目标实现目标 )) and constraints(and constraints( 约束约束条件条件 ). ). （需求、分析设计、实现、调试、部署、维护（需求、分析设计、实现、调试、部署、维护…………））

The actors (the customers, managers, and developers) in The actors (the customers, managers, and developers) in software production with seemingly software production with seemingly reasonableexpectations and attitudes (reasonableexpectations and attitudes ( 看上去很合理的看上去很合理的想法想法 )) that can contribute to increasing the time and cost of product that can contribute to increasing the time and cost of product

development. development. Some of these expectations and attitudes, although Some of these expectations and attitudes, although

mistakenmistaken, are quite widespread that they have acquired , are quite widespread that they have acquired a mythical status. a mythical status.

SOFTWARE MYTHS(SOFTWARE MYTHS( 软件神话，软件开发的误软件神话，软件开发的误区区 ))

Today, most knowledgeable professionals Today, most knowledgeable professionals recognize myths for what they are—recognize myths for what they are— misleadingmisleading attitudes that have caused serious problems attitudes that have caused serious problems

for managers and technical people alike. for managers and technical people alike. old attitudes and habits are old attitudes and habits are difficult to modifydifficult to modify, and , and

remnants of software myths are still believed.remnants of software myths are still believed. TypesTypes

Management mythsManagement myths Customer mythsCustomer myths Practitioner's mythsPractitioner's myths

Management mythsManagement myths

Managers with software Managers with software responsibilityresponsibility, like , like managers in most disciplines, are often under managers in most disciplines, are often under pressure to pressure to maintain budgetsmaintain budgets keep schedules from slippingkeep schedules from slipping improve qualityimprove quality

Like a drowning person who grasps at a straw(Like a drowning person who grasps at a straw( 救救命稻草命稻草 ), a software manager often grasps at belief ), a software manager often grasps at belief in a software myth, if that belief will lessen the in a software myth, if that belief will lessen the pressure .pressure .

Management mythsManagement myths MythMyth: : We already have a book that's full of standards and We already have a book that's full of standards and

procedures for building software, won't that provide my procedures for building software, won't that provide my people with everything they need to know?people with everything they need to know?

Reality: Reality: The book of standards may very well exist, but is it used? The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it Does it reflect modern software engineering practice? Is it

complete? complete? Is it streamlined(Is it streamlined( 经过修改经过修改 ) to improve time to delivery while ) to improve time to delivery while

still maintaining a focus on quality? still maintaining a focus on quality? In many cases, the answer to all of these questions is "no.“In many cases, the answer to all of these questions is "no.“

问题是你用了没有，遵照执行了没有？问题是你用了没有，遵照执行了没有？

Management mythsManagement myths MythMyth: : My people have state-of-the-artMy people have state-of-the-art （最新） （最新）

software development tools, after all, we buy them software development tools, after all, we buy them the newest computers.the newest computers.

Reality: Reality: It takes much more than the latest model mainframe, It takes much more than the latest model mainframe,

workstation, or PC to do high-quality software workstation, or PC to do high-quality software development. development.

Computer-aided software engineering (CASE) tools Computer-aided software engineering (CASE) tools are are more important than hardwaremore important than hardware for achieving for achieving good quality and productivity, yet the majority of good quality and productivity, yet the majority of software developers still software developers still do notdo not use them effectively. use them effectively.

好的开发平台有的是，但最重要的是一个合适好的开发平台有的是，但最重要的是一个合适的的 CASECASE 工具工具

Management mythsManagement myths MythMyth: : If we get behind schedule, we can add more If we get behind schedule, we can add more

programmers and catch up.programmers and catch up. Reality: Reality:

Software development is not a mechanistic process like Software development is not a mechanistic process like manufacturing. manufacturing.

Brooks said: "adding people to a late software project makes Brooks said: "adding people to a late software project makes it later." it later."

At first, this statement may seem counterintuitive. At first, this statement may seem counterintuitive. However, as new people are added, However, as new people are added, people who were working must spend time educating the people who were working must spend time educating the

newcomers, newcomers, thereby reducing the amount of time spent on productive thereby reducing the amount of time spent on productive

development effort. development effort. People can be added but only in a planned and well-People can be added but only in a planned and well-

coordinated manner.(coordinated manner.( 只能是按计划地增加只能是按计划地增加 ))

Management mythsManagement myths

MythMyth: : If I decide to outsourceIf I decide to outsource （外包） （外包） the the software project to a third party, I can just relax and software project to a third party, I can just relax and let that firm build it.let that firm build it.

RealityReality: : If an organization does not understand how to If an organization does not understand how to

manage and control software projects internally, manage and control software projects internally, it will invariably struggle(it will invariably struggle( 陷入困境陷入困境 ) when it ) when it

outsources software projects.outsources software projects. 客户客户开发组织（不能置之不理）开发组织（不能置之不理） 开发组织开发组织开发组织（也不能置之不理）开发组织（也不能置之不理）

Customer mythsCustomer myths A customer who requests computer software may be A customer who requests computer software may be

a person at the next desk, a person at the next desk, a technical group down the hall,a technical group down the hall, the marketing/sales department, the marketing/sales department, an outside company that has requested software under an outside company that has requested software under

contract. contract. In many cases, the customer believes myths about software In many cases, the customer believes myths about software

because because software managers and practitioners do little to correct software managers and practitioners do little to correct

misinformation(misinformation( 讹传讹传 ). ). 没有相关人员给他们纠正没有相关人员给他们纠正 Myths lead to false expectations (by the customer) and Myths lead to false expectations (by the customer) and

ultimately, dissatisfaction with the developer.ultimately, dissatisfaction with the developer. 最终形成对最终形成对开发者地不满开发者地不满

Customer mythsCustomer myths

MythMyth: : A A general statementgeneral statement of objectives is of objectives is sufficient to begin writing programs—we can fill in sufficient to begin writing programs—we can fill in the details later.the details later.

Reality: Reality: A poor up-front definition(A poor up-front definition( 糟糕的需求定义糟糕的需求定义 ) is the ) is the

major cause of failed software efforts. major cause of failed software efforts. A formal and detailed description of the information A formal and detailed description of the information

domain, function, behavior, performance, interfaces, domain, function, behavior, performance, interfaces, design constraints, and validation criteria is essential. design constraints, and validation criteria is essential.

These characteristics can be determined These characteristics can be determined onlyonly after after thorough communication(thorough communication( 密切合作、有效沟通密切合作、有效沟通 ) ) between customer and developer.between customer and developer.

Customer mythsCustomer myths

MythMyth: : Project requirements continually change, but Project requirements continually change, but change can be easily accommodated because change can be easily accommodated because software is flexible.software is flexible.

Reality: Reality: It is true that software requirements change, but the It is true that software requirements change, but the

impact of change varies with impact of change varies with the timethe time at which it is at which it is introduced. introduced.

If serious attention is given to up-front(If serious attention is given to up-front( 预先预先 ) ) definition, definition, earlyearly requests for change can be requests for change can be accommodated accommodated easilyeasily. The customer can review . The customer can review requirements and recommend modifications with requirements and recommend modifications with relatively little impact on cost. relatively little impact on cost.

Customer mythsCustomer myths MythMyth: : Project requirements continually change, but Project requirements continually change, but

change can be easily accommodated because change can be easily accommodated because software is flexible.software is flexible.

Reality: Reality: When changes are requested during software design, When changes are requested during software design,

the the cost impact grows rapidlycost impact grows rapidly. . When Resources have been committed and a design When Resources have been committed and a design

framework has been established. framework has been established. Change can cause upheaval (Change can cause upheaval ( 引起剧变引起剧变 )that requires )that requires

additional resources, major design modification, additional additional resources, major design modification, additional cost. cost.

Changes in function, performance, interface, or other Changes in function, performance, interface, or other characteristics during implementation (code and test) have characteristics during implementation (code and test) have a severe impact on cost. a severe impact on cost.

the impact of changethe impact of change

Change, when requested after software is in Change, when requested after software is in production, can be over an order of magnitude more production, can be over an order of magnitude more expensive than the same change requested earlier.expensive than the same change requested earlier.

Practitioner's mythsPractitioner's myths

Myths that are still believed by software Myths that are still believed by software practitioners have been fostered(practitioners have been fostered( 培育培育 ) by 50 years ) by 50 years of programming culture. of programming culture.

During the early days of software, programming During the early days of software, programming was viewed as an was viewed as an art form(art form( 艺术活动艺术活动 )). .

Old ways and attitudes Old ways and attitudes die harddie hard..

Practitioner's mythsPractitioner's myths

MythMyth: : Once we write the program and get it to Once we write the program and get it to work, our job is done.work, our job is done.

Reality: Reality: Someone once said that "the sooner you begin Someone once said that "the sooner you begin

'writing code', the longer it'll take you to get done." 'writing code', the longer it'll take you to get done." Industry data indicate that 60 ~ 80% of all effort Industry data indicate that 60 ~ 80% of all effort

expended on software will be expended expended on software will be expended after it is after it is delivered to the customerdelivered to the customer for the first time. for the first time.

搞清需求再动手！搞清需求再动手！

Practitioner's mythsPractitioner's myths

MythMyth: : Until I get the program "running" I have no Until I get the program "running" I have no way of assessing its quality.way of assessing its quality.

Reality: Reality: One of the most effective One of the most effective software quality assurance software quality assurance

mechanismsmechanisms can be applied from the inception of a can be applied from the inception of a project(project( 项目初期项目初期 ) — the ) — the formal technical review. formal technical review.

Software reviews(Software reviews( 软件评审软件评审 ) are a "quality filter" ) are a "quality filter" that have been found to be that have been found to be more effective than testingmore effective than testing for finding certain classes of software defects.for finding certain classes of software defects.

Practitioner's mythsPractitioner's myths

MythMyth: : The only deliverable work product for a The only deliverable work product for a successful project is the working program.successful project is the working program.

Reality: Reality: A working program is A working program is only one part ofonly one part of a a software software

configuration configuration that includes many elements. that includes many elements. DocumentationDocumentation provides a foundation for successful provides a foundation for successful

engineering and, more important, guidance for engineering and, more important, guidance for software support.software support.

Practitioner's mythsPractitioner's myths

MythMyth: : Software engineering will make us create Software engineering will make us create voluminous and unnecessary documentation(voluminous and unnecessary documentation( 大量大量无用文档无用文档 ) and will invariably slow us down.) and will invariably slow us down.

Reality: Reality: Software engineering is not about creating Software engineering is not about creating

documents. documents. It is about It is about creating qualitycreating quality. . Better quality leads to reduced rework. Better quality leads to reduced rework. And reduced rework results in faster delivery times.And reduced rework results in faster delivery times.赶工导致返工！赶工导致返工！

1.2 History and Evolution 1.2 History and Evolution

a brief history of software developmenta brief history of software development the evolution of software practices since the the evolution of software practices since the

1950s. 1950s. The The growing complexity of software applicationsgrowing complexity of software applications, ,

together with the together with the lessons learned from early lessons learned from early software projectssoftware projects, have made software , have made software engineering increasingly important in today‘s engineering increasingly important in today‘s use case. use case.

软件工程从项目实践的摸爬滚打中一路走来、软件工程从项目实践的摸爬滚打中一路走来、壮大、形成体系、趋向完善壮大、形成体系、趋向完善…………

a brief history of software developmenta brief history of software development In the 1950s and through much of the 1960s, In the 1950s and through much of the 1960s, hardware hardware

dominateddominated the computer world. the computer world. Several years after the invention of the transistor(Several years after the invention of the transistor( 晶体晶体

管管 )) in 1947, computers began scaling down in size and in 1947, computers began scaling down in size and cost. cost.

In 1954, IBM announced its first transistor-based In 1954, IBM announced its first transistor-based computer computer 之前都是电子管，体积很大之前都是电子管，体积很大

by the late 1950s several organizations, companies, and by the late 1950s several organizations, companies, and universities had computers at their disposal(universities had computers at their disposal( 利用计算利用计算机进行处理机进行处理 ). ).

At that time, computers were still very At that time, computers were still very expensive and expensive and very largevery large: : a computer significantly less powerful than today's laptop a computer significantly less powerful than today's laptop

occupied as much as one or two rooms, occupied as much as one or two rooms, together with permanent storage devices together with permanent storage devices 永久存贮装置 永久存贮装置 and and

other accessories. other accessories.

a brief history of software developmenta brief history of software development

Management of computer production was Management of computer production was substantially substantially hardware orientedhardware oriented many of the same practices applicable(many of the same practices applicable( 可使用的实践可使用的实践 ))

to the manufacturing of industrial products formal to the manufacturing of industrial products formal standards, quality controls, and cost controls were standards, quality controls, and cost controls were applied to hardware. applied to hardware.

There was an area of expertise(There was an area of expertise( 专门的领域专门的领域 )) called called hardware engineeringhardware engineering, but the software , but the software itself was still something of an afterthought(itself was still something of an afterthought( 置之置之脑后脑后 ).).

a brief history of software developmenta brief history of software development

Much attention and capita(Much attention and capita( 资金资金 )) went into went into hardwarehardware

software production and programming was the software production and programming was the purview(purview( 范围范围 ) of ) of a few individualsa few individuals who who understood how to make all that machinery do understood how to make all that machinery do something useful. something useful. They worked with programming languages (like They worked with programming languages (like

assembly language) that few programmers would choose assembly language) that few programmers would choose to use today. to use today.

Programming was definitely seen as more of Programming was definitely seen as more of an artan art than than a science, and had a science, and had little visibilitylittle visibility at the at the management management levellevel. .

a brief history of software developmenta brief history of software development Programmers were given complete responsibility for the Programmers were given complete responsibility for the

software, and it was common for a programmer to begin coding software, and it was common for a programmer to begin coding withoutwithout spending any time on spending any time on analysisanalysis, , specificationspecification, or , or designdesign. .

This approach led to This approach led to an undisciplined style(an undisciplined style( 无组织无纪律无组织无纪律 )) of of programming, following programming, following fewfew formal methods( formal methods( 很少有正规的开发很少有正规的开发方法方法 ) and learning by ) and learning by trial and errortrial and error. .

There was a There was a lacklack of of predictability in the quality of the codepredictability in the quality of the code, and a , and a lack of lack of accountability on the part of its developers(accountability on the part of its developers( 开发者缺乏责开发者缺乏责任心任心 )). .

It was It was difficultdifficult if not impossible if not impossible to estimate how longto estimate how long a project a project would take. would take.

the code was often the code was often poorly and incompletely documentedpoorly and incompletely documented causing causing a severe problem for anyone taking over its maintenance from a severe problem for anyone taking over its maintenance from the original developers.the original developers.

a brief history of software developmenta brief history of software development through the late 1960sthrough the late 1960s

As computers became more widespreadAs computers became more widespread 1970s1970s

More and more of people and organizations relying on hardware More and more of people and organizations relying on hardware and softwareand software

the disorderly world of software development was destined for the disorderly world of software development was destined for reform. reform.

In the literature, one finds references to the "software In the literature, one finds references to the "software crisis" of the 1970s, crisis" of the 1970s, an era when an era when

the quality of software was the quality of software was generally unacceptably lowgenerally unacceptably low, , deadlines were seldom met deadlines were seldom met costs sometimes went over budget to a significant degree. costs sometimes went over budget to a significant degree.

a brief history of software developmenta brief history of software development The costs of software development began to The costs of software development began to

overshadow(overshadow( 超出超出 )) the costs associated the costs associated with hardware. with hardware.

It was clearly time to replace It was clearly time to replace the old the old CABTABCABTAB ("code a bit, test a bit . . . don't ("code a bit, test a bit . . . don't know how long it will take") approach to know how long it will take") approach to programming, which had become too programming, which had become too costly, costly, with a new onewith a new one that emphasized that emphasized formal methods for formal methods for quality assessmentquality assessment cost control cost control

a brief history of software developmenta brief history of software development the 1970s through the 1990sthe 1970s through the 1990s

Efforts from focused on Efforts from focused on increasing understanding of the science of programming,increasing understanding of the science of programming, improving predictability of the software product and process improving predictability of the software product and process improving the accountability of the participants. (improving the accountability of the participants. ( 明确责任明确责任 ))

The The software development processsoftware development process became a became a primary primary object of studyobject of study for research and for research and development, development,

E.g.,E.g., especially at newly founded research especially at newly founded research institutions like institutions like

Carnegie Mellon University'sCarnegie Mellon University's Software Engineering InstituteSoftware Engineering Institute (http://www.sei.cmu.edu). (http://www.sei.cmu.edu).

a brief history of software developmenta brief history of software development

Still, the problems of the original “software Still, the problems of the original “software crisis” have not been completely alleviated(crisis” have not been completely alleviated( 减减轻轻 ), and the effectiveness of software ), and the effectiveness of software development is development is still poorstill poor in many fields. in many fields.

Stephen Schach suggests that the “Stephen Schach suggests that the “software software crisiscrisis” should have been called the “” should have been called the “software software depressiondepression,” because it has lasted significantly ,” because it has lasted significantly longer than a crisis normally does. (longer than a crisis normally does. ( 危机：一阵，危机：一阵，萧条：持久萧条：持久 ))

a brief history of software developmenta brief history of software development Today software has become ubiquitousToday software has become ubiquitous （无处不在） （无处不在）

and its quality is even more crucial. and its quality is even more crucial. business decisions. business decisions. the basis for solutions to science and engineering problems. the basis for solutions to science and engineering problems. relied upon by relied upon by

transportation and telecommunication systems, by transportation and telecommunication systems, by the medicalthe medical IndustrialIndustrial military establishmentsmilitary establishments entertainment industry. entertainment industry.

各行各业，人们已经离不开它了各行各业，人们已经离不开它了………… Therefore, it is Therefore, it is even more vitaleven more vital now to improve the now to improve the

predictability of the software process in terms of predictability of the software process in terms of costcost timetime correctness. correctness.

The term "software engineering"The term "software engineering" was coined(was coined( 形成形成 )) in 1967 and formally in 1967 and formally

endorsed(endorsed( 认可认可 ) the following year by the ) the following year by the NATO NATO Software Engineering ConferenceSoftware Engineering Conference, held in , held in Germany. Germany.

It reflected the hope that It reflected the hope that software could be designed, implemented, and managed software could be designed, implemented, and managed

like products in other engineering disciplineslike products in other engineering disciplines, , E.g.E.g.,like road, bridges, skyscraper in civil engineering. ,like road, bridges, skyscraper in civil engineering.

We do not build road bridges using We do not build road bridges using trial-and-trial-and-error methodserror methods, because the costs are too high(, because the costs are too high( 试试不起！不起！ ).).

In terms of both In terms of both money and safetymoney and safety. So why do we . So why do we build software that way? build software that way?

The bridge analogy The bridge analogy 软件与修桥的类比软件与修桥的类比 beneficial in some ways. beneficial in some ways.

It points out that, in the case of products like bridges, the It points out that, in the case of products like bridges, the designers designers make their best effortmake their best effort to to anticipate different anticipate different conditions and problemsconditions and problems resulting from them. resulting from them.

Consequently, the product is designed to Consequently, the product is designed to avoid total avoid total failure and to withstand problem conditionsfailure and to withstand problem conditions by designing by designing for them and building in a margin of safety. for them and building in a margin of safety.

But the analogy with bridges But the analogy with bridges breaks downbreaks down in in certain respects. certain respects. In the first place, the analogy is In the first place, the analogy is not always applicablenot always applicable to to

all software systems. all software systems. E.g.E.g., when using , when using rapid prototypingrapid prototyping as part of the as part of the

development strategy, the prototype is development strategy, the prototype is notnot expected to be expected to be robust. robust.

The bridge analogyThe bridge analogy Many finished applications, software failure either a Many finished applications, software failure either a

crash or an incorrect result is not as catastrophic(crash or an incorrect result is not as catastrophic( 灾难灾难 ) ) as the as the failure of a bridge structurefailure of a bridge structure, , because a program can be easily restarted but a bridge because a program can be easily restarted but a bridge

cannot be rebuilt quickly or easily. cannot be rebuilt quickly or easily. The program can be reinitialized or its state recovered, if it was The program can be reinitialized or its state recovered, if it was

periodically saved, with relatively little cost. periodically saved, with relatively little cost.

The bridge analogyThe bridge analogy

problems that do not lead problems that do not lead software systemsoftware system to a to a crash can be more insidious(crash can be more insidious( 潜伏潜伏 ). ). Errors may accumulateErrors may accumulate , causing the internal state of the , causing the internal state of the

system to deterioratesystem to deteriorate over a long while.(over a long while.( 差错长期累积，差错长期累积，使系统恶化使系统恶化 ) ) By the time a failure occurs, it is By the time a failure occurs, it is difficultdifficult to findto find

the primary causethe primary cause of the fault of the fault Signs of failureSigns of failure may be more may be more obviousobvious in a in a

frequently inspected frequently inspected bridgebridge. .

The bridge analogyThe bridge analogy Moreover, Moreover, fault tolerancefault tolerance and and failure avoidancefailure avoidance in a in a

software system will necessarily take a different form software system will necessarily take a different form than in a than in a physical structurephysical structure. . E.g.,E.g., you cannot exactly guarantee safety an engineer designs a bridge you cannot exactly guarantee safety an engineer designs a bridge

forfor heavier-than-expected heavier-than-expected loads. loads. But, over-designing the software is ok .But, over-designing the software is ok . DetectionDetection of and of and recoveryrecovery from faults is to be implemented by from faults is to be implemented by

embedding consistency(embedding consistency( 相容性相容性 ) and assumption checks) and assumption checks （各种（各种假定情况检查） 假定情况检查） in the program, in the program, by providing error reportsby providing error reports （出错报告） （出错报告） and recovery optionsand recovery options（恢复方法） （恢复方法） before a situation is reached that leads to a system before a situation is reached that leads to a system

crash (crash (e.g.e.g., attempts to divided by 0). , attempts to divided by 0).

Difference: maintenance of systemsDifference: maintenance of systems Due to the changing requirements, software is Due to the changing requirements, software is

incrementally incrementally redesignedredesigned and and re-implementedre-implemented throughout its lifetimethroughout its lifetime while bridge maintenance is typically very minor and localized.while bridge maintenance is typically very minor and localized.

The kinds of software changes in its lifetime as part of The kinds of software changes in its lifetime as part of maintenance are maintenance are far more radicalfar more radical than those bridges are than those bridges are expected to. (expected to. ( 软件常常大改，桥梁只会是小修小补软件常常大改，桥梁只会是小修小补 )) Bridges may need to be rebuilt every so often to accommodate Bridges may need to be rebuilt every so often to accommodate

more traffic and heavier loads, but there are bridges that have more traffic and heavier loads, but there are bridges that have lasted lasted with little maintenancewith little maintenance for hundreds of years! ( for hundreds of years! ( 历经千百历经千百年的桥年的桥 ))

In contrast, a software product may In contrast, a software product may have a very short have a very short lifetimelifetime before it reaches obsolescence before it reaches obsolescence （废弃） （废弃） or or before it becomes more costly to maintain than replace.before it becomes more costly to maintain than replace.

DifferenceDifference ：： experience accumulation experience accumulation

unlikeunlike bridge building, the experience bridge building, the experience accumulated in developing software will accumulated in developing software will notnot necessarily(necessarily( 不一定不一定 )) result in better software result in better software because the because the hardware platformshardware platforms and associated and associated operating operating

systemssystems are changing and becoming complex at a faster are changing and becoming complex at a faster rate than we can master them. rate than we can master them. （我们在掌握之前就更（我们在掌握之前就更新换代了）新换代了）

This acceleration is partly due to This acceleration is partly due to the quantum leapsthe quantum leaps （高速发展）（高速发展） made by made by hardware hardware

technologytechnology in the last half-century, in the last half-century, changes in the capabilities of changes in the capabilities of software toolssoftware tools..

1.3 Life Cycle and Economy1.3 Life Cycle and Economy

The goal of this module is to introduce The goal of this module is to introduce the overall software life cycle, the overall software life cycle, economic factors that influence both economic factors that influence both the choice of a the choice of a

development approachdevelopment approach and and overall constraintsoverall constraints on on development itself. development itself.

goal of software engineeringgoal of software engineering

There are There are manymany ways to write programs that ways to write programs that produce a set of produce a set of desired outputdesired output from a specified from a specified set of input. set of input.

The The goal of software engineeringgoal of software engineering is to is to find the development methodology that is optimal, find the development methodology that is optimal,

where optimality might be evaluated along several where optimality might be evaluated along several different dimensionsdifferent dimensions 衡量方法 衡量方法 according to the according to the situation.situation.

when deciding on an optimal development methodologywhen deciding on an optimal development methodology

development timedevelopment time development costdevelopment cost product qualityproduct quality MaintainabilityMaintainability and so on……and so on……

An example of software developmentAn example of software development the FastWeb company decides to develop a program the FastWeb company decides to develop a program

that will convert a set of documents to HTML format. that will convert a set of documents to HTML format. If this job is to be done once, by internal staff only, If this job is to be done once, by internal staff only,

it might make sense to select a development methodology that it might make sense to select a development methodology that minimizes cost and timeminimizes cost and time, at the , at the possible expense of qualitypossible expense of quality. .

It is It is okayokay if the software if the software crashes once in a whilecrashes once in a while, because external , because external customers will never use it. customers will never use it.

On the other hand, if the conversion program will On the other hand, if the conversion program will become part of FastWeb's suite of support tools for become part of FastWeb's suite of support tools for external customers, external customers, quality and maintainability are much more important; quality and maintainability are much more important; in this case, a development methodology that produces software in this case, a development methodology that produces software

that is that is more reliablemore reliable may be considered optimal even if it takes may be considered optimal even if it takes more time and money. more time and money.

model of software developmentmodel of software development Any model of software development must take Any model of software development must take

into consideration that the software goes through into consideration that the software goes through several different phasesseveral different phases in its lifetime. in its lifetime.

All software development involves these basic All software development involves these basic activities: activities: requirements analysis, requirements analysis, specification, specification, design, design, Implementation, Implementation, integration, integration, maintenancemaintenance retirement.retirement.

Requirements analysis:Requirements analysis:

The developer The developer meets with the customermeets with the customer to to understand the problemunderstand the problem to be addressed by the to be addressed by the proposed software system. proposed software system.

an an interviewinterview process process explore and refine the conceptexplore and refine the concept identified and discussed the client's specific identified and discussed the client's specific

requirements and constraintsrequirements and constraints What we get in this phaseWhat we get in this phase

a requirements document or checklista requirements document or checklist

SpecificationSpecification

Using the requirements document as a guideUsing the requirements document as a guide the developer produces the developer produces

a specificationa specification for all of the functionality to be included for all of the functionality to be included in the productin the product

a development methodologya development methodology estimated costestimated cost and and scheduleschedule. .

DesignDesign

Using the Using the functional specificationfunctional specification as a guide as a guide the developer produces the developer produces

detailed design documents detailed design documents For the For the individual software modulesindividual software modules to be built to be built For the For the overall software architectureoverall software architecture that will integrate those that will integrate those

modules and modules and interfaceinterface with the customer's software with the customer's software environment. environment.

ImplementationImplementation

Following the Following the design documentsdesign documents and the and the guidelinesguidelines in the project plan in the project plan

the developer programmers construct the the developer programmers construct the individual software modules. individual software modules.

This phase ends when all the modules have been This phase ends when all the modules have been implemented(coding)implemented(coding) and and testedtested independently. independently.

IntegrationIntegration

The individual modules are combined into the The individual modules are combined into the overall software architecture, overall software architecture,

then be tested by both the developer and the then be tested by both the developer and the customer. customer.

This phase ends This phase ends when various customer acceptance tests(when various customer acceptance tests( 接收测试接收测试 ))

(related to functional requirements) are successful(related to functional requirements) are successful the software is deployed at the customer site. the software is deployed at the customer site.

MaintenanceMaintenance

After acceptance of the original productAfter acceptance of the original product all changesall changes to the software are considered part of to the software are considered part of

the maintenance process. the maintenance process.

新三年，旧三年，缝缝补补又三年新三年，旧三年，缝缝补补又三年…………

Types of maintenanceTypes of maintenance Corrective(Corrective( 改正型改正型 )) maintenance maintenance

which removes residual faults with no change in original specifications which removes residual faults with no change in original specifications Enhancements(Enhancements( 增强型增强型 )) or updatesor updates

which imply changes to the original specifications and new development which imply changes to the original specifications and new development Perfective(Perfective( 完善型完善型 ) maintenance) maintenance

which improves the performance of existing functionality which improves the performance of existing functionality Adaptive(Adaptive( 适应型适应型 )) maintenancemaintenance

which includes changes made when the product must operate in a new software which includes changes made when the product must operate in a new software environment environment

Note: Note: It is important to note that all software undergoes maintenance, It is important to note that all software undergoes maintenance, not just bad not just bad

softwaresoftware. Software must constantly adapt to changes in the functional . Software must constantly adapt to changes in the functional requirements and operating environments of the organizations using it. requirements and operating environments of the organizations using it. Maintenance typically Maintenance typically absorbs the majority of the cost and timeabsorbs the majority of the cost and time invested in a invested in a software product. software product.

RetirementRetirement

be finally taken out of service be finally taken out of service the functionality supported by the software the functionality supported by the software

becomes obsoletebecomes obsolete （功能废弃）（功能废弃） retirement usually involves retirement usually involves exporting some exporting some

existing data to one or more new applicationsexisting data to one or more new applications before the software is taken out of service. before the software is taken out of service.

RetirementRetirement When to Retire? is based on a variety of factors:When to Retire? is based on a variety of factors:

The immediate cost of the new technology versus the old (the The immediate cost of the new technology versus the old (the purchase price of the product) purchase price of the product)

The cost of developing and maintaining applications that use the The cost of developing and maintaining applications that use the new technology new technology

The effort to train staff who will use the new software The effort to train staff who will use the new software The short-term loss of overall productivity during training and The short-term loss of overall productivity during training and

familiarization familiarization Note:Note:

Software can be retired and replaced in a variety of situations.Software can be retired and replaced in a variety of situations. no choice but to replace existing software and the costs involved are no choice but to replace existing software and the costs involved are

mandatorymandatory ( ( 被迫被迫 )()(Y2K bugY2K bug). ). the long-term costs of using new software are lower than the costs of using the long-term costs of using new software are lower than the costs of using

the existing software, but it is important to note that it may take some time the existing software, but it is important to note that it may take some time before the short-term costs of replacement are recuperated(before the short-term costs of replacement are recuperated( 弥补弥补 ). ).

About these phasesAbout these phases

These are usually part of a global These are usually part of a global project planproject plan that indicates how each of these phases will be that indicates how each of these phases will be carried out. carried out.

The project plan includes an The project plan includes an overall schedule (including activities and milestones)overall schedule (including activities and milestones) possibly other forms of global documentation possibly other forms of global documentation

such as a risk management plansuch as a risk management plan a test plana test plan an integration planan integration plan …… ……

About these phasesAbout these phases

In practice, some life-cycle models emphasize an In practice, some life-cycle models emphasize an approach where approach where each phase can and should be undertaken each phase can and should be undertaken more than oncemore than once

in an iterative or cyclic fashion. in an iterative or cyclic fashion. This is often necessary when certain aspects of This is often necessary when certain aspects of

the requirements, design, etc. are the requirements, design, etc. are not well not well understoodunderstood until after some software has already until after some software has already been constructed.been constructed.

Classical vs OO approach Classical vs OO approach

"classical" software engineering, "classical" software engineering, focuses on the construction of structured programs. focuses on the construction of structured programs. Specific code modules, programming languages, etc. are Specific code modules, programming languages, etc. are

not not actively considered until after the specifications actively considered until after the specifications phase has ended. phase has ended.

the object-oriented approach the object-oriented approach explicitly consider reusing existing code objects during explicitly consider reusing existing code objects during

the analysis and specification phases. the analysis and specification phases.

notenote

You should understand You should understand the boundaries of the different phases are fluidthe boundaries of the different phases are fluid （不是一（不是一成不变的）成不变的） ; ; depending on the life-cycle model and implementation depending on the life-cycle model and implementation

approach, approach, different tasks may fall under(different tasks may fall under( 应用应用 ) different phases) different phases the phases themselves may the phases themselves may be arranged in different be arranged in different

groupingsgroupings and/or and/or orderings of tasksorderings of tasks. .

Table 1. Relative Time, Cost of Life-Cycle Phases Table 1. Relative Time, Cost of Life-Cycle Phases

Phase Costs Time

Requirements 2% 21% / 18% (and specifications)

Specifications 5% included in requirements

Design 6% 18% / 19%

Module coding 5% 36% / 34% (and testing)

Module testing 7% included in coding

Integration 8% 24% / 29%

Maintenance 67%  —

comparative time and effort spentcomparative time and effort spent

Surprisingly, the most time is Surprisingly, the most time is notnot spent in the spent in the original coding of the modulesoriginal coding of the modules, but in , but in maintenance activities after delivery. maintenance activities after delivery.

This is especially true of software that remains in This is especially true of software that remains in service for long periods of time, that typically service for long periods of time, that typically undergoes several undergoes several modificationmodification to accommodate to accommodate changing requirementschanging requirements changes in the operating environment changes in the operating environment integration with other software ……integration with other software ……

One important implicationOne important implication Any Any design elementdesign element, , testing technique testing technique or or support toolsupport tool

that significantly improves extensibility of the software that significantly improves extensibility of the software (and/or reduces the time required to update and test it) (and/or reduces the time required to update and test it) will have a greater overall impact on project cost than will have a greater overall impact on project cost than corresponding technical breakthroughs on the corresponding technical breakthroughs on the coding coding processprocess..

其他方面的改进比编码过程中的技术突破更有效、节省其他方面的改进比编码过程中的技术突破更有效、节省成本！为什么呢成本！为什么呢 ?? A good software engineer will consider A good software engineer will consider

the various elements of a possible the various elements of a possible maintenance planmaintenance plan, , optimizing the design and implementation of the system to optimizing the design and implementation of the system to

promote straightforward, low-cost(promote straightforward, low-cost( 简单、低成本简单、低成本的的 )maintenance.)maintenance.

Another characteristic of software engineeringAnother characteristic of software engineering

budget is spent as followsbudget is spent as follows Requirements Requirements specification specification design (30%) design (30%) thethe

coding phasecoding phase ( (only 5%only 5% ) ) testing testing integration integration ( (30%)30%) …… ……

Why ?There are two reasons for this. Why ?There are two reasons for this. quality software delivery depends on a significant quality software delivery depends on a significant

investment in these non-coding activities. investment in these non-coding activities. the actual time spent coding up the system can be the actual time spent coding up the system can be

dramatically reduced if detailed specifications and dramatically reduced if detailed specifications and designs have been created in advance. (designs have been created in advance. ( 需求详尽了，需求详尽了，编码轻松了编码轻松了 ,, 设计工具甚至支持设计工具甚至支持自动代码生成自动代码生成………… ))

Time of codingTime of coding

从前那些事从前那些事…… …… BeforeBefore the advent of SE the advent of SE coding took much longer because the details of coding took much longer because the details of

the requirements and design were discovered the requirements and design were discovered during implementation. during implementation.

ChangesChanges in requirements and design can imply in requirements and design can imply significant significant rewritingrewriting of existing code of existing code

the coding phase takes much longer the coding phase takes much longer When When not enoughnot enough time is to write time is to write good specificationsgood specifications

and and design documentationdesign documentation

quality assurance activitiesquality assurance activities

Schach said: Schach said: more errors are introduced in the specification and more errors are introduced in the specification and

design phases than in later phases of the life cycle. design phases than in later phases of the life cycle. So it is important that So it is important that quality assurancequality assurance

activities begin activities begin earlyearly, even , even before coding beginsbefore coding begins! ! Although specification and design documents Although specification and design documents

can‘t be tested the way software is tested, they can‘t be tested the way software is tested, they can can be discussed and evaluatedbe discussed and evaluated in formal in formal reviews, which aim to reviews, which aim to identify various faultsidentify various faults that that must be rectifiedmust be rectified （修正） （修正） before before implementation begins.implementation begins.

cost of finding faultscost of finding faults The overall The overall cost of finding faultscost of finding faults increases exponentially( increases exponentially( 指数增指数增

长长 ) in the later stages of the software life cycle. ) in the later stages of the software life cycle. In later phases of the software cycle, more people and artifacts In later phases of the software cycle, more people and artifacts

are affected by software changes. are affected by software changes. when a fault is discovered when a fault is discovered

all of the previously completed phases may require significant revision or all of the previously completed phases may require significant revision or replacementreplacement

Previously implemented software must be edited, recompiled, and tested to Previously implemented software must be edited, recompiled, and tested to verify that changes are successful and that no other errors were introduced.verify that changes are successful and that no other errors were introduced.

Documentation must be updated. Documentation must be updated. if the software has already been delivered, a new version of the entire product if the software has already been delivered, a new version of the entire product

must be delivered and installedmust be delivered and installed it is much more cost effective to identify faults as early as possible it is much more cost effective to identify faults as early as possible

in the life cycle. in the life cycle. identifying problems as early as possibleidentifying problems as early as possible

three main components of each step three main components of each step Each step or phase in the life cycle can be Each step or phase in the life cycle can be

discussed with respect to its three main discussed with respect to its three main components: components: ProcessProcess 过程过程 : the distinct /: the distinct / interdependent tasks carried interdependent tasks carried

out during the phaseout during the phase MethodsMethods 方法方法 : the specific task descriptions for each of : the specific task descriptions for each of

the tasks in the processthe tasks in the process ToolsTools 工具工具 : semi- or fully automated support tools for : semi- or fully automated support tools for

the process and methodsthe process and methods Successful software engineering promotes high Successful software engineering promotes high

quality in all aspects of the process, the methods, quality in all aspects of the process, the methods, and the tools. and the tools.

planning is requiredplanning is required

Although Although substantial planning(substantial planning( 概要地计划概要地计划 )) is is required to pin down(required to pin down( 确定使用确定使用 ) all the details ) all the details of process, methods, and tools for a given phase, of process, methods, and tools for a given phase, a a detailed plandetailed plan is an absolute prerequisite for is an absolute prerequisite for accurate cost estimationaccurate cost estimation resource allocationresource allocation schedulingscheduling

1.4 Terminology 1.4 Terminology

some of the key terms in software engineering some of the key terms in software engineering were presentedwere presented and explained. and explained.

key termskey terms A A productproduct is any nontrivial piece of software. is any nontrivial piece of software. 具有使用价值地软具有使用价值地软件件 A A systemsystem is the combination of hardware and software that runs is the combination of hardware and software that runs

the product. the product. A A methodologymethodology 方法方法 or or paradigmparadigm 模式模式 is a particular approach, is a particular approach,

or set of techniques, designed to accomplish a specific phase or a or set of techniques, designed to accomplish a specific phase or a number of phases in the software development life cycle. number of phases in the software development life cycle.

A A bugbug is the colloquial term( is the colloquial term( 口头语口头语 )) used to refer to a software used to refer to a software fault. fault. Although this term is commonly used by programmers and users, it is Although this term is commonly used by programmers and users, it is

important to break the notion down(important to break the notion down( 区分开区分开 )) more formally into three terms more formally into three terms with different meanings: with different meanings:

A A fault(fault( 差错差错 )) is the actual problem in the code that is causing a is the actual problem in the code that is causing a failure. failure.

A A failure(failure( 故障故障 )) is the behavior perceived by the user that results is the behavior perceived by the user that results from the fault in the code. from the fault in the code.

An An error(error( 错误错误 )) is the is the programmer's mistakeprogrammer's mistake that led to the fault that led to the fault in the code. in the code.

example for distinction between faultexample for distinction between fault ，， failure and errorfailure and error

an an errorerror might occur when the programmer might occur when the programmer forgets to copy the latest version of a Java class forgets to copy the latest version of a Java class filefile to the directory from which the product is to the directory from which the product is assembled in preparation for delivery. assembled in preparation for delivery.

The The faultfault might be that the product throws might be that the product throws an an unknown method exceptionunknown method exception and terminates. and terminates.

The observed The observed failurefailure might be that the might be that the system system freezesfreezes when the user clicks on the "Save" when the user clicks on the "Save" button in the product's user interface.button in the product's user interface.

This simple example illustrates This simple example illustrates how difficulthow difficult it it can be to uncover the error from the observed can be to uncover the error from the observed failure. failure.

more group of termsmore group of terms

the three main participants in the software the three main participants in the software development process:development process: The clientThe client

the individual or organization who wants a product to be the individual or organization who wants a product to be developed developed

The developerThe developer the individual or group responsible for building the product the individual or group responsible for building the product

The user(s)The user(s) the person or persons who will utilize the product and on the person or persons who will utilize the product and on

whose behalf the client has commissioned the product whose behalf the client has commissioned the product

The roles of client, developer, and userThe roles of client, developer, and user Sometimes the client and the user are the same Sometimes the client and the user are the same

individual or organization, and the developer is individual or organization, and the developer is some outside party contracted to build the some outside party contracted to build the software.software. 医院管理层委托欲开发手术病人体征记录软件，医医院管理层委托欲开发手术病人体征记录软件，医生护士使用生护士使用

For smaller software projects, the developer may For smaller software projects, the developer may be an individual rather than an organization. be an individual rather than an organization.

At other times, all three roles may be filled by At other times, all three roles may be filled by groups inside the same organization. groups inside the same organization. 学校开发教学管理系统，或许教务部委托国软学院学校开发教学管理系统，或许教务部委托国软学院开发，全校师生使用开发，全校师生使用 ..

distribution of roles in software developmentdistribution of roles in software development contract softwarecontract software developmentdevelopment

the client and the developer are completely separate organizationsthe client and the developer are completely separate organizations internal softwareinternal software developmentdevelopment

the client and the developer are part of the same organization, is an instance of. the client and the developer are part of the same organization, is an instance of. Commercial off the shelf (Commercial off the shelf ( 商用现货商用现货 ) / shrink-wrapped software) / shrink-wrapped software

the software product is being developed by a company or individual in the software product is being developed by a company or individual in response to a perceived market need. response to a perceived market need.

the client could be identified with the management of the companythe client could be identified with the management of the company the developer with the technical division of the companythe developer with the technical division of the company the user with the potential customer for the product.(the user with the potential customer for the product.( 所有有需求的人所有有需求的人 ) )

Other variationsOther variations also possible. also possible.

they will all benefit from careful specification, design, planning, they will all benefit from careful specification, design, planning, testing, and maintenance of the software product.testing, and maintenance of the software product.