Systemutvecklingsmetoder vid fem IT-företag i Göteborg

Storlek: px
Starta visningen från sidan:

Download "Systemutvecklingsmetoder vid fem IT-företag i Göteborg"

Transkript

1 Handelshögskolan Göteborgs universitet Institutionen för informatik Systemutvecklingsmetoder vid fem IT-företag i Göteborg Med detta arbete har vi kartlagt olika utvecklingsmetoder, såväl iterativa som sekventiella för att ge större kunskap inom ämnet. Arbetet behandlar Binomens Luxus, Cap Geminis Perform, Ericsson Mobile Data Designs Darwin, Rationals Unified Process som används på Frontec och Ericsson-Hewlett Packard Telecommunications. Uppsatsen redogör för tankarna och strukturerna inom dessa metoder och beskriver även vad iterativt och sekventiellt arbete innebär. Frågor som besvaras är bl.a. vilka metoder som används, hur pass detaljerade de är, om företagen tagit fram dem själva eller köpt in dem, om man kan se några paralleller mellan företagens storlek, ålder och om de jobbar marknadsnära eller kundnära och metoden de använder sig av. Dessa frågor har besvarats genom att vi har gjort intervjuer på företagen och därefter fördjupat oss i deras metoder. Susanna Haikara Sofia Larsson Bodil Näsström Examensarbete I 10 p. ADB-programmet våren 1999 Handledare: Birgitta Ahlbom

2 2

3 Innehållsförteckning 1 INLEDNING PROBLEMBAKGRUND SYFTE PROBLEMDEFINITION METOD DISPOSITION TEORETISK BAKGRUND VAD ÄR EN SYSTEMUTVECKLINGSMETOD? VARFÖR BEHÖVS METODER? VATTENFALLSMODELLEN ITERATIV MODELL Boehm s spiralmodell INKREMENTELL UTVECKLING OBJEKTORIENTERAD MODELLERING UML - BOOCH, RUMBAUGH OCH JACOBSON FÖRETAGEN OCH DERAS METODER SYSTEMUTVECKLINGSPROCESSEN PÅ BINOMEN LUXUS SYSTEMUTVECKLINGSPROCESSEN PÅ CAP GEMINI Business Application Reference Manual IAD (Iterative Application Development) SYSTEMUTVECKLINGSPROCESSEN PÅ ERICSSON MOBILE DATA DESIGN (ERV) Darwin SYSTEMUTVECKLINGSPROCESSEN PÅ FRONTEC SYSTEMUTVECKLINGSPROCESSEN PÅ ERICSSON HEWLETT PACKARD TELECOMMUNICATIONS Rup RESULTAT JÄMFÖRELSE Iterativt kontra vattenfall Jämförelser mellan företagen DISKUSSION/SLUTSATSER EGNA KOMMENTARER REFERENSLISTA BILAGOR

4 1 Inledning 1.1 Problembakgrund Fram till 60-talet var datortekniken i sig så ny att det då inte fanns några systemutvecklingsmodeller. Under 70-talet arbetade man enligt utdataorienterade metoder, dvs. att man inriktade sig på vad systemet skulle producera. Metoder för att bygga system skapades från början enbart för stora företag där man normalt hade en god framförhållning och en systemutredning därför kunde ta ganska lång tid. I slutet av 70-talet fick dock även mindre företag möjlighet att skaffa egna datasystem varför en hel del nya metodansatser började diskuteras. Krav på detta slag av systemering är framför allt lågt pris och kort utvecklingstid. Systemeringen avser att skapa en modell av ett avgränsat verksamhetsområde, ett område inom vilket det finns problem som man skall lösa. Modellen skall vara så formaliserad att den kan ligga till grund för en eventuell datorrealisering. Modellen har även som syfte att utgöra ett kommunikationsmedel för de parter som är berörda av systemutredningen. Datorer har kommit att spela en allt större roll i systemutvecklingsprocessen. De hjälper till att snabbare klara av att producera dokumentation, att snabbare ta fram konsekvenser av förändringsförslag. Diverse CASE-verktyg har utvecklats för att stödja systemutvecklingsarbetet. 1.2 Syfte Detta arbete syftar till att kartlägga olika utvecklingsmetoder, såväl iterativa som sekventiella för att ge större kunskap inom ämnet. 1.3 Problemdefinition Vilka metoder används? Hur detaljerade är metoderna? Använder sig företagen av en redan existerande metod eller har de utarbetat en egen? Vad tar företagen med i beräkningarna när de skall bestämma sig för en viss metod? Kan man se några paralleller mellan storleken och ålder på företaget och metoden de använder sig av? Kan man se några paralleller om företagen arbetar kundnära 1 eller marknadsnära 2 och deras metod? 1 Med kundnära avses företag som utvecklar system och program för en specifik kund. 2 Med marknadsnära menar vi här företag som utvecklar standardsystem för marknaden, dvs ingen specifik kund. 4

5 1.4 Metod För att besvara våra frågor har vi läst litteratur runt ämnet systemutveckling. Det har varit svårt att få tag i relevant litteratur angående specifika metoder. Däremot har vi hittat en hel del bra böcker om systemutveckling i allmänhet. För att få reda på mer om moderna metoder som används i praktiken fick vi istället besöka och göra intervjuer på några av Göteborgs ledande IT-företag. Frågorna vi ställde till företagen återfinns i bilaga1. Vi kontaktade ett flertal företag och talade med de som visade intresse. Vi har besökt Pär Lagström på Frontec, Staffan Ehnebom på Ericsson Hewlett Packard Telecommunications, Anna Börjesson på Ericsson Mobile Data Design, Jan Windahl på Binomen och Jan Lindqvist på Cap Gemini. Vi har även fått ta del av deras metoder och det är dessa vi har fördjupat oss i. 1.5 Disposition Uppsatsen börjar med en inledande teoretisk del som skall ge bakgrundsfakta till vårt arbete. Här beskrivs de olika tillvägagångssätten vid systemutveckling. En del handlar även om UML (Unified Modelling Language) och dess skapare. Därefter följer en presentation av företagen vi har valt att titta på samt deras metoder. De sista sidorna tillägnas resultatet, jämförelser och våra egna slutsatser. 5

6 2 Teoretisk bakgrund 2.1 Vad är en systemutvecklingsmetod? Systemering avser att skapa en modell av ett avgränsat verksamhetsområde och att utgöra ett kommunikationsmedel för de parter som är berörda av systemutredningen. En metod är det konkreta tillvägagångssättet för att realisera en modell. Metoden är ett medel för att säkerställa kvalitén på systemet. Den ger även en gemensam notation som är viktig för att se till att alla som är involverade i projektet talar samma språk. Användandet av metoden ser också till att alla deltagarna i systemutvecklingsarbetet får en god överblick över systemet och kan följa arbetets gång. Thanos Magoulas hävdar att om en metod skall vara tillämpningsbar på ett företag måste den harmoniera med: begrepp målbild systemutvecklingsmodell paradigm systemdesign intressentmodell tekniker, dokumentationsform, verktyg regler/ vägledningsprinciper Figur 1 6

7 Inom systemutveckling brukar metoderna innehålla följande faser och beskrivningar på hur man skall göra. Analys: I den första fasen görs en verksamhetsanalys, eller en prestudy, som ligger till grund för kravspecifikationen som talar om vad system skall göra och inte göra. Slutprodukten av analysen är kravspecifikationen. Design: Under designfasen byggs en övergripande arkitektur och de olika delkomponenterna specificeras. Det är under den här fasen som själva byggritningen för systemet arbetas fram t.ex. dataflödesdiagram, relationsscheman, strukturdiagram osv. Realisering: I realiseringsfasen skapas systemet fysiskt efter de ritningar och specifikationer som togs fram under designfasen. Implementering: Systemet implementeras hos slutanvändarna. Test: Många olika typer av test utförs för att säkerställa att systemet gör det som det är skapat för att göra dvs. uppfyller de krav som togs fram under analysfasen. Underhåll: När systemet tagits i bruk måste det underhållas eftersom nya krav uppstår under användandet, fel hittas, vissa uppdateringar kan behöva göras och det kan finnas behov av att lägga till ny funktionalitet. Detta är grundstegen i alla systemutvecklingsmetoder som vi har tittat på. Hur de utförs och i vilken ordning varierar från metod till metod vilket vi kommer att beskriva längre fram. 2.2 Varför behövs metoder? Olika metoder skiljer sig mycket från varandra och strävar ofta mot olika mål. Exempel på mål: Få fram exakta krav för informationssystemet Effektivisera utvecklingsprocessen Få fram ett system i tid till rimlig kostnad Få fram bra dokumentation och ett system som är lätt att underhålla Få fram eventuella ändringar som behöver göras så tidigt som möjligt i utvecklingsprocessen Få fram ett system som alla berörda blir nöjda med 7

8 2.3 Vattenfallsmodellen Figur 2 Vattenfallsmodellen är sekventiell. Detta innebär att den består av ett antal olika faser och att man innan man övergår till nästa fas skall ha avslutat den föregående. Den ligger till grund för många av de metoder som existerar idag. De huvudsakliga faserna i modellen är: Kravanalys och kravspecifikation: I samarbete med kunden görs en analys av vad systemet skall göra och vilka problem som måste lösas. Detta sammanställs sedan till en kravspecifikation. Design: En övergripande arkitektur byggs och olika delkomponenter specificeras. Implementation och enhetstestning: De olika delkomponenterna utvecklas och varje enhet testas. Integration och testning: De olika delarna sätts samman och testas tillsammans för att verifiera att det fungerar. Användning och underhåll: Systemet installeras hos kunden och tas i användning. Nyupptäckta fel rättas och systemet anpassas ytterligare till att passa kundens krav. Tanken är att man skall passera de olika faserna i följd. 8

