Systemarkitektur

Jeg tipper med hatten til V2 for at have rystet kravspecifikationen til EFI systemet løs fra mørklægningslovens skyggeland, bravo!

Mens jeg sad i Lufthavstoget i Norge stødte jeg ind i en artikel med overskriften "System Architecture" fra 1981, som er en glimrende partner til monsteret fra Skat.

Det der særligt slog mig ved denne artikel er hvor ærlig og fornuftig den er omkring alle de fejl og fejlestimater der blev begået undervejs.

Anbefalingerne, selvom mange af de teknologiske buzzwords vil synes fremmede for de fleste nu om dage, kunne med stor fordel have været brugt på EFI systemet.

Mit yndlingscitat er dette:

"The LMOS system, from its inception to its full Bell System penetration, will take 13 years to complete. There is no way that any operations systems designer is 13 years smart."

Tænk hvis nogen af de ansvarlige for EFI systemet havde gjort sig en sådan overvejelse...

phk

Kommentarer (16)
Povl H. Pedersen

Der er kommet nye udviklingsmetoder til. Vi havde også Amanda der blev lavet til OS/2, og skulle leveres på OS/2 flere år efter at produktet var lukket og slukket, og det var svært at finde hardware at køre det på.

Det er problemet ved at bestille færdige produkter (den gamle udviklingsmodel) til levering engang i fremtiden. Men i det mindste ved man hvad man har bestilt, og ved hvor meget der skal laves om straks efter leveringen.

Nyere udviklingsmetoder går i stedet på at man hyrer en mængde folk med kompetencer i stedet for. Nu var det en mindre dansk levrandør der fik opgaven til 100 mio DKK om året i 4-5 år.

Når man anvender denne metode ved man ikke hvad man får, man får så meget man kan nå at lave indenfor rammerne. Til gengæld kan det bruges undervejs. Hvis EFI havde kunnet opkræve 10% af gælden undervejs, så havde det været en god forretning.

Problemet er, at man skal have tillid til leverandøren, og at denne kan få og fastholde de rigtige mennesker.

Til gengæld, så har jeg svært ved at se hvordan noget projekt kan koste over 100 mio DKK/år. Det er vel 50-80 mand + det løse (omkostning = 2x medarbejderens løn). Ikke engang Apple, Microsoft m.fl. bruger så mange personer på enkelte produkter. Softwareudvikling skalerer ikke lineært. Jeg tror man får diminishing return of scale langt tidligere. Og man nummer 75 er ikke mere end halvt så effektiv som nummer 25.

Dog vil der være spor der kan paralleliseres. Der kan laves API'er, og man kan arbejde på hver sin side af dem. Men de skal være på plads inden man kan ansætte folk til at kode op imod dem.

Ud fra ovenstående mener jeg, at det offentlige bør afvise alle tilbud på softwareudvikling som er over 100 mio om året, og som ikke har klare aftalte delleverancer kort inde i projektet, og med exit klausuler løbende, med kompensation til den offentlige opgavestiller hvis de ser sig nødt til at afbryde et frugtesløst samarbejde.

Hvis projektet kører godt, så skal man nok få vedligeholdelses- og udviklingsaftaler efterfølgende. De fleste systemer bør være levende, og det bør der budgeteres med, medmindre man fastfryser lovgivningen.

Et problem med denne metode er, at det er sværere at outsource store dele af opgaven til en skål ris om dagen, man er nødt til at være tæt på kunden.

Poul-Henning Kamp Blogger

Der er kommet nye udviklingsmetoder til.

Det er der faktisk ikke.

Vi udvikler stadig software på fundamentalt set samme måde som man gjorde i 1980: Der sidder mennesker og skriver linie efter linie af programkode.

Jeg vi give dig at kodelinierne nu kan være længere end de ca. 72 tegn en TTY og et hulkort kunne rumme og også at vi spilder (?) mindre papir på programlistninger.

