CH 1

Download as pdf or txt
Download as pdf or txt
You are on page 1of 35

SE 482

Software Project Management

Chapter 1: Introduction

Adapted From The Lecture Slides for Managing and Leading Software Projects

developed by Richard E. (Dick) Fairley, Ph.D. to accompany the text:

Managing and Leading Software Projects published by Wiley, 2009

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-1
Topics
 Why Managing and Leading Software Projects Is Difficult
 The Nature of Project Constraints
 A Workflow Model for Managing Software Projects
 Organizational Structures for Software Projects
 Organizing the Project Team
 Maintaining the Project Vision and the Product Vision
 Frameworks, Standards, and Guidelines

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-2
What is a Project?
A project is characterized as follows:
• a one-time effort is planned
• starting and ending dates are prescribed
• a project team is assembled
• schedule and budget are allocated
• well-defined objectives are established
• roles are identified, responsibilities are assigned,
and authority is delegated

Software projects are temporary organizational units


Managing and Leading Software Projects,
by R. Fairley, © Wiley, 2009

chapter 1
slide 1-6
What is Management?
Management is concerned with planning and coordinating
the work activities of others so that they can achieve goals
that cannot be achieved by each individual acting alone

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-7
What is Software Project Management?

Software Project Management (SPM) is the art and science of planning


and coordinating the work of software developers and other personnel
to develop and modify software artifacts that:
 are pleasing to users and customers
 are developed and modified in an economical and timely manner
 and that can be maintained efficiently and effectively

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-8
The Four Major Activities of SPM
1. Planning and Estimating
 identify work activities
 prepare a schedule
 prepare a budget
2. Measuring and Controlling
 requirements
 quality and productivity
 schedule and budget
 product evolution
3. Leading and Communicating
 motivating / coaching / educating project members
 communicating with management, customers,
 subcontractors, other projects
4. Managing Risk
 identifying and confronting potential problems
Managing and Leading Software Projects, chapter 1
by R. Fairley, © Wiley, 2009 slide 1-9
Managing versus Leading
Managing is concerned with the quantitative aspects of SPM:
 planning and estimating
 measuring and controlling
 quantitative risk management
Leading is concerned with the qualitative aspects of SPM:
 communicating and coordinating
 inspiring and maintaining morale Should a project
 qualitative risk management manager be a
manager or a
leader?

An effective project manager is both


a manager and a leader!
Managing and Leading Software Projects, chapter 1
by R. Fairley, © Wiley, 2009 slide 1-10
Project Success Criteria
The primary goal of S/W engineering is to develop and modify S/W,
where:

 the product satisfies technical requirements, user needs & expectations

 the product is delivered on time & within budget

 development milestones are achieved on time & within budget

 the product is easy to modify and maintain

 staff morale is high throughout project



work instills pride in the developers

Managing and Leading Software Projects,


chapter 1
by R. Fairley, © Wiley, 2009 slide 1-11
Project Manager’s Success Criteria
 delivery of an acceptable product on time and within budget
within the limits imposed by project constraints
 maintaining good relations with customers, suppliers,
 managers, and other organizational units
 maintaining a motivated project team
 advancing the career of each project member
 advancing his or her career
 Other criteria?

Managing and Leading Software Projects,


by R. Fairley, © Wiley, 2009
chapter 1
slide 1-12
Why Are Software Projects Difficult?
 According to Fred Brooks*, software projects are difficult because of
accidental and essential difficulties.

 Accidental difficulties are caused by the current state of our


understanding of methods, tools, and techniques of the underlying
technology base.

 Essential difficulties are caused by the inherent nature of software.


There are four essential properties of software differentiate it from
other kinds of engineering artifacts and make software projects difficult:
Complexity, Conformity, Changeability, and Invisibility of software.
* The Mythical Man-Month by Fred Brooks, Addison Wesley, 1995

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-13
Essential Difficulties
 Complexity
The complexity of software arises from the large number of unique,
interacting parts in a software system.
 Conformity
Software must conform to exacting specifications in the representation
of each part, in the interfaces to other internal parts, and in the
connections to the environment in which it operates.
 Changeability
Changes may occur because customers change their minds; competing
products change; mission objectives change; laws, regulations, and
business practices change,........etc.

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-14
Essential Difficulties – Cont.
 Invisibility
 Software has no physical properties.
 software products under development are often reported to be
“ almost complete ” for long periods of time with no evidence.
 Many software projects have been cancelled after large
investments of effort, time, and money, because no one could
objectively determine the status of the work products or provide
a credible estimate of a completion date or the cost to complete
the project.

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-15
Additional Difficulties
Additional reasons software projects are difficult are:
 Intellect-intensive, team-oriented nature of the work
Software is developed by teams of individuals engaged in creative
problem solving activities. The team may pursue a “plan-driven”
approach or an “agile” approach.
Most successful S/W projects incorporate
aspects of both planning and agility
 Externally imposed constraints
 Platforms, software tools, hardware,…etc.
 Process standards
 Business considerations
 Ethical considerations
 …
 Others?
Managing and Leading Software Projects, chapter 1
by R. Fairley, © Wiley, 2009 slide 1-15
More About Constraints…
Useful constraints provide guidance. For example, well-defined
requirements are the basis for planning, estimating,
and establishing success criteria.
Inhibiting constraints inhibit the ability to achieve success criteria. For
example, excessive schedule pressure may inhibit the
ability to deliver a product of high quality.

Some of the most difficult problems or challenges you will encounter in


managing software projects arise from establishing and maintaining a
balance among the constraints on:
 Scope (the work to be done ),
 Budget ( the money to acquire resources),
 Resources ( the assets available to do the job),
 Technology ( methods and tools to be used), and
 Scheduled delivery date ( the date on which the system must be ready
for delivery).
Managing and Leading Software Projects, chapter 1
by R. Fairley, © Wiley, 2009 slide 1-26
A Workflow Model/ Process Model for
Software Projects
Change Requests Problem Reports

Start Requirements Software


Here and Constraints Development

customer Planning
Activity Work Independent
and Assign-
Replanning Definition Validation
management ments
Quality Deliver
Directives and
Constraints Assurance Product
Estimating
Controlling Configuration
Management

Data
Retention Other Supporting
Processes

Project Reports Status Reports


Reporting Measuring

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-28
Some Supporting Processes for S/W Projects
Supporting Process Purpose
Configuration Change control; base line management; product audits;
Management Product builds
Verification Determining the degree to which work products satisfy
the conditions placed on them by other work products
and work processes
Validation Determining the degree of fitness of work products for
their intended use in their intended environments
QualityAssurance Assuring conformance of work processes and work
products to policies, plans, and procedures
Documentation Preparation and updating of intermediate and deliverable
work products
Developer Training Maintaining adequate and appropriate skills
User and Operator Imparting skills needed to effectively use and operate
Training systems
Managing and Leading Software Projects, chapter 1
by R. Fairley, © Wiley, 2009 slide 1-30
Eight Supporting Processes in ISO & IEEE
Standards 12207
 Documentation
 Configuration management
 Quality assurance
 Verification
 Validation
 Joint review
 Audit
 Problem resolution

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-31
Topics
 Why Managing and Leading Software Projects Is Difficult
 The Nature of Project Constraints
 A Workflow Model for Managing Software Projects
 Organizational Structures for Software Projects
 Organizing the Project Team
 Maintaining the Project Vision and the Product Vision
 Frameworks, Standards, and Guidelines

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-34
Organizational Structures for S/W Projects
Organizations that conduct engineering projects, including software
projects, are typically organized in one of four ways:
1. functional structure,
2. project structure,
3. matrix structure, or
4. hybrid structure.

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-35
1. Functional Structures
Department
Manager

Process-Oriented:

Requirements Design Implementation ...


Group Group Group Group

Department
Manager

Product-Oriented:

User Interface Algorithms Data base ...


Group Group Group Group

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-36
2. Project-Structured Organizations

The project manager, have full


Department authority and responsibility for
managing budget and resources
Manager

Project #1 Project #2 Project #3 Project #n

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-38
3. Matrix-Structured Organizations
The goal of a matrix
organization is to obtain
the advantages of both
functional and
project structures;
functional specialists are
assigned to projects as
needed and work for you,
the project manager, while
applying their expertise to
your project. When their
tasks are completed, they
return to their function
groups and are assigned,
as needed, to other
projects. Workers in a
matrix organization thus
have two bosses: their
functional manager and
their project manager.
Managing and Leading Software Projects, chapter 1
by R. Fairley, © Wiley, 2009 slide 1-39
3. Matrix-Structured Organizations – Cont.

Two problems that can occur


in matrix organizations are:
(1) conflicts between
functional managers and
project managers over the
allocation of worker
resources (which puts the
workers in untenable
situations), and
(2) frequent shifting of
workers from project to
project as crises occur (know
as “ firefighting ” mode).

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-39
4. Hybrid Structured Organizations
Few, if any, organizations are purely functional, project, or matrix in nature.

100% 0%

Functional

Functional Matrix Project


Emphasis Emphasis

Project

0% 100%
Project Project
Coordinator Manager

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-40
An Organizational Model for S/W Projects
Customer

Project Manager

Software Architect

Team Team Team V&V CM XX


