دانشگاه صنعتی شیراز دانشکده مهندسی کامپیوتر و فناوری اطالعات گروه

مهندسی کامپیوتر

پایان نامه کارشناسی ارشددر رشته مهندسی کامپیوتر گرایش نرم افزار

بهبود روش ارزیابی معماری نرم افزار از دیدمدیریت برون سپاری

نگارش:آرش رضوانی

استاد راهنما:دکتر سید رئوف خیامی

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

94بهمن

بسمه تعالی

بهبود روش ارزیابی معماری نرم افراز از دیدمدیریت برون سپاری

پایان نامه ارائه شده به عنوان بخشی از فعالیت هایتحصیلی

نگارش:

آرش رضوانی

برای اخذ درجه کارشناسی ارشد

گروه مهندسی کامپیوتر دانشکده مهندسی کامپیوتر ودانشگاه صنعتی شیرازفناوری اطالعات

ارزیابی پایان نامه توسط هیات داوران با درجه: عالی دکتر سید رئوف خیامی مرتبه علمی استادیار در رشته مهندسی کامپیوتر

)استاد راهنما (................... دکتر امید بوشهریان مرتبه علمی استادیار در رشته مهندسی کامپیوتر

)استاد مشاور(........................... دانشور محمد رفیع خوارزمی مرتبه علمی مربی در رشته مهندسی فناوری

اطالعات )داور(.................._____________________________________________________

مدیر امور آموزشی و تحصیالت تکمیلی دانشگاه:

_____________________________________________________حق چاپ محفوظ و مخصوص به دانشگاه صنعتی شیراز است.

94بهمن

تأييديه ي صحت و اصالت نتايج

اينج44انب آرش رض44وانی دانش44جوي رش44ته مهندس44ی ک44امپیوتر مقط44ع تأيي44د92214014تحصيلي کارشناسی ارش44د ب44ه ش44ماره دانش44جويي

می نمای44د كلي44ه نت44ايج اين پایان نام44ه/رس44اله، ب44دون هیچ گون44ه دخ44ل و تصرف ، حاصل مستقيم پژوهش صورت گرفته توسط اينجانب اس44ت. در مورد اقتب44اس مس44تقيم و غیرمس44تقیم از س44اير آث44ار علمي، اعم از كتاب، مقاله، پایان نام44ه ب44ا رع44ايت ام44انت و اخالق علمي، مشخص44ات

كامل منبع مذكور درج شده است. در صورت اثبات خالف مندرجات فوق، به تش44خيص مقام44ات ذی ص44الح دانش444گاه ص444نعتي ش444يراز، مط444ابق ق444وانين و مق444ررات مرب444وط و آئین نامه ه44ای آموزش44ي، پژوهش44ي و انض44باطي عم44ل خواه44د ش44د و اينجانب حق هرگونه اعتراض و تجديدنظر را، نسبت به رأي صادره، از خود ساقط می کند. همچنين، هرگونه مسئوليت ناشي از تخلف نس44بت به صحت و اصالت نتايج مندرج در پایان نامه/رس44اله در براب44ر اش44خاص ذی نفع )اعم از حقيقي و حق44وقي( و مراج44ع ذی ص44الح )اعم از اداري و قضايي( متوجه اينجانب خواهد بود و دانشگاه صنعتي ش44يراز هیچ گون44ه

مسئوليتي در این زمينه نخواهند داشت. - كليQQه حقQQوق مQQادي اين اثQQر متعلQQق بQQه1تبصQQره

دانشگاه صنعتي شيراز است.

- اينجانب تعهد می نماید بدون اخذ مجQQوز از2تبصره دانشQQگاه صQQنعتي شQQيراز دسQQتاوردهاي اين پایان نامQQه/رساله را منتشر نكند و يا در اختيار ديگران قرار ندهد.

نام و نام آرش رضوانیخانوادگي دانشجو:

تاريخ و امضاء

مجوز بهره برداري از پايان نامه

ب

کلیه حقوق مادی و معنوي مترتب بر نتایج پایان نامه متعلق به دانشگاه و انتشار نتایج نیز تابع مقررات دانشگاهی است و با موافقت استاد

راهنما به شرح زير، بالمانع است:

.بهره برداري از اين پايان نامه/ رساله براي همگان بالمانع است ،بهره برداري از اين پايان نامه/ رساله با اخذ مجوز از استاد راهنما

بالمانع است.بهره برداري از اين پايان نامه/ رساله تا

تاريخ .................................... ممنوع است.

نام استاد يا اساتيدراهنما:

دکتر سیدرئوف خیامی

تاريخ:

امضا:

ج

ماحصل آموخته هایم را تقدیم می کنم

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

و همچنین دانشجویانی که این تحقیق گره از مشکل تحقیقاتی شان

برمی دارد، ان شاء الله.

د

تشکر از خدای مهربانم می کنم که در تمام عمر مرا یاری نمود.

تشکر از خانواده مهربانم، پدر عزیزم، مادر دلسوزم و برادران مهربانم

می کنم.

تشکر از استاد عزیزم دکتر سید رئوف خیامی که واقعا مثل اسمشان

رئوف و مهربان هستند.

تشکر از دکتر بوشهریان که با مشاورهای خوبشان، من را در به پایان

رساندن این تحقیق کمک کردند.

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

تحقیقات

همکاری خوبی انجام دادن، بخصوص از آقای مهندس صادقی و آقای

مهندس فیاضی

سپاسگزاری از تمامی دوستانم که طی این سال های به من یاری نمودند.

ه

چکیده

بهبود روش ارزیابی معماری نرم افراز از دیدمدیریت برون سپاری

نگارش :

آرش رضوانی

امروزه ارزیابی معماری نرم افزار، برای نرم افزارهای بزرگ و پیچیده یک امر مهم و ضروری است. نرم افزارها هرروز پیچیده و

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

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

برای صفات کیفیتی در معماری نرم افزار روش های متعددی ارائه شده است. بیشتر روش های ارزیابی روی صفات کیفی مانور می دهند، که

معماری نرم افزار ارزیابی شده اهداف کیفی و کمی ذی نفعان سیستمرا برآورده می کند و یا اینکه این اهداف را ارضا نمی کند.

در این تحقیق مقدمه ای در مورد معماری نرم افزار، و اینکه اهداف و کاربردهای ارزیابی معماری نرم افزار چه چیزی است، بیان

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

به عنوان روش پایه و مبنی توسعه انتخابATAMروش ارزیابی گردید. در روش پیشنهادی، عالوه بر ارائه ساختار معرفی معماری با

در ایجاد درخت سودمندی وISO 9126استفاده از مدل کیفیتی بهبود داده شده است. در ادامه برایATAMسناریوها، روش ارزیابی

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

معماری نرم افزار، ارزیابی معماری نرم افزار،واژه هاي كليدي:ATAMمدل های کیفیت،

و

ز

فهرست مطالب

1.فصل اول: مقدمه12.....................................................................- مقدمه1-14......................................................- بیان کلیات مسئله1-25.....................................................- پرسش های تحقیق1-35...........................................................- اهداف تحقیق1-47......................................- اهمیت و ضرورت انجام تحقیق1-57.............................................................- جنبه نوآوری1-68................. و نتایج مورد انتظار از تحقیقمتصور- کاربردهای 1-78.....................................................- روش انجام تحقیق1-88.....................................................پایان نامه- بخش هاي 1-9

.فصل دوم: ادبیات تحقیق و مروری بر تحقیقات210انجام شده

11...................................................................- مقدمه2-111.....................................- تعاريف، اصول و مباني نظري2-211................................................- برون سپاری چیست؟2-312.......................- شمای کلی برون سپاری از گذشته تا حال2-4 - دالیل روی آوردن سازمان ها و شرکت ها به رویکرد2-5

12...................................................................برون سپاری13..- گام های الزم برای شناسایی فعالیت های قابل برون سپاری2-614............- چه نوع فعالیت هایی را می توان برون سپاری کرد؟2-714..............- چارچوبی برای تصمیم گیری برون سپاری خدمات2-816........................- ریسک های برون سپاری توسعه نرم افزار2-9

17................................- استانداردهای مهندسی نرم افزار2-1018...............................- بخش استانداردهای محصول۲-10-1AD.................................19- مرحله طراحی معماری 2-10-2

21...................................................- معماری نرم افزار2-1125.............................................- تصميمات معماري۲-۱1-۱26.....................................- معماری در چرخه حیات2-11-2

27.....................- الگوی معماری مدل مرجع معماری مرجع2-1228.............................- نمونه ای از معماری های مطرح۲-۱2-۱

28..................................- دیدگاه ها و ساختارهای معماری2-1329..................................................- ساختارهای ماژول2-1429............................................- ساختار مولفه و اتصال2-1530...............................................- ساختارهای تخصیص2-1631....................................- ساختارهای معماری نرم افزار2-17

32...........................................................- ماژول2-17-133................................................- مولفه و اتصال2-17-233.........................................................- تخصیص2-17-3

35........................................................- سبک معماری2-1836......................................- انواع سبک های معماری2-18-1

40.........................................- ارزیابی معماری نرم افزار2-1941...........................- ویژگی های کیفیتی معماری نرم افزار2-20

44......................................- توضیح کامل صفات کیفیتی2-2144...........................................................- كارايي2-21-145............................................................- امنيت2-21-246.............................................- در دسترس بودن2-21-347.............................- قابليت عملكرد يا وظیفه مندی2-21-447................................................- قابليت استفاده2-21-548...........................................- قابليت اصالح پذیری2-21-650....................................................- قابليت حمل2-21-750........................................- قابليت استفاده مجدد2-21-851..........................................- قابليت تجميع پذيري2-21-9

51..............................................- قابليت آزمايش2-21-1052............................................- جدول ارزش دهی یانگ2-2253.......................................- مروری بر تحقیقات پیشین2-2353.................- مروري بر مدل های معروف كيفيت نرم افزار2-24

McCall....................................................53- مدل 2-24-1ISO/IEC...................................................56- مدل 2-24-2IEEE.......................................................57- مدل 2-24-3ISO/IEC-9126.............................................58 مدل -2-24-4

60..................- روش های مشهور ارزیابی معماری نرم افزار2-25ATAM.........60- روش تحليل معماري از طريق مصالحه 2-25-1CBAM...........................62- روش تحليل هزينه- سود 2-25-2.ALMA- روش تحليل قابليت اصالح در سطح معماري 2-25-3 .64HoPLAA....66- روش کل نگر ارزیابی معماری خط تولید 2-25-4

69...................- مقايسه روش های ارزيابي مبتني بر سناريو2-2673.فصل سوم: روش پیشنهادی برای حل مسئله3

74...................................................................- مقدمه3-174......................- ساختار معماری نرم افزار روش پیشنهادی3-2

PLC.....................................75- چرخه حیات محصول 3-2-177.........- استاندارد، الگوها، اهداف و محدودیت نرم افزار3-2-278........................................1+4- استفاده معماری 3-2-3

81...........................- بهبود روش ارزیابی معماری نرم افزار3-3ATAM....................82- روش ارزیابی معماری نرم افزار 3-3-1ATAM...................................85- مشارکت کنندگان در 3-3-2ATAM....................................................88- مراحل 3-3-3ATAM...........................................95- انواع خروجی 3-3-497..... در ارزیابی معماری نرم افزارISO 9126- مدل کیفیتی 3-3-5107...........................................................- سناریو3-3-6

110.فصل چهارم: ارزیابی معماری نرم افزار4111.......................................- ارزیابی معماری نمونه یک4-1

111...........................................................- مقدمه4-1-1111..................................- نحوه سازماندهی معماری4-1-2111..........................- اهداف و محدودیت های معماری4-1-3112........................................- دیدگاه موارد کاربردی4-1-4

ط

113.................................................- دیدگاه منطقی4-1-5118............................................- دیدگاه پیاده سازی4-1-6118................................................- دیدگاه استقرار4-1-7119.......................................................- مدل داده4-1-8120...............................................- کیفیت و کارآیی4-1-9

125.........................................- ارزیابی معماری نمونه دو4-2131.............................................................- جمع بندی4-3

132.فصل پنجم: جمع بندی و پیشنهادها5133.................................................................- مقدمه5-1133............................................................- نتیجه گیری5-2136.............................................................- پیشنهاد ها5-3

137مراجع

ي

فهرست شکل ها

12........................................ شمای کلی برون سپاری1-2شکل ESA........................18 استانداردهای مهندسی نرم افزار 2-2شکل SR............................................20 نمای کلی مراحل 3-2شکل 22..... مراحل تبديل نيازمنديهاي كاربر به معماري نرم افزار4-2شکل 25................................ مراحل تولید معماری نرم افزار5-2شکل 27..................................... چرخه حیات تحویل تکاملی6-2شکل ارتباط بین مدل مرجع، الگو معماری، معماری مرجع و7-2شکل

28...........................................................................معماری30.................................. ساختارهای معماری نرم افزار8-2شکل 37..................................... سبک متمرکز بر روی داده9-2شکل Pipe&Filter...............................38 سبک جریان داده - 10-2شکل Batch/Sequential...........................38 سبک جریان داده -11-2شکل 39........................................... سبک ماشین مجازی12-2شکل 39.............................. سبک برنامه اصلی و زیر روال13-2شکل 40................................... سبک سیستم های شیءگرا14-2شکل 40...................................... سبک سیستم های الیه ای15-2شکل .Mc call ساختار دسته بندی خصوصيات كيفيتي در مدل 16-2شکل .55Mc call............................................56 مدل کیفیتی 17-2شکل 59................................. جنبه های استاندارد نرم افزار18-2شکل HoPLAA..............................67 ورودی خروجی روش 19-2شکل 70........................ ارتباط سيستم موردنیاز با معماری.20-2شکل 76.................................... دوران چرخه حیات محصول1-3شکل 78.....................................................1+4 معماری 2-3شکل ATAM...................................................83 روند کار 3-3شکل 98......................... شاخص های ارزیابی کیفیت نرم افزار4-3شکل 108.............. بخش های اصلی سناریوی خصوصیات کیفی5-3شکل 113........................ دیاگرام موارد کاربردی )سطح باال(1-4شکل 114......................... دیاگرام دیدگاه منطقی )سطح باال(2-4شکل 115................. دیاگرام فعالیت برای الگوریتم مسیریابی3-4شکل . دیاگرام مربوط به سناریو تغییر توپولوژی پیش فرض4-4شکل .117118.... دیاگرام توالی مربوط به تغییر توپولوژی پیش فرض5-4شکل 119................................... نمای کلی استقرار سامانه6-4شکل نسخه فعلی نرم افزار شبیه سازی ترافیک شبکهER شمای 7-4شکل

119.................................................................ملی اطالعات

ك

فهرست جدول ها

15.... نحوه تأثیر متغیرهای مستقل بر برون سپاری خدمات1-2جدول 35................................................. ارتباط ساختارها2-2جدول 52.......................................... جدول ارزش دهی یانگ3-2جدول 63............................... بررسی کلی سه روش ارزیابی4-2جدول 72.............. مقایسه روش های ارزیابی معماری نرم افزار5-2جدول 75............................... مخاطبین چرخه حیات محصول1-3جدول 86................................. نقش و توضیحات تیم ارزیاب2-3جدول 99........................ جدول ارزیابی ویژگی کیفی عملیاتی3-3جدول 99...................... جدول ارزیابی ویژگی قابلیت اطمینان4-3جدول 100............................... جدول ارزیابی ویژگی کاربری5-3جدول 100............................. جدول ارزیابی ویژگی کارآمدی6-3جدول 101.................... جدول ارزیابی ویژگی قابلیت نگهداری7-3جدول 101......................... جدول ارزیابی ویژگی قابلیت حمل8-3جدول 102................. جدول ارزیابی پرمحتواتر ویژگی عملیاتی9-3جدول 103..... جدول ارزیابی پرمحتواتر ویژگی قابلیت اطمینان10-3جدول 103................ جدول ارزیابی پرمحتواتر ویژگی کاربری11-3جدول 105.............. جدول ارزیابی پرمحتواتر ویژگی کارآمدی12-3جدول 105..... جدول ارزیابی پرمحتواتر ویژگی قابلیت نگهداری13-3جدول 106......... جدول ارزیابی پرمحتواتر ویژگی قابلیت حمل14-3جدول ISO9126............................106 جدول ارزیابی صفات 15-3جدول 121.......... جدول ارزیابی چرخه حیات محصول نمونه یک1-4جدول 122.......... جدول ارزیابی ویژگی کیفی عملیاتی نمونه یک2-4جدول 122 جدول ارزیابی ویژگی کیفی قابلیت اطمینان نمونه یک3-4جدول 123........... جدول ارزیابی ویژگی کیفی کاربری نمونه یک4-4جدول 123......... جدول ارزیابی ویژگی کیفی کارآمدی نمونه یک5-4جدول 124 جدول ارزیابی ویژگی کیفی قابلیت نگهداری نمونه یک6-4جدول 124.... جدول ارزیابی ویژگی کیفی قابلیت حمل نمونه یک7-4جدول 125........... جدول ارزیابی چرخه حیات محصول نمونه دو8-4جدول 126............ جدول ارزیابی ویژگی کیفی کارایی نمونه دو9-4جدول ..... جدول ارزیابی ویژگی کیفی قابلیت اطمینان نمونه دو10-4جدول

126127.......... جدول ارزیابی ویژگی کیفی کاربری نمونه دو11-4جدول 127........ جدول ارزیابی ویژگی کیفی کارآمدی نمونه دو12-4جدول ..... جدول ارزیابی ویژگی کیفی قابلیت نگهداری نمونه دو13-4جدول

128128... جدول ارزیابی ویژگی کیفی قابلیت حمل نمونه دو14-4جدول ... جدول مقایسه روش های مهم ارزیابی معماری نرم افزار1-5جدول

135

ل

فهرست کلمات اختصاری

AD Architectural DesignAHP Analytical Hierarchy ProcessALMA Architecture Level Modifiability AnalysisATAM Architecture Trade-off Analysis MethodCBAM Cost Benefit Analysis MethodERD Entity Relationship DiagramESA European Space AgencyIA Information ArchitectureIEC International Electrotechnical CommissionIEEE Institute of Electrical and Electronics EngineersISO International Organization for StandardizationSA Software ArchitectureSAAM Software Architecture Analysis MethodSEI Software Engineering Institute

1.فصل اول: مقدمه

بهبود روش ارزیابی معماری نرم افزار... مقدمه: اول فصل

مقدمه-1-1

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

این پیشرفت ها قرارگرفته اند. در این میان نرم افزارهای بزرگی در حال تولید هستند که این نرم افزارها نیاز به مدیریت، سمت وسو دادن آن ها

به سوی بهتر و بهینه شدن است. نگهداری و توسعه سیستم های امروزی بسیار پیچیده شده اند و این

پیچیدگی دو دلیل عمده دارند: یکی پیچیدگی ذاتی نرم افزار و دوم غیرقابل کنترل بودن عوامل تولیدکننده نرم افزار. یکی از بهترین راه های

]مدیریت و مقابله با پیچیدگی نرم افزار استفاده از معماری نرم افزار است1,2].

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

. به بیان دیگر یک[2]است، که مؤلفه ها و ارتباطات آن ها را توضیح می دهد توصیف مجرد از پیاده سازی سیستم های نرم افزاری را نشان می دهد. در

حالت کلی تمرکز معماری در نقطه ای بعد از تحلیل و قبل از طراحی.[3]است

برون سپاری در بسیاری از شرکت های بزرگ امروزه در مراحل تولید قسمت هایی از محصوالت شرکت یا مرتبط با آن ها انجام می شود. در

شرکت های نرم افزاری نیز بعضی از قسمت های تولید سیستم برون سپاری می شود. معماری که از دید برون سپاری مورد استفاده و بررسی قرار

می گیرد معموال خیلی کالن تر از معماری نرم افزاری می باشد که موردبحثدر کارهای داخلی تولید نرم افزاری است.

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

کارها، شتاب تحوالت محیطی، عدم اطمینان به آینده، افزایش هزینه ها، بزرگ شدن برخی از سازمان ها )به ویژه در بخش عمومی( و نیز

محدودیت های قانونی سبب شده است تا سازمان ها در الگوهای مدیریتی خود تجدیدنظر کرده و برای دستیابی به مزیت های رقابتی در دنیای کنونی کسب وکار، به استراتژی های جدیدی روی آوردند. یکی از این استراتژی ها،

تمرکز بر شایستگی های اصلی و واگذاری بسیاری از فعالیت ها به منابع خارج از سازمان )برون سپاری( است. بر این اساس، به منظور فراهم

2

بهبود روش ارزیابی معماری نرم افزار... مقدمه: اول فصل

کردن امکان پاسخ گویی کارا، با تأمین سطح خدمت مطلوب به مشتریان و توانمند شدن بنگاه ها در واکنش به تقاضا های متنوع امروزی، استراتژی

برون سپاری به عنوان ابزاری کارآمد )اما با ریسک های بالقوه( توسط.[4]بسیاری از سازمان های پیشرو به کار گرفته شده است

چیست؟1برون سپاریدر لغت به معنی دستیابی به سود از طریق منابع خارجی است. ازلحاظ مفهومی برون سپاری عبارت است از یک تصمیم تجاریت

آگاهانه و مبتنی بر تفکر برای انتقال )واگذاری( کار داخلی به یک.[5]تأمین کننده خارجی

3سپاری برون مرزی و برون2سپاری درون مرزیسپاری به دو شکل برونبرون

.[6]انجام می شود در پایان نامه خود در مورد برون سپاری نرم افزار به این نکته4هرمن

اشاره می کند که برون سپاری نرم افزار با اغلب انواع دیگر برون سپاری متفاوت است، به دلیل این که در این نوع برون سپاری شرکت سعی می کند

تا یک کار )پروژه( فکری پیچیده را به جای یک کار تکراری و معمولی که.[7]فرایند انجام آن به راحتی قابل فهم است را برون سپاری کند

،5 برون سپاری نرم افزار می تواند به معنای برون سپاری توسعه 10 و یا اجرای9، نگهداری8، آموزش7، مدیریت6طراحی و برنامه ریزی

.[8]نرم افزار باشد درباره ی مزایایی استفاده از رویکرد برون سپاری در شرکت ها، می توان

:[3,6]به موارد زیر اشاره نمود11تمرکز بر شایستگی های محوری

کاهش هزینه تمام شده محصولارتقاء کیفیت محصوالت و خدماتافزایش ظرفیت تولید و ارائه خدمات

1 Outsourcing

2 Domestic outsourcing

3 Offshore outsourcing4 Hermn

5 Development

6 Planning

7 Managing

8 Training

9 Maintenance

10 Operation11 Core Competencies

3

بهبود روش ارزیابی معماری نرم افزار... مقدمه: اول فصل

افزایش سرعت تحویل محصولحفظ منابع سازمان برای انجام فعالیت های کلیدی

سازمان ها این مزایا را به واسطه تمرکز بر توانایی های کلیدی خود و معماری نرم افزار ازاشتراک ریسک ها، تجربه ها و هزینه ها کسب می کنند.

دید برون سپاری به جز توجه به از کالس دیاگرام، نمودار فعالیت و ... بلکهیک توصیف بزرگ و کلی از معماری هست.

تصمیمات معماری مرتبط با صفات کیفیتی معماری بوده و تأثیر زیادی روی کیفیت سیستم های نرم افزاری می گذارند. در معماری نرم افزار یک

سری مدل های کیفیتی وجود دارند. مدل های که ویژگی یک معماری خوب را بیان می کنند و باعث تولید یک سیستم باکیفیت باال می شوند و در هر

مدل کیفیتی به بررسی یک سری از متریک های مهم و مشترک پرداخته شده]است که رعایت آن در نرم افزار باعث تولید محصولی باکیفیت می شود

1,2]. در این حیطه تولیدکنندگان نرم افزار به دنبال راه های هستند که بتوانند

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

.[2]ویژگی ها و صفات کیفیتی و میزان برآورده شدن آن ها است روش های ارزیابی معماری نرم افزار درواقع سعی دارند، خصوصیات

كیفیتی سیستمی كه بر اساس یك معماری قرار است تولید شود، را پیش بینی نمایند. درواقع پیش بینی رفتارهای زمان اجرا، و خصوصیات سیستم تولیدی بر اساس معماری آن سیستم است. این روش ها به

دسته های پرسشی، اندازه گیری و تركیبی تقسیم می شوند. در روش های پرسشی از پرسشنامه، چک لیست و سناریو برای بررسی معماری استفاده

می کند. در روش های اندازه گیری از معیارها، شبیه سازی و نتایج اجرای سیستم، استفاده شده و این روش ها معموال نتایج کمی ارائه می نمایند.

روش های تركیبی با استفاده از روش های پرسشی و اندازه گیری به دنبال.[2]ارائه روش هایی سریع تر و دقیق تر برای ارزیابی معماری می باشند

مسئلهبیان کلیات -1-2

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

