CHAPTER 2: SOFTWARE DEVELOPMENT PROCESSES

Definition: The activities that go into producing an “information systems” solutions to

“an organizational” problem or opportunity/ challenge.

● It is part of organizational problem solving process.

● Problem may be :-

● Non performance as expected.

● Realization of areas, it should take advantage of

new opportunities (to perform more successfully).

System development is a structured problem-solving process with distinct activities: -

● System planning

● System analysis a
g
● System design
b
● Programming/ implementation f
c e
● Testing
d
● Conversion

● Production System development process

NB: each activity entails interaction with the
● Maintenance
organization

NB: The activities takes place sequentially but since some may need to be repeated while
others may take place simultaneously, depending on the approach to the system building
employed.
The Software Process Models

The software process is the set of activities and associated results, which produce a
software product. These activities are mostly carried out by software engineers.
There is no such thing as a ‘right’ or a ‘wrong’ software process. Different software
processes decompose software activities (feasibility study, analysis, design,
implementation and evolution) in different ways. The timing of the activities varies as
does the results of each activity. Different organizations use different processes to
produce the same type of product. However, some processes are more suitable than
others for some types of application. If the wrong process is used, this will probably
reduce the quality or the usefulness of the software product to be developed.
Because there are a variety of different process models used, it is impossible to produce
reliable figures for cost distribution across these activities. However, we do know that
modifying software usually takes up more than 60% of total software costs. This
percentage is increasing as more and more software is produced and has to be
maintained. Designing software for change is therefore essential.
Software processes (like most business processes) are complex and involve a very large
number of activities. Like products, processes also have attributes or characteristics.
It is not possible to optimize all process attributes simultaneously. For example, if a
rapid development process is required then it may be necessary to reduce the process
visibility. Making a process visible means producing documents at regular intervals.

PROCESS CHARACTERISTICS DESCRIPTION

i) Understandability – To what extent is the process explicitly defined and how easy
is it to understand the process definition?

ii) Visibility – Do the process activities culminate in clear results so that the progress
of the process is externally visible?

iii) Supportability – To what extent can the process activities be supported by CASE
tools?

iv) Acceptability – Is the defined process acceptable to and unable by the engineers
responsible for producing the software products?
v) Reliability - Is the process designed in such a way that process errors are avoided
or trapped before they result in product errors?

vi) Robustness – Can the process continue in spite of unexpected problems?

vii) Maintainability – Can the process evolve to reflect changing organization

requirements or identified process improvements?

viii) Rapidity – How fast can the process of delivering a system from a given
specification be completed?

METHODOLOGIES OF SYSTEM DEVELOPMENT

• THE ‘WATERFALL’ MODEL

The first explicit model of the software development process was derived from other
engineering processes (Royce, 1970). This was enthusiastically accepted by software
project management. It offered a means of making the development process more
visible. Because of the cascade from one phase to another, this model is known as the
‘waterfall model’.
There are numerous variations of this process model (which is sometimes called the
software life cycle). The principal stages of the model map onto the fundamental
development activities:

Requirements
Definition

System and
Software Design

Implementation
and Unit testing

Integration and
System Testing

Operation and
Maintenance
 1. Requirements analysis and definition: The system’s services, constraints and
goals are established by consultation with system users. They are then defined in
a manner which is understandable by both users and development staff.

2. System and software design: The systems design process partitions the
requirements to either hardware or software system. It establishes an overall
system architecture. Software design involves representing the software system
functions in a form that may be transformed into one or more executable
programs.

3. Implementation and unit testing: During this stage, the software design is realized as
a set of program units. Unit testing involves verifying that each unit meets its
specification.

4. Integration and system testing: The individual program units 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 (although not necessarily) this is the longest
life cycle phase. 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 practice these stages overlap and feed information to each other. During design,
problem with requirements are identified: during coding, design problems are found and
so on. The software process in not a simple linear model but involves a sequence of
iterations of the development activities.
During the final life cycle phase (operation and maintenance) the software is put into use.
Errors and omissions in the original software requirements are discovered. Program and
design errors emerge and the need for new functionality is identified. Modifications
become necessary for the software to remain useful. Making these changes (software
maintenance) may involve repeating some or all previous process stages.
Unfortunately, a model which includes frequent iterations makes it difficult to identify
definite management checkpoints for planning and reporting. Therefore, after a small
number of iterations, it is normal to freeze parts of the development, such as the
specification, and to continue with the later development stages. Problems are left for
later resolution, ignored or are programmed around. This premature freezing of
requirements may mean that the system won’t do what the users want. It may also lead to
badly structured systems as design problems are circumvented by implementation tricks.
The problem with the waterfall model is its inflexible partitioning of the project into these
distinct stages. Delivered systems are sometimes unusable, as they do not meet the
customer’s real requirements. Nevertheless the waterfall model reflects engineering
practice. Consequently, it is likely that software process models based on this approach
will remain the norm for large hardware–software systems development.

• PROTOTYPING MODEL
Prototype
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
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 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
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.
A prototype of the actual product is preferred in situations such as:
• User requirements are not complete
• Technical issues are not clear

• 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 modules for 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 development because the system can be easily
portioned into units in terms of objects.

Advantages:
 User gets a chance to experiment partially developed system

 Reduce the error because the core modules get tested thoroughly.

Disadvantages:
 It is difficult to divide the problem into several versions that would be acceptable to the
customer which can be incrementally implemented & delivered.
 Fig 3.3: Evolutionary Model

• SPIRAL MODEL
The Spiral model of software development is shown in fig. 4.1. 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, the next one with design, and so on. Each phase in this
model is split into four sectors (or quadrants) as shown in fig. 4.1. The following activities
are carried out during each phase of a spiral model.
 Fig 4.1: Spiral Model

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.
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.
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.
Circumstances to use spiral model
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.

