Szoftverfejlesztési megközelítések. A szoftverfejlesztés strukturált megközelítése. Az agilis fejlesztés alapelvei és jelentése

1.Kódolás

A szoftverfejlesztési szakaszban a következő fő műveleteket hajtják végre: kódolás; tesztelés; PP segítő rendszer kialakítása; felhasználói dokumentáció készítése; a szoftver verziójának elkészítése és telepítése,

A kódolás az a folyamat, amelynek során a magas és alacsony szintű tervezési eredményeket kész szoftvertermékké alakítják. Vagyis kódoláskor a lefordított szoftvermodellt a választott programozási nyelv segítségével írják le, amely lehet bármelyik létező nyelv. A nyelvválasztást vagy az ügyfél kérésére, vagy a megoldandó probléma figyelembevételével és személyes tapasztalat fejlesztők.

A kódolás során a kiválasztott nyelvre vonatkozó szabványt kell követni, például a C nyelv esetében ez ANSI C, C++ esetén pedig az ISO/IEC 14882 „Standard for the C++ ProgrammingLanguage”.

A programozási nyelvekre általánosan elfogadott szabványon túlmenően a vállalat saját kiegészítő követelményeket is kidolgozhat a programírás szabályaira vonatkozóan. Főleg a programszöveg formázására vonatkozó szabályokat érintik.

A szabvány és a céges szabályok betartása lehetővé teszi, hogy megfelelően működő, jól olvasható, más fejlesztők számára is érthető programot készítsünk, amely tartalmazza a fejlesztőre vonatkozó információkat, a létrehozás dátumát, nevét és célját, valamint a konfigurációkezeléshez szükséges adatokat.

A kódolási szakaszban a programozó programokat ír és maga teszteli azokat. Az ilyen típusú tesztelést egységtesztnek nevezik. A szoftverteszttel kapcsolatos összes kérdést a fejezet tárgyalja. 10. ábra, a szoftverfejlesztési szakaszban használt tesztelési technológia leírása is itt található. Ezt a technológiát tesztelésnek nevezik "üvegdoboz" (üvegdoboz); néha tesztelésnek is nevezik "fehér doboz" (fehér doboz) szemben a „fekete doboz” klasszikus fogalmával.

A fekete doboz tesztelés során a programot olyan objektumként kezelik, amelynek belső szerkezete ismeretlen. A tesztelő beír adatokat és elemzi az eredményt, de nem tudja pontosan, hogyan működik a program. A tesztek kiválasztásakor a szakember a számára érdekes bemeneti adatokat, feltételeket keres, amelyek nem szabványos eredményekhez vezethetnek. Elsősorban az egyes bemeneti adatosztályok képviselői érdeklik, amelyekben a legnagyobb valószínűséggel fordulnak elő hibák a tesztelt programban.

Az „üvegdoboz” tesztelésekor a helyzet teljesen más. A tesztelő (jelen esetben maga a programozó) teszteket fejleszt azon forráskód ismerete alapján, amelyhez hozzáfér. teljes hozzáférés. Ennek eredményeként a következő juttatásokban részesül.

1. A tesztelés iránya. A programozó részenként tesztelheti a programot, speciális teszt szubrutinokat fejleszthet, amelyek meghívják a tesztelt modult, és továbbítják rá a programozót érdeklő adatokat. Sokkal egyszerűbb egy külön modult „üvegdobozként” tesztelni.

2. Teljes kód lefedettség. A programozó mindig meg tudja határozni, hogy az egyes tesztekben mely kódrészletek működnek. Látja, hogy a kód mely további ágai maradnak teszteletlenek, és kiválaszthatja, hogy milyen feltételek mellett kerüljön tesztelésre. Az alábbiakban leírjuk, hogyan követhető nyomon az elvégzett tesztek kódlefedettségének mértéke.

3. Képes irányítani a parancsok áramlását. A programozó mindig tudja, hogy melyik függvényt kell legközelebb végrehajtani a programban, és milyen állapotban kell lennie. Annak megállapítására, hogy egy program úgy működik-e, ahogy gondolja, a programozó beiktathat olyan hibakereső parancsokat, amelyek információkat jelenítenek meg a végrehajtásáról, vagy egy speciális programot használhat erre. szoftver debuggernek hívják. A hibakereső sok hasznos dolgot tud végezni: figyeli és módosítja a programparancsok végrehajtási sorrendjét, megjeleníti a változói tartalmát és azok címét a memóriában stb.

4. Az adatok integritásának ellenőrzése. A programozó tudja, hogy a program mely részének módosítania kell az egyes adatelemeket. Az adatok állapotának figyelésével (ugyanazon hibakereső használatával) képes azonosítani a hibákat, például a nem megfelelő modulok által megváltoztatott adatokat, azok helytelen értelmezését, vagy a sikertelen szervezést A programozó saját maga is automatizálhatja a tesztelést.

