ارزیابی معماری نرم‌افزار و مدل‌های بلوغ معماری فنی نرم‌افزار

معماری نرم‌افزار چیست؟

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

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

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

حالا چرا باید معماری نرم افزار رو ارزیابی بکنیم؟

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

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

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

پس برای اجتناب کردن از تلف شدن سرمایه و زمان که به دلیل انتخاب معماری نامناسب می باشد، توصیف کردن یك نقشه معماری رسمی و معتبر که قابل ارزیابی باشد، قبل از شروع به پیاده سازی یك سیستم، می تواند بسیار مفید باشد. تکنیکهای توصیف رسمی به عنوان زبان توصیف معماری به ما اجازه ارزیابی و اعتبارسنجی معماری انتخاب شده را می دهد، تا مشخص نماید که آیا معماری پذیرفته شده برای رسیدن به نیازمندیهای غیر وظیفه مندی مشخص شده برای آن سیستم مناسب است یا خیر. در ارزیابی و تحلیل معماری باید به شیو های عمل نمود که نیازهای همۀ ذی نفعان در نظر گرفته شود . ارزیابی معماری در مرحله اعتبار بخشی یا اعتبار سنجی به یك سیستم نرم افزاری و یا در مرحلة پذیرش آن سیستم باید انجام گیرد.

پس در نهایت به صورت کلی از فواید ارزیابی معماری می توان به ملاقات صاحبان سهام، کاهش هزینه نگهداری، اولویت بندی ویژگی‌های کیفیتی، بهبود کیفیت مستندات معماری، بهبود کیفیت معماری نرم افزار، کاهش ریسك و هزینه کمتر در تغییرات سیستم، اشاره نمود.

نقش هاي کلیدي در فرآیند ارزیابی:

- مشاور

- معمار

- مدیر پروژه

- تیم ارزیابی

- ذینفعان

حالا با توجه به اهمیت این موضوع، روش های گوناگونی برای ارزیابی ارائه شده و انتخاب روش ارزیابی مناسب با توجه به نوع سیستم و تنوع روش ها یکی از مباحث اصلی و حساس در این زمینه است که تو 4 دسته بیانشون میکنن:

• مبتنی بر تجربه
• مبتنی بر سناریو
• مبتنی بر ریاضی
• مبتنی بر شبیه سازی

مبتنی بر تجربه:

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

مبتنی بر ریاضی:

برای اندازه‌گیری تناسب سیستم‌های نرم‌افزاری حیاتی، مانند نرم افزارهای حوزه ­های پزشکی، هواپیما و مأموریت­ های فضایی، ارزیابی کمی ویژگی‌های کیفی عملیاتی مهم است و باید انجام بشود و چون اکثر روش‌های ارزیابی معماری نرم‌افزار مبتنی بر سناریو از استدلال­ های کیفی برای ارزیابی ویژگی‌های کیفی در زمان توسعه، استفاده می‌کنند، نمی‎‌توانند این سیستم ها را ارزیابی کنند، بنابراین، تعدادی از روش‌های ارزیابی معماری نرم‌افزار مبتنی بر مدل ریاضی ایجاد شده‌اند.

این روش ­ها معماری نرم­ افزار را با استفاده از معادلات ریاضی شناخته شده مدل می­ کنند، در این روش اطلاعات دقیق عددی مهم هستند و برای مثال برای اندازه گیری دقیق پرفورمنس(مثلا این سیستم توانایی انجام چند TPS را دارد و چندتا مدنظر ماست) یا قابلیت اعتماد و ... از این روش استفاده می شود.

مبتنی بر شبیه سازی:

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

و اما رویکرد مبتنی بر سناریو:

این روش در عمل بیشتر مورد استفاده قرار می گیرد، انواع گوناگونی دارد و در این مقاله بیشتر این رویکرد را تعریف می‌کنیم و تمرکز بیشتری نسبت به بقیه روی این روش خواهیم داشت:

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

بعضی از ویژگی های رویکرد مبتنی بر سناریو:

رویکردهای مبتنی بر سناریو کاملاً بالغ در نظر گرفته می شوند و همینطور به طور گسترده در عمل مورد استفاده قرار می گیرند.

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

در ادامه انواع روش های مبتنی بر سناریو رو مورد بررسی قرار می دهیم:

روش‌های رویکرد مبتنی بر سناریو:

SAAM (Scenario-based Software Architecture Analysis Method):

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

