Software Development Models U4 PDF

UNIT 3 A
Analysis techniques
Unit 4
TCC 125/05
Software Development
Models
Development Models
B WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models
COURSE TEAM
Course Team Coordinator: Ms. Azrina P. Jamal Mydin
Content Writer: Ms. Siti Sarah bt. Md. Rahim
Instructional Designer: Mr. Khoo Chiew Keen
Academic Member: Mr. Chandarasegaran Natarajan
COURSE COORDINATOR
Ms. Azrina P. Jamal Mydin
EXTERNAL COURSE ASSESSOR

Associate Professor Masrah Azrifah, Universiti Putra Malaysia
PRODUCTION
In-house Editor: Mr. Khoo Chiew Keen
Graphic Designer: Ms. Valerie Ooi
Wawasan Open University is Malaysias first private not-for-profit tertiary institution dedicated to
adult learners. It is funded by the Wawasan Education Foundation, a tax-exempt entity established
by the Malaysian Peoples Movement Party (Gerakan) and supported by the Yeap Chor Ee Charitable
and Endowment Trusts, other charities, corporations, members of the public and occasional grants
from the Government of Malaysia.
The course material development of the university is funded by Yeap Chor Ee Charitable and
Endowment Trusts.
2012 Wawasan Open University

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or
transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or
otherwise, without prior written permission from WOU.
Wawasan Open University

(KPT/JPT/DFT/US/P01)
Wholly owned by Wawasan Open University Sdn. Bhd. (700364-W)
54, Jalan Sultan Ahmad Shah, 10050 Penang.

Tel: (604) 2180333 Fax: (604) 2279214
Email: enquiry@wou.edu.my
Website: www.wou.edu.my
UNIT 4 C
Development models
Contents
Unit 4 Development Models
Unit overview
Unit objectives
4.1 System development life cycle
Objectives
Introduction
Understanding system development life cycle
Key aspects of system development life cycle
4.2 Objected-oriented analysis and design
13
Objectives
13
Introduction
13
Understanding object-oriented analysis and design
13
Object-oriented analysis
14
Object-oriented design
17
4.3 Agile distributed development method
23
Objectives
23
Introduction
23
An agile view of process
23
Extreme programming
25
Scrum
27
D WAWASAN OPEN UNIVERSITY

4.4 Component-based software engineering
31
Objectives
31
Introduction
31
Understanding component-based software

engineering
31
Component-based software engineering process
33
Component-based software engineering for reuse
34
Component-based software engineering with reuse
35
Component composition
36
Suggested answers to activity
39
4.5 Spiral model and others
41
Objectives
41
Introduction
41
Overview of spiral model
41
The spiral model process
43
Concurrent development model
44
The component assembly model
46
50
4.6 Prototyping model
51
Objectives
51
Introduction
51
The prototyping model approach
51
Steps in prototyping model
52
Limitation of prototyping model
54
UNIT 4 E
Development models
Advantages of prototyping model
55
57
4.7 Rapid application development model
59
Objectives
59
Introduction
59
Overview of rapid application development model
59
Process of rapid application development model
60
Suitability of rapid application development model
62
65
Summary of Unit 4
67
Suggested answers to self-tests
69
References
73
Glossary
75
F WAWASAN OPEN UNIVERSITY

UNIT 4 1
Development models
Unit Overview
his unit is organised into seven sections. The first section will introduce the system
development life cycle, which is a process of creating or altering information,
with the models and methodologies that people use to develop software. These
methodologies form the framework for planning and controlling the creation of an
information system.
Section 4.2 focuses on object-oriented analysis and design. This is one of the software
engineering approaches that models software as a group of interacting objects.
Each object represents some entity of interest in the system being modelled, and is
characterised by its class, state (data elements), and behaviour.
Section 4.3 will discuss agile distributed development model. This is based on
iterative and incremental development. It promotes adaptive planning, evolutionary
development and delivery, a time-boxed iterative approach, and encourages rapid
and flexible response to change.
Section 4.4 discusses the component-based software engineering. It is a reuse-based
approach to defining, implementing and composing loosely coupled independent
components into systems. This practice aims to bring about wide-ranging benefits
equally in both the short-term and the long-term for the software itself and for
organisations that sponsor such software.
In section 4.5, you will be exposed to spiral and other models related to software
engineering. The spiral model combines elements of both design and prototypingin-stages, in an effort to combine advantages of top-down and bottom-up concepts.
Other models will be Concurrent Development Model and the Component Assembly
Model.
Section 4.6 focuses on prototyping model. This model is built, tested, and then
reworked as necessary until an acceptable prototype is finally achieved from which
the complete system or product can now be developed. There are several steps that
will be learnt in this section.
Section 4.7 focuses on Rapid Application Development (RAD) model. This model
uses minimal planning in favour of rapid prototyping. There are several processes
in making this model and it will be covered in this section.
2 WAWASAN OPEN UNIVERSITY

Unit Objectives
By the end of Unit 4, you should be able to:
1. Explain the major phases in system development life cycle.
2. Determine the use of object-oriented analysis and design.
3. Differentiate between object-oriented analysis and object-oriented design.
4. Explain Agile Distributed Development process.
5. Describe the suitability of Agile Distributed Development Model.
6. Appraise the major processes of component-based software engineering.
7. Describe the model process of spiral model and others.
8. Describe the activities in prototyping model.
9. Explain the phases of rapid application development model.
UNIT 4 3
Development models
4.1 System Development Life Cycle

Objectives
By the end of this section, you should be able to:
1. Describe the system development life cycle.
2. Discuss the six stages of system development life cycle.
Introduction
Nowadays, it is increasingly necessary to have a large software development team
for a project since hardware and software systems become more complex. A method
that describes a system development that can be modelled is developed in order to
manage the teams effectively and maintain the overall progress.
The system development life cycle models the development of complex systems in
a few steps. Each steps of development led to the next with the output from the
earlier step being the input for the step which follows. We have broken this section
into two parts:
1. Understanding system development life cycle.
2. Key aspects of system development life cycle.
Understanding system development life cycle

Managing overall progress of a project can be hard without proper planning and
steps. Disarrangement of steps can lead to severe results. In order to prevent it, a
method was developed in which system development could be done easily. The system
development life cycle method has been thought to deliver a better development.
The software development team has been using system development life cycle models
as a process to develop training, information system and stakeholder ownership.
According to Taylor (2004), the project life cycle encompasses all the activities of
the project, while the systems development life cycle focuses on realising the product
requirements. During the development of a system, system development life cycle
describes the stages involved, from the drawing board all the way to the completion
of the project. To simplify it, we can say that system development life cycle is the
conceptual model that represents the stages involved in system development in
project management.
A number of system development life cycle models or methodologies have been
created to guide the processes involved including the waterfall model which is the
original system development life cycle method. Let us look at the other System

Development Life Cycle models as below:

1. Waterfall Model
2. Prototyping Model
3. Iterative Model
4. The spiral Model
5. Rapid Application Model
6. Object-oriented Model
7. Agile Distributed Development Methodologies
8. Component-based Software Engineering Method
Even though there are various kinds of system development life cycle methodologies
or models, all of them fit with the primary objectives of system development life
cycle related to business areas in order to:
1. Ensure the delivery of high quality development.
2. Provide efficient management control.
3. Enhance productivity.
Generally, we know that system development life cycle can help us to solve specific
needs in user requirement. But, there are also situations where system development
life cycle is not needed when developing a system. In-house developers that could
create software on their own and have a clear understanding of what is needed by
the user do not have to use system development life cycle.
Key aspects of system development life cycle

As we know, system development life cycle is represented by different stages when
developing a system. It provides a sequence of activities for software development
teams to refer and follow. This sequence of activities is represented as a set of steps
in which each step will use the result from the previous step. Let us look at Figure
4.1 for better understanding.
UNIT 4 5
Development models
6. Operations and
maintenance
1. Planning
5. Testing
2. Analysis
4. Coding
3. Design
Figure 4.1 System development life cycle model
As you can see from Figure 4.1, there are six stages in system development life
cycle model. Each of the stages has its own meaning and job description. System
development life cycle has phases that are essential to system developers. Let us go
through one by one the six stages in this model.
1. Planning
In this stage, we will divide it into three phases which are
a. Preliminary study
In this phase, a brief investigation of the project will be done in order to
get a clear picture of what the actual system may be. A system proposal
will be created which will have details about the project, with some of the
study involving searching the problem definition, objectives of the study,
constraint and expected benefit of the new system, terms of reference for
study and many more. The person in charge of preparing the proposal is
system analyst. Once the system proposal has been done, it will proceed
to the customer. It depends on them to accept it or reject it or request
some modifications in the proposal. In the preliminary study, it will go
through the following steps:
i.
Problem identification and project initiation
ii.
Background analysis
iii. System proposal

b. Feasibility study
The next phase after the project sponsor accepts the system proposal
will be feasibility study. The development team members need to form
a descriptive view of the project and determine its goals and objectives.
In this phase, the development team needs to produce project plan and
budget estimation for the future stages of development. The main goal
of this phase is not to solve problems but try to define the scope.
c. Detailed study
In this phase, a detailed investigation will be carried out. There are
various operations that have a relationship within and outside the system.
Data are collected so that it is easy to draw the exact boundary of the
new system using the steps, such as keeping up with the problem view
and requirements and taking notes of the pros and cons even in new
areas of the system. A proper documentation of all the findings can be
presented in the form of data flow diagrams, data structures and miniature
specification. The important points that need to be determined in this
phase are:
i.
The specification for the new system based on user requirement.
ii.
Functional requirement that shows the relationship in the new

system.
iii. List of attributes and entities.
d. Analysis
Analysis, in terms of system development can be defined as the process
of collecting data, understanding the processes involved, identifying
problems and recommending feasible suggestions for improving the
system functioning. It also includes subdividing the complex process
involving the entire project and identification of data store.
The system analyst will be the one that analyses the end user information
needs and prepares a work plan. With analysis, we will be able to gather
requirements for the system. This phase includes a process of detailed
study. The main objectives of systems analysis are to find a correct answer
to each of the questions below:
i.
What is being done?
ii.
When is it being done?
iii. Who is doing it?
UNIT 4 7
Development models
iv.
Why is it being done?
v.
How is it being done?
vi. How can it be improved?
If we look at the questions, system analysis is more of a thinking process

