Computer Programming Courses and Certificates

 SSD1 = Introduction to Information Systems

 SSD2 = Introduction to Computer Systems

 SSD3 = Object-Oriented Programming and Design

 SSD4 = User-Centered Design and Testing

 SSD5 = Data Structures and Algorithms

 Software Systems Development Courses and
Certificates

 SSD1 - 5 = Computer Programming courses and

certificate
 SSD6 = System-Level Programming

 SSD7 = Database Systems

 SSD8 = Networks and Distributed Programming

 SSD9 = Software Specification, Test and Maintenance

 SSD10 = Software Project Organization and

Management
SSD9: Software Specification, Testing, and
Maintenance
 Course Resource:
 My email address:
xiongqw@gmail.com
 Web site for this course materials
http://www.icarnegie.com/
 Web site for this course information:
http://c4se.51.net/se/index.htm
 Time for questioning and answering:
1.Before or after class
2.When do practice in lab
 Lecture and practice arrangement
周数 内容 周数 内容

1 上课 10 上机练习
2 上课 11 上课
3 上课 12 上机练习
4 上机练习 13 上课
5 上课 14 上机练习 / 测试
6 上机练习 15 上课
7 上课 16 上机练习
8 上机练习 / 测试 17 上课
9 上课 18 上机练习 / 测试
 Overview ---- about our course
 This course is an introduction to software engineering.
 Including the principles and practices that contribute to
 producing better software
 making software development more predictable and economical.
 You will learn about
 how software development practices have changed in the last few
decades( 面向过程 – 面向对象 )
 the different phases that a software product goes through.
 You will study
 specific techniques for improving the quality of products, for each
phase of software development
 You will read about
 the interactions and expectations of groups and organizations that
participate in the software development process.
 course organization
 The course is organized into
 eight units, each with several sections.
 All units have
 a multiple-choice quiz (sum. 8 )
 a practical exercise (but the first unit, sum. 9).
 The exercises are part of the project for the course and lead
you to create a software product from start to finish.
 There are also three in-class exams.
 Prerequisites
 SSD4 User-Centered Design and Testing
 SSD7 Database Systems
 Course Textbook
 The required textbook for the course is:
 Schach, Stephen. Object-Oriented and Classical
Software Engineering. 6th ed
 Reference books
 软件工 程：实 践者 的研究 方法 （第 6 版） , （美）
ROGER S.PRESSMAN
 软件工 程导论 （第 四版） , 张海藩
 人月神 话 , （美 ） Frederick P. Brooks ， Jr.
 MySQL 使用 指南
 Java/jdbc 程序设 计
 大量专 门针对 开发 各阶段 的技 术与方 法书 籍
 需求工程
 OOA/OOD
 编程实践
 个人 / 小组过程
 测试
 ……
 Assigned Reading
 A complete list of SSD9 Required Readings has
been compiled for your reference.
 SSD9 Required Readings
Section Sixth Edition Fifth Edition
1.2 1.1 1.1
1.3 1.2–1.10 1.2–1.6
1.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
Section Sixth Edition Fifth Edition
2.2.2 2.9.2 3.2
2.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.2
3.1.2 11.3 11.3
3.1.3 11.7 11.6
3.2 11.6 11.5
 SSD9 Required Readings
Section Sixth Edition Fifth Edition
4.1.1 12.1–12.2 12.1
4.1.2 12.3–12.4 12.2–12.3
4.1.3 12.5 12.4
4.1.4 12.6 12.5
4.3.1 12.5.1 12.4.1
5.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.6
6.1.2 14.1–14.2 14.1–14.2
 SSD9 Required Readings
Section Sixth Edition Fifth Edition
6.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.9
6.2.3 6.5, 14.13.2, 14.16, 14.25 6.5, 14.8.2, 14.11, 15.12
6.2.4 14.15–14.19 14.10–14.14
6.3 14.6, 14.20 15.1–15.3
6.4 6.4, 14.21–14.22 6.4, 15.4–15.5
6.5 5.4–5.10, 14.24.1–14.24.2 5.4–5.10 and 15.6–15.8
2.2.2, 2.3.2, 2.4.2, 2.5.2,
7.1
2.6.2, 2.7.2
7.5 9.9 9.9
 SSD9 Required Readings
Section Sixth Edition Fifth Edition
8.1 15.1–15.3, 15.6 16.1–16.3, 16.6
8.2 15.4, 15.7–15.8 16.4, 16.7–16.8
8.3 15.5 16.5
8.4 15.9–15.11 16.9–16.11
 The purpose of SSD9 is for students to Learn
 the principles and practices for producing better
software and for making software development more
predictable and economical
 to examine critically the different phases of a software
product's life cycle
 various approaches to software design
 the role of software architecture in software design
 structured systems analysis, object-oriented analysis
(OOA), and object-oriented design (OOD)
 the different types of software testing, documentation,
and maintenance techniques
 to design and build Internet-based software projects of
significant scale
 acquiring experience in all phases of the software
product life cycle
 Students successfully completing SSD9 will be able to

 I. Produce( 做出各 类成果 )

 1. Software systems based on customer requirements
 2. Scope descriptions( 功能范围描述 ) and
requirements checklists （需求对照表） by choosing
a suitable development model
 3. Unified Modeling Language (UML) diagrams
illustrating the use cases identified for the software
product
 4. Use case scenarios( 用例情形 ) for normal and
abnormal use cases
 5. A class list for a product using the noun extraction
（名词提取） technique
 Students successfully completing SSD9 will be able to

 I. Produce( 做出各 类成果 )

 6. Class diagrams( 类图 ) and state transition diagrams(
状态转移图 ) using the UML notation
 7. Sequence diagrams （顺序图） and collaboration
