vattenfallsmetoden

en systemutvecklings-process som är enkel­riktad. – Vattenfallsmetoden innebär att när ett steg i processen är avslutat börjar man med nästa, och man backar inte. (Se grindprocess.) Vatten­fall rinner ju inte uppåt. – De traditionella stegen i systemutveckling är kravspecifikation, analys, design, realisering och testning, och dessa genomgås alltså i tur och ordning i vattenfallsmetoden. Modellen var dominerande under 1970‑talet och var bekväm för projektledarna, men resultatet blev inte alltid lyckat, och det märkte man inte förrän det var för sent. På engelska kallas metoden ibland sarkastiskt för faith‑driven development – annars: the waterfall method. – I dag är det vanligare med metoder där man fortlöpande testar koden, och vid behov går tillbaka och ändrar i kravspecifikation, analys och design. Man talar om:

  • iterativ system­utveckling, vilket innebär att man snabbt tar fram ett fungerande, men grovt till­yxat, system som sedan finslipas i många omgångar (iterationer), och om:
  • inkrementell systemutveckling, där man först utvecklar de centrala delarna av ett system, och sedan lägger till fler funktioner.

– Ett modernt sätt att arbeta är agil systemutveckling. – Läs också om scrummer­fall och upfront design samt om waterfalling, som är något helt annat.

[systemutveckling] [ändrad 21 februari 2022]

synchronize-and-stabilize

synkronisera–stabilisera – ett arbetssätt vid systemutveckling: flera grupper arbetar parallellt med varsin del av systemet. De synkroniserar (samordnar) och stabiliserar (rättar) sitt arbetsresultat (koden) ofta under arbetets gång. Arbetssättet är ett alternativ till den traditionella vattenfallsmetoden, och bygger på erfarenheter från utvecklingen av Netscape Navigator† och Internet Explorer. Metoden beskrevs i boken Competing on internet time: Lessons from Netscape and its battle with Microsoft från 1998 (länk) av David Yoffie (länk) från Harvard och Michael Cusumano (länk) från MIT.

[systemutveckling] [ändrad 1 november 2019]

systemutveckling

(systems development, på svenska också: systemering) – utveckling av it‑system. – I ett it-system kan det ingå applikationer, klienter, serverprogram, databaser, nätverk, funktioner för systemadministration och it-säkerhet, så kallade mellanprogram, webbservrar, webbsidor och annat. Många av de beståndsdelarna köps sedan länge som färdiga standardprodukter, men de behöver anpassas till organisationens behov och knytas samman i ett nätverk. – Systemut­veck­ling om­fattar en hel kedja från beställning till test och leverans av systemet. Man brukar tala om stegen kravspecifika­tion, användningsfall, analys, design, kodning och testning, men dessa görs numera sällan i tur och ordning. (Läs om vattenfallsmetoden kontra agil systemutveckling.) – I system­­utveckling skiljer man ibland mellan metoder och processer. En metod är ett sätt att, utifrån kravspecifikationen, komma fram till hur det färdiga systemet ska se ut. Man tar fram en modell av det färdiga systemet (analys följt av design). En process utgår sedan från modellen och är en plan för hur utvecklingsarbetet ska gå till. Jäm­för med att göra ritningarna till ett hus (=metoden) och att planera byggandet av ett hus (=processen). I agil systemutveckling är skillnaden mellan metod och process mindre uttalad. – När man talar om programutveckling menar man ofta bara att man utvecklar ett enda program (en applikation). Det finns dock ingen skarp gräns mellan systemutveckling och programutveckling. – IDG:s artiklar om systemutveckling: länk.

[systemutveckling] [ändrad 25 mars 2023]

