CS 540 – Quantitative Software Engineering

1. CS 540 – Quantitative Software Engineering Lecture 1 Think like an engineerGeorge D. Ogden, Ph. D.ogden@cs.stevens.edu orgeorge.ogden@stevens.edu

2. Roadmap • My history • Class mechanics • Quantitative Software Engineering • Software Process Models • CMM and the SEI • Ethics of our profession • Reading: first chapter in Bernstein and Yuhas (B&Y)

3. George Ogden, Ph D Background • 25 years at Bell Telephone Laboratories (and corporate successors) • Project experience with NASA, DARPA, and Naval Personnel Research, Exxon, et. al. • Small software company specializing in statistical analysis programming • Human Factors/Industrial-Organizational Research

4. Review Syllabus Two texts plus supplementary reading 11 lectures- one chapter/week https://guinness.cs.stevens-tech.edu/~lbernste/ Two Exams – 20% each Final - 40% Log book - 20% Testing will be from books, supplemental readings and lectures Class mechanics

5. Log Book/Homework/Projects • Email me lecture summary, homework problem, article/reading summary, web site review, etc. • email me logbook entries every week on Tuesday mornings by 8:00 AM. • Logbooks should be part of your professional life, it is time to start!

6. Lecture Topics • Think Like an Engineer: Overview of QSE • People, Projects, Products: Software management • Requirements • Prototyping • Architecture • Estimation • Risk Management • Human Factors • Implementation • Testing

7. Birth of Software Engineering • The software crisis, NATO conference, autumn 1968, Garmisch, Germany • Origin of term software engineering • “My thesis is that the software industry is weakly founded, and that one aspect of this weakness is the absence of a software components subindustry” MD McIlroy • https://guinness.cs.stevens-tech.edu/~lbernste/ select ‘Trustworty Systems radial then NATO

8. Software Crisis Persists • $250B spent on 175,000 projects with: • Average cost of projects: large company $2.3M, medium $1.3M small $.4M • Almost a third will be cancelled before they are completed • Over half will cost twice their current estimates • Only 15% will be finished on time and on budget • FAA Air Traffic Control project, • Mars missions • London Ambulance Dispatch System • Airbus

9. Customers do not get what want The National Software Council found this situation largely unchanged in 1995 and 2005. $200,000 Used after rework Abandoned or reworked $100,000 Used as delivered Delivered but not used A 1979 U.S. Government Accounting office report (FGMSD-80-4), which breaks down results from $6.8 million in nine federal software projects, shows that only 2% of the software was used as delivered. INFORMATION PROVIDED BY ACM SICSOFT SOFTWARE ENGINEERING NOTES, VOL 10 NO. 5, OCTOBER 1985.

10. Viewpoint • Bernstein and Yuhas: “..think like an engineer, especially for software” • SE practices make development of software: • Less chaotic • Reliably repeatable • More humane • Emphasis on simplification, trustworthiness, risk assessment and architecture

11. Views of Software Engineering • SEI: • Engineering is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind. • Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems.

12. Quantitative Software Engineering • “Quantitative Software Engineering is an analytical approach to producing reliable software products within budget and on time” - Stevens QSE program • Which matches the 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”

13. Software Engineering Knowledge (SWEBOK) • Software requirements analysis • Software design • Software construction • Software testing • Software maintenance • Software configuration management • Software quality analysis • Software engineering management • Software engineering infrastructure • Software engineering process

14. Reality check • There is theory • There are empirical models • There is engineering • There is a state-of-the-practice • There is a state-of-the-art • Why does the state-of-the-practice lag the state-of-the-art?

15. Software Process Models • The cost of constructing most software occurs during development and not during production • Process is a series of predictable steps, a roadmap • We will cover: • Hacking • Waterfall • Prototyping • Incremental • RAD • Spiral • Agile

16. Hacking • Code and Fix, Do Until Done Models • No planning, general idea of product, informal “design” mostly through code • Code, use, debug, test until ready for release • No way to tell you are done or if requirements met

17. Simplified Model HACKING System PROBLEM Reqts Eng Reqts Spec Test Maintain Design Code Tech Spec Implement

18. Analysis Design Coding Testing Integration Royce’s Waterfall Model • Phases in lockstep • Encourages narrow focus • Mistakes found late • Generates tightly coupled systems

19. Waterfall Model with feedback Reqts Eng Design Implementation Test V&V Maintenance

20. Waterfall: document-driven milestones • Baselined Requirements Specification • Baselined Test Plan • Baselined Design Specification • Baselined Code • Test Results report

21. Waterfall process • Change intolerant • Document-driven • Customer must state all requirements upfront, but fully 40% of requirements evolve • Features unavailable until implementation phase • Strong distinction between Development and Maintenance • Came from an era when coding was difficult and computing was expensive • Still in use

