ICONIX
Az ICONIX egy olyan szoftverfejlesztési módszertan, amely mind a Rational Unified Process (RUP), mind az extrém programozás (XP) és az agilis szoftverfejlesztéssnél korábban jött létre. A RUP-hoz hasonlóan az ICONIX folyamat is UML használati eset alapú, de könnyebb szerkezetű a RUP-nál. Az ICONIX több követelményt és tervezési dokumentációt biztosít, mint az XP, és célja az elemzési bénulás elkerülése. Az ICONIX folyamat mindössze négy UML alapú diagramot használ egy négylépéses folyamatban, amelyben a használati eset szövegét működő kóddá alakítja.
Az ICONIX fő megkülönböztetése a robusztussági elemzés alkalmazása, amely az elemzés és a tervezés közötti szakadék áthidalására szolgál. A robusztusság-elemzés csökkenti a használati esetleírások kétértelműségét azáltal, hogy gondoskodik arról, hogy azokat egy kísérő tartománymodell kontextusában írják meg. Ez a folyamat megkönnyíti a használati esetek tervezését, tesztelését és becslését.
Az ICONIX-folyamatot a Use Case Driven Object Modeling with UML: Theory and Practice című könyv ismerteti.[1]
Lényegében az ICONIX folyamat az alapvető "logikai" elemzési és tervezési modellezési folyamatot írja le. A folyamat azonban különösebb testreszabás nélkül alkalmazható olyan projektekre is, amelyek más projektmenedzsmentet követnek.
Az ICONIX folyamat áttekintése szerkesztés
Az ICONIX folyamat négy mérföldkőből áll. Minden szakaszban felülvizsgálják és frissítik az előző mérföldkőhöz kapcsolódó munkát.
1. mérföldkő: Követelmények felülvizsgálata szerkesztés
Az ICONIX folyamat megkezdése előtt el kell végezni néhány követelményelemzést. Ebből az elemzésből azonosíthatók a használati esetek, egy tartománymodell és néhány GUI prototípus készíthető.
2. mérföldkő: Előzetes tervezési áttekintés szerkesztés
A használati esetek azonosítása után szöveg írható le, amely leírja, hogy a felhasználó és a rendszer hogyan kommunikál egymással. A rendszer robusztussági elemzést hajt végre, hogy megtalálja a lehetséges hibákat a használati eset szövegében, és ennek megfelelően frissül a tartománymodell. A használati eset szövege fontos annak azonosításához, hogy a felhasználók hogyan fognak interakcióba lépni a tervezett rendszerrel. Továbbá a fejlesztő számára is lehetőséget adnak, hogy megmutassa az ügyfélnek az eddigi fejleményeket, és ellenőrizhetik, hogy a követelményelemzés eredményei helyesek-e.
3. mérföldkő: Részletes tervezési áttekintés szerkesztés
Az ICONIX-folyamat ezen szakaszában a 2. mérföldkőből származó területi modellt és használati esetek szövegét használják fel az erre épülő rendszer megtervezéséhez. A tartománymodellből osztálydiagram készül, a használati eset szövegéből pedig szekvenciadiagramok készülnek.
4. mérföldkő: Telepítés szerkesztés
Unit teszteket írunk annak ellenőrzésére, hogy a rendszer megfelel-e a használati esetek szövegének és a szekvenciadiagramoknak. Végül kódot írunk az osztály- és szekvenciadiagramok felhasználásával.
Jegyzetek szerkesztés
- ↑ Doug Rosenberg & Matt Stephens (2007). Use Case Driven Object Modeling with UML: Theory and Practice. Apress. ISBN 1590597745
Fordítás szerkesztés
Ez a szócikk részben vagy egészben az ICONIX című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
Források szerkesztés
- Rosenberg, D., Stephens, M. & Collins-Cope, M. (2005). Agile Development with ICONIX Process. Apress. ISBN 1590594649