Chap 4
Software Processes
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 1
Objectives





To introduce software process models
To describe three generic process models
and when they may be used
To describe outline process models for
requirements engineering, software
development, testing and evolution
To explain the Rational Unified Process
model
To introduce CASE technology to support
software process activities
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 2
Topics covered





4.1 Software process models
4.2 Process iteration
4.3 Process activities
4.4 The Rational Unified Process
4.5 Computer-aided software engineering
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 3
What is the software process?

A software process is a set of activities that
leads to the production of a software
product. These activities may involve the
development of software from scratch in a
standard programming language.
Increasingly, however, new software is
developed by extending and modifying
existing systems and by configuring and
integrating off-the-shelf software or system
components.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 4
The fundamental activities of
software processes.

Although there are many software processes, some
fundamental activities are common to all software
processes:
•
•
•
•
Software specification : the functionality of the software
and constraints on its operation must be defined.
Software design and implementation : the software to
meet the specification must be produced.
Software validation : the software must be validated to
ensure that it does what the customer wants.
Software evolution : the software must evolve to meet
changing customer needs. 64
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 5
4.1 The software process

A software process model is an abstract
representation of a process. It presents a
description of a process from some
particular perspective, and thus provides
only partial information about that process.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 6
Generic software process models

The waterfall model
•

Evolutionary development
•

Separate and distinct phases of specification
development, validation and evolution and represents
them as separate process phases such as requirements
specification, software design, implementation, testing
and so on.
This approach interleaves (interchange) the activities of
specification, development and validation. An initial
system is rapidly developed from abstract specifications.
This is then refined with customer input to produce a
system that satisfies the customer’s needs.
Component-based software engineering
•
The system is assembled from existing components, the
focuses on integrating these components into a system
rather than developing them from scratch.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 7


These generic process models are widely
used in current software engineering
practice. They are not mutually (interchange)
exclusive and are often used together,
especially for large systems development.
Sub-system within a larger system may be
developed using different approaches, but
we should understand that, in practice, they
are often combined.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 8
4.1.1 Waterfall model
Figure 4.1
the software life cycle
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 9
4.1.1 Waterfall model phases
1.
Requirements analysis and definition
•
2.
System and software design
•
3.
The system’s services, constraints and goals are
established by consultation with system users. They are
then defined a detail system specification.
Systems design process partitions the requirements to
either hardware or software systems. It establishes an
overall system architecture. Software design involves
identifying and describing the fundamental software
system abstractions and their relationships.
Implementation and unit testing
•
Software design is realized (accomplish) as a set of
programs or program units. Unit testing involves verifying
that each unit meets its specification.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 10
Waterfall model phases
4.
Integration and system testing
•
5.
Individual program units or programs are integrated and
tested as a complete system to ensure that the software
requirements have been met. After testing, the software
system is delivered to the Customer.
Operation and maintenance
•
This is longest life-cycle phase. The system is installed
and put into practical use. 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 as
new requirements are discovered. 67
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 11
Waterfall model problems




Inflexible partitioning of the project into distinct
stages makes it difficult to respond to changing
customer requirements.
Therefore, this model is only appropriate when the
requirements are well-understood and changes
will be fairly limited during the design process.
Few business systems have stable requirements.
The waterfall model is mostly used for large
systems engineering projects where a system is
developed at several sites.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 12
4.1.2 Evolutionary development
There are two fundamental types of evolutionary
development:

Exploratory development
Objective is to work with customers and to evolve a final system
from an initial outline specification. Should start with wellunderstood requirements and add new features as proposed by
the customer.

Throw-away prototyping
•
Objective is to understand the system requirements. Should
start with poorly understood requirements to clarify what is
really needed.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 13
4.1.2 Evolutionary development
Figure 4.2
Evolutionary development
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 14
4.1.2


