Software Project

management
Lecture 2:
PROJECT MANAGEMENT
Introduction
Software project management is an essential part of software engineering.
Projects need to be managed because professional software engineering is always subject to
organizational budget and schedule constraints.
The project manager’s job is to ensure that the software project meets and overcomes these
constraints as well as delivering high-quality software.
Good management cannot guarantee project success.
However, bad management usually results in project failure: the software may be delivered late,
cost more than originally estimated, or fail to meet the expectations of customers
The success criteria for project management obviously vary from project to project but, for most
projects, important goals are:
1. Deliver the software to the customer at the agreed time.
2. Keep overall costs within budget.
3. Deliver software that meets the customer’s expectations.
4. Maintain a happy and well-functioning development team.
Why is Software management is
different?
➢ software engineering is different from other types of engineering in a
number of ways that make software management particularly
challenging. Some of these differences are:
➢ The product is intangible: A manager of a shipbuilding or a civil engineering
project can see the product being developed. If a schedule slips, the effect on the
product is visible—parts of the structure are obviously unfinished.
Software is intangible. It cannot be seen or touched. Software project managers
cannot see progress by simply looking at the artifact that is being constructed.
Rather, they rely on others to produce evidence that they can use to review the
progress of the work.
➢ Large software projects are often ‘one-off’ projects: Large software projects are usually
different in some ways from previous projects. Therefore, even managers who have a large
body of previous experience may find it difficult to anticipate problems.

➢ Software processes are variable and organization-specific: The engineering process for some
types of system, such as bridges and buildings, is well understood.
However, software processes vary quite significantly from one organization to another.
 Software project manager
It is impossible to write a standard job description for a software project manager. However,
most managers take responsibility at some stage for some or all of the following activities:
✓Project planning: Project managers are responsible for planning, estimating and scheduling
project development, and assigning people to tasks.
✓Reporting: Project managers are usually responsible for reporting on the progress of a project
to customers and to the managers of the company developing the software. They have to be
able to communicate at a range of levels, from detailed technical information to management
summaries.
✓Risk management: Project managers have to assess the risks that may affect a project, monitor
these risks, and take action when problems arise.
✓People management: Project managers are responsible for managing a team of people. They
have to choose people for their team and establish ways of working that lead to effective team
performance.

✓Proposal writing: The first stage in a software project may involve writing a proposal to win a
contract to carry out an item of work. The proposal describes the objectives of the project and
how it will be carried out. It usually includes cost and schedule estimates and justifies why the
project contract should be awarded to a particular organization or team.
Risk management
Risk management is one of the most important jobs for a project manager. Risk management
involves anticipating risks that might affect the project schedule or the quality of the software
being developed, and then taking action to avoid these risks
You can think of a risk as something that you’d prefer not to have happen. Risks may threaten
the project, the software that is being developed, or the organization.
 Risk Types
There are, therefore, three related categories of risk:
✓Project risks: Risks that affect the project schedule or resources. An example of a project risk is
the loss of an experienced designer. Finding a replacement designer with appropriate skills and
experience may take a long time and, consequently, the software design will take longer to
complete.

✓Product risks: Risks that affect the quality or performance of the software being developed. An
example of a product risk is the failure of a purchased component to perform as expected. This
may affect the overall performance of the system so that it is slower than expected.
✓Business risks: Risks that affect the organization developing or procuring the software. For
example, a competitor introducing a new product is a business risk. The introduction of a
competitive product may mean that the assumptions made about sales of existing software
products may be unduly optimistic
Of course, these risk types overlap. If an experienced programmer leaves a project this can be a
project risk because, even if they are immediately replaced, the schedule will be affected. It
inevitably takes time for a new project member to understand the work that has been done, so
they cannot be immediately productive.
Consequently, the delivery of the system may be delayed. The loss of a team member can also
be a product risk because a replacement may not be as experienced and so could make
programming errors.
Finally, it can be a business risk because that programmer’s experience may be crucial in
winning new contracts.
Methodologies
You should record the results of the risk analysis in the project plan along with a consequence
analysis, which sets out the consequences of the risk for the project, product, and business.
Effective risk management makes it easier to cope with problems and to ensure that these do not
lead to unacceptable budget or schedule slippage.
The specific risks that may affect a project depend on the project and the organizational
environment in which the software is being developed. However, there are also common risks
that are not related to the type of software being developed and these can occur in any project.
Some of these common risks are shown in Figure
Risk management
Risk management is particularly important for software projects because of the inherent
uncertainties that most projects face.
These stem from loosely defined requirements, requirements changes due to changes in
customer needs, difficulties in estimating the time and resources required for software
development, and differences in individual skills.
You have to anticipate risks; understand the impact of these risks on the project, the product,
and the business; and take steps to avoid these risks.
You may need to draw up contingency plans so that, if the risks do occur, you can take
immediate recovery action.
Risk management stages
1. Risk identification: You should identify possible project, product, and business risks.
2. Risk analysis: You should assess the likelihood and consequences of these risks.
3. Risk planning: You should make plans to address the risk, either by avoiding it or
minimizing its effects on the project.
4. Risk monitoring: You should regularly assess the risk and your plans for risk mitigation and
revise these when you learn more about the risk.
You should document the outcomes of the risk management process in a risk management plan.
This should include a discussion of the risks faced by the project, an analysis of these risks, and
information on how you propose to manage the risk if it seems likely to be a problem.
The risk management process is an iterative process that continues throughout the project.
Once you have drawn up an initial risk management plan, you monitor the situation to detect
emerging risks.
As more information about the risks becomes avail able, you have to reanalyze the risks and
decide if the risk priority has changed.
You may then have to change your plans for risk avoidance and contingency management.
Risk identification
Risk identification is the first stage of the risk management process. It is concerned with
identifying the risks that could pose a major threat to the software engineering process, the
software being developed, or the development organization.
Risk identification may be a team process where a team get together to brainstorm possible
risks.
Alternatively, the project manager may simply use his or her experience to identify the most
probable or critical risks.
As a starting point for risk identification, a checklist of different types of risk may
be used.
Risk checklist
There are at least six types of risk that may be included in a risk checklist:
1. Technology risks: Risks that derive from the software or hardware technologies that are used
to develop the system.
2. People risks: Risks that are associated with the people in the development team.
3. Organizational risks: Risks that derive from the organizational environment where the
software is being developed.
4. Tools risks: Risks that derive from the software tools and other support software used to
develop the system.
5. Requirements risks: Risks that derive from changes to the customer requirements and the
process of managing the requirements change.
6. Estimation risks: Risks that derive from the management estimates of the resources required
to build the system.
Risk analysis
During the risk analysis process, you have to consider each identified risk and make a judgment
about the probability and seriousness of that risk.
There is no easy way to do this. You have to rely on your own judgment and experience of
previous projects and the problems that arose in them.
It is not possible to make precise, numeric assessment of the probability and seriousness of each
risk. Rather, you should assign the risk to one of a number of bands:
1) The probability of the risk might be assessed as very low ( 10%), low (10–25%), moderate (25–
50%), high (50–75%), or very high ( 75%).
2) The effects of the risk might be assessed as catastrophic (threaten the survival of the project),
serious (would cause major delays), tolerable (delays are within allowed contingency), or
insignificant.
Risk planning
The risk planning process considers each of the key risks that have been identified, and develops
strategies to manage these risks.
For each of the risks, you have to think of actions that you might take to minimize the disruption
to the project if the problem identified in the risk occurs.
You also should think about information that you might need to collect while monitoring the
project so that problems can be anticipated.
Again, there is no simple process that can be followed for contingency planning. It relies on the
judgment and experience of the project manager.
Risk management strategies:
These strategies fall into three categories:
1) Avoidance strategies Following these strategies means that the probability that the risk will
arise will be reduced.
2) Minimization strategies Following these strategies means that the impact of the
risk will be reduced.
3) Contingency plans Following these strategies means that you are prepared for the worst
and have a strategy in place to deal with it.
You can see a clear analogy here with the strategies used in critical systems to ensure reliability,
security, and safety, where you must avoid, tolerate, or recover from failures.
Obviously, it is best to use a strategy that avoids the risk. If this is not possible, you should use a
strategy that reduces the chances that the risk will have serious effects.
Finally, you should have strategies in place to cope with the risk if it
arises. These should reduce the overall impact of a risk on the project or product.
Risk monitoring
Risk monitoring is the process of checking that your assumptions about the product, process,
and business risks have not changed. You should regularly assess each of the identified risks to
decide whether or not that risk is becoming more or less probable.
You should also think about whether or not the effects of the risk have changed.
To do this, you have to look at other factors, such as the number of requirements change
requests, which give you clues about the risk probability and its effects.
These factors are obviously dependent on the types of risk.
You should monitor risks regularly at all stages in a project. At every management review, you
should consider and discuss each of the key risks separately. You should decide if the risk is
more or less likely to arise and if the seriousness and consequences of the risk have changed.
Risk types:
Managing people
Managing people
The people working in a software organization are its greatest assets. It costs a lot to recruit and
retain good people and it is up to software managers to ensure that the organization gets the
best possible return on its investment. In successful companies and economies, this is achieved
when people are respected by the organization and are assigned responsibilities that reflect their
skills and experience.

