<- Tillbaks

Systemutvecklingsmetodik

Innehållsförteckning

Kravanalys, -specifikation och -hantering

Kravanalys

Alla utvecklingsprocesser utgår från en analys och beskrivning av det system som skall utvecklas. En briställig kravanalys kan leda till dålig slutresultat. Inledande kraven formuleras ofta av personer som saknar tillräckligt tekniskt kunnande, och/eller en tillräckligt god uppfattning om vad som egentligen behövs. Kravbeskrivningar kan göras på olika nivåer, för olika målgrupper. De enskilda kraven kan vara av olika typ. Varje krav måste vara spårbar.

Identifikation av krav

Identifiera de olika intressenterna / stakeholders och identifiera krav sett från olika synvinklar / viewpoints. Intervjuer med kunden och övriga intressenter, fördefinierade frågor, improviserade diskussioner. Ethnography: Observation av användarna i deras dagliga arbete. Analys av olika scenarier för ett visst krav. Vad händer i normalfallet, vad händer när nogot går fel. Kan dokumenteras som text och/eller diagram.

Viewpoints

Olika intressenter har olika perspektiv på systemet. Interactor viewpoints: Direkta användare av systemet. Indirect viewpoints: Intressenter som inte använder systemet personligen men vars intressen påverkar systemets krav. Domain viewpoints: Karaktäristika och begränsningar som upptår som en följd av omgivningen systemet befinner sig i.

Krav ur kundperspektiv

Kunden har normala krav, förväntade krav och sensationella krav. Man utalar bara normala. Om det uppfylls normala krav är det bra och om man uppfyller sensationella krav är det väldigt bra. Om man inte uppgyller normala eller förväntade är det dåligt.

Kravhantering (requirements management)

För stora system förändras kraven ständigt. I praktiken omöjligt att specificera ett system hel och hållet. När slutanvändaren/beställaren får nya versioner av systemet kommer nya behov att upptäckas (Change requests).

Riktighetsanalys -> Om det är giltig problem -> Följdanalys -> Möjligt att göra? -> Implementera förändingen. Annars man gör inte en change request.

Olika typer av krav

Funktionella krav beskriver, vilka tjänster ett system skall tillhandahålla? Hur systemet skall fungera i olika situationer? Hur det skall reagera på olika indata? Vilken utdata som skall produceras?

Icke-funktionella krav är begränsningar, constraints, som måste tas i beaktande då systemet konstrueras. Berör ofta systemet i sin helhet. Icke-funktionella krav kan delas upp i olika kategorier: Produktkrav (Product requirements): pålitlighet, användarvänlighet, prestanda, resursbehov, flexibilitet. Organisationskrav (Organizational requirements): Typ av utvecklingsprocess, leveranskrav, standarder.

Exempel på funktionella krav

Exempel på icke-funktionella krav

Exempel pålitlighet(reliability):

Mätbarhet av icke-funktonella egenskaper

Icke-funktonella krav kan vara svåra att kontrollera och definera exakt. Pålitlighet (reliability), prestanda, användarsvänlighet kan mätas, åtminstone efter att systemet är färdigställt. Mean time between failures, Availability percentage, Frames per second, Enkäter för användare, tidsåtgång för utbilding. Begrepp om “safety” och “security” svårare att mäta, omöjligt att granska varje kryphål.

Diffust krav:

“The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized”

Mätbar krav:

“Medical staff should be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use.”

Mätbarhet av icke-funktinella krav

FURPS+

En annan variant av kravkategorisering:

Hög abstraktionsnivå: Användarkrav / user stories

Kortattade beskrivningar. Beskriver vad systemet skall göra, eller vem som skall använda systemet och hur (=user stories). Bör undvika att gå in på tekniska detaljer. Kan använda ett standardiserat format eller vara fritt formulerade. Kan ha en priotitering, t.ex. must-have, should-have, nice-to-have.

Låg abstraktionsnivå: Systemkrav / use cases

