در محاسبات،مدل آشوب یک ساختار توسعه نرم‌افزار است. پدیدآور آن، که خود را که با استفاده از نام مستعار L. B. S. Raccoon[۱] معرفی می‌کند، به این اشاره می‌کند که مدل‌های مدیریت پروژه مانند مدل مارپیچ و مدل آبشاری در حالی که در مدیریت برنامه‌ها و کارکنان خوب هستند، روش‌هایی برای رفع اشکالات یا حل دیگر مشکلات فنی ارایه نمی‌کنند. در همین حین، اصول برنامه‌نویسی، در حالی که در رفع اشکالات و حل مشکلات فنی مؤثر هستند، کمکی در مدیریت ضرب‌الاجل‌ها یا پاسخ به درخواست‌های مشتری نمی‌کنند. این ساختار تلاشی برای ایجاد پلی برای این شکاف است. نظریه آشوب به عنوان یک ابزار برای کمک به درک این مسائل قرار گرفت.[۲]
چرخه حیات توسعه نرم‌افزار
مدل آشوب یادآور می‌شود که مراحل چرخه حیات به تمام سطوح پروژه‌ها، از کل پروژه تا تک تک خطوط کد مربوط می‌شود.
- کل پروژه باید تعریف، اجرا و یکپارچه شود.
- سیستم‌ها باید تعریف، پیاده‌سازی و یکپارچه شوند.
- ماژول‌ها باید تعریف شده، اجرا و یکپارچه شوند.
- توابع باید تعریف، پیاده‌سازی و یکپارچه شوند.
- خطوط کد تعریف شده، اجرا و یکپارچه می‌شوند.
یک تغییر مهم در چشم‌انداز این است که آیا پروژه‌ها می‌توانند به عنوان واحدهای کل در نظر گرفته شوند یا باید به صورت قطعه ای مورد توجه قرار گیرند. هیچ‌کس در یک نشست، ده‌ها هزار خط کد را نمی‌نویسد. آنها قطعات کوچک را خط به خط در یک زمان را می‌نویسند و مطمئن می‌شوند که این قطعات کوچک کار می‌کنند. سپس آنها از آنجا به تکمیل ساخت می‌پردازند. رفتار یک سیستم پیچیده از رفتار ترکیبی بلوک‌های کوچکتر پدیدار می‌شود.
استراتژی آشوب
استراتژی آشوب، استراتژی توسعه نرم‌افزار بر اساس مدل آشوب است. قاعده اصلی این است که همیشه حل مهمترین مسئله در اولویت است.
- یک مسئله، یک کار برنامه‌نویسی ناقص است.
- مهمترین مسئله، ترکیبی از بزرگ، فوری و قوی است.
- مسائل بزرگ برای کاربران به عنوان عملکرد اجرایی ارزش دارند.
- مسائل فوری، به هنگام هستند که در غیر این صورت کار دیگری را متوقف خواهند کرد.
- مسائل محکم زمانی که حل شوند مورد اعتماد و آزمایش قرار می‌گیرند. پس از آن توسعه دهندگان می‌توانند با خیال راحت به موارد دیگر بپردازند.
- حل کردن به این معنی است که آن را به نقطه ثبات برسانند.
استراتژی آشوب شبیه راهکار برنامه نویسان برای پایان دادن به یک پروژه است، زمانی که آنها لیستی از خطاها را برای رفع و ویژگی‌هایی برای ایجاد را دارند. معمولاً فردی کارهای باقیمانده را اولویت بندی می‌کند و برنامه نویسان آنها را یکی یکی رفع می‌کنند. استراتژی آشوب بیان می‌کند که این تنها راه درست برای انجام کار است.
استراتژی آشوب الهام گرفته از استراتژی گو است.
ارتباط با نظریه آشوب
چندین ارتباط با نظریه آشوب وجود دارد.
- مدل آشوب ممکن است به توضیح اینکه چرا نرم‌افزار آنقدر غیرقابل پیش‌بینی است کمک کند.
- توضیح می‌دهد که چرا با مفاهیم سطح بالا مانند معماری نمی‌توانند مستقل از سطوح خط کد رفتار کنند.
- این یک نقطه جلب توجه برای توضیح آنچه که باید بعداً، از دید استراتژی هرج و مرج انجام شود، ارایه می‌دهد.
جستارهای وابسته
منابع
خواندن بیشتر
- Roger Pressman (1997) Software Engineering: A Practitioner's Approach 4th edition, pages 29–30, McGraw Hill.
- Raccoon (1995) The Chaos Model and the Chaos Life Cycle, in ACM Software Engineering Notes, Volume 20, Number 1, Pages 55 to 66, January 1995, ACM Press.
