Formalizing the Project Goals

(1)

1/13

Prof. Moheb Ramzy Girgis

Department of Computer Science Faculty of Science

Minia University

Software Project Management

3. Creating The Project Plan – Part I

Software Project Management - Prof. Moheb Ramzy Girgis Dept. of Computer Science - Faculty of

Science Minia University

Introduction

 Once the project is launched by being selected by the approval committee, it is time to carefully plan the project.

 The project manager will follow a set of project

management guidelines, sometimes referred to as the project management life cycle, as he/she organizes, guides, and directs the project from inception to completion.

 Generally speaking, the project management phases consist of initiation, planning, execution, control, and closure.

 The project manager must make a myriad of decisions regarding the project, including determining the best project methodology, developing a work plan for the project, determining a staffing plan, and establishing mechanisms to coordinate and control the project.

(2)

2/13

 Defining the project goals (project scope) is one of the first and most important activities in a project.

 The project scope:

 Ensures that the project includes all and only the work necessary.

 Establishes a baseline of the work to be performed.

 Defines a reference document for project acceptance.

 The definition of the project scope starts during the feasibility study.

 The project goals and the alignment of a project with its scope continues throughout the lifecycle of a project.

Formalizing the Project Goals

Project Scope Document

 The project scope is described in the project scope document, which contains:

 Project goals and requirements, which describe what we intend to achieve with the project and the main characteristics of the project and its outputs.

 Assumptions and constraints, which describe the conditions which have to be met for the project to succeed.

 Project outputs and control points, which describe the outputs of the project, and in some cases, a rough timing of their delivery.

Formalizing the Project Goals

(3)

3/13

 Project Goals and Requirements

 Most projects are initiated to accomplish a specific objective that ties back to one or more business goal(s).

 In order for the project to meet the business objectives, it is critical that the requirements also be aligned to the business goals.

 The goal is defined at the beginning of the project while a requirement is accurately collected by the project manager to meet that goal afterwards in the planning phase.

 The project goals and requirements are the basis to define:

 The baseline work to be performed.

 The project acceptance criteria.

 Clearly understanding the business goals and project objectives at the start will make it easier to evaluate and prioritize the requirements according to how well they support the objective.

Formalizing the Project Goals

Project Objectives/Goals Attributes

 Project objectives/goals must be:

 Specific:

Clear and concise.

 Measurable:

Easy to obtain measure to understand whether the goal has been reached. Maybe a date or a number, or a formula (but keep it simple!).

 Agreed-to:

Goals must be specific enough that the team can agree on being able to reach them.

 Realistic:

Goals must be realistic. Unrealistic goals set unrealistic expectation and make the team apathetic.

 Time-bound:Must have a begin and an end.

Formalizing the Project Goals

(4)

4/13

 Assumptions and constraints

 Projects have assumptions and constraints. It is necessary to understand them if you want to complete your project successfully.

 Assumptions

 An assumption is a belief of what you assume to be true in the future.

 You make assumptions based on your knowledge, experience or the information available on hand. These are anticipated events or circumstances that are expected to occur during your project’s life cycle.

 Assumptions are supposed to be true but do not

necessarily end up being true; Sometimes, they may turn out to be false, which can affect your project significantly.

Formalizing the Project Goals

 They add risks to the project because they may or may not be true.

 For example, you have assumed that some particular equipment will be made available to you whenever you need it. However, the equipment is not provided when the time comes. Now, you are in a difficult situation.

 Constraints

 Constraints are limitations imposed on the project, such as the limitation of cost, schedule, or resources, and you have to work within the boundaries restricted by these constraints.

 All projects have constraints, which are defined and identified at the beginning of the project.

 Constraints are outside of your control. They are imposed upon you by your client, organization, or by any

government regulations.

Formalizing the Project Goals

(5)

5/13

 Project Outputs (Milestones and Deliverables)

 The project outputs define what a project will accomplish and when.

 Milestone: a significant event in the project

 Identify critical points in the project and in the schedule

 Often used at “review” or “delivery” times

 Can be tied to contractual terms, calendar constraints, deliverables

 Deliverable: a unique, measurable, and verifiable work product

 Can be internal or external

 Can have different dissemination and formality levels

 In Gantt charts, tasks are often interconnected (the output of task is a deliverable which is the input of a subsequent activity)

