1. CSE 436—Software and its Processes
Ron K. Cytron
http://www.cs.wustl.edu/~cytron/cse436/
19 September 2005
2. CSE 436 Software Engineering Workshop
Questions for discussion
• Why does it take so long to get software
finished?
– What does “finished” really mean?
– Is software so special?
– Metro Link
• Why are development costs so high?
– Initial shock factor
– Bidding problems
– Time = money
3. CSE 436 Software Engineering Workshop
Questions for discussion
• Why can’t we find all errors before we give the
software to our customers?
– Debugging
– Testing
– Program proofs
– Fault sources
– What is our obligation?
• Why do we spend so much time and effort
maintaining existing programs?
– Legacy systems
– What happens to software over time?
4. CSE 436 Software Engineering Workshop
Questions for discussion
• Why do we continue to have difficulty in
measuring progress as software is being
developed and maintained?
– Progress usually means “distance from done”
– Monotonically nonincreasing?
5. CSE 436 Software Engineering Workshop
Changing Nature of Software [Pressman]
• System software
– Services
– Middleware
• Application software
– Business apps
– Point of sale
– Real-time manufacturing (safety concerns)
• Engineering/scientific
– Number crunching
– Weather
– Seismic exploration
6. CSE 436 Software Engineering Workshop
Changing Nature of Software [Pressman]
• Embedded software
– Limited available resources
• Power
• Storage
– Long lifetime, MTF
– Limited ability to maintain or repair
– “Computer” becomes invisible
– Amazing applications
• Dust
• Flexible buildings
– Lots of activity to make this a higher-level endeavor
7. CSE 436 Software Engineering Workshop
Changing Nature of Software [Pressman]
• Client / server
– Distributed components
– Often federated to make one application
• User authentication
• Shopping based on inventory
• Financing
• Payment
• Web applications
– Connectionless environment
– Security / server-side state
– Fault tolerance
8. CSE 436 Software Engineering Workshop
Changing Nature of Software [Pressman]
• Open source
– OSI
– Free Software
• Free = frei, nicht umsonst
– BSD
• Decisions based on open source projects
– Can it be used?
– How does it impact the project?
– How does it affect the cost?
– How does it help maintenance?
• Copyright (copyleft) and patent protection
issues
9. CSE 436 Software Engineering Workshop
Software Evolution
• Continuing change and growth
– What works now will be expected to do more
tomorrow
– Redesign seems expensive
• Increasing complexity
– Changes often don’t fit into seminal software vision
– Entropy is unavoidable
• Legacy systems are unavoidable
– Monolithic systems are problematic
– Old languages are still very much in use
• COBOL, Fortran
• JOVIAL
10. CSE 436 Software Engineering Workshop
Management Myths [Pressman]
• We already have standards and procedures for building
software; isn’t that enough?
– How widely used is it?
– How relevant to the team?
– How useful to the project?
• If we’re behind schedule, we’ll just add more
programmers to catch up
– “Adding people to a late project makes it later” [Brooks]
– Ramp-up time
– Interference
• If I outsource a project, I can just relax
– Management issues are much more difficult, and if not
understood, will sink the project
11. CSE 436 Software Engineering Workshop
Customer Myths [Pressman]
• A general statement of work is sufficient to kick
off the project, and we can fill in the details later
– Loosey-goosey
– Nonlinear effect of added requirements: O(n) added
text does not make for O(n) added work
• Requirements can change, and that’s OK
because software is so flexible
– See above
– Most software project failures can be traced to
inadequacy of requirement specifications
12. CSE 436 Software Engineering Workshop
Software Engineers’ Myths [Pressman]
• Once the program is written, I’m done
– Between 60-80% of effort expended after delivery
• Until the program is written, quality is uncertain
– Formal design reviews
– Formal code reviews
– Test-first approaches
– Prototyping to verify design and structure
– Prototyping to validate requirements
• The only deliverable is the program itself
– Lots of documentation: installation guides, usage
guides, maintenance guides, API defintions and
examples
13. CSE 436 Software Engineering Workshop
Software Engineers’ Myths [Pressman]
• Documentation is Software-Engineering busy
work
– Focus is on quality, not quantity
– Documentation can be hard for engineers to write,
just as C++ may be difficult for poets.
– Conserve energy: documented code can serve as a
basis for useful documentation
• JavaDoc
• Doxygen
