Software Development Models U2 PDF

UNIT 2 A
Software process management
Unit 2
TCC 125/05
Software Development
Models
Software Process
Management
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 2 C
Contents
Unit 2 Software Process
Management
Unit overview
Unit objectives
2.1 Process modelling
Objectives
Introduction
Goal of process model
Classification of process model
The waterfall model
The incremental development
Suggested answers to activity
14
2.2 Design architecture
15
Objectives
15
Introduction
15
Understanding of architectural design
15
Architectural design decisions
17
Architectural patterns
Layered architecture
Database architecture
Client-server architecture
Pipe-and-filter architecture
19
20
21
22
23
D WAWASAN OPEN UNIVERSITY

2.3 Software quality
27
Objectives
27
Introduction
27
Definition of software quality
27
Software quality measurement
28
Quality standards
34
2.4 Risk management
41
Objectives
41
Introduction
41
Software risk area
41
Risk projection
Risk analysis
Risk planning
44
45
47
Risk monitoring
48
51
Summary of Unit 2
53
Suggested answers to self-tests
55
References
57
Glossary
59
UNIT 2 1
Unit Overview
nit 2 is organised into four sections. In section 2.1, you will learn about process
modelling in software development. You will be exposed to two types of process
modelling where each of it has its own behaviour.
In section 2.2, you will be exposed to design architecture. The design should be
according to specific architecture. The architectural design process will give an
output of an architectural model. There are several architecture patterns that you
will learn in this section.
In section 2.3,you will learn about quality in software creation. There are specific
standards used for ensuring customer satisfaction in software creation.
In the last section, you will be introduced to risk management.This is also an
important part in software development because you must be aware of the risk and
have the knowledge to manage it carefully depending on the situation.
Unit Objectives
By the end of Unit 2, you should be able to:
1. Describe the process modelling in software development.
2. Identify the design architecture.
3. Describe the software quality assurance.
4. Identify the risk area and project it.
2 WAWASAN OPEN UNIVERSITY

UNIT 2 3
2.1 Process Modelling

Objectives
By the end of this section, you should be able to:
1. List activities in software processes.
2. Describe classification of process model.
3. Describe activities in waterfall model.
4. Identify benefits of incremental model.
Introduction
The process of developing software can be formed based on specific model according
to the type of software that you want to build. Process modelling in software
development plays an important role in software development. It helps the developers
to create software in a well-organised way.
Many process models have been introduced by experts in software development.
In this section, two kinds of constantly used process models will be introduced to
you. This section is divided into four parts as follows:
1. Goal of process model.
2. Classifications of process model.
3. The waterfall model.
4. Incremental process model.
Goal of process model

Before we go further to any process model, we need to have an understanding related
to software process. Pressman (2001) defined software process as an approach to
engineer a software. It consists of a set of activities that lead to the production of
a software product. We usually emphasise the activities when we discuss about the
processes in the production of a software product. The typical activities involved in
software processes include:
1. Software design.
2. Software configuration management.

3. Unit testing.
4. Software validation.
5. Software specification.
6. Document preparation.
7. Software planning.
These are only some of the activities involved in software processes. It is complex
and relies on people to make the decisions and judgements. Software processes are
categorised as either plan-driven processes or agile processes. Using a plan-driven
process, the activities are planned in advance and progress is measured against the
plan. The opposite is true when using agile processes. It is not easy to manage
since it is incremental and frequently changes the process according to customer
requirement. Therefore, each process is suitable depending on the type of software.
Now, lets see the relations between software process and a process model. As you
have learnt, a software process contains a lot of activities involved in developing
software. Therefore, for the ease of software engineers, a process model has been
introduced. A process model simplifies and organises the activities involved in
software process. You can imagine the process model as a framework that can be
extended to create more specific software processes. According to Wikipedia, the
goals of specific models are:
1. Descriptive
This means that it will track what actually happens during the process. The
software development team will take the point of view of other software
engineers to determine the improvements necessary to make the software
perform more effectively and efficiently.
2. Prescriptive
This defines the desired processes and how the software development team
might carry out the work. The software development team needs to set and
follow the rules, guidelines and behaviour patterns so that they can achieve
good performance. It depends on the team having strict enforcement of
rules or flexible guidance.
3. Explanatory
It provides the explanation for the rationale of the processes. It establishes
a link between the processes and the requirements that the model needs to
fulfil for the development.
UNIT 2 5
The process model can also be described as a navigational structure which supports
the dynamic selection of the objective to be achieved. The models represent an
abstraction of the process that can be used to explain different activities in software
development.
The process models covered in this section are:
1. The waterfall model
It is a model that contains process activities including specification,
development, validation and evolution and represents them as separate
process phases such as requirement specification, software design,
implementation and so on.
2. The incremental model

This model interleaves the activities of specification, development and
validation. The software development team will use it in a series of versions,
with each version adding new requirement or functionality to the previous
version.
The process models can be used together especially for large system development.
Sub-systems within large system may be developed using different process model.
The software development team may use a waterfall-based process for parts that are
well understood and that can be specified. Software with requirements that may be
difficult to specify in advance may be developed using an incremental approach.
Classification of process model

A software development team needs to develop a strategy on how to include the
activities in process development. Therefore, a process model will be developed
depending on the classification of the project and application, the methods and
tools to be used and the control and deliverables that are required. According to
Wikipedia, classification of process model is based on the following factors:
1. Coverage
As stated by Dowson (1998), there are five types of coverage for which a
process model can be defined differently:
a. Activity-oriented: It is related to a set of activities conducted for the
specific purpose of product definition; a set of partially ordered steps
intended to reach a goal.
b. Product-oriented: It is a series of activities that cause sensitive product
transformations to reach the desired product.

c. Decision-oriented: It is a set of related decisions conducted for the specific

purpose of product definition.
d. Context-oriented: It is a sequence of contexts causing successive product
transformations under the influence of a decision taken in a context.
e. Strategy-oriented: It calls for building models to represent multi-approach
processes and plan different possible ways to elaborate the product based
on the notion of intention and strategy.
2. Alignment
According to Rolland and Pernici (1998), there can be different kinds of
processes such as:
a. Strategic processes
These processes often require human cooperation whereby they need
to investigate alternative ways of doing things and eventually produce a
plan for doing it.
b. Tactical processes
These processes are more concerned with the tactics to be adopted for
actual plan achievement.
c. Implementation processes
These are the lowest level of processes. These processes are directly
concerned with the details of the what and how of plan implementation.
3. Granularity
As Rolland and Pernici (1998) state, this factor refers to the detail level of
the process model and affects the kind of rules, explanation and trace that
can be provided. Fine granularity provides more detailed capability. Typically,
software development team prefer to use a fine-grained process model for
the details of the model with proper instructions and important execution
dependencies such as the dependencies between components.
Therefore, software process model is very important in standardising the format for
development projects. A survey must be done by the software development team on
the important basic model. There are hundreds of different models and the software
development team needs to choose a suitable process model for their project.
UNIT 2 7
The waterfall model

As Royce (1970) states, the first published software development model was derived
from more general system engineering processes. It is illustrated in Figure 2.1 and is
known as the waterfall model. This is because of the flows that shower down from
one phase to another. The waterfall model is an example of a plan-driven process
whereby you must plan and schedule all the process activities before working on them.
Requirement
Analysis
System and
Software Design
Implementation
and Unit Testing
Integration and
System Testing
Operation and
Maintenance
Figure 2.1 Waterfall model
The process activities of the waterfall model reflect the fundamental development
activities as follows:
1. Requirement analysis
By interacting with the system users which include the stakeholders, we can
understand the requirements such as system services, constraint and system
goals. They are then defined in detail and serve as a system specification.
2. System and software design

System design involves architectural design. It describes the main blocks
and components of the system, interfaces and interactions. Therefore,
the hardware and software requirement will be defined. The goal of this
stage is to generate a documentation that includes all the design activities
which establish an overall system architecture. Software design involves
identifying and describing the fundamental software system abstractions and
its relationships. The interactions between modules are described and at the
end, the software development team shall come up with a software design
documentation which is the basis for the following implementation work.

3. Implementation and unit testing

In this phase, the software design is realised as a set of programs or program
units. Unit testing involves verifying that each unit meets its specification.
Each unit will be developed independently and can be tested for its
functionality.
4. Integration and system testing

During integration phase, the individual program units or programs are
brought together to be tested as a complete system. It is to ensure that the
software requirements have been met. After the system is tested, it will be
delivered to the customer.
5. Operation and maintenance

