Szoftverfejlesztési modellek Vízesés Vízesés Spirál Extrém Programozási UI Prototípuskészítés Növekményes W-Modell Tesztelés Egységes szoftverfejlesztési folyamat (USDP) MSF módszertan

Vízesés modell Követelményelemzés Termékspecifikáció összeállítása Tervezés Termékarchitektúra összeállítása Megvalósítás Forráskód fejlesztése Forráskód külön részeinek integrálása Tesztelés és hibaelhárítás

Extrém programozási kezdeti követelmények elemzése tervezés integráció megvalósítás tesztelése új követelmények felülvizsgálata/jóváhagyása/módosítása fejlesztési terv kiadása

UI Prototyping Termék kiadás Szoftverfejlesztés a változásokat szem előtt tartva Követelmények és specifikációk tisztázása Prototípus módosítása és néhány funkció finomítása Alapvető funkcionalitás Interfész prototípus Előzetes specifikáció

Növekményes fejlesztés 1. iteráció 2. iteráció …. Követelmények Elemzés Tervezés Megvalósítás Komponens tesztelés Integráció A teljes egész iteráció tesztelése N

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

Egységes szoftverfejlesztési folyamat (USDP) követelményeinek összegyűjtése Iter 1…. Iter N Az Iter 1 tervezése…. Iter N Az Iter 1 megvalósítása…. Iter N Az Iter 1 tervezése…. Iter N tesztelése Iter 1…. Iter N

Tipikus szoftvertermék-architektúra komponensek és tipikus szoftverkövetelmények Ø Ø Ø Ø Programszervezés Fő rendszerosztályok Adatszervezés Üzleti szabályok Felhasználói felület Erőforrás-kezelés Biztonság Teljesítmény Skálázhatóság Interakció más rendszerekkel (integráció) Nemzetköziesítés, honosítás Bemeneti-kimeneti adatok Hibakezelés

Tipikus szoftvertermék-architektúra-összetevők és tipikus szoftverkövetelmények A hibatűrés olyan rendszertulajdonságok halmaza, amelyek javítják a rendszer megbízhatóságát azáltal, hogy észlelik a hibákat, helyreállítják és elkülönítik a rendszerre gyakorolt ​​rossz következményeket. Bármilyen valós rendszer tervezése során a hibatűrés biztosítása érdekében előre kell látni minden olyan lehetséges helyzetet, amely rendszerhibához vezethet, és ki kell dolgozni a meghibásodások kezelésére szolgáló mechanizmusokat. A megbízhatóság a rendszer azon képessége, hogy ellenálljon a különféle hibáknak és hibáknak. A meghibásodás a rendszer átmenete egy hiba következtében teljesen működésképtelen állapotba. A hiba a rendszer működésében fellépő hiba, amely nem vezet a rendszer meghibásodásához. Minél kevesebb meghibásodás és meghibásodás egy bizonyos ideig, annál megbízhatóbbnak tekinthető a rendszer.

A szoftvertermék architektúrájának tipikus összetevői és tipikus szoftverkövetelményei Megbízhatósági görbe N t 1 t Minél távolabbról, annál nehezebb lesz hibát találni. Minél összetettebb a rendszer, annál nagyobb a meghibásodások és meghibásodások valószínűsége.

A szoftvertermék architektúrájának jellemző komponensei és jellemző szoftverigényei Ø A kifejlesztett architektúra megvalósításának lehetőségei. Ø Túl sok funkcionalitás. Ø Döntés meghozatala kész szoftverkomponensek vásárlásáról. Ø Stratégia módosítása.

A kérdések ellenőrző listája, amely lehetővé teszi, hogy következtetéseket vonjon le az architektúra minőségéről: Ø Világosan le van írva a program általános felépítése; Ø Ø Ø A specifikáció tartalmazza-e az architektúra áttekintését és annak indokait. Megfelelően meghatározzák-e a program fő összetevőit, felelősségi területeiket és interakcióikat a többi komponenssel. A követelményspecifikációban meghatározott összes funkciót ésszerű számú rendszerkomponens megvalósítja-e. Leírják és indokolják a legfontosabb osztályokat. Adva van-e az adatbázis felépítésének leírása. Minden üzleti szabály meghatározott? Leírják a rendszerre gyakorolt ​​hatásukat?

