9 project planning

Sizing Effort for project depends on many factors Size is the main factor – many experiments and data analysis have validated this Size in the start is only an estimate; getting size estimates from requirement is hard Need a size unit that can be “computed” from requirements Function points attempt to do this

Function Points Is a size measure like LOC Determined from SRS Defines size in terms of “ functionality “ Why “measure” size early ? Needed for estimation and planning Five different parameters external input type external output type logical internal file type external interface file type external inquiry type

Function Points… These five parameters capture the functionality of a system within a type , an element may be simple , average or complex A weighted sum is taken External input type : each unique input type A input type is unique if the format is different from others or if the specifications require different processing.

Function Points… Simple : a few data elements Complex : many data elements and many internal files needed for processing Only files needed by the application are counted. ( HW/OS config. Files are are not counted ) External output type : each unique output that leave system boundary E.g. Reports , messages to user , data to other applications Simple : few columns

Function Points… Average : many columns Complex : references many files for production Logical internal file type : An application maintains information internally for its own processes Each logical group of data generated , used and maintained Same for simple , average and complex

Function Points… External interface file type logical files passed between application External inquiry type input , output combination Weights External Input 3 4 6 External Output 4 5 7 Logical int. file 7 10 15 External int. file 5 7 10 External inquiry 3 4 6

Function Points… Unadjusted function point : Basic function points Adjusted for other factors 14 such factors performance objectives , transaction rate etc. Final FP is adjusted differs at most 35%

Function Points… Interest in FP since obtained at requirements => major advantage Well correlated with size in some what interchangeable and tables exist 1 FP = 70 LOC of C Works well for MIS , but not for system type Major draw back - subjectivity not repeatable not precisely known ever for a built system not addictive

Project Schedule A project Schedule is at two levels - overall schedule and detailed schedule Overall schedule comprises of major milestones and final date Detailed schedule is the assignment of lowest level tasks to resources

Overall Schedule Depends heavily on the effort estimate For an effort estimate, some flexibility exists depending on resources assigned Eg a 56 PM project can be done in 8 months (7 people) or 7 months (8 people) Stretching a schedule is easy; compressing is hard and expensive

Overall Scheduling... One method is to estimate schedule S (in months) as a function of effort in PMs Can determine the fn through analysis of past data; the function is non linear COCOMO: S = 2.5 E 3.8 Often this schedule is checked and corrected for the specific project One checking method – square root check

Determining Overall Schedule from past data

Determining Milestones With effort and overall schedule decided, avg project resources are fixed Manpower ramp-up in a project decides the milestones Manpower ramp-up in a project follows a Rayleigh curve - like a normal curve In reality manpower build-up is a step function

Milestones ... With manpower ramp-up and effort distribution, milestones can be decided Effort distribution and schedule distribution in phases are different Generally, the build has larger effort but not correspondingly large schedule COCOMO specifies distr of overall sched. Design – 19%, programming – 62%, integration – 18%

An Example Schedule # Task Dur. (days) Work (p-days) Start Date End Date 2 Project Init tasks 33 24 5/4 6/23 74 Training 95 49 5/8 9/29 104 Knowledge sharing 78 20 6/2 9/30 114 Elaboration iteration I 55 55 5/15 6/23 198 Construction iteration I 9 35 7/10 7/21

Detailed Scheduling To reach a milestone, many tasks have to be performed Lowest level tasks - those that can be done by a person (in less than 2-3 days) Scheduling - decide the tasks, assign them while preserving high-level schedule Is an iterative task - if cannot “fit” all tasks, must revisit high level schedule

Detailed Scheduling Detailed schedule not done completely in the start - it evolves Can use MS Project for keeping it Detailed Schedule is the most live document for managing the project Any activity to be done must get reflected in the detailed schedule

An example task in detail schedule Module Act Code Task Duration Effort History PUT Unit test # 17 1 day 7 hrs St. date End date %comp Depend. Resource 7/18 7/18 0% Nil SB

.Project Scheduling….. The scheduling process

..Project Scheduling…. Graphical notations used in software project scheduling: Tables: summary description of tasks Bar charts : show schedule against the time Activity charts : graphs that depict dependencies between tasks and indicate the critical path (the longest path in the activity graph)

… Project Scheduling… Example of tabular description :

… .Project Scheduling.. Example of activity chart

… ..Project Scheduling. Example of bar chart

…… Project Scheduling Staff allocation chart

Detail schedule Each task has name, date, duration, resource etc assigned % done is for tracking (tools use it) The detailed schedule has to be consistent with milestones Tasks are sub-activities of milestone level activities, so effort should add up, total schedule should be preserved

Team Structure To assign tasks in detailed schedule, need to have a clear team structure Hierarchic team org is most common Project manager has overall responsibility; also does design etc. Has programmers and testers for executing detailed tasks May have config controller, db manager, etc

Team structure.. An alternative – democratic teams Can work for small teams; leadership rotates Another one used for products A dev team led by a dev mgr, a test team led by test mgr, and a prog. Mgmt team All three report to a product mgr Allows specialization of tasks and separate career ladders for devs, tests, PMs

SCM process and planning Have discussed SCM process earlier During planning, the SCM activities are planned along with who will perform them Have discussed planning also earlier Includes defining CM items, naming scheme, directory structure, access restrictions, change control, versioning, release procedure etc

