January 12, 1999Chapter 1 1 Software Engineering  CPSC 431 MW 1:50...

Click here to load reader

download 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

of 22

  • date post

    21-Dec-2015
  • Category

    Documents

  • view

    212
  • download

    0

Embed Size (px)

Transcript of January 12, 1999Chapter 1 1 Software Engineering  CPSC 431 MW 1:50...

  • Slide 1
  • 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 -- TAs Off: TTR 8:30-9:45; 3:15-4:00pm Off: MF 2:00-4:00pm 328B Bright; 845-5009 425E Bright 845-4306 Lihan@cs.tamu.eduLihan@cs.tamu.edu ask8166@cs.tamu.edu Sections 503, 504,506 Sections501, 502, 505 Textbook:Software Engineering -- A Practitioners Approach, 4th Edition by Roger S. Pressman
  • Slide 2
  • January 12, 1999Chapter 1 2 Software Engineering CPSC 431 zReference books -- at least one recommended yUML in a Nutshell by Sinan Si Albir, OReilly yUML Distilled by Martin Fowler and Kendall Scott, Addison-Wesley yThe Unified Modeling Language User Guide by Grady Booch, James Rumbaugh and Ivar Jacobson, Addison- Wesley yVisual Modeling with Rational Rose and UML by Terry Quatrani, Addison-Wesley yUML Notation Guide -- available from copy center or web at http://www.rational.com/uml/resources/documentation/notation/index.jtmpl
  • Slide 3
  • 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
  • Slide 4
  • 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
  • Slide 5
  • 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
  • Slide 6
  • 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
  • Slide 7
  • 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
  • Slide 8
  • 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
  • Slide 9
  • 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?
  • Slide 10
  • 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 $100s of millions?
  • Slide 11
  • January 12, 1999Chapter 1 11 Software Engineering Introduction zSome questions to put SE in perspective (cont): 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?
  • Slide 12
  • 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.
  • Slide 13
  • January 12, 1999Chapter 1 13 Some Software Characteristics zIn theory, software does not wear out at all. zBUT, yHardware upgrades. ySoftware upgrades.
  • Slide 14
  • 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.
  • Slide 15
  • 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.
  • Slide 16
  • 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
  • Slide 17
  • January 12, 1999Chapter 1 17 Software Myths zMyth: Its 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 dont 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.
  • Slide 18
  • 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 50 - 70% may occur after delivery.
  • Slide 19
  • January 12, 1999Chapter 1 19
  • Slide 20
  • January 12, 1999Chapter 1 20 Software Myths zMyth: I cant 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.
  • Slide 21
  • January 12, 1999Chapter 1 21
  • Slide 22
  • January 12, 1999Chapter 1 22