An evolutionary approach to software development is
often more effective than the waterfall approach in
producing system that meet the immediate needs of
customers.
From an engineering and management perspective,
the evolutionary approach has two problems:
•
•
Process is not visible: Managers need regular deliverables
(report) to measure progress. If systems are developed
quickly, it is not cost-effective to produce documents that
reflect every version of the system.
Systems are often poorly structured: Continual change tend
to corrupt the software structure. incorporating (combine)
software changes becomes increasingly difficult and costly.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 15
4.1.2 Evolutionary development

Problems
•
•
•

Lack of process visibility;
Systems are often poorly structured;
Special skills may be required.
Applicability (suitable)
•
•
•
For small or medium-size interactive systems;
For parts of large systems (e.g. the user
interface);
For short-lifetime systems.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 16


For small and medium-sized systems (up to
500,000 lines of code). I think that the
evolutionary approach is the best approach
to development.
For large, complex, long-life-time systems,
where different teams develop different part
of the system, it is difficult to establish a
stable system architecture using this
approach. Which makes it hard to integrate
contributions from the teams.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 17




For large systems, I recommend a mixed process that
incorporates the best features of the waterfall and the
evolutionary development models.
This may involve developing a throwaway prototype to
resolve uncertainties in the system specification, then reimplement the system using a more structured approach.
Part of the system that are well understood can be
specified and developed using a waterfall-based
process.
Other part of system, such as the user interface, which
are difficult to specify in advance, should always be
developed using an exploratory programming approach.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 18
4.1.3 Component-based software
engineering (CBSE)


Based on systematic reuse where systems
are integrated from existing components or
COTS (Commercial-off-the-shelf) systems.
This approach is becoming increasingly
used as component standards have
emerged.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 19
4.1.3

Process stages
1.
Component analysis;
•
2.
Given the requirements specification, a search is made for
components to implement that specification. Usually, there
is no exact match, and the components that may be used
only provide some of the functionality required.
Requirements modification;
•
©Ian Sommerville 2006
During this stage, the requirements are analysed using
information about the components that have been
discovered. They are then modified to reflect (consider) the
available components. Where modifications are
impossible, the component analysis activity may be reentered to search for alternative solutions.
Software Engineering, 8th edition. Chapter 4
Slide 20
3. System design with reuse;
•
During this phase, the framework of the system is
designed or an existing framework is reused. The
designers take into account the components that are
reused and organize the framework to cater (supply) to
this. Some new software may have to be designed if
reusable components are not available.
4. Development and integration.
•
©Ian Sommerville 2006
Software that cannot be externally procured is
developed, and the components and COTS systems
are integrated to create the new system. System
integration, in this model, may be part of the
development process rather than a separate activity.
Software Engineering, 8th edition. Chapter 4
Slide 21
Reuse-oriented development
Figure 4.3
component-based software engineering
CBSE : Component-based software engineering
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 22
Advantage and short-point of Componentbased software engineering




Has obvious advantage of reducing the amount of
software to be developed and so reducing cost and
risks.
Leads to faster delivery of the software.
However, requirements compromises are inevitable
and this may lead to a system that does not meet
the real needs of users.
Furthermore, some control over the system
evolution is lost as new versions of the reusable
components are not under the control of the
organization using them.70
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 23
4.2 Process iteration





Change is inevitable in all large software projects.
The system requirements change as the business
procuring the system responds to external
pressures.
Management priorities change.
As new technologies become available designs and
implementation change.
This means that the software process is not a oneoff process; rather, the process activities are
regularly repeated as the system is reworked in
response to change requests.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 24
4.2

Two (related) approaches
•
Incremental delivery:
• The software specification, design and implementation
are broken down into a series of increments that are
each developed in turn.
•
Spiral development:
• The development of the system spirals outwards from
an initial outline through to the final developed system.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 25
4.2




The essence of iterative processes is that the
specification is developed in the same time with the
software developed.
However, this conflicts with the procurement model
of many organizations where the complete system
specification is part of the system development
contract.
In the incremental approach, there is no complete
system specification until the final increment is
specified.
So which large customers such as government
agencies may find difficult to accommodate.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 26
4.2.1 Incremental delivery



