1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b)
2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan folk faktisk jobber a) implisitte systemkrav b) formelle prosesser c) kodestandarder d) etikk Svar: a)
3. Hvilke av følgende er IKKE et funksjonelt krav? a) Etter vellykket innlogging, høres en lyd b) Autentisering av brukeren (id og passord) kreves før bruk av systemet c) Systemet må utvikles i løpet av seks måneder d) Ingen data skal forsvinne ved strømbrudd Svar: c)
4. I systemutvikling inneholder en kravspesifikasjon en: a) liste av nøkkelpersonell som utgjør ledelsen b) fullstendig beskrivelse av tilstanden til systemet c) beskrivelse av hva systemet skal gjøre d) beskrivelse av programvare som vil implementere systemet Svar: c)
5. Brukerkrav beskrives i følgende språk: a) Kun engelsk b) Latin c) Naturlig språk d) Så teknisk som mulig Svar: c)
6. Hvilke av følgende er IKKE et prinsipielt trinn i en endringshåndteringsprosess? a) Problemanalyse b) Endringsanalyse c) Implementering av endringer d) Spesifikasjon av problem Svar: d), fig. 4.19 (spesifikasjon av problem er input ;l endringhåndteringsprosesen)
7. Scrum er et eksempel på: a) Prosess b) Prosessmodell c) Utviklingsprosess Svar: b), Se slides fra forelesning om systemutviklingsprosessen
8. Hvilken av disse er ikke en prosessaktivitet? a) Analyse b) Design c) Testing d) Pålitelighet Svar: d), Pålitelighet er et mål på ikke- funksjonelt krav
9. Hvilket utsagn er riktig? a. I fossefallsmodellen kan man ikke endre kode etter at systemet er satt i drift b. Fossefallsmodellen representerer plandrevne prosesser c. I fossefallsmodellen vektlegges iterasjoner Svar: b)
10. Omfattende testing vil alltid føre til et feilfritt system a) Sant b) Galt Svar: b)
11. Use Cases (bruksmønstre) kan sørge for verdifull input til design av black-box testing a) Sant b) Galt Svar: a)
12. Testing av metoder definert i objektorienterte klasser blir vanskeliggjort av: a) Innkapsling ( encapsulation ) b) Nedarving ( inheritance ) Svar: b)
13. En bedrift skal sette i gang et større systemutviklingsprosjekt. Hvor vil du kunne lese om hvorfor prosjektet skal realiseres? a) Kravspesifikasjonen b) Plandokumentet med milepæler og budsjetter c) Forretningsplanen Svar: c), se forelesning om prosjektledelse
14. I de fleste systemutviklingsprosjekter blir utviklingen organisert i team. Hvilket av følgende utsagn er feil? a) Like personlighetstyper og kjønn fungerer oftest best b) Jo større gruppen er, dess større utfordring med kommunikasjon c) Kommunikasjon går bedre i uformelle team enn i hierarkisk strukturerte team d) Det er vanlig med selvstyrte utviklingsteam i smidig metodikk Svar: a)
15. Hva vil du IKKE finne i en prosjektplan i et plandrevet utviklingsprosjekt? a. Prosjektorganisering b. Risikoanalyse c. Tidsplan for prosjektet d. Systemkrav Svar: d
16. Hvilken av følgende faktorer reduserer sjansen for overestimering av kostnader i et IT prosjekt? a. Høy usikkerhet b. Lite relevant erfaring c. Prosjektet er mindre enn tidligere prosjekter d. Lang varighet på prosjektet Svar: c
Eksamen 2011 Oppgave 2 a - Aktivitetsdiagram Velg drikke Velg styrke Lag drikke
Eksamen 2011 Oppgave 2 a - Aktivitetsdiagram ok Rengjøringslampe lyser Rengjør maskinen Velg drikke ok Mangler kaffe/melk Fyll på kaffe/melk Velg styrke Lag drikke Oppdater maskin (mengde kaffe/melk + rengjøring)
Eksamen 2011 Oppgave 2 a - Tilstandsdiagram Rengjøring Velger styrke rengjort Start Venter do/ Vis "Velg drikk" Velger drikk kaffe fylt på Melk fylt på Trykket fyll på melk trykket fyll på kaffe Velg styrke og utfør do/ Vis "Velg styrke" og "Utfør" Trykker utfør Lag drikk Fylle på kaffe do/ Fyller på kaffe entry/ Lokk åpnes exit/ Lokk lukkes Fylle på melk do/ Fyller på melk do/ Lag drikk exit/ Oppdater kaffemaskin (tilgjengelighet og rengjørin... Slutt
Eksamen 2011 Oppgave 2 b Tilstandsdiagrammer brukes for å modellere systemets tilstand i forhold til hendelser (eksterne eller interne). Systemet går fra en tilstand til en annen. Aktivitetsdiagrammer brukes for å modellere dataflyten eller prosessen i systemet.
Eksamen 2011 Oppgave 2 c Usecase-beskrivelse Navn: Velg drikke Aktør: Bruker av kaffemaskin Prebetingelser: Rengjør knappen lyser ikke, evt. ingen Postbetingelser: Valgt drikke utleveres Hovedflyt: H1: Bruker velger drikk H2: Hvis en drikk med kaffe er valgt, får brukeren et tilleggsvalg (kan endre styrke) H3: Bruker trykker utfør knapp H4: Systemet beregner riktig blanding H5: Systemet lager og leverer drikke H6: Systemet oppdaterer status for maskinen
Eksamen 2011 Oppgave 2 c Usecase-beskrivelse Alternative flyt: A1: Mangler melk A1.1: Mangler melk knapp aktiveres A1.2:Kun valg av drikke uten melk kan velges A1.3: Systemet fortsetter fra H1 A2: Mangler kaffe. Tilsvarende som A1 (bytt ut melk med kaffe) A3: Rengjør maskinen A3.1: Rengjør-maskin knapp aktiveres A3.2: Systemet opplyser om at ingen drikk kan velges før maskin er rengjort A.3.3: Systemet fortsetter fra H1
Eksamen 2011 Oppgave 2 d Klassediagram
Eksamen 2011 Oppgave 2 d Klassediagram
Eksamen 2011 Oppgave 2 d Klassediagram
Eksamen 2011 Oppgave 2 d Klassediagram
Eksamen 2011 Oppgave 2 d Klassediagram
Eksamen 2011 Oppgave 2 e Sekvensdiagram Velg drikke Ka : Kaffeautomat : Kaffemaskinbruker 1: velgdrikke(id) 2: lagdrikkeobjekt(id) : drikke 3: velgstyrke(styrke) 4: velgutfør() 5: leverdrikke(drikke, styrke) 6: oppdaterstatus()
Eksamen 2011 Oppgave 2 e Pseudo-kode (ikke spørsmål i oppgaven) Class Kaffeautomat { Drikke drikke; lagdrikkeobjekt(int id) :Drikke { switch (id) { case 0: drikke = new Espresso(); break; case 1: drikke = new Cappuchino(); break; etc. } return drikke; } velgdrikke (id) { drikke = lagdrikkeobject(id); } velgstyrke(styrke) { drikke.setsterk(styrke); } velgutfør() { leverdrikke (drikke, styrke); } }
Eksamen 2011 Oppgave 3 Empiriske metoder Det enkleste vil nok være å lage en spørreundersøkelse. Lag et skjema med relevante spørsmål som først testes ut på noen (3-4) pilotpersoner før det sendes ut til alle ansatte For å få mer dybdeinnsikt i hva folk mener og hvorfor, kunne man kjøre en intervju -undersøkelse. Det krever imidlertid mye mer ressurser (et intervju kan sjelden være mindre enn 1/2 time; typisk vil det ta en time). Derfor er det mest realistisk å velge ca. 20 personer som har ulike roller, og de må velges både blant de som har deltatt i ett av de to Scrum-teamene og de som ikke har drevet med Scrum. Synspunkter vil da kunne utdypes, men man kan ikke vite sikkert hvor representative synspunktene er. Hadde man hatt virkelig bra med ressurser og litt tid på seg, kunne man også kjørt et komparativ (sammenlignende) case-studie der man valgte ut ett prosjekt hos hver av de to Scrum-teamene og så lot to team som jobber tradisjonelt utføre de samme to prosjektene som Scrum teamene, slik at man har to prosjekter som begge kjøres av ett Scrum-team og ett tradisjonelt team. Utfordringen vil være å få prosjektene like nok med hensyn til kundeinvolvering, men det er mulig, jfr. Studien over "Database for empiriske studier" der fire firmaer lagde samme system (presentert på flere forelesninger).
Eksamen 2011 Oppgave 4a Scrum Scrum Jobber i team med en flat struktur, teamleder kalles Scrum-master, og er mer fasilitator enn tradisjonell prosjektleder (fordeler ikke oppgaver etc). Utviklingen foregår gjennom iterasjoner, kalt sprinter, av varighet 2-4 uker. Før en ny sprint starter gjennomføres sprintplanlegging der oppgavene som skal være med (kalles sprint backlog ) velges ut fra en større produkt backlog. En backlog er som regel en samling av user stories, og en produkteier (PO) har ansvaret for prioritering av oppgavene ( user stories) i en backlog. PO representerer kunden og er som regel med på sprint planleggingen og prioriterer oppgaver fra product backlog. Det er vanlig under sprintplanlegging at hele teamet er med på estimering av oppgavene ved bruk av såkalt planning poker. Noen foretrekker relativ estimering (en oppgave blir estimert til 8 points, en annen til 13 etc.). Andre foretrekker absolutt estimering (som regel i timer). Viktig i Scrum er daglige stand-up -møter der alle i teamet kort forteller om hva som er gjort siden siste møte (dagen før), problemer man eventuelt har og hva som skal gjøres fram til neste møte. Stand-up møtet skal være kort (det er derfor det er vanlig å stå, 15 min. er vanlig). Lange faglige diskusjoner tas i andre møter uten at alle trenger delta.
Eksamen 2011 Oppgave 4a Scrum Scrum Jobber i team med en flat struktur Teamleder kalles Scrum-master Mer fasilitator/tilrettelegger enn tradisjonell prosjektleder (fordeler ikke oppgaver etc). Utviklingen foregår gjennom iterasjoner, kalt sprinter, av varighet 2-4 uker. Før en ny sprint starter gjennomføres sprintplanlegging der oppgavene som skal være med (kalles sprint backlog ) velges ut fra en større produkt backlog. En backlog er som regel en samling av user stories, og en produkteier (PO) har ansvaret for prioritering av oppgavene ( user stories) i en backlog. PO representerer kunden og er som regel med på sprint planleggingen og prioriterer oppgaver fra product backlog. Det er vanlig under sprintplanlegging at hele teamet er med på estimering av oppgavene ved bruk av såkalt planning poker. Noen foretrekker relativ estimering (en oppgave blir estimert til 8 points, en annen til 13 etc.). Andre foretrekker absolutt estimering (som regel i timer). Viktig i Scrum er daglige stand-up -møter der alle i teamet kort forteller om hva som er gjort siden siste møte (dagen før), problemer man eventuelt har og hva som skal gjøres fram til neste møte. Standup møtet skal være kort (det er derfor det er vanlig å stå, 15 min. er vanlig). Lange faglige diskusjoner tas i andre møter uten at alle trenger delta.
Eksamen 2011 Oppgave 4a Kanban Kanban Baserer seg på Lean metodikk, bl.a. kjent fra Toyota og Just-intime prinsippet: Ikke start å lage noe før det er etterspurt. Kanban opererer ikke med tidsbokser som Scrum, man jobber til aktivitetene er ferdig. Kanban er flytbasert, dvs. oppgaver jobbes med inntil de er ferdige. I motsetning til i Scrum der man jobber innenfor faste tidsbokser. I Kanban settes det ofte et tak på antall oppgaver som kan utføres parallelt. Kanban brukes ofte der det er uungåelige avbrudd for å utføre support-, drift- og ad hocvedlikeholdsoppgaver. Også i Kanban er det vanlig å ha daglige Stand-up møter.
Eksamen 2011 Oppgave 4a Kanban Kanban Baserer seg på Lean metodikk, bl.a. kjent fra Toyota og Just-in-time prinsippet: Ikke start å lage noe før det er etterspurt. Kanban opererer ikke med tidsbokser som Scrum, man jobber til aktivitetene er ferdig. Kanban er flytbasert, dvs. oppgaver jobbes med inntil de er ferdige. I motsetning til i Scrum der man jobber innenfor faste tidsbokser. I Kanban settes det ofte et tak på antall oppgaver som kan utføres parallelt. Kanban brukes ofte der det er uungåelige avbrudd for å utføre support-, drift- og ad hocvedlikeholdsoppgaver. Også i Kanban er det vanlig å ha daglige Stand-up møter.
Eksamen 2011 Oppgave 4 b Scrum vs. Kanban I Scrum har man sprintplanleggingsmøter der man estimerer oppgaver og legger dem i en sprint backlog Dette kan være en fordel da det blir lagt ned ekstra innsats for å bli ferdig med en Sprint, og gjennom timeboxing har man oversikt over når ting skal være ferdige. Estimering av innsats er ikke så vanlig i Kanban, noe som kan være en ulempe ift. å beregne kostnadene i prosjektet. På den annen side er det i Kanban få aktiviteter som går samtidig ( just-in-time - prinsippet). Dette gjør at aktivitetene er mindre avhengige av hverandre. I tilfeller der det er vanskelig å estimere innsatsen eller det er mange avbrudd pga feilretting, support- eller vedlikeholdsoppgaver, kan Kanban være gunstig.
Eksamen 2011 Oppgave 4 b Scrum vs. Kanban I Scrum har man sprintplanleggingsmøter der man estimerer oppgaver og legger dem i en sprint backlog. Dette kan være en fordel da det blir lagt ned ekstra innsats for å bli ferdig med en Sprint, og gjennom timeboxing har man oversikt over når ting skal være ferdige. Estimering av innsats er ikke så vanlig i Kanban, noe som kan være en ulempe ift. å beregne kostnadene i prosjektet. På den annen side er det i Kanban få aktiviteter som går samtidig ( just-in-time - prinsippet). Dette gjør at aktivitetene er mindre avhengige av hverandre. I tilfeller der det er vanskelig å estimere innsatsen eller det er mange avbrudd pga feilretting, support- eller vedlikeholdsoppgaver, kan Kanban være gunstig.