Způsoby spolupráce objednatele a dodavatele na softwarovém projektu

Na jedné straně máme objednatele, který má zájem o vytvoření informačního systému a na druhé straně dodavatele. Jaké jsou běžné způsoby spolupráce? Tyto modely se liší v míře fixace rozsahu, času a ceny, což ovlivňuje rizika, flexibilitu i zapojení obou stran. Volba závisí na definici požadavků, velikosti projektu a tolerance k riziku.

Fix Time, Fix Price (FTFP)

Tento způsob dodávky fixuje čas, cenu a rozsah projektu. Rizika nese dodavatel, odběratel má jistotu, že pokud nebude požadovat změny, musí být dodržen dohodnutý rozpočet. Nevýhodou tohoto způsobu spolupráce je nutnost určení přesného rozsahu projektu. Problémem může být také malá flexibilita, kdy změny znamenající navýšení rozsahu projektu vedou k výraznému navýšení ceny a času a mohou vyžadovat novou smlouvu a/nebo formální schválení. Dodavatel proto často navýší cenu rezervami na neočekávané komplikace, což může vést k nižší kvalitě nebo zjednodušenému řešení.

Time and Material (T&M)

Odběratel platí za skutečně odvedenou práci. Čas a rozsah projektu může být flexibilní. Tento způsob spolupráce lze využít pro agilní projekty, kde se postupně objevují a rozpracovávají požadavky. Rizikem je možnost překročení plánovaného rozpočtu. Odběratel musí aktivně monitorovat průběh, schvalovat sprinty a priorizovat úkoly, což zvyšuje jeho zapojení, ale vede k vyšší kvalitě finálního produktu.

Bodyshop

Dodavatel poskytuje svoje specialisty do týmu objednatele. Objednatel platí za jejich čas předem dohodnutou sazbu. Riziko dodavatele je minimální, odpovědnost je na straně objednatele. Výhodou je možnost rychle najmout další specialisty, pokud to projekt vyžaduje. 

Dedicated Team 

Dodavatel sestaví exkluzivní tým pracující dlouhodobě pouze pro odběratele, s plnou kontrolou nad procesy. Výhodou je hluboké porozumění doméně, stabilita a škálovatelnost.

Hybridní model

Kombinace předchozích způsobů spolupráce. Například dohodnuté klíčové milníky projektu s pevně daným termínem a platba za skutečně odvedenou práci. Tento přístup vyvažuje jistotu FTFP s flexibilitou T&M, ideální pro středně velké projekty s některými známými požadavky a prostorem pro iterace. Smlouvy často obsahují strop rozpočtu nebo bonusy za předčasné dokončení milníků, což podporuje důvěru mezi stranami.

User story, Use case, funkční požadavky, akceptační kritéria, ...

 Nedávno jsem dostal následující otázky:

• Není náhodou user story a use case to samé?
• Má smysl vymýšlet akceptační kritéria, když mám popsané funkční požadavky?
• A není vlastně user story a use case jen rozpracováním funkčního požadavku?

Pojďme si to projít. Funkční požadavek je například: Systém musí umožnit přihlášení uživatele. Specifikuje, co je požadováno. 

Use case pak popisuje, jak uživatel pracuje se systémem. Tj. v daném, případě by hlavní scénář byl:

• Uživatel otevře přihlašovací formulář.
• Uživatel zadá uživatelské jméno a heslo.
• Uživatel klikne na tlačítko „Přihlásit".
• Systém ověří údaje v databázi.
• Systém zobrazí úvodní stránku a přihlásí uživatele.

Alternativní scénáře mohou řešit situaci, kdy uživatel zadá chybné přihlašovací údaje a obnovu hesla.

User story je „Jako registrovaný uživatel se chci přihlásit pomocí jména a hesla, abych získal přístup k mým datům a funkcím systému.".

Akceptační kritéria:

