1 CISH-6050 - Software Engineering Management Review Syllabus -Course Overview Introductions The Software Crisis -What is it? -How real is it? Review Syllabus

1 CISH-6050 - Software Engineering Management

• Review Syllabus- Course Overview

• Introductions

• The Software Crisis

- What is it?

- How real is it?

• Review Syllabus- Course Overview

• Introductions

• The Software Crisis

- What is it?

- How real is it?

AGENDAAGENDA


•Software Engineering Basics and Definitions- Software

Quality Development

- Software Engineering Software Process Framework Software Processes

•Software Engineering Basics and Definitions- Software

Quality Development

- Software Engineering Software Process Framework Software Processes

AGENDA …AGENDA …


- Software Engineering Management

•Software Process & Product Quality

- Software Engineering Management

•Software Process & Product Quality

AGENDA …AGENDA …


The Software CrisisThe Software Crisis

What is it?What is it?


Software Crisis ExamplesSoftware Crisis Examples

• IRS – Business Systems Modernization - $8B Upgrade– Launched in 1999

– CADE- 1st software release 3 years late & $36.8M over budget

– 8 other major projects missed deployment deadlines

– Cost Overruns > $200M

• IRS – Business Systems Modernization - $8B Upgrade– Launched in 1999

– CADE- 1st software release 3 years late & $36.8M over budget

– 8 other major projects missed deployment deadlines

– Cost Overruns > $200M


Software Crisis Examples …Software Crisis Examples …

IRS Project Status Past Due $ Overrun

E-Services 2004 Deployments

2 years $86M

Customer Account Data Engine (CADE)

1st release August, 2004

3 years $36.8

Integrated Financial System

Target October, 2004

1 year $50M

Modernized E-file Scheduled for Spring, 2004

4 months $17.1M

Custodial Accounting Project

First phase August, 2004

20 months $59.5M

Ongoing IRS Modernization Projects



IRS Project Status $ OverrunSecurity and Technology Infrastructure Release 1

5 months late $7.6M

Customer Communications 2001 9 months late $5.3M

Customer Relationship Management Exam

3 months late ($1.9M Under budget)

Human Resource Connect On time $200K

Internet Refund Fact of Filing 14 months late $12.9M

Completed IRS Modernization Projects



•Bank of America – MasterNet– Spent $23M on an initial 5 year

accounting & reporting system

– Spent $600M trying to make it work

– Project cancelled

– Lost customer accounts - $Billons

•Bank of America – MasterNet– Spent $23M on an initial 5 year

accounting & reporting system

– Spent $600M trying to make it work

– Project cancelled

– Lost customer accounts - $Billons



•Allstate Insurance – In 1982– $8M computer system to automate

business– EDS providing software – Initial 5 year project continued for 10

years, until 1993– Cost approached $100M

•Allstate Insurance – In 1982– $8M computer system to automate

business– EDS providing software – Initial 5 year project continued for 10

years, until 1993– Cost approached $100M



•Blue Cross and Blue Shield of Wisconsin - 1983– EDS hired to build $200M computer

system

– Delivered on time in 18 months

– System didn’t work – issued $60M in overpayments and duplicate checks

– BC lost 35,000 policy holders by 1987

•Blue Cross and Blue Shield of Wisconsin - 1983– EDS hired to build $200M computer

system

– Delivered on time in 18 months

– System didn’t work – issued $60M in overpayments and duplicate checks

– BC lost 35,000 policy holders by 1987


Software Crisis Examples …Software Crisis Examples …•Therac-25: 1985 - 1987

– Computerized radiation therapy machines made by Atomic Energy Canada Limited (AECL)

– Massive radiation overdoses by the Therac-25 between 6/85 and 1/87

– 4 deaths and serious injuries

– Original User Interface faulty, allowing techs to administer high dosages

•Therac-25: 1985 - 1987– Computerized radiation therapy

machines made by Atomic Energy Canada Limited (AECL)

– Massive radiation overdoses by the Therac-25 between 6/85 and 1/87

– 4 deaths and serious injuries

– Original User Interface faulty, allowing techs to administer high dosages



•Software development projects suffering from:– Cost overruns

– Schedule delays

– Reduced functional deliverables

– Potential project cancellation

•Software development projects suffering from:– Cost overruns

– Schedule delays

– Reduced functional deliverables

– Potential project cancellation


Software Crisis StatsSoftware Crisis Stats

