Software project management

1. Conventional
Software
Management
• The traditional method for the development of
software is called as conventional approach.
• The best thing and worst thing about software is
“FLEXIBILITY”…because the outcome of flexibility is
unpredictable.
• The 3 important analyses of the state of software
engineering are
• Highly unpredictable …only 10% of software project are
delivered successfully
• Management discipline is more of a discriminator
• The level of software scrap and rework is indicative of an
immature process

2. WaterFall
model
• The waterfall model is a linear, sequential approach
to the software development lifecycle (SDLC) that is
popular in software engineering and product
development.
• The waterfall model uses a logical progression of
SDLC steps for a project, similar to the direction
water flows over the edge of a cliff. It sets distinct
endpoints or goals for each phase of development.
Those endpoints or goals can't be revisited after
their completion.

3. WaterFall
model
The two basic steps to building a program or project-
• Analysis
• Coding
These two involve creative work that directly
contributes to the usefulness of end product.

4. 1.System Requirements
2.Software Requirement
3.Analysis
4.Program Design
5.Coding
6.Testing
7.Operations Or Maintain
The Large
Scale System
Approach for
SPD stages

5. DRAWBACKS
OF
WATERFALL
MODEL
• The Basic framework described in the waterfall
model is risky and invites failure, because the
testing phase occurs at the end of development
cycle.
• This is the first event for which timing ,storage
,input/output transfers are experienced as
distinguished from analyzed.
• If the result outcome is failure as per client needs.
• Either the requirements must be modified or
• Substantial change is warranted.

6. Five
Necessary
improvements
for this
approach to
work:
1. Program design comes first
Insert a preliminary program design phase between the
software requirements generation phase and the analysis
phase.
Advantages:
1.) By this technique, the program designer assures that
the software will not fail because of storage, timing, and
data flux (continuous change).
2.) As analysis proceeds in the succeeding phase, the program
designer must impose on the analyst the storage, timing, and
operational constraints in such a way that he senses the
consequences.
3.) If the total resources to be applied are insufficient or if the
embryonic(in an early stage of development) operational
design is wrong, it will be recognized at this early stage and
the iteration with requirements and preliminary design can be
redone before final design, coding, and test commences.

7. 2.Document The Design:
Document each step thoroughly.
Advantages-
• Easy communication among the team members.
• Support later modifications by a separate test team,
separate maintenance team and operations personnel
who are not software literates
3.Do It Twice:
Major problems and alternatives are addressed
Do it for N times approach
Finally Major requirements are implemented
Five
Necessary
improvements
for this
approach to
work:

8. 4.Plan ,Control, And Monitor Testing:
Why?
Required a lot of project resources (manpower, computing
time ) is the test phase
Greatest risk in terms of cost and schedule.
The previous 3 recommendations were all aimed at
uncovering and solving the problems before entering the
test phase
How?
1. Employ a team of test specialists who are not responsible
for the original design
2. Employ visual inspections to spot the obvious errors like
dropped minus sign, missing factors of two, jumps to
wrong addresses
3. Test every logic path
4. Employ the final checkout on the target computer
Five
Necessary
improvements
for this
approach to
work:

9. 5.Involve The Customer:
Involve customers in the project at all the earlier
points.
These include -
 ”Preliminary software review ” following the
preliminary program design step,
A sequence of ”critical software design reviews”
during program design
A final software acceptance review followed by
testing.
Advantages:
Their insight, judgement and commitment of the
customer can boost the development effort.
Five
Necessary
improvements
for this
approach to
work:

10. The software development plan :old version
• Define precise requirements
• Define precise plan to deliver system
constrained by specified time and budget
• Execute and track to plan
Initial project situation stakeholder satisfication
space
reused or legacy assets
Detalied plans ,scope
But:less than 20% of success rate

11. Water fall
model in
practice:
Projects following the conventional software
management process are-
 Not delivered on time
 Not within initial budget, and
 Rarely meet user requirements.

12. The 5 Major
Problems with
Conventional
Software
Management
Process.
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.

13. Expenditures By
Activity For A
Conventional
Software Project

14. 1. Protracted integration
and late design breakage
The diagram shows development progress
versus time. The following sequence of
issues is common in this phase;
• Early success via paper designs and
through briefings.
• Commitment to code late in life cycle.
• Integration difficulties due to unforeseen
implementation issues and interface
ambiguities.
• Heavy budget and schedule pressure to
get the system working.
• Late response of non-optimal fixes, with
no time for design.
• A very delicate, unmaintainable product
delivered late.

15. 1. Protracted integration
and late design breakage
• In conventional approach the use of
immature languages and technologies is
difficult to understand the software project
design and to change it in future.
• In conventional model the entire system
was designed on paper, and implemented all
at once, then integrated. Here we perform
system testing at the end of the process to
check the fundamental architecture is good
or not.

16. 2.Late risk resolution
A serious problem in waterfall model was
lack of early risk resolution.
The diagram shows risk profile for
conventional model projects covers four
distinct periods. They are –
• At the early stage risk is defined as
missing a cost, schedule, feature or
quality
• At this stage requirement being
specified so risk exposure was
unpredictable.

17. 2.Late risk resolution
• After the design concept was 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 begin the integration the real
system level risks are addressed.

18. Requirements driven
functional decomposition.
• The diagram shows the Suboptimal
software component organizations
resulting from a requirements driven
approach.
• Another issue in conventional process is
requirements are specified in functional
manner. In waterfall model
requirements are allocated to the
components.
• The decomposition is very difficult
based on object oriented design and
use of existing components.

19. The conventional process cause adversarial stakeholder
relationships, in large part because of the difficulties of
requirements specification and the exchange of information only
through paper documents and engineering information in adhoc
formats.
The following sequence of things happened in contractual
software development.
1.The contractor prepared a draft contract deliverable document
that captured an intermediate artifact and delivered it to the
customer for approval.
2.The customer as expected to provide comments.
3.The contractor incorporated these comments and submitted a
final version for approval.
4.This one shot review process is highly sensitive on the part of
customers and contractors. The exchanges of paper reviews are
intolerable.
3.Adversarial
stakeholder
relationships:

20. The conventional software development
process focuses on producing various
documents that attempt to describe the
software product.
Here formal meetings are 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.
Most review meetings has low engineering
values and high cost in terms of effort and
schedule involved in their preparation and
conduct.
5.Focus on
documents and
review meetings:

21. Results of
conventional
software
project design
reviews

22. Need For A
Modern
Software
Management
System
Diagnosing the five symptoms of projects
headed for trouble can be difficult,
especially in early phases of the life cycle
when problems with the conventional
approach would have been most easily
cured.
Consequently, modern software projects
must use mechanisms that assess project in
early life cycle phases and that continue with
objective, periodic checkup.