• Úspěšné přihlášení: Po zadání platných údajů se uživatel dostane na úvodní stránku do 2 sekund bez chyb.​
• Neplatné údaje: Systém zobrazí chybovou zprávu „Neplatné jméno nebo heslo" a vrátí formulář, bez odhalení konkrétního údaje.​
• Bezpečnost: Po 3 neúspěšných pokusech se účet zamkne na 5 minut; zadání prázdných polí zobrazí varování.​

Shrňme si to:

• Funkční požadavek říká, co má systém dělat.
• Use case říká, jak uživatel interaguje se systémem.
• User story říká, proč to uživatel potřebuje.
• Akceptační kritéria definují, kdy je funkcionalita hotova.

Stabilita softwarových požadavků

Stabilita softwarových požadavků má zásadní vliv na celý projekt. Pokud jsou požadavky stabilní, jasně pochopené a sdílené všemi aktéry, vývoj probíhá předvídatelně, náklady se drží pod kontrolou a architektura se nemusí neustále ohýbat podle nově se objevujících nápadů.

Nestabilní požadavky mají vždy konkrétní kořenovou příčinu. Jednou z nejčastějších je nedostatečné pochopení toho, kdo je skutečný stakeholder. Mnoho týmů pracuje pouze s jednou skupinou uživatelů, která je nejvíce slyšet, a teprve během vývoje se ukáže, že existují i další skupiny, jejichž potřeby nebyly zachyceny.

Další častou příčinou je příliš rychlý start vývoje. Tlak na rychlé výsledky často vede k tomu, že týmy „skočí rovnou do kódu“, aniž by věnovaly dostatek prostoru analýze a validaci požadavků. Výsledek? Požadavky jsou formulovány vágně, mnohdy i vícevýznamově, a jakmile je implementace vystaví realitě, začne se ukazovat, že každý stakeholder si požadavek vyložil jinak.

Nestabilita také vzniká tehdy, když projekt nemá jasnou a sdílenou produktovou vizi. Pokud neexistuje dokument typu Vision & Scope, dochází k tomu, že každý stakeholder vnáší do projektu vlastní agendu a jednotlivé požadavky nejsou zasazené do širší strategie. Bez této kotvy je jakákoliv specifikace náchylná ke změnám.

Stabilizace požadavků není o vytvoření „betonové specifikace“, kterou už nikdy nelze změnit. Jde o to, aby jakákoliv změna byla předvídatelná, řízená a odůvodněná. V praxi se osvědčilo několik postupů.

Jedním z nejúčinnějších nástrojů je vytvoření kvalitní vize a rámce projektu. V okamžiku, kdy se všichni stakeholdery shodnou na tom, proč systém vzniká, jaké problémy řeší a jaké naopak neřeší, dramaticky klesá množství pozdějších změn. 

Dalším krokem je důsledná validace požadavků s uživateli. V mnoha organizacích stačí, že analytik napíše specifikaci a ta se formálně schválí. Praxe však ukazuje, že skutečné porozumění vzniká až při prototypování, modelování scénářů a aktivní diskuzi. 

Neméně důležité je zavedení baseline – tedy oficiální, verzované sady schválených požadavků. Jakmile je baseline stanovena, každá změna se posuzuje prostřednictvím řízení změn. To neznamená, že se změny zakazují, ale že se u každé změny vyhodnocuje dopad na architekturu, testy, plán a rozpočet. Teprve poté se rozhodne, zda změna skutečně stojí za cenu, kterou její přijetí přináší.

V agilních projektech je situace specifická. Agilní přístup nestaví na tom, že požadavky jsou stabilní dlouhodobě, ale naopak očekává jejich vývoj. Přesto však platí, že požadavky musí být stabilní minimálně v rámci sprintu. V praxi to znamená, že během sprintu nesmí docházet k zásadním reinterpretacím uživatelských příběhů. Pokud se to přesto děje, většinou se ukáže, že produktový owner neměl dostatečně připravený backlog, nebo že stakeholdery nebyli včas zapojeni do rozpracování požadavků.

Nestabilita požadavků nikdy nezmizí sama od sebe. Je potřeba ji aktivně řídit a čelit jejím příčinám. Pokud však tým přijme správné postupy a začne pracovat se stakeholdery profesionálně a strukturovaně, stabilita se stane přirozeným vedlejším efektem dobře řízeného vývojového procesu.

