Lesson 1: Introduction to Software Engineering

Contents
1.0.Aims and Objectives
1.1.Introduction
1.2.Definition
1.3.Size Factors
1.4.Quality and Production Factors
1.5.Managerial Issues
1.6.Review Questions
1.7.Let us Sum up
1.8. Lesson end Activities
1.9. Points for Discussion
1.10. References

1.0. AIMS AND OBJECTIVES

• To understand the meaning of software engineering

• To understand the principles of Software Engineering
• To understand the quality and productivity factors of SE
• To understand the various managerial issues in SE

1.1. INTRODUCTION

Computers find applications in a wide variety of fields ranging from rail

ticket reservation systems to medical diagnosis systems. Hence it is necessary
for any computer to work on a wide spectrum of software.
Software is not merely a collection of computer programs. There is a thin
difference between software and program. A program consists of a set of
instructions that a computer follows to perform a task and is complete in it. It
is generally used only by the author of the program and has little or no
documentation. It is difficult for others to use the program, modify it, or debug
it. An example may be a program in C language to arrange a list of names in
ascending order.
On the other hand, software is a collection of programs and is developed
for widespread use. Hence it is expected to be very user friendly. It contains
comprehensive documentation, which enables it to be used by people other
than the developers also. The documentation also enables customization, i.e.,
modification of the software to suit specific applications by third party
programmers.

7
 In the initial stages of software development, the software was
unmanaged and little attention was paid to systematic methods for its creation,
until delays and costs began to go up. This necessitated the need for a
structured approach to programming, laying the way for software development
within a planned framework.
Software creation has accelerated in the recent past as evidenced by the
boom in software employment. Software has been created to automate most
aspects of every day life. But the software development has been to large extent
independent, raising questions of compatibility, quality, reusability, and
maintainability. Schedule and cost increases, poorly defined customer
requirements, poor quality of software, little or sometimes no documentation for
the software developed are some of the few problems that led to a software
crisis (disaster). These problems have grown exponentially making it almost
impossible to manage the large volume of software available. These problems
have led to a new branch of study concerned with the development of formal
methods to address these problems, called Software Engineering.

1.2. DEFINITIONS

The IEEE glossary on software engineering terminology gives the

following definition for software:
Software Engineering is the application of a systematic,
disciplined, quantifiable approach to the development,
operation and maintenance of software, that is, the application
of engineering to software.
A systematic approach to the analysis, design, implementation and
maintenance of software. It often involves the use of CASE tools. There are
various models of the software life cycle and many methodologies for the
different phases.
It will be clear that the term software engineering involves many
difference issues - all are important to the success of large-scale software
development. Many authors define Software Engineering as:
Boehm [Boehm 1979]:
Software Engineering: The practical application of scientific knowledge in
the design and construction of computer programs and the associated
documentation required to develop, operate, and maintain them.
Dennis [Dennis 1975]:
Software engineering is the application of principles, skills, and art to the
design and construction of programs and systems of programs.
Parnas [Parnas 1974]:

8
 Software engineering is programming under at last one of the following
two conditions:
(1) More than one person is involved in the construction and/or use of
the programs
(2) More than one version of the program will be produced
Fairley [Fairley 1985]:
Software engineering is the technological and managerial discipline
concerned with the systematic production and maintenance of software
products that are developed and modified on time and within cost
estimates.
Sommerville [Sommerville 1989]:
Software Engineering is concerned with building software systems which
are large than would normally be tackled by a single individual, uses
engineering principles in the development of these systems and is made
up of both technical and non-technical aspects.
Pomberger and Blaschek [Pomberger 1996]:
Software engineering is the practical application of scientific knowledge
for the economical production and use of high-quality software.
1.2.1. Principle of Software Engineering
The basic principle of software Engineering is to use structured, formal and
disciplined methods for building and using systems, just as in any other branch
of engineering. Software Engineering is an attempt at providing the same, a set
of methods, a variety of tools, and a collection of procedures.

Methods provide the rules and steps for carrying out tasks. The tasks
are project-planning and estimation, system and software requirements
analysis, design of processes and data structures, algorithm and
program architecture, coding, testing and maintenance.

Tools provide automated or semi-automated support for methods. Tools
which automate the range of Software Engineering methods can be
integrated into one system called CASE (Computer Aided Software
Engineering) tools. CASE tools are available to support and automate
most of the software engineering methods.

Standard procedures bind the methods and tools into a framework.
They define the sequence in which methods will be applied and the
deliverables (documents, forms, reports, etc.) that are required. These
specify the controls that ensure quality, coordinate change, and the
milestones that help a manager assess progress.

9
Software Engineering provides certain models that encompass the above
methods, tools and procedures. The paradigm (theories and methodology) may
be viewed as models of software development.
Check your progress
I State whether true of false:
1. There is no difference between software engineering and programming.
2. Software engineering differs from classical engineering disciplines to
some extent.

II Choose the correct answer.

The concept of software engineering was born because:
a) People felt the need for more programmers.
b) Most software projects were over budget and behind schedule
c) Most development time was spent on rework.
d) B and C

