January 12, 1999 Chapter 11
Software Engineering CPSC 431MW 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
[email protected] [email protected]
Sections 503, 504,506 Sections501, 502, 505
Textbook: “Software Engineering -- A Practitioner’s Approach,” 4th Edition by Roger S. Pressman
January 12, 1999 Chapter 12
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 13
Software Engineering CPSC 431
Grading Mid-term Exam (Mar. 6/7) 30% Final Exam 30% Laboratory Project 30% Homework 10%
Course OutlinePart 1 -- The Product and the Process
Chapters 1 & 2
January 12, 1999 Chapter 14
Software Engineering CPSC 431
Course OutlinePart 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 15
Software Engineering CPSC 431
Course OutlinePart 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 16
Software Engineering CPSC 431
Course OutlineRe-ordered topics -- Testing
Testing Methods and Strategies - Chapter 16 & 17 Object-Oriented Testing - Chapter 22
January 12, 1999 Chapter 17
Software Engineering CPSC 431
Course OutlinePart 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 18
Software Engineering CPSC 431
Course OutlinePart 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 110
Software Engineering — Introduction
What is Software Engineering (SE)? The process of 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 MbytesNetscape.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 111
Software Engineering — Introduction Some questions to put SE in perspective (con’t):
What is the impact of distributing buggy software? Why do we have so many software upgrades? What is the impact of software upgrades?
Why is it so difficult to measure software development progress?
What are some of the ethical issues in software development?
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 112
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 113
Some Software Characteristics
In theory, software does not wear out at all.
BUT, Hardware upgrades. Software upgrades.
January 12, 1999 Chapter 114
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 115
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 116
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 117
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 118
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 119
Percent Maintenance Historgram
0%
5%
10%
15%
20%
25%
30%
35%
(0,15] (15,30] (30,45] (45,60] (60,75]
January 12, 1999 Chapter 120
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 121
25%
31%
13%
8%
6%
0%
5%
10%
15%
20%
25%
30%
35%
<=2 (2.4] (4,6] (6,8] (8,10] >10
Estimate in weeks
January 12, 1999 Chapter 122
SLOCs per Year Histogram
0%
5%
10%
15%
20%
25%
30%
35%
40%
(0,5k] (5k,10k] (10k,20k] (20k,50k] >50k
Series1
Top Related