ECEN 5543 — Lecture 1 Notes — 08/29/2006
- Requirements engineering is a key problem for software development process
- “We know why projects fail, we know how to prevent thier failure — so why do they still fail” — Martin Cobb, Cobb’s Paradox
- Standish Report (can be viewed online)
- Challenged Projects — Delivered, but late or with reduced functionality 52.7%
- Impaired — Never Delivered 31.1%
- Successful — Delivered basically ontime with full functionality
- Success Factors — In order of impact — User Involvement, Executive Management Support, Clear statement of Requirements, realistic expectactions, smaller project milestones (iterative development)
- Requirements Volatility should be meaused and reported even if management does not specifically ask for it.
- In a timeline from the Tape Disk market, there was a large milestone marked “Miracle Happens Here”. This was taken very seriously in the project group. In this case, in order for the project to be succesful there had to be a technological break through. The project could proceed up to this point, but until R&D made thier breakthrough it would then stall. Example from Prof. Dameron, not report.
- Impaired Projects — in order of impact — incomplete requirements, lack of user involvement, lack of resources, unrealistic expectations
- What dos a software development process do for you?
- You get the info you need
- When you need it
- in a form that you can use
- Effective mangement environment allows itterations to work correctly, without interuption, breaks, lost resources, etc.
- UML diagramming vs. Making up your own diagramming is like drawing an electrical diagram and making up your own symbols.
Since all of the presentations and lectures are available online, my notes are probably going to be pretty sparse. However, if I put them online I will have access to them even if I don’t have my notebook handy.
For next lecture:
- Read Standish Report exerpt
- Read Unfinished Voyages (sorry for the crappy link, but I can’t find it on the Standish site)