Software Development Models U4 PDF
Software Development Models U4 PDF
Analysis techniques
Unit 4
TCC 125/05
Software Development
Models
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
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.
UNIT 4 C
Development models
Contents
Unit 4 Development Models
Unit overview
Unit objectives
Objectives
Introduction
13
Objectives
13
Introduction
13
13
Object-oriented analysis
14
Object-oriented design
17
23
Objectives
23
Introduction
23
23
Extreme programming
25
Scrum
27
31
Objectives
31
Introduction
31
31
33
34
35
Component composition
36
39
41
Objectives
41
Introduction
41
41
43
44
46
50
51
Objectives
51
Introduction
51
51
52
54
UNIT 4 E
Development models
55
57
59
Objectives
59
Introduction
59
59
60
62
65
Summary of Unit 4
67
69
References
73
Glossary
75
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.
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
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.
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.
UNIT 4 5
Development models
6. Operations and
maintenance
1. Planning
5. Testing
2. Analysis
4. Coding
3. Design
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.
ii.
Background analysis
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.
ii.
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.
ii.
UNIT 4 7
Development models
iv.
v.
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.
ii.
Design forms.
Design coding.
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
UNIT 4 9
Development models
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.
ii.
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.
ii.
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.
ii.
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
UNIT 4 13
Development models
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.
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.
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
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.
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.
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
UNIT 4 23
Development models
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
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
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.
Evaluate System
Release Software
Develop/Integrate/
Test Software
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
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.
Assess
Select
Review Develop
Sprint Cycle
Project Closure
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.
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.
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
UNIT 4 31
Development models
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.
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
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
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.
UNIT 4 35
Development models
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?
Outline
System
Requirement
Identify
Candidate
Components
Modify Requirements
According to Discovered
Components
Architectural
Design
Identify
Candidate
Components
Compose
Components
to Create
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.
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)
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.
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
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.
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
Determine
objective,
alternatives and
constraint
Evaluate
alternative,
resolve risk
Risk
analysis
Prototype
Design
Test
Plan
Develop and
verify next
level system
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.
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?
UNIT 4 45
Development models
None
Under
development
Awaiting
changes
Under
review
Under
revision
Baseline
Done
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.
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.
UNIT 4 49
Development models
Feedback
Activity 4.2
Here are examples of answers and ideas that the student can use.
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
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.
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.
UNIT 4 53
Development models
Listen to
customer
Build or revise
mock up
Customer test
drive mock up
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.
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?
UNIT 4 55
Development models
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
UNIT 4 57
Development models
Feedback
Activity 4.3
Here are examples of answers and ideas that the student can use.
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
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.
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.
UNIT 4 61
Development models
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.
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
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
UNIT 4 65
Development models
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
Coding
Design
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
Using the
feedback
both the
specifications
and the
prototype
can be
improved
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
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
Backlog
Client/server applications
Configuration interface
Debugged
Error correction.
Elicit
To evoke, to induce.
Fidelity
Precision.
Glue code
Pragmatic
Sprint
Syntactic
Determined by syntax.