The waterfall model of development requires
customers for a system to commit (make sure) to a set
of requirements before design begins and the
designer to commit to particular design strategies
before implementation.
An evolutionary approach to development allows
requirements and design decisions to be delayed
but also leads to software that may be poorly
structured and difficult to understand and maintain.
Incremental delivery is an in-between approach
that combines the advantages of these models. 71
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 27
In the incremental development process




Customer identify, in outline, the services should be
provided in the system.
They identify which of the services are most
important and which are least important to them.
A number of delivery increments are then defined,
with each increment providing a sub-set of the
system functionality.
The allocation (assign) of services to increments
depends on the service priority with the highest
priority services delivered first. 72
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 28
Incremental development
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 29
4.2.1 Incremental development
advantages
1.
2.
Customer do not have to wait until the entire
system is delivered before they can gain
value from it, the first increment satisfies
their most critical requirements so they can
use the software immediately.
Customer can use the early increments as
prototypes and gain experience that informs
their requirements for later system
increments.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 30
3.
4.
There is a lower risk of overall project failure.
Although problems may be encountered in some
increments, it is likely that most of them will be
successfully delivered to the customer.
As the highest priority services are delivered first,
and later increments are integrated with them, it is
inevitable that the most important system services
receive the most testing. This means that customers
are less likely to encounter software failures in the
most important parts of the system. 72
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 31
Incremental delivery problems


Should be relatively small ( no more than
20,000 lines of code )
Each increment should deliver some system
functionality.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 32
4.2.2 Spiral development




Process is represented as a spiral rather than as a
sequence of activities with backtracking.
Each loop in the spiral represents a phase in the
process.
No fixed phases such as specification or design loops in the spiral are chosen depending on what is
required.
Thus the innermost loop might be concerned with
system feasibility (practicability), the next loop with
requirements definition, the next loop may with
system designed.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 33
Spiral model of the software process
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 34
Spiral model sectors
Each loop in the spiral is split into four sectors:
1. Objective setting

Specific objectives for that phase are defined.
Constraints on the process and the product are
identified and a detailed management plan is drawn
up. Project risks are identified. Alternative strategies,
depending on these risks, may be planned.
2. Risk assessment and reduction (reduce)

For each of the identified project risks, a detailed
analysis is carried out. Steps are taken to reduce the
risk. For example, if there is risk that the requirements
are inappropriate, a prototype system may be
developed.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 35
3.
4.
Development and validation
•
After risk evaluation, a development model for the system
is chosen.
•
If safety risks are the main consideration, development
based on Formal Transformations may be the most
appropriate.
•
If the main identified risk is sub-system integration then
Waterfall model may be the most appropriate
development model.
Planning
•
The project is reviewed and the next phase of the spiral is
planned.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 36
Conclusion of Spiral development


The main difference between the spiral model and
other software process models is the explicit
recognize of risk in the spiral model.
For example, if the intention is to use a new
programming language, a risk is that the available
compilers are unreliable or do not produce
sufficiently efficient object code. So risk in project
problems such as schedule and cost overrun so risk
minimization is very important project management
activity.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 37





A cycle of the spiral begins by determine clear
objectives. such as performance and functionality.
Alternative ways of achieving these objectives and
the constraints imposed on each of the loop.
Each alternative is assessed or evaluate.
To resolve these risks by information-gathering
activities such as more detailed analysis,
prototyping and simulation.
Once risks have been assessed, some development
is carried out, followed by a planning activity for the
next phase of the process.
74
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 38
4.3 Process activities
1.
2.
3.
4.
Software specification
Software design and implementation
Software validation
Software evolution
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 39
4.3.1 Software specification


