Re: [Hardhats-members] Life cycle models
I assume that by ACT you mean activity? This is interesting because it's a case in which I find my instinct and intuition at odds. My basic instinct as a developer is to break it up into a (possibly cyclic) sequence of (timed?) events. My intuition, on the other hand, is that on the semantic (or even ontological) level, it's a basic concept, and how I might implement an activity in a real system actual reflects my knowledge about activities. And I have to ask: How do you see Deming's ideas being applied to medicine? === Gregory Woodhouse [EMAIL PROTECTED] The policy of being too cautious is the greatest risk of all. --Jawaharlal Nehru On Jun 28, 2005, at 6:37 PM, 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 --- 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=7477alloc_id=16492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Life cycle models
With respect to the term Life Cycle Model we must remember that we are speaking of the representation of the processes and activities that will lead, over the lifetime of the envisioned system, to the trajectory of system configurations. There will be the general form of processes and activities applicable to the general model, like Rapid Prototyping (e. g. as depicted in ASTM E-1340) to which will be added specific details related to the specific system and enterprise being considered. The generalities for a system in the health information domain will have concepts and functions that cross numerous specific enterprises and specialty disciplines which will then be conditionmed by the detail applicable to the individual enterprise. Much of this conceptual detail can be reflected in the conceptual content standards and referenced in the Life Cycle Model documentation (e.g. IEEE 1362, 830, 1058) that are associated with the Zachman Framework concepts applied to the system of interest. For VistA, a general template document triad can be prepared that can be then tailored for the specific system and project of interest to a given health information architecture. In working with the health professional specialty disciplines, the information system engineers involved have the ability to convey to these specialties the magnitude of the effort involved (which may include business process re-engineering) that is frequently not even comprehended; many may think the effort is the same as buying a computer box of the shelf from the local electronic store. So the recognition of the Life Cycle Model and its implications is critical and something both the Infoirmation systems folks and the health specialty disciplines both need to know with lots of common ground. RP LCM is most useful to (but not unique to) healthcare because of the rapid evolution of the underlying knowledge (e. g. Genomics, Proteomics, Metabolomics), terms VistA is still trying to cath up with. For VistA education in the Common Ground is key to how benefiiciary Acquirers will be able to work synergistically with the Suppliers who will enable them make it all work. Thus WorldVistA must have closely communicating Project teams and Educational Programs that will set the stage for what the Supplier organizations (e.g. VSA) will do so that these organizations can realize their essential contribution to the System Life Cycle. I hope that this wasnt too long. On Wed, 29 Jun 2005, Gregory Woodhouse wrote: I assume that by ACT you mean activity? This is interesting because it's a case in which I find my instinct and intuition at odds. My basic instinct as a developer is to break it up into a (possibly cyclic) sequence of (timed?) events. My intuition, on the other hand, is that on the semantic (or even ontological) level, it's a basic concept, and how I might implement an activity in a real system actual reflects my knowledge about activities. The Key is joint work of information systems engineers (ISE) with the health specialty disciplines (HSD)throughout the System Life Cycle (SLC). And I have to ask: How do you see Deming's ideas being applied to medicine? Deming's ideas affect both the conceptual content (HSD) and the implemented content (ISE) that result in an effective system behavior that positively supports the measured outcome of the healthcare enterprise. Health service professional disciplines will be involved in the measurement process. Thes esteps are all part of the healthcare business process. === Gregory Woodhouse [EMAIL PROTECTED] The policy of being too cautious is the greatest risk of all. --Jawaharlal Nehru On Jun 28, 2005, at 6:37 PM, 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 --- 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=7477alloc_id=16492op=click
RE: [Hardhats-members] Life cycle models
Gregory Woodhouse said: I assume that by ACT you mean activity? Yes - ACT essentially means build the widget. This is interesting because it's a case in which I find my instinct and intuition at odds. My basic instinct as a developer is to break it up into a (possibly cyclic) sequence of (timed?) events. My intuition, on the other hand, is that on the semantic (or even ontological) level, it's a basic concept, and how I might implement an activity in a real system actual reflects my knowledge about activities. This process grew out of Shewhart's work for Bell Lab in the 20's. The widget was the old rotary telephone. Shewhart wanted to reduce variation so that a product wouldn't require replacement. In this century, I have seen rotary phones installed over 40 years ago, and work the same way they did the first day on the job. My latest purchase of electronic version is malfunctioning after 36 months. Would I go back? No! However, in Shewhart's time every $ spent on replacement came off the bottom line. Here was the (pre computer) origin of the control chart, and analysis of variance, commonly used in today's quality programs. And I have to ask: How do you see Deming's ideas being applied to medicine? Any number examples com to mind. However, one that recently played out on this list discussing errors (CHECK): http://www.wired.com/news/medtech/0,1286,67639,00.html?tw=wn_tophead_6 Brent James, M.D. has made a science of quality medical care dating back to the 80's. I have (FileMan) data dating back to 1993 on A1c and diabetes management. FileMan is a great facilitator of the Deming method. thurman === Gregory Woodhouse [EMAIL PROTECTED] The policy of being too cautious is the greatest risk of all. --Jawaharlal Nehru On Jun 28, 2005, at 6:37 PM, 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 originator 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 persistence 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 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Web casts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=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=7477alloc_id=16492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Life cycle models
It's not too long, perhaps a bit confusing because I'm not familiar with all the listed standards, but that's a different matter. I know very well what is meant by the term life cycle, and I should perhaps clarify that when I speak of implementation, I am referring to implementation of support tools. From a modeling perspective, it does seem sensible, though, to inquire as to what we mean by life cycle because it does directly influence how we design tools, represent concepts, and encode knowledge about a life cycle model so that the tool can make use of that knowledge in a meaningful way. Are we talking past eachother? --- A. Forrey [EMAIL PROTECTED] wrote: With respect to the term Life Cycle Model we must remember that we are speaking of the representation of the processes and activities that will lead, over the lifetime of the envisioned system, to the trajectory of system configurations. There will be the general form of processes and activities applicable to the general model, like Rapid Prototyping (e. g. as depicted in ASTM E-1340) to which will be added specific details related to the specific system and enterprise being considered. The generalities for a system in the health information domain will have concepts and functions that cross numerous specific enterprises and specialty disciplines which will then be conditionmed by the detail applicable to the individual enterprise. Much of this conceptual detail can be reflected in the conceptual content standards and referenced in the Life Cycle Model documentation (e.g. IEEE 1362, 830, 1058) that are associated with the Zachman Framework concepts applied to the system of interest. For VistA, a general template document triad can be prepared that can be then tailored for the specific system and project of interest to a given health information architecture. In working with the health professional specialty disciplines, the information system engineers involved have the ability to convey to these specialties the magnitude of the effort involved (which may include business process re-engineering) that is frequently not even comprehended; many may think the effort is the same as buying a computer box of the shelf from the local electronic store. So the recognition of the Life Cycle Model and its implications is critical and something both the Infoirmation systems folks and the health specialty disciplines both need to know with lots of common ground. RP LCM is most useful to (but not unique to) healthcare because of the rapid evolution of the underlying knowledge (e. g. Genomics, Proteomics, Metabolomics), terms VistA is still trying to cath up with. For VistA education in the Common Ground is key to how benefiiciary Acquirers will be able to work synergistically with the Suppliers who will enable them make it all work. Thus WorldVistA must have closely communicating Project teams and Educational Programs that will set the stage for what the Supplier organizations (e.g. VSA) will do so that these organizations can realize their essential contribution to the System Life Cycle. I hope that this wasnt too long. On Wed, 29 Jun 2005, Gregory Woodhouse wrote: I assume that by ACT you mean activity? This is interesting because it's a case in which I find my instinct and intuition at odds. My basic instinct as a developer is to break it up into a (possibly cyclic) sequence of (timed?) events. My intuition, on the other hand, is that on the semantic (or even ontological) level, it's a basic concept, and how I might implement an activity in a real system actual reflects my knowledge about activities. The Key is joint work of information systems engineers (ISE) with the health specialty disciplines (HSD)throughout the System Life Cycle (SLC). And I have to ask: How do you see Deming's ideas being applied to medicine? Deming's ideas affect both the conceptual content (HSD) and the implemented content (ISE) that result in an effective system behavior that positively supports the measured outcome of the healthcare enterprise. Health service professional disciplines will be involved in the measurement process. Thes esteps are all part of the healthcare business process. === Gregory Woodhouse [EMAIL PROTECTED] The policy of being too cautious is the greatest risk of all. --Jawaharlal Nehru On Jun 28, 2005, at 6:37 PM, 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.
Re: [Hardhats-members] Life cycle models
On Wed, 29 Jun 2005, Greg Woodhouse wrote: It's not too long, perhaps a bit confusing because I'm not familiar with all the listed standards, but that's a different matter. I know very well what is meant by the term life cycle, and I should perhaps clarify that when I speak of implementation, I am referring to implementation of support tools. I inserted that discussion because this dialog is applicable to a wider audience, one member of who I spoke with yesterday. Members of the full audience are not always familiar with many of the key concepts or the nature of aspects of the standards process but we need to reach them and I am pursuing this line of thought with Rick Marhall with respect to WV's activities. While that is going on we, here on the Hardhats forum need to get our collegues well oriented to the full field of discussion so that it can be carried forward into the various other forums that will reach the needed other participants. I think that the discussion of the application of RP (or its variants) or other LCMs to not only VistA projects but also those in other subject domains than healthcare where M may be used in concert with numerous other components of an enterprise information domain. We should envision the discussion at various levels as M programmers rapidly get into details that seem intuitively obvious but are not familiar to those outside that subject area. Its natural but the M Community is open and eager to relate its capabilites to other technolgies and components. I find the same propensity true of clinical laboratorians with respect to their discipline as it is just natural. but it does poiunt out how we must work at altering our horizon to get at the intrinsic problem domain. From a modeling perspective, it does seem sensible, though, to inquire as to what we mean by life cycle because it does directly influence how we design tools, represent concepts, and encode knowledge about a life cycle model so that the tool can make use of that knowledge in a meaningful way. I would hope that WV will have a specific Project team on Infrastructure/Tools that can establish close liaison with the VA's groups working in this area. That could benefit both organizations and lead to an evolving tools library that could be easily applied to rapidly evolving conceptual content leading to truly effective and robust system behavior for end users. This tool set could enable the HealthePeople vision of Demetriades, Kolodner, and Christopherson in ways that perhaps they hadnt yet realized. Are we talking past eachother? Nope! As is natural, we each just have different perpsectives even though we have much common ground. --- A. Forrey [EMAIL PROTECTED] wrote: With respect to the term Life Cycle Model we must remember that we are speaking of the representation of the processes and activities that will lead, over the lifetime of the envisioned system, to the trajectory of system configurations. There will be the general form of processes and activities applicable to the general model, like Rapid Prototyping (e. g. as depicted in ASTM E-1340) to which will be added specific details related to the specific system and enterprise being considered. The generalities for a system in the health information domain will have concepts and functions that cross numerous specific enterprises and specialty disciplines which will then be conditionmed by the detail applicable to the individual enterprise. Much of this conceptual detail can be reflected in the conceptual content standards and referenced in the Life Cycle Model documentation (e.g. IEEE 1362, 830, 1058) that are associated with the Zachman Framework concepts applied to the system of interest. For VistA, a general template document triad can be prepared that can be then tailored for the specific system and project of interest to a given health information architecture. In working with the health professional specialty disciplines, the information system engineers involved have the ability to convey to these specialties the magnitude of the effort involved (which may include business process re-engineering) that is frequently not even comprehended; many may think the effort is the same as buying a computer box of the shelf from the local electronic store. So the recognition of the Life Cycle Model and its implications is critical and something both the Infoirmation systems folks and the health specialty disciplines both need to know with lots of common ground. RP LCM is most useful to (but not unique to) healthcare because of the rapid evolution of the underlying knowledge (e. g. Genomics, Proteomics, Metabolomics), terms VistA is still trying to cath up with. For VistA education in the Common Ground is key to how benefiiciary Acquirers will be able to work synergistically with the Suppliers who will enable them make it all work. Thus WorldVistA must have closely communicating Project teams and Educational
RE: [Hardhats-members] Life cycle models
Thurman wrote: Gregory Woodhouse said: I assume that by ACT you mean activity? Yes - ACT essentially means build the widget. That's not how I read the reference you gave at http://www.balancedscorecard.org/bkgd/pdca.html quote * PLAN: Design or revise business process components to improve results * DO: Implement the plan and measure its performance * CHECK: Assess the measurements and report the results to decision makers * ACT: Decide on changes needed to improve the process /quote build the widget would be in the second step DO. The steps CHECK and ACT are all about improving the widget and the process of making it. --- 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=7477alloc_id=16492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Life cycle models
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
RE: [Hardhats-members] Life cycle models
Oops! You are CORRECT. I'm not an expert - just a devotee. A better explanation below: Act to implement changes on a larger scale if the experiment is successful. This means making the changes a routine part of your activity. Also Act to involve other persons (other departments, suppliers, or customers) affected by the changes and whose cooperation you need to implement them on a larger scale, or those who may simply benefit from what you have learned (you may, of course, already have involved these people in the Do or trial stage). Better link: http://www.hci.com.au/hcisite2/toolkit/pdcacycl.htm Deming, who got his start in the US census bureau is also known for his popular pronoucement: In God we trust. All others must bring data. thurman -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Jim Self Sent: Wednesday, June 29, 2005 2:38 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Life cycle models Thurman wrote: Gregory Woodhouse said: I assume that by ACT you mean activity? Yes - ACT essentially means build the widget. That's not how I read the reference you gave at http://www.balancedscorecard.org/bkgd/pdca.html quote * PLAN: Design or revise business process components to improve results * DO: Implement the plan and measure its performance * CHECK: Assess the measurements and report the results to decision makers * ACT: Decide on changes needed to improve the process /quote build the widget would be in the second step DO. The steps CHECK and ACT are all about improving the widget and the process of making it. --- 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=7477alloc_id=16492op=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=7477alloc_id=16492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Life cycle models
-Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Jim Self Sent: Wednesday, June 29, 2005 3:03 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Life cycle models Agree with the concepts. My interest here was the fact that Deming's best work involved the organization and use of data - a real strength of computers. I also found it interesting that this basis of computer strength seemed to have some parallel with the PDCA. This is not the first exposure of my naiveté in programming. thurman 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. --- 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_idt77alloc_id492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Life cycle models
I know this is a caricature, but I keep thinking of, If you raised your chair 1 centimeter, then over the course of a year you could save 45 minutes on time spent standing up to walk to the water cooler. Performance based management is great, but it begs the question of what we are really managing. --- Thurman Pedigo [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Jim Self Sent: Wednesday, June 29, 2005 3:03 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Life cycle models Agree with the concepts. My interest here was the fact that Deming's best work involved the organization and use of data - a real strength of computers. I also found it interesting that this basis of computer strength seemed to have some parallel with the PDCA. This is not the first exposure of my naiveté in programming. thurman 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. --- 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_idt77alloc_id492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members === 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=7477alloc_id=16492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Life cycle models
Excellent caricature. Deming was a great fan of usability. I will interject my bias on efficiency: 1. Efficiency=Quality/Cost 2. Quality = design performance + satisfaction Effeciency isn't a rush job as many assume - but cost effective usability. thurman -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Wednesday, June 29, 2005 5:13 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Life cycle models I know this is a caricature, but I keep thinking of, If you raised your chair 1 centimeter, then over the course of a year you could save 45 minutes on time spent standing up to walk to the water cooler. Performance based management is great, but it begs the question of what we are really managing. --- Thurman Pedigo [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Jim Self Sent: Wednesday, June 29, 2005 3:03 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Life cycle models Agree with the concepts. My interest here was the fact that Deming's best work involved the organization and use of data - a real strength of computers. I also found it interesting that this basis of computer strength seemed to have some parallel with the PDCA. This is not the first exposure of my naiveté in programming. thurman 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. --- 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_idt77alloc_id492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members === 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=7477alloc_id=16492op=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_idt77alloc_id492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
[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. === 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=7477alloc_id=16492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Life cycle models
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=7477alloc_id=16492op=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=7477alloc_id=16492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Life cycle models
Yes...I thought about expanding this list, but wanted to keep it simple. In retrospect, I think you are right that this is an element that I should have included. --- A. Forrey [EMAIL PROTECTED] wrote: 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. === 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=7477alloc_id=16492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Life cycle models
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. === 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=7477alloc_id=16492op=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=7477alloc_id=16492op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
