IT1101 Informatikk basisfag, dobbeltime 30/10 Midtsemesterprøve: Mandag 1005 i R1 Prøve får samme struktur som den første (6 poeng HTML etc.) Noen lignende spørsmål og selvsagt noe nytt Generaltips: gjør øving 10 (gamle eksamensoppgaver) I dag: Kapittel 6. Kursorisk pensum: 6.3, "Design Patterns" s. 281-282, 6.5, 6.8. I dag: Systemutvikling Hva er systemutvikling? Faser i utviklingsprosessen Kvalitet på programvare Forskjellig type programvare Modularitet Testing Tradisjonell vs inkrementell utvikling Dokumentasjon Kalles også systemering. Systemutvikling (Software Engineering) hva er det? Utvikling av store datasystemer Mer komplekse enn de primitive maskinprogrammene vi har sett på og de programmene (noen av) dere lager i IT1103 Software engineering is concerned with the theories, methods and tools for developing, managing and evolving software products I. Sommerville Systemutvikling innebærer utfordringer utover det programmeringstekniske! Systemutvikling: utfordringer Hva skal vi lage? Hvilke krav har kunden/brukeren til datasystemet? Kunde trenger ikke være samme person som bruker. Hvordan estimere hvor lang tid det tar å lage datasystemet? Hvordan estimere kostnadene? Hvordan måle fremdriften underveis? Hvordan ta hånd om risiko underveis. Kjenner vi teknologien vi skal bruke? Hvordan virker teknologiene sammen? Systemutvikling: utfordringer (2) Hvordan dele opp prosjektet i håndterbare deler? Hvordan sikre at delene systemet består av er kompatible med hverandre? Systemutvikling = store datasystemer. Flere personer i sving for å lage systemet. Hvordan kommuniserer personene i prosjektet? Hvordan vet vi at systemet vi har laget faktisk gjør det brukeren/kunden ønsket? Hvordan laget vi sikre, pålitelige systemer? På kortest mulig tid og til lavest mulig kostnad? ANALYSE KONSTRUKSJON IMPLEMENTASJON - TESTING Analogi til tradisjonell utvikling Dette er utfordringer man møter også innen andre mer tradisjonelle ingeniørvitenskaper (bygg, olje/gass, maskin, marinteknikk etc.) Eksempel: bygging av en bro Likevel forskjellig Men utvikling av programvare er likevel ganske forskjellig fra tradisjonelle ingeniørvitenskaper. Uhåndgripelighet: Ikke fysiske komponenter Ikke like standardiserte komponenter Ekstreme krav til korrekthet Kvalitet: målbarhet (mangel på metrikker)
Hvorfor er systemutvikling viktig? Det moderne samfunn er avhengig av datasystemer Offentlig administrasjon Trondheim kommune, Skatteetaten Offentlige institusjoner St. Olavs hospital, Posten, militæret Private bedrifter Lagersystem, kunderegister, salgsystem, økonomi og regnskapssystem, kommunikasjonssystem Produksjonsindustri Produksjonssystemer Privat Tegneprogram, musikkprogram, chatteprogram etc. Systemutvikling: Arbeidet (prosessen) med å lage disse datasystemene. Men: systemutvikling er vanskelig Feil i programvare har ført til mange ulykker og nesten-ulykker NASAs Mars Climate Orbiter - værsatelitt (1999) Et utviklingsteam brukte engelske måleenheter (fot, tommer) mens et annet brukte det metriske målesystem (meter). Men: systemutvikling er vanskelig forts. Ariane 5 (1996, 7.5 milliarder $) Eksploderte etter 40 sekunder. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed. Men: systemutvikling er vanskelig forts. Norge: overskridelser 1990: Rikstrygdeverkets datasystem, TRESS-90 ble ikke ferdig til planlagt tid. Fem år senere ble prosjektet stoppet. Anslått tap 1.2 milliarder kr. 1995: Statens Vegvesen taper 152 millioner på utvikling av et datasystem som viser seg å være ubrukelig. 1995: NSB taper 200 millioner på et nytt billettsalgsystem som ikke fungerete Ca. 50% av alle systemutviklingsprosjekter er IT1101 Informatikk basisfag høsten forskinket 2003 Kvalitet på programvare Hva er det viktigste av alt? Jo: at datasystemet løser kundens problem Programvare kan sies å ha høy kvalitet hvis det løser en kundes problem Hva er da kritisk? Løse riktig problem Løse problemet riktig Kvalitetssikring Kvalitetssikring av programvare vil innebære følgende aspekter Validering Sjekke at kravene reflekterer kundens behov (ingen misforståelser) Løse riktig problem Verifisering Sjekke at løsningen vi har laget er i overensstemmelse med kravene Løse problemet riktig
Programvares livssyklus Når første versjon av et datasystem er utviklet går systemet inn i en syklus av repeterende bruk og modifisering som fortsetter til programmet forkastes Grunner til at modifisering må gjøres kan være: Feil i programmet (funksjonalitet, kvalitet) Endrede krav (verden forandrer seg ) Store kostander til vedlikehold! Programvare - klassifisering To hovedtyper programvare! Hyllevare Programvare laget for et åpent marked Skreddersydd/spesialbestillt programvare Programvare laget for en bestemt kunde Tradisjonell utvikling Hovedstegene (fasene) i utviklingen Analyse Konstruksjon (Design) Implementasjon Testing Analyse Hva skal systemet (programvaren) gjøre? Hyllevare Markedsundersøkelse: identifisere potensielle kunder Antar hva brukeren (kunden) vil ha Spesialbestillt I samarbeid med kunden beskrive kravene til systemet Analysefasen skal ende opp med en kravspesifikasjon som beskriver hva programmet skal tilfredstille Krav til programvaren Funksjonelle krav: Hva skal programmet utføre/gjøre? Ikke-funksjonelle krav: Hvilke kvaliteter skal programmet inneha? Må på forhånd spesifiseres hvilke kvalitetsattributter man forventer av programvaren Aktuelle kvalitetskrav Pålitelighet Sannsynligheten for at et program vil kjøre feilfritt over et gitt tidsrom Ytelse Kapasiteten til systemet. Throughput og responstid. Sikkerhet (eng security safety) Security: Ikke uautorisert aksess Safety: Ikke skader på omgivelsene
Aktuelle kvalitetskrav forts. Effektivitet Hvor mye ressurser (prosessor, hovedminne) programmet bruker Brukervennlighet Hvor lett er det å sette seg inn i bruken av programmet? Aktuelle kvalitetskrav Flyttbarhet (eng portability) Hvor lett er det å flytte programmet til en annen plattform? Interoperatbilitet I hvilken grad kan programmet kobles sammen med andre programmet? Ofteerdetønskeligåutveklseinformasjon mellom programmer. Aktuelle kvalitetskrav Vedlikeholdbarhet Hvor lett er det å endre programmet feil/utvidelser Gjenbrukbarhet I hvilken grad programmet (hele eller deler av det) kan gjenbrukes i andre systemer Motstridende kvalitetskrav Ikke alle kvalitetskrav kan oppfylles samtidig Eksempler: Gjenbrukbarhet <-> ytelse Flyttbarhet <-> ytelse Kvalitet koster! Derfor viktig å finne ut hvilke kvalitetskrav som er viktigst slik at disse prioriteres gjennom hele systemutviklingsprosessen Konstruksjon (design) Hvordan skal datasystemet (programvaren) innfri kravene? Deler opp systemet i moduler Hva skal modulene gjøre og hvordan skal de kommunisere med hverandre? Moduler imperativt paradigme: Prosedyrer Moduler objektorientert paradigme: Klasser Modularitet Deler opp systemet i mindre moduler som sammen skal utgjøre systemet Top-down design: Fra en overordnet beskrivelse av systemet til stadig mindre moduler Bottom-up design: Identifiserer først enkeltoppgaver (i form av moduler) og setter deretter disse sammen til et system
Strukturkart Brukes for å beskrive strukturen i systemer implementert i imperative språk Viser hvordan modulene (altså prosedyrene) henger sammen Klassediagrammer For å beskrive strukturen i systemer implementert i objektorienterte språk Viser hvilke objekter systemet består av og hvilke sammenhenger det er mellom dem. Utviklet modelleringsspråk for å beskrive slike systemer UML Unified Modelling Language Kobling Kobling: Sammenheng mellom moduler Moduler vil aldri være helt uavhengige av hverandre De kan sende data seg imellom Da kalles det datakobling De kan overlate kontroll til en annen modul Da kalles det kontrollkobling Implementering Selve skrivingen av koden Algoritmer beskrives vha pseudokode Skrives i programmeringsspråket systemet skal implementeres i C++, Java, Visual Basic Websystem: JSP, ASP, PHP Ønskelig med minst mulig kobling! Testing Har vi lykkes? Hver prosedyre/objekt testes under implementeringen Modultest Modulene må testes sammen Integrasjonstest Testing Vi kan ikke verifisere at et program er uten feil uten å prøve alle mulige måtene man kan kjøre programmet på Hvilke data inn Hvilken rekkefølge brukeren gjør ting i programmet Det er ikke mulig å teste alle mulige scenarioer Man har utviklet testmetodologier for å finne så mange feil som mulig Glass-box testing Pareto prinsippet Basis path testing Black-box testing
Pareto prinsippet Feil er som regel samlet i noen få moduler Ved å identifisere disse (komplekse/vanskelige) modulene kan disse testes mer inngående enn de andre Det er mer lønnsomt å teste disse veldig nøye enn å teste alle modulene like inngående Vilfredo Pareto: 80-20 regelen Basis path testing Kan som sagt ikke teste alle mulige stier (ulike forløp) gjennom programmet Basis path testing: Sikrer seg at alle instruksjonene kjøres minst en gang Basis path testing forts. Tester ikke alle stiene i programmet, sikrer at alle instruksjonene blir testet Black box testing Testeren vet ingenting om programmets oppbygning (interne struktur) Brukertester Boundary testing Sjekk hva som skjer ved yttergrensene for lovlige input Beta testing Flere måter å tilnærme seg disse fasene Vannfallsmodellen Hver fase skal være avsluttet før neste fase påbegynnes Milepæler Når milepæl er nådd (en fase er ferdig) kan man ikke gå tilbake Svakheter ved vannfallsmetoden Kunden vet ikke alltid hva han vil ha Vanskelig å formulere alle krav på forhånd Kundens behov ikke statiske Løser foreldete problemer
Alternative metoder Inkrementell systemutvikling Bygger først en forenklet versjon av systemet Forbedrer denne etterhvert Legger til funksjonalitet Gjør forandringer ut fra tilbakemeldinger Alternative metoder Throwaway prototyping Enkle versjoner av programmet bygges raskt og forkastes når de har gjort sin nytte Demonstrasjonsformål (salg) Identifisere endelige krav Trend siste årene: Utvikling med åpen kildekode Noen ser et behov for et program og lager en første versjon Kildekode gjøres tilgjengelig Andre tar i bruk og forbedrer programmet Mange er med å utvikle programmet Linux ble i startfasen utvikler på denne måten, ved at Linus Torvald la ut kildekode til et operativsystem han jobbet med. Systemdokumentasjon Hvordan systemet er strukturert (kildekode og modeller) Kommentarer i kildekode er en del av systemdokumentasjonen Til bruk for utviklerene (spesielt de som skal vedlikeholde systemet) Dilemma mellom å programmere og å dokumentere Problem: utdaterte modeller? Brukerdokumentasjon Forklarer funksjonene i programmet, og hvordan man bruker dem Lite teknisk Bokform eller hjelpepakker i selve programmet Oppsummering I dag: Systemutvikling Neste torsdag: Kapittel 7 om Hva er systemutvikling? datastrukturer Faser i utviklingsprosessen Kvalitet på programvare Forskjellig type programvare Modularitet Testing Tradisjonell vs inkrementell utvikling Dokumentasjon