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

THE User-Centered Design and Testing; THE Database Systems

Course TextbookReference

The required textbook reference for the course will be:

Schach, Stephen. Object-Oriented and Classical Software Engineering. 6th ed. McGraw Hill Publishing Co., 2004. ISBN: 0-07-286551-2

Schach, Stephen. Object-Oriented and Classical Software Engineering. 5th ed. McGraw Hill Publishing Co., 2002. ISBN: 0-07-239559-1

Schach, Stephen. Classical and Object-Oriented Software Engineering, with UML and Java. 4th ed. WCB/McGraw Hill Publishing Co., 1998. ISBN: 0-07-230226-7.

Previous editions of the book can be used instead of the new sixth 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.

A complete list of THIS COURSE Required Readings has been compiled for your reference.

Course Outcomes

The purpose of THIS COURSE 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 THIS COURSE 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. / 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.1Software Challenges and Myths
1.2History and Evolution
1.3Life Cycle and Economy
1.4Terminology

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

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

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