Polytechnic University of the Philippines

College of Computer and Information Sciences

SOFTWARE ENGINEERING
DAY 2 – CONTINUATION TO INTRODUCTION TO SOFTWARE; INTRODUCTION TO SOFTWARE ENGINEERING

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 or operates inside a mainframe computer,
software is an information transformer – producing, managing, acquiring, modifying, displaying, or transmitting information
that can be as simple as a single bit or as complex as a multimedia presentation derived from data acquired from dozens
of independent sources. 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 delivers the most important product of our time—information. It transforms personal data (e.g., an individual’s
financial transactions) so that the data can be more useful in a local context; it manages business information to enhance
competitiveness; it provides a gateway to worldwide information networks (e.g., the Internet), and provides the means for
acquiring information in all of its forms.

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

CHARACTERISTICS OF SOFTWARE

Software has characteristics that are considerably different than those of hardware:

1. Software is developed or engineered; it is not manufactured in the classical sense.

Although some similarities exist between software development and hardware manufacturing, the two activities
are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing
phase for hardware can introduce quality problems that are nonexistent (or easily corrected) for software. Both
activities are dependent on people, but the relationship between people applied and work accomplished is entirely
different. Both activities require the construction of a “product,” but the approaches are different. Software costs
are concentrated in engineering. This means that software projects cannot be managed as if they were
manufacturing projects.

2. Software doesn’t “wear out.”

Figure 1.1 Failure curve for hardware Figure 1.2 Failure curves for software

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!

This seeming contradiction can best be explained by considering the actual curve in Figure 1.2. During its life,
software will undergo change. As changes are made, it is likely that errors will be introduced, causing the failure
rate curve to spike as shown in the “actual curve” (Figure 1.2). Before the curve can return to the original steady-
state failure rate, another change is requested, causing the curve to spike again. Slowly, the minimum failure rate
level begins to rise—the software is deteriorating due to change.

Another aspect of wear illustrates the difference between hardware and software. When a hardware component
wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an
error in design or in the process through which design was translated into machine executable code. Therefore,
the software maintenance tasks that accommodate requests for change involve considerably more complexity
than hardware maintenance.

3. Although the industry is moving toward component-based construction, most software continues to be
custom built.

As an engineering discipline evolves, a collection of standard design components is created. Standard screws
and off-the-shelf integrated circuits are only two of thousands of standard components that are used by
mechanical and electrical engineers as they design new systems. The reusable components have been created
so that the engineer can concentrate on the truly innovative elements of a design, that is, the parts of the design
that represent something new. In the hardware world, component reuse is a natural part of the engineering
process. In the software world, it is something that has only begun to be achieved on a broad scale.

A software component should be designed and implemented so that it can be reused in many different programs.
Modern reusable components encapsulate both data and the processing that is applied to the data, enabling the
software engineer to create new applications from reusable parts. For example, today’s interactive user interfaces
are built with reusable components that enable the creation of graphics windows, pull-down menus, and a wide
variety of interaction mechanisms. The data structures and processing detail required to build the interface are
contained within a library of reusable components for interface construction.

ATTRIBUTES OF QUALITY SOFTWARE

A software product can be judged by what it offers and how well it can be used. This software must satisfy on the
following grounds:

 Operational
 Transitional
 Maintenance

Well-engineered and crafted software is expected to have the following characteristics:

1. Operational
This tells us how software works in operations. It can be measured on:
o Budget
o Usability
o Efficiency
o Correctness
o Functionality
o Dependability
o Security
o Safety
 2. Transitional
This aspect is important when the software is moved from one platform to another:
o Portability
o Interoperability
o Reusability
o Adaptability

3. Maintenance
This aspect briefs about how well software has the capabilities to maintain itself in the ever-changing
environment:
o Modularity
o Maintainability
o Flexibility
o Scalability

SOFTWARE DEVELOPMENT MYTHS

Pressman (1997) describes a number of common beliefs or myths that software managers, customers, and developers
believe falsely. He describes these myths as “misleading attitudes that have caused serious problems.” We look at these
myths to see why they are false, and why they lead to trouble.

1. Software Management Myths. Pressman describes managers’ beliefs in the following mythology as grasping at
straws:
a. Development problems can be solved by developing and documenting standards.
Standards have been developed by companies and standard organizations. They can be very useful.
However, they are frequently ignored by developers because they are irrelevant and incomplete, and
sometimes incomprehensible.
b. Development problems can be solved by using state-of-the art tools.
Tools may help, but there is no magic. Problem solving requires more than tools, it requires great
understanding. As Fred Brooks (1987) says, there is no silver bullet to slay the software development
werewolf.
c. When schedules slip, just add more people.
This solution seems intuitive: if there is too much work for the current team, just enlarge it. Unfortunately,
increasing the team size increases communication overhead. New workers must learn project details
taking up the time of those who are already immersed in the project. Also, a larger team has many more
communication links, which slows progress. Fred Brooks (1975) gives us one of the famous software
engineering maxims, which is not a myth, “adding people to a late project makes it later.”

