第1页 / 共140页
第2页 / 共140页
第3页 / 共140页
第4页 / 共140页
第5页 / 共140页
第6页 / 共140页
第7页 / 共140页
第8页 / 共140页
卡内基梅隆著名数据结构教程(ssd5).pdf
SSD9 - Software Specification, Testing, and Maintenance
Software Systems Development 9
Software Specification, Testing, and Maintenance
This course is an introduction to software engineering. Software engineering includes
the principles and practices that contribute to producing better software and to making
software development more predictable and economical. You will learn about how
software development practices have changed in the last few decades and about the
different phases that a software product goes through. For each phase of software
development, you will study specific techniques for improving the quality of products
and you will read about the interactions and expectations of groups and organizations
that participate in the software development process.
The course is organized into eight units, each with several sections. All units have a
multiple-choice quiz and all but the first unit contain a practical exercise. 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. You can read about
how to work through the quizzes, exercises, and exams in the course Help pages.
Prerequisites
SSD4 User-Centered Design and Testing; SSD7 Database Systems
Course Textbook
The required textbook for the course will be:
Schach, Stephen. Object-Oriented and Classical Software Engineering. 7th ed.
McGraw Hill Publishing Co., 2007. ISBN: 978-0-07-319126-3
OR
Schach, Stephen. Object-Oriented and Classical Software Engineering. 6th ed.
McGraw Hill Publishing Co., 2004. ISBN: 0-07-286551-2
Sixth edition of the book can be used instead of the new seventh edition;
copies of older editions may be available through sources that sell used books.
Important: Reading assignments given in the online notes are valid for any
edition unless otherwise noted. Where the readings for an edition differ from
the default, the page or section numbers are listed in parentheses for the
specified edition.
For your reference, Appendix B. Readings has a complete list of required
readings from the textbook.
Course Outcomes
1
SSD9 - Software Specification, Testing, and Maintenance
The purpose of SSD9 is for students to
1. Learn the principles and practices for producing better software
and for making software development more predictable and
economical
2. Learn to examine critically the different phases of a software
product's life cycle
3. Learn various approaches to software design and about the role
of software architecture in software design
4. Learn structured systems analysis, object-oriented analysis
(OOA), and object-oriented design (OOD)
5. Learn the different types of software testing, documentation,
and maintenance techniques
6. Learn 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
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
9. Detailed code documentation using Javadoc
10. Project implementation plans, test plans, and documents at
every phase
11. A final software system for demonstration
II. Use
1. OOA and OOD techniques
2
SSD9 - Software Specification, Testing, and Maintenance
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
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
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; and (d) develop test
plans and acceptance test plans for complex software projects.
Unit 1. Overview of Software Engineering
The overall goal of software engineering is the production of fault-free software that
satisfies the user's needs and that is delivered on time and within budget.
In this unit, we begin by examining some of the challenges of developing software,
and some of the myths that still surround the software development process. We then
look back at the evolution of software practices and at the concerns that motivated the
shift from a focus on programming to a wider view of software production. Next, we
introduce the stages of the software life cycle and consider their economic aspects.
The unit concludes with a brief review of some of the terminology that will be used
throughout the remainder of the course.
1.1 Software Challenges and Myths
1.2 History and Evolution
3
SSD9 - Software Specification, Testing, and Maintenance
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, and some of the misconceptions about software development
that have sprung up over the relatively short history of large-scale software
production.
Just about anyone who has participated in developing software products of any
significant size or complexity will tell you two things. First, if there is something you
can count on, it is that it will take you longer to finish than you expect. Second, even
when you think the product is completed, problems will still be lurking that testing
will not have found. In the old days, people used to say that whatever time estimate
you thought was reasonable, you should multiply it at least by a factor of three, or ten.
From the perspective of a software development manager, development delays, and
errors found after delivery can incur unacceptable losses, which take the form of
additional (unexpected) costs and 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.
Why are the costs of software development so high? In part, because software
development frequently goes over the estimated time limits. So why does it take so
long to get programs finished? Why do we have difficulty measuring development
progress and why can we not find all errors before we deliver? These questions do not
have a simple answer because the software process is a complex one, involving
multiple parties who have different objectives and constraints. The actors in software
production—the customers, managers, and developers—may come into the process
with expectations and attitudes that, while seemingly reasonable, 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. We will review some of these myths below. (For additional myths, refer to
Pressman 2000, section 1.4.)
4
SSD9 - Software Specification, Testing, and Maintenance
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! When it comes to assessing the quality of the program as well as its
ultimate correctness, other factors come into play. For example, we may ask whether
the assumptions made by each piece of the code are well defined, or whether a
complete test suite has been provided for the program, or for individual components
of the program. Being able to answer these questions positively will not only result in
a program that is easier to maintain, but will also help the programmer build
confidence in the building blocks of the system and assess its quality during
development. Formal software reviews that look at these aspects of the software will
also help to assess its quality.
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.
5
SSD9 - Software Specification, Testing, and Maintenance
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
6
SSD9 - Software Specification, Testing, and Maintenance
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.
References
Pressman, Roger S. Software Engineering: A Practitioner's Approach. 4th ed. New
York: McGraw Hill, 2000.
1.2 History and Evolution
The goal of this module is to provide a brief history of software development, by
considering 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.
Readings:
Schach, section 1.1.
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 and
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.
Management of computer production was substantially hardware oriented, and 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
7
SSD9 - Software Specification, Testing, and Maintenance
an area of expertise called hardware engineering, but the software itself was still
something of an afterthought.
With so much attention and capital going 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.
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 if any 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. Furthermore, the code was often poorly and incompletely documented causing a
severe problem for anyone taking over its maintenance from the original developers.
As computers became more widespread through the late 1960s and 1970s, the number
of people and organizations relying on hardware and software mushroomed, and 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 if ever met, and
costs sometimes went over budget to a significant degree. 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 and cost control.
Efforts from the 1970s through the 1990s focused on increasing understanding of the
science of programming, improving predictability of the software product and process,
and improving the accountability of the participants. The software development
process became a primary object of study for research and development, especially at
newly founded research institutions like Carnegie Mellon University's Software
Engineering Institute (http://www.sei.cmu.edu). 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 in his
textbook that the "software crisis" should have been called the "software depression,"
because it has lasted significantly longer than a crisis normally does. Today software
has become ubiquitous and its quality is even more crucial. It drives business
decisions. It serves as the basis for solutions to science and engineering problems. It is
heavily relied upon by transportation and telecommunication systems, by the medical,
industrial, and military establishments, and by the ever-growing entertainment
8
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