In this phase, the system is installed and put into practical use. The system
is handed over to the customer. The customer will check if the requirements
are implemented as expected. The customer will also validate if the system
follows the requirements. The software development team needs to be
prepared if there are any changes required during customer validation, which
is why we have a maintenance stage. Maintenance involves correcting errors
which were not discovered during the stage life cycle. It may also improve
the implementation of system units and enhance the system services.
According to the principle of waterfall model, the following phase should not start
until the previous phase has finished. Practically, these phases overlap and feed
information to each other. Waterfall model involves feedback from one phase to
another. Any documentation created has to be modified to reflect the changes made.
That is why waterfall model process is better when developing large-sized software
that requires more years of work since it covers every aspect in detail.
As has been stated earlier, the waterfall model is the oldest process model for software
processes. Therefore, as stated in Waterfal-Model.com, there are some disadvantages
when the waterfall model is applied such as:
1. Many software projects are dependent upon external factors. Therefore the
biggest factor will be the client. It often happens that the client will change the
requirements of the project. This will affect the normal plan of construction
and the functionality as well. The waterfall model does not work well in a
situation like this. If this happens, then a number of steps would go to waste
and there may be a need to start everything all over again. It is not even easy
to take out the cost estimate of each step since in the waterfall model, each
stage plays an important role.
UNIT 2 9
2. The other negative aspect of this model is that a huge amount of time is
also wasted. As we have learnt, in the waterfall model, we cannot execute
the next phase unless the first phase is successfully completed. Therefore,
while the software designers are still designing the software, the programmers
time is completely wasted.
3. Another disadvantage of this method is that the testing period comes quite
late in the developmental process; whereas in other developmental programs,
the designs would be tested a lot sooner to rectify the flaws at a stage when
time and money has not been wasted.
4. The use of documentation has its advantage but it is going to be wasted for
smaller projects. This is because it will take a lot of effort and time to prepare
the documentation.
Nowadays, waterfall model is often inappropriate for developing super-vast software.

This is because it will affect the cost estimates and time effort. However, it can serve
as a useful process in situations where the requirements are firmly implanted and no
changes are required right up to the completion of development.
Activity 2.1
Consider the following two development projects:
1. Development of a program for configuring mobile phones and
PDAs for mobile networks.
2. Development of an application for managing the ship autopilot
control system.
In your opinion, which of the above development is likely to better

correspond to the waterfall model?
The incremental development

The incremental development is a process that represents the idea of developing
preliminary implementation, exposing it to user so that they can comment, and
evolving it through several versions until the perfect system has been developed.
Figure 2.2 shows the incremental process model where you can see that specification,
development and validation activities are mixed with rapid feedback across activities.

Outline
Preliminary
Description
Version
Validation
Preliminary
Preliminary
Version
Version
Validation
Intermediate
Preliminary
Version
Version
Validation
Final Version
Figure 2.2 Incremental development
This process is better than the waterfall model for most businesses because it uses
an agile approach. It actually reflects the way we solve problems. In real life, when
people realise that they already made a mistake, they seldom work out a complete
problem solution for it in advance. They usually move towards finding the solution
immediately. The same goes for incremental model software process. Furthermore,
it is cheaper and easier to make changes in the software by developing the software
incrementally.
By applying this process, the first increment is often a core product. This includes the
most important and urgently required functions. This means that the customer can
evaluate the system at the early stage in the development. The customer evaluation
is very important so that we can be sure that the software delivers what is required.
As a result of evaluation, a plan is developed for the next increment. This process is
repeated following the delivery of each increment until it produces a product that
satisfies the customer requirement.
According to Sommerville (2010), there are three important benefits of using
incremental development:
1. The reduction in cost in changing customer requirements. The quantum of
analysis and documentation that has to be redone is much less than when
using waterfall model.
2. Using incremental development, customer will evaluate the development
work that has been done. Therefore, it is easier to get customer feedback since
they can see how much has been implemented. Customers can give comment
during the demonstration of the software.
3. Using incremental development, even without all functions included in
the software, more delivery and deployment of useful software can be given
to customer. Customers are able to gain value from the software earlier than
using a waterfall process.
UNIT 2 11
Nowadays, the most common approach to the development of application system

is incremental development. This is because the approach can be suitable for both
plan-driven and agile approaches. If the software development team intends to use
the plan-driven approach for their software processes, then the system increments are
identified in advance. If using agile approach, then early increment is identified and
the development of later increments depends on progress and customer priorities.
Sommerville (2010) states that from the management perspective, the incremental
approach has two problems:
1. The process cannot be seen. This means that the project leader needs to
regularly deliver to measure progress. If software is generated quickly, it is
not cost effective to come up with documents that reflect every version of
the project.
2. As the new increments are added, the system structure tends to degrade.
Changing it regularly tends to corrupt the system structure unless time and
money is spent on refactoring to improve the software. It becomes
increasingly difficult and costly when embodying further software changes.
You can develop a system using incremental development and present it to customers
for comment without actually delivering it in a complete product. Using incremental
development, the project leader can control how many team members should be
assigned to each phase. This may lead to reduction in cost estimation of effort that
you will learn in Unit 5.
Summary
The modelling of the software process refers to a process expressed
in the form of a model concept. Process model can also be seen as
a framework that can be extended to create more specific software
processes. There are three goals that you need to know in process
modeling, that is, descriptive, prescriptive and explanatory.
A process model that is to be developed depends on the classification
of the project and application, the methods and tools to be used and
the control and deliverables that are required. The classification of
process model is based on factors such as the coverage, the alignment
and the granularity.
The waterfall model has several phases that include requirement
analysis, system and software design, implementation and unit
testing, integration and system testing, and operation and
maintenance. Using waterfall model, you need to finish the previous
phase before starting the following phase. Practically, incremental
model phase overlaps and feeds information to each other.

The incremental model uses an agile approach. This process is

repeated following the delivery of each increment until it produces
a product that satisfies the customer requirement. You can present
the product to customers for comment without actually delivering
it in a complete product.
Self-test 2.1
1. The goals of a process model are as stated below except:
A. Descriptive
B. Prescriptive
C. Revolutionary
D. Explanatory
2. Which of the following is a term related to process model?

A. Activity oriented
B. Basic oriented
C. Design oriented
D. Component oriented
3. We can classify process model by its alignment. Which of the

processes below can help in the achievement of a plan?
A. Strategic processes
B. Tactical processes
C. Implementation processes
D. None of the above
4. Which of the following has lower level processes?

A. Strategic processes
B. Tactical processes
C. Implementation processes
D. None of the above
UNIT 2 13
5. The incremental model of software development is

A. A reasonable approach when requirements are well defined.
B. A good approach when a working core product is required
quickly.
C. The best approach to use for projects with large development
teams.
D. A revolutionary model that is not used for commercial
products.
6. The waterfall model is the oldest paradigm in software

engineering.
A. True
B. False
7. The advantage of incremental model is that it generates working

software quickly and early during the software life cycle.
A. True
B. False
8. The disadvantage of incremental model is each phase of iteration

is rigid and will overlap each other.
A. True
B. False

Feedback
Activity 2.1
The answer may vary depending on your ideas and creativity.
Development project number 2 is suited to the waterfall model in
its software process. This is because development project number
2 is considered a large-sized software development. It may take a
long time to develop it. It also needs detailed requirements and
involves a lot of external resources. Rather, project number 1 needs
faster development since mobile development is considered as a
super-vast software.
UNIT 2 15
2.2 Design Architecture

Objectives
1. Describe architectural design.
2. Explain design patterns.
3. Identify layered architecture.
Introduction
The design process is a sequence of steps that enable the designer to describe all
aspects of the software to be built. Architectural design begins by representing the
totality of the thing to be built and slowly refining the thing to provide guidance
for constructing each detail. This section is divided into three parts:
1. Understanding of architectural design.
2. Architectural design decisions.
3. Architectural patterns.
Understanding of architectural design

Architectural design represents how a system should be organised and designed to
reflect the overall structure of a system. It enables the software development team
to analyse the effectiveness of the design in meeting the requirements. In the model
of the software development process, architectural design is the first phase in the
software design process. It is the critical link between design and requirements
engineering as it identifies the main structural components in a system and the
relationship between them. The architectural design process will give an output
of an architectural model that describes how the system is organised as a set of
communicating components.
There is a significant overlap between the processes of requirements engineering
and architectural design. A system specification should not include any design
information. This is totally unrealistic except for developing very small systems.
Architectural decomposition represents the work of structure and organises the
specification.
Therefore, you might propose abstract system architecture as part of the requirements
engineering process where you connect a group of system function with large-scale
components or sub-systems. Then, you may use the architecture decomposition

