Embed Size (px)
Citation preview
1
Software EngineeringTextbook: “Software Engineering -- A Practitioner’s Approach,” 5th Edition by Roger S. Pressman
URL: http://dslab.kunsan.ac.kr/softeng.htmhttp://bobby-gerardo.tripod.com/softeng
2
Software Engineering
Course OutlinePart 1 -- The Product and the Process
Chapters 1 & 2
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
3
Software Engineering
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
4
Software Engineering
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
5
Software Engineering
Course Outline
Re-ordered topics -- Testing Testing Methods and Strategies - Chapter 16 & 17 Object-Oriented Testing - Chapter 22
6
Software Engineering
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
8
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 XP > 300 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?
9
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?
10
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.
11
Some Software Characteristics
In theory, software does not wear out at all.
BUT, Hardware upgrades. Software upgrades.
12
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.
13
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., C, C++, 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.
14
Types of Software Applications
Systems Software Real-Time Software Business Software Engineering Software Embedded Software Artificial Intelligence Software Personal Computer Software
16
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.
17
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.
18
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.
