Software Project Management: A Comprehensive Guide to Planning, Documents, and Phases, Slides of Software Engineering

Download Software Project Management: A Comprehensive Guide to Planning, Documents, and Phases and more Slides Software Engineering in PDF only on Docsity! Software Project Management Life Cycle Planning docsity.com Today  1. Lifecycle Planning  2. Project plans  3. Phases in Detail  Step-by-step of typical software project  Previous Week: WBS, SOW, Project Charter  Next Week: PERT, CPM, Scheduling & Estimation docsity.com Documents  Planning  Product docsity.com Potential Deliverables by Phase Possible Deliverabies by Phase > Concept Document > Statement of Work (SOW) > Project Charter > RFP & Proposal Software Concept L. Requirements > Requirements Document (Sofware Requirements Specification) > Work Breakdown Structure (VBS) >» Functional Specification (Top Level Design Specification) > Entity Relationship Diagram > Data Flow Diagram > Detailed Design Specification » Object Diagrams >» Detailed Data Model Software Development Plan (Software Project Management Plan) Design > > + > Baseline Project Plan » Coding Standards > Quality Assurance Plan > Working Code > Configuration Management Plan Coal 5 >» Unit Tests i oding an ® Risk Management Pian Debucging > Integrated Modules > Tested Application | > Integration Plan » Acceptance Test Sign-off > Detailed SQA Test Plan Systems > Maintenance Specification ! > SQA Test Cases Testing >» Deployed Application g | > Acceptance Test Procedures >» Post-Performance Analysis rie » User Documentation Deployment & Maintenance > Training Plan >» Support Plan >» Release Checklist docsity.com Planning Documents  Software Development Plan (SDP)  Software Quality Assurance Plan (SQAP)  Software Configuration Management Plan (SCMP)  Risk Management Plan  Software Process Improvement Plan  Communications Management Plan  Migration Plan  Operations Plan docsity.com Product Documents  Statement of work/Need  System Interface Specification  Software Requirements Specification  Software Design Specification  Software Validation & Verification Plan  User Documentation  Support Plan  Maintenance Documentation docsity.com Remind Planning  How much will it cost?  How long will it take?  How many people will it take?  What might go wrong? docsity.com Planning  Scoping  Estimation  Risk  Schedule  Control Strategy docsity.com SDP / SPMP  Fundamental Sections  Project overview  Deliverables  Project organization  Managerial processes  Technical processes  Budget  Schedule docsity.com Communications Management Plan  Often a section of SPMP  Describes information flow to all parties  Gathering and distributing information  Status meetings  Monthly, Weekly, Daily?  Status reports are vital docsity.com Create a Project Intranet  A great communications tool  Reference all project resources here docsity.com Time Allocation by Phase  Remember the 40-20-40 Rule  Specification-Implementation-Test Planning Code & Unit Test Integration & Test Commercia l DP 25% 40% 35% Internet Systems 55% 15% 30% Real-time Systems 35% 25% 40% Defense Systems 40% 20% 40% Bennatan, E.M, “On Time Within Budget” docsity.com Time Allocation by Phase Activity Small Project (2.5K LOC) Large Project (500K LOC) Analysis 10% 30% Design 20% 20% Code 25% 10% Unit Test 20% 5% Integration 15% 20% System test 10% 15% McConnell, Steve, “Rapid Development” docsity.com Activities by % of Total Effort NASA’s “Manager’s Handbook for Software Development” docsity.com Concept Exploration  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:  Concept Document, Product Description, Proposal, SOW, Project Charter docsity.com Concept Exploration  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  Achieved via:  Good concept document or equivalent  Demonstration of clear need (justification)  Initial estimates docsity.com Requirements  Requirements are capabilities and condition to which the system – more broadly, the project – must conform docsity.com Why are Requirements so Important? a Cost to A Correct 4 Phase That a Defect Is Created Requirernents Architecture Detailed design \ Construction | \ \ \ ae Requirements Architecture Detailed Construction Maintenance design Phase That a Defect Is Corrected Copyright 1998 Steven C. McConnell. Reprinted with pemnission from Software Project Survival Guide (Mlicrosoft Press, 1998). docsity.com Requirements  Characteristics & Issues  Conflict of interest: developer vs. customer  Potential tug-of-war: Disagreement on Features & Estimates  Especially in fixed-price contracts  Frequent requirements changes  Achieving sign-off  Project planning occurs in parallel docsity.com 2 Types of Requirements  Functional (behavioral)  Features and capabilities  Non-functional (“technical”) (everything else)  Usability  Human factors, help, documentation  Reliability  Failure rates, recoverability, availability  Performance  Response times, throughput, resource usage  Supportability  Maintainability, internationalization  Operations: systems management, installation  Interface: integration with other systems  Other: legal, packaging, hardware docsity.com Analysis & Design  The “How” Phases  Inputs: Requirements Document  Outputs:  Functional Specification  Detailed Design Document  User Interface Specification  Data Model  Prototype (can also be done with requirements)  Updated Plan (improved estimates; new baseline) docsity.com Analysis & Design  Top-level design & detailed design  Continues process from RD  Ends with Critical Design Review (CDR)  Formal sign-off  Can also include earlier Preliminary Design Review (PDR) for high level design docsity.com Analysis & Design  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 disagreement docsity.com Development  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 docsity.com Integration & Test  Evolves from Dev. Phase  Often done as 2 parallel phases  Partial integration & initial test  Starts with integration of modules  An initial, incomplete version constructed  Progressively add more components docsity.com Integration & Test  Integration primarily a programmer task  Test primarily a QA team task  Integration:  Top-down: Core functionality first, empty shells for incomplete routines (stubs)  Bottom up: gradually bind low-level modules  Prefer top-down generally docsity.com Deployment & Maintenance  Installation depends on system type Web-based, CD-ROM, in-house, etc.  Migration strategy  How to get customers up on the system  Parallel operation  Deployment typically in your project plan, maintenance not docsity.com Deployment & Maintenance  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 docsity.com Deployment & Maintenance  Characteristics & Issues  Lack of enthusiasm  Pressure for quick fixes  Insufficient budget  Too many patches  Personnel turnover  Regression testing is critical  Preferably through automated tools docsity.com Lifecycle Planning  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  A lifecycle is not a design, modeling or diagramming technique  The same technique (UML, DFD, etc) can be used with multiple lifecycles docsity.com Evolution of SDLC  Ad-Hoc  Traditional/Classical SDLC  Evolutionary SDLC  Agile SDLC docsity.com Choosing Your Lifecycle  Varies by project  Opt for “iterative” or “incremental”  How well are requirements understood?  What are the risks?  Is there a fixed deadline?  How experienced is the team or customer? docsity.com