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

فهرست مطالب

۱٫۲٫ فرآیند مهندسی نرم افزار    ۴
۱٫۱٫۲٫پیاده سازی ،آزمایش ،تست و مستند سازی    ۴
۲٫۲٫ انواع مخازن داده    ۵
۱٫۲٫۲٫کد اصلی:    ۵
۲٫۲٫۲٫ مخازن خطا(سیستم ردیابی خطا BTS)    ۵
۳٫۲٫۲٫ لیست نامه ها و گفتگوهای ثبت شده    ۶
۴٫۲٫۲ .پایگاه داده کنترل منبع (پایگاه داده کنترل ویرایش ها)    ۶
۵٫۲٫۲٫ اطلاعات طراحی و نیازمندیهای سیستم    ۷
۶٫۲٫۲٫ مخازن شرح اجرا    ۷
۷٫۲٫۲٫ مخازن سیستم نرم افزار    ۷
۳٫۲٫ خطای نرم افزاری    ۸
۱٫۳٫۲٫سیستم ردیابی خطا    ۸
۴٫۲٫تحقیقات پیشین در حوزه دادهکاوی در مخازن خطا    ۱۶
۵٫۲٫ اندازه گیری شباهت بین متون    ۱۹
۱٫۵٫۲٫شباهت خطی    ۱۹
۱٫۱٫۵٫۲٫اندازه گیری شباهت بر پایه کاراکتر    ۲۰
۲٫۱٫۵٫۲٫ شباهت بر پایه توالی    ۲۱
۲٫۵٫۲٫ تشابه بر پایه مجموعه    ۲۳
۳٫۵٫۲٫تشابه بر پایه دانش    ۲۶
۴٫۵٫۲٫ اندازه گیری شباهت ترکیبی    ۲۸
منابع و ماخذ    ۳۰

منابع

 ۱٫ Naresh Kumar Nagwani, Pradeep Singh/”Bug Mining Model Based on Event-ComponentSimilarity to Discover Similar and Duplicate GUIBugs”/ ۲۰۰۹ IEEE International Advance Computing Conference (IACC 2009)/Patiala, India/6-7 March 2009.

۴٫ Naresh Kumar Nagwani, ShrishVerma/ “Predicting Expert Developers for Newly Reported Bugs Using Frequent Terms Similarities of Bug Attributes”/ ۲۰۱۱ Ninth International Conference on ICT and Knowledge Engineering / 2011 IEEE.

۵٫ Hui Zeng, David Rine/ ” Estimation of Software Defects Fix Effort Using Neural Networks”/ Proceedings of the 28th Annual International Computer Software and Applications Conference (COMPSAC’۰۴)/ ۲۰۰۴ IEEE.

۶٫ JunzoWatada/ “Analysis of Software Reliability by Fuzzy Regression Model”/ TENCON 2000

۷٫ Lucas D. Panjer/ ” Predicting Eclipse Bug Lifetimes”/ Fourth International Workshop on Mining Software Repositories (MSR’07)/ 2007 IEEE.

۸٫ Suma.V, Pushpavathi T.P, and Ramaswamy.V/”An Approach to Predict Software Project Success by Data Mining Clustering”/ International Conference on Data Mining and Computer Engineering (ICDMCE’2012)/ Bangkok,(Thailand)/ December 21-22, 2012.

۹٫ CathrinWeiß ,Thomas Zimmermann, Rahul Premraj , Andreas Zeller ,Saarland University/ ” How Long will it Take to Fix This Bug?”/ Fourth International Workshop on Mining Software Repositories (MSR’07)/ 0-7695-2950-X/07 $20.00 © /۲۰۰۷ IEEE

۱۰٫ Naresh Kumar Nagwani, ShrishVerma/” Predictive Data Mining Model for Software Bug Estimation Using Average Weighted Similarity”/ Advance Computing Conference (IACC)/ 2010 IEEE 2^nd International.

