software process

Software Processes

Loganathan RLoganathan R

1Prof. Loganathan R., CSE, HKBKCE

Objectives

• Understand the concept of software processmodels

• Understand three generic process models andwhen they may be used

• Understand the activities involved in• Understand the activities involved inrequirements engineering, softwaredevelopment, testing and evolution

• Understand the Rational Unified Process model• Introduce the CASE technology to support

software process activities


The Software Process

• Common fundamental activities to all Software processes are:

– Specification;

– Design;

– Validation;

– Evolution.– Evolution.

• A software process model is an abstract representation of aprocess. It presents a description of a process from someparticular perspective.


Generic software process models

• The waterfall model– Separate and distinct phases of specification and development.

• Evolutionary(Iterative) development– Specification, development and validation are interleaved.

• Component-Based Software Engineering• Component-Based Software Engineering– The system is assembled from existing components.

• There are many variants of these models e.g. formaldevelopment where a waterfall-like process is used but thespecification is a formal specification that is refined throughseveral stages to an implementable design.


Waterfall Model

System andSoftware Design

RequirementsDefinition

Implementation


Implementationand Unit Testing

Integration andSystem Testing

Operation andMaintenance

Waterfall Model phases

• Requirements analysis and definition• Services, constraints & goals are established & Defined

• System and software design• Establishes overall System architecture ,identifies & describes

the software system abstractions & their relationships• Implementation and unit testing

Design is realised as program units. Unit testing involves• Implementation and unit testing

• Design is realised as program units. Unit testing involvesverifying each unit meets its specification

• Integration and system testing• Program unit are integrated and tested as a system to ensure it

meets the requirement specification.• Operation and maintenance

• System is installed & put in use. Maintenance involvescorrecting errors, improving implementation & enhancing withnew requirements as discovered


Waterfall model problems• The main drawback of the waterfall model is the difficulty of

accommodating change after the process is underway. Onephase has to be complete before moving onto the next phase.

• Inflexible partitioning of the project into distinct stages makesit difficult to respond to changing customer requirements.

• Therefore, this model is only appropriate when the• Therefore, this model is only appropriate when therequirements are well-understood and changes will be fairlylimited during the design process.

• Few business systems have stable requirements.

• The waterfall model is mostly used for large systemsengineering projects where a system is developed at severalsites.


Evolutionary developmentConcurrentactivities

Specification InitialVersion


ValidationFinal

Version

Development IntermediateVersions

OutlineDescription

Evolutionary development

• Develop an initial implementation and expos touser comment and then refine it through manyversions.

• Types:• Exploratory development• Exploratory development

– Objective is to work with customers and to evolve a finalsystem from an initial outline specification. Should start withwell-understood requirements and add new features asproposed by the customer.

• Throw-away prototyping– Objective is to understand the system requirements. Should

start with poorly understood requirements to clarify what isreally needed.


• Problems– Lack of process visibility;

– Systems are often poorly structured;

