Thurman, The Deming cycle embodies some important concepts, but your breakdown of it for software development does not fit very well with my understanding.
In following the link below, it seems to me that the central element is the application of the concept of a feedback cycle to business pactices. That seems a very powerful idea and interestingly there is the acknowledgement that some phases of the overall cycle are complex enough to contain sub-cycles. This mention of "wheels with wheels" begins to touch on what I see as a fundamental inadequacy of non-recursive process models for describing software development. Given the ready availability of computing resources and the fact that computers are our most powerful tools for analyzing and solving complex problems, software development is essential problem solving behavior that can be applied to any abstract problem area - including software development. I routinely write software to help with the analysis of problems and to facilitate coding, documentation, testing. maintenance, etc. Many programs that I write are for my own use or for the use of other programmers. Some are used once and discarded, others become integral to our development environment or to our overall user interface or computing paradigm etc and stay in place for many years. Software development cycles can easily exist within all of the phases of the Deming cycle and for a simple application or well defined product, it seems to me that the major phases of software development could all well fit within the "DO" phase of the Deming cycle, at least from some management perspectives. Software maintenance does not seem to fit particularly well in the ACT phase - rather it would be in the spinoff of successive cycles of development and feedback at many levels. Software development (and problem solving in general) at the enterprise level would consist of many circles within circles. Thurman Pedigo wrote: >I have been watching this thread with a bit of nagging abstraction - then >recognized it. Presented is a modified technique of W. Edwards Deming - the >guy who taught the Japanese how to eat Detroit's lunch (in the 50's). >Shewhart was the originater in the 20's. A brief link: >http://www.balancedscorecard.org/bkgd/pdca.html >PLAN; DO; CHECK; ACT > >And broken down: >PLAN: > 1. requirements analysis > 2. design >DO: > 3. coding > 4. documentation >CHECK: > 5. testing >ACT: > 6. maintenance >And the cycle restarts. >> (Of course, this list could be elaborated/expanded.) > >Perhaps the post industrial era adds new challenges. However, the basic >concept of simplification and persistance have merits not met by the "throw >this away and build anew" philosophy that seems to invade our work. > >Unfortunately, we failed to appropriately integrate Deming with medicine. > >thurman > > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:hardhats- >> [EMAIL PROTECTED] On Behalf Of Greg Woodhouse >> Sent: Tuesday, June 28, 2005 9:57 AM >> To: Hardhats >> Subject: [Hardhats-members] Life cycle models >> >> 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 >> >> (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". --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- 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
