Software Engineering: A Practitioner s Approach, 6/e

BN Shankar Gowda 1

Software Engineering: A Practitioner’sApproach, 6/e

Chapter 3Prescriptive Process Models

(Software Development Lifecycle Models)

BN Shankar Gowda 2

Chapter Overview

Water Fall Model

Incremental process models Incremental model

RAD model

Evolutionary Models Prototyping

Spiral model

Concurrent development model

Specialized Process Models Component based development

The formal methods model

Aspect Oriented software development

The United Process

BN Shankar Gowda 3

Prescriptive Models Prescriptive process models advocate an orderly

approach to software engineeringThat leads to a few questions … If prescriptive process models strive for structure and

order, are they inappropriate for a software world thatthrives on change?

Yet, if we reject traditional process models (and theorder they imply) and replace them with somethingless structured, do we make it impossible to achievecoordination and coherence in software work?

BN Shankar Gowda 4

Software Development Lifecycle Models

Software Development Lifecycle Models

A lifecycle model, also called as process model, is an abstractdescription of the software development and modification process.

It maps out the main stages in which the above process is carriedout.

Software Engineering provides certain process models for carryingout the software development activity.

There are various and numerous methods to guide the life cycle of asoftware project. We can nonetheless define a few canonical modelsfrom which the wide variety of methods is local adaptations.

We will attempt to compare these various canonical models anddefine how we can adapt them to particular project situations.

BN Shankar Gowda 5

Risks of not following the process:

Success or failure of a project is completely dependent on theabilities of the development team/becomes person dependen.

Repeatability of success is at stake.

By not adopting a process the quality standards betweenprojects vary greatly leading to gross underestimations.

There is no control over the processes/ projects leading to..

Inability to predict important project parameters likeestimates of effort, schedule and budget.

Continuous improvement cannot be achieved.

BN Shankar Gowda 6

Activities in the Development ProcessLifecycle

Conceptualization & Requirements Planning (Estimating ,Scheduling, Tracking) Modeling / Design of Systems (Analysis & Specification,

Architectural & Infrastructure Design, Detailed Design, etc) Construction / Module Development

Coding Testing

Unit Testing Integration Testing System Testing User Acceptance Testing

Deployment Installation User and Technical Training Maintenance

BN Shankar Gowda 7

The Waterfall ModelCommunicat ion

PlanningModeling

Construct ionDeployment

analysisdesign code

test

project init iat ionrequirement gat hering estimating

schedulingtracking

deliverysupportf eedback

BN Shankar Gowda 8

The Waterfall Model Called as the Classic Lifecycle Model developed by Royce in 1970.

Follows a documentation driven paradigm.

Is a time-ordered sequence of activities called as lifecycle stages.

Requirements of customer are well understood

Work flows from Communication activity to deployment in LinearFashion/ a systematic and sequential approach to software

Generally adapted when well-defined requirements which arereasonably stable or when enhancements to the existing system mustbe made.

Each framework activity starts only after the previous activity hasfinished.

Iteration is not possible

BN Shankar Gowda 9

Lifecycle Stages defined in this model are: System Engineering

Software Requirements Analysis

Planning

Modeling & Design

Construction Coding (Build)

Testing

Deployment Maintenance

The Waterfall Model

BN Shankar Gowda 10

System Engineering: The software to be developed must alwaysfunction as part of a larger system. Hence it is necessary to start outby establishing requirements for the larger system. A subset of theseis then assigned to the software. This stage ensures that the softwarewill interface properly with people, hardware and other software inthe system.

Software Requirements Analysis: The requirements gatheringactivity now focuses specifically on the software. Here the softwareengineer, playing the role of analyst, understands the informationdomain, as well as the functional, performance and interfacingrequirements.

The output of this stage is the structured requirements.

Design: After the structured requirements are documented, theactual structure of the programs that will make up the software iscreated. The structure may be thought of as being determined byfour distinct attributes: software architecture, data structure,procedural detail and interface characterization.

BN Shankar Gowda 11

The design process thus translates the structured requirementsinto an actual representation of the software.

The output of this stage is the design documents, including theprogram specifications.

Coding (Build): The program specifications are translated into amachine-readable form by the process of coding. The output of thisstage is the actual programs that will make up the software.