A kérdések ellenőrző listája, amely lehetővé teszi, hogy következtetést vonjon le az architektúra minőségéről: Ø Le van írva a felhasználói felület tervezési stratégiája. Ø A felhasználói felület modulárissá van-e alakítva, hogy a változtatások ne érintsék a rendszer többi részét. ØAdva van-e az adatbeviteli/kimeneti stratégia leírása. Ø Elvégezték-e az ezzel az architektúrával megvalósítandó rendszer teljesítményelemzését. Ø Elvégezték-e a tervezett rendszer megbízhatósági elemzését. Ø Megtörtént-e a rendszer skálázhatósági és bővíthetőségi kérdéseinek elemzése.

Szoftver-refaktorálás A refaktorálás magában foglalja a szoftverek újhoz igazítását hardver valamint az új operációs rendszerekre, új fejlesztőeszközökre, új követelményekre, valamint a szoftver architektúrára és funkcionalitására. Ez a szoftver belső struktúrájának külső viselkedésének megváltoztatása nélküli megváltoztatása, amely a szoftver módosítását hivatott biztosítani. A refaktorálás ésszerű okai: A kód ismétlődő; a módszer megvalósítása túl nagy; túl sok hurkok egymásba ágyazása, vagy maga a hurok nagyon nagy; az osztálynak gyenge a kapcsolata (az osztály tulajdonságai és metódusai csak 1 objektumot írjanak le); egy osztályinterfész nem alkot konzisztens absztrakciót; a módszer túl sok paramétert igényel. Meg kell próbálnia a paraméterek számát ésszerű minimumon tartani; az osztály egyes részei az osztály többi részétől függetlenül változnak;

A szoftver átalakítása a program megváltoztatásakor több osztály párhuzamos megváltoztatását igényli. Ha ilyen helyzet adódik, az osztályok átszervezése szükséges, hogy a jövőben minimálisra csökkenjenek az esetleges változások helyei; párhuzamosan több öröklési hierarchiát kell megváltoztatnia; több esetblokkot kell módosítania. A programot úgy kell módosítani, hogy az ügy blokkba kerüljön, és a programban annyiszor hívja meg; Az együtt használt kapcsolódó adattagok nincsenek osztályokba rendezve. Ha ismételten ugyanazt az adatelem-készletet használja, akkor érdemes megfontolni ezen adatok kombinálását és a velük végzett műveletek külön osztályba helyezését;

Egy szoftverrefaktorálási módszer több elemet használ egy másik osztályból, mint a sajátja. Ez azt jelenti, hogy a metódust át kell helyezni egy másik osztályba, és a régiből kell meghívni; az elemi adattípus túlterhelt. A valós világ lényegének leírásához jobb egy osztályt használni, mint bármely meglévő adattípust túlterhelni; az osztály túlságosan korlátozott funkciókkal rendelkezik. Jobb, ha megszabadulunk ettől az osztálytól, ha funkcionalitását egy másik osztályba helyezzük át; "kóbor" adatokat továbbítanak a módszerek láncolatán. Azokat az adatokat, amelyeket egy metódusnak csak azért adnak át, hogy átadják egy másik metódusnak, kóbor adatoknak nevezzük. Ha ilyen helyzetek merülnek fel, próbálja meg megváltoztatni az osztályok és módszerek architektúráját, hogy megszabaduljon tőlük.

A médiaobjektum újrafaktorálása nem tesz semmit. Ha egy osztály feladata a metódushívások átirányítása más osztályokhoz, akkor a legjobb, ha megszünteti ezt a proxyt, és közvetlenül más osztályokat hív meg; az egyik osztály túl sokat tud a másik osztályról. Ebben a helyzetben szigorúbbá kell tenni a tokozást, hogy az örökös minimális ismeretekkel rendelkezzen a szülőjéről; a módszernek szerencsétlen neve van; az adatok tagjai nyilvánosak. Ez elmossa a határvonalat az interfész és a megvalósítás között, elkerülhetetlenül megszakítja a tokozást, és korlátozza a program rugalmasságát; megjegyzéseket helyezzen el a forráskódban;