that involves the creative skills of the development team.
e. Design
This is actually the most crucial stage in the system development. After
the analysis phase has been done, the new system must be designed. A
logical design is created from the requirements that have been gathered.
Then, it will be converted to physical system design. There are two stages
in system design:
i.
Preliminary or general design

At this stage, the cost estimation and the specification of the features
are estimated. After the preliminary project is considered to be
probable, we will move to detailed design phase.
ii.
Structured or detailed design

In this phase, the design of the system becomes more structured.
This will consider the input, output, databases, forms, coding
schemes and processing specification that will be drawn up in detail.
The hardware and software platform including the programming

languages in which the new system will developed are also decided. The
system design is employed following the steps below.
Define the system output precisely.
Determine the requirement to produce the output.
Determine the format of files and database.
Decide the processing method and use of software.
Determine the procedure of data input.
Design forms.
Design coding.

Develop manual procedures.
Document the design.
f. Coding
The goal of coding stage is to transform the design that was done into
codes using a suitable programming language. To make it a feasible
system, the system design needs to be implemented which requires
the coding phase. This phase affects both testing and maintenance.
To reduce the testing and maintenance effort, the programmer needs
to create a well-written code for the system. Therefore, in developing
system, there is a need to focus on developing a coding that is easy to
write. The programmers need to implement simplicity and clarity when
delivering the coding. With the help of computer language, the defined
procedures are converted into control specifications. The programs must
be standardising in nature so that it can help in maintenance and any
required future changes.
g. Testing
Testing refers to a process of verifying and validating the system, to ensure
it works as expected, in meeting the requirements and the business goals.
Usually, there will be approximately 80% of error in the first two front
end releases when applying the intensive test approach. Let us look at
Figure 4.2 for the formal review points in testing:
2. Design
System
Test
1. Organise
Project
5. Build
System
Test
7. Execute
System
Test
3. Build Test
Process
4. Design Test
Environment
8. Integration
Testing
6. Build Test
Environment
10. Sign-off
and
Review
9. Start
Pilot Test
Figure 4.2 Formal review points in testing phase
Figure 4.2 is an outline of the test approach. Boxes 1 to 6 represent the

major review stages prior to test execution, while boxes 7 to 10 represent
the stages planned for and after test execution.
UNIT 4 9
Development models
A test plan will be developed after codifying the programs. Then, we

need to run the test plan on a given set of test data. The output of the
test plan needs to match the expected results. The following test runs are
carried out using the test data:
i.
Program test
The programs must be individually tested in the program test.
The prepared test data needs to be compiled and brought to working
conditions. Any error that occurrs is noted and debugged.
ii.
System test
The system test should be done after the program tests with the
errors removed. The test in this phase will be using actual data. At
each execution, the output will be analysed. If the outputs do not
match the expected output, then an error has occurred. In such case,
the error needs to be identified and fixed, and further testing is
required.
h. Operation and maintenance

The operations or implementation begins when the new system is
accepted by the user. The development team configures the system
security, tests the functionality of the features, installs the system and
obtains a formal authorisation to perform the system. Before placing the
system into operation, the system test must be performed to ensure all
security specifications are met.
The results of the system tests and design review must be fully
documented, updated with new reviews and test records. The major steps
involved in this phase are:
i.
Installation of hardware and software.
ii.
Install the new system into the organisation.
iii. Training / workshop for users.

iv.
Documentation.
When the programs are loaded into the users computer, training needs
to be given to the user or staff. The training must consist of:
i.
How to install the system.
ii.
How to insert and extract the information from the system.

iii. How to operate the system to process data.

iv.
How to generate a report.
When the user or staff is trained, they will shift the method of work
from manual to computerised system. This is called changeover. Now,
you already know the inside parts of operations. Next, let us look at the
maintenance of the system.
There is no doubt that the system will need maintenance. This is the
least glamorous step but it is required during the whole system life. Once
the system has been delivered to customer, there will definitely be some
changes while the system is in used. Maintenance is needed to eliminate
errors in the system during its working life. We need to maintain the
system from time to time. The maintenance of the system is done in
order to:
i.
Know the full capabilities of the system.
ii.
Know the required changes or extra requirements.
iii. Performance study.
A new project may need to be set up if a major change to a system

is needed. The new system will then proceed through all the system
development life cycle phases.
Summary
System development life cycle is a process that involves activities,
from initiation, analysis, design, implementation to maintenance.
This cycle helps in establishing a system project plan because it gives
an overall list of stages that are required for developing a system.
It is actually an integration of different but important activities.
System development life cycle has phases that are essential to system
developers. There are six stages in this model, planning, analysis,
design, coding, testing and operations and maintenance. Each of the
stages has their own activities handled by the software development
team to build the project.
UNIT 4 11
Development models
Self-test 4.1
1. What is the primary objective of system development life cycle?
A. To ensure the delivery of high quality development
B. To enhance bad results
C. To ensure the integration between phases
D. To enhance the feasibility study
2. How many phases are there in the system development life cycle?
A. 5
B. 6
C. 7
D. 8
3. A system proposal will have details about the project. At which

phase will the system proposal be created?
A. Preliminary study
B. Feasibility study
C. Detail study
D. None of the above
4. ___________ is a process of collecting data, understanding

the processes involved, identifying problems and recommending
collecting feasible suggestions for improving the system
functioning.
A. Design
B. Planning
C. Analysis
D. Coding
5. Actual programming code is done in the _______________

phase.
A. Design
B. Planning
C. Analysis
D. Coding

6. Maintenance is a process of verifying and validating that the

system works as expected and meets the requirements.
A. True
B. False
UNIT 4 13
Development models
4.2 Object-oriented Analysis and

Design
Objectives
1. Describe the object-oriented analysis and design.
2. Discuss the object-oriented analysis.
3. List the four steps in object-oriented analysis.
Introduction
Object-oriented analysis and design is defined as a way to model software as a
group of communicating objects. The objects will be classified by classes, state and
behaviour. We can use several notations in developing object-oriented analysis and
design. Object-oriented analysis and object-oriented design have different tasks
between them.
In object-oriented analysis, the subjects will be analysed using a conceptual model.
Object-oriented design accomplishes the specification of the analysis. We have
divided this section into three parts:
1. Understanding object-oriented analysis and design.
2. Object-oriented analysis.
3. Object-oriented design.
Understanding object-oriented analysis and design

One of the development techniques is using object-oriented analysis and design.
Object-oriented analysis and design represents an approach that models software
as a group of interacting objects. The object is depicted as an entity and will be
characterised by classes, state and behaviour. Many models can be developed to
define the static structure, dynamic behaviour and runtime distribution. To represent
the model used in object-oriented analysis, we can use difference notations such as
Unified Modelling Language (UML) that we have already learnt in Unit 3.
To make the concept of object-oriented analysis and design more understandable,
let us look at a real life example. Suppose you are having dinner in a restaurant with
your family, you want some chilli sauce and you ask your sister to get it for you. You
might say to your sister, Please help me to get some chilli sauce, and she will do it.

On the other hand, instead of saying that, you can try, Please stand up and walk to
your right and then to the left towards the chilli sauce table, move your right hand
until it touches the chilli sauce bottle, grab it, lift it from the table, then, walk to
your right and then to the left towards our table, stop when my hand touches the
bottle, wait until my hand close around the bottle, and then let go of the bottle.
This sentence can be used as well but it sounds strange compared to the common
way of giving instructions.
This example shows you the difference between procedural and object-oriented
analysis and design. The object-oriented way is to say, Please help me get some
chilli sauce, and leave it to the object to carry out the task any way it chooses. The
activities that specify the steps of getting the bottle to your hand is the procedural way.
In developing object-oriented analysis and design, we use requirements that we have
already gathered through analysis technique. So, let us go through the concepts of
object-oriented analysis and object-oriented design.
Object-oriented analysis
An object depicted as an entity and characterised by class, state and behaviour is
called object-oriented analysis. The model that has been developed can then be used
to complete the task. The objective is to develop a model that can describe system
that can be used to satisfy the customer requirement. Using object-oriented analysis,
a multipart analysis model can be built to satisfy the objective.
Object-oriented analysis is represented by graphics or language that defines class,
relationships, attribute and behaviour. To ensure it is right, the element of the
object-oriented analysis model will be reviewed for clarity, completeness, consistency
and correctness with user requirements. We have already gone through some of the
conceptual models in Unit 3. The conceptual model involved in object-oriented
analysis consists of a set of use case, a number of interaction diagrams and UML
class diagrams. Sometimes, it may include some mock-up user interface.
There are four steps to be performed in object-oriented analysis:
1. Identify the objects and classes.
2. Identify the relationship between the objects.
3. Identify the attributes.
4. Identify the services.
Since we have already studied the concept of modelling, we will go through briefly the
steps involved in object-oriented analysis. The first step is to identify the objects and
classes, which may be people, things, places, concepts, events or organisations. Next,
we will create an object diagram to indicate the relationship between the objects.
Then, the attributes and services of each object will be identified and documented
on class templates.
UNIT 4 15
Development models
Dozens of object-oriented analyses were developed when the popularity of the object
technologies peaked during the late 1980s and into the 1990s. Each of the objectoriented analyses presented a process for the analysis of a system, a graphic diagram
that yields out the process and a notation that makes the development team create
the model in a consistent way. Among the most currently used are:
1. The Booch Method
It consists of both a micro and a macro development process. Micro
development process is defined as analysis tasks that are re-applied for each
step in the macro development process. This method identifies classes and
objects, defines relationships among the classes and objects, and conducts
a series of manners to elaborate it.
2. The Rumbaugh Method

This analysis method consists of three models:
a. The object model representation of objects, classes, hierarchies and
relationship.
b. The dynamic model representation of object and behaviour of the
system.
c. The functional model representation of information flow through the
system and categorised as high-level data flow diagram.
3. The Jacobson Method

This method place heavy emphasis on the use case that gives a description
that represents how the user interacts with the system. It is also called objectoriented software engineering (OOSE).
4. The Coad and Yourdon Method