Testing: The programs created are tested for conformance tospecifications. The internal logic, as well as functional andperformance aspects are tested.

Maintenance: After software system is installed and running thereare many reasons that demand a change to this system. Some of themost common reasons being, in the long run changing businessneeds, changing technological advances or needs, etc. Theimmediate being the errors made during development or bugs.Maintenance, therefore, means making changes to the existingsystem. Maintenance essentially consists of reapplying each of theabove stages to existing software rather than new software.

BN Shankar Gowda 12

The Waterfall Model contd. …

Advantages Simplicity and

The logical way of structuring the different activities in a software project.

The Waterfall model is well suited to projects that has low risk inthe areas of user interface and performance requirements, but highrisk in budget, schedule predictability and control.

Disadvantages It assumes that the requirements are completely ready before the

design, which is not the case in most of the development scenarios

Does not admit iteration between stages.

A working version of the software is not available until late in thedevelopment process and the customer is completely cut-off fromthe development until the acceptance testing stage.

BN Shankar Gowda 13

Disadvantages The major drawback of the waterfall model is that it assumes that the

requirements completely evolved, elicited and specified in advance during theRequirements Analysis stage. Unfortunately, requirements keep on evolving andchanging throughout the process and beyond, therefore requiring for considerableand continuous feedback and iterative consultation.

Some drawbacks of waterfall model can be listed ass: It does not admit iteration between stages that are removed from each other;

For Eg: Errors made in design may not be found until the testing stage.On the other hand, allowing cycling between any two stages causes loss of control in the

model. Any step can then be revisited at any point in time, and anyone in the team maybe working on any stage at a given time.

Everybody waits with bated breath until the project is complete. The customer often has difficulty expressing requirements in such a cogent form as to

be directly implemented in software. This model has difficulty accommodating thisnatural uncertainty that exists at the beginning of the cycle. This uncertainty tends toget carried down to later stages and may create need for much rework.

A working version of the software is not available until late in the developmentprocess, and if major errors are discovered at this stage, the results can be disastrous.

Thus it can be concluded that the Water-Fall model is well suited to projects thathas low risk in the areas of user interface and performance requirements, but highrisk in budget, schedule predictability and control.

Iterative Process System requirements ALWAYS evolve in the

course 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.

BN Shankar Gowda 14

BN Shankar Gowda 15

Iterative Process Models There may be situations where Software requirements are not

well-defined, but the overall scope of the development follows apurely linear process.

Types of Incremental process models

Incremental model

RAD model

Spiral model

BN Shankar Gowda 16

Incremental Model

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n td e l i v e r yf e e d b a c k

analysis

design code

t est

increment # 1

increment # 2

delivery of1st increment

delivery of2nd increment

delivery ofnt h increment

increment #n

project calendar time


M o d e l i n gC o n s t r u c t i o n


analysis

design code

t est


M o d e l i n gC o n s t r u c t i o n


analysis

designcodet est

The Incremental Model Rather than deliver the system as a single

delivery, the development and delivery isbroken down into increments with eachincrement delivering part of the requiredfunctionality.

User requirements are prioritised and thehighest priority requirements are included inearly increments.

Once the development of an increment isstarted, the requirements are frozen thoughrequirements for later increments cancontinue to evolve.

BN Shankar Gowda 17

BN Shankar Gowda 18

Initial software requirements are reasonably well-defined.

Combines elements of Waterfall model applied in an iterative fashion. i,e, Applieslinear sequence in a ”staggered fashion”.

It is Iterative in nature

Focuses on the delivery of operational product with each increment.

Early increments are “stripped down” versions of the final product.

Eg: Word doc/ ppt

The first increment is always the “CORE PRODUCT” i,e, basic requirements

The core product is evaluated / used by customer .

Based on the feedback , a plan is developed for the next increment.

Plan addresses the modification to the core product & delivery of additionalfeatures and functionality.

The process is repeated following the delivery of each increment, until thecomplete product is released.

The Incremental Model by Mills,1980

BN Shankar Gowda 19

The Incremental Model( cont’d…)

When to use Incremental Model? Initial software requirements are reasonably well-defined.

