Project, People, Processes and Products

• Project management skills – schedule, monitoring, risk management, …

• People management skills – delegation, mentoring, staffing, promoting, evaluating, training, …

• Process management skills – life cycle model processes and deliverables

• Product management skills – quality control, metrics, …

Top 10 reasons why projects fail

• Inadequately trained and/or inexperienced project managers

• Failure to set and manage expectations

• Poor leadership at any and all levels

• Failure to adequately identify, document and track requirements

• Poor plans and planning processes

• Poor effort estimation

• Cultural and ethical misalignment

• Misalignment between project team and business it serves

• Inadequate or misused methods

• Inadequate communication, including progress tracking and reporting

Estimation techniques

• Estimation during project startup

• Time and effort to be included in initial project schedule

• Avoid overestimation or underestimation

• Micro level and macro level estimation

– Macro level: not detailed, based on Kilo line of code

– Micro level: detailed, more accurate,

Estimation techniques

• Requirements level estimation – black-box, high level

– Function point, feature point, use case point

• Implementation level estimation – white box, low level based on code

– COCOMO

Empirical estimation models Effort (person-month)

• E = (a + (b x Sizec )) x F

– a, b and c are model coefficients that are empirically obtained,

– Size is the estimated size of the project in KLOC

– F is a product of factors influencing project estimates.

• In the Bailey-Basili model:

E = (5.5 + (0.73 x Size1.16) x F

– The same general equation is also used to estimate the effort for projects where the Size is estimated in terms of function points needed.

• In Kemerer model: E = (-37 + 0.96 x Size) x F

– F depends on project complexity factors.

– Size = function points

Function point metrics • Complexity of software and the effort needed to develop it are a

function of the number and type of five different kinds of functional components that can be obtained and assessed at the requirements specifications phase.

– internal files (IF) corresponding to the database files that are created and maintained within the application to develop.

– external files (EF) corresponding to the files owned and maintained by other applications, but are used by the application to develop.

– external inputs (EI) corresponding to the inputs that affect the control flow and internal logic of the application leading to the creation and maintenance of data.

– external outputs (EO) corresponding to the data leaving the application to different output devices, files or external systems.

– external inquiries (EIQ) corresponding to simple user queries.

Example 10.1

• Suppose the software to develop has 1 EIs, 3 EOs, and 1 UI, all of simple complexities, the number of unadjusted function points (UFP) would then be 3*1+4*3+3*1 = 18.

• In addition, it has 2 Eis and 1 UI of average complexity, and 1 EI, 1 EO, 1 IF and 3 EF of high complexity.

• Similar computations should be performed for the remaining average and complex components.

• The total number of UFPs is: (3*1+4*3+3*1) + (4*2+4*1) + (6*1+7*1+15*3+10*1) = 98 UFPs.

A rating from 0 to 5 is assigned to each factor.

Their sum is computed to obtain a value for S.

Computing the adjusted function points (AFP)

• The overall complexity factor F is then computed using the equation:

CF = 0.65 + 0.01 x S

– CF will be within the range 0.65 to 1.35.

– The number of adjusted function points (AFP) is

UFP x CF

Reconciling estimations

• Another approach the manager can take to reduce the risk of underestimation is to produce estimates using different techniques and performed by different experts. Differences between the estimated efforts can then be reconciled using statistical analysis techniques.

• For example, if the three estimates, ELow, EHigh and EMid are obtained, such that ELow < EMid < EHigh, the value for E that can be used is computed using the equation:

E = (ELow + 4 x EMid + EHigh) / 6

Mapping AFP to Effort

• m = f 3*j / 27 person-months.

• j depends on the type of the software application involved and the capabilities and expertise of the development team and varies from 0.39 to 0.48.

• In Example 10.1, if we consider j = 0.43, the number of person-months would be 13.71

• Average number of LOC per function point in the C and Java are 162 and 63, respectively

• In Example 10.1, the estimated number of lines would be about 15 KLOC of C code or 6 KLOC of Java code.

FP estimation excel sheet

<<FP sheet>>

Assumptions:

Effort exponent is 0.43

Cost per day is 400 $

20 working day per month

65 Java lines of code per AFP

Use case point (UCP) estimation

• By Kamer in 1993 – an extension of FP method based on UCM.

• Based on steps or transactions in a Use Case

• Unadjusted Actor Weight (UAW), Unadjusted Use Case Weight (UUCW)

• Unadjusted Use Case Point UUCP = UAW + UUCW

• Adjusted UCP AUCP = UUCP x TCF x ENVF

TCF = 0.6 + 0.01 x TF , TF is sum of

weighted values

EF = 1.4 – 0.03 x ENVF , ENVF is sum of

all weighed values

Computing the effort

• 25 person-hours per AUCP

• Use case PlaceOrder: complex use case, 3 actors: buyer is complex and warehouse and accounting are simple

• UAW = 5, UUCW = 15, UUCP = 20

• TF = 38.5, TCF = 0.985, ENVF = 21.5, EF = 0.755

• AUCP = 20 x 0.985 x 0.75 = 14.87

• Effort is (14.87 x 25) / 7hrs/day = 53.11 days

UCP estimation excel sheet

<<UCP Sheet>>

Assumptions:

Person-Hours per AUCP is 25

7 hours of work per day

400 $ per day

Risk Management • One main reason for project failure: inability to deal

adequately with anticipated or unanticipated problem

• Ideally all risks must be anticipated by manager

• Software risk: a problem occurring during the development of the software and the consequence of that problem.

• Continuous process: Risk engineering cycle

• Aim: make timely and informed decisions and take appropriate risk control actions to deal with the risk

– Prevention, detection, response

Scheduling and tracking projects

• Schedule is influenced by available resources and estimations

• Tracking project progress to avoid delays and take timely necessary actions

• To manage and track a large project, the project manager needs to divide the project work into related tasks.

• Tasks need to be structured around the phases of the life cycle model adopted by the development company.

Representing project tasks

• The tasks of a project can be summarized in both a tabular or graphical form.

• A typical template for the tabular representation of a project schedule includes one row per task.

• Columns correspond to the attributes of the task including the task id, task name, duration, start date, finish date, and the predecessor task(s) if any.

• A task whose duration is 0 day is called a milestone task. It is used to represent the termination of a phase or a group of tasks in the project schedule.

Task network • A graphical representation of a project schedule.

• Composed of nodes and directed arcs joining them.

• A node represents a task and includes its name and its duration.

• A directed arc between two nodes represents the dependency of the sink node or task on the completion of the start node or task.

• The task represented by the sink node cannot start until all the predecessor tasks have successfully terminated.

• Initial tasks are represented by nodes with no incoming edges.

Final tasks are represented by nodes with no outgoing edges.

Task network

• The project length is the duration in days of the longest path in the task network, the length of the project critical path.

• Given the available resources, including human and other system resources, and the tasks dependencies between the tasks the manager must exploit the concurrent execution of tasks to its fullest.

• The concurrent execution of tasks leads to better resource utilization and to shorter project length.

Example

• A project schedule table composed of 9 tasks including a milestone task.

• Task A is the initial task, task H is the final

• A critical path (CP) on the task network is the longest duration path from start to finish.

• A task network may have more than one CP all having the same total duration. A task that is included in a CP is called a critical task. Any delay in the completion of a critical task leads to a delay in the project termination.