Transcript CSEB233 Fundamentals of Software Engineering Module 9: Software Project Management Company LOGO Badariah Solemon 2010

CSEB233 Fundamentals of Software Engineering
Module 9:
Software Project Management
Company
LOGO
Badariah Solemon 2010
Objectives
 Discuss the importance of software project
management (SPM)
 Explain the four P’s of effective project
management: people, product, process,
project
 Introduce the W5HH Principle and critical
practices for performance-based management
Badariah Solemon 2010
Importance of SPM
 Building computer software is complex,
particularly if it involves many people working
over a relatively long time.
 That is why software projects need to be
managed
Badariah Solemon 2010
The Management Spectrum
 Effective software project management
focuses on the four P’s:




People — the most important element of a
successful project
Product — the software to be built
Process — the set of framework activities and
software engineering tasks to get the job done
Project — all work required to make the product a
reality
Badariah Solemon 2010
Four P’s: People
 People must be organized to perform software work
effectively.
 The “people factor” is so important that the Software
Engineering Institute has developed People Capability
Maturity Model (People-CMM).
 People-CMM maturity model defines key practice areas like
staffing, communication and coordination, work
environment, training, career development, team/ culture
development and others.
 Organizations that have a higher levels of People-CMM have a
higher likelihood of implementing effective software project
management practice.
Badariah Solemon 2010
Four P’s: People ~ Stakeholders
 Defined as “individuals or organizations who stand to gain or
lose from the success or failure of a system” (Nuseibeh and
Easterbrook, 2000).
 By definition, stakeholders are those who are impacted by (or
have an impact on) the project.
 Example:





Senior managers who define the business issues that often have significant influence on
the project.
Project (technical) managers who must plan, motivate, organize, and control the
practitioners who do software work.
Practitioners who deliver the technical skills that are necessary to engineer a product or
application.
Customers who specify the requirements for the software to be engineered and other
stakeholders who have a peripheral interest in the outcome.
End-users who interact with the software once it is released for production use.
Badariah Solemon 2010
Four P’s: People ~ Team Leaders
 To be effective, the project team must be organized
in a way that maximizes each person’s skills and
attributes, which is the job of the team leader.
 What do we look for when choosing a team leader?


Based on MOI model of leadership by Weinberg (1986):
motivation, organization, ideas or innovation
Based on four traits of effective project manager by
Edgemon (1995): problem solving, managerial identity,
achievement, influence and team building
Badariah Solemon 2010
Four P’s: People ~ Team Leaders
 The MOI Model of leadership:



Motivation - the ability to encourage (by “push or pull”)
technical people to produce to their best ability.
Organization - the ability to mold existing processes (or
invent new ones) that will enable the initial concept to be
translated into a final product.
Ideas or innovation - he ability to encourage people to
create and feel creative even when they must work within
bounds established for a particular software product or
application.
Badariah Solemon 2010
Four P’s: People ~ Team Leaders
 Four traits of effective project manager by Edgemon
(1995):




Problem solving - can diagnose relevant technical and organizational
issues, systematically structure a solution or motivate others to
develop the solution, apply lesson learns from past projects to new
situation and many others.
Managerial identity – a good manager must take charge of the
project.
Achievement – reward initiative and accomplishment to optimize the
team productivity.
Influence and team building – able to ‘read’ people, understand verbal
and nonverbal signal and react to the needs of the people sending the
signals.
Badariah Solemon 2010
Four P’s: People ~ Software Team
How to lead?
How to organize?
How to collaborate?
How to motivate?
How to create good ideas?
Badariah Solemon 2010
Four P’s: People ~ Software Team
 The following factors must be considered when
selecting a software project team structure:







the difficulty of the problem to be solved
the size of the resultant program(s) in lines of code or function
points
the time that the team will stay together (team lifetime)
the degree to which the problem can be modularized
the required quality and reliability of the system to be built
the rigidity of the delivery date
the degree of sociability (communication) required for the
project
Badariah Solemon 2010
Four P’s: People ~ Agile Team
 Agile teams are formed for agile software development.
 Agile philosophy encourages customer satisfaction and early
incremental delivery of software, small highly motivated
project teams, informal methods, minimal software
engineering work products, and overall development
simplicity.
 The distribution of skills must be appropriate to the problem.
 Mavericks (individualist) may have to be excluded from the
team, if team cohesiveness is to be maintained.
 Agile teams are self-organizing.
Badariah Solemon 2010
Four P’s: People ~ Issues
 Software projects get into trouble because of reasons such as:




Scale- the scale of many development efforts is large, leading to
complexity, confusion, and significant difficulties in coordinating team
members.
Uncertainty- resulting in a continuing stream of changes
Interoperability- new software must communicate with existing
software and conform to predefined constraints imposed by the
system or product.
Formal and informal communication among team members and
between multiple teams must be established.
 Formal communication – writing, structured meetings, and other non-interactive
and impersonal communication channel.
 Informal communication – more personal. Members share ideas on an ad hoc
basis.
Badariah Solemon 2010
Four P’s: Product
 Before project can be planned:
1. Establish product objectives and scope - communication
with the customer and other stakeholders must occur so
that product scope and requirements are understood.
2. Identify technical and management constraints
3. Consider alternative solutions - enable the managers and
practitioners to select a “best” approach, given the
constraints imposed by delivery deadlines, budgetary
restrictions, personnel availability and other factors.
Badariah Solemon 2010
Four P’s: Product ~ Scope
 Scope is defined by answering the following questions:



Context. How does the software to be built fit into a larger
system, product, or business context and what constraints are
imposed as a result of the context?
Information objectives. What customer-visible data objects
(Chapter 8) are produced as output from the software? What
data objects are required for input?
Function and performance. What function does the software
perform to transform input data into output? Are any special
performance characteristics to be addressed?
 Software project scope must be unambiguous and