تحقیقات از دیدگاه مدیریت برون سپاری باید طوری ساختار معماری نرم افزار و ارزیابی آن صورت بگیرد، که هم شرکت برون سپار)کارفرما( و

4

بهبود روش ارزیابی معماری نرم افزار... مقدمه: اول فصل

هم شرکت ذینفع معماری )مجری(، شرکت کننده در مناقصه ی برون سپارینرم افزار بتوانند از مزایای این تحقیق بهره مند شوند.

که در ابتدا با توجه به دیدگاه برون سپاری در این تحقیقات یک ساختار مشخص معماری نرم افزار ارائه می گردد و در ادامه کار به ارزیابی این

معماری پیشنهادی با بهبود یکی از روش های ارائه شده پرداخته شده است.

پرسش های تحقیق-1-3

در این تحقیق پرسش، چالش و نیازمندی های مطرح می شود، که در پایان این پایان نامه به این موارد پاسخ داده شده است. پرسش های تحقیق

در متن زیر مطرح شده است. تاكنون روش های بسياري براي ارزيابي معماري نرم افزار پيشنهاد و بكار

گرفته شده است. اما بيشتر اين روش ها امكان واضح و مستقيمي براي مقايسه دو معماري ارائه نمی دهند. همچنین صفات کیفی نرم افزار به صورت واضح مشخص نمی شوند. ارزیابی های معماری نرم افزار

به صورت کمی و دقیق بررسی نمی شوند بلکه تحلیلی و به صورت کیفیارزیابی می شوند.

هاي كيفي سيستممعماري نرم افزار نقش مهمي در دستيابي به ويژگي دارد و در اين حين ارزيابي معماري در خصوص ميزان دستيابي به نيازهاي

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

دستيابي به استعداد برآورده نمودن نيازهاي كيفي و شناخت ریسک های.[9]بالقوه است

اهداف تحقیق-1-4

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

نرم افزارهای بزرگ و پیچیده خیلی ساده و آسان تر شود، و داشتن مستندات و معماری نرم افزار باعث این امر می شود. با ارائه ساختار

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

همچنین استفاده از مدل های کیفیتی در معماری نرم افزار باعث

5

بهبود روش ارزیابی معماری نرم افزار... مقدمه: اول فصل

رضایت، امنیت و کاربرد بهتر نرم افزارهای ساخته شده می شود. با شناخت و بکار بردن صفات کیفیتی در معماری نرم افزار باعث این امر می شویم

که یک سطح قابل قبول از صفات کیفی در نرم افزار داشته باشیم. صفات کیفی در فصل آتی مفصل تر بحث خواهد شد. در این تحقیق برای رسیدن

به این امر جامعه عملISO9126به این هدف با استفاده از استاندارد پوشانده می شود.

با ساخت معماری مؤثر شما می توانید با شناسایی طراحی ریسک در . یکی از اهداف استفاده از[9]اوایل روند توسعه ریسک ها را کاهش دهید

معماری حامل اولیه از کیفیت های سیستم مانند عملکرد، اصالح و امنیت که هیچ کدام را می توان بدون یک چشم اندازه معماری یکی شده به دست

.[4]آورد در ارزیابی معماری نرم افزار می توان به این سؤاالت که در بند پایین

مطرح شده است، رسید و این سؤاالت بعضی اهداف و کاربردهای ارزیابیمعماری نرم افزار است.

چگونه می توان تصميمات معماري را اندازه گیری كرده و مفاهيم هزینه ها و سودها را استخراج نمود و آن ها را باهم مقايسه كرد؟

چگونه می توان صفات كيفيتي را تحليل نموده و با در نظر گرفتن هزینه ها و سودها مصالحه های موردنیاز را انجام داد؟

چگونه می توان ميزان احتمال هزينه و سود را مشخص نمود؟ موارد زیر بعضی از دیگر اهداف و کاربردهای ارزیابی معماری نرم افزار

هستند:.سهامداران به صورت كامال روشن و واضح معماري را می فهمند.ارتباط بين سهامداران افزايش می یابدمستندات معماري در جريان ارزيابي بهبود می یابد و در صورت لزوم

دوباره ايجاد می شود.به سازمان ها كمك می نماید تا يك برنامه ی از پيش ارزیابی شده براي

سرمایه گذاری های خود تهيه نمايند.می تواند اصولي را براي تصمیم گیری های منطقي درزمینه بكار گيري

هاي معماري تهيه نمايد.استراتژيامكان ارزيابي قابليت اصالح پذیری از جنبه های متفاوت ارزيابي

ريسك، پیش بینی هزينه و همچنين نگهداري سيستم و انتخابمعماري وجود دارد.

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

6

بهبود روش ارزیابی معماری نرم افزار... مقدمه: اول فصل

اهمیت و ضرورت انجام تحقیق -1-5

یکی از اهمیت ها و ضرورت انجام این تحقیق از دیدگاه مدیریت برون سپاری این است، نیاز امروزه شرکت های بزرگ برای بعضی از

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

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

حل مسائل مطرح شده بیان شد. یکی از اهمیت های انجام این تحقیق این است که برای ارزیابی معماری

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

پوشانده شده است. در معماری نرم افزار صفات کیفی بسیار قابل توجه هستند و ارضای

صفات کیفی معماری تضمین کننده پیروزی در پیاده سازی نرم افزار طراحی شده است. برای ارزیابی واضح و مشخص در معماری نرم افزار نیازمند آن هستیم که صفات کیفی به صورت واضح بیان شود در تحقیق

انجام شده این ضرورت موردبررسی قرار می گیرد.

جنبه نوآوری-1-6

در این تحقیق با ترکیب یک روش ارزیابی معماری نرم افزار با مدل صفات کیفیتی نرم افزار به بهبود آن روش پرداخته شده است. همچنین

ارزیابی های معماری نرم افزار موجود خیلی وابسته به گروه ارزیاب و به صورت تحلیل و کیفی است که در این تحقیق از وابستگی به گروه

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

بخشیده ایم. نوآوری دیگر این تحقیق آن است که در زمینه مدیریت و بهبود

برون سپاری یک ساختار مشخص برای ارائه معماری نرم افزار بیان شدهاست.

7

بهبود روش ارزیابی معماری نرم افزار... مقدمه: اول فصل

و نتایج مورد انتظار از تحقیقمتصورکاربردهای -1-7

کاربردهای قابل تصور از این تحقیق انجام شده می توان به آن اشاره کرد که در برون سپاری نرم افزارهای شرکت های بزرگ و شرکت های برون

سپار، همچنین شرکت های شرکت کننده در مناقصه می توان استفاده کاربردی انجام داد. برای ارزیابی یک معماری و چند معماری باهم می توان از کاربردهای متصور این تحقیق بیان کرد. نتایج مورد انتظار از تحقیق این

است که یک ساختار مشخص برای معماری نرم افزار ارائه داده شود. همچنین ارزیابی معماری نرم افزار همان طور که به صورت مفصل بیان شده

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

شود و صفات کیفی به صورت مشخص مورد ارزیابی قرار بگیرد.

روش انجام تحقیق-1-8

با استفاده از کتاب ها و مقاالت موردنیاز برای به دست آوردن اطالعات کافی را نسبت به کارهای انجام شده موردبررسی و مطالعه قرار گرفت.

در حیطه نوآوری مطالعات خودم را انجام داده تا روش های ارزیابی معماری نرم افزار موردبررسی گردید و از میان روش ها مناسب ترین روش

مورد مطالعه بیشتر قرار گرفت. سپس روش های مدلATAMآن ها، روش با توجه به مزیت هایISO9126صفات کیفیتی بررسی شد، که میان آن روش

که نسبت به دیگر روش های موجود برخوردار بود، انتخاب شد و برای بهبود در این تحقیق بکار گرفتهATAMدادن روش ارزیابی معماری نرم افزار

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

پایان نامهبخش هاي -1-9

این پایان نامه در پنج فصل انجام گرفته شد، فصل اول پایان نامه به بیان کلیات، اهداف؛ ضرورت و روش انجام آن پرداخته شده است. فصل دوم پایان نامه شامل موارد ادبیات تحقیق و تحقیقات پیشین است و در فصل

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

8

بهبود روش ارزیابی معماری نرم افزار... مقدمه: اول فصل

واقعی انجام گرفت. فصل پنجم که فصل آخر این پایان نامه است به نتیجه گیری روش پیشنهادی پرداخته ایم. آخرین بخش پایان نامه مراجع

مورداستفاده در این تحقیق قرار گرفته است.

9

2. فصل دوم: ادبیات تحقیق و

مروری بر تحقیقات انجام شده

مقدمه-2-1

این فصل فصل قبل مقدمه ی بر کلیات پایان نامه ارائه شد و در در به تعاریف اولیه موردنیاز در تحقیق و همچنین پیشینه تحقیق پرداخته

شده است.

تعاريف، اصول و مباني نظري-2-2

در ابتدا تعاریف برون سپاری و از دیدگاهی کلی به آن پرداخته ایم، سپس استانداردهای مهندسی نرم افزار را بیان کرده که مقدمه برای بیان معماری نرم افزار است. همچنین معماری نرم افزار و تصمیمات

معماری بیان می شود. بعدازآن تعریف ارزیابی معماری نرم افزار پرداختهشد و سپس متریک های و صفات کیفیتی نرم افزار بیان شده است.

برون سپاری چیست؟-2-3

]در لغت به معنی دستیابی به سود از طریق منابع خارجی می باشد5].

هرمن در پایان نامه خود در مورد برون سپاری نرم افزار به این نکته اشاره می کند که برون سپاری نرم افزار با اغلب انواع دیگر برون سپاری

متفاوت است، به دلیل این که در این نوع برون سپاری شرکت سعی می کند تا یک کار )پروژه( فکری پیچیده را به جای یک کار تکراری و

]معمولی که فرایند انجام آن به راحتی قابل فهم است را برون سپاری کند7].

، طراحی و1برون سپاری نرم افزار به معنای برون سپاری توسعه نرم افزار6 و یا اجرای5، نگهداری4، آموزش3، مدیریت2برنامه ریزی

.[8]می باشد

شمای کلی برون سپاری از گذشته تا حال-2-4

امروزه گرایش به استفاده از برون سپاری روند بیشتری پیداکرده، به ویژه کسب وکارهای مبتنی بر فناوری اطالعات. موتور جستجو مثل

1 Development

2 Planning

3 Managing

4 Training

5 Maintenance

6 Operation

درOutsourcingگوگل شاهد خوبی است؛ چون در هنگام جستجوی کلمه نیز همچون همزاد در اغلب نتایجInformation Technologyاینترنت، کلمه

جستجو به چشم می خورد. شکل زیر شمای کلی برون سپاری را از.[10]گذشته تا حال نمایش می دهد

شمای کلی برون سپاری1-2شکل

دالیل روی آوردن سازمان ها و شرکت ها به-2-5برون سپاریرویکرد

درباره ی استفاده از رویکرد برون سپاری در شرکت ها، دالیل و علل مختلفی بیان شده که به طورکلی می توان آن ها را در سه گروه

:[4]دسته بندی کرد دستیابی به توانمندی ها و امکانات در کالس جهانی: هدف آن ها،•

دستیابی به توانمندی های جهانی بدون پذیرش ریسک توسعه، درهمه ی زمینه های مرتبط است.

دسترسی مناسب به بهترین تجربیات و کسب مهارت های جدید.•تحصیل و کسب ایده های نوآورانه.• کسب وجهه ی تجاری مناسب به واسطه ی همکاری با پیمانکاران•

پیشرو.بهره گیری منابع داخلی برای مقاصد دیگر.•فقدان منابع در دسترس در داخل.•

سرعت بخشیدن به مزایای مهندسی مجدد.• شتاب در منحنی یادگیری در یک کسب وکار جدید، و یا برعکس،•

کاهش نیاز برای سرمایه گذاری و ریسک. کاهش ریسک از طریق شریک شدن با یک واحد دیگر در محیط•

تجاری نامطمئن.

گام های الزم برای شناسایی فعالیت های قابل-2-6برون سپاری

این سیستم مشخص می کند که کدام فعالیت ها قابل واگذاری بوده و کدام فعالیت ها را نباید برون سپاری کرد. بنابراین اصلی ترین سؤال

مدیریت سؤال مدیریت در این بخش پاسخ داده می شود. بدین منظور:[11]طی مراحل و انجام فعالیت های زیر الزامی است

:این قسمت اصلی ترین بخش نظامتدوین زنجیره ارزش برون سپاری محسوب شده و به همین دلیل از اهمیت و

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

ارزش آفرینی تعیین و طبقه بندی می شوند. الزم به ذکر است که در سازمان های بزرگ بهتر است در بخش های مجزا این

کارها به صورت همزمان انجام شود.:این مرحله به ترتیب ازتدوین فرآیندهای شرکت

فرآیندهایی که بیشترین ارزش را برای شرکت ایجاد می کنند آغاز می شود. هدف اصلی این مرحله، مستندسازی و کاهش

خطاهای مراجعه به حافظه افراد است. :در اینتعیین نقاط ضعف، قوت و مزیت رقابتی

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

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

دوره های زمانی مشخص موردبازنگری قرار خواهد گرفت.:اصلی ترینتدوین استراتژی های برون سپاری

خروجی های این بخش، تعیین سیاست های برون سپاری و تعیین

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

می شود.

چه نوع فعالیت هایی را می توان برون سپاری-2-7کرد؟

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

کرد. هر فعالیتی غیر از فعالیت های اصلی سازمان را می توان.[4]برون سپاری کرد

پاسخ به سؤاالت زیر قابلیت های کلیدی سازمان را مشخص خواهد کردهسته اصلی و علت وجودی سازمان چیست؟؟[4]مزیت های رقابتی سازمان چیست

چارچوبی برای تصمیم گیری برون سپاری-2-8خدمات

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

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

استفاده از برون سپاری نیست، بلکه تعیین خدمتی است که باید برون سپاری شود و این موضوع نیازمند آن است که راهبردهای

.[12]برون سپاری به روشنی معین شوند

[12]نحوه تأثیر متغیرهای مستقل بر برون سپاری خدمات1-2جدول

[13]گارتنرچرخه حیات برون سپاری به نظر آقای

راهبرد برون سپاری1مرحله :هم راستاییارزيابي سازمانيقابلیت های درون سازمانیبررسي بازارتصميمات ساخت يا خريد.تجزیه وتحلیل خطر

ارزيابي و انتخاب2مرحله :شناساييتوسعه ی ضوابطفرآيند انتخاب.فرصت های شراكت

توسعه ی قرارداد3مرحله :مدل نظارتانتخاب معيارهاروش های پرداختشرايط.پیش بینی تغييرات

مديريت برون سپاری4مرحله :

ارتباطتخمين بهره وریاهداف: رسيدن به اهداف کسب وکار، بهره وری، نوآوري و

كیفيت گذار.

رریسک های برون سپاری توسعه نرم افزا-2-9

داشتن تخصص در زمینه آی تی ،: 1توانمندی تأمین کننده فرض این است که.متخصصان کافی و سوابق خوب و موفق

.[14]این معیار تأثیر مثبتی در عملکرد پروژه داردمیزان آشنایی تأمین کننده از:2دانش تجاری تأمین کننده

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

.[14]داردحوزه پروژه: 3اطمینان مشتری از نیازمندی هایش

وابسته به نیازمندی های مشتری است، بنابراین مشتری باید دقیقا بداند که چه می خواهد. فرض این است که این معیار

.[14]تأثیر مثبتی در عملکرد پروژه دارداگر مشتری: 4داشتن دانش فناوری از سوی مشتری

همان طوری که دانش تجاری دارد، دانش فناوری و تکنولوژیک داشته باشد راحت تر می تواند با تأمین کننده تبادل اطالعات کند

بنابراین رابطه بین تأمین کننده و مشتری سلیس تر می شود. فرض این است که این معیار تأثیر مثبتی در عملکرد پروژه

.[14]داردخریدار و تأمین کننده: 5روشن و شفافیت بودن اهداف

ممکن است هرکدام اهداف متفاوتی را دنبال کنند که دلیل آن روشن و واضح نبودن اهداف است.بنابراین باید اهداف پروژه

1 Vendor Power2 Business Knowledge of Vendor.3 Client Requirement Certainty4 Technology Knowledge of Client.5 Goal Clarity

فرض این است که این مشخص و در اختیار طرفین قرار گیرد..[14]معیار تأثیر مثبتی در عملکرد پروژه دارد

باید تمام ذی نفعان اهداف یکسانی از: 1هم راستایی اهداف داشته باشند. یا هم راستایی اهداف تیم پروژه باSDOپروژه

اهداف سازمان مشتری. فرض این است که این معیار تأثیر.[14]مثبتی در عملکرد پروژه دارد

استانداردهای مهندسی نرم افزار-2-10

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

منتشر گردید که هم اکنون1984 در سال 2ESAآژانس فضای اروپا رعایت این استانداردهای برای کلیه نرم افزارهای آژانس فضایی اروپا

ضروری و اجباری است. این استانداردها تعریف موجز و کوتاهی از نحوه تولید نرم افزار

مطلوب و باکیفیت قابل قبول ارائه می دهند. استانداردهای مهندسی به سه بخش اصلی تقسیم می شوند. که در شکل زیرESAنرم افزار

.[15] نشان داده شده استESAاستانداردهای مهندسی نرم افزار

.ESA [15]استانداردهای مهندسی نرم افزار 1-2شکل

: استانداردها، توصیه ها و3بخش اول استانداردهای محصول1 Goal Alignment.2 European Space Agency3 Product Standards

رهنمودهای مربوط به محصول را شامل می شود. بخش دوم ، رویه های مورداستفاده در مدیریت یک پروژه1استانداردهای رویه

شامل خالصه ها،2نرم افزاری را تشریح می کند. بخش سوم پیوست ها.[15]جداول ، فرم ها و فهرستی از روش ها ضروری است

روش های استفاده شده در این مجموعه مشتمل بر سه گروه زیر است:روش های ضروریروش های توصیه شدهرهنمودها

- بخش استانداردهای محصول۲-10-1

این بخش کلیات چرخه حیات نرم افزار را تشریح می کند. محصوالت نرم افزاری الزم است با روش معینی طراحی و اجرا گردند. یک" مدل

چرخه حیات"، فعالیت های پروژه را در قالب مراحل مشخص سازمان دهی می کند و تعیین می نماید کدام یک از فعالیت ها باید در کدام

مرحله انجام گیرند. بر اساس این استاندارد، شش مرحله بایستی در:[15]چرخه حیات یک نرم افزار طی شود که عبارت اند از

مرحلهUR User Requirementsتعیین نیازهای کاربر : مرحلهSR Software Requirementsتعیین نیازهای نرم افزار : مرحلهAD Architectural Designطراحی معماری : مرحلهDD Detailed Designطراحی تفصیلی و تولید برنامه : مرحلهTR Transfer of the Softwareانتقال و واگذاری نرم افزار :

برای بهره برداری مرحلهOM Operation & Maintenanceبهره برداری و نگهداری:

این مراحل به عنوان مدل چرخه حیات است. چهار مرحله اول با یکبازبینی خاتمه می یابند.

...SRخروجی مرحله

سند نیازهای نرم افزارطرح آزمون سیستم طرح مدیریت پروژه برای مرحلهAD طرح مدیریت پیکربندی برای مرحلهAD

1 Procedure Standards2 Appendices

طرح وارسی و اعتبارسنجی برای مرحلهAD طرح تضمین کیفیت برای مرحلهAD

ADمرحله طراحی معماری - 2-10-2

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

تخصیص وظیفه مندی ها به مؤلفه های نرم افزار و تعیین گردش اطالعاتو عملیات بین آن ها به طرح معماری نرم افزار تغییر می یابد.

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

.[15]جهت تأیید فرضیات طرح اصلی ضروری باشدورودی ها:

SRکلیه خروجی های مرحله

.SR [15]نمای کلی مراحل 1-2شکل

شرح فعالیت ها:

ساختار مدل فیزیکی شامل:

تجزیه نرم افزار به مؤلفه ها، پیاده سازی الزامات غیر وظیفه مندی، معیارهای کیفیت طرح و بررسی مزیت های نسبی

مابین طرح های جایگزین

ساختار مدل معماری شامل: تعیین وظیفه مؤلفه ها، تعیین ساختمان داده ها، تعیین میزان

استفاده از منابع کامپیوتری و انتخاب زبان برنامه نویسیخروجی ها:سند طراحی معماریطرح های آزمون یکپارچگی طرح مدیریت پروژه برای مرحلهDD طرح مدیریت پیکربندی برای مرحلهDD طرح وارسی و اعتبارسنجی برای مرحلهDD طرح تضمین کیفیت برای مرحلهDD

مشخصESAدر توضیحات باال جایگاه معماری نرم افزار در استاندارد .[15]شده است

معماری نرم افزار-2-11

سیستم در باالترین سطحblueprintمعماری یک سیستم نرم افزاری انتزاع است که مولفه های اصلی و مهم ترین محاورات بین آنها را توصیف میکند. معماری نرم افزار یک برنامه یا سیستم محاسباتی،

ساختار یا ساختارهای آن سیستم محاسباتی است که خصوصیات قابل.[16]رویت از بیرون عناصر و ارتباطات بین آن ها را نشان می دهد

منظور از خصوصیات قابل رویت از بیرون فرضیاتی هستند که عناصر مختلف می توانند از عنصر دیگر داشته باشند از قبیل سرویس های فراهم شده، کارآیی، خصوصیات، رسیدگی به خطاها، منابع مشترک

استفاده شده. منظور از معماری عناصر نرم افزاری را نشان میدهد این است که معماری در بردارنده اطالعاتی پیرامون چگونگی اتصال عناصر

به یکدیگر است. این بدین معنی است که معماری عناصری را که در این.[16]ارتباطات نقشی ندارند، نادیده می گیرد

واسط ها از دو بخش عمومی و اختصاصی تقسیم میشوند که معماری مرتبط با بخش عمومی این تقسیم بندی است بخش اختصاصی بصورت

داخلی پیاده سازی می شوند که به معماری مربوط نمی شود. تعریف معماری مشخص می کند که سیستم ها می توانند بیش از یک ساختار

داشته باشند و این که یک ساختار به تنهایی نمی تواند یک معماری درنظر گرفته شود.

تعاریف دیگر معماری:.معماری طراحی سطح باالست.معماری ساختار کلی سیستم است،معماری ساختار مولفه های یک برنامه یا سیستم، ارتباط بین آن ها

و مفاهیم و راهنمای های کنترل کننده طراحی و تکامل آن ها درزمان است.

[16]معماری مولفه ها و اتصال ها است. معماري نرم افزار از موضوعات روز موردتوجه محققين و متخصصين

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

سيستم است به گونه ای كه صفات و ویژگی های رفتاري الزم، در آن مشخص باشد. معماري، يك ديدگاه واضح از كل سيستم به ما می دهد كه

براي كنترل و توسعه آن، الزم و ضروري است. واژه معماري داراي ريشه التين بوده و به معني استادي در ساختن است. معماري يك

سيستم مجموعه نقشه های فني از جنبه های مختلف آن سيستم را نشان.[1]می ده

درواقع يك توصيف سطح باال از سيستم بوده كه اهداف و عملكرد سيستم را براي طراحان و سازندگان و همچنين استفاده کنندگان آن بيان

هاي مشتري است. به بیان دیگرداشته و نشان دهنده مطابقت با نيازمندي معماري يك توصيف مجرد از پیاده سازی سيستم نرم افزاري را نشان

می دهد.

در حالت كلي تمركز معماري در نقطه ای بعد از تحليل و قبل از طراحي است، و از طريق تجزيه مدل تحليلي به زیرسیستم ها و

واسطه های آن ها و درنهایت تعيين قسمت های اصلي و عينيت بخشيدن به فرآيندهاي سيستم مشخص می شود. درواقع معماري يك طراحي سطح باال از نرم افزار موردنظر بوده كه نكات بیان شده در آن اثرات اساسي در كليت سيستم می گذارد. جزئياتي كه فقط مربوط به يك

قسمت از سيستم می شود، در طراحی های سطح پائين تر بيان می گردد. به طورکلی به هر معماري يك سيستم می توان گفت طراحي، ولي هر

. [2]طراحي را نمی توان معماري ناميد مسئله1معماري اولين مرحله تبديل سيستم بیان شده توسط ذينفعان

به توصيفي است كه در آن عملكرد عناصر تكنيكي سيستم مشخص شده باشد همان گونه كه در شكل زیر نشان داده شده يك نمونه كاري

3 فرآيند تبديل و سپس با پااليش2بیان شده توسط كاربر به نمودار تواليو دقیق تر نمودن آن اين نمودار در سطح معماري سيستم بيان می شود.

.[1]نرم افزارهاي كاربر به معماري مراحل تبديل نيازمندي1-2شکل

1 Stockholder2 Sequence Diagrams

3 Refinement

تصميماتي كه از دید کلی سيستم اتخاذشده و دامنه وسيعي را در برمی گیرند، تصميمات معماري محسوب می شوند. ولي تصميماتي كه در

سطح محدودي گرفته می شوند و ديد محلي دارند، تصميمات معماري محسوب نمی گردند. اين دسته بندی به ما اجازه می دهد كه بين طراحي و

پیاده سازی، و تصميمات معماري تفاوت قائل شويم. تصميمات معماري عناصر ساختاري و كليدي سيستم، و همچنين صفات قابل رؤیت آن ها از

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

.[17]موردنظر، هرکدام يك تصميم معماري هستند تعريف دقيق و يكتائي براي معماري نرم افزار ارائه نگرديده است كه اين خود يكي از مشکالت اصلي بر سر تحقيقات در اين زمينه است در

تعريف ذکرشده است. تعدادي از تعاريف100بعضي منابع بيش از معروف تر در ذيل بیان شده است:

معماري نرم افزار مجموعه ای از اجزاء معماري )طراحي( است- دسته اند. اجزاء3كه شكل خاصي دارند. اين اجزاء معماري

.3، اجزاء اتصالی2، اجزاء داده ای1پردازشي معماري نرم افزار مجموعه ای است از مؤلفه ها و اتصال دهنده ها به-

همراه توصيف تعامالت بين آن ها. معماري نرم افزار براي يك برنامه يا سيستم محاسباتي، ساختار يا-

ساختارهاي آن سيستم است كه شامل مؤلفه های نرم افزاري،خصوصيات بارز خارجي آن مؤلفه ها و ارتباطات ميان آن ها است.

سازمان دهی اساسي يك سيستم كه شامل مؤلفه ها، ارتباط هر- يك از آن ها با يكديگر و محيط، و اصول حاكم بر طراحي و تكامل

آن ها.

اجزاء معماري نرم افزار به صورت مفهومي به Garlan و Shawبر طبق نظر موارد ذيل طبقه بندی می شود:

مؤلفه: يك موجوديت محاسباتيمتصل کننده: يك اثر متقابل و تعامل بين مؤلفه هاواسط: يك نقطه تعامل بين مؤلفه ها و متصل کننده ها يا محیط های

خارجي درواقع می توان گفت كه معماري نرم افزار، بخش های اصلي

نرم افزار را در قالب مؤلفه ها شناسايي می کند، اما به اجزاء دروني و1 Processing Elements

2 Data Elements3 Connecting Elements

ساختمان داده های خود مؤلفه ها نمی پردازد. معماري عالوه بر ساختار، به رفتار سيستم نيز نگاه می کند. معماري در نرم افزار به دنبال تحليل

هاي كليدي كه در نظرهاي كليدي است معموال ويژگييكسري ويژگي می گیریم، جدا از نيازهاي وظيفه مندي است و بيشتر در نيازهاي غیر

وظیفه مندي خالصه می شود. درواقع می توان گفت كه معماري نرم افزار،رابطه ای بين ساختار و رفتار مؤلفه ها ايجاد می نماید.

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

.[2]هزینه ها و زیبایی شناختی نيز موردتوجه است معماري نرم افزار يك سيستم را می توان ديد مشترك همه صاحبان

سهام و توسعه دهندگان دخيل در يك سيستم نرم افزاري دانست كه همگي روي آن اتفاق نظر دارند يا حداقل آن را پذیرفته اند. معماري

نرم افزار يك سيستم، اطالعات زير را در مورد آن سيستم ارائه می دهد:سازمان دهی سيستم نرم افزاري•عناصر ساختاري و واسطه های آن ها•تركيب عناصر ساختاري و رفتاري درون زیرسیستم ها•

معماري نرم افزار مرحله ای از فرآيند مهندسي است كه نمی توان به صورت دقيق مشخص كرد كه در كدام نقطه از اين فرآيند تعبیه شده است، ولي در حالت كلي تمركز معماري در نقطه های بعد از تحليل و قبل از طراحي است و از طريق تجزیه مدل تحليلي به زیرسیستم ها،

واسط های آن ها، وابستگي ميان آن ها و درنهایت تعيين رده های كليدي و واقعيت بخشيدن به موارد كاربري حياتي انجام می شود. در ده سال

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

2].

.[2]مراحل تولید معماری نرم افزار 2-2شکل

- تصميمات معماري۲-۱1-۱

تصميماتي كه بايد از ديد كلي سيستم اتخاذ شوند و دامنه وسيعي را در بر می گيرند، تصميمات معماري محسوب می شوند، ولي تصميماتي

كه در سطح محدودي گرفته می شوند و ديد محلي دارند، تصميم معماري محسوب نمی شوند. اين دسته بندی به ما اجازه می دهد كه بين طراحي و

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

انتخاب تعداد مؤلفه ها، انتخاب مؤلفه های قابل رؤیت از بيرون، صفات كيفيتي موردنظر، هرکدام يك تصميم معماري هستند. تصميمات معماري

.[18]در همان مرحله اوليه معماري اتفاق می افتد به صورت خالصه معماري نرم افزار يعني بيان ساختار يا ساختارهایی

هاي قابل رؤیت از خارج ايناز سيستم كه مؤلفه های نرم افزاري، و ويژگي مؤلفه ها و روابط بين آن ها را نشان می دهد. به عبارت دیگر معماري

نرم افزار عبارت است از ساختار مؤلفه ها در يك سيستم، رابطه داخلي آن ها و اصول و خطوط راهنمائي كه طراحي و ارزيابي سيستم در طي

زمان را امکان پذیر می کند.

اگر بخواهيم اهميت معماري نرم افزار را از منظر فني موردبررسی قراردهيم می توان سه دليل در اين رابطه بيان نمود:

الف: معماري به عنوان وسیله ای جهت ارتباط ميان ذينفعان سيستم: معماري نرم افزار يك سيستم را می توان ديد مشترك همه ذينفعان سيستم دانست. درصورتی که همه يا اكثر آن ها روي آن اتفاق نظر

داشته باشند، می توان آن را به عنوان پایه ای براي درك متقابل، مشورت و رايزني و همچنين عامل ارتباط ميان آن ها قرارداد.

همان طور كه قبال هم بيان شد درواقع معماري یک زبان مشترك ميان تمام آن ها برقرار می کند كه براي همه قابل فهم بوده و به درك

صحیح تر سيستم كمك می کند. ب: امكان تصميمات زودهنگام طراحي: معماري نرم افزار شامل

هاي سطح باال و زودهنگام در طراحي1تصميمات و مصالحه های است، كه منجر به توليد سيستم نرم افزاري می شود و صفات آن را

تعيين می کند. مطالعات در اين زمينه نشان می دهد كه هزينه تصحيح ها يا در فازيك خطاي کشف شده در خالل فاز شناخت نيازمندي

معماري بسيار كمتر از هزينه تصحيح همان خطا در حالتي است كهخطا در فاز آزمايش كشف شود.

ج: امكان قابليت استفاده مجدد در معماري: گفتيم كه معماري طراحي سطح باال و تشخيص مؤلفه ها و نحوه ساختار آن ها در سيستم را مشخص می نماید. لذا اين امكان وجود دارد كه در

ها و خصوصيات، بتوان مؤلفه هایسيستمي مشابه، با همان نيازمندي ایجادشده را مورداستفاده مجدد قرارداد و همان طور كه می دانیم اين

موضوع در فرآيند توليد و توسعه سیستم های نرم افزاري از اهميت.[2]خاصي برخوردار است

معماری در چرخه حیات- 2-11-2

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

.[17]نشان داده شده است1 Trade-off

[17]چرخه حیات تحویل تکاملی1-2شکل

الگوی معماری مدل مرجع معماری مرجع-2-12

