Ein vereinfachtes Modell der Softwarewissenschaft

deposit_hagen

Mathematik und

Informatik

Informatik-Berichte 37 – 06/1983

Ein vereinfachtes Modell der

Softwarewissenschaft

Franz Stetter

Zusammenfassung: Die Theorie der Softwarewissenschaft, durch Halstead begründet und beschrieben, versucht den Softwareent- wicklungsprozeß einheitlich und deduktiv zu beschreiben.

Ausgangspunkt der Theorie ist der Ansatz, die Programmbausteine in zwei Klassen, Operanden und Operatoren, einzuteilen.

In der vorliegenden Arbeit wird ein vereinfachtes Modell der Softwarewissenschaft vorgestellt, das die Programmbausteine nicht weiter differenziert. Man gelangt so, ohne Verlust an Genauigkeit, zu relativ einfachen Beziehungen zwischen ver- schiedenen Programmgrößen.

Summary: The theory of software science developed by Halstead attempts to analyze the software production process in a unified manner. The theory is based on the assumption that programs are

composed of operands and operators. In this paper we present a simplified view on software science: We do not distinguish between operands and operators. From there, we obtain simple relationships between prograrnm parameters.

- 2 -

In allen gängigen Programmiersprachen kann der Aufbau eines Programms (bzw. eines Moduls) in Programmkopf und Programm-

rumpf unterteilt werden. Während der Programmkorf die nach außen sichtbare und notwendige Information enthält - wie etwa Programm- name, Eingabevariablen, Ausgabevariablen, Kommentar mit Leistungs- beschreibung -, ist der Programmrumpf dem Benutzer eines Programms verborgen zu halten, um bei späteren Programmänderungen Auswirkun- gen auf die Benutzer des Programms möglichst zu vermeiden.

Will man die ¹¹Größe¹¹ oder ¹¹Länge¹¹ eines Programms P bestimmen, so läßt~sich ein erster grober Ansatz aus dem zuvor beschriebenen Programmaufbau unmittelbar ableiten. Nach der DIN-Norm /Deut75/

besteht ein Programmrumpf nämlich aus Vereinbarungen und An-

weisungen, so daß die Zahl der Vereinbarungen und Anweisungen ein Maß für die Länge ist. Die also durch

( 1. 1) l (P) .- Anzahl der Vereinbarungen und

L

Anweisungen eines Programms [LOC]

gemessene Länge bezeichnet man als Zeilenmaß; die Dimension des Zeilenmaßes ist LOC (lines ~f ~ade).

Es hat sich gezeigt, daß in der Praxis mit dem Zeilenmaß für große Programme brauchbare Aussagen gemacht werden können;

solche Aussagen sind etwa, daß ein Programmierer bei einem

mittelschweren Programm durchschnittlich 500 LOC's pro Monat zu- standebringt. Obwohl der "Gehalt" der einzelnen Anweisungen stark variiert - beispielsweise haben die Anweisungen A := o und

A := 1.23 x (SQRT(LN(x-3.2))-x)t 2 sicherlich nicht denselben Schwierigkeitsgrad-, wird man erwarten können, daß sich die einzelnen Anweisungen und Vereinbarungen im Mittel auf einen bestimmten Schwierigkeitsgrad einpendeln.

Wenn man zu genaueren Aussagen gelangen will, muß man offensicht- 1 ich die Vereinbarungen und Anweisungen in ihre "Bausteine" zer- legen und die Anzahl der Bausteine, aus denen die einzelnen Ver- einbarungen und Anweisungen aufgebaut sind, berücksichtigen.

Die nächst kleineren Bausteine, aus denen Vereinbarungen und An- weisungen aufgebaut sind, sind nun: Variablen, Konstanten,

arithmetische Operatoren, logische Operatoren, Trennzeichen, Klammern, Prozeduraufrufe, Wertzuweisungen und ähnliches.

Wir nennen diese Bausteine kurz die Elemente eines Programms.

Elemente sind also unterhalb der Ebene der Anweisungen und Ver- einbarungen die nächstgrößeren syntaktischen Einheiten. Wir führen folgende Bezeichnungen ein:

( 2 . 1 ) Vokabular E ( p)

.

^- Menge der Elemente eines Programms ( 2 . 2 ) Vokabulargröße n ( p)

-

card ( E ( p ) ) ,

p ,

( 2. 3 ) Häufigkeit f ( e)

. -