The process of establishing what services
are required and the constraints on the
system’s operation and development.
Requirements engineering process
1. Feasibility study;
•
©Ian Sommerville 2006
An estimate is made of whether the identified user
needs may be satisfied using current software and
hardware technologies, and whether the proposed
system will be cost-effective from a business point of
view and within existing budgetary constraints.
Software Engineering, 8th edition. Chapter 4
Slide 40
2.
Requirements elicitation (draw out) and analysis;
•
3.
Requirements specification;
•
4.
This is a process of deriving the system requirements
through observation of existing systems, discussions with
potential users and customer, task analysis and so on.
This activity will translating the information gathered during
the analysis activity into a set of requirement documents.
Requirements validation.
•
©Ian Sommerville 2006
This activity checks the requirements for consistency and
completeness .in this stage, error in the requirements
document may occur, it must be modified to correct these
problems.
Software Engineering, 8th edition. Chapter 4
Slide 41
The requirements engineering process
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 42
4.3.2 Software design and implementation


The process of converting the system
specification into an executable system.
Software design
•

Implementation
•

Design a software structure that realizes the
specification;
Translate this structure into an executable
program;
The activities of design and implementation
are closely related and may be interleaved.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 43
Design process activities
1.
Architectural design

2.
Abstract specification

3.
The sub-system making up the system and their
relationships are identified and documented.
For each sub-system, under its services an abstract
specification and the constraints which will be produced.
Interface design

For each sub-system, its interface with other sub-systems
is designed and documented. This interface specification
must be clear,
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 44
4.
Component design
•
5.
Data structure design
•
6.
Service are assigned to components and
interface of these components are designed.
To designed a detail and specified Data
structure for the implementation system.
Algorithm design
•
Detail designed and specified the algorithms
that used to provide service.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 45
The software design process
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 46
Structured methods
Structured methods is approach that rely on
producing graphical models of the system，
include a design process model，notations to
represent the design, report formats, rules and
design guidelines, it may support some or all of
the following models of a system:
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 47
Structured methods

Possible models
1. Object model; that show the object classes used in the
system and their dependencies.
2. Sequence model; show how objects in the system interact
when the system is executing.
3. State transition model; shows system states and the
triggers condition for the transitions from one state to another.
4. Structural model; to documented the system components
and their aggregations.
5. Data-flow model. to describe the model when data
transformation is processed. 78
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 48
Programming and debugging



Translating a design into a program and
removing errors from that program.
Programming is a personal activity - 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.
79
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 49
The debugging process
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 50
4.3.3 Software validation



Verification and validation (V & V) is
intended to show that a system conforms
(obedient) to its specification and meets the
requirements of the system customer.
Involves checking and review processes and
system testing.
System testing involves executing the
system with test cases that are derived
(gain) from the specification of the real data
to be processed by the system.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 51
The testing process
Figure 4.9
the testing process
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 52
Testing stages


Component or unit testing
•
Individual components are tested independently;
•
Components may be simple entities such as functions or
objects class. or may be related groupings of these
entities.
System testing
•
The components are integrated to make up the system.
•
This process is concerned with finding errors that result
from unanticipated (unexpected) interactions between
component interface problems.
•
It is also concerned with validating that the system meets
its functional and non-functional requirements.
•
For large systems, may be a multistage process where
components are integrated to form sub-systems that are
individually test before they are themselves integrated to
form the final system.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 53
Testing stages



Acceptance testing
• Testing with customer (real) data to check that
the system meets the customer’s needs.
• It may reveal errors and omissions in the
system requirements definition because the real
data exercise the system in different ways from
the test data. 80
Usually, system development and testing are
interleave.
Figure 4.10, explain how to connect with testing
plain between the development and testing
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 54
Testing phases
Figure 4.10
Testing Phases
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 55
Category of Acceptance Testing


Alpha testing: custom system are developed for a
single client. The Alpha testing process continues
until the system developer and client agree that the
delivered system is an acceptable implementation of
the system requirements.
Beta testing: when a system is to be marketed as a
software product, this testing process called Beta
testing, it involves delivering a system to a number
of potential customers who agree to use that
system. Then report problems to the system
developers. This exposes the product to real use
and detects errors that may not have been
anticipated by the system builders.
81
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 56
4.3.4 Software evolution


