Chapter- 5�Software Project Management

Software Project Management

• Software Project Management is to be done in scientific way.
• It involves the knowledge, techniques and tools necessary to manage the software development.
• It starts before any activity starts.
• The Software Project Management includes basic function such as scoping, planning, estimating, scheduling, organizing, directing, coordinating, controlling and closing.

Management Spectrum

• The management spectrum describes the management/hierarchy of people associated with a software project.
• How to make a software project successful.
• Effective Software Project Management focuses on the four P’s:
• People
• Product
• Process
• Project
• The order is not arbitrary.

The People

• People factor is very much important in the process of software development.
• There are following areas for software people like, recruiting, performance management, training, compensation, career development, workgroup development, and team/culture development.
• Organizations achieve high levels of maturity in the people management area.

Stakeholders

• Senior managers who define the business issues that often have significant influence on the project.
• Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work.
• Practitioners who deliver the technical skills that are necessary to engineer a product or application.
• Customers who specify the requirements for the software to be engineered
• End-users who interact with the software once it is released for production use.

Project Manager

The following characteristics defines an effective project manager

1. Problem solving: An effective software manager can diagnose the technical and organizational issues and systematically structure a solution or motivate other practitioners to apply the solution.

2. Managerial Identity: A good manager must take charge of the project and must have confidence to assume control when necessary.

3. Achievement: To optimize the productivity of a project team, a manager must reward initiative and accomplishment of the practitioners.

4. Influence and Team Building: An effective project manager must be able to read people, to understand verbal and non verbal signals and react to the needs of the people sending these signals. The manager must remain under control in high stress situation.

Software Teams

Software Team

The best team structure depends on

• the management style of your organization,
• the number of people who will populate the team
• their skill levels, and
• the over all problem difficulty.
• The following seven project factors for the structure of software engineering teams:
1. The difficulty of the problem to be solved.
2. The “size” of the resultant programs in lines of code or function points.
3. The time that the team will stay together.
4. 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.

Agile Team

1. The agile team is a very active team.

2. It encourages customers satisfaction by early incremental delivery of software.

3. It provides small and highly motivated project teams.

4. This is an highly motivated team who provides minimal software engineering work product.

Product

1. Before a project can be planned, the product objectives and scope should be identified.

2. Objectives identify the overall goals for the product without considering how these goals will be achieved.

3. Scope identifies the primary data, functions and behaviors that categorize the product.

4.It identifies cost, risk and realistic break downs of project task.

Process

• The process model is the plan to be selected depending on following factors
• a) Customers and developers.
• b) Characteristics of product itself.
• c) Project environment of software team.
• Regardless of the size and type of project, there are small number of framework activities that are applicable to all of them.
• There are also umbrella activities like SQA, that occur throughout the system.

Project

• We conduct planned and controlled software projects for one primary reason-it is the only known way to manage complexity.
• A software project manager, who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management.
• And develop a common sense approach for planning, monitoring and controlling the project.

Project

To manage a successful software project, we must understand what can go wrong.

• 10 signs that indicate that an information systems project is moving towards failure-

1. Software people don't understand their customers needs.

2. The product scope is poorly defined.

3. Changes are managed poorly.

4. The chosen technology changes.

5. Business needs change.

6. Deadlines are unrealistic.

7. Users are resistant.

8. Sponsorship is lost.

9. The project team lacks people with appropriate skills.

10. Managers avoid best practices and lessons learned.

Project Scheduling

1. In project management, a schedule consist of a list of project terminal elements, with intended start date and finish date.

2. The s/w project scheduling distributes estimated efforts across the planned project period by allocating the effort to particular s/w engineering tasks.

3. There are many tasks in a s/w project. The project manager defines all the task and generates the schedule.

4. Initially a macroscopic schedule is developed, identifying all major process framework activities and then the detailed schedule of specific tasks are identified and scheduled.

Factors that delay Project Schedule

Although there are many reasons why software is fail, most can be traced to one or more of the following root causes:

1. An unrealistic deadline established by someone outside the software team and forced on managers and practitioners.

2. Changing customer requirements that are not reflected in schedule changes.

3. An honest underestimate of the amount of effort and/or the number of resources that will be required to do the job.

4. Predictable and/or unpredictable risks that were not considered when project commenced.

5. Technical difficulties that could not have been foreseen in advance.