5.Belső határpontok látása. BAN BEN forráskód láthatók a program azon határpontjai, amelyek kívülről el vannak rejtve. Például egy bizonyos művelet végrehajtásához több teljesen különböző algoritmus is használható, és a kód megtekintése nélkül lehetetlen meghatározni, hogy a programozó melyiket választotta. Egy másik gyakori példa a túlcsordulási probléma a bemeneti adatok ideiglenes tárolására használt pufferben. A programozó azonnal meg tudja mondani, mekkora adatmennyiségnél fog túlcsordulni a puffer, és nem kell több ezer tesztet lefolytatnia.

6. A kiválasztott algoritmus által meghatározott tesztelési lehetőség. A nagyon összetett számítási algoritmusokat használó adatfeldolgozás tesztelése speciális technológiákat igényelhet. A klasszikus példák közé tartozik a mátrix transzformáció és az adatrendezés. A tesztelőnek a programozóval ellentétben pontosan tudnia kell, hogy milyen algoritmusokat használ, ezért a szakirodalomhoz kell fordulnia.

Az üvegdoboz tesztelése a programozási folyamat része. A programozók ezt a munkát folyamatosan végzik, minden modult megírása után tesztelnek, majd a rendszerbe integrálást követően újra.

Az egységtesztelés során használhat szerkezeti vagy funkcionális tesztelési technológiát, vagy mindkettőt.

Szerkezeti A tesztelés az üvegdobozos tesztelés egyik fajtája. Fő gondolata a tesztelendő szoftverútvonal helyes megválasztása. Vele ellentétben funkcionális a tesztelés a fekete doboz tesztelés kategóriájába tartozik. Minden programfunkció tesztelése a bemeneti adatok megadásával és a kimenet elemzésével történik. Ugyanakkor nagyon ritkán veszik figyelembe a program belső felépítését.

Bár a szerkezeti tesztelés sokkal erősebb elméleti alapja, a legtöbb tesztelő a funkcionális tesztelést részesíti előnyben. A strukturális tesztelés jobban megfelel a matematikai modellezésnek, de ez nem jelenti azt, hogy hatékonyabb. Mindegyik technológia lehetővé teszi a másik használata során kihagyott hibák azonosítását. Ebből a szempontból egyformán hatékonynak nevezhetők.

A tesztelés tárgya lehet nemcsak teljes útvonal program (az elejétől a befejezésig végrehajtott parancsok sorozata), hanem annak egyes szakaszai is. Teljesen irreális egy program végrehajtásának minden lehetséges módját tesztelni. Ezért a tesztelő szakemberek minden lehetséges út közül azonosítják azokat a csoportokat, amelyeket feltétlenül tesztelni kell. A kiválasztáshoz speciális kritériumokat használnak, az úgynevezett lefedettségi kritériumok (coveragecriteria), amelyek nagyon valós (még ha elég nagy) számú tesztet határoznak meg. Ezeket a kritériumokat néha ún logikai lefedettségi kritériumok, vagy teljességi kritériumok.

3. Segítő rendszer kialakítása szoftver termék. Felhasználói dokumentáció készítése

Célszerű a projekt egyik munkatársát kinevezni a dokumentáció műszaki szerkesztőjének. Ez a munkavállaló más munkát is végezhet, de fő feladata a dokumentáció elemzése legyen, még akkor is, ha azt más munkatársak is készítik.

Gyakran előfordul, hogy többen dolgoznak egy szoftver létrehozásán, de egyikük sem vállal teljes felelősséget annak minőségéért. Emiatt a szoftvernek nemhogy nem profitál abból, hogy többen fejlesztik, hanem veszítenek is, hiszen tudat alatt mindenki a másikra hárítja a felelősséget, és elvárja, hogy a kollégái elvégezzék a munka ezt vagy azt a részét. Ezt a problémát egy olyan szerkesztő kinevezésével oldják meg, aki teljes felelősséggel tartozik a műszaki dokumentáció minőségéért és pontosságáért.

A PP súgórendszer a felhasználói kézikönyvhöz kidolgozott anyag alapján kerül kialakításra. A munka elvégzéséért felelős személy alakítja és hozza létre. Ez lehet egy műszaki szerkesztő vagy valamelyik fejlesztő a műszaki szerkesztővel együtt.

A jól dokumentált PP a következő előnyökkel rendelkezik.

1. Könnyű használat. Ha a szoftver jól dokumentált, akkor sokkal könnyebben alkalmazható. A felhasználók gyorsabban megtanulják, kevesebb hibát követnek el, és ennek eredményeként gyorsabban és hatékonyabban végzik munkájukat.

2. Alacsonyabb költség technikai támogatás. Ha a felhasználó nem tudja, hogyan hajtsa végre a szükséges műveleteket, felhívja a nyomtatott áramkör gyártójának műszaki támogatási szolgálatát. Egy ilyen szolgáltatás működtetése nagyon drága. Egy jó kézikönyv segít a felhasználóknak a problémák önálló megoldásában, és csökkenti a technikai támogatási csapattal való kapcsolatfelvétel szükségességét.

3. Nagy megbízhatóság. Az érthetetlen vagy hanyag dokumentáció kevésbé megbízhatóvá teszi a szoftvert, mert felhasználói nagyobb valószínűséggel követnek el hibákat, és nehezen értik meg, mi okozta ezeket, és hogyan kezeljék a következményeket.