When there is a compelling need to provide a limited set of softwarefunctionality to users quickly and then refine and expand on thatfunctionality in later releases.

When staffing is unavailable for a complete implementation bybusiness deadline. Early increments can be implemented by fewpeople & If core product is well received, additional staff can beadded to implement the next increment.

BN Shankar Gowda 20

Incremental Development Process

Develop systemincrement

Define Corerequirements

AssignRequirements to

increments

Validatesystem

Integrateincrement

Validateincrement

Design systemArchitecture

System Incomplete

Final System

BN Shankar Gowda 21

Advantages The customer do not have to wait until the

entire system is delivered. Customers can use the early increments as a

form of prototype and gain experience whichinforms the requirements for later systemdevelopment.

Lower risk of overall project failure. The highest priority services are delivered first

and the later increments are integrated withthem.

BN Shankar Gowda 22

The RAD Model

Communicat ion

Planning

Modelingbusiness modelingdat a modelingprocess modeling

Construct ioncomponent reuseaut omat ic code

generat iont est ing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modelingdat a modelingprocess modeling

Construct ioncomponent reuseaut omat ic code

generat iont est ing

Mode lingbusiness modelingdata modelingprocess modeling

Const ruct ioncomponent reuseautomatic code

generationtesting

Team # 2

Team # n

int egrat iondeliveryfeedback

BN Shankar Gowda 23

Rapid Application Development Model

Focuses on a SHORT DEVELOPMENT CYCLE. Requirements are well-understood and project scope is constrained. High-speed adaptation of the waterfall model , in which Rapid

development is achieved by using a component based constructionapproach where each major function is completed in 60 to 90 days.

Maps into generic framework activities. Communication : works to clearly understand the business problem. Planning: imp. As multiple teams work in parallel on different

system functions. Modeling: encompasses Business modeling, data modeling and

process modeling and establishes design representations. Construction: Deployment:

BN Shankar Gowda 24

Drawbacks: For large, but scalable projects, RAD requires sufficient HR to

create the right number of RAD teams that will be working inparallel.

If developers and customers are not committed to Rapid-Fire-Activities necessary to complete the system, RAD projects fail.

If the system cannot be properly modularized, building thecomponents necessary for RAD will be problematic.

If high performance is an issue, and performance is to be achievedthrough tuning the interfaces to the subsystem components, thenRAD approach may not work.

RAD may not be appropriate when technical risks are high.

Rapid Application Development Model (Cont’d)Incremental Model: As Increments or advancements are deliverediteratively in every 60 to 90 days

BN Shankar Gowda 25

The Spiral Model

communication

planning

modeling

constructiondeployment

delivery feedback

start

analysisdesign

codetest

estimationschedulingrisk analysis

Spiral Mpodel

26

Riskanal ysis

Riskanal ysis

Riskanal ysis

Riskanal ysis Proto-

type 1

Prototype 2

Prototype 3Oper a-tionalpr oto ype

Concept ofOper a tion

Simula tions , models , benchmar ks

S/Wrequir ements

Requir ementvalida tion

DesignV&V

Productdesign Detailed

design

Code

Unit test

Integ ra tiontestAcceptance

testService Develop , verifyne xt-le vel pr oduct

Evalua te alterna tives,identify , resolv e risks

Deter mine objecti ves,alterna tives and

constr aints

Plan ne xt phase

Integ ra tionand test plan

Developmentplan

Requir ements planLife-cycle plan

REVIEW

BN Shankar Gowda

BN Shankar Gowda 27

Spiral Model

One of the most generic of all the models presented byBoehm in 1985.

Most life cycle models can be derived as special cases ofthe spiral model.

It is an evolutionary model that couples with the iterativenature of prototyping, with controlled and systematicaspects of Waterfall model.

The spiral uses a risk management approach to softwaredevelopment.

It has two main distinguishing features: Cyclic approach for incrementally growing a system’s degree of

definition & implementation while decreasing the degree of risk. A set of anchor point milestones for ensuring feasible solution.

BN Shankar Gowda 28

The spiral model emphasizes on the need to go back andre look at earlier stages, i.e. requirements and design, asmany number of times as required till the projects stakeholders are completely satisfied with all the aspects of thesystem.

