Kap. 23 – Software Engineering How Information Technology Is Conquering the World: Workplace, Private Life, and Society Professor Kai A. Olsen, Universitetet i Bergen og Høgskolen i Molde

Kai A. Olsen, Tradisjonell systemutvikling Metodene er utviklet over lang tid For å redusere risiko i store prosjekter Nødvendig om utviklingen skjer under fast kontrakt

Kai A. Olsen, CMM – Capability Maturity Model SEI, Software Engineering Institute i Pittsburgh bruker dette for å definere nivået på softewareutvikling.

Kai A. Olsen, Nivåer av softwareutvikling: Initial: Udisiplinerte prosesser, individer bestemmer hvordan ting skal gjøres og hvilke teknikker som skal brukes Repeatable level: Grunnleggende prosesser for budsjettering og planlegging av utviklingsprosesser er beskrevet og kan repeteres Defined level: Dokumentasjon, standardisering Managed level: Kvalitetskontroll Optimizing level: Kontinuerlig prosess for forbedring, objektive målinger

Kai A. Olsen, Passer for hvem Mest anvendelig for store softwarehus, som utvikler etter rigide spesifikasjoner Har mange prosjekter Ofte store prosjekter Mange prosjektdeltagere Formalisering er nødvendig for å få oversikt og kontroll

Kai A. Olsen, Problemer med modellen Mange softwareutviklere bruker en ad hoc modell (nivå 1) med stor suksess Eksempler: Microsoft, Google, Facebook, Apple Men dette kan sies å falle innenfor kreativ softwareutvikling, mens “maturity” modellen kanskje er ment for mer rutinepreget virksomhet?

Kai A. Olsen, Protester (2000-) Nye ideer: ”Agile” programming Rapid Prototyping Idé: Kjappere utvikling Utnytte kompetansen til individuelle programmerere Gjøre programmering kreativt og spennende igjen

Kai A. Olsen, Prinsipper for nye metoder

Kai A. Olsen, Kanban Ordet tas fra Toyotas produksjonsplan Istedenfor ”push” benyttes ”pull”, for Toyota blir deler produsert når de trengs, ikke ut fra en overordnet plan For programvare fokuserer metoden på inkrementell og kontinuerlig utvikling

Kai A. Olsen, Scrum Bygger systemet i faser. Starter med et planleggingsmøte, der en bestemmer hva som skal gjøres i neste fase (”sprints”). En ”sprint” kan vare i en eller flere uker. Oppgavene defineres ut fra en liste av systemkrav Stadig gjennomganger for å se hva som mangler. Metoden håndterer endringer i krav underveis i prosessen.

Kai A. Olsen, App for rørleggere Rørleggerne har spesifisert sine behov Ut fra dette har vi laget en behovsanalyse. Den definer mål, sier litt om hvordan vi ser for oss implementasjonen og viser til grunnleggende prinsipper (skal virke online/offline, «responsive design», REST teknologi…) Denne er diskutert med rørleggerne og de som skal utvikle systemet (et programvarehus i Stavanger) Utvikling i form av Scrum. Vi har faste telefonmøter der vi gjennomgår det som ble gjort i siste sprint og definerer oppgaver for neste sprint. Milepeler der vi møtes i Stavanger for å teste applikasjonen. Spesifikasjonsarbeidet startet våren 2014, implementasjonen starten i november 2014, ferdig system høsten 2015, i drift fra januar 2016.

Kai A. Olsen, Konklusjon Software-utviklere må beherske mange programutviklingsmetoder slik at en kan velge riktig metode for riktig prosjekt (akkurat som snekkeren, han har også en stor verktøykasse) Noen ganger kan standard utviklingsprinsipper brukes, andre ganger kan en ta mer radikale metoder i bruk. Poenget er å gi kunden produkter som er nyttige, på kortest mulig tid til lavest mulig kostnad.