Software Management

Software Crisis

Mid 1990’s - analysis of the state of the software engineering industry

Result : Success rate of the projects is very low.
 Conventional Software Management.
The Waterfall Model.
Conventional Software Management Performance.

Conventional software management

techniques work well for custom-developed
software where the requirements are fixed
when development begins.

The life cycle typically follows a sequential

transition from requirements to design to code
to testing, with ad hoc documentation that
attempts to
capture complete intermediate representations
at every stage.
After coding and unit testing of individual
components, the components are compiled
and linked together (integrated) into a
complete system.
 Waterfall Model
The waterfall model of conventional software management, which is still
prevalent in many mature software organizations, has served its purpose.
The ever-increasing market demands on software development
performance continue. The increasing breadth of Internet applications has
further accelerated the transition to a more modern management process
known as spiral, incremental, evolutionary, or iterative development.
A comparison of conventional and modern software development
models illustrates some of the critical discriminators in this transition.

The waterfall model is a sequential software development process, in

which progress is seen as flowing steadily downwards (like a
waterfall) through the phases of Conception, Initiation, Analysis,
Design (validation), Construction, Testing and maintenance.

To follow the waterfall model, one proceeds from one phase to the next
in a purely sequential manner.
The waterfall model is a popular version of
the systems development life cycle model
for software engineering. Often considered
the classic approach to the systems
development life cycle, the waterfall
model describes a development method
that is linear and sequential. Waterfall
development has distinct goals for each
phase of development. Imagine a waterfall
on the cliff of a steep mountain. Once the
water has flowed over the edge of the cliff
and has begun its journey down the side of
the mountain, it cannot turn back. It is the
same with waterfall development. Once a
phase of development is completed, the
development proceeds to the next phase
and there is no turning back.
The advantage of waterfall development is that it
allows for departmentalization and managerial
control. A schedule can be set with deadlines for
each stage of development and a product can
proceed through the development process like a
car in a carwash, and theoretically, be delivered
on time. Development moves from concept,
through design, implementation, testing,
installation, troubleshooting, and ends up at
operation and maintenance. Each phase of
development proceeds in strict order, without any
overlapping or iterative steps.

The disadvantage of waterfall development is that

it does not allow for much reflection or revision.
Once an application is in the testing stage, it is
very difficult to go back and change something
that was not well-thought out in the concept stage.
Alternatives to the waterfall model include joint
application development (JAD), rapid application
development (RAD), synch and stabilize, build
and fix, and the spiral model.
The Rational Unified Process

Life cycle has four phases:

Inception: definition and assessment of
the vision and business case
Elaboration: synthesis, demonstration,
and assessment of an architecture
baseline
Construction: development,
demonstration, and assessment of useful
increments
Transition: usability assessment,
productization, and deployment
 Improving Software Economics.

•Reducing Software Product Size.

•Languages.
•Object-Oriented Methods and Visual Modeling.
•Reuse.
•Commercial Components.
•Improving Software Processes.
•Improving Team Effectiveness.
•Improving Automation through Software Environments.
•Achieving Required Quality.
•Peer Inspections: A Pragmatic View.
 Software Economics
Five fundamental parameters that can be abstracted from software costing
models:
•Size
•Process
•Personnel
•Environment
•Required Quality

Size: Usually measured in SLOC or number of Function Points required to

realize the desired capabilities.
Process – used to guide all activities.
Personnel – capabilities of the personnel in general and in the application
domain in particular
Environment – the tools / techniques / automated procedures used to support
the development effort.
Required Quality – the functionality provided; performance, reliability,
maintainability, scalability, portability, user interface utility; usability…
Effort = (personnel)(environment)(quality)(size)
 Cost Model Parameters
