Chapter 2 – Processes and Models

Lesson 2
SOFTWARE MODELS

Objectives:
At the end of this chapter you should be able to:

• Describe various process models, such as the waterfall and prototyping models, in depth.
• Explain the difference between prescriptive and agile process models.
• Describe the main components of CASE tools, and how they can address system development
problems.

Readings:
Software models
The framework just presented provides a list of generic activities common to most models of the
software process. However, each model treats the activities differently, and each model is suitable for
different projects and for different teams.

It is important to realize that the activities outlined in the process models given below should be
modified, based on:

• The problem having to be solved.

• The characteristics of the project.
• The nature of the development team.
• The organizational culture.

Prescriptive and agile models

Prescriptive software models are those which prescribe the components which make up a software
model, including the activities, the inputs and outputs of the activities, how quality assurance is
performed, how change is managed, and so on. A prescriptive model also describes how each of these
elements are related to one another (note that in this sense, “prescriptive” is not meant to indicate that
these methods admit no modification to them, as we previously used the word).

On the other hand, agile software models have a heavy focus on change in the software engineering
process. Agile methods note that not only do the software requirements change, but so do team
members, the technology being used, and so on. We will discuss agile methods later in this chapter.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 1

Prescriptive software models
The waterfall life cycle model

The waterfall model was the first, and for a time, the only process model. This model is also known as
the “traditional” or “typical” software life cycle.

Note

Some writers use the acronym TLC, standing for “Traditional Life Cycle”. In this module we will refer to
this software model as the “waterfall” model. This model is sometimes also called the “linear
sequential” model.

The features of the waterfall model are as follows:

• The system development process is broken into distinct stages.

• Each stage involves a particular project activity — such as “communication” or “construction”.
• Each stage, when completed, results in a deliverable (also called a product).
• The input to any particular stage are the deliverables from the previous stage.
• The model presents the stages in a strict, one-way sequence — a project cannot go back to
repeat a stage once that stage has been completed. Any required re-work (as a result, for
example, of changing software requirements) is very limited.

The name “waterfall” comes from likening this method to a river cascading over a series of waterfalls:
the river is the output from each stage; the output from one stage is the input to another, in strict-
sequence, and at no point do the stages reverse; a project cannot go back to a stage that has previously
been completed.

Figure 2.4. The waterfall method

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 2

Each stage of the waterfall method flows into another. Stages do not flow backwards through the
model.

There are some slight differences in the way the waterfall model is presented between different books,
however these differences are usually related to the number and names of the stages. Any presentation
of the waterfall model will present a very similar sequence of stages to the following:

• Communication
• Planning
• Modelling
• Construction
• Deployment

There are a number of advantages to the waterfall model:

• The stages consist of well-defined tasks which promotes good scheduling and cost estimation
(if all stages occur in the expected sequence once only).
• The deliverables provide targets or milestones to see how far a team has reached in the
development process.
• The life cycle is broken into well-defined stages — so staff expertise can be used efficiently
(e.g., a data modeler only needs to work on certain stages, a programmer only on other stages,
and so on).
• At any one time the project team knows what should be happening and the deliverable(s) they
are to produce.

However, there are also a number of major limitations of the waterfall model, which occur frequently
in software development:

• It is rare that a software development project will follow the sequential process that the waterfall
model uses.
• Although the requirements are specified early on, user understanding and feedback of the
software will not occur until after the system is implemented, which is possibly too late (or very
costly) to change.
• The user may not be able to describe the requirements of the desired system in any detail early
on.
• The model does not easily allow for the anticipation of change — some systems take years to
develop, but once the early stages have been completed the model commits the project to a
fixed specification of the system.
• Many projects based on the waterfall model stress the importance of certain products
(documents) being delivered at certain times — it is possible for a project to become managed
in a bureaucratic way, with documents being delivered on schedule, but the focus drifting away
from developing a usable, effective system for the users.
• If a problem is identified at a later stage, the model does not make it easy (or cheap) to return
to an earlier stage to rectify the mistake (since all intermediate steps will need to be repeated,
resulting in significant, unplanned, time and resource costs).

