1October 29, 2008 Lecture 27 1CS 390 – Lecture 27Software Project Management Plans Components of a software project management plan The work to be done The resources with which to do it The money to pay for it October 29, 2008 Lecture 27 2Resources Resources needed for software development: People Hardware Support softwareOctober 29, 2008 Lecture 27 3Use of Resources Varies with Time Rayleigh curves accurately depict resource consumptionRc= t/k2e-t2/2k2 The entire software development plan must be a function of timeOctober 29, 2008 Lecture 27 4Work Categories Project function Work carried on throughout the project Examples: Project management Quality controlOctober 29, 2008 Lecture 27 5Work Categories (2) Activity Work that relates to a specific phase A major unit of work, With precise beginning and ending dates, That consumes resources, and Results in work products like the budget, design, schedules, source code, or users’ manualOctober 29, 2008 Lecture 27 6Work Categories (3) Task An activity comprises a set of tasks(the smallest unit of work subject to management accountability)2October 29, 2008 Lecture 27 7Completion of Work Products Milestone: The date on which the work product is to be completed It must first pass reviews performed by Fellow team members Management The client Once the work product has been reviewed and agreed upon, it becomes a baseline Changeable only through formal procedureOctober 29, 2008 Lecture 27 8Work Package Work product, plus Staffing requirements Duration Resources The name of the responsible individual Acceptance criteria for the work product The detailed budget as a function of time, allocated to Project functions Activities October 29, 2008 Lecture 27 9Software Project Management Plan Framework There are many ways to construct an SPMP One of the best is IEEE Standard 1058.1 The standard is widely accepted It is designed for use with all types of software products It supports process improvement Many sections reflect CMM key process areas It is ideal for the Unified Process There are sections for requirements control and risk managementOctober 29, 2008 Lecture 27 10IEEE Software Project Management Plan (Figure 9.9) Overview Project summary Purpose, scope, and objectives Assumptions and constraints Project deliverables Schedule and budget summary Evolution of the project management plan Reference materials Definitions and acronyms Project organizations External interfaces Internal structure Roles and responsibilitiesOctober 29, 2008 Lecture 27 11IEEE Software Project Management Plan (2) Managerial process plans Start-up plan Estimation plan Staffing plan Resource acquisition plan Project staff training plan Work plan Work activities Schedule allocation Resource allocation Budget allocation Managerial process plans (cont’d) Control plan Requirements control plan Schedule control plan Budget control plan Quality control plan Reporting plan Metrics collection plan Risk management plan Project close-out planOctober 29, 2008 Lecture 27 12IEEE Software Project Management Plan (3) Technical process plans Process model Methods, tools, and techniques Infrastructure plan Product acceptance plan Supporting process plans Configuration management plan Testing plan Documentation plan Quality assurance plan Reviews and audits plan problem resolution plan Subcontractor management plan Process improvement plan Additional plans3October 29, 2008 Lecture 27 13Software Project Management Plan Framework (2) Some of the sections are inapplicable to small-scale software Example: Subcontractor management planOctober 29, 2008 Lecture 27 14Planning Testing Often overlooked The SPMP must explicitly state what testing is to be done Traceability is essential, e.g. number and reference each aspect of requirements All black box test cases must be drawn up as soon as possible after the specifications are completeOctober 29, 2008 Lecture 27 15Planning Object-Oriented Projects An object-oriented product consists of largely independent pieces Consequently, planning is somewhat easier The whole is more than the sum of its parts We can use COCOMO II (or modify Intermediate COCOMO) estimatorsOctober 29, 2008 Lecture 27 16Planning Object-Oriented Projects (2) However, reuse induces errors in cost and duration estimates Reuse of existing components during development Production of components for future reuse (up to 3x longer to do) These work in opposite directions Newer data: The savings outweigh the costsOctober 29, 2008 Lecture 27 17Training Requirements “We don’t need to worry about training until the product is finished, and then we can train the user” Training is generally needed by the members of the development group, starting with training in software planning A new software development method necessitates training for every member of the groupOctober 29, 2008 Lecture 27 18Training Requirements (2) Introduction of hardware or software tools of any sort necessitates training Programmers may need training in the operating system and/or implementation language Documentation preparation training may be needed Computer operators require training4October 29, 2008 Lecture 27 19Documentation Standards IBM internal commercial product (50 KDSI) 28 pages of documentation per KDSI Commercial software product of the same size 66 pages per KDSI IMS/360 Version 2.3 (about 166 KDSI) 157 pages of documentation per KDSI [TRW] For every 100 hours spent on coding activities, 150–200 hours were spent on documentation-related activitiesOctober 29, 2008 Lecture 27 20Types of Documentation Planning Control Financial Technical Source code Comments within source codeOctober 29, 2008 Lecture 27 21Documentation Standards (2) Reduce misunderstandings between team members Aid SQA Only new employees have to learn the standards Standards assist maintenance programmers Standardization is important for user manualsOctober 29, 2008 Lecture 27 22Documentation Standards (3) As part of the planning process Standards must be set up for all documentation In a very real sense, the
View Full Document