This has always been viewed as the easiest object-oriented analysis method to
learn. The guidelines given are straightforward and the modelling notation
is simple to understand. The outlines of this method are as follows:
a. The object is identified using what to look for criteria
b. Defining the generalisation structures
c. Defining the structure
d. Identifying the subjects of components

e. Defining the attributes

f. Defining the services
5. The Wirfs-Brock Method

This method does not make a clear distinction between analysis and design
task. This method has a continual process that starts with assessment of
user specification and ends with a design. The outlines for this method are
as follows:
a. User specification will be evaluated.
b. Classes will be extracted from the specification.
c. Classes will be grouped to identify superclasses.
d. Each class will define its responsibilities
e. Each class will be assigned responsibilities
f. Classes will be define its relationships
g. Collaboration between classes will be defined based on responsibilities
h. Building a hierarchy representation of classes
i. Constructing a collaborate graph for the system
Even though each of these object-oriented analysis methods has a different process,
the overall processes are quite similar. Software development teams need to perform
the following steps while doing object-oriented analysis:
1. Elicit user requirement for the system.
2. Identifying the use cases and scenarios.
3. Using basic requirement as a guidance to select objects.
4. Identifying operations and attributes for each object.
5. Defining structures and hierarchies that organise classes.
6. Create an object relationship model.
7. Create an object behaviour model.
8. Reviewing the object oriented analysis model against use cases.
UNIT 4 17
Development models
Grady Booch, James Rumbaugh, and Ivar Jacobson have shared their knowledge and
combined the best features of their object-oriented analysis and design methods into
a unified method. It is called Unified Modelling Language (UML). It has become
a popular method in the industry. It allows the software engineer to use modelling
notations that have a set of syntactic, semantic and pragmatic rules to express an
analysis model.
Object-oriented design
A developer applies implementation constraints to the conceptual model produced
in object-oriented analysis during the object-oriented design. It involves any
technological or environmental non-functional requirement constraint such as
response time, development environment, transaction output, runtime platform
and those that are inherent from the programming language.
In the conceptual model, a model of solution domain has been created by mapping
the conceptual model onto implementation classes and interfaces such as the
detailed description of how the system will be built. There are four key steps in
object-oriented design:
1. You will need to define object life cycle.
2. You will need to define relationship of each class.
3. You will need to define the service logic.
4. You will need to complete the class definitions.
We will use an object state diagram to define and analyse the object life cycle. Then,
a class diagram will be used to define the class relationship. Each service provided
by a class is defined. Lastly, the class diagram and object diagram are completed
along with other class templates. You may refer to Unit 3 for a brief description of
state and class diagrams.
Responsibilities Design
Message Design
Class and Object Design
Subsystem Design
Figure 4.3 The object-oriented design pyramid

Object-oriented design accomplishes the definition of a multilayered software

architecture, the specification of system that performs the specific function, a
description of objects that form the building of the system and a communication
mechanism that makes the data flow between layers and objects.
Figure 4.3 shows the object-oriented design pyramid. There are four design layers in
object-oriented design pyramid. Let us go through one by one as shown in the figure:
1. Subsystem layer
It represents each of the subsystems that enables the system to gain the user
requirement and implement the technical infrastructure that supports user
requirements.
2. Class and object layer

It contains representation of each object. It also has the object hierarchy
that can create the system using generalisation and targeted specialisations.
3. Message layer
It contains the details of the design that enable the object to communicate
with the collaborators. This layer establishes the internal and external
interfaces for the system.
4. Responsibilities layer
It contains the algorithmic design for all operations and attributes for each
design.
The object-oriented design pyramid focuses on the design of the specific product.
According to Bertrand Meyer (1988), five criteria is necessary for judging a design
methods ability to gain modularity and relate it to object-oriented design.
1. Decomposability
It is a facility that helps the development team to decompose a large problem
into subproblems that are easier to solve.
2. Composability
It is to ensure that the components in the system can be reused to create
other systems.
UNIT 4 19
Development models
3. Understandability
A program component must be understood easily without referring to other
modules or information.
4. Continuity
Enables small changes to be made in a program and the changes will not
interrupt too much with other processes in one or a few modules.
5. Protection
If an error occurs in the module, it will reduce the propagation of side effects.
The design criteria and principles that are in this section can be applied to any
design methods such as structured design. As we have noted earlier, a variety of
object-oriented analysis and object-oriented design methods were created in the
past decades. You have also been provided with the briefing of early object-oriented
analysis methods. Now, let us look at the brief overview for object-oriented design
methods as follows:
1. The Booch Method
In design context, macro development process includes dividing the similar
object into separate partitions, defining relevant scenario, creating design
prototype and applying validated design prototype to usage scenarios. Micro
development process represents a set of rules that govern the use of attributes
and domain-specific policies for memory management, error handling and
other infrastructure functions.
2. The Rumbaugh Method

It represents design activities that help the design to be conducted at two
different levels of design, system design and object design. To construct a
complete system, system design will focus on layout for the components
that are required. Meanwhile, object design depicts the detailed layout of
an object.
3. The Jacobson Method

The design model punctuates traceability to the object-oriented software
engineering analysis model. At first, the idea of analysis model is adapted in
the real-world environment. The objects called blocks will be created and

categorised as interface blocks, control blocks and entity blocks. During

the execution, communication between blocks will be defined and it will
be organised into the subsystems.
4. The Coad and Yourdon Method

The design model focuses on in representation of the four major system
components, the problem domain component, the human interaction
component, the task management component and the data management
component. This design method was developed based on the study on how
effective object-oriented designers do their work.
5. The Wirfs-Brock Method

It depicts a series of technical tasks in which the development team leads
smoothly into design. Each class has its own protocol and is constructed by
refining contracts between classes. Each protocol and operation is designed
in detail so that they can be used as guidance for implementation.
The overall object-oriented design processes are consistent even though the
terminology and the steps for processes of each object-oriented design method differ.
A software development team needs to perform the following generic steps to carry
out object-oriented design:
1. Each subsystem needs to be described and allocated to processors and tasks.
2. A design strategy needs to be chosen so that can implement data management,
interface support and task management.
3. A control mechanism needs to be designed for the system.
4. Create a procedural representation to perform the object design for each
operation and data structures for class attributes.
5. Message design needs to be done by joining objects and its representation.
6. Messaging model will be created.
7. The design will be reviewed again as required. The design steps in this
discussion are iterative.
UNIT 4 21
Development models
Summary
Object-oriented analysis and design is about viewing and modelling
the system as a set of interacting and interrelated objects. Objectoriented analysis involves using a conceptual model that contains
a set of use case, a number of interaction diagrams and UML class
diagrams. The four steps involved when performing object-oriented
analysis are defining the objects, identifying the relationship between
the object, identifying the attributes and identifying the services.
Usually, an object state diagram will be used to define and analyse
the object life cycle in object-oriented design. The four steps in
performing object-oriented design are the needs of defining which
object life cycle that you want to use, defining the relationship
of each class, depicting the service logic and completing the class
definitions.
Self-test 4.2
1. The object is depicted as an entity and will be characterised by
class, state and behaviour. The above statement refers to:
A. Object-oriented analysis
B. Object-oriented design
C. Object-oriented cycle
D. Object-oriented development
2. In object-oriented analysis, this model consists of both a micro

and a macro development process. Which of the following
methods is represented by the above statement?
A. The Rumbaugh Method
B. The Booch Method
C. The Jacobson Method
D. The Wirfs-Brock Method
3. In object-oriented analysis, this method does not make a clear

view between analysis and design task. Which of the following
methods is represented by the above statement?
A. The Rumbaugh Method
B. The Booch Method
C. The Jacobson Method
D. The Wirfs-Brock Method

4. ___________ is to ensure that the components in the system

can be reused to create other systems.
A. Continuity
B. Decomposability
C. Composability
D. Protection
5. Which of the following is not in object-oriented design pyramid

layer?
A. Responsibility
B. Class and object
C. Message
D. Process
6. Object oriented design uses a data flow diagram to define and

analyse the object life cycle.
A. True
B. False
UNIT 4 23
Development models
4.3 Agile Distributed Development

Method
Objectives
1. Describe the agile processes.
2. Discuss extreme programming.
3. Discuss scrum process.
Introduction
The agile software development is a group of software development methods based on
incremental and iterative process, where requirements and solutions evolve through
collaboration between self-organising and cross-functional team.
It encourages adaptive planning, evolutionary development and delivery, as well as
promotes flexible response from users or customers to change the project. Using
agile distributed development method, you will define a framework that encourages
foreseen interactions throughout the development cycle. This section is divided into
three parts:
1. An agile view of process
2. Extreme programming
3. Scrum
An agile view of process

In the past decades, software was developed by a large software development team that
came from different companies. They will work together for a long period of time
to create software. There are some projects that may take years to complete, starting
from the initial requirement until the deployment. The approaches involved is very
hefty overhead planning, designing and documenting the system. However, when
this approach is applied to a small or medium project, it wastes a lot of time because
they are focusing more on the planning rather than the development and testing.
Therefore, the problems led a number of software developers to create a new method
called agile method. This method focuses on the software itself rather than on its
design and documentation. Agile method can deliver working software quickly to the
customer, and the customer can add or change the requirements in later iterations.

The goal is to cut down the excessive administrative procedures by avoiding work
that has long-term value and eliminating documentation.
According to Sommerville (2011), the critical study behind agile method is bias
from the agile manifesto. Below are the manifesto statements:
We are uncovering better ways of developing software by doing it and helping others to
do it. Through this work we have come to value:
Individual and interactions over processes and tools
Working software cover comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Agile has a set of principles based on agile manifesto. These principles will be adapted
by various agile methods in different ways. There are two agile methods that we will
discuss later in this section, namely extreme programming and Scrum. Now, let us
look at the principles of agile method:
1. Customer involvement When developing software using agile method,
user need to be involved throughout the development process. They need
to provide the system requirement and appraise it while doing the iteration.
2. Incremental delivery The project will be divided into smaller and more
manageable pieces by inserting the user requirement in each increment.
3. People not process The software development team will do it their own
way using their own skills without any perspective processes.
4. Embrace change You need to anticipate that the user requirement will
change regularly just like the system design.
5. Maintain simplicity You need to focus on simplicity of the software
being developed and the same goes for the developing process. If possible,
try to eliminate complexity from the system.
The agile method is constantly used for small- and medium-sized development.
According to Drobna et al. (2004), some software development teams are
experimenting this method in large-scale projects. For the outcome, software
development teams face risks such as cost escalation and longer durations. But, the
development work itself can still be performed by small agile teams. Agile methods
UNIT 4 25
Development models
will require significant modification when implementing it in a critical project.

