Lecture 2

Software Processes (Part -2)

Objectives
The objective of this lecture is to introduce a software process (part 2)—a coherent set of
activities for software production. After this lecture, student will
■ understand the concepts of software processes and software process models;
■ understand the need for software life cycle
■ have been introduced to the incremental model, the evolutionary models and the
Unified Process Model
■ understand a software life cycle model encourages the team members to perform
various development activities in a systematic and disciplined manner. It also makes
management of software development projects easier.
■ understand that the different life cycle models have their own advantages and
disadvantages. Choosing an appropriate life cycle model should focus for the problem
at hand. After choosing a basic life cycle model, software development organizations
usually tailor the standard life cycle models according to their needs.

Reference Reading

• Roger. S. Pressman, “Software Engineering, A Practitioner’s Approach”, 8th

edition, 2015
• Chapter 3: The Software Process Structure
• Chapter 4: Process Models
• Iron Sommerville, “Software Engineering”, Global Edition, 10th edition, 2016
• Chapter 2: Software Processes
• Rajib Mall, “Fundamentals of Software Engineering”, 4th Edition, 2014
• Chapter 2: Software Life Cycle Models

1. Introduction

We have discussed the generic software process model, called “the Waterfall
Model”, and the activities carried out at every step during the life cycle phases in the part 1.
However, the waterfall model is not the right process model in situations where informal
team communication is possible and software requirements change quickly. Moreover, the
characteristics of software development projects have changed drastically over years. In the
1970s and 1960s, software development projects spanned several years and mostly involved
generic software product development. The projects are now shorter, and involve
Customized software development. Further, software was earlier developed from scratch.

- 37 -
Now the emphasis is on as much reuse of code and other project artifacts as possible. In
this section, we discuss other variant of the waterfall models for different project situations.

2. Incremental Process Model

Incremental development is based on the idea of developing an initial

implementation, getting feedback from users and others, and evolving the software through
several versions until the required system has been developed (Figure 2.1). The incremental
model is sometimes referred to as the successive versions model. In this life cycle model,
first a simple working system implementing only a few basic features is built and delivered
to the customer. Over many successive iterations, successive versions are implemented and
delivered to the customer until the desired system is realised.
In the incremental model, the requirements of the software are first broken down
into several modules or features that can be incrementally constructed and delivered. This
has been pictorially shown in Figure 2.1. At any time, plan is made only for the next
increment and no long-term plans are made. Therefore, it becomes easier to
accommodate change requests from the customers. The systems are developed in
different phases that can be useful to the customers as they can be used as standalone units
when they are treated independently.

Figure 2.1: Incremental software development.

The incremental model has schematically been shown in Figure 2.2. After the
requirements gathering and specification, the requirements are split into several versions.
The development team first undertakes to develop the core features of the system. The core
or basic features are those that do not need to invoke any services from the other features.
On the other hand, non-core features need services from the core features. Once the initial
core features (version 1) are developed, these are refined into increasing levels of capability
by adding new functionalities in successive versions. Each incremental version is usually
developed using an iterative waterfall model of development. As each successive version of
the software is constructed and delivered to the customer, the customer feedback is
obtained on the delivered version and these feedbacks are incorporated in the next
version. Each delivered version of the software incorporates additional features over the
previous version and also refines the features that were already delivered to the customer.

- 38 -
After the last (shown as version n) has been developed and deployed at the client site, the
full software is deployed.
For example, the word-processing software is developed using the incremental
paradigm. The first increment, might deliver basic file management, editing, and document
production functions. The second increment, more sophisticated editing and document
production capabilities. The third increment, spelling and grammar checking and the
fourth increment, advanced page layout capability. The process flow for any increment can
incorporate the prototyping paradigm discussed in the next subsection. This model is
better than a waterfall approach for systems whose requirements are likely to change during
the development process. It is the most common approach for the development of
application systems and software products. The incremental model combines the elements’
linear (the plan-driven approach) and parallel (concurrent) process flows.

Figure 2.2: Incremental model of software development.

Figure 2.3 Incremental development (a) concurrent activities