It is important that software project managers understand the technical issues that influence the
work of software development. Unfortunately, however, good software engineers are not
necessarily good people managers. Software engineers often have strong technical skills but
may lack the softer skills that enable them to motivate and lead a project development team.
As a project manager, you should be aware of the potential problems of people management
and should try to develop people management skills.
People management factors
✓Consistency: People in a project team should all be treated in a comparable way. No one
expects all rewards to be identical but people should not feel that their contribution to the
organization is undervalued.
✓Respect: Different people have different skills and managers should respect these differences.
All members of the team should be given an opportunity to make a contribution.
✓Inclusion: People contribute effectively when they feel that others listen to them and take
account of their proposals. It is important to develop a working environment where all views,
even those of the most junior staff, are considered.
✓Honesty: As a manager, you should always be honest about what is going well and what is
going badly in the team. You should also be honest about your level of technical knowledge and
willing to defer to staff with more knowledge when necessary.
Motivating people
As a project manager, you need to motivate the people that work with you so that they
contribute to the best of their abilities.

If people are not motivated, they will not be interested in the work they are doing.
They will work slowly, be more likely to make mistakes, and will not contribute to the broader
goals of the team or the organization.

To provide this encouragement, you should understand a little about what motivates people.
Maslow (1954) suggests that people are motivated by satisfying their needs.
People Personality type
Personality type also influences motivation. Bass and Dunteman (1963) classify professionals
into three types:
1. Task-oriented people, who are motivated by the work they do. In software engineering, these
are people who are motivated by the intellectual challenge of software development.

2. Self-oriented people, who are principally motivated by personal success and recognition.
They are interested in software development as a means of achieving their own goals. This does
not mean that these people are selfish and think only of their own concerns. Rather, they often
have longer-term goals, such as
career progression, that motivate them and they wish to be successful in their work to help
realize these goals.
3. Interaction-oriented people, who are motivated by the presence and actions of co-workers. As
software development becomes more user-centered, interaction- oriented individuals are
becoming more involved in software engineering.

Interaction-oriented personalities usually like to work as part of a group, whereas task-oriented

and self-oriented people usually prefer to act as individuals
Teamwork
Most professional software is developed by project teams that range in size from two to several
hundred people. However, as it is clearly impossible for everyone in a large group to work
together on a single problem, large teams are usually split into a number of groups.
Each group is responsible for developing part of the overall system. As a general rule, software
engineering project groups should not have more than 10 members.
When small groups are used, communication problems are reduced. Everyone knows everyone
else and the whole group can get around a table for a meeting to discuss the project and the
software that they are developing.
Putting together a group that has the right balance of technical skills, experience, and
personalities is a critical management task. However, successful groups are more than simply a
collection of individuals with the right balance of skills.
A good group is cohesive and has a team spirit. The people involved are motivated by the
success of the group as well as by their own personal goals.
In a cohesive group, members think of the group as more important than the individuals who
are group members.
The benefits of creating a cohesive group
are:
1. The group can establish its own quality standards Because these standards are established
by consensus, they are more likely to be observed than external standards imposed on the
group.
2. Individuals learn from and support each other People in the group learn from each other.
Inhibitions caused by ignorance are minimized as mutual learning is encouraged.
3. Knowledge is shared Continuity can be maintained if a group member leaves. Others in
the group can take over critical tasks and ensure that the project is not unduly disrupted.
4. Refactoring and continual improvement is encouraged Group members work collectively
to deliver high-quality results and fix problems, irrespective of the individuals who
originally created the design or program
Generic factors that affect team working:
1. The people in the group: You need a mix of people in a project group as software
development involves diverse activities such as negotiating with clients, programming,
testing, and documentation.
2. The group organization: A group should be organized so that individuals can contribute to
the best of their abilities and tasks can be completed as expected.
3. Technical and managerial communications: Good communications between group
members, and between the software engineering team and other project stakeholders, is
essential
Selecting group members
A manager or team leader’s job is to create a cohesive group and organize their group so that
they can work together effectively. This involves creating a group with the right balance of
technical skills and personalities, and organizing that group so that the members work together
effectively.
A group that has complementary personalities may work better than a group that is selected
solely on technical ability.
People who are motivated by the work are likely to be the strongest technically.
People who are self-oriented will probably be best at pushing the work forward to finish the job.
People who are interaction- oriented help facilitate communications within the group.
Group organization
The way that a group is organized affects the decisions that are made by that group, the ways
that information is exchanged, and the interactions between the development group and
external project stakeholders. Important organizational questions for project managers include:
1- Should the project manager be the technical leader of the group? The technical leader or
system architect is responsible for the critical technical decisions made during software
development. Sometimes, the project manager has the skill and experience to take on this role.
However, for large projects, it is best to appoint a senior engineer to be the project architect, who
will take responsibility for technical leadership.
2- Who will be involved in making critical technical decisions, and how will these be made? Will
decisions be made by the system architect, the project manager, or by reaching consensus
amongst a wider range of team members?
3- How will interactions with external stakeholders and senior company management be
handled? In many cases, the project manager will be responsible for these interactions, assisted
by the system architect if there is one. However, an alternative organizational model is to create
a dedicated role concerned with external liaison, and appoint someone with appropriate
interaction skills to that role.
4. How can groups integrate people who are not colocated? It is now common for groups to
include members from different organizations and people to work from home as well as in a
shared office. This has to be taken into account in group decision-making processes.
5. How can knowledge be shared across the group? Group organization affects information
sharing as certain methods of organization are better for sharing than others. However, you
should avoid too much information sharing as people become overloaded and excessive
information distracts them from their work.
Group communications
It is absolutely essential that group members communicate effectively and efficiently with each
other and with other project stakeholders. Group members must exchange information on the
status of their work, the design decisions that have been made, and changes to previous design
decisions.
They have to resolve problems that arise with other stakeholders and inform these stakeholders
of changes to the system, the group, and delivery plans. Good communication also helps
strengthen group cohesiveness.
Group members come to understand the motivations, strengths, and weaknesses of other
people in the group.
The effectiveness and efficiency of communications is influenced by:
Group size: As a group gets bigger, it gets harder for members to communicate effectively. The
number of one-way communication links is n * (n -1), where n is the group size, so, with a group
of eight members, there are 56 possible communication pathways. This means that it is quite
possible that some people will rarely communicate with each other.
Group structure: People in informally structured groups communicate more effectively than
people in groups with a formal, hierarchical structure. In hierarchical groups, communications
tend to flow up and down the hierarchy. People at the same level may not talk to each other.
This is a particular problem in a large project with several development groups. If people
working on different subsystems only communicate through their managers, then there are
more likely to be delays and misunderstandings.
Group composition: People with the same personality types may clash and, as a result,
communications can be inhibited. Communication is also usually better in mixed-sex groups
than in single-sex groups.
The physical work environment: The organization of the workplace is a major factor in
facilitating or inhibiting communications.
The available communication channels: There are many different forms of communication—
face-to-face, e-mail messages, formal documents, telephone, and Web 2.0 technologies such as
social networking and wikis. As project teams become increasingly distributed, with team
members working remotely, you need to make use of a range of technologies to facilitate
communications.
Software project
management plan
Outline
Concepts and terminology
Purpose of Software Project Management Plans
Structure of a Project Management Plan
Project responsibilities
Team structures
Project planning
Work breakdown structure
Communication Management
Dependencies
Schedule
Project Management Tools
Reference:
◦ Bruegge&Dutoit, Chapter 12
◦ http://notesbruegge.in.tum.de/PAID2/schedule/ProjectManagement011599.pdf

What is not covered in this lecture?

◦ Communication Management, Meeting Management
◦ Bruegge & Dutoit, Chapter 4
◦ http://notesbruegge.in.tum.de/PAID2/schedule/ProjectCommunication112598.pdf
◦ Cost estimation
◦ Reference: Software engineering economics, Barry Boehm, Prentice Hall 1981
Laws of Project Management
Projects progress quickly until they are 90% complete. Then they remain at 90% complete forever.

When things are going well, something will go wrong. When things just can’t get worse, they will.
When things appear to be going better, you have overlooked something.

If project content is allowed to change freely, the rate of change will exceed the rate of progress.

Project teams detest progress reporting because it manifests their lack of progress.
How it should go
Requirements
Analysis

Design

Implementation

System Testing

Delivery and Installation

Software Project Management Plan
Software Project:
◦ All technical and managerial activities required to deliver the deliverables to the client.
◦ A software project has a specific duration, consumes resources and produces work products.
◦ Management categories to complete a software project:
◦ Tasks, Activities, Functions

Software Project Management Plan:

◦ The controlling document for a software project.
◦ Specifies the technical and managerial approaches to develop the software product.
◦ Companion document to requirements analysis document: Changes in either may imply changes
in the other document.
◦ SPMP may be part of project agreement.
Project Agreement
Document written for a client that defines:
◦ the scope, duration, cost and deliverables for the project.
◦ the exact items, quantities, delivery dates, delivery location.

Can be a contract, a statement of work, a business plan, or a project charter.

Client: Individual or organization that specifies the requirements and accepts the project
deliverables.
Deliverables (= Work Products that will be delivered to the client):
◦ Documents
◦ Demonstrations of function
◦ Demonstration of nonfunctional requirements
◦ Demonstrations of subsystems
Project Agreement vs Problem Statement
Client Manager Project Team
(Sponsor)

Problem
Statement Software Project
Management Plan
Project
Agreement
Project Management Activities
(continued on next slide)

Initiation

Problem statement
definition

Initial top-level Initial milestones

design planning

Team formation Communication

infrastructure setup

Project kickoff
 Project kickoff
Steady state

Status monitoring Risk management

Project replanning Project agreement

Termination

Installation Client acceptance test Postmortem

Project: Functions, Activities and Tasks
f1:Function
p:Project
f2:Function

a1:Activity a2:Activity a3:Activity

a2.1:Activity a2.2:Activity a2.3:Activity

t1:Task t2:Task t3:Task t4:Task

Functions
Activity or set of activities that span the duration of the project

f1:Function
p:Project
f2:Function

a1:Activity a2:Activity a3:Activity

a2.1:Activity a2.2:Activity a2.3:Activity

t1:Task t2:Task t3:Task t4:Task

Functions
Examples:
◦ Project management
◦ Configuration Management
◦ Documentation
◦ Quality Control (Verification and validation)
◦ Training

Question: Is system integration a project function?

Mapping of terms: Project Functions in the IEEE 1058 standard are called Integral processes in
the IEEE 1074 standard. We call them cross-development processes
Tasks
f1:Function
p:Project
f2:Function

a1:Activity a2:Activity

a2.1:Activity a2.2:Activity

t1:Task t2:Task t3:Task

• Small enough for • Large enough

• Smallest unit
adequate planning to avoid micro
of work subject
and tracking management
to management
Tasks
Smallest unit of management accountability
◦ Atomic unit of planning and tracking
◦ Finite duration, need resources, produce tangible result (documents, code)

Specification of a task: Work package

◦ Name, description of work to be done
◦ Preconditions for starting, duration, required resources
◦ Work product to be produced, acceptance criteria for it
◦ Risk involved

Completion criteria
◦ Includes the acceptance criteria for the work products (deliverables) produced by the task.
Task Sizes
Finding the appropriate task size is Tasks must be decomposed into sizes that
problematic allow monitoring
◦ Todo lists from previous projects ◦ Work package usually corresponds to well
◦ During initial planning a task is necessarily defined work assignment for one worker for a
large week or a month.
◦ You may not know how to decompose the ◦ Depends on nature of work and how well task
problem into tasks at first is understood.
◦ Each software development activity identifies
more tasks and modifies existing ones
Examples of Tasks
Unit test class “Foo”
Test subsystem “Bla”
Write user manual
Write meeting minutes and post them
Write a memo on NT vs Unix
Schedule the code review
Develop the project plan
Related tasks are grouped into hierarchical sets of functions and activities.
Action item
 Action Item
Definition: A task assigned to a person that has to be done within a week or less
Action items
◦ Appear on the agenda in the Status Section
◦ Cover: What?, Who?, When?

Example of action items:

◦ Florian unit tests class “Foo” by next week
◦ Marcus develops a project plan before the next meeting
◦ Bob posts the next agenda for the Simulation team meeting before Sep 10, 12noon.
◦ The VIP team develops the project plan by Sep 18
Activities
f1:Function
p:Project
f2:Function

a1:Activity a2:Activity

a2.1:Activity a2.2:Activity

t1:Task t2:Task t3:Task

• Major unit of work • Consists of smaller • Culminates in project

with precise dates activities or tasks milestone.
Activities
Major unit of work Activities may be grouped into larger activities:
◦ Establishes hierarchical structure for project
Culminates in major project milestone: (phase, step, ...)
◦ Internal checkpoint should not be externally
◦ Allows separation of concerns
visible
◦ Precedence relations often exist among
◦ Scheduled event used to measure progress
activities (PERT Chart)
Milestone often produces baseline:
◦ formally reviewed work product
◦ under change control (change requires formal
procedures)
Examples of Activities
Major Activities: Activities during requirements analysis:
◦ Planning ◦ Refine scenarios
◦ Requirements Elicitation ◦ Define Use Case model
◦ Requirements Analysis ◦ Define object model
◦ System Design ◦ Define dynamic model
◦ Object Design ◦ Design User Interface
◦ Implementation
◦ System Testing
◦ Delivery
Structure of a Software Project
Management Plan
Front Matter
1. Introduction
2. Project Organization
3. Managerial Process
4. Technical Process
5. Work Elements, Schedule, Budget
Optional Inclusions
SPMP Part 0: Front Matter
Title Page
Revision sheet (update history)
Preface: Scope and purpose
Tables of contents, figures, tables
 SPMP Part 1: Introduction
1.1 Project Overview
◦ Executive summary: description of project, product summary

1.2 Project Deliverables

◦ All items to be delivered, including delivery dates and location

1.3 Evolution of the SPMP

◦ Plans for anticipated and unanticipated change

1.4 Reference Materials

◦ Complete list of materials referenced in SPMP

1.5 Definitions and Acronyms

 SPMP Part 2: Project Organization
2.1 Process Model
◦ Relationships among project elements

2.2 Organizational Structure

◦ Internal management, organization chart

2.3 Organizational Interfaces

◦ Relations with other entities

2.4 Project Responsibilities

◦ Major functions and activities; nature of each; who’s in charge
Process Model
Shows relationships among Visualization of process model
◦ Functions, activities, tasks
Project Management Aids
◦ Milestones
◦ MS Project (Microsoft)
◦ Baselines
◦ MAC Project (Claris)
◦ Reviews
◦ EasyTrak (Planning Control International)
◦ Work breakdown structure
◦ Project deliverables
◦ Sign-offs
Example of an Organization Chart
Client Management Consultants

Cross-functional Teams Development Teams

Architecture Logbook

HCI
Maintenance
Web Master

Documentation Vehicle

Configuration Mgt Travel

VIP

Infrastructure Team
Project Roles
Planner Group leader
Analyst Liaison
Designer Minute Taker
Programmer Project Manager
Tester
Maintainer
Trainer
Document Editor
Web Master
Configuration Manager
Project Roles
Management roles
◦ Organization and execution of the project within constraints. Examples: project manager, team
leader.

Development roles
◦ Specification, design and construction of subsystems. Examples: Analyst, system architect,
implementor.

Cross functional roles

◦ Coordination of more than one team. Example: API Engineer, configuration manager, tester

Consultant roles
◦ Support in areas where the project participants lack expertise. Examples: End user, client,
application domain specialist ( problem domain), technical consultant (solution domain).

Promoter roles
◦ Promote change through an organization.
Promoter Roles
Promoters are self appointed individuals who identify themselves with the outcome of the
project.
They are member of the corporate organization and may not necessarily be directly involved
with the project. Instead, they are interfaces to the rest of the corporate organization.
Because of the power, knowledge of technology, or familiarity with the project’s processes, they
are able to promote and push specific changes through the organization.
Power Promoter
Also called executive champion
Pushes the change through the existing organizational hierarchy.
◦ not necessarily at the top of the organization, but must have protection
from top level management, otherwise project opponents might be able
to prevent the success of the project.
Tasks:
◦ constantly identify difficulties, resolve issues, and communicate with the
project members, especially with the developers.
Example at project level: Project Manager.
Example at corporate level: Chief Executive Officer (CEO).
Knowledge Promoter
Also called the technologist,
Promotes change arising in the application domain or the solution domain. Usually
associated with the power promoter.
Tasks: Acquire information iteratively, understand the benefits and limitations of new
technologies, and argue its adoption with the other developers.
Example at project level: System architect.
◦ Reports to project manager
◦ Does not have any direct subordinate in the reporting hierarchy
◦ Has final say over all technical decisions in the system.

Example at corporate level: Chief Technical Officer (CTO).

Process Promoter
The process promoter has intimate knowledge of the projects processes and procedures.
The process promoter is in constant interaction with the power promoter to get
consensus on the overall goals.
Tasks: Bridge between the power and knowledge promoters, who often do not speak or
understand the same language.
Example at project level: Development lead. Responsible for the administrative aspects
of a project, including planning, milestones definition, budgeting and communication
infrastructure.
Example at corporate level: Chief Information Officer (CIO
Project Management: Hierarchical Project Organization

Control Flow
Information Flow Chief Executive

First Level Manager

(“Front-Line Manager”)

A B Project Members

A wants to talk to B: Complicated Information Flow

A wants to make sure B does a certain change: Complicated Controlflow

Basis of organization:
Complicated information and control flow
across hierarchical boundaries
 Example of Hierchical Organization:
Chief Programmer Team

Chief Programmer

Assistant
Chief Programmer

Senior Programmer Librarian Administration Tester

Junior Programmer
 Another Project Organization:
Egoless Programming Team (Weinberg)

Analyst

Tester Programmer

Designer Librarian
Project-Based Project Organization
Project
Leader

Coaches

Subsystem Team Subsystem Team Subsystem Team

A B Team
Members

A wants to talk to B: Communication Flow

A wants to make sure B does a certain change: Decision Flow

Basis of organization:
Nonlinear information flow across dynamically formed units
Associations in organizational structures
Reporting association:
◦ Used for reporting status information

Decision association
◦ Used for propagating decisions

Communication association
◦ Used for exchanging information needed for decisions (e.g., requirements, design models, issues).
Observations on Management
Structures
Hierarchical structures
◦ “Reports”, “Decides” and “Communicates-With” all mapped on the same association
◦ Do not work well with iterative and incremental software development process
◦ Manager is not necessarily always right

Project-based structures
◦ “Reports”, “Decides” and “Communicates-With”are different associations
◦ Cut down on bureaucracy reduces development time
◦ Decisions are expected to be made at each level
◦ Hard to manage
Hierarchical Structure
Projects with high degree of certainty, stability, uniformity and repetition.
◦ Requires little communication
◦ Role definitions are clear

When?
◦ The more people on the project, the more need for a formal structure
◦ Customer might insist that the test team be independent from the design team
◦ Project manager insists on a previously successful structure
Project-Based Structure
Project with degree of uncertainty
◦ Open communication needed among members
◦ Roles are defined on project basis

When?
◦ Requirements change during development
◦ New technology develops during project
 Assigning Responsibilities To People
“To Do” List for the Project Team A

Role 1
• Item 1 Person A
Item 1
• Item 2 Item 2
• Item 3 Item 9 Role 1
• Item 4 Role 2 Role 2
• Item 5 Item 4
• Item 6 Item 5
• Item 7 Item 7
Person B
• Item 8
• Item 9 Role 3
Item 3
Role 3
Item 6
Item 8
Possible Mappings of ToDos to People
One-to-One
◦ Ideal but often not worth to be called a project

Many-to-Few
◦ Each project member assumes several roles ("hats")
◦ Danger of overcommittment
◦ Need for load balancing

Many-to-"Too-Many"
◦ Some people don't have significant roles
◦ Bystanders
◦ Loosing touch with project
Team Formation
Top level Design
◦ “Rough” Subsystem Decomposition (before requirements analysis)
◦ Done during Predevelopment phase

Team Formation done after Top Level Design

Heuristics:
◦ One team for each subsystem
◦ One cross-functional task per team
◦ 5-7 members per team

Be prepared to iterate the team formation after system design when the subsystem
decomposition is baselined
Project Roles: Coach
Listen to gripes from individual teams
Review weekly team reports
Attend weekly project meetings
Schedule and prepare meetings with client
Insist that guidelines are followed
Assign presentations (in-class project meetings, client review, client acceptance test)
Resolve conflicts if they cannot be resolved otherwise
Project Role: Group leader
Responsible for intra-group communication (Meeting Management: Primary Facilitator)
◦ Run the weekly project meeting
◦ Post agenda before meeting
◦ Define and keep track of action items (who, what, when)
◦ Measure progress (Enforce milestones)
◦ Deliver work packages for the tasks to the project management
◦ Present problems and status of team to project manager

The group leader has to be rotated among members of the team.

Group Leader: Create an Agenda
Purpose of Meeting
Desired Outcome
Information Sharing
Action Items
Information Processing
(Check Previous
Meeting Critique Meeting)

Issues
(Check Previous
Meeting & BBoards)
Project Role: Liaison
Responsible for inter-group communication
◦ Make available public definitions of subsystem developed by the team to the architecture teams
(ensure consistency, etc)
◦ Coordinate tasks spanning more than one group with other teams

Responsible for team negotiations

Examples: API Engineer, Configuration manager
Project Role: Planner
Plans and tracks the activities of an individual team and has the following responsibilities.
Define project plan for team:
◦ PERT chart, resource table and GANTT chart showing work packages
◦ Enter project plan into project management tool

Make project plan available to management

Report team status to project manager

No explicit planner in PAID. Responsibilities assumed by coaches

Project Role: Document Editor
Collect, proofread and distribute team documentation
Submit team documentation to architecture team
Collect agendas
Take minutes at meetings
Web Master
Maintain team home page
Keep track of meeting history
Keep track of design rationale
Web Master:
Publish Meeting Information on Team Homepage
◦ Must contain Agenda, minutes, action items and issues
◦ Possibilities:
◦ One HTML document per meeting, with anchors (maintained by one role)
◦ Separate HTML documents for Agenda, Minutes, etc (maintained by several roles)

Date Agenda Minutes Action Items Issues

9/9/96 Agenda Minutes Action Items Issues

9/16/96 Agenda Minutes Action Items Issues

http://cascade1.se.cs.cmu.edu/
15-413/homePagesTeams/UserInterface/www/index.htm
 SPMP Part 3: Managerial Processes
3.1 Management Objectives and Priorities
◦ Philosophy, goals and priorities

3.2 Assumptions, Dependencies, Constraints

◦ External factors

3.3 Risk Management

◦ Identifying, assessing, tracking, contingencies for risks

3.4 Monitoring and Controlling Mechanisms

◦ Reporting mechanisms and formats, information flows, reviews

3.5 Staffing Plan

◦ Needed skills (what?, how much?, when?)
Examples of Assumptions
There are enough cycles on the development machines
Security will not be addressed
There are no bugs in Together-J, the CASE Tool recommended for the project
A demonstration of the Starnetwork system will be given by the client
Examples of Dependencies
The database team depends on the EPC database provided by DaimlerChrysler
The automatic code generation facility in the CASE tool depends on JDK. The current release of
Together-J supports only JDK 1.1.6
Examples of Constraints
The length of the project is 3 months. limited amount of time to build the system
The project consists of beginners. It will take time to learn how to use the tools
Not every project member is always up-to-date with respect to the project status
The use of UML and a CASE tool is required
Any new code must be written in Java
The system must use Java JDK 1.1.6
Risk Management
Risk: Members in key roles drop the Risk: One subsystem does not provide the
course. functionality needed by another
◦ Contingency: Roles are assigned to somebody subsystem.
else. Functionality of the system is ◦ Contingency: ?
renegotiated with the client.

Risk: The project is falling behind Risk: Ibutton runs only under JDK 1.2
schedule. ◦ Contingency: ?
◦ Contingency: Extra project meetings are
scheduled.
 SPMP Part 4: Technical Process
4.1 Methods, Tools and Techniques
◦ Computing system, development method, team structure, etc.
◦ Standards, guidelines, policies.

4.2 Software Documentation

◦ Documentation plan, including milestones, reviews and baselines.

4.3 Project Support Functions

◦ Plans for functions (quality assurance, configuration management).
 SPMP Part 5: Work Elements
5.1 Work Packages (Work breakdown structure)
◦ Project decomposed into tasks; definitions of tasks

5.2 Dependencies
◦ Precedence relations among functions, activities and tasks

5.3 Resource Requirements

◦ Estimates for resources such as personnel, computer time, special hardware, support software.

5.4 Budget and Resource Allocation

◦ Connect costs to functions, activities and tasks.

5.5 Schedule
◦ Deadlines, accounting for dependencies, required milestones
Creating Work Packages
Work Breakdown Structure (WBS) (Section 5.1)
◦ Break up project into activities (phases, steps) and tasks.
◦ The work breakdown structure does not show the interdependence of the tasks

The identification of the work breakdown structure is an instance of object identification and
associating these objects
WBS Trade-offs
Work breakdown structure influences cost and schedule
Thresholds for establishing WBS in terms of percentage of total effort:
◦ Small project (7 person-month): at least 7% or 0.5 PM
◦ Medium project (300 person-month): at least 1% or 3 PMs
◦ Large project (7000 person-month): at least 0.2 % or 15 PMs

Determination of work breakdown structure is incremental and iterative

Source: Software Engineering

WBS Schedule Economics, Barry W. Boehm
p. 47, Prentice Hall, N.J., 1981

Cost
(Time, $$)
Dependencies and Schedule
(SPMP Section 5.2 + 5.5)
An important temporal relation: “must be preceded by”
Dependency graphs show dependencies of the tasks (hierarchical and temporal)
◦ Activity Graph:
◦ Nodes of the graph are the project milestones
◦ Lines linking the nodes represent the tasks involved
◦ Schedule Chart (MS-Project):
◦ Nodes are tasks and milestones
◦ Lines represent temporal dependencies

Estimate the duration of each task

Label dependency graph with the estimates
Project Management Tools for Work
Packages
Visualization Aids for Project Presentation
◦ Graphs (Schedule), Trees (WBS)
◦ Tables (Resources)
Task Timeline
◦ Gantt Charts: Shows project activities and tasks in parallel. Enables the project manager to understand
which tasks can be performed concurrently.
Schedule Chart (PERT Chart)
◦ Cornerstone in many project management tools
◦ Graphically shows dependencies of tasks and milestones
◦ PERT: Program Evaluation and Review Technique
◦ A PERT chart assumes normal distribution of tasks durations
◦ Useful for Critical Path Analysis
◦ CPM: Critical Path Method
Project: Building a House
Activity 1: Landscaping the lot
◦ Task 1.1: Clearing and grubbing
◦ Task 1.2: Seeding the Turf
◦ Task 1.3: Planting shrubs and trees
Activity 2: Building the House
◦ Activity 2.1 : Site preparation
◦ Activity 2.2: Building the exterior
◦ Activity 2.3: Finishing the interior
Activity 2.1 : Site preparation
◦ Task 2.1.1: Surveying
◦ Task 2.1.2: Obtaining permits
◦ Task 2.1.3: Excavating
Task 2.1.4: Obtaining materials
Activity 2: Building a House, ctd
Activity 2.2: Building the exterior Activity 2.3 : Finishing the Interior
◦ Task 2.2.1: Foundation ◦ Task 2.3.1: Interior plumbing
◦ Task 2.2.2: Outside Walls ◦ Task 2.3.2: Interior electrical work
◦ Task 2.2.3: Exterior plumbing ◦ Task 2.3.3: Wallboard
◦ Task 2.2.4: Exterior electrical work ◦ Task 2.3.4: Interior painting
◦ Task 2.2.5: Exterior siding ◦ Task 2.3.5: Floor covering
◦ Task 2.2.6: Exterior painting ◦ Task 2.3.6: Doors and fixtures
◦ Task 2.2.7: Doors and Fixtures
◦ Task 2.2.8: Roof
Activity Graph for Activity “Building a House” ST ART

Build Outside Wall

Surveying
1.2 1.1
Excavation
1.3
Buy Materials
1.4
Lay Foundation
2.1
Build Outside Wall
Install Exterior Plumbing 2.2
Install Interior Plumbing

2.3 3.1
Install Exterior Electrical Install Interior Electrical
2.4 3.2
Install Exterior Siding Install Wallboard
2.5 3.3
Paint Exterior Install Flooring Paint Interior
2.6 3.4 3.5
Install Exterior Doors Install Roo¼ ng
Install Interior Doors
2.7 2.8 3.6

2.6 FINISH
 PERT Chart Example for "Building a
House"
12/3/94 12/21/94 1/11/95
Install Install Install
Interior Interior Wallboard
Plumbing Electrical
Building a House:
0 0 0 1/22/95
12 15 9 Paint
MS Project PERTcy
Interior
Chart with Duration of
Activities (Pfleeger 2.3) 0 2/8/95
11
1/22/95 Install
Interior
Install Doors
Flooring
0
10/15/94 11/5/94 7
8/27/94 8/27/94 9/17/94 10/1/94 0 2/16/95
Lay Build 18
START Survey Excava Buy 1/19/95 FINISH
Founda Outside
ing tion Material
tion Wall Install
0 Roofing 1/19/95 0
0 12 0 0 0
0 10 10 Install 0
3 15 20 12
9 Exterior
Doors
8/27/94
15
Request 1/12/95
6
Permits Paint
0 Exterior
15 12
5
12/3/94 12/17/94 12/31/94

Install Install Install

Start Time 8/29/94
Exterior Exterior Exterior
Legend Plumbing Electrical Siding

12 12 12
Slack Time 0 8
10 10
Duration 0
 Slack Time and Critical Path
Slack Time
◦ Available Time - Estimated (“Real”) Time for a task or activity
◦ Or: Latest Start Time - Earliest Start Time

Critical Path
◦ The path in a project plan for which the slack time at each task is zero.

The critical path has no margin for error when performing the tasks (activities) along its route.
How do you become a good project
planner?
Establish a project plan
◦ Start with the plan based on your experience with the last project(s)

Keep track of activities and their duration

Determine difference between planned and actual performance
Make sure to do a post-mortem
◦ Lessons learned
◦ Ask developers for feedback
◦ Write a document about what could have been improved
Writing the SPMP
Example full SPMPs
OWL project
◦ http://cascade1.se.cs.cmu.edu/15-413/courseDocs/spmpF96.html

JAMES project
◦ http://cascade1.se.cs.cmu.edu/JAMES/J_courseDocs/SPMP/SPMP1.0.html
Project Management Heuristics
Make sure to be able to revise or dump a project plan
◦ Complex system development is a nonlinear activity

If project goals are unclear and complex use team-based project management. In this case
◦ Avoid GANTT charts and PERT charts for projects with changing requirements
◦ Don’t look too far into the future

Avoid micro management of details

Don’t be surprise if current project management tools don’t work:
◦ They were designed for projects with clear goals and fixed organizational structures
Project Management Summary
Get agreement among customers, managers and teams
◦ Problem statement
◦ Software project management plan
◦ Project agreement
◦ Make sure agreement allows for iteration

Organization Structures
SPMP
Project planning
◦ Start with work breakdown structure (WBS)
◦ Identify dependencies and structure: Tasks, activities, functions

Tools and Techniques

◦ GANTT, Dependency graph, Schedule, Critical Path Analysis
◦ Be careful with tools in projects with a lot of change
SOFTWARE COST ESTIMATION
Software cost estimation
Predicting the resources required for a software
development process
Objectives
To introduce the fundamentals of software costing and pricing
To describe three metrics for software productivity assessment
To explain why different techniques should be used for software estimation
To describe the COCOMO 2 algorithmic cost estimation model
Topics covered
Productivity
Estimation techniques
Algorithmic cost modelling
Project duration and staffing
Fundamental estimation questions

How much effort is required to complete an activity?

How much calendar time is needed to complete an activity?
What is the total cost of an activity?
Project estimation and scheduling and interleaved management activities
 Software cost components
Hardware and software costs
Travel and training costs
Effort costs (the dominant factor in most
projects)
salaries of engineers involved in the project
Social and insurance costs
Effort costs must take overheads into account
costs of building, heating, lighting
costs of networking and communications
costs of shared facilities (e.g library, staff restaurant, etc.)
Costing and pricing
Estimates are made to discover the cost, to the developer, of producing a software system
There is not a simple relationship between the development cost and the price charged to the
customer
Broader organisational, economic, political and business considerations influence the price
charged
Software pricing factors
Programmer productivity
A measure of the rate at which individual
engineers involved in software development
produce software and associated
documentation
Not quality-oriented although quality assurance
is a factor in productivity assessment
Essentially, we want to measure useful
functionality produced per time unit
Productivity measures
Size related measures based on some output from the software process. This may be lines of
delivered source code, object code instructions, etc.
Function-related measures based on an estimate of the functionality of the delivered software.
Function-points are the best known of this type of measure
Measurement problems
Estimating the size of the measure
Estimating the total number of programmer
months which have elapsed
Estimating contractor productivity (e.g.
documentation team) and incorporating this
estimate in overall estimate
Lines of code
What's a line of code?
◦ The measure was first proposed when programs were typed on cards with one line per card
◦ How does this correspond to statements as in Java which can span several lines or where there can be
several statements on one line

What programs should be counted as part of the system?

Assumes linear relationship between system
size and volume of documentation
Productivity comparisons
The lower level the language, the more
productive the programmer
◦ The same functionality takes more code to implement in a lower-level language than in a high-level
language

The more verbose the programmer, the higher

the productivity
◦ Measures of productivity based on lines of code suggest that programmers who write verbose code
are more productive than programmers who write compact code
High and low level languages
System development times
Function points
Based on a combination of program characteristics
◦ external inputs and outputs
◦ user interactions
◦ external interfaces
◦ files used by the system

A weight is associated with each of these

The function point count is computed by multiplying each raw count by the weight and
summing all values
Function points
Function point count modified by complexity of the project
FPs can be used to estimate LOC depending on the average number of LOC per FP for a given
language
◦ LOC = AVC * number of function points
◦ AVC is a language-dependent factor varying from 200-300 for assemble language to 2-40 for a 4GL

FPs are very subjective. They depend on the estimator.

◦ Automatic function-point counting is impossible
Object points
Object points are an alternative function-related measure to function points when 4Gls or
similar languages are used for development
Object points are NOT the same as object classes
The number of object points in a program is a weighted estimate of
◦ The number of separate screens that are displayed
◦ The number of reports that are produced by the system
◦ The number of 3GL modules that must be developed to supplement the 4GL code
Object point estimation
Object points are easier to estimate from a specification than function points as they are simply
concerned with screens, reports and 3GL modules
They can therefore be estimated at an early point in the development process. At this stage, it is
very difficult to estimate the number of lines of code in a system
Productivity estimates
Real-time embedded systems, 40-160
LOC/P-month
Systems programs , 150-400 LOC/P-month
Commercial applications, 200-800
LOC/P-month
In object points, productivity has been measured between 4 and 50 object points/month
depending on tool support and developer capability
Factors affecting productivity
Quality and productivity
All metrics based on volume/unit time are
flawed because they do not take quality into
account
Productivity may generally be increased at the
cost of quality
It is not clear how productivity/quality metrics
are related
If change is constant then an approach based on counting lines of code is not meaningful
Estimation techniques
There is no simple way to make an accurate estimate of the effort required to develop a software
system
◦ Initial estimates are based on inadequate information in a user requirements definition
◦ The software may run on unfamiliar computers or use new technology
◦ The people in the project may be unknown

Project cost estimates may be self-fulfilling

◦ The estimate defines the budget and the product is adjusted to meet the budget
Estimation techniques
Algorithmic cost modelling
Expert judgement
Estimation by analogy
Parkinson's Law
Pricing to win
Algorithmic code modelling
A formulaic approach based on historical cost information and which is generally based on the
size of the software
Discussed later in this chapter
Expert judgement
One or more experts in both software
development and the application domain use
their experience to predict software costs.
Process iterates until some consensus is
reached.
Advantages: Relatively cheap estimation
method. Can be accurate if experts have direct
experience of similar systems
Disadvantages: Very inaccurate if there are no
experts!
Estimation by analogy
The cost of a project is computed by comparing
the project to a similar project in the same
application domain
Advantages: Accurate if project data available
Disadvantages: Impossible if no comparable
project has been tackled. Needs systematically
maintained cost database
Parkinson's Law
The project costs whatever resources are
available
Advantages: No overspend
Disadvantages: System is usually unfinished
Pricing to win
The project costs whatever the customer has to
spend on it
Advantages: You get the contract
Disadvantages: The probability that the
customer gets the system he or she wants is
small. Costs do not accurately reflect the work
required
Top-down and bottom-up estimation
Any of these approaches may be used top-down or bottom-up
Top-down
◦ Start at the system level and assess the overall system functionality and how this is delivered through
sub-systems

Bottom-up
◦ Start at the component level and estimate the effort required for each component. Add these efforts to
reach a final estimate
Top-down estimation
Usable without knowledge of the system architecture and the components that might be part of
the system
Takes into account costs such as integration, configuration management and documentation
Can underestimate the cost of solving difficult low-level technical problems
Bottom-up estimation
Usable when the architecture of the system is known and components identified
Accurate method if the system has been designed in detail
May underestimate costs of system level activities such as integration and documentation
Estimation methods
Each method has strengths and weaknesses
Estimation should be based on several methods
If these do not return approximately the same result, there is insufficient information available
Some action should be taken to find out more in order to make more accurate estimates
Pricing to win is sometimes the only applicable method
Experience-based estimates
Estimating is primarily experience-based
However, new methods and technologies may make estimating based on experience inaccurate
◦ Object oriented rather than function-oriented development
◦ Client-server systems rather than mainframe systems
◦ Off the shelf components
◦ Component-based software engineering
◦ CASE tools and program generators
Pricing to win
This approach may seem unethical and unbusinesslike
However, when detailed information is lacking it may be the only appropriate strategy
The project cost is agreed on the basis of an outline proposal and the development is
constrained by that cost
A detailed specification may be negotiated or an evolutionary approach used for system
development
Algorithmic cost modelling
Cost is estimated as a mathematical function of
product, project and process attributes whose
values are estimated by project managers
◦ Effort = A ´ SizeB ´ M
◦ A is an organisation-dependent constant, B reflects the disproportionate effort for large projects and M
is a multiplier reflecting product, process and people attributes

Most commonly used product attribute for cost

estimation is code size
Most models are basically similar but with
different values for A, B and M
Estimation accuracy
The size of a software system can only be known accurately when it is finished
Several factors influence the final size
◦ Use of COTS and components
◦ Programming language
◦ Distribution of system

As the development process progresses then the size estimate becomes more accurate
Estimate uncertainty
The COCOMO model
An empirical model based on project experience
Well-documented, ‘independent’ model which is not tied to a specific software vendor
Long history from initial version published in 1981 (COCOMO-81) through various
instantiations to COCOMO 2
COCOMO 2 takes into account different approaches to software development, reuse, etc.
COCOMO 81
COCOMO 2 levels
COCOMO 2 is a 3 level model that allows increasingly detailed estimates to be prepared as
development progresses
Early prototyping level
◦ Estimates based on object points and a simple formula is used for effort estimation

Early design level

◦ Estimates based on function points that are then translated to LOC

Post-architecture level
◦ Estimates based on lines of source code
Early prototyping level
Supports prototyping projects and projects where there is extensive reuse
Based on standard estimates of developer productivity in object points/month
Takes CASE tool use into account
Formula is
◦ PM = ( NOP ´ (1 - %reuse/100 ) ) / PROD
◦ PM is the effort in person-months, NOP is the number of object points and PROD is the
productivity
Object point productivity
Early design level
Estimates can be made after the requirements have been agreed
Based on standard formula for algorithmic models
◦ PM = A ´ SizeB ´ M + PMm where
◦ M = PERS ´ RCPX ´ RUSE ´ PDIF ´ PREX ´ FCIL ´ SCED
◦ PMm = (ASLOC ´ (AT/100)) / ATPROD
◦ A = 2.5 in initial calibration, Size in KLOC, B varies from 1.1 to 1.24 depending on novelty of the
project, development flexibility, risk management approaches and the process maturity
Multipliers
Multipliers reflect the capability of the developers, the non-
functional requirements, the familiarity with the development
platform, etc.
◦ RCPX - product reliability and complexity
◦ RUSE - the reuse required
◦ PDIF - platform difficulty
◦ PREX - personnel experience
◦ PERS - personnel capability
◦ SCED - required schedule
◦ FCIL - the team support facilities

PM reflects the amount of automatically generated code

Post-architecture level
Uses same formula as early design estimates
Estimate of size is adjusted to take into account
◦ Requirements volatility. Rework required to support change
◦ Extent of possible reuse. Reuse is non-linear and has associated costs so
this is not a simple reduction in LOC
◦ ESLOC = ASLOC ´ (AA + SU +0.4DM + 0.3CM
+0.3IM)/100
◦ ESLOC is equivalent number of lines of new code. ASLOC is the number of lines of reusable
code which must be modified, DM is the percentage of design modified, CM is the percentage
of the code that is modified , IM is the percentage of the original integration effort required for
integrating the reused software.
◦ SU is a factor based on the cost of software understanding, AA is a factor which reflects the
initial assessment costs of deciding if software may be reused.
The exponent term
This depends on 5 scale factors (see next slide). Their sum/100 is added to 1.01
Example
◦ Precedenteness - new project - 4
◦ Development flexibility - no client involvement - Very high - 1
◦ Architecture/risk resolution - No risk analysis - V. Low - 5
◦ Team cohesion - new team - nominal - 3
◦ Process maturity - some control - nominal - 3

Scale factor is therefore 1.17

Exponent scale factors
Multipliers
Product attributes
concerned with required characteristics of the software product being developed
Computer attributes
constraints imposed on the software by the hardware platform

Personnel attributes
multipliers that take the experience and capabilities of the people working on the project into
account.

Project attributes
concerned with the particular characteristics of the software development project
Project cost drivers
Effects of cost drivers
 Project planning
Algorithmic cost models provide a basis for
project planning as they allow alternative
strategies to be compared
Embedded spacecraft system
Must be reliable
Must minimise weight (number of chips)
Multipliers on reliability and computer constraints > 1
Cost components
Target hardware
Development platform
Effort required
Management options
Option choice
Option D (use more experienced staff) appears to be the best alternative
◦ However, it has a high associated risk as expreienced staff may be difficult to find

Option C (upgrade memory) has a lower cost saving but very low risk
Overall, the model reveals the importance of staff experience in software development
Project duration and staffing
As well as effort estimation, managers must estimate the calendar time required to complete a
project and when staff will be required
Calendar time can be estimated using a COCOMO 2 formula
◦ TDEV = 3 ´ (PM)(0.33+0.2*(B-1.01))
◦ PM is the effort computation and B is the exponent computed as discussed above (B is 1 for the early
prototyping model). This computation predicts the nominal schedule for the project

The time required is independent of the number of people working on the project
Staffing requirements
Staff required can’t be computed by diving the development time by the required schedule
The number of people working on a project varies depending on the phase of the project
The more people who work on the project, the more total effort is usually required
A very rapid build-up of people often correlates with schedule slippage
Main points to remember
Factors affecting productivity include individual aptitude, domain experience, the development
project, the project size, tool support and the working environment
Different techniques of cost estimation should be used when estimating costs
Software may be priced to gain a contract and the functionality adjusted to the price
Main points to remember
Algorithmic cost estimation is difficult because of the need to estimate attributes of the
finished product
The COCOMO model takes project, product, personnel and hardware attributes into
account when predicting effort required
Algorithmic cost models support quantitative option analysis
The time to complete a project is not proportional to the number of people working on the
project
software pricing
software pricing factors?
1. Human resources
2. Project complexity & size
3. Software functionality
4. Scope of work
5. UX/UI
6. Integrations
7. Migration
8. Extra expenses
◦ Licenses
◦ Infrastructure
◦ maintenance fees
What are pricing models in IT
industry?
It can be overwhelming to build software from scratch. Not only does it involve
writing code, but it also involves various phases such as architecture, design,
testing, and deployment.
With pricing models, companies can easily understand what they are paying for
and what benefits they will get from their projects. There are several types of
pricing models that can help companies develop software: Fixed price, Time and
Material, Outstaffing, Dedicated team, Hybrid, and Gain-sharing model.
Fixed Price Model / Waterfall
As the name itself implies, a fixed price model is an agreement between a business and an IT outsourcing
company on a strictly predefined set of requirements to be accomplished for a predefined price.

A fixed price model is an ideal mechanism for projects with a clear scope, established project management
methodologies, and a stable set of requirements. For a successful collaboration, a team and a service
provider should have a good grasp of project requirements and a conducive working environment in place
and should be aware of each other’s skills and needs.
Time and Material (T&M) pricing model
User behaviors and needs change faster than a typical software development project lasts. Often, you as a
client can only predict possible intentions and perceptions of users. Thus, during the development process,
new product requirements and new flows will appear, and they will affect the total software price as well.
The time and material price model provides agility. Flexibility in software development enables you to
create a product that the market indeed needs and will use.
Also, this model is the most transparent one. In the fixed price models, where the probability of risk is high,
IT outsourcing companies charge an extra 20%-50% on top of their real estimation to be able to absorb the
risk and ensure profit. In the Time and Material model, you as a client always pay the real price
without any premiums. Thus, you always know where your money goes.
With this pricing model, the service provider and the client organization normally agree
upon an hourly rate. The billing is based on the developers’ levels of education and
experience.
How to estimate the final price using the time & material pricing model?
During the first meeting, we meticulously examine the clients’ vision and the users’ needs. A
special SWOT analysis team consisting of senior-level developers with expertise in the
required field then creates a detailed roadmap and estimates the scope of the project.
The roadmap created by the SWOT analysis team consists of:
Typical tasks (team onboarding, DevOps, test);
Specific tasks;
Team composition.
Total estimation for typical tasks can easily be calculated, and the SWOT analysis team creates
approximate estimates for specific tasks and multiplies them by the developers’ hourly rate.
This approach enables us to determine the right pricing and answer all potential questions regarding how
the final estimate was calculated. Additionally, the clients themselves have the power to shape the final
price by altering the scope of work or suggesting changes in the team composition.
Hybrid pricing model
The hybrid model is a cost-effective alternative to the traditional T&M model for projects
that do not have specific requirements or clear-cut goals. It allows customers to set a fixed
price based on the estimate. This model has the best features of the two models - Fixed-
priced and Time & Material, such as the ability to deploy resources and the well-aligned
processes.
The hybrid model is ideal for projects with unclear objectives and requirements at the start.
It allows for feedback and input during the early stages, but it can be refined over time to
deliver the best possible results. This model is also ideal for customers who prefer to pay
one-time or hourly.
It allows customers to keep their budgets flexible and avoid compromising on the quality of
their product or application. It also provides a controlled environment for the service
provider.
Outstaffing pricing model
Outstaffing means handing tasks over to individual specialists working for a service
provider company. Organizations engage in outstaffing when they lack the expertise or
capacity to complete the tasks in-house.
Usually, hiring experienced developers might take a lot of time, and sometimes, you don’t
have enough authority to attract the best personnel. This model provides human resources
for whole projects or just parts of projects as needed.
The model is ideal for clients who are looking to hire specialists on a short-term basis. The
clients don’t have to pay for recruiting, and terminating the contract is easy.
The outstaffing pricing model can use predefined rates like the time and material model or
fixed price in the form of a regular salary without covering additional benefits, taxes,
vacations, and coffee breaks.
And since the project is managed by the client organization, closer monitoring of
performance provides more accurate cost control. To confirm the seniority level of the
professionals being hired, most IT outsourcing companies let clients interview and test
outstaffed team members.
Dedicated team model
This type of model is ideal for companies that need to quickly expand their software
development team. The most significant advantage of a dedicated team pricing model is its
ability to control the number of people that the team members are allowed to work with.
You can also monitor and interview the members of the team.
Unlike an in-house team, a dedicated team model eliminates the need for hiring and
training new employees. Instead, you can enjoy the services that the team provides. With a
dedicated team, you can also pay the monthly salaries of the employees that you have
hired.
Gain-sharing pricing model
Future unicorn startups having great ideas but unable to attract the best employees and
financial resources to boost their growth can pitch their product to IT outsourcing
providers.
The providers in some cases might operate as investors and become co-founders of a
startup. In contrast to traditional monetary investments, the startups ask for labor expertise.
It is called the gain-sharing pricing model.
However, this pricing model is usually not the most attractive to IT service providers. These
pitches often come from startups that lack a solid foundation and are looking for freebies.
 Gain-sharing pricing model recommendations:
1. Develop a clear monetization strategy and make sure you know how your project is
going to generate profit in the future.
2. Conduct market-fit analysis.
3. Have a clear vision of how your product is going to meet users’ needs.
Software development contract:
What should be included in a software development contract?
1. Service should be provided
This section should also include the project scope and any details that you need to protect
both you and the partner from disputes.
The Services section should also include a discussion about the procedures involved in
making changes to the scope of the contract. This should be done in writing so that both
parties can make informed decisions.
2. Project time and cost
The contract's terms should also be summarized in terms that are easy to understand. This
section also includes the project's timeline and the estimated cost of the project.
In addition, the contract should also include a statement that explains the responsibility of
both parties for delays caused by the project. If the parties have already agreed on partial
payments, this should also be included in the contract.
3. Testing
The acceptance testing section should also include a statement that clearly states the type of
testing that will be performed on both the vendor and the client.
 4. Intellectual property rights
It is one of the important sections. The software that's developed as the result of a project should
also be clearly stated in the contract. This section should also include the terms and conditions
that govern the use of the software.
Particularly it should include:
A. source code
B. Any material that was developed during software development: wireframes, designs, plans,
etc.
C. The development company can only reassign the rights to the software that it created. If the
software was developed using open-source tools, they will remain public.
5. Confidentiality
The confidentiality section should also be included in the contract to protect the information that the
development company has stored about the project.
Most software development contracts contain confidentiality provisions that are usually maintained after
the contract has been completed.
software maintenance
Why software maintenance:
• Successful software live much longer than development cycle period.
• Hence,
• New requirements emerge when the software is used.
• The business environment changes.
• Faults must be repaired.
• New computers or equipment are added to the
system.
• Scaling-up makes the performance or reliability
insufficient.

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 2
Maintenance Process (Simple):

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 3
The Issue of Software Evolution Cost:
• Software engineering maintenance and evolution activities account for much, if
not most, of software costs!

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 4
Evolution vs Maintenance:
• Both terms are used interchangeably, however, there is a
semantic difference.
• Lowell Jay Arthur distinguish the two terms as follows:
“Software maintenance means to preserve from failure or
decline.”
“Software evolution means a continuous change from lesser,
simpler, or worse state to a higher or better state.”

• Keith H. Bennett and Lie Xu use the term:

“Maintenance for all post-delivery support and evolution to those
driven by changes in requirements.”

• Maintenance is considered to be set of planned activities

whereas evolution concern whatever happens to a system
over time.
Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 5
Maintenance Models(Processes):
• Software maintenance have its own Software Maintenance Life Cycle (SMLC)
model.
• Popular SMLC models:
I. Staged model.
II. Iterative models.
III. Change Mini-cycle models.

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 6
Maintenance Standards:
• IEEE and ISO have both addressed SW maintenance
processes:
• IEEE/EIA 1219 specifies staged process.
• ISO/IEC 14764 specifies iterative process.
• ISO/IEC12207.
• Standards specify maintenance process as asset of
activities:
• process implementation, problem and modification analysis,
modification implementation, maintenance review/acceptance,
migration and retirement.
• Each activity contains tasks.
• Each task describes a specific action with inputs and outputs.

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 7
Maintenance Terms:
• These definitions are taken from IEEE standards:
• Maintainability: the ease with which a software system or component can be modified.
It cannot be measured directly, but is affected by factors.
• Ripple Effect: changes in one software location can impact other components. Ripple
effects enforce the dynamic analysis, that is, we have to run the program.
• Impact Analysis: the process of identifying potential consequences of a change in
terms of how the change will effect the rest of the system.
• Traceability: the degree to which a relationship can be established between two or
more products of the development process, such as the requirements and code, or
design documentation and tests.

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 8
Software Configuration Management (SCM):
• SCM is the discipline of managing and controlling change in the evolution of
software system.

• It ensures that the released software is not contaminated by uncontrolled or

unapproved changes.
• The goal of SCM is to manage and control the numerous corrections,
extensions, and adaptations that are applied to a system over its lifetime.

• An SCM system has four different elements, each element addressing a distinct
user need as follows:
I. Identification of software configurations: artifacts, milestones, and changes.
II. Control of software configurations: ways of alterations.
III. Auditing software configurations: making software status visible to management.
IV. Accounting software configuration status: history of software alterations.

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 9
Commercial Off-the-Shelf (COTS) software:
• COTS are usually component-based systems (CBS).
• For examples: Operating Systems, Database Systems, Networking, Displays.
• The major differences between CBS and custom-built software systems:
1. Infrastructure and organization.
2. User community.
3. Modernization.
4. Skills of maintenance teams.
5. Maintenance cost.
6. Maintenance function.
7. Planning complexity.
• But, from another prospective COTS:
1. May come with upgrade costs or licensing fees.
2. Will not meet all business needs or include unwanted features.
3. May need to change business processes to match the software.
4. May include security or technical undesired properties.
5. High customization costs, or impossible to customize.
Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 10
Reengineering:
• Reengineering is to transform an existing “lesser” into a new “better”
system.
• Reengineering activity includes: examination, analysis and
restructuring of an existing software to reconstitute the new one.
• Chikofsky and Cross II defines reengineering as:
“the examination and alteration of a subject system to reconstitute
the new form and the subsequent implementation of it.”
• Jacobson and Lindstorm formula:

Reengineering = Reverse engineering + Δ + Forward engineering.

• Reverse engineering is the activity for a more abstract representation of the
system. It is the process of examination, not a process of change.
• Forward engineering is the traditional process of moving from designs to
implementation.
• Δ is captures alteration that is change of the system.
Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 11
Legacy Systems:
• A legacy system is an old system which is valuable for
the business that owns it.
• Bennett used the following definition:
“large software systems that we don’t know how to cope
with but that are vital to our organization.”
• Similarly, Brodie and Stonebraker: define a legacy
system as
“any information system that significantly resists modification
and evolution to meet new and constantly changing
business requirements.”

• Options to manage legacy systems:

1. Freeze it.
2. Outsource it.
3. Maintenance it.
4. Discard and redevelop it.
5. Wrap it.
6. Migrate it.
Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 12
 Impact Analysis:
• Impact analysis is to estimate the parts of the software that
can be affected by any change.
• Impact analysis techniques can be partitioned into two
classes:
• Traceability analysis: high-level artifacts (e.g., requirements,
design, code & test cases) are identified, linked to be maintained.
• Dependency analysis: to assess the affects of change on semantic
dependencies between program entities. Main techniques ara:
• call-graph-based and
• dependency-graph-based analysis.
• Common notions related to impact analysis among
practitioners:
• Ripple effect: how likely is a change may cause problems in the
rest of a program.
• Change propagation: activity ensures that a change made in one
component is propagated properly throughout the entire system.
Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 13
Refactoring:
• Refactoring is the process of making a change to the
internal structure of software to make it easier to
understand and cheaper to modify without changing its
observable behavior.
• It is the object-oriented equivalent of restructuring.
• Refactoring includes:
• Duplicate code removal,
• Code simplification,
• There are two aspects of the above definition:
• Preserve the “observable behavior” of the software system
(through regression).
• Improve the internal structure of a software system (improve
maintainability).
Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 14
 Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 15
Program Comprehension:
• Program understanding or comprehension is
“the task of building mental models of an underlying software system at various
abstraction levels, ranging from models of the code itself to ones of the underlying
application domain, for software maintenance, evolution and re-engineering
purposes.”
• Program comprehension deals with the cognitive processes involved
in constructing a mental model of the program.
• Common element is:
• Hypotheses are a way to understand code in an incremental manner.
• After that, programmer forms a hypothesis and verifies it.
• By continuously formulating new hypotheses and verifying them, the programmer
understands more and more code and in increasing details.
• Several strategies can be used to arrive at relevant hypotheses such
as: bottom-up, top-Down, opportunistic.
• Strategies namely chunking and cross-referencing are used to
produce higher-level abstraction structures.
Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 16
Software Reuse:
• Software reuse was introduced by Dough McIlroy in 1968. Also,
program families by David Parnas, and domain analysis by Jim
Neighbors.
• Program families are sets of programs whose common properties
are considered before analyzing individual differences.
• Domain analysis is to identifying objects and operations of systems
in a particular domain.
• Reusable assets can be either reusable artifacts or software
knowledge.
• Capers Jones identified four types of reusable artifacts:
• data reuse,
• architectural reuse,
• design reuse,
• program reuse.

• Cost savings in maintenance stages is twice the savings during

development.
• Reusability is a property of a software assets that indicates the Copyrights © 2021 All rights reserved,
degree to which it can be reused. Al Azhar University-Gaza, Palestine. 17
• Reusable components must exhibit the following:
I. Environmental independence: components can be reused irrespective of the
environment from which they were originally captured.
II. High cohesion: components that implement a single operation or set of related
operations.
III. Loose coupling: components that have minimal links to other components.
IV. Adaptability: components that are adaptable so they can be customized to fit a range of
similar situation.
V. Understandability: components which are easily understandable that users can quickly
interpret functionality.
VI. Reliability: components that are error-free.
VII. Portability: components that are not restricted in terms of the software or hardware
environment they operate in.
• Benefits of Reuse:
1. Increased reliability.
2. Reduced process risk.
3. Increase productivity.
4. Standards compliance.
5. Accelerated development.
6. Improve maintainability.
7. Reduction in maintenance time and effort.
Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 18
 Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 19
Intention-based Classification of Software Maintenance:
• Maintenance activities are divided into four groups:
• Corrective maintenance: The purpose of corrective
maintenance is to correct failures: processing failures and
performance failures.

• Adaptive maintenance: The purpose of adaptive maintenance

is to enable the system to adapt to changes in its data
environment or processing environment.

• Perfective maintenance: The purpose of perfective

maintenance is to make a variety of improvements, namely,
user experience, processing efficiency, and maintainability.

• Preventive maintenance: The purpose of preventive

maintenance is to prevent problems from occurring by
modifying software products.

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 20
• Corrective maintenance:
• The purpose of corrective maintenance is to correct failures: processing failures and
performance failures.

• Examples of corrective maintenance:

• A program producing a wrong output is an example of processing failure.
• Similarly, a program not being able to meet real-time requirements is an example of performance failure.

• The process of corrective maintenance includes

• isolation and
• correction of defective elements in the software.

• There is a variety of situations that can be described as corrective maintenance such as

correcting a program that aborts or produces incorrect results.

• Basically, corrective maintenance is a reactive process, which means that corrective

maintenance is performed after detecting defects with the system.
Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 21
• Adaptive maintenance:
• The purpose of adaptive maintenance is to enable the system to adapt to changes in its
data environment or processing environment.

• This process modifies the software to properly interface with a changing or changed
environment.

• Adaptive maintenance includes system changes, additions, deletions, modifications,

extensions, and enhancements to meet the evolving needs of the environment in which the
system must operate.

• Examples of Adaptive maintenance are:

• changing the system to support new hardware configuration;
• converting the system from batch to on-line operation; and
• changing the system to be compatible with other applications.

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 22
• Perfective maintenance:
• The purpose of perfective maintenance is to make a variety of improvements, namely, user
experience, processing efficiency, and maintainability.

• Examples of perfective maintenance are:

• the program outputs can be made more readable for better user experience;
• the program can be modified to make it faster, thereby increasing the processing efficiency;
• and the program can be restructured to improve its readability, thereby increasing its maintainability.

• Activities for perfective maintenance include restructuring of the code, creating and
updating documentations, and tuning the system to improve performance.

• It is also called “reengineering”.

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 23
• Preventive maintenance:
• The purpose of preventive maintenance is to prevent problems from occurring by
modifying software products.

• Basically, one should look ahead, identify future risks and unknown problems, and take
actions so that those problems do not occur.
• Preventive maintenance is very often performed on safety critical and high available
software systems.

• The concept of “software rejuvenation” is a preventive maintenance measure to prevent,

or at least postpone, the occurrences of failures (crash) due to continuously running the
software system.

• It involves occasionally terminating an application or a system, cleaning its internal state,

and restarting it.

• Rejuvenation may increase the downtime of the application; however, it prevents the
occurrence of more severe failures. Copyrights © 2021 All rights reserved,
Al Azhar University-Gaza, Palestine. 24
Activity-based Classification of Software Maintenance:
• Kitchenham et al. organize maintenance modification
activities into two categories:
• Corrections:
Activities in this category are designed to fix defects in the system,
where a defect is a discrepancy between the expected behavior and
the actual behavior of the system.

• Enhancements:
Activities in this category are designed to effect changes to the system.
It is further divided into three subcategories as follows:
– enhancement activities that modify some of the existing
requirements implemented by the system;
– enhancement activities that add new system requirements; and
– enhancement activities that modify the implementation without
changing the requirements implemented by the system.

Copyrights © 2021 All rights reserved,

Al Azhar University-Gaza, Palestine. 25