روش SAAM ابتدا از مراحل مختلف تولید نرم افزار، مصنوعات را دریافت می کند و سپس با ایجاد سناریوها اقدام به ارزیابی معماري نرم افزار می نماید.

سه ورودي زیر توسط این روش دریافت می شود:

1- سند دیدگاه و سند تشریح گردانندگان کسب و کار

2- مدل نیازمندیهاي سیستم شامل موارد کاربري و توصیف موارد کاربري

3- مستندات تشریح معماري

هر یک از سناریوها از نظر اینکه در معماري سیستم، برقرار است یا خیر، مورد سنجش قرار می گیرد و عدد صفر و یک به هر یک نسبت داده می شود. گاه یک سناریو در تعارض با سناریوي دیگري قرار می گیرد بدین معنا که نمی توان همزمان به هر دو سناریو در سیستم دست یافت. بین سناریوها با دادن فاکتور وزنی به هر کدام، مصالحه برقرار می‌شود.

این روش ارزیابی شامل شش مرحلۀ اصلی است:

1) مرحلۀ ایجاد سناریوها : سناریوهای سیستم به این شکل ساخته می‌شوند که ذی نفعان سعی می کنند که با کمک جرقه های ذهنی انواع فعالیت هایی که سیستم باید پشتیبانی نماید را تعیین کنند و تغییرات و اصلاحاتی که در مورد این فعالیت‌ها به نظرشان می‌رسد را نیز اعلام و پیش بینی کنند، بعدش این فعالیت‌ها گروه‌بندی می‌شوند و سناریوها بدست می‌آیند.

2) توصیف معماری‌ها : اولا مستنداتی که اولید می‌شوند، باید تمام بخش‌های ایستا و پویای سیستم را به خوبی معرفی کرده باشند. در این مرحله از ارزیابی، معماری یا معماری‌های کاندید مشخص می‌شوند. مستنداتی که برای معرفی معماری یا معماری‌های کاندید استفاده می‌شود باید به نحوی تهیه شده باشد که برای همۀ افراد شرکت‌کننده در ارزیابی قابل درك باشد.

3) دسته‌بندی و اولویت‌بندی سناریوها : در این مرحله، سناریوها به دو دستۀ مستقیم و غیرمستقیم تقسیم می‌شوند. سناریوهای مستقیم به منظور اندازه‌گیری کارایی یا قابلیت اطمینان معماری به کار می‌روند، ولی سناریوهای غیرمستقیم برای اندازه‌گیری صفت کیفی قابلیت اصلاح پذیری سیستم استفاده می‌شود. یک سناریوی مستقیم به‌وسیلۀ معماری کاندید پشتیبانی می‌شود و برپایه‌ی نیازمندی‌هایی است که سیستم از آن متحول خواهد شد. یک سناریوی غیرمستقیم دنباله‌ای از رویدادها برای تحقق بخشیدن یا انجام معماری می‌باشد. معماری کاندید باید تغییرات جزئی و یا کلی بیابد تا با سناریوهای غیرمستقیم انطباق یابد.

4) ارزیابی سناریوهای غیرمستقیم به صورت جداگانه : ولی در مورد سناریوهای غیرمستقیم معمار باید شرح دهد که برای اینکه معماری شامل این سناریو گردد، باید چه تغییراتی در معماری ایجاد گردد و چون صحبت از تغییرات است، نیاز به ارزیابی سناریوهای غیرمستقیم مشاهده می‌شود اما در مورد سناریوهای مستقیم، فقط لازم است که معمار چگونگی اجرای سناریو توسط معماری را شرح دهد،

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

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

معایب روش SAAM :

• این روش ارزیابی، یک روش مرحله‌ای برای ارزیابی معماری است، ولی با وجود این، تکنیکهای کمی را برای انجام مراحل مختلف ارائه می‌دهد و در اصل موفق بودن این ارزیابی، به تجارب ارزیاب وابسته است.
• فرآیند تولید سناریو بر اساس دید ذی نفعان می‌باشد و تصور سناریوی غیرمستقیم برای آنها مشکل است.
• در SAAM یک اندازه‌گیری کیفی مشخصی از ویژگی‌های معماری تجزیه و تحلیل شده وجود ندارد.