diagrams （协作图） using UML
 8. Detailed class diagrams, object interface
specifications, and skeletal Java class files( 使用 java 实
现基本框架 )
 9. Detailed code documentation using Javadoc

 10. Project implementation plans, test plans, and

documents at every phase
 11. A final software system for demonstration
 Students successfully completing SSD9 will be able to

 II. Use （运用 ）

 1. OOA and OOD techniques
 2. Entity-relationship (ER) modeling techniques

 3. The MySQL database system and Java Database

Connectivity (JDBC) for a project
 4. Javadoc to produce documentation

 5. Techniques for improving the quality of artifacts for

each phase of software development
 Students successfully completing SSD9 will be able to

 III. Knowledgeably Discuss

 1. Specification techniques that address the various
software engineering principles
 2. Computer-aided software engineering (CASE)
technology
 3. Code reuse and design reuse

 4. Managing maintenance: fault reports, fault

prioritization
 5. Maintenance of object-oriented software
 Students successfully completing SSD9 will be able to

 IV. Hold Positions as Software Engineers

 Those who certify in this course will be able to
 (a) develop software systems using modern software
engineering principles;
 (b) make decisions about selecting the appropriate life-
cycle model for software development;
 (c) develop documents required by each life cycle of the
software development process;
 (d) develop test plans and acceptance test plans( 验收测
试计划 ) for complex software projects.
 Unit 1. Overview of Software Engineering
 1.1 Software Challenges and Myths
 1.2 History and Evolution
 1.3 Life Cycle and Economy
 1.4 Terminology

 Assessments
 Multiple-Choice Quiz 1
 1.1 Software Challenges and Myths
 In this module we will briefly survey
 some of the challenges to be faced when developing
software
 some of the misconceptions about software development
that have sprung up over the relatively short history of
large-scale software production.
 过来人会 告诉你……
 anyone who has participated in developing
software products of any significant size or
complexity will tell you two things.
 if there is something you can count on, it is that it will
take you longer to finish than you expect.
 even when you think the product is completed,
problems will still be lurking(" 潜伏 ") that testing will
not have found.
 Past and present
 In the old days, people used to say that whatever time
estimate you thought was reasonable, you should （ ×3,
× 10 ） .
 software development manager think:
 development delays, and errors found after delivery can incur unacceptable
losses:
 additional (unexpected) costs
 greatly diminished customer satisfaction( 满意度 ) and confidence( 信任度
)
 In today‘s competitive environment
 getting a product to market on time and with as few residual
“bugs”( 残留的缺陷 ) as possible can mean the difference
between the success and failure of a product, or even a company.
 软件危机
 软件危机
 是指在计算机软件的开发和维护过程中所遇到的一
系列严重问题。
 20 世纪 60 年代末至 20 世纪 70 年代初 ，“软
件危机”一词在 计算机界广 为流传。
 事实上，几乎从 计算机诞生 的那一天起 ，就
出现了软件危机 ，
 到了 1968 年在原西德 Garmish 召开的 NATO
的 国际软件工 程会议 上才被人们普遍 认识到
。
 正是这次会议， “软件工程 ”正式提出 并被
 软件危 机的表现 － 软件成 本日益增 长
 计算机 发展的 早期
 大型计算机系统主要是被设计应用于非常狭窄的军事领域。
 研制计算机的费用主要由国家财政提供，研制者很少考虑到
研制代价问题。
 随着计 算机市 场化 和民用 化的 发展
 代价和成本就成为投资者考虑的最重要的问题之一
 20 世纪 50 年代 ，
 软件成本在整个计算机系统成本中所占的比例为 10%-20% ，
主要是硬件成本太高。
 计算机硬件随着技术的进步 ( 晶体管的发明、集成电路 ) 、生
产规模的扩大，价格却不断下降
 随着软件产业的发展，软件成本日益增长。
 软件成本在计算机系统中所占的比例越来越大。
 软件危 机的表现 － 软件成 本日益增 长
 到 20 世纪 60 年代中期
 软件成本在计算机系统中所占的比例已增长到约
50%
 而且没有维持这个数字，该数字还在不断地递增，
 以下是一组来自 美国空军计 算机系统的 数据
：
 1955 年占 18% ，
 1970 年达到 60% ，
 1975 年达到 72% ，
 1980 年达到 80% ，
 1985 年达到 85% 左右
 为什么会有这么 高的比例
 人力成本增加，智力劳动之前了

 软件危 机的表现 － 开发进 度难以控 制
 由于软件是逻辑 、智力产品 ，软件的开 发需
建立庞大的逻辑 体系，这是 与其他产品 的生
产不一样的。
 例如：工厂里要生产某种机器，在时间紧的情况下
可以要工人加班或者实行“三班倒”，而这些方法
都不能用在软件开发上。
 在软件开发过程 中，用户需 求变化等 各种意
想不到的情况 层出不穷，
 软件开发过程很难保证按预定的计划实现
 给项目计划和论证工作带来了很大的困难
 软件危 机的表现 － 开发进 度难以控 制
 BROOK 曾经提出： “ 在已拖延 的软件项 目
上，增加人力只 会使其更难 按期完成 ”。
 软件系统结构复杂，各部分附加联系极大，盲目增
加软件开发人员并不能成比例地提高软件开发能力
。
 相反随着人员数量的增加，人员的组织、协调、通
信、培训和管理等方面的问题将更为严重。
 许多重要的大型 软件开发项 目，由于离 预定
目标相差甚远不 得不宣布失 败
 例如： IBM OS/360 和世界范围的军事命令控制系统