Formalizing the Project Goals

 Regardless of whether time is a critical issue on a project or not, the project manager will have to develop a

preliminary estimate of the amount of time the project will take.

 Estimation is the process of assigning projected values for time and effort.

 Estimation can be performed manually or with the help of an estimation software package like Construx Estimate, Costar, or KnowledgePLAN.

 The estimates developed at the start of a project are usually based on a range of possible values (e.g., the design phase will take three to four months) and gradually become more specific as the project moves forward (e.g., the design phase will be completed on March 22).

Estimating the Project Time Frame

(6)

6/13

Sources of the numbers used to calculate these estimates:

 Past experience: Numbers can be taken from projects with similar tasks and technologies, or provided by experienced developers.

 Systems consulting firms : One of the greatest strengths of systems consulting firms is the past experience that they offer to a project; they have estimates and

methodologies that have been developed and honed over time and applied to hundreds of projects.

 Detailed analysis: A good practice is to keep track of the actual time and effort values during the SDLC so that numbers can be refined along the way, and the next project can benefit from real data.

Estimating the Project Time Frame

 There are two basic approaches to estimate the time required to build a system.

I. Estimating Project Time Using Industry Standards

 This is the simplest approach. It takes the time spent in (or estimated for) the planning phase and uses industry

standard percentages to calculate estimates for the other SDLC phases.

 Industry standards suggest that a “typical” business application system spends 15% of its effort in the

planning phase, 20%in the analysis phase, 35% in the design phase, and 30%in the implementation phase.

 So, if a project takes 4 months in the planning phase, then the entire project likely will take a total of 26.66 person- months (4 0.15 = 26.66).

Estimating the Project Time Frame

(7)

7/13

 These same industry percentages are then used to estimate the amount of time in each phase, as shown in the above figure.

 The obvious limitation of this approach is that it can be difficult to take into account the specifics of your individual project, which may be simpler or more difficult than the

“typical” project.

Estimating the Project Time Frame

Estimating Project Time Using Industry Standards

II. Estimating Project Time Using The Function Point Approach

Estimating the Project Time Frame

 This is a more precise approach to estimation.

 The function point approach can be used to estimate the sizeof the new system, the effort that will be required to complete the system, and the time the project will require.

 The function point approach uses a three-step process. (See the figure).

 First, the project manager estimates the size of the project in terms of the number of lines of code the new system will require.

(8)

8/13

 This size estimate is then converted into the amount of effort required to develop the system in terms of the number of person-months.

 The estimated effort is then converted into an estimated schedule time in terms of the number of months from start to finish.

Step 1: Estimate System Size

 The first step is to estimate the size of a project by using function points, a concept developed in 1979 by Allen Albrecht of IBM.

 A function point is a measure of program size that is based on the system’s number and complexity of inputs, outputs, queries, files, and program interfaces.

Estimating the Project Time Frame

The steps of estimating the size of a project:

1. Calculate the total unadjusted function points (TUFP) for the project

 The project manager lists the system components (inputs, outputs, queries, files, and program interfaces), which represent its major elements and related to the system’s functional requirements, on a worksheet.

 He/she records the total number of each component that the system will include, and then breaks down the number to show the number of components that have low,

medium, and high complexity.

 For example, there are 19 outputs that need to be developed for the system, 4 of which have low complexity, 10 that have medium complexity, and 5 that are very complex.

Estimating the Project Time Frame

(9)

9/13

 For each component, a total number of points is calculated by multiplying each number by a complexity index.

 The complexity index values are drawn from function point research and tell us, for example, that a low complexity input is “worth” three function points, while a high complexity output is “worth” seven function points. (See the figure)

Estimating the Project Time Frame

 The total number of points for all

components are added up to determine the total unadjusted function points

(TUFP) for the project, as shown in the figure.