- 39 -
 Figure 2.3 Incremental development (b) process in each successive version

2.1 Advantages of the Incremental Model

Three major ADVANTAGES over the waterfall model::-

1. The cost of implementing requirements changes is reduced.
• The amount of analysis and documentation that has to be redone is significantly
less than is required with the waterfall model.
2. It is easier to get customer feedback on the development work that has been done.
• Customers can comment on demonstrations of the software and see how much
has been implemented. Customers find it difficult to judge progress from
software design documents.
3. Early delivery and deployment of useful software to the customer is possible,
even if all of the functionality has not been included.
• Customers are able to use and gain value from the software earlier than with a
waterfall process.

2.2 Disadvantages of the Incremental Model

• It is only helpful for large software products because we can find individual
modules for incremental implementation.
• It is also used when the customer is ready to receive the product.
• The process is not visible. Managers need regular deliverables to measure progress.
If systems are developed quickly, it is not cost effective to produce documents
that reflect every version of the system.
• System structure tends to degrade as new increments are added. Regular change
leads to messy code as new functionality is added in whatever way is possible. It
becomes increasingly difficult and costly to add new features to a system.

3. Evolutionary Process Models

In the incremental development model, complete requirements are first developed

and the SRS document prepared. In contrast, in the evolutionary model, the requirements,
plan, estimates, and solution evolve over the iterations, rather than fully defined and frozen
in a major up-front specification effort before the development iterations begin. Such

- 40 -
evolution is consistent with the pattern of unpredictable feature discovery and feature
changes that take place in new product development.
The Evolutionary software development model is based upon principle of
incremented developments of the functional unit and then integrating it for visible. It is an
Iterative model and develops increasingly more complete versions of the software and
sometimes referred to as design a little, build a little, test a little, deploy a little model; this
means that after the requirements have been specified, the design, build, test, and
deployment activities are iterated.

Two common evolutionary process models are discussed here.

1. Prototyping Model
2. The Spiral Model.

Figure 2.4: Evolutionary model of software development.

3.1 Prototyping Model

This model suggests building a working prototype of the system, before

development of the actual software. When a customer defines a set of general objectives for
software, but does not identify detailed requirements for functions and features. The
prototype serves as a mechanism for identifying software requirements to better

- 41 -
understand what is to be built. The prototype can serve as “the first system”. A software
prototype is an early version of a software system that is used to demonstrate concepts,
try out design options, and find out more about the problem and its possible solutions.
This model is the most appropriate for projects that suffer from technical and
requirements risks. A constructed prototype helps overcome these risks.
A software prototype can be used
1. In the requirements engineering process, a prototype can help with the elicitation
and validation of system requirements.
2. In the system design process, a prototype can be used to explore software solutions
and in the development of a user interface for the system to check the feasibility of a
proposed design.

For example, a fitness app developed using incremental prototypes might deliver
the basic user interface screens needed to sync a mobile phone with the fitness device and
display the current data; the ability to set goals and store the fitness device data on the
cloud might be included in the second prototype, creating and modifying the user interface
screens based on customers feedback; and a third prototype might include social media
integration to allow users to set fitness goals and share progress toward them with a set of
friends.

There are two prototyping models:

1. Throw away prototyping
• In this model, some prototype systems are discarded (“throwaways”) after the
customer approves them, and the actual software is developed using the iterative
waterfall approach focus on the quality.

2. RAD – Rapid Application Development

• RAD model uses both prototyping and evolutionary models. In this model,
prototype systems are evolutionary that the prototype slowly evolves into the
actual system.
• In this model prototypes are constructed, and incrementally the features are
developed and delivered to the customer. But unlike the prototyping model, the
prototypes are not thrown away but are enhanced and used in the software
construction.

3.1.1 Prototype development

A process model for prototype development is shown in Figure 2.5. The objectives
of prototyping should be made explicit from the start of the process. These may be to
develop the user interface, to develop a system to validate functional system requirements,
or to develop a system to demonstrate the application to managers.

- 42 -
 Figure 2.5 Prototype Development

