رقم المقالة : 202007118203 زيارة : 10677 الصفحة: 57 - 66

نوع المخطوط: المحکّمة

ارائه يك روش اوليه جهت تخمين پروژه‌هاي نرم‌افزاري مبتنی بر تراکنش منطقی

الموضوعات :

1 - پژوهشگر رایانه
2 - دانشگاه صنعتی مالک اشتر، تهران، ایران

تاريخ الإرسال : 28 الأربعاء , ربيع الأول, 1435 تاريخ التأكيد : 28 الأربعاء , ربيع الأول, 1435 تاريخ الإصدار : 27 الإثنين , ذو الحجة, 1438

الکلمات المفتاحية: توجّه بصری, دستگاه ردیاب چشم, صفحات وب, منو,

ملخص المقالة :

در این مطالعه به منظور تعیین میزان توجّه بصری کاربران به منوی راست و به منوی چپ صفحات وب شاخص تعداد خیرگی‌ها روی منوی راست و منوی چپ با استفاده از دستگاه ردیاب چشم سنجیده شد تا مشخص گردد که کدام منو به لحاظ توجّه بصری برای کاربران در ارجحیت قرار دارد. روش: 116صفحۀ حاوی دو منوی راست و چپ در قالب 3 مجموعۀ فارسی- انگلیسی و انگلیسی- فارسی برای 30 آزمودنی نمایش داده شد و آزمودنی‌ها ملزم به یافتن یک لغت در منوها بوده‌اند. داده‌های مربوط به تعداد خیرگی‌های کاربران روی هر منو که نشانی از میزان توجّه بصری آن‌ها به آن منو بود با استفاده از دستگاه ردیاب نگاه ثبت و جمع آوری شد. یافته‌ها: تعداد کل خیرگی‌های کاربر بر منوهای مجموعۀ انگلیسی با توجّه به جهت چینش منوها (راست یا چپ) متفاوت نبود. اما تعداد کل خیرگی‌های کاربر بر منوهای مجموعۀ فارسی، مجموعۀ فارسی- انگلیسی و به طور کلی در مجموع همۀ صفحات سه مجموعه با توجّه به جهش چینش منوها (راست یا چپ) متفاوت و روی منوی راست بیش از منوی چپ بود. نتیجه‌گیری: با توجّه به بیش‌تر بودن تعداد خیرگی‌ها روی منوی راست در این مطالعه و مزیت‌های اثبات شدۀ منوی راست و همین طور به دلیل آن که تا به حال مزیت قابل پیش‌بینی بودن منوی چپ چین در فرهنگ‌هایی بوده است که زبان مادریشان از چپ به راست خوانده می‌شود و این‌که نتایج مطالعات پیشین پیرامون سرعت بالای انجام تکالیف و تعامل با منوی چپ چین، متناقض است، می‌توان به طراحان وب سایت‌ها توصیه کرد که در طراحی وب سایت‌های بومی از منوی راست چین استفاده کنند.

المصادر:

1. جلالي، ح. (1385). مديريت پروژه‌هاي نرم‌افزاري. تهران: دانشگاه صنعتي مالك اشتر.
2. Adams, Scott. (2007). Requirements analysis and specification. CSE432. 3-4.
3. Carroll, Edward. (2002).Estimating Software Based on Use Case Points. Agilis Solutions, A Business Unit Of Hepieric, Inc, 257-258.
4. Coombs, Paul. (2003). IT Project Estimation- A Practical Guide of the Costing of Software. Cambridge University Press.
5.Jones, Capers. (2005). Software Estimating Methods for Large Projects. Crosstalk, 10.
1. Laird, Linda, M. (2006). The Limitations of Estimation. Published by the IEEE Computer Society. 42-44.
6.Laird, Linda, M. (2006). Software Measurement and Estimation : A Practical Approach. IEEE Computer Society / Wiley Partnership, 2.
7.Lakshmanan, D. (2007). Potentiality Of Usecase Point Method for Estimating the Size and Effort of Software Development Projects. Medwell Journals, 1565-1568.
8. Molokken, K & Jorgensen, M. (2004). A Survey on Software Estimation in the Norwegian Industry. IEEE Computer Society, 2.
9. Peters, k. (2009). Software Project Estimation",Simon Farser University.

نص كامل:

فصلنامه علمي- پژوهشي

فناوري اطلاعات و ارتباطات ایران

سال نهم، شماره‌هاي 31 و 32، بهار و تابستان 1396

