Introduction to Software Engineering

Lesson 1

INTRODUCTION TO SOFTWARE ENGINEERING

n 1967, a NATO study group coined the phrase "software engineering" as a response to their belief that the current software crisis could be solved by adapting existing engineering practices to software development. This crisis was characterized

by the consistent development of low quality software that exceeded cost limits and development deadlines. Twenty years later, the software crisis was still thriving. Consider the following analysis done by the Government Accounting Office (GAO) in 1979 on the state of management information systems software development [Air Force 1996]. Out of the 163 contractors and 113 government personnel surveyed,

I

60% of their contracts had schedule overruns, 50% of their contracts had cost overruns, 45% of the software could not be used, 29% of the software was never delivered, and 19% of the software had to be reworked to be used.

Even today the software crisis is a significant problem that software engineering must address. Dr. John Dalbey of California Polytechnic State University organized the following information about the current state of the software crisis [Dalbey 1998].

In the September 1994 issue of Scientific American, W. Wayt Gibbs chronicled the following example of the modern software crisis in his article "Software's Chronic Crisis":

"Denver's new international airport was to be the pride of the Rockies, a wonder of modern engineering. Twice the size of Manhattan, 10 times the breadth of Heathrow, the airport is big enough to land three jets simultaneously in bad weather. Even more impressive than its girth is the airport's subterranean baggage-handling system. Tearing like intelligent coal-mine cars along 21 miles of steel track, 4,000 independent "telecars" route and deliver luggage between the counters, gates and claim areas of 20 different airlines. A central nervous system of some 100 computers networked to one another and to 5,000 electric eyes, 400 radio receivers and 56 bar-code scanners orchestrates the safe and timely arrival of every valise and ski bag.

At least that is the plan. For nine months, this Gulliver has been held captive by Lilliputians-errors in the software that controls its automated baggage system. Scheduled for takeoff by last Halloween, the airport's grand opening was postponed until December to allow BAE Automated Systems time to flush the gremlins out of its $193-million system. December yielded to March. March slipped to May. In June the airport's planners, their bond rating demoted to junk and their budget hemorrhaging

Lesson 1: Introduction to Software Engineering _______________________________________________________

red ink at the rate of $1.1 million a day in interest and operating costs, conceded that they could not predict when the baggage system would stabilize enough for the airport to open [Gibbs 1994]."

Eventually the Denver International Airport (DIA) did open, but the advanced baggage system was only partially functioning. The four delayed openings of the airport caused many residents to speculate that DIA really stood for "Do It Again," "Doesn't Include Airlines," or "Done In April". In order to finally open the terminal, the city invested $51 million to install a conventional baggage system as a work around to the high-tech system. Ironically, the conventional system was completed four weeks ahead of schedule and $3.4 million under budget [Cook 1995]. The obvious question is: why was the high-tech system so difficult to implement?

According to Fred Brooks [Brooks 1987], part of the answer to this question is that software is inherently complex. Unlike other engineering disciplines, software systems lack repeated elements. While a building may be constructed of thousands of bricks, a software product will combine pieces with the same functionality into a single subroutine. This means that software is composed of thousands of unique parts rather than repeated parts. Software systems also have very large numbers of operational states that makes exhaustive testing impossible. A bridge, on the other hand, is also a large and complex structure, but only a handful of extreme states (i.e. inclement weather, heavy traffic, earthquakes) need to be tested to insure the reliability of the bridge. In addition to inherent complexity, Brooks also mentions some other essential qualities of software such as changeability and invisibility that contribute to the software crisis. Changeability refers to the fact that all software eventually gets changed. Clients may want to add new functionality or developers may want to port the program to a new hardware platform. While it is unthinkable that a civil engineer would be asked to move a bridge to a new location, software engineers are regularly expected to perform major modifications on existing software. Invisibility refers to the fact that software is not a physical entity. Because of this, it is difficult for the human mind to use some of its most powerful conceptual tools in the development of software.

With these difficulties in mind, the need for effective software engineering becomes even more urgent. Software systems are playing an increasingly common role in our everyday lives. Failure to develop reliable software systems can cost more than just money and time. Consider the following examples cited by Michael Lyu in the introduction to the Handbook of Software Reliability Engineering:

"Unfortunately, software can also kill people. The massive Therac-25 radiation therapy machine had enjoyed a perfect safety record until software errors in its sophisticated control systems malfunctioned and claimed several patients' lives in

Software Project Management _________________________________________________________________

3

___________________________________________________ Software Engineering: A Computer Science Approach

1985 and 1986. On October 26, 1992, the Computer Aided Dispatch system of the London Ambulance Service broke down right after its installation, paralyzing the capability of the world's largest ambulance service to handle 5000 daily requests in carrying patients in emergency situations. In the recent aviation industry, although the real causes for several airliner crashes in the past few years remained mysteries, experts pointed out that software control could be the chief suspect in some of these incidences due to its inappropriate response to the pilots' desperate inquires during abnormal flight conditions [Lyu 1997]."

