Planning Phase - P&MSP2010 (3/11)
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Planning Phase - P&MSP2010 (3/11)

on

  • 2,640 views

- Development lifecycle models

- Development lifecycle models
- Matching lifecycles to projects
- Project plans

Statistics

Views

Total Views
2,640
Views on SlideShare
2,640
Embed Views
0

Actions

Likes
2
Downloads
162
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Planning Phase - P&MSP2010 (3/11) Presentation Transcript

  • 1. Session 3 Planning Emanuele Della Valle http://home.dei.polimi.it/dellavalle
  • 2. Credits 2 This slides are largely based on Prof. John Musser class notes on “Principles of Software Project Management” M t” Original slides are available at http://www.projectreference.com/ htt // j t f / Reuse and republish permission was granted Planning and Managing Software Projects – Emanuele Della Valle
  • 3. Today 3 1. Phases in Detail • Step-by-step of typical software project 2. Lifecycle Planning 3. Project p j plans Next Week: Lots of Project ish Details: WBS PERT Project-ish WBS, PERT, CPM, Scheduling & Estimation Planning and Managing Software Projects – Emanuele Della Valle
  • 4. Session 2 Review 4 PMI Fundamentals PMI Processes Project and Organizations • Functional, Project, Matrix organizations , j , g • Role of PM in this type of organizations Project Selection Project Portfolio Management Procurement Management Initial documents • Statement of Work (SOW) • Project Charter Planning and Managing Software Projects – Emanuele Della Valle
  • 5. Introduction to session 3 Project Phases 5 Planning and Managing Software Projects – Emanuele Della Valle
  • 6. Introduction to session 3 Time Allocation by Phase 6 Remember the 40-20-40 Rule • Specification-Implementation-Test Planning Code & Integration & Unit Test Test Commercial 25% 40% 35% DP Internet 55% 15% 30% Systems Real-time Real time 35% 25% 40% Systems Defense 40% 20% 40% Systems Bennatan, E.M, “On Time Within Budget” Planning and Managing Software Projects – Emanuele Della Valle
  • 7. Introduction to session 3 Time Allocation by Phase 7 Activity Small Project Large Project (2.5K LOC) (500K LOC) Analysis 10% 30% Design 20% 20% Code 25% 10% Unit T t U it Test 20% 5% Integration 15% 20% System test 10% 15% McConnell, Steve, “Rapid Development” Planning and Managing Software Projects – Emanuele Della Valle
  • 8. Introduction to session 3 Activities by % of Total Effort 8 NASA’s “Manager’s Handbook for Software Development” Planning and Managing Software Projects – Emanuele Della Valle
  • 9. Introduction to session 3 Potential Deliverables by Phase 9 Planning and Managing Software Projects – Emanuele Della Valle
  • 10. Phases in Detail Concept Exploration 10 The “Why” phase Not a “mandatory formal phase mandatory formal” • Sometimes called the “pre-project” phase Collecting p j g project ideas • Then the “funneling” process Project Justification • Cost-benefit analysis • Project Portfolio Matrix • ROI Initial planning and estimates Planning and Managing Software Projects – Emanuele Della Valle
  • 11. Phases in Detail Concept Exploration 11 Possibly includes Procurement Management: • RFP Process • Vendor selection • Contract management Gathering the initial team • Including PM if not already on-board Identify the project sponsor • Primary contact for approval and decision making Potential Phase Outputs: p • Concept Document, Product Description, Proposal, SOW, Project Charter Planning and Managing Software Projects – Emanuele Della Valle
  • 12. Phases in Detail Concept Exploration 12 Characteristics & Issues • Lack of full commitment and leadership • Some frustrations: – Management only getting rough estimates from development – Development not getting enough specifics from customer – Finding a balanced team • Budget sign-off may be your 1st major task g g y y j • Achieved via: – Good concept document or equivalent – Demonstration of clear need (justification) – Initial estimates Planning and Managing Software Projects – Emanuele Della Valle
  • 13. Phases in Detail Requirements 13 The “What” phase Inputs: SOW, Proposal Outputs: • Requirements Document ( ) q (RD) – a.k.a.Requirements Specification Document (RSD) – Software Requirements Specification (SRS) • 1st Project Baseline • Software Project Management Plan (SPMP) • Requirements Approval & Sign-Off – Your most diffi l task in this phase difficult k i hi h Planning and Managing Software Projects – Emanuele Della Valle
  • 14. Phases in Detail Requirements 14 Perhaps most important & difficult phase Shortchanging it is a ‘classic mistake classic mistake’ Can begin with a Project Kickoff Meeting Can end with a Software Requirements Review (SRR) C d ith S ft R i t R i • For Sponsor and/or customer(s) approval Planning and Managing Software Projects – Emanuele Della Valle
  • 15. Phases in Detail Why are Requirements so Important? 15 Planning and Managing Software Projects – Emanuele Della Valle
  • 16. Phases in Detail Requirements 16 Characteristics & Issues • Conflict of interest: developer vs. customer • Potential tug of war: tug-of-war: – Disagreement on Features & Estimates – Especially in fixed-price contracts • Frequent requirements changes • Achieving sign-off Project l P j t planning occurs i parallel i in ll l Planning and Managing Software Projects – Emanuele Della Valle
  • 17. Phases in Detail Requirements 17 Requirements are capabilities and condition to which the system – more broadly, the project – must conform f Planning and Managing Software Projects – Emanuele Della Valle
  • 18. Phases in Detail 2 Types of Requirements 18 Functional (behavioral) • Features and capabilities Non-functional (a.k.a. “technical”) (everything else) • Usability – Human factors, help, documentation factors help • Reliability – Failure rates, recoverability, availability • Performance f – Response times, throughput, resource usage • Supportability pp y – Maintainability, internationalization • Operations: systems management, installation • Interface: integration with other systems • Other: legal, packaging, hardware Planning and Managing Software Projects – Emanuele Della Valle
  • 19. Phases in Detail Requirements 19 Other ways of categorizing • Go-Ahead vs. Catch-up – R l ti Relative t competition to titi • Backward-looking vs. Forward-looking – Backward: address issues with previous version – Forward: Anticipating future needs of customers Must be prioritized • Must-have • Should-have • Could-have (Nice-to-have: NTH) ( ) Must be approved An example I m proud of I’m • http://www.service-finder.eu/attachments/D1.1.pdf Planning and Managing Software Projects – Emanuele Della Valle
  • 20. Phases in Detail Early Phase Meetings 20 Project Kickoff Meeting Project Brainstorming Meeting • Clarify goals, scope, assumptions • Refine estimates WBS Meeting Planning and Managing Software Projects – Emanuele Della Valle
  • 21. Phases in Detail Analysis & Design 21 The “How” Phases Inputs: Requirements Document Outputs: • Functional Specification p • Detailed Design Document • User Interface Specification • Data Model • Prototype (can also be done with requirements) • Updated Plan (improved estimates; new baseline) Planning and Managing Software Projects – Emanuele Della Valle
  • 22. Phases in Detail Analysis & Design 22 a.k.a. Top-level design & detailed design Continues process from RD Ends with Critical Design Review (CDR) • Formal sign-off g • Can also include earlier Preliminary Design Review (PDR) for high level design Planning and Managing Software Projects – Emanuele Della Valle
  • 23. Phases in Detail Analysis & Design 23 Characteristics & Issues • Enthusiasm via momentum • Team structure and assignments finalized • Delays due to requirements changes, new information or late ideas • Issues around personnel responsibilities • Unfeasible requirements (technical complexity) • Resource Issues – Including inter-project contention Planning and Managing Software Projects – Emanuele Della Valle
  • 24. Phases in Detail Development 24 The “Do It” phase Coding & Unit testing Often overlaps Design & Integration phases • To shorten the overall schedule • PM needs to coordinate this Planning and Managing Software Projects – Emanuele Della Valle
  • 25. Phases in Detail Development 25 Other concurrent activities • Design completion • Integration begins • Unit testing of individual components • Test bed setup (environment and tools) • Project plans updated l d d • Scope and Risk Management conducted Planning and Managing Software Projects – Emanuele Della Valle
  • 26. Phases in Detail Development 26 Characteristics • Pressure increases • Staffing at highest levels • Often a “heads-down” operation Issues • Last-minute changes • Team coordination (esp. in large projects) • Communication overhead • Management of sub-contractors Planning and Managing Software Projects – Emanuele Della Valle
  • 27. Phases in Detail Integration & Test 27 Evolves from Dev. Phase Often done as 2 parallel phases • Partial integration & initial test Starts with integration of modules g An initial, incomplete version constructed Progressively add more components Planning and Managing Software Projects – Emanuele Della Valle
  • 28. Phases in Detail Integration & Test 28 Integration primarily a programmer task Test primarily a QA team task Integration: • Top-down: Core functionality first, empty shells for p y , py incomplete routines (stubs) • Bottom up: gradually bind low-level modules • Prefer top-down generally p g y Planning and Managing Software Projects – Emanuele Della Valle
  • 29. Phases in Detail Integration & Test 29 Tests • Integration testing • Black & White box testing White-box • Load & Stress testing • Alpha & Beta testing • Acceptance testing Other activities • Final budgeting; risk mgmt ; training; installation mgmt.; preparation; team reduced Planning and Managing Software Projects – Emanuele Della Valle
  • 30. Phases in Detail Integration & Test 30 Characteristics & Issues • Increased pressure • Overtime • Customer conflicts over features • Frustration over last-minute failures • Budget overruns d • Motivation problems (such as burnout) • Difficulty in customer acceptance – Esp. true for fixed-price contracts Planning and Managing Software Projects – Emanuele Della Valle
  • 31. Phases in Detail Deployment & Maintenance 31 Installation depends on system type • Web-based, CD-ROM, in-house, etc. Migration strategy How to get customers up on the system g p y • Parallel operation Deployment typically in your project plan, maintenance not Planning and Managing Software Projects – Emanuele Della Valle
  • 32. Phases in Detail Deployment & Maintenance 32 Maintenance • Fix defects • Add new features • Improve performance Configuration control is very important here Documents need to be maintained also Sometimes a single team maintains multiple products Planning and Managing Software Projects – Emanuele Della Valle
  • 33. Phases in Detail Deployment & Maintenance 33 Characteristics & Issues • Lack of enthusiasm • Pressure for quick fixes • Insufficient budget • Too many patches • Personnel turnover l • Regression testing is critical – Preferably through automated tools y g Planning and Managing Software Projects – Emanuele Della Valle
  • 34. Lifecycle Planning 34 a.k.a. Lifecycle Management or Systems Development Life Cycle (SDLC ) Greatly influences your chance of success Not c oos g a lifecycle is a bad option ot choosing ecyc e s opt o Three primary lifecycle model components • Phases and their order • Intermediate products of each phase • Reviews used in each phase Planning and Managing Software Projects – Emanuele Della Valle
  • 35. Lifecycle Planning 35 Different projects require different approaches You do not need to know all models by name You should know how that if given a certain scenario what sort of SDLC would be appropriate at so t o S C ou d app op ate There are more than covered here A lifecycle is not a design modeling or diagramming design, technique • The same technique (UML, DFD, etc) can be used with multiple lif l i l lifecycles l Planning and Managing Software Projects – Emanuele Della Valle
  • 36. Lifecycle Planning Pure Waterfall 36 The “granddaddy” of models Linear sequence of phases • “Pure” model: no phases overlap Document driven All planning done up-front Planning and Managing Software Projects – Emanuele Della Valle
  • 37. Lifecycle Planning Waterfall Risk 37 Why does the waterfall model “invite risk”? Integration and testing occur at the end • Often anyone’s 1st chance to “see” the program Planning and Managing Software Projects – Emanuele Della Valle
  • 38. Lifecycle Planning Pure Waterfall 38 Works well for projects with • Stable product definition • Well-understood Well understood technologies • Quality constraints stronger than cost & schedule • Technically weak staff – Provides structure – Good for overseas projects Planning and Managing Software Projects – Emanuele Della Valle
  • 39. Lifecycle Planning Pure Waterfall 39 Disadvantages • Not flexible – Ri id march from start->finish Rigid hf t t fi i h • Difficult to fully define requirements up front • Can produce excessive documentation • Few visible signs of progress until the end Planning and Managing Software Projects – Emanuele Della Valle
  • 40. Lifecycle Planning Code-and-Fix 40 “Code-like-Hell” Specification (maybe), Code (yes), Release (maybe) Advantages • No overhead • Requires little expertise Disadvantages • No process, quality control, etc. • Highly risky Suitable for S it bl f prototypes or throwaways t t th Planning and Managing Software Projects – Emanuele Della Valle
  • 41. Lifecycle Planning Spiral 41 Planning and Managing Software Projects – Emanuele Della Valle
  • 42. Lifecycle Planning Spiral 42 Emphasizes risk analysis & mgmt. in each phase A Series of Mini-projects Mini projects Each addresses a set of “risks” • Start small, explore risks, prototype, plan, repeat , p ,p yp , p , p Early iterations are “cheapest” Number of spirals is variable • Last set of steps are waterfall-like Planning and Managing Software Projects – Emanuele Della Valle
  • 43. Lifecycle Planning Spiral 43 Advantages • Can be combined with other models • As costs increase, risks decrease increase • Risk orientation provides early warning Disadvantages • More complex • Requires more management Planning and Managing Software Projects – Emanuele Della Valle
  • 44. Lifecycle Planning Modified Waterfall – Sashimi 44 Overlapping phases Advantages • Reduces overall schedule • Reduces documentation • Works well if personnel continuity Disadvantages • Milestones more ambiguous • Progress tracking more difficult • Communication can be more difficult Planning and Managing Software Projects – Emanuele Della Valle
  • 45. Lifecycle Planning Evolutionary Prototyping 45 Design most prominent parts first • Usually via a visual prototype Good for situations with: • Rapidly changing requirements • Non-committal customer • Vague problem domain Provides steady, visible progress Disadvantages • Time estimation is difficult • Project completion date may be unknown • An excuse to do “code-and-fix” Planning and Managing Software Projects – Emanuele Della Valle
  • 46. Lifecycle Planning Staged Delivery 46 Waterfall steps through architectural design Then detailed design, code, test, deliver in stages Advantages • Customers get p g product much sooner • Tangible signs of progress sooner • Problems discovered earlier • Increases flexibility • Reduces: status reporting overhead & estimation error Disadvantages g • Requires more planning (for you the PM) • More releases increase effort (and possible feature p) creep) How’s this differ from Evolutionary Prototyping? Planning and Managing Software Projects – Emanuele Della Valle
  • 47. Lifecycle Planning V Process Model 47 Planning and Managing Software Projects – Emanuele Della Valle
  • 48. Lifecycle Planning V Process Model 48 Designed for testability • Emphasizes Verification & Validation Variation of waterfall g Strengths • Encourages V&V at all phases Weaknesses • Does not handle iterations • Changes can be more difficult to handle Good h i for G d choice f systems that require hi h reliability t th t i high li bilit such as patient control systems Planning and Managing Software Projects – Emanuele Della Valle
  • 49. Lifecycle Planning RAD 49 Rapid Application Development Popular in the 80’s 80 s • 1. Joint Requirements Planning (JRP) • 2. Joint Application Design (JAD) • 3 Construction 3. – Heavy use of tools: code generators – Time-boxed; many prototypes • 4. C Cutover Good for systems with extensive user input available Planning and Managing Software Projects – Emanuele Della Valle
  • 50. Lifecycle Planning COTS 50 Commercial Off-The-Shelf software Build vs. buy Build-vs.-buy decision Advantages • Available immediatelyy • Potentially lower cost Disadvantages • Not as tailored to your requirements Remember: custom software rarely meets its ideal (so compare that reality to CO S option) h l COTS ) Planning and Managing Software Projects – Emanuele Della Valle
  • 51. Lifecycle Planning Choosing Your Lifecycle 51 Varies by project Opt for “iterative” or “incremental” iterative incremental How well are requirements understood? What Wh t are the risks? th i k ? Is there a fixed deadline? How experienced is the team or customer? Planning and Managing Software Projects – Emanuele Della Valle
  • 52. Lifecycle Planning McConnell’s way of choosing a Lifeclycle 52 Model ab c de f gh i j k Legend: Pure Waterfall x x ~ ~~ x = excellent, Code-and-Fix Code and Fix x x ~ = fair to excellent, empty box = poor. Spiral x x x x x ~~~ x x Modified Waterfalls ~~ x x ~~ x ~~~ Evolutionary P otot ping E ol tion Prototyping x ~x~ ~x x~ Staged Delivery x x ~~~ ~ x Commercial (COTS) x x x ~ a. Works with poorly understood requirements b. Works with poorly understood architecture c. Produces highly reliable system g y y d. Produces system with large growth envelope e. Manages risks f. Can be constrained to a predefined schedule g. g Has low overhead h. Allows for midcourse corrections i. Provides customer with progress visibility j. Provides management with progress visibility k. Requires little manager or developer sophistication [source http://acmesoffware.com/acme/default.asp ] Planning and Managing Software Projects – Emanuele Della Valle
  • 53. Lifecycle Planning XP: eXtreme Programming 53 Not a Microsoft product Part of movement called “Agile Development” Agile Development A “Lightweight” methodology A bit counter-culture t lt Currently in vogue Motto: “Embrace Change” Highly Incremental / Iterative g y Planning and Managing Software Projects – Emanuele Della Valle
  • 54. Lifecycle Planning eXtreme Programming 54 Planning and Managing Software Projects – Emanuele Della Valle
  • 55. Lifecycle Planning eXtreme Programming 55 Suitable for small groups Attempts to minimize unnecessary work Uses an “on-site” customer Small releases S ll l Pair programming Refactoring q Stories as requirements You want good developers if you use this Planning and Managing Software Projects – Emanuele Della Valle
  • 56. Lifecycle Planning Other “Agile” Methodologies 56 Agile here means “lite”, reduced docs, highly iterative Agile Software Development • Alliance , http://www.agilealliance.org/home • their “manifesto”, http://agilemanifesto.org/ • their book http://www.amazon.com/exec/obidos/ASIN/0201699699/104-2402656-5403151 SCRUM • Features 30-day “Sprint” cycles • See http://jeffsutherland.org/scrum/ Feature Driven Development (FDD) • XP with more emphasis on docs and process Planning and Managing Software Projects – Emanuele Della Valle
  • 57. Lifecycle Planning Other “Agile” Methodologies 57 Adaptive Software Development (ASD) • Book http://www.amazon.com/exec/obidos/tg/detail/-/0932633404/ • Site http://www adaptivesd com/learn html http://www.adaptivesd.com/learn.html Dynamic System Development Method (DSDM) • Popular in Europe Homegrown: developers often hide their “agile adventures adventures” from management Planning and Managing Software Projects – Emanuele Della Valle
  • 58. Lifecycle Planning Other “Agile” Methodologies 58 Pros • Similar to XP, can reduce process overhead • Responsive to user feedback • Amenable to change Cons • Requires close monitoring by PM • May not “scale” to large projects • Often requires better quality developers Planning and Managing Software Projects – Emanuele Della Valle
  • 59. Project Plans Planning 59 “Plans are nothing. But planning is everything.” Gen. Dwight Eisenhower Planning and Managing Software Projects – Emanuele Della Valle
  • 60. Project Plans Planning 60 Preliminary planning starts on day one Even in the pre-project phase pre project Should not be conducted “in secret” Need buy-in and approval N db i d l • Very important step • Both from above and below Planning and Managing Software Projects – Emanuele Della Valle
  • 61. Project Plans Your PM Process 61 Why • Deliverable: ROI What • SOW, Requirements How • Design Specification, Software Development Plan, Lifecycle Futrell, Shafer, Shafer, “Quality Software Project Management” Do it • Execution Did it • Post Project Report Planning and Managing Software Projects – Emanuele Della Valle
  • 62. Project Plans Primary Planning Steps 62 Identify project scope and objectives Identify project organizational environment Analyze project characteristics Identify Id tif project products and activities j t d t d ti iti Estimate effort for each activity Identify risk Allocate resources Review and communicate plan Planning and Managing Software Projects – Emanuele Della Valle
  • 63. Project Plans Documents 63 Planning Product Planning and Managing Software Projects – Emanuele Della Valle
  • 64. Project Plans Planning Documents 64 Software Development Plan (SDP) Software Quality Assurance Plan (SQAP) Software Configuration Management Plan (SCMP) Risk Management Plan Ri k M t Pl Software Process Improvement Plan Communications Management Plan Migration Plan g Operations Plan Planning and Managing Software Projects – Emanuele Della Valle
  • 65. Project Plans Planning Documents 65 You (the PM) need to choose which documents are appropriate Docs do not have to be lengthy S a Set Small Set: • Software Development Plan • Risk Management Plan • Software Quality Assurance Plan • Software Configuration Management Plan Planning and Managing Software Projects – Emanuele Della Valle
  • 66. Project Plans My Choice 66 Statement of Work (SOW) Project Charter Software Project Management Plan (SPMP) Budget B d t Responsibility Assignment Matrix (RAM) Risk Management Plan Planning and Managing Software Projects – Emanuele Della Valle
  • 67. Project Plans Product Documents 67 Statement of Need System Interface Specification Software Requirements Specification Software Design Specification Software Validation & Verification Plan User Documentation Support Plan Maintenance Documentation Planning and Managing Software Projects – Emanuele Della Valle
  • 68. Project Plans Software Project Survival Guide 68 Another McConnell book See construx.com s SPSG section construx.com’s http://www.construx.com/survivalguide/subject.htm • Good content online • Documents • Schedules • Checklists • Project P j t web site template b it t l t I tool I’ve often used • Software Project Survival Test – http://www.construx.com/Page.aspx?hid=1229 Planning and Managing Software Projects – Emanuele Della Valle
  • 69. Project Plans Planning 69 How much will it cost? How long will it take? How many people will it take? What i ht Wh t might go wrong? ? Planning and Managing Software Projects – Emanuele Della Valle
  • 70. Project Plans Planning 70 Scoping Estimation Risk Schedule S h d l Control Strategy Planning and Managing Software Projects – Emanuele Della Valle
  • 71. Project Plans Process Issues 71 You want a fairly sophisticated process without incurring much overhead Remember, projects are often larger than they first appear Easier to loosen too much process than add later Planning and Managing Software Projects – Emanuele Della Valle
  • 72. Project Plans Plans Evolve Over Time 72 NASA’s “Manager’s Handbook for Software Development” Planning and Managing Software Projects – Emanuele Della Valle
  • 73. Project Plans Software Development Plan 73 Software Project Management Plan (SPMP) Some consider it the most important document in the project (along with SRS) • Can be seen as an aggregation of other core documents Evolves over time as pieces come together p McConnell’s example • http://www.construx.com/Page.aspx?nid=240 Planning and Managing Software Projects – Emanuele Della Valle
  • 74. Project Plans SDP / SPMP 74 Fundamental Sections • Project overview • Deliverables • Project organization • Managerial processes • Technical processes h l • Budget • Schedule Planning and Managing Software Projects – Emanuele Della Valle
  • 75. Project Plans Communications Management Plan 75 Often a section of SPMP Describes information flow to all parties • Gathering and distributing information Status meetings g • Monthly, Weekly, Daily? • Status reports are vital Planning and Managing Software Projects – Emanuele Della Valle
  • 76. Project Plans Create a Project Intranet 76 A great communications tool Reference all project resources here For instance have a look at portals of my current p ojects projects • http://www.service-finder.eu • http://www.larkc.eu and http://wiki.larkc.eu • http://www search-computing it/ http://www.search computing.it/ Planning and Managing Software Projects – Emanuele Della Valle
  • 77. Optional Readings 77 McConnell: 8 “Estimation”, 9 “Scheduling” Thayer: Cori pg. 171-182 “Fundamentals of Master 171 182 Fundamentals Scheduling”, Fairley 183-194 “Work Breakdown Structures” Review relevant links as appropriate on http://www.projectreference.com/ Planning and Managing Software Projects – Emanuele Della Valle
  • 78. Questions? 78 Planning and Managing Software Projects – Emanuele Della Valle
  • 79. Comics 79 [source http://www.cs.ucl.ac.uk/external/atanu/req.gif ] Planning and Managing Software Projects – Emanuele Della Valle
  • 80. 80 Planning and Managing Software Projects – Emanuele Della Valle
  • 81. Comics 81 [source http://www.codinghorror.com/blog/images/software-engineering-explained.png ] Planning and Managing Software Projects – Emanuele Della Valle
  • 82. Read out more about the tree swing 82 http://www.businessballs.com/treeswing.htm Planning and Managing Software Projects – Emanuele Della Valle