9 2.4 Iterativ modell Iterativa modeller går ut på att man successivt bygger fram systemet. Vid iteration kan man arbeta med mer än en fas åt gången medan man under sekventiellt tillvägagångssätt alltid gör färdigt en fas innan man påbörjar nästa. Man kan under vilken fas som helst gå tillbaka ett eller flera steg för att sedan upprepa stegen (till skillnad från sekventiell utveckling där man oftast gör färdigt hela vägen innan man kan gå tillbaka). Under iterativt arbete har man inte samma kontroll, som under sekventiellt arbete, på var man är i utvecklingen dvs. att man sällan har milstolpar som talar om vad som skall vara färdigt när, utan mer riktlinjer för vad som bör ha åstadkommits vid en viss tidpunkt. Därmed är det inte sagt att det måste vara färdigt eftersom man i iterativt arbete aldrig blir helt färdig eftersom man hela tiden förbättrar och bygger på systemet. 3 En iteration är en komplett utvecklingsloop som resulterar i en release av en körbar produkt, en del av den slutliga produkten som är under utveckling, som alltså växer inkrementellt från iteration till iteration för att till slut bli det färdiga systemet. Ett iterativt arbete innebär att man kan gå tillbaka och ändra i ett användningsfall utan att det påverkar ett annat. I och med att man skapar användningsfall kan man dessutom skapa ett gränssnitt för varje användningsfall. Detta sker tidigt i utvecklingsprocessen och det är bra att kunna visa upp för kunden vad denne har att vänta sig. Dessutom kan man rätta till små problem och önskemål mycket tidigt i utvecklingsprocessen. För att grafiskt se hur faserna följer varandra i en iterativ modell se figur Enligt Rational Software. För mer information gå in på Rationals hemsida 9

10 2.4.1 Boehm s spiralmodell Figur 3 Boehm tog 1988 fram en alternativ processmodell, spiralmodellen, som tar hänsyn till eventuella risker i utvecklingsprocessen. Varje varv i spiralen motsvarar en fas i utvecklingsprocessen. Dessa faser är inte förutbestämda, utan ledningen för projektet måste besluta hur projektet ska struktureras i olika delar. Varje varv eller fas delas i fyra sektorer: Målsättning: specifika mål för projektfasen definieras, liksom begränsningar i den övergripande utvecklingsprocessen, och en detaljerad projektplan dras upp. Risker för projektet identifieras och alternativa strategier beroende på dessa risker planeras. Riskbedömning och riskreducering: för varje identifierad risk görs en detaljerad analys, och åtgärder vidtas för att reducera risken. Utveckling och validering: en utvecklingsmodell väljs för systemet, t ex vattenfallsmodellen. Valet av modell bör utgå från de identifierade riskerna. Planering: projektet ses över och beslut fattas om man ska gå vidare med nästa fas (nästa varv i spiralen). Planer för nästa fas dras då upp. 10

11 Boehm föreslår ett standardformulär för varje varv eller fas som bör innehålla följande delar: Målet vilket beskriver vad man vill åstadkomma med analysen Begränsningar som kan minska möjligheterna till att lyckas med projektet Alternativ till olika sätt att uppnå målen Risker som är tänkbara med de alternativ man valt Riskresolution innebär strategier för att minimera riskerna Resultat är det som åstadkommits av arbetet under fasen Planering för hur man går vidare till nästa fas Åtagande innebär ett ledningsbeslut för hur och om man ska fortsätta 2.5 Inkrementell utveckling För att utveckla stora programsystem har man under ett antal år nu förordat vad man kallar en inkrementell programframtagning. Med detta menas att man istället för att göra färdigt ett helt programsystem med alla beställarens krav från början så koncentrerar man sig först på de mest centrala delarna och gör ett system som bara klarar dessa. 2.6 Objektorienterad modellering Objektorientering i sig är inte en metod utan snarare ett synsätt på hur man skall gå till väga för att modellera. När man arbetar objektorienterat delar man in den, för systemet, väsentliga delen av verksamheten i objekt. Dessa objekt har tillstånd, beteende och attribut. Attributen är objektets egenskaper, objektet person har t.ex. attributet kön. Ett av objektets attribut, eller en sammansättning av attribut, måste vara unikt för att man skall kunna identifiera instansen av klassen. Tillståndet är värdena på attributen. Beteende beskriver vilka handlingar objektet kan utföra. Genom att gömma både data och programkod inom objektet (inkapsling) uppnås både stabilitet och portabilitet. Detta innebär att objekten känner till varandras yttre egenskaper och kan därmed skicka och ta emot information sinsemellan. Däremot är ett objekts inre egenskaper skyddade från insyn. 2.7 UML - Booch, Rumbaugh och Jacobson UML (Unified Modelling Language) är ett standardiserat visuellt modelleringsspråk, men som ändå på ett smidigt sätt tillåter anpassningar till olika organisationer, utvecklingsprocesser och verktyg. UML beskriver samtliga vanliga begrepp och aspekter av objektorientering, men är samtidigt enkelt att anpassa och man kan själv bestämma hur mycket av UML man vill använda. UML har kommit att bli en standard både för att kommunicera modeller till människor och för att utveckla modeller med datorverktyg. UML är en sammansmältning av de metoder som skapats av de tre ledande guruerna inom modellering: Grady Booch (Booch-metoden), James Rumbaugh (OMT) och Ivar Jacobson (Objectory), som numer alla tre är anställda på programvaruföretaget Rational. 11

12 Samtidigt som Rational presenterar UML som världsvinnande metod släpper de version 4.0 av sin objektorienterade utvecklingsmiljö Rational Rose bestämde sig OMG (Object Management Group) för att det var dags att ta fram en standard för objektorienterade metoder. Grady Booch och James Rumbaugh satt vid det här laget båda på Rational som gör utvecklingsverktyget Rose och försökte bygga ihop sina standarder, Booch och OMT, till en. Sommaren 1995 kom Ivar Jacobson med och de blev the three amigos. Rational har satsat stort på att få sina skyddslingar att enas. Utvecklingsverktyget Rational Rose, har tidigare haft stöd för modellering med OMT och Booch. I den nya versionen, Rose 4.0, finns även stöd för UML. Dessa tre gurus har alltså förenats för att etablera ett standardiserat modelleringsspråk som ett första steg i att få ett slut på de sk metodkrigen. De har också presenterat en Unified Process, dvs en grundläggande process för hur själva utvecklingsarbetet ska gå till (vad ska göras, när ska det göras, hur ska det göras, och varför ska det göras), som heter RUP (Rational Unified Process). UML togs officiellt i bruk som standard av OMG En mycket intressant mekanism som införts i UML är begreppet stereotyper. En stereotyp är en anpassning av ett visst modellelement, där utvecklaren själv kan definiera ytterligare semantik (betydelse) till ett redan existerande modellelement. En stereotyp kan även tilldelas en egen ikon så att den har ett unikt utseende i modellen. Genom stereotyper kan UML anpassas till en viss typ av verksamhet, en viss typ av system, eller en viss typ av utvecklingsmiljö (exempelvis ett visst programmeringsspråk). Stereotypbegreppet har lagt grunden för att olika dialekter kommer att utvecklas. Som det mesta i UML är också stereotyper öppna, det vill säga inget hindrar ett företag att utöka klassningen med rapportklasser, styrklasser och så vidare. Hur man använder UML är en öppen fråga, det är ju ett modelleringsspråk. Enligt Ivar Jacobson är det framträdande med UML att det först och främst är baserat på användningsfall. Det är dessutom iterativt och inkrementellt. De tio första iterationerna går ut på att hitta rätt arkitektur. De därpå följande iterationerna innebär att hitta rätt programvara. Utvecklingen sker i steg och varje steg skall resultera i en körbar prototyp. Grady Booch sammanfattar problemen runt modellering i fyra punkter i en artikel i Unix Review (12/96). Valet av modell har avgörande betydelse för vilket sätt ett problem kommer att angripas på och vilken form lösningen får. Ingen enskild modell är tillräcklig; det bästa sättet att angripa ett komplicerat system är att titta på det från olika håll. Alla modeller kan uttryckas på olika abstraktionsnivåer. De modeller som fungerar bäst är de som har den bästa verklighetsförankringen. I och med UML, the Unified Modeling Language, ska dessa problem vara lösta. Verktygsstöd 12

13 I och med att definitionen av UML släpptes relativt nyligen, så har ännu inte verktygstillverkarna hunnit med att implementera fullt stöd för språket. Många CASE-verktyg har idag stöd för UML och genom att använda CASE-verktyg så fås maskinstöd för att enkelt skapa modeller i UML, navigera och söka i komplexa system, dokumentera modeller samt även mer avancerat stöd såsom kodgenerering, versionshantering och spårning av krav i system. 13

14 3 Företagen och deras metoder 3.1 Systemutvecklingsprocessen på Binomen Binomen är ett relativt litet företag (19 anställda) som arbetar med administrativa system dvs. anpassningar av ekonomisystemet Pyramid och teknisk systemutveckling (på Ericsson Microwave och Volvo) De arbetar även med RCC (Rational Competence Center) vilket innebär att de hjälper kunderna med process, metod och verktygskunnande. Binomen arbetar alltid objektorienterat. Endast då kunden kräver det används strukturerad programmering, men utvecklingsarbetet sköts tills största delen ändå objektorienterat. Binomen använder sig av en egen utvecklad systemutvecklingsmodell, Luxus. Systemutvecklingsprocessen bygger på ett användningsfallsbaserat och objektorienterat synsätt som stöds av RUP (Rational Unified Process). Inför varje projekt skall denna metod konfigureras av projektledaren för att passa projektet (detta görs i första aktiviteten). Milstolparna skall passeras sekventiellt, även om en del faller bort eller tillkommer under konfigureringen. Tollgatesen är knutna till Binomens projektstyrningsmodell. Binomen håller även på att utveckla en light version av Luxus som skall vara till för kortare och mindre projekt och som bara skall innehålla några moduler ur Luxus. Luxus är alltså sekventiell (momenten kan dock genomföras iterativt). Detta kan låta lite konstigt då Rational s RUP (som Luxus bygger på ) är iterativ och hårt trycker på fördelarna med just iterativt arbete. Detta ses dock inte som någon konflikt, utan som Jan Windahl på Binomen säger: Luxus har fått ett sekventiellt utseende eftersom den är hårt knuten till vår projektstyrning. RUP:s iterativa delar framgår inte riktigt tydligt i Luxus - det är korrekt, men vi har hittills inte upplevt detta som ett problem i de mindre och medelstora projekt som vi tillämpat Luxus på. Vi brukar försöka åstadkomma iterativ parallellism, genom realisering av s.k. återkopplande pilot-användningsfall. De återkopplande pilot-användningsfallen innebär att man väljer ut ett eller ett par representativa användningsfall som man kör i botten, inkluderande implementation och test, innan man slutför det resterande analys och designarbetet. På detta sättet så säkrar man i förväg upp att de tekniska ansatserna i arkitektur och målmiljö kommer att fungera som man har tänkt. Det är även svårt att urskilja när (i vilken/vilka) aktiviteter som själva kodningen utförs. Jan Windahl förklarar detta så här: Kodning och kodgranskning kan idag se väldigt olika ut beroende på vilka verktyg och vilken målmiljö som man väljer. Vi har inte velat låsa fast oss i någon specifik miljö och därför så är processen lite vag/flexibel på denna punkten. Men om man exempelvis väljer C++, VB, eller Java(J++) så skapar vårt huvudverktyg (Rational Rose) färdiga kodskelett för alla klasser och metoder på ett 14

