Unit-I Part-II

1

PROJECT MANAGEMENT

Project Management

Project Management is the discipline (order or control) of defining and achieving targets while optimizing the use of resources (time, money, people, materials, energy, space, etc) over the course of a project (a set of activities of finite duration).

The job pattern of an IT company engaged in software development can be seen split in two parts:

• Software Creation

• Software Project Management

A project is well-defined task, which is a collection of several operations done in order to achieve a goal (for example, software development and delivery). A Project can be characterized as:

• Every project may have a unique and distinct goal.

• Project is not routine activity or day-to-day operations.

• Project comes with a start time and end time.

• Project ends when its goal is achieved hence it is a temporary phase in the lifetime of an organization.

• Project needs sufficient resources in terms of time, manpower, finance, material and knowledge-bank.

Definition of Project Management

A simple definition of project management includes:

• Project management is no small task.

• Project management has a definite beginning and end. It's not a continuous process.

• Project management uses various tools to measure activities and track project tasks. These include Work Breakdown Structures, Gantt charts and PERT charts.

• Projects frequently need ad-hoc resources rather than dedicated, full-time positions common in organizations.

2

Often, a triangle, commonly called the "triple constraint", is used to summaries project management. The three most important factors are time, cost and scope. These form the vertices with quality as the central theme.

The triple constraint

In words, the triple constraint has four core elements:

• Projects must be within cost.

• Projects must be delivered on time.

• Projects must be within scope.

• Projects must meet customer quality requirements.

More recently, the project management triangle has given way to a project management diamond - with cost, time, scope and quality as the four vertices and customer expectations as a central theme.

3

No two customers have the same expectations. You must ask, explicitly, about each customer's expectations. If you don't know what those expectations are, you have no hope of meeting them.

Project Phases

A project goes through six phases during its lifecycle:

1. Project Definition: Defining the goals, objectives and critical success factors for the project

2. Project Initiation: Everything needed to set up the project before work can start

3. Project Planning: Detailed plans of how the work will be carried out, including time, cost and resource estimates

4. Project Execution: Doing the work to deliver the product, service or desired outcome

5. Project Monitoring & Control: Ensuring that a project stays on track and taking corrective action to ensure it does

6. Project Closure: Formal acceptance of the deliverables and disbanding of all the elements required to run the project

Roles of a Project Manager

Leader

A project manager must lead his team towards success. He should provide them direction and make them understand what is expected of them. Clearly explain the roles of each member of the team.

He must build a team comprising of individuals with different skills so that each member contributes effectively to the best of their abilities.

Liaison

The project manager is a link between his clients, his team and his own supervisors. He must coordinate and transfer all the relevant information from the clients to his team and report to the upper management.

Mentor

4

A project manager must have a range of competencies:

• Leadership

• People management (customers, suppliers, functional managers and project team)

• Effective communication (verbal and written)

• Influencing

• Negotiation

• Conflict management

• Planning

• Contract management

• Estimating

• Problem solving

• Creative thinking

• Time management

Project managers put up with ultimate responsibility for making things happen. Traditionally, they have carried out this role as simple implementers. To do their jobs they needed to have the necessary administrative and technical competencies.

Barriers, Risks and Issues That Affect Project Success

Many things can go wrong in project management. Any barriers, risks and issues can affect every phase and process of project management. Here are just some of the things that can possibly go wrong:

• Poor communication

• Disagreement

• Misunderstandings

• Inclement weather

• Union strikes

5

• Poor management

• Poorly defined goals and objectives

A good project management discipline will not eliminate all risks, issues and surprises - but it will provide standard processes and procedures to deal with them and help prevent the following:

• Projects finishing late, exceeding budget and not meeting customer expectations

• Inconsistency between the processes and procedures used by project managers, leading to the favoring of some project managers more than others

• Successful projects, despite a lack of planning, achieved through high stress levels, goodwill and significant amounts of overtime

• Project management being seen as not adding value and as a waste of time and money

• Unforeseen internal and external events impacting the project

******************************************************************************