Mera detaljerade och exakta beskrivningar av systemets funktionalitet. Delar upp högnivåkrav i mindre delar. Kan beskriva på olika sätt. Fria formuleringar. Användning av dokumentmallar, templates. Använding av grafiska notationer. Användarfallsdiagram kan ses som innehållsförteckning över systemkrav.

Användadarkrav vs systemkrav

Exempel på användarkrav

Exempel på systemkrav

Objektorientering

Klasser och objekt

I en procedurell design är byggstenarna funktioner och variabler ab olika datatyper. I en objektorienterad design är byggstenar klasser och objekt. En klass är en datatyp som kan innehålla både data och funktioner. Ett objekt är en variabel vars datatyp är en klass. Ett objekt är en instans av en klass. Objekt är föremål som har vissa egenskaper (properties) och beteende (behaviour).

Klasser

En klass är en mall (template) för objekt av en viss typ. Alla instanser av samma klass har samma beteenden. Alla instanser av samma klass har samma egenskaper, men objekten kan ha olika värden på dessa egenskaper.

Objekts tillstånd

Egenskapernas värden bestämmer objektets tillstånd: en radio kan vara påslagen/avstängd, vara inställd på en viss kanal, ha en viss volyminställning. Egenskaper kalls även attribut, medlemsvaraiabler eller fält. Ett beteende kan påverka egenskapernas värde och därigenom objektets tillstånd: En radio kan slås på/stängs av, kanalen kan ändras, volymen kan justeras. Beteende kalls också operationer, medlemsfunktioner eller metoder.

Varför klasser och objekt?

Data och den funktionalitet som behövs för att manipulera data kan samlas i en och samma klass (lägre “coupling”, högre “cohesion”). Datainkapsling - ett objekt kan “skydda” sina egenskaper och endast låta andra objekt läsa eller modifiera dem under ordnade formet. Arv och polymorfism ökar möjligheten att återanvända och skriv effektiv kod.

Från struct till klass

Hur sjiljer sig en struct (i C) från en klass (Javascript eller Java)? En struct innehåller endast data(=egenskaper), ingen funktionalitet(=beteenden). En klass ingåller både data och funktioner som utnyttjar datan.

// Java code for a Race class
class Race {
    double distance; // Ignoring data encapsulation, ‘package private’ access
    int duration;
    
    // Constructor, creates a Race object     
    Race(double distance, int duration) {
        // ‘this’ is a pointer/reference to the current object
        this.duration = duration;     
        this.distance = distance;   
    }
    
    double getSpeed() {
        return this.distance/this.duration*3600;
    }
};

// Create and use an object
Race marathonWR = new Race(42.195, 7269);    
double speed = marathonWR.getSpeed();

Samverkande klasser och objekt

En klass kan ha objekt som attribut. En operation i en klass kan ta emot eller returnera objekt. Kan använda (bland annat) associationer för att visa beroenden mellan klasser i ett klassdiagram, och länkar för att visa motsvande beroenden mellan objekt.

Arbetssätt, utvecklingsprocesser och arbetsmetoder

Processer för mjukvaruutveckling

Software development process: En samling sammanlänkade aktiviteter var slutresultat är en mjukvaruprodukt. Kravanlys, design, implementation, validering ingår i alla processer men deras inbördes förhållanden varierar. En processmodell är en abstrakt representation av en process. En verklig process är en anpassning av en modell.

Iteration vid mjukvaruutveckling

I en iterativ process återkommer samma projektfas flera gånger. I en icke-iterativ process utförs varje projektfas (kravanalys, desing, implementation, testing osv) endas en gång I praktiken är alla processer iterativ. Fel uppdagas och måste korrigeras. Uppdragsgivaren vill göra ändringar i kravspecifikationerna. Men finns olika sätta att hantera iterationerna.

Vattenfallsmodellen

Specifikation, design, implementation och testing följer efter varandra i väl avgränsade projektfaser.

Dokumentationsorienterad: en fas avslutas i refel med att ett eller flera dokument godkänns. I teorin börjar nästa fas när den föregående fasen är avslutad. I praktiken ändå överlappningar. Kostsamt och bescärligt om brister i kravanalys eller design upptäcks sent i utvecklinsprocessen (Oplanerade iterationer).