15 mycket kraftfullt sätt. Det räcker oftast med att modellen granskas och bedöms den vara korrekt så blir faktiskt koden oftast därefter. Embryot till Luxus föddes redan 1993 då Binomen bildades och den har därefter utvecklats och den version som används idag var färdig Eftersom Binomen har använt sig av Luxus sedan starten 1993 kan man inte påvisa några effektiviseringar av användandet av Luxus jämfört med någon annan modell. Dock kan de se vissa effekter av Luxus hos de företag som Binomen sålt Luxus till. Under det allra första projektet, då modellen implementeras på ett företag, brukar både tidsmängden och kostnaderna öka, men detta skall man sedan få igen genom en ökad kompetens som i följande projekt skall spara både tid och pengar LUXUS Tollgate 1- Projektstart Aktivitet- Process och verktygskonfiguration, dvs hur systemutvecklingsprocessen (Luxus ) samt dess verktyg skall användas i projektet. Verktyg- Word, SoDA, Clear Case Resultat- Utvecklingsfallsbeskrivning/Development Case Description Milstolpe 1- utvecklingsfallsbeskrivingen är klar och godkänd. Aktivitet- Ordlista, dvs en ordlista med utmärkande begrepp och termer för projektet skapas. Verktyg- Word Resultat- Ordlista/Glossary Milstolpe 2- ordlistan godkänd Tollgate 2 a- Start av analysarbetet Aktivitet- Verksamhetsanalys, dvs hur den verksamhet där ett tänkt informationssystem kan komma att spela en roll. Verktyg- Word, Balance Scorecard Resultat- Verksamhetsbeskrivning/Business Process Description Milstolpe 3- Verksamhetsbeskrivningen klar och godkänd av kund. Aktivitet- Kravspecifiaktion, dvs vilka speciella krav som skall ställas på systemet. Verktyg- Rose, Requisite Pro, SoDA, UML-train Resultat- Kravspecifikation/ Supplementary Specification Milstolpe 4- Kravspecifikationen klar och godkänd av kund. Aktivitet- Användningsfalls analys ( Use case scenario), dvs hur aktörer (människor eller andra system i verksamheten skall interagera med det tänkta informationssystemet för att erhålla önskad funktionalitet. Verktyg- Rose, Requisite Pro, SoDA, UML-train Resultat- Användningsfallsbeskrivning/ Use Case Description Milstolpe 5- Användningsfallsbeskrivningen klar och godkänd av kund. Aktivitet- Arkitekturanalys och design, dvs indelning av systemet i logiska delsystem. 15

16 Verktyg- Rose, SoDA, Apex Resultat- Preliminär designmodell, arkitekturbeskrivning/architectural description Milstolpe 6- Arkitekturbeskrivningen klar och godkänd av kund. Tollgate 2 b- Start av realisering Aktivitet- Prototyping av användargränsnitt, dvs en prototyp av det grafiska och logiska gränssnittet mot användaren. Verktyg- Visual Basic, Visual C++, Delphi, Smalltalk, Word Resultat- Granskningsprotokoll från kundens genomgång av prototypen Milstolpe 7- GUI-prototypen granskad och godkänd av kund. Aktivitet- Testfallsanalys, dvs hur användningsfallen i användningsfallsmodellen skall testas för önskad funktionalitet skall anses vara verifierad. Verktyg- SQA Suite, Word Resultat- Testfallsbeskrivning/Test Case Description and procedures Milstolpe 8- testfallsbeskrivningen klar och godkänd av kund. Aktivitet- Användningsfall och objektdesign (systemdesignen) dvs vilka klasser som det tilltänkta informationssystemet skall kunna hantera för att uppfylla specificerade användningsfall. Verktyg- Rose, SoDA, Apex, Word Resultat- Desigmodell, Klassbeskrivning, Designregler Milstolpe 9- Designmodellen klar och godkänd. Milstolpe 10- Klassbeskrivningarna klara och godkända. Milstolpe 11- Designreglerna klara och godkända. Tollgate 2c- Leveransplan Aktivitet- Releaseplanering. Denna aktivitet utförs inkrementellt i varje steg och beskriver i vilken ordning som olika användningsfall med tillhörande systempaket skall designas, implementeras och testas. Verktyg- Word, SoDA Resultat- Releaseplan Milstolpe 12- Releaseplanen klar och godkänd av kund. Aktivitet- Implementationsplanering, dvs hur olika objekt eller paket av objekt föreslås bli tekniskt implementerade (utvecklingsmiljö, fönsterdesign, klassbibliotek, databas struktur, målmiljö mm.) Verktyg- Word Resultat- Implementationsförslag Milstolpe 13:n- Implementationsförslagen klara och godkända för alla i releasen n berörda användningsfall. Tollgate 3- Start av systemimplementering Aktivitet- Implementering, dvs implementation och test av nya kodavsnitt. Verktyg- Rose, Apex, SoDA, Purify, SQA Resultat- Körbara moduler (källkodsfiler) 16

17 Milstolpe 14 :n- Implementering och test klar och godkänd för all kod till alla i releasen n berörda användningsfall. Aktivitet- Användningsfallstestning inklusive felrättning, dvs testning och verifiering av funktionalitet enligt testfallsbeskrivning- inklusive hjälptexter. Verktyg- SQA Suite, Quantify, PreVue, Test Mate, SoDA Resultat- Granskningsprotokoll Use Case Test Milstolpe 15:n- Användningsfallstest klar och godkänd för alla i releasen n berörda användningsfall samt berörda icke-funktionella krav. Aktivitet- Systemtest inklusive felrättning, dvs testning och validering av (del)systemet i målmiljön enligt testfallsbeskrivningen. Verktyg- SQA Suite, Quantify, PreVue, Test Mate, SoDA Resultat- Granskningsprotokoll- Systemtest Milstolpe 16:n- Systemtest klar och godkänd för alla i releasen n berörda användningsfall samt berörda icke-funktionella krav. Aktivitet- Kunddokumentation, dvs all användar- och underhållsdokumentation. Verktyg- Word Resultat- Användar och underhållsdokumentation Milstolpe 17:n Användar- och underhållsdokumentaion klar och godkänd för alla i releasen n berörda användningsfall. Tollgate 4a...n- Accepterad (del)leverans. Aktivitet- Leverans, dvs kundens mottagande av delsystemet. Verktyg- Word Resultat- Acceptanstestprotokoll Milstolpe 18:n- Releasen n levererad med godkänd acceptans test utförd tillsammans med kund. Aktivitet- Utbildning, dvs kundutbildning på användningen av (del)systemet. Verktyg- Word Resultat- Kursmaterial, kursutvärderingar Milstolpe 19:n- kursutvärderingen sammanställd efter genomförd utbildning av användare på alla i releasen n berörda användningsfall. Tollgate 5a- Accepterad slutleverans Aktivitet- Slutleverans, dvs Revidering av utvecklingsfallsbeskrivningen inklusive efterkalkyl. Verktyg- Word Resultat- Reviderad utvecklingsfallsbeskrivning samt avslutsrapport Milstolpe 20- Intern avslutsrapport samt uppdaterad utvecklingsfallsbeskrivning. Tollgate 5b- Projektavslut Aktivitet- Avslut (inklusive eventuell garantitid), dvs formellt avslut av projektet. Verktyg- Word, Balance Score Card Resultat- Sammanställning av alla (garanti)aktiviteter samt ekonomiskt utfall för kunden baserat på vidtagna åtgärder Milstolpe 21- Utvärdering av sammanställda garantiaktiviteter. 17

18 3.2 Systemutvecklingsprocessen på Cap Gemini Cap Gemini är Europas och ett av världens största IT- och managementkonsultföretag. I Norden finns Cap Gemini på ett fyrtiotal orter med sammanlagt medarbetare. Cap Gemini är certifierat enligt ISO 9001 med tillägg för TickIT. Cap Geminis verksamhet är uppdelad i två stora huvudområden: Projekt- och ansvarsuppdrag som utgör ca 30-40% av verksamheten och innebär att Cap Gemini själva bistår med projekledare, metoder och tar ansvar för slutresultatet. Kompetensförstärkning som innebär att Cap Gemini säljer konsulter till kunden och att det därmed är kunden som tar ansvar för slutresultatet samt att det är kunden som beslutar om vilka metoder som skall användas. Cap Gemini använder sig av en övergripande metod som de kallar Perform som innehåller modeller för varje slags verksamhet som Cap Gemini ägnar sig åt. Perform används slaviskt under alla aktiviteter, men eftersom Perform är uppbyggd av flera moduler kan den anpassas till varje projekt. Figur 4 Perform är en systemutvecklingsmetod som bygger på best practice, de modeller som ingår i Perform bygger på bl.a. Vattenfallsmodellen, Reflex och Logic och en iterativ modell. 18

19 Reflex och Logic är kända modeller som användes av de forna företagen Programmator och Datalogik som idag ingår i Cap Gemini. Perform började utvecklas 1991 och då fokuserade man sig på att modellen skulle vara ett hjälpmedel för att hålla tidsramar, budget och möta kundens krav. Viktigt var också att man skulle kunna använda modellen internationellt då Cap Gemini arbetar över hela världen, därför var ett gemensamt vokabulär en viktig aspekt. Efter 1994, då Perform vidareutvecklades, fokuserade man sig på leveransen för att ha förmåga att leverera i tid. Tidigare hade ansvarsprojekten en stor over-run (som innebär skillnaden mellan förkalkylerad tidsåtgång och resultatet), men efter att Perform togs i bruk är det mycket små avvikelser både vad gäller budget och leveranstid. Cap Gemini använder regelbundet quality metrics för att mäta kvalitén på sina produkter och har fått mycket bra betyg från sina kunder. Perform är Cap Geminis projektstyrningsmodell och den består av en mängd olika moduler som gör att den går att anpassa till alla olika projekt som Cap Gemini arbetar med. Metoderna som används beskrivs som livscykler. Performs livscykler är beskrivna i referensmanualer som generellt innehåller: Processmodell (som visar strukturen för en livscykel) Register för uppgifter (som beskriver de föreslagna faserna, uppgifterna och aktiviteterna) Register för resultat (beskriver hur man ska komma fram till resultatet) Register för tekniker (ger förslag på rekommenderade tekniker) Ordlista och bibliografi De bitar av Perform som vi har tittat närmre på är Business Application Reference Manual och Iterative Application Development Business Application Reference Manual Business Application Reference Manual är en del av Perform som används vid utveckling av affärssystem. Den måste användas ihop med Performs Project Management Reference Manual. Den passar för alla storlekar av affärssystemsapplikationer och uppmuntrar prototyping. Den är främst ett verktyg för projektledare som planerar utvecklingen för ett projekt, men används även av personal som deltar i utvecklingen för att visa deltagarnas ansvarsområden. En affärssystemsapplikation har ofta följande särdrag: Konventionell struktur, dokumentdriven, består av både automatiska och manuella systemelement (med möjlighet att länkas till andra existerande system), ingen 19

20 förutbestämd systemmjukvara, programutvecklingsspråk, användargränssnitt eller dialogprotokoll. Man kan använda referensmanualen för affärssystem ensamt eller i kombination med andra referensmanualer för att ta fram en bild av nödvändiga aktiviteter och detta kan utföras sekventiellt eller parallellt. Den kan t.ex. föregås av en Pre-study eller Clients request, ha blivit initierat från ett systemintegrationsprojekt eller kräva användande av någon annan livscykel som t.ex. Training Development and Delivery Reference Manual eller Application Conversion Reference Manual. Referensmanualen delar in deltagarna i nio olika roller: Projekt manager, Project quality manager, Development team, Client authority, User representative, User team, Business expert(s), Technical expert(s) och External quality authority. Ansvaret delas upp i fem olika nivåer: R = Responsible, E = Executes, P = Participates, V = Verifies, A = Approves. Rollerna och ansvarsnivåerna visas sedan i matriser i de olika skeendena. Layout standards Processmodell Framsidan av processmodellen visar faser, uppgifter och aktiviteter ihop med resultat och ansvar i diagramform. Baksidan av processmodellen visar en helhetsbild av hela livscykeln och tar bara med och faser och uppgifter. Uppgiftsregister (Directory of tasks) Detta är ett register som är strukturerat i faser och tillhandahåller en överblick över varje fas och en beskrivning av dess uppgifter. Teknikregister (Directory of techniques) Detta innehåller tabeller som beskriver olika grupper av tekniker och som utförligt beskriver hur en enskild teknik används för ett visst ändamål. Resultatregister (Directory of deliverables) Resultatet är ett dokument som genereras vid slutförandet av en uppgift eller aktivitet. Det kan bestå av beskrivningar, diagram, listor och tablåer. Anpassning En livscykel anpassas efter det arbete som skall göras och det kan innebära att man tar bort en hel fas, kombinerar olika faser, aktiviteter och uppgifter, lägger till eller tar bort uppgifter och aktiviteter, upprepar faser eller uppgifter (t.ex. för sub-system) sträcker uppgifter och resultatdokument över fasgränserna. 20

21 Dessa beslut skall tas av projektledaren när planen för hela projektet läggs upp. Alla väsentliga anpassningsbeslut måste justeras i projektkvalitetsplanen (PQP) som är ett aktivt kontrolldokument där projektledaren sätter upp ramverket för projektet. PQP:n måste beskriva begränsningar och mål för både projekt och system, den globala projektplanen och nyckeldokumenten, projektets organisation och ansvarsområden, utvecklingsprocessen (faser, uppgifter och aktiviteter), projektledningsprocessen och kontrollprocessen. Verifikation och validering Verifikation är en process där man kontrollerar och bekräftar att ett resultat har producerats professionellt eller att en process har utförts i enlighet med överenskomna standards. Validering är den process där man bekräftar att det som är beskrivet i resultatdokumentet kommer att tillföra en adekvat lösning till systemet och lösa kundens problem. Uppgiftsregister (Directory of tasks) Uppgiftsregistret är indelat i fyra faser: Kravspecifikation (Requirements definition) Funktionell design (Functional design) Teknisk design (Technical design) Realisering (Build) Kravspecifikation Målen med denna fas är att: Fastställa alla målsättningar för system och organisation och möjligheter till förbättring. Fastställa detaljerade krav för det nya systemet. Modellera dessa krav grafiskt Försäkra sig om att inga krav är förbisedda i det nya systemet. Validera föregående schema, kostnads- och riskanalys. Kravspecifikationen innehåller följande steg: uppdatera PQP definiera systemkrav analysera nuvarande system analysera nuvarande organisation genomgång av teknologisk bas producera systemkravsmodell 21

22 Funktionell design Målen med funktionell design är att förse kunden med en komplett funktionell modell av den rekommenderade systemlösningen, förse tekniska designers med en detaljerad funktionell specifikation som bas för den tekniska designen av systemet, bekräfta systemkonfigurationskraven och för att kunna planera nästa fas (teknisk design). Funktionell design innehåller följande steg: uppdatera PQP skapa övergripande funktionell specifikation skapa systemkonfiguration skapa detaljerad funktionell specifikation definiera andra systems förändringsstrategier definiera organisationsförändringsstrategier motivera funktionell design definiera testningsstrategi producera plan över datakonvertering producera utbildningsplan Teknisk design Målet med teknisk design är att ta fram alla nödvändiga detaljer för att möjliggöra för specialister att konstruera och testa det efterfrågade systemet (eller sub-systemen) i realisationsfasen. Teknisk design innehåller följande steg: uppdatera PQP skapa detaljerad teknisk specifikation utveckla implementationsplan planera and specificera systemtest specificera modifieringar till andra system specificera manuella procedurer motivera teknisk design planera and specificera godkännandetest specificera verktyg för datakonvertering specificera utbildning Realisering Målet med realisering är att konstruera operationella systemprocesser, utföra tester på dessa, modifiera andra system (där så är nödvändigt), utveckla konverteringsverktyg och 22

23 utbildningsmaterial och utveckla nödvändiga procedurer för att hantera den fysiska implementeringen av systemet. Realisering innehåller följande steg: uppdatera PQP planera och specificera länktest skapa systemmanualer I varje steg av de fyra faserna (kravspecifikation, funktionell design, teknisk design och realisering) beskrivs vad man ska ha med sig in i varje nytt steg (vilka dokument) och vad som skall produceras. Varje steg delas in i ett antal aktiviteter som skall utföras och varje steg valideras och verifieras IAD (Iterative Application Development) Cap Gemini har investerat i och utvecklat en ny systemutvecklingsansats vars mål är att uppnå en högre grad av tillfredställda kunder genom: att möta kundens förväntningar få snabbare leveranstid att minska utvecklingskostnaderna Denna nya systemutvecklingsansats är designad runt en IAD-livscykel. IAD baseras på följande tekniska koncept: prototyping arkitektur design GUI design Återanvändning Objektorientering kan också användas som en systemutvecklingsteknik. Livscykeln består av ett fåtal faser som exekveras på ett iterativt sätt (se Figur 4:). Vid varje iteration genereras (och i vissa fall implementeras) en pilot. Erfarenheterna från föregående pilot influerar utvecklingen av efterföljande piloter. Följande ansatser används vid iteration beroende på situationen: Evolutionary strategy I denna strategi inkluderas alla tre faserna i varje iteration. Denna strategi reflekterar huvudkonceptet som ligger bakom en iterativ utveckling som kan summeras: att analysera lite, designa lite, koda/testa lite, implementera lite och därefter upprepa processen. 23

24 Incremental Delivery I denna ansats är alla krav fullt specificerade från början och iteration används för att bygga och leverera systemet inkrementellt genom att man fokuserar på de krav som kommer att ge kunden de snabbaste fördelarna. Incremental Build I denna ansats använder man iteration på de två första faserna av livscykeln. Detta innebär fördelar i utvecklingsprocessen av de piloter som genererats under utvecklingen, men inget installeras förrän hela systemet är färdigt. Management techniques Figur 5 IAD livscykeln kräver vissa ledningstekniker: Joint application development Tillämpningen av workshops där användare och utvecklare tillsammans kommer överens om krav och specifikationer är typiska. Workshops leder till snabbare utvecklingscykel, realistiska specifikationer, färre dokument vid varje milstolpe och färre formella valideringsaktiviteter. Olika typer av workshops används genom IAD-livscykeln för att uppmuntra team-work och för att underlätta beslutsfattande i realtid: joint development strategy joint requirements definition join pilot design 24

25 joint review and testing joint feedback collection joint acceptance Under workshops är det uppenbarligen viktigt att ha de mest effektiva deltagarna. A-teams Ett A-team består av ansvarsfulla, utbildade och duktiga utvecklare med en hög grad av samarbetskänsla som tillsammans har kunskaperna som behövs för att analysera, designa, bygga och implementera systemet. Beroende på storleken på projektet kan det finnas flera A-team som arbetar parallellt. Time-boxing Time-boxing är gensvaret på behovet av snabb systemutveckling och härmed kan ett leveransdatum sättas. Time-boxing kan också utföras inom utvecklingsprocessen för att färdigställa valda delar av systemet inom en given tidsram. Det är viktigt att användarens förväntningar är klargjorda för varje time-box. Användarna måste förstå att snabb leverans och stegvis leverans av systemet innebär begränsad funktionalitet i delrelease. Development techniques IAD ansatsen uppmuntrar användandet av olika utvecklingstekniker som är relevanta för storleken och stilen på ett projekt. Prototyping Under workshops och utvecklingsuppgifter används prototypingverktyg för att bygga olika prototyper. Vissa av dessa prototyper kan modellera det externa beteendet hos systemet likväl som den interna arkitekturen. Det finns tre olika typer av prototyper: exploratory prototyping evolutionary prototyping operational prototyping 25

26 Architecture design IAD livscykeln förespråkar en öppet och strukturerad systemarkitektur när det gäller systemutveckling. En sådan arkitektur tillför flexibilitet som är ett måste i dagens miljöer. Denna flexibilitet fås genom: portabilitet utbyggbarhet testbarhet Arkitekturen bör vara så pass flexibel att den är oberoende av plattformar och nätverk. En väldefinierad arkitektur tillför också en bra bas för återanvändning och underhåll. Graphical user interface(gui) design GUI handlar inte bara om kosmetik utan effektiv GUI design är viktigt då den tillför konsistens i utseendet på applikationerna lättare och mer produktiv användarsamverkan användarkoordination Inom IAD livscykeln används GUI design och prototypingverktyg under workshops för att specificera och validera användarsamverkan. Object orientation Figur 6 IAD-livscykeln kan appliceras med hjälp av objektorienterad teknik. Objektorientering överensstämmer med mänskliga koncept genom att den representerar strukturen, dynamiken och semantiken i den verkliga världen genom abstrakta entiteter. En fördel med objektorientering är att den klarar av komplexitet och förändringar och uppmuntrar återanvändning. Den primära enheten i objektorienterade system är klassen som representerar den gemensamma strukturen och beteendet hos en grupp objekt. Varje objektorienterat system kan därför ses som en samling av objekt som infriar vissa skyldigheter genom aktivt samarbete med andra objekt för att nå önskad funktionalitet. 26

27 Målsättningen med objektorienterad strukturering är att klara av komplexiteten i systemet genom att organisera klasser av objekt i arvshierarkier för att utforska deras likheter samtidigt som man separerar deras ansvarsområden. Andra viktiga objektorienteringskoncept är: inkapsling polymorfism meddelande överföring dynamiska bindningar Tack vare dessa principer är objektorienterad teknik passande för iterativ utveckling genom att den förenklar uppdelandet av problem i mindre bitar, underlättar designen av arkitekturen och ökar produktiviteten. Reuse Återanvändning ses ofta som nyckeln till produktivitet (genom att man kan leverera system med mindre arbete, färre fel och mindre testning). Alla delar av en lösning bör vara återanvändningsbara, även sakkunskap. Korttidsåteranvändning kan förbättra: effektiviteten pålitligheten Återanvändning uppmuntrar team-work eftersom den kräver en gemensam kultur och kunskapen att bygga vidare på någon annans arbete. Tools Det finns en hel del verktyg tillgängliga idag för att stödja dessa tekniker och för att ta hand om komplexiteten. Bland dessa verktyg hittas: 3GL- och 4GL-språk databasmiljöer GUI verktyg Prototypingverktyg Objektorienterade verktyg och bibliotek Dessa verktyg gör det möjligt att samordna utbildning och optimal återanvändning. 27

28 Method components PERFORMs referensmanual för IAD är en modul i PERFORM. Den beskriver en metod (i form av en livscykel) som tillhandahåller en ansats för strukturering av och hur man leder projekt. Denna ansats tillhandahåller en föreslagen struktur och en serie av de mest troliga faser, uppgifter och aktiviteter som krävs för att skapa de produkter som förväntas av utvecklingsprocessen (dokument, prototyper osv.) och till sist den färdiga produkten. PERFORMs livscykler är beskrivna i referensmanualer som generellt innehåller: en processmodell (som visar livscykeln i bild) ett register för uppgifter (beskriver hur man kan bryta ner faser, uppgifter och aktiviteter) ett register för dokument (beskriver hur man bör producera dokumenten) ett register över tekniker (ger råd om vilka tekniker man bör använda) Strukturen i referensmanualen för IAD är väldigt lik strukturen ovan, men det finns några skillnader p.g.a. följande: ansatsen som beskrivs är väldigt ny och behöver därför några specifika detaljer i dess presentation för att tillhandahålla en klar uppfattning för det underliggande konceptet manualen är en tidig utgåva som kommer att bli förbättrad med tiden, därför kan vissa delar vara oklara eller sakna vissa detaljer Process model IADs processmodell presenteras inte för sig själv utan är inbakad i IAD manualen. Processmodellen visar faserna och uppgifterna i diagramform tillsammans med de viktigaste iterationerna och de centrala workshops som bör hållas. IAD livscykeln kan användas på två olika situationer beroende på den huvudsakliga utvecklingstekniken som används (antingen konventionella tekniker eller objektorienterade tekniker). Directory of tasks Uppgiftsregistret är strukturerat efter faser och ger en överblick över varje fas och tillhandahåller en beskrivning av motsvarande uppgift. Överblicken över fasen visar fasens huvudsakliga mål, inledning, logiska grund och de centrala dokumenten. Den innehåller också dependency diagram och tillhandahåller råd om hur man skall använda sig av tuning och iteration inom fasen. 28

29 Varje uppgiftsbeskrivning innehåller följande avsnitt: en uppgiftsöverblick iterations riktlinjer tuning riktlinjer råd och kommentarer återanvändnings riktlinjer en verifikations- och valideringschecklista inputs och outputs referenser till relevanta standards och tekniker en aktivitetslista Directory of techniques Denna presenterar en kort beskrivning om vilka tekniker som kan användas under iterativ systemutveckling. Den innehåller tre grupper av tekniker: vanliga tekniker (vilkas användande är oberoende av objektorientering) konventionella tekniker (relaterat till systemmodellering) objektorienterade tekniker (ersätter konventionella modelleringstekniker när det passar i projektet) Tabellen nedan visar listan av tekniker och till vilken grupp de hör. Figur 7 29

30 Directory of deliverables Resultatet är ett dokument som genereras vid slutförandet av en uppgift eller aktivitet. Det kan bestå av beskrivningar, diagram, listor och tablåer. Andra egenskaper Iteration och anpassning (tuning) På grund av IAD livscykelns cykliska natur kan vissa uppgifter upprepas under den första iterationen, men sedan inte alls under de efterföljande iterationerna (och vice versa). Anpassning av en livscykel går ut på att anpassa fasernas, uppgifternas och aktiviteternas ramverk efter det arbete som skall göras. I IAD livscykeln kan det göras på följande sätt: flytta på fasgränser repetera faser eller uppgifter tillämpa parallell utveckling där det passar eller behövs utöka uppgifter och dokument över fasgränserna kombinera uppgifter och dokument ta bort eller lägga till uppgifter och aktiviteter flytta eller lägga till valideringar och granskningar till risker associerade med utvecklingen Vissa av dessa beslut bör tas tillsammans under en utvecklingsstrategi workshop andra beslut tas av projektledaren då man skapar delar av den detaljerade arbetsplanen för en specifik fas. Alla signifikanta anpassningsbeslut bör beskrivas i PQP:n (project quality plan) Verifikation och validering Verifikation är en process där man kontrollerar och bekräftar att ett resultat har producerats professionellt eller att en process har utförts i enlighet med överenskomna standards. Denna process kan utföras manuellt eller med hjälp av automatik beroende på de verktyg som används. Validering är den process där man bekräftar att det som är beskrivet i resultatdokumentet kommer att tillföra en adekvat lösning till systemet och lösa kundens problem. Speciella mätningar kan göras för att ge effektiv validering som t.ex. att hålla workshops och använda olika sorters prototyper. Återanvändning Återanvändning begränsas inte bara till mjukvarukomponenter utan det kan även omfatta alla designdelar som används under hela livscykeln. Därför innehåller varje uppgiftsbeskrivning en separat sektion för återanvändning. 30

31 Återanvändningsaktiviteterna innebär: att identifiera möjligheterna att hitta likheter bearbeta dessa möjligheter Användandet av de nya komponenterna leder till att man får uppslag till ny a förändringar på designdelarna. Business Process Re-engineering Figur 8 BPR (Business process re-engineering) är en iterativ process där man använder sig av mycket erfarna företagsreprestentanter som assisteras av medhjälpare och teknologiska visionärer. BPR innebär nytänkande och nydesign av ett helt företag, processer, ledning, jobb, organisationens struktur och värderingar inkluderat. BPR ses som en metod för att: förbättra kundservicen öka konkurrensmöjligheterna förhöja flexibiliteten i funktionerna minska kostnaderna på IT system BPR utforskar potentiella vägar, expanderar företagsvisionen och utvecklar företagets processmodeller. 31

32 Som en konsekvens kommer de gamla processerna att bytas ut mot nya och detta kommer i sin tur att ha en positiv effekt på företaget och de anställda inom organisationen. I en sådan här miljö har informationsteknologi blivit ett bra hjälpmedel vid implementationen av mer effektiva företagsprocesser. Architecture development Den här processen har sin egen livscykel, den får sin näring från BPR och den producerar en teknisk arkitektur som underhåller de strategiska IS kraven. Processen använder sig av output från BPR för att se över kraven så att man kan välja de informationsssystem som möter företagskraven. Sedan utforskar den de potentiella alternativen till IT arkitektur och bekräftar vilken effekt den arkitekturen kommer att ha på existerande system och företaget. Arkitekturutvecklingen inkluderar också implementations planen för de tekniska komponenterna, underhållet, hjälpen och utbildningsbehovet. Systems development All systemutveckling kan innehålla en (eller flera) initiativ när man använder IAD och parallella initiativ när man använder sig av andra livscykler. Alla Perform-systemutvecklingslivscykler kontrolleras av Performprojektledningslivscykeln som hanterar planering, uppdelning av uppgifter, kontroll, rapportering och leverans av produkten. Om IAD n följer en BPR och/eller arkitekturutvecklingsvägen kommer dessa att tillföra de tekniska anvisningarna och de globala kraven för de önskade systemen/applikationerna. Systems roll-out Denna del är viktigare än implementeringen av en lokaliserad pilot, och kanske även hela systemet, inom ramarna för IAD utveckling. Utvecklingen kan ha handlat om en del under en avdelning där det används specifika pilothårdvara och mjukvara eller nätverk. När man sen accepterat denna del för implementation över hela koncernen är roll-outen en mycket stor och komplicerad spridningsprocess som kräver planering, inköp, installation, träning, acceptans, support och feedback. När det gäller stora strategiska system kräver hårdvara, mjukvara, nätverk, support och konfiguration av alla delar en tillägnad livscykel. 32

Chaos om datorprojekt..

Chaos om datorprojekt.. Systemutveckling och användbarhet Användarcentrerad systemutveckling, gränssnitt och prototyper. Referens till avsnitt i kursboken Dix kapitel 6 Gulliksen, Göransson: Användarcentrerad systemdesign, kapitel:

Läs mer

Chaos om IT-projekt..

Chaos om IT-projekt.. Användarcentrerad systemutveckling, gränssnitt och prototyper. Lämplig extraläsning Gulliksen, Göransson: Användarcentrerad systemdesign, Studentlitteratur, kapitel: 4, 5, 6, 7, 8, 9 (Bredvidläsning) Syfte

Läs mer

Användarcentrerad Systemutveckling

Användarcentrerad Systemutveckling Användarcentrerad Systemutveckling Människadatorinteraktion (MDI) Inst. för informationsteknologi http://www.it.uu.se/edu/ course/homepage/hci/ ht10 Användarcentrerad systemutveckling, gränssnitt och prototyper.

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer

RUP - Rational Unified Process

RUP - Rational Unified Process IBM Software Group RUP - Rational Unified Process Eva Hådding eva.hadding@se.ibm.com 1 Projektkaos. Chaos-rapporten 28% av projekten avslutades i tid och enligt budget. 49% av projekten drog över de ursprungliga

Läs mer

Symptom på problemen vid programvaruutveckling

Symptom på problemen vid programvaruutveckling eller Varför är det bättre med halsbränna i början av ett projekt än i slutet? Eva Hådding ehadding@rational.com Symptom på problemen vid programvaruutveckling Användarnas och verksamhetens behov ej uppfyllda

Läs mer

UML: Exempel. Ett modelleringsspråk. UML: Ansvar. UML: tre huvudanvändningar. Exempel: En klass position storlek. UML Unified Modelling Language

UML: Exempel. Ett modelleringsspråk. UML: Ansvar. UML: tre huvudanvändningar. Exempel: En klass position storlek. UML Unified Modelling Language Ett modelleringsspråk : Exempel Fönster Klassnamn Unified Modelling Language Av Booch, Jacobson, Rumbaugh Exempel: En klass position storlek Attribut (instansvariaböe) Resultatet av en sammanslagning av

Läs mer

Objektorientering. Grunderna i OO

Objektorientering. Grunderna i OO Objektorientering Grunderna i OO 1 Systemutveckling Tre systemnivåer: Verksamhet Informationssystem Datasystem Huvuduppgifterna i ett systemutvecklingsarbete: Verksamhetsanalys Informationsbehovsanalys

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

Föreläsning om OO, OOA och UML

Föreläsning om OO, OOA och UML Föreläsning om OO, OOA och UML Modellering Kristian Ekberg Källa bild: video Marie Åsberg, AFA Försäkring Dagens föreläsning Presentation Kristian Ekberg Model och modellering Vad är en modell och vad

Läs mer

Introduktion. Byggstenar TDBA63 2005-11-22

Introduktion. Byggstenar TDBA63 2005-11-22 Introduktion UML står för Unified Modeling Language. Det är tänkt att fungera som hjälpmedel vid modellering av alla tänkbara typer av utvecklingsarbeten, inte bara inom dataomdrådet. Det största värdet

Läs mer

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram 2EMHNWRULHQWHUDG5HDOWLGVSURJUDPPHULQJ Föreläsning 7 OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram - Kravspecifikationer, användningsfall, systemarkitektur - Analysfas vad är analys?

Läs mer

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel Kursinformation Metodik för programvaruutveckling Föreläsning 3 Latex ok för litteraturstudierapport (prata med mig bara) Nästa föreläsning är av Björn Regnell (jag är med också) Presentationer imorgon

Läs mer

Introduktion till objektorientering. Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten?

Introduktion till objektorientering. Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten? Introduktion till objektorientering Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten? TDDD78, TDDE30, jonas.kvarnstrom@liu.se 729A85 jonas.kvarnstrom@liu.se

Läs mer

RUP Rational Unified Process. 17 november 2004

RUP Rational Unified Process. 17 november 2004 RUP Rational Unified Process 17 november 2004 RUP Volvo Information Technology, Eva Hådding Volvo Information Technology Volvo IT ingår i Volvo-koncernen Volvo Lastvagnar Volvo Bussar Volvo Anläggningsmaskiner

Läs mer

CREATING VALUE BY SHARING KNOWLEDGE

CREATING VALUE BY SHARING KNOWLEDGE CREATING VALUE BY SHARING KNOWLEDGE PROJEKTLEDNING 101 Nidzara Dellien, Lund September 2017 PROJEKT En formell definition på projekt är följande (enligt Wikipedia): En temporär satsning för att framställa

Läs mer

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08 Formpipe Platina och kvalité Rasmus Staberg, Teknisk direktör, 2014-04-08 04 08 1 Formpipe Presentation Bakgrund Platina släpptes som första release år 2000. Fick pris för Best in show från Bill Gates

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 17 juni 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

Objektorienterad analys och design

Objektorienterad analys och design Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 1 Objekt-orienterad analys och design: Litteratur Skansholm: Kapitel 4 Se även 1. http://www.uml.org/ 2. http://www-306.ibm.com/software/rational/uml/

Läs mer

Metoder och verktyg för funktionssäkerhet

Metoder och verktyg för funktionssäkerhet Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och

Läs mer

SYSTEMUTVECKLING METODER & MODELLER. Suzana Ramadani

SYSTEMUTVECKLING METODER & MODELLER. Suzana Ramadani SYSTEMUTVECKLING METODER & MODELLER 1 Processlinjen Produktlinjen Livscykelmodellen systemutveckling systemering Analys Design Realisering Implementering Förändringsanalys Verksamhetsanalys Förvaltning

Läs mer

UML 1(5) Introduktion till Unified Modeling Language. 1 Bakgrund och historik

UML 1(5) Introduktion till Unified Modeling Language. 1 Bakgrund och historik UML 1(5) Introduktion till Unified Modeling Language 1 Bakgrund och historik UML är ett objektorienterat modellspråk för att specificera och visualisera system. Det är framtaget i första hand för IT-orienterade

Läs mer

2014-2015 Alla rättigheter till materialet reserverade Easec

2014-2015 Alla rättigheter till materialet reserverade Easec 1 2 Innehåll Introduktion... 4 Standarder... 5 Översikt: Standarder... 6 1058.1-1987 IEEE Standard för Software Project Management Plans... 7 Ingående dokument... 8 Syfte och struktur... 9 ITIL... 10 ITIL

Läs mer

Objektorienterad konstruktion

Objektorienterad konstruktion Analys - Objektorienterad konstruktion Vad är objektorientering?» Ett sätt att angripa programmeringsproblem» Ett sätt att tänka när man programmerar Vad innebär objektorientering?» Att uppmärksamheten

Läs mer

Introduktion till objektorientering. Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten?

Introduktion till objektorientering. Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten? Introduktion till objektorientering Vad är objektorientering egentligen? Hur relaterar det till datatyper? Hur relaterar det till verkligheten? jonas.kvarnstrom@liu.se 2014 2017 jonas.kvarnstrom@liu.se

Läs mer

Objektorienterad programmering, allmänt

Objektorienterad programmering, allmänt Objektorienterad programmering, allmänt Sven-Olof Nyström Uppsala Universitet 17 juni 2005 1 Vilka egenskaper vill vi att program ska ha? Förslag (en partiell lista): De ska... gå snabbt att skriva vara

Läs mer

Viktiga egenskaper hos ett program (Meyer): Objektorienterad programmering, allmänt. Vilka egenskaper vill vi att våra program ska ha?

Viktiga egenskaper hos ett program (Meyer): Objektorienterad programmering, allmänt. Vilka egenskaper vill vi att våra program ska ha? Viktiga egenskaper hos ett program (Meyer): Objektorienterad programmering, allmänt Sven-Olof Nyström Uppsala Universitet 17 mars 2005 1. Korrekthet 2. Robusthet 3. Utökbarhet 4. Återanvändbarhet 5. Kompatibilitet

Läs mer

Mjukvarudesign. Designprocessen. Teknisk design. Konceptuell design

Mjukvarudesign. Designprocessen. Teknisk design. Konceptuell design RE SD PD I UT IT ST AT Mjukvarudesign System Requirement Specification Inkrementell och iterativ! Konceptuell design (VAD) Systemdesign (OOA) Arkitekturell (grovkornig, UML) Teknisk design (HUR) Programdesign

Läs mer

Företagsmodellering i UML

Företagsmodellering i UML Företagsmodellering i UML En kort-kort introduktion av Ambjörn Naeve http://kmr.nada.kth.se Modellering En modell är en förenklad beskrivning av ett komplext område En modell är motiverad av mål (= har

Läs mer

Exempel på verklig projektplan

Exempel på verklig projektplan Exempel på verklig projektplan Detta är ett exempel på en proffessionell projektplan hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och mycket av

Läs mer

Föreläsning 2. Objektorienterad analys och design. Analys: att modellera världen. Design: att strukturera program.

Föreläsning 2. Objektorienterad analys och design. Analys: att modellera världen. Design: att strukturera program. Föreläsning 2 Objektorienterad analys och design. Analys: att modellera världen. Design: att strukturera program. Vår process Kravbeskrivning (3 dagar). Enkel form av användningsfall (use cases). Analys

Läs mer

Martin Völcker, SLL & Suit

Martin Völcker, SLL & Suit 1 2009-02-03 DSDM Martin Völcker, SLL & Suit martin.volcker@suit.se Tel: 08-648 70 00 Mobil:0708-252424 Mentorskap - Projektledning - Utbildning- Workshops 2 2009-02-03 Oklara krav Oklara roller Försenade

Läs mer

Analys och design. Objekt. Klass. med hjälp av CRC. Klassdiagram

Analys och design. Objekt. Klass. med hjälp av CRC. Klassdiagram Analys och design med hjälp av CRC 83 Klassdiagram Objekt Ett objekt är en individuellt identifierbar entitet som kan vara konkret eller abstrakt. Ett objekt har tillstånd, beteende och identitet. Reellt,

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet June 22, 2006 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

Objektorienterad analys och design

Objektorienterad analys och design Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet June 22, 2006 1 Objekt-orienterad analys och design: Litteratur Skansholm: Kapitel 4 Se även 1. http://www.uml.org/ 2. http://www-306.ibm.com/software/rational/uml/

Läs mer

Diagnos och design av Verksamhet och IT, 7, 5 HP. Föreläsning 2 Sofie Pilemalm

Diagnos och design av Verksamhet och IT, 7, 5 HP. Föreläsning 2 Sofie Pilemalm Diagnos och design av Verksamhet och IT, 7, 5 HP Föreläsning 2 Sofie Pilemalm Dagens Agenda Systemutveckling i backspegeln och för framtiden Problem och utmaningar Användarcentrerad utveckling Som del

Läs mer

Processbeskrivning Systemutveckling

Processbeskrivning Systemutveckling ProcIT-P-015 Processbeskrivning Systemutveckling Lednings- och kvalitetssystem Fastställd av Sven Arvidson 2011-09-12 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Systemutvecklingsprocessen

Läs mer

Praktikum i programvaruproduktion

Praktikum i programvaruproduktion Praktikum i programvaruproduktion Introduktion Föreläsare/Ansvarig: Pontus Boström Email:pontus.bostrom@abo.fi Rum A5055 Assistent: Petter Sandvik Email: petter.sandvik@abo.fi Rum: A5048 Föreläsningar:

Läs mer

Projekt- och kvalitetsstyrning på Frontec

Projekt- och kvalitetsstyrning på Frontec Projekt- och kvalitetsstyrning på Frontec Detta dokument beskriver hur Frontec bedriver utvecklingsprojekt med kvalitetssäkring FSAB_LS020_Projekt och kvalitetsstyrning A.doc Sida 1(6) Frontec kan projekt

Läs mer

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Kravhantering / Testprocess - Agenda AGENDA Grundläggande kravhanteringsprocess. Insamling, dokumentation, prioritering, Test och förvaltning

Läs mer

Projektuppgift i Användarcentrerad Systemdesign, ht 04

Projektuppgift i Användarcentrerad Systemdesign, ht 04 Projektuppgift i Användarcentrerad Systemdesign, ht 04 E-Dagis enligt systemutvecklings metoden The Usability Engineering Lifecycle, Deborah J. Mayhew Grupp 3: Daniel Lundberg, dalu8987@student.uu.se Hanna

Läs mer

EAs krav vid ackreditering av flexibel omfattning

EAs krav vid ackreditering av flexibel omfattning SWEDAC DOC 12:1 2012-05-10 Utgåva 1 Inofficiell översättning av EA 2/15 M:2008 EAs krav vid ackreditering av flexibel omfattning Swedac, Styrelsen för ackreditering och teknisk kontroll, Box 878, 501 15

Läs mer

Processinriktning i ISO 9001:2015

Processinriktning i ISO 9001:2015 Processinriktning i ISO 9001:2015 Syftet med detta dokument Syftet med detta dokument är att förklara processinriktning i ISO 9001:2015. Processinriktning kan tillämpas på alla organisationer och alla

Läs mer

Informationssystem och databasteknik, 2I-1100

Informationssystem och databasteknik, 2I-1100 Informationssystem och databasteknik, 2I-1100 Introduktion till informationssystem - användning, teknik och utveckling Vad är ett informationssystem? Informationssystem: datoriserat system som stödjer

Läs mer

men borde vi inte också testa kraven?

men borde vi inte också testa kraven? men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST, 24 februari 2011 SQS Software Quality Systems Sweden AB Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av

Läs mer

729G75: Programmering och algoritmiskt tänkande. Tema 1, föreläsning 1 Jody Foo

729G75: Programmering och algoritmiskt tänkande. Tema 1, föreläsning 1 Jody Foo 729G75: Programmering och algoritmiskt tänkande Tema 1, föreläsning 1 Jody Foo Föreläsningsöversikt Kursinfo / Om kursen Algoritmer Objektorienterad programmering i praktiken terminologi använda objekt

Läs mer

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström.

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström. Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström. Författare Per Johansson, Henrik Wallinder Generellt Helhetsintrycket från genomläsning av uppsatsen

Läs mer

Lyckade projekt - finns det?

Lyckade projekt - finns det? Lyckade projekt - finns det? Maria Lindqvist Björkman Enea Business Software Enea Business Software 2002 Sida 1 Agenda Förväntningar kund & leverantör Statistik om projekt Framgångsfaktorer Exempel på

Läs mer

729G75: Programmering och algoritmiskt tänkande. Tema 1. Föreläsning 1 Jody Foo

729G75: Programmering och algoritmiskt tänkande. Tema 1. Föreläsning 1 Jody Foo 729G75: Programmering och algoritmiskt tänkande Tema 1. Föreläsning 1 Jody Foo Föreläsningsöversikt Kursinfo / Om kursen Algoritmer Objektorienterad programmering i praktiken terminologi använda objekt

Läs mer

LiTH Autonom styrning av mobil robot 2007-02-15. Projektplan. Martin Elfstadius & Fredrik Danielsson. Version 1.0

LiTH Autonom styrning av mobil robot 2007-02-15. Projektplan. Martin Elfstadius & Fredrik Danielsson. Version 1.0 Projektplan Martin Elfstadius & Fredrik Danielsson Version 1.0 Status Granskad Godkänd 1 PROJEKTIDENTITET Autonom styrning av mobil robot Vårterminen 2007 Linköpings Tekniska Högskola, ISY Namn Ansvar

Läs mer

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till?

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? 1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? Att lära sig via metaforer innebär att man drar nytta av kunskap som användaren redan har,

Läs mer

Arkitektur och metodbeskrivning. Nationell informationsstruktur

Arkitektur och metodbeskrivning. Nationell informationsstruktur Arkitektur och metodbeskrivning Nationell informationsstruktur Nationell informationsstruktur arkitektur och metodbeskrivning Nationell informationsstruktur (NI) ska bestå av sammanhängande modeller, vilket

Läs mer

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 Document: STG/PS K 525SV1 Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 SIS, Projekt Kvalitetsledning 1 1) Introduktion Produktstöd Två av de viktigaste målsättningarna i arbetet

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