یک الگو معماری توصیفی توصیفی از عناصر و انواع ارتباط بین آن ها به همراه مجموعه ای از اجبارها در مورد چگونگی استفاده از آن هاست.

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

سرویس گیرنده. یک مدل مرجع، تقسیم وظیفه مندی به همراه جریان داده بین

بخش ها است. یک مدل مرجع تجزیه استاندارد یک مساله مشخص بهبخش هایی است که به صورت اشتراکی مساله را حل می کنند.

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

مرجع وظیفه مندی را تقسیم می کند معماری مرجع یک نگاشتی از آن وظیفه مندی به بخش های تجزیه شده سیستم است. نگاشت می تواند یک

.[19]به یک باشد) امام ضروری ندارد(

یک عنصر نرم افزاری می تواند قسمتی از یک وظیفه یا چندین وظیفه راپیاده سازی کند.

مدل های مرجع، الگوهای معماری و معماری های مرجع، معماری نیستند. آن ها مفاهیم مفیدی هستند که عناصر یک معماری را به دست]می آورند. هر کدام از این مفاهیم نتیجه تصمیمات اولیه طراحی هستند

19].

.[19]یارتباط بین مدل مرجع، الگو معماری، معماری مرجع و معمار1-2شکل

- نمونه ای از معماری های مطرح۲-۱2-۱

Main Frameمعماری •

File Serverمعماری •

Client/Serverمعماری •

Two-Tierمعماری •

Three-Tierمعماری •

Service Oriented Architecture (SOA)معماری سرویس گرا •

Enterprise Resource Planning ERPبرنامه ریزی منابع انسانی •

.[20]معماری نرم افزار شیءگرا•

دیدگاه ها و ساختارهای معماری-2-13

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

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

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

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

نرم افزاری متمرکز شویم. در ارائه معماری از دو مفهوم مرتبط با هم به نام های دیدگاه و ساختار استفاده می شود که تعریف هر یک به شرح زیر

است: دیدگاه- نمایشی از یک مجموعهای منسجم از عناصر معماری استکه به وسیله ذینفعان سیستم )معماری( ایجاد شده و خوانده می شود. ساختار- مجموعه ای از عناصر و ارتباط بین آن هاست. در یک نوع

. [16]ساختار فقط عناصر متعلق به آن نوع ساختار لحاظ می شود

ساختارهای ماژول-2-14

عناصر در این ساختار ماژول های سیستم هستند که واحدهایی از پیاده سازی می باشند. ماژول ها یک روش مبتنی بر کد برای بررسی

سیستم ارائه می کنند و بر بخش های وظیفه مندی سیستم تاکید دارند. این نوع ساختار تاکید کمتری بر روی چگونگی آشکار شدن نتایج در زمان

اجرا دارد.ساختار ماژول اجازه پاسخ دهی به سواالتی را می دهد که عبارتند از:

وظیفه مندی اصلی تخصیص داده شده به هر یک از ماژول ها چیست؟

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

؟[16]سازی با ماژول های دیگر ارتباط دارند

ساختار مولفه و اتصال-2-15

عناصر در این ساختار مولفه های زمان اجرا و اتصال ها هستند.

]ساختار مولفه و اتصال به پاسخ گویی سواالتی از قبیل زیر می باشد 16]:مولفه های اجرای اصلی کدام هستند و چگونه تعامل برقرار

می کنند؟مخزن داده مشترک اصلی چه چیزی است؟

کدام بخش از سیستم تکرار شده است؟چگونه داده ها در سرتاسر سیستم حرکت می کنند؟کدام بخش های سیستم می توانند به صورت موازی اجرا شوند؟چگونه می توان ساختار سیستم را زمانی که در حال اجرا است

تغییر داد؟

ساختارهای تخصیص-2-16

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

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

فایل هایی ذخیره شده اند؟چه عناصر نرم افزاری به چه تیم های توسعه تخصیص داده

شده اند؟

[19]ساختارهای معماری نرم افزار1-2شکل

ساختارهای معماری نرم افزار-2-17

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

به توضیح مفصلتر پرداخته شده است. 1ساختارهای ماژول

2تجزیه 3استفاده

o4الیه ای

5کالس یا تعمیم

6ساختارهای مولفه و اتصال

7فرآیند یا فرآیندهای ارتباطی

8هم زمانی

1 Module2 Decomposition3 Uses4 Layered5 Class6 Component and connector7 Process8 Concurrency

1مخزن یا داده های مشترک

2سرویس گیرنده-سرویس دهنده

3ساختارهای تخصیص

4استقرار

5پیاده سازی

[19]6انتساب کار.

ماژول- 2-17-1

ساختار های مبتنی بر ماژول به شرح زیر هستند: تجزیه: واحدها، ماژول های هستند که بوسیله رابطه " یک زیر ماژول است از "به ماژول های کوچک تر تقسیم می شوند که این موضوع نشان

می دهد چگونه ماژول های بزرگ تر به ماژول های کوچک تر تقسیممی شوند.

ساختار تجزیه قابلیت اصالح بزرگی در سیستم به وسیله تضمین این است که احتماال تغییرات در داخل یک تعداد ماژول خواهد بود، ایجاد

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

استفاده: واحدهای این ساختار ماژول ها، رویه ها و منابع رابط های ماژول ها هستند. واحدها از طریق رابطه " استفاده می کند از " به

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

را به سیستم اضافه کند که این امر یک توسعه تدریجی را امکان پذیرمی کند.

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

1 Shared Data2 Client-Server3 Allocation4 Deployment5 Implementation6 Work Assignment

انتزاعی )ماشین مجازی( طراحی می شوند که این امر باعث می شودمشخصات الیه پایین از دید الیه باالتر پنهان باشد

کالس یا تعمیم: واحدهای این ساختار کالس ها هستند که توسط رابطه " ارث بری می کند از " یا " یک نمونه ای است از" با یکدیگر ارتباط

برقرار می کنند. این نوع ساختار از استدالل درباره رفتارهای مشترک و مشخص کردن تفاوت ها بین کالس های مختلف حمایت می کند. همچنین

ساختار کالس اجازه می دهد که درباره استفاده مجدد و افزایش تدریجی.[16]تصمیم گیری شود

مولفه و اتصال- 2-17-2

ساختارهای مبتنی بر مولفه و اتصال به شرح زیر هستند: فرآیند یا فرآیندهای ارتباطی: واحدها، فرآیندها یا نخ ها هستند که به

وسیله ارتباط، هم زمانی و یا عملیات انحصاری به واحدهای دیگر متصل می شوند. این نوع ساختار با جنبه های اجرایی سیستم در ارتباط

می باشد. ارتباط در این نوع ساختار "الحاق"است که نشان می دهد چگونه اتصال ها و مولفه ها یکدیگر را کنترل می کنند، ساختار فرآیند در

زمینه بررسی )اجرا( کارآیی و قابلیت دسترسی یک سیستم مورداستفاده قرار می گیرد.

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

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

جداگانه درفرآیند طراحی تخصیص داده شود. ساختار هم زمانی باعثمی شود که نیازمندی های اجرای هم زمانی شناسایی شوند.

مخزن یا داده های مشترک: این ساختار دربرگیرنده مولفه ها و هایی است که برای ایجاد، ذخیره و دسترسی به داده های مانا مورداتصال

استفاده قرار می گیرند. این ساختار نشان می دهند که داده ها چگونه تولید و مصرف می شوند و هم چنین به تضمین کارآیی و یکپارچگی داده ها

کمک می کند.سرویس گیرنده-سرویس دهنده: برای سیستم های سرویس گیرنده-

ها سرویس دهنده مناسب است. واحدها در این ساختار سرویس گیرنده و سرویس دهنده ها هستند و اتصال ها قراردادهایی هستند که این واحدها

از آن برای برقراری ارتباط و انجام کار سیستم استفاده می کنند. کاربرد این ساختار در جداسازی دغدغه ها برای توزیع پذیری فیزیکی و تنظیم بار

.[16]کاری سیستم است

تخصیص- 2-17-3

ساختارهای مبتنی بر تخصیص به شرح زیر هستند: استقرار: عناصر ساختار استقرار موجودیت های نرم افزاری،

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

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

ساختار به مهندس سیستم کمک می کند که پیرامون کارآیی، یکپارچگی داده ها، قابلیت دسترس پذیری و امنیت سیستم استدالل های الزم انجام

دهد. ساختار استقرار یکی از ساختارهای جالب در مورد سیستم هایتوزیع شده و موازی است.

پیاده سازی: این ساختار نشان می دهد چگونه عناصر نرم افزاری به ساختارهای فایل در طی فرآیند توسعه، به منظور فراهم آوردن

یکپارچگی یا محیط کنترل پیکربندی سیستم نگاشت شده اند. این ساختاربرای مدیریت فعالیت های توسعه و ساخت فرآیندها، حیاتی است.

انتساب کار: این ساختار برای تخصیص فعالیت های پیاده سازی و یکپارچگی به تیم های توسعه مناسب است. ساختار انتساب کار به

عملکرد افراد کمک می کند و حتی مشخص می کند که تجارب مورد نیاز هر تیم چه چیزی باید باشد تا بتواند کار را خوب تحویل دهد. هم چنین

برای پروژه های بزرگ توزیع شده که کار به تیم های مختلف واگذار.[16]می شود این ساختار کاربرد مناسبی دارد

.[19]ارتباط ساختارها1-2جدول

هر کدام از ساختارهای عنوان شده، دیدهای مختلفی از سیستم ارائه می کنند و هر کدام در جایگاه خود مهم و مفید هستند. این ساختارها

مستقل نیستند زیرا عناصر هر یک به عناصر دیگری وابسته است. بعنوان مثال یک ماژول در ساختار تجزیه ممکن است به یک یا چند ساختار

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

نکته مهم این است که در تمام سیستم ها نیاز نیست که از کلیه ساختارها استفاده شود برای سیستم های کوچک انتخاب یک یا چند

ساختار میتواند جوابگو باشد، زیرا این ساختارها می توانند در بردارندهساختارهای دیگر نیز باشند.

بنابراین انتخاب نوع و تعداد ساختارهای موجود در یک معماری رابطه.[16]مستقیم با ماهیت سیستم نرم افزاری و حجم و گستردگی آن دارد

سبک معماری-2-18

سبک معماری یک نوع ابر مدل جهت تعیین مجموعه ای از اجزا و ارتباطات میان آن ها برای مشخص نمودن سیستمی بر مبنای آن سبک

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

.[20]ترکیب شوند : به مجموعه ای از الگوها و قوانینی برای ساخت وزبان الگو

سبک ها. سازماندهی الگوهای جدید از روی الگوهای اولیه گفته می شود بیشتر مواقع یک روش. بیشتر به زبان الگوها شباهت دارن تا به الگوها

الگو جزئی. طراحی را که می باید سبک یا الگو نامیده شود توافق ندارد سبک ها در. و دقیق تر یک راه حل را برای مسئله طراحی پیشنهاد میکند

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

نوع اتصاالت میان این اجزا را به همراه مجموعه قوانینی برای ترکیب.[20]اجزا و اتصاالت با یکدیگر تعریف می کند

سبک معماری نرم افزار مجموعه ای است متشکل از:اجزااتصاالتقوانینمکانیزم تعامل

انواع سبک های معماری- 2-18-1

در ادامه با چند سبک بطور خالصه آشنا می شویم و به بررسیساختار آن می پردازیم.

2003سبک معماری کمنتس با توجه به نوع دید، یک دسته بندی را ارائه2003کلمنتس در سال

نموده است. مالک دسته بندی در برخی از آن ها موضوع بوده و سبک ها بر اساس موضوع و نوع آن ها در گروه های مختلف قرار گرفته بودند.

مالک دیگری که می توان بر اساس آن دسته بندی سبک ها را مورد.[20]بررسی قرار داد مفهوم دید معماری است

Module View TypeoDecompositionoUsesoGeneralization

oLayeredComponent and Connector (C&C) View Type

oPipe-and-FilteroShared-DataoPublish-Subscribe (Blackboard)oClient-ServeroPeer-to-PeeroCommunicating-Processes

Allocation View TypeoDeploymentoImplementationoWork Assignment

سبک متمرکز بر روی داده هدف این سبک معماری، رسیدن به کیفیت برقراری یکپارچگی و

یا قابلیت تجمیع پذیری می باشد. کلمه متمرکز روی داده اشاره به سیستم های دارد که در آن ها دستیابی و بهنگام سازی داده ها،

.[20]توصیفی مناسب از عملکرد سیستم است

.[20]سبک متمرکز بر روی داده 1-2شکل

سبک جریان داده هدف در این سبک رسیدن به ویژگی استفاده مجدد و اصالح

پذیری است. در این سبک سیستم به این دید نگاه می شود که یک سری از تبدیالت روی قطعاتی متوالی از داده ها ورودی انجام

می شود..Batch/Sequential و Pipe&Filterاین سبک شامل دو زیر سبک است:

تاکید روی تبدیل و پردازش تدریجی روی داده به وسیلهPipe&Filterسبک

مولفه های متوالی دارد. این سبک یک سبک متداول در خانواده سیستم.[20] استUNIXعامل

.Pipe&Filter [20]سبک جریان داده - 2-2شکل

گام های پردازش یا همان مولفه ها،Batch/Sequentialدر سبک برنامه های مستقلی هستند و فرض بر این است که هر گام قبل از

شروع گام بعد، اجرایش به تکامل می رسد.

.Batch/Sequential [20]سبک جریان داده - 3-2شکل

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

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

در این شکل سه نوع داده موجود هستندبرنامه در حال تفسیر شدنداده های برنامهحاالت داخلی مفسر

موتور تفسیر دستوری را از برنامه در حال تفسیر انتخاب می کند،

حاالت داخلی خود را بهنگام میکند و بنابر دستور، قاعدتا داده های.[20]برنامه را به هنگام می سازد

.[20]سبک ماشین مجازی4-2شکل

سبک برنامه اصلی و زیر روال در این سبک، هدف قطعه قطعه کردن برنامه به قطعات کوچکتر،

.[20]برای رسیدن به اصالح پذیری باالتر است

.[20]سبک برنامه اصلی و زیر روال5-2شکل

سبک سیستم های شیءگرا این سبک، نسخه مدرنی از سبک های فراخوانی بازگشت است.

.[20]قابلیت استفاده مجدد و اصالح پذیری را باال می برد

.[20]سبک سیستم های شیءگرا6-2شکل

سبک سیستم های الیه ای این سبک زمانی استفاده می شوند که مساله کارایی در زمان اجرا

.[20]مورد نظر باشد

.[20]سبک سیستم های الیه ای7-2شکل

ارزیابی معماری نرم افزار-2-19

روش های ارزیابی معماری نرم افزار به سه دسته پرسشی اندازه گیری و ترکیبی تقسیم می شوند که در روش های پرسشی از

پرسشنامه، چک لیست و سناریو برای بررسی معماری استفاده می کند و

در روش های اندازه گیری از معیارها، شبیه سازی و نتایج اجرای سیستم، استفاده شده و این روش ها معموال نتایج کمی ارائه می نمایند. روش های

ترکیبی با استفاده از پرسشی و اندازه گیری به دنبال ارائه روش های.[2,17]سریع تر و دقیق تر برای ارزیابی معماری نرم افزار می باشند

ارزیابی معماری ممكن است در زمان ها مختلفی از چرخه حیات نرم افزار اتفاق بیفتد. بر این اساس معموال ارزیابی به دودسته ارزیابی

زود و ارزیابی دیر تقسیم می شوند. زمانی كه ارزیابی قبل از پیاده سازی و با اهدافی مثل امکان سنجی پیاده سازی یك معماری یا انتخاب از بین

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

.[1,19]سیستم های جدید انجام شود

ویژگی های کیفیتی معماری نرم افزار-2-20

هاي كيفيتي، همان نیازمندی های غیر وظیفه مندي سيستمويژگي-می باشند كه تا حد زيادي تعیین کننده سبك معماري نيز می باشند. ويژگي

هاي غير وظيفه مندي هستند،هاي كيفيتي كه درواقع همان نيازمندي بايستي در نرم افزار به صورت يكسري پارامترهاي فني، در نظر گرفته

ها را به صورت قابل فهم برايشوند و براي همين معمار بايد اين ويژگي ساير صاحبان سهام ليست نمايد تا آنان در مورد اين ليست امكان

اظهارنظر داشته باشند و درنهایت سيستم داراي كيفيت موردنظر باشد. معماري اولين قدم توليد نرم افزار بوده كه نيازهاي كيفيتي در آن

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

راحت تر قابل ردیابی خواهند بود.

هاي كيفيتي ازنظر ارزيابي به دودسته تقسيمويژگيمی شوند:

اين صفات نشانصفات كيفيتي قابل مشاهده در زمان اجرا: می دهند كه در طول مدت اجرا، يك سيستم چقدر خوب می تواند

هاي رفتاري خودش را تأمین كند. يعني به لحاظ رفتاري معيننيازمندي می کند كه آيا سيستم نتايج را برآورده می کند و آيا اين نتايج را در زمان درست برآورده می سازد يا خير؟ درواقع اين صفات كيفيتي مربوط به

هاي قابل مشاهده در حين اجرا هستند. يعني نرم افزار را بايد اجراويژگي هايي فراهمكرد تا مشخص شود كه در اثر اجراي آن چنين ويژگي

می شوند يا خير؟ مورد می باشند:5صفات كيفتي قابل مشاهده در زمان اجرا

1كارايي

2امنيت 3در دسترس بودن

4قابليت عملكرد يا وظيفه مندي 5قابليت كاربرد و استفاده

1 Performance2 Security3 Availability4 Functionality5 Usability

اين صفاتصفات كيفيتي غیرقابل مشاهده در زمان اجرا: به گونه ای هستند كه با اجراي آن نمی توان تشخيص داد كه به آن

دست یافته ایم يا خير و به عبارت دیگر نمی توان آن را در زمان اجرا ديد و بايد بعدا ارزيابي شود. اين دسته از صفات نشان می دهند كه جمع آوری

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

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

مورد می باشند:5صفات كيفيتي غیرقابل مشاهده در زمان اجرا 6قابليت اصالح پذیری 7قابليت حمل 8قابليت تجميع پذيري 9قابليت استفاده مجدد 10قابليت آزمايش

البته هر دودسته صفات كيفيتي معرفی شده در باال، چه قابل مشاهده در زمان اجرا و چه غیرقابل مشاهده در زمان اجرا، مربوط به خود

سيستم و برنامه كاربردي می باشند و به آن ها صفات كيفيتي مرتبط با هاي كيفيتي مرتبط با حرفه همسيستم می گویند ولي يك سري ويژگي

داريم، كه آن ها نيز در معماري اثرگذار هستند، كه از آن جمله می توان بهمسائلي مانند قيمت تمام شده، زمان پايان و... اشاره كرد.

دو نكته در رابطه با صفات كيفيتي از اهميت زيادي برخوردار است:معماري براي تحقق بسياري از صفات كيفيتي مهم و بحراني

در سيستم است و اين کیفیت های موردنظر می بایستی در سطح معماري طراحي و ارزيابي شوند، يعني در سطح

ها هستند كه بايد مورد طراحي ومعماري يكسري از ويژگيارزيابي قرار گيرند.

برخي از اين صفات كيفي وابسته به معماري نيستند و تحقيق درزمینه ی دستيابي به اين کیفیت ها در معماري كار درستي نيست و نتيجه قابل استفاده ای ارائه نمی کند. به همين علت

ها در زمان معماري و طراحي قابلمی گوییم كه يكسري ويژگي6 Modifiability7 Portability8 Integritability9 Reusability10 Testability

ارزيابي هستند و براي بعضي از صفات كيفيتي معماري بايد معماري را اجرا نمود يعني آزمايش آن ها به زمان اجرای

معماري موكول می شود. بحث صفات كيفيتي در سیستم های پيچيده مطرح می شود و برآورده

كردن اين صفات به صورت مجرد امکان پذیر نيست، يعني بايد ابتدا مصاديقي روشن شود و بعد در چارچوب مصاديق ارزيابي را انجام دهيم و ببينيم كه به اين صفات رسیده ایم يا خير؟ اصوال رسيدن به يك كيفيت

بر روي كيفيت ديگر، تأثیرگذار است. مثال ممكن است وقتی که كارايي را باال ببريم، امنيت را پايين آوريم، يعني ممكن است كه همة صفات

كيفيتي را نتوانيم باهم برآورده سازيم. مثال فرض كنيد امنيت و تحمل خطا به صورت انحصاري قابل دستیابی باشند ولي اگر توأم باهم بخواهيم

آن ها را داشته باشيم بايد مصالحه انجام دهيم. يكي از مسائلي كه در هاي كيفيتي داريم اين است كه بايد اهلارتباط با بحث معماري و ويژگي

سازش باشيم، يعني همه صفات كيفيتي را ممكن است نتوانيم همزمان فراهم كنيم ولي بايد ببينيم كه کدام یک از اين شرايط براي ما حائز

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

.[2]قابليت استفاده مجدد داشته باشيم و...

توضیح کامل صفات کیفیتی-2-21

در این بخش به توضیح کامل تر صفات کیفیتی پرداخته می شود و به صورت مفصل تر صفات کیفیتی شرح داده شده است که در آخر این

بخش به شناخت کامل و درک مفهوم دقیق صفات کیفیتی می رسیم و از استفاده می شود.[2]منبع

كارايي- 2-21-1

كارايي مربوط به زمان پاسخ سيستم يا پاسخگو بودن سيستم است. درواقع می توان گفت كه كارايي به زمان موردنظر براي پاسخگويي سيستم به تعدادي از رخدادها در يك پريود زماني مربوط می شود.

( از طريق ميزان1كارايي را از دو روش می توان محاسبه كرد: ) ( تعداد رخدادهايي كه در واحد زمان2پاسخ گویی به يك رخداد خاص و )

مورد پاسخگويي قرار می گیرند. پس كارايي به ما می گوید كه به چه ميزان توانسته ایم زمان پاسخگويي را كم كنيم. اغلب اين ويژگي كيفي

را بوسيلة محاسبه مقدار زمان الزم براي اجراي كامل يك تراكنش،.[2]اندازه گیری می کنیم

چون ارتباط با سيستم بيشتر از خود محاسبات زمان می برد، درنتیجه كارايي نشان می دهد كه چقدر تعامالت بين اجزاي سيستم تدوین شده و به چه ميزان اين اجزاء شناسايي و تعبیه شده، تا زمان بااليي را به عنوان

زمان پرت براي سیستم ها و يا زير سیستم ها نداشته باشيم. ميزان تعامالتي كه در فراخواني توابع يا رویه ها و يا در همگام سازی فرآيندها يا

مکانیسم های ارتباطي ديگر وجود دارد، روي كارايي سيستم تأثير می گذارد و باعث می شود كه كارايي به عنوان تابعي از معماري مطرح

شود، پس كارايي را می توان در سطح معماري درك كرد و تحليل و مدل.[2]نمود

با نرخ ورودی ها و تقاضاي سرويس و اندازه صف ها و تأخيرهايي كه در زمان اجرا مشاهده می کنیم، می توانیم كارايي را ارزيابي نماييم.

به طورکلی كارايي يك سيستم را با ايجاد يك مدل تخميني صف شبیه سازی می کنیم. براي شبیه سازی كارايي سعي می کنیم كه ميزان

انتظار را براي هر كاري كه در سيستم است و براي هر مشتري كه وارد سيستم می شود، بررسي كنيم و با استفاده از يك تابع نرخ ورود و

همچنين توزيع تقاضاي سرويس بين پردازنده های مختلف و تخمين زمان پردازش و ميزان صف های تولیدشده براي هر پردازنده، ميزان كارايي را

.[2]محاسبه كنيم پس براي محاسبه كارايي بايد زمان پردازش هرکدام از تراکنش های

سيستم را تخمين بزنيم و بر اساس شبیه سازی، كارايي سيستم را مشخص نماييم، مثال مشخص كنيم كه اگر يك خادم به سيستم اضافه كنيم، به چه ميزان بر روي كارايي تأثير می گذارد، و آيا وجود يا عدم

وجود اين خادم اضافه بر روي كارايي تأثیر می گذارد يا خير؟ درمجموع می توان گفت كه كارايي يك فاكتور مهم و برنده در معماري است و

.[2]ارزش رسيدن به آن بسيار باال است

امنيت- 2-21-2

امنيت واحدي از سيستم است كه توانايي يك سيستم را براي مقاومت در برابر مسائل ناخواسته و تالش های غيرمجاز و همچنين امتناع

از سرويس درزمانی كه خود سيستم در حال ايجاد سرویس هایی براي كاربران است، نشان می دهد. امنيت را می توان از منظرهاي مختلف نگاه كرد. از منظر سیستم عامل، شبكه و بانك اطالعاتي، سخت افزار

و... و همچنين ازنظر عوامل انساني و مسائل فيزيكي، مثل آتش سوزی.[2]و دزدي و...

Spoogfingو DOSمسائلي كه به طور عمده در امنيت با آن روبه رو هستيم

است.DOSنتيج44ه س44رازير ش44دن درخواس44ت های ناخواس44ته زي44اد ب44ه :

سيستم اس44ت ك44ه سيس44تم را از پاس44خگويي ب44ه درخواس44ت های حقيقي ب44ازمی دارد، يع44ني آن ق44در به ط44ور غ44يرواقعي ك44ار تولي44د می کنیم كه باعث زيادي بار شدن سيس4تم ش44ده و خ44ود اين ك4ار باعث می شود كه سيس44تم نتوان44د وظ44ايف واقعي خ44ود را انج44ام

دهد.IP Source Spoofing بر اساس كپي كردن آدرس :IPاس44ت. اين

حمله براي رسيدن به آدرس مقص44د، از مس44ير ك44امپيوتر ميزب44ان و ن44ام ي44ك ك44امپيوتر را جع44لIPاست. يعني اينكه يك نفر آدرس

می کند تا شناسايي نشود و از طريق آن خرابکاری هایی را انج44ام می دهد، كه ق44ابل کنترل و پيگ44يري نیس44ت. پس ابت44دا ترافي44ك ب44ه س44مت مقص44د را كم می کن44د و بع44د از طري44ق اعتب44ار ك44امپيوتر

.[2]ميزبان وارد عمل می شود

در دسترس بودن- 2-21-3

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

است و اجرا می شود. اين ويژگي كيفيتي نشان می دهد كه سيستم چقدرقادر است كه مشكالت خود را رفع كند و به حالت طبيعي خود بازگردد. اين صفت این گونه اندازه گیری می شود كه مدت زمان بين مشكالت

به وجود آمده در نظر گرفته می شود و مشخص می شود كه در اين بازة زماني تا چه ميزان به سرعت به مشكالت پاسخ داده شده، و سيستم به

حالت طبيعي برگشته است. آن كسري از زمان كه سيستم سر پا است و سؤال ها را جواب می دهد و به درخواست ها پاسخ می گوید، ميزان در

.[2]دسترس بودن را نشان می دهد است در دسترس بودن رابطه نزديكي باقابلیت اطمينان دارد، يعني هر چه

قابليت اطمينان در سيستمي زياد باشد، آن سيستم در دسترس تر خواهد بود و بالعكس. قابل اطمینان بودن يعني توانايي سيستم براي

ادامه عمليات در طول زمان. در دسترس بودن و قابليت اطمينان، وابستگي كامل با معماري

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

پشتيبان گيري و... می توان اين دو صفت كيفي را افزايش داد، كه همهاین ها از تصميمات معماري هستند.

نصب مؤلفه های اضافي براي اجرا در زمان بروز خطا و باال بردن دقت و برخورد كردن با خطاها در بهبود اين دو صفت كيفيتي و درنتیجه

در معماري اثرگذار می باشند و بايد در معماري از پيش ديده شوند. پارامترهايي كه در اين دو صفت دخالت دارند هر دو وابسته به معماري می باشند و عبارت اند از متوسط زمان شكت كه عمدتا با ايجاد معماري

باتحمل خطاهاي باالتر، اين عدد بيشتر می شود يعني متوسط زمان شكست اگر معماري باتحمل خطاي باال داشته باشيم تغيير می کند ولي

در عوض تحمل خطا با تكرار عناصر پردازشي مهم و اتصاالت در معماري به دست می آید. پارامتر بعدي متوسط زمان اصالح است. هر

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

.[2]می گذارد

وظیفه مندیقابليت عملكرد يا - 2-21-4

اين صفت توانايي سيستم براي انجام كاري كه سيستم به منظور آن ایجادشده است، را نشان می دهد. اين صفت نشان می دهد كه به چه

ميزان سيستم توانمند است. براي انجام يك كار بايد اجزاء سيستم در يك مسير هماهنگ براي تكميل آن كار پيش روند. اگر به اين اجزاء

مسئولیت های درست و واقعي واگذار نشود و يا تسهيالت الزم براي انجام اين كار و هماهنگي با بقيه مؤلفه ها را نداشته باشد، سيستم قادر

به ايجاد قابليت عملكرد موردنیاز نخواهد بود.

قابليت عملكرد ذاتا به معماري مربوط نيست و يك صفت غير معماري است و جزو مسائلي كه به تصمیم گیری معماري نياز دارند، نیست، اما چون اين صفت به ویژگی هایی مربوط می شود كه آن ها

تأثیرگذار روي معماري هستند خود قابليت عملكرد بحثي است كه مجزا از ساير صفات كيفيتي قابل بررسی است و از طرف ديگر چون بستر

اوليه يك سيستم نرم افزاري را نيازهاي وظیفه مندی تعيين می کند، پس.[2]می توان گفت كه اين صفت به معماري مربوط می شود

قابليت استفاده- 2-21-5

اين صفت به اجزاء زير شكسته می شود: 1يادگيري2كارايي

3قابل يادداشت بودن

4جلوگيري و اجتناب از خطا

5رسيدگي به خطا

6رضايت

پس اگر بخواهيم قابليت استفاده يك محصول نرم افزاري را اندازه گیری.[2]نماييم بايد آن را در اين اجزاء خالصه نماييم

- اينكه چقدر قابل يادگيري است و چقدر راحت و سريع يك1كاربر می تواند استفاده از واسط كاربر را فرابگیرد.

- آيا سيستم در زمان كم و با سرعت مناسب به تقاضاي2كاربر پاسخ می دهد.

- چقدر سيستم قابل حفظ شدن است، يعني كاربر به ياد3 می آورد كه چگونه سيستم را بايد بكار بگيرد. يعني این گونه نيست

كه كاربر سريع آن را از ياد ببرد و اگر یک بار از سيستم استفاده كرد دفعه ديگر با نگاه كردن، سريع به ياد بياورد كه چگونه بايد از

آن استفاده كند. - آيا سيستم خطاهاي معمول كاربر را پیش بینی می کند و از4

آن ها جلوگيري می کند.

1Learnability2Efficiency

3Memorability4Error Avoidance

5Error Handling6Satisfaction

- آيا سيستم به كاربر براي رهايي از مشكالت كمك می کند.5- آيا سيستم كار را براي كاربر آسان تر كرده است يا خير؟6

اصالح پذیریقابليت - 2-21-6

می توانیم ادعا كنيم كه اين قابليت در هر شكلي كه باشد بهترين ارتباط را با معماري دارد. توانايي اينكه تغييرات را با سرعت و كارايي

باال و هزينه كم ايجاد كنيم همان قابليت اصالح پذیری است كه بستگي به معماري دارد. يكي از ویژگی هایی كه كامال با معماري قابل انطباق است

قابليت اصالح است كه آن منعکس کننده معماري قابل اصالح است. قابليت اصالح تابعي از چگونگي تغيير است، يعني دانستن و يا شناسايي

.[2]محل تغيير در شرايط مساوي ايجاد تغيير بزرگ در يك سيستم نسبت به

تغيير در يك مؤلفه كوچك هزينه بيشتري را در بردارد، زيرا اعمال تغيير در سيستم بزرگ تر كار مشکل تری است. ازآنجایی که معماري مؤلفه ها و

مسئولیت ها را تعريف می کند، شرايطي را كه تحت آن هر مؤلفه بايد تعريف شود را نيز بررسي و تعريف می کند، پس مسئله اصالح پذیری با

معماري ازاین جهت گره می خورند. ازآنجایی که معماري اولين قدمي است كه ما در توليد سيستم برمی داریم تا مؤلفه را تعريف كنيم و چون

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

شرايط بتواند تغيير كند، چيست؟ دسته تقسيم می کند.3تمام تغييرات ممكن را معماري به

تغييراتي كه موجب ايجاد قابليت تغيير فقط در يك مؤلفه-1 می شوند. يعني تغييري كه می دهیم منحصر به اصالح يك مؤلفه

می شود. پس گاهي اوقات اثر تغيير بر روي يك مؤلفه است.گاهي اوقات قابليت تغيير روي چند مؤلفه است.-2 اين تغيير چيزي فراتر از بحث قابليت اصالح پذیری است، مثال تغيير-3

در سبك معماري، كه يك تغيير بنيادي است.

اغلب تغييراتي كه در نیازمندی های كاري سازمان و درنتیجه در نیازمندی های كاري يك سيستم به وجود می آید، باعث می شود كه ما به

]سمت اصالح پذیری برويم، اين تغييرات به چند دسته تقسيم می شوند2]: توانايي در تغيير يا گسترش: اضافه كردن يك كارايي جديد، بهبود-1

