1

SOFTWARE DEVELOPMENT

2

SOFTWARE CRISES

3

1. Problems Faced By The Customers1. US Internal Revenue System has abandoned its tax system

modernization program after having spent $4 billion;2. the state of California spent $1 billion on its non-functional

welfare database system;3. the £339 million UK air traffic control system was reported as

being two years behind schedule;4. a discount stock brokerage company had 50 people working 14

hours or more a day to correct three months of records clerically – the report commented that the new system had been rushed into operation without adequate testing;

5. in the United Kingdom, a Home Office immigration service computerization project was reported as having missed two deadlines and was nine months late;

6. the Public Accounts Committee of the House of Commons (UK) blamed software bugs and management errors for £12 million of project costs in relation to an implementation of a Ministry of agriculture computer system to administer farm subsidies.

7. More ???

SOFTWARE PROJECT FAILURE

4

3. AN INDUSTRY PERSPECTIVE

2. GENERALH/W advances continue to outpace the pace of building S/W to tap hardware’s potential.

Why cost estimations are mostly incorrect?

Why requirements are kept changing

Why does it take so long to get programs finished?

Why are costs so high?

Why can’t we find all errors before we give the S/W to our customer?

Why do we have difficulty in measuring progress as S/W is being developed?

Our ability to build S/W could not keep pace with the growing need of business and market

Demand of highly reliable operations (ticketing, communication and power control) of S/W due to our dependency on computer

SOFTWARE CRISES

5

4. SOFTWARE COMPETITIVENESS

S/W is now an extremely competitive business. We cannot afford unlimited cost and time for poor quality software.

SOFTWARE CRISES

6

The statistics – Chaos Report

Project completion

16%

31%

53%

On time, on budget,with all of the specifiedfeatures and functions

Cancelled before theywere completed

delivered andoperational but over-budget, over-scheduleor with fewer featuresand functions thanspecified

Standish Group – 1995 365 IT executives in US

companies in diverse industry segments.

8,380 projects

average cost overrun = 189%

average time

overrun = 222%.

61% of originally specified features included

×

?

In Averages• 189% of original budget• 221% of original schedule• 61% of original functionality

7

Symptom of Software Crisis

About US$250 billions spent per year in the US on application development

Out of this, about US$140 billions wasted due to the projects getting abandoned or reworked; this in turn because of not following best practices and standards

Ref: Standish Group, 1996Ref: Standish Group, 1996

8

Symptom of Software Crisis

10% of client/server apps are abandoned or restarted from scratch

20% of apps are significantly altered to avoid disaster

40% of apps are delivered significantly late

Source: 3 year study of 70 large c/s apps 30 European firms. Source: 3 year study of 70 large c/s apps 30 European firms.

Compuware (12/95)Compuware (12/95)

9

Software products:– fail to meet user requirements– crash frequently– expensive– difficult to alter, debug, enhance– often delivered late– use resources non-optimally

Observed Problems

10

Why is the Statistics so Bad? Misconception on software development

– Software myths, e.g., the man-month myth– False assumptions– Not distinguishing the coding of a computer

program from the development of a software product

Software programs have exponential growth in complexity and difficulty level with respect to size.

– The ad hoc approach breaks down when size of software increases.

11

Why is the Statistics so Bad?...

Software professionals lack engineering training– Programmers have skills for programming

but without the engineering mindset about a process and discipline

How is Software usually Constructed …

The requirements specification was defined like this

The developers understood it in

that way

This is how the problem was solved before.

This is how the problem is solved now

That is the program after debugging

This is how the program is described by marketing dept.

This, in fact, is what the customer wanted … ;-)

13

Software Myths(Customer Perspectives)

A general statement of objectives is sufficient to get started with the development of software. Missing/vague requirements can easily be incorporated/detailed out as they get concretized.

Application requirements can never be stable; software can be and has to be made flexible enough to allow changes to be incorporated as they happen.