۱۱٫ Naresh Kumar Nagwani, Ashok Bhansali/”A Data Mining Model to Predict Software Bug Complexity Using Bug Estimation and Clustering”/ ۲۰۱۰ International Conference on Recent Trends in Information/ Telecommunication and Computing/ 2010 IEEE.

۱۲٫ Naresh Kumar Nagwani, ShrishVerma/ “Predicting Expert Developers for Newly Reported Bugs Using Frequent Terms Similarities of Bug Attributes”/ ۲۰۱۱ Ninth International Conference on ICT and Knowledge Engineering / 2011 IEEE.

۱۳٫ Berliner/ “Parallelizing software development In Proceedings of the USENIX”/ Winter 1990Technical Conference/ volume 341, page 352, 1990

۱۴٫ M. Pilato, B. Collins-Sussman, and B. W. Fitzpatrick/ “Version Control with Subversion”/ O’ReillyMedia/ 2008

۱۵٫ sourceforge.net

۱۶٫ code.google.com

۱۷٫ Stephen W. Thomas/” Mining Software Repositories with Topic Models”/ School of Computing Queen’s University Kingston, Ontario, Canada. Technical Report 2012-586. IEEE.

۱۸٫ Golnoosh Abaee, Department of Studies in Computer Science,Islamic Azad University, Roodehen Branch, Iran. D.S.Guru, Department of Studies in Computer Science, University of Mysore, Manasagangothri, ,Mysore,570006, India/ ”Enhancement of Bug Tracking Tools; the Debugger”/ ۲nd International Conference on Software Technology and Engineering(ICSTE)/ 2010.

۱۹٫ Bug life cycle / softwaretestinghelp.com/bug-life-cycle/

۲۰٫ Naresh Kumar Nagwani, Dr. Shrish Verma1Assistant Professor, Computer Science & Engineering; 2Associate Professor & Head, Electronics & Tel. Communication Engg. Mm National Institute of Technology Raipur,1nknagwani.cs@nitrr.ac.in, 2shrishverma@nitrr.ac.in/ On Studying the Effect of Sample Size in Evaluation of Bug Classifiers/ ISSN: 0974-6846, Vol: 6 Issue: 1/ January 2013

۲۱٫ Wael H. Gomaa,Computer Science Department Modern Academy for Computer ,Science & Management Technology Cairo, Egypt.Aly A. Fahmy,Computer Science Department Faculty of Computers and Information, Cairo University Cairo, Egypt/ ”A Survey of Text Similarity Approaches”/ International Journal of Computer Applications/ (0975 – ۸۸۸۷) Volume 68– No.13/ April 2013.

 ۱٫۲٫ فرآیند مهندسی نرم­افزار

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

۱٫۱٫۲٫پیاده سازی ،آزمایش ،تست و مستند ­سازی

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

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

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

افزایش کیفیت، قابلیت اطمینان، قابلیت نگهداری

رضایت کاربران و سهامداران

کاهش هزینه­های جانبی و پشتیبانی

تحویل به موقع

استفاده از مولفه­های استاندارد

استفاده مجدد

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

۲٫۲٫ انواع مخازن داده

۱٫۲٫۲٫کد اصلی:

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

۲٫۲٫۲٫ مخازن خطا(سیستم ردیابی خطا BTS[2])

این مخازن برای ذخیره اطلاعات مربوط به ایجاد و حل خطا، مشخصات ارتقاء سیستم و کلیه اقدامات دیگر در مرحله تعمیر و نگهداری استفاده می­شوند. معمولا هنگامی­که توسعه­دهندگان و کاربران به مشکل یا خطایی در یک سیستم نرم­افزاری مواجه می­شوند، یادداشتی درباره این خطا در پایگاه ­داده خطا در موضوع مربوطه ذخیره­ می­شود. این اطلاعات شامل: علت و مکان وقوع خطا در برنامه و اینکه چگونه خطا باعث ایجاد اشکال و خلل در روند برنامه شده­ است. پس از آن یک یا چند متخصص، موضوع ایجاد ­شده را برای رفع مشکل بررسی می­کنند. چنانچه خطا برطرف شود موضوع در فرم مربوطه بسته­ می­شود. تمام این اطلاعات در مخازن و پایگاه­های خطا ذخیره می­شوند. عمومی­ترین سیستم­های مخازن خطا Bugzilla ، Trac هستند.

