Počítačová veda, kybernetika a programovanie

Iteration N USDP Unified Software Development Process Model prípadu použitia popisuje prípady, v ktorých bude aplikácia použitá. Analytický model popisuje základné triedy pre aplikáciu. Model návrhu popisuje vzťahy a vzťahy medzi triedami a priradenými objektmi. Model nasadenia popisuje distribúciu softvéru medzi počítačmi.

Lekcia číslo 20
Všeobecné zásady a prístupy k vývoju softvéru

Modely vývoja softvéru

1. Vodopád
2. Kaskádový model
3. Špirála
4. Extrémne programovanie
5. Inkrementálne
6. Metodika Lekárov bez hraníc

Vodopádový model

Špirálový model

Prírastkový vývoj

Analýza požiadaviek

Dizajn

Implementácia

Komponent

testovanie

Integrácia

Testovanie

jeden celok

Iterácia 1 Iterácia 2…. Iterácia N.

Zjednotený proces vývoja softvéru (USDP)

1. Model prípadu použitia opisuje prípady použitia, v ktorých sa bude aplikácia používať.
2. Analytický model popisuje základné triedy pre aplikáciu.
3. Návrhový model popisuje vzťahy a vzťahy medzi triedami a vybranými objektmi.
4. Model nasadenia popisuje distribúciu softvéru medzi počítačmi.
5. Implementačný model popisuje vnútornú organizáciu programového kódu.
6. Testovací model pozostáva z testovacích komponentov, testovacích postupov a rôzne možnosti testovanie

Metodika Lekárov bez hraníc

Typické súčasti architektúry softvérového produktu a typické požiadavky na softvér

odolnosť proti chybám- súbor vlastností systému, ktorý zvyšuje jeho spoľahlivosť zisťovaním chýb, obnovou a lokalizáciou zlých dôsledkov pre systém. Pri navrhovaní akéhokoľvek skutočného systému na zaistenie odolnosti voči chybám je potrebné zabezpečiť všetky druhy situácií, ktoré môžu viesť k zlyhaniu systému, a vyvinúť mechanizmy na riešenie porúch.

Spoľahlivosť - schopnosť systému odolávať rôznym poruchám a poruchám.

Odmietnutie Ide o prechod systémuv dôsledku chyby v úplne nefunkčnom stave.

Havária - chyba v prevádzke systému, ktorá nevedie k zlyhaniu systému.

Čím menej zlyhaní a zlyhaní za určité časové obdobie, tým je systém spoľahlivejší.

A tiež ďalšie diela, ktoré by vás mohli zaujímať
57355.		Rozmanitosť organických zlúčenín, ich klasifikácia. Organická hmota živej prírody	48,5 kB
	Rôznorodosť organických zlúčenín je daná jedinečnou schopnosťou atómov uhlíka navzájom sa kombinovať jednoduchými a viacnásobnými väzbami za vzniku zlúčenín s takmer neobmedzeným počtom atómov spojených v reťazcových cykloch bicykle trojkolky polycykly rámcov atď.
57359.		Spracovanie verbálnych informačných modelov	291 kB
	Základné pojmy: model; informačný model; verbálny informačný model; anotácia; abstraktné. Synopsa Synopsa z lat. Vytvorte obrys pre 2. Uložte dokument do vlastného priečinka pod názvom Obrys.
57361.		Číslo a číslo 3. Korelácia čísel na hraniciach 3. Písanie čísel 3. Korelácia čísel na hraniciach objektov	35,5 kB
	Skici všetkých tvorov, ktoré stoja za to prvýkrát, ktoré stoja za to, kým stoja za číslo 1 Kto stojí za číslo 2 Hto susid pravák bilochki Hto susid livoruký žirafa Hto є blízky handto Hto є dolný hander Kto stojí uprostred tvorov Gras Show nie je pokrčený.

Modely vývoja softvéru Vodopád Model vodopádu Špirála Extrémne programovanie Prototypovanie používateľského rozhrania Inkrementálne testovanie modelu W Jednotný proces vývoja softvéru (USDP) Metodika MSF

Waterfall Model Požiadavky Analýza Špecifikácia produktu Vytvorenie Návrhu Architektúra produktu Vytvorenie Implementácia Vývoj zdrojového kódu Integrácia oddelených častí zdrojového kódu Testovanie a odstraňovanie chýb

Extrémne programovanie Počiatočné požiadavky Analýza Dizajn Integrácia Implementácia Testovanie Nové požiadavky Vývojový plán Revízia / schválenie / Modifikácia Vydanie produktu

UI Prototyping Vydanie produktu Vývoj softvéru s prihliadnutím na zmeny Objasnenie požiadaviek a špecifikácií Úprava prototypu a spresnenie niektorých funkcií Základná funkčnosť Prototyp rozhrania Predbežná špecifikácia

Prírastkový vývoj Iterácia 1 Iterácia 2…. Požiadavky Analýza Návrh Implementácia Komponentové testovanie Integrácia Testovanie celej iterácie jednotky N

Unified Software Development Process (USDP) Ø Use-Case Model, popisuje prípady použitia, v ktorých sa bude aplikácia používať. Ø Analytický model popisuje základné triedy pre aplikáciu. Ø Model návrhu popisuje prepojenia a vzťahy medzi triedami a pridelenými objektmi. Ø Model nasadenia popisuje distribúciu softvéru medzi počítačmi. Ø Implementačný model popisuje vnútornú organizáciu programového kódu. Ø Testovací model pozostáva z testovacích komponentov, testovacích postupov a rôznych testovacích možností

Zjednotený proces vývoja softvéru (USDP) Zhromaždite požiadavky ITER 1…. Iter N Design Iter 1…. Implementácia Iter N Iter 1…. Iter N Konštrukcia Iter 1…. Testovanie Iter N Iter 1…. Iter N.

Typické súčasti architektúry softvérového produktu a typické softvérové ​​požiadavky Ø Ø Ø Ø Organizácia programu Hlavné triedy systému Organizácia údajov Obchodné pravidlá Užívateľské rozhranie Správa zdrojov Zabezpečenie Výkonnosť Škálovateľnosť Interoperabilita s inými systémami (integrácia) Internacionalizácia, lokalizácia Údaje I / O Spracovanie chýb