Projekt, kde je téměř vše špatně

Už pár měsíců pracuji na projektu, kde je spousta věcí špatně. Pojďme se na ně podívat:

• Nejasně definovaný rozsah projektu. - jasně vymezený rozsah projektu je základ. Jeho absence vede k postupnému rozšiřování požadavků bez odpovídající kontroly dopadu na čas, rozpočet a kvalitu.
• Neujasněné potřeby a očekávání zákazníka - Zákazník nemá jasnou představu, zda cílem projektu je vytvoření softwarového produktu, konzultace k procesům, nebo návrh zlepšení. 
• Demotivovaný interní analytický tým - nedostatečná motivace vede k poklesu kvality analýzy požadavků.
• Projektový manažer bez technického zázemí - projektový manažer má formální roli, ale chybí mu znalosti vývojového procesu a technických aspektů projektu. Nedostatečná technická kompetence vede k tomu, že řízení projektu je „papírové“ – formálně správné, avšak bez reálného dopadu na kvalitu a efektivitu vývoje.
• Dodavatel se slepě snaží vyhovět všem požadavkům zákazníka, místo aby zastával roli odborného partnera a prosazoval racionální a efektivní řešení.

Doménový model

Doménový model je jeden z modelů, který vzniká v rámci analýzy. Zobrazuje základní entity a vztahy mezi nimi. Jeho cílem je usnadnit pochopení mezi doménovými experty, analytiky a zákazníky.

Pro příklad si vezměme eshop. Tam nalezneme entity jako zákazník, objednávka, produkt. Normální je použít tyto entity. Pokud něco vypadá jako kočka, mňouká to jako kočka, tak je to zřejmě kočka.

Jenže jsem se setkal na projektu s kolegy, kteří chtějí dotáhnout model k dokonalosti. Přemýšlí, jestli je zákazník skutečně zákazník, když si zatím nic nekoupil. Přesto, že má připravenou objednávku, tak to zatím není ještě zákazník. Ono ani objednávka není objednávkou, protože zatím není zaplacená, takže nic objednané vlastně zatím není.

A tak nám vznikají další entity jako registrovaný uživatel a předobjednávka. A řeší se, kdy z registrovaného uživatele vzniká zákazník a kdy se předobjednávka mění na objednávku. Dlouhé diskuse a další entity v doménovém modelu paralyzují analýzu. Na požadavcích není možné pracovat, protože neznáme ani základní entity a nejsme schopni dát dohromady ani názvy user stories. Nevíme, jestli přidáváme zboží do objednávky nebo předobjednávky a jestli to dělá zákazník nebo registrovaný uživatel.

Analýza do šuplíku

Nápad ze strany zákazníka - co udělat analýzu bez vývoje. Nejdřív všechno pěkně zanalyzujeme a pak uvidíme. Budeme mít jasno, kolik MD bude třeba. A můžeme si vybrat mezi více dodavateli vývojové části. Jde to takto udělat, nebo je v tom nějaký háček?

• Analýza morálně zastarává, mění se legislativa, procesy i technologie.
• Bez vývoje se analýza nepropojí s architekturou, designem, testy ani konfigurací.
• Bez návazného vývoje nelze posoudit návratnost ani efektivitu navržených řešení, neexistuje zpětná vazba.
• Uživatelům není co předvést.
• Analytik ztrácí motivaci, protože nevidí výsledek své analýzy.

Autorizace - naprosté základy pro analytika

Cílem autorizace je rozhodnout, zda ověřený subjekt má oprávnění vykonat určitou akci. Tj. například zda si uživatel Petr Novák může prohlédnout obsah určitého dokumentu s id b046c6c5-5d6c-479c-8918-ef4038cc1ac4.

Existují 4 základní modely autorizace:

• Role-Based (RBAC)
• Attribute-Based (ABAC)
• Relationship-Based (ReBAC)
• Policy-Based (PBAC)

Pojďme se na ně podrobněji podívat. Všechny tyto modely řeší kdo co může, ale každý jinak.

