TDDI02 Programmeringsprojekt, Föreläsning 2 Filip Strömbäck Med utgångspunkt i tidigare slides av Jonas Lindgren På denna föreläsning: Dokument - kravspecifikation, projektplan Vad är klok design?
Projektarbete kräver Fördelning av arbete mellan grupper och individer, eventuellt med hänsyn till kompetenser Flitig kommunikation mellan grupper/individer Beroende mellan grupper/individers alster En tidsplan Milstolpar för att avgöra om planen måste ändras Dokumentation, för att Beskriva mål och förlopp för eventuella ersättare Samla erfarenheter Förbättra processen
Projektarbete kräver: Kravspecifikation Se kurshemsidan för information om vad som kan vara intressant att ha med i kravspecifikationen Speciellt viktigt är funktionella krav, i form av: Ska-krav - dessa krav måste implementeras Bör-krav - implementeras i mån av tid Tänk på att projektet examineras utifrån kraven
Projektarbete kräver: Kravspecifikation Exempel: E-butik Man ska kunna sortera produkterna
Projektarbete kräver: Kravspecifikation Exempel: E-butik Man ska kunna sortera produkterna (Dåligt) Användaren ska kunna sortera produkter på pris i både stigande och fallande ordning (Bra)
Projektarbete kräver: Kravspecifikation Exempel: E-butik Man ska kunna sortera produkterna (Dåligt) Användaren ska kunna sortera produkter på pris i både stigande och fallande ordning (Bra) Exempel: Ska: Användaren ska kunna välja att betala med kort Bör: Användaren bör kunna välja att betala med faktura Bör: Användaren bör kunna spara artiklar utanför kundvagnen i sin "önskelista" för senare köp
Projektarbete kräver: Kravspecifikation Ickefunktionella krav: Totala laddningstiden för alla sidor ska vara under 100 ms Hemsidan ska se likadan ut i Internet Explorer 7, Edge, Firefox 42, Chrome 33, och IceWeasel Hemsidan ska använda HTML5 uteslutande Hemsidan ska klara 5000 samtidiga användare på en server
Projektarbete kräver: Projektplan En projektplan ska (åtminstone): Vara nedskriven i förväg Beskriva: Vad som ska uträttas, med vilken metod, men ingen design Vara välskriven, strukturerad, kortfattad och begriplig Ta hänsyn till tänkbara olyckshändelser Levande dokument: utvecklas i takt med projektet
En projektplan kan innehålla Översikt Intro till jobbet, kunden, gruppens organisation Fasplan/Tidsplan - obligatorisk Vilka utvecklingsfaser, vilka produkter, vilka datum? Organisationsplan Vilka team, vems ansvar? Testplan Vem? Hur? Verktyg? Förändringsplan Vad händer om förutsättningar ändras? Dokumentationsplan Vilka, när, till vem? Vem godkänner?
En projektplan kan innehålla Utbildningsplan Intern, extern Vem, när, resurser? Plan för rapportering och granskningar Vad, till vem, när? Installationsplan Vilken procedur krävs för att komma igång? Plan för kvalitetssäkring Standarder som ska användas? Varuplan Vad ska levereras, när? Delleveranser? Resursplan Persontid, datortid Summering av milstolpar!
Rubriker i mer verklig projektplan 1 Revisionshistoria 11 Ändringslogg 12 Relaterade dokument 2 Förutsättningar och bakgrund 21 Syfte 22 Bakgrund 3 Mål 31 Affärsmål 32 Systemmål 33 Kvalitetsmål 4 Omfattning och resultat 41 1 1 Se kurshemsidan
Exempel på milstolpar Fas/Milstolpe Planerat datum Förstudiefasen Förstudiedokument klart 1994-02-05 Förstudiedokument accepterat 1994-02-10 Definitionsfasen Kravspecifikationsdokument klart 1994-02-25 Kontrakt skrivet 1994-02-25 Acceptansvillkor framställda 1994-02-25 Kravspecifikationsdokument accepterat 1994-03-01 Projektplan klar 1994-03-04 Designfasen Designdokument klart 1994-04-15 Programmerarhandbok klar 1994-04-13 Systemtestfall framställda 1994-04-05 Integrationstestfall framställda 1994-04-08
Exempel på riskanalys Miniriskmetoden: Risk Sanno- Konse- Riskvärde Åtgärd likhet kvens Beställare får Ha flera slut på gosedjur 3 5 3 5 = 15 leverantörer Anton tröttnar Hitta på gosedjurshestar 1 6 1 6 = 6 ersättare
Mäta förlopp av implementation Uppfattning om utvecklingsförlopp Svårt att få en bra uppfattning Märkbar investering Olika metoder
Planering: Burn down chart
Planering: GANTT-diagram
Design - Viktiga nyckelord Modularisering Små, överblickbara bitar Modulkvalitet, egenskaper som kännetecknar en bra modul: Inkapsling Abstraktioner Språkoberoende Metodik Hur urskiljer man moduler?
Modul - abstraktionslager Exempel: TCP/IP 7 Application layer 6 Presentation layer 5 Session layer 4 Transport layer 3 Network layer 2 Data link layer 1 Physical layer
Modul Viktigast: överblickbar, förståelig för en person eller ett team Därför ska den: Inte vara för stor (eller komplex) Ha ett väl avgränsat syfte (hög cohesion) Ha få relationer till andra moduler (låg coupling) En modul kan exempelvis vara: En subrutin (eller process) En databeskrivning (utan algoritmer) Ett hopbygge av flera mindre moduler om hög cohesion råder Exempelvis en klass, eller ett paket
Modul - detaljerad design Förslag på modulattribut som måste specificeras 2 : Identifikation, unikt (namn) Typ, ex subsystem, paket, klass, fil, subrutin Syfte, övergripande beskrivning Funktion, relaterat till kravspecifikationen Beståndsdelar, om sådana i sin tur finns Beroenden, relationer till andra komponenter Gränssnitt till andra komponenter, i detalj Externa resurser Utförande, beskrivning av algoritmer, exceptions etc Data, beskrivning och avsikt av interna data 2 IEEE Standard 1016, från van Vliet
OOA/OOD CRC-kort Sälja Öka lagersaldo Ta bort ur lager Vara Kund, lagersaldo, pris Lagersaldo Lagersaldo
OOA/OOD CRC-kort Sälja Öka lagersaldo Ta bort ur lager Sälja Öka lagersaldo Ta bort ur lager Hämta recension Vara Kund, lagersaldo, pris Lagersaldo Lagersaldo Bok Kund, lagersaldo, pris Lagersaldo Lagersaldo ISBN
Utvärdering av språk Vilka möjligheter har man att i språket kunna: Modularisera på ett vettigt sätt Göra egna abstraktioner? Införa information hiding? Skapa oberoende mellan moduler? Skriva läsbar kod? Hur är det med Ortogonaliteten? Typning Få kraftfulla konstruktioner som kan kombineras godtyckligt Gäller blandning av typer, typkontroll, när denna äger rum Utnyttja det som språket tillhandahåller!
Implementation Tänk på: Skriv för folk, inte kompilatorer Programkod ska kunna läsas och förstås i den följd programtexten anger Använd styrstrukturerna på ett systematiskt sätt, en ingång, en utgång