Prístupy k vývoju softvéru. Štruktúrovaný prístup k vývoju softvéru. Princípy a význam agilného rozvoja

1.Kódovanie

Vo fáze vývoja softvéru sa vykonávajú tieto hlavné činnosti: kódovanie; testovanie; vývoj systému pomoci PP; tvorba užívateľskej dokumentácie; vytvorenie verzie a inštalácia softvéru,

Kódovanie je proces konverzie výsledkov návrhu na vysokej a nízkej úrovni do hotového softvérového produktu. Inými slovami, pri kódovaní je zostavený softvérový model opísaný pomocou zvoleného programovacieho jazyka, ktorým môže byť ktorýkoľvek z existujúcich jazykov. Voľba jazyka sa vykonáva buď na žiadosť zákazníka, alebo s prihliadnutím na riešený problém a osobná skúsenosť vývojárov.

Pri kódovaní sa musíte riadiť štandardom pre vybraný jazyk, napríklad pre jazyk C je to ANSI C a pre C++ je to ISO/IEC 14882 “Standard for the C++ ProgrammingLanguage”.

Okrem všeobecne akceptovaného štandardu pre programovací jazyk môže spoločnosť vyvinúť aj svoje vlastné dodatočné požiadavky na pravidlá pre písanie programov. Týkajú sa najmä pravidiel pre formátovanie textu programu.

Dodržiavanie štandardných a firemných pravidiel umožňuje vytvoriť program, ktorý funguje správne, je ľahko čitateľný a zrozumiteľný pre ostatných vývojárov, obsahuje informácie o vývojárovi, dátume vytvorenia, názve a účele, ako aj potrebné údaje pre správu konfigurácie.

Vo fáze kódovania programátor píše programy a sám ich testuje. Tento typ testovania sa nazýva testovanie jednotiek. Všetky otázky súvisiace s testovaním softvéru sú popísané v kapitole. 10, je tu opísaná aj testovacia technológia, ktorá sa používa vo fáze vývoja softvéru. Táto technológia sa nazýva testovanie "sklenený box" (sklenený box); niekedy sa tomu hovorí aj testovanie "biely box" (whitebox) na rozdiel od klasického konceptu „čiernej skrinky“.

Pri testovaní čiernej skrinky sa s programom zaobchádza ako s objektom, ktorého vnútorná štruktúra je neznáma. Tester zadáva údaje a analyzuje výsledok, ale nevie, ako presne program funguje. Pri výbere testov špecialista hľadá vstupné údaje a podmienky, ktoré sú z jeho pohľadu zaujímavé, čo môže viesť k neštandardným výsledkom. Primárne ho zaujímajú tí zástupcovia každej triedy vstupných údajov, v ktorých sa s najväčšou pravdepodobnosťou vyskytnú chyby v testovanom programe.

Pri testovaní „skleneného boxu“ je situácia úplne iná. Tester (v tomto prípade sám programátor) vyvíja testy na základe znalosti zdrojového kódu, ku ktorému má prístup plný prístup. V dôsledku toho získa nasledujúce výhody.

1. Smer skúšania. Programátor môže testovať program po častiach, vyvíjať špeciálne testovacie podprogramy, ktoré volajú testovaný modul a prenášajú do neho dáta, ktoré programátora zaujíma. Je oveľa jednoduchšie otestovať samostatný modul ako „sklenený box“.

2.Úplné pokrytie kódu. Programátor môže vždy určiť, ktoré fragmenty kódu fungujú v každom teste. Vidí, ktoré ďalšie vetvy kódu zostávajú netestované a môže si vybrať podmienky, za ktorých sa budú testovať. Nižšie popisujeme, ako sledovať stupeň pokrytia kódom vykonaných testov.

3. Schopnosť kontrolovať tok príkazov. Programátor vždy vie, ktorá funkcia má byť v programe vykonaná ako ďalšia a aký má byť jej aktuálny stav. Ak chcete zistiť, či program funguje tak, ako si myslí, môže programátor zahrnúť ladiace príkazy, ktoré zobrazujú informácie o jeho vykonávaní, alebo na to použiť špeciálny program. softvér nazývaný debugger. Debugger môže robiť veľa užitočných vecí: monitorovať a meniť postupnosť vykonávania príkazov programu, zobrazovať obsah svojich premenných a ich adresy v pamäti atď.

4. Schopnosť monitorovať integritu údajov. Programátor vie, ktorá časť programu by mala zmeniť každý dátový prvok. Sledovaním stavu dát (pomocou rovnakého debuggera) dokáže identifikovať chyby, ako sú zmeny dát nesprávnymi modulmi, ich nesprávna interpretácia, či neúspešná organizácia.Programátor môže testovanie sám automatizovať.

5.Vízia vnútorných hraničných bodov. IN zdrojový kód tie hraničné body programu, ktoré sú skryté z vonkajšieho pohľadu, sú viditeľné. Napríklad na vykonanie určitej akcie možno použiť niekoľko úplne odlišných algoritmov a bez nahliadnutia do kódu nie je možné určiť, ktorý z nich si programátor vybral. Ďalším bežným príkladom by bol problém s pretečením vo vyrovnávacej pamäti používanej na dočasné ukladanie vstupných údajov. Programátor vie okamžite povedať, pri akom množstve dát pretečie vyrovnávacia pamäť a nemusí robiť tisíce testov.

6. Možnosť testovania podľa zvoleného algoritmu. Testovanie spracovania údajov, ktoré využíva veľmi zložité výpočtové algoritmy, môže vyžadovať špeciálne technológie. Medzi klasické príklady patrí transformácia matíc a triedenie údajov. Tester, na rozdiel od programátora, potrebuje presne vedieť, aké algoritmy sa používajú, preto sa musí obrátiť na odbornú literatúru.

Testovanie sklenenej skrinky je súčasťou procesu programovania. Programátori túto prácu robia stále, každý modul testujú po jeho napísaní a potom znova po jeho integrácii do systému.

Pri testovaní jednotiek môžete použiť technológiu štrukturálneho alebo funkčného testovania alebo oboje.

Štrukturálne testovanie je typ testovania sklenených boxov. Jeho hlavnou myšlienkou je správny výber softvérovej cesty, ktorá sa má testovať. Na rozdiel od neho funkčné testovanie patrí do kategórie testovania čiernej skrinky. Každá funkcia programu je testovaná zadaním jej vstupných údajov a analýzou jej výstupu. Zároveň sa veľmi zriedka berie do úvahy vnútorná štruktúra programu.

Hoci štrukturálne testovanie je oveľa výkonnejšie teoretický základ, väčšina testerov preferuje funkčné testovanie. Štrukturálne testovanie je vhodnejšie pre matematické modelovanie, ale to neznamená, že je efektívnejšie. Každá technológia vám umožňuje identifikovať chyby vynechané pri použití tej druhej. Z tohto hľadiska ich možno nazvať rovnako účinnými.

Predmetom testovania môže byť nielen plná cesta program (postupnosť príkazov, ktoré vykonáva od začiatku do konca), ale aj jeho jednotlivé časti. Je absolútne nereálne testovať všetky možné spôsoby spustenia programu. Špecialisti na testovanie preto zo všetkých možných ciest identifikujú tie skupiny, ktoré je bezpodmienečne potrebné otestovať. Na výber používajú špeciálne kritériá tzv kritériá pokrytia (coveragecriteria), ktoré určujú veľmi reálny (aj keď dosť veľký) počet testov. Tieto kritériá sa niekedy nazývajú logické kritériá pokrytia, alebo kritériá úplnosti.

3. Vývoj systému pomoci softvérový produkt. Vytváranie užívateľskej dokumentácie

Je vhodné určiť jedného z projektových zamestnancov technickým redaktorom dokumentácie. Tento zamestnanec môže vykonávať aj inú prácu, ale jeho hlavnou úlohou by mala byť analýza dokumentácie, aj keď ju vypracovávajú aj iní zamestnanci.

Často sa stáva, že na tvorbe softvéru pracuje viacero ľudí, no nikto z nich nenesie plnú zodpovednosť za jeho kvalitu. V dôsledku toho softvér nielenže neťaží z toho, že ho vyvíja viac ľudí, ale aj stráca, keďže každý podvedome presúva zodpovednosť na druhého a očakáva, že tú či onú časť práce urobia jeho kolegovia. Tento problém sa rieši menovaním redaktora, ktorý nesie plnú zodpovednosť za kvalitu a správnosť technickej dokumentácie.

Systém pomoci PP je vytvorený na základe materiálu vyvinutého pre používateľskú príručku. Tvorí a vytvára ho osoba zodpovedná za vykonávanie tejto práce. Môže to byť buď technický editor, alebo jeden z vývojárov spolu s technickým editorom.

Dobre zdokumentovaný PP má nasledujúce výhody.

1. Jednoduché použitie. Ak je softvér dobre zdokumentovaný, potom je oveľa jednoduchšie ho aplikovať. Používatelia sa to učia rýchlejšie, robia menej chýb a vďaka tomu robia svoju prácu rýchlejšie a efektívnejšie.

2. Nižšie náklady technická podpora. Keď používateľ nevie prísť na to, ako vykonať úkony, ktoré potrebuje, zavolá službu technickej podpory výrobcu PCB. Prevádzka takejto služby je veľmi drahá. Dobrá príručka pomáha používateľom riešiť problémy samostatne a znižuje potrebu kontaktovať tím technickej podpory.

3. Vysoká spoľahlivosť. Nezrozumiteľná alebo nedbalá dokumentácia spôsobuje, že softvér je menej spoľahlivý, pretože jeho používatelia sa častejšie dopúšťajú chýb a je pre nich ťažké pochopiť, čo ich spôsobilo a ako sa vysporiadať s ich následkami.

Jednoduchosť údržby. Obrovské množstvo peňazí a času sa vynakladá na analýzu problémov, ktoré sú spôsobené chybami používateľov. Zmeny vykonané v nových vydaniach softvéru sú často len zmenami rozhrania starých funkcií. Sú predstavené preto, aby používatelia konečne prišli na to, ako softvér používať a prestali volať technickú podporu. Dobrý manažment do značnej miery

Informatika, kybernetika a programovanie

Iterácia N Jednotný vývojový proces softvér USDP Use Case Model popisuje prípady, v ktorých bude aplikácia použitá. Analytický model popisuje základné triedy pre aplikáciu. Návrhový model popisuje prepojenia a vzťahy medzi triedami a vyhradenými objektmi.Nasadzovací model popisuje distribúciu softvéru medzi počítačmi.

Lekcia č.20
Všeobecné princípy a prístupy k vývoju softvéru

Modely vývoja softvéru

1. Vodopadnaja
2. Kaskádový model
3. Špirála
4. Extrémne programovanie
5. Prírastkové
6. Metodológia Lekárov bez hraníc

Model vodopádu

Špirálový model

Postupný 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

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

1. Model prípadov použitia popisuje prípady, v ktorých bude aplikácia použitá.
2. Analytický model popisuje základné triedy pre aplikáciu.
3. Návrhový model popisuje prepojenia 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ôznych testovacích prípadov.

Metodológia Lekárov bez hraníc

Typické komponenty architektúry softvérových produktov a typické softvérové ​​požiadavky

odolnosť proti chybámsúbor vlastností systému, ktorý zvyšuje jeho spoľahlivosť detekciou chýb, obnovou a lokalizáciou zlých následkov pre systém. Pri návrhu akéhokoľvek reálneho systému na zabezpečenie odolnosti voči poruchám je potrebné zabezpečiť všetky možné situácie, ktoré môžu viesť k zlyhaniu systému a vyvinúť mechanizmy na zvládanie porúch.

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

Odmietnutie toto je systémový prechodv dôsledku chyby do úplne nefunkčného stavu.

Zrútiť sa chyba v prevádzke systému, ktorá nevedie k zlyhaniu systému.

Čím menej porúch a porúch počas určitého časového obdobia, tým je systém považovaný za spoľahlivejší.

Rovnako ako ďalšie diela, ktoré by vás mohli zaujímať
57355.		Rozmanitosť organických zlúčenín, ich klasifikácia. Organické látky živej prírody	48,5 kB
	Rozmanitosť organických zlúčenín je daná jedinečnou schopnosťou atómov uhlíka spájať sa navzájom jednoduchými a viacnásobnými väzbami za vzniku zlúčenín s takmer neobmedzeným počtom atómov spojených do reťazcov: cykly, bicykle, trojkolky, polycykly, kostry 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 poznámku pre 2. Uložte dokument do vlastného priečinka pod názvom Poznámka.