Leader #1 Leader#2 Leader #3
... ... V&V: Verification and Validation
CM: Configuration Management
Member Member XX: other supporting processes

Member Member

Each team has 2 to 5 members plus a team leader

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-41
Organizing The Project Team
A complex system is composed of:
 hardware (computers and others)
 software (newly developed and reused)
 people (operators, maintainers)

A software project may be one of a collection of projects


 under the technical direction of a system engineering team

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-42
The System Engineering Team
The responsibilities of systems engineers include:
 defining operational requirements,
 specifying system requirements,
 developing the system design,
 allocating system requirements to system components, integrating the
system components as they become available,
 verifying that the system to be delivered is correct, complete, and
consistent with respect to its technical specifications, and
 validating operation of the system with its intended users in its intended
operational environment.

for “software only” projects the people who perform


these functions are termed “software system engineers”

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-43
Maintaining the Project and Product Visions

 The project manager is the the keeper of the process vision (the
project roadmap), which is documented in the project plan and is
updated as the project evolves.

 The software architect is the keeper of the product vision (the goals
for the product), which is documented in the requirements and
architectural design specifications and is updated as the product
evolves

The project manager is like a movie producer and


the software architect to a movie director. !!!

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-45
The movie producer and the movie director!
 The producer (project manager) has overall responsibility for
schedules, budgets, resources, customer relations, and delivery of a
satisfactory product on time and within budget.
 The director (software architect) is responsible for the content of
the product.

 Producer and director must work together to maintain and


constantly communicate the process vision and the product vision
to the cast of developers and supporting personnel as well as other
project stakeholders

Managing and Leading Software Projects,


by R. Fairley, © Wiley, 2009
chapter 1
slide 1-46
Frameworks, Standards, and Guidelines
• A process framework is a generic process model that can be tailored
and adapted to fit the needs of particular projects and organizations.

• An engineering standard is a codification of methods, practices, and


procedures that is usually developed and endorsed by a professional
society or independent agency.

• Guidelines are pragmatic statements of practices that have been found


to be effective in many practical situations.

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-47
Frameworks, Standards, and Guidelines – Cont.
Some well known frameworks, standards, and guidelines for software
engineering and the associated URLs are:
 The Capability Maturity Model® Integration for development CMMI-
DEV-v1.2) [www.sei.cmu.edu/cmmi/models]
 ISO/IEC and IEEE/EIA Standards 12207 [www.iso.org];
[standards.ieee.org/software]
 IEEE/EIA Standard 1058 [standards.ieee.org/software]
 the Project Management Body of Knowledge (PMBOK®)
[www.pmibookstore.org]

Elements of these models that are relevant to managing and leading software
projects are presented in appendices to the chapters of this text, including
Appendix 1A to this chapter.

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-48
The Main Points of Chapter 1
 A project is a coordinated set of activities that occur within a specific
timeframe to achieve specific objectives

 The primary activities of software project management are planning and


estimating; measuring and controlling; leading, communicating, and
coordinating; and managing risk

 Software projects are inherently difficult because software is complex,


changeable, conformable, and invisible

 Software projects are conducted by teams of individuals who engage in


intellect-intensive teamwork

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-49
The Main Points of Chapter 1 – Cont.

 Project constraints are limitations imposed by external agents on


some or all of the operational domain, operational requirements,
product requirements, project scope, budget, resources, completion
date, and platform technology
 A workflow model indicates the work activities and the flow of work
products among work activities in a software project

 The entire description of a software system or product is usually too


complex for the entire description to be written directly in
programming language, so we must prepare different descriptions at
different levels of abstraction, and for different purposes.

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-50
The Main Points of Chapter 1– Cont.
 Organizations that conduct software projects use functional,
project, weak matrix, and strong matrix structures Software
projects organized in a hierarchical manner provide well-defined
work activities, roles, authorities, and responsibilities at each
level in the hierarchy; hierarchies can expand and shrink to fit the
needs of each project

 Requirements must be allocated and the design structured so that


the work of each small team can proceed concurrently with the
work of other teams.

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-51
The Main Points of Chapter 1– Cont.
 The project manager maintains the project vision, as documented in
the project plan, and the software architect maintains the product
goals, as documented in the requirements and architectural design
 A software process framework is a generic process model that can
be tailored and adapted to fit the needs of particular projects and
organizations.
 A software engineering standard is a codification of methods,
practices, and procedures, usually developed and endorsed by a
professional society or independent agency.
 Guidelines are pragmatic statements of practices that have been
found to be effective in many practical situations.

Managing and Leading Software Projects, chapter 1


by R. Fairley, © Wiley, 2009 slide 1-51

You might also like