Size
Abstraction and component-based
development technologies
• Higher Order Languages (C++, Java, VB,
• OO (analysis, design, programming)
• Reuse
• Commercial Components

Process
Methods and techniques
• Iterative Development
• Process Maturity Models
• Architecture-first development
• Acquisition reform

Personnel
People factors
• Training and personnel skill development
• Teamwork
• Win-win cultures
 Cost Model Parameters

Environment
Automation technologies and tools
• Integrated tools (visual modeling, compiler, editors, debuggers, CMS, ….
• Open Systems
• Hardware platform performance
• Automation of coding, documents, testing, analyses

Quality
Performance, reliability, accuracy
• Hardware platform performance
• Demonstration-based assessment
• Statistical quality control
 Generations of Software Development
Conventional
 1960’s - 1970’s (Craftsmanship)
 Waterfall Model
 Functional Design
 Custom Tools
 Custom Process
 Primitive Language
 Environments
 Custom
 Size
 100% Custom
 Process
 Ad hoc
 Issues
 Over Budget
 Over Schedule
 Predictably Bad
 Generations of Software Development

Transition
 1980’s – 1990’s (Software Engineering)
 Process Improvement
 Environments
 Off-the-shelf
 Separate
 Encapsulation
 Size
 70% Customised Components
 30% Components
 Process
 Repeatable
 Issues
 Addressing the complexity of the Distributed Environment
 Infrequently On Budget, On Schedule
 Unpredictable
 Generations of Software Development

Modern Practices
 2000 Later (Software Production)
 Iterative Development
 Component Based
 Environments
 Off the Shelf
 Integrated
 Process
 Managed / Measured
 Return on Investment
 Size
 70% Pre-built Components
 30% Customised Solutions
 Usually On budget, On Schedule
 Predictable
 Improving Software Economics
Key is a ‘balanced’ approach; patient
Five Key Initiatives – In Order:
Reducing the size and/or complexity of application
Improving the development process itself
Using more-skilled personnel and creation of better teams
Creating better ‘environments’ with appropriate tools and technology to
foster improvement
Re-looking at Quality
Reducing Software Product Size
The larger the product, the more expensive it is ‘per line.’ Fact.
Complicated due to
Component-based development
Automatic code generation
“Instruction Explosion”
GUI builders
4GLs
Modeling Languages
Executable code size often increases!

Integration costs for reusable

software components are significant,
but predictable. This article discusses
the major reuse cost impacts and
describes a rational method for
projecting cost and schedule for
software developments that
incorporate reusable and COTS
software components.
Reducing Software Product Size
A.Languages
•Function Point metrics
•SLOC metrics
•Level of abstraction and functionality
•Reducing size changes ‘level of abstraction’ allowing us to focus on
architecture, …  easier to understand, reuse, maintain. (may import
packages of classes and objects…)

B.OO Methods and Visual Modeling

•Assertions abound re benefits of OO methods on productivity and
quality

C.Reuse
•Always had ‘reuse’ with stored functions/subpgms
•Differences in platforms / environments has hurt reuse potential

D.Commercial Components
• quality, cost ,supportability, and the architecture.
Improving Software Processes
 Objective: minimize overhead and direct these energies toward production
activities.

Three generic improvement scenarios:

•Improve efficiency of each step in
process

•Eliminate some steps in the

process

•Undertake the same number of

steps, but employ concurrency
where possible
Software economics is the study of how scarce project resources are allocated for
software projects. Software economics helps software managers allocate those
resources in the most efficient manner. The process of counting function points,
gathering data, analyzing data is commonly referred to as Software Metrics, but in
reality is a branch of economics which should be called Software Economics
Increasing Marginal Cost
As the size of a software project the unit cost (or average cost) rises. In other words
software has increasing marginal costs and there are few economies of scale when
developing a software application. Any large engineering or construction project
follows this same economic model.

Hours per function point (average costs) go up as project and organizational size
increase.
Diseconomies of Scale
In all software projects there are some basic principles which cause diseconomies of
scale. That is:
There are low fixed costs relative to variable costs
Communication becomes difficult as project becomes larger
Multiple logical paths grow in a nonlinear manner as size increases
Interrelationships of functions grow geometrically as project becomes large.
Pragmatic Software Cost Estimation

Algorithmic Model
Expert Judgment
Analogy
Parkinson & Price to Win
Top-Down
Bottom-Up

A Good Estimate :
•It is conceived and supported by the project manager, architecture
team, development team, and test team accountable for performing the
work
•It is accepted by all stakeholders as ambitious
•It is base on a well-defined software cost model with a credible basis
•It is based on a database of relevant project experience that includes
similar processes, similar technologies, similar environments, similar
quality requirements, and similar people
•It is defined in enough detail so that its key risk areas are understood
and the probability of success is objectively assessed
The Old Way and the New.
The Principles of Conventional Software Engineering.
The Principles of Modern Software Management.
Transitioning to an Iterative Process.

Unit III
 Davis Top 30 Principals
1. Make Quality #1

2. High-Quality Software is Possible

3. Give Products to Customers Early

4. Determine the Problem before writing the Requirements

5. Evaluate design alternatives

6. Use an Appropriate Process Model

7. Use Different Languages for Different Phases

8. Minimize the Intellectual distance

9. Put techniques before tools

10.Get it right before you make it faster

Unit III
 Davis Top 30 Principals
11.Inspect Code

12.Good Management is more important than good technology

13.People are key to success

14.Follow with care

15.Take responsibility

16.Understand the customer’s priorities

17.The more they see the more they need

18.Plan to throw one way

19.Design for change

20.Design without documentation is not design

Unit III
 Davis Top 30 Principals
21.Use tools but be realistic

22.Avoid tricks

23.Encapsulate

24.Use coupling and cohesion

25.Use the McCabe complexity measure

26.Don’t test your own software

27.Analyze causes for errors

28.Realize that software’s entropy increases

29.People and time are not interchangeable

30.Expect excellence

Unit III
 Top 10 Principles of Modern Software Management

1.Base the process on an architecture-first approach,

2.Establish an iterative life-cycle 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,
 Top 10 Principles of Modern Software Management

6. Capture design artifacts 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 an economically-scalable, configurable process.
Principles of Conventional Software Management

1.Freeze requirements before design.

2.Forbid coding before detailed design review.

3.Use a higher-order programming language.

4.Complete unit testing before integration.

5.Maintain detailed traceability among all artifacts.

6.Thoroughly document each stage of the design.

7.Assess quality with an independent team.

8.Inspect everything.

9.Plan everything early with high fidelity.

10.Rigorously control source-code baselines.

Modern Process Approach for solving Conventional Problems

Conventional Process
Late Breakage and excessive scrap / rework

Impact
Quality, Cost, Schedule

Modern Process
•Architecture First Approach
•Iterative Development
•Automated Change Management
•Risk- confronting process