Software Engineering [Work In Progress]

Software Project Management

Author: Matteo Bertini
Version: 0.1
Copyright: by-nc-sa


Software is everyday more present in any activity, and even more will be in the future.

We can say: We will need more and more software.

Software success factors

  • Well educated developers (technically and socially).
  • Better engineering (usage of a process, continuous process improvement, helping tools)
  • Appropriate Technologies (object oriented programming, components)
  • Reuse (of processes and programs)

What is Software

From IEEE glossary:

"Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system"

So, the software is not only a program with it’s own data, but also the world of informations around it, preceding the software (requirements, specification, models…) and following it (documentation).

Software have as target:

  • a particular customer
  • general market

and can be developed:

  • as a new project,
  • as a configuration of something already done,
  • using parts of a previous work.

Software is a systematically developed technological product characterized by a defined set of properties.

What is a program

From IEEE glossary:

"A combination of computer instructions and data definitions that enable computer hardware to perform computational or control functions"

A program is the main part of a software, when we have only a program we have a legacy software.

Software properties

Software is not the same engineering product, it has some particular property:

  • software is immaterial
  • common sense cannot always help
  • a metaphor as software maintenance can be misleading
  • a copy is not different from the original (but the original is still there in the shop!! It is different from stealing!)
  • software is not build but developed
  • reuse is attractive if effort for reusing is limited
  • often developers (1) overestimate own capacity or (2) underestimate project complexity (or both!).
  • software building blocks are immaterial
  • used languages influence software properties
  • software is a complex product
  • costs are necessary hight
  • software reflect reality
  • based on a model of reality
  • must change with it
  • is no a linear function
  • hard to test

Good software properties

"The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable

Maintainable: software must be modifiable to follow reality evolutions
Dependable: we want to trust software
Efficient: efficient resource usage
Acceptable: must be accepted by the user, so must be understandable, usable and compatible with other customers systems.

What is software engineering

From Sommerville:

"Software engineering is an engineering discipline that is concerned with all aspects of software production"

… or better software development.

Software engineering should take a systematic and organized approach, use tools and techniques tailed to the problem and to system limits and available resources.

From IEEE glossary:

  1. The application of a systematic, disciplined, quantifiable approach to the developement, operation and manteniance of software; that is, the application of application engineering to software.
  2. The study of approaches as in (1)

Something very abstract, Prof. suggests:

"Software engineering is any activity for developing or modifying software"

As any other engineering activity, we have to:

  • cost is the most important factor
  • standard exists to be used
  • modularity is good
  • support quality.

Software engineering goals

We want to produce successful software.

So, both software and process must be:

  • effective
  • fast
  • cheap

but problem arise because of:

  • complexity of algorithms and hard understandability of programs
  • quantity is a crucial factor, we must use abstraction.

Software engineering methods

Sommerville says:

"Structured approaches to software developement which include system models, notation, rules, design advice and process guidance"

Software engineering use:

  • graphical models to describe the system
  • well defined rules
  • hints for best practices
  • process guidance, step to step

System triangle

Methods, Languages e Tools connected by common concepts.

Methods are: OOD, OOH, refactoring, …
Languages: Java, UML, C++, …
Tools: R. Rose, Eclipse, Poseidon, …
concepts are: objects, messages, inheritance, classes, …

Software life cycle

Generic software life cycle

Every software is developed in steps, every step represents wishes.

Components are tested individually, then throughout the integration following a predefined structure we have the final product.

Software is put in operations, and modified or corrected according to the needs.

At the end of the life cycle can be a retirement or substitution phase.

Software life cycle

Time lapse from the conception to the retirement of software.

Software life consists of some default phases: concept, requirements, design, implementation, test, installation and checkout, operation and maintenance, and sometime retirement or substitution.

  Top level design  
  Detailed design  
  Coding e test  
  Integration, test, Acceptance
  Operation, Maintenance
  • Which are customers problems?
  • How can software help solving them?
  • Which are main software functionality?
Requirements specification
  • Which are software requirements?

Requirements are the contract between customer and developer.

Requirement Specification is the foundation of the following development, so must be well done.

(better stressing the customer 20 times before, to be sure having the right idea, then arguing later)

Design, top level and detailed
  • Define software components.
  • Design architecture.
  • Define interfaces between components.
  • Define components functionality.

Design produces Software Architecture

Coding and Test

When components are coded, it’s time to test.

  • Every component is tested following the specification (unit test).
  • Identified errors are corrected.

This phase ended with coded and tested components.

Integrations, Test, Acceptance
  • Components are assembled following the architecture.
  • Interfaces are tested (integration test).
  • Acceptance Test verify software and customer environment compatibility.

This phase end with the (delivered system).

Operation and Maintenance

This phase starts with the system installation in the client environment and the subsequent putting in operation.

The Maintenance phase consists in the correcting of errors arose during installation and subsequent use.


Software is immutable in an evolving reality, so it can be old.

We have to start thinking of a substitution with some advance:

   |               '               '                      '
   |            * *'*              '                      '       +
   |         *     '   *           '           * *        '     +
   |       *       '       *       '        *       *     '    +
   |     *         '           *   '     *             *  '   +
   |   *           '               *  *                   *  +
   |  *            '               '                      ' +*
   | *             '               '                      '+    *
   |*              '               '                      +
   ----------------o---------------o----------------------o-------------------> Time
      Developement    Maintenance        Reeginering        New Developement

Software engineering costs

