Upload
lizbeth-bell
View
224
Download
0
Tags:
Embed Size (px)
Citation preview
Objectives
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.
S/W Process Models
2
The 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.
S/W Process Models
3
Abstraction
Elimination of unnecessary detail Model
Abstract view Abstract
representation
S/W Process Models
4
Software 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 processHighly intellectualMust dynamically adjust to creative
needs of professionals and tasks
S/W Process Models
5
Critical Software Process Issues
Factors to considerNature of the project.
Software projects are different.Organizational needs.Experience level of members/teamCurrent product status
E.g., Brand new product?Available tools and facilities
S/W Process Models
6
Critical Software Process Issues
Factors to considerQuality
More intensive quality assuranceProduct Technology
New technology or algorithm?Requirements instability
Unknown requirements Unstable requirements
Complexity Large systems
S/W Process Models
7
Waterfall model
Requirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation and
maintenance
S/W Process Models
9
Waterfall model phases
Requirements analysis and definitionSystem and software designImplementation and unit testingIntegration and system testingOperation and maintenanceThe 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.
S/W Process Models
10
Waterfall 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. S/W Process Models
11
V-Shaped Model
Project and Requirements Planning
Product Requirements and Specification Analysis
Architecture or High-Level Design
Detailed Design
Unit Testing
Integration and Testing
System and Acceptance Testing
Coding
Production Operation and Maintenance
S/W Process Models
12
V-Shaped Model
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.
S/W Process Models
13
V-Shaped Model
Emphasizes the relationship between the phases preceding and following coding.
The dotted lines indicate that these phases should be considered in parallel.
S/W Process Models
14
Phases in the V-Shaped Model
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.
S/W Process Models
15
Phases in the V-Shaped Model
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.
S/W Process Models
16
Phases in the V-Shaped Model
Coding– Transforms the algorithms defined during the design
phase into software. Unit Testing
– Checks each code module for errors.
S/W Process Models
17
Phases in the V-Shaped Model
Integration and Testing– Integrate and test individual code modules.
System and acceptance testing– Test entire software system in its hardware
environment.S/W Process Models
18
Phases in the V-Shaped Model
Productions, operation and maintenance– Puts software into production and provides for
enhancements and corrections.
S/W Process Models
19
V-Shaped Model Problems
Does not easily handle concurrent events
No iteration of phasesCannot handle dynamic changes in
requirements throughout the life cycleRequirements are tested too late to
make changes without affecting the schedule
No risk analysisS/W Process Models
20
Spiral 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.
S/W Process Models
21
S/W Process Models 22
Spiral model of the software process
Determine objectives, alternatives and constraints
Evaluate alternatives, identify, resolve risks
Develop, verify next-level product
Plan next phaseAnd test plan
requirements
Operational prototype
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2
Prototype 3Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmar ks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
Code
Unit test
IntegrationtestAcceptance
testService
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
Spiral 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.
S/W Process Models
23
Spiral Model problems
Highly dependent on risk analysis Requires very knowledgeable personnel Errors may occur if risk is not properly
analyzedWillingness of the Customer
S/W Process Models
24
RAD Model
Rapid Application DevelopmentUser is involved in all phasesUse tools that allow product evaluation at
all stages of developmentCharacterized by quick turnaround time
from requirements definition to deliveryHigh component reuse factor
S/W Process Models
25
RAD ModelD
evel
opm
ent
Eff
ort
Time
Requirements Planning
User Description
Construction
Cut Over
User Involvement
S/W Process Models
26
Phases 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.
S/W Process Models
27
Phases 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.
S/W Process Models
28
Strengths of RAD
Use of powerful tools reduces cycle time
Lower cost due to reduced cycle timeOngoing customer involvementReuse of existing program component
S/W Process Models
29
RAD problems
Heavily dependent on user involvement throughout the process.
Requires highly skilled developers in the use of development tools.
Heavily dependent on reusable components.
S/W Process Models
30
Generic activities
SpecificationDesign (and implementation)ValidationEvolution
S/W Process Models
31
Specification
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.
S/W Process Models
32
Example requirements engineering process
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
S/W Process Models
33
Design 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.
S/W Process Models
34
Example design process activities
Architectural designAbstract specificationInterface designComponent designData structure designAlgorithm design
S/W Process Models
35
Example software design process
Architecturaldesign
Abstractspecification
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
S/W Process Models
36
Validation
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.
S/W Process Models
37
Testing 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.
S/W Process Models
38
Testing 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
S/W Process Models
39
Evolution
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.
S/W Process Models
40