Role-Based (RBAC)

Oprávnění se řídí pomocí rolí. Takže Petr Novák si může prohlédnout obsah dokumentu, pokud má roli, která to umožňuje.

Attribute-Based (ABAC)

Oprávnění  se řídí atributy. Takže pokud 

user.id = document.creator_id 

OR document.access_list contains user.id

OR (user.role == "Administrator" AND document.confidential == False)

Relationship-Based (ReBAC)

Přístup se odvozuje ze vztahu mezi uživatelem a objektem. 

relation creator: user

relation viewer: user

permission view = creator + viewer

K danému dokumentu se pak definují vztahy

document:doc123#creator@user:jan.kral

document:doc123#viewer@user:petr.novak

user:jan.kral#role@role:administrator

Policy-Based (PBAC)

Přístup se řídí centrální sadou politik.

Dejme tomu, že budeme používat SpicyDB. Jak se do toho pustit z analytického pohledu? Tady je  kuchařka, jak do toho:

1. Začni Use Case scénáři -  cílem je získat úplný přehled oprávnění z pohledu uživatele.
2. Z Use-casů odvoď entity a vztahy. Cílem je vědět, jaké objekty existují a jaké vztahy mezi nimi bude SpiceDB spravovat.
3. Definuj oprávnění – Permission Matrix Cílem je převést business logiku na formální pravidla.
4.  Namapuj existující role (RBAC → ReBAC)
5. Navrhni SpiceDB schema. To už je práce pro developera.
6. Ověř funkčnost – Testovací scénáře. Tady se zapojí tester.
7. Popiš Governance (správa a změny).
8. Připrav migrační/integrační plán.

Externí analytik

Ve středně velkých firmách, které provozují vlastní informační systémy pro interní potřebu i pro zákazníky, je běžné, že vývoj a údržbu zajišťuje interní tým analytiků, vývojářů a testerů.

V určitých situacích však firma potřebuje realizovat rozsáhlejší projekt, který přesahuje kapacitní nebo odborné možnosti interního týmu. V takovém případě bývá přizvána externí firma – a právě zde často vznikají specifické problémy, zejména v oblasti analýzy.

Klíčoví uživatelé jsou zvyklí spolupracovat s interními analytiky, kteří firmu dobře znají – rozumí jejím procesům, historickým souvislostem i interní terminologii.

Externí analytik naopak tyto znalosti obvykle nemá. Přichází zvenčí, a proto se často ptá na věci, které se uživatelům zdají být naprostou samozřejmostí.

Z jejich pohledu pak může působit, že „neví, o čem mluví“, nebo že analýza postupuje pomalu. To vede k frustraci na obou stranách a někdy i ke ztrátě důvěry ve schopnost externího týmu dodat očekávaný výsledek.

Dopady:

• Ztráta času: opakované vysvětlování základních pojmů a procesů.
• Nedorozumění: rozdílné interpretace pojmů, dokumentů či požadavků.
• Snížená efektivita: analytici tráví více času získáváním kontextu než samotnou analýzou.
• Napětí v komunikaci: uživatelé mohou mít pocit, že musí dělat „analýzu za analytiky“.

Aby spolupráce s externími analytiky probíhala efektivně, je vhodné věnovat pozornost úvodní fázi jejich zapojení:

• Zaškolení do firemního prostředí - Představit strukturu firmy, základní procesy a hlavní informační systémy.
• Oborová a legislativní orientace - Vysvětlit klíčové regulatorní požadavky, které se týkají daného projektu nebo sektoru.
• Terminologický slovník / doménový přehled - Předat srozumitelný přehled používaných pojmů a zkratek.
• Mentor z interního týmu - Určit kontaktní osobu z interních analytiků, která externí tým provede kontextem.
• Kontrolní body kvality analýzy - Zavést pravidelné review výstupů, aby se včas zachytily nejasnosti nebo odchylky.

Velmi rychlý úvod do BMPN

 Potřebujete modelovat obchodní procesy? Pak máte k dispozici:

