INTRODUCTION TO SOFTWARE ENGINEERING

For more www.ThesisScientist.com
UNIT 1
INTRODUCTION TO SOFTWARE ENGINEERING
Software Engineering is the set of processes and tools to develop software. Software
Engineering is the combination of all the tools, techniques, and processes that used in
software production. Therefore Software Engineering encompasses all those things that
are used in software production like :
 Programming Language
 Programming Language Design
 Software Design Techniques
 Tools
 Testing
 Maintenance
 Development etc.
These days object-oriented programming is widely being used. If programming
languages will not support object-orientation then it will be very difficult to implement
object-oriented design using object-oriented principles. All these efforts made the basis
of software engineering.
Well-Engineered Software
Well-engineered software is one that has the following characteristics.
 It is reliable
 It has good user-interface
 It has acceptable performance
 It is of good quality
 It is cost-effective
Every company can build software with unlimited resources but well-engineered software
is one that conforms to all characteristics listed above.

Software has very close relationship with economics. When ever we talk about
engineering systems we always first analyze whether this is economically feasible or not.
Therefore you have to engineer all the activities of software development while keeping
its economical feasibility intact.
The major challenges for a software engineer is that he has to build software within
limited time and budget in a cost-effective way and with good quality Therefore well-
engineered software has the following characteristics.
 Provides the required functionality
 Maintainable
 Reliable
 Efficient
 User-friendly
 Cost-effective
But most of the times software engineers ends up in conflict among all these goals. It is
also a big challenge for a software engineer to resolve all these conflicts.
The Balancing Act!
Software Engineering is actually the balancing act. You have to balance many things like
cost, user friendliness, Efficiency, Reliability etc. You have to analyze which one is the
more important feature for your software is it reliability, efficiency, user friendliness or
something else.
There is always a trade-off among all these requirements of software. It may be the case
that if you try to make it more user-friendly then the efficiency may suffer. And if you try
to make it more cost-effective then reliability may suffer. Therefore there is always a
trade-off between these characteristics of software.
These requirements may be conflicting. For example, there may be tension among the
following :
 Cost vs. Efficiency
 Cost vs. Reliability

 Efficiency vs. User-interface
A Software Engineer is required to analyze these conflicting entities and tries to strike a
balance.
Challenge is to balance these requirements .
Software Engineers always confront with the challenge to make a good balance of all
these tings depending on the requirements of the particular software system at hand. He
should analyze how much weight should all these things get such that it will have
acceptable quality, acceptable performance and will have acceptable user-interface.
In some software the efficiency is more important and desirable.
For example if we talk about a cruise missile or a nuclear reactor controller that are
droved by the software systems then performance and reliability is far more important
than the cost-effectiveness and user-friendliness. In these cases if your software does not
react within a certain amount of time then it may result in the disaster like Chernobyl
accident. Therefore software development is a process of balancing among different
characteristics of software described in the previous section. And it is an art to come up
with such a good balance and that art can be learned from experience.
Law of diminishing returns
In order to understand this concept lets take a look at an example. Most of you have
noticed that if you dissolve sugar in a glass of water then the sweetness of water will
ncrease gradually. But at a certain level of saturation no more sugar will dissolved into
water. Therefore at that point of saturation the sweetness of water will not increase even
if you add more sugar into it.
The law of diminishing act describes the same phenomenon. Similar is the case with
software engineering. Whenever you perform any task like improving the efficiency of
the system, try to improve its quality or user friendliness then all these things involves an
element of cost. If the quality of your system is not acceptable then with the investment
of little money it could be improved to a higher degree. But after reaching at a certain

