CSE 230: Introduction to Software Engineering Topics covered: Introduction

Evolution of the software business  First software company was established in 1955:  State of the software business today:

Role of software Computer systems/software play an important role in virtually every aspect of our day to day lives: Software is becoming increasingly sophisticated and permeates every aspect of our lives, it is increasingly important to build it efficiently and right. And yet… Software development today is fraught with uncertainty and is characterized by (similar to what it was decades ago):

State of the practice EstimateEarlyOn TimeDelayedCanceled 13, % 74.77%11.83% 7.33% 130, %60.76%17.67%20.33% 1,300,000 13,000,000 Source: Patterns of software failures and successes, Capers Jones, 1996 Conclusions:

State of the practice (contd..) Cost overrun SuccessfulCancelled Source: The Standish Group, 1994 Successful projects (16.2%) Challenged (52.7%) Impaired (31.1%)

State of the practice (contd..)  Corporate software is often obsolete before delivery, and is incapable of evolving to meet future needs.  Many projects start with wrong goals and need to restart.  Cost and time overruns:

Software development problems Software costs are increasing as hardware costs continue to decline. Software costs Hardware costs Time Hardware costs vs. Software costs

Software development problems (contd..) Software development times are getting longer and longer and maintenance costs are getting higher and higher 3% 8% 7% 15% 67% Requirements -- 3% Design -- 8% Implementation -- 7% Testing -- 15% Maintenance -- 67% Conclusions:

Software development phases & waterfall model Requirements analysis and definition Design and specification Implementation and unit testing Integration and system testing Operation and maintenance

Relative costs to fix errors Requirements Design Implementation Testing Maintenance Cost Cost to fix an error increases as it is found later and later in the software lifecycle.

Software development problems (contd..) Air Traffic Control (FAA modernization): Outages of AT&T long distance switches: Ariane 5 launch explosion, 4 June 1996: East coast black-out, Aug NIST estimates that the US economy loses approximately $59.5 billion of 0.6% of the GDP due to software failures Lesson:

Why are software projects late? Estimating techniques are poorly developed Estimates are based on optimism: Optimism could be because of the nature of creativity: Our techniques of estimating are poorly developed. More seriously they reflect an unvoiced assumption which is quite untrue, that is, that all will go well. -- Fred Brooks, The Mythical Man-Month

Why are software projects late? (contd..) Estimating techniques confuse effort with progress. Is one man working six months equal to six men working one month? Our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable. - Fred Brooks, The Mythical Man-Month

Why are software projects late ? (contd..) Do not plan schedule effectively. In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of the projects were on schedule until and except in system testing….. - Fred Brooks, The Mythical Man-Month.

Why software projects are late? (contd..) Do not monitor progress effectively How does a software project get to be a year late?.. One day at a time! Fred Brooks, The Mythical Man-Month.

Why are software projects late ? (contd..) When slippage is recognized, we add people. Most tasks require communication among workers, which consists of: For n workers, intercommunication: Adding more people to an already late project is usually like “Adding gasoline to fire!” Adding manpower to a late software project makes it later. Fred Brooks, The Mythical Man-Month.

Fred Brooks & The Mythical Man-Month  Fred Brooks became manager for IBM’s OS 360 in  Previous experience in hardware design.  OS/360 (probably) largest software system attempted at that time.  OS/360 results:  The Mythical Man-Month analyzes OS/360 experiences.  Professor at UNC Chapel Hill.  Experiences and analyses are true even today.

Definition of software engineering  IEEE definition:  The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software.  Roger S. Pressman’s definition:  Software engineering is the technology that encompasses a process, a set of methods and an array of tools. (Software Engineering: A Practitioner’s Approach)  Parnas’ definition:  Multi-person construction of multi-version software (Parnas 1978)

We have a “Software Crisis”! (1968)  “Software Engineering” was coined in  NATO conference in Germany.  An “early study” of problem DOD projects revealed the following facts:

Historical perspective of software engineering  “Early days”  Towards a software engineering discipline:

What software engineering is and is not..  Software engineering is concerned with “engineering” software systems, that is, building and modifying practical software systems:  Software engineering is not..  These are the issues that haven’t really surfaced in learning to program.  Transformation/translation of a program to “software”

Programmer vs. software engineer  Students familiar with programs and some forms of documentation through course projects in an academic environment:  Experiences of professionals in the software industry:

Program to a software product transformation Program product Programming system Programming system product 3X 9X Checking Account Program

Program to a software product transformation  Difficult part in designing any software system is usually not the coding of the software.  Software engineering is not about individual programming but about a structured approach for groups to manage complexity and change.

What is a software product? Software is: - Definition offered by R. S. Pressman. (Software Engineering: A Practitioner’s Approach) Alternatively,

Software Engineering: Three key elements  Process  Methods:  Tools:

Example: Process, Method, and Tools  Testing of individual code modules (before integration).  Process addresses issues such as how it is to be done, who is responsible for it, when does it get done, etc.  Documents  Who has the responsibility?  How do we verify (check) that it has been done?

Example: Process, Method, Tools  Method addresses issues such as what approach will be used?  Example: Black-box testing:  Example: White-box or “coverage testing”:

Example: Process, Method, Tools  Tools provide software support for processes and methods:  Test case generator:  Regression test environment.  Memory leak tool.  Coverage testing and measurement tool.  Problem reporting and tracking tool.  Test-case matrix.

Summary  Critical aspects of our day to day lives depend on software, yet software development lacks the rigor and discipline of mature engineering disciplines:  Too many projects get delayed, costs and schedules slip.  Software engineering is about bringing discipline and rigor to the building and maintenance of software systems.  Study of software engineering focuses on three key elements: process, methods and tools.  In addition to the functionality/feature related requirements, software products are often expected to satisfy various non functional requirements:  Relative priorities of these requirements depend on the nature of the application.  May or may not be able to satisfy all the requirements, tradeoffs may be necessary.