Once a decision has been made to procure
hardware, it is very expensive to make changes to
the hardware design, however change can be made
to software at any time during or after the system
development.
As requirements change through changing business
circumstances, the software that supports the
business must also evolve and change.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 57



Distinction between development and evolution
(maintenance) is becoming increasingly irrelevant
(unrelated) .
Fewer and fewer software systems are now
completely new systems,
It is more realistic to think of software engineering
as an evolutionary process. 82
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 58
System evolution
Figure 4.11
System evolution
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 59
4.4 The Rational Unified Process
(RUP)


A modern process model derived from the work on
the UML (Unified Modeling Language) and
associated process.
Normally described from 3 perspectives (viewpoint)
•
•
•
A dynamic perspective that shows phases over time;
A static perspective that shows process activities;
A practice perspective that suggests good practice.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 60
RUP phases


RUP is a phased model that identifies four discrete
(separated) phases in the software process. However, unlike
the waterfall model where phases are equated with process
activities, the phase of RUP are more closely related to
business rather than technical concerns.
Include four stage as followed : (Dynamic view)
1.
©Ian Sommerville 2006
Inception
•
Establish the business case for the system. You should
identify all external entities (people and system) that will
interact with the system and define these interactions.
You should use this information to assess the contribution
that the system makes to the business. In case the
contribution is minor then the project may be cancelled.
Software Engineering, 8th edition. Chapter 4
Slide 61
Dynamic view
2.
Elaboration
•
•
•
•
Toe goals is Develop an understanding of the problem domain
Establish an architecture framework for the system
Identify key project risks when develop project plan
When completion of this phase, you have


3.
Requirements model for the system (UML are specified)
Architectural description and software development plan
Construction
•
•
•
In this phase is essentially concerned System design,
programming and testing.
Some systems are developed in parallel and integrated during
this phase.
When completion, you should have a working software system
and associated documentation that is ready for delivery to users.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 62
4.
Transition
•
•
©Ian Sommerville 2006
Is final phase, concerned with moving the system
from the development environment to the user
community and making it work in a real environment.
This is a expensive and sometimes problematic
activity, but is ignored in the most software process
models. 83
Software Engineering, 8th edition. Chapter 4
Slide 63
Dynamic view

RUP is Iteration activities and supported in
two ways.
•
•
Each phase may be enacted (act) in an
interative way with the results (complete)
developed incrementally.
The whole set of phase may also be enacted an
interative way incrementally too, as show by the
looping arrow from Tasnsition to Inception in
followed next Figure 4.12
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 64
RUP phase model
P has e i terati on
Incepti on
©Ian Sommerville 2006
Elaborati on
Cons tructi on
Software Engineering, 8th edition. Chapter 4
Transi tion
Slide 65
Workflows in the RUP description


The static view of the RUP focuses on the
activities during the development process.
These are called workflows in RUP description
•
•
•
There are six core process workflows identified in
the process and three core supporting workflows.
The RUP has been designed in conjunction with
the UML (Unified Modeling Language)
The workflows show in followed figure 4.13
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 66
Static workflows (static view)
W ork flow
Descri ption
Business modelling
The business processes are modelled using business use cases.
Requirement s
Actors who interact with the system are ident ified and use cases are
developed to model the system requirement s.
Analysis and design
A design model is created and documented using architectural
models, component models, object models and sequ ence models.
Implementat ion
The components in the system are implemented and structured into
implementat ion sub-systems. Automat ic code generat ion from design
models helps accelerate this process.
Test
Test ing is an iterat ive process that is carried out in conjunct ion with
implementat ion. System test ing follows the completion of the
implementat ion.
Deployment
A product release is created, distributed to users and installed in their
workplace.
Configurat ion and
change management
This supporting workflow managed changes to t he system (see
Chapter 29).
Project management
This supporting workflow manages the system development (see
Chapter 5).
Environment
This workflow is concerned with making appropriate software tools
available to the software development team.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 67
RUP describes good SE practice
Six fundamental best practices are recommended:
1.
Develop software iteratively
•
•
2.
Plan increments of the system based on customer
requirement
Develop and deliver the highest priority system features
early in the development process.
Manage requirements
•
•
•
Explicitly the customer’s requirements document
keep track of change the requirements
Analyse the impact of changes on the system before
accepting them.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 68
3.
Use component-based architectures
•
4.
Visually model software
•
5.
Use graphical UML models to show static and dynamic
view of the software system.
Verify software quality
•
6.
Transfer the system structure into components
Ensure that the software meets the organization quality
standards.
Control changes to software
•
Manage changes to the software using a change
management system and configuration management
procedures and tools 84
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 69
4.5 Computer-aided software
engineering (CASE)