كارايي، اصالحات، ايجاد ساختارهاي جديد از اين نوع هستند. توانایی هایی كه در حذف مسائل ناخواسته وجود دارد: همان حذف-2

توانمندی های ناخواسته است كه براي ساده سازی كارايي يك كاربرد استفاده می شود، يعني براي مؤثرتر كردن و ساده كردن

يك وظيفه به كار می رود. براي مؤثرتر كردن كارايي، امكانات ناخواسته را حذف می کنیم، اين توانايي مربوط به مرحله نگهداري

است و در زمان اجرا قابل مشاهده نيست. تطبيق با محيط كاري و محيط عملياتي جديد: مثال وقتي تغييراتي-3

روي پردازنده ها و وسايل ورودي و خروجي و دستگاه های ديگر به وجود می آید می خواهیم نرم افزار آن ها منطبق با امكانات جديد شود، اگر این گونه باشد می گوییم كه قابليت حمل داريم كه اين

قابليت حمل درواقع جزئي از قابليت اصالح پذیری است. ساختاربندی مجدد: در اين دسته از تغييرات طراحي دوباره-4

سرویس های سيستم و ماژول ها را براي بهینه سازی انجام . مثال مؤلفه های قابل استفاده مجدد را جايگزين مؤلفه هایمی دهیم

قديمي سيستم می کنیم كه اين كار به منظور توسعه آتي سيستم انجام می گیرد، پس می توان به قابليت اصالح پذیری، قابليت

نگهداشت گفت و اين دو نام از ديد عملياتي و اثرگذاري.[2]متفاوت اند ولي ازنظر معماري اين دو اصطالح يكسان هستند

قابليت حمل- 2-21-7

اين صفت توانايي اجرا تحت محیط های محاسباتي مختلف را براي سيستم فراهم می کند. اين محیط ها می توانند سخت افزاری و يا

نرم افزاري و يا تركيبي از اين دو باشند. يك سيستم به ميزاني قابل حمل است كه تمام فرضيات در مورد هر محيط محاسباتي را در يك مؤلفه

گردآوردي كرده باشد. پس به شرطي می توانیم انتظار داشته باشيم كه نرم افزار به طور كامل قابل جابجايي باشد كه تمام فرضيات در مورد محيط محاسباتي در يك يا چند مؤلفه خالصه شده باشد. با داشتن يك

معماري الیه بندی می توان به اين قابليت دست یافت و از اين نظر می توان گفت كه اين صفت به معماري مرتبط است. مثال اگر برنامه ما

به صورت مستقيم به امكانات سخت افزاری وابسته نباشد، بلكه اليه واسطي وجود داشته باشد، مثال ماشين مجازي كه نرم افزار ما روي آن ماشين مجازي اجرا شود و ماشين مجازي روي سخت افزارهای مختلف

پیاده سازی شود، آنگاه ما به قابليت حمل دست یافته ایم و البته اين. [2]مسئله جزو تصميمات معماري است

قابليت استفاده مجدد- 2-21-8

اين صفت معموال به معني طراحي سيستمي است كه كل ساختمان آن سيستم يا برخي از مؤلفه های آن بتواند دوباره در كاربردهاي آتي

استفاده شوند. يعني سيستم را با اين هدف طراحي كنيم كه برخي از مؤلفه های آن بتوانند در برنامه های كاربردي آينده يا در چرخه های بعدي هم استفاده شوند. براي رسيدن به قابليت استفاده مجدد بايد سيستم طوري ساختاربندي شده باشد كه مؤلفه ها به عنوان محصوالتي انتخابي

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

ساخته شده اند، باشد كه در اين حالت اين صفت مفهوم قابليت تجميع را.[2]می رساند

باشد و هرکدام1براي داشتن اين صفت بايد سيستم مبتني بر مؤلفه از اين مؤلفه ها به عنوان بخشي از خدمات يا محصوالتي كه در برنامه های

مختلف می توانند كار كنند، در نظر گرفته شوند و ميزان ارتباطات مؤلفه ها كم در نظر گرفته شود و در اين صورت سیستم های بعدي

می تواند از مؤلفه های انتخابي درست شوند.

1 Component Base

قابليت تجميع پذيري- 2-21-9

اين صفت نشان می دهد كه مؤلفه هایی كه جدا از هم ساخته شده اند، چقدر می توانند باهم كار كنند و همديگر را تحمل نمايند. اين مطلب

بستگي به اين موضوع دارد كه به چه ميزان پیچیدگی های خارجي مؤلفه ها پنهان شده و تعامل و مكانيزم و سازوكارهاي ارتباطي

شناخته شده و به صورت يك پروتكل تعریف شده است و همچنين به چه ميزان مسئولیت ها بين مؤلفه ها تقسیم شده است كه تمام اين تصميمات

در سطح معماري هستند. همچنين قابليت تجميع به اين مطلب بستگي دارد كه چقدر درست و كامل و به خوبی واسطه های مؤلفه ها

تعریف شده اند. اگر واسط مناسبي براي مؤلفه ها طراحي نشده باشد،.[2]قابليت تجميع از بين می رود

قابليت آزمايش- 2-21-10

قابليت آزمايش يك نرم افزار امكاني است كه نرم افزار بتواند اشتباهات خود را در حين تست به نمايش بگذارد. ممكن است سيستم

به گونه ای ساخته شود كه تست آن مشكل باشد ولي اگر از اول سيستم را به گونه ای بسازيم كه قطعات جدا از هم با وظیفه معين و اتصاالت معین شده تعريف شوند، خودبه خود اين امكانات كمك می کند كه اگر

]اشكالي در آن ها وجود دارد، موقع تست به راحتی محل اشكال پيدا شود2].

قابليت آزمايش باال اين امكان را فراهم می نماید كه در صورت بروز اشكال در يك سيستم، به سرعت بتوانيم مولفة داراي اشكال را پيدا

نموده و اشكال آن مؤلفه را مشخص نموده و به نمايش بگذاريم. درواقع می توان گفت كه قابليت آزمايش يعني احتمال اينكه با فرض وجود حداقل يك اشتباه در سيستم نرم افزاري، در اجراي بعدي اين خطا

آشكار گردد. قابليت آزمايش به ایده هایی نظير قابليت مشاهده و قابليت كنترل نيز وابسته است. بايد قابليت كنترل هر مؤلفه و ورودی های آن و

مشاهده خروجی های آن وجود داشته باشد، درواقع بايد بتوان مسير اجرا را رديابي كرد. معماري خوب، معماري است كه قابليت آزمايش باال داشته باشد. براي اينكه سيستم قابل آزمایش باشد بايد امكان كنترل حالت داخلي هر مولفة درون آن و مشاهده خروجي آن وجود داشته

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

می کند. اگر ما بتوانيم به صورت تدريجي كار توليد را انجام دهيم،.[2]خودبه خود قابليت آزمايش هم فراهم خواهد شد

جدول ارزش دهی یانگ-2-22

خط ارزش دهی یانگ صفات کیفیتی موجود را با توجه به ارزش کیفی.[15]مشخص شده در جدول به ارزش کمی معادل آن تبدیل می کند

جدول ارزش دهی یانگ1-2جدول مقادیر کمیمقادیر کیفی

7مطلق6خیلی زیاد

5زیاد4متوسط

3کم

2خیلی کم1ناچیز

پیشینمروری بر تحقیقات -2-23

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

همچنین به تحقیق های جدید که در این زمینه انجام داده شده است،پرداخته شد.

مروري بر مدل های معروف كيفيت نرم افزار-2-24

استفاده کدام یک از سبک های معماری نرم افزار، در ارزیابی معماری خود یک چالش است. که در ادامه به شرح سه مدل معروف کیفیتی

معمار نرم افزار پرداخته می شود.

براي توصيف و مشخص نمودن صفات كيفيتي معموال از مدل های كيفيتي استفاده می شود. اين مدل ها عموما به صورت ساختار درختي از صفات كيفيتي و ارتباطات آن ها بیان شده اند. بررسي مدل های معروف

واصلی، صفات كيفيتي مناسب در يك سيستم نرم افزاري را بهتر مشخص می نماید. ذينفعان مسئله بامطالعه اين مدل ها می توانند

خواسته های خود را دقیق تر و مشخص تر بيان دارند، و بدانند كه چه]چيزهاي را بايد در توصيف خواسته های خود در اين زمينه مشخص نمايند

18].

McCallمدل - 2-24-1

م توسط نيروي هوايي آمريكا، جنرال1976-7اين مدل در سال الكتريك و مركز توسعه هوايي روم با هدف بهبود كيفيت محصوالت

نرم افزاري ارائه شد. در اياالت متحده آمريكا از اين مدل براي پروژه هاي با مقياس بزرگ نظامي و فضايي استفاده شده است. ايده اصلي مدل،

تعيين ارتباط بين عوامل كيفي و معيار هاي ارزيابي محصول است. هرچند انتقادهايي به اين مدل وارد است، ولي مزيت عمده اين مدل،

.[23]ارتباط بين ويژگي هاي كيفي و معيار ها است هايي كه كيفيت1در اين مدل يك گروه بندی مفيد براي فاكتور

نرم افزار را تحت تأثیر قرار می دهند، پیشنهادشده است. اين روش ، توانائي2كيفيت نرم افزار را بر اساس سه جنبه خصوصيات عملياتي

بيان می دارد.4، توانائي انتقال3اصالح:Cavanoدسته بندی فاكتورها به صورت ذيل است

،6، قابليت اطمينان5- خصوصيات عملياتي: صحت و درستي.9 و قابليت استفاده8، درستي و امانت7كارائي

1 Factor2 Operations

3 Revision4 Transition

5 Correctness6 Reliability7 Efficiency

8 Integrity9 Usability

،2، انعطاف پذیری1- خصوصيات توانائي اصالح: قابليت نگهداري.3آزمون پذیری

، قابليت استفاده4- خصوصيات توانائي انتقال: قابليت حمل.[1]6، قابليت تعامل پذيري5مجدد

.Mc call [1]ساختار دسته بندی خصوصيات كيفيتي در مدل 1-2شکل

هر يك از فاكتورها در اين مدل بر اساس پرسشي از طرف يكي از نكته قوت اينباالذينفعان مطرح است، طراحي گرديده است. شکل

كيفيتي محصول8 با مالک های7مدل ارتباط فاكتورهاي كيفيت خارجي است. كيفيت خارجي عبارت است از كيفيتي كه توسط خصوصيات

پوياي كد در حال اجرا اندازه گیری شده و كيفيتي كه توسط خصوصيات ثابت كد توسط برنامه نويسان اندازه گیری می شود را كيفيت داخلي

.[17]می گویند

1 Maintainability2 Flexibility3 Testability4 Portability5 Reusability

6 Interoperability7 External Quality

8 Criteria

.Mc call [1]مدل کیفیتی 2-2شکل

ISO/IECمدل - 2-24-2

اين مدل، با توجه به نياز شديد صنعت نرم افزار به استاندارد شدن انتشار يافتISOارزيابي نرم افزار، توسط مؤسسه بين المللي استاندارد

اين. [23] اصالح و تكميل شدISO توسط متخصصان2001و در سال ، قابليت اطمينان، قابليت استفاده،1مدل شش ويژگي قابليت كاركردي

كارآئي، قابليت نگهداري و قابليت حمل شدن را به عنوان ویژگی های اصلي كيفيتي نرم افزار بيان می دارد. در اين مدل عوامل به دو سطح

ويژگي و زير ويژگي تقسیم شده و همانند مدل های قبلي ساختار سلسله مراتبي داشته با اين فرق كه زير ویژگی ها در اين ساختار فقط در يك

:ISO/IECويژگي در نظر گرفته شده اند 4، تعامل پذیری و امنيت3، دقت2- عملكرد: مناسب بودن

6 و قابليت بازگشت از خطا5- قابليت اطمينان: قابليت تحمل خطا 7- قابليت استفاده: قابليت درك سيستم، يادگيري و به کارگیری

9، و رفتار منابعي8- فاكتور کارایی: رفتار زماني

، ميزان12، تغييرپذيري11: قابليت تجزیه وتحلیل10- قابليت نگهداري و قابلیت آزمايش.13تثبيت

1 Functionality2 Suitability

3 Accuracy4 Security

5 Fault Tolerance6 Recovery

7 Operability8 Time Behaviour

9 Resource Behaviour10 Maintainability

11 Analyzability12 Changeability

13 Stability

، قابليت نصب و قابليت1- قابليت حمل: تطابق پذیری.[1]همزيستي

IEEEمدل - 2-24-3

درواقع استانداردي براي ايجاد مدل كيفيتي بيان داشته، IEEEمؤسسه و مدل كيفيتي صريحي پيشنهاد نداده است. ساختار درختي را براي مدل

كيفيتي بيان داشته و بيشتر تأکید بر چگونگي طراحي روش های اندازه گیری فاكتورهاي كيفيتي دارد. ساختار پيشنهادي شبه درختي با سه

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

سطح اول، معیارهایی براي هر يك از فاكتورهاي كيفيتي مشخص شودIEEE .

به عنوان پيشنهاد اوليه يك درخت با فاكتورها و زير فاكتورهائي به شكلذيل پيشنهاد نموده است:

زماني و صرفه جوئی منابع.2- کارایی: صرفه جوئی و در دسترس4، تحمل خطا3- قابليت اطمينان: بدون نقص بودن

بودن. و تعامل پذیری.5- عملكرد: كامل بودن، صحت، امنيت، سازگاري

.6- قابليت پشتيباني: قابليت آزمايش، توسعه پذیری و اصالح پذیری - قابليت حمل: استقالل از سخت افزار، استقالل از نرم افزار و

قابليت نصب و قابليت استفاده مجدد. - قابليت استفاده: قابليت درك، سادگي يادگيري، قابليت

.[1]7به کارگیری و قابليت ارتباط با كاربر

1 Adaptability2 Economy

3 Nondeficiency4 Error Tolerance

5 Compatibility6 Correctability

7 Communicativeness

ISO/IEC-9126مدل - 2-24-4

اين استاندارد بين المللي، در سطح اول مدل، كيفيت محصول نرم افزاري را به شش ويژگي کيفي اصلي تقسيم مي كند كه هر يك از

آن ها از چند ويژگي فرعي تشکیل شده اند. ارتباط ويژگي هاي سطح اول ويژگي فرعي مدل با سطح دوم، به صورت يک به چند است؛21مدل با

به طوری که در اين مدل، كمترين همپوشاني وجود دارد. عالوه بر اين دو سطح، مدل داراي معيارهايي براي ارزيابي کيفيت نرم افزار نيز است.

مهم ترین مزيت اين مدل اين است كه ويژگي هاي كيفي داخلي و خارجي.[23]يك نرم افزار در آن تفکیک شده است

درواقع، این مدل، شكلي کلی برای ارزیابی کیفیت نرم افزار ارائه می کند. یکی از نقاط قوت این استاندارد این است که قابلیت تطابق با بسیاری از سیستم ها را دارد؛ اما كاستي آن اين است كه شامل نکات

جزئی تر نمی شود؛ ويژگي يا شاخص است و شامل6مدل اصلی این استاندارد، شامل

:[23]زیر شاخص هايي است که بیشتر به آن ها خواهیم پرداخت

این مدل در موارد کاربردی جدید زیادی بکار گرفته شده است که می توان گفت بعنوان مثال در پروژه ای که از کتاب الکترونیک بکار

. در[24]گرفته می شود صفات کیفی بر اساس این ایزو مدل شده است را با مدل ایزو بررسیERPمقاله ای ساگازی، ارزیابی کیفی سیستم

. در بررسی دیگر که توسعه چرخه حیات برنامه های[25]نموده اند کاربردی و محصوالت نرم افزار کیفی مورد بررسی قرار گرفته شد این

.[26]ایزو از نظر قابلیت و کیفتی برتر است

[26]جنبه های استاندارد نرم افزار1-2شکل

روش های مشهور ارزیابی معماری نرم افزار-2-25

در این بخش به شرح روش های مهم ارزیابی معماری نرم افزار هست که درSAAMپرداخته شد. ازنظر تاریخچه اولین مدل ارزیابی مدل

ارائه شد و روش های زیادی از این سال به بعد ارائه شد، در1993سال پرداختهATAM، CBAM، ALMA، HoPLAAادامه به تشریح چهار روش

[27][،2،][18[, ]17[, ]3][،1همچنین این چهار روش موردبررسی از ]جمع آوری شده است.

ATAMروش تحليل معماري از طريق مصالحه - 2-25-1

يكي از روش های معروف مبتني بر سناريو روش تحليل معماري مبتني بر مصالحه است. اين روش به صورت كامال جدا از روش های قبلي توسعه يافت و هدف از آن تحليل صفات كيفيتي خاص بر اساس معماري

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

مطرح1998 به عنوان يك مدل مارپيچي ارزیابی در سال ATAMاست. .[21]شد

ATAM:يك روش مبتني بر سناريو براي ارزيابي صفات كيفيتي مانند قابليت اصالح پذیری، قابليت حمل، قابليت توسعه و قابليت تجمع است. اين روش چگونگي تأمین شدن اهداف كيفيتي توسط معماري سيستم

پيشنهادي را با استفاده از يك فرآيند تکرارپذیر ارزيابي می نماید. سناريوها در اين روش بر سه نوع می باشند. سناريوهاي مورد كاري كه

يك وضعيت عادي از اجراي سيستم را تشريح می کند. سناريوهاي پيشرفت، شامل سناریوهایی می باشند كه تغييرات قابل پیش بینی آينده سيستم را نشان می دهند. سومين نوع سناريوها، سناريوهاي اكتشافي

بوده كه محدودیت های سيستم را نشان می دهند. به عبارت دیگر سناريوهاي اكتشافي وضعیت هایی را بيان می کنند كه سيستم تحت فشار

.[1,2]بوده و عملكردش به حد نهائي كاري خود رسيده باشد جهت تأمین اهداف كيفيتي اين روش پيشنهاد درست نمودن درخت

سودمندي سيستم توسط ذينفعان را ارائه نموده است. بدين شكل ذينفعان اهداف اصلي كيفيتي موردنظر خود، به همراه مشخصه های

جزئی تر آن اهداف را بيان می دارند. سپس براي تحقق آن ها يك سري سناريو مطرح نموده و پس از اولویت بندی سناريوها، به ارزيابي

عکس العمل سيستم در شرايط آن سناريوها می پردازند. گاهي تأمین اهداف كيفيتي سيستم با يكديگر تداخل داشته و بايد بين تأمین آن ها يك

تعادل و مصالحه ای برقرار نمود. يكي از اهداف اين روش مشخص كردن.[22]نقاط مصالحه و بيان روش ايجاد تعادل بين صفات كيفيتي است

فراهم كردن یک راه اصولي براي فهميدنATAMهدف روش ارزيابي توانائي معماري نرم افزار با در نظر گرفتن چندين صفت كيفيتي كه با

عالوه بر ارزيابي صفات كيفيتي،ATAMیکدیگر رقابت دارند، است. وابستگی های اين صفات كيفيتي را نيز مشخص می نماید. درواقع اين

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

مکانیسم های مصالحه را نيز مشخص می سازد. همچنين ریسک های معماري نرم افزار كه مانع رسيدن به اهداف كاري سازمان می شوند، نيز

.[27]در اين روش مشخص می گردد شامل بخش های متفاوتي تقسيمATAMمراحل نشست ارزيابي

می شود:ارائه و معرفي: معرفي روش ارزيابي، معرفي محرک ها و

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

سودمندي صفات كيفيتي، تحليل معماری ها.تست و آزمايش: جرقه های ذهني و اولویت بندی سناریوها، تحليل

مجدد معماري پيشنهادي.[27]بخش گزارش: معرفي نتايج.

ATAMمحاسن روش به شرح زير است:ATAMمحاسن روش

سهامداران به صورت كامال روشن و واضح معماري را می فهمند.

.ارتباط بين سهامداران زياد است و افزايش می یابدمستندات معماري در جريان ارزيابي بهبود می یابد و در صورت

لزوم دوباره ايجاد می شود.نتايج معماري بر اساس سناریوهای كيفيتي و موارد كاربري

استخراج می شود.

سناريوهاي كيفيتي تولیدشده به وسیله سهامداران يا بعضا تيم ATAM.بر اساس نیازمندی های غير وظیفه مندی كيفيتي است

CBAMروش تحليل هزينه- سود - 2-25-2

اين روشي يكي از روش هایی است كه بر مفاهيم بودجه )هزينه – سود( و زمان براي دستيابي به اهداف معماري بحث جدي می نماید. اين

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

ارزيابي را با توجه به نكات مالي و اقتصادي معماري انجام می دهد.CBAMپلي بين دو زمينه توليد و توسعه نرم افزار با اقتصاد سازمان در

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

تصمیم گیری بوده ولي در اين روش عوامل كيفيتي تجاري سيستم نيز به ارزيابي تا حدودي اضافه شده است. از مزاياي اصلي اين روش می توان ارائه يك مقياس اندازه گیری براي برگشت سرمايه، و كمك به تهيه يك]برنامه ارزیابی شده براي معماري و سرمایه گذاری بر روي آن، نام برد

22]. آن ممكن است8 تا 2 مرحله تقسیم شده كه مراحل 9اين روش به

.[22[, ]21]رچندين مرتبه تكرامراحل اين روش عبارت اند از:

. انتخاب سناريوها: از مجموعه سناريوهاي تعریف شده در مراحل1ATAMو سناريوهاي جديد كه توسط ذينفعان در شروع اين روش

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

. تشريح و دقيق نمودن سناريوها: در اين مرحله بر اساس نظر2 ذينفعان، محدوده وضعیت های بدترين، جاري، ايده آل و بهترين حالت

را براي هر يك از سناريوها مشخص می شود. رأی به هر يك از ذينفعان،100. اولویت بندی سناريوها: با تخصيص 3

درجه اهميت هر يك از سناريوها مشخص می شود. بدين شكل وزنهر يك از سناريوها در محاسبه سودمندي، تعيين می شود.

. محاسبه سودمندي: بر اساس نظر ذينفعان امتیاز سودمندي براي4 هريك از وضعیت های تک تک سناريوها )بدترين، جاري، ايده آل و

بهترين( مشخص می گردد. . ايجاد استراتژی های معماري براي سناريوها و محاسبه سطح5

جواب مورد انتظار: در اين مرحله استراتژی های مختلف معماري نرم افزار مشخص شده و بر اساس نظر ذينفعان، سطح جواب گوئي

جاري و مورد انتظار هر يك از استراتژی ها، تعيين می گردد. . تعيين سودمندي سطح جواب سناريوهاي مرتبط با هر يك از6

استراتژی ها: با استفاده از مقدار سودمندي استخراج شده )به كمك نمودار سودمندي( ، براي هر يك از استراتژی ها، ميزان سطح جواب

جاري و مورد انتظار مشخص می گردد. . محاسبه ميزان سودمندي هر يك از استراتژي معماري: در اين7

قسمت بر اساس امتياز وزن دار سطح جواب هر يك از سناريوها و سناريوهاي تحت تأثیر هر يك از استراتژی ها، مجموع امتياز سودمندي

استراتژی ها مشخص می شود. : بر1. انتخاب استراتژي برتر بر اساس ضريب بازگشت سرمايه8

اساس ضريب بازگشت سرمايه در هر يك از استراتژی ها، آن ها را مرتب نموده و بهترين استراتژي انتخاب می شود. ضريب بازگشت

سرمايه براي هر استراتژي از تقسيم امتياز سودمندي محاسبه شدهدر مرحله قبل بر هزينه پیش بینی شده آن استراتژي به دست می آید.

1 Return On Investment (ROI)

. تائيد نتايج به وسیله عقل سليم: در انتها انتخاب انجام شده، ازنظر9 كلي موردبررسی قرارگرفته و بر اساس شرايط عمومي کسب وکار،

.[27]دمورد تحليل شهودي قرار می گیر از تماميATAMشرکت کنندگان در جلسات ارزيابي مانند روش

ذينفعان سيستم تشکیل شده و فرض بر اين است كه در گروه شرکت کننده قابليت محاسبه هزينه و سود مربوط به معماری ها و

.[1,2]سناريوها وجود دارد

CBAMمحاسن روش

اين روش يك مقياس اندازه گیری براي برگشت سرمايه گزاري•در سيستم را تهيه می کند.

از پيشه یاين روش به سازمان ها كمك می نماید تا يك برنام•ارزیابی شده براي سرمايه گزارش های خود تهيه نمايند.

اين روش می تواند اصولي را براي تصمیم گیری های منطقي در•زمينة بكار گيري استراتژی های معماري تهيه نمايد.

] می پردازیمSAAM, ATAM and CBAMدر یک دید کلی به سه روش 28].

