Download Software Processes in Software Engineering and more Lecture notes Software Engineering in PDF only on Docsity!
10 TOPIC 2 SOFTWARE PROCESSES
Topic
Software
Processes
L E A R N I N G O U T C O M E S
By the end of this topic, you should be able to:
- Describe the concept of a software process model;
- Explain the waterfall model, evolutionary development, formal systems development, and reuse-based development model;
- Describe process iteration and its approaches;
- Explain software specification and its four main phases; and
- Define software design and implementation, software validation, and software evolution.
INTRODUCTION
Software development consists of several processes. These processes will be
carried on by the project team from beginning until it is finish. The software
processes are the continuous set of activities for specifying, designing,
implementing, and testing software systems. This will lead to the creation of the
software product. These processes could involve the development from scratch
or by reusing existing codes. The processes involved in software development
are software process models, process iteration, software specification, software
design and implementation, software validation and software evolution.
TOPIC 2 SOFTWARE PROCESSES! 11
The software process model consists of four steps as illustrated in Figure 2.1.
Figure 2.1: Four steps of software process model
A software process model is a structured set of activities required to
develop a software system.
A software process model can also be described as an abstract representation of a
process. It presents a description of a process from some particular perspectives.
There are four process models and the models are shown in Table 2.1.
Process Models Descriptions
The Waterfall Model
This model is separated phases of specification and development. For example, there are almost 5 to 6 steps or phases such as requirements specifications, analyse problem and software design, implementation or coding, testing and maintenance.
Evolutionary Development
In this model, specification and development are interleaved. For example, an initial system rapidly developed from abstract specifications. This is then refined with customer input to produce a system which satisfies the customer’s needs.
Formal Systems Development
A mathematical system model is formally transformed to an implementation. Then, verification of system components is carried out by making mathematical arguments that they conform to their specification.
Reuse-based Development
The system is assembled from existing components or reusable components. The reusable components will be integrated into a system without doing or starting the software process development from scratch.
Table 1.2: Components in Software Engineering Methods
SELF-CHECK 2.
You have learnt FOUR steps software process models. Can you define them?
2.1^ SOFTWARE PROCESS MODELS
TOPIC 2 SOFTWARE PROCESSES! 13
(c) Implementation and Unit Testing
During the implementation stage, the software design is created as a set of
programs or program units. Then when the each unit was completed, the
unit testing involves verifying that each unit meets its specification.
(d) Integration and System Testing
After unit testing has been completed, the individual program units or
programs are integrated and tested as a complete system to make sure that
the software requirements have been met. After integration testing has been
completed, the software system is delivered to the customer.
(e) Operation and Maintenance
Normally, operation and maintenance phase is the longest life-cycle phase.
During this cycle, the system is installed and used by the user. Maintenance
involves correcting errors which were not discovered in earlier stages of the
life cycle, improving the implementation of system units and enhancing the
system’s services when new requirements are discovered.
In principle, the result of each phase will come out with one or more standard
documents which are approved. For the standardisation, it depends on the
company itself whether they want to make the documents into specific standard
or just creating their own standard. Most of the time, the following phase should
not start until the previous phase has finished because these stages overlap and
feed information to each other.
The software will put into use during the operation and maintenance phase.
In this phase, errors and omissions in the original software requirements are
discovered and new functionality is identified. In order to make these changes,
it may involve repeating some or all previous process stages. The problem with
waterfall model can be classified into three important points.
Three Problems with Waterfall Model:
(i) Inflexible partitioning of the project into distinct stages;
(ii) Waterfall model is difficult to respond to changing customer
requirements; and
(iii) Waterfall model is only appropriate when the requirements are well-
understood.
2.1.2 Evolutionary Development
The objective evolutionary development is to develop initial system to get user’s
comments and later it will be enhanced and refined to evolve into functional
system. This is shown in Figure 2.3.
14 TOPIC 2 SOFTWARE PROCESSES
There are two types of evolutionary development as shown in Figure 2.4.
Figure 2.3: Evolutionary development Source: Adapted from Sommerville (2001, pg.47)
Figure 2.4: Two types of evolutionary development
16 TOPIC 2 SOFTWARE PROCESSES
Figure 2.6: Formal transformation Source: Adapted from Sommerville (2001, pg.48)
The main differences between this approach and the waterfall model are:
(a) The software requirements specification is later refined into a detailed formal
specification which is expressed in a mathematical notation; and
(b) The development process design, implementation and unit testing are
replaced by a transformational development process. Then through a series
of transformations, they will become a program. This refinement process is
illustrated in Figure 2.6.
From the previous transformation process, the formal mathematical repre-
sentation of the system is systematically converted into a more detailed system.
Each step adds detail into the development process until the formal specification
is converted into an equivalent program.
The advantages of the transformational approach are:
(a) A program meets its specification, where the distance between each
transformation is less than the distance between a specification and a
program;
(b) A transformational approach made up of a sequence of smaller steps is
better. This approach is particularly suited to the development of systems
that have stringent safety, reliability or security requirements.
There were few defects in the delivered system and the development costs were
not significantly different from the costs of other approaches.
However, this approach also has disadvantages because processes cased on
formal transformations are not widely used. They require specialised expertise
and the system interaction is not amenable to formal specification and this takes
up a very large part of the development effort for most software systems.
TOPIC 2 SOFTWARE PROCESSES! 17
SELF-CHECK 2.
The waterfall model and formal systems development is one of the models
in software process models. Can you find the differences between them?
2.1.4 Reuse-oriented Development
In the software development industry nowadays, there are many cases where
software is reused for another projects. Normally, this method will be used when
the project members can identify the codes that can be reused. They reuse these
components, modify them and incorporate them into system. The process model
for reuse-oriented development is shown in Figure 2.7.
Requirement Specification
Component Analysis
Requirements Modification
System Design with Reuse
Development and Integration
System Validation
Figure 2.7: Reuse-oriented developments Source: Adapted from Sommerville (2001, pg. 50)
There are four main stages in this model as summarised in Table 2.3.
Stages Descriptions
Component Analysis
From the given the requirements specification, a search is made for components to implement that specification and even though it does not match but its functionality might has certain similarity.
Requirements Modification
During this stage, the requirements are analysed and then modified to reflect the available components.
System Design with Reuse
During this phase, the framework of the system is designed or an existing framework is reused and sometimes some new software may have to be designed if reusable components are not available.
Development and Integration
Lastly, the software which cannot be brought in is developed and the components and Commercial-Off-The-Shelf (COTS) systems are integrated to create the system.
Table 2.3: Four Stages of Reuse-oriented Development
TOPIC 2 SOFTWARE PROCESSES! 19
Figure 2.8: Incremental development Source: Adapted from Sommerville (2001, pg.52)
Define Outline Requirements
Assign Requirements to Increments
Design System Architecture
Integrate Increment
Development System Increment
Validate Increment
Validate System
Final System System Incomplete
In this model, development is broken into increments and each increment will
deliver part of the required functionality. Then, user requirements are prioritised
and the highest priority requirements are included in early increments. Then, the
next requirements are started and continue to evolve.
Incremental development process has a number of advantages and disadvantages
as shown in Table 2.4.
Incremental Development Process
Advantages Disadvantages
(a) Customer value can be delivered with each increment so system functionality is available earlier.
(a) Increments should be relatively small. Example: not more than 20000 lines of codes and each increment should deliver some system functionality. (b) Early increments act as a prototype to help to validate requirements for later increments.
(b) It may be difficult to map the customer’s requirements onto the right size of increments.
(c) Lower risk of overall project failure. (^) (c) Most systems require a set of basic facilities which are used by different parts of the system.
(d) The highest priority system services tend to receive the most testing.
Table 2.4: Four Stages of Reuse-oriented Development
20 TOPIC 2 SOFTWARE PROCESSES
Table 2.5: Four Stages of Reuse-oriented Development
2.2.2 Spiral Development
The spiral model of the software process (Figure 2.9) was originally proposed by
Boehm and now, it is well known. Process is represented as a spiral rather than as
a sequence of activities with backtracking and each loop in the spiral represents
a phase in the process. There are no fixed phases such as specification or design -
loops in the spiral are chosen depending on what is required. Moreover, risks are
explicitly assessed and resolved throughout the process. Each loop in the spiral is
divided into four sectors as described in Table 2.5.
Sectors Descriptions Objective Setting Specific objectives for the phase are identified.
Risk Assessment and Reduction
Risks are assessed and activities put in place to reduce the key risks.
Development and Validation
A development model for the system is chosen which can be any of the generic models.
Planning The project is reviewed and the next phase of the spiral is planned.
Determine Objectives Alternatives and Constraints
Evaluate Alternatives Identify, Resolve Risks Risk Analysis Risk Analysis Risk Analysis Operational Prototype
Prototype 3 Prototype 2 Proto- type 1
Risk REVIEW Analysis
Requirements Plan Life-cycle Plan
Concept of Operation
Simulations, Models, Benchmarks
Development Plan Integration and Test Plan Plan Next Phase
S/W requirements Requirement Validation Design V&V
Product Design Detailed Design Code Unit Test Integration Test Acceptance Service Test Develop, Verify Next-Level Product
Figure 2.7: Boehm’s spiral model of the software process Source: Adapted from Sommerville (2001, pg.54)
22 TOPIC 2 SOFTWARE PROCESSES
Figure 2.10 : The requirements engineering process Source: Adapted from Sommerville (2001, pg.55)
Requirements Elicitation and Analysis
Requirements Validation
Feasibility Study Requirements Specification
Feasibility Report System Models User and System Requirements Requirements Document
There are four main phases in the requirements engineering process as explained
in Table 2.6.
Phases Descriptions
Feasibility Study
To identify user’s needs such as software and hardware technologies that should be used on the new system. The study will decide if the proposed system will be cost-effective and if it can be developed given existing budgetary constraints.
Requirements Analysis
To derive the system requirements through observation of existing systems, discussion with potential users and procurers, talk analysis, and many more. This may involve the development of one or more different system models and prototypes.
Requirements Specification
To translate the information gathered during the analysis activity into a document that defines a set of requirements. There are two types of requirements, namely user requirements and system requirements.
Requirements Validation
To check the requirements for realism, consistency and completeness and errors in the requirements document are inevitably discovered. It must then be modified to correct these problems.
Table 2.6: Four Main Phases in the Requirements Engineering Process
ACTIVITY 2.
Suggest why it is important to make a distinction between developing
the user requirements and developing the system requirements in the
requirements engineering process.
TOPIC 2 SOFTWARE PROCESSES! 23
Figure 2.11 : Two parts of the software design and implementation
Figure 2.12 : : A general model of the design process Source: Adapted from Sommerville (2001, pg.57)
2.4 SOFTWARE DESIGN AND IMPLEMENTATION
The software design and implementation is divided into two parts as illustrated
in Figure 2.11.
SELF-CHECK 2.
Software design and implementation carry different objectives. What do you
think the differences between these two processes?
The software design and implementation is the process of converting the
system specification into an executable system.
SOFTWARE DESIGN AND IMPLEMENTATION
Software Design
Design a software structure that realises the specification.
Implementation
Translate this structure into an executable program.
Abstract Specification
Interface Design
Component Design
Data Structure Design
Algorithm Design
Architectural Design
System Architecture
Software Specification
Interface Specification
Component Specification
Data Structure Specification
Algorithm Specification
Requirements Specification Design Activities
Design Products
TOPIC 2 SOFTWARE PROCESSES! 25
(b) An entity-relation model that is used to describe the basic entities and the
relations between them in the design stage. Normally entity-relation models
are used to describe database structures;
(c) A structural model which indicates the system components and their
documented interactions; and
(d) Object-oriented methods which include an inheritance model of the system,
models of the static and dynamic linkages between objects and a model of
interactions between objects when the system is executing.
ACTIVITY 2.
(a) Describe the main activities in the software design process and the outputs of these activities. By using an entity-relation diagram, show possible relationships between the outputs of these activities.
(b) What are the FIVE components of a design method? Take any method which you know and describe its component. Assess the completeness of the method which you have chosen.
(c) Design a process model for running system tests and recording their results.
2.4.2 Programming and Debugging
SELF-CHECK 2.
Have you ever heard about programming and debugging? How do
programming and debugging relate?
Programming is a process of translating a design into a program and
removing errors from that program.
Programming is a personal activity and there is no generic programming process.
Programmers carry out some program testing to discover faults in the program
and remove these faults in the debugging process.
Normally, programmers will test the program code that they have developed.
The testing process often reveals program defects that must be removed from the
program. This is called debugging.
26 TOPIC 2 SOFTWARE PROCESSES
Defect testing and debugging are considered different processes. Testing
establishes the existence of defects while debugging is concerned with locating
and correcting these defects. Figure 2.13 illustrates a possible debugging process.
Therefore, the debugging process is part of both software development and
software testing.
Debugging is the process of identification and removal of localised
implementation errors or bugs from a program or system.
Figure 2.13: The debugging process Source: Adapted from Sommerville (2001, pg.60)
Locate Error
Design Error Repair
Repair Error
Re-test Program
ACTIVITY 2.
Which methods do you think is the easier to work on? Is it programming or debugging? Why?
Software verification and validation is intended to show that a system
conforms to its specification and meets the requirements of the system
customer. It involves checking and review processes and system testing.
System testing involves executing the system with test cases that are derived from
the specification of the real data to be processed by the system. Figure 2.14 shows
a five -stage testing process where system components are tested individually,
then they are integrated and tested and, finally, the system is tested with the
customer’s data.
2.5 SOFTWARE VALIDATION
SELF-CHECK 2.
Software validation is the third step of software process model. Can you
think what the purpose of this step is?
28 TOPIC 2 SOFTWARE PROCESSES
Figure 2.15: Testing phases in the software process Source: Adapted from Sommerville (2001, pg.62)
Figure 2.16: The differences between alpha testing and beta testing
System Specification
System Design
Detailed Design
Module and Unit Code and Test
Requirements Specification
Acceptance Test Plan
System Integration Test Plan
Sub-system Integration Test Plan
Sub-system Integration Test
System Integration Test
Acceptance Service Test
There are two types of testing, that is alpha testing and beta testing. Figure 2.
shows the differences between alpha testing and beta testing.
VS
Alpha Testing !!!!!Also called as Acceptance testing !!!The alpha testing process continues until the system developer and the client agree that the delivered system is an acceptable implementation of the system requirements.
Beta Testing !!!!!Often used when the system is to be !!!! marketed as a software product !!!!It involves delivering a system to a! number of potential customers who agree to use that system.
2.6 (^) SOFTWARE EVOLUTION
Software is inherently flexible and can change. As requirements change through
changing business circumstances, the software that supports the business must
also evolve and change. Although there has been a differentiation between
development and evolution, this is increasingly irrelevant as fewer and fewer
systems are completely new.
There has always been a differentiation between the process of software
development and the process of software evolution. Software development is
considered to be a creative activity where a software system is developed from an
initial concept through to a working system.
TOPIC 2 SOFTWARE PROCESSES 29
As defined by Sommerville (2001),
Software maintenance is the process of changing that system once it has
gone into use.
Although the maintenance costs are higher than the initial development costs,
maintenance activities are considered to be less critical than actual software
development.
This differentiation is becoming increasingly irrelevant. Few software systems are
now completely new systems and it makes much more sense to see development
and maintenance as a continual effort. Instead of two separate processes, it
is more realistic to consider software engineering as an evolutionary process
where software is continually changed over its lifetime in response to changing
requirements and customer needs. This evolutionary process is illustrated in
Figure 2.17.
Assess Existing Define systemRequirements Systems Propose SystemChanges SystemsModify
Existing Systems
New System
Figure 2.17: System evolution Source: Adapted from Sommerville (2001, pg.63)
ACTIVITY 2.
Does version of certain software can be considered as software
evolution? Explain it.
SUMMARY
r Software processes are the activities involved in producing a software
system. Software process models are abstract representations of these
processes. All software processes include software specification, software
design and implementation, software validation and software evolution.