Men bortset fra disse praktisk detaljer er der ingen materiel forskel på programudvikling i 1980 og idag.

Claus Nedergaard Jacobsen

Hvad med agile metoder som SCRUM? De handler jo netop netop om at minimere den risiko, der er forbundet med, at omverdenen (herunder OS) ændrer sig i projektets forløb, men tager også hensyn til, at såvel kunder som udviklere bliver klogere i forløbet. Jeg tror det er de metoder, som Poul H. Pedersen tænker på. Iflg. Jeff Sutherland (bagmanden bag SCRUM), er det ikke længere tilladt i USA at specificere store offentlige IT-projekter iht. en vandfaldsmodel. Det lyder på mig, som om at det er det nordmændene indså allerede i 1981.

Martin Kristiansen

Hvad med agile metoder som SCRUM?

Da jeg gik på universitetet blev SCRUM kaldt Rapid Prototyping. Før det blev det kaldt Trial And Error.

Et agilt/prototyping-forløb er en god idé da det afklarer hvad det er kunden har brug for. Problemet er at man skal give en pris og en tidsplan for en løsning inden man kender kompleksiteten af projektet for at vinde udbudsrunden.

Morten Hansen

Kunne godt tænke mig at høre om folks erfaringer/viden med opstart og udvikling af ambisiøse enterprise-projekter der er blevet en succes
Google startede jo som et hypotetisk studieprojekt der både skulle bevise at pagerank algoritmen holdt vand og som et modsvar til Harvard professores tese om at det var umuligt at downloade internettet og indeksere det lokalt.
Facebook startede som et lille hobbyprojekt
Store banksystemer starter måske med at man laver en kerne og så indfaser features og områder (?)
Er der nogle der kender lidt til baggrunden bag PBS (som måske minder lidt om EFI hvor man også skal snakke med en mssse systemer) havde man fra start nogle store langsigtede planer ... eller er det noget er er blevet udvidet og skaleret med tiden?
Mange store kendte systemer er startet som en flyvsk ide eller løsning på et konkret problem / opgave (eks Varnish) - uden det måske burde inddrages i denne diskussion
@phk: hvor meget kender du evt til opstarten af FreeBSD? Det startede vel også med et solidt fondament der opfyldte de mest basale krav til et OS og derefter løbende har fået tilføjet festures. Her havde man vel ikke dets nuværende niveau i tankerne fra dag 1?

Allan Pedersen

Jeg kan godt se Poul du kan argumentere der intet nyt er kommet til, hvis du reducerer programmering til blot at sidde ved en stol og skrive kode.
Der er heller ikke kommet noget nyt til madlavning i 500 år så længe vi snakker om at røre i en gryde.,

Jeg tror ikke du kan finde ret mange steder der havde taget OOP til i de spæde 80'ere, eller tager jeg meget fejl?

Frithiof Jensen

Vi udvikler stadig software på fundamentalt set samme måde som man gjorde i 1980: Der sidder mennesker og skriver linie efter linie af programkode.


Njaeh -

Der findes en masse "kode", som gör virkelige samt vigtige ting ude i verden, "skrevet i" värktöjer som "Rational Rose RT" hvor man tegner blok diagrammer, event-flow diagrammer og state-machines. Derfra genereres C++ source som man (forhåbentligt) compiler uden at pille i det (telecom) .

Der findes "Matlab + Simulink" hvor man arbejder med funktionsblokke og "operators", National Instruments har noget lignende (proces kontrol).

Stort set alle PLC'ere anvender funktionsblokke efter IEC 61131/3 - selv Open Source "soft-plc'ere" fungerer sådan. (proces control)

GNU Radio programmeres fortrinsvis med funktionsblokke.

FPGA, et cetera. er genereret fra blokke eller VHDL, Verilog.

Naturligvis kan/bör man indvende at disse blokke og funktioner i sidste ende er hacket op een line af gange af nogle få rigtige udviklere, men, jeg vil til gengäld hävde at störsteparten af udviklertimerne bruges i "LEGO-miljöerne" og at "LEGO-diagrammet" er "sourcen" for det som ryger ud i frekvensomformere, motordrives, mobilnetvärk, ... hvilket er godt fordi färre ting springer i luften eller bränder op når man er tvunget til at programmere op imod interfaces (det er vel egentligt det som grafikken giver, samt et helikopter-overblik, så man ikke drukner i bits).

http://www.ni.com/sv-se.html
https://se.mathworks.com/products/simulink/index.html?s_tid=gn_loc_drop
https://en.wikipedia.org/wiki/GNU_Radio
http://www.proview.se/v3/
http://www.openplcproject.com

Frithiof Jensen

Kunne godt tænke mig at høre om folks erfaringer/viden med opstart og udvikling af ambisiøse enterprise-projekter der er blevet en succes


Success ... Måles det på:

a) hvor mange sälgere/konsulenter og investorer på "lösningssiden" kan pensionere sig inden de er fyldt 40,
b) hvor stor en del af kravene blev korrekt implementeret, til tiden endda,
c) om det egentlige "forretnings-"problem bag projektet blev löst?

Jo större et projekt er, desto flere "stakeholders" fra kategori "a" vil der väre som definerer og driver projektet, "b" er mest udviklere og teknikere, mens "c" ofte er givet af en meget begränset flok, typisk en ikke-teknisk ledergruppe. Som nemt drukner totalt i tusindvis af detaljer produceret af "a" og "c".

Odds'ene er imod ambitiöse enterprise projekter. Hvis ikke man er i "a"-teamet.

Poul-Henning Kamp Blogger

Der findes en masse "kode", som gör virkelige samt vigtige ting ude i verden, "skrevet i"

Den slags "kode" har intet med programmering at gøre, der er tale om byggeblokssammensætning med en typisk fysisk lav grad af komplexitet.

Selvom jeg er sikker på at de findes, har jeg aldrig fået pålidelige underretninger om kompexitet over ca. 10.000 "dimser" i den slags værktøjer.

Programmer er rask væk på millioner af linier

Finn Glamhøj

Den slags "kode" har intet med programmering at gøre, der er tale om byggeblokssammensætning med en typisk fysisk lav grad af komplexitet.

PLC Funktionsblokke er ikke meget andet end en grafisk version af IL/STL (Instruction List/Statement List) som er et assembler lignende sprog. Så skrives programmet i IL/STL er det da programmering?

Selvom jeg er sikker på at de findes, har jeg aldrig fået pålidelige underretninger om kompexitet over ca. 10.000 "dimser" i den slags værktøjer.

Programmer er rask væk på millioner af linier

Er det antallet af kodelinjer der afgøre om der er tale om programmering? Og i så fald hvor mange kodelinjer skal der til førend der er tale om programmering?

Min egen opfattelse af programmering er umiddelbart, at omsætte et ønske om udførelse af en opgave til kode der kan udføres af en computer, enten direkte, eller indirekte via en eller anden form for oversætter, eller sagt på en anden måde det at beskrive opgavens udførelse så den kan udføres af en computer.

Finn Glamhøj

Det er primært - stort set udelukkende - komplexiteten der skaber problemerne.

Jeg er helt med på, at jo mere kompleks en opgave er, jo større risiko er der for problemer, men har det noget at gøre med om der er tale om programmering?

Opgaver løst med en enkelt PLC ved brug af f.eks funktionsblokke høre nok sjældent til i den komplekse ende, men en hel fabrik med mange PLC’er, hvis opgave hver især er løst med funktionsblokke kan formodentlig god være en kompleks opgave, samlet set.

Men okay, grunden til at jeg kommenterede var dit udsagn om at den slags "kode" har intet med programmering at gøre, men for mig at se er der simple programmeringsopgave og komplekse programmeringsopgaver og jeg var egentlig bare ude efter en definition på, hvornår der er tale om programmering.

Log ind eller Opret konto for at kommentere