This is because it will affect security, dependability and safety. There are constant
occurrences of non-technical problems when using agile method:
1. The agile method involves the user. Therefore, the success of the system
depends entirely on the user who is willing to spend time with the
development team. However, user representatives are usually not able to
give full commitment to the software development team. This is because
they also have their own commitments.
2. The capability of software development team to interact with each other
can affect the development process.
3. System that has many stakeholders will have problems prioritising changes if
not managed well as each stakeholder may give various opinions when
prioritising changes.
4. The team members may not have time to maintain simplicity due to workload
and tight schedule.
5. Companies may change their culture or processes for improvement. When
the culture and process of a company changes, it will be difficult to reorganise
the system again due to the informal processes in the agile method used by
the development team.
Typically, a software development team that uses agile method for their project has
to rely on contracts, which the company pays for the time required for development.
So, as long as it goes well, the benefit goes to both developers and customers.
Extreme programming
Extreme programming is the most widely used agile method. In extreme
programming, requirements are expressed as scenarios or user stories. It will be
implemented directly as a series of tasks. The programmers will work in pairs and
develop tests before writing the coding. All of the release cycles may have a short
delivering schedule. Extreme programming involves a number of practices:
1. Incremental planning The requirement will be determined by the time
available and priority, and recorded on a Story Card.
2. Small releases First, development will be done with a minimal set of
functionality that provides business value. Functions will be added in coming
releases.
3. Simple design Design that needs to be carried out must be simple as long
as it meets user requirements.

4. Test first development A framework will be used to write tests for a new
functionality before that function is implemented.
5. Refactoring To keep the coding simple, the developers will refactor the
code continuously as soon as the improvement codes are found.
6. Pair programming Programmers will work as a pair and support each
other and even check each others work.
7. Collective ownership Since the programmers work together, anyone can
change anything.
8. Continuous integration After all task is complete, it will be integrated into
the whole system. All tests in the system must be successful after integration.
9. Sustainable pace Large amount of time is considered unacceptable in
extreme programming.
10. On-site customer the customer is considered part of the development
team and is responsible for bringing the system requirement to the team for
development.
Select User Stories

or Scenarios for this
Release
Stories will be broken

down into tasks
Planning the Release
Evaluate System
Release Software
Develop/Integrate/
Test Software
Figure 4.4 The extreme programming release cycle
The ten practices above actually reflect the principle of agile methods:
1. Incremental development The requirement will be based on customer
stories or scenario and the developer will decide what kind of functionality
should be included in it.
2. Customer involvement Customer will be part of the development team
and is responsible for acceptance tests of the system.
3. People, not process Using a pair of programmers, customer and a good
development process, there will be no need for excessively long working
hours.
UNIT 4 27
Development models
4. Embrace change Change will be done frequently when the system is

released to the customer.
5. Maintaining simplicity With a frequent refactoring and using a simple
design that enables changes in the future.
System requirements are provided by the customer who is working with the team.
Together, they develop scenarios that encapsulate the needs into a simple but
spectacular system.
Scrum
As far as we know, the uses of agile method has widened in the previous decades.
Therefore, different agile methods have been created. One of them is Scrum.
According to Schwaber and Beedle (2001), the Scrum approach focuses on managing
iterative development rather than technical approaches. Scrum can also be depicted as
incremental agile software development that represents a new approach to planning
the system, bringing decision-making authorities to the level of operations properties.
Outline Planning and

Architectural Design
Assess
Select
Review Develop
Sprint Cycle
Project Closure
Figure 4.5 The Scrum process
From Figure 4.5, we can see there are three stages in Scrum.
1. Outline planning you will establish the objective for the system and design
the software architecture.
2. Sprint cycles each cycle brings an increment to the system.

3. Project closure it finishes up the system, completes the documentation

such as user manual and determines the lesson learnt from the system.
The important part in Scrum process is the Sprint cycle. It is a planning unit that
determines the work to be done, as well as the features required for development
and system implementation. At the end of it, the complete functionality is delivered
to stakeholders. Let us look at the key characteristics of the process:
1. Sprint has a fixed life cycle, normally 2 to 4 weeks.
2. The list of work will be produced, starting with planning. During assessment
stage, the list of work will be reviewed and reprioritised. At the beginning of
each sprint, the customer can provide new requirements since they are closely
involved with the project.
3. In Sprint, the whole development team will get together with customer
during the selection stage to select the functionality and features of the
system.
4. Once the development team and customers agreed on the functionality
and features, the development stage begins. A short daily meeting will be
held to review the progress. During this stage, development team is separated
from customer and the company. This is to protect the development team
from external extraction. This is called Scrum Master.
5. At the end, the final result is reviewed and presented to the stakeholder or
the company. The next Sprint cycle then begins.
In Scrum, there is no project manager since everybody is empowered to make

decisions. Scrum master acts as a facilitator that arranges daily meetings, tracks
backlog of work to be done, measures the progress against backlog and communicates
with customers and management outside the team. Rising and Janoff (2000) discuss
the successful use of Scrum when they used it in telecommunication software
development environment and the advantages are as follows:
1. The system is developed into a set of manageable and understandable chucks.
2. Requirements that are unstable will not hold back the progress.
3. Team communication is improved due to the team having visibility of
everything.
4. The customer gains feedback on how the system works when the team
implements on-time delivery increment to them.
5. A positive value is created where everyone expects the project to succeed
and trust between customers and development team is established.
UNIT 4 29
Development models
Originally, Scrum had been used by a team that can work together in one place so
that it is easy to conduct daily meetings. Nowadays, there are various experiments
going on to develop Scrum for distributed development environments (Sutherland
et al. 2007). Today, distributed development environment will consist of many team
members located in different places around the world.
Summary
Using agile distributed development method, we can produce
results in a short time for some projects that may take years. We
can deliver working software quickly to the customer. The customer
can add or change the requirements in later iterations. The goal of
agile distributed development method is to cut down the excessive
administrative procedures by avoiding work that has long-term
value and eliminating documentation.
Extreme programming is the greatest use of the agile methods.
Scenarios or user stories are used to express the user requirements.
Extreme programming involves practices such as incremental
planning, small releases, simple design, test first development,
refactoring, pair programming, collective ownership, continuous
integration, sustainable pace and on-site customer.
Scrum approach focuses on managing iterative development. It is
also an incremental agile software development that represents a
new approach to planning the system. The three stages in Scrum
are outline planning, sprint cycles and project closure.
Self-test 4.3
1. Agile methods require significant modification when
implementing it in a critical project since it will affect all the
requirements below EXCEPT
A. security
B. time consuming
C. dependability
D. safety

2. When developing software using agile method, users need to

be involved throughout the development process. This statement
refers to
A. incremental involvement
B. customer involvement
C. iteration development
D. embrace change
3. How many weeks are needed in a sprint life cycle?

A. 5 to 6 weeks
B. 4 to 5 weeks
C. 3 to 5 weeks
D. 2 to 4 weeks
4. In ______________, requirements are expressed as scenarios

or user stories.
A. Sprint cycle
B. Scrum master
C. extreme programming
D. design development
5. During the development stage in Scrum, the development team

is separated from customer and the company. This situation is
called
A. priority
B. sprint cycle
C. backlog
D. Scrum master
6. Everybody is empowered to make decisions in Scrum.

A. True
B. False
UNIT 4 31
Development models
4.4 Component-based Software

Engineering
Objectives
1. Describe the component-based software engineering.
2. Discuss the process of component-based software engineering.
3. Differentiate component-based software engineering (CBSE) for reuse and
CBSE with reuse.
4. Describe the component composition.
Introduction
Component-based software engineering is a process that articulates the design and
construction of computer-based systems using reusable components. This process
has a high level of abstraction and usually will be represented by its interface. The
details of implementation are hidden from other components.
Component-based software engineering can be depicted as a process of identifying,
performing and integrating loose components into a new system. As such, we have
broken this section down into three parts:
1. Understanding component-based software engineering.
2. Component-based software engineering process.
3. Component composition.
Understanding component-based software engineering

When a company wants to develop a system, they will choose a development
method that is suited their requirements. Component-based Software Engineering
(CBSE) is an approach that reuses the software component to develop software.
CBSE can be represented as a process of identifying, performing and integrating
loose components into systems.
Nowadays, customers demand dependable software which can be easily deployed.
Therefore, it is better to reuse rather than implement a new system. Let us look at
the essentials of CBSE:

1. Components There must be a separation between interface and

implementation. So, if the component needs to be replaced, it will not cause
changes to other parts of the system.
2. Component standard A component standard is very important because it
is embodied in a component model. Components written in different
languages can communicate with the same system.
3. Middleware You need to have a middleware support that handles the
communication of the components so that you can make it as independent,
distributed components working together.
4. Development process CBSE will be geared by a development process.
It allows requirement to develop depending on the functionality of available
components.
A component is an element that can be assessed using a procedure called mechanism

by other components running on separate computers. The system that uses a
component from other systems must incorporate its own copy of that component.
According to Lau and Wang (2007), various protocols and standards have been
developed, such as Microsofts COM and .NET, Suns Enterprise Java Beans (EJB)
and CORBAs CCM for supporting this component. The components that have
different platforms cannot be combined. This is a barrier to their adoption.
In order to solve this dilemma, the development of notion of a component as a
service has been done. A standard was proposed to support the service-oriented
software engineering. A component as service is a stand-alone entity that is external
to a program that uses them.
So, rather than copying the component, you actually refer the external service to
the system that you build. Therefore, service-oriented software engineering is a type
of component-based software engineering whereby it uses notion of a component
and is supported by a standard.
Reading
To know more about the problems with CBSE, go to
SoftwareEngineering-9.com. Problems with CBSE.
http://www.SoftwareEngineering-9.com/Web/CBSE/problems.
html.
(Accessed 28 May 2012)
UNIT 4 33
Development models
Component-based software engineering process