Inkrementell utveckling

Utveckla systemet stegvis, i inkrement. Varje inkrement / version innehåller en del av den funktionalitet som behövs i den färdiga produkten.

Hur proiritera?

Målsättning: Kunden / användaren kan utvärdera produkten redan efter den första iterationen.

Kravanalys -> Uppdeling av krav i inkrement -> Arkitekturdesign -> Utveckla följande inkrement -> Testa inkrement -> Integrera inkrementet -> Systemtest -> Sista inkrement? (Nej, tillbaks till utveckla följande inkrement) : (Ja, levereras).

Komponentbaserade utveckling

Återanvändning, software reuse. Återanvändning i stor skala ställer speciella krav på utvecklingsprocessen.

Kravanalys -> >nalys av komponenenter -> Modifikation av krav -> Design med återanvändning -> Utveckling och integration -> System test -> Leverans.

Agila metoder

Traditionella utvecklingsmetoder har upptått under utvecklingen av stora, komplexa system. För mindre projekt kan den inbyggda byråkratin i dessa processer bli oproportionerligt stor. Stora och tröga processer gör det svårt att snabbt anpassa sig till förändrade krav. Som ett alternativ har agial (“Lättrörliga”) metoder utvecklats och i praktiken blivit dominerande inom de flesta typer av mjukvaruutveckling.

http://agilemanifesto.org/

Kundcentrerade - kunden deltar i utvecklingsarbetet genom att ge feedback och prioritera krav. Utnyttjar iterativa metoder - mjukvaran utvecklas i inkrement. “People not process” - gruppmedlemmarna skall inte bindas till et visst arbetssätt. Kommunikationen mellan gruppmedlemmar viktig. Kontinuerlig förbättring och kommunikation. “Embrace change” - Acceptera att dina planer kommer att förändras. “Maintain simplicty” - Undvik komplexitet.

Extreme Programming (XP)

Test-driven development - skriv test först, koden sedan. Ett inkrement accepteras om alla gamla test, och de nya som skrevs just för detta inkrement är ok. Pair programming - En dator, minst två programmerare. Refactoring - Kontinuerlig förbättring av existerande kod. Kontinuerlig integration, mycket små inkrement. Kravspecifikation genom User Stories som bryts ner till mindre tasks. “Designing for change is wasted effort”.

SCRUM

Fokuserar på projektplanering. Produktens krav är uppställda i en product backlog. Görs av projektets Product Owner - ofta kunden/uppdragsivaren. Arbetet delas upp i sprints. I början av varje sprint överförs de viktigaste produktkraven till en sprint backlog. Under sprinten utvecklas dessa krav av ett SCRUM team. Korta dagliga “stand-up” möten. Sprint demo och sprint retrospective efter en sprint. Ingen traditionell projektledare; en SCRUM master sköter byråkratin, kundkontakter och “underröker hinder” (removes impediments).

http://commons.wikimedia.org/wiki/File:Scrum_process.svg

Kanban

Ursprung i tillverkningsindustrin: lean manufacturing (Toyota). Inga fasta tidsramar, sprints (kontinuerligt flöde). Fokus på flow efficiency - kontinuerlig förbättring. Inga fasta roller. Kanban boards för att visualisera flödet. Work-In-Process limits.

Kravanalys och agila metoder

XP: User stories -> tasks SCRUM: Project backlog -> sprint backlog -> task Kanban: Epics -> User stories Agiala metoder definerar i sig inte hur krav dokumenteras. “Just imple enoug, but not too simple”. Dokumentation är ett krav i sig.

https://agilemodeling.com/essays/agileDocumentationBestPractices.htm

Exempel på kravanalys inom en gail process

Agila metoder och hållbarhet

“Social hållbar arbetsätt” den åttonde principen i den agila manifestet: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Upprätthålla ett agil arbetssätt: “Sustainable agility” och “Sustainable agile transformation”.