بررسی کلی سه روش ارزیابی1-2جدول تکنیک های توضیح مختصرنقات قوتنقاط ضعف

اولویت بندیNot a clear qualitymetricNot supported bytechniques forperforming the steps

Identifying the areas of highpotential complexityOpen for any architecturalDescription

Performs assessment ofcompeting softwarearchitectures with regardto specified qualityattributes

Softwarearchitectureanalysis method)SAAM(

Requires detailedtechnical knowledge

Scenarios generation basedon requirementsApplicable for static anddynamic properties

Assesses how well softwarearchitecture satisfiesparticular quality goals bytaking into considerationquality

Architecture tradeoffanalysismethod )ATAM(

dependenciesAbsence of definedguidelines on how toquantify costs andbenefits

Provide business measuresfor particular systemchangesMake explicit theuncertainty associatedwith the estimates

Evaluates softwarearchitectures by takinginto consideration costs,benefits and scheduleimplications ofarchitectural decisions

Cost–benefitanalysis method)CBAM(

ALMAروش تحليل قابليت اصالح در سطح معماري - 2-25-3

در اكثر متون علمي قابليت اصالح پذیری و نگهداري يك سيستم نرم افزاري به عنوان اصلی ترین فاكتور كيفيت نام برده می شود. در

هزينه چرخه70 تا %50تحقيقات انجام شده مشخص گرديده بيش از % حيات يك سيستم نرم افزاري به اصالحات انجام شده بر روی نسخه اول

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

اين روش در ابتدا فقط براي دستگاه های اطالعات تجاري طراحي گرديد.ALMAيك روش مبتني بر سناريو بوده كه براي ارزيابي ویژگی های

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

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

معماري پيشنهادي براي يك سيستم بوده و به منظور مشخص نمودن.[27]معماري بهتر و مناسب تر انجام می شود

مرحله طراحي گرديده شده است. مشخص كردن5اين روش در هدف تحليل، توصيف معماري نرم افزار، استخراج سناريوها تغيير، ارزيابي سناريوها و تفسير نتايج مراحل پنج گانه اين روش ارزيابي

می باشند. اين مراحل لزوما به طور متوالي انجام نمی شوند و ممكن است كه بعضي از مراحل به صورت تكراري هم انجام شوند. روش

ALMA بر اساس SAAMساخته شده و به همين جهت پیش شرط های زيادي از آن به ارث برده است. ازجمله اينكه از ذينفعان خواسته

می شود كه سناريوهاي تغيير را كه در طول تحوالت سيستم به نظرشان با استفاده از اين سناريوها،ALMAبه وجود می آیند، را مشخص نمايند.

قابليت تغییرپذیری سيستم را مورد ارزيابي قرار می دهد. تحليلگر همچنين بايد بتواند ميزان هزينه تأمین اين تغييرات را مشخص ارزيابي

قرار می دهد. تحليلگر همچنين بايد بتواند ميزان هزينه تأمین اين تغييرات.[27]را مشخص کند

ALMA محاسن و معايب

عبارت است از: ALMAمحاسن روش ارزيابي امكان ارزيابي قابليت اصالح پذیری از جنبه های متفاوت ارزيابي

ريسك، پیش بینی هزينه و همچنين نگهداري سيستم و انتخابمعماري وجود دارد.

سهامدارانALMAمی توانند به دو روش باال به پايين و پايين به باال، سناريوها را توليد نمايند و به همين دليل مرحله توليد

سناريوهاي تغيير نسبتا ساده است.در اين روش مفروضات مهم و كليدي به صورت صريحي بيان

می شوند.وجود تکنیک های قابل تكرار براي انجام مراحل مختلف اين

روش

عبارت است از: ALMAمعايب روش ارزيابي

اين روش فاقد تصمیم گیری در مورد دقت و درستي نتايج تحليل است.

.اين روش نمی تواند اثبات كند كه ارزيابي ريسك كامل استاين روش نمی تواند تعداد پیش بینی های نگهداري را توجيه

.[27]نمايد

HoPLAA 1خط تولید معماری ارزیابی کل نگر روش- 2-25-4

ATAMروش کل نگر ارزیابی معماری خط تولید گسترش یافته روش

هست که برای ارزیابی معماری خط تولید است.این روش در دو مرحله به شناسایی خطرات در دو سطح معماری زیر انجام می پذیرد. این دو

سطح معماری عبارتنداز:ارزیابی معماری هسته.1ارزیابی معماری محصول منحصربه فرد..2

شناسایی و2در ارزیابی معماری هسته، نقاط تکامل پذیر دستورالعمل های تکامل پذیری تعریف می شوند. مفهوم نقاط تکامل پذیر

که حاوی حداقل3این است که یک نقطه حساسیت یا یک نقطه معاوضه یک نقطه تنوع است را تعیین می کند. شناسایی از نقاط تکامل پذیر

تضمین می کند که صفات کیفیتی در سطوح محصوالت منحصربه فرد نیست.4معماری با صفات کیفیتی معماری هسته در تضاد و ناسازگاری

دستورالعمل های تکامل پذیر برای اطالع رسانی به طراحان درباره ناسازگاری های بالقوه و راهنمایی آن ها به ساختن تصمیم گیری طرحی

.[29]مناسب در محصوالت بعدی فاز طراحی معماری استفاده می شود نشأت گرفته شده است و ورودی خروجی های اینATAMاین روش از

زیر به صورت کامل بیان شده7-2روش بر دو سطح معماری در شکل مرحله دارد.7است دو سطح

1 Holistic Product Line Architecture Assessment (HoPLAA) method

2 evolvability

3 tradeoff

4 conflict

HoPLAAورودی خروجی روش 1-2شکل

و در ادامه به توضیحی مختصری که شامل چند مقاله جدید در موردبحثارزیابی معماری نرم افزار است می پردازیم

یک مدل توسعه یافته ی مبتنی بر آتاماتا با عنوان[30]در مقاله به این مدلUML 2.0آتاماتای تیمی برای تبدیل توصیفات معماری از

رسمی معرفی می شود. با توجه به زیربنای رسمی به وجود آمده، یک مدل تحلیلی برای ارزیابی کارایی معماری که با آتاماتای تیمی

توصیف شده است معرفی گردید و معمار با کمک رویه پیشنهادی خصوصیات کارایی معماری موردنظر را در شرایط هجوم ناگهانی

درخواست ها ارزیابی نموده و اصالحات الزم را جهت بهبود آن اعمالمی نماید.

روشی پیشنهادی امکان مقایسه دو معماری را در تمام[9]در مقاله دوره چرخه حیات نرم افزار تضمین می کند. این روش بر سه مفهوم

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

به هدف کسب و کار خاص، نظارت بر میزان پیشرفت پروژه در یک فرآیند مبتنی بر معماری نرم افزار و اثبات بهبود حاصل از انجام تغییرات

کلی یا جزئی بر معماری پیشین استفاده نمود. به منظور بهینه سازی توسعه یک برنامه قابل استفاده[31]در مقاله

در تلفن همراه ارائه شده است. در این پژوهش یک روش که در راستای بازرسی متد "تجزیه و تحلیل معماری نرم افزار از درک نیازمندی های

قابل استفاده" و یک ارزیابی قابلیت استفاده از تلفن همراه در قالب یک آزمون کاربر طراحی شده است. این روش به ما اجازه می دهد که نشان

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

و شناسایی از مشکالت قابلیت استفاده را در دو روش شناسایی کنیم. این کار ارائه چگونگی ترکیبی از دو روش است، که در مشکالت قابلیت

استفاده یک راه جامع ارائه دهد. به بررسی ارزیابی باز بودن معماری نرم افزار موبایل[32]در مقاله

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

می شود. همچنین در این مقاله بینش بیشتری داخل استراتژی های موفقباز بودن برای رشد اکوسیستم نرم افزار ارائه شده است.

، به شرح یک مقایسه از شش[33] در مقاله 2012همچنین در سال روش موردنیاز اولویت بندی امنیتی پرداخته است. این روش ها عبارت اند

(ARM(، روش تسریع نیاز )AHPاز: فرآیند تحلیل سلسله مراتبی ) اولویت بندی، پوکر اولویت، مدل هزینه سود، داشبورد تصمیم

پرداختهCOCOMO-II 1(، و پسوند امنیتیSIDDسرمایه گذاری امنیتی )است.

تصمیمات معماری، توانایی پیاده سازی سیستم های با کاربردی خوب The Representational Stateو نیازمندی هایی صفات کیفی را مشخص می کند.

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

را اتخاذ می کنند، که چندین مزیتSOAسیستم های توزیع شده مبتنی بر فراهم می آورد، همچنین حالت های جدید از چالش ها و خطرها است.

بویژه در میان آن خطراتی که موجب شکست موثر در نیازمندی صفات کیفی می شود مهم است، بعنوان مثال: امنیت، قابلیت اطمینان و

یک روش ثابت کارآمد برای شناسایی و کمک کاهش دادن اینکارایی. خطرات در ارزیابی معماری نرم افزار است. در این مقاله ارائه داده

شده یک روش، ابزار و دستورالعمل برای کمک کردن به فعالیت های این دستورالعمل ها.RESTارزیابی معماری در سیستم های مبتنی بر

1 Security extension

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

کند به ارزیاب های معماری، ما یک دلیل از توصیف مفهومی این که چگونه استفاده می کنیم ارائهATAMدستورالعمل در روش ارزیابی

درRESTمی دهیم. در این مقاله همچنین ارزیابی یک سیستم مبتنی بر دنیای حقیقی با متخصصان صنعت به منظور ارزیابی قابلیت ها آن ارائه

.[34]شده است توسعه توزیع سیستم های نرم افزاری در مقیاس بزرگ که شامل

سرمایه گذاری کالن می شود در سطح باالی از ریسک قرار گرفته است. آن را مورد بررسی قرار داده اند و شرایط امنیATAMبا روش ارزیابی

.[35]برای این سیستم نرم افزاری ارزیابی و ارائه می کند

مقايسه روش های ارزيابي مبتني بر سناريو-2-26

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

ارزيابي مبتني بر سناريو مورد تجزیه وتحلیل قرار می گیرد. همچنين براي مقايسه روش های مبتني بر سناريو آن ها در يك چارچوب مقایسه ای

موردبررسی قرار خواهند گرفت. ازنظر كلي در هر روش ارزيابي ویژگی های كيفيتي يك سيستم

نرم افزاري، بايد سه فعالیت اصلي مورد توجه باشد:به دست آوردن ویژگی های كيفيتي درخواستي ذينفعان و

اولویت بندی آن ها..پيدا نمودن ویژگی های كيفيتي موجود در معماري پيشنهادي.يك روش براي بررسي مطابقت و سازگاري اين دو باهم

بدين معني كه بايد ویژگی های كيفيتي مورد انتظار ذينفعان با توجه به اولويت موردنظر آن ها ابتدا مشخص شده و همچنين ویژگی های موجود

در راه حل پيشنهادي نيز تعيين گردد. سپس با توجه به اين دودسته ويژگي ميزان تأمین مطابقت ویژگی های موجود در معماري پيشنهادي با

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

ویژگی های سيستم درخواستي است. تمام كساني كه تجربه ای در تجزیه

و تحلیل سيستمهاي نرم افزاري و توصيف آن ها دارند به اين امر واقف می باشند كه، مشكالت زیادی در تعيين نیازمندی های سيستم و توصيف

خواسته های ذينفعان و مستند نمودن آن ها وجود دارد. از طرف ديگر در دنياي واقعي و عملي توليد نرم افزار، بيشتر مواقع توصيف كامل و دقيقي از سيستم وجود نداشته، و يا در زمان طراحي معماري اين

توصيف كامال مكتوب و مشخص در مستندات سيستم بیان نشده است. از طرفی ديگر به علت عدم آشنایی دقيق استفاده کنندگان سيستم از

مفاهيم كيفيتي نرم افزار و اصطالحات متداول در اين علم، اين خطر نيز وجود دارد كه نتوانند خواسته خود را به شكل صحيح بيان دارند.

روش های ارزيابي مبتني بر سناریو سعي دارد كه با آشنایی بيشتر ذينفعان سيستم، نسبت به مفاهيم ارزيابي و ویژگی های كيفيتي

خواسته ها را مشخص تر به دست آورد. در اكثر اين روش ها با درگير کردن ذينفعان واقعي سيستم در كار ارزيابي و بيان نمونه های شهودي از خواسته آن ها، نیازمندی های واقعي مشخص می شود. اين روش ها با بیان

سناريوها توسط ذينفعان، سعي در تداعي شرايط عملي داشته تا توقع خود را بهتر درك نموده و خارج از پیش فرض های معنائي كلمات موجود

در مهندسي نرم افزار، نوع و ميزان رفتاري كه از سيستم متوقع می باشند، را بيان نمايند. جهت مشخص نمودن ویژگی هایی كه در

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

ویژگی های مختلف كيفيتي در طرح خود را مشخص می نمایند. درنهایت با شراكت تمامي ذينفعان ميزان مطابقت معماري با نیازمندی های سيستم مشخص می شود. بدين شكل مشخص است روش های مبتني بر سناريو

به هر سه مرحله ارزيابي ویژگی های كيفيتي به ميزان مناسبي اهميتداده و درروش خود آن ها را در نظر گرفته است.

درواقع هدف ارزيابي مطابقت خصوصيات سيستم آماده اجرا با سيستم موردنیاز است. براي اينكه اين مطابقت تا اتمام توليد به تأخیر

نيفتد، از معماري براي پیش بینی رفتارهاي آن استفاده می شود. همچنينسيستم موردنیاز با توصيف انجام شده توسط ذينفعان مشخص می شود.

با درگير شدن تمامي ذينفعان مسئله در جلسات بازنگري موجب می شود كه هر چه بيشتر سيستم توصیف شده با سيستم موردنیاز

مطابقت پيدا نموده و از ورود تصورات اشتباه حتي امکان جلوگيريشود.

ارتباط سيستم موردنیاز با معماری.1-2شکل

به جز روند انجام عملياتي كه در ابتداي اين قسمت براي يك روش ارزيابي يادآوري شد، خصوصيات ديگري نيز در ميزان موفقيت يك روش

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

منظور صرف شود. به طور خالصه هزینه ای كه اجراي يك ارزيابي به هزینه های توليد نرم افزار اضافه می کند، اعم از هزینه های زماني و هزینه های پرسنلي موردنظر می باشد. البته اين نكته در كنار ميزان

نتايجي كه از آن روش به دست می آید، بهتر قابل بررسی است. روش های مبتني بر سناريو با توجه به اين موضوع سعي نموده اند باکم

كردن هرچه بيشتر هزینه های تحميلي، با حداكثر دقت و صحت، سه مرحله اصلي ارزيابي را انجام دهند. به طورمعمول با توجه به اندازه

روز الي يك هفته كاري و افراد شرکت کننده2سيستم، زمان ارزيابي از نفر در نظر گرفته شده است. بدين لحاظ ازنظر15 الي 4در آن بين

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

اما نكته ضعف يا خطري كه در اين روش ها وجود دارد اينستكه موفقيت تمامي آن ها، وابستگي بسياري به دانش و تجربيات ذينفعاني

دارد كه در جلسه شركت نموده اند. تمامي تصميمات با توجه به نظرات اين گروه گرفته شده و اگر اين افراد در مباحث کسب وکار مربوطه،

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

افراد باتجربه و تبحر باال نيز ممكن است هميشه در دسترس نبوده و ياهزينه پرسنلي را بسيار افزايش دهند.

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

ویژگی های مورد ارزيابي، تعداد مراحل فرآيند ارزيابي، ابزارها و استراتژی ها، ميزان مستند شدن و مشخص بودن جزئيات روند کار،

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

مقایسه روش های ارزیابی معماری نرم افزار1-2جدول HoPLAAALAMCBAMATAM

تماميویژگی ها

اصالح پذیر ی و

نگهداری

صرفه جوئی ومنابع مالي

تماميویژگی ها

ویژگی هایكيفيتي

7 فاز در 2مرحله

6 فاز و 2 فعاليت5فعاليت

فعاليت9 فاز2در

تعداد مراحلفرآيند

همه سیستم هاخط تولید

سیستم ها ی

کسب وکار

همههمه سیستم هاسیستم ها

محدودهكاربردي

نفره2تيم ارزيابي و

گروه ذينفعان

مشخصنشده

2 روز، تيم 2 نفره ارزيابي وگروه ذينفعان

روز، تيم2 نفره2

ارزيابي و گروه

ذينفعان

منابع زماني/انساني

نقاطتکامل پذیر

پیش بینی اثرات

تغييرات

تعيين منابع اقتصادي و

عملياتي

نقاط حساس و

مصالحه

اهداف ريزارزيابي

3. فصل سوم: روش

پیشنهادی برای حل مسئله

79

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

مقدمه-3-1

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

، ازATAMاست. در ادامه برای بهبود روش ارزیابی معماری نرم افزار استفاده شده است. نهایتا باISO9126مدل معروف کیفیت نرم افزار

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

شده است.

ساختار معماری نرم افزار روش پیشنهادی-3-2

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

مورد استفاده در ساختار1+4سوم معماری کورچن یا همان معماری معماری پیشنهادی شده است.

برای ارزیابی این ساختار معماری، از روش ارزیابی معماری نرم افزارATAMاستفاده شده است، که در روش پیشنهادی به بهبود آن

ارائه شده برای به دستISO 9126پرداخته ایم. ابتدا باید از جدول ویژگی آوردن سناریوهای مورداستفاده یا همان سؤاالت که باعث می شود متوجه اجراشدن یا نشدن صفات کیفی می شود، بکار گرفته شود.

سناریوهای موردنظر خود را استخراج کرده باATAMدرروش ارزیابی و سپس با استفاده از جدول ارزش دهی یانگISO 9126کمک جدول

مقداری کمی به آن صفت کیفی داده شود. در آخر ارزیابی امتیازها داده شده جمع و ارزش معماری نرم افزار طراحی شده مشخص شده در

بین معماری های متفاوت رتبه بندی می شود. در ادامه به تفصیل بیشتر مراحل آن می پردازیم و نهایتا، معماری

80

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

نرم افزار نمونه و معماری پروژه توسعه سیستم مدیریت چرخه عمر تجهیزات شبکه و نیروگاه های برق هرمزگان با روش پیشنهادی بررسی

می شود.

PLC1چرخه حیات محصول - 3-2-1

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

پرداخته ایم.PLCکامل چرخه حیات محصول درواقع چرخه حیات محصول، چارچوب و نظامی است جهت معرفی

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

. [15]زمان و هزینه است چرخه حیات محصول به دو ریز بخش تقسیم می شود. که در ساختار

پیشنهادی معماری نرم افزار ابتدا باید مخاطبین محصول شناخته شده باشند و سپس اینکه ساختار کلی چرخه حیات محصول به صورت مختصر

در معماری بیان شود، که چه روندی در طول حیات خود دارد.مخاطبین چرخه حیات محصول(1

[15]مخاطبین چرخه حیات محصول1-3جدول مخاطبین چرخه حیات محصولدرجمدیران عامل و معاونینیک

مدیران تولید و معاونینرئیس گروه های کاری

گروه ها و شرکت های همکار )ارائه دهندگان و فروشندگاندوسیستم ها(

مشتری های خاص )یا کنترل دقیق(اشخاصی که ارزش افزوده برای محصول خواهند آورد

ساختار کلی چرخه حیات محصول(2 تولد، بلوغ، مرگ

هر سیستم دارای طول عمر معینی است که در طول آن برای تأمین1 Product Life Cycle

81

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله نیازمندی های اطالعاتی رو به گسترش دست خوش تغییراتی قرار خواهد

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

سیستم جاری و نهایتا منجر به پایان عمرش می گردد. چرخه حیات محصول نرم افزاری در ابتدا تولید و بعد به مرحله بلوغ خواهد رسید

.[15]درنهایت به مرحله مرگ ختم می شود

دوران چرخه حیات محصول2-3شکل

علت وجود این بخش در معماری نرم افزار پیشنهادی با توجه به دید مدیریت برون سپاری به این خاطر است که برای ارزیابی ابتدای از فرد و

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

نرم افزار چند سال عمر مفید با توجه به پیشرفت تکنولوژی در زمان را دارد و چه زمان این نرم افزار با توجه به درخواست ها و تغییر تکنولوژی

.[15]به مرگ ختم می شود هدف از به کارگیری چرخه حیات محصول نرم افزاری، ایجادمنظور از

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

هزینه پرداخت کرد. دلیل به کار گرفتن این بخش در ساختار معماری نرم افزار پیشنهادی

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

بگیرد. این بخش باعث می شود که طراح دید کامل به نرم افزار طراحی شده داشته باشد و تمام مخاطبین موردنیاز نرم افزار را

تولد

بلوغ

مرگ

82

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

شناسایی کند.

استاندارد، الگوها، اهداف و محدودیت نرم افزار- 3-2-2

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

نرم افزاری توسط طراح پرداخته شده است. در ساختار معماری نرم افزار به بیان اهداف نرم افزار موردنظر

پرداخته شده و همچنین از محدودیت ها موجود چه سخت افزاری و چه نرم افزاری پرده برداشته شده است. از الگوهای یا استانداردهای

مورداستفاده در طراحی نرم افزار مشخص شده است. به طور مثال استفاده از معماری سه الیه در برنامه نویسی یا استفاده از سرویس

کالینت سرور و .... مزیت این بخش در ساختار معماری نرم افزار پیشنهادی این است که

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

مشخص شود که نرم افزار به چه ویژگی و صفات کیفی اولویت بیشتری داده شده و اولویت صفات کیفی در این قسمت مشخص شده است. ارزیابی معماری نرم افزار این بخش، کمک شایانی به وابستگی کمتر ارزیابی به تیم ارزیاب می کند. به دلیل اینکه، کلی از صفات کیفی و

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

ارائه داده است، مشخص می شود که آیا این شرکت صالحیت انجام وتوانایی پیاده سازی معماری پیشنهادی خود را دارد یا خیر.

در بخش بعدی ساختار معماری نرم افزار استفاده از معماری آقایکورچن یا همان چهار بعالوه یک موردبررسی قرار می گیرد.

1+4استفاده معماری - 3-2-3

در بخش سوم و آخرین بخش از ساختار معماری نرم افزار ارائه شده از معماری چهار بعالوه یک استفاده می کنیم. که در آن دیدگاه های

نسبت به1+4 بیان می شود. مزیت استفاده معماری 1+4معماری

83

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

ساختارها و دیدگاه های معماری نرم افزار، که آقای کروچن در مقاله ای بیان کرد. هیچ کدام از ساختارها با یکدیگر تناقضی ندارند و همه آن ها در

جهت برطرف کردن نیازمندی های سیستم هستند ولی بهتر است از موارد کاربردی مهم به منظور انتخاب ساختارها استفاده شود که منجر

شد. که امروزه این دیدگاه خیلی مورد استفاده عموم1+4به دیدگاه قرار گرفته شده است.

با تکمیل این معماری ساختار پیشنهادی برای بیان معماری نرم افزار ارائه شده کامل می شود. در قسمت بعدی این فصل به ارزیابی اینمعماری پیشنهادی با بهبود روش پیشنهادی ارائه شده می پردازیم.

1+4معماری 1-3شکل

دیدگاه منطقی: این دیدگاه پیرامون نیازمندی های عملیاتی است که به مهم ترین

نیازمندی های منطق کاربردی سیستم و موارد کاربردی سیستم می پردازد. از محصول های مرتبط با این دیدگاه می توان به مدل طراحی که شامل دیاگرام های کالس می باشد اشاره کرد. افراد درگیر این دیدگاه

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

دیدسازمان دهی آن ها در قالب بسته های طراحی پرداخته می شود.

84

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

منطقی درگیر قابلیت هایی است که سیستم برای کاربران نهایی فراهم ،Communicationمی آورد. برای نمایش دید منطقی از نمودارهای کالس،

دیدگاه منطقی شامل کالس ها و استفاده می شود. Sequenceو نمودار اشیا است که در شئ گرایی جهت دستیابی به حداکثر تجرید استفاده

.[16]می شود. درواقع همان ساختار ماژول است دید الیه بندی یا ماژول: در این قسمت باید مواردی از قبیل

ماژول هایی ) که می توانند الیه یا زیرسیستم در نظر گرفته شوند( که تجزیه عملکردی سیستم را نشان می دهند همراه با اشیاء، رویه ها، توابع

و ارتباطات بین آن ها )به عنوان مثال، فراخوانی رویه، درخواست متد و. [19]غیره( نمایش داده شوند

دیدگاه پردازش: حیطه کاری این دیدگاه پیرامون نیازمندی های غیر عملکردی است که

هم روندی و همزمانی پردازش ها را موردمطالعه قرار می دهد. ایندیدگاه محصول جداگانه ای در اختیار نمی گذارد.

درprocess viewدر دیدگاه پروسه بررسی و مشخص شدن نحوه نحوه پیاده سازی سیستم و معماری داخلی آن است، پروسه های اصلی

سیستم را با توسط نمودار همکاری نمایش داده می شود. عصر اندیشه. نحوه هم زمانی و توزیع وظیفه مندی ها را نشان می دهد. ساختار مؤلفه ها

دید فرآیند، درگیر وجهه پویای سیستم است. پروسه های. [16]و اتصال ها سیستم را توصیف کرده و نحوه تعامل آن ها باهم. همچنین بر رفتار

سیستم در زمان اجرا تمرکز دارد. دید فرایند همزمانی، توزیع، کارایی و برایActivity از نمودارهای UMLمقیاس پذیری را پوشش می دهد. در

نمایشان استفاده می شود. دید مؤلفه و اتصال: در این قسمت باید فرآیندها و نخ ها همراه با

همگام سازی، جریان داده و رویدادها که آن ها را به یکدیگر متصل.[19]می کند، نشان داده شود

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

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

85

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

دیدگاه پیاده سازی که توصیف معماری و طراحی داخلی سیستم است، ارائه از تجزیه وتحلیل الیه ها و قسمت های مختلف سیستم

دید توسعه برای تشریح سیستم از دید یک برنامه نویس است ومی باشد. Implementationدرگیر مدیریت نرم افزار است. به این دید همچنین

View هم می گویند. در UML از نمودار Componentبرای توصیف ازUMLکمپوننت های سیستم استفاده می کند. برای نمایش این دید در

سازمان دهی ماژول ها، کتابخانه ها، استفاده می کنیم.Packageنمودار زیرسیستم ها و واحدهای توسعه را نمایش می دهد درواقع ساختار

.[16]تخصیص را نمایش می دهد

دیدگاه استقرار حیطه این دیدگاه در مورد توپولوژی استقرار است. این دیدگاه به

تشریح نحوه نگاشت نرم افزار در محیط فیزیکی و سخت افزار می پردازد و جنبه های توسعه نرم افزار را نشان می دهد. در این دیدگاه با توصیف

سناریو استقرار در معماری به توصیف ساختار نهایی استقرار پرداخته و فرض هایی در موردنیاز در زمان استقرار بیان می کنیم. مهم ترین خروجی

این قسمت سند استقرار نام دارد. در دیدگاه فیزیکی نحوه قرارگیری و آرایش ماژول و پکیج های

نرم افزاری بر روی سخت افزار موجود نمایش داده می شود. پلت فرم وسخت افزار و سیستم عامل و نرم افزارهای مورداستفاده بیان می شود.

دید فیزیکی سیستم را از دید یک مهندس سیستم نمایش می دهد. این دید درگیر توپولوژی کمپوننت های نرم افزاری در الیه فیزیکی است،

از نمودارهایUMLبعالوه ارتباطات فیزیکی بین این کمپوننت ها. در Deploymentبرای نمایش الیه فیزیکی استفاده می شود. نحوه نگاشت

اجزا را به پردازنده ها و گره های ارتباطی مشخص می کند. این ساختار]مشابه ساختار تخصیص است اما بیشتر جنبه استقرار مدنظر آن است

16].

دید موارد کاربردی یا سناریو: این دیدگاه به توصیف و توضیح پیرامون سناریوهای مهم و اساسی

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

سند حاصل از این دیدگاه سند موارد کاربرد است.

86

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

دیدگاه موارد کاربردی که ابتدا نمای کلی سیستم را ترسیم می کند، دیاگرام ها می پردازیمusecase به بررسی قسمت های مهم توسطسپس

دیدگاه موارد کاربردی یاو توضیح مختصری در مورد آن ها بازگو می کنیم. ها ،use caseسناریوها. توصیف معماری با استفاده از مجموعه ای از

سناریوها انجام می شود. این سناریوها توصیفگر توالی ارتباطات بین اشیا و پروسه ها هستند. به خودی خود یک دید نیست درواقع همان موارد

.[16]کاربردی است نسب به ساختارها و دیدگاه های1+4مزیت استفاده معماری

بیان کرد که هیچ کدام[36]معماری نرم افزار که آقای کروچن در مقاله ی از ساختارها با یکدیگر تناقضی ندارند و همه آن ها در جهت برطرف

کردن نیازمندی های سیستم هستند ولی بهتر است از موارد کاربردی 1+4مهم به منظور انتخاب ساختارها استفاده شود که منجر به دیدگاه

. که امروزه این دیدگاه خیلی مورداستفاده عموم قرارگرفته[36]شدشده است.

با تکمیل این معماری ساختار پیشنهادی برای بیان معماری نرم افزار ارائه شده کامل شده است. در بخش بعدی این فصل به ارزیابی معماری

پیشنهادی با بهبود روش پیشنهادی ارائه شده پرداخته شده است.

بهبود روش ارزیابی معماری نرم افزار-3-3

در ارزیابی معماری مطرح شده از روش ارزیابی معماری نرم افزارATAM پرداخته شده، استفاده کرده ایم. در این بخش به بهبود این روش

به صورت زیر بیان شدهATAMمراحل روش ارزیابی معماری نرم افزار است.

ATAMروش ارزیابی معماری نرم افزار - 3-3-1

يكي از روش های معروف مبتني بر سناريو روش تحليل معماري مبتني بر مصالحه می باشد. اين روش به صورت كامال جدا از روش های قبلي توسعه يافت و هدف از آن تحليل صفات كيفيتي خاص بر اساس

بر روي جنبه های كيفيتي معماري با جزئياتATAMمعماري می باشد. بيشتري از روش های قبل بحث می کند، و در عمل نسخه تقویت شده ای

87

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

به عنوان يك مدل مارپيچي ارزیابی در سالATAM می باشد. SAAMاز .[21] مطرح شد1998

ATAM:يك روش مبتني بر سناريو براي ارزيابي صفات كيفيتي مانند قابليت اصالح پذیری، قابليت حمل، قابليت توسعه و قابليت تجمع

می باشد. اين روش چگونگي تأمین شدن اهداف كيفيتي توسط معماري سيستم پيشنهادي را با استفاده از يك فرآيند تکرارپذیر ارزيابي می نماید.

سناريوها در اين روش بر سه نوع می باشند. سناريوهاي مورد كاري كه يك وضعيت عادي از اجراي سيستم را تشريح می کند. سناريوهاي

پيشرفت، شامل سناریوهایی می باشند كه تغييرات قابل پیش بینی آينده سيستم را نشان می دهند. سومين نوع سناريوها، سناريوهاي اكتشافي

بوده كه محدودیت های سيستم را نشان می دهند. به عبارت دیگر سناريوهاي اكتشافي وضعیت هایی را بيان می کنند كه سيستم تحت فشار

بوده و عملكردش به حد نهائي كاري خود رسيده باشد. جهت تأمین اهداف كيفيتي اين روش پيشنهاد درست نمودن درخت

سودمندي سيستم توسط ذينفعان را ارائه نموده است. بدين شكل ذينفعان اهداف اصلي كيفيتي موردنظر خود، به همراه مشخصه های

جزئی تر آن اهداف را بيان می دارند. سپس براي تحقق آن ها يك سري سناريو مطرح نموده و پس از اولویت بندی سناريوها، به ارزيابي

عکس العمل سيستم در شرايط آن سناريوها می پردازند. گاهي تأمین اهداف كيفيتي سيستم با يكديگر تداخل داشته و بايد بين تأمین آن ها يك

تعادل و مصالحه ای برقرار نمود. يكي از اهداف اين روش مشخص كردن.[22]نقاط مصالحه و بيان روش ايجاد تعادل بين صفات كيفيتي است

88

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

ATAMروند کار 1-3شکل

فراهم كردن یک راه اصولي براي فهميدنATAMهدف روش ارزيابي توانائي معماري نرم افزار با در نظر گرفتن چندين صفت كيفيتي كه با

عالوه بر ارزيابي صفات كيفيتي،ATAMیکدیگر رقابت دارند، می باشد. وابستگی های اين صفات كيفيتي را نيز مشخص می نماید. درواقع اين

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

مکانیسم های مصالحه را نيز مشخص می سازد. همچنين ریسک های معماري نرم افزار كه مانع رسيدن به اهداف كاري سازمان می شوند، نيز

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

، روشي جامع و كامل را براي امر ارزيابي معماريATAMبه كار می رود. سيستم ها و به دست آوردن اطالعات ارزشمندي از آن ها ارائه مي نمايد.

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

معياري براي سنجش ميزان تطابق معماري ارائه شده باATAMروش مشخصه های كيفي كه در سيستم موردنظر مي باشند، به دست می دهد.

قادر به ارائه ي اطالعاتي در مورد چگونگيATAMاز سوي ديگر، روش برهم کنش اهداف كيفي سيستم نيز مي باشد. به عنوان مثال، اين روش

89

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله مي تواند تعيين كند كه كدام اهداف كيفي و تا چه حد بر هم تأثير دارند، و

چه بده مصالحه های بين آن ها برقرار است )به عنوان مثال، كاهشکدام یک منجر به افزايش ديگري مي شود، و برعکس(.

براي درك اهميت در دست داشتن يك روش ارزيابي معماري كارا و دقيق، بايد چالش هاي ارزيابي معماري سيستم هاي نرم افزاري را

به درستی شناسايي نماييم. يك بعد دشواري ارزيابي معماري سيستم هاي نرم افزاري بزرگ آن است كه خود معماري نيز عموما بسيار بزرگ

است، و درك آن در مدت زمان كوتاه كار آساني نیست. از سوي ديگر، روش ارزيابي بايد راه کاری براي ارتباط دهی اهداف كاري سيستم به تصميماتي كه در معماري اتخاذ گرديده است، ارائه كند. برقراري اين

ارتباط، خصوصا در مورد سيستم هاي بزرگ و پيچيده، كار دشواري است. عالوه بر اين ها، به دست آوردن اهداف و نقطه نظرات ذینفعان متفاوت پروژه در زمان كوتاه، امري با پيچيدگي ها و ظرافت هاي خاص

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

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

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

تالش براي حل اينATAMمعماري در زمان كوتاه مي باشند. روش مشكل دارد.

شامل بخش های متفاوتي تقسيمATAMمراحل نشست ارزيابي می شود:

ارائه و معرفي: معرفي روش ارزيابي، معرفي محرک ها وپیشران های حرفه، معرفي معماري نرم افزار.

تحليل و بررسي: معرفي معماری های پيشنهادي، ايجاد درختسودمندي صفات كيفيتي، تحليل معماری ها.

تست و آزمايش: جرقه های ذهني و اولویت بندی سناریوها، تحليلمجدد معماري پيشنهادي.

بخش گزارش: معرفي نتايج

90

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

ATAMمشارکت کنندگان در - 3-3-2

ATAM:به مشارکت و همکاری سه گروه نیازمند است که عبارت اند از ا- تیم ارزیابی

این گروه جز اعضای معرفی شده پروژه معماری نیستند و معموال متشکل از سه یا پنج نفر است. هر عضو از تیم دارای تعدادی از نقش هایی است که درروند ارزیابی باید مسئولیت هایی مرتبط با

آن نقش ها را انجام دهد. نقش های موجود در تیم ارزیاب یک واحد همیشه فعال است که ارزیابی معماری به صورت مداوم در آن در

حال انجام شدن است. اعضاء این تیم می تواند از معماران سیستم که در زمینه موردنظر مهارت دارند، انتخاب شوند.

نیروهای تیم می توانند متعلق به تیم توسعه ی سازمانی باشند که معماری آن در حال ارزیابی است و یا اینکه به عنوان مشاور از

خارج سازمان حضورداشته باشند.- تصمیم گیرندگان پروژه 2

این افراد در مذاکره به منظور توسعه و تکمیل پروژه توانایی زیادی دارند و یا قدرت و اجازه اعمال تغییرات در معماری را

دارند. آن ها معموال شامل مدیریت پروژه و نمایندگانی از مشتری هستند که از توسعه سیستم به صورت مالی پشتیبانی می کنند.

برای معمار معموال نقش خاصی در ارزیابی معماری وجود دارد که باید آن را به صورت مناسب انجام دهد. نهایتا، شخصی که

مأموریت ارزیابی را دارد که باید آن را به صورت مناسب انجام دهد. نهایتا، شخصی که مأموریت ارزیابی را دارد معموال توانایی و قدرت مذاکره برای توسعه و تکمیل پروژه دارد )حتی اگر قدرت