Component-based software engineering process is a reuse-based approach to
composing loosely coupled independent components into systems. The goal is to
bring benefits to the software itself and organisations that sponsor such software.
There are two types of CBSE processes as stated below:
1. Development for reuse this process is related to the component that will
be reused by other systems. It includes generalising existing components.
The objective of this process is to produce one or more reusable components.
You will know which component that you are working with and you have
to access the source code to generalise it.
2. Development with reuse this process involves building a new system using
existing components. Different from the above process, this time, you do
not know which component is available, so you need to find these
components and design your system to make the most effective use of them.
You also may not have access to their source code.
CBSE for
Reuse
Designer,
Implementer,
System Analyst
Component
Certification
Component
Management
CBSE with
Reuse
Designer,
Integrator
Component
Acquisition
Vendor
Librarian
Local or external
certifier
Component
Repository
Figure 4.6 CBSE processes
From Figure 4.6, you can see other processes such as component acquisition,
component certification and component management. So, let us look at the function
of the processes involved:
1. Component acquisition
It involves acquiring components for reuse or for building a system into
a reusable component. It may also involve finding the components from
external sources or accessing it locally.

2. Component management
This process involves managing a companys reusable component by ensuring
the component is properly stored, catalogued and made available for reuse.
3. Component certification
This is a process where the component will be checked and certified to
ensure that it meets the specification.
The company will take care of the component by maintaining it and it can be stored
in a component repository with the information related to the component. Now,
we will go into the details about CBSE for reuse and CBSE with reuse.
Component-based software engineering for reuse

Component-based software engineering for reuse is a process of making available
reusable components through a component management system. Usually, it is done
by companies committed to reuse-driven software engineering. However, these
internal parts are not usable without change.
You have to adapt and extend the components and make it more generic to make
it reusable. But, you need to remember that reusing the component may incur
cost. Therefore, there are two subjects that need to be considered. It is whether the
components are likely to be reused and also whether the cost saving from future
reuse can justify the cost of making the component reusable.
Let us look at subject number one. In this case, you should decide if the component
should have one or many stable domain abstractions attached. Domain abstraction
in this context refers to object of the system. For example, for school management
system, domain abstractions might include teacher, subjects and students. Therefore,
if the component is attached with many domain abstractions, it can probably be used.
Now, for subject number two, it involves cost. You need to develop the cost of
changes that are required to make the component reusable. These involve cost of
component documentation and component validation. To make the component
more reusable, you may:
1. Change the name to make it more general.
2. Remove the application-specific method.
3. Make a method more generic on the component.
4. Make an exception handling on all methods.
5. Combine the components to increase independence.
UNIT 4 35
Development models
6. Add a configuration interface to allow the component to be adapted in

various situations.
Before the component is made available for reuse, certification may be carried
out. During the certification process, a person who is not the developer checks the
quality of the component. The components are tested and certified if it meets the
acceptable quality standards.
Activity 4.1
Many other objects produced as part of systems can be reused even
though software components are the most obvious reusable artifact.
What is the benefit developers gain from doing so?
Component-based software engineering with reuse

The component-based software engineering for reuse has to include activities that
search and combine reusable components. Let us look at Figure 4.7 that shows the
CBSE with reuse process.
Outline
System
Requirement
Identify
Candidate
Components
Modify Requirements
According to Discovered
Components
Architectural
Design
Identify
Candidate
Components
Compose
Components
to Create
Figure 4.7 CBSE with reuse
The user requirement will be written as an outline instead of a detail, and the
customers or users who define the requirement must be as flexible as possible during
the process. So, if the requirement is too specific, it will be hard to find a component
that has the specific requirement. Requirements are identified and modified in the
early process. If the component does not meet the user requirement, then the related
requirement needs to be revised so that the component can support the requirement.
After the system architecture has been designed, you need to identify the candidate
component since it is possible the component that we already have is not suitable or
does not work properly with other components. Therefore, we need to do component
search, select it and design the refinement activities before validating it.

Development is a composition process where you discover which components

are combined. This involves combining components with the component model
infrastructure and you may also add other functionalities to the reused components.
Component composition
Component composition is a process that combines components with each other
using specially written glue code to create another component or system. Figure
4.8 shows the types of component composition. There are a few ways to compose
a component.
(a)
(b)
(c)
Figure 4.8 Types of component composition
Let us say you are composing two components, component A and component B
to create a new component. You can compose the component in different ways as
indicated in Figure 4.8.
1. Sequential composition
If you are building a new component from two existing components, you
need to call the existing component by sequence. The service at component
A is called and the return of the result by A is then used to call the service in
component B. In sequential composition, the components do not call each
other. Some extra glue code is required to call the component service in the
right order and to ensure that the result component delivered by component
A matches the input expected in component B. This is the process that
happened in situation (a) which we called sequential composition.
2. Hierarchical composition
When one component calls directly on the service provided by other
component, it will be in hierarchical composition as shown in Figure
4.8(b). The calling component gets the service from the called component.
If component A calls directly on component B, and the interface matches
together, there is no need to add extra coding.
UNIT 4 37
Development models
3. Additive composition
The additive composition in Figure 4.8(c) occurs when more than one
component are added together to develop a new component with integration
functionality. Through the external interface of the composed components,
the components will be called separately. Component A and component
B are not depending on each other. It also does not contact together. This
type of composition is usually used with components that are programmed
in units or components that are services.
In some cases, you might create a system that uses all the forms of component
composition. You may also have to write glue code in certain components. When
you design a component or want to reuse a component, you should clearly define
the roles of each component so that it will not be overlapping.
Summary
Component-based software engineering brings benefits to software
quality, software development team productivity and the overall
total system cost. The two types of CBSE processes are development
for reuse and development with reuse. The three kinds of function
in CBSE processes are component acquisition, component
management and component certification.
The economics of software reuse becomes a question of whether it
will be cost-effective to build fewer components and reuse more.
Generally, the answer will be yes but the software development
team must also count the non-trivial costs associated with the
qualification, adaption and combination of reusable components.
Self-test 4.4
1. Component-based software engineering can be represented as
a process of
A. identifying, performing and integrating loose components
into systems.
B. planning, designing and integrating loose components into
systems.
C. creating, designing and integrating loose components into
systems.
D. analysing, creating and integrating loose components into
systems.

2. What is middleware in the essential of CBSE?

A. It involves finding the components from external sources.
B. It handles the communication of the components.
C. It allows the requirement to develop depending on the
functionality.
D. It embraces changes in the component model.
3. How do you make CBSE more reusable?

A. Application-specific method can be added.
B. Need to make verification for all methods.
C. Combine the components to increase complication.
D. Change the name to make it more general.
4. The ____________ in CBSE with reuse refers to someone not

from the software development team checking the quality of
the component.
A. graduation
B. verification
C. certification
D. composition
5. There are three types of component composition EXCEPT

A. Sequential
B. Hierarchical
C. Additive
D. Parallel
6. When you design a component or want to reuse a component,

you do not have to define the roles of each component so that
it can be overlapping.
A. True
B. False
UNIT 4 39
Development models
Feedback
Activity 4.1
Here are examples of answers and ideas that the student can use.
1. Software quality Using reuse components, we can increase
software quality since these components are tested under a
variety of situations before being used in other applications. It
also produces more standardised software and provides a
powerful competitive advantage.
2. Software development team productivity The software
development team can shorten software development time and
focus on other components that need to be developed.
Furthermore, software development team can produce better
software using the reuse component.
3. The overall total system cost A proper strategy for using
reuse component can lead to significant cost-savings. It can
reduce software development (fewer programmers) and
maintenance cost.

UNIT 4 41
Development models
4.5 Spiral Model and Others

Objectives
1. Describe the phases in spiral model.
2. List the activities in spiral model.
3. Describe the concurrent development model.
4. Differentiate the technologies in component assembly model.
Introduction
Spiral model is the software development process that combines the elements of
design and prototyping in stages. These stages start with designing the main objective
and end up with the customer reviewing the progress. A series of major technical
activities can be represented as a concurrent process model.
With focus on the objective of the project, the software development team puts
their effort to each stage of the development. Programmers will always work on the
coding since it takes much of the time to create a single program. This section is
broken down into four parts:
1. Overview of spiral model.
2. The spiral model process.
3. Concurrent development model.
4. The component assembly model.
Overview of spiral model

Barry Boehm (1985) defined the spiral model in his article A Spiral Model of Software
Development and Enhancement. The spiral model is a software development process
that integrates with elements of prototyping and design in an effort to integrate the
advantages of bottom-up and top-down approach concepts. This is the first model
that explains why the iteration matters.
Typically, spiral model is applied to large, complicated and expensive projects. The
spiral model emphasises risk analysis. There are four important phases in spiral model:

1. Determine objectives
2. Risk analysis
3. Developing and testing
4. Planning
The spiral model integrates the idea of iterative model with systematic and the
waterfall model for controlling the aspects. The spiral model allows for incremental
refinement each time the project moves around the spiral. Risk management is also
involved when developing project using spiral model to ensure the project is always
on track.
At each repetition cycle in the spiral model, you need to remember that the project
before the upcoming repetition is an extension of an earlier project. This model is
separated into planning, risk analysis, building a prototype and duplicating it.
There are some advantages and disadvantages when using a spiral model:
1. Advantages
a. You will having a high amount of risk analysis.
b. This model is good for large and critical project.
c. A system is produced early in the stage of software life cycle.
2. Disadvantages
a. It does not work well with smaller project.
b. The success of the project highly depends on the risk analysis.
c. This model can be a costly model.
d. In the risk analysis stage, ,good expertise is needed.
The effort of engineering and doing analysis must be applied towards the cycle to
gain the goals of the project. Further details about the spiral model will be discussed
in the next section.
UNIT 4 43
Development models
The spiral model process