to discuss the requirements needed with the customers. According to Sommerville

(2010), the software development team may design software architectures at two
levels of abstraction:
1. Architecture in the small
This is concerned with the architecture of individual programs. At this level,
Sommerville (2010) is concerned with the way that an individual program
is decomposed into components.
2. Architecture in the large

This is concerned with the architecture of complex systems that includes
other system or programs or program components. These systems will be
distributed over different computers and owned by different companies.
As Bosch (2000) states, software architecture is important because it affects the

performance, robustness, ability to distribute and maintainability of a system. He also
stated that individual components implement the functional system requirements.
The non-functional requirement depends on the system architecture.
According to Bass et al. (2003), the three advantages of explicitly designing and
documenting software architecture are:
1. Stakeholder communication
The architecture will be the high-level presentation of the system. Therefore,
it may be used as a focus for discussion by a range of different stakeholders.
2. System analysis
Analysis is needed when making the system architecture in the early stage.
Architectural design decisions have a deep effect on whether the system can
meet critical requirements.
3. Large-scale reuse
Systems that have similar requirements often have the same system
architecture. Therefore, it is possible to develop a system where the
architecture can be reused for other system.
Simple block diagrams are often used to model system architecture as in Figure 2.3.
Components are represented by boxes in the diagram. Boxes within boxes means
that the component has been decomposed to sub-components. The arrows mean
that data or control signals are passed from one component to another depending
on the direction shown.
UNIT 2 17
However, Bass et al. (2003) claim that these block diagrams are poor architectural
representations since it did not show the relationship between the components. The
differences between practice and architectural theory arise because there are two
ways in which an architectural model of a program is used:
1. As a method of facilitating discussion about the system design
A high-level architectural view of a system is useful for communication with
system stakeholders and project planning because it does not mess with
details. Stakeholders can relate to it and understand an abstract view of the
system. They can discuss the system as a whole without being confused by
details. The architectural model describes the key components that are to
be developed so that project leaders can start assigning people to plan the
development of the systems.
2. As a method of documenting an architecture that has been designed

The goal is to produce a complete system model that shows the different
components in the system, its interfaces and also the connections. A detailed
architectural description makes it easier to understand and expand the
system.
During the design process, block diagram is actually a good way to describe system
architecture. This is because it supports communication between people involved
in the process. However, if the architecture of a system is to be documented, then
it is better to use well-defined semantics for architectural description.
Architectural design decisions

Architectural design represents a creative process where you design a system
organisation that will satisfy the functional and non-functional requirements. Since
its a creative process, the activities depend on the type of system being developed,
the experience of the system architect and the requirement of the system. Therefore,
we may state that architectural design is a series of decisions to be made, not just a
normal sequence of activities.
Structural decisions need to be made during the architectural design process. These
decisions affect the system and development process. Sommerville (2010) states
that the software development team needs to consider the following fundamental
questions about the system:
1. Is there a generic application architecture that can act as a template for the
system that is being designed?
2. How will the system be distributed across a number of processors?
3. What architectural patterns might be used?

5. What will be the fundamental approach used to structure the system?

6. How will the structural components in the system be decomposed into
subcomponents?
7. What strategy will be used to control the operation of the components in
the system?
8. What architectural organisation is the best for delivering the non-functional
requirements of the system?
9. How will the architectural design be evaluated?
10. How should the architecture of the system be documented?
There is usually only a single processor for systems designed for personal computers
and you do not have to design the architecture of the system. This is different for
large systems. Most of it is a distributed system where it can be used across many
different computers. The choice of distribution architecture is a key decision that
affects the performance and reliability of the system.
As Garlan and Shaw (2003) state, architectural pattern is a description of a system
organisation such as a client-server organisation. It also captures the essence of an
architecture that has been used in difference software systems. You need to choose
the most suitable structure that will enable you to meet the system requirements. You
also need to decide on the strategy for decomposing components into subcomponents
for decomposed structural system units.
Finally, in the control modelling process, you have to make decisions about how
the execution of components should be controlled. Since the relationship between
non-functional requirements and software architecture is a close one, the particular
architectural style or pattern that you choose for a system must depend on the nonfunctional requirements:
1. Performance
The architecture should be designed to localise critical operations within
a small number of components. You may also consider run-time system
organisations that allow the system to be replicated and executed in different
processors.
2. Security
A layered structure for the architecture can be used if security is a critical
requirement. The most critical assets are protected in the innermost layers
and a high level of security validation is applied to these layers.
UNIT 2 19
3. Safety
The architecture must be designed so that safety-related operations are all
located in one component. This reduces the costs and problems of safety
validation and makes it possible to provide related protection systems that
can safely shut down the system in the event of failure.
4. Availability
The architecture must be designed to include redundant components so that
it is possible to replace and update components without stopping the system.
5. Maintainability
The system architecture must be designed using fine-grain components that
can readily be changed if maintainability is a critical requirement. A sharing
data structure must be avoided and producers of data should be separated
from the customers.
There will be potential conflict in some of these architectures. Using large

components improves performance and using small fine-grain components improves
maintainability. Some compromise must be found if both system requirements are
important. It can be achieved by using different architectural patterns or style for
different parts of the system.
Architectural patterns
Architectural patterns are commonly used in different types of systems. You can
imagine architectural patterns as a stylised, abstract description of good operation
which has been tried and tested in different systems. Therefore, architectural pattern
can be described as a system organisation that has been successful in previous system.
It should have a collection of data such as the patterns strengths and weaknesses.

Controller
State Change
Maps User Actions to

Model Updates
Selects Views
Model
View Selection
Encapsulates Application
States
Change
Notifies View of State
Notification
Changes
User Events
View
Renders Model
Requests Model Updates
Sends Users Events to
Controller
State Query
Figure 2.3 The organisation of the MVC
There is one well-known pattern which is the Model-View-Controller pattern.

As Weisfeld and Matt (2004) state, Model-View-Controller (MVC) pattern was
originally formulated in the late 1970s by Tryygve Reenskaug as part of the Smalltalk
system. This pattern is the basis of interaction management in many web-based
systems. The description inside the pattern includes the name, a brief description
and an example of a type of system where the pattern is used. Figure 2.3 shows the
organisation of the MVC.
Layered architecture
The layered architecture pattern is another way to accomplish independence in terms
of security. The system is organised into layers with related functionality connected
to each layer. Layered architecture is used when building new facilities on top of
existing systems. It can also be used when the development is spread across several
teams with each team responsible for a layer of functionality. Other than that, layered
architecture can be used when there is a requirement for multi-level security.
Figure 2.4 shows the layered architecture pattern. As you can see, it has been
organised in a form of separate layers. Each of the layers depends only on the services
offered by the layer immediately beneath it.
UNIT 2 21
User Interface
User Interface Management

Authentication and Authorisation
Core Business Logic/Application Functionality

System Utilities
System Support (OS, Database, etc.)
Figure 2.4 A generic layered architecture
Each of the layers becomes closer to the machine instruction set. As the layer is
developed, some of the services provided by that layer may be made available to
users. The architecture pattern is also changeable and portable. Lets say the interface
layer changes, and only the neighbouring layer is affected. This makes it easier to
provide multi-platform implementations of an application system as layered system
localises machine dependencies in inner layers.
The advantages of layered architecture are that it allows replacement of entire layers
so long as the interface is maintained. Any redundant facilities can be provided in
each layer to increase the dependability of the system. There are also disadvantages
when using layered architecture. Sometimes, a high-level layer may have to interact
directly with a lower level layer. Therefore, performance can be a problem because
of multiple levels of interpretation of a service request as it is processed at each layer.
These mean that it is impossible to have a clean separation between layers.
Database architecture
The systems that use a large amount of data are organised using shared database.
Database architecture is where all data in a system is managed in a central database
that can be accessed by all system components. You can use this pattern when you
have a system that generates a lot of information that needs to be stored for a long
time.
A database will be at the centre of this architecture and is accessed frequently by other
components that update, add, delete or even modify the data within the database.
Organising tools around a database is an effective way to share large amounts of
data. There is no need to exchange data explicitly from one component to another.
However, components must operate with an agreed database model.

Code
Generator
Java
Editor
UML
Editors
Design
Analyser
Report
Generator
Project Database
C++
Editor
Figure 2.5 Example of database architecture
Figure 2.5 is an illustration of a situation in which database is used. The advantage

