COMP 325 Lecture 8: Project Management, Planning, and Estimation
major resources: Object-Oriented and Classical Software Engineering 6ed, Schach 2005, Object-Oriented Software Engineering, Schach 2008. Object-Oriented Software Engineering 2ed, Lethbridge & Laganiere, 2005.

[ previous | schedule | next ]

Project Management Overview

• Project management involves
• Planning – an attempt to predict and prepare for the various activities to be undertaken over the course of the project
• Control – influence various factors that reduce risk and address problems before and as they arise
• Planning is covered below
• Some things you can control to lesser or greater extent:
• time allocation
• information and its flow
• team and process organization
• degree of quality
• money allocation
• Management process involves
• do the planning
• monitor the progress (this is risk management - expect the unexpected)
• reallocate resources as needed
• Critical subtext is managing people and the key is communication

Project Planning Overview following structure of IEEE 1058

• "Failing to plan is planning to fail." (anonymous)
• IEEE 1058 title: IEEE Standard for Software Project Management Plans
• aka SPMP, adopted in 1998
• scope: "To prescribe the format and contents of software management plans. A software management plan is the controlling document for managing a software project; it provides the technical and managerial activities necessary to satisfy the requirements for the software project."
• purpose: "To provide a uniform scheme to prepare and present a software project management plan."
• use or adaptation of this standard forces project managers to consider in advance all aspects of the endeavor
• developers who follow this standard to the T are likely at CMM level 4 or 5.
• the PDF of this standard is 26 pages long and can be purchased from the IEEE Shop for $109.
• Section 1: Overview - purpose, scope, objectives, deliverables, schedule, budget, plan evolution procedures
• Section 2: Reference materials - list of documents referred to in the plan
• Section 3: Definitions and acronyms
• Section 4: Project Organization - external interfaces, internal structure, roles and responsibilities
• Section 5: Management Process Plans
         Start-up Plan - estimation, staffing, training
         Work Plan - activities, schedules, budgets
         Control Plan - requirements, schedule, budget, quality, metrics
• Section 6: Technical Process Plans - process model, methods, tools, techniques, acceptance
• Section 7: Supporting Process Plans - configuration management, documentation, testing, quality assurance, reviews, etc
• Section 8: Additional Plans - anything not covered above, e.g. security, installation, maintenance

Importance of Testing

• testing important to all phases and workflows
• test plan required as part of SPMP
• test plan should describe testing process, techniques, schedule, documents
• many test documents can be prepared very early in development
• even the SPMP itself needs to be tested through inspection before finalized

Project Estimation Overview

• Most important things to estimate are cost and duration (relate to risk)
• Extremely difficult to estimate accurately
• Estimate accuracy improves exponentially the later into development it is done (no surprise)
• Decent estimate can be done near end of analysis workflow
• Affect of re-use is difficult to estimate (save by reuse but costs more to develop for future reuse)
• If you are bidding against other developers for client, estimate has to be done quickly and with little information
• Cost and duration estimates based on product size estimate
• There are a number of product size measurements
• As development progresses, refine estimate based on performance so far

Some Product Size Metrics

• lines of code (LOC) : ancient and discredited but still widely used. why?
• thousand delivered source instructions (KDSI) : how does it differ from LOC?
• function points : based on user perspective rather than developer perspective
• A number of complex formulas are computed based primarily on five counts
• number of input items (coming from data entry screen or another application)
• number of output items (sent to display screen or reports or another application)
• number of inquiries (data retrieval processes)
• number of master files (internal file data used)
• number of interfaces (external file data used)
• The counts are each weighted according to their complexity
• a technical complexity factor is determined based on the relative importance of specific quality measures (efficiency, reusability, portability, etc)
• Function Points calculated by summing the weighted counts, then applying the technical complexity factor
• "function point counting" is a pretty complicated process and the rules manual is hundreds of pages long
• although developed in the 1970s, function points methodology has been continually updated to reflect technology advances (GUI, OO, client-server, etc)
• very active community see www.ifpug.org (International Function Point Users Group).
• object oriented metrics have also been developed. I did some research in this area at JPL. Examples include
• number of classes
• number of methods
• number of subclasses
• number of overridden methods
• class reuse
• none of these metrics reflects effects and effort of maintenance; all are based on snapshot. LOC example: if product is 10K LOC and 4K of those are refactored into 2K, the result is 8K LOC (10-4+2) which does not reflect the refactoring effort

Development Cost Estimation

• Lethbridge and Lagamiere (reference above) define Principles of Effective Cost Estimation
  1. Divide and conquer
  2. Include all activities
  3. Base estimates on past experience plus knowledge of current project
  4. Account for differences when extrapolating from other projects
  5. Anticipate the worst case
  6. Combine multiple independent estimates
  7. Revise and refine estimates as work progresses
• size estimates are factored into cost, but cost does not increase linearly with size
• one approach is expert judgment by analogy, where several internal experts independently estimate cost by comparing scope of this project to scope and cost of their previous projects. Estimates are collected and distributed, then refined based on the distributed estimates. Process is repeated until consensus reached
• another approach is bottom-up where you break down project into components, estimate their cost, then sum (why might this have limited accuracy?)
• yet another approach is to develop and use an algorithmic model that takes metric measurements as input and calculates cost
• COCOMO (COnstructive COst MOdel) is a widely-used family of algorithmic cost estimation modeling techniques
• Intermediate COCOMO arrives at estimated effort by
• calculating nominal effort based on KDSI
• applying a series of development effort multipliers
• multipliers are based on the relative risk rating of 15 factors, called cost drivers
• cost drivers include things such as required reliability, resource constraints, personnel experience, languages and tools used
• COCOMO II, 2000 update of the 1980s vintage, expands COCOMO to handle additional lifecycle models and development techniques
• family of models designed to be applied at different lifecycle points, depending on the among and type of information available
• includes an application composition model applied early in analysis
• includes an early design model applied late in analysis, based on function points
• includes a postarchitectural model applied later in the lifecycle, based on function points or KDSI

Project Schedule Management

• PERT chart - (Program Evaluation and Review Technique)
  • A directed acyclic graph (DAG) of nodes and directed edges (arrows).
  • Each node represents a task, and has an associated cost (time)
  • Edges show the progression of tasks and dependencies
  • A given task cannot be started until all tasks it depends on (incoming edges) are completed
  • The critical path is the path from start to end that has the largest accumulated cost
  • A path can start at any node having no incoming edges, end at any node having no outgoing edges
  • Critical path gives estimate of duration
  • If any task on the critical path takes longer than expected, project completion will be delayed
• Gantt chart
  • A horizontal bar chart
  • Time runs along the X-axis
  • Tasks are along the Y-axis as horizontal bars
  • Each bar runs from task start time to its completion time (visual clue of time required)
  • Task cannot start until tasks it depends on are completed
  • Project duration and completion date are visible at a glance
• Both of these are useful for scheduling any kind of project