Forstudie Nå situasjonen: dagens situasjon med ulemper og fordeler

Slides:



Advertisements
Liknende presentasjoner
Praktisk info til prosjektkunder
Advertisements

Tema 7 FAG- OG SVENNEPRØVER
Endringsstyring Change Management.
Prototyping & Use Case Software Engineering Gruppe
Tips og triks Strukturering av større applikasjoner Automatiserte tester. Kristian Johannessen
Levende HMS-system – hva betyr det i praksis?
Hvem stakk av med produkteieren min?
Forstudie og Kravspesifikasjon
23. januar 2004TDT4285 Planl&drift IT-syst1 Tjeneroppgraderinger TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI.
Modellbruk i Referansekatalogen Øyvind Aassve NorStella.
1 Oppgave gjennomgang Kap Oppgaver -Kap 12: 1, 2, 3, 5, 7, 8, 11, 18, 19.
Grunnleggende testteori
Regneark II IN 102 Forelesning 4.
Programvare-prosesser
Prototyping In 140 Sommerville kap. 8. Mål Forstå hensikten med prototyping i forskjellige utviklingsprosjekt Forstå forskjellen mellom evolusjonær og.
Introduksjon til systemutvikling
Utført av: Jeppe Flensted HiST Vår 2009
Kravanalyse og spesifikasjon
Hovedprosjekt Prosjektledere: Ståle Furset Torbjørn Vik Oppdragsgiver: Torbjørn Vik.
Maximite AS Et konsulentselskap bestående av 8 uavhengige konsulenter som er spredt fra Finmark til Oslo Bred erfaring innen blant annet strategiutvikling,
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.
I dag snakker vi om: Brukergrensesnitt med kvalitet Bruksegenskaper Normans 7 stadier Testing med papirprototyp.
Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu
Human Factors (HF) i kontrollrom - En revisjonsmetode 2003
Empiriske metoder Oppgaveanalyse, observasjon
UML og grensesnitt UML er standard for modellering innen objekt-orientert programvare kan UML også brukes til modellering av grensesnitt? fordel: bedre.
1 19. januar 2006 TDT4285 Planl&drift IT-syst Om du ønsker, kan du sette inn navn, tittel på foredraget, o.l. her. Forelesning nr 6: Dynamisk dokumentasjon.
  © Steria FitNesse som nyttig verktøy Smidig FitNesse som nyttig verktøy Anders Vindvad.
Presentasjon  SW faults og failure/testing issues –Gruppe 1 Petter Therese Kjell Gunnar Christian Eva.
Gruppe 3 – Presentasjon 2 Henning Kristiansen, Mats Lindh, André Hauge og Vegard Simensen.
Strategi og samhandlingsarkitektur
Klare mål for kvalitets- og miljøarbeidet Nye utfordringer krever nye tanker: Skal vi sertifisere oss? Rica Nidelven Hotel Trondheim, 26. – 27.januar.
Opplæring; Lov om kommunale helse – og omsorgstjenester kapittel 9:
Retningslinjer for spesifikasjoner til oppdrag
Konfigurasjonsstyring Configuration Management
Hvorfor bruke tid på testing ?
Testing av objektorienterte systemer Testplanlegging
PUG-NORWAY OKTOBER 2008 THOMAS SKJØRTEN, HILDE ANDREASSEN UML og OpenEdge OOABL.
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.
Forstudie og Kravspesifikasjon
Easy answer Hovedprosjekt nr 56 våren 2001: ”web  interface  MobilSvar” - grensesnitt for innlegging av personlig velkomstmelding.
Programvare- prosesser - del2 In 140 Forelesning nr. 4 Sommerville kap. 3.
Masteroppgave Administrasjonsmoduler til eAccess.
FINF- H -04, 21 september 2004 Arild Jansen. AFIN/UiO 1 FINF Forelesning uke 39 Personvern som premiss for SU-prosessen Diskusjon om personvern som.
Konstruksjon og Testing Torsdag 30. september 2004 Av Even Aasland Harald Ueland.
Prosjekt ERP i Troms Kraft Beskrivelse prosjektfaser og overordnede prosesser
Prosjektnavn Firmanavn Presentert av
Status webSA 2013 Videreutviklingsrådet ninaelise
Identifisere behov – og etablere krav
RUP-prosjekt Sammenhengen med UML
Nytt Intranett Trøndelag Fylkeskommune
PDSA-sirkel/småskalatest
Ting Forbindelser Ting og forbindelser blir til sammen et diagram
Prosjektnavn Firmanavn Presentert av
Programvareprosessen styrer utviklingen
PDSA-sirkel/småskalatest
Utlånssystem for datautstyr
Prosjektnavn | Firmanavn |Navn på presentatør
Arbeidsprosesser, roller og ansvar
Hvordan lager du en åpen kravspesifikasjon og behovsbeskrivelse når du skal lage en IKT-løsning Kapittel 2 i SSA-S, SSA-T og innovasjonspartnerskapskontrakten.
Dybdelæring – regneark B – Samarbeid
Dybdelæring - GeoGebra B – Samarbeid
Dybdelæring – regneark B – Samarbeid
Forside/oversikt Fag / tema Naturfag Trinn 4.trinn
Modul 1 – Representasjoner
Utskrift av presentasjonen:

