Chapter 22: An Overview of Software Project Management

1
Chapter 22 An Overview of Software Project
Management

• 22.1 Introduction
• Good software project management is an absolute
  necessity for the success of the overall project
  but it is difficult.
• Software development is performed in teams
• only very very small projects are developed by a
  single person from beginning to end
• teams are made up of different people with
  various expertise and clear roles software
  analysts, software designers, programmers,
  testers, GUI designers etc.
• -gt The work of these software engineers must be
  coordinated and managed managing the people.
• But before a project can be started, and while it
  is ongoing, we must consider the problem at hand
• The objectives and scope of the project must be
  initially considered (without this we cannot
  estimate the overall cost, duration etc. of the
  project)
• The problem at hand is likely to evolve during
  the duration of the project this must be
  strictly managed.

2

• -gt The problem at hand must be clearly defined
  throughout the project managing the problem.
• Finally, we must be able to manage the process
  used to develop the software this is true
  whatever the development process model used
• are we on time?
• where are the problems?
• Etc.
• -gt The project itself must be managed managing
  the process.
• Hence we have highlighted the three main areas of
  software project management
• Managing the people
• Managing the problem
• Managing the process

3

• 22.2 Managing the People
• Software project management is principally
  concerned with managing people !
• In software development the most important asset
  of a company is its staff.
• Staff may include, team managers, software
  analysts, software designers, programmers,
  testers, administration staff etc.
• A team leader must
• Motivate encourage technical people to produce
  their best, reward achievements
• Organise the work of the staff must be organised
  to allow software development to take place
• Foster Communication to allow people to exchange
  ideas and be creative
• Build a Successful Team Environment handle
  personal conflicts.
• This is not an easy task.
• Ultimately, a team leader is responsible for
  everything.

4

• 22.3 Managing the Problem
• 22.3.1 In the Beginning
• A manager must deal at the beginning of a project
  with many questions to be answered but with very
  little information available
• Can we do it?
• How long will it take?
• How much will it cost?
• Will the intended users' problems be addressed?
• All this relate to being able to define the
  problem that needs to be solved.
• Initially we need to very quickly define the
  software scope
• Context how will the software fit into its
  future environment? (e.g. part of a business, a
  process, is embedded). What constraints (e.g.
  performance, legislative, dependability) are
  imposed on the project as a result of the
  context?
• Data what outputs and inputs will the software
  have to manipulate?
• Functionalities what will be the broad
  functionalities of the software?

5

• Only after having identified the scope of the
  software can we give estimates to the set of
  initial questions (e.g. cost, duration).
• 22.3.2 During the Development
• After agreeing to embark on a software project,
  it is likely that the initial problem will evolve
  over time.
• This is due to
• The initial problem is not likely to have been
  fully specified new problem characteristics will
  emerge
• Whoever commissioned the project is likely to
  come up with new ideas
• Unforeseen technical problems will make the
  project more difficult.
• Management must ensure that these modifications
  to the problem stay within the original scope of
  the problem.
• The more the problem changes the more risky the
  project.

6

• 22.3.3 After Delivery
• During software maintenance requests for changes
  will be made management must carefully evaluate
  the extent of the changes to be made before
  committing to them.
• 22.3.4 Informal Estimation Techniques
• As just seen, managing the problem must be done
  to ensure that reliable estimates can be issued
  and are respected.
• Estimation is one of the main activity in
  software project management.
• This is a complex area and affects cost
  estimation, project duration and staffing.
• Informally
• As seen, we need at least a definition of the
  problem's scope before issuing estimates
• We can rely on past experience based on similar
  projects that we have developed
• We can analyse other people's projects that are
  similar
• We can break the project into small pieces and
  estimate them individually.

7

• 22.4 Managing the Process
• 22.4.1 In the Beginning
• As seen in the last chapter, a manager needs to
  select and document an appropriate software
  development process for the current project.
• This is not easy and requires skills and
  judgement.
• This choice will have consequences for staffing
  levels, maybe costs, duration, organisation of
  the team and the project schedule.