Typické súčasti architektúry softvérového produktu a typické požiadavky na softvér Odolnosť voči poruchám je súbor vlastností systému, ktorý zvyšuje jeho spoľahlivosť zisťovaním chýb, obnovou a izolovaním zlých dôsledkov pre systém. Pri navrhovaní akéhokoľvek skutočného systému na zaistenie odolnosti voči chybám je potrebné zabezpečiť všetky druhy situácií, ktoré môžu viesť k zlyhaniu systému, a vyvinúť mechanizmy na riešenie porúch. Spoľahlivosť je schopnosť systému odolávať rôznym zlyhaniam a poruchám. Zlyhanie je prechod systému v dôsledku chyby do úplne nefunkčného stavu. Zlyhanie je chyba v prevádzke systému, ktorá nevedie k zlyhaniu systému. Čím menej porúch a zlyhaní za určité časové obdobie, tým je systém spoľahlivejší.

Typické súčasti architektúry softvérového produktu a typické požiadavky na softvér Krivka spoľahlivosti N t 1 t Čím ďalej, tým ťažšie bude nájsť chybu. Čím je systém zložitejší, tým je väčšia pravdepodobnosť, že zlyhá a zlyhá.

Typické súčasti architektúry softvérového produktu a typické požiadavky na softvér Ø Možnosti implementácie vyvinutej architektúry. Ø Nadbytočná funkčnosť. Ø Rozhodnutie o kúpe hotových softvérových komponentov. Ø Stratégia zmeny.

Kontrolný zoznam otázky, ktoré nám umožňujú urobiť záver o kvalite architektúry: Ø Je celková organizácia programu jasne opísaná; Ø Ø Ø Obsahuje špecifikácia prehľad architektúry a jej odôvodnenie. Sú hlavné zložky programu, oblasti ich zodpovednosti a interakcie s inými zložkami dostatočne definované? Sú všetky funkcie uvedené v špecifikácii požiadaviek implementované primeraným počtom systémových komponentov. Existuje popis najdôležitejších tried a ich odôvodnenie. Existuje popis organizácie databázy. Sú definované všetky obchodné pravidlá? Bol popísaný ich vplyv na systém.

Kontrolný zoznam otázok na vyvodenie záverov o kvalite architektúry: Ø Bola popísaná stratégia návrhu používateľského rozhrania. Ø Bolo používateľské rozhranie modulárne, aby zmeny neovplyvnili zvyšok systému. Ø Existuje popis stratégie vstupu / výstupu údajov. Ø Bola vykonaná analýza výkonu systému, ktorý bude implementovaný s použitím tejto architektúry. Ø Bola vykonaná analýza spoľahlivosti navrhnutého systému? Ø Bola vykonaná analýza problémov škálovateľnosti a rozšíriteľnosti systému.

Refaktorovanie softvéru Refaktoring zahŕňa prispôsobenie softvéru novému hardvér a na nové operačné systémy, nové vývojové nástroje, nové požiadavky, ako aj softvérovú architektúru a funkčnosť. Toto je zmena vo vnútornej štruktúre softvéru bez zmeny jeho vonkajšieho správania, navrhnutá tak, aby poskytovala úpravu softvéru. Primerané dôvody pre refaktoring: Kód sa opakuje; implementácia metódy je príliš veľká; príliš veľa vnorenia slučiek alebo samotná slučka je veľmi veľká; trieda má slabú súdržnosť (vlastnosti a metódy triedy musia popisovať iba 1 predmet); rozhranie triedy netvorí konzistentnú abstrakciu; metóda vyžaduje príliš veľa parametrov. Malo by sa vyvinúť úsilie, aby bol počet parametrov primerane minimálny; jednotlivé časti triedy sa menia nezávisle od ostatných častí triedy;

Softvér na refaktorovanie pri zmene programu vyžaduje súbežnú úpravu niekoľkých tried. Ak takáto situácia nastane, je potrebné reorganizovať triedy, aby sa minimalizovali miesta možných zmien v budúcnosti; musieť súčasne zmeniť niekoľko hierarchií dedičnosti; musíte zmeniť niekoľko blokov prípadov. Program je potrebné upraviť takým spôsobom, aby sa vykonala implementácia bloku prípadov, a v programe ho vyvolať v potrebnom počte; súrodenecké položky používané spoločne nie sú organizované do tried. Ak opakovane používate rovnakú sadu dátových položiek, potom je vhodné zvážiť kombináciu týchto údajov a operácie, ktoré sa s nimi vykonávajú, zaradiť do samostatnej triedy;

Metóda softvérového refaktorovania používa viac prvkov inej triedy, ako je jej vlastná. To znamená, že metódu je potrebné presunúť do inej triedy a zavolať zo starej; primitívny dátový typ je preťažený. Na opis entity v reálnom svete je lepšie použiť triedu, ako preťažovať existujúce dátové typy; trieda má príliš obmedzenú funkčnosť. Je lepšie sa tejto triedy zbaviť prenosom jej funkčnosti do inej triedy; roamingové údaje sa prenášajú pozdĺž reťazca metód. Údaje, ktoré sa prenášajú do metódy, ktorá sa má odovzdať iba inej metóde, sa nazývajú „blúdivé“. Keď nastanú tieto situácie, pokúste sa redizajnovať svoje triedy a metódy, ako sa ich zbaviť.

Refaktorovanie softvéru nerobí nič s objektom mediácie. Ak je úloha triedy zredukovaná na presmerovanie volaní metód do iných tried, potom je najlepšie odstrániť takýto sprostredkovateľský objekt a volať do iných tried priamo; jedna trieda vie príliš veľa o inej triede. V tejto situácii je potrebné zapuzdrenie sprísniť, aby sa zabezpečili minimálne znalosti dediča o jeho rodičovi; metóda má nešťastný názov; títo členovia sú verejní. Tým sa stiera hranica medzi rozhraním a implementáciou, nevyhnutne sa narúša zapuzdrenie a obmedzuje flexibilita programu; písať komentáre v zdrojový kód;

Refaktorovanie softvéru Podtrieda používa iba malý zlomok metód svojich predkov. K tejto situácii dochádza, keď je nová trieda vytvorená iba na zdedenie niekoľkých metód zo základnej triedy a nie na opis akejkoľvek novej entity. Aby sa tomu zabránilo, je potrebné transformovať základnú triedu takým spôsobom, aby poskytovala prístup k novej triede iba k metódam, ktoré potrebuje; kód obsahuje globálne premenné. Globálne by mali byť iba tie premenné, ktoré skutočne používa celý program. Všetky ostatné premenné musia byť buď lokálne, alebo sa musia stať vlastnosťami niektorých objektov; program obsahuje kód, ktorý môžete jedného dňa potrebovať. Pri vývoji systému je vhodné poskytnúť miesta, kde bude možné v budúcnosti pridať zdrojový kód.

1. Účel programovacej technológie. História vývoja programovacej technológie. Typy softvérových projektov. Komponenty programovacej technológie. Projekt, produkt, proces a ľudia

2. Životný cyklus programu. Cyklická povaha vývoja. Základné pojmy programovacej technológie. Procesy a modely. Fázy a zákruty. Míľniky a artefakty. Zainteresované strany a zamestnanci.

3. Identifikácia a analýza požiadaviek. Požiadavky na softvér. Schéma vývoja požiadaviek. Správa požiadaviek.

4. Architektonický a detailný návrh. Implementácia a kódovanie. Testovanie a overovanie. Proces kontroly kvality. Metódy bielej a čiernej skrinky. Kontrola a recenzie. Testovanie cieľov. Overovanie, validácia a testovanie systému. Údržba a neustály vývoj.

5. Modely vývojového procesu. Modely vodopádov a dopravníkov. Špirálové a inkrementálne modely. Flexibilné modely vývojového procesu.

6. Konštrukcia procesného modelu. Identifikácia požiadaviek na proces. Použité fázy, míľniky a artefakty. Voľba architektúry procesu. Postup pre typický projekt. Zdokumentované postupy.

7. Modely vývojového tímu. Kolektívna povaha vývoja. Optimálna veľkosť tímu. Podriadenosť účastníkov projektu. Rozvoj tímu a rozvoj personálu. Špecializácia, spolupráca a interakcia.

8. Modely vývojového tímu. Hierarchický tímový model. Chirurgická tímová metóda. Model rovesníckeho tímu.

9. Povaha programovania. Veda o programovaní. Umenie programovania. Remeslo programovania. Paradigmy programovania. Štruktúrované programovanie. Logické programovanie. Objektovo orientované programovanie.

10. Architektúra softvéru. Manažment udalostí. Architektúra klient / server. Služby. Trojvrstvová architektúra. Navrhovanie programov. Koncepčný návrh. Logický dizajn. Podrobný dizajn.

1. Novikov prístupy k vývoju softvéru "http: // okno. /window_catalog/files/r60368/itmo307.pdf.

2. Extrémne programovanie. - SPb.: Peter, 2002.

3. Technológia vývoja softvéru. - SPb. : Peter, 2004.

4. Brooks ml. navrhnuté a vytvorené softvérových balíkov... Moskva: Nauka, 1975; nové vydanie prekladu: Mýtický mesiac človeka. SPb.: SYMBOL +, 1999.

5. Algoritmy + dátové štruktúry = programy. M., Mir, 1978.

6. Systematické programovanie. Úvod. Moskva: Mir, 1977.

7. Štruktúrované programovanie. Moskva: Mir, 1975.

8. Disciplína programovania. Moskva: Mir, 1978.

9. Technológie vývoja softvéru. - SPb.: Peter, 2002.

10. Programovanie Terekhov. M.: BINOM, 2006.

11. Rambeau J. Zjednotený proces vývoja softvéru. SPb: Peter, 2002.

Ekonomická teória pre manažérov

Základné mikroekonomické teórie. Príklady aplikácie v analýze ekonomických procesov. Základné makroekonomické teórie. Príklady aplikácie v analýze ekonomických procesov. Zásady a metódy riadenia ekonomických procesov. Súbor nástrojov na hodnotenie úrovne rozvoja ekonomických procesov Problémy rozšírenej reprodukcie. Faktory ekonomického rastu ruskej ekonomiky. Kritériá a ukazovatele trvalo udržateľného rozvoja. Vyhladzovanie cyklické výkyvy... Úloha multiplikátora a akcelerátora pri hodnotení tempa ekonomického rozvoja. Výrobné funkcie v ekonomike. Príklady aplikácie v analýze ekonomických procesov. Zisk. Výpočet ukazovateľov ovplyvňujúcich zisk, grafické znázornenie bodu zlomu. Metodika implementácie investičnej politiky.

Kurz ekonomickej teórie: učebnica pre univerzity / Ed. ... - Kirov: "ASA", 2004. Kolemaev - matematické modelovanie. Modelovanie makroekonomických procesov a systémov: učebnica. M .: UNITY-DANA, 2005. Bazhin kybernetika. Charkov: Consul, 2004. Leushin workshop o metódach matematického modelovania: návod. Štát Nižný Novgorod tech. univ.- N. Novorod, 2007. Politikom o ekonómii: Prednášky laureátov Nobelovej ceny za ekonómiu. M.: Moderná ekonómia a právo, 2005. Cheremnykh. Pokročilá úroveň: Učebnica.-M .: INFRA-M, 2008. Vývoj inštitúcií miniekonómie. Ekonomický ústav URO RAS, - Moskva: Nauka, 2007.

Technológie na vývoj a prijímanie rozhodnutí manažmentu [N]

Rozhodovanie ako základ činnosti manažéra. Úvod do teórie rozhodovania. Základné pojmy z teórie rozhodovania. Modely riadenia podniku a ich vplyv na rozhodovanie. Rôzne spôsoby klasifikácia rozhodnutí. Klasifikácia: podľa stupňa formality, podľa stupňa rutiny, podľa frekvencie, podľa naliehavosti, podľa stupňa dosiahnutia cieľov, podľa metódy výberu alternatívy. Základné metódy rozhodovania. Silné vôľové metódy rozhodovania. Rozhodovanie o cieľoch. Čas hľadať riešenia. Hlavné chyby Matematické metódy rozhodovania. Matematické aspekty teórie rozhodovania. Operačný výskum. Matematický prístup k rozhodovaniu. Rozhodovací strom. Modely vývoja a rozhodovania. Herná teória. Matematické metódy rozhodovania. Matematické aspekty teórie rozhodovania. Modely teórie radenia. Modely riadenia zásob. Lineárny programovací model. Transportné úlohy. Simulačné modelovanie. Analýza siete. Ekonomická analýza. Obmedzenia racionálnych modelov. Vlastnosti vývoja a rozhodovania v skupine. Metóda určovania skupinovej súdržnosti na základe stupňa prepojenia množín. Techniky kolektívneho rozhodovania. Konsenzuálna metóda. Spôsoby hlasovania. Kreatívne metódy rozhodovania. Brainstorm. Konferencia myšlienok. Lodná doska. Metóda De Bonových klobúkov mysle. Teória invenčného riešenia problémov (TRIZ). Perfektné konečné riešenie. Príklady úloh a ich riešenie pomocou TRIZ. Aplikácia metód TRIZ pri jedinečných a kreatívnych rozhodnutiach. Metódy rozvíjania myšlienok riešení a ich prispôsobenia situácii. Cieľový stromový model. Stratégia na zosúladenie záujmov. Tvorba rozhodnutí o koordinácii záujmov. Metódy určovania záujmov zmluvných strán. Systémy na podporu rozhodovania (expertné systémy). História tvorby rozhodovacích systémov. Klasifikácia rozhodovacích systémov. Typická štruktúra expertného systému. Spôsoby, ako reprezentovať znalosti. Logické inferenčné metódy. Aplikácia expertných systémov v praxi.

