Computing and SE II Chapter 14 Software Project

Computing and SE II Chapter 14: Software Project Management Er-Yu Ding Software Institute, NJU

Main Contents 1. What is SPM (software project management)? 2. Staffing 3. Project planning 4. Software Estimation 5. Project Scheduling and Tracking 6. Risk Management

management? ---Software project management • As an engineering discipline, management is needed • Concerned with activities involved in ensuring that software is delivered – on time – within the budget – high quality (in accordance with the requirements) • Project management is needed because software development is always subject to budget and schedule constraints

1. What is software project management? ---The means of “software” • When we say software, we are not talking about programs, but about program system products • We all know all about programs, but what about program system products? • Fred Brooks explains the difference and shows the effort involved

1. What is software project management? • ---Program and Program system Program – program is complete by itself product (1) – program is ready to run by author for planned inputs on system on which it was developed, and probably under no other circumstances • Product system – each program is a component in integrated collection (system) – precisely defined interface to which all programs in system must comply – each program must stick to reasonable resources – each program is tested with other programs; number of combinations grows quadratically with each additional program

1. What is software project management? • ---Program and Program system Program Product: – product can product (2) be run, tested, repaired, extended – – – by anyone, not just author product runs on multiple platforms product accommodates many sets of data range and form of input to product must be generalized product must test for validity of input and provide response to invalid inputs must be product documentation for maintainers and users

1. What is software project management? • ---Program and. Product: system Program System Program product (3) – all attributes of program system and – all attributes of program product (multipliers may be bigger if the number of components is large)

1. What is software project management? • --- Program and Programwhen we Perhaps the key problem is that system should be thinking about program system product think about (4) product , we continue to programs, and all expectations are off by an order of magnitude. – – ease vs. difficulties, time, costs, … • We see only the program and forget all the other junk that must be added to make it a program system product !

• 1. What is software project management? ---the means of “project” Project – The objective of the project to build a program system product is to make sure that all the necessary junk gets planned in. • Projects have plans: – Resources • Multiple People • Schedule • Budget • Others – Specific work to do – Deliverables

1. What is software project management? • ---the means of “management” Any project with more than one person must be managed by definition • The job of management is to make sure that the planned junk does not get left behind in the zeal to release the software when only the program in its heart has been written! – Allocate resources properly. – Communicate and facilitate communication. – Control leads to quality.

• 1. What is software project management? General---Theories of SPM theories of management and project management can be applied to SPM • And there are some special theories for software project management – This is what we mean when we say “SPM”

1. What is software project management? • ---Elements of Software Projects Resources – Multiple People – Schedule – Budget – Others • Specific work to do – Life Cycle and Process Model • Deliverables – Artifacts pieces – Integral Product • Project Plan – Resources Plan – Specific Work Plan – Deliverables Plan

• 1. What is software project management? All activities to manage elements of Software Projects ---Broad sense SPM activities Goal: Deliver high quality product, within budget and on time.

1. What is software project management? This is the means of SPM in this SPM activities ---Narrow sense chapter • • Surrounding Project Plan – – – Project Planning Software estimation Project scheduling and tracking Risk management Staffing (optional) • Narrow sense SPM is paralleled to – Software process management – Quality management – Software configuration management • Notes: Project scope is mainly solved in Requirements Engineering

2. Staffing • People are an organisation’s most important assets. • The tasks of a manager are essentially people-oriented. Unless there is some understanding of people, management will be unsuccessful. • Poor people management is an important contributor to project “It’s always a people problem” failure.

2. Staffing ---Staffing Activities Selecting Staffs Managing Groups Motivating People Organizing Teams Arranging Work Environment

2. Staffing --- Selecting Staffs / Selecting staff • An important project management task is team selection. • Information on selection comes from: – Information provided by the candidates. – Information gained by interviewing and talking with candidates. – Recommendations and comments from other people who know or who have worked with the candidates.

2. Staffing --- Selecting Staffs / Staff selection factors 1

2. Staffing --- Selecting Staffs / Staff selection factors 2

• 2. Staffing --- Selecting Staffs / Staffing Projects do not typically have a ‘static Profile team size’ • Who and how many varies as needed Copyright: Rational Software 2002

2. Staffing --- Selecting Staffs / Roll-on & PM must have a plan as to how & when Roll-off • • Roll-on – Hiring or ‘reserving’ resources – Ramp-up time • Learning project or company • Roll-off – Knowledge transfer – Documentation – Cleanup

• 2. Staffing --- Selecting Staffs / Team The MOI Model: Leader – Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability. – Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. – Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

2. Staffing --- Selecting Staffs / Providing Leadership • Positional Power – Power derived from having a leadership position – Not always effective • Personal Power – Charisma or personal charm – Sometimes more effective than positional power

2. Staffing --- Organizing Teams/ Software Teams The following factors must be considered when selecting a software project team structure. . . • The difficulty of the problem to be solved • The size of the resultant program(s) in lines of code or function points • The time that the team will stay together (team lifetime) • The degree to which the problem can be modularized • The required quality and reliability of the system to be built • The rigidity of the delivery date • The degree of sociability (communication) required for the project

2. Staffing --- Organizing Teams/ Organizational • Closed paradigm—structures a team along a Paradigms traditional hierarchy of authority • Random paradigm—structures a team loosely and depends on individual initiative of the team members • Open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm • Synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves

2. Staffing --- Organizing Teams/ Team Structures

2. Staffing --- Arranging Work Environment / Working environments • The physical workplace provision has an important effect on individual productivity and satisfaction – – – – Room size Furniture Equipment Temperature Humidity Brightness Noise …

2. Staffing --- Arranging Work Environment / Workspace • Workspacesorganisation private should provide spaces where people can work without interruption – Providing individual offices for staff has been shown to increase productivity. • However, teams working together also require spaces where formal and informal meetings can be held. • Enough equipment supplied to support team work

2. Staffing --- Arranging Work Environment / Office layout

2. Staffing ---Motivating People • An important role of a manager is to motivate the people working on a project. • Motivation is a complex issue but it appears that their are different types of motivation factors • People go to work because they are motivated by the people that they work with.

2. Staffing ---Motivating People / Motivation Factors

2. Staffing • • • ---Motivating People / Avoid Team A frenzied work atmosphere in which team members “Toxicity” waste energy and lose focus on the objectives of the work to be performed. High frustration caused by personal, business, or technological factors that cause friction among team members. “Fragmented or poorly coordinated procedures” or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment. Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing. “Continuous and repeated exposure to failure” that leads to a loss of confidence and a lowering of morale.

2. Staffing ---Managing groups • Most software engineering is a group activity – The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone. • “Schedule disaster, functional misfit and system bugs all arise because the left hand does not know what the right hand is doing” • Teams working on a project must communicate with one another in as many ways as possible: informally, regular project

2. Staffing ---Managing groups / Group communications • Good communications are essential for effective group working. • Information must be exchanged on the status of work, design decisions and changes to previous decisions. • Good communications also strengthens group cohesion as it promotes understanding.

3. 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 • Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget

3. Project planning ---Types of project plan

3. Project planning --- Project planning process

3. Project planning --- Project plan structure Introduction Project organisation Risk analysis Hardware and software resource requirements • Work breakdown • Project schedule • Monitoring and reporting mechanisms • •

3. Project planning --- Plan Contents Project Scope Estimates Risks Schedule Software Project Plan

