1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 2, 3, &4 Process Software...
-
Upload
maud-heath -
Category
Documents
-
view
232 -
download
3
Transcript of 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 2, 3, &4 Process Software...
1
Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 6/eApproach, 6/e
Chapter 2, 3, &4Chapter 2, 3, &4ProcessProcess
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use OnlyMay be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.
2
Software Software ProcessProcess
A framework for the tasks that are required to build
high-quality software.
A process defines who is doing what, when, and how
to reach a certain goal.
3
A Process A Process FrameworkFramework
Process frameworkProcess frameworkFramework activity #1Framework activity #1
work taskswork taskswork productswork productsmilestones & deliverablesmilestones & deliverablesQA checkpointsQA checkpoints
……
Framework activity #nFramework activity #n
……
Umbrella ActivitiesUmbrella Activities
4
Generic Framework Generic Framework ActivitiesActivities
CommunicationCommunication: Communication and collaboration : Communication and collaboration with the stakeholders and encompasses requirement with the stakeholders and encompasses requirement gathering and other activities.gathering and other activities.
PlanningPlanning: Establishment of a plan: the technical tasks, : Establishment of a plan: the technical tasks, risks, resources, work products, and a work schedulerisks, resources, work products, and a work schedule
ModelingModeling:: Analysis of requirements: better understanding of Analysis of requirements: better understanding of
requirementsrequirements Design: that achieves the requirementsDesign: that achieves the requirements
ConstructionConstruction Code generation: manual or automatedCode generation: manual or automated Testing: uncover errors.Testing: uncover errors.
DeploymentDeployment: Delivery of software for customer : Delivery of software for customer evaluation with feedback.evaluation with feedback.
5
Umbrella ActivitiesUmbrella Activities Software project managementSoftware project management Formal technical reviewsFormal technical reviews Software quality assuranceSoftware quality assurance Software configuration managementSoftware configuration management Work product preparation and Work product preparation and
productionproduction Reusability managementReusability management MeasurementMeasurement Risk managementRisk management
6
The Process Model:The Process Model:AdaptabilityAdaptability
The framework activities will The framework activities will alwaysalways be applied on be applied on everyevery project ... BUT project ... BUT
The tasks (and degree of rigor) for The tasks (and degree of rigor) for each activity will vary based on:each activity will vary based on: the type of project the type of project characteristics of the projectcharacteristics of the project common sense judgment; concurrence of common sense judgment; concurrence of
the project teamthe project team
7
Process PatternsProcess Patterns Process patterns define a set of activities, actions, Process patterns define a set of activities, actions,
work tasks, work products and/or related behaviorswork tasks, work products and/or related behaviors A template is used to define a patternA template is used to define a pattern Typical examples:Typical examples:
Customer communication (a process activity)Customer communication (a process activity) Analysis (an action)Analysis (an action) Requirements gathering (a process task)Requirements gathering (a process task) Reviewing a work product (a process task)Reviewing a work product (a process task) Design model (a work product)Design model (a work product)
http://www.ambysoft.com/processPatternsPage.htmlhttp://www.ambysoft.com/processPatternsPage.html
8
Process Patterns – An Process Patterns – An ExampleExample
Pattern NamePattern Name: Prototyping: PrototypingIntentIntent: The objective is to build a model that can be assessed iteratively by : The objective is to build a model that can be assessed iteratively by
stakeholders in an effort to identify or solidify sw requirementsstakeholders in an effort to identify or solidify sw requirementsTypeType: Phase pattern: Phase patternInitial ContextInitial Context: The following preconditions must be met: 1. stakeholders : The following preconditions must be met: 1. stakeholders
have been identified; 2. a mode of communication b/w stakeholders and sw have been identified; 2. a mode of communication b/w stakeholders and sw team has been established; 3. the overriding problem has been identified team has been established; 3. the overriding problem has been identified by stakeholders; 4. an initial understanding of proj. scope, basic by stakeholders; 4. an initial understanding of proj. scope, basic requirements, and constraints has been developed.requirements, and constraints has been developed.
ProblemProblem: Requirements are hazy or nonexistent. Stakeholders are unsure : Requirements are hazy or nonexistent. Stakeholders are unsure that they need.that they need.
SolutionSolution: A description of the prototyping process is presented.: A description of the prototyping process is presented.Resulting ContextResulting Context: A software prototype that identifies basic : A software prototype that identifies basic
requirements is approved by stakeholders.requirements is approved by stakeholders.Related PatternsRelated Patterns: customer-communications; iterative design, …: customer-communications; iterative design, …Known Uses/ExamplesKnown Uses/Examples: Prototyping is recommended when requirements : Prototyping is recommended when requirements
are uncertain.are uncertain.
9
The Primary Goal of Any Software The Primary Goal of Any Software Process: Process: High QualityHigh Quality
Remember:Remember:
High quality = project timelinessHigh quality = project timeliness
Why?Why?
Less rework!Less rework!
10
Two Schools of Process Two Schools of Process ModelsModels
Prescriptive process models Prescriptive process models advocate an orderly approach to advocate an orderly approach to
software engineeringsoftware engineering Agile developmentAgile development
Encourages early incremental delivery Encourages early incremental delivery of softwareof software
Stresses continuous communication Stresses continuous communication between developers and customersbetween developers and customers
11
Prescriptive Process Prescriptive Process ModelsModels
Define a distinct set of activities, actions, tasks, Define a distinct set of activities, actions, tasks, milestones, and work products.milestones, and work products.
Software engineers and managers adapt a Software engineers and managers adapt a prescriptive process model to their needprescriptive process model to their need
Guide a software team through a set of Guide a software team through a set of framework activities that organized into a linear, framework activities that organized into a linear, incremental, or evolutionary process flow incremental, or evolutionary process flow
The work products are the programs, documents, The work products are the programs, documents, and data that are produced as a consequence of and data that are produced as a consequence of the activities.the activities.
12
The Waterfall The Waterfall ModelModel
Communication Planning
ModelingConstruction
Deployment analysis design code
test
project initiation requirement gathering estimating
scheduling tracking
delivery support feedback
13
The Waterfall ModelThe Waterfall Model
It suggests a systematic, sequential approach to It suggests a systematic, sequential approach to software development.software development.
The oldest paradigm for software engineeringThe oldest paradigm for software engineering Suitable for systems whose requirements are well-Suitable for systems whose requirements are well-
defined and reasonably stable.defined and reasonably stable. Drawbacks:Drawbacks:
Real projects rarely follow the sequential flow.Real projects rarely follow the sequential flow. It is often hard for the customer to state all requirements explicitly.It is often hard for the customer to state all requirements explicitly. A working product will not be available until late in the project A working product will not be available until late in the project
time-span.time-span. Requirement errors may not be found until they are very costly to Requirement errors may not be found until they are very costly to
fix.fix.
14
The Incremental The Incremental ModelModel
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
15
The Incremental The Incremental ModelModel
The waterfall model applied in an iterative fashion.The waterfall model applied in an iterative fashion. Each linear sequence produces deliverable Each linear sequence produces deliverable
increments of the software.increments of the software. Normally core product is first delivered and Normally core product is first delivered and
supplementary features are incrementally added.supplementary features are incrementally added. Useful when staffing is unavailable for a complete Useful when staffing is unavailable for a complete
implementation by the project deadline.implementation by the project deadline. Increments may be planned to manage technical Increments may be planned to manage technical
risksrisks
16
Rapid Application Rapid Application DevelopmentDevelopment
Communication
Planning
Modelingbusiness modeling data modeling process modeling
Constructioncomponent reuse automatic code generation testing
Deployment
60 - 90 days
Team # 1
Modelingbusiness modeling
data modeling process modeling
Constructioncomponent reuse automatic code
generation test ing
Modelingbusiness modeling data modeling process modeling
Const ruct ioncomponent reuse automatic code generation testing
Team # 2
Team # n
integration delivery feedback
17
The RAD ModelThe RAD Model The incremental model with a short development cycle.The incremental model with a short development cycle. Multiple RAD teams develop different components of the Multiple RAD teams develop different components of the
system in parallel.system in parallel. Short system development cycle is achieved by using a Short system development cycle is achieved by using a
component-based construction approach.component-based construction approach. Suitable for systems that can be modularized in a way that Suitable for systems that can be modularized in a way that
enables each major function to be completed in a short period enables each major function to be completed in a short period of time.of time.
Drawbacks:Drawbacks: For large systems, it requires sufficient people to form the RAD For large systems, it requires sufficient people to form the RAD
teamsteams If developers and customers are not committed to the rapid-fire If developers and customers are not committed to the rapid-fire
activities, the project would failactivities, the project would fail If the system cannot modularized properly, it can be problematic.If the system cannot modularized properly, it can be problematic. It may be difficult to achieve high performance.It may be difficult to achieve high performance. It may not be appropriate if technical risks are high.It may not be appropriate if technical risks are high.
18
Evolutionary Models: Evolutionary Models: PrototypingPrototyping
Communication
Quick plan
Construction of prototype
Modeling Quick design
Delivery & Feedback
Deployment
communication
Quickplan
ModelingQuick design
Constructionof prototype
Deploymentdelivery &feedback
19
Evolutionary Models: Evolutionary Models: PrototypingPrototyping
Assists the software developer and the customer to better Assists the software developer and the customer to better understand what is to be built when requirements are fuzzy.understand what is to be built when requirements are fuzzy."I know this is what I asked for, but it isn't really what I wanted.""I know this is what I asked for, but it isn't really what I wanted."
A quick throwaway prototype for users to experiment and A quick throwaway prototype for users to experiment and the developer to understand and refine requirements based the developer to understand and refine requirements based on users’ feedback.on users’ feedback...
The customer may falsely perceive the prototype as a The customer may falsely perceive the prototype as a working system, unwilling to continue for a complete working system, unwilling to continue for a complete system.system.
Assumptions and design architecture of the prototype may Assumptions and design architecture of the prototype may influence implicitly the architecture of the real system.influence implicitly the architecture of the real system.
Rarely employed for complete development cycle.Rarely employed for complete development cycle.
20
Evolutionary Models: The Evolutionary Models: The SpiralSpiral
communication
planning
modeling
constructiondeployment delivery feedback
start
analysis design
code test
estimation scheduling risk analysis
21
Evolutionary Models: The Evolutionary Models: The SpiralSpiral
Risk-drivenRisk-driven process model. process model. A A cyclic approachcyclic approach for incrementally growing a for incrementally growing a
system’s degree of definition and implementation.system’s degree of definition and implementation. A set of A set of anchor point milestonesanchor point milestones for ensuring for ensuring
stakeholder commitment for feasible and mutually stakeholder commitment for feasible and mutually satisfactory solutions.satisfactory solutions.
Prototyping can be employed as a risk reduction Prototyping can be employed as a risk reduction mechanism at any stagemechanism at any stage
A good approach for large-scale systems.A good approach for large-scale systems.
22
Still Other Process Still Other Process ModelsModels
Component based developmentComponent based development—systems are built by —systems are built by integrating Commercial off-the-shelf (COTS) software integrating Commercial off-the-shelf (COTS) software components. Following the following steps:components. Following the following steps:1.1. Research and evaluate component-based productsResearch and evaluate component-based products
2.2. Resolve component integration issuesResolve component integration issues
3.3. A software architecture is designed to accommodate the A software architecture is designed to accommodate the componentscomponents
4.4. Components are integrated into the architectureComponents are integrated into the architecture
5.5. Comprehensive testing is conducted.Comprehensive testing is conducted. Formal methodsFormal methods—emphasizes the mathematical —emphasizes the mathematical
specification of requirementsspecification of requirements
23
Still Other Process Still Other Process ModelsModels
Aspect-oriented software development (AOSD)Aspect-oriented software development (AOSD) Certain concerns span the whole system architectureCertain concerns span the whole system architecture
High-level properties of the system: security, fault toleranceHigh-level properties of the system: security, fault tolerance Application of business rulesApplication of business rules Systemic: task synchronization or memory managementSystemic: task synchronization or memory management
AOSD is a process and methodological approach for AOSD is a process and methodological approach for defining, specifying, designing, and constructing aspects.defining, specifying, designing, and constructing aspects.
Unified ProcessUnified Process—a “use-case driven, architecture-—a “use-case driven, architecture-centric, iterative and incremental” software centric, iterative and incremental” software process closely aligned with the Unified Modeling process closely aligned with the Unified Modeling Language (UML) – Details coming soonLanguage (UML) – Details coming soon
24
inceptioninception
The Unified Process (UP)The Unified Process (UP)
software increment
Release
Inception
Elaboration
construction
transition
production
inception
elaboration
25
UP PhasesUP Phases
Inception Elaboration Construction Transition Production
UP Phases
Workflows
Requirements
Analysis
Design
Implementation
Test
Iterations #1 #2 #n-1 #n
Support
26
UP Work ProductsUP 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
27
The Manifesto for The Manifesto for Agile Software Agile Software DevelopmentDevelopment
““We are uncovering better ways of We are uncovering better ways of developing software by doing it and helping developing software by doing it and helping others do it. Through this work we have others do it. Through this work we have come to value: come to value:
•Individuals and interactionsIndividuals and interactions over over processes and tools processes and tools •Working softwareWorking software over comprehensive over comprehensive documentation documentation •Customer collaborationCustomer collaboration over contract over contract negotiation negotiation •Responding to changeResponding to change over following a over following a planplan
That is, while there is value in the items on That is, while there is value in the items on the right, we value the items on the left the right, we value the items on the left more.”more.”
Kent Beck et alKent Beck et al
28
What is “Agility”?What is “Agility”?
Effective (rapid and adaptive) response to Effective (rapid and adaptive) response to changechange
Effective communication among all Effective communication among all stakeholdersstakeholders
Drawing the customer onto the teamDrawing the customer onto the team Organizing a team so that it is in control of Organizing a team so that it is in control of
the work performedthe work performed
Yielding …Yielding … Rapid, incremental delivery of softwareRapid, incremental delivery of software
29
An Agile ProcessAn Agile Process
Is driven by customer descriptions of what Is driven by customer descriptions of what is required (scenarios)is required (scenarios)
Recognizes that plans are short-livedRecognizes that plans are short-lived Develops software iteratively with a heavy Develops software iteratively with a heavy
emphasis on construction activitiesemphasis on construction activities Delivers multiple ‘software increments’Delivers multiple ‘software increments’ Adapts as changes occurAdapts as changes occur
30
Extreme Programming (XP)Extreme Programming (XP)
The most widely used agile process, originally The most widely used agile process, originally proposed by Kent Beckproposed by Kent Beck
XP PlanningXP Planning Begins with the creation of “Begins with the creation of “user storiesuser stories”” Agile team assesses each story and assigns a Agile team assesses each story and assigns a costcost Stories are grouped to for a Stories are grouped to for a deliverable incrementdeliverable increment A A commitmentcommitment is made on delivery date is made on delivery date After the first increment “After the first increment “project velocityproject velocity” is used to ” is used to
help define subsequent delivery dates for other help define subsequent delivery dates for other incrementsincrements
31
Extreme Programming (XP)Extreme Programming (XP)
XP DesignXP Design Follows the Follows the KIS principle (nothing less, nothing more.)KIS principle (nothing less, nothing more.) Encourage the use of Encourage the use of CRC cardsCRC cards for classes relevant to the current for classes relevant to the current
increment.increment. For difficult design problems, suggests the creation of “For difficult design problems, suggests the creation of “spike spike
solutionssolutions”—a design prototype”—a design prototype Encourages “Encourages “refactoringrefactoring”—an iterative refinement of the internal ”—an iterative refinement of the internal
program designprogram design XP CodingXP Coding
Recommends the Recommends the construction of a unit testconstruction of a unit test for the stories for the stories beforebefore coding coding commencescommences
Encourages “Encourages “pair programmingpair programming”” XP TestingXP Testing
All All unit tests are executed dailyunit tests are executed daily ““Acceptance tests”Acceptance tests” are defined by the customer and executed to assess are defined by the customer and executed to assess
customer visible functionalitycustomer visible functionality
32
Extreme Programming (XP)Extreme Programming (XP)
unit test continuous integration
acceptance testing
pair programming
Release
user stories values acceptance test criteria iteration plan
simple design CRC cards
spike solutions prototypes
refactoring
software incrementproject velocity computed
33
Adaptive Software Adaptive Software DevelopmentDevelopment
Originally proposed for complex systems Originally proposed for complex systems by Jim Highsmithby Jim Highsmith
ASD — distinguishing featuresASD — distinguishing features Mission-drivenMission-driven planning planning Component-based focusComponent-based focus Uses “Uses “time-boxingtime-boxing” (See Chapter 24)” (See Chapter 24) Explicit consideration of Explicit consideration of risksrisks Emphasizes Emphasizes collaborationcollaboration for requirements for requirements
gatheringgathering Emphasizes “Emphasizes “learninglearning” throughout the process” throughout the process
34
Adaptive Software Adaptive Software DevelopmentDevelopment
SpeculationSpeculation Adaptive cycle planning uses initiation information Adaptive cycle planning uses initiation information
to define the set of release cycles (increments)to define the set of release cycles (increments) CollaborationCollaboration
Team members multiply their talent and creative Team members multiply their talent and creative output with mutual trust. (1) criticize without output with mutual trust. (1) criticize without animosity (2) assist without resentment (3) work animosity (2) assist without resentment (3) work as hard/harder as othersas hard/harder as others
LearningLearning As development progresses members learn toward As development progresses members learn toward
the complete cycle through the complete cycle through focus groupsfocus groups, , formal formal technical reviewtechnical review, and , and postmortemspostmortems..
35
Adaptive Software Adaptive Software DevelopmentDevelopment
adaptive cycle planning uses mission statement project constraints basic requirements time-boxed release plan
Requirements gathering J AD mini-specs
components implemented/ tested focus groups for feedback formal technical reviews postmortems
software incrementadjustments for subsequent cycles
Release
36
Dynamic Systems Development Dynamic Systems Development MethodMethod
Promoted by the DSDM Consortium (Promoted by the DSDM Consortium (www.dsdm.orgwww.dsdm.org)) DSDM—distinguishing featuresDSDM—distinguishing features
Similar in most respects to XP and/or ASDSimilar in most respects to XP and/or ASD Nine guiding principlesNine guiding principles
Active user involvement is imperative. Active user involvement is imperative. DSDM teams must be empowered to make decisions.DSDM teams must be empowered to make decisions. The focus is on frequent delivery of products. The focus is on frequent delivery of products. Fitness for business purpose is the essential criterion for acceptance of Fitness for business purpose is the essential criterion for acceptance of
deliverables.deliverables. Iterative and incremental development is necessary to converge on an accurate Iterative and incremental development is necessary to converge on an accurate
business solution.business solution. All changes during development are reversible.All changes during development are reversible. Requirements are baselined at a high levelRequirements are baselined at a high level Testing is integrated throughout the life-cycle.Testing is integrated throughout the life-cycle.
37
ScrumScrum
Originally proposed by Schwaber and BeedleOriginally proposed by Schwaber and Beedle Scrum—distinguishing featuresScrum—distinguishing features
Development work is partitioned into “Development work is partitioned into “packetspackets”” Testing and documentation are on-goingTesting and documentation are on-going as the product as the product
is constructedis constructed Work occurs in “Work occurs in “sprintssprints” and is derived from a ” and is derived from a
““backlogbacklog” of existing requirements” of existing requirements Meetings are very shortMeetings are very short and sometimes conducted and sometimes conducted
without chairswithout chairs ““demosdemos” are delivered to the customer with the time-box ” are delivered to the customer with the time-box
allocatedallocated
38
CrystalCrystal
Proposed by Cockburn and HighsmithProposed by Cockburn and Highsmith Crystal—distinguishing featuresCrystal—distinguishing features
Actually a Actually a family of process modelsfamily of process models that allow that allow ““maneuverabilitymaneuverability” based on problem characteristics” based on problem characteristics
Face-to-face communicationFace-to-face communication is emphasized is emphasized Suggests the use of “Suggests the use of “reflection workshopsreflection workshops” to ” to
review the work habits of the teamreview the work habits of the team
39
Feature Driven DevelopmentFeature Driven Development
Originally proposed by Peter Coad et alOriginally proposed by Peter Coad et al FDD—distinguishing featuresFDD—distinguishing features
Emphasis is on defining Emphasis is on defining “features”“features” aa featurefeature “is a client-valued function that can be “is a client-valued function that can be
implemented in two weeks or less.”implemented in two weeks or less.” Uses a Uses a feature templatefeature template
<action> the <result> <by | for | of | to> a(n) <object><action> the <result> <by | for | of | to> a(n) <object>Add the product to a shopping cartAdd the product to a shopping cartDisplay the technical spec of a productDisplay the technical spec of a productStore the shipping info for a customerStore the shipping info for a customer
A A features listfeatures list is created and “ is created and “plan by featureplan by feature” is ” is conductedconducted
Design and construction merge in FDDDesign and construction merge in FDD