1. Software Engineering
Project Management

2. Software project management
Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software

3. The Aim of Project Management
To complete a project:
• On time
• On budget
• With required functionality
• To the satisfaction of the client
• Without exhausting the team

4. Planning
Inadequate planning leads to frustration towards the end of the project & poor project performance
Project Start
Project End

5. Triple Contraint
Time
Software
Cost
Quality

6. Management tasks “Plan the work and work the plan” Planning Organizing
Staffing
Directing
Controlling
… and dealing with deviations from the plan
“Plan the work and work the plan”

7. 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
there is an international shortage of skilled IT staff

8. Software is Built by Teams
• Best size for a team is 3 to 8 people
• Team members may include:
developers (from trainee to expert)
domain experts
graphic or interface designers
software librarians
testers
• Teams must have:
administrative leadership (manager)
technical leadership

9. Time distribution

10. Office layout

14. Human needs hierarchy

18. Team structure
management structure
communication pattern

19. Team structure
management structure
communication pattern

22. Personality types Task-oriented. Self-oriented. Interaction-oriented
The motivation for doing the work is the work itself;
Self-oriented.
The work is a means to an end which is the achievement of individual goals - e.g. to get rich, to play tennis, to travel etc.;
Interaction-oriented
The principal motivation is the presence and actions of co-workers. People go to work because they like to go to work.

23. Software Business Questions
• You are employed for company X writing software. When you leave, who owns your work? What use can you make of the work?
• You work free-lance for company X. When you finish, who owns your work? What use can you make of the work?
• You are a student on CS What you finish what use can you make of your project work? What use can University make of it?
Read the contract!

24. Project scheduling

25. Project scheduling / Project planning
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
Dependent on project managers intuition and experience

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
Adding people to a late project makes it later because of communication overheads
The unexpected always happens. Always allow contingency in planning

27. Task durations and dependencies

28. Activity network

29. Staff allocation

30. Example: a compiler project

31. Example: a compiler project

32. Activity bar chart

33. Staff allocation chart

34. Risk management

35. Risk management
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
Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project.

36. Software risks

37. The risk management process

38. 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

39. Risk identification Examples of different risk types
Possible risks
Technology
The database used in the system cannot process as many transactions per second as expected. (1)
Reusable software components contain defects that mean they cannot be reused as planned. (2)
People
It is impossible to recruit staff with the skills required. (3)
Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)
Organizational
The organization is restructured so that different management are responsible for the project. (6)
Organizational financial problems force reductions in the project budget. (7)
Tools
The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)
Requirements
Changes to requirements that require major design rework are proposed. (10)
Customers fail to understand the impact of requirements changes. (11)
Estimation
The time required to develop the software is underestimated. (12)
The rate of defect repair is underestimated. (13)
The size of the software is underestimated. (14)

40. Risk analysis Assess probability and seriousness of each risk
Probability may be very low, low, moderate, high or very high
Risk effects might be catastrophic, serious, tolerable or insignificant

41. Risk types and examples
Probability
Effects
Organizational financial problems force reductions in the project budget (7).
Low
Catastrophic
It is impossible to recruit staff with the skills required for the project (3).
High
Key staff are ill at critical times in the project (4).
Moderate
Serious
Faults in reusable software components have to be repaired before these components are reused. (2).
Changes to requirements that require major design rework are proposed (10).
The organization is restructured so that different management are responsible for the project (6).
The database used in the system cannot process as many transactions per second as expected (1).

42. Risk types and examples
Probability
Effects
The time required to develop the software is underestimated (12).
High
Serious
Software tools cannot be integrated (9).
Tolerable
Customers fail to understand the impact of requirements changes (11).
Moderate
Required training for staff is not available (5).
The rate of defect repair is underestimated (13).
The size of the software is underestimated (14).
Code generated by code generation tools is inefficient (8).
Insignificant

43. Risk planning
Consider each risk and develop a strategy to manage that risk
Avoidance strategies
The probability that the risk will arise is reduced
Minimisation strategies
The impact of the risk on the project or product will be reduced
Contingency plans
If the risk arises, contingency plans are plans to deal with that risk

44. Risk monitoring
Assess each identified risks regularly to decide whether or not it is becoming less or more probable
Also assess whether the effects of the risk have changed
Each key risk should be discussed at management progress meetings

45. Risk indicators Risk type Potential indicators Technology
Late delivery of hardware or support software; many reported technology problems.
People
Poor staff morale; poor relationships amongst team members; high staff turnover.
Organizational
Organizational gossip; lack of action by senior management.
Tools
Reluctance by team members to use tools; complaints about CASE tools; demands for higher-powered workstations.
Requirements
Many requirements change requests; customer complaints.
Estimation
Failure to meet agreed schedule; failure to clear reported defects.

46. Feasibility Study
Before beginning a project, a short, low-cost study to identify
• Client
• Scope
• Potential benefits
• Resources needed:
staff, time, equipment, etc.
• Potential obstacles
Where are the risks? How can they be minimized?

47. Scope What are the boundaries of the project? Examples:
• Static web pages with open access on the Web [Web Profiler]
• Used by the general public [Digital Collections]
• Varying data formats [Legal Information]
• Thousands of sensors [Data mining]
• Support for Windows, Mac, Unix [SALSA]

48. Potential Benefits Why are you doing this project? Examples
• Create a marketable product
• Improve the efficiency of an organization
• Control a system that is too complex to control manually
• New or improved service
• Safety or security

