It’s Much More Than
“Software Engineering: A Practitioner’s Approach -
Fourth Edition” Pressman, Chapter 1
HP Software Engineering via Martin Griss
“Code Complete” McConnell, Chapters 1-3
CS 3500 SE - 1
(Pressman Figure 1.1)
Early years Second era Third era Fourth era
Batch Multiuser Distributed Powerful
Limited Real-time systems desk-top
distribution Embedded systems
Custom “intelligence” OOP
Increasing Amounts of Software
software software Low cost Parallel
The fifth era? Consumer
• Cloud computing impact
• Smart phones
1950 1960 1970 1980 1990 200x
CS 3500 SE - 2
The 50+ Year “Software Crisis”
Hardware advances faster than the ability of
software to take advantage of the hardware
Demand for new programs exceeds our ability to
Computers are pervasive; reliability is key; major
damage is possible on failure
We struggle to build reliable, high quality software
Support and enhancement of existing programs is
expensive and error prone due to poor design and
Many, many projects are started but never finished
CS 3500 SE - 3
Aspects of Software Crisis
Techniques that work for small programs don’t scale
Big systems live on beyond original author(s)
Most effort expended after first release
Requirements change rapidly
User expectations increase rapidly
Most software late, expensive, buggy or inadequate
Last minute testing can’t ensure quality
What can you add to this list?
CS 3500 SE - 4
Software vs. Hardware
Hardware failure rates Idealized software failure rates
(Pressman 1.2) (Pressman 1.3)
Why the difference?
CS 3500 SE - 5
Software Failure Rates
Idealized software failure rates Actual software failure rates
(Pressman 1.3) (Pressman 1.4)
Why the difference?
CS 3500 SE - 6
– We have books of standards.
– I work very hard to put the latest, greatest, fastest, state-of-the-art
hardware in front of all my programmers.
– We have the greatest CASE tools around.
– If we get behind, we can just add more programmers.
– A general statement of objectives is sufficient to start coding, we can
fill in the details later
– Project requirements change constantly, but change is easy because
software is flexible.
– Once the program is written and working, our job is done.
– Until the program is running, there is no way to assess quality.
– The only deliverable for a successful project is the working program.
CS 3500 SE - 7
Solution: Disciplined Software
“More than just programming and algorithms” HCI
CS 3500 SE - 8
– Analysis [What do we need?] (14-22%)
– Design [How do we do it?] (16-21%)
– Coding [Implement it] (30-39%)
– Testing [Make sure it works] (25-37%)
Relative time to fix defect after release
depends on origin:
– Analysis >> design >> coding >> test
Average time in maintenance
– Only 25-45% of entire lifecycle spent in development
– Fixing defects is 20-30% of lifecycle; enhancing the
program is 35-45% of lifecycle
– Half of maintenance time is spent figuring things out
CS 3500 SE - 9
Software Development Processes
Traditional Waterfall Process
- Address each step completely before moving to the next
- Each step might take many months
- Premium on getting things right the first time
- Emphasis on management hierarchies and written reports
- Iterate repeatedly through each step, gradually growing the
- Each iteration produces an incomplete but usable system
- Design changes and code refactoring are the norm
- Premium on frequent and rapid interactions among clients and
- Emphasis on face-to-face interactions
What Will We Study?
C# Programming using Visual Studio 2010
Software Construction Tools and Techniques
– Version control (SVN)
– Performance profiling
– Code inspections
– Object-oriented design patterns
– Program organization and coding style
– UML (Unified Modeling Language)
CS 3500 SE - 11
What Will We Study?
– Pipe and filter
Working Individually, in Pairs, in Small Groups
– Via programming projects
– Requirement gathering
– High-level design
– Intellectual property
– Professional ethics