صص: 66- 57

$E:\E Drive\logo\iicta Logo0.JPG$

ارائه يك روش اوليه جهت تخمين پروژه‌هاي نرم‌افزاري مبتنی بر تراکنش منطقی

* مهرداد شهسواري **علی مهجور

* دانشجوی کارشناسی ارشد مهندسی نرمافزار، دانشگاه آزاد اسلامی، واحد آشتیان، ایران

** دکتری نرم افزار ، دانشگاه صنعتی مالک اشتر، تهران، ایران

تاریخ دریافت: 09/11/1392 تاریخ پذیرش: 24/04/1396

چكيده

واژه‌های کلیدی: توجّه بصری، دستگاه ردیاب چشم، صفحات وب، منو.

1. مقدمه

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

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

تخمين اندازه محصول، كليدي‌ترين ورودي فرايند تخمين پروژه مي‌باشد. در صورتي كه تخمين اندازه محصول درست نباشد، زمانبندي انجام شده دور از واقعيت خواهد بود. [1].

روش‌هاي تخمين پروژه‌هاي نرم‌افزاري اغلب براساس اطلاعات پروژه‌هاي قبلي و پايان يافته مي‌باشند. پژوهشگران و مهندسين، اطلاعات پروژه‌ها را مطالعه كرده و معادلات و رابطه‌هايي را ارایه نموده‌اند. برخي از رابطه ها خيلي ساده و برخي ديگر پيچيده مي باشند. در مجموع هيچ‌كدام با همه پروژه‌هاي پايان يافته قبلي كاملاً مطابق نيستند. آن‌ها بيشتر به طور احتمالي و براساس رابطه‌هايشان حجم كار درخواست شده براي پروژه را پيش‌گويي مي‌كنند[5].

صدها روش تخمين نرم‌افزار مستند وجود دارد كه برخي از آن‌ها هزينه نرم‌افزار را تخمين مي‌زنند. در بيشتر موارد تخمین دارای تنوع وسيعي از ورودي‌ها بوده و خروجي آن نيروي انساني است. بسیاری از روش‌ها نيز از يك رابطه تحليلي براساس كنترل‌كننده‌هاي هزينه (كه به نوعي خصوصيات و مشخصات پروژه مانند اندازه سامانه، حوزه سامانه، پيچيدگي و روش توسعه هستند) استفاده مي‌كنند [5].

2. بیان مساله

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

به همين دليل توجه به پروژه‌هایي كه به موقع به پايان رسيده‌اند مي‌تواند كمك بزرگي در جلوگيري از شكست پروژه در ميان راه باشد.

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

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

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

3. ادبیات پژوهش

پاول كومبز ¹ در رابطه با تخمين پروژه‌هاي نرم‌افزاري مي‌گويد: "هيچ كس تخمين‌زدن را دوست ندارد. تخمين‌زدن در شغل ما بي اجرترين كاري است كه مي‌توان انجام داد_ قبول مسوولیت سنگيني است براي كاري دشوار و دقيق. اگر دنبال درخشيدن هستيد از تخمين‌زدن پرهيز كنيد." [3].

با وجودي که تخمين از نظر مفهوم چيز ساده‌اي است اما در حقيقت بسيار پيچيده است. ميزان موفقيت تخمين نرم‌افزار در صورت استفاده از ابزارهاي تخمين بسيار بيشتر از روش‌هاي تخمين دستي مي‌باشد. از طرفي ابزارهاي تخمين نرم‌افزار تجاري نيز بدون نقص نيستند و حتي مي‌توانند نادرست هم باشند. اما ابزارهاي خودكار اغلب از نظر دقت و هميشه از نظر سرعت بي‌نقص‌تر از تخمين‌هاى انساني مي‌باشند.

در مجموع هيچ ‌‌يک از روش‌هاي تخمين عاري از خطا نيستند. بهترين روش رايج براي تخمين هزينه نرم‌افزار استفاده ترکيبي از ابزارهاي تخمين هزينه نرم‌افزار به همراه ابزارهاي مديريت پروژه نرم‌افزاري زير نظر مديران با تجربه پروژه‌هاى نرم‌افزاري و متخصصين تخمين مي‌باشد. [4].

سه روش بنيادي و مطرح در تخمين پروژه‌هاي نرم‌افزاري روش تحليل درجه عملکردي²، روش کوکومو به نام "مدل هزينه ساخت" و روش تخمين درجه موردکاربرد³ مي‌باشند كه در ادامه شرح مختصري از هرکدام به‌ طور جداگانه بيان مي‌گردد.