level of quality the return on investment on the system’s quality will become reduced.
Meaning that the return on investment on quality of software will be less than the effort
or money we invest. Therefore, in most of the cases, after reaching at a reasonable level
of quality we do not try to improve the quality of software any further. This phenomenon
is shown in the figure below.
Benefit
Software Background
Caper Jones a renounced practitioner and researcher in the filed of Software Engineering,
had made immense research in software team productivity, software quality, software
cost factors and other fields relate to software engineering. He made a company named
Software Productivity Research in which they analyzed many projects and published the
results in the form of books. Let’s look at the summary of these results.
He divided software related activities into about twenty-five different categories listed in
the table below. They have analyzed around 10000 software projects to come up with
such a categorization. But here to cut down the discussion we will only describe nine of
them that are listed below.
 Project Management
 Requirement Engineering

 Design
 Coding
 Testing
 Software Quality Assurance
 Software Configuration Management
 Software Integration and
 Rest of the activities
One thing to note here is that you cannot say that anyone of these activities is dominant
among others in terms of effort putted into it. Here the point that we want to emphasize is
that, though coding is very important but it is not more than 13-14% of the whole effort
of software development.
So, according to Fred Brook, in the eye of an unsophisticated manager software is like a
giant. Sometimes it reveals as an unscheduled delay and sometimes it shows up in the
form of cost overrun. To kill this giant the managers look for magical solutions. But
unfortunately magic is not a reality. We do not have any magic to defeat this giant. There
is only one solution and that is to follow a disciplined approach to build software. We
can defeat the giant named software by using disciplined and engineered approach
towards software development.
Therefore, Software Engineering is nothing but a disciplined and systematic approach to
software development.
Now we will look at some of the activities involved in the course of software
development. The activities involved in software development can broadly be divided
into two major categories first is constriction and second is management.
Software Development
The construction activities are those that are directly related to the construction or
development of the software. While the management activities are those that complement
the process of construction in order to perform construction activities smoothly and

effectively. A greater detail of the activities involved in the construction and management
categories is presented below.
Construction
The construction activities are those that directly related to the development of software,
e.g. gathering the requirements of the software, develop design, implement and test the
software etc. Some of the major construction activities are listed below.
 Requirement Gathering
 Design Development
 Coding
 Testing
Management
Management activities are kind of umbrella activities that are used to smoothly and
successfully perform the construction activities e.g. project planning, software quality
assurance etc. Some of the major management activities are listed below.
 Project Planning and Management
 Configuration Management
 Software Quality Assurance
 Installation and Training

•
•
•
•
Project Plaining and
Management
Configuration Management
Quality Assurance
Installation and Training
Management
Construction
• Requirements
• Design
• Coding
• Testing
• Maintenance
Figure1
Development Activities
As we have said earlier that management activities are kind of umbrella activities that
surround the construction activities so that the construction process may proceed
smoothly. This fact is empathized in the Figure1. The figure shows that construction is
surrounded by management activities. That is, certain processes and rules govern all
construction activities. These processes and rules are related to the management of the
construction activities and not the construction itself.
A Software Engineering Framework
The software development organization must have special focus on quality while
performing the software engineering activities. Based on this commitment to quality by
the organization, a software engineering framework is proposed that is shown in Figure 2.
The major components of this framework are described below.

Quality Focus :
As we have said earlier, the given framework is based on the organizational commitment
to quality. The quality focus demands that processes be defined for rational and timely
development of software. And quality should be emphasized while executing these
processes.
Processes :
The processes are set of key process areas (KPAs) for effectively manage and deliver
quality software in a cost effective manner. The processes define the tasks to be
performed and the order in which they are to be performed. Every task has some
deliverables and every deliverable should be delivered at a particular milestone.
Methods :
Methods provide the technical ―how-to’s‖ to carryout these tasks. There could be more
than one technique to perform a task and different techniques could be used in different
situations.
Tools :
Tools provide automated or semi-automated support for software processes, methods, and
quality control.
Method
Process
Quality Focus
Task Set
T
O
O
L
S
Figure 2
Software Engineering Framework
Software Development Loop

