1. Software Engineering

2. How many lines of code? Average CS1004 assignment: 200 lines Average CS4115 project: 5000 lines Corporate e-commerce project: 80,000 lines Microsoft Windows Vista: 50,000,000+ lines

3. What is Software Engineering? NOT just programming NOT just programming [part of] a large software system NOT just programming as a member of a large team

4. What is Software Engineering? “The practice of creating and maintaining software applications by applying technologies and practices from engineering, computer science, project management, application domains and other fields.” -Wikipedia

5. Over 50% of software projects fail Fred Brooks : IBM’s OS/360 “was late, took more memory than was planned, costs were several times the estimate, and it did not perform very well until several releases after the first”

6. Why do software projects fail? Difficult to accurately estimate how long something will take

7. Why do software projects fail? Developers typically overestimate/overstate their productivity

8. Why do software projects fail? Requirements are not always clearly defined

9. Why do software projects fail? Requirements are not always realistic

10. Why do software projects fail? Requirements are always changing

11. Software development = tradeoffs Cost vs Scope vs Quality vs Time Security vs Performance Specialization vs Generalization Specificity vs Flexibility

12. Software Engineering Processes: –Project management (resources, time, etc.) –Requirements gathering & management –Software design & architecture –Software development –Testing and quality assurance Tools: –Software design, development, and testing –Communication –Requirements and defect tracking –Version control

13. Why Study Software Engineering? Writing a program is easy –Program = code (possibly with comments) Developing a software system is harder –System = program plus technical documentation sufficient such that someone other than original developers can maintain, typically involving environmental interoperation (beyond just UI and file system) Developing a software product is very hard –Product = system plus customers, fulfilling the business needs of those customers, with customer- oriented documentation and support

14. Why Study Software Engineering? Software Engineering aims at supporting the development of high-quality software products –High-quality software products are more robust, efficient and effective –High-quality software products are easier to use, understand, modify, and compose with other high-quality software products

15. But I just want to learn Java!!!

16. Software Engineering is still important! “Software Engineers” aren’t the only ones who should know about software engineering Creating high-quality software is necessary in any case in which you or someone else will need to maintain and/or modify your code

17. Software Engineering Activities System Engineering Process Selection and Training Requirements –Eliciting –Analysis –Recording Technology Selection and Training Design –Architecture –Components –Modules Coding –Unit Testing –Debugging Integration –Build –Integration Testing –Configuration Management System Testing –Performance Testing & Optimization –Acceptance Testing –Beta Testing Deployment –Delivery –Installation Operations –System Management –Maintenance –Upgrades Support Activities –Project Planning and Tracking –Customer Interaction –Process Improvement –Training –Documentation –Personnel Management

18. In the Beginning…

19. Build First Version Retirement Operations Modify until Customer satisfied Code-and-Fix

20. Discussion of Code-and-Fix Really Bad Really Common Advantages –No Overhead –No Expertise Disadvantages –No means of assessing progress –Difficult to coordinate multiple programmers Useful for “hacking” single-use/personal-use programs: start with empty program and debug until it works

21. Requirements Validate Retirement Operations Test Implementation Verify Design Waterfall

22. More Detailed Waterfall REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

23. Discussion of Waterfall Articulated by Win Royce, ~1970 Widely used today Advantages –Measurable progress –Experience applying steps in past projects can be used in estimating duration of “similar” steps in future projects –Produces software artifacts that can be re-used in other projects The original waterfall model (as interpreted by many) disallowed iteration –Inflexible –Monolithic –Requirements change over time –Maintenance not handled well The “waterfall with feedback” model was, however, what Royce had in mind

24. Waterfall* REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

25. Prototyping Initial Concept Complete and Release Prototype Refine Prototype Until Acceptance Design and Implement Initial Prototype

26. Discussion of Prototyping Mock-ups allow users to visualize an application that hasn't yet been constructed Used to help develop requirements specification –Useful for rapidly changing requirements –Or when customer won’t commit to specification Once requirements “known”, waterfall (or some other process model) used Prototypes discarded once design begins –Prototypes should not be used as a basis for implementation, since prototyping tools do not create production quality code –Customer (and management) may need to be “educated” about prototypes: a prototype is not 80-90% of the final product, usually not even 10%

27. Incremental (Staged) Detailed Design, Implement, Test, Deliver Feature Set Requirements Validate Retirement Operations Verify Architectural Design

28. Discussion of Incremental Iterations are classified according to feature sets –e.g., features 1 and 2 will be delivered in this iteration, features 3 and 4 are next Series of increasingly “complete” releases

29. The Basic Problem: Risk Some modern approaches view “risk” as the main problem of software development –Schedule slips –Business changes –Staff turnovers –New technologies –…

30. Spiral Model PLANDEVELOP AND TEST DETERMINE GOALS, ALTERNATIVES, CONSTRAINTS EVALUATE ALTERNATIVES AND RISKS Requirements, life-cycle plan Budget 1 Alternatives 1 Constraints 1 Risk analysis 1 2 3 4 Constraints 2 3 4 Budget 2 3 4 Alternatives 2 3 4 Prototype 1 Proto- type 2 Proto- type 3 Proto- type 4 Concept of operation Software requirements Validated requirements Development plan Integration and test plan Software design Validated, verified design Detailed design Code Unit test System test Acceptance test Implementation plan start

31. Discussion of Spiral Model Proposed by Barry Boehm, ~1986 Similar to Incremental Model, but each iteration is driven by “risk management” and/or customer feedback Determine objectives and current status Identify risks and priorities Next iteration addresses (current) highest risk and/or highest priority items Repeat

32. Agile Programming Initial Concept Operations Acceptance Testing and Delivery Requirements and Iteration Planning Next Iteration Design and Implement

33. Discussion of Agile Each iteration a mini-project –Each iteration’s deliverable is not a prototype, but an operational system –Understand risk vs. business value in planning iterations –Put some working functionality into user’s hands as early as possible Timeboxing: –Set the date for delivering an iteration –Date cannot change –Only functionality (scope) can change –Short duration iterations (weeks, not months)

34. eXtreme Programming

35. Created by Kent Beck in late 1990s “Takes best practices to extreme levels” Focuses on five values: –Communication –Simplicity –Feedback –Courage –Respect

36. What does this mean for me?

37. Software Engineering in CS1007 The programs you write in this class will graded as much on their “quality” as on their functionality This means that they should be: –Well-designed –Robust and well-tested You need to come up with your own personal “software process” to ensure the quality of the code you write