（ WWMCCS ），在耗费了大量的人力和财力之后
，宣布失败。
 软件危 机的表现 － 软件质 量差
 软件项 目即使 能按 预定日 期完 成，结 果却 不尽人 意
。
 例如： 1965 年至 1970 年，美国范登堡基地发射火箭多次失
败，绝大部分故障是由应用程序错误造成的。
 程序的 一些微 小错 误可以 造成 灾难性 的后 果，
 例如：美国发射一枚阿脱拉斯火箭，火箭飞离地面几十英里
高空开始翻转，地面控制中心被迫下令炸毁。后经检查发现
是飞行计划程序里漏掉了一个连字符。
 一个小小的疏漏造成了这支价值 1850 万美元的火箭试验失败。
　　
 在“软 件作坊 ”里 ，
 缺乏工程化思想的指导，程序员几乎总是习惯性地以自己的
想法去代替用户对软件的需求，
 软件设计带有随意性，很多功能只是程序员的 " 一厢情愿“
 软件 危机的表现 －软件维 护困难
 正式投 入使用 的软 件， 总是存 在 着一 定数量 的错 误
，
 在不同 的运行 条件 下，软 件就 会出现 故障 ，因此 需
要维护 。
 由于在软件设计和开发过程中，没有严格遵循软件开发标准
，各种随意性很大，没有完整的真实反映系统状况的记录文
档，给软件维护造成了巨大的困难。
 特别是在软件使用过程中，原来的开发人员可能因各种原因
已经离开原来的开发组织，使得软件几乎不可维护。
 软件修 改是一 项很 “危险 ”的 工作，
 对一个复杂的逻辑过程，哪怕做一项微小的改动，都可能引
入潜在的错误
 常常发生“纠正一个错误带来更多新错误”的问题，从而产
生副作用。
 资料表 明 ，工 业界为 维护 软件支 付的 费用占 全部 硬
件和软 件费用 的 40%-75% 。
 1976–1981 data
Maintenance constitutes 67% of total cost
 软件危 机的原因 －用户需 求不明确
 从软件危机的种 种表现和软 件作为逻辑 产品
的特殊性可以发 现软件危机 的原因
 用户需求不明确 问题主要体 现在四个方 面：
 在软件开发出来之前，用户本人也不清楚软件的具
体需求；
 用户对软件需求的描述不精确，可能有遗漏、有二
义性、甚至有错误；
 在软件开发过程中，用户还提出修改软件功能、界
面、支撑环境等方面的要求；
 软件开发人员对用户需求的理解与用户本来愿望有
差异。
 软件危机 的原因 －缺乏正确 的理论指导
 缺乏有力的方法 学和工具方 面的支持。
 由于软件不同于 大多数其他 工业产品， 其开
发过程是复杂的 逻辑思维过 程，其产品 极大
程度地依赖于开 发人员高度 的智力投入 。
 过分地依靠 程序设计人员在 软件开发过 程中
的 技巧和创造 性 ，
 加剧软件产品的个性化，也是发生软件危机的一个
重要原因。
 所以，软件开发 团队中不需 要“个人英 雄主
义”！
 软件危 机的原因 －软件规模越 来越大
 随着软件应用范 围的增广， 软件规模愈 来愈
大。大型软件项 目需要组织 一定的人力 共同
完成，
 多数管理人员缺乏开发大型软件系统的经验，
 多数软件开发人员又缺乏管理方面的经验。

 各类人员的信息 交流不及时 、不准确、 有时

还会产生误解。
 软件项目开发人 员不能有效 地、独立自 主地
处理大型软件的 全部关系 和 各个分支 ，因此
容易产生疏漏和 错误。
 软件危机的原因 －软件复 杂度越来 越高
 软件不仅仅是在 规模上快速 地发展扩大 ，而
且其复杂性也急 剧地增加。
 软件产品的特殊 性和 人类智 力的局限性 ，导
致人们无力处理 复杂问题
 所谓 " 复杂问题 " 的概念是 相对的 ，一旦 人
们采用先进的组 织形式、开 发方法和工 具提
高了软件开发效 率和能力， 新的、更大 的、
更复杂的问题又 摆在人们的 面前。
 如何克 服软件危 机
 人们在认真地研 究和分析了 软件危机背 后的
真正原因之后， 得出了
 人们面临的不光是技术问题，更重要的是管理问题。
管理不善必然导致失败
 开始探索用工程 的方法进行 软件生产的 可能
性，即用现代工 程的概念、 原理、技术 和方
法进行计算机软 件的开发、 管理和维护 。
 于是，计算机科 学技术的一 个新领域 -- 软件
工程诞生了。

　　
 如何克 服软件危 机
 软件工 程是
 用工程、科学和数学的原则与方法研制、维护计算机软件的
有关技术及管理方法。
 软件工 程包括 三个 要素：
 （ 1 ）方法。软件工程方法为软件开发提供了“如何做”的
技术，是完成软件工程项目的技术手段；
 （ 2 ）工具。软件工具是人类在开发软件的活动中智力和体
力的扩展和延伸，为软件工程方法提供了自动的或半自动的
软件支撑环境；（工欲善其事，必先利其器）
 （ 3 ）过程。软件工程的过程则是将软件工程的方法和工具
综合起来以达到合理、及时地进行计算机软件开发的目的。
 迄今为 止，软 件工 程的研 究与 应用已 经取 得很大 成
就，它 在软件 开发 方法、 工具 、管理 等方 面的应 用
大大缓 解 了软 件危机 造成 的被动 局面 。
 Questions ？ So many Whys……
 Why are the costs of software development so
high?
 In part, because software development frequently goes
