1 / 31 cs 425/625 software engineering software processes based on chapter 3 of the textbook...
Post on 21-Dec-2015
222 views
TRANSCRIPT
1 / 31
CS 425/625 Software EngineeringCS 425/625 Software Engineering
Software ProcessesSoftware Processes
Based on Chapter 3 of the textbook [Somm00]: Ian Sommerville, Software Engineering, 6th Ed., Addison-Wesley, 2000
and on Ch3 PowerPoint presentation fromwww.comp.lancs.ac.uk/computing/resources/IanS/SE6/Slides/index.html
September 3, 2003
2 / 31
OutlineOutline
Software Process ModelsSoftware Process Models Waterfall modelWaterfall model Evolutionary developmentEvolutionary development Formal developmentFormal development Reuse-oriented developmentReuse-oriented development Incremental modelIncremental model Spiral modelSpiral model
Software Process ActivitiesSoftware Process Activities SpecificationSpecification Design and implementationDesign and implementation ValidationValidation EvolutionEvolution
Automated Process SupportAutomated Process Support
3 / 31
Software Process ModelsSoftware Process Models
Software processSoftware process = organized set of activities = organized set of activities aimed at building a software systemaimed at building a software system
Software process modelSoftware process model = an abstract = an abstract representation of a software processrepresentation of a software process
Fundamental software process activities:Fundamental software process activities: Software specificationSoftware specification Software design and implementationSoftware design and implementation Software validationSoftware validation Software evolutionSoftware evolution
4 / 31
Software Process Models: Waterfall..Software Process Models: Waterfall..
The Waterfall modelThe Waterfall model [Somm00, Fig 3.1][Somm00, Fig 3.1]
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
5 / 31
Software Process Models: .Waterfall.Software Process Models: .Waterfall.
Main characteristics: Also called classic software life cycle or
sequential model Process activities (phases/stages) are clearly
separated After a number of iterations, phases of the life
cycle (such as specification and design) are “frozen”
6 / 31
Software Process Models: ..WaterfallSoftware Process Models: ..Waterfall
Advantages: Organized approach, provides robust separation of
phases Reflects common engineering practice
Disadvantages:Disadvantages: Doesn’t cope well with changes required by the client Doesn’t cope well with changes required by the client Development teams might wait for each otherDevelopment teams might wait for each other A working version of the product is available only lateA working version of the product is available only late
Applicability:Applicability: When requirements are well known and few changes When requirements are well known and few changes
are likely to be neededare likely to be needed Can be used also for parts of larger software systemsCan be used also for parts of larger software systems
7 / 31
Software Process Models: Software Process Models: Evolutionary Development…Evolutionary Development…
Evolutionary Development model Evolutionary Development model [Somm00, Fig 3.2][Somm00, Fig 3.2]
ValidationFinal
version
DevelopmentIntermediate
versions
SpecificationInitial
version
Outlinedescription
Concurrentactivities
8 / 31
Software Process Software Process Models: .Evolutionary Development..Models: .Evolutionary Development..
Main characteristics: The phases of the software construction are
interleaved Feedback from the user is used throughout the entire
process The software product is refined through many versions
Types of evolutionary development: Exploratory development Throw-away prototyping
9 / 31
Software Process Software Process Models: ..Evolutionary Development.Models: ..Evolutionary Development.
Advantages: Deals constantly with changes Provides quickly an initial version of the system Involves all development teams
Disadvantages: Quick fixes may be involved “Invisible” process, not well-supported by
documentation The system’s structure can be corrupted by
continuous change
10 / 31
Software Process Models: …Software Process Models: …Evolutionary DevelopmentEvolutionary Development
Disadvantages [cont’d]: Special tools and techniques may be necessary The client may have the impression the first
version is very close to the final product and thus be less patient
Applicability: When requirements are not well understood When the client and the developer agree on a
“rapid prototype” that will be thrown away Good for small and medium-sized software
systems
11 / 31
Software Process Models: Software Process Models: Formal Development….Formal Development….
The Formal System Development modelThe Formal System Development model [Somm00, Fig 3.3][Somm00, Fig 3.3]
Requirementsdefinition
Formalspecification
Formaltransformation
Integration andsystem testing
12 / 31
Software Process Models: Software Process Models: .Formal Development….Formal Development…
The Formal Transformation process The Formal Transformation process [Somm00, Fig 3.4][Somm00, Fig 3.4]
R2Formal
specificationR3
Executableprogram
P2 P3 P4
T1 T2 T3 T4
Proofs of transformation correctness
Formal transformations
R1
P1
13 / 31
Software Process Models: Software Process Models: ..Formal Development....Formal Development..
Main characteristics: Approach based on formal, mathematics-based
techniques for specification, refinement, and verification
A formal specification is produced, than transformed using mathematical methods into the software product’s design and code; formal verification is also used
14 / 31
Software Process Models: Software Process Models: ...Formal Development....Formal Development.
Advantages: Transformations between stages are sufficiently close
to ensure better verification and less expensive proofs Errors, omissions, ambiguities, and contradictions in
specifications are more completely detected The final product is more likely to satisfy the The final product is more likely to satisfy the
requirements requirements The product’s reliability is increased The product’s reliability is increased
15 / 31
Software Process Models: Software Process Models: ….Formal Development….Formal Development
Disadvantages:Disadvantages: Requires knowledge of and experience with Requires knowledge of and experience with
formal methodsformal methods Are resource consumingAre resource consuming
Applicability:Applicability: Safety- and security-critical systemsSafety- and security-critical systems Parts of the systems that must be thoroughly Parts of the systems that must be thoroughly
verified verified
16 / 31
Software Process Models: Software Process Models: Reuse-Oriented Development…Reuse-Oriented Development…
The Reuse-oriented Development modelThe Reuse-oriented Development model [Somm00, Fig 3.5][Somm00, Fig 3.5]
Requirementsspecification
Componentanalysis
Developmentand integration
System designwith reuse
Requirementsmodification
Systemvalidation
17 / 31
Software Process Models: .Reuse-Oriented..Software Process Models: .Reuse-Oriented..
Main characteristics:Main characteristics: Makes intensive use of existing reusable Makes intensive use of existing reusable
componentscomponents The focus is on integrating the components The focus is on integrating the components
rather than on creating them from the scratchrather than on creating them from the scratch
18 / 31
Software Process Models: ..Reuse-Oriented.Software Process Models: ..Reuse-Oriented.
Advantages:Advantages: Reduces considerably the software to be Reduces considerably the software to be
developed “in-house”developed “in-house” Allows faster deliveryAllows faster delivery In principle, more reliable systems, due to In principle, more reliable systems, due to
using previously tested componentsusing previously tested components
19 / 31
Software Process Models: …Reuse-OrientedSoftware Process Models: …Reuse-Oriented
Disadvantages:Disadvantages: Compromises in requirements are neededCompromises in requirements are needed Less control over the system’s evolutionLess control over the system’s evolution
Applicability:Applicability: When there is a pool of existing components that When there is a pool of existing components that
could satisfy the requirements of the new could satisfy the requirements of the new product product
20 / 31
Software Process Models: Software Process Models: Incremental Development…Incremental Development…
The Incremental Model The Incremental Model [Somm00, Fig 3.6][Somm00, Fig 3.6]
Valida teincrement
Develop systemincrement
Design systemarchitecture
Integrateincrement
Valida tesystem
Define outline requirements
Assign requirements to increments
System incomplete
Finalsystem
21 / 31
Software Process Models: .Incremental..Software Process Models: .Incremental..
Main characteristics:Main characteristics: Hybrid model that combines elements of the Hybrid model that combines elements of the
waterfall and evolutionary paradigmswaterfall and evolutionary paradigms The specification, design, and implementation The specification, design, and implementation
phases are broken in smaller incrementsphases are broken in smaller increments
22 / 31
Software Process Models: ..Incremental.Software Process Models: ..Incremental.
Advantages:Advantages: Provides better support for process iterationProvides better support for process iteration Reduces rework in the software construction processReduces rework in the software construction process Some decisions on requirements may be delayedSome decisions on requirements may be delayed Allows early delivery of parts of the systemAllows early delivery of parts of the system Supports easier integration of sub-systemsSupports easier integration of sub-systems Lower risk of project failure Lower risk of project failure Delivery priorities can be more easily set Delivery priorities can be more easily set
23 / 31
Software Process Models: ...IncrementalSoftware Process Models: ...Incremental
Disadvantages:Disadvantages: Increments need be relatively smallIncrements need be relatively small Mapping requirements to increments may not be Mapping requirements to increments may not be
easyeasy Common software facilities may be difficult to Common software facilities may be difficult to
identify identify Applicability:Applicability:
When it is possible to deliver the system “part-by-When it is possible to deliver the system “part-by-part” part”
24 / 31
Software Process Models: Spiral Model..Software Process Models: Spiral Model..
Boehm’s Spiral ModelBoehm’s Spiral Model [Somm00, Fig 3.7][Somm00, Fig 3.7]
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2Prototype 3
Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
CodeUnit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
25 / 31
Software Process Models: .Spiral Model.Software Process Models: .Spiral Model.
Main characteristics:Main characteristics: Also a hybrid model that support process iterationAlso a hybrid model that support process iteration The process is represented as a spiral, each loop in The process is represented as a spiral, each loop in
the spiral representing a process phasethe spiral representing a process phase Four sectors per loop: objective setting, risk Four sectors per loop: objective setting, risk
assessment and reduction, development and assessment and reduction, development and validation, planningvalidation, planning
Risk is explicitly taken into considerationRisk is explicitly taken into consideration
26 / 31
Software Process Models: ..Spiral ModelSoftware Process Models: ..Spiral Model
Advantages:Advantages: Risk reduction mechanisms are in placeRisk reduction mechanisms are in place Supports iteration and reflects real-world practicesSupports iteration and reflects real-world practices Systematic approachSystematic approach
Disadvantages: Requires expertise in risk evaluation and reduction Complex, relatively difficult to follow strictly Applicable only to large systems
Applicability: Internal development of large systems
27 / 31
Process Activities: SpecificationProcess Activities: Specification Requirements engineering Requirements engineering [Somm00, Fig 3.8][Somm00, Fig 3.8]
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
28 / 31
Process Activities: Design & ImplementationProcess Activities: Design & Implementation
A general model for design [Somm00, Fig 3.9]A general model for design [Somm00, Fig 3.9]
Architecturaldesign
Abstractspecification
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
29 / 31
Process Activities: TestingProcess Activities: Testing
The debugging process [Somm00, Fig 3.10]The debugging process [Somm00, Fig 3.10]
The testing process [Somm00, Fig. 3.11]The testing process [Somm00, Fig. 3.11]
Locateerror
Designerror repair
Repairerror
Re-testprogram
Sub-systemtesting
Moduletesting
Unittesting
Systemtesting
Acceptancetesting
Componenttesting
Integration testing Usertesting
30 / 31
Process Activities: EvolutionProcess Activities: Evolution
System evolutionSystem evolution [Somm00, Fig 3.13][Somm00, Fig 3.13]
Assess existingsystems
Define systemrequirements
Propose systemchanges
Modifysystems
Newsystem
Existingsystems
31 / 31
Automated Process SupportAutomated Process Support Classification of CASE technology Classification of CASE technology [Somm00, Fig 3.16][Somm00, Fig 3.16]
Single-methodworkbenches
General-purposeworkbenches
Multi-methodworkbenches
Language-specificworkbenches
Programming TestingAnalysis and
design
Integratedenvironments
Process-centredenvironments
Filecomparators
CompilersEditors
EnvironmentsWorkbenchesTools
CASEtechnology