نگهداری نرم‌افزار
نگهداری نرم‌افزار (به انگلیسی: software maintenance) در مهندسی نرم‌افزار به معنی اصلاح یک محصول نرم‌افزاری «پس از تحویل» آن است، و هدف این فعالیت آن است که برای بهبود کارایی، و دیگر ویژگی‌های نرم‌افزار، خطاهای موجود در آن را تصحیح کند.
گرایشی از مهندسی نرم‌افزار است که شامل نگهداری و اصلاح یک محصول نرم‌افزاری پس از تحویل است به منظور تصحیح اشکالات پیش‌آمده و بهبود عملکرد یا ویژگی‌های دیگر آن نرم‌افزار.
یک دید متعارف نسبت به تعمیر و نگهداری نرم‌افزار این است که آن را صرفاًشامل رفع نقصهای نرم‌افزاری بدانیم، اما یک مطالعه نشان داده‌است که بیش از ۸۰٪ از فعالیت‌های مربوط به تعمیر و نگهداری نرم‌افزار مرتبط با اقدامات اصلاحی نیست. این دید متعارف توسط کاربرانی که مشکلی در نرم‌افزار گزارش می‌دهند که در واقعیت بهبودهایی بر کارایی نرم‌افزار هستند تقویت می‌شود. مطالعات جدیدتر درصد فعالیت‌های مربوط به تعمیر و نگهداری نرم‌افزار که مرتبط با رفع اشکال هستند را نزدیک به ۲۱٪ گزارش کرده‌اند.
تاریخچه
نگهداری نرم‌افزار و تکامل سیستم‌ها برای اولین بار توسط Meir M. Lehman در سال ۱۹۶۹ میلادی مورد بررسی قرار گرفت. طی یک دوره بیش از بیست ساله، تحقیقات او منجر به تدوین قوانین لیمن (لیمن ۱۹۹۷) شد. یافته‌های کلیدی تحقیقات وی شامل این است که تعمیر و نگهداری نرم‌افزار در واقع توسعه تکاملی آن است و نگهداری نرم‌افزار در واقع از درک آنچه برای سیستم (نرم‌افزار) در طول زمان اتفاق می‌افتد در تصمیم‌گیری کمک می‌گیرد. لیمن نشان داد که سیستم در طول زمان همچنان در حال تکامل است. آن‌ها در تکامل و رشد خود در طی زمان پیچیده‌تر می‌شوند مگر اینکه برخی از اقدامات مانند کد refactoring به منظور کاهش پیچیدگی صورت پذیرد.
در اواخر دهه ۱۹۷۰ یک بررسی گسترده و معروف طی یک مطالعه توسط Lientz و Swanson انجام شد که در آن از سهم زیاد هزینه‌های تعمیر و نگهداری در هزینه‌های چرخه حیات یک نرم‌افزار پرده برداشته شد. آن‌ها فعالیت‌های تعمیر و نگهداری را به چهار کلاس طبقه‌بندی کردند:
- تطبیقی – اصلاح سیستم برای مقابله با تغییرات در محیط نرم‌افزار (همانند DBMSها و سیستم عامل ها)
- بهبودی (Perfective) – اجرای کاربری‌های جدید یا تغییر کاربری‌های موجود مورد نیاز است که دغدغه وضعیت کاربری نرم‌افزار را دارد
- اصلاحی – تشخیص و تعمیر خطاهایی که احتمالاً توسط کاربران گزارش شده‌اند
- پیشگیری – بهبود راحتی نگهداشت نرم‌افزار یا قابلیت اطمینان به کارایی آن جهت جلوگیری از مشکلات آتی
این بررسی نشان داد که حدود ۷۵٪ از فعالیت‌های تعمیر و نگهداری صرف دو نوع اول شد و اصلاح خطاها حدود ۲۱٪ از فعالیت‌های مربوط به تعمیر و نگهداری را به خود اختصاص داد. بسیاری از مطالعات بعدی نتایج مشابهی را نشان می‌دهند. مطالعات نشان می‌دهد که مشارکت کاربر نهایی بسیار مهم است و در جمع‌آوری داده‌ها و نیازمندی‌های جدید و تجزیه و تحلیل آن‌ها نقش مهمی ایفا می‌کند، و این علت اصلی هر گونه مشکل در تکامل و تعمیر و نگهداری نرم‌افزار است؛ بنابراین تعمیر و نگهداری نرم‌افزار مهم است چرا که بخش بزرگی از کل هزینه‌های چرخه حیات نرم‌افزار را به خود اختصاص می‌دهد و همچنین عدم توانایی در ایجاد تغییر در نرم‌افزار با سرعت و قابلیت اعتماد مناسب به این معنی است که فرصت‌های کسب و کار از دست می‌روند.
اهمیت تعمیر و نگهداری نرم‌افزار
کلید نگهداری نرم‌افزار توجه به مسائل مربوط به هر دو زمینه مدیریتی و فنی است. کلید مدیریت مسائل عبارتند از: هم‌ترازی و همراهی با مشتری، ایجاد اولویت‌هایی برای نیروی انسانی، برآورد صحیح هزینه‌ها. کلید حل مسائل فنی عبارتند از: برطرف کردن محدود درک، تأثیر، تحلیل، تست، نگهداری و اندازه‌گیری.
تعمیر و نگهداری نرم‌افزار فعالیت بسیار گسترده‌ای است که شامل تصحیح خطا و پیشرفت قابلیت‌های نرم‌افزار و بهینه‌سازی آن است. از آنجایی که تغییر اجتناب ناپذیر است، مکانیسم‌های مورد استفاده باید امکان ارزیابی و کنترل و ایجاد تغییرات را داشته باشند.
بنابراین هر کاری که به منظور تغییر نرم‌افزار انجام می‌شود بخشی از عملیات تعمیر و نگهداری نرم‌افزار در نظر گرفته می‌شود و هدف آن حفظ ارزش نرم‌افزار در طول زمان می‌باشد. ارزش نرم‌افزار را می‌توان با گسترش پایه مشتری (Customer Base) آن افزایش داد و این امر نیازمند تبدیل شدن نرم‌افزار به حالتی است که برای استفاده کارآمدتر باشد و فناوری‌های جدید در آن به کار گرفته شوند. تعمیر و نگهداری ممکن است در طول ۲۰ سال رخ دهد در حالی که توسعه ممکن است مجموعاً ۱–۲ سال طول بکشد.
برنامه‌ریزی تعمیر و نگهداری نرم‌افزار
بخشی جدایی ناپذیر از نرم‌افزارها تعمیر و نگهداری آنهاست که نیازمند تهیه برنامه‌ای دقیق برای تعمیر و نگهداری آن در طول فرایند توسعه نرم‌افزار است. باید مشخص کنید که چگونه به درخواست‌های تغییر یا گزارش مشکلات کاربران پاسخ خواهید داد. بودجه فعالیت‌ها باید شامل تخمینی از منابع مورد نیاز و هزینه‌های آتی باشد تا دچار مشکل نشویم. تعمیر و نگهداری نرم‌افزار که می‌تواند برای ۵–۶ سال (یا حتی دهه‌ها پس از فرایند توسعه نرم‌افزار) ادامه داشته باشد نیازمند یک طرح مؤثر است که بتواند دامنه کاری نرم‌افزار را تعیین کند و زمینه را برای ارائه برآوردی از هزینه‌های چرخه زندگی نرم‌افزار فراهم کند. انتخاب استانداردهای مناسب جهت به چالش کشیدن اقدامات بعدی روی نرم‌افزار از مرحله اولیه مهندسی نرم‌افزار است که از دید سهامداران نگران دارای اهمیت بسزایی است.
فرایندهای تعمیر و نگهداری نرم‌افزار
این بخش توصیف شش گام فرایند تعمیر و نگهداری نرم‌افزار را عنوان می‌کند:
- فرایند پیاده‌سازی شامل آماده‌سازی نرم‌افزارها و فعالیت‌های انتقال مفاهیم و ایجاد برنامه تعمیر و نگهداری است که خود شامل آماده‌سازی برای دست یاختن به مشکلات شناسایی شده در طول توسعه و پیگیری محصول در قالب پیکربندی مدیریتی است.
- تجزیه و تحلیل مشکل و اصلاح فرایندی که اجرا شده‌است باید توسط تیمی که مسئولیت تعمیر و نگهداری برنامه را بر عهده دارند انجام شود.
- این روند با توجه به اجرای اصلاح خود تکرارپذیر است.
- در روند پذیرش تغییر به واسطه تأیید اصلاح کار توسط فردی که ارائه درخواست اصلاح کرده بود مطمئن شوید که اصلاح ارائه شده یک راه حل مناسب است.
- روند مهاجرت یک روند استثنایی است و نه بخشی از تعمیر و نگهداری روزانه. اگر این نرم‌افزار باید به پلت فرم دیگری منتقل شود باید بدون هرگونه تغییر در عملکرد آن این فرایند انجام شود و یک تیم تعمیر و نگهداری پروژه به این کار اختصاص داده شود.
- آخرین فرایند تعمیر و نگهداری نیز یک رویداد است که به صورت روزانه رخ نمی‌دهد و آن بازنشستگی یک قطعه از نرم‌افزار است.
عوامل تعمیر و نگهداری
تأثیر عوامل مؤثر کلیدی بر نگهداری (طبقه‌بندی شده به ترتیب حداکثر تأثیر مثبت به پایین)
| عوامل تعمیر و نگهداری | محدوده مثبت |
|---|---|
| متخصصان تعمیر و نگهداری | ۳۵٪ |
| کارکنان با تجربه بالا | ۳۴٪ |
| متغیرها و داده‌های بر پایه جدول | ۳۳٪ |
| پیچیدگی کم پایه کد | ۳۲٪ |
| Y2K و موتورهای جستجو ویژه | ۳۰٪ |
| ابزار تغییر ساختار کد | ۲۹٪ |
| Re-engineering tools | ۲۷٪ |
| زبان‌های برنامه‌نویسی سطح بالا | ۲۵٪ |
| ابزار مهندسی معکوس | ۲۳٪ |
| ابزار تجزیه و تحلیل پیچیدگی | ۲۰٪ |
| ابزار ردیابی نقایص | ۲۰٪ |
| Y2K متخصصان "به روز رسانی دسته جمعی" | ۲۰٪ |
| ابزار تغییر کنترل خودکار | ۱۸٪ |
| عدم پرداخت اضافه کاری | ۱۸٪ |
| کیفیت اندازه‌گیری | ۱۶٪ |
| بازرسی رسمی پایه کد | ۱۵٪ |
| آزمون رگرسیون کتابخانه‌ها | ۱۵٪ |
| زمان پاسخ دهی بسیار عالی | ۱۲٪ |
| آموزش سالانه> ۱۰ روز | ۱۲٪ |
| تجربه بالا مدیریت | ۱۲٪ |
| میز کمک اتوماسیون | ۱۲٪ |
| عدم وجود ماژول مستعد خطا | ۱۰٪ |
| گزارش نقص آنلاین | ۱۰٪ |
| اندازه‌گیری بهره‌وری | ۸٪ |
| سهولت استفاده عالی | ۷٪ |
| اندازه‌گیری رضایت کاربر | ۵٪ |
| روحیه بالای تیم | ۵٪ |
| مجموع | ۵۰۳٪ |
نه تنها ماژول‌های مستعد خطا آزاردهنده و مشکل‌ساز هستند بلکه بسیاری از دیگر عوامل نیز می‌توانند موجب تنزل عملکرد بیش از پیش سیستم نیز بشوند. برای مثال "اسپاگتی کد" یک تکه کد بسیار پیچیده‌است که نگهداری مطمئن و ایمن آن کاملاً دشوار است. یک پیش‌آمد بسیار معمول است که اغلب تنزل‌های عملکردی سیستم ناشی از عدم استفاده از ابزارهای نگهداری مناسب است همانند ابزارهای ردیابی نقص، ردیابی تغییر نرم‌افزار، نرم‌افزار مدیریت و تست نرم‌افزار. باید برای استفاده از این ابزارها اهتمام نمود.
همچنین نگاه کنید به
منابع
- ↑ «نگهداری نرم‌افزار» [رایانه و فنّاوری اطلاعات] هم‌ارزِ «software maintenance»؛ منبع: گروه واژه‌گزینی. جواد میرشکاری، ویراستار. دفتر پنجم. فرهنگ واژه‌های مصوب فرهنگستان. تهران: انتشارات فرهنگستان زبان و ادب فارسی. شابک ۹۷۸-۹۶۴-۷۵۳۱-۷۶-۴ (ذیل سرواژهٔ نگهداری نرم‌افزار)
- ↑ "ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance". Iso.org. 2011-12-17. Retrieved 2013-12-02.
- ↑ "ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance". Iso.org. 2011-12-17. Retrieved 2013-12-02.
- ↑ Pigoski, Thomas M. , 1997: Practical software maintenance: Best practices for managing your software investment.
- ↑ Eick, S. , Graves, T. , Karr, A. , Marron, J. , and Mockus, A. 2001.
- ↑ Software Maintenance and Re-engineering, CSE2305 Object-Oriented Software Engineering
- ↑ Lientz B. , Swanson E. , 1980: Software Maintenance Management.
- ↑ Lehman M. M. , 1980: Program, Life-Cycles and the Laws of Software Evolution.
- ↑ Penny Grubb, Armstrong A. <g class="gr_ gr_35 gr-alert gr_spell gr_inline_cards gr_disable_anim_appear ContextualSpelling ins-del multiReplace" id="35" data-gr-id="35">Takang</g>, 2003: Software Maintenance: Concepts and Practice.