I. Teória rozhodovania: učebnica. - M.: Skúška, 2006.- 573 s. I. Rozhodovanie. Teória a metódy rozvoja manažérskych rozhodnutí. Výučba. - M.: Marec 2005. - 496 s. Vývoj riešení pre manažment - M.: Vydavateľstvo Delo, 2004 - 392 s. G. Odborné hodnotenia a rozhodovanie. - M.: Patent, 1996. - 271 s. Taha // Úvod do operačného výskumu = Operačný výskum: Úvod. - 7. vydanie. - M.: „Williams“, 2007. - S. 549-594. G. Chvost. Ekonomické prognózy a rozhodovanie. M.: „Pokrok“ 1970. KD Lewis. Metódy prognózovania ekonomických ukazovateľov. Moskva: „Financie a štatistika“ 1986. G. S. Kildishev, A. A. Frenkel. Analýza a prognózy časových radov. M.: „Štatistiky“ 1973. O. Kim, C. W. Mueller, W. R. Klecka a kol. Faktor, diskriminačná a klastrová analýza. M.: „Financie a štatistika“ 1989. Efektívny manažér. Kniha 3. Rozhodovanie. - MIM LINK, 1999 Turevsky a manažment motorovej dopravnej spoločnosti. - M.: postgraduálna škola, 2005.,; vyd. ... Analýza systému v manažmente: návod... - M.: Finance and statistics, 2006., Tinkov: učebnica. - M.: KNORUS, 2006.

Modelovanie podnikových procesov v integrovaných manažérskych systémoch

Aké sú zásady rozlišovania obchodných procesov? Aký je problém holistického popisu podnikových procesov. Čo je to systém, aké má vlastnosti? Úloha systémovej analýzy v modelovaní podnikových procesov? Proces ako predmet kontroly. Procesné prostredie. Hlavné prvky obchodného procesu. Výhody a nevýhody funkčného a procesného riadenia. Cyklus riadenia PDCA. Fázy cyklu riadenia procesu. Cyklus PDCA a implementácia požiadaviek ISO 9001: 2008. Metodika SADT (Structured Analysis and Design Technique - metóda štruktúrnej analýzy a návrhu). Esencia. Základné ustanovenia. Ako je v metodike IDEF0 reprezentovaný funkčný model aktivity? Čo znamenajú činnosti v diagramoch funkčného modelu, ako sú zobrazené podľa metodiky IDEF0? Na čo slúžia šípky v diagramoch funkčných modelov, aké sú ich typy a typy? Metodika DFD. Esencia. Hlavné súčasti grafov DFD. Aké sú vlastnosti diagramov DFD a ako sú popísané? Aké sú vlastnosti objektov grafu DFD? Čo predstavujú šípky v grafe DFD? Metodika IDEF3. Esencia. Dokumentačné a modelovacie nástroje. Aké sú vlastnosti diagramov IDEF3 a čo popisujú? Aké sú vlastnosti objektov diagramu IDEF3? A strelec? Klasifikácia procesov. Typické obchodné procesy. Reengineering a jeho technológie. Kedy je vhodné uplatniť reinžiniering vo vedení spoločnosti? Monitorovanie a meranie procesov. Ukazovatele procesu organizácie. Numerické a hodnotiace hodnotenia procesov.

„Modelovanie podnikových procesov pomocou AllFusion Process Modeler (BPwin 4.1) Dialogue-MEPhI“ 2003 „Vytvorenie informačných systémov pomocou AllFusion Modeling Suite“ vyd. Dialogue-MEPhI 2003 "Cvičenie funkčného modelovania s AllFusion Process Modeler 4.1. (BPwin) Kde? Prečo? Ako?" vyd. „Dialogue-MEPhI“ 2004 Dubeykovsky modeling with AllFusion Process Modeler (BPwin). vyd. „Dialogue-MEPhI“ 2007 D. Mark, C. McGowan „Metodika štrukturálnej analýzy a návrhu SADT“ 1993 klasická práca o metodike SADT. Analýza systémov Cheremnykh: IDEF-technológie, Modelovanie a analýza systémov. Technológie IDEF. Dielňa. M.: Finance and statistics, 2001., „Structural business models: DFD-technologies“ http: // www. /Level4.asp? ItemId = 5810 „Teória a prax reorganizácie podnikových procesov“ 2003 / P50.1 .. Metodika funkčného modelovania. Moskva: Gosstandart Ruska, 2000. http: // www. IDEF0, IDEF3, DFD http: // www. Modelovanie podnikových procesov pomocou BPwin http: // www. / department / se / devis / 7 / IDEF0 v modelovaní procesov riadenia podniku http: /// content / view / 21/27 / http: // www. /dir/cat32/subj45/file1411/view1411.html http: // www. http: // www.

Hodnotenie účinnosti softvérových produktov

1. Architektúra IT

2. Oblasti procesov riadenia.

3. Zoznam plánovania a organizácie doménových procesov

4. Zoznam procesov získavania a implementácie domény

5. Zoznam prevádzky a údržby doménových procesov

6. Zoznam procesov monitorovania a hodnotenia domény

7. Charakteristika úrovní modelu zrelosti procesu

9. KPI a KGI, ich vzťah a účel

1. 10. Všeobecné kontroly IT a kontroly aplikácií. Oblasti zodpovednosti a zodpovednosti podnikania a IT.

Ruské vydanie Cobit 4.1.

Právna úprava tvorby a používania duševného vlastníctva

1. Vytvorte zoznam duševných práv k výsledkom duševnej činnosti a odhaľte ich obsah.

2. Vymenujte druhy zmlúv o nakladaní s výhradnými právami. Popíšte každú z týchto zmlúv o výhradných právach.

4. Popíšte hlavné ustanovenia právnej ochrany počítačového programu ako predmetu autorských práv.

5. Porovnajte hlavné ustanovenia právnej ochrany Databázy ako predmetu autorského práva a ako predmetu súvisiacich práv.

6. Popíšte podmienky patentovateľnosti predmetov patentových práv: vynálezy; úžitkové vzory; priemyselné vzory.

7. Rozšíriť obsah kritérií patentovateľnosti vynálezu: novinka; invenčný krok; priemyselná použiteľnosť.

8. Popíšte podmienky a postup na získanie patentu na vynález, úžitkový vzor alebo priemyselný vzor, ​​ako aj podmienky zabezpečujúce platnosť patentov a podmienky ich platnosti.

9. Uveďte definíciu „know-how“ a uveďte zoznam podmienok, za ktorých vytvorenia a výkonu sa vykonáva právna ochrana výrobných tajomstiev.

10. Uveďte chránené prostriedky individualizácie a uveďte ich porovnateľné charakteristiky.

1., Práva duševného vlastníctva v Ruská federácia, učebnica // M, Prospect, 2007

2., Právo duševného vlastníctva, študijná príručka // M, RIOR, 2009

Projektový manažment a vývoj softvéru [A]

Čo je to metodika, prečo je potrebná. Všeobecná štruktúra metodiky, hlavné prvky metodiky. Zásady navrhovania vlastnej metodiky. Príklady rôznych artefaktov, rolí, kompetencií, okrajových podmienok. Štruktúra metodiky podľa Cowberna, metrika metodiky. Kritériá projektu podľa Cowberne. Kritériá výberu metodiky, Coubernova matica. Životný cyklus projektu. Vodopádové a iteračné modely životný cyklus... Limity použiteľnosti pre vodopádové a iteračné modely. RUP ako príklad iteratívnej metodiky. Základné pojmy RUP, limity použiteľnosti. Úloha človeka vo vývoji softvéru. Agilné metodiky, základné princípy agilných metodík. Dôvod vzniku agilných metodík. Scrum ako príklad agilnej metodiky. Role, artefakty, aktivity v Scrume. Rozsah Scrum. Extreme Programming (XP) Myšlienky, hodnoty, základné postupy, limity použiteľnosti. Podobnosti a rozdiely medzi programami Scrum a XP. Zhromažďovanie a správa požiadaviek. Základné postupy, termíny, zásady. Prístupy k projektovej a produktovej dokumentácii, hlavné typy dokumentov. Príklady postupov riadenia požiadaviek z metodík diskutovaných v kurze. Plánovanie vývoja softvéru. Typy plánov, manažment rizík, obľúbené riziká. Príklady postupov plánovania rozvoja z metodík diskutovaných v kurze. Testovanie vývoja softvéru. Pojem zostavy (zostavy) softvérového produktu. Základné testovacie metódy, termíny. Príklady testovacích postupov z metodík diskutovaných v kurze. Pojem zostavy (zostava), spôsoby ukladania kódu, nástroje. Dva princípy organizácie práce so systémom na správu verzií. Vlastnosti procesu uvoľnenia / zobrazenia produktu pre rôzne kategórie produktov, príklady postupov. Moderné koncepty softvérovej architektúry, vrstvené architektúry, kritériá architektúry. Zoznam potrebných rozhodnutí pri navrhovaní softvéru, prístupy k výberu úložného systému.

Kent Beck - Extrémne programovanie Frederick Brooks - Bájny mesiac človeka alebo ako stvorené softvérových systémov... Tom de Marco - Termín. Román o projektovom manažmente. Tom de Marco, Timothy Lister - Valčík s medveďmi. Tom de Marco, Timothy Lister - Ľudský faktor_ úspešné projekty a tímy. Alistair Couburn - Každý projekt má svoju vlastnú metodiku. Alistair Couburn - Ľudia ako nelineárne a najdôležitejšie súčasti vývoja softvéru. Andriy Orlov - Poznámky automatizátora. Profesionálne priznanie. Philip Crachten - Úvod do racionálneho zjednoteného postupu. Henrik Kniberg - Scrum a XP: Poznámky z frontovej línie. Prezentácie prednášok z kurzu

Podstata štrukturálneho prístupu k vývoju softvéru EIS spočíva v jeho dekompozícii (rozdelení) na automatizované funkcie: systém je rozdelený na funkčné podsystémy, ktoré sú zase rozdelené na podfunkcie, tie na úlohy atď. konkrétne postupy. Systém si zároveň zachováva holistický pohľad, v ktorom sú všetky základné prvky navzájom prepojené. Pri vývoji systému „zdola nahor“, od jednotlivých úloh k celému systému, sa stráca integrita, problémy vznikajú pri popise informačnej interakcie jednotlivých komponentov.

Všetky najbežnejšie metódy štruktúrovaného prístupu sú založené na niekoľkých všeobecných zásadách:

1. Princíp „rozdeľ a panuj“;

2. Princíp hierarchického usporiadania - princíp usporiadania jednotlivých častí systému do hierarchických stromových štruktúr s pridaním nových podrobností na každej úrovni.

Rozlišovanie dvoch základných princípov neznamená, že ostatné zásady sú sekundárne, pretože ignorovanie ktoréhokoľvek z nich môže viesť k nepredvídateľným následkom (vrátane zlyhania celého projektu “). Hlavnými z týchto zásad sú:

1. Princíp abstrakcie - zvýraznenie podstatných aspektov systému a odvádzanie pozornosti od nepodstatného.

2. Zásada konzistentnosti, platnosti a konzistentnosti systémových prvkov.

3. Princíp štruktúrovania údaje - údaje by mali byť štruktúrované a hierarchicky organizované.

V štrukturálnom prístupe existujú v zásade dve skupiny nástrojov, ktoré opisujú funkčnú štruktúru systému a vzťah medzi údajmi. Každá skupina fondov zodpovedá určitým typom modelov (diagramov), najbežnejšie z nich sú:

DFD (Data Flow Diagrams) - diagramy toku údajov;

SADT (Structured Analysis and Design Technique - metodika štrukturálnej analýzy a návrhu) - modely a zodpovedajúce funkčné diagramy: zápisy IDEF0 (funkčné modelovanie systémov), IDEF1x (koncepčné modelovanie databáz), IDEF3x (konštrukcia systémov na hodnotenie kvality objekt; grafický popis tokových procesov, interakcie procesov a objektov, ktoré sú týmito procesmi zmenené);

· ERD (Entity - Relationship Diagrams) - diagramy „entita -vzťah“.

Takmer všetky metódy štrukturálneho prístupu (štrukturálna analýza) vo fáze vytvárania požiadaviek na softvér používajú dve skupiny modelovacích nástrojov:

1. Diagramy znázorňujúce funkcie, ktoré by mal systém vykonávať, a vzťahy medzi týmito funkciami - DFD alebo SADT (IDEF0).

2. Diagramy, ktoré modelujú údaje a ich vzťahy (ERD).

Konkrétna forma uvedených diagramov a interpretácia ich konštrukcií závisia od štádia životného cyklu softvéru.

Vo fáze formovania softvérových požiadaviek sa modely SADT a DFD používajú na zostavenie modelu „AS-IS“ a modelu „TO-BE“, čím sa odzrkadľuje existujúca a navrhovaná štruktúra podnikových procesov organizácie a interakcia medzi nimi. (pomocou modelov SADT je ​​spravidla obmedzené iba na túto fázu, pretože pôvodne neboli určené na návrh softvéru). S pomocou ERD sa opis údajov použitých v organizácii vykonáva na koncepčnej úrovni bez ohľadu na spôsob implementácie databázy (DBMS).

V prvej časti sme sa rozhodli porovnať metodiky vývoja softvéru s takými ukazovateľmi, ako je pomer metodiky k iteračnému vývoju a stupeň formality pri navrhovaní pracovných materiálov a vo všeobecnosti v procese vývoja. V tejto časti používame tieto metriky na porovnanie najznámejších techník vývoja softvéru.

Uvidíme, ako to pôjde…

Žiaľ, toto je najťažšie opísateľná kategória - koniec koncov, zahŕňa to produkt kŕčovitého hádzania začiatočníka pokúšajúceho sa za každú cenu dokončiť svoj prvý projekt, ako aj celkom vyspelé a osvedčené metodiky, ktoré absorbovali mnoho rokov a rozmanité skúsenosti konkrétnych vývojových tímov a dokonca aj tých, ktoré sú popísané vo vnútorných predpisoch. Pretože ľudia, ktorí sú schopní vyvinúť svoju vlastnú metodiku, ju spravidla môžu sami vyhodnotiť z hľadiska iterácie a formalizácie, zameriame sa na začiatočníkov. Žiaľ, najčastejšie to znamená, že pravidlá pre rozvoj buď neexistujú, alebo boli vyvinuté a prijaté, ale nie sú dodržané. Prirodzené v takýchto podmienkach je extrémne nízky level rozvojový formalizmus. S týmto je teda všetko jasné.

Vývoj „Ako to ide“

A čo iteračný prístup? Bohužiaľ sa v takýchto projektoch spravidla nepoužíva. V prvom rade preto, že by to umožnilo už pri prvých iteráciách vyhodnotiť projekt ako mimoriadne pochybný a vyžadujúci si naliehavý zásah vyššieho manažmentu, aby sa veci dali do poriadku. V iteratívnom projekte sa tradičná odpoveď programátora, že všetko je pre neho už na 90% pripravené, odohráva iba do konca prvej iterácie ...

Štrukturálne metodiky

Štrukturálne metodiky

Štrukturálne metódy sú skupinou metodológií vyvinutých spravidla pred rozšírením objektovo orientovaných jazykov. Všetky zahŕňajú rozvoj vodopádov. Aj keď, ako sa ukázalo, aj v tomto článku, ktorý sa často uvádza ako prvá prezentácia prístupu k vodopádu, bolo povedané, že je vhodné začať projekt s vývojom prototypu, tj. dve iterácie.

Napriek tomu je základom týchto metodík postupný prechod z práce do práce a prenos výsledkov (dokumentov) ďalšej etapy účastníkom ďalšej.

Všetky tieto metodiky tiež predpokladajú vysoko formalizovaný prístup, aj keď v nich možno nájsť vyhlásenia o primeranom množstve dokumentácie. Jedným z nejasných príkladov, ktoré metodológie vývoja softvéru vyvinuli nielen na Západe, je citát z knihy, ktorá u nás vyšla na začiatku osemdesiatych rokov minulého storočia a uvádza, že stupeň formalizácie programátorskej úlohy by mal byť určený na základe toho, ako dobre analytik a programátor. A to napriek skutočnosti, že predmet knihy predpokladal vývoj dosť kritických, ako sa im teraz hovorí, systémov, chýb, v ktorých vedú k vážnym stratám alebo dokonca katastrofám.

Agilné metodiky

Agilné metodiky vychádzajú z desiatich princípov, z ktorých pomenujeme iba tie, ktoré určujú hodnotenie týchto metodík podľa vybraných parametrov:

• hlavnou vecou je uspokojiť zákazníka a poskytnúť mu produkt čo najskôr;
• nové vydania produktu by sa mali objavovať každých niekoľko týždňov, v extrémnych prípadoch - mesiacov;
• väčšina efektívna metóda prenos znalostí účastníkom vývoja a medzi nimi - osobná komunikácia;
• spustený program je najlepším ukazovateľom pokroku vo vývoji.

Tieto metódy sú teda jasne zamerané na iteračný vývoj softvéru a minimálnu formalizáciu procesu. K druhému bodu je však potrebné urobiť výhradu: tieto metódy sú zamerané na minimálnu úroveň formalizácie prijateľnú pre daný projekt. Minimálne jedna z metodík zahrnutých v flexibilnej skupine - Crystal - má modifikácie navrhnuté tak, aby vykonávali procesy s rôznym počtom účastníkov a rôznou kritickosťou vyvíjaného softvéru (kritickosť softvéru je určená možnými dôsledkami chýb, ktoré sa môžu líšiť v od nevýznamných finančných strát cez opravy chýb až po katastrofické). Aby ďalšie porovnanie s agilnými metodikami nebolo zbytočné, uvádzame krátke popisy niekoľko z nich.