• Activity diagramy (UML)
• ARIS notaci EPC (Even-Driven Process Chain).
• BPMN

Pojďme se dnes podívat na BPMN. 

Základem jsou aktivity. To je činnost, která se vykonává v obchodním procesu. 

• Může mít více vstupů i výstupů. 
• Může být atomická, nebo složená. 
• V diagramu vypadá jako obdélník se zaoblenými rohy.

Dále v BPMN najdeme konektory (spojující čáry). Ty jsou 3 typů: 

• Sequence flow - definuje pořadí, jak jsou vykonávány aktivity za sebou. Nemůže překročit hranice procesu.
• Message flow - používá se pro komunikaci mezi účastníky procesu.
• Association - vyjadřuje propojení dvou objektů.

Eventy (události) jsou reprezentovány kolečkem a mohou být 3 typů:

• Start event
• Intermediate event
• End event

Start event a End event jsou jasné, ale k čemu je Intermediate event? K modelování výjimek, nebo může například reprezentovat časový limit, příjem/odeslání zprávy, signál nebo podmínku.

Důležitou částí jsou gateways, které větví proces. V základu jsou tyto typy:

• Exkluzivní brána (XOR) – rozhodnutí: jen jedna větev může pokračovat (označena X).
• Paralelní brána (AND) – rozdělení/spojení větví, všechny běží současně (+).
• Inkluzivní brána (OR) – může spustit jednu nebo více větví (O).
• Komplexní brána – složité podmínky.
• Event-based gateway – volba podle události, nikoli podle podmínky.

A poslední věc, se kterou je třeba se seznámit jsou swimlanes (plavecké dráhy). Jsou dvou typů:

• Pool (bazén) – představuje organizaci nebo hlavního účastníka.
• Lane (dráha) – dělí pool na konkrétní role/departamenty.

Mnoho dobrých rad

Chtěl bych se podělit o jednu zkušenost z jednoho právě dokončeného projektu. Na začátku projektu se ho zúčastnil jeden seniorní vývojář. Byl velmi zkušený, měl spoustu dobrých nápadů a to nejen ve vztahu k vývoji, ale i k analýze a testování. Téměř na každé schůzce jsme se dozvěděli, co všechno je špatně a co by bylo třeba dělat lépe. Bylo toho opravdu hodně. Skoro všechno mělo nějakou vadu a všechno by bylo třeba vylepšit, protože to nebylo dokonalé. Důležitou informací je, že projekt byl tou dobou v celkem velkých problémech a práce začala nabírat zpoždění. A ačkoliv byly jeho rady určitě dobře míněny, byl tento kolega poměrně velkým demotivujícím faktorem pro tým, protože nikdo přece nechce pracovat na projektu, kde je úplně všechno špatně.

Moje rada pro tyto situace je soustředit se vždy na ty nejvíce palčivé problémy. Cílem není dosáhnout dokonalosti, cílem je dosáhnout takových podmínek, které umožní úspěšně dokončit projekt a dodat daný systém.

Ulehčení práce

Lidé mají tendenci ulehčovat si práci, i když tím někomu jinému naopak práci zkomplikují. Dnes jsem řešil chybu nahlášenou testerem. A nebyla to jedna chyba, hned tři chyby v jednom ticketu, které tester nalezl v jednom testovacím scénáři. Proč si neulehčit život a nedat tři chyby do jednoho ticketu?

• Každá chyba může mít jiný životní cyklus. Některou budeme řešit hned, jinou třeba zamítneme.
• Řešitel je zvyklý na jednu chybu v jedno ticketu. Netuší, že má očekávat tři chyby. Takže se zaměří na popis první a ostatní dvě mu mohou uniknout.
• Reportování stavu - řešitel vyřeší jednu chybu, na druhé pracuje a třetí se ještě nevěnoval. Pokud to budou tři nezávislé chyby, bude mít každá jiný stav. Víme, že třetina chyb je vyřešených. Pokud to bude jeden ticket, bude mít jen jeden stav (v daném případě něco jako IN PROGRESS).

Ulehčit si práci je super, ale nemělo by to být na úkor jiných.

