2 Software Development and the Software Crisis Modified

2 - Software Development and the Software Crisis [Modified version of Stellman and Greene’s Chapter 1 slides. Adapted to be used in the CSCD 306 course 2014]

Software Development Activities Requirements Collection Establish customer’s needs Analysis Model and specify the requirements (“what”) Design Model and specify a solution (“how”) Implementation Construct a solution in software Testing Validate the solution against the requirements Maintenance Repair defects and adapt the solution to new requirements NB: these are ongoing activities, not sequential phases!

Requirements Collection User requirements are often expressed informally: – features – usage scenarios Although requirements may be documented in written form, they may be incomplete, ambiguous, or even incorrect.

Changing requirements Requirements will change! – inadequately captured or expressed in the first place – user and business needs may change during the project Validation is needed throughout the software lifecycle, not only when the “final system” is delivered! – build constant feedback into your project plan – plan for change – early prototyping can help clarify requirements

Requirements Analysis and Specification Analysis is the process of specifying what a system will do. – The intention is to provide a clear understanding of what the system is about and what its underlying concepts are. The result of analysis is a specification Does the requirements document. specification correspond to the users’ actual needs?

Object-Oriented Analysis An object-oriented analysis results in models of the system which describe: • classes of objects that exist in the system – responsibilities of those classes • relationships between those classes • use cases and scenarios describing – operations that can be performed on the system – allowable sequences of those operations

Prototyping (I) A prototype is a software program developed to test, explore or validate a hypothesis, i. e. to reduce risks. An exploratory prototype, also known as a throwaway prototype, is intended to validate requirements or explore design choices. – UI prototype — validate user requirements – rapid prototype — validate functional requirements – experimental prototype — validate technical feasibility

Prototyping (II) An evolutionary prototype is intended to evolve in steps into a finished product. • iteratively “grow” the application, redesigning and refactoring along the way First do it, then do it right, then do it fast.

Design is the process of specifying how the specified system behaviour will be realized from software components. The results are architecture and detailed design documents. Object-oriented design delivers models that describe: – how system operations are implemented by interacting objects – how classes refer to one another and how they are related by inheritance – attributes and operations associated to classes

Implementation and Testing Implementation is the activity of constructing a software solution to the customer’s requirements. Testing is the process of validating that the solution meets the requirements. – The result of implementation and testing is a fully documented and validated solution.

Design, Implementation and Testing Design, implementation and testing are iterative activities • System tests reflect the requirements specification • Testing and implementation go handin-hand – Ideally, test case specification precedes design and implementation

Maintenance is the process of changing a system after it has been deployed. • Corrective maintenance: identifying and repairing defects • Adaptive maintenance: adapting the existing solution to new platforms • Perfective maintenance: implementing new requirements

Maintenance activities “Maintenance” entails: • configuration and version management • reengineering (redesigning and refactoring) • updating all analysis, design and user documentation

Maintenance costs “Maintenance” typically accounts for 70% of software costs! Means: most project costs concern continued development after deployment – Lientz 1979 © Oscar ESE — Introduction ESE 1. 14

Software Process • A process is a collection of activities, actions and tasks that are performed when some work product is to be created. It is not a rigid prescription for how to build computer software. Rather, it is an adaptable approach that enables the people doing the work to pick and choose the appropriate set of work actions and tasks. • Purpose of process is to deliver software in a timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who will use it. 15

Activities of a Generic Process Ian Sommerville redefined the software development activities as follows: • Communication: communicate with customer to understand objectives and gather requirements • Planning: creates a “map” defines the work by describing the tasks, risks and resources, work products and work schedule. • Modeling: Create a “sketch”, what it looks like architecturally, how the constituent parts fit together and other characteristics. • Construction: code generation and the testing. • Deployment: Delivered to the customer who evaluates the products and provides feedback based on the evaluation. • These five activities can be used to all software development regardless of the application domain, size of the project, complexity of the efforts etc, though the details will be different in each case. 16

The Waterfall Model 17

Waterfall Model Unidirectional, no way back finish this step before moving to the next 18

The Software Crisis What is it? 19 CISH-6050 - Software Engineering Management

3 of 500 Sw projects Succeed • Letters to the Editor ("The Times"), August 19, 2002, No easy task to start IT projects – From Professor Martyn Thomas, • • Sir, Your leading article (August 14) rightly focuses attention on the unacceptable rate of failure of IT projects, although contrary to what you suggest the problems are not necessarily worse in the public sector. A survey of 1, 027, mainly private sector, IT projects published in the 2001 British Computer Society Review showed that only 130 (12. 7 per cent) succeeded. • Software development projects were worst: of more than 500 projects surveyed, only three were regarded as having succeeded • As you report (Business, August 14) the problems are similar in the US. I have audited many software projects in both public and private sector organisations and in my experience the many and complex reasons for failures boil down to this : – most customers and most suppliers fail to recognise that complex software development is an engineering task.