22. Why is Waterfall still used? • Easy to understand • Familiar to customers, steps make intuitive sense • ‘Natural’ Structure for new staff or teams • Tight control by project management • Requirements are stable • Forces documentation

23. Prototyping by Barry Boehm Build/revise mockup Listen to customer Customer test drives mockup When finished: Design, Implement, Test, Maintain

24. 30% 45% 25% Development approach comparison • TRADITIONAL SOFTWARE • PROCESS PROTOTYPE BASED PROCESS Systems Engineering & Prototype Systems Engineering 20% Final Development Design, Develop, Test, Install 80% • Deployment Final Development, Deployment 40% REDUCTION 40%

25. On prototyping • Evolutionary versus throwaway prototypes • Prototyping takes advantage of high level languages, sacrifices efficiency for speed • Great when few initial requirements • People (dev and users) like prototypes • Danger of feature creep • Documentation, performance of final system may suffer - perceived lack of discipline • Customer and management may think it is done • Quality can go either way • Requires experienced developers

26. Incremental • Functionality of system is produced and delivered in small increments • “prototyping + waterfall” - but focuses on delivery of operational product • Focuses on assigning priorities to features for each release - Rolling Stones • Especially useful with small staff, to manage technical risks and to build to current capability (e.g., hardware) • Not good when delivery is expensive

27. Rapid Application Development (RAD) • Incremental development • Focus is on time to market • JRPs (Joint Requirements Planning) - requirements triaged and JADs (Joint Application Design)-developers and users work together through prototyping to a finalized design • Product developers are SWAT (Skilled with Advanced Tools) team • Cutover- final testing of system takes place, users trained, system installed • Best used in information systems where technical risks are low • Typically 60-90 days

28. RAD advantages • Customer involvement • Tools reduce cycle time • Project team usually knows problem domain, key • Developers are willing to dive deeply into domain - key success factor in any model • Time-box, usually 60 days, bounds development • Installation and user training are an explicit part of the process

29. Spiral Development -Boehm • Drives to reduce risks • Recognizes that at each iteration you go through most phases • At each iteration you pinpoint sub-problem with highest risk and solve • Other models are subsumed

30. Boehm’s Spiral Model Analysis Design • Incremental and iterative • Evolutionary • Prototyping quick feedback • Continuous integration Coding Testing

31. Spiral Model

32. WinWin adds • Life Cycle Objectives - goals for each major software activity • Life Cycle architecture • Initial Operation Capability - (site plan+) preparation for software installation/distribution, site preparations before install (even for PCs) and assistance required by all relevant parties.

33. Spiral advantages • Risk analysis may uncover show stoppers early • Chunks development so that it is affordable • Waterfall like characteristics add some discipline, management control • Lots of feedback from all stakeholders

34. Spiral disadvantages • Expensive for small projects • Requires risk assessment expertise • Development is on again/off again so the other stages can be accomplished - in prototyping development is continuous. • “It is a custom. More honored in the breach than the observance.” William Shakespeare

35. Development plans (5w’s and h) • Every Project must have a development • Who will do what? • What will be done and what do you depend on? • When will it be done? • Where will it be done? • Why will you do it? • How will you do it?

36. Maintenance vs. Continuing Development • Fix bugs • Add features • Improve structure and maintainability • Zero defect philosophy • End Support During the product lifecycle there is a tension between progressive and antiregressive activities

37. Tailored OO Application Software Reusable Software Vendor Software User Programs Software Engineering Client Personal Computer Client Workstation Application Server Large Data Server

38. Requirements issues(

39. Software Engineering Institute • http://www.sei.cmu.edu/ • “The SEI promotes the evolution of software engineering from an ad hoc, labor intensive activity to a discipline that is well managed and supported by technology.” • Three themes: • Move to the left • Reuse everything • Never make the same mistake twice

40. Capability Maturity Model • A roadmap for software process improvement (Paulk 1999) • Describe an evolutionary process from ad hoc to maturity and discipline • Used in conjunction with the SEI’s IDEAL model • Initiating the improvement program • Diagnosing the current state of practice • Establishing the plans for the improvement program • Acting on the plans and recommended improvement • Learning from it

41. CMM (Paulk, 1999)

42. Software Engineering Ethics • TSQSE describes disasters due to failures in software engineering. • Software projects are pressure cookers • Software projects rely on relationships and trust • IEEE Computer Society and ACM have developed a software engineering code of ethics with eight principles Memorize the short form

43. Assignments • Read Chapter 1TSQSE • Read preface and chapter 1 of MMM • Download SWEBOK • Email me (ogden@cs.stevens.edu) 2-3 paragraphs summary of lecture 1 • Read Wikipedia article on “Software Engineering” Memorize the short form

44. Key Question for Software Engineers What’s the problem? It depends.