Computer-aided software engineering (CASE) is
software to support software development and
evolution processes activities.
The activities include such requirements
engineering, design, program development and
testing.
So case tool include design editors, data
dictionaries, compilers, debuggers, system
building tools and so on.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 70

Case technology provides software process
support by automating some process
activities and by providing information about
the software that is being developed.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 71

Example of Activity that can be automated :
1. Graphical editors for system model
development;
2. Data dictionary that holds information about the
entities and relations in a design;
3. Generation of user interfaces from a graphical
interface description that is created interactively
by the user;
4. Program debugging through the provision of
information about an executing program;
5. Automated translators to generate new versions
of a program from an old version of a
programming, language such as COBOL. 85
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 72
Case technology

Case technology has led to significant
improvements in the software process, in fact,
the improvements have been achieved 40%
saved. However, it did not generate huge
savings in software process costs.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 73

CASE are limited by two factor :
1. Software engineering requires creative thought
•
•
existing CASE system can easily automate routine
activities
But try to use artificial intelligence technology to
provide support for design have not been successful.
2. Software engineering is a team activity and, for
large projects, much time is spent in team
interactions. CASE technology does not really
support these.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 74
CASE technology is now mature

In the market the CASE tools and
workbenches are available from a wide
range of suppliers.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 75
CASE classification
Classification helps us understand the different types of
CASE tools and their support for process activities.
1.
Functional perspective
•
2.
Process perspective
•
3.
Tools are classified according to their specific
function.
Tools are classified according to process activities
that are supported.
Integration perspective
•
Tools are classified according to their organisation
into integrated units.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 76
Figure 4.14

In figure 4.14, according to functionality to
classified the case tool.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 77
Functional tool classification
Tool type
Examples
Planning tools
PERT tools, estimation tools, spreadsheets
Editing tools
Text editors, diagram editors, word processors
Change ma nagement tools
Requirements traceability tools, change control systems
Configuration management tools
Version management systems, system b uilding tools
Prototyping tools
Very high-level languages, user interface generators
Method-support tools
Design editors, data dictionaries, code generators
Language-processing tools
Compilers, interpreters
Program analysis tools
Cross reference generators, static analysers, dynamic analysers
Testing tools
Test data generators, file comp arators
Debugging tools
Interactive debugging systems
Documentation tools
Page layout programs , ima ge editors
Re-engineering tools
Cross-reference systems , program re-structuring systems
Figure 4.14
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 78
Figure 4.15

It is the other way to classified to show the
each step of development when use CASE
tools.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 79
Activity-based tool classification
R e-eng in eerin g to ols
Tes tin g to ols
Deb ug g in g too ls
Prog ram an aly sis to ol s
Lang u ag e-p ro ces sin g
to ol s
Meth o d s up po r t too ls
Prot oty p ing to ol s
C on fig urati on
man ag emen t to ol s
C hang e man ag emen t t oo ls
Documen tat io n t oo ls
Edit ing t oo ls
Plan ni ng to o ls
Figure 4.15
©Ian Sommerville 2006
Specifi catio n
Desi gn
Impl emen tat io n
Software Engineering, 8th edition. Chapter 4
Verificat ion
an d
Val idatio n
Slide 80
CASE integration
The other classified way for CASE is depending on it can support
the how wide of software process