For many development projects, the limitations of the waterfall model are usually considered to far
outweigh its advantages.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 3

RAD (Rapid Application Development) Model
RAD is a linear sequential software development process model that emphasizes a concise development
cycle using an element-based construction approach. If the requirements are well understood and
described, and the project scope is a constraint, the RAD process enables a development team to create
a fully functional system within a concise time period.

RAD (Rapid Application Development) is a concept that products can be developed faster and of higher
quality through:

o Gathering requirements using workshops or focus groups

o Prototyping and early, reiterative user testing of designs
o The re-use of software components
o A rigidly paced schedule that refers design improvements to the next product version
o Less formality in reviews and other team communication

The various phases of RAD are as follows:

1.Business Modelling: The information flow among business functions is defined by answering
questions like what data drives the business process, what data is generated, who generates it, where
does the information go, who process it and so on.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 4

2. Data Modelling: The data collected from business modeling is refined into a set of data objects
(entities) that are needed to support the business. The attributes (character of each entity) are
identified, and the relation between these data objects (entities) is defined.

3. Process Modelling: The information object defined in the data modeling phase are transformed to
achieve the data flow necessary to implement a business function. Processing descriptions are created
for adding, modifying, deleting, or retrieving a data object.

4. Application Generation: Automated tools are used to facilitate construction of the software; even
they use the 4th GL techniques.

5. Testing & Turnover: Many of the programming components have already been tested since RAD
emphasis reuse. This reduces the overall testing time. But the new part must be tested, and all
interfaces must be fully exercised.

When to use RAD Model?

o When the system should need to create the project that modularizes in a short span time (2-3
months).
o When the requirements are well-known.
o When the technical risk is limited.
o When there's a necessity to make a system, which modularized in 2-3 months of period.
o It should be used only if the budget allows the use of automatic code generating tools.

Advantage of RAD Model

o This model is flexible for change.

o In this model, changes are adoptable.
o Each phase in RAD brings highest priority functionality to the customer.
o It reduced development time.
o It increases the reusability of features.

Disadvantage of RAD Model

o It required highly skilled designers.

o All application is not compatible with RAD.
o For smaller projects, we cannot use the RAD model.
o On the high technical risk, it's not suitable.
o Required user involvement.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 5

Spiral Model

The spiral model, initially proposed by Boehm, is an evolutionary software process model that
couples the iterative feature of prototyping with the controlled and systematic aspects of the linear
sequential model. It implements the potential for rapid development of new versions of the software.
Using the spiral model, the software is developed in a series of incremental releases. During the
early iterations, the additional release may be a paper model or prototype. During later iterations,
more and more complete versions of the engineered system are produced.

The Spiral Model is shown in figure below:

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle,
the various alternatives that are possible for achieving the targets, and the constraints that exists.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 6

Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is located on
the risk perception for the project.

Development and validation: The next phase is to develop strategies that resolve uncertainties
and risks. This process may include activities such as benchmarking, simulation, and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice made whether to
continue with a further period of the spiral. If it is determined to keep, plans are drawn up for the
next step of the project.

The development phase depends on the remaining risks. For example, if performance or user-
interface risks are treated more essential than the program development risks, the next phase may
be an evolutionary development that includes developing a more detailed prototype for solving the
risks.

The risk-driven feature of the spiral model allows it to accommodate any mixture of a specification-
oriented, prototype-oriented, simulation-oriented, or another type of approach. An essential element
of the model is that each period of the spiral is completed by a review that includes all the products
developed during that cycle, including plans for the next cycle. The spiral model works for
development as well as enhancement projects.

When to use Spiral Model?

o When deliverance is required to be frequent.

o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

Advantages

o High amount of risk analysis

o Useful for large and mission-critical projects.

Disadvantages

o Can be a costly model to use.

o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.
ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 7
V-Model

V-Model also referred to as the Verification and Validation Model. In this, each phase of SDLC must
complete before the next phase starts. It follows a sequential design process same as the waterfall
model. Testing of the device is planned in parallel with a corresponding stage of development.

Verification: It involves a static analysis method (review) done without executing code. It is the
process of evaluation of the product development process to find whether specified requirements meet.