Mer OOP. Variation i typ. Medlen repetition. Generiska klasser. Gränssnitt - Interface. Mer om klasser Några exempel UML

Mer OOP. Variation i typ. Medlen repetition. Generiska klasser. Gränssnitt - Interface. Mer om klasser Några exempel UML Målet Mer OOP Mer om klasser Några exempel UML Modularitet Språkligt modulära enheter Få gränssnitt Små gränssnitt Tydliga gränssnitt Dold information Återanvändbarhet Variation i typer Variation i datastrukturer

Läs mer

Objektorienterad programmering

Objektorienterad programmering Objektorienterad programmering Aletta Nylén http://user.it.uu.se/~aletta Epost: aletta.nylen@it.uu.se Rum: 1216 Kursinfo Lärare: Aletta Nylén Jesper Wilhelmsson Litteratur: Object-Oriented Software Development

Läs mer

BESKRIVNING AV PROCESSMETODEN SCRUM

BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM INNEHÅLLSFÖRTECKNING inledning... 3 SCRUM... 3 Bakgrund... 3 Faser... 3 Ramverket... 3 Nordscrum... 4 StudentProjekt...

Läs mer

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning Nationell Informationsstruktur 2015:1 Bilaga 7: Arkitektur och metodbeskrivning Innehåll Nationell informationsstruktur arkitektur och metod... 3 Standarder inom informatik... 3 NI relaterat till ISO 42010...

