Download Software Project Management Direct

Project Management for
Modern Software Development
Timothy Korson
Sothern Adventist University
1/41
Software Project Management
Direct
2/41
Recommended Reading
Addison Wesley
ISBN-0-201-30958-0
For an excellent compilation of information on
general project management see the Project
Management Body of Knowledge published by the
Project Management Institute. Information on it
can be found at www.pmi.org
3/41
Management Activities
Manage risk
Planning the work
Measure the project
Resource planning
Ensure quality
Foster reuse
Communicate with stakeholders
Manage the project team
4/41
What Do Project Managers Do?
 Team Management
 Plan, Schedule, Track
Direct
 Resource Allocation
 Project Direction
 Politics
 Remove Project Obstacles
5/41
Team Management
Direct
 Manage the people on the team
 Motivation
 Conflict resolution
 Evaluation, promotion
 Recruitment, retention
 Career development
 Task assignment
6/41
Scheduling
 Plan and Track the project
 Detailed planning and scheduling
Direct




Per person planning and tracking
Iterations
Increments
Testing, Deployment, Support
 Big Picture
 Functionality Time Tradeoffs
 Delivery dates
7/41
Management
 The basic questions:
 Where are we?
Question
 Are we making progress?
 When will we be finished?
 How much will it cost?
 What is the quality?
8/41
Resource Allocation
Direct







Staffing
Software development tools
Software components
Computer resources
External resources
Space
Etc.
9/41
Direction
Direct
 Keep the project direction aligned
with the stakeholders vision
 Quality vs. Functionality vs. Cost
tradeoffs
10 - 44
10/41
Politics
 Project interface and team buffer
Direct
 Manage stakeholder relationships
 Protect the team from the whims of
exterior forces
 Negotiate with upper level
management and project
stakeholders
 Manage interaction with other
teams, such as testing and quality
assurance
 Fight for resources
11/41
Remove Project Obstacles
 Daily Project Meeting Identifies
 Bottlenecks
 Needed resources
 Issues that need resolving
 Conflicts between stakeholders
 Differences between plans and
actualities
 Processes that need improvement
12/41
How Does The Use of Agile Processes Affect
These Management Tasks?
Direct
 Team Management
 Less Assigning of Tasks
 More mentoring
 Plan, Schedule, Track
 Less detailed plans
 More Stakeholder Education
 Different Style of Contracts
 Different Use of Plans
 Resource Allocation
 Project Direction
 Alignment of Stakeholder Values
 Politics
13/41
Stakeholders
 A stakeholder is any individual who
affects or is affected by the
application being built:
Define
 Client (those who are paying)
 User (those who interact with the application)



14/41
Stakeholders
“Involve real users [stakeholders]
throughout the software development
process; their presence is a constant
reminder why and for whom the
software is being crafted.” [Booch]
15/41
Project Management
 Project management is the application of
knowledge, skills, tools, and techniques to project
activities in order to meet or exceed stakeholder
needs and expectations from a project.
Define
 Meeting or exceeding stakeholder needs and
expectations involves balancing competing
demands:
 Scope, time, cost, and quality
 Differing needs and expectations among stakeholders
 Identified requirements vs. unidentified requirements
16/41
Why Do Software Projects Fail?
 We fail to properly manage risks
 We don’t build the right thing
Question
 We are blindsided by technology
Notice the “We”. As project managers, we develop
idealistic plans, we set unrealistic schedules, we deceive
ourselves and others, and we refuse to face reality. These
projects eventually enter “free fall” with no one taking
responsibility and everyone waiting for the crash (while
sending out resumes).
17/41
Fail To Properly Manage Risks
 “Management must actively attack a project’s
risks, otherwise they will actively attack you.”
[Gilb]
 The first step in managing risks is to identify
them
 people
 technology
 environment
 dependenciies
18/41
Don’t Build The Right Thing
 Incorrect focus on requirements rather than on
business goals and objectives.
 Examples:
 Inventory
 NASA
 Road
19/41
Blindsided By Technology
 Concepts are more difficult than they seem, tools
don’t scale up or they introduce errors, suppliers
don’t deliver promised functionality or
performance. Interactions are more complex that
understood.
(Engine Control Unit)
20/41
Project Management To The Rescue
 Effective project management actively
works to minimize these problems by:
 Explicitly identifying and creating written
mitigation and contingency plans for project
risks
 Continuous demonstration and early and
frequent deployment of the product being built
 Continuous validation of the technologies for
use on the project
21/41
Two Types of Risk
 Project and Process Risk
 What could go wrong with this project?
Define
 Product or Requirements Risk
 Which faults would be most damaging to the
stakeholders?
22/41
Managing Project Risk
 Risk Dimensions
 Uncertainty – An event may or may not
happen. What is the probability of its
occurrence?
 Damage – What are the implications to the
project if the risk occurs?
 Problem
 A risk that has occurred.
23/41
Managing Risk
The most serious risk factors that affect development
projects are:
1) Requirements Problems
Incorrect, incomplete, misunderstood, or creeping
2) Management Malpractice
2.1 Excessive cost or schedule pressure
2.2 Failure to plan, track or control within the framework of a modern
development process
-- inaccurate resource estimation
-- denial
2.3 Poor Team Management
3) Poor Quality Software Engineering
…inadequate technical expertise
4) Technology Failure
24/41
Managing Project Risk
 Acceptance – The level of risk is
deemed to be within acceptable limits.
Define
 Mitigation – Take steps to minimize the
loss.
 Prevention – Take steps to minimize