6. Human difficulties that could not have been foreseen in advance.

7. Miscommunication among project staff that results in delays.

8. A failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem.

Principles of Project Scheduling

i. Compartmentalization: The project must be compartmentalized into a number of manageable activities and tasks.

ii. Interdependency: The interdependency of each compartmentalized activity or task must be determined.

iii. Time allocation: Each task to be scheduled must be allocated some number of work units (e.g., person‐days of effort).

iv. Effort validation: the project manager must ensure that no more than the allocated number of people have been scheduled at any given time.

​

​

​

v. Defined responsibilities: Every task should be assigned to a specific team member

vi. Defined outcomes: Every task should have a defined outcome.

Vii. Defined milestones: Every task or group of tasks should be associated with a project milestone.

viii. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved.

Project schedule can be tracked by using different scheduling tools and techniques.

Program Evaluation Review Technique (PERT)

i. PERT, is used in projects that have unpredictable tasks and activities such as in research and development projects.

ii. It utilizes three estimates of the time to complete the project: the most probable, the most promising, and the most unfavorable.

iii. It is a probabilistic tool.

iV) It uses several estimates to determine the time completion of the project and controls activities so that it will be completed faster and at a lower cost.

Critical Path Method (CPM)

i. CPM is a technique that is used in projects that have predictable activities and tasks such as in construction projects.

ii. It allows project planners to decide which aspect of the project to reduce or increase when a trade-off is needed.

iii. It is a deterministic tool and provides an estimate on the cost and the amount of time to spend in order to complete the project.

iv. It allows planners to control both the time and cost of the project.

Difference PERT Vs CPM

1. The Program Evaluation and Review Technique (PERT) is suitable for projects that have unpredictable activities while the Critical Path Method (CPM) is suitable for projects that have predictable activities.

2. CPM uses a single estimate for the time that a project can be completed while PERT uses three estimates for the time that it can be completed.

3. CPM is a deterministic project management tool while PERT is a probabilistic project management tool.

4. CPM allows project management planners to determine which aspect of the project to sacrifice when a trade-off is needed in order to complete the project while PERT does not.

​

Time-Line Charts or Gantt chart

• A time-line chart can be developed for the entire project or separate charts can be developed for each project function or for each individual working on the project.
• All project tasks (for concept scoping) are listed in the left-hand column.
• The horizontal bars indicate the duration of each task.
• When multiple bars occur at the same time on the calendar, task concurrency is implied.
• The diamonds indicate milestones.

Timeline Charts

Concept of Task Network

• A task network, also called an activity network, is a graphic representation of the task flow for a project.
• It is the mechanism through which task sequence and dependencies are input to an automated project scheduling tool.
• In its simplest form, the task network depicts major software engineering tasks.
• The concurrent nature of software engineering activities leads to a number of important scheduling requirements.
• In addition, the project manager should be aware of those tasks that lie on the critical path.
• That is, tasks that must be completed on schedule if the project as a whole is to be completed on schedule.

Ways of Project Tracking

Tracking: - can be accomplished in different ways:

• Conducting periodic project status meetings in which each team member reports progress and problems.
• Evaluating the results of all reviews conducted throughout the software engineering process.
• Determining whether formal project milestones have been accomplished by the scheduled date.
• Comparing actual start-date to planned start-date for each project task.
• Meeting informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon.

Project Risks

What can go wrong?

What is the likelihood?

What will the damage be?

What can we do about it?

Risk Management

• Software risk :A software risk is anything which can cause a delay in software or stops the progress of a system or even terminates the software project.
• 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.
• Loss can be anything, increase in production cost, development of poor quality software, not being able to complete the project on time.

Concept of Proactive and Reactive risk strategies

Reactive:

1. Majority of the software teams and managers rely on this approach i.e., nothing is done about risks until something actually goes wrong.

2. Here when something goes wrong the team files into action and attempts to correct the problem.

3. Here disaster management or risk management is the choice of management technique.

Proactive:

1. Here the primary objective is to avoid risk and to have a contingency plan in place to handle unavoidable risk in controlled and effective manner.

2. Here the proactive strategy start in the early of project development.

3. Possibilities and types of risks are identified, they are checked and arranged as per their priority and impact and prioritized according to their importance.

4. Then after ranking the risk the main plan of the project team is to avoid the risk.