understandable at the management and technical levels.
Badariah Solemon 2010
Four P’s: Product ~ Scope
 Scope is defined by answering the following questions:



Context. How does the software to be built fit into a larger
system, product, or business context and what constraints are
imposed as a result of the context?
Information objectives. What customer-visible data objects
(Chapter 8) are produced as output from the software? What
data objects are required for input?
Function and performance. What function does the software
perform to transform input data into output? Are any special
performance characteristics to be addressed?
 Software project scope must be unambiguous and
understandable at the management and technical levels.
Badariah Solemon 2010
Four P’s: Product ~ Problem Decomposition
 Sometimes called partitioning or problem
elaboration.
 A complex problem is partitioned into smaller
problems that are more manageable.
Badariah Solemon 2010
Four P’s: Process
 A process that is appropriate for the
people and the product should be
selected.
Four P’s: Process ~ Melding the
Product and the Process
page: 658
Badariah Solemon 2010
Four P’s: Process~ Melding the
Product and the Process
 Refer to figure shown in previous slide.
 The job of the project manager (and other team
members) is to estimate resource requirements
for each matrix cell, start and end dates for the
tasks associated with each cell, and work
products to be produced as a consequence of
each task.
Badariah Solemon 2010
Four P’s: Process ~ Project Decomposition
 Factors that you need to look at when choosing
the process model:



The customers who have requested the product and
the people who will do the work
The characteristics of the product itself
The project environment in which the software team
works
Badariah Solemon 2010
Four P’s: Process ~ Project Decomposition
 Example of type of project and suitable
approach:


A relatively small project that is similar to past
efforts - linear sequential approach might be
suitable
The deadline is so tight that full functionality cannot
reasonably be delivered – incremental approach
might be suitable
Badariah Solemon 2010
Four P’s: Project
 The project must be planned by estimating
effort and calendar time to accomplish work
tasks.
 Some of the required activities: defining work
products, establishing quality checkpoints, and
identifying mechanisms to monitor and control
work defined by the plan.
Badariah Solemon 2010
Four P’s: Project
 Projects get into trouble when …










Software people don’t understand their customer’s needs.
The product scope is poorly defined.
Changes are managed poorly.
The chosen technology changes.
Business needs change [or are ill-defined].
Deadlines are unrealistic.
Users are resistant.
Sponsorship is lost [or was never properly obtained].
The project team lacks people with appropriate skills.
Managers [and practitioners] avoid best practices and lessons learned.
Badariah Solemon 2010
Four P’s: Project ~ CommonSense Approach to Projects
How does a manager act to avoid problems
discussed before?
 Start on the right foot. This is accomplished by working hard (very
hard) to understand the problem that is to be solved and then setting
realistic objectives and expectations.
 Maintain momentum. The project manager must provide incentives to
keep turnover of personnel to an absolute minimum, the team should
emphasize quality in every task it performs, and senior management
should do everything possible to stay out of the team’s way.
 Refer to footer (page 660) for the implication of above underlined
statement.
Badariah Solemon 2010
Project: Common-Sense
Approach to Projects
 Track progress. For a software project, progress is tracked as
work products (e.g., models, source code, sets of test cases)
are produced and approved (using formal technical reviews)
as part of a quality assurance activity.
 Make smart decisions. In essence, the decisions of the
project manager and the software team should be to “keep it
simple.”
 Conduct a postmortem analysis. Establish a consistent
mechanism for extracting lessons learned for each project.
Badariah Solemon 2010
The W5HH Principle
 A series of questions that lead to a definition of key
project characteristics and the resultant project plan.







Why is the system being developed?
What will be done?
When will it be accomplished?
Who is responsible?
Where are they organizationally located?
How will the job be done technically and managerially?
How much of each resource (e.g., people, software, tools,
database) will be needed?
Barry Boehm [Boe96]
Badariah Solemon 2010
Critical Practices
 Example of practices that is important in software
project management:

Metrics-based project management
 Measures of specific attributes of the process, project,
and product are used to compute software metrics.
 These metrics can be analyzed to provide indicators
that guide management and technical actions.
 Empirical cost and schedule estimation
 Estimate how much money, effort, resources
(people, hardware, software), risks, and time that
will take to build a system.
Badariah Solemon 2010
Critical Practices
1. Defect tracking against quality target


Requires that quality targets be set and that tracked
defects be analyzed against those targets.
Involve activities like recording defects in a database;
following a documented process to analyze, resolve, and
remove them; tracking the process; measuring defects
against quality targets; and reporting metrics on the
process to program management.
Badariah Solemon 2010
Critical Practices

Example of quality measures with examples of target
values, are as follows:
 Number of defects (a measure of reliability): less than 1 defect per
function point
 Cyclomatic Complexity (McCabe's): less than 10 for all modules
 Operator errors: Less than 5 per day
 Time to restore: less than 1 hour
 Timing: less than 1 second response time
 Fault tolerance: at least 80% of failures circumvented

Reference: https://goldpractice.thedacs.com/practices/gp_28.php
Badariah Solemon 2010
Critical Practices
2. Earned value tracking

Quantitative technique for assessing progress as the
software team progresses through the work tasks
allocated to the project schedule.
3. People aware management

Management of people that involve in project.
Badariah Solemon 2010
Summary
In this module, students should have learned
about:
 The importance of software project management
(SPM)
 The four P’s of effective project management:
people, product, process, project
 The W5HH Principle and critical practices for
performance-based management
Badariah Solemon 2010
References
 Contents in the slides are adopted from the
book and the slides that accompanied the
book by R.S. Pressman, Software Engineering:
A Practitioner’s Approach, 7th. Edition,
McGraw Hill, 2009.
Badariah Solemon 2010