•Standish Group ‘94 CHAOS Report: – The US spends $250B on IT projects

– 31.3% of projects will be cancelled before being completed

– 52.7% will cost 189% of original est.

– 78.4% of software projects deployed with at least 74.2% of features

– $140B in project waste

•Standish Group ‘94 CHAOS Report: – The US spends $250B on IT projects

– 31.3% of projects will be cancelled before being completed

– 52.7% will cost 189% of original est.

– 78.4% of software projects deployed with at least 74.2% of features

– $140B in project waste



How did it start? How did it start?


The Software Crisis HistoryThe Software Crisis History

•1950s and 1960s – Programs are procedures to run hardware– Procedural, sequential thought

process

– Assembler level coding languages

– Modules, interfaces, state machines, data abstractions, etc. not familiar concepts to most practitioners

•1950s and 1960s – Programs are procedures to run hardware– Procedural, sequential thought

process

– Assembler level coding languages

– Modules, interfaces, state machines, data abstractions, etc. not familiar concepts to most practitioners


The Software Crisis History …The Software Crisis History …

− Procedurally coded instructions led to subroutines and macros

– Monitor programs evolved that could invoke and provide services to other programs

– Late 1960s, Monitor programs evolved to operating systems

− Procedurally coded instructions led to subroutines and macros

– Monitor programs evolved that could invoke and provide services to other programs

– Late 1960s, Monitor programs evolved to operating systems



•Late 1960s – Operating Systems– Utility programs developed for

repeated data manipulation

– FORTRAN and COBOL

– Assembler programs with I/O devices called at machine lang level

– New subsystems - Databases to handle mass of data

•Late 1960s – Operating Systems– Utility programs developed for

repeated data manipulation

– FORTRAN and COBOL

– Assembler programs with I/O devices called at machine lang level

– New subsystems - Databases to handle mass of data



•1970s – Software Properties – Complex

Rapid growth in size of apps

− Error Prone Inherited ‘spaghetti’ code

− Labor-intensive Very few good development tools

•1970s – Software Properties – Complex

Rapid growth in size of apps

− Error Prone Inherited ‘spaghetti’ code

− Labor-intensive Very few good development tools



•Cost overruns become the norm − Software complex, labor intensive,

and high volume of errors

– More time needed than planned to develop code

•More focus needed– How software developed

– Process of developing software

•Cost overruns become the norm − Software complex, labor intensive,

and high volume of errors

– More time needed than planned to develop code

•More focus needed– How software developed

– Process of developing software



•1970s - concepts & practices developed to manage size and complexity− Lifecycle models

− Defect detection earlier in cycle

− Improved testing methodologies

− Design and code inspections

− Program proof of correctness

•1970s - concepts & practices developed to manage size and complexity− Lifecycle models

− Defect detection earlier in cycle

− Improved testing methodologies

− Design and code inspections

− Program proof of correctness



•Despite improvements from the 1970s to 1980s, investing in software development still viewed as “bottomless pit”− Highly error prone

− Labor-intensive

− Cost overruns

•Despite improvements from the 1970s to 1980s, investing in software development still viewed as “bottomless pit”− Highly error prone

− Labor-intensive

− Cost overruns


The Software Crisis History …The Software Crisis History …•Early 1980s – hardware costs decreased

•Software development & service dominating cost factor

•Led to shift in industry:− Defect Prevention

− Defect Removal

− Software Development Tools

•Early 1980s – hardware costs decreased

•Software development & service dominating cost factor

•Led to shift in industry:− Defect Prevention

− Defect Removal

− Software Development Tools


The Software Crisis – Why?The Software Crisis – Why?

“The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents."

- Nathaniel Borenstein

“The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents."

- Nathaniel Borenstein



•Why are late deliverables and poor quality tolerated?

•For other items:– Defects not tolerated – cars,

appliances, homes, etc.

– High quality expected

– Compensation for defects

– Contractual obligation

•Why are late deliverables and poor quality tolerated?

•For other items:– Defects not tolerated – cars,

appliances, homes, etc.

– High quality expected

– Compensation for defects

– Contractual obligation



•Arguments – Valid or Invalid?

– Software is an art form; planning and cost management will damage creativity.

– Defect-free software can’t be produced.

•Arguments – Valid or Invalid?

– Software is an art form; planning and cost management will damage creativity.

– Defect-free software can’t be produced.