روش ارزیابی SAAM قابلیت تشخیص نقاط ضعف و قوت یك معماری را دارد . تأکید این روش بر روی قابلیت اصلاح پذیری است به گونه‌ای که این روش به راحتی می‌تواند نقاطی از معماری نرم افزار سیستم مورد نظر را که نیازمندی قابلیت اصلاح پذیری را برآورده نساخته، مشخص نماید و یا اگر چند معماری متفاوت از سیستم وجود دارد که عملکرد یکسانی دارند، این روش می تواند از جنبه قابلیت اصلاح پذیری آنها را مقایسه کند و به صورت نسبی آنها را رتبه بندی نماید .البته این روش می تواند ارزیابی سریعی بر روی صفات کیفیتی مختلفی از جمله ، قابلیت اصلاح پذیری، قابلیت حمل و جابجایی، قابلیت گسترش، قابلیت نگهداری،قابلیت تجمیع، قابلیت اطمینان هم داشته باشد، ولی اساس ارزیابی این روش بر پایة قابلیت اصلاح پذیری است .این روش ارزیابی پس از طراحی معماری بدون جزئیات، می تواند وارد عمل شود.

به صورت کلی:

• اولین روش ارزیابی معماری نرم افزار مبتنی برسناریو است.
• به منظور ارزیابی بعضی از صفات کیفیتی معماری مانند، قابلیت اصلاح پذیری، قابلیت نگهداری، قابلیت اطمینان و .. ایجاد گردیده است.
• تأکید این روش بر روی قابلیت اصلاح پذیری است.
• این روش به راحتی می تواند نقاط قوت و ضعف از جانب اصلاح پذیری را مشخص کند.
• البته از سمت ویژگی‌های کیفی دیگر نیز می‌تواند با کیفیت کمتر نقاط قوت و ضعف را نشان دهد.
• مناسب ترین زمان برای اعمال SAAM، بعد از طراحی SA سطح بالا و قبل از اجراست.

 ATAM (Architecture based Tradeoff Analysis Method):

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

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

روش ATAM به صورت کاملاً جدا از روش SAAM و روش‌های مبتنی بر آن، توسعه یافت و هدف از آن تحلیل صفات کیفیتی خاص بر اساس معماری بود. ATAM بر روی جنبه های کیفیتی معماری با جزئیات بیشتر بحث می‌کند و در عمل نسخۀ تقویت شده‌ا‌ی از SAAM می باشد. ATAM به عنوان یك مدل مارپیچی از طراحی در سال1991 مطرح شد و در سال 1999 مدل مارپیچی تحلیل و طراحی که تکامل فعلی و میزان پیشرفت را شرح می داد، مطرح گردید .

در واقع ATAM یك روش مبتنی بر سناریو برای ارزیابی صفات کیفیتی مانند : قابلیت اصلاح پذیری، قابلیت حمل، قابلیت توسعه، و قابلیت تجمیع می باشد. این روش چگونگی ارضاء شدن اهداف کیفیتی ویژه توسط معماری نرم‌افزار را تحلیل می‌کند. این روش، یك فرآیند تکرارپذیر می‌باشد .

این روش نیز بر اساس روش SAAM است و بیشتر تمرکز آن بر روي چهار فاکتور کیفی، تغییرپذیری، کارایی، دسترس پذیری و امنیت است. در این روش با توجه به چهار فاکتور کیفی فوق، سناریوهایی ارائه شده است. افرادي که تجربه کمتري دارند تمایل بیشتري به این روش دارند، زیرا سناریوها در این روش از قبل نوشته شده است.

یکی از مسائلی که روش ATAM به آن پرداخته تحلیل مدل مصالحۀ سناریوها با یکدیگر است.

موضوعات مطروحه در این تحلیل عبارتند از اولویت بندي سناریوها، تشخیص تناقض سناریوها و نمره دادن به هر یک از سناریوها.

از روش ATAM می توان در خط تولید نرم افزار (SPL) نیز بهره جست تا بتوان ریسک هاي بالقوه موجود در معماري مربوطه را کشف کرد.

به صورت کلی:

• هدف آن تحلیل صفات کیفیتی خاص بر اساس معماری است.
• در عمل نسخۀ تقویت شده‌ای(پیشرفته) از SAAM می باشد و بیشتر از SAAM به جزئیات می‌پردازد.
• در واقع ATAM یك روش مبتنی بر سناریو است که همزمان چندین ویژگی کیفی را در نظر می‌گیرد.
• یک فرآیند تکرارپذیر می باشد.
• این روش برای حفظ تعادل بین ویژگی‌های کیفی ارائه شده است.
• یک روش خوب و تثبیت شده است.

