drawings &


the human


software development







tree of knowledge
of good and bad

Software Developemnt Taxonomy

Copyright © Heinz Prantner 2008, 2009

last updated: May 09 2009

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 License.

"Every philosophical problem starts with 'I don't know'." Ludwig Wittgenstein

"The logic takes care for herself, we only have to watch how she does it." Ludwig Wittgenstein

Plate of 12 Categories, Immanuel Kant, Kritik der reinen Vernunft:

  Functions of Mind Categories
1 Common - Allgemeine Unity - Einheit
2 Particular - Besondere Multitude - Vielheit
3 Singular - Einzelne University - Allheit
4 Affirmative - Bejahende Reality - Realitaet
5 Negative - Verneinende Negation - Negation
6 Infinite - Unendliche Limitation - Limitation
7 Categorical - Kategorische Substance - Subsistenz
Inherence - Inhaerenz
8 Hypotetical - Hypothetische Causality - Kausalitaet
Dependence - Dependenz
9 Disjunctive - Disjunktive Community - Gemeinschaft
10 Problematic - Problematische Possibilty - Moeglichkeit
Impossibility - Unmoeglichkeit
11 Assertive - Assertorische Existence - Dasein
Nonexistence - Nichtsein
12 Indisputable - Apodiktische Necessity - Notwendigkeit
Chance - Zufaelligkeit

The 7 layers of the OSI model

Table of Contents


Software Development is the science and the art of the organization and movements of information. When it comes to implement new software or to analyse existing software it is not easy where to start with and what to look for. The following shall give us a guideline through the development phases and a generic template for the software development topics. Our daily comfort or discomfort strongly relate to the information architecture.

This is work in progress. Chapters vary in their extent.


car workshop, photo HP

In everything you do:

For SW development you need to:

SW Development is done in 5 phases:

Analysis starts with "I don't know.", "I don't understand.". Some get stucked here. Others may jump over. Others get lost in details. Analysis requires criteria to check against the matter to get an understanding.

Design is about how you present your thoughts to others. It may be blurry, funny, complicated, redundant, overloaded, not there, superficial, wrong. All of them are not good. Design should be clear and direct. Design requires structure for clearness.

Implementation is the deed, going beyond theory. Implementation requires style for liability.

Verification is to go beyond pure deed, bringing quality to the subject: it proves whether it is good or bad deed. Verification requires strength to reach high quality.

Integration brings all together. If the above steps were the letters in the alphabet, the integration would be the word, bringing sense and sound to the subject. Integration requires skill for ingenuity.

(§1) Architecture

Sol Lewitt - Modular Cube - Hallesches Ufer Berlin, photo HP

(§1.1) Network Architecture

(§1.1.1) Network Services

(§1.1.2) Networking Functions

(§1.1.3) Communication Protocol Specification

(§1.2) System Architecture

(§1.3) Software Architecture

Strategies and Drivers

Software Organization Topics

software model diagrams (according to uml)


environment system package platform board card
area script shell program component entity
task unit thread process procedure instruction
stream object module box container bus
interface link connection socket drive disk
host modem service server client proxy
gateway hub router switch rack shelf
table array structure transaction record set
class queue buffer vector map tree
iterator option origin destination argument key
id tag bit byte character word
string state alarm event primitive message
command request indication configuration confirmation acknowledgement
log trace file sector track volume
action activity terminal display screen monitor
computer controller handler device machine engine
calculator generator motor driver tester mirror
base floor desk world universe

(§1.3.3) Design Patterns

The design patterns from Gamma, Helm, Johnson and Vlissides are the creme of software development. For my own humble attempts on this topic see design patterns.

(§2) Requirements

Requirements purpose:

Requirements origins:

Requirements types:

Requirements record:

Requirement program status:

Requirement review state:

Requirement implementation state:

Requirements layers:

(§3) Analysis

(§4) Component Design

This chapter addresses the software layout within a software component regarding the design principles and design documentation topics.


Raul Walch, "Westfrucht/Porsche", 2007, Holz, ca. 500x200x130cm, Kunstsalon Berlin 2007, Foto HP

(§4.1) Major Software Component Design Principles

(§4.1.1) Task List

