14-11-2012, 05:46 PM
Conventional Software Management
[attachment=39501]
Introduction
Three analyses of the state of the software engineering industry as of mid 1990s yielded:
Software Development is still highly unpredictable
Only about 10% of software projects are delivered successfully on time, within initial budget, and meets user requirements
The management discipline is more of a discriminator in success or failure than are technology advances
The level of software scrap and rework is indicative of an immature process.
Behold the magnitude of the software problem and current norms!
But is the ‘theory’ bad? “Practice bad?” Both?
Let’s consider….
The Waterfall Model
Recognize that there are numerous variations of the ‘waterfall model.’
Tailored to many diverse environments
The ‘theory’ behind the waterfall model – good
Oftentimes ignored in the ‘practice’
The ‘practice’ – some good; some poor
Waterfall – TheorySuggested Changes ‘Then’ and ‘Now’
Items 1 and 4 are still valid.
1) Use a test team not involved in the development of the system – at least for testing other than ‘unit testing…’
4) Employ final checkout on target computer….
Item 2 (software inspections) – good years ago, but modern development environments obviate this need. Many code analyzers, optimizing compilers, static and dynamic analyzers are available to automatically assist…
May still yield good results – but not for significant problems! Stylistic!
Item 3 (testing every path) is impossible. Very difficult with distributed systems, reusable components (necessary?), and other factors…. (aspects)
In Practice
Characteristics of Conventional Process – as it has been applied (in general)
Projects not delivered on-time, not within initial budget, and rarely met user requirements
Projects frequently had:
1. Protracted integration and late design breakage
2. Late risk resolution
3. Requirements-driven functional decomposition
4. Adversarial stakeholder relationships
5. Focus on documents and review meetings
Let’s look at these five major problems…