Y@SiN
11-19-2009, 07:10 PM
پیشتر در مورد تولد، حیات و مرگ نرم افزار نوشته بودم، با طرح ایده بیمارستان نرم افزار، بحث های متفاوتی داشتم با دوستان و همکاران، از جمله مهیار نظری داشت در مورد، زایشگاه و قبرستان نرم افزار که پسندیدم، در همین راستا می خواهم خلاصه یکی از بحث هایی که کردیم را نگارش کنم، آنهم در مورد مرگ نرم افزار.
اگر نرم افزار را موجود زنده بدانیم و سازنده آن را خالق آن، باید به تولد و رشد نرم افزار اعتقاد داشته باشیم و لاجرم به مرگ نرم افزار (مطلب مرتبط).
مرگ نرم افزار چیست؟ زمانی که دیگر از آن استفاده نکنیم و به هردلیلی تصمیم به جایگزینی آن با یک محصول دیگر و یا عدم استفاده از آن بگیریم.
دلایل مرگ نرم افزار را می توان در موارد زیر برشمرد:
- تغییر نیازهای سازمان استفاده کننده
- عدم پشتیبانی سازنده
- ارتقاء تکنولوژی و فنآوری ساخت و یا محیط استفاده (نرم افزاری و یا سخت افزاری)
- نقص نرم افزار (علی الخصوص نقص های غیر قابل برطرف شدن)
- به بازار آمدن نرم افزار با قیمت مناسبتر و یا کیفیت برتر
- مشکلات قراردادی بین خریدار و فروشنده که گاهی به لغو پروژه ساخت و کنارگذاشتن محصول آماده شده می گردد.
-...
دقت شود در برخی موارد فوق نرم افزار به صورت کامل از بین نمی رود، بلکه زمان استفاده از آن برای یک مشتری خاص به پایان می رسد که می توان آن را به مرگ آن نسخه خاص از نرم افزار تعبیر کرد. شاید بهتر باشد به جای لغت Software Death از Software Shoutdown برای این پدیده استفاده کرد. به هر حال، باید پذیرفت که نرم افزار هم روزی می میرد. اما نکته مهم آن است که در مورد مرگ نرم افزار چه باید کرد؟
باید پذیرفت، آنقدری که در مورد تولد نرم افزار کار شده است (در قالب فرآیندهای ساخت سیستم و متدولوژی های تحلیل، طراحی و پیاده سازی) و یا در مورد رشد و نگهداری نرم افزار(در قالب فرآیند های پشتیبانی و نگهداشت نرم افزار)، در مورد مرگ نرم افزار کار نشده است و متخصصان نظر نداده اند.
چرا برای مرگ نرم افزار باید فکر کرد؟ پاسخ روشن است، تاثیری که مرگ یک نرم افزار روی تولید کننده و یا مصرف کننده می گذارد. تاثیری که شاید اهمیتش کمتر از مرگ واقعی یک انسان برای آن مجموعه ها نباشد.
همانگونه که یک انسان پیش از مرگ باید وصیت کند و حساب خودش را با سایرین روشن کند (به اصطلاح حلالیت بطلبد) و پس از مرگ هم، نزدیکان باید مراحل کفن و دفن را به طور کامل انجام دهند، در هنگام مرگ یک نرم افزار باید عمل نمود!
به من ایراد نگیرید که اینها چیست می نویسم، صبر کنید، توضیح می دهم!
از پارامتر های که در کیفیت نرم افزار مود توجه قرار می گیرد بحث جامعیت یا Integrity است. این پارامتر به محافظت نرم ا�?زار از اجزاء خود در مقابل دسترسی های مجاز و غیر مجاز بر می گردد. بدین شکل که یک نرم افزار باید مکانیزم های امنیتی (security) و ایمنی (Safety) مختلفی را برای مخفی سازی جزییات و ساختار داده های خود رعایت کنند.
این پارامتر در مدت زمان حیات نرم افزار منطقی است و رعایت آن توسط هر نرم افزار حسن آن محسوب می شود. چون باعث می شود نرم افزار در مقابل دسترسی ها مستحکم باشد و نتوان به سادگی آن به آن نفوذ کرد و ساختارهای اطلاعاتی و عملیاتی آن را کشف کرد.
اما زمانی که یک نرم افزار از چرخه کاری سازمان خارج می شود (به اصطلاح همان مرگ) تکلیف چیست؟ در آن موقع باید در صورت لزوم اطلاعات از نرم افزار خارج شده و در قالب جدید و یا نرم افزار جدید قابل بارگذاری بشود و در مواردی تکلیف الگوریتم های پیجیده روشن شده و روش کار آنها در اختیار کاربر قرار گیرد تا بتواند در سیستم جدید احتمالی آن ها را استفاده کند، از سوی دیگر چنین نرم افزاری باید به صورت کامل از سازمان کاری فعال حذف شود بدون آنکه آسیب جدی به فرآیندهای جاری وارد نماید. به عبارت دیگر همانگونه یک نرم افزار را از روی یک دستگاه Uninstall می کنیم و با اینکار همه اجزاء نرم افزار از روی کامپیوتر برداشته می شود. به همان شکل هم باید بتوان یک نرم افزار را از روی یک سازمان Uninstall نمود.
با این توضیح، بهتر است یک نرم افزار هنگام مرگ خود کارهای زیر را انجام دهد (تسویه حساب و وصیت کردن میت!) :
- افشای ساختارداده خود در حدی که بتوان داده را از سیستم به سیستم دیگر انتقال داد.
- ارسال اطلاعات به یک فرمت استاندارد (برای مثال XML ) برای فراهم سازی امکان Import/Export
-افشای متن برنامه و علی الخصوص الگوریتم های پیچیده در صورت عدم متن باز (Open Source) بودن برنامه در حدی که بتوان روابط علی و معلولی تراکنش ها و ورود اطلاعات تا تهیه گزارشات را شناسایی کرد.
-معرفی همه بخش های خود برای آنکه با Uninstall کردن آنها از روی سیستم های سرور و استفاده کننده
-از کار افتادن بخش ها به صورت تدریجی و نه مقطعی برای عدم اخلال در کارهای جاری سازمان
-...
و یک تیم متخصص تولید کننده بایستی موارد زیر را در قبل و بعد از مرگ یک نرم افزار مد نظر قراردهند:
- فراهم کردن امکانات ساختاری برای زمان مرگ نرم افزار (موارد فوق)
- ارائه خدمات پشتیبانی در زمان آغاز فرآیند از کار انداختن نرم افزار (فرآیند تجاری)
- انتشار کد نرم افزار به صورت عمومی و یا خصوصی در صورت خاتمه همه فعالیت ها روی آن نرم فزار
-فراهم ساختن امکاناتی برای افزایش طول عمر نرم افزار از جمله قابلیت های توسعه، گسترش، انعطاف و سازگاری
- ...
وبرای یک استفاده کننده در زمان حذف یک نرم افزار سازمانی از چرخه کاری توصیه می شود:
- عدم شیفتگی در مقابل فنآوری های نوین، لزومی ندارد با هر ارتقاء نرم فزار و سخت افزار، نرم افزاری سازمانی ارتقآء یابد و یا جایگزین گردد.
- دقت در زمان مرگ نرم افزار: سازمانها پس از مدتی استفاده از یک نرم افزار، به شدت به آن وابسته می شوند و عوض کردن آن هزینه زیادی تحمیل می کند. تشخیص زمان درست کنارگذاشتن یک نرم افزار و جایگزینی آن و محاسبه تاثیرات و هزینه های احتمالی آن بسیار مهم است تا سازمان به صورت آگاهانه اقدام به انجام این کار بنمایند.
- دقت در زمان خرید نرم افزار: چنانچه نرم افزاری حساس خریداری می شود، فقط به موارد زمان راه اندازی توجه نشود، این شرط لازم است ولی کافی نیست. بهتر است در مورد آنکه آن نرم افزار در صورت نیاز به حذف چگونه عمل می کند هم ی تواند به عنوان یک پارامتر تصمیم گیری مطرح شود (هر چند با وزن تصمیم گیری پایین تر از سایر موارد).
- بکارگیری یک متدولوژی و یک روش گام به گام برای حذف یک نرم افزار: با خرید یک سیستم جدید، در بسیاری از موراد نمی توان به صورت انقلابی سیستم جدید را جایگزین قدیمی کرد. بلکه باید در یک دوره زمانی و با اطمینان از صحت عملکرد سیستم جدید و انتقال اطلاعات به آن و تکمیل فرآیند آموزشی کاربران به مرور نرم افزار قدیمی را از کار بیاندازند.
- هر نرم افزاری بالاخره می میرد، منتظر مرگ آن نباشند، آن را نکشند و یا وادار به خودکشی نکنند!: اغلب دیده ام سازمانها نگاهشان به یک نرم افزار شبیه نگاه به یک آدم در بستر مرگ است، هر روز آرزوی مرگش را می کنند و یا با دستکاری آن، زمینه مرگش را ساده تر می کنند، حتی گاهی با ساخت دعواهای الکی یا بهانه گیری، کاری می کنند که یک فروشنده نرم افزار، خود دست به خودکشی نرم افزارش بزند و عطای سازمان را به لقایش ببخشد. همه اینها زمانی فاجعه است که نرم افزار بدون مشکل و یا با ایرادات جزیی کار کند، ایراداتی که بحرانی هم نیست و صرفا استفاده کننده به دلیل شرایط احساسی و یا علاقه به کم کاری و یا ارتباط با یک فروشنده دیگر، مایل به ادامه کار یک نرم افزار نیست. (این مورد را به وضوح در پروژه ای که چند ماه پیش مشاور و ناظرش بودم دیدم که یک مجموعه از طرف کارفرما، چون خودش مجری اصلی نبود، در کار پروژه اخلال ایجاد می کرد تا بتواند نرم افزاری که تازه کمتر از یکسال از بهره برداریش می گذرد را با یک سیستم جدید جایگزین کند)
و یک توصیه همدردانه با تولید کنندگان نرم افزار: هر نرم افزاری روزی می میرد، زیاد غصه اش را نخورید، به فکر تولد سایر نرم افزار ها و خلق نرم افزارهای جدید باشید!
همین!
اگر نرم افزار را موجود زنده بدانیم و سازنده آن را خالق آن، باید به تولد و رشد نرم افزار اعتقاد داشته باشیم و لاجرم به مرگ نرم افزار (مطلب مرتبط).
مرگ نرم افزار چیست؟ زمانی که دیگر از آن استفاده نکنیم و به هردلیلی تصمیم به جایگزینی آن با یک محصول دیگر و یا عدم استفاده از آن بگیریم.
دلایل مرگ نرم افزار را می توان در موارد زیر برشمرد:
- تغییر نیازهای سازمان استفاده کننده
- عدم پشتیبانی سازنده
- ارتقاء تکنولوژی و فنآوری ساخت و یا محیط استفاده (نرم افزاری و یا سخت افزاری)
- نقص نرم افزار (علی الخصوص نقص های غیر قابل برطرف شدن)
- به بازار آمدن نرم افزار با قیمت مناسبتر و یا کیفیت برتر
- مشکلات قراردادی بین خریدار و فروشنده که گاهی به لغو پروژه ساخت و کنارگذاشتن محصول آماده شده می گردد.
-...
دقت شود در برخی موارد فوق نرم افزار به صورت کامل از بین نمی رود، بلکه زمان استفاده از آن برای یک مشتری خاص به پایان می رسد که می توان آن را به مرگ آن نسخه خاص از نرم افزار تعبیر کرد. شاید بهتر باشد به جای لغت Software Death از Software Shoutdown برای این پدیده استفاده کرد. به هر حال، باید پذیرفت که نرم افزار هم روزی می میرد. اما نکته مهم آن است که در مورد مرگ نرم افزار چه باید کرد؟
باید پذیرفت، آنقدری که در مورد تولد نرم افزار کار شده است (در قالب فرآیندهای ساخت سیستم و متدولوژی های تحلیل، طراحی و پیاده سازی) و یا در مورد رشد و نگهداری نرم افزار(در قالب فرآیند های پشتیبانی و نگهداشت نرم افزار)، در مورد مرگ نرم افزار کار نشده است و متخصصان نظر نداده اند.
چرا برای مرگ نرم افزار باید فکر کرد؟ پاسخ روشن است، تاثیری که مرگ یک نرم افزار روی تولید کننده و یا مصرف کننده می گذارد. تاثیری که شاید اهمیتش کمتر از مرگ واقعی یک انسان برای آن مجموعه ها نباشد.
همانگونه که یک انسان پیش از مرگ باید وصیت کند و حساب خودش را با سایرین روشن کند (به اصطلاح حلالیت بطلبد) و پس از مرگ هم، نزدیکان باید مراحل کفن و دفن را به طور کامل انجام دهند، در هنگام مرگ یک نرم افزار باید عمل نمود!
به من ایراد نگیرید که اینها چیست می نویسم، صبر کنید، توضیح می دهم!
از پارامتر های که در کیفیت نرم افزار مود توجه قرار می گیرد بحث جامعیت یا Integrity است. این پارامتر به محافظت نرم ا�?زار از اجزاء خود در مقابل دسترسی های مجاز و غیر مجاز بر می گردد. بدین شکل که یک نرم افزار باید مکانیزم های امنیتی (security) و ایمنی (Safety) مختلفی را برای مخفی سازی جزییات و ساختار داده های خود رعایت کنند.
این پارامتر در مدت زمان حیات نرم افزار منطقی است و رعایت آن توسط هر نرم افزار حسن آن محسوب می شود. چون باعث می شود نرم افزار در مقابل دسترسی ها مستحکم باشد و نتوان به سادگی آن به آن نفوذ کرد و ساختارهای اطلاعاتی و عملیاتی آن را کشف کرد.
اما زمانی که یک نرم افزار از چرخه کاری سازمان خارج می شود (به اصطلاح همان مرگ) تکلیف چیست؟ در آن موقع باید در صورت لزوم اطلاعات از نرم افزار خارج شده و در قالب جدید و یا نرم افزار جدید قابل بارگذاری بشود و در مواردی تکلیف الگوریتم های پیجیده روشن شده و روش کار آنها در اختیار کاربر قرار گیرد تا بتواند در سیستم جدید احتمالی آن ها را استفاده کند، از سوی دیگر چنین نرم افزاری باید به صورت کامل از سازمان کاری فعال حذف شود بدون آنکه آسیب جدی به فرآیندهای جاری وارد نماید. به عبارت دیگر همانگونه یک نرم افزار را از روی یک دستگاه Uninstall می کنیم و با اینکار همه اجزاء نرم افزار از روی کامپیوتر برداشته می شود. به همان شکل هم باید بتوان یک نرم افزار را از روی یک سازمان Uninstall نمود.
با این توضیح، بهتر است یک نرم افزار هنگام مرگ خود کارهای زیر را انجام دهد (تسویه حساب و وصیت کردن میت!) :
- افشای ساختارداده خود در حدی که بتوان داده را از سیستم به سیستم دیگر انتقال داد.
- ارسال اطلاعات به یک فرمت استاندارد (برای مثال XML ) برای فراهم سازی امکان Import/Export
-افشای متن برنامه و علی الخصوص الگوریتم های پیچیده در صورت عدم متن باز (Open Source) بودن برنامه در حدی که بتوان روابط علی و معلولی تراکنش ها و ورود اطلاعات تا تهیه گزارشات را شناسایی کرد.
-معرفی همه بخش های خود برای آنکه با Uninstall کردن آنها از روی سیستم های سرور و استفاده کننده
-از کار افتادن بخش ها به صورت تدریجی و نه مقطعی برای عدم اخلال در کارهای جاری سازمان
-...
و یک تیم متخصص تولید کننده بایستی موارد زیر را در قبل و بعد از مرگ یک نرم افزار مد نظر قراردهند:
- فراهم کردن امکانات ساختاری برای زمان مرگ نرم افزار (موارد فوق)
- ارائه خدمات پشتیبانی در زمان آغاز فرآیند از کار انداختن نرم افزار (فرآیند تجاری)
- انتشار کد نرم افزار به صورت عمومی و یا خصوصی در صورت خاتمه همه فعالیت ها روی آن نرم فزار
-فراهم ساختن امکاناتی برای افزایش طول عمر نرم افزار از جمله قابلیت های توسعه، گسترش، انعطاف و سازگاری
- ...
وبرای یک استفاده کننده در زمان حذف یک نرم افزار سازمانی از چرخه کاری توصیه می شود:
- عدم شیفتگی در مقابل فنآوری های نوین، لزومی ندارد با هر ارتقاء نرم فزار و سخت افزار، نرم افزاری سازمانی ارتقآء یابد و یا جایگزین گردد.
- دقت در زمان مرگ نرم افزار: سازمانها پس از مدتی استفاده از یک نرم افزار، به شدت به آن وابسته می شوند و عوض کردن آن هزینه زیادی تحمیل می کند. تشخیص زمان درست کنارگذاشتن یک نرم افزار و جایگزینی آن و محاسبه تاثیرات و هزینه های احتمالی آن بسیار مهم است تا سازمان به صورت آگاهانه اقدام به انجام این کار بنمایند.
- دقت در زمان خرید نرم افزار: چنانچه نرم افزاری حساس خریداری می شود، فقط به موارد زمان راه اندازی توجه نشود، این شرط لازم است ولی کافی نیست. بهتر است در مورد آنکه آن نرم افزار در صورت نیاز به حذف چگونه عمل می کند هم ی تواند به عنوان یک پارامتر تصمیم گیری مطرح شود (هر چند با وزن تصمیم گیری پایین تر از سایر موارد).
- بکارگیری یک متدولوژی و یک روش گام به گام برای حذف یک نرم افزار: با خرید یک سیستم جدید، در بسیاری از موراد نمی توان به صورت انقلابی سیستم جدید را جایگزین قدیمی کرد. بلکه باید در یک دوره زمانی و با اطمینان از صحت عملکرد سیستم جدید و انتقال اطلاعات به آن و تکمیل فرآیند آموزشی کاربران به مرور نرم افزار قدیمی را از کار بیاندازند.
- هر نرم افزاری بالاخره می میرد، منتظر مرگ آن نباشند، آن را نکشند و یا وادار به خودکشی نکنند!: اغلب دیده ام سازمانها نگاهشان به یک نرم افزار شبیه نگاه به یک آدم در بستر مرگ است، هر روز آرزوی مرگش را می کنند و یا با دستکاری آن، زمینه مرگش را ساده تر می کنند، حتی گاهی با ساخت دعواهای الکی یا بهانه گیری، کاری می کنند که یک فروشنده نرم افزار، خود دست به خودکشی نرم افزارش بزند و عطای سازمان را به لقایش ببخشد. همه اینها زمانی فاجعه است که نرم افزار بدون مشکل و یا با ایرادات جزیی کار کند، ایراداتی که بحرانی هم نیست و صرفا استفاده کننده به دلیل شرایط احساسی و یا علاقه به کم کاری و یا ارتباط با یک فروشنده دیگر، مایل به ادامه کار یک نرم افزار نیست. (این مورد را به وضوح در پروژه ای که چند ماه پیش مشاور و ناظرش بودم دیدم که یک مجموعه از طرف کارفرما، چون خودش مجری اصلی نبود، در کار پروژه اخلال ایجاد می کرد تا بتواند نرم افزاری که تازه کمتر از یکسال از بهره برداریش می گذرد را با یک سیستم جدید جایگزین کند)
و یک توصیه همدردانه با تولید کنندگان نرم افزار: هر نرم افزاری روزی می میرد، زیاد غصه اش را نخورید، به فکر تولد سایر نرم افزار ها و خلق نرم افزارهای جدید باشید!
همین!