01 intro+
TRANSCRIPT
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