Anzahl, wie oft eEE(P) in ^p vorkommt, ( 2. 4) Länge N (P):= E eEE(P) z: f ( e) .

Da jedes Element eEE(P) mindestens einmal im Programm vorkommen muß, gilt offensichtlich

( 2 . 5 )

Halstead /Hals77/, der diese Begriffe eingeführt und die darauf aufbauende Theorie ¹¹Softwarewissenschaft¹¹ (eng. software science) genannt hat, teilt die Elemente in zwei Klassen ein, in Operanden und Operatoren. Die Operandenklasse en~hält die Variablen und Konstanten und in derüperatorenklasse sind alle übrigen Elemente zusammengefaßt. Wie in /Stet83/ gezeigt wurde, ist_eine solche Aufteilung in zwei Klassen überflüssig; sie macht darüberhinaus die weiteren Oberlegungen nur unnötig kompliziert.

- 4 -

Da zudem die Zahl der Operanden und die Zahl der Operanden nach /Hals77/ unmittelbar voneinander abhängen, hat man es auch dort implizit nur mit einer Variablen zu tun.

Halstead berücksichtigt ferner bei der Zählung der Operanden und der Operatoren nur die Anweisungen, nicht dagegen die Verein- barungen. Gegen diese Vorgehensweise sprechen sowohl neuere empirische Ergebnisse /Shen83/ als auch die Einsicht, daß die Daten zum Programm gehören: Je einfacher die Datenstrukturen sind, desto umfangreicher wird im allgemeinen der Algorithmus.

Wenn im folgenden keine Verwechslungen zu befürchten sind, schreiben wir statt lL(P), E(P), n(P), NE(P) kurz lL,E,n,NE.

Die durch NE gemessene Länge eines Programms nennen wir Element- maß, die Dimension bezeichnen wir mit el.

Das Zeilenmaß und das Elementmaß stehen, wie zu erwarten ist, in enger Korrelation. Es gibt eine programmspezifische Konstante cP derart, daß

( 2 . 6)

( 2 . 7 )

N = C l ,

E P L ^{C ?:} 1 ,

p

N = 0(1 ) und 1 = O(NE)

E L L

gilt. Mittelt man für eine feste Sprache die Konstante c _p über eine große Anzahl von Programmen, so zeigt sich, daß cP um einen Mittelwert schwankt (/Hals77/, /0tte79/). Für Assemblersprachen gilt c~3 und für höhere Programmiersprachen gilt c~5-8. Die _{p p} Konstante c _p hat die Dimension [el/LOC] und sie gibt an, wieviel Elemente eine Vereinbarung bzw. Anweisung durchschnittlich hat.

l)f(x)=O(g(x)) bedeutet, daß es eine Konstante k gibt, für die lf(x)l~klg(x)) für alle x gilt; lf(x)I wächst also im selben Maß wie !g(x)l.

3. Beispiel

Die vorigen (und die späteren) Ausführungen sollen an einem Beispielprogramm erläutert werden. Wir betrachten ein PASCAL- Programm, das zu zwei gegebenen Zahlen EINl und EIN2 den größten gemeinsamen Teiler nach dem Euklidschen Algorithmus berechnet; ist mindestens eine der beiden Zahlen nicht positiv, so so11 als Ergebnis o ausgegeben· werden.

program EUKLID (EIN1,EIN2,GGT);

var EIN1,EIN2,GGT,H:integer;

begin

read (EIN1,EIN2); GGT := o;

i f EINl>o and EINbo then begin

GGT ^:= EINl; H ^:= EIN2;

whiie GGT* H do

i f GGT>H then GGT := GGT-H eise H := H-GGT end;

write (EIN1,EIN2,GGT) end.

Beispiel (3.1): Programm EUKLID

Es 1st nun:

Element var . .. : EINl GGT

begin ... end

( )

i f ... then

>

whiie ... do

f e 1 5 8 6 2 2 1 3 1 2

E 1 e me n t f e' _ ....

integer l

EI N2 5

H 7

5

read 1

: = 5

i f ... then 1 ... eise

and 1

*

¹

write 1

Tabelle (3.2): Vokabular und Häufigkeit

Man beachte, daß begin ... end, if ... then usw. eine syntaktische Einheit bilden und deshalb als ein Element gezählt werden.

Man erhält nun aus (3.2) unmittelbar:

( 3 . 3 ) n=20, N =59.

E