Validation: It involves dynamic analysis method (functional, non-functional), testing is done by

executing code. Validation is the process to classify the software after the completion of the
development process to determine whether the software meets the customer expectations and
requirements.

So, V-Model contains Verification phases on one side of the Validation phases on the other side.
Verification and Validation process is joined by coding phase in V-shape. Thus, it is known as V-Model.

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where product requirements
understood from the customer's side. This phase contains detailed communication to
understand customer's expectations and exact requirements.
2. System Design: In this stage system engineers analyze and interpret the business of the
proposed system by studying the user requirements document.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 8

 3. Architecture Design: The baseline in selecting the architecture is that it should understand
all which typically consists of the list of modules, brief functionality of each module, their
interface relationships, dependencies, database tables, architecture diagrams, technology detail,
etc. The integration testing model is carried out in a particular phase.
4. Module Design: In the module design phase, the system breaks down into small modules.
The detailed design of the modules is specified, which is known as Low-Level Design
5. Coding Phase: After designing, the coding phase is started. Based on the requirements, a
suitable programming language is decided. There are some guidelines and standards for coding.
Before checking in the repository, the final build is optimized for better performance, and the
code goes through many code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design
phase. These UTPs are executed to eliminate errors at code level or unit level. A unit is the
smallest entity which can independently exist, e.g., a program module. Unit testing verifies that
the smallest entity can function correctly when isolated from the rest of the codes/ units.
2. Integration Testing: Integration Test Plans are developed during the Architectural Design
Phase. These tests verify that groups created and tested independently can coexist and
communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit
and Integration Test Plans, System Tests Plans are composed by the client?s business team.
System Test ensures that expectations from an application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement analysis part.
It includes testing the software product in user atmosphere. Acceptance tests reveal the
compatibility problems with the different systems, which is available within the user atmosphere.
It conjointly discovers the non-functional problems like load and performance defects within the
real user atmosphere.

When to use V-Model?

o When the requirement is well defined and not ambiguous.

o The V-shaped model should be used for small to medium-sized projects where requirements
are clearly defined and fixed.
o The V-shaped model should be chosen when sample technical resources are available with
essential technical expertise.

Advantage (Pros) of V-Model:

1. Easy to Understand.
2. Testing Methods like planning, test designing happens well before coding.
ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 9
 3. This saves a lot of time. Hence a higher chance of success over the waterfall model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.

Disadvantage (Cons) of V-Model:

1. Very rigid and least flexible.

2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early prototypes of the software
are produced.
4. If any changes happen in the midway, then the test documents along with the required
documents, has to be updated.

Incremental Model

Incremental Model is a process of software development where requirements divided into multiple
standalone modules of the software development cycle. In this model, each module goes through
the requirements, design, implementation and testing phases. Every subsequent release of the
module adds function to the previous release. The process continues until the complete system
achieved.

The various phases of incremental model are as follows:

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 10

1. Requirement analysis: In the first phase of the incremental model, the product analysis
expertise identifies the requirements. And the system functional requirements are understood by
the requirement analysis team. To develop the software under the incremental model, this phase
performs a crucial role.

2. Design & Development: In this phase of the Incremental model of SDLC, the design of the
system functionality and the development method are finished with success. When software
develops new practicality, the incremental model uses style and development phase.

3. Testing: In the incremental model, the testing phase checks the performance of each existing
function as well as additional functionality. In the testing phase, the various methods are used to
test the behavior of each task.

4. Implementation: Implementation phase enables the coding phase of the development system.
It involves the final coding that design in the designing and development phase and tests the
functionality in the testing phase. After completion of this phase, the number of the product working
is enhanced and upgraded up to the final system product

When we use the Incremental Model?

o When the requirements are superior.

o A project has a lengthy development schedule.
o When Software team are not very well skilled or trained.
o When the customer demands a quick release of the product.
o You can develop prioritized requirements first.

Advantage of Incremental Model

o Errors are easy to be recognized.

o Easier to test and debug
o More flexible.
o Simple to manage risk because it handled during its iteration.
o The Client gets important functionality early.

Disadvantage of Incremental Model

o Need for good planning

