Tyto texty obsahuji hodne zjednudusenych zapisu (vymyslel jsem je ja, takze nemusi byt spravne mohou byt deformovane ci zobecnene).
Pri zapisu jsem nepouzival dekompozici, nevytvarel jsem ani specifikaci.
Pri psani tohoto zapisu nebylo zraneno zadne zvire.

• dekompozice deli problemy na mensi celky, ktere se dale lepe zpracovavaji
• Lepsi zvladnuti problemu (velke problemy se v celku nedaji zvladnout)
• Delba prace
• moznost vyvyjet jednotlivych celku nezavisle
• moznost testovat jednotlive casti

Pamatovat

• analyza a specifikace
• architektonicky a podrobny navrh
• implementace
• integrace a testovani
• provoz a udrzba

Etapy vyvoje, nutne cinnosti, vstupy a vystupy etap
Rozdily v modelech jsou v posloupnosti etap.

• transformaci neformalnich pozadavku na formalni
• provedeni studie vhodnosti
• planovani akceptacnich testu.

• dohodnuti a naplanovani projektu
• provedeni dekompozice
• ujasneni koncepce

V podstate upresnuje architektonicky navrh

• rozdeleni lidskych zdroju
• plan testu a testovacich dat
• plan algoritmu (ktere na co a proc)
• plan soucasti (provedla se dekompozice.. tak se rekne kdo, co a jak udela)

ten nadpis se mi zda dost debilni (testovani je ve vsech castech pred implementaci se ale testy pouze planuji)

• Vypracovani dokumentace
• Programova realizace (a ja si vzdycky myslel ze toto hlavne vyplyva ze slova implementace.. no co..)
• Zacatek skoleni
• Testovani jednotlivych casti (ne celku ten az pri integraci, az se jednotlive casti spoji.)

nazev by napovidal, ze zde se k testovani nedostaneme.. opak je vsak pravdou

• Spojeni jednotlivych casti (postupne casti na podsystemy a podsystemy de kompletniho celku )
• Oprava chyb
• Testovani jednotlivych celku (podsystemu casti uz jsou otestovane)

• Dalsimu skoleni dalsich zamestnancu
• nasazeni softwaru (jak vyplyva z nadpisu)
• Prevzeti systemu zakaznikem

• opravy chyb, rozsirovani a upravovani systemu
• reseni problemu (nemusi to byt jenom chyby)
• cokoli dalsiho co se muze pri provozu naskytnout

• Nasledujici etapa zacne vzdy po predchazejici… (jak necekane ze?)

• + Pri stalych pozadavcich zarucuje nejlepsi strukturu
• - Zakaznik vidi spustitelnou verzi pozde
• - Realne projekty nesleduji etapy v definovanem poradi.
• 

(Varianta vodopadoveho modelu s durazem na testovani)

• System se teda vyvyji v iteracich no..
• Horsi vysledna struktura
• Predem se stanovi ucelene casti, ktere se pak predavaji uzivateli

• Jednotlive kroky se opakuji
• kombinace prototypu a analyzy rizik

Ma graf… horizontalni casti: zahajeni, rozpracovani, konstrukce, zavedeni; vertikalni casti: pozadavky, analyza, navrh. implementace, testovani.
v podstate se postupne jakoby prekryvaji a kazdy dalsi se pomalu posouva v pravo… jen testovani zacina az v rozpracovani a iteruje porad dokola..

• Zde je zas po kazde iteraci spustitelny kod
• provadi se kontrola kvality
• Modely a vizualizace (UML a tak dal. to co do nas tloukli cely semestr… 2x )

• Zadny projekt nepouziva striktne jeden model.
• modely jsou pouze koncepty

• Zakaznik
  1. Sponzoruje vyvoj
  2. Spocifikuje pozadavky
• Dodavatel
  1. Vyviji (ma zavazky k zakaznikovi)
  2. Komunikuje, testuje.. (proste se stara)
• Uzivatel
  1. Upresnuje pozadavky
  2. Testuje a pouziva system

• Programator
  1. Navrhuje technicke reseni
  2. implementuje, opravje, castecne, testuje
  3. ma jasne danou praci, primo viditelny vysledek
