Galbraith, David Fairley --- "Just enough religion to make us hate: a ...
Chart 2-1 Copyright © 2004 by R. Fairley CSE 516 Summer, 2004 CSE 516 (formerly known as CSE 500)...
-
Upload
samuel-mccormick -
Category
Documents
-
view
214 -
download
1
Transcript of Chart 2-1 Copyright © 2004 by R. Fairley CSE 516 Summer, 2004 CSE 516 (formerly known as CSE 500)...
chart 2-1Copyright © 2004
by R. FairleyCSE 516Summer, 2004
CSE 516(formerly known as CSE 500)
Introduction to Software Engineering
SESSION 2: People, Processes, and Technology
developed byRichard E. Fairley, Ph.D.
Professor and Director of Software EngineeringOregon Graduate Institute
Modified and presented bySanjeev Qazi ([email protected])
chart 2-2Copyright © 2004
by R. FairleyCSE 516Summer, 2004
SESSION 2 OVERVIEW
• Some People Issues
• Some Technology Factors
• Some Process Models
• A Homework Assignment
chart 2-3Copyright © 2004
by R. FairleyCSE 516Summer, 2004
SUCCESS FACTORS FOR SOFTWARE ENGINEERING
• Three key factors in software engineering
– people: numbers and skills– process: the way of working– technology: platform and domain
• Good processes allow people to apply technology
– efficiently: without wasting time or effort, and – effectively: to achieve a desired result
chart 2-4Copyright © 2004
by R. FairleyCSE 516Summer, 2004
PEOPLE ISSUES IN SOFTWARE ENGINEERING
• Software is produced by individuals and teams of individuals working in a closely coordinated manner
– the work is “intellect-intensive”
• Software is always part of a larger system
– software engineers must work with other people:
• other team members
• other software groups
• hardware groups
• marketing groups
• customers and users
• contract administrators
• human resource people
chart 2-5Copyright © 2004
by R. FairleyCSE 516Summer, 2004
A “People Issues” Text
• The textbook:
Peopleware, 2nd. Ed. by DeMarco and Lister, published by Dorset House, ISBN 0-932633-43-9
provides a good discussion of people issues in software engineering
chart 2-6Copyright © 2004
by R. FairleyCSE 516Summer, 2004
PEOPLE ISSUES - II
• Software is made by individuals and teams of individuals
• Individual success requires ability, skill, and motivation
• A team is a group of individuals working in a cooperative manner toward common shared goals
• Team success requires that:
– team members have a shared vision
– team members have shared work products
– team members be willing to help one another
a group of people working togetheris not necessarily a team
chart 2-7Copyright © 2004
by R. FairleyCSE 516Summer, 2004
PEOPLE ISSUES - III
• Productivity of individuals in software development varies by factors of 10:1 and more
• Productivity of groups varies by factors of 10:1 and more (not all groups are teams)
• Individual productivity is a matter of:– skill and experience: ability to do the job– motivation: willingness to do the job
• Team productivity is a matter of individual productivity plus the synergy of group dynamics.
chart 2-8Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Can’t vs Won’t
• Can’t occurs when:– a person is willing but unable
• Won’t occurs when:– a person is able but unwilling
• Can’t and won’t occur when:– a person is unable and unwilling
• Can and will occur when:– a person is able and willing
success in software engineering requires individuals and teams who are willing and able
chart 2-9Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Factors That Contribute to Efficient and Effective Software Engineering Teams
• Appropriate number of people• Correct skill mixture• Good tools• Adequate training• Respect for one another• Respect for leaders and managers• Shared ownership of the results• Good communication skills• Good communication channels• Willingness to be team members• Fair treatment of each person• Good working environment• Having some fun together
chart 2-10Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Team Building Techniques
• Allow people to work together for extended periods of time
• Conduct off-site planning and review meetings– with some opportunities for socializing
• Allow team participation in off-site training courses
• Provide corporate-sponsored recreational activities
• Find isolated tasks for “lone wolf” contributors
• Reassign disruptive and unsocial people– remember the 80/20 rule (the 95/5 rule?):
don’t spend 95% of your time with the 5% of people who can’t and/or won’t and who will never change
chart 2-11Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Communication Channels
• The number of communication paths among n workers is n(n-1)/2:– 4 workers have 6 communication channels – 5 workers have 10 communication channels– 10 workers have 45 communication channels– 20 workers have 190 communication channels
• Most people can effectively maintain a fully communicative working relationship with at most 4 or 5 other people– 7 2 is the generally accepted limit of short-term,
working memory
• A hierarchical tree structure provides the minimum number of links needed to construct a connected graph
chart 2-12Copyright © 2004
by R. FairleyCSE 516Summer, 2004
An Organizational Model for Software Projects
Project Manager
TeamLeader #1
Team Leader#2
TeamLeader #3
V&V CM
Member Member Member Member
Software Architect
. . .
Customer
XX
hierarchical structures can grow or shrink as necessary
chart 2-13Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Team Leader’s Role
The team leader:
• Oversees personal and team processes
• Oversees personal and team product quality
• Mentors and coaches team members
• Maintains team morale, energy, and drive
• Keeps management informed
• Interfaces with other teams and groups
• Resolves problems and issues within his or her control
• Elevates problems and issues beyond his or her control
The team leader is responsible for the quantity and quality of team output
chart 2-14Copyright © 2004
by R. FairleyCSE 516Summer, 2004
A QUESTION
Which is more productive?
1. A team consisting of 3 to 6 software developers, in which one person spends part of his time coordinating the work of the other team members?
Or
2. A “team” consisting of 3 to 6 software developers, where each developer “does their own thing?”
chart 2-15Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Project Manager
• The project manager is responsible for delivering a satisfactory product on time and within budget by:
– planning and estimating
– measuring and controlling
– leading and directing
– communicating and coordinating
– This is where the “buck” usually stops.
chart 2-16Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Software Architect
• The software architect
– develops the system architecture and – maintains the vision and integrity of the system by:
• developing technical options, • presenting them to the decision makers, and • overseeing the technical activities, • ensuring that the product/project satisfies the project
constraints
chart 2-17Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Roles for The Software Architect
• The software architect is:
– member of system design team
– leader of software analysis and design team
– leader of implementation team leads
– keeper of the product vision
– spokesperson for the software team
– technical coordinator with other design teams, and possibly other organizations
– responsible for completeness, consistency, and correctness of the software product
A Chief Architect may be responsible for a product family or product line within an organization
chart 2-18Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Roles vs Role Players
• On a small project (about 5 or fewer people), the project manager, software architect, and team leader roles may be played by one individual
– which means he/she is “wearing different hats”
• On a large project (20 or more people), the project manager and software architect may be assisted by others
– and there would typically be multiple team leaders
chart 2-19Copyright © 2004
by R. FairleyCSE 516Summer, 2004
A Three-Way Contractual Model
• Customer agrees to not request changes to the requirements without re-negotiating with the project manager and software architect
• Project manager agrees to provide the resources needed to implement the product requirements and to measure and report schedule, budget, progress, quality, and risk factors
• Software architect agrees to develop (or modify) a product that satisfies the product requirements using the resources provided by the project manager
chart 2-20Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Some Examples of Re-Negotiating the Contract
• Marketing (customer) requests changes in the light of a competitor’s new product– must renegotiate resources, schedule, and product
features with the project manager and software architect
• Software architect hits a technical snag and cannot deliver the product on schedule– must renegotiate with marketing and project manager
• Project manager cannot provide promised resources because of a hiring freeze– must renegotiate with marketing and software architect
chart 2-21Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Theory of Triple Constraint
• What “Triple Constraint” says is that for any project, there are three variables that need to be balanced. These are:
– Time (or schedule): • How much time is available for your group to deliver on the
work assigned?
– Cost/Budget (or resources):• What is the cost of the project?
– This can include manpower cost (usually the highest), software licenses, hardware, etc.
– Quality (or features):• What are the quality requirements (based on some metric)
and/or feature requirements for the product?
chart 2-22Copyright © 2004
by R. FairleyCSE 516Summer, 2004
SESSION 2 OVERVIEW
• Some People Issues=> Some Technology Factors• Some Process Models• A Homework Assignment
chart 2-23Copyright © 2004
by R. FairleyCSE 516Summer, 2004
TECHNOLOGY
• Software engineering tools are hardware and software that help us build other software
• Technology provides the tools to do the job– work stations– target processors– host and target operating systems– compilers, linkers, loaders– local area networks– requirements engineering tools– design tools– debugging and testing tools– programming environments – configuration management tools– project management tools– e-mail, word processors, spreadsheets
software engineers are tool builders
chart 2-24Copyright © 2004
by R. FairleyCSE 516Summer, 2004
PEOPLE, PROCESS, AND TECHNOLOGY
• Process is the way in which people, working in teams, apply technology to build high quality products - efficiently and effectively
People Process Technology
Capability
Product
chart 2-25Copyright © 2004
by R. FairleyCSE 516Summer, 2004
What Is a Software Process?
• A process – is a way of doing something– includes work activities– includes procedures for conducting the work activities
• The work activities transform input work products into output work products
• The procedures are supported by methods and tools; for example:
DesignProcess
Requirements Design DocumentsTest Plans
methodsand tools
chart 2-26Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Nature of Software Processes
• A process is typically part of a larger process– the design process is part of the development process
• A process may have sub-processes– the design process includes a design review process
• A process has entry and exit criteria– we must have some requirements before we design; we must have a
design review before we complete the design
• A process includes procedures for conducting the work activities; for example:
RepairProcess
Problem Report Repaired Code
Updated Work Products
methodsand tools
chart 2-27Copyright © 2004
by R. FairleyCSE 516Summer, 2004
An Example-- The Defect Repair Process --
Fixing a customer-reported defect involves the following procedures:
1. reproducing the failure (absolutely need this)2. finding the defect3. fixing the mistake4. regression testing5. documenting the fix6. updating other work products7. checking-in the modified code8. releasing the product with the fix.9. closing the problem report.
QA will typically verify that this bug has been fixed. Customer certainly will :=)
note: fixing a user-reported defect also involves a Configuration Management process
chart 2-28Copyright © 2004
by R. FairleyCSE 516Summer, 2004
THE NATURE OF ENGINEERING PROCESSES
• An engineering process is a way of accomplishing some engineering activity
• Key aspects of an engineering process include:
– Process Definition: what is the process?
– Process Enactment: how is it done?
– Process Measurement: how well is it done?
– Process Assurance: is it done correctly?
– Process Improvement: how can it be done better?
chart 2-29Copyright © 2004
by R. FairleyCSE 516Summer, 2004
A Process Model for Developing Software-Intensive Systems
DefineOperationalRequirements
SpecifySystemRequirements
DevelopSystemArchitecture
ObtainSoftwareComponents
IntegrateSoftwareComponents
systemvalidation
systemvalidation
User NeedsAcquirer Expectations
User NeedsAcquirer Expectations
softwarevalidation
softwarevalidation
IntegrateTotalSystem
Allocate theSoftwareRequirements
DevelopSoftwareDesign
Allocate theHardwareRequirements
Allocate thePeopleRequirements
add othercomponents
chart 2-30Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Obtaining the Software Components
• Software components can be obtained by:
– designing and building in-house
– contracting with a third party supplier
– buying components from a vendor
– reusing components from another system• With or without modification
– using components provided by another group• With or without modification
Each of these approaches requires a different process;several approaches may be used on one project
chart 2-31Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Support Functions for Software Development
• Supporting functions for software development and modification include:
– configuration management• change control; version control
– verification and validation• checking completeness, consistency, and correctness of work products
– quality assurance• assuring the quality of both process and product
– documentation support• developing user and customer materials
– training• developer training; user training
Each supporting function must be accomplished using a well-defined process
chart 2-32Copyright © 2004
by R. FairleyCSE 516Summer, 2004
customer
management
Planning and Replanning
ActivityDefinition
WorkAssign-ments
SoftwareDevelopment
Quality Assurance
Independent Validation
Measuring
Controlling
DataRetention
Estimating
ReportingStatus ReportsProject Reports
Requirementsand Constraints
Directives andConstraints
Change Requests and Problem Reports
ConfigurationManagement
product
. . . . . . . . . . . . .. . . .
Process Models for Software Development
chart 2-33Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Some FOUNDATION ELEMENTS of a Software Development Process
• coding style guidelines
• code documentation guidelines
• debugging tools
• peer reviews
• testing strategies, procedures, and tools
• periodic backups
• a version control system (SCM)
• a defect tracking system
• a design documentation tool
• a project planning and tracking system
chart 2-34Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Some Process Models for Software Development
Model Emphasis
Hacking Writing Programs
Waterfall Project Phases
Incremental Staged Development
Evolutionary Exploratory Development
Spiral Risk Management
Cleanroom Rigorous Process
Component-based Savings and Quality
Frameworks Tailoring and Adaptation
chart 2-35Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Hacking
• To hack means to start writing the programs without any system engineering, requirements analysis, software design, or test planning
• Hacking focuses attention on implementation details before
– understanding the problem (analysis)– developing a solution (design)– determining success criteria (objectives)
• A hacker is one who hacks
development of a complex system requiresmultiple descriptions at different levels of abstraction
chart 2-36Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Descriptions: The Work Products of Software Engineering
• The work products of software engineering include:
– operational requirements: user needs– technical specifications: developer’s guidance– design documents: structure and interfaces– test plans: product validation– source code: implementation– project plans: project roadmaps– status reports: visibility– reference manual: product dictionary– on-line help: user guidance– installation instructions: operators’ guidance– release notes: know issues; hints– maintenance guide: maintainers’ guidance
chart 2-37Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Waterfall ModelUser Needs
System Requirements
Software Requirements
Software Design
Implementation
Software Test
System Test
Verification:are we buildingthe system correctly?
Acceptance Test
Validation:did we buildthe correct system?
chart 2-38Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Advantages of the Waterfall Approach
• Compared to Hacking, the Waterfall Model requires us to:
– develop requirements before design
– design before writing programs
– test programs after integrating them
– have milestone reviews
– establish and control work product baselines
chart 2-39Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Milestone Reviews in the Waterfall Model
User Needs
System Requirements
Software Requirements
Software Design
Implementation
Software Test
System Test
Verification:are we buildingthe system correctly?
Acceptance Test
Validation:did we buildthe correct system?
SRR
SSR
PDRCDR
TRR
STR
SAR
CAR
SRR: System Requirements ReviewSSR: Software Specification ReviewPDR: Preliminary Design ReviewCDR: Critical Design ReviewTRR: Test Readiness ReviewSTR: Software Test ReviewSAR: System Acceptance ReviewCAR: Customer Acceptance Review
chart 2-40Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Baselines and Version Control
• A baseline is a work product that has been accepted by the involved parties and placed under version control– acceptance requires application of some acceptance
criteria
• A baseline cannot be changed without the agreement of the involved parties
• A baseline is changed because:1. the requirements for the work product changed, or2. a defect was found in the work product
baselines and version control are fundamentaltechniques of software engineering; they
are elements of Configuration Management
chart 2-41Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Waterfall Approach
• The Waterfall Model requires that we (attempt to):
– specify the requirements completely, consistently, correctly, and unambiguously on the first attempt
– design the system completely and correctly on the first attempt
– write all of the program interfaces and internal details correctly on the first attempt
– integrate the components in one large step
– do system testing at the end
the waterfall model is a one-pass process
chart 2-42Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Some Realities of Software Development
1. Requirements always change because of:
– changing customer desires and user needs– initial requirements analysis inadequate– understandings and insights gained through experience – changing technology– changing competitive situation– personnel turnover: engineering, management, marketing,
customer
2. The design is never right the first time– design is a creative, problem solving process
3. Frequent demonstrations of progress and early warning of problems are desirable
An iterative development model is best
chart 2-43Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Iterative Development
• Iteration is the process by which the desired result is approached through repeated cycles
• In software engineering, an iterative approach allows revision of and addition to the work products
• Different types of iterative models support revision of:– requirements– design– code
iteration should be planned;not done as an afterthought
chart 2-44Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Iterative Development - II
• The goals of iterative development are:
– frequent demonstrations of progress– early warning of problems– ability to incorporate changes
• Three types of iterative development models
1. incremental2. evolutionary3. spiral models
chart 2-45Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Incremental Implementation Process
IncrementalValidation
RequirementsSpecifications
DesignPartitioning
ArchitecturalDesign
IncrementalBuilds*
IncrementalVerification
OperationalRequirements
*build includes detailed design,implementation, review, and test
chart 2-46Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Incremental Implementation Approach
• Design is partitioned into a series of prioritized builds
– each build adds capabilities to the existing base in priority order
• builds produce demonstrable versions
– most critical parts are built first• and tested/demonstrated most often
– All incremental builds are not necessarily customer builds.
chart 2-47Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Incremental Building and Validating
AddFeature Set N
• • •• • • • • •
AddFeature Set 2
BuildFeature Set 1
Time
ValidateFeature Set FS1
ValidateFeature Sets
1 + 2
• • •• • • • • •Goal:
Rework < 20% oftotal effort
Deliver Version 1.0
Validateall Features
DesignPartitioning
Demo FS1
Demo 1+2
(Rqmts & Design)
...
chart 2-48Copyright © 2004
by R. FairleyCSE 516Summer, 2004
An Incremental ExampleBuilding A Compiler
• Version 0.1: input reader
• Version 0.2: plus lexical analyzer
• Version 0.3: plus symbol table
• Version 0.4: plus code generator
• Version 0.5: plus linker table
• Version 0.6: plus writer
• Version 0.7: plus error messages
• Version 0.8: plus optimizer
Version 0.8 is customer Version 1.0
chart 2-49Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Milestone Chart for a Six Month Incremental Project
V0.1V0.2
V0.3V0.4
V0.5V0.6
V0.7V0.8
2 Months
Design Implementation*
4 Months
Demo1Demo2
Demo3Demo4
Demo5Demo6
Demo7
Demo &Deliver V1.0
Note: bi-weekly demonstrationmilestones
a project milestone is a point in timewhere progress is assessed
Design MilestoneRequirements Milestone
Rqmts
chart 2-50Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Design Partitioning
• Partitioning criteria for the incremental versions must be established;
– for example:• foundation elements
– elements needed to support other elements• prioritized user needs
– must-have features first– nice-to-have features next
• a safety-critical system– safety features first– other features next
• a user-intensive system– user interface features first– other features next
• an operating system– kernel operations first– utility operations next
chart 2-51Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Guidelines for Incremental Development
• Build an “official” demonstration version every week/month– developers may do more frequent builds
• Build product versions according to priority of requirements– build and test the most critical parts first
• Do independent review and testing of each version
• Incorporate requirements changes into later versions
• Redesign if changes to previous builds exceed 20% of effort when building two successive product versions
chart 2-52Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Advantages of Incremental Development
• Allows early and continuing demonstrations of progress
• Components built first are tested most
• Can incorporate some changes to requirements in later builds
• Can make trade-offs of features and schedule– during development– at delivery time
• Can provide incremental deliveries to customers– during development– at delivery time
chart 2-53Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Incremental Delivery
• Deliver of early versions provides early feedback from users
• Allows product delivery on schedule– with most important features working– with systematic planning for later versions
• At delivery time, it is better to be
– 100% complete with 80% of the most important product features
than to be
– 80% complete with 100% of features (and nothing to deliver)
chart 2-54Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Evolutionary Model
• Used when a first version of the requirements cannot be (mostly) specified in advance:
Cycle 1 Cycle 2 Cycle 3 Cycle n. . .
Analyze Design Implement Test Evaluate=> => => =>
• Details of each cycle:
Each Cycle is<= 1 Month Duration
chart 2-55Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Evolutionary Development Guidelines
• Used when requirements cannot be mostly specified in advance
• Evolutionary cycles end when– project is cancelled because it is infeasible– project is converted to an incremental approach– product is delivered
• Using the evolutionary approach indicates a high-risk project
chart 2-56Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Spiral Approach
• The Spiral Process is a nested set of iterative development models– earlier activities are revisited, revised, and refined on each pass of
the spiral
• Each cycle of a spiral model involves four steps:
Step 1 - determine objectives, alternatives, and constraintsStep 2 - identify risks for each alternative, choose one of the alternativesStep 3 - implement the chosen alternativeStep 4 - evaluate results and plan for the next cycle of the spiral
• The cycles continue until the desired objectives are achieved
chart 2-57Copyright © 2004
by R. FairleyCSE 516Summer, 2004
time
xx
xxx
x
x
x
An Evolutionary Spiral Model
x
x
xxx
x
x
x
x
x
x
x
x
x
xx
x
x
x
x
x
x
x
xx
x
x
x
x
x
xxx
xxx
x
x
x
xx
x
xx
x
xx
xx
x
ANALYZE:Determineobjectives,alternatives,and constraints
DESIGN:evaluate alternatives,Identify risks of eachalternative &choose one
DEVELOP:Implement and test the chosen alternative
EVALUATE:examine resultsand decide whatto do next
x
x
Each Cycle is One Month or Less
chart 2-58Copyright © 2004
by R. FairleyCSE 516Summer, 2004
time
xx
xxx
x
x
x
An Incremental Build Spiral Model
x
x
xxx
x
x
x
x
x
x
x
x
x
xx
x
x
x
x
x
x
x
xx
x
x
x
x
x
xxx
xxx
x
x
x
xx
x
xx
x
xx
xx
x
DETAILED DESIGN:Select algorithmsand data structures;specify interfacedetails
IMPLEMENTATION:implement, document,review, test the build
VALIDATION:Integrate the buildinto the base systemand test the combination
EVALUATION:examine resultsand decide whatto do next
x
x
Each Cycle is One Week or Less
chart 2-59Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Some Spiral Models for System Development - I
DefineOperationalRequirements
SpecifySystemRequirements
DevelopSystemArchitecture
ObtainSoftwareComponents
Integrate &Test SoftwareComponents
systemvalidation
User NeedsCustomer Expectations
softwarevalidation
Integrate& TestSystem
Allocate SoftwareRequirements Develop
SoftwareDesign
Allocate theHardwareRequirements
Allocate thePeopleRequirements
operationalvalidation
starthere
endhere
IncrementalImplementationSpiral
add othercomponents
chart 2-60Copyright © 2004
by R. FairleyCSE 516Summer, 2004
A Nested Set of Spiral Models
DefineOperationalRequirements
SpecifySystemRequirements
DevelopSystemArchitecture
ObtainSoftwareComponents
Integrate &Test SoftwareComponents
IntegrateTotalSystem
Allocate SoftwareRequirements Develop
SoftwareDesign
Allocate theHardwareRequirements
Allocate thePeopleRequirements
operationalvalidation
starthere
User NeedsCustomer Expectations
endhere
add othercomponents
chart 2-61Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Some Comments
• Moving from an inner level to an outward level of the Spiral Model indicates project instability
• Moving from an outer level to an inward level of the Spiral Model indicates growing project stability
• Incremental and evolutionary development can be thought of as instances of the spiral approach
• How do we proceed when none of the product factors are stable or partitionable?– conduct a feasibility study using prototyping
chart 2-62Copyright © 2004
by R. FairleyCSE 516Summer, 2004
The Role of Prototyping
• Prototyping involves building a “mock-up” of some part of a system
• Prototyping is typically used to– build a mock-up of the user interface, or– write a program to study a technical issue
• Prototyping is a technique, not a process model– prototyping does not eliminate the need for requirements
analysis, design, test planning, integration, system testing, and documentation activities
Prototyping is a technique that must be planned and controlled; it should not be an excuse for hacking
chart 2-63Copyright © 2004
by R. FairleyCSE 516Summer, 2004
A Spiral Model of Prototyping to Elicit User Requirements
DefineOperationalRequirements
SpecifySystemRequirements
DevelopSystemArchitecture
ObtainSoftwareComponents**
IntegrateSoftwareComponents**
systemvalidation
User NeedsCustomer Expectations
Acquirer Conditions
softwarevalidation
REQUIREMENTS ENGINEERING
IntegrateTotalSystem**
AllocateSoftwareRequirements
Develop**SoftwareDesign
** must maintain user and acquirer involvement
AllocateHardwareRequirementsAllocatePeopleRequirements
chart 2-64Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Managing Prototyping Efforts
• Prototyping must not be used as an excuse for uncontrolled hacking– specific (limited) objectives must be established for each
prototyping iteration– time frame of each iteration must be limited to one month or
less– results must be evaluated and decisions made, just as in the
evolutionary approach
• Evolutionary development follows a systematic process within a larger strategy; prototyping is a technique to study a specific problem within a limited context
Prototyping must be planned and controlled it should not be an excuse for hacking
chart 2-65Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Some Distinctions
• When building a prototype, we keep the knowledge we have gained but – we do not use the code in the deliverable version of the system
unless we are willing to do additional work to develop production code
• When using evolutionary development, we keep the knowledge we have gained in each cycle– we may, or may not, use the code we have written in the
deliverable version of the system
• When using incremental development, the goal is to keep the code we write in each build as part of the deliverable system
chart 2-66Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Prototype
Evolutionary
Incremental
Mix and match the processes to fit the problem, as appropriate:1. Prototype to understand the problem
2. Evolutionary to develop solutions
3. Incremental to develop the product
4. Spiral framework to manage iteration
Spiral
A Tailorable Process Framework
development processes must be designed and evolvedin the same way that the product is designed and evolved
chart 2-67Copyright © 2004
by R. FairleyCSE 516Summer, 2004
A Recommended Approach
• Use prototyping to understand technical issues and to specify the User Interface
• Use evolutionary spiral approaches to evolve solutions (as necessary)
• Use an incremental spiral approach whenever possible– including frequent demonstrations and incremental version
testing
• Embed software development in a system-level spiral model
• Embed the system development process in a workflow process model
chart 2-68Copyright © 2004
by R. FairleyCSE 516Summer, 2004
customer
management
Planning and Replanning
ActivityDefinition
WorkAssign-ments
SoftwareDevelopment
Quality Assurance
Independent Validation
Measuring
Controlling
DataRetention
Estimating
ReportingStatus ReportsProject Reports
Requirementsand Constraints
Directives andConstraints
Change Requests and Problem Reports
ConfigurationManagement
product
. . . . . . . . . . . . .. . . .
A Process Model of Project Workflow
chart 2-69Copyright © 2004
by R. FairleyCSE 516Summer, 2004
A Nested Set of Spiral Models
DefineOperationalRequirements
SpecifySystemRequirements
DevelopSystemArchitecture
ObtainSoftwareComponents
Integrate &Test SoftwareComponents
IntegrateTotalSystem
Allocate SoftwareRequirements Develop
SoftwareDesign
Allocate theHardwareRequirements
Allocate thePeopleRequirements
operationalvalidation
starthere
User NeedsCustomer Expectations
endhere
add othercomponents
chart 2-70Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Managing Iterative Development• Iterations must be pre-planned
• Iterations must be of limited duration
• Multiple work activities, and multiple types of work activities may be conducted concurrently
• Iterative, independent validation is required
• An automated version control is essential for establishing and maintaining product baselines– A baseline is a work product that has been evaluated and
accepted by the involved parties– A baseline changed for one of two reasons:
• in response to a requirements change• to fix a defect
the product vision must be maintained
chart 2-71Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Who Keeps the Process Roadmap and the Product Vision?
• Every software project should have a software development team, with project manager, software architect, and team leader roles– the project manager keeps the process roadmap (the
project plan)– the software architect keeps the product vision (the
product architecture)
• Fred Brooks says– the project manager is like the movie producer– the software architect is like the movie director
chart 2-72Copyright © 2004
by R. FairleyCSE 516Summer, 2004
An Organizational Structure for Software Projects
Project Manager
TeamLeader #1
Team Leader#2
TeamLeader #3
V&V CM
Member Member Member Member
Software Architect
. . .
Customer
XX
hierarchical structures can grow or shrink as necessary
chart 2-73Copyright © 2004
by R. FairleyCSE 516Summer, 2004
A Comment
• This session has focused on process models for developing software
• All of the work processes of software engineering should have well-defined processes;
– for example:
• configuration management• quality assurance• verification and validation• and so forth
chart 2-74Copyright © 2004
by R. FairleyCSE 516Summer, 2004
THE IMPORTANCE OF SOFTWARE PROCESS MODELS
• Physical constraints determine the processes to be used to build and modify physical systems
• In software, our process models provide guidelines that are the equivalent of physical constraints in building physical systems
– process models help us coordinate the work activities of different people working on a common, intellectual work product
chart 2-75Copyright © 2004
by R. FairleyCSE 516Summer, 2004
READINGS FOR THIS WEEK
• Sommerville, Chapter 3– The Software Process
• Brooks, Chapters 3 & 4– The Surgical Team– Autocracy, Democracy, and System Design– material in Brooks Ch. 19, starting on pg. 253
chart 2-76Copyright © 2004
by R. FairleyCSE 516Summer, 2004
SESSION 2 Assignments
• Read the Session Three Readings– see the syllabus
• Complete Homework Assignment 2 (next two slides. The same assignment is also on the web)
– it must be turned in at the start of class next session
chart 2-77Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Homework Assignment #2
Develop an incremental process for development of a word processor
1. Describe the features of your word processor, including a list of the software components in the word processor
2. Develop a numbered list of 10 to 15 operational requirements for the word processor
prioritize the requirement in the order of implementation
3. Decide how many incremental builds (5 or more) will be implemented and demonstrated; group the requirements into incremental builds– the most important parts should be built first– some earlier parts may provide the features needed to build
the later parts4. Include a table of milestones for the development project
indicating the number of each build, what new features will be in each build, and the schedule when each build will be implemented and demonstrated
The assignment is due at start of class next session
chart 2-78Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Homework Assignment #2
Use the following format for your answer:
Your NameCSE 516, Assignment #2Date the Assignment is due
1. Brief description of the features of your word processor, including the software components in the word processor
2. Numbered list of 10 to 15 operational requirements for the word processor in priority order for incremental development
3. Partitioning and grouping of the requirements for each incremental version– increment #1: list of requirements to be included in
increment #1– increment #2: list of additional requirements to be included
in increment #2– and so forth
4. Table of schedule milestones for the project
chart 2-79Copyright © 2004
by R. FairleyCSE 516Summer, 2004
An Example1. BRIEF DESCRIPTION OF AN ATM
• An automated teller machine (ATM) allows people to conduct financial transactions at convenient times using conveniently located terminals
• Elements of software for an ATM include:– Hardware Drivers– Communication Package– User Transaction Interface– Off-Line Diagnostics– Off-Line Maintenance
• Incremental development of the User Transaction part will be presented. User Transactions include the following elements:– transaction validation– transaction processing– transaction recording– transaction termination
chart 2-80Copyright © 2004
by R. FairleyCSE 516Summer, 2004
2. NUMBERED LIST OF REQUIREMENTS FOR ATM FINANCIAL TRANSACTIONS
[1] Financial Transactions can only occur when the ATM is in ON-LINE mode[2] a) Financial Transaction shall accommodate Quick Cash Withdrawal, Standard
Withdrawal, Deposit, Loan Payment, Balance Inquiry, and b) Terminate requests from customers
[3] Financial Transaction shall permit cash withdrawal from checking, savings, and credit card accounts
[4] Financial Transaction shall permit deposits to checking, savings, and credit card accounts
[5] Financial Transaction shall permit transfer of funds between checking and savings, savings and checking, checking and loan accounts, and savings and loan accounts
[6] Financial Transaction shall permit account balance inquiries on checking, savings, and loan accounts
[7] Financial Transaction shall prompt (both visual and audio) the customer toa) Enter Personal Identificationb) Enter Transaction Information
and so forth
chart 2-81Copyright © 2004
by R. FairleyCSE 516Summer, 2004
3. PARTITIONING AND GROUPING OF THE ATM REQUIREMENTS
• Increment #1:– build the ONLINE communication software (in several incremental builds)
• Increment #2:– build the User Interface shell (in several incremental builds)
• Increment #3:– build communication between user interface and financial institution (in
several incremental builds)
• Increment #4:– build the Hardware Driver software (in several incremental builds)
• Increment #5:– build the Quick Cash Withdrawal option (in several incremental builds)
• and so forth
chart 2-82Copyright © 2004
by R. FairleyCSE 516Summer, 2004
4. THE MILESTONE CHART AND SCHEDULE
• See lecture charts 2-49 for example of milestone charts– note: you should not copy these charts; make a milestone
chart for your project
• Your schedule should be in the form of a table:– milestone #1:
name work to be completed date (or time from start of project)
– milestone #2: name work to be completed date (or time from
start of project)etc.
chart 2-83Copyright © 2004
by R. FairleyCSE 516Summer, 2004
Session 2 Summary
• Some People Issues• Some Technology Factors• Some Process Models • A Homework Assignment