is 556 fall 20031 is 556 project management david a. lash 630.979.5940 [email protected] week...

IS 556 Fall 2003 1

IS 556 Project Management

David A. [email protected] 3

David Lash

2David LashCS 556 - Winter

Agenda

Software Lifecycle Extreme Programming Processes Case: Xerox


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


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


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


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.


“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


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


The Spiral Development Model

Each iteration software increases complexity, functionality.

You’ll need an “evolution plan”, up front to negotiate with customer.


Software phases … Looked at

Waterfall Rad Spiral

Will look at common phases: Concept Requirements Design Code Integration Maintain


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


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.


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


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


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.


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.


Agenda

Software Lifecycle Extreme Programming Processes


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



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.



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


Extreme Project Flow

http://www.extremeprogramming.org/rules.html

http://www.extremeprogramming.org/rules.html


Extreme Programming Key Concepts

Customer involvementQuick release of small projectsUse cases, system metaphorsPaired programmingFrequent unit tests


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.


Agenda

Software LifeCycle Extreme Programming Processes

IS 556 Fall 2003 25

Software Project Survival Guide Ch 3 Survival Concepts


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


Process Profiles Pg 24-25

Figure 3.3 – W/O process focus, as time & complexity increases, more and more thrashing


Process Profiles Pg 24-25Figure 3.4 Early focus on process minimizing

thrashing.

While process might effect creativity Essential to productivity, moral, control


Process Profiles Pg 24-25Good processes designed to enable early

problem detection … (Figure 3-5) cheaper to correct

Early defects Foundation for failure Propagation


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


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


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


Staged DeliveryDelivery of functions in stages

Most important first Most large projects has natural phase overlap


Staged DeliveryStages delivery Plan p.54

Functionality delivered via stages


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.


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


Milestones

Status of the project often tracked via major milestones. See Fig. 5-7 p. 64


Milestones Project plan would define and track each

activity that corresponds with each major milestone (Table 5.1 Pg 65.)


Ch 4. Software Development Lifecycles Types of models Majors phases

Extreme ProgrammingCh 3 Software Project - Survival Guide

Using Development Processes

Ch. 5 The Successful Project - Survival Guide Staged Delivery & Tracking Milestones

Summary

is 556 fall 20031 is 556 project management david a. lash 630.979.5940 [email protected] week...

Documents