قيق همه را با لفظ خطا و هم معني در نظر ميگيريم.
3.2.2. ليست نامهها و گفتگوهاي ثبت شده
ليست ايميلها (يا آرشيو بحثها) همراه با گفتگوهاي ثبت شده بين افراد دخيل در يک پروژه آرشيوي از ارتباطات متني توسعهدهندگان ، مديران و ذينفعان آن پروژه هستند. ليست متني متشکل از بستههاي الکترونيکي که شامل سه قسمت:
سرآيند (فرستنده ،گيرنده و زمان ارسال)
بدنه پيغام(متن داخل ايميل)
مجموعهاياز فايلهاي پيوستشده(مستندات اضافي که همراه ايميل فرستاده میشود) ميباشد.
شرح گفتگوها شامل ثبت مکالمات فوري بين ذينفعان پروژه، که بر حسب زمان يا نويسنده دستهبندي شدهاند، ميباشد.
4.2.2 .پايگاه داده کنترل منبع (پايگاه داده کنترل ويرايش ها)
سيستمي براي ثبت تاريخ تغييرات (ويرايشها) بههمراه خود ويرايش و اطلاعات ديگر به صورت اسناد و اطلاعات متني است. توسعهدهندگان معمولا تاريخ و زمان ويرايش يک کد اصلي را در پايگاه دادههايي ذخيره ميکنند. پايگاه دادههاي کنترل کد رايج مانند] cvs 13[ و] svn 14[ ، به توسعه دهندگان اجازه ميدهند به يک کپي از مخزن سراسري و جهاني، در سيستم فايلهاي محلي خود، دسترسي داشته باشند. اسناد موجود را ويرايش کند، يا اطلاعاتي اضافه يا کم کند و يا ساختار دايرکتوري اين مخازن را تغيير دهند. همچنين ميتواند در مخزن اصلي سند يا اطلاعات جديد محلي ايجاد کند.
بنابراين کنترل بازبينيها دو نتيجه مهم در بر خواهد داشت:
اول اينکه به توسعهدهندگان اجازه ميدهد، مستقل از کساني که به مخازن دسترسي دارند، فايلهاي روي سيستمهاي خود را تغيير دهند . پس از آن که تغييرات تاييد شده ايجاد شد بقيه ميتوانند اين تغيرات را بررسيکنند. اين استقلال کاري اجازه ميدهد که يک چرخه کار موازي بدون نياز به ارسال ايميل و گفتگو و نيز بدون تغيرات ورژن برنامه به عقب و جلو تشکيل شود.
دوم اينکه زمان و تاريخ همه اطلاعات و مستندات به صورت خودکار ثبت و نگهداري ميشود. اگر نسخههاي قبل نرمافزار نياز بود، توسعهدهندگان بهراحتي ميتوانند به نسخههاي قبل سيستم دسترسي داشته باشند و سيستم را به نسخه قبلي برگردانند.
5.2.2. اطلاعات طراحي و نيازمنديهاي سيستم
مستندات نيازمنديها، معمولا در ارتباط با مشتري و يا با تاييدهاي او تنظيم ميشود. اين اسناد ليستي از نيازهاي مشتري است که خواهان انجام آن توسط سيستم است. اين نيازها به دو صورت دستهبندي ميشوند. اينکه چه نيازهايي را سيستم بايد برطرف کند و چگونه و با چه کيفيتي موردانتظار مشتري است. اطلاعات طراحي نيز شامل تمام اطلاعات مربوط به طراحيمعماري و الگوريتمهاي مهم و مورد استفاده18 سيستم است. طراحي سيستم ميتواند به شکل نمودار(مانند UML) و يا بهصورت متون جريان کار نمايش داده شوند.

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

7.2.2. مخازن سيستم نرم افزار
مخازن سيستم نرمافزار شامل مجموعهاي از سيستمهاي مختلف به همراه کد اصلي آنها که افراد علاقهمند ميتوانند بهراحتي در آن جستجو کرده و از آنها استفاده نمايند. از مخازن مهم رايج در اين حوزه ميتوان به Source Forge ]15 [وGoogle Code ]16[ اشاره کرد.
اين مخازن شامل آرايه وسيعي از اطلاعات در حوزههاي مختلف پروژههاي نرمافزاري است که ميتوان اطلاعات غني را در فازهاي مختلف آن استخراج کرد. آنچه بهعنوان منابع داده در اين تحقيق مورد استفاده قرار ميگيرد همان مخازن خطا است. که با استفاده از يک سيستم رديابي خطا نمونههاي آماري لازم استخراج مي شود]17[.

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

1.3.2.سيستم رديابي خطا
سيستم رديابي خطا يک برنامه نرمافزاري است که براي کمک در سهولت پيگيري خطاهاي نرم افزاري در طول عمر پروژه طراحي و ارائه شدهاست. اين سيستم يک نرمافزار کاربردي براي تيم توسعه است بهطوري که به آنها در تضمين کيفيت و کاهش هزينه ها و پيشرفت سريع پروژه کمک ميکند. اين سيستمها به کليه افراد دخيل در يک پروژه اعم از کاربران، توسعهدهندگان و ذينفعان ديگر اجازه ميدهد که خطاي رويت شده در نرمافزار را در هر مرحله از روند توليد که باشد گزارش داده و پيگيري کنند. بسياري از پروژههاي بزرگ از اين نرمافزارها استفادهکرده و پروژه
هاي خود را در نسخههاي مختلف ارائه ميدهند. تا در مراحل مختلف از ارائه نسخه جديد خطاهاي نسخه قبلي که ديگران گزارش دادهاند پيگيري و رفع کنند. پروژه در هر حالتي ارائه شود، چه بهصورت مرحلهاي يا کامل، متنباز يا بسته و با هر متد استفاده شده در مهندسي نرمافزار ، يک سيستم رديابي خطا در پيشبرد بهتر و سريعتر فرآيند مهندسي نرمافزار بسيار ارزشمند است.
بسياري از اين نرمافزارها براي استفاده عموم طراحي شده و بقيه تنها براي استفاده در يک پروژه طراحي ميشوند. معمولا سيستمهاي رديابي خطا با ديگر اپليکيشنهاي مديريت پروژه يکپارچه و مجتمع ميشوند]18[. مهمترين قسمت اين سيستمها مخازن اطلاعاتي آنهاست که کليه اطلاعات مربوط به خطا را در خود ذخيره ميکنند. بايد ديد در يک سيستم رديابي خطا ايدهال چه اتفاقي ميافتد و يک خطا چه چرخهاي را در طول عمر خود در آن طي ميکند. بهعنوان مثال باگزيلا20يک سيستم رديابي خطا است که در سال 1998 توسط تري ويسمن21 براي شرکت موزيلا22 نوشته شد.
در ابتدا باگزيلا بهعنوان يک سيستم رديابي خطا متنباز از داخل خانه براي کاربران مرتبط با نت اسکيپ23 طراحي شد. ابتدا به زبان TCL24 و سپس به Perl براي راحتي و سهولت استفاده و دخالت همگان در پيشرفت کار برگردانده شد. اين سيستم براي استفاده در پروژههاي متن باز بهينهسازي شد. بهطوري که شرکتها و پروژههاي بزرگي چون ياهو، ناسا،Gnome ، KDE ، Apache ، RedHat، ويکي مديا و خود موزيلا از آن استفاده کردند هر خطا يک شناسه(ID)، عنوان، تاريخ، وضعيت، نام محصول و مولفه، ميزان شدت سختي و پيچيدگي، اولويت و غيره را در خصوصيات خود دارد]9 [(شکل2-1).

شکل2- 1-مشخصات يک موضوع (خطا)در نرم افزار Bugzilla

يک خطا از زمان ايجاد تا زمان بستهشدن(حل مشکل) چرخهاي را در سيستم دارد(شکل2-2) نمودار فعاليت برای يک مخزن خطا در شکل2-3 نشان داده شدهاست.

شکل2- 2 – چرخه يک خطا در يک سيستم مديريت خطا]19[

شکل2- 3 – نمودار جريان کار25 يک سيستم رديابی خطا
خطا جديد (NEW ) يا تاييد شده وارد سيستم ميشود(unconfirmed) اگر اعتبار خطا توسط يکي از اعضاي تيم يا هسته مديريتي تاييد شد، بهعنوان يک گروه جديد ثبت ميشود.
مديران وکساني که مسئول ارزيابي خطاها هستند بايد وجود خطا را تاييد کنند. اعتبار و غيرتکراري بودن آن را نيز بررسيکنند. اگر خطا تاييد شد به قسمت تاييد شدهها (Assigned) رفته، تا در اختيار تيم توسعه براي حل و فصل و رفع خطا قرار گيرد. در غير اين صورت به قسمت تاييد نشده ( unconfirmed ) براي بررسي بيشتر ميرود.
اگر خطا رفع شد برچسب حل شده ( Resolved ) خورده و آن را به وضعيت حل شده انتقال ميدهند.
اعضاي تيم ممکن است يک خطا حلشده را به يکي از حالتهاي سازگار(Verified) و سپس بسته (Closed) اتصال دهند. يا دوباره به شکلي در رابطه با اين خطا مواجه شدند و آن را به حالت دوباره باز يا تاييد شده بفرستند.
خطاهايي که به مرحله Resolved بازگردانده ميشوند يا نامعتبرند يا تکراري هستند و نياز به بررسي مجدد دارند و يا بهطور کامل رفع شدهاند. چرخه عمر يک خطا از مرحلهی جديد تا مرحله خروج از حل تعريف ميشود. شکل2-4 وظايف هر يک از اشخاص در ارتباط با مخزن خطا را نشان میدهد. دو كادر قرمز دردو نمودار شکل2-4 و شکل2-3 محدوده كاري اين تحقيق را نشان ميدهند.

شکل2-4- نمودار مورد کاربرد26 يک سيستم رديابی خطا
همانطور که در شکل2-5 ميبينيد، يک خطا داراي مشخصات متني است. برچسب، وضعيت خلاصه و در قسمت جزئيات توضيحات و راهحلهاي ارائه شده با ذکر نام نويسنده و تاريخ براي هر خطا درج شده است. همين اطلاعات و متون ثبت شده دامنه کار تحقيقاتي ماست. اين دادهها منبع غني اطلاعات و دانش سودمند است. اينکه چگونه اين دادهها را کاوش کنيم و چه اطلاعاتي در آنها نهفته است، گامهاي تحقيق ما را ميسازند. از آنجايي که اين دادهها توسط افراد مختلف و با استفاده از قوانين نحوي صحيح و ناصحيح و گاه کلمات مشابه دريک حوزه استفاده شدهاند نياز به يک جستجو معنايي به شدت احساس ميشوند.

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

4.2.تحقيقات پيشين در حوزه دادهکاوي در مخازن خطا
در سال 1992 اولين نرمافزار رديابي خطا GNATS27 شروعي براي MSR بود. با ارائه اولين نرمافزار رديابي خطا، مديريت و استفاده از دانش نهفته در خطاها اولين قدمهاي خود را برداشت. در اين مدت محققان سعيکردند براي استخراج بهينه و مفيدتر دانش، مدلها و روشهاي جديدي با استفاده از الگوريتمهاي مختلف ارائه کنند. بيشتر اين روشها از الگوريتمهاي دستهبندي براي دستهبندي اطلاعات و استفاده از دانش آنها بهصورت طبقهبندي شده استفاده کردند. ابتدا مروري کوتاه بر تحقيقات قبلي و روش هاي بررسي شده خواهيم داشت. نواقص و کمبودهايي که به موجب آن ها اين تحقيق انجام شده و روش ارائه شدهاست نيز بررسی خواهد شد.
سال 2000، JunzoWatada به منظور برآورد تعداد خطاها در يک پروژه نرمافزاري از رگرسيون فازي استفادهکرد]6[. وي مجموعه سئوالاتي را براي استفاده در سيستم فازي در مراحل مختلف از يک پروژه مطرح کرد. در اين روش تمام دادهها براي جستجو هدف قرار نميگيرد و اين خود ضعف بزرگي است.
Lucas D.Panger در سال 2007 مقايسهاي براي دستهبندي مخازن خطا با استفاده از پنج الگوريتم دسته بندي 0-R ،1-R، درخت تصميمگيري C4.5 ،Naïve Bayes و رگرسيون لجستيک، در دادههاي گرفته شده از Bugzilla انجام دادهاست]5[. اين کار با محاسبه درصد خطاهايي که دستهبندي شدهاند و ضريب Kappa براي هر کدام با استفاده از نرمافزار Weka انجام داده است. دادهها بر اساس طول عمروتوضيحات متني دستهبندي شدهاند. اين تحقيق تنها مقايسهاي بين الگوريتمهاي مختلف در يک دستهبندي ساده براي دادههاي موجود در يک مخزن است، که کمتر به شباهت بين يک خطا جديد و خطاهاي ديگر پرداخته شده است.
در همان سال CathrinWeib و همکارانش با استفاده از دادههاي گرفته شده از JBoss در سه مرحله طول عمر خطای جديد را تخمين زدند]9[. ابتدا بهکمک الگوريتم نزديکترين همسايهKNN-α گزارشهاي مشابه را از منبع استخراج ميکند و در مرحله بعد با استفاده از موتور جستجوLucene دادهها با شباهت متني بيشتر استخراج ميشود. Lucene ازSVM و يک مدل بولي28 براي جستجو و ارزيابي متون استفاده ميکند. در اين تحقيق اگر موضوع با شباهت با توضيحات خطای جديد پيدا نشد، باز الگوريتم نزديکترين همسايه KNN-α را براي استخراج داده استفاده ميشود پس از اين مراحل دادههاي فيلترشده ميتواند در تخمين طول عمر خطا جديد و حل آن کمک ميکند. اين روش جزء روشهاي ابتدايي با بهکارگيري اندازهگيري تشابه بين متون بود. اما موتور و الگوريتم آن نهتنها به معناي کلمات توجه نميکرد بلکه جزه روشهاي ابتدايي جستجو در متون متشابه بود.
Nagwani در سال 2009 روشي را با دامنه خطاهاي حوزه GUI ارائه کرد. در اين تحقيق خطاهاي مربوط به GUI را از پروژه مختلف را به عنوان داده در نظر گرفت. از نظر او خطا در طول فرآيندی رخ مي دهد که اين فرآيند شامل چند رويداد متوالي است]1[. مدل وي در سه مرحله داده ها را فيلتر مي کند. در مرحله اول داده ها


دیدگاهتان را بنویسید