Da Beispiel (3.1) aus einer Vereinbarung und elf Anweisungen besteht, ergibt sich nach (2.6) für c _p der Wert 59/12~5, d.h., eine Anweisung (Vereinbarung) besteht aus ca. 5 Elementen.

4. Schätzwert N für NE

Gemäß (2.5) gilt n~NE. Es ist naheliegend zu fragen, ob es zwischen n und NE eine funktionale Beziehung gibt. In /Stet83/

wurde geieigt, daß (ld~log 2 ) ( 4 . 1 ) N = nxld(n/2)

ein sehr guter Schätzwert für die Länge N ist. Beim Beispiel

E

(3.1) erhalten wir mit n=20 nach (4.1) den Wert N=66, der recht nahe bei NE=59 liegt. Im Anhang sind einige Beispiele aufgeführt, die zeigen, daß N und NE sehr nahe beieinander liegen.

Trotz mancher Versuche /Zweb77/ gibt es bisher keine zufrieden- stellende theoretische Interpretation der Formel (4.1).

Viele experimentelle Untersuchungen haben jedoch die Gültigkeit von (4.1) in außerordentlicher Weise untermauert.

Die Formel (4.1) kann bei ¹¹unvernünftiger¹¹ Programmierung offen- sichtlich beliebig ad absurdum geführt werden. Beispielsweise

könnte man für den Booleschen Ausdruck ¹¹false ¹¹ auch, (B 1v8 2 )A(8 1A8 2) schreiben, wenn 81 und 82 beliebige Boolesche Variablen sind,

oder man könnte eine Wertzuweisung der Form A := 1 hundertmal hintereinander schreiben. Die experimentelle Bestätigung von

(4.1) wurde an veröffentlichten bzw. ausgereiften Programmen voll- zogen, so daß es naheliegt zu sagen, daß der Schätzwert N für

11gu½e^{11 ,} strukturierte Programme gilt. Solche guten Programme ver- meiden sowohl Redundanz als auch ¹¹unvernünftige¹¹ Konstruktionen der folgenden Art /Hals77/:

a) Komplementäre Operationen wie A-8+8 oder Bv,8.

b) Mehrdeutige Variablen, d.h. Variablen, die im Programm an ver- schiedenen Stellen für verschiedene Zwecke benutzt werden (etwa zur Speicherersparnis).

c) Synonyme Variablen, d.h. verschiedene Variablen mit derselben Bedeutung (Gegenteil von b)).

- 8 -

d) Gemeinsame Teilausdrücke sind nicht mittels einer Variablen bzw. Prozedur zusammengefaßt.

e) Das andere Extrem zu d) ist die Einführung überflüssiger Wert- zuweisungen, wie z.B.:

A:=B+C; D:=At2;

anstelle des kürzeren Ausdrucks D:=(B+C)t2.

f) Ungeklammerte Ausdrücke wie AxA+2xAxß+ßxB sollen in der Form (A+B)t2 dargestellt werden.

In (4 .1) steigt N monoton mit n, also gibt es eine Umkehrfunktion f mit n=f(N). Zur Bestimmung von f bemerken wir zunächst, daß

( 4 . 2 ) ld(N/2) ::; ^N ld(N/2) ^2xN

gilt. Um n genauer einzugrenzen, kann man für n den Ansatz

n = N

a.+ 1 d ( N/ 2 )-axl d ( 1 d ( N))

mit einem geeigneten a machen. Es zeigt sich, daß a=! die Um- kehrfunktion sehr gut wiedergibt (man vergleiche die Werte im Anhang); Also haben wir mit

1+8xld(N)-9xld(ld(N)) 8xN

für n einen Schätzwert nN, der aus N berechnet werden kann.

Es sei angemerkt, daß die funktionale Beziehung zwischen n und N für alle Sprachen gilt. Ist die Vokabulargröße für eine Sprache

erst einmal festgelegt, so ist damit auch die Länge bestimmt. Da die Länge bei Programmen abnimmt, wenn sie in höheren Programmier-

sprachen geschrieben werden, ist die Vokabulargröße offensichtlich von der gewählten Programmiersprache abhängig. Für jedes Programm gibt es jedoch eine untere Schranke für die Vokabulargröße n, wie die folgende Oberlegung zeigt.

Ein Programm realisiert eine Funktion f:E-A, die bestimmte Ein- gabevariablen in Ausgabevariablen abbildet. Ist n die Zahl der

ea

Eingabe- und Ausgabevariablen, so benötigt man neben diesen Elementen immer noch mindestens zwei weitere Elemente: einen

