On Tue, 28 Jun 2005, Greg Woodhouse wrote:
I'm not sure that everyone is familiar with the concept of a life cycle model. Software development is traditionally divided into a number of phases: 1. requirements analysis 2. design 3. coding 4. documentation 5. testing 6. maintenance
Validation/Verification is another process in the Principles. Check http://www.swebok.org for the references to the principles, the standards and their application if information systems engineering. In about 1985 at the MUG Meeting in New Orleans there was extensive discussion of these models about the time of the start of the IEEE-CS/JTC1 SC7 standarsd effort; the latest discussion realted to M was at the 1998 Seattle MDC meeting when Leonard Tripp presented these ideas. The WF LCM by that time had long been recognized as outdated in many, if not most, cases. Active debate within the M community of these ideas will be beneficial.
(Of course, this list could be elaborated/expanded.) Life cycle has to do with the way these various phases flow together. In a traditional waterfall model, each phase follows the previous one in sequence. First, the requirements must be defined (and documented). Next, a design based on those requirements is developed. The system is then implemented (coded) and tested. Finally, there is an ongoing process of maintenance. The waterfall model is definitely out of fashion (but in practice, real projects often do use this model). There are alternives, including an iterative model in which 3 or 5 flows back to 2 (possibly 1), and the software is developed through a process of successive refinement. In many cases, phase 1 (requirements analysis) is considered a "one-time" process, and requirements are considered to be known and fixed throughout the life cycle. In other models, requirements analysis is also considered an ongoing process that is an integral part of the cycle. This is an important aspect of the rapid prototyping model, in which small pieces of functional (or, at least running) software are developed and put into the hands of the users. Requirements can then be further elaborated based on the prototypes, developers can elaborate and refine their design, or even completely change the basic design. For example, a user interface (UI) prototype may be built for no reason other than to demonstrate the product's UI. The actual implementation (code) may not be suitable for the finished product, even if the UI remains the same. Other alternatives exist, sometimes differing in small ways and sometimes in more substantial ways from others. For example, the Rational Unified Process is based on a model it calls iterative. Though I don't hear this term as much these days, the waterfall model adapted to a series of phases of expanding scope is sometimes called a "spiral model". === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