OpenAPI

Co je to OpenApi a proč by ho měl analytik znát? OpenApi je (překvapivě) specifikace pro popis Api.  Používá JSON nebo YAML a poskytuje standardizovaný způsob, jak definovat endpointy, operace, parametry, odpovědi, autentizaci a další aspekty API. 

Specifikace OpenAPI obsahuje několik klíčových sekcí:

• Info – Základní informace o API (název, verze, popis).
• Servers – Seznam dostupných serverů API.
• Paths – Definice jednotlivých endpointů a jejich operací.
• Components – Znovupoužitelné definice schémat, parametrů a odpovědí.
• Security – Popis mechanismů autentizace a autorizace.

A jak to vlastně vypadá:

openapi: 3.0.0

info:

  title: Správa dokumentů API

  description: API pro správu dokumentů v rámci případů

  version: 1.0.0

servers:

  - url: https://api.example.com/v1

security:

  - bearerAuth: []

paths:

  /cases/{caseId}/documents:

    get:

      summary: Získání seznamu dokumentů pro daný případ

      security:

        - bearerAuth: []

      parameters:

        - name: caseId

          in: path

          required: true

          schema:

            type: string

      responses:

        '200':

          description: Seznam dokumentů

          content:

            application/json:

              schema:

                type: array

                items:

                  $ref: '#/components/schemas/Document'

        '404':

          description: Případ nebyl nalezen

          content:

            application/json:

              schema:

                type: object

                properties:

                  error:

                    type: string

                    example: "Case not found"

components:

  schemas:

    Document:

      type: object

      properties:

        id:

          type: integer

        filename:

          type: string

        created:

          type: string

          format: date-time

        description:

          type: string

        documentOrigin:

          type: string

          enum: [digital, paper]

  securitySchemes:

    bearerAuth:

      type: http

      scheme: bearer

      bearerFormat: JWT

Analytik by se v tom měl minimálně zorientovat a být schopen zkontrolovat, zda má/nemá k dispozici všechny atributy, které jsou třeba.

Příklad nejednoznačně zadaného požadavku

Dnes jsem narazil na pěkný příklad nejednoznačně zadaného požadavku. Zadavatel chtěl průměrný věk zákazníků, kterým banka poskytla úvěr. 

Dejme tomu, že se zákazník narodil 5.1.1982 a banka mu poskytla úvěr 11.11.2024. Jaké číslo započítáte jako věk daného zákazníka?

• číslo 42, protože zákazníkovi bylo 42 let.
• číslo 42,85, protože to je přesný věk zákazníka v letech.

Podle zvolené metody výpočtu se samozřejmě bude lišit celkový výsledek a součástí zadání by tedy měla být specifikace způsobu výpočtu. 

Přesný popis je důležitý nejen pro analytiky

Dnes jsem řešil jednu chybu. Tester ji objevil při testování konkrétního scénáře. Tento scénář testoval zpracování úvěru, který původně vznikl v externí prodejní síti. Při zpracování tohoto úvěru se vyskytla chyba, že nejde uložit upravenou adresu žadatele.

Takže tester založil chybu a napsal: U úvěru z externí prodejní sítě nelze zeditovat adresu žadatele.

Co je na tom špatně?

Předně je třeba ověřit, jestli má  vliv to, že je úvěr z externí prodejní sítě. Výsledek je, že nemá.

Verze 2: Nelze zeditovat adresu žadatele.

Nelze adresu zeditovat? To samozřejmě lze, ale neuloží se.

Verze 3: Nelze uložit adresu žadatele.

Týká se to jen adresy? Co když nebudu editovat adresu, ale cokoliv jiného? 

Verze 4: Nelze uložit údaje žadatele (jméno a příjmení, adresa, kontaktní údaje).

Týká se to jen konkrétní situace, nebo to nastane vždy?

Verze 5: Nelze uložit údaje žadatele (jméno a příjmení, adresa, kontaktní údaje), pokud není vyplněno rodné číslo žadatele.

Přesnost je důležitá. A nejen v analýze.