Läs mer

Objekt-orienterad programmering. Klassbegreppet och C++ UML. UMLs fördelar

Objekt-orienterad programmering. Klassbegreppet och C++ UML. UMLs fördelar Klassbegreppet och C++ OOP UML Klasser och objekt i C++ Uppdelning i filer Attribut och metoder Inkappsling - åtkomst Klassattribut - objektattribut Objekt-orienterad programmering Att använda ett objektorienterat

Läs mer

Datalagringsmetodik och arkitektur i Java. Projektdefinition. Projektdefinition. Björn Brenander. 7 maj 2001

Datalagringsmetodik och arkitektur i Java. Projektdefinition. Projektdefinition. Björn Brenander. 7 maj 2001 Datalagringsmetodik och arkitektur i Java Projektdefinition Dokumenttitel Projektdefinition Dokumentansvarig Dokumentförfattare Björn Brenander Dokumentnamn Projektdefinition.doc Version 16 Ref. nr. Skapades

Läs mer

Visuell GUI Testning

Visuell GUI Testning Visuell GUI Testning Vad är ett Graphical User Interface (GUI)? Icke-animerat GUI Animerat GUI Nuläget System- och acceptanstestning är dyrt! Manuellt Långsamt Enformigt Svårt att replikera exakt Nödvändigt