57361.		Číslo a obrázok 3. Zarovnanie čísel na hraniciach 3. Písanie čísel 3. Zarovnanie počtu predmetov	35,5 kB
	Koľko je stvorení Kto je prvý Kto je posledný Kto je číslo 1 Kto je číslo 2 Vymenujte susedov ježka. Kto je pravoruká veverička Kto je ľavoruká žirafa Kto je najväčší Kto je najmenší Kto stojí uprostred tvorov Gra Show me, nezmiluj sa.

Dnes v softvérovom inžinierstve existujú dva hlavné prístupy k vývoju softvéru EIS, medzi ktorými je zásadný rozdiel spôsobený rôzne cesty rozklad systémov. Prvý prístup sa nazýva funkčno-modulárny alebo štrukturálny. Je založená na princípe funkčnej dekompozície, pri ktorej je popísaná štruktúra systému z hľadiska hierarchie jeho funkcií a prenosu informácií medzi jednotlivými funkčné prvky. Druhý, objektovo orientovaný prístup využíva rozklad objektov. V tomto prípade je štruktúra systému popísaná z hľadiska objektov a spojení medzi nimi a správanie systému je opísané z hľadiska výmeny správ medzi objektmi.

Podstata štrukturálneho prístupu k vývoju softvéru EIS teda spočíva v jeho rozklade (rozpade) na automatizované funkcie: systém je rozdelený na funkčné podsystémy, ktoré sa zase delia na podfunkcie, tie na úlohy atď. špecifické postupy. Automatizovaný systém si zároveň zachováva holistický pohľad, v ktorom sú všetky komponenty prepojené. Pri vývoji systému „zdola nahor“ sa od jednotlivých úloh až po celý systém stráca celistvosť, vznikajú problémy pri popisovaní informačná interakcia jednotlivé zložky.

Všetky najbežnejšie metódy štrukturálneho prístupu sú založené na množstve všeobecných princípov. Základné princípy sú:

princíp „rozdeľuj a panuj“ (pozri pododdiel 2.1.1);

princíp hierarchického usporiadania je princíp organizovania komponentov systému do hierarchických stromových štruktúr s pridávaním nových detailov na každej úrovni.

Vyzdvihnutie dvoch základných princípov neznamená, že zostávajúce princípy sú druhoradé, keďž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 princípov sú:

princíp abstrakcie – zvýraznenie podstatných aspektov systému a abstrahovanie od nedôležitého;

princíp konzistencie - platnosť a konzistentnosť prvkov systému;

princíp štruktúrovania údajov – údaje musia byť štruktúrované a hierarchicky usporiadané.

Štrukturálny prístup využíva najmä dve skupiny nástrojov, ktoré popisujú funkčnú štruktúru systému a vzťahy medzi dátami. Každá skupina nástrojov zodpovedá určitým typom modelov (diagramov), z ktorých najbežnejšie sú:

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

SADT (Structured Analysis and Design Technique - metóda konštrukčnej analýzy a návrhu) - modely a zodpovedajúce funkčné diagramy;

ERD (Entity-Relationship Diagrams) - entitno-relačné diagramy.

Diagramy toku údajov a diagramy vzťahov medzi entitami sú najčastejšie používané typy modelov v nástrojoch CASE.

Špecifický pohľad uvedených diagramov a interpretácia ich návrhov závisí 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 odrážajú existujúcu a navrhovanú štruktúru podnikových procesov organizácie a interakciu medzi nimi ( použitie modelov SADT sa spravidla obmedzuje iba na túto fázu, pretože pôvodne neboli určené na návrh softvéru). Pomocou ERD sa vykonáva popis údajov používaných v organizácii na koncepčnej úrovni, nezávisle od nástrojov implementácie databáz (DBMS).

Vo fáze návrhu sa DFD používajú na popis štruktúry navrhnutého softvérového systému a možno ich spresniť, rozšíriť a doplniť o nové návrhy. Podobne sú ERD spresnené a doplnené o nové konštrukty, ktoré popisujú reprezentáciu údajov na logickej úrovni vhodnej pre následné generovanie databázovej schémy. Tieto modely môžu byť doplnené o diagramy odrážajúce architektúru softvérového systému, programové blokové diagramy, hierarchiu obrazovkové formuláre a menu atď.

