konfiguration och version och variant?

Transkript

1 Att fundera på medan vi väntar: Vad är det för skillnad mellan konfiguration och version och variant? ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik & Föreläsning 4 Arkitektur, design, kodning Vad betyder: Jonas Wisbrant Agenda Detta har hänt... Pratat krav och plan och test Övning 3: Utformat testfall Fått återkoppling och kanske reviderat krav och plan inför MS1 Haft kursombudsmöte Påbörjat testplan med testspecifikation? Förbereda testrapport? Påbörjat design? Börjat programmera? Kursinformation Arkitektur Design Kodning Produktlinjer Konfigurationshantering - forts 2 3 4

2 Ombudsmöte Kan man förstå software engineering utan att ha upplevt stora programvaruprojekt? Utmaning Långsiktiga utmaningar: Möjlighet till samtidig skrivning i en wiki-sida Möjlighet att ladda ned föreläsningsfilmerna Önskemål inför nästa kursomgång: Mer tidigt stöd för wikin, wiki-lathund och kanske gör-det-själv-labb, ordnad peer-support? Bättre struktur på informationsmaterialet: - Kompendiet ostrukturerat - bättre logisk följd - Övningsfrågorna borde finnas i kompendiet - Bättre beskrivning av hur projektet ska gå till - Wikins templates stämmer inte med projektbeskrivningen (kurswebb) Önskemål på kort sikt: Förtydligande av vad som förväntas av manual/lathund i projektet. Förtydligande av om det är frågan om ett studentprojekt, fiktivt verkligt projekt eller både-och. Finns inget självklart svar. Förtydligande av att man inte kan räkna med föreläsningsfilmerna under hemtentan Eventuellt nytt möte måndag 9/5 kl Kan man förstå vad som händer i stora programvaruprojekt utan att ha studerat software engineering? = barcode reader Operator = electronic lock Barcode printer PC Kravspecifikation = pincode terminal Fas 1 Specifikation Projektplan Testplan Extra exit door Bicycle garage Entry door Fas 2 Design Designdokument Exit door Fas 3 Implementation och enhetstest Fas 4 Systemtest Exekverbar källkod Dokumenterat genomförda systemtest Projekthandledare Projektgrupp QA från IP3 5 6 Hur ska vi gör med manualen / lathund? Önskemål om Versionshistorien Svar: Vet ej! På lämpligt sätt... Kommentera gärna bort länkarna till 0.x-versionerna eller åtminståne till de outnyttjade versionerna ;-) Detta vill vi uppnå: En metod för att bli klokare på hur systemet skall användas Smidigare acceptanstest (kurs-läge) Utnyttja/förstå kopplingen: Likhet: Förlopp Testfall Skillnader: - Inramning - Språkbruk - Kontext 1. Börja 2. Genomför 3. Slutför Användarfall Manual 7 8

3 Kursinformation V 4: Nu: Arkitektur, design, kodning, versioner Ti kl 24: MS 1 eller To Ö: Mer om test: T V 5: Må kl 13 F: Utvecklingsprocesser, vidareutveckling, om tentamen To övning: Om tenta och återkoppling testplan Arkitektur och Design Notera: och i andra kurser -> ingår INTE i denna kurs 9 10 Design Modulär nedbrytning är både en aktivitet Helt system Helt system Helt system M1 M1 M11 M12 och ett resultat M2 M3 M2 M21 M3 arkitektur -> design -> kod är en vettig hierarki

4 men man kan ju även designa bottomup Alltså M1 M11 M12 Hela systemet Top-down Bottom-up Toppom-dup M11 M12 M21 M2 M21 M3 M1 M11 M12 M2 M3 M Koppling Koppling påverkas av I hur stor utsträckning är enheter i programmet kopplade till varandra? Man vill ha låg koppling Antal gränssnitt mellan olika delar Typ av gränssnitt Enkla gränssnitt ger lägre koppling än komplicerade gränssnitt Åtkomst av interna detaljer ger högre koppling än endast anrop av funktioner Kommunikation av endast data ger lägre koppling än kommunikation av kontrollinformation Vid objektorientering komponent-nivå-koppling t ex när en klass har en annan klass som instansvariabel Interaktionskoppling (som gränssnitt ovan) Koppling baserat på ärvning 15 16

