2/25 - text příspěvku - Jan Sokol / VÚMS Praha, 7 s.

řízení_projektování  (! kompletace a údržba velkých IS),  konfigurační_řízení  (! kompletace a distribuce DOS-4), 

... Dále je rozpracován přepis článku, protože obrázek originálu není doistatečně čitelný - ČeV, červen 2021

   Na téma technologie programátorské práce už bylo napsáno mnoho článků, existuje řada víceméně propracovaných metod či technologií a i v Československu se touto problematikou zabývá několik pracovišť. O technologii programování se píší knihy a vyučuje na školách. Nicméně do praxe se výsledky této činnosti zatím neprosadily. Jendím z důvodů je jistě setrvačnost, neochota se učit novým věcem. Domnívám se však, že je tu ještě jeden dosti podstatný důvod věcný. Všechny teoretické práce se zatím týkají pouze technologie programování, případně analýzy problémů, a tedy pokrývají jenom část té problematiky, kterou musí řešit každé pracoviště, produkující a dodávající rozsáhlé programové systémy.

   V následujícím se pokusím

1. vysvětlit povahu a rozsah problémů, které je třeba v této souvislosti řešit
2. stručně popsat konkretní řešení, užívané ve VÚMS při kompletování programového vybavení DOS-4
    a dalších programových celků 

 

1. Kompletování, distribuce a údržba

   Z hlediska našeho tématu lze, domnívám se, úlohy a programové systémy rozdělit do tří velmi hrubých kategorií:

A.  ty, které zvládne jeden člověk, případně několik lidí pod vedením jednoho člověka
B.  ty, které se vhodnou analýzou a organizací práce dají rozdělit na několik částí s vlastností podle A
C.  zbývající, které se takto rozdělit nedají.

   Převážná většina úloh, které se u nás i ve světě na počítačích řeší, a většina programových systémů, které vznikají, patří naštěstí do kategorie A. Práce na takových úlohách má jistě své problémy jako ostatně každá trochu náročnější technická činnost. Vztahy mezi analýzou a programováním, testování, předávání do provozu, reklamace a opravy chyb, rozšiřování a změny funkcí - to všechno jsou obtížné problémy, do nichž se však v tomto příspěvku nechci pouštět. Rozhodující se mi zdá to, že jsou zvládnutelné či přinejmenším přehlédnutelné jedním člověkem. Pravda, ten člověk nemůže být kdokoli, musí mít jisté schopnosti a a vlastnosti, ale je to stále jeden člověk.

   Přednosti a výhody této kategorie úloh jsou dávno známy a před několika lety se dokonce psalo o metodě s trochu honosným názvem "tým vedoucího programátora" /chief programmer's team/. Úspěšný manažer jedné anglické softwarové firmy mi před několika lety řekl, že celá jeho metoda spočívá v tom, pro každou úlohu najít takového člověka, aby ji zvládl sám. Pokud mu na něčem zvlášť záleží, vyplatí se mu najmout takové lidi dva nebo tři a nechat je dělat totéž, aby si nakonec mohl vybrat nejlepší řešení. "Než by se ti tři dohodli, co a jak budou dělat, je každý z nich jednotlivě s prací hotov". Vynikající programátor skutečně udělá práci za deset průměrných, výsledek je často lepší a dřív hotov.

   Bohužel ne všechno, s čím se setkáváme, spadá do této "ideální" kategorie, Buď proto, že úloha je pro ty programátory, které máme, prostě příliš rozsáhlá. Nebo je to "železná kráva", úloha, která se bude udržovat, upravovat a měnit deset let a víc. Nebo vyžaduje součinnost mnoha lidí s různými znalostmi a schopnostmi, a tak dále. I v tomto případě se pokusíme úlohu rozebrat a rozdfělit tak, aby se vešla alespoň do kategorie B našeho předchozího dělení. Problémy s tím, jak celek udržet pohromadě se sice objeví, ale nebudou tak velké. Budou pochopitelně tím větší a vážnější, čím těsnější budou vazby a souvislosti mezi jednotlivými částmi. Nicméně i v tomto případě můžeme kompletování, testování, distribuci a údržbu považovat za část práce řešitelů úlohy, tj. analytiků a programátorů, kteří na úloze pracují.

   Další zlom nastává v okamžiku, kdy jsou splněny následující tři podmínky:

- na úkolu pracují desítky programátorů, případně na místně oddělených pracovištích
- programový systém se musí udržovat a přizpůsobovat potřebám uživatelů mnoho let
- systém se bude provozovat na mnoha místech a v různých podmínkách

   Tím je, domnívám se, naplněna "skutková podstata" kategorie C a řízení projektu je třeba uchopit jiným způsobem.

   Pokud se včas, to jest hned na začátku rozpozná, o jak složitou věc se jedná, je aspoň v zásadě možné využít výsledků teoretických prací, o nichž jsem se zmínil na začátku, zejména metod modulárního programování či "programování ve velkém" /programming in the large/. Metoda byla i u nás několikrát popsána a propagována, z programových produktů, které ji podporují, bych rád uvedl aspoň BPS /VÚSEI-AR Bratislava/ a SNAP /VÚMS Praha/. První z nich, implementovaný na počítačích SMEP, ADT i JSEP, zahrnují i vlastní programovací jazyk, blízký jazyku MODULA-2. Druhý, který je k dispúozici na počítačích JSEP /DOS-4 i OS/ dovoluje programování v různých programovacích jazycích /Assembler, PL/I, Pascal atd./.

   Podaří-li