11Funktionsoperator f¹¹ und einen Operator, um den Ausgabevariablen Werte zuzuweisen. Also gilt für die untere Schranke n0 von n

( 4 . 4) no=2+n :,; n

ea

Nehmen wir nun an, daß wir eine entsprechende Programmiersprache dieser kompakten Form haben, so ist die Länge N für ein solches Programm E

( 4 . 5 )

da jedes Element gerade einmal im Programm auftritt. Da anderer- seits nach (4.1) für no der Schätzwert N=n0 ldn0 gilt und dieser Wert mit (4.5) nicht übereinstimmt, kann (4.1) nur für Werte

von n gelten, die nicht zu nahe bei no liegen. Nimmt man anstelle von (4.1) den Schätzwert

( 4 . 6 ) N0 =nxld((n-n0+4)/2)

so gilt N0 (n0 )=n0 • Wie im Anhang gezeigt wird, ist auch No ein guter Schätzwert für N . Da jedoch No von den zwei Variablen

E

n und n0 abhängt, hat die Formel (4.6) gegenüber der Formel (4.1) Nachteile. In den folgenden Oberlegungen werden wir deshalb stets mit dem Schätzwert N rechnen; man muß dann lediglich darauf achten, daß bei Werten von n nahe no von dem Schätzwert N auf den Schätz- wert No übergegangen wird.

Aus (4.1) und (4.3) können wir die Beziehungen ( 4 . 7 )

und (4.8)

N=O(nxld(n))

n=O(N/ld(N)) festhalten.

- 10 -

5. Programmvolumen

Um ein Programm mit der Länge NE und der Vokabulargröße n mit möglichst wenig Zeichen darzustellen, muß man dien Elemente binär verschlUsseln. Man benötigt dazu insgesamt ld(n) Bits.

Die Gesamtzahl der Zeichen, die das Programm benötigt, ist somit NExld(n).

Man definiert nun das Volumen V durch

(5.1) V:=Nxld(n)=nxld(n)xld(n/2) [bits].

FUr Werte von n nahe no wird man natürlich N durch No aus (4.6) ersetzen müssen. Damit ist das kleinstmögliche Volumen, Minimal- volumen V0 genannt, durch

(5.2) Vo:=noxld(no)

gegeben. Man nennt das Minimalvolumen auch den Informations-

inhalt des Programms, da Vo für einen fest vorgegebenen Algorithmus eine Konstante ist.

Das Volumen V wächst monoton mit n, so daß es eine Umkehrfunktion g mit n=g(V) gibt, die bei Bedarf mit ähnlichen Methoden wie

im Abschnitt zuvor, wo n als Funktion von N bestimmt wurde, be- stimmt werden kann.

Je näher für einen festen Algorithmus das Volumen sich dem Minimal- volumen nähert, desto kompakter wird die Implementierung.

Andererseits wird die Implementierung umso aufwendiger und damit auch schwieriger, je weiter sich V von Vo entfernt.

Man definiert

(5.3) D:=V/Vo ^{( D;d)}

als den Schwierigkeitsgrad der Implementierung. Den Kehrwert (5.4) L:=1/D=Vo/V ^(L:,;l)

bezeichnet man als Programmstufe. Das Produkt LxV=Vo gibt somit den Informationsinhalt eines Programms an; es ist für einen festen Algorithmus konstant.

Halten wir nun eine Implementierungssprache fest und betrachten wir den Schwierigkeitsgrad in Abhängigkeit vom Minimalvolumen, so gilt

(5.5) Va~D.

Je größer der Informationsinhalt ist, desto schwieriger wird auch die Implementierung. Man nennt die Größe

(5.6) A:=V0 /D=LxVa=Vo/V .2

die Sprachstufe. A ist für eine bestimmte Sprache in erster Näherung eine Konstante. Nach /Hals77/ gilt:

Sprache ^A Varianz

Assembler 0.88 0.42 Fortran 1.14 0.81 Algol 58 1. 21 0.74

PL/I 1.53 0.92

Tabelle {5.7}: A-Werte

Mit den eingeführten Größen kann man nun eine Beziehung zwischen n, n₀ und A ableiten. Aus V=Vo/A und V=nxld(n)xld(n/2) folgt durch 2

Gleichsetzung

