Charakteristika softwaru - Software se nikdy fyzicky neopotřebuje. Software je řešen a vyvíjen inženýry

Softwarový proces

Softwarový proces – definice souvisejících pojmů

Software - Programové vybavení počítače. Software je tvořen souhrnem počítačových programů, pravidel, úvodní dokumentace a dat, která náleží provozu počítačového systému. Charakteristika softwaru - Software se nikdy fyzicky neopotřebuje. Software je řešen a vyvíjen inženýry.

září ’08

Střední průmyslová škola Bruntál

2

Softwarový proces – softwarové inženýrství

Softwarové inženýrství - je samostatný ing. obor, který řeší systematický přístup k vývoji, provozování, údržbě a nahrazování starého softwaru.

září ’08


3

Softwarový proces

Vývoj software je proces, při němž jsou uživatelovy potřeby transformovány na požadavky na software, tyto jsou transformovány na návrh, návrh je implementován pomocí kódu, kód je testován, dokumentován pro konečné použití.

září ’08


4

Softwarový proces

Jinak řečeno softwarový proces nám umožňuje sledovat celý průběh vývoje software tak, abychom lépe dokázali vyhovět potřebám klienta. Letité poznatky v zásadě umožnily rozdělit softwarový proces do několika základních aktivit.

září ’08


5

Softwarový proces – aktivity při vývoji software

•

Specifikace požadavků – obecná definice funkcí a jiných omezení vyvíjeného softwaru.

•

Vývoj – implementace systémů dle daných výsledků specifikace (musí odpovídat požadavkům)

•

Validace – aktivita, ve které se skutečně ověří, že software odpovídá zadání.

•

Evoluce – musí být umožněn další vývoj software tak, aby byl umožněn a zajištěn jeho další vývoj

září ’08


6

Softwarový proces – viditelné znaky vývoje software

•

Artefakty o o o o

•

Výpisy z programů Dokumentace Data Zdrojové kódy

Procesy o o o

září ’08

Pracovní postupy Uznávaná pravidla Interakce mezi členy týmu


7

Softwarový proces – programování ve velkém vs. v malém

Prozatím použijte poznámky z hodin.

září ’08


8

Softwarový proces – viditelné znaky vývoje software

Vzhledem k povaze softwaru je právě viditelnost jednotlivých artefaktů a procesů velmi důležitá. Je to to jediné co nám umožňuje optimalizovat aktivity. Při konfrontaci s jiným odvětvím výroby, jako jsou například stavebnictví a strojírenství, kde je každá s fází výroby jasně zřetelná, je výroba softwaru problematičtější. Víme z vlastních zkušeností, že u softwaru může být viditelný výsledek práce až po několika desítkách hodin.

září ’08


9

Softwarový proces – modely životního cyklu

Modely životního cyklu jsou jakýmsi pracovním postupem, kterými se řídí výroba softwaru. Každý z níže uváděných modelů je pak vhodný pro různorodé typy projektů. Což bude jedno ze srovnávacích kritérii. Modely životního cyklu nám umožní lépe sledovat již zmíněné aktivity a zlepšují řízení vývoje softwaru.

září ’08


10

Softwarový proces – modely životního cyklu: Vodopád

září ’08


11


Pro kvalitu software by bylo nejvhodnější, kdyby každá fáze byla úplná 100% a už bychom se k ní nemuseli vracet – to by garantovalo také úplný výstup. Z praxe však víme, že se žádná fáze nepodaří napoprvé dokončit a je potřeba se k nim vracet.

září ’08


12


•

Definice požadavků – probíhají konzultace s klientem, jejichž výsledkem by měla být co možná nejpřesnější specifikace požadavků uvažovaného softwaru.

•

Analýza a návrh software – zde se připravují na základě požadavků podklady pro programátora. Jinak řečeno, musíme přesně říct co a jak má programátor udělat.

•

Implementace a testování komponent – opět zde vycházíme z předchozího cyklu. V této části probíhá kódování v konkrétním jazyce a ověření správnosti výsledků.

září ’08


13


•

Testování celého systému – předposlední fáze ověřuje splnění požadavků na systém.

•

Provoz a údržba – nenápadná, částečně opomíjená fáze, ale časově nejnáročnější. V této fázi musí být zajištěna reakce na změny působící na software z okolního prostředí (nové technologie, operační systémy, architektury počítačů, apod.)