14

Software Myths(Developer Perspectives)

Once the software is demonstrated, the job is done.

Usually, the problems just begin!

15

Until the software is coded and is available for testing, there is no way for assessing its quality.

Usually, there are too many tiny bugs inserted at every stage that grow in size and complexity

as they progress thru further stages!

Software Myths(Developer Perspectives)

16

The only deliverable for a software development project is the tested code.

The code is only the externally visible component

of the entire software complement!

Software Myths(Developer Perspectives)

17

Software Myths (Management Perspectives)

As long as there are good standards and clear procedures in my company, I shouldn’t be too concerned.

But the proof of the pudding is in the eating;

not in the Recipe !

18

Software Myths (Management Perspectives)

As long as my software engineers(!) have access to the fastest and the most sophisticated computer environments and state-of-the-art software tools, I shouldn’t be too concerned.

The environment is only one of the several factors

that determine the quality of the end software product!

19

Software Myths (Management Perspectives)

When my schedule slips, what I have to do is to start a fire-fighting operation: add more software specialists, those with higher skills and longer experience - they will bring the schedule back on the rails!

Unfortunately, software business does not

entertain schedule compaction beyond a limit!

20

Misplaced Assumptions

All requirements can be pre-specified Users are experts at specification of their

needs Users and developers are both good at

visualization The project team is capable of

unambiguous communication

Ref: Larry VaughnRef: Larry Vaughn

21

Usually small in size

Author himself is sole user

Single developer

Lacks proper user interface

Lacks proper documentation

Ad hoc development.

Large

Large number of users

Team of developers

Well-designed interface

Well documented & user-manual prepared

Systematic development

Programs Software Products

Confused with Programs and Products

22

Software Programming ≠ Software Engineering

Software programming: the process of translating a problem from its physical environment into a language that a computer can understand and obey. (Webster’s New World Dictionary of Computer Terms)– Single developer

– “Toy” applications

– Short lifespan

– Single or few stakeholders• Architect = Developer = Manager = Tester = Customer = User

– One-of-a-kind systems

– Built from scratch

– Minimal maintenance

23

Software Programming ≠ Software Engineering

Software engineering– Teams of developers with multiple roles– Complex systems– Indefinite lifespan– Numerous stakeholders

• Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User

– System families– Reuse to amortize costs– Maintenance accounts for over 60% of overall

development costs

24

So, Software Engineering is … Scope

– study of software process, development principles, techniques, and notations

Goals

– production of quality software,

– delivered on time,

– within budget,

– satisfying customers’ requirements and users’ needs

25

The Role/Scope Of S/W Engineering In System Design• A software system is often a component of a much larger system.

• The software engineering activity is therefore a part of a much larger system design activity in which the requirements of the software are balanced against the requirements of other parts of the system being designed.*

• For Example, A requirement such as “the system must not be down for more than a second in 20 years” or “when a receiver is taken off-hook, a dial tone is played within half a second” can be satisfied with a combination of hardware, software and special devices.

• A trade off is required as what should be done in software and what should be done in hardware. Software implementation offers flexibility, while hardware implementation offers performance.$

• To do software engineering right, requires a broader look at the general problem of system engineering. It requires software engineer to be involved when requirements are being developed initially for the whole system.

26

• It requires that software engineer attempt to understand the application area rather than just what abstract interfaces the software must meet.

27

S/W CHARACTERISTICS

3.

Software is developed or engineered, it is not manufactured in the classical sense.

Software doesn’t wear out

Software is complex

Software is like an ‘aging factory’

Industry is moving towards component-based assembling, most software is custom built.

28

Wear vs. Deterioration

idealized curve

change

actual curve

Failurerate

Time

increased failurerate due to side effects

29

Software ApplicationsSystem software

Real-time softwareBusiness softwareEngineering/scientific softwareEmbedded softwarePC softwareAI softwareNetwork applicationsWeb applications