the probability.
25/41
Managing Product Risk
 Establish risk criteria:
 Operational Profile (Frequency of Use)
 Consequence of Failure
 Probability of failure
 Use risk analysis to allocate:
 analysis resources
 architectural resources
 testing resources
 management resources
26/41
Early Risk Resolution
 80% of the engineering is consumed by 20% of the
requirements.
 80% of the software cost is consumed by 20% of the
components.
 80% of the errors are caused by 20% of the components.
 80% of software scrap and rework is caused by 20% of the
changes.
 80% of the resource consumption (execution time, disk space,
memory) is consumed by 20% of the components.
 80% of the engineering is accomplished by 20% of the tools.
 80% of the progress is made by 20% of the people.
Royce
27/41
Risk profile of a typical modern project
across its life cycle.
Inception
Elaboration
Construction--Transition
High
Project Risk Exposure
Controlled Risk
Management Period
Conventional
Project Risk Profile
Modern Project
Risk Profile
Risk Exploration
Period
Risk Resolution
Period
Low
Project Life Cycle
Royce
28/41
7(±2) Habits Of Successful Projects
 A ruthless focus on developing a system that provides a
set of essential but minimal characteristics.
 A culture that is centered on results, encourages
communication, and yet is not afraid to fail.
 The application of a well-managed iterative and
incremental development life cycle.
 Creating and communicating a strong, coherent, and
resilient architectural vision.
 Effective use of object-oriented modeling.
 A management team that is obsessed with quality through
adherence to the fundamental principles of software
development
29/41
Top 10 Principles of Modern Software
Management
Direct
1. Base the process on an architecture first approach.
2. Establish an iterative lifecycle process that confronts risk early.
3. Transition design methods to emphasize component-based
development.
4. Establish a change management environment.
5. Enhance change freedom through tools that support round-trip
engineering.
6. Capture design artifact in rigorous, model-based notation.
7. Instrument the process for objective quality control and progress
assessment.
8. Use a demonstration-based approach to assess intermediate
artifacts.
9. Plan intermediate releases in groups of usage scenarios with
evolving levels of detail.
10. Establish a configurable process that is economically scalable.
Royce
30/41
Software Management Best Practices

Formal risk management - using an iterative process.

Agreement on interfaces - same intent as architecture-first
principle.

Formal inspections

Metric-based scheduling and management - directly related to
model-based notation and objective quality control principles.

Binary quality gates at the inch-pebble level - evolving levels of
detail principle.

Programwide visibility of progress versus plan.

Defect tracking against quality targets - directly related to
architecture-first and objective quality control principles.

Configuration management - same reasoning behind the
change management principle.

People-aware management accountability.
Direct
Software Acquisition Best Practices Initiative
Airlis Software Council
31/41
Top 30 Principles of Conventional
Software Engineering
1.
Make quality #1.
•
2.
Depends what one means by quality
High–quality software is possible.
•
3.
Agreed, but bug free software is next to impossible
Give products to customers early.
•
4.
Yes, but
ISBN: 0070158401 McGraw Hill
Determine the problem before
writing the requirements.
•
•
Domain analysis before detailed use cases
Develop the requirements incrementally
32/41
Top 30 Principles of Software Engineering cont.
5) Evaluate design alternatives.
•
Make sure to to test the design against the business goals
6) Use an appropriate process model.
•
Configure yes, but don’t neglect the fundamentals
7) Use different languages for different phases.
•
Use cases, class diagrams, …
8) Minimize intellectual distance.
•
Absolutely
33/41
Top 30 Principles of Software Engineering cont.
9) Put techniques before tools.
•
The good old days are long gone….
10)Get it right before you make it faster.
•
Yes, but
11)Inspect code.
•
Not in the top 30
12)Good management is more important than good
technology.
•
Let me explain...
34/41
Top 30 Principles of Software Engineering cont.
13) People are the key to success.
•
Should be in the top 5
14) Follow with care.
•
Good advice
15) Take responsibility.
•
Your parents should have taught you this
16) Understand the customer’s priorities.
•
Change customer to stakeholder.
17) The more they see, the more they need.
•
True, but don’t let that stop you
35/41
Top 30 Principles of Software Engineering cont.
18)Plan to throw one away.
•
Too waterfall...
19)Design for change
•
Absolutely, but formally define the scope of anticipated change
20)Design without documentation is not design.
•
False
21)Use tools, but be realistic.
•
Also be realistic about what will happen if you don’t use tools!
22)Avoid tricks.
•
How about: “document your tricks”
36/41
Top 30 Principles of Software Engineering cont.
23) Encapsulate.
•
Move this to the top 10
24) Use coupling and cohesion.
•
A bit simplistic
25) Use the McCabe complexity measure.
•
If you suspect the quality of your software engineers ...
26) Don’t test your own software.
•
Don’t be the only one to test ...
37/41
Top 30 Principles of Software Engineering cont.
27)Analyze causes for errors.
•
A principle of process improvement
28)Realize that software’s entropy increases.
•
Only if you let it
29)People and time are not interchangeable.
•
But they are linked
30)Expect Excellence.
•
And you may get it
38/41
What Do Project Managers Do?
 Team Management
 Plan, Schedule, Track
Direct
 Resource Allocation
 Project Direction
 Politics
 Remove Project Obstacles
39/41
Management
 Management is more than the ability to
estimate, plan and track
Direct
 Good managers understand the
fundamentals of good software engineering,
and build an environment and culture that
reward quality.
40/41
Don’t Confuse Activity with Accomplishment!
 Do what you have to do
Direct
 Team Management
 Plan, Schedule, Track
 Resource Allocation
 Project Direction
 Politics
 But don’t neglect achieving
your primary responsibility
 Value to the stakeholders
41/41