1.3. SIZE FACTORS

Size-oriented software metrics are derived by normalizing quality and/or

productivity measures by considering the “size” of the software that has been
produced.
Examples:
• Direct measures - Errors per KLOC, Defects per KLOC, Cost per KLOC,
pages of documentation per KLOC.
• Indirect measures – Errors/person-month, LOC per person-month,
Cost/page of documentation
Advantages:
These measures are easy to use.
Disadvantage:
LOC is not universally accepted as a key measure because it is language
dependant and programmer dependant.

1.4. QUALITY AND PRODUCTIVITY FACTORS

The overriding goal of software engineering is to produce a high quality

system, application, or product. To achieve this goal, software engineers must
do the following:

10
1. Apply effective methods coupled with modern tools within the context of a
mature software process.
2. Measure in order to assess the quality of the process as well the product.
Measuring Quality
Although there are many measures of software quality, correctness,
maintainability, integrity, and usability provide useful indicators for the project
team.
a. Correctness: Correctness is the degree to which the software performs
its required function. Defects per KLOC, where a defect is defined as a
verified lack of conformance to requirements.
b. Maintainability: Maintainability is the ease with which a program can
be corrected if an error is encountered, adapted if its environment
changes, or enhanced if the customer desires a change in requirements.
There is no direct measure for software maintenance. Hence indirect
measures have to be used. A simple time-oriented metric known as a
Mean-Time-To-Change (MTTC) is the time it takes to analyze a change
request, design an appropriate modification, implement the change, test
it, and distribute the change to all the users.
c. Integrity: Integrity measures a system’s ability to withstand attacks on
its security. Attacks can be made on programs, data, and documents. To
measure integrity, two additional attributes must be defined: threat and
security. Threat is the probability that an attack of a specific type will
occur within a given time. Security is the probability that the attack of a
specific type will be repelled. The integrity of a system can be defined as:
Integrity = ∑ [1 – threat x ( 1 – security)]
d. Usability: Usability is an attempt to quantify “user friendliness” and can
be measured in terms of four characteristics: (1) the physical and/or
intellectual skill required to learn the system; (2) the time required to
become moderately efficient in the use of the system; (3) the net increase
in productivity measured when the system is used by someone who is
moderately efficient, and (4) a subjective assessment of users attitude
towards the system.
Defect Removal Efficiency (DRE)
A quality metric that provides benefit at both the project and process
level is Defect Removal Efficiency (DRE). DRE is a measure of the filtering
ability of quality assurance and control activities as they are applied throughout
all process framework activities.
DRE = E / (E + D)
Where E = number of errors found before delivery of the software to the end
user,

11
 D = number of defects found after delivery
The ideal value for DRE is 1. That is, no defects are found in the software.
Realistically, D will be greater than zero, but the value of DRE can still
approach 1 as E increases. In fact, as E increases, it is likely that the final
value of D will decrease. On the whole, DRE encourages a software project team
to institute techniques for finding as many errors as possible before delivery.
DRE can also be used within the project to assess a team’s ability to find errors
before they are passed to the next software engineering task. This is because
errors that are not found during a phase (e.g. Requirements Analysis) are
passed onto the subsequent stage (e.g. Design). When used in this context, DRE
can be redefined as:
DREi = Ei / (Ei + Ei + 1)
where,
Ei = number of errors found during software engineering activity i
Ei+1 = number of errors found during software engineering activity i + 1
that are traceable to errors that were not discovered in software
engineering activity i.
A quality objective for a software team (or an individual software engineer) is to
achieve DREi that approaches 1. That is, errors should be filtered out before
they are passed on to the next activity.
Measurement of software quality factors
Software Quality Factors cannot be measured because of their unclear
description. It is necessary to find measures, or metrics, which can be used to
quantify them as non-functional requirements
For example, reliability is a software quality factor, but cannot be
evaluated in its own right. However there are related attributes to reliability,
which can indeed be measured. Such attributes are mean time to failure, rate of
failure occurrence, availability of the system. Similarly, an attribute of
portability is the number of target dependent statements in a program.
A scheme which could be used for evaluating software quality factors is
given below. For every characteristic, there are a set of questions which are
relevant to that characteristic. Some type of scoring formula could be developed
based on the answers to these questions, from which a measure of the
characteristic may be obtained.
• Understandibility: Are variable names descriptive of the physical or
functional property represented? Do uniquely recognisable functions
contain adequate comments so that their purpose is clear? Are
deviations from forward logical flow adequately commented? Are all
elements of an array functionally related?

12
 • Completeness: Does the program contain all referenced subprograms