The same prototype usually cannot meet all objectives. If the objectives are left
unstated, management or end-users may misunderstand the function of the prototype.
Consequently, they may not get the benefits that they expected from the prototype
development.

Figure 2.6: Prototyping model of software development.

- 43 -
 The second stage is to decide what to put into and, more importantly, what to leave
out of the prototype system. To reduce prototyping costs and accelerate the delivery
schedule, you may leave some functionality out of the prototype. If the objective of the
prototype is to establish a user interface, Error handling and management may be ignored
and non-functional requirements such as response time and memory utilization are relaxed.
Standards of reliability and program quality may be reduced. Then develop the software
prototype as it is targeted.
The final stage of the process is prototype evaluation. Provision must be made
during this stage for user training, and the prototype objectives should be used to derive a
plan for evaluation. Potential users need time to become comfortable with a new system
and to settle into a normal pattern of usage. Once they are using the system normally, they
then discover requirements errors and omissions. A general problem with prototyping is
that users may not use the prototype in the same way as they use the final system.
Prototype testers may not be typical of system users. There may not be enough time to train
users during prototype evaluation. If the prototype is slow, the evaluators may adjust their
way of working and avoid those system features that have slow response times. When
provided with better response in the final system, they may use it in a different way.

Figure 2.6: Prototyping model of software development.

- 44 -
3.1.2 Iterative Development
Once the customer approves the prototype, the actual software is developed using
the iterative waterfall approach, shown in figure 2.6. In spite of the availability of a working
prototype, the SRS document is usually needed to be developed since the SRS document is
invaluable for carrying out traceability analysis, verification, and test case design during
later phases. However, for GUI parts, the requirements analysis and specification phase
becomes redundant since the working prototype that has been approved by the customer
serves as an animated requirements specification. The code for the prototype is usually
thrown away. However, the experience gathered from developing the prototype helps a great
deal in developing the actual system.

3.1.3 Advantages of Prototyping

By constructing the prototype and submitting it for user evaluation, many customer
requirements get properly defined and technical issues get resolved by experimenting with
the prototype. This minimizes later change requests from the customer and the associated
redesign costs. Prototype improved system usability and it becomes a closer match to users’
real needs. It can improve design quality, maintainability and reduced development effort.

3.1.4 Two major problems with prototyping:

• Misuse to avoid proper analysis and design, and never completing prototypes as
proper applications.
• The system might never get formalized. Details of processing, for instance, data
validation and audit requirements, might be forgotten in the push to get a working
prototype into production.

3.2 The Spiral Model

The spiral model gets its name from the appearance of its diagrammatic representation that
looks like a spiral with many loops (see Figure 2.7). The exact number of loops of the spiral is not
fixed and can vary from project to project. The number of loops shown in Figure 2.7 is just an
example. Each loop of the spiral is called a phase of the software process. The exact number of
phases through which the product is developed can be varied by the project manager depending
upon the project risks. A prominent feature of the spiral model is handling unforeseen risks that
can show up much after the project has started. So, this model is also called “Risk Management
Model” with a risk-driven process model generator using prototyping as a risk reduction
mechanism.
The spiral model is an evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic aspects of the waterfall model. It
provides the potential for rapid development of increasingly more complete versions of the
software. This model contains the elements from all the other life cycle model along with the
necessary risks involves in each of the developmental phase.

- 45 -
 Using the spiral model, software is developed in a series of evolutionary releases. During
early iterations, the release might be a model or prototype. During later iterations, increasingly
more complete versions of the engineered system are produced.

3.2.1 Risk handling in Spiral Model

A risk is essentially any adverse condition that might hinder the successful
completion of a software project. Example, consider a project for which a risk can be that
data access from a remote database might be too slow to be acceptable by the customer. This
risk can be resolved by building a prototype of the data access subsystem and
experimenting with the exact access rate. If the data access rate is too slow, possibly a
caching scheme can be implemented or a faster communication scheme can be deployed to
overcome the slow data access rate. Such risk resolutions are easier done by using a
prototype because the pros and cons of an alternate solution scheme can evaluated faster and
inexpensively, as compared to experimenting using the actual software application being
developed.