of having database architecture is that the components can be independent where
they do not need to know the existence of other components. Changes made by one
component can be propagated to all components. Data can be managed consistently
since all the data is in place.
However, database architecture also has its weaknesses. If there is any failure in
the database, it will affect the whole system. Some difficulties may occur when
distributing the database across several computers.
Client-server architecture
In using client-server architecture, the functionality of the system is organised into
services with each service delivered from separate servers. The users of this service will
be the client who will access servers to make use of them. Client-server architecture
can be used when data in a shared database has to be accessed from different places.
This is because service can be duplicated and it can also be used when the load on
a system is changeable.
A system that uses the client-server pattern is organised as a set of services and
associated servers and clients that access and use the services. According to
Sommerville (2010), there are three major components in the client-server pattern:
1. A set of servers that offer services to other components.
2. A set of clients that call on the services offered by servers.
3. A network that allows the clients to access these services.
We know that layered architecture is independent. The same goes for client-server
architecture where services and servers can be changed without affecting other parts
of the system. Clients may have to know the names of the available servers and the
services that they provide. But, servers do not have to know the information about
the client or how many clients are accessing their services. Client access is through
UNIT 2 23
procedure calls using a request-reply protocol such as the http protocol used in the
World Wide Web. Basically, client makes a request to the server and just waits until
it receives a reply.
Student 1
Student 2
Student 3
Internet
Subject Server
Result Server
Picture Server
Subjects Register
Result Transcript
Photo Store
Figure 2.6 A client-server architecture for a student registration system
Figure 2.6 shows an example of a client-server architecture for a student registration
system. The client in the example given will be the student whereby the server
will include subject, result and photo servers. The advantage of using client-server
architecture is that servers can be distributed across a network. Therefore, general
functionality such as printing services can be available to all clients. There is also a
drawback for client-server architecture. Performance of the client-server architecture
may be affected if there is any server failure because it depends on the network as
well as the system.
Pipe-and-filter architecture
As Sommerville (2010) states, the name pipe and filter originated from the Unix
system where it was possible to link processes using pipes. It passes a text stream
from one process to another. By associating Unix commands, systems that conform
using this model can be implemented using pipes and the control facilities of the
Unix shell. The name filter is used because a transformation filters out the data
it can process from its input data stream.
Pipe-and-filter architecture represents the processing of the data in a system that is
organised with each component (filter) being separate and carries out only one type
of data transformation. The data flows (as in a pipe) from one component to another
for processing. Usually, it is used in data processing applications where inputs are
processed in separate phases to generate related outputs.

Issue
Receipts
Read Issued
Invoices
Identify
Payments
Find
Payments Due
Invoices
Receipts
Issue Payment
Reminder
Reminders
Payments
Figure 2.7 Example of the pipe and filter architecture
The example given in Figure 2.7 is used in batch processing application. A company
issues invoices to buyers. Payments that have been made are reconciled with the
invoice once a week. A receipt is issued when invoices have already been paid. For
those invoices that have not been paid within the time given, a reminder will be
issued.
The advantage of using pipe-and-filter architecture is that it is easy to understand
and support transformation reuse. These can be implemented as either a concurrent
or sequential system. The other advantage is that the workflow style matches the
structure of many business processes. The drawback of this architecture is that the
format for data transfer has to be agreed when communicating transformations. Each
transformation must parse its input and unparse its output to the agreed form. As a
result, the system overhead and may mean that it is impossible to reuse functional
transformations that use incompatible data structures.
Summary
A software design is a description of how a design of a software
system is organised. It begins by representing the totality of the
thing to be built and slowly refines the thing to provide guidance
for constructing each detail. There are two levels of abstraction that
the software development team may design, the architecture in the
small and the architecture in the large.
Architectural design is a creative process where you design a product
that can satisfy the requirements which include functional and nonfunctional requirements. For choosing a particular architectural style,
you must depend on its non-functional requirements that include
the performance, security, safety, availability and maintainability.
Architectural pattern can be described as a system organisation that
has been successful in previous systems. There are several levels of
architecture pattern which include database architecture, clientserver architecture and pipe-and-filter architecture.
UNIT 2 25
Self-test 2.2
1. Software architecture is important in software development
because:
A. it is designed according to standards.
B. it increases the potential risks.
C. it affects the robustness of the system development.
D. its design is structured and easy to accommodate change.
2. Architecture design is a representation that enables a software

engineer to:
A. analyse the effectiveness of the design in meeting its stated
requirements.
B. analyse the quality of the design in meeting its stated
requirements.
C. increase the risks associated with the construction of the
software.
D. All of the above.
3. Below are the advantages of layered patterns EXCEPT:

A. It is eligible for multi-level security.
B. The components of a system encapsulate data.
C. Allows replacement of the entire layer.
D. Redundant facilities increase the dependability of the system.
4. When do database architecture need to be used?

A. When it is a small system.
B. Basic layered pattern involved.
C. System generated a lot of information.
D. None of the above.
5. Below are the major components of the client-server pattern

EXCEPT:
A. A set of clients that offer services to access the components.
B. A set of servers that offer services to other components.
C. A set of clients that call on the services offered by servers.
D. A network that allows the clients to access these services.

6. Performance of the client-server architecture may be affected if

there is any server failure.
A. True
B. False
7. The advantages of using pipe and filter architecture is that it is

easy to understand and support transformation reuse.
A. True
B. False
8. Any component can operate with database model.

A True
B. False
UNIT 2 27
2.2 Software Quality

Objectives
1. Explain the three principle of software quality management.
2. Identify the types of software metrics.
3. Describe the key stages of component measurement.
4. Identify types of software standards in software quality.
Introduction
Software quality is one of the important parts when developing software. This is
because any dissatisfaction with the quality of software may lead to many complaints
from the customers or users. Therefore, it led the software development team to
have a formal technique to achieve of software quality. As such, this section has
been broken into four parts:
1. Definition of software quality.
2. Software quality measurement.
3. Quality assurance.
4. Quality standards.
Definition of software quality

Probably everyone has an idea about the meaning of quality. However, when it comes
to quality in the real world, for example, when there is software development project
disagreements between the persons involved, it often leads to further problems.
Especially in the case of customer complaints about faults in a software product, it
seems to be unclear not only what the requirements are, but also if the software has
the right characteristics with regard to these requirements.
Dissatisfaction with software quality led to the adoption of formal techniques of
software quality management. These quality management techniques have led to
significant improvements in the general level of software quality. As Sommerville
(2010) states, there are three principal concerns in software quality management
for software systems:

1. At the organisational level, quality management is concerned with

establishing a framework of organisational processes and standards that will
lead to high quality software. The software development team needs to take
responsibility for defining the software development processes to be used
and standards that should be applied to the software.
2. At the project level where quality management involves the application of
specific quality processes, check that these planned processes have been
followed and ensure that the project outputs are consistent with the standards
that are applicable to the software.
3. Quality management at the project level is also concerned with establishing
a quality plan for a project. It must include with quality goals and define
what processes and standards are to be used.
As an attribute of an item, quality refers to measurable characteristics; things we are

able to compare to known standards such as length, colour, electrical properties, and
malleability. However, software, largely an intellectual entity, is more challenging
to characterise than physical objects. Nevertheless, measures of a programs
characteristics do exist. These properties include complexity, cohesion, number of
function points, lines of code, and many others.
In software development, quality of design encompasses requirements, specifications,
and the design of the system. Quality of conformance is an issue focused primarily
on implementation. If the implementation follows the design and the resulting
system meets its requirements and performance goals, conformance quality is high.
Software quality measurement

Software measurement involves deriving a numeric value or profile for an attribute of
a software component, system or process. You may be able to simplify a conclusion
about the quality of the software by comparing these values to each other and to
the standards that apply across the organisation. A system could be assessed using
a range of metrics with software measurement. From the measurement obtained, a
value for the quality of the system could be inferred.
Software metric is a characteristic of a software system, system documentation or
development process that can be measured. Some examples of software metrics are:
1. The size of a program in lines of code.
2. The readability of a passage of written text.
3. The number of reported faults in a delivered software product.
4. The number of person-days required to develop a system component.
UNIT 2 29
There are two kinds of software metrics, control metrics and predictor metrics. Lets
go deeper into both metrics:
1. Control metrics
It supports the process management and is associated with software processes.
For example, the average effort and the time required to repair reported
defects.
2. Predictor metrics
It helps you predict the characteristics of the software. For example, the
cyclomatic complexity of the modules.
Both metrics influence management decision making. Project leaders use process
measurements to decide if process changes should be made and predictor metrics
to help estimate the effort required to make software changes. Sommerville (2010)
states that there are two ways of using measurements of a software system:
1. To assign a value to system quality attributes
Project leaders can access system quality attributes (example, maintainability)
by measuring the characteristics of system components and then aggregating
the measurements.
2. To identify the system components whose quality is substandard

