Precis läst en kurs i programvarutestning och där pratade vi väldigt mycket om kvalité på mjukvara och hur man kan öka kvalitén etc.
tentan jag skrev idag hade 10 frågor och varje fråga i stort sett innehöll ordet "kvalité".

Via kursen så har jag fått flera svar på vad som menas med kvalité på mjukvara och jag undrar nu vad ni anser kvalité är när man pratar om mjukvaror?

En mycket intresant fråga och svaret variera självklart på vem du frågar, vilken roll personen har, en användare och en utvecklare skulle till stor sannolikhet ge olika svar på den frågan, och beroende på vad som är viktigt för dom. Ur en användares perpesktiv så skulle tex kvalitét kunna mästas i form av användarens grad av nöjdhet, ur en systemutveckalares perspektiv skulle det mästas på val av design och arkitektur. Så det är svårt att veta vilken roll jag skulle ta i denna fråga.. men jag svarar nu utifrån en systemutvecklare/arkitekt roll:

Kavlitét på mjukavara för mig handlar om robusta, skalbara system som är lätta att underhålla och uppnår kundens förväntingar och har lång livslängd. För att nå dit så krävs det hög kvalitét redan på specifikation-, design och kodnivå. Kvalitét för mig handlar också om att skriva kod som andra kan läsa och förstå som gör det enklare för andra att underhålla koden. Ett rätt val av design och arkitektur för det givna systemet spelar en stor roll för att uppnå bra kvalitét också.

Jag är väldigt intresead av vad du tycker är kvalitét på mjukvara efter att ha gått en kurs inom det..

Precis som Fredrik skriver så är ju kvalitetn på mjukvara olika ifrån vilket perspektiv man ser det på. Som Användare tycker man att mjukvaran skall fungera utan buggar och uppträda på ett förväntat sätt. Som Beställare (hög chef) ser man mer kvaliten i mjukvaran att den levererar cost-benifit. Att man lyckas räkna hem kostnade för inköpet på något sätt; pengar, kundnöjdhet, effektivitet osv osv...

Jag som utvecklare skulle vilja säga att kvalite för den mjukvara jag utvecklar hamlar precis som Fredrik nämde, robusta, skalbara system som är lätta att underhålla och vidareutveckla. Att de de levererar det användare förväntar sig tycker inte jag har med kvaliten på själva koden, utan mer i kommunikationerna mellan användare och utvecklare, vilket kräver bra metoder för att lösa detta.

Tyvärr så blir det ofta så att jag som utvecklare kan få med mina premiser att koden lämnar högkvalité men användare får ändå inte det som de förväntar sig, och det beror helt enkelt på att man inte fått till en riktigt bra dialog mellan användarna och utvecklarna av olika orsaker. Och jag tror nästan att man måste jobba mer på den biten än på själva koden, för i slutet av dagen så är det ändå användarnas åsikt som väger tyngst (eftersom de sitter med pengarna :) )

- M

"Och jag tror nästan att man måste jobba mer på den biten än på själva koden, för i slutet av dagen så är det ändå användarnas åsikt som väger tungst "

Håller inte riktigt med dig där. Kan vi inte leverera kvalitét på kod, så kommer vi få svårt att leverea en produkt. Förstår vi inte beställren, så kommer vi inte kunna leverera det hon vill ha, borde inte båda spela stor roll!?

Dialog mellan utvecklare och beställare är som du säger väldigt viktig för att kunna leverera det användare förväntas få, de måste prata ett gemensamt språk för att förstå varandra. Eric Evans skriver om detta i sin bok om Domain Driven Design, under Ubiquitous language.

När det gäller kvalitét på kod, så har även den en stor betydelse och kan vara avgörande, därför väldigt vilktig. Uncle Bob skrive i sin bok "Clean Code" att det finns företag som gått under pga att utvecklare inte har skrivit "ren" kod, dålig kod kan leda till kvalitétsbrister så som buggar, svårt att bygga vidare på etc, tillslut blir det en så stor kostnad för företagen att de måste läggas ner.

Så det finns många aspekter som spelar stor roll för att få bra kvalitét, bara för att vi har en fungerande system efter det har lämnat QA så betyder det inte att systemet kommer att fungera bra i den "riktiga världen". Michael T. Nygard, skriver i sin bok "Release IT!" om just detta. Vi lämnar över vårt system till QA, de verifierar att allt fungerar som det ska under sin instängda labbmiljö. Men den miljön är ofta inte den miljö som produkten ska driftsättas i. Så vi kan också säga att bra kvalitét på ett system, ska innebära att den ska fungera i "den riktiga världen".

Gerald Weinberg skriver i sin bok "Quality Software Management: Systems Thinking", att kvalitét har olika betydelse för olika personer vilket innebär att olika personer uppfattar kvalitét på en mjukvara väldigt olika. Han skriver också att de frågor som borde ställas är "Vilka är de människor som vill sätta värde på vår mjukvara" och "Vad är värdefullt för dom?", genom att göra det så får vi det rätta svaret på vad kvalitét på mjukvara är.

Precis vad som skrivits här så är kvaliten sett från vilken roll syn att se på det, jag hittade en bra text som sammanfattade det bra.

För mig som utvecklare så är kvaliten lika med den översta meningen dvs bugfri, möter kraven på applikationen samt underhållbarheten vilket man också kan mäta :)

"Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. However, quality is obviously a subjective term. It will depend on who the 'customer' is and their overall influence in the scheme of things. A wide-angle view of the 'customers' of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organization's management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine columnists, etc. Each type of 'customer' will have their own slant on 'quality' - the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free"

"Håller inte riktigt med dig där. Kan vi inte leverera kvalitét på kod, så kommer vi få svårt att leverea en produkt. Förstår vi inte beställren, så kommer vi inte kunna leverera det hon vill ha, borde inte båda spela stor roll!? "

Man kan leverera produkter utan att det finns kvalitet i koden. Massor med projekt som gör det, där man inte tänkt på vidareutveckling och underhåll, och programmet fungerar som användaren förväntar sig.

Helt klart så är båda viktiga, men användare bryr sig inte ett skit om hur bra vi har kodat vilken utvecklingsmodell vi har använt, användaren vill bara ha en knapp att trycka på. Så det är viktigare att knappen finns där än att vi har kvalite på koden, det utesluter dock inte att vårt arbete blir så mycket lättare om vi har kvalite i koden än utan kvalite. Speciellt om det kommer förändringar till kravspecen i ett senare skede :)

- M