Läs mer

Kursöversikt Certifierad Mjukvarutestare

Kursöversikt Certifierad Mjukvarutestare Kursöversikt Certifierad Mjukvarutestare Kurs Poäng (5 yh poäng/vecka) Examensarbete 20 Grunderna inom test 20 Kommunikation i arbetslivet 15 Lärande i arbete 1 60 Lärande i arbete 2 60 Projektarbete 15

Läs mer

Förvaltningsplan NyA 2016

Förvaltningsplan NyA 2016 Systemförvaltning och systemdrift Föredragande Anders Mobjörk Systemansvarig 010-470 06 38 anders.mobjork@uhr.se BESLUT Diarienummer 4.2.2-1263-2015 Datum 2015-12-04 Postadress Box 45093 104 30 Stockholm

Läs mer

Ramverk för projekt och uppdrag

Ramverk för projekt och uppdrag Peter Yngve IT-centrum 2011-02-10 1.0 1 (9) Ramverk för projekt och uppdrag Peter Yngve IT-centrum 2011-02-10 1.0 2 (9) BAKGRUND/MOTIV... 3 MÅL OCH SYFTE... 3 DEFINITIONER AV PROJEKT... 3 MODELL FÖR PROJEKTSTYRNING...

Läs mer

Processbeskrivning Systemutveckling

