System Udvikling Kilde: Per S Laursen.

Slides:



Advertisements
Lignende præsentationer
Virksomhedens interessenter
Advertisements

Anskaffelse af ny teknologi
Atomer Et programmeret forløb. En måde at lære på.
Gammelheds-Philosophy
KONFLIKTHÅNDTERING Velkommen! Dias.
Du skal vide nogen om blodtrykket, fordi det fortæller noget om hvordan dit hjerte har det. HUSK - at hjertet ikke er til at undvære ligesom bilen.
SMUT PAKKE 3 VIDEN OM KOST.
Hvem er vi? Martin Dahl Karin Dam Nielsen
Vi hører altid om kvinders “regler”, her er så mændenes regler.
Værktøjer/tips og tricks - til implementering af ændringer i egen organisation Hvorfor benchmarking/evaluering Er der nogen, der ved, hvorfor vi laver.
©Jenny Bohr – Til underviserne Her er valgt at vise filmen ”et liv i kaos”. Hvis kursisterne er unge, kan man vælge en anden film eks. ”det.
Mr. Raggys prøveeksamen Gennemgang af svarene.
Forsiden 1.Denne knap bruges når du vil taste dagens resultater ind. 2.Denne knap skal kun bruges hvis du allerede har gemt data og du finder ud af at.
Du skal vide nogen om blodtrykket, fordi det fortæller noget om hvordan dit hjerte har det. HUSK - at hjertet ikke er til at undvære ligesom bilen.
Afkobling af stivelsesstøtte
Hvordan programmerer man?? STREAM - en model. Programmører arbejder ofte i teams Hver programmør arbejder på sin del af en større helhed.
Manuelle målstyrings-tavler
Vi hører altid om kvinders “regler”, her er så mændenes regler.
Arkitektur - data.
1 Video-regelquiz - Inkl. svar. 2 I denne lille video-regelquiz bliver I stillet over for ni regelsituationer i slagspil. Hver situation beskrives i en.
Samarbejde med eller uden Service Level Agreement (SLA)
IM-Strategi.
Sprog/billeder på Internettet
Bytte   PowerPoint  .
Beskyt din computer og dine data!
Formularer (Access, del 3)
The Sims2 Double Deluxe + Sims 2 Pets
Hans Peter Wolsing iværksætterkoordinator SKYD IKKE DIG SELV I FODEN Nordjyske Medier 17. nov
1 De fem mest brugte regler… der ikke eksisterer. Fem regler, der ikke eksisterer…
Vestegnsprojektet Forebyggelsespuljens temadag 4. oktober 2012
Kommunikation / it.
Trivselsundersøgelse og ledelsesevaluering
IS-Strategi.
Udvikling – del II.
Felter og nøgle-felter (databaser, del 6)
1 Menuer (MenuStrip) MonthCalendar + DateTimePicker ListBox & CheckedListBox ComboBox Faneblade (eng.: tabs) med TabControl Steen Jensen, efterår 2013.
SMUT PAKKE 4 VIDEN OM MOTION.
Virksomheder - definition
SEO PÅ AU.
Relationer – børn og voksne
Økonometri 1: Specifikation og dataproblemer1 Økonometri 1 Specifikation, og dataproblemer 4. november 2005.
Introduktion til Access (Access, del 1)
Validering af data (Access, del 7)
Opslagsfelter (Access, del 6). RHS – Informationsteknologi 2 Udgangspunkt Vi er ofte i den situation, at valg af en type for et felt ikke begrænser vores.
Oprettelse af tabeller (Access, del 2)
Vi hører altid om kvinders “regler”, her er så mændenes regler.
Østjysk rapport om udligning og tilskud Seminar om udligning den 26. April 2010 Job og Økonomidirektør Asbjørn Friis Jensen, Favrskov.
Kjeld Tyllesen, PEØ, CBS1 1 vare produceret på 2 anlæg Kjeld Tyllesen Erhvervsøkonomi / Managerial Economics.
Økonometri 1: Dummy variable
”Et virtuelt spring over bæltet” ITMF projekt november 2003 Ella Myhring Skolebibliotekar, projektleder Højby Biblioteksbutik.
Arkitektur - software. RHS - Informationsteknologi 2 Software-arkitektur Formålet med software-arkitekturen er at definere en software-”platform”, som.
1 Algoritme til at løse knude P-center problemet Algoritmen brugte set covering problemet Virker derfor kun til knude problemer Vi vil alligevel bruge.
Ældre, IT og læring. Ældre tæmmer teknologien..
Økonometri 1: Specifikation og dataproblemer1 Økonometri 1 Specifikation, og dataproblemer 7. april 2003.
Mr. Raggys prøveeksamen
1 Senior Erhverv Søhøjlandet Nye tider, nye muligheder…! PP er sendt pr.mail.
Globaliseringsredegørelsen 24.mar. 14 Figurer fra Danmark tiltrækker for få udenlandske investeringer i Sådan ligger landet
Hvordan kan man læse dette regnestykke? -7 – 3
Udvikling – del II. 2 Håndtering af krav Uanset hvordan vi organiserer udviklingen af et SW-produkt, er håndtering af krav altid kritisk Dårlig håndtering.
Rapporter (Access, del 5). RHS – Informationsteknologi – Udgangspunkt Vi har oprettet en database Vi har defineret en eller flere tabeller, og.
Grunde til at jeg elsker dig
Fundamentale datastrukturer
Profilfag Julemarked Helt på plads med samarbejdsbutikker
Patientsikkerhed, kvalitet og akkreditering
Opslagsfelter (Access, del 6). RHS – Informationsteknologi – Udgangspunkt Vi er ofte i den situation, at valg af en type for et felt ikke begrænser.
Introduktion til Access (Access, del 1). RHS – Informationsteknologi – Fra design til udvikling Vi ved nu, hvordan vi finder et design for en database,
1 Fundamentale datastrukturer. 2 Definitioner: abstrakt datatype, datastruktur Elementære datastrukturer og abstrakte datatyper : arrays, stakke, køer,
Økonometri 1: Specifikation og dataproblemer1 Økonometri 1 Specifikation og dataproblemer 2. november 2004.
Oprettelse af tabeller (Access, del 2)
Præsentationens transcript:

