ارائه يك روش اوليه جهت تخمين پروژه‌هاي نرم‌افزاري مبتنی بر تراکنش منطقی
محورهای موضوعی : عمومىمهرداد شهسواری 1 * , علی مهجور 2
1 - پژوهشگر رایانه
2 - دانشگاه صنعتی مالک اشتر، تهران، ایران
کلید واژه: توجّه بصری, دستگاه ردیاب چشم, صفحات وب, منو,
چکیده مقاله :
در این مطالعه به منظور تعیین میزان توجّه بصری کاربران به منوی راست و به منوی چپ صفحات وب شاخص تعداد خیرگی‌ها روی منوی راست و منوی چپ با استفاده از دستگاه ردیاب چشم سنجیده شد تا مشخص گردد که کدام منو به لحاظ توجّه بصری برای کاربران در ارجحیت قرار دارد. روش: 116صفحۀ حاوی دو منوی راست و چپ در قالب 3 مجموعۀ فارسی- انگلیسی و انگلیسی- فارسی برای 30 آزمودنی نمایش داده شد و آزمودنی‌ها ملزم به یافتن یک لغت در منوها بوده‌اند. داده‌های مربوط به تعداد خیرگی‌های کاربران روی هر منو که نشانی از میزان توجّه بصری آن‌ها به آن منو بود با استفاده از دستگاه ردیاب نگاه ثبت و جمع آوری شد. یافته‌ها: تعداد کل خیرگی‌های کاربر بر منوهای مجموعۀ انگلیسی با توجّه به جهت چینش منوها (راست یا چپ) متفاوت نبود. اما تعداد کل خیرگی‌های کاربر بر منوهای مجموعۀ فارسی، مجموعۀ فارسی- انگلیسی و به طور کلی در مجموع همۀ صفحات سه مجموعه با توجّه به جهش چینش منوها (راست یا چپ) متفاوت و روی منوی راست بیش از منوی چپ بود. نتیجه‌گیری: با توجّه به بیشتر بودن تعداد خیرگی‌ها روی منوی راست در این مطالعه و مزیت‌های اثبات شدۀ منوی راست و همین طور به دلیل آن که تا به حال مزیت قابل پیش‌بینی بودن منوی چپ چین در فرهنگ‌هایی بوده است که زبان مادریشان از چپ به راست خوانده می‌شود و این‌که نتایج مطالعات پیشین پیرامون سرعت بالای انجام تکالیف و تعامل با منوی چپ چین، متناقض است، می‌توان به طراحان وب سایت‌ها توصیه کرد که در طراحی وب سایت‌های بومی از منوی راست چین استفاده کنند.
In this study, in order to determine the level of visual attention of users to the right menu and to the left menu of web pages, the number of dazzles on the right and left menu was measured using an eye tracker to determine which menu is preferable to users in terms of visual attention. contract. Method: 116 pages containing two right and left menus were displayed in the form of 3 sets of Persian-English and English-Persian for 30 subjects and the subjects were required to find a word in the menus. Data related to the number of users' dazzle on each menu, which was an indication of their visual attention to that menu, was recorded and collected using the gaze tracker. Results: The total number of user idiots on the menus of the English collection did not differ according to the order of the menus (right or left). But the total number of user wonders on the menus of the Persian collection, the Persian-English collection and in general in all the pages of the three collections was different due to the jump in the arrangement of the menus (right or left) and on the right menu more than the left menu. Conclusion: Considering the higher number of dumbbells on the right menu in this study and the proven advantages of the right menu, as well as the fact that the advantage of having a left-hand menu in China has been in cultures whose mother tongue is read from left to right. Although the results of previous studies on the high speed of homework and interaction with the left-hand menu are inconsistent, web designers can be advised to use the right-hand menu when designing native websites.
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 |
|
ارائه يك روش اوليه جهت تخمين پروژه‌هاي نرم‌افزاري مبتنی بر تراکنش منطقی
* مهرداد شهسواري **علی مهجور
* دانشجوی کارشناسی ارشد مهندسی نرمافزار، دانشگاه آزاد اسلامی، واحد آشتیان، ایران
** دکتری نرم افزار ، دانشگاه صنعتی مالک اشتر، تهران، ایران
تاریخ دریافت: 09/11/1392 تاریخ پذیرش: 24/04/1396
چكيده
در این مطالعه به منظور تعیین میزان توجّه بصری کاربران به منوی راست و به منوی چپ صفحات وب شاخص تعداد خیرگی‌ها روی منوی راست و منوی چپ با استفاده از دستگاه ردیاب چشم سنجیده شد تا مشخص گردد که کدام منو به لحاظ توجّه بصری برای کاربران در ارجحیت قرار دارد. روش: 116صفحۀ حاوی دو منوی راست و چپ در قالب 3 مجموعۀ فارسی- انگلیسی و انگلیسی- فارسی برای 30 آزمودنی نمایش داده شد و آزمودنی‌ها ملزم به یافتن یک لغت در منوها بوده‌اند. داده‌های مربوط به تعداد خیرگی‌های کاربران روی هر منو که نشانی از میزان توجّه بصری آن‌ها به آن منو بود با استفاده از دستگاه ردیاب نگاه ثبت و جمع آوری شد. یافته‌ها: تعداد کل خیرگی‌های کاربر بر منوهای مجموعۀ انگلیسی با توجّه به جهت چینش منوها (راست یا چپ) متفاوت نبود. اما تعداد کل خیرگی‌های کاربر بر منوهای مجموعۀ فارسی، مجموعۀ فارسی- انگلیسی و به طور کلی در مجموع همۀ صفحات سه مجموعه با توجّه به جهش چینش منوها (راست یا چپ) متفاوت و روی منوی راست بیش از منوی چپ بود. نتیجه‌گیری: با توجّه به بیشتر بودن تعداد خیرگی‌ها روی منوی راست در این مطالعه و مزیت‌های اثبات شدۀ منوی راست و همین طور به دلیل آن که تا به حال مزیت قابل پیش‌بینی بودن منوی چپ چین در فرهنگ‌هایی بوده است که زبان مادریشان از چپ به راست خوانده می‌شود و این‌که نتایج مطالعات پیشین پیرامون سرعت بالای انجام تکالیف و تعامل با منوی چپ چین، متناقض است، می‌توان به طراحان وب سایت‌ها توصیه کرد که در طراحی وب سایت‌های بومی از منوی راست چین استفاده کنند.
واژه‌های کلیدی: توجّه بصری، دستگاه ردیاب چشم، صفحات وب، منو.
1. مقدمه
اندازه‌گيري از ملزومات اوليه پروژه‌هاي نرم‌افزاري مي‌باشد. آنچه كه قابل اندازه‌گيري نباشد قابل كنترل و در نتيجه قابل مديريت علمي و دقيق نيز نمي‌باشد. مديريت پروژه بدون اندازه‌گيري تبديل به مديريت حسي، غيرعلم ي و غیر دقيق مي‌شود. حتي در صورتيكه پروژه موفق باشد، موفقيت آن در
|
|
تخمين اندازه محصول، كليدي‌ترين ورودي فرايند تخمين پروژه مي‌باشد. در صورتي كه تخمين اندازه محصول درست نباشد، زمانبندي انجام شده دور از واقعيت خواهد بود. [1].
روشهاي تخمين پروژه‌هاي نرم‌افزاري اغلب براساس اطلاعات پروژه‌هاي قبلي و پايان يافته مي‌باشند. پژوهشگران و مهندسين، اطلاعات پروژه‌ها را مطالعه كرده و معادلات و رابطه‌هايي را ارایه نموده‌اند. برخي از رابطه ها خيلي ساده و برخي ديگر پيچيده مي باشند. در مجموع هيچ‌كدام با همه پروژه‌هاي پايان يافته قبلي كاملاً مطابق نيستند. آن‌ها بيشتر به طور احتمالي و براساس رابطه‌هايشان حجم كار درخواست شده براي پروژه را پيش‌گويي مي‌كنند[5].
صدها روش تخمين نرمافزار مستند وجود دارد كه برخي از آن‌ها هزينه نرمافزار را تخمين مي‌زنند. در بيشتر موارد تخمین دارای تنوع وسيعي از ورودي‌ها بوده و خروجي آن نيروي انساني است. بسیاری از روش‌ها نيز از يك رابطه تحليلي براساس كنترل‌كننده‌هاي هزينه (كه به نوعي خصوصيات و مشخصات پروژه مانند اندازه سامانه، حوزه سامانه، پيچيدگي و روش توسعه هستند) استفاده مي‌كنند [5].
2. بیان مساله
امروزه تعداد زيادي از پروژه‌هاي نرم‌افزاري در كشور ما از نظر زمان، هزينه و رفع تمام نيازهاي مشتري، با مشكل روبرو شده و در نهايت با لغو شدن و شكست پروژه مواجه مي‌شوند. درصد بالايي از پروژه‌هاي نرم‌افزاري در همان مراحل ابتدايي كار و پس از تحليل نيازمندي‌ها به دلايل گوناگون با مشكل مواجه مي‌گردند.
به همين دليل توجه به پروژه‌هایي كه به موقع به پايان رسيده‌اند مي‌تواند كمك بزرگي در جلوگيري از شكست پروژه در ميان راه باشد.
البته حتي پروژه‌هاي موفق نيز در نحوة رسيدن به اين مرحله يعني از شكست تا موفقيت، با هم متفاوت مي‌باشند. يكي از مهمترين تفاوت‌ها نحوة رسيدن آن‌ها به زمانبندي، هزينه و منابع پيش‌بيني شده وكيفیتي است كه در ابتداي كار تخمين زده مي‌شود.
متاسفانه در كشور ما با وجود جايگاه بالاي تخمين و ميزان تاثيرگذاري آن بر ميزان موفقيت پروژه‌هاي نرم‌افزاري، بدليل پيچيدگي بالا، سرعت كم و پائين بودن دقت ابزارهاي خودكار تخمين پروژه نرم‌افزاري، تخمين اندازه، تلاش، زمان و هزينه بصورت تجربي و قياسي انجام مي‌گردد.
هدف و سوال اصلی این تحقیق این است که چگونه مي‌توان روشي اوليه جهت تخمين پروژه‌هاي نرم‌افزاري تراکنشی ارایه نمود كه در يكي از زمينه‌هاي سرعت، دقت و يا سادگي نسبت به ساير روشهاي موجود بهتر باشد؟
3. ادبیات پژوهش
پاول كومبز1 در رابطه با تخمين پروژه‌هاي نرم‌افزاري مي‌گويد: "هيچ كس تخمين‌زدن را دوست ندارد. تخمين‌زدن در شغل ما بي اجرترين كاري است كه مي‌توان انجام داد_ قبول مسوولیت سنگيني است براي كاري دشوار و دقيق. اگر دنبال درخشيدن هستيد از تخمين‌زدن پرهيز كنيد." [3].
با وجودي که تخمين از نظر مفهوم چيز ساده‌اي است اما در حقيقت بسيار پيچيده است. ميزان موفقيت تخمين نرمافزار در صورت استفاده از ابزارهاي تخمين بسيار بيشتر از روشهاي تخمين دستي مي‌باشد. از طرفي ابزارهاي تخمين نرمافزار تجاري نيز بدون نقص نيستند و حتي مي‌توانند نادرست هم باشند. اما ابزارهاي خودكار اغلب از نظر دقت و هميشه از نظر سرعت بي‌نقص‌تر از تخمين‌هاى انساني مي‌باشند.
در مجموع هيچ يک از روشهاي تخمين عاري از خطا نيستند. بهترين روش رايج براي تخمين هزينه نرمافزار استفاده ترکيبي از ابزارهاي تخمين هزينه نرمافزار به همراه ابزارهاي مديريت پروژه نرم‌افزاري زير نظر مديران با تجربه پروژه‌هاى نرم‌افزاري و متخصصين تخمين مي‌باشد. [4].
سه روش بنيادي و مطرح در تخمين پروژه‌هاي نرم‌افزاري روش تحليل درجه عملکردي2، روش کوکومو به نام "مدل هزينه ساخت" و روش تخمين درجه موردکاربرد3 مي‌باشند كه در ادامه شرح مختصري از هرکدام به طور جداگانه بيان مي‌گردد.
4. روش تحليل درجه عملکردي
در اين روش اندازه‌گيري نرمافزار مستقل از زيرساخت4 توسعه استفاده شده براي آن مي‌باشد. در روش تحلیل درجه عملکردی اندازه نرمافزار بر مبناي يك سنجه اختصاصي با نام "FunctionPoint" و با توجه به جداول منطقی5 و تراکنش6های مورد نیاز در نرمافزار مي‌باشند.
در اين روش، اندازه نرمافزار با تعيين تعداد عملكرد7 تهيه شده براي كاربر به دست مي‌آيد. اندازه‌گيري در اين روش مستقل از پايگاه8 توسعه استفاده شده است و نيازمندي‌هاي عملکردي كاربر9 اساس اندازه‌گيري هستند [4].
5. روش کوکومو به نام "مدل هزينه ساخت"
روش كوكومو وابستگي زياد به توانائي مدير براي تخمين اندازه نرمافزار دارد. کوکومو براي تخمين اندازه نرمافزار از روش تخمين درجه عملکردي استفاده مي‌کند.
در اين روش ابتدا درجه عملکردي يا تعدادFP پروژه محاسبه مي‌گردد و پس از محاسبهFP زبان برنامه‌نويسي پروژه مشخص و بر اساس آن LOC پروژه نيز بدست مي‌آيد [9].
6. روش تخمين درجه موردکاربرد
روش تخمين درجه موردکاربرد به عنوان روش تخمين هزينه و زمان در برخي از ابزارهاي مهندسي نرمافزار كه از UML براي مدل‌سازي استفاده مي‌كنند، پيش‌بيني شده است. از آن‌جايي‌که در ديدگاه خدمت‌گرا10 که امروزه مقبوليت و عموميت بسياري در مدل‌سازي سامانه‌ها پيدا کرده است، شناخت سامانه‌ها و تعيين نيازمندي‌ها مبتني بر تعيين مورد‌هاي‌کاربرد است. لذا مستقيما اندازه پروژه‌ها را براساس درجه موردکاربرد و بدون در نظر گرفتن درجه عملكردي مشخص مي‌کنند. در اين راستا ميزان پيچيدگي عملگرها11، ميزان بزرگي سناريوي موردکاربرد، فاکتورهاي محيطي و فاکتورهاي تکنيکي مطرح مي‌شود [7].
7. سابقه تحقيقات و مطالعات انجام گرفته
در سطح داخلی (کشور ایران) تحقیقات زیادی روی تخمین پروژه‌های نرم‌افزاری انجام نشده است و با وجود جایگاه بالای آن، در کتب مهندسی نرمافزار خیلی مختصر به آن اشاره شده است و در بین پایان‌نامه‌ها و مقاله‌های موجود در سطح دانشگاه‌ها نیز مطالب زیادی در رابطه با تخمین پروژه‌های نرم‌افزاری یافت نمی‌شود.
در سطح خارجی هم تا سال 1997 روش‌هایی مانند تحليل درجه عملكردي، مدل هزينه ساخت، درجه عملكرد موردکاربرد و غیره ارایه شده‌اند ولی از سال 1997 به بعد تحقیقات محققین بیشتر بر اصلاح روش‌های ارایه شده و بهبود روش‌ها متمرکز بوده است و می‌توان گفت در این دوره روش مطرح جدیدی ارایه نشده است. طي این دوره محققین همواره بدنبال آن بوده‌اند كه بتوانند در چرخه حيات پروژه‌های نرم‌افزاری روشي براي پاسخ به نيازمندي‌هاي مشتري‌ها در زماني كمتر ارایه دهند و سرعت تخمین را افزایش دهند.
طی این سال‌ها یک تيم نرم‌افزاري بنام "تیم راه‌حل‌های چابك و سریع" شروع به جمع‌آوري سنجه‌هاي جدید تخمين پروژه‌های نرم‌افزاری نموده است [2].
8. روش پژوهش
از آنجا که هدف این تحقیق ارائه يك روش جديد و افزایش دانش جدید در حوزه تخمين پروژه‌هاي نرم‌افزاري است اين تحقيق یک تحقیق بنیادی است و از طرفي چون به دنبال ارايه يك الگوی مناسب و عملي براي تخمين پروژه‌هاي نرم‌افزاري هستيم و الگوي ما در قالب يك نرمافزار كاربردي پيادهسازي خواهد شد از نظر نوع هدف، تحقيق ما كاربردي هم می‌باشد.
اين تحقيق از نظر روش جمع‌آوري داده‌ها از نوع "توصيفي" مي‌باشد. تحقيق توصيفي را مي‌توان به پنج دسته پيمايشي، همبستگي، اقدام پژوهي، بررسي موردي و پس رويدادي تقسيم كرد که تحقیق حاضر از نوع تحقیق اقدام پژوهي و بررسي موردي می‌باشد.
9. یافته‌های پژوهش
ما در اين تحقيق مختص تخمين نرم‌افزارهاي تراكنشي و مبتني بر داده به روشی دست یافته‌ایم که ورودي مورد نياز آن نيازمندي‌هاي عملكردي سامانه مي‌باشد. اين روش مناسب جهت تخمين در مراحل اوليه پروژه است. هدف از ارایه اين روش رسيدن به يك سنجه مناسب براي اندازه‌گيري نرمافزار است كه با تعداد خطوط كد تناسب زيادي داشته باشد و در يكي از زمينه‌هاي سادگي، دقت و سرعت از سنجه‌هاي ديگر بهتر باشد.
روش پيشنهادي ما پس از شناسايي نقاط ضعف و قوت روش‌های موجود، در راستاي تقويت نقاط قوت و رفع نواقص ارایه گرديده است. اين روش كليه مولفه‌هاي موثر در روشهاي دیگر تخمین پروژه‌های نرم‌افزاری را مد نظر قرار مي‌دهد.
10. روش تخمين درجه تراكنش منطقي12
در اين روش هر مورد کاربرد به تعدادي تراکنش شکسته مي‌شود. اندازه هر تراکنش بصورت جداگانه بر اساس فاکتورهاي اندازه تراکنش (TSF) به دست مي‌آيد. سپس با جمع کردن اندازه تراکنش‌هاي هر مورد کابرد، اندازه هر مورد کاربرد و در نهايت با جمع کردن اندازه موارد کاربرد، اندازه کل پروژه به دست مي‌آيد. اندازه‌هاي بدست آمده براي تراکنش‌ها، موارد کاربرد و کل پروژه بر مبناي سنجه ابداعي با نام درجه تراکنش منطقي (LTP) مي‌باشد. در اين مقاله اثبات خواهيم کرد که اندازه‌هاي بدست آمده بر اساس اين سنجه (نسبت به سنجه UCP) همبستگي بيشتري با اندازه واقعي نرمافزار (بر اساس سنجه KLOC) دارد.
11. انواع تراکنش‌هاي منطقي
نيازمندي‌ها كارهايي هستند كه برنامه بايد انجام دهد و چگونگي آن مهم نيست نيازمندي‌ها قابليت‌ها و شرايطي هستند كه سيستم و پروژه بايد از آن‌ها پيروي نمايد. نيازمندي‌ها به دو دسته تقسيم مي‌شوند:
1- عملكردي13: چه كارهايي بايد انجام شود (رفتار سيستم).
2- غيرعملكردي14: كارها چگونه بايد انجام شوند (صفات سيستم) [1].
در نرم‌افزارهاي تراکنشي نيازمندي‌هاي عملكردي كاربران در قالب دو بخش ورود اطلاعات به سامانه و خروج اطلاعات از سامانه قرار مي‌گيرند.
ورود اطلاعات به سامانه معادل با تراكنش‌هاي منطقي ثبت اطلاعات و خروج اطلاعات از سامانه متناظر با تراكنش‌هاي منطقي مشاهده اطلاعات مي‌باشد. از طرفي كدهايي كه برآورده‌كننده نيازمندي عملكردي سامانه نرم‌افزاري مي‌باشند، در نهايت منجر به يكي از تراكنش‌هاي منطقي ثبت، ويرايش، حذف و مشاهده اطلاعات مي‌شوند. پس جهت اندازه‌گيري بخش عملكردي نرمافزار مي‌توان تعداد و ويژگي‌هاي تراكنش‌هاي منطقي ثبت، ويرايش، حذف و مشاهده را طي يك مرحله تحقق15 از موارد کاربرد استخراج كرد.
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 پروژه فضاي نمونه آماري، تعداد ده پروژه را جهت ورزيدگي16 مدل پيشنهادي و در راستاي افزايش دقت وزن‌هاي تعيين شده جهت عوامل موثر در اندازه تراكنش‌هاي منطقي (جدول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) بدست آورديم. البته حاصل جمع وزن تراكنش‌ها در واقع ULTP17 يعني اندازه تعديل‌نشده نرمافزار است كه با اعمال فاكتورهاي فني و محيطي تعديل خواهد شد. رابطه محاسبه ULTP براي هر تراكنش به صورت زير است:
رابطه (1) | ULTP = ∑1..6 TSFi |
رابطه (2) | ULTP = ∑1..n ( ∑1..6 TSFi ) |
در اينجا n تعداد تراكنش‌هاي منطقي پروژه و TSFi وزن فاكتـور موثر بر هر تراكـنش مـي‌باشد. لازم به ذكر اسـت كه TSFiها بر حسب نوع تراكنش و با استفاده از جدول2 و3 تعيين مي‌گردند. به عنوان مثال براي يك تراكنش حذف طبق جدول2 فقط فاكتور موثر بر آن يعني TSF2 مقداردهي و مابقي فاكتورها بصورت پيش‌فرض صفر در نظر گرفته مي‌شوند.
16. مطالعه موردي و اثبات روش
ما جهت اثبات دقيق‌تر بودن اين روش نسبت به روش UCP از روش مطالعه موردي18 و تحليل‌هاي آمار استنباطي استفاده نموديم. در اين راستا تعداد 15 پروژه نرم‌افزاري انجام شده را مورد بررسي قرار داديم كه با توجه به اينكه تعداد موارد کاربرد در اين پروژه‌ها كمتر از 20 موردکاربرد بود اين پروژه‌ها جزء پروژه‌هاي كوچك محسوب مي‌شدند. فرايند توليد اين پروژه‌ها مبتني بر RUP ، محيط برنامه نويسي آن‌ها C#.Net و پايگاه داده آن‌ها SQL Server 2000 بود.
در ادامه با رعايت کليه موارد زير، تعداد خطوط كد پروژه‌ها (LOC) را محاسبه نموديم.
1. كدهايي كه در راستاي آزمون و پشتيباني سامانه نباشند، محاسبه مي‌شوند.
2. خطوطي از كد كه به وسيله كاركنان تيم پروژه توليد مي‌شود، مد نظر است.
3. کدهايي که به وسيله سازنده‌هاي خودكار كد19 توليد مي‌شوند محاسبه نمي‌گردند.
4. تعريف متغيرها20 جزء کد هستند ولي توضيحات21 شمارش نمي‌شوند[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 (علامت **) وجود دارد. ولي ضريب همبستگي پيرسون22 در متغير ULTP نسبت به ضريب همبستگي پيرسون در متغير UUCP به اندازه 049/0 به عدد يك نزديك‌تر است و اين مساله نشان مي‌دهد كه همبستگي ULTP به LOC به اندازه 049/0 از همبستگي UUCP به LOC بيشتر است.
در اين تحليل LOC را متغير وابسته و UUCP و ULTP را متغير مستقل در نظر گرفتيم كه پس از انجام تحليل، خروجي آن در قالب جدول7 به دست آمد.
جدول 7. ضرايب رگرسيون
مدل | ضريب استاندارد نشده | ضريب استاندارد شده | T | Sig. | |
B | استاندارد خطا | بتا | |||
(ثابت) | 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 رابطه اول کمترين مجذورهاي متداول23 به صورت زير نتيجه مي‌شود:
رابطه (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 |
UUCW | وزن تعديل نشده موردکاربرد | TSF1-TSF6 | |||
19. پيادهسازي
ما بر اساس روش پيشنهادي، نرم‌افزاري به نام ابزار تخمين درجه تراكنش منطقي يا LTP-SE24 پيادهسازي نموديم. همان‌طور که در شکل1 نشان داده شده است ورودي اين ابزار، اطلاعات تراكنش‌هاي منطقي پروژه نرم‌افزاري به تفكيك موردکاربرد و خروجي آن، اندازه هر موردکاربرد يا اندازه كل پروژه مي‌باشد.
ابزار LTP-SE در محيط .Net2005 تحت وب و با زبان برنامه نويسي C# پيادهسازي و از SQL 2005 به عنوان پايگاه داده استفاده مي‌كند. نرمافزار LTP-SE داراي سه لايه واسط كاربري25، لايه دسترسي به داده26 و پايگاه داده27 مي‌باشد.
20. نتیجه گیری و پیشنهادات
بر اساس تحلیل‌های آماری انجام شده نتیجه می‌گیریم روش LTP نسبت به روش UCP دقيق‌تر مي‌باشد و بر خلاف روشUCP به ترسيم نمودار فعاليت (سناريو گام به گام) موردکاربرد نياز ندارد. همچنین با توجه به جدول شماره5 این روش كليه عوامل موجود در روشهاي COCOMO، UCP و FP را پوشش داده و در مقايسه با روش FP براي الگوريتم‌ها (در قالب پيچيدگي محاسبات) ضريبي لحاظ نموده است.
این روش جهت تخمين در فازهاي اوليه پروژه مناسب است و با روشهاي متداول امروزي مانند RUP سازگار است. قابليت انعطاف و تطبيق زيادي دارد و بدليل فرمال بودن روش، ابهام آن كم است.
خروجي و محصولات فرعي اين روش در چارچوب فرايند توسعه نرمافزار (مثلا در ترسيم نمودار اشيا تجاري28) قابل استفاده است.
بنـابراین پیشنهاد می‌شود پژوهشگران علاقه‌مند در رابطه با
منابع 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