Navigating the Realm of Software Engineering

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 • 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. 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

6. 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

7. 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

8. 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]

9. 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

10. 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 ]

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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/