slank systemutveckling – systemutveckling utan onödigt arbete, onödig kod och onödig byråkrati. Det är en utveckling av agil systemutveckling, och har inspirerats av lean production, ett industriellt produktionssätt som har utvecklats på Toyota. Principerna för slank systemutveckling har beskrivits av Mary Poppendieck och Tom Poppendieck i boken Lean software development, 2003. – Se begreppet lean. – Se också poppendieck.com.
[systemutveckling] [ändrad 7 april 2023]
(validation) – utvärdering – kontroll av att något verkligen har de egenskaper som det uppges eller förväntas ha. Validitet kan översättas med giltighet:
- – i systemutveckling: kontroll och bekräftelse av att programmet fungerar på det sätt som beställaren väntar sig. Programmet ska faktiskt gå att använda för det ändamål som det har byggts för. Man skiljer mellan validering och verifiering. Verifiering är kontroll av att ett program är utfört enligt beställningen, vilket inte nödvändigtvis betyder att det fungerar som beställaren hade tänkt sig;
- – om data: validitet är att data i ett it-system stämmer med verkliga förhållanden;
- – vid datainmatning och programmering är validering kontroll av att data eller programkod följer formella regler: rätt antal tecken, rätt typ av tecken, rätt ordning, rätt format. – Se också validerare;
- – i it-säkerhet är validering kontroll av att en användare eller ett program har rätt att utföra en viss åtgärd. (Jämför med autentisering.)
– Se också robotfilter, ibland kallat valideringskod. – Validering kan syfta både på själva kontrollen och på intygandet av att kraven är uppfyllda.
[data] [it-säkerhet] [programmering] [språktips] [systemutveckling] [testning] [ändrad 21 mars 2022]
en metod för utveckling av datorsystem med betoning på överblick och successiva förbättringar. En viktig aspekt är att alla deltagare ska se hur projektet fortskrider. (Kanban är ett japanskt ord som betyder anslagstavla.) Alla deltagare uppmuntras att föreslå och genomföra rättelser och förbättringar. Kanban innebär också att man gör en sak i taget: nya arbetsuppgifter delas inte ut förrän de tidigare är avklarade. (Detta kallas för pull.) Principerna är hämtade från den japanska tillverkningsindustrin.
[systemutveckling] [ändrad 28 oktober 2012]
(CMM) – en avvecklad modell för utvärdering och förbättring av systemutveckling som process, utvecklad inom SEMA-initiativet vid Carnegie Mellon-universitetet. CMM utvecklades 1987—1997, och har ersatts av Capability maturity model integration, CMMI. – Syftet med CMM var att göra programutveckling till en ingenjörsmässig process (software engineering), som när man bygger en bro. Det har senare ifrågasatts ifall brobygge eller annat materiellt konstruktionsarbete är den bästa förebilden för programutveckling. – CMM klassade programutvecklande företags och myndigheters mogenhet i fem nivåer:
- – initial (slumpmässig, utan rutiner), även kallad chaotic;
- – repeatable (med styrning, baserad på erfarenheter);
- – defined (baserad på dokumenterade rutiner och procedurer);
- – managed (med löpande ingående utvärdering av både arbetet och resultatet) och:
- – optimizing (som ständigt tillvaratar erfarenheter och nya idéer för att förbättra arbetsgången och pröva nya lösningar).
– Företag kunde få sina programutvecklingsprocesser utvärderade och certifierade enligt CMM, men endast ett fåtal företag nådde den högsta nivån. Alla sådana certifieringar upphörde att gälla 2007. – CMM var också känt som SW-CMM – Capability maturity model for software.
[nerlagt] [systemutveckling] [ändrad 10 juni 2019]
domändriven design, förkortat DDD – principen att programutveckling ska vara nära knuten till det verksamhetsområde (domän, betydelse 2) som programmet ska användas i. Programmet ska på olika sätt återspegla den domän som det ska användas i, och experter inom området (domänen) ska känna igen sig. – Uttrycket domain-driven design myntades 2004 av Eric Evans i en bok med samma namn. – Se domainlanguage.com.
[programmering] [systemutveckling] [ändrad 14 september 2018]
(extreme programming, XP) – i programmering: ett arbetssätt som bygger på dagligt nära samarbete, ansikte mot ansikte, mellan en grupp programmerare och beställare. – Programmerarna arbetar i par. Man testar skriven kod mycket ofta (se test‑driven development), och utvecklar snabbt ett grovt fungerande komplett system som sedan finslipas i iterationer, det vill säga genom att hela systemet gång på gång omarbetas innan det levereras. Detta gör att man lätt kan anpassa systemet till ändrade krav. – Extremprogrammering kan ses som ett sätt att systematisera det sätt att arbeta på som programmerarna själva brukar föredra. – Läs mer på webbplatsen XProgramming. (Se också Dilbert) – Jämför med agil systemutveckling.
[programmering] [systemutveckling] [ändrad 10 juni 2020]
1939 – svensk expert på systemutveckling och objektorientering. – Ivar Jacobson deltog runt 1970 i utvecklingen av Ericssons AXE‑växel, och formulerade då principer för systemutveckling som anknöt till vad som senare blev känt som objektorienterad systemutveckling. Han blev särskilt känd för metodiken med användningsfall. Jacobson startade 1987 företaget Objectory som 1991 köptes av Ericsson och sedan, 1995, såldes vidare till amerikanska Rational, som i sin tur 2003 blev uppköpt av IBM. Under tiden på Rational utvecklade Jacobson tillsammans med två andra guruer inom objektorientering, Grady Booch och James Rumbaugh, UML, ett beskrivningsspåk för systemutveckling som blivit branschstandard. (De tre guruerna brukade kallas sig för ”The three amigos” efter en film med samma namn, se IMdB, länk.) De har också utvecklat Unified process. Se också practices. – Ivar Jacobson var vice vd på Rational men slutade strax efter dess uppgående i IBM för att bli fristående konsult. Han leder nu Ivar Jacobson International (ivarjacobson.com). – I början av 2010-talet har han tagit initiativ till Semat, ett enhetligt sätt att beskriva systemutvecklingsmetoder.
[it-historia] [ivar jacobson] [personer] [systemutveckling] [ändrad 12 augusti 2019]
beskrivning i stora drag av ett system av mjukvara. – Arkitekturen beskriver vilka komponenter som ingår i systemet, vad komponenterna ska göra, hur de fungerar ihop och hur hårdvara och användare påverkar systemet. – Termen används också om hårdvara i motsvarande betydelse. – På engelska: architecture. – Se också it‑arkitekt och abstraktion.
[systemutveckling] [ändrad 26 augusti 2021]
specialist på att utforma it-system så att de motsvarar kraven i den verksamhet de är avsedda för. – Uppgiften är att beskriva arkitekturen i stora drag, inte att realisera den i detalj. Man brukar skilja mellan olika typer av it-arkitektur:
- – Företagsarkitektur (enterprise architecture) beskriver företaget, dess delar och relationerna mellan dem;
- – Mjukvaruarkitektur (software architecture) är en utförlig beskrivning av de program och databaser som en organisation använder;
- – Infrastrukturarkitektur (infrastructure architecture) handlar om den grundläggande infrastruktur av datorer, servrar och datakommunikation som en organisation behöver;
- – Informationsarkitektur (information architecture) handlar om hur organisationens information ska hanteras, lagras, spridas och skyddas;
- – Verksamhetsarkitektur (business architecture) är kopplingen mellan företagsarkitekturen och verksamheten, så som den uttrycks i it-systemet.
– En internationell organisation för it-arkitekter är IASA.
[systemutveckling] [yrken] [ändrad 30 januari 2019]
(service-oriented architecture, SOA) – it-system som består av delar som lätt kan kombineras till olika applikationer. – Systemet byggs upp av delar (tjänster) med tydliga och avgränsade uppgifter (lön, kund, order) och dessa görs så att de lätt kan kombineras med varandra. Syftet är att en tjänst bara ska programmeras en gång i en organisation. – Tjänsteorienterad arkitektur kan ses som en reaktion på det faktum att många organisationer har många system som gör ungefär samma sak, men som inte fungerar ihop. I SOA sätts system vid behov ihop av komponenter i en behållare (container). Det som kallas för tjänster är alltså inte tjänster för slutanvändaren, utan tjänster i betydelsen färdigskrivna funktioner för programmeraren. – Dessutom ska de standardiserade gränssnitten göra det möjligt för program från olika leverantörer att utbyta tjänster direkt vid behov, utan att det behövs tilläggsprogram för översättning. – Tjänsteorienterad arkitektur är nära knutet till web services. Förkortas skämtsamt även till TjOA. – I mitten av 2010-talet började SOA‑trenden att ersättas av mikrotjänster – samma princip, men med mer finfördelade funktioner. – Jämför med informationsorienterad arkitektur.
[it-system] [soa] [ändrad 15 mars 2018]