Forstudie Nå situasjonen: dagens situasjon med ulemper og fordeler dagens systemløsninger (S) dagens arbeidsprosesser (O) dagens roller/kompetanse/mennesker (P) Alternative løsninger: strukturert evaluering valg av løsning Konkurrerende løsninger Ønsket situasjon: morgendagens situasjon med ulemper og fordeler systemløsninger (S) arbeidsprosesser (O) roller og kompetanse (P)

Kravspesifikasjon Funksjonelle krav - funksjonell beskrivelse av kundens krav Nummerering vs ikke nummerering av krav Figurer og diagrammer – husk forklaring og konsistens! Overordnet programvarearkitektur Datamodell – entiteter og relasjoner Krav til GUI – farger, plassering av ikoner, gruppering av info, ol Prototyping av skjermbilder for å bedre kommunikasjonen med kunden Formler Ikke-funksjonelle krav – må avpasses den enkelte kundes infrastruktur Ytelse Responstider Oppetid ……. Valg av utviklingsverktøy Krav til dokumentasjon

Konstruksjon Fra hva til hvordan – fra spesifikasjon til realisering Beskrivelse av teknologien som skal brukes og hvordan denne skal brukes til å realisere komponentene Komponentstandard – regler/retningslinjer for design og programmering av komponenter Detaljert programvare arkitektur GUI Logikk Database ? Mellomvare Bruk av diagrammer, gjerne UML Pseudokode Itererer mellom konstruksjon og programmering?

Implementasjon Implementasjonsdokumentasjonen bør typisk inneholde: Programmeringsstandard. Standard for kommentering i koden (kommentarer for å gjøre koden mer forståelig) Legge ved noen sider som viser gode eksempler på hvordan standardene arter seg i praksis. Legg ved kode som viser programmering av spesielle algoritmer.   Koden skal dokumenteres på et slikt vis at kunden faktisk klarer å bruke denne videre.

Testing Testing planlegges og gjennomføres normalt i fem trinn: Overordnet testplan - bør gjøres senest i kravspesifikasjonsfasen Plan for hver enkelt test som skal gjennomføres - bør gjøres senest i konstruksjonsfasen Utarbeidelse av detaljerte testspesifikasjoner eller sjekklister for hver test - bør gjøres senest i konstruksjonsfasen Gjennomføring av testene inkludert retting av feil, retesting og dokumentasjon av testresultatene Godkjenning av testresultatene

Testing - fortsetter Viktige momenter i forbindelse med utarbeidelse av en overordnet testplan er:  Hvilke tester skal gjennomføres i dette prosjektet (tabell 2)? Hvilke tester skal det utarbeides sjekklister for? Sjekklister er mest vanlig for enhets- og modultester. Hvilke tester skal det utarbeides detaljerte testspesifikasjoner for? Detaljerte testspesifikasjoner er vanlig for system-, integrasjons-, brukbarhets- og akseptansetester Hvem skal teste? Prosjektet, kunden, …… Når skal det testes? En overordnet tidsplan. Hvem er ansvarlig for å utarbeide detaljerte testspesifikasjoner og sjekklister? Hvem skal det rapporteres til?

Testing - fortsetter Viktige momenter i forbindelse med utarbeidelse av testplaner er: Hva skal testes (arbeidsflyt, funksjonalitet, grensesnitt, ikke-funksjonelle krav, osv)? Når skal testen utføres? En detaljert tidsplan. Husk å planlegge med retting av feil og retesting Hvem skal teste? Navn på testerne. Test data, hvor skal de tas fra? - live/fake, automatic/manual, ....? Hvem er ansvarlig for å utarbeide detaljerte testspesifikasjoner? Klassifisering av feil Prosedyrer for hva dere gjør når dere finner feil Hvordan skal testresultatene rapporteres, dvs innhold i testrapporten? Godkjenningskriterier for testen Hvem godkjenner testen?   Detaljeringsgraden må avpasses i forhold til prosjektets behov.

Testing - fortsetter Detaljerte testspesifikasjoner bør inneholde: testbeskrivelser (de operasjonene som skal gjennomføres data som skal testes (input og forventet output)

Testing - fortsetter Typiske tester utført av prosjektet: Enhetstest Modultest Systemtest Integrasjonstest Typiske tester utført av kunden: Brukbarhetstets Akseptansetest Operasjonell test

Bruker- og installasjonsveiledning! To viktige dokumenter!!

Evaluering Fire bolker: Prosessen og resultatet – fokus på dere selv Kunden og oppgaven – fokus på kunden Faget – fokus på fagets opplegg og veiledere Videre arbeid

Presentasjon og demonstrasjon 20 minutter PRESENTASJON: forklar oppgaven og mål problemer og prioritering Hva tok dere fatt med ? Hvilke løsningsalternativer? Forklar litt om prosessen og de valg som har ført til den løsning vi ser i dag Løsningen Hva skal vi få se -> Overgang til demoen.  20 minutter DEMO 5 minutter spørsmål!