•How long will this be tolerated?– Until someone does it better

– Until the defects cause damage

• If there are no improvements and customers don’t suffer intolerable pain, the market place could continue as it has

•How long will this be tolerated?– Until someone does it better

– Until the defects cause damage

• If there are no improvements and customers don’t suffer intolerable pain, the market place could continue as it has


The Software Crisis - ImprovingThe Software Crisis - Improving

•General public no longer shielded from computers or software:– Critical component in products

Brakes cars, flies planes, manages financial transactions, runs machinery, etc.

– General public more intolerant of software flaws

•General public no longer shielded from computers or software:– Critical component in products

Brakes cars, flies planes, manages financial transactions, runs machinery, etc.

– General public more intolerant of software flaws



• Is the Software Crisis real?– Really a crisis?

– Or, a chronic affliction causing pain?

•Did (or will) it escalate as originally predicted?

• If it’s improving, is it over now?

• Is the Software Crisis real?– Really a crisis?

– Or, a chronic affliction causing pain?

•Did (or will) it escalate as originally predicted?

• If it’s improving, is it over now?



•Robert Glass, author of a number of books on software failures:

"I look at my failure stories and see exception reporting, spectacular failures in the midst of many successes, a cup that is nearly full."

•Robert Glass, author of a number of books on software failures:

"I look at my failure stories and see exception reporting, spectacular failures in the midst of many successes, a cup that is nearly full."



•March, 2004 CHAOS Chronicles Report shows big improvements:– Project success rate increased to 34%

(1994: 16% success rate)

– Project failures rate declined to 15% (1994: 31% failure rate)

– Challenged projects account for remaining 51%

•March, 2004 CHAOS Chronicles Report shows big improvements:– Project success rate increased to 34%

(1994: 16% success rate)

– Project failures rate declined to 15% (1994: 31% failure rate)

– Challenged projects account for remaining 51%



– 51% of challenged projects have a lower overrun ratio than in 2000

– 43% average cost overrun

(1994: 180% cost overrun)

– $55B spent on project waste

(1994: $140B project waste) $17B cost overruns (1994: $59B) $38B lost projects (1994: $81B)

– 51% of challenged projects have a lower overrun ratio than in 2000

– 43% average cost overrun

(1994: 180% cost overrun)

– $55B spent on project waste

(1994: $140B project waste) $17B cost overruns (1994: $59B) $38B lost projects (1994: $81B)



•Not all good news:– Time overruns increased to 82%

(2000: 63% time overruns)

− 52% of required features/functions make it in released product

(2000: 67% features in final product)


•Not all good news:– Time overruns increased to 82%

(2000: 63% time overruns)

− 52% of required features/functions make it in released product





•Software Engineering and Software Engineering Management are a continued effort against the Software Crisis

•Software and Software Engineering Basics

•Software Engineering and Software Engineering Management are a continued effort against the Software Crisis

•Software and Software Engineering Basics


Software Fundamentals Software Fundamentals

•What is Software? (Pressman)– Instructions that when executed

perform desired function

– Data structures that enable programs to adequately manipulate information

– Documents that describe the operation and use of programs

•What is Software? (Pressman)– Instructions that when executed

perform desired function

– Data structures that enable programs to adequately manipulate information

– Documents that describe the operation and use of programs


Software Characteristics Software Characteristics •Developed or Engineered – not “manufactured”– Software is logical system element

– Software projects managed differently than manufacturing projects

•Software doesn’t physically wear out like hardware might

•Most software custom built

•Developed or Engineered – not “manufactured”– Software is logical system element

– Software projects managed differently than manufacturing projects

•Software doesn’t physically wear out like hardware might

•Most software custom built


Software Software •Many Types

– Systems, Real Time, Business, Scientific, Embedded, PC, Web, AI

•Products– Generic or Packaged (COTS)

– Custom Built

•Sources– Open (shareware)– Closed (Proprietary)

•Many Types– Systems, Real Time, Business,

Scientific, Embedded, PC, Web, AI

•Products– Generic or Packaged (COTS)

– Custom Built

•Sources– Open (shareware)– Closed (Proprietary)


Software Quality Software Quality

– Functionality

– Reliability and Dependability

– Maintainability

– Functionality

– Reliability and Dependability

– Maintainability

– Usability

– Portability

– Learnability

– Efficiency

– Security

– Usability

– Portability

– Learnability