over the estimated time limits.
 why does it take so long to get programs
finished?
 Why do we have difficulty measuring
development progress?
 why can we not find all errors before we deliver?
 Anwser for Whys……
 We do not have a simple answer because
 the software process is a complex one,
 involving multiple parties
 Each have different objectives( 实现目标 ) and constraints( 约束
条件 ). （需求、分析设计、实现、调试、部署、维护……）
 The actors (the customers, managers, and developers) in
software production with seemingly
reasonableexpectations and attitudes ( 看上 去很 合理
的想法 )
 that can contribute to increasing the time and cost of product
development.
 Some of these expectations and attitudes, although
mistaken, are quite widespread that they have acquired
a mythical status.
 SOFTWARE MYTHS( 软件神话， 软件开发的 误
区)
 Today, most knowledgeable professionals
recognize myths for what they are—
 misleading attitudes that have caused serious problems
for managers and technical people alike.
 old attitudes and habits are difficult to modify, and
remnants of software myths are still believed.
 Types
 Management myths
 Customer myths

 Practitioner's myths
 Management myths
 Managers with software responsibility, like
managers in most disciplines, are often under
pressure to
 maintain budgets
 keep schedules from slipping

 improve quality

 Like a drowning person who grasps at a straw( 救

命稻草 ), a software manager often grasps at belief
in a software myth, if that belief will lessen the
pressure .
 Management myths
 Myth: We already have a book that's full of standards and
procedures for building software, won't that provide my
people with everything they need to know?
 Reality:
 The book of standards may very well exist, but is it used?
 Are software practitioners aware of its existence?
 Does it reflect modern software engineering practice? Is it
complete?
 Is it streamlined( 经过修 改 ) to improve time to delivery
while still maintaining a focus on quality?
 In many cases, the answer to all of these questions is "no.“
 问题是 你用了 没有 ，遵照 执行 了没有 ？
 Management myths
 Myth: My people have state-of-the-art （最新）
software development tools, after all, we buy them
the newest computers.
 Reality:
 It takes much more than the latest model mainframe,
workstation, or PC to do high-quality software
development.
 Computer-aided software engineering (CASE) tools
are more important than hardware for achieving
good quality and productivity, yet the majority of
software developers still do not use them effectively.
 好的开发平台有 的是，但最 重要的是一 个合
适的 CASE 工具
 Management myths
 Myth: If we get behind schedule, we can add more
programmers and catch up.
 Reality:
 Software development is not a mechanistic process like
manufacturing.
 Brooks said: "adding people to a late software project makes
it later."
 At first, this statement may seem counterintuitive.
However, as new people are added,
 people who were working must spend time educating the
newcomers,
 thereby reducing the amount of time spent on productive
development effort.
 People can be added but only in a planned and well-
coordinated manner.( 只能是按 计划 地增加 )
 Management myths
 Myth: If I decide to outsource （外包） the
software project to a third party, I can just relax and
let that firm build it.
 Reality:
 If an organization does not understand how to
manage and control software projects internally,
 it will invariably struggle( 陷入困 境 ) when it
outsources software projects.
 客户 开发组织（不能置之不理）
 开发组织 开发组织（也不能置之不理）
 Customer myths
 A customer who requests computer software may be
 a person at the next desk,
 a technical group down the hall,
 the marketing/sales department,
 an outside company that has requested software under
contract.
 In many cases, the customer believes myths about software
because
 software managers and practitioners do little to correct
misinformation( 讹传 ). 没有 相关 人员给 他们 纠正
 Myths lead to false expectations (by the customer) and
ultimately, dissatisfaction with the developer. 最终形成对
开发者地不满
 Customer myths
 Myth: A general statement of objectives is
sufficient to begin writing programs—we can fill in
the details later.
 Reality:
 A poor up-front definition( 糟糕 的需求 定义 ) is the
major cause of failed software efforts.
 A formal and detailed description of the information
domain, function, behavior, performance, interfaces,
design constraints, and validation criteria is essential.
 These characteristics can be determined only after
thorough communication( 密切合 作、有 效沟 通 )
between customer and developer.
 Customer myths
 Myth: Project requirements continually change, but
change can be easily accommodated because
software is flexible.
 Reality:
 It is true that software requirements change, but the
impact of change varies with the time at which it is
introduced.
 If serious attention is given to up-front( 预先 )
definition, early requests for change can be
accommodated easily. The customer can review
requirements and recommend modifications with
relatively little impact on cost.
 Customer myths
 Myth: Project requirements continually change, but
change can be easily accommodated because
software is flexible.
 Reality:
 When changes are requested during software design,
the cost impact grows rapidly.
 When Resources have been committed and a design
framework has been established.
 Change can cause upheaval ( 引起剧变 )that requires
additional resources, major design modification, additional
cost.
 Changes in function, performance, interface, or other
characteristics during implementation (code and test) have
a severe impact on cost.
 the impact of change
 Change, when requested after software is in
production, can be over an order of magnitude more
expensive than the same change requested earlier.
 Practitioner's myths
 Myths that are still believed by software
practitioners have been fostered( 培育 ) by 50 years
of programming culture.
 During the early days of software, programming
was viewed as an art form( 艺术活动 ).
 Old ways and attitudes die hard.
 Practitioner's myths
 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 60 ~ 80% of all effort
expended on software will be expended after it is
delivered to the customer for the first time.
 搞清需求再动手！
 Practitioner's myths
 Myth: Until I get the program "running" I have no
way of assessing its quality.
 Reality:
 One of the most effective software quality assurance
mechanisms can be applied from the inception of a
project( 项目初 期 ) — the formal technical review.
 Software reviews( 软件评 审 ) are a "quality filter"