It means that project leaders can detect any components with characteristics
that stray from the standards. For example, project leaders measure
components to find those with the highest complexity. This is because it
may contain bugs since complexity makes them harder to understand.
It is difficult to make direct measurements on software quality attributes. This is

because they are affected by subjective factors. For example, user experience and
education simply cannot be measured objectively. Therefore, project leaders need
to measure some internal attributes of the software. They also need to assume that
these are related to the quality characteristics that users are concerned with.

External Quality Attributes
Internal Attributes
Depth of Inheritance Tree

Maintainability
Cyclomatic Complexity
Reliability
Program Size in Line of Code
Reusability
Number of Error Messages
Usability
Length of User Manual
Figure 2.8 Relationship between external and internal software
Figure 2.8 depicts the relationship between external and internal software but does
not show how the attributes are related. As Kitchenham (1990) states, there are
three conditions that must hold if the measure of the internal attribute is to be a
useful predictor:
1. Measurement must be accurate for the internal attribute. It may need special
purpose tools to make the measurements.
2. External and internal attributes must have an interest connection so that it
can be measured. The value of the external attributes must be related in
some way, to the internal attributes.
3. Both attribute relationships must be understood, validated and expressed in
terms of a formula or model. The formula or model must include identifying
the functional form of the model by analysis of data collected, and identifying
the parameters that are to be included in the model.
Product metrics
For measuring internal attributes of a software system, product metrics are used.
Products metrics are predictor metrics such as the system size measured in lines
of code, or the number of ways to connect with each object class. Unfortunately,
software characteristics cannot be easily measured because they do not have consistent
relationship with quality attributes such as maintainability. The relationship change
depends on the development processes, technology used and type of system that is
being developed. According to Sommerville (2010), the product metrics fall into
two classes:
UNIT 2 31
1. Dynamic metrics
These metrics can be collected when doing system testing or after the system
has been used. This means that dynamic metrics are collected through
measurements of a program during execution. For example, the number of
bug reports to complete computation.
2. Static metrics
For static metrics, the measurement made is representative of the system. For
example, the code size when doing the program, any error in documentation
or improper design.
These two types of metrics are related to different quality attributes. Dynamic metrics
help to assess the effectiveness and reliability of a program.
Software Metric
Description
Fan-in/Fan-out
Fan-in is a measure of the number of functions or methods

that call another function or method (lets say A). Fan-out
is the number of functions that are called by function A.
High value for fan-in means that A is tightly coupled to
the rest of the design. High values for fan-out suggest
that the overall complexity of A may be high because of
the complexity of the control logic needed to coordinate
the called components.
Length of code
It measures the size of a program. The larger the size of

code of a component, the more complex it will be.
Cyclomatic complexity
It measures the control complexity of a program.

This control complexity may be related to program
understandability.
Length of identifiers
It measures the length of identifiers in a program such as

the names of variables, classes, methods and others. The
longer the identifiers, the more likely they are meaningful
and hence the more understandable the program.
Depth of conditional
nesting
It measures the depth of nesting of of-statements in

a program. Deeply nested if-statements are hard to
understand and potentially error-prone.
Fog index
It measures the average length of words and sentences

in documents. The higher the value of a documents Fog
index, the more difficult it is to understand the document.
Table 2.1 Static software product metrics
Static metrics assess the complexity and maintainability of the software or its
components. Table 2.1 shows the static software product metrics that are applicable
to any program. It is easy to measure the access time required to start up the system
and the execution time required for particular functions. This is because it relates
directly to the systems efficiency.

Software component analysis

Each component in the system can be analysed. Using a range of metrics the
component can be analysed separately. The result of analysis is then compared
for different components. It can also be compared with previous projects. The
analyst may detect if there are any problems with the quality of these components
if its different from its norm. As Sommerville (2010) states, the key stages of this
component measurement process are:
1. Choose measurement to be made.
You can create questions that are to be answered by the measurement.
You may also set the standard of measurement required to answer to these
questions. It is a good way to use when deciding what data is to be collected.
2. Select component to be assessed.

You do not have to assess all the components inside the system. You may
select a representative of components for measurement. You can focus on
the core components of the system that are in almost constant use.
3. Measure component characteristics.

The chosen components are measured and the associated metric values are
computed. It involves processing the component representation such as the
design and coding using an automated data collection tool.
4. Identify irregular measurements.

After you have measured all components that you select, you compare it
with each other or with previous measurements that have been recorded
in a measurement database. You may detect the problem by looking at the
unusually high or low values for each metric.
5. Analyse irregular components.

You should examine any irregular components to decide if this metric
value means that the quality of the component can be compromised. This
is because any irregular measurement does not mean that the component
has poor quality.
Any measurement must be kept even when data has not been used during a particular
project. You may make comparisons of software quality across projects and verify the
relations between internal attributes and quality characteristics once a sufficiently
large measurement database has been established.
UNIT 2 33
Quality assurance
In the software industry, different companies and industries interpret quality
assurance in different ways. Quality assurance simply means the definition of
procedures, processes and standards that are aimed at ensuring that software quality is
achieved. Sometimes, quality assurance also involves all configuration management,
verification and validation activities that occur after the product is delivered to the
customers.
Normally, there will be a team within the software development team that handles
quality assurance. The quality assurance (QA) team is responsible for managing the
release testing process where they need to manage the testing of the software before
it is released to customers. The QA team is also responsible for checking that the
system fully covers all requirements.
The QA team usually will not participate in any particular development group.
They should be independent and report to management above the project leader
level. This is because the project leader needs to maintain the project schedule and
budget. If any problem occurs, they may be accused of compromising on product
quality so that they meet their schedule. With independent QA teams, it can be
ensured that the organisation goals of quality are not compromised by short-term
budget and schedule considerations.
Althought QA teams should be independent groups, they still need to assist the
software development team to achieve high quality end product. Therefore, the
QA team prepares a quality plan for the development. The quality plan sets out
the desired software qualities and describes how these are to be assessed. However,
software development that applies agile method may have a less formal quality plan.
Humphrey (1993), in his classic book on software management, suggests an outline
structure for a quality plan. This includes:
1. Product introduction
This includes the description of the product and the quality expectations
for the product.
2. Product plan
Product plans will include the critical release dates and responsibilities for
the product. It also has plans for distribution and product servicing.
3. Process descriptions
This includes the development and service processes and standards that
should be used for product development and management.

4. Quality goals
This includes identification and justification of critical product quality
attributes.
5. Risk management
The quality plan also includes risk management whereby it defines the key
risks that might affect product quality and the actions to be taken to address
these risks.
Quality plan needs to be as short as possible. The reason is people will not read if it
is too long and this will defeat the purpose of producing the quality plan. For project
leaders, they should encourage the team to take responsibility for their quality of
their work and develop new approaches to quality improvement.
Quality standards
In the QA process, the important part is the selection of standards that should apply
in software development. Tools and methods may be chosen to support the use of
these standards. Once it has been selected, the project-specific processes have to be
defined to monitor the use of the standards. Sommerville (2010) states that software
standards are important because of these three reasons:
1. Standards capture wisdom that is of value to the organisation. They are based
on knowledge about the best or most appropriate practice for the customers
usage. It can be achieved after a great deal of trial and error. Building it into
a standard helps the company reuse this experience and avoid previous
mistakes.
2. Standards provide the framework for defining what quality actually means in
a particular setting. Since software quality is subjective, therefore, using
standards can establish a basis for deciding if a required level of quality has
been achieved.
3. Standards assist continuity when work carried out by one person is taken
up and continued by others. Standards also ensure that all the team members
adopt the same practices.
UNIT 2 35
To increase the product quality, the standards have to deliver its value. There are
two types of software engineering standards in software quality:
1. Product standards
Product standards have to be designed in such a way so that they can be
applied and checked in a cost-effective way. It is applied when the software is
being developed. There will be document standards that involve the structure
of requirement documents, documentation standards that involve standard
comment header for an object-class definition and coding standards where
it defines how a programming language should be used.
2. Process standards
This includes the definition of processes that check whether those product
standards have been followed. Process standards may have definitions of
specification, design and validation processes, process support tools and a
description of the documents that should be written during these processes.
QA teams that are developing standards should build the standards based on company
standards such as national and international standards. For international standards,
the QA team must draw up a standards handbook where it defines the standards
that are needed by their company. Table 2.2 shows the example of standards that
can be included in the handbook.
Product standards
Process standards
Design review form
Design review conduct
Requirements document structure
Submission of new code for system