– Efficiency

– Security

Expect software to contain sufficient:


Software Quality …Software Quality …•Some attributes are exclusive and difficult to optimize– Relationship of cost to improving each

attribute

– Cost vs. efficiency

•Some attributes are exclusive and difficult to optimize– Relationship of cost to improving each

attribute

– Cost vs. efficiency

Efficiency

Cost


Software Development Software Development

1.Understand problem (Requirements)

2. Identify possible solutions (Design)

3. Implement solution (Develop - code)

4.Ensure solution solves problem (Test)

5.Ensure solution continues to solve problem (Lifecycle Management)

1.Understand problem (Requirements)

2. Identify possible solutions (Design)

3. Implement solution (Develop - code)

4.Ensure solution solves problem (Test)

5.Ensure solution continues to solve problem (Lifecycle Management)

Basic Development Activities


Myth vs. RealityMyth vs. Reality

•Myth #1– General statement of objectives is

sufficient to begin writing programs; the details can be filled in later.

•Reality #1– Poor definition up front is major cause of

failed software efforts.

•Myth #1– General statement of objectives is

sufficient to begin writing programs; the details can be filled in later.

•Reality #1– Poor definition up front is major cause of

failed software efforts.


Myth vs. Reality …Myth vs. Reality …

•Myth #2– Project requirements continue to

change, but can be easily accommodated – software is flexible.

•Reality #2– Impact of change varies with the

phase it was introduced – Requirements, Design, Code, Test

•Myth #2– Project requirements continue to

change, but can be easily accommodated – software is flexible.

•Reality #2– Impact of change varies with the

phase it was introduced – Requirements, Design, Code, Test


Myth vs. Reality …Myth vs. Reality …•Myth #3

– Once we write the program and get it to work, our job is done.

•Reality #3– The sooner you begin writing code,

the longer it will take to get done.

– 60%-80% of all effort expended after delivered to customer for first time.

•Myth #3– Once we write the program and get it

to work, our job is done.

•Reality #3– The sooner you begin writing code,

the longer it will take to get done.

– 60%-80% of all effort expended after delivered to customer for first time.


Myth vs. Reality …Myth vs. Reality …

•Myth #4– Until the program is running, there’s

no way to assess its quality.

•Reality #4– SQA – Formal technical reviews can

be applied from the start of the project.

•Myth #4– Until the program is running, there’s

no way to assess its quality.

•Reality #4– SQA – Formal technical reviews can

be applied from the start of the project.


What is Software Engineering?What is Software Engineering?

•Fritz Bauer (Naur, 1969)– "The establishment and use of sound

engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.“

•Problems with this definition?

•Fritz Bauer (Naur, 1969)– "The establishment and use of sound

engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.“



Software Engineering …Software Engineering …

•Sommerville (1995)– "Software engineering is concerned

with the theories, methods, and tools which are needed to develop the software for these computers.“


•Sommerville (1995)– "Software engineering is concerned

with the theories, methods, and tools which are needed to develop the software for these computers.“



Software Engineering …Software Engineering …

• IEEE (IEE93)– " (1) The application of a systematic,

disciplined, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1).”

•Problem with this definition?

• IEEE (IEE93)– " (1) The application of a systematic,

disciplined, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1).”

•Problem with this definition?


Software Engineering …Software Engineering …•H. Younessi (SE 1)

– "Software Engineering is the collective term applied to attempts to produce high quality, complex, and large software on a largely methodical and reasonably sustainable basis with an increasingly scientific and quantitative orientation.”

•Scientific, Quantitative & Quality

•H. Younessi (SE 1)– "Software Engineering is the collective

term applied to attempts to produce high quality, complex, and large software on a largely methodical and reasonably sustainable basis with an increasingly scientific and quantitative orientation.”

•Scientific, Quantitative & Quality


Software Engineering ProcessSoftware Engineering Process

•Principle Elements of SEP:1.Methodology

2.People and Organizational Influences

3.Technology

•SEP – A mix of an instance of a methodology, conducted within an organizational content, utilizing a specific set of technologies

•Principle Elements of SEP:1.Methodology

2.People and Organizational Influences

3.Technology

•SEP – A mix of an instance of a methodology, conducted within an organizational content, utilizing a specific set of technologies


Software Process FrameworkSoftware Process Framework

•Define Framework as a method or approach to do something

– Example: Follow recipe to cook a meal