eXtreme Programming alebo XP (extrémne programovanie)

Metodika XP, ktorú vyvinuli Kent Beck, Ward Cunningham a Ron Jeffries, je dnes najznámejšou metodikou Agile. Niekedy je samotný koncept Agile explicitne alebo implicitne identifikovaný s XP, ktorý obhajuje komunikáciu, jednoduchosť, spätnú väzbu a odvahu. Je popisovaný ako súbor praktík: plánovanie hier, krátke vydania, metafory, jednoduchý dizajn, refaktoring, vývoj dopredu, párové programovanie, kolektívne vlastníctvo kódu, 40-hodinový pracovný týždeň, prítomnosť zákazníkov a štandardy kódu. Záujem o XP rástol zdola - od vývojárov a testerov, ktorých trápil bolestivý proces, dokumentácia, metriky a ďalší formalizmus. Nepopierali disciplínu, ale nechceli nezmyselne dodržiavať formálne požiadavky a hľadali nové, rýchle a flexibilné prístupy k rozvoju vysokokvalitných programov.

Pri použití XP je starostlivý predbežný návrh softvéru nahradený na jednej strane neustálou prítomnosťou zákazníka v tíme, pripraveným odpovedať na akúkoľvek otázku a vyhodnotením akéhokoľvek prototypu, a na strane druhej pravidelnými revíziami kódu (tzv. nazývané refaktoring). Dôkladne komentovaný kód je považovaný za základ projektovej dokumentácie. Vysoko veľká pozornosť metodika sa zameriava na testovanie. Spravidla je pre každú novú metódu najskôr napísaný test a potom je vyvinutý skutočný kód metódy, kým sa test nezačne úspešne vykonávať. Tieto testy sú uložené v sadách, ktoré sa automaticky vykonajú po akejkoľvek zmene kódu.

Aj keď je programovanie párov a 40-hodinový pracovný týždeň asi najznámejšími funkciami systému XP, stále podporujú a prispievajú k vysokej produktivite vývojárov a menšiemu počtu vývojových chýb.

Krištáľovo čistý

Crystal je rodina metodík, ktoré určujú potrebný stupeň formalizácie vývojového procesu v závislosti od počtu účastníkov a kritickosti úloh.

Metodika Crystal Clear je výkonovo nižšia ako XP, ale používa sa čo najľahšie. Implementácia vyžaduje minimálne úsilie, pretože je zameraná na ľudské návyky. Verí sa, že táto metodika opisuje prirodzený poriadok vývoja softvéru, ktorý je stanovený v dostatočne kvalifikovaných tímoch, ak sa nezaoberajú účelnou implementáciou inej metodiky.

Kľúčové vlastnosti Crystal Clear:

• iteračný prírastkový vývoj;
• automatické regresné testovanie;
• používatelia sú zapojení do aktívnej účasti na projekte;
• zloženie dokumentácie určujú účastníci projektu;
• Spravidla sa používajú nástroje na kontrolu verzie kódu.

Okrem Crystal Clear zahŕňa rodina Crystal niekoľko ďalších metodík navrhnutých na zvládnutie väčších alebo kritickejších projektov. Majú o niečo prísnejšie požiadavky na dokumentáciu a postupy podpory, ako je zmena a kontrola verzií.

Funkcia riadená vývojom

Feature Driven Development (FDD) funguje s konceptom funkcie alebo vlastnosti (vlastnosti) systému, ktorý je dostatočne blízky konceptu prípadu použitia používaného v RUP. Asi najpodstatnejším rozdielom je dodatočné obmedzenie: „každú funkciu by malo byť možné implementovať maximálne do dvoch týždňov“. To znamená, že ak je prípad použitia dostatočne malý, môže byť považovaný za funkciu, a ak je veľký, mal by byť rozdelený do niekoľkých relatívne nezávislých funkcií.

FDD obsahuje päť procesov, pričom posledné dva sa opakujú pre každú funkciu:

• vývoj všeobecného modelu;
• zostavenie zoznamu požadovaných funkcií systému;
• plánovanie práce na každej funkcii;
• návrh funkcie;
• zostrojenie funkcie.

Práca na projekte zahŕňa časté zostavovanie a je rozdelená na iterácie, z ktorých každá je implementovaná pomocou špecifického súboru funkcií.

Vývojári vo FDD sú rozdelení na „triednych majstrov“ a „hlavných programátorov“. Hlavní programátori zapájajú majiteľov tried zapojených do práce na ďalšej nehnuteľnosti. Na porovnanie, XP nemá žiadnu osobnú zodpovednosť za triedy alebo metódy.

Spoločné znaky

Zoznam agilných metodík je v súčasnosti dosť široký. Metodiky, ktoré sme popísali, napriek tomu poskytujú veľmi úplný obraz o celej rodine.

Takmer všetky agilné metodiky používajú iteračný prístup, v ktorom je podrobne naplánované iba obmedzené množstvo práce súvisiace s vydaním nasledujúceho vydania.

Takmer všetky agilné metodiky sú zamerané na najneformálnejší prístup k vývoju. Ak sa problém dá vyriešiť v rámci neformálneho rozhovoru, je lepšie to urobiť. Okrem toho je potrebné vyhotoviť rozhodnutie prijaté vo forme papierového alebo elektronického dokumentu, iba ak sa bez neho nedá zaobísť.

Agilné metodiky

GOST

GOST, podobne ako požiadavky na CMM popísané v nasledujúcej časti, nie sú metodikami. Spravidla nepopisujú samotné procesy vývoja softvéru, ale iba formulujú určité požiadavky na procesy, ktoré do istej miery zodpovedajú rôznym metodikám. Porovnanie požiadaviek podľa rovnakých kritérií, pomocou ktorých porovnávame metodiky, pomôže okamžite určiť, ktoré metodiky by sa mali použiť, ak sa potrebujete vypracovať v súlade s GOST.

V súčasnosti v Rusku platia staré GOST 19. a 34. série a novšia GOST R ISO IEC 122207. GOST 19. a 34. série sú prísne zamerané na kaskádový prístup k vývoju softvéru. Vývoj v súlade s týmito GOST prebieha v etapách, z ktorých každá zahŕňa implementáciu prísne definovaných prác, a končí vydaním pomerne veľkého počtu veľmi formálnych a rozsiahlych dokumentov. Okamžité prísne dodržiavanie týchto noriem teda nielenže vedie k vodopádovému prístupu, ale poskytuje aj veľmi vysoký stupeň formalizácie vývoja.