آن را نداشته باشد( و باید جزء این گروه قرار بگیرد.- ذینفعان معماری3

ذینفعان در مورد این معماری را به عنوان مبنایی برای تبلیغ کار خود قرار دهند، سود زیادی به دست می آورند. آن ها اشخاصی

هستند که توانایی انجام کارهایشان وابسته به ترویج قابلیت تغییرپذیری، امنیت، قابلیت دسترسی باال و سایر خصوصیات

معماری است. ذینفعان دربرگیرنده توسعه دهندگان، آزمایش کنندگان، یکپارچه سازها، نگهدارندها، مهندسی کارایی، کاربران، سازندگان سیستم و سایر افراد درگیر توسعه سیستم

هستند. نقش ذینفعان درروند ارزیابی آن است که اهداف خصوصیات

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

به منظور ارزیابی مناسب معماری سیستم، باید بین دوازده تا پانزدهسرویس مرود انتظار ذینفعان مشخص شود.

91

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

نقش و توضیحات تیم ارزیاب1-3جدول مشخصات مطلوبمسئولیت هانقش

تنظیم ارزیابی،رهبر تیم هماهنگی با مشتریان،

تضمین اینکه نیاز مشتریان برآورده شده

است، بستن قرارداد ارزیابی، تشکیل تیم

پروژه و رؤیت گزارشنهایی قابل تحویل

سازمان دهنده خوب با مهارت های مدیریتی،

در ارتباط برقرار کردن با مشتری ماهر

باشد و به فرجه های زمانی نیز توجه داشته

باشد.

اجرای ارزیابی؛رهبر ارزیابی هماهنگی با مشتریان، )استخراج( سناریوها،

مدیریت انتخاب سناریوها / فرآیند

اولیت بندی، تسهیل ارزیابی سناریوها در

برابر معماری و تسهیلدر محل

راحت در مقابل شنوندگان، مهارت

عالی در تسهیل کردن، درک خود از پیامدهای معماری، دارای تجربه

در زمینه ارزیابی معماری، قادر به

مشخص کردن این موضوع باشد که آیا نیاز است یک بحثی

به صورت طوالنی انجام شود یا اینکه به خاطر بی فایده بودن

باید قطع شود. نوشتن سناریوها روینویسنده سناریو

flipchart یا whiteboard در زمان استخراج

سناریوها، دستیابی به توافق بر روی لغات استفاده شده در هر

سناریو و متوقف کردن مذاکره تا زمان

استخراج شدن لغات

دستخط خوب، سخت گیری در مورد

حرکت از طریق شناخت سناریوها،

توانایی در درک ماهیتبحث های تکنیکی

نویسنده شرحمذاکرات

نوشتن شرح مذاکرات )اقدامات( به شکل

الکترونیکی، سناریوهای خام، علت و جزئیات

هر سناریو و چاپ فهرستی از سناریوهای پذیرفته شده برای ارائه

تایپ کننده خوب و سریع، سازمان دهند خوب برای بازخوانی

سریع اطالعات، قابلیت درک خوب پیامدهای معماری،

قابلیت تطبیق سریع

92

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

پیامدهای تکنیکی،به مشارکت کنندگان نترس در زمینه ایجاد

وقفه در بحث به منظور درک بهتر پیامد و تولید

مستندات مفید به رهبر ارزیابی کمکوقت نگه دار

می کند تا مبتنی بر زمان بندی حرکت کند و

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

را کنترل می کند.

حاضر باشد در میان جلسه وقفه ایجاد کندتا زمان را اعالم کند.

نکاتی را در مورد اینکهناظر فرآیند فرآیند ارزیابی چگونه

می تواند بهبود و یا منحرف شود مطرح

می کند، دادن پیشنهادهایی به رهبر ارزیابی در بخش های

مختلف فرآیند ارزیابی، بعد از اتمام ارزیابی

مسئول ارائه گزارش به تیم ارزیابی معمار در زمینه روند فرآیند

ارزیابی، نکات مثبت و تجارب موفق

به دست آمده است.

ناظری بامالحظه، دارای دانش در زمینه

فرآیند ارزیابی، داشتن تجارب در زمینه روش

ارزیابی معماری

به رهبر ارزیابی کمکاجراکننده فرآیند می کند تا مراحل روش

ارزیابی را به خاطرآورده و انجام دهد.

تسلط کامل بر مراحل روش، بتواند و بخواهد

راهنمایی های خردمندانه به رهبر

ارزیابی بدهد مسائل معماری کهپرسشگر

ذینفعان به آن توجه نداشته اند را مطرح

می کند.

بینش معماری خوب، بینش خوب در مورد

ذینفعان، داشتن تجربه در مورد سیستم مورد ارزیابی، نترس در بیان

کردن پیامدهای جنجال برانگیز و دنبال

کردن آن ها، آشنا باخصوصیات دغدغه ها

93

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

ATAMمراحل - 3-3-3

داراي چهار فاز اصلي است. در فاز صفر )تدارک و ATAMپروسه ی مشارکت(، رهبر تيم ارزياب به همراه تصمیم گیران كليدي پروژه در

مالقات مي كنند. در اين ATAMخصوص تعيين دقيق جزئيات پروسه ي جلسه، در مورد امكانات برگزاري جلسه، فهرست اوليه ي ذينفعان

معماري، زمان بندي آماده سازی گزارش كتبي نهايي، و موارد موردبحثدر فاز بعدي تصميماتي گرفته مي شود.

در فاز يك )ارزیابی( اعضاي تيم ارزياب با تصمیم گیران پروژه به منظور آغاز جمع آوری اطالعات و تحليل مالقات مي كنند. در اين فاز، معماري مورد تحليل قرار مي گيرد. در فاز دو )ادامه ارزیابی( ذينفعان

مي شوند، و كار تحليل ادامه مي يابد. درATAMمعماري وارد پروسه ي اين فاز، مراحل فاز قبلي ابتدا اجماال مورد مرور قرار مي گيرد، تا

شده اند، ازATAMذينفعان معماري كه به تازگی وارد پروسه ي فعاليت هاي انجام شده مطلع شوند.

گزارشي كتبيATAMدر فاز سوم )پیگیری( شرکت کنندگان پروسه ي را تهيه می کنند، و سپس جلسه اي برگزار مي شود كه در آن نقاط قوت و

جهت استفاده در تحليل هاي آتي موردبررسیATAMضعف پروسه ي واقع مي شوند. در اینجا، مراحل فازهاي ارزيابي )فازهای یک و دو( از

را به طور خالصه مرور می کنیم :ATAMپروسه ی )فازهای یک و دو( متشکل از نه مرحله هستند.ATAMفازهای تحلیل

مرحله اول تا شش در فاز اول انجام می شوند. در فاز دوم، همراه با نمایش های ذینفعان، مراحل یک تا شش خالصه شده و همچنین مراحل

هفت تا نه انجام می شوند. مراحل تحلیل اسما به صورت ترتیبی و آن هم مبتنی بر یک مجموعه از دستورات انجام می شود امام بعضی اوقات باید

اصالحات پویایی در زمان بندی ایجاد شود تا بتوان در دسترس بودن کارکنان و اطالعات مربوط به معماری تطبیق ایجاد کرد. هر ارزیابی

منحصربه فرد بوده و تیم ارزیابی ممکن است در صورت نیاز به مرحله اولیه برگردد یا یک مرحله را لغو کرده و مرحله بعدازآن را انجام دهد و

یا چندین مرحله را به صورت تکراری انجام دهد.

94

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

ATAMمرحله اول: نمایش را برای نمایندگان پروژه ارائهATAMدر مرحله اول، رهبر ارزیابی

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

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

ATAMخالصه هاي از مراحل پروسه ي ، در این مرحله، ATAMارائه ي

توضيح داده مي شود. اين مرحله به منظور حصولبرای شرکت کنندگان انجام ATAMاطمينان از آگاهي تمامي شرکت کنندگان از مراحل پروسه ي

در اين مرحله خروجی های هر مرحله، ATAMمي گردد. عالوه بر مراحل نيز مورداشاره قرار مي گيرد.

مرحله دوم: نمایش پیشران های )محرک( حرفه هر شخص درگیر در ارزیابی )نماینده پروژه و اعضای تیم( نیاز به درک زمینه سیستم و پیشران های منجر به توسعه سیستم را دارد.

ارائه ای که تصمیم گیرنده پروژه انجام می دهد باید مطالب زیر را تشریحکند:عملکردهای بسیار مهم سیستمهرگونه محدودیت های سیاسی، اجتماعی، مدیریتی و تکنیکی

مربوط به سیستماهداف حرفه و زمینه های مرتبط به سیستمذینفعان اصلیپیشران های معماری )یعنی اهداف خصوصیات کیفی اصلی که

معماری را شکل می دهند(.

مرحله سوم: نمایش معماری در این مرحله سرپرست معماری )یا تیم معماری(، معماری سیستم

را با سطح جزئیات مناسب تشریح می کند. میزان یا سطح جزئیات به چندین فاکتور بستگی دارد: چقدر از معماری طراحی و مستندسازی

شده است؟ چقدر زمان الزم است؟ ماهیت رفتار و خصوصیات کیفیچیست؟

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

همچنین خیلی مهم است که معمار حتما روش های معماری یا الگوهای

95

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

استفاده شده برای برآورده کردن نیازمندی ها را تشریح کند )بهتر است زمانی الگوها تشریح شوند که واژگان استفاده شده در معماری ساده

باشند(. به منظور استفاده از زمان محدود، ارائه معماری باید حاوی اطالعات مهم و اصلی باشد. یعنی اینکه باید ماهیت معماری نشان داده

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

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

دقیقه را برای ارائه معماری در60 اسالید و مدت 20این قالب نظر می گیرد.

اسالید، نیازمندی های اصلی معماری، خصوصیات3 تا 2در قابل اندازه گیری مرتبط با نیازمندی های اصلی و هرگونه روش ها، مدل ها و استانداردهای به کار گرفته شده برای تحقیق آن ها ارائه

می شوند. اسالید ذکر می شوند.8 تا 4اطالعات مهم معماری در نمودار متن: این نمودار، زمینه یا متنی را که سیستم در آینده در

آن قرار می گیرد و همچنین اشخاص و سیستم هایی که با آن هاتعامل خواهند داشت را مشخص می کند.

دید الیه بندی یا ماژول: در این قسمت باید مواردی از قبیل ماژول هایی ) که می توانند الیه یا زیرسیستم در نظر گرفته شوند(

که تجزیه عملکردی سیستم را نشان می دهند همراه با اشیاء، رویه ها، توابع و ارتباطات بین آن ها )به عنوان مثال، فراخوانی رویه،

درخواست متد و غیره( نمایش داده شوند.دید مؤلفه و اتصال: در این قسمت باید فرآیندها و نخ ها همراه با

همگام سازی، جریان داده و رویدادها که آن ها را به یکدیگر متصلمی کند، نشان داده شود.

دید استقرار: پردازشگرها، رسانه های ذخیره سازی و سنسورها و رسانه های داخلی همراه با رسانه های ارتباطی و شبکه هایی که

آن ها را به یکدیگر متصل می کنند باید در این قسمت نمایش داده شوند. همچنین باید مشخص شود که فرایندها بر روی کدام

پردازشگرها اجرا خواهند شد. اسالید، روش معماری، الگوها و تاکتیک های بکار6 تا 3در

گرفته شده، انواع خصوصیات کیفی و چگونگی برآورده شدنخصوصیات کیفی تشریح می شوند.

96

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

اسالید، مؤلفه های آماده برای استفاده به کاررفته و2 تا 1در همچنین چگونگی انتخاب و یکپارچگی آن ها تشریح می شود.

اسالید، یک الی سه سناریوی موارد کاربردی مهم3 تا 1در نمایش داده شود و اگر امکان پذیر باشد منابع استفاده در زمان

اجرا هر یک از آن ها نمایش داده شود. اسالید، یک الی سه سناریوی مربوط به تغییرات نمایش3 تا 1در

داده شود و اگر امکان پذیر باشد تأثیرات تغییرات بر ماژول هایدیگر و واسط ها نیز تشریح شود.

اسالید خطرات و پیامدهای معماری با توجه به3 تا 2در نیازمندی های اصلی معماری تشریح شود.

اسالید واژه نامه مربوط به سیستم نمایش داده شود.1در همان طور که از قالب معرفی شده قابل مشاهده است دیدهای

معماری اصلی ترین ابزار برای معماری هستند تا بتواند از طریق آن ها معماری را توصیف کند. نمودار متن، دیدهای مؤلفه و اتصال، دیدهای

الیه بندی، تجزیه، ماژول و دید استقرار تقریبا برای هر نوع روش ارزیابی سودمند هستند و معمار باید آن ها را در ارائه خود لحاظ کند. دیدهای

دیگر نیز می توانند سودمند باشند به شرط آن که شامل اطالعات مناسب در مورد معماری باشند، مخصوصا اگر آن ها شامل اطالعاتی در مورد

دستیابی به اهداف خصوصیات کیفی مهم سیستم باشند. بنابراین به عنوان قانون کلی، معمار باید دیدهایی را ارائه کند که درروند ایجاد

معماری به این نتیجه رسیده است که آن ها اهمیت زیادی دارند. درروند ارائه معماری، تیم ارزیابی به منظور آشکارسازی اطالعات به دست آمده از مستندات معماری و پیشران های معماری، سؤاالتی از

معمار خواهد پرسید. آنان همچنین به گفته های معمار گوش داده و الگوهاو تکنیک های به کار گرفته شده در سیستم را یادداشت می کنند.

مرحله چهارم: تعیین روش های معماری بر روی تحلیل معماری از طریق درک روش هایATAMتمرکز

معماری آن است. همان طور که می دانیم الگوهای معماری در زمینه شناخت روش هایی که هر یک خصوصیات کیفی خاصی را تحت تأثیر قرار

می دهند، بسیار کارآمد هستند. به عنوان مثال، الگوی الیه بندی قابلیت حمل را از طریق تحت تأثیر قرار دادن کارایی به ارمغان می آورد )باعث