Figure 2.7: Spiral model of software development.

The spiral model supports coping up with risks by providing the scope to build a
prototype at every phase of software development. For example, consider as shown in
figure 2.8, risk handling in the spiral model where the major risks were requirements,
design, and implementation.

- 46 -
 The first trip around the spiral builds the project requirements. The team
examines alternatives, identifies the largest risks (perhaps the customers’ performance
requirements are unclear), resolves the risks, and builds a prototype set of requirements.
Team members then use the prototype to analyze the requirements and verify that they are
correct. At that point, the verified requirements become the actual requirements.
The next trip around the spiral builds the application design. The team evaluates
design alternatives, identifies and resolves the major risks, and builds a prototype design.
Team members analyze the design and verify that it makes sense. The prototype design
then becomes the design.

Figure 2.8 Risk handling in the Spiral model for the major risks: requirements, design, and
implementation

The final trip around the spiral drives the application’s implementation. The
team evaluates implementation alternatives. They identify risks (perhaps previous projects
have had maintenance issues) and resolve them (they decide to have more code reviews).
The team then builds an operational prototype that shows how the program will work. They
use the prototype to verify that everything is on track, and then they actually build the
application. In this cycle, the implementation steps are broken down into detailed design,
programming, unit testing, integration testing, and acceptance testing.

- 47 -
3.2.2 Phases of the Spiral Model

Spiral software development is a spiral with many loops, shown in figure. The exact
number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the
software process. Each phase in this model is split into four sectors (or quadrants) and the
activities are carried out during each phase of a spiral model. In the first quadrant, a few
features of the software are identified to be taken up for immediate development based on
the overall software development. With each iteration around the spiral (beginning at the
center and moving outwards), progressively more complete versions of the software are
built. In other words, implementation of the identified features forms a phase.
• First quadrant (Objective Setting)
• During the first quadrant, identify the objectives of the phase.
• Examine the risks associated with these objectives.
• Alternative solutions possible for the phase are proposed.

• Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk to select the best
possible solution
• Then selected solutions are evaluated by developing an appropriate prototype. For
example, if there is a risk that the requirements are inappropriate, a prototype
system may be developed.

• Third Quadrant (Development and Validation)

• During the third quadrant, develop and validate the next level of the software
product after resolving the identified risks.
• At the end of the third quadrant, the identified features have been implemented
and the next version of the software is available.

• Fourth Quadrant (Review and Planning)

• Review the results achieved so far (i.e. the developed version of the software) with
the customer
• Plan the next iteration around the spiral.

The radius of the spiral at any point represents the cost incurred in the project so far,
and the angular dimension represents the progress made so far in the current phase. For
example, the innermost loop might be concerned with feasibility study. The next loop with
be requirements specification, the next one with design, and so on. Cost and schedule are
adjusted based on feedback derived from the customer after delivery. In the spiral model
of development, the project manager dynamically determines the number of phases as
the project progresses and adjusts the planned number of iterations required to complete the

- 48 -
software. Therefore, in this model, the project manager plays the crucial role of tuning
the model to specific objective.

3.2.3 Advantages/pros and Disadvantages/cons of the Spiral Model

The spiral model that restrict its use to a only a few types of projects. Since the
software risks need to be continually assessed as it is developed, risk-driven and is more
complicated phase structure than the other models we discussed, it would therefore be to
use, unless there are knowledgeable and experienced staff in the project. Also, it is not
very suitable for use in the development of outsourced projects.
In spite of the disadvantages of the spiral model that we pointed out, for projects
having many unknown risks that might show up as the development proceeds, the spiral
model would be the most appropriate development model to follow. All these risks are
resolved by building a prototype before the actual software development starts. In this
regard, it is much more powerful than the prototyping model.

Case study 2.2

Galaxy Inc. undertook the development of a satellite-based communication between
mobile handsets that can be anywhere on the earth. In contrast to the traditional cell
phones, by using a satellite-based mobile phone a call can be established as long as
both the source and destination phones are in the coverage areas of some base stations.
System Requirement:
The system would function through about six dozens of satellites orbiting the earth.
The satellites would directly pick up the signals from a handset and beam signal to the
destination handset. Since the foot prints of the revolving satellites would cover the
entire earth, communication between any two points on the earth, even between
remote places such as those in the Arctic ocean and Antarctica, would also be
possible.
Risks in the Projects:
However, the risks in the project are many, including determining how the calls
among the satellites can be handed-off when they are themselves revolving at a very
high speed. In the absence of any published material and availability of staff with
experience in development of similar products, many of the risks cannot be identified
at the start of the project and are likely to crop up as the project progresses. The
software would require several million lines of code to be written.
Sprial Development:
Galaxy Inc. decided to deploy the spiral model for software development after
hiring highly qualified staff. To speed up the software development, independent
parts of the software were developed through parallel cycles on the spiral. The cost
and delivery schedule were refined many times, as the project progressed. The project
was successfully completed after five years from start date.

- 49 -
4. The Unified Process Model

The Unified Process model is based on the object-oriented software development. It

combines the best features of each of the individual object-oriented analysis and design
methods and adopts additional features proposed by other experts in object-oriented
modeling. The result was UML—a unified modeling language that contains a robust
notation for the modeling and development of object-oriented systems. By 1997, UML
became a de-facto industry standard for object-oriented software development. The Unified
Process recognizes the importance of customer communication and streamlined methods for
describing the customer’s view of a system (the use case).

4.1 Phases of the UP Model

The Unified Process (UP) approach is an iterative and incremental development

framework. This model include four phases: the inception phase, the elaboration phase, the
construction phase the transition phase and two more phase after transition are the
production phase: the ongoing use of the software is monitored, support for the operating
environment and the disposal phase: remove the application and move users to a
replacement system.

(1) The inception phase:

• Both customer communication and planning activities are performed.
• Fundamental business requirements are described through a set of preliminary
use cases that describe which features and functions each major class of users
desires.
• Planning identifies resources, assesses major risks, defines a schedule, and
establishes a basis for the phases that are to be applied as the software increment
is developed.
(2) The elaboration phase
• Includes the communication and modeling activities of the generic process
model.
• Elaboration refines and expands the preliminary use cases into the
architectural model that include five different views of the software—the use
case model, the analysis model, the design model, the implementation model,
and the deployment model.
(3) The construction phase
• Using the architectural model as input, the construction phase develops or
acquires the software components that will make each use case operational for
end users.
• All required features and functions for the software increment are implemented
in source code and construct the final version of the software increment. In

- 50 -
 additions unit tests are designed and executed for each component and
integration testing are conducted. Use cases are used to derive a suite of
acceptance tests.
(4) The transition phase
• Software increment is given to end users for beta testing, and user feedback
reports both defects and necessary changes.
• The user manuals, troubleshooting guides, installation procedures for the release
software increment are created by the software team.
• At end of this phase, the software increment becomes a usable software
release.
(5) The production phase
• During this phase, the ongoing use of the software is monitored, support for the
operating environment (infrastructure) is provided, and defect reports and
requests for changes are submitted and evaluated.

Figure 2.9 shows the Unified Process, where construction takes more time and
effort than the other phases. The resources represent (mostly the number of people in the
development team) required for that phase. Time represents the amount of time spent on that
phase. It should be noted that not every task identified for a UP workflow is conducted for
every software project. The team adapts the process (actions, tasks, subtasks, and work
products) to meet its needs.

Figure 2.9 The Unified Process Model

It is likely that the five UP phases do not occur in a sequence, but phases are done in
concurrency. This means the construction, transition, and production phases are being
conducted at the same time for the next software increment. In figure 2.10, the project had
three elaboration iterations, four construction iterations, and two transition phases are
conducted in parallel. The Unified Process, the amounts of different kinds of work grow and
shrink during different project phases.

- 51 -
 Figure 2.10 The Unified Process Model Phases and Iterations

4.2 Advantages/pros and Disadvantages/cons of the Unified Process Model