4. روش تحليل درجه عملکردي

در اين روش اندازه‌گيري نرم‌افزار مستقل از زيرساخت⁴ توسعه استفاده شده براي آن مي‌باشد. در روش تحلیل درجه عملکردی اندازه نرم‌افزار بر مبناي يك سنجه اختصاصي با نام "FunctionPoint" و با توجه به جداول منطقی⁵ و تراکنش⁶‌های مورد نیاز در نرم‌افزار مي‌باشند.

در اين روش، اندازه نرم‌افزار با تعيين تعداد عملكرد⁷ تهيه شده براي كاربر به دست مي‌آيد. اندازه‌گيري در اين روش مستقل از پايگاه⁸ توسعه استفاده شده است و نيازمندي‌هاي عملکردي كاربر⁹ اساس اندازه‌گيري هستند [4].

5. روش کوکومو به نام "مدل هزينه ساخت"

روش كوكومو وابستگي زياد به توانائي مدير براي تخمين اندازه نرم‌افزار دارد. کوکومو براي تخمين اندازه نرم‌افزار از روش تخمين درجه عملکردي استفاده مي‌کند.

در اين روش ابتدا درجه عملکردي يا تعدادFP پروژه محاسبه مي‌گردد و پس از محاسبهFP زبان برنامه‌نويسي پروژه مشخص و بر اساس آن LOC پروژه نيز بدست مي‌آيد [9].

6. روش تخمين درجه موردکاربرد

روش تخمين درجه موردکاربرد به عنوان روش تخمين هزينه و زمان در برخي از ابزارهاي مهندسي نرم‌افزار كه از UML براي مدل‌سازي استفاده مي‌كنند، پيش‌بيني شده است. از آن‌جايي‌که در ديدگاه خدمت‌گرا¹⁰ که امروزه مقبوليت و عموميت بسياري در مدل‌سازي سامانه‌ها پيدا کرده است، شناخت سامانه‌ها و تعيين نيازمندي‌ها مبتني بر تعيين مورد‌هاي‌کاربرد است. لذا مستقيما اندازه پروژه‌ها را براساس درجه موردکاربرد و بدون در نظر گرفتن درجه عملكردي مشخص مي‌کنند. در اين راستا ميزان پيچيدگي عملگرها¹¹، ميزان بزرگي سناريوي موردکاربرد، فاکتورهاي محيطي و فاکتورهاي تکنيکي مطرح مي‌شود [7].

7. سابقه تحقيقات و مطالعات انجام گرفته

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

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

طی این سال‌ها یک تيم نرم‌افزاري بنام "تیم راه‌حل‌های چابك و سریع" شروع به جمع‌آوري سنجه‌هاي جدید تخمين پروژه‌های نرم‌افزاری نموده است [2].

8. روش پژوهش

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

اين تحقيق از نظر روش جمع‌آوري داده‌ها از نوع "توصيفي" مي‌باشد. تحقيق توصيفي را مي‌توان به پنج دسته‌ پيمايشي، همبستگي، اقدام پژوهي، بررسي موردي و پس رويدادي تقسيم كرد که تحقیق حاضر از نوع تحقیق اقدام پژوهي و بررسي موردي می‌باشد.

9. یافته‌های پژوهش

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

روش پيشنهادي ما پس از شناسايي نقاط ضعف و قوت روش‌های موجود، در راستاي تقويت نقاط قوت و رفع نواقص ارایه گرديده است. اين روش كليه مولفه‌هاي موثر در روش‌هاي دیگر تخمین پروژه‌های نرم‌افزاری را مد نظر قرار مي‌دهد.

10. روش تخمين درجه تراكنش منطقي¹²

در اين روش هر مورد کاربرد به تعدادي تراکنش شکسته مي‌شود. اندازه هر تراکنش بصورت جداگانه بر اساس فاکتورهاي اندازه تراکنش (TSF) به دست مي‌آيد. سپس با جمع کردن اندازه تراکنش‌هاي هر مورد کابرد، اندازه هر مورد کاربرد و در نهايت با جمع کردن اندازه موارد کاربرد، اندازه کل پروژه به دست مي‌آيد. اندازه‌هاي بدست آمده براي تراکنش‌ها، موارد کاربرد و کل پروژه بر مبناي سنجه‌‌‌ ابداعي با نام درجه تراکنش منطقي (LTP) مي‌باشد. در اين مقاله اثبات خواهيم کرد که اندازه‌هاي بدست آمده بر اساس اين سنجه (نسبت به سنجه‌ UCP) همبستگي بيشتري با اندازه واقعي نرم‌افزار (بر اساس سنجه KLOC) دارد.