Könnyű karbantartás. Hatalmas mennyiségű pénzt és időt fordítanak a felhasználói hibák által okozott problémák elemzésére. Az új szoftverkiadásokon végrehajtott változtatások gyakran egyszerűen a régi funkciók felületének módosításai. Ezeket azért vezetik be, hogy a felhasználók végre rájöjjenek, hogyan kell használni a szoftvert, és ne hívják fel a technikai támogatást. Jó menedzsment nagymértékben

Számítástechnika, kibernetika és programozás

Iteráció N egységes fejlesztési folyamat szoftver Az USDP használati esetmodell leírja azokat az eseteket, amikor az alkalmazást használni fogják. Az analitikai modell az alkalmazás alaposztályait írja le. A tervezési modell az osztályok és a lefoglalt objektumok közötti kapcsolatokat és kapcsolatokat, a telepítési modell pedig a szoftverek számítógépek közötti elosztását írja le.

20. lecke
A szoftverfejlesztés általános elvei és megközelítései

Szoftverfejlesztési modellek

1. Vodopadnaya
2. Kaszkád modell
3. Spirál
4. Extrém programozás
5. Járulékos
6. MSF módszertan

Vízesés modell

Spirál modell

Inkrementális fejlődés

Követelményelemzés

Tervezés

Végrehajtás

Összetevő

tesztelés

Integráció

Tesztelés

egy egész

1. iteráció 2. iteráció…. N. iteráció

Egységes szoftverfejlesztési folyamat (USDP)

1. A használati esetmodell leírja azokat az eseteket, amikor az alkalmazást használni fogják.
2. Az analitikai modell az alkalmazás alaposztályait írja le.
3. A tervezési modell az osztályok és a kiválasztott objektumok közötti kapcsolatokat és kapcsolatokat írja le
4. A telepítési modell a szoftverek számítógépek közötti elosztását írja le.
5. A megvalósítási modell a programkód belső felépítését írja le.
6. A tesztmodell tesztkomponensekből, vizsgálati eljárásokból és különböző tesztesetekből áll.

MSF módszertan

Tipikus szoftvertermék-architektúra-összetevők és tipikus szoftverkövetelmények

hibatűrésrendszertulajdonságok halmaza, amely a hibák észlelésével, a rendszerre gyakorolt ​​rossz következmények visszaállításával és lokalizálásával növeli a megbízhatóságát. A hibatűrést biztosító valós rendszer tervezésekor gondoskodni kell minden lehetséges szituációról, amely rendszerhibához vezethet, és ki kell dolgozni a meghibásodások kezelésére szolgáló mechanizmusokat.

Megbízhatóság a rendszer azon képessége, hogy ellenálljon a különféle meghibásodásoknak és meghibásodásoknak.

Elutasítás ez egy rendszerváltása hiba következtében teljesen működésképtelen állapotba kerül.

Összeomlás olyan hiba a rendszer működésében, amely nem vezet rendszerhibához.

Minél kevesebb meghibásodás és meghibásodás egy bizonyos időtartam alatt, annál megbízhatóbbnak tekinthető a rendszer.

Valamint más művek, amelyek érdekelhetik
57355.		Szerves vegyületek változatossága, osztályozásuk. Az élő természet szerves anyagai	48,5 KB
	A szerves vegyületek sokféleségét a szénatomok egyedülálló képessége határozza meg, hogy egyszerű és többszörös kötésekkel kapcsolódjanak egymáshoz, és szinte korlátlan számú atomot tartalmazó vegyületeket képezzenek láncokba: ciklusok, kerékpárok, triciklik, policiklusok, vázak stb.
57359.		Verbális információs modellek feldolgozása	291 KB
	Alapfogalmak: modell; információs modell; verbális információs modell; annotáció; absztrakt. Szinopszis Szinopszis a lat. Jegyzet létrehozása 2. Mentse el a dokumentumot a saját mappájába Megjegyzés néven.
57361.		Szám és ábra 3. Számok igazítása a határokon 3. Számok írása 3. Az objektumok számának igazítása	35,5 KB
	Hány lény van Ki az első Ki az utolsó Ki az 1. Ki a 2. Nevezze meg a sündisznó szomszédait. Ki a jobbkezes mókus Ki a balkezes zsiráf Ki a legnagyobb Ki a legkisebb Ki áll a lények közepén Gra Mutasd, ne könyörülj.

Napjainkban a szoftverfejlesztésben két fő megközelítés létezik az EIS szoftverek fejlesztésében, amelyek közötti alapvető különbség abból adódik különböző utak rendszerek dekompozíciója. Az első megközelítést funkcionális-modulárisnak vagy strukturálisnak nevezik. A funkcionális dekompozíció elvén alapul, amelyben a rendszer felépítését a funkcióinak hierarchiájában és az egyének közötti információátadásban írják le. funkcionális elemek. A második, objektumorientált megközelítés objektumbontást használ. Ebben az esetben a rendszer felépítését az objektumok és a köztük lévő kapcsolatok, a rendszer viselkedését pedig az objektumok közötti üzenetváltással írjuk le.