کاهش کارایی می شود( و الگوی مخزن داده نیز معموال قابلیتگستردگی برای مصرف کنندگان و تولیدکنندگان داده به ارمغان می آورد. در این وضعیت، تیم ارزیابی دید خوبی نسبت به الگوها و روش های

97

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

بکار گرفته شده توسط معمار در طراحی سیستم دارد. آن ها مستند معماری را مطالعه کرده و همچنین ارائه معمار را نیز خواهند شنید. در

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

بدست آوردن نکات مهم مربوط به معماری که به صورت صریح ذکر نشده اند، ماهر باشند. در این مرحله کوتاه، تیم ارزیابی به سادگی الگوها و روش های به کار گرفته را فهرست می کند. درواقع فهرست توسط یک

منشی نوشته می شود و در اختیار همه قرار داده می شود تا آن رامشاهده کرده و پایه ای برای کارهای بعدی قرار دهند.

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

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

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

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

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

خاصی وجود ندارد که در آن ذکرشده باشد که آیا معماری کفایت می کند؟ یا قابلیت تغییرپذیری در چه روش هایی دارد؟ یا توان عملیاتی

چگونه باال رفته است؟ و یا به چه ماشین هایی متصل می شود؟ در این مرحله، اهداف خصوصیات کیفی از طریق یک سازوکار،

مشهور به "درخت سودمندی" به صورت کامل بیان می شوند. در این مرحله، تیم ارزیابی با تصمیم گیرندگان پروژه همکاری می کنند تا اهداف خصوصیات کیفی مهم سیستم را شناسایی، اولویت بندی و تصحیح کرده و سپس آن ها را با استفاده از سناریوها نشان دهند. درخت سودمندی به

این دلیل به کار گرفته شده است تا نیازمندی ها را عینی کرده و نماینده مشتری و معمار مجبور شوند تا نیازمندی های کیفی مناسب را که در

حال تالش برای فراهم کردن آن ها هستند را دقیق تر تعریف کنند. درخت سودمندی با سودمندی به عنوان ریشه آغاز می شود.

سودمندی یک عبارت از خوبی بودن کلی سیستم است. خصوصیات

98

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

کیفی، سطح دوم را شکل می دهند زیرا آن ها مؤلفه های سودمندی هستند. خصوصیات کیفی نام گذاری شده در نمایش پیشران های حرفه در

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

کنند(. گاهی اوقات هم ذینفعان نام هایی را برای خصوصیات کیفی استفاده می کنند که برای فرهنگ خودشان معنی دار است و زیاد

درجاهایی دیگر استفاده نمی شود. نام هایی که ذینفعان معرفی می کنند به شرطی مناسب خواهد بود که ذینفعان بتوانند تشریح کنند که معنی آن

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

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

بهبود مهم ترين اهداف مشخصه های كيفي سيستم است. در اینجا از يك درخت سودمندي استفاده مي كنيم، تا نیازمندی های مشخصه های كيفي سيستم كه عموما مجرد هستند را به صورت محسوس درآوريم. درخت

سودمندي، درختی است با گره ي ريشه ي سودمندي، كه در آن مشخصه های كيفي فرزندان ريشه هستند، كه هر يك درصورتی که بهبود

يابد و به چند مشخصه ی كيفي جداگانه تبديل شود، خود داراي چند فرزند )كه مشخصه های كيفي بهبودیافته هستند( خواهد بود. سناريوهاي كيفي، برگ هاي درخت خواهند بود. اين سناريوها شامل اجزاء محرك، محیط و

پاسخ می باشند. سناريوها بر اساس اهمیتشان، و نيز درجه ي سختي برآورده ساختن هر يك می توانند مورد رتبه بندي قرار گيرند. در مرحله

بعدی، سناريوها بر اساس اين رتبه ها موردبررسی قرار مي گيرند.

مرحله ششم: روش های تحلیل معماری در این مرحله، سناريوها به ترتيب نزولي اهميت موردبررسی قرار

مي گيرند. براي هر سناريو، مقدار و چگونگي پشتيباني سناريو از آن تعيين مي شود. در اين مرحله موارد خطرات و غير خطرات، و نيز نقاط

حساسيت و مصالحه ی مشخص می گردند. در انتهاي اين مرحله، وارد فاز با حضور ذينفعان6 تا 1دو مي شويم. در فاز دو، یک بار ديگر مراحل

پروژه مورد مرور قرار مي گيرند، تا به مرحله بعدی برسیم.

99

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

مرحله هفتم: طوفان ذهنی )جرقه زنی( و اولویت بندیسناریوها

سناریوهای اولیت بندی شده در درخت سودمندی، وقتی سناریوها جمع آوری شدند باید اولیت بندی شوند. از ذینفعان خواسته می شود سناریوها با رفتار یکسان و یا مرتبط با یک دغدغه یکسانی هستند را

ادغام کنند سپس آن ها به سناریوهایی که احساس می کنند خیلی مهم هستند رأی می دهند. هر ذینفع معادل سی درصد تعداد سناریو، رأی

می دهد. بنابراین اگر چهل سناریو به دست آمده باشد هر ذینفع شش رأیمی توانند بدهد.

آراء می توانند در هر روشی تخصیص یابد. به عنوان مثل یک ذینفع می تواند هر شش رأی خود را به یک سناریو دهد و یا اینکه به هر سناریو

یک رأی دهد. طوفان ذهنی)جرقه زنی( و رتبه سناریوها. هدف این مرحله، به دست

آوردن نيازمندي هاي كيفي موردنظر ذينفعان است. در این مرحله، سناريوهاي كيفي به صورت یک طوفان ذهنی توليد مي شوند و توسط ذينفعان با رأي گيري مورد رتبه بندي قرار مي گيرند. این سناريوها در

مرحله ي بعدي مورد تحليل قرار مي گيرند.

مرحله هشتم: تحلیل روش های معماری ،6تحليل رويكردهاي معماري. در اين مرحله مشابه مرحله ي

سناريوهاي تولیدشده توسط ذينفعان معماري در مرحله ي قبل مورد تحليل قرار مي گيرند. این مرحله مي تواند منجر به آشكار شدن

مورد تحليل قرار6بخش هايي از معماري گردد كه در مرحله ي نگرفته اند. تصميمات معماري كه منجر به تحقق هر سناريو مي گردند در

اين مرحله مشخص مي شوند.

مرحله نهم: نمایش نتایج در این مرحله، نتايج به دست آمده از تحليل هاي انجام شده در مراحل

قبل حضور ذينفعان ارائه مي گردد. اين نتايج شامل مستندات رويكردهاي معماري، مجموعه ي سناريوهاي كيفي و رتبه بندي آن ها از مرحله ي

طوفان ذهنی، درخت سودمندی، موارد خطرات کشف شده، موارد غير خطرات شناسایی شده، نقاط حساسيت و مصالحه به دست آمده در

مراحل تحليل، و شناسايي زمينه هاي خطرپذيري و ارتباط برقرار كردن است.2بين هر يك از آن ها و اهداف كاري به دست آمده در مرحله ی

100

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

معماری مستند شدهمجموعه ای از سناریوها و اولویت بن44دی آن ه44ا ک44ه از ذهن طوف44انی

به دست آمده اند.درخت سودمندیخطرات کشف شده غیر خطرات مستند شدهنقاط حساس و نقاط مصالحه یافت شده

ATAMانواع خروجی - 3-3-4

به سه دسته ي خروجي هاي اصلي، ATAMخروجي هاي پروسه ي خروجي هاي فرعي و خروجي هاي غيرقابل لمس تقسيم می گردد:

ATAMخروجي هاي اصلي، مقصود اصلي از اجراي پروسه ي -1

مي باشند. اين محصوالت شامل يك نمايش مختصر از معماري سيستم، فهرستي از اهداف كاري سيستم، نيازمندي هاي كيفي

سيستم كه به صورت مجموعه اي از سناريوهاي كيفي بيان گرديده اند، نگاشتي از تصميمات مهم معماري به نيازمندي هاي

كيفي سيستم، مجموعه اي از نقاط حساسيت، و مصالحه ی پیداشده، موارد خطرات و غير خطرات و نیز مجموعه ای از

زمينه هاي خطرپذيري مي باشند. از اين خروجي ها در توليد گزارشاستفاده مي شود. ATAMكتبي نهايي پروسه ي

خروجي هاي فرعي، به عنوان محصوالت فرعي فعاليت هاي-2 پروسه ي ارزيابي معماري توليد مي گردند. در اینجا چند مثال براي

اين محصوالت ذكر می کنیم. نمايشي از معماري سيستم كه در توليد مي گردد ممكن است از معماري اصلي ATAMخالل پروسه ي

سيستم برتر باشد. در چنين حالتي، اين نما از معماري سيستم به عنوان يك خروجي فرعي در نظر گرفته مي شود. سناريوهايي

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

در گزارش نهايي ارائه مي گردد مي تواند دليل برخي تصميماتاتخاذ شده در معماري سيستم را روشن سازد.

خروجي هاي غيرقابل لمس، محصوالتي مي باشند كه حائز اهميتي-3 حداقل برابر بااهمیت ساير انواع خروجي ها مي باشند. اغلب، اين

101

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

را توليد مي كنند. ATAMخروجي ها ماناترين نتايج پروسه ي به عنوان مثال، چند نوع از این خروجی ها را برمی شماریم. حس

بين ذينفعان معماري ايجاد ATAMمشاركتي كه در طی پروسه ي می شود از نمونه های اين نوع خروجي ها است. مسيرهاي ارتباطي ایجادشده بين معمار سيستم و ذينفعان نيز از اين دسته خروجي ها

است. ازجمله پراهميت ترين اين خروجي ها، فهم و درك بهتر معماري و نقاط قوت و ضعف آن از سوي تمام شرکت کنندگان

می باشد.ATAMپروسه ي نمایش مختصر از معماریبیان اهداف حرفهنیازهای کیفی برحسب مجموعه ای از سناریوهانگاشت تصمیمات معماری به نیاز کیفی

تصمیمات معماری می توانند برحسب خصوص44یاتی کیفی ک44ه آن ها پشتیبانی یا جلوگیری می کند، تفس44یر ش44وند. ب44رای ه4ر س44ناریوی کیفی موردبررس44ی قرارگرفت44ه دررون44د اعم44ال

ATAMتص44میمات معم44اری ک44ه منج44ر ب44ه دس44تیابی ب44ه آن ، می شود، مشخص می شوند.

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

نیازمندی ها خصوصیات کیفی معم44اریهزینه کارایی درزمینهزیاد است یا نه؟

مجموعه ای از خطرات و غیر خطرات به عنوان تصمیم معماری تعریف می شود که ATAMخطر در

منجر به نتایج نامطلوب در وضعیت نیازمندی های خصوصیات کیفی می ش44ود. ب44ه همین ص44ورت غ44یر خط44ر ن44یز تص44میم

102

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله معم44اری اس44ت ک44ه امن در نظ44ر گرفت44ه می ش44ود خط44رات شناسایی شده می توانند مبنایی را برای برنامه ک4اهش خط4ر

معماری شکل دهند.مجموعه ای از موضوعات خطرات

زم44انی ک44ه تحلی44ل کام44ل ش44د تیم ارزی44ابی کلی44ه خط44رات کشف شده را بررسی می کنند تا عن44اوینی را ب44ه دس44ت آورد که ضعف های سیستماتیک در معماری و یا ح44تی در فرآین44د و تیم معماری را مشخص می کند. اگر با این خط4رات برخ4ورد

نشود آن ها اهداف حرفه پروژه را تهدید خواهد کرد.

در ارزیابی معماری نرم افزارISO 9126مدل کیفیتی - 3-3-5

یکی از بهبود. پرداختیمATAMدر باال به توضیح کامل روش ارزیابی ISOهای این روش سناریوهای از پیش آماده شده، که توسط مدل

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

استفاده شده است. درواقع، این مدل، شكلي کلی برای ارزیابی کیفیت نرم افزار ارائه

می کند. یکی از نقاط قوت این استاندارد این است که قابلیت تطابق با بسیاری از سیستم ها را دارد؛ اما كاستي آن اين است كه شامل نکات

جزئی تر نمی شود. که در ارزیابی معماری نرم افزار به نکات جزئی پرداخته نمی شود. مهم ترین مزيت اين مدل اين است كه ويژگي هاي

كيفي داخلي و خارجي يك نرم افزار در آن تفکیک شده است. زیر ویژگی های که در اینISO 9126روش ارزیابی کیفیت نرم افزار

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

103

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

شاخص های ارزیابی کیفیت نرم افزار1-3شکل

مشخص شده و سناریوهای آماده برایISO9126جدول زیر صفات ارزیابی بیان کرده است. این سناریوها کمک به کامل کردن معماری نرم افزار از سمت شرکت های تولید نرم افزار می کند. همچنین برای

ارزیابی از دو قسمت امتیاز جدول یانگ و میزان دستیابی به آن ویژگی که در سه سطح ضعیف، متوسط و سخت موردبررسی قرار خواهد

خط ارزش دهی یانگ صفات کیفیتی موجود را با توجه به ارزشگرفت. ]کیفی مشخص شده در جدول به ارزش کمی معادل آن تبدیل می کند

15] .

104

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

جدول ارزیابی ویژگی کیفی عملیاتی1-3جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

مناسبعملیاتیبودن

توان وظیفه های موردنیازآیا میرا اجرا کرد؟

صحیحبودن

آیا نتایج صحیح هستند؟

قابلیتتعامل

آیا سیستم می تواند با دیگرسیستم ها تعامل داشته باشد؟

آیا سیستم از دسترسیامنیتغیرمجاز جلوگیری می کند؟

در ویژگی عملیاتی، ورودی سناریوها و الگوهای استفاده شده در معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود. برای

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

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

رای گیری و جدول یانگ نسبت به استفاده از الگوریتم های مناسب وتوضیح کامل ذینفعان معماری، به ویژگی ها امتیاز داده می شود.

جدول ارزیابی ویژگی قابلیت اطمینان2-3جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتاطمینان

تکمیلشدن

آیا باگذشت زمان خطاهاحذف شده اند؟

تلورانسخطا

آیا نرم افزار قادر به مدیریتخطاها است؟

قابلیتبازیابی

آیا نرم افزار بعد از این که مشکلی برای آن به وجود آمد،

اطالعات ذخیره نشده را نگهداری می کند و امکان ادامه

کار با نرم افزار وجود دارد؟ در ویژگی قابلیت اطمینان، ورودی سناریوها و الگوهای استفاده شده در معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود. برای این ویژگی تست های بکار گرفته شده در معماری مورد بررسی

قرار گرفته خواهد شد. بررسی الگوهای کنترل کیفیت و تضمین کیفیت بیان می شود، استفاده از تکنیک تراکنش، استفاده از آزمون های کنترل

خطا. در ارزیابی با استفاده از رای گیری و جدول یانگ نسبت به استفاده از الگوریتم های مناسب و توضیح کامل ذینفعان معماری، به

ویژگی ها امتیاز داده می شود.

105

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

جدول ارزیابی ویژگی کاربری3-3جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتکاربریفهم

آیا کاربر می فهمد که چگونه ازسیستم به راحتی استفاده کند؟

قابلیتیادگیری

آیا کاربر می تواند کار کردن باسیستم را یاد بگیرد؟

قابلیتعملیاتی

آیا کاربر می تواند بدون تالشزیاد از سیستم استفاده کند؟

قابلیتجذب

آیا ظاهر برنامه زیبا و جذاباست؟

در ویژگی کاربری، ورودی سناریوها و الگوهای استفاده شده در معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود. استفاده از یک اینترفیس واحد در کل پروژه توسط مدیر پروژه،

استفاده از کامپوننت های آماده، ناوبری در سیستم مانند تب در حرکت بین گزینه ها، ارائه کتابچه های راهنما در پایان تحویل نرم افزار، برگزاری کالس های آموزشی برای آموزش کاربران، ارائه می گردد. در ارزیابی با

استفاده از رای گیری و جدول یانگ نسبت به استفاده از الگوریتم های مناسب و توضیح کامل ذینفعان معماری، به ویژگی ها امتیاز داده

می شود.

جدول ارزیابی ویژگی کارآمدی4-3جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

رفتارکارآمدیزمان

آیا سیستم به سرعت بهدرخواست پاسخ می دهد؟

کاربردمنبع

آیا سیستم از منابع به صورتکاربردی استفاده می کند؟

ورودی سناریوها و الگوهای استفاده شده درکارآمدی،در ویژگی معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود.

بررسی در این زمینه، برنامه طراحی شده مناسب با منابع تصمیم گیرندگان پروژه است، الگویی برای زمان پاسخ، در نظر گرفته شده

است. در ارزیابی با استفاده از رای گیری و جدول یانگ نسبت به استفاده از الگوریتم های مناسب و توضیح کامل ذینفعان معماری، به

ویژگی ها امتیاز داده می شود.

جدول ارزیابی ویژگی قابلیت نگهداری5-3جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

106

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

قابلیتنگهداری

قابلیتتحلیل

آیا خطاها به راحتیشناخته شده و رفع می شوند؟

قابلیتتغییر

آیا نرم افزار به راحتی تغییرمی یابد؟

قابلیتپایداری

در صورت ایجاد تغییر، آیا نرم افزار به کارش ادامه

می دهد؟ قابلیت

آزمايش آیا به راحتی قابل آزمایش

است؟ ورودی سناریوها و الگوهای استفاده شده درنگهداریدر ویژگی

معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود. استفاده از الگو معماری سه الیه در برنامه نویسی باعث قابلیت تغییر

هاExceptionو پایداری در برنامه می شود، در تحلیل و طراحی برنامه از . در ارزیابی با استفاده از رای گیری و جدول یانگاستفاده شده است

نسبت به استفاده از الگوریتم های مناسب و توضیح کامل ذینفعانمعماری و اتخاذ تصمیم معماری، به ویژگی ها امتیاز داده می شود.

جدول ارزیابی ویژگی قابلیت حمل6-3جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتحمل

قابلیتسازگاری

آیا می توان نرم افزار را بهمحیط های دیگر انتقال داد؟

قابلیتنصب

آیا نرم افزار به آساني نصبمی شود؟

قابلیتتطبیق

آیا نرم افزار با استانداردهایحمل سازگار است؟

قابلیتجایگزینی

آیا می توان به آساني نرم افزار را به جای نرم افزارهای دیگر

جایگزین کرد؟ ورودی سناریوها و الگوهای استفاده شده درحملدر ویژگی قابلیت

معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود. استفاده از الگو کالینت سرور قابلیت سازگاری را بیشتر می کند،

استفاده از وب سرویس باعث تقویت این ویژگی می شود. در ارزیابی با استفاده از رای گیری و جدول یانگ نسبت به استفاده از الگوریتم های

مناسب و توضیح کامل ذینفعان معماری و اتخاذ تصمیم معماری، بهویژگی ها امتیاز داده می شود.

ISO 9126برای ارزیابی با استفاده از جداول باال یک بررسی کامل، مطرح شده است. اگر بخواهیم برای ارزیابی معماری نرم افزار ارائه شده

107

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

بکار ISO 9126دیدگاه جزئی تر داشته باشیم جدول زیر را برای قسمت برده شده است.

در جداول زیر، سواالت بیشتری برای سناریوهای معماری در صفاتISO9126مطرح شده است، این سواالت ازنظر امکانات فنی، رابط

کاربری و آموزش کاربران و... مطرح گردید شده است.

جدول ارزیابی پرمحتواتر ویژگی عملیاتی7-3جدول ویژگیاصلی

زیرویژگی

خطسؤاالتزمینهیانگ

پیاده سازی

مناسعملیاتی ب

بودن

معمار ی

نرم افزار

میزان دامنه جستجوی مفهومی ضبط و نگهداری فرآیندهای

پژوهشی کاربر ارائه گزارش های مختلف همچون

چاپ کاغذی یا چاپ دیجیتالی خروجی گرفتن از داده های متنوع نرم افزار عالوه بر داده های اصلی

)مثل: پاورقی ها، تصاویر،فهرست ها(

امکانا ت

فنی

برخورداری از یک موتور جستجوی قوی و سریع دارای

امکانات رتبه بندی جواب ها، نمایش های مختلف جواب، جستجو در تمام محتواها،

امکان، Stop Wordsساماندهي جستجوي کلمات با اعراب، امکان جستجو بر اساس ريشه کلمات و

يا ريشه و کلمه خاصمتفرق

هدرصد مقبولیت نزد کاربران

قابلیتهمکار

ی

معمار ی

نرم افزار

ارتباط یک نرم افزار با نرم افزارهای مرتبط پژوهشی و

دفتری

امکانا ت

فنی

به اشتراک گذاري اطالعاتکاربران و محققان

معمارصحت ی

نرم افزار

توان و دقت عمليات جستجو

درصد امنیت اطالعات برنامه وامنیتامنیت استفاده از الگوریتم های

رمزگذاری داده ها امنیت برنامه و جلوگیری از

دسترسی غیرمجاز

108

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

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

جدول ارزیابی پرمحتواتر ویژگی قابلیت اطمینان8-3جدول ویژگیاصلی

زیرویژگی

خطسؤاالتزمینهیانگ

پیاده سازی

قابلیتاطمینان

قابلیتبلوغ

امكانا ت

فني

رفع اشكاالت سيستمبه مرورزمان

معمار ی

نرم افزار

امکان رفع باگ ها و نواقص و اضافه کردن قابليت به آن از

الحاقيهايdll و هاpatchطريق

تلوران س

خطا

امکانا ت

فنی

توانايي در مديريت خطا و تضمينعملكرد صحيح نرم افزار

بررس ی

کیفیت

حداقلی باگ های برنامه

قابلیتبازیابی

معمار ی

نرم افزار

بازگشت به وضعیت امن درهنگام بروز اشکال

جدول ارزیابی پرمحتواتر ویژگی کاربری9-3جدول ویژگیاصلی

زیرویژگی

خطسواالتزمینهیانگ

پیاده سازی

قابلیتکاربریفهم

رابطکاربر

ان

ارائه پیام ها یا رفتار مناسب براساس کارکرد کاربر

گروه بندی درست منوهای برنامه اطالع رسانی به کاربر هنگام انجام

پردازش خاص همچون جستجو اطالع رسانی نسبت به وضعیت

جاری در طول زمان اجرایبرنامه

آموزش

اطالع رساني مناسب راجع به امكانات سيستم با استفاده از

و...هاhintمنوها، معما ری

نرم افزار

میزان تبعیت برنامه از عرف سایر نرم افزارها )راهبري كاربر

در صفحات برنامه، كليدهايميانبر و...(

دارا بودن راهنمای موضوعیآموز قابلیت

109

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

یادگیری

وجود کتابچه راهنما برای برنامه هاش وجود راهنمای برخط یا داخل برنامه برای کاربران و درصد

راهنمایی آن نسبت به صورتک ها و فهرست ها و وجود دمو

آموزشی و تبلیغاتی و آزمایشی، امکان جستجو در راهنمای کاربر،

وجود پیوند به راهنما در هر صفحه قابلیتعملیات

ی

امکانا ت

فنی

پشتیبانی برنامه از زبان فارسی فراهم آوردن محيط هاي پ ژوهشي

متعدد جهت آسان كردن تحقيقكاربران

معما ری

نرم افزار

امکانات اصلی برنامه در معرضدید کاربر

رابطکاربر

ان

میزان تسهیالت ویژه برای افرادناتوان

ایجاد تمایز بین محتوای مهم وغیر مهم

ناوبری: عدم لزوم به مهارت کاربران برای ناوبری، قابلیت

بازگشت به صفحه قبل و مرحله وجود پیوند برای رفتن به قبل،

یک سطح باالتر در هر صفحه، وجود پیوندي براي بازگشت به صفحه اصلی برنامه از تمامی 3صفحات، حداکثر عمق برنامه

است، مشخص بودن مکان کاربردر هر صفحه

امکان ناوبری بدون ماوس وجود ابزار ناوبری یکسان در تمام

صفحات سهولت دسترسی کاربر به

پاسخهای موردنظر تعداد کلیک موردنیاز تا رفعنیازهای اطالعاتی مخاطب

مناسب بودن چگونگي عملکردTAB

سهولت دسترسی کاربر بهپاسخهای موردنظر

تعداد زبان های پشتیبانی شده دربرنامه

معما ری

نرم اف

حفظ آخرین وضعیت برنامه جهتبارگذاری در اجرای بعدی

عدم وابستگی به ابزارهای جانبی

110

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

Officeمثل زار امکان دسترسیهای متنوع به متون

با توجه به نیاز کاربر وجود رابطه بین حوزه هایاطالعاتی مختلف با یکدیگر

سفارشی کردن عملکرد برنامه امکانات اصلی برنامه در معرض

دید کاربر قابلیت جذب

کردن- قابلیت جذبکاربر

رابطکاربر

ان

تنوع و استفاده درست و مناسب از کنترل ها )لیست، چک لیست،

رادیوباتن و...( تعداد فونت و رنگ )پیش فرض( و

تنظیمات متداول و سفارشی کردن قابلیت هایی مثل: فونت،

رنگ، سایز و انتخاب قلم های خوانا و با اندازه مناسب برای متن ها و عنوان ها و عدم ایجاد

مشکل توسط رنگ ها در خواناییمتن

میزان استفاده از المان های بومیو مذهبی در رابط های کاربری

زیبایی رابط کاربر با استفاده ازاصول هنري و زيبايي شناختي

تناسب وضعیت چیدمان صورتک ها و آیتم ها در صفحات )پیچیدگی و کیفیت جداول، استفاده مؤثر از الیه ها، استفاده از فضا، استفادهاز تقسیم کننده ها و جداکننده ها(

هماهنگی رابط کاربر در کل برنامه و وجود یک قالب ثابت در

تمام برنامه

جدول ارزیابی پرمحتواتر ویژگی کارآمدی10-3جدول ویژگیاصلی

زیرویژگی

خطسواالتزمینهیانگ

پیاده سازی

رفتارکارآمدیزمان

معمار ی

نرم افزار

پاسخ گويي سريع به جستجويكاربر

کاربردمنبع

رابطکاربرا

ن

میزان پیکربندی رابط کاربری ازخارج برنامه به صورت منبع )

Resource) میزان استفاده صحیح و مناسبامنیت

(Buffering & cashingاز... )قابلیت استفاده در شبکه

ممانعت از توقف اجرا به دلیلامکانا

111

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

تفنی

پردازش خاص

معمار ی

نرم افزار

استفاده بهينه از تمام محيط ميزكار

جدول ارزیابی پرمحتواتر ویژگی قابلیت نگهداری11-3جدول ویژگیاصلی

زیرویژگی

خطسواالتزمینهیانگ

پیاده سازی

قابلیتنگهداری

قابلیتتحلیل

امكانا ت

فني

شناسايي صحيح خطاهاي احتمالي و اطالع رساني مناسب

به كاربر قابلیت

تغییرمعما ری

نرم افزار

میزان توسعه پذیری برنامه )مانند(Add-Insامکان اضافه شدن

فراهم بودن امکان نصب مجموعه اي از کتب و منابع

مختص يک موضوع توسط کاربرامكانا

تفني

ارائه راهكارهاي مناسب و متنوعجهت به روزرسانی نرم افزار

قابلیت گرفتن اطالعات کاربران و تأثیرپذیری برنامه از نظرات

کاربران قابلیتپایداری

معما ری

نرم افزار

نسخه پذیری و پشتیبانی ازنسخه های مختلف

كاركرد صحيح نرم افزار بعد از به روزرسانی برنامه اجرايي و يا

اطالعات قابلیت

آزمايش-آزمون پذی

ری

امكانا ت

فني

دارا بودن امکان آزمايش برنامه

جدول ارزیابی پرمحتواتر ویژگی قابلیت حمل12-3جدول ویژگیاصلی

زیرویژگی

خطسواالتزمینهیانگ

پیاده سازی

قابلیتحمل

قابلیتسازگار

ی

معمار ی

نرم افزار

قابلیت انعطاف برنامه ها با انواعمحيط ها

قابلیتنصب

معمار ی

نرم افزار

مراحل نصب و سهولت فعال سازی نرم افزارها و استفاده

)عدم وابستگی به نوع سیستم عامل ها و نرم افزارهای جانبی یا مدیریت آن در صورت

112

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