System Udvikling Kilde: Per S Laursen

RHS - Informationsteknologi Er det svært…? Sammenlignet med hvad…? Måske ikke sværere at lave IT-projekter end så mange andre slags projekter Imidlertid er der – desværre – rigtig mange eksempler på IT-projekter, som er gået galt RHS - Informationsteknologi

RHS - Informationsteknologi Er det svært…? Amanda – system til sagsbehandling af arbejdsløse Start-budget 214 mill, endelig pris 650 mill Tidsramme fire år, kører ikke rigtig godt efter ni år… Elektroniske patient-journaler (EPJ) Hvert amt har kørt egne projekter – ingen koordination Indtil videre brugt milliarder… RHS - Informationsteknologi

Hvorfor er det så svært…? Er det sværere end at bygge en bro…? Ja, kravene til en bro er som regel ret veldefinerede Mange IT-projekter er – i sidste ende – fejlet på grund af uklarhed om krav RHS - Informationsteknologi

Old school IT-udvikling Engang troede man, at vi kunne specificere krav til f.eks. software een gang for alle Vi starter med at definere krav, og så laver vi ”alt det andet” bagefter Vandfalds-metoden RHS - Informationsteknologi

RHS - Informationsteknologi Vandfalds-metode Krav Design Implementation Test Vedligehold RHS - Informationsteknologi

Hvorfor virker den ikke? Vandfalds-metoden bygger på en (naiv) idé om rationel og alvidende opførsel Kunden ved præcist hvad systemet skal kunne, allerede når projektet starter Kunden kan formidle sine krav til leverandøren på objektiv og entydig vis Omfanget af et projekt kan estimeres alene ud fra en specifikation af krav RHS - Informationsteknologi

Hvorfor virker den ikke? Dette har vist sig at være særdeles langt fra virkeligheden… RHS - Informationsteknologi

Hvordan IT ikke skal sælges… I lang tid man man troet, at det at købe software var som at købe skovle… Alt kan specificeres – og prissættes – på forhånd, for det kan andre varer jo! Meget svært at sælge budskabet om usikkerhed til kunderne – hvem skal betale for usikkerheden…? RHS - Informationsteknologi

Hvordan IT ikke skal sælges… Mange firmaer har solgt store udviklings-projekter til fast pris, uden egentlig at vide hvad de solgte… Manglende viden hos sælgere…? Eller måske belønnes sælgere for salg, ikke for gennemførsel…? RHS - Informationsteknologi

Hvordan IT ikke skal sælges… Ville vi acceptere følgende…? Hej, jeg vil gerne købe et jakke-sæt. Jeg fortæller detaljer senere, men jeg vil have en fast pris! Øhm…ok, lad os sige 600,- Godt, i øvrigt skal det være skræddersyet, og lavet af thailandsk silke, og…(så videre) RHS - Informationsteknologi

Hvordan IT ikke skal sælges… Sådan er mange IT-projekter desværre blevet solgt – og hvem ender så med at sidde med problemet…? Dem som skal udføre selve projektet! RHS - Informationsteknologi

Hvordan IT ikke skal sælges… Således tænkes der ofte i SW-branchen – på lederniveau… Projektet er solgt til en fast pris på X kroner Vores interne pris er Y kroner pr. time For at det skal løbe rundt, skal projektet derfor udføres på X/Y timer! Selv om vi ikke rigtig ved, hvad projektet går ud på…men det må programmørerne løse! RHS - Informationsteknologi

Hvordan IT ikke skal sælges… Med andre ord - projektet er solgt til en fast pris, så internt forsøges det presset igennem til den aftalte pris, og/eller den aftalte deadline Overarbejde… Pizza og cola… Nørd-image… RHS - Informationsteknologi 14

RHS - Informationsteknologi Målepunkter Et SW-projekt indeholder tre essentielle parametre ud over kravene til projektet: Omkostninger Varighed Kvalitet (PS Figur 5.2) RHS - Informationsteknologi