Egy szoftverrefaktoráló alosztály csak egy kis töredékét használja az ősei módszereinek. Ez a helyzet akkor fordul elő, ha egy új osztály csak néhány metódus öröklésére szolgál az alaposztályból, és nem ír le új entitást. Ennek elkerülése érdekében az alaposztályt úgy kell átalakítani, hogy az csak a számára szükséges metódusoknak adjon hozzáférést az új osztályhoz; a kód globális változókat tartalmaz. Csak a teljes program által ténylegesen használt változók legyenek globálisak. Az összes többi változónak vagy lokálisnak kell lennie, vagy valamilyen objektum tulajdonságává kell válnia; a program olyan kódot tartalmaz, amelyre egyszer szükség lehet. A rendszer fejlesztésénél célszerű olyan helyeket biztosítani, ahol a jövőben forráskódot lehet hozzáadni.

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

Iteráció N USDP egységes szoftverfejlesztési folyamat A 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 dedikált 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
Általános elvekés a szoftverfejleszté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 fejlesztés

Követelményelemzés

Tervezés

Végrehajtás

Összetevő

tesztelés

Integráció

Tesztelés

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ésolyan rendszertulajdonságok halmaza, amelyek a hibák észlelésével, a rendszer rossz következményeinek visszaállításával és lokalizálásával növelik a megbízhatóságát. Bármilyen valós rendszer tervezése során a hibatűrés biztosítása érdekében előre kell látni minden olyan lehetséges helyzetet, 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 a rendszer átmenetea hiba következtében teljesen működésképtelen állapotba kerül.

összeomlik olyan hiba a rendszer működésében, amely nem vezet a rendszer meghibásodásához.

Minél kevesebb meghibásodás és meghibásodás egy bizonyos ideig, 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. A természet szerves anyagai	48,5 KB
	A szerves vegyületek sokféleségét a szénatomok egyedi képessége határozza meg, hogy egyszerű és többszörös kötésekkel egyesülve szinte korlátlan számú atomot tartalmazó vegyületeket képeznek láncokba, ciklusokba, kerékpárokba, triciklikbe, policiklusokba, vázakba 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. Készítsen vázlatot a 2. A dokumentumot a saját mappájába Abstract néven.
57361.		Szám és szám 3. Számpárosítás a határokon 3. Írott számok 3. Régi tárgyak párosítása	35,5 KB
	Az összes lény száma Ki legyen az első Ki legyen az utolsó Ki legyen az 1-es szám alatt Ki legyen a 2-es szám alatt Ki a susid jobbkezes mókus Ki a susid balkezes zsiráf

Megjegyzés: A szoftverfejlesztés rugalmas megközelítését, a rugalmas fejlesztés alapelveit veszik figyelembe. Olyan technikák listája szerepel, amelyek bizonyos mértékig megfelelnek a rugalmas szoftverfejlesztés alapelveinek. Elemezzük az agilis fejlesztés kulcsfontosságú értékeit és alapelveit.

Az előadás prezentációja letölthető.

Az előadás célja:

Ismerje meg az agilis szoftverfejlesztés célját és alapelveit.

Bevezetés

Agilis szoftverfejlesztési módszertan iteratív megközelítés alkalmazására összpontosított, amelyben szoftver fokozatosan, kis lépésekben jön létre, beleértve egy bizonyos követelményrendszer megvalósítását. Feltételezhető, hogy a követelmények változhatnak. Az agilis módszertanokat alkalmazó csapatok sokoldalú fejlesztőkből alakulnak, akik különféle feladatokat látnak el a szoftvertermékek létrehozásának folyamatában.

Agilis módszerek alkalmazásakor a kockázatminimalizálást úgy hajtják végre, hogy a fejlesztést rövid ciklusok sorozatára, ún iterációk, 2-3 hétig tart. Az iteráció olyan feladatok halmaza, amelyeket meghatározott időn belül kell végrehajtani. Minden iterációban létrejön a szoftverrendszer működőképes verziója, amelyben a legnagyobb prioritás (ennél az iterációnál) vevői követelmények. Minden iteráció elvégzi a működő szoftver létrehozásához szükséges összes feladatot: tervezés, követelményelemzés, tervezés, kódolás, tesztelés és dokumentáció. Bár egyetlen iteráció általában nem elegendő egy termék új verziójának kiadásához, nyilvánvaló, hogy a jelenlegi szoftver kiadásra kész minden iteráció végén. Minden iteráció végén a csapat újra priorizálja a szoftvertermék követelményeit, esetleg módosítja a rendszerfejlesztést.

Az agilis fejlesztés alapelvei és jelentése

Az agilis fejlesztési módszertanhoz kulcsfontosságú posztulátumok vannak deklarálva, amelyek lehetővé teszik a csapatok számára, hogy magas teljesítményt érjenek el:

• emberek és interakcióik;
• működő szoftverek szállítása;
• együttműködés az ügyféllel;
• válasz a változásra.

Emberek és interakció. Az emberek a siker legfontosabb részei. Az egyéni csapattagok és a jó kommunikáció elengedhetetlen a jól teljesítő csapatokhoz. A kommunikáció megkönnyítése érdekében az agilis gyakorlatok magukban foglalják a munkaeredmények és a döntések megváltoztatásának gyakori megbeszélését. A megbeszéléseket naponta néhány percig, az iteráció végén pedig a munka eredményeinek elemzésével és visszatekintéssel lehet tartani. Az értekezletek során a hatékony kommunikáció érdekében a csapattagoknak be kell tartaniuk a következő kulcsfontosságú magatartási szabályokat:

• minden csapattag véleményének tiszteletben tartása;
• legyen őszinte minden kommunikációban;
• minden adat, intézkedés és döntés átláthatósága;
• bizalom abban, hogy minden résztvevő támogatni fogja a csapatot;
• elkötelezettség a csapat és céljai iránt.

A hatékony csapat és a jó kommunikáció mellett tökéletes szoftvereszközökre van szükség ahhoz, hogy agilis módszertannal nagy teljesítményű csapatokat hozzanak létre.

Dolgozó szoftver fontosabb, mint az átfogó dokumentáció. Minden agilis módszertan rámutat arra, hogy előre meghatározott időközönként kisméretű működő szoftvereket kell eljuttatni az ügyfélhez. Szoftver, mint szabály, meg kell felelnie az egységtesztelés szintjén, a rendszerszintű tesztelésnek. A dokumentáció mennyiségét minimálisra kell csökkenteni. A tervezési folyamat során a csapatnak naprakészen kell tartania egy rövid dokumentumot, amely tartalmazza a döntés indoklását és a szerkezet leírását.

Az ügyféllel való együttműködés fontosabb, mint a szerződés szerinti formális megállapodások. A projekt sikeres befejezéséhez rendszeres és gyakori kommunikáció szükséges a megrendelővel. Az ügyfélnek rendszeresen részt kell vennie a szoftverrel kapcsolatos döntések megvitatásában, ki kell fejeznie kívánságait, észrevételeit. A minőségi termék létrehozásához szükséges az ügyfél bevonása a szoftverfejlesztési folyamatba.

A változásokra való gyors reagálás fontosabb, mint a terv követése. A változásokra való reagálás képessége nagymértékben meghatározza egy szoftverprojekt sikerét. A szoftvertermékek létrehozása során gyakran változnak vevői követelmények. Az ügyfelek gyakran nem tudják pontosan, mit akarnak, amíg nem látják, hogy működik. szoftver. Agilis módszertanokat keresnek Visszacsatolás az ügyfelektől a szoftvertermék létrehozásának folyamatában. A változásokra való reagálás elengedhetetlen egy olyan termék létrehozásához, amely vevői elégedettséget és üzleti értéket biztosít.

Az agilis fejlesztés alapelveit 12 alapelv támogatja. Az agilis specifikus módszertanok olyan folyamatokat és szabályokat határoznak meg, amelyek többé-kevésbé megfelelnek ezeknek az elveknek. A szoftvertermékek létrehozásának rugalmas módszerei a következő elveken alapulnak:

