5.

Software project management

By
Polska Chifundo Mlangeni

1
 Introduction
◼ Software project management is the important task
of planning, directing, motivating, and
coordinating a group of professionals to
accomplish software development.
◼ Software project management uses many concepts
from management in general, but it also has some
concerns unique to software development.

2
 Project Visibility
◼ One such concern is lack of project visibility.
◼ makes it hard to manage.
◼ In many other fields, it is easy to see progress or
lack of progress.
◼ Many software projects get stalled at 90 percent
complete.
◼ Many of the techniques in software
management are aimed at overcoming this
lack of visibility
3
MANAGEMENT APPROACHES

Process Management vs Project Management

4
 Process Management
◼ Process Management and Project Management
go hand-in-hand to deliver a successful project
◼ Each has a clearly delineated area of
responsibility
◼ Process Management
◼ deals with defining and managing what is done on
a project, including tasks completed, deliverables
produced, roles performed, and tools used. It
deals with the “scientific method” used to deliver
an IT solution. 5
 Project Management
◼ Project Management deals with tracking
the process being executed, from a
schedule and cost perspective.
◼ It includes
◼ functions for developing the optimal project
schedule,
◼ producing a financial model of the project,
◼ scheduling and tracking of effort against plan,
◼ managing costs against budget,
◼ reporting of status, 6
 Process Management
Objectives
◼ To define a repeatable process that, when
executed, behaves predictably and delivers a
quality product – on schedule and within budget.
◼ To produce higher quality IT solutions.
◼ To increase productivity and shorten the delivery
cycle, through the application of optimized
processes and the re-use of work products.
◼ To upgrade the skill levels of all project
participants, including delivery team staff and
customers 7
Team approaches
◼ Introduction
◼ Team Structures
◼ Communication in the software project

8
 Introduction
◼ Once the project is approved, the management
of it concentrate on two themes:
◼ Creating a working team.
◼ Tracking what was planed.
◼ In this section we’ll focus on: How to organize
a working team?”

9
 Why do we need to create a
project organization?
◼ The activities have to be split up when planning
so that the achievement and control of each
task would be easier.
◼ Then we have to create the conditions for:
◼ coordinating easily: starting of tasks; taking decisions;
tracking; and ending of tasks.
◼ Providing communications between people in charge of
each task and people in the same or other tasks.

10
 Amount of structure in the team
◼ While some groups of programmers can work very
independently, other groups need strong structure
to make progress
◼ strongly structured team
◼ small assignments are made to each member

◼ These are often called ‘‘inch pebbles’’ because the

assignments are small milestones.

◼ Weakly structured team
◼ the tasks are usually of longer duration and more

open-ended.
11
Organization structure

◼ Enterprises have their own organization and can

clash with engineers own culture.
◼ It's important to identify the organization
structure and understand their line of authority
and knowledge distribution.
◼ Typical structures are:
◼ Functional organization
◼ Project organization
◼ Matrix organization

12
 Functional organization (I)
◼ Functional is a hierarchical organization struct.
where each employee has one clear superior, and
staff are grouped by areas of specialization and
managed by a person with expertise in that area
◼ Is the more known structure (military, church,...)
◼ Is the typical pyramidal structure. Each new level
introduces a type of specialization. It can be:
◼ type of work (functional),

◼ geographic localization (Territorial),

◼ Size of clients (Clients oriented),

◼ product (Product oriented).

13
 Functional organization (II)
◼ Communication is allowed between:
◼ People under the same boss (same level).
◼ Boss and subordinate.
◼ Formal communication between two people
in different areas must follow a long trip.
◼ Worker to boss,… boss to boss until a point in
the pyramid where it starts to go down until boss
to worker.

14
Functional organization (III)
Example:

15
Advantages of functional
organization
◼ Centralization of similar resources.
◼ Specialists in the same area close.
◼ Better professional careers
◼ Cooperation between specialists in the same
area
◼ Less need of technical experts.
◼ Maximum flexibility in the use of staff.
◼ Higher standardization level.
16
 Disadvantages of Functional
Organization

◼ Cracks in the inter-functional areas,

generating conflicts as:
◼ Responsibility: “this isn't responsibility”
◼ Power: several boss want to take decisions, in
the same subject.
◼ Communication, “I finished my task”, “Nobody
told me about …”, ...
◼ Deferent functions can have opposite
objectives. 17
 Project organization (I)
◼ Projectized organizational structure is one in which
the project manager has full authority to assign
priorities, apply resources, and direct the work of
persons assigned to the project
◼ Objectives attainment in a quick manner.
◼ Enterprise organization depends on the actual projects
◼ Each project has their own team and all the necessary
resources.
◼ The project manager has decision capacity.
◼ Team duration depends on the project duration.
18
Project organization (II),
Example:

19
Advantages of Project
Organization.
◼ objectives unity (clear objective)
◼ Control unity. Every body depends on
the same boss.
◼ Easy communication.
◼ Clear responsibilities.

