LECTURE THREE: SOFTWARE PROCESSES

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.

3.2 Specific Objectives:

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.


3.3 Lecture Outline:

3.3.1Definition of a life cycle model

3.3.2 Importance of software life cycle model
3.3.3Classical Waterfall Model
3.3.4 Spiral Model
3.3.5 Prototyping Model
3.3.6 Evolutionary Model
3.3.7 Incremental Model

3.4 Software Life 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. 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.

3.5 Importance of a software life cycle model

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.

3.6 The classical waterfall model

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

Phases of water fall model

3.6.1 Feasibility study

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.

3.6.2 Requirement Analysis and Specification

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.

3.6.3 System design: -

The design phase is to transform the requirements specified from the SRS document into a
design that is suitable for implementation in some programming language. During the design
phase the software architecture is derived from the SRS document. Two distinctly different
approaches are available: the traditional design approach and the object-oriented design
approach.
 1. Traditional design approach
Traditional design consists 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.

2. 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.

3.6.4 Coding and unit testing:-

The coding and unit testing phase (sometimes referred to implementation phase because the
design is implemented) of software development involves translating the software design into
source code using a programming language. 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
tested individually.
During this phase, each module is tested to determine that it works correctly. It involves
testing each module in isolation as this is the most efficient way to debug the errors identified
at this stage.

3.6.5 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 based on the
system design. The different modules rarely integrated all at one instead 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:
1. Alpha – testing: system testing performed by the development team.
2. Beta– testing: system testing performed by a friendly set of customers.
3. Acceptance testing: 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 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.

3.6.8 Disadvantages of waterfall model:

 Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing.

3.6.9 When to use the waterfall model:

 Requirements are very well known, clear and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short.

3.7 Spiral model

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.

1. First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives.
2. Second 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.
3. Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving the identified risks.
4. 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.
3.7.1 Advantages of Spiral model:
 High amount of risk analysis hence, avoidance of Risk is enhanced.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.

3.7.2 Disadvantages of Spiral model:

 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.

3.7.3 When to use Spiral model:

 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment unwise because of potential changes to economic
priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and exploration)

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:

1. Throwaway/Rapid Prototyping: Throwaway prototyping is also called as rapid or close

ended prototyping. This type of prototyping uses very little efforts with minimum
requirement analysis to build a prototype. Once the actual requirements are understood,
the prototype is discarded and the actual system is developed with a much clear
understanding of user requirements.
2. Evolutionary Prototyping: Evolutionary prototyping also called as breadboard prototyping
is based on building actual functional prototypes with minimal functionality in the
beginning. The prototype developed forms the heart of the future prototypes on top of
which the entire system is built. Using evolutionary prototyping only well understood
 requirements are included in the prototype and the requirements are added as and when
they are understood.
3. Incremental Prototyping: Incremental prototyping refers to building multiple functional
prototypes of the various sub systems and then integrating all the available prototypes to
form a complete system.
4. Extreme Prototyping: Extreme prototyping is used in the web development domain. It
consists of three sequential phases. First, a basic prototype with all the existing pages is
presented in the html format. Then the data processing is simulated using a prototype
services layer. Finally the services are implemented and integrated to the final prototype.
This process is called Extreme Prototyping used to draw attention to the second phase of
the process, where a fully functional UI is developed with very little regard to the actual
services.

A prototype of the actual product is preferred in situations such as:

• user requirements are not complete
• technical issues are not clear

Let’s see an example for each of the above category.

3.8.1 Advantages of Prototype model:

 Users are actively involved in the development
 Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily
 Confusing or difficult functions can be identified

3.8.2 Disadvantages of Prototype model:

 Leads to implementing and then repairing way of building systems.
 Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
 Incomplete application may cause application not to be used as the full system was
designed
 Incomplete or inadequate problem analysis.

3.8.3 When to use Prototype model:

 Prototype model should be used when the desired system needs to have a lot of
interaction with the end users.
 Typically, online systems, web interfaces have a very high amount of interaction with end
users, are best suited for Prototype model. It might take a while for a system to be built
that allows ease of use and needs minimal training for the end user.
 Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.
3.9 Evolutionary Development

Evolutionary development is an iterative and incremental approach to software

development. Instead of creating a comprehensive artifact, such as a requirements
specification, that you review and accept before creating a comprehensive design model, you
instead evolve the critical development artifacts over time in an iterative manner. Instead of
building and then delivering your system in a single “big bang” release you instead deliver it
incrementally over time
It is often associated with the object-oriented approach to system development. The aim of
this process is to split the problem up into many sub-tasks each of which can deliver a part of
the product that offers a tangible improvement in the system to the users. Each sub-task is
tackled and delivered as a separate deliverable in the life of the project. Delivery of a new
component changes the perception of the project, then the priorities on completing the
remaining tasks are re-evaluated in the light of the new component and the most important
(from a user view) is chosen as the next to deliver. Evolutionary development is highly robust
because changes can easily be factored into the process but it is not particularly Visible
because it may be difficult to keep track of many sub-tasks in an efficient way.
There is growing recognition that software, like all complex systems, evolves over a period of
time. Business and product requirements often change as development proceeds, making a
straight line path to an end product unrealistic; tight market deadlines make completion of a
comprehensive software product impossible, but a limited version must be introduced to meet
competitive or business pressure; a set of core product or system requirements is well
understood, but the details of product or system extensions have yet to be defined. In these
and similar situations, software engineers need a process model that has been explicitly
designed to accommodate a product that evolves over time.
The Evolutionary models are iterative. They are characterized in a manner that enables
software engineers to develop increasingly more complete versions of the software.

3.9.1 Advantages of Evolutionary Model

 This model is useful in exploratory programming (such as Artificial Intelligence
applications) where it is difficult to frame the
specifications.
 In case major problems are foreseen, the developer can stop the
development after some iterations.
 This model is very appropriate for research projects. For example, to develop software
for automatic speech recognition, a small vocabulary can be taken and the system is
developed. After achieving success, the vocabulary can be increased in stages. This
approach is better than starting development of an unlimited vocabulary speech
recognition system directly (and after two years, realizing that it is very difficult!).

3.9.2 Disadvantages of Evolutionary Model

◦ Lack of process visibility
◦ Systems are often poorly structured
◦ Special skills (e.g. in languages for rapid prototyping) may be required

3.9.3 When to use Evolutionary Model

◦ For small or medium-size interactive systems
◦ For parts of large systems (e.g. the user interface)
◦ For short-lifetime systems
3.10 INCREMENTAL MODEL

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.

3.10.1 Advantages of Incremental model:

 Generates working software quickly and early during the software life cycle.
 More flexible – less costly to change scope and requirements.
 Easier to test and debug during a smaller iteration.
 Customer can respond to each built.
 Lowers initial delivery cost.
 Easier to manage risk because risky pieces are identified and handled during it’d
iteration.

3.10.2 Disadvantages of Incremental model:

 Needs good planning and design.
 Needs a clear and complete definition of the whole system before it can be broken down
and built incrementally.
 Total cost is higher than waterfall.

3.10.3 When to use the Incremental model:

 Requirements of the complete system are clearly defined and understood.
 Major requirements must be defined; however, some details can evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.
3.11 Activities

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.12 Self Test Questions

1. A prototype of the actual product is preferred in situations such as:

• user requirements are not complete
• technical issues are not clear.
Give an example for each of the above category.
2. Discuss at least six software process models. Identify their advantages and
disadvantages

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.

2.8 Extracted from

SE Complete Notes Version 2 CSE IIT, Kharagpur

Ian Sommerville (2011) Software Engineering (11th Edition) Addison Wesley

Various Internet resources