září ’08


14


•

Nevýhody o

o o

o

září ’08

Pro klienty je obtížné dopředu jasně specifikovat co vlastně chtějí. Často vznáší dodatečné požadavky, což nabourává sled fází Vodopádu. Výsledky dosti opožděně po sepsání požadavků, což zvyšuje nároky na trpělivost klienta. Problematické je též hledání chyb. Když si představíme, že snahou je vyhotovit každou z fází co nejúplnější, pak chyba popřípadě nový požadavek značně zvyšuje nároky na čas a tím zvyšuje i cenu projektu. V reálném prostředí se jednotlivé fáze obtížně dodržují. V případě použití Vodopádu u webových aplikací, kde jsou zvýšené nároky na design (implementace), dojde k posunu části implementace. Střední průmyslová škola Bruntál

15


•

Výhody o

o

září ’08

Díky jasnému rozdělení jednotlivých etap lze lépe rozdělovat práci mezi jednotlivé specialisty. V dnešní době se stává jen zřídka, že by jeden člověk realizoval rozumně velké softwarové dílo efektivně sám. Je potřeba mít velké množství znalostí. V případě dodržení sledu a obsahu jednotlivých etap je Vodopád velmi efektivní z pohledu zapracování požadavků, zvyšuje tak celkovou pravděpodobnost úspěšnosti projektu. Díky této schopnosti bývá v praxi často preferován před ostatními modely.


16

Softwarový proces – modely životního cyklu: Výzkumník

září ’08


17


Stává se, že oblast, pro kterou je systém vyvíjen není příliš obvyklá pro realizační tým. Pro příklad lze uvést například systém pro evidenci drogistických výrobků. Zde z největší pravděpodobností nelze očekávat podrobnou znalost řešitelů v daném odvětví. Během získávání poznatků se vývojáři mohou často vracet zpět na začátek. V tomto konkrétním případě by mohlo být vhodnější použít model Výzkumník. Naopak například pro evidenci CD/DVD disků Vodopád, protože očekáváme, že řešitel, dokáže hned v úvodu korigovat požadavky.

září ’08


18


•

Vytvoř systém – s vědomostí nespecifikovaného výsledku, řešitel přistoupí přímo k tvorbě rámcových specifikací.

•

Implementuj systém – výsledkem této etapy je funkční systém se všemi očekávanými vlastnostmi.

•

Používej systém – klient testuje systém a zjišťuje zda mu vyhovuje, či nikoli.

•

Předání hotového systém – v ideálním případě je možné, že již při prvním pokusu dojde k předání systému.

září ’08


19


•

Nevýhody o

o o o o

září ’08

Při použití Výzkumníka nevzniká příliš kvalitní dokumentace. Většinou řešitel provedené změny v implementaci nezapracovává do dokumentace. Tento fakt částečně komplikuje další vývoj softwaru. Je vhodný pouze pro menší nadané řešitelské týmy. Velmi špatně se sledují jednotlivé etapy vývoje jako jsou analýza a návrh. Obtížné manažerské řízení – dělba úkolů. Těžká nahraditelnost řešitelů projektu. Nový programátor má díky neúplné dokumentaci problémy se změnami aplikaci


20


•

Výhody o o o o

září ’08

Existuje reálná šance, že je výrobek schválen hned napoprvé a předán k užívání. Doba řešení projektu bývá kratší než u Vodopádu. Vynecháním částí, kde se tvoří dokumentace, je možné zásadně ovlivnit cenu výsledného produktu. Je velmi výkonný u malých projektů, takových jež se nedají rozumně rozdělit na menší samostatně existující podsystémy.


21

Softwarový proces – modely životního cyklu: Prototyp Sběr požadavků a tvorba analýzy

Rychlý návrh

Vylepšení návrhu prototypu

Vytvoření prototypu

Vyhodnocení prototypu klientem

Specifikace systému

Návrh a implementace systému

září ’08


22

Softwarový proces – modely životního cyklu: Prototyp