•Software Process sometimes inaccurately called a method or methodology

•Define Framework as a method or approach to do something

– Example: Follow recipe to cook a meal

•Software Process sometimes inaccurately called a method or methodology


Software Process Framework …Software Process Framework …

• Is a Software Engineering Process– The process of developing a piece of

code (i.e. using OO methodology)

– Or, is it the process of getting through a software development project (i.e. start to finish)?

•Different levels of “Process” granularity

• Is a Software Engineering Process– The process of developing a piece of

code (i.e. using OO methodology)

– Or, is it the process of getting through a software development project (i.e. start to finish)?

•Different levels of “Process” granularity



•Lower Level– Describes steps to complete a task

– Methods by which work is done

•Higher Level– By definition, process contains a

methodology component, as well as organizational and technology component

•Lower Level– Describes steps to complete a task

– Methods by which work is done

•Higher Level– By definition, process contains a

methodology component, as well as organizational and technology component



•Characteristics of Process Framework:

– Understandable

– Enactable (instantitable)

– Repeatable

– Definable (well defined)

– Manageable (well managed)

– Improvable

•Characteristics of Process Framework:

– Understandable

– Enactable (instantitable)

– Repeatable

– Definable (well defined)

– Manageable (well managed)

– Improvable



•Development Models used in Process Framework:

– Waterfall

– V-Model

– Spiral

– Evolutionary

– Rational Unified Process (RUP)

– OPEN

•Development Models used in Process Framework:

– Waterfall

– V-Model

– Spiral

– Evolutionary

– Rational Unified Process (RUP)

– OPEN



•Software Process should provide:– Functionality - appropriateness of use

– Usability

– Clarity of definition

•Software Process (& Framework that yielded it) should reflect:

– Methodology, Organization, Technology

•Software Process should provide:– Functionality - appropriateness of use

– Usability

– Clarity of definition

•Software Process (& Framework that yielded it) should reflect:

– Methodology, Organization, Technology



•Myth #1– We already have a book full of

standards & procedures for building software, won't that provide everything that my developers need to know?

•Reality #1– Is the book used? Are developers

aware of it? Does it reflect current SE standards?

•Myth #1– We already have a book full of

standards & procedures for building software, won't that provide everything that my developers need to know?

•Reality #1– Is the book used? Are developers

aware of it? Does it reflect current SE standards?



•Myth #2– People have state-of-the-art software

development tools, since we buy them the newest computers.

•Reality #2– It takes more than the latest model

mainframe, PC, or workstation to do high-quality software development – CASE tools.

•Myth #2– People have state-of-the-art software

development tools, since we buy them the newest computers.

•Reality #2– It takes more than the latest model

mainframe, PC, or workstation to do high-quality software development – CASE tools.



•Myth #3– Software Engineering will cause us to

create large amounts of unnecessary documentation and will slow us down.

•Reality #3– Software Engineering is not about

creating documents. It’s about creating quality. Better quality leads to reduced rework, resulting in faster delivery times.

•Myth #3– Software Engineering will cause us to

create large amounts of unnecessary documentation and will slow us down.

•Reality #3– Software Engineering is not about

creating documents. It’s about creating quality. Better quality leads to reduced rework, resulting in faster delivery times.



•Myth #4– If we get behind schedule, we can add

more programmers and catch up

•Reality #4– Software development is not a

mechanistic process like manufacturing. In the words of Brooks: "adding people to a late software project makes it later."

•Myth #4– If we get behind schedule, we can add

more programmers and catch up

•Reality #4– Software development is not a

mechanistic process like manufacturing. In the words of Brooks: "adding people to a late software project makes it later."


Software Engineering Management

Software Engineering Management

Why do Software Engineering Management?

Why do Software Engineering Management?


Software Engineering Management …


• SE subject to budget and schedule constraints

• Project Management ensures software development done according to organization’s constraints: policies, goals, and requirements

• SE subject to budget and schedule constraints

• Project Management ensures software development done according to organization’s constraints: policies, goals, and requirements




Balance Schedule, Cost, ProductBalance Schedule, Cost, Product

Cost

Schedule Product


Software Engineering Mgmt …Software Engineering Mgmt …

•Software Engineering Management differs from other types of engineering management– Intangible product

– No standard process

– Large software projects often ‘one-off’ projects

•Software Engineering Management differs from other types of engineering management– Intangible product

– No standard process