o Total Cost is high.
o Well defined module interfaces are needed.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 11

Agile Model

The meaning of Agile is swift or versatile. "Agile process model" refers to a software development
approach based on iterative development. Agile methods break tasks into smaller iterations, or parts
do not directly involve long term planning. The project scope and requirements are laid down at the
beginning of the development process. Plans regarding the number of iterations, the duration and the
scope of each iteration are clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model, which typically lasts
from one to four weeks. The division of the entire project into smaller parts helps to minimize the
project risk and to reduce the overall project delivery time requirements. Each iteration involves a team
working through a full software development life cycle including planning, requirements analysis,
design, coding, and testing before a working product is demonstrated to the client.

Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 12

1. Requirements gathering: In this phase, you must define the requirements. You should explain
business opportunities and plan the time and effort needed to build the project. Based on this
information, you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with stakeholders to define
requirements. You can use the user flow diagram or the high-level UML diagram to show the work of
new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins. Designers
and developers start working on their project, which aims to deploy a working product. The product
will undergo various stages of improvement, so it includes simple, minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance and looks
for the bug.

5. Deployment: In this phase, the team issues a product for the user's work environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team receives feedback
about the product and works through the feedback.

Agile Testing Methods:

o Scrum
o Crystal
o Dynamic Software Development Method (DSDM)
o Feature Driven Development (FDD)
o Lean Software Development
o eXtreme Programming (XP)

Scrum

SCRUM is an agile development process focused primarily on ways to manage tasks in team-based
development conditions.

There are three roles in it, and their responsibilities are:

o Scrum Master: The scrum can set up the master team, arrange the meeting and remove
obstacles for the process
o Product owner: The product owner makes the product backlog, prioritizes the delay and is
responsible for the distribution of functionality on each repetition.
o Scrum Team: The team manages its work and organizes the work to complete the sprint or
cycle.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 13

eXtreme Programming (XP)

This type of methodology is used when customers are constantly changing demands or requirements,
or when they are not sure about the system's performance.

Crystal:

There are three concepts of this method-

1. Chartering: Multi activities are involved in this phase such as making a development team,
performing feasibility analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:
A. Team updates the release plan.
B. Integrated product delivers to the users.
3. Wrap up: According to the user environment, this phase performs deployment, post-
deployment.

Dynamic Software Development Method (DSDM):

DSDM is a rapid application development strategy for software development and gives an agile project
distribution structure. The essential features of DSDM are that users must be actively connected, and
teams have been given the right to make decisions. The techniques used in DSDM are:

1. Time Boxing
2. MoSCoW Rules
3. Prototyping

The DSDM project contains seven stages:

1. Pre-project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project

Feature Driven Development (FDD):

This method focuses on "Designing and Building" features. In contrast to other smart methods, FDD
describes the small steps of the work that should be obtained separately per function.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 14

Lean Software Development:

Lean software development methodology follows the principle "just in time production." The lean
method indicates the increasing speed of software development and reducing costs. Lean development
can be summarized in seven phases.

1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole

When to use the Agile Model?

o When frequent changes are required.

o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.

