ZeePedia buy college essays online

Software Project Management

<<< Previous Project Dimensions, Software Development Lifecycle Next >>>
Software Project Management (CS615)
1. Introduction & Fundamentals
Project Dimensions
Product and Technology
­ The 80:20, rule was originated by Vilfredo Pareto, an Italian economist who
studies the distribution of wealth in a variety of countries around 1900. He
discovered a common phenomenon: about 80% of the wealth in most countries
was controlled by a consistent minority -- about 20% of the people. Pareto called
this a "predictable imbalance." His observation eventually became known as
either the "80:20 rule" or "Pareto's Principle."
The credit for adapting Pareto's economic observations to business goes to the
"Father of Total Quality Management," service quality consultant Joseph M.
Juran. In 1950, he published "The Quality Control Handbook," which first
recognized the applicability of the Pareto principle in the context of inventory
management, e.g.:
20% of the repair parts normally account for 80 percent of the total
80% of production volume usually comes from 20% of the producers
He subsequently recognized that this rule of thumb was universally applicable
across fields of endeavor. As a credit to Pareto's work, Juran named his finding
the Pareto Principle. This universal management theory became generalized as
"the 80-20 Rule":
The "80:20 rule" has become one of the best known "leadership shorthand terms"
reflecting the notion that most of the results (of a life, of a program, of a financial
campaign) come from a minority of effort (or people, or input).
The Rule, states that a small number of causes (20%) is responsible for a large
percentage (80%) of the effect. It means that in anything a few (20 percent) are
vital and many (80 percent) are trivial.
There is an inherent imbalance between cause and effect, effort and reward, inputs
and outputs, etc; and that imbalance tends to the ratio of 80:20. So, if we know
which 20% of our work produces 80% of our income, we can do more of it and
our income will increase proportionately!
Software Project Management (CS615)
You know 20 percent of you stock takes up 80 percent of your warehouse space
and that 80 percent of your stock comes from 20 percent of your suppliers. Also
80 percent of your sales will come from 20 percent of your sales staff. 20 percent
of your staff will cause 80 percent of your problems, but another 20 percent of
your staff will provide 80 percent of your production. It works both ways.
Some Sample 80/20 Rule Applications
80% of process defects arise from 20% of the process issues.
20% of your sales force produces 80% of your company revenues.
80% of delays in schedule arise from 20% of the possible causes of the delays.
80% of customer complaints arise from 20% of your products or services.
How It Can Help You
­ The value of the Pareto Principle for a manager is that it reminds you to focus on
the 20 percent that matters. Of the things you do during your day, only 20 percent
really matter. Those 20 percent produce 80 percent of your results. Identify and
focus on those things. When the fire drills of the day begin to sap your time,
remind yourself of the 20 percent you need to focus on. If something in the
schedule has to slip, if something isn't going to get done, make sure it's not part of
that 20 percent.
Pareto's Principle, the 80/20 Rule, should serve as a daily reminder to focus 80
percent of your time and energy on the 20 percent of you work that is really
important. Don't just "work smart", work smart on the right things.
­ Size
The larger product, there will be more requirements and features to deliver,
eventually it will take more time in its production. So if you cut the size of the
produce to half it will save you 60% of the effort.
­ Characteristic
­ Development Tools
Software Project Management (CS615)
Customer delivered value
Value of products
Total value
Value of services
Personal value
Real value to
Image value
the customer
Financial cost
Total costs
Time cost
Energy cost
Psychical cost
Project Phases
Organizations performing projects will usually divide each project into several
Project phases to improve management control and provide for links to the
ongoing operations of the performing organization.
Collectively, the project phases are known as the project life cycle. Software
development, just like most other activities, has a beginning, middle and an end.
The end of one development activity is sometimes perceived as being linked to
the beginning of a new development activity thus producing a cycle of beginning-
middle-end, link, beginning-middle-end, link, and so forth.
This view of software development is referred to as the software development
life cycle.
A project has five phases. Here's a brief summary of each:
Articulate your vision for the project, establish goals, assemble your team,
and define expectations and the scope of your project.
Refine the scope, identify specific tasks and activities to be completed,
and develop a schedule and budget.
Accomplish your goals by leading your team, solving problems, and
building your project.
Software Project Management (CS615)
Monitor changes to the project make corrections, adjust your schedule to
respond to problems, or adjust your expectations and goals.
Deliver your project to your audience, acknowledge results, and assess its
success. Take the time to compose a written evaluation of the project and
the development effort.
The middle three phases are not sequential. You will find that you are constantly
planning, executing, and controlling your project as necessary.
Aren't these phases really just common sense? In many ways, yes, but keep in
mind that software development, whether a few Web pages or a complex CD-
ROM, is a complex, unpredictable process.
Most software projects (something like 80 percent) are delivered late,
substantially over budget, and incomplete. The more effort you put into managing
your project, the more you increase your chances of success.
­ Characteristics of Project Phases
Each project phase is marked by completion of one or more deliverables. A
deliverable is a tangible, verifiable work product such as a feasibility study, a
detail design, or a working prototype. The deliverables, and hence the phases, are
part of a generally sequential logic designed to ensure proper definition of the
product of the project.
The conclusion of a project phase is generally marked by a review of both key
deliverables and project performance to date, to a) determine if the project should
continue into its next phase and b) detect and correct errors cost effectively. These
phase-end reviews are often called phase exits, stage gates, or kill points.
Each project phase normally includes a set of defined deliverables designed to
establish the desired level of management control. The majority of these items are
related to the primary phase deliverable, and the phases typically take their names
from these items: requirements, design, build, test, startup, turnover, and others,
as appropriate.
­ Characteristics of the Project Life Cycle
The project life cycle serves to define the beginning and the end of a project. For
example, when an organization identifies an opportunity to which it would like to
respond, it will often authorize a needs assessment and/or a feasibility study to
decide if it should undertake a project. The project life-cycle definition will
determine whether the feasibility study is treated as the first project phase or as a
separate, standalone project.
Software Project Management (CS615)
The project life-cycle definition will also determine which transitional actions at
the beginning and the end of the project are included and which are not. In this
manner, the project life-cycle definition can be used to link the project to the
ongoing operations of the performing organization.
The phase sequence defined by most project life cycles generally involves some
form of technology transfer or handoff such as requirements to design,
construction to operations, or design to manufacturing. Deliverables from the
preceding phase are usually approved before work starts on the next phase.
However, a subsequent phase is sometimes begun prior to approval of the
previous phase deliverables when the risks involved are deemed acceptable. This
practice of overlapping phases is often called fast tracking.
Project life cycles generally define:
What technical work should be done in each phase (e.g., is the work of the
architect part of the definition phase or part of the execution phase?).
Who should be involved in each phase (e.g., implementers who need to be
involved with requirements and design).
Project life-cycle descriptions may be very general or very detailed. Highly
detailed descriptions may have numerous forms, charts, and checklists to
provide structure and consistency. Such detailed approaches are often called
project management methodologies.
Most  project  life-cycle
Cost and staffing levels are low at the start, higher toward the end, and drop
rapidly as the project draws to a conclusion.
The probability of successfully completing the project is lowest, and hence
risk and uncertainty are highest, at the start of the project. The probability of
successful completion generally gets progressively higher as the project
The ability of the stakeholders to influence the final characteristics of the
project's product and the final cost of the project is highest at the start and
gets progressively lower as the project continues. A major contributor to this
phenomenon is that the cost of changes and error correction generally
increases as the project continues.
Care should be taken to distinguish the project life cycle from the product life
cycle. For example, a project undertaken to bring a new desktop computer to
market is but one phase or stage of the product life cycle.
Although many project life cycles have similar phase names with similar
deliverables required, few are identical. Most have four or five phases, but some
Software Project Management (CS615)
have nine or more. Even within a single application area, there can be significant
One organization's software development life cycle may have a single design
phase while another's has separate phases for functional and detail design.
Subprojects within projects may also have distinct project life cycles. For
example, an architectural firm hired to design a new office building is first
involved in the owner's definition phase when doing the design, and in the
owner's implementation phase when supporting the construction effort. The
architect's design project, however, will have its own series of phases from
conceptual development through definition and implementation to closure. The
architect may even treat designing the facility and supporting the construction as
separate projects with their own distinct phases.
­ Project Life Cycle includes the following Phases and activities:
A. Concept Phase
1. User Need
2. Initial Investigation
3. User Review
4. System Performance Design
5. Candidate Review
6. Study Phase Report
B. Requirements Phase
1. The software requirements specification document
2. The project development plan
3. The software test plan
C. Design Phase
1. General System Review
2. Processing Requirements Identification
3. Data Base Design
4. Control Requirements
5. Output Design
6. Input Design
7. Software Selection
8. Equipment Selection/Acquisition
9. People
10. Reference Manual Identification
11. Plans
12. Design Specifications Preparation
13. Design Phase Report Preparation
D. Development Phase
Software Project Management (CS615)
1. Implementation Planning
2. Computer Program Design
3. User Review
4. Equipment Acquisition and Installation
5. Coding and Debugging
6. Computer Program Testing
7. System Testing
8. Reference Manual Preparation
9. Personnel Training
10. Changeover Plan Preparation
11. Development Phase Report Preparation
12. User Acceptance Review
E. Operation Phase
1. System Changeover
2. Routine Operation
3. System Performance Evaluation
4. System Changes/Enhancements
Software Development Lifecycle
Water Fall Theme
Software development, just like most other activities, has a beginning, middle and
an end. The end of one development activity is sometimes perceived as being
linked to the beginning of a new development activity thus producing a cycle of
beginning-middle-end, link, beginning-middle-end, link, and so forth. This view
of software development is referred to as the software development life cycle.
There are many variations of the software development life cycle. Figure 1
presents a simple life cycle that was common during the first few decades of
software development. In those early days of software development, the
programmer would create programs by iterating from code to fix then back to
code, and then to fix again, until something acceptable was (hopefully) produced.
At the start of the cycle, there was usually no clear concept of what was required,
and the basic development procedure was a form of 'let's see what we can do'
The software development method represented by the development cycle in Fig.1
is often referred to as the code and fix method (for obvious reasons). Software
development methodologies have come a long way since the days of code and fix,
though it is surprising how much software is still being developed this way.
Successful management of any project, especially software projects, requires
planning, and planning is impossible with code and fix, which is totally
unpredictable. Management of software development within an engineering
Software Project Management (CS615)
discipline is based on a much more orderly set of development phases. These
phases are not implemented solely by programmers; they require software
engineers. In fact, programming has become a relatively small part of the modern
software development cycle, as is evident from Table 1.
The numbers in Table 1 are derived from the general shift in emphasis to software
planning (requirements and design) and testing. Commercial data processing
systems, with some exceptions, still spend a significant amount of development
time in the programming and unit testing phase. Real-time systems are often more
complex, and may include extensive hardware software integration. This usually
requires more planning and more integration and testing.
Figure 1: the code and fix method
Table 1 Estimated percentage of time spent in each major software development phase
Code and unit test Integration and test
Commercial data processing 25%
Real-time systems
Military systems
Military systems require high reliability and are usually closely supervised by the
customer, leading to a significant increase in the time spent in planning.
The data in Table 1, of course, represents a generalization; commercial data
processing systems can be just as complex as a real-time system.
Figure 2 presents the basic phased model of a software development cycle. This
model, called the Waterfall model, gets its name from the way in which each
phase cascades into the next (due to overlapping), as demonstrated in Fig. 3.
Some interpretations of the Waterfall model, like the one that follows, combine
the top level design and the detailed design phases into a single design phase, and
the integration and test phases into a single phase. In fact, there are many
variations of the classic Waterfall model, but they are all based upon a systematic
transition from one development phase to the next, until the project is complete.
Software Project Management (CS615)
Top level
Figure 2: The phased model of the software development life cycle
Software requirements
Top level" design
Detailed design
Figure 3: The Waterfall model of the software development life cycle
Rapid prototyping There are other development methodologies that do not move
from one phase to the next like the Waterfall model. Rapid prototyping, for
Software Project Management (CS615)
instance, iterates in a mini-development phase until a system prototype is
developed (see Fig. 4). After the prototype is complete, the Waterfall approach
can then be implemented to complete the full system. Rapid prototyping is
particularly helpful in projects where the requirements are difficult to specify. The
prototype can be used as a tool for analyzing and determining what the
requirements should be.
The Spiral model, described by Boehm (1988), is another development method
that iterates between the requirements, design and implementation phases.
However, the Spiral model continues iterating until the final system is complete.
Within each, iteration, the Spiral model follows a phased approach similar to the
Waterfall model.
Different models maybe suitable for different software projects or for different
software development organizations However, a good model must include certain
fundamental features. Some of these basic requirements are discussed in IEEE
Standard (IEEE 1993) Standard for Software Life Cycle Processes. This standard
describes the processes that are mandatory for the development of software and
specifies the activities that must be included in the life cycle model.
Most modern software development models, and certainly those following IEEE
Standard 1074, include some form of the basic phased model. It is therefore
important to understand the different phases and how they relate to one another.
The rapid prototyping cycle
Figure 4: Rapid prototyping followed by the phase method.
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration