Föreläsning 4: Konfigurationer, Plattformar & Design I Programvaruutveckling - Metodik 2016 Jonas Wisbrant

Transkript

1 Föreläsning 4: Konfigurationer, Plattformar & Design I Programvaruutveckling - Metodik 2016 Jonas Wisbrant 1 Snabbrepris: Test Testning kan påvisa fel, men inte bevisa att det inte finns fel Testprocessen kopplar samman integration med testning: enhetstest, integrationstest, systemtest, acceptanstest Testmetoder kan vara antingen black box eller white box Dokumentgranskning är en testform där man kritiskt läser ett dokument på ett systematiskt sätt. Verifiering Validering Dynamisk testning Statisk testning Enhetstest Integrationstest Systemtest Acceptanstest Testfall Kravtäckningsmatris Black-box-test White-box-test Ekvivalensklass-partitionering Gränsvärdestestning Parvis testning Stresstest Kodtäckning Bransch coverage Testprotokoll Felrapport

2 Färdigtestat? När vi gjort vad vi lovat i projekt- och testplan: t ex visat att alla kraven på alla abstraktionsnivåer är uppfyllda:...traverserat alla grenar i koden......med alla upptänkliga kombinationer av variabler......på alla plattformar......med max+ belastning Kursinformation Nyligen: Levererat L3: Krav + projektplan och granskningar Pratat och testat Test Skissat på testplan + testspecifikation på systemnivå På gång: Nu: Kl 1: Snart: Föreläsning 4 FB3 = Grankningsprotokoll i rätt gdrive-mapp Muntlig komplettering FB - enligt ÖK med PHL Onsdag-torsdag Ö4a-b: Kodgranskning + dubbelworkshop för testfall för UC1: Cykel Garage Måndag nästa vecka: F5 + L4: Krav1.0 och Plan 1.0 = Baseline MS1

3 Vad händer med L3: Muntlig återkoppling + ΔL3-L4 för Krav följs upp av annan projektgrupp PHL kopierar L3 som PDF FB3 = Granskningsprotokoll. Beslut: Go/redo Muntlig komplettering FB3 per grupp PHL kopierar L3 + PHL-protokoll + L4 till QAmapp Peer QA Signera av åtgärdslista i QA-mapp Bokat tid för muntlig återkoppling Omarbete Meta QA PHL gör extra koll OBS! v 1.1 Vad händer med L5: Granska annan grupps testplan/specifikation PHL kopierar Test 1.0 till QA-mapp OBS! v 1.1 Peer Granskning av Test ==> Granskningsprotokoll till QA-mapp Meta QA PHL gör extra koll

4 Agenda F4-F6 F4 Konfigurations- och versionshantering står inte så tydligt i boken regler för projektet finns i projektmaterialet på kurswebben Plattformar & produktlinjer står inte så tydligt i boken (kort i måna av tid) Programvarudesign 1 Programvarudesign 2 Efterläsning programmering vid F5 Praktisk testning - fokus white-box F6 Utvecklingsprocesser Konfigurationer och versioner Programvaruutveckling - Metodik 2016 Jonas Wisbrant 8

5 Diskussion - försök förklara för din granne: Vad är det för skillnad mellan: Konfiguration Version Variant? Hur håller vi isär pågående versioner från frysta? Konfigurationshantering Testprotokoll Utb.plan Design Process Test Projektplan Manualer Krav Kod

6 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 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.

7 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)

8 Versioner, releaser och delta V 1.0 release Versi V 1.1 version V 1.2 version V 1.3 version V 2.0 V1.1 Delta 1 release V 2.1 V1.0 V1.2 Delta 2 version Lagra ändringar i delta Hålla reda på ändringshistoria ID för varianter/grenar V1.1a V1.0 V1.1 V1.1.1 V1.2 V2.0 V1.1b Ä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 } } Delta?

9 Formulär för ändringshantering, del av information Del 1 Namn Projekt Ändring nr Anledning Objekt att ändra Del 3 Förslag på ändring Skattad tid CCB-möte, datum CCB beslut Del 2 Utredare Resultat av utredning Del 4 Ansvarig för ändring Kommentar Ny version: CCB Change Control Board 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

10 Systembygge 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) Tekniska, praktiska och politiska versioner? Teknisk version varje gång man sparar händer ofta med automatik möjliggör ibland roll-back Praktisk version när man jobbar på olika håll ofta vid samarbete (distribuerat?) men inget som kräver beslut Politisk version när man ändrar nummer: Låser historiken Underlag för beslut Beskriver förändringar Kopplar ihop olika dokument Möjliggör ordnad förgrening

11 Ändringshantering av i ert projekt Baserat på: Efter baseline dvs efter att milstolpe uppnåtts Ansvariga för dokument som bestämmer vem som får ändra vad Uppdatering av versionsnummer Spridande av information inom gruppen Speciella regler för kravspecifikationen (efter baseline får man inte ändra utan att ansöka hos projekthandledaren) 1. Kort version av vår process: 2. Person A finds out that there is something wrong in a document Person A locates the fault in the document (currently in version 1.0) Person A notifies the person responsible for the document (person B) and asks for permission to change it Person B gives person A permission to change the document Person A updates the document, updates the version number to 1.1 and gives it to person B. Person B is now responsible for telling all persons that are working with the document or depend on it, that there is a new version Versionshistoria i dokument och ändringsformulär Ladda ner, skriv mail eller imlementa i driven enligt ÖK med PHL

