Uke 42 // Systemutvikling

1. Hva er systemutvikling?
   Systemutvikling er prosessen med å opprette og vedlikeholde informasjonssystemer. Å utvikle et informasjonssystem inkluderer alle de fem komponentene: Hardware, Software, Data, Prosedyrer, og mennesker.
2. Hvorfor er systemutvikling både utfordrende og risikabelt?
   Det er fordi det krever at man inkluderer alle de fem komponentene, og krever derfor mer enn kun programmering eller teknisk ekspertise. Man må ta hensyn til systemets formål, oppsett av prosjektet, og bestemme de nødvendige kravene for kunnskap og ledelseskompetanse.
1. Vanskelig å fastslå krav
2. Endringer i krav
3. Vanskeligheter med tidsramme og budsjett
4. Endringer i teknologien
3. Hvilke faser/aktiviteteter inngår i SDLC?
   SDLC (System development life cycle)
1. Beskriv hver av de fem fasene.
   
1. Definering av systemet
   Bruke administrasjonens utsagn om systemets behov for å kunne begynne å definere det nye systemet.
2. Analyse av krav
   Her identifiserer utviklerne de særlige funksjonene i det nye systemet.
3. Komponentdesign
   Resultatet av fase 3 er et sett med godkjente brukerkrav, som igjen blir den primære inngangen for å designe systemkomponentene.
4. Implementering
   I denne fasen implementerer, tester og installerer utviklerne det nye systemet.
5. Vedlikehold
   Over tid vil brukerne finne feil og problemer, og de vil utvikle nye krav. I denne fasen startes prosessen på nytt, og feil vil bli utrettet.
4. Drøft hver av følgende utfordringer ifm. systemutvikling:
1. Kravspesifikasjon. Hvordan, hva gjøres…
   Dette er den viktigste fasen i systemutviklingen.
1. Systemanalytikere intervjuer brukerne, og tar vare på resultatene av intervjuene.
2. Evaluering av eksisterende systemer gjøres.
3. Bestemmelse av nye websider/skjema/rapporter.
4. Identifisere den nye applikasjonens funksjoner
5. Vurdere sikkerhet
6. Lage en datamodell
7. Vurdere alle de fem komponentene i et IS
2. Endringer i behov og ønsker
   Dette er den siste fasen, er viktig for funksjonaliteten på systemet.
1. Fiksing av systemet slik at det fungerer som planlagt
2. Tilpasse systemet til endringer i behov og ønsker/krav.
1. Registrere ønsker om forandring:
1. Feil i systemet
2. Eventuelle forbedringer
2. Prioritere ønskene basert på viktighet
3. Reparere disse feilene:
1. Patching av systemet (Kritiske problemer som trenger fiks så fort som mulig)
2. Service packs (Samling av mange lavt prioriterte problemer som skal fikses)
3. Ny utgivelse
3. Endring i teknologi, rammebetingelser
   Teknologi er stadig i utvikling, og blant annet blir hardware stadig bedre og kraftigere. I tillegg kan hardware, i likhet med software, komme med tekniske problemer. Dermed må man ta hensyn til at utbedringer eller endringer også må gjøres på flere områder enn bare krav fra brukerne. Software kan også være et problem, for eksempel må systemet være fungerende med ulike nettlesere, operativsystemer m.m. Mange opplever kompabilitetsproblemer med systemer/programmer ved f.eks. overgang til en ny versjon av Windows (fra f.eks. XP til Windows 8). Teknologi kan være så mangt, blant annet: Hardware, software, systemer (operativsystemer osv.)
4. Planlegging og gjennomføring; økonomi;
   Ledelsen for prosjektet forsøker å sette opp en tidsgrense og plan for budsjett, men disse er bare omtrentlige vurderinger av hva det kan koste og hvor lang tid det kan ta. I større prosjekter som går over flere år og koster flere millioner/milliarder, vil det være så godt som umulig å lage et godt budsjett og tidsplan for utførsel. At disse antagelsene sjeldent er riktige, vil ofte medføre større kostnader enn forventet, og at prosjektet varer lengre enn det som er planlagt.
