1. 1 Software Engineering Textbook:“Software Engineering -- A Practitioner’s Approach,” 5th Edition by Roger S. Pressman URL: http://dslab.kunsan.ac.kr/softeng.htmhttp://dslab.kunsan.ac.kr/softeng.htm http://bobby-gerardo.tripod.com/softeng

2. 2 Software Engineering Course Outline Part 1 -- The Product and the Process yChapters 1 & 2 Part 2 -- Software Management yManagement Concepts -- Chapter 3 ySoftware Process and Project Metrics -- Chapter 4 yProject Planning -- Chapter 5 yRisk Management -- Chapter 6 yScheduling and Tracking -- Chapter 7 yQuality Assurance -- Chapter 8 yConfiguration Management -- Chapter 9

3. 3 Software Engineering Course Outline zPart 3 -- Conventional Methods ySystem Engineering - Chapter 10 yAnalysis Concepts and Principles - Chapter 11 yAnalysis Modeling - Chapter 12 yDesign Concepts and Principles - Chapter 13 yDesign Methods - Chapter 14 yReal-Time Design - Chapter 15 yTesting Methods and Strategies - Chapter 16 & 17 yMetrics for Software - Chapter 18

4. 4 Software Engineering Course Outline zPart 4 -- Object-Oriented SE yObject-Oriented Concepts - Chapter 19 yObject-Oriented Analysis - Chapter 20 yObject-Oriented Design - Chapter 21 yObject-Oriented Testing - Chapter 22 yMetrics for Object-Oriented Systems - Chapter 23

5. 5 Software Engineering Course Outline zRe-ordered topics -- Testing yTesting Methods and Strategies - Chapter 16 & 17 yObject-Oriented Testing - Chapter 22

6. 6 Software Engineering Course Outline zPart 5 -- Advanced Topics yFormal Methods -- Chapter 24 yCleanroom SE -- Chapter 25 ySoftware Reuse -- Chapter 26 yRe-engineering -- Chapter 27 yClient/Server -- Chapter 28 yComputer-Aided Software Engineering -- Ch. 29 yThe Future -- Chapter 30

7. 7 Software Engineering zAn initial calibration of perspective: yHow many lines of code are produced, on average, by one software engineer in a year? yHow long would it take you to do the attached web generation problem?

8. 8 Software Engineering — Introduction zWhat is Software Engineering (SE)? yThe process of building a software product. zSome questions to put SE in perspective: yWhat are the sizes of some typical software products? xMaple.exe = 1.3 Mbytes.-- System over 3.8 Mbytes xNetscape.exe = 1.26 megabytes. xMicrosoft Office XP > 300 megabytes. yHow many people would it take to build these in 1 year? 2? yWhat would you do if a bug could cost lives and $2 billion? yWhat would you do if a delay could cost $100’s of millions?

9. 9 Software Engineering — Introduction zSome questions to put SE in perspective (con’t): yWhat is the impact of distributing buggy software? yWhy do we have so many software upgrades? yWhat is the impact of software upgrades? yWhy is it so difficult to measure software development progress? yWhat are some of the ethical issues in software development? yWhy does it take so long to develop software? yWhy does software cost so much? yWhy do people continue to use buggy and/or obsolete software?

10. 10 Some Software Characteristics zSoftware is engineered or developed, not manufactured in the traditional sense. zSoftware does not wear out in the same sense as hardware.

11. 11 Some Software Characteristics zIn theory, software does not wear out at all. zBUT, yHardware upgrades. ySoftware upgrades.

12. 12 Some Software Characteristics zThus, reality is more like this. yMost serious corporations control and constrain changes zMost software is custom built, and customer never really knows what she/he wants.

13. 13 Some General Approaches zDevelop and use good engineering practices for building software. zMake heavy use of reusable software components. zUse modern languages that support good software development practices, e.g., C, C++, Java. zUse 4th generation languages. zBut, almost everything is a two-edged sword. yConsider long term tool maintenance. xRight now, this is a major problem for NASA.

14. 14 Types of Software Applications zSystems Software zReal-Time Software zBusiness Software zEngineering Software zEmbedded Software zArtificial Intelligence Software zPersonal Computer Software

15. 15

16. 16 Software Myths zMyth: It’s in the software. So, we can easily change it. yReality: Requirements changes are a major cause of software degradation. zMyth: We can solve schedule problems by adding more programmers. yReality: Maybe. It increases coordination efforts and may slow things down. zMyth: While we don’t have all requirements in writing yet, we know what we want and can start writing code. yReality: Incomplete up-front definition is the major cause of software project failures.

17. 17 Software Myths zMyth: Writing code is the major part of creating a software product. yReality: Coding may be as little as 10% of the effort, and 50 - 70% may occur after delivery.

18. 18 Software Myths zMyth: I can’t tell you how well we are doing until I get parts of it running. yReality: Formal reviews of various types both can give good information and are critical to success in large projects. zMyth: The only deliverable that matters is working code. yReality: Documentation, test history, and program configuration are critical parts of the delivery. zMyth: I am a (super) programmer. Let me program it, and I will get it done. yReality: A sign of immaturity. A formula for failure. Software projects are done by teams, not individuals, and success requires much more than just coding.