• 22.4.1.1 Scheduling
• A project must have a schedule.
• For flexibility, the initial schedule may leave
  some areas relatively fuzzy these can be
  reviewed as the project progress and more is
  learnt about the problem.

8

• However given a particular development process, a
  schedule must at the very least
• Identify a set of tasks to be completed
• Identify interdependence between tasks
• Identify major milestones and deliverables
• Contain review periods (e.g. the plan next cycle
  in a spiral model)
• Estimate effort needed for each tasks
• Estimate resources needed
• Result in a task network.
• All of this will have an impact on the earlier
  estimates that were given.
• A task network may be represented on a Gantt
  chart (example on next slide).
• Large projects should use a Computer Aided
  Software Engineering (CASE) tool to help with the
  scheduling of tasks (e.g. implement PERT method)
  e.g. www.criticaltools.com.
• An initial schedule is unlikely to be fully
  respected as the project progresses the project
  needs to be managed and controlled in an on-going
  basis.

9
(No Transcript)
10

• 22.4.2 During the Development
• During the development of the software the
  process needs to be managed and controlled in an
  on-going basis.
• In addition to the issues relating to the problem
  and the people, issues that a manager has to keep
  track in process management during the duration
  of a project include
• Will the schedule be respected?
• Will the costs estimations be respected?
• Are we following the actual development process
  model chosen?
• Is the quality of the work so far sufficiently
  high?
• This is process tracking.
• To answer these questions a manager must be able
  to
• Identify current difficulties as early as
  possible
• Resolve current difficulties
• Foresee future difficulties (I.e. perform risk
  analysis).

11

• 22.4.2.1 Identifying Current Difficulties
• Good team work is invaluable team members must
  feel confident enough to highlight difficulties
  and not conceal them
• In addition Measures and Metrics can help in this
  area (also in others such as initial
  estimations).
• 22.4.2.2 Measures and Metrics
• Measurement is fundamental to engineering
  disciplines a little less so in software
  engineering currently. The CMM insists on
  measurements from Level 4 upwards.
• Measurements in the physical world ca be
  categorised in 2 ways
• Direct measures e.g. number of lines of code,
  execution speed, actual duration of a task.
• Indirect measures (Also Known As metrics) e.g.
  quality, complexity, testability.
• Direct measures are easy to collect.
• Indirect measures (aka metrics) are difficult in
  software engineering because software is mostly
  an intellectual product.

12

• Metrics are based on direct measures I.e. direct
  measures are combined together in a metric and
  applied to give a quantitative value about a
  characteristic of the entity that is measured.
• Example of basic relationships between metrics
  and direct measures

13

• The problem comes from agreeing what to measure
  and how to combine these measures to end up with
  a meaningful metric that is a true reflection of
  the characteristic that we wish to measure a
  highly controversial area.
• Many metrics exist in software engineering, e.g.
• To indicate the quality of a technical document
• To access the productivity of team members
• To assess the benefits (in terms of productivity
  and quality gains for example) derived from new
  software engineering methods and tools
• To assess the complexity of a piece of code
• Metrics can obviously help in project management.

14

• Examples of metrics
• Assessing the quality of a past project plan
• (actual project duration) div (estimated project
  duration)
• Estimating effort (in person-months)
• AB(Kloc)C
• where A is a constant in person-months, B is a
  constant of person-months (Kloc)-c, C is
  without dimension
• Metrics can be very complex they have their
  usages but must be handled with care.
• 22.4.2.4 Resolving Difficulties
• If it is detected that problems are occurring
  (e.g. the schedule is slipping, the work of a
  team member is poor, this part of the design
  needs improving) the project manager must try to
  alleviate them.
• 22.4.2.5 Foresee future difficulties (I.e.
  perform risk analysis).
• Obviously it is better if difficulties do not
  arise at all and if they do it is better if
  their impact is minimal.

15

• These are the goal of risk analysis.
• Risks are always linked to unknowns and
  unexpected.
• As seen it is an integral part of the spiral
  model of software development it should be
  carried out in all projects.
• 22.5 Conclusions
• Effective project management is very difficult.
• But it is obviously essential.