نگهداری و تعمیر نرم افزار در مهندسی نرم افزار

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

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

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

ما در این مقاله به عناوین زیر خواهیم پرداخت:

مبانی نگهداری نرم افزار

تغییر سیستم نرم افزاری

سیستم قدیمی(قبلی)

مبانی نگهداری نرم افزار

نرم افزار فرسوده و خسته نمی شود. با این حال ، برای پاسخگویی به نیازهای کاربر جدید ، باید به روز رسانی شود و بهبود یابد. برای چنین تغییراتی در سیستم نرم افزار ، نگهداری نرم افزار انجام می شود. IEEE (مؤسسه مهندسان برق و الکترونیک) تعمیر و نگهداری را به عنوان "فرآیند اصلاح سیستم نرم افزاری یا اجزای سازنده ی آن پس از تحویل برای اصلاح نقص ، بهبود عملکرد یا سایر ویژگی ها یا انطباق محصول با یک محیط تغییر یافته" تعریف می کند. هدف این است که اطمینان حاصل کنیم که نرم افزار پس از تحویل و استقرار سیستم قادر به ایجاد تغییرات است.

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

1. ارائه تداوم خدمات: روند تعمیر و نگهداری نرم افزار بر رفع خطاها ، بازیابی از خرابی هایی مانند خرابی سخت افزار یا ناسازگاری سخت افزار با نرم افزار و ایجاد تغییرات در سیستم عامل و سخت افزار متمرکز است.

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

4- تسهیل کار تعمیر و نگهداری در آینده: تعمیر و نگهداری نرم افزار کار تعمیر و نگهداری در آینده را تسهیل می کند ، که ممکن است شامل بازسازی کد نرم افزار و پایگاه داده مورد استفاده در نرم افزار باشد.

تغییر سیستم نرم افزاری

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

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

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

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

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

4- حفظ آشنایی: این قانون بیان می کند که محدودیتی در سرعت ارائه عملکردهای جدید وجود دارد. این بدان معناست که اضافه کردن قابلیتهای زیاد به سیستم در یک نسخه ، قطعاً ممکن است خطاهای جدیدی در سیستم ایجاد کند. اگر یک افزایش بزرگ ارائه شود ، برای اصلاح خطاهای سیستم جدید "نسبتاً سریع" نسخه جدیدی لازم است. بنابراین ، سازمانها نباید برای توسعه عملکردهای بزرگ در هر نسخه ، بدون در نظر گرفتن نیاز به تعمیر خطا ، بودجه در نظر بگیرند.

جدول قوانین لمن

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

سیستم قدیمی

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

جدول مشخصات سیستم قدیمی

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

سیستم های قدیمی به دلایل زیر برای ایجاد تغییرات طراحی نشده اند:

1. امید به زندگی کوتاه: در زمان سفارش آنها ، پیش بینی نشده بود که از سیستم های قدیمی برای چندین دهه استفاده میشود.
2. عدم موفقیت مدل های فرایندی در تلقی کردن تکامل به عنوان یک فعالیت مهم: به عنوان مثال ، الزامات تکامل را می توان از اهداف کسب و کار استخراج کرد ، اما طبق روش سنتی ، در مرحله مشخصات توسعه ، نیازهای آینده تا حد زیادی نادیده گرفته می شوند.
3. محدودیت های موجود در زمان توسعه: هنگامی که سیستم های قدیمی تولید می شوند ، حافظه و قدرت پردازش محدود می شود که تصمیمات طراحی نرم افزار را محدود می کند. از تکنیک ها برای استفاده بهینه از این منابع استفاده شده است ، اما به قیمت از دست دادن قابلیت نگهداری و تعمیرات مشاهده شده است که برای توسعه سیستم های نرم افزاری "طولانی مدت" ، سهولت قابلیت نگهداری یک پیش شرط است.

غالباً سازمانها با معضلی معروف به معضل میراث روبرو می شوند ، كه می گوید: ‘یك سیستم قدیمی كه حیاتی است ، باید به نوعی در سازمان خود موثر باشد. با این حال ، نگهداری مداوم از سیستم گران است و وسعت اجرای موثر تغییرات زیاد به شدت محدود است. علاوه بر این ، هزینه های جایگزینی سیستم از ابتدا بسیار زیاد است. "

اجزای یک سیستم قدیمی

"تکامل" یک سیستم قدیمی توسط قطعاتی که سیستم قدیمی را تشکیل میدهد تعیین می شود

این قسمتها را می توان طبق نمودار بالا طبقه بندی کرد.

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

توجه: تجزیه و تحلیل دقیق قسمتهای فنی ، تجاری و سازمانی سیستم ، آینده یک سیستم قدیمی را تعیین می کند.