Uvedené modely spolu poskytujú úplný popis softvéru EIS bez ohľadu na to, či ide o systém existujúci alebo novo vyvinutý. Zloženie diagramov v každom konkrétnom prípade závisí od zložitosti systému a požadovanej úplnosti jeho popisu.

Predmetom väčšiny príkladov diagramov uvedených v tejto kapitole je daňový systém Ruskej federácie, ktorého najúplnejší popis je obsiahnutý v daňovom zákonníku Ruskej federácie. Informačné technológie, používané v daňovom systéme Ruskej federácie, majú určité vlastnosti.

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

Všetky najbežnejšie metódy štrukturálneho prístupu sú založené na niekoľkých všeobecných princípoch:

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

2. Princíp hierarchického usporiadania je princíp organizovania komponentov systému do hierarchických stromových štruktúr s pridávaním nových detailov na každej úrovni.

Izolácia dvoch základných princípov neznamená, že zostávajúce princípy 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 princípov sú:

1. Princíp abstrakcie – vyzdvihovanie podstatných aspektov systému a abstrahovanie od nedôležitého.

2. Princíp konzistentnosti, platnosti a konzistentnosti prvkov systému.

3. Princíp štruktúrovania dáta - dáta musia byť štruktúrované a hierarchicky usporiadané.

V štrukturálnom prístupe existujú najmä dve skupiny nástrojov, ktoré popisujú funkčnú štruktúru systému a vzťahy medzi dátami. Každá skupina nástrojov zodpovedá určitým typom modelov (diagramov), z ktorých najbežnejšie sú:

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

· SADT (Structured Analysis and Design Technique - metodológia štrukturálnej analýzy a návrhu) - modely a zodpovedajúce funkčné diagramy: zápisy IDEF0 (funkčné modelovanie systémov), IDEF1х (konceptuálne modelovanie databáz), IDEF3х (konštrukcia systémov na hodnotenie kvality dielo objektu; grafický popis tok procesov, interakcia procesov a objektov, ktoré sa týmito procesmi menia);

· ERD (Entity - Relationship Diagrams) - entitno-relačné diagramy.

Takmer všetky metódy štrukturálneho prístupu (štrukturálna analýza) v štádiu formovania softvérových požiadaviek využívajú dve skupiny modelovacích nástrojov:

1. Diagramy znázorňujúce funkcie, ktoré musí 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 podoba uvedených diagramov a interpretácia ich návrhov závisí 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 odrážajú existujúcu a navrhovanú štruktúru podnikových procesov organizácie a interakciu medzi nimi ( použitie modelov SADT sa zvyčajne obmedzuje iba na túto fázu, pretože pôvodne neboli určené na návrh softvéru). Pomocou ERD sa vykonáva popis údajov používaných v organizácii na koncepčnej úrovni bez ohľadu na nástroje implementácie databázy (DBMS).

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

2. Životný cyklus programu. Cyklický charakter vývoja. Základné pojmy programovacej techniky. 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. Vývojový diagram požiadaviek. Riadenie požiadaviek.

4. Architektonický a detailný návrh. Implementácia a kódovanie. Testovanie a overovanie. Proces kontroly kvality. Metódy bielej skrinky a čiernej skrinky. Kontroly a recenzie. Testovacie ciele. 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 prírastkové modely. Flexibilné modely procesov vývoja.

6. Konštrukcia procesného modelu. Identifikujte požiadavky na proces. Použité fázy, míľniky a artefakty. Výber architektúry procesu. Postup pri realizácii štandardného projektu. Zdokumentované postupy.

7. Modely vývojových tímov. Kolektívny charakter vývoja. Optimálna veľkosť tímu. Podriadenosť účastníkov projektu. Rozvoj tímu a rozvoj zamestnancov. Špecializácia, spolupráca a interakcia.

8. Modely vývojových tímov. Hierarchický tímový model. Metóda chirurgického tímu. Model rovesníckeho tímu.

9. Povaha programovania. Veda o programovaní. Umenie programovania. Programátorské remeslo. Programovacie paradigmy. Štruktúrované programovanie. Logické programovanie. Objektovo orientované programovanie.