RHS - Informationsteknologi Krav Som nævnt før definerer krav, hvad det endelige produkt skal kunne I praksis er krav ”levende” – som projektet skrider frem, afklares krav løbende Krav fremkommer i mange former og fra mange interessenter Ofte en meget stor udfordring at få gjort krav objektive og testbare RHS - Informationsteknologi

RHS - Informationsteknologi Ressourcer Som regel et ret firkantet mål for, hvor meget ”manpower” der er til rådighed for at udføre et givent projekt 15 mand i fuld tid i 2 år = 30 mande-år Men Har de andre opgave i virksomheden? Har de relevante kompetencer? Ferie, sygdom, møder, uddannelse,… RHS - Informationsteknologi

RHS - Informationsteknologi Deadline Ideelt set vil de fleste SW-projekter gerne arbejde til produktet er ”færdigt” – svært at få lov til i praksis Ofte er deadline påført udefra Konkurrenter Større begivenhed (messe eller lign.) Lovkrav …men ofte sættes den ret ”tilfældigt” RHS - Informationsteknologi

RHS - Informationsteknologi Kvalitet Hvad er kvalitet i forhold til software…? At det virker! (?) Kan være meget svært at formulere, hvad kvalitet egentlig dækker over RHS - Informationsteknologi

RHS - Informationsteknologi Kvalitet Bør i princippet være ”indbygget” i de krav, der stilles til softwaren 90 % af brugerne skal give programmet karakteren 10 eller bedre i en bruger-undersøgelse pr. 1/10-2010 Programmet skal kunne udføre en korrekt planlægning i mindst 99 % af et sæt af 500 praktiske tilfælde RHS - Informationsteknologi 20

RHS - Informationsteknologi The planning game Kernen af mange problemer i SW-udvikling har været, at man har troet man kunne fastlægge alle fire parametre på forhånd… …UDEN at spørge dem, som rent faktisk skal udføre opgaven! RHS - Informationsteknologi

RHS - Informationsteknologi The planning game Typisk eksempel; at finde behov for ressoucer ved at regne baglæns fra projektets salgspris: Projektet solgt for 4 millioner Vi koster 500 kr/time Altså 8000 timer til rådighed! Og samtidig insistere på kontrol over krav, kvalitet og deadline! RHS - Informationsteknologi 22

RHS - Informationsteknologi The planning game I mere moderne organisationer spiller man ”the planning game” Regler: Ledelsen må vælge værdierne for tre af de fire parametre De som skal udføre opgaven må så – på basis af disse tre værdier – vælge værdien for den fjerde parameter RHS - Informationsteknologi

RHS - Informationsteknologi The planning game Eksempel Ledelsen siger Vi skal være færdige 1/1-2013 Kravene til funktionalitet er… Kravene til kvalitet er… Dem som skal løse opgaven siger: OK, så skal vi bruge 16 mand som er 80 % på dette projekt, frem til 1/1-2013 RHS - Informationsteknologi

RHS - Informationsteknologi The planning game Eksempel Ledelsen siger Vi kan sætte 12 mand af med 70% allokering Kravene til funktionalitet er… Kravene til kvalitet er… Dem som skal løse opgaven siger: OK, så kan vi være færdige 1/5 - 2013 RHS - Informationsteknologi

RHS - Informationsteknologi The planning game Eksempel (nok det typiske…) Ledelsen siger Vi kan sætte 12 mand af med 70% allokering Kravene til funktionalitet er… Deadline er 1/1-2013 Dem som skal løse opgaven siger: OK, men så bliver det i en skod-kvalitet  RHS - Informationsteknologi

RHS - Informationsteknologi Planning poker Hvordan finder man ud af, hvor meget det kræver at løse en bestemt opgave? Man løser opgaven  Alternativt Tidligere erfaringer Estimeringsteknikker Mavefornemmelse / gæt RHS - Informationsteknologi

RHS - Informationsteknologi Planning poker Hvis en gruppe skal estimere en opgaves omfang, er der ofte meget psykologi og gruppedynamik involveret Faglig stolthed Tabe ansigt ”Jeg vil ikke virke dum” Estimater bliver ofte for lave RHS - Informationsteknologi 28

RHS - Informationsteknologi Planning poker Planning Poker er et redskab til at gøre estime-ring mere objektivt Regler Der fremlægges en opgave, som skal estimeres Opgavens detaljer kan diskuteres Efter endt diskussion vælger hver deltager skjult sit eget estimat for opgavens omfang, f.eks i mande-timer Alle viser deres estimat De med højest og lavest estimat detaljerer deres grunde for deres estimat Man tager en runde til, indtil estimaterne er rimeligt ens. RHS - Informationsteknologi

RHS - Informationsteknologi Planning poker For at planning poker kan virke, er der nogle krav til deltagerne Respektér hinanden, og hinandens argumenter Det er ikke en kamp om at det laveste estimat skal vinde; det bedste estimat skal vinde Lær af hinandens argumenter, prøv ikke bare at skyde dem ned Respektér, at folk ændrer deres estimater undervejs Stop, når forskellen på det højeste og laveste estimat er mindre end 50 % RHS - Informationsteknologi