• analytik
  1. Vytvareni cile, specifikace
  2. musi umet komunikovat
  3. nejasne ohraniceni prace

• Funkcionalni (co bude system delat)
• Na provoz (jak to byde delat)
• Na vysledny system (na cem musi system fungovat a t.d.)
• Na rozhrani (jak bude software vypadat, vstupy/vystupy)
• Na vyvoj (vo bude pouzito, jak se bude postupovat)
• Externi (legislativa….)

• Vyrazeni (pri popisu se vynecha treba jen jedno slovo.. popis pak neni jasny)
• Deformace (deformace (pokrouceni) nedokonale vyscetleni problemu)
• Zobecneni (popis je skoro stejny jako u deformace zobecneni je ale zabaleni problemu do jednodussiho, ktery ale nepopisuje vse)

Vyuziva se uml USE CASE a DATA FLOW DIAGRAMY
Use case popisuje ucastniky systemu a jejich moznosti v systemu. DFD popisuje tok a sklady dat v systemu.

• neexistuje standard
• vetsinou se pouziva tabulka
• pokrocile techniky
  • include, extend (pouzivat co nejmene)

Popisuje datove sklady a tok dat v systemu

• Soubor peostredku(objekty, tridy, UML,….) a metodologin(napr. RUP,…..)
• Vyssi stabilita prvku z pohledu menicich se pozadavku

• Abstrakce (zobecneni, zjednoduseni problemu)
• Zapouzdreni (seskupeni funkcionality do jednotek)
• polymorfismus stejne rozhrani muze byt implementovano ruzne)
• Dedicnost (moznost dedit atributy a vlastnosti od nadrazeneho objektu, sdilet jeho chovavni (vytvareni objektu na zaklade jiz existujicich))

• Reprezentuji data zapouzdrena v objektu
• Atribut je vlastnosti objektu
• neni to promenna (to ale nesouvisi s implementaci)

• Objekty lze dale seskupovat do trid
• Trida je mnozina objektu, se stejnym chovanim
• Objekt je instanci tridy ⇒ vytvari se z ni, trida je predpis obejktu)

Implementace je vybrana v dobe kompilace programu

Implementace je vybrana az za behu programu

Kdyz se mneni otec, muze se menit o syn

• Pracuje se pouze s objekty
• nove objekty se vytvareji klonovanim jiz existujicich objektu
• jazyky Self, Javascript

• Urcuje se velikost elementu v pameti, moznosti prace s nimi.
• Staticky typovane jazyky:
  • C, C++, Java
  • Kontrola datovych typu pri kompilaci
• Dynamicky typovane jazyky:
  • Self, Python, PHP
  • Kontrola datovych typu az pri behu

Silne a slabe datove typy popisuji moznosti a omezeni kombinace prace s datovymi typy

• Zakladni model je Diagram trid
• Zobrazuje tridy a jejich vzajemne vztahy
  • Asociace
  • Zavislost
  • Zobecneni
  • Realizace

• Entity relationship diagram - ERD
• State-Transition Diagram - STD

• Slouzi k modelovani dat v klidu (diagram se nesnazi zobrazovat akce ani tok dat. pouze vazby… prakticky navrh DB)
• pojmy
  • Entita je vec (objekt) realneho sveta (napriklad klent c.1, ucet c.1)
  • Entitni mnozina je mnozina entit tehoz typu, ktere sdili vlastnosti.. (to nejak nechapu)
  • atribut je vlastnost entity (napr. cislo klienta, jmeno, prijmeni,…)
  • Vztah je asociace mezi nekolika entitami (napriklad klient c.1 vlastni ucet c.1,….)
  • vztahova mnozina (nevim.. popsal bych to jako abstrakci vztahu ⇒ klient vlastni ucet) stejne jako u entitni mnoziny

Jmeno entitni mnoziny slouzi k vyjadreni vyznamu vztahu.

Je to cetnost vztahu v dane vazbe 1..n———–1
Kardinalita je maximalni cislo..

To same jako kadinalita.. urcuje vlastne povinnost
1..n … je to povinne musi byt alespon jedna polozka..
0..n … neni to povinne → nemusi byt ani jednou.
Clenstvi je minimalni cislo.