10. Architektúra softvéru. Manažment podujatí. Architektúra klient/server. Služby. Trojvrstvová architektúra. Dizajn programu. Koncepčný návrh. Logický dizajn. Detailný dizajn.

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

2. Extrémne programovanie. – Petrohrad: Peter, 2002.

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

4. Brooks Jr. sú navrhnuté a vytvorené softvérové ​​systémy. M.: Nauka, 1975; nové vydanie prekladu: The Mythical Man-Month. SPb.: SYMBOL+, 1999.

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

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

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

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

9. Technológie vývoja softvéru. – Petrohrad: Peter, 2002.

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

11. Rambo J. Jednotný proces vývoja softvéru. Petrohrad: Peter, 2002.

Ekonomická teória pre manažérov

Základné mikroekonomické teórie. Príklady aplikácie pri analýze ekonomických procesov. Základné makroekonomické teórie. Príklady aplikácie pri analýze ekonomických procesov. Princípy a metódy riadenia ekonomických procesov. Nástroje hodnotenia ú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. Vyhladenie cyklických výkyvov. Úloha multiplikátora a akcelerátora pri hodnotení tempa ekonomického rozvoja. Produkčné funkcie v ekonomike. Príklady aplikácie pri analýze ekonomických procesov. Zisk. Výpočet ukazovateľov ovplyvňujúcich zisk, grafický obrázok bod zlomu. Metodika implementácie investičnej politiky.

Kurz ekonomickej teórie: učebnica pre vysoké školy / Ed. . –Kirov: „ASA“, 2004. Kolemaev - matematické modelovanie. Modelovanie makroekonomických procesov a systémov: učebnica. M.: UNITY-DANA, 2005. Bažinská kybernetika. Charkov: Consul, 2004. Leushin workshop o metódach matematického modelovania: učebnica. Štát Nižný Novgorod tech. univ.- N. Novorod, 2007. Politici 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. Evolúcia mini-ekonomických inštitúcií. Ekonomický inštitút, Uralská pobočka Ruskej akadémie vied, - M.: Nauka, 2007.

Technológie pre rozvoj a manažérske rozhodovanie [N]

Rozhodovanie ako základ činnosti manažéra. Úvod do teórie rozhodovania. Základné pojmy teórie rozhodovania. Modely riadenia podniku a ich vplyv na rozhodovanie. Rôzne spôsoby klasifikácia riešení. Klasifikácie: podľa stupňa formálnosti, podľa stupňa rutinnosti, podľa frekvencie, podľa naliehavosti, podľa stupňa dosiahnutia cieľov, podľa spôsobu výberu alternatívy. Základné metódy rozhodovania. Vôľové metódy rozhodovania. Ciele rozhodovania. Čas pri hľadaní riešení. Základné chyby Matematické metódy rozhodovania. Matematické aspekty teórie rozhodovania. Operačný výskum. Matematický prístup k rozhodovaniu. Rozhodovací strom. Modely rozvoja a rozhodovania. Herná teória. Matematické metódy rozhodovania. Matematické aspekty teórie rozhodovania. Modely teórie radenia. Modely riadenia zásob. Model lineárneho programovania. Dopravné úlohy. Simulačné modelovanie. Sieťová analýza. Ekonomická analýza. Obmedzenia racionálnych modelov. Vlastnosti rozvoja a rozhodovania v skupine. Metóda na určenie skupinovej kohézie na základe stupňa konektivity súborov. Metódy kolektívneho rozhodovania. Metóda konsenzu. Spôsoby hlasovania. Kreatívne metódy rozhodovania. Brainstorming. Konferencia myšlienok. Lodná rada. De Bonova metóda „mysliacich klobúkov“. Teória invenčného riešenia problémov (TRIZ). Dokonalé konečné riešenie. Príklady problémov a ich riešenia pomocou TRIZ. Aplikácia metód TRIZ pri jedinečných a kreatívnych rozhodnutiach. Metódy rozvoja nápadov na riešenia a ich prispôsobenia situácii. Model stromu cieľov. Stratégia koordinácie záujmov. Tvorba rozhodnutí na koordináciu záujmov. Metódy určovania záujmov protistrán. Systémy na podporu rozhodovania (expertné systémy). História vzniku rozhodovacích systémov. Klasifikácia rozhodovacích systémov. Typická štruktúra expertný systém. Metódy prezentácie vedomostí. Metódy logického vyvodzovania. 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í. Návod. - M.: MarT, 2005. - 496 s. Vývoj manažérskych rozhodnutí - M.: Vydavateľstvo "Delo", 2004 - 392 s. G. Odborné posudky a rozhodovanie - M.: Patent, 1996. - 271 s. Taha // Úvod do operačného výskumu = Operačný výskum: Úvod. - 7. vyd. - M.: "Williams", 2007. - S. 549-594. G. Theil. Ekonomické prognózy a rozhodovanie. M.: „Progress“ 1970. K. D. Lewis. Metódy prognózovania ekonomických ukazovateľov. M.: „Financie a štatistika“ 1986. G. S. Kildišev, A. A. Frenkel. Analýza a prognóza časových radov. M.: „Statistics“ 1973. O. Kim, C. W. Muller, U. R. Klekka a ďalší Faktorová, diskriminačná a zhluková analýza. M.: „Financie a štatistika“ 1989. Efektívny manažér. Kniha 3. Rozhodovanie. – MIM LINK, 1999 Turevsky a manažment podniku motorovej dopravy. - M.: Vyššia škola, 2005. , ; upravil . Systémová analýza v manažmente: tutoriál. – M.: Financie a štatistika, 2006. , Tinkov: učebnica. – M.: KNORUS, 2006.

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