Software engineering costs vary depending on:

  • type of system
  • requirements (performance, quality, reliability, …)

Cost distribution depends on the model used, but in general:

60% Developement 40% Test
in waterfall model:
  • 60% Developement
  • 15% Specification
  • 25% Design
  • 20% Implementation
  • 40% Integration & Test
in iterative development:
  • 10% Specification
  • 60% Iterative developement
  • 30% System test
in component based development:
  • 20% Specification
  • 30% Components development
  • 50% Integration and test

Software engineering panorama summary

  • Software is a complex product (tell it to the customer).
  • Software properties make development hard (see over).
  • Software must be developed in a systematic manner => Software Engineering.
  • Software use languages, tools and methods based on common concepts.
  • Software development is a stepwise process (activities and phases).

Software Project Management

Project management connects and coordinates any activity in the project development:

 ___________             Documents        _______________
/  Quality  \        <---------------    / Configuration \
\ Assurance /                            |   and Change  |
 ´´´´´´´´´´´ >--------.                  \   Management  /
      ^       Reports _\____________      ´´´´´´´´´´´´´´´
      |              /    System    \             ^
      |              \ Construction /             | Plan
       \              ´´´´´´´´´´´´´´              | Data
   Plan  \                   Y                   /
   Data    \     ________________________       /  Achievement
             \_\ |                      |\   <-'      Data
               / |  Project Management  | |
                 |______________________| |

What is a Project

A project is a set of activities, interactions and results aimed at achieving a defined goal, provided limited resources and limited time.

Or by Kerzner 2002:

"Any series of activities and tasks that have a specific objective to be completed within certain specification, have a defined start and end dates, have founding limits (if applicable) and consume resources (money, people, equipment, …)"

Properties of a project

A project is defined by a temporary limited and unique task that provide answers to the following questions:

  • What? – Define goals.
  • When? – Time: start, end.
  • Who? – Teams.
  • Whereby? – Resources.
  • How? – Project organization and model.

Project roles

  • Manager: responsible of the development project (from inside).
  • Team members: Analyst, Architect, Programmer, Tester, Configuration Manager, Reviewer, …
  • Client/Customer: Placer orders, decide and accept.
  • Users: yes… involve them.
  • Development Organization: place, cafè, hardware, contracts, …

Kinds of Projects

We have mainly three kinds of project:

  • Internal project: client and developers are part of the same organization, software will be used internally and conflicts are solved by the chief.
  • Ordered project: client and developer agree on a contract, conflicts may be solved juridically.
  • Development project: client is the marketing division, and product is offered and sold by the company, money came from a development budget.

Often a project is a mixture of these three kinds.

What is project management

A task oriented definition could be (Thayer 1987):

"A system of procedures, practices, technologies and know-how that provides the planning, organizing, staffing, directing and controlling, necessary to successfully manage an engineering project."

A goal oriented definition could be (Sommerville):

"Concerned with activities involved in ensuring that software is delivered on time and within budget and in accordance with the requirements of the organizations developing and procuring the software."

Why do projects fail

Projects mainly fail because of:

  • improper management
  • fixation of first estimate
  • wrong level of details
  • first-time-seen tools
  • too many people
  • poor communication
  • rewarding the wrong actions

IT projects fail too because of:

  • ill-defined or changing requirements
  • poor planning / management
  • uncontrolled quality
  • unrealistic expectation / inaccurate estimate
  • naive adoption of a new technology

Problems are the same:

  • software is immaterial
  • there is no standard process
  • experience transition is difficult (better having a superposition lapse with two project managers)

Project managers common mistakes

  • start coding without analysis
  • do not define requirements and quality goals
  • do not follow a process model
  • set unrealistic deadlines (knowing that)
  • use first-time-seen tools
  • do not manage risks
  • do not check project deliverables
  • do not test systematically

Success factors

  • small teams
  • risk management
  • good manager
  • good communication
  • right person for the right work
  • clear requirements
  • user involvement
  • realistic and up-to-date schedule

Goals of project management

We want to: Produce all deliverables with required quality within time and resources.

We’d like also to:

  • give a positive impression
  • acquire know-how
  • think reusable
  • keep an attractive working environment (Google balloons)

Project management overview

Project management activities are mainly four:

  1. Planning
  2. Tracking
  3. Controlling
  4. Reporting

Project management areas are:

  • Scopehow much?
  • Workwhat?
  • Qualityhow?
  • Peoplewho?
  • Riskwhat if?

Tasks of project management

Project planning
  • define goals
  • analyze environment
  • structure tasks/activities to be performed
  • panning quality issues
  • preparing the schedule
  • planning resources
  • planning costs and budget
  • planning risk management
Project organization
  • define roles
  • delegate authority and responsibility
  • set up a communication structure
Team management
  • select people
  • engage a team
  • promoting people
  • motivate people
  • solve conflicts
  • release the team
Project controlling
  • define measures to control quality, deadlines, resources and costs
  • measure project progresses
Risk management
  • identify the risks
  • evaluate the risks
  • define mitigation and contingency measures

Project management prerequisites

Project manager needs:

  • procedures to measure project progress
  • procedures to estimate costs
  • procedures to plan activities, schedule, …
  • to understand the development process
  • to have realistic estimation if own abilities
  • to have experience
  • to work in an appropriate environment

Project manager skills

