Facit Programvaruteknik DV1/MN1,
20 maj 1999

  1. Ge ett tydligt exempel på
    1. några krav från en kravdefinition, och
    2. några krav från en kravspecifikation
    som visar att relationen mellan dessa är many-to-many.
    Obs. Kraven ska ha de egenskaper som du vet krav bör ha. (6p., 1.5 sida)

    Svar

    Det finns naturligtvis hur många bra exempel som helst. Det viktigaste är att det är tydliga, testbara krav, och att relationen verkligen blir many-many.

    Kravdefinition:

    KD_Ed_1. I systemet ingår en syntaxstyrd editor.

    KD_Ed_1.1. Editorn visar olika syntaktiska objekt genom färgkodning.

    KD_Safe_1. Terminalen elektromagnetiska fält får inte överstiga TCO95 normen.

    Kravspecifikation:

    KS_Term_1. Alla terminaler är av typ ABC2000.
    Rationale: detta är en färgskärm (KD_Ed_1.1) med strålningsskydd (KD_Safe_1).

    KS_Ed_1. Editorn är emacs v. 19.5.
    Rationale: emacs v. 19.5 uppfyller KD_Ed_1 och KD_Ed_1.1.

    3p för tydliga krav, 3p för ett bra many-many exempel.

  2. Beskriv fördelar och nackdelar med processen `evolutionary prototyping'.
    Ge även ett exempel på ett projekt där evolutionary prototyping skulle passa bra, och ett exempel där det skulle passa dåligt. (4p., 1.5 sida)

    Svar

    De viktigaste för och nackdelar är (det finns fler, som kan ge poäng):
    Fördelar: Nackdelar: Obs. Man ska inte blanda ihop evolutionary prototyping med throw-away prototyping och inte heller med inkrementell utveckling (där man ändrar så lite som möjligt, och bara tillägger).

    Exempel:
    bra: ett intelligent hjälpsystem till ett verktyg, som försöker gissa vad användaren vill. (Det är nyttigt från början och kan gradvis bli bättre på att gissa.)
    bra: operativsystem, kompilator (rimligt att gradvis utöka och förbättra funktionalitet)
    dålig: signalsystem på järnväg, etc.

    Obs: ett exempel ska vara konkret. "Ett system som lösar ett välkänt problem" är inte konkret.

    Lite grovt: 1p fördelar, 1p nackdelar, 1p exempel-bra, 1p exempel-dålig.

  3. Vad är det största problemet med verktyg (CASE-tools) som genererar kod från en design? (3p., 0.5 sida)

    Svar

    Reverse-engineering. Någon gång måste man ändra i koden, och då klarar verktyg vanligtvis inte av att anpassa designen.

    Alla andra rimliga svar (stor kod, oläslig kod, etc): 1p.

  4. På vilka sätt ska man underlätta/förbereda för testning under specifikation, design, och kodning? Gör en uppdelning efter olika typer av testning. (8p., 2.5 sidor)

    Svar

    Viktiga punkter (2p): Andra punkter (1p): Obs: här ger jag poäng för vad man skriver, inte för vad man glömmer.

  5. Pålitlighet.
    1. Hur mätar man pålitligheten ROCOF i ett färdigt produkt?
    2. Hur kan man uppskatta blivande pålitligheten i ett produkt innan det är färdigt?
    3. Om uppskattningen pekar på en för låg pålitlighet, hur kan man då öka pålitligheten i produkten?
    4. Varför är det enklare att öka snabbheten i ett pålitligt produkt, än att öka pålitligheten i ett snabbt produkt?
    5. Om uppskattningen pekar på en för låg pålitlighet, hur kan man då ändra processen så att nästa produkt blir pålitligt nog från början?
    (2+3+2+2+2 = 11p., 3 sidor)

    Svar

    1. Statistical testning.
    2. Använd ett internt mått, som tex olika komplexitetsmått, antal pekare-operationer, etc. (2p) som genom ett känt samband (1p) ger en uppskattning.
    3. Det man inte ska göra är att direkt försöka påverka det interna måttet. (Tex. Om kött är grått i stället för rött har det blivit dåligt och det blir inte bättre med ketchup.) Det bästa är att identifiera de delar där måttet ät för högt och se över designen där. Kanske även införa inspections eller helt förbjuda vissa programkonstruktioner.
    4. Trögheten är oftast ett lokalt problem (90% av tiden i 10% av koden), pålitlighetsproblem är mer utspridda. Ett system som är gjort för att vara pålitligt har ofta enkel, snygg kod; ett system som är gjort för att vara snabbt har ofta svårförståeliga optimeringar. Därför är det pålitliga systemet låttare att ändra.
    5. Quality Management, följa standarder, planering, inspections, kanske t.o.m. byta till Cleanroom.

  6. Gäller Brooks' lag och resonemanget i `The Mythical Man-Month' även om projektet använder sig av `Chief programmer teams'? (3p., 1 sida)

    Svar

    Ja. När en försening uppstår kan det vara frestande att tycka att "Brooks' lag gäller inte mig, eftersom ...", men så är det sällan. Det enda undantaget i samband med "Chief programmer teams" är att det går att utöka stödteamet om det är det som är flaskhalsen.

  7. Hur passar Cleanroom metoden in i en projektmodell med stor återanvändning? Vilka delar av Cleanroom-paketet passar in och underlättar återanvändning - vilka delar blir mer problematiska? (6p., 1.5 sida)

    Svar

    Målet blir i ett sådant modell att tillverka återanvändbara komponenter, samt att bygga system med dessa.

    Cleanroom är ett paket med fem delar: Formell specifiering, strukturerad programmering, inspections, statistisk testning, och inkrementell utveckling.

    Formell specifiering och inspections passar in mycket bra: de kan ge certifierade komponenter med en tydlig specifikation. Strukturerad programmering hjälper kanske inte lika mycket, men är inte heller ett hinder.

    Inkrementell utveckling och återanvändning går att förena, men det är inte helt lätt. Inkrementell utveckling är ju i princip en top-down teknik, och återanvändning bottom-up. (Obs: inkrementell utveckling är inte samma sak som att klistra ihop en massa moduler.)

    Statistisk testning av komponenter blir det största problemet, eftersom det är omöjligt att förutse hur en komponent kommer att användas i framtiden. Det går alltså inte att ha en användarprofil.

  8. Många artiklar förespråker mer `ordnade former' inom programvarutekniken.
    1. Varför har dessa tekniker gemensamt att de flytter arbete från senare delar av ett projekt till tidigare delar?
    2. Ange några problem med att flytta arbetet på detta vis.
    (6p., 1.5 sida)

    Svar

    1. Ju senare man upptäcker ett fel, ju dyrare den blir, så om man försöker att förebygga fel eller upptäcka dem tidigt flyttar det arbete till tidigare delar i ett projekt.
      De senare delar av projektet är mest omfattande, så det är där man kan uppnå en vinst.
      Det finns säkert tekniker som inte flyttar arbetet tidigare, men dessa behöver inte så många artiklar för att sälja dem.
    2. Att utföra arbetet tidigare är en investering, och varje investering medför en viss risk att den inte återbetalar sig. Antingen för att hela projektet läggs ner, eller för att metoden inte fungerar så bra som man hade hoppats. (Dessa metoder blir ofta som en religion som kräver ett offer nu för att uppnå någonting bra i framtiden.)

  9. Ovanför entrén till aulan i Universitetshuset står
    Tänka fritt är stort, tänka rätt är större
    Vad är sambandet mellan programvaruteknik idag, denna mening, och vetenskapen i allmänt i 1887, då Universitetshuset blev färdigt? (3p. 1 sida)

    Svar

    Att tänka fritt är att tycka, utan större krav på bevis. Experiment utförs, men utan utvärdering. Man får gärna hävda att Atlantis fanns i Sverige eller att åderlåtning botar alla sjukdom. Eller i programvarutekniken att metod X kommer att bli nästa Silver Bullet.

    Att tänka rätt är att använda vetenskapliga metoder, särskild i utvärdering av experiment. Det krävs i teknisk/industriell sammanhang: det kostar liv att "tänka fritt" när man bygger ånglok, elanläggningar osv.

    Sedan är det frågan vem som bestämmer vad är vetenskapligt, och "rätt". Ibland var det kyrkan som satte gränser (i Holland examineras fortfarande inte evolutionsteorin på gymnasium eftersom det bara är en "teori"), men även teorin om rörliga kontinenter blev utfryst länge. Detsamma gäller kanske idag oviljan i programvarutekniken att ta till sig (bevis som talar för) vissa metoder.