Pohled prototypu na softwarový proces se očekávaně odlišuje od Výzkumníka a Vodopádu. Požadavky a analýza systému jsou tvořeny s vědomím, že se během vývoje mohou změnit. Očekává se, že některé části již vyvinutého softwaru budou vědomě zahozeny. Prototyp prohlubuje spolupráci mezi řešiteli a zákazníkem. Klient během vývoje testuje prototypy (buď ve formě specifikace nebo úplné implementace) a dále upřesňuje své požadavky. Tento způsob vývoje je vhodný v situacích, kdy zákazník přesně neví co od systému chce.

září ’08


23


•

Sběr požadavků a tvorba analýzy – v prototypu může být neúplná očekávají se změny.

•

Rychlý návrh – ze znalostí z předchozí fáze se provede rychlý návrh prototypu systému.

•

Vytvoření prototypu – musí být funkční, v prvních fázích nemusí sledovat model chování, dále je vhodné tvořit prototyp tak aby jeho části byly znovu použitelné. Viz. Komponentní technologie. Tento přístup může výrazně urychlit další vývoj.

září ’08


24


•

Vyhodnocení prototypu klientem – klient se vyjádří k prototypu, ověří prototyp vlastním testováním. Aby byl efekt testování co nejlepší, je zapotřebí úplně zdokumentovat výsledky testů.

•

Vylepšení návrh prototypu – zapracování poznatků z předchozí fáze.

•

Specifikace systému + Návrh a implementace systému – využití poznatků ze specifikace a implementace prototypů. Jedná se o finální zkompletování.

září ’08


25


•

Nevýhody o

o

o o

září ’08

Vysoké nároky na interakci s klientem, při větším počtu prototypů se ztrácí efektivita. Navíc vysoké množství prototypů zvyšuje dobu řešení projektu. Prototyp je nevhodný pro řešení velmi velkých projektů a těch projektů, které vyžadují velké množství přerozdělované práce. Z pohledu manažerského řízení se špatně přerozděluje práce. Zpravidla každý prototyp má svůj vlastní evoluční vývoj. Některé prototypy mohou být úplně nepoužitelné, zbytečná práce. Špatně se určuje cena díla.


26


•

Výhody o

o

o

září ’08

Hlavní výhoda spočívá především v tom, že se může prototypovat tak dlouho, dokud není systém dle požadavků zákazníka. Pokud řešitelé tvoří specifikaci a následně implementaci tak, že se dá opět použít, může být prototypování velmi rychlé. V případě, že prototypujeme pouze specifikaci můžeme ušetřit čas strávený nad implementací.


27

Softwarový proces – modely životního cyklu: Rational Unified Process

září ’08


28

Softwarový proces – modely životního cyklu: Rational Unified Process

Metodologie Rational Unified Proces (RUP) je komerčním rozšířením Unified Proces (UP) od firmy IBM. Nejpodstatnějším rozdílem je rozšíření pracovních postupů: přidání Byznys modelování před požadavky a přidání Nasazení. Metodologie samozřejmě obsahují i další rozdíly, ale ty jsou pro naše potřeby zanedbatelné. Bez újmy na úplnosti se budeme zabývat UP a později rozšíříme výklad i o RUP.

září ’08


29

Softwarový proces – modely životního cyklu: Unified Process

Unified proces (UP) definuje proces vývoje software a s ním spojené tři základní otázky: kdo, co, kdy a jak. UP je oproti UML, které tvoří jazykovou část, částí procesní. Metodika UP byla vyvinuta v roce 1967. Jelikož se od sebe jednotlivé projekty zpracovávané pomocí UP liší, což je přirozený stav vyplívající z požadavků na systém, je nutné pro každý projekt vytvořit novou instanci. Díky tomuto postupu je docílena vysoká univerzalizace, která se dá použít na každý projekt. Metodika UP obsahuje tři základní axiomy. o o o září ’08

Zásada řízení případem užití a rizikem. Zásada soustředění na architekturu. Zásada iterace a přírůstku. Střední průmyslová škola Bruntál

30


Kdo, co, kdy a jak? Při průchodu dbejte na to, aby jste si dokázaly odpovědět na výše uvedené otázky! Sledujete naplnění odpovědí během jednotlivých iterací, v každé iteraci si je musíte ověřit!

září ’08


31


Jako hlavní přínos UP chápeme iterativní přístup k jednotlivým pracovním postupům. V každé iteraci pak díky testování ověřujeme správnost dosavadních výsledků. Výška křivky v jednotlivých pracovních postupech pak vyjadřuje množství vykonané práce. Viditelné rozčlenění umožňuje dobrou kontrolu a dělbu práce mezi jednotlivé specialisty.