– Large software projects often ‘one-off’ projects



•Software Engineering Management Fundamentals– Determine size of product

– Allocate resource for the product

– Create plan for utilizing resource

– Monitor project

– Measure project

•Software Engineering Management Fundamentals– Determine size of product

– Allocate resource for the product

– Create plan for utilizing resource

– Monitor project

– Measure project



•Effective Software Project Management: 4 P’s– People

– Product

– Process

– Project

•Effective Software Project Management: 4 P’s– People

– Product

– Process

– Project


RecapRecap•The Software Crisis

•Software– Quality

– Development

•Software Engineering– Software Process Framework

– Software Processes

•Software Engineering Management

•The Software Crisis

•Software– Quality

– Development

•Software Engineering– Software Process Framework

– Software Processes

•Software Engineering Management


ReferencesReferences• R. S. Pressman, Software Engineering: A

Practitioner's Approach, 5th ed., McGraw-Hill, New York, 2001

• I. Sommerville, Software Engineering, 5th ed., Addison-Wesley, Reading, MA, 1995

• R. Radice, R. Phillips, Software Engineering: An Industrial Approach, Prentice Hall, Englewood Cliffs, NJ, 1988

• P. G. Neumann, Computer Related Risks, Addison-Wesley, Reading, MA, January, 1995

• R. S. Pressman, Software Engineering: A Practitioner's Approach, 5th ed., McGraw-Hill, New York, 2001

• I. Sommerville, Software Engineering, 5th ed., Addison-Wesley, Reading, MA, 1995

• R. Radice, R. Phillips, Software Engineering: An Industrial Approach, Prentice Hall, Englewood Cliffs, NJ, 1988

• P. G. Neumann, Computer Related Risks, Addison-Wesley, Reading, MA, January, 1995


References …References …• R. L. Glass, Software Runaways, Prentice Hall

PTF, Upper Saddle River, NJ, 1998• N. G. Leveson, C. S. Turner, "An Investigation of

the Therac-25 Accidents," IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41

• W. S. Humphrey, "The Changing World of Software", Software Engineering Institute, Carnegie Mellon University, December, 2001. Available at http://www.sei.cmu.edu/publications/articles/watts-humphrey/changing-world-sw.html

• R. L. Glass, Software Runaways, Prentice Hall PTF, Upper Saddle River, NJ, 1998

• N. G. Leveson, C. S. Turner, "An Investigation of the Therac-25 Accidents," IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41

• W. S. Humphrey, "The Changing World of Software", Software Engineering Institute, Carnegie Mellon University, December, 2001. Available at http://www.sei.cmu.edu/publications/articles/watts-humphrey/changing-world-sw.html


References …References …

• H. Younessi, B. Henderson-Sellers, "Cooking up Improved Software Quality: Developing reliable and usable critical information systems with processes", Object Development, October 1997, pp. 38-42

• S. McConnell, Rapid Development: Taming Wild Software Schedules, Microsoft Press, Redmond, Washington, 1996

• H. Younessi, B. Henderson-Sellers, "Cooking up Improved Software Quality: Developing reliable and usable critical information systems with processes", Object Development, October 1997, pp. 38-42

• S. McConnell, Rapid Development: Taming Wild Software Schedules, Microsoft Press, Redmond, Washington, 1996


References …References …• The Standish Group, “The CHAOS Report

(1994)”. Available at http://www.standishgroup.com/sample_research/chaos_1994_1.php

• The Standish Group, “Latest Standish Group CHAOS Report Shows Project Success Rates Have Improved by 50%”, March 25, 2003. Available at http://www.standishgroup.com/press/article.php?id=2

• The Standish Group, “The CHAOS Report (1994)”. Available at http://www.standishgroup.com/sample_research/chaos_1994_1.php

• The Standish Group, “Latest Standish Group CHAOS Report Shows Project Success Rates Have Improved by 50%”, March 25, 2003. Available at http://www.standishgroup.com/press/article.php?id=2


References …References …• E. Varon, “For the IRS There’s No EZ Fix”, CIO

Magazine, Vol. 17, No. 12, April 1 2004, pp. 50-56. Also available at http://www.cio.com/archive/040104/irs.html

• E. Varon, “For the IRS There’s No EZ Fix”, CIO Magazine, Vol. 17, No. 12, April 1 2004, pp. 50-56. Also available at http://www.cio.com/archive/040104/irs.html