Software Engineering Unit I Page 1 Unit 01: The Nature of Software & Software Engineering
Contents
1.1 THE NATURE OF SOFTWARE ... 2
1.1.1 Defining Software ... 3
1.1.2 Software Application Domains ... 4
1.1.3 Legacy Software ... 5
1.2 THE CHANGING NATURE OF SOFTWARE ... 6
1.2.1WebApps ... 6
1.2.2 Mobile Applications ... 6
1.2.3 Cloud Computing ... 6
1.2.4 Product Line Software ... 6
1.3 DEFINING THE DISCIPLINE ... 7
1.4 THE SOFTWARE PROCESS ... 8
1.4.1 The Process Framework ... 8
1.2.2 Umbrella Activities ... 9
1.4.3 Process Adaptation ... 10
1.5 SOFTWARE ENGINEERING PRACTICE ... 10
1.5.1 The Essence of Practice ... 10
1.5.2 General Principles ... 11
Software Engineering Unit I Page 2 Overview
Software is designed and built by software engineers. Software is used by virtually everyone in society.
Software is pervasive in our commerce, our culture, and our everyday lives.
Software engineers have a moral obligation to build reliable software that does no harm to other people..
Computer software continues to be the single most important technology on the world stage. And it‟s also a prime example of the law of unintended consequences. Sixty years ago no one could have predicted that software would become an indispensable technology for business, science, and engineering; that software would enable the creation of new technologies (e.g., genetic engineering and nanotechnology), the extension of existing technologies (e.g., telecommunications), and the radical change in older technologies (e.g., the media); that software would be the driving force behind the personal computer revolution; that software applications would be purchased by consumers using their smart phones; that software would slowly evolve from a product to a service as “on-demand” software companies deliver just-in-time functionality via a Web browser; that a software company would become larger and more influential than all industrial-era companies; that a vast software-driven network would evolve and change everything from library research to consumer shopping to political discourse to the dating habits of young (and not so young) adults.
1.1 THE NATURE OF SOFTWARE
Today, software takes on a dual role. It is a product, and at the same time, the vehicle for delivering a product.
As a product, it delivers the computing potential embodied by computer hardware or more broadly, by a network of computers that are accessible by local hardware. Whether it resides within a mobile phone, a hand-held tablet, on the desktop, or within a mainframe computer, software is an information transformer.
As the vehicle used to deliver the product, software acts as the basis for the control of the computer (operating systems), the communication of information (networks), and the creation and control of other programs (software tools and environments).
Software Engineering Unit I Page 3 The role of computer software has undergone significant change over the last half-century. Dramatic improvements in hardware performance, profound changes in computing architectures, vast increases in memory and storage capacity, and a wide variety of exotic input and output options have all precipitated more sophisticated and complex computer-based systems. Sophistication and complexity can produce dazzling results when a system succeeds, but they can also pose huge problems for those who must build and protect complex systems.
Today, a huge software industry has become a dominant factor in the economies of the industrialized world. Teams of software specialists, each focusing on one part of the technology required to deliver a complex application, have replaced the lone programmer of an earlier era. And yet, the questions that were asked of the lone programmer are the same questions that are asked when modern computer-based systems are built:
Why does it take so long to get software finished? Why are development costs so high?
Why can‟t we find all errors before we give the software to our customers? Why do we spend so much time and effort maintaining existing programs?
Why do we continue to have difficulty in measuring progress as software is being developed?
1.1.1 Defining Software
Software is: (1) Instructions (computer programs) that when executed provide desired features, function, and performance; (2) Data structures that enable the programs to adequately manipulate information, and (3) Descriptive information in both hard copy and virtual forms that describes the operation and use of the programs.
Software Engineering Unit I Page 4 Figure 1.1 depicts failure rate as a function of time for hardware. The relationship, often called the “bathtub curve,” indicates that hardware exhibits relatively high failure rates early in its life (these failures are often attributable to design or manufacturing defects); defects are corrected and the failure rate drops to a steady-state level (hopefully, quite low) for some period of time.
As time passes, however, the failure rate rises again as hardware components suffer from the cumulative effects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out.
Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the “idealized curve” shown in Figure 1.2. Undiscovered defects will cause high failure rates early in the life of a program. However, these are corrected and the curve flattens as shown. The idealized curve is a gross oversimplification of actual failure models for software. However, the implication is clear— software doesn’t wear out. But it does deteriorate!
1.1.2 Software Application Domains
Today, seven broad categories of computer software present continuing challenges for software engineers:
System software— a collection of programs written to service other programs. Some system software (e.g., compilers) processes complex, but determinate, information structures. Other systems applications (e.g., operating system components) process largely indeterminate data.
Application software—stand-alone programs that solve a specific business need. Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making.
Software Engineering Unit I Page 5 dynamics, and from computer-aided design to molecular biology, from genetic analysis to meteorology.
Embedded software—resides within a product or system and is used to implement and control features and functions for the end user and for the system itself. Embedded software can perform limited and esoteric functions (e.g., key pad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, etc.).
Product-line software—designed to provide a specific capability for use by many different customers. Product-line software can focus on a limited and esoteric marketplace (e.g., inventory control products) or address mass consumer.
Web/Mobile applications—this network-centric software category spans a wide array of applications and encompasses both browser-based apps and software that resides on mobile devices.
Artificial intelligence software—makes use of nonnumeric algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Applications within this area include robotics, expert systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game playing.
1.1.3 Legacy Software
Hundreds of thousands of computer programs fall into one of the seven broad application domains discussed in the preceding subsection. Some of these are state-of-the-art software—just released to individuals, industry, and government. But other programs are older, in some cases much older.
These older programs—often referred to as legacy software—have been the focus of continuous attention and concern since the 1960s.
Unfortunately, there is sometimes one additional characteristic that is present in legacy software—poor quality. Legacy systems sometimes have inextensible designs, convoluted code, poor or nonexistent documentation, test cases and results that were never archived, a poorly managed change history—the list can be quite long. And yet, these systems support “core business functions and are indispensable to the business.” What to do?
The only reasonable answer may be: Do nothing, at least until the legacy system must undergo some significant change. If the legacy software meets the needs of its users and runs reliably, it isn‟t broken and does not need to be fixed.
However, as time passes, legacy systems often evolve for one or more of the following reasons:
• The software must be adapted to meet the needs of new computing environments or technology.
• The software must be enhanced to implement new business requirements.
Software Engineering Unit I Page 6 • The software must be re-architected to make it viable within a evolving computing environment.
1.2 THE CHANGING NATURE OF SOFTWARE
1.2.1WebApps
In the early days of the World Wide Web (circa 1990 to 1995), websites consisted of little more than a set of linked hypertext files that presented information using text and limited graphics. As time passed, the augmentation of HTML by development tools (e.g., XML, Java) enabled Web engineers to provide computing capability along with informational content. Web-based systems and applications ( WebApps) were born. Today, WebApps have evolved into sophisticated computing tools that not only provide stand-alone function to the end user, but also have been integrated with corporate databases and business applications.
1.2.2 Mobile Applications
Reside on mobile platforms such as cell phones or tablets
Contain user interfaces that take both device characteristics and location attrtibutes Often provide access to a combination of web-based resources and local device
processing and storage capabilities
Provide persistent storage capabilities within the platform
1.2.3 Cloud Computing
Provide distributed data storage and processing resources to networked computing devices
Frontend services include the client devices and application software to allow access Backend services include servers, data storage, and server-resident applications Cloud architectures can be segmented to restrict access to private data
1.2.4 Product Line Software
Set of software-intensive systems that share a common set of features and satisfy the needs of a particular market
Software Engineering Unit I Page 7 1.3 DEFINING THE DISCIPLINE
Software Engineering :
(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
(2) The study of approaches as in (1).
Software engineering is a layered technology as shown in figure 2.1.
Any engineering approach must rest on an organizational commitment to quality. Total quality management, Six Sigma, and similar philosophies foster a continuous process improvement culture, and it is this culture that ultimately leads to the development of increasingly more effective approaches to software engineering. The bedrock that supports software engineering is a quality focus.
Software Engineering Unit I Page 8 a framework that must be established for effective delivery of software engineering technology.
Software engineering methods provide the technical how-to‟s for building software. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support. Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques.
Software engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.
1.4 THE SOFTWARE PROCESS
A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which software engineering is to be applied. An action (e.g., architectural design) encompasses a set of tasks that produce a major work product (e.g., an architectural model). A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.
1.4.1 The Process Framework
A process framework establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. In addition, the process framework encompasses a set of umbrella activities that are applicable across the entire software process. A generic process framework for
software engineering encompasses five activities:
Communication. Before any technical work can commence, it is critically important to communicate and collaborate with the customer (and other stakeholders). The intent is to understand stakeholders‟ objectives for the project and to gather requirements that help define software features and functions. Planning. Any complicated journey can be simplified if a map exists. The map—called a software project plan—defines the software engineering work by describing the technical tasks to be conducted, the risks that are likely, the resources that will be required, the
work products to be produced, and a work schedule.
Software Engineering Unit I Page 9 carpenter, or an architect, you work with models every day. You create a “sketch” of the thing so that you‟ll understand the big picture—what it will look like architecturally, how the constituent parts fit together, and many other characteristics. A software engineer does the same thing by creating models to better understand software requirements and the design that will achieve those requirements. Construction. What you design must be built. This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code.
Deployment. The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation.
1.2.2 Umbrella Activities
Software engineering process framework activities are complemented by a number of umbrella activities. In general, umbrella activities are applied throughout a software project and help a software team manage and control progress, quality, change, and risk. Typical umbrella activities include: Software project tracking and control—allows the software team to assess progress against the project plan and take any necessary action to maintain the schedule.
Risk management—assesses risks that may affect the outcome of the project or the quality of the product.
Software quality assurance—defines and conducts the activities required to ensure software quality.
Technical reviews—assess software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity. Measurement—defines and collects process, project, and product measures that assist the team in delivering software that meets stakeholders‟ needs; can be used in conjunction with all other framework and umbrella activities. Software configuration management—manages the effects of change throughout the software process.
Reusability management—defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components.
Software Engineering Unit I Page 10 1.4.3 Process Adaptation
a process adopted for one project might be significantly different than a process adopted for another project.
Among the differences are
• Overall flow of activities, actions, and tasks and the interdependencies among them. • Degree to which actions and tasks are defined within each framework activity. • Degree to which work products are identified and required.
• Manner in which quality assurance activities are applied.
• Manner in which project tracking and control activities are applied. • Overall degree of detail and rigor with which the process is described.
• Degree to which the customer and other stakeholders are involved with the project. • Level of autonomy given to the software team.
• Degree to which team organization and roles are prescribed.
1.5 SOFTWARE ENGINEERING PRACTICE
A generic software process model composed of a set of activities that establish a framework for software engineering practice. Generic framework activities— communication, planning, modeling, construction, and deployment—and umbrella activities establish a skeleton architecture for software engineering work.
1.5.1 The Essence of Practice
In the classic book, How to Solve It, written before modern computers existed, George Polya [Pol45] outlined the essence of problem solving, and consequently, the essence of software engineering practice:
1. Understand the problem (communication and analysis). 2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance)
Understand the problem. It‟s sometimes difficult to admit, but most of us suffer from hubris when we‟re presented with a problem. Understanding isn‟t always that easy. It‟s worth spending a little time answering a few simple questions:
• Who has a stake in the solution to the problem? That is, who are the stakeholders? • What are the unknowns? What data, functions, and features are required to properly solve the problem?
Software Engineering Unit I Page 11 • Can the problem be represented graphically? Can an analysis model be created?
Plan the solution. Now you understand the problem (or so you think), and you can‟t wait to begin coding. Before you do, slow down just a bit and do a little design:
• Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required?
• Has a similar problem been solved? If so, are elements of the solution reusable? • Can subproblems be defined? If so, are solutions readily apparent for the subproblems? • Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?
Carry out the plan. The design you‟ve created serves as a road map for the system you want to build. There may be unexpected detours, and it‟s possible that you‟ll discover an even better route as you go, but the “plan” will allow you to proceed without getting lost.
• Does the solution conform to the plan? Is source code traceable to the design model? • Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to the algorithm?
Examine the result. You can‟t be sure that your solution is perfect, but you can be sure that you‟ve designed a sufficient number of tests to uncover as many errors as possible.
• Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented?
• Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements?
1.5.2 General Principles
The dictionary defines the word principle as “an important underlying law or assumption required in a system of thought.” Regardless of their level of focus, principles help you establish a mind-set for solid software engineering practice. They are important for that reason.
David Hooker [Hoo96] has proposed seven principles that focus on software engineering practice as a whole. They are reproduced in the following paragraphs:
The First Principle: The Reason It All Exists
Software Engineering Unit I Page 12 before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: “Does this add real value to the system?” If the answer is no, don‟t do it. All other principles support this one.
The Second Principle: KISS (Keep It Simple, Stupid!)
Software design is not a haphazard process. There are many factors to consider in any design effort. All design should be as simple as possible, but no simpler. This facilitates having a more easily understood and easily maintained system. This is not to say that features, even internal features, should be discarded in the name of simplicity.
The Third Principle: Maintain the Vision
A clear vision is essential to the success of a software project. Without one, a project almost unfailingly ends up being “of two [or more] minds” about itself. Without conceptual integrity, a system threatens to become a patchwork of incompatible designs, held together by the wrong kind of screws . . .
The Fourth Principle: What You Produce, Others Will Consume
Seldom is an industrial-strength software system constructed and used in a vacuum. In some way or other, someone else will use, maintain, document, or otherwise depend on being able to understand your system. So, always specify, design, and implement knowing someone else will have to understand what you are doing.
The Fifth Principle: Be Open to the Future
A system with a long lifetime has more value. In today's computing environments, where specifications change on a moment‟s notice and hardware platforms are obsolete just a few months old, software lifetimes are typically measured in months instead of years. However, true “industrial-strength” software systems must endure far longer. To do this successfully, these systems must be
ready to adapt to these and other changes.
The Sixth Principle: Plan Ahead for Reuse
Software Engineering Unit I Page 13 This last Principle is probably the most overlooked. Placing clear, complete thought before action almost always produces better results. When you think about something, you are more likely to do it right. You also gain knowledge about how to do it right again. If you do think about something and still do it wrong, it becomes a valuable experience.
1.6 SOFTWARE DEVELOPMENT MYTHS
Software development myths—erroneous beliefs about software and the process that is used to build it—can be traced to the earliest days of computing. Myths have a number of attributes that make them insidious. For instance, they appear to be reasonable statements of fact (sometimes containing elements of truth), they have an intuitive feel, and they are often promulgated by experienced practitioners who “know the score.
Management myths. Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and 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 (even temporarily).
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 adaptable? 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.
Myth: If we get behind schedule, we can add more programmers and catch up (sometimes called the “Mongolian horde” concept).
Reality:
Software development is not a mechanistic process like manufacturing. 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.
Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm build it.
Reality:
Software Engineering Unit I Page 14 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, or 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.
Myth: A general statement of objectives is sufficient to begin writing programs—we can fill in the details later.
Reality: Although a comprehensive and stable statement of requirements is not always possible, an ambiguous “statement of objectives” is a recipe for disaster. Unambiguous requirements (usually derived iteratively) are developed only through effective and continuous communication between customer and developer.
Myth:
Software 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. When requirements changes are requested early (before design or code has been started), the cost impact is relatively small.
Practitioner’s myths. Myths that are still believed by software practitioners have been fostered by over 60 years of programming culture. During the early days, programming was viewed as an art form. Old ways and attitudes die hard.
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 between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.
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 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.
Myth: The only deliverable work product for a successful project is the working program.
Software Engineering Unit I Page 15 documents, plans) provide a foundation for successful engineering and, more important, guidance for software support.
Myth: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.