building
Method header format
Version release process
Java programming style
Project plan approval process
Project plan format
Change control process
Change request form
Test recording process
Table 2.2 Product standards and process standards
Standards have to be adaptable since different types of software have different

development processes. The project leader has the authority to change or modify
process standards but it is important to ensure that the changes do not lead to loss
of product quality when changes are made.

The ISO 9001 standards

The ISO 9001 standard is a framework for developing software standards. There
will be documentation that includes general quality principles, describes quality
processes in general and lays out the organisational standards and procedures. It
will be documented in the company quality manual. This standard was originally
developed in 1987 but has undergone major revision in 2000 which includes the
nine core processes as shown in Figure 2.9.
Product Delivery Processes
Supporting Processes
Business
Acquisition
Business
Management
Design and
Development
Supplier
Management
Test
Inventory
Management
Production
and Delivery
Configuration
Management
Service and
Support
Figure 2.9 ISO 9001 core processes
If the company comply with ISO 9001, they need to document how the processes
relate to these core processes. It must also define and maintain records that
demonstrate that the defined company processes have been followed. The company
quality manual must describe the relevant processes and the process data that has
to be collected and maintained.
A company must define the types of processes that are to comply with ISO 9001. The
company must also have procedures in place that show that the quality processes are
being followed. The relationships between ISO 9001, organisational quality manual
and individual project quality plans are shown in Figure 2.10. This figure has been
derived from a model given by Ince (1994). It explains how the general ISO 9001
standards can be used as a basis for software quality management processes.
UNIT 2 37
ISO 9001
Quality
Models
instantiated as
Organisation
Quality
Manual
documents
Organisation
Quality
Process
is used to develop
Project 1
Quality Plan
Project 2
Quality Plan
Project 3
Quality Plan
supports
Project
Quality
Management
instantiated as
Figure 2.10 ISO 9001 and quality management
It is not necessarily true when some people think that ISO 9001 certification means
that the quality of the software that has been developed by certified companies is
better than by uncertified companies. The ISO 9001 standard focuses on ensuring
that the organisation has quality management procedures in place and that they
follow these procedures.
Summary
Software quality is needed when developing software. This is to
make sure that the software will satisfy the requirements and the
needs of the customers or users. There are formal techniques to
achieve satisfaction.
Software quality measurement involves deriving a numeric value
or profile for an attribute of a software component, system or
process. It will measure using software metrics. There are two kinds
of software metrics, control metrics and predictor metrics. Both
metrics influence management decision making.
Another technique to achieve software quality is to have quality
assurance. Quality assurance simply means the definition of
procedures, processes and standards that are aimed at ensuring
that software quality is achieved. The quality assurance (QA) team
is responsible for managing the release testing process where they

need to manage the testing of the software before it is released to

customers. A quality plan is needed to show the value of doing
quality assurance.
Software standards should be applied in software development.
Tools and methods may be chosen to support the use of these
standards. The ISO 9001 standard is a framework for developing
software standards.
Self-test 2.3
1. What is the function of software quality?
A. To satisfy customer requirements and needs.
B. To have integration between team members.
C. To design a good architecture.
D. To give extra work to software development team.
2. Quality of software will be measured using software metrics.

What is software metrics?
A. A characteristic of a software system that can be measured.
B. A measurement of software standards.
C. A characteristic of product to support quality assurance.
D. A measurement of software value.
3. These metrics can be collected when doing system testing or

after the system has been used.
A. Static metrics
B. Product metrics
C. Dynamic metrics
D. Control metrics
4. The measurement of the code size when doing the program is

______________.
A. static metrics
B. product metrics
C. dynamic metrics
D. control metrics
UNIT 2 39
5. Quality assurance will produce a ______________ at the end

of evaluation.
A. design plan
B. quality plan
C. assurance plan
D. risk plan
6. The ISO 9001 standard is a framework for developing software

standards.
A. True
B. False
7. The QA team is responsible for managing the quality design

process.
A. True
B. False
8. Software quality measurement influences management decision

making.
A. True
B. False

UNIT 2 41
2.4 Risk Management

Objectives
1. Identify categories of risk.
2. Describe the process of risk management.
3. Explain how to perform risk projection.
4. Identify the risk planning strategies.
Introduction
This section provides a simple approach to performing these risk assessments and
will discuss some of the most common risk areas, present a simple risk table to help
to quantify some of the risks associated with the software development process. By
identifying known and predictable risks, the project manager takes a first step toward
avoiding them when possible and controlling them when necessary. The student
will expose with different type of risk where each of it has their own behaviour. This
section is divided into three parts:
1. Software risk area.
2. Risk projection.
3. Risk monitoring.
Software risk area

Risk management refers to the process of developing strategies aimed at preventing
and controlling the risk of occurrence of errors and harmful events. The majority
of software teams rely solely on reactive risk strategies. Reactive risk strategies can
be defined as slow response to changes in a firms environment, undertaken only
when the management is forced to take rearguard action. At best, a reactive strategy
monitors the project for likely risks.
For project leaders, this is one of the important parts in software development.
It involves anticipating risk that may affect the project schedule or even software
quality. An action has to be developed to prevent these risks. Just imagine that risk
is something that you prefer it not to happen. Risks can threaten the entire software
development process. Sommerville (2010) states three related categories of risk:

1. Project risks
These risks affect the journey of your project or your resources. For example,
lets say you lost one of your best and experienced programmer. It may
take a time to find a replacement programmer with appropriate skills and
consequently, the software coding design may take longer to complete.
2. Product risks
These risks affect the performance and quality of the software being
developed. For example, the failure to develop a component that can perform
as expected. This may affect the entire performance of the system so that it
is slower than expected.
3. Business risks
These risks affect the software development team developing the software.
For example, a competitor introducing a new product is a business risk.
The introduction of a competitive product may mean that the assumptions
made about sales of existing software may be excessive by expecting the most
favourable outcome.
These risk types may overlap. Imagine an experienced designer leaving a project.
This can be a project risk since the schedule of the development may be disrupted.
Even if the person is immediately replaced, the new designer must take time to
understand the work that has been done and this causes the delivery of the system
to be delayed. However, it can also be a product risks because the replacement of the
new designer may not be as experienced and the person could make design errors.
Finally, it can be a business risk. The reason is because the designers experience may
be crucial in winning new contracts.
The risks may depend on the project and the software development team environment
in which software is being developed. There are also common risks that are not
related to the type of software being developed and this can occur in any project.
Table 2.3 shows some of the common risks.
UNIT 2 43
Risk
Affect
Description
Staff turnover
Project
Experienced staff will leave the

team before it is finished.
Mangement change
Project
There will be a change of software

development management team
with different priorities.
Hardware unavailability
Project
Hardware that is essential for the

project will not be delivered on
schedule.
Requirement change
Project and Product
There will be a larger number

of changes to the requirements
than anticipated.
Specification delays
Project and Product
Specifications of essential
interfaces are not available on
schedule.
Size underestimate
Project and Product
The size of the system has been

underestimated.
CASE tool
underperformance
Project
CASE tools, which suppor t

the project, do not perform as
anticipated.
Technology change
Business
The underlying technology

on which the system is built is
superseded by new technology.
Product competition
Business
A competitive product is
marketed before the system is
completed.
Table 2.3 Example of common projects, product and business risks
When developing risk management, you have to anticipate the risks, understand
the impact of the risks on the software and the business and take action to prevent
these risks. You may need to develop a contingency plan so that when the risks do
occur, you immediately take recovery action.
The process of risk management involves several stages:
1. Risk identification: identifying possible project, product and business risks.
2. Risk analysis: assessing the likelihood and consequences of the risks.
3. Risk planning: Make plans to address risk, either by avoid the risks or
minimising its effects on the project.
4. Risk monitoring: Regularly assess the risk and plan for risk mitigation and
revise these when you learn more about the risk.