metod

  1. – i systemutveckling: systematiskt sätt att framställa en modell av det system som ska byggas. – Metoder brukar kunna delas upp i kravspecifikation, användningsfall, analys, konstruktion (design) och realisering (implementa­tion), men de momenten behöver inte genomföras i tur och ordning (se iterativ och vattenfallsmetoden). Planen för realiserande av modellen kallas för process, men numera drar man sällan en skarp gräns mellan metod och process;
  2. – i objektorientering: operation som ett objekt kan genomföra genom att exekvera kod som ingår i objektet. Kallas även för rutin eller procedur. Metoder är inkapslade och exekveras efter anrop (metodanrop eller meddelande, betydelse 2) till objektet. Objektet kan på motsvarande sätt leverera resultatet av operationen (returvärdet) som ett meddelande. Programmeraren behöver inte veta hur programkoden som ingår i koden ser ut, hon behöver bara veta hur man anropar metoden.

– På engelska: method.

[systemutveckling] [ändrad 5 februari 2019]

SEMAT

Software engineering method and theory – ett enhetligt sätt att beskriva systemutvecklingsmetoder, utvecklat av bland andra Ivar Jacobson. Semat strävar efter att på ett entydigt sätt beskriva de teoretiska grunderna för systemutveckling och tillvägagångssätten vid realisering av system. Semat är till stor del agnostiskt när det gäller teorier och metoder, men rymmer vissa värderingar. Till exempel att agila metoder vanligtvis är bra och att vattenfallsmetoden inte är bra. – Se semat.org.

[förkortningar på S] [systemutveckling] [ändrad 1 september 2020]

Qt Group

företaget som utvecklar utvecklingsplattformen Qt. – Qt är en verktygslåda för utveckling av program med grafiska användargränssnitt. Program som har ut­­veck­lats i Qt kan köras i Windows, macOS och Linux utan ändringar. De kan också köras på mobiltelefoner. – Qt är skrivet med öppen källkod och sprids i två versioner: dels som fri mjukvara, dels som betalprogram med en licens som ger kunden frihet att använda Qt‑baserade program i egna produkter. Qt används i KDE. – Qt Development Frameworks grundades 1994 i Norge av Eirik Chambe‑Eng och Haavard Nord under namnet Trolltech. Före­taget köptes 2008 av finländska Nokia, som först döpte om det till Qt Software, sedan integrera­de det i Nokia som en avdel­ning under namnet Qt Development Frame­works. I augusti 2012 såldes det till Digia (digia.com). Där var det först en avdelning som hette Qt Commercial, sedan dotterbolag, 2016 avknoppat under namnet Qt Group Plc. – Se qt.io.

[avknoppningar] [grafiskt användargränssnitt] [systemutveckling] [ändrad 19 december 2019]

tjänstefiering

(servicification eller servitisation) – det att processer och funktioner i it‑system görs om till tjänster (i programmeringsteknisk betydelse). – Allmänt innebär detta att processen / funktionen separeras från det system som den tidigare har ingått i och förpackas separat. Den får ett namn och ett programmeringsgränssnitt så att andra program kan anropa den och be den att utföra olika uppgifter. Detta kan ske inom ramen för företaget, men tjänsten kan också tillhandahållas av ett annat företag på ett standardiserat sätt. – De två engelska orden servicification och servitisation hade ursprungligen något olika inne­börd, men de är numera utbytbara. Servitisation är språk­ligt korrekt, men servicification är mer be­grip­ligt.

[it-system] [programmering] [systemutveckling] [ändrad 2 maj 2020]

separation of concerns

uppdelning i problemområden – i systemutveckling: det att olika delproblem i ett program hålls i sär så att man kan hantera dem separat. En ändring i ett problemområde ska alltså kunna genomföras utan att det påverkar hela systemet. Exempel: man bör hålla i sär lönesystemet och listan över personalens adresser. Man bör också hålla i sär det grafiska användargränssnittet (presentationen) och den kod som gör beräkningar och sökningar. Detta gör att det blir lättare att hitta och rätta till fel och att göra förbättringar. Det minskar risken för att fel i en funktion stör andra funktioner. Det gör det också enklare att återanvända delar av programkoden. – Principen om uppdelning i problemområden formulerades först av Edsger Dijkstra, men den hade tillämpats i praktiken tidigare. – Se också sepa­ration of duties.

[systemutveckling] [ändrad 7 juli 2019]