Processbeskrivning Systemutveckling ProcIT-P-013 Processbeskrivning Systemutveckling Lednings- och kvalitetssystem Fastställt av Sven Arvidson 2012-06-20 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Systemutvecklingsprocessen

Läs mer

Kurser och seminarier från AddQ Consulting

Kurser och seminarier från AddQ Consulting Kurser och seminarier från AddQ Consulting Med fokus på kvalitet och effektivitet bidrar vi till att underlätta människors vardag. Kompetensutveckling är nyckeln till framgång för dig som jobbar med test,

Läs mer

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning En rapport från CATD-projektet, januari-2001 1 2 Förstudie Beslutsstöd för operativ tågtrafikstyrning Bakgrund Bland de grundläggande

Läs mer

Inkapsling (encapsulation)

Inkapsling (encapsulation) UML UML är en standard för att dokumentera och visualisera sina tankar och beslut under analys och design. Att lära sig allt om UML får inte plats i den här kursen, men vi kommer lära oss vissa delar.

Läs mer

Kravspecifikation Fredrik Berntsson Version 1.1

Kravspecifikation Fredrik Berntsson Version 1.1 Kravspecifikation Fredrik Berntsson Version 1.1 Status Granskad FB 2016-02-01 Godkänd FB 2015-02-01 Dokumenthistorik Version Datum Utförda ändringar Utförda av Granskad 1.0 2015-02-01 Första versionen

Läs mer

Agil programutveckling

Agil programutveckling Agil programutveckling Pontus Evertsson D00, Lunds Tekniska Högskola d00pe@efd.lth.se Anna Jennerheim D00, Lunds Tekniska Högskola d00aj@efd.lth.se 2003-05-15 1 1. Inledning 3 2. Extreme Programming (XP)

Läs mer

Webbserverprogrammering

Webbserverprogrammering Webbserverprogrammering WES Webbserverprogrammering Ämnet webbserverprogrammering behandlar funktionalitet för webblösningar och samspelet mellan beställare, användare, formgivare och utvecklare. Ämnets

Läs mer

Wise Business Support Ms Office Kursinnehåll För nybörjare och därefter

Wise Business Support Ms Office Kursinnehåll För nybörjare och därefter Wise Business Support Ms Office Kursinnehåll För nybörjare och därefter Mohammad Honarbakhsh 2013 01 11 073 784 22 74 mo.honar@wisebs.com www.wisebs.com Ms Office Ms Word, Ms Outlook, Ms PowerPoint, Ms