12 Alltså: Projektens versionsnummer för kravspecifikation blir t ex 0.0 första version inom projektet 0.x nya versioner efter arbete med dokumentet 0.99version inlämnad till projekthandledare 1.0 Dokument för godkänd milstolpe MEN, stryk de som är äldre än ny version efter att projekthandledare godkänt ändring Konfigurationshantering - sammanfattning Ändringshantering görs för rätt beslut ska tas baserat på beslut ska tas baserat på både tekniska frågor ochatt affärsbeslut både tekniska frågor och affärsbeslut ni vill innan v 0.99, men efter det måste ni följa procedurerna i kompendiet. För kravspecifikationen måste änd 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 Plattformar & produktlinjer Programvaruutveckling - Metodik 2016 Jonas Wisbrant 2 5

14 Plattformar inom produktutveckling Inte bara inom programvara: Black & Decker Battery Pack Motor Pack Bilindustri Peugeot, Fiat, Toyota, etc Software product line A software product line is a set of software-intensive 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. Fk1 Fk2 edu/productlines/about_pl.html Fkn Plattform v. k Fk+1.1 Fk+1.2 Plattform v. k+1 Fk+1.m

15 Vad innebär detta? 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 Programvarudesign Programvaruutveckling - Metodik 2016 Jonas Wisbrant 3 0

16 Agenda F4-F6 F4 Konfigurations- och versionshantering står inte så tydligt i boken regler för projektet finns i projektmaterialet på kurswebben Plattformar & produktlinjer står inte så tydligt i boken (kort i måna av tid) Programvarudesign 1 Programvarudesign 2 Efterläsning programmering vid F5 Praktisk testning - fokus white-box F6 Utvecklingsprocesser Programvarudesign - agenda Arkitekturdesign Objektorienterad design Design av användargränssnitt

17 Design Design är både en aktivitet och ett resultat

18 Modell för design av objektorienterad programvara Arkitekturdesign Nedbrytning av systemets övergripande struktur System - helheten Subsystem enhet som ej beror på andra subsystem Moduler enhet som verkar ihop med andra moduler (Komponenter en eller flera klasser) System Subsystem A M A-1 Subsystem B Subsystem C M C-1 M B-1 M C-2 M A-2 M B-2 M B-3 M C-3

19 System-of-sys tems Syfte med arkitekturdesignen Länk mellan kraven och detaljerad design Grov ritning för implementation Kommunicerar designbeslut i organisationen Grund för systemanalys Säkerhet Prestanda Underlättar återanvändning Använda delar i andra system Utveckla produktlinjer

20 Val av arkitekturdesign Förståelse för kontext och intressenter nödvändig för bra beslut Kvalitetskraven avgör ofta beslutet Vad vill vi uppnå? Motsättningar vanligt! Övriga faktorer som kan avgöra Organisationens tekniska kompetens och erfarenhet Återanvändning av tidigare arkitektur Standarder som behöver uppfyllas Prestanda? Kommunikation är en prestandatjuv! Samla tunga beräkningar i moduler som kommunicerar minimalt utåt Acceptera att beräkningsmoduler blir stora System Subsystem A Subsystem B M A-1 M A-2 M A-3 M A-4 M A-5 M A-6 M C-1 M C-2 M C-3

21 Säkerhet? (security) Åtkomstbegränsning viktigt Introducera säkerhet i olika lager Hantera den känsligaste informationen innerst System Subsystem A M A-1 M A-4 M A-2 Subsystem A M A-3 M A-1 M A-2 M A-3 M A-4 M A-5 M A-6 M SECURE Säkerhet? (safety) Att verifiera säkerhetskrav är svårt och dyrt Samla alla säkerhetskritiska operationer i separat subsystem System Subsystem A M A-1 Subsystem B Subsystem C M C-1 M B-1 M C-2 M A-2 M B-2 M B-3 M C-3

22 Tillgänglighet? Minimera risken att systemet är otillgängligt Introducera redundans System Subsystem B1 Subsystem A M B1-1 M A-1 M A-2 M A-3 M A-4 M A-5 M A-6 Subsystem B2 M B Enkelt underhåll/evolution? Fokusera på små oberoende moduler Minimal kommunikation gör det lättare att ersätta moduler i framtiden System Subsystem A Subsystem A M A-1 M A-2 M A-3 M A-4 M A-5 M A-6 44 M A-1 M A-2 M A-3 M A-4 M A-5 M A-6 M A-7 M A-8 M A-9

23 LinkedIn: Java-arkitektur Övning 4a och 4b Samma upplägg som Ö1a-Ö1b kursvecka 2 - Övning 4a på onsdag kl eller Hemarbete 2 h - Övning 4b på torsdag kl eller Sista övningarna - men kod/projekt-jour minst kommande onsdag...