Types of Software Risks

There are two basic types of risks:

(a) Generic Risk : Generic Risk is the general purpose possible threat to every software product.

(b) Product Specific Risk: Product Specific risk can be find out only by those with a clear understanding of the technology going to be used for that project.

Different Categories of Risks: -

(a) Project Risk: - Threaten the project plan. That is if project risk become real it is likely that project schedule will slip and that costs will increase. Project risks identity potential budgetary, schedule, personnel, resource, customer and requirement problem.

(b) Technical Risk: - Threaten the quality and timeliness of the software to be produced. If technical risk becomes real, implementation may become difficult or impossible.

(c) Business Risk: - Threaten the viability of the software to be built. Business risk often jeopardizes the product or the project.

​

(d) Market Risk:- Building product that no one wants

(e) Strategic Risk: - Building a product that no longer fits into the business strategy

(f) Management Risk: - Building a product that the sale force doesn‘t understand.

(g) Budget Risk: - Losing budgetary or personnel commitment

Risk Assessment

• Risk assessment involves the evaluation of the risk. We take a triplet into consideration for understanding risk assessment in detail.
• In the triple ri stands for risk, li stands for likelihood that is probability of the risk, and xi represents impact of the risk.
• In initial stages of project planning a risk is stated generally. As the time passes, it is important to divide that risks into sub types and try to refine it.

Risk Management Paradigm

RISK

control

identify

analyze

plan

track

Risk identification

• Risk identification can be defined as systematic attempt to specify or find out threats to the project plan. Project plan includes estimation, resource distribution etc.
• With the help of finding well known and predictable risks, the project manager or leader can take first step to deal with or avoid them.
• These risks need to be controlled or avoided as per its form.

Risk Analysis

• After identification of the risk, risk analysis has to be done.
• The process of risk analysis is analyzing the potential risks with its types and details.
• The time and efforts needed for risks analysis are huge.
• Analysis starts with what risks are there, their probability and consequences with their impact on the project.

Risk refinement : In initial stages of project planning a risk is stated generally. As the time passes it is important to divide that risks into its sub types and try to refine it.

The way to refine risk is to represent the risk in condition – transition – consequence i.e. CTC format. The risk can be stated as follows.

<Condition>(Possibly)<Consequence>

Risk Prioritization

• For the purpose of deciding the priority of the risk, process called as risk prioritization is used.
• When first four columns of the risk table are filled with the risk related data, the table needs to be sorted by probability and by impact.
• The risk with high probability and high impact risks are located at the top of the table.
• The risks with low probability go to the bottom of the table after sorting.
• This is called as first order prioritization of the risks.

• The project manager analyses the sorted risk table and defines the cutoff line.
• It is a horizontal line at some point in the table. The risk above this line will be given more attention. The risks below the line will be again reviewed and evaluated.
• After this, again second order prioritization of the risk below cut off line is done.

RMMM strategy

• To assist the project team in developing a strategy for dealing with risk.
• An effective strategy must consider three issues: risk avoidance, risk monitoring, and risk management and contingency planning.
• If a software team adopts a proactive approach to risk avoidance is always the best strategy.
• This is achieved by developing a plan for risk mitigation.

​

Risk Mitigation

• To mitigate this risk, you would develop a strategy for reducing turnover.
• Among the possible steps to be taken are:
• Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, competitive job market).
• Mitigate those causes that are under your control before the project starts.
• Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave.
• Organize project teams so that information about each development activity is widely dispersed.

• Define work product standards and establish mechanisms to be sure that all models and documents are developed in a timely manner.
• Conduct peer reviews of all work (so that more than one person is ―up to speed).
• Assign a backup staff member for every critical technologist

Risk Monitoring

• As the project proceeds, risk-monitoring activities commence.
• The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely.
• In the case of high staff turnover, the general attitude of team members based on project pressures, the degree to which the team has jelled, interpersonal relationships among team members, potential problems with compensation and benefits, and the availability of jobs within the company and outside it are all monitored.

​

​

Risk Management

• In addition to monitoring these factors, a project manager should monitor the effectiveness of risk mitigation steps. Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality.
• It is important to note that risk mitigation, monitoring, and management (RMMM) steps incur additional project cost. For example, spending the time to back-up every critical technologist costs money. Part of risk management, therefore, is to evaluate when the benefits accrued by the RMMM steps are outweighed by the costs associated with implementing them.

