?

Software Engineering
Subject: SOFTWARE ENGINEERING Credit: 4

SYLLABUS

Overview:
Introduction: FAQs about Software Engineering; Professional and Ethical Responsibility;
Software Process: Models; Process Iteration, Specification, Software Design and
Implementation; Verification & Validation; Software Evolution; Automated Process Support.

Software Project Management and Requirements

Project Management: Management Activities, Project Pl Software Project Management and
Requirements Project Management: Management Activities, Project Planning, Project
Scheduling, Risk Management; Software Requirements: Functional and Non-Functional
Requirements, User Requirements, System Requirements, Requirements Document;
Requirements Engineering Process: Feasibility Studies, Requirements Elicitation and Analysis,
Requirements Validation, Requirements Management.

System Models, Software Prototyping and Specifications

System Models, Software Prototyping and Specifications System models: Context, Behavioural,
Data, and Object models, CASE Workbenches; Software Prototyping: Prototyping in the
Software Process, Rapid Prototyping Techniques, User Interface Prototyping; Specifications:
Formal Specification in the Software Process, Interface Specification, Behavioural Specification.

Architectural Design
Introduction: System Structuring; Control Models; Modular Decomposition; Domain- Specific
Architectures; Distributed Systems Architectures: Multiprocessor Architectures; Client-Server
Architectures, Distributed Object Architectures; CORBA (Common Object Request Broker
Architecture)

Software Design
Object Oriented Design: Objects and Object Classes, Object-Oriented Design Process, Design
Evolution; Real Time Software Design: Systems Design, Real-Time Executives, Monitoring and
Control Systems, Data Acquisition Systems; Design with Reuse: Component-Based
Development, Application Families, Design Patterns; User Interface Design: Principles, User
Interaction, Information Presentation, User Support, Interface Evaluation.

Verification, Validation and Testing

Verification and Validation (V & V): Static and Dynamic V & V, V & V Goals, V & V vs.
Debugging, Software Inspections / Reviews, Clean-Room Software Development; Software
Testing: Defect Testing, Integration Testing, Interface Testing, Object-Oriented Testing, Testing
Workbenches
Managing People
Introduction; Limits to Thinking; Memory Organization; Knowledge Modeling; Motivation;
Group Working; Choosing and Keeping People; the People Capability Maturity Model

Software Cost Estimation and Quality Management

Software Cost Estimation: Productivity, Estimation Techniques, Algorithmic Cost Modelling,
Project Duration and Staffing. Quality Management: Quality Assurance and Standards, Quality
Planning, Quality Control, Software Measurement and Metrics; Process Improvement: Process
and Product Quality, Process Analysis and Modelling, Process Measurement, the SEI Process
Maturity Model, and Process Classification

Evolution
Legacy Systems: Structures, Design, and Assessment; Software Change: Program Evolution
Dynamics, Software Maintenance, Architectural Evolution; Software Re- Engineering: Source
Code Translation, Reverse Engineering, Program Structure Improvement, Program
Modularization, Data Re-Engineering; Configuration Management

Suggested Readings:
1. Software Engineering: An Engineering Approach, by J.F.Peters and W. Pedrycz,
Publisher: John Wiley and Sons
2. Software Engineering: A Practitioner's Approach by Roger Pressman, Publisher:
McGraw-Hill
3. Fundamentals of Software Engineering by Ghezzi, Jayazeri, and Mandrioli, Publisher:
Prentice-Hall
4. Software Engineering Fundamentals by Ali Behforooz, and Frederick J.Hudson,
Publisher: Oxford University Press
 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING (MBA)

COURSE OVERVIEW

Software systems are now ubiquitous. Virtually all electrical equipment now includes some kind of
software; software is used to help run manufacturing industry, schools and universities, health care,
finance and government; many people use software of different kinds for entertainment and education.
The specification, development, management and evolution of these software systems make up the
discipline of software engineering.

Even simple software systems have a high inherent complexity so engineering principles have to be used
in their development. Software engineering is therefore an engineering discipline where software
engineers use methods and theory from computer science and apply this cost-effectively to solve difficult
problems. These difficult problems have meant that many software development projects have not
been successful. However, most modern software provides good service to its users; we should not let
high-profile failures obscure the real successes of software engineers over the past 30 years.

Software engineering was developed in response to the problems of building large, custom software
systems for defence, government and industrial applications. We now develop a much wider range of
software from games on specialized consoles through personal PC products and web-based systems to
very large-scale distributed systems. Although some techniques that are appropriate for custom systems,
such as object-oriented development, are universal, new software engineering techniques are evolving for
different types of software. It is not possible to cover everything in one book so I have concentrated on
universal techniques and techniques for developing large-scale systems rather than individual software
products.

Although the book is intended as a general introduction to software engineering, it is oriented towards
system requirements engineering. I think this is particularly important for software engineering in the
21st century where the challenge we face is to ensure that our software meets the real needs of its users
without causing damage to them or to the environment.

The approach that I take in this book is to present a broad perspective on software engineering and I
don’t concentrate on any specific methods or tools. There are no simple solutions to the problems of
software engineering and we need a wide spectrum of tools and techniques to solve software engineer-
ing problems.

i
SOFTWARE ENGINEERING

Software Engineering

CONTENT
Lesson No. Topic Page No.

Lesson 1 Introduction 1
Lesson 2 Software Processes 6
Lesson 3 Software Processes 9
Lesson 4 Project Management 13
Lesson 5 Project Management 16
Lesson 6 Software Requirements 20
Lesson 7 Software Requirements 23
Lesson 8 Requirements Engineering Process 27
Lesson 9 Requirements Engineering Process 31
Lesson 10 System Models 36
Lesson 11 System Models 39
Lesson 12 Software Prototyping 43
Lesson 13 Software Prototyping 45
Lesson 14 Formal Specifications 49

Lesson 15 Architectural Design 54

Lesson 16 Architectural Design 57

Lesspn 17 Distributed Systems Architectures 61

Lesson 18 Distributed Systems Architectures 64

Lesson 19 Object-Oriented Design 67

Lesson 20 Object-Oriented Design 70
Lesson 21 Real-time Software Design 74
Lesson 22 Real-time Software Design 78
Lesson 23 Design with Reuse 81
Lesson 24 User Interface Design 85
Lesson 25 User Interface Design 88
Lesson 26 Verification and Validation 93
Lesson 27 Software Testing 97
Lesson 28 Software Testing 101
Lesson 29 Managing People 104

iv
 SOFTWARE ENGINEERING
Software Engineering

CONTENT
Lesson No. Topic Page No.

Lesson 30 Managing People 106

8 Lesson 31 Software Cost Estimation 112

Lesson 32 Software Cost Estimation 115
Lesson 33 Quality Management 120
Lesson 34 Quality Management 123
Lesson 35 Process Improvement 127

9 Lesson 36 Legacy Systems 132

Lesson 37 Software Change 139
Lesson 38 Software Re-Engineering 144
Lesson 39 Configuration Management 149
Lesson 40 Configuration Management 152

v
 UNIT I
OVERVIEW AND REQUIREMENTS
LESSON 1: UNIT 1
INTRODUCTION CHAPTER 1

Getting Started With Software Software products may be developed for a particular customer

SOFTWARE ENGINEERING
Engineering or may be developed for a general market
Objectives Software products may be
• To introduce software engineering and to explain its • Generic - developed to be sold to a range of different
importance customers
• To set out the answers to key questions about software • Bespoke (custom) - developed for a single customer
engineering according to their specification
• To introduce ethical and professional issues and to explain What is Software Engineering?
why they are of concern to software engineers Software engineering is an engineering discipline, which is
concerned with all aspects of software production
Topics Covered
Software engineers should adopt a systematic and organised
• FAQs about software engineering
approach to their work and use appropriate tools and tech-
• Professional and ethical responsibility niques depending on the problem to be solved, the
Software Engineering development constraints and the resources available
The economies of ALL developed nations are What is The Difference Between Software
dependent on software Engineering and Computer Science?
More and more systems are software controlled Computer science is concerned with theory and fundamentals;
Software engineering is concerned with theories, methods and software engineering is concerned with the practicalities of
tools for professional software development developing and delivering useful software
Software engineering expenditure represents a Computer science theories are currently insufficient to act as a
significant fraction of GNP in all developed countries complete underpinning for software engineering
Software Costs What is The Difference Between Software
Software costs often dominate system costs. The costs of Engineering and System Engineering?
software on a PC are often greater than the hardware cost System engineering is concerned with all aspects of computer-
based systems development including hardware, software and
Software costs more to maintain than it does to develop. For
process engineering. Software engineering is part of this process
systems with a long life, maintenance costs may be several times
development costs System engineers are involved in system specification, architec-
Software engineering is concerned with cost-effective software tural design, integration and deployment
development What is a Software Process?
FAQs About Software Engineering A set of activities whose goal is the development or evolution
of software
What is software?
Generic activities in all software processes are:
What is software engineering?
• Specification : what the system should do and its
What is the difference between software engineering and development constraints
computer science?
• Development : production of the software system
What is the difference between software engineering and system
• Validation : checking that the software is what the customer
engineering?
wants
What is a software process?
• Evolution : changing the software in response to changing
What is a software process model? demands
What are the costs of software engineering?
What is a Software Process Model?
What are software engineering methods? A simplified representation of a software process, presented
What is CASE (Computer-Aided Software Engineering) from a specific perspective
What are the attributes of good software? Examples of process perspectives are
What are the key challenges facing software engineering? • Workflow perspective : sequence of activities

What is Software?
Computer programs and associated documentation

1
 • Data-flow perspective : information flow Software must be usable by the users for which it was designed
SOFTWARE ENGINEERING

• Role/action perspective : who does what What are the Key Challenges Facing Software
Generic Process Models Engineering?
Coping with legacy systems, coping with increasing diversity and
• Waterfall
coping with demands for reduced delivery times
• Evolutionary development
Legacy Systems
• Formal transformation
Old, valuable systems must be maintained and updated
• Integration from reusable components
Heterogeneity
What are The Costs of Software Engineering? Systems are distributed and include a mix of hardware and
Roughly 60% of costs are development costs, 40% are testing software
costs. For custom software, evolution costs often exceed
Delivery
development costs
There is increasing pressure for faster delivery of software
Costs vary depending on the type of system being developed
and the requirements of system attributes such as performance Professional and Ethical Responsibility
and system reliability Software engineering involves wider responsibilities than simply
the application of technical skills
Distribution of costs depends on the development model that
is used Software engineers must behave in an honest and ethically
responsible way if they are to be respected as professionals
What are Software Engineering Methods?
Structured approaches to software development which include Ethical behaviour is more than simply upholding the law.
system models, notations, rules, design advice and process Issues of Professional Responsibility
guidance
Confidentiality
Model Descriptions Engineers should normally respect the confidentiality of their
Descriptions of graphical models, which should be produced employers or clients irrespective of whether or not a formal
Rules
confidentiality agreement has been signed.
Constraints applied to system models Competence
Recommendations Engineers should not misrepresent their level of competence.
Advice on good design practice They should not knowingly accept work, which is out with,
their competence.
Process Guidance
What activities to follow Intellectual Property Rights
Engineers should be aware of local laws governing the use of
What is Case (Computer-aided Software intellectual property such as patents, copyright, etc. They should
Engineering)? be careful to ensure that the intellectual property of employers
Software systems which are intended to provide automated and clients is protected.
support for software process activities. CASE systems are often
Computer Misuse
used for method support
Software engineers should not use their technical skills to
Upper-CASE misuse other people’s computers. Computer misuse ranges
Tools to support the early process activities of requirements and from relatively trivial (game playing on an employer’s machine,
design say) to extremely serious (dissemination of viruses).
Lower-CASE ACM/IEEE Code of Ethics
Tools to support later activities such as programming, debug- The professional societies in the US have cooperated to produce
ging and testing a code of ethical practice.
What are The Attributes of Good Software? Members of these organisations sign up to the code of practice
The software should deliver the required functionality and when they join.
performance to the user and should be maintainable, depend- The Code contains eight Principles related to the behaviour of
able and usable and decisions made by professional software engineers,
Maintainability including practitioners, educators, managers, supervisors and
Software must evolve to meet changing needs policy makers, as well as trainees and students of the profes-
sion.
Dependability
Software must be trustworthy Code of Ethics : Preamble
Efficiency Preamble
Software should not make wasteful use of system resources • The short version of the code summarizes aspirations at a
Usability high level of the abstraction; the clauses that are included in

2
 the full version give examples and details of how these The software process consists of activities, which are involved,

SOFTWARE ENGINEERING
aspirations change the way we act as software engineering in developing software products. Basic activities are software
professionals. Without the aspirations, the details can specification, development, validation and evolution.
become legalistic and tedious; without the details, the Methods are organised ways of producing software. They
aspirations can become high sounding but empty; together, include suggestions for the process to be followed, the
the aspirations and the details form a cohesive code. notations to be used, and rules governing the system descrip-
• Software engineers shall commit themselves to making the tions, which are produced and design guidelines.
analysis, specification, design, development, testing and CASE tools are software systems, which are designed to
maintenance of software a beneficial and respected support routine activities in the software process such as editing
profession. In accordance with their commitment to the design diagrams, checking diagram consistency and keeping track
health, safety and welfare of the public, software engineers of program tests which have been run.
shall adhere to the following Eight Principles:
Software engineers have responsibilities to the engineering
Code of Ethics : Principles profession and society. They should not simply be concerned
1. Public with technical issues.
Software engineers shall act consistently with the public interest. Professional societies publish codes of conduct, which set out
the standards of behaviour expected of their members.
2. Clients and Employer
Software engineers shall act in a manner that is in the best Activity
interests of their client and employer consistent with the public What are the four important attributes, which all software
interest. products have? Suggest four attributes, which may be
3. Product significant.
Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
4. Judgment
Software engineers shall maintain integrity and independence in
their professional judgment.
5. Management
Software engineering managers and leaders shall subscribe to
and promote an ethical approach to the management of
software development and maintenance.
6. Profession
Software engineers shall advance the integrity and reputation of
the profession consistent with the public interest.
7. Colleagues
Software engineers shall be fair to and supportive of their
colleagues.
8. Self
Software engineers shall participate in lifelong learning regarding
the practice of their profession and shall promote an ethical
approach to the practice of the profession.
Ethical Dilemmas
Disagreement in principle with the policies of senior manage-
ment
Your employer acts in an unethical way and releases a safety-
critical system without finishing the testing of the system
Participation in the development of military weapons systems
or nuclear systems
Key Points
Software engineering is an engineering discipline, which is
concerned with all aspects of software production.
Software products consist of developed programs and associ-
ated documentation. Essential product attributes are
maintainability, dependability, efficiency and usability.

3
 Activity Activity
SOFTWARE ENGINEERING

What are the four important attributes, which all software Software engineering methods only became widely used when
products should have? Suggest four other attributes, which CASE technology became available to support them. Suggest
may be significant. five types of method support, which can be provided by CASE
tools.

Activity Activity
Explain why system-testing costs are particularly high for generic Apart from the challenges of legacy systems, heterogeneity and
software products, which are sold to a very wide market. rapid delivery, identify other problems and challenges that
software engineering is likely to face in the 21st century.

4
 SOFTWARE ENGINEERING

5
Notes -
 UNIT I
OVERVIEW AND REQUIREMENTS
LESSON 2 AND 3:
SOFTWARE PROCESSES CHAPTER 2

Coherent Sets of Activities For Specifying, Designing, Waterfall Model

SOFTWARE ENGINEERING

Implementing And Testing Software Systems

Objectives
• To introduce software process models Requirements
definition
• To describe a number of generic process models and when
they may be used System and
software design
• To outline lower-level process models for requirements
engineering, software development, testing, and evolution
Implementation
• To introduce CASE technology to support software process and unit testing
activities
Integration and
Topics Covered system testing
• Software process models
Operation and
• Process iteration maintenance
• Software specification
• Software design and implementation
• Software verification & validation
Waterfall Model Problems
• Software evolution Inflexible partitioning of the project into distinct stages makes
Automated process support it difficult to respond to changing customer requirements.
The Software Process Thus, this model is only appropriate when the requirements are
A structured set of activities required to develop a well understood.
software system In general, the drawback of the waterfall model is the difficulty
• Specification of accommodating change after the process is underway.
• Design Evolutionary Development
• Validation / verification Exploratory Development *– objective is to work with
customers and to evolve a final system from an initial outline
• Evolution
specification. (Development starts with well-understood parts
A software process model is an abstract representation of a of system.)
process. It presents a description of a process from some
Throwaway Prototyping – objective is to understand the system
particular perspective
requirements. (Prototyping focuses on poorly understood
Models should be as simple as possible, but no requirements.)
Simpler. – A. Einstein • Also known as exploratory programming, or evolutionary
Generic Software Process Models prototyping
The Waterfall Model : separate and distinct phases of specifica- Evolutionary development
tion and development
Evolutionary Development : specification and development are Concurrent
interleaved activities

Formal Systems Development : a mathematical system model is Initial

formally transformed to an implementation Specification
version
Reuse-Based Development : the system is assembled from
existing components Outline
Development
Intermediate
description versions

Final
Validation
version

6
Potential Problems • Process stages

SOFTWARE ENGINEERING
• Lack of process visibility • Reusable software analysis
• Final version/prototype is often poorly structured • Requirements modification
• Special skills (e.g., in languages for rapid prototyping) may be • System design with reuse
required • Development and integration
Applicability This approach is becoming more important, but experience is
• For small or medium-size interactive systems still limited.
• For parts of large systems (e.g., the user interface) R e qu ire m e n ts
s pe c ifi c a ti on
C o m po ne nt
a na l ys is
R e qu ire m e n ts
m o di fi c a ti on
S yst e m de sig n
w i th re u se

• For short-lifetime systems (in case of exploratory

development) D e ve l opm e nt
a nd int e gr a tio n
S y st e m
v al id a ti on

Formal Systems Development

Based on the transformation of a mathematical specification Process Iteration
through different representations to an executable program For large systems, requirements ALWAYS evolve in the course
of a project.
Transformations are “correctness-preserving” so it is possible to
show that the program conforms to its specification Thus, process iteration is ALWAYS part of the process.
Embodied in Mills’ “Clean room” approach to software Iteration can be incorporated in any of the generic process
development models
Requirements Formal Formal Integration and Two other approaches that explicitly incorporate iteration:
definition specification transformation system testing
• Incremental development
• Spiral development
Formal Transformations
Incremental Development
Formal transformations Rather than deliver the system as a single unit, the development
T1 T2 T3 T4 and delivery is broken down into increments, each of which
incorporates part of the required functionality.
Formal Executable
User requirements are prioritised and the highest priority
R1 R2 R3
specification program requirements are included in early increments.
Once the development of an increment is started, its require-
P1 P2 P3 P4 ments are “frozen” while requirements for later increments can
continue to evolve.
Proofs of transformation correctness
Define outline Assign requirements Design system
requirements to increments architecture
Problems
• Need for specialized skills and training to apply the technique Develop system Validate Integrate Validate
increment increment increment system
• Difficult to formally specify some aspects of the system such
Final
as the user interface (thus, focus is usually limited to system
functional requirements) System incomplete

Applicability Incremental Development Advantages

• Critical systems, especially those where a safety or security case Useful functionality is delivered with each increment, so
must be made before the system is put into operation customers derive value early.
• Critical parts of large systems Early increments act as a prototype to help elicit requirements
Reuse-oriented Development for later increments.
Based on systematic (as opposed to serendipitous) reuse of Lower risk of overall project failure
existing software units The highest priority system services tend to receive the most
Units may be: testing.
• Procedures or functions (common for past 40 years) Potential Problem
• Components (“component-based development”) Requirements may NOT be partitionable into stand-alone
• Core elements of an application (“application family”)
increments.

• Entire applications — COTS (Commercial-off-the-shelf) Extreme Programming (Beck ’99)

systems Recent evolution of incremental approach based on
May also be based on use of design patterns

7
 • Development and delivery of very small increments of Software Specification
SOFTWARE ENGINEERING

functionality The process of establishing what services are required and the
• Significant customer involvement in process constraints on the system’s operation and development
• Constant code improvement Requirements Engineering Process
• Ego less, pair-wise programming • Feasibility (technical and otherwise) study

NOT document-oriented • Requirements elicitation and analysis

Gaining acceptance in some small organizations • Requirements specification (documentation)

Representative of the “agile” development paradigm • Requirements validation

Boehm’s Spiral Development The Requirements Engineering Process

Process is represented as a spiral rather than a sequence of
activities. Feasibility Requirements
study elicitation and
Each loop in the spiral represents a phase in the process. analysis
Requirements
No fixed phases such as specification or design — loops in the specification
spiral are chosen depending on what is required Feasibility Requirements
report validation
Explicitly incorporates risk assessment and resolution throughout
System
the process models

Spiral Model of the Software Process User and system

requirements

Requirements
Determine objectives document
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis Software Design and Implementation
Risk
analysis Opera- The process of producing an executable system based on the
Prototype 3 tional
Prototype 2 protoype specification
Risk
REVIEW analysis Proto-
type 1
Software design – design a software structure that realizes the
Requirements plan Simulations, models, benchmarks specification
Life-cycle plan Concept of
Operation S/W Implementation – translate this structure into an executable
requirements Product
design Detailed program
Requirement design
Development
plan validation Code The activities of specification, design, and implementation are
Unit test
Integration Design
V&V Integration
closely related and may be inter-leaved.
and test plan
Plan next phase test
Service
Acceptance
test Develop, verify
Design Process Activities
next-level product
“High-Level” design activities
• Architectural design : subsystems and their relationships are
identified
Spiral Model Quadrants
• Abstract specification : of each sub-system’s services
Objective Setting : specific objectives for the phase are identified
• Interface design : among sub-systems
Risk Assessment and Reduction : risks are assessed and
activities put in place to reduce the key risks “Low-Level” design activities
Development and Validation : a development model for the • Component design : services allocated to different
system is chosen which can be any of the generic models components and their interfaces are designed
Planning : the project is reviewed and the next phase of the • Data structure design
spiral is planned • Algorithm design

Models for Fundamental Process Activities

Software specification/requirements engineering
Software development (design and implementation)
Software verification and validation
Software evolution

8
The Software Design Process

SOFTWARE ENGINEERING
Requirements
specification

Design activities

Architectural Interface Component Data Algorithm

Abstract
design design design structure design
specification
design

Software Data
System Interface Component Algorithm
specification structure
architecture specification specification specification
specification

Design products
Design Methods Sub-system/product testing : sub-systems or products are
Systematic (canned) approaches to developing a software design tested
The design is usually documented as a set of graphical models (product/sub-system) Integration testing
Possible Models System testing : testing of the system as a whole, including user
acceptance test
• Data-flow model
• Entity-relation-attribute model Software Evolution
Software is inherently flexible and subject to change.
• Structural model
As requirements change through changing business circum-
• Object models
stances, the software that supports the business must also
Programming and Debugging evolve and change.
Translating a design into a program and removing errors from The distinction between development and evolution is
that program (compare with Clean room SE) increasingly irrelevant as fewer and fewer systems are completely
Programming is a “personal activity” - a there is no generic new.
programming process
Programmers carry out some program testing to discover faults
(“unit testing”), and remove faults in the debugging process Define system Assess existing Propose system Modify
requirements systems changes systems
The Debugging Process
Locate Design Repair Re-test
error error repair error program Existing New
systems system
Software Verification & Validation
Verification and validation (V&V) determines whether or not a Automated Process Support (Case)
system Computer-aided software engineering (CASE) is software to
(1) conforms to its specification and (2) meets the needs of the support software development and evolution processes
customer. Activity automation
Involves inspection / review processes and (machine-based) • Graphical editors for system model development
testing
• Data dictionaries for name management
Testing involves executing system elements with test cases that
• GUI builders for user interface construction
are derived from specifications and/or program logic.
• Debuggers to support program faultfinding
Testing Stages
• Automated translators to generate new versions of a
Unit/Module testing : individual function/procedures are
program
tested
(e.g., restructuring tools)
(unit/module) Integration testing
Component testing : functionally related units/modules are CASE Technology
tested together CASE technology has led to significant improvements in the
software process, but not the order of magnitude improve-
(component) Integration testing
ments that were once predicted.

9
 • Software engineering involves design activity requiring Requirements engineering is the process of establishing what
SOFTWARE ENGINEERING

creative thought : this is not readily automatable services are required and the constraints on the system’s
• Software engineering is a team activity and, for large projects, operation and development.
much time is spent in team interactions. CASE technology Design and implementation processes produce an executable
does not support this well. system based on the specification.
CASE Classification V&V involves checking that the system meets its specification
Classification helps us understand the different types of CASE and satisfies user needs.
tools / systems and their support for process activities Evolution is concerned with modifying the system after it is
Functional perspective : tools are classified according to their placed in use.
specific function CASE technology supports software process activities
Process perspective : tools are classified according to process Activity
activities that are supported
Giving reasons for your answer based on the type of system
Integration perspective : CASE systems are classified according being developed, suggest the most appropriate generic software
to their breadth of support for the software process process model which might be used as a basis for managing the
CASE Integration development of the following systems:
Tools – support individual process tasks such as design • A system to control anti –lock braking in a car.
consistency checking, text editing, etc. • A virtual reality system to support software maintenance:
Workbenches : support a process phase such as specification or • A university accounting system that replaces an existing
design, Normally include a number of integrated tools system;
Environments : support all or a substantial part of an entire • An interactive system for railway passengers that finds train
software process. Normally include several integrated work- times from terminals installed in stations.
benches
Tools, Workbenches, Environments

CASE
technology

Tools Workbenches Environments

File Integrated Process-centred

Editors Compilers
comparators environments environments

Analysis and
Programming Testing
design

Multi-method Single-method General-purpose Language-specific

workbenches workbenches workbenches workbenches

Key Points
Software processes are the activities involved in producing and
evolving a software system. They are represented in a software
process model.
Fundamental activities are specification, design and implementa-
tion, validation & verification, and evolution.
Generic models are very general process models representing
different approaches to development.
Iterative process models describe the software process as a cycle
of activities.

10
Activity Activity

SOFTWARE ENGINEERING
Explain why programs which are developed using evolutionary Suggest why it is important to make a distinction between
development are likely to be difficult to maintain. developing the user requirements and developing the system
requirements in the requirements engineering process.

Activity Activity
Explain how both the waterfall model of the software process Describe the main activities in the software design process and
and the prototyping model can be accommodated in the spiral the outputs of these activities. Using an entity- relation
process model. diagram, show possible relationships between the outputs of
these activities.

11
 Activity Activity
SOFTWARE ENGINEERING

What are the five components of a design method? Take any Explain why a software system that is used in a real-world
method which you know and describe its components. Assess environment must change or become progressively less useful.
the completeness of the method, which you have chosen.

Activity Activity
Design a process model for running system tests and recording Suggest how a CASE technology classification scheme may be
their results. helpful to managers responsible for CASE system procure-
ment.

12
 UNIT I
OVERVIEW AND REQUIREMENTS
LESSON 4 AND 5: UNIT 2
PROJECT MANAGEMENT CHAPTER 3

Organizing, Planning and Scheduling Software Projects • Many techniques of engineering project

SOFTWARE ENGINEERING
Objectives management are equally applicable to software project
management.
• To introduce software project management and to describe
its distinctive characteristics • Technically complex engineering systems tend to suffer from
most of the same problems as software systems.
• To discuss project planning and the planning process
• To show how graphical schedule representations are used by
Project Staffing
project management • May not be possible to appoint the ideal people to work on
a project…
• To discuss the notion of risks and the risk management
process •Project budget may not allow for use of highly paid staff.
Topics Covered •Those with appropriate skills / experience may not be
available.
• Management activities
•An organization may wish to develop employee skills by
• Project planning
assigning inexperienced staff.
• Project scheduling
• Managers have to work within these constraints especially
• Risk management when (as is currently the case) there is an international
Software Project Management shortage of skilled IT staff.
• Concerned with activities involved in ensuring Project Planning
that software is delivered on time, within budget and in • Probably the most time-consuming project management
accordance with the requirements of the organizations activity (or at least it should be).
developing and procuring the software.
• Continuous activity from initial concept to system delivery.
• Project management is needed because software Plans must be regularly revised as new information becomes
development is always subject to budget and schedule available.
constraints that are set by the organization developing the
• Different types of sub-plans may be developed to support a
software.
main software project plan concerned with overall schedule
Software Management Distinctions and budget.
• The product is intangible. Types of Project Sub-plans
• The product is uniquely flexible.
• Software engineering is not recognized as an engineering Plan Description
Quality plan Describes the quality procedures and
discipline with the same status as mechanical, electrical standards that will be used in a project.
engineering, etc. Validation plan Describes the approach, resources and
• The software development process is not schedule used for system validation.
Configuration Describes the configuration management
standardized. management plan procedures and structures to be used.
• Many software projects are “one-off ” projects. Maintenance plan Predicts the maintenance requirements of
the system, maintenance costs and effort
Management Activities required.
Staff development plan. Describes how the skills and experience of
• Proposal writing (to fund new projects)
the project team members will be
• Project planning and scheduling developed.
• Project costing and preparing bids
• Project monitoring and reviews Project Planning
• Personnel selection and evaluation • “The plan is nothing – the planning is everything.”

• Report writing and presentations – Dwight Eisenhower, on the

D-Day invasion plan
• Attending lots and lots of meetings!

Management Commonalities
• These activities are not peculiar to software
management.

13
 Project Planning Process • Organize as concurrent activities to make optimal use of
SOFTWARE ENGINEERING

workforce.
Establish the project constraints • Minimize task dependencies to avoid potential delays.
Make initial assessments of the project parameters • Dependent on project managers’ intuition and experience
Define project milestones and deliverables
The Project Scheduling Process
while project has not been completed or canceled loop
Draw up project schedule
Initiate activities according to schedule Identify Identify activity Estimate resources Allocate people Create project
activities dependencies for activities
Wait (for a while) toactivities charts

Revise estimates of project schedule

Re-negotiate project constraints and deliverables Software Activity charts
requirements and bar charts
if (problems arise) then
Initiate technical review and possible revision
Scheduling Problems
end if
end loop • Estimating the difficulty of problems, and hence the cost of
developing solutions, is hard.
Project Plan Document Structure • Progress is generally not proportional to the number of
• Introduction (goals, constraints, etc.) people working on a task.
• Project organisation • Adding people to a late project can make it later. (due to
coordination overhead)
• Risk analysis
• The unexpected always happens. Always allow for different
• Hardware and software resource requirements
contingencies in planning.
• Work breakdown
Bar Charts and Activity Networks
• Project schedule
• Graphical notations are often used to illustrate project
• Monitoring and reporting mechanisms
schedules.
Activity Organization • Activity charts (a.k.a. PERT* charts) show task dependencies,
• Activities in a project should be associated with tangible durations, and the critical path.
outputs for management to judge progress (i.e., to provide • Bar charts (a.k.a. GANTT charts) generally show resource
process visibility) (e.g., people) assignments and calendar time.
• Milestones are the unequivocal end-points of process * Program Evaluation and Review Technique
activities.
Task Durations and Dependencies
• Deliverables are project results delivered to customers.
(There are also internal deliverables.) Task Duration (days) Dependencies
• The waterfall model allows for the straightforward definition T1 8
of milestones (“a deliverable oriented model”). T2 15
T3 15 T1 (M1)
• Deliverables are always milestones, but milestones are not T4 10
necessarily deliverables T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
Milestones in The Re Process T7 20 T1 (M1)
ACTIVITIES T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
Feasibility Requirements Prototype Design Requirements
T11 7 T9 (M6)
study analysis development study specification
T12 10 T11 (M8)

Feasibility Requirements Evaluation Architectural Requirements Activity Network

report definition report design specification
1 4/ 7/99 1 5 d ay s
1 5 d ay s
M1 T3
MILESTONES 8 day s T9
T1 5 d ays 4/ 8/99 2 5/8/99
2 5/ 7/99
T6 M4 M6
4/7/99 M3
Project Scheduling s tart
1 5 d ay s
2 0 d ay s 7 day s
T7 T1 1
T2
• Split project into tasks and estimate time and resources 5/9/99
2 5/7/99 1 0 d ay s 1 1/ 8/99
1 0 d ay s
required to complete each. M2
T5
M7
1 5 d ay s
M8
T4

• Tasks should not be too small or too large they should last 1 8/ 7/99
T10 10 days
T12
on the order of weeks for projects lasting months. M5
2 5 d ay s
T8 Fi nish
1 9/9/ 99

14
Activity Timeline

SOFTWARE ENGINEERING
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Start
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T1 1
M8
T12
Finish

Staff Allocation

4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10

Jim T7

Mary T5

15
 Risk Management Risks and Risk Types
SOFTWARE ENGINEERING

• Risk management is concerned with identifying risks and

drawing up plans to minimize their effect on a project. Risk type Possible risks
• A risk is a probability that some adverse circumstance will Technology The database used in the system cannot process as
many transactions per second as expected.
occur. Software components which should be reused contain
Project risks affect schedule or resources. defects which limit their functionality.
People It is impossible to recruit staff with the skills required.
Product risks affect the quality or performance of the software Key staff are ill and unavailable at critical times.
being developed. Required training for staff is not available.
Organisational The organisation is restructured so that different
Business risks affect the organisation developing or procuring management are responsible for the project.
Organisational financial problems force reductions in the
the software. project budget.
(Taxonomy based on Effect) Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Software Risks Requirements Changes to requirements which require major design
rework are proposed.
Customers fail to understand the impact of requirements
changes.
Risk Risk t ype Description Estimation The time required to develop the software is
Staff turnover Project Experienced staff will leave the underestimated.
projec t befor e it is finis hed. The rate of defect repair is underestimated.
Mana gement change Project There will be a c hange of The size of the software is underestimated.
organ isational management with
different priorities.
Hardw are unavailab ility Project Hardw are which is ess ential for the
projec t w ill not be delivered on
sched ule.
Requirements change Project and There will be a larger numb er of Risk Analysis
product changes to the requirements than
anticipate d. • Assess probability and seriousness of each risk.
Specification delays Project and Specifications of ess ential interfaces
product are not available on sc hedule • Probability may be very low, low, moderate, high or very
Size underestimate Project and The size of the syst em has been
product underestimated. high.
CAS E t ool under- Product CASE t ools w hich su pport the
performance projec t do not perform as anticipated • Risk effects might be catastrophic, serious, tolerable or
Tec hnology change Bus iness The underlying technology on which insignificant.
the sys tem is b ui lt is su pe rseded by
new tec hnology.
Product comp etition Bus iness A competitive product is marketed
before t he sys tem is com plete d. Risk Probability Effects
Organisational financial problems force reductions Low Catastrophic
in the project budget.
It is impossible to recruit staff with the skills High Catastrophic
The Risk Management Process required for the project.
• Risk identification : identify project, product and business Key staff are ill at critical times in the project. Moderate Serious
Software components which should be reused Moderate Serious
risks contain defects which limit their functionality.
Changes to requirements which require major Moderate Serious
• Risk analysis : assess the likelihood and consequences of design rework are proposed.
these risks The organisation is restructured so that different High Serious
management are responsible for the project.
• Risk planning : draw up plans to avoid or minimise the The database used in the system cannot process Moderate Serious
as many transactions per second as expected.
effects of the risk The time required to develop the software is High Serious
• Risk monitoring : monitor the risks throughout the project underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
Risk Risk analysis Riskplanning Risk The rate of defect repair is underestimated. Moderate Tolerable
identification monitoring The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant

List of potential Risk avoidance Risk

Prioritisedrisk
risks list
and contingency assessment Risk Planning
plans
Consider each risk and develop a strategy to manage that risk.
Avoidance strategies : the probability that the risk will arise is
Risk Identification reduced.
• Technology risks Minimisation strategies : the impact of the risk on the project or
product is reduced.
• People risks
• Organisational risks
Contingency plans : if the risk arises, contingency plans are plans
to deal with that risk.
• Requirements risks
• Estimation risks
(Taxonomy based on Source)

16
Risk Management Strategies Activitiy

SOFTWARE ENGINEERING
Explain why the intangibility of software systems poses special
Risk
Organisational
Strategy
Prepare a briefing document for senior management showing how the project is problems for software project management.
financial problems making a very important contribution to the goals of the business.
Recruitment Alert customer of potential difficulties and the possibility of delays, investigate
problems buying-in components.
Staff illness Reorganise team so that there is more overlap of work and people therefore
understand each other’s jobs.
Defective Replace potentially defective components with bought-in components of known
components reliability.
Requirements Derive traceability information to assess requirements change impact, maximise
changes information hiding in the design.
Organisational Prepare a briefing document for senior management showing how the project is
restructuring making a very important contribution to the goals of the business.
Database Investigate the possibility of buying a higher-performance database.
performance
Underestimated Investigate buying in components, investigate use of a program generator.
development time

Risk Monitoring
• Assess each identified risk regularly to decide whether or not
it is becoming less or more probable.
• Also assess whether the effects of the risk have changed.
• Each key risk should be discussed at management progress
meetings.
Risk Factors
Risk Strategy
Organisational Prepare a briefing document for senior management showing how the project is
financial problems making a very important contribution to the goals of the business.
Recruitment Alert customer of potential difficulties and the possibility of delays, investigate
problems buying-in components.
Staff illness Reorganise team so that there is more overlap of work and people therefore
understand each other’s jobs.
Defective Replace potentially defective components with bought-in components of known
components reliability.
Requirements Derive traceability information to assess requirements change impact, maximise
changes information hiding in the design.
Organisational Prepare a briefing document for senior management showing how the project is
restructuring
Database
making a very important contribution to the goals of the business.
Investigate the possibility of buying a higher-performance database.
Activitiy
performance
Underestimated Investigate buying in components, investigate use of a program generator.
Explain why the best programmers do not always make the
development time best software managers.

Key Points
• Good project management is essential for project success.
• The intangible nature of software causes problems for
management.
• Managers have diverse roles, but their most significant
activities are planning, estimating, and scheduling.
• Planning and estimating are iterative processes, which
continue throughout the course of a project.
• A project milestone is a predictable state where
some formal report of progress is presented to
management.
• Risks may be project risks, product risks or business risks.
• Risk management is concerned with identifying risks, which
may affect the project, and planning to ensure that these risks
do not develop into major threats.

17
 Activity Activity
SOFTWARE ENGINEERING

Explain why the process of project planning is an iterative one What is the critical distinction between a milestone and a
and why a plan; must be continually reviewed during a software deliverable?
project.

Activity
Following figure sets out a number of activities, durations and
dependencies. Draw an activity chart and a bar chart showing the
project schedule.

Task Duration Dependencies