وابستگی( قابلیتتطبیق

معمار ی

نرم افزار

میزان استعداد تبدیل بهXMLقالب های استاندارد مانند

امکانا ت

فنی

تنوع در حامل برنامه به منظور استفاده از استانداردها و

مزیت های حامل) گویایی -استاندارد (

قابلیتجایگزین

ی

امکانا ت

فنی

امکان جایگزینی برنامه های دیگربا این برنامه

ISO9126جدول ارزیابی صفات 13-3جدول

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

کیفی و همچنین سناریوها از جدول ارزش دهی یانگ استفاده شده است. میزان دستیابی به این سناریو در عمل به سه سطح ساده، متوسط و

سخت معماری نرم افزار ارزیابی شده است. در قسمت بعدی برایآشنایی بیشتر با سناریو به توضیح سناریو پرداخته شده است.

سناریو- 3-3-6

هر سناریوی خصوصیات کیفی، یک نیازمندی مرتبط با خصوصیات کیفیرا بیان می کند.

یک سناریوی خصوصیت کیفی از شش بخش تشکیل شده است:

1منبع تحریک

منبع تحریک شامل بعضی از موجودیت ها )مانند انسان، سیستم کامپیوتری یا هر محرک دیگر( است که یک تحریک را ایجاد می کند.

به عبارت بهتر مولد یک تحریک است.

2محرک

محرک شرایطی است که اگر در سیستم ایجاد شود الزم استموردبررسی قرار بگیرد.

1 Source of Stimulus2 Stimulus

113

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

1محیط

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

در حال اجرا با بارکاری زیاد یا در هر وضعیت دیگری قرار داشتهباشد.

2فراورده

فرآورده موجودیتی است که هدف تحریک است. فرآورده ممکناست که کل سیستم یا بخشی از آن را در نظر گرفته شود.

3پاسخ

پاسخ عبارت است از فعالیتی که سیستم بعد از تحریک شدنانجام می دهد.

4معیار پاسخ

وقتی که پاسخی داده می شود آن باید به روشی مشخص اندازه گیری شود تا نیازمندی های موردنظر بتواند مورد آزمایش

قرار بگیرند. در حالت کلی دو نوع سناریوی خصوصیات کیفی وجود دارد. اولی

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

هستند که برایConcreteدیگری سناریوی خصوصیات کیفی عینی سیستم های خاص مشخص می شوند. مشخصات خصوصیات کیفی

به صورت مجموعه ای از سناریوهای عمومی بیان می شود، که برای تبدیل کردن مشخصات خصوصیات کیفی به نیازمندی های خصوصیات کیفی

.[16]مرتبط با یک سیستم خاص، نیاز به سناریوهای عینی است

بخش های اصلی سناریوی خصوصیات کیفی1-3شکل 1 Environment2 Artifact3 Response4 Response Measure

114

فصل سوم: بهبود روش ارزیابی معماری نرم افزار... روش پیشنهادی برای حل مسئله

به عنوان مثال یک سناریو که کمک گرفته از جدول باال از قسمت ویژگی قابلیت حمل زیر ویژگی قابلیت سازگاری قسمت معماری

قابلیت انعطاف برنامه ها با انواع محيط هانرم افزار جمله : سناریوی به این صورت نوشته می شود بنا به اهمیت موضوع در

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

چگونه است

115

4. ارزیابیفصل چهارم:

معماری نرم افزار

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

نمونه یک ارزیابی معماری-4-1

مقدمه- 4-1-1

در فصل قبل روش پیشنهادی ارائه داده شد و در این فصل به بررسی و ارزیابی دو معماری نمونه با روش پیشنهادی پرداخته شده

است. سند حاضر به بیان مولفه های سطح باالی سامانه شبیه سازیترافیک شبکه ملی اطالعات می پردازد.

نحوه سازماندهی معماری- 4-1-2

" که مدلی مشهور در4+1سند معماری حاضر، بر اساس مدل " سازماندهی مولفه های معماری سیستم است سازماندهی شده است.

این مدل شامل دیدگاه های مختلفی همچون دیدگاه های منطقی،پردازش، پیاده سازی، استقرار و موارد کاربردی است.

اهداف و محدودیت های معماری- 4-1-3

این بخش از سند، نیازمندی های معماری سیستم تشریح می نماید.

بستر فنی سامانهاین سامانه یک س44امانه تحت ش44بکه اس44ت ک44ه از معم44اری

کالینت-سرور استفاده می کن44د. ل44ذا در س44مت س44رور، ب44رای برق44راری ارتب44اط

TCP/IP روی بس4444تر httpکالینت، از پروتک4444ل اس4444تاندارد استفاده می ش44ود. همچ44نین س44رویس دهن44ده وب ب44ر روی

به درخواست های کاربران پاسخ خواهد80پرت استاندارد Internet Explorerداد. همچنین در سمت کالینت، مرورگرها

ب44ه ب44اال پش44تیبانی خواهن44د3 نسخه Firefox به باال 7نسخه شد..

117

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

امنیتجهت تض444مین دسترس444ی امن ب444ه سیس444تم ش444بکه ملی

اطالعات، مکانیزم تصدیق اصالت کاربران و مک44انیزم ه44ایدسترسی مبتنی بر نقش استفاده می شود.

ذخیر سازیب44رای ذخ44یره س44ازی داده ه44ا از پایگ44اه داده رابط44ه ای

MySQL.استفاده می شود

قابلیت اطمینان و در دسترس بودن س44اعته24این سیستم به غیر از مواقع بحرانی به ص44ورت

روز هفته قابل دسترسی خواهد بود.7و در

دیدگاه موارد کاربردی- 4-1-4

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

ها بیان می نماید. شکل اینuse-caseاین بخش معماری را از دیدگاه های سیستم نمایش میusecaseدیدگاه را در قالب یکی از جامع ترین

هایusecase در واقع یک مورد کاربرد مادر است که usecaseدهد. این تشریحBusiness Usecase Spacificationسطح پایین تر از آن در سند

شده اند.

118

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

دیاگرام موارد کاربردی )سطح باال(1-4شکل

دیدگاه منطقی- 4-1-5

معماری سامانه شبیه سازی ترافیک شبکه ملی، از سه الیه استانداردو معروف تشکیل شده است که ذیل تشریح شده اند:

119

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

الیه نمایش: این الیه حاوی عناصری است که مسئول فراهم آوردن فرم هایی است که برای کاربران انسانی سیستم اجرا می گردند و

معموال برای برقراری ارتباط کاربر با سیستم از آنها استفاده می شود. از جمله این عناصر می توان به مولفه های موجود در واسط گرافیکی

کاربر اشاره نمود. الیه منطق کسب و کار: این الیه شامل عناصر مسئول برای انجام انواع پردازش های سازمان و کسب و کار و نیز به کار بستن قواعد و

قانون های موجود در آنجاست. این الیه به عنوان هسته اصلی نرم افزار تلقی می شود و تمامی عملیات منطقی و محاسباتی مورد نیاز برای

ایجاد گزارش ها الزم، در این الیه از نرم افزار انجام می شود. این الیه شامل زیر الیه های گوناگون است تا با استفاده از آنها بتواند با بهره

گیری از داده های ورودی توسط کاربر و سناریو های تعریف شده توسط او و داده های موجود در فایل ها و پایگاه های داده مرتبط به نرم افزار

محاسبه های الزم را به انجام برساند. الیه دسترسی به داده ها: این الیه شامل عناصر مسئول برای فراهمآوردن دسترسی به منبع داده ها همانند پایگاه های داده رابطه ای است.

دیاگرام دیدگاه منطقی )سطح باال(1-4شکل

در ادامه به تشریح اجمالی مولفه های اساسی الیه کسب و کار پرداختهشده است.

traffic aggregatorمولفه این مولفه از داده های ورودی توسط کاربر و داده های موجود در

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

120

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار شاخص ها ذکر شده است با هم جمع می کند تا ترافیک هر مسیریاب لبه

را محاسبه نماید.

Routingمولفه زیرالیه الگوریتم مسیریابی بخشی از هسته نرم افزار است که

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

ها متنی در اختیار کاربر قرار می گیرد.

دیاگرام فعالیت برای الگوریتم مسیریابی2-4شکل

121

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

configuration managerمولفه این مولفه وظیفه ی نگهداری پارامترهای مربوط به وضعیت فعلی

را برعهده دارد. منظور از وضعیت فعلی شبکهIP/MPLSشبکه ی پارمترهایی نظیر جمعیت استان ها، ضریب نفوذ سرویس های مختلف ارایه شده در هر استان ) روی هر مسیریاب لبه(، تعداد دانشگاه ها و مراکز آموزش عالی، پهنای باند اختصاصی ارایه شده در هر مسیریاب

لبه و اطالعات مشابه است.

scenario managerمولفه وظیفه مولفه مدیریت سناریو، بارگزاری سناریوهای ذخیره شده در

حافظه، مدیریت سناریوی بارگذاری شده و مدیریت ذخیره سناریوها روی دیسک است. ایجاد ورودی مناسب برای مولفه جمع بندی ترافیک

یکی از وظایف اصلی این زیرالیه محسوب می گردد.

topology managerمولفه مولفه مدیریت توپولوژی شبکه ظیفهی ایجاد توپولوژی ذخیره شده

و تحویل آن به الیه نمایش، برای نمایش به کاربرconfigutationدر فایل است. در این الیه محل قرار گرفتن مسیریاب های هسته، لبه و هسته

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

جغرافیایی مورد نیاز را برای الیه نمایش انجام می دهد. یکی از مهمترین سناریوهای کاربردی این مولفه سناریوی "تغییر توپولوژی پیش فرض"

است که در دیاگرام زیر نمایش داده شده است.

122

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

دیاگرام مربوط به سناریو تغییر توپولوژی پیش فرض3-4شکل

feasibility checkerمولفه این مولفه وظیفه اعتبار سنجی یک سناریو از نقطه نظر عملیاتی

بودن در شبکه ملی اطالعات را داراست.

report model managerمولفه مولفه تولید گزارش، با بهره گیری از نتایج محاسبات انجام شده در هسته ی اصلی محاسباتی نرم افزار و انجام محاسبات روی داده های خام موجود، مدل داده ای مربوط به گزارش ها را در سطوح مختلف

ایجاد می نماید و برای نمایش از طریق مولفه ارتباط با واسط کاربری،.به الیه نمایش ارسال می کند

دیدگاه پیاده سازی- 4-1-6

در این بخش، نرم افزار نسخه اولیه ای که تا کنون به عنوان یکprototype .توسعه داده شده، تبیین شده است seguence diagramمربوط به

123

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

تغییر توپولوژی در نرم افزار فعلی به صورت زیر می باشد:

دیاگرام توالی مربوط به تغییر توپولوژی پیش فرض1-4شکل

دیدگاه استقرار- 4-1-7

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

از نظرapplication server و database serverشکل مشخص شده است، فیزیکی روی یک سرور نصب می شوند.

124

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

نمای کلی استقرار سامانه1-4شکل

مدل داده- 4-1-8

، مربوط به سامانه شبیه سازی ترافیک شبکهERDنسخه اولیه نمودار ملی اطالعات در شکل زیر نمایش داده شده است، این نمودار در نسخه

فعلی نرم افزار استفاده شده است.

نسخه فعلی نرم افزار شبیه سازی ترافیک شبکه ملی اطالعاتERشمای 1-4شکل

125

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

کیفیت و کارآیی- 4-1-9

عدد می5تعداد کاربران همزمان سیستم در نسخه اولیه باشد.

در24*7سیستم به جز در مواقع بحرانی به صورت دسترس خواهد بود.

امنیت سامانه در حوزه نرم افزاری، توسط استفاده از مکانیزم های مدیریت کاربران و تصدیق اصالت آن ها

تامین می شود. امنیت سامانه در حوزهLANداخل سازمان بر عهده

کارشناس شبکه سازمان خواهد بود.سناریوهای تست نرم افزار متعاقبا در سند تست اعالم

خواهند شد و کیفیت شبیه سازی نرم افزار توسط اینتست ها قابل ارزیابی خواهد بود.

ارزیابی معماری ارائه شده در باال به صورت زیر مکتوبشده است:

ارزیابی معماری نرم افزار سامانه شبیه سازی ترافیک شبکه ملی اطالعات است. در ابتدا فاز اول، رهبر ارزیاب با مدیر تصمیم گیرندگان

معماری برای جلسه اول با این گروه تماس برقرار کرده و جلسه اول را برنامه ریزی می کنند. در فاز دوم، تیم ارزیابی با گروه تصمیم گیرندگان

پروژه جلسه اول را تشکیل می دهند. در مرحله اول، رهبر ارزیاب را به تصمیم گیرندگان پروژه ارائه می دهد. در مرحلهATAMمراحل

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

های سیستم را تشریح کرده است.بستر فنی سامانه

oاین سامانه یک سامانه تحت شبکه است که از معماری کالینت سرور استفاده می کند. لذا در سمت سرور، برای برقراری ارتباط کالینت، از پروتکل های

استفاده می شود.tcp/ip روی بستر httpاستاندارد 80همچنین سرویس دهند وب بروی پرت استاندارد

به درخواست های کاربران پاسخ خواهد داد. oهمچنین در سمت کالینت مرورگرهای اکسپورور

126

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

نسخه هفت به باال و فایرفاکس نسخه سه به باالپشتیبانی خواهد شد.

امنیتoجهت تضمین دسترسی امن به سیستم شبکه ملی

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

ذخیره سازیoبرای ذخیره سازی داده ها از پایگاه داده رابطه ای

my sql.استفاده می شود قابلیت اطمینان و در دسترس بودن

o 24این سیستم به غیر از مواقع بحرانی به صورت روز هفته قابل دسترسی خواهد بود.7ساعت و در

مرحله سوم معماری پیشنهادی بررسی شد. در مرحله چهارم بعد از نمایش معماری، تیم ارزیابی تصمیم های معماری موجود بعالوه مواردی

که در روند پیش ارزیابی از مستند معماری درک شد در روند ارزیابی مکتوب کرده اند. از معماری کالینت سرور استفاده شده است و همچنین مکانیزم تصدیق اصالت کاربران و مکانیزم های دسترسی مبتنی بر نقش

استفاده می شود. . قابل دسترسی در تمام ساعات روز کهmy sqlپایگاه داده رابطه ای

این اطالعات در مرحله پنچم و ششم و هفتم و هشتم مورد بررسی و امتیاز قرار گرفت. در ادامه مرحله پنجم: ایجاد درخت سودمندی

خصوصیات کیفی در جداول زیر است و معماری نمونه یک ارزیابی شده اگر درباره صفت کیفی خاصی راه حل و الگو بررسیاست. در ارزیابی کم و متوسط در جداول ارزیابی شده است.3نشده است، نمره

جدول ارزیابی چرخه حیات محصول نمونه یک1-4جدول نداردداردچرخه حیات محصول

نداردچرخه حیات محصول مشخص است؟مخاطبین ساختار کلی چرخه حیات تولد بلوغ مرگ مشخص شده

است؟ندارد

جدول ارزیابی ویژگی کیفی عملیاتی نمونه یک2-4جدول پیاده ساز خطسؤاالتزیر ویژگی ویژگی

127

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

ییانگاصلیعملیات

ی مناسب

بودن توان وظیفه های( آیا می1

موردنیاز را اجرا کرد؟متوس کم3

ط صحیحبودن

متوس کم3( آیا نتایج صحیح هستند؟2ط

قابلیتتعامل

( آیا سیستم می تواند با دیگر3سیستم ها تعامل داشته باشد؟

متوس کم3ط

( آیا سیستم از دسترسی4امنیتغیرمجاز جلوگیری می کند؟

متوس زیاد5ط

در ویژگی عملیاتی ورودی سناریوها و الگوهای استفاده شده درمعماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود.

برای سوال اول تا سوم راه حلی پیشنهاد نشده، بنابراین به اینسواالت نمره سه داده شده است.

برای سوال چهارم این مطلب ارائه شد که، امنیت سامانه در حوزه نرم افزاری، توسط استفاده از مکانیزم های مدیریت کاربران و

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

مکانیزم های دسترسی مبتنی بر نقش استفاده می شود، و نمره پنچ،پیاده سازی متوسط داده شد.

جدول ارزیابی ویژگی کیفی قابلیت اطمینان نمونه یک3-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتاطمینا

ن

تکمیلشدن

( آیا باگذشت زمان خطاها1حذف شده اند؟

متوس کم3ط

تلورانسخطا

( آیا نرم افزار قادر به2مدیریت خطاها است؟

4 متوس

ط

متوسط

قابلیتبازیابی

( آیا نرم افزار بعد از این که3 مشکلی برای آن به وجود

آمد، اطالعات ذخیره نشده را نگهداری می کند و امکان

ادامه کار با نرم افزار وجوددارد؟

4 متوس

ط

متوسط

در ویژگی قابلیت اطمینان ورودی سناریوها و الگوهای استفاده شدهدر معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود. برای سوال اول هیچ راه حلی ارائه نگردید و به این سوال نمره سه

داده شد. امتیاز،Exception handlingبرای سوال دو م و سوم با استفاده از الگوی چهار به سواالت این ویژگی داده شده است.

128

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

جدول ارزیابی ویژگی کیفی کاربری نمونه یک4-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتکاربریفهم

( آیا کاربر می فهمد که1 چگونه از سیستم به راحتی

استفاده کند؟

4 متوس

ط

متوسط

قابلیتیادگیری

( آیا کاربر می تواند کار2کردن با سیستم را یاد بگیرد؟

4 متوس

ط

ساده

قابلیتعملیاتی

( آیا کاربر می تواند بدون3 تالش زیاد از سیستم استفاده

کند؟

4 متوس

ط

ساده

قابلیت جذبکردن

( آیا ظاهر برنامه زیبا و4جذاب است؟

4 متوس

ط

ساده

در ویژگی کاربری ورودی سناریوها و الگوهای استفاده شده درمعماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود. برای کل سواالت این ویژگی راه حل، استفاده از یک استاندارد و

اینترفیس واحد به کل سواالت، امتیاز چهار داده شده است.

جدول ارزیابی ویژگی کیفی کارآمدی نمونه یک5-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

کارآمدی

رفتارزمان

( آیا سیستم به سرعت به1درخواست پاسخ می دهد؟

متوس زیاد5ط

کاربردمنبع

( آیا سیستم از منابع2 به صورت کاربردی استفاده

می کند؟

متوس زیاد5ط

ورودی سناریوها و الگوهای استفاده شده درکارآمدیدر ویژگی معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود.

برای این ویژگی سیستم بصورت هفت در هفت روز بصورت بیست وچهار ساعته، در دسترس است. به سواالت این ویژگی امتیاز پنچ داده

شده است.

جدول ارزیابی ویژگی کیفی قابلیت نگهداری نمونه یک6-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتنگهدار

قابلیتتحلیل

( آیا خطاها به راحتی1شناخته شده و رفع می شوند؟

متوس زیاد5ط

129

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

قابلیتیتغییر

( آیا نرم افزار به راحتی تغییر2می یابد؟

متوس زیاد5ط

قابلیتپایداری

( در صورت ایجاد تغییر، آیا3 نرم افزار به کارش ادامه

می دهد؟

متوس زیاد5ط

قابلیتآزمايش

( آیا به راحتی قابل آزمایش4است؟

متوس کم3ط

ورودی سناریوها و الگوهای استفاده شده درنگهداریدر ویژگی معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود.

برای سه سوال اول راه حل استفاده از معماری کالینت سرور، امتیاز Exception handling و همچنین استفاده از tcp/ipاستفاده از شبکه

پنچ با پیاده سازی متوسط داده شده است. برای سوال چهارم راه حلی ارائه نشده است و به این سوال نمره سه

داده شده است.

جدول ارزیابی ویژگی کیفی قابلیت حمل نمونه یک7-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتحمل

قابلیتسازگاری

( آیا می توان نرم افزار را به1محیط های دیگر انتقال داد؟

متوس کم3ط

قابلیتنصب

( آیا نرم افزار به آساني2نصب می شود؟

4 متوس

ط

متوسط

قابلیتتطبیق

( آیا نرم افزار با3 استانداردهای حمل سازگار

است؟

4 متوس

ط

متوسط

قابلیتجایگزینی

( آیا می توان به آساني4 نرم افزار را به جای

نرم افزارهای دیگر جایگزینکرد؟

متوس کم3ط

ورودی سناریوها و الگوهای استفاده شده درحمل قابلیتدر ویژگی معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود.

برای سوال اول و چهارم هیچ الگوی استفاده نشده است و به اینسواالت نمره سه داده شد.

برای سواالت دو و سه، استفاده از الگو معماری کالینت سرور و شبکهtcp/ipنمره چهار داده شده است. ارائه گردید که

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

130

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار های بیان شده امتیاز مورد نظر خود را دریافت کرده اند. تمام نقاط بکار

شناسایی شد نقاط امن سیستم است. در فاز هشتم معمار طبق معماری ارائه شده تصمیمات معماری خود

را برای ارضا سناریوهای که در اولویت فاز های قبل قرار گرفت بیانکرد.

همانطور که در جداول مرحله پنجم آورده شده است نتیجه ارزیابی کم و3 اگر درباره صفت کیفی دیگر بررسی نشده است، نمره بیان شد.

متوسط در جدول باال ارزیابی شده است.

ارزیابی معماری نمونه دو-4-2

برای ارزیابی معماری نرم افزار به دست آمده از شرکت عصر اندیشه در قسمت جدول به صورت زیر عمل می کنیم. جلسه ی در مکان شرکت

پروژه توسعه سيستم مدیریت چرخه عمربه ارزیابی معماری نرم افزار ای برق هرمزگان برگزار شد. در روند ارزیابیتجهیزات شبکه و نیروگاهه

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

معماری نرم افزار نمونه دوم در بخش دوم ساختار معماری پیشنهادی که درباره محدودیت ها و اهداف نرم افزار بیان شده را با استفاده از

جدول ارائه شده به ارزیابی آن می پردازیم. ازجمله امنیت و غیره. در ادامه معماری چهار بعالوه یک را شرح داده

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

اگر درباره صفت کیفی خاصی راه حل و الگو بررسی نشدهارزیابی کم و متوسط در جداول ارزیابی شده است.3است، نمره

جدول ارزیابی چرخه حیات محصول نمونه دو1-4جدول نداردداردچرخه حیات محصول

نداردچرخه حیات محصول مشخص است؟مخاطبین ساختار کلی چرخه حیات تولد بلوغ مرگ مشخص شده

است؟ندارد

131

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

کیفی کارایی نمونه دوویژگی جدول ارزیابی 2-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

مناسبعملیاتیبودن

توان وظیفه های( آیا می1موردنیاز را اجرا کرد؟

4 متوس

ط

متوسط

صحیحبودن

4( آیا نتایج صحیح هستند؟2متوس

ط

متوسط

قابلیتتعامل

( آیا سیستم می تواند با3 دیگر سیستم ها تعامل داشته

باشد؟

متوس کم3ط

( آیا سیستم از دسترسی4امنیتغیرمجاز جلوگیری می کند؟

متوس زیاد5ط

در ویژگی عملیاتی ورودی سناریوها و الگوهای استفاده شده درمعماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود.

استفاده از الگو معماری سه الیه ارائهبرای سوال یک و دو، راه حل و پیاده سازی متوسط ارزیابی شد.4گردید که به نمره

برای سوال چهارم راه حل به این گونه بیان شد، معماری سیستم به نحوی خواهد بود كه امكان برقراری ارتباط و استفاده از اطالعات

اداره برق هرمزگان در صورت داشتنموجود در سیستم های سایر مجوز، دسترسی به آن سیستم ها را داشته باشد، کلیه پسوردهای

کهکاربران در پایگاه داده به صورت رمزنگاری شده نگهداری می شود. و پیاده سازی متوسط ارزیابی شد.5به نمره

چون نسبت به قابلیت تعامل راه حلی ارائه نگردید، نمره سه داده شد.

کیفی قابلیت اطمینان نمونه دوویژگی جدول ارزیابی 3-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتاطمینان

تکمیلشدن

( آیا باگذشت زمان خطاها1حذف شده اند؟

4 متوس

ط

متوسط

تلورانسخطا

( آیا نرم افزار قادر به2مدیریت خطاها است؟

4 متوس

ط

متوسط

قابلیتبازیابی

( آیا نرم افزار بعد از این که3 مشکلی برای آن به وجود

آمد، اطالعات ذخیره نشده را نگهداری می کند و امکان

ادامه کار با نرم افزار وجود

4 متوس

ط

متوسط

132

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

دارد؟ در ویژگی قابلیت اطمینان ورودی سناریوها و الگوهای استفاده شدهدر معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود.

برای سه سوال باال راه حل، استفاده از الگو معماری سه الیه و ارائه گردید و امتیاز چهار به اینException handlingبکارگیری از الگوی

سواالت داده شد.

کیفی کاربری نمونه دوویژگی جدول ارزیابی 4-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتکاربریفهم

( آیا کاربر می فهمد که1 چگونه از سیستم به راحتی

استفاده کند؟

متوس کم3ط

قابلیتیادگیری

( آیا کاربر می تواند کار2کردن با سیستم را یاد بگیرد؟

ساده زیاد5

قابلیتعملیاتی

( آیا کاربر می تواند بدون3 تالش زیاد از سیستم استفاده

کند؟

ساده زیاد5

قابلیت جذبکردن

( آیا ظاهر برنامه زیبا و4جذاب است؟

4 متوس

ط

متوسط

در ویژگی کاربری ورودی سناریوها و الگوهای استفاده شده درمعماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود.

برای سوال اول راه حلی ارائه نشد بنابراین به این سوال نمره سهداده شد.

برای سوال دوم و سوم، برگزاری آموزش برای کاربران و ارائه کتابچه و پیاده سازی متوسط ارزش دهی شد.5راهنما برای نرم افزار امتیاز

برای سوال چهارم استفاده از یک اینترفیس واحد و مناسب ارائهگردید که نمره چهار و پیاده سازی متوسط داده شد.

کارآمدی نمونه دوکیفیویژگی جدول ارزیابی 5-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

رفتارکارآمدیزمان

( آیا سیستم به سرعت به1درخواست پاسخ می دهد؟

متوس کم3ط

کاربردمنبع

( آیا سیستم از منابع2 به صورت کاربردی استفاده

می کند؟

متوس کم3ط

ورودی سناریوها و الگوهای استفاده شده درکارآمدیدر ویژگی

133

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود. برای دو سوال باال راه حلی ارائه نشده است، بنابراین نمره سه ارزش

دهی شد.

کیفی قابلیت نگهداری نمونه دوویژگی جدول ارزیابی 6-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتنگهداری

قابلیتتحلیل

( آیا خطاها به راحتی1شناخته شده و رفع می شوند؟

متوس زیاد5ط

قابلیتتغییر

( آیا نرم افزار به راحتی تغییر2می یابد؟

متوس زیاد5ط

قابلیتپایداری

( در صورت ایجاد تغییر، آیا3 نرم افزار به کارش ادامه

می دهد؟

متوس زیاد5ط

قابلیتآزمايش

( آیا به راحتی قابل آزمایش4است؟

4 متوس

ط

متوسط

ورودی سناریوها و الگوهای استفاده شدهنگهداریدر ویژگی قابلیت در معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود.

و معماریException handlingبرای سوال اول تا سوم استفاده از الگو کالینت سرور ارائه گردید که به این سوال نمره پنچ و پیاده سازی

متوسط داده شده است. برای سوال چهارم استفاده از کامپوننت ها و کالس های مجزا ارائه شد

که نمره چهار دریافت کرد.

کیفی قابلیت حمل نمونه دوویژگی جدول ارزیابی 7-4جدول ویژگیاصلی

خطسؤاالتزیر ویژگییانگ

پیاده سازی

قابلیتحمل

قابلیتسازگاری

( آیا می توان نرم افزار را به1محیط های دیگر انتقال داد؟

4 متوس

ط

متوسط

قابلیتنصب

( آیا نرم افزار به آساني2نصب می شود؟

4 متوس

ط

متوسط

قابلیتتطبیق

( آیا نرم افزار با3 استانداردهای حمل سازگار

است؟

متوس کم3ط

قابلیتجایگزینی

( آیا می توان به آساني4 نرم افزار را به جای

متوس کم3ط

134

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

نرم افزارهای دیگر جایگزینکرد؟

ورودی سناریوها و الگوهای استفاده شده درحمل قابلیتدر ویژگی معماری، توسط تیم ذینفعان معماری و تیم معمار انجام می شود.

برای سوال اول و دوم راه حل، استفاده از الگو معماری کالینت سرورارائه گردید و نمره چهار ارزش دهی شد.

برای سوال سه و چهار، هیچ راه حلی ارائه نشد که به این سوال نمرهسه داده شده است.

در ادامه به بیان تشریحی ارزیابی پرداخته شده است. برای مقایسه و ایجاد سناریو به معمار طراح شرکت نمونه دوم نیاز است، که بتواند

معماری ارائه شده را توضیح دهد. ولی نکات مکتوب قابل بررسی را دراین مرحله ارزیابی شده است.

در مستند معماری نرم افزار با این جمله مواجه می شویم، در عموما با توزیع شدگی، امنیت، قابلیت های مرتبط با سهولت استفاده، رابطه

پایایی، مقاومت در برابر خطا و مسائلی از این قبیل هستند که درمعماری سیستم تأثیرگذار هستند.

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

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

ادارهموجود در سیستم های سایربرقراری ارتباط و استفاده از اطالعات برق هرمزگان در صورت داشتن مجوز دسترسی به آن سیستم ها را

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

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

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

سیستم و در چه سطحی دسترسی دارد. کلیه پسوردهای کاربران در پایگاه داده به صورت رمزنگاری شده

به ویژگی عملیاتی و زیر ویژگی امنیت مربوط نگهداری می شود. می شود که اگر عملی و پیاده سازی در نرم افزار شود نمره عالی دریافت

می کند.

135

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

، منویKendu Menuبا استفاده از کامپوننت در این جمله معماری کاربری به نحوی طراحی و پیاده سازی شده است که کاربر بتواند با کمترین تعداد کلیک به فرم ها و گزارش ها موردنظر دسترسی داشته

این جمله به ویژگی کاربری مرتبط می شود که با توضیحی باشد.داده شده است از وجه امتیاز خوبی برخوردار است.

می شود. LOGاعمال مهم کاربران در سیستم این جمله در معماری به امنیت و قابلیت اطمینان مرتبط می شود که حائز اهمیت است.که

در مستند معماری راجع به گزارش گیر با انواع مختلف و سخت افزار بکار رفته و نرم افزارهای مورداستفاده سخن گفته شده که به ویژگی

عملیاتی، زیر ویژگی مناسب بودن مرتبط می شود. جهت تعامل بهتر نرم افزار با کاربران امکاناتو در این متن معماری،

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

است. امکان مرتب سازی اطالعات به صورت صعودی و نزولی در کلیه

کنترل ها و مؤلفه های وب آماده برای توسعه جداول موجود در فرم ها از ابزارواسط کاربر استفاده خواهد شد و در این میان بهترین کاندیدا

Kendu UI به ویژگی کاربری پرداخته و مفید است. است که در متن مستند از الگوی معماری الیه ای )معماری سه الیه( در

طراحی برنامه استفاده شده است. که به ویژگی های عملیاتی و قابلیت اطمینان و قابلیت نگهداری مرتبط می شود که استفاده از این الگو استاندارد مناسبی است. در متن مستند به ساده شدن طراحی و

ساده تر شدن نگهداری اشاره شده است. با استفاده از معماری سه الیه در پیاده سازی نرم افزار و استفاده معماری چهار بعالوه یک به عنوان شناخت از مؤلفه نرم افزار. دید کلی از اینکه آیا ذینفع معماری، نرم

افزار ارائه شده را شناخته و دید کامل و کلی به نرم افزار دارد، مورداستفاده و بررسی قرار می گیرد. که از این نظر باید یک فرد مسلط

به کار نرم افزار و مشاور استفاده شود. که در نمای موارد کاربردیویژگی عملیاتی را پوشش می دهد و می توان آن را بررسی نمود. در دیدگاه منطقی روند کار و انجام کار از دیدگاه مدیریتی بررسی

می شود. در دیدگاه پروسس پیاده سازی و معماری داخلی به صورت کلی بررسی

می شود. در نمای فیزیکی نحوه قرارگیری پلت فرم و پکیج های نرم افزاری

136

فصلبهبود روش ارزیابی معماری نرم افزار... چهارم: ارزیابی معماری نرم افزار

مشخص می شود و جزئیات سخت افزار و نرم افزار بیان می شود. در نمای پیاده سازی هم توصیف معماری و طراحی داخلی سیستم

به صورت کلی بیان می شود. کم و متوسط3اگر درباره صفت کیفی، دیگر بررسی نشده است، نمره

در جدول باال ارزیابی شده است.

جمع بندی-4-3

در این فصل ساختار معماری نرم افزار برای مدیریت برون سپاری برای نمونه یک ارائه داده شد. بعدازآن به ارزیابی این ساختار

پرداخته شده و همچنین نمونه دوم ارزیابی شد. شیوه ارزیابی این دو و جدول ارزش دهیISO9126 از روش ATAMنمونه با بهبود روش ارزیابی

یانگ بررسی شد.

137

5. جمع بندی وفصل پنجم:

پیشنهادها

بهبود روش ارزیابی معماری نرم افزار... فصل پنجم:جمع بندی و پیشنهادها

مقدمه-5-1

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

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

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

نتیجه گیری-5-2

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

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

ازنظر كلي در هر روش ارزيابي ویژگی های كيفيتي يك سيستمنرم افزاري، بايد سه فعالیت اصلي مورد توجه باشد:

به دست آوردن ویژگی های كيفيتي درخواستي ذينفعان و اولویت بندی آن ها.

.پيدا نمودن ویژگی های كيفيتي موجود در معماري پيشنهادي.يك روش براي بررسي مطابقت و سازگاري اين دو باهم

بدين معني كه بايد ویژگی های كيفيتي مورد انتظار ذينفعان با توجه به اولويت بندی موردنظر آن ها ابتدا مشخص شده و ویژگی های موجود در راه حل پيشنهادي نيز تعيين گردد. سپس با توجه به اين دودسته ويژگي

ميزان تأمین مطابقت ویژگی های موجود در معماري پيشنهادي باخواسته های ذينفعان محاسبه گردد.

سخت ترین قسمت، پيدا نمودن مشخصه های كامل و دقيق ویژگی های سيستم درخواستي است. تمام كساني كه تجربه ای در

تجزیه وتحلیل سيستمهاي نرم افزاري و توصيف آن ها دارند به اين امر

139