Løsningsforslag Sluttprøve 2015

Transkript

1 Høgskolen i Telemark Løsningsforslag Sluttprøve 2015 Emne: IA4412 Systemutvikling og dokumentasjon Fagansvarlig: Hans- Petter Halvorsen, Olav Dæhli Klasse: IA2, A- vei Dato: Time: 09:00-12:00 Oppgavesettet består av følgende: Antall sider: 12 (inkl. denne siden og vedlegg) Antall oppgaver: 5 Vedlegg: Ingen Hjelpemidler: Ingen hjelpemidler tillatt Sluttprøven teller 30% av sluttkarakteren. Kandidaten må selv kontrollere at oppgavesettet er fullstendig. Fagansvarlig besøker normalt ikke eksamenslokalene. Kandidater kan ikke kalle på fagansvarlige for å få hjelp til å tolke noen av eksamensoppgavene. Hvis du mangler eventuelle forutsetninger for å løse oppgaven, må du definere passende antagelser selv. All svar må begrunnes, selv om det ikke står dette eksplisitt i oppgaveteksten! Vennligst bruk kulepenn og skriv tydelig (hvis sensor ikke kan lese håndskriften har man ikke annet valg enn å gi 0 poeng)!

2 Oppgave 1 (20%): Softwareutvikling Oppgave 1.1 (5%) Programmering er sentralt, mens andre aktiviteter også er viktige i systemutvikling, som f.eks.: Problemanalyse Kravarbeid (Kravspesifisering) Utforming (Design) Implementering, som jo innebærer mye mer enn bare programmering Testing Validering Innføring (Utrullling, Deployment, Installasjon, ) Vedlikehold Oppgave 1.2 (5%) a) En systemutviklingprosess er et rammeverk for hvordan vi kan komme fra A til Å i utviklingen av et system. Eksempler på systemutviklingsprosesser: Fossefallsmetoden Scrum XP Bør ha med minst 3 for å få full pott. b) Det er viktig å ha en god systemutviklingsprosess fordi systemutvikling- prosessen påvirker blant annet: Prosjektstyringen Arbeidsmiljøet Hvilken type og mengde kommunikasjon systemutviklerne har med kunde(r) 2

3 Hvilken type og mengde kommunikasjon systemutviklerne har med hverandre Hvordan man estimerer tidsbruk Hvor godt man tar høyde for endringer som forekommer underveis etc Oppgave 1.3 (10%) a) Fossefallsmodellen: Plandrevet prosessmodell. Fossefallsmodellen består av fem forskjellige faser. Om en fase er ferdig, går man i utgangspunktet ikke tilbake til den. Derav navnet fossefallsmodellen. 5 Hovedfaser: 1. Kravspesifisering 2. System- og softwaredesign 3. Implementasjon og enhetstesting 4. Integrasjon og systemtesting 5. Installasjon og vedlikehold b) Plandrevne vs. smidige Tabellen viser noen forskjelle på disse: Plandrevne Prosessaktivitetene planlagt på forhånd. Progresjon måles i henhold til planen En tung prosess som inkluderer mange aktiviteter og roller. Krever formelle, detaljerte og konsistente prosjektdokumenter Vektlegger aktiviteter som gjøres tidlig i prosessen (planlegging, analyse & design) Smidige Planleggingen gjøres litt etter litt (inkrementelt) Enklere å endre prosessen for å tilpasse endrede krav fra kunden Fokuserer mer på fundamentale prinsipper (f.eks. kontinuerlig testing ). Har færre formelle dokumenter og er ofte mer iterative 3

4 c) Når bruke Fossefallsmetoden: Det finnes en rekke kjente systemer som har en endelig og fastsatt kravspesifikasjon. Med stabile krav, kan man ofte med sikkerhet anvende en plandreven prosess. Eksempel: Kalkulator Det eksisterer også en rekke systemer som er kritiske. Dette betyr at en eventuell systemfeil kan forårsake tap av menneskeliv eller andre store verdier. Slike systemer bør ikke leveres inkrementelt og det settes krav til at kravspesifikasjonen er komplett før utviklingen starter. Eksempel: Flytrafikksystemer, atomreaktor og lignende. Om noen eller flere av de følgende faktorene er tilstede, kan det være gunstig å benytte fossefallsmodellen: Systemet som skal utvikles er stort Det er store geografiske avstander mellom utviklerne Systemet som skal utvikles er velkjent Systemet er et kritisk sanntidssystem 4

5 Oppgave 2 (15%): Scrum Oppgave 2.1 (10%) Scrum er en smidig utviklingsmetodikk. Metodikken baserer seg på at man deler opp arbeidet i sprinter som har en varighet på 2-4 uker. I hver enkelt sprint er det en rekke definerte faser som utviklingsteamet skal igjennom. Scrum - a term used in Rugby football A Framework for Software Development An Agile Software Development method Simple to understand Flexible Exremely difficult to master! Self- organizing Teams (3-9 persons) Scrum Team: Her er en overordnet skisse: Daglige standups: Det er vanlig med daglige standups der alle på teamet kort besvarer følgende spørsmål: 5

6 Hva har jeg gjort siden sist? Hva skal jeg gjøre i dag? Hvilke eventuelle hindringer har jeg? Her er forklaring av noen begreper som brukes i Scrum: Sprint: Periode på 2-4 uker. Utvikler funksjonalitet, leverer til kunde etter hver sprint Backlog: En prioritert liste med arbeidsoppgaver som skal utføres i prosjektet. Produkteieren har ansvar for å vedlikeholde denne listen. Består ofte av såkalte brukerhistorier Scrummaster: Ansvarlig for å holde daily- standups og å beskytte utviklingsteamet mot forstyrrelser fra blant annet kunde. I implementeringsfasen er det derfor Scrum Master som hovedsakelig skal ta seg av all kundekontakt. Produkteier: Eier av visjon og representant for interessentene. Ansvarlig for product backlog og for hvilke oppgaver som skal prioriteres. Produkteier skal aldri være Scrum Master. Scrum Team: Et tverrfaglig team som skal utvikle inkrementet i hver sprint. Alle utover de to øvrige rollene er likestilte, og enhver har ansvar for å bidra med sin kompetanse under en sprint. Oppgave 2.2 (5%) Her er noen eksempler hvor smidig utvikling kan være gunstig å benytte: Interaktive applikasjoner Utvikling av nye ideer Ved små utviklingsteam og prosjekter Prosjekter hvor det er sannsynlig at kravspesifikasjonen endres underveis 6

7 Oppgave 3 (15%): Kravhåndtering Oppgave 3.1 (5%) Kravspesifikasjon: Prosessen å identifisere, analysere og spesifisere kravene til et IT- system. Hva er det som skal lages? Dette formaliseres i et kravspesifikasjonsdokument som spesifiserer bruker- og systemkrav. Dette brukes som basis for anbud, kontrakt og design og implementasjon av systemet. En kravspesifikasjon er viktig fordi det Skaper felles forståelse av systemet Skaper enighet om hva som skal leveres Er grunnlag for kontrakt som viser hva leverandør og kunde blir enige om Forhindrer eventuelle konflikter som kan oppstå på bakgrunn av uklare forventninger Oppgave 3.2 (10%) Funksjonelle krav: Funksjonelle krav definerer hva systemet skal gjøre. Hvilke tjenester (funksjoner) systemet skal tilby. Hvordan det skal reagere på ulike typer input. Kan også si hva systemet ikke skal gjøre De skrives gjerne slik: Systemet skal kunne Systemet bør kunne... Eksempler: Systemet skal kunne legge til restauranter Systemet skal kunne legge til en vurdering av en restaurant Systemet skal kunne vise restauranter som er i nærheten av brukeren 7

8 Systemet skal kunne legge til en meny for en restaurant Systemet skal kunne sortere restauranter basert på vurdering Ikke- funksjonelle krav er ved hvilke rammer systemet skal implementere de funksjonelle kravene. De kan anses som egenskaper. Egenskapene må evalueres ved at man må kunne måle/teste dem. Kan også beskrives som kvalitetsønsker Ikke- funksjonelle krav skrives typisk slik: Systemet må være egenskap Eksempler: Systemet må være raskt, det skal ikke ta mer enn 5 sekunder å laste inn en side Systemet må være brukervennlig, en ny kunde skal finne en restaurant på under ett minutt Systemet må være plattformuavhengig Systemet må kunne håndtere samtidige brukere All systemdokumentasjon skal være skrevet på engelsk 8

9 Oppgave 4 (30%): Software- modellering Oppgave 4.1 (15%) Oppgave 4.2 (10%) Løsningsforslag dersom fremmednøkler tas med i visningen: Denne løsningen forutsetter at det er kun en passasjer per booking? - som jo er en begrensning. Noen flere kolonner i de ulike tabellene bør også være, f.eks hvilket land flyplassen ligger i, adddrese, Passasjerens addresse, epost, brukernavn, passord, informasjon om flytype, osv. 9

10 Løsningsforslag dersom fremmednøkler ikke tas med i visningen: Oppgave 4.3 (5%) Use case benyttes til å beskrive hva et system skal gjøre, men ikke hvordan oppgaven skal løses. De er ment å være intuitive og lette å forstå, så de også kan brukes i kommunikasjon med oppdragsgivere. De er derfor godt egnet i en kravspesifikasjonsfase. Klassediagram brukes til å beskrive og dokumentere et objektorientert systems statiske struktur. Dette innbefatter å beskrive hvilke klasser som inngår og hvordan disse er relatert til hverandre (men ikke interaksjonen dem imellom). Sekvensdiagram er et interaksjonsdiagram som viser hvordan objekter i systemet samhandler gjennom utveksling av meldinger. Objekter (og eventuelt actors) oppføres horisontalt på toppen av diagrammet. Vertikalt er det en tidslinje der tiden øker nedover langs aksen. Objekters levetid markeres med søyler, og diagrammet påføres meldinger som utveksles mellom objektene. Denne diagramtypen kan f.eks. brukes til å beskrive hvordan et use case kan realiseres. 10

11 Oppgave 5 (20%): Testing Oppgave 5.1 (5%) a) Gjenstående feil? Her er noen eksempler: Testene er skrevet av utviklerne. Dermed er det mulig at testene ikke dekker alle mulige utfall Vanskelig å teste mot noe du ikke vet er der Man vet aldri om man har oppdaget alle feil, fordi de ikke er oppdaget, ennå Hva om testene ikke er skrevet riktig? b) Nødvendigheten av feilfritt? Her er noen eksempler: De fleste programmer er ikke så kritiske at det ikke kan være gjenstående feil ved levering av produkt Noen feil blir ikke oppdaget før lenge etter at et system er tatt i bruk, for eksempel en funksjon som sjeldent brukes og med spesiell input Som regel lite lønnsomt å forsøke å rette alle feil før det settes i produksjon. Dette vet både kunde og leverandør, og ulike kontraksmessige forhold regulerer slik feilretting c) Teste sin egen kode? Fordeler med at utviklerne tester sin egen kode: Det er tidsbesparende at de selv tester koden, spesielt i enhetstesting og tidlig i utviklingsfasen. Mange feil blir oppdaget under whitebox- testing. Unødvendig at et uavhengig testteam skal finne feil som utvikler lettere finner fordi de kjenner den interne strukturen og koden i systemet. Oppgave 5.2 (10%) a) Regresjonstesting: Når vi benytter regresjonstesting utfører vi de samme testene om igjen etter hver kodeendring, selv om kodeendringen ikke nødvendigvis ligger i den koden som omhandler testen 11

12 Gamle feil kommer ofte tilbake etter kodeendringer, og en av årsakene er at utviklere kan sjekke inn feil versjon av kode Det er ofte slik at en endring et sted i koden kan ha følger andre steder i programmet som man ikke forutså på forhånd b) Enhetstesting vs. integrasjonstesting: Enhetstesting tester individuelle enheter av kildekode. I objektorientert programmering kan det være en hel klasse eller en metode Enheten testes helt isolert fra resten av systemet Formålet med en enhetstest er å forsikre at koden gjør akkurat det den skal I integrasjonstesting setter vi sammen enheter til og gjør tester på disse sammensatte enhetene c) Minibank system: Eksempel på Enhetstester: Blir PIN- kode validert korrekt? Blir kort godkjent korrekt? Blir kort spyttet ut korrekt? Eksempel på Integrasjonstester: Henter man saldo fra riktig konto? Trekkes riktig beløp fra konto? Oppgave 5.3 (5%) Hva er funksjonell og ikke- funksjonell testing? Gi eksempler. Funksjonell testing: HVA systemet gjør. Tester om systemet gjør det de funksjonelle kravene spesifiserer. Brukeren skal trykke på en knapp for å ta ut penger, osv. Ikke- funksjonell testing: HVORDAN systemet virker. Tester brukervennlighet, effektivitet, robusthet, etc. Viktig at disse er målbare! 12