Quality Planning Delivering high quality is a basic goal Quality can be defined in many ways Current industry standard - delivered defect density (e.g. #defects/KLOC) Defect - something that causes software to behave in an inconsistent manner Aim of a project - deliver software with low delivered defect density

Defect Injection and Removal Software development is labor intensive Defects are injected at any stage As quality goal is low delivered defect density, these defects have to be removed Done primarily by quality control (QC) activities of reviews and testing

Approaches to Quality Management Ad hoc - some testing, some reviews done as and when needed Procedural - defined procedures are followed in a project Quantitative - defect data analysis done to manage the quality process

Procedural Approach A quality plan defines what QC tasks will be undertaken and when Main QC tasks - reviews and testing Guidelines and procedures for reviews and testing are provided During project execution, adherence to the plan and procedures ensured

Quantitative Approach Goes beyond asking “has the procedure been executed” Analyzes defect data to make judgements about quality Past data is very important Key parameters - defect injection and removal rates, defect removal efficiency (DRE)

Quality Plan The quality plan drives the quality activities in the project Level of plan depends on models available Must define QC tasks that have to be performed in the project Can specify defect levels for each QC tasks (if models and data available)

Risk Management Any project can fail - reasons can be technical, managerial, etc. Project management aims to tackle the project management aspect Engineering life cycles aim to tackle the engineering issues A project may fail due to unforeseen events - risk management aims to tackle this

Risk Management Risk: any condition or event whose occurrence is not certain but which can cause the project to fail Aim of risk management: minimize the effect of risks on a project

Risk Identification To identify possible risks to a project, i.e. to those events that might occur and which might cause the project to fail No “algorithm” possible, done by “what ifs”, checklists, past experience Can have a list of “top 10” risks that projects have seen in past

Top Risk Examples Shortage of technically trained manpower Too many requirement changes Unclear requirements Not meeting performance requirements Unrealistic schedules Insufficient business knowledge Working on new technology

Risk Prioritization The number of risks might be large Must prioritize them to focus attention on the “high risk” areas For prioritization, impact of each risk must be understood In addition, probability of the risk occurring should also be understood

Risk Prioritization ... Risk exposure (RE) = probability of risk occurring * risk impact RE is the expected value of loss for a risk Prioritization can be done based on risk exposure value Plans can be made to handle high RE risks

A Simple approach to Risk Prioritization Classify risk occurrence probabilities as: Low, Medium, High Classify risk impact as: Low, Medium, High Identify those that are HH, or HM/MH Focus on these for risk mitigation Will work for most small and medium sized projects

Risk Control Can the risk be avoided? E.g. if new hardware is a risk, it can be avoided by working with proven hardware For others, risk mitigation steps need to be planned and executed Actions taken in the project such that if the risk materializes, its impact is minimal Involves extra cost

Risk Mitigation Examples Too many requirement changes Convince client that changes in requirements will have an impact on the schedule Define a procedure for requirement changes Maintain cumulative impact of changes and make it visible to client Negotiate payment on actual effort.

Examples ... Manpower attrition Ensure that multiple resources are assigned on key project areas Have team building sessions Rotate jobs among team members Keep backup resources in the project Maintain documentation of individual’s work Follow the CM process and guidelines strictly

Examples ... Unrealistic schedules Negotiate for better schedule Identify parallel tasks Have resources ready early Identify areas that can be automated If the critical path is not within the schedule, negotiate with the client Negotiate payment on actual effort

Risk Mitigation Plan Risk mitigation involves steps that are to be performed (hence has extra cost) It is not a paper plan - these steps should be scheduled and executed These are different from the steps one would take if the risk materializes - they are performed only if needed Risks must be revisited periodically

Background A plan is a mere document that can guide It must be executed To ensure execution goes as per plan, it must be monitored and controlled Monitoring requires measurements And methods for interpreting them Monitoring plan has to plan for all the tasks related to monitoring

Measurements Must plan for measurements in a project Without planning, measurements will not be done Main measurements – effort, size, schedule, and defects Effort – as this is the main resource; often tracked through effort reporting tools Defects – as they determine quality; often defect logging and tracking systems used During planning – what will be measured, how, tool support, and data management

Project Tracking Goal: To get visibility in project execution so corrective actions can be taken when needed to ensure project succeeds Diff types of monitoring done at projects; measurements provide data for it

Tracking… Activity-level monitoring Each activity in detailed schd is getting done Often done daily by managers A task done marked 100%; tools can determine status of higher level tasks Status reports Generally done weekly to take stock Summary of activities completed, pending Issues to be resolved

Tracking… Milestone analysis A bigger review at milestones Actual vs estimated for effort and sched is done Risks are revisited Changes to product and their impact may be analyzed Cost-schedule milestone graph is another way of doing this

Project Management Plan The project management plan (PMP) contains outcome of all planning activities - focuses on overall project management Besides PMP, a project schedule is needed Reflects what activities get done in the project Microsoft project (MSP) can be used for this Based on project planning; is essential for day-to-day management Does not replace PMP !

PMP Structure - Example Project overview - customer, start and end date, overall effort, overall value, main contact persons, project milestones, development environment.. Project planning - process and tailoring, requirements change mgmt, effort estimation, quality goals and plan, risk management plan, ..

PMP Example ... Project tracking - data collection, analysis frequency, escalation procedures, status reporting, customer complaints, … Project team, its organization, roles and responsibility, …

Project Planning - Summary Project planning forms the foundation of project management Key aspects: effort and schedule estimation, quality planning, risk mgmt., … Outputs of all can be documented in a PMP, which carries all relevant info about project Besides PMP, a detailed project schedule maintains tasks to be done in the project

9 project planning

More Related Content

What's hot (19)

Similar to 9 project planning (20)

More from randhirlpu (13)

Recently uploaded (20)

9 project planning