1. Legfontosabb prioritás a vásárlói igények kielégítése hasznos szoftverek rövid időn belüli szállításával, majd a folyamatos frissítésekkel. Az agilis módszerek magukban foglalják a kezdeti verzió gyors szállítását és gyakori frissítések. A csapat célja, hogy a projekt elindítását követő néhány héten belül működő verziót szállítsanak. A jövőben a növekményes funkcionalitással rendelkező szoftverrendszereket néhány hetente kell szállítani. Az ügyfél elkezdheti kereskedelmi működés rendszert, ha kellően működőképesnek tartja. Ezenkívül az ügyfél egyszerűen tud olvasni jelenlegi verzió szoftver, adja meg visszajelzését megjegyzésekkel.
2. Ne hagyja figyelmen kívül a változó követelményeket, még a fejlesztés késői szakaszában sem. A rugalmas folyamatok lehetővé teszik a változtatások figyelembe vételét az ügyfél versenyelőnyének biztosítása érdekében. Az agilis módszertanokat alkalmazó csapatok arra törekszenek, hogy a programszerkezet minőségi legyen, a változtatások minimális hatással a rendszer egészére.
3. A szoftver új működő verzióinak átadása gyakran, egy héttől két hónapig terjedő időközönként, a rövidebb határidők preferálásával. Ugyanakkor cél a felhasználó igényeinek megfelelő program szállítása, minimális kísérő dokumentációval.
4. Az ügyfeleknek és a fejlesztőknek együtt kell működniük a projekt során. Úgy gondolják, hogy egy sikeres projekthez az ügyfeleknek, a fejlesztőknek és az összes érdekelt félnek gyakran és sokféleképpen kell kommunikálnia a szoftvertermék célirányos fejlesztése érdekében.
5. A projekteket motivált embereknek kell megvalósítaniuk. Biztosítson egészséges munkakörnyezetet a projektcsapatnak, biztosítsa a szükséges támogatást, és bízzon abban, hogy a csapattagok elvégzik a munkát.
6. A leghatékonyabb és legtermékenyebb módszer a fejlesztőcsapat felé történő információtovábbításra és azon belüli véleménycserére a személyes beszélgetés. Az agilis projektekben a kommunikáció fő módja az egyszerű emberi interakció. Az írásos dokumentumok a szoftver fejlesztésével párhuzamosan jönnek létre és frissülnek, és csak szükség esetén.
7. A munkaprogram a projekt előrehaladásának fő mutatója. Egy agilis projekt befejezésének megközelítését a rendelkezésre álló mennyiség alapján ítélik meg Ebben a pillanatban a program megfelel a megrendelő igényeinek.
8. Az agilis folyamatok elősegítik a hosszú távú fejlődést. Az ügyfeleknek, fejlesztőknek és felhasználóknak a végtelenségig állandó ütemben kell tartaniuk.
9. A mérnöki kiválóságra és a minőségi tervezésre való szakadatlan összpontosítás növeli az értékét rugalmas technológiák. Az agilis csapattagok arra törekszenek, hogy minőségi kódot hozzanak létre rendszeres átalakításokkal.
10. Az egyszerűség annak művészete, hogy kevesebbet csinálva többet érjünk el. A csapat tagjai az aktuális feladatokat a lehető legegyszerűbben és leghatékonyabban oldják meg. Ha a jövőben probléma adódna, akkor lehetőség van a minőségi kód módosítására nagy költség nélkül.
11. A legjobb architektúrák, követelmények és tervek önszerveződő csapatoktól származnak. A rugalmas csapatokban a feladatokat nem egyes tagokhoz, hanem a csapat egészéhez osztják ki. A csapat maga dönti el, hogyan valósítja meg a legjobban az ügyfél igényeit. A csapat tagjai a projekt minden területén együttműködve dolgoznak. Minden résztvevő hozzájárulhat a közös ügyhöz. A csapat egyetlen tagja sem felelős kizárólag az architektúráért, a követelményekért vagy a tesztekért.
12. A csapatnak rendszeresen át kell gondolnia, hogyan válhat még hatékonyabbá, majd ennek megfelelően igazítsa és finomítsa viselkedését. Egy agilis csapat folyamatosan módosítja szervezetét, szabályait, megállapodásait és kapcsolatait.

A fenti elvek bizonyos mértékig megfelelnek számos szoftverfejlesztési módszertannak:

Agilis modellezés	koncepciók, elvek és technikák (gyakorlatok) összessége, amely lehetővé teszi a szoftverfejlesztési projektekben a modellezés és a dokumentáció gyors és egyszerű végrehajtását;
Agilis egységes folyamat (AUP)	az IBM RationalUnifiedProcess(RUP) egyszerűsített változata, amely egy egyszerű és érthető közelítést (modellt) ír le az üzleti alkalmazások szoftvereinek elkészítéséhez;
Nyit	ez a szoftverfejlesztés iteratív-növekményes módszere. Könnyű és rugalmas RUP opcióként van elhelyezve;
AgileDataMethod	iteratív szoftverfejlesztési módszerek csoportja, amelyben a követelmények és a megoldások különböző, többfunkciós csapatok együttműködésével valósulnak meg;
DSDM	a gyors alkalmazásfejlesztés (RapidApplicationDevelopment, RAD) koncepcióján alapuló dinamikus rendszerek fejlesztésének módszertana. Ez egy iteratív és inkrementális megközelítés, amely ad különleges jelentése a felhasználó/fogyasztó folyamatos bevonása a folyamatba;
Extrém programozás (XP)	extrém programozás;
Adaptív szoftverfejlesztés (ADD)	adaptív szoftverfejlesztés;
Funkcióvezérelt fejlesztés (FDD)	a funkcionalitás fokozatos kiegészítésére összpontosító fejlesztés;
Igazivá válni	iteratív megközelítés a webes alkalmazásokhoz használt funkcionális specifikációk nélkül;
MSFfogAgileSoftwareDevelopment	Agilis szoftverfejlesztési módszertan a Microsofttól;
Dulakodás	szabályokat állapít meg a fejlesztési folyamat irányítására, és lehetővé teszi a meglévő kódolási gyakorlatok használatát a követelmények módosításával vagy taktikai változtatásokkal [

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. Az érintettek és a munkavállalók.

3. A követelmények azonosítása és elemzése. Szoftverkövetelmények. Követelményfejlesztési rendszer. 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és és felülvizsgálat. Célok tesztelése. Ellenőrzés, érvényesítés és rendszer tesztelése. Karbantartás és folyamatos fejlesztés.

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

6. Folyamatmodell tervezése. A folyamatkövetelmények azonosítása. Használt fázisok, mérföldkövek és műtermékek. A folyamat architektúra kiválasztása. Egy tipikus projekt lebonyolításának eljárása. dokumentált eljárások.

7. A fejlesztő csapat modelljei. A fejlődé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. A fejlesztő csapat modelljei. Hierarchikus csapatmodell. A sebészi csapat módszere. Egyenlő felek csapatának modellje.

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ális 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. Koncepció kialakítása. Logikai 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. szoftverrendszereket terveznek és készítenek. Moszkva: Nauka, 1975; új fordítási kiadás: Mitikus emberhónap. Szentpétervár: 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 menedzsereknek

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. Ciklikus ingadozások elsimí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 gazdaságban. 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, a fedezeti pont grafikus ábrázolása. A befektetési politika megvalósításának módszertana.

Közgazdaságelméleti kurzus: tankönyv egyetemeknek / Szerk. . -Kirov: "ACA", 2004. Kolemaev - matematikai modellezés. Makrogazdasági folyamatok és rendszerek modellezése: tankönyv. M.: UNITY-DANA, 2005. Bazhin kibernetika. Kharkiv: Consul, 2004. Leushin workshop a matematikai modellezés módszereiről: tankönyv. Nyizsnyij Novgorod állam tech. egyetem - N. Novorod, 2007. Politikusok a gazdaságról: Nobel-díjasok közgazdasági előadásai. Moszkva: Modern Közgazdaságtan és Jog, 2005. Cseremnyk. Emelt szint: Tankönyv.-M.:INFRA-M, 2008. A minigazdasági intézmények fejlődése. Az Orosz Tudományos Akadémia Uráli Fiókjának Közgazdaságtudományi Intézete, - M.: Nauka, 2007.

Technológiák vezetői döntések kidolgozásához és elfogadásához [N]

A döntéshozatal 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. Alapvető döntéshozatali módszerek. A döntéshozatal akaratlagos módszerei. Döntéshozatali célok. Ideje megoldásokat találni. Alapvető hibák A döntéshozatal matematikai módszerei. A döntéshozatal elméletének 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éshozatal elméletének matematikai vonatkozásai. Sorelméleti modellek. Készletgazdálkodási modellek. Lineáris programozási modell. szállítási feladatokat. 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. Módszer a csoportkohézió meghatározására a halmazok kapcsoltsági foka alapján. A kollektív döntéshozatal módszerei. konszenzusos módszer. szavazási módszerek. Kreatív döntéshozatali módszerek. Ötletelés. Ötletkonferencia. Hajótanács. A mentális kalapok módszere, de Bono. A feltaláló problémamegoldás elmélete (TRIZ). Az ideális végmegoldás. Példák problémákra és megoldásukra a TRIZ segítségével. A TRIZ módszerek alkalmazása egyedi és kreatív döntések meghozatalában. Megoldási ötletek kidolgozásának és a helyzethez igazításának módszerei. Célfa modell. Az érdekegyeztetés stratégiája. Érdekegyeztetési 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. A szakértői rendszer tipikus felépítése. A tudásreprezentáció módjai. Logikai következtetés módszerei. Szakértői rendszerek alkalmazása a gyakorlatban.

I. A döntéshozatal elmélete: tankönyv. - M.: Vizsga, 2006. - 573 p. I. Döntéshozatal. A vezetői döntések fejlesztésének elmélete és módszerei. Oktatóanyag. - M.: 2005. március - 496 p Vezetői döntés kidolgozása - M.: Delo Kiadó, 2004 - 392 p. 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. - S. 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.: "Statistics" 1973. O. Kim, C. W. Muller, W. R. Klekka és munkatársai: Factor, discriminant and cluster analysis. 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.: elvégezni az iskolát, 2005. , ; szerk. . 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

Mik az üzleti folyamatok alapelvei? 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 diagramjain szereplő művek, hogyan jelennek meg az IDEF0 módszertan szerint? Mire szolgálnak a nyilak a funkcionális modell diagramokon, milyen típusok és típusok vannak? DFD módszertan. Lényeg. A DFD diagramok alapvető összetevői. Melyek a DFD-diagramok jellemzői, mit írnak le bennük? Melyek a DFD-diagram objektumok jellemzői? Mit jelentenek a nyilak a DFD diagramon? IDEF3 módszertan. Lényeg. Dokumentációs és modellezési eszközök. Mik az IDEF3 diagramok jellemzői, mit írnak le? 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 vállalat irányításában? Folyamatok monitorozása, mérése. A szervezet folyamatainak 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. "Dialogue-MEPhI" 2003 "A funkcionális modellezés gyakorlata az AllFusion Process Modeler 4.1-el. (BPwin) Hol? Miért? Hogyan?" szerk. "Dialogue-MEPhI" 2004 Dubeikovsky 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. Moszkva: Gosstandart of Russia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Üzleti folyamatok modellezése a BPwin segítségével http://www. /department/se/devis/7/ IDEF0 az üzleti folyamatok modellezésének kezelé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. 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 Operations and Maintenance 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ése

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ényeire vonatkozó szellemi tulajdonjogokat, és hozza nyilvánosságra azok tartalmát.

2. Sorolja fel a kizárólagos jog feletti rendelkezési szerződések típusait! Mutassa be ezeket a kizárólagos jogról szóló szerződéseket.

4. Ismertesse a Számítógépes Program, mint szerzői jog tárgya jogi védelmének főbb rendelkezéseit!

5. Hasonlítsa össze az Adatbázis, mint szerzői és szomszédos jogok tárgya jogi védelmének főbb rendelkezéseit!

6. Ismertesse a szabadalmi jogok tárgyai szabadalmazhatóságának feltételeit: találmányok; hasznos modellek; ipari 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 időtartamát!

9. Adja meg a „know-how” definícióját, és sorolja fel azokat a feltételeket, amelyek mellett a gyártási titkok jogi védelme felmerül és megvalósul.

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

1., Szellemi tulajdonjog az Orosz Föderációban, tankönyv // M, Prospekt, 2007

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

Projektmenedzsment és szoftverfejlesztés [R]

Mi az a módszertan, miért van rá szükség. Általános szerkezet módszertan, módszertani alapelemek. Saját módszertan kialakításának elvei. Példák különféle műtermékekre, szerepekre, kompetenciákra, peremfeltételekre. Cowburn módszertan szerkezete, módszertani mérőszámai. Cowburn projekt kritériumai. Módszertani kiválasztási kritériumok, 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 mint egy iteratív módszertan példája. RUP alapfogalmak, alkalmazhatósági korlátok. Az emberi szerep a szoftverfejlesztésben. Agilis módszertanok, az agilis módszertanok alapelvei. Az agilis módszertanok eredete. A Scrum az agilis módszertan példájaként. Szerepek, tárgyak, tevékenységek a Scrumban. A Scrum alkalmazási határai. 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 összegyűjtése és kezelése. Alapvető gyakorlatok, kifejezések, alapelvek. A projekt és a termék dokumentálásának megközelítései, a 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 összeszerelés (build) fogalma, a kódtárolás módjai, eszközök. Két alapelv a verziókezelő rendszerrel való munka megszervezéséhez. A termékkiadási/elrendezési folyamat 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 Frederic Brooks – A mitikus emberhónap avagy hogyan jönnek létre a szoftverrendszerek. Tom de Marco – Határidő. Regény a projektmenedzsmentről. Tom de Marco, Timothy Lister – Keringős medvékkel. Tom de Marco, Timothy Lister – Az 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 szoftverfejlesztés legfontosabb összetevői. Andrij Orlov – Egy automata feljegyzései. Szakmai vallomás. Philip Krachten – Bevezetés a racionális egységes folyamatba. Henrik Kniberg - Scrum és XP: jegyzetek az élvonalból. Tanfolyami előadások prezentációi

1. Cascade (angol vízesés) - szabványos fejlesztési modell

Kaszkádos fejlesztési modell - olyan modell, amelyben a fejlesztés minden szakaszát egymás után hajtják végre - a következő szakasz az előző befejezése után kezdődik.

Ez a modell a szoftverfejlesztési folyamat következő lépéseit tartalmazza:

Először is meghatározzák a jövőbeli program műszaki paramétereit, ennek eredményeként jóváhagyják a szoftverkövetelmények listáját. Ezután következik a tervezésre való áttérés, melynek során dokumentáció készül, amely leírja a programozók számára a tervet és a követelmények megvalósításának módját.

A tervezés befejezése után a programozók megvalósítják (konstruálják) a projektet. A megvalósítás szakaszában a projekt összes összetevője integrálva van. Csak ezeknek a szakaszoknak a teljes befejezése után kerül sor a késztermék tesztelésére és hibakeresésére. Továbbá a szoftvertermék implementálható, és a megvalósítás után támogatást nyújthat - új funkcionalitást vezet be, és kiküszöbölheti a hibákat.

A vízesés fejlesztésének fő előnyei:

2. Agilis szoftverfejlesztési módszertan

Szoftverfejlesztési módszerek készlete, amely magában foglalja az ügyfelek képviselői és a fejlesztők közötti együttműködést. Az agilis fejlesztési módszer az iteratív megközelítésen, a követelmények dinamikus kialakításán és azok rövid szakaszokban történő megvalósításán alapul.

Minden ilyen szakasz eredménye, beleértve az iterációs ciklust is, egy miniatűr szoftverprojekt,

Számos agilis fejlesztési módszer létezik, a leghíresebbek a Scrum, Extreme Programming, DSDM.

Az agilis fejlesztés fő előnyei:

		kockázat minimalizálása; a szoftvertermék funkcionalitásának fokozatos növelése; kis mennyiségű írásos dokumentáció; dob alap verzió programokat a lehető leghamarabb.
Vannak hátrányai is:
		képtelenség pontosan meghatározni a projekt költségvetését; a projekt készenlétének pontos időzítésének lehetetlensége; nem alkalmas állami és költségvetési szervezetek számára; motivációt igényel az ügyfél felelős képviselőitől.

Agilis szoftverfejlesztési kiáltvány Folyamatosan jobb módszereket fedezünk fel a szoftverfejlesztés közvetlen fejlesztésével és mások segítésével. Az elvégzett munkának köszönhetően rájöttünk, hogy: Emberek és interakció fontosabb, mint a folyamatok és az eszközök Működő termék fontosabb, mint az átfogó dokumentáció Együttműködés az ügyféllel fontosabb, mint a szerződés feltételeinek tárgyalása A változásra való felkészültség sokkal fontosabb az eredeti tervet követve Vagyis anélkül, hogy tagadnánk a jobb oldali jelentőségét, mégis jobban értékeljük azt, ami a bal oldalon van.

Az agilis fejlesztés alapelvei:

Ügyfél-elégedettség a szükséges szoftverek gyors és zavartalan szállítása miatt; már a fejlesztés végén is üdvözöljük a követelmények változását (ez növelheti a keletkező termék versenyképességét); működő szoftverek gyakori szállítása (havonta vagy hetente vagy még gyakrabban); szoros, napi kommunikáció a megrendelő és a fejlesztők között a projekt során; a projektet motivált személyek hajtják végre, akik számára biztosítottak a szükséges munkakörülmények, támogatás és bizalom; az információátadás javasolt módja a személyes beszélgetés (szemtől szemben); a működő szoftver a fejlődés legjobb mércéje; a szponzoroknak, a fejlesztőknek és a felhasználóknak a végtelenségig állandó tempót kell tartaniuk; állandó összpontosítás a műszaki kiválóság és a felhasználóbarát tervezés javítására; egyszerűség - a művészet, hogy ne végezzünk felesleges munkát; a legjobb technikai követelmények, a tervezést és az építészetet egy önszerveződő csapattól szerzik be; állandó alkalmazkodás a változó körülményekhez.