ALMA (Architecture-Level Modifiability Analysis):

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

این روش میزان تغییرپذیري معماري را بررسی می‌کند و در انتها یا معماري نرم افزار بهبود می یابد و یا معماري مجدد انجام می شود. همچنین در این روش یک معماري موجود در ابتداي کار وجود دارد که آن را توسط روش SAAM ارزیابی می‌کنند. سپس مشکلات معماري مشخص شده و سناریوهاي تغییر (یك سناریوی تغییر برای یك سیستم، یك رویداد ویژه ای را شرح می دهد که به واسطة اتفاق افتادن این رویداد در چرخة حیات آن سیستم، سیستم نیازمند اصلاح شود ) مشخص می شود. سپس ارزیابی تغییرات انجام داده می شود و در انتها نتیجه‌گیري می شود ،آیا معماري قابل اصلاح هست یا خیر و زمان و هزینه براي این اصلاح نرمال است یا خیر.

بنابراینALMA یك روش ارزیابی مبتنی بر سناریو می باشد که برای ارزیابی صفات کیفیتی نرم افزار که روی قابلیت اصلاح پذیری متمرکز است، ایجاد شده است.

به صورت کلی:

• این روش ابتدا فقط برای سیستم‌های اطلاعاتی کاری توسعه داده شد.
• کاهش میزان هزینه، تلاش و وقت لازم برای اعمال تغییرات در سیستم با مشخص کردن سناریوهای تغییر بر روی معماری سیستم. (شناسایی انواع تغییراتی که SA برای آنها انعطاف ناپذیر است)
• این روش ویژگی‌های تغییرپذیری را با استفاده از شاخص‌هایی مانند ارزیابی ریسک و پیش بینی هزینۀ نگهداری و اعمال تغییرات ارزیابی می‌کند.
• این روش، چارچوبی برای توصیف نتایج کمی ایجاد می کند.
• کاربردها: مهندسی مجدد سیستم‌های قدیمی، ارتباطات راه دور، سیستم‌های اطلاعاتی، سیستم‌های تعبیه شده و حوزه‌های پزشکی.

 SBAR (Scenario-Based Architecture Reengineering) :

یك خصوصیت برجسته این روش آن است که برای ارزیابی معماری سیستم موجود، خود سیستم می تواند استفاده شود . فرآیند ارزیابی می تواند به روش کامل یا آماری انجام شود.SBAR به عنوان روشی برای اندازه گیری سیستم نرم افزاری شناخته شده است.(مهندسی مجدد معماری). در فرآیند ارزیابی کامل، مجموعه ای از سناریوها تعریف و با هم ترکیب می شوند.

به صورت کلی:

• در فرآیند ارزیابی آماری، تعریف کردن مجموعه ای از سناریوها است که یك نمونه ساده بدون همه موارد را می سازد.
• همچنین SABR طراحی مجدد معماری را برای ویژگی های قابلیت اطمینان و کیفیت عملکرد هدایت می کند.
• هدف اصلی این روش معرفی یک فرآیند تکراری ارزیابی کیفیت و تحول معماری است.
• همچنین SBAR از چندین ویژگی کیفیت مانند ATAM پشتیبانی می کند اما با ATAM تفاوت دارد که از تکنیک های مختلفی برای ارزیابی استفاده می کند.
• کاربردها: سیستم اعلام حریق، سیستم اندازه گیری و سیستم دیالیزاستفاده شده است.

FAAM (Family-Architecture Assessment Method):

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

براي نمونه این روش می‌تواند براي خانواده‌اي از سیستم‌هاي مالی، سیستم‌هاي منابع انسانی، سیستم‌هاي محاسباتی، سیستم‌هاي مدیریت بیمارستانی و .. مورد استفاده قرار گیرد.

در این روش تکلیف مسئول ارزیابی مشخص است که باید اقدام به ارزیابی چه سناریوهایی کند. بدین ترتیب در این روش نیازي به جلسات طوفان فکري بین اعضاي تیم ارزیابی نیست، زیرا سناریوهاي مربوطه از قبل تعیین و بر روي آنها تفکر شده است.

CBAM (Cost-Benefit Analysis Method):

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