In this module, we will examine some of the fundamental concepts of software engineering such as the life cycle of software development and the two major paradigms of developing software. By the end of this section, you should be able to do the following:

Recognize the current software crisis and the need for software engineering,

Understand and reproduce the phases of the software life cycle,

Compare the procedural paradigm with the object-oriented paradigm (OOP), and

Understand the principles of the OOP.

FAQs about Software EngineeringThis section is designed to answer some fundamental questions about software engineering and also to give you some impression of my views of the discipline.

WHAT IS SOFTWARE? Many people equate the term software with computer programs. In fact, this is too restrictive a view. Software is not just the programs but also all associated documentation and configuration data which is needed to make these programs operate correctly. A software system usually consists of a number of separate programs, configuration files which are used to set up these programs, system documentation that describes the structure of the system and user documentation that explains how to use the system and, for software products, web sites for users to download recent product information.

Software engineers are concerned with developing software products, i.e. software that can be sold to a customer. There are two types of software product:

Generic products. These are stand-alone systems that are produced by a development organization and sold on the open market to any customer who is able to buy them. Sometimes they are referred to as shrink-wrapped software. Examples of this type of product include databases, word processors, drawing packages and project management tools.

_________________________________________________________________ Software Project Management

4


Bespoke (or customized) products. These are systems that are commissioned by a particular customer. A software contractor develops the software specially for that customer. Examples of this type of software include control systems for electronic devices, systems written to support a particular business process and air traffic control systems.

WHAT IS SOFTWARE ENGINEERING? Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. In this definition, there are two key phrases:

1. ‘engineering discipline’ Engineers make things work. They apply theories, methods and tools where these are appropriate but they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods to support them. Engineers also recognize that they must work to organizational and financial constraints, so they look for solutions within these constraints.

2. ‘all aspects of software production’ Software engineering is not just concerned with the technical processes of software development but also with activities such as software project management and with the development of tools, methods and theories to support software production.

In general, software engineers adopt a systematic and organized approach to their work, as this is often the most effective way to produce high-quality software. Engineering is all about selecting the most appropriate method for a set of circumstances and a more creative, informal approach to development may be effective in some circumstances. Informal development is particularly appropriate for the development of web-based e-commerce systems that requires a blend of software and graphical design skills.

WHAT IS THE DIFFERENCE BETWEEN SOFTWARE ENGINEERING AND COMPUTER SCIENCE? Essentially, computer science is concerned with the theories and methods that underlie computers and software systems whereas software engineering is concerned with the practical problems of producing software. Some knowledge of computer science is essential for software engineers in the same way that some knowledge of physics is essential for electrical engineers.

Ideally, all of software engineering should be underpinned by theories of computer science but in reality this is not the case. Software engineers must often use ad hoc approaches to develop the software. Elegant theories of computer science cannot always


5


be applied to real, complex problems that require a software solution.

WHAT IS SOFTWARE PROCESS? A software process is a set of activities and associated results that produce a software product. These activities are mostly carried out by software engineers. There are four fundamental process activities that are common to all software processes. These activities are:

Software specification. The functionality of the software and constraints on its operation must be defined.

Software development. The software to meet the specification must be produced.

Software validation. The software must be validated to ensure that it does what the customer wants.

Software evolution. The software must evolve to meet changing customer needs.

Different software processes organize these activities in different ways and are described at different levels of detail. The timing of the activities varies, as does the results of each activity. Different organizations may use different processes to produce the same type of product. Some processes on the other hand, are more suitable than others for some types of application. If an inappropriate process is used, this will probably reduce the quality or the usefulness of the software product to be developed.

WHAT IS A SOFTWARE PROCESS MODEL? A software process model is a simplified description of a software process that is presented from a particular perspective. Models, by their very nature, are simplifications, so a software process model is an abstraction of the actual process that is being described. Process models may include activities that are part of the software process, software products and the roles of people involved in software engineering. Some examples of the types of software process model that may be produced are:

A workflow model This shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in this model represent human actions.

A data-flow or activity model This represents the process as a set of activities each of which carries out some data transformation. It shows how the input to the process such as a specification is transformed to an output such as a design. The activities here may be at a lower level than

activities in a workflow model. They may represent transformations carried out by people or by computers.


6


A role/action model This represents the roles of the people involved in the software process and the activities for which they are responsible.

WHAT IS GOOD SOFTWARE? Just as manufacturers look for ways to assure the quality of the products they produce, so too must software engineers find methods to assure that their products are of acceptable quality and utility. Thus, good software engineering must always include a strategy for producing quality software. Garvin (1984) has written about how different people perceive quality. He describes quality from five different perspectives:In this section, we examine what distinguishes good software from bad software:

the transcendental view, where quality is something we can recognize but not definethe user view, where quality is fitness for purposethe manufacturing view, where quality is conformance to specificationthe product view, where quality is tied to inherent product characteristicsthe value-based view, where quality depends on the amount the customer is willing to pay for it.

The transcendental view is much like Plato’s description of the ideal or Aristotle’s concept of form. In other words, just as every actual table is an approximation of an ideal table, we can think of software quality as an ideal toward which we strive; however, we may never be able to implement it completely.

The transcendental view is ethereal, in contrast to the more concrete view of the user. We take a user view when we measure product characteristics, such as defect density or reliability, in order to understand the overall product quality.

The manufacturing view looks at quality during production and after delivery. In particular, it examines whether the product was built right the first time, avoiding costly rework to fix delivered faults. Thus, the manufacturing view is a process view, advocating conformance to good process. However, there is little evidence that conformance to process actually results in products with fewer faults and failures; process may indeed lead to high-quality products, but it may possibly institutionalize the production of mediocre products.

The user and manufacturing views look at the product from the outside, but the product view peers inside and evaluates a product’s inherent characteristics. The view is the one often advocated by software metrics experts; they assume that good internal quality indicators will lead to good external ones, such as


7


reliability and maintainability. However, more research is needed to verify these assumptions and to determine which aspects of quality affect the actual product’s use. We may have to develop models that link the product view to the user view.

Customers or marketers often take a user view of quality. Researchers sometimes hold a product view, and the development team has a manufacturing view. If the differences in viewpoints are not made explicit, then confusion and misunderstanding can lead to bad decisions and poor products. The value-based view can link these disparate pictures of quality. By equating quality to what the customer is willing to pay, we can look at trade-offs between cost and quality, and we can mange conflicts when they arise. Similarly, purchasers compare product costs with potential benefits, thinking of quality as value for money.

Professional and Ethical ResponsibilityLike other engineers, software engineers must accept that their job involves wider responsibilities than simply the application of technical skills. Their work is carried out within a legal and social framework. Software engineering is obviously bounded by local, national and international laws. Software engineers must behave in an ethical and morally responsible way if they are to be respected as professionals.It goes without saying that engineers should uphold normal standards of honesty and integrity. They should not use their skills and abilities to behave in a dishonest way or in a way that will bring disrepute to the software engineering profession. However, there are areas where standards of acceptable behavior are not bounded by laws but by the more tenuous notion of professional responsibility. Some of these are:

Confidentiality. Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.

Competence. Engineers should not misrepresent their level of competence. They should not knowingly accept work that is outwitting their competence.

Intellectual property rights. Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected.


8


Computer misuse. Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial to extremely serious.

In this respect, professional societies and institutions have an important role to play. Organizations such as the ACM, the IEEE and the British Computer Society publish a code of professional conduct or code of ethics. This code exists in both a short form and a longer form that adds detail and substance to the shorter version:

Software Engineering Code of Ethics and Professional Practice

PREAMBLEThis short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code.

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC – Software engineers shall act consistently with the public interest.2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests

of their client and employer consistent with the public interest.3. PRODUCT – Software engineers shall ensure that their products and related modifications meet

the highest professional standards possible.4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional

judgment.5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an

ethical approach to the management of software development and maintenance.6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession

consistent with the public interest.7. COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues.8. SELF – Software engineers shall participate in lifelong learning regarding the practice of their

profession and shall promote an ethical approach to the practice of the profession.

The general area of ethics and professional responsibility is one that has received increasing attention over the past few years. It can be considered from a philosophical standpoint where the basic principles of ethics are considered and software engineering ethics are discussed with reference to these basic principles. This is the approach taken by Laudon (1995) and to a lesser extent by Huff and Martin (1995).

I find this approach rather abstract and difficult to relate to my everyday experience. I much prefer the more concrete approach embodied in codes of conduct and practice. I think that ethics are best discussed in a software engineering context and not as a subject in their own right.


9


EXERCISES

1. What are the four important attributes that all software products should have? Suggest four other attributes that may be significant.

2. Describe the software crisis.

3. Why is it so difficult to build correct software?

4. What are three essential qualities of software? Explain each in your own words.

5. Why is it extremely important that software be correct?

6. What is the difference between a software process model and a software process? Suggest two ways in which a software process model might be helpful in identifying possible process improvements.

7. Discuss whether professional engineers should be certified in the same way as doctors or lawyers.

8. For each of the clauses in the ACM/IEEE Code of Ethics, suggest an appropriate example that illustrates that clause.


Documents

Introduction to Software Engineering