Tools
•
Support individual process tasks such as design
consistency checking, text editing, etc.

Workbenches
•
Support a process phase such as specification or design,
Normally include a number of integrated tools.

Environments
•
Support all or a substantial part of an entire software
process. Normally include several integrated
workbenches.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 81
Tools, workbenches, environments
CASE
tech no lo g y
Wo rk ben ch es
To ols
Editors
Compilers
File
co mpar ato rs
Analy sis an d
d esign
Multi-metho d
wo rk ben ch es
©Ian Sommerville 2006
In teg rated
en v iro nmen ts
Pro grammin g
Sing le-meth od
wo rk ben ch es
Env iro nmen ts
Pro ces s-cen tr ed
en v iro nmen ts
Tes tin g
Gen er al-pu rp os e
wo rk ben ch es
Lang u ag e-s pecific
wo rk ben ch es
Software Engineering, 8th edition. Chapter 4
Slide 82
Key points
1.
2.
3.
4.
5.
Software processes are the activities involved in
producing and evolving a software system.
Software process models are abstract representations
of these processes.
General activities are specification, design and
implementation, validation and evolution.
Generic process models describe the organisation of
software processes. Examples include the waterfall
model, evolutionary development and componentbased software engineering.
Iterative process models describe the software
process as a cycle of activities.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 83
Key points
6.
7.
8.
9.
Requirements engineering is the process of developing
a software specification.
Design and implementation processes transform the
specification to an executable program.
Validation involves checking that the system meets to
its specification and user needs.
Evolution is concerned with modifying existing system
to meet new requirements. This is becoming the normal
approach to software development for small and
medium-sized systems.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 84
More informations

Computer Aided Software Engineering (CASE tool) Computer Aided Software Engineering
tools offer many benefits for developers building large-scale systems. As spiralling user
requirements continue to drive system complexity to new levels, enabling us to abstract away
from the entanglement of source code, to a level where architecture and design become more
apparent and easier to understand and modify. The larger a project, the more important it is to
use a case tool in software development.
As developers interact with portions of a system designed by their colleagues, they must quickly
seek a subset of classes and methods and assimilate an understanding of how to interface with
them. In a similar sense, management must be able, in a timely fashion and from a high level, to
look at a representation of a design and understand what's going on. For these reasons, CASE
tools coupled with methodologies give us a way of representing systems too complex to
comprehend in their underlying source code or schema-based form.
Select Business Solutions has been developing and building these CASE tools since the late
1980s, as well as developing processes and methods to support high quality application
development.
Solution Breakdown
Select Solution Factory a Business Process Modeling - BPM, a Unified Modeling
Language - UML modeling tool, and Data Modeling CASE Tool
Select Scope Manager a eXtreme Programming and Agile Modeling CASE Tool
Select SSADM a Structured Systems Analysis and Design Methodology CASE
Tool
Select Yourdon a real time CASE Tool supporting the Yourdon, Hatley-Pirbhai
and Ward-Mellor real-time extensions.
10.
11.
The Rational Unified Process is a modern generic
process model that is organised into phases
(inception, elaboration, construction and transition
“Dynamic perspective”) but that separates activities
(requirements, analysis and design, etc. ”Static
perspective”)
CASE technology provides automated supports for
software process. CASE tools support individual
process activities; workbenches support a set of
related activities; environments support all or most
software process activities.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 86
End week 6
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 87
Week 8 testing

Could you explain how many Software
process models in this chapter, and detail
explain them?
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 88
Ans

p65
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 89
Exercises 4.1