(n0 xld(n0 ) )2 = \xnxld(n)xld(n/2) z (/W xld(n//;")) ² also

( 5 • 8 ) n o x 1 d ( n o ) = ~ ^x 1 d ( n / /;) .

- 12 -

Eine Näherungslösung nach der Newton-Methode /Stet83/ 1 iefert für n den Wert

( 5 . 9 )

no ( 2 l+ln(no) )2 LJ."Ix

1-1 n /4A{2 ¹ + 1 n(n0 ) 2

= ~~xh² (no,A),

Es gilt h(no,A)-1 für no- ^{00 ,} Somit haben wir (5.10) n = 0(no ² /A)

und

( 5. 11)

no=

^{0 (} Cxn ) .

Gleichung (5.10) kann so interpretiert werden, daß man für höhere Programmiersprachen weniger Elemente benötigt als bei Assembler- sprachen. Durch Vorgabe der Sprache ist also für einen festen Algorithmus die Anzahl der benötigten Elemente festgelegt.

Da die Länge N nur von der Vokabulargröße n abhängt, folgt in Verbindung mit (4.7):

(5.12) N =O(n5xld(no)/A).

In der folgenden Tabelle sind einige Werte von n in Abhängig- keit von n0 und /1, angegeben, die nach (5.9) berechnet sind.

/1,

no 1 1. 25 1. 5

4 10 9 9

10 46 40 36

25 24 7 212 187

50 921 780 681

100 3498 2938 2545

Tabelle {5.13}: Werte von n als Funktion von n⁰ und /1,

6. Programmieraufwand

Ein Programm der Länge N und der Vokabulargröße n zu programmieren kann bezüglich des Aufwands so interpretiert werden: Man wähle nach einer bestimmten Methode N-mal ein Element aus dem Vokabular.

Eine effiziente Methode, zum Beispiel binäres Suchen, erfordert

jedesmal ld(n) Vergleiche, so daß insgesamt Nxld(n) Versleiche durch- zuführen sind. M.a.W., der Wert des Programmvolumens gibt die

Zahl der Bits an, die zur Darstellung des Programms benötigt werden, und für jedes Bit ist eine Entscheidung zu treffen.

Nun ist der Aufwand sicherlich proportional zum Schwierigkeits- grad, d.h. der einzelne Vergleich erfordert mehr Ober-

legungen.

Man definiert aufgrund der vorigen Oberlegungen den Programmier- aufwand E durch

( 6 . 1 ) E:~DxNxld(n)=DxV ^{[ p E ] •}

Die Dimension PE nennen wir Programmiereinheit.

Diese Gleichung läßt sich nun noch leicht umformen zu:

( 6 . 2 )

( 6 . 3 ) E = Vo/t, . ^{3 2}

Halten wir in (6.3) einen Algorithmus fest und variieren die Implementierungssprache, so trägt allein der Nenner zur Sprach- abhängigkeit bei, da Vo sprachunabhängig ist. Es gilt also

( 6 • 4 )

Die folgende Tabelle gibt auf der Grundlage von (5.7) die Werte von 1/A² wieder:

- 14 -

Assembler Fortran Algol 58 PL/I

>,_-2

% von Assembler

% von PL/I

1. 29 100 300

0.77

60

179

0.58

53

158

0.43 33 100 Tabelle (6.5): Sprachenabhängigkeit von E

Es wird also z.B. dreimal so aufwendig, wenn man eine Assembler- sprache anstelle von PL/I wählt.

Hält man nun eine bestimmte Implementierungssprache fest, d.h., man betrachtet>-. als Konstante, so lassen sich unmittelbar

die folgenden Aussagen ableiten.

( 6 • 6 ) E

=

0 ( nix ( l d ( n0 ) 3

) , (nach ( 6 • 3 ) und ( 5 . 2 ) ) ,

( 6 • 7 ) E

=

^{O(n6°5 x(ld(n))3 ) , (nach ( 6 . 6 ) und (5.11)),}

( 6 • 8 ) E

=

^{0 ( N 1• 5 X (} 1 d ( N ) ) ^{1• 5 ),} (nach ( 6 . 6 ) und (5.12)), ( 6 • 9 ) E = 0(lt⁵ x(ld(lL)) ^{1" 5 ) ,} (nach ( 6 • 8) und (5.7)).

Da die Programmierzeit T proportional zum Prog~ammieraufwand ist, d.h. T~E, erhält man durch

(6.10) T=E/Eo

die Programmierzeit in einer entsprechenden Zeiteinheit, wenn Eo der in dieser Zeiteinheit zu leistende Programmieraufwand ist.

Eo muß für eine spezifische Programmierung experimentell bestimmt werden, da Eo sehr stark variieren kann (Art des Programms,

Testumgebung, Erfahrungen, Kenntnisse, Fähigkeiten, Maschinen- unterstLltzung etc.). FLlr Werte von Eo sei auf die entsprechende Literatur verwiesen; die dort angegebenen L0C ¹s können mittels (2.6),(4.3) und (6.1) leicht umgerechnet werden.

Nach (6.8) und (6.9) steigt der Programmieraufwand nichtlinear mit der Länge des Programms. Folglich verringert eine Aufteilung eines Programms in Moduln den Programmieraufwand erheblich.

- 16 -

7. Schlußbemerkungen

Wie /Shen83/ bemerkt, ist die Theorie der Softwarewissenschaft noch stark in der Entwicklung. Obwohl es teilweise ernste Einwände gegen die Theorie überhaupt gibt, sprechen andererseits die empirischen Daten dafür, daß die Theorie zumindest in einer ersten Näherung brauchbare Ergebnisse liefert. Mit der zuvor entwickelten Verein- fachung der Theorie ist es erstmals möglich, exakte Beziehungen zwischen verschiedenen Programmparametern - Zahl der Ein-/Ausgabe- variablen, Programmlänge, Programmvolumen, Vokabulargröße etc. - abzuleiten.

Anhang

Die folgenden Beispiel sind /Hals77/ entnommen. Beispiel 1 bis 14 sind in den Comm. of ACM veröffentlicht, die restlichen sind kommerzielle Programme. In der Tabelle sind n, n0 und N

E

gemessene Größen, alle übrigen Werte sind abgeleitet.

n no n _N N _E N No

CACM 1 28 10 28 104 107 97

CACM 2 22 5 22 84 76 75

CACM 3 59 14 59 454 288 272

CACM 4 37 7 37 137 155 151

CACM 5 31 6 31 124 122 120

CACM 6 28 6 28 99 107 104

CACM 7 19 ⁵ lS 59 61 60

CACM 8 31 7 31 133 122 118

CACM 9 60 12 60 312 294 282

CACM 10 18 5 18 48 57 56

CACM 11 18 5 18 55 57 56

CACM 12 20 5 20 62 66 65

CACM 13 19 5 19 61 61 60

CACM 14 40 9 40 187 173 165

GM 15 127 34 126 686 760 711

GM 28 263 45 260 1919 1851 1787 GM 36 376 70 372 2642 2841 2736 GM 40 515 60 509 3985 4124 4039 GM 50 203 34 201 1248 1353 1306

GM 118 38 8 37 122 155 150

- 18 -

Es gilt für die mittleren Fehler und die mittleren Fehlerquadrate:

0 ¹ = ₂₀ ^{1 l::} (NE-No)/NE= ^0.020,

82 =

fö

^I: ((NE-N)/NE)2 = 0.016,

03

=

₂₀ 1 ^I: (NE-No)/NE

=

^0.012,

1 _I:

((NE-No)/NE) 2

=

^0.023.

8 '+

=

₂₀

Literatur

/Deut75/

/Fitz78/

/Hals77/

/Otte79/

/Shen83/

/Stet83/

/Zweb77/

Deutscher Normenausschuß (Hrsg.): ¹¹Normen über

Informationsverarbeitung^{11 •} 3. Aufl., Beuth, Berlin, 1975 Fitzsimmons 'A, and Love T.: ¹¹A review and eval uation of software science^{11 •} ACM Comp. surv. 10, 3-18, 1978 Halstead, M.H.: ¹¹Elements of software science^{11 •}

Elsevier North Holland Inc., New York, N.Y., 1977 0 t t e n s t e i n , L . M . : ¹¹ Quant i tat iv e es t i m a t es o f de b u g g i n g requirements ^{11 •} IEEE Trans. Softw. Eng., Vol. SE-5, pp. 504-514, 1979

Shen V.Y., Conte S.O., and Dunsmore H.E.: ¹¹Software science revisited: A critical analysis of the theory and its empirical support^{11 •} IEEE Trans. Softw. Eng., SE-9, pp.155-165, 1983

Stetter, F.: ¹¹Estimates in software science^{11 •} Informatik- Bericht Nr. 31, Fernuniversität Hagen, 1983

Zweben, S.H.: ¹¹A study of the physical structure of algorithms^{11 •} IEEE Trans. Softw. Eng., Vol. SE-3,

pp. 250-258, 1977