Káoszmodell

Ehhez a szócikkhez további forrásmegjelölések, lábjegyzetek szükségesek az ellenőrizhetőség érdekében. Emiatt nem tudjuk közvetlenül ellenőrizni, hogy a szócikkben szereplő állítások helytállóak-e. Segíts a szócikk fejlesztésében további megbízható források hozzáadásával.

A számítástechnikában a káoszmodell a szoftverfejlesztés egyik struktúrája. Megalkotója az L.B.S. Raccoon^[1] á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.^[2]

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.

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.

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.

Ez a szócikk részben vagy egészben a Chaos model 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.

• 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.

• V modell