روش‌های قبلی مانند SAAM و ATAM صفات کیفیتی مانند قابلیت اصلاح پذیری، قابلیت استفاده، کارایی و غیره را در نظر می گرفتند و بر اساس آنها تصمیمات معماری مورد نیاز را اتخاذ می کردند اما CBAM مدعی است که عواملی مانند هزینه ها، سودها و ریسک‌ها نیز باید به عنوان صفات کیفیتی در نظر گرفته شوند، چرا که آنها در تصمیمات معماری تاثیر به سزایی می‌گذارند.

در این روش هزینه به عنوان یک خصوصیت کیفی درنظر گرفته می‌شود و تصمیمات معماري را در حوزه هاي استقرار و پیاده سازي گرفته می‌شود و اثرات آن هزینه را در نظر می گیرد.

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

به صورت کلی:

• همچنین CBAM دو حوزه (فرایند معماری و اقتصاد) را در توسعه نرم افزار سازمان به هم متصل می کند.
• و CBAM هزینه ها را به عنوان عناصر کیفی محاسبه می کند، که هنگام برنامه ریزی یک سیستم نرم افزاری باید مراقب آنها بود.(CBAM ادعا می کند که هزینه ها، سودها و امکانات ویژگی های کیفیت ضروری هستند.)
• عدم قطعیت مربوط به تخمین ها را صراحتا بیان می کند.
• رویکرد آن آنالیز مزایای مربوط به استراتژی های مختلف معماری، ارزیابی کیفیت، و محاسبه مطلوبیت با توجه به هزینه و عامل زمان است.

بررسی کلی و مقایسۀ مختصر روش‌های مبتنی بر سناریو:

در روش SAAM مهم‌ترین پارامتری که مورد ارزیابی قرار می‌گیرد قابلیت اصلاح پذیری بوده و از مزایای این روش قابل استفاده بودن برای هر نوع معماری است و از معایب این روش نیز نداشتن تکنیک‌هایی برای انجام مراحل و متریک‌های مشخص است.

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

در روش CBAM مهم‌ترین پارامتری که مورد ارزیابی قرار می‌گیرد، هزینه ها، سودها، و زمانبندی بوده و از مزایای این روش تعیین میزان برگشت سرمایه در ایجاد تغییرات است و از معایب این روش نیزاین است که بطور مستقل بکار نمی رود و وابسته به روش دیگر است. در روش ALMAمهم‌ترین پارامتری که مورد ارزیابی قرار می‌گیرد قابلیت اصلاح پذیری بوده و از مزایای این روش مشخص نمودن شرایط توقف تولد سناریو و مشخص کردن تکنیکهای تکرار مراحل است و از معایب این روش نیز کامل نبودن ارزیابی ریسك و نبود تصمیم گیری در مورد درستی نتایج و تمرکز روی صفات ایستا است. در روش FAAM مهم‌ترین پارامتری که مورد ارزیابی قرار می‌گیرد تعامل پذیری و قابلیت گسترش بوده و از مزایای این روش داشتن تکنیک‌هایی برای تقویت تیم ارزیابی است و از معایب این روش نیز تمرکز روی صفات ایستا و به کار رفتن در محیط‌های خاص است.

همچنین در روش SBAR پارامترهای متنوعی مورد ارزیابی قرار می‌گیرد و از مزایای این روش همکاری در طراحی معماری و ارزیابی بر مبنای سناریو است و از معایب این روش نیز نیاز به دانش و تخصص است.

مدل‌های بلوغ نرم افزار

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

هدف از مدل‌های بلوغ ارائه شده این است که چارچوبی را فراهم نمایند، تا به سازمان‌ها کمک کنند درجۀ فعلی تکامل خود را ارزیابی کنند و در کنار آن با طی مسیر مشخص شده در این مدل‌ها به تعالی بیشتر دست یابند و بتوانند پروژه‌های خود را بهتر و موثرتر مدیریت کرده و به نتیجه برسانند.

به صورت کلی:

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

انواع مختلفی از مدل‌های بلوغ وجود دارد. موردی که برای استفاده انتخاب می کنید ممکن است به صنعت شما یا آنچه که شما نیاز دارید ارزیابی کنید، بستگی داشته باشد، در ادامه انواع آن را بررسی می‌کنیم:

 Capability Maturity Model Integration(CMMI) :

یکپارچه‌سازی مدل بلوغ توانایی (Capability Maturity Model Integration) مدل فرآیندی است برای تعریف و ترویج رفتارهای سازمانی که منجر به بهبود کارایی می‌گردد. CMMI یک شیوۀ بهبود فرایندی است که با عناصر اصلی فرایندهای موثر سازمان یافته است. در مدل CMMI سازمان‌ها این قابلیت را دارند که زمان سیکل های روند توسعه را کاهش داده و امکان پیش‌گویی میزان کارایی حاصل از هر عملیات و همچنین امکان سازگاری محصولات با نظر کاربران نهایی را برآورده سازند.

