About the Site | What's New? | Disclaimer | Site Map | Fun Stuff
This is a very important question to consider and, unfortunately, it has been my experience that this is the one question that the practitioners of QA often fail to even ask, much less attempt to answer. In short, a discipline generally tries to look for and exploit regularities in the area of its expertise. We use our disciplines to develop theories to capture and summarize reality, to make predictions, and to guide further actions or research. We share strategies, including observation and experimentation techniques, as well as the statistical analysis of results. This allows the discipline to provide a foundation for practitioners. While there may be differences in focus, skill level, and maturity, we should not allow this to cause us to overlook similarities in assumptions, outlooks, and methods.
When proposing changes and solutions and various improvement initiatives, one has to set up and define the problem one is trying to solve and present criteria for evaluating the solution. Then you have to have some way of turning those abstract ideas into the practices of a concrete set of activities. In other words, you go from a set of basic assumptions and derive solutions that dictate how the various activities that make up a given discipline should occur. With that, when considering whether or not something is a discipline, you just need to consider if there are certain definable things that you have to do in order to be doing whatever you are promoting. All of our abstract concepts have to be capable of being reduced to practice, to be capable of being reinforced, to make the values therein something akin to a natural habit. We have to have a more concrete structure that leads us to practices that satisfy and embody the aforementioned values. We can often use our values to derive some principles of action and those principles will often guide the direction that our discipline goes. (If the values are too vague, they will often not lead to an easy derivation of principles.) The principles are important because they can help us choose between various alternatives meaning that we can choose alternatives that meet the principles more fully.
We ought to pay careful attention to situational details and let situational problem-solving- rather than compliance to standards-drive software process evolution. The question is: is that true? What things like the SEI CMM or the ISO or even IEEE attempt to do are provide a model of organizational structure that is capable of producing good software. Things like TQM even extend this to a more high-level organizational concern by looking at the entire context in which the process of software development is embedded. The concept of "software engineering" was put forth to suggest a framework for decomposing development into manageable stages or phases. The "process movement" then came along to focus on the procedural details of each stage/phase and how to define, measure, and modify them. The point is that all of this gradually speaks to the notion of a discipline. Consider the concept of methodology engineering, as just one example. Methodology engineering is a taxonomy to map methods to projects. What generally happens is that organizations in what is known as their "commercial-focused" stage rely on familiar practices as they are written down by someone else. Sometimes those familiar practices are changed incrementally and then those companies sometimes pass on that methodology to others by making it widely known as a case study or something similar, such as someone writing an article about it. This does not guarantee industry success but if the economic and commercial stakes are high enough and if the modified practices are viable enough, a "science" begins to form. If the science matures, it should contribute to commercial practice overall by developing theories that can be put to the test in the commercial arena. If this is successful, an engineering discipline emerges. (The key is that the success of the discipline comes not just from the principles but also from practical application/experimentation.)
For questions or comments on the site, contact Jeff Nyman.
The material on this site, unless stated otherwise, is considered Open Content
and is distributed under the GNU Free Documentation License.
GlobalTester, TechQA, Copyright © 2002 All Rights Reserved. (Labelled with ICRA)