Läs mer

Nationell informationsstruktur 2016:1. Bilaga 7: Arkitektur och metodbeskrivning

Nationell informationsstruktur 2016:1. Bilaga 7: Arkitektur och metodbeskrivning Nationell informationsstruktur 2016:1 Bilaga 7: Arkitektur och metodbeskrivning Nationell informationsstruktur arkitektur och metodbeskrivning Nationell informationsstruktur (NI) ska bestå av sammanhängande

Läs mer

QC i en organisation SAST 2008-09-16

QC i en organisation SAST 2008-09-16 QC i en organisation SAST 2008-09-16 1 Agenda Hur är vi organiserade inom test på SEB? Hur är QC uppsatt på SEB? Hur arbetar vi med QC i en stor organisation? Uppfyllde QC våra förväntningar och hur har

Läs mer

Några grundläggande begrepp

Några grundläggande begrepp Några grundläggande begrepp Validering bygger vi rätt system? Uppfyller kravspecifikationen de verkliga behoven? Verifiering bygger vi systemet rätt? Uppfyller det färdiga systemet kravspecifikationen?

Läs mer

Skapa insikter till rätt beslut

Skapa insikter till rätt beslut Skapa insikter till rätt beslut Enklaste vägen till beslut med dynamiska rapporter Verksamhetskolls dashboards är tydliga och det är lätt att direkt ta till sig det väsentliga. Alla dimensioner i ditt

Läs mer

Undervisningen i ämnet webbutveckling ska ge eleverna förutsättningar att utveckla följande:

Undervisningen i ämnet webbutveckling ska ge eleverna förutsättningar att utveckla följande: WEBBUTVECKLING Ämnet webbutveckling behandlar de tekniker som används för att presentera och bearbeta information i webbläsaren samt utifrån dessa tekniker skapa och vidareutveckla statiska och dynamiska

Läs mer

Tentamen i: Affärssystem och tjänsteorienterad arkitektur

Tentamen i: Affärssystem och tjänsteorienterad arkitektur Tentamen i: Affärssystem och tjänsteorienterad arkitektur Kurskod: DSK2:SOA1 Datum: 21 december 2012 Tid: 09:00 13:00 Examinator: Gustaf Juell-Skielse Information Hjälpmedel: Omfång: Poängkrav: Utförande:

Läs mer

The power of simplicity

The power of simplicity The power of simplicity FACTSHEET - 1 - Vertex GRC är ett molnbaserat verktyg som är utvecklat med användaren i fokus det ska vara lätt och intuitivt att implementera, administrera och använda! Verktyget

Läs mer

WEBBSERVERPROGRAMMERING

WEBBSERVERPROGRAMMERING WEBBSERVERPROGRAMMERING Ämnet webbserverprogrammering behandlar funktionalitet för webblösningar och samspelet mellan beställare, användare, formgivare och utvecklare. Ämnets syfte Undervisningen i ämnet

Läs mer

Predictions EVRY Integration AB

Predictions EVRY Integration AB Version: 1.0 Datum: 2016-01-22 evry.com Uppdragsbeskrivning Predictions EVRY Integration AB Versionshistorik Ändring nr. Ändring datum Förändringar Reviderad av 1.0 16-01-22 Dokumentet skapat Torbjörn

Läs mer

Projektering av informationssystem

Projektering av informationssystem Projektering av informationssystem Att ta fram specifikationer för utveckling av informationssystem eller upphandling av standardsystem. Kurslängd: 3 dagar Kursbeskrivning Att ta fram precisa, kompletta

Läs mer

David A, Niklas G, Magnus F, Pär E, Christian L 2011-02-02 CHALMERS INLÄMNING1. IKOT Grupp B4

David A, Niklas G, Magnus F, Pär E, Christian L 2011-02-02 CHALMERS INLÄMNING1. IKOT Grupp B4 David A, Niklas G, Magnus F, Pär E, Christian L 2011-02-02 CHALMERS INLÄMNING1 IKOT Grupp B4 Innehållsförteckning Bakgrund... 3 Intressenter... 3 Mål... 4 Spelregler... 4 Leveranser... 5 Avgränsningar...

Läs mer

Utbildningsplan. Systemvetenskapliga programmet. 180 högskolepoäng. System Science Program. 180 Higher Education Credits *)

Utbildningsplan. Systemvetenskapliga programmet. 180 högskolepoäng. System Science Program. 180 Higher Education Credits *) Utbildningsplan Systemvetenskapliga programmet 180 högskolepoäng System Science Program 180 Higher Education Credits *) Fastställd i Utbildnings- och Forskningsnämnden 2012-11-14 Gäller fr.o.m. 2013-07-01

Läs mer

Objektorienterade programmeringsspråk. Objektorienterade språk. Den objekt-orienterade modellen. Jämför med icke-oo

Objektorienterade programmeringsspråk. Objektorienterade språk. Den objekt-orienterade modellen. Jämför med icke-oo Objektorienterade språk Historik Simula 67 Smalltalk 80 Procedurorienterad programmering Subprogram Programbibliotek Dataorienterad programmering Abstrakta datatyper Objektbaserade språk, föregångare till

Läs mer

Modern utvecklingsmetodik. Användarcentrering i företag. Användarcentrering i företag. Användarcentrering i företag. Användarcentrering i företag

Modern utvecklingsmetodik. Användarcentrering i företag. Användarcentrering i företag. Användarcentrering i företag. Användarcentrering i företag Modern utvecklingsmetodik TNMK31 Användbarhet HIIA20 Användbarhet med kognitiv psykologi Teknikdriven design kontra användarcentrerad design Traditionell filosofi Teknikdriven Fokus på komponenter Individuella

Läs mer

Att välja verktyg för portföljhantering. - Vad vet en leverantör om det?

Att välja verktyg för portföljhantering. - Vad vet en leverantör om det? Att välja verktyg för portföljhantering - Vad vet en leverantör om det? Agenda Problem som ska lösas med verktyg Olika typer av verktyg Att utvärdera och välja verktyg Egenutvecklat eller standard Förankring

Läs mer

Vägledning för krav på dokumenterad information enligt ISO 9001:2015

Vägledning för krav på dokumenterad information enligt ISO 9001:2015 Vägledning för krav på dokumenterad information enligt ISO 9001:2015 1 Orientering Två av de viktigaste målen vid revideringen av standarderna i ISO 9000-serien var att a) utveckla förenklade standarder

Läs mer

Är objektorienterad modellering ett måste? (HS-IDA-EA )

Är objektorienterad modellering ett måste? (HS-IDA-EA ) Är objektorienterad modellering ett måste? (HS-IDA-EA-00-409) Anders Johansson (a97andjo@student.his.se) Institutionen för datavetenskap Högskolan i Skövde, Box 408 S-54128 Skövde, SWEDEN Examensarbete

Läs mer

Visionen om en Tjänstekatalog

Visionen om en Tjänstekatalog Visionen om en Tjänstekatalog Varför ska vi införa tjänster? Copyright BiTA Service Management/Rolf Norrman 1 IT:s värde för verksamheten tydliggörs i verksamhetens egna termer Organisationens kundfokus

Läs mer

Informationshantering vid systemutveckling styrd av CM

Informationshantering vid systemutveckling styrd av CM Informationshantering vid systemutveckling styrd av CM Håkan Edler Torbjörn Jungeby Tore Qvist Syfte och mål Syftet med arbetsgruppens aktuella arbete är, att möjliggöra ett samordnat informationsutbyte

Läs mer

Projektplan. LiTH Segmentering av MR-bilder med ITK Anders Eklund. Version 1.0. Status. Bilder och grafik projektkurs, CDIO MCIV LIPs

Projektplan. LiTH Segmentering av MR-bilder med ITK Anders Eklund. Version 1.0. Status. Bilder och grafik projektkurs, CDIO MCIV LIPs Segmentering av MR-bilder med ITK 2006-02-02 Projektplan Version 1.0 Status Granskad Godkänd Bilder och grafik projektkurs, CDIO MCIV LIPs 1 PROJEKTIDENTITET MCIV 2006 VT Linköpings Tekniska Högskola,

Läs mer

TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER

TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER TPFD Beskrivning Rev 4 1(10) TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER Anv.krav Terminologi Detaljkrav Konfigdok Hantera Utgåvor Projektplan Testplan Test-o-felrättning Ändringslogg Återst.

Läs mer

Lyckas med outsourcing av lön och HR Whitepaper

Lyckas med outsourcing av lön och HR Whitepaper bluegarden.se Lyckas med outsourcing av lön och HR Whitepaper Kan din verksamhet tjäna på att outsourca hela eller delar av löne- och HRadministrationen? Detta whitepaper ger dig underlag att fatta korrekta

Läs mer

SKOLFS. beslutade den XXX 2017.

SKOLFS. beslutade den XXX 2017. 1 (11) Föreskrifter om ändring i Skolverkets föreskrifter (SKOLFS 2010:247) om ämnesplan för ämnet programmering i gymnasieskolan, inom kommunal vuxenutbildning på gymnasial nivå och inom vidareutbildning

Läs mer

Astrakan Strategisk Utbildning AB 2011 1

Astrakan Strategisk Utbildning AB 2011 1 Målet med detta kapitel är att du skall kunna utvärdera ett agilt projekt och förstå hur man upptäcker vad som behöver förstärkas. Metoden som egentligen är ett verktyg kan användas på många sätt: att

Läs mer

Opponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg

Opponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg Datavetenskap Opponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg Oppositionsrapport, C-nivå 2006:12 1 Sammanfattat omdöme av examensarbetet Examensarbetet är intressant eftersom

Läs mer

Business Model Transformation. Banbrytande affärsmodeller genom transformation av affärsarkitektur

Business Model Transformation. Banbrytande affärsmodeller genom transformation av affärsarkitektur Business Model Transformation Banbrytande genom transformation av affärsarkitektur Business Model Transformation Vår grundläggande metod för affärsutveckling och transformation av verksamheter kallar vi

Läs mer

http://www.one-life.com/ http://www.bjork.com/ http://www.ro.me/ http://www.protest.eu/en#!/home

http://www.one-life.com/ http://www.bjork.com/ http://www.ro.me/ http://www.protest.eu/en#!/home http://www.one-life.com/ http://www.bjork.com/ http://www.ro.me/ http://www.protest.eu/en#!/home http://www.oakley.com/legionofoakley?cm_mmc=ads-_-apparel_goggles-_-prs_sigseries-_-appa Inspiration Koncept

Läs mer