THE MANAGEMENT SPECTRUM or 4 P`s of Software System

Effective software project management focuses on the four P’s: people, product, process, and project. The manager who forgets that soft-ware engineering work is an extremely human effort will never have success in project management.

The effective software project management focuses on four P's.

The People The Product The Process The Project

The People

The following categories of people are involved in the software process.

• Senior Managers

• Project Managers

• Practitioners

6

• End Users

Senior Managers define the business issue.

Project Managers plan, motivate, Organize and control the practitioners who do the Software work.

Practitioners deliver the technical skills that are necessary to engineer a product or application.

Customer specifies the requirements for the software to be developed.

End Users interact with the software once it is released.

The Product

• Before a software project is planned, the product objectives and scope should be established technical and management constraints should be identified.

• Without this information it is impossible to define a reasonable cost, amount of risk involved, the project schedule etc.

Scope can be defined by

• Context.

How does this product fit into business processes?

What systems will the product interact with?

• Objectives. What data objects are required as i/p or o/p

• Function.

What function does the software system perform on i/p to produce o/p What level of performance is required

The Process

Here the important thing is to select an appropriate process model to develop the software. There are different process models available.

They are

• Water fall model,

7

• RAD(Rapid Application Development) model,

• Spiral model.

In practice we may use any one of the above models or a combination of the above models.

The Project

In order to manage a successful software project, we must understand what can go wrong (so that problems can be Avoided)and how to do it right. A project is a series of steps where we need to make accurate decision so as to make a successful project.

• Projects get into risk when …

– Software people don’t understand their customer’s needs.

– The product scope is poorly defined.

– Changes are managed poorly.

– The chosen technology changes.

– Deadlines are unrealistic.

– Users are resistant.

– Sponsorship is lost.

– The project team lacks people with appropriate skills.

– Managers [and practitioners] avoid best practices and lessons learned.

******************************************************************************

The W5HH Principle in Project Management

Barry Bohem suggested an approach that addresses project objectives, milestones and schedules, responsibilities, management and technical approaches and required resources. This is called W5HH principle. The questions that are answered in this principle are:

1. Why is the system being developed?

2. What will be done?

8

5. Where they are organizationally located?

6. How will the job be done technically and managerially?

7. How much of each resource is needed?

WHY IS THE SYSTEM BEING DEVELOPED?

It enables the parties to assess the validity of business reasons for the software work. It justifies the expenditure of people, time, and money.

Stated in another way, does the business purpose justify the expenditure of people, time, and money?

WHAT WILL BE DONE?

It specifies the task set required for the project.

WHEN WILL IT BE DONE?

It helps to determine the project schedule. It helps in determining when tasks are conducted and when milestones are reached.

WHO IS RESPONSIBLE FOR A FUNCTION?

It helps to accomplish the role and responsibilities of each member of the software team.

WHERE THEY ARE ORGANIZATIONALLY LOCATED?

The software team does not contain all the roles and responsibilities. The customers, users and stakeholders also have responsibilities.

HOW WILL THE JOB BE DONE TECHNICALLY AND MANAGERIALLY?

The management and technical strategy of project is defined once the scope of the product is established.

HOW MUCH OF EACH RESOURCE IS NEEDED?

It helps in deriving estimates based on the answers to the above questions.

9

Software estimation

In order to successful software project & proper execution of task, the Estimation Techniques plays vital role in software development life cycle.

The technique which is used to calculate the time required to accomplish a particular task is called Estimation Techniques.

To estimate a task different effective Software Estimation Techniques can be used to get the better estimation.

What is Estimation?

“Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable.”

The Estimate is prediction or a rough idea to determine how much effort would take to complete a defined task. Here the effort could be time or cost.

A rough idea how long a task would take to complete. An estimate is especially an approximate computation of the probable cost of a piece of work.

The calculation of test estimation techniques is based on:

• Past Data/Past experience

• Available documents/Knowledge

• Assumptions

• Calculated risks

Before starting one common question arises in the testers mind is that “Why do we estimate?” The answer to this question is pretty simple, it is to avoid the exceeding timescales and overshooting budgets for testing activities we estimate the task.

Few points need to be considered before estimating testing activities:

• Check if all requirements are finalize or not.

• If it not then how frequently they are going to be changed.

• All responsibilities and dependencies are clear.

• Check if required infrastructure is ready for testing or not.

• Check if before estimating task is all assumptions and risks are documented.

10

COCOMO - An Empirical Estimation Model for Effort

Introduction:

The structure of empirical estimation models is a formula, derived from data collected from past software projects that uses software size to estimate effort. Size, itself, is an estimate, described as either lines of code (LOC) or function points (FP).

No estimation model is appropriate for all development environments, development processes, or application types. Models must be customized (values in the formula must be altered) so that results from the model agree with the data from the particular environment.

The typical formula of estimation models is:

Where;

E represents effort, in person months,

S is the size of the software development, in LOC or FP, and,

a, b, and c are values derived from data.

The relationship seen between development effort and software size is generally:

11

COCOMO:

When Barry Boehm wrote 'Software Engineering Economics', published in 1981, he introduced an empirical effort estimation model (COCOMO - COnstructive COst MOdel) that is still referenced by the software engineering community.

The original COCOMO model was a set of models; 3 development modes (organic, semi-detached, and embedded) and 3 levels (basic, intermediate, and advanced).

COCOMO model levels:

Basic - predicted software size (lines of code) was used to estimate development effort.

Intermediate - predicted software size (lines of code), plus a set of 15 subjectively assessed 'cost drivers' was used to estimate development effort.

Advanced - on top of the intermediate model, the advanced model allows phase-based cost driver adjustments and some adjustments at the module, component, and system level.

COCOMO development modes:

Organic - small relatively small, simple software projects in which small teams with good application experience work to a set of flexible requirements.

Embedded - the software project has tight software, hardware and operational constraints.

Semi-detached - an intermediate (in size and complexity) software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.

COCOMO model:

The general formula of the basic COCOMO model is:

Where:

E represents effort in person-months,

S is the size of the software development in KLOC and,

12

13

As an example of how the intermediate COCOMO model works, the following is a calculation of the estimated effort for a semi-detached project of 56 KLOC. The cost drivers are set as follows:

14

The effective management of a software project greatly depends on careful planning the progress of the project. The plan prepared at the start of a project is considered an initial plan and it should be used as the driver for the entire project. The initial plan should be the best possible plan given by the available information. It evolves as the project progresses and more information becomes available.

The project plan

The project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out the work. Most project plans includes the following sections:

1. Introduction. This summarizes the objectives of the project and sets out the budget, time and other constraints.

2. Work breakdown. This sets out the breakdown of the project into activities and identifies the milestones and deliverables associated with each activity.

3. Hardware and software resource requirements. This specifies the hardware and the support software allocated to development activities.

4. Project organization. This defines the development team, its members and the roles in the team.

5. Project schedule. Project schedule shows the dependencies between activities, the estimated time required to complete activities and the allocation of people to activities.

6. Risk analysis. This describes the possible project risks and the strategies to manage them. 7. Monitoring and reporting mechanisms. This defines the management reports that should be

produced, when these should be produced and the project monitoring mechanisms used.

15

Risk Management

What Is Software Risk And Software Risk Management?

Risk is an expectation of loss, a potential problem that may or may not occur in the future. It is generally caused due to lack of information, control or time.

A possibility of suffering from loss in software development process is called a software risk.

Loss can be anything, increase in production cost, development of poor quality software, not being able to complete the project on time. Software risk exists because the future is uncertain and there are many known and unknown things that cannot be incorporated in the project plan.

A software risk can be of two types

(1) Internal risks that are within the control of the project manager and

(2) External risks that are beyond the control of project manager.

A project manager has to deal with risks arising from three possible cases:

1. Known knowns are software risks that are actually facts known to the team as well as to the entire project.

For example not having enough number of developers can delay the project delivery. Such risks are described and included in the Project Management Plan.

2. Known unknowns are risks that the project team is aware of but it is unknown that such risk exists in the project or not.

For example if the communication with the client is not of good level then it is not possible to capture the requirement properly. This is a fact known to the project team however whether the client has communicated all the information properly or not is unknown to the project.

16

1. Software Risk Identification

2. Software Risk Analysis

3. Software Risk Planning

4. Software Risk Monitoring

These Processes are defined below. Software Risk Identification

In this phase of Risk management you have to define processes that are important for risk identification. All the details of the risk such as unique Id, date on which it was identified, description and so on should be clearly mentioned.

Software Risk Analysis

Software Risk analysis is a very important aspect of risk management. In this phase the risk is identified and then categorized.

After the categorization of risk, the level, likelihood (percentage) and impact of the risk is analyzed.

Likelihood is defined in percentage after examining what are the chances of risk to occur due to various technical conditions. These technical conditions can be:

1. Complexity of the technology

2. Technical knowledge possessed by the testing team

3. Conflicts within the team

4. Teams being distributed over a large geographical area

5. Usage of poor quality testing tools

With impact we mean the consequence of a risk in case it happens. It is important to know about the impact because it is necessary to know how a business can get affected:

1. What will be the loss to the customer

2. How would the business suffer

3. Loss of reputation or harm to society

17

6. Cancellation of business license

Level of risk is identified with the help of:

Qualitative Risk Analysis: Here you define risk as:

• High

• Low

• Medium

Quantitative Risk Analysis: can be used for software risk analysis but is considered inappropriate because risk level is defined in % which does not give a very clear picture.

Software Risk Planning

Software risk planning is all about:

1. Defining preventive measure that would lower down the likelihood or probability of various risks.

2. Define measures that would reduce the impact in case a risk happens.

3. Constant monitoring of processes to identify risks as early as possible.

Software Risk Monitoring

Software risk monitoring is integrated into project activities and regular checks are conducted on top risks. Software risk monitoring comprises of:

• Tracking of risk plans for any major changes in actual plan, attribute, etc.

• Preparation of status reports for project management.

• Review risks and risks whose impact or likelihood has reached the lowest possible level should be closed.