K managementu kvality softwaru se dlouho přistupovalo spíše jako k inženýrskému oboru.
Díky specifikům softwarových produktů a projektů ve srovnání s jinými obory to však s sebou přinášelo problémy s nízkou kvalitou a neefektivitou softwaru, nesplněním požadavků softwaru, projekty překračovaly rozpočet, harmonogram, nebo dokonce nebyl software nikdy dodán. Vývoj tohoto oboru se od té doby značně posunul, přesto však v roce 2001 přišel pokus o změnu v podobě agilního manifestu a s ním spjatých agilních metodik.
Agilní přístup je založen na vůdcovství, spolupráci, důvěře a respektu, požadavky se postupně upřesňují a realizují v jednotlivých iteracích, formalizace procesů je nízká, uživatelé jsou do procesu vývoje softwaru zapojeni průběžně, jejich požadavky se mohou průběžně měnit před každou iterací, zaměřují se na vývoj kódu a minimalizují dokumentaci.
Kvalitou je v agilním přístupu myšlena zejména kvalita kódu a k jejímu zajištění slouží metody jako refactoring nebo test-driven vývoj a další. Řízení kvality v agilním vývoji je spíše neformální a klade důraz na vytvoření určité kultury, kde se všichni členové týmu cítí
Management
být odpovědní za kvalitu SW produktu a sami podnikají kroky k zajištění kvality. Agilní komunita je v zásadě proti přístupům založeným na standardech a procesech, jako je tomu v předchozích kapitolách. Agilní metodiky zřídka používají formální kontrolní procesy, ve Scrumu se například vývojový tým schází po každé iteraci, aby prodiskutoval otázky kvality, a na základě toho se může rozhodnout třeba pro změnu způsobu práce, aby se zabránilo případným problémům s kvalitou. Právě z téhle strany se vyvinul názor, že vývoj softwaru nikdy nebude inženýrským oborem, jako je například stavebnictví, a proces vývoje nepůjde nalinkovat předem, protože zde lidský faktor hraje naprosto klíčovou roli. Lidé z vývoje softwaru by se dle tohoto pohledu měli zaměřit zejména na získání znalostí v praxi pod vedením někoho zkušenějšího, kdo jim bude dělat mentora či průvodce. Jejich kvalifikace by se pak měla postupně zvyšovat od juniorní pozice až po seniorní, kdy budou taktéž schopní předávat zkušenosti nováčkům. (7; 21; 22)
Inženýrský pohled na vývoj softwaru je však trochu jiný. Lewis Grey (23) prosazuje potřebu standardů v softwarovém inženýrství a poukazuje na to, že je to nutné i z biologického hlediska člověka. Problémy, které mohou během vývoje softwaru nastat a které softwaroví inženýři a vývojáři prožívají, přirovnává k problémům, které s sebou přináší hypoxie a stres, jenž zažívají horolezci na svých cestách do vysokých hor, jako je například Mount Everest.
Silný stres nebo hypoxie zhoršují lidské myšlení, úsudek, schopnost rozeznat rizika, zvážit alternativy a rozhodnout se tak, jako by to udělal, kdyby byl v klidu. Co je navíc horší, lidé, na které působí hypoxie nebo stres, se nejenže nerozhodují dobře a dělají chyby, ale hlavně si tuto skutečnost neuvědomují, což při výstupu na nejvyšší horu světa může vést ke katastrofě. Proto byla v průběhu let stanovena přísná pravidla, kterými se řídí každý, kdo chce tento výstup úspěšně absolvovat, a nezáleží na tom, zda se jedná o zkušené horolezce, průvodce nebo začátečníka. Tato pravidla nahrazují správné rozhodnutí a úsudek, který horolezce čeká například v nejnebezpečnější části výstupu poblíž vrcholu Mount Everestu a jenž je v určitých chvílích kritický. V každodenním životě se s hypoxií zaměstnanec nejspíš nesetká, existuje však podobný zdravotní stav a tím je stres. Stejně jako u hypoxie i při silném stresu člověk často zjednodušuje možnosti řešení problémů na černobílé a poté rychle využije řešení, aby mohl přejít k řešení dalšího problému. Z lidských zkušeností je však dokázané, že tento přístup k rozhodování je špatný. Pro špatné rozhodování pod stresem vznikla jednoduchá řešení – jasná pravidla a seznamy, kterými se například řídí i piloti při přípravě letu nebo potápěči před ponořením do vody. Uvědomují si totiž, že když jsou pod tlakem nebo v rozrušení, člověk zapomíná na věci, na které by běžně nezapomněl, a dělá chyby. Mnoho moderních standardů softwarového inženýrství jako ISO 9000, ISO 12207, CMM a další má sloužit jako seznamy. Motivací pro používání standardů není a neměla by být jen potřeba mít certifikaci. Standardy a další seznamy jsou zde proto, aby se firmy vyhnuly katastrofě. V mnoha moderních standardech je jasně dané, že je nutné jejich přizpůsobení konkrétním potřebám firmy. Moderní procesní standardy taktéž nejsou navrženy tak, aby nahradily profesionální dovednosti nebo několikaleté zkušenosti vývojáře. Piloti rovněž musejí umět létat a kontrolní seznamy před odletem jim neslouží jako náhrada jejich dovedností. Stejně tak vývojáři musí umět programovat a standardy by jim měly sloužit jako „kontrolní seznamy“, které jim pomohou v kritických chvílích. (23)
Klíčové výhody softwarových standardů a procesů:
• Zachycují znalosti přínosné pro společnost. Jsou založeny na znalostech stovek nebo tisíců profesionálů, kteří dali dohromady nejlepší nebo nejvhodnější praxi pro společnosti. Tyto znalosti byly často získány až po velkém množství pokusů a omylů.
Integrace standardu pak může společnosti pomoct vyhnout se předchozím chybám.
(21; 23)
• Poskytují rámec pro definování toho, co pro společnost znamená kvalita. Jak již bylo zmíněno, kvalita softwaru je subjektivní a pomocí standardů je vytvořen základ pro rozhodování, zda bylo požadované úrovně kvality dosaženo. (21)
• Pomáhají přechodu, když je práce prováděná jednou osobou a převzata jinou.
Zajišťují, aby všichni v organizaci uplatňovali stejné postupy. (21)
• Dittrich (24) pak zdůrazňuje, že moderní standardy, metodiky nebo procesy nejsou nepřekročitelné zákony, ale komunikační prostředky, které poskytují společný jazyk pro usnadnění pochopení složitých a nepřehledných aktivit v oblasti vývoje softwaru. (25)
Když lidé tvrdí, že všechny procesní standardy brání vývoji softwaru, prosazují přístup, který oslavuje tzv. hrdiny, kteří se nebojí rizika a procesním standardům se vyhýbají.
Skutečnost je však taková, že čím větší je riziko, tím větší jsou i hrdinové. Společně s tím se však zvětšuje i stres. A právě ve chvílích stresu, kdy jsou standardy a procesy nejvíce potřebné, by se tito hrdinové snažili překonat své vrozené biologické hranice. Je to stejné jako dát horolezce do tzv. zóny smrti na Mount Everestu bez pravidel. Sice budou možná více kreativní než s pravidly, ale budou se muset spoléhat jen na sebe a stres jim znemožní udělat v kritických chvílích ta správná rozhodnutí. Společnosti a projekty potřebují procesní standardy ve chvílích, kdy jsou jejich zaměstnanci nejvíce pod tlakem a mají omezený čas na přemýšlení a rozhodování. Proto je i přes všechna pozitiva velmi nebezpečné nechat tyto hrdinné zaměstnance nechat volně bez pravidel, pokynů, procesů a standardů. (23)
Toto srovnání je důležité zejména proto, že velmi ovlivňuje přístup, který následně člověk a daná společnost volí při managementu kvality softwaru. Jsou situace, kdy je agilní přístup lepší. Například při vývoji jednoduché webové stránky pro malou společnost je nejspíš zbytečné řešit standardy, když se zde hodí aplikovat různé agilní metody a procesy založené na agilních praktikách (například agilní sprinty). Naopak komplexní projekt pro velkou banku zřejmě nebude možné úspěšně dokončit bez jakýchkoliv pravidel a standardů. To ale neznamená, že není možné v takovém projektu na určitých místech aplikovat některé agilní metody. Kontext, ve kterém vývoj softwaru probíhá, je tak zcela zásadní a je nutné se mu přizpůsobit a nezatracovat ani jeden nebo druhý přístup k vývoji. (7)
2 User experience
Pochopení historie user experience je důležité pro pochopení celé této oblasti, proto se tato kapitola na začátku věnuje vývoji a historii UX. Na to navazuje vysvětlení základních pojmů, které jsou s UX neodmyslitelně spojené, což se týká taktéž kreativního přístupu Design Thinking nebo návrhového procesu Double diamond. Následuje analýza vztahu UX nejen s normou ISO 25010, která je důležitá minimálně z inženýrského pohledu na UX, ale také vztah s managementem kvality softwaru tak, jak je popsán v předchozí kapitole.