Tehát az EIS szoftverfejlesztés strukturális megközelítésének lényege az automatizált funkciókra való lebontásában (bontásában) rejlik: a rendszer funkcionális alrendszerekre oszlik, amelyek viszont alfunkciókra, ezek feladatokra, stb. konkrét eljárások. Az automatizált rendszer ugyanakkor fenntart egy holisztikus nézetet, amelyben az összes komponens összekapcsolódik. A rendszer „alulról felfelé” történő fejlesztése során az egyes feladatoktól a teljes rendszerig az integritás elvész, problémák merülnek fel a leírás során. információs interakció egyedi komponensek.

A strukturális megközelítés összes leggyakoribb módszere számos általános elven alapul. Az alapelvek a következők:

az „oszd meg és uralkodj” elve (lásd a 2.1.1. alfejezetet);

a hierarchikus rendezés elve az az elve, hogy a rendszer összetevőit hierarchikus fastruktúrákba rendezzük, minden szinten új részletek hozzáadásával.

Két alapelv kiemelése nem jelenti azt, hogy a fennmaradó elvek másodlagosak, hiszen bármelyik figyelmen kívül hagyása beláthatatlan következményekkel járhat (beleértve a teljes projekt kudarcát is). Ezen elvek főbbek a következők:

az absztrakció elve - a rendszer lényeges aspektusainak kiemelése és a lényegtelentől való elvonatkoztatás;

konzisztencia elve - a rendszerelemek érvényessége és konzisztenciája;

adatstrukturálás elve – az adatoknak strukturáltnak és hierarchikusan rendezettnek kell lenniük.

A strukturális megközelítés elsősorban két eszközcsoportot használ, amelyek a rendszer funkcionális felépítését és az adatok közötti kapcsolatokat írják le. Minden eszközcsoport bizonyos típusú modelleknek (diagramoknak) felel meg, amelyek közül a leggyakoribbak:

DFD (Data Flow Diagrams) - adatfolyam diagramok;

SADT (Structured Analysis and Design Technique - szerkezeti elemzés és tervezés módszere) - modellek és a megfelelő funkcionális diagramok;

ERD (Entity-Relationship Diagrams) - entitás-kapcsolat diagramok.

Az adatfolyam-diagramok és az entitás-kapcsolat diagramok a CASE-eszközök leggyakrabban használt modelljei.

Konkrét nézet A felsorolt ​​diagramok közül és azok terveinek értelmezése a szoftver életciklusának szakaszától függ.

A szoftverkövetelmények kialakításának szakaszában a SADT modelleket és a DFD-t használják az "AS-IS" és a "TO-BE" modell felépítésére, így tükrözve a szervezet üzleti folyamatainak meglévő és javasolt struktúráját és a köztük lévő interakciót ( a SADT modellek használata általában csak erre a szakaszra korlátozódik, mivel eredetileg nem szoftvertervezésre szánták). Az ERD segítségével a szervezetben felhasznált adatok koncepcionális szintű leírása valósul meg, független az adatbázis implementációs eszközöktől (DBMS).

A tervezési szakaszban a DFD-k segítségével leírják a tervezett szoftverrendszer felépítését, ezek finomíthatók, bővíthetők, új tervekkel egészíthetők ki. Hasonlóképpen az ERD-k finomítása és kiegészítése új konstrukciókkal történik, amelyek leírják az adatok logikai szintű reprezentációját, amely alkalmas egy adatbázisséma későbbi generálására. Ezek a modellek kiegészíthetők a szoftverrendszer architektúráját tükröző diagramokkal, programblokk diagramokkal, hierarchiával képernyő formákés menü stb.

A felsorolt ​​modellek együttesen az EIS szoftverek teljes leírását adják, függetlenül attól, hogy a rendszer meglévő vagy új fejlesztésű. A diagramok összetétele minden konkrét esetben a rendszer összetettségétől és leírásának szükséges teljességétől függ.

Az ebben a fejezetben szereplő diagrampéldák többségének tárgya az Orosz Föderáció adórendszere, amelynek legteljesebb leírását az Orosz Föderáció adótörvénykönyve tartalmazza. Információs technológia, amelyet az Orosz Föderáció adórendszerében használnak, bizonyos jellemzőkkel rendelkeznek.

Tehát az EIS szoftverfejlesztés strukturális megközelítésének lényege az automatizált funkciókra való lebontásában (bontásában) rejlik: a rendszer funkcionális alrendszerekre oszlik, amelyek viszont alfunkciókra, ezek feladatokra, stb. konkrét eljárások. Ugyanakkor a rendszer fenntart egy holisztikus nézetet, amelyben az összes komponens összekapcsolódik. A rendszer „alulról felfelé” történő fejlesztésekor az egyes feladatoktól a teljes rendszerig az integritás elvész, problémák merülnek fel az egyes komponensek információs interakciójának leírásakor.

A strukturális megközelítés összes leggyakoribb módszere számos általános elven alapul:

1. Az „oszd meg és uralkodj” elve;

2. A hierarchikus rendezettség elve a rendszer összetevőinek hierarchikus fastruktúrákba szervezésének elve, minden szinten új részletek hozzáadásával.

Két alapelv elkülönítése nem jelenti azt, hogy a fennmaradó elvek másodlagosak, mert ezek bármelyikének figyelmen kívül hagyása beláthatatlan következményekkel járhat (beleértve az egész projekt kudarcát is). Ezen elvek főbbek a következők:

1. Az absztrakció elve - a rendszer lényeges szempontjainak kiemelése és a lényegtelentől való elvonatkoztatás.

2. A rendszerelemek összhangjának, érvényességének és konzisztenciájának elve.

3. Strukturálási elv adat – adat strukturáltnak és hierarchikusan szervezettnek kell lennie.

A strukturális megközelítésben elsősorban két eszközcsoport van, amelyek a rendszer funkcionális felépítését és az adatok közötti kapcsolatokat írják le. Minden eszközcsoport bizonyos típusú modelleknek (diagramoknak) felel meg, ezek közül a leggyakoribbak:

· DFD (Data Flow Diagrams) - adatfolyam diagramok;

· SADT (Structured Analysis and Design Technique - szerkezeti elemzés és tervezés módszertana) - modellek és a megfelelő funkcionális diagramok: IDEF0 (rendszerek funkcionális modellezése), IDEF1х (adatbázisok fogalmi modellezése), IDEF3х (rendszerek felépítése minőségi értékelésre) jelölések egy tárgy munkája; grafikus leírás folyamatok áramlása, folyamatok és objektumok kölcsönhatása, amelyeket ezek a folyamatok megváltoztatnak);

· ERD (Entity - Relationship Diagrams) - entitás-kapcsolat diagramok.

A strukturális megközelítés (strukturális elemzés) szinte minden módszere a szoftverkövetelmények kialakításának szakaszában a modellező eszközök két csoportját használja:

1. A rendszernek végrehajtandó funkciókat és a funkciók közötti kapcsolatokat bemutató diagramok - DFD vagy SADT (IDEF0).

2. Az adatokat és azok kapcsolatait modellező diagramok (ERD).

A felsorolt ​​diagramok konkrét formája és terveinek értelmezése a szoftver életciklusának szakaszától függ.

A szoftverkövetelmények kialakításának szakaszában a SADT modelleket és a DFD-t használják az „AS-IS” és a „TO-BE” modell felépítésére, így tükrözve a szervezet üzleti folyamatainak meglévő és javasolt struktúráját és a köztük lévő interakciót ( a SADT modellek használata, mivel általában csak erre a szakaszra korlátozódnak, mivel eredetileg nem szoftvertervezésre készültek). Az ERD segítségével a szervezetben felhasznált adatok leírása koncepcionális szinten történik, függetlenül az adatbázis implementációs eszközöktől (DBMS).

1. A programozási technológia célja. A programozási technológia fejlődésének története. Szoftverprojektek típusai. A programozási technológia összetevői. Projekt, termék, folyamat és emberek

2. A program életciklusa. A fejlődés ciklikussága. A programozási technológia alapfogalmai. Eljárások és modellek. Fázisok és fordulatok. Mérföldkövek és műtermékek. Érintettek és alkalmazottak.

3. A követelmények azonosítása és elemzése. Szoftverkövetelmények. Követelményfejlesztési folyamatábra. Követelménykezelés.

4. Építészeti és részletes tervezés. Megvalósítás és kódolás. Tesztelés és ellenőrzés. Minőség-ellenőrzési folyamat. Fehér doboz és fekete doboz módszerek. Ellenőrzések és felülvizsgálatok. Célok tesztelése. Ellenőrzés, érvényesítés és rendszerteszt. Karbantartás és folyamatos fejlesztés.

5. A fejlesztési folyamat modelljei. Vízesés és szállítószalag modellek. Spirális és inkrementális modellek. Rugalmas fejlesztési folyamatmodellek.

6. Folyamatmodell felépítése. Határozza meg a folyamatkövetelményeket. Felhasznált fázisok, mérföldkövek és műtermékek. A folyamat architektúra kiválasztása. Szabványprojekt végrehajtásának eljárása. Dokumentált eljárások.

7. Fejlesztő csapatmodellek. A fejlesztés kollektív jellege. Optimális csapatlétszám. A projekt résztvevőinek alárendeltsége. Csapatfejlesztés és személyzetfejlesztés. Specializáció, együttműködés és interakció.

8. Fejlesztő csapatmodellek. Hierarchikus csapatmodell. Sebészi csapat módszer. Peer team modell.

9. A programozás természete. A programozás tudománya. A programozás művészete. A programozás mestersége. Programozási paradigmák. Strukturált programozás. Logikai programozás. Objektumorientált programozás.

10. Szoftver architektúra. Rendezvényszervezés. Kliens/szerver architektúra. Szolgáltatások. Háromrétegű architektúra. Programtervezés. Koncepcionális tervezés. Logikus tervezés. Részletes tervezés.

1. Novikov megközelítések a szoftverfejlesztéshez" http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Extrém programozás. – Szentpétervár: Péter, 2002.

3. Szoftverfejlesztési technológia. - Szentpétervár. : Péter, 2004.

4. Brooks Jr. tervezik és készítik szoftverrendszerek. M.: Nauka, 1975; a fordítás új kiadása: The Mythical Man-Month. SPb.: SYMBOL+, 1999.