2. Calculate the Adjusted Project Complexity (APC) factor

 To create a more realistic size for the project, a number of additional system factors, related to its non-functional requirements, such as end-user efficiency, reusability, and data communications are assessed in terms of their effect on the project’s complexity.

Estimating the Project Time Frame

 The assessment of each factor ranges from 0, which means irrelevant, to 5, which means extremely relevant.

 These assessments are totaled to give the total Processing

Complexity (PC) score, as shown in the figure.

(10)

10/13

Estimating the Project Time Frame

 The Adjusted Project Complexity (APC) factor has a baseline value of 0.65.

 The APC factor is calculated by adding the total Processing Complexity (PC) score (converted to hundredths) to this baseline amount, as follows:

Adjusted Project Complexity (APC) = 0.65 + (0.01 * PC) 3. Calculate the total adjusted function points (TAFP)

 The total adjusted function points (TAFP) is calculated as follows:

TAFP = APC * TUFP

 This number will be in the range [0.65 TUFP, 1.35 TUFP]

 It should give the project manager a reasonable idea as to how big the project will be.

Estimating the Project Time Frame

4. Convert the function points (TAFP) to lines of code

 Once the project manager has estimated the number of function points, he/she converts it into the lines of code that will be required to build the system.

 The number of lines of code (LOC) depends on the programming language you choose to use.

 The figure presents a very rough

conversion guide for some popular

languages.

 No. of LOC = TAFP * No. of LOC per Function Point for the selected language.

(11)

11/13

Estimating the Project Time Frame

 Example:

 APC = 0.65 + (0.01 * 7) = 0.72

 TAFP = APC * TUFP

= 0.72 * 338 = 243.36

 If you were to develop the system in Java, it would typically require

approximately 13,385 lines of code to write it.

LOC = 243.36 * 55

= 13384.8

Remarks:

 In the planning phase, the exact nature of the system has not yet been determined, so it is impossible to know exactly how many inputs, outputs, and so forth will be in the system. It is up to the project manager to make an intelligent guess.

 Later in the project, once more is known about the system, the project manager will revise the estimates, using this better knowledge to produce more accurate results.

 Since there is a direct relationship between lines of code and the amount of effort and time required to develop a system, the choice of development language has a significant impact on the time and cost of projects.

Estimating the Project Time Frame

(12)

12/13

Step 2: Estimate Effort Required

 Once an understanding is reached about the size of the system, the next step is to estimate the effort that is required to build it.

 Effort is a function of the system size combined with production rates (how much work someone can complete in a given time).

 One of the most popular algorithms for estimating the effort is the Constructive Cost Modeling (COCOMO ) model.

 COCOMO model was designed by Barry W. Boehm to convert a lines-of-code estimate into a person-month estimate.

Estimating the Project Time Frame

 There are different versions of the COCOMO model that vary with:

 the complexity of the software,

 the size of the system,

 the experience of the developers, and

 the type of software that you are developing (e.g., business application software such as university registration system;

commercial software such as Word; or system software such as Windows).

 For small to moderate-size business software projects (i.e., 100,000 lines of code and 10 or fewer programmers), the model is quite simple:

effort (in person-months) =

1.4 * thousands of lines of code

Estimating the Project Time Frame

(13)

13/13

 For example, suppose that we were going to develop a business software system requiring 10,000 lines of code.

This project would typically take 14 person-months of effort.

 If the system in the example given in Slide 22 were developed in Java (which equates to 13,385 lines of code), it would require about 18.74 person-months of effort.

Step 3: Estimate Time Required

 Once the effort is understood, the optimal schedule for the project can be estimated.

 Historical data or estimation software can be used as aids, or one rule of thumb is to determine schedule by the

following equation:

schedule time (months) = 3.0 * person-months^1/3

Estimating the Project Time Frame

 This equation is widely used, although the specific

numbers vary (e.g., some estimators may use 3.5 or 2.5 instead of 3.0).

 The equation suggests that a project that has an effort of 14 person-months should be scheduled to take a little more than 7 months to complete.

 Continuing our example, the 18.74 person-months would require about 8 months.

 It is important to note that this estimate is for the analysis, design, and implementation phases; it does not include the planning phase