410 likes | 614 Views
Topics covered. Management activitiesProject planningProject schedulingRisk management. The product is intangible.The product is uniquely flexible.The software development process is not standardised.Many projects are 'one-off'.. Project management challenges. Project planning. Probably th
E N D
1. Project management
2. Topics covered Management activities
Project planning
Project scheduling
Risk management
3. The product is intangible.
The product is uniquely flexible.
The software development process is not standardised.
Many projects are 'one-off'. Project management challenges
4. Project planning Probably the most time-consuming project management activity.
Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available.
5. The project plan The project plan sets out to map:
The work breakdown
The resources available to the project
Cost estimation
A schedule for the work
6. Cost Estimation
7. Problem Our ability to realistically plan and schedule projects depends on our ability to estimate project costs and development efforts
In order to come up with a reliable cost estimate, we need to have a firm grasp on the requirements, as well as our approach to meeting them
Typically costs need to be estimated before these are fully understood
8. Estimating uncertainty Boehm 1981
9. What are project costs?
For most software projects, costs are:
Hardware Costs
Travel & Training costs
Effort costs
10. What are effort costs? Effort costs typically largest of the 3 types of costs, and the most difficult to estimate.
Effort costs include:
Developer hours
Heating, power, space
Support staff; accountants, administrators, cleaners, management
Networking and communication infrastructure
Central facilities such as rec room & library
Social security and employee benefits
11. Effort cost estimation - Overhead Effort costs
Developer time (salaries)
All the other stuff
All the other stuff costs aprox. the same as the developer time!
12. Effort cost estimation - Overhead OSU example:
45% for benefits
46% for “indirect” costs (space, infrastructure etc) calculated on top of everything else
$1,000 +benefits ($450) + infrastructure ($667)
= $2,117
13. Determining software cost Boehm (1981) Algorithmic cost modeling
Base estimate on project size (lines of code)
Expert judgment
Ask others
Estimation by analogy
Cost based on experience with similar projects
Parkinson’s Law
Project time will expand to fill time available
Pricing to win
Cost will be whatever customer is willing to pay
Top-down estimation
Estimation based on function/object points
Bottom-up estimation
Estimation based on components
14. Aggravating & mitigating factors Market opportunity
Uncertainty/risks
Contractual terms
Requirements volatility
Financial health
Opportunity costs
15. Cost drivers Software reliability
Size of application database
Complexity
Analyst capability
Software engineering capability
Applications experience
Virtual machine experience
Programming language expertise Performance requirements
Memory constraints
Volatility of virtual machine
Environment
Turnaround time
Use of software tools
Application of software engineering methods
Required development schedule
16. Project staffing May not be possible to appoint the ideal people to work on a project
Project budget may not allow for the use of highly-paid staff
Staff with the appropriate experience may not be available
An organisation may wish to develop employee skills on a software project.
Managers have to work within these constraints especially when there are shortages of trained staff.
17. Metrics Lines of code
Simple, but not very meaningful metric
Easy to pad, affected by prog language
How to count revisions/debugging etc?
Function points
Amount of useful code produced (goals/requirements met)
Less volatile, more meaningful, not perfect
Object points
Number of artifacts that need to be produced
Less detailed, requires less work to estimate, but more appropriate for some types of applications
18. Function points Function points are computed by first calculating an unadjusted function point count (UFC). Counts are made for the following categories (Fenton, 1997):
External inputs – those items provided by the user that describe distinct application-oriented data (such as file names and menu selections)
External outputs – those items provided to the user that generate distinct application-oriented data (such as reports and messages, rather than the individual components of these)
External inquiries – interactive inputs requiring a response
External files – machine-readable interfaces to other systems
Internal files – logical master files in the system
Each of these is then assessed for complexity and given a weighting from 3 (for simple external inputs) to 15 (for complex internal files).
19. Unadjusted Function Point Count (UFC)
20. Function points -> Lines of code 200-300 LOC/Function point in assembly
Multiplication factor by language
Programmer productivity?
30-900 LOC/month!
21. Basic cost models
22. Object points Similar to function points (used to estimate projects based heavily on reuse, scripting and adaptation of existing tools)
Number of screens (simple x1, complex x2, difficult x3)
Number of reports (simple x2, complex x5, difficult x8)
Number of custom modules written in languages like Java/C x10
23. Object point estimation
PM = (object points x(1-%reuse/100)/ productivity
Productivity estimates from 4-50 object points/month, depending on experience and the availability/maturity of tools
24. Project Scheduling
25. Project scheduling Split project into tasks and estimate time and resources required to complete each task.
Organize tasks concurrently to make optimal use of workforce.
Minimize task dependencies to avoid delays caused by one task waiting for another to complete.
26. Scheduling problems Estimating the difficulty of problems and hence the cost of developing a solution is hard.
Productivity is not proportional to the number of people working on a task.
The unexpected always happens. Always allow contingency in planning.
27. Activity vocabulary Activities in a project should be organised to produce tangible outputs for management to judge progress.
Milestones are the end-point of a process activity.
Deliverables are project results delivered to customers.
28. Bar charts and activity networks Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two.
Activity charts show task dependencies and the critical path.
Bar charts show schedule against calendar time.
29. Task durations and dependencies
30. Activity network
31. Activity timeline
32. Risk Management
33. Risk management Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project.
A risk is a probability that some adverse circumstance will occur
Project risks affect schedule or resources;
Product risks affect the quality or performance of the software being developed;
Business risks affect the organisation developing or procuring the software.
34. The risk management process Risk identification
Identify project, product and business risks;
Risk analysis
Assess the likelihood and consequences of these risks;
Risk planning
Draw up plans to avoid or minimise the effects of the risk;
Risk monitoring
Monitor the risks throughout the project;
35. Uncertainty Sources Requirements
Match (UI/interface)
Changing Environment
Resources
Management (support & talent)
Supply Chain
Politics
Conflict
Innovation
Scale
36. Risk Management How much risk to take
Return on investment = value-cost/cost
Need for specificity in calculating these?
What are the difficulties in specifying costs, benefits, value, and to whom?
37. Risk Vocabulary What is risk management vs. Crisis management?
Show stoppers! (project assumptions)
What is Mitigation?
What is a transition indicator?
38. What is risk management? Risk discovery
Exposure analysis (probability * cost/damages)
Contingency planning
Mitigation
Ongoing transition monitoring
39. Core Risks 1 inherent scheduling flaw
2 Requirements inflation
3 Employee turnover
4 Specifications breakdown
5 Poor productivity
40. Risk Management Strategies Risks can be
avoided
contained
mitigated
evaded
ignored
41. Ignoring Risks Risks to ignore:
1 Probability is just very small
2 Effect makes product irrelevant
3 Minimal consequence
4 Someone else’s risk
42. Risk Analysis Estimating project completion
The Nano-percent date
Risk Exposure
Cost x Probability