5. Algoritmusok + adatszerkezetek = programok. M., Mir, 1978.

6. Szisztematikus programozás. Bevezetés. M.: Mir, 1977.

7. Strukturált programozás. M.: Mir, 1975.

8. Programozási tudomány. M.: Mir, 1978.

9. Szoftverfejlesztési technológiák. – Szentpétervár: Péter, 2002.

10. Terekhov programozás. M.: BINOM, 2006.

11. Rambo J. Egységes szoftverfejlesztési folyamat. Szentpétervár: Péter, 2002.

Közgazdasági elmélet vezetőknek

Alapvető mikroökonómiai elméletek. Alkalmazási példák a gazdasági folyamatok elemzésében. Makrogazdasági alapelméletek. Alkalmazási példák a gazdasági folyamatok elemzésében. A gazdasági folyamatok irányításának elvei és módszerei. Eszközök a gazdasági folyamatok fejlettségi szintjének felméréséhez A kiterjesztett szaporodás problémái. Az orosz gazdaság gazdasági növekedésének tényezői. A fenntartható fejlődés kritériumai és mutatói. A ciklikus ingadozások kisimítása. A multiplikátor és a gyorsító szerepe a gazdasági fejlődés ütemének megítélésében. Termelési funkciók a közgazdaságtanban. Alkalmazási példák a gazdasági folyamatok elemzésében. Nyereség. A nyereséget befolyásoló mutatók számítása, grafikus kép fedezeti pont. A beruházási politika végrehajtásának módszertana.

A közgazdaságtan tantárgya: tankönyv egyetemek számára / Szerk. . –Kirov: „ASA”, 2004. Kolemajev - matematikai modellezés. Makrogazdasági folyamatok és rendszerek modellezése: tankönyv. M.: UNITY-DANA, 2005. Bazhin kibernetika. Kharkov: Consul, 2004. Leushin workshop a matematikai modellezés módszereiről: tankönyv. Nyizsnyij Novgorod állam tech. egyetem - N. Novorod, 2007. Politikusok a közgazdaságtanról: Nobel-díjasok közgazdasági előadásai. M.: Modern közgazdaságtan és jog, 2005. Cheremnykh. Emelt szint: Tankönyv.-M.:INFRA-M, 2008. Mini-gazdaság intézményeinek alakulása. Közgazdaságtudományi Intézet, az Orosz Tudományos Akadémia Uráli Kirendeltsége, - M.: Nauka, 2007.

Technológiák a fejlesztéshez és a vezetői döntéshozatalhoz [N]

A döntéshozatal, mint a vezetői tevékenység alapja. Bevezetés a döntéselméletbe. Döntéselméleti alapfogalmak. Vállalatirányítási modellek és hatásuk a döntéshozatalra. Különböző módokon megoldások osztályozása. Osztályozások: a formalitás mértéke, a rutinosság foka szerint, a gyakoriság szerint, a sürgősség szerint, a célok elérésének mértéke szerint, az alternatívaválasztás módja szerint. A döntéshozatal alapvető módszerei. A döntéshozatal akaratlagos módszerei. A döntéshozatal céljai. A megoldások keresésének ideje. Alapvető hibák A döntéshozatal matematikai módszerei. A döntéselmélet matematikai vonatkozásai. Operációkutatás. A döntéshozatal matematikai megközelítése. Döntési fa. A fejlődés és a döntéshozatal modelljei. Játékelmélet. A döntéshozatal matematikai módszerei. A döntéselmélet matematikai vonatkozásai. A sorban állás elméletének modelljei. Készletgazdálkodási modellek. Lineáris programozási modell. Szállítási feladatok. Szimulációs modellezés. Hálózati elemzés. Gazdasági elemzés. A racionális modellek korlátai. A csoportos fejlődés és döntéshozatal jellemzői. Egy módszer a csoportkohézió meghatározására a halmazok kapcsolódási foka alapján. A kollektív döntések meghozatalának módszerei. Konszenzusos módszer. Szavazási módszerek. Kreatív döntéshozatali módszerek. Ötletelés. Ötletkonferencia. Hajótanács. De Bono „Gondolkodó Kalapok” módszere. A feltalálói problémamegoldás elmélete (TRIZ). A tökéletes végső megoldás. Példák problémákra és megoldásaikra a TRIZ segítségével. A TRIZ módszerek alkalmazása egyedi és kreatív döntések meghozatalakor. Megoldási ötletek kidolgozásának és a helyzethez igazításának módszerei. Célfa modell. Érdekegyeztetési stratégia. Érdekegyeztető döntések megalkotása. A szerződő felek érdekeinek meghatározásának módszerei. Döntéstámogató rendszerek (szakértői rendszerek). A döntéshozatali rendszerek létrejöttének története. A döntéshozatali rendszerek osztályozása. Tipikus szerkezet szakértői rendszer. Az ismeretek bemutatásának módszerei. Logikai következtetés módszerei. Szakértői rendszerek alkalmazása a gyakorlatban.

