CEN 4021 2 nd Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi sadjadi/ [email protected] Software Process Models

CEN 4021 2nd Lecture

CEN 4021 CEN 4021 Software Engineering II Software Engineering II

Instructor: Masoud Sadjadi

http://www.cs.fiu.edu/~sadjadi/

[email protected]

Software Process ModelsSoftware Process Models

2nd LectureCEN 4021: Software Engineering II

AcknowledgementsAcknowledgements

Dr. Onyeka Ezenwoye

Dr. Peter Clarke

Dr. Betty Cheng

Dr. Bernd Bruegge

Dr. Allen Dutoit

2


ObjectivesObjectives

To understand– Software process and process models,

including the main characteristics of each model, critical software process issues, and the pros and cons of each model.

– The generic process activities and what they mean. This includes details of what exactly each activity is for and the stages within them.


The software processThe software process

A structured set of activities required to develop a software system– Specification;– Design;– Validation;– Evolution.

A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.


AbstractionAbstraction

Elimination of unnecessary detail

Model Abstract view Abstract representation


Software Process modelSoftware Process model

A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

No universal software process Highly intellectual Must dynamically adjust to creative

needs of professionals and tasks


Critical Software Process Critical Software Process IssuesIssues

Factors to consider– Nature of the project.

Software projects are different.

– Organizational needs.

– Experience level of members/team

– Current product statusE.g., Brand new product?

– Available tools and facilities


Critical Software Process Critical Software Process IssuesIssues

Factors to consider– Quality

More intensive quality assurance

– Product TechnologyNew technology or algorithm?

– Requirements instabilityUnknown requirementsUnstable requirements

– ComplexityLarge systems


Software Process ModelsSoftware Process Models

Waterfall

V

Spiral

Rapid Application Development


Waterfall modelWaterfall model

Requirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation and

maintenance


Waterfall model phasesWaterfall model phases

Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The main drawback of the waterfall model is

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


Waterfall model problemsWaterfall model problems

Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.

Few business systems have stable requirements.

Requirements have to be understood early on.


V-Shaped ModelV-Shaped Model

Project and Requirements Planning

Product Requirements

and Specification

AnalysisArchitecture or

High-Level Design

Detailed Design

Unit Testing

Integration and Testing

System and Acceptance

Testing

Coding

Production Operation and Maintenance



A variation of the Waterfall model. Places strong emphasis on Verification and Validation. Testing of the product is planned in the early phases of the

process. Acceptance test plan is developed. System test plan is developed.



Emphasizes the relationship between the phases preceding and following coding.

The dotted lines indicate that these phases should be considered in parallel.


Phases in the V-Shaped Phases in the V-Shaped ModelModel

Project and requirements planning– Determines system requirements and allocation of resources.

Product requirements and specification analysis– Analysis of software problem, concludes with complete

specification of the software.



Architecture or High-level design– Determines how the software functions are to implement the

design. Detailed Design

– Defines algorithms for components that were defined during the architecture phase.



Coding– Transforms the algorithms defined during the design phase into

software.

Unit Testing– Checks each code module for errors.



Integration and Testing– Integrate and test individual code modules.

System and acceptance testing– Test entire software system in its hardware

environment.



Productions, operation and maintenance– Puts software into production and provides for enhancements

and corrections.


V-Shaped Model ProblemsV-Shaped Model Problems

Does not easily handle concurrent events No iteration of phases Cannot handle dynamic changes in

requirements throughout the life cycle Requirements are tested too late to make

changes without affecting the schedule No risk analysis


Spiral developmentSpiral development

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

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

No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.

Risks are explicitly assessed and resolved throughout the process.


Spiral model of the software Spiral model of the software processprocess

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternatives,identify, resolve risks

Determine objectives,alternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

Determine objectives, alternatives and

constraints

Evaluate alternatives, identify, resolve risks

Develop, verify next-level product

Plan next phaseAnd test plan

requirements

Operational prototype


Spiral model sectorsSpiral model sectors

Objective setting– Specific objectives for the phase are identified.

Risk assessment and reduction– Risks are assessed and activities put in place

to reduce the key risks. Development and validation

– A development model for the system is chosen which can be any of the generic models.

Planning– The project is reviewed and the next phase of

the spiral is planned.


Spiral Model problemsSpiral Model problems

Highly dependent on risk analysis– Requires very knowledgeable personnel– Errors may occur if risk is not properly analyzed

Willingness of the Customer


RAD ModelRAD Model

Rapid Application Development

User is involved in all phases Use tools that allow product evaluation at all

stages of development Characterized by quick turnaround time from

requirements definition to delivery High component reuse factor


RAD ModelRAD ModelD

evel

opm

ent

Eff

ort

Time

Requirements Planning

User Description

Construction

Cut Over

User Involvement


Phases in RAD ModelPhases in RAD Model

Requirements planning phase– Requirements are gathered using technique called joint

requirements planning (JRP) User description

– Joint application design (JAP) is used to harness user involvement.


Phases in RAD ModelPhases in RAD Model

Construction phase– Combines design, coding, testing. Heavy use of code

generators and other production tools

Cut over– Acceptance testing, installation and user training.


Strengths of RADStrengths of RAD

Use of powerful tools reduces cycle time Lower cost due to reduced cycle time Ongoing customer involvement Reuse of existing program component


RAD problemsRAD problems

Heavily dependent on user involvement throughout the process.

Requires highly skilled developers in the use of development tools.

Heavily dependent on reusable components.


Generic activitiesGeneric activities

Specification Design (and implementation) Validation Evolution


SpecificationSpecification

The process of establishing what services are required and the constraints on the system’s operation and development.

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


example requirements example requirements engineering processengineering process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument


design and implementationdesign and implementation

The process of converting the system specification into an executable system.

design– Design a software structure that realises the

specification; Implementation

– Translate this structure into an executable program;

The activities of design and implementation are closely related and may be inter-leaved.


example design process example design process activitiesactivities

Architectural design Abstract specification Interface design Component design Data structure design Algorithm design


example software design example software design processprocess

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products


ValidationValidation

Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer.

Involves checking and review of processes, various testing stages.

Testing involves executing the system with test cases that are derived from the specification.

Testing tries to establish if observed behaviour matches expected behaviour.


Testing stagesTesting stages

Unit testing– Individual components are tested independently; – Components may be functions or objects or coherent

groupings of these entities. Integration testing (subsystem testing)

– Individual components are merged and tested. System testing

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

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

meets the customer’s needs.


Testing phasesTesting phases

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand test

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test

note that model is V


EvolutionEvolution

Software is inherently flexible and can change.

As requirements change through changing business circumstances, the software that supports the business must also evolve and change.

Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.


Example evolution processExample evolution process

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems

Documents

CEN 4021 2 nd Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi sadjadi/ [email protected] Software Process Models