• nepouzivat slabe entitni mnoziny (nema vlastni identifikator (PK) pouziva cizi klic. Slaba mnozina nemuze existovat bez identifikujici mnoziny.)
• entitni mnoziny jsou podstatna jmena (klient, ucet)
• vztahove mnoziny jsou slovesa
• mezi mnozinami muze byt vice vazeb
• celkovy sestem by nemel byt zahrnut do ERD
• Nahrazeni vztahu N:M (vazebni mnozinou prida se treri tabulka, v ktere bude moci byt pouzita vicekrat )napriklad limit uctu nepatri ani k uctu ani ke klientovi.. klient muze mit vice uctu a ucet vyuzivat vice klientu.. kazdy s jinym limitem.. lemit bude proto v dalsi tabulce

• zachycuje chovani systemu v zavislosti na case
• prechody mezi stavy a samotne stavy, ve kterych se system muze vyskytovat (delalo se to v projektech do INP a INC)
  • system ma pouze jeden pocatecni stav ale muze mit vice koncovych stavu
  • muze nastat pouze jeden koncovy stav

• udrzovatelnost
• srozumitelnost (vystupu, programu)
• efektivnost programu
• prenositelnost
• efektivnost vyvoje

• system je mozne predvadet az po jeho uplnem dokonceni
• testovani jednotlivych modulu je jednodussi nez testovani logiky celeho systemu

• Moznost demonstrovat system pomerne brzy
• Vcasne odhaleni chyb
• v nekterych pripadech se neda pouzit.

v praxi se pouziva kombinace obou pristupu.

• verifikace zjistuje, jestli vytvarime vyrobek spravne podle pozadavku.
• validace zjistuje, zda vytvarime spravny vyrobek (zda delame to co chhce zakaznik.)

• Spravnost
• Bezpecnost
• Spolehlivost
• Efektivnost

Typy overeni jsou staticke a dynamicke.. Staticke nevyzaduji beh programu.

• testovaci vstup se vybira na zaklade testovaciho kriteria
• testovaci kriterium urcuje podminky, ktere musi splnovat mnozina testovacich vstupu ( napriklad pokryti vsech prikazu v programu)

• Spolehlivost
  • Kriterium je spolehlive, kdyz vsechny mnoziny testovacich vstupu splnujici toto kriterium jsou stejne.. (nezalezi na vyberu vstupu)
• Platnost
  • Kriterium je platne, kdyz pro kazdou chybu v programu existuje mnozina testovacich vstupu, ktere splnuje kriterium k a krera odhali chybu.

• Nahodne testovani
  • Mnozina vstupu se vybere nahodne
• Funkcionalni testovani
  • na zaklade specifikace
  • metoda cerne skrinky
• strukturalni testovani
  • na zaklade vnitrni struktury
  • metoda bile skrinky
  • Mutacni testovani
    • do programu se umyslne zavedou chyby
    • kontrolujeme, zda zavedene testy tuto chybu odhalali.
• testovani rozhrani
  • na zaklade znalosti rozhrani mezi moduly

• testovani zdola nahoru (od mensich casti po celky)
• testovani shora dolu (od celku k mensim castem)
• sendvicova testovani (kombinace dvou predchozich, moduly se deli do skupin logicke , funkcni-)
• Jednofazove testovani (samostatne moduly a pak se naraz integruji. narocne vyhledavani mista chyby)
• Testovani porovnavanim (vice verzi systemu na porovnani, vyvoj pro vice platform)

• provadi se u uzivatele
• uzivatel urcuje, zda produkt splnuje zadani
• dalsi zmeny jiz predstavuji udrzbu
• vztahuje se na zakazkovy software

Vyuziva se pro genericke softwarove vyrobky, kde neni mozne provest akceptacni testovani.
alfa- tam kde se vyvyji, testuje uzivatel, zname prostredi
beta- testuje uzivatel u sebe, podava zpravu, nezname prostredi

• mensi objem dokumentace ⇒ dokumentaci z casti zastupuje dobre komentovany zdrojovy kod.

deleni na adaptivni vs. prediktivni, people-oriented vs. process-oriented.

• adaptivni (agilni metodologie) - reaguji na zmeny a vyvijeji se
• prediktivni se planuji pro velke useky velmi detailne
• process oriented metody
  • tym se meni, projekt zustava stejny
  • posloupnost kroku se nemeni
