Download
introduction n.
Skip this Video
Loading SlideShow in 5 Seconds..
Introduction PowerPoint Presentation
Download Presentation
Introduction

Introduction

297 Views Download Presentation
Download Presentation

Introduction

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Introduction ECE 417/617:Elements of Software Engineering Stan Birchfield Clemson University

  2. Why does this course exist? • Software is becoming more and more • important • complex • Software is everywhere, at multiple levels: System, application, scientific, embedded, ubiquitous, web, AI, … • We still do not know how to do it • Techniques that we have been using for 60 years are inadequate • Software engineering is an attempt to solve this problem • Expect several generations for new habits/principles/procedures to be • discovered • transmitted (education) • Adopted (replacing old habits)

  3. The Software Crisis • Standish Group (1995) studied S/W projects: • 16% successful(fully functional, on-time, and on-budget) • 53% challenged(reduced functionality, late, over-budget) • 31% failed(cancelled) • More recent data (2006) suggests an improvement: 35%, 46%, and 19%

  4. Famous Bugs • 1997: Mars Pathfinder • three tasks: low-priority (weather data), medium-priority (communications), high-priority (information bus) • priority inversion: Med interrupted Low before High could execute • watchdog timer repeatedly rebooted system because High had not executed in time • on-board debugging fixed the problem • http://www.ece.cmu.edu/~raj/mars.html • 1999: Mars Climate Orbiter • Smashed into planet because units were not converted from English to metric • $125 million spacecraft lost • 2004: Mars rover Spirit • Just after launch (June 2003), bug found in S/W, new version uploaded • This caused side-effect, so another version uploaded • After a few days, rover went into infinite reboot • Longest trial for file system testing was 9 days • 2004: Air traffic controller in Southern California • Microsoft server timed to shut down automatically every 49.7 days to prevent data overload (232 milliseconds) • Technicians normally reboot system every 30 days to avoid this • One technician forgot  system shut down on its own • 800 planes were left in the air without contact; 5 near misses • 2005: Toyota Prius • Bug caused gasoline engine to stall, often on highway • 1995: Denver airport automated baggage system software

  5. Another glitch • "Last year in South Africa an anti-aircraft had a 'software glitch' during a training exercise," he says. "It was supposed to fire upwards into the sky, instead it lowered and it fired in a circle and killed nine soldiers, all because of a software glitch." • http://www.cnn.com/2009/WORLD/americas/07/23/wus.warfare.remote.uav/index.html

  6. S/W in automobiles • Average automobile has • 70 to 100 microprocessor-based electronic control units (ECUs), running • 100 million lines of software code • Control software logic analyzes vehicle load, engine operations, battery parameters, temperatures, ... • Software development is the single most important consideration in new product development engineering • 35-40% of the cost of a car is software and electronics (13-15% of that cost is software development) • 50% of car warranty costs are related to electronics and embedded software • Bugs: • 2005: Toyota recalled >160000 Prius hybrids due to S/W problem • May 2008: Chrysler recalled >20000 Jeep Commanders b/c bug in automatic transmission S/W • June 2008: Volkswagen recalled ~4000 Passats and Tiguans for bug in engine-control-module S/W • November 2008: GM recalled >12000 Cadillacs that toggled air bag enable/disable bit from Robert N. Charette, This Car Runs on Code, IEEE Spectrum, Feb. 2009

  7. What is Software Engineering? • The IEEE Computer Society defines software engineering as: • (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) • If you do not find this helpful, you are not alone • A better definition: “S/W engineering is applying sound engineering principles to develop reliable, efficient, economic S/W” – Pressman

  8. What is S/W engineering? • S/W engineering is about managing complexity and change • complexity – many different conflicting objectives, lack of modularity • change – requirements updated when developers/clients get better understanding of application, staff turn-around is high, time b/w technological changes shorter than duration of project“The only constant is change” • S/W engineering • focuses on quality (foundation) • involves • Process – defines framework in which S/W is developed and managed • Methods – activities involved • Tools – support the work

  9. What is S/W engineering? • Modeling – one of the basic methods of science • Problem solving – lack of fundamental theory leads to empirical methods to find solutions • Knowledge acquisition – knowledge acquisition is a non-linear process; addition of new piece of knowledge may invalidate all previous knowledge; all activities are interrelated • Rationale-driven – assumptions change continually; must capture context in which each decision was made

  10. Product and process • Product – end result • Process – how to get there • Often seen as dichotomy (either-or). Field has vascillated back and forth over the years between the two. • In truth, there is a duality. Both are true, both are important, need to keep them in balance [Margaret Davis]

  11. Balance, balance, balance! • If you learn nothing else, remember this: Balance • Lone-ranger mentality has a tendency to reject discipline (distrust theory) • Academia has a tendency to over-emphasize discipline (theory more important than practice) • Common sense usually works • Be wary of absolutes (in software) • Even very good programmers can be trapped by adherence to rules rather than focusing on the end product

  12. The Controversy • The term S/W engineering originated in 1968 at a conference in Germany • But is the term meaningful? • S/W is fundamentally different from traditional engineering disciplines • Not bound by laws of physics • Nearly anything can change (plans, people, funding, milestones requirements, designs, tests) • Metrics have no atomic units and are highly subjective • Software development is more akin to movie production • Produces complex web of intellectual property • Limited only by vision and creativity • It is a blend of science and art • Some prefer software development, or software economics [Walter Royce, Successful Software Management Style:  Steering and Balance, IEEE Software, 20(5):40-47, 2005 ]

  13. Other differences • Unlike traditional engineering, • S/W is developed, not manufactured • Most S/W is still custom-built, not component-based construction • S/W does not ‘wear out’, but it does deteriorate • H/W failure curve vs. S/W failure curve • S/W projects cannot be managed as if they were manufacturing projects

  14. S/W Engineering is Management • S/W Engineering is about instilling discipline into the development process • Will make you a better programmer (self-management) • Is necessary for managing teams of programmers (especially large teams) • S/W Engineering is a collection of • management techniques • wisdom and advice gained from past projects (successes and failures) • abstractions to mediate between low-level code and high-level human language

  15. What, A Management Course? • No, you will not be able to manage a large S/W project with hundreds of people by the end of this course • Management skills take years to develop • But, if we are successful, you will • Be better able to manage your own code development • Be equipped to work in (and perhaps lead) a small team of programmers • Be alert to the struggles and issues faced by software managers

  16. The Purpose of this Course • Encounter the concepts / terms / methods of S/W Engineering • Some of these are useful • Even those that are not: You should be familiar with them, because you will encounter them • Almost all are subject to change / disagreements • Understanding the historical context and key players is important • Gain practical experience • Only way to master a craft is to do it – “Learning by doing” • (Imagine a painting class without paint) • Apply concepts as needed • Non-linear learning (“just in time learning”): Many concepts will not be taught until after you need them • Develop proficiency with some additional tools • C++, VC++, CVS, … • Learn to learn • Field is constantly changing • Habit and ability to continue learning is essential to success

  17. Course Mechanics • Entire class will work on one project • Students will work in pairs (pair programming) • Initially, pairs will self-organize into groups • Some random shuffling will occur • Weekly meetings in class • Each group will present progress, issues • Other groups will offer suggestions • Code will be inspected, reviewed • Individually, • Attendance expected • Bi-weekly “Learning reports” document non-linear learning (e.g., suggested readings, on-line references you encounter during project, etc.) • Final exam will cover primarily “textbook” knowledge; like certification exam

  18. Certification • IEEE Computer Society offers two levels of software certification • CSDA Certified Software Development Associate (introduced in 2008 for those at an entry level)http://www.computer.org/csda • CSDP Certified Software Development Professional (introduced in 2002 for midcareer software development practitioners) http://www.computer.org/csdp • Both comply with the ISO/IEC 24773 standard • ISO/IEC 24773:2008 is calledSoftware Engineering–Certification of Software Engineering Professionals–Comparison Framework • uses the IEEE Computer Society’s Guide to the Software Engineering Body of Knowledge (SWEBOK) as its description of the profession

  19. SWEBOK • Guide to the Software Engineering Body of Knowledge (SWEBOK) is “the benchmark for defining and comparing certifications in software engineering,” – Jim Moore, 2008 chair of the IEEE Computer Society’s Professional Practices Committee, the group that oversees the certification programs. • http://www.swebok.org/

  20. S/W Engineer • A good software engineer • knows how to identify requirements • can properly categorize project risk • can accurately estimate • “These skills are critical to providing customers with the correct product, on time, within budget.” – Susan K. (Kathy) Land