11. انواع تراکنش‌هاي منطقي

نيازمندي‌ها كارهايي هستند كه برنامه بايد انجام دهد و چگونگي آن مهم نيست نيازمندي‌ها قابليت‌ها و شرايطي هستند كه سيستم و پروژه بايد از آن‌ها پيروي نمايد. نيازمندي‌ها به دو دسته تقسيم مي‌شوند:

1- عملكردي¹³: چه كارهايي بايد انجام شود (رفتار سيستم).

2- غيرعملكردي¹⁴: كارها چگونه بايد انجام شوند (صفات سيستم) [1].

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

ورود اطلاعات به سامانه معادل با تراكنش‌هاي منطقي ثبت اطلاعات و خروج اطلاعات از سامانه متناظر با تراكنش‌هاي منطقي مشاهده اطلاعات مي‌باشد. از طرفي كدهايي كه برآورده‌كننده نيازمندي عملكردي سامانه نرم‌افزاري مي‌باشند، در نهايت منجر به يكي از تراكنش‌هاي منطقي ثبت، ويرايش، حذف و مشاهده اطلاعات مي‌شوند. پس جهت اندازه‌گيري بخش عملكردي نرم‌افزار مي‌توان تعداد و ويژگي‌هاي تراكنش‌هاي منطقي ثبت، ويرايش، حذف و مشاهده را طي يك مرحله تحقق¹⁵ از موارد کاربرد استخراج كرد.

12. فاکتورهاي موثر بر اندازه تراکنش‌ها

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

جدول 1. فاکتورهاي موثر بر اندازه تراکنش‌ها

فاکتور	توضيح	وزن
TSF1	تعداد صفات موجوديت اصلي	5
TSF2	تعداد موجوديت مرتبط با تراكنش	5
TSF3	تعداد ورودي جهت مشاهده اطلاعات	5
TSF4	تعداد خروجي در مشاهده اطلاعات	1
TSF5	ميزان محاسبات	10
TSF6	نوع محيط نمايش اطلاعات	2

13. نحوه تاثير فاکتورهاي موثر بر اندازه انواع تراکنش

همه فاکتورهاي ذکر شده در جدول 1 بر روي اندازه همه انواع تراکنش‌ها تاثير ندارند. به عنوان مثال فاکتور TSF1 که همان تعداد صفات موجوديت مي‌باشد، تاثيري بر روي اندازه تراکنش حذف ندارد. فاکتورهاي موثر بر هر نوع از تراکنش‌ها در ‏0 آورده شده است.

جدول 2. نحوه تاثير فاکتورهاي موثر بر اندازه انواع تراکنش

نوع تراكنش	فاکتور موثر	نحوه تاثير
ثبت و ويرايش	TSF1	موثر در ساخت واسط كاربري
ثبت و ويرايش	TSF2	موثر در ساخت واسط كاربري و موثر در كدنويسي
حذف	TSF2	موثر در ميزان كنترل هاي لازم حذف
مشاهده	TSF2	موثر در ساخت واسط كاربري و موثر از نظر كنترل روابط بين موجوديت‌ها
	TSF3	موثر در ساخت واسط كاربري
	TSF4	موثر در ساخت محيط نمايش
	TSF5	موثر در كدنويسي
	TSF6	موثر در ساخت محيط نمايش

14. افزايش دقت وزن‌هاي تعيين شده جهت عوامل موثر در اندازه تراكنش‌هاي منطقي

از بين 25 پروژه فضاي نمونه آماري، تعداد ده پروژه را جهت ورزيدگي¹⁶ مدل پيشنهادي و در راستاي افزايش دقت وزن‌هاي تعيين شده جهت عوامل موثر در اندازه تراكنش‌هاي منطقي (جدول1) مورد استفاده قرار داديم كه وزن‌ عوامل موثر در اندازه تراكنش‌هاي منطقي به روش آزمون و خطا به شرح جدول3 به دست آمد.

جدول 3. تعيين وزن عوامل موثر در تراكنش‌هاي منطقي

فاکتور	ويژگي اندازه‌گيري شده	شرايط	وزن
TSF1	تعداد صفات موجوديت اصلي	كمتر از 3	5
		بين 3 تا 5	10
		بيشتر از 5	15
