210 likes | 365 Views
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
E N D
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; 845-5009 425E Bright 845-4306 Lihan@cs.tamu.edu ask8166@cs.tamu.edu Sections 503, 504,506 Sections501, 502, 505 Textbook: “Software Engineering -- A Practitioner’s Approach,” 4th Edition by Roger S. Pressman January 12, 1999 Chapter 1
Software Engineering CPSC 431 • Reference books -- at least one recommended • “UML in a Nutshell” by Sinan Si Albir, O’Reilly • “UML Distilled” by Martin Fowler and Kendall Scott, Addison-Wesley • “The Unified Modeling Language User Guide” by Grady Booch, James Rumbaugh and Ivar Jacobson , Addison-Wesley • “Visual Modeling with Rational Rose and UML” by Terry Quatrani , Addison-Wesley • “UML Notation Guide” -- available from copy center or web at http://www.rational.com/uml/resources/documentation/notation/index.jtmpl January 12, 1999 Chapter 1
Software Engineering CPSC 431 • Grading • Mid-term Exam (Mar. 6/7) 30% • Final Exam 30% • Laboratory Project 30% • Homework 10% Course Outline • Part 1 -- The Product and the Process • Chapters 1 & 2 January 12, 1999 Chapter 1
Software Engineering CPSC 431 Course Outline • Part 3 -- Conventional Methods • System Engineering - Chapter 10 • Analysis Concepts and Principles - Chapter 11 • Analysis Modeling - Chapter 12 • Design Concepts and Principles - Chapter 13 • Design Methods - Chapter 14 • Real-Time Design - Chapter 15 • Testing Methods and Strategies - Chapter 16 & 17 • Metrics for Software - Chapter 18 January 12, 1999 Chapter 1
Software Engineering CPSC 431 Course Outline • Part 4 -- Object-Oriented SE • Object-Oriented Concepts - Chapter 19 • Object-Oriented Analysis - Chapter 20 • Object-Oriented Design - Chapter 21 • Object-Oriented Testing - Chapter 22 • Metrics for Object-Oriented Systems - Chapter 23 January 12, 1999 Chapter 1
Software Engineering CPSC 431 Course Outline • Re-ordered topics -- Testing • Testing Methods and Strategies - Chapter 16 & 17 • Object-Oriented Testing - Chapter 22 January 12, 1999 Chapter 1
Software Engineering CPSC 431 Course Outline • Part 2 -- Software Management • Management Concepts -- Chapter 3 • Software Process and Project Metrics -- Chapter 4 • Project Planning -- Chapter 5 • Risk Management -- Chapter 6 • Scheduling and Tracking -- Chapter 7 • Quality Assurance -- Chapter 8 • Configuration Management -- Chapter 9 January 12, 1999 Chapter 1
Software Engineering CPSC 431 Course Outline • Part 5 -- Advanced Topics • Formal Methods -- Chapter 24 • Cleanroom SE -- Chapter 25 • Software Reuse -- Chapter 26 • Re-engineering -- Chapter 27 • Client/Server -- Chapter 28 • Computer-Aided Software Engineering -- Ch. 29 • The Future -- Chapter 30 January 12, 1999 Chapter 1
Software Engineering — Introduction • What is Software Engineering (SE)? • The processof building a software product. • Some questions to put SE in perspective: • What are the sizes of some typical software products? • Maple.exe = 1.3 Mbytes.-- System over 3.8 Mbytes • Netscape.exe = 1.26 megabytes. • Microsoft Office 97 > 180 megabytes. • How many people would it take to build these in 1 year? 2? • What would you do if a bug could cost lives and $2 billion? • What would you do if a delay could cost $100’s of millions? January 12, 1999 Chapter 1
Software Engineering — Introduction • What is the impact of distributing buggy software? • Some questions to put SE in perspective (con’t): • Why do we have so many software upgrades? • What is the impact of software upgrades? • What are some of the ethical issues in software development? • Why is it so difficult to measure software development progress? • Why does it take so long to develop software? • Why does software cost so much? • Why do people continue to use buggy and/or obsolete software? January 12, 1999 Chapter 1
Some Software Characteristics • Software is engineered or developed, not manufactured in the traditional sense. • Software does not wear out in the same sense as hardware. January 12, 1999 Chapter 1
Some Software Characteristics • In theory, software does not wear out at all. • BUT, • Hardware upgrades. • Software upgrades. January 12, 1999 Chapter 1
Some Software Characteristics • Thus, reality is more like this. • Most serious corporations control and constrain changes • Most software is custom built, and customer never really knows what she/he wants. January 12, 1999 Chapter 1
Some General Approaches • Develop and use good engineering practices for building software. • Make heavy use of reusable software components. • Use modern languages that support good software development practices, e.g., Ada95, Java. • Use 4th generation languages. • But, almost everything is a two-edged sword. • Consider long term tool maintenance. • Right now, this is a major problem for NASA. January 12, 1999 Chapter 1
Types of Software Applications • Systems Software • Real-Time Software • Business Software • Engineering Software • Embedded Software • Artificial Intelligence Software • Personal Computer Software January 12, 1999 Chapter 1
Software Myths • Myth: It’s in the software. So, we can easily change it. • Reality: Requirements changes are a major cause of software degradation. • Myth: We can solve schedule problems by adding more programmers. • Reality: Maybe. It increases coordination efforts and may slow things down. • Myth: While we don’t have all requirements in writing yet, we know what we want and can start writing code. • Reality: Incomplete up-front definition is the major cause of software project failures. January 12, 1999 Chapter 1
Software Myths • Myth: Writing code is the major part of creating a software product. • Reality: Coding may be as little as 10% of the effort, and 50 - 70% may occur after delivery. January 12, 1999 Chapter 1
Software Myths • Myth: I can’t tell you how well we are doing until I get parts of it running. • Reality: Formal reviews of various types both can give good information and are critical to success in large projects. • Myth: The only deliverable that matters is working code. • Reality: Documentation, test history, and program configuration are critical parts of the delivery. • Myth: I am a (super) programmer. Let me program it, and I will get it done. • Reality: 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, 1999 Chapter 1