مدل بلوغ قابلیت CMMI، با بکارگیری دانش و تجارب در مدیریت فرایندها و با تکبه بر این اصل که "کیفیت سیستم یا محصول شدیدا متاثر از فرایندی است که در توسعه و نگهداشت آن به کار رفته است"، ایجاد شده است. مدل CMMI علاوه بر بهبود، برای ارزیابی و مقایسۀ سازمان‌ها نیز به کار می‌رود.

مدل CMMI در دانشکده مهندسی نرم‌افزار دانشگاه Carnegie Mellon با پشتوانه دولت، سازمان‌های نظامی، صنایع و مراکز علمی ایجاد شد. در حال حاضر توسط انیستیتو CMMI که بخشی از دانشگاه Carnegie Mellon است، اداره می‌شود.

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

مدل CMMI بلوغ سازمان‌ها را در ۵ سطح تعریف می‌کند. سازمان‌هایی که این مدل را می‌پذیرند هدف‌شان افزایش سطوح بلوغ سازمان است. قابل ذکر است با رسیدن به سطح ۵یعنی “Optimizing”، نباید این مدل را کنار گذاشت. در این مرحله سازمان‌ها باید روی بهبود منظم متمرکز باشند.

۵ سطح بلوغ به شرح زیر است:

• سطح ابتدایی یا شروع(Initial): در این سطح برنامه‌ریزی و کارایی فرایندها، دچار هرج و مرج است، خواسته‌ها اشتباه فهمیده می‌شود و هزینه و زمان را نمی‌توانند درست پیش بینی کنند. همچنین در این سطح فرآیندها به صورت واکنشی هستند. معمولا کارها دیرتر از زمان مقرر و با هزینه‌ی بیشتر از بودجه مقرر انجام می‌شوند. در سطح Initial، فضای سازمان غیرقابل پیش‌بینی است و ریسک‌ها و ناکارآمدی افزایش می‌یابد.
• سطح مدیریت(Managed): در این سطح اقدامات اولیه مدیریت پروژه صورت می‌گیرد. پروژه‌ها برنامه‌ریزی، اجرا، ارزیابی و کنترل می‌شوند اما همچنان مشکلات زیادی وجود دارد.همچنین در این سطح خواسته‌ها پیگیری شده و از حالت اشتباه بودن درآمدند، برنامه‌ریزی را توانستند کنترل کنند، هر کسی روش خودش را دارد و روشی که همه استفاده کنند وجود ندارد و به صورت رسمی نیست.
• سطح تعریف شده(Defined): در این سطح، تمام فرایندهای مدیریتی و مهندسی، در سطح سازمان تعریف شده و به صورت یکنواخت، بکار گرفته می‌شوند، خواسته‌ها ثبت و پیگیری می‌َشود و تا جایی می‌رود که پیاده سازی شود، هزینه و زمان هم قابل قبول است. در این سطح سازمان‌ها به جای رفتار واکنشی بیشتر به سمت پیش‌بینی و برنامه‌ریزی حرکت می‌کنند. مجموعه‌ای از "استانداردهای سازمانی" برای راهنمایی در اجرای پروژه‌ها و برنامه‌ها وجود دارد. در سطحDefined کسب و کارها نواقص خود، روش برطرف کردن آن و اهداف در راستای بهبود را می‌شناسند.
• سطح مدیریت شده کمی(Quantitatively managed) : در این سطح کیفیت کنترل شده و کمیت مطرح می‌شود، کنترل آماری قابل قبول است و روی کیفیت محصول عدد و رقم قرار می‌دهیم، اندازه‌ها در یک پایگاه اطلاعات سازمانی نگهداری می‌شوند. همچنین در این سطح کنترل و ارزیابی بیشتری وجود دارد. سازمان با استفاده از داده‌های کمی، فرآیندهای مورد نیاز ذینفعان را پیش‌بینی می‌کند. کسب و کار، جلوتر از ریسک‌ها در حرکت است.
• سطح بهینه سازی(Optimizing): در این سطح تمرکر بر روی بهبود مستمر فرایند، تحلیل فرایندها، رفع نقاط ضعف و تقویت آنها، تقویت خطاها و رفع علت بروز خطا و بهبود مستمر فرایند از طریق نوآوری های تکنولوژی است. در این سطح فرآیندهای سازمان منعطف و پایدار هستند. در سطح پایانی، سازمان در وضعیت بهبود منظم و استفاده از فرصت‌ها خواهد بود. در سطح Optimizing سازمان پایدارتر و پیش‌بینی‌پذیرتر است که این امر فضا را برای چابکی و خلاقیت باز می‌کند.