TSF2	تعداد موجوديت مرتبط با تراكنش	كمتر از 3	5
		بين 3 تا 5	10
		بيشتر از 5	15
TSF3	تعداد ورودي جهت مشاهده اطلاعات	كمتر از 3	5
		بين 3 تا 5	10
		بيشتر از 5	15
TSF4	تعداد خروجي در مشاهده اطلاعات	كمتر از 5	1
		بين 5 تا 10	2
		بيشتر از 10	3
TSF5	ميزان محاسبات	بدون محاسبه	0
		محاسبات معمولي	10
		محاسبات پيچيده	20
TSF6	نوع محيط نمايش	بدون محيط نمايش و جهت كنترل	0
		نمايش در فرم	2
		نمايش در قالب گزارش	4

15. محاسبه اندازه تراکنش‌هاي منطقي، اندازه موارد کاربرد و اندازه نرم‌افزار

با استفاده ازجدول3 اندازه هر تراكنش منطقي را محاسبه نموديم سپس با جمع اندازه تراکنش‌هاي هر مورد کاربرد، اندازه مورد کاربرد را بدست آورديم و در نهايت با جمع وزن كليه تراكنش‌هاي منطقي نرم‌افزار، اندازه نرم‌افزار را بر حسب درجه تراكنش منطقي (LTP) بدست آورديم. البته حاصل جمع وزن تراكنش‌ها در واقع ULTP¹⁷ يعني اندازه تعديل‌نشده نرم‌افزار است كه با اعمال فاكتورهاي فني و محيطي تعديل خواهد شد. رابطه محاسبه ULTP براي هر تراكنش به صورت زير است:

رابطه‎ (1)	ULTP = ∑1..6 TSFi
رابطه‎ (2)	ULTP = ∑1..n ( ∑1..6 TSFi )

در اينجا n تعداد تراكنش‌هاي منطقي پروژه و TSFi وزن فاكتـور موثر بر هر تراكـنش مـي‌باشد. لازم به ذكر اسـت كه TSFiها بر حسب نوع تراكنش و با استفاده از جدول2 و3 تعيين مي‌گردند. به عنوان مثال براي يك تراكنش حذف طبق جدول2 فقط فاكتور موثر بر آن يعني TSF2 مقداردهي و مابقي فاكتورها بصورت پيش‌فرض صفر در نظر گرفته مي‌شوند.

16. مطالعه موردي و اثبات روش

ما جهت اثبات دقيق‌تر بودن اين روش نسبت به روش UCP از روش مطالعه موردي¹⁸ و تحليل‌هاي آمار استنباطي استفاده نموديم. در اين راستا تعداد 15 پروژه نرم‌افزاري انجام شده را مورد بررسي قرار داديم كه با توجه به اينكه تعداد موارد کاربرد در اين پروژه‌ها كمتر از 20 موردکاربرد بود اين پروژه‌ها جزء پروژه‌هاي كوچك محسوب مي‌شدند. فرايند توليد اين پروژه‌ها مبتني بر RUP ، محيط برنامه نويسي آن‌ها C#.Net و پايگاه داده آن‌ها SQL Server 2000 بود.

در ادامه با رعايت کليه موارد زير، تعداد خطوط كد پروژه‌ها (LOC) را محاسبه نموديم.

1. كدهايي كه در راستاي آزمون و پشتيباني سامانه نباشند، محاسبه مي‌شوند.

2. خطوطي از كد كه به وسيله كاركنان تيم پروژه توليد مي‌شود، مد نظر است.

3. کدهايي که به وسيله سازنده‌هاي خودكار كد¹⁹ توليد مي‌شوند محاسبه نمي‌گردند.

4. تعريف متغيرها²⁰ جزء کد هستند ولي توضيحات²¹ شمارش نمي‌شوند[8].

سپس اندازه تعديل‌نشده پروژه‌ها را توسط روش‌ UCP و روش پيشنهادي (LTP) محاسبه نموديم كه در نهايت نتايج به شرح ‏0 بدست آمد.

جدول 4. اندازه‌هاي بدست آمده از پروژه‌هاي نرم‌افزاري نمونه

