autor: Vlastimil Čevela Mechanizace a automatizace administrativy 2/1975
*) V literatuře bývá uváděn pojem "strukturované programování" dle doslovného překladu z angličtiny, avšak ten přesně vystihuje pouze část problematiky, kterou se tato stať zabývá - pozn. autora
Cesta ke zvýšení produktivity
Rezoluce ÚV KSČ k posílení úlohy vědeckého rozvoje - dokument, který mimo jiné ukazuje též směry dalšího rozvoje výpočetní techniky - ukládá jako jeden z klíčových úkolů zvýšení účinnosti při nasazení počítačů.Při hluibším zamyšlení nad oblastí zpracování hromadných dat je možno dojít k závěru, že problém lze v zásadě rozdělit na dvě části.:
Především je to otázka sjednoceného využívání všech dosud často značně roztříštěných technických i persobnálních kapacit k dosažení realizace vysoce efektivních automatizovaných systémů. Zřejmá náročnost tohoto řešení vyžaduje dlouhodobou činnost specialozovaných pracovišť.
Nabízí se však ještě další oblast, která skýtá rezervy - a jak naznačují některé tendence ve světovém vývoji, zdaleka to nejsou rezervy zanedbatelné. Jedná se o aplikaci metod pro zvýšení efektivnosti vlastní programátorské práce. Na rozdíl od výše uvedené problematiky, jde o poměrně jednoduché zásady, s možností okamžitého použití. Rovněž výsledný efekt se začně prakticky ihned projevovat.
Ve výpočetním středisku TESLA 200 národního podniku INGSTAV Brno byly některé nové racionalizační metody použity na řadě praktických aplikací s velice povzbudivými výsledky. Považujeme za zvlšť cenné, že se jedná o ověření na typu počítače, který má v současné době v ČSSR nejvíce instalovaných systémů. Umožňujeme proto široké odborné veřejnosti seznámení s podstatou těchto námětů a se zkušenostmi při jejich praktickém využívání.
Charakteristika programátorské práce
Pokusme se formulovat, co v sobě v širším slova smyslu zahrnuje činnost, běžně nazývaná programování. Dojdeme ke třem základním skupinám prací, které mají jednak svoji specifickou metodiku a jsou většinou rozlišeny i časovým odstupem:
- programování - převedení myšlenkového algoritmu zpracování do programovacího jazyka příslušného počítače, tj. programová analýza a vlastní kódování.
- ladění - ověření správné funkce navrženého programu a odstranění veškerých zjištěných chyb.
- údržba - dodatečné přizpůsobovánínovým požadavkům, tj. promítání potřebných úprava a změn do hotového programu.
Při kritickém pohledu do našich programátorských řad zjistíme, že:
- současný stav je charakterizován především silně individuálním přístupem k tovrbě programu
- práce na programu je obestřena jakýmsi "mýtem tajemnosti" a nikdo kromě autora nemá většinou možnost postihnout detailní logiku postupu celého řešení
- považuje se za nutné pro zachování stavovské cti, aby program obsahoval různá oroiginální řešení a "speciální finty", které činí právě toto řešení jedinečným a tím prakticky nesrozumitelným pro kohokoliv jiného
- dodržoPříčiny složitostivání i jednoduchých požadavků na sjednocování metodiky, třeba jenom na vnější projevy programů, natožpak vážné zavádění nějakého normovaného programování není ve většině výpočetních středisek běžnou záležitostí, ale spíš v povědomí, jako "že by se mělo ...".
Za této situace vznikne potom nekontrolovaně složitý program, který se dále v závislosti na kvalitách autora může vyznačovat i značnou neuspořádaností. A to nejen ve fyzickém zápisu, ale což je horší, i ve stavbě logiky.
Následky jsou známy. Vysoké časové i finanční nároky vývoje programových systémů a v dalších kolech značné náklady a těžkopádnost při provádění údržby. Nezastupitelnost programátorů, a tím ohrožení spolehlivosti postupu vývoje a především údržby rozsáhlejších programů.
Příčiny složitosti
Programování samo o sobě v žádném případě nepatří mezi jednoduché obory lidské činnosti. V posledních letech se však stále více ukazuje, a ověřovací praxe tyto závěry plně podporuje, že si je děláme daleko komplikovanější, než by skutečně muselo být. Uvažujeme-li složitost, jako hlavní zdroj problémů, můžeme z tohoto pohledu zkoumat jednotlivé oblasti programátorské práce.
Začněme nejprve údržbou. Její podstatné zjednodušení je velice problematické především proto, že ve většině případů není možné předem určit, jaké požadavky budou na program v budoucnu kladeny. Kromě toho s růstem celkového objemu vytvořených programů, se budou nároky na údržbu dále zvětšovat. Pokud jde o ladění a ověřování, tam naše snaha patrně skončí ve výhodné volbě využití standardních programovacích prostředků a organizace ladících souborů v možnostech daného počítače. Východisko bychom tedy měli hledat především na počátku sledovaného procesu, tj. v programové analýze a sestavování posloupnosti instrukcí v příslušném programovacím jazyku.
Pokusíme se dále rozebrat časovou náročnost jednotlivých úseků programátorské práce. Podle literatury dosahuje programátor v rámci celého projektu výkonu pěti až deseti instrukcí za den. Čas na vlastní zakódování těchto instrukcí však nemůže překročit více než několik minut. Čím se tedy po zbývající dobu programátor zabývá ? Měl by provádět důslednou analýzu programového řešení a ještě před zadáním (textu zdrojového programu) do děrovny simulovat programovou logiku na kontrolním příkladu u stolu.
Skutečnost však bývá většinou jiná. Samozřejmě, že sestavení algoritmu v jazyku počítače zabere jistý delší či kratší čas, ale s čistým svědomím je možno prohlásit, že se obecně stráví daleko více času ověřováním a laděním programu, než jeho vytvořením. To vyplývá z dosud značmě rozšířeného přístupu, že programování sestává z trochy strategického přemýšlení na začátku a z hromady úprav při ladění a ověřování. Není zvláštní výjimkou ani úplné přepracování programu po zjištění zásadně chybné logiky nebo vinou nedostatečné komunikace s navazujícími programátory.
V oblasti údržby programů je situace ještě podstatně horší. Poněvadž stále roste rozsah existujícího programového vybavení, rozšiřují se také požadavky na údržbu a přizpůsobování. Díky složité stavbě programů, které již při mnohonásobném ladění bývají poznamenány jistou neuspořádaností logické struktury, dochází někdy k téměř neřešitelným situacím.
S časovým odstupem je detailní vysledování logického postupu programu a stanovení okamžitého stavu proměnných v určitém místě značně obtížné. Často je to i sám autor, kdo velice pracně luští přesné detailní funkce. Složitost programu stále roste, protože v některých případech jsou vkládány nové sekvence a skoky jen proto, že programátor nemůže najít požadovanou funkci, případně se obává zrušit existující sekvenci ze strachu, aby nenarušil činnost jiného úseku.
Výsledky uvedeného zkoumání nás přivedly k závěru, že jsou to především chyby a neuspořádanost myšlení, které limitují produktivitu programování. Byla již publikována řada materiálů, zabývajících se snahou o racionalizaci celého programovacího procesu. Problém je v nich zásadně řešen ve dvou sférách - jednak uspořádanou technologií zápisu vlastního programu a současně novým organizačním přístupem.
Uspořádaná technologie konstrukce a zápisu programu
Logika uspořádaného zápisu programu vychází z následujících úvah:
a) sekvenční přístup (top-down approach)**
**) autor tehdy z nedostatku zkušeností nepřesně chápal a přeložil "přístup shora dolů", jako "sekvenční přístup", ale v závěru podkapitoly principy "systémového přístupu" po úrovních vysvětluje správně - pozn. v r. 2015.
Program je třeba psát tak, aby byla pokud možno přímá korespondence mezi statickou formou programu a dynamickým průběhem při jeho provádění.
Předpokládejme např. následující programový úsek v jazyce COBOL.
1. if A > 30 go to 3.
if A > 20 go to 2.
move 8 to B.
go to 4.
2. move 7 to B.
go to 4.
3. move 6 to B.
4. exit.
Pro oči, vytrénované v jazyku Cobol jistě není problémem brzy postihnout všechny souvislosti. Pokud však návěští 3. a 4. budou o několik stran dále, bude třeba značného listování k tomu, aby se zjistilo, co program zamýšlí. Oč snadněji se lze v tomto programu orientovat, je-li zapsán příslušně uspořádaným způsobem:
1. if A > 30 move 6 to B else
if A > 20 move 7 to B
else move 8 to B.
2. exit.
Dodržování sekvenčně uspořádané formy se striktně vyžaduje všude tam, kde je to možné.
Uvedený požadavek je však třeba chápat i ze širšího hlediska, tj. kontrukci celého systému je dle možností nutno budovat i ověřovat postupně a plynule "shora-dolů". To jsme však u náplně discipliny systémového přístupu vůbec, a tedy mimo okruh našeho momentálního zájmu.
Zde je však nutné poznamenat, že požadavek sekvenčního přístupu vznášíme na instrukce jako prvky systému, kterým je PROGRAM. Pokud některý detail má své speciální řešení, prvkem pak není výkonná instrukce, ale volání uzavřeného podprogramu, ať již pomocí PERFORM nebo CALL. Na každé další rozlišovací úrovni v systému PODPROGRAM potom platí shodné sekvenční zásady.
b) základní schémata (structured programming)
Jednotlivé programové funkce, kterákoliv kombinace rozhodnutí a jakákoliv druh logiky, mohou být vyjádřeny použitím jednoho ze tří základních schémat dle obr. 1 až 3. Každé z těchto základních schémat je charakterizováno jedním jednoduchým vstupem a jedním výstupem. Tato schémata mohou být zkombinována do programu, který je velmi jednoduchý v tom smyslu, že postup jeho provádění je ze zhora dolů a nejsou v něm žádné "cesty zpět". Jsou možné i různé kombinace sloučení základních schémat, ale musí být udržena zásada jeden vstup, jeden výstup. Uvedená pravidla připouštjí výjimku pouze ve dvou případech:
Za prvé se jedná o situaci, kdy se v konvenčním programování používá vypočtený skok nebo přepínač, teda případ, kdy se v závislosti na hodnotě proměnné provede pouze jedna z možných funkcí (viz. obr. 4). Je to vlastně zobecnění výběrového příkazu dle obr. 3 ze dvouhodnotové na více hodnotovou operaci.
Za druhé jde o případ, který vznikne pouze tehdy, když programátor potřebuje zakončit cyklus abnormálně. Ačkoliv takové zakonení poruší zásadu jeden vstup/jeden výstup, může znamenat výrazné úspory místa i strojového času při provádění programu.
Tyto výjimky, pokud jsou vhodně použity však pouze potvrzují pravidlo uspořádaného programování.
Z uvedeného vyplívá i způsob kodování zdrojového programu. Především zjišťujeme, že není vůbec používán příkaz skoku GO TO. Někdy bývá nepřítomnost GO TO prezentována jako hlavní podstata věci. Ověřená skutečnost však je takový, že jsou-li výše zmíněná pravidla správně a důsledně aplikována, tak jednoduše není mnoho příležitostí uvažovat jeho použití.
Popsaná základní schémata mohou být vytvořena v jakémkoliv programovacím jazyku. Uspořádané programování může teda praktikovat kdokoliv - obtížnost se mění ovšem závislostí na tom, který jazyk je používán. Hovoří se i o použití v jazyku assembleru, pokud jsou k dospozici vhodné makroinstrukce, avšak hlavní pole působnosti je ve stávajicích vyšších programovacích jazycích a v jejich dalším vývoji. Zde jsou většinou přímo k dispozici vhodné instrukce. Na příklad FOR TRAN má jednoduchý příkaz IF pro volbu a Do pro cyklus, PL/1 má IF - THAN - ELSE a DO WHILE a rovněž COBOL obsahuje IF - THEN - ELSE a PERFORM UNTIL pro tytéž účely. Tyto příkazy většinou mohou být použity i rekurzivně , takže celkové možnosti jsou skutečně bohaté.
Je třeba se zmíit i o dalších důležitých věcech, které patří ke správné technologii i uspořádaného zápisu programu. Především je třeba zmenšit rozsah programů a složitější problémy řešit pomocí jednotlivých modulů. Délka procedury nebo programu by měla být udržena v mezích srozumitelných jednotek - takových, které lze najednou přehlédnout, tedy asi 50 řádků, neboli 1 strana výpisu z tiskárny. Protože má jeden vstup a jeden výstup, odpadá úplně jakékoliv listování a je možno podstatně lépe koncentrovat pozornost na logiku věci.
Pečlivé optické rozvržení výpisu programu, ukazujicí umístění jednotlivých úrovní, dobrž komentář a popisná "mluvící" návěstí rovněž značně zlepšují srozumitelnost programového textu.
Všechno, co bylo řečeno, možná opravdu poněkud ztíží psaní programu, ale podstatně se zjednoduší jeho čtení. Ale z hlediska kontroly jeho logiky, odstraňování běžných chyb a především z důvodů nutnosti pozdější údržby je zvýšení čitelnosti a srozumitelnosti daleko převažujicí výhodou.
Organizace pracovních týmů
Vytvořením obecněji srozumitelného zdrojového programu se nám otevírá nové pole působnosti při kontrole a řízení programátorské práce. Proces tvorby programů se mění ze soukromého umění na veřejnou praci a to umožňuje podstatné ovlivňování kvality a produktivity. Pro vývoj programového systému lze vytvořit tým, ve kterém panuje dokonalé rozdělení a dělba práce mezi jednotlivé specialilsty. Tento způsob je podstatně výhodnější, než rozkouskování mezi všeobecně zaměřené pracovníky, kteří mají shodné mnohonásobné starosti se všemi problémy komunikace a integrace.
Jádro programového týmu sestává z hlavního programátora, jeho zástupce a programového knihovníka. Toto jádro je sestaveno tak, že je schopno plnit komplexní úkoly od programové analýzy přes kódování a ladšní programů až po dokumentaci, včetně zajišťování potřebné údržby. V závislosti na rozsahu projektu je tým dále doplněn 2 až 3 programátory, případně dalšími specialisty.
Technickým vedoucím týmu je hlavní programátor, který udržuje organizační disciplínu a nese zodpovědnost za projekt. Podstatnou částí náplně jeho práce však také je navrhovat a kódovat centrální kritické segmenty programového systému. Vymezuje rovněž programy nebo moduly pro své spolupracovníky a kontroluje jejich vývoj.
Zástupce hlavního programátora se účastní návrhu klíčových problémů a veškerých důležitých akcí do té míry, aby byl schopen kdykoliv převzít vedení projektu. Plní v případě potřeby též funkci výzkumného asistenta v programové strategii a taktice a umožňuje tak hlavnímu programátorovi plné soustředění na nejdůležitější problémy.
Programový knihovník je zodpovědný za údržbu knihoven a za přípravu, dokumentaci a provedení všechn ladících a ověřovacích prací. Není to však pouhý společný asistent týmu. Zajišťuje, aby byly v platném stavu knihovny a výpisy zdrojových programů, připravuje použitelné programy v jazyku stroje a běžná ladící data. Další členové týmu mohou pracovat efektivněji, s větším pořádkem a s méně zbytečnými omyly. Kromě toho je kdykoliv možné zkontrolovat stav a průběh prací. Vedlejším výsledkem této centralizované činnosti je významné řešení papírové a administrativní práce programátorů.
Schéma činnosti programátorského týmu je na obr. 5. Popsaná technologie spolu s organizací umožňuje plynulé ověřování i kontrolu všech rozhodujicích funkcí a celé architektury programu na papíře ve zdrojovém jazyku. Tato situace způsobí, že přemýšlení na úrovni návrhu je provedeno podstatně hlouběji i když vlastní zápis programu vyžaduje prakticky též čas, jako při klasickém přístupu. celkovým výsledkem kvalifikovanější a pečlivěji sehrané týmové práce je rapidní snížení nároku na ladění a přepracování programů, zvýšení produktivity a ještě významnější zvýšení spolehlivosti a udržovatelnosti vytvořených programů.
Uspořádané programování v praxi
Zásady popsané organizace týmu jsou ve Výpočtovém středisku INGSTAV ověřovány ve skupině programátorů-analytiků, kterou tvoří 6 členů, převážně s kvalifikací VŠ. Uspořádaná technologie konstrukce a zápisu byla důsledně aplikována zhruba na dvou desítkách programů. Tyto řeší dílčí úlohy rozsáhlého podsystému, vyvíjeného již delší dobu klasickým způsobem. Další podmínky, zkušenosti a dosažené výsledky lze charakterizovat asi následovně:
a) prostředky jazyka COBOL TESLA 200
Uvedená literatura, která většinou popisuje poznatky firmy IBM, uvádí příklady převážně z jazyků FORTRAN a PL/1. Prakticky celou výše uvedenou metodiku je však možno úspěšně praktikovat i v jazyku COBOL TESLA 200:
- zápis programu v Cobolu poměrně dobře odpovídá struktuře mluveného jazyka, takže postup logiky problému může být vyjádřen velice názorně
- instrukce IF - ELSE a PERFORM - UNTIL dostatečně umožňují realizovat prakticky všechna základní schémata,
- je možné vytvářet přehlednou grafickou formu výpisu zdrojového programu, zařazovat komentáře a používat samovysvětlujicích návěstí a tak zajistit maximální srozumitelnost programového textu
- kompilátor zajišťuje možnost blokové struktury programů formou slučování přes určitou COMMON-oblast nebo pomocí globálních identifikátorů (instrukce CALL a PROCEDURE DIVISION USING)
- využití Cobolské knihovny dovoluje poměrně dokonalou manipulaci se zdrojovými programy.
Vzhledem ke značné časové náročnosti kompilace na magnetopáskové TESLE 200, přináší zde využití uspořádaného programování veliké úspory strojového času jak ve fázi ladění, tak při údržbě. Lze předpokládat, že popsané výhody a úspory nebudou zanedbatelné ani v budoucnu, kdy připravovaná disková verze kompilátorů zkrátí kompilaci na několik minut.
b) Organizace vs INGSTAV
Je potřebné se zmínit o některých organizačních podmínách ve Výpočetním středisku INGSTAV, které mají nemalý vliv na způsob práce všech ze dvou desítek programů. Pracovníky vedení střediska byla vytvořena již při zahájení činnosti v roce 1970 Norma řízení VS. Obsahuje podrobnou jednotnou metodiku analytické, programové i realizační dokumentace a organizace zpracování dat v provozu VS. Je zde též zakotvena povinnost předložit řešení každého projektu v určitých fázích k interní oponentuře ve vedení střediska. Z toho pokynu, který je v praxi důsledně uplatňován, souvisí s naší problematikou:
- Programy, stejně tak jako soubory dat na každém médiu, mají jednotnou formu označování a ohlašování 6 místným identifikátorem. Poněvadž je založena na pořadovém číslování v rámci střediska, je tento systém jednoznačně určujicí.
- Ošetření veškerých vstupů dat do počítače (asi 7 milionů děrovaných znaků měsíčně) včetně vytvoření souborů na magnetických páskách dle potřeb jednotlivých agend je prováděno univerzálním standardním programovým podsystémem. Ten umožňuje nejen tvorbu vět libovolné struktury, ale provádí i řadu formálních kontrol správnosti.
Tiskové výpisy jednotlivých programů nejsou prováděny přímo, ale zapisují se systémem řízeného záznamu na magnetickou pásku TISKOVÁ BANKA. Vlastní tisk je potom řešen standardním programem, který přebírá též některé funkce řízení tisku, jako naplnění stránky a ošetření záhlaví, opakování od určitého místa a podobně.
Uvedené prostředky umožňují programátorovi soustředit se prakticky pouze na práci se soubory na magnetických páskách.
- Celý třísměnný provoz počítače TESLA 200 probíhá systémem zavřených dveří, tj. bez osobní účasti programátorů. Jednotný přehledný systém návodů pro vedení výpočtů při ladění, ověřování i rutině podstatně šetří čas programátorů a odstraňuje jejich závilost na režimu počítače.
- Specielním vlastním standardním programem je umožněna realizace centrální střediskové knihovny běžně laděných programů. Jsou na ni ukládány ve strojovém kódu (HSFT) a celá údržba včetně kompilací je rovněž zajištěna bez účasti programátorů. Výhody tohoto řešení při ladění a ověřování jsou zřejmé.
c) práce v programátorském týmu
Základní podmínkou uplatňování metod uspořádaného programování je vytvoření dobrého tvůrčího ovzduší a získání pochopení a ochoty všech zúčastněných ke spolupráci. Jedná se o nové, neobvyklé návyky a tak je pochopitelné, že je možno narazit, především u povah konzervativněji zaměřených, nebo u silných individualit. Důležité však je nebát se a začít. První úspěchy, které se určitě dostaví, jsou tou nejlepší argumentací. Je známo, že čím má člověk vyšší úroveň vzdělání a inteligence, tím hůře se smiřuje s příkazy, o jejichž oprávněnosti není vnitřně přesvědčen. V řadách programátorů máme co činit s velice kvalifikovanými odborníky, takže pouhým nařizovaním v žádněm případě neuspějeme. Proto je především nutné provádět osvětovou činnost a pomocí konkrétních příkladů vyvracet námitky.
Většina zkušených programátorů zpravidla již má svůj systém racionální konstrukce a zápisu programů, ověřené sekvence a podobně. Vždy zde však zůstává problém složitosti v souvislosti s pozdější údržbou, zajištěním kontroly spolehlivé komunikace s navazujicími úseky a především v případě změny osoby nositele úkolu, která je v této profesi dosti častá.
Z průběhu dosavadního ověřování lze vytypovat některé důležité momenty:
- důsledně je využívána osoba programového knihovníka k zajištění údržby COBOL-LIBR, i pro obhospodařování odladěných programů na uživatelské knihovně projektu (ULT),
- kařdý program má kromě řešitele určeného oponenta, který dokáže svým nezaujatým přístupem buď sám odhalit řadu chyb, nebo funguje jako ¨katalyzátor¨ a svými dotazy urychlí správnou reakci autora,
- oponentura se provádí nejprve nad vývojovým diagramem a s architekrurou programu a potom nad opisem štítků zdrojového programu, který je pořízen standardním Dumpfil, tedy s minimálním nárokem na strojový čas. Teprve po opravení zjištěných chyb se zadává kompilace Cobol,
- při oponentuře se klade důraz nejen na logickou a věcnou správnost, ale i na vzhledovou formální úpravu programu, tj. čitelnost a srozumitelnost,
- důsledná bloková struktura programů umožňuje, aby kódování jednotlivých funkcí bylo rozděleno mezi více samostatných řešitelů, ať již s využitím slučování programů, nebo s vyhrazenými odentifikátory.
Závěrem je zde plně na místě připomenout, že bez pochopení a iniciativní podpory spolupracovníků by nebylo možno provést v takovém rozsahu ověření, a nakonec ani napsat tento článek.
d) zhodnocení výsledků
Praktické ověřování metodiky uspořádané logiky a organizace programování sice zatím neprobíhá dlouhou dobu, ale přesto je již možno vysledovat některé tendence:
- chybovost při ladění je podstatně menší, hledání a odstraňování chyb je značně rychlejší,
- použití uspořádané techologie konstrukce programu má oproti klasickému způsobu tu důležitou vlastnost, že programátora nenásilně přivádí k hlubšímu zamyšlení a rozboru způsobu řešení problému,
- zmenšení počtu kompilací o 50%, uváděné v literatuře není vůbec přehnané a s využitím kontrolního opisu se ještě dále snižuje,
- dodatečné zásahy do programů, pokud byly prováděny, jsou skutečně nesrovnatelně jednodušší záležitostí, než při klasickém způsobu,
- uspořádanou formou bylo možno poměrně značně srozumitelně popsat základní nejčastěji používané algoritmy pro konverzi, slučování apod., které se staly vítanou metodickou pomůckou,
- ukazuje se, že důsledným používáním metod uspořádaného programování získávají ve svých výsledcích nejen začátečníci, ale i ostřílení zkušení programátoři.
Jako zajímavost můžeme též uvést zjištěnou zkušenost, že je možno zaměřit soutěživost nejen na originalitu, ale i na dosažení jednoduchého řešení a maximální uspořádané přehlednosti zápisu programu. Například použití výše zmíněných popsaných algoritmů není povinné, ale vlastní sekvenc se připouští pouze tehdy, pokud je čitelnější a jednodušší.
Závěr
Některé uvedené náměty by jistě vyžadovaly další podrobný výklad s praktickými ukázkami, avšak i to co bylo řečeno, může být impulsem k zamyšlení. Uspořádanou technologii konstrukce a zápisu programu si může prakticky každý programátor ihned vyzkoušet.
Zdá se, že tendence vývoje programování nebude směřovat k striktním normám na řešení určité problematiky, možná už proto, že se tímto přístupem omezuje tvůrčí invence programátorského řemesla. Zajištění čitelnosti a srozumitelnosti programů naproti tomu programátora nijak nesvazuje a vhodně provedená oponentura jeho díla může mít i značný motivační význam. Objektivní skutečností přitom je, že si dodržováním popsaných zásad podstatně zjednoduší svoji práci, především při kontrole a úpravách programu.
Uspořádaná logika a organizace umožňuje, aby se v programátorské práci projevila síla kolektivu a využily možnosti dělby práce. Bude to tedy pravděpodobně harmonicky sladěný tým, kdo udá krok k cestě za budoucím rozvojem programování.
Literatura.
1. Daniel D. Mc Cracken: Revolution in Programming An Overview (Datamation-December 1973)
2. James R. Donaldson: Structured Programming (Datamation-December 1973)
3. E. F. Miller, G. E. Lindamood: Structured Programming Topdown Approach (Datamation-December 1973)
4. F. T. Baker, H. D. Mills: Chief Programmer Teams (Datamation-December 1973)
5. R. J. Mercer: Simplicity in Programming (Datamation-June 1974)
6. Ing.Drkal, Ing.Dostál, Majda, Ing. Čevela, Ing.Literák, Ing.Pressfreud: Norma řízení výpočetního střediska Ingstav (Ingstav Brno 1970 a 1972)
7. Ing.Čevela: systém zpracování informací v podnikovém výpočetním středisku T 200-Ingstav Brno (Informace Dataclub Tesla 200-č.2-3/1973)
8. Dr. Novák: Efektivnost programovacích jazyků (mechanizace automatizace administrativy č. 5/74)
9. Ing.Čevela, Ing. Drkal, Ing.Lášek,Ing.Kalmár: Návrh směrnice k dokumentování úloh projektové a programové přípravy pro počítač TESLA 200 (Ingstav Brno-URS Praha-srpen 1973)
10. Ing. Pressfreud, Ing.Čevela: Dokumentace standardních programů VS Ingstav Brno
ČeV, doslovný přepis původního textu z r. 1974, publikovaného 1975, přepsáno 07/2017