روال تصمیم‌گیری در معماری نرم‌افزار

روال تصمیم‌گیری چه جایگاه و اهمیتی در تدوین معماری نرم‌افزار دارد؟ روش تصمیم‌سازی و تصمیم‌گیری مطمئن چه ویژگی‌های باید داشته باشد؟ چطور تصمیمات‌مان را مستند کنیم؟

جایگاه تصمیم‌گیری در عملیات معماری نرم‌افزار

همانطور که قبلاً شرح دادم من این تعریف را برای معماری نرم‌افزار بیشتر می‌پسندم:

تعریف معماری نرم‌افزار: مجموعه تصمیمات مهم در فرایند توسعه نرم‌افزار با هدف مدیریت مخاطرات

با این تعریف تقریباً می‌توان گفت معماری نرم‌افزار چیزی جز تصمیم‌گیری نیست. بعد از آنکه درک اولیه از فضای مساله پیدا شد، طراحی فضای راه‌حل شروع می‌شود. در این نقطه با دو راهی‌های مختلفی مواجه می‌شویم.

• از چه جور پایگاه‌داده‌ای استفاده کنیم؟
• چه زبان برنامه‌نویسی برای توسعه بک‌اند این محصول مناسب‌تر است؟
• محصول را به چه مولفه‌هایی بشکنیم؟

اگر بخواهیم یک نرم‌افزار خوب داشته باشیم باید روال درست تصمیم‌گیری را بلد باشیم.

استخراج سؤالات معماری

برای اینکه فکر خود را نظم دهیم، در ابتدا لیستی از سؤالات معماری استخراج می‌کنیم. این لیست اصطلاحاً ADL‌ (مخفف Architecture Decision Log) نامیده می‌شود.

• برخی از سؤالات ممکن است به هم وابسته باشند. یعنی پاسخ یک سؤال، گزینه‌های سؤال دیگر را محدود یا مقید کرده یا حتی پاسخ خاصی به یک سوال، یک سؤال دیگر را از موضوعیت خارج نماید.
• در نوشتن سؤالات دست و دل‌باز باشید و هر سوالی به ذهنتان رسید را بنویسید.
• سعی کنید سؤالات کاملاً شفاف و غیر کلی باشند.
• سؤالات را از جهت اهمیت و تاثیرگذاری اولویت‌بندی کنید.
• در ادامه مسیر هر جا خودتان را در یک دو راهی یا چند راهی دیدید،‌ آن را به صورت یک سؤال مستقل یادداشت نمایید.

قالب پاسخگویی به سؤالات معماری

برای پاسخگویی صحیح به سؤالات معماری گام‌های زیر پیشنهاد می‌شود:

• شرح سؤال: قبل از هر چیز باید سؤال به خوبی تبیین شود. ممکن است لازم باشد پیش‌فرض‌ها و زمینه سؤال کمی توضیح داده شود.
• تعیین معیارها: نیاز به معیارهایی داریم که بتوانیم گزینه‌های مختلف را با آن‌ها بسنجیم. مثل پوشش نیازهای کارکردی و کیفی، عدم نقض محدودیت‌های معماری، قیمت خرید مجوز بهره‌برداری،‌ منحنی یادگیری، دسترسی به نیروی انسانی متخصص، هزینه‌های پشتیبانی و غیره. باید معیارها را وزن‌دهی کرده و خطوط قرمز را مشخص کنیم.
• طراحی گزینه‌ها: برای هر سؤال معماری چند گزینه پاسخ طراحی کنید. اگر فقط به یک گزینه پاسخ رسیدید به احتمال زیاد به اندازه کافی روی گزینه‌ها فکر نکردید.
• ارزیابی گزینه‌ها: گزینه‌هایی که طراحی کرده‌ایم را بر اساس معیارها سنجیده و مزایا و معایب هر یک را مشخص می‌کنیم.
• جمع‌بندی: نهایتاً با سبک و سنگین‌ کردن گزینه‌ها یک پاسخ را انتخاب می‌کنیم. در صورت نیاز می‌توانیم پاسخ انتخاب شده و تبعات و ملزومات آن را بیشتر شرح دهیم.

اهمیت مستندسازی تصمیمات معماری

 

 

تیم‌های نرم‌افزاری معمولاً در قالب «سند معماری نرم‌افزار» یا SAD ساختار محصول‌شان را مستند می‌کنند ولی مستندسازی تصمیمات معماری رواج کمتری دارد. در سال‌های اخیر روی مستندسازی تصمیمات معماری در قالب ADR (مخفف Architecture Decision Record) تاکید بیشتری می‌شود (مثل این و این و این). چرا که کمک می‌کند دلیل تصمیمات معماری را افراد بیرون تیم یا اعضای جدید تیم سریع‌تر درک کنند و حتی در طول زمان در بازنگری تصمیمات به تیم کمک می‌نماید. 

مستندسازی بخشی از فرایند تصمیم‌گیری

در شرکت اعوان تجربه بسیار مثبتی از مستندسازی تصمیمات معماری در حین فرایند تصمیم‌گیری داریم. یعنی به جای آنکه پس از انعقاد تصمیمات آن‌ها را مستند کنیم، معمار نرم‌افزار در حین تصمیم‌گیری دست به قلم می‌شود. سؤالات را نوشته و پاسخ‌ها را در قالب مورد نظر وارد می‌کند. مهمترین دستاورد این روش آن است که ذهن معمار نرم‌افزار حین تصمیم‌گیری منظم‌تر شود. از طرفی بلافاصله می‌تواند مستند را با دیگر اعضای تیم به اشتراک گذاشته و قبل از انعقاد تصمیم نظر آنها را بگیرد. ما در سال‌های اخیر برای مستندسازی از Confluence بهره‌ می‌گیریم. با این ابزار اعضای تیم می‌توانند نظرات خود را به صورت Inline Comment‌ با معمار نرم‌افزار تبادل کنند. یعنی مستند بخشی از فرایند تصمیم‌گیری است و نه فقط خروجی آن.

البته این شیوه تبادل نظر برای برخی از موضوعات پیچیده و چند وجهی کارآمد نیست. در این موارد از جلسات تصمیم‌گیری گروهی استفاده می‌کنیم. ان شاء الله در آینده راجع به ملزومات و ساختار جلسات تصمیم‌گیری گروهی در زمینه معماری نرم‌افزار خواهم نوشت.