R	پروژه نرم‌افزاري	UUCP	ULTP	LOC
1	برنامه‌ريزي و بهره‌كار	58	428	5337
2	انبار تعميراتي	70	494	8836
3	اعزام اكيپ تعميراتي	65	690	7736
4	تعيين وضعيت تجهيزات	208	1064	16923
5	تعميرات	306	2606	37527
6	عمليات ترابري	196	2339	31574
7	آمار و گزارشات ترابري	48	765	9641
8	الزامات ترابري	140	1929	30677
9	مديريت و نظارت و پيگيري	51	1002	10526
10	درخواست و امريه ترابري	197	1398	19705
11	مديريت طرح و برنامه	706	5013	84223
12	امور دامپزشکي	191	1198	14736
13	امور تغذيه	104	1149	17920
14	مهندسي و تاسيسات	395	2606	37525
15	مديريت بهداشت و درمان	463	2987	38526

نمودار داده‌هاي بدست آمده در جدول4 در نمودار 1 نشان داده شده است.

نمودار1. اندازه پروژه‌هاي نرم‌افزاري نمونه

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

17. کارايي روش

پس از ثبت داده‌هاي جدول4 در نرم‌افزار SPSS و انجام تحليل همبستگي دو متغيري و رگرسيون خطي روي آن‌ها نتايج زير به دست آمد كه به تشريح آن مي‌پردازيم.

الف- تحليل همبستگي دو متغيري

در اين تحليل يك‌بار متغير LOC را با متغير UUCP و يك‌بار با متغير ULTP مقايسه نموديم كه خروجي تحليل در قالب دو جدول5 و جدول6 بدست آمد.

جدول 5. همبستگي دو متغيري LOC با UUCP

		UUCP	LOC
UUCP	همبستگی پیرسون	1	(**) 938/0
	Sig. (2-tailed)		00/0
	N	15	15
LOC	همبستگی پیرسون	(**) 938/0	1
	Sig. (2-tailed)	00/0
	N	15	15

جدول 6. همبستگي دو متغيري LOC با ULTP

		ULTP	LOC
ULTP	همبستگی پیرسون	1	(**) 987/0
	Sig. (2-tailed)		00/0
	N	15	15
LOC	همبستگی پیرسون	(**) 987/0	1
	Sig. (2-tailed)	00/0
	N	15	15

همان‌طور كه مشاهده مي‌شود در هر دو مورد همبستگي در سطح معنادار 01/0 (علامت **) وجود دارد. ولي ضريب همبستگي پيرسون²² در متغير ULTP نسبت به ضريب همبستگي پيرسون در متغير UUCP به اندازه 049/0 به عدد يك نزديك‌تر است و اين مساله نشان مي‌دهد كه همبستگي ULTP به LOC به اندازه 049/0 از همبستگي UUCP به LOC بيشتر است.

ب- تحليل رگرسيون خطي

در اين تحليل LOC را متغير وابسته و UUCP و ULTP را متغير مستقل در نظر گرفتيم كه پس از انجام تحليل، خروجي آن در قالب جدول7 به دست آمد.

جدول 7. ضرايب رگرسيون

مدل	ضريب استاندارد نشده		ضريب استاندارد شده	T	Sig.
مدل	B	استاندارد خطا	بتا	T	Sig.
(ثابت)	879/2874-	460/1649		743/1-	107/00
UUCP	659/2	601/15	25/0	170/0	867/00
ULTP	819/15	359/2	964/0	707/6	000/00

با توجه به جدول7 رابطه‌ اول کمترين مجذورهاي متداول²³ به صورت زير نتيجه مي‌شود:

رابطه‎ (3)

LOC = -2874/88 + 2/659(UUCP) + 15/819(ULTP)

با دقت در رابطه3 مشخص مي‌شود كه ميزان تاثير غيرمستقيم ULTP روي LOC نسبت به تاثير غيرمستقيم UUCP روي LOC به اندازه 16/13 بيشتر است.

18. کامل بودن فاکتورها

جهت اثبات روش پيشنهادي(LTP)، فاکتورهاي تعدادي از روش‌‌هاي مطرح تخمين را استخراج كرده و نشان داديم كه هر يك از اين فاکتورها چگونه و توسط چه فاکتوري از روش پيشنهادي ما (LTP) پوشش داده مي‌شود.

جدول 8. نگاشت مولفهها

R	روش		مولفه		مولفه LTP
1	FPA	تحليل درجه عملكردي	ILF	فايل منطقي داخلي	TSF1,TSF2
			EIF	فايل واسط خارجي	TSF1, TSF2
			EI	ورودي خارجي	TSF3
			EO	خروجي خارجي	TSF4
			EQ	پرس و جوي خارجي	TSF6