49. Resources
Examples:
Staff: 5 to 7 students, with some help. How many hours per week? What skills do people have?
Time: Must be completed by end of semester, including operational system, documentation, presentation
Equipment and software: What special needs are there?
Client: Will the client be sufficiently available and helpful?

50. Feasibility Report A written document
• For a general audience: client, financial management,
technical management, etc.
• Short enough that everybody reads it
• Long enough that no important topics are skipped
Looking for a well written, well presented document.

51. Failure to Cancel a Project
Example: University F developed a novel programming language.
• From 1985 to 1989, this was a promising language for simple programming of window-based applications
• By 1990, clearly not gaining acceptance beyond University F
• But development continued for many more years (about $500K)
Not cancelled because ...

52. Too Big to Cancel!
Example: University A has antiquated administrative systems. Senior management decides to replace them all with commercial packages from X. The timetable and budget are hopelessly optimistic.
• Staff get dispirited.
• The Chief Information Officer finds another job.
• A new Chief Information Officer is appointed.
What should she do?

53. We are doing it the Wrong Way!
Example: University B has a (big) joint project with Company Y to develop a new computer operating system.
After two years work, a junior software developer persuades the university leader that the technical approach is wrong.
• What should the university do?
• What should the company do?

54. How to Stop Gracefully
• It is harder to cancel a project than to start it.
• It is harder to withdraw a service than introduce it.
Considerations
• The proponents of the system must now reverse their public stance.
=> Management of expectations
• Users of the service need a migration strategy.
• Technical staff must have a graceful path forward.

55. Time to Complete a Software Project
Large software projects typically take at least two years from start to finish
• Formative phase -- changes of plan are easy to accommodate
• Implementation phase -- fundamental changes are almost impossible
Yet many things can change in two years.

56. Changing Requirements and Design
Example: The CNRI Handle System -- a high performance, distributed system to map names to resources ( ).
• In 1994 only web browser was Mosaic
• In 1994 Java did not exists
• In 1994 mirroring and caching utilities were not available
• In 1994 commercial interest was limited
Design decisions made in 1994 had to be changed. Software was rewritten and greatly improved in 1998/9.
If a job's worth doing, it's worth doing twice!

57. Changes of Leadership
Many projects are wasted because of management changes
Example: In 1988, Company W gave University D $1,000,000 to port a new operating system to its personal computers. The work was well done, on time.
• Company W changed its president and senior technical staff during the project. The work was wasted.
• A decade later and several presidents later, Company W is releasing a modern version of the same operating system.

58. Case study: Nokia software factories
Geographically distributed environment
typical project: 100 developers working in three to four sites
synchronous work not possible (differences in time zones)
Product family architecture
architecture developed for an entire family, and components developed to be used in all family members
Concurrent engineering
components developed concurrently at different sites, retrieved from the various sites and combined in a central location
Use of tools
process is tool supported (for requirements engineering, design, coding, version management, configuration management, and testing)

59. Cost estimation

60. Cost estimation
We need predictive methods to estimate the complexity of software before it has been developed
predict size of the software
use it as input for deriving the required effort

61. Typical cost driver categories
Product
e.g., reliability requirements or inherent complexity
Computer
e.g., are there execution time or storage constraints?
Personnel
e.g., are the personnel experienced in the application area or the programming language being used?
Project
e.g., are sophisticated software tools being used?

62. Productivity measures
Size related measures based on some output from the software process. This may be lines of delivered source code, object code instructions, etc.
Function-related measures based on an estimate of the functionality of the delivered software. Function-points are the best known of this type of measure.

63. A byproduct
Function points used to measure the relative power of different languages
compute number of source lines required to code a function point
numbers range from 320 (assembler languages), 128 (C), 91 (Pascal), 71 (Ada83), 53 (C++, Java), 6 (“spreadsheet languages”)

64. System development times

65. Algorithmic cost modelling
Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers:
Effort = A ´ SizeB ´ M
A is an organisation-dependent constant, B reflects the disproportionate effort for large projects and M is a multiplier reflecting product, process and people attributes.
The most commonly used product attribute for cost estimation is code size.
Most models are similar but they use different values for A, B and M.

66. Generic formula for effort
PM = c.KLOCk
Legend
PM: person month
KLOC: K lines of code
c, k depend on the model
k>1 (non-linear growth)
Initial estimate then calibrated using a number
of "cost drivers"

67. COCOMO Size estimate based on delivered source instructions, KDSI
Categorizes the software as:
organic
semidetached
embedded
each has an associated formula for nominal development effort based on estimated code size

68. COCOMO nominal effort and schedule equations

69. COCOMO 81

70. COCOMO 2
COCOMO 81 was developed with the assumption that a waterfall process would be used and that all software would be developed from scratch.
Since its formulation, there have been many changes in software engineering practice and COCOMO 2 is designed to accommodate different approaches to software development.

71. COCOMO 2 models
COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates.
The sub-models in COCOMO 2 are:
Application composition model. Used when software is composed from existing parts.
Early design model. Used when requirements are available but design has not yet started.
Reuse model. Used to compute the effort of integrating reusable components.
Post-architecture model. Used once the system architecture has been designed and more information about the system is available.

72. Use of COCOMO 2 models

73. Application composition model
Supports prototyping projects and projects where there is extensive reuse.
Based on standard estimates of developer productivity in application (object) points/month.
Takes CASE tool use into account.
Formula is
PM = ( NAP ´ (1 - %reuse/100 ) ) / PROD
PM is the effort in person-months, NAP is the number of application points and PROD is the productivity.

74. Object point productivity