The spiral model is therefore iterative and can beconsidered as a series of short waterfall cycles, each cycleending by producing an early prototype representing a partof the entire project.

The advantage of this approach is that it helps indemonstrating a proof of concept early in the project lifecycle, and therefore more accurately reflects the disorderlyor even chaotic evolution of technology

Spiral Model

BN Shankar Gowda 29

The radial dimension represents evolution towards a completesystem.

In each iteration analyze the results of the previous iteration,determine the risk and build a prototype. With each iterationoutward, progressively more complete versions of the software arebuilt.

During the first circuit, the objectives, alternatives and constraintsare defined. Risks are identified and analyzed. If risk analysisindicates substantial uncertainty in requirements, prototyping maybe done.

The Engineering may follow the life cycle approach or a prototypingapproach. The customer evaluates the work and makes suggestionsfor modifications. Based on these, the next stage of planning andrisk analysis is done. The system thus evolves toward a completeversion.

The Spiral Model contd. …

BN Shankar Gowda 30

Advantages Defers elaboration of low risk software elements

Incorporates prototyping as a risk reduction strategy

Gives an early focus to reusable software

Accommodates life-cycle evolution, growth, and requirementchanges

Incorporates software quality objectives into the product

Focus on early error detection and design flaws

Sets completion criteria for each project activity to answer thequestion: "How much is enough?"

Uses identical approaches for development and maintenance

Can be used for hardware-software system development

BN Shankar Gowda 31

Evolutionary Development Models Software like all complex systems , evolves over a period of time.

Business and product requirement often change as developmentproceeds, making a straight line path to an end product unrealistic.

The set of core product / system requirements is well understood,but the details of the product/ system extensions have yet to bedefined.

Evolutionary models are iterative.

They are characterized in a manner that software engineers todevelop increasingly more complete versions of the software.

Types of Evolutionary Models

Prototyping

Concurrent Development model

BN Shankar Gowda 32

Evolutionary Models: Prototyping

Communicat ion

Quick plan

Construct ionofprototype

ModelingQuick design

Delivery& Feedback

Deployment

BN Shankar Gowda 33

In what situation is this model useful?Requirements are very seldom fully known at the beginning of a

project, the Prototyping model therefore addresses this fact. How is it used?It starts with first building a simplified version of the system, then seek

feedback from the different stakeholders of the project, then comeup with a second, better system. This cycle is repeated until all thestakeholders are completely satisfied with all the aspects of thesystem.

Variations on the theme of prototyping can be exploited further toinscrease the success rate of the project. For instance, a developmentteam can consider approaches like: Creating just a user interface without background data processing or

validation logic. Coding only one or a few important functionality of the system or subsystems.

Prototyping

BN Shankar Gowda 34

Throwaway Prototyping ModelUseful in "proof of concept" or situations where

requirements and user's needs are unclear or poorlyspecified. The approach is to construct a QUICK ANDDIRTY partial implementation of the system during orbefore the requirements phase.

Exploratory Prototyping ModelUseful in projects that have low risk in such areas as

losing budget, schedule predictability and control,large-system integration problems, or coping withinformation sclerosis, but high risk in user interfacedesign.

Prototyping Types

BN Shankar Gowda 35

Evolutionary Development

Outlinedescription

Specification

Development

Validation

Initial Version

Final Version

IntermediateVersion

Interleaved activities Work Products

BN Shankar Gowda 36

Evolutionary prototyping

Develop abstractspecification

User prototypesystem

Build prototypesystem

Deliver System SystemAdequate

yes

No

BN Shankar Gowda 37

Prototyping model consists of the following steps:

Requirements: Elicitation of requirements at the time.

Design: Integrate the initial layer of requirements into a new orexisting design to form a prototype.

Prototype Creation or Modification: Design is used tocreate a prototype of the system. This may mean creating aprototype or modifying the already created one (in the earlier cycle).

Assessment: The prototype is presented to the customer forreview and assessment. Comments and suggestions are collectedfrom the customer and recorded.

Prototype Refinement: Information collected from thecustomer is use to refine the prototype.

Systems Implementation: In most cases, the system isrewritten once requirements are understood.