20
Disadvantages of Project
Organization
◼ Changing enterprise organization.
◼ Duplication of resources and inefficiency.
◼ Difficult to share individuals/expertise across
projects
◼ Complex staff management
◼ What will happen when the project is finished?

21
 Matrix organization (I)
◼ Matrixed structure is one in which the project
manager shares responsibility with the
functional managers for assigning priorities
and for directing the work of persons assigned
to the project
◼ It's a multidimensional structure.
◼ Try to take the best of both.
◼ First we create functional structure and over this
we put a project structure.
22
Matrix organization (II)

23
 Matrix organization:
Advantages
◼ Equilibrate project objectives and
departments.
◼ Staff has better professional stability
◼ Specialists belong to the same department
and consults are easy.
◼ Easy professional careers.

24
Matrix organization :
disadvantages
◼ Staff has two or more managers when
they are in different projects.
◼ Project managers have less authority.

25
 Teams Structure
◼ The development of software projects
usually requires:
◼ Small teams.
◼ Classical structures aren’t an appropriate reference
◼ Specialists in different areas:
◼ Software technical knowledge
◼ Knowledge about the implied area.
◼ (Multifunctional teams).

26
Team Structure in software projects

◼ Three team structures are popular in this

field:
◼ Egoless programming team (Weinberg)
◼ Chief programming team (Mills and Baker).
◼ Controlled decentralized team structure.
◼ Marilyn Mantei (1981)

27
 Communication in the
software project.
◼ Communicating in harmony
◼ In software development projects, the
inability of people to communicate effectively
with one another represents one of the more
common obstacles to the achievement of:
◼ High product quality, and
◼ High productivity.

28
communication
◼ Improving communications among
project players offers substantial
morale, productivity, quality, and, cost
benefits to a project

29
 Once communication problems
surfaces, the process to follow:
◼ Understand the cause of the problems.
◼ Put corrective action into place.
◼ Enforce an ongoing communicative work
environment.

30
Actions to improve
communication.
◼ When you are wrong, admit it.
◼ Exercise tolerance.
◼ Meet people.
◼ Be quick to assist.
◼ Ask others for assistance.
◼ Use tact - put your comments in the
correct perspective.
31
 Actions to improve
communication.
◼ Keep others informed - do not give surprises.
◼ Close problems.
◼ Show appreciation.
◼ Be a good listener.
◼ Greet people - remember their names.
◼ Consider compromise.

32
 Actions to improve
communication.
◼ Be willing to break with tradition.
◼ Know what to expect from others.
◼ Respect people.

33
 Process Management Process

• Software Process Improvement

• Capability maturity models

34
 Background
◼ A process is not a static entity – it has to
change to improve the Q&P
◼ Focus of process management is to evaluate
and improve the process
◼ Is different from project management which
focuses on a project
◼ Process management is an advanced topic

35
 Software Process Improvement

◼ To improve the process, an org must

understand the current process
◼ Required process be properly documented
◼ Properly executed on projects
◼ Data is collected from projects to understand the
performance of process on projects
◼ Changes to process are best made in small
increments
36
 Software Process Improvement
Frameworks
◼ What changes that should be made to the
process and when
◼ Frameworks suggest ways of how process
improvement can proceed
◼ Capability Maturity Model (CMM) is one of the
most common frameworks
◼ Others include: ISO 9000, SPICE, Trillium &
Bootstrap
◼ The CMM framework provides a general
37
roadmap for process improvement
 Capability Maturity Models
◼ The Software Engineering Institute
(www.sei.cmu.edu) has developed the Capability
Maturity Model.
◼ The Software Engineering Capability Maturity Model (SE-
CMM) is used to rate an organization’s software
development process.
◼ An assessment of an organization’s practices,
processes, and organization is used to classify an
organization at one of the following levels:
38
CMM

39
 CMM maturity levels: Level 1: Initial
◼ This is the lowest level and usually characterized as
chaotic. No formalized method for any activity
◼ Basic project controls for ensuring that activities are
being done properly, and that the project plan is being
adhered to, are missing
◼ project plans and development processes are
abandoned in favor of a code-and-test type of
approach
◼ Success depends solely on the quality and capability of
individuals.
◼ process capability is unpredictable as the process
constantly changes
◼ Organizations at this level can benefit most by
improving project management, quality assurance, and 40
change control
 Level 2: Repeatable
◼ Policies for managing a software project and
procedures to implement those policies exist.
◼ Proj mgnt is well developed in a process
◼ project commitments are realistic and based on

past experience with similar projects, cost and

schedule are tracked
◼ problems resolved when they arise, formal

configuration control mechanisms are in place

◼ software project standards are defined and

followed.
◼ Results obtained by this process can be repeated

as the project planning and tracking is formal

41
 Level 3: Defined
◼ The organization has standardized a software
process, which is properly documented.
◼ A software process group exists in the
organization that owns and manages the
process.
◼ In the process each step is carefully defined with
verifiable entry and exit criteria, methodologies
for performing the step, and verification
mechanisms for the output of the step.
◼ In this process both the development and
management processes are formal.
42
 Level 4: Managed
