INTRODUCTION:
S oftware Engineeringis a framework for building softwareand is an engineering approach to
software development. Software programs can be developed without S/E principles and
methodologies but they are indispensable if we want to achieve good quality software in a
cost effective manner.
S OFTWARE ENGINEERINGis defined as a systematic, disciplinedand quantifiable approach for
the development, operation and maintenance of software.
SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY
• Quality focus - Bedrock that supports Software Engineering.
• Process - Foundation for software Engineering
• Methods - Provide technical How-to’s for building software
• Tools - Provide semi-automatic and automatic support to methods
NEED OF SOFTWARE ENGINEERING
T he need of software engineering arises because of higher rate of change in user requirements
and environment on which the software is working.
∙Large software -It is easier to build a wall thanto a house or building, likewise, as the size
of software become large engineering has to step to give it a scientific process.
∙Scalability-If the software process were not basedon scientific and engineering concepts,
it would be easier to re-create new software than to scale an existing one.
∙ Cost- As hardware industry has shown its skills and huge manufacturing has lower down the
price of computer and electronic hardware. But the cost of software remains high if proper
process is not adapted.
∙Dynamic Nature-The always growing and adaptingnature of software hugely depends upon the
environment in which the user works. If the nature of software is always changing, new
enhancements need to be done in the existing one. This is where software engineering plays a
good role.
∙Quality Management-Better process of software developmentprovides better and quality
software product.
CHARACTERESTICS OF GOOD SOFTWARE
software product can be judged by what it offers and how well it can be used. This software
A
must satisfy on the following grounds:
∙Operational
∙Transitional
∙Maintenance
Operational
This tells us how well software works in operations. It can be measured
on: ∙Budget
∙Usability
∙Efficiency
∙Correctness
∙Functionality
∙Dependability
∙Security
∙Safety
Transitional
This aspect is important when the software is moved from one platform to
another: ∙Portability
∙Interoperability
∙Reusability
∙Adaptability
Maintenance
T his aspect briefs about how well a software has the capabilities to maintain itself in the
ever changing environment:
∙Modularity
∙Maintainability
∙Flexibility
SOFTWARE DEVELOPMENT LIFE CYCLE(SDLC)
L IFE CYCLE MODEL A software life cycle model (also called process model) is a descriptive and
diagrammatic representation of the software life cycle. A life cycle model represents all the activities
required to make a software product transit through its life cycle phases. It also captures the order
in which these activities are to be undertaken.
THE NEED FOR A SOFTWARE LIFE CYCLE MODEL
T he development team must identify a suitable life cycle model for the particular project and
then adhere to it. Without using of a particular life cycle model the development of a software
product would not be in a systematic and disciplined manner. When a software product is being
developed by a team there must be a clear understanding among team members about when
and what to do.
E xample- Suppose a software development problem is divided into several parts and the parts are
assigned to the team members. From then on, suppose the team members are allowed the
freedom to develop the parts assigned to them in whatever way they like. It is possible that one
member might start writing the code for his part, another might decide to prepare the test
documents first, and some other engineer might begin with the design phase of the parts assigned
to him. This would be one of the perfect recipes for project failure. A software life cycle model
defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria have
been satisfied. So without software life cycle model the entry and exit criteria for a phase cannot
be recognized. Without software life cycle models it becomes difficult for software project
managers to monitor the progress of the project.
Different software life cycle models
any life cycle models have been proposed so far. Each of them has some advantages as well
M
as some disadvantages. A few important and commonly used life cycle models are as follows:
∙Classical Waterfall Model
∙Iterative Waterfall Model
∙Prototyping Model
∙Evolutionary Model
∙Spiral Model
1. CLASSICAL WATERFALL MODEL
T he classical waterfall model is intuitively the most obvious way to develop software.
Though the classical waterfall model is elegant and intuitively obvious, it is not a practical
model in the sense that it cannot be used in actual software development projects. Thus,
this model can be considered to be a theoretical way of developing software. But all other
life cycle models are essentially derived from the classical waterfall model. So, in order to
be able to appreciate other life cycle models it is necessary to learn the classical waterfall
model.
Feasibility study –
T he main aim of feasibility study is to determine whether it would be financially
and technically feasible to develop the product.
∙At first project managers or team leaders try tohave a rough understanding of what is
required to be done by visiting the client side. They study different input data to the system
and output data to be produced by the system. They study what kind of processing is
needed to be done on these data and they look at the various constraints on the behavior
of the system.
∙After they have an overall understanding of theproblem they investigate the different
solutions that are possible. Then they examine each of the solutions in terms of what kind
of resources required, what would be the cost of development and what would be the
development time for each solution.
∙Basedonthisanalysistheypickthebestsolutionanddeterminewhetherthesolutionis
feasiblefinanciallyandtechnically.Theycheckwhetherthecustomerbudgetwouldmeet
thecostoftheproductandwhethertheyhavesufficienttechnicalexpertiseinthearea
of development.
Requirements analysis and specification: -
T he aim of the requirements analysis and specification phase is to understand the exact
requirements of the customer and to document them properly. This phase consists of
two distinct activities, namely
∙Requirements gathering and analysis
∙Requirements specification
The goal of the requirements gathering activity is to collect all relevant information from
the customer regarding the product to be developed. This is done to clearly understand
the customer requirements so that incompleteness and inconsistencies are removed.
T he requirements analysis activity is begun by collecting all relevant data regarding the
product to be developed from the users of the product and from the customer through
interviews and discussions. For example, to perform the requirements analysis of a
business accounting software required by an organization, the analyst might interview all
the accountants of the organization to ascertain their requirements. The data collected
from such a group of users usually contain several contradictions and ambiguities, since
each user typically has only a partial and incomplete view of the system. Therefore it is
necessary to identify all ambiguities and contradictions in the requirements and resolve
them through further discussions with the customer. After all ambiguities, inconsistencies,
and incompleteness have been resolved and all the requirements properly understood, the
requirements specification activity can start. During this activity, the user requirements are
systematically organized into a Software Requirements Specification (SRS) document. The
customer requirements identified during the requirements gathering and analysis activity
are organized into a SRS document. The important components of this document are
functional requirements, the non functional requirements, and the goals of
implementation.
esign: - The goal of the design phase is to transform the requirements specified in the
D
SRS document into a structure that is suitable for implementation in some programming
language.
In technical terms, during the design phase the softwarearchitectureisderivedfromthe
SRS document. Two distinctly different approaches are available: the traditional design
approach and the object-oriented design approach.
∙Traditional design approach -Traditional designconsists of two different activities; first
a structured analysis of the requirements specification is carried out where the detailed
structure of the problem is examined. This is followed by a structured design activity.
During structured design, the results of structured analysis are transformed into the
software design.
∙Object-oriented design approach -In this technique,various objects that occur in the
problem domain and the solution domain are first identified, and the different
relationships that exist among these objects are identified. The object structure is further
refined to obtain the detailed design.
Coding and unit testing:-
T he purpose of the coding phase (sometimes called the implementation phase) of
software development is to translate the software design into source code. Each
component of the
design is implemented as a program module. The end-product of this phase is a set of
program modules that have been individually tested. During this phase, each module is
unit tested to determine the correct working of all the individual modules. It involves
testing each module in isolation as this is the most efficient way to debug the errors
identified at this stage.
Integration and system testing: -Integration of different modules is undertaken once they
have been coded and unit tested. During the integration and system testing phase, the
modules are integrated in a planned manner. The different modules making up a software
product are almost never integrated in one shot. Integration is normally carried out
incrementally over a number of steps. During each integration step, the partially integrated
system is tested and a set of previously planned modules are added to it. Finally, when all
the modules have been successfully integrated and tested, system testing is carried out.
The goal of system testing is to ensure that the developed system conforms to its
requirements laid out in the SRS document. System testing usually consists of three
different kinds of testing activities:
∙α – testing:It is the system testing performedby the development team. ∙β –testing:It
is the system testing performed by a friendly set of customers. ∙Acceptance testing:It is
t he system testing performed by the customer himself after the product delivery to
determine whether to accept or reject the delivered product. System testing is normally
carried out in a planned manner according to the system test plan document. The system
test plan identifies all testing-related activities that must be performed, specifies the
schedule of testing, and allocates resources. It also lists all the test cases and the expected
outputs for each test case.
Maintenance: -Maintenance of a typical software productrequires much more than the
e ffort necessary to develop the product itself. Many studies carried out in the past
confirm this and indicate that the relative effort of development of a typical software
product to its maintenance effort is roughly in the 40:60 ratios.
Shortcomings of the classical waterfall model
T he classical waterfall model is an idealistic one since it assumes that no development error
is ever committed by the engineers during any of the life cycle phases. However, in practical
development environments, the engineers do commit a large number of errors in almost
every phase of the life cycle. The source of the defects can be many: oversight, wrong
assumptions, use of inappropriate technology, communication gap among the project
engineers, etc. These defects usually get detected much later in the life cycle. For example,
a design defect might go unnoticed till we reach the coding or testing phase. Once a defect
is detected, the engineers need to go back to the phase where the defect had occurred and
redo some of the work done during that phase and the subsequent phases to correct the
defect and its effect on the later phases. Therefore, in any practical software development
work, it is not possible to strictly follow the classical waterfall model.
2. ITERATIVE WATERFALL MODEL
T o overcome the major shortcomings of the classical waterfall model, we come up with
the iterative waterfall model.
Here,
e provide feedback paths for error correction as & when detected later in a phase.
w
Though errors are inevitable, but it is desirable to detect them in the same phase in
which they occur. If so, this can reduce the effort to correct the bug.
T headvantageof this model is that there is a workingmodel of the system at a very early
stage of development which makes it easier to find functional or design flaws. Finding
issues at an early stage of development enables to take corrective measures in a limited
budget.
T hedisadvantagewith this SDLC model is that it isapplicable only to large and bulky
software development projects. This is because it is hard to break a small software
system into further small serviceable increments/modules.
3.PRTOTYPING MODEL
rototype
P
A prototype is a toy implementation of the system. A prototype usually exhibits limited
functional capabilities, low reliability, and inefficient performance compared to the
actual software. A prototype is usually built using several shortcuts. The shortcuts might
involve using inefficient, inaccurate, or dummy functions. The shortcut implementation
of a function, for example, may produce the desired results by using a table look-up
instead of
performing the actual computations. A prototype usually turns out to be a very
crude version of the actual system.
Need for a prototype in software development.
T here are several uses of a prototype. An important purpose is to illustrate the input data
formats, messages, reports, and the interactive dialogues to the customer. This is a valuable
mechanism for gaining better understanding of the customer’s needs: ∙How the screens
might look like
∙how the user interface would behave
∙how the system would produce outputs
Another reason for developing a prototype is that it is impossible to get the perfect
roduct in the first attempt. Many researchers and engineers advocate that if you want to
p
develop a good product you must plan to throw away the first version. The experience
gained in developing the prototype can be used to develop the final product.
prototyping model can be used when technical solutions are unclear to the
A
development team. A developed prototype can help engineers to critically examine the
technical issues associated with the product development. Often, major design decisions
depend on issues like the response time of a hardware controller, or the efficiency of a
sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way
to resolve the technical issues.
prototype of the actual product is preferred in situations such as:
A
• User requirements are not complete
• Technical issues are not clear
4. EVOLUTIONARY MODEL
It is also called successive versions model or incremental model. At first, a simple working model is
built. Subsequently it undergoes functional improvements & we keep on adding new functions till
the desired system is built.
Applications:
∙Large projects where you can easily find modulesfor incremental implementation. Often used
when the customer wants to start using the core features rather than waiting for the full software.
∙Also used in object oriented software developmentbecause the system can be easily portioned
into units in terms of objects.
Advantages:
∙User gets a chance to experiment partially developedsystem
∙Reduce the error because the core modules get testedthoroughly.
Disadvantages:
∙It is difficult to divide the problem into severalversions that would be acceptable to the customer
which can be incrementally implemented & delivered.
5. SPIRAL MODEL
T he diagrammatic representation of this model appears like a spiral with many loops. The
exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase
of the software process.
For example, the innermost loop might be concerned with feasibility study, the next loop
with requirements specification, the next one with design, and so on. Each phase in this
model is split into four sectors (or quadrants) . The following activities are carried out
during each phase of a spiral model.
F irst quadrant (Objective Setting)
• During the first quadrant, it is needed to identify the objectives of the
phase. • Examine the risks associated with these objectives.
S econd Quadrant (Risk Assessment and Reduction)
• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks.
For example, if there is a risk that the requirements are inappropriate, a prototype
system may be developed.
Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving the identified
risks. Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the customer and plan the next iteration
around the spiral.
• Progressively more complete version of the software gets built with each iteration
around the spiral.
ircumstances to use spiral model
C
The spiral model is called a meta model since it encompasses all other life cycle models.
Risk handling is inherently built into this model. The spiral model is suitable for
development of technically challenging software products that are prone to several kinds
of risks. However, this model is much more complex than the other models – this is
probably a factor deterring its use in ordinary projects.
Comparison of different life-cycle models
T he classical waterfall model can be considered as the basic model and all other life cycle
models as embellishments of this model. However, the classical waterfall model cannot be
used in practical development projects, since this model supports no mechanism to
handle the errors committed during any of the phases.
T his problem is overcome in the iterative waterfall model. The iterative waterfall model is
probably the most widely used software development model evolved so far. This model is
simple to understand and use. However this model is suitable only for well-understood
problems; it is not suitable for very large projects and for projects that are subject to
many risks.
T he prototyping model is suitable for projects for which either the user requirements or
the underlying technical aspects are not well understood. This model is especially popular
for development of the user-interface part of the projects.
T he evolutionary approach is suitable for large problems which can be decomposed into a
set of modules for incremental development and delivery. This model is also widely used
for object oriented development projects. Of course, this model can only be used if the
incremental delivery of the system is acceptable to the customer.
The spiral model is called a meta model since it encompasses all other life cycle models.
Risk handling is inherently built into this model. The spiral model is suitable for
development of technically challenging software products that are prone to several kinds
f risks. However, this model is much more complex than the other models – this is
o
probably a factor deterring its use in ordinary projects.
T he different software life cycle models can be compared from the viewpoint of the
customer. Initially, customer confidence in the development team is usually high irrespective
of the development model followed. During the lengthy development process, customer
confidence normally drops off, as no working product is immediately visible. Developers
answer customer queries using technical slang, and delays are announced. This gives rise to
customer resentment. On the other hand, an evolutionary approach lets the customer
experiment with a working product much earlier than the monolithic approaches. Another
important advantage of the incremental model is that it reduces the customer’s trauma of
getting used to an entirely new system. The gradual introduction of the product via
incremental phases provides time to the customer to adjust to the new product. Also, from
the customer’s financial viewpoint, incremental development does not require a large
upfront capital outlay. The customer can order the incremental versions as and when he can
afford them.