BN Shankar Gowda 38

Disadvantages Prototyping can lead to false expectations. This is a situation created

by the customer thinking the system is ready to roll out. Thecustomer does not see the work that has to be done internally suchas database normalization and the like.

In addition, this model may lead to Poor System Design, especiallywhen we have to "grow“ the software. At some point, in maybecome obvious that our choice of data structures for the earlyiterations were not general enough, and needs to be changed. Sucheffects are not as rare as we would like them to be.

More importantly this model makes it more difficult to schedule theactual implementation. Situations where Market Timing isimportant, the risk of using this model is very high.

The process is not visible for measuring progress. Systems are often poorly structured, due to continual changes. Special tools and techniques may be required.

Component-based software engineering Based on systematic reuse where systems are

integrated from existing components or COTS(Commercial-off-the-shelf) systems.

Process stages Component analysis; Requirements modification; System design with reuse; Development and integration.

This approach is becoming increasingly usedas component standards have emerged.

39BN Shankar Gowda

Component-Based Software Engineering

Requirementsspecification

Componentanalysis

Developmentand integ ration

System designwith reuse

Requirementsmodification

Systemvalidation

40BN Shankar Gowda

BN Shankar Gowda 41

Component Based Development

The model composes applications from prepackaged or off-the shelfsoftware components with well defined interfaces that enable thecomponent to be integrated into the software.

CBD incorporates many of the characteristics of the Spiral modeland is evolutionary in nature, demanding an iterative approach.

Modeling and Construction begins activities begin with theidentification of Candidate components.

Regardless of the technology that is used to build the component,CBD incorporates the following steps: Available component-based products are researched and evaluated for the

application domain in question. Component integration issues are considered. A software architecture is designed to accommodate the components. Components are integrated into the architecture Comprehensive testing is conducted

BN Shankar Gowda 42

The Unified ProcessDeveloped by James Rumbaugh, Grady Booch, and Ivar Jacobson.

•Draws the best FEATURES and CHARACTERSTICS ofconventional Software process models.

• Focuses on the importance of Customer communication &streamlined methods for describing the customer’s view ofthe system.

• Emphasizes the important role of software architecture andhelps architect focus on the right goals, likeunderstandability, reliance to future changes, and reuse.

• The unified process is incremental, and iterative, providingthe evolutionary feel.

• Provides necessary technology to support Object-Oriented-SE practice.

•Hybrid Process model.

BN Shankar Gowda 43

The Unified Process (UP) cont’d…Phases of UP

soft ware increment

Release

Incept ion

Elaborat ion

const ruct ion

t ransit ion

product ion

BN Shankar Gowda 44

The INCEPTION Phase:

Encompasses both Customer Communication & Planning Activities.

Collaborates with customers, end-users, and all stake holders foridentifying the fundamental Business requirements in the for ofUSE-CASES.

A rough Architecture for the system is proposed. Initially, a tentative outline of major subsystems and the function and features

that populate them is considered.

A Plan for Iterative, incremental nature of ensuing the project isdeveloped. Planning identifies Resources, Assesses major risks, defines a Schedule,

decomposes the project, and establishes basis for Incremental deliverables.

The Unified Process (UP)Phases of UP cont’d…

BN Shankar Gowda 45

. Use-Cases describes the features and functionality desired bymajor class of users/ sequence of actions that are performed by useras they interact with the software. Eg: ATM

Use-Case helps to identify the scope of the project and provide abasis for Project Planning.


BN Shankar Gowda 46

The ELABORATION Phase:Encompasses Customer communication and Modeling activities of

Generic frame work activities. Refines and expands preliminary Use-Cases that were developed as

part of Inception phase Expands Architectural representation to include 5 different views of

software: The Use-Case model :Use-case diagramUsers and Functionality The Analysis model :Sequence /Activity diagram/state chart The Design model :Class Diagram The Implementation model :Component diagram The Deployment model. :Deployment diagram

A close review is done on the Plan and any modification to the planis made.


BN Shankar Gowda 47

The CONSTRUCTION Phase:

Identical to the construction activity of generic process.

Using Architectural model as input, the construction phase develops/ acquires software components that will make each use-caseoperational for end-users.