2. Software Customer Myths. Customers often vastly underestimate the difficulty of developing software.
Sometimes marketing people encourage customers in their misbeliefs.
a. Change is easily accommodated, since software is malleable.
Software can certainly be changed, but often changes after release can require an enormous amount of
labor.
b. A general statement of need is sufficient to start coding.
For developers to have a chance to satisfy the customers’ requirements, they need detailed descriptions
of the requirements. Developers cannot read the minds of customers.
 3. Developer Myths.
a. The job is done when the code is delivered.
Commercially successful software may be used for decades. Developers must continually maintain such
software: they add features and repair bugs. Maintenance costs predominate over all other costs;
maintenance may be 70% of the development costs. This myth is true only for shelfware – software that
is never used, and there are no customers for next release of a shelfware product.
b. Project success depends solely on the quality of the delivered program.
Documentation and software configuration information is very important to the quality. Developers must
maintain the software and they need good design documents, test data, etc. to do their job.
c. You can’t assess software quality until the program is running.
There are static ways to evaluate quality without running a program. Software reviews can effectively
determine the quality of requirement documents, design documents, test plans, and code. Formal
(mathematical) analyses are often used to verify safety critical software, software security factors, and
very-high reliability software.

INTRODUCTION TO SOFTWARE ENGINEERING

SOFTWARE ENGINEERING – an engineering branch associated with the development of software product using well-
defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and reliable
software product.

IEEE defines software engineering as:

“The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of
software.”

HISTORY OF SOFTWARE ENGINEERING

1968 - The term 'software engineering' was suggested at conferences organized by NATO to discuss the 'software crisis'.

SOFTWARE CRISIS - name given to the difficulties encountered in developing large, complex systems in the 1960s. It
was proposed that the adoption of an engineering approach to software development would reduce the costs of software
development and lead to more reliable software.

LATE 1970s - Early use of software design methods such as Yourdon and Constantine's structured design. Development
of first programming environments.

EARLY 1980s - Development of the Ada programming language which included notions of structured programming and
information hiding. Proposals for software engineering environments. CASE tools introduced to support design methods.
Development of algorithmic approaches to software costing and estimation. Publication of the 1st edition of this book as
the first student textbook on software engineering.

GENERIC PHASES OF SOFTWARE ENGINEERING

Initiation phase: Definition phase: Design phase:

Idea What? How

Maintenance phase: Implementation phase: Development phase:

Follow-up Implementation How to implement?

1. Initiation Phase
This is the beginning of the project. In this phase, the idea for the project is explored and elaborated. The goal of
this phase is to examine the feasibility of the project. In addition, decisions are made concerning who is to carry
out the project, which party (or parties) will be involved and whether the project has an adequate base of support
among those who are involved.
 Questions to be answered in the initiation phase include the following:
o Why this project?
o Is it feasible?
o Who are possible partners in this project?
o What should the results be?
o What are the scopes and limitations of this project?

2. Definition Phase
In this phase, the requirements that are associated with a project result are specified as clearly as possible. This
involves identifying the expectations that all of the involved parties have with regard to the project result.

3. Design Phase
In this phase, one or more designs are developed, with which the project result can apparently be achieved.
Depending on the subject of the project, the products of the design phase can include dioramas, sketches, flow
charts, site trees, HTML screen designs, prototypes, photo impressions and UML schemas.

4. Development Phase
In this phase, everything that will be needed to implement the project is arranged. This phase is complete when
implementation is ready to start.

5. Implementation Phase
This phase involves the construction of the actual project result. Programmers are occupied with encoding,
designers are involved in developing graphic material, the actual reorganization takes place. It is during this
phase that the project becomes visible to outsiders, to whom it may appear that the project has just begun. The
implementation phase is the doing phase, and it is important to maintain the momentum.

At the end of the implementation phase, the result is evaluated according to the list of requirements that was
created in the definition phase. It is also evaluated according to the designs. For example, tests may be
conducted to determine whether the web application does indeed support Explorer 5 and Firefox 1.0 and higher.

6. Maintenance Phase
Although it is extremely important, this phase is often neglected. During this phase, everything is arranged that is
necessary to bring the project to a successful completion.

ASSIGNMENT: Research what are the different software process models.