that have been found to be more effective than testing
for finding certain classes of software defects.
 Practitioner's myths
 Myth: The only deliverable work product for a
successful project is the working program.
 Reality:
 A working program is only one part of a software
configuration that includes many elements.
 Documentation provides a foundation for successful
engineering and, more important, guidance for
software support.
 Practitioner's myths
 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.

赶工导 致返工 ！
 Some mistaken perceptions about software
development originate with the customer. For
example:
 "A general statement of objectives is sufficient to begin
writing programs�we can fill in the details later."
 "Project requirements continually change, but change
can be easily accommodated, because software is
flexible."
 Both of these myths reflect the perception that, because
software can be changed more easily than a
manufactured product, it can be modified in response to
changing requirements at any point in the process,
without paying any penalty. While it is true that it is
easier to change code than to change a manufactured
product, the repercussions of software changes go far
beyond the actual change itself. In some cases, the
changes will be very localized and minor; in other cases,
they may require substantial redesign of the affected
component, as well as interacting components. In all
cases, any change will require substantial testing to
make sure that no new problems have been
inadvertently introduced.
 Some of the misconceptions about software
development come from the developers
themselves. For example:
 "Once we write the program and get it to work, our job
is done."
 "The only deliverable for a successful project is the
working program."
 "Until I get the program running, I really have no way of
assessing its quality."
 While it is true that a working program is an
essential component of successful software
development, it is by no means the only
component. Depending on what agreements have
been reached for maintaining the software after
delivery, either the developer or the customer
will need to make some modifications to the
code. At that point, it will be extremely
important to have code that is clearly written
and well documented, since it is very likely that
the programmers making the modifications will
not be the same ones who wrote the code
initially. Even if the programmers were the
same, they would quickly find out how much
they had forgotten about their own programs!
 Finally, some of the myths surrounding the need for software engineering may come from the
management of the organization where the product is being developed. Consider the following
statements coming from a manager and, immediately following them in each case, some objections
that should be raised:
 "We already have a book full of standards and procedures."
Any manager working in an organization whose daily running already requires adherence to a number of
standards and procedures is, understandably, reluctant to add more. Yet those existing standards and procedures
may have little impact on the quality of the software process; perhaps they are outdated and do not reflect current
practices, or perhaps they are simply not applied.

 "My people have state-of-the-art software development tools, because we bought them the newest computers."
Hardware by itself contributes relatively little to high-quality software development; it is more important to have
good software tools and well-defined development practices.

 "If we get behind schedule, we can just add more programmers."

Today's computers can run very large software products that would take a single person a long time to develop.
Although team programming permits the development of large products in a short time by allowing work in
parallel, it also introduces complexity. Changes affecting the interface to modules of the system need to be
distributed among all programmers whose code interacts with those modules. Coordination among team members
may require lengthy meetings and conferences. When adding new programmers to an ongoing project, one must
consider the time that it will take the new programmers to get up to speed and become productive, and the time
required for existing team members to train the newcomers, as well as any additional time required for
communication and coordination within the enlarged group.
 While trying to debunk individual myths
surrounding software development may be
useful in itself, the real solution for meeting the
challenges of software production is to provide a
framework that supports constant, evolutionary
improvement in product and process, based on
an explicit model of the development process. In
Unit 2, we will examine some of the models that
have already been developed.
 At the very beginning of this unit, we defined software
engineering rather generally as "a discipline whose aim is the
production of fault-free software that satisfies the user's needs
and that is delivered on time and within budget." More
specifically, software engineering is an endeavor whose objective
is to set realistic expectations regarding the software development
process, so these expectations can be satisfied. It achieves its
objective by planning for and tracking a development itinerary
where the functionality of a product matches its requirements,
the development schedule satisfies the constraints of both the
customer and the developer, and the overall cost of development
does not exceed the budget provided for it. Knowing how to
analyze and manipulate the trade-offs between what the
customer wants and what the software producer can provide
under the given constraints is what separates a system engineer
from a mere programmer. From the software engineering point
of view, actual coding is a small part of the overall effort!
 Finally, in the midst of hardware, software,
schedules, and budgets, one should not forget
that, like many other enterprises, software
production involves human beings�the
customers, the programmers, and the
managers�and therefore software engineering
is directly concerned with managing people and
facilitating communication.
 1.2 History and Evolution
 a brief history of software development
 the evolution of software practices since the
1950s.
 The growing complexity of software
applications, together with the lessons learned
from early software projects, have made
software engineering increasingly important in
today‘s use case.
 软件工程从项目 实践的摸爬 滚打中一路 走来
、壮大、形成体 系、趋向完 善……
 a brief history of software development
 In the 1950s and through much of the 1960s, hardware
dominated the computer world.
 Several years after the invention of the transistor( 晶体
管 ) in 1947, computers began scaling down in size and
cost.
 In 1954, IBM announced its first transistor-based
computer 之前 都是 电子管 ，体 积很大
 by the late 1950s several organizations, companies, and
universities had computers at their disposal( 利用 计算
机进行 处理 ).
 At that time, computers were still very expensive and
very large:
 a computer significantly less powerful than today's laptop
occupied as much as one or two rooms,
 together with permanent storage devices 永久存贮装置 and
other accessories.
 a brief history of software development
 Management of computer production was
substantially hardware oriented
 many of the same practices applicable( 可使用的实践 )
to the manufacturing of industrial products formal
standards, quality controls, and cost controls were
applied to hardware.
 There was an area of expertise( 专门的领域 )
called hardware engineering, but the software
itself was still something of an afterthought( 置
之脑后 ).
 a brief history of software development
 Much attention and capita( 资金 ) went into
