اسلاید پایان نامه بهبود روش ارزیابی معماری نرم افزار از دید مدیریت برون سپاری
Improving Software Architecture Evaluation Method based on Outsourcing Management Approach
42. نامه پایان مراجع از قسمتی
• B. Biel, T. Grill, and V. Gruhn, “Exploring the benefits of the
combination of a software architecture analysis and a usability
evaluation of a mobile application,” J. Syst. Softw., vol. 83, no. 11,
pp. 2031–2044, Nov. 2010.
• M. Anvaari and S. Jansen, “Evaluating architectural openness
in mobile software platforms,” in Proceedings of the Fourth European
Conference on Software Architecture: Companion Volume, 2010, pp.
85–92.
• N. Mead and T. Christian, “An Evaluation of Cost-Benefit Using
Security Requirements Prioritization.” Software Engineering Institute
Carnegie Mellon University.
• B. Costa, P. F. Pires, F. C. Delicato, and P. Merson, “Evaluating
REST architectures—Approach, tooling and guidelines,” J. Syst.
Softw., vol. 112, pp. 156–180, Feb. 2016.
• A. Zalewski and S. Kijas, “Beyond ATAM: Early architecture
evaluation method for large-scale distributed systems,” J. Syst.
Softw., vol. 86, no. 3, pp. 683–697, Mar. 2013.42از41
معمارینرم افزارالگوهای معماری و سبکهای معماریمدل مرجع ،معماری مرجعدیدگاه و ساختارهای معماریمعماری 4+1جدول ارزشدهی یانگ
برون سپاری
جنگ بین سوئد و فلاند، پادشاه سوئد هرینک هیبرتسون
یکی از راه جلوگیری از این مسئله معماری نرمافزار
نرمافزار چگونه تقسیم بندی شده و ساختارش چگونه است.
Parnas این خط فکری را گسترش داد و ماژول پنهان سازی اطلاعات و ساختارهای نرمافزاری و ... را مطرح کرد
کتابی راجع به اهمیت معماری نوشت
واسط معماری نرمافزار با اصول جدید نرمافزار توصیف کردن
توجه به معماری بعنوان سطحی جدا در طراحی معماری نرمافزار
هر سازمان که معماری را به عنوان یک اساس
برای پروسههای توسعه نرمافزار خود میپذیرد
نیاز دارد که جایگاه آن را در چرخه حیات درک کند.
یک الگوی معماری توصیفی از عناصر و انواع ارتباط بین آنها
به همراه مجموعهای از اجبارها در مورد چگونگی استفاده از آنهاست. یکی از کاربرداش خصوصیات کیفی
زبان الگو: به مجموعهای از الگوها و قوانینی برای ساخت و سازماندهی الگوهای جدید از روی الگوهای اولیه گفته میشود
سبکها بیشتر به زبان الگوها شباهت دارن تا به الگوها
الگو جزئی و دقیقتر یک راهحل را برای مسئله طراحی پیشنهاد میکند
سبک ها در حقیقت راهحل نیستند، بلکه چارچوبی برای راهحلها مشخص میکنند
سبک ماشین مجازی، سبک شی گرا، سبک جریان داده
یک مدل مرجع، تقسیم وظیفه مندی به همراه جریان داده بین بخشها است.
یک مدل مرجع تجزیه استاندارد یک مساله مشخص به بخشهایی است که به صورت اشتراکی مساله را حل میکنند.
یک معماری مرجع، مدل مرجع نگاشت داده شده به عناصر نرمافزاری و جریانهای داده بین آنهاست.
مدل معماری مین فریم، معماری فایل سرور، معماری کلاینت سرور، معماری سرویس گرا، معماری شی گرا، معماری ای ار پی
یک ساختار ماژول مجموعهای از ماژولهای سیستم و نحوه سازماندهی آن ماژولها است.
یک دید ماژول نمایشی از ساختارها است که به وسیله ذینفعان مستند شده و به وسیله ذینفعان سیستم استفاده میشود.
ساختارهای ماژول، زیر ساختار تجزیه، استفاده- لایه ای و کلاس
تجزیه Decomposition - استفاده Uses (لایه ای Layered) - کلاس یا تعمیم Class
ساختارهای مولفه و اتصال، زیر ساختار فرآیند، همزمانی، دادههای مشترک و Client-Server
Component and connector - فرآیند یا فرآیندهای ارتباطی Process - همزمانی Concurrency - مخزن یا دادههای مشترک Shared Data - سرویس گیرنده-سرویس دهنده Client-Server
ساختارهای تخصیص زیر ساختار استقرار، پیاده سازی, انتساب کار
Allocation : استقرار Deployment - پیاده سازی Implementation - انتساب کار Work Assignment
در سال 95 آقای کروچن بیان کرد
هیچ کدام از ساختار با یکدیگر تناقضی ندارند و همه آنها در جهت برطرف کردن نیازمندی های سیستم هستند
ولی بهتر است موارد کاربردی مهم به منظور انتخاب ساختارها استفاده شود.
دیدگاه منطقی Logical
دیدگاه فرآیند Process
دیدگاه توسعه Development
دیدگاه فیزیکی Physical
+
دیدگاه سناریو Scenarios
خط کش یانگ امتیاز دهی آن بر این اساس است.
در لغت به معنی دستیابی به سود از طریق منابع خارجی میباشد
به دلیل اینکه در این نوع برونسپاری شرکت سعی میکند تا یک کار (پروژه) فکری پیچیده را بهجای یک کار تکراری و معمولی که فرایند انجام آن بهراحتی قابلفهم است را برونسپاری کند
مزایا: دسترسی مناسب به بهترین تجربیات و کسب مهارتهای جدید.
تحصیل و کسب ایدههای نوآورانه.
بهرهگیری منابع داخلی برای مقاصد دیگر.
سرعت بخشیدن به مزایای مهندسی مجدد.
کاهش ریسک از طریق شریک شدن با یک واحد دیگر در محیط تجاری نامطمئن.
مدل کیفیت نرم افزار
روش ارزیابی معماری نرم افزار
یه سری مقالات در زمینه پایان نامه
اين مدلها عموماً به صورت ساختاري درختي از صفات كيفيتي و ارتباطات آنها بيان شده اند.
ذينفعان مسئله با مطالعه اين مدلها مي توانند خواسته هاي خود را دقيق تر و مشخص تر بيان دارند
و بدانند كه چه چيزهاي را بايد در توصيف خواسته هاي خود در اين زمينه مشخص نمايند
در اين مدل يك گروه بندي مفيد براي فاكتور هايي كه كيفيت نرم افزار را تحت تاثير قرار مي دهند، پيشنهاد شده است.
اين روش كيفيت نرم افزار را براساس سه جنبه خصوصيات عملياتي، توانائي اصلاح، توانائي انتقال بيان مي دارد.
Factor
Operations
Revision
Transition
International Organization for Standardization
International Electrotechnical Commission
اين مدل شش ويژگي قابليت كاركردي،
قابليت اطمينان،
قابليت استفاده،
كارآئي،
قابليت نگهداري و
قابليت حمل شدن را به عنوان ويژگيهاي اصلي كيفيتي نرم افزار بيان مي دارد.
مهمترین مزيت اين مدل اين است كه ويژگيهاي كيفي داخلي و خارجي يك نرمافزار در آن تفکیکشده است
6 ویژیگی 21 زیر ویژگی كه زير ويژگيها در اين ساختار فقط در يك ويژگي در نظر گرفته شده
زیر ویژگی ها با هم هموپشانی ندارند
Architecture Trade-off Analysis Method
روش ارزیابی معماری مبتنی بر مصالحه
به عنوان يك مدل مارپيچي ازريابي در سال 1998 مطرح شد
براساس صفات کیفیتی
قابلیت اصلاح پذيري، قابليت حمل، قابليت توسعه و قابليت تجميع
4 بخش اصلی
9 مرحله
Architecture Level Modifiability Analysis
روش تحلیل قابلیت اصلاح در سطح معماری
پيش گويي هزينه هاي لازم براي اعمال تغييرات در سيستم (هزينه هاي اصلاح پذيري در آينده)
مشخص نمودن ميزان انعطاف پذيري سيستم
مقايسه دو يا چند معماري با يكديگر
The Representational State Transfer (REST)، اخیرا سبکهای معماری بهصورت گسترده ای برای کامل کردن سرویسها و برنامههای کاربردی استفاده میشوند.
برای نشان دادن اینکه چطور این دستورالعمل میتواند کمک کند به ارزیابهای معماری، ما ارائه میدهیم یک دلیل از توصیف مفهومی که چطور استفاده میکنیم این دستورالعمل را در روش ارزیابی ATAM.
توسعه توزیع سیستمهای نرم افزاری در مقیاس بزرگ که شامل سرمایهگذاری کلان میشود
در سطح بالای از ریسک قرار گرفته است، که با روش ارزیابی ATAM آن را مورد بررسی قرار داده شده است و شرایط امنی فراهم میکند
چرخه حیات محصول از دو زیر بخش تشکیل میشود
مخاطبین چرخه حیات محصول و ساختار کلی چرخه حیات محصول
در ساختار پیشنهادی معماری نرمافزار ابتدا باید مخاطبین محصول شناخته شده باشند و سپس اینکه ساختار کلی چرخه حیات محصول به صورت مختصر در معماری بیان شود، که چه روندی در طول حیات خود دارد. وجود این بخش در معماری نرمافزار باعث میشود که صلاحیت شرکت تولید کننده معماری تا حدی معینی مشخص شود و قابل قبول باشد.
یکی از منظورهای هدف به کارگیری از چرخه حیات محصول نرمافزاری، ایجاد تعادل بین زمان و هزینه است.
معمار یا تیم معماری باید مخاطبین چرخه حیات محصول را بشناسند
تا برای طراحی و پیاده سازی نرمافزار اشراف راحتری به نرم افزار و کاربردهای آن داشته باشند
هر سیستم دارای طول عمر معینی است
که در طول آن برای تامین نیازمندیهای اطلاعاتی رو به گسترش
دست خوش تغییراتی قرار خواهد گرفت،
بر اثر تغییرات مکرر است که سیستم فوق العاده حجیم شده
و استفاده از آن دیگر مقرون به صرفه نخواهد بود
و یا با ظهور فناوریهای جدید در بازار
لاجرم مجبور به استفاده از سیستم جدید
و کنار گذاشتن سیستم جاری و نهایتا منجر به پایان عمرش میگردد.
چرخه حیات محصول نرمافزاری در ابتدا تولید و بعد به مرحله بلوغ خواهد رسید
در نهایت به مرحله مرگ ختم میشود
معمار یا تیم معماری در این قسمت از اهداف و محدودیت های حرفه و حیطه نرمافزار باید صحبت کند.
معمار یا تیم معماری در معماری نرمافزار خود باید الگوها و یا استانداردهای مورد استفاده در طراحی معماری خود سخن به میان میآورد.
عملکردهای بسیار مهم سیستم
هر گونه محدودیتهای سیاسی، اجتماعی، مدیریتی و تکنیکی مربوط به سیستم
اهداف حرفه و زمینههای مرتبط به سیستم
پیشرانهای معماری (یعنی اهداف خصوصیات کیفی اصلی که معماری را شکل میدهند).
ارتباط ويژگيهاي سطح اول مدل با 21 ويژگي فرعي مدل با سطح دوم، بهصورت يک به چند است؛
این گروه جز اعضای معرفی شده پروژه معماری نیستند و معمولا متشکل از سه یا پنج نفر است.
هر عضو از تیم دارای تعدادی از نقشهایی است که در روند ارزیابی باید مسئولیتهایی مرتبط با آن نقشها را انجام دهد.
نقشهای موجود در تیم ارزیاب یک واحد همیشه فعال است که ارزیابی معماری به صورت مداوم در آن در حال انجام شدن است.
اعضاء این تیم میتواند از معماران سیستم که در زمینه مورد نظر مهارت دارند، انتخاب شوند.
نیروهای تیم میتوانند متعلق به تیم توسعهی سازمانی باشند که معماری آن در حال ارزیابی است و یا اینکه به عنوان مشاور از خارج سازمان حضور داشته باشند.
این افراد در مذاکره به منظور توسعه و تکمیل پروژه توانایی زیادی دارند و یا قدرت و اجازه اعمال تغییرات در معماری را دارند.
آنها معمولا شامل مدیریت پروژه و نمایندگانی از مشتری هستند که از توسعه سیستم به صورت مالی پشتیبانی میکنند.
برای معمار معمولا نقش خاصی در ارزیابی معماری وجود دارد که باید آن را به صورت مناسب انجام دهد. نهایتا، شخصی که ماموریت ارزیابی را دارد که باید آن را به صورت مناسب انجام دهد.
شخصی که ماموریت ارزیابی را دارد معمولا توانایی و قدرت مذاکره برای توسعه و تکمیل پروژه دارد (حتی اگر قدرت آن را نداشته باشد) و باید جزء این گروه قرار بگیرد.
ذینفعان در مورد این معماری را به عنوان مبنایی برای تبلیغ کار خود قرار دهند، سود زیادی به دست میآورند.
آنها اشخاصی هستند که توانایی انجام کارهایشان وابسته به ترویج قابلیت تغییرپذیری، امنیت، قابلیت دسترسی بالا و سایر خصوصیات معماری است.
ذینفعان دربرگیرنده توسعهدهندگان، آزمایش کنندگان، یکپارچهسازها، نگهدارندها، مهندسی کارایی، کاربران، سازندگان سیستم و سایر افراد درگیر توسعه سیستم هستند.
نقش دینفعان در روند ارزیابی آن است که اهداف خصوصیات کیفی خاص که لازم است در معماری برای موفقیت سیستم وجود داشته باشد را بیان کنند.
در این مرحله با ایجاد سناریو یک درخت سودمندی تشکیل میدهیم
به این صورت که ریشه کلمه سودمندی فرزند ریشه صفات کیفی، و فزرند صفات کیفی را سناریو ها تشکیل میدهند که برای این کار ما از مدل کیفیتی ISO 9126 استفاده میکنیم
برای ساده سازی سناریو و امتیاز دهی به آن از جداول زیر استفاده میکنم
برای ازریابی از جدول ازرش دهی یانگ استفاده میکنیم
تصمیمات معماری وجود دارند که تاثیرات مشخصی بر روی خصوصیات کیفی دارند. برای مثال، کاملا واضح است که در نظر گرفتن پایگاه داده پشتیبان یک تصمیم معماری است به طوری که این تصمیم قابلیت اطمینان را به صورت مثبت تحت تاثیر قرار میدهد بنابراین چنین تصمیمی یک نقطه با توجه به قابلیت اطمینان تلقی میشود.
با این وجود پشتیبانگیری باعث مصرف منابع سیستم شده و بنابراین کارایی را بصورت منفی تحت تاثیر قرار میدهد.
لذا آن را میتوان یک نقطه مصالحه بین کارآیی و قابلیت اطمینان دانست.
اینکه این تصمیم خطر است یا نه بستگی به این دارد که آیا هزینه کارایی در زمینه نیازمندیها خصوصیات کیفی معماری زیاد است یا نه؟
فهم واضح سهامداران از معماری
افزایش ارتباط بين سهامداران
بهبود و تکمیل مستندات معماری
نتایج برگرفته از سناریو
ارضای صفات کیفی و وظیفه غیرعملکردی سیستم
که بوسیله رابطه " یک زیر ماژول است از "به ماژولهای کوچکتر تقسیم میشوند که این موضوع نشان میدهد چگونه ماژولهای بزرگتر به ماژولهای کوچکتر تقسیم میشوند.
رابطه " استفاده میکند از " به واحدهای دیگر مرتبط میشوند و منظور این است که صحت واحدی که از واحد دیگر استفاده میکند به صحت واحد استفاده شده بستگی دارد.
در این ساختار هر لایه به سرویسهای لایه پایینتر از خود دسترسی دارد
ارتباط در این نوع ساختار "الحاق"است که نشان میدهد چگونه اتصالها و مولفهها یکدیگر را کنترل میکنند
یک نخ منطقی مجموعهای از محاسبات پشت سرهم است که میتواند به نخی فیزیکی جداگانه درفرآیند طراحی تخصیص داده شود.
در این ساختار، رابطه "تخصیص داده شده به" نشان میدهد واحدهای فیزیکی عناصر نرمافزاری به چه چیزی تخصیص داده شدهاند و رابطه "منتقل شده به" نیز برای تخصیص پویا استفاده میشود.
یه ماژول در ساختار تجزیه ممکن است به یک یا چند عنصر ساختار مولفه و اتصال تبدیل شود.
در تمام سیستم ها نیاز نیست که از کلیه ساختارها استفاده شود
در سیستم های بزرگ هر ساختار ممکن است آنقدر بزرگ باشد که طراح مجبور باشد آنها را به زیرساختارهایی تبدیل کند.
تمامی ذینفعان پروژه در این قسمت درگیر هستند.
نمای کلی سیستم را ترسیم میکند، سپس به بررسی قسمتهای مهم توسط usecase دیاگرامها می پردازد.
توصیف معماری با استفاده از مجموعه ای از use case ها که توصیفگر توالی ارتباطات بین اشیا و پروسه ها هستند.
در این دیدگاه عملیات اصلی مورد نقد قرار میگیرد فعلان در هر عملیات مشخص میشود و جریانهای اصلی کار مشخص میشود.
مهمترین سند حاصل از این دیدگاه سند موارد کاربرد است.
دید فرایند توزیع، کارایی و مقیاس پذیری را پوشش می دهد.
در UML از نمودار های Activity برای نمایش ان استفاده می شود.
نحوه همزمانی و توزیع وظیفهمندیها را نشان میدهد.
دید فرآیند، درگیر وجهه پویای سیستم است. پروسه های سیستم را توصیف کرده و نحوه تعامل آن ها با هم.
حیطه کاری این دیدگاه پیرامون نیازمندیهای غیر عملکردی است که همروندی و همزمانی پردازش ها را مورد مطالعه قرار میدهد.
این دیدگاه محصول (artifact) جداگانهای در اختیار نمیگذارد.
دید مولفه و اتصال: در این قسمت باید فرآیندها و نخها همراه با همگام سازی، جریان داده و رویدادها که آنها را به یکدیگر متصل میکند، نشان داده شود.
برنامه نویسان افرادی هستند که در این دیدگاه دخیل هستند.
برای نمایش این دید در UML از نمودار Component یاPackage استفاده میکنیم
دیدگاه پیاده سازی که توصیف معماری و طراحی داخلی سیستم میباشد، ارائه از تجزیه و تحلیل لایهها و قسمتهای مختلف سیستم میباشد.
این دیدگاه مشخصا به کامپوننتهای نرمافزاری اشاره کرده و لایه ها، زیرلایهها، زیرسیستمها و نحوه ارتباط بین آنها را تشریح میکند.
مدل پیاده سازی محصولات حاصل از این دیدگاه میباشند.
دید فیزیکی سیستم را از دید یک مهندس سیستم نمایش می دهد.
دید توسعه برای تشریح سیستم از دید یک برنامه نویس است و درگیر مدیریت نرمافزار است.
در UML از نمودار های Deployment برای نمایش لایه فیزیکی استفاده میشود.
این دید درگیر توپولوژی کمپوننت های نرمافزاری در لایه فیزیکی است، بعلاوه ارتباطات فیزیکی بین این کمپوننت ها.
نحوه نگاشت اجزا را به پردازندهها و گرههای ارتباطی مشخص میکند
این ساختار مشابه ساختار تخصیص است اما بیشتر جنبه استقرار مدنظر آن است.
حیطه این دیدگاه در مورد توپولوژی استقرار میباشد.
این دیدگاه به تشریح نحوه نگاشت نرمافزار در محیط فیزیکی و سختافزار میپردازد و جنبههای توسعه نرمافزار را نشان میدهد.
در این دیدگاه با توصیف سناریو استقرار در معماری به توصیف ساختار نهایی استقرار پرداخته و فرضهایی در مورد نیاز در زمان استقرار بیان میکنیم.
مهمترین خروجی این قسمت سند استقرار نام دارد.
اجزا: عناصر اوليه هر نرم افزاری را تشکيل می دهند، نظير پايگاه های داده، عناصر محاسباتی، و ...
اتصالات: توپولوژی و نحوه ساماندهی و ارتباط اجزا با يکديگر را نشان می دهند.
قوانين: مجموعه ای از محدوديت ها و مقررات که نحوه ترکيب اجزا، محدوديت های اعمال شده روی اتصالات، و ... را مشخصمی کنند.
مکانيزم تعامل: روشی که نشان می دهد اجزای نرم افزار از طريق توپولوژی تعيين شده چگونه با يکديگر همکاری داشته و کنترل اجرا چگونه ميان آنها منتقل می شود. به عنوان مثال فراخوانی ها يک نمونه از اين چنين مکانيزمی هستند.
هدف این سبک معماری، رسیدن به کیفیت برقراری یکپارچگی و یا قابلیت تجمیع پذیری میباشد.
هدف در این سبک رسیدن به ویژگی استفاده مجدد و اصلاح پذیری است
اولی در خانواده unix
هدف اصلی رسیدن به قابلیت حمل بالا است
در این شکل سه نوع داده موجود هستند
برنامه در حال تفسیر شدن
دادههای برنامه
حالات داخلی مفسر
موتور تفسیر دستوری را از برنامه در حال تفسیر انتخاب میکند، حالات داخلی خود را بهنگام میکند و بنابر دستور، قاعدتا دادههای برنامه را به هنگام میسازد.
هدف قطعه قطعه کردن برنامه به قطعات کوچکتر، برای رسیدن به اصلاح پذیری بالاتر است
نسخه مدرنی از سبکهای فراخوانی بازگشت است
قابلیت استفاده مجدد و اصلاح پذیری را بالا میبرد
زمانی استفاده می شوند که مساله کارایی در زمان اجرا مورد نظر باشد
يكي از روشهاي معروف مبتني بر سناريو روش تحليل معماري مبتني بر مصالحه مي باشد. اين روش به صورت كاملاً جدا از روشهاي قبلي توسعه يافت و هدف از آن تحليل صفات كيفيتي خاص براساس معماري ميباشد.
ATAM بر روي جنبه هاي كيفيتي معماري با جزئيات بيشتري از روشهاي قبل از خود بحث مي كند، و در عمل نسخه تقويت شده اي از SAAM مي باشد.
ATAMبه عنوان يك مدل مارپيچي ازريابي در سال 1998 مطرح شد
ATAMيك روش مبتني بر سناريو براي ارزيابي صفات كيفيتي مانند: قابليت اصلاح پذيري، قابليت حمل، قابليت توسعه و قابليت تجمع ميباشد.
اين روش چگونگي تامين شدن اهداف كيفيتي توسط معماري سيستم پيشنهادي را با استفاده از يك فرآيند تكرار پذير ارزيابي مي نمايد.
هدف روش ارزيابي ATAM فراهم كردن يك راه اصولي براي فهميدن توانائي معماري نرم افزار با در نظر گرفتن چندين صفت كيفيتي كه با يك ديگر رقابت دارند، مي باشد.
ATAM علاوه بر ارزيابي صفات كيفيتي، وابستگي هاي اين صفات كيفيتي را نيز مشخص مي نمايد.
این گروه جز اعضای معرفی شده پروژه معماری نیستند و معمولا متشکل از سه یا پنج نفر است.
هر عضو از تیم دارای تعدادی از نقشهایی است که در روند ارزیابی باید مسئولیتهایی مرتبط با آن نقشها را انجام دهد.
نقشهای موجود در تیم ارزیاب یک واحد همیشه فعال است که ارزیابی معماری به صورت مداوم در آن در حال انجام شدن است.
اعضاء این تیم میتواند از معماران سیستم که در زمینه مورد نظر مهارت دارند، انتخاب شوند.
نیروهای تیم میتوانند متعلق به تیم توسعهی سازمانی باشند که معماری آن در حال ارزیابی است و یا اینکه به عنوان مشاور از خارج سازمان حضور داشته باشند.
این افراد در مذاکره به منظور توسعه و تکمیل پروژه توانایی زیادی دارند و یا قدرت و اجازه اعمال تغییرات در معماری را دارند.
آنها معمولا شامل مدیریت پروژه و نمایندگانی از مشتری هستند که از توسعه سیستم به صورت مالی پشتیبانی میکنند.
برای معمار معمولا نقش خاصی در ارزیابی معماری وجود دارد که باید آن را به صورت مناسب انجام دهد. نهایتا، شخصی که ماموریت ارزیابی را دارد که باید آن را به صورت مناسب انجام دهد.
شخصی که ماموریت ارزیابی را دارد معمولا توانایی و قدرت مذاکره برای توسعه و تکمیل پروژه دارد (حتی اگر قدرت آن را نداشته باشد) و باید جزء این گروه قرار بگیرد.
ذینفعان در مورد این معماری را به عنوان مبنایی برای تبلیغ کار خود قرار دهند، سود زیادی به دست میآورند.
آنها اشخاصی هستند که توانایی انجام کارهایشان وابسته به ترویج قابلیت تغییرپذیری، امنیت، قابلیت دسترسی بالا و سایر خصوصیات معماری است.
ذینفعان دربرگیرنده توسعهدهندگان، آزمایش کنندگان، یکپارچهسازها، نگهدارندها، مهندسی کارایی، کاربران، سازندگان سیستم و سایر افراد درگیر توسعه سیستم هستند.
نقش دینفعان در روند ارزیابی آن است که اهداف خصوصیات کیفی خاص که لازم است در معماری برای موفقیت سیستم وجود داشته باشد را بیان کنند.
همانطور که در جدول بالا یک نگاه اجمالی به روش ارزیابی بهبود یافته ATAM انداختیم. روش ارزیابی چهار فاز دارد، که فاز صفر اولین گام ارزیابی هست هماهنگی رهبر تیم ارزیابی با تصمیمگیرندگان کلیدی پروژه میباشد.
فاز یک و دو، در نه مرحله انجام میپذیرد. که فاز اول در شش مرحله و در ادامه فاز دوم، در سه مرحله انجام میپذیرد.
فاز سوم که اخرین گام ارزیابی معماری نرمافزار میباشد، فاز نتیجه گیری و گزارش کار می باشد.
در مرحله اول، رهبر ارزیابی ATAM را برای نمایندگان پروژه ارائه میکند.
در واقع از این مرحله به منظور تشریح فرآیندی که هر شخص آن را انجام خواهد داد و پاسخگویی به سوالات و ایجاد زمینه و انتظاراتی برای باقیمانده فعالیتها، استفاده میشود.
بنابراین رهبر با استفاده از ارائه استانداردی، مراحل ATAM و خروجیها آن را تشریح خواهد کرد.
هر شخص درگیر در ارزیابی (نماینده پروژه و اعضای تیم) نیاز به درک زمینه سیستم و پیشرانهای منجر به توسعه سیستم را دارد.
ارائهای که تصمیم گیرنده پروژه انجام میدهد باید مطالب زیر را تشریح کند:
عملکردهای بسیار مهم سیستم
هر گونه محدودیتهای سیاسی، اجتماعی، مدیریتی و تکنیکی مربوط به سیستم
اهداف حرفه و زمینههای مرتبط به سیستم
ذینفعان اصلی
پیشرانهای معماری (یعنی اهداف خصوصیات کیفی اصلی که معماری را شکل میدهند).
ارائهي معماري در اين مرحله، معماري سيستم شرح داده مي شود.
در طی شرح معماری، تنها در حد لزوم وارد جزئيات ميشويم.
محدوديت هاي فنّي احتمالی، مانند سیستم عامل، سخت افزار یا میان افزار مورد استفاده در سيستم مورد بررسي قرار ميگيرند.
در این مرحله صحبت راجع به محدودیت ها، اهداف مرتبط با نرمافزار سخن گفته میشود
تمرکز ATAM بر روی تحلیل معماری از طریق درک روشهای معماری آن است.
الگوهای معماری در زمینه شناخت روشهایی که هر یک خصوصیات کیفی خاصی را تحت تاثیر قرار میدهند، بسیار کارآمد هستند.
الگوی لایهبندی قابلیت حمل را از طریق تحت تاثیر قرار دادن کارایی به ارمغان میآورد (باعث کاهش کارایی میشود) و الگوی مخزن داده نیز معمولا قابلیت گستردگی برای مصرفکنندگان و تولیدکنندگاه داده به ارمغان میآورد.
آنها مستند معماری را مطالعه کرده و همچنین ارائه معمار را نیز خواهند شنید.
فهرست برداری میشود از تمامی الگوها و استانداردهایی که در معماری استفاده شده و پایهای برای کارهای بعدی قرار میدهند
در این مرحله با ایجاد سناریو یک درخت سودمندی تشکیل میدهیم
به این صورت که ریشه کلمه سودمندی فرزند ریشه صفات کیفی، و فزرند صفات کیفی را سناریو ها تشکیل میدهند که برای این کار ما از مدل کیفیتی ISO 9126 استفاده میکنیم
برای ساده سازی سناریو و امتیاز دهی به آن از جداول زیر استفاده میکنم
برای ازریابی از جدول ازرش دهی یانگ استفاده میکنیم
تحليل رويكردهاي معماري در این مرحله، سناريوها به ترتيب نزولي اهميت مورد بررسي قرار ميگيرند.
براي هر سناريو، مقدار و چگونگي پشتيباني سناريو از آن تعيين ميشود.
در اين مرحله موارد خطرات و غير خطرات، و نيز نقاط حساسيت و مصالحهی مشخّص ميگردند.
در انتهاي اين مرحله، وارد فاز دو ميشويم.
در فاز دو، يك بار ديگر مراحل 1 تا 6 با حضور ذينفعان پروژه مورد مرور قرار ميگيرند، تا به مرحله بعدی برسیم.
سناریوهای اولیت بندی شده در درخت سومندی
وقتی سناریوها جمع آوری شدند باید اولیت بندی شوند.
از ذینفعان خواسته میشود سناریوها با رفتار یکسان و یا مرتبط با یک دغدغه یکسانی هستند را ادغام کنند سپس آنها به سناریوهایی که احساس میکنند خیلی مهم هستند رای میدهند.
هر ذینفع معادل سی درصد تعداد سناریو، رای میدهد. بنابراین اگر چهل سناریو بدست آمده باشد هر ذینفع شش رای میتوانند بدهد.
آراء میتوانند در هر روشی تخصیص یابد. به عنوان مثل یک ذینفع میتواند هر شش رای خود را به یک سناریو دهد و یا اینکه به هر سناریو یک رای دهد.
سناریوهای مهم مشخص شده
معمار تشریح میکند که چگونه تصمیمات مربوط به معماری برای تحقق هر کدام از سناریوها به کار گرفته شدهاند.
در این مرحله تیم ارزیابی فعالیتهای مشابه با مرحله شش را که نگاشت سناریوهای جدید و دارای بالاترین رتبه به فرآوردههای معماری تا به حال پوشش داده نشده است، تکرار میکند.
تصمیمات معماری میتوانند بر حسب خصوصیاتی کیفی که آنها پشتیبانی یا جلوگیری میکند، تفسیر شوند. برای هر سناریوی کیفی مورد بررسی قرار گرفته در روند اعمال ATAM، تصمیمات معماری که منجر به دستیابی به آن میشود، مشخص میشوند.
تصمیمات معماری وجود دارند که تاثیرات مشخصی بر روی خصوصیات کیفی دارند. برای مثال، کاملا واضح است که در نظر گرفتن پایگاه داده پشتیبان یک تصمیم معماری است به طوری که این تصمیم قابلیت اطمینان را به صورت مثبت تحت تاثیر قرار میدهد بنابراین چنین تصمیمی یک نقطه با توجه به قابلیت اطمینان تلقی میشود. با این وجود پشتیبانگیری باعث مصرف منابع سیستم شده و بنابراین کارایی را بصورت منفی تحت تاثیر قرار میدهد. لذا آن را میتوان یک نقطه مصالحه بین کارآیی و قابلیت اطمینان دانست. اینکه این تصمیم خطر است یا نه بستگی به این دارد که آیا هزینه کارایی در زمینه نیازمندیها خصوصیات کیفی معماری زیاد است یا نه؟
خطر در ATAM به عنوان تصمیم معماری تعریف میشود که منجر به نتایج نامطلوب در وضعیت نیازمندیهای خصوصیاتکیفی میشود. به همین صورت غیر خطر نیز تصمیم معماری است که امن در نظر گرفته میشود خطرات شناسایی شده میتوانند مبنایی را برای برنامه کاهش خطر معماری شکل دهند.
زمانی که تحلیل کامل شد تیم ارزیابی کلیه خطرات کشف شده را بررسی میکنند تا عناوینی را به دست آورد که ضعفهای سیستماتیک در معماری و یا حتی در فرآیند و تیم معماری را مشخص میکند. اگر با این خطرات برخورد نشود آنها اهداف حرفه پروژه را تهدید خواهد کرد.
تصمیمات معماری وجود دارند که تاثیرات مشخصی بر روی خصوصیات کیفی دارند. برای مثال، کاملا واضح است که در نظر گرفتن پایگاه داده پشتیبان یک تصمیم معماری است به طوری که این تصمیم قابلیت اطمینان را به صورت مثبت تحت تاثیر قرار میدهد بنابراین چنین تصمیمی یک نقطه با توجه به قابلیت اطمینان تلقی میشود.
با این وجود پشتیبانگیری باعث مصرف منابع سیستم شده و بنابراین کارایی را بصورت منفی تحت تاثیر قرار میدهد.
لذا آن را میتوان یک نقطه مصالحه بین کارآیی و قابلیت اطمینان دانست.
اینکه این تصمیم خطر است یا نه بستگی به این دارد که آیا هزینه کارایی در زمینه نیازمندیها خصوصیات کیفی معماری زیاد است یا نه؟
خطر در ATAM به عنوان تصمیم معماری تعریف میشود که منجر به نتایج نامطلوب در وضعیت نیازمندیهای خصوصیات کیفی میشود.
به همین صورت غیر خطر نیز تصمیم معماری است که امن در نظر گرفته میشود.
خطرات شناسایی شده میتوانند مبنایی را برای برنامه کاهش خطر معماری شکل دهند.
زمانی که تحلیل کامل شد تیم ارزیابی کلیه خطرات کشف شده را بررسی میکنند تا عناوینی را به دست آورد که ضعفهای سیستماتیک در معماری و یا حتی در فرآیند و تیم معماری را مشخص میکند.
اگر با این خطرات برخورد نشود آنها اهداف حرفه پروژه را تهدید خواهد کرد.
سهامداران بصورت كاملاً روشن و واضح معماري را مي فهمند.
ارتباط بين سهامداران زياد است و افزايش مي يابد.
مستندات معماري در جريان ارزيابي بهبود مييابد و در صورت لزوم دوباره ايجاد ميشود.
نتايج معماري براساس سناريو هاي كيفيتي و موارد كاربري استخرا ج مي شود.
سناريوهاي كيفيتي توليد شده بوسيله سهامداران يا بعضاً تيمATAM براساس نيازمنديهاي غيروظيفهمندي كيفيتي است.
رابطه ذینفعان سیستم و معماری بیچاره خخخخ
هر ذینفع علاقمندی و اهداف خاص خود را دارد معمار با توازن بین آنها در سطح مناسبی اهداف را برآورده میکند
ساختار و ماهیت سازمان توسعه دهنده بر معماری تاثیر میگذارد بهرهدهی کوتاه مدت
استانداردهای عملی صنعتی یا فنون متداول مهندسی نرمافزار اثر مستقیمی بر معماری نرمافزار دارد
در این شکل یه سری مفهوم به ما میرسونه ولی معماری نرم افزار نیست
چون نمیگه هر دایره چکاره هست
نمیگه اهمیت کدوم مهمتره
نمیگه سمت فلش ها بکدوم سمت هست و کدوم اوله کدوم دوم
و ....