Podľa akých princípov sa rozlišujú obchodné procesy? Aký je problém holistického popisu obchodných procesov? Čo je to systém, aké má vlastnosti? Úloha systémovej analýzy v modelovaní podnikových procesov? Proces ako objekt kontroly. Procesné prostredie. Základné prvky obchodného procesu. Výhody a nevýhody funkčného a procesného riadenia. cyklus riadenia PDCA. Etapy cyklu riadenia procesov. Cyklus PDCA a implementácia požiadaviek ISO 9001:2008. Metodika SADT (Structured Analysis and Design Technique - metóda statickej analýzy a návrhu). Esencia. Základné ustanovenia. Ako je funkčný model činnosti reprezentovaný v metodike IDEF0? Čo znamenajú činnosti vo funkčných modelových diagramoch, ako sa zobrazujú podľa metodiky IDEF0? Na čo slúžia šípky v diagramoch funkčných modelov, aké sú ich typy a typy? metodika DFD. Esencia. Základné komponenty DFD diagramov. Aké sú vlastnosti DFD diagramov a čo je v nich popísané? Aké sú vlastnosti objektov diagramu DFD? Čo znamenajú šípky na diagrame DFD? IDEF3 metodika. Esencia. Dokumentačné a modelovacie nástroje. Aké sú vlastnosti diagramov IDEF3 a čo je v nich popísané? Aké sú vlastnosti objektov diagramu IDEF3? A strelec? Klasifikácia procesov. Typické obchodné procesy. Reengineering a jeho technológia. Kedy je vhodné použiť reengineering pri riadení firmy? Monitorovanie a meranie procesov. Ukazovatele organizačných procesov. Numerické a ratingové hodnotenia procesov.

"Modelovanie obchodných procesov pomocou AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Vytváranie informačných systémov pomocou AllFusion Modeling Suite" ed. "Dialog-MEPhI" 2003 "Prax funkčného modelovania s AllFusion Process Modeler 4.1. (BPwin) Kde? Prečo? Ako?" vyd. "Dialogue-MEPhI" 2004 Dubeykovsky modelovanie s AllFusion Process Modeler (BPwin). vyd. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Metodológia štrukturálnej analýzy a navrhovania SADT" 1993 klasická práca na metodike SADT. Cheremnychova analýza systémov: IDEF-technológie, Modelovanie a analýza systémov. IDEF technológie. Dielňa. M.: Finance and Statistics, 2001. “Štrukturálne obchodné modely: DFD technológie” http://www. /Level4.asp? ItemId=5810 "Teória a prax reorganizácie podnikových procesov" 2003/ P50.1.. Metodika funkčného modelovania. M.: Gosstandart Ruska, 2000. http://www. IDEF0, IDEF3, DFD http://www. Modelovanie obchodný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 efektívnosti softvérových produktov