اگرچه تا به امروز سیستم­های متعددی ساخته شده­اند. در حالت ­عادی بین خطا[۳]، نقص[۴]، عیب[۵] تفاوت قائل می­شویم، اما در این تحقیق همه را با لفظ خطا و هم معنی در نظر می­گیریم.

۳٫۲٫۲٫ لیست نامه­ها و گفتگو­های ثبت شده

لیست ایمیل­ها (یا آرشیو بحث­ها) همراه با گفتگوهای ثبت شده بین افراد دخیل در یک پروژه آرشیوی از ارتباطات متنی توسعه ­دهندگان ، مدیران و ذینفعان آن پروژه هستند. لیست متنی متشکل از بسته­ های الکترونیکی که شامل سه قسمت:

سرآیند (فرستنده ،گیرنده و زمان ارسال)

بدنه پیغام­(متن داخل ایمیل)

مجموعه­ای­از فایل­های پیوست­ شده(مستندات اضافی که همراه ایمیل فرستاده ­می­شود) می­باشد.

شرح گفتگو­ها شامل ثبت مکالمات فوری بین ذینفعان پروژه، که بر حسب زمان یا نویسنده دسته­ بندی شده ­اند، می­باشد.

۴٫۲٫۲ .پایگاه داده کنترل منبع (پایگاه داده کنترل ویرایش ها)

سیستمی برای ثبت تاریخ تغییرات (ویرایش­ها) به ­همراه خود ویرایش و اطلاعات دیگر به ­صورت اسناد و اطلاعات متنی است. توسعه­دهندگان معمولا تاریخ و زمان ویرایش یک کد اصلی را در پایگاه داده­ هایی ذخیره می­کنند. پایگاه داده­ های کنترل کد رایج مانند] cvs 13[ و] svn 14[ ، به توسعه ­دهندگان اجازه می­دهند به یک کپی از مخزن سراسری و جهانی، در سیستم فایل­های محلی خود، دسترسی داشته باشند. اسناد موجود را ویرایش کند، یا اطلاعاتی اضافه یا کم کند و یا ساختار دایرکتوری این مخازن را تغییر دهند. همچنین می­تواند در مخزن اصلی سند یا اطلاعات جدید محلی ایجاد کند.

بنابراین کنترل بازبینی­ها دو نتیجه مهم در بر خواهد داشت:

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

دوم اینکه زمان و تاریخ همه اطلاعات و مستندات به صورت خودکار ثبت و نگهداری می­شود. اگر نسخه­ های قبل نرم ­افزار نیاز بود­، توسعه­دهندگان به­راحتی می­توانند به نسخه­های قبل سیستم دسترسی داشته باشند و سیستم را به نسخه قبلی برگردانند.

۵٫۲٫۲٫ اطلاعات طراحی و نیازمندی­های سیستم

مستندات نیازمندی­ها، معمولا در ارتباط با مشتری و یا با تایید­های او تنظیم می­شود. این اسناد لیستی از نیازهای مشتری است که خواهان انجام آن توسط سیستم است. این نیازها به دو صورت دسته­بندی می­شوند. اینکه چه نیازهایی را سیستم باید برطرف کند و چگونه و با چه کیفیتی مورد­­انتظار مشتری است. اطلاعات طراحی نیز شامل تمام اطلاعات مربوط به طراحی­معماری و الگوریتم­های مهم و مورد استفاده[۶] سیستم است. طراحی سیستم می­تواند به شکل نمودار(مانند UML) و یا به­صورت متون جریان کار نمایش داده شوند.

[۱]-Module

[۲]– bug-tracking system

[۳]– bug

[۴]– defect

[۵]– fault

[۶]– Use Case

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