Let’s now look at software engineering activities from a different perspective. Software
development activities could be performed in a cyclic and that cycle is called software
development loop which is shown in Figure3. The major stages of software development
loop are described below.
Problem Definition :
In this stage we determine what is the problem against which we are going to develop
software. Here we try to completely comprehend the issues and requirements of the
software system to build.
Technical Development :
In this stage we try to find the solution of the problem on technical grounds and base our
actual implementation on it. This is the stage where a new system is actually developed
that solves the problem defined in the first stage.
Solution Integration :
If there are already developed system(s) available with which our new system has to
interact then those systems should also be the part of our new system. All those existing
system(s) integrate with our new system at this stage.
Status Quo :
After going through the previous three stages successfully, when we actually deployed
the new system at the user site then that situation is called status quo. But once we get
new requirements then we need to change the status quo.
After getting new requirements we perform all the steps in the software development
loop again. The software developed through this process has the property that this could
be evolved and integrated easily with the existing systems.

Problem
Definition
Technical
Development
Solution
Integration
Status Quo
Figure3
Software Development Loop
Software Process
A software process is a road map that helps you create a timely, high quality result. It is
the way we produce software and it provides stability and control. Each process defines
certain deliverables known as the work products. These include programs, documents,
and data produced as a consequence of the software engineering activities.
Process Maturity and CMM
The Software Engineering Institute (SEI) has developed a framework to judge the process
maturity level of an organization. This framework is known as the Capability Maturity
Model (CMM). This framework has 5 different levels and an organization is placed into
one of these 5 levels. The following figure shows the CMM framework.
These levels are briefly described as follows‖
1. Level 1 – Initial: The software process is characterized as ad hoc and occasionally
even chaotic. Few processes are defined, and success depends upon individual
effort. By default every organization would be at level 1.

2. Level 2 – Repeatable: Basic project management processes are established to
track cost, schedule, and functionality. The necessary project discipline is in place
to repeat earlier successes on projects with similar applications.
3. Level 3 – Defined : The software process for both management and engineering
activities is documented, standardized, and integrated into an organizational
software process. All projects use a documented and approved version of the
organization’s process for developing and supporting software.
4. Level 4 – Managed: Detailed measures for software process and product quality
are controlled. Both the software process and products are quantitatively
understood and controlled using detailed measures.
5. Level 5 – Optimizing: Continuous process improvement is enabled by qualitative
feedback from the process and from testing innovative ideas and technologies.
SEI has associated key process areas with each maturity level. The KPAs describe those
software engineering functions that must be present to satisfy good practice at a particular
level. Each KPA is described by identifying the following characteristics :
1. Goals: the overall objectives that the KPA must achieve.
2. Commitments: requirements imposed on the organization that must be met to
achieve the goals or provide proof of intent to comply with the goals.
3. Abilities: those things that must be in place – organizationally and technically – to
enable the organization to meet the commitments.
4. Activities: the specific tasks required to achieve the KPA function
5. Methods for monitoring implementation: the manner in which the activities are
monitored as they are put into place.
6. Methods for verifying implementation: the manner in which proper practice for
the KPA can be verified.

Each of the KPA is defined by a set of practices that contribute to satisfying its goals. The
key practices are policies, procedures, and activities that must occur before a key process
area has been fully instituted.
The following table summarizes the KPAs defined for each level.
Level KPAs
1 No KPA is defined as organizations at this level follow ad-hoc processes
2 • Software Configuration Management
• Software Quality Assurance
• Software subcontract Management
• Software project tracking and oversight
• Software project planning
• Requirement management
3 • Peer reviews
• Inter-group coordination
• Software product Engineering
• Integrated software management
• Training program
• Organization process management
• Organization process focus
4 • Software quality management
• Quantitative process management
5 • Process change management
• Technology change management
• Defect prevention
Software Lifecycle Models
Recalling from our first course, a software system passes through the following phases:

1. Vision– focus on why
2. Definition– focus on what
3. Development– focus on how
4. Maintenance– focus on change
During these phases, a number of activities are performed. A lifecycle model is a series
of steps through which the product progresses. These include requirements phase,
specification phase, design phase, implementation phase, integration phase, maintenance
phase, and retirement. Software Development Lifecycle Models depict the way you
organize your activities
There are a number of Software Development Lifecycle Models, each having its
strengths and weaknesses and suitable in different situations and project types. The list
of models includes the following:
 Build-and-fix model
 Waterfall model
 Rapid prototyping model
 Incremental model
 Extreme programming
 Synchronize-and-stabilize model
 Spiral model
 Object-oriented life-cycle models