3 of 500 Sw projects Succeed • Every step needs engineering rigour, based on sound computer science and supported by formal quality control. – Companies who work this way produce software much closer to their planned timescales and at lower cost. – Their customers are asked detailed questions to fix the requirements early in the project, and every subsequent change can be quickly analysed to see what it will cost, in money and time. – Their software contains so few errors that maintenance costs are negligible. • Most of the worldwide software industry treats software development as a craft that requires only technician-level skills. – Until that changes, projects will continue to suffer massive delays and cost overruns. • Regards, MARTYN THOMAS, Visiting Professor of Software Engineering, Oxford University Computing Laboratory, The Wolfson Building, Park Road, Oxford OX 1 3 QD. August 14, 2002, martyn@thomas-associates. co. uk 21 CISH-6050 - Software Engineering Management

Software Crisis Examples • IRS – Business Systems Modernization - $8 B Upgrade – Launched in 1999 – 1 st software release 3 years late & $36. 8 M over budget – 8 other major projects missed deployment deadlines – Cost Overruns > $200 M 22 CISH-6050 - Software Engineering Management

Software Crisis Examples … Ongoing IRS Modernization Projects IRS Project Status E-Services 2004 Deployments 2 years $86 M Customer Account 1 st release Data Engine (CADE) August, 2004 3 years $36. 8 Integrated Financial Target System October, 2004 1 year $50 M Scheduled for Spring, 2004 4 months $17. 1 M Custodial First phase Accounting Project August, 2004 20 months $59. 5 M Modernized E-file 23 Past Due $ Overrun CISH-6050 - Software Engineering Management

Software Crisis Examples … Completed IRS Modernization Projects IRS Project Status $ Overrun Security and Technology Infrastructure Release 1 5 months late $7. 6 M Customer Communications 2001 9 months late $5. 3 M Customer Relationship Management Exam 3 months late ($1. 9 M Under budget) Human Resource Connect On time $200 K Internet Refund Fact of Filing 14 months late $12. 9 M 24 CISH-6050 - Software Engineering Management

Software Crisis Examples … • Bank of America – Master. Net – Spent $23 M on an initial 5 year accounting & reporting system – Spent $600 M trying to make it work – Project cancelled – Lost customer accounts - $Billons 25 CISH-6050 - Software Engineering Management

Software Crisis Examples … • Allstate Insurance – In 1982 – $8 M computer system to automate business – EDS providing software – Initial 5 year project continued for 10 years, until 1993 – Cost approached $100 M 26 CISH-6050 - Software Engineering Management

Software Crisis Examples … • Blue Cross and Blue Shield of Wisconsin - 1983 – EDS hired to build $200 M computer system – Delivered on time in 18 months – System didn’t work – issued $60 M in overpayments and duplicate checks – BC lost 35, 000 policy holders by 1987 27 CISH-6050 - Software Engineering Management

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 28 CISH-6050 - Software Engineering Management

The Software Crisis • Software development projects suffering from: – Cost overruns – Schedule delays – Reduced functional deliverables – Potential project cancellation 29 CISH-6050 - Software Engineering Management

Elements of the Continuing Software Crisis Software is not delivered on time Software is over budget (usually by a factor of 2 or more) Dramatic example: in the early 1980's the IRS hired Sperry to automate tax form processing for $103 million. By 1985 the cost had tripled, the system could not handle the workload, and it had to be replaced. Software is too complex. Complexity does not scale linearly: for example, a 1000 line program is more than 10 times as complex as a 100 line program

Elements of the Software Crisis (cont'd) Software is unmaintainable due to: poor design poor documentation (most software can be understood only by its author, and then only within a few months of writing it) Software is inefficient (new versions of complex software require machine upgrades) Software is unreliable due to: poor design (Therac-25 disaster) inadequate testing (market pressures) impossible testing

Software Crisis Statistics • Standish Group ‘ 94 CHAOS Report: – The US spends $250 B 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 – $140 B in project waste 32 CISH-6050 - Software Engineering Management

The Software Crisis How did it start? 33 CISH-6050 - Software Engineering Management

The Software Crisis History • 1950 s and 1960 s – Programs are procedures to run hardware – Procedural, sequential thought process – Assembler level coding languages – Late 1960 s, Monitor programs evolved to operating systems 34 CISH-6050 - Software Engineering Management

The Software Crisis History … • 1970 s – Software Properties – Complex Ø Rapid growth in size of apps − Error Prone Ø Inherited ‘spaghetti’ code − Labor-intensive Ø Very few good development tools 35 CISH-6050 - Software Engineering Management

The Software Crisis History … • 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 36 CISH-6050 - Software Engineering Management

The Software Crisis History … • 1970 s - 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 37 CISH-6050 - Software Engineering Management

The Software Crisis History … • Despite improvements from the 1970 s to 1980 s, investing in software development still viewed as “bottomless pit” − Highly error prone − Labor-intensive − Cost overruns 38 CISH-6050 - Software Engineering Management

The Software Crisis History … • Early 1980 s – hardware costs decreased • Software development & service dominating cost factor • Led to shift in industry: − Defect Prevention − Defect Removal − Software Development Tools 39 CISH-6050 - Software Engineering Management

The Software Crisis – Why? • 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 40 CISH-6050 - Software Engineering Management

The Software Crisis – Why? • Arguments – Valid or Invalid? – Software is an art form; planning and cost management will damage creativity. – Defect-free software can’t be produced. 41 CISH-6050 - Software Engineering Management

The Software Crisis – Why? • 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 42 CISH-6050 - Software Engineering Management

The 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 43 CISH-6050 - Software Engineering Management

The Software Crisis - Improving • March, 2008 statistics show 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% 44 CISH-6050 - Software Engineering Management

The Software Crisis - Improving – 51% of challenged projects have a lower overrun ratio than in 2000 – 43% average cost overrun (1994: 180% cost overrun) – $55 B spent on project waste (1994: $140 B project waste) Ø $17 B cost overruns (1994: $59 B) Ø $38 B lost projects (1994: $81 B) 45 CISH-6050 - Software Engineering Management

The Software Crisis - Improving • 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) (1994: 74% features in final product) 46 CISH-6050 - Software Engineering Management

