1.1 --- a/unix-phil.ms	Sat Feb 13 11:37:50 2010 +0100
     1.2 +++ b/unix-phil.ms	Thu Feb 18 11:24:36 2010 +0100
     1.3 @@ -21,7 +21,7 @@
     1.4  .ds .] ]
     1.5  .\"----------------------------------------
     1.6  .TL
     1.7 -Why the Unix Philosophy matters
     1.8 +Why the Unix Philosophy still matters
     1.9  .AU
    1.10  markus schnalke <meillo@marmaro.de>
    1.11  .AB
    1.12 @@ -108,6 +108,7 @@
    1.13  This only underlines what the Unix Philosophy is:
    1.14  A retrospective view on the main concepts of Unix software;
    1.15  especially those that were sucessful and unique to Unix.
    1.16 +.\" really?
    1.17  .PP
    1.18  Before we will have a look at concrete concepts,
    1.19  we discuss why software design is important
    1.20 @@ -115,53 +116,89 @@
    1.21  
    1.22  
    1.23  .NH 1
    1.24 -Importance of software design
    1.25 +Importance of software design in general
    1.26  .LP
    1.27  Why should we design software at all?
    1.28 -It is general knowledge, that a bad plan is better than no plan.
    1.29 -As stated earlier in this document, the process of building a software
    1.30 -means going from an idea to a release.
    1.31 -The development process tells how to get from the idea to the release.
    1.32 -Software design is the shape of the built software.
    1.33 -This means, that different designs of a software would be different target points to go to.
    1.34 -Thus, the design of a software defines the global direction the development goes.
    1.35 +It is general knowledge, that even a bad plan is better than no plan.
    1.36 +Ignoring software design is programming without a plan.
    1.37 +This will lead pretty sure to horrible results.
    1.38  .PP
    1.39 -It is not enough that the released software offers all requested functionality.
    1.40 -It is a misbelief that only function matters.
    1.41 -Building a software the first time is only a small part of the overall work.
    1.42 -The larger part begins when the software is released for the first time
    1.43 -\(en maintainance and extending work..
    1.44 -This part soon covers more time than the time which was needed to build the software the first time.
    1.45 -.\" cf. brooks?
    1.46 +The design of a software is its internal and external shape.
    1.47 +The design talked about here has nothing to do with visual appearance.
    1.48 +If we see a program as a car, then its color is of no matter.
    1.49 +Its design would be the car's size, its shape, the number and position of doors,
    1.50 +the ratio of passenger and cargo transport, and so forth.
    1.51  .PP
    1.52 -The extendability and maitainability of a software highly depends on its design.
    1.53 -Good design eases these tasks much.
    1.54 -Bad design, in contrast, requires much more effort for maintaining and
    1.55 -extending the software.
    1.56 -Developers should, for their own best, have maintainability and extendability in mind
    1.57 -when they design the software.
    1.58 +A software's design is about quality properties.
    1.59 +Each of the cars may be able to drive from A to B,
    1.60 +but it depends on its properties whether it is a good car for passenger transport or not.
    1.61 +It also depends on its properties if it is a good choice for a rough mountain area.
    1.62  .PP
    1.63 -Users of the software, in contrast, do not care about maintainability and extendability,
    1.64 -at least not directly.
    1.65 -They care about usability and flexibility.
    1.66 -They want the software to directly solve their problems.
    1.67 -They want to be able to to use all its functions if they learned a few of them.
    1.68 -They want to use the software for similar tasks.
    1.69 -Software is successful if users enjoy using it.
    1.70 -Good software design can offer great flexibility and usability.
    1.71 +Requirements to a software are twofold: functional and non-functional.
    1.72 +Functional requirements are easier to define and to verify.
    1.73 +They are directly the software's functions.
    1.74 +Functional requirements are the reason why software gets written.
    1.75 +Someone has a problem and needs a tool to solve it.
    1.76 +Being able to solve the problem is the main functional requirement.
    1.77 +It is the driving force behind all programming effort.
    1.78  .PP
    1.79 -Good design matters for developers \fIand\fP for users.
    1.80 -Hence both groups should care about good software design.
    1.81 -Bad design limits the software in some way.
    1.82 -It may still provide all requested function, but it will have worse quality,
    1.83 -and thus require more work effort for developers or frustrate users.
    1.84 +On the other hand, there are also non-functional requirements.
    1.85 +They are called \fIquality\fP requirements, too.
    1.86 +The quality of a software is about properties that are not directly related to
    1.87 +the software's basic functions.
    1.88 +Quality aspects are about the properties that are overlooked at first sight.
    1.89  .PP
    1.90 -Good software design is to the implementation like data structures are to algorithms
    1.91 -\(en if you get the former right, then you do not need to care about the latter,
    1.92 -it will simply go the right way.
    1.93 -.\" cf. ??? ``good data, bad algos''
    1.94 -
    1.95 -
    1.96 +Quality is of few matter when the software gets initially built,
    1.97 +but it will be of matter in usage and maintainance of the software.
    1.98 +A short-sighted might see in developing a software mainly building something up.
    1.99 +Reality shows, that building the software the first time is only a small amount
   1.100 +of the overall work.
   1.101 +Bug fixing, extending, rebuiling of parts \(en short: maintainance work \(en
   1.102 +does soon take over the major part of the time spent on a software.
   1.103 +Not to forget the usage of the software.
   1.104 +These processes are highly influenced by the software's quality.
   1.105 +Thus, quality should never be neglected.
   1.106 +The problem is that you hardly ``stumble over'' bad quality during the first build,
   1.107 +but this is the time when you should care about good quality most.
   1.108 +.PP
   1.109 +Software design is not about the basic function of a software;
   1.110 +this requirement will get satisfied anyway, as it is the main driving force behind the development.
   1.111 +Software design is about quality aspects of the software.
   1.112 +Good design will lead to good quality, bad design to bad quality.
   1.113 +The primary functions of the software will be affected modestly by bad quality,
   1.114 +but good quality can provide a lot of additional gain from the software,
   1.115 +even at places where one never expected it.
   1.116 +.PP
   1.117 +The ISO/IEC 9126-1 standard, part 1,
   1.118 +.[
   1.119 +%I International Organization for Standarization
   1.120 +%T ISO Standard 9126: Software Engineering \(en Product Quality, part 1
   1.121 +%C Geneve
   1.122 +%D 2001
   1.123 +.]
   1.124 +defines the quality model as consisting out of:
   1.125 +.IP \(bu
   1.126 +.I Functionality
   1.127 +(suitability, accuracy, inter\%operability, security)
   1.128 +.IP \(bu
   1.129 +.I Reliability
   1.130 +(maturity, fault tolerance, recoverability)
   1.131 +.IP \(bu
   1.132 +.I Usability
   1.133 +(understandability, learnability, operability, attractiveness)
   1.134 +.IP \(bu
   1.135 +.I Efficiency
   1.136 +(time behaviour, resource utilisation)
   1.137 +.IP \(bu
   1.138 +.I Maintainability
   1.139 +(analysability, changeability, stability, testability)
   1.140 +.IP \(bu
   1.141 +.I Portability
   1.142 +(adaptability, installability, co-existence, replaceability)
   1.143 +.LP
   1.144 +These goals are parts of a software's design.
   1.145 +Good design can give these properties to a software,
   1.146 +bad designed software will miss them.
   1.147  
   1.148  
   1.149  .NH 1