In the following sections we shall study these models in detail and discuss their strengths
and weaknesses.
Build and Fix Model
This model is depicted in the following diagram :

It is unfortunate that many products are developed using what is known as the build-and-
fix model. In this model the product is constructed without specification or any attempt at
design. The developers simply build a product that is reworked as many times as
necessary to satisfy the client. This model may work for small projects but is totally
unsatisfactory for products of any reasonable size. The cost of build-and fix is actually far
greater than the cost of properly specified and carefully designed product. Maintenance
of the product can be extremely in the absence of any documentation.
Waterfall Model
The first published model of the software development process was derived from other
engineering processes. Because of the cascade from one phase to another, this model is
known as the waterfall model. This model is also known as linear sequential model. This
model is depicted in the following diagram.

The principal stages of the model map directly onto fundamental development activities.
It suggests a systematic, sequential approach to software development that begins at the
system level and progresses through the analysis, design, coding, testing, and
maintenance .In the literature, people have identified from 5 to 8 stages of software
development.
The five stages above are as follows :
1. Requirement Analysis and Definition: What - The systems services, constraints
and goals are established by consultation with system users. They are then defined in
detail and serve as a system specification.
2. System and Software Design: How – The system design process partitions the
requirements to either hardware of software systems. It establishes and overall system
architecture. Software design involves fundamental system abstractions and their
relationships.

3. Implementation and Unit Testing: - How – During this stage the software
design is realized as a set of programs or program units. Unit testing involves verifying
that each unit meets its specifications.
4. Integration and system testing: The individual program unit or programs are
integrated and tested as a complete system to ensure that the software requirements have
been met. After testing, the software system is delivered to the customer.
5. Operation and Maintenance: Normally this is the longest phase of the software
life cycle. The system is installed and put into practical use. Maintenance involves
correcting errors which were not discovered in earlier stages of the life-cycle, improving
the implementation of system units and enhancing the system’s services as new
requirements are discovered.
In principle, the result of each phase is one or more documents which are approved. No
phase is complete until the documentation for that phase has been completed and
products of that phase have been approved. The following phase should not start until the
previous phase has finished.
Real projects rarely follow the sequential flow that the model proposes. In general these
phases overlap and feed information to each other. Hence there should be an element of
iteration and feedback. A mistake caught any stage should be referred back to the source
and all the subsequent stages need to be revisited and corresponding documents should be
updated accordingly. This feedback path is shown in the following diagram.

Because of the costs of producing and approving documents, iterations are costly and
require significant rework.
The Waterfall Model is a documentation-driven model. It therefore generates complete
and comprehensive documentation and hence makes the maintenance task much easier. It
however suffers from the fact that the client feedback is received when the product is
finally delivered and hence any errors in the requirement specification are not discovered
until the product is sent to the client after completion. This therefore has major time and
cost related consequences.
Rapid Prototyping Model
The Rapid Prototyping Model is used to overcome issues related to understanding and
capturing of user requirements. In this model a mock-up application is created ―rapidly‖
to solicit feedback from the user. Once the user requirements are captured in the
prototype to the satisfaction of the user, a proper requirement specification document is
developed and the product is developed from scratch.
An essential aspect of rapid prototype is embedded in the word ―rapid‖. The developer
should endeavour to construct the prototype as quickly as possible to speedup the
software development process. It must always be kept in mind that the sole purpose of the

