۲٫۲٫ انواع مخازن داده
۱٫۲٫۲٫کد اصلی:
کد اصلی بخش قابل ­اجرا و رفتار یک توسعه نرم­افزاری است. که در نهایت به ­صورت فرمت اجرایی به مشتری تحویل داده می­ شود. که عموما به ­عنوان مهمترین داده از سوی توسعه­دهندگان مورد توجه قرار می­گیرد. مخزن حاوی این اطلاعات شامل تعدادی از منابع کد و اسناد در یک یا چند زبان مختلف برنامه­نویسی است. این اسناد معمولا به موجودیت­های منطقی به نام­های ماژول^[۱۳]یا بسته گروه­بندی می­شوند. تمام این مجموعه اطلاعات کد اصلی سیستم نامیده می­ شود. برای کاوش این متون تمرکز روی شناسه­ها (متغیر، نام)، توضیحات و رشته­ های اصلی داخل کد اصلی است. معمولا کلمات کلیدی و نمادها در نظر گرفته نمی­شوند.
(( اینجا فقط تکه ای از متن درج شده است. برای خرید متن کامل فایل پایان نامه با فرمت ورد می توانید به سایت nefo.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. ))

۲٫۲٫۲٫ مخازن خطا(سیستم ردیابی خطا BTS^[14])
این مخازن برای ذخیره اطلاعات مربوط به ایجاد و حل خطا، مشخصات ارتقاء سیستم و کلیه اقدامات دیگر در مرحله تعمیر و نگهداری استفاده می­شوند. معمولا هنگامی­که توسعه­دهندگان و کاربران به مشکل یا خطایی در یک سیستم نرم­افزاری مواجه می­شوند، یادداشتی درباره این خطا در پایگاه ­داده خطا در موضوع مربوطه ذخیره­ می­ شود. این اطلاعات شامل: علت و مکان وقوع خطا در برنامه و اینکه چگونه خطا باعث ایجاد اشکال و خلل در روند برنامه شده­ است. پس از آن یک یا چند متخصص، موضوع ایجاد ­شده را برای رفع مشکل بررسی می­ کنند. چنانچه خطا برطرف شود موضوع در فرم مربوطه بسته­ می­ شود. تمام این اطلاعات در مخازن و پایگاه­های خطا ذخیره می­شوند. عمومی­ترین سیستم­های مخازن خطا Bugzilla ، Trac هستند.
اگرچه تا به امروز سیستم­های متعددی ساخته شده ­اند. در حالت ­عادی بین خطا^[۱۵]، نقص^[۱۶]، عیب^[۱۷] تفاوت قائل می­شویم، اما در این تحقیق همه را با لفظ خطا و هم معنی در نظر می­گیریم.
۳٫۲٫۲٫ لیست نامه­ ها و گفتگو­های ثبت شده
لیست ایمیل­ها (یا آرشیو بحث­ها) همراه با گفتگوهای ثبت شده بین افراد دخیل در یک پروژه آرشیوی از ارتباطات متنی توسعه­دهندگان ، مدیران و ذینفعان آن پروژه هستند. لیست متنی متشکل از بسته­های الکترونیکی که شامل سه قسمت:
سرآیند (فرستنده ،گیرنده و زمان ارسال)
بدنه پیغام­(متن داخل ایمیل)
مجموعه ­ای­از فایل­های پیوست­شده(مستندات اضافی که همراه ایمیل فرستاده ­می­ شود) می­باشد.
شرح گفتگو­ها شامل ثبت مکالمات فوری بین ذینفعان پروژه، که بر حسب زمان یا نویسنده دسته­بندی شده ­اند، می­باشد.
۴٫۲٫۲ .پایگاه داده کنترل منبع (پایگاه داده کنترل ویرایش ها)
سیستمی برای ثبت تاریخ تغییرات (ویرایش­ها) به­همراه خود ویرایش و اطلاعات دیگر به ­صورت اسناد و اطلاعات متنی است. توسعه­دهندگان معمولا تاریخ و زمان ویرایش یک کد اصلی را در پایگاه داده­هایی ذخیره می­ کنند. پایگاه داده ­های کنترل کد رایج مانند] cvs 13[ و] svn 14[ ، به توسعه ­دهندگان اجازه می­ دهند به یک کپی از مخزن سراسری و جهانی، در سیستم فایل­های محلی خود، دسترسی داشته باشند. اسناد موجود را ویرایش کند، یا اطلاعاتی اضافه یا کم کند و یا ساختار دایرکتوری این مخازن را تغییر دهند. همچنین می ­تواند در مخزن اصلی سند یا اطلاعات جدید محلی ایجاد کند.
بنابراین کنترل بازبینی­ها دو نتیجه مهم در بر خواهد داشت:
اول اینکه به توسعه­دهندگان اجازه می­دهد، مستقل از کسانی که به مخازن دسترسی دارند، فایل­های روی سیستم­های خود را تغییر دهند . پس از آن که تغییرات تایید شده ایجاد شد بقیه می­توانند این تغیرات را بررسی­کنند. این استقلال کاری اجازه می­دهد که یک چرخه کار موازی بدون نیاز به ارسال ایمیل و گفتگو و نیز بدون تغیرات ورژن برنامه به عقب و جلو تشکیل شود.
دوم اینکه زمان و تاریخ همه اطلاعات و مستندات به صورت خودکار ثبت و نگهداری می­ شود. اگر نسخه­های قبل نرم­افزار نیاز بود­، توسعه­دهندگان به­راحتی می­توانند به نسخه­های قبل سیستم دسترسی داشته باشند و سیستم را به نسخه قبلی برگردانند.
۵٫۲٫۲٫ اطلاعات طراحی و نیازمندی­های سیستم
مستندات نیازمندی­ها، معمولا در ارتباط با مشتری و یا با تایید­های او تنظیم می­ شود. این اسناد لیستی از نیازهای مشتری است که خواهان انجام آن توسط سیستم است. این نیازها به دو صورت دسته­بندی می­شوند. اینکه چه نیازهایی را سیستم باید برطرف کند و چگونه و با چه کیفیتی مورد­­انتظار مشتری است. اطلاعات طراحی نیز شامل تمام اطلاعات مربوط به طراحی­معماری و الگوریتم­های مهم و مورد استفاده^[۱۸] سیستم است. طراحی سیستم می ­تواند به شکل نمودار(مانند UML) و یا به­ صورت متون جریان کار نمایش داده شوند.
۶٫۲٫۲٫ مخازن شرح اجرا
اطلاعات مربوط به خروجی یک برنامه در حین یک یا چند بار اجرا، بر حسب آن­ چه که در قسمت تست مشخص شده ثبت می­ شود. این اطلاعات شامل لیستی از زمان و دلیل اجرا شدن متدهای یک سیستم، مقادیر قطعی متغیرها و جزئیات مربوط به شرایط اجراست. این لیست هنگامی مفید است که فرایند اشکال­زدایی در مقیاس وسیع همزمان با هزاران یا میلیون­ها فرایند دیگر از سوی افراد مختلف انجام شود. در این هنگام پیدا کردن اشکالات فردی لازم اما کاری دشوار و زمان بر است. این مخازن کمک می­ کنند به تک تک این اجراها با جزئیات دسترسی داشته ­باشیم.
۷٫۲٫۲٫ مخازن سیستم نرم افزار
مخازن سیستم نرم­افزار شامل مجموعه ­ای از سیستم­های مختلف به همراه کد اصلی آنها که افراد علاقه­مند می­توانند به­راحتی در آن جستجو کرده و از آنها استفاده نمایند. از مخازن مهم رایج در این حوزه می­توان به Source Forge ]15 [وGoogle Code ]16[ اشاره کرد.
این مخازن شامل آرایه وسیعی از اطلاعات در حوزه ­های مختلف پروژه­ های نرم­افزاری است که می­توان اطلاعات غنی را در فازهای مختلف آن استخراج کرد. آن­چه به­عنوان منابع داده در این تحقیق مورد استفاده قرار می­گیرد همان مخازن خطا است. که با بهره گرفتن از یک سیستم ردیابی خطا نمونه­های آماری لازم استخراج می شود]۱۷[.
۳٫۲٫ خطای نرم­افزاری
اشکال نرم­افزاری، خطا، نقص و یا شکست ایجاد شده در برنامه کامپیوتری است، که باعث تولید یک نتیجه نادرست یا غیرمنتظره می­ شود. یا باعث بروز رفتار ناخواسته از سیستم می­گردد. رفع این مشکلات در پروژه­ های نرم­افزاری از سخت­ترین و پر هزینه­ترین مراحل مهندسی نرم­افزار است. این خطاها می ­تواند در پروژه­ های بزرگ ومخصوصا پروژه­ های متن باز^[۱۹] از سوی همه کاربران و توسعه­دهندگان گزارش شوند. از این رو نرم افزارهای ردیابی خطا به کمک آمده تا بتوان این گزارشات را ثبت و پی­گیری کرد. خاطر نشان می­کنم که در این تحقیق همان­طور که قبلا گفتیم مشکلات اعم از نقص، شکست یا خطا با عنوان خطای نرم­افزاری معرفی می­ شود.
۱٫۳٫۲٫سیستم ردیابی خطا
سیستم ردیابی خطا یک برنامه نرم­افزاری است که برای کمک در سهولت پی­گیری خطاهای نرم افزاری در طول عمر پروژه طراحی و ارائه شده­است. این سیستم یک نرم­افزار کاربردی برای تیم توسعه است به­ طوری که به ­آن­ها در تضمین کیفیت و کاهش هزینه ها و پیشرفت سریع پروژه کمک می­ کند. این سیستم­ها به کلیه افراد دخیل در یک پروژه اعم از کاربران، توسعه­دهندگان و ذینفعان دیگر اجازه می­دهد که خطای رویت ­شده در نرم­افزار را در هر مرحله از روند تولید که باشد گزارش داده و پیگیری کنند. بسیاری از پروژه­ های بزرگ از این نرم­افزارها استفاده­کرده و پروژه­ های خود را در نسخه­های مختلف ارائه می­ دهند. تا در مراحل مختلف از ارائه نسخه جدید خطاهای نسخه قبلی که دیگران گزارش داده­اند پیگیری و رفع کنند. پروژه در هر حالتی ارائه شود، چه به­ صورت مرحله­ ای یا کامل، متن­باز یا بسته و با هر متد استفاده شده در مهندسی نرم­افزار ، یک سیستم ردیابی خطا در پیشبرد بهتر و سریع­تر فرایند مهندسی نرم­افزار بسیار ارزشمند است.
بسیاری از این نرم­افزارها برای استفاده عموم طراحی شده و بقیه تنها برای استفاده در یک پروژه طراحی می­شوند. معمولا سیستم­های ردیابی خطا با دیگر اپلیکیشن­های مدیریت پروژه یکپارچه و مجتمع می­شوند]۱۸[. مهمترین قسمت این سیستم­ها مخازن اطلاعاتی آن­هاست که کلیه اطلاعات مربوط به خطا را در خود ذخیره می­ کنند. باید دید در یک سیستم ردیابی خطا ایده­ال چه اتفاقی می­افتد و یک خطا چه چرخه­ای را در طول عمر خود در آن طی می­ کند. به­عنوان مثال باگزیلا^[۲۰]یک سیستم ردیابی خطا است که در سال ۱۹۹۸ توسط تری ویسمن^[۲۱] برای شرکت موزیلا^[۲۲] نوشته شد.
در ابتدا باگزیلا به­عنوان یک سیستم ردیابی خطا متن­باز از داخل خانه برای کاربران مرتبط با نت اسکیپ^[۲۳] طراحی شد. ابتدا به زبان TCL^[24] و سپس به Perl برای راحتی و سهولت استفاده و دخالت همگان در پیشرفت کار برگردانده شد. این سیستم برای استفاده در پروژه­ های متن باز بهینه­سازی شد. به­ طوری که شرکت­ها و پروژه­ های بزرگی چون یاهو، ناسا،Gnome ، KDE ، Apache ، RedHat، ویکی مدیا و خود موزیلا از آن استفاده کردند هر خطا یک شناسه(ID)، عنوان، تاریخ، وضعیت، نام محصول و مولفه، میزان شدت سختی و پیچیدگی، اولویت و غیره را در خصوصیات خود دارد]۹ [(شکل۲-۱).
شکل۲- ۱-مشخصات یک موضوع (خطا)در نرم افزار Bugzilla
یک خطا از زمان ایجاد تا زمان بسته­شدن(حل مشکل) چرخه­ای را در سیستم دارد(شکل۲-۲) نمودار فعالیت برای یک مخزن خطا در شکل۲-۳ نشان داده شده­است.

شکل۲- ۲ – چرخه یک خطا در یک سیستم مدیریت خطا]۱۹[

شکل۲- ۳ – نمودار جریان کار^[۲۵] یک سیستم ردیابی خطا
خطا جدید (NEW ) یا تایید ­شده وارد سیستم می­ شود(unconfirmed) اگر اعتبار خطا توسط یکی از اعضای تیم یا هسته مدیریتی تایید شد، به­عنوان یک گروه جدید ثبت می­ شود.
مدیران وکسانی که مسئول ارزیابی خطاها هستند باید وجود خطا را تایید کنند. اعتبار و غیرتکراری بودن آن ­را نیز بررسی­کنند. اگر خطا تایید شد به قسمت تایید شده­ها (Assigned) رفته، تا در اختیار تیم توسعه برای حل و فصل و رفع خطا قرار گیرد. در غیر این صورت به قسمت تایید نشده ( unconfirmed ) برای بررسی بیشتر می­رود.
اگر خطا رفع شد برچسب حل شده ( Resolved ) خورده و آن را به وضعیت حل شده انتقال می­ دهند.
اعضای تیم ممکن است یک خطا حل­شده را به یکی از حالت­های سازگار(Verified) و سپس بسته (Closed) اتصال دهند. یا دوباره به شکلی در رابطه با این خطا مواجه شدند و آن را به حالت دوباره باز یا تایید شده بفرستند.
خطا­هایی که به مرحله Resolved بازگردانده می­شوند یا نامعتبرند یا تکراری هستند و نیاز به بررسی مجدد دارند و یا به­ طور کامل رفع شده ­اند. چرخه عمر یک خطا از مرحله­ جدید تا مرحله خروج از حل تعریف می­ شود. شکل۲-۴ وظایف هر یک از اشخاص در ارتباط با مخزن خطا را نشان می­دهد. دو کادر قرمز در­دو نمودار شکل۲-۴ و شکل۲-۳ محدوده کاری این تحقیق را نشان می­ دهند.
شکل۲-۴- نمودار مورد کاربرد^[۲۶] یک سیستم ردیابی خطا
همان­طور که در شکل۲-۵ می­بینید، یک خطا دارای مشخصات متنی است. برچسب، وضعیت خلاصه و در قسمت جزئیات توضیحات و راه­ حل­های ارائه ­شده با ذکر نام نویسنده و تاریخ برای هر خطا درج شده است. همین اطلاعات و متون ثبت شده دامنه کار تحقیقاتی ماست. این داده ­ها منبع غنی اطلاعات و دانش سودمند است. اینکه چگونه این داده ­ها را کاوش کنیم و چه اطلاعاتی در آن­ها نهفته است، گام­های تحقیق ما را می­سازند. از آنجایی که این داده ­ها توسط افراد مختلف و با بهره گرفتن از قوانین نحوی صحیح و ناصحیح و گاه کلمات مشابه دریک حوزه استفاده شده ­اند نیاز به یک جستجو معنایی به شدت احساس می­شوند.
شکل۲- ۵-مشخصات یک خطا
پایه و اساس این تحقیق جستجو جملات مشابه معنایی است. به­صورتی که آن­دسته از جملات که دارای تشابه معنایی بیشتری با جمله یا کلمه کاندیدای ما هستند، جداسازی شوند. چگونگی این کار در سه مرحله خلاصه می شود: ابتدا با بهره گرفتن از تکنیک­هایی که در ادامه پیشنهاد می­ شود از میان داده ­های آماری­که از یک مخزن خطا انتخاب شده، میزان تشابه هر خطا (بر اساس داده ­های متنی مانند توضیحات، سرآمد، راه­حل و غیره) با خطای­ جدید اندازه ­گیری می­ شود. در مرحله بعد این خطا با بهره گرفتن از یک الگوریتم خوشه­بندی که سعی شده یک الگوریتم بهینه باشد به دسته­های جدا بر اساس ضریب تشابه محاسبه شده تقسیم می­شوند.
این کار به کاربر کمک می­ کند که نمونه­های مشابه گزینش ­شده را در خوشه­های طبقه ­بندی­ شده از نظر سختی و پیچیدگی کار در اختیار داشته­باشد.گاهی ممکن است کاربر خود بر اساس تجربه حدس بزند که مشکل زیاد پیچیده نیست. یا برعکس مشکل به زمان زیادی برای حل نیاز داشته باشد، در این حالت این خوشه­بندی می ­تواند در کاستن زمان یافتن راه­حل کمک قابل توجهی داشته باشد. آن­چه این کار را از کارهای انجام شده قبلی متمایز می­ کند توجه به بهره­وری و بهبود کارایی است. یک مخزن خطا مجموعه ­ای گسترده و بزرگ از داده­هاست که هر روز بزرگتر می­ شود. با بزرگ شدن نمونه آماری و نیاز به دقت در کار ابعاد پیچیدگی این عمل روشن خواهد ­شد. هدف اصلی این کار استفاده از تکنیکی است که دقت بالاتری داشته باشد. جستجو در یک بانک داده که متون در آن از قانون خاص برای رعایت اصول تحریر و قواعد نحوی استفاده نشده است، و کسانی که داده ­ها را ثبت کرده ­اند ممکن است از کلمات مشابه زیادی استفاده کرده باشند، نیاز بیشتری به یک جستجوی معنایی دارد.
۴٫۲٫تحقیقات پیشین در حوزه داده ­کاوی در مخازن خطا
در سال ۱۹۹۲ اولین نرم­افزار ردیابی خطا GNATS^[27] شروعی برای MSR بود. با ارائه اولین نرم­افزار ردیابی خطا، مدیریت و استفاده از دانش نهفته در خطا­ها اولین قدم­های خود را برداشت. در این مدت محققان سعی­کردند برای استخراج بهینه و مفیدتر دانش، مدل­ها و روش­های ­جدیدی با­ استفاده از الگوریتم­های مختلف ارائه ­کنند. بیشتر این روش­ها از الگوریتم­های دسته­بندی برای دسته­بندی اطلاعات و استفاده از دانش آن­ها به­ صورت طبقه ­بندی شده استفاده کردند. ابتدا مروری کوتاه بر تحقیقات قبلی و روش های بررسی ­شده خواهیم داشت. نواقص و کمبودهایی که به ­موجب آن ­ها این تحقیق انجام شده و روش ارائه شده­است نیز بررسی خواهد شد.
سال ۲۰۰۰، JunzoWatada به ­منظور برآورد تعداد خطا­ها در یک پروژه نرم­افزاری از رگرسیون فازی استفاده­کرد]۶[. وی مجموعه سئوالاتی را برای استفاده در سیستم فازی در مراحل مختلف از یک پروژه مطرح کرد. در این روش تمام داده ­ها برای جستجو هدف قرار نمی­گیرد و این خود ضعف بزرگی است.
Lucas D.Panger در سال ۲۰۰۷ مقایسه­ ای برای دسته­بندی مخازن خطا با بهره گرفتن از پنج الگوریتم دسته بندی ۰-R ،۱-R، درخت تصمیم ­گیری C4.5 ،Naïve Bayes و رگرسیون لجستیک، در داده ­های گرفته­ شده از Bugzilla انجام داده­است]۵[. این کار با محاسبه درصد خطا­هایی که دسته­بندی شده ­اند و ضریب Kappa برای هر کدام با بهره گرفتن از نرم­افزار Weka انجام داده ­است. داده ­ها بر اساس طول عمروتوضیحات متنی دسته­بندی شده ­اند. این تحقیق تنها مقایسه­ ای بین الگوریتم­های مختلف در یک دسته­بندی ساده برای داده ­های موجود در یک مخزن است، که کمتر به شباهت بین یک خطا جدید و خطا­های دیگر پرداخته شده­ است.