2	Mark II	تحليل درجه عملكردي نمره 2	Wi	وزن عناصر داده‌اي ورودي	TSF3
			We	وزن عناصر داده‌اي ارجاعي	TSF1, TSF2
			Wo	وزن عناصر داده‌اي خروجي	TSF4
3	Feature Point	تخمين مبتني بر خصيصه	ILF	فايل منطقي داخلي	TSF1, TSF2
			EIF	فايل واسط خارجي	TSF1, TSF2
			EI	ورودي خارجي	TSF3
			EO	خروجي خارجي	TSF4
			EQ	پرس و جوي خارجي	TSF6
			Complexity	پيچيدگي الگوريتم	TSF5
4	Object Point	تخمين مبتني بر شيء	Screen	صفحه نمايش	TSF1-TSF3
			Report	گزارش	TSF4, TSF6
			3GL	ما‍ژول هاي سه زبان توليد	TSF5
5	UCP	درجه عملكرد مورد کاربرد	UAW	وزن تعديل نشده عملگر	TSF1-TSF3
5	UCP	درجه عملكرد مورد کاربرد	UUCW	وزن تعديل نشده موردکاربرد	TSF1-TSF6

19. پيادهسازي

ما بر اساس روش پيشنهادي، نرم‌افزاري به نام ابزار تخمين درجه تراكنش منطقي يا LTP-SE²⁴ پياده‌سازي نموديم. همان‌طور که در شکل1 نشان داده شده است ورودي اين ابزار، اطلاعات تراكنش‌هاي منطقي پروژه نرم‌افزاري به تفكيك موردکاربرد و خروجي آن، اندازه هر موردکاربرد يا اندازه كل پروژه مي‌باشد.

شکل1. شماي کلي نرم‌افزار

ابزار LTP-SE در محيط .Net2005 تحت وب و با زبان برنامه نويسي C# پياده‌سازي و از SQL 2005 به‌ عنوان پايگاه داده استفاده مي‌كند. نرم‌افزار LTP-SE داراي سه لايه واسط كاربري²⁵، لايه دسترسي به داده²⁶ و پايگاه داده²⁷ مي‌باشد.

20. نتیجه گیری و پیشنهادات

بر اساس تحلیل‌های آماری انجام شده نتیجه می‌گیریم روش LTP نسبت به روش UCP دقيق‌تر مي‌باشد و بر خلاف روشUCP به ترسيم نمودار فعاليت (سناريو گام به گام) موردکاربرد نياز ندارد. همچنین با توجه به جدول شماره5 این روش كليه عوامل موجود در روش‌هاي COCOMO، UCP و FP را پوشش داده و در مقايسه با روش FP براي الگوريتم‌ها (در قالب پيچيدگي محاسبات) ضريبي لحاظ نموده است.

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

خروجي و محصولات فرعي اين روش در چارچوب فرايند توسعه نرم‌افزار (مثلا در ترسيم نمودار اشيا تجاري²⁸) قابل استفاده است.

درك سنجه درجه تراكنش منطقي يا LTP، ساده و آسان است. زیرا اين سنجه مبتني بر يك نظريه قابل اطمينان می‌باشد (اساس کار این روش بر چهار عملیاتSelect , Delete , Update , Add استوار است). از طرفی اين سنجه به دلیل این که يك سنجه عملكردي است، براي برآورد مناسب‌ است.

بنـابراین پیشنهاد می‌شود پژوهشگران علاقه‌مند در رابطه با

منابع

1. جلالي، ح. (1385). مديريت پروژه‌هاي نرم‌افزاري. تهران: دانشگاه صنعتي مالك اشتر.

2. Adams, Scott. (2007). Requirements analysis and specification. CSE432. 3-4.

3. Carroll, Edward. (2002).Estimating Software Based on Use Case Points. Agilis Solutions, A Business Unit Of Hepieric, Inc, 257-258.

4. Coombs, Paul. (2003). IT Project Estimation- A Practical Guide of the Costing of Software. Cambridge University Press.

5. Jones, Capers. (2005). Software Estimating Methods for Large Projects. Crosstalk, 10.

6. Laird, Linda, M. (2006). The Limitations of Estimation. Published by the IEEE Computer Society. 42-44.

7. Laird, Linda, M. (2006). Software Measurement and Estimation : A Practical Approach. IEEE Computer Society / Wiley Partnership, 2.