rapid prototype is to capture the client’s needs; once this has been determined, the rapid
prototype is effectively discarded. For this reason, the internal structure of the rapid
prototype is not relevant.
Integrating the Waterfall and Rapid Prototyping Models
Despite the many successes of the waterfall model, it has a major drawback in that the
delivered product may not fulfil the client’s needs. One solution to this is to combine
rapid prototyping with the waterfall model. In this approach, rapid prototyping can be
used as a requirement gathering technique which would then be followed by the activities
performed in the waterfall model.
Incremental Models
As discussed above, the major drawbacks of the waterfall model are due to the fact that
the entire product is developed and delivered to the client in one package. This results in
delayed feedback from the client. Because of the long elapsed time, a huge 15 new
investment of time and money may be required to fix any errors of omission or
commission or to accommodate any new requirements cropping up during this period.
This may render the product as unusable. Incremental model may be used to overcome
these issues.
In the incremental models, as opposed to the waterfall model, the product is partitioned
into smaller pieces which are then built and delivered to the client in increments at
regular intervals. Since each piece is much smaller than the whole, it can be built and sent
to the client quickly. This results in quick feedback from the client and any requirement
related errors or changes can be incorporated at a much lesser cost. It is therefore less
traumatic as compared to the waterfall model. It also new investment of time and money
may be required to fix any errors of omission or commission or to accommodate any new
requirements cropping up during this period. This may render the product as unusable.

Incremental model may be used to overcome these issues. In the incremental models, as
opposed to the waterfall model, the product is partitioned into smaller pieces which are
then built and delivered to the client in increments at regular intervals. Since each piece is
much smaller than the whole, it can be built and sent to the client quickly. This results in
quick feedback from the client and any requirement related errors or changes can be
incorporated at a much lesser cost. It is therefore less traumatic as compared to the
waterfall model. It also required smaller capital outlay and yield a rapid return on
investment. However, this model needs and open architecture to allow integration of
subsequent builds to yield the bigger product. A number of variations are used in object-
oriented life cycle models.

There are two fundamental approaches to the incremental development. In the first case,
the requirements, specifications, and architectural design for the whole product are
completed before implementation of the various builds commences.
In a more risky version, once the user requirements have been elicited, the specifications
of the first build are drawn up. When this has been completed, the specification team
turns to the specification of the second build while the design team designs the first build.
Thus the various builds are constructed in parallel, with each team making use of the
information gained in the all the previous builds. This approach incurs the risk that the
resulting build will not fit together and hence requires careful monitoring.

Implementation,
integration
Deliver to clientDesignSpecification
Implementation,
integration
Implementation,
integration
Build 1
Implementation,
integration
Build 2
Build 3
Build n
Specification team
Design team
Implementation,
integration team
Rapid Application Development (RAD)
Rapid application development is another form of incremental model. It is a high speed
adaptation of the linear sequential model in which fully functional system in a very short
time (2-3 months). This model is only applicable in the projects where requirements are
well understood and project scope is constrained. Because of this reason it is used
primarily for information systems.

Synchronize and Stabilize Model
This is yet another form of incremental model adopted by Microsoft. In this model,
during the requirements analysis interviews of potential customers are conducted and
requirements document is developed. Once these requirements have been captured,
specifications are drawn up. The project is then divided into 3 or 4 builds. Each build is
carried out by small teams working in parallel. At the end of each day the code is
synchronized (test and debug) and at the end of the build it is stabilized by freezing the
build and removing any remaining defects. Because of the synchronizations, components
always work together. The presence of an executable provides early insights into
operation of product.
Spiral Model
This model was developed by Barry Boehm. The main idea of this model is to avert risk
as there is always an element of risk in development of software. For example, key
personnel may resign at a critical juncture, the manufacturer of the software development
may go bankrupt, etc.
In its simplified form, the Spiral Model is Waterfall model plus risk analysis. In this case
each stage is preceded by identification of alternatives and risk analysis and is then
followed by evaluation and planning for the next phase. If risks cannot be resolved,
project is immediately terminated. This is depicted in the following diagram.

As can be seen, a Spiral Model has two dimensions. Radial dimension represents the
cumulative cost to date and the angular dimension represents the progress through the
spiral. Each phase begins by determining objectives of that phase and at each phase a new
process model may be followed.
A full version of the Spiral Model is shown below :