I. Döntéshozatal elmélet: Tankönyv. - M.: Vizsga, 2006. - 573 p. I. Döntéshozatal. A vezetői döntések kialakításának elmélete és módszerei. Oktatóanyag. - M.: MarT, 2005. - 496 pp. Vezetői döntések alakulása - M.: "Delo" Kiadó, 2004 - 392 pp. G. Szakértői értékelések és döntéshozatal - M.: Szabadalom, 1996. - 271 p. Taha // Bevezetés a műveletek kutatásába = Operations Research: An Introduction. - 7. kiadás - M.: „Williams”, 2007. - P. 549-594. G. Theil. Gazdasági előrejelzések és döntéshozatal. M.: „Haladás” 1970. K. D. Lewis. A gazdasági mutatók előrejelzésének módszerei. M.: „Pénzügy és Statisztika” 1986. G. S. Kildishev, A. A. Frenkel. Idősor elemzés és előrejelzés. M.: Statisztika, 1973. O. Kim, C. W. Muller, U. R. Klekka és mások Tényező-, diszkriminancia- és klaszteranalízis. M.: „Pénzügy és Statisztika” 1989. Hatékony menedzser. 3. könyv Döntéshozatal. – MIM LINK, 1999 Turevsky és egy gépjármű-szállítási vállalkozás vezetése. - M.: Felsőiskola, 2005. , ; szerkesztette . Rendszerelemzés a menedzsmentben: oktatóanyag. – M.: Pénzügy és Statisztika, 2006. , Tinkov: tankönyv. – M.: KNORUS, 2006.

Üzleti folyamatok modellezése integrált irányítási rendszerekben

Milyen elvek alapján különböztetik meg az üzleti folyamatokat? Mi a probléma az üzleti folyamatok holisztikus leírásával? Mi a rendszer, milyen tulajdonságai vannak? A rendszerelemzés szerepe az üzleti folyamatok modellezésében? A folyamat, mint az irányítás tárgya. Folyamatkörnyezet. Egy üzleti folyamat alapelemei. A funkcionális és folyamatmenedzsment előnyei és hátrányai. PDCA kezelési ciklus. A folyamatirányítási ciklus szakaszai. PDCA ciklus és az ISO 9001:2008 követelményeinek megvalósítása. SADT módszertan (Structured Analysis and Design Technique - szerkezeti elemzés és tervezés módszere). Lényeg. Alapvető rendelkezések. Hogyan jelenik meg a tevékenység funkcionális modellje az IDEF0 módszertanban? Mit jelentenek a funkcionális modell diagramokon szereplő tevékenységek, hogyan jelennek meg az IDEF0 módszertan szerint? Mire szolgálnak a nyilak a funkcionális modell diagramokon, milyen típusuk és típusuk van? DFD módszertan. Lényeg. A DFD diagramok alapvető összetevői. Melyek a DFD diagramok jellemzői és mit írnak le bennük? Mik a DFD diagramobjektumok jellemzői? Mit jelentenek a nyilak a DFD diagramon? IDEF3 módszertan. Lényeg. Dokumentációs és modellező eszközök. Melyek az IDEF3 diagramok jellemzői, és mit írnak le bennük? Melyek az IDEF3 diagram objektumok jellemzői? És a lövész? A folyamatok osztályozása. Tipikus üzleti folyamatok. Újratervezés és technológiája. Mikor célszerű újratervezést alkalmazni egy cég irányítása során? Monitoring és mérési folyamatok. A szervezeti folyamatok mutatói. Folyamatok numerikus és minősítő értékelése.

"Üzleti folyamatok modellezése AllFusion Process Modelerrel (BPwin 4.1) Dialog-MEPhI" 2003 "Információs rendszerek létrehozása az AllFusion Modeling Suite segítségével" ed. "Dialog-MEPhI" 2003 "Funkcionális modellezés gyakorlata AllFusion Process Modeler 4.1-el. (BPwin) Hol? Miért? Hogyan?" szerk. "Dialogue-MEPhI" 2004 Dubeykovsky modellezés AllFusion Process Modelerrel (BPwin). szerk. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "A szerkezetelemzés és tervezés módszertana SADT" 1993 klasszikus munka a SADT módszertanról. Cseremnykh rendszerek elemzése: IDEF-technológiák, Rendszerek modellezése és elemzése. IDEF technológiák. Műhely. M.: Pénzügy és Statisztika, 2001. „Strukturális üzleti modellek: DFD technológiák” http://www. /Level4.asp? ItemId=5810 "Az üzleti folyamatok átszervezésének elmélete és gyakorlata" 2003/ P50.1.. Funkcionális modellezési módszertan. M.: Gosstandart of Russia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Üzleti folyamatok modellezése BPwin segítségével http://www. /department/se/devis/7/ IDEF0 az üzletvezetési folyamatok modellezésében http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Szoftvertermékek hatékonyságának értékelése

1. IT architektúra

2. Vezetési folyamatok területei.

3. A Tervezés és szervezés tartomány folyamatainak listája

4. Tartományi folyamatok listája Beszerzés és megvalósítás

5. Az Üzemeltetés és karbantartás tartomány folyamatainak listája

6. A Monitoring és Értékelés tartomány folyamatainak listája

7. A folyamatérettségi modell szintjeinek jellemzői

9. KPI és KGI kapcsolatuk és céljuk