8. Lakshmanan, D. (2007). Potentiality Of Usecase Point Method for Estimating the Size and Effort of Software Development Projects. Medwell Journals, 1565-1568.

9. Molokken, K & Jorgensen, M. (2004). A Survey on Software Estimation in the Norwegian Industry. IEEE Computer Society, 2.

10. Peters, k. (2009). Software Project Estimation",Simon Farser University.

موارد زیر تحقیق نمایند..

الف- اندازه تعديل‌نشده حاصل از روش تخمين درجه تراكنش منطقي (ULTP)، بايد با اعمال عوامل فني (TCF) و محيطي (EF) تعديل شود.

ب- با آزمون اين روش روي تعداد زيادي از پروژه‌هاي نرم‌افزاري انجام شده، ميزان دقت روش از طريق تنظيم وزن عوامل موثر بر اندازه تراكنش‌هاي منطقي قابل افزايش است.

ج- اين روش مي‌بايست علاوه بر نرم‌افزارهاي تراكنشي و داده محور، روي انواع ديگر نرم‌افزار مورد آزمون و ارزيابي قرار گيرد.

د- عامل بهره‌‌وري در روش‌هاي موجود تخمين، بيشتر بصورت تجربي و از طريق مقايسه با پروژه‌هاي انجام شده قبلي بدست مي‌آيد. ولي پيشنهاد مي‌شود در كار آينده مختص روش LTP روشي جهت محاسبه عامل بهره‌‌وري ارايه شود.

در صورت انجام تحقيقات بالا مي‌توان تلاش پروژه را با داشتن اندازه تعديل شده پروژه و عامل بهره‌‌وري بدست آورد. هزينه و زمان پروژه نيز با استفاده از تلاش پروژه قابل محاسبه است.

5.Jones, Capers. (2005). Software Estimating Methods for Large Projects. Crosstalk, 10.

11. Laird, Linda, M. (2006). The Limitations of Estimation. Published by the IEEE Computer Society. 42-44.

6.Laird, Linda, M. (2006). Software Measurement and Estimation : A Practical Approach. IEEE Computer Society / Wiley Partnership, 2.

7.Lakshmanan, D. (2007). Potentiality Of Usecase Point Method for Estimating the Size and Effort of Software Development Projects. Medwell Journals, 1565-1568.

12. Jones, Capers. (2005). Software Estimating Methods for Large Projects. Crosstalk, 10.

13. Laird, Linda, M. (2006). The Limitations of Estimation. Published by the IEEE Computer Society. 42-44.

14. Laird, Linda, M. (2006). Software Measurement and Estimation : A Practical Approach. IEEE Computer Society / Wiley Partnership, 2.

15. Lakshmanan, D. (2007). Potentiality Of Usecase Point Method for Estimating the Size and Effort of Software Development Projects. Medwell Journals, 1565-1568.

16. Molokken, K & Jorgensen, M. (2004). A Survey on Software Estimation in the Norwegian Industry. IEEE Computer Society, 2.

17. Peters, k. (2009). Software Project Estimation",Simon Farser University.

Journals, 1565-1568.

8. Molokken, K & Jorgensen, M. (2004). A Survey on Software Estimation in the Norwegian Industry. IEEE Computer

Society, 2.

9. Peters, k. (2009). Software Project Estimation",Simon Farser University.

[1] . Paul Coombs

[2] . Function Point Analysis (FPA)

[3] . Usecase Point (UCP)

[4] . Platform

[5] . Logical file

[6] . Transaction

[7] . Functionality

[8] . Platform

[9] . Functional User Requirement (FUR)

[10] . Service Oriented

[11] . Actor

[12] . Logical Transaction Point (LTP)

[13] . Functional

[14] . Non-Functional

[15] . Realization

[16] . Training

[17] . Unadjusted Logical Transaction Point (ULTP)

[18] . Case Study

[19] . Code Generator

[20] . Variable Declatation

[21] . Comment

[22] . Pearson Correlation

[23] . Ordinary Least Squares(OLS)

[24] . Logical Transaction Point -Software Estimation (LTP-SE)

[25] . User Interface Layer

[26] . Data Access Layer

[27] . DataBase Layer

[28] . Business Object Model

شارک

عنوان URL للمقالة

ارائه يك روش اوليه جهت تخمين پروژه‌هاي نرم‌افزاري مبتنی بر تراکنش منطقی

رایمگ

الروابط

المراكز ذات الصلة

دعامة

الصفحات الرسمية