Category: Kunskapsbank

UML är ett otroligt kraftfullt modelleringsspråk som innehåller en hel massa olika symboler med ett stort regelverk för hur dessa kan relateras till varandra. Allt detta är beskrivet i UML-specifikationen. För att göra UML lite mer lättillgängligt så har man … Continue reading
sysml

SysML är ett modelleringsspråk som utvecklas och förvaltas av OMG. Det är definierat som en UML-profil där men försökt minska UMLs tyngdpunkt på modellering av mjukvara till att göra modellspråket mer generellt och anpassat för att modellera hela system, mjukvara och hårdvara tillsammans.

SysML återanvänder 7 av UMLs 14 diagramtyper och lägger till två nya diagramtyper.

Andreas Hägglund har presenterat SysML för dataföreningens UML-nätverk och tog då fram denna introduktionspowerpoint till SysML.

process-till-kod

process-till-kodAndreas Hägglund håller kurser i bl.a. krav och UML åt Astrakan. En av dessa är UML för projektledare och kravställare. På tre dagar går man igenom 10 av UMLs 13 diagram. Jobbig kurs att hålla eftersom det blir så mycket diskussion kring vart och ett av diagramtyperna! Otroligt kul kurs att hålla, eftersom det bli så mycket diskussion kring vart och ett av diagramtyperna!

I vilket fall, det dyker alltid upp frågor kring hur man gör för att gå från verksamhetsprocess till användningsfall till kodat och testat system. Andreas har därför gjort en kort beskrivning av det.

från verksamhetsprocess till testat system

requirements

requirementsPå senare tid hörs det allt oftare att användningsfall är hopplöst ute, en omodern kravteknik. Att arbeta med användningsfall är vattenfallsorienterat och inte agilt. User stories däremot, det är minsann en agil kravteknik. Om jag får säga min mening kan agil systemutveckling, krav och användningsfall inte missförstås mer än så!

Vad som avgör om man arbetar agilt med kraven eller inte, är inte vilken form man dokumenterar kraven på (användningsfallsbeskrivningar och user stories är ju egentligen bara två olika sätt att dokumentera samma krav på).

Det är syftet med dokumentet som avgör om man är agil eller inte.

Skriver man krav för att som verksamhetsrepresentant slippa prata med utvecklarna, då arbetar man inte agilt.
Gör man däremot beskrivningen för att ha en utgångspunkt eller startpunkt för diskussion med utvecklarna. Då arbetar man agilt. Om man beskriver kraven som användningsfall, som user stories eller som traditionella
kravlistor har inget med saken att göra.

Andreas Hägglund har skrivit ett blogginlägg och ett dokument om detta.

Agil-kravhantering-1_0

Characteristics_of_Capability_Maturity_Model

 

Characteristics_of_Capability_Maturity_ModelSystemvaruhusets vision är att revolutionera IT-branschen genom att göra systemutvecklingsarbetet förutsägbart. För att uppnå förutsägbarhet så fördjupar vi kontinuerligt våra kunskaper inom tekniker som java och C#. För att kunna revolutionera branschen krävs det att fler än vi ändrar vårt arbetssätt. Vi delar därför med oss av vår kunskap, på webben, genom utbildningar och i våra uppdrag som konsulter.

 

CMM är framtagen av Software Engineering Institute (SEI) som är en delvis oberoende avdelning av Carnegie Mellon Universitetet. Det är ett federalt finansierad forsningscenter som betalas av det amerikanska försvarsdepartementet. Från början var det tänkt att modellen skulle användas för att bedömma om anbudsgivare hade någon möjlighet att leva upp till sina löften… Modellen kan dock även användas för att utvärdera, planera och genomföra processförbättringsprojekt. Den identifierar ett antal nyckelområden som behövs för att förbättringar ska kunna ske. Den första versionen av CMM för mjukvaruutveckling presenterades 1993. Idag finns det tre olika typer av processmognadsmodeller, SW-CMM (Software Engineering), SE-CCM (System Engineering), IPD-CMM (Integrated Product Development),
SA-CMM (Software Acquistion) och P-CMM (People). De tre förstnämnda integrerades i augusti 2002 i ytterligare en modell som kallas CMMI (Integration).

introduktion till capability maturity model

butterfly_ballot

 