◼ Quantitative goals exist for process and
products.
◼ Data is collected from software processes,
which is used to build models to characterize
the process.
◼ Hence, measurement plays an important role
in a process at this level.
◼ Due to the models built, the organization has
a good insight of the process capability and
its deficiencies.
◼ The results of using such a process can be
predicted in quantitative terms 43
 Level 5: Optimizing
◼ The focus of the organization is on
continuous process improvement.
◼ Data is collected and routinely analyzed to
identify areas that can be strengthened to
improve quality or productivity.
◼ New technologies and tools are introduced
and their effects measured in an effort to
improve the performance of the process.
◼ Best software engineering and management
practices are used throughout the
organization. 44
CMM maturity levels

◼ Most organizations will be assessed

at level 1 initially. Improving to
higher levels involves large efforts at
organization and process
management. Level 5 has been
achieved by only a few organizations

45
 CMM
◼ can be used to assess the current level of
the process of an organization
◼ In a level, process has some capabilities
and lays the foundation for next level
◼ For moving from one level to another, CMM
specifies areas to focus on
◼ Is used heavily by sw industry

46
EARNED VALUE ANALYSIS

47
 Earned Value - What is it?
◼ Simply, it is a project monitoring and
measurement system that:
1. establishes a clear relationship between planned
accomplishments and actual accomplishments
2. reinforces and rewards good planning practices
◼ An approach to measuring progress in a
software project is to calculate how much
has been accomplished
48
 Earned Value Analysis
◼ Consist of Basic measures to calculate how much
has been accomplished
◼ Percent of the estimated time that has been completed
◼ Basic Measures
◼ Budgeted Cost of Work (BCW)
◼ The estimated effort for each work task
◼ Budgeted Cost of Work Scheduled (BCWS)
◼ The sum of the estimated effort for each work task that was
scheduled to be completed by the specified time
◼ Budget at Completion (BAC)
◼ The total of the BCWS and thus the estimate of the total effort of
the project
Earned Value Analysis
◼ Basic Measures
◼ Planned Value (PV)
◼ PV = BCW/BAC
◼ The percentage of the total estimated effort assigned to
a particular work task
◼ Budgeted Cost of Work Performed (BCWP)
◼ The sum of the estimated efforts for the work tasks
completed by the specified time
◼ Actual Cost of Work Performed (ACWP)
◼ Sum of the actual efforts for the work tasks that have
been computed
 Summary
◼ Cost, in the form of Earned Value or BCWP,
can be used to analyze progress of a project
◼ Using Earned Value data to make critical
project decisions must be based on careful
analysis of data, variances and trends

51
 Error Tracking
◼ Error tracking is keeping track of the errors that have
occurred and the inter-error times (the time between
occurrences of the errors)
◼ This can be used to make decisions about when to
release software.
◼ Makes software developers aware of the significance
of errors and error reduction
◼ The effects of changes in the software process can be
seen in the error data
◼ Making the errors and error detection visible
encourages testers and developers to keep error
reduction as a goal.
52
 Error Rates
◼ The error rate is the inverse of the inter-error time.
◼ Instantaneous error rate
◼ if an error occur every 2 days, then

◼ Instantaneous error rate= ½= 0.5 errors/day.

◼ is a good estimate of the current error rate.
◼ Cumulative error rate
◼ the sum of all the errors found divided by the total
time
◼ is a good estimate of future error rates
◼ As most errors are corrected (the faults
removed), the error rates should go down
and the inter-error times should be increasing53
 Error Graphs
◼ Plotting this data can show trends in the error
rate (errors found per unit time).
◼ Fitting a straight line to the points is an
effective way to display the trend.
◼ The trend can be used to estimate future
error rates.
◼ When the trend crosses the x-axis, the
estimate of the error rate is zero, or there are
no more errors. 54
 Error Graphs
◼ If the x-axis is number of errors, the value of
the x-intercept can be used as an estimate of
the total number of errors in the software
◼ If the x-axis is the elapsed time of testing,
the intercept is an estimate of the testing
time necessary to remove all errors.
◼ The area under this latter line is an estimate
of the number of errors originally in the
software 55
 EXAMPLE
◼ Consider the following error data (given as
the times between errors): 4, 3, 5, 6, 4,6, 7
◼ The instantaneous error rates are the
inverses of the inter-error times:
◼ 0.25,0.33, 0.20, 0.17, 0.25, 0.17, and 0.14.
◼ Plotting these against error number gives a
downward curve, as shown on next slide.
◼ This suggests that the actual error rate is
decreasing 56
◼ A straight line through the points would intersect the
axis about 11.
◼ Since this implies that the error rate would go to
zero at the eleventh error, an estimate of the total
number of errors in this software would be 11
errors.
◼ Since seven errors have been found, this suggests
that there may be four more errors in the software
57