Arbeidet med kravspesifikasjonen In 140 Sommerville kap. 6.

Slides:



Advertisements
Liknende presentasjoner
Risiko Sannsynlighetsgradering:1 = Lite sannsynlig (kan inntreffe mindre enn én gang hvert 100. år) 2 = Mindre sannsynlig (kan inntreffe mellom én gang.
Advertisements

Hvordan skrive en vitenskapelig artikkel?
Hva slags spørsmål skal man stille på hvilke nivåer?
Utlandsprosessen Studiestøtteonferansen i Stockholm 1. – 3. juni 2014.
Praktisk info til prosjektkunder
May Britt Drugli Førsteamanuensis, RBUP, NTNU
Tips og råd for praktisk kompetansearbeid
Forelesning IMT Februar 2006
Prosjektstyring In 140 Sommerville kap 4.
Prototyping & Use Case Software Engineering Gruppe
Ideutvikling - Problemdefinisjonen. Hva gjør de erfarne problemløserne? •Samler og analyserer informasjon og data •Snakker med mennesker som kjenner problemet.
Å overleve oppgaveskriving: Litteraturgjennomgang
Det utdanningsvitenskapelige fakultetet, Institutt for lærerutdanning og skoleforskning Artikkelbaserte avhandlinger og veilederrollen Seminar for kandidater.
Gruppeundervisning / Innleveringer Obligatoriske innleveringer: –Leveres til gruppeleder. Innlevering 1: Uke 10 ( ) –Markedsanalyse.
1 Oppgave gjennomgang Kap Oppgaver -Kap 12: 1, 2, 3, 5, 7, 8, 11, 18, 19.
Kompetanseutvikling Seminar Bjørnefjorden 09. febr Av
Prosjektstyring In 140 Sommerville kap 4.
Verifikasjon og validering
Prototyping In 140 Sommerville kap. 8. Mål Forstå hensikten med prototyping i forskjellige utviklingsprosjekt Forstå forskjellen mellom evolusjonær og.
Systemmodeller In 140 Sommerville kap. 7. Mål Forstå hensikten med kontekstmodell Forstå ideene bak –oppførselsmodellering –datamodellering –objektmodellering.
Objektorientert utforming In 140 Forelesning Nr 13 Sommerville kap 12 – del 2.
Kravanalyse og spesifikasjon
Hovedprinsipper i Rational Unified Process
Bendik Bygstad Høgskolen i Vestfold RUP-prosjekt Sammenhengen med UML 1.Hovedstruktur i RUP-prosjekter 2.Faser og iterasjoner 3.Sammenhengen med.
1 Skal vi snakke sammen? Jan Håvard Skjetne SINTEF / University of Melbourne
Human Factors (HF) i kontrollrom - En revisjonsmetode 2003
Innledning SIF80AP Future and HCI av Brad Myers m.fl.
UML og grensesnitt UML er standard for modellering innen objekt-orientert programvare kan UML også brukes til modellering av grensesnitt? fordel: bedre.
Software Requirements Elicitation
© Eurokompetanse a.sISO 9000:2000 august 2001 nr. 1.
Ledelse av systemutviklingsprosjekter Leikny Øgrim Høgskolen i Oslo.
Framtidens kompetanser - og hvordan vi utvikler dem
Dokumentasjon av rettslige beslutningssystemer Dag Wiese Schartum, AFIN.
CARISMA Context-Aware Reflective Middleware System for Mobile Applications.
Å omfavne forandringer med ekstrem programmering(XP) Brukt i In140 Skrevet av Ola Bø Bygger på Kent Becks artikkel "Embracing change with extreme programming."
Spørsmål til diskusjon Hvordan kan vi påvirke holdningene i alle ledd -Se til England? -Den gode samtalen? -Annet.
Spørsmål og aktiviteter på ulike nivåer
Prosjektavslutning og sluttrapport
Identifisere behov – og etablere krav
BUCS Utfordringer og valg av fokus Tor Stålhane. Rammebetingelser Første spørreundersøkelse viser at det vi gjør må kunne: Brukes sammen med UML Passe.
Objektorientert utforming In 140 Sommerville kap. 12.
Valgforums valgkonferanse 2014 Har du tenkt på hva som kan gå galt?
Dokumentasjon av rettslige beslutningssystemer Dag Wiese Schartum, AFIN.
Brukermedvirkning In 140 Forelesning. Historie Skandinaviske tradisjon Sosio-teknisk metode NJMF-prosjektet( ) –Dataavtalen LO-NAF(i dag NHO) –Arbeidsmiljøloven.
Programvareendring del 1 In 140 Forelesning Nr 21 Sommerville kap 27, 1. Del.
In Forelesning Sommerville kap 4 andre del
Forstudie Nå situasjonen: dagens situasjon med ulemper og fordeler
Masteroppgave Administrasjonsmoduler til eAccess.
FINF- H -05, 13. september 2005 Arild Jansen. AFIN/UiO 1 FINF Forelesning 13.sept Personvern som premiss for SU-prosessen Diskusjon om personvern.
Objektorientert design
Konstruksjon og Testing Torsdag 30. september 2004 Av Even Aasland Harald Ueland.
Objektorientert utforming In 140 Forelesning Nr 11 Sommerville kap 12 – del 1.
Systemmodeller In 140 Forelesning nr. 9 Sommerville kap. 7.
OPPGAVER MÅL TEKNOLOGI.
Objektorientert design In 140 Sommerville kap 12 – del 1.
Use case realisering Designmodellering Kirsten Ribu Kapittel 4 UML Distilled.
Evaluering av [prosjektnavn] [navn]. Resultat kontra mål Målsetting: Oppgi opprinnelig mål eller prosjektmål –Lag en liste over de viktigste måleenhetene.
Tips og råd Til hva dere bør tenke på når dere setter samme et business case (basert på innspill fra seminar )
I den prosessorienterte organisasjon spør man
RIS-metoden for prosessforbedring
Rammer for og organisering av eForvaltningen
Identifisere behov – og etablere krav
Bompengereformen en suksess? Forutsetninger og fallgruber
Case og empiri <Fag> <Navn> Institutt for statsvitenskap
Dokumentasjon av rettslige beslutningssystemer
Lærerik bruk av læringsteknologi «Skoleår»
Evaluering av «MUSIT Ny IT-arkitektur»
Dybdelæring – regneark B – Samarbeid
Prosjektmodellen Otto Husby Cimple AS.
Utskrift av presentasjonen:

Arbeidet med kravspesifikasjonen In 140 Sommerville kap. 6

Mål Forstå de viktigste aktivitetene i arbeidet med kravspesifikasjonen og forholdet mellom dem. Bli kjent med flere teknikker for å arbeide med kravspesifikasjoner Forstå betydningen av kravvalidering og hvordan kravgjennomganger brukes til dette Forstå hvorfor det er nødvendig å administrere kravene og hvordan dette støtter arbeidet med kravspesifikasjonen

Målet er å skape kravspesifikasjonsdokumentet Fire grunnleggende aktiviteter Forstudie Faktainnsamling og kravanalyse Kravspesifisering Kravvalidering Strukturerte analysemetoder – Muligheter og begrensninger

Forstudie Starter med en grovskisse av systemet og hvordan det skal brukes. Resultatet er en rapport der konklusjonen er: –Det er verdt å fortsette videre med kravspesifikasjon –eller ikke. Dette bør belyses: –Bidrar systemet til organisasjonens mål –Kan systemet lages med eksisterende teknologi innenfor tids og kostnadsrammer –Kan systemet integreres med systemer som allerede eksisterer

Spørsmål som kan stilles etter at informasjon er hentet inn: –Hvordan kan organisasjonen greie seg uten det planlagte systemet –Hva er problemet med eksisterende løsninger, og hvordan vil et nytt system kunne bidra til å løse problemet –Hvilke direkte bidrag kan systemet gi til forretningsmålene –Kan informasjon overføres til andre systemer i organisasjonen (Datafangst) –Bruker systemet teknologi som er ny for organisasjonen? –Hva skal systemet støtte og hva skal det ikke støtte

Hvem kan svare på spørsmål –Avdelingsledere –Utviklere med erfaring fra området –Teknologieksperter –Sluttbrukere Forstudierapporten skal –Gi en konklusjon – skal vi fortsette? Forstudierapporten kan endre –Budsjett –Omfang –Tidsplan –Krav

Faktainnsamling og kravanalyse Samarbeid mellom utviklere, kunde og sluttbrukere for å: –Forstå anvendelsesområdet –Finne hvilke tjenester systemet skal levere –Krav til ytelse osv osv Kan involvere mange ulike interessenter Vanskelig prosess fordi: –Interessentene vet ikke hva de kan kreve –Interessentene bruker sin forståelse og terminologi –Interessentene har forskjellige mål og utrykksform –Politisk innflytelse –Dynamisk økonomisk og organisatorisk miljø –Interessentblandingen kan endre seg

Faktainnsamling og kravanalyse

Teknikker for faktainnsamling og kravanalyse Perspektiv orientert VORD Scenarier Etnografi

VORD – Viewpoint Oriented Requirement Definition Mange interessenter i et middels system. Eksempel: Interessenter i en bankautomat ATM –Kunder i egen bank –Andre banker –Leder for avdelingskontor –Skrankepersonale –Databaseadministratorer –Sikkerhetssjefer –Markedsavdelingen –Vedlikeholdspersonale

Viewpoint kan defineres som –Datakilde eller bruker/sluk –Systemmodell f.eks ER vs Tilstandsdiagram –Tjenestemottaker Interaktive systemer Naturlig struktureringsmetode Lett å sjekke gyldighet Også god strukturering av ikke funksjonelle krav Informasjon om VP og tjenester i standard skjemaer

VORD-maler for viewpoint og tjenester Viewpoint-mal Referanse Atributter Hendelser Tjenester UnderVP Tjeneste-mal Referanse Begrunnelse Spesifikasjon Ikke funksjonelle krav Leverandør

VORD Idemyldring – Boblediagram Identifisere VP og tilhørende tjenester Ikke-allokerte tjenester VP –tjenestemottaker –datakilde –kontrollkilde CASE nødvendig

Scenarier Beskrivelse av samhandling bruker/system Nyttig ved overgang fra grovbeskrivelse Kan inneholde: –Tilstandsbeskrivelse ved start –Hendelsesrekkefølge –Mulige feil og hvordan de takles –Samtidige aktiviteter –Tilstandsbeskrivelse ved slutt Uformelt eller strukturert –Hendelsesscenarier –Use case (Anvendelsestilfelle)

Hendelsesscenarier Del av VORD – beskriver hendelsesrespons Hver enkeltinteraksjon kan dokumenteres med eget scenarium –Dataflyt (dataflow) –Systemhandlinger –Unntak

–Ellipse er datautveksling med VB –Kontrollinfo fra/til boksens topp –Data går ut på høyre interne data uten ramme –Unntak vises under boksen. Ved flere unntaksmuigheter i skyggeramme –Neste hendelse vises i skyggelagt boks

Use Case Scenariebasert (Jacobson 1993) UML (Use Case + Interaksjonsdiagram) Aktører og interaksjoner

Sekvensdiagrammer

Etnografi Programvaresystemer er i en sosial sammenheng Sosiale og organisatoriske krav kritisk suksessfaktor Observasjonsteknikk –Analysator i omgivelsene for systemet –Følge med i og notere hva som faktisk gjøres –Ubevisst organisering –Komplekst og rikt – ikke som antatt Spesielt effektiv i to sammenhenger: –Finne forskjeller mellom faktisk og beskrevet prosess –Finne behov for samarbeid Kan brukes sammen med prototyping Er ikke nok alene

Kravvalidering Er spesifikasjonen = kundens behov? Det bør sjekkes at spesifikasjonen er –Gyldig –Konsistent –Komplett –Realistisk –Verifiserbar Teknikker –Gjennomgang –Prototyping –Testtilfeller –Automatisk konsistenssjekk Vanskelig for utviklere Enda vanskeligere for sluttbruker

Kravgjennomgang Manuell prosess med representanter for oppdragsgiver og utviklerorganisasjon Formell eller uformell –Uformell diskusjon mellom utviklere og interessenter kan gi gode resultater –Formell walk-through. Sjekke alle punkter Konsistens Kompletthet Testbarhet Forståelighet Sporbarhet Tilpasningsdyktig –Konflikter, feil og mangler må skrives ned og løsning finnes

Kravadministrasjon Store systemer spesielt utsatt for forandringer –Skal forbedre eksisterende situasjon –Vanskelig å forutse hva nytt system innebærer –Stor og variert brukergruppe. Støttebalanse –Oppdragsgiver og sluttbruker har gjerne forskjellig behov –Endret systemmiljø –Økt forståelse gir nye krav Kravstyring er å forstå og styre endrede krav Parallelt med faktainnsamling og kravanalyse Ulike krav har ulik stabilitet

Konstante og flyktige krav Konstante krav –Stabile krav som er forbundet med kjernevirksomheten Flyktige krav –Krav som sannsynligvis vil skifte –Fire klasser: Krav som kan forandres av eksterne instanser Krav som har kommet til underveis Krav som er avhengige av det nye systemet Krav til kompatibilitet med arbeidsmåten.

Kravstyringsplanlegging Dette må du ta stilling til: –Kravidentifisering –Kravstyringsprosess –Sporbarhetsopplegg –CASE – støtte

Sporbarhet Eierinteressent og begrunnelse Hvilke andre krav henger sammen med dette kravet Hvordan er dette kravet planlagt innfridd Kravsammenhenger –Matrise –Database

Matrise for kravsammenheng

Kravforandringsadministrasjon Formell metode gir konsistent og kontrollert behandling –Problemanalyse og forandringsspesifikasjon –Forandringsanalyse og overslag –Implementering Kravspesifikasjonsdokumentet bør være skrevet for forandring: Få eksterne referanser og modulær oppbygning Ikke fall for fristelsen å gjøre en rask endring og så dokumentere etterpå