butterfly_ballotSystemvaruhusets vision är att revolutionera IT-branschen genom att göra systemutvecklingsarbetet förutsägbart. För att uppnå förutsägbarhet så fördjupar vi kontinuerligt våra kunskaper inom tekniker som java och C#. För att kunna revolutionera branschen krävs det att fler än vi ändrar vårt arbetssätt. Vi delar därför med oss av vår kunskap, på webben, genom utbildningar och i våra uppdrag som
konsulter.

 

Form och användbarhet är viktiga komponenter i systemutveckling, de är helt avgörande för hur ett nytt system upplevs och tas emot av användarna. För expertsystem är det viktigt med ett pedagogiskt och genomarbetat användargränssnitt eftersom det är höga krav på snabbt och tydligt beslutsstöd.

form och användbarhet

Cocomo-Calculator

 

Cocomo-CalculatorSystemvaruhusets vision är att revolutionera IT-branschen genom att göra systemutvecklingsarbetet förutsägbart. För att uppnå förutsägbarhet så fördjupar vi kontinuerligt våra kunskaper inom tekniker som Java och C#. För att kunna revolutionera branschen krävs det att fler än vi ändrar vårt arbetssätt. Vi delar därför med oss av vår kunskap, på webben, genom utbildningar och i våra uppdrag som konsulter.

Cocomo (Constructive Cost Estimation Model) är en är en beprövad och statistiskt underbyggd modell för tidsuppskattning, framtagen av Barry Boehm. Modellen syftar till att förbättra tidsuppskattningen av utvecklingsprojekt. Tidsåtgången uppskattas genom att först uppskatta systemets storlek och sedan utvärdera projektgruppens effektivitet. Detta dokument syftar inte till att beskriva hela modellen utan listar endast de faktorer som Cocomo inkluderar för att utvärdera projektgruppens effektivitet.

cocomo

xp-model

 

xp-modelSystemvaruhusets vision är att revolutionera IT-branschen genom att göra systemutvecklingsarbetet förutsägbart. För att uppnå förutsägbarhet så fördjupar vi kontinuerligt våra kunskaper inom tekniker som java och C#. För att kunna revolutionera branschen krävs det att fler än vi ändrar vårt arbetssätt. Vi delar därför med oss av vår kunskap, på webben, genom utbildningar och i våra uppdrag som konsulter.

eXtreme Programming (XP) har uppstått som en reaktion på andra, alltför omfattande, processers misslyckande när det gäller att underlätta för projektgruppen att uppnå sina mål. Processen riktar sig i första hand till små projekt. Enligt Kent Beck, som är en av upphovsmännen, kommer ordet extrem i processens namn ifrån att man har tagit bort allting dåligt i processen och enbart behållt det som är bra men i gengäld gör man extremt mycket av de aktiviteterna.

Ledorden för arbetet är kommunikation, enkelhet, återkoppling och mod. XP är en ‘lätt’ process där man enbart gör de aktiviteter som direkt bidrar till slutproduktens kvalitet, exekverbarhet och förvaltningsbarhet. Arbetssättet och värdegrunden i processen är utformad i syfte att minimera byråkrati och onödigt arbete samt att minimera ‘cowboy-coding’ genom att betona vikten av ett disciplinerat angreppssätt för test, kommunikation och omarbete.

introduktion till extreme programming

DSDM_Atern_Project_Phases

 

DSDM_Atern_Project_PhasesSystemvaruhusets vision är att revolutionera IT-branschen genom att göra systemutvecklingsarbetet förutsägbart. För att uppnå förutsägbarhet så fördjupar vi kontinuerligt våra kunskaper inom tekniker som java och C#. För att kunna revolutionera branschen krävs det att fler än vi ändrar vårt arbetssätt. Vi delar därför med oss av vår kunskap, på webben, genom utbildningar och i våra uppdrag som konsulter.

 

DSDM är en publik metod som förvaltas av ett konsortium. Den utarbetades i början av 1990-talet (första versionen kom 1995) och är nu framme vid version 4.1. Det är en affärsdriven metod som täcker alla steg från affärsbehov till implementerat systemstöd. DSDM är en metod som frångår den klassiska vattenfallsmodellen och arbetar iterativt och inkrementellt (dock på ett lite annorlunda sätt än vad som beskrivs i t.ex. RUP). DSDM är baserad på RAD (Rapid Application Develoment) och har ett helhetsperspektiv, dvs metoden koncentrerar sig på att få ordning på helheten. Man förklarar tydligt vilka bitar som måste finnas och hur de hänger ihop, men man talar inte om exakt vad de innehåller. Det överlåts till metodanvändarna.

introduktion till dsdm