In spiral model, elements of the project can be added to the spiral model when it
becomes available or known. In this way, it can be assured that there will be no
conflict with previous requirements and design. This technique is compatible with
approaches that have more than one software build and release and allows for the
making of an orderly transition to a maintenance activity.
Determine
objective,
alternatives and
constraint
Evaluate
alternative,
resolve risk
Risk
analysis
Prototype
Design
Test
Plan
Develop and
verify next
level system
Figure 4.9 The spiral model
As we have mentioned earlier, the four phases in spiral model are determine objective,
risk analysis, developing and testing and planning. These four phases will follow one
after another in order to eliminate problems. This is because repeating the phases
will help find the problems and deal with it when the same phase is repeated the
next time. Let us look at the activities inside the spiral model as follow:
1. Determine objective
In this phase, we will identify the objectives, the alternatives and also the
constraints of the project. The entire outcome from the discussion will be
documented. The objectives and requirements are determined in order to
choose the approach to follow during the project life cycle.
2. Risk analysis
This is the most important part of the spiral model. All available alternatives
that can help to solve the problem and develop a cost-effective project are
analysed. Strategies are decided and used for risk management. Prototype
may be used to collect some data if there is uncertainty in requirements.
It can also been used to find the possible ways to deal with the potential
changes in requirements.

3. Developing and testing

In this phase, the actual development of the project is carried out. After the
software has been developed, it will pass through other phases repeatedly
so that it can be improved.
4. Planning
After developing the project, the software project will be passed to the
customer for comments and suggestions, which can help to identify and
resolve potential errors. From the feedback, planning will be made for the
next iteration.
A more complete project is built as we go on repetiting all the four phases.
The first iteration is considered the most important, as almost all possible
risk, constraints, requirements are identified. The following iterations use
the defined strategies to develop a complete system.
Activity 4.2
After learning the spiral model phases, in your opinion, why do you
think it is called as a Spiral model?
Concurrent development model

The concurrent development model can be identified as a series of major technical
tasks and activities. Their relation states are prototyping, analysis modelling,
customer communication and other important tasks. According to Davis and Sitaram
(1994), the concurrent development model is driven by user needs, management
decisions and review results. Let us look at Figure 4.10 that shows one element of
the concurrent development model.
UNIT 4 45
Development models
None
Under
development
Awaiting
changes
Under
review
Under
revision
Baseline
Done
Figure 4.10 One element of the concurrent process model
In Figure 4.10, you can see that this is one of the elements of concurrent development
model that consists of analysis activities. The boxes represent a state of a software
development team activity. The activity may be in any one of the externally observable
modes of behaviour noted at any given time.
The activities inside concurrent development model exist concurrently but it will
reside in different states. In the concurrent model, there is one element which is
communication with customer. This activity has completed its first iteration and
exists in the awaiting changes state.
The analysis activity exists in the none state while preliminary customer communication
is completed. After that, it makes a transition to the underdevelopment state. If the
customer wants to change or add any requirement, the analysis activity will move
from underdevelopment state to the awaiting changes state.
The concurrent development model depicts the series of events that will trigger
transitions from state to state for each of its activities. It is also often used as the
element for the development of client/server applications. In client/server application,
concurrency is achieved in two ways as follows:
1. System and component can be modelled using state-oriented approach and
it occurs simultaneously.
2. Typical application is performed with many components that can be designed
and realised concurrently.

Concurrent development model can be used in all types of software project. It

provides accurate picture of the present state of a project. A network of activities
is developed when using concurrent development model rather than a sequence.
Events generated within the activity network trigger transitions among the states
of an activity.
The component assembly model

Different software programs were built to satisfy the different customer needs before
the concept of system development life cycle had been introduced. It was a long time
ago and millions of programs have been developed for different reasons and needs.
A lot of time is spent by programmers on developing a single program.
To find a solution, a software development life cycle plan called component assembly
model had been created. The development team using this model finds available
components and integrates it to build a system instead of starting over with different
codes and languages. Component assembly models are iterative models where some
parts of activities will be repeated until it gets the best prototype.
Component assembly model uses the available tools and GUIs to build software.
However, component assembly model also uses a lot of previously made components.
Therefore, it does not use Software Development Kits (SDKs) to develop the system
but integrates powerful components together. What the software development team
needs to do is just identify the user requirement, look for the components, and then
integrate it.
In reality, the component assembly model is not as easy as it seems. It is a very
challenging model whereby there are stumbling blocks that stop the use of this
component assembly model. Generally, the stumbling blocks are:
1. The previous program is not optimised for this model
The development team cannot just simply take out any component and use
them in their programs. There are so many things that need to be considered.
One of the matters is the incompatibility of the tools for development and
framework. If the systems do not have the same framework, it will be timeconsuming for the development team to adjust the software compared to
creating a new one. The development team will also find it hard if the system
uses different types of development tools. They need to revert to another
program just to create a system under the same framework.
2. The component that needs to be evaluated must be independent of the
whole program
A positive comment about the component does not necessarily mean it will
be good for your system. The software development team will look at the
role of the component but it will always be a challenge when the component
is integrated into the new system. It will also give us a hard time when
improving the system if the framework of the component is different.
UNIT 4 47
Development models
3. Close-ended components
This is another problem in software development. These components are
created to answer a specific need but to combine with the new system is
really impossible. This is because the language used in the component is
not compatible with the new system. You can modify the component but
that will be the same as creating a new component and that is not the aim
of the component assembly model.
4. Licensing
The new system that has other integrated components cannot be called an
independent system since it uses a collection of different programs. There
is also no formal licensing scheme on using components. Sometimes, the
software development team cannot tell whether their components have been
combining other programs without their knowledge.
Even with stumbling blocks in the component assembly model, some technologies
can be used to solve the problem. So, let us look at the technologies:
1. Mash-ups
Software development team can use different frameworks to make a
single program using the JavaScript and eventually Ajax was created.
OpenAjax Alliance had been created by IBM Company. It will ensure the
interoperability of various frameworks.
2. Commercialisation
Nowadays, there are a lot of online companies offering components for the
software. Software development team can easily get the components that
they want and put it into their system. It is assured that the component can
work with the new program since it is a commercial component.
3. Best practice
Since system is constantly being developed around the world, software
development team knows it is important to synchronise the frameworks
and platform so that the component can be reused later.
Current technologies and methods enable the component assembly model
to be worked out. It could offer benefits to large-scale projects. It also brings
benefits to large companies since they are familiar with the industry and
have tools to develop their own system.

Summary
Spiral model is developed to overcome the disadvantages of the
waterfall model. A highly skilled person is required when developing
using spiral model. In spiral model, the process needs to be iterated
more than once and therefore demands more time. Therefore, it is
somehow an expensive task.
The four activities in spiral model are planning, risk analysis,
engineering and evaluation. The concurrent development model
can be identified as a series of major technical tasks, activities and
their relation states.
Component assembly model is an iterative model where some
parts of activities will be repeated until it gets the best prototype.
Even with stumbling blocks in the component assembly model,
technologies can be used to overcome them.
The similarity among these three models is that all of the models
are using iterative approach. The process will be repeated until the
desired result is achieved.
Self-test 4.5
1. The four activities in spiral model are
A. determine objective, risk analysis, developing and testing,
planning.
B. determine objective, designing, integrating, implementing.
C. planning, designing, engineering, evaluation.
D. analysing, creating, integrating, planning.
2. Below are the advantages of spiral model EXCEPT

A. The system is produced early in the stage of software life
cycle.
B. The success of the project is highly dependent on the risk
analysis.
C. You will have a high amount of risk analysis.
D. This model is good for large and critical projects.
UNIT 4 49
Development models
3. In which phase in the spiral model will the development team

take feedback from customers and evaluate it?
A. Testing
B. Determine objectives
C. Analysing
D. Planning
4. ____________ refers to the means/methods the software

development team can achieve the components from the online
companies.
A. Best practise
B. Technologies
C. Commercialisation
D. Licensing
5. You can modify the component but that will be the same as
creating a new component and that is not the aim of the
component assembly model. This statement refers to
A. modification
B. mash up
C. licensing
D. close-ended components
6. System and component can be modelled using state oriented

approach and it occurs separately.
A. True
B. False

Feedback
Activity 4.2
As the name (spiral model) implies, the fourth phase involves
preparing to go back around to start again from quadrant one,
with the previous system that you have already built last time. The
idea is to iterate round the quadrants through the entire life of the
development until it satisfies the customer needs. In this way, you
can figure out what you did wrong in the previous phase and plan
what you need to do next.
UNIT 4 51
Development models
4.6 Prototyping Model

Objectives
1. List types of prototyping.
2. List the activities in prototyping model.
3. Describe the limitation of prototyping model.
4. Describe the advantages of prototyping model.
Introduction
The prototyping model begins by gathering the needed requirements. The software
development team will meet customers or project sponsors to define the overall
objectives of the software. They will also identify the requirement areas which
require further definition.
Typically, customers have their expectation in the system development. Prototype
model reflects an attempt to increase flexibility of the development process by making
the customers interact and experience the software while the development team works
on the system. In this section, we have broken this section down into four parts:
1. The prototyping model approach.
2. Steps in prototyping model.
3. Limitation of prototyping model.
4. Advantages of prototyping model.
The prototyping model approach

Software is created in regular phases in the traditional system development life cycle.
Usually, it has phases such as planning, design, testing, documentation and deploying.
Even though the traditional method looks easy to manage, sometimes, the structured
creation of a system makes it harder to be modified before the system is deployed.
Therefore, system analysts and design teams have developed a new model called
the prototyping model. It is one of the system development methods. Prototyping
model is built, tested and then reworked as necessary until the acceptable prototype
is developed before a system can be deployed.

There are two major types of prototype that are based on their development planning
which are as follows:
1. Throwaway prototyping
It represents the creation of a model that will be discarded after the final
delivery of the system. It is also called close-ended prototyping. After
identifying the requirement, a simple design will be developed to show the
users what the product may look like. It involves creating a working model
of the system in different parts at the very early stage. The method used is
informal but the users can re-examine their expectations and clarify their
needs. When it has been achieved, the prototype model will be thrown away
and the system is formally constructed based on the prototype.
Prototypes resemble the actual system in terms of appearance, interaction
and timing according to the fidelity. To create a low fidelity, there is one
method for the throwaway prototype which is paper prototyping. It is first
implemented in paper and pencil and then mimics the function of the
actual system. To build a high fidelity Throwaway Prototype is to use a GUI
Builder that creates a dummy design where the system does not provide any
functionality.
2. Evolutionary prototyping
It is also called breadboard prototyping. The objective is to build a very
robust prototype in a structured manner and constantly refine it. When
developing using this kind of prototype, the system is continuously refined
and built. This allows the software development team to add requirements
or make changes during the phase.
Since the prototype is continuously refined, it indirectly builds the maturity
of the system. The software development team can focus on creating parts
of the system that they understand instead of working on the whole system.
When the software development team deploys the system to user, the user can detect
opportunities for new good function and give comments to the development team.
The team can then take this request, save and use it for other projects in the future.
Steps in prototyping model

