IS 556 Project Management

1. IS 556 Project Management David A. Lash 630.979.5940 dlash@condor.depaul.edu Week 3 David Lash

2. Agenda • Software Lifecycle • Extreme Programming • Processes • Case: Xerox

3. Overview • 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

4. 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. Code And Fix Maintain Concept Code Fix

5. The Software Development Life Cycle • Many 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

6. Concept Requirements Design Implementation Integration Go Live Maintenance The ‘Waterfall’ Model 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. Time

7. “Rapid Prototyping” Model • Often 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, Concept Prototype Rqmnts Design Impl Integrate Test RapidPrototypes

8. Evolutionary Software Development • Main 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

9. The Spiral Development Model Each iteration software increases complexity, functionality. You’ll need an “evolution plan”, up front to negotiate with customer.

10. Software phases … • Looked at • Waterfall • Rad • Spiral • Will look at common phases: • Concept • Requirements • Design • Code • Integration • Maintain

11. Concept Phase • Determine 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

12. 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.

13. Design Phase • Software 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

14. Implementation Phase • Coding!!! • 40% spec –20% coding – 40% integration • Problems • Time pressure • Requirements problems • Resource shortage • Customer/client and management problems ReqDesign CodeTest IntegrateTest

15. Integrate Test Phase • Modules combined & overall testing VS requirements • System 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.

16. Maintenance Phase • Most 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.

17. Agenda • Software Lifecycle • Extreme Programming • Processes

18. 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

19. 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.

20. Introduction to Extreme Programming • Simple design • simplicity rather than complex but optimized • desire to keep code maintainable • design worked on by team • Development - Paired Programming • No one develops code without a partner • two 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

21. Extreme Project Flow http://www.extremeprogramming.org/rules.html

22. Extreme Programming Key Concepts • Customer involvement • Quick release of small projects • Use cases, system metaphors • Paired programming • Frequent unit tests

23. 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.

24. Agenda • Software LifeCycle • Extreme Programming • Processes

25. Software Project Survival Guide Ch 3 Survival Concepts

26. Software Project Survival Guide Ch 3 - Process • Need 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

27. Process Profiles Pg 24-25 • Figure 3.3 – W/O process focus, as time & complexity increases, more and more thrashing

28. Process Profiles Pg 24-25 • Figure 3.4 Early focus on process minimizing thrashing. • While process might effect creativity • Essential to productivity, moral, control

29. Process Profiles Pg 24-25 • Good processes designed to enable early problem detection … (Figure 3-5) • cheaper to correct • Early defects • Foundation for failure • Propagation

30. Ch. 5 The Successful Project - What Makes a Project Successful • 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 Should add: The resulting software must meet or exceed client expectations

31. What Makes a Project Successful • 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.

32. 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)

33. Staged Delivery • Delivery of functions in stages • Most important first • Most large projects has natural phase overlap

34. Staged Delivery • Stages delivery Plan p.54 • Functionality delivered via stages

35. Staged Delivery Benefits • Critical functionality early -> get something useful early • Reduce 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.

36. Staged Delivery Staffing • Phase 1 Software definition • Requirements development • Architecture design • Senior developers • Phase 2 Staged Delivery • Detail design and construction • Testing Face a go/no go decision

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

38. Milestones • Project plan would define and track each activity that corresponds with each major milestone (Table 5.1 Pg 65.)

39. Summary • Ch 4. Software Development Lifecycles • Types of models • Majors phases • Extreme Programming • Ch 3 Software Project - Survival Guide • Using Development Processes • Ch. 5 The Successful Project - Survival Guide • Staged Delivery & Tracking Milestones