The main strength of the Spiral Model comes from the fact that it is very sensitive to the
risk. Because of the spiral nature of development it is easy to judge how much to test and
there is no distinction between development and maintenance. It however can only be
used for large-scale software development and that too for internal (in-house) software
only.

Object-Oriented Lifecycle Models
Object-oriented lifecycle models appreciate the need for iteration within and between
phases. There are a number of these models. All of these models incorporate some form
of iteration, parallelism, and incremental development.
Extreme Programming
It is a somewhat controversial new approach. In this approach user requirements are
captured through stories which are the scenarios presenting the features needed by the
client? Estimate for duration and cost of each story is then carried out. Stories for the next
build are selected. Then each build is divided into tasks. Test cases for task are drawn up
first before and development and continuous testing is performed throughout the
development process.
One very important feature of extreme programming is the concept of pair programming.
In this, a team of two developers develop the software, working in team as a pair to the
extent that they even share a single computer.

In Extreme Programming model, computers are put in center of large room lined with
cubicles and client representative is always present. One very important restriction
imposed in the model is that no team is allowed to work overtime for 2 successive weeks.
XP has had some successes. It is good when requirements are vague or changing and the
overall scope of the project is limited. It is however too soon to evaluate XP.
Fountain Model
Fountain model is another object-oriented lifecycle model. This is depicted in the
following diagram.
Requirement
Object-oriented analysis
Object-oriented design
Implementation
Implementation and integration
Further development
Operations
Maintenance

In this model the circles representing the various phases overlap, explicitly representing
an overlap between activities. The arrows within a phase represent iteration within the
phase. The maintenance cycle is smaller, to symbolize reduced maintenance effort when
the object oriented paradigm is used.
Rational Unified Process (RUP)
Rational Unified Process is very closely associated with UML and Krutchen’s
architectural model. In this model a software product is designed and built in a succession
of incremental iterations. It incorporates early testing and validation of design ideas and
early risk mitigation. The horizontal dimension represents the dynamic aspect of the
process. This includes cycles, phases, iterations, and milestones. The vertical dimension
represents the static aspect of the process described in terms of process components
which include activities, disciplines, artifacts, and roles. The process emphasizes that
during development, all activities are performed in parallel, however, and at a given time
one activity may have more emphasis than the other.
The following figure depicting RUP is taken from Krutchen’s paper.

Comparison of Lifecycle Models
As discussed above, each lifecycle model has some strengths and weaknesses. These are
summarized in the following table :

The criteria to be used for deciding on a model include the organization, its management,
skills of the employees, and the nature of the product. No single model 2 1 may fulfill the
needs in a given situation. It may therefore be best to devise a lifecycle model tuned to
your own needs by creating a ―Mix-and-match‖ life-cycle model.
Quality Assurance and Documentation
It may be noted that there is no separate QA or documentation phase. QA is an activity
performed throughout software production. It involves verification and validation.

Verification is performed at the end of each phase whereas validation is performed before
delivering the product to the client.
Similarly, every phase must be fully documented before starting the next phase. It is
important to note that postponed documentation may never be completed as the
responsible individual may leave. Documentation is important as the product is
constantly changing—we need the documentation to do this. The design (for example)
will be modified during development, but the original designers may not be available to
document it.
The following table shows the QA and documentation activities associated with each
stage.

Phase Documents QA
Requirement
Definition
Rapidprototype, or
Requirementsdocument
Rapidprototype
Reviews
Functional
Specification
Specification document(specifications)
SoftwareProductManagement Plan
Traceability
FSReview
ChecktheSPMP
Design Architectural Design
DetailedDesign
Traceability
Review
Coding Sourcecode
Test cases
Traceability
Review
Testing
Integration Sourcecode
Test cases
Integrationtesting
Acceptance testing
Maintenance Changerecord
Regressiontest cases
Regressiontesting

INTRODUCTION TO SOFTWARE ENGINEERING

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to INTRODUCTION TO SOFTWARE ENGINEERING (20)

More from Prof Ansari (20)

Recently uploaded (20)

INTRODUCTION TO SOFTWARE ENGINEERING