UNIT-I

Overview: Introduction:
Professional Software Development, Software Engineering Ethics,
Case studies.

Software Processes: Models, Process activities, Coping with

Change, Process improvement.

Requirements Engineering and System Modelling:

Software Requirements: Functional and Non-functional requirements,
Requirements Elicitation, Specification, Validation and Change
Topics covered

Software Processes
 Software process models
 Process activities
 Coping with change
 Process improvement

Chapter 2 Software Processes 2

The software process

Chapter 2 Software Processes 3

Software process descriptions

 When we describe and discuss processes, we usually

talk about the activities in these processes such as
specifying a data model, designing a user interface, etc.
and the ordering of these activities.
 Process descriptions may also include:
 Products, which are the outcomes of a process activity;
 Roles, which reflect the responsibilities of the people involved in
the process;
 Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a
product produced.

Chapter 2 Software Processes 4

Plan-driven and agile processes

 Plan-driven processes are processes where all of the

process activities are planned in advance and progress
is measured against this plan.
 In agile processes, planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
 In practice, most practical processes include elements of
both plan-driven and agile approaches.
 There are no right or wrong software processes.

Chapter 2 Software Processes 5

Software process models

Chapter 2 Software Processes 6

The waterfall model

Chapter 2 Software Processes 7

Waterfall model phases

Chapter 2 Software Processes 8

Waterfall model problems

Chapter 2 Software Processes 9

Incremental development

Chapter 2 Software Processes 10

Incremental development benefits

Chapter 2 Software Processes 11

Incremental development problems

 The process is not visible.

 Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.
 System structure tends to degrade as new increments
are added.
 Unless time and money is spent on refactoring to improve the
software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly
difficult and costly.

Chapter 2 Software Processes 12

Reuse-oriented software engineering

Chapter 2 Software Processes 13

Reuse-oriented software engineering

Chapter 2 Software Processes 14

Types of software component

 Web services that are developed according to service

standards and which are available for remote invocation.
 Collections of objects that are developed as a package
to be integrated with a component framework such
as .NET or J2EE.
 Stand-alone software systems (COTS) that are
configured for use in a particular environment.

Chapter 2 Software Processes 15

The requirements engineering process

Chapter 2 Software Processes 16

Software design and implementation

Chapter 2 Software Processes 17

A general model of the design process

Chapter 2 Software Processes 18

Design activities

 Architectural design, where you identify the overall

structure of the system, the principal components
(sometimes called sub-systems or modules), their
relationships and how they are distributed.
 Interface design, where you define the interfaces
between system components.
 Component design, where you take each system
component and design how it will operate.
 Database design, where you design the system data
structures and how these are to be represented in a
database.
Chapter 2 Software Processes 19
Software validation

Chapter 2 Software Processes 20

Stages of testing

Chapter 2 Software Processes 21

Testing stages

Chapter 2 Software Processes 22

Testing phases in a plan-driven software
process

Chapter 2 Software Processes 23

Coping with change

 Change is inevitable in all large software projects.

 Business changes lead to new and changed system
requirements
 New technologies open up new possibilities for improving
implementations
 Changing platforms require application changes
 Change leads to rework so the costs of change include
both rework (e.g. re-analysing requirements) as well as
the costs of implementing new functionality

Chapter 2 Software Processes 24

Reducing the costs of rework

 Change avoidance, where the software process includes

activities that can anticipate possible changes before
significant rework is required.
 For example, a prototype system may be developed to show
some key features of the system to customers.
 Change tolerance, where the process is designed so that
changes can be accommodated at relatively low cost.
 This normally involves some form of incremental development.
Proposed changes may be implemented in increments that have
not yet been developed. If this is impossible, then only a single
increment (a small part of the system) may have be altered to
incorporate the change.

Chapter 2 Software Processes 25

Software prototyping

Chapter 2 Software Processes 26

Benefits of prototyping

Chapter 2 Software Processes 27

The process of prototype development

Chapter 2 Software Processes 28

Prototype development

 May be based on rapid prototyping languages or tools

 May involve leaving out functionality
 Prototype should focus on areas of the product that are not well-
understood;
 Error checking and recovery may not be included in the
prototype;
 Focus on functional rather than non-functional requirements
such as reliability and security

Chapter 2 Software Processes 29

Throw-away prototypes

Chapter 2 Software Processes 30

Incremental delivery

Chapter 2 Software Processes 31

Incremental development and delivery

 Incremental development
 Develop the system in increments and evaluate each increment
before proceeding to the development of the next increment;
 Normal approach used in agile methods;
 Evaluation done by user/customer proxy.
 Incremental delivery
 Deploy an increment for use by end-users;
 More realistic evaluation about practical use of software;
 Difficult to implement for replacement systems as increments
have less functionality than the system being replaced.

Chapter 2 Software Processes 32

Incremental delivery

Chapter 2 Software Processes 33

Incremental delivery advantages

Chapter 2 Software Processes 34

Incremental delivery problems

 Most systems require a set of basic facilities that are

used by different parts of the system.
 As requirements are not defined in detail until an increment is to
be implemented, it can be hard to identify common facilities that
are needed by all increments.
 The essence of iterative processes is that the
specification is developed in conjunction with the
software.
 However, this conflicts with the procurement model of many
organizations, where the complete system specification is part of
the system development contract.

Chapter 2 Software Processes 35

Process Improvement
Process Improvement

 Understanding, Modelling and Improving the Software

Process
Objectives
Topics covered
Process improvement
Process attributes
Process improvement stages

 Process analysis
 Model and analyse (quantitatively if possible) existing
processes
 Improvement identification
 Identify quality, cost or schedule bottlenecks
 Process change introduction
 Modify the process to remove identified bottlenecks
 Process change training
 Train staff involved in new process proposals
 Change tuning
 Evolve and improve process improvements
The process improvement process
Process and product quality
Principal product quality factors
Quality factors
Process analysis and modelling
Process analysis and modelling
Process analysis techniques
Elements of a
process model
The module testing activity
Activities in module testing

©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31. Slide ##
Process exceptions
Process measurement
Classes of process measurement
Goal-Question-Metric Paradigm
The Software Engineering Institute
The SEI process maturity model
Maturity model levels
Key process areas
SEI model problems
The CMM and ISO 9000
Capability assessment
The capability assessment process
Process classification
Process applicability
Process choice
Process tool support
 Key points

 Process improvement involves process analysis,

standardisation, measurement and change
 Process models include descriptions of tasks,
activities, roles, exceptions, communications,
deliverables and other processes
 Measurement should be used to answer specific
questions about the software process used
 The three types of process metrics which can be
collected are time metrics, resource utilisation metrics
and event metrics
 Key points

 The Software Engineering Institute (SEI) model

classifies software processes as initial, repeatable,
defined, managed and optimising. It identifies key
processes which should be used at each of these
levels
 The SEI model is appropriate for large systems
developed by large teams of engineers. It cannot be
applied without modification in other situations
 Processes can be classified as informal, managed,
methodical and improving. This classification can be
used to identify process tool support