not available in the usual systems library? Are all parameters required
by the program available? Are all inputs required by the program
available?
• Conciseness (short): Is all code reachable? Is any code redundant? How
many statements within loops could be placed outside the loop, thus
reducing computation time? Are branch decisions too complex?
• Portability (capable of being transferred): Does the program depend
upon system or library routines unique to a particular installation? Have
machine-dependent statements been flagged and commented? Has
dependency on internal bit representation of alphanumeric or special
characters been avoided?
• Consistency (stability): Is one variable name used to represent difficult
physical entities in the program? Does the program contain only one
representation for physical or mathematical constants? Are functionally
similar arithmetic expressions similarly constructed? Is a consistent
scheme for indentation used?
• Maintainability: Has some memory capacity been reserved for future
expansion? Is the design cohesive, i.e., each module has recognizable
functionality? Does the software allow for a change in data structures
(object-oriented designs are more likely to allow for this)? If a
functionally-based design (rather than object-oriented), is a change likely
to require restructuring the main-program, or just a module?
• Testability: Are complex structures employed in the code? Does the
detailed design contain clear pseudo-code? Is the pseudo-code at a
higher level of abstraction than the code? If tasking is used in concurrent
designs, are schemes available for providing adequate test cases?
• Usability: Is a GUI used? Is there adequate on-line help? Is a user
manual provided? Are meaningful error messages provided?
• Reliability: Are loop indexes range tested? Is input data checked for
range errors? Is divide-by-zero avoided? Is exception handling provided?
• Structuredness: Is a block-structured programming language used? Are
modules limited in size? Have the rules for transfer of control between
modules been established and followed?
• Efficiency: Have functions been optimized for speed? Have repeatedly
used blocks of code been formed into sub-routines?

1.5. MANAGERIAL ISSUES

Software engineering is an application of management activities such as:

• Planning,

13
 • Coordinating,
• Ensuring,
• Monitoring,
• Controlling and
• Reporting
to insure that the development of software is systematic, disciplined and
measured.
Software Engineering Measurement
1. Goals
1. Organizational objectives
2. Software process improvement goals
2. Measurement selection
1. Goal-driven measurement selection
2. Measurement validity
3. Measuring software and its development
1. Size measurement
2. Structure measurement
3. Resource measurement
4. Quality measurement
4. Collection of data
1. Survey techniques and form design
2. Automated and manual data collection
5. Software measurement models
1. Model building, calibration and evaluation
2. Implementation, interpretation and refinement of models
Software Project Management
• Communication:
• Rationale management:
o The problem
o the alternatives considered
o the criteria used to evaluate the alternatives

14
 o the debate
o the decision
• Testing: find differences between the system and its models by executing
the system with sample input data sets.
o Unit testing: object design compared with object and subsystem.
o Integration testing: combinations of subsystems are integrated
and compared with the system design model.
o System testing: typical and exceptional cases are compared with
the requirements model
o Acceptance testing
• Software configuration management: establishes baseline, monitors and
controls changes in work products, versions.
• Project management: oversight activities that insure the delivery of a
high-quality system on time and within budget including
o planning and budgeting
o hiring and organizing developers into teams
o monitoring project status
o intervening when deviation occur
• Software life cycle modeling activities
Since quantitative methods have proved so powerful in the other sciences,
computer science practitioners and theoreticians have worked hard to bring
similar approaches to software development
Software metrics are numerical data related to software development.
Metrics strongly support software project management activities. They relate to
the four functions of management as follows:
1. Planning - Metrics serve as a basis of cost estimating, training planning,
and resource planning, scheduling, and budgeting.
2. Organizing - Size and schedule metrics influence a project's
organization.
3. Controlling - Metrics are used to status and track software development
activities for compliance to plans.
4. Improving - Metrics are used as a tool for process improvement and to
identify where improvement efforts should be concentrated and measure
the effects of process improvement efforts.
A metric quantifies a characteristic of a process or product. Metrics can be
directly observable quantities or can be derived from one or more directly

15
observable quantities. Examples of raw metrics include the number of source
lines of code, number of documentation pages, number of staff-hours, number
of tests, number of requirements, etc. Examples of derived metrics include
source lines of code per staff-hour, defects per thousand lines of code, or a cost
performance index.

1.6. REVIEW QUESTIONS

1. What are the different software paradigms available? Can we combine the
paradigms? Explain.
2. What are the objectives of Software Engineering?
3. Explain the evolving role of software.
4. Give a generic view of Software Engineering.
5. What is software re-engineering? Explain it.
6. Explain Software crises and software myths.
7. What is software reuse? Explain.
8. Define Software Engineering. List out is components.
9. Discuss the fundamental activities, which are common to all software
processes.

1.7. LET US SUM UP

This Lesson covered the following:

• The early unplanned approaches to software development and how their
inadequacy in face of increased sophisticated led to the software crises
• The realization of the need for a more structured and organized way of
building software, leading to the birth of Software Engineering.
• Definition of Software Engineering
• Software Engineering methods, tools and procedures
1.8. LESSON END ACTIVITIES
i. Interview programmer and managers in the organization of your choice to
determine management problem areas.
ii. How do the perceptions of managers and programmers differ?
1.9. POINTS FOR DISCUSSION
i. Which is more important the product or process? Justify your answer

16
ii. Identify the umbrella activities in software engineering process.

1.10. REFERENCES
1. Richard Fairley, “Software Engineering Concepts”, Tata McGraw-Hill, 1997.
2. Roger S.Pressman, Software engineering- A practitioner’s Approach,
McGraw-Hill International Edition, 5th edition, 2001.

17
18