Celistvý pohled na kvalitu podle způsobu realizace dodávek softwaru

V rámci snahy o efektivní řízení kvality se obvykle pokoušíme vyvážit vynaložené úsilí a prostředky vůči dostupnému času, rozsahu požadované funkčnosti a kvalitě provedení – jinak řečeno požadavku na míru bezchybného provozu dodaného softwaru.

V případě izolovaného systému je ještě relativně snadné většinu z těchto proměnných kvantifikovat a řídit. Celá problematika se ale začne rychle komplikovat v případě integrace více systémů. A opravdu zajímavým se toto téma stane, chceme-li se podívat na řízení kvality softwaru skrze celou organizaci.

Účelnost především

Teleologie (z řeckého „telos“ – tedy cíl nebo účel) je filozofickým směrem z dob Aristotela. Zabývá se zkoumáním účelnosti, tedy zaměřenosti k cíli, za použití principů logiky. A právě teleologie nám nabízí velmi elegantní způsob, jak na problematiku kvality nahlížet řekněme i z byznysového pohledu, a tedy bez nutnosti zabíhat do detailu či naopak příliš zjednodušovat. Prostě řečeno, z pohledu teleologie je každá věc tak dobrá, nakolik plní svůj účel.Na první pohled triviální definice nám umožňuje redukovat komplexitu a rozlišit důležité od méně podstatného.

Takže i každá organizace je natolik kvalitní, tak dobrá, nakolik plní svůj účel (vizi, misi). A totéž lze říci o jednotlivých odděleních, business doménách a IT systémech, které naplnění účelu organizace umožňují či podporují.

Opačná úvaha, ve smyslu narušení schopnosti organizace či její části naplňovat svůj účel, nám pak pomůže identifikovat rámcový objem prostředků, které bychom měli vynakládat na předcházení těmto událostem – jak jednorázově, tak i průběžně či opakovaně. Prostě se musíme ptát: „Co se stane (a kolik nás to bude stát), nebude-li daný systém pracovat správně nebo dokonce fungovat přestane?“

Přečtěte si také:

Co by měl CIO vědět na začátku kariéry?

Ale aby to nebylo tak jednoduché, jsme navíc nuceni vzít v potaz skutečnost, že vše prochází neustálými změnami. Systémy, organizace i struktury v ní se mění v závislosti na nových příležitostech či potřebách. Každá taková změna, je-li řízena, by měla zahrnovat definici očekávaného benefitu, či, z pohledu teleologie, také definici svého účelu.

Dvojí přístup k řízení kvality softwaru

Pro názornější představu se podívejme na dimenzi kvality při typické dodávce softwaru a dva přístupy k jejímu pojetí. Kvalitou v tomto případě rozumíme naplnění očekávaného benefitu, tedy účelu této dodávky jakožto jednotky změny.

Obecně vzato, se k dodávkám softwarových řešení přistupuje odlišně už v závislosti na režimu fungování organizace samotné, tedy jak dodávky plánuje a jakým způsobem je realizuje. V tradičním prostředí a kaskádovém (vodopádovém) režimu, budeme předem fixovat rozsah funkčnosti systému a během realizace se budeme snažit kontrolovat čas a náklady. Kvalita pak bývá ověřována v samostatném kroku dodávky, obvykle až po analýze a vývoji či implementaci celé dodávky softwaru, ale ještě před jeho nasazením do provozu.

Pozitivem takového přístupu je nákladově efektivní průběh fáze ověření kvality. Častým negativním důsledkem je ale omezený prostor na úpravy či zdokonalení, s ohledem na dodržení plánovaného termínu dokončení, ale také na fakt, že testování je až předposlední fází v rámci SDLC (Software Delivery Life Cycle), tedy obecného způsobu dodávky softwaru.

A právě z uvedeného plyne, že důraz bývá kladen spíše na uživatelské a manuální testování než na automatizaci, protože se nepředpokládá časté opakování testů. Navíc máme z důvodu blížícího se termínu uvedení do provozu omezený čas na úpravy a doladění. To vše se ale bude později negativně projevovat v produkčním provozu softwaru. 

Přečtěte si také:

Koučování IT profesionálů pro vedoucí role

V případě jakýchkoliv zásahů či požadavků na úpravy softwaru budeme nuceni řešit regresní testy, tedy ověřovat, že jsme s úpravou nezavlekli do daného systému chybu nebo nezpůsobili nějaký nežádoucí či neočekávaný dopad provedené změny. To s sebou nese další náklady na lidskou práci, delší dobu potřebnou pro úpravy a v konečném důsledku hlavně menší schopnost a vůli k adopci nových potřeb a změn.

Krok za krokem s větší agilitou

Druhý, tzv. agilní přístup k řízení kvality, se liší už od samého základu. Jak je vidět z přiložené ilustrace, ve více agilně nastavené organizaci budeme naopak předem fixovat čas a náklady na každou iteraci (krok, cyklus dodávky) a obvykle i jejich počet. V průběhu realizace se pak budeme v jednotlivých iteracích snažit o definici a vytvoření konkrétní části funkčnosti softwaru, včetně okamžitého ověření její kvality. 

S každou iterací pak budeme mít možnost ujistit se, že se přibližujeme k naplnění očekávaného benefitu a účelu dodávky. Hned v další iteraci máme možnost korekce, doplnění, či změny, což v konečném důsledku vede k dodávkám softwaru s vyšší přidanou hodnotou, a tedy i s větší výslednou kvalitou z pohledu teleologie.

SDLC je v tomto režimu nahrazován zavedením DevOps, zjednodušeně řečeno procesu, kdy software v rámci každé iterace vzniká od návrhu až k nasazení do produkce. Zásadním prvkem je zde automatizace, a to zejména v oblasti sestavení, nasazení do provozního prostředí a ověřování kvality. Ta je ověřována průběžně, zejména prostřednictvím automatizovaných nástrojů a testů, jako součást každé iterace a často i každého sestavení.

Pokud tedy chápeme kvalitu dodávky softwaru jako míru schopnosti systému či jeho komponent plnit svůj účel, budeme ji vždy snadněji a spolehlivěji dosahovat formou agilní dodávky. To s sebou nese i postupnou harmonizaci samotné struktury organizace s tímto způsobem řízení, což již dnes můžeme vidět zejména u produktově orientovaných firem.

Autor je Head of Market Segment, Capgemini Česká republika