به صورت کلی:

• مدل CMMI بهبود فرآیند را تحت تأثیر قرار می‌دهد و کمک می‌کند خطرات را در توسعه خدمات، محصول و نرم‌افزار کاهش دهیم.
• امروزه CMMI برای توسعه سخت افزار، نرم افزار و خدماتی در تمامی صنایع استفاده می‌شود و فقط محدود به نرم‌افزار نیست.
• هدف اعلام شدۀ CMMI این است که سازمان‌ها را قادر می‌سازد تا عملکرد را در طیف گسترده‌ای از قابلیت‌های حیاتی کسب‌وکار، از جمله توسعه محصول، بهبود خدمات، مدیریت نیروی کار، مدیریت تامین‌کننده و امنیت سایبری، ارتقا دهند و محک بزنند.

 Digital Maturity Model (DMM):

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

این مدل که به اختصار DMM نامیده می‌شود، ظرفیت‌های دیجیتال سازمان‌ها را در قالب 5 بعد از ابعاد کاملا صریح مطرح در کسب و کار مورد ارزیابی قرار می‌دهد تا یک دید جامع از بلوغ دیجیتال در سراسر سازمان ایجاد نماید. این ابعاد به ترتیب عباتند از: 1-مشتریان، 2-استراتژی، 3-تکنولوژی، 4-فرآیندهای عملیاتی، 5- سازمان و فرهنگ سازمانی.

به صورت کلی:

• همچنین DMM یک مدل ارزیابی است که سطح کنونی بلوغ دیجیتالی سازمان را در ابعاد اصلی کسب و کار به تصویر می‌کشد تا سازمان را با درک روشنی از وضعیت بلوغ فعلی‌اش آشنا کند و آنها را قادر می‌سازد تا حوزه‌های تمرکز را تعریف کنند.
• چارچوبی(framework) است که برای ارزیابی و درک سطح فعلی بلوغ دیجیتالی یک شرکت استفاده می‌شود.
• یک نقشه راه برای رسیدن به اهداف بلوغ دیجیتال، برنامه ریزی برای رشد و سنجش موفقیت ارائه می دهد.
• و DMM شش بعد اصلی، یعنی مشتری، استراتژی، فناوری، عملیات، سازمان و فرهنگ و داده را پوشش می دهد.(این ابعاد بیشتر به چندین زیربعد تقسیم می شوند که جنبه های مختلف بلوغ دیجیتال را منعکس می کنند.)

 Business Process Maturity Model (BPMM):

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

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

مدل BPMM، یکی از بهترین و دقیق‌ترین مدل‌های بلوغ مدیریت فرآیند است که به وسیله Bill Curtis و John Alden طراحی و اجرا شد. این مدل، نوعی راهنما برای به دست گرفتن کنترل فرآیندهای کسب و کار، در 5 سطح قابل ارزیابی است. سیستم BPMM بر تغییر و بهبود عملکرد، گردش کار، مدیریت و فرآیند متمرکز است و قادر است فرآیند بهبود را به تمامی بخش‌های سازمان هدایت کند.

در مدل بلوغ فرایند کسب و کار هر سطح از بلوغ، اهداف و شرایط مورد نیاز برای پیشرفت‌های آتی را فراهم می‌کند و در واقع به صورت مرحله به مرحله جلو می‌رویم و می‌توانیم ویژگی های یک فرایند را ارزیابی کنیم و برای حفظ و بهینه سازی آن تلاش کنیم، اینها از اصول اصلی BPMM است.

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

کسب و کارها با استفاده از فرآیندهای کنترلی این ابزار، از مزایای مختلفی مانند: صرفه جویی در هزینه‌ها، افزایش کیفیت پیش بینی‌ها، مشارکت بیشتر کارکنان و افزایش بهره وری برخوردار خواهند شد.

ارزیابی مدل بلوغ فرایند کسب‌وکار:

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

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

به صورت کلی:

