Rätt från början
•Download as PPTX, PDF•
0 likes•495 views
Många organisationer vet vad de vill ha och har välfungerande processer för att säkerställa att det som beställts verkligen är det som levereras. Men hur säkerställer man att det man beställer är det verksamheten verkligen behöver? Och vad händer när man får det man beställde men inte det man behövde? Kanske har verksamheten kommit med krav som inte pekar mot något identifierat effektmål alls? Bör dessa då inte genomföras eftersom de inte bidrar till att uppfylla effektmålen eller indikerar kraven kanske på att det finns ytterligare bakomliggande behov som ännu inte är identifierade? Hur kan du som beställare göra för att oftare lyckas med att beställa lösningar som möter upp mot de bakomliggande behoven i din verksamhet?
Recommended
Recommended
More Related Content
Similar to Rätt från början
Similar to Rätt från början (20)
More from ADDQ
More from ADDQ (8)
Recently uploaded
Recently uploaded (20)
Rätt från början
- 2. AGIL BEHOV KRAVLEDNING KONTRAKT ANALYS VERIFIERING VERKTYG MODELLERING SPÅRBARHET ABSTRAKTIONSNIVÅER PRIORITERING ICKE FUNKTIONELLA KRAV KRAVUTVECKLING VATTENFALL ÅTAGANDE RISK KRAVLEDNING FUNKTIONELLA KRAV OUTTALADE KRAV IREB TESTBARHET IEEE 830 SPECIFIERING REQB
- 9. Se det andra inte ser 6
- 10. Mönsterbrytare?
- 11. Tänk Tvärtom?
- 12. Feinschmecker?
- 13. Behov Kors & Tvärs?
- 16. Reflektera 6
- 17. Kultur
- 20. Komplexitet
- 21. ISO 25010 (Wikipedia) • Reliability - A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. • Maturity • Fault Tolerance • Recoverability • Reliability Compliance • Usability - A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. • Understandability • Learnability • Operability • Attractiveness • Usability Compliance • Efficiency - A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions. • Time Behaviour • Resource Utilization • Efficiency Compliance • Maintainability - A set of attributes that bear on the effort needed to make specified modifications. • Analyzability • Changeability • Stability • Testability • Maintainability Compliance • Portability - A set of attributes that bear on the ability of software to be transferred from one environment to another. • Adaptability • Installability • Co-Existence • Replaceability • Portability Compliance
- 22. Hur jobbar man med hur?
- 23. Bygg en prototyp
- 24. Erfarenheter och lärda läxor
- 26. Summering
- 27. • REQB Foundation Certificate Course – 1-2 juni, ADDQ Odinsgatan 11, Göteborg – Boka på addq.se!
- 28. Tack!
Editor's Notes
- 56… Säger det talet er något? 56 är grundämnet bariums position i periodiska systemet och Chiles landsnummer. 56 var året Ingemar Stenmark föddes och Ikea började sälja sina platta paket. 56 % är också den del av alla fel som är orsakade av brister i kravhanteringen när det kommer till IT utvecklingsprojekt. Räkna då med att i runda slängar 80% av alla IT projekt anses helt eller delvis misslyckade. Med dom dystra orden vill jag hälsa er välkomna till vårt frukostseminarie!
- Hur många av er känner igen orden på bilden? Är det kanske något ni brukar göra och arbeta med? Är det kanske något ni vet med er om att ni BORDE göra? Temat för dagen är att göra rätt från början, och varför är det viktigt att göra rätt från början? Jo för att vi är måna om slutresultatet, och målen nås ordentligt mycket smidigare, bättre och billigare om vi hanterar organisationens krav och behov på rätt sätt så tidigt som möjligt i ett projekt. Det finns hur många studier som helst som bekräftar det påståendet. Men för att kunna göra rätt behövs kunskap och inspiration! Idag kommer vi genom en tredelad föreläsning beröra tre vanliga områden där beställande organisationer ofta INTE gör rätt idag. Mina kollegor Per och Peter kommer att prata om ickefunktionella krav och outtalade krav. Själv tänkte jag börja med att prata lite om hur vi kommunicerar krav när vi beställer.
- När vi skall beställa något är vi onekligen just det där - on a quest. Vi söker efter något. Kanske är det lösningen på ett verksamhetsproblem eller uppfyllnad av ett behov? Är det man beställer och det man behöver samma sak? Hur kommunicerar man bäst med sin leverantör för att få det man behöver? Ingen vill väl vara en del av lösningen som inte löser problemet!
- Lösningskrav kontra affärskrav – när man beställer konfronteras man oundvikligen med KRAV Hur ser ett krav ut? Olika beroende på vem det kommer ifrån! Verksamheten, slutanvändarna - ofta konkreta krav med lösningsfokus. Knappar och dialogrutor Systemfunktioner Ledningen – ofta lite mer abstrakta. Kvalitativa mål – ökad nöjdhet. Kvantitativa mål – 30 % färre sjukskrivna. Rätt kravnivå när man ska kommunicera beställningar.
- Abstraktionsnivåer, vad är det? mellan himmel och jord Olika detaljnivåer av krav Verksamhets/affärskrav, lösningskrav, komponentkrav (Ge exempel) Olika kravnivåer är tillämpliga beroende på var i processen man är, är det utveckling eller presale? Verksamhetskrav viktiga initialt beställning. Dumt att lägga tid på
- Spårbarhet som analyshjälp Spårbarhet är bra till massa saker Koppla krav och testfall, koppla ändringar till krav, koppla olika krav inom samma område till varann. Viktigt att koppla ihop krav på abstraktionsnivåer – vertikal spårbarhet! Top down perspektivet. Titta på effektmålet och se vilka åtgärder som krävs Bottom up perspektiv.
- Effekt-i-(v) leverantörsdialog. Ge din leverantör ett kontext att utarbeta lösningsförslaget i. Kommunicera dina effektmål! Leverera verksamhetskrav, låt din leverantör leverera en lösning. Genom att detaljera kraven mer än det behövs så riskerar man att låsa in sig. (Vanligt att man tänker att ju noggrannare och mer detaljerat desto bättre) Bäst föredatum! Du ska bygga ett hus och arkitektritar ett som är tillräckligt för dig och din partner och för ert gemensamma barn. Av någon anledning blir det inte av och ritningen läggs på hyllan. 5 år senare tas den fram igen och huset byggs. Först när ni flyttar in märker ni att det inte finns tillräckligt många rum eftersom ni på 5 år i det närmsta fördubblat familjens storlek. Det händer ju inte tänker ni nu. Nä inte med hus nej, med IT system händer det hela tiden. Behov förändras eftersom det är omvärldsfaktorer som styr dem. Tänk på det när du beställer! Sammanfattning. * Gör din hemläxa, inte leverantörens jobb! Ju högre detaljnivå desto kortare bästföredatum på kraven. Krav förekommer på olika nivåer använd vertikal spårbarhet för att mappa ihop dom! TA FRAM PETERS BILD
- Enbart INTRO-slide, sista slide på SA preso
- Helikopterperspektiv
- Olika Hattar
- NFR: Mått: Diameter, Bredd, Axelns bredd Vikten, är viktig och att den är jämnt fördelad Hållbarhet: Hur många varv kan det rulla? Färg Material: Trä / Träslag Temperaturpåverkan: Kyla Frost, Värme Eld Hur påverkas hjulet om en eker bryts, två? Fler NFR? Bild på felhjul
- Icke-funktionella krav är ett oändligt stort område. Detta är olika kategorier av ickefunktionella krav enligt ISO standarden för Software Quality. Jag är ingen stor beundrare av ISO standarder men detta utdrag från wikipedia visar lite av hur komplext området är. Det är en helt egen vetenskap. Men man behöver inte alltid ha krav i varje kategori för att känna sig säker utan det är som det brukar vara med krav generellt. Det beror på.
- Contraints sätter scope och avgör var produkten/tjänsten inte ska leverera / tillhandahålla Exempel: Lagkrav sekretes Byggindustri standarder normer
- Kommer det ta lång tid att söka? Kommer webbgränssnittet fungera i Chrome? Skickas mina inloggningsuppgifter krypterat? Med en prototyp kan dessa HUR-krav samlas in på ett relativt tidigt stadium och kraven kan uppdateras för att maximera produktens kundnytta. Alternativet är att dessa krav ställs när produkten är ”nästan färdig” och då blir ändringar antingen betydligt dyrare eller kanske omöjliga att genomföra inom projektets ramar.
- Säkra kompetens från liknande projekt både på beställarsidan och leverantörssidan för att sätt säkerställa bästa förutsättningar att inte uppfinna hjulet igen. Kravdokument är, om än alltid levande, ofta väldigt återvinningsbara!
- Om tidigare releaser finns eller liknande produkter är levererade sedan innan, så finns ovärderlig information där som ett smörgåsbord. Förvaltningen har god kännedom om vilka problem som kunder har upplevt och min erfarenhet säger att de ofta är av NFR karaktär. Funktionerna är ju redan där och är en förutsättning för att produkten kan brukas. Icke funk däremot kan vara svårare att ringa in och lämnas därför tills det gör tillräckligt “ont”.
- Vi har varit inne på tre olika aspekter av kravarbetet. Sara började att prata om olika abstraktionnivåer av krav, vikten av att beskriva kravkontext och inte minst att krav har ett bästföredatum som är delvis beroende på kravets detaljnivå och omvärldsfaktorer. Peter fortsatte sedan med att prata om tänkvärda infallsvinklar när man ska fånga de outtalade kraven. Det handlade om att se det andra inte ser genom att i ett helikopterperspektiv, ha modet att bryta mönster och samtidigt vara finsmakare när det kommer till detaljer. Jag avslutade sedan med att prata om ickefunktionella krav. Jag och Peter pratade om att visualisera, att bygga prototyper för att fånga ickefunktionella krav och att värdesätta och arbeta med återkoppling från slutanvändarna. Målet med dagens dragning, som Sara var inne på inledningsvis, var att ge exempel kring kravaspekter för att höja chanserna att göra rätt från början. Kravområdet är fullt av fällor och vi har pratat om några idag. Vi har presenterat några tips på hur du kan undvika att trampa i fällorna. För det kan göra riktigt j-a ont! Tänk på siffran 56!
- En bra början är att skaffa kunskap i kravområdet. Vi vill passa på att tipsa om REQB Foundation, som är en internationellt gångbar certifieringskurs på två dagar i grundläggande kravhantering. Där man får verktyg för att lyckas med kravhantering i det vardagliga arbetet. Vi kan varmt rekommendera den som en bra början! Nästa tillfälle är redan 1-2 juni här i Göteborg. Även om det redan finns anmälda deltagare så finns det platser kvar!
- Tack för oss och hoppas ni känner givande. Vi hoppas ni tar er tid att fylla i utvärderingsenkäten innan ni fortsätter med onsdagen. Självklart finns vi kvar för vidare frågor och diskussioner.