Brontekst bekijken van Taxonomy/1. Quality/07. Development

<noinclude>{{Taxonomy/Contents}}</noinclude>
{{Taxonomy/Intro|The [[Taxonomy/1._Quality/1._Rationality|Rationality Square]] and [[Taxonomy/1._Quality/4._Correctness_Theorems|Correctness Theorem]] give rise to a taxonomy that allows enginering issues to be distinguished, ordered, and classiefied, including those where [[Taxonomy/1._Quality/6._Software|Software]] is envolved. Once we understand what it means that an artefact is correct, we can investigate how actually to '''make''' them.}}

Let us start with the question how {{*|thing}}s come into existence at all. Theoretically, there are three different ways.{{Classification|Coming into existence|
*creation
*evolution
*construction}}
; Creation : Someone simply ''makes'' the it. We do not know whether there has ever been a {{*|specification}}, let alone a [[Taxonomy/1._Quality/4._Correctness_Theorems|Correctness Theorem]]. The thing just has the properties it has, and it may be difficult to detect them. (Examples: Heaven and Earth, Windows). A result of creation hardly deserves the label "{{*|artefact}}". If we like it, we can use it at our own responsibility. As soon as we want to rely on it and be sure, we need to apply {{*|reverse engineering}} to find a [[Taxonomy/1._Quality/4._Correctness_Theorems|Correctness Theorem]] that relates a {{*|structure}} obtained by {{*|decomposition}} to our needs in terms of a {{*|specification}}. We do not need to do this for ''all'' its properties, only for those we are interested in. 
; Construction ("Rational design") : Design along the cornerstones of the [[Taxonomy/1._Quality/1._Rationality|Rationality Square]]: Write down the {{*|specification}} of the desired {{*|property|properties}} (a [[Taxonomy/supplement/design model|design model]]) and find a [[Taxonomy/1._Quality/4._Correctness_Theorems|Correctness Theorem]] that links this specifications to parts that can be obtained. Sometimes we may find that specification and blueprint are not accessible. In that case, like with created things, we must apply {{*|reverse engineering}}, and we do not need to do this for ''all'' its properties, only for those we are interested in. If, for example, we want to use an old computer as a stand to place a monitor at the right height, as it often happens, we only need a correctness theorem about the computer's thickness and mechanical stability. In other words: we build a "[[Taxonomy/supplement/verification model|verification model]]" which is much simpler than its original "[[Taxonomy/supplement/design model|design model]]".
; Evolution : An existing artefact is changed slightly; the result may be better with respect to some criteria. If the original artefact was covered by a [[Taxonomy/1._Quality/4._Correctness_Theorems|Correctness Theorem]] (which usually is not the case), this theorem should be changed correspondingly.

In practise, we usually have a mix of these three:

; Development : In an iterative process, existing {{*|artefact}}s are changed slightly, combined with each other, while newly constructed artefacts may be added. {{*|reverse engineering}} of existing artefacts can be involved in this process. In a rational development process one starts with a {{*|specification}} that is a first, often idealised, approximation of the desired {{*|property|properties}}, and weakens it until a [[Taxonomy/1._Quality/4._Correctness_Theorems|Correctness Theorem]] for a realisable {{*|artefact}} can be proved. See also: [[Taxonomy/2._Methodology/3._Non-Monotonic Refinement]].

In that mix it is easy to get mixed up and to focus on the wrong sub-problem. It is essential always to understand what the focus is at any moment of such a process and who is responsible for what.