• همچنین BPMM با شناسایی فعالیت‌های تجاری نابالغ و ناسازگار و توسعه فرآیندهای بالغ و منظم، مسیر بهبود تکاملی را توصیف می‌کند.
• این مدل بلوغ فرآیند راه‌های معرفی شیوه‌های کیفیت در توسعه نرم‌افزار را بررسی می‌کند.
• و BPMM موفقیت سیستم های سازمانی را با ارائه روش های اثبات شده برای اعتبار مورد نیاز سیستم تضمین می کند: دقت موارد استفاده و اثربخشی برنامه ها؛ ساده سازی الزامات برای برنامه های کاربردی سازمانی؛ و ارائه یک استاندارد قابل اعتماد برای ارزیابی بلوغ گردش کار فرآیندهای کسب و کار.

 Capability Maturity Model (CMM):

استاندارد نرم‌افزار تدوين شده توسط دانشكده مهندسي نرم‌افزار دانشگاه كارنگي ملون آمريكا و مؤسسه SEI (Software Engineering Institute) می باشد که چارچوبي است براي توصيف اجزاي كليدي يك فرآيند كارآمد جهت توليد نرم‌افزار و همچنین چارچوبی است برای توصيف سير بهبود تكاملي از يك فرآيند ناكامل و نامنظم به يك فرآيند تكامل يافته و منظم.

سطوح مختلف این بلوغ همانند همان بلوغ CMMI است.

به صورت کلی:

• مدل بلوغ قابلیت (CMM) روشی است که برای توسعه و اصلاح فرآیند توسعه نرم افزار یک سازمان استفاده می شود.
• این مدل یک مسیر تکاملی پنج سطحی از فرآیندهای به طور فزاینده سازمان یافته و به طور منظم بالغ تر را توصیف می کند.
• و CMM مدل قدیمی تر CMMI است.(در واقع CMMI اصول Agile را به CMM اضافه می کند تا به بهبود فرآیندهای توسعه، مدیریت پیکربندی نرم افزار و مدیریت کیفیت نرم افزار کمک کند.)
• یکی از انتقادات CMM این است که بیش از حد فرآیند محور است و به اندازه کافی هدف گرا نیست. سازمان ها به سختی می توانند CMM را با اهداف و نیازهای خاص تطبیق دهند.

 Agile Maturity Model (AMM)

• مدل بلوغ چابک ابزاری داخلی است که در سازمان‌ها استفاده می‌شود تا به سازمان‌ها کمک کند تا شیوه‌های فعلی خود را درک کنند و در جهت بهبود آن‌ها با هدف افزایش توانایی پاسخگویی به شرایط متغیر کسب‌وکار و استفاده بهتر از نوآوری‌ها تلاش کنند.
• مدل بلوغ چابک (AMM) برای محیط های توسعه نرم افزار چابک متمرکز شده است، ارزیابی سازگاری و ارزیابی تناسب را برای ارزیابی و بهبود بهترین شیوه‌های چابک معرفی می‌کند.
• برای راهنمایی و هدایت سازمان ها از رویکردهای سنتی به رویکردهای چابک استفاده می‌شود.

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»

منابع:

• A Patidar, U Suman, " A survey on software architecture evaluation methods", 2nd International Conference on Computing for Sustainable Global Development , 2015
• MA Babar, I Gorton, " Comparison of scenario-based software architecture evaluation methods ,11th Asia-Pacific Software Engineering Conference,2004
• CJ Torrecilla-Salinas, J Sedeño, MJ Escalona, " Agile, Web Engineering and Capability Maturity Model Integration: A systematic literature review", 2016
• G Remane, A Hanelt, F Wiesboeck, LM Kolbe," DIGITAL MATURITY IN TRADITIONAL INDUSTRIES – AN EXPLORATORY ANALYSIS", 2017
• C Williams,D Schallmo, K Lang," Digital Maturity Models for Small and Medium-sized Enterprises: A Systematic Literature Review", ISPIM Conference …, 2019
• https://flevy.com/blog/business-process-maturity-model-bpmm-explained/
• https://www.geeksforgeeks.org/capability-maturity-model-integration-cmmi/
• https://www2.deloitte.com/content/dam/Deloitte/global/Documents/Technology-Media-Telecommunications/deloitte-digital-maturity-model.pdf
• https://www.techtarget.com/searchsoftwarequality/definition/Capability-Maturity-Model
• https://link.springer.com/chapter/10.1007/978-3-642-38833-0_12