září ’08


32


•

Pracovní postupy a iterace UP přesně specifikuje pracovní postup, který ve svém sledu určuje, co je třeba udělat a způsoby, kterými je možné cíle dosáhnout. Základních pracovních postupů je pět, každý z nich obvykle zahrnuje plánování, odhad a další postupy a mechanismy, které jsou pro danou iteraci specifické. o o o o o

září ’08

Požadavky Analýza Návrh Implementace Testování


33


•

• • • •

Požadavky. Zaznamenávají, co by měl systém dělat, jak by se měl chovat a další kritéria definované zadavatelem. Analýza. Zjemnění požadavků, určení jejich struktury, snaha o hlubší pochopení. Návrh. Provádí realizaci konkrétních požadavků a kompozici architektury systému. Implementace. Jedná se o zápis kódu v daném jazyce na základě provedeného návrhu. Testování. V této části se ověřuje, zda systém odpovídá požadavkům a zahrnuje očekávané funkce.

září ’08


34


•

Fáze metodiky UP Každý pracovní postup iterace je rozložen do několika základních fází. Je evidentní, že každý z těchto postupů nemůže být vyhotoven přímo. Jinak řečeno každá metodika by se měla skládat z čtyř fází, které by měli být odděleny tzv. milníkem. o o o o

září ’08

Začátek Rozpracování Konstrukce Zavedení


35


•

•

Začátek. V této fázi dojde k samotnému odstartování. Milníkem je definice cíle, kterého se má dosáhnout po ukončení dané fáze. Tento faktor je velmi důležitý, protože oproti ostatním vývojovým procesům, které se spíše zaměřují na artefakty, UP je zaměřena více na konečné cíle. Rozpracování. V této fázi je důležité vytvoření spustitelné architektury. Jedná se již o spustitelný systém, který pokrývá nejméně 80 % funkčních požadavků. Je určen k dalšímu dopracování a zjemnění. Milníkem této fáze je vytvoření životního cyklu se všemi náležitostmi.

září ’08


36


•

•

Konstrukce. Zde se již ze spustitelného základu vytvořeného ve stádiu rozpracování stává konečná verze systému. V tomto stádiu jsou dále dokončeny veškeré modely, a systém zahrnuje veškeré požadavky. Milník je provozní způsobilost. Zavedení. Poslední částí je zavedení. Zde se snažíme především o dokončení testování a opravu všech chyb. Dalšími cíly jsou příprava uživatelů, tvorba manuálů, školení a další kroky potřebné pro zavedení softwaru do praxe. Nasazení produktu je posledním milníkem.

září ’08


37


•

Nevýhody o

o

září ’08

Pro malé projekty není UP příliš vhodné, důvodem je požadavek na úplnou a kvalitní dokumentaci, jejíž tvorba může být zdlouhavá. Zdlouhavost vývoje je problematické z pohledu okolních změn, délka vývoje, může být natolik dlouhá, že dynamický vývoj v tomto oboru, může rychlejší než rychlost tvorby produktu.


38


•

Výhody o

o o

o

září ’08

Lze velmi rychle nalézt chybu, odstranění chyby v ranném okamžiku vývoje aplikace, snižuje náklady na její pozdější odstranění. Pozdější odstranění je totiž zásadně dražší a navíc pozdě odhalená chyby jde většinou na vrub řešitele. Lze velmi elegantně přerozdělovat práci a průběžně sledovat výsledky jednotlivých pracovních týmů. Od středně velkých projektů je UP nebo její modifikace nejefektivnější. Důvodem je právě ona optimalizace dělby a kontroly práce. ………………


39

Softwarový proces – Agilní metodiky

•

Nejužívanější agilní metodiky • • • • •

•

SCRUM Extrémní programování LEAN Development Feauture Driven Development Test Driven Development

Další metodiky • •

září ’08

Crystal Adaptive Driven Development


40

Softwarový proces – Agilní metodiky – SCRUM Development proces

•

Zvýšení efektivity vývoje sofwtare • •

• •

Každý vývojář odpovídá za svou množinu objektů Tři až osm pevně daných posloupností s pevnými časovými intervaly (Sprints) • •

•

Iterativní přístup Inkrementální přístup