• people oriented metody
  • podporuje prace tymu
  • proces nevytvari znalosti tymu.

• requirements eneineering
  • vysoke naroky na specifikaci
  • snaha ziskat celkove utvoreny obraz projektu, ktery se dal nemeni
• fixni pozadavky
  • jejich vytvoreni je prilis slozite
• adaptivni metody
  • iterativni vyvoj
    • inkrementalni
    • spiralovy
  • kazda iterace zahrnuje vsechny casti vyvojoveho cyklu.
  • v prvni iteraci se vzdy provadi prevazne planovain

• lide jsou zdroje, maji role
• podstatne je mnozstvi, ne kvalita
• clovek je komponenta systemu

• vychazi z faktu, ze clovek ma promenne chovani a dva nejsou steji
• clovek dokaze nejlepe rozhodnout, vsechny technicke otazky sve prace.

• XP (extreme programming)
• crystal
• scrum
• daaaalsi… Feature driven development dynamic system development

• zaklad je komunikace
• parove programovani, testovani, odhady ukolu
• snazi se resit problemy co nejjednoduseji
• male zmeny

• „casove ohranicene usili, ktere se vyviji s cilem vytvorit jedinecny vysledek“ (nenapada me jiny jednodussi popis.. bohuzel)
  • casove ohranicene usili - (konec projektu urcuje dosazeni dosazitelnych cilu projektu.)
  • jedinecny vysledek - (I kdyz existuji stejne fungujici pojekty, nejsou identicke. )

• me to pripomina takovou znacku pro recyklaci takove ty sipky do krouzku
• sipky jsou ctyri
  • Naplanuj
  • udelej
  • skontroluj
  • jednej

je to celkem jasne proste cyklus jak by se mel chovat manazer

je to graf.. vypada jako krkonose.. znazornuje jak se prekryvaje ruzne casti vyvoje.. sem dostanu leda obrazek

• nekdy se inicializace provadi az po studii vhodnosti
• cinnosi
  • prodi se spoustu analyzy (vseobecnych indormaci, rizik, mezi, podpory)
  • prehodnoceni toleranci a limitu
  • stanoveni zakladni koncepce projektu

Softeware bez chyb ≠ kvalitni software

• velikost, pocty radek, pocet modulu,rozsah dokumentace
• spolehlivost
  • MTBF = MTTF+MTTR (stredni doba mazi vypadky)
  • MTTF = stredni doba do nasledujiciho vypadku
  • MTTR = stredni doba opravy
• dostupnost = MTTF/MTBF *100 [%]
• slozitost
• chyby
• udrzovatelnost

• zakladni tridy softwarovych licenci
  • public domain - verejne, pouzitelne bez omezeni
  • open source - dostupne zdrojove texty
  • proprietalni - vyrobce prodava spustitelnou aplikaci

• Nejpouzivanejsi lience jsou GNU licence:
  • GPL - Vyzaduje, aby software zustal v teto licenci
  • LGPL - Lssser GPL Licence - slabsi.. napriklad pro knihovny
  • Free Documentation Licence - pro dokumentaci
• BSD nevyzaduje dalsi sireni pod BSD
• MIT Licese,……

Tohle me nejak nevzalo.. zkratim to je toho tu strasne moc

1. Verejnost - Melo by se jednat v souladu s verejnymi zajmy
2. Zakaznik a Zamestnavatel - To same co prvni ale se zakaznikem a zamestnavatelem.
3. Vyrobek - Zajisteni nejvyssich moznych standardu
4. Posuzovani - Softwarovi inzenyru by meli posuzovat cestne a nezavisle
5. Management - Manazeri by meli propagovat a podporovat etiku
6. profese - Zlepsovani povesti profese
7. kolegove - Spravedlivost k ostatnim kolegum
8. osobnost - Meli bychom se vzdelavat, vzdelava, vzdelavat, prosazovat eticky kodex

a pozor! na konec! (protoze tohle uz je konec) Poslednich par bodu (ne tak jak jsou zde popsany) vytvorily organizace na podporu standardu. IEEEE-CS, ACM…

Doufam, ze to k necemu bude me i ostatnim