Documentation needed as an outcome from the risk management process. This must
include a discussion about the risk, an analysis of the risk and information on how
you propose to mitigate the risk if it seems likely to be a problem.
The risk management process is an iterative process. You need to monitor the situation
to detect emerging risks. You have to re-analyse the risks as more information about
the risks is available. You also need to decide if the risk priority has changed.
Risk projection
The first stage of the risk management process is to identify the risk. Risk projection
or risk identification may be a team process where a team gets together to project
any possible risks. Normally, the project leaders will simply use their experience to
identify the most probable or critical risks. A checklist of different types of risk may
be used. According to Sommerville (2010), there are at least six types of risk that
may be included in a risk checklist:
1. Technology risks
These risks derive from the software or hardware technologies that are used
to develop the system.
2. People risks
These risks are associated with the people in the development team.
3. Organisational risks
These risks derive from the organizational environment where software is
being developed.
4. Tools risks
These risks derive from the software tools and any support software used
to develop the system.
5. Requirement risks
These risks derive from changes to the customer requirements and the process
of managing the requirement change.
UNIT 2 45
6. Estimation risks
These risks derive from the management estimates of the resources required
to build the system.
You may have a long list of risks when you have finished the risk identification process.
Table 2.4 shows examples of different types of risks according to Sommerville (2010).
Risk type
Possible risk
Technology
The database used in the system cannot process as many

transaction per second as expected (1)
Reusable software components contain defects means they
cannot be reused as planned. (2)
People
It is impossible to recruit staff with the skills required. (3)

Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)
Organisational
The organisation is restricted so that different management is

responsible for the project. (6)
Organisational financial problems force reductions in the project
budget. (7)
Tools
The code generated by software code generation tools is

inefficient. (8)
Software tools cannot work together in an integrated way. (9)
Requirements
Changes to requirements that require major design rework are

proposed. (10)
Estimation
The time required to develope the software is underestimated. (11)

The size of the software is underestimated. (12)
Table 2.4 Examples of different types of risks
You may need to reduce the list to a manageable size. It is impossible to keep track
of all of them if you have too many risks.
Risk analysis
You have to consider each identified risk to make a judgement about the danger of
the risk during the risk analysis process. You need to rely on your own judgement and
experience from previous projects and the problems that occurred. It is impossible to
make a precise assessment of the probability and seriousness of the risks. Therefore,
you should assign the risk to one of a number of bands:

The probability of the risk might be assessed as:

Probability
Percentage (%)
Very Low
< 10
Low
10 to 25
Moderate
25 to 50
High
50 to 75
Very High
>75
The effect of the risk might be assessed as:

Effects
Description
Catastrophic
Threatens the survival of the project
Serious
Would cause major delay
Tolerable
Delays are within allowed contingency
Insignificant
Relatively meaningless and of no effect
After you have assigned the number of band to the risk, you may organise the results
of this analysis process using a table according to seriousness (effects) of the risk.
Table 2.5 shows this for the risks that have been identified in Table 2.4.
Possible Risk
Probability
Effects
Organisational financial problems force reductions

in the project budget. (7)
Low
Catastrophic
It is impossible to recruit staff with the skills required.

(3)
High
Catastrophic
Key staff are unavailable at critical times. (4)
Moderate
Serious
Reusable software components contais defects

means they cannot be reused as planned. (2)
Moderate
Serious
Changes to requirements that require major design

rework are proposed. (10)
Moderate
Serious
The organisation is restricted so that different

management is responsible for the project. (6)
High
Serious
The database used in the system cannot process as

many transactions per second as expected. (1)
Moderate
Serious
The time required to develop the software is

underestimated. (11)
High
Serious
Software tools cannot work together in an integrated

way. (9)
High
Tolerable
Required training for staff is not available. (5)
Moderate
Tolerable
UNIT 2 47
The rate of defect repair is underestimated. (12)
Moderate
Tolerable
The code generated by software code generation

tools is inefficient. (8)
Moderate
Insignificant
Table 2.5 Risk types and examples
You need detailed information about the project, the process, the development team
and the organisation. Since it is an iteration process, you need to update this table
during iteration. Boehm (1998) suggests that the top 10 risks will be the risks that
need to be considered for full monitoring.
Risk planning
You need to think about the actions that you might take for each risk to minimise
the disruption to the project if the risks do occur. The risk planning considers each
of the key risks that has been identified and develops strategies to manage the risks.
According to Sommerville (2010), these strategies fall into three categories:
1. Avoidance strategies
Following avoidance strategies means that the probability of the risk
occurring will be reduced.
2. Minimisation strategies
Following minimisation strategies, the impact of the risks will be reduced.
3. Contingency plans
Following contingency plans means that you are prepared for the worst and
have a strategy in place to deal with it.
If these three strategies are not compatible with you risks, you should use a strategy
that reduces the chances that the risk will have serious effects. Finally, you should
have strategies in place to cope with the risk if it arises.

Activity 2.2
Consider the project development of a program that uses incremental
model to develop an application of e-statement for banking system.
The software development team listed the potential risks and did
analysis on the potential risks. Below are the potential risks:
Possible Risk
Probability
It is impossible to recruit staff with the skills required.

(1)
High
No communication among team members. (2)
Moderate
Failure to identify complex functionalities and time

required to develop those functionalities. (3)
Moderate
The product is complex to implement. (4)
High
Wrong budget estimation occurs during system

project estimation. (5)
Low
The code generated by software code generation

tools is inefficient. (6)
Moderate
Difficult project modules integration. (7)
High
Continuously changing requirement that requires

major rework of the project. (8)
Moderate
The time required to develop the software is

underestimated. (9)
High
Suggest how you may organise the results of this analysis process
using a table which lists the seriousness (effects) of the risk.
Risk monitoring
Risk monitoring is the process of checking that your assumptions about the product,
process and business risks have not changed. To decide whether the risk is becoming
more or less probable you must regularly assess each of the risks. You also need to
think about whether or not the effects of the risk have changed.
To implement this, you have to look at other factors. For example, the number of
requirements change requests will give you clues about the risk probability and the
effects. These factors depend on the types of risk. Table 2.6 gives some examples of
factors that may help you in assessing the risk types.
UNIT 2 49
Risk type
Potential indicators
Technology
Late delivery of hardware; many reported technology problems.
People
Poor staff morale; poor relationships amongst software

development team; high staff turnover.
Organisational
Organisational gossip; lack of action by senior management.
Tools
Reluctance by team members to use tools; complaints about CASE

tools; demands for higher-powered workstations.
Requirements
Many requirements change requests; customer complaints.
Estimation
Failure to meet contract schedule; failure to clear reported defects.
Table 2.6 Risk indicators
Regular monitoring needs to be done at all stages of the project. You may also
consider and discuss each of the key risks separately at every management review.
As a project leader, they need to decide if the risk is more likely to occur and if the
seriousness and the effect of the risk have changed.
Summary
In risk management, the software development team needs to assess
overall risk so that it can mitigate the chances of software failure.
Risks can threaten the entire software development process. There
are three categories of risk which include project risks, product risks
and business risks.
Performing risk projection is a team process where a team gets
together to project any possible risks. The possible risks that they
define will be put into a list. The list may need to be reduced to a
manageable size if there are a lot of potential risks. It is impossible
to keep track of all of them if you have too many risks. The team
needs detailed information about the project, the process, the
development team and the organisation.
The risk management team needs to think about the actions that
should be taken for each risk. The risk planning considers each of the
key risks that has been identified and develops strategies to manage
the risks. There are several strategies to manage the risk which
include avoidance strategies, minimisation strategies and developing
a contingency plan. After that, the team needs to regularly monitor
the process for all steps in software processes.

Self-test 2.4
1. The majority of software teams rely solely on reactive risk
strategies. Below are the risk categories EXCEPT:
A. project risks
B. product risks
C. design risks
D. business risks
2. These risks affect the performance and quality of the software

being developed. The statement refers to:
A. project risks
B. product risks
C. design risks
D. business risks
3. The process of risk management involves assessing the likelihood

and consequences of the risk. Which stage of risk management
does the statement refer to?
A. Risk identification
B. Risk analysis
C. Risk design
D. Risk monitoring
4. Which of the following statements is a category in people risk

types?
A. Reusable software components contain defects means they
cannot be reused as planned.
B. It is impossible to recruit people without experience in the
area concerned.
C. The size of the software is underestimated.
D. None of the above.
5. The effect of the risk might be assessed as below EXCEPT:

A. Catastrophic
B. Serious
C. Tolerable
D. Ordinary
UNIT 2 51
6. The risk management team needs to think about the actions

that should be taken for each risk.
A. True
B. False
7. Avoidance strategies mean that the probability of the risk

occurring will be reduced.
A. True
B. False
8. Software development team does not have to regularly monitor

the process for all steps in software processes.
A. True
B. False
Feedback
Activity 2.2
The answer may vary depending on your ideas and creativity:
Possible Risk
Probability
Effects
Wrong budget estimation occurs