T1 10
T2 15 T1
Activity T3 10 T1, T2
Briefly explain the purpose of each of the sections in a software
T4 20
T5 10
project plan.
T6 15 T3, T4
T7 20 T3
T8 35 T7
T9 15 T6
T10 5 T5, T9
T11 10 T9
T12 20 T10
T13 35 T3, T4
T14 10 T8, T9
T15 20 T12, T14
T16 10 T15

18
Activity Notes:

SOFTWARE ENGINEERING
You are asked by your manager to deliver software to a sched-
ule, which you know can only be met, by asking your project
team to work unpaid overtime. All team members have young
children. Discuss whether you should accept this demand form
your manager or whether you should persuade your team to
give their time to the organization rather than their families.
What factors might be significant in your decision?

Activity
As a programmer, you are offered promotion to project
management but you feel that you can make a more effective
contribution in a technical rather than a managerial role. Discuss
whether you should accept the promotion.

19
 UNIT I
OVERVIEW AND REQUIREMENTS
LESSON 6 AND 7:
SOFTWARE REQUIREMENTS CHAPTER 4

Objectives May be the basis for the contract itself — must be defined in
SOFTWARE ENGINEERING

• To introduce the concepts of abstract “user” and more detail

detailed “system” requirements May be the basis for design and implementation – must bridge
• To describe functional and non-functional requirements requirements engineering and design activities
• To explain two techniques for describing system • User requirements : statements in natural language plus
requirements: structured NL and PDLs diagrams of system services and constraints. Written
primarily for customers.
• To suggest how software requirements may be organized in
a requirements document • System requirements : structured document setting out
detailed descriptions of services and constraints precisely.
Topics Covered May serve as a contract between client and developer.
• Functional and non-functional requirements • Software design specification : implementation oriented
• User requirements abstract description of software design, which may utilize
• System requirements formal (mathematical) notations. Written for developers.
• The software requirements document User and System Requirements
Requirements Engineering 1. The software must provice a means of representing and
• The process of eliciting, analysing, documenting, and accessing external files created by other tools.
validating the services required of a system and the
constraints under which it will operate and be developed. 1. The user should be provided with facilities to define the
• Descriptions of these services and constraints are the type of external files.
requirements for the system. 2. Each external file type may have an associated tool which
• Requirements may be high-level and abstract, or detailed and may be applied to the file.
mathematical 3. Each external file type may be represented as a specific
• The hardest single part of building a software system is icon on the user’s display.
deciding precisely what to build. No other part of the 4. Facilities should be provided for the icon representing an
conceptual work is as difficult… No other part of the work external file type to be defined by the user.
so cripples the resulting system if done wrong. No other 5. When a user selects an icon representing an external file
part is more difficult to rectify later. the effect of that selection is to apply the tool associated
– Fred Brooks, “No Silver Bullet…” with the type of the external file to the file represented by
Why is Requirements Engineering So Hard? the selected icon.
• Difficulty of anticipation
• Unknown or conflicting requirements / priorities Requirements Readers
• Conflicts between users and procurers
• Fragmented nature of requirements Client managers
System end-users
• Complexity / number of distinct requirements User requirements Client engineers
• Some analogies: Contractor managers
System architects
Working a dynamically changing jigsaw puzzle
Blind men describing an elephant
System end-users
Different medical specialists describing an ill patient
Client engineers
System requirements
Types of Requirements System architects
• Requirements range from being high-level and abstract to
Software developers
detailed and mathematical.
• This is inevitable as requirements may serve multiple uses.
May be the basis for a bid for a contract – must be open to
interpretation

20
Functional and Non-functional Requirements Requirements Completeness and Consistency

SOFTWARE ENGINEERING
• Functional requirements : services the system should • In principle, a requirements specification should be both
provide, how it should react to particular inputs, or how it complete and consistent.
should behave in particular situations. Complete : all required services and constraints are defined.
• Non-functional requirements : constraints on services or Consistent : no conflicts or contradictions in the requirements.
functions (e.g., response time) or constraints on
• In practice, this is nearly impossible.
development process (e.g., use of a particular CASE toolset).
• Domain requirements : functional or non-functional Non-functional Requirements
requirements derived from application domain (e.g., legal • Define system attributes (e.g., reliability, response time) and
requirements or physical laws constraints (e.g., MTTF e•5K transactions, response time d•2
seconds).
Examples of Functional Requirements
• Attributes are often emergent system properties : i.e., only
• The user shall be able to search either all of the initial set of
observable when the entire system is operational.
databases or select a subset from it.
• Process constraints may mandate a particular CASE system,
• The system shall provide appropriate viewers for the user to
programming language, or development method.
read documents in the document store.
• Non-functional requirements may be more critical than
• Every order shall be allocated a unique identifier
functional requirements. If not met, the system may be
(ORDER_ID), which the user shall be able to copy to the
useless.
account’s permanent storage area
Non-functional Classifications
Requirements Imprecision
• Product requirements : specify product behaviour
• Problems arise when requirements are not precisely stated.
• Organizational requirements : derived from policies /
• Ambiguous requirements may be interpreted in different
procedures in customer’s or developer’s organization (e.g.,
ways.
process constraints)
• Consider the term “appropriate viewers”
• External requirements : derived from factors external to the
User intention : special purpose viewer for each different product and its development process (e.g., interoperability
document type requirements, legislative requirements)
Developer interpretation : provide a text viewer that shows the
Non-functional Classifications
contents of the documents

No n-fu nctio nal

requ ir ements

Pro du ct Or ganizatio nal Extern al

requ ir ements requ ir ements requirements

Ef ficiency Reliab ility Po rtability Interoperab ility Ethical

requir ements requ ir ements requirements requirements requirements

Usab ility Delivery Implementation Stand ards Legislative

requ irements requirements requ ir ements requirements requirements

Performance Space Privacy Safety

requ irements requ ir ement s requirements requirements

21
 Examples • For this reason, preferred points in the solution space
SOFTWARE ENGINEERING

• Product requirement: 4.C.8 it shall be possible for all should be identified.

necessary communication between the APSE and the user to Domain Requirements
be expressed in the standard Ada character set.
• Derived from the application domain rather than user needs.
• Organisational requirement: 9.3.2 the system development
• May be new functional requirements or constraints on
process and deliverable documents shall conform to the
existing requirements.
process and deliverables defined in XYZCo-SP-STAN-95.
• If domain requirements are not satisfied, the system may be
• External requirement: 7.6.5 the system shall not disclose any
unworkable.
personal information about customers apart from their
name and reference number to the operators of the system. Library System Domain Requirements
• There shall be a standard user interface to all databases, which
Goals Versus Requirements
shall be based on the Z39.50 standard.
• General goals such as “system should be user friendly” or
• Because of copyright restrictions, some documents must be
“system should have fast response time” are not verifiable.
deleted immediately on arrival. Depending on the user’s
• Goals should be translated into quantitative requirements
requirements, these documents will either be printed locally
that can be objectively tested.
on the system server for manually forwarding to the user or
Examples routed to a network printer.
• A system goal: The system should be easy to use by Train Protection System Domain Requirement
experienced controllers and should be organized in such a
• The deceleration of the train shall be computed as:
way that user errors are minimized.
Dtrain = Dcontrol + Dgradient
• A verifiable non-functional requirement: Experienced
controllers shall be able to use all the system functions after a where Dgradient is 9.81m/s2 * compensated gradient/alpha
total of two hours training. After this training, the average and where the values of 9.81m/s2 /alpha are known for
number of errors made by experienced users shall not exceed different types of train.
two per day. Domain Requirements Problems
Requirements Measures • Understandability : requirements are expressed in the
language of the application domain and may not be
understood by software engineers.
Property Measure
Speed Processed transactions/second • Implicitness : domain experts may not communicate such
User/Event response time requirements because they are so obvious (to the experts).
Screen refresh time
Size K Bytes User Requirements “Shoulds”
Number of RAM chips • Should be understandable by system users who don’t have
Ease of use Training time detailed technical knowledge.
Number of help frames
Reliability Mean time to failure • Should only specify external system behaviour.
Probability of unavailability • Should be written using natural language, forms, and simple
Rate of failure occurrence
Availability intuitive diagrams.
Robustness Time to restart after failure Some Potential Problems With Using Natural
Percentage of events causing failure
Language
Probability of data corruption on failure
Portability Percentage of target dependent statements • Lack of clarity : expressing requirements precisely is difficult
Number of target systems without making the document wordy and difficult to read.
• Requirements confusion : functions, constraints, goals, and

Requirement Interactions design info may not be clearly distinguished.

• Requirements amalgamation : several different requirements
• Competing / conflicting requirements are common with
complex systems. may be lumped together.

• Spacecraft system example: Guidelines For Writing User Requirements

To minimize weight, the number of chips in the unit should • Adopt a standard format and use it for all requirements.
be minimized. • Use language in a consistent way. E.g., use shall for
To minimize power consumption, low-power chips should be mandatory requirements, should for desirable requirements.
used. • Use text highlighting to identify key parts of the
But using low-power chips means that more chips have to be requirement.
used. Which is the most critical requirement? • Avoid the use of computer jargon.

22
System Requirements Part of an ATM Specification

SOFTWARE ENGINEERING
• More detailed descriptions of user requirements
• May serve as the basis for a contract class ATM {
// declarations here
• Starting point for system design & implementation public static void main (String args[]) throws InvalidCard {
try {
• May utilize different system models such as object or thisCard.read () ; // may throw InvalidCard exception
dataflow pin = KeyPad.readPin () ; attempts = 1 ;
while ( !thisCard.pin.equals (pin) & attempts < 4 )
{ pin = KeyPad.readPin () ; attempts = attempts + 1 ;
System Requirements And Design Information }
if (!thisCard.pin.equals (pin))
• In principle, system requirements should state what the throw new InvalidCard ("Bad PIN");
system should do, and not how it should be designed. thisBalance = thisCard.getBalance () ;
do { Screen.prompt (" Please select a service ") ;
• In practice, however, some design info may be incorporated, service = Screen.touchKey () ;
switch (service) {
since: case Services.withdrawalWithReceipt:
receiptRequired = true ;
Sub-systems may be defined to help structure the requirements.
Interoperability requirements may constrain the design.
PDL Disadvantages
Use of a specific design model may be a requirement
• PDL may not be sufficiently expressive to illustrate
More Potential Problems With Using Natural requirements in a concise an understandable way.
Language
• Notation is only understandable to people with
• Ambiguity : the readers and writers of a requirement must programming language knowledge.
interpret the same words in the same way. NL is naturally
• The specification may be taken as a design prescription rather
ambiguous so this is very difficult.
than a model to facilitate requirements understanding.
• Over-flexibility : the same requirement may be stated in a
number of different ways. The reader must determine when Interface Specification
requirements are the same and when they are different. • Used to specify operating interfaces with other systems.
• Lacks of modularisation : NL structures are inadequate to Procedural interfaces
structure system requirements sufficiently. Data structures that are exchanged
Alternatives to NL Specification Data representations
• Also used to specify functional behaviour.
Notation Description • Formal notations are effective for interface specification – e.g.,
Structured This approach depends on defining standard forms or
natural templates to express the requirements specification. pre- and post-conditions
language
Design This approach uses a language like a programming PDL Interface Description
description language but with more abstract features to specify the
languages requirements by defining an operational model of the Example: Interface and Operational Specifications of a
system.
Graphical A graphical language, supplemented by text annotations is
Function
notations used to define the functional requirements for the system.
An early example of such a graphical language was SADT interface PrintServer {
(Ross, 1977; Schoman and Ross, 1977). More recently,
use-case descriptions (Jacobsen, Christerson et al., 1993) // defines an abstract printer server
have been used. I discuss these in the following chapter. // requires: interface Printer, interface PrintDoc
Mathematical These are notations based on mathematical concepts // provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter
specifications such as finite-state machines or sets. These unambiguous
specifications reduce the arguments between customer void initialize ( Printer p ) ;
and contractor about system functionality. However, most
void print ( Printer p, PrintDoc d ) ;
customers don’t understand formal specifications and are
void displayPrintQueue ( Printer p ) ;
reluctant to accept it as a system contract. I discuss formal
void cancelPrintJob (Printer p, PrintDoc d) ;
specification in Chapter 9.
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer

Program Description Languages (PDLs) Function: Set BIG to the largest value in array A [1.. N]
• Requirements are specified operationally using pseudo-code.
Interface Specification
• Shows what is required by illustrating how the requirements Pre-condition: N > 1
could be satisfied. Post-condition: there exists an i in [1,N] such that BIG=A [i]
• Especially useful when specifying a process that involves an & for every in [1,N], BIG > A [j] & A is unchanged
ordered sequence of actions, or when describing hardware
and software interfaces.

23
 • This is a generic structure that must be instantiated for
SOFTWARE ENGINEERING
Operational Specification
if N e•1 then do specific systems
BIG: = A [1]
Requirements Document Structure
for i = 2 to N do
• Preface (readers, version, change history)
if A [i] > BIG then BIG: = A [i] end if
end for • Introduction
end if • Glossary
The Requirements Document (SRS) • User requirements definition
• The official statement of what is required of the system • System requirements specification
developers. • System models
• Should include both user and system requirements. • System evolution
• NOT a design document. As much as possible, it should set • Appendices
out WHAT the system should do rather than HOW it
• Index
should do it.
Key Points
Users of a Requirements Document
• Requirements set out what the system should do and define
constraints on its operation and implementation.
S pe c i f y t he r e q uir e m e n ts a nd • Functional requirements set out services the system should
r e a d th e m to c h e c k t ha t t he y provide
S y st e m c us to m e r s m e e t th e ir n e e ds . T h e y
s pe c if y c h a ng e s t o th e • Non-functional requirements constrain the system being
r e qu ir e m e n ts developed or the development process
• User requirements are high-level statements of what the
U s e t he r e q ui r e m e nt s
d o c um e n t to pl a n a bi d f or system should do
M a na g e r s
t he s ys te m a n d to pl a n th e
sy st e m de v e lo pm e n t p r oc e s s
• User requirements should be written in natural language,
tables and diagrams.
U s e t he r e q ui r e m e nt s to
• System requirements are intended to communicate the
S y st e m e ng in e e r s un de r s ta n d w h a t s ys te m i s to functions that the system should provide.
b e de v e lo p e d
• System requirements may be written in structured natural
language, a PDL or in a formal language.
S y st e m te s t U s e t he r e q u i r e m e nt s to
e ng in e e r s d ev e lo p va l id a ti on te s ts f o r • A software requirements document (SRS) is the agreed
t he s ys te m statement of system requirements
Activity
S y st e m U s e t he r e q u i r e m e nt s to he l p
m a in te n a nc e u nd er s ta n d th e sy st e m a n d Discuss the problems of using natural language for defining
e ng in e e r s t he r e l a ti on sh ip s b e tw e e n it s user and system requirements and show, using small examples,
p ar t s
how structuring natural language into forms can help avoid
some of these difficulties.

Requirements Document Requirements

• Specify external system behaviour
• Specify implementation constraints
• Easy to change (!)
• Serve as reference tool for maintenance
• Record forethought about the life cycle of the system i.e.
predict changes
• Characterise responses to unexpected events

IEEE Requirements Standard

• Introduction
• General description
• Specific requirements
• Appendices
• Index

24
Activity Activity

SOFTWARE ENGINEERING
Discuss ambiguities or omissions in the following statements Write system requirements for the above system using a Java
of requirements for part of a ticket issuing system. based notation. You may make any reasonable assumptions
An automated ticket issuing system sells rail tickets. Users select about the system. Pay particular attention to specifying user
their destination, and input a credit card and a personal errors.
identification number. The rail ticket is issued and their credit
card account charged with its cost. When the user presses the
start button, a menu display of potential destinations is
activated along with a message to the user to select a destina-
tion. Once a destination has been selected, users are requested to
input their credit card. Its validity is checked and the user is then
requested to input a personal identifier. When the credit
transaction has been validated, the ticket is issued.

Activity
Using the technique suggested here where natural language is
presented in a standard way, write plausible user requirements
for the following functions:
• An unattended petrol (gas) pump system that includes a
credit card reader. The customer swipes the card through the
reader then specifies the amount of fuel required. The fuel is
Activity
delivered and the customer’s account debited.
Rewrite the above description using the structured approach
• The cash dispensing functioning a bank auto teller machine.
described in this chapter. Resolve the identified ambiguities in
some appropriate way. • The spell checking and correcting functioning a word
processor.

25
 Activity Activity
SOFTWARE ENGINEERING

Describe three different types of non-functional requirement, You have taken a job with a software user who has contracted
which may be placed on a system. Give examples of each of your previous employer to develop a system for them. You
these types of requirement. discover that your compan7y’s interpretation of the require-
ments is different form the interpretation taken by your
previous employer. Discuss what you should do in such a
situation. You know that the costs to your current employer
will increases in the ambiguities are not resolved. You have also
a responsibility of confidentiality to your previous employer.

Activity
Write a set of non-functional requirements for the ticket issuing
system described above, setting out its expected reliability and
its response time.

26
 UNIT I
OVERVIEW AND REQUIREMENTS
LESSON 8 AND 9:
REQUIREMENTS ENGINEERING CHAPTER 5
PROCESS

Objectives Elicitation and Analysis

SOFTWARE ENGINEERING
• To describe the principal requirements engineering activities • Involves working with customers to learn about the
• To introduce techniques for requirements elicitation and application domain, the services needed and the system’s
analysis operational constraints.
• To describe requirements validation • May also involve end-users, managers, maintenance
personnel, domain experts, trade unions, etc. (That is, any
• To discuss the role of requirements management in support
stakeholders.)
of other requirements engineering processes
Problems of Elicitation and Analysis
Topics Covered
• Getting all, and only, the right people involved.
• Feasibility studies
• Stakeholders often don’t know what they really want (“I’ll
• Requirements elicitation and analysis
know when I see it”).
• Requirements validation
• Stakeholders express requirements in their own terms.
• Requirements management
• Stakeholders may have conflicting requirements.
Requirements Engineering Processes • Requirements change during the analysis process. New
• The processes used for RE vary widely depending on the stakeholders may emerge and the business environment may
application domain, the people involved and the evolve.
organization developing the requirements. • Organizational and political factors may influence the system
• However, there are a number of generic activities common to requirements.
most processes:
The Elicitation and Analysis Process
Feasibility study
Requirements elicitation and analysis
Requirements specification
Requirements validation
Feasibility Study
• Determines whether or not the proposed undertaking is
worthwhile.
• Aims to answer three basic questions:
Would the system contribute to overall organizational objec-
tives?
Could the system be engineered using current technology and
within budget?
Could the system be integrated with other systems already in
Viewpoint-oriented Elicitation
use?
• Stakeholders represent different ways of looking at a
Feasibility Study Issues problem (viewpoints)
• How would the organization cope if the system weren’t
• A multi-perspective analysis is important, as there is no
implemented? single correct way to analyse system requirements.
• What are the current process problems and how would the
• Provides a natural way to structure the elicitation process.
system help with these?
• What will the integration problems be?
Types of Viewpoints
• Data sources or sinks : viewpoints are responsible for
• Is new technology needed? New skills?
producing or consuming data. Analysis involves checking
• What must be supported by the system, and what need not
that assumptions about sources and sinks are valid.
be supported?
• Representation frameworks : viewpoints represented by
different system models (i.e., dataflow, ER, finite state

27
 machine, etc.). Each model yields different insights into the • Examples include:
SOFTWARE ENGINEERING

system. Ross’ Structured Analysis (SA),

• Receivers of services : viewpoints are external to the system Volere Requirements Process (www.volere.co.uk)
and receive services from it. Natural to think of end-users as
Knowledge Acquisition and Sharing for Requirement Engineer-
external service receivers.
ing (KARE) (www.kare.org),
Method-based RE Somerville’s Viewpoint-Oriented Requirements Definition
• “Structured methods” to elicit, analyse, and document (VORD), and
requirements. The baut’s Scenario-Based Requirements Engineering (SBRE)

Volere Requirements Process

Volere Requirement Shell

28
 SOFTWARE ENGINEERING
KARE Workbench Architecture

Somerville’s VORD Method

VORD Standard Forms

29
 Scenarios SBRE Scenario Generation
SOFTWARE ENGINEERING

• Depict examples or scripts of possible system behaviour.

• People often relate to these more readily than to abstract
statements of requirements.
• Particularly useful in dealing with fragmentary, incomplete, or
conflicting requirements.
Scenario Descriptions
• System state at the beginning of the scenario.
• Sequence of events for a specific case of some generic task the
system is required to accomplish.
• Any relevant concurrent activities.
• System state at the completion of the scenario.

A Simple Scenario
• t0: The user enters values for input array A. The values are
[1, 23, -4, 7, 19]. The value of output variable BIG remains
‘undefined’. Scenario Representation in VORD
• t1: The user executes program MAX. • VORD supports the graphical description of multi-threaded
“event scenarios” to document system behaviour:
• t2: The value of variable BIG is 23 and the values of A are
[1, 23, -4, 7, 19]. Data provided and delivered
Control information
Scenario-Based Requirements Engineering (SBRE)
Exception processing
• Marcel support environment allows rapid construction of an
operational specification of the desired system and its The next expected event
environment. • Multi-threading supports description of exceptions.
• Based on a forward chaining rule-based language. Scenario for a “Start Transaction” Event
• An interpreter executes the specification to produce natural
language based scenarios of system behavior.
SBRE Rule Template

UML Use-cases and Sequence Diagrams

• Use-cases are a graphical notation for representing abstract
scenarios in the UML.
• They identify the actors in an interaction and describe the
interaction itself.
• A set of use-cases should describe all types of interactions
with the system.
• Sequence diagrams may be used to add detail to use-cases by
showing the sequence of event processing.

30
Library Use-cases incomplete information so that the system will fail.

SOFTWARE ENGINEERING
Ethnography
• A social scientists spends considerable time observing and
analysing how people actually work.
• People do not have to explain or articulate what they do.
• Social and organizational factors of importance may be
observed.
• Ethnographic studies have shown that work is usually richer
and more complex than suggested by simple system models.
Focused Ethnography
• Developed during a project studying the air traffic control
process.
• Combines ethnography with prototyping.
• Prototype development raises issues: which focus the
ethnographic analysis.
• Problem with ethnography alone: it studies existing practices,
which may not be relevant when a new system is put into
place.
Catalogue Management Sequence Diagram Requirements Validation
• Concerned with whether or not the requirements define a
system that the customer really wants.
• Requirements error costs are high, so validation is very
important. (Fixing a requirements error after delivery may
cost up to 100 times that of fixing an error during
implementation.)
Requirements Checking
• Validity: Does the system provide the functions which best
support the customer’s needs?
• Consistency: Are there any requirements conflicts?
• Completeness: Are all functions required by the customer
included?
• Realism: Can the requirements be implemented given
available budget and technology?
• Verifiability: Can the requirements be tested?
Requirements Validation Techniques
Social and Organizational Factors • Requirements reviews / inspections : systematic manual
• All software systems are used in a social and organizational analysis of the requirements.
context. This can influence or even dominate the system • Prototyping : using an executable model of the system to
requirements. check requirements.
• Good analysts must be sensitive to these factors, but there is • Test-case generation : developing tests for requirements to
currently no systematic way to tackle their analysis. check testability.
Example • Automated consistency analysis : checking the consistency of
• Consider a system: which allows senior management to a structured requirements description.
access information without going through middle managers. Requirements Reviews / Inspections
• Managerial status: Senior managers may feel that they are too • Regular reviews should be held while the requirements
important to use a keyboard. This may limit the type of definition is being formulated.
system interface used.
• Both client and contractor staff should be involved in
• Managerial responsibilities: Managers may have no reviews. (Stakeholders)
uninterrupted time when they can learn to use the system
• Reviews may be formal (with completed documents) or
• Organizational resistance: Middle managers who will be informal. Good communications between developers,
made redundant may deliberately provide misleading or customers and users can resolve problems at an early stage.

31
 Review Check-list • Source traceability : links from requirements to stakeholders
SOFTWARE ENGINEERING

• Verifiability: Is the requirement realistically testable? who proposed these requirements.

• Comprehensibility: Is the requirement properly understood? • Requirements traceability : links between dependent
requirements.
• Traceability: Is the origin of the requirement clearly stated?
• Design traceability : links from the requirements to the
• Adaptability: Can the requirement be changed with
design.
minimum impact on other requirements? (Especially when
change is anticipated!) CASE Tool Support
Requirements Management • Requirements storage : requirements should be managed in a
secure, managed data store.
• Requirements management is the process of managing
changing requirements during the requirements engineering • Change management : the process of change management is
process and system development. a workflow process whose stages can be defined and
information flow between the stages partially automated.
• New requirements emerge during the process as business
needs change and a better understanding of the system is • Traceability management : automated discovery and
developed. documentation of relationships between requirements
• The priority of requirements from different viewpoints Requirements Change Management
changes during the development process. • Should apply to all proposed changes to the requirements.
• The business and technical environment of the system • Principal stages:
changes during its development.
Problem analysis : discuss identified requirements problem and
Enduring and Volatile Requirements propose specific change(s).
• Enduring requirements: Stable requirements derived from Change analysis and costing : assess effects of change on other
the core activity of the customer organization. E.g., a requirements.
hospital will always have doctors, nurses, etc. May be derived Change implementation : modify requirements document and
from domain models. others to reflect change.
• Volatile requirements: Requirements which change during Requirements Change Management
development or when the system is in use. E.g.,
requirements derived from the latest health-care policy.
Classification of Requirements
• Mutable requirements : those that change due to changes in
the system’s environment.
• Emergent requirements : those that emerge as understanding
of the system develops. Key Points
• Consequential requirements : those that result from the • The requirements engineering process includes a feasibility
introduction of the system. study, elicitation and analysis, specification, and validation.
• Compatibility requirements : those that depend on other • Requirements analysis is an iterative process involving
systems or organizational processes. domain understanding, requirements collection,
classification, structuring, prioritization and validation.
Requirements Management Planning
• Systems have multiple stakeholders with different
• During requirements management planning, you must viewpoints and requirements.
decide on:
• Social and organization factors influence system
• Requirements identification : how requirements will be requirements.
individually identified.
• Requirements validation is concerned with checks for validity,
• A change management process : a process to be followed consistency, complete-ness, realism, and verifiability.
when analysing the impact and costs of a requirements
• Business, organizational, and technical changes inevitably
change.
lead to changing requirements.
• Traceability policies : the amount of information about
• Requirements management involves careful planning and a
requirements relationships that is maintained.
change management process.
• CASE tool support : the tool support required to help
manage requirements change.
Traceability
• Traceability is concerned with the relationships between
requirements, their sources, and the system design.

32
Activity

SOFTWARE ENGINEERING
Suggest who might be stakeholders in a university student Activity
records system. Explain why it is almost inevitable that the
For three of the viewpoints identified in the library cataloguing
requirements of different stakeholders will conflict in some
system, suggest services which might be provided to that
ways.
viewpoint, data which the viewpoint might provide and events
which control the delivery of these services.

Activity
A software system is to be developed to automate a library
catalogue. This system will contain information about all the Activity
books in a library and will be usable by library staff and by book
Using your own knowledge of how an ATM is used, develop a
borrows and reasons the system should support catalogue
set of use cases that could be used to derive the requirements
browsing, querying, and should provide facilities allowing users
for an ATM system.
to send messages to library staff reserving a book which is on
loan. Identify the principal viewpoints, which might be taken
into account in the specification of this system and show their
relationships using a viewpoint hierarchy diagram.

33
 Activity Activity
SOFTWARE ENGINEERING

Discuss an example of a type of system where social and Why do tractability matrices become difficult to mange when
political factors might strongly influence the system require- there are many system requirements? Design a requirements
ments. Explain why these factors are important in your structuring mechanism, based on viewpoints, which might help
example. reduce the scale of this problem.

Activity
When emergency changes have to be made to system software
Activity may have to be modified before changes to the requirements
have been approved. Suggest a model of a process for making
Who should be involved in a requirements review? Draw a
these modifications, which ensures that the requirements
process model showing how a requirements review might be
document and the system implementation do not become
organized.
inconsistent.

34
Activity

SOFTWARE ENGINEERING
Your company uses a standard analysis method which is
normally applied in all requirements analyses. In your work, you
find that this method cannot represent social factors, which are
significant in the system you are analyzing. You point out to
your manager who makes clear that the standard should be
followed. Discuss what you should do in such a situations.

Notes:

35
 UNIT I
OVERVIEW AND REQUIREMENTS
LESSON 10 AND 11: UNIT 3
SYSTEM MODELS CHAPTER 6

Abstract Descriptions of Systems Whose Model Types

SOFTWARE ENGINEERING

Requirements are Being Analysed • Data processing model showing how the data is processed at
Objectives different stages
• To explain why the context of a system should be modelled • Composition model showing how entities are composed of
as part of the RE process other entities
• To describe behavioural modelling, data modelling and • Architectural model showing principal sub-systems
object modelling • Classification model showing how entities have common
• To introduce some of the notations used in the Unified characteristics
Modelling Language (UML) • Stimulus/response model showing the system’s reaction to
• To show how CASE workbenches support system events
modelling Context Models
Topics Covered • Context models are used to illustrate the boundaries of a
• Context models system
• Behavioural models • Social and organisational concerns may affect the decision on
where to position system boundaries
• Data models
• Architectural models show the a system and its relationship
• Object models
with other systems
• CASE workbenches
The Context of An ATM System
System Modelling
• System modelling helps the analyst to understand the
Security
functionality of the system and models are used to system
communicate with customers
Branch
• Different models present the system from different Account
accounting
perspectives database
system
External perspective showing the system’s context or environ- Auto-teller
ment system
Behavioural perspective showing the behaviour of the system Branch
Usage
Structural perspective showing the system or data architecture counter
database
system
Structured Methods Maintenance
• Structured methods incorporate system modelling as an system
inherent part of the method
• Methods define a set of models, a process for deriving these
models and rules and guidelines that should apply to the Process Models
models
• Process models show the overall process and the processes
• CASE tools support system modelling as part of a that are supported by the system
structured method
• Data flow models may be used to show the processes and
Method Weaknesses the flow of information from one process to another
• They do not model non-functional system requirements
• They do not usually include information about whether a
method is appropriate for a given problem
• The may produce too much documentation
• The system models are sometimes too detailed and difficult
for users to understand

36
Equipment Procurement Process • Data flow diagrams may also be used in showing the data

SOFTWARE ENGINEERING
exchange between a system and other systems in its
Delivery environment
note

Equipment Checked Delivery

note
CASE Toolset DFD
Specify spec. spec. Accept Check
Validate Get cost
equipment specification delivery of delivered Input Valid Ch eck ed Desig n User
estimates
requir ed equipment items
d esig n des ign desig n analys is report
Spec. +
supplier + Design Des ign Desig n Repo rt
Order Installation
Equipment estimate instructions
edito r cro ss checker analy ser gen erator
spec. Supplier list notification and
Supplier Find Choose
Place
Install
Referenced Checked
equipment
database suppliers supplier equipment desig ns des ign Out put
Order order
details + Desig n Code skelet on cod e Desig n
Blank order Installation
acceptance datab ase generator database
form

Accept
delivered
Checked and
signed order form
equipment State Machine Models
Equipment
details
• These model the behaviour of the system in response to
Equipment
external and internal events
database
• They show the system’s responses to stimuli so are often
used for modelling real-time systems
• State machine models show system states as nodes and
Behavioural Models
events as arcs between these nodes. When an event occurs,
• Behavioural models are used to describe the overall the system moves from one state to another
behaviour of a system
• State charts are an integral part of the UML
• Two types of behavioural model are shown here
Microwave Oven Model
Data-processing models that show how data is processed as it
moves through the system
Full
power Full power
State machine models that show the systems response to events do: set power
= 600
• Both of these models are required for a description of the
system’s behaviour Waiting
Timer
Number
do: display
Data-processing Models time Full
power
Set time Operation
do: operate
do: get number
exit: set time oven
• Data flow diagrams are used to model the system’s data Half
Half power
processing power
Timer
Door
closed Cancel
Door Start
• These show the processing steps as data flows through a open Door
Half power Waiting
system do: set power Door
Enabled
do: display
open
do: display
= 300 closed 'Ready' time
• Intrinsic part of many analysis methods
• Simple and intuitive notation that customers can understand Disabled
do: display
• Show end-to-end processing of data 'Waiting'

Order Processing DFD

Microwave Oven State Description

Checked and State Description

Completed Signed Signed Send to signed order
order form order form order form supplier + order Waiting The oven is waiting for input. The display shows the current time.
Order
details + Complete Validate Record
notification Half power The oven power is set to 300 watts. The display shows ‘Half
blank order form order order power’.
order form Adjust Full power The oven power is set to 600 watts. The display shows ‘Full
Order available power’.
Signed budget
details order form Set time The cooking time is set to the user’s input value. The display
Order shows the cooking time selected and is updated as the time is set.
amount Disabled Oven operation is disabled for safety. Interior oven light is on.
+ account Display shows ‘Not ready’.
details
Enabled Oven operation is enabled. Interior oven light is off. Display
Orders Budget shows ‘Ready to cook’.
file file
Operation Oven in operation. Interior oven light is on. Display shows the
timer countdown. On completion of cooking, the buzzer is
sounded for 5 seconds. Oven light is on. Display shows ‘Cooking
complete’ while buzzer is sounding.
Data Flow Diagrams
• DFDs model the system from a functional perspective
• Tracking and documenting how the data associated with a
process is helpful to develop an overall understanding of the
system

37
 Microwave Oven Stimuli Software Design Semantic Model
SOFTWARE ENGINEERING

Des ig n
Stimulus Description n am e
1 1
Half power The user has pressed the half power button d es crip tion
C -d ate
Full power The user has pressed the full power button M -dat e
Timer The user has pressed one of the timer buttons
h as -no des i s-a h as -link s
Number The user has pressed a numeric key 1
Door open The oven door switch is not closed n n
Door closed The oven door switch is closed 1
Start The user has pressed the start button No de 1 h as -li nk s n Link
Cancel The user has pressed the cancel button n am e n am e
typ e t yp e
2 l in ks 1
1 1
State Charts
• Allow the decomposition of a model into sub-models (see h as -la b els h as -lab els
following slide) Lab el
n am e
• A brief description of the actions is included following the n
tex t
n
‘do’ in each state ico n

• Can be complemented by tables describing the states and the

stimuli
Data Dictionaries
Microwave Oven Operation • Data dictionaries are lists of all of the names used in the
system models. Descriptions of the entities, relationships
and attributes are also included
Operation
Time • Advantages
Checking Support name management and avoid duplication
OK Cook
do: check do: run Store of organisational knowledge linking analysis, design and
status generator implementation
• Many CASE workbenches support data dictionaries
Turntable Emitter Timeout
fault fault Data Dictionary Entries

Alarm Done
Name Description Type Date
do: buzzer on 1:N relation between entities of type
do: display for 5 secs.
event has-labels Node or Link and entities of type Relation 5.10.1998
Label.
Holds structured or unstructured
Label information about nodes or links. Entity 8.12.1998
Door Cancel
Labels are represented by an icon
open (which can be a transparent box) and
associated text.
Disabled Waiting A 1:1 relation between design
Link entities represented as nodes. Links Relation 8.12.1998
are typed and may be named.
Each label has a name which
name identifies the type of label. The na me Attribute 8.12.1998
Semantic Data Models (label) must be unique within the set of label
types used in a design.
• Used to describe the logical structure of data processed by Each node has a name which must be
the system name unique within a design. The name Attribute 15.11.1998
(node) may be up to 64 characters long.
• Entity-relation-attribute model sets out the entities in the
system, the relationships between these entities and the
entity attributes Object Models
• Widely used in database design. Can readily be implemented • Object models describe the system in terms of object classes
using relational databases
• An object class is an abstraction over a set of objects with
• No specific notation provided in the UML but objects and common attributes and the services (operations) provided
associations can be used
by each object
• Various object models may be produced
Inheritance models

38
Aggregation models User Class Hierarchy

SOFTWARE ENGINEERING
Interaction models
• Natural ways of reflecting the real-world entities manipulated Libr ary us er
Nam e
by the system Ad d ress
Ph on e
• More abstract entities are more difficult to model using this Regi st rat io n #

approach Regi st er ()
De-r egi st er ()
• Object class identification is recognised as a difficult process
requiring a deep understanding of the application domain
Reader Bo rro wer
• Object classes reflecting domain entities are reusable across Affil iatio n Item s o n l oan
M ax. lo ans
systems
Inheritance Models
• Organise the domain object classes into a hierarchy St aff St ud ent

• Classes at the top of the hierarchy reflect the common Dep artm en t M ajo r s ub ject
Dep artm en t ph on e Ho m e ad d ress
features of all classes
• Object classes inherit their attributes and services from one
or more super-classes. These may then be specialised as
Multiple Inheritance
necessary
• Rather than inheriting the attributes and services from a
• Class hierarchy design is a difficult process if duplication in single parent class, a system, which supports multiple
different branches is to be avoided
inheritance, allows object classes to inherit from several
The Unified Modelling Language super-classes
• Devised by the developers of widely used object-oriented • Can lead to semantic conflicts where attributes/services with
analysis and design methods the same name in different super-classes have different
• Has become an effective standard for object-oriented semantics
modelling • Makes class hierarchy reorganisation more complex
• Notation
Object classes are rectangles with the name at the top, attributes
in the middle section and operations in the bottom section Book Voice recording
Relationships between object classes (known as associations) are Author
shown as lines linking objects
Speaker
Edition Duration
Inheritance is referred to as generalisation and is shown Publication date Recording date
‘upwards’ rather than ‘downwards’ in a hierarchy
ISBN
Library Class Hierarchy

Library i tem

Catalog ue n u mber
Acq ui si ti on d ate
Co st
Ty pe
St at us
Nu mb er of co pi es
Talking book
Acq uire ()
Catal ogu e ()
Dis po se () # Tapes
Issu e ()
Return ()

Pu bl is hed item Record ed i tem

Ti tl e T i tl e
Pub li sh er M edium Object Aggregation
• Aggregation model shows how classes, which are collections,
are composed of other classes
Bo ok M ag azi ne Fi lm Co mpu ter
Au th or Directo r
p ro g ram • Similar to the part-of relationship in semantic data models
Year
Edition Iss u e Dat e of releas e Version
Publ icat io n d at e Dis tri buto r Pl at fo rm
ISBN

39
 Object Behaviour Modelling • Forms definition tools
SOFTWARE ENGINEERING

• A behavioural model shows the interactions between objects • Import/export translators

to produce some particular system behaviour that is specified • Code generation tools
as a use-case
Key Points
• Sequence diagrams (or collaboration diagrams) in the UML
are used to model interaction between objects • A model is an abstract system view. Complementary types of
model provide different system information
Issue of Electronic Items
• Context models show the position of a system in its
environment with other systems and processes
Ec at : : Lib ra ry Ite m Li b1 :
N et S er ve r
• Data flow models may be used to model the data processing
C a ta l og
in a system
: Lib ra ry Us e r • State machine models model the system’s behaviour in
response to internal or external events
Lo ok up
• Semantic data models describe the logical structure of data,
D i s pl ay which is imported to or exported by the systems
Iss u e • Object models describe logical system entities, their
Iss u e li c enc e
classification and aggregation
Ac c ep t li ce nce
• Object models describe the logical system entities and their
C o m pre ss classification and aggregation
• CASE workbenches support the development of system
De l iv e r
models
Activity
CASE Workbenches Draw a context model for a patient information system in a
• A coherent set of tools that is designed to support related hospital. You may make any reasonable assumptions about the
software process activities such as analysis, design or testing other hospital systems, which are available, but your model
• Analysis and design workbenches support system modelling must include a patient admissions system and an image storage
during both requirements engineering and system design system for X-rays.
• These workbenches may support a specific design method or
may provide support for a creating several different types of
system model
An Analysis and Design Workbench

Structured Report
Data
diagramming generation
dictionary
tools facilities

Central Query
Code
generator information language
repository facilities

Forms Design, analysis

and checking Import/export
creation
tools facilities
tools

Analysis Workbench Components

• Diagram editors
• Model analysis and checking tools
• Repository and associated query language
• Data dictionary
• Report definition and generation tools

40
Activity Activity

SOFTWARE ENGINEERING
Based on your experience with a bank ATM, draw a data-flow Draw state machine models of the control software for:
diagram modeling the data processing involved when a • An automatic washing machine, which has different
customer withdraws cash form the machine. programs for different types of clothes.
• The software for ac compact disc player.
• A telephone answering machine on an LED display. The
system should allow the telephone owner to dial in, type a
sequence of numbers (identified as tones) and have the
recorded messages replayed over the phone.

Activity
Model the data processing which might take place in an
electronic mail system. You should model the mail sending and
Activity
mail receiving processing separately.
Develop an object model including a class hierarchy diagram and
an aggregation diagram showing the principal components of a
personal computer system and its system software.

41
 Activity Notes -
SOFTWARE ENGINEERING

Develop a sequence diagram showing the interactions involved

when a student registers for a course in a university. Courses
may have a limited number of places so the registration process
must include checks that places are available. Assume that the
student accesses an electronic course catalogue to find out about
available courses.

Activity
Describe three modeling activities that may be supported by a
CASE workbench for some analysis method. Suggest three
activities that cannot be automated.

42
 UNIT I
OVERVIEW AND REQUIREMENTS
LESSSON 12 AND 13:
SOFTWARE PROTOTYPING CHAPTER 7

Objectives Throw-away prototyping : to elicit and validate requirements

SOFTWARE ENGINEERING
• To describe the use of prototypes in different types of Evolutionary prototyping : to deliver an acceptable, working
development projects system to end-users
• To discuss evolutionary and throw-away prototyping Experimental prototyping : to evaluate proposed solutions for
To introduce three rapid prototyping techniques: feasibility, performance, etc.
High-level language development, Simulation, Prototyping and Scenarios
Database programming, and • What are the differences between prototyping and
Component reuse simulation?
• To explain the need for user interface prototyping
Topics Covered
• Prototyping in the software process
• Rapid prototyping techniques
• User interface prototyping
What is Prototyping?
• Some traditional features:
An iterative process emphasizing
Rapid development,
Evaluative use, • What is the connection between simulation models /
prototypes, scenarios?
Feedback, and
Simulation models are automatic scenario generators.
Modification
Prototypes facilitate manual scenario generation.
Learning (based on feedback)
Consideration of alternatives Prototyping Benefits
Concreteness (a “real system” is developed and presented to real • Misunderstandings exposed.
users) • Difficult to use or confusing services identified
• Boundary between prototyping and normal system • Missing services detected
development blurs when an evolutionary (e.g., agile) • Incomplete and/or inconsistent requirements found by
development approach is used. analysts as prototype is being developed. Can demo
Uses of Prototypes feasibility and usefulness
• Principal use is to help customers and developers better • Basis for writing a system specification
understand system requirements. Prototyping Process
Experimentation stimulates anticipation of how a system could E s t ab l is h D e fi ne
D e v e lo p E v a lu a t e
be used. p ro to ty p e
o b j ec t iv e s
p ro to ty p e
f u n c ti o n a li ty
p ro to ty p e p ro to ty p e

Attempting to use functions together to accomplish some task

P ro to ty p i n g O u t li n e E x e c u t ab le E v a lu ati o n
can easily reveal requirements problems. p la n d ef i n i ti o n p ro to ty p e re po r t

• Other potential uses:

Evaluating proposed solutions for feasibility (Experimental Prototyping Outcomes
Prototyping) • Improved system usability
“Back-to-back” system testing • Closer match to the system needed
Training users before system delivery • Improved design quality (maybe…)
• Prototyping is most often undertaken as a risk reduction • Improved maintainability (maybe…)
activity.
• Reduced overall development effort (maybe…but corrective
Classifying Prototypes maintenance costs are usually reduced)
• By purpose:

43
 Prototyping in The Software Process Specialized developer skills required
SOFTWARE ENGINEERING

• Evolutionary prototyping : prototype is produced and • Maintenance problems : Continual change tends to corrupt
refined through a number of stages to become the final system structure so long-term maintenance is expensive.
system. • Contractual problems : No system requirements specification
• Throwaway prototyping : prototype is produced to help to serve as basis for contract
elucidate / validate requirements and then discarded. The
Incremental Development Revisited
system is then developed using some other development
process. • System developed and delivered in increments after
establishing an overall architecture.
Starting Points
• Users experiment with delivered increments while others are
• In evolutionary prototyping, development starts with those being developed.
requirements, which are best understood.
• Intended to combine advantages of prototyping with a
• In throwaway prototyping, development starts with those more manageable process and maintainable system structure.
requirements, which are least understood.
Incremental Development Process
Approaches to Prototyping
Ev o lu ti on ary Del i vered Define system
p ro to ty pi ng s ys tem deliverables
Ou t li ne
R equ irem ent s
Th row-away Execut able P rot ot yp e + Build system Validate
S y st em S peci ficat io n Design system Specify system
P ro to ty pi ng increment
architecture increment increment

NO
Evolutionary Prototyping
Deliver final System Validate Integrate
• Often used when a specification cannot be developed in system complete? system increment
YES
advance (e.g., AI systems and GUI applications).
• System is developed as a series of prototype versions
delivered to the customer for assessment.
Throw-away Prototyping
• Verification is unnecessary as there is no specification. • Used to reduce requirements risk.
• Validation involves assessing the adequacy of the system. • Initial prototype is developed from outline requirements,
delivered for experiment, and modified until risk is
Develop abstract Build prototype Use prototype
specification system system
acceptably low

Outline Develop Evaluate Specify

N requirements prototype prototype system

Reusable
YES components
Deliver System
system adequate?
Delivered
Develop Validate software
software system system

• Techniques for rapid system development are used such as

CASE tools and 4GLs.
Throw-away Prototype Delivery
• User interfaces are usually developed using a GUI
development toolkit. • Developers may be pressurized to deliver a throw-away
prototype as the final system.
Advantages of Evolutionary Prototyping Over
• This is very problematic...
Normal System Development
It may be impossible to meet non-functional requirements.
• Accelerated delivery : Quick availability is sometimes more
important than details of functionality or maintainability. The prototype is almost certainly undocumented.
• User engagement : System is more likely to meet user The system may be poorly structured and therefore difficult to
requirements and users are more likely to want to make it maintain.
work. Normal quality standards may not have been applied.
Evolutionary Prototyping Problems Prototypes AS Specifications?
• Management problems • Some parts of the requirements (e.g., safety-critical functions)
Poor fit with existing waterfall management model may be impossible to prototype and so don’t appear in the
specification.

44
• An implementation has no legal standing as a contract.

SOFTWARE ENGINEERING
Interface
Spreadsheet
• Non-functional requirements cannot be adequately generator

represented in a system prototype. DB

programming
Report
gen erator
lan guag e
Implementation Techniques
Databas e manag ement system
• Various techniques may be used for rapid development:
Dynamic high-level language development Fourth-gener ation language

Database programming (4GL’s)

Component and Application Assembly
Component and application assembly
• Prototypes can be created quickly from a set of reusable
• These are not mutually exclusive : they are often used components plus some mechanism to “glue” these
together.
components together.
• Visual programming is an inherent part of most prototype • The composition mechanism must include control facilities
development systems.
and a mechanism for component communication
Dynamic High-level Languages • Must take into account the availability and functionality of
• Include powerful data management facilities : often type less existing components
and interpretive
Prototyping With Reuse
• Require large run-time support system : not normally used • Application level development
for large system development.
Entire application systems are integrated with the prototype so
• Some offer excellent GUI development facilities. that their functionality can be shared.
• Some have an integrated support environment whose For example, if text preparation is required, a standard word
facilities may be used in the prototype.
processor can be used.
• Examples: Lisp (list structure based), Prolog (logic based), • Component level development
and Smalltalk (object-oriented)
Individual components are integrated within a standard
Choice of Prototyping Language framework to implement the system
• What is the application domain? (e.g., NLP?, matrix Framework can be a scripting language or an integration
manipulation?) framework such as CORBA, DCOM, or Java Beans
• What user interaction is required? (text-based? Web-based?) Reusable Component Composition
• What support environment comes with the language? (e.g.,
tools, components) Reusable Component
Executable
software composition
prototype
• What support environment comes with the language? (e.g., components framework
tools, components)
• Different parts of the system may be programmed in Control and
different languages. However, there may be problems with integration code
language communications.
• A multi-paradigm language (e.g., LOOPS) can reduce this Compound Documents
problem. • For some applications, a prototype can be created by
Database Programming Languages developing a compound document.
• Domain specific languages for business systems based • This is a document with active elements (such as a
around a database management system spreadsheet) that allow user computations.
• Normally include a database query language, a screen • Each active element has an associated application, which is
generator, a report generator and a spreadsheet. invoked when that element is selected.
• May be integrated with a CASE toolset • The document itself is the integrator for the different
• The language + environment is some-times known as a applications.
fourth-generation language (4GL) Application Linking in Compound Documents
• Cost-effective for small to medium sized business systems C om p ou nd d ocu m ent

• Examples include Informix, Appgen, Sculptor, and Power- Text 1 Table 1 Text 2 T e xt 3 S o un d 1
4GL.
Table 2 T e xt 4 S o un d 2 Text 5

W o rd p r o c e s s o r S p r ea d s h e e t A u dio pla ye r

45
 Visual Programming • Prototyping is essential for parts of the system such as the
SOFTWARE ENGINEERING

• Scripting languages such as Visual Basic support visual user interface, which cannot be effectively pre-specified. Users
programming where the prototype is developed by creating a must be involved in prototype evaluation
user interface from standard items and associating Activity
components with these items. You have been asked to investigate the feasibility of
• A large library of components exists to support this type of prototyping in the software development process in your
development organization. Write a report for your manager discussing the
• These may be tailored to suit the specific application classes of project where prototyping should be used and setting
requirements. out the expected costs and benefits form using prototyping.

Visual Programming With Reuse

Hypertext
Date component display component

File Edit Views Layout Options Help

General
12th January 2000 Index
Range checking 3.876
script

User prompt
component +
Draw canvas script
component

Tree display
component

Problems With Visual Development

• Difficult to coordinate team-based development
• No explicit system architecture (hidden)
• Complex dependencies between parts of the program can
cause maintainability problems.
Activity
User Interface Prototyping Explain why, for large systems development, it is recommended
• It is impossible to pre-specify the look and feel of a user that prototypes should be throw away prototypes.
interface in an effective way. Prototyping is essential.
• UI development consumes an increasing part of overall
system development costs
• User interface generators may be used to “draw” the interface
and simulate its functionality with components associated
with interface entities.
• Web interfaces may be prototyped using a web site editor.
Key Points
• A prototype can be used to give end-users a concrete
impression of the system’s capabilities.
• Prototyping is becoming increasingly used for system
development where rapid development is essential.
• Throw-away prototyping is used to understand the system
requirements.
• In evolutionary prototyping, the system is developed by
evolving an initial version to the final version.
• Rapid development of prototypes is essential. This may
require leaving out functionality or relaxing non-functional
constraints.
• Prototyping techniques include the use of very high-level
languages, database programming and prototype
construction from reusable components.

46
Activity Activity

SOFTWARE ENGINEERING
Under what circumstances would you recommend that Discuss prototyping using reusable components and suggest
prototyping should be used as a means of validating system problems which may arise using this approach. What is the
requirements? most effective way to specify reusable components?

Activity Activity
Suggest difficulties that might arise when prototyping real time You have been asked by a charity to prototype a system that
embedded computer systems : keeps track of tall donations they have received. This system has
to maintain the names and addresses of donors, their particular
interests, the amount donated, and when it was donation (e.g.
it must be spent on a particular project) and the system must
keep track of these donations and how they were spent. Discuss
how you would prototype this system bearing in mind that the
charity has a mixture of paid workers and volunteers. Many of
the volunteers are retirees who have had little or no computer
experience.

47
 Activity
SOFTWARE ENGINEERING

You have developed a throw prototype system for a client who

is very happy with it. However, she suggests that there is no
need to develop another system but that you should deliver the
prototype and offers an excellent price for the system. You
know that there may be future problems with maintaining the
system. Discuss how you might respond to this customer.

Notes:

48
 UNIT I
OVERVIEW AND REQUIREMENTS
LECTURE 14:
FORMAL SPECIFICATIONS CHAPTER 8

Objectives • In systems where failure must be avoided, the use of formal

SOFTWARE ENGINEERING
• To explain why formal specification helps discover problems methods is justified and likely to be cost-effective.
in system requirements. • Thus, the use of formal methods is increasing in critical
• To describe the use of: system development where safety, reliability, and security are
important.
Algebraic specification techniques, and
Model-based specification techniques (including simple pre and Formal Specification in The Software Process
post conditions). Requirements Formal
specificatio n specificat ion
Topics Covered
Requ irements Hi gh-le vel
• Formal specification in the software process defini tion d es ign

• Interface specification Sy stem

modell ing
Ar chitect ural
des ign
• Behavioural specification
Formal Methods Formal Specification Techniques
• Formal specification is part of a more general collection of
techniques known as “formal methods.”
• All are based on the mathematical representations and
analysis of requirements and software.
• Formal methods include:
Formal specification
Specification analysis and property proofs
Algebraic approach : the system is specified in terms of its
Transformational development operations and their relationships via axioms.
Program verification (program correctness proofs) Model-based approach (including simple pre- and post-
• Specifications are expressed with precisely defined vocabulary, conditions) : the system is specified in terms of a state model
syntax, and semantics. and operations are defined in terms of changes to system state.
Acceptance and Use Formal Specification Languages
• Formal methods have not become mainstream as was once
predicted, especially in the US.
Other, less costly software engineering techniques (e.g., inspec-
tions / reviews) have been successful at increasing system
quality. (Hence, the need for formal methods has been reduced.)
Market changes have made time-to-market rather than quality
the key issue for many systems. (Formal methods do not reduce
time-to-market.) Use of Formal Specification
The scope of formal methods is limited. They are not well • Formal specification is a rigorous process and requires more
suited to specifying user interfaces. (Many interactive applica- effort in the early phases of software development.
tions are “GUI-heavy” today.) • This reduces requirements errors as ambiguities,
Formal methods are hard to scale up to very large systems. incompleteness, and inconsistencies are discovered and
(Although this is rarely necessary.) resolved.
The costs of introducing formal methods are high. • Hence, rework due to requirements problems is greatly
reduced.
Thus, the risks of adopting formal methods on most projects
outweigh the benefits.
• However, formal specification is an excellent way to find
requirements errors and to express requirements
unambiguously.
• Projects, which use formal methods invariably, report fewer
errors in the delivered software.

49
 Development Costs With Formal Specification • (System State) Model-based specification exposes the system
SOFTWARE ENGINEERING

state and defines operations in terms of changes to that

state.
C o st Vali da t io n
• Z is a mature notation for model-based specification. It
De s ig n and combines formal and informal descriptions and incorporates
Im pl em ent a t io n Va li dat io n
graphical highlighting.
Des ig n a nd
Im pl em e nt at io n • The basic building blocks of Z-based specifications are
S p e ci fic at io n
schemas.

S p e ci fica t io n
• Schemas identify state variables and define constraints and
operations in terms of those variables.
The Structure of A Z Schema
W i th ou t fo rm a l W i th fo rm al Schema name Schema signature Schema predicate
s pe cifi c at io n s pec ifi ca t io n

Natural numbers (0, 1, 2, …)

Container
contents:
Specification of Sub-system Interfaces capacity: Defines schema state
• Large systems are normally comprised of sub-systems with contents <
Š capacity “invariants”, pre- & post-
well-defined interfaces.
conditions
• Specification of these interfaces allows for their independent
development.
An Insulin Pump
• Interfaces are often defined as abstract data types or objects.
• The algebraic approach is particularly well suited to the Insulin reservoir
specification of such interfaces.
insulin
Needle
Sub-system Interfaces assembly Pump Clock

Int e r f a c e delivery
o bj ec t s

Sensor Controller Alarm

S u b- s ys te m S u b-s ys te m
A B glucose level

Display1 Display2

text messages dose delivered

Specification Components
Power supply
• Introduction : defines the sort (type name) and declares
other specifications that are used
• Description : informally describes the operations on the type Modelling The Insulin Pump
• Signature : defines the syntax of the operations in the • The schema models the insulin pump as a number of state
interface and their parameters variables
• Axioms : defines the operation semantics by defining reading? -from sensor dose, cumulative dose
axioms which characterize behaviour r0, r1, r2 -last 3 readings
Types of Operations capacity -pump reservoir
• Constructor operations: operations which create / modify alarm! -signals exceptional conditions
entities of the type pump! -output for pump device
• Inspection operations: operations, which evaluate entities of display1!, display2! -text messages & dose
the type being specified
• Names followed by a? are inputs, names followed by a! are
• Rule of thumb for defining axioms: define an axiom, which outputs.
sets out what is always true for each inspection operation
over each constructor Schema Invariant
Model-based Specification • Each Z schema has an invariant part, which defines
conditions that are always true (schema predicates)
• Algebraic specification can be cumber-some when object
operations are not independent of object state (i.e., previous • For the insulin pump schema, it is always true that:
operations). The dose must be less than or equal to the capacity of the
insulin reservoir.

50
No single dose may be more than 5 units of insulin and the Output Schemas

SOFTWARE ENGINEERING
total dose delivered in a time period must not exceed 50 units • The output schemas model the system displays and the
of insulin. This is a safety constraint. alarm that indicates some potentially dangerous condition.
display1! shows the status of the insulin reservoir. • The output displays show the dose computed and a warning
Insulin Pump Schema message.
• The alarm is activated if blood sugar is very low – this
indicates that the user should eat something to increase his
Insulin_pump blood sugar level.
reading? :
dos e, cumulative_dose:
r0, r1, r2: // used to record the last 3 readings taken DIS PLAY
capacity: ∆Insulin_P um p conversion
alarm!: {off, on} Note conflict with
pump!: “insulin low” msg.
dis play1!, display2!: STRING dis pla y2!' = Na t_to_s tring (dose ) ∧
(re a ding? < 3 ⇒ displa y1!' = "S uga r low" ∨
dose ? capacity ^ dose ? 5 ^ cumulative_dose ? 50 re a ding? > 30 ⇒ displa y1!' = "S uga r high" ∨
dos e ?Š capacity ∧ dose Š 5 ∧ cumulative_dose Š 50
capacity
capacity? 40
•40=> ⇒display1! = “ “= " "
dis play1! 30 ⇒ displa y1!' = "OK")
re a ding? ?•33 a nd re a ding? Š? 30
capacity ? 39 ^ capacity
capacity Š 39 ∧ capacity • ? 10 =>10display1! = “Insulin
⇒ dis play1! low”
= "Ins ulin low"
capacity
capacity Š 9 ⇒ alarm! = on ∧ dis play1! = "Ins ulinlow”
? 9 => alarm! = on ^ display1! = “Insulin very very low"
r2 ALAR M
r2==reading?
reading? ∆Insulin_P um p
every 10 minutes…
( re a ding? < 3 ∨ re a ding? > 30 ) ⇒ a la rm!' = on ∨ ^ AND
( re a ding? •
? 3 ∧ re a ding? ?Š 30 ) ⇒ a la rm!' = off

The Dosage Computation

• The insulin pump computes the amount of insulin required
Schema Consistency
by comparing the current reading with two previous
readings. • It is important that schemas be consistent. Inconsistency
suggests a problem with system requirements.
• If these suggest that blood glucose is rising then insulin is
delivered. • The INSULIN_PUMP schema and the DISPLAY are
inconsistent:
• Information about the total dose delivered is maintained to
allow the safety check invariant to be applied. display1! shows a warning message about the insulin reservoir
(INSULIN_PUMP)
• Note that this invariant always applies – there is no need to
repeat it in the dosage computation. display1! Shows the state of the blood sugar (DISPLAY)

DOSAGE Schema • This must be resolved before implementation of the system.

Secification Via Pre-and Post-conditions
• Predicates that (when considered together) reflect a program’s
DO SAGE
operations change state intended functional behavior are defined over its state
∆Insulin_Pump variables.
( • Pre-condition: expresses constraints on program variables
dos e = 0 ∧ imports state & predicates
before program execution. An implementer may assume
( (( r1 ? r0) ^ ( r2 = r1)) V
(( r1 •r0) ∧ ( r2 = r1)) ∨ these will hold BEFORE program execution.
((((r1
r1 >>r0)
r0)^∧( r2(r2<Šr1))
r1))V∨
((((r1 r0)^∧((r1-r2)
r1 <<r0) ((r1-r2)> >(r0-r1)))
(r0-r1))) • Post-condition: expresses conditions / relationships among
) ∨ program variables after execution. These capture any
dose = 4 ∧
( obligatory conditions AFTER program execution.
(( r1
(( r1 Š? r0)
r0) ^∧ (r2 = r1)) ∨V
(r2 =r1)) • Language: (first order) predicate calculus
((
(( r1 r0) ∧
r1 << r0) ((r1-r2)
^ ((r1 – r2)Š?(r0-r1)))
(r0 – r1)))
) ∨ Predicates (X>4)
dos e =(r2 -r1) * 4 ∧
(
(( r1
r1 Š? r0)
r0) ^∧ (r2
Connectives (&, V, → , ó, NOT)
(( (r2>>r1))
r1))V∨
((
(( r1 r0) ∧
r1 >> r0) ((r2–- r1)
^ ((r2 r1) ?•(r1
(r1 –- r0)))
r0))) Universal and existential quantifiers (for every, there exists…)
)
) x?- value of x after operation Rules of inference (if A & (A → B) then B)
capacity' = cap acity - dos e
cumula tive_dos e' = cumulative _dose + dos e Example 1
r0' = r1 ∧ r1 ' = r2
Sort a non-empty array LIST [1..N] into increasing order.
Pre-cond: N >1
Post-cond: For_Every i, 1 < i < N-1, LIST [i] < LIST [i+1] &
PERM (LIST, LIST’)

51
 Example 2 Activity
SOFTWARE ENGINEERING

Search a non-empty, ordered array LIST [1..N] for the value You have been given the task of selling formal specification
stored in KEY. If present, set found to true and J to an index techniques to a software development organization. Outline
of LIST which corresponds to KEY. Otherwise, set FOUND to how you would go about explaining the advantages of formal
false. specifications to skeptical, practicing software engineers.
Pre-cond: N > 1 & [(“LIST is in increasing order”) V (“LIST is
in decreasing order”)]
(Exercise: express the “ordered” predicate above FORMALLY.)
Post-cond: [(FOUND & There Exists i, 1 < i < N | J=i &
LIST [J]=Key) V (NOT FOUND & For_Every i, 1 < i < N,
LIST [i] ≠ KEY)] & UNCH (LIST, KEY)
Key Points
• Formal system specification complements informal
specification techniques.
• Formal specifications are precise and unambiguous. They
remove areas of doubt in a specification.
• Formal specification forces an analysis of the system
requirements at an early stage. Correcting errors at this stage
is cheaper than modifying a delivered system.
• Formal specification techniques are most applicable in the
development of critical systems.
• Algebraic techniques are particularly suited to specifying
interfaces of objects and abstract data types.
• In model-based specification, operations are defined in terms
of changes to system state.
Activity Activity
Suggest why the architectural design of a system should precede Explain why it is particularly important to define sub-system
the development of a formal specification. interfaces in a precise way and why algebraic specification is
particularly appropriate for sub-system interface specification.

52
Activity Activity

SOFTWARE ENGINEERING
In the example of a controlled airspace sector, the safety You are a systems engineer and you are asked to suggest the
condition is that aircraft may not be within 300 m of height in best way to develop the safety software for a heart pacemaker.
the same sector. Modify the specification shown in figure 9.8 to You suggest formally specifying the system but your sugges-
allow aircraft to occupy the same height in the sector so long as tion is rejected by your manager. You think his reasons are weak
they are separated by at least 8km of horizontal difference. You and based on prejudice. Is it ethical to develop the system using
may ignore aircraft in adjacent sectors. Hint. You have to modify methods that you think are inadequate?
the constructor operations so that they include the aircraft
position as well as its height. You also have to define an
operation that, given two positions, returns the separation
between them.

Activity
Bank teller machines rely on using information on the user’s
card giving the bank identifier, the account number and the
user’s personal identifier. They also derive account information
from a central database and update that database on completion
of a transaction. Using your knowledge of ATM operation
write Z schemas defining the state of the system, card valida-
tion (where the user’s identifier is checked) and cash withdrawal.

53
 UNIT II
DESIGN, VERIFICATION AND VALIDATION
LESSON15 AND 16: UNIT 4
ARCHITECTURAL DESIGN CHAPTER 9

Establishing The Overall Structure of a Software • Control modelling : a model of the control relationships
SOFTWARE ENGINEERING

System between the sub-systems is established.

Objectives • Modular decomposition : the identified sub-systems are
decomposed into lower-level modules (components, objects,
• To introduce architectural design and to discuss its
etc.)
importance
• To explain why multiple models are required to document in Terminology Issues
architecture • Modular decomposition is sometimes called high-level
• To describe types of architectural models that may be used (system) design.
• To discuss use of domain-specific architectural reference • A sub-system is usually a system in its own right, and is
models sometimes called a Product.

Topics Covered • A module is a lower-level element that would not normally

be considered a separate system; modules are sometimes
• Architectural design called Components or Objects.
• System structuring • Traditional (and Somerville’s) terminology
• Control models System (System)
• Modular decomposition Product (Sub-System)
• Domain-specific architectures Component (Module)
What is Architectural Design? Module (Unit) (Algorithm)
• The process of identifying the sub-systems making up a Architectural Models
system and a framework for sub-system control and
communication. • Different types of models may be used to represent an
architectural design.
• A boot-strapping process undertaken in parallel with the
abstract specification of sub-systems.
• Each presents a different perspective on the architecture.
• The output of this process is the software architecture. Architectural Model Types
The Software Design Process • Static structural models show the major system components.
• Dynamic process models show the process structure of the
Requirements
specification
system at run-time.
Design activities
• Interface models define the sub-system services offered
Architectural Abstract Interface Component Data Algorithm
through public interfaces.
design design design structure design
specification
design
• Relationship models show relationships such as a dataflow
among sub-systems.
Software Data
System Interface Component Algorithm
architecture specification specification specification
structure
specification
specification Architectural Styles
Design products • The architecture of a system may conform to a single generic
model or style, although most do not.
Advantages of explicit architecture design and documentation (Bass) • An awareness of these styles and how they can affect system
• Stakeholder communication : the architecture may be used as attributes can simplify the problem of choosing an
a focus of discussion by system stakeholders. appropriate architecture.
• System analysis : the feasibility of meeting critical non- System Attributes And Architectural Styles /
functional requirements (e.g., performance, reliability, Structures
maintainability) can be studied early on.
• Performance : localize operations by using fewer, large-grain
• Large-scale reuse : the architecture may be reusable across a components to minimize sub-system communication.
range of systems with similar requirements.
• Security : use a layered architecture with critical assets in inner
Architectural Design Process layers.
• System structuring : the system is decomposed into major • Safety : isolate safety-critical components in one or just a few
sub-systems and communication (e.g., data sharing) sub-systems.
mechanisms are identified.

54
Availability : include redundant components in the architecture. Repository Model Advantages

SOFTWARE ENGINEERING
• Maintainability : use fine-grain, self-contained components. • Simple and efficient way to share large amounts of data
locally.
System Structuring
• Concerned with decomposing the system into interacting • Sub-systems, which use data, need not be concerned with
how that data is produced, and vice-versa.
sub-systems.
• The architectural design is normally expressed as a block • Management activities such as backup, access control, and
recovery are centralized.
diagram presenting an overview of the system structure.
• More specific models showing how sub-systems share data • Sharing model is published as the repository schema.
Integration of compatible tools is relatively easy.
are distributed, and interface with each other may also be
developed. (Examples follow.) Repository Model Disadvantages
Packing Robot Control System • Sub-systems must agree on a single repository data model.
This is inevitably a compromise.

V ision
• Data model evolution is difficult and expensive.
s ys tem • No provision for sub-system-specific data management
requirements related to backup, access control, and recovery.
Ob ject Arm Gripp er
• May be difficult to distribute efficiently over a number of
identificat io n con tro ller con tro ller machines due to problems with data redundancy and
s ys tem
inconsistency.
The Client-server Model
Packag in g • Distributed system model, which shows how data and
s election
s ys tem
processing are distributed across a range of processors.
• Major components are:
A set of stand-alone servers, which provide specific services
Packing Co nveyo r
such as printing, file management, etc.
s ys tem con tro ller A set of clients, which call on these services
A network, which allows clients to access these services
Film and Picture Library
The Repository Model
• Sub-systems must exchange info. This may be done in two Client 1 Client 2 Client 3 Client 4
ways:
Shared data is held in a central database or repository and may
be accessed by all sub-systems.
Each sub-system maintains its own database and passes data Wide-bandwidth network
explicitly to other sub-systems.
• When large amounts of data are used, the repository model
of sharing is commonly used.
Catalogue Video Picture Hypertext
CASE Toolset Architecture server server server server

Catalogue Filmclip Digitized Hypertext

files photographs web
Design Code
editor generator

Client-server Model Advantages

• Supports distributed computing.
Design Project Program
translator repository editor • Underlying network makes distribution of data
straightforward.
• No shared data model so servers may organize data to
optimise their performance.
Design Report
analyser generator
• Distinction between servers and clients may allow use of
cheaper hardware.
• Relatively easy to expand or upgrade system.

55
 Client-server Model Disadvantages Call-return Model
SOFTWARE ENGINEERING

• Relatively complex architecture – problem determination can

be difficult. Main
• No shared data model so data integration may be program
problematic.
• Redundant data management in each server.
• No central register of names and services, so it may be hard Routine 1 Routine 2 Routine 3
to find out what servers and services are available.
The Abstract Machine Model
• Organizes a system into a series of layers.
• Each layer defines an abstract machine and provides a set of Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2
services used to implement the next level of abstract
machine.
• When a layer interface changes, only the adjacent layer is Manager Model - Real-time System Control
affected.
• However, it is often difficult to structure systems in this way.
S e n so r A c t ua t or
(Why?) p ro ce s se s p ro ce s se s
Abstract Machine Based Version Management
System
S y st e m
c on tr o ll er

Version man ag emen t

Ob ject managemen t C o m pu ta t io n U s er Fa ul t
p ro ce s se s i nt er fa c e h an dl e r

Datab as e system
Op eratin g Principal Event-based Control Models
system 1. Broadcast model : an event is broadcast to all sub-systems;
any sub-system, which can handle the event, may do so.
2. Interrupt-driven model : used in real-time systems where
interrupts are detected by an interrupt handler and passed to
some other component for processing.
(Other event-based models include compound documents and
production systems.)
Control Models
Broadcast Model
• Concerned with the control flow between sub-systems.
Distinct from the system structure model. • Effective in integrating sub-systems executing on different
computers in a network.
• Two general approaches:
• Control policy is NOT embedded in the message handler;
Centralized control : one sub-system has overall responsibility
sub-systems register an interest in specific events and the
for control and starts and stops other sub-systems.
event handler ensures that these events are sent to them.
Event-based control : each sub-system can respond to externally
• Registration of interests’ supports selective broadcasting.
generated events from other sub-systems, or from the system’s
environment. • Evolution is relatively easy since a new sub-system can be
integrated by registering its events with the event handler.
Centralized Control Models
• However, sub-systems don’t know if or when an event will
1. Call-return model : top-down subroutine model where be handled by some other sub-system.
control starts at the top of a subroutine hierarchy and moves
downwards. Applicable to sequential systems only. Interrupt-driven Systems
2. Manager model : applicable to concurrent systems. One • Used in real-time systems where fast response to an event is
system component controls the stopping, starting and essential.
coordination of other system processes. Also applicable to • A handler is defined for each type of interrupt.
sequential systems where it is usually implemented as a case • Each type is associated with a memory location and a
statement within a management routine. hardware switch causes transfer to its handler – fast!

56
• Allows fast response but is complex to program and difficult • Sometimes referred to as a pipe and filter model (after

SOFTWARE ENGINEERING
to verify. (Why?) terminology used in UNIX).
Interrupt-driven Control • Variants of this approach have a long history in software
design.

Interrupts • When transformations are sequential, this is a batch

sequential model
• Which is extensively used in data processing systems.
Interrupt • Not really suitable for interactive systems (input data streams
vector versus events)
Invoice Processing System

Issue
Handler Handler Handler Handler Receipts
receipts
1 2 3 4
Read issued Identify
invoices payments
Find Issue
Process Process Process Process payments payment Reminders
1 2 3 4 due reminder
Invoices Payments

Modular Decomposition (A.K.A. High-level Design)

Domain-specific Architectures
• Sub-systems are decomposed into lower-level elements. • Architectural models which are specific to some application
• Two models are considered: domain
An object model where the system is decom-posed into • Two types of domain-specific models:
interacting objects. (object-oriented design)
1.Generic models encapsulate the traditional, time-tested
A data-flow model where the system is decomposed into characteristics of real systems.
functional modules, which transform inputs into outputs.
2.Reference models are more abstract and describe a larger class
(function-oriented design)
of systems. They provide a means of comparing different
Object Models systems in a domain.
• Structure the system into a set of loosely coupled objects • Generic models are usually bottom-up models; Reference
with well-defined interfaces. models are top-down models.
• Object-oriented decomposition is concerned with identifying Generic Models
object classes, their attributes and operations.
• The compiler model is a well-known example.
• When implemented, objects are created from these classes • Based on the thousands written, it is now generally agreed
and some control model is used to coordinate object
that the standard components of a compiler are:
operations.
Lexical analyser
Invoice Processing System
Symbol table
Syntax analyser
Customer Receipt
customer# invoice# Syntax tree
name date
address amount Semantic analyser
Invoice
credit period customer#
invoice# Code generator
date
amount Compiler Model
customer
Payment issue () Symbol
invoice# sendReminder () table
date acceptPayment ()
amount sendReceipt ()
customer#
Lexical Syn tactic Semantic Code
analysis analysis analysis generation
Data-flow Models
• Functional transformations process inputs to produce
outputs. Sequential function model (batch processing oriented)

57
 Language Processing System • Domain specific architectural models are abstractions over an
SOFTWARE ENGINEERING

application domain.
• They may be constructed by abstracting from existing
Lexical Syntax Semantic
analyser analyser analyser systems or they may be idealized reference models.
Activity
Explain why it may be necessary to design the system architec-
ture before the specifications are written.
Pretty- Abstract Grammar
printer syntax tree definition Optimizer

Symbol Output Code

Editor
table definition generator

Repository

Repository-based model
Reference Architectures
• Reference models are derived from a study of the application
domain rather than from existing systems.
• May be used as a basis for system implementation, or to
compare different systems. It acts as a standard against
which systems can be evaluated.
• The OSI (Open System Interconnection) model is a layered
model for communication systems (in particular, data
processing / point-of-sale applications).
OSI Reference Model

7 Application Application
Activity
6 Presentation Presentation
Construct a table showing the advantages and disadvantages of
5 Session Session the different structural models discussed in this chapter.

4 Transport Transport

3 Network Network Network

2 Data link Data link Data link

1 Physical Physical Physical

Communications medium

Key Points
• The software architect is responsible for deriving a structural
system model, a control model, and a sub-system
decomposition model.
• Large systems rarely conform to a single architectural model.
• System decomposition models include the repository model,
client-server model, and abstract machine model.
• Control models include centralized control and event-driven
models.
• Modular decomposition models include data-flow and
object models.

58
Activity Activity

SOFTWARE ENGINEERING
Giving reasons for your answer, suggest an appropriate Explain why a call-return model of control is not usually
structural model for the following systems: suitable for real time systems which control some process.
• An automated ticket issuing system used by passengers at a
railway station.
• A computer controlled video conferencing system, which
allows video, audio, and computer data to be visible to
several participants at the same time.
• A robot floor cleaner, which is intended to clean relatively,
clear spaces such as corridors. The cleaner must be able to
sense walls and other obstructions.

Activity
Giving reasons for your answer, suggest an appropriate control
model for the following systems:
• A batch processing system, which takes information about
hours, worked and pays rates and prints salary slips and bank
Activity credit transfer information.
Design an architecture for the above systems based on your • A set of software tools, which are, produced buy different
choice of model. Make reasonable assumptions about the vendors but which mist work together.
system requirements. • A television controller, which responds to, signals form a
remote control unit.

59
 Notes:
SOFTWARE ENGINEERING

Activity
Discuss their advantages and disadvantages as far as disreputa-
bility is concerned of the data flow model and the object model.
Assume that both single machine and distributed versions of
an application are required.

Activity
Should there be a separate profession of ‘software architect’
whose role is to work independently with a customer to design
a software architecture? This would then be implemented by
some software company. What might be the difficulties of
establishing such a profession?

60
 UNIT II
DESIGN, VERIFICATION AND VALIDATION
LESSON17 AND 18:
DISTRIBUTED SYSTEMS
CHAPTER 10
ARCHITECTURES

Architectural Design for Software That Executes on Distributed Systems

SOFTWARE ENGINEERING
More Than One Processor • Virtually all-large, computer-based systems are now
Objectives distributed systems.
• To explain the advantages and disadvantages of distributed • Processing is distributed over several computers rather than
systems architectures. confined to a single machine.
• To describe different approaches to the development of • Distributed software engineering is now very important.
client-server systems. Distributed System Characteristics / Advantages
• To explain the differences between client-server and • Resource sharing (hardware and software)
distributed object architectures.
• Openness (resource extendibility)
• To describe object request brokers and the principles
• Concurrency (parallel processing)
underlying the CORBA standards.
• Scalability (up to capacity of network)
Topics Covered
• Fault tolerance (potential)
• Multiprocessing systems
• Transparency (ability to conceal distributed nature)
• Distributed systems architectures
Distributed System Disadvantages
Client-server architectures
• Complexity (no. of factors affecting emergent properties)
Distributed object architectures
• Security (multiple access points, network eavesdropping)
• CORBA (Common Object Request Broker Architecture)
• Manageability (heterogeneity)
Multiprocessor Architectures
• Unpredictable responsiveness
• System composed of multiple processes, which may or may
not execute on different processors. Issues in Distributed System Design
• Distribution of process to processor may be pre-ordered or
may be under the control of a dispatcher. Design issue Description
Resource The resources in a distributed system are spread across different
A Multiprocessor Traffic Control System identification computers and a naming scheme has to be devised so that users can
discover and refer to the resources that they need. An example of
such a naming scheme is the URL (Uniform Resource Locator) that
Traffic flow Traffic light control
is used to identify WWW pages. If a meaningful and universally
Sensor
processor processor processor understood identification scheme is not used then many of these
resources will be inaccessible to system users.
Sensor Display
Light Communications The universal availability of the Internet and the efficient
control control
process
process process implementation of Internet TCP/IP communication protocols means
that, for most distributed systems, these are the most effective way
for the computers to communicate. However, where there are
specific requirements for performance, reliability etc. alternative
approaches to communications may be used.
Traffic lights
Quality of service The quality of service offered by a system reflects its performance,
Traffic flow sensors availability and reliability. It is affected by a number of factors such
and cameras Operator consoles
as the allocation of processes to processes in the system, the
distribution of resources across the system, the network and the
system hardware and the adaptability of the system.
Types of Multiprocessing Systems Software The software architecture describes how the application
• Personal systems that are not distributed and that are architectures functionality is distributed over a number of logical components and
how these components are distributed across processors. Choosing
designed to run on a personal computer or workstation. the right architecture for an application is essential to achieve the
(word processors) desired quality of service.

• Embedded systems that run on a single processor or on an

integrated group of processors. (control systems, real-time
systems) Distributed Systems Architectures
• Distributed systems where the system software runs on a • Client-server architectures : Ristributed services, which are
loosely integrated group of processors linked by a network. called on by clients. Servers that provide services are treated
(ATM systems) differently from clients that use services.
• Distributed object architectures : Removes distinction
between clients and servers. Any object in the system may
provide and use services from other objects.

61
 Middleware Distributing Layers to Processors
SOFTWARE ENGINEERING

• Software that manages and enables communication between • Two-tier C/S architecture : the three layers are distributed
the diverse components of a distributed system. Middleware between a server processor and a set of clients.
is usually off-the-shelf rather than specially written. • Three-tier C/S architecture : the layers are distributed among
• Distributed system frameworks, e.g. CORBA and DCOM, is two server processes / processors and a set of clients.
an important class of middle-ware described later. • Multi-tier C/S architectures : the layers are distributed among
Client-server Architectures multiple server processes / processors (each associated with a
separate database, for example) and a set of clients.
• The application is modelled as a set of services that are
provided by servers and a set of clients that use the services. Two-tier Architectures: Thin and Fat Clients
• Clients must know of servers but servers need not know of • Thin-client model : the application logic and data
clients. (e.g., “installing” a network printer) management are implemented on the server; the client only
• Clients and servers are logical processes as opposed to handles the user interface.
physical machines. • Fat-client model : the server is only responsible for data
• The mapping of processors to processes is not necessarily management; the client handles the application logic and the
1:1. user interface.

A Client-server System Thin and Fat Clients

Presentation
c2 c3 c4 Server
c12
Thin-client Data management
c11
model Client
Server pro cess Application
c1 processing
s1 s4

c10
c5
Cl ient process Presentation
s2 s3 c9 Application processing Server
Fat-client
c6 model Client Data
c7 c8
management

Computers in a C/S Network

c1 c2 c3, c4
Thin-client Model
CC1 CC2 CC3
• Often used when centralized legacy systems evolve to a C/S
s1, s2
Network s3, s4 Server
architecture; the user interface is migrated to workstations or
SC1
computer
terminals and the legacy system acts as a server.
SC2
• Places a heavy processing load on both the server and the
Client network; this is wasteful when clients are powerful
computer
c5, c6, c7
CC4 CC5
c8, c9
CC6
c10, c11, c12 workstations.
Fat-client Model
Application Layers Model • More processing is delegated to the client as the application
• Presentation layer : concerned with presenting the results of a logic is executed locally.
computation to system users and with collecting user inputs. • But system management is more complex, especially when
• Application processing layer : concerned with implementing application function changes and new logic must be installed
the logic (functionality) of the application. on each client.
• Data management layer : concerned with all system database A Client-server ATM System
operations.
Application Layers ATM

P r e s e n ta t io n la y e r ATM Acco unt server

Tele- Cu stomer
p rocessin g accou nt
A p p l i ca t io n p r o c e s s in g
ATM mo nitor d atabase
l ay e r
ATM

D a t a m a n a ge m e n t
l ay e r

62
Three-tier Architectures Advantages of Distributed Object Architectures

SOFTWARE ENGINEERING
• Each application architecture layer may execute on a separate • Allows system designer to delay decisions on where and how
processor. services should be provided. (Service-providing objects may
• Allows for better performance and scalability than a thin- execute on any network node.)
client approach and is simpler to manage than a fat-client • Very open architecture : allows new resources to be added as
approach. required.
A 3-tier C/S Architecture • Flexible and scaleable.
Presentation • System is dynamically reconfigurable : objects can migrate
Server Server across the network as required. (Thus improving
Client Application Data performance.)
processing management
Uses of Distributed Object Architectures
• As a logical model for structuring and organizing a system
An Internet Banking System solely in terms of services provided by a number of
distributed objects. (E.g., a data mining system.)
Client HTTP interaction
• As a flexible means of implementing C/S systems. Both
Web server Datab ase server clients and servers are realised as distributed objects
SQL query
Client Account service SQL
Customer
account
communicating through a software bus.
provision
database
A Data Mining System
Client

Database 1 Report gen.

Client Integrator 1

Use of C/S Architectures Database 2

Visualiser

Architecture Applications Integrator 2

Two-tier C/S Legacy system applications where separating application
architecture with processing and data management is impractical
Database 3
thin clients Computationally-intensive applications such as compilers with
Display
little or no data management
Data-intensive applications (browsing and querying) with little
or no application processing.
Two-tier C/S Applications where application processing is provided by
architecture with COTS (e.g. Microsoft Excel) on the client
fat clients Applications where computationally-intensive processing of
data (e.g. data visualisation) is required. Disadvantages of Distributed Object Architectures
Applications with relatively stable end-user functionality used
in an environment with well-established system management • Complex to design due to model generality and flexibility in
Three-tier or Large scale applications with hundreds or thousands of clients service provision.
multi-tier C/S Applications where both the data and the application are
architecture volatile. • C/S systems seem to be a more natural model for most
Applications where data from multiple sources are integrated systems. (They reflect many human service transactions.)
CORBA (Common Object Request Broker
Distributed Object Architectures Architecture)
• Eliminates the distinction between clients and servers. • International standards for an Object Request Broker (ORB):
middleware to manage communications between distributed
• System components are objects that provide services to, and objects.
receive services from, other objects.
• Several implementation of CORBA are available (Unix and
• Object communication is through middle-ware called an MS OS’s).
object request broker (effectively a software bus)
• Defined by the Object Management Group (>500
Distributed Object Architectures companies, including Sun, HP, IBM).
o1 o2 o3 o4
• DCOM (Distributed Component Object Model) is an
alternative standard developed and implemented by
S (o 1) S (o 2) S (o 3) S (o 4)
Microsoft.

S o ftw are bu s
Components of The OMG Vision of a Distributed
Application
o5 o6 • Application objects designed and implemented for this
S (o 5) S (o 6) application.

63
 ORB-based Object Communications
• Domain-specific objects defined by the OMG. (e.g., finance/
SOFTWARE ENGINEERING

insurance, healthcare)
• Fundamental CORBA distributed computing services such o1 o2
as directories and security management.
• Horizontal facilities (such as user interface facilities) used in S (o1) S (o2)
many different applications
COBRA Application Structure
IDL IDL
stub skeleton
Application Domain Horizontal
objects facilities CORBAfacilities
Object Request Broker

Object request broker

Inter-ORB Communications
• ORBs handle communications between objects executing on
the same machine.
CORBA services • Inter-ORB communications are used for distributed object
calls.
• CORBA supports ORB-to-ORB communication by
providing all ORBs access to all IDL interface definitions and
Major Elements of the CORBA Standards by implementing the OMG’s standard Generic Inter-ORB
• An application object model where objects encapsulate state Protocol (GIOP).
and have a well-defined, language-neutral interface defined in
Inter-ORB Communications
an IDL (interface definition language).
• An object request broker (ORB) that locates objects o1 o2 o3 o4
providing services, sends service requests, and returns results
to requesters. S (o1) S (o2) S (o3) S (o4)

• A set of general object services of use to many distributed

applications.
IDL IDL IDL IDL
• A set of common components built on top of these
services. (Task forces are currently defining these.)
Object Request Broker Object Request Broker
CORBA Objects
Network
• Objects that provide services have IDL skeletons that link
their interface to an implementation.
• Calling objects have IDL stubs for every object being called. Examples of General CORBA Services
• Objects do not need to know the location or • Naming and trading services : these allow objects to discover
implementation details of other objects. and refer to other objects on the network.

Object Request Broker (ORB) • Notification services : these allow objects to notify other
objects that an event has occurred.
• The ORB handles object communications. It knows of all
objects in the system and their interfaces.
• Transaction services : these support atomic transactions and
rollback on failure.
• The calling object binds an IDL stub that defines the
interface of the called object. Key Points
• Calling this stub results in calls to the ORB, which then calls • Almost all new large systems are distributed systems.
the required object through a published IDL skeleton that • Distributed systems support resource sharing, openness,
links the interface to the service implementation. concurrency, scalability, fault tolerance, and transparency.
• Client-server architectures involve services being delivered by
servers to programs operating on clients.
• User interface software always runs on the client and data
management on the server.
• In a distributed object architecture, there is no distinction
between clients and servers.

64
• Distributed object systems require middle-ware to handle Activity

SOFTWARE ENGINEERING
object communications. It is proposed to develop a system for stock information where
• The CORBA standards are a set of middle-ware standards dealers can access information about companies and can evaluate
that support distributed object architectures. various investment scenarios using a simulation system.
Different dealers use this simulation in different ways according
Activity
to their experience and the type of stocks that they are dealing
Explain why distributed systems are inherently more scalable with. Suggest a client-server architecture for this system that
than centralized systems. What are the likely limits on the shows where functionality is located justify the client server
scalability of the system? system model that you have chosen.

Activity
Activity Distributed systems based on a client-server model have been
What is the fundamental difference between a fat-client and a developed since the 1980s but it is only recently that system
thin-client approach to client-server systems development? architectures based on disrupted objects have been imple-
Explain why the use of Java as an implementation language mented. Suggest three reasons why this should be the case.
blurs the distinction between these approaches.

65
 Activity Activity
SOFTWARE ENGINEERING

Explain why the use of distributed objects with an object What are the basic facilities that must be provided by an object
request broker simplifies the implementation of scalable client- request broker?
server systems. Illustrate your answer with an example.

Activity
How is the CORBA IDL used to support communications
between objects that have been implemented in different
programming languages? Explain why this approach may cause
performance problems if there are radical differences between
the languages used for object implementation.

66
 UNIT II
DESIGN, VERIFICATION AND VALIDATION
LESSON 19 AND 20: UNIT 5
OBJECT-ORIENTED DESIGN CHAPTER 11

Objectives Object-oriented Development

SOFTWARE ENGINEERING
• To explain how a software design may be represented as a set • OO Analysis: concerned with developing an object model of
of interacting objects that encapsulate their own state and the application domain.
operations. • OO Design: concerned with developing an object-oriented
• To describe the activities in the object-oriented design process system model to implement requirements
• To introduce various models used to describe an object- • OO Programming: concerned with realising an OOD using
oriented design an OO programming language such as Java or C++.
• To show how the UML may be used to represent these Objects and Object Classes
models
• Objects are entities with state and a defined set of operations
Topics Covered on that state.
• Objects and object classes State is represented as a set of object attributes.
• An object-oriented design process Operations provide services to other objects when requested.
• Design evolution • Object classes are templates for objects.
An object class definition includes declarations of all attributes
Characteristics of OOD and operations associated with an object of that class.

• Allows designers to think in terms of interacting objects that They may inherit attributes and services from other object
maintain their own state and provide operations on that classes.
state instead of a set of functions operating on shared data. The Unified Modeling Language
• Objects hide information about the representation of state • Several different notations for OOD were proposed in the
and hence limit access to it. 1980s and 1990s. (Booch, Rumbaugh, Jacobson, Coad &
• Objects may be distributed and may work sequentially or in Yourdon, Wirfs, …)
parallel. • UML is an integration of these notations.
A design strategy based on “information hiding”… • It describes a number of different models that may be
• A useful definition of information hiding: produced during OO analysis and design (user view,
structural view, behavioural view, implementation view, …)
Potentially changeable design decisions are isolated
(i.e., “hidden”) to minimize the impact of change. Employee Object Class (UML)
- David Parnas
Interacting Objects
E m p loy ee
o1: C1 o3:C3 o4: C4
state o1 state o3 state o4 n am e : st ring
ops1() ops3 () ops4 () a dd re s s: s trin g
d at eO fB irt h : Dat e
e m ployee N o: inte ger
s ocialS ec urity No : s tring
o2: C3 o6: C1 o5:C5 d ep art men t : Dep t
state o2 state o6 state o5 ma na ger: E mploy ee
ops3 () ops1 () ops5 () s alary : in te ge r
s ta t us: {curren t, left, retire d}
t a xC od e: in te ger
Advantages of OOD . ..
• Easier maintenance. Objects may be join ()
understood as stand-alone entities. lea v e ()
• Objects are appropriate reusable components. re tire ()
• For some systems, there is an obvious mapping from real c ha nge Det ails ()
world entities to system objects.

67
 Object Communication • It is a reuse mechanism at both the design and the
SOFTWARE ENGINEERING

• Conceptually, objects communicate by message passing. programming level.

• Messages include: • The inheritance graph is a source of organisational
knowledge about domains and systems.
The name of the service requested,
A copy of the information required to carry out the service, and Problems With Inheritance
the name of a holder for the result of the service. • Object classes are not self-contained (i.e., they cannot be
understood without reference to their super-classes).
• In practice, messages are often implemented by procedure
calls • Designers have a tendency to reuse the inheritance graph
created during analysis. (Inheritance graphs of analysis,
Message Examples design and implementation have different functions.)
// Call a method associated with a buffer
// object that returns the next value Inheritance and OOD
// in the buffer v = circularBuffer. Get ( ); • Inheritance is a useful implementation concept, which allows
reuse of attribute and operation definitions.
// Call the method associated with a • Some feel that identifying an inheritance hierarchy or network
// thermostat object that sets the is also a fundamental part of object-oriented design.
// temperature to be maintained thermostat.setTemp (20); (Obviously, this can only be implemented using an OOPL.)
Generalization and Inheritance • Others feel this places unnecessary restrictions on the
implementation.
• Objects are members of classes, which define attribute types
and operations. • Inheritance introduces complexity and this is undesirable,
especially in critical systems.
• Classes may be arranged in a hierarchy where one class (a
super-class) is a generalization of one or more other classes UML Associations
(sub-classes) • Objects and object classes participate in various types of
• A sub-class inherits the attributes and operations from its relationships with other objects and object classes.
super class and may add new methods or attributes of its • In the UML, a generalized relationship is indicated by an
own. association.
A UML Generalisation Hierarchy • Associations may be annotated with information that
describes their nature.
• Associations can be used to indicate that an attribute of an
Employee object is an associated object or that a method relies on an
associated object.
An Association Model

Ma nager Programmer
Employee
is-member-of Department
budgetsControlled project
progLanguage
dateAppointed is-managed-by

manages
Manager

Project De pt. Strategic

Ma nag er Ma nager Ma nag er Concurrent Objects
• The nature of objects as self-contained entities make them
projects dept responsibilities
well suited for con-current implementation.
• The message-passing model of object
communication can be implemented directly if objects are
running on separate processors in a distributed system.
Advantages of Inheritance Concurrent object implementation: servers and
• It is an abstraction mechanism, which may be used to classify active objects
entities. • Servers (Passive objects): implemented as parallel processes
with entry points corresponding to object operations. If no

68
 calls are made to it, the object suspends itself and waits for Context of Weather Station

SOFTWARE ENGINEERING
further requests for service.
• Active objects: implemented as parallel processes and the «subsystem»
«subsystem»
Data collection
internal object state may be changed by the object itself and Data display
not simply by external calls. Observer Satellite
User Map
Example: An Active Transponder Object Comms interface display

Weather Map
• A transponder object broadcasts an aircraft’s position. station Balloon Map printer
• The object periodically updates the position by triangulation
from satellites. «subsystem» «subsystem»
Data processing Data archiving
An Object-oriented Design Process
Data
• Define the context and modes of use of the system. Data Data storage
checking integration
• Design the system architecture. Map store Data store

• Identify the principal system objects.

• Develop design models (static and dynamic). • Modes of system use : a dynamic model that describes how
• Specify object interfaces. the system will interact with its environment.
Weather System Description • Modes of weather station use are illustrated below using a
• A weather data collection system is required to generate UML use-case model.
weather maps on a regular basis using data collected from Use-cases for the Weather Station
remote, unattended weather stations and other data sources
such as weather observers, balloons and satellites. Weather
stations transmit their data to the area computer in response
to a request from that machine.
• The area computer validates the collected data and integrates
it with the data from different sources. The integrated data is
archived and, using data from this archive and a digitised
map database a set of local weather maps is created. Maps
may be printed for distribution on a special-purpose map
printer or may be displayed in a number of different
formats.
• A weather station is a package of software-controlled Use-case Description
instruments, which collects data, performs some data
processing and transmits this data for further processing. System
U s e -c a s e
W eather station
Report
The instruments include air and ground thermometers, an Actors W eather data collection system, W eather station
Data The weather station sends a summary of the weather
anemometer, a wind vane, a barometer and a rain gauge. data that has been collected from the instruments in the
Data is collected every five minutes. collection period to the weather data collection system.
The data sent are the maximum minimum and average
ground and air tem peratures, the m a x i m u m , m i n i m u m
• When a command is issued to transmit the weather data, the and average air pressures, the maximum, minimum and
weather station processes and summarises the collected data. average wind speeds, the total rainfall and the wind
direction as sampled at 5 minute intervals.
The summarised data is transmitted to the mapping Stimulus The weather data collection system establishes a
modem link with the weather station and requests
computer when a request is received. transmission of the data.
Response The summarised data is sent to the weather data
1.Define system context and modes of use collection system
Comments W eather stations are usually asked to report once per
• Goal: develop an understanding of the relationships hour but this frequency may differ from one station to
the other and may be modified in future.
between the software being designed and its external
environment.
• System context: a static model that describes other systems 2. Design System Architecture
in the environment. • A layered architecture is appropriate for the weather station:
• The context of the weather station is illustrated below using Interface layer : for handling communications
UML packages. Data collection layer : for managing instruments
Instruments layer : for collecting data
• Rule of Thumb: There should be no more than 7 entities in
an architectural model.

69
 Weather Station Architecture Other Objects And Object Refinement
SOFTWARE ENGINEERING

• Use domain knowledge to identify more objects, operations,

Weather station
and attributes.
«subsy stem»
Manages all
external
Weather stations should have a unique identifier.
Interface communications
Weather stations are remotely situated so instrument failures
Collects and have to be reported automatically. Therefore, attributes and
«subsy st em» summarises
Da ta collection weather data operations for self checking are required.

Package of
• Active or passive objects?
«subsy stem»
I nst ruments
instruments for raw
data collections Instrument objects are passive and collect data on request rather
than autonomously. This introduces flexibility (how?) at the
expense of controller processing time.
UML “nested packages” UML annotations
Are any active objects required?
3. Identify Principal System Objects
4. Develop Design Models
• Identifying objects (or object classes) is the most difficult
part OO design. • Design models show the relationships among objects and
object classes.
• There is no “magic formula” – it relies on the skill,
experience, and domain knowledge of system designers • Static models describe the static structure of the system in
terms of object and object class relationships.
• An iterative process – you are unlikely to get it right the first
time. • Dynamic models describe the dynamic interactions among
objects.
Approaches to Object Identification
Examples of Design Models
• Use a grammatical approach based on a natural language
description of the system (Abbott’s heuristic). • Sub-system models show logical groupings of objects into
coherent sub-systems. (static)
• Associate objects with tangible things in the application
domain (e.g. devices). • Sequence models show the sequence of object interactions
associated with system uses. (dynamic)
• Use a behavioural approach: identify objects based on what
participates in what behaviour. • State machine models show how individual objects change
their state in response to events. (dynamic)
• Use scenario-based analysis. The objects, attributes and
methods in each scenario are identified. • Other models include use-case models, aggregation models,
generalisation (inheritance) models, etc.
• Use an information-hiding based approach. Identify
potentially change-able design decisions and isolate these in Subsystem Models
separate objects. • In the UML, these are shown using packages, an
Weather Station Object Classes encapsulation construct.

• Weather station : interface of the weather station to its • This is a logical model – the actual organization of objects in
environment. It reflects interactions identified in the use-case the system as implemented may be different.
model. Weather Station Subsystems
• Weather data : encapsulates summarised data from the
instruments. -Annotations
• Ground thermometer, Anemometer, Barometer : application «subsystem»
Interface
«subsystem»
Da ta collection
domain “hardware” objects related to the instruments in the
system
CommsController WeatherData
Weather Station Object Classes

Instrument
Weath erS tati on W eath erD ata WeatherStation Status
identifier airTem peratures
groundTem peratures
report Weather () win dS peeds
c alibrate (inst rument s) win dDirec tions
t est () pres sures
s tart up (ins trum ents ) rainfall «subsystem»
s hutdow n (ins trum ents )
c ollect () Instruments
sum maris e ()
Air
thermometer RainGauge Anemometer
G rou nd An em o m eter Ba rom eter
the rm o m eter pres sure
win dS peed
tem perat ure win dDirec tion height
Ground
tes t ()
tes t () test () thermometer Barometer WindVane
c alibrate () c alibrate ()

70
Sequence Models Changes Required

SOFTWARE ENGINEERING
• Objects are arranged horizontally across the top. • Add an object class called “Air quality” as part of Weather
• Time is represented vertically; models are read top to Station
bottom. • Add an operation reportAirQuality to WeatherStation.
• Interactions are represented by labelled arrows - different Modify the control software to collect pollution readings
styles of arrows represent different types of interaction. • Add objects representing pollution monitoring instruments.
• A thin rectangle in an object lifeline represents the time when Pollution Monitoring
the object is the controlling object in the system.
Data collection sequence
W e a t h e rS t a t i o n
A i r q u a l it y
id e n t ifie r
NO Data
re p o rt W e a t h e r () s m o k e D a ta
r e p o r t A ir Q u a lity ( ) b e n z e n e D a ta
c a lib r a te ( in st r u m e n t s)
t e st ( ) c o lle ct ( )
s ta r t u p ( in s tr u m e n ts ) su m m a r is e ( )
sh u t d o w n ( in s tr u m e n t s)

P o ll u t io n m o n it o ri n g i n s t r u m e n t s

NO meter S m o ke M e te r

B enz eneMeter

Weather Station State Machine Model

Key Points
Operation calibrate () Calibrating
• OOD results in design components with their own private
state and operations.
calibration OK
startup () Waiting test () Testing
• Objects should have constructor and inspection operations.
Shutdown
They provide services to other objects.
shutdown () transmission done test complete
• Objects may be implemented sequentially or concurrently.
Transmitting
clock collection • The Unified Modeling Language provides different notations
done reportWeather ()
for defining different object models.
weather summary
complete
Summarising • A range of different models may be produced during an
Collecting
object-oriented design process. These include static and
dynamic system models
• Object interfaces should be defined precisely.
5. Object Interface Specification
• Object-oriented design simplifies system evolution.
• Designers should avoid revealing data representation
information in their interface design. (operations access and Activity
update data) Explain why adopting an approach to design that is based on
loosely coupled objects that hide information about their
• Objects may have several logical interfaces, which are representation should lead to a design which may be readily
viewpoints on the methods provided. (supported directly in modified.
Java)
• The UML uses class diagrams for interface specification but
pseudocode may also be used.
Design Evolution
• Hiding information in objects means that changes made to
an object do not affect other objects in an unpredictable way.
• Assume pollution-monitoring facilities are to be added to
weather stations.
• Pollution readings are transmitted with weather data.

71
 Activity Activity
SOFTWARE ENGINEERING

Using examples, explain the difference between an object and an Using the UML graphical notation for object classes, design the
object class. following object classes identifying attributes and operations.
Use your own experience to decide on the attributes and
operations that should be associated with these objects:
• A telephone:
• A printer for a personal computer;
• A personal stereo system;
• A bank account;
• A library catalogue.

Activity
Under what circumstances might it be appropriate to develop a
design where objects execute concurrently?

Activity
Develop the design of the weather station to show the
interaction between the data collection sub- system and the
instruments that collect weather data. Use sequence charts to
show this interaction.

72
 SOFTWARE ENGINEERING
Activity
Identify possible objects in the following systems and develop
an object oriented design for them. You may make any
reasonable assumptions about the systems when deriving the Activity
design. Draw a sequence diagram showing the interactions of objects in
• A group diary and time management system is intended to a group diary system when a group of people arrange a meeting.
support the timetabling of meetings and appointments
across a group of co-workers. When an appointment is to be
made which involves a number of people, the system finds a
common slot in each of their diaries and arranges the
appointment for that time. If no common slots are
available, it interacts with the users to rearrange their personal
diaries to make room fort the appointment.
• A petrol (gas) station is to be set up for fully automated
operation. Derivers swipe their credit card through a reader
connected to the pump; the card is verified by
communication with a credit company computer and a fuel
limit established. The driver may then take the fuel required
when fuel delivery is complete and the pump hose is
returned to its holster, the driver’s credit card account is
debited with the cost to the furl taken. The credit card is
returned after debiting. If the card is invalid, it is returned
buy the pump before fuel is dispensed.

73
 UNIT II
DESIGN, VERIFICATION AND VALIDATION
LESSON 21 AND 22:
REAL-TIME SOFTWARE DESIGN CHAPTER 12

Designing Embedded Software Systems Whose Architectural Considerations

SOFTWARE ENGINEERING

Behaviour is Subject to Timing Constraints • Because of the need to respond to timing demands made by
Objectives different stimuli/responses, the system architecture must
allow for fast switching between stimulus handlers
• To explain the concept of a real-time system and why these
systems are usually implemented as concurrent processes • Timing demands of different stimuli are different so a
simple sequential loop is not usually adequate
• To describe a design process for real-time systems
• To explain the role of a real-time executive
• Real-time systems are usually designed as cooperating
processes with a real-time executive controlling these
• To introduce generic architectures for monitoring and control processes
and data acquisition systems
A Real-time System Model
Topics Covered
• Systems design
Sensor Sensor Sensor Sensor Sensor Sensor
• Real-time executives
• Monitoring and control systems
• Data acquisition systems
Real-time
Real-time Systems control system

• Systems, which monitor and control their environment

• Inevitably associated with hardware devices
Actuator Actuator Actuator Actuator
Sensors: Collect data from the system environment
Actuators: Change (in some way) the system’s environment
• Time is critical. Real-time systems MUST respond within System Elements
specified times
• Sensors control processes
Definition Collect information from sensors. May buffer information
• A real-time system is a software system where the correct collected in response to a sensor stimulus
functioning of the system depends on the results produced • Data processor
by the system and the time at which these results are
Carries out processing of collected information and computes
produced
the system response
• A ‘soft’ real-time system is a system whose operation is • Actuator control
degraded if results are not produced according to the
specified timing requirements Generates control signals for the actuator
• A ‘hard’ real-time system is a system whose operation is Sensor/Actuator Processes
incorrect if results are not produced according to the timing
specification Sen so r Actuator
Stimulus/Response Systems
• Given a stimulus, the system must produce a response St imu lu s Resp on se
within a specified time
Sen so r Data Actuator
• Periodic stimuli. Stimuli, which occur at predictable time con tro l p ro cesso r con tro l
intervals
For example, a temperature sensor may be polled 10 times per
second
System Design
• A periodic stimuli. Stimuli, which occur at unpredictable
times • Design both the hardware and the software associated with
system. Partition functions to either hardware or software
For example, a system power failure may trigger an interrupt,
which must be processed by the system • Design decisions should be made on the basis on non-
functional system requirements

74
• Hardware delivers better performance but potentially longer Microwave Oven State Machine

SOFTWARE ENGINEERING
development and less scope for change
Full
Hardware and Software Design power Full power
do: set power
= 600

Timer
Waiting
Es t ab lis h s ys tem do: display
Number
Full Set time Operation
requ irement s time
power do: get number do: operate
exit: set time oven
Half
Half power
Door
power Cancel
Timer closed
Door Start
open System
Parti ti on Half power Enabled fault Waiting
do: set power do: display
requ irement s = 300
Door
closed
do: display
'Ready' time

Disabled
do: display
'Waiting'

S o ftware Hardw are

requ ir em ent s requ irem ent s
Real-time Programming
• Hard-real time systems may have to programmed in
S o ftware Hardw are assembly language to ensure that deadlines are met
d es ig n d es ig n • Languages such as C allow efficient programs to be written
but do not have constructs to support concurrency or shared
resource management
R-t Systems Design Process • Ada as a language designed to support real-time systems
design so includes a general-purpose concurrency mechanism
• Identify the stimuli to be processed and the required
responses to these stimuli Java As A Real-time Language
• For each stimulus and response, identify the timing • Java supports lightweight concurrency (threads and
constraints synchronized methods) and can be used for some soft real-
• Aggregate the stimulus and response processing into time systems
concurrent processes. • Java 2.0 is not suitable for hard RT programming or
• A process may be associated with each class of stimulus and programming where precise control of timing is required
response Not possible to specify thread execution time
• Design algorithms to process each class of stimulus and Uncontrollable garbage collection
response. These must meet the given timing requirements Not possible to discover queue sizes for shared resources
• Design a scheduling system, which will ensure that processes Variable virtual machine implementation
are started in time to meet their deadlines
Not possible to do space or timing analysis
• Integrate using a real-time executive or operating system
Real-time Executives
Timing Constraints
• Real-time executives are specialised operating systems, which
• May require extensive simulation and experiment to ensure manage the processes in the RTS
that these are met by the system
• Responsible for process management and resource
• May mean that certain design strategies such as object- (processor and memory) allocation
oriented design cannot be used because of the additional
• May be based on a standard RTE kernel which is used
overhead involved
unchanged or modified for a particular application
• May mean that low-level programming language features • Does not include facilities such as file management
have to be used for performance reasons
Executive Components
State Machine Modelling
• Real-time clock
• The effect of a stimulus in a real-time system may trigger a
transition from one state to another. Provides information for process scheduling.
• Finite state machines can be used for modelling real-time • Interrupt handler
systems. Manages aperiodic requests for service.
• However, FSM models lack structure. Even simple systems • Scheduler
can have a complex model. Chooses the next process to be run.
• The UML includes notations for defining state machine • Resource manager
models
Allocates memory and processor resources.

75
 • Despatcher Process Management
SOFTWARE ENGINEERING

Starts process execution. • Concerned with managing the set of concurrent processes
Non-stop System Components • Periodic processes are executed at pre-specified time intervals
• Configuration manager • The executive uses the real-time clock to determine when to
execute a process
Responsible for the dynamic reconfiguration of the system
software and hardware. Hardware modules may be replaced and • Process period - time between executions
software upgraded without stopping the systems • Process deadline - the time by which processing must be
• Fault manager complete
Responsible for detecting software and hardware faults and RTE Process Management
taking appropriate actions (e.g. switching to backup disks) to Scheduler Reso urce m ana ger Despa tcher
ensure that the system continues in operation Ch oo se p ro cess Allocate m em ory Start executio n on an
fo r executio n and p ro cesso r av ailab le pro cesso r
Real-time Executive Components
Process Switching
Sch edulin g
info rmat io n • The scheduler chooses the next process to be executed by the
processor. This depends on a scheduling strategy, which may
R eal-tim e
Sch eduler Inte rrup t take the process priority into account
c lo ck h an dl er
• The resource manager allocates memory and a processor for
the process to be executed
Pro ce s s reso urce
requ irem ent s
• The despatcher takes the process from ready list, loads it
onto a processor and starts execution
Pro ces ses Avail able
awaitin g Reso ur ce
reso urces manag er
reso urce
l is t Scheduling Strategies
Releas e d
R eady
pro ce s ses reso urces • Non pre-emptive scheduling
R eady Pro ce s so r
lis t
De s pat ch er
l is t Once a process has been scheduled for execution, it runs to
Ex ecutin g completion or until it is blocked for some reason (e.g. waiting
p ro ces s
for I/O)
• Pre-emptive scheduling
Process Priority The execution of executing processes may be stopped if a
• The processing of some types of stimuli must sometimes higher priority process requires service
take priority • Scheduling algorithms
• Interrupt level priority. Highest priority, which is allocated to Round-robin
processes requiring a very fast response
Rate monotonic
• Clock level priority. Allocated to periodic processes
Shortest deadline first
• Within these, further levels of priority may be assigned
Monitoring and Control Systems
Interrupt Servicing
• Important class of real-time systems
• Control is transferred automatically to a pre-determined
memory location
• Continuously check sensors and take actions depending on
sensor values
• This location contains an instruction to jump to an interrupt
service routine
• Monitoring systems examine sensors and report their results
• Further interrupts are disabled, the interrupt serviced and • Control systems take sensor values and control
hardware actuators
control returned to the interrupted process
• Interrupt service routines MUST be short, simple and fast Burglar Alarm System

Periodic Process Servicing

• A system is required to monitor sensors on doors and
windows to detect the presence of intruders in a building
• In most real-time systems, there will be several classes of
periodic process, each with different periods (the time
• When a sensor indicates a break-in, the system switches on
lights around the area and calls police automatically
between executions), execution times and deadlines (the time
by which processing must be completed) • Sensors
• The real-time clock ticks periodically and each tick causes an Movement detectors, window sensors, door sensors.
interrupt which schedules the process manager for periodic 50 window sensors, 30 door sensors and 200 movement
processes detectors
• The process manager selects a process, which is ready for Voltage drop sensor
execution

76
• Actions Building Monitor Process 1

SOFTWARE ENGINEERING
When an intruder is detected, police are called automatically.
Lights are switched on in rooms with active sensors. // See http://www.software-engin.com/ for links to the complete Java code for this
// example
An audible alarm is switched on.
class BuildingMonitor extends Thread {
The system switches automatically to backup power when a
voltage drop is detected. BuildingSensor win, door, move ;

The R-T System Design Process Siren siren = new Siren () ;

Lights lights = new Lights () ;
• Identify stimuli and associated responses Synthesizer synthesizer = new Synthesizer () ;
DoorSensors doors = new DoorSensors (30) ;
• Define the timing constraints associated with each stimulus WindowSensors windows = new WindowSensors (50) ;
and response MovementSensors movements = new MovementSensors (200) ;
PowerMonitor pm = new PowerMonitor () ;
• Allocate system functions to concurrent processes
BuildingMonitor()
• Design algorithms for stimulus processing and response {
generation // initialise all the sensors and start the processes
siren.start () ; lights.start () ;
• Design a scheduling system, which ensures that processes synthesizer.start () ; windows.start () ;
doors.start () ; movements.start () ; pm.start () ;
will always be scheduled to meet their deadlines
Stimuli to be Processed }

• Power failure
Generated aperiodically by a circuit monitor. When received, the Building Monitor Process 2
system must switch to backup power within 50ms
• Intruder alarm
public void run ()
Stimulus generated by system sensors. Response is to call the {
police, switch on building lights and the audible alarm int room = 0 ;
while (true)
Timing Requirements {
// poll the movement sensors at least twice per second (400 Hz)
move = movements.getVal () ;
// poll the window sensors at least twice/second (100 Hz)
Stim ulus /R esp ons e T imi ng re qu ir eme nts
Pow er fai l interr upt The sw itch to bac kup p ower m ust be co mp leted win = windows.getVal () ;
w ithin a dea dline of 5 0 ms . // poll the door sensors at least twice per second (60 Hz)
D oor ala rm Eac h door ala rm sh ould be polled twice per door = doors.getVal () ;
sec ond. if (move.sensorVal == 1 | door.sensorVal == 1 | win.sensorVal == 1)
W indow ala rm Eac h w indow ala rm sh ould be poll ed twice per {
sec ond. // a sensor has indicated an intruder
Movem en t detec tor Eac h mo ve m ent de tect or s hould be polle d tw ice if (move.sensorVal == 1) room = move.room ;
per s eco nd. if (door.sensorVal == 1) room = door.room ;
A udible ala rm The a udibl e alarm should b e sw itche d o n w ithin if (win.sensorVal == 1 ) room = win.room ;
1/2 s eco nd of an a larm be ing r aised by a s ensor .
Li ghts sw it ch The l ights sh ould be s witc hed on w ithi n 1 /2 lights.on (room) ; siren.on () ; synthesizer.on (room) ;
sec ond o f an ala rm b eing rais ed by a sens or. break ;
Comm unica tions The ca ll to th e police sh ould be s ta rted w ithin 2
}
sec onds o f an ala rm being rais ed by a sens or.
}
V oice sy nt hesi ser A synthesised m ess age sh ould be avai lab le
w ithin 4 s ec onds of an a larm be ing r ai se d by a lights.shutdown () ; siren.shutdown () ; synthesizer.shutdown () ;
sens or. windows.shutdown () ; doors.shutdown () ; movements.shutdown () ;

} // run
} //BuildingMonitor
Process Architecture

4 00 Hz 6 0Hz 1 00 Hz
Control Systems
Movement Door senso r W ind ow sen so r
d etecto r pro cess p ro cess p ro cess • A burglar alarm system is primarily a monitoring system. It
Detector s tatus Senso r status Sen so r status collects data from sensors but no real-time actuator control
560 Hz Alar m s ystem • Control systems are similar but, in response to sensor
Bu ilding monitor Co mmu nicatio n
values, the system sends control signals to actuators
p ro cess p ro cess

Power failu re
• An example of a monitoring and control system is a system,
interru pt Bu ilding mon itor Roo m numb er
which monitors temperature and switches heaters on and off
Pow er switch Alarm sys tem
p ro cess pro cess Alert mess ag e

Ro om nu mber
Alarm Alarm Alarm system
system system Ro om nu mber
Au dible alarm Lighting co ntrol Voice synth esizer
p ro cess pro cess p ro ces s

77
 A Temperature Control System • Producer and consumer processes must be mutually
SOFTWARE ENGINEERING

excluded from accessing the same element.

500Hz • The buffer must stop producer processes adding
information to a full buffer and consumer processes trying
Sensor
process to take information from an empty buffer.
Java Implementation of a Ring Buffer 1
Sensor
500Hz values

Thermostat class CircularBuffer

process {
int bufsize ;
Switch command SensorRecord [] store ;
500Hz Room number Thermostat process int numberOfEntries = 0 ;
int front = 0, back = 0 ;
Heater control Furnace
process control process CircularBuffer (int n) {
bufsize = n ;
store = new SensorRecord [bufsize] ;
} // CircularBuffer
Data Acquisition Systems
synchronized void put (SensorRecord rec ) throws InterruptedException
• Collect data from sensors for subsequent processing and {
analysis. if ( numberOfEntries == bufsize)
wait () ;
• Data collection processes and processing processes may have store [back] = new SensorRecord (rec.sensorId, rec.sensorVal) ;
different periods and deadlines. back = back + 1 ;
if (back == bufsize)
• Data collection may be faster than processing e.g. collecting back = 0 ;
information about an explosion. numberOfEntries = numberOfEntries + 1 ;
notify () ;
• Circular or ring buffers are a mechanism for smoothing } // put
speed differences.
Reactor Data Collection
Java Implementation of a Ring Buffer 2
• A system collects data from a set of sensors monitoring the
neutron flux from a nuclear reactor.
synchronized SensorRecord get () throws InterruptedException
• Flux data is placed in a ring buffer for later processing. {
SensorRecord result = new SensorRecord (-1, -1) ;
• The ring buffer is itself implemented as a concurrent process if (numberOfEntries == 0)
so that the collection and processing processes may be wait () ;
synchronized. result = store [front] ;
front = front + 1 ;
Reactor Flux Monitoring if (front == bufsize)
Sen sors (each dat a flow is a sensor valu e) front = 0 ;
Senso r numberOfEntries = numberOfEntries - 1 ;
Processed
identifier and notify () ;
flux level
value
Sensor Sensor data Process return result ;
Display
pro cess buffer data
} // get
} // CircularBuffer

A Ring Buffer Key Points

• Real-time system correctness depends not just
Producer on what the system does but also on how fast it
process reacts
• A general RT system model involves associating processes
Consumer with sensors and actuators
process
• Real-time systems architectures are usually designed as a
number of concurrent processes
• Real-time executives are responsible for
process and resource management.
Mutual Exclusion • Monitoring and control systems poll sensors and send
control signal to actuators
• Producer processes collect data and add it to the buffer.
Consumer processes take data from the buffer and make • Data acquisition systems are usually organised according to a
elements available producer consumer model

78
• Java has facilities for supporting concurrency but is not Activity

SOFTWARE ENGINEERING
suitable for the development of time-critical systems Draw state machine models of the control software for the
following systems:
Activity
Using examples, explain why real time systems usually have to • An automatic washing machine, which has different
be implemented using processes. programs for different types of clothes.
• The software for a compact disc player.
• A telephone answering machine, which records incoming
messages and displays the number of accepted messages on
an LED display. The system should allow the telephone
owner to dial in, type a sequence of numbers (identified as
tones) and have the recorded messages replayed over the
phone.
• A drinks vending machine, which can dispense coffee with
and without milk and sugar. The user deposits a coin and
makes his or her selection by pressing a button on the
machine. This causes a cup with powdered coffee to be
output. The user places this cup under a tap, presses another
button and hot eater is dispensed.

Activity
Explain why an object oriented approach to software develop-
ment may not be suitable for real time systems.

Activity
Discuss the strengths and weaknesses of Java as a program-
ming language for real time systems.

79
SOFTWARE ENGINEERING

Activity
You are asked to work on a real-time development project for a
military application but have no previous experience of projects
in that domain. Discuss what you, as a professional software
engineer, should do before starting work on the project.

Notes:

80
 UNIT II
DESIGN, VERIFICATION AND VALIDATION
LESSON 23:
DESIGN WITH REUSE CHAPTER 13

Objectives Reuse Problems

SOFTWARE ENGINEERING
• To explain the benefits and some potential problems with • Increased maintenance costs – especially if source code /
software reuse. documentation absent.
• To describe different types of reusable elements and • Lacks of tool support – CASE toolsets do not support
processes for reuse. development with reuse.
• To introduce application families as a route to reuse. • Not-invented-here syndrome
• To describe design patterns as high-level abstractions that • Repositories of reusable elements – techniques for
promote reuse. classifying, cataloguing, and retrieving elements are
immature.
Topics Covered
• Component-based development
• Finding, understanding, and adapting reusable elements
takes time.
• Application families
Component-based Development
• Design patterns
• Component-Based Software Engineering (CBSE) is a
Reuse-based Software Engineering development approach based on systematic reuse.
• In most engineering disciplines, systems are routinely • CBSE emerged in the late 1990’s due to failure of OO
designed by composing elements that have been used in development to lead to extensive reuse.
other systems.
• Components are designed to be general service providers.
• This has not been true in SE, but to reduce risks and
accelerate development, it is now recognized that we need to Critical Characteristics of a Reusable Component
adopt design processes based on systematic reuse. • An independent executable entity: source code is typically not
available so the component is not compiled with other
Software Reuse Practice
system elements.
• Application system reuse : widely practised as software
systems are implemented as application families. COTS
• All interactions are through a published (2-part) interface :
internal state is never exposed.
reuse is becoming increasingly common.
• Component reuse : now seen as the key to effective and Component Interface
widespread reuse through Component-Based Software • “Provides interface” : defines the services that are provided
Engineering (CBSE). However, it is still relatively immature. by the component to other system elements.
• Function reuse : libraries of reusable functions have been • “Requires interface” : defines the services that must be made
common for 40 years. available to the component by other system elements in
Benefits of Reuse order to operate.

• Increased reliability : when reused elements have been tried Component Interfaces
and tested in a variety of working systems. Component
Requires interface Provides interface
• Reduced process risk : less uncertainty of cost compared to
new development.
• More effective use of specialists : re-use elements instead of
experts.
• Standards compliance : when standards are embedded in
reusable elements. Printing Services Component
• Accelerated development : reduced development and
validation time. Requires interface PrintService Provides interface

Requirements for Design with Reuse Printer description GetPDfile

Print
GetQueue
• Must be possible to find appropriate reusable elements.
Control interface PrinterInt Remove
• Must be confident that the elements will be reliable and will Transfer
behave as specified. Register

• Elements must be documented so that they can be Unregister

understood and, when necessary, modified.

81
 Component Abstraction Levels • Configuration specialization : different versions of the
SOFTWARE ENGINEERING

• Functional abstraction : implements a single function (e.g., application are created to handle different peripheral devices.
square root) • Functional specialization : different versions of the
• Casual groupings : loosely related entities such as data application are created for customers with different
declarations and functions requirements.
• Data abstractions : a data abstraction or object class Family Member Development
• Cluster abstractions : related object classes that work together Re-negotiate
requirements
• System abstraction : an entire, self-contained system (e.g., MS
Elicit Choose closest-
Excel) stakeholder fit family
requirements member Adapt existing Deliver new
CBSE Processes system family member

• Component-based reuse may be opportunistic, or it may

drive the development process.
• In reuse-driven development, system requirements are Use existing family member as prototype
modified to reflect the available components.
Design Patterns (Chris Alexander, Mid-70’s)
• CBSE often involves an evolutionary development process
with components being “glued together” using a scripting
• A way of reusing “accumulated knowledge and wisdom”
about a problem and its solution.
language. (e.g., Unix shell, Visual Basic, TCL/TK)
• A design pattern is a description of some problem and the
An Opportunistic Reuse Process essence of its solution.
Des ign Search fo r Incorpo rate
s ystem
Sp ecify
reus able dis covered
• Should be sufficiently abstract to be reusable in different
compon ents
aachitecture components compon ent s contexts.
• Often utilize OO characteristics such as inheritance and
the “we might get lucky” approach
polymorphism.
Reuse-driven Development
Pattern Elements (Gamma, ‘95)
• Name: a meaningful pattern identifier
Modify requirements
Outline Search for according to • Problem description
system reusable discovered
requirements components • Solution description: a template for a design solution that
components
can be instantiated in different operational contexts (often
illustrated graphically)
• Consequences: the results and trade-offs of applying the
Specify system pattern (analysis and experience)
Search for components
Architectural
reusable based on reusable The Observer Pattern (Details: P. 323)
design
components components
• Name: Observer
• Description: Separates the display of object state from the
object itself.
CBSE Problems
• Problem description: Used when multiple displays of state
• Component incompatibilities : may mean that cost and are needed.
schedule savings are less than expected.
• Solution description: See UML description
• Finding and understanding components : repositories and
tool support are lacking. • Consequences: Optimisations to enhance display
performance are impractical.
• Managing evolution as requirements change : source code is
typically not available. (“waiting for the next release”) Multiple Displays
Application Families
50
• An application family or product line is a related set of D
A 25
applications that has a common, domain-specific architecture. C
A B C D
B 0
• The common core of the application family is reused each
time a new application is required.
• Each specific application is specialized in some way. Su bj ect
Application Family Specialization Ob s erv er 1 A: 40 Ob s erv er 2
• Platform specialization : different versions of the application B: 25
C: 15
are developed for different platforms. D: 20

82
The Observer Pattern Activity

SOFTWARE ENGINEERING
Explain why the savings in cost form reusing existing software
Subject Observer is not simple proportional to the size of the components that
Attach (Observer)
Detach (Observer)
Update () are reused.
Notify () for all o in observers
o -> Update ()

ConcreteSubject ConcreteObserver

GetState () Update () observerState =

return subjectState subject -> GetState ()
subjectState observerState

Key Points
• Design with reuse involves designing software around
existing examples of good design and making use of
existing software elements.
• Advantages are lower costs, faster software development,
and lower risks.
• CBSE relies on black-box components with defined requires-
and provides- interfaces.
• Software components for reuse should be independent,
reflect stable domain abstractions, and provide access to state
through interface operations.
• COTS product reuse is concerned with the reuse of large-
scale, off-the-shelf systems.
• Application families are related applications that have a
common, domain-specific architecture.
• Design patterns are high-level abstractions that document
successful design solutions.
Activity
What are the major technical and non-technical factors which Activity
hinder software reuse? Form your own experience, do you reuse Give four circumstances where you might recommend against
much software? If not, why not? software reuse.

83
 Activity Activity
SOFTWARE ENGINEERING

Suggest possible requires and provides interfaces for the Why are patterns an effective form of design reuse? What are
following components: the disadvantages to this approach to reuse?
• A component implementing a bank account.
• A component implementing a language-independent
keyboard. Keyboards in different countries have different key
organizations and different character sets.

Activity
The reuse of software raises a number of copyright and
intellectual property issues. If a customer pays a software
Activity contractor to develop some system, who has the right to reuse
What is the difference between an application framework and a the developed code? Does the software contractor have the right
COTS product as for as reuse is concerned? Why is it some- to use that code as a basis for a generic component? What
times easier to reuse a COTS product than an application payment mechanisms might be used to reimburse providers of
framework? reusable components? Discuss these issues and other ethical
issues associated with the reuse of software.

84
 UNIT II
DESIGN, VERIFICATION AND VALIDATION
LESSON 24 AND 25:
USER INTERFACE DESIGN CHAPTER 14

Designing Effective Interfaces for Software Systems Information remains visible in its own window when attention

SOFTWARE ENGINEERING
is switched.
Objectives
• Fast, full-screen interaction is possible with immediate access
• To suggest some general design principles for user interface
to anywhere on the screen
design
• To explain different interaction styles User-centred Design
• To introduce styles of information presentation • The aim of this chapter is to sensitise software engineers to
key issues underlying the design rather than the
• To describe the user support which should be built-in to
implementation of user interfaces
user interfaces
• To introduce usability attributes and system approaches to
• User-centred design is an approach to UI design where the
needs of the user are paramount and where the user is
system evaluation
involved in the design process
Topics Covered • UI design always involves the development of prototype
• User interface design principles interfaces
• User interaction User Interface Design Process
• Information presentation
• User support
Analyse and Produce paper-
• Interface evaluation understand user based design
Evaluate design
with end-users
activities prototype
The User Interface
• System users often judge a system by its Produce
Design Evaluate design
interface rather than its functionality prototype
dynamic design
with end-users
prototype
• A poorly designed interface can cause a user to
make catastrophic errors Executable Implement
prototype final user
• Poor user interface design is the reason why so interface

many software systems are never used

Graphical User Interfaces UI Design Principles
• Most users of business systems interact with these systems • UI design must take account of the needs, experience and
through graphical interfaces although, in some cases, legacy capabilities of the system users
text-based interfaces are still used • Designers should be aware of people’s physical and mental
GUI Characteristics limitations (e.g. limited short-term memory) and should
recognise that people make mistakes
Characteristic Description
Windows Multiple windows allow different information to be
• UI design principles underlie interface designs although not
displayed simultaneously on the user’s screen. all principles are applicable to all designs
Icons Icons different types of information. On some systems,
icons represent files; on others, icons represent Design Principles
processes.
Menus Commands are selected from a menu rather than typed • User familiarity
in a command language.
Pointing A pointing device such as a mouse is used for selecting
The interface should be based on user-oriented terms and
choices from a menu or indicating items of interest in a concepts rather than computer concepts. For example, an office
window.
system should use concepts such as letters, documents, folders
Graphics Graphical elements can be mixed with text on the same
display. etc. rather than directories, file identifiers, etc.
• Consistency
GUI Advantages The system should display an appropriate level of consistency.
• They are easy to learn and use. Commands and menus should have the same
Users without experience can learn to use the system quickly. • Minimal surprise
• The user may switch quickly from one task to If a command operates in a known way, the user should be able
another and can interact with several different applications. to predict the operation of comparable commands
• Recoverability

85
 The system should provide some resilience to user errors and Menu Systems
SOFTWARE ENGINEERING

allow the user to recover from errors. This might include an • Users make a selection from a list of
undo facility, confirmation of destructive actions, ‘soft’ deletes, possibilities presented to them by the system
etc.
• The selection may be made by pointing and
• User guidance clicking with a mouse, using cursor keys or by
Some user guidance such as help systems, on-line manuals, etc. typing the name of the selection
should be supplied • May make use of simple-to-use terminals such as touch
• User diversity screens
Interaction facilities for different types of user should be Advantages of Menu Systems
supported. For example, some users have seeing difficulties and • Users need not remember command names as they are
so larger text should be available always presented with a list of valid commands
Format, command punctuation should be similar, etc. • Typing effort is minimal
User-system Interaction • User errors are trapped by the interface
• Two problems must be addressed in interactive systems • Context-dependent help can be provided. The user’s context
design is indicated by the current menu selection
How should information from the user be provided to the Problems With Menu Systems
computer system?
• Actions which involve logical conjunction (and) or
How should information from the computer system be disjunction (or) are awkward to represent
presented to the user?
• Menu systems are best suited to presenting a small number
• User interaction and information presentation may be of choices. If there are many choices, some menu structuring
integrated through a coherent framework such as a user facility must be used
interface metaphor
• Experienced users find menus slower than command
Interaction Styles language
• Direct manipulation Form-based Interface
• Menu selection
• Form fill-in NE W BOOK
• Command language Titl e ISBN
• Natural language
Author Price
Direct Manipulation Advantages
Publicatio n
Pub lisher
• Users feel in control of the computer and are less likely to be date
Number o f
intimidated by it Edition copies
• User learning time is relatively short Classification Loan
• Users get immediate feedback on their actions so mistakes status
Dat e of
can be quickly detected and corrected purchase
Ord er
status

Direct Manipulation Problems

• The derivation of an appropriate information space model
can be very difficult Command Interfaces
• Given that users have a large information space, what • User types commands to give instructions to the system e.g.
facilities for navigating around that space should be UNIX
provided? • May be implemented using cheap terminals.
• Direct manipulation interfaces can be complex to program • Easy to process using compiler techniques
and make heavy demands on the computer system
• Commands of arbitrary complexity can be created by
Control Panel Interface command combination
• Concise interfaces requiring minimal typing can be created
Title JSD. example Grid Busy Problems With Command Interfaces
Method JSD • Users have to learn and remember a command language.
OUIT
Type Network Units cm Command interfaces are therefore unsuitable for occasional
Selection Process Reduce Full users
PRINT
• Users make errors in command. An error detection and
NODE LINKS FONT LABEL EDIT
recovery system is required

86
• System interaction is through a keyboard so typing ability is Information Presentation

SOFTWARE ENGINEERING
required • Static information
Command Languages Initialised at the beginning of a session. It does not change
• Often preferred by experienced users because they allow for during the session
faster interaction with the system May be either numeric or textual
• Not suitable for casual or inexperienced users • Dynamic information
• May be provided as an alternative to menu commands Changes during a session and the changes must be communi-
(keyboard shortcuts). In some cases, a command language cated to the system user
interface and a menu-based interface are supported at the May be either numeric or textual
same time
Information Display Factors
Natural Language Interfaces
• Is the user interested in precise information or
• The user types a command in a natural language. Generally, data relationships?
the vocabulary is limited and these systems are confined to
specific application domains (e.g. timetable enquiries)
• How quickly do information values change?
Must the change be indicated immediately?
• NL processing technology is now good enough to make
these interfaces effective for casual users but experienced users
• Must the user take some action in response to
a change?
find that they require too much typing
• Is there a direct manipulation interface?
Multiple User Interfaces
• Is the information textual or numeric? Are relative values
C o m m an d
important?
Gr ap hi cal u ser
l an gu ag e
i nt erface
i nt erface Alternative Information Presentations

C o m m an d
GU I
l an gu ag e Jan Feb M ar Ap ri l May Ju ne
m anag er
i nt erp reter 2 84 2 2 85 1 3 16 4 2 78 9 1 27 3 2 83 5

Op erati ng s ys tem 4 00 0

Information Presentation 3 00 0
• Information presentation is concerned with presenting
system information to system users
2 00 0
• The information may be presented directly (e.g. text in a
word processor) or may be transformed in some way for
presentation (e.g. in some graphical form) 1 00 0
• The Model-View-Controller approach is a way of supporting
multiple presentations of data
0
Jan Feb Mar Ap ril M ay Ju ne

Information to Presentation
be displayed software
Analogue Vs. Digital Presentation
• Digital presentation
Display
Compact - takes up little screen space
Precise values can be communicated
Model-view-controller
• Analogue presentation
View state view modification Controller state Easier to get an ‘at a glance’ impression of a value
messages User inputs
View methods Controller methods Possible to show relative values
Easier to see exceptional data values
Model queries
and updates Model edits
Model state

Model methods

87
 Dynamic Information Display Colour Use Guidelines
SOFTWARE ENGINEERING

• Don’t use too many colours

• Use colour coding to support use tasks
1
• Allow users to control colour coding
4 2
0 10 20 • Design for monochrome then add colour
• Use colour coding consistently
3
• Avoid colour pairings, which clash
• Use colour change to show status change
Dial with needle Pie chart Thermometer Horizontal bar
• Be aware that colour displays are usually lower resolution
User Support
Displaying Relative Values
• User guidance covers all system facilities to support users
including on-line help, error messages, manuals etc.
Pressure Temperature • The user guidance system should be integrated with the user
0 100 200 300 400 0 25 50 75 100 interface to help users when they need information about the
system or when they make some kind of error
• The help and message system should, if possible, be
integrated
Textual Highlighting Help and Message System

Ap pl icat io n

!
The filename you have chosen h as been
used. Please choose an other name
He l p Erro r m ess ag e
i nt erface s ys tem
Ch. 16 User interface design
M essag e
p re s enta ti on
OK Cancel s ys tem

He l p Erro r m e ss ag e
fram es t ex ts
Data Visualisation
• Concerned with techniques for displaying large amounts of
information Error Messages
• Visualisation can reveal relationships between entities and • Error message design is critically important. Poor error
trends in the data messages can mean that a user rejects rather than accepts a
system
• Possible data visualisations are:
Weather information collected from a number of sources
• Messages should be polite, concise, consistent and
constructive
The state of a telephone network as a linked set of nodes
• The background and experience of users should be the
Chemical plant visualised by showing pressures and tempera- determining factor in message design
tures in a linked set of tanks and pipes
Design Factors in Message Wording
A model of a molecule displayed in 3 dimensions
Web pages displayed as a hyperbolic tree Context The user guidance system should be aware of what the user is
doing and should adjust the output message to the current
Colour Displays context.
Experience As users become familiar with a system they become irritated
• Colour adds an extra dimension to an interface by long, ‘meaningful’ messages. However, beginners find it
difficult to understand short terse statements of the problem.
and can help the user understand complex The user guidance system should provide both types of message
and allow the user to control message conciseness.
information structures Skill level Messages should be tailored to the user’s skills as well as their
experience. Messages for the different classes of user may be
• Can be used to highlight exceptional events expressed in different ways depending on the terminology which
is familiar to the reader.
• Common mistakes in the use of colour in Style Messages should be positive rather than negative. They should
use the active rather than the passive mode of address. They
interface design include: should never be insulting or try to be funny.
Culture Wherever possible, the designer of messages should be familiar
The use of colour to communicate meaning with the culture of the country where the system is sold. There
are distinct cultural differences between Europe, Asia and
Over-use of colour in the display America. A suitable message for one culture might be
unacceptable in another.

88
Nurse Input of a Patient’s Name Help System Windows

SOFTWARE ENGINEERING
Please type the patient name in the box then click on OK
Help frame map Mail redirection

Bates, J. Mail may be redirected to another

network user by pressing the
redirect button in the control
OK Cancel panel. The system asks for the
name of the user or users to
whom the mail has been sent

You are here more next topics

System and User-oriented Error Messages

System-oriented error message

User-oriented error message
Help history

Error #27 1. Mail

?
Patient J. Bates is not registered
Invalid patient id entered Click on Patients f or a list of registered patients
2. Send mail
Click on Retr y to re-input a patient name 3. Read mail
Click on Helporf more inf ormation 4. Redirection
OK Cancel
Patients Help Retry Cancel

Help System Design User Documentation

Help? means ‘help I want information” • As well as on-line information, paper documentation should
be supplied with a system
Help! means “HELP. I’m in trouble”
• Both of these requirements have to be taken into account in • Documentation should be designed for a range of users
from inexperienced to experienced
help system design
• Different facilities in the help system may be required • As well as manuals, other easy-to-use documentation such as
a quick reference card may be provided
Help Information
User Document Types
• Should not simply be an on-line manual
• Screens or windows don’t map well onto paper pages. System
evaluators
System
administrators
Novice
users
Experienced
users
System
administrators
• The dynamic characteristics of the display can improve
information presentation.
Functional Installation Introductory Reference Administrator’s
• People are not so good at reading screen as they are text. description document manual manual guide

Help System Use

• Multiple entry points should be provided so that the user Description of
services
How to install
the system
Getting
started
Facility
description
Operation and
maintenance
can get into the help system from different places.
• Some indication of where the user is positioned in the help
system is valuable.
Document Types
• Facilities should be provided to allow the user to navigate
• Functional description
and traverse the help system.
Brief description of what the system can do
Entry Points to a Help System
• Introductory manual
Presents an informal introduction to the system
To p-lev el
ent ry • System reference manual
Describes all system facilities in detail
En try f ro m
ap pl icat io n
• System installation manual
Describes how to install the system
• System administrator’s manual
En tr y fro m e rro r
m ess ag e sy st em Describes how to manage the system when it is in use
User Interface Evaluation
• Some evaluation of a user interface design should be carried
He l p fram e n etwo rk
out to assess its suitability

89
 • Full-scale evaluation is very expensive and impractical for Activity
SOFTWARE ENGINEERING

most systems Suggest situations where it is unwise or impossible to provide a

• Ideally, an interface should be evaluated against a usability consistent user interface.
specification. However, it is rare for such specifications to be
produced
Usability Attributes

Attribute Description
Learnability How long does it take a new user to
become productive with the system?
Speed of operation How well does the system response match
the user’s work practice?
Robustness How tolerant is the system of user error?
Recoverability How good is the system at recovering from
user errors?
Adaptability How closely is the system tied to a single
model of work?

Simple Evaluation Techniques

• Questionnaires for user feedback
• Video recording of system use and subsequent
tape evaluation.
• Instrumentation of code to collect information
about facility use and user errors.
• The provision of a grip button for on-line user
feedback.
Key Points
• Interface design should be user-centred. An interface should
be logical and consistent and help users recover from errors
• Interaction styles include direct manipulation; menu systems Activity
form fill-in, command languages and natural language What factors have to be taken into account when designing
menu based interface for ‘walkup’ systems such as bank ATM
• Graphical displays should be used to present trends and
machines? Write a critical commentary on the interface of an
approximate values. Digital displays when precision is
ATM that you use.
required
• Colour should be used sparingly and consistently
• Systems should provide on-line help. This should include
“help, I’m in trouble” and “help, I want information”
• Error messages should be positive rather than
negative.
• A range of different types of user documents should be
provided
• Ideally, a user interface should be evaluated against a usability
specification

90
Activity Activity

SOFTWARE ENGINEERING
Suggest ways in which the user interface to an e- commerce What are the guidelines which should be followed when using
system such as an online bookstore or music retailer might be color in a user interface? Suggest how color might be used more
adapted for users who are physically challenged with some form effectively in the interface of an application system that you use.
of casual impairment or problems with muscular control.

Activity
Activity
Discuss the advantages of graphical information display and
Write a short set of guidelines for designers of user guidance
suggest four applications where it would be more appropriate
systems.
to use graphical rather than digital displays of numeric informa-
tion.

91
 Notes:
SOFTWARE ENGINEERING

Activity 7: Design a questionnaire to gather information about

the user interface f some tool (such as a word processor) with
which you are familiar. If possible, distribute this questionnaire
to a number of users and try to evaluate the results. What do
these tell you about the user interface design?

Activity 8: What ethical issues might user interface designers

face when trying to reconcile the needs of end-users of a system
with the needs of the organization which is paying for the
system to be developed?

92
 UNIT II
DESIGN, VERIFICATION AND VALIDATION
LESSON 26: UNIT 6
VERIFICATION AND VALIDATION CHAPTER 15

Objectives • The level of confidence required depends on at least three

SOFTWARE ENGINEERING
• To introduce software verification and validation and to factors…
discuss the distinction between them. Factors Affecting Level of Confidence Required
• To describe the program inspection / review process and its 1. Software function / purpose: Safety-critical systems require a
role in V & V. much higher level of confidence than demonstration-of-
• To describe the Clean room software development process. concept prototypes.
Topics Covered 2. User expectations: Users may tolerate shortcomings when
the benefits of use are high.
• Software inspections / reviews
3. Marketing environment: Getting a product to market early
• Cleanroom software development
may be more important than finding additional defects.
Verification Vs. Validation
V&V Versus Debugging
• Verification:
• V&V and debugging are distinct processes.
“Are we building the product right?”
V&V is concerned with establishing the existence of defects in a
The software should conform to its specification. program.
• Validation: Debugging is concerned with locating and ” repairing these
“Are we building the right product?” defects.
The software should do what the user really needs / wants. • Defect locating is analogous to detective work or medical
diagnosis.
Static and Dynamic V&V
• Software inspections / reviews: analyse static system Software Inspections / Reviews
representations such as requirements, design, source code, • Involve people examining a system representation
etc. (static V & V) (requirements, design, source code, etc.) with the aim of
• Software testing: executing an implementation of the discovering anomalies and defects.
software to examine outputs and operational behaviour • They do not require execution so may be used before system
(dynamic V & V) implementation.
• Can be more effective than testing after system
Static implementation. (As demonstrated in many studies.)
verification
Why Code Inspections can be so Effective
• Many different defects may be discovered in a single
Requirements High-level Formal Detailed
specification Program inspection. (In testing, one defect may mask others so several
specification design design
executions may be required.)
• They reuse domain and programming language knowledge.
Dynamic (Reviewers are likely to have seen the types of error that
Prototype
validation
commonly occur.)
Inspections and Testing are Complementary
Program Testing • Inspections can be used early with non-executable entities
• Defect testing: Tests designed to discover system defects. and with source code at the module and component levels.
Sometimes referred to as coverage testing. (Covered after • Testing can validate dynamic behaviour and is the only
“Proofs of Correctness”.) effective technique at the sub-system and system code levels.
• Statistical testing: Tests designed to assess system reliability • Inspections cannot directly check non-functional
and performance under operational conditions. Makes use requirements such as performance, usability, etc.
of an operational profile.
Program Inspections / Reviews
V&V Goals
• Formalised approaches to document walk throughs or desk
• Verification and validation should establish confidence that checking.
the software is “fit for purpose”.
• Intended exclusively for defect DETECTION (not
• This does NOT usually mean that the software must be correction).
completely free of defects.

93
 • Defects may be logical errors, anomalies in the code that Inspection Checks
SOFTWARE ENGINEERING

might indicate an erroneous condition, or non-compliance

with standards.
Fault class Inspection check
Inspection Pre-conditions (“Entry Criteria”) Data faults Are all program variables initialised before their values
are used?
• A precise specification must be available. Have all constants been named?
Should the lower bound of arrays be 0, 1, or something
• Team members must be familiar with the organization else?
standards. Should the upper bound of arrays be equal to the size of
the array or Size -1?
• Syntactically correct code must be available (for code If character strings are used, is a delimiter explicitly
inspections). assigned?
Control faults For each conditional statement, is the condition correct?
Inspection Pre-conditions Is each loop certain to terminate?
Are compound statements correctly bracketed?
• An error checklist should be prepared. In case statements, are all possible cases accounted for?
Input/output faults Are all input variables used?
• Management must accept the fact that inspection will increase Are all output variables assigned a value before they are
output?
costs early in the software process. (payoff comes later) Interface faults Do all function and procedure calls have the correct
• Management must not use inspections results for staff number of parameters?
Do formal and actual parameter types match?
appraisals. (Don’t kill the goose that lays the golden eggs.) Are the parameters in the right order?
If components access shared memory, do they have the
The Inspection Process same model of the shared memory structure?
Storage management If a linked structure is modified, have all links been
faults correctly reassigned?
Planning
If dynamic storage is used, has space been allocated
correctly?
Overview Follow-up Is space explicitly de-allocated after it is no longer
Individual
Rework required?
preparation Exception Have all possible error conditions been taken into
Inspection
meeting management faults account?

Inspection Procedure
Approximate Inspection Rate
• System overview presented to inspection team.
• 500 statements/hour during overview.
• Code and associated documents are
distributed to inspection team in advance.
• 125 source statement/hour during individual preparation.
• Inspection takes place and discovered errors are noted. • 90-125 statements/hour during inspection meeting.
• Modifications are made to repair discovered errors (by • Inspection is therefore an expensive process.
owner). • Inspecting 500 lines costs about 40 person/ hours
(assuming 4 participants).
• Re-inspection may or may not be required.
Inspection Teams
Cleanroom Software Development
• The name is derived from the ‘Cleanroom’ process in
• Typically made up of 4-7 members.
semiconductor fabrication.
• Author (owner) of the element being inspected.
The Philosophy is Defect Avoidance Rather Than
• Inspectors who find errors, omissions and inconsistencies.
Defect Removal.
• Reader who steps through the element being reviewed with
• A software development process based on:
the team.
Incremental development (if appropriate)
• Moderator who chairs the meeting and notes discovered
errors. Formal specification
• Other roles are Scribe and Chief moderator Static verification using correctness arguments
Statistical testing to certify program reliability
Code Inspection Checklists
• Checklist of common errors should be used to drive NO defect testing!
individual preparation. The Cleanroom Process
• Error checklist for is programming language dependent. Fo rmally Erro r rewo rk
s pecify
• The “weaker” the type checking (by the compiler), the larger s ystem

the checklist. Define

s oftware
C o ns tru ct
s tru ct ured
Fo rmally
verify
Integrate
increment
increment s p rog ram cod e
• Examples: initialisation, constant naming, loop Develo p
o perat io nal
termination, array bounds, etc. p ro file
Des ig n
statis tical
Test
i nt eg rated
tests s ys tem

94
Cleanroom Process Teams extent can testing be used to validate that the program is fit for

SOFTWARE ENGINEERING
• Specification team: responsible for developing and its purpose?
maintaining the system specification
• Development team: responsible for developing and
verifying the software. The software is NOT executed or even
compiled during this process.
• Certification team: responsible for developing a set of
statistical tests to measure reliability after development.
Clean Room Process Evaluation
• Results in IBM and elsewhere have been very impressive
with very few discovered faults in delivered systems.
• Independent assessment shows that the process is no more
expensive than other approaches.
• Not clear how this approach can be transferred to an
environment with less skilled engineers.
Key Points
• Verification and validation are not the same. Verification
shows conformance with a specification; validation shows
conformance with customer’s needs/desires.
• Static verification techniques involve examination and Activity
analysis of software elements for error detection. Explain why program inspections are an effective technique for
• Program inspections are very effective in discovering errors. discovering errors in a program. What types of error are unlikely
to be discovered through inspections?
• The Clean room development process depends on formal
specification, static verification, and statistical testing.
Activity
Discuss the differences between verification and validation and
explain why validations particularly difficult process.

Activity
Explain why an organization with a competitive, elitist culture
would probably find it difficult to introduce program inspec-
tions as a V& V technique.

Activity
Explain why it is not necessary for a program to be completely
free of defects before it is delivered to its customers. To what

95
SOFTWARE ENGINEERING

Activity
A manager decides to use the reports of program inspections as
an input to the stag appraisal process. These reports show who
made and who discovered program errors. Is this ethical
managerial behaviour? Would it be ethical if the staff were
informed in advance that this would happen? What difference
might it make to the inspection process?

Activity
Using your knowledge of Java, C++, C or some other pro-
gramming language, derive a checklist of common errors (not
syntax errors) which could not be detected by a complier but
which might be detected in a program inspection.

Activity
One approach which is commonly adapted to system testing is
to test the system until the testing budget is exhausted and
then deliver the system to customers. Discuss the ethics of this
approach.

Activity
Read the published papers on clean room development and
write a management report highlighting the advantages, costs
and risks of adopting this approach to software development.

96
 UNIT II
DESIGN, VERIFICATION AND VALIDATION
LESSON 27 AND 28:
SOFTWARE TESTING CHAPTER 16

Objectives • Testing typical situations is more important than

SOFTWARE ENGINEERING
• To understand testing techniques that are geared to discover boundary value cases
program faults Test Data and Test Cases
• To introduce guidelines for interface testing • Test data Inputs, which have been devised to test the system
• To understand specific approaches to object-oriented testing • Test cases Inputs to test the system and the predicted
• To understand the principles of CASE tool support for outputs from these inputs if the system operates according
testing to its specification
Topics Covered The Defect Testing Process
• Defect testing
• Integration testing Test Test Test Test
cases data results reports
• Object-oriented testing
• Testing workbenches Design test Prepare test Runprogram Compare results
cases data with test data totest cases
The Testing Process
• Component testing
Testing of individual program components Black-box Testing
Usually the responsibility of the component developer (except • An approach to testing where the program is considered as a
sometimes for critical systems) ‘black-box’
Tests are derived from the developer’s experience • The program test cases are based on the system specification
• Integration testing • Test planning can begin early in the software process
Testing of groups of components integrated to create a system
or sub-system Inp ut s caus in g
ano m alo us
The responsibility of an independent testing team Inp ut test dat a I b eh av io ur
e
Tests are based on a system specification
Testing Phases

Component Integration Sy stem

testing testing

Softw are dev eloper Independent tes ting team Ou t pu ts wh ich reveal
the p resen ce o f
Ou tpu t test resu lts Oe d efects
Defect Testing
• Testing programs to establish the presence of system defects
• The goal of defect testing is to discover defects in programs
• A successful defect test is a test, which causes a program to Equivalence Partitioning
behave in an anomalous way • Input data and output results often fall into different classes
• Tests show the presence not the absence of defects where all members of a class are related
Testing Priorities • Each of these classes is an equivalence partition where the
• Only exhaustive testing can show a program is program behaves in an equivalent way for each class member
free from defects. However, exhaustive testing • Test cases should be chosen from each partition
is impossible
• Tests should exercise a system’s capabilities
rather than its components
• Testing old capabilities is more important than
testing new capabilities

97
 (Not Found and not (exists i, T’FIRST >= i
SOFTWARE ENGINEERING

<= T’LAST, T (i) = Key))

Search Routine : Input Partitions
• Inputs, which conform to the pre-conditions
Inva li d in pu ts V ali d in pu ts • Inputs where a pre-condition does not hold
• Inputs where the key element is a member of
the array

S y stem
• Inputs where the key element is not a member
of the array
Testing Guidelines (Sequences)
• Test software with sequences, which have only a single value
• Use sequences of different sizes in different tests
O u tput s • Derive tests so that the first, middle and last elements of the
sequence are accessed
• Test with sequences of zero length
• Partition system inputs and outputs into Search Routine - Input Partitions
‘equivalence sets’
If input is a 5-digit integer between 10,000 and 99,999, Array Element
equivalence partitions are <10,000, 10,000-99, 999 and > Single value In sequence
10, 000 Single value Not in sequence
Choose test cases at the boundary of these More than 1 value First element in sequence
sets More than 1 value Last element in sequence
More than 1 value Middle element in sequence
00000, 09999, 10000, 99999, 10001 More than 1 value Not in sequence
Equivalence Partitions

3 11
Input sequence (T) Key (Key) Output (Found, L)
4 7 10 17 17 true, 1
17 0 false, ??
17, 29, 21, 23 17 true, 1
41, 18, 9, 31, 30, 16, 45 45 true, 7
Less than 4 Between 4 and 10 More than 10 17, 18, 21, 23, 29, 41, 38 23 true, 4
21, 23, 29, 33, 38 25 false, ??
Number of input values

9999 100000 White-box Testing

10000 50000 99999
• Sometimes called Structural testing
• Derivation of test cases according to program
Less than 10000 Between 10000 and 99999 More than 99999 structure. Knowledge of the program is used to identify
additional test cases
Input values • Objective is to exercise all program statements
(not all path combinations)

Search Routine Specification

Procedure Search (Key: ELEM; T: ELEM_ARRAY; Test data
Found: in out BOOLEAN; L: in out ELEM_INDEX) ;
Pre-condition : the array has at least one element
T’FIRST <= T’LAST Tests Derives
Post-condition : the element is found and is referenced by L
(Found and T (L) = Key)
or Component Test
code outputs
: the element is not in the array

98
Binary Search (Java) Binary Search - Test Cases

SOFTWARE ENGINEERING
Inp ut array (T ) Key ( Key ) Output ( Found, L )
class BinSearch { 17 17 true, 1
17 0 false, ??
// This is an encapsulation of a binary search function that takes an array of 17, 21, 23, 29 17 true, 1
// ordered objects and a key and returns an object with 2 attributes namely 9, 16, 18, 30, 31, 41, 45 45 true, 7
// index - the value of the array index
17, 18, 21, 23, 29, 38, 41 23 true, 4
// found - a boolean indicating whether or not the key is in the array
// An object is returned because it is not possible in Java to pass basic types by 17, 18, 21, 23, 29, 33, 38 21 true, 3
// reference to a function and so return two values 12, 18, 21, 23, 32 23 true, 4
// the key is -1 if the element is not found 21, 23, 29, 33, 38 25 false, ??

public static void search ( int key, int [] elemArray, Result r )

{ Path Testing
int bottom = 0 ; • The objective of path testing is to ensure that the set of test
int top = elemArray.length - 1 ;
int mid ;
cases is such that each path through the program is executed
r.found = false ; r.index = -1 ; at least once
while ( bottom <= top )
{
• The starting point for path testing is a program flow graph
mid = (top + bottom) / 2 ; that shows nodes representing program decisions and arcs
if (elemArray [mid] == key) representing the flow of control
{
r.index = mid ;
• Statements with conditions are therefore nodes in the flow
r.found = true ; graph
return ;
} // if part Program Flow Graphs
else • Describes the program control flow. Each branch is shown as
{
a separate path and loops are shown by arrows looping back
if (elemArray [mid] < key)
bottom = mid + 1 ; to the loop condition node
else • Used as a basis for computing the cyclomatic
top = mid - 1 ;
}
complexity
} //while loop • Cyclomatic complexity = Number of edges - Number of
} // search
nodes +2
} //BinSearch
Cyclomatic Complexity
• The number of tests to test all control
statements equals the cyclomatic complexity
Binary Search - Equiv. Partitions • Cyclomatic complexity equals number of conditions in a
• Pre-conditions satisfied, key element in array program
• Pre-conditions satisfied, key element not in array • Useful if used with care. Does not imply
• Pre-conditions unsatisfied, key element in array adequacy of testing.
• Pre-conditions unsatisfied, key element not in array • Although all paths are executed, all combinations of paths
are not executed
• Input array has a single value
• Input array has an even number of values
1
• Input array has an odd number of values
Equivalence class boundaries b ot to m > t op
w h il e bo ttom < = to p
2

3 if (elem A rray [m id] == k ey

Elements < Mid Elements > Mid

8 4
(i f (elem A rray [mi d]< key

Mid-point 5 6
9

Binary search flow graph

99
 Independent Paths Bottom-up Testing
SOFTWARE ENGINEERING

• 1, 2, 3, 8, 9
• 1, 2, 3, 4, 6, 7, 2
Test
• 1, 2, 3, 4, 5, 7, 2 drivers
• 1, 2, 3, 4, 6, 7, 2, 8, 9 Level N Level N Level N Level N Level N
Testing
sequence
• Test cases should be derived so that all of these paths are
executed
• A dynamic program analyser may be used to check that paths
have been executed
Test
Integration Testing drivers
Level N–1 Level N–1 Level N–1
• Tests complete systems or subsystems composed of
integrated components
• Integration testing should be black-box testing with tests Testing Approaches
derived from the specification • Architectural validation
• Main difficulty is localising errors Top-down integration testing is better at discovering errors in
• Incremental integration testing reduces this problem the system architecture
Incremental Integration Testing • System demonstration
Top-down integration testing allows a limited demonstration at
A T1
an early stage in the development
T1 • Test implementation
A
T1 T2 Often easier with bottom-up integration testing
A B
T2 • Test observation
T2 B T3 Problems with both approaches. Extra code may be required to
T3 observe tests
B C
T3 T4
C Interface Testing
T4
D T5
• Takes place when modules or sub-systems are integrated to
create larger systems
Test sequence Test sequence Test sequence • Objectives are to detect faults due to interface errors or
1 2 3
invalid assumptions about interfaces
• Particularly important for object-oriented development as
Approaches to Integration Testing objects are defined by their interfaces
• Top-down testing
Start with high-level system and integrate from the top-down
replacing individual components by stubs where appropriate
Test
cases
• Bottom-up testing
Integrate individual components in levels until the complete
system is created
• In practice, most integration involves a combination of these
strategies
Top-down Testing

Testing
Level 1 Level 1 . ..
sequence A B

Level 2 Level 2 Level 2 Level 2

Level 2 C
stubs

Level 3
stubs

100
Interfaces Types Object Class Testing

SOFTWARE ENGINEERING
• Parameter interfaces • Complete test coverage of a class involves
Data passed from one procedure to another Testing all operations associated with an object
• Shared memory interfaces Setting and interrogating all object attributes
Block of memory is shared between procedures Exercising the object in all possible states
Procedural interfaces • Inheritance makes it more difficult to design object class
Sub-system encapsulates a set of procedures to be called by tests, as the information to be tested is not localised
other sub-systems Weather Station Object Interface
• Message passing interfaces
Sub-systems request services from other sub-systems Weather Station
Interface Errors identifier
• Interface misuse reportWeather()
A calling component calls another component and makes an calibrate(instruments)
error in its use of its interface e.g. parameters in the wrong order test ()
startup(instruments)
• Interface misunderstanding shutdown(instruments)
A calling component embeds assumptions about the behaviour
of the called component, which are incorrect • Test cases are needed for all operations
• Timing errors • Use a state model to identify state transitions for testing
The called and the calling component operate at different speeds • Examples of testing sequences
and out-of-date information is accessed Shutdown : Waiting : Shutdown
Interface Testing Guidelines Waiting : Calibrating : Testing : Transmitting : Waiting
• Design tests so that parameters to a called procedure are at Waiting : Collecting : Waiting : Summarising : Transmitting :
the extreme ends of their ranges Waiting
• Always test pointer parameters with null pointers Object Integration
• Design tests, which cause the component to fail • Levels of integration are less distinct in object-oriented
• Use stress testing in message passing systems systems
• In shared memory systems, vary the order in which • Cluster testing is concerned with integrating and testing
components are activated clusters of cooperating objects
Stress Testing • Identify clusters using knowledge of the operation of
• Exercises the system beyond its maximum design load. objects and the system features that are implemented by
Stressing the system often causes defects to come to light these clusters
• Stressing the system test failure behaviour.. Systems should Approaches to Cluster Testing
not fail catastrophically. Stress testing checks for unacceptable • Use-case or scenario testing
loss of service or data Testing is based on user interactions with the system
• Particularly relevant to distributed systems which can exhibit Has the advantage that it tests system features as experienced by
severe degradation as a network becomes overloaded users
Object-oriented Testing • Thread testing
• The components to be tested are object classes that are Tests the systems response to events as processing threads
instantiated as objects through the system
• Larger grain than individual functions so approaches to • Object interaction testing
white-box testing have to be extended
Tests sequences of object interactions that stop when an object
• No obvious ‘top’ to the system for top-down integration operation does not call on services from another object
and testing
Scenario-based Testing
Testing Levels
• Identify scenarios from use-cases and supplement these with
• Testing operations associated with objects interaction diagrams that show the objects involved in the
• Testing object classes scenario
• Testing clusters of cooperating objects • Consider the scenario in the weather station system where a
• Testing the complete OO system report is generated

101
 Collect Weather Data Testing Workbench Adaptation
SOFTWARE ENGINEERING

• Scripts may be developed for user interface simulators and

:CommsController :W eatherStation :W eatherData patterns for test data generators
request (report) • Test outputs may have to be prepared manually for
comparison
acknowledge ()
report () • Special-purpose file comparators may be developed
summarise ()
Key Points
• Test parts of a system which are commonly used rather than
send (report) those which are rarely executed
reply (report)
• Equivalence partitions are sets of test cases where the
acknowledge () program should behave in an equivalent way
• Black-box testing is based on the system specification
• Structural testing identifies test cases, which cause all paths
Weather Station Testing through the program to be executed
• Thread of methods executed • Test coverage measures ensure that all statements have been
executed at least once.
CommsController: request - WeatherStation: report -
WeatherData: summarise • Interface defects arise because of specification misreading,
misunderstanding, errors or invalid timing assumptions
• Inputs and outputs
• To test object classes, test all operations, attributes and states
Input of report request with associated acknowledge and a final
output of a report • Integrate object-oriented systems around clusters of objects
Can be tested by creating raw data and ensuring that it is Activity
summarised properly Discuss the differences between black box and structural testing
Use the same raw data to test the Weather Data object and suggest how they can be used together in the defect testing
process.
Testing Workbenches
• Testing is an expensive process phase. Testing workbenches
provide a range of tools to reduce the time required and total
testing costs
• Most testing workbenches are open systems because testing
needs are organisation-specific
• Difficult to integrate with closed design and analysis
workbenches
A Testing Workbench

Test data
Specification
generator

Source Test Oracle

code manager Test data

Dynamic Program Test Test

analyser being tested results predictions

Activity
Execution File What testing problems might arise in numerical routines
Simulator
report comparator
designed to handle very large and very small numbers?

Report Test results

generator report

102
 SOFTWARE ENGINEERING
Activity
Explain why interface testing is necessary given that individual
units have been extensively validated through unit testing and
program inspections.

Activity
Derive a set of test for the following components:
• A sort routine, which sorts arrays of integers.
• A routine, which takes a line of text as input and counts the
number of non-blank characters in that line.

Activity
Explain why bottom-up and top-down testing may be
inappropriate testing strategies for object oriented systems.

Activity
Show, using a small example, why it is practically impossible to
exhaustively test a program.

103
 UNIT III
MANAGEMENT
LESSON 29 AND 30: UNIT 7
MANAGING PEOPLE CHAPTER 17

Managing People Working As Individuals And In Memory Organisation

SOFTWARE ENGINEERING

Groups
Objectives F ro m
• To describe simple models of human cognition and their s en se s
relevance for software managers
• To explain the key issues that determine the success or S h ort -te rm
otherwise of team working m e m ory
• To discuss the problems of selecting and retaining technical
staff
• To introduce the people capability maturity model (P-CMM)
Wo rk in g m e m o ry
Topics Covered
• Limits to thinking
• Group working
• Choosing and keeping people Lo ng -te r m m e m o ry
• The people capability maturity model (L a r g e c ap ac i ty, sl ow a c c e ss )
People in the Process
• People are an organisation’s most important assets
• The tasks of a manager are essentially people Short-term Memory
oriented. Unless there is some understanding • Fast access, limited capacity
of people, management will be unsuccessful
• 5-7 locations
• Software engineering is primarily a cognitive • Holds ‘chunks’ of information where the size of
activity. Cognitive limitations effectively limit the software
a chunk may vary depending on its familiarity
process
• Fast decay time
Management Activities
Working Memory
• Problem solving (using available people)
• Larger capacity, longer access time
• Motivating (people who work on a project)
• Memory area used to integrate information from
• Planning (what people are going to do) short-term memory and long-term memory.
• Estimating (how fast people will work) • Relatively fast decay time.
• Controlling (people’s activities)
Long-term Memory
• Organising (the way in which people work)
• Slow access, very large capacity
Limits to Thinking
• Unreliable retrieval mechanism
• People don’t all think the same way but everyone is subject
to some basic constraints on their thinking due to
• Slow but finite decay time - information needs reinforced
• Relatively high threshold - work has to be done to get
Memory organisation
information into long-term memory.
Knowledge representation
Information Transfer
Motivation influences
• Problem solving usually requires transfer
• If we understand these constraints, we can understand how
between short-term memory and working memory
they affect people participating in the software process
• Information may be lost or corrupted during this
transfer
• Information processing occurs in the transfer
from short-term to long-term memory

104
Cognitive Chunking Problem Solving

SOFTWARE ENGINEERING
• Requires the integration of different types of knowledge
Loop (process entir e array) (computer, task, domain, organisation)

Loop (process unsorted part of array) • Development of a semantic model of the solution and
testing of this model against the problem
• Representation of this model in an appropriate notation or
Compare adjacent elements programming language

Swap if necessary so that smaller comes first

Partial
Problem Solution
solutions

Knowledge Modelling
• Semantic knowledge: knowledge of concepts such as the New knowledge
Working
operation of assignment, concept of parameter passing etc.
Existing knowledge memory
• Syntactic knowledge: knowledge of details of a
representation e.g. an Ada while loop.
• Semantic knowledge seems to be stored in a structured,
representation independent way.
Syntactic/Semantic Knowledge
Long-term memory

Motivation
• An important role of a manager is to motivate the people
working on a project
• Motivation is a complex issue but it appears that their are
different types of motivation based on

Task knowledge Computer knowledge Basic needs (e.g. food, sleep, etc.)
Semantic knowledge Syntactic knowledge Personal needs (e.g. respect, self-esteem)
Social needs (e.g. to be accepted as part of a group)
Human Needs Hierarchy
Knowledge Acquisition
• Semantic knowledge through experience and
active learning - the ‘ah’ factor
Self-
• Syntactic knowledge acquired by memorisation. realizatio n needs
• New syntactic knowledge can interfere with
existing syntactic knowledge. Es teem needs
Problems arise for experienced programmers in mixing up
syntax of different programming languages Social need s

Semantic Knowledge Safety needs

• Computing concepts : notion of a writable
store, iteration, concept of an object, etc. Phy siolog ical need s
• Task concepts : principally algorithmic - how to
tackle a particular task
• Software development ability is the ability to integrate new Motivating People
knowledge with existing computer and task knowledge and • Motivations depend on satisfying needs
hence derive creative problem solutions
• It can be assumed that physiological and safety
• Thus, problem solving is language independent needs are satisfied

105
 • Social, esteem and self-realization needs are Time Distribution
SOFTWARE ENGINEERING

most significant from a managerial viewpoint

Need Satisfaction
• Social 20%
No n-p roductive
Provide communal facilities activ ities

Allow informal communications 50%

Interaction w ith
• Esteem o th er peo ple
3 0%
Recognition of achievements Work ing alon e

Appropriate rewards
• Self-realization
Training - people want to learn more
Responsibility
Group Composition
Personality Types
• Group composed of members who share the
• The needs hierarchy is almost certainly an over-simplification same motivation can be problematic
• Motivation should also take into account different Task-oriented : everyone wants to do their own thing
personality types:
Self-oriented : everyone wants to be the boss
Task-oriented
Interaction-oriented : too much chatting, not enough work
Self-oriented
• An effective group has a balance of all types
Interaction-oriented
• Can be difficult to achieve because most
• Task-oriented. engineers are task-oriented
The motivation for doing the work is the work itself
• Need for all members to be involved in decisions, which
• Self-oriented. affect the group
The work is a means to an end which is the achievement of Group Leadership
individual goals - e.g. to get rich, to play tennis, to travel etc.
• Leadership depends on respect not titular
• Interaction-oriented status
The principal motivation is the presence and actions of co- • There may be both a technical and an
workers. People go to work because they like to go to work administrative leader
Motivation Balance • Democratic leadership is more effective that
• Individual motivations are made up of elements autocratic leadership
of each class • A career path based on technical competence
• Balance can change depending on personal should be supported
circumstances and external events Group Cohesiveness
• However, people are not just motivated by personal factors • In a cohesive group, members consider the group to be more
but also by being part of a group and culture. important than any individual in it
• People go to work because they are motivated by the people • Advantages of a cohesive group are:
that they work with
Group quality standards can be developed
Group Working Group members work closely together so inhibitions caused by
• Most software engineering is a group activity ignorance are reduced
The development schedule for most non-trivial software Team members learn from each other and get to know each
projects is such that they cannot be completed by one person other’s work
working alone
Ego less programming where members strive to improve each
• Group interaction is a key determinant of group other’s programs can be practised
performance
Developing Cohesiveness
• Flexibility in group composition is limited
• Cohesiveness is influenced by factors such as the
Managers must do the best they can with available people organisational culture and the personalities in the group
• Cohesiveness can be encouraged through
Social events
Developing a group identity and territory

106
Explicit team-building activities Chief Programmer Teams

SOFTWARE ENGINEERING
• Openness with information is a simple way of ensuring all Specialist pool
group members feel part of the group Nucleus of chief programmer team

Administrator
Group Loyalties Chief Backup
Toolsmith programmer programmer
• Group members tend to be loyal to cohesive groups OS specialist
• ‘Groupthink’ is preservation of group irrespective of Tech. author Librarian Outside
technical or organizational considerations Communica tion
Test specialist
• Management should act positively to avoid groupthink by
forcing external involvement with each group
Group Communications • Consist of a kernel of specialists helped by others added to
the project as required
• Good communications are essential for effective group
working • The motivation behind their development is the wide
difference in ability in different programmers
• Information must be exchanged on the status of work,
design decisions and changes to previous decisions • Chief programmer teams provide a supporting environment
for very able programmers to be responsible for most of the
• Good communications also strengthens group cohesion as it system development
promotes understanding
Problems
• Status of group members
Higher status members tend to dominate conversations
• This chief programmer approach, in different forms, has
undoubtedly been successful
• Personalities in groups
• However, it suffers from a number of problems
Too many people of the same personality type can be a
Talented designers and programmers are hard to find. Without
problem
exception people in these roles, the approach will fail
• Sexual composition of group
Other group members may resent the chief programmer taking
Mixed-sex groups tend to communicate better the credit for success so may deliberately undermine his/her role
• Communication channels High project risk as the project will fail if both the chief and
Communications channelled though a central coordinator tend deputy programmer are unavailable
to be ineffective Organisational structures and grades may be unable to accom-
Group Organisation modate this type of group
• Software engineering group sizes should be relatively small Choosing and Keeping People
(< 8 members) • Choosing people to work on a project is a major managerial
• Break big projects down into multiple smaller projects responsibility
• Small teams may be organised in an informal, democratic • Appointment decisions are usually based on
way information provided by the candidate (their resume or CV)
• Chief programmer teams try to make the most effective use information gained at an interview
of skills and experience
recommendations from other people who know the candidate
Democratic Team Organisation • Some companies use psychological or aptitude tests
• The group acts as a whole and comes to a consensus on There is no agreement on whether or not these tests are actually
decisions affecting the system useful
• The group leader serves as the external interface of the group
but does not allocate specific work items
• Rather, work is discussed by the group as a whole and tasks
are allocated according to ability and experience
• This approach is successful for groups where all members are
experienced and competent
Extreme Programming Groups
• Extreme programming groups are variants of democratic
organisation
• In extreme programming groups, some ‘management’
decisions are devolved to group members
• Programmers work in pairs and take a collective
responsibility for code that is developed

107
 Staff Selection Factors Office Layout
SOFTWARE ENGINEERING

Factor Explanation Meeting

Application domain For a project to develop a successful system, the room
experience developers must understand the application domain.
Platform experience May be significant if low-level programming is
involved. Otherwise, not usually a critical attribute. Office Office W ind ow
Programming language Normally only significant for short duration projects Co mmunal
experience where there is insufficient time to learn a new area
language.
Educational background May provide an indicator of the basic fundamentals
Office Office
which the candidate should know and of their ability
to learn. This factor becomes increasingly irrelevant
as engineers gain experience across a range of Office Of fice
projects.
Communication ability Very important because of the need forproject staff to Sh ared
communicate orally and in writing with other Office Of fice documentation
engineers, managers and customers.
Adaptability Adaptability may be judged by looking at the different
types of experience which candidates have had.This is
an important attribute as it indicates an ability to
learn. The People Capability Maturity Model
Attitude Project staff should have a positive attitude to their
work and should be willing to learn new skills. This
• Intended as a framework for managing the development of
is an important attribute but often very difficult to people involved in software development
assess.
Personality Again, an important attribute but difficult to assess. • Five stage model
Candidates must be reasonably compatible with other
team members. No particular type of personality is Initial : Ad-hoc people management
more or less suited to software engineering.
Repeatable : Policies developed for capability improvement
Defined : Standardised people management across the
organisation
Working Environments
Managed : Quantitative goals for people management in place
• Physical workplace provision has an important
effect on individual productivity and satisfaction Optimising : Continuous focus on improving individual
competence and workforce motivation
Comfort
Privacy The People Capability Maturity Model
Facilities
O pti mi zi n g
• Health and safety considerations must be taken into account C o nt in uo us ly im p rov e m e th od s
for dev e lo pi ng pe rs on a l a nd
Co nt in uo us wo rkfo rc e in no vat io n
Co ach in g
o rg an is a ti on al com p eten ce Perso na l C o m pe t e nc y De v e lo pm en t
Lighting
M a nag ed
Heating Qu ant it a ti vel y m a nag e Org an is ati on al P erform a n c e Al i gn m en t
o rg an is a ti on a l gro wt h in Org an is ati on al C om p eten cy M a n a ge m en t
wo rkfo rce c ap abi li ti e s a n d
Furniture est a bl is h com p eten cy-b a sed
Te am -ba s ed Pra cti ce s
Te am B u il di ng
t ea m s
M ent ori ng
Environmental Factors De fi n ed
Ide n ti fy pri m ary
• Privacy : each engineer requires an area for uninterrupted c om p ete n c ie s an d
a li gn w ork force
P arti cip ato ry C ul tu re
C o m peten cy-b a sed Pra ct ice s
a c ti vi ti es wi th th em C a re er D e ve l op m e nt
work C o m peten cy Dev elo pm e n t
Wo rk forc e Pla n ni ng
• Outside awareness : people prefer to work in natural light Kn ow le d ge a nd Ski ll s An aly si s

Re pe a tab l e
• Personalization : individuals adopt different working Ins t il l b a si c
d is ci pl in e i nt o C o m pe ns ati on
Train in g
practices and like to organize their environment in different wo rkfo rc e
a ctivi ti e s Perform an c e M a n a ge m en t
St affin g
ways C o m m un ic ati on
W o rk e n vi ron m ent

Workspace Organisation I niti al

• Workspaces should provide private spaces where people can

work without interruption
Providing individual offices for staff has been shown to P-CMM Objectives
increase productivity • To improve organisational capability by improving workforce
• However, teams working together also require spaces where capability
formal and informal meetings can be held • To ensure that software development capability is not reliant
on a small number of individuals
• To align the motivation of individuals with that of the
organisation
• To help retain people with critical knowledge and skills

108
Key Points

SOFTWARE ENGINEERING
• Managers must have some understanding of human factors
to avoid making unrealistic demands on people
• Problem solving involves integrating information from
long-term memory with new information from short-term
memory
• Staff selection factors include education, domain experience,
adaptability and personality
• Software development groups should be small and cohesive
• Group communications are affected by status, group size,
group organisation and the sexual composition of the group
• The working environment has a significant effect on
productivity
• The People Capability Maturity Model is a framework for
improving the capabilities of staff in an organisation
Activity
Activity
What factors should be taken into account when selecting staff
What is the difference between syntactic and semantic knowl-
to work on a software development project?
edge? Form your own experience; suggest a number of
instances of each of these types of knowledge.

Activity Activity
As a training manager, you are responsible for the initial Explain why keeping all members of a group informed about
programming language training of a new graduate intake to progress and technical decisions in a project can improve group
your company whose business is the development of defense cohesiveness.
aerospace systems. The principal programming language used is
Ada, which was designed for defense systems programming.
The trainees may be computer science graduates, engineers or
physical scientists. Some but not all of the trainees have
previous programming experience; none have previous
experience in Ada. Explain how you would structure the
programming t4aining for this group of graduates.

109
SOFTWARE ENGINEERING

Activity
Explain what you understand by ‘groupthink’. Describe the
dangers of this phenomenon and explain how it might be
avoided.

Activity
Why are open plan and communal offices sometimes less
suitable for software development than individual officers?
Under what circumstances do you think that open-plan
environments might be better?

Activity
You are a programming manager who has been given the task
of rescuing a project that is critical to the success of the
company. Senior management have given you an open-ended
budget and you may choose a project team of yup to five
people form any other projects going on in the company.
However, a rival company, working in the same area, is actively
recruiting staff and several staff working for your company has
left to join them.
Activity
Describe tow models of programming team organization that Why is the P - CMM an effective framework for improving the
might be used in this situation and make a choice of one of management of people in an organization? Suggest how it may
these models. Give reasons for your choice and explain why you have to be modified if it is to be used in small companies.
have rejected the alternative model.

110
 SOFTWARE ENGINEERING
Notes:

Activity
Should managers become friendly and mix socially with more
junior members of their group?

Activity
Is it ethical to provide the answers which you think the tester
wants rather than saying what you really feel when taking
psychological tests?

111
 UNIT III
MANAGEMENT
LESSON 31 AND 32: UNIT 8
SOFTWARE COST ESTIMATION CHAPTER 18

Predicting the resources required for a software Software Pricing Factors

SOFTWARE ENGINEERING

development process
Objectives Factor Description
Market opportunity A development organisation may quote a low price
• To introduce the fundamentals of software costing and because it wishes to moveinto a new segment of the
pricing software market. Accepting a low profit on one
project may give the opportunityof more profit later.
• To describe three metrics for software productivity The experience gained may allow new products to be
assessment developed.
Cost estimate uncertainty If an organisation is unsure of its cost estimate, it
• To explain why different techniques should be used for may increase its price by some contingency over and
software estimation above its normal profit.
Contractual terms A customer may bewilling to allow the developer to
• To describe the COCOMO 2 algorithmic cost estimation retain ownership of the source code and reuse it in
other projects. The price charged may then be less
model than if the software source code is handed over to the
customer.
Topics Covered Requirements volatility If the requirements are likely to change, an
• Productivity organisation may lower its price to win a contract.
After the contract is awarded, high prices may be
• Estimation techniques charged for changes to the requirements.
Financial health Developers in financial difficulty may lower their
• Algorithmic cost modelling price to gain a contract. It is better to make a small
profit or break even than to go out of business.
• Project duration and staffing
Fundamental Estimation Questions
• How much effort is required to complete an activity?
Programmer Productivity
• How much calendar time is needed to complete an activity?
• What is the total cost of an activity? • A measure of the rate at which individual engineers involved
in software development produces software and associated
• Project estimation and scheduling and interleaved documentation
management activities
• Not quality-oriented although quality assurance is a factor in
Software Cost Components productivity assessment
• Hardware and software costs • Essentially, we want to measure useful functionality
• Travel and training costs produced per time unit
• Effort costs (the dominant factor in most Productivity Measures
projects) • Size related measures based on some output from the
Salaries of engineers involved in the project software process. This may be lines of delivered source code,
Social and insurance costs object code instructions, etc.
• Effort costs must take overheads into account • Function-related measures based on an estimate of the
functionality of the delivered software. Function-points are
Costs of building, heating, lighting
the best known of this type of measure
Costs of networking and communications
Measurement Problems
Costs of shared facilities (e.g. library, staff restaurant, etc
• Estimating the size of the measure
Costing and Pricing
• Estimating the total number of programmer
• Estimates are made to discover the cost, to the developer, of months which have elapsed
producing a software system
• Estimating contractor productivity (e.g.
• There is not a simple relationship between the development documentation team) and incorporating this
cost and the price charged to the customer estimate in overall estimate
• Broader organisational, economic, political and business Lines of Code
considerations influence the price charged
• What’s a line of code?
The measure was first proposed when programs were typed on
cards with one line per card

112
How does this correspond to statements as in Java which can Object Points

SOFTWARE ENGINEERING
span several lines or where there can be several statements on • Object points are an alternative function-related measure to
one line function points when 4Gls or similar languages are used for
• What programs should be counted as part of the system? development
• Assumes linear relationship between system • Object points are NOT the same as object classes
size and volume of documentation • The number of object points in a program is a weighted
Productivity Comparisons estimate of
• The lower level the language, the more The number of separate screens that are displayed
productive the programmer The number of reports that are produced by the system
The same functionality takes more code to implement in a The number of 3GL modules that must be developed to
lower-level language than in a high-level language supplement the 4GL code
• The more verbose the programmer, the higher Object Point Estimation
the productivity
• Object points are easier to estimate from a specification than
Measures of productivity based on lines of code suggest that function points, as they are simply concerned with screens,
programmers who write verbose code are more productive than reports and 3GL modules
programmers who write compact code
• They can therefore be estimated at an early point in the
High And Low Level Languages development process. At this stage, it is very difficult to
estimate the number of lines of code in a system
Low-level language
Productivity Estimates
Analysis Design Coding Validation
• Real-time embedded systems, 40-160
LOC/P-month
High-level language
• Systems programs, 150-400 LOC/P-month
Analysis Design Coding Validation • Commercial applications, 200-800
LOC/P-month

System Development Times

• In object points, productivity has been measured between 4
and 50 object points/month depending on tool support
Analysis Design Coding Testing Documentation and developer capability
Assembly code 3 weeks 5 weeks 8 weeks 10 weeks 2 weeks
High-level language 3 weeks 5 weeks 8 weeks 6 weeks 2 weeks
Size Effort Productivity
Factors Affecting Productivity
Assembly code 5000 lines 28 weeks 714 lines/month
High-level language 1500 lines 20 weeks 300 lines/month
Factor Description
Application domain Knowledge of the application domain is essential for
experience effective software development. Engineers who already
Function Points understand a domain are likely to be the most
productive.
• Based on a combination of program characteristics Process quality The development process used can have a significant
External inputs and outputs effect on productivity. This is covered in Chapter 31.
Project size The larger a project, the more time required for team
User interactions communications. Less time is available for
development so individual productivity is reduced.
External interfaces Technology support Good support technology such as CASE tools,
supportive configuration management systems, etc.
Files used by the system can improve productivity.
• A weight is associated with each of these Working environment As discussed in Chapter 28, a quiet working
environment with private work areas contributes to
• The function point count is computed by multiplying each improved productivity.
raw count by the weight and summing all values
• Function point count modified by complexity of the project
• FPs can be used to estimate LOC depending on the average Quality and Productivity
number of LOC per FP for a given language • All metrics based on volume/unit time are
LOC = AVC * number of function points flawed because they do not take quality into
account
AVC is a language-dependent factor varying from 200-300 for
assemble language to 2-40 for a 4GL • Productivity may generally be increased at the
cost of quality
• FPs are very subjective. They depend on the estimator.
• It is not clear how productivity/quality metrics
Automatic function-point counting is impossible
are related
• If change is constant then an approach based on counting
lines of code is not meaningful

113
 Estimation Techniques Start at the system level and assess the overall system functionali
SOFTWARE ENGINEERING

• There is no simple way to make an accurate estimate of the ty and how this is delivered through sub-systems
effort required to develop a software system • Bottom-up
Initial estimates are based on inadequate information in a user Start at the component level and estimate the effort required for
requirements definition each component. Add these efforts to reach a final estimate
The software may run on unfamiliar computers or use new Top-down Estimation
technology
• Usable without knowledge of the system architecture and
The people in the project may be unknown the components that might be part of the system
• Project cost estimates may be self-fulfilling • Takes into account costs such as integration, configuration
The estimate defines the budget and the product is adjusted to management and documentation
meet the budget • Can underestimate the cost of solving difficult low-level
• Algorithmic cost modelling technical problems
• Expert judgement Bottom-up Estimation
• Estimation by analogy • Usable when the architecture of the system is known and
• Parkinson’s Law components identified
• Pricing to win • Accurate method if the system has been designed in detail
Algorithmic Code Modelling • May underestimate costs of system level activities such as
integration and documentation
• A formulaic approach based on historical cost information
and which is generally based on the size of the software Estimation Methods
Expert Judgement • Each method has strengths and weaknesses
• One or more experts in both software development and the • Estimation should be based on several methods
application domain use their experience to predict software • If these do not return approximately the same result, there is
costs. Process iterates until some consensus is reached. insufficient information available
• Advantages: Relatively cheap estimation method. Can be • Some action should be taken to find out more in order to
accurate if experts have direct experience of similar systems make more accurate estimates
• Disadvantages: Very inaccurate if there are no experts! • Pricing to win is sometimes the only applicable method
Estimation by Analogy Experience-based Estimates
• The cost of a project is computed by comparing • Estimating is primarily experience-based
the project to a similar project in the same • However, new methods and technologies may make
application domain estimating based on experience inaccurate
• Advantages: Accurate if project data available Object oriented rather than function-oriented development
• Disadvantages: Impossible if no comparable project has Client-server systems rather than mainframe systems
been tackled. Needs systematically maintained cost database
Off the shelf components
Parkinson’s Law Component-based software engineering
• The project costs whatever resources are available CASE tools and program generators
• Advantages: No overspend
Pricing to Win
• Disadvantages: System is usually unfinished
• This approach may seem unethical and unbusinesslike
Pricing to Win • However, when detailed information is lacking it may be the
• The project costs whatever the customer has to only appropriate strategy
spend on it
• The project cost is agreed on the basis of an outline proposal
• Advantages: You get the contract and the development is constrained by that cost
• Disadvantages: The probability that the • A detailed specification may be negotiated or an evolutionary
customer gets the system he or she wants is approach used for system development
small. Costs do not accurately reflect the work
required
Algorithmic Cost Modelling
• Cost is estimated as a mathematical function of
Top-down and Bottom-up Estimation product, project and process attributes whose
• Any of these approaches may be used top-down or bottom- values are estimated by project managers
up
Effort = A ´ SizeB ´ M
• Top-down

114
A is an organisation-dependent constant, B reflects the dispro- COCOMO 2 levels

SOFTWARE ENGINEERING
portionate effort for large projects and M is a multiplier • COCOMO 2 is a 3 level model that allows increasingly
reflecting product, process and people attributes detailed estimates to be prepared as development progresses
• Most commonly used product attribute for cost ”estimation • Early prototyping level
is code size
Estimates based on object points and a simple formula is used
• Most models are basically similar but with for effort estimation
different values for A, B and M
• Early design level
Estimation Accuracy Estimates based on function points that are then translated to
• The size of a software system can only be known accurately LOC
when it is finished • Post-architecture level
• Several factors influence the final size Estimates based on lines of source code
Use of COTS and components
Early Prototyping Level
Programming language
• Supports prototyping projects and projects where there is
Distribution of system extensive reuse
• As the development process progresses then the size • Based on standard estimates of developer productivity in
estimate becomes more accurate object points/month
Estimate Uncertainty • Takes CASE tool use into account
• Formula is
4x
PM = (NOP ´ (1 - %reuse/100)) / PROD•PM is the effort in
person-months, NOP is the number of object points and
PROD is the productivity
2x
Object Point Productivity
Developer’s Very low Low Nominal High Very high
x Code experience and
Feasibility Requirements Design Delivery
capability
ICASE maturity and Very low Low Nominal High Very high
0.5x capability
PROD (NOP/month) 4 7 13 25 50

0.25x Early Design Level

• Estimates can be made after the requirements have been
The COCOMO Model agreed
• An empirical model based on project experience • Based on standard formula for algorithmic models
• Well-documented, ‘independent’ model, which is not tied to PM = A ´ SizeB ´ M + PMm where
a specific software vendor M = PERS ´ RCPX ´ RUSE ´ PDIF ´ PREX ´ FCIL ´ SCED
• Long history from initial version published in 1981 PMm = (ASLOC ´ (AT/100)) / ATPROD•A = 2.5 in initial
(COCOMO-81) through various instantiations to calibration, Size in KLOC, B varies from 1.1 to 1.24 depending
COCOMO 2 on novelty of the project, development flexibility, risk manage-
• COCOMO 2 takes into account different approaches to ment approaches and the process maturity
software development, reuse, etc. Multipliers
COCOMO 81 • Multipliers reflect the capability of the developers, the non-
functional requirements, the familiarity with the
Project Formula Description development platform, etc.
complexity
Simple PM = 2.4 (KDSI)1.05 × M Well-understood applications RCPX - product reliability and complexity
developed by small teams.
Moderate PM = 3.0 (KDSI)1.12 × M More complex projects where RUSE - the reuse required
team members may have limited PDIF - platform difficulty
experience of related systems.
Embedded PM = 3.6 (KDSI)1.20 × M Complex projects where the PREX - personnel experience
software is part of a strongly
coupled complex of hardware, PERS - personnel capability
software, regulations and
operational procedures.
SCED - required schedule
FCIL - the team support facilities
• PM reflects the amount of automatically generated code

115
 Post-architecture Level • Personnel attributes
SOFTWARE ENGINEERING

• Uses same formula as early design estimates Multipliers that take the experience and capabilities of the
people working on the project into account.
• Estimate of size is adjusted to take into account
• Project attributes
Requirements volatility. Rework required to support change
Concerned with the particular characteristics of the software
Extent of possible reuse. Reuse is non-linear and has associ- development project
ated costs so this is not a simple reduction in LOC
Project Cost Drivers
ESLOC = ASLOC ´ (AA + SU +0.4DM + 0.3CM +0.3IM)/
100
»ESLOC is equivalent number of lines of new code. ASLOC is Product attributes
RELY Required system DATA Size of database used
the number of lines of reusable code which must be modified, reliability
DM is the percentage of design modified, CM is the percentage CPLX Complexity of system RUSE Required percentage of
of the code that is modified, IM is the percentage of the modules reusable components
DOCU Extent of documentation
original integration effort required for integrating the reused required
software. Computer attributes
TIME Execution time STOR Memory constraints
»SU is a factor based on the cost of software understanding; constraints
AA is a factor, which reflects the initial assessment costs of PVOL Volatility of
development platform
deciding if software may be reused. Personnel attributes
ACAP Capability of project PCAP Programmer capability
The Exponent Term analysts
• This depends on 5 scale factors (see next slide). Their sum/ PCON Personnel continuity AEXP Analyst experience in project
domain
100 is added to 1.01 PEXP Programmer experience LTEX Language and tool experience
• Example in project domain
Project attributes
Precedent ness - new project - 4 TOOL Use of software tools SITE Extent of multi-site working
and quality of site
Development flexibility - no client involvement - Very high - 1 communications
SCED Development schedule
Architecture/risk resolution - No risk analysis - V. Low - 5
compression
Team cohesion - new team - nominal - 3
Process maturity - some control - nominal - 3
Scale factor is therefore 1.17 Project Planning
Exponent Scale Factors
• Algorithmic cost models provide a basis for
project planning as they allow alternative
strategies to be compared
Scale factor Explanation • Embedded spacecraft system
Precedentedness Reflects the previous experience of the organisation
with this type of project. Very low means no previous Must be reliable
experience, Extra high means that the organisation is Must minimise weight (number of chips)
completely familiar with this application domain.
Development Reflects the degree of flexibility in the development Multipliers on reliability and computer constraints > 1
flexibility process. Very low means a prescribed process is used;
Extra high means that the client only sets general goals.
• Cost components
Architecture/risk Reflects the extent of risk analysis carried out. Very low Target hardware
resolution means little analysis, Extra high means a complete a
thoroughrisk analysis.
Development platform
Team cohesion Reflects how well the development team know each Effort required
other and work together. Very low means very difficult
interactions, Extra high means an integrated and Management Options
effective team with no communication problems.
Process maturity Reflects the process maturity of the organisation. The
A. Us e exis ting hardware,
computation of this value depends on the CMM development system and
Maturity Questionnaire but an estimate can be achieved development team
by subtracting the CMM process maturity level from 5.

B. Processor and C. Memory D. More

memory u pg rade upgrade on ly ex perien ced staff
Multipliers Har dware cost in crease Hardware cost
Experience decrease increase
• Product attributes
Concerned with required characteristics of the software product
being developed E. New de velopment F. Staff w ith
s ys tem h ardware experience
• Computer attributes Hardware cost in crease
Constraints imposed on the software by the hardware platform Experience decr ease

116
Management Options Costs • The time to complete a project is not proportional to the

SOFTWARE ENGINEERING
number of people working on the project
Option RELY STOR TIME TOOLS LTEX Total effort Software cost Hardware Total cost

A 1.39 1.06 1.11 0.86 1 63 949393

cost
100000 1049393 Activity
B 1.39 1 1 1.12 1.22 88 1313550 120000 1402025 Describe two metrics that have been used to measure program-
C 1.39 1 1.11 0.86 1 60 895653 105000 1000653
mer productivity. Comment briefly on the advantages and
D 1.39 1.06 1.11 0.86 0.84 51 769008 100000 897490
E 1.39 1 1 0.72 1.22 56 844425 220000 1044159 disadvantages of these metrics.
F 1.39 1 1 1.12 0.84 57 851180 120000 1002706

Option Choice
• Option D (use more experienced staff) appears to be the best
alternative
However, it has a high associated risk, as experienced staff may
be difficult to find
• Option C (upgrade memory) has a lower cost saving but very
low risk
• Overall, the model reveals the importance of staff experience
in software development
Project Duration and Staffing
• As well as effort estimation, managers must estimate the
calendar time required to complete a project and when staff
will be required
• Calendar time can be estimated using a COCOMO 2 formula
TDEV = 3 ´ (PM)(0.33+0.2*(B-1.01))
PM is the effort computation and B is the exponent computed
as discussed above (B is 1 for the early prototyping model).
This computation predicts the nominal schedule for the project
• The time required is independent of the number of people
working on the project Activity
Cost estimates are inherently risky irrespective of the estimation
Staffing Requirements technique used. Suggest four ways in which the risk in a cost
• Staff required can’t be computed by diving the development estimate can be reduced.
time by the required schedule
• The number of people working on a project varies
depending on the phase of the project
• The more people who work on the project, the more total
effort is usually required
• A very rapid build-up of people often correlates with
schedule slippage
Key Points
• Factors affecting productivity include individual aptitude,
domain experience, the development project, the project size,
tool support and the working environment
• Different techniques of cost estimation should be used
when estimating costs
• Software may be priced to gain a contract and the
functionality adjusted to the price
• Algorithmic cost estimation is difficult because of the need
to estimate attributes of the finished product
• The COCOMO model takes project, product, personnel and
hardware attributes into account when predicting effort
required
• Algorithmic cost models support quantitative option
analysis

117
 Activity Activity
SOFTWARE ENGINEERING

Give three reasons why algorithmic cost estimates prepared in Implement the COCOMO model using a spreadsheet such as
different organizations are not directly comparable. Microsoft excel. Details of the model can be downloaded form
the COCOMO2 web site.

Activity
Activity
Some very large software projects involve the writing of
Explain how the algorithmic approach to cost estimation may
millions of lines of code. Suggest how useful the cost estima-
be used by project mangers for option analysis. Suggest a
tion models are likely to be for such systems. Why might the
situation where mangers may choose an approach that is not
assumptions on which they are based be invalid for very large
based on the lowest project cost.
software system?

118
Activity Notes:

SOFTWARE ENGINEERING
Is it ethical for a company to quote a low price for a software
contract knowing that the requirements are ambiguous and that
they can charge a high price for subsequent changes requested by
the customer?

Activity
Should measured productivity be used by managers during the
staff appraisal process? What safeguards are necessary to ensure
that quality is not affected by this?

119
 UNIT III
MANAGEMENT
LESSON 33 AND 34:
QUALITY MANAGEMENT CHAPTER 19

Managing the Quality of the Software Process and Select applicable procedures and standards for a particular project
SOFTWARE ENGINEERING

Products and modify these as required

Objectives • Quality control
• To introduce the quality management process and key quality Ensure that procedures and standards are followed by the
management activities software development team
• To explain the role of standards in quality management • Quality management should be separate from project
• To explain the concept of a software metric, predictor metrics management to ensure independence
and control metrics Quality Management and Software Development
• To explain how measurement may be used in assessing Software development D1 D2 D3 D4 D5
software quality process

Topics Covered
• Quality assurance and standards Quality management
process
• Quality planning
• Quality control Standards and Quality Quality review reports
procedures plan
• Software measurement and metrics
Software Quality Management ISO 9000
• Concerned with ensuring that the required level of quality is • International set of standards for quality management
achieved in a software product • Applicable to a range of organisations from manufacturing
• Involves defining appropriate quality standards and to service industries
procedures and ensuring that these are followed • ISO 9001 applicable to organisations, which design, develops
• Should aim to develop a ‘quality culture’ where quality is seen and maintains products
as everyone’s responsibility • ISO 9001 is a generic model of the quality process must be
What is Quality? instantiated for each organisation
• Quality, simplistically, means that a product should meet its Management responsibility Quality system
specification Control of non-conforming products Design control
Handling, storage, packaging and Purchasing
• This is problematical for software systems delivery
Tension between customer quality requirements (efficiency, Purchaser-supplied products Product identification and traceability
Process control Inspection and testing
reliability, etc.) and developer quality requirements (maintainabil- Inspection and test equipment Inspection and test status
ity, reusability, etc.) Contract review Corrective action
Document control Quality records
Some quality requirements are difficult to specify in an unam- Internal quality audits Training
biguous way Servicing Statistical techniques
Software specifications are usually incomplete and often
inconsistent ISO 9000 Certification
The Quality Compromise • Quality standards and procedures should be documented in
an organisational quality manual
• We cannot wait for specifications to improve before paying
attention to quality management • External body may certify that an organisation’s quality
manual conforms to ISO 9000 standards
• Must put procedures into place to improve quality in spite
of imperfect specification • Customers are, increasingly, demanding that suppliers are
ISO 9000 certified
• Quality management is therefore not just concerned with
reducing defects but also with other product qualities
Quality Management Activities
• Quality assurance
Establish organisational procedures and standards for quality
• Quality planning

120
ISO 9000 and Quality Management • Documentation process standards

SOFTWARE ENGINEERING
How documents should be developed, validated and main-
I S O 90 00
q ua li ty m o d e l s tained
i ns ta n t ia t ed a s
• Document standards
O r g an iz a t io n
do c u m e n ts
O r g an iz a t io n Concerned with document contents, structure, and appearance
q ua li ty m a n u al q ua li ty p r o ce s s

i s u se d t o d e ve lo p i ns ta nt ia t ed a s
• Document interchange standards
How documents are stored and interchanged between different
P r o je c t 1 P r o je c t 2 P r o je c t 3 P r o je c t qu a li ty
q ua li ty p la n q ua li ty p la n q ua li ty p la n m a n a g em e n t documentation systems
Documentation Process
S u pp or t s

Quality Assurance and Standards Incorporate

Create Review Re-draft
review
• Standards are the key to effective quality management initial draft draft
comments
document

• They may be international, national, and organizational or Stage 1:

Creation Approved document
project standards
• Product standards define characteristics that all components
Proofread Produce Check
should exhibit e.g. a common programming style text final draft final dr aft

• Process standards define how the software process should be Stage 2:

Polishing Approved document
enacted
Importance of Standards
Layout Review Produce Print
• Encapsulation of best practice: avoids text layout print masters copies

repetition of past mistakes Stage 3:

Pr oduction
• Framework for quality assurance process : it involves checking
standard compliance
• Provide continuity : new staff can understand Document Standards
the organisation by understand the standards Document identification standards
applied
How documents are uniquely identified
Product and Process Standards • Document structure standards
Product standards Process standards Standard structure for project documents
Design review form Design review conduct
Document naming standards Submission of documents to CM
• Document presentation standards
Procedure header format Version release process Define fonts and styles use of logos, etc.
Ada programming style standard Project plan approval process
Project plan format Change control process • Document update standards
Change request form Test recording process Define how changes from previous versions are reflected in a
document
Problems with Standards
Document Interchange Standards
• Not seen as relevant and up-to-date by software engineers
• Documents are produced using different systems and on
• Involve too much bureaucratic form filling different computers
• Unsupported by software tools so tedious manual work is • Interchange standards allow electronic documents to be
involved to maintain standards
exchanged, mailed, etc.
Standards Development • Need for archiving. The lifetime of word processing systems
• Involve practitioners in development. Engineers should may be much less than the lifetime of the software being
understand the rationale underlying a standard documented
• Review standards and their usage regularly. • XML is an emerging standard for document interchange,
Standards can quickly become outdated and this reduces their which will be widely supported in future
credibility amongst practitioners
Process and Product Quality
• Detailed standards should have associated tool support. • The quality of a developed product is influenced by the
Excessive clerical work is the most significant complaint
quality of the production process
against standards
• Particularly important in software development as some
Documentation Standards product quality attributes are hard to assess
• Particularly important : documents are the tangible • However, there is a very complex and poorly understood
manifestation of the software between software processes and product quality

121
 Process-based Quality Quality Control
SOFTWARE ENGINEERING

• Straightforward link between process and product in • Checking the software development process to ensure that
manufactured goods procedures and standards are being followed
• More complex for software because: • Two approaches to quality control
The application of individual skills and experience is particularly Quality reviews
important in software development Automated software assessment and software measurement
External factors such as the novelty of an application or the
Quality Reviews
need for an accelerated development schedule may impair
product quality • The principal method of validating the quality of a process
or of a product
• Care must be taken not to impose inappropriate process
standards • Group examined part or all of a process or system and its
documentation to find potential problems
Process-based Quality
• There are different types of review with different objectives
Define process
Develop Assess product Inspections for defect removal (product)
product quality
Reviews for progress assessment (product and process)
Quality reviews (product and standards)

Improve
No
Quality
Yes
Standardize Types of Review
process OK process

Review type Principal purpose

Design or program To detect detailed errors in the design or
inspections code and to check whether standards have
Practical Process Quality been followed. The review should be driven
by a checklist of possible errors.
• Define process standards such as how reviews should be Progress reviews To provide information for management
conducted, configuration management, etc. about the overall progress of the project.
This is both a process and a product review
• Monitor the development process to ensure that standards and is concerned with costs, plans and
are being followed schedules.
Quality reviews To carry out a technical analysis of product
• Report on the process to project management and software components or documentation to find faults
or mismatches between the specification
procurer and the design, code or documentation. It
may also be concerned with broader quality
Quality Planning issues such as adherence to standards and
other quality attributes.
• A quality plan sets out the desired product qualities and how
these are assessed and define the most significant quality
attributes Quality Reviews
• It should define the quality assessment process • A group of people carefully examine part or all of a software
• It should set out which organisational standards should be system and its associated documentation.
applied and, if necessary, define new standards • Code, designs, specifications, test plans, standards, etc. can all
Quality Plan Structure be reviewed.

• Product introduction • Software or documents may be ‘signed off ’ at a review,

which signifies that progress to the next development stage
• Product plans has been approved by management.
• Process descriptions
The Review Process
• Quality goals
• Risks and risk management Sel ect Co mplete
rev iew team rev iew fo rms
• Quality plans should be short, succinct documents
Arr ang e p lace
Ho l d rev iew
If they are too long, no one will read them and time

Dis tribu te
Software Quality Attributes d ocumen ts

Safety UnderstandabilityPortability Review Functions

Security Testability Usability
• Quality function : They are part of the general quality
Reliability Adaptability Reusability
management process
Resilience Modularity Efficiency
Robustness Complexity Learnability • Project management function : They provide information for
project managers
• Training and communication function - product knowledge
is passed between development team members

122
Quality Reviews Metrics Assumptions

SOFTWARE ENGINEERING
• Objective is the discovery of system defects and • A software property can be measured
inconsistencies • The relationship exists between what we can measure and
• Any documents produced in the process may be reviewed what we want to know
• Review teams should be relatively small and reviews should • This relationship has been formalized and validated
be fairly short • It may be difficult to relate what can be measured to desirable
• Review should be recorded and records maintained quality attributes
Review Results Internal and External Attributes
• Comments made during the review should be
classified. Number of procedure
No action : No change to the software or documentation is parameters
required. Maintainability
Refer for repair : Designer or programmer should correct an Cyclomatic complexity
identified fault.
Reliability
Reconsider overall design : The problem identified in the
Program size in lines
review impacts other parts of the design. Some overall of code
judgement must be made about the most cost-effective way Portability
of solving the problem. Number of error
• Requirements and specification errors may messages
have to be referred to the client. Usability

Software Measurement and Metrics Length of user manual

• Software measurement is concerned with deriving a numeric
value for an attribute of a software product or process
• This allows for objective comparisons between techniques The Measurement Process
and processes
• A software measurement process may be part of a quality
• Although some companies have introduced measurement control process
programmes, the systematic use of measurement is still
uncommon
• Data collected during this process should be maintained as
an organisational resource
• There are few standards in this area
• Once a measurement database has been established,
Software Metric comparisons across projects become possible
• Any type of measurement, which relates to a software Product Measurement Process
system, process or related documentation
Lines of code in a program, the Fog index, and number of Choose Analyse
person-days required to develop a component measurements anomalous
to be made components
• Allow the software and the software process to
be quantified Select Identify
components to anomalous
• Measures of the software process or product be assessed measurements

• May be used to predict product attributes or to control the Measure

software process component
characteristics
Predictor and Control Metrics

Data Collection
• A metrics programme should be based on a set of product
Software Software and process data
process product
• Data should be collected immediately (not in retrospect) and,
if possible, automatically
Control Predictor • Three types of automatic data collection
measurements measurements
Static product analysis
Dynamic product analysis
Management Process data collation
decisions

123
 Automated Data Collection Software Product Metrics
SOFTWARE ENGINEERING

Software metric Description

Instrumented
Fan in/Fan-out Fan-in is a measure of the number of functions that call some other
function (say X). Fan-out is the number of functions which are called
by function X. A high value for fan-in means that X is tightly

software system
coupled to the rest of the design and changes to X will have
extensive knock-on effects. A high value for fan-out suggests that the
overall complexity of X may be high because of the complexity of
the control logic needed to coordinate the called components.
Length of code This is a measure of the size of a program. Generally, the larger the
size of the code of a program’s components, the more complex and
error-prone that component is likely to be.
Cyclomatic This is a measure of the control complexity of a program. This
complexity control complexity may be related to program understandability. The
computation of cyclomatic complexity is covered in Chapter 20.
Length of This is a measure of the average length of distinct identifiers in a
identifiers program. The longer the identifiers, the more likely they are to be
meaningful and hence the more understandable the program.

Usage Fault
Depth of This is a measure of the depth of nesting of if-statements in a
conditional nesting program. Deeply nested if statements are hard to understand and are
potentially error-prone.

data data Fog index This is a measure of the average length of words and sentences in
documents. The higher the value for the Fog index, the more difficult
the document may be to understand.

Object-oriented Metrics

Data Accuracy
Object- Description
• Don’t collect unnecessary data oriented
metric
The questions to be answered should be decided in advance and Depth of This represents the number of discrete levels in the inheritance tree where
the required data identified inheritance sub-classes inherit attributes and operations (methods) from super-classes.
tree The deeper the inheritance tree, the more complex the design as,
• Tell people why the data is being collected potentially, many different object classes have to be understood to
understand the object classes at the leaves of the tree.
It should not be part of personnel evaluation Method fan- This is directly related to fan-in and fan-out as described above and means
in/fan-out essentially the same thing. However, it may be appropriate to make a
• Don’t rely on memory distinction between calls from other methods within the object and calls
from external methods.
Collect data when it is generated not after a project has finished Weighted This is the number of methods included in a class weighted by the
methods per complexity of each method. Therefore, a simple method may have a
Product Metrics class complexity of 1 and a large and complex method a much higher value. The
larger the value for this metric, the more complex the object class.
• A quality metric should be a predictor of Complex objects are more likely to be more difficult to understand. They
product quality may not be logically cohesive so cannot be reused effectively as super-
classes in an inheritance tree.
• Classes of product metric Number of These are the number of operations in a super-class which are over-ridden
overriding in a sub-class. A high value for this metric indicates that the super-class
Dynamic metrics, which are collected by measurements, made operations used may not be an appropriate parent for the sub-class.
of a program in execution
Static metrics, which are collected by measurements, made of
the system representations Measurement Analysis
Dynamic metrics help assess efficiency and reliability; static • It is not always obvious what data means
metrics help assess complexity, understandability and maintain-
ability Analysing collected data is very difficult
• Professional statisticians should be consulted if available
Dynamic and Static Metrics
• Data analysis must take local circumstances into account
• Dynamic metrics are closely related to software quality
attributes Measurement Surprises
It is relatively easy to measure the response time of a system • Reducing the number of faults in a program leads to an
(performance attribute) or the number of failures (reliability increased number of help desk calls
attribute) The program is now thought of as more reliable and so has a
• Static metrics have an indirect relationship with quality wider more diverse market. The percentage of users who call the
attributes help desk may have decreased but the total may increase
You need to try and derive a relationship between these metrics A more reliable system is used in a different way from a system
and properties such as complexity, understandability and where users work around the faults. This leads to more help
maintainability desk calls

124
Key Points

SOFTWARE ENGINEERING
• Software quality management is concerned with ensuring
that software meets its required standards
• Quality assurance procedures should be documented in an
organisational quality manual Activity
• Software standards are an encapsulation of best practice Briefly describe possible standards which might be used for:
• Reviews are the most widely used approach for assessing • The use of control constructs in C, C++ OR Java.
software quality • Reports which might be submitted for a term project in a
• Software measurement gathers information about both the university:
software process and the software product • The process of purchasing and installing a new computer.
• Product quality metrics should be used to identify potentially
problematical components
• There are no standardised and universally applicable software
metrics
Activity
Explain why a high-quality software process should lead to high
quality software products. Discuss possible problems with this
system of quality management.

Activity
Explain why design metrics are, by themselves, an inadequate
method of predicting design quality.

Activity
What are the stages involved in the review of a software design?

125
 Activity
SOFTWARE ENGINEERING

A colleague who is a very good programmer produces software

with a low number of defects but consistently ignores organiza-
tional quality standards. How should the managers in the
organization react to this behaviour?

Notes:

126
 UNIT III
MANAGEMENT
LESSON 35:
PROCESS IMPROVEMENT CHAPTER 20

Understanding, Modelling and Improving the • Process change introduction

SOFTWARE ENGINEERING
Software Process Modify the process to remove identified bottlenecks
Objectives • Process change training
• To explain the principles of software process improvement Train staff involved in new process proposals
• To explain how software process factors influence software • Change tuning
quality and productivity Evolve and improve process improvements
• To introduce the SEI Capability Maturity Model
The Process Improvement Process
and to explain why it is influential. To discuss
the applicability of that model
• To explain why CMM-based improvement is not universally Introduce
process change
applicable Analyse Identify Tune
process improvements process changes
Topics Covered Train
engineers
• Process and product quality
• Process analysis and modelling Process Process change Training Feedback on Revised process
• Process measurement model plan plan improvements model

• The SEI process maturity model

• Process classification
Process and Product Quality
Process Improvement
• Process quality and product quality are closely
• Understanding existing processes related
• Introducing process changes to achieve organisational • A good process is usually required to produce a
objectives, which are usually focused on quality good product
improvement, cost reduction and schedule acceleration
• For manufactured goods, process is the
• Most process improvement work so far has principal quality determinant
focused on defect reduction. This reflects the increasing
• For design-based activity, other factors are also involved
attention paid by industry to quality
especially the capabilities of the designers
• However, other process attributes can be the focus of
improvement Principal Product Quality Factors

Process Attributes
Development
technology
Process characteristic Description
Understandability To what extent is the process explicitly defined and how easy is it to
understand the process definition?
Visibility Do the process activities culminate in clear results so that the progress

Supportability
of the process is externally visible?
To what extent can the process activities be supported by CASE tools?
Process Product People
Acceptability Is the defined process acceptable to and usable by the engineers quality quality quality
responsible for producing the software product?
Reliability Is the process designed in such a way that process errors are avoided or
trapped before they result in product errors?
Robustness Can the process continue in spite of unexpected problems?
Maintainability Can the process evolve to reflect changing organisational requirements

Rapidity
or identified process improvements?
How fast can the process of delivering a system from a given
Cost, time and
specification be completed? schedule

Process Improvement Stages Quality Factors

• Process analysis • For large projects with ‘average’ capabilities, the development
Model and analyse (quantitatively if possible) existing processes process determines product quality
• Improvement identification • For small projects, the capabilities of the developers is the
Identify quality, cost or schedule bottlenecks main determinant

127
 • The development technology is particularly significant for The Module Testing Activity
SOFTWARE ENGINEERING

small projects
• In all cases, if an unrealistic schedule is imposed then Rôle
product quality will suffer Post-condition
Pre-condition Test All defined tests
Process Analysis and Modelling engineer run on module
• Process analysis Module compiles
without syntax
The study of existing processes to understand the relationships errors Responsible
between parts of the process and to compare them with other for Outputs
processes Test Signed-off test
• Process modelling module record
Input
The documentation of a process, which records the tasks, the Process
Module Module test
roles and the entities, used specification data
Process models may be presented from different perspectives
• Study an existing process to understand its
activities Activities in Module Testing
• Produce an abstract model of the process. You should
normally represent this graphically. Several different views
(e.g. activities, deliverables, etc.) may be required TEST DATA P REPAR ATION
Prepare test da ta
Read mod ule Submit test data
accor d ing to Rev iew tes t d ata
• Analyse the model to discover process specificatio n
specificatio n
fo r rev iew

problems. Involves discussing activities with stakeholders MODULE TEST HARNESS P REPARATI ON

Process Analysis Techniques Ch eck out module

from configuration Read and understan d Prepare test harn ess
fo r module
Compile test
h arn ess
mana g emen t sy stem mo dule interface
• Published process models and process
standards TEST EXECUTION

Inco rporate mod ule Run approved tests Record tes t resu lts
It is always best to start process analysis with an existing model. with test harn ess o n module for regression tes ts

People then may extend and change this. TEST REPORTING

• Questionnaires and interviews Write repo rt on mod ule

tes ting includ ing d etails
Su bmit repo rt Su bmit test
for ap prov al resu lts to CM
of d iscov ered problems
Must be carefully designed. Participants may tell you what they
think you want to hear
• Ethnographic analysis
Involves assimilating process knowledge by observation Process Exceptions
Elements of a Process Model • Software processes are complex and process models cannot
effectively represent how to handle exceptions
Several key people becoming ill just before a critical review
Process model element Description A complete failure of a communication processor so that no e-
Activity An activity h as a clearly de fined obj ective, entry and exit
(represented by a round- condition s. Examples of activities are preparing a set of test mail is available for several days
edged rectangle with no data to test a modul e, coding a function or a modul e, proo f-
drop shadow) reading a docu ment, etc. Generally, an activity is atomic i.e. Organisational reorganisation
it is the respon sibili ty of on e person or group. It i s not
decompos ed into sub-activiti es. A need to respond to an unanticipated request for new
Process A process is a set of activiti es which have som e coherence
(represented by a round- and whose objective is generally agreed within an proposals
edged rectangle with drop organisation. Ex amples of processes are requirements
shadow) analysis, architectural design, t est planning, e tc. • Under these circumstances, the model is suspended and
Deliverable A deliverable is a tangibl e output of an activity which is managers use their initiative to deal with the exception
(represented by a rectangle predicted in a proj ect plan.
with drop shadow)
Condition A condition i s either a pre-condition which mus t hold be fore
Process Measurement
(represented by a a process or activity can start or a post-condit ion wh ich hold s
parallelogr am ) after a process or activity h as finished.
• Wherever possible, quantitative process data should be
Role A role is a bounded area of responsib ility. Ex amples of roles collected
(represented by a circle might b e configu ration manager, test engine er, software
with drop shadow) designer, etc. One person may have several dif ferent rol es However, where organisations do not have clearly defined
and a singl e role may be associated with several diff erent
people. process standards this is very difficult, as you don’t know what
Exception An exception i s a descript ion of ho w to modify the process if to measure. A process may have to be defined before any
(not shown in example s some anticipated or un anticipated event occurs. Exceptions
here but m ay be represented are often und efined and it i s left to th e ingenuity of th e measurement is possible
as a doubl e edged box ) proj ect managers and engineers to h andle the exception.
Communi cation An int erchange of info rmation bet ween people or between • Process measurements should be used to assess process
(represented by an arrow) people and supporting computer systems. Communi cation s
may be inform al or formal. Formal communi cations migh t be
improvements
the approv al of a deliverable by a project manager; informal
communi cations might be the interchange of electroni c mail
to resolve ambiguiti es in a document.

128
But this does not mean that measurements should drive the • Defined

SOFTWARE ENGINEERING
improvements. The improvement driver should be the Process management procedures and strategies defined
organizational objectives and used
Classes of Process Measurement • Managed
• Time taken for process activities to be Quality management strategies defined and used
completed • Optimising
E.g. Calendar time or effort to complete an activity or Process improvement strategies defined and used
process
Key Process Areas
• Resources required for processes or activities
E.g. Total effort in person-days
• Number of occurrences of a particular event Opti mizing
Process change manag emen t
E.g. Number of defects discovered Technolo gy chang e managemen t
Defect prevention
Goal-Question-Metric Paradigm
Ma naged
• Goals Software quality management
Qu antitative process management
What is the organisation trying to achieve? The objective of
process improvement is to satisfy these goals Defined
Peer reviews
• Questions Interg roup coo rdination
Software p rodu ct en gineering
Questions about areas of uncertainty related to the goals. You Integrated softw are management
Traini ng p rogramme
need process knowledge to derive these Organizati on p roces s definition
Organizati on p roces s focus
• Metrics
Measurements to be collected to answer the questions Repeatable
Softw are confi gurat ion management
The Software Engineering Institute Softw are q ualit y assurance
Softw are s ubcontract managemen t
• US Defence Dept. funded institute associated with Carnegie Softw are p roject tracking and oversigh t
Softw are p roject plannin g
Mellon Requirements management

• Mission is to promote software technology transfer

Initial
particularly to defence contractors
• Maturity model proposed in mid-1980s, refined in early
1990s.
SEI Model Problems
• Work has been very influential in process improvement
• It focuses on project management rather than product
The SEI Process Maturity Model development.
• It ignores the use of technologies such as rapid
Level 5 prototyping.
Optimizing
• It does not incorporate risk analysis as a key process area
Le vel 4 • It does not define its domain of applicability
Managed
The CMM and ISO 9000
Level 3 • There is a clear correlation between the key processes in the
Defined
CMM and the quality management processes in ISO 9000
Le vel 2 • The CMM is more detailed and prescriptive and includes a
Repeatable
framework for improvement
Level 1
• Organisations rated as level 2 in the CMM are likely to be
Initial ISO 9000 compliant
Capability Assessment
• An important role of the SEI is to use the CMM to assess
Maturity Model Levels the capabilities of contractors bidding for US government
defence contracts
• Initial
Essentially uncontrolled
• The model is intended to represent organisational capability
not the practices used in particular projects
• Repeatable
• Within the same organisation, there are often wide variations
Product management procedures defined and used in processes used

129
 • Capability assessment is questionnaire-based Process Tool Support
SOFTWARE ENGINEERING

The Capability Assessment Process

Informal Managed Methodical Improving
process process process process
Select projects Distribute Analyse Clarify
for assessment questionnaires responses responses

Configuration Project Analysis and Specialized

Generic management design
Interview management tools
Identify issues Interview Interview tools tools workbenches
for discussion project managers engineers managers tools

Key Points
Brief managers Present Write report
and engineers assessment • Process improvement involves process analysis,
standardisation, measurement and change
• Process models include descriptions of tasks, activities, roles,
Process Classification
exceptions, communications, deliverables and other
• Informal processes
No detailed process model. Development team chose their • Measurement should be used to answer specific
own way of working questions about the software process used
• Managed • The three types of process metrics, which can be collected, are
Defined process model, which drives the development time metrics, resource utilisation metrics and event metrics
process • The SEI model classifies software processes as initial,
• Methodical repeatable, defined, managed and optimising. It identifies
Processes supported by some development method such key processes, which should be used at each of these levels
as HOOD • The SEI model is appropriate for large systems developed by
• Supported large teams of engineers. It cannot be applied without
modification in other situations
Processes supported by automated CASE tools
• Processes can be classified as informal, managed, methodical
Process Applicability and improving. This classification can be used to identify
process tool support

Info rmal
Prototy pes Activity
Short-lifeti me prod ucts Under what circumstances is product quality likely to be
proces s 4GL busines s s ys tems
determined by the quality of the development team? Give
examples of the types of software product that are particularly
dependent on individual talent and ability.
Managed Lar ge sy st ems
proces s Long-lifeti me pro ducts

Well -unders to od
Method ical
applicat io n domai ns
proces s
Re-eng ineered sys tems

Process Choice
• Process used should depend on type of product, which is
being developed
For large systems, management are usually the principal
problem so you need a strictly managed process. For smaller
systems, more informality is possible.
• There is no uniformly applicable process, which should be
standardised within an organisation
High costs may be incurred if you force an inappropriate
process on a development team

130
Activity

SOFTWARE ENGINEERING
Describe three types of software process metric that may be
collected as par of a process improvement process. Give one
example of each type of metric.

Activity
Consider the type of software process used in your organiza-
tion. How many of the key process areas identified in the SEI
model are used? How would this model classify your level of
process maturity?

Activity
Give two advantages and two disadvantages of the approach to
process assessment and improvement which is embodied in the
SEI process maturity model.

Activity
Suggest three specialized software tools which might be
developed to support a process improvement programme in an
organization

Activity
Suggest two application domains where the SEI capability
model is unlikely to be appropriate. Give reasons why this is the
case.

131
 UNIT IV
ENVOLUTION
LESSON 36: UNIT 9
LEGACY SYSTEMS CHAPTER 21

Older Software Systems That Remain Vital to an The Legacy Dilemma

SOFTWARE ENGINEERING

Organisation • It is expensive and risky to replace the legacy system

Objectives • It is expensive to maintain the legacy system
• To explain what is meant by a legacy system and why these • Businesses must weigh up the costs and risks and may
systems are important choose to extend the system lifetime using techniques such
• To introduce common legacy system structures as re-engineering.
• To briefly describe function-oriented design Legacy System Structures
• To explain how the value of legacy systems can be assessed • Legacy systems can be considered to be socio-technical
systems and not simply software systems
Topics Covered
• System hardware : May be mainframe hardware
• Legacy system structures
• Support software : Operating systems and utilities
• Legacy system design
• Application software : Several different programs
• Legacy system assessment
• Application data : Data used by these programs that is often
Legacy Systems critical business information
• Software systems that are developed specially for an • Business processes : The processes that support a business
organisation have a long lifetime
objective and which rely on the legacy software and hardware
• Many software systems that are still in use were developed • Business policies and rules : Constraints on business
many years ago using technologies that are now obsolete
operations
• These systems are still business critical that is, they are
essential for the normal functioning of the business
Legacy System Components
• They have been given the name legacy systems Embeds
knowledge of
Uses
Legacy System Replacement Support Application Business policies
software software and rules
• There is a significant business risk in simply scrapping a
legacy system and replacing it with a system that has been Runs-on Runs-on Uses Uses Constrains
developed using modern technology
• Legacy systems rarely have a complete specification. During System Application Business
hardware data processes
their lifetime they have undergone major changes, which may
not have been documented
• Business processes are reliant on the legacy system Layered Model
• The system may embed business rules that are not formally
documented elsewhere S o c io -t e c h n i c al s ys t e m
• New software development is risky and may not be
successful B u si ne s s p r oc e s se s
Legacy System Change
• Systems must change in order to remain useful A p pl i ca t io n so f tw a r e
• However, changing legacy systems is often expensive
S u pp ort so f tw a r e
• Different parts implemented by different teams so no
consistent programming style
• The system may use an obsolete programming language H ard w a re
• The system documentation is often out-of-date
• The system structure may be corrupted by many years of System Change
maintenance
• In principle, it should be possible to replace a layer in the
• Techniques to save space or increase speed at the expense of system leaving the other layers unchanged
understandability may have been used
• In practice, this is usually impossible
• File structures used may be incompatible

132
• Changing one layer introduces new facilities and higher-level • Rather than being organised as a set of interacting objects,

SOFTWARE ENGINEERING
layers must then change to make use of these these systems have been designed using a function-oriented
• Changing the software may slow it down so hardware design strategy
changes are then required • Several methods and CASE tools are available to support
• It is often impossible to maintain hardware interfaces function-oriented design and the approach is still used for
because of the wide gap between mainframes and client- many business applications
server systems A Function-oriented View of Design
Legacy Application System
P r o g ra m 1 P rog ra m 2 P rog ra m 3
Sh ared m em ory

F i le 1 F i le 2 F i le 3 F i le 4 F i le 5 F i le 6

P r o g ra m 4 P ro g ra m 5 P rog ra m 6 P rog ra m 7

F1 F2 F3
Database-centred System

Program Program Program Program

1 2 3 4

F4 F5

Database describes Logical and

management physical
system data models Input-process-output Model

Transaction Processing System

Account queries
and updates
Serialised
transactions
Teleprocessing Accounts
monitor database Input Process Output

Input-process-output
ATM s and terminals • Input components read and validate data from a terminal or
file
Legacy Data • Processing components carry out some transformations on
• The system may be file-based with incompatible files. The that data
change required may be to move to a database-management • Output components format and print the results of the
system computation
• In legacy systems that use a DBMS (the database • Input, process and output can all be represented as functions
management system) may be obsolete and incompatible with data ‘flowing’ between them
with other DBMSs used by the business
Functional Design Process
• The teleprocessing monitor may be designed for a particular • Data-flow design
DB and mainframe. Changing to a new DB may require a
new TP monitor Model the data processing in the system using data-flow
diagrams
Legacy System Design
• Structural decomposition
• Most legacy systems were designed before object-oriented
Model how functions are decomposed to sub-functions using
development was used
graphical structure charts that reflect the input/process/output
structure

133
 • Detailed design Design Description of an ATM
SOFTWARE ENGINEERING

The functions in the design and their interfaces are described in

detail. These may be recorded in a data dictionary and the design INPUT
expressed using a PDL loop
repeat
Data Flow Diagrams Print_input_message (” Welcome - Please enter your card”) ;
until Card_input ;

• Show how an input data item is functionally transformed by Account_number := Read_card ;

Get_account_details (PIN,Account_balance, Cash_available) ;
a system into an output data item
PROCESS
• Are an integral part of many design methods and are if Invalid_card (PIN)then
supported by many CASE systems Retain_card ;
Print ("Card retained - please contact your bank") ;
else
• May be translated into either a sequential or parallel design. repeat
Print_operation_select_message ;
In a sequential design, processing elements are functions or Button := Get_button ;
case Get_button is
procedures; in a parallel design, processing elements are tasks when Cash_only =>
Dispense_cash (Cash_available, Amount_dispensed) ;
when Print_balance =>
or processes Print_customer_balance (Account_balance) ;
when Statement =>
Order_statement (Account_number) ;
when Check_book =>
Order_checkbook (Account_number) ;
end case ;
Payroll System DFD Print ("Press CONTINUE for more services or ST
Button := Get_button ;
OP to finish");

until Button = STOP ;

OUTPUT
Write tax Tax
transaction transactions
Tax deduction + SS Eject_card ;
Employee number +tax office Print (“Please take your card ) ;
records Update_account_information (Account_number
, Amount_dispensed) ;
Write pension Pension data
Monthly pay data end loop ;
rates
Decoded Pension
Read employee employee deduction +
record Valid
record employee record SS number
Validate Compute
employee data Print payslip
salary Empoyee data +
deductions
PRIN TER
Using Function-oriented Design
Read monthly Pay information Net payment + bank
pay data
Tax
account info.
Write bank Bank
• For some classes of system, such as some transaction
tables transaction transactions
processing systems, a function-oriented approach may be a
Monthly pay better approach to design than an object-oriented approach
data Social security
Write s ocial
deduction + SS number
s ecurity data
Social
s ecurity dat a • Companies may have invested in CASE tools and methods
for function-oriented design and may not wish to incur the
costs and risks of moving to an object-oriented approach
Payroll Batch Processing
Legacy System Assessment
• The functions on the left of the DFD are input functions • Organisations that rely on legacy systems must choose a
Read employee record, Read monthly pay data, Validate strategy for evolving these systems
employee data
• Scrap the system completely and modify business processes
• The central function : Compute salary : carries out the so that it is no longer required
processing
• Continue maintaining the system
• The functions to the right are output functions • Transform the system by re-engineering to improve its
Write tax transaction, Write pension data, Print payslip, Write maintainability
bank transaction, and Write social security data
• Replace the system with a new system
Transaction Processing • The strategy chosen should depend on the system quality
• A bank ATM system is an example of a transaction and its business value
processing system
System Quality and Business Value
• Transactions are stateless in that they do not rely on the
result of previous transactions. Therefore, a functional Business value
High business value
approach is a natural way to implement transaction Low quality High business value
High quality
processing
9
10 8
6
7

Low business value Low business value

Low quality High quality

2 5
1 3 4

System quality

134
Legacy System Categories Application Assessment

SOFTWARE ENGINEERING
• Low quality, low business value : These systems should be
scrapped
• Low-quality, high-business value : These make an important Factor Questions
Understandability How difficult is it to understand thesource code of the current system?
business contribution but are expensive to maintain. Should How complex are the control structures which are used? Do variables
be re-engineered or replaced if a suitable system is available have meaningful names that reflect their function?
Documentation What system documentation is available? Is the documentation
• High-quality, low-business value : Replace with COTS, scrap Data
complete, consistent and up-to-date?
Is there an explicit data model for the system? Towhat extent is data
completely or maintain duplicated in different files? Is the data used by thesystem up-to-date
and consistent?
• High-quality, high business value : Continue in operation Performance Is the performance of the application adequate? Do performance
using normal system maintenance problems have a significant effect onsystem users?
Programming Are modern compilers available for the programming language used to
language develop the system? Is the programming language still used for new
Business Value Assessment system development?
Configuration Are all versions of all parts of the system managed bya configuration
• Assessment should take different viewpoints into account management management system? Is there an explicit description of the versions of
components that are used in thecurrent system?
System end-users Test data Does test data for the system exist? Is there a record of regression tests
carried out when newfeatures have been addedto the system?
Business customers Personnelskills Are there people available who havethe skills to maintain the
application? Are there only a limited number of people who understand
Line managers the system?
IT managers
Senior managers
System Measurement
• Interview different stakeholders and collate results • You may collect quantitative data to make an assessment of
System Quality Assessment the quality of the application system
• Business process assessment : How well does the business • The number of system change requests
process support the current goals of the business? • The number of different user interfaces used by the system
• Environment assessment : How effective is the system’s • The volume of data used by the system
environment and how expensive is it to maintain?
Key Points
• Application assessment : What is the quality of the
application software system? • A legacy system is an old system that still provides essential
business services
Business Process Assessment
• Legacy systems are not just application software but also
• Use a viewpoint-oriented approach and seek answers from include business processes, support software and hardware
system stakeholders
• Most legacy systems are made up of several different
• Is there a defined process model and is it followed? programs and shared data
• Do different parts of the organisation use different processes • A function-oriented approach has been used in the design of
for the same function? most legacy systems
• How has the process been adapted? • The structure of legacy business systems normally follows an
• What are the relationships with other business processes and input-process-output model
are these necessary? • The business value of a system and its quality should be
• Is the process effectively supported by the legacy application used to choose an evolution strategy
software? • The business value reflects the system’s effectiveness in
Environment Assessment supporting business goals
Factor Questions • System quality depends on business processes, the system’s
Supplier Is the supplier is still in existence? Is the supplier financially stable and environment and the application software
stability likely to cont inue in existence? If the supplier is no longer in business,
are the systems maintained by someone else?
Failure rate Does the hardware have a high rate of reported failures? Does the
support software crash and force system restarts?
Age How old is the hardware and software? The older the hardware and
support software, the more obsolete it will be. It may still function
correctly but th ere could b e significant economic and bu siness benefits
to moving to more modern systems.
Performance Is the p erformance of the system adequate? Do performance problems
have a significant effect on system users?
Support What local support is required by th e hardware and software? If there
requirements are high costs associated with this support, it may be worth considering
system replacement.
Maintenance What are the costs of hardware maintenance and suppo rt software
costs licences? Older hardware may have higher maintenance costs than
modern systems. Suppo rt software may have h igh annual licensing
costs.
Interoperability Are there problems interfacing the system to othe r systems? Can
compilers etc. be used with current versions of the op erating system? Is
hardware emulation required?

135
 Activity Activity
SOFTWARE ENGINEERING

Explain why legacy systems may be critical to the operation of a What difficulties are likely to arise when different components
business. of a legacy system are implemented in different programming
languages?

Activity Activity
Suggest three reasons why software systems become more Why is it necessary to use a teleprocessing monitor when
difficult to understand when different people are involved in requests to update data in a system come form a number of
changing these systems. different terminals? How do modern client-server systems
reduce the load on the teleprocessing monitor?

136
Activity Activity

SOFTWARE ENGINEERING
Most legacy systems use a function oriented approach to design. Suggest 10 questions that might be put to end users of a
Explain why this approach to design may be more appropriate system when carrying out a business process assessment.
for these systems than an object oriented design strategy.

Activity Activity
Under what circumstances might an organization decide to scrap Explain why problems with support software might mean that
a system when the system assessment suggests that it is of an organization has to replaces its legacy systems.
high quality and high business value?

137
 Activity
SOFTWARE ENGINEERING

The management of an organization has asked you to carry out

a system assessment and has suggested to you that they would
like the results of that assessment to show that the system is
obsolete and that it should be replaced by a new system. This
will mean that a number of system maintainers are made
redundant. Your assessment actually shoes that the system is
well maintained and is of high quality and high business value.
How would you report these results to the management of the
organization?

Notes:

138
 UNIT IV
ENVOLUTION
LESSON 37:
SOFTWARE CHANGE CHAPTER 22

Managing the Processes of Software System Change Lehman’s laws

SOFTWARE ENGINEERING
Objectives
Law Description
• To explain different strategies for changing software systems Continuing change A program that is used in a real-world environment
necessarily must change or become progressively less
Software maintenance useful in that environment.
Increasing complexity As an evolving program changes, its structure tends
Architectural evolution to become more complex. Extra resources must be
devoted to preserving and simplifying the structure.
Software re-engineering Large program evolution Program evolution is a self-regulating process.
System attributes such as size, time between releases
• To explain the principles of software maintenance and the number of reported errors are approximately
• To describe the transformation of legacy systems from invariant for each system release.
Organisational stability Over a program’s lifetime, its rate of development is
centralised to distributed architectures approximately constant and independent of the
resources devoted to system development.
Topics Covered Conservation of Over the lifetime of a system, the incremental change
familiarity in each release is approximately constant.
• Program evolution dynamics
• Software maintenance
Applicability of Lehman’s Laws
• Architectural evolution
• This has not yet been established
Software Change • They are generally applicable to large, tailored systems
• Software change is inevitable developed by large organisations
New requirements emerge when the software is used • It is not clear how they should be modified for
The business environment changes Shrink-wrapped software products
Errors must be repaired Systems that incorporate a significant number of COTS
New equipment must be accommodated components
The performance or reliability may have to be improved Small organisations
• A key problem for organisations is implementing and Medium-sized systems
managing change to their legacy systems Software Maintenance
Software Change Strategies • Modifying a program after it has been put into use
• Software maintenance • Maintenance does not normally involve major changes to the
Changes are made in response to changed requirements but the system’s architecture
fundamental software structure is stable • Changes are implemented by modifying existing
• Architectural transformation components and adding new components to the system
The architecture of the system is modified generally from a Maintenance is Inevitable
centralised architecture to a distributed architecture • The system requirements are likely to change while the
• Software re-engineering system is being developed because the environment is
No new functionality is added to the system but it is restruc- changing. Therefore a delivered system won’t meet its
tured and reorganised to facilitate future changes requirements!
• These strategies may be applied separately or together • Systems are tightly coupled with their environment. When a
system is installed in an environment it changes that
Program Evolution Dynamics environment and therefore changes the system requirements.
• Program evolution dynamics is the study of the processes of
• Systems MUST be maintained therefore if they are to remain
system change
useful in an environment
• After major empirical study, Lehman and Belady proposed
that there were a number of ‘laws’, which applied to all
Types of Maintenance
systems as they evolved • Maintenance to repair software faults
• There are sensible observations rather than laws. They are Changing a system to correct deficiencies in the way meets
applicable to large systems developed by large organisations. its requirements
Perhaps less applicable in other cases • Maintenance to adapt software to a different operating
environment

139
 Changing a system so that it operates in a different environ- Development/Maintenance Costs
SOFTWARE ENGINEERING

ment (computer, OS, etc.) from its initial implementation

• Maintenance to add to or modify the system’s functionality
S y st e m 1
Modifying the system to satisfy new requirements
S y st e m 2
Distribution of Maintenance Effort
0 50 1 00 1 50 2 00 2 50 3 00 3 50 4 00 4 50 5 00 $

D e v e lo pm e n t c os ts M a in te n a nc e c os ts

Fault repair Maintenance Cost Factors

(17%)
• Team stability
Maintenance costs are reduced if the same staff are involved
with them for some time
Functionality
Software addition or • Contractual responsibility
adaptation modification
(18%) The developers of a system may have no contractual responsi-
(65%)
bility for maintenance so there is no incentive to design for
future change
• Staff skills
Maintenance staff are often inexperienced and have limited
domain knowledge
• Program age and structure
As programs age, their structure is degraded and they become
Spiral Maintenance Model harder to understand and change
Evolutionary Software
• Rather than think of separate development and maintenance
phases, evolutionary software is software that is designed so
that it can continuously evolve throughout its lifetime
The Maintenance Process

Specification Implemention
Change Impact System release Change System
requests analysis planning implementation release

Start
Perfective Adaptive Corrective
Release 1 maintenance maintenance maintenance

Operation Validation
Change Requests
Release 2 • Change requests are requests for system changes from users,
customers or management
Release 3 • In principle, all change requests should be carefully analysed
as part of the maintenance process and then implemented
• In practice, some change requests must be implemented
urgently
Maintenance Costs Fault repair
• Usually greater than development costs (2* to 100* Changes to the system’s environment
depending on the application) Urgently required business changes
• Affected by both technical and non-technical factors
Change Implementation
• Increases as software is maintained. Maintenance corrupts the
software structure so makes further maintenance more
difficult. Proposed Requirements Requirements Software
changes analysis updating development
• Ageing software can have high support costs (e.g. old
languages, compilers etc.)

140
Emergency Repair Number of outstanding change requests

SOFTWARE ENGINEERING
Change Analyze Modify Deliver modified • If any or all of these is increasing, this may indicate a decline
requests source code source code system in maintainability
Architectural Evolution
Maintenance Prediction
• There is a need to convert many legacy systems from a
• Maintenance prediction is concerned with assessing which centralised architecture to client-server architecture
parts of the system may cause problems and have high
maintenance costs • Change drivers
Change acceptance depends on the maintainability of the Hardware costs : Servers are cheaper than mainframes
components affected by the change User interface expectations : Users expect graphical user interfaces
Implementing changes degrades the system and reduces its Distributed access to systems : Users wish to access the system
maintainability from different, geographically separated, computers
Maintenance costs depend on the number of changes and costs Distribution Factors
of change depend on maintainability
Maintenance Prediction Factor Description
Business Returns on the investment of distributing a legacy system
What parts of the system
importance depend on its importance to the business and howlong it
will be the most expensive will remain important. If distribution provides more efficient
What parts of the system are to maintain?
most likely to be affected by support for stable business processes then it is more likely to
change requests?
Predicting be a cost-effective evolution strategy.
maintainability System age The older the system the more difficult it will be to modify
its architecture because previous changes will have degraded
What will be the lifetime the structure of the system.
maintenance costs of this
Predicting system Predicting system? System structure The more modular the system, the easier it will be to change
maintenance
changes
costs the architecture. If the application logic, the data
management and the user interface of the system are closely
What will be the costs of intertwined, it will be difficult to separate functions for
How many change
requests can be
maintaining this system
over the next year?
migration.
expected? Hardware Application distribution may be necessary if there is
procurement company policy to replace expensive mainframe computers
policies with cheaper servers. .

Change Prediction
• Predicting the number of changes requires and Legacy System Structure
understanding of the relationships between a system and its • Ideally, for distribution, there should be a clear separation
environment between the user interface, the system services and the
• Tightly coupled systems require changes whenever the system data management
environment is changed • In practice, these are usually intermingled in older legacy
• Factors influencing this relationship are systems
Number and complexity of system interfaces Legacy System Structures
Number of inherently volatile system requirements
U s e r i nt e rfa c e
The business processes where the system is used U s e r i n t e r fa c e

Complexity Metrics S e rv i c e s
S e rvi c e s
• Predictions of maintainability can be made by assessing the
complexity of system components D a t a ba s e D a t a ba s e

• Studies have shown that most maintenance effort is spent I d e a l m o d e l f o r d i st rib u t io n R e a l le g a c y s y s te m s

on a relatively small number of system components
• Complexity depends on Layered Distribution Model
Complexity of control structures
Complexity of data structures Presen tatio n

Procedure and module size Dat a v alidat io n

Process Metrics
Interacti on co nt rol
• Process measurements may be used to assess maintainability
Number of requests for corrective maintenance Ap plicatio n serv ices
Average time required for impact analysis
Dat abas e
Average time taken to implement a change request

141
 Legacy System Distribution Key Points
SOFTWARE ENGINEERING

Desktop PC clients running application

• Software change strategies include software maintenance,
architectural evolution and software re-engineering
Legacy system
Application
• Lehman’s Laws are invariant relationships that affect the
services
Middleware layer (wrapper)
evolution of a software system
Database
• Maintenance types are
User interface

Legacy system Maintenance for repair

Maintenance for a new operating environment
Character terminals
Maintenance to implement new requirements
Distribution Options • The costs of software change usually exceed the costs of
software development
• The more that is distributed from the server to the client, the
higher the costs of architectural evolution • Factors influencing maintenance costs include staff stability,
the nature of the development contract, skill shortages and
• The simplest distribution model is UI distribution where
degraded system structure
only the user interface is implemented on the server
• Architectural evolution is concerned with evolving centralised
• The most complex option is where the server simply
to distributed architectures
provides data management and application services are
implemented on the client • A distributed user interface can be supported using screen
management middleware
Distribution Option Spectrum
Activity
Server: Interaction control
Data validation
Server: Services
Database Server:Database Explain why a software system which is used in a real world
Services
Database
environment must change or become progressively less useful.

Client: Presentation Client: Presentation Client: Presentation

Interaction control Interaction control
Data validation Data validation
Services

Increasing cost
and effort

User Interface Distribution

• UI distribution takes advantage of the local processing
power on PCs to implement a graphical user interface
• Where there is a clear separation between the UI and the
application then the legacy system can be modified to
distribute the UI
• Otherwise, screen management middleware can translate text
interfaces to graphical interfaces
Desktop PC clients with
GUI interface
Screen descriptions

Legacy system

Application
services
Screen management
Database middleware

User interface

UI Migration Strategies

Strategy Advantages Disadvantages

Implementation Access to all UI functions so no Platform dependent
using the window real restrictions onUI design May be more difficult to achieve
management Better UI performance interface consistency
system
Implementation Platform independent Potentially poorer UI
using a web Lower training costs due to user performance
browser familiarity with the WWW Interface design is constrained
Easier to achieve interface by the facilities provided by web
consistency browsers

142
Activity Activity

SOFTWARE ENGINEERING
Explain the difficulties of measuring program maintainability. Two major international banks with different customer
Suggest why you should use several different complexity information databases merge and decide that they need to
metrics when trying to assess the maintainability of a program. provide access to all customer information form all bank
branches. Giving reasons for your answer, suggest the most
appropriate strategy for providing access to these systems and
briefly discuss how the solution might be implemented.

Activity
As a software project manager in a company that specializes in
Activity
the development of software for the offshore oil industry, you
Do software engineers have a professional responsibility to
have been given the task of discovering those factors which
produce maintainable code even if this is not explicitly re-
affect the maintainability of the particular systems which are
quested by their employer?
developed by your company. Suggest how you might set up a
programme to analyze the maintenance process to discover
appropriate maintainability metrics for your company.

143
 UNIT IV
ENVOLUTION
LESSON 38:
SOFTWARE RE-ENGINEERING CHAPTER 23

Reorganising and Modifying Existing Software • May force software re-engineering as the legacy systems are
SOFTWARE ENGINEERING

Systems to Make them More Maintainable designed to support existing processes

Objectives Forward Engineering And Re-engineering
• To explain why software re-engineering is a cost-effective
System Design and New
option for system evolution specification implementation system
• To describe the activities involved in the software re- Forward engineering
engineering process
• To distinguish between software and data re-engineering and Existing Understanding and Re-engineered
software system transformation system
to explain the problems of data re-engineering
Software re-engineering
Topics Covered
• Source code translation
The Re-engineering Process
• Reverse engineering
• Program structure improvement Original
Program
documentation
Modularised
program
Original data
program
• Program modularisation
Reverse
engineering
• Data re-engineering
Data
Source code Program reengineering
System Re-engineering translation modularisation

• Re-structuring or re-writing part or all of a legacy system Program

structure
without changing its functionality improvement
Structured Reengineered
• Applicable where some but not all sub-systems of a larger program data
system require frequent maintenance
• Re-engineering involves adding effort to make them easier to Re-engineering Cost Factors
maintain. The system may be re-structured and re-
documented • The quality of the software to be re-engineered
• The tool support available for re-engineering
When to Re-engineer
• The extent of the data conversion, which is required
• When system changes are mostly confined to
part of the system then re-engineer that part • The availability of expert staff for re-engineering
• When hardware or software support becomes Re-engineering Approaches
obsolete
Automated progr am Program and data
• When tools to support re-structuring are restructuring restructuring

available
Re-engineering Advantages Automated source Automated restructuring Restructuring plus
code conversion with manual changes architectural changes
• Reduced risk
There is a high risk in new software development. There may be Increased cost
development problems, staffing problems and specification
problems
• Reduced cost Source Code Translation
The cost of re-engineering is often significantly less than the • Involves converting the code from one language (or language
costs of developing new software version) to another e.g. FORTRAN to C
• May be necessary because of:
Business Process Re-engineering
Hardware platform update
• Concerned with re-designing business processes to make
them more responsive and more efficient Staff skill shortages
• Often reliant on the introduction of new computer systems Organisational policy changes
to support the revised processes • Only realistic if an automatic translator is available

144
The Program Translation Process Restructuring Problems

SOFTWARE ENGINEERING
System to be System to be Re-engineered
• Problems with re-structuring are:
re-engineered re-engineered system
Loss of comments
Loss of documentation
Identify source Design translator Automatically Manually Heavy computational demands
code differences instructions translate code translate code
• Restructuring doesn’t help with poor modularisation where
related components are dispersed throughout the code
Reverse Engineering
• The understandability of data-driven programs may not be
• Analysing software with a view to understanding its design improved by re-structuring
and specification
• May be part of a re-engineering process but may also be used
Program Modularisation
to re-specify a system for re-implementation • The process of re-organising a program so that related
program parts are collected together in a single module
• Builds a program data base and generates information from
this • Usually a manual process that is carried out by program
inspection and re-organisation
• Program understanding tools (browsers, cross-reference
generators, etc.) may be used in this process Module Types
The Reverse Engineering Process • Data abstractions :A bstract data types where data structures
and associated operations are grouped
Program stucture
diagrams
• Hardware modules : All functions required to interface with a
Automated
analysis hardware unit
System
Systemto be
information
Document Data stucture • Functional modules : Modules containing functions that
re-engineered generation diagrams
store carry out closely related tasks
Manual
annotation Traceability • Process support modules : Modules where the functions
matrices support a business process or process fragment
Recovering Data Abstractions
• Reverse engineering often precedes re-engineering but is
sometimes worthwhile in its own right
• Many legacy systems use shared tables and global data to save
memory space
The design and specification of a system may be reverse
engineered so that they can be an input to the requirements
• Causes problems because changes have a wide impact in the
system
specification process for the system’s replacement
• Shared global data may be converted to objects or ADTs
The design and specification may be reverse engineered to
support program maintenance Analyse common data areas to identify logical abstractions
Create an ADT or object for these abstractions
Program Structure Improvement
Use a browser to find all data references and replace with
• Maintenance tends to corrupt the structure of a program. It
reference to the data abstraction
becomes harder and harder to understand
• The program may be automatically restructured to remove Data Abstraction Recovery
unconditional branches • Analyse common data areas to identify logical abstractions
• Conditions may be simplified to make them more readable • Create an abstract data type or object class for each of these
abstractions
Condition Simplification
Complex condition • Provide functions to access and update each field of the data
abstraction
if not (A > B and (C < D or not (E > F)))...
Simplified condition
• Use a program browser to find calls to these data
abstractions and replace these with the new defined functions
if (A <= B and (C>= D or E > F)...
Data Re-engineering
Automatic Program Restructuring
• Involves analysing and reorganising the data structures (and
Program to be Restructur ed sometimes the data values) in a program
restructured program
• May be part of the process of migrating from a file-based
system to a DBMS-based system or changing from one
Analyser and Program
graph builder generator
DBMS to another
• Objective is to create a managed data environment
Graph
repr esentation

145
 Approaches to Data Re-engineering • Data naming problems
SOFTWARE ENGINEERING

Names may be hard to understand. The same data may have

Approach Description
Data cleanup The data records and values are analysed to improve their quality.
different names in different programs
Duplicates are removed, redundant information is deleted and a consistent • Field length problems
format applied to all records. This should not normally require any
associated program changes. The same item may be assigned different lengths in different
Data extension In this case, the data and associated programs are re-engineered to remove
limits on the data processing. This may require changes to programs to programs
increase field lengths, modify upper limits on the tables, etc. The data itself
may then have to be rewritten and cleaned up to reflect the program • Record organisation problems
changes.
Data migration In this case, data is moved into the control of a modern database Records representing the same entity may be organised differ-
management system. The data may be stored in separate files or may be ently in different programs
managed by an older type of DBMS.
• Hard-coded literals
• No data dictionary
Data Problems
Data Conversion
• End-users want data on their desktop machines rather than
in a file system. They need to be able to download this data
• Data re-engineering may involve changing the data structure
organisation without changing the data values
from a DBMS
• Systems may have to process much more data than was • Data value conversion is very expensive. Special-purpose
programs have to be written to carry out the conversion
originally intended by their designers
• Redundant data may be stored in different formats in The Data Re-engineering Process
different places in the system
Data
Data Value Inconsistencies Program to be re-engineered
analysis

Data inconsistency Description

Inconsistent default Different programs assign different default values to the same logical data
values items. This causes problems for programs other than those that created the
data. The problem is compounded when missing values are assigned a Entity name Data
default value that is valid. The missing data cannot then be discovered. modification re-formatting
Inconsistent units The same information is represented in different units in different Data Literal Default value Data
programs. For example, in the US or the UK, weight data may be analysis
represented in pounds in older programs but in kilograms in more recent
replacement conversion conversion
systems. A major problem of this type has arisen in Europe with the Data definition Validation rule
introduction of a single European currency. Legacy systems have bee n re-ordering modification
written to deal with national currency units and data has to be converted to
euros.
Inconsistent validation Different programs apply different data validation rules. Data written by Stage 1 Stage 2 Stage 3
rules one program may be rejected by another. This is a particular problem for
archival data which may not have been updated in line with changes to Change summary tables Modified
data validation rules. data
Inconsistent Programs assume some meaning in the way items are represented. For
representation example, some programs may assume that upper-case text means an
semantics address. Programs may use different conventions and may therefore reject
data which is semantically valid.
Inconsistent handling
of negative values
Some programs reject negative values for entities which must always be
positive. Others, however, may accept these as negative values or fail to Key Points
recognise them as negative and convert them to a positive value.
• The objective of re-engineering is to improve the system
structure to make it easier to understand and maintain
Data Migration • The re-engineering process involves source code translation,
reverse engineering, program structure improvement,
Program 1 Program 2 Program 3
program modularisation and data re-engineering
• Source code translation is the automatic conversion of
program in one language to another
File 1 File 2 File 3 File 4 File 5 File 6 • Reverse engineering is the process of deriving the system
design and specification from its source code
• Program structure improvement replaces unstructured
Program 4 Program 5 Program 6 Program 7
control constructs with while loops and simple conditionals

Becomes
• Program modularisation involves reorganisation to group
related items
• Data re-engineering may be necessary because of inconsistent
Program 3 Program 4 Program 5 Program 6
data management
Program 7
Program 2

Database describes
management Logical and
Program 1 physical
system
data models

146
Activity Activity

SOFTWARE ENGINEERING
Under what circumstances do you think that software should What problems might arise when converting data form one
scrapped and rewritten rather than re-engineered? type of database management system to another (e.g. hierarchi-
cal to relational or relational to object –oriented?

Activity
Write a set of guidelines that may be used to help find modules
in an unstructured program.
Activity
Explain why it is impossible to recover a system specification
be automatically analyzing system source code.

147
 Activity Activity
SOFTWARE ENGINEERING

Using examples, describe the problems with data degradation A company routinely places contractual conditions on freelance
which may have to be tackled during the process of data working on re-engineering their applications which prevents
cleanup. them from taking on contracts with similar companies. The
reason for this is that re-engineering inevitably reveals business
information. Is this a reasonable position for a company to take
given that they have no obligations to contractors after their
contract has finished?

Activity
The year 2000 problem where dates were represented as two
digits posed a major program maintenance problem for many
organizations. What were the implications of this problem for
data re-engineering?

148
 UNIT IV
ENVOLUTION
LESSON 39 AND 40:
CONFIGURATION MANAGEMENT CHAPTER 24

Managing The Products of System Change • Standards may be based on external CM standards (e.g.

SOFTWARE ENGINEERING
IEEE standard for CM)
Objectives
• Existing standards are based on a waterfall process model -
• To explain the importance of software configuration
new standards are needed for evolutionary development
management (CM)
• To describe key CM activities namely CM planning, change Concurrent Development And Testing
management, version management and system building • A time for delivery of system components is agreed
• To discuss the use of CASE tools to support configuration • A new version of a system is built from these components
management processes by compiling and linking them
Topics Covered • This new version is delivered for testing using pre-defined
tests
• Configuration management planning
• Change management
• Faults that are discovered during testing are documented and
returned to the system developers
• Version and release management
Daily System Building
• System building
• CASE tools for configuration management
• It is easier to find problems that stem from component
interactions early in the process
Configuration Management • This encourages thorough unit testing : Developers are
• New versions of software systems are created as they change under pressure not to ‘break the build’
For different machines/OS • A stringent change management process is required to keep
Offering different functionality track of problems that have been discovered and repaired
Tailored for particular user requirements Configuration Management Planning
• Configuration management is concerned with managing • All products of the software process may have to be
evolving software systems managed
System change is a team activity Specifications
CM aims to control the costs and effort involved in making Designs
changes to a system Programs
• Involves the development and application of procedures and Test data
standards to manage an evolving software product
User manuals
• May be seen as part of a more general quality management
• Thousands of separate documents are generated for a large
process
software system
• When released to CM, software systems are sometimes called
baselines, as they are a starting point for further development CM Planning

System Families
• Starts during the early phases of the project
• Must define the documents or document
PC Mainframe classes, which are to be managed (Formal
version version
VM S
documents)
version • Documents which might be required for future
Initial DEC Workstation
system version version system maintenance should be identified and specified as
Unix managed documents
version
Sun
version The CM Plan
• Defines the types of documents to be managed and a
document naming scheme
CM Standards
• Defines who takes responsibility for the CM procedures and
• CM should always be based on a set of standards, which are creation of baselines
applied within an organisation
• Defines policies for change control and version management
• Standards should define how items are identified; how • Defines the CM records which must be maintained
changes are controlled and how new versions are managed

149
 • Describes the tools, which should be used to assist the CM Change Management
SOFTWARE ENGINEERING

process and any limitations on their use • Software systems are subject to continual change requests
• Defines the process of tool use From users
• Defines the CM database used to record configuration From developers
information
From market forces
• May include information such as the CM of external
• Change management is concerned with keeping managing of
software, process auditing, etc.
these changes and ensuring that they are implemented in the
Configuration Item Identification most cost-effective way
• Large projects typically produce thousands of documents, The Change Management Process
which must be uniquely identified
• Some of these documents must be maintained for the Request change by completing a change request form
lifetime of the software Analyze change request
• Document naming scheme should be defined if change is valid then
Assess how change might be implemented
so that related documents have related names. Assess change cost
• A hierarchical scheme with multi-level names is Submit request to change control board
if change is accepted then
probably the most flexible approach
repeat
Configuration Hierarchy make changes to software
submit changed software for quality approval
until software quality is adequate
PCL-TOOLS create new system version
else
reject change request
COMPILE BIND EDIT MAKE-GEN else
reject change request
FORM STRUC TUR ES HELP

DIS PLAY QUERY

Change Request Form
• Definition of change request form is part of the CM
FORM-S PECS AS T-INTERFACE FORM-IO planning process
• Records change required, suggestor of change, reason why
OB JECTS CODE TESTS change was suggested and urgency of change (from requestor
of the change)
• Records change evaluation, impact analysis, change cost and
The Configuration Database recommendations (System maintenance staff)
• All CM information should be maintained in a configuration
database Change Request Form

• This should allow queries about configurations to be Project: Proteus/PCL-Tools Number: 23/94
Change requester: I. Sommerville Date: 1/12/98
answered Requested change: When a component is selected from the structure,
display the name of the file where it is stored.
Who has a particular system version?
Change analyser: G. Dean Analysis date: 10/12/98
What platform is required for a particular version? Components affected: Display-Icon.Select, Display-Icon.Display

What versions are affected by a change to component X? Associated components: FileTable

How many reported faults in version T? Change assessment: Relatively simple to implement as a file name table
is available. Requires the design and implementation of a display field. No
• The CM database should preferably be linked to the software changes to associated components are required.

being managed Change priority: Low

Change implementation:
Cm Database Implementation Estimated effort: 0.5 days
Date to CCB: 15/12/98 CCB decision date: 1/2/99
CCB decision: Accept change. Change to be implemented in Release 2.1.
• May be part of an integrated environment to support Change implementor: Date of change:
software development. The CM database and the managed Date submitted to QA: QA decision:
Date submitted to CM:
documents are all maintained on the same system Comments

• CASE tools may be integrated with this so that there is a

close relationship between the CASE tools and the CM tools
• More commonly, the CM database is maintained separately as Change Tracking Tools
this is cheaper and more flexible • A major problem in change management is tracking change
status

150
• Change tracking tools keep track the status of • Release : An instance of a system, which is distributed to

SOFTWARE ENGINEERING
each change request and automatically ensure users outside of the development team
that change requests are sent to the right
Version Identification
people at the right time.
• Procedures for version identification should define an
• Integrated with E-mail systems allowing
unambiguous way of identifying component versions
electronic change request distribution
• Three basic techniques for component identification
Change Control Board
Version numbering
• Changes should be reviewed by an external group who Attribute-based identification
decide whether or not they are cost-effective from a strategic
and organizational viewpoint rather than a technical Change-oriented identification
viewpoint Version Numbering
• Should be independent of project responsible • Simple naming scheme uses a linear derivation
for system. The group is sometimes called a change control e.g. V1, V1.1, V1.2, V2.1, V2.2 etc.
board • Actual derivation structure is a tree or a
• May include representatives from client and network rather than a sequence
contractor staff
• Names are not meaningful.
Derivation History • Hierarchical naming scheme may be better
• Record of changes applied to a document or Version Derivation Structure
code component
• Should record, in outline, the change made, the rationale for V1 .1 b V1 .1 .1

the change, who made the change and when it was

implemented
V1 .0 V1 .1 V1 .2 V2 .0 V2 .1 V2 .2
• May be included as a comment in code. If a standard
prologue style is used for the derivation history, tools can
process this automatically V1 .1 a

Component Header Information

Attribute-based Identification
// P ROTEUS p roject (ESP RIT 6087) • Attributes can be associated with a version with the
//
// P CL-TOOLS/EDIT/FORMS/DISP LAY/AST-INTERFACE
combination of attributes identifying that version
// • Examples of attributes are Date, Creator, Programming
// Obje ct: PC L-Tool-Desc Language, Customer, and Status etc.
// Author: G. Dea n
// Crea tion date : 10th November 1998 • More flexible than an explicit naming scheme for version
// retrieval; Can cause problems with uniqueness
// © Lancaste r Unive rsity 1998 • Needs an associated name for easy reference
//
// Modifica tion history Attribute-based Queries
// Version Modifier Date Cha nge Rea son
// 1.0 J. Jones 1/12/1998 Add heade r S ubmitted to CM
• An important advantage of attribute-based identification is
// 1.1 G. Dean 9/4/1999 New field Cha nge re q. R07/99 that it can support queries so that you can find ‘the most
recent version in Java’ etc.
Example
Version and Release Management AC3D (language =Java, platform = NT4, date = Jan 1999)
• Invent identification scheme for system versions
Change-oriented Identification
• Plan when new system version is to be produced
• Integrates versions and the changes made to create these
• Ensure that version management procedures and tools are versions
properly applied
• Used for systems rather than components
• Plan and distribute new system releases
• Each proposed change has a change set that describes
Versions/Variants/Releases changes made to implement that change
• Version : An instance of a system, which is functionally • Change sets are applied in sequence so that, in principle, a
distinct in some way from other system instances version of the system that incorporates an arbitrary set of
• Variant : An instance of a system, which is functionally changes may be created
identical but non-functionally distinct from other instances
of a system

151
 Release Management Release Creation
SOFTWARE ENGINEERING

• Releases must incorporate changes forced on • Release creation involves collecting all files and ocumentation
the system by errors discovered by users and required to create a system release
by hardware changes • Configuration descriptions have to be written for different
• They must also incorporate new system hardware and installation scripts have to be written
functionality • The specific release must be documented to record exactly
• Release planning is concerned with when to what files were used to create it. This allows it to be re-created
issue a system version as a release if necessary
System Releases System Building
• Not just a set of executable programs • The process of compiling and linking software components
• May also include into an executable system
Configuration files defining how the release is configured for a • Different systems are built from different combinations of
particular installation components
Data files needed for system operation • Invariably supported by automated tools that are driven by
‘build scripts’
An installation program or shell script to install the system on
target hardware System Building Problems
Electronic and paper documentation • Do the build instructions include all required
Packaging and associated publicity components?

• Systems are now normally released on CD-ROM or as When there are many hundreds of components making up a
downloadable installation files from the web system, it is easy to miss one out. This should normally be
detected by the linker
Release Problems
• Is the appropriate component version specified?
• Customer may not want a new release of the system A more significant problem. A system built with the wrong
They may be happy with their current system as the new version version may work initially but fail after delivery
may provide unwanted functionality
• Are all data files available?
• Release management must not assume that all previous The build should not rely on ‘standard’ data files. Standards
releases have been accepted. All files required for a release
vary from place to place
should be re-created when a new release is installed
• Are data file references within components correct?
Release Decision Making
Embedding absolute names in code almost always causes
• Preparing and distributing a system release is an expensive problems as naming conventions differ from place to place
process
• Is the system being built for the right platform?
• Factors such as the technical quality of the system,
Sometimes must build for a specific OS version or hardware
competition, marketing requirements and customer change
configuration
requests should all influence the decision of when to issue a
new system release • Is the right version of the compiler and other
software tools specified?
System Release Strategy
Different compiler versions may actually generate different code
and the compiled component will exhibit different behaviour
Factor
Technical quality of
Description
If serious system faults are reported which affect the way in which
System Building
the system many customers use the system, it may be necessary to issue a
fault repair release. However, minor system faults may be repaired Version
System management Compilers Linker
by issuing patches (often distributed over the Internet) that can be builder system
applied to the current release of the system.
Lehman’s fifth law This suggests that the increment of functionality which is included
(see Chapter 27) in each release is approximately constant. Therefore, if there has
been a system release with significant new functionality, then it
may have to be followed by a repair release. Source code Object code Executable
Build component
Competition A new system release may be necessary because a competing script components system
versions
product is available.
Marketing The marketing department of an organisation may have made a
requirements commitment for releases to be available at a particular date.
Customer change For customised systems, customers may have made and paid for a System Representation
proposals specific set of system change proposals and they expect a system
release as soon as these have been implemented. • Systems are normally represented for building by specifying
the file name to be processed by building tools.
Dependencies between these are described to the building
tools

152
• Mistakes can be made as users lose track of which objects are Distributed compilation

SOFTWARE ENGINEERING
stored in which files Derived object management
• A system modelling language addresses this problem by
Component Dependencies
using a logical rather than a physical system representation
CASE Tools for Configuration
Management comp

• CM processes are standardised and involve applying pre-

defined procedures
• Large amounts of data must be managed scan .o s yn .o s em . o cgen .o
• CASE tool support for CM is therefore essential
• Mature CASE tools to support configuration management
are available ranging from stand-alone tools to integrated s can .c s yn .c s em . c cgen .c
CM workbenches
Change Management Tools
• Change management is a procedural process so it can be d efs .h
modelled and integrated with a version management system
• Change management tools
Form editor to support processing the change request forms
Key Points
Workflow system to define who does what and to automate
information transfer • Configuration management is the management of system
change to software products
Change database that manages change proposals and is linked
to a VM system • A formal document-naming scheme should be
established and documents should be managed in a database
Version Management Tools
• The configuration database should record information about
• Version and release identification changes and change requests
Systems assign identifiers automatically when a new version is • A consistent scheme of version identification should be
submitted to the system established using version numbers, attributes or change sets
• Storage management. • System releases include executable code, data, configuration
System stores the differences between versions rather than all files and documentation
the version code • System building involves assembling components into a
• Change history recording system
Record reasons for version creation • CASE tools are available to support all CM activities
• Independent development • CASE tools may be stand-alone tools or may be integrated
Only one version at a time may be checked out for change. systems which integrate support for version management,
Parallel working on different versions system building and change management

Delta-based Versioning

Version Version Version Version

1.0 1.1 1 .2 1.3

D1 D2 D3

Creatio n d ate

System Building
• Building a large system is computationally expensive and
may take several hours
• Hundreds of files may be involved
• System building tools may provide
A dependency specification language and interpreter
Tool selection and instantiation support

153
 Activity Activity
SOFTWARE ENGINEERING

Explain why you should not use the title of a document to Using a data-flow diagram. Describe a change management
identify the document in a configuration management system. procedure, which might be used in a large organization
Suggest a standard for a document identification scheme that concerned with developing software foe external clients.
may be used for all projects in an organization. Changes may be suggested form either external or internal
sources.

Activity
Using the entity-relational or object-oriented approach design a
model of a configuration database which records information
about system components, versions, releases and changes.
Some requirements for the data model are as follows:
• It should be possible to retrieve all versions or a single Activity
identified version of a component. Describe the difficulties which can be encountered in system
• It should be possible to retrieve the latest version of a building. Suggest particular problems that might arise when a
component. system is built on a host computer for some target machine.
• It should be possible to find out which change requests have
been implemented by a particular version of a system.
• It should be possible to discover which versions of
components are included in a specified version of a system.
• It should be possible to retrieve a particular release of a
system according to either the release date or the customers
to whom the release was delivered.

154
Activity Activity

SOFTWARE ENGINEERING
A common problem with system building occurs when physical Describe two ways in which system building tools can optimize
file names are incorporated in system code and the file structure the process of building a version of a system form its compo-
implied in these names differs form that of the target machine. nents.
Write a set of programmer’s guidelines, which help avoid this
and other system building problems, which you can think of.

Activity
Describe five factors which must be taken into account by
engineers during the process of building a release of a large
software system.

155
“The lesson content has been compiled from various sources in public domain including but not limited to the
internet for the convenience of the users. The university has no proprietary right on the same.”

Rai Technology University Campus

Dhodballapur Nelmangala Road, SH -74, Off Highway 207, Dhodballapur Taluk, Bangalore - 561204
E-mail: [email protected] | Web: www.raitechuniversity.in