The Analysis and Design models started during Elaboration phaseare completed to reflect the final version of s/w increment.

All reqd. functionalities and features are implemented.

Unit tests are designed & executed for each use-case.

Integration activities are conducted.


BN Shankar Gowda 48

The TRANSITION Phase:Encompasses the latter stages of generic construction activity & first

part of generic Deployment activity.. Developed software is given to end-users for beta-testing. User feedback reports DEFECTS & NECESSARY changes. Necessary work products/ support information are created. The output of Transition phase is USABLE SOFTWARE

RELEASE.The PRODUCTION phase:Identical to deployment phase of generic activity. The software is monitored. Support for operating environment is provided Defect reports & requests for changes are submitted and evaluated.


Six Fundamental best practices recommended

Develop s/w iteratively: plan increments based on customer priorities

Manage Requirements: Explicitly keep track of customer’s requirements

and keep track of changes to these requirements.

Use Component based architecture: Structure the system architecture into components

Visually model s/w: Use Graphical UML model

Verify s/w quality: Control changes to s/w: Manage changesBN Shankar Gowda 49

BN Shankar Gowda 50

It is most likely that at the same time the Construction

Transition and

Production

Phases are being conducted.


BN Shankar Gowda 51

UP Phases

Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

BN Shankar Gowda 52

Work Products of Unified Process ModelInception phase

Vision documentInitial use-case modelInitial project glossaryInitial business caseInitial risk assessment.Project plan,phases and iterations.Business model,if necessary.One or more prototypes

Elaboration phaseUse-case modelSupplementary requirementsincluding non-functionalAnalysis modelSoftware architectureDescription.Executable architecturalprototype.Preliminary design modelRevised risk listProject plan includingiteration planadapted workflowsmilestonestechnical work productsPreliminary user manual

Construction phase

Design modelSoftware componentsIntegrated softwareincrementTest plan and procedureTest casesSupport documentationuser manualsinstallation manualsdescription of currentincrement

Transition phaseDelivered software

incrementBeta test reportsGeneral user

feedback

Process activities Software specification Software design and implementation Software validation Software evolution

53BN Shankar Gowda

Software specification The process of establishing what services

are required and the constraints on thesystem’s operation and development.

Requirements engineering process Feasibility study; Requirements elicitation and analysis; Requirements specification; Requirements validation.

54BN Shankar Gowda

The requirements engineering process

Feasibilitystud y

Requir ementselicitation and

anal ysisRequir ementsspecification

Requir ementsvalidation

Feasibilityrepor t

Systemmodels

User and systemrequirements

Requir ementsdocument

55BN Shankar Gowda

Software design and implementation

The process of converting the systemspecification into an executable system.

Software design Design a software structure that realises the

specification; Implementation

Translate this structure into an executableprogram;

The activities of design andimplementation are closely related andmay be inter-leaved.

56BN Shankar Gowda

Design process activities Architectural design Abstract specification Interface design Component design Data structure design Algorithm design

57BN Shankar Gowda

The software design process

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

58BN Shankar Gowda

Structured methods Systematic approaches to developing a

software design. The design is usually documented as a set

of graphical models. Possible models

Object model; Sequence model; State transition model; Structural model; Data-flow model.

59BN Shankar Gowda

Programming and debuggingTranslating a design into a program and

removing errors from that program.Programming is a personal activity -

there is no generic programmingprocess.

Programmers carry out some programtesting to discover faults in the programand remove these faults in thedebugging process.

60BN Shankar Gowda

The debugging process

Locateerr or

Designerror repair

Repairerror

Re-testpr ogram

61BN Shankar Gowda

Software Validation Verification and validation (V & V) is intended

to show that a system conforms to itsspecification and meets the requirements ofthe system customer.

Involves checking and review processes andsystem testing.

System testing involves executing the systemwith test cases that are derived from thespecification of the real data to be processedby the system.

62BN Shankar Gowda

The Testing process

Componenttesting

Systemtesting

Acceptancetesting

63BN Shankar Gowda

Testing stages Component or unit testing

Individual components are tested independently; Components may be functions or objects or

coherent groupings of these entities. System testing

Testing of the system as a whole. Testing ofemergent properties is particularly important.

