Professional Documents
Culture Documents
l3 Sep Software Process
l3 Sep Software Process
3.1 Introduction
This lecture introduces various software development processes. We begin by defining life
cycle models and their importance in software development. We shall also explain the
activities undertaken in the different phases of the software development process.
AtLecture
3.3 the end of this lecture you should be able to:
Outline
3.3.1 •Classical
ExplainWaterfall
the term life cycle model.
Model
• Explain
3.3.2 Spiral Model what problems would occur if no life cycle model is used.
• Identify the
3.3.3 Prototyping Model different phases and activities of the classical waterfall model.
Identify the
3.3.4 Evolutionary Modeldifferent phases and activities of the Spiral Model
Identify the different phases and activities of Prototyping Model.
Identify the different phases and activities of Evolutionary Model.
Identify the different phases and activities of Incremental 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. It also captures the order in which these activities are to
be undertaken.
A life cycle model maps the different activities performed on a software product from its
inception to retirement. Different lifecycle models may map the basic development activities
to phases in different ways. The basic activities included in all life cycle models are similar
though the activities may be carried out in different orders in different life cycle models.
During any life cycle phase, more than one activity may also be carried out. For example, the
design phase might consist of the structured analysis activity followed by the structured
design activity.
The development team must identify a suitable life cycle model for the particular project and
then follow it. Without using of a particular life cycle model the development of a software
product would not be done 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. Otherwise it would lead to chaos and project failure. For
example: A software development problem is divided into several parts and the parts are
assigned to the team members. From then on, 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 lack of consistency would lead to project failure.
The waterfall model is a sequential design process, often used in software development
processes, in which progress is seen as flowing steadily downwards (like a waterfall) through
the phases of Feasibility Study, Requirements Analysis and Specification, Design, Coding
and Unit Testing, Integration and System Testing and Maintenance.
The classical waterfall model is the most obvious way to develop software. 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.
In order to be able to appreciate other life cycle models it is necessary to learn the classical
waterfall model.
Classical waterfall model divides the life cycle into the following phases:
• Feasibility Study
• Requirements Analysis and Specification
• Design
• Coding and Unit Testing
• Integration and System Testing
• Maintenance
The main aim of feasibility study is to determine whether it would be financially and
technically feasible to develop the product. The project managers or team leaders try to
understand 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. When they have an overall understanding of the problem 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.
Based on this analysis they select the best solution and determine whether the customer
budget would meet the cost of the product and whether they have sufficient technical
expertise in the area of development.
The 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 so as to clearly understand the
customer requirements so that incompleteness and inconsistencies are removed.
The requirements analysis activity is begins with collecting all relevant data regarding the
product to be developed from the users of the product and from the customer .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 contains several
contradictions and ambiguities, since each user has only a partial and incomplete view of the
system. It is therefore 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 the requirements
properly understood, the requirements specification activity can begin.
During specification, 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 nonfunctional
requirements, and the goals of implementation.
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 required resources. It also lists all the test cases
and the expected outputs for each test case.
3.6.6 Maintenance: -
Maintenance of software products requires a lot more effort than 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 ratio. Maintenance involves performing any one or more of the following three kinds
of activities:
Corrective Maintenance: correcting errors that were not discovered during the product
development phase.
Perfective maintenance: Improving the implementation of the system, and enhancing the
functionalities of the system according to the customer’s requirements.
Adaptive maintenance : migrating the software to work in a new environment. For example,
moving the software to work with a new operating system.
.
3.6.7 Advantages of waterfall model:
Simple and easy to understand and use.
Easy to manage due to the rigidity of the model – each phase has specific deliverables
and a review process.
Phases are processed and completed one at a time.
Works well for smaller projects where requirements are very well understood.
Many projects are risk driven. The process model proposed by Professor Barry Boehm aims
to control and manage project risks during the course of development and provide
opportunities for understanding the problem domain throughout the development and for
building the system incrementally. The spiral model begins with an initial plan for
development, evaluate risks, perhaps do some prototyping to evaluate alternatives at the
system level, and produces a concept of operations document which describes how the
system should work at a high level. From the concept of operations, a set of requirements for
the system is extracted and this should be as complete as possible. The spiral model then uses
to iteration to complete the development.Each iteration typically involves risk analysis,
prototyping to determine the feasibility and desirability of various alternatives and then
design, coding and testing.
It allows for a complete re-evaluation of the project direction after each spiral, and the
requirements can be re-evaluated. However we need to ensure that new insights, which lead
to new requirements are consistent with prior requirements and with the what has been built
thus far
The Spiral model of software development is shown above .The 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 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.
3.8 Prototype
A prototype is a model implementation of the system. It 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.
There 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
• how the user interface would behave
• how the system would produce outputs
This is something similar to what the architectural designers of a building do; they show a
prototype of the building to their customer. The customer can evaluate whether he likes it or
not and the changes that he would need in the actual product. A similar thing happens in the
case of a software product and its prototyping model.
Another reason for developing a prototype is that it is impossible to get the perfect product in
the first attempt. Many researchers and engineers advocate that if you want to 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.
A prototyping model can be used when technical solutions are unclear to the 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.
Following is the stepwise approach to design a software prototype:
Basic Requirement Identification: This step involves understanding the very basics
product requirements especially in terms of user interface. The more intricate details
of the internal design and external aspects like performance and security can be
ignored at this stage.
Developing the initial Prototype: The initial Prototype is developed in this stage,
where the very basic requirements are showcased and user interfaces are provided.
These features may not exactly work in the same manner internally in the actual
software developed and the workarounds are used to give the same look and feel to
the customer in the prototype developed.
Review of the Prototype: The prototype developed is then presented to the customer
and the other important stakeholders in the project. The feedback is collected in an
organized manner and used for further enhancements in the product under
development.
Revise and enhance the Prototype: The feedback and the review comments are
discussed during this stage and some negotiations happen with the customer based on
factors like , time and budget constraints and technical feasibility of actual
implementation. The changes accepted are again incorporated in the new Prototype
developed and the cycle repeats until customer expectations are met.
Prototypes can have horizontal or vertical dimensions. Horizontal prototype displays the user
interface for the product and gives a broader view of the entire system, without concentrating
on internal functions. A vertical prototype on the other side is a detailed elaboration of a
specific function or a sub system in the product.
The purpose of both horizontal and vertical prototype is different. Horizontal prototypes are
used to get more information on the user interface level and the business requirements. It can
even be presented in the sales demos to get business in the market. Vertical prototypes are
technical in nature and are used to get details of the exact functioning of the sub systems. For
example, database requirements, interaction and data processing loads in a given sub system.
There are different types of software prototypes used in the industry. Following are the major
software prototyping types used widely:
The incremental model the whole requirement is divided into various builds. Multiple
development cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles
are divided up into smaller, more easily managed modules. Each module passes through the
requirements, design, implementation and testing phases. A working version of software is
produced during the first module, so you have working software early on during the software
life cycle. Each subsequent release of the module adds function to the previous release. The
process continues till the complete system is achieved.
1) Read more about software processes from chapter two of the book software engineering by Ian
Sommerville 9th edition
2) Read and writes notes on
i. V model
ii. RAD model
3.13 Summary
We have discussed all the popular SDLC models. Waterfall is traditional SDLC models and is
sequential type. Sequential means that the next phase can start only after the completion of first
phase. Such models are suitable for projects with very clear product requirements and where
the requirements will not change dynamically during the course of project completion.
Spiral models are more accommodative in terms of change and are suitable for projects where
the requirements are not so well defined, or the market requirements change quite frequently.
Software Prototype and evolutionary are modern techniques to understand the requirements in a
better way early in the project cycle.