== Canonical activities ==
Rational development involves a mix of the '''canonical activities''' defined by the [[Taxonomy/1._Quality/1._Rationality|Rationality Square]], and it is useful to understand each of them separately. Even if they are done by the same person, they require different skills.{{Classification|Canonical development activities|
*specify
*implement
**design
**realise}} 
; Specify : Find out what one wants (the desired {{*|property|properties}}) and put it on paper in terms of a {{*|specification}}. In rare cases this is done from scratch (''"Get some men to the moon and safely back again!"''). More often, an existing specification is adapted. When one knows only vaguely what one wants, explation of [[Taxonomy/supplement/prototype|prototype]]s is unavoidable. Therefore, the definitive specifications of most artefacts emerge together with the corresponding [[Taxonomy/1._Quality/4._Correctness_Theorems|Correctness Theorem]]. Nevertheless it is useful to distinguish the act of specifying from considerations around the specific structure of one implementation of the specification.
; Implement : For a given {{*|specification}}, make an implementation. The customer is usually not interested in how this is achieved but may very well be interested in a [[Taxonomy/1._Quality/4._Correctness_Theorems|Correctness Theorem]] accompanying the artefact.
; Design : The mathematical part of implementing: for a given {{*|specification}}, find a blueprint that satisfies it. This may require {{*|reverse engineering}} of some given physical components. It involves {{*|decomposition}} and [[Taxonomy/supplement/abstraction|abstraction]]. The designer is the one who has to invent a correctness theorem, which links the world of the providers of the parts of the artefact under dscussion to the requirements of the customer. The design is correct if the theorem can be proved. The artefact will work as desired if that theorem reflects what the customer needs and if the system is realised conforming to that theorem .
; Realise : The physical part of implementing: actually ''make'' an artefact from that blueprint. Remember that if the blueprint is a computer program, realisation is trivial: it consists of compiling the program and loading it into the computer's working memory.

== Stakeholders ==
{{Classification|Stakeholders|
*customer
*designer
*provider
*domain expert}}
; Customer : The customer is interested in the bottom right of the [[Taxonomy/1._Quality/1._Rationality|Rationality Square]] and in the right side of the [[Taxonomy/1._Quality/4._Correctness_Theorems|Correctness Theorem]]: she is the one who wants an {{*|artefact}} with certain {{*|property|properties}} for some purpose and is willing to pay for it. Usually, the artefact should not be more expensive than necessary, but often the customer has no idea whether the price to be paid is justified. A bigger problem can be that the customer has only vague ideas over the purpose of the artefact (“my firm ought do something with the Internet”), or even a wrong understanding of the problem (“I want exactly such a system as my neighbours have”). The customer needs designer and domain expert as partners; together they can arrive at a reasonable problem definition and a suitable solution for a fair price. The customer may sign a contract around a {{*|specification}} of the artefact to be built, but is usually not interested in its {{*|structure}}, viz. the {{*|blueprint}} ("...if ot only works"). The customer ought to be a professional with respect to the problem to be solved but needs not be a system engineer nor a domain expert nor to have any idea about possible solutions.
; Designer : The designer is interested in the top left of the [[Taxonomy/1._Quality/1._Rationality|Rationality Square]], als she has to invent a [[Taxonomy/1._Quality/4._Correctness_Theorems|Correctness Theorem]] the left side of which can be realised or, in other words, has to select the necessary parts and to describe how to build a system from them. Designers can be notoriously uninterested in what the designed artefact actually ''does'' in reality. Nevertheless, the designer has to find out what the customer expects. The designer also needs expert knowledge about the available or obtainable parts from which systems can be constructed.
; Provider : Providers provide the parts the designer needs. They do not need to have any idea of the problem to be solved but need to be experts in the technologies on which the system is based, for example in programming languages, electronics, or mechanics.
; Domain expert : A domain expert for the [[Taxonomy/supplement/problem domain|problem domain]] is necessary if domain specific knowledge is required which customer and designer cannot be expected to have. More domain experts can be be necessary for the [[Taxonomy/supplement/solution domain|solution domain]] to help the designer with the parts from which the artefact is constructed.

It is not uncommon that one person or one group plays two or more of these rôles at the same time. This frequently is the cause of unsystematic thinking. Of course a designer may be his own customer, domain expert and/or provider, but when reasoning about a system one should take great care always to be aware of the four different standpoints. 

These different rôles can be distinguished at every level of system design, the designer of one level being the customer of the parts at the next lower level, where the providers take the rôle of part designers. In this paper we will consider one level only. The reader should understand that our considerations also hold at all other levels, possibly with respect to different technologies (for example microcode instead of programs), requiring different domain experts.