2 Att definiera mjukvara och system

Det här dokumentet diskuterar tekniska system och sociotekniska system. Tekniska system är flexibla i syfte och sammanhang, medan sociotekniska system styrs av sitt sammanhang och syfte. Sociotekniska system tar hänsyn till omgivningen och kan ha specifika användningsområden och restriktioner. De kan också ha emergenta egenskaper och vara icke-deterministiska. Användbarheten av ett system beror inte bara på dess funktionalitet utan också på om det uppfyller användarnas behov och har rätt sammanhang.

Välkommen till den andra delen i avsnittet Introduktion till Software Engineering. Den här delen handlar om hur vi definierar mjukvara och system. Den första delen var en introduktion till själva avsnittet Software Engineering. Den här delen tar oss en bit på vägen till att förstå vad som Software Engineering är och för att göra det så behöver vi definiera: vad är mjukvara och vad är ett system i det här sammanhanget? Om vi skulle titta på en ganska så långrandig definition av mjukvara från Pressman  som han skrev 2015 så skulle man kunna säga att "Software is 1) Instructions (computer programs) that when executed provide  desired features, functions and performance. 2) Data structures that enable the programs  to adequately manipulate information, and 3) descriptive information in both hard copy and virtual forms that describes the operation and use of the programs". Så i den här delen så talar Pressman om det som vi kanske vanligtvis tänker på som mjukvara, det vill säga själva datorprogrammet. Men vi ser också att Pressman tar upp andra saker i det här som går längre och tänker på att vad är data strukturerna? Hur är de här programmen utformade och vad hänger de ihop med för data som finns? Och också vad finns det för data runtomkring de här, eller för information runt om kring de här programmen? Så när vi talar om mjukvara i den här kursen och de här avsnitten så ser vi mjukvara ur ett Software Engineering perspektiv. Och då är det inte bara just själva koden vi tänker på, utan i mjukvara så ingår givetvis den här koden som vi normalt tänker på som mjukvara. Men det är inte det enda. Vi har också dokumentationen runt den här koden. Det kan vara ren dokumentation runt så att säga koden. Vad gör den här funktionen eller metoden i den här koden? Hur fungerar den och hur är den avsedd?  Men också saker som till exempel: vilka är kraven för det här systemet vi har implementerat, hur ser dem ut? Vad ska systemet uppfylla? Vilka tester har vi gjort för det här systemet? Hur ser arkitekturen ut för det här systemet? Sådan information är också någonting vi ser som en del av mjukvaran  även om det inte är kod. Något som också påverkar mjukvara idag är det som vi talar om ibland som bibliotek på olika sätt, det vill säga tredjepartsfunktioner  som vi använder så kod vi inte har skrivit själva, men som är annans kod som vi använder för att få nåt att funka. Det är ganska sällan i dag man skriver mjukvara helt från scratch och skriver all kod själv, utan vi använder olika bibliotek och ramverk för att underlätta och knyta samman och slippa uppfinna hjulet två gånger och skriva det som nån redan har skrivit och paketerat snyggt till exempel. Men det är ju också någonting som ingår i mjukvaran som är en produkt som vi tittar på därför att den används där vi är beroende av den, hur den fungerar och så vidare. Och även hur den är dokumenterad. Och det vi också behöver tänka på tillhör det här är så att säga data och konfigurationsdata. Och med data i det här fallet så är det då datan som finns i systemet. Det kan vara datan i en databas, men det kan också vara sådan data som handlar om bilder som förbättrar ett gränssnitt. Vad är det för "skin" som finns. Det är knappar, bakgrunder och så vidare som förbättrar upplevelsen av en produkt. I spel så har vi kanske lättare att se det här där vi har en massa modeller som används och liknande som också är någonting som hänger ihop med vår mjukvara, som måste finnas där för att mjukvaran ska bete sig på önskvärt sätt. Och sen också det man kan tala om som konfigurationsdata. Dels, vilka versioner finns? Hur har dem förändrats för den här mjukvaran? Men också hur kan den här mjukvaran ställas in och användas på olika sätt? Och den sista delen, som vi inte heller bortser från utan ser som som en del av mjukvara i det här sammanhanget är support. Hur supporteras mjukvaran? Vad finns runtomkring? Kan man rapporterar fel på den här mjukvaran? Samlar den in data om sin användning till exempel? Vad är den kompatibel med och liknande. Så det här är också någonting som vi ser som en del i helheten mjukvara runt det här. Så när vi talar om Software Engineering så är mjukvaran betydligt mer än bara koden till mjukvaran. Det är allt det som finns runtomkring också för att stötta skapandet av mjukvaran och driften av mjukvaran. Och mjukvaran i sig talar vi då om att de här ingår ofta i ett system och då kan man behöva fråga sig: vad är ett system? Och om vi ser ett system, ett enkelt system, som börjar vi med att säga att okej, vi har mjukvara som är en del av vårt system och så har vi hårdvara också för den måste köra på någonting, vår mjukvara. Om vi tittar på mjukvara och hårdvara tillsammans, och säger att vårt system just nu består bara av mjukvara och hårdvara, det är det vi tar hänsyn till, då kallar man det här oftast för ett tekniskt system. Och ett tekniskt system är ett system där syfte och sammanhang är flexibelt. Så ett typiskt tekniskt system skulle kunna vara till exempel ett Officeprogram där vad du använder det här programmet till, syftet och sammanhanget är flexibelt. Du kan använda Word och skriva en skönlitterär bok på flera hundratusen ord om du vill. Du kan använda precis samma program till att skriva ett protokoll för ett möte. Vad du använder ett kalkylblad till till exempel kan ju varierar stort. Du kanske kör statistik över korpenmatcherna i fotbollen du är med. Du kanske använder det här för din privatekonomi. Jag till exempel använder det här för att registrera och hålla koll på resultat och hur det ser ut på kurserna. För att kunna plocka fram statistik under en kursgång och så vidare. Det vill säga vi använder samma program till många olika saker. Och den som skriver det här programmet för ett teknisk system och skapar ett tekniskt system och skriver mjukvaran och vet då kanske delvis vilken hårdvara den kör på eller vad man är kompatibel med. Vet dock inte vad jag kommer att använda det här programmet exakt till. Eller det här systemet beroende på hur stort vi tänker runt det här, utan det kan användas på många olika sätt, så det är ganska allmänt hållet. Det finns ju ingen absolut användare som man vet ska använda det här till precis detta, utan man måste forma det här systemet. Efter en del generella antaganden om vad man tror  skulle kunna vara möjligt med det här. Så det som vi tittar på här är så att säga omgivningen runt det här. Vart det används och hur det används vet vi väldigt lite om för ett tekniskt system. Men om vi då tar med här och säger att okej, omgivningen är nu faktiskt väldigt viktig. Det här systemet ska användas till något väldigt speciellt i en väldigt speciell omgivning. Då börjar man tala om någonting som kallas för socio-tekniska system, där omgivningen och syftet är någonting som styr hur systemet utformas. Ska man ta väldigt speciella programvara så kan det handla om programvara i en operationssal som används för att hålla reda på vilka verktyg och instrument man har använt och hur många gasbindor av den sorten och så vidare, för att räkna det här. Vad händer under det här?  Man för en patientjournal under en operation. Finns i ett väldigt speciellt sammanhang. Väldigt speciellt syfte. Det här är inte ett program du skulle kunna använda för någonting annat. Du kan inte sätta dig och liksom göra något annat än just att hålla reda på de här sakerna under operationen och föra en journal för operationen. Syftet och sammanhanget styr helt. Det här är också förmodligen beroende på vad det är för hårdvara. I vilken omgivning finns det här? Någonting som du ska kunna hantera med handskar på och så vidare? Det ska vara hårdvara som går att göra rent och så vidare. Allting behöver ju inte vara så här extremt. Det kan ju handla om att ha speciellt utformade program för att till exempel hantera andra saker i ett företag som hur hanterar vi till exempel löner och personal. Det här kanske inte är något man gör specifikt för just ett företag, utan det är lite mer allmänt. Men syftet och sammanhanget är löner, löneutbetalningar och så vidare. Det vill säga det här är inget program man  sen sätter sig och gör någonting annat i. Det är inte något jag använder för min privatekonomi eller någonting sådant. Så syftet och sammanhanget styr vad det här systemet gör väldigt hårt, och ibland talar man också då om att helheten blir mer än summan av delarna i sådana här system. Så när vi sätter samman de här sakerna så får de ett nytt syfte, en ny del i det hela. Om så om vi tar ett tekniskt system som är mjukvaran och hårdvaran och sedan lägger till den här omgivningen och förändrar kanske ett befintligt system och gör ändringar så att det blir till ett väldigt specifikt syfte, så får vi någonting mer än de där delarna. Och ibland jämför man det här med metaforen en en cykel att jag har en trampa. Jag har en sadel och styre och hjul och så vidare. Var och en för sig så är dem det här. Men när vi sätter samman dem så får vi någonting mer. Det är först då vi får en cykel. Så ett system vi delar in det här i tekniska system, sociotekniska system. Tekniska system är mjukvara och hårdvara. Medans våra sociotekniska system tar med omgivningen också. I  tekniska system är syfte och sammanhang flexibelt medans i sociotekniska system så låter vi syfte och sammanhang styra systemet. Och tekniska system används i många olika sammanhang. Det går inte att förutsätta exakt vad de används till, medan sociotekniska system är styrda av sitt sammanhang och det är helheten som finns och avhandlar de här delarna är viktig. När vi bygger system så talar man om Systems Engineering och om man skulle tänka Systems Engineering som en större del så är Software Engineering nåt som finns inom det här området Systems Engineering. Så om man tittar på olika lager inom hur fungerar ett system, så har vi allt då från längst ner: utrustningen, hårdvaran, vi kör på, på olika sätt. Vi har någon form av operativsystem kanske. Vi har saker som kommunicerar mellan,  datahantering. Vi har själva applikationer. Sen går vi utanför det här också och säger att det finns processer som styr det här. Vi har affärsprocesser eller hur en organisation fungerar på något sätt som är det här. Hur ser den här organisationen ut? Vad är det för typ av organisation? Och sen finns det också ett lager som kan ses som samhället som vi finns i. Där inget av det här existerar i vakuum. Och Systems Engineering behöver ta hänsyn till nåt väldigt stort i det här. Var är man inne och påverkar direkt och beroende på hur man ser det här så kan man kanske dra den här mer upp mot samhälle om man vill. Software Engineering är trots allt fokuserat på software så att det här går någonstans ned mot  operativsystem. Men vi gör inte hårdvaran. Det här är inte hur vi utvecklar hårdvara bäst utan vi tittar på mjukvara, men den påverkas av hårdvaran. Och på samma sätt så drar vi upp i den andra änden: affärsprocesser och kanske även lite längre upp mot organisation i vissa fall beroende på vad man gör, som påverkar Software Engineering för att det vi gör ska ändå finnas i nån form av "context". Och så har vi också att mjukvara specifikt är inget lager i det här, utan mjukvara kan ju finnas utspritt på många olika ställen i detta. Och i det här också så ser vi att om vi nu ska skapa och ta hänsyn till alla de här delarna så är många olika discipliner involverade. Så om vi talar om Soft Engineering så har vi den närliggande computer science och hur vi optimerar algoritmer som ligger nära. Men vi ser ju också att vi behöver jobba mot till exempel hårdvara, elektronik på olika sätt. Och i andra änden så är det också att vi kommer att hur upplever man någonting, men talar om olika former av design och "user experience" som kommer in här, med interaktionsdesign på olika sätt och även sådant som handlar om hur jobbar man i ett företags processer och organisationsvetenskap påverkar också här. Så det finns många olika delar in i det här när vi bygger upp system och även när vi bara tittar på Software Engineering som vi hela tiden överlappar lite mot och behöver ha en förståelse för ibland.  Hur fungerar de här ämnesområden? Även om man själv inte är specialist på det området. Och när vi talar om sociotekniska system som finns i ett sammanhang så har vi först kärnan, det tekniska system, men sen då lägger vi på det här sammanhanget. Det vill säga: hur används det här? Det som man talar om i den här bilden som "operational processes" . Hur används programvaran? Och de här påverkar varandra. Hur det tekniska systemet är utformat kan påverka hur vi använder det, men också hur vi vill använda, hur en organisation ser ut.  Vad har den för policys och riktlinjer och så vidare, påverkar hur vi vill utforma det tekniska systemet för att de här ska stötta varandra på olika sätt. Och här kommer mer och mer saker in i det här som påverkas, till exempel kultur i en organisation. Vad den här organisationen för övergripande mål och strategier för sina affärsverksamhet, påverkar det här. Och om vi vill hålla oss så att säga och inte få problem i samhället med de lagar och förordningar som finns så är det också någonting som vi faktiskt måste ta hänsyn till.  Att det finns tredjepartsdelar som påverkar våra system. För vad kan man göra och när kan man göra det?  Som kanske går att göra tekniskt, men som man etiskt får fundera på: Är det här något jag vill göra? Jag har suttit i ett projekt där vi gjorde journaler för rehabilitering av  missbrukare och kriminella i samhället. Och det här var ett företag som tidigare hade haft allt på papper och de ville nu ha ett webbaserat system och de var utspridda från Stockholm till Malmö, i princip i verkansområde med många olika personer som var stödpersoner och handledare och så vidare, olika mindre kliniker som man hade avtal med där man gjorde drogtester, bland annat. Och när vi höll på att jobba med det här systemet så liksom vad kunde man göra, och vi höll på att gå igenom vilka behov hade dem. Vad ville de se? Vad ville dem göra? För det var ju mer än bara själva journalföringen Det var också sådant som så att säga vad deras klienter gjorde. Höll dem på med några fritidsintressen? Hur gick det och så vidare. Så det  här var för deras handläggare som stöttade dem i det här också. Så det var inte bara rena sjukjournaler. Och när vi satt och pratade om det här så sa jag att jo, men de vill ju kunna hitta hur man hittar sina klienter Jo, men det sa vi att vi fått ägna mycket tid åt och läsa in oss på för att det här föll ändå under patientjournallagen och sekretesslagen som innehåller ganska strikta restriktioner av vad du får göra. Och då konstaterade man att jo, men du kan ju  söka på ett namn och du kan söka på ett personnummer i det här och så vidare. Och så kan det ploppa upp och vilken träff du fick och så vidare. Man kan också söka på ett organisationsnummer, så ett id i systemet är tillåtet enligt det här. Och så sitter vi och talar om det här och vi har skisser framme. Och då säger dem: men då skulle vi kunna ploppa upp alla klienter som finns i Växjö. Men då fick vi säga att ja, tekniskt sett är det inga som helst problem för oss att skriva en funktion där du kan söka Växjö och få upp en lista på alla klienter i Växjö. Men enligt patient- journallagen så får man faktiskt inte göra det. Då är det bara det här namn, personnummer och ett id i systemet man får använda. Så vi tänker faktiskt inte göra en funktion som innebär att ni kan söka på Växjö. Det enda som man faktiskt har lite frihet att göra i det är är att vi kan ta fram statistik så vi skulle kunna ta fram och göra en funktion som säger hur många klienter finns i Växjö. Men vi får inte lista vilka dem är. Och sådana saker styr då ett sociotekniskt system som har ett väldigt specifikt sammanhang. Där vi säger att: Vi tänker inte bryta mot patientjournallagen och sekretesslagen när vi gör det här systemet, och då styrs faktiskt delar av vad som kan göras i det här systemet av en tredje part. Inte av oss som utvecklare egentligen, inte av vår kund som skulle använda system, utan av en tredjepart i form av lagstiftning. Och när man sen sitter med det här också ska man komma ihåg att vi talar olika språk i det här. Så när vi talar om kultur och vad vet man, så bör man också ta hänsyn till vad man talar med som ska använda ett system vet och förstår om det här, och det kan vara knepigt att se all information som finns. För att vissa saker är självklart och man  kanske inte säger det. Och det här kommer vi återkomma till mer i avsnitt om kravhantering och problematik med att förstå krav och hur man uttrycker sig. Men när vi då tittar på de här sociotekniska  systemen så talar vi ofta om det som kallas "Emergent properties". Och det är tillbaka till den här metaforen med cykeln, att när vi har satt ihop delarna så kan vi helt plötsligt cykla. Vi kan inte göra så mycket med styret i sig själv, med trampan i sig själv, med hjulet i sig själv och ramen och så vidare. Men när vi sätter samman alla delarna så kan vi cykla. Det talar man då om som "Emergent properties". Att när man sätter samman många delar, sätter dem i ett sammanhang. Så får vi ett nytt syfte och ny egenskap som kommer fram. Så till exempel för att ta då det här systemet som var patientjournaler att när vi satte samman saker som handlade om att lagra nåt i en databas, lagra filer, att använda ett webbgränssnitt, så kunde vi helt plötsligt bygga upp någonting som gav ett syfte och ett sammanhang till det här och som blev ett användbart system. Så det här är någonting man talar om när man talar om de sociotekniska systemen med "Emergent properties". Så att det kan finnas delar i det här systemet som i sig själva kanske inte är väldigt användbara, eller som är så generella och så att de blir bara tekniska system. Men när vi sätter samman dem och låter dem jobba tillsammans så får vi någonting mer. Och sen talar vi också om att sociotekniska system är icke-deterministiska. Och om vi tänker efter här,  någonting som är deterministiskt det är någonting vi kan avgöra saker med. Att vi har viss indata och visst indata ger alltid viss utdata, det vill säga viss input ger en viss output och vi kan alltid förutsäga det. Då har vi ett deterministiskt system. Men ett icke- deterministiskt system är ju då någonting när det här inte fungerar på det här sättet, och det innebär att vi har ett system som har så många delar, så många faktorer som påverkar hur det beter sig. Att vi inte alltid kan förutsäga det här. Så vilken indata som ger vilken utdata eller vilken input som ger vilken output. Hur den outputen ser ut kan variera med samma input beroende på tillfälle och tillstånd i systemet och liknande. Så vi kan inte säga på förhand exakt hur de här alltid beter sig. Och det här är ju också en utmaning för att testa och säga vad fungerar och vad fungerar inte i ett system, och det kommer vi också återkomma till när vi tittar i avsnittet Verifiering och validering. Vad kan vi egentligen testa i ett system? Vad kan vi säga om ett system genom att testa på olika sätt? Så här har vi någonting som är viktigt att komma ihåg i de här bitarna att vi har "Emergent properties" som kommer upp och att de här systemen med icke- deterministiska som är en utmaning Och så ska vi också komma ihåg att ett systems användbarhet är inte enbart beroende av systemet i sig själv. Ett system kan göra saker, det kan bete sig precis som som det ska. Men om det här inte var helt rätt system? Och det är inte vad användarna behövde. Så fyller det kanske inget syfte för någonting. Det är inte användbart.  Och här kan man ju säga att du kan skriva en internetbank som fungerar alldeles utmärkt. Du kan ha massor med funktioner som går jättebra att göra och smidigt och praktiskt. Men det har ingen säkerhet och det är nog inte en internetbank vi hade velat använda som har en dålig säkerhet, oavsett hur bra layouten när jag är inne. Hur smidigt det är att se till exempel översikt över konton och transaktioner och liknande eller sådant. Om nästan vem som helst kan logga in. Så användbarheten faller om inte alla delarna finns där som är behov. Det som finns kanske fungerar alldeles utmärkt, men är det inte rätt sak så är systemet som helhet inte någonting som är användbart. Det här var den sista biten i den här delen om vad är ett system och hur ser vi på de här bitarna med mjukvara?