hardware
 software production and programming was the
purview( 范围 ) of a few individuals who
understood how to make all that machinery do
something useful.
 They worked with programming languages (like
assembly language) that few programmers would choose
to use today.
 Programming was definitely seen as more of an art than
a science, and had little visibility at the management
level.
 a brief history of software development
 Programmers were given complete responsibility for the
software, and it was common for a programmer to begin coding
without spending any time on analysis, specification, or design.
 This approach led to an undisciplined style( 无组 织无 纪律 ) of
programming, following few formal methods( 很少有正 规的 开
发方 法 ) and learning by trial and error.
 There was a lack of predictability in the quality of the code, and a
lack of accountability on the part of its developers( 开发者 缺乏
责任 心 ).
 It was difficult if not impossible to estimate how long a project
would take.
 the code was often poorly and incompletely documented causing
a severe problem for anyone taking over its maintenance from
the original developers.
 a brief history of software development
 through the late 1960s
 As computers became more widespread
 1970s
 More and more of people and organizations relying on hardware
and software
 the disorderly world of software development was destined for
reform.
 In the literature, one finds references to the "software
crisis" of the 1970s,
 an era when
 the quality of software was generally unacceptably low,
 deadlines were seldom met
 costs sometimes went over budget to a significant degree.
 a brief history of software development
 The costs of software development began to
overshadow( 超出 ) the costs associated
with hardware.
 It was clearly time to replace the old