Požiadavky GOST

GOST 12207, na rozdiel od štandardov 19. a 34. série, popisuje vývoj softvéru ako súbor základných a pomocných procesov, ktoré môžu fungovať od začiatku do konca projektu. Model životného cyklu je možné vybrať na základe charakteristík projektu. Táto GOST teda výslovne nezakazuje používanie iteratívneho prístupu, ale jeho použitie výslovne neodporúča. GOST 12207 je tiež flexibilnejší, pokiaľ ide o požiadavky na formálnosť vývojového procesu. Obsahuje iba pokyny o potrebe zdokumentovať hlavné výsledky všetkých procesov, ale neexistujú žiadne zoznamy požadovaných dokumentov a pokynov týkajúcich sa ich obsahu.

GOST 12207 teda umožňuje iteračný a menej formalizovaný vývoj softvéru.

Vývojové modely zrelosti (CMM, CMMI)

Okrem národných a medzinárodných štandardov existuje niekoľko prístupov k certifikácii procesu vývoja. Najslávnejšie z nich v Rusku sú zrejme CMM a CMMI.

CMM (Capability Maturity Model) je model zrelosti procesu vývoja softvéru, ktorý je určený na posúdenie úrovne zrelosti vývojového procesu v konkrétnej spoločnosti. Podľa tohto modelu existuje päť úrovní vyspelosti vývoja. Prvá úroveň zodpovedá vývoju „ako to dopadne“, keď vývojári idú na každý projekt, ako keby to bol výkon. Druhý zodpovedá viac-menej zabehnutým procesom, kedy sa môžete sebavedomo spoľahnúť na pozitívny výsledok projektu. Tretí zodpovedá prítomnosti rozvinutých a dobre popísaných procesov používaných vo vývoji a štvrtý zodpovedá aktívnemu využívaniu metrík v procese riadenia na stanovovanie cieľov a monitorovanie ich dosahovania. Nakoniec piata úroveň sa týka schopnosti spoločnosti optimalizovať proces podľa potreby.

Požiadavky na CMM a CMMI

Po nástupe CMM sa začali vyvíjať špecializované modely zrelosti na vytváranie informačných systémov, na proces výberu dodávateľov a niektoré ďalšie. Na ich základe bol vyvinutý integrovaný model CMMI (Capability Maturity Model Integration). Okrem toho sa CMMI pokúsilo prekonať nedostatky CMM, ktoré sa v tom čase objavili - zveličenie úlohy formálnych popisov procesov, keď bola dostupnosť určitej dokumentácie hodnotená výrazne vyššia ako len dobre zavedená, ale nie popísaná proces. CMMI sa však zameriava aj na použitie vysoko formalizovaného procesu.

Základom modelov CMM a CMMI je teda formalizácia vývojového procesu. Zameriavajú vývojárov na implementáciu procesu podrobne popísaného v predpisoch a pokynoch, ktorý naopak nemôže vyžadovať vývoj veľkého objemu projektovej dokumentácie na primeranú kontrolu a podávanie správ.

Vzťah CMM a CMMI k iteračnému vývoju je viac nepriamy. Formálne ani jeden, ani druhý nekladie žiadne špecifické požiadavky na dodržiavanie vodopádu alebo iteračný prístup. Podľa niektorých odborníkov je však CMM kompatibilnejší s prístupom k vodopádu, zatiaľ čo CMMI umožňuje aj iteračný prístup.

RUP

RUP je samozrejme iteratívna metodika. Aj keď formálne nie je v RUP nikde uvedená povinnosť dokončiť všetky fázy alebo určitý minimálny počet iterácií, celý prístup je zameraný na skutočnosť, že ich je veľa. Obmedzený počet iterácií bráni RUP v plnom využití jeho výhod. RUP sa dá súčasne použiť aj v takmer vodopádových projektoch, ktoré v skutočnosti zahŕňajú iba niekoľko iterácií: jednu vo fáze vytvárania a druhú vo fáze prenosu. Mimochodom, toto je počet iterácií, ktoré sa skutočne používajú v kaskádových projektoch. Koniec koncov, testovanie a skúšobná prevádzka systému zahŕňa zavedenie opráv, ktoré môžu znamenať určité akcie súvisiace s analýzou, návrhom a vývojom, to znamená, že v skutočnosti sú ďalším prechodom cez všetky fázy vývoja.

Metodika RUP

Pokiaľ ide o formálnosť metodiky, RUP tu predstavuje užívateľovi veľmi široké spektrum možností. Ak dokončíte všetku prácu a úlohy, vytvoríte všetky artefakty a dostatočne formálne (s oficiálnym recenzentom, s prípravou úplnej recenzie vo forme elektronického alebo papierového dokumentu atď.) Vykonáte všetky recenzie, RUP môže byť mimoriadne formálnou a ťažkopádnou metodikou. RUP vám zároveň umožňuje vyvíjať iba tie artefakty a vykonávať iba tie činnosti a úlohy, ktoré sú potrebné pre konkrétny projekt. A vybrané artefakty je možné vykonávať a kontrolovať s akýmkoľvek stupňom formality. Môžete požadovať podrobnú štúdiu a starostlivý návrh každého dokumentu, poskytnutie rovnako starostlivo vykonaného a vykonaného preskúmania a dokonca podľa starej praxe každé takéto preskúmanie schváliť na vedecko -technickej rade podniku. Alebo sa môžete obmedziť na e -mail alebo skicu na papieri. Okrem toho je tu vždy ešte jedna príležitosť: vytvoriť si v hlave dokument, to znamená premyslieť si príslušnú otázku a urobiť konštruktívne rozhodnutie. A ak sa toto rozhodnutie týka iba vás, obmedzte sa napríklad na komentár v programovom kóde.

RUP je teda iteratívna metodika s veľmi širokým rozsahom možné riešenia z hľadiska formalizácie procesu vývoja.

Zhrňme si výsledky druhej časti článku. RUP, na rozdiel od väčšiny ostatných metodík, vám umožňuje zvoliť si stupeň formalizácie a iterácie vývojového procesu v širokom rozsahu, v závislosti od charakteristík projektov a rozvíjajúcej sa organizácie.

A prečo je to také dôležité - budeme diskutovať v ďalšej časti.