--- a/unix-phil.ms	Sat Feb 13 11:37:50 2010 +0100
+++ b/unix-phil.ms	Thu Feb 18 11:24:36 2010 +0100
@@ -21,7 +21,7 @@
 .ds .] ]
 .\"----------------------------------------
 .TL
-Why the Unix Philosophy matters
+Why the Unix Philosophy still matters
 .AU
 markus schnalke <meillo@marmaro.de>
 .AB
@@ -108,6 +108,7 @@
 This only underlines what the Unix Philosophy is:
 A retrospective view on the main concepts of Unix software;
 especially those that were sucessful and unique to Unix.
+.\" really?
 .PP
 Before we will have a look at concrete concepts,
 we discuss why software design is important
@@ -115,53 +116,89 @@
 
 
 .NH 1
-Importance of software design
+Importance of software design in general
 .LP
 Why should we design software at all?
-It is general knowledge, that a bad plan is better than no plan.
-As stated earlier in this document, the process of building a software
-means going from an idea to a release.
-The development process tells how to get from the idea to the release.
-Software design is the shape of the built software.
-This means, that different designs of a software would be different target points to go to.
-Thus, the design of a software defines the global direction the development goes.
+It is general knowledge, that even a bad plan is better than no plan.
+Ignoring software design is programming without a plan.
+This will lead pretty sure to horrible results.
+.PP
+The design of a software is its internal and external shape.
+The design talked about here has nothing to do with visual appearance.
+If we see a program as a car, then its color is of no matter.
+Its design would be the car's size, its shape, the number and position of doors,
+the ratio of passenger and cargo transport, and so forth.
 .PP
-It is not enough that the released software offers all requested functionality.
-It is a misbelief that only function matters.
-Building a software the first time is only a small part of the overall work.
-The larger part begins when the software is released for the first time
-\(en maintainance and extending work..
-This part soon covers more time than the time which was needed to build the software the first time.
-.\" cf. brooks?
+A software's design is about quality properties.
+Each of the cars may be able to drive from A to B,
+but it depends on its properties whether it is a good car for passenger transport or not.
+It also depends on its properties if it is a good choice for a rough mountain area.
+.PP
+Requirements to a software are twofold: functional and non-functional.
+Functional requirements are easier to define and to verify.
+They are directly the software's functions.
+Functional requirements are the reason why software gets written.
+Someone has a problem and needs a tool to solve it.
+Being able to solve the problem is the main functional requirement.
+It is the driving force behind all programming effort.
+.PP
+On the other hand, there are also non-functional requirements.
+They are called \fIquality\fP requirements, too.
+The quality of a software is about properties that are not directly related to
+the software's basic functions.
+Quality aspects are about the properties that are overlooked at first sight.
 .PP
-The extendability and maitainability of a software highly depends on its design.
-Good design eases these tasks much.
-Bad design, in contrast, requires much more effort for maintaining and
-extending the software.
-Developers should, for their own best, have maintainability and extendability in mind
-when they design the software.
+Quality is of few matter when the software gets initially built,
+but it will be of matter in usage and maintainance of the software.
+A short-sighted might see in developing a software mainly building something up.
+Reality shows, that building the software the first time is only a small amount
+of the overall work.
+Bug fixing, extending, rebuiling of parts \(en short: maintainance work \(en
+does soon take over the major part of the time spent on a software.
+Not to forget the usage of the software.
+These processes are highly influenced by the software's quality.
+Thus, quality should never be neglected.
+The problem is that you hardly ``stumble over'' bad quality during the first build,
+but this is the time when you should care about good quality most.
+.PP
+Software design is not about the basic function of a software;
+this requirement will get satisfied anyway, as it is the main driving force behind the development.
+Software design is about quality aspects of the software.
+Good design will lead to good quality, bad design to bad quality.
+The primary functions of the software will be affected modestly by bad quality,
+but good quality can provide a lot of additional gain from the software,
+even at places where one never expected it.
 .PP
-Users of the software, in contrast, do not care about maintainability and extendability,
-at least not directly.
-They care about usability and flexibility.
-They want the software to directly solve their problems.
-They want to be able to to use all its functions if they learned a few of them.
-They want to use the software for similar tasks.
-Software is successful if users enjoy using it.
-Good software design can offer great flexibility and usability.
-.PP
-Good design matters for developers \fIand\fP for users.
-Hence both groups should care about good software design.
-Bad design limits the software in some way.
-It may still provide all requested function, but it will have worse quality,
-and thus require more work effort for developers or frustrate users.
-.PP
-Good software design is to the implementation like data structures are to algorithms
-\(en if you get the former right, then you do not need to care about the latter,
-it will simply go the right way.
-.\" cf. ??? ``good data, bad algos''
-
-
+The ISO/IEC 9126-1 standard, part 1,
+.[
+%I International Organization for Standarization
+%T ISO Standard 9126: Software Engineering \(en Product Quality, part 1
+%C Geneve
+%D 2001
+.]
+defines the quality model as consisting out of:
+.IP \(bu
+.I Functionality
+(suitability, accuracy, inter\%operability, security)
+.IP \(bu
+.I Reliability
+(maturity, fault tolerance, recoverability)
+.IP \(bu
+.I Usability
+(understandability, learnability, operability, attractiveness)
+.IP \(bu
+.I Efficiency
+(time behaviour, resource utilisation)
+.IP \(bu
+.I Maintainability
+(analysability, changeability, stability, testability)
+.IP \(bu
+.I Portability
+(adaptability, installability, co-existence, replaceability)
+.LP
+These goals are parts of a software's design.
+Good design can give these properties to a software,
+bad designed software will miss them.
 
 
 .NH 1