5. Hvordan håndtere “diseconomics of scale” i prosjekter?
   Dette kan håndteres ved å eliminere overtid, slik at man ikke betaler økt timelønn for de ansatte. Vi kan også tilpasse arbeidsmengden på flere personer slik at hver person får mindre oppgaver, og dette kan resultere i at prosjektet blir ferdig tidligere. Det er bedre å beregne hvor mange ansatte man trenger fra starten av, enn å ansette flere senere. Å ansatte nye mennesker langt inn i prosessen vil føre til Brooks’ Law, som sier at “Adding more people to a late project makes the project later.”
5. Hvilke faktorer vil avgjøre om et tenkt informasjonssystem skal utvikles eller skrotes. Se “Feasibility”.
   For å finne avgjørende faktorer for dette, må man vurdere “Feasibility” (Gjennomførbarhet). Under feasibility har man ulike kategorier:
1. Cost feasibility, som sier noe om omtrentlige kostnader og sammenligner det med systemets verdi.
2. Schedule feasibility, som sier noe om en tidsplan for prosjektet.
3. Technical feasibility, som refererer til om eksisterende informasjonteknologi kan møte kravene til det nye systemet.
4. Organizational feasibility, som dreier seg om hvorvidt det nye systemet passer innenfor organisasjonens skikker, kultur og juridiske krav.
1. Hvordan si noe om kost, nytte, tidsbruk, organisasjonsmessige konsekvenser av et TENKT system?
   Ved å bruke de ulike vurderingene av gjennomførbarhet i listen over.
6. Forklar fordeler og utfordringer med å utvikle en prototype?
1. Fordeler ved å utvikle en prototype er blant annet:
1. Gir direkte erfaring
2. Brukere av prototypen vil vurdere brukbarhet og kommer på egenskaper og funksjoner de har glemt å nevne.
3. Prototyper gir data som man kan bruke til å estimere både utviklings- og driftskostnader.
2. Utfordringer ved å utvikle en prototype er blant annet:
1. Dyrt å lage prototyper
2. Vanskelig å lage en fungerende prototype
3. Må ofte lages i begynnelsen av prosjektarbeidet, ofte før man har fått finansieringen. Å lage en prototyper er kostbart, og det sies derfor at: “We need the prototype to get the funds, and we need the funds to get the prototype”.
7. Hvordan gå fra kravspec til et system som kan testes?
1. Plattform/HW
2. Funksjonalitet?
3. Data?
8. Forklar hva som skjer ved implementering av et IS.
   Ved implementering av et IS skjer følgende:
1. Bygge systemets komponenter
2. Gjennomføre enhetstesting
3. Integrere komponenter
4. Gjennomføre integrert test
5. Konvertere til det nye systemet
9. Hvordan testes et IS?
   Når utviklerne har satt opp og testet alle komponentene, integrerer de de individuelle komponentene og tester systemet. Utviklerne må deretter designe og utvikle testplaner og lagre resultatene av testene. En testplan består av sekvenser med handlinger som brukere vil gjøre når de bruker det nye systemet. Disse planene inkluderer både vanlige handlinger som brukerne gjør, i tillegg til feil-handlinger.
1. Hvilke ulike typer tester har vi?
   
1. Product Quality Assurance (PQA)
2. Beta testing
10. Quality Assurance QA (Kvalitetssikring) er aktiviteter for å sikre kvalitet. Hvilke QA aktiviteter kjenner du til, eller hva kan du tenke deg til bidrar til kvalitet ifm Systemutvikling?
    Product Quality Assurance, gjøres som regel av PQA personale, som er spesialister på testing. Det som gjøres er at disse personene tester systemet, og overvåker brukernes test-aktivitet. PQA vurderer:
1. Safe environment
2. Supportive environment
3. Interaction
4. Engagement
5. Youth-centered policies and practices
6. High expectations for youth and staff
7. Access
11. Innføring kan gjøres på flere måter, drøft fordeler og ulemper ved hver av dem. Alt på en gang, pilot,  parallell, stegvis….
1. Alt på en gang:
1. Ulemper: Hvis det nye systemet feiler, fører det til store problemer. Systemet er da ubrukelig til det enten har blitt fikset eller det gamle blir reinstallert.
2. Fordeler: Rask og effektiv måte å bytte ut systemet på.
2. Pilot:
1. Ulemper: Ulikt system innad i samme bedrift kan føre til inkonsistent data, vanskelig for en bruker å gå fra den ene avdelingen til en annen.
2. Fordeler: Hvis det nye systemet feiler, er skadeomfanget begrenset til kun en del av systemet.
3. Parallell:
1. Ulemper: Veldig kostbart, fordi begge systemer kjører samtidig. Brukerne må gjøre alle handlinger to ganger; en gang på hvert av systemene. Den dyreste måten for installasjon, samtidig som den er den tregeste måten.
2. Fordeler: Kan sees på som en forsikring. Gjør det lett å gå tilbake til det gamle systemet hvis det nye skulle feile.
4. Stegvis:
1. Ulemper: Vanskelig/umulig i mange tilfeller, ettersom så mange systemer er så tett integrerte.
2. Fordeler: Trygg måte å teste på, og gjør det lettere å finne eventuelle problemer.
12. Drøft fordeler og utfordringer med Fossefallmodellen.
13. Estimering; ulike tilnærminger;
1. Jobbe til timene er oppbrukt, da er vi ferdige.
2. Jobbe fram til deadline, levere (kjenner dere til denne)
3. Finne ressursbehov for hver komponent som skal utvikles.
14. Hvordan balansere Funksjonalitet (scope), kostnad, tid, kvalitet?
15. Hva menes med “divide and conquer” ifm prosjektgjennomføring?
16. Hva er, og hva er hensikten med Work Breakdown Structure *(WBS)?
17. Hva er blitt tatt opp som svakheter med Waterfall, som løses vha en mer agil tilnærming til SU.
18. Hva kjennetegner agil tilnærming til SU?
19. Scrum er en blant mange agile metoder, hva kjennetegner denne?
20. Hva er brukerhistorier i Scrum?
21. Hva er planning-poker?
22. Hva er backlogg?

Uke 42 // Strategier og Konkurransekraft

1. Hvordan vil en organisasjons strategi påvirke krav til bedriftens informasjonssystemer?
   Først må bedriften undersøke strukturen på deres industri, og dermed utvikle en konkurransedyktig strategi. Denne strategien bestemmer verdikjedene, som igjen bestemmer forretningsprosessene. Disse forretningsprosessene bestemmer kravene og funksjonene for informasjonssystemet.
2. Drøft forholdet mellom verdikjede / forretningsprosess / IS
   Verdikjeden blir bestemt av den strategien som bedriften har bestemt seg for, som igjen bestemmer hvilken forretningsprosess de skal forholde seg til. Denne forretningsprosessen bestemmer kravene for informasjonssystemet.
3. Drøft gangen fra Visjon; Mål; Strategi; Tiltak;
   Bedriften må først utarbeide hvilken visjonen de har for bedriften. Denne prosessen går videre til hvilke mål de har, som skal nås ved bruk av en strategi som de må bestemme. Til slutt gjøres et tiltak basert på strategien for å nå bedriftens mål.
4. Forklar med ett eksempel en IT-investering som er strategisk.

5. Hva kan bidra til Ustrategiske IT investeringer?
   Ved bruk av for store ressurser i utviklingen av IT, kan dette ansees som en ustrategisk investering. Dette fordi man ofte overinvesterer i IT i form av at man investerer i mer funksjonalitet og kraft i disse systemene enn det man egentlig har og vil få bruk for. I tillegg er slike investeringer lette å kopiere for konkurrentene, og vil derfor ikke være en varig fordel for bedriften.