Tehát az EIS szoftverek fejlesztésének strukturális megközelítésének lényege az automatizált funkciókra való lebontásában (particionálásában) rejlik: a rendszer funkcionális alrendszerekre oszlik, amelyek viszont alfunkciókra, ezek feladatokra, stb. meghatározott eljárásokig. Ugyanakkor a rendszer megőrzi a holisztikus nézetet, amelyben az összes alkotóelem összekapcsolódik. Az "alulról felfelé" építkező rendszer kialakítása során az egyes feladatoktól a teljes rendszerig elvész az integritás, problémák merülnek fel az egyes komponensek információs interakciójának leírásánál.
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 rendezés elve - a rendszer alkotórészeinek hierarchikus fastruktúrákba szervezésének elve, minden szinten új részletek hozzáadásával.
A két alapelv kiválasztása 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 a teljes projekt kudarcát is). Ezen elvek főbbek a következők:
1. Az absztrakció elve - a rendszer lényeges aspektusainak kiemelése és a figyelemelvonás a nem lényegestől.
2. A rendszer elemeinek konzisztenciájá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 alapvetően 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) - adatfolyamok diagramjai;
SADT (Structured Analysis and Design Technique - szerkezeti elemzés és tervezés módszertana) - modellek és megfelelő funkcionális diagramok: IDEF0 (rendszerek funkcionális modellezése), IDEF1x (adatbázisok fogalmi modellezése), IDEF3x (egy objektum minőségének felmérésére szolgáló építési rendszerek) jelölések az áramlási folyamatok grafikus leírása, a folyamatok és a folyamatok által megváltoztatott objektumok interakciója);
· ERD (Entity - Relationship Diagrams) - "entitás-kapcsolat" diagramok.
A strukturális megközelítés (strukturális elemzés) szinte minden módszerében a modellező eszközök két csoportját használják a szoftverkövetelmények kialakításának szakaszában:
1. A rendszernek végrehajtandó funkciókat és a funkciók közötti kapcsolatokat bemutató diagramok - DFD vagy SADT (IDEF0).
2. Adatokat és kapcsolataikat modellező diagramok (ERD).
A felsorolt diagramok konkrét formája és felépítésük é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, valamint a köztük lévő kölcsönhatást. (A SADT modellek használata általában csak erre a szakaszra korlátozódik, mivel eredetileg nem szoftvertervezésre készültek). Az ERD segítségével a szervezetben használt adatok fogalmi szintű leírása valósul meg, függetlenül az adatbázis (DBMS) megvalósításának eszközeitől.
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.
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 elég a kiadáshoz új verzió termék, érthető, 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é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ó. 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:
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.
A működő 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. Rugalmas alkotási módszerek szoftver termékek a következő elveken alapulnak:
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. Iteratív és inkrementális megközelítést képvisel, amely hangsúlyozza a felhasználó/fogyasztó folyamatos részvételét a folyamatban; |
| 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 [ |
A szoftverfejlesztésben a mai napig két fő megközelítés létezik az EIS szoftverek fejlesztésében, amelyek közötti alapvető különbség az, hogy különböző utak rendszerek bomlása. 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 egyes funkcionális elemek közötti információátadásban írják le. 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özöttük lévő kapcsolatok, a rendszer viselkedését pedig az objektumok közötti üzenetváltással írjuk le.
Tehát az EIS szoftverek fejlesztésének strukturális megközelítésének lényege az automatizált funkciókra való lebontásában (particionálásában) rejlik: a rendszer funkcionális alrendszerekre oszlik, amelyek viszont alfunkciókra, ezek feladatokra, stb. meghatározott eljárásokig. Ugyanakkor az automatizált rendszer megőrzi a 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 kölcsönhatásának leírásánál.
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);
hierarchikus rendezés elve - a rendszer alkotórészeinek hierarchikus fastruktúrákba szervezésének elve, minden szinten új részletek hozzáadásával.
A két alapelv kiválasztása 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 szempontjainak kiosztása és a figyelem elterelése a nem lényeges szempontokról;
a következetesség elve - a rendszer elemeinek érvényessége és konzisztenciája;
az adatstrukturálás elve - az adatokat strukturáltnak és hierarchikusan kell szervezni.
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ési és tervezési módszer,) - 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.
A felsorolt diagramok konkrét formája és felépítésük értelmezése a szoftver életciklusának szakaszától függ.
A szoftverrel szemben támasztott kö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, valamint a (a SADT modellek használata általában csak erre a szakaszra korlátozódik, mivel eredetileg nem szoftvertervezésre készültek). Az ERD segítségével a szervezetben használt adatok leírása az adatbázis implementációs eszközöktől (DBMS) független fogalmi szinten történik.
A tervezési szakaszban a DFD-k segítségével leírják a megtervezett szoftverrendszer felépítését, miközben finomíthatók, bővíthetők és ú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 diagramokkal, amelyek tükrözik a szoftver rendszerarchitektúráját, a programok blokkdiagramjait, a képernyő formák és menük hierarchiáját stb.
A felsorolt modellek együtt adnak Teljes leírás EIS szoftver, függetlenül attól, hogy a rendszer meglévő vagy új fejlesztésű. A diagramok összetétele minden 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árgyköre 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 az Orosz Föderáció adórendszerében használják bizonyos jellemzőkkel.
Ma a szoftverfejlesztésben az IS szoftverek fejlesztésének két fő megközelítése létezik, amelyek közötti alapvető különbség a rendszerek különböző dekompozícióiból adódik: a funkcionális-moduláris (strukturális) megközelítés, amely a funkcionális dekompozíció elvén alapul, amelyben a rendszer felépítése a funkcióinak hierarchiájában és az egyes funkcionális elemek közötti információátadásban van leírva, és objektum orientált megközelítés, amely objektumdekompozíciót használ, leírja az IS szerkezetét az objektumok és a köztük lévő kapcsolatok szempontjából, valamint a rendszer viselkedését az objektumok közötti üzenetküldés szempontjából.
Tehát az IS szoftverek fejlesztésének strukturális megközelítésének lényege az automatizált funkciókra bontásban rejlik: a rendszer funkcionális alrendszerekre oszlik, amelyek viszont alfunkciókra, feladatokra vannak osztva, és így tovább egészen konkrétig. eljárások. Ugyanakkor az IS megőrzi a reprezentáció integritását, ahol minden 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 kölcsönhatásának leírásánál.
A strukturális megközelítés alapelvei a következők:
o elv" Oszd meg és uralkodj";
o elv hierarchikus rendezés - a komponensrendszerek hierarchikus fastruktúrákba szervezésének elve, minden szinten új részletek hozzáadásával. A két alapelv kiválasztása nem jelenti azt, hogy a fennmaradó elvek másodlagosak, hiszen bármelyik figyelmen kívül hagyása beláthatatlan következményekhez vezethet.
Ezen elvek főbbek a következők:
o absztrakció - a rendszer lényeges szempontjainak kiemelése;
o következetesség - a rendszer elemeinek érvényessége és konzisztenciája;
o adatstrukturálás - az adatoknak strukturáltnak és hierarchikusan rendezettnek kell lenniük.
Vizuális modellezés. A szoftvermodellt általában egy szoftverrendszer formalizált leírásának nevezik az absztrakció bizonyos szintjén. Mindegyik modell meghatározza a rendszer egy adott aspektusát, diagramok és dokumentumok halmazát használja adott formátumban, és tükrözi a különböző emberek gondolatait és tevékenységeit, akiknek meghatározott érdeklődési körük, szerepük vagy feladatuk van.
A grafikus (vizuális) modellek a rendszerarchitektúra megjelenítésére, leírására, tervezésére és dokumentálására szolgáló eszközök. Az egyes projektekben használt modellek összetétele, általános esetben részletességük a következő tényezőktől függ:
o a megtervezett rendszer nehézségei;
o leírásának szükséges teljessége;
o a projekt résztvevőinek ismeretei és készségei;
o tervezésre szánt idő.
A vizuális modellezés különösen a CASE-eszközök fejlesztését befolyásolta nagyban. A CASE (Computer Aided Software Engineering) fogalmát tág értelemben használják. Ennek a fogalomnak az eredeti jelentése, amely csak a szoftverfejlesztés automatizálásának feladataira korlátozódik, mára új értelmet nyert, lefedi a szoftver életciklus-folyamatainak nagy részét.
A CASE technológia szoftvertervezési módszerek halmaza, valamint egy sor eszközöket, amely lehetővé teszi vizuális formában a témakör modellezését, a modell elemzését a szoftverfejlesztés és -karbantartás minden szakaszában, valamint alkalmazások fejlesztését a felhasználók információs igényei szerint. A legtöbb létező CASE-eszköz strukturális vagy objektumorientált elemzési és tervezési módszereken alapul, diagramok vagy szövegek formájában megjelenő specifikációkat használva a külső követelmények, a rendszermodellek közötti kapcsolatok, a rendszer viselkedési dinamikájának és a szoftverarchitektúrák leírására.
Az első részben a szoftverfejlesztési módszertanok összehasonlítását választottuk, olyan mutatókat, mint a módszertan és az iteratív fejlesztés aránya, valamint a formalitás mértéke a munkaanyagok tervezésében és általában a fejlesztésben. Ebben a részben ezeket a mérőszámokat használjuk a legismertebb szoftverfejlesztési gyakorlatok összehasonlítására.
Sajnos ez a legnehezebben leírható kategória – elvégre ez magában foglalja mind az első projektjét bármi áron befejezni próbáló kezdő görcsös dobálásának termékét, mind a meglehetősen kiforrott és jól bevált módszereket, amelyek sok évet magukba szívtak. konkrét fejlesztőcsapatok sokrétű tapasztalata, sőt belső szabályzatban is le vannak írva. Mivel azok, akik képesek saját módszertanukat kidolgozni, általában maguk is tudják értékelni azt iteráció és formalizálás szempontjából, ezért a kezdőkre fogunk összpontosítani. Sajnos ez leggyakrabban azt jelenti, hogy a fejlesztés lebonyolítására vonatkozó szabályok vagy egyáltalán nem léteznek, vagy kidolgozták és elfogadták, de nem hajtják végre. Természetes ilyen körülmények között rendkívül alacsony szintű fejlődési formalizmus. Szóval ez minden világos.
Fejlesztés "Hogyan működik"
Mit szólnál egy iteratív megközelítéshez? Sajnos általában nem használják ilyen projektekben. Mindenekelőtt azért, mert ez már az első iterációknál lehetővé tenné, hogy a projektet rendkívül kétesnek ítéljék meg, és a rend helyreállításához a felsőbb vezetés sürgős beavatkozását igénylőnek minősítsék. Hiszen egy iteratív projektben a programozó hagyományos válasza, hogy minden 90%-ban készen van, csak az első iteráció befejezéséig tart…
Strukturális módszertanok
A strukturális módszerek olyan módszertanok csoportja, amelyeket rendszerint még az objektum-orientált nyelvek elterjedése előtt fejlesztettek ki. Mindegyik lépcsőzetes fejlesztést tartalmaz. Bár, mint kiderült, abban a cikkben, amelyet gyakran emlegetnek a vízesés-szemlélet első bemutatásaként, elhangzott, hogy kívánatos egy prototípus kifejlesztésével kezdeni a projektet, vagyis legalább két iteráció.
Mindazonáltal ezeknek a módszereknek az alapja a munkából a munkába való szekvenciális átmenet és a következő szakasz eredményeinek (dokumentumainak) átadása a következő szakasz résztvevőinek.
Mindezek a módszerek szintén erősen formalizált megközelítést feltételeznek, bár ésszerű mennyiségű dokumentációra vonatkozó kijelentések találhatók bennük. Az egyik nem kézenfekvő példa arra, hogy a szoftverfejlesztési módszertanok nem csak nyugaton alakultak ki, egy idézet egy nálunk a nyolcvanas évek elején megjelent könyvből, amely szerint egy programozási feladat formalizáltsági fokát kell meghatározni. hogy milyen jól az elemző és a programozó. És mindez annak ellenére, hogy a könyv témája meglehetősen kritikus, mai nevén rendszerek kifejlesztése volt, amelyek hibái komoly veszteségekhez vagy akár katasztrófákhoz vezetnek.
Az agilis módszertanok tíz alapelven alapulnak, amelyek közül csak azokat nevezzük meg, amelyek meghatározzák ezen módszerek értékelését a kiválasztott paraméterek szerint:
Így ezek a módszerek egyértelműen az iteratív szoftverfejlesztésre és a folyamat minimális formalizálására összpontosítanak. A második ponttal kapcsolatban azonban fenntartással kell élni: ezek a módszerek az adott projekt számára elfogadható minimális formalizáltsági szintre összpontosítanak. A rugalmas csoportba tartozó módszerek közül legalább egy - a Crystal - olyan módosításokat tartalmaz, amelyek különböző résztvevőszámú és a kifejlesztett szoftver eltérő kritikusságú folyamatainak végrehajtására szolgálnak (a szoftver kritikusságát a hibák lehetséges következményei határozzák meg, amelyek a jelentéktelentől eltérőek lehetnek pénzügyi veszteség hogy a hibákat katasztrofálisra javítsák). Annak érdekében, hogy a rugalmas módszerekkel való további összehasonlítás ne legyen értelmetlen, bemutatjuk rövid leírások több közülük.
A Kent Beck, Ward Cunningham és Ron Jeffries által kidolgozott XP módszertan a legismertebb az agilis módszertanok közül napjainkban. Néha az „agilis módszertanok” fogalmát kifejezetten vagy implicit módon azonosítják az XP-vel, amely a társaságiságot, az egyszerűséget, a visszajelzést és a bátorságot hirdeti. Gyakorlatok összességeként írják le: játék tervezése, rövid kiadások, metaforák, egyszerű tervezés, átalakítás, tesztelés előtti fejlesztés, páros programozás, kódmegosztás, 40 órás munkaidő munkahét, vásárlói jelenlét és kódszabványok. Az XP iránti érdeklődés alulról felfelé nőtt – a fejlesztők és tesztelők részéről, akiket fájdalmas folyamat, dokumentáció, mérőszám és egyéb formalizmus gyötört. Nem utasították el a fegyelmet, de nem voltak hajlandók értelmetlenül követni a formai követelményeket, és új, gyors és rugalmas megközelítéseket kerestek a színvonalas programok kidolgozásához.
XP használatakor a gondos előzetes szoftvertervezést felváltja egyrészt a megrendelő állandó jelenléte a csapatban, készen válaszolni minden kérdésre és kiértékelni bármilyen prototípust, másrészt a rendszeres kódrevíziók (ún. refaktorálás). Az alaposan kommentált kód a tervdokumentáció alapja. A módszertanban nagy figyelmet fordítanak a tesztelésre. Általános szabály, hogy minden új metódushoz először egy tesztet írnak, majd a tényleges metóduskódot fejlesztik, amíg a teszt sikeresen el nem indul. Ezek a tesztek olyan csomagokban vannak tárolva, amelyek minden kódmódosítás után automatikusan végrehajtásra kerülnek.
Bár a páros programozás és a 40 órás munkahét az XP talán legismertebb funkciója, továbbra is támogató jellegűek, és hozzájárulnak a magas fejlesztői termelékenységhez és a fejlesztési hibák csökkentéséhez.
A Crystal olyan módszertancsalád, amely a résztvevők számától és a feladatok kritikusságától függően meghatározza a fejlesztési folyamat formalizáltságának szükséges mértékét.
A Crystal Clear módszertana teljesítményben gyengébb az XP-nél, de a lehető legkönnyebben használható. Megvalósítása minimális erőfeszítést igényel, mert az emberi szokásokra összpontosít. Úgy gondolják, hogy ez a módszertan a szoftverfejlesztés természetes rendjét írja le, amely kellően képzett csapatokban jön létre, ha nem vesznek részt más módszertan célirányos megvalósításában.
A Crystal Clear legfontosabb tulajdonságai:
A Crystal Clear mellett számos más módszer is található a Crystal családban, amelyeket nagyobb vagy kritikusabb projektekre terveztek. A dokumentáció mennyiségére és a támogató eljárásokra, például a változtatásokra és a verziókezelésre vonatkozó, kissé szigorúbb követelményekben különböznek egymástól.
A Feature Driven Development (FDD) olyan rendszerfunkció vagy szolgáltatás szempontjából működik, amely meglehetősen közel áll a RUP használati eset koncepciójához. A legjelentősebb különbség talán egy további korlátozás: "minden egyes funkciónak legfeljebb két hét alatt kell megvalósítania." Vagyis ha elég kicsi a használati eset, akkor függvénynek tekinthető, ha pedig nagy, akkor több, viszonylag független függvényre kell bontani.
Az FDD öt folyamatot tartalmaz, amelyek közül az utolsó kettő minden funkciónál megismétlődik:
A projekten végzett munka gyakori felépítésekkel jár, és iterációkra oszlik, amelyek mindegyikét egy adott szolgáltatáskészlet segítségével valósítják meg.
Az FDD fejlesztőit "osztálymesterekre" és "főprogramozókra" osztják. A fő programozók bevonják az érintett osztályok tulajdonosait, hogy a következő ingatlanon dolgozzanak. Összehasonlításképpen: XP-ben nincs személyes felelősség az osztályokért vagy metódusokért.
A rugalmas módszertanok listája jelenleg meglehetősen széles. Mindazonáltal az általunk leírt módszertanok nagyon teljes képet adnak az egész családról.
Szinte minden agilis módszertan iteratív megközelítést alkalmaz, amelyben csak a következő kiadás kiadásához kapcsolódó korlátozott mennyiségű munkát terveznek meg részletesen.
Szinte minden agilis módszertan a fejlesztés leginformálisabb megközelítésére összpontosít. Ha a probléma egy normális beszélgetés során megoldható, akkor jobb, ha ezt tesszük. Ezenkívül a határozatot papír vagy elektronikus dokumentum formájában csak akkor kell elkészíteni, ha e nélkül lehetetlen.
Agilis módszertanok
A GOST-ok, akárcsak a következő részben ismertetett CMM-követelmények, nem módszertanok. Általában nem magukat a szoftverfejlesztési folyamatokat írják le, hanem csak bizonyos követelményeket fogalmaznak meg a folyamatokkal szemben, amelyeknek különböző módszertanok felelnek meg ilyen vagy olyan mértékben. A követelmények összehasonlítása ugyanazon kritériumok szerint, amelyek alapján a módszereket összehasonlítjuk, azonnal eldöntheti, hogy melyik módszertant használja, ha a GOST-nak megfelelően kell fejlesztenie.
Jelenleg Oroszországban a régi, 19. és 34. sorozatú GOST, valamint az újabb GOST R ISO IEC 122207. A 19. és 34. sorozatú GOST szigorúan a szoftverfejlesztés lépcsőzetes megközelítésére összpontosít. Ezekkel a GOST-okkal összhangban a fejlesztés szakaszokban történik, amelyek mindegyike szigorúan meghatározott munka elvégzését foglalja magában, és meglehetősen nagy számú, nagyon formalizált és kiterjedt dokumentum kiadásával zárul. Így ezeknek a szabványoknak az azonnali szigorú betartása nemcsak vízesés-szemlélethez vezet, hanem a fejlesztés igen magas fokú formalizálását is biztosítja.
GOST követelmények
A GOST 12207 a 19. és 34. sorozat szabványaival ellentétben a szoftverfejlesztést fő- és segédfolyamatok összességeként írja le, amelyek a projekt elejétől a végéig működhetnek. Az életciklus modell a projekt jellemzői alapján választható ki. Így ez a GOST nem tiltja kifejezetten az iteratív megközelítés alkalmazását, de kifejezetten nem is ajánlja annak használatát. A GOST 12207 rugalmasabb a fejlesztési folyamat formalitására vonatkozó követelmények tekintetében is. Csak utalásokat tartalmaz az összes folyamat főbb eredményeinek dokumentálásának szükségességére, de nem tartalmazza a szükséges dokumentumok listáját és a tartalmukra vonatkozó utasításokat.
Így a GOST 12207 lehetővé teszi az iteratív és kevésbé formalizált szoftverfejlesztést.
A nemzeti és nemzetközi szabványok mellett számos megközelítés létezik a fejlesztési folyamat tanúsítására. Oroszországban a leghíresebbek a CMM és a CMMI.
A CMM (Capability Maturity Model) a szoftverfejlesztési folyamatok érettségi modellje, amely egy adott vállalat fejlesztési folyamatának érettségi szintjének felmérésére szolgál. E modell szerint a fejlesztési folyamat érettségének öt szintje van. Az első szint a „hogyan megy” fejlesztésnek felel meg, amikor a fejlesztők minden projekthez bravúrként mennek hozzá. A második a többé-kevésbé jól bevált folyamatoknak felel meg, amikor kellő magabiztossággal lehet számítani a projekt pozitív kimenetelére. A harmadik a fejlesztés során használt kidolgozott és jól leírt folyamatok meglétének, a negyedik pedig a mérőszámok aktív felhasználásának az irányítási folyamatban a célok kitűzésére és azok elérésének nyomon követésére. Végül az ötödik szint a vállalat azon képességére vonatkozik, hogy szükség szerint optimalizálja a folyamatot.
CMM és CMMI követelmények
A CMM megjelenése után speciális érettségi modelleket kezdtek fejleszteni a létrehozáshoz információs rendszerek, a beszállítók kiválasztásának folyamatához és néhány máshoz. Ezek alapján egy integrált CMMI modellt (Capability Maturity Model Integration) fejlesztettek ki. Emellett a CMMI-ben kísérlet történt a CMM addigra megnyilvánuló hiányosságainak áthidalására - a folyamatok formális leírásának szerepének eltúlzására, amikor bizonyos dokumentációk meglétét sokkal magasabbra értékelték, mint egy jól bevált, de nem leírt folyamat. A CMMI azonban egy erősen formalizált folyamat használatára is összpontosít.
Így a CMM és CMMI modellek alapja a fejlesztési folyamat formalizálása. A szabályzatban és utasításban részletesen leírt folyamat megvalósítását célozzák meg a fejlesztők, amihez viszont nagy mennyiségű projektdokumentáció kidolgozása szükséges a megfelelő ellenőrzéshez és jelentéstételhez.
A CMM és a CMMI kapcsolata az iteratív fejlesztéssel közvetettebb. Formálisan egyikük sem támaszt konkrét követelményeket a vízeséshez vagy az iteratív megközelítéshez való ragaszkodáshoz. Egyes szakértők szerint azonban a CMM jobban kompatibilis a vízesés megközelítéssel, míg a CMMI lehetővé teszi az iteratív megközelítést is.
Természetesen a RUP egy iteratív módszertan. Bár formálisan az összes fázis kötelező végrehajtása vagy bizonyos minimális számú iteráció nincs feltüntetve a RUP-ban, az egész megközelítés arra irányul, hogy ezekből elég sok van. Az iterációk korlátozott száma nem teszi lehetővé a RUP teljes előnyeinek kihasználását. Ugyanakkor a RUP szinte lépcsőzetes projektekben is használható, amelyek valóban csak néhány iterációt tartalmaznak: az egyik a Build fázisban, a másik pedig az átviteli fázisban. Mellesleg, ez az iterációk száma, amelyet ténylegesen használnak a vízesés projektekben. Hiszen a rendszer tesztelése, próbaüzeme magában foglalja a korrekciók elvégzését is, amelyek bizonyos elemzéssel, tervezéssel, fejlesztéssel kapcsolatos tevékenységeket is magukban foglalhatnak, vagyis tulajdonképpen egy újabb áthaladást jelentenek a fejlesztés minden fázisán.
RUP módszertan
Ami a módszertan formalitását illeti, a RUP nagyon széles lehetőségeket kínál a felhasználónak. Ha elvégzi az összes munkát és feladatot, elkészíti az összes műtárgyat, és meglehetősen formálisan (hivatalos lektorral, a teljes felülvizsgálat elkészítésével elektronikus vagy papíralapú dokumentum formájában stb.) lefolytatja az összes felülvizsgálatot, a RUP fordulhat rendkívül formális, megfontolt módszertannak tekinthető. Ugyanakkor a RUP lehetővé teszi, hogy csak azokat a műtermékeket fejlessze, és csak azokat a munkákat és feladatokat hajtsa végre, amelyek egy adott projektben szükségesek. A kiválasztott műtermékek pedig tetszőleges fokú formalitás mellett végrehajthatók és áttekinthetők. Előírható minden egyes dokumentum részletes tanulmányozása, gondos kivitelezése, ugyanolyan gondosan elkészített és formalizált felülvizsgálat biztosítása, sőt a régi gyakorlat szerint minden ilyen felülvizsgálat jóváhagyása a vállalkozás tudományos és műszaki tanácsánál. Tudsz korlátozni email vagy vázlatot papírra. Ezen kívül mindig van még egy lehetőség: fejben formálni egy dokumentumot, vagyis átgondolni a releváns kérdést, és konstruktív döntést hozni. És ha ez a döntés csak Önt érinti, korlátozza magát például egy megjegyzésre a programkódban.
Így a RUP egy iteratív módszertan, nagyon széles skálával lehetséges megoldások a fejlesztési folyamat formalizálása szempontjából.
Foglaljuk össze a cikk második részét. A RUP, ellentétben a legtöbb más módszertannal, lehetővé teszi a fejlesztési folyamat formalizálásának és iterációjának széles körben történő kiválasztását, a projektek és a fejlesztő szervezet jellemzőitől függően.
És hogy ez miért olyan fontos - a következő részben tárgyaljuk.