Advantage (Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.

Disadvantages (Cons) of Agile Model:

1. Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.
2. Due to the lack of proper documentation, once the project completes and the developers allotted
to another project, maintenance of the finished project can become a difficulty.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 15

Iterative Model

In this Model, you can start with some of the software specifications and develop the first version of
the software. After the first version if there is a need to change the software, then a new version of the
software is created with a new iteration. Every release of the Iterative Model finishes in an exact and
fixed period that is called iteration.

The Iterative Model allows the accessing earlier phases, in which the variations made respectively. The
final output of the project renewed at the end of the Software Development Life Cycle (SDLC) process.

The various phases of Iterative model are as follows:

1. Requirement gathering & analysis: In this phase, requirements are gathered from customers
and check by an analyst whether requirements will fulfil or not. Analyst checks that need will achieve
within budget or not. After all of this, the software team skips to the next phase.

2. Design: In the design phase, team design the software by the different diagrams like Data Flow
diagram, activity diagram, class diagram, state transition diagram, etc.

3. Implementation: In the implementation, requirements are written in the coding language and
transformed into computer programs which are called Software.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 16

4. Testing: After completing the coding phase, software testing starts using different test methods.
There are many test methods, but the most common are white box, black box, and grey box test
methods.

5. Deployment: After completing all the phases, software is deployed to its work environment.

6. Review: In this phase, after the product deployment, review phase is performed to check the
behavior and validity of the developed product. And if there are any error found then the process starts
again from the requirement gathering.

7. Maintenance: In the maintenance phase, after deployment of the software in the working
environment there may be some bugs, some errors or new updates are required. Maintenance involves
debugging and new addition options.

When to use the Iterative Model?

1. When requirements are defined clearly and easy to understand.

2. When the software application is large.
3. When there is a requirement of changes in future.

Advantage (Pros) of Iterative Model:

1. Testing and debugging during smaller iteration is easy.

2. A Parallel development can plan.
3. It is easily acceptable to ever-changing needs of the project.
4. Risks are identified and resolved during iteration.
5. Limited time spent on documentation and extra time on designing.

Disadvantage (Cons) of Iterative Model:

1. It is not suitable for smaller projects.

2. More Resources may be required.
3. Design can be changed again and again because of imperfect requirements.
4. Requirement changes can cause over budget.
5. Project completion date not confirmed because of changing requirements.

Evolutionary Process Model

Evolutionary model is a combination of Iterative and Incremental model of software development
life cycle. Delivering your system in a big bang release, delivering it in incremental process over time
is the action done in this model. Some initial requirements and architecture envisioning need to be
done.
ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 17
It is better for software products that have their feature sets redefined during development because of
user feedback and other factors. The Evolutionary development model divides the development cycle
into smaller, incremental waterfall models in which users are able to get access to the product at the
end of each cycle.
Feedback is provided by the users on the product for the planning stage of the next cycle and the
development team responds, often by changing the product, plan or process. Therefore, the software
product evolves with time. All the models have the disadvantage that the duration of time from start of
the project to the delivery time of a solution is very high. Evolutionary model solves this problem in a
different approach.

Evolutionary model suggests breaking down of work into smaller chunks, prioritizing them and then
delivering those chunks to the customer one by one. The number of chunks is huge and is the number
of deliveries made to the customer. The main advantage is that the customer’s confidence increases as
he constantly gets quantifiable goods or services from the beginning of the project to verify and validate
his requirements. The model allows for changing requirements as well as all work in broken down into
maintainable work chunks.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 18

Application of Evolutionary Model:
1. It is used in large projects where you can easily find modules for incremental implementation.
Evolutionary model is commonly used when the customer wants to start using the core features
instead of waiting for the full software.
2. Evolutionary model is also used in object-oriented software development because the system
can be easily portioned into units in terms of objects.

Advantages:
• In evolutionary model, a user gets a chance to experiment partially developed system.
• It reduces the error because the core modules get tested thoroughly.

Disadvantages:
• Sometimes it is hard to divide the problem into several versions that would be acceptable to the
customer which can be incrementally implemented and delivered.

Prototyping life cycle model

A prototype system is a smaller version of part(s) of the final system that gives the user a sense of the
finished system's functionality. It has some of the core features of the final system and, where features
and functions are omitted, it pretends to behave like the final system. Prototypes are typically developed
quickly, may lack unnecessary features, may be buggy, and have poor usability. However, prototypes
can fill an important role in understanding software which does not have clear requirements.

Once the developers and users have a clear idea of the software's requirements, the project can move
into another development life-cycle, and the prototypes are thrown away. This is important, since as
we previously mentioned, the prototypes are generated quickly and are not designed to be robust or
complete.

To prototype quickly and effectively, fourth generation languages (4GLs), graphical user-interface (GUI)
tools (like those that come with Visual Studio, QT and GTK), and off-the-shelf components are
commonly used. The quality of the prototype is only of concern where it would hinder the prototype's
use in understanding the final software being developed. If the prototype is usable enough to meet the
objectives put forward for its development, the prototype has been successful.

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 19

Figure 2.6. Disposable prototyping

As can be seen, after some initial analysis a set of objectives is developed for the prototype. These
objectives may differ between projects — perhaps detailed requirements need to be elicited, perhaps
alternative user interactions are to be evaluated and so on. Each version of the prototype should be
specified so that the software can be correctly designed and implemented — a prototype that does not
ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 20
fully test the objectives is a waste of resources, and may be misleading. Once a prototype has been
completed it should be evaluated against its objectives. The evaluation decides whether the prototype
should be extended, a new prototype developed, or — if the specified objectives are met — if the
project can move on to develop the software using another process model.

Advantages of prototyping include:

• Users get an early idea of the final system features.

• The prototype provides an opportunity to identify problems early and to change the
requirements appropriately.
• The prototype is a model that all users and customers should be able to understand and provide
feedback on, thus the prototype can be an important tool to improve communication between
users and developers.
• It may be possible to use aspects of the prototype specification and design in the final system
specification and design, thus some of the prototype development resources can be recouped.

A major problem with developing “disposable” prototypes is that the customer may believe it to be the
final product. Customers may not understand the need to re-engineer the software and restart
development, and may ask that the prototype be “cleaned up” and released to them.

The Unified Process

This unified process is also known as the Rational Unified Process (RUP), after the Rational Corporation
who helped in the model's development. The Rational Corporation also develops CASE tools to support
the use of the model.

The unified process is a unification of the various early object-oriented analysis and design models
proposed in the 80s and 90s. It is an attempt to combine the best features of these various models
which initially resulted in the unified modelling language (UML). The UML has become the standard
diagrammatic language for modelling object-oriented software.

While the UML provides a modelling framework for developing object-oriented software, it does not
provide any process model. This led to the development of the unified process, which is a process
model for developing object-oriented software, and uses the UML as its modelling language.

The unified process is an incremental software process that is architecture driven, focuses on mitigating
risk, and drives development through using use cases. Being architecture-driven, early iterations focus
on building the portions of the software that will define the software's overall architecture. Focusing on
risk, early iterations also focus on developing the high-risk portions of the software. Software
development iterations moves through five phases: inception, elaboration, construction, transition and
production. These phases cannot be directly mapped on to the generic process framework activities:
rather, each iteration contains some of the framework activities.

The inception phase is concerned with project feasibility: what should the software do, in broad terms
rather than specifics, and what are the high-risk areas? Should the development go ahead? Inception
is usually a short phase, often having no more than one iteration. Little development usually occurs
during the inception phase, but the software requirements are discovered using use cases

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 21

(communication), and a small subset of these requirements (those with high risk, and which focus on
the software architecture) are fleshed out (communication and planning).

Programming begins during the iterations of the Elaboration phase. Each iteration develops the
requirements fleshed out in the previous iterations (modelling and construction), and chooses more
requirements to flesh out (communication and planning) for development in the next iteration. The
elaboration phase completes once all of the requirements have been fleshed out. However, this does
not mean that communication and planning activities stop and do not occur in later phases: there is
always constant communication with the customer and an understanding that requirements may
change.

Much of the construction activity occurs in the iterations of the construction phase. While the iterations
of the elaboration phase each had at least one meeting in which some use cases are fleshed-out and
selected for development in the next iteration, all the use cases have already been fleshed out when
the construction phase begins.

The transition phase contains the initial portions of the deployment activity: the software is given to
the customer for evaluation (called beta testing). The customer's feedback will cause the software to
be modified as required, and thus the transition phase includes some communication and construction
activities. The production phase includes the final portion of the deployment activity: the software is
now being used by the customer, and is monitored and supported by the software engineer.

The transition phase employs a technique called beta testing. Beta testing occurs when the software
is given to the user to allow them to use the software and uncover any defects and deficiencies. There
should be a formal communications framework for the customer to report their findings to the
developers, and for the developers to assess these reports and to determine how to proceed.

Self – Check Questionnaire 2

How well did you remember what you read? Answer the following questions briefly:

1. What is a life cycle model?

2. What are the activities of the generic software process?
3. What features of the waterfall life cycle model separate it from other models?
4. Describe the disadvantages of the waterfall model.
5. What are the main features of the prototyping life cycle model?
6. What are the points of the Agile Manifesto?

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 22