https://www.infoq.com/articles/agile-manifesto-sustainability/

Diagram

UML-verktyg (Unified Modeling Language)

Användarfallsdiagram

Kravspecifikation och systemdesign i textform kan göras exakt och uttömmande, men kan bli komplex och svårförståelig. Diagram utnyttjar symboler och abstraktioner för att beskriva krav och funktionalitet.

Användarfallsdiagram / Use case diagrams

Kan ses som en innehållsförteckning för en kravspecifikation. Visar de operationer som en yttre användare (actor) kan utföra. Primär användare: Den huvudsakliga användaren. Sekundära användare: Andra Användare som deverkar till att utföra kravet. Primär och sekundär användare kan indikeras med pilar.

alt text

Yttre användare kan vara människor eller andra system. En fysisk användare kan gestalta olika actors (användaren har olika roller). Användarfall kan ha inbördes relationer, include, extend, inherit.

alt text

Relationer mellan användarfall

A utökar/extends B: I vissa fall kommer funktionaliteten i A att utföras som en del av B. Används för att visa alternativ programflöden, undantagssituationer, etc.

A inkluderar/includes B: B kommer alltid att utföras då A utförs. Används främst då funktionaliteten i B återanvänds i flera olika användarfall.

“If in doubt, leave it out”

alt text

Oklara relationer

alt text

Klassdiagram

Man kan utnyttja klassdiagram för att illustrera en högnivådesign. Låt komponenterna/delsystemen motsvara klasser. Visa olika komponenter som kommunicerar med varandra genom associationer. Visa komponenterna funktionalitet som operationer. Visa vilken data komponenterna innehåller genom attribut.

alt text

Grafisk representation av klasser

Klassdiagram används för att visa olika klasser och dess inbörde förhållanden. Objektdiagram kan används för att visa objekt.

alt text

Sambandet mellan klassdiagram och sekvensdiagram

Ett sekvensdiagram visar interaktionen mellan objekten i ett system. Varje objekt är en instans av en klass.

Visar komponenter som ingår i ett system och hur dessa samverkar.

alt text

Sekvensdiagram

Visar komponenter som ingår i ett system och hur dessa samverkar. Ett krav/användarfall kan innehålla flera alternativa händelseförlopp/scenarion, normalfallet och undantagsfall / felsituationer. Ett sekvensdiagram beskriver i regel händelseförloppet för ett scenario. Ett sekvensdiagram visar interaktionen mellan “objekt”. Vi kan här tolka ett objekt som antingen en komponent eller en användare. En användare kan visas som en actor.

alt text

Komponenterna skickar meddelande till varandra. Streckade pilar är returvärden. Hur visa “returvärden” till en mänsklig användare? Genom en pil från komponenten till användaren. Eller genom ett meddelande till UI-komponenten. Visa felmeddelandek Visa resultat, Uppdatera kärm osv. De lodrätta vita strecken visar när ett objekt/en funktion är aktiv

Happy case

alt text

DNS lookup fails

alt text

Page not found

alt text

Tillståndsmaskin (state machines)

Beskriver hur ett system reagerar på olika händelser. Antar att systemet alltid befinner sig i ett visst tillsånd (state), och att en viss händelse (event) kan få den att ändra tillsånd. Tar inte ställning till systemets inre struktur. Bra sätt att resonera kring funktionaliteten, “Vad händer om denna händelse inträffar då systemet befinner sig i detta tillstånd?”.

Actions och guards

old machine

En kund matar in ett mynt och väljer därefter den önskade varan. Automaten har två tillstånd: “Idle” - kunden har inte matat in pengar. “Money inserted” - kunden har matat in pengar. Obs; Idle-tillståndet regerar inte på händelsen “Product selected”.

actoins och guards

Internal actions

Entry: Någon som utförs då tillståndet aktiveras. Do: Något som utförs aktivt medan vi är inne i tillsåndet. Exit: Någon som utförs innan vi går över till ett annat tillstånd.

alt text

alt text

Händelser som hanteras inne i ett tillstånd utan att byta tillstånd. Aktiverar alltås inte entry- eller exit-aktiviteter.