1. 10.Általános informatikai és alkalmazásvezérlők. Üzleti és informatikai felelősségi körök és felelősségi körök.

Cobit 4.1 orosz kiadás.

A szellemi tulajdon létrehozásának és felhasználásának jogi szabályozása

1. Sorolja fel a szellemi tevékenység eredményeihez fűződő szellemi jogokat, és tárja fel azok tartalmát.

2. Sorolja fel a kizárólagos jogok feletti rendelkezési megállapodások típusait! Mutassa be ezeket a kizárólagos jogokkal kapcsolatos megállapodásokat.

4. Ismertesse a Számítógépes Program, mint szerzői jog tárgyának jogi védelmére vonatkozó főbb rendelkezéseket!

5. Hasonlítsa össze az Adatbázis, mint szerzői jog és szomszédos jogok tárgya jogi védelmére vonatkozó főbb rendelkezéseket.

6. Ismertesse a szabadalmi jogok tárgyai szabadalmazhatóságának feltételeit: találmányok; használati modellek; ipari formatervezési minták.

7. Bővítse a találmány szabadalmazhatósági kritériumainak tartalmát: újdonság; feltalálói lépés; ipari alkalmazhatóság.

8. Ismertesse a találmány, használati minta vagy ipari minta szabadalom megszerzésének feltételeit, eljárását, valamint a szabadalmak érvényességét biztosító feltételeket és azok érvényességi idejét!

9. Határozza meg a „know-how”-t, és sorolja fel azokat a feltételeket, amelyek létrehozása során felmerül és megvalósul a gyártási titkok jogi védelme.

10. Sorolja fel az individualizálás védett eszközeit, és adja meg azok összehasonlító jellemzőit!

1. Szellemi tulajdonjogok in Orosz Föderáció, tankönyv // M, Prospekt, 2007

2., Szellemi tulajdonjog, tankönyv // M, RIOR, 2009.

Projekt- és szoftverfejlesztés menedzsment [I]

Mi az a módszertan, miért van rá szükség. A módszertan általános felépítése, a módszertan főbb elemei. A saját módszertan megtervezésének alapelvei. Példák különféle műtermékekre, szerepekre, kompetenciákra, peremfeltételekre. A módszertan szerkezete Cowburn szerint, módszertani metrikák. Cowburn tervezési kritériumai. A módszertan kiválasztásának kritériumai, Cowburn mátrix. Projekt életciklusa. Vízesés és iteratív életciklus modellek. Alkalmazhatósági korlátok vízesések és iteratív modellek esetében. A RUP az iteratív módszertan példájaként. A RUP alapfogalmai, az alkalmazhatóság határai. Az ember szerepe a szoftverfejlesztésben. Agilis módszertanok, az agilis módszertanok alapelvei. A rugalmas módszertanok megjelenésének oka. Scrum a rugalmas módszertan példájaként. Szerepek, tárgyak, tevékenységek a Scrumban. Scrum alkalmazhatósági korlátai. Extreme Programming (XP) Ötletek, értékek, alapgyakorlatok, alkalmazhatóság határai. Hasonlóságok és különbségek a Scrum és az XP között. Követelmények begyűjtése és kezelése. Alapvető gyakorlatok, kifejezések, alapelvek. Projekt és termék dokumentálásának megközelítései, főbb dokumentumtípusok. Példák követelménykezelési gyakorlatokra a tantárgyban tárgyalt módszertanokból. Szoftverfejlesztés tervezése. Tervek típusai, kockázatkezelés, népszerű kockázatok. Példák fejlesztési tervezési gyakorlatokra a tanfolyamon tárgyalt módszertanokból. Tesztelés a szoftverfejlesztésben. A szoftvertermék összeállításának (építésének) fogalma. Alapvető vizsgálati módszerek, kifejezések. Példák tesztelési gyakorlatokra a tanfolyamon tárgyalt módszertanokból. Az összeállítás (build) fogalma, a kód tárolásának módjai, eszközök. Két alapelv a verziókezelő rendszerrel való munka megszervezéséhez. A termék kiadási/megjelenítési folyamatának jellemzői különböző termékkategóriákhoz, gyakorlati példák. A szoftverarchitektúra modern koncepciói, többszintű architektúrák, architektúra kritériumai. Szoftvertervezéskor szükséges döntések listája, adattároló rendszer kiválasztásának megközelítései.

Kent Beck – Extrém programozás Frederick Brooks – A mitikus emberhónap avagy a szoftverrendszerek létrehozása. Tom DeMarco – Határidő. Regény a projektmenedzsmentről. Tom De Marco, Timothy Lister – Keringős a medvékkel. Tom de Marco, Timothy Lister – Emberi tényező – sikeres projektek és csapatok. Alistair Cowburn – Minden projektnek megvan a maga módszertana. Alistair Cowburn – Az emberek, mint nemlineárisak és a szoftverkészítés legfontosabb összetevői. Andriy Orlov – Egy automatizálási mérnök feljegyzései. Szakmai vallomás. Philipp Kratchen – Bevezetés a racionális egységes folyamatba. Henrik Kniberg - Scrum és XP: jegyzetek az élvonalból. A tanfolyamon elhangzott előadások bemutatása