Like the spiral approach, the Unified Process approach is most useful with large
high‐risk projects and projects with uncertain or changeable requirements.
The iterative approach to the elaboration, construction, and transition phases enables
to incrementally define the requirements and assemble the application. The elaboration
iterations focus on risks and risk mitigation to improve the project’s chance of success. The
inception and elaboration phases generate a lot of documentation that can help new
developers join the team later.
The Unified Process is complicated, it often requires more resources than simpler
approaches. Risk analysis can be difficult. It doesn’t work well with small projects. You
could end up spending more time on inception and elaboration than you’d need to build the
entire application with a simpler approach.

5. Comparison of different Software Process Models

(1) The Waterfall Model

 The waterfall model can be considered as the basic model and all other life cycle
models are add-ons of this model.
 But it cannot be used in practical development projects, since this model supports
no mechanism to handle the changes during any of the phases. This problem is
overcome by the iterative waterfall model through the provision of feedback
paths.

- 52 -
  However, this iterative model is suitable only for well-understood problems; such
as embedded systems, critical systems and large systems developed by several
companies.
 It is not suitable for very large projects and for projects that are subject to change
and have many risks.

(2) Incremental Process Model

 This model is suitable for large problems which can be decomposed into a set of
different modules for incremental development and delivery of the product.
 This model can only be used if the incremental delivery of the system is
acceptable to the customer.
 It reduces the customer’s shock 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.
 This model is also widely used for object-oriented development projects.

(3) Evolutional Process Model

1) Prototyping Model
• The prototyping model is suitable for projects for which either the user
requirements or the underlying technical aspects are not well understood.
2) Spiral Model
• 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.

(4) The Unified Process Model

 Like the spiral approach, the Unified Process approach is most useful with large
high‐risk projects and projects with uncertain or changeable requirements.
 Quality documentation is emphasized. This model is used for object-oriented
development projects. There is continuous customer involvement.
 It accommodates requirements changes. It works well for maintenance projects.

6. Selecting an Appropriate Software Process Model for a Project

Select a suitable life cycle model for a specific project would depend on several
factors based on an analysis of issues such as the following:

- 53 -
(1) Characteristics of the software to be developed:
The choice of the life cycle model to a large extent depends on the nature of the software
that is being developed. For small services projects, the agile model (discuss later) is
favoured. On the other hand, for product and embedded software development, the
iterative waterfall model can be preferred. An evolutionary model is a suitable model for
object-oriented development projects.

(2) Characteristics of the development team:

The skill-level of the team members is a significant factor in deciding about the life
cycle model to use. If the development team is experienced in developing similar
software, then even an embedded software can be developed using an iterative waterfall
model. If the development team is entirely novice, then even a simple data processing
application may require a prototyping model to be adopted.

(3) Characteristics of the customer:

If the customer is not quite familiar with computers, then the requirements are likely to
change frequently as it would be difficult to form complete, consistent, and
unambiguous requirements. Thus, a prototyping model may be necessary to reduce later
change requests from the customers.

6.1 Example: Selecting an Appropriate Software Process for project

Suggest the most appropriate generic software process model that might be used as a basis
for managing the development of the following systems. Explain your answer according to
the type of system being developed:
(1) A system to control antilock braking in a car
(2) A virtual reality system to support software maintenance
(3) A university accounting system that replaces an existing system
(4) An interactive travel planning system that helps users plan journeys with the lowest
environmental impact

Solution:

(1) A system to control antilock braking in a car

• This is an “Anti-lock braking system” so that it is a type of safety-critical system
that requires a lot of up-front analysis before implementation.
• Therefore it certainly needs a plan-driven approach to development with the
requirements carefully analyzed.
• So that “the classical water fall model” is the most appropriate approach with to
use, sometime with formal transformations between the different development
stages.

- 54 -
(2) A virtual reality system to support software maintenance
• This is a “virtual reality system” that system requirements will change and there
will be an extensive user interface components.
• Therefore “Incremental development model with some UI (user interface)
prototyping” is the most appropriate model.
• An agile process may be used.

(3) A university accounting system that replaces an existing system

