Upload
caitlin-powers
View
223
Download
7
Embed Size (px)
Citation preview
Chapter 4 프로세스 모델
Process Models
임현승강원대학교
Revised from the slides by Roger S. Pressman and Bruce R. Maxim for the book “Software Engineering: A Practitioner’s Approach, 8/e”
Prescriptive Models
• Prescriptive process models advocate an orderly approach to software engineering
• That leads to a few questions …– If prescriptive process models strive for structure
and order, are they inappropriate for a software world that thrives on change?
– Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?
2
The Waterfall Model
Communication Planning
ModelingConstruction
Deployment analysis design code
test
project initiation requirement gathering estimating
scheduling tracking
delivery support feedback
3
The Waterfall Model
• Challenges of the waterfall model– Real projects rarely follow the sequential flow– Difficult to accommodate the uncertainty in
requirements– A working version of SW will not be available until
late in the project time span
• Blocking states– Some members must wait for other members of the
team to complete dependent tasks
• Advantage– Useful if requirements are fixed and work is to
proceed to completion in a linear manner4
The V-Model• Describes the relationship of quality assurance actions
to the actions associated with communication, modeling, and early construction activities
5
The Incremental Model
C o m m u n i c a t i o n
P 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 t
d e l i v e ry f e e d b a c k
analys is
des ign code
t es t
increment # 1
increment # 2
delivery of 1st increment
delivery of 2nd increment
delivery of nth increment
increment # n
project calendar time
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
De p l o y m e n t
d e l i v e r y
f e e d b a c k
analys is
des ign code
t es t
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 t
d e l i v e r y
f e e d b a c k
analys is
des igncode t es t
6
Example using the Incremental Model
• Word-processing software– Develop the basic file management,
editing, and document production functions in the first increment
– More sophisticated editing and document production capabilities in the second increment
– Spelling and grammar checking in the third increment
7
Evolutionary Models: Prototyping
• Evolutionary models are iterative
Constructionof prototype
Communication
Quick plan
Construction of prototype
Modeling Quick design
Delivery & Feedback
Deployment
communication
Quickplan
ModelingQuick design
Constructionof prototype
Deploymentdelivery &feedback
8
Evolutionary Models: Prototyping
• A prototyping paradigm is the best-fit for the following situations– A customer does not identify detailed
requirements for functions and features– Developers are unsure of the efficiency
of an algorithm, the adaptability of an operating systems, or the form of human-machine interaction, etc.
9
Evolutionary Models: Prototyping
• Advantages– Prototyping paradigm helps SW engineers
and other stakeholders to better understand what is to be built
– The quick design and implementation focuses on a representation of those aspects of the SW that will be visible to the end users
– Ideally, the prototype serves as a mechanism for identifying SW requirements
10
Evolutionary Models: Prototyping
• Problems– In most projects, the first system built is
barely usable– Software engineers try to modify the
prototype to use it as a working version– Once stakeholders see a working
prototype, they demand that a few fixes be applied to make the prototype a working product
11
Evolutionary Models: The Spiral
communication
planning
modeling
constructiondeployment delivery feedback
start
analysis design
code test
estimation scheduling risk analysis
12
Evolutionary Models: The Spiral
• Characteristics– Uses prototyping as a risk reduction
mechanism, but more importantly, enables us to apply the prototyping approach at any stage in the evolution of the product
– It may be difficult to convince customers that the evolutionary approach is controllable (demands considerable risk assessment expertise)
13
Concurrent Models
Under review
Baselined
Done
Under
revision
Awaiting
changes
Under
development
none
Modeling activity
represents the stateof a software engineeringactivity or task
Allows a software team to represent iterative and concurrent elements of any of the process models
14
Other Process Models
• Component based development—the process to apply when reuse is a development objective
• Formal methods—emphasizes the mathematical specification of requirements
15
Other Process Models
• AOSD (Aspect-Oriented Software Development)– provides a process and methodological
approach for defining, specifying, designing, and constructing aspects (e.g., security, fault-tolerance, the application of business rules)
• Unified Process– a “use-case driven, architecture-centric,
iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)
16
The Unified Process (UP)
software increment
Release
Inception
Elaboration
construction
transition
production
inception
elaboration
17
UP Phases
Inception Elaboration Construction Transition Production
UP Phases
Workflows
Requirements
Analysis
Design
Implementation
Test
Iterations #1 #2 #n-1 #n
Support
18
UP Work ProductsInception phase
Elaboration phase
Construction phase
Transition phase
Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n
Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual
Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals description of current increment
Delivered software increment Beta test reports General user feedback
19
Personal Software Process (PSP)
• Planning. This activity isolates requirements and develops both size and resource estimates. In addition, a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created.
• High-level design. An external specification is created for each component and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked.
20
Personal Software Process (PSP)
• High-level design review. Formal verification methods (Chapter 21) are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results.
• Development. The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.
• Postmortem. Using measures and metrics collected the effectiveness of the process is determined. (If this is a large amount of data it should be analyzed statistically.) Measures and metrics should provide guidance for modifying the process to improve its effectiveness.
21
Team Software Process (TSP)
• Build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams (IPT) of three to about 20 engineers.
• Show managers how to coach and motivate their teams and how to help them sustain peak performance.
• Accelerate software process improvement by making CMM Level 5 behavior normal and expected. – The Capability Maturity Model (CMM), a measure of the effectiveness of a
software process, is discussed in Chapter 30.• Provide improvement guidance to high-maturity
organizations. • Facilitate university teaching of industrial-grade
team skills.22