The Software Crisis - Improving • Software Engineering and Software Engineering Management are a continued effort against the Software Crisis 47 CISH-6050 - 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 48 CISH-6050 - Software Engineering Management

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 49 CISH-6050 - Software Engineering Management

Software Engineering Mgmt … • Software Engineering Management Fundamentals – Determine size of product – Allocate resource for the product – Create plan for utilizing resource – Monitor project – Measure project 50 CISH-6050 - Software Engineering Management

Why do software projects fail? • People begin programming before they understand the problem – Everyone likes to feel that they’re making progress – When the team starts to code as soon as the project begins, they see immediate gains – When problems become more complex (as they always do!), the work gets bogged down – In the best case, a team that begins programming too soon will end up writing good software that solves the wrong problem http: //www. stellman-greene. com 51

Why do software projects fail? • The team has an unrealistic idea about how much work is involved – From far away, most complex problems seem simple to solve – Teams can commit to impossible deadlines by being overly optimistic and not thinking through the work – Few people realize the deadline is optimistic until it’s blown http: //www. stellman-greene. com 52

Why do software projects fail? • Defects are injected early but discovered late – Projects can address the wrong needs – Requirements can specify incorrect behavior – Design, architecture and code can be technically flawed – Test plans can miss functionality – The later these problems are found, the more likely they are to cause the project to fail http: //www. stellman-greene. com 53

Why do software projects fail? • Programmers have poor habits – and they don’t feel accountable for their work – Programmers don’t have good control of their source code – Code written by one person is often difficult for another person to understand – Programmers don’t test their code, which makes diagnosing and fixing bugs more expensive – The team does not have a good sense of the overall health of the project http: //www. stellman-greene. com 54

Why do software projects fail? • Managers try to test quality into the software – Everyone assumes that the testers will catch all of the defects that were injected throughout the project – When testers look for defects, managers tell them they are wasting time – When testers find defects, programmers are antagonized because they feel that they are being personally criticized – When testers miss defects, everyone blames them for not being perfect http: //www. stellman-greene. com 55

How can we make sure that our projects succeed? • Make sure all decisions are based on openly shared information – It’s important to create a culture of transparency, where everyone who needs information knows where to find it and is comfortable looking at it – All project documents, schedules, estimates, plans and other work products should be shared with the entire team, managers, stakeholders, users and anyone else in the organization who wants them – Major decisions that are made about the project should be well-supported and explained http: //www. stellman-greene. com 56

How can we make sure that our projects succeed? • Don’t second-guess your team members’ expertise – Managers need to trust team members – Just because a manager has responsibility for a project’s success, it doesn’t mean that he’s more qualified to make decisions than the team members – If you don’t have a good reason to veto an idea, don’t http: //www. stellman-greene. com 57

How can we make sure that our projects succeed? • Introduce software quality from the very beginning of the project – Review everything, test everything – Use reviews to find defects – but don’t expect the review to be perfect – Use reviews to gain a real commitment from the team – It’s always faster in the long run to hold a review than it is to skip it http: //www. stellman-greene. com 58

How can we make sure that our projects succeed? • Don’t impose an artificial hierarchy on the project team – Consider all software engineers equal – A manager should not assume that programming is more difficult or technical than design, testing or requirements engineering – Managers should definitely not assume that the programmer is always right, or the tester is always raising false alarms http: //www. stellman-greene. com 59

How can we make sure that our projects succeed? • Remember that the fastest way through the project is to use good engineering practices – Managers and teams often want to cut important tasks – especially estimation, reviews, requirements gathering and testing. – If it were faster to build the software without these practices, we would never use them – Every one of these practices is about saving time and increasing quality by planning well and finding defects early. Cutting them out will cost time and reduce quality. http: //www. stellman-greene. com 60

Most spec changes arise from poor requirements capture