1. IT architektúra

2. Oblasti procesov riadenia.

3. Zoznam procesov v doméne Plánovanie a organizácia

4. Zoznam doménových procesov Acquisition and Implementation

5. Zoznam procesov v doméne Prevádzka a údržba

6. Zoznam procesov v doméne Monitorovanie a hodnotenie

7. Charakteristika úrovní modelu zrelosti procesu

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

1. 10. Všeobecné IT kontroly a aplikačné kontroly. Oblasti zodpovednosti a zodpovednosti obchodu a IT.

Ruské vydanie Cobit 4.1.

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

1. Vymenujte duševné práva k výsledkom duševnej činnosti a zverejnite ich obsah.

2. Uveďte typy dohôd o nakladaní s výhradnými právami. Opíšte každú z týchto dohôd o nakladaní s výhradnými právami.

4. Popíšte hlavné ustanovenia právnej ochrany Počítačového programu ako predmetu autorského práva.

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

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

7. Rozšíriť obsah kritérií patentovateľnosti pre vynález: novosť; vynálezcovský krok; priemyselná využiteľnosť.

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

9. Definujte „know-how“ a uveďte podmienky, pri ktorých vzniku vzniká a je vykonávaná právna ochrana výrobného tajomstva.

10. Vymenujte chránené prostriedky individualizácie a uveďte ich porovnávacie charakteristiky.

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

2., Právo duševného vlastníctva, učebnica // M, RIOR, 2009.

Riadenie vývoja projektov a softvéru [I]

Čo je metodika, prečo je potrebná. Všeobecná štruktúra metodiky, hlavné prvky metodiky. Zásady pre návrh vlastnej metodiky. Príklady rôznych artefaktov, rolí, kompetencií, okrajových podmienok. Štruktúra metodiky podľa Cowburna, metodologické metriky. Kritériá dizajnu Cowburn. Kritériá výberu metodiky, Cowburnova matica. Životný cyklus projektu. Vodopád a iteračné modely životného cyklu. Limity použiteľnosti pre vodopádové a iteračné modely. RUP ako príklad iteratívnej metodológie. Základné pojmy RUP, limity použiteľnosti. Úloha človeka pri vývoji softvéru. Agilné metodiky, základné princípy agilných metodík. Dôvod vzniku flexibilných metodík. Scrum ako príklad flexibilnej metodológie. Roly, artefakty, aktivity v Scrume. Limity použiteľnosti scrumu. Extrémne programovanie (XP) Myšlienky, hodnoty, základné postupy, limity použiteľnosti. Podobnosti a rozdiely medzi Scrum a XP. Zber a riadenie požiadaviek. Základné postupy, pojmy, princípy. Prístupy k dokumentovaniu projektu a produktu, 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, riadenie rizík, obľúbené riziká. Príklady postupov plánovania rozvoja z metodík diskutovaných v kurze. Testovanie pri vývoji softvéru. Koncepcia montáže (zostavenia) softvérového produktu. Základné metódy testovania, pojmy. Príklady testovacích postupov z metodík diskutovaných v kurze. Pojem zostavy (build), spôsoby ukladania kódu, nástroje. Dva princípy organizácie práce so systémom správy verzií. Vlastnosti procesu uvoľnenia/zobrazenia produktu pre rôzne kategórie produktov, príklady postupov. Moderné koncepty softvérovej architektúry, viacúrovňové architektúry, kritériá architektúry. Zoznam nevyhnutných rozhodnutí pri návrhu softvéru, prístupy k výberu systému na ukladanie dát.

Kent Beck – Extrémne programovanie Frederick Brooks – Mesiac mýtického človeka alebo ako vznikajú softvérové ​​systémy. Tom DeMarco – 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 Cowburn – Každý projekt má svoju vlastnú metodiku. Alistair Cowburn - Ľudia ako nelineárne a najdôležitejšie komponenty pri tvorbe softvéru. Andriy Orlov - Poznámky automatizačného inžiniera. Profesionálne priznanie. Philipp Kratchen - Úvod do racionálneho jednotného procesu. Henrik Kniberg - Scrum a XP: poznámky z predných línií. Prezentácie prednášok o kurze