To do this, a good project manager should have:

  • Technical skills (rised from the ranks)
  • economical, application, software engineering, …
  • Project management skills
  • planning, estimating, controlling, time-managing, negotiating, …
  • Leadership skills
  • communication, decision, delegation, motivation, moderation, …
  • Personal skills
  • responsibility, toughness, team spirit, patience, ability to communicate, fairness, …

Why do project manager fail

  • experience and education
  • learning by doing school
  • expectation of senior management
  • no time, no personnel, …
  • expectation of the client
  • specify better, with the client…
  • team members
  • they should work systematically, follow standards, documents results
  • own demand
  • management and technical work

Project management phases

Project development is a continuous activity, composed of three phases regardless the model used:

  • Initial phase
  • Development
  • Final phase

Initial phase

Time from the order to the start of development.


  • defining scope
  • planning project
  • staffing
  • analyzing the environment


  • setting up structures and information for the project running

Development phases

Deliverables are produced according the plan, every phase is financed individually and structured following a process model.

Final phase

The project is finished in a controlled manner, tasks to be performed after the project end are identified and assigned.

Experience is collected and documented.

Resource distribution

Rough plot of resource distribution:

    |                  '             *   *           '
    |                  '        *            *       '
    |                  '    *                   *    '
    |                  ' *                        *  '
    |                 *'                            *'
    |              *   '                             '*
    |           *      '                             '  *
    |      *           '                             '     *
    | *                '                             '        *
    -------------------o-----------------------------o---------------------> Time
       Initial phase           Development phase         Final phase
         Planning                 Controlling            Terminating

Project management summary

Project management is a prerequisite for a successful project and must be a whole time continuous activity.

Main tasks of project management are:

  • planning
  • controlling
  • team management
  • risk management

Project managers must have the right skills (social, technical, …)

A project must follow a structured path:

  • starting phase
  • development phase
  • final phase

Starting a project

Initial phase

In the initial phase the project manager has to define the project goals, estimate resources (personnel and skills), estimate costs and time, identify risks and provide a communication and work infrastructure.

Sometime when costs and deadline are known, project manager must plan backwards.

Initial phase objectives

At first we must define all projects goals and deliverables working in co-operation with the customer.

Then we have to evaluate the first draft, assessing the technical feasibility and economics factors as Return On Investments.

We start then planning the project, the project definition phase consists of:

  • defining project organization,
  • assigning responsibilities
  • identifying risks

We have to communicate pertinent information to all stake-holders.

And we have always to remember, in any project, at any time, we have the no-go option!

Initial phase structure

Initial phase begins when:

  • a customer asks a quotation based on a tender document.
  • Somebody has a product idea

Someone (project manager) has to collect enough information for a sensible go/no-go decision, money and time needed for this phase are usually a development organization effort.

Initial phase ends when:

  • we start the project
  • we decide not to go.

Rough graph of uncertainty in the project:

HIGH  ^  Uncertainty
      |            '            '
      |  *  *  *  *' *  .       '
      |       Rough Goal   *    '
      |            '          * '
      |            '            *
      |            '  Project   ' *
      | Pre-Study  ' Definition '   *
      |            '            '     *
      |            '            '        * .
      |            '            '             * * * * *
 LOW  |------------o------------o-------------------------------> Time
            Initial Phase            Planning, Execution, ...

Project Goals

A project goal is everything the project has to produce and deliver.

All stake-holders have to be involved in the goals definition phase.

Good projects have:

  • Precise goals and requirements
  • Quantifiable goals
  • Achievable goals

Goals contradictions

Goals can be contradictory, especially in big and complex projects.

Contradictions have to be identified and resolved, and project manager has to ensure the achievability of goals.

For example: Money, Quality and Time:

       \ O O
        O   O ----> Quality
         O O
 Costs /

Goals and non-Goals

All the goals form the definition sheet, sometime is useful include in the formulation non-goals too.


Goal: Write english docs.
non-Goal: Translate docs in other languages.

Scope management

Scope management is the phase dedicated to defining and controlling what is included in the project and what is not.

We have to deliver all we have planned and nothing more.

Scope management ensure development is not late for wrong directed efforts.

Scope management has a mayor rule in backwards projects (defined deadline and costs).

At the end of this phase we have the Requirement Specification sheet.

Controlling the project scope

Project scope can be subject of changes, enhancements, new requirements, errors, …

Any new information must follow a common path:

                                         ( Technical impact, )
                                         (  Budget, Market,  )
 ----------------                        (   Schedule, ...   )