Acceptance testing Testing with customer data to check that the

system meets the customer’s needs.

64BN Shankar Gowda

Testing phases

Requir ementsspecifica tion

Systemspecifica tion

Systemdesign

Detaileddesign

Module andunit codeand test

Sub-systeminteg ration

test plan

Systeminteg rationtest plan

Acceptancetest plan

Service Acceptancetest

Systeminteg ration test

Sub-systeminteg ration test

65BN Shankar Gowda

Software Evolution Software is inherently flexible & can change. As requirements change through changing

business circumstances, the software thatsupports the business must also evolve andchange.

Although there has been a demarcationbetween development and evolution(maintenance) this is increasingly irrelevantas fewer and fewer systems are completelynew.

66BN Shankar Gowda

System Evolution

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems

67BN Shankar Gowda

Static workflowsWorkflow Description

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

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

Analysis and design A design model is created and documented using architecturalmodels, component models, object models and sequence models.

Implementation The components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from designmodels helps accelerate this process.

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

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

Configuration andchange management

This supporting workflow managed changes to the system (seeChapter 29).

Project management This supporting workflow manages the system development (seeChapter 5).

Environment This workflow is concerned with making appropriate software toolsavailable to the software development team. 68BN Shankar Gowda

Computer-Aided Software Engineering Computer-aided software engineering (CASE) is

software to support software development andevolution processes.

Activity automation Graphical editors for system model development; 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.

69BN Shankar Gowda

CASE Technology Case technology has led to significant

improvements in the software process.However, these are not the order ofmagnitude improvements that were oncepredicted Software engineering requires creative thought -

this is not readily automated; Software engineering is a team activity and, for

large projects, much time is spent in teaminteractions. CASE technology does not reallysupport these.

70BN Shankar Gowda

CASE classification Classification helps us understand the different

types of CASE tools and their support for processactivities.

Functional perspective Tools are classified according to their specific

function.

Process perspective Tools are classified according to process activities

that are supported.

Integration perspective Tools are classified according to their organisation

into integrated units.71BN Shankar Gowda

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

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

Language-processing tools Compilers, interpreters

Program analysis tools Cross reference generators, static analysers, dynamic analysers

Testing tools Test data generators, file comparators

Debugging tools Interactive debugging systems

Documentation tools Page layout programs, image editors

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

72BN Shankar Gowda

Activity-based tool classification

Specification Design Implementation Verificationand

Validation

Re-eng ineering tools

Testing tools

Debugg ing tools

Prog ram analysis tools

Language-processingtools

Method suppor t tools

Prototyping tools

Configurationmanagement tools

Change management tools

Documentation tools

Editing tools

Planning tools

73BN Shankar Gowda

CASE integration Tools

Support individual process tasks such asdesign consistency checking, text editing, etc.

Workbenches Support a process phase such as specification

or design, Normally include a number ofintegrated tools.

Environments Support all or a substantial part of an entire

software process. Normally include severalintegrated workbenches.

74BN Shankar Gowda

Tools, workbenches, environments

Single-methodworkbenches

Gener al-purposeworkbenches

Multi-methodworkbenches

Langua ge-specificworkbenches

Pro gramming TestingAnalysis anddesign

Integ rateden vironments

Process-centr eden vironments

Filecompar atorsCompilersEditors

EnvironmentsWor kbenchesTools

CASEtechnolo g y

75BN Shankar Gowda

Key points Software processes are the activities involved in

producing and evolving a software system. Software process models are abstract representations of

these processes. General activities are specification, design and

implementation, validation and evolution. Generic process models describe the organisation of

software processes. Examples include the waterfallmodel, evolutionary development and component-basedsoftware engineering.

Iterative process models describe the software processas a cycle of activities.

76BN Shankar Gowda

Key points Requirements engineering is the process of developing a

software specification. Design and implementation processes transform the

specification to an executable program. Validation involves checking that the system meets to

its specification and user needs. Evolution is concerned with modifying the system after

it is in use. The Rational Unified Process is a generic process model

that separates activities from phases. CASE technology supports software process activities.

77BN Shankar Gowda

Documents

Software Engineering: A Practitioner s Approach, 6/e