The enumeration of tasks (to do's) for the software component is crucial for the complete software development cycle (beginning with requirements and ending in test). For the component structure the task list provides the initial subdivision and grouping of elements.

(§4.1.2) Data Model

(§ Managed Objects

The data model identifies the data objects pertaining to the component. Each data objects (Managed Object) represents the system view of the known outside world, which may consist of human user input systems, user information devices, any other device, network interfaces, network peer elements, and the like. Each data object (managed object) has a generic set of attributes defined:

(§ Commands

Specify the list of user commands and command parameter applying to the object.

(§ Configuration

Specify the configuration parameter applying to the object.

(§ States

Specify the transient state parameter for the object.

(§ Events

Specify the events pertaining to the object

(§ Statistics

Specify the statistics parameter for the object.

(§4.1.3) Interfaces, Service Definitions

Interface, Service Message Types:

Interface, Service Categories:

(§4.1.4) Object Model, Software Structure, Task Assignment

(§ Software Structure Design Criteria

Software design criteria:

(§4.1.5) Relations and Dependencies

Specify the relations and dependencies of sub groups within the component.

(§4.2) Software Component Design Documentation

(§4.2.2) Task Descriptions

A component task object is similar to a class in object oriented languages. It is a protocol stack software component design principle and thus is independent of any programming language. A component task is defined by a list of attributes (given below) and is very useful for several purposes as shown hereby.

Why do we need component task objects?

Component task object types:

Component task object attributes:

plus eventually diagrams


(§4.2.3) State Descriptions

(§4.2.9) Technical Data

(§5) Feature Design

(§6) Test

Component Task Use Case Definition

Component Task Use Cases may be derived from:

Protocol Test Cases

Stress Cases

Test Case Definition

Each test case must relate to one use case.

Handle with care! Do not copy paste generate wrong information just because you are sooo in a hurry! Notice: There is exactly _one_ world, which will be still there in the next moment. So where to do you hurry? But if you create wrong information now, the same world will be messed up [just a little bit more than it was already] in the next moment. It is good that you read such text.

Test Case Header:
Mandatory Fields:

Optional Fields:

Requirements mapping overview:

(§7) Integration

If I think of a scale from less integrated to more integrated I would not know the criteria how to measure integration. If I think of what is best and most integrated within itself, how the big relates to the small, the heavy to the light, the protrusive to the embracing, active to passive, synthetic to the organic, integrated with outside others, room, space, urban architecture, people, sheeps, landscape and universe, then Henry Moore sculptures come in my mind as the perfect, perfect integration.

(§8) Software Administration


Defects are reported for a failure reltated to both:

Issue analysis may result in the following:

For issues relevant to the component the following shall be evaluated

Over time the following may be interesting for root cause analysis:

Based on the number of issues over time a quality state can be maintained per component task:





(§9) Project Management

(§10) Working Together

Welt der Schatten, Kunst der Suedsee - Ethnologisches Museum, Staatliche Museen zu Berlin, photo HP

Roles Overview


Find your role and know where you end and someone else begins.

Roles Definitions



Configuration Manager


Documentation Manager


Product Manager


Project Manager


Quality Assurance

The maintenance of a desired level of quality in a service or product, esp. by means of attention to every stage of the process of delivery or production.



For me perhaps the greatest joy is, while in the process of writing, I see and understand what belongs and fits together.

Vriginia Woolf


Business Developer


Technology Developer


Technical Writer


Subject - Concept - Object

Be receptive

Everything we encounter exists already within us as idea or conception we have for the matter. The real object relates to the conception we have for that subject and from the difference our emotions evolve.

Be clear on the subject to understand what the topic is about.

Be clear on the object, be sure to understand correctly what is said and meant by others.

Be clear on your concept and where are the differences to what comes in.

Be clear on your emotions evolving from this relation.

Be active

State your understanding of what is the matter, subject.

State your understanding of what you have been asked to do or what you want to be done.

Deliver what you have been asked for.

Be reflective

Reflect on the subject, concept, object.

Reflect on the output and go over it from the beginning if necessary.

Reflect on the reactions.

The software implementation is a reflection of what is around it

It may be that if you try to locate the problem in the software component implementation, that you miss the true root cause at all. The software component implementation with its structure and problems is a reflection of what is around the implementation: the software architecture, the software requirements, the software documents, the component tests, the component releases, the tools, the process, the development organization, project management, the management. If the structures around the software are broken then the software will be broken.

What we observe can be of one or more of the following major character types:

where each of them can be of low, medium or high degree.


Authority pulls responsibility. The part under authoritarian control is weakened and the authority over time is overloaded. This (system) architecture is doomed to break.

Authoritativeness is a result of the wish to be better than others. Authoritativeness also means to follow authority. Someone following authority will take the first chance to become authoritarian him-,herself.

We have seen that in life and in software. It does not work well.


We engage in formal activity to learn to distinguish between Right and Wrong. The formal activity relates to a subject which we have not mastered yet. Then the formal activitiy is a helpful utility. If the relation to the subject is lost, the activity becomes pure formalism without meaning and content. The formality then takes over and controls ourselves. We no longer control the activity and we do not learn to distinguish between right and wrong. We transition into puppets who rely on outside judgement and control.

Formalism is a result of declination of the matter.

We have seen that in life and in software. It does not work well.


Friendliness goes beyond the border of responsibility. You end up doing things which others are supposed to do. This may exhaust you over time and weaken others. If the responsibilites are not clear the system becomes instable and hard to maintain.

Friendliness is a result of affection.

We have seen that in life and in software. It does not work well.


Chaos is the absence of structure, the abuse of structures, the absence of names, the abuse of names.

Chaos is a result of fear and doubt.

We have seen that in life and in software. It does not work well.

If we want to get better software we have to clean up on these attributes. If we dont know what we need to do we at least know what not to do:

The qualities of a manager

Welt der Schatten, Kunst der Suedsee - Ethnologisches Museum, Staatliche Museen zu Berlin, photo HP

The qualities a manager should convey


People working together on a subject in group should have a solid base they can rely on.


A clear determination on what is us versus to what are the others.


A goal oriented, pragmatic, direct attitude towards challenges.

end of document