during system project estimation. (5)
Low
Catastrophic
It is impossible to recruit staff with

the skills required. (1)
High
Catastrophic
No communication among team

members. (2)
Moderate
Serious
Continuously changing requirement

that requires major rework of the
project. (8)
Moderate
Serious
The product is complex to implement.

(4)
High
Serious
The time required to develop the

software is underestimated. (9)
High
Serious

Difficult project modules integration.

(7)
High
Tolerable
Fa i l u r e t o i d e n t i f y c o m p l e x
functionalities and time required
to develop those functionalities. (3)
Moderate
Insignificant
The code generated by software

code generation tools is inefficient.
(6)
Moderate
Insignificant
UNIT 2 53
Summary of Unit 2
Summary
This unit addressed further the understanding of software project
management. The unit explored the process modelling whereby it
refers to a process that can be expressed as a form of model concept.
It can also be seen as a framework that can be extended to create
more specific software processes. A classification of process model
is based on factors such as coverage, alignment and granularity.
Two common software process model have been introduced, the
waterfall model and incremental model. Waterfall model is suitable
for projects that need a long time to develop. Incremental model
is an agile method where the process is repeated following the
delivery of each increment until it produces a product that satisfies
the customer requirement.
Unit 2 also explored software design. Software design consists of
architectural design and the architectural patterns. Software design
is actually a description of how the design of software is organised.
Functional and non-functional requirements play an important role
in architectural design. When choosing a particular architectural
style, you must refer to its non-functional requirements that include
performance, security, safety, availability and maintainability.
There are several levels of architecture pattern which include
database architecture, client-server architecture and pipe-and-filter
architecture.
Software quality is also one of the important factors when developing
software. This is to make sure that the software will satisfy the
requirements and needs of the customers or users. To achieve
satisfaction, formal techniques are used such as software quality
measurement, having quality assurance and knowing the software
standards. Software quality measurement involves deriving a
numeric value or profile for an attribute of a software component,
system or process. For quality assurance, a quality plan is needed
to show the value of doing quality assurance. In software standards,
tools and methods are needed to support the use of these standards.
One standard stated in this unit is ISO 9001 standard whereby it
is a framework for developing software standards.

The last section of this unit discussed risk management. It is needed

in software development so that they can assess any risk that may
occur. There are three categories of risk, project risks, product risks
and business risks. The software development team will list out all
the potential risks and organise it from the highest value risk to the
lowest. A potential solution will be developed to mitigate the risk.
After that, the team needs to regularly monitor the process for all
steps in software processes.
UNIT 2 55
Suggested Answers to Self-tests

Feedback
Self-test 2.1
1. C
2. A
3. B
4. C
5. A
6. A
7. A
8. B
Self-test 2.2
1. C
2. A
3. B
4. C
5. A
6. A
7. A
8. B

Self-test 2.3
1. A
2. A
3. C
4. A
5. B
6. A
7. B
8. A
Self-test 2.4
1. C
2. B
3. B
4. B
5. D
6. A
7. A
8. B
UNIT 2 57
References
Bass et al. (2003) Software Architecture in Practice, 2nd edn, Addison-Wesley
Professional.
Boehm (1998) Using the WINWIN spiral model: A case study, Computer, vol. 31.
Bosch, J (2000) Design and Use of Software Architectures: Adopting and Evolving a
Product Line Approach, Pearson Education Addison-Wesley & ACM.
Dowson, M (1998) Iteration in the software process, Proceedings of the 9th
International Conference on Software Engineering.
Garlan, D and Shaw, M (2003) Software Architecture, Prentice-Hall.
Humphrey, W S (1993) Software process development and enactment: Concepts
and definitions, Proceedings of the 2nd International Conference on Software Process.
Ince, D (1994) ISO 9001 and Software Quality, McGraw Hill.
Kitchenham, B A (1990) Software development cost models, in Rook, P (2000)
Software Reliability Handbook, Elsevier Applied Science.
Pressman, R S (2001) Software Engineering: A Practitioners Approach, 5th edn, USA:
McGraw-Hill.
Rolland, R and Pernici (1998) A comprehensive view of process engineering.
Proceedings of the 10th International Conference CAiSE98, B. Lecture Notes in
Computer Science 1413. Springer.
Sommerville, I (2010) Software Engineering, 9th edn, Addison Wesley
Waterfal-Model.com, Waterfall model: Advantages, examples, phases and more,
http://www.waterfall-model.com/ (Accessed 9 November 2012).
Weisfeld, M A (2004) The Object-Oriented Thought Process, Sams Publishing.
Wikipedia Process Modeling, http://en.wikipedia.org/wiki/Process_modeling
(Accessed 9 November 2012).
Winston, R (1970) Managing the development of large software systems, Proceedings
of IEEE WESCON, 26 (August): 1 9.

UNIT 2 59
Glossary
Block diagrams
The principal parts are represented by blocks

connected by lines that show the relationships
among the blocks.
Contingency plan
A plan devised for an outcome other than in

the usual (expected) plan.
Cyclomatic complexity
It is a software metric (measurement) and is

used to indicate the complexity of a program.
http
Hypertext Transfer Protocol (HTTP) is

an application protocol for distributed,
collaborative, hypermedia information systems.
Multi level security
The application of a computer system to

process information with different sensitivities
and prevent users from obtaining access to
information for which they lack authorisation.
Risks mitigation
Efforts taken to reduce either the probability

or consequences of a threat.
Robustness
The ability of a system to cope with errors

during execution.
Smalltalk system
An object-oriented, dynamically-typed,
reflective programming language.
Unix
A multitasking, multi-user computer operating

system.
WWW
Acronym for World Wide Web. A system of

interlinked hypertext documents accessed via
the Internet.

Software Development Models U2 PDF

Uploaded by

Software Development Models U2 PDF

Uploaded by

UNIT 2 A

Software process management

B WAWASAN OPEN UNIVERSITY

EXTERNAL COURSE ASSESSOR

2012 Wawasan Open University

Wawasan Open University

54, Jalan Sultan Ahmad Shah, 10050 Penang.

2.1 Process modelling

Goal of process model

Classification of process model

The waterfall model

The incremental development

Suggested answers to activity

2.2 Design architecture

Understanding of architectural design

Architectural design decisions

D WAWASAN OPEN UNIVERSITY

2.3 Software quality

Definition of software quality

Software quality measurement

2.4 Risk management

Software risk area

Suggested answers to activity

Suggested answers to self-tests

2 WAWASAN OPEN UNIVERSITY

2.1 Process Modelling

Goal of process model

4 WAWASAN OPEN UNIVERSITY

2. The incremental model

Classification of process model

6 WAWASAN OPEN UNIVERSITY

c. Decision-oriented: It is a set of related decisions conducted for the specific

The waterfall model

Figure 2.1 Waterfall model

2. System and software design

8 WAWASAN OPEN UNIVERSITY

3. Implementation and unit testing

4. Integration and system testing

5. Operation and maintenance

Nowadays, waterfall model is often inappropriate for developing super-vast software.

In your opinion, which of the above development is likely to better

The incremental development

10 WAWASAN OPEN UNIVERSITY

Figure 2.2 Incremental development

Nowadays, the most common approach to the development of application system

12 WAWASAN OPEN UNIVERSITY

The incremental model uses an agile approach. This process is

2. Which of the following is a term related to process model?

3. We can classify process model by its alignment. Which of the

4. Which of the following has lower level processes?

5. The incremental model of software development is

6. The waterfall model is the oldest paradigm in software

7. The advantage of incremental model is that it generates working

8. The disadvantage of incremental model is each phase of iteration

14 WAWASAN OPEN UNIVERSITY

Suggested answers to activity

2.2 Design Architecture

Understanding of architectural design

16 WAWASAN OPEN UNIVERSITY

to discuss the requirements needed with the customers. According to Sommerville

2. Architecture in the large

As Bosch (2000) states, software architecture is important because it affects the

2. As a method of documenting an architecture that has been designed

Architectural design decisions

18 WAWASAN OPEN UNIVERSITY

5. What will be the fundamental approach used to structure the system?

There will be potential conflict in some of these architectures. Using large

20 WAWASAN OPEN UNIVERSITY

Maps User Actions to

Figure 2.3 The organisation of the MVC

There is one well-known pattern which is the Model-View-Controller pattern.

User Interface Management

Core Business Logic/Application Functionality

System Support (OS, Database, etc.)

Figure 2.4 A generic layered architecture

22 WAWASAN OPEN UNIVERSITY