4. Software Estimation • Estimation of resources, cost, and schedule for a software engineering effort requires – experience – access to good historical information (metrics – the courage to commit to quantitative predictions when qualitative information is all that exists • Estimation carries inherent risk and this risk leads to uncertainty

4. Software Estimation --- Creating an Estimate… • Estimating the Software Development Effort Cost – Estimating Size Estimation Technique – Productivity factors Efforts

4. Software Estimation --- Estimating Size • Three main factors 1. Units of measure • LOC: Lines Of Code • FP: Function Points 2. Software included in the measurement 3. Amount of reused code • Reused code is generally counted differently than newly written code • Must track code Added, Changed and Deleted from the reused code

• 4. Software Estimation --- Units of Measure / Lines of The lower level the language, the more code productive the programmer – The same functionality takes more code to implement in a lower-level language than in a high-level language • The more verbose the programmer, the higher the productivity – Measures of productivity based on lines of code suggest that programmers who write verbose code are more productive than programmers who write compact code

4. Software Estimation --- Units of Measure / Function • Based on a combination of program points characteristics – – external inputs and outputs user interactions external interfaces files used by the system • A weight is associated with each of these • The function point count is computed by multiplying each raw count by the weight and summing all values

4. Software Estimation --- Units of Measure / Lines of code VS function points • Function point count modified by complexity of the project • FPs can be used to estimate LOC depending on the average number of LOC per FP for a given language – LOC = AVC * number of function points – AVC is a language-dependent factor varying from 200 -300 for assemble language to 2 -40 for a 4 GL • FPs are very subjective. They depend on the estimator. – Automatic function-point counting is impossible

4. Software Estimation --- Units of Measure / Lines of code VS function points • Lines of code – Developers’ technical view – If have enough details, lines of code are more accurate • The most accurate estimation is lines of code when projects finished • Function points – Users’ functional view – In the initial phase, function points are more appropriate than lines of code when only high-level characteristics available

4. Software Estimation --- Productivity Factors • A measure of the rate at which individual engineers involved in software development produce software and associated documentation • Not quality-oriented although quality assurance is a factor in productivity assessment • Essentially, we want to measure useful

4. Software Estimation --- Productivity Factors / 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

4. Software Estimation --- Productivity Factors / Factors affecting productivity

4. Software Estimation --- Cost estimation techniques

4. Software Estimation --- Cost estimation techniques / Expert • One or morejudgementboth software experts in development and the application domain use their experience to predict software costs. Process iterates until some consensus is reached. • Advantages: Relatively cheap estimation method. Can be accurate if experts have direct experience of similar systems • Disadvantages: Very inaccurate if

4. Software Estimation --- Cost estimation techniques / • The cost. Estimation by is computed by of a project analogy comparing the project to a similar project in the same application domain • Advantages: Accurate if project data available • Disadvantages: Impossible if no comparable project has been tackled. Needs systematically maintained cost

4. Software Estimation --- Cost estimation techniques / Parkinson's Law • The project costs whatever resources are available. The cost is determined by available resources rather than by objective assessment. If the software has to be delivered in 12 months and five people are available, the effort required is estimated to be 60 personmonths • Advantages: No overspend

4. Software Estimation --- Cost estimation techniques / Pricing to win • The project costs whatever the customer has to spend on it • Advantages: You get the contract • Disadvantages: The probability that the customer gets the system he or she wants is small. Costs do not accurately reflect the work required

4. Software Estimation --- Cost estimation techniques / Algorithmic cost modelling • A formulaic approach based on historical cost information and which is generally based on the size of the software • Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers

4. Software Estimation --- Cost estimation techniques / Algorithmic cost modelling • Conventional Methods – Efforts = Size / Productivity • Process-Based Estimation – Step 1: Identify the tasks • Tasks are recorded in a Work Breakdown Structure (WBS) – Step 2: Estimate the efforts required per task – Step 3: Efforts = ∑(effort per task) • Estimation with Use-Cases – Steps 1: Separating use cases into different kinds of groups – Step 2: Estimate the sizes for each group – Step 3: Efforts = ∑(size per group) / Productivity • Empirical Estimation Models

4. Software Estimation --- Algorithmic cost modelling / Conventional Methods Example: LOC Approach Average productivity for systems of this type = 620 LOC/pm. Burdened labor rate =$8000 per month, the cost per line of code is approximately $13. Based on the LOC estimate and the historical productivity data, the total estimated project cost is $431, 000 and the estimated effort is 54 person-months.

4. Software Estimation --- Algorithmic cost modelling / Conventional Methods Example: FP Approach The estimated number of FP is derived: FPestimated = count-total × [0. 65 + 0. 01 × ∑ (Fi)] FPestimated = 375 organizational average productivity = 6. 5 FP/pm. burdened labor rate = $8000 per month, the cost per FP is approximately $1230. Based on the FP estimate and the historical productivity data, the total estimated project cost is $461, 000 and the estimated effort is 58 person-months.

4. Software Estimation --- Algorithmic cost modelling / Process-Based Estimation Based on an average burdened labor rate of $8, 000 per month, the total estimated project cost is $368, 000 and the estimated effort is 46 person-months.

4. Software Estimation --- Algorithmic cost modelling / Estimation with Use-Cases Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the use-case estimate and the historical productivity data, the total estimated project cost is $552, 000 and the estimated effort is 68 person-months.

4. Software Estimation --- Cost estimation techniques / Empirical Estimation Models

4. Software Estimation --- Cost estimation techniques / Empirical • COCOMO IIEstimation Models is actually a hierarchy of estimation models that address the following areas: • Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount. • Early design stage model. Used once requirements have been stabilized and basic software architecture has been established. • Post-architecture-stage model. Used during the construction of the software.

4. Software Estimation --- COCOMO-II • Algorithmic methods – Effort = f(x 1, x 2, …, xn) – where {x 1, x 2, …, xn} denote the cost factors. • Linear models • Power function models – S=Size(x 1, x 2, …, xn) • Multiplicative models

4. Software Estimation --- COCOMO-II / Cost factors • Product factors: required reliability; product complexity; database size used; required reusability; documentation match to life-cycle needs; • Computer factors: execution time constraint; main storage constraint; computer turnaround constraints; platform volatility; • Personnel factors: analyst capability; application experience; programming capability; platform experience; language and tool experience; personnel continuity; • Project factors: multisite development; use of software tool; required development

4. Software Estimation --- The Make-Buy Decision

4. Software Estimation --- Computing Expected Cost expected cost = (path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost build = 0. 30 ($380 K) + 0. 70 ($450 K) = $429 K similarly, expected cost = $382 K reuse expected cost buy = $267 K expected cost contr = $410 K

4. Software Estimation --- Estimation accuracy • The size of a software system can only be known accurately when it is finished • Several factors influence the final size – Use of “off the shelf” components – Programming language – Distribution of system • As the development process progresses then the size estimate becomes more accurate

4. Software Estimation --- Estimate uncertainty: As the project progresses the probablilty of a difference in actual to estimate decreases Actual personmonths x = estimated person-months

5. Project Scheduling and Tracking ---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.

5. Project Scheduling and Tracking --- The project scheduling principles (Process) • • • compartmentalization—define distinct tasks interdependency—indicate task interrelationship effort validation—be sure resources are available defined responsibilities—people must be assigned defined outcomes—each task must have an output defined milestones—review for quality

5. Project Scheduling and Tracking --- Bar charts and activity networks • Graphical notations used to illustrate the project schedule. • 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.

5. Project Scheduling and Tracking --- Task durations and dependencies

5. Project Scheduling and Tracking --- Activity network

5. Project Scheduling and Tracking --- Activity timeline

5. Project Scheduling and Tracking --- Staff allocation

5. Project Scheduling and Tracking ---Effort Allocation • “front end” activities 40 -50% 15 -20% – customer communication – analysis – design – review and modification • construction activities 30 -40% – coding or code generation • testing and installation

• • • 5. Project Scheduling and Tracking conduct periodic project status meetings in ---Schedule Tracking which each team member reports progress and problems. evaluate the results of all reviews conducted throughout the software engineering process. determine whether formal project milestones (diamonds in previous slide) have been accomplished by the scheduled date. compare actual start-date to planned start-date for each project task listed in the resource table meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon.

6. Risk Management --- Risk & Uncertainty • A risk is: “an uncertain event or condition that, if it occurs, will have a positive or negative effect on a project objective” • Uncertainty = lack of knowledge about future events • Risk = uncertainty that matters

6. Risk Management --- Reactive Risk Management • Project team reacts to risks when they occur • Mitigation—plan for additional resources in anticipation of fire fighting • Fix on failure—resource are found applied when the risk strikes • Crisis management—failure does not respond to applied resources and

6. Risk Management --- Proactive Risk Management • formal risk analysis is performed • organization corrects the root causes of risk control track RISK plan analyze identify

6. Risk Management • • --- associated. Identification software to be Risk with the overall size of the Product size—risks built or modified. Business impact—risks associated with constraints imposed by management or the marketplace. Customer characteristics—risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. Process definition—risks associated with the degree to which the software process has been defined and is followed by the development organization. Development environment—risks associated with the availability and quality of the tools to be used to build the product. Technology to be built—risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system. Staff size and experience—risks associated with the overall technical and project experience of the software engineers who will do the work.

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

6. Risk Management --- Risk analysis / Risk Projection • Risk projection, also called risk estimation, attempts to rate each risk in two ways – the likelihood or probability that the risk is real – the consequences of the problems associated with the risk, should it occur. • The are four risk projection steps: – establish a scale that reflects the perceived likelihood of a risk – delineate the consequences of the risk – estimate the impact of the risk on the project and the product, – note the overall accuracy of the risk projection so that there will be no misunderstandings.

6. Risk Management --- Risk analysis: An example

6. Risk Management --- 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;

6. Risk Management --- Risk planning / Recording Risk Information Project: Embedded software for XYZ system Risk type: schedule risk Priority (1 low. . . 5 critical): 4 Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component delivery may be delayed Probability: 60 % Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testing Monitoring approach: Scheduled milestone reviews with hardware group Contingency plan: Modification of testing strategy to accommodate delay using software simulation Estimated resources: 6 additional person months beginning 7 -1 -96

6. Risk Management --- Risk tracking and controlling • 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.

Conclusions 1. What is SPM (software project management)? 2. Staffing 3. Project planning 4. Software Estimation 5. Project Scheduling and Tracking 6. Risk Management

The End • Recommend paper – 《software project management》 • Next Lecture – Software Process Management