View
214
Download
0
Embed Size (px)
Citation preview
3David LashCS 556 - Winter
Ch 4. Software Development Lifecycles Types of models Majors phases
Ch 3 Software Project - Survival Guide Using Development Processes
Ch. 4 Survival Skills - Survival Guide Planning & Risk management
Ch. 5 The Successful Project - Survival Guide Staged Delivery & Tracking Milestones
Overview
4David LashCS 556 - Winter
On Time- Chapt 4 -
Software development Lifecycles (the process model used to develop software): Coding is a small part in overall effort:
• Planning: 25-55%• Code and Unit Test: 15-40%• Integration and Test: 35-40%
Code and Fix - Little planning, little discipline, mainly for simple, small, and extremely well defined problems.
Concept Code Fix Maintain
Code And Fix
5David LashCS 556 - Winter
The Software Development Life CycleMany Software Development Life Cycle (SDLC)
model been described and used. (since 1970s) SDLC model includes all project phases from the initial
concept to the final delivery of the software product. Waterfall model one of the oldest SDLC models.
Each phase cascades into next (with overlap) Often requires a “set” of documents to be produced:
requirements, architecture, test, LL design, maintenance, code, (and then repeat for next release).
Need to be able to specify solid requirements up front (because of long time from concept to code)
Can spend lots of time/money before customer gets product A strength though is its structure
6David LashCS 556 - Winter
The ‘Waterfall’ Model
Integration
Concept
Requirements
Design
Implementation
Go Live
MaintenanceTime
Each of these “phases” might require a document to be completed and reviewed
Can be extremely difficult to set a schedule early on and meet schedule deadline.
7David LashCS 556 - Winter
“Rapid Prototyping” ModelOften customer cannot accurately state
requirements up-front. Problem is too complex, hard to imagine solution, not clear
what it should look like
Produce set of prototypes that drive reqmts definition. Once done might throw away prototype and then use
waterfall Problems: Time to prototype, pressure to use prototype,
temptation to use prototype,
PrototypeConcept TestIntegrateRqmnts Design Impl
Rapid Prototypes
8David LashCS 556 - Winter
Evolutionary Software DevelopmentMain Concept: Software evolves and grows
from a basic to a more complex product, uses iterative (repeating) development cycle. Mini-waterfall for each iteration
Advantages/Issue: Minimizes risk of spending lots of resources for something customer not wants Customer gets something useful sooner (but you may have to support something sooner) Initial phases might not be thrown away Not all problems are suitable to model (might not be able to break problem down,
customer might nott be available for early releases.) Architecture needs to be thought out to avoid rework
9David LashCS 556 - Winter
The Spiral Development Model
Each iteration software increases complexity, functionality.
You’ll need an “evolution plan”, up front to negotiate with customer.
10David LashCS 556 - Winter
Software phases … Looked at
Waterfall Rad Spiral
Will look at common phases: Concept Requirements Design Code Integration Maintain
11David LashCS 556 - Winter
Concept PhaseDetermine the system need and basis for:
RFP/Cost-benefit Requirements Planning and preparation estimates
Concept document might Analyze market and user needs Establish the need for project Provide initial estimates
Problems Costs not hard Need to sell management. Need leader/champion Getting staff and budget commitment Political posturing - who will lead project
12David LashCS 556 - Winter
Requirements Phase
Formal definition of what system should be (not how).
Concludes with Requirements Spec review.Potential Problems:
Disagreement over nailing down specs. Conflicting requirements with different customers Changing and shifting requirements
Project planning may occur in parallel.Potential problems: Estimating time and schedules within project plan Staffing and locating development team Obtaining budget
Produces: Requirements Specification and project development plan and test plan.
13David LashCS 556 - Winter
Design PhaseSoftware design spec defines how system will be built. In large projects might have:
High level design - Architecture Low level design - Design (Design decisions might well effect project plan)
The design produces Test specs Integration plan Design Specification
Problems include: Architecture issues/decisions (what is best for future?) New requirement discovery Political realities behind vendor selection
14David LashCS 556 - Winter
Implementation Phase
Coding!!! 40% spec –20% coding
– 40% integration
0
5
10
15
20
25
30
35
40
Percent ofTime
ReqDesign
CodeTest
IntegrateTest
Problems Time pressure Requirements problems Resource shortage Customer/client and management problems
15David LashCS 556 - Winter
Integrate Test PhaseModules combined & overall testing VS requirementsSystem integration can proceed:
Top-Down - central exec code first, lower part stubs Bottom-Up - Overall drivers include lower level modules Inside out - For example DB systems: built DB first, then DB access,
then human interface Integration Testing, Independent testing, Installation testing,
alpha (w/o live data) and beta testing, acceptance testing Problems
Bad integration plan Dealing with complex system (and other people’s code) Third party failures - late delivery, software defects Last minute changes - Project acceptance & On-site integration.
16David LashCS 556 - Winter
Maintenance PhaseMost important part of most, important systems
Systems can be in maintenance for decades
Software Maintenance? - The process of modifying a software system or
component after delivery to correct faults, improve performance, or adapt.
Problems during maintenance Motivating - maintenance is less glamorous Documentation often bad, reading code can be ugly. Making changes to live systems tricky.
Consider a system: developed 7+ years ago. Original development team gone. Second generation development team gone. Architecture is old. Not clear why design tradeoffs were made. System is in production. Code is hard to under understand (maybe even never reviewed.) Your job, maintain and evolve it. Complete rework not an option.
18David LashCS 556 - Winter
Introduction to Extreme Programming
A Lightweight Methodology less rules, modest number of practices, easier to
follow Emphasis on more customer involvement, faster
releases, shared development, more collaborative development
19David LashCS 556 - Winter
Introduction to Extreme Programming
Based on four concepts: Planning -
Requirements -• High level requirements are developed use “user stories” (non-
technical description of functionality use). 3-4 sentences long.• Developers and users create a set of stories to be implemented in
first release. – Emphasis on delivering a useable/testable versions ASAP
Schedule -• User team estimates each user story in terms of ideal programming
weeks• Iterative development - schedule is divided into 12-15 intervals of 1-
3 weeks length• Implement only those items on schedule (no advanced development)
Measure progress by “velocity” - • measure number of stories complete in interval and use that as
benchmark.
20David LashCS 556 - Winter
Introduction to Extreme Programming
Simple design simplicity rather than complex but optimizeddesire to keep code maintainabledesign worked on by team
Development - Paired ProgrammingNo one develops code without a partnertwo developers work together - one codes, the other
“strategies” and “reviews”• Cite studies that extra resources are justified in much fewer
problems later• Avoid the high stress code reviews
Test soon and often Unit tests for all code Acceptance tests run often and score is posted
21David LashCS 556 - Winter
Extreme Project Flow
http://www.extremeprogramming.org/rules.html
22David LashCS 556 - Winter
Extreme Programming Key Concepts
Customer involvementQuick release of small projectsUse cases, system metaphorsPaired programmingFrequent unit tests
23David LashCS 556 - Winter
Extreme Programming Precepts
Do the simplest thing that could possibly work. If a program is so complex that it will be hard to modify later, it is just too complex.
You’re not gonna need it. Save time by implementing new features when you actually need them, not when you foresee that you’ll need them someday.
Code reviews are good. Programmers should work in pairs, sharing one screen, so that all code is reviewed as it is written.
Interaction between developers and customers is good. Have a customer on site who can prioritize work for the team and answer questions as they arise.
Work at a pace that can be sustained indefinitely. Work overtime only when it is effective. “Death march” projects do not produce quality software.
26David LashCS 556 - Winter
Software Project Survival Guide Ch 3 - ProcessNeed documented, defined processes
Ensures proper activities and focus Adds overhead but minimizes developers thrashing
Need to be pre-defined to minimize thrashing Change control - E.g. a team allowing mid-term
changes and later realize scope creep and blown schedule.
Quality- Need to ensure quality at each level integration becomes ugly
Code control - If skip source control can lose time with multiple developers overwriting files
Schedules - re-estimating schedules during devmt
27David LashCS 556 - Winter
Process Profiles Pg 24-25
Figure 3.3 – W/O process focus, as time & complexity increases, more and more thrashing
28David LashCS 556 - Winter
Process Profiles Pg 24-25Figure 3.4 Early focus on process minimizing
thrashing.
While process might effect creativity Essential to productivity, moral, control
29David LashCS 556 - Winter
Process Profiles Pg 24-25Good processes designed to enable early
problem detection … (Figure 3-5) cheaper to correct
Early defects Foundation for failure Propagation
30David LashCS 556 - Winter
McConnell states in the Software Project Survival Guide that “A successful project should be one that meets its cost, schedule and quality goals within engineering tolerances and without padding its schedule or budget.”
Simply stated the project must be: On budget On time On target
Ch. 5 The Successful Project - What Makes a Project Successful
Should add: The resulting software must meet or exceed client expectations
31David LashCS 556 - Winter
For a project to be considered “successful”, all members of the customer community must share a common vision, or set of objectives for the project, against which the outcome of the project can be measured.
Only the customer community itself can change this common vision, or set of objectives for the project.
What Makes a Project Successful
32David LashCS 556 - Winter
Karl Albrecht presented a simple management model in his 1970’s book Successfully Managing by Objectives that still applies today, and especially so to project work: Look Ahead (The Project Vision) Plan Ahead (Planning the Work) Move Ahead (Working the Plan)
What Makes a Project Successful
33David LashCS 556 - Winter
Staged DeliveryDelivery of functions in stages
Most important first Most large projects has natural phase overlap
34David LashCS 556 - Winter
Staged DeliveryStages delivery Plan p.54
Functionality delivered via stages
35David LashCS 556 - Winter
Staged Delivery Benefits Critical functionality early -> get
something useful earlyReduce risks of unsuccessful integration
(by eliminate big integration bang)Problems become evident earlier Customer changes can be considered
between changes. Balances flexibility and efficiency
Costs -> - Increases overhead because time needed to release software.- Increases maintenance complexity since supporting code earlier.
36David LashCS 556 - Winter
Staged Delivery Staffing
Phase 1 Software definition Requirements development Architecture design Senior developers
Phase 2 Staged Delivery Detail design and construction Testing
FaceFace a go/no go decision
37David LashCS 556 - Winter
Milestones
Status of the project often tracked via major milestones. See Fig. 5-7 p. 64
38David LashCS 556 - Winter
Milestones Project plan would define and track each
activity that corresponds with each major milestone (Table 5.1 Pg 65.)