CABTAB ("code a bit, test a bit . . . don't
know how long it will take") approach to
programming, which had become too
costly, with a new one that emphasized
formal methods for
 quality assessment
 cost control
 a brief history of software development
 the 1970s through the 1990s
 Efforts from focused on
 increasing understanding of the science of programming,
 improving predictability of the software product and process
 improving the accountability of the participants. ( 明确责任 )

 The software development process became a

primary object of study for research and
development,
 E.g., especially at newly founded research
institutions like
 Carnegie Mellon University's
Software Engineering Institute
(http://www.sei.cmu.edu).
 a brief history of software development
 Still, the problems of the original “software
crisis” have not been completely alleviated( 减
轻 ), and the effectiveness of software
development is still poor in many fields.
 Stephen Schach suggests that the “software
crisis” should have been called the “software
depression,” because it has lasted significantly
longer than a crisis normally does. ( 危机：一 阵
，萧条：持久 )
 a brief history of software development
 Today software has become ubiquitous （无处 不在）
and its quality is even more crucial.
 business decisions.
 the basis for solutions to science and engineering problems.
 relied upon by
 transportation and telecommunication systems, by
 the medical
 Industrial
 military establishments
 entertainment industry.
 各行各业，人们已经离不开它了……
 Therefore, it is even more vital now to improve the
predictability of the software process in terms of
 cost
 time
 correctness.
 The term "software engineering"
 was coined( 形成 ) in 1967 and formally
endorsed( 认可 ) the following year by the
NATO Software Engineering Conference, held in
Germany.
 It reflected the hope that
 software could be designed, implemented, and managed
like products in other engineering disciplines,
 E.g.,like road, bridges, skyscraper in civil engineering.
 We do not build road bridges using trial-and-
error methods, because the costs are too high( 试
不起！ ).
 In terms of both money and safety. So why do we
build software that way?
 The bridge analogy 软件与 修桥的类 比
 beneficial in some ways.
 It points out that, in the case of products like bridges, the
designers make their best effort to anticipate different
conditions and problems resulting from them.
 Consequently, the product is designed to avoid total
failure and to withstand problem conditions by designing
for them and building in a margin of safety.
 But the analogy with bridges breaks down in
certain respects.
 In the first place, the analogy is not always applicable to
all software systems.
 E.g., when using rapid prototyping as part of the
development strategy, the prototype is not expected to be
robust.
 The bridge analogy
 Many finished applications, software failure either a
crash or an incorrect result is not as catastrophic( 灾难
) as the failure of a bridge structure,
 because a program can be easily restarted but a bridge
cannot be rebuilt quickly or easily.
 The program can be reinitialized or its state recovered, if it was
periodically saved, with relatively little cost.
 The bridge analogy
 problems that do not lead software system to a
crash can be more insidious( 潜伏 ).
 Errors may accumulate , causing the internal state of the
system to deteriorate over a long while.( 差错长期累积
，使系统恶化 )
 By the time a failure occurs, it is difficult to find
the primary cause of the fault
 Signs of failure may be more obvious in a
frequently inspected bridge.
 The bridge analogy
 Moreover, fault tolerance and failure avoidance in a
software system will necessarily take a different form
than in a physical structure. E.g.,
 you cannot exactly guarantee safety an engineer designs a bridge
for heavier-than-expected loads.
 But, over-designing the software is ok .
 Detection of and recovery from faults is to be implemented by
embedding consistency( 相容性 ) and assumption checks （各种
假定情况检查） in the program,
 by providing error reports （出错报告） and recovery
options （恢复方法） before a situation is reached that leads to
a system crash (e.g., attempts to divided by 0).
 Difference: maintenance of systems
 Due to the changing requirements, software is
incrementally redesigned and re-implemented
throughout its lifetime
 while bridge maintenance is typically very minor and localized.
 The kinds of software changes in its lifetime as part of
maintenance are far more radical than those bridges are
expected to. ( 软件常 常大改 ，桥 梁只会 是小 修小补 )
 Bridges may need to be rebuilt every so often to accommodate
more traffic and heavier loads, but there are bridges that have
lasted with little maintenance for hundreds of years! ( 历经千百年
的桥 )
 In contrast, a software product may have a very short
lifetime before it reaches obsolescence （废弃 ） or
before it becomes more costly to maintain than replace.
 Difference ： experience accumulation
 unlike bridge building, the experience
accumulated in developing software will not
necessarily( 不一定 ) result in better software
 because the hardware platforms and associated operating
systems are changing and becoming complex at a faster
rate than we can master them. （我们在掌握之前就更
新换代了）
 This acceleration is partly due to
 the quantum leaps （高速发展） made by hardware
technology in the last half-century,
 changes in the capabilities of software tools.
 1.3 Life Cycle and Economy
 The goal of this module is to introduce
 the overall software life cycle,
 economic factors that influence both the choice of a
development approach and overall constraints on
development itself.
 goal of software engineering
 There are many ways to write programs that
produce a set of desired output from a specified
set of input.
 The goal of software engineering is to
 find the development methodology that is optimal,
where optimality might be evaluated along several
different dimensions 衡量方法 according to the
situation.
 when deciding on an optimal development methodology

 development time
 development cost
 product quality
 Maintainability
 and so on……
 An example of software development
 the FastWeb company decides to develop a program
that will convert a set of documents to HTML format.
 If this job is to be done once, by internal staff only,
 it might make sense to select a development methodology that
minimizes cost and time, at the possible expense of quality.
 It is okay if the software crashes once in a while, because external
customers will never use it.
 On the other hand, if the conversion program will
become part of FastWeb's suite of support tools for
external customers,
 quality and maintainability are much more important;
 in this case, a development methodology that produces software
that is more reliable may be considered optimal even if it takes
more time and money.
 model of software development
 Any model of software development must take
into consideration that the software goes through
several different phases in its lifetime.
 All software development involves these basic
activities:
 requirements analysis,
 specification,
 design,
 Implementation,
 integration,
 maintenance
 retirement.
 Requirements analysis:
 The developer meets with the customer to
understand the problem to be addressed by the
proposed software system.
 an interview process
 explore and refine the concept
 identified and discussed the client's specific
requirements and constraints
 What we get in this phase
 a requirements document or checklist
 Specification
 Using the requirements document as a guide
 the developer produces
 a specification for all of the functionality to be included
in the product
 a development methodology

 estimated cost and schedule.

 Design
 Using the functional specification as a guide
 the developer produces
 detailed design documents
 For the individual software modules to be built
 For the overall software architecture that will integrate those
modules and interface with the customer's software
environment.
 Implementation
 Following the design documents and the
guidelines in the project plan
 the developer programmers construct the
individual software modules.
 This phase ends when all the modules have been
implemented(coding) and tested independently.
 Integration
 The individual modules are combined into the
overall software architecture,
 then be tested by both the developer and the
customer.
 This phase ends
 when various customer acceptance tests( 接收测试 )
(related to functional requirements) are successful
 the software is deployed at the customer site.
 Maintenance
 After acceptance of the original product
 all changes to the software are considered part of
the maintenance process.

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

 Types of maintenance
 Corrective( 改正型 ) maintenance
 which removes residual faults with no change in original specifications
 Enhancements( 增强型 ) or updates
 which imply changes to the original specifications and new development
 Perfective( 完善型 ) maintenance
 which improves the performance of existing functionality
 Adaptive( 适应型 ) maintenance
 which includes changes made when the product must operate in a new software
environment
 Note:
 It is important to note that all software undergoes maintenance, not just bad
software. Software must constantly adapt to changes in the functional
requirements and operating environments of the organizations using it.
Maintenance typically absorbs the majority of the cost and time invested in a
software product.
 Retirement
 be finally taken out of service
 the functionality supported by the software
becomes obsolete （功能 废弃）
 retirement usually involves exporting some
existing data to one or more new applications
before the software is taken out of service.
 Retirement
 When to Retire? is based on a variety of factors:
 The immediate cost of the new technology versus the old (the
purchase price of the product)
 The cost of developing and maintaining applications that use the
new technology
 The effort to train staff who will use the new software
 The short-term loss of overall productivity during training and
familiarization
 Note:
 Software can be retired and replaced in a variety of situations.
 no choice but to replace existing software and the costs involved are
mandatory ( 被迫 )(Y2K bug).
 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
before the short-term costs of replacement are recuperated( 弥补 ).
 About these phases
 These are usually part of a global project plan
that indicates how each of these phases will be
carried out.
 The project plan includes an
 overall schedule (including activities and milestones)
 possibly other forms of global documentation
 such as a risk management plan
 a test plan

 an integration plan

 ……
 About these phases
 In practice, some life-cycle models emphasize an
approach where
 each phase can and should be undertaken more than once
in an iterative or cyclic fashion.
 This is often necessary when certain aspects of
the requirements, design, etc. are not well
understood until after some software has already
been constructed.
 Classical vs OO approach
 "classical" software engineering,
 focuses on the construction of structured programs.
 Specific code modules, programming languages, etc. are
not actively considered until after the specifications
phase has ended.
 the object-oriented approach
 explicitly consider reusing existing code objects during
the analysis and specification phases.
 note
 You should understand
 the boundaries of the different phases are fluid （不是一
成不变的） ;
 depending on the life-cycle model and implementation
approach,
 different tasks may fall under( 应用 ) different phases

 the phases themselves may be arranged in different

groupings and/or orderings of tasks.
 Table 1. Relative Time, Cost of Life-Cycle Phases
Phase Costs Time
21% / 18% (and
Requirements 2%
specifications)

included in
Specifications 5%
requirements
Design 6% 18% / 19%
36% / 34% (and
Module coding 5%
testing)
Module testing 7% included in coding
Integration 8% 24% / 29%
Maintenance 67% —
 comparative time and effort spent
 Surprisingly, the most time is not spent in the
original coding of the modules, but in
maintenance activities after delivery.
 This is especially true of software that remains in
service for long periods of time, that typically
undergoes several modification to accommodate
 changing requirements
 changes in the operating environment

 integration with other software ……

 One important implication
 Any design element, testing technique or support tool
that significantly improves extensibility of the software
(and/or reduces the time required to update and test it)
will have a greater overall impact on project cost than
corresponding technical breakthroughs on the coding
process.
 其他方 面的改 进比 编码过 程中 的技术 突破 更有效 、
节省成 本！为 什么 呢 ?
 A good software engineer will consider
 the various elements of a possible maintenance plan,
 optimizing the design and implementation of the system to
promote straightforward, low-cost( 简单、低成本的 )
maintenance.
 Another characteristic of software engineering
 budget is spent as follows
 Requirements  specification  design (30%)  the
coding phase (only 5% )  testing  integration (30%)
……
 Why ?There are two reasons for this.
 quality software delivery depends on a significant
investment in these non-coding activities.
 the actual time spent coding up the system can be
dramatically reduced if detailed specifications and
designs have been created in advance. ( 需求详尽了，
编码轻松了 , 设计工具甚至支持自动代码生成…… )
 Time of coding
 从前那些事…… Before the advent of SE
 coding took much longer because the details of
the requirements and design were discovered
during implementation.
 Changes in requirements and design can imply
significant rewriting of existing code
 the coding phase takes much longer
 When not enough time is to write good specifications
and design documentation
 quality assurance activities
 Schach said:
 more errors are introduced in the specification and
design phases than in later phases of the life cycle.
 So it is important that quality assurance
activities begin early, even before coding begins!
 Although specification and design documents
can‘t be tested the way software is tested, they
can be discussed and evaluated in formal
reviews, which aim to identify various faults that
must be rectified （修正） before
implementation begins.
 cost of finding faults
 The overall cost of finding faults increases exponentially( 指数 增
长 ) in the later stages of the software life cycle.
 In later phases of the software cycle, more people and artifacts
are affected by software changes.
 when a fault is discovered
 all of the previously completed phases may require significant revision or
replacement
 Previously implemented software must be edited, recompiled, and tested to
verify that changes are successful and that no other errors were introduced.
 Documentation must be updated.
 if the software has already been delivered, a new version of the entire product
must be delivered and installed
 it is much more cost effective to identify faults as early as possible
in the life cycle.
 identifying problems as early as possible
 three main components of each step
 Each step or phase in the life cycle can be
discussed with respect to its three main
components:
 Process 过程 : the distinct / interdependent tasks carried
out during the phase
 Methods 方法 : the specific task descriptions for each of
the tasks in the process
 Tools 工具 : semi- or fully automated support tools for
the process and methods
 Successful software engineering promotes high
quality in all aspects of the process, the methods,
and the tools.
 planning is required
 Although substantial planning( 概要地计划 ) is
required to pin down( 确定使用 ) all the details
of process, methods, and tools for a given phase,
a detailed plan is an absolute prerequisite for
 accurate cost estimation
 resource allocation

 scheduling
 1.4 Terminology
 some of the key terms in software engineering
were presented and explained.
 key terms
 A product is any nontrivial piece of software. 具有使用 价值地
软件
 A system is the combination of hardware and software that runs
the product.
 A methodology 方法 or paradigm 模式 is a particular
approach, or set of techniques, designed to accomplish a specific
phase or a number of phases in the software development life
cycle.
 A bug is the colloquial term( 口头语 ) used to refer to a software
fault.
 Although this term is commonly used by programmers and users, it is
important to break the notion down( 区分开 ) more formally into three terms
with different meanings:
 A fault( 差错 ) is the actual problem in the code that is causing a
failure.
 A failure( 故障 ) is the behavior perceived by the user that results
from the fault in the code.
 An error( 错误 ) is the programmer's mistake that led to the
fault in the code.
 example for distinction between fault ， failure and error
 an error might occur when the programmer
forgets to copy the latest version of a Java class
file to the directory from which the product is
assembled in preparation for delivery.
 The fault might be that the product throws an
unknown method exception and terminates.
 The observed failure might be that the system
freezes when the user clicks on the "Save"
button in the product's user interface.
 This simple example illustrates how difficult it
can be to uncover the error from the observed
failure.
 more group of terms
 the three main participants in the software
development process:
 The client
 the individual or organization who wants a product to be
developed
 The developer
 the individual or group responsible for building the product
 The user(s)
 the person or persons who will utilize the product and on
whose behalf the client has commissioned the product
 The roles of client, developer, and user
 Sometimes the client and the user are the same
individual or organization, and the developer is
some outside party contracted to build the
software.
 医院管理层委托欲开发手术病人体征记录软件，医
生护士使用
 For smaller software projects, the developer may
be an individual rather than an organization.
 At other times, all three roles may be filled by
groups inside the same organization.
 学校开发教学管理系统，或许教务部委托国软学院
开发，全校师生使用 .
 distribution of roles in software development
 contract software development
 the client and the developer are completely separate organizations
 internal software development
 the client and the developer are part of the same organization, is an instance of.
 Commercial off the shelf ( 商用现 货 ) / shrink-wrapped software
 the software product is being developed by a company or individual in
response to a perceived market need.
 the client could be identified with the management of the company
 the developer with the technical division of the company
 the user with the potential customer for the product.( 所有有需求的人 )
 Other variations also possible.

 they will all benefit from careful specification, design, planning,

testing, and maintenance of the software product.