​

Software Configuration Management (SCM)

• Software Configuration Management (SCM) is also known as change management.
• Changes can occur at any point of a time and that too because of any reason throughout the life cycle.
• Sources of change can be:-
• Change in a product requirement and business rule because of new business or market conditions.
• Modification in data,functionality,services etc.
• Reorganization or business growth
• Redefinition of product because of budgetary and scheduling constraints.

Elements of software configuration management system

Four important elements that should exist when a configuration management system is developed:

Component elements -a set of tools coupled within a file management system (e.g., a database) that enables access to and management of each software configuration item.

Process elements -a collection of actions and tasks that define an effective approach to change management (and related activities) for all constituencies involved in the management, engineering, and use of computer software.

Construction elements -a set of tools that automate the construction of software by ensuring that the proper set of validated components (i.e., the correct version) have been assembled.

Human elements-a set of tools and process features (encompassing other CM elements) used by the software team to implement effective SCM.

Need of SCM

1. Identify change or changes.

2. Keep control on change.

3. For ensuring that change is properly implemented.

4. Make report of changes and present it to the people who have interest in that.

Benefits of SCM

1. Changes can be made with ease throughout software development process.

2. Changes are systematically recorded.

3. Changes are available whenever required for review.

4. Different version of software project can be created and process can be continued for long time.

5. Repository is available in the form of database.

6. Every object's detail can be stored with its attributes.

7.Changes can be traced in forward and backward direction.

8. Customer requirements are fulfilled by accepting changes.9. It is one of the activities of software quality assurance that supports validation as well as verification.

10. Avoids lot of confusion because of change in software project.

​

​

Software Configuration Management Activities/Process

Identification of change

To control and manage configuration items, each must be named and managed using an object-oriented approach

 Basic objects are created by software engineers during analysis, design, coding, or testing

 Aggregate objects are collections of basic objects and other aggregate objects

 An entity-relationship (E-R) diagram can be used to show the interrelationships among the objects

Software Configuration Management Activities

Identification of change

To control and manage configuration items, each must be named and managed using an object-oriented approach

 Basic objects are created by software engineers during analysis, design, coding, or testing

 Aggregate objects are collections of basic objects and other aggregate objects

 An entity-relationship (E-R) diagram can be used to show the interrelationships among the objects

Version Control

 Combines procedures and tools to manage the different versions of configuration objects created during the software process

 An entity is composed of objects at the same revision level

 A variant is a different set of objects at the same revision level and coexists with other variants

 A new version is defined when major changes have been made to one or more objects

Change Control

 Change request is submitted and evaluated to assess technical merit and impact on the other configuration objects and budget

 Change report contains the results of the evaluation

 Change control authority (CCA) makes the final decision on the status and priority of the change based on the change report.

Software Configuration Audit

 A software configuration audit complements the formal technical review by assessing a configuration object for characteristics that are generally not considered during review. The audit asks and answers the questions such as:

 Has the change specified in the ECO been made? Have any additional modifications been incorporated?

 Has a formal technical review been conducted to assess technical correctness?

​

Status Reporting

Configuration status reporting (sometimes called status accounting) is an SCM task that answers the following questions:

1. What happened?

2. Who did it?

3. When did it happen?

4. What else will be affected?

​

SCM Repository Functions

Data integrity: It ensure consistency among related objects.

Information sharing: Sharing information among multiple developers, multiple tools, manages and controls multiuser access to data.

Tool integration: Establishes data model that can accessed by many software engineering tools, controls access to data.

Data integration: Provides data base functions that allow various SCM task to be performed on one or more Software Configuration Items(information as part of project) .

Methodology enforcement: Defines an entity relationship model stored in repository for software engineering.

Document standardization: It is a standard approach for creation of software engineering documents.

SCM Tool Features

Versioning - control changes to all work products before and after release to customer.

Dependency tracking and change management - tracking relationships among multiple versions of work products to enable efficient changes (link management)

Requirements tracing – depends on link management, provides the ability to track all work products that result from a specific requirements specification (forward tracing) and to identify which requirement generated by any given work product (backward tracing)

Configuration management – works closely with link management and versioning facilities to keep track of a series of configurations representing project milestones or production releases

Audit trails - establishes additional information about when, where, why, and by whom changes were made