January 12, 1999Chapter 1 1 Software Engineering  CPSC 431 MW 1:50 – 2:40 TTR 2:20 – 3:10. BRIGHT 113 ZACHRY 105b W. M. Lively Rm 427C, H. R. Bright Bldg. Office Hours:4 – 5 pm M - TTR Li Han Ashar Khan -- TA’s Off: TTR 8:30-9:45; 3:15-4:00pm Off: MF 2:00-4:00pm 328B Bright; E Bright Sections 503, 504,506 Sections501, 502, 505 Textbook:“Software Engineering -- A Practitioner’s Approach,” 4th Edition by Roger S. Pressman

January 12, 1999Chapter 1 2 Software Engineering  CPSC 431 zReference books -- at least one recommended y“UML in a Nutshell” by Sinan Si Albir, O’Reilly y“UML Distilled” by Martin Fowler and Kendall Scott, Addison-Wesley y“The Unified Modeling Language User Guide” by Grady Booch, James Rumbaugh and Ivar Jacobson, Addison- Wesley y“Visual Modeling with Rational Rose and UML” by Terry Quatrani, Addison-Wesley y“UML Notation Guide” -- available from copy center or web at

January 12, 1999Chapter 1 3 Software Engineering  CPSC 431 zGrading yMid-term Exam (Mar. 6/7)30% yFinal Exam30% yLaboratory Project30% yHomework10% Course Outline zPart 1 -- The Product and the Process yChapters 1 & 2

January 12, 1999Chapter 1 4 Software Engineering  CPSC 431 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

January 12, 1999Chapter 1 5 Software Engineering  CPSC 431 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

January 12, 1999Chapter 1 6 Software Engineering  CPSC 431 Course Outline zRe-ordered topics -- Testing yTesting Methods and Strategies - Chapter 16 & 17 yObject-Oriented Testing - Chapter 22

January 12, 1999Chapter 1 7 Software Engineering  CPSC 431 Course Outline zPart 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

January 12, 1999Chapter 1 8 Software Engineering  CPSC 431 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

January 12, 1999Chapter 1 9 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?

January 12, 1999Chapter 1 10 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 97 > 180 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?

January 12, 1999Chapter 1 11 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?

January 12, 1999Chapter 1 12 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.

January 12, 1999Chapter 1 13 Some Software Characteristics zIn theory, software does not wear out at all. zBUT, yHardware upgrades. ySoftware upgrades.

January 12, 1999Chapter 1 14 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.

January 12, 1999Chapter 1 15 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., Ada95, 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.

January 12, 1999Chapter 1 16 Types of Software Applications zSystems Software zReal-Time Software zBusiness Software zEngineering Software zEmbedded Software zArtificial Intelligence Software zPersonal Computer Software

January 12, 1999Chapter 1 17 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.

January 12, 1999Chapter 1 18 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 % may occur after delivery.

January 12, 1999Chapter 1 19

January 12, 1999Chapter 1 20 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.

January 12, 1999Chapter 1 21

January 12, 1999Chapter 1 22