I 1987 fremlagde Fred Brooks under titlen
"There is no silver bullet" (IEEE Computer; April 1987)
følgende budskab til softwarebranchen:
"Of all the monsters that fill the
nightmares of our folklore, none terrify more than werewolves,
because they transform unexpectedly from the familiar into
horrors. For these, one seeks bullets of silver, that can
magically lay them to rest. The familiar software project, at
least as seen by the nontechnical manager, has something of this
character; it is usually innocent and straightforward, but is
capable of becoming a monster of missed schedules, blown budgets,
and flawed products. So we hear desperate cries for a silver
bullet - something to make software costs drop as rapidly as
computer hardware costs do."
De fleste vil nok give Brooks ret med hensyn
til beskrivelsen af forløbet af et typisk softwareprojekt; men
har han ret i, at der ikke er nogen løsning på softwarekrisen?
Brad J. Cox argumenterede i artiklen
"There Is a Silver Bullet" (Byte; Oct. 1990) for, at
der er en løsning; men den forudsætter en kulturel revolution i
stedet for en teknologisk revolution.
Alle de forsøg, som man i de sidste 20 år har
gjort for at eliminere softwarekrisen, har været forsøg på at
klare problemerne med større eller mindre teknologiske
revolutioner.
Når man taler med professionelle
systemudviklere om, hvordan systemudvikling foregår i den
virksomhed, hvor de er ansat, er det et gennemgående træk i
beskrivelserne, at det er de samme personer, som altid kommer med
de mest brugbare løsninger. De er måske i besiddelse af et
medfødt talent, som gør dem til "super"
systemudviklere. Men måske er det også noget, der kan læres?
Hovedopgavens første formål er at afklare, om
en mulig løsning på softwarekrisen (den kulturelle revolution)
simpelthen kunne bestå i, at man forsøgte at mobilisere
"skjulte" kreative reserver hos de mindre produktive
systemudviklere.
Hovedopgavens andet formål er at give en
kritisk vurdering af forskellige eksisterende
systemudviklingsmodeller i forhold til den foreslåede løsning
på softwarekrisen.
Hovedopgavens tredie formål er at forsøge at opstille nogle alternative måder at organisere softwareudvikling på ud fra den foreslåede løsning på softwarekrisen.
Vi har valgt at bevare hovedopgavens
oprindelige idégrundlag i den form, som det havde, da vi
startede på opgaven.
Arbejdet med hovedopgaven har selvfølgelig
givet en indsigt, som bl.a. har betydet, at resultatet er blevet
en smule anderledes end det, vi oprindelig sigtede mod.
Det, der har gjort det stærkeste indtryk på
os selv, er især kapitlerne 2, 4 og 5. Arbejdet med disse
kapitler har givet os ny indsigt, som vi også føler et stort
behov for at dele med andre.
Undervejs har den sproglige form i opgaven
også ændret karakter. Her er vi vores vejleder Peter Hegstrup
stor tak skyldig. Vi har igennem det meste af opgaven med vilje
forsøgt at underspille signaleringen af vort budskab. Hvor det
er muligt, lader vi kilderne tale for sig selv.
Herved håber vi selvfølgelig på, at det
bliver muligt for læseren at genopleve de samme erkendelser, som
førte os frem til en ny indsigt i begreberne problemløsning og
softwarekrise.
Skulle det mislykkes, sammenfatter de sidste to
kapitler den indsigt, som vi er kommet frem til. I kapitel 5
opregner vi en række paradokser, som vi er stødt på i den
måde, som systemudvikling foregår på. Kapitel 6 rummer en
række konklusioner og forslag til, hvordan vi mener, man kan
løse softwarekrisen.
Det første og det sidste af de tre formål,
der er skitseret i idégrundlaget, er dækket af opgaven. Det
andet formål er faktisk også dækket, selvom man kan mene, at
argumentationen er for underspillet til at være kritisk i sin
form. Men som nævnt er denne form valgt med overlæg, fordi vi
tror, at budskabet i denne form vil have en større mulighed for
at overbevise en skeptisk læser.
Sæt dig behageligt til rette, åbn dit sind,
og læs.
Tak til Peter for vejledning og ragekniv.
Tak til kollegerne for gode ideer, indvendinger
og konstruktive diskussioner
Odense d. 11. december 1992
Bruno Johansen / Bjarne Larsen
Opgaven består af følgende kapitler:
1.1 Softwarekrisen
1.2 Forsøg på løsning af softwarekrisen
1.2.1 Strukturerede teknikker
1.2.2 Software Engineering
1.2.3 Information Engineering
1.2.4 CASE værktøjer
1.2.5 Eksperimentel systemudvikling
1.2.6 Objekt-orienteret systemudvikling
1.2.7 Funktionel programmering
1.3 Men softwarekrisen er der endnu
1.4 Kulturel revolution
2.1 Hvad kan vi lære af filosofien?
2.1.1 Den klassiske filosofi
2.1.2 Renæssancens filosofi
2.1.3 Det 17. århundredes filosofi
2.1.4 Det 18. århundredes filosofi
2.1.5 Det 20. århundredes filosofi
2.1.6 Matematikkens rolle i filosofi og videnskab
2.2 Hvad kan vi lære af psykologien?
2.2.1 Kognitionspsykologi
2.2.1.1 Procesteorierne
2.2.1.2 Udviklingsteorierne
2.2.1.3 Strukturteorierne
2.2.2 Modulteorierne
2.2.3 Den indre scene
2.3 Hvad kan man lære af historien?
2.4 Hvad kan man lære af antropologien?
2.5 Hvad kan man lære af neurofysiologien?
2.5.1 Hjernen
2.5.1.1 Hjernestammen
2.5.1.2 Det limbiske system
2.5.1.3 Storhjernen
2.5.1.4 Hemisfærespecialiseringen
2.5.2 Hjernens udvikling i psykologisk perspektiv
2.6 Hvad er ekspertise
2.6.1 Problemløsningsområder
2.6.2 Fra nybegynder til ekspert i fem trin
2.7 Hvad er intelligens
2.8 Intuition
2.8.1 Intuitive oplevelser
2.8.2 Den rigtige hjerne - den forkerte teori
2.8.3 Forberedelse til intuitionen
2.8.4 Om at give intuitionen retning
2.8.5 Om at stimulere intuitionen
2.8.6 Inkubationens betydning
2.9 Kreativitet
2.10 Hvad mennesker er gode til, og hvad mennesker ikke er gode til?
3.1 Syskon
3.1.1 De grundlæggende ideer og principper
3.1.2 Faserne
3.1.3 Styringen
3.1.4 Hensynet til mennesker
3.1.5 Løsningsmetoder
3.2 Strukturerede metoder
3.2.1 Historisk udvikling
3.2.2 Struktureret programmering
3.2.3 Struktureret design
3.2.4 Struktureret analyse
3.2.4.1 De grundlæggende ideer og principper
3.2.4.2 Faseopdeling
3.2.4.3 Vedligeholdelse
3.2.4.4 Fysiske, logiske og essentielle modeller
3.2.4.5 Fordele og ulemper ved struktureret analyse
3.3 Prototypeudvikling
3.3.1 Rapid Structured Prototyping
3.3.2 Eksperimentel systemudvikling
3.4 Formalistiske metoder
3.4.1 Formel specifikation
3.4.2 Fordele ved en formel specifikation
3.4.3 Hindringer for formelle specifikationer
3.4.4 Funktionel programmering
3.5 Objekt-orienteret systemudvikling
3.5.1 Dataabstraktion
3.5.2 Fælles adfærd
3.5.3 Udvikling
3.5.4 Softwarekvalitet
4.1 Round-Trip Gestalt Design
4.2 Bjarne Stroustrup
4.3 Paul Lindgreens systemanalyse
4.4 Professionel systemudvikling
4.5 Gerald Weinbergs General Systems Thinking
4.6 Egne iagttagelser
5.1 Forholdet mellem praksis og teori
5.2 Totalt overblik som forudsætning
5.3 Muligheden af at bevise ethvert logisk udsagn
5.4 Markedsmekanismer
5.5 Dokumentation som kommunikationsmedie
5.6 Manglende kendskab til filosofien
5.7 Manglende problemløsningsværktøj
5.8 Intelligensens betydning for systemudvikling
5.9 Ekspert og generalist
5.10 Teknologiudvikling som løsning på softwarekrisen
5.11 Kunstig intelligens og ægte intelligens
6.1 Behovet for en systemudviklingsmodel
6.2 Det flerfaglige ståsted
6.3 Problemløsning
6.4 Manglende dokumentation for påstande
Indlagt 27. april 1997