alt text

alt text

Choise state

alt text

Start state

alt text

Arkitekturdesign

“Make thins as simple as possible, but no simpler” Cohesion: Ett mått på hur specialiserad en komponent är på en viss uppgift. Coupling: Ett mått på i vilken utsträckning en komponent är beroende av andra moduler. Hög cohesion och låg coupling innebär att endast ett fåtal komponenter behöver ändras om funktionaliteten förändras.

Vad innebär arkitekturdesign? “Högnivådesign” Indeling i delsystem (subsystems) Definiera kommunikationen mellan delsystem, Lokala delsystem? Distribuerade delsystem? System av system?

Klient och server

Distribuerade system

Minimal klient-serverarkitektur: två fysiska nivåer. Men den logiska designen har i regel minst tre nivåer: Användargränssnitt (presentation, view), Applikationslogik (controller, business logic), Datahantering (data management, data access, model).

Thin-client & fat-client

Layers / lager

Varje nivå använder tjänster (=en API, Application Programming Interface) från den underliggande nivån, och erbjuder tjänster (=en annan API) till den ovanliggande nivån (Mellanliggande nivåer är både klienter och servrar). En strikt uppdelining i lager ofta svår att genomföra i praktiken, tjänster i under lager kan behövas av många ovanliggande lager (Typisk kompromiss).

https://appinventiv.com/blog/mobile-app-architecture/

APIs för webbapplikationer

RESTful web services. Representational State Transfer, “Statless” Frågor: URLs (Uniform Resource Locator) Svar: Typsikt JSON eller XML.

GraphQL. Frågor: “Query strings” Svar: JSON

XML

<?xml version="1.0" encoding="ISO-8859-1"?>
<quoutes>
   <stock>  
      <ticker>AAPL</ticker>  
      <buy>191.73</buy>  
      <sell>192.23</sell>
   </stock>
   <stock>
      <ticker>GOOG</ticker>
      <buy>154.84</buy>
      <sell>154.90</sell>
   </stock>
</quoutes>

JSON

{"quotes": 
   [
      { "ticker": "APPL", 
        "buy": 191.73, 
        "sell": 192.23 
      }, 
      { "ticker": "GOOG", 
        "buy": 154.84, 
        "sell": 154.90 
      }
   ] 
}

GraphQL query

{
   quotes(filter: {buy: {between: { min: 100, max: 200} } }) 
   { 
       ticker
       buy
       sell
   }
}

Microservices

“Loosely coupled services”, “Polyglot technologies”, “Lightweight protocols”. Monolithic architecture vs Microservice architecture.

Molntjänster

Implementationshjälpmedel

Coding conventions / standards

Regler och standarder för hur kod skall skrivas. Lättare att underhålla, lättare för andra att förstå (högre kodkvalitet). Olika ursprung som gnu, google, CERT

http://www.gnu.org/prep/standards/

https://google.github.io/styleguide/

https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard

Kodanalys

“Statisk kodanalys” - analys som inte kör programmet. Kan generera en lång lista med varningar där en del kanske kan ignoreras, men du måste kunna motivera varför.

Emulatorer och simulatorer CASE-verktyg (Computer Aided Software Engineering)

Inte alltid praktiskt möjligt att utveckla program i samma hårdvarumiljö som det skall användas i. Kan emulera eller simulera den riktiga miljön på vanlig PC. Mjukvaruutvecklingen behöver inte vänta tills nyutvecklad hårdvara finns tillgänglig. Standargårdvara är billig. Kan ge bättre möjligheter att debugga programmet.

Emulering vs simulering

En emulator efterliknar både mjuk och hårdvara. Samma binärfil kan köras antingen på den äkta hårdvaran (native environment) eller i en emulator. Exempel: Emulator för Android. En simulator efterliknar endast mjukvaran. Källkoden måste kompileras till ex x86-maskinkod för att kunna köras i simulatorn. Exempel: Simulator för IOS.

Opensource metodik

Verifikation och validering

Versionshantering