Software Engineering Project Management

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

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

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

Triple Contraint Time Software Cost Quality

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”

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

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

Time distribution

Office layout

Human needs hierarchy

Team structure management structure communication pattern

Team structure management structure communication pattern

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.

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 502. What you finish what use can you make of your project work? What use can University make of it? Read the contract!

Project scheduling

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

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

Task durations and dependencies

Activity network

Staff allocation

Example: a compiler project

Example: a compiler project

Activity bar chart

Staff allocation chart

Risk management

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.

Software risks

The risk management process

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

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)

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

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

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

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

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

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.

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?

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]

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

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?

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.

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

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?

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?

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.

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.

Changing Requirements and Design Example: The CNRI Handle System -- a high performance, distributed system to map names to resources (1994-99). • 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!

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.

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)

Cost estimation

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

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?

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.

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”)

System development times

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.

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"

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

COCOMO nominal effort and schedule equations

COCOMO 81

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.

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.

Use of COCOMO 2 models

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.

Object point productivity