• This is a “university accounting system” that system requirements are fairly well-
known and the system will be used in an environment in conjunction with losts of
other system such as a research grant management system.
• Therefore “a reuse-based approach” is likely to be appropriate.

(4) An interactive travel planning system that helps users plan journeys with the lowest
environmental impact
• This is an “interactive travel planning system” that system requirements will
change and there will be a complex user interface.
• Therefore “Incremental development model with some UI (user interface)
prototyping” is the most appropriate model.
• An agile process may be used as real user experience with the system is required.

SUMMARY
In this lecture, three software development models have been introduced.
Incremental model, first a simple working system implementing only a few basic features is
built and delivered to the customer. Over much successive iteration, successive versions are
implemented and delivered to the customer until the desired system is realized.
Prototyping lets you study pieces of an application so that you can make adjustments.
Models such as spiral and Unified Process use iteration to help the development and
requirements eventually meet. Some of those models also place an emphasis on risk
management to reduce the chances of the project failing.
In addition to keeping a project heading in the right direction, iterative and incremental
methods allow you to release partial implementations of the application if they are useful.
The next lecture describes other techniques that give the users partial functionality as soon
as possible.

*********************************************************************************

Exercises
(1) Which life cycle model would you follow for developing software for each of the
following applications? Mention the reasons behind your choice of a particular life cycle
model.
(a) A well-understood data processing application.

- 55 -
 (b) A new software that would connect computers through satellite communication.
Assume that your team has no previous experience in developing satellite
communication software.
(c) A software that would function as the controller of a telephone switching system.
(d) A new library automation software that would link various libraries in the city.
(e) An extremely large software that would provide, monitor, and control cellular
communication among its subscribers using a set of revolving satellites.
(f ) A new text editor.
(g) A compiler for a new language.
(h) An object-oriented software development effort.
(i) The graphical user interface part of a large software.
(2) Incremental software development could be very effectively used for customers who do
not have a clear idea about the systems needed for their operations. Discuss.
(3) With respect to the prototyping model for software development, answer the following:
(a) What is a prototype?
(b) Is it necessary to develop a prototype for all types of projects?
(c) If you answer to part (b) of the question is no, then mention under what
circumstances is it beneficial to construct a prototype.
(d) If your answer to part (b) of the question is yes, then explain does construction of a
prototype always increase the overall cost of software development.
(4) If the prototyping model is being used in a development project of moderate size, is it
necessary to develop an SRS document? Justify your answer.
(5) Consider that a software development project that is beset with many risks. But, assume
that it is not possible to anticipate all the risks in the project at the start of the project and
some of the risks can only be identified much after the development is underway. As the
project manager recommend the use of the prototyping or the spiral model? Explain
your answer.
(6) What are the major advantages of first constructing a working prototype before starting
to develop the actual software? What are the disadvantages of this approach?
(7) Explain how a software development effort is initiated and finally terminated in the
spiral model.
(8) Suppose a travel agency needs a software for automating its bookkeeping activities. The
set of activities to be automated are rather simple and are at present being carried out
manually. The travel agency has indicated that it is unsure about the type of user
interface which would be suitable for its employees and its customers. Would it be
proper for a development team to use the spiral model for developing this software?
(9) Briefly discuss the evolutionary process model. Explain using suitable examples the
types of software development projects for which the evolutionary life cycle model is
suitable. Compare the advantages and disadvantages of this model with the iterative
waterfall model.
(10) Imagine that a government wants a software program that helps to keep track of the
utilization of the country’s vast mineral resources. Although the requirements put
forward by the government were not very clear, a software company was tasked with
the development of a prototype. The government found the prototype impressive, and

- 56 -
 asked it be extended to be the actual system that would be used. Discuss the pros and
cons of taking this approach.
(11) You have developed a prototype of a software system and your manager is very
impressed by it. She proposes that it should be put into use as a production system,
with new features added as required. This avoids the expense of system development
and makes the system immediately useful. Write a short report for your manager
explaining why prototype systems should not normally be used as production systems.

********************* End of lecture 2 **************************

The more that you read, the more things you will know.
The more that you learn, the more places you will go.
Dr. Sesus

- 57 -