A számítástechnikában a káoszmodell a szoftverfejlesztés egyik struktúrája. Megalkotója az L.B.S. Raccoon álnevet használta, aki megjegyezte, hogy a projektmenedzsment-modellek, mint például a spirálmodell és a vízesésmodell, bár jól kezelik az ütemtervet és a személyzetet, nem nyújtanak módszereket a hibák kijavítására vagy más technikai problémák megoldására. Ugyanakkor a programozási módszertanok, bár hatékonyak a hibák javításában és a technikai problémák megoldásában, nem segítenek a határidők kezelésében vagy az ügyfelek kéréseire való reagálásban. A struktúra ezt a szakadékot próbálja áthidalni. A káoszelméletet eszközként használták, hogy segítsen megérteni ezeket a kérdéseket.ACM Digital Library, The chaos model and the chaos cycle, ACM SIGSOFT Software Engineering Notes, Volume 20 Issue 1, Jan. 1995
Szoftverfejlesztés életciklusa A káoszmodell értelmében az életciklus fázisai a projekt minden szintjére vonatkoznak, a teljes projekttől az egyes kódsorokig.
A teljes projektet meg kell határozni, meg kell valósítani és integrálni kell. A rendszereket meg kell határozni, meg kell valósítani és integrálni kell. A modulokat meg kell határozni, meg kell valósítani és integrálni kell. A funkciókat meg kell határozni, meg kell valósítani és integrálni kell. A kódsorokat definiálni, megvalósítani és integrálni kell.
A perspektívában bekövetkező fontos változás az, hogy a projektekre gondolhatunk egész egységként vagy gondolhatunk egy-egy darabként is. Senki sem ír több ezer sor kódot egyhuzamban. Kis részeket írnak, sorról sorra haladva, miközben figyelik azt, hogy ezek a kis részek működnek-e. Majd ezeket a felépített részeket otthagyják. Egy komplex rendszer a kisebb építőkockák kombinált viselkedéséből alakul ki.
Káoszstratégia A káoszstratégia a szoftverfejlesztés egy stratégiája, ami a káoszmodellen alapul. A fő szabály az, hogy mindig a legfontosabb problémát kell először megoldani.
A probléma egy befejezetlen programozási feladat. A legfontosabb probléma a nagy, a sürgős és a robusztus kombinációja. A nagy problémák működő funkcionalitásként értéket biztosítanak a felhasználók számára. A sürgős problémák időszerűek, mivel máskülönben más munkát hátráltatnának. A robusztus problémák megbízhatóak és teszteltek, amikor megoldják őket. A fejlesztők ezután nyugodtan másra összpontosíthatják a figyelmüket. A megoldani azt jelenti, hogy stabil állapotba hozni.
A káoszstratégia hasonlít ahhoz, ahogyan a programozók dolgoznak egy projekt vége felé, amikor a javítandó hibák és létrehozandó funkciók listája van előttük. Általában valaki rangsorolja a fennmaradó feladatokat, és a programozók egyesével javítják ki őket. A káoszstratégia azt állítja, hogy ez az egyetlen érvényes módja a munka elvégzésének.
A káoszstratégiát a go stratégiája ihlette.
Kapcsolatok a káoszelmélettel A káoszelmélettel több kapcsolata is van.
A káoszmodell segíthet megmagyarázni, miért hajlamosak a szoftverek ennyire kiszámíthatatlanok lenni. Megmagyarázza, hogy az olyan magas szintű fogalmak, mint az architektúra, nem kezelhetők-e az alacsony szintű kódsoroktól függetlenül. Ez egy horog arra, hogy elmagyarázza, mit kell tovább tennie a káoszstratégia szempontjából.
Jegyzetek
Fordítás
További irodalom Roger Pressman (1997) Software Engineering: A Practitioner Approach 4. kiadás, 29–30. Oldal, McGraw Hill. Raccoon (1995): A káoszmodell és a káosz életciklusa, ACM Software Engineering Notes, 20. kötet, 1. szám, 55–66. Oldal, 1995. január, ACM Press.
Kapcsolódó szócikkek V modell
Kategória:Szoftverfejlesztés