Denní schůzky (suplují centrální plánování) Každý Sprint končí výsledkem (Demo)

Klíčové pojmy • • • • •

září ’08

Flexibilní předměty dodání (nejasné cíle) Flexibilní harmonogram Malé týmy (tři až šest členů – kombinace týmů) Časté revize (každodenní zkoumání) Spolupráce Střední průmyslová škola Bruntál

41


•

Pojmy metodiky SCRUM • •

•

Backlog (Nosič informací o činnostech, funkcích, vlastnostech, uživatelských příbězích Riziko (silně orientováno na analýzu rizik)

Posloupnost kroků a fází •

• • •

září ’08

Plánování (Rozsah aktuální verze, harmonogram, nutné zdroje. Důležitý je Backlog – je mapován na objekty) Architektura a design (vytvoření architektury) Vývoj Uzavření (Zákazník posoudí parametry aktuální verze)


42


•

Třetí fáze - Vývoj

září ’08


43


•

Výhody • • •

•

Pružná reakce na změny zadání Každodenní reflexe vývoje Objektově orientovaný přístup

Nevýhody • • • •

Obtížný přechod na nový způsob práce Vhodné typy lidí Vyrovnání se s odlišným typem vývoje SCRUM je spíše způsob vedení, nedefinuje konkrétní postupy

Zdroje: Agilní programování, Václav Kadlec http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf - SCRUM za pět minut

září ’08


44

Softwarový proces – Agilní metodiky – Extrémní programování

•

•

Největší důraz je kladen na zdrojový kód. Považuje se za jediný exaktní, jednoznačný, změřitelný, ověřitelný a nezpochybnitelný zdroj informací. Charakteristiky • • • • • •

září ’08

Jednoduchost (nejjednodušší verze, která ještě může fungovat) Průběžné revize a kontroly zdrojového textu Neustálé zlepšování návrhu (refaktorizace) Klíč k úspěchu je architektura Testování modulů Velmi krátké iterace (minuty, hodiny)


45


září ’08


46


•

Čtyři hodnoty extrémního programování • • • • •

září ’08

Komunikace Jednoduchost Odvaha Zpětná vazba Pátá, podprahová hodnota: respekt


47


•

Výhody • • •

•

V souladu s lidskými instinkty Iterativní a inkrementální vývoj Nelpění na formalitách

Nevýhody • • • •

Nutný zaběhlý tým – neúspěšný pokus Proč dělat věci jednoduše, když to jde složitě Programátoři s dobrou znalostí programátorských základů Kolektivní vlastnictví kódu, kdo za co zodpovídá

http://www.extremeprogramming.org/

září ’08


48

Softwarový proces – Agilní metodiky – LEAN Development

•

•

Metodika převzata z výroby automobilů z tzv. Lean Manufactoring. Ta je používána v automobilce Toyota (Toyota Production Systém) Cíle • • •

•

Vývoj software za třetinu obvyklého času Třetina obvyklého rozpočtu Snížit na třetinu četnost chyb

Co je při vývoji podle LEAN Development nepostradatelné • • • •

září ’08

Suroviny a základní materiály Výsledný produkt, který někdo koupí Nástroje používané týmem při výrobě produktu Dovednosti získané týmem


49


•

Odstranění zbytečností • •

•

Minimalizace zásob • •

•

Vyvíjíme jen to co je potřebné Potřebujeme jen to co potřebuje klient k provozu

Maximalizace toku • •

•

Co můžeme postrádat Minimální specifikace – často pouze požadavky

Push systém – rozdělení do kroků Lineární vývoj

Vývoj je tažen poptávkou • •

září ’08

Rozhodnutí provádět co nejpozději Vycházíme z měnících se požadavků


50


•

Pracovníci mají pravomoci rozhodovat •

•

Hlavním cílem je uspokojovat požadavky zákazníků • •

•

Častý kontakt s klientem Vyšší spokojenost

Zavedení zpětné vazby • •

•

Nerozhoduje se shora, pracovníci rozhodují sami

Počítáme s neúplnými požadavky Možnost přepisu či likvidace již hotových částí programu

Odstranění lokálních optimalizací •

• září ’08

Neoptimalizovat lokální moduly. Zefektivnění jednoho modulu nemusí nutně znamenat zefektivnění celku. Optimalizovat celek Střední průmyslová škola Bruntál

51


•

Partnerství s dodavateli •

•

Pro dodávané části systému najít spolehlivého dodavatele

Kultura pro neustálé zlepšování • •

září ’08

Zvýšení motivace členů týmu Zlepšení pracovního prostředí


52


•

Výhody • • •

•

Možný rychlý vývoj systému Část postupů lze aplikovat i do jiných metodik Velký prostor pro individuality v týmu

Nevýhody • • •

září ’08

Není skutečnou metodikou Nevhodné pro velmi velké projekty Lineární vývoj je tak pomalý jak je pomalý nejpomalejší programátor


53

Softwarový proces – Empirické zákony

Během let, kdy byl vyvíjen software se zjistilo, že existují pravidla a postupy, které se opakují, nebo které vykazují během doby života software podobné nebo totožné vlastnosti. Tyto poznatky daly za vznik Empirickým zákonům. Nejčastěji sledované vlastnosti: o o o o

září ’08

Dělba, plánování (normování) práce Ohodnocení práce Náročnost prací V závislosti na uvedeném - výsledky


54

Softwarový proces – Empirické zákony

Tato sledování a prováděly především velké softwarové firmy (USA). Systematické sledování dalo za vznik Softwarové fyzice. Lehman a Belady studovali dynamiku softwarových systémů poté co byly dokončeny Po statickém vyhodnocení dat o údržbě a vzrůstající velikosti systémů publikovali následujících pět zákonů.

září ’08


55

Softwarový proces – Empirické/Lehmanovy zákony

• •

•

Zákon trvalé proměny: Systém používaný v reálném prostředí se neustále mění, dokud není cenově výhodnější systém restrukturalizovat nebo jej nahradit zcela novou verzí. Zákon rostoucí složitosti: Při evolučních změnách je program stále méně a méně strukturovaný (vzrůstá entropie) a vzrůstá tedy jeho složitost. Odstranění narůstající složitosti vyžaduje dodatečné úsilí. Zákon vývoje programu: Rychlost změn globálních atributů systému se může jevit v omezeném časovém intervalu jako náhodná. V dlouhodobém pohledu se však jedná o seberegulující proces, který lze statisticky sledovat a předvídat.

září ’08


56

Softwarový proces – Empirické/Lehmanovy zákony

•

•

Zákon invariantní spotřeby práce: Celkový pokrok při vývoji projektů je statisticky invariantní. Jinak řečeno, rychlost vývoje programů je přibližně konstantní a nekoreluje s vynaloženými prostředky. Zákon omezené velikosti přírůstku: Systém určuje přípustnou velikost přírůstku v nových verzích. Pokud je limita překročena, objeví se závažné problémy týkající se kvality a použitelnosti systému.

září ’08


57

Softwarový proces – Boehemovo TopTen

1.

2. 3. 4. 5. 6.

Nalezení a oprava softwarového problému je 100x dražší než odstranění defektu ve fázi požadavků a v úvodních fázích návrhu. Údaje uvedené v plánu práce lze stlačit o ( přidáním lidí peněz atd.) o 25%, ale víc ne. Údržba stojí 2x tolik, co vývoj aplikací. Vývoj a údržba jsou především funkcí velikosti produktu Variace lidských schopností je příčinou největších variací v produktivitě Podíl ceny SW a HW se změnil z hodnoty 15:85 v roce 1955 na 85:15 v roce 1985 a stále roste ve prospěch SW.

září ’08


58

Softwarový proces – Boehemovo TopTen

7. 8.

Pouze 15% práce tvoří kódování Instrukce aplikačního programu je 3x dražší než instrukce individuálního programu, instrukce systémových programů jsou 9x dražší 9. Inspekce programu zachyt 60% chyb 10. Mnohé SW procesy splňují Paretovo rozložení: o o o o o

září ’08

20% modul přispívají k 80% ceny, 20% modul obsahuje 80% chyb, 20% chyb spotřebuje 80% rozpočtu vyhrazeného na opravy, 20% modul spotřebuje 80% času výpočtu, 20% nástrojů používá 80% času


59

Softwarový proces

Literatura: http://www.fi.muni.cz/~sochor/PA103/Slajdy/

září ’08


60

Charakteristika softwaru - Software se nikdy fyzicky neopotřebuje. Software je řešen a vyvíjen inženýry

Recommend Documents