IN4MATX 43 Lecture Notes - Lecture 3: Failure Cause, Work Breakdown Structure, Tacit Knowledge
27 Apr 2018
School
Department
Course
Professor
IN4MATX – 36900 – Intro to Software Engineering
Week 2 – Lecture 3 – Software Failures
Software Failures
• Why did CA payroll system and DWP billing system upgrades fail?
• What is the real problem?
o Task was too complex
▪ The payroll system had to cover the 160 state departments, 40+
medical and dental plans, totaling to over $100 million in all
▪ The DWP failed because of it’s large base being 3.8 million
customers
▪ On a huge scale, and too difficult for one system to handle alone
• It had to conform to medical plans, tax laws, and other rules
etc., relating to conformity
• Very human things that the software had to get right
o The software had to conform to the realistic standards of payroll contracts,
as well as adhere to the laws and billing policies
o Progress on its own is difficult to measure
▪ The company had been working on it for a while, and it was hard to
judge how far they’d come
▪ The farther into it they go, the harder it is to realize
o The goal had been started in the 1970s
▪ Systems had been in place for so long
▪ Most people who were involved in the initial system are no longer
there
• There’s a loss of knowledge that is basically impossible to
get back
o Hubble Psychology
▪ In which they believed that as long as they hit certain milestones,
they’d keep earning money to finish the tasks later
▪ They believe that after all the issues and failures, it would be worth
it
• Failures being budget, schedule, bugs etc.
• Over-optimism that is a concept in which there’s a belief that
it would all be worth it
▪ Hubble telescope; it was something that there were schedule
changes, budgets blown, but they’d kept throwing money at it until it
worked out
• Some stats
o Also illustrative of a much bigger problem
o Five out of 10 projects deliver on project and on time
▪ Only half meet our budget and schedule goals
o When they go over their costs, it’s usually double
find more resources at oneclass.com
find more resources at oneclass.com
o About 34 percent of the projects are late
• More stats
o From CHAOS report
o 31% of projects are cancelled before completed
o Billions are wasted per year on cancelled, unused or unusable projects
o Up to 52/7% of the projects were more than 189% over the budget when
finally delivered
Some Requirements
• Shopa Failure
o ‘the company is still trying to figure out what product to build’
o Understanding the system and what the goals are is important before
actually starting
▪ Shopa failed even with their wide budget, millions of dollars
because nobody had taken the time or effort to establish what the
requirements and specifications were
• Reminder: Top Software Failure Causes
o Requirements issues
▪ Lack of user input/involvement
• Don’t understand what the user wants
▪ Incomplete requirements and specifications
• Haven’t taken time to figure it out
▪ Changing requirements and specifications
• Requirements are changing too much and you can’t keep
up; end up making something dated compared to what is
wanted
o Lack of rigor/formality (cutting corners)
▪ Lack of discipline in development process
▪ Lack of methodical usage of metrics
o Lack of resources (practical)
• Definition of requirements
o What the software should do (without saying how it should do it)
▪ Not how it should be implemented or designed
▪ What are it’s services and uses that the software should provide to
the user
• Why requirements?
o Studies show that project failures typically relate to requirements
• More stats
o From CHAOS reports
▪ 70% of the rework costs are attributed to requirement issues
▪ Lack of user input is listed as the most frequent problem
find more resources at oneclass.com
find more resources at oneclass.com