| Request change |                      / ```````````````````
 ---------------- --->  ----------------                           * REJECT
                       | Analyze change |                        / * POSTPONE
                        ---------------- --->  ----------------  /
                                              | Decide  change |
                                               ----------------  \
                                                                   * ACCEPT -> Implement

Project definition sheet

Project Name

  • Motivation: Why? ROI, …
  • Goals: goals, sub-goals, time, costs, quality
  • Products & deliverables: What?
  • Description: Tasks, cost estimation, Milestones
  • Stake-holders & organization: customer, manager, team, controller, …
  • Major Risks: results of an initial risk assessment.
Checklist of the project definition
  • Is each goal is:
  • defined explicitly and accurately?
  • achievable?
  • Important non-goals are defined?
  • Contradictions are resolved?
  • Schedule and budget estimation are realistic?
  • Stake-holders accept goals and estimation?
  • Important risks are identified and assessed?

Initial phase summary

Essential phase, we should make a sound go/no-go decision.

Initial phase (afters goals and scope definition) produces:

  • project definition
  • initial project plan

The initial phase consumes real resources.

Project planning

Project planning is probably the most time-consuming activity in project management, it consists in a continuous activity from the initial concept to the system delivery, and must be revised as new information becomes available.

A plan is a model of the future, so it’s never correct, but we have to do our best to follow the plan.

If we do not plan we have no sound bases for:

  • estimating duration and budget
  • controlling what we have done and what is left.

Plans are more important in highly dynamical environment and if something is unclear.

Issues to be planned

What should we plan?

  • Deliverables (quality)
  • Dates
  • Resources (people and budget)
  • Work (what, which order)

We have to answer the following questions:

  • Why do we run the project?
  • What do we have to do?
  • How much money and other resources do we need?
  • Who is doing what?
  • When do we start and when are we finished?

From the IEEE glossary:

"A project plan is a document that describes the technical and management approach to be followed for a project"

Typically a plan describes:

  • the work to be done,
  • the resources required,
  • the methods to be used,
  • the procedures to be followed,
  • the schedules to be met,
  • and the way the project will be organized.

Different plans exist:

  • Quality, Validation, Configuration, Management, Training, …

Work organization


Activities are the unit of work in a project, if an activity is big, can be decomposed in sub-activities till reaching the atomic-activity level (activity that can be performed by a few people in a short time, with well defined inputs and outputs).

S.M.A.R.T properties of activities

  • Specific: goal oriented.
  • Measurable: we must measure progresses.
  • Assignable: one responsible.
  • Ralistic: on time and resources.
  • Time related: deadline.
Work packages

A work package is an activity that can be performed by a single person or a small group in 2-4 weeks. A work package must have clear (visible) results that can be checked against its requirements.

A work package memory is composed by:

  • effort estimation
  • deadlines
  • results
  • actual cost

Work packages are a sort of contract between project manager and developers.

Estimation of global remaining efforts, controlling and work balancing are based on work packages.


Milestones are defined points in time during the project where defined results have to be available.

A milestone consists of:

  • defined results
  • quality attributes
  • deadline
  • eventually an external milestone committee

Based on the quality perceived, the customer (steering committee) can decide to continue (staring a new phase) or cancel the project.

There are two common kinds of milestones:

  • External (gate with go/no-go decision)
  • Internal (controlling)

Activity planning

Before planning we have to identify every activity needed to reach our goals.

Experience shows that a graphical visualization can help.

Work Breakdown Structure

The Work Breakdown Structure consists of a tree of activities of descending load, ending with atomic activities as leafs.

Activities are decomposed by phases and by components:

1. Project                    (1)                                 (   Develop   Software   )
   -------                   /   \                               /     /          \         \
                            /     \                            /      /            \          \
2. Main Tasks          (1.1)       (1.2)         (Requirements)   (Design)   (Implementation)  (Tests)
   ----------          /   \           \          |                    :             :            :
                      /     \           \         |
3. Sub-Tasks     (1.1.1)   (1.1.2)     (1.2.3)    o- Interview with customer
   ---------        :       /   \         :       o- Create Req. Spec.
                   :       /     \         :      :
4. Work Packages     ( (

Decomposition can follow a top-down approach:

Project + decomposition criteria => main tasks => work packages

or a bottom-up approach:

Activities are collected, a part-of relationship is defined, a WBS draft is drawn and then completed with missing activities.

We can check if a WBS is complete with two rules:

  • Disjunction rule: all activities of a level must be completely distinct.
  • Completion rule: any decomposition must cover every aspect of the parent activity.

We can check if an activity is truly atomic controlling if:

  • we are able to measure the progress,
  • start and stop dates are defined,
  • we can estimate costs and duration,
  • work can be performed independently from other activities.

A work package can be further decomposed in tasks in a subsequent planning.

At the end of the WBS we have to check for completeness/overload against the goals/non-goals.

The WBS are an important activity, that, if performed completely, can provide the basis for:

  • scheduling
  • cost estimation
  • resource allocation
  • project tracking e controlling
WBS good practices

Better design a WBS chart jointly with all the team members:

  • common understanding,
  • common terminology,
  • use synergies,
  • motivate people,
  • publicize overall project goals.

Precedence planning and time schedules

Once we have a complete WBS we have to find out and explicitate logical and temporal sequences between the activities.

We have to do:

  • precedence planning,
  • duration estimation.

We have some method at different deepness to clarify the situation.

Milestone list: A simple list of the most important events and related functionalities.
Bar chart (Gantt chart):
  Every activity has a start and end time, the resulting bar is placed on a calendar.
Precedences and time overlapping activity are clearly visible.
Activity network plan:
  Same as Bar chart, but is possible to express also logical precedences between work packages.
On an Activity network plan is possible to find out easily the critical path in the project.
Critical path

The critical path in a project is a sequence of non overlapping activities that, if delayed, imply all the project is delayed.

As for a recipe:

  • set water and salt of the ring
  • make the sauce
  • when water boils, put pasta
  • wait past is "al dente", put out water and put in sauce

… and eat!

we can estimate the duration of the activities:

  • set water and salt of the ring: 1 min, no dependencies
  • make the sauce: 5 min, no dependencies
  • when water boils, put pasta: 10 min, can-start-if-done set water and salt of the ring
  • wait past is "al dente", put out water and put in sauce: 10 min, can-start-if-done when water boils, put pasta, and can-stop-if-done make sauce.

in this case the critical path is:

  • set water and salt of the ring (1)
  • when water boils, put pasta (10)
  • wait past is "al dente", put out water and put in sauce (10)

So the make sauce activity can be started late or extended (for a maximum of 16 minutes together) without affecting the project deadline.

But, if we want a complex sauce, lets say, that require 30 minute work, than the critical path is only the make the sauce activity, we can see: 1 min + 10 min + 10 min = 21 min (pasta time) < 30 min but the sauce must be ready when past is "al dente" !!!

In this simple example we have already a good example of the importance of good estimations, only with a good estimation we can follow the deadline.

Let see some algorithm:

  • Every activity has:
  • a duration d
  • we will calculate:
  • an Early Start Time EST and an Early Finish Time EFT
  • a Late Start Time LST and a Late Finish Time LFT

We proceed with two steps (from Dijkstra shortest path):

Forward calculation:

  • EST(start) = 0
    we start NOW
  • EFT(i) = EST(i) + d(i)

    we will finish as soon as possible

  • EST(j) = max(EFT(pj)) where pj are all j predecessor.
    we can start the next step only when all predecessor are done, that is when the last predecessor is done

Backwards calculation:

  • LFT(end) = EFT(end)
    we cannot do better
  • LST(i) = LFT(i) – d(i)
    to be in time we should start right what we have estimated before
  • LFT(j) = min(LST(sj) where sj are all j successors.
    a previous activity must be finished before the first subsequent start

Done this we have an important information, the Slack Time of every activity:

ST(i) = LST(i) – EST(i) = LFT(i) – EFT(i)

that is the time an activity can be moved without affecting project duration.

Activities with no Slack Time (ST == 0) are on the critical path, and should be carefully monitored.

Issues of resource planning

We have to plan:

  • human resources,
  • technical resources,
  • money.
Human resources planning

We have to plan required skills for the project development in advance, keeping in mind that both overloaded people and enormous teams are not a Good Thing (TM).

No solution here!

Project Management Tools

There are a quite number of tools aimed to help the project manager planning and monitoring work, they help in visualization, automatic report generation, agenda reminders, shortest path calculation and so on.

Planning summary

Plans are the foundation for a running project.

Investments in planning is a Good Thing (TM).

We should:

  • publicize the plan,
  • work to follow the plan.

Choose and use the right tools.

Common errors are:

  • no planning
  • too detailed planning
  • only time schedule plan

Project manager don’t like planning because:

  • it takes time
  • you have to think
  • you have to use paper and pencil
  • you are bounded in a systematic procedure
  • they will see you are late!

Risk management

We have to manage risks because:

  • no project has no risk
  • especially first-of-its-kind has hight risk

so we have to identify and assess risks.

Often project manager doesn’t like thinking about risks and sometime risk managing techniques are not known.

A software risk is a potential problem with a likelihood and an effect.

There are more kind of risks:

  • Project risk, effecting the schedule,
  • Product risk, effecting quality and performances,
  • Business risk, effecting the procuring or the selling of something.

Risk management aims at identifying and planning to minimize risks effect on the project.

Definition of Risk Engineering from SEI:

Cover all activities that are necessary in order that risks do not become problems.

  • Risk Engineering
  • Risk Analysis
  • Identification
  • Estimation
  • Evaluation
  • Risk Management
  • Planning
  • Controlling
  • Monitoring

Goals of risk management

Set up a culture where risks are: identified, assessed, communicated and managed proactively.

The other why is called "Crisis management".

Risks management process

Risk management is a continuous process based on good communication:

            /              \
 _         /                \
 /'       /       Comm       \        \
|  Monitoring     unic     Analyzing   |
 \        \       ation      /       |/.
           \                /
            \              /
              - Planning -
Risk Identification

Identification is difficult, we have to look in the future.

Experience of former project can help:

  • colleagues
  • database

We should collect the experience!! Learning by doing.

A good method is to use check lists covering the most important aspects of a project:

  • People
  • Technology
  • Process
  • Organization
  • Requirements
  • Tools
  • Estimation
Risk analysis

The goal of risk analysis is to assess and prioritize risks.

We assign a discrete value at risk’s likelihood and effect:


  1. low
  2. moderate
  3. high


  1. tolerable
  2. serious
  3. catastrophic
Risk planning

We consider three main measures in risk planning:

Avoidance measures:
  we try to reduce likelihood.
Minimization measures:
  we try to reduce effects.
Contingency measures:
  what to do if risk arise.

To chose the right measure we can use a common assessment formula:

          Risk Value = Likelihood * Effect
|\_____   L    |    (3)    |    (2)     |    (1)    |
|   E  \______ |    High   |  Moderate  |    Low    |
|     (3)      | H H H H H | H H H H H  |           |
| Catastrophic | H H H H H | H H H H H  |  M M M M  |
|     (2)      | H H H H H |            |           |
|   Serious    | H H H H H |  M M M M   |     L     |
|     (1)      |           |            |           |
|  Tolerable   |  M M M M  |     L      |     L     |

Risk assessment:

L*E: Likelihood * Effect
1*1: nothing
1*2: monitor probability
2*1: monitor effects
1*3: minimization + contingency
3*1: nothing or avoidance
2*2: avoidance + minimization
2*3: avoidance + contingency
3*2: avoidance + minimization
3*3: ALL! no-go?
Risk monitoring

Assess identified risk regularly to monitor probability and effect changes, better during a periodic meeting.


Good communication is a prerequisite of effective risk management, all relevant people must be involved and informed (customer, steering committee, upper management).

We’d like to have a risk proactive culture.

Risks documentation

Experience in risk management is very important, we can accumulate experience in a useful way with a detailed status report.

Benefits of risk management

Risks are identified and communicated.

Measures are planned proactively.

Continuos assessment of the situation.

We can learn from the past.

Risk management summary

Every project has risks

Risk management is:

  • identify risks
  • plan a measure
  • assess the situation again

Checklist are a simple and useful technique.

We aim to a culture of risk-talking management.

Project controlling

Project controlling techniques provide metrics and measurement procedures to assess the actual project progress, useful to compare actual results to planned schedule and budget.

This append by establishing controlling standards and producing a periodical project status report, for just-in-time control measures and future reference.

Controlling, naturally, is a continuous process!

Involved rules

Main roles involved in controlling are:

  • Customer (wait and hope)
  • Project Owner (informs about Progresses, External Milestones)
  • Project Manager (informs about Internal and External Milestones)
  • Programmer (informs about work progress)

Management control cycle

We can summarize in the following graph the control cycle:

| +----------+ | /                      BIG CHANGE
| | Project  | |<----------------------------------
| | Planning | | \     change the plan            |
| +----------+ |                                  |
+--------------+                                  |
       |                                          |
       |            +------------+   small  +-----+----+
       |            | Corrective |<---------| Analize  |
       |     +------| control    |  change  | Resoults |
       |     |      | Measures   |          +----+-----+
       |     |      +------------+              /|\
      \|/   \|/                                  |
       '     '                            +------+-------+
   .//---------\\.                        | +----------+ |
 //  Realization  \\                      | |Comparison| |
|    of Plan and    |                     | |to Plans  | |
|      Control      |                     | +----------+ |
 \\.   Measures  .//                      +-------+------+
    \\----+----//                                /|\
          |                                       |
          |              +-----------+            |
          |            \ | Measuring |            |
          +------------->| Project   |------------+
                       / | Progesses |

Measuring progresses

We need to know as soon as possible if there are deviations from the schedule in the project development, to do this our most important unit of control are the work packages.

We need to monitor every week the effort spent on every package. To do this in a big project we need a supporting tool.

We define a set of indicators:

                             actual effort
Degree Of Completion    = -------------------
                    EfS     planned  effort

This DoF indicator, based on the actual effort is very dependent from a good planning… and planning is rarely SO good.

We can create a new parameter, the estimate to complete, an estimate that we hope to be more precise in going on in the project.

Using the estimate to complete we can have a more realistic forecast final effort as:

forecast final effort = actual effort + estimate to complete

and then a new Degree Of Completion formula can be:

                                actual effort
Degree Of Completion    = -------------------------
                    ETC     forecast final effort

Sometime in a big project is not possible to have actual data every week (estimate to complete and actual effort)

Another useful parameter can be the earned value, based only on the, estimate to complete and the initial planned effort:

earned value = planned effortestimate to complete

So the new Degree Of Completion formula is:

                            earned value
Degree Of Completion   = ------------------
                    EV     planned effort

We can summarize the meaning of the three Degree Of Completion formulas:

                             actual effort         actual work done,
Degree Of Completion    = ------------------- =  normalized by planned
                    EfS     planned  effort            efforts

                                actual effort           actual degree of
Degree Of Completion    = ------------------------- =  completion  in the
                    ETC     forecast final effort       updated deadline

                            earned value         degree of completion
Degree Of Completion   = ------------------ =  based only on the latest =
                    EV     planned effort        estimate to complete

                          1     estimate to complete
                       = 11 - ------------------------
                          1        planned effort

Costs monitoring

As for time, we need to monitor costs too, we ca do this using a few parameters:

C_a = accumulated costs = labour + investments costs

C_frc = forecasted reminder costs to complete the project = entered commitments + cost to complete

A we have an estimate of total costs as forecasted Total costs, a sum of:

C_ftc = C_a + C_frc = what spent + what we will spend

Trend analysis

An easy but important visualization tool is the Trend Analysis graph:

Forecasted Competion
     .  Date
     +------------------------------------------------------+  +------+---------------+
     |                                                    //|  | **** | Requirements  |
     |                                                  //  |  +------+---------------+
     |                                                //    |  | ++++ | Architecture  |

30/05+----------------------------------------------//      |  +------+---------------+
     |                     ++                     // |      |
     |                  +++                     //   |      |
     |++++++++++++++++++                      //     |      |
     |                                      //       |      |
     |                                    //         |      |
15/05+----------------------------------//           |      |
     |          *********             // |           |      |
     |       ***         ****       //   |           |      |
     |*******                     //     |           |      |
     |                          //       |           |      |
     |                        //         |           |      |
30/04+----------------------//           |           |      |
     |                    // |           |           |      |
     |                  //   |           |           |      |
     |                //     |           |           |      |
     |              //       |           |           |      |
     |            //         |           |           |      |
15/04+----------//           |           |           |      |
     |        // |           |           |           |      |
     |      //   |           |           |           |      |
     |    //     |           |           |           |      |
     |  //       |           |           |           |      |
     |//         |           |           |           |      |
     +-----------+-----------+-----------+-----------+------+--> Reporting
               15/05       30/04       15/05       30/05         dates

Analyzing the graph we can see that:

  • initial forecasts are too optimistic,
  • architecture forecast are reviewed late, only after a week we know requirements will be late.

Control measures

If we are late we must do something, various ways are possible:

  • Planned deliverables cannot be produced:
  • increase productivity (motivation, control),
  • increase resources (beware communication overhead of big staffs),
  • reduce deliverables.
  • Completion date will be exceeded:
  • increase resources,
  • reduce deliverables,
  • concentrate efforts on the critical path (to reduce the overall duration).
  • Planned costs will be exceeded:
  • delegate to (cheep) subcontractors,
  • reduce the quality.

We always have to inform the customer of the various possibilities and agree on a modification (deadline, quality or cost).

Project controlling summary

Project monitoring and controlling are continuous activities.

Monitoring is possible only with a plan (strange no?).

A comparison between plan and actual status must be the basis of a control measure.

We ha to collect actual performance data for future reference.

Controlling is based on work packages, work and schedules.

Software process models

A software development process is an activity composed by (possibly overlapping) steps that translate user needs in a software product:

  • user needs are translated in software requirements,
  • requirements are translated in design,
  • design is implemented in code,
  • code is tested,
  • (sometime) software is installed and checked onsite.


Before we can start a software development project we have to answer the following questions:

  • What is the scope and what are the goals of the project?
  • What are the resources and the time we need to produce the project deliverables?
  • How should we organize the project?
  • Is there a process model we have to apply?
  • Should we customize the chosen process model?
  • What language, methods and tools are we going to use?
  • What are the skills we need during the project?

Code and Fix (the italian politics way)

Coding and correcting together with ad-hoc tests are the only activities performed consciously (sometime as in the italian politic way, ad-hoc tests are inexistent, the only test is it runs!).

At the end, system as no guaranties to conform to the real requirements, coding and correction is a domino effort increasing with time, and normally, documentation lacks.

But this is the most common model perhaps!

Waterfall model

Waterfall model is well know model supporting project management:

  • System Analysis
  • System Specification
  • System Design
  • Module Specification and Design
  • Code and Module-Test
  • Integration and System Test
  • Operation and Maintenance

Every time an error is found control go back to the originating step. The problem is that user feedback comes often too late.

Incremental development

The basic idea is: we won’t develop the system as a whole.

Feedback is possible in short time, but due to the absence of an executable system is based only on a good requirement specification.

Iterative development

Iterative development is defined as a:

"Controlled continuous revision of software aiming at correcting errors early and integrate improvements"

"We get things wrong before we get them right"

Main differences to the waterfall model are:

  • Requirements are a moving material:
  • software usage induces software requirement modification.
  • Maintenance activities are integrated in the development process.

Rational Unified Process

RUP is a generic process model and has to be customized before application.

It is based on use cases and prototyping:

Prototypes are good for:

  • minimize risks
  • demonstrate progresses

The process is intrinsically incremental and use UML formalism whenever possible.

RUP defines 4 development phases and a set of disciplines.

Any discipline is performed in any phase, and phases can be iterated more times.

RUP assumes software is conceived in an object oriented manner.

RUP is organized in two dimensions:

  • Work (disciplines):
  • how do what,
  • Requirement -> Analysis & Design -> Implementation -> Test cycle,
  • project management, environment, configuration and change management.
  • Phases:
  • work is organized in subsequent phases,
  • each phase complete with a successful milestone test.

RUP phases

Product development is done in several development cycles, each cycle consists of 4 phases and deliver a product release, each phase can require several iterations.

RUP phases are:

  • Inception
  • Elaboration
  • Construction
  • Transition


  • define project goals, deliverables and costs,
  • check high risk requirements.


  • identify use cases,
  • make a risk analysis,
  • define: success criteria (important deliverables), resources and important milestones.

Main question:

Should we start (continue) the project?


  • Vision document
  • Model of the application domain <— we need a domain expert!!
  • Important requirement list (10%-20% of all use cases).
  • Draft project plan with important milestones.
  • Draft costs estimation.
  • List of deliverables.
  • Glossary of common terms: communication is important both with client and collaborators.

Entry condition:

  • Project was started


  • Analyze and understand the application domain.
  • Design the software architecture.
  • Eliminate high project risks.


  • Work out use cases in detail.
  • Identify and formulate non-functional requirements.
  • Construction of the first prototype.
  • Creating the project plan.

Main questions:

Do we know what to deliver?

Do we have an appropriate architecture?

Can we control the risks?


  • Top level architecture:
  • All use cases are identified, 80% already are detailed.
  • Model of the application domain.
  • Chosen development technology.
  • Non-functional requirements.
  • Inspection report:
  • software architecture,
  • most important use cases.
  • Prototype.
  • Revisited Project Plan.

Entry conditions:

  • Project plan and defined architecture.


  • Implementing the project based on the architecture.


  • Select use cases to implement.
  • Detail use case (if necessary).
  • Revise architecture (if necessary).
  • Implement the use case.
  • Test the resulting system.

Main question:

Can we use the system?


  • Tested system.
  • User documentation.
  • System documentation of developed release.

Entry conditions:

  • Beta release of the software


  • Correct errors.
  • Integrate user feedback in the system.
  • Measure system quality
  • If necessary, improve development process.

Main questions:

Are all requirements implemented?

Do we have to perform a further cycle?

RUP structure

The process is represented by a workflow.

Workflow is populated by roles

A role perform an activity and is responsible for an artifact.

The artifact is the memory of the project.

RUP Disciplines

Disciplines in RUP are four:

  • Business Modeling
  • Requirements
  • Analysis and Design
  • Implementation

The first discipline, Business Modeling is to be performed with a Business domain expert and lies out our goals.



  • Describe what the system should do
  • Define boundaries of the system (scope)
  • Identify non-functional requirements


  • Use Cases
  • Non-functional requirements
  • Glossary
Analysis and design


  • requirements, design model of preceded iterations.


  • Define how the system should be build.


  • Use Case design:
  • Identify the influence of use cases to object model.
  • Work out dynamical use cases as interaction diagrams.
  • Development / Revision of the object model:
  • Revising existing class diagram.
  • Define a package structure.
  • Architectural design:
  • Define top level architecture.
  • Map classes / packages on components.


  • Revised design model.


  • Design model.


  • Implement all classes.
  • Ensure specification adherence.


  • Generate code framework from model design (automatic if possible).
  • Implement operation and other missing parts.
  • Perform class test (unit test).
  • Integrate tested classes in the existing environment.


  • Working tested system.

Process customization

Project my differ vastly, RUP can be customized in regard of:

  • project kind,
  • complexity and size,
  • culture of the organization.

We can evaluate how many:

  • Artifact and Document produce: we should produce only what is a value for the organization.
  • Workflow and Roles activate: in small project activities and roles can be combined.

Software Process Model Summary

RUP as a sum of many years of processes,


  • Excellent configuration and change management (TOOLS)
  • High management abilities
  • Know of in OOD and related languages (UML).


  • Deep monitoring and controlling.
  • Excellent documentation for the future.


  • Difficult to customize due to the numerous predefined interactions (customization means less tool support).
  • Unstable definition of the process (and so hard replication).
  • Stable, suggested work order (sometime cannot fit).

Software Process Improvement

Develop software is hard, everyone has a own best way.

Due to immaterial ground, invisible results, often software is the biggest problem in a complex system (Train, Airplane, Rocket, ..)

Software Engineering Institute CMM

Software Engineering Institute was founded by the Department of Defense of USA to:

  • Analyze software development in industry
  • Analyze research on software engineering
  • Develop method for process improvement
  • Transfer research into practice
  • Do consulting service.

Levels of maturity

CMM define a set of four levels of maturity for organization, every level contains previous levels:

  • (1) Initial (uncontrolled)
  • disciplined process -> (2) repeatable (project and configuration management)
  • standard, consistent process -> (3) defined (formally defined process)
  • predictable process -> (4) managed (measured process)
  • continuously improving process -> (5) optimizing (optimized process)

Maturity Level:

  • a well defined evolutionary plateau on the path to becoming a mature organization,
  • each level is a foundation for a continuous improvement process.

Process Area:

  • a set of related practices performed to achieve a set of goals,
  • each area reside in a given maturity level,
  • process areas define the process capability of the organization.
KPA, Software Project Planning


  • Documentation of software estimates for planning and tracking
  • Planning of software project activities
  • Agreement of affected group and individuals for commitments

Commitment to perform:

  • Designated responsible project manager for negotiating commitments and developing the project plan.
  • The project follow a written organizational policy for planning.

Ability to perform:

  • Existence of a documented and approved statement of work.
  • Assignment of responsibilities for developing the project plan.
  • Adequate funding and resources for the project planning.
  • Training of individuals involved in project planning.

Activities performed:

  • Participation of the software engineering group on the project proposal team.
  • Software project planning is initiated early and in parallel with overall project planning.
  • Participation of the software engineering group in the project’s life.
  • Commitments are reviewed with senior management in a documented procedure.
  • A (project-specific) software life cycle with predefined stages is identified or defined.
  • The software development plan is developed in a documented manner.
  • The plan for the software project is documented.
  • Software products are identified and configuration management is set.
  • Size estimates are derived following a documented procedure.
  • Effort and cost estimates are from a documented procedure.
  • Critical computer resources are defined from a documented procedure.
  • Software schedule is derived from a documented procedure.
  • Risks are identified, assessed and documented.
  • Tool supporting the project are prepared.
  • Planning data are recorded.

Measurement and analysis:

  • Measurements provide the status of the software planning activities

Verifying implementation:

  • Activities are reviewed with senior management periodically.
  • Activities are reviewed with project manager on a periodic or event-based basis.
  • Software quality is reviewed by a specific group that release a report.
Livello 1, initial
  • Uncontrolled process
  • No standards
  • Overcommitment, frequent out of time/budget
  • Dependence on individuals (heroes)
  • Constant firefighting
Livello 2, repeatable
  • Some experience is collected and process has some guidelines
  • Each project is managed as individual
  • No organization-wide standards
  • Key process areas:
  • Requirement management
  • Project Planning
  • Project Tracking
  • Subcontractor management
  • Quality insurance
  • Configuration management
Livello 3, defined
  • Process management is institutionalized (software engineering process group).
  • Process is formally defined
  • There is an organization-wide standard process usage
  • Key process areas:
  • Organization process focus
  • Organization process definition
  • Training program
  • Integrated software management
  • Software product engineering
  • Inter-group coordination
  • Peer reviews
Livello 4, managed
  • Metrics are defined and used
  • Quantitative goals are defined
  • Variation occurs within known bounds
  • Key process areas:
  • Quantitative process management
  • Software quality management
Livello 5, optimizing
  • Processes are continuously optimized
  • Both process and technology changes are managed
  • Key process areas:
  • Defect prevention
  • Technology change management
  • Process change management



Comments are closed.