SOFTWARE PROJECT

MANAGEMENT
UNIT - I
Dr.A.Pathanjali Sastri
Professor, Dean Academics & Quality Assurance
CONVENTIONAL SOFTWARE
MANAGEMENT
The Waterfall model
• The waterfall model is also called as linear sequential model or classic
life cycle model.
• Most software engineering texts present the waterfall model as the
source of the "conventional" software process.
• There are two essential steps common to the development of
computer programs: Analysis and Coding.
The Waterfall model
• In order to manage and control all of the intellectual freedom
associated with software development, one must introduce several
other "overhead" steps, including system requirements definition,
software requirements definition, program design, and testing.
• These steps supplement the analysis and coding steps.
The Waterfall model
• The basic framework described in the waterfall model is risky and
invites failure.
• The testing phase that occurs at the end of the development cycle is
the first event for which timing, storage, input/output transfers, etc.,
are experienced as distinguished from analyzed.
• The resulting design changes are likely to be so disruptive that the
software requirements upon which the design is based are likely
violated.
• Either the requirements must be modified or a substantial design
change is warranted.
The Waterfall model
• The following are 5 improvements to the basic waterfall process to
eliminate the development risks.
1) Program design comes first:
• Insert a preliminary program design phase between the software requirements
generation phase and the analysis phase.
• The insufficient resources and the design limitations are then identified in the
early stages
• Begin the design process with program designers, not analysts or programmers.
• Allocate processing functions, design the database, allocate execution time,
define interfaces and processing modes with the operating system, describe input
and output processing, and define preliminary operating procedures.
• Write an overview document that is understandable, informative, and correct.
The Waterfall model
2) Document the design
We know that document design is required a lot for software programs

• Each designer must communicate with interfacing designers, managers, and

possibly customers.
• During early phases, the documentation is the design.
• The real value of documentation is to support later changes by a separate test
team, a separate maintenance team, and operations personnel who are not
software literate.
The Waterfall model
3) Do it twice if possible:
The software delivered to the customer for operational purpose is actually the
second version after considering critical design and operational issues.
• In the first version, the team must have a special broad competence where
they can quickly sense trouble spots in the design, model them, model
alternatives.

4) Plan, control and monitor testing

• The combination of manpower, computer time and management is called the
test phase.
• This phase has greater risk in terms of cost and schedule
The Waterfall model
The following are the important things in test phase:
• Employ a team of test specialists who were not responsible for the original
design;
• Employ visual inspections to spot the obvious errors
• Test every logic path
• Employ the final checkout on the target computer.
The Waterfall model
5) Involve the customer:
• It is important to involve the customer in a formal way so that he has
committed himself at earlier points before final delivery.
• These include a "preliminary software review“ following the preliminary
program design step, a sequence of "critical software design reviews" during
program design, and a "final software acceptance review“ after testing is
performed.
The Waterfall model
• In Practice
• Some software projects still follow the conventional software management
process
• The characteristics of conventional model are:
1. Protracted integration and late design breakage
2. Late risk resolution
3. Requirements driven functional decomposition
4. Adversarial stakeholder relationships
5. Focus on documents and review meetings
The Waterfall model
1) Protracted integration and late design breakage
• Early success via paper designs and thorough briefings.
• Commitment to code late in the life cycle.
• Heavy budget and schedule pressure to get the system working.
• Late response of non optimal fixes, with no time for redesign.
• A very delicate, unmaintainable product delivered late.
The Waterfall model

• In conventional approach the use of immature languages and technologies is

difficult to understand the software project design and to change it in future.
• Here we perform system testing at the end of the process to check the
fundamental architecture is good or not.
The Waterfall model
• In the conventional model, the entire system was designed on paper, then
implemented all at once, then integrated.
• The following table provides a typical profile of cost expenditures across the
spectrum of software activities.
The Waterfall model
2) Late Risk Resolution
• A serious issue associated with the waterfall lifecycle was the lack of early risk
resolution.
• The following diagram illustrates a typical risk profile for conventional
waterfall model projects.
The Waterfall model
• Early in the life cycle, as the requirements were being specified, the actual
risk exposure was highly unpredictable.
• After a design concept available even on paper, risk exposure stabilized.
• In the next step, after the system was coded some of the individual
component risks was resolved.
• When the integration begins the real system risks are touchable.
The Waterfall model
3) Requirements driven functional decomposition
• The software development process has been requirements driven.
• We should present precise requirements definition and then implement
exactly those requirements.
• We should treat all the requirements are equally important.
• Requirement specification is an important and difficult job in the
development process.
The Waterfall model
4) Adversarial stake holder Relationship
• The contractor prepared a draft contract deliverable document and delivered
it to the customer for approval.
• The customer was expected to provide comments
• The contractor incorporated these comments and submitted a final version
for approval.
The Waterfall model
5) Focus on documents and Review meetings
• The conventional software development process focused on producing
various documents that attempted to describe the software product.
• The formal meetings were conducted to exchange specific documents.
• The developers produce tons of papers to describe the project progress to the
customers rather than to reduce risk and produce quality software.
Conventional Software Management
Process
• Barry Boehm describes the objective characterization of the state of
software development.
1. Finding and fixing a software problem after delivery costs 100 times more
than finding and fixing the problem in early design phases.
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.
Conventional Software Management
Process
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 the errors are caused by 20% of the components
• 80% of software scrap and rework is caused by 20% of the errors
• 80% of the progress is made by 20% of the people