– Special skills (e.g. in languages for rapid

Evolutionary development

– Special skills (e.g. in languages for rapidprototyping) may be required.

• Applicability– For small or medium-size interactive systems;

– For parts of large systems (e.g. the user interface);

– For short-lifetime systems.


Component-based software engineering

RequirementsSpecifications

ComponentAnalysis

System Designwith Reuse

RequirementsModifications


Developmentand Integration

SystemValidation

Component-based software engineering

• Based on systematic reuse where systems are integratedfrom existing components or COTS (Commercial-off-the-shelf) systems.

• Process stages– Component analysis :- Search for components for given

specification– Requirements modification :- Analyse the requirements using– Requirements modification :- Analyse the requirements using

the discovered component information and modify to reflectthe available components

– System design with reuse :- Framework of the system isdesigned or existing framework is reused

– Development and integration :- non available components aredeveloped and integrated with COTS system to create therequired system

• This approach is becoming increasingly used as componentstandards have emerged.


Process Iteration

• System requirements ALWAYS evolve in thecourse of a project so, process iteration whereearlier stages are reworked is always part ofthe process for large systems.

• Iteration can be applied to any of the genericprocess models.

• Two (related) approaches– Incremental delivery;

– Spiral development.


Incremental delivery

Design SystemArchitecture

Define OutlineRequirements

Assign Requirementsto Increments


ValidateIncrement

Develop systemIncrement

IntegrateIncrement

ValidateSystem

System Incomplete

FinalSystem


• Rather than deliver the system as a single delivery, thedevelopment (Specification, design & implementation)and delivery is broken down into increments with eachincrement delivering part of the required functionality.

• User requirements are prioritised and the highest• User requirements are prioritised and the highestpriority requirements are included in early increments.

• Once the development of an increment is started, therequirements are frozen though requirements for laterincrements can continue to evolve.


• Advantages

– Customer value can be delivered with eachincrement so system functionality is availableearlier.


earlier.

– Early increments act as a prototype to help elicitrequirements for later increments.

– Lower risk of overall project failure.

– The highest priority system services tend toreceive the most testing.


Extreme programming

• Variant of incremental delivery.

• Based on the development based on thedevelopment and delivery of very smallincrements of functionality.increments of functionality.

• Relies on constant code improvement, userinvolvement in the development team andpair wise programming.


Spiral development

• Process is represented as a spiral rather thanas a sequence of activities with backtracking.

• Each loop in the spiral represents a phase inthe process.the process.

• No fixed phases such as specification ordesign - loops in the spiral are chosendepending on what is required.

• Risks are explicitly assessed and resolvedthroughout the process.


Spiral model of the software process

Risk

analysis

Risk

analysis

Risk

analysis

Prototype 2

Prototype 3Oper a-

tional

protoype

Evaluate alterna tives,

identify , resolve risks

Deter mine objecti ves,

alterna tives and

constr aints


Risk

analysis Proto-

type 1

Prototype 2 protoype

Concept of

Oper ation

Simulations , models , benchmarks

S/W

requir ements

Requir ement

validation

Design

V&V

Product

design Detailed

design

Code

Unit test

Integ ration

testAcceptance

testService Develop , verify

next-level pr oduct

Plan ne xt phase

Integ ration

and test plan

Development

plan

Requir ements plan

Life-cycle plan

REVIEW

Spiral model Sectors

• Objective setting

– Define the Specific objectives for that phase. Identify theconstraints on the process/product and project risk. Plan forconstraints & find alternate for risk or resolve.

• Risk assessment and reduction– Risks are analysed & assessed and take steps to reduce the risks.– Risks are analysed & assessed and take steps to reduce the risks.

• Development and validation– A development model for the system is chosen which can be any

of the generic models. Example for UI risk use evolutionaryprototyping, for safety risk use formal transformation, for sub-system risk Waterfall model

• Planning– The project is reviewed and the next phase of the spiral is planned.


Process activities

• 1. Software specification

• 2. Software design and implementation

• 3. Software validation

• 4. Software evolution• 4. Software evolution


1. Software specification• Software Specification or requirements engineering is the process of

understanding and defining what services are required and identifyingthe constraints on the system’s operation and development.

• Requirements engineering process

– Feasibility study:- Estimate whether the current h/w & s/w technology will

satisfy user needs & cost-effective. Feasibility study should be cheap &quick.

– Requirements elicitation and analysis :- Derive the requirements by

observing existing system, discussing with users, task analysis & so on. Producesystem models & prototypes

– Requirements specification :- Translate the previous activity information

into requirements document. Types of requirements:

• User requirements :- for customer & end user

• System requirements : - detailed description of the required functionality

– Requirements validation :- Checks the requirements for realism consistency

& completeness.22Prof. Loganathan R., CSE, HKBKCE

The requirements engineering process

FeasibilityStudy

RequirementsElicitation and

Analysis

RequirementsSpecification

RequirementsFeasibility


RequirementsValidation

FeasibilityReport

SystemModels

User and SystemRequirements

RequirementsDocument

2. Software Design and Implementation

• The process of converting the systemspecification into an executable system.

• Software design– is a description of software structure, data, interfaces

and algorithms used in the system that realises theand algorithms used in the system that realises thespecification;

• Implementation– Translate design structure into an executable

program;

• The activities of design and implementation areclosely related and may be inter-leaved.


The software design process

RequirementSpecification

Design activities


ArchitecturalDesign

AbstractSpecificatio

n

InterfaceDesign

ComponentDesign

DataStructureDesign

AlgorithmDesign

SystemArchitecture

SoftwareSpecification

InterfaceSpecification

ComponentSpecification

DataStructure

Specification

AlgorithmSpecification

Design products

Software Design process activities

• Architectural designSubsystem making up the system & their relationships are identified & documented

• Abstract specificationAbstract specification of subsystem services & its operating constraints are produced

• Interface design• Interface designSubsystem interfaces with other subsystem is designed unambiguously & documented

• Component designComponent services are allocated & its interfaces also designed

• Data structure designThe data structures used in the implementation is designed & specified

• Algorithm designAlgorithm to provide services are designed & specified


Design methods• In Agile method, design process output is represented

in the code of the program• The Structured methods produces graphical models

and code generated automatically from that. Includesdesign process model, design notations, report formats& design guidelines.

• Structured methods supports the following models:• Structured methods supports the following models:– Object model :Shows object classes & their dependencies– Sequence model :Shows how objects interact when system is

executing– State transition model :Shows system states & triggers for

transition from one state to another– Structural model :System Components & their aggregations

are documented– Data-flow model :System is modelled using transformations

that takes place as it is processed


Programming and Debugging

• Translating a design into a program andremoving errors from that program.

• Programming is a personal activity - there isno generic programming process.no generic programming process.

• Programmers carry out some program testingto discover faults in the program and removethese faults in the debugging process.


The Debugging Process

Locate Design Error Repair Retest


LocateError

Design ErrorRepair

RepairError

RetestProgram

3. Software validation

• Verification and validation (V & V) is intendedto show that a system conforms to itsspecification and meets the requirements ofthe system customer.

• Involves checking and review processes and• Involves checking and review processes andsystem testing.

• System testing involves executing the systemwith test cases that are derived from thespecification of the real data(customer data)to be processed by the system.


The Testing Process

Component System Acceptance


ComponentTesting

SystemTesting

AcceptanceTesting

Testing process stages• Component or unit testing

– Individual components are tested independentlyfor correct operation;

– Components may be functions or objects orcoherent groupings of these entities.

• System testing• System testing– Testing of the system as a whole to validate

functional & non-functional requirements. Testingof emergent properties is particularly important.

• Acceptance testing– Testing with customer data to check that the

system meets the customer’s needs &performance.


Testing phases in a Software processRequirementsSpecification

SystemSpecification

SystemDesign

DetailedDesign

Module / UnitCode and Test

Sub-systemIntegrationTest Plan

SystemIntegrationTest Plan

AcceptanceTest Plan


• Alpha testing : Acceptance testing

• Beta testing : For marketed products, involves deliveringsystem to potential customers who agree to use

ServiceAcceptance

TestSystem

Integration TestSub-system

Integration Test

4. Software evolution

• Software is inherently flexible and can change.

• As requirements change through changingbusiness circumstances, the software thatsupports the business must also evolve andsupports the business must also evolve andchange.

• Although there has been a demarcationbetween development and evolution(maintenance) this is increasingly irrelevant asfewer and fewer systems are completely new.


System evolution

Assess existingDefine system Propose system Modify


Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems

The Rational Unified Process

• A modern process model derived from the work onthe UML and associated Unified SoftwareDevelopment process.

• It is a Hybrid process model : Combines the elementsof generic process models, supports iteration &of generic process models, supports iteration &illustrates good practices in specification & design

• Normally described from 3 perspectives

– A dynamic perspective that shows phases over time;

– A static perspective that shows process activities;

– A practice perspective that suggests good practice.


RUP phase model

Phase iteration


Inception Elaboration Construction Transition

RUP phases

• Inception– Establish the business case for the system.

• Elaboration– Develop an understanding of the problem domain– Develop an understanding of the problem domain

and the system architecture.

• Construction– System design, programming and testing.

• Transition– Deploy the system in its operating environment.


RUP good practice

• Develop software iteratively

• Manage requirements

• Use component-based architectures

• Visually model software• Visually model software

• Verify software quality

• Control changes to software


Static workflowsWorkflow Description

Business modelling The business processes are modelled using business use cases.

RequirementsActors who interact with the system are identified and use cases aredeveloped to model the system requirements.

Analysis and designA design model is created and documented using architectural models,component models, object models and sequence models.

ImplementationThe components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from design


Implementation implementation sub-systems. Automatic code generation from designmodels helps accelerate this process.

TestTesting is an iterative process that is carried out in conjunction withimplementation. System testing follows the completion of theimplementation.

DeploymentA product release is created, distributed to users and installed in theirworkplace.

Configuration andChange management

This supporting workflow managed changes to the system

Project management This supporting workflow manages the system development

EnvironmentThis workflow is concerned with making appropriate software toolsavailable to the software development team.

Computer-aided software engineering

• Computer-aided software engineering (CASE) is software tosupport software development and evolution processes.

• Activity automation

– Graphical editors for system model development;

– Data dictionary to manage design entities;– Data dictionary to manage design entities;

– Graphical UI builder for user interface construction;

– Debuggers to support program fault finding;

– Automated translators to generate new versions of a program.


Case technology

• Case technology has led to significantimprovements in the software process. However,these are not the order of magnitudeimprovements that were once predictedimprovements that were once predicted

– Software engineering requires creative thought - thisis not readily automated;

– Software engineering is a team activity and, for largeprojects, much time is spent in team interactions.CASE technology does not really support these.


CASE classification

• Classification helps us understand the different types of CASEtools and their support for process activities.

• Functional perspective

– Tools are classified according to their specific function.

• Process perspective• Process perspective

– Tools are classified according to process activities that aresupported.

• Integration perspective

– Tools are classified according to their organisation into integratedunits.


Functional tool classificationTool type Examples

Planning tools PERT tools, estimation tools, spreadsheets

Editing tools Text editors, diagram editors, word processors

Change management tools Requirements traceability tools, change control systems

Configuration management tools Version management systems, system building tools

Prototyping tools Very high-level languages, user interface generators


Prototyping tools Very high-level languages, user interface generators

Method-support tools Design editors, data dictionaries, code generators

Language-processing tools Compilers, interpreters

Program analysis toolsCross reference generators, static analysers, dynamicanalysers

Testing tools Test data generators, file comparators

Debugging tools Interactive debugging systems

Documentation tools Page layout programs, image editors

Re-engineering tools Cross-reference systems, program re-structuring systems

Activity-based tool classification

Re-engineering tools

Testing tools

Debugging tools

Program analysis tools

Language-processing tools


Specification Design Implementation Verification &Validation

Method support tools

Prototyping tools

Configuration managementtools

Change management tools

Documentation tools

Editing tools

Planning tools

CASE integration

• Tools– Support individual process tasks such as design

consistency checking, text editing, etc.

• Workbenches– Support a process phase such as specification or– Support a process phase such as specification or

design, Normally include a number of integratedtools.

• Environments– Support all or a substantial part of an entire

software process. Normally include severalintegrated workbenches.


Tools, workbenches, environments

EnvironmentsWorkbenchesTools

CaseTechnology


Single-methodWorkbenches

General-purposeWorkbenches

Multi-methodWorkbenches

Language-specificWorkbenches

Programming TestingAnalysis and

Design

Integrated

EnvironmentsProcess-centred

EnvironmentsFile ComparatorsCompilersEditors

software process

Technology

software process model

design process

maintenance system

software system abstractions

cots system

required system

generic software process

defined system