Software Project Management

Unit1
1.1 Introduction
Software
The software can be best defined as a set of instructions, technically referred to as
programs, that perform operations and specific tasks based on the commands of the
user.
project

Project is a piece of work, often involving many people, that is planned and organized
carefully.
Management

Management is the process of organizing and controlling people, resources, and tasks to
achieve a specific goal. It can also be defined as the application of policies, procedures,
and strategies to achieve business objectives.
Software Project Management
ment (SPM) is the process of planning, implementing, monitoring, and controlling
software projects. It's a specialized sub-discipline of project management that focuses
on the systematic management of resources, time, and budget to ensure a project's
successful completion.
1.2 Waterfall Model
The Waterfall Model was the first Process Model to be introduced. It is also referred to
as a linear-sequential life cycle model.
Also called as linear model.
It is very simple to understand and use. In a waterfall model, each phase must be
completed before the next phase can begin and there is no overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software
development.
The waterfall Model illustrates the software development process in a linear sequential
flow. This means that any phase in the development process begins only if the previous
phase is complete. In this waterfall model, the phases do not overlap.
Introduced by Winston Royce in 1970
The sequential phases in Waterfall model are −
 • Requirement Gathering and analysis − All possible requirements of the system
to be developed are captured in this phase and documented in a requirement
specification document.
• System Design − The requirement specifications from first phase are studied in
this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture.
• Implementation − With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next phase.
Each unit is developed and tested for its functionality, which is referred to as Unit
Testing.
• Integration and Testing − All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done;
the product is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment.
To fix those issues, patches are released. Also to enhance the product some
better versions are released. Maintenance is done to deliver these changes in the
customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name
"Waterfall Model". In this model, phases do not overlap.
Advantages :
Some of the major advantages of the Waterfall Model are as follows:
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Easy to arrange tasks.
• Process and results are well documented.
Disadvantages:
The major disadvantages of the Waterfall Model are as follows −
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
 • Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.

1.3 Conventional Software Management Performance :

2. You can compress software development schedules 25% of nominal, but no more.

3. For every $1 you spend on development, you will spend $2 on maintenance.

4. Software development and maintenance costs are primarily a function of the number
of source lines of code.

5. Variations among people account for the biggest differences in software productivity.

6. The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in
1985, 85:15.

7. Only about 15% of software development effort is devoted to programming.

8. Software systems and products typically cost 3 times as much per SLOC as individual
software programs. Software-system products (i.e., system of systems) cost 9 times as
much.

9. Walkthroughs catch 60% of the errors.

10. 80% of the contribution comes from 20% of the contributors.

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 software scrap and rework is caused by 20% of the errors.

80% of the resources are 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.

These relationships provide some good benchmarks for evaluating process improvements
and technology improvements.

Also called as the “Pareto Principle “