A prototype model offers the best approach to developing systems where the detailed
input, processing, or even output requirements are not certain. In most development,
the first system built is barely usable. This is because it may be too big, too slow
and awkward to use. Since there are no alternatives, the development team needs to
start again but it will become smarter. Finally, the development team will develop
a design that will solve the customers problems.
UNIT 4 53
Development models
Listen to
customer
Build or revise
mock up
Customer test
drive mock up
Figure 4.11 The prototyping paradigm
Figure 4.11 shows the prototyping model paradigm. It is an iterative process whereby
it will repeat the process of trial and error until it achieves the acceptable prototype.
There are several basic steps in the prototyping model:
1. When building a system, the new requirements are defined as detailed as
it can be. This includes interviewing the customer or looking at the aspects
of existing system.
2. Create the preliminary design.
3. From the preliminary design, a first prototype is constructed.
4. The evaluation for the first prototype will be done by the customer, where
strengths and weaknesses will be noted. The development team collets the
data and analyses it.
5. Based on the users comment, the first prototype will be modified and
reconstructed as a second prototype.
6. The same goes for second prototype; it will be evaluated by the customers
or users.
7. This process will be iterated until an accessible prototype has been defined.
8. The final system will be developed based on the final prototype.
The prototype serves as a mechanism for identifying user requirements. If a working

prototype is develop, the software development team will use the existing system
fragment or apply tools such as report generators or window managers that will
allow the working systems to be generated quickly.

When implementing using prototyping model, the users get a feel of the actual
system and the software development team gets to build the system immediately.
The first prototype can be considered the first system for the customer to use. That is
why the customer and software development system like the prototyping paradigm.
Activity 4.3
From the previous section, we can see that prototyping had been
applied in spiral model. From your point of view, what is the
difference between prototype model and spiral model?
Limitation of prototyping model

Prototyping model has been described as the best approach as the user can get a feel
of using the actual system in the first prototype. Yet, there are also problems that
may occur when using prototyping model. Let us look at the reasons:
1. After developing the first prototype and showing it to the customer, the
customer might not be unaware that the prototype was developed under a
rushed condition. It is difficult to create a document for this software since
it is frequently changing.
2. There are also chances that the software development team may have
developed a prototype with flaws but did not correct it. There is always a
chance of designer flaws since the prototypes are not yet complete.
3. In order to have a prototype working quickly, the software development team
may endanger implementation by leaving out important requirements.
Initially, an inefficient algorithm may be implemented and inappropriate
operating system or programming language may be used simply to
demonstrate capability in the short term. After a duration of time, the
software development team may become familiar with these choices and
forget to change them.
Prototyping can be an effective model for software engineering although problems

may occur. The important part is to identify the rules of the game at the beginning
when the customer and software development team must both agree that the
prototype is developed to offer a mechanism for identifying requirements. Then,
it will be discarded and actual system will be implemented with quality and
maintainability.
UNIT 4 55
Development models
Advantages of prototyping model

There are advantages when using prototype modelling in developing a system.
Prototyping produces capable model for system development even though there are
limitations. Let us look at the advantages of prototype modelling:
1. One of the benefits when developing a system using prototype model is that
it has a time frame for development. More effort can be put into developing
the actual system than preparing documentation. In this method, the actual
system can be released in advance.
2. The division of responsibility when working on the prototype is also different.
This is because there are no stages of work in prototyping model. Everyone
in the development team needs to do the same thing at the same time.
3. Since the development team members are all working at the same time, the
man hours in the development process will be reduced. The work will become
even faster. It is also more efficient as the development team members will
share ideas regarding the issues faced.
Nowadays, prototyping model has become popular because of their advantages.

Customers prefer to see the system from the beginning so that they are familiar
with the system.
Summary
Prototyping model is built, tested and then reworked as necessary
until the acceptable prototype is developed before a system can be
deployed. There are two major types of prototype that are based
on their development planning, throwaway prototyping and
evolutionary prototyping.
A prototype model offers the best approach to developing a system
that has uncertain details for input, processing, and even output
requirement. There are several basic steps in the prototyping model
including identify requirement, create preliminary design, develop
first prototype and show it to the customer to review. These steps
will be repeated until the customer is satisfied with the result.
Any earlier changes that you make in development life cycle will not
cost you a lot towards the end of the project since there is nothing
at that point to redo. The more effort you put in developing the
actual system, the more time you can save.

Self-test 4.6
1. Which of the following terms are the two major types of
prototype that are based on their development planning?
A. Throwaway, Evolutionary
B. Throwaway, Preliminary
C. Preliminary, Evolutionary
D. Throwaway, Risky
2. In most developments, the first system built is usually barely

usable. Why does this situation happen?
A. The system is too new.
B. The system is too big and too slow.
C. The system does not achieve the customer requirement.
D. The system is too good to be true.
3. The prototyping model paradigm shows an iterative process.

Which of the following is not in the process?
A. Listen to customer
B. Build mock-up
C. Revise mock-up
D. Analysing requirement
4. The prototype serves as a ____________ for identifying user

requirements.
A. objects
B. attributes
C. mechanism
D. entities
5. Prototypes resemble the actual system in terms of the following

aspects EXCEPT
A. Appearance
B. Interaction
C. Timing
D. Cost
UNIT 4 57
Development models
6. The system can also be created using a lot of comments and

reviews but only from the programmers.
A. True
B. False
Feedback
Activity 4.3
We can use prototype model when the requirement of the customers
is not clear and it is supposed to be changed. Different from spiral
model, prototype does not focus on any risk management. Spiral
model is built using the features in prototyping model.

UNIT 4 59
Development models
4.7 Rapid Application Development

Model
Objectives
1. Describe rapid application development model.
2. List the phases of rapid application development model.
3. Discuss the drawback of rapid application development model.
Introduction
Rapid application development is a software developing methodology that uses
minimal planning. Using the rapid application development model, the planning of
software development is interleaved with writing the software itself. Due to the lack
of preliminary planning, it allows software to be developed much easier and faster
while changing the requirements. We have broken down this section into three parts:
1. Overview of rapid application development model.
2. Process of rapid application development model.
3. Suitability of rapid application development model.
Overview of rapid application development model

Rapid application development model is used to describe a software development
process. It involves with iterative development and prototype development.
According to Whitten (2004), this model is actually a merger of various structured
techniques with prototyping techniques to cause a faster and greater progress of
software system projects.
In the 1970s and 1980s, software engineers applied other models such as structured
system analysis and design method or even waterfall models. There were problems
with these methodologies whereby it took a long time to build and the requirements
need to be changed before the system was completed. This has resulted in inadequate
development or sometimes the system becomes unusable. Such problems led to the
creation of rapid application development.
Structured technique and prototyping that have been applied in the rapid application
development model are especially useful in defining users requirements and designing
the final system. The process starts with using structured technique to gain the

development of preliminary data models and business process models. In the next
stage, verification of requirement will be made by using prototyping. When applying
this, the data and process models are refined since it is an iterative process.
Nowadays, the term rapid application model is used in a broader, more general sense
that brings out various methods which aim to speed up the development application,
such as the use of framework for web application. Rapid application development
is an idea that system can be delivered faster with better features through:
1. Using workshops and focus groups to gather requirement.
2. Using prototyping and user testing for the design.
3. Using reuse software component.
4. A firmly fixed step schedule that includes design improvements to the next
product version.
5. Using less formality when doing the reviews and communication between
teams.
There are some companies that offer products that have some or all of the tools for
rapid application development, including requirement gathering tools, prototyping
tools, computer aided software engineering tools, and language development
environments such as JAVA platform groupware for communication among
development team members and testing tools. The rapid application development
model usually inherits software reuse and embraces the object-oriented programming
technologies.
Process of rapid application development model

Rapid application development model emphasises extremely short development cycle.
This model is an adaptation of the linear sequential model whereby it is achieved
by using component-based construction. The rapid application development model
process can help a software development team to create a functional system within
a very short amount of time if the requirements are well understood.
The rapid application development model has the following phases:
1. Business modelling
The information moving along the business functions is modelled in a way
that answers the questions as below:
a. What kind of information drives the business process?
b. What kind of information is generated?
UNIT 4 61
Development models
c. Who is responsible for generating it?

d. Where does the information flow to?
e. Who is responsible for processing the information?
2. Data modelling
The information movement identified as part of the business modelling
state earlier is refined into a set of data objects that are required to support
the projects. The characteristic of information is called attributes and the
relationship between these objects is defined.
3. Process modelling
The data objects identified in the data modelling stage are converted to
achieve the information movement necessary to implement a business
function. Processing descriptions are developed for adding, deleting,
retrieving or modifying a data object.
4. Application generation
Rapid application development assumes the use of fourth generation
technique. Automated tools are used to assist the progress of construction
of the software in all cases.
5. Testing and turnover

Many of the program components have been tested since the rapid
application development model process emphasises reuse. This gives effect of
reducing the overall testing time. However, testing for the new components
must be done. The same goes for all interfaces which must be fully exercised.

Team 3
Business
Modeling
Team 2
Business
Modeling
Team 1
Business
Modeling
Data
Modeling
Data
Modeling
Data
Modeling
Process
Modeling
Process
Modeling
Process
Modeling
Application
Generation
Application
Generation
Application
Generation
Testing &
Turnover
Testing &
Turnover
Testing &
Turnover
60 to 90 days
Figure 4.12 Rapid application development model
The rapid application development model is shown in Figure 4.12. It is a candidate

for rapid application development when a business application can be modularised in
a way that enables each major function to be completed. Each of the major functions
can be addressed by a division of the rapid application development team and then
combining it to form a whole system.
Suitability of rapid application development model

Rapid application development takes advantage of automated tools and techniques
to construct the process of building information systems. Rapid application
development exchanges hand design and coding operation which depends on the
individual, with automated design and coding that results in a more stable process.
It also delivers more capable operations which are faster and less error-prone than
hand coding, hence developing a more stable system.
All types of rapid application developments have the potential for having a good
framework for faster development with improvement of the system quality. To enable
faster development, the rapid application development model approach may involve
compromises in functionality and performance. The rapid application development
model approach has drawbacks as follows:
UNIT 4 63
Development models
1. This model needs sufficient human resources to create the right number of
rapid application development teams for large but scalable developments.
2. Building the components necessary for rapid application developments will
be problematic if a system cannot be properly modularised. The rapid
application development may not work if high performance is an issue
through tuning the interface to system components.
3. When the technical risks are high, this model may not be appropriate for
developing the system. This problem may occur when the new software
needs a high degree of interoperability with existing computer programs.
Activity 4.4
Rapid application development uses minimal planning when
developing software. From your point of view, when is the best
time to use rapid application development? What are the factors
that encourage you to use the rapid application development model?
Summary
Rapid application development model allows organisations to build
software applications faster, better and cheaper. By implementing
rapid application development model, the project does not have
to handle a bundle of documentation. It is also a concept that
allows systems to be developed faster and with high quality through
gathering requirements using focus group, reuse component and
less formality in reviewing the projects.
Some companies offer products that have all or some of the tools
for rapid application development that can be applied to hardware
development as well. Some programming languages are offered in
visual packages and are often defined as supplying rapid application
development.

Self-test 4.7
1. What was the problem that led to the creation of rapid
application development?
A. Time-consuming and the lack of user requirement
B. Cost efficiency
C. Lack of experienced software developer
D. Inadequate programming language
2. In rapid application development model, verification of user

requirement had been made using
A. design
B. prototype
C. customer review
D. testing
3. Rapid application development can be developed faster through

the following EXCEPT
A. Using a reuse component
B. Using a focus group
C. Using a prototype
D. Using a formal review
4. Rapid application development is a _____________ whereby its

processes work to reuse existing program component when
possible or create a reusable component when necessary.
A. data modelling
B. process modelling
C. application generation
D. testing
5. This model needs sufficient human resources to create the

right number of rapid application development teams for large
but scalable developments. This statement refers to the model
as its
A. cycle
B. definition
C. advantages
D. drawback
UNIT 4 65
Development models
6. The project will succeed when the developers and customer

focus on their own work.
A. True
B. False
Feedback
Activity 4.4
Here are examples of answers and ideas that you can use.
1. When you know that the customer needs to be involved
throughout the life cycle.
2. Project can be time-boxed.
3. The project has low technical risks.
4. The software development teams shall include programmers
and system analysts who are really experienced in it.
5. The development needs quick result.

UNIT 4 67
Development models
Summary of Unit 4
Summary
This unit addressed software development models to the students,
with the process of each of the models being examined in
different sections and subsections. Previously, big organisations
implement process methodologies to develop their software. Their
methodologies are raw whereby its unpredictable and sometimes
takes a long time to achieve the objective of the project.
It is a decades-long goal to find solid methodologies, which can
define repeatable and predictable processes, in order to improve
productivity and quality of the project. Some system analysts
try to systematise or formalise the seemingly unmanageable task
of developing software while others apply project management
technique to develop the software.
Software project can easily be overbudget and delivered late without
proper planning from the project management. Effective project
management appears to be lacking in large numbers of software
projects that did not meet expectations. The expectations should be
set in terms of cost, delivery schedule, or its functionality. Therefore,
in this unit, we give you several models created by different system
analysts to make the cycle of project management smoother and
avoid any major risks.
In this unit, there are several models and methodologies that use
SDLC models such as agile distributed development method, spiral
model, prototyping model and rapid application development
model. Object-oriented analysis and design and component-based
software engineering focuses on the use of component inside the
software. But, the concept of developing it still uses the SDLC
phases. Each of the models and methodologies has different phases
and steps.
Plan
Minimal
Planning
Determine
the objective
Determine
basic
requirements
Lack of
extensive
pre-planning
Phase/
Method
Agile Method
Spiral Model
Prototype
Model
Rapid
Application
Development
Model
Developers
will re-factor
the code
continuous
development
Design must
be simple
as long as
fulfill the
requirement
Using reuse
software
component
The initial prototype is

developed that includes only
user interfaces
Design and coding depends

on the requirement given
Coding
Design
Users interact with systems

analysts and develop models
and prototypes that represent
all system processes, inputs,
and outputs
Develop
preliminary
estimates of
development
time, cost
and effort
Identify
resolve risk
Requirement
determine
by the time
available and
priority
Analysis
Testing for
the new
components
must be
done
The
customers
examine the
prototype
and provide
feedback on
additions or
changes
Verify the
product for
this iteration.
After that,
plan for the
next iteration
Focused
on quick
response to
change and
continuous
development
Testing
All tests must

past before
integration
Using the
feedback
both the
specifications
and the
prototype
can be
improved
All tests must

past before
integration
All tests must

past before
integration
Operation &
Maintenance

Table 4.1 Brief activities that involve each method related to SDLC phases
Each of the models and methodologies should contain the basic parts
of SDLC activities such as planning, analysis, design, coding, testing
and operation and maintenance as shown in Table 4.1. They also
have their own limitations and advantages. Therefore, before you
infer any models and methodologies, you need to see the condition
of the project itself so that you can have a better development that
produces high quality projects.
UNIT 4 69
Development models
Suggested Answers to Self-tests

Feedback
Self-test 4.1
1. A
2. B
3. A
4. C
5. D
6. B
Self-test 4.2
1. A
2. B
3. D
4. C
5. D
6. B
Self-test 4.3
1. B
2. B
3. D
4. C

5. D
6. A
Self-test 4.4
1. A
2. B
3. D
4. C
5. D
6. B
Self-test 4.5
1. A
2. B
3. D
4. C
5. D
6. B
Self-test 4.6
1. A
2. B
3. D
4. C
UNIT 4 71
Development models
5. D
6. B
Self-test 4.7
1. A
2. B
3. D
4. C
5. D
6. B

UNIT 4 73
Development models
References
Boehm, B (1985) A spiral model of software development and enhancement
Computer, May: 61 72.
Davis, A and Sitaram, P (1994) A concurrent process model of software development,
Software Engineering Notes, 19(2): 38 51.
Drobna et al. (2004) Piloting XP on Four Mission-Critical Projects. IEEE Software,
21 (6), 70 5.
Jacobson, I, Booch, G and Rumbaugh, J (1999) The Unified Software Development
Process, Addison-Wesley Professional.
Taylor, J (2004) Managing Information Technology Projects, p.39.
Lau and Wang (2007) IEEE Transactions on Software Engineering, 33(10):709 724.
Meyer, B (1988) Object-oriented Software Construction, 2nd edn, USA: Prentice-Hall.
Rising L and Janoff, N S (2000) The Scrum software development process for small
teams, IEEE Software, vol. 17, no. 4, pp. 26 32.
Schwaber, K and Beedle, M (2001) Agile Software Development with Scrum,
Englewood Cliffs, NJ: Prentice Hall.
Sommerville I (2010) Software Engineering, International Edition, 9th edn, USA,
Pearson.
Sutherland, J, Viktorov, A, Blount, J and Puntikov, N (2007) Distributed Scrum:
Agile project management with outsourced development teams. 40th Hawaii
International Conference on System Sciences, Hawaii: IEEE Computer Society
Whitten, J L, , Bentley, L D and Dittman, K C (2003) Systems Analysis and Design
Methods, 6th edn, USA: Pearson.

UNIT 4 75
Development models
Glossary
Ajax
Asynchronous JavaScript and XML.
Backlog
A reserve or accumulation, as of work, inventory.
Client/server applications
Software functionality is divided between

clients, normally PCs, and server a more
powerful computer that typically maintain the
database.
Configuration interface
Allows you to edit all the settings that control

its behaviour.
Debugged
Error correction.
Elicit
To evoke, to induce.
Fidelity
Precision.
Glue code
Generate additional code to attach the

component.
Pragmatic
Pertaining to a practical point of view or

practical considerations.
Sprint
Move at full speed, especially for a short time

and distance.
Syntactic
Determined by syntax.

Software Development Models U4 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Software Development Models U4 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

UNIT 3 A

B WAWASAN OPEN UNIVERSITY

EXTERNAL COURSE ASSESSOR

2012 Wawasan Open University

Wawasan Open University

54, Jalan Sultan Ahmad Shah, 10050 Penang.

4.1 System development life cycle

Understanding system development life cycle

Key aspects of system development life cycle

4.2 Objected-oriented analysis and design

Understanding object-oriented analysis and design

4.3 Agile distributed development method

An agile view of process

D WAWASAN OPEN UNIVERSITY

4.4 Component-based software engineering

Understanding component-based software

Component-based software engineering process

Component-based software engineering for reuse

Component-based software engineering with reuse

Suggested answers to activity

4.5 Spiral model and others

Overview of spiral model

The spiral model process

Concurrent development model

The component assembly model

Suggested answers to activity

4.6 Prototyping model

The prototyping model approach

Steps in prototyping model

Limitation of prototyping model

Advantages of prototyping model

Suggested answers to activity

4.7 Rapid application development model

Overview of rapid application development model

Process of rapid application development model

Suitability of rapid application development model

Suggested answers to activity

Suggested answers to self-tests

F WAWASAN OPEN UNIVERSITY

2 WAWASAN OPEN UNIVERSITY

4.1 System Development Life Cycle

Understanding system development life cycle

4 WAWASAN OPEN UNIVERSITY

Development Life Cycle models as below:

Key aspects of system development life cycle

Figure 4.1 System development life cycle model

Problem identification and project initiation

iii. System proposal

6 WAWASAN OPEN UNIVERSITY

The specification for the new system based on user requirement.

Functional requirement that shows the relationship in the new

iii. List of attributes and entities.

What is being done?

When is it being done?

iii. Who is doing it?

Why is it being done?

How is it being done?

vi. How can it be improved?

If we look at the questions, system analysis is more of a thinking process

Preliminary or general design

Structured or detailed design

The hardware and software platform including the programming

Define the system output precisely.