Advantages of the Spiral Model

Below are some advantages of the Spiral Model.
 Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development model to
follow due to the risk analysis and risk handling at every phase.
 Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
 Flexibility in Requirements: Change requests in the Requirements at a later phase
can be incorporated accurately by using this model.
 Customer Satisfaction: Customers can see the development of the product at the
early phase of the software development and thus, they habituated with the system by
using it before completion of the total product.
 Iterative and Incremental Approach: The Spiral Model provides an iterative and
incremental approach to software development, allowing for flexibility and
adaptability in response to changing requirements or unexpected events.
 Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk
management, which helps to minimize the impact of uncertainty and risk on the
software development process.
  Improved Communication: The Spiral Model provides for regular evaluations and
reviews, which can improve communication between the customer and the
development team.
 Improved Quality: The Spiral Model allows for multiple iterations of the software
development process, which can result in improved software quality and reliability.
Disadvantages of the Spiral Model
Below are some main disadvantages of the spiral model.
 Complex: The Spiral Model is much more complex than other SDLC models.
 Expensive: Spiral Model is not suitable for small projects as it is expensive.
 Too much dependability on Risk Analysis: The successful completion of the
project is very much dependent on Risk Analysis. Without very highly experienced
experts, it is going to be a failure to develop a project using this model.
 Difficulty in time management: As the number of phases is unknown at the start of
the project, time estimation is very difficult.
 Complexity: The Spiral Model can be complex, as it involves multiple iterations of
the software development process.
 Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple
evaluations and reviews.
 Resource Intensive: The Spiral Model can be resource-intensive, as it requires a
significant investment in planning, risk analysis, and evaluations.

• Agile
Agile is the methodology that developers favor the most out of all the
methodologies out there.

Famous for its iterative approach to software development that offers rapid-fire
progress, Agile is a framework that fosters highly collaborative environments
between all the teams involved in a project.

It’s dynamic, adaptive, flexible, lightweight, and extremely responsive, working in

sprints with a defined time period to complete small and highly manageable
tasks, thus reducing the time in which software goes live. Through and through,
Agile is an advocate of adaptive planning, evolutionary development, continuous
improvement, responsiveness, flexibility, and quick delivery.

• Iterative and incremental

The iterative and incremental SDLC model does its name honor. This model is
kicked off with a small set of requirements which is then enhanced iteratively with
evolving versions until you reach a final product that’s ready to be implemented
and deployed. The iterative and incremental model is the answer to Waterfall’s
many faults; for example, the iterative life cycle starts by specifying and
implementing only a portion of the software, which is then reviewed to dictate
which features will follow next.

In short, the iterative and incremental model works through multiple, repeated,
and incremental cycles so developers can pinpoint which areas to improve based
on previous deployments of the software.

• V model
An extended arm of the Waterfall methodology, the v-model executes processes
sequentially in an upward fashion, which in visual context resembles the letter V. Some
refer to the v-model as the verification and validation model thanks to its foundation of
testing phases for each development phase. In short, every piece of software development
is associated with a testing phase.

One thing to note about the v-model is that no phase can start until the previous one is
completed including a corresponding testing exercise.
Advantages:
This is a highly disciplined model and Phases are completed one at a time.

 V-Model is used for small projects where project requirements are clear.

 Simple and easy to understand and use.

 This model focuses on verification and validation activities early in the life cycle
thereby enhancing the probability of building an error-free and good quality product.

 It enables project management to track progress accurately.

 Clear and Structured Process: The V-Model provides a clear and structured process
for software development, making it easier to understand and follow.

 Emphasis on Testing: The V-Model places a strong emphasis on testing, which helps
to ensure the quality and reliability of the software.

 Improved Traceability: The V-Model provides a clear link between the requirements
and the final product, making it easier to trace and manage changes to the software.

 Better Communication: The clear structure of the V-Model helps to improve

communication between the customer and the development team.

Disadvantages:
High risk and uncertainty.

It is not a good for complex and object-oriented projects.

It is not suitable for projects where requirements are not clear and contains high risk
of changing.

This model does not support iteration of phases.

It does not easily handle concurrent events.

Inflexibility: The V-Model is a linear and sequential model, which can make it
difficult to adapt to changing requirements or unexpected events.

Time-Consuming: The V-Model can be time-consuming, as it requires a lot of

documentation and testing.

Overreliance on Documentation: The V-Model places a strong emphasis on

documentation, which can lead to an overreliance on documentation at the expense of
actual development work.

RAD
 Rapid Application Development (RAD) is a software development model that
focuses on rapid prototyping and quick iterations. It prioritizes speed and user
involvement in the development process.

Advantages:

 The use of reusable components helps to reduce the cycle time of the project.

 Feedback from the customer is available at the initial stages.

 Reduced costs as fewer developers are required.

 The use of powerful development tools results in better quality products in

comparatively shorter time spans.

 The progress and development of the project can be measured through the
various stages.

 It is easier to accommodate changing requirements due to the short iteration

time spans.

 Productivity may be quickly boosted with a lower number of employees.

Disadvantages:
  The use of powerful and efficient tools requires highly skilled professionals.

 The absence of reusable components can lead to the failure of the project.

 The team leader must work closely with the developers and customers to close
the project on time.

 The systems which cannot be modularized suitably cannot use this model.

 Customer involvement is required throughout the life cycle.

 It is not meant for small-scale projects as in such cases, the cost of using
automated tools and techniques may exceed the entire budget of the project.

 Not every application can be used with RAD.

Comparison of different life-cycle models

The 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.
This 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.
The 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.