5 Samhörighet (Cohesion) Hela systemet M1 M11 M12 Diskutera i grupper om 2-3 personer Hur väl innehållet i en del hänger samman M2 M3 Slumpvis inga meningsfulla beroenden, M21 bara paketerat Logiskt t ex en modul som sköter all utmatning av data Temporal t ex en modul som sköter all uppstart eller avslut Procedurbaserad när procedurer som utförs efter varandra slås ihop, t ex innehållet i en loop Kommunikationsbaserad när delar som behandlar samma data slås ihop Sekvensiell när serier av procedurer som utgör indata till varandra slås samman Funktionell när innehållet står för en enstaka funktion, t ex sortera vektor Varför är det viktigt med låg koppling och hög samhörighet i allmänhet i ert projekt Hur ska man göra för att uppnå detta rent konkret i ett projekt som ert? Hela systemet M1 M11 M12 M2 M21 M Mål med en arkitekturdesign (dokument) Förståelse och kommunikation Möjliggöra återanvändning på hög nivå Stöd för konstruktion och utveckling Underlag för analys Arkitekturdesign, olika vyer Modul-beskrivning t ex programkod med relationer Klass A är beroende av Klass B Komponenter och konnektorer t ex binärer och kopplingar Object A delar data med objekt B Allokeringsbeskrivningar fysisk allokering av systemets komponenter låsreglerna finns i systemet, låstimern finns i dörrposten 19 20

6 Arkitekturer: Exempel Delad data gemensam information repository Klient 1 Klient 2 Klient n Nätverk Delsystem 1 gemensam information repository Client-server -modellen Delad data Delsystem 2 Delsystem n Betj. 1 Abstract-machine modellen / Layered system Betj. 1 Betj. m Pipes and filters Klient 2 Delsystem 2 Delsystem n Fördelar: Svårigheter: Effektivt med mycket data De som producerar data måste inte veta så mycket om mottagaren Backup, etc lätt Alla delsystem använder samma dataform Vidareutveckling kan vara svårt eftersom mycket bygger på en viss datamodell Olika krav på detta Layered system: Exempel OSI - referensarkitektur Client-server -modellen Klient 1 Delsystem 1 Klient n Betj. m Nätverk Betj. 1 Betj. 1 Fördelar: Distribuerad arkitektur Lätt att lägga till klienter och betjänare Svårigheter: Nya enheter måste kanske anpassas Ingen gemensam datamodell 23 24

7 Hur ska man välja arkitektur? Kvalitetskrav påverkar beslutet, t ex: Prestanda (svarstid, genomströmning) Inte för mycket kommunikation, Säkerhet mot intrång (Security) Kritiska funktioner i lägre lager, Säkerhet för användaren (Safety) Operationer i begränsat antal moduler, Tillgänglighet Redundanta komponenter, Underhållbarhet Komponenter som är lätta att förstå för sig själva, låg komplexitet, 25 Utvärdering - Mått på design? Hur avgör man om en design är bra? Några förslag: Graph impurity Informationsflöde = size * (inflow * outflow) 2 Weighted methods per class:... WMC= Inte uppenbart hur man ska mäta detta! n " i=1 c i Hela systemet M1 M11 M12 M2 M21 M3 26 Kodning Kodning Kombineras med enhetstestning Kodningsstandarder kan finnas Kodgranskningar kan utföras 27 28

8 Ett exempel på en kodningsstandard (Java) Varför vill man ha denna typ av standarder? Basic Additional File names File organization Indention (4 characters) Comments Declarations (1/line) Statements (if always with {}) White space (2 lines Naming (semantic Ökad rörlighet Personer kan gå mellan projekt Erfarenheter best practice Trovärdighet between) Naming conventions consistency, understandable abbreviations,) Constant names instead of raw numbers) Every class should have a comment Avoid static variables File size < 200 LOC Vilka problem finns att införa standarder? Vad kan man göra för att komma tillrätta med problemen? Exempel från Xuefen Fang, Using a coding standard to improve program quality Quality Software, Design/arkitektur är även att bestämma ansvar 30 Plattformar Varje modul/klass/etc ska utvecklas av någon Person, avdelning, företag, Även resurser i organisationen kan påverka design/ arkitektur Organisation speglar design (och vice versa?) 31 32

9 Plattformar inom produktutveckling Inte bara inom programvara: Black & Decker Battery Pack Motor Pack Software product line A software product line is a set of softwareintensive systems that share a common, managed set of feature that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. F k1 F k2 F kn productlines/about_pl.html Bilindustri Peugeot, Fiat, Toyota, etc Plattform v. k F k+1.1 F k+1.2 F k+1.m Plattform v. k+1 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F4 33 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F4 34 Vad innebär detta? Er design i projektet Parallell utveckling -> lägre kostnader, fler produkter, kortare tid till marknad per produkt Ökad komplexitet: t ex nya krav och påverkar flera produkter (och plattformar). Mer komplexa projektplaner, testning, organisation Långsiktiga beslut för plattform, kortsiktiga beslut för produkter Nya produkter innehåller funktioner från tidigare produkter -> I stort sett aldrig specifikation från 0. Mycket arv Ingen mall finns Alla klasser ska beskrivas Namn, konstruktorer, publika metoder, ärvning Ange även ansvarig för klasser/metoder Rita grafiskt (klassdiagram) Följ gränssnitt enligt projektbeskrivningen

