Home  For Educators: Lecture Notes and Handouts
|
Slides and Lecture Notes |
|
|
These slides can be used by professors, teachers and trainers who have
adopted "Applied Software Project Management" as a textbook. The
PowerPoint files and their contents can be used (with attribution) in
other presentations and publications.
There is one slide set for each chapter in the book.
Lecture 1: Introduction to Applied Software Project Management
Why projects fail, how to make them succeed.
Abstract:
Many software organizations have problems delivering quality
software that is finished on time and meets the users' needs. Luckily,
most software project problems have surprisingly few root causes, and
these causes are well understood. Solutions to these problems have been
discovered, explained, and tested in thousands of software
organizations around the world. These solutions are generally
straightforward and easy to implement. However, they are not always
intuitive to people who do not understand project management, and that
makes them difficult to introduce. It's possible to make projects
succeed by recognizing the common causes of project failure, and
applying basic project management principles in order to address those
causes. (This lecture corresponds to Chapter 1.)
Lecture 2: Software Project Planning
Using a Vision and Scope document to identify needs; Elements of a project plan.
Abstract:
If a project manager does not really understand the context in which
the software is being built, then the only thing that the project team
sees is the urgency; they lose track of the needs. They can see the
individual problems that they are working to solve, but they may lose
track of the big picture. Unless the team understands the needs that
drive the project, they may end up with a narrow focus, causing them to
waste time addressing problems that are of little importance to the
stakeholders. It’s easy to build great software that solves the wrong
problems, but the only way to build the appropriate software is for
everyone in the project to understand and agree on both why and how
that software will be built before the work begins. That’s the purpose
of project planning. (This lecture corresponds to Chapter 2.)
Lecture 3: Estimation
Helping the project team create realistic estimates.
Abstract:
To someone who has never estimated a project in a structured way,
estimation seems little more than attempting to predict the future.
This view is reinforced when off-the-cuff estimates are inaccurate and
projects come in late. But a good formal estimation process, one that
allows the project team to reach a consensus on the estimates, can
improve the accuracy of those estimates, making it much more likely
that projects will come in on time. A project manager can help the team
to create successful estimates for any software project by using sound
techniques and understanding what makes estimates more accurate. (This
lecture corresponds to Chapter 3.)
Lecture 4: Project Schedules
Creating, optimizing and tracking a project schedule.
Abstract:
The project schedule is the core of the project plan. It is used by the
project manager to commit people to the project and show the
organization how the work will be performed. Schedules are used to
communicate final deadlines and, in some cases, to determine resource
needs. They are also used as a kind of checklist to make sure that
every task necessary is performed. If a task is on the schedule, the
team is committed to doing it. In other words, the project schedule is
the means by which the project manager brings the team and the project
under control. (This lecture corresponds to Chapter 4.)
Lecture 5: Reviews
Different practices for reviewing work products.
Abstract:
A review is any activity in which a work product is distributed to
reviewers who examine it and give feedback. Different work products
will go through different kinds of reviews: the team may do a very
thorough, technical review of a software requirements specification,
while the vision and scope document will be passed around via email and
have higher level walkthroughs. Reviews are useful not only for finding
and eliminating defects, but also for gaining consensus among the
project team, securing approval from stakeholders, and aiding in
professional development for team members. In all cases, the work
product coming out of the review has fewer defects than it had when it
was submitted—even though the author thought it was “complete” before
the review. Every defect that is found during a review is a defect that
someone did not have to spend time tracking down later in the project. (This lecture corresponds to Chapter 5.)
Lecture 6: Software Requirements
Eliciting requirements, creating a software requirements specification and controlling changes.
Abstract:
Most software is built to meet the needs of someone other than the
programmer. If those needs are going to be satisfied, the behavior of
the software must be planned before the software is built. Software
requirements engineering is the art and science of developing an
accurate and complete definition of the behavior of software that can
serve as the basis for software development. Like project management,
programming, and testing, software requirements engineering encompasses
a set of skills that require training and practice. Many projects are
delayed (or fail completely) because development begins before anyone
on the project team really understands how the software should behave.
The solution to this problem is to take the time to gather and verify
the software requirements — documentation that completely describes the
behavior that is required of the software — before the software is
designed, built, and tested. (This lecture corresponds to Chapter 6.)
Lecture 7: Design and Programming
Reviewing the design, refactoring, unit testing and project automation.
Abstract:
While many development problems originate outside of the programming
team, there are some basic changes that the programmers can make that
will improve the quality of the code they produce. Most teams, even
ones with skilled and talented programmers, are vulnerable to the same
design and programming problems. These problems can be addressed with a
few basic tools and techniques—which can often be put in place entirely
within the programming team, without involving anyone else in the
organization. (This lecture corresponds to Chapter 7.)
Lecture 8: Software Testing
Test plans, test cases, defect tracking, automation and post-mortem reports.
Abstract:
In software testing, quality is defined as “conformance to
requirements.” Every use case, functional requirement, and other
software requirement defines a specific behavior that the software must
exhibit. When the software does not behave the way that the
requirements say it must behave, that is a defect. This means that your
software testers are responsible for figuring out whether the software
that was produced by the team behaves in the way that the requirements
it was built from say that it should. Throughout the entire software
project, the team does many things to find and prevent defects. Once
the software has been built, it’s time to look back and make sure that
it meets the requirements. The goal of software testing is to make sure
that the product does what the users and stakeholders need it to do.
Software testers review the final product to make sure that the initial
requirements have been met. (This lecture corresponds to Chapter 8.)
Lecture 9: How to diagnose and fix a troubled software project, part I
Lecture 10: How to diagnose and fix a troubled software project, part II
Abstract:
There's an old saying: "There's only one way to be right, but a million
ways to be wrong." This is not necessarily the case with software
projects. In practice, the vast majority of projects go wrong in one of
a small number of ways. Throughout Part I of "Applied Software Project
Management," many scenarios are identified which highlight the most
common causes of project failure. Lecture 9 shows how projects can fail
due to problems with project planning, estimation, and failure to hold
reviews. Lecture 10 shows project problems that are caused by poor
requirements engineering practices, bad programming habits, or a lack
of software testing. Both lectures cover many scenarios that typify how
projects fail, and point to some of the tools, techniques and practices
that project managers can use to fix them.
Lecture 11: Understanding Change
Why change fails, and how to make your changes succeed.
Abstract:
It would be nice if it were sufficient to understand why projects fail,
and to know how to apply specific tools, techniques and practices to
fix them. Unfortunately, that's not enough. Building better software
requires changing the way things are done in your organization, and
change makes many people very uncomfortable. Project managers around
the world have tried to implement straightforward improvements to the
way they build software, only to find that they can't convince the
other people in their organizations to agree to discuss those changes,
much less to actually alter the way their projects are carried out. It
can be frustrating to see a problem, feel like you have the solution,
and not be able to do anything about it. By understanding the most
common ways that people respond to change and learning how to convince
or reassure the ones who are resistant to change, it is possible to
overcome these obstacles and successfully make the changes that your
organization needs. (This lecture corresponds to Chapter 9.)
Lecture 12: Management and Leadership
Managing your organization, team and project.
Abstract:
In a sense, part of the job of the project manager is to serve as an
information conduit. The project manager helps information flow from
the team up to senior management in the form of project status and
analysis information. It is his job to understand all of the work being
done, so that it can be summarized to the people who make the decisions
about the future of the project; they need this information to make
informed and intelligent decisions. This requires that the project
manager put a lot of effort into understanding what it is the team is
doing and why they are doing it. The project manager cannot simply ask
for estimates, fit those estimates in a schedule, and quiz the team on
the percentage they’ve completed. He must understand what actions each
team member is taking to complete the task, and what possible
complications they are running into. The project manager is the only
person looking at how the tasks interrelate; he is the only one with
the perspective to see the problems and, ideally, fix them. (This lecture corresponds to Chapter 10.)
Lecture 13: Managing an Outsourced Project
Avoiding the common pitfalls that happen when working with an outsourced vendor.
Abstract:
Managing projects is hard. Scope creeps, changes go uncontrolled,
defects are introduced, schedules are delayed…and that’s all in your
own organization, where your software engineering team is right down
the hall. Imagine how difficult it is to get even these results when
your team is in another organization in an entirely different
building—and possibly in a city halfway around the world! When you hire
a company outside your organization to build your software, you open up
yourself, your project, and your organization to exactly these
problems. (This lecture corresponds to Chapter 11.)
Lecture 14: Process Improvement
A formal software process can help the organization expand its capability.
Abstract:
If you ask a dozen people on a software team to describe how the team
should build software, you’ll get at least a dozen different
answers—and most of those descriptions, if followed, will produce
something. But what’s produced may not be very good: it may not be
useful to the users, it may not be of very high quality, and the team
may not be comfortable building, delivering, or maintaining it. A
software process makes sure that everyone on the team agrees up front
on how they will build software, while simultaneously ensuring that the
software will be built in a way that works for the team and the
organization. (This lecture corresponds to Chapter 12.)
All photos by Nisha Sondhe, except Lecture 7 by Steven Stellman.
|
|
|
|