giving reasons for your answer based on the
type of system being developed, suggest the
most appropriate generic software process
model that might be used as a basis for
managing the development of the following
systems:
•
A system to control anti-lock braking in a car.
• Anti-lock braking system: Safety-critical system so
method based on formal transformations with proofs of
equivalence between each stage, therefore waterfall
model is appropriate.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 90
•
A virtual reality system to support software
maintenance :
• Virtual reality system, the system whose requirements
cannot be predicted in advance so exploratory
programming model is appropriate. (4.1.2) 68
•
A university accounting system that replaces an
existing system :
• System whose requirements should be stable
because of existing system therefore waterfall model
is appropriate.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 91
•
An interactive system that allows railway
passengers to find train times from terminals
installed in stations.
• System with a complex user interface but which must
be stable and reliable. Should be based on throwaway prototyping to find requirements then either
incremental development or waterfall model. (4.1.2) 68
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 92
Exercises 4.2

Explain why programs that are developed using
evolutionary development are likely to be difficult to
maintain.
•
From an engineering and management perspective, the
evolutionary approach has two problems:
• The process is not visible: Managers need regular
deliverables to measure progress. If systems are developed
quickly, it is not cost-effective to produce documents that
reflect every version of the system.
• Systems are often poorly structured: continual change tends
to corrupt the software structure. Incorporating software
changes becomes increasingly difficult and costly.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 93
Exercises 4.5

Suggest why it is important to make a distinction
between developing the user requirements and
developing system requirements in the requirements
engineering process.
•
•
User requirements (high-level abstract requirements): are
statement, in a natural language plus diagrams, of what
services the system is expected to provide and the constraints
under which it must operate.
System requirements (detailed description of what the system
should do, sometimes call a functional specification): set out
the system’s functions, services and operational constraints in
detail. The system requirements document should be precise
(exact). It should define exactly what is to be implemented. It
may be part of the contract between the system buyer and the
software developers.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 94
Exercises 4.6

Describe the main activities in the software
design process and the outputs of these
activities. Using a diagram, show possible
relationships between the outputs of these
activities.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 95
Answer 4.6
Architectural design
2. Abstract specification
3. Interface design
4. Component design
5. Data structure design
6. Algorithm design
The diagram as show on page 77, 4.3.2 figure 4.7
1.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 96
Exercises 4.8

Design a process model for running system
tests and recording their results.
No
Running program
Recording result
Error occur
System stop
Yes
Input new
data for test
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 97
Exercises 4.9

Explain why a software system that is used in realworld environment must change or become
progressively less useful.
•
Systems must change because as they are installed in an
environment the environment adapts to them and this
adaptation naturally generates new/different system
requirements. Furthermore, the system's environment is
dynamic and constantly generates new requirements as a
consequence (result) of changes to the business,
business goals and business policies. Unless the system
is adapted to reflect these requirements, its facilities will
become out-of-step with the facilities needed to support
the business and, hence, it will become less useful
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 98
Exercises 4.10

Suggest how a CASE technology classification
scheme may be helpful to managers responsible for
CASE system procurement
•
A classification scheme can be helpful for system
procurement because it helps identify gaps in the CASE
tool coverage in an organization. Procurement may be
aimed at filling these gaps. Alternatively, a classification
scheme may be used to find tools which support a range
of activities - these may represent the most cost effective
purchases if funds are limited.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 99
Exercises 4.12

Historically, the introduction of technology has
caused profound (deep) changes in the labour market
and, temporarily at least, displaced (replace) people
from jobs. Discuss whether the introduction of
advanced CASE technology is likely to have the
same consequences for software engineers. If you
don’t think it will, explain why not. If you think that it
will reduce job opportunities, is it ethical (moral) for
the engineers affected to passively (inactive) or
actively resist the introduction of this technology?
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 100

Ans:
•
•
There are obviously (easy understand) different views
here and a lot depends on the development of CASE
technology in the future. A major difference between the
introduction of CASE technology and, for example, the
introduction of CAD technology which made draftsmen
redundant, is that the routine elements in the design and
development of software are relatively minor parts of the
whole development process. Therefore, savings are not
that large. However, if AI (Artificial Intelligent) technology
develops so that truly intelligent tools can be developed
than, obviously, this situation will change.
By the way, new technology will change some job to
become redundant, but in the same time, it will create
new opportunity and new jobs for the new century.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 101
End
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 4
Slide 102