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

چکیده:

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

1- مقدمه

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

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

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

  با توجه به اهمیت انتخاب روش ارزیابی مناسب،ارائه چارچوبی برای مقایسه روش های ارزیابی معماری نرم افزار و سپس انتخاب روش مناسب،سودمند می باشد.چارچوب های که تاکنون معرفی شده تنها بر روی روش های مشابه(عمدتا بر روی روش های مبتنی برSAAM[1]) تست شده و از این نظر ناقص است.همچنین در این چارچوب راه حلی برای انتخاب روش ارزیابی مناسب، پیشنهاد نشده است.

  در این مقاله  ،چارچوبی برای مقایسه روش های ارزیابی معماری نرم افزار ارائه شده که این چارچوب بر پایه برخی پارامترها بنا شده است. همچنین در کنار این چارچوب تکنیکی برای انتخاب زوش ارزیابی مناسب با توجه به نوع سیستم در حال توسعه ارائه شده است. ما این چارچوب را AES-AKU[2] نامیده ایم.

2- چارچوب پیشنهادی برای مقایسه روش های ارزیابی معماری نرم افزار

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

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

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

   در این بخش به معرفی سه روش ارزیابی معماری نرم افزار (ATAMوCBAMوبازبینی معماری در RUP) خواهیم پرداهت.سپس از این روش ها به عنوان بستری برای تست چارچوب ارائه شده،اسنفاده خواهیم نمود.

3-1 روش[3] ATAM

این روش بر پایه SAAM بنا شده است.ATAM علاوه بر ارزیابی ویژگی های کیفی،به بررسی ارتباط و Tradeoff میان ویژگی های کیفی می پردازد.در این روش هدف به دست آوردن نحوه برآورده شدن ویژگی های کیفی در معماری می باشد.در روش ATAM،3 پارامتر در مورد هر بخش مورد ارزیابی ،مشخص می شود:

نقاط حساسیت [4] : مجموعه ای از اجزا معماری که وجود آنها برای برآورده شدن یک نیاز کیفی حیاتی می باشد.

نقاط Trade_off:نقاط حساسی هستند که تحت تاثیر دو ویژگی کیفی قرار دارند.

نقاط ریسک :نقاطی که ممکن است سیستم را از دستیابی به ویژگی کیفی مورد نظر باز دارد.

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

3-2 روش[5] CBAM

روش ATAMمعماری را از تظر ویژگی های کیفی ارزیابی می کند.در CBAM،هدف اصافه کردن یک پارامتر دیگر به این مجموعه می باشد. این پارامتر هزینه می باشد.در نهایت خروجی این روش،فهرستی از راهبردهای معماری است که به ترتیب سودمندی مرتب شده اند.روش CBAM،بر پایه روش ATAM بنا شده است.بنابراین ورودی های  این روش، خروجی های ATAM  می باشند.تیم ارزیاب در این روش ،همانند روش ATAM  می باشد.

3-3 روش بازبینی معماری RUP

در RUP،ارزیابی معماری نرم افزار در قالب فعالیت بازبینی معماری[6] در گروه فعالیت بهبود معماری[7] ارائه شده است. مجری این عمل بازبین فنی[8] معرفی شده است.در اهداف روش بازبینی معماری،به دست آوردن ریسک های موجود در زمینه بودجه و زمان بندی،یافتن اشکالات موجود در معماری سیستم ،یافتن تناقض بین نیازهای به دست آمده و معماری، ارزیابی ویژگی های کیفی معماری، تعیین فرصت های استفاده  مجدد می باشد.

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

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

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

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

4- مقایسه روش های ارزیابی در چارچوب ارائه شده

  تکنیک ارزیابی: روش ATAM یک روش مبتنی بر سناریو شمرده می شود.CBAM ترکیبی از روش های سناریو و اندازه گیری می باشد و سناریوها پایه اصلی اندازه گیری هزینه ها هستند.در بازبینی معماری توسط RUP،تکنیک های چک لیست ،اندازه گیری و سناریو پیشنهاد شده است اما تکنیکی که برای آن به طور دقیق راه حل ارائه شده، تکنیک چک لیست می باشد.

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

  داشتن فرایند قوی[9]:ATAM، توسط فرایندی قوی پشتیبانی می شود.ورودی ها و خروجی های هر مرحله کاملا مشخص می باشد.CBAM نیز توسط یک فرایند قوی پشتیبانی شده و مجری هر یک از فعالیت های آن وورودی ها و خروجی ها به دقت مشخص شده است.

  قابلیت یکپارچگی با فرایند توسعه نرم افزار: روش های ATAMو CBAM، تا کنون با فرایندهای توسعه نرم افزار RUP و extreme Programming یکپارچه شده اند.روش بازبینی معماری RUP، تنها قابل استفاده در کنار RUP، می باشد.

  مرحله ارزیابی معماری: برای انجام روش ATAM ، باید معماری نرم افزار به طور کامل ایجاد شده باشد.روش CBAM،پس از ATAM انجام می شود بنابراین این روش نیز قبل از آغاز طراحی باید انجام گردد.

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

  تخصص های فنی مورد نیاز: روش ATAM،نیاز به دانش فنی بالا دارد.تیم ارزیاب باید از افرادی تشکیل شود که قدرت ارزیابی ویژگی های کیفی گوناگون را داشته باشند.روش CBAM، نیاز به افرادی دارد که توانایی تخمین هزینه هر راهبرد معماری را داشته باشد.روش RUP، قابل انجام توسط مهندس نرم افزار دارای دانش

در زمینه معماری نرم افزار می باشد.

5- امتیاز دهی به روش های ارزیابی در AES-AKU

  پس از قرار دادن روش های ارزیابی درچارچوب AES-AKU ، به هر یک از روش ها در مقابل هر یک از پارامترهای چارچوب، امتیازی بین 1تا 10 اختصاص می دهیم.این امتیاز بیانگر قدرت پارامتر مذکور در روش ارزیابی می باشد. (امتیاز پارامترi در روش ارزیابیj را با علامت ijS نمایش می دهیم.) پس از امتیاز دهی روش ها، با توجه به نوع سیستم مورد ارزیابی، به هر یک از پارامترهای مقایسه، وزنی اختصاص داده می شود.(وزن پارامترi را با علامت iw نشان می دهیم.) این وزن بیانگر اهمیت پارامتر مذکور در سیستم توسعه داده شده می باشد. پس از امتیاز دهی و وزن دهی در قالب چارچوب AES-AKU، امتیاز کلی هر روش را به صورت زیر محاسبه می کنیم:

 iw´ ijs å= jScore

- انتخاب روش ارزیابی مناسب برای سیستم مطالعه موردی به وسیله AES-AKU

  برای ارزیابی معماری نرم افزار این سیستم، روش های ارزیابی را در چارچوب AES-AKU، مقایسه وارزیابی نمودیم.در زیر به نحوه امتیاز دهی و وزن دهی هر یک از پارامترها پرداخته شده است.باید توجه داشت معیار دقیقی برای اختصاص وزن یا امتیاز ها وجود ندارد و مقادیر تقریبی و تجربی می باشند. نتایج این امتیازدهی در جدول 1، ارائه شده است.

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

[1] Software Architecture Analysis Method

[2] Architecture Evaluation Selection_Amir Kabir University

[3] Architecture Trade_off Analysis Method

[4] Sensitivity Points

[5] Cost_Benefit Analysis Method

[6] Review The Architecture

[7] Refine The Architecture

[8] Technical Reviewer

[9] Process Support