10 Krav Konfigurationshantering Testpro tokoll Test Kod Design Process Manualer Projektplan Utb.- plan Olika versioner Olika produktvarianter Olika kunder Diskussion: Försök förklara för din granne: Vad är det för skillnad mellan konfiguration och version och variant? & Vad betyder: 37 Configuration Management Configuration Management Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life. Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life

11 Typiska frågor man kan vilja ha svar på Vilka kunder har installerat en viss version av systemet? Vilken hårdvara och OS krävs för en viss version? Vilka versioner har levererats av ett visst system? Vilka versioner påverkas om jag ändrar en viss komponent i systemet? Hur många olika ändringar håller man på att göra av ett visst system? Hur många rapporterade men ännu ej rättade fel finns det i ett system hos en viss kund? Planering av konfigurationhantering Bestäm vad som ska konfigurationshanteras Projektdokument inte säkert Produktdokument ja Organisationsdokument ja, men inte av projektet Bestäm rutiner för konfigurationshantering Bestäm ansvarig för konfigurationshantering Bestäm hur ändringshantering ska gå till Bestäm vilka verktyg för konfigurationshantering som ska användas (och vilken typ av databas man ska använda) Versioner, releaser och delta V 1.0 release V 1.1 version V 1.2 version V 1.3 version V 2.0 release V 2.1 version ID för varianter/grenar V1.1a V1.0 V1.1 V1.1b V1.1.1 V1.2 V2.0 V1.0 V1.1 V1.2 Delta 1 Delta 2 Lagra ändringar i delta Hålla reda på ändringshistoria Delta? Ändringshantering ordnad övergång Begär ändring genom att fylla i formulär Analysera ändringsbegäran Om ändring nödvändig och korrekt {! Utvärdera hur ändring kan göras + kostnad! Skicka förfrågan till CCB! Om ändring accepterad {!! Ändra i systemet!! Uppdatera ändringsbegäran!! tillverka ny version av systemet! } } 43 44

12 Formulär för ändringshantering, del av information CCB Change Control Board Del 1 Namn Projekt Ändring nr Anledning Objekt att ändra Del 2 Utredare Resultat av utredning Del 3 Förslag på ändring Skattad tid CCB-möte, datum CCB beslut Del 4 Ansvarig för ändring Kommentar Ny version: Strategiska beslut om vilka ändringar som ska ske Inte bara tekniska beslut Representerar kund, projekt och andra intressenter För programvara som används i flera produkter blir det mer komplicerat Systembygge Sammanfattning Bygga en fungerande version av hela systemet från de komponenter som finns, t ex Senaste versionerna av allt En viss version av en viss produkt En viss version av en viss produkt till en viss kund En viss version av en viss produkt till en viss plattform Behövs t ex vid systemtest och andra tester (och såklart vid leverans) och i andra kurser -> ingår inte i denna kurs Design görs på olika nivåer: arkitektur -> design -> kodning Man vill ha låg koppling och hög sammanhållning Exempel på vanliga arkitekturer: delad data, client server, layered system, pipes and filters Kvalitetskravkrav påverkar arkitekturen Plattformsbaserad utveckling ger parallellism och kortare tid till marknad, men också ökad komplexitet Ändringshantering görs för att rätt beslut ska tas baserat på både tekniska frågor och affärsbeslut I projektet får ni göra mycket som ni vill innan v 0.99, men efter det måste ni följa procedurerna i kompendiet. För kravspecifikationen måste ändringar efter 1.0 godkännas av projekthandledaren

13 Uppgift: Programmera ett cykelgarage Uppdrag Alltså Faser och leverabler Målmiljö Kravspecifikation = barcode reader Operator = electronic lock Barcode printer PC = pincode terminal Fas 1 Specifikation eller annan ÖK! Projektplan Testplan Fas 2 Design Designdokument Fas 3 Implementation och enhetstest Exit door Fas 4 Systemtest Utvecklingsmiljö To Ö: Mer om test: T.9-11 Extra exit door Bicycle garage Entry door V 4: Ti kl 24: MS 1 eller Aktörer Dokumentmiljö Projekthandledare Projektgrupp QA från IP3 Exekverbar källkod Dokumenterat genomförda systemtest Tips: Titta på en gammal tenta... V 5 inleds med tecknad serie 50