- – systemutvecklingsprocessen från planering till leverans och godkännande från beställare. Alltså en systematisk uppläggning av projektarbetet;
- – systemets hela livscykel, inklusive drift, underhåll, uppdateringar och slutligen avveckling. – Se också livscykelanalys.
– På engelska: systems development life cycle, förkortat SDLC.
[systemutveckling] [ändrad 15 augusti 2017]
(Law of Demeter) – princip för systemutveckling, i synnerhet objektorienterad: varje del av systemet (varje objekt) ska veta så lite som möjligt om resten av systemet. Man kan se det som en tillämpning av principen need‑to‑know:
- – varje objekt ska bara ha kunskap om de andra objekt som det måste utbyta meddelanden med (dess ”vänner” eller ”grannar”);
- – ett objekt ska bara ta emot meddelanden från sina vänner (enligt punkt 1), inte från okända objekt;
- – ett objekt ska bara prata med sina vänner.
– Demeters lag formulerades 1987 av Demeterprojektet (länk) vid Northwestern University (länk) i Evanston i Illinois. Grundtanken är att uppbyggnaden av varje objekt så mycket som möjligt ska vara oberoende av hur andra objekt är uppbyggda. Det gör det relativt enkelt att byta ut objekt utan att systemet som helhet påverkas. Systemet blir också relativt överskådligt om man tillämpar Demeters lag. Nackdelen är att det blir omständligt att programmera metoder som kräver att ett objekt utbyter långväga meddelanden. – Demeters lag leder till lös bindning. – Demeterprojektet var uppkallat efter den grekiska gudinnan Demeter. – Läs också om Unixfilosofin.
[lagar] [systemutveckling] [ändrad 23 december 2017]
konsulttjänst som i en upphandling erbjuds till ett orimligt lågt pris. – Det förekommer att tjänster erbjuds för så lite som en krona per timme eller i vissa fall helt gratis. Att erbjuda enkronaskonsulter är ett sätt att vinna en upphandling som gäller flera kategorier av tjänster. Ett företag som offererar normala priser för två av tre kategorier av tjänster, men tar en krona i timmen för den tredje kategorin får nämligen ett lågt genomsnittspris, och kan därför vinna upphandlingen. Poängen är att företaget inte har lovat att verkligen leverera den orimligt billiga kategorin av tjänster när kunden faktiskt begär det. Företaget har i själva verket aldrig haft för avsikt att leverera andra tjänster än de som det tar ett normalt pris för. – Läs också om bait-and-switch.
[bluff och båg] [konsulter] [ändrad 25 april 2021]
information radiator – stor bildskärm med aktuell information om hur ett systemutvecklingsprojekt fortskrider. Den placeras väl synlig så att alla i projektet kan se den. Används bland annat i agil systemutveckling.
[bildskärmar] [systemutveckling] [ändrad 11 juni 2017]
i datorvetenskap: det att alla delar av ett it‑system, eller samverkande it‑system, är överens om ett visst värde. – Konsensus är en förutsättning för många transaktioner och andra förändringar. Konsensus måste finnas när man gör ändringar i databaser i transaktionssystem (till exempel biljettförsäljning), genomför transaktioner som är tidsberoende (alla måste vara överens om vad klockan är) och i många andra sammanhang. – Det finns många motsvarigheter utanför datorvärlden, till exempel procedurerna som i ett demokratiskt val är till för att alla väljare ska kunna förvissa sig om att valet har gått rätt till och att valresultatet är korrekt. – Man talar i datorvetenskap om konsensusproblemet (the consensus problem). Tekniker för att etablera konsensus kallas för konsensusmekanismer (consensus mechanisms) eller konsensus-algoritmer (consensus algorithms). En känd konsensusalgoritm är blockkedjan i bitcoin‑systemet. – Om det är nödvändigt att nå konsensus trots att det finns ofullständig eller kanske felaktig information talar man om det bysantinska generalsproblemet. – På engelska: consensus.
[datorvetenskap] [systemutveckling] [ändrad 8 augusti 2022]
(technical debt) – dålig eller kortsiktig programutveckling som belastning på it‑system. ”Skulden” måste förr eller senare betalas genom att man omarbetar programmet eller byter ut det. Den tekniska skulden är, så länge den finns kvar, en belastning för driften och för annan systemutveckling. – Teknisk skuld kan i vissa fall också ses som en tillfällig nödvändighet: företaget måste ”sätta sig i skuld” för att inte missa ett tillfälle. Det kan då gälla både teknisk skuld i betydelsen slarvig programmering (för att man ska kunna leverera i tid) och skuld i pengar. I båda fallen måste skulden då betalas tillbaka. – Uttrycket skapades av Ward Cunningham, känd för att ha utvecklat den första wikin. – Man kan också tala om en teknisk kostnadsbomb i liknande betydelse. – Läs också om säkerhetsskuld.
[systemutveckling] [ändrad 18 mars 2019]