چرا نرم‌افزارها می میرند ؟
معمولاً وقتی سازمان یا شرکتی نرم‌افزاری را سفارش می‌دهد، هیچ‌گاه به این موضوع فکر نمی‌کند که ممکن است قبل از تحویل گرفتن آن، نرم‌افزار او بمیرد و از آن محصول نتواند استفاده کند. یا اگر نرم‌افزار را سالم تحویل بگیرد باز هم به این موضوع فکر نمی‌کند که این نرم‌افزار روزی می‌میرد.
سازمان‌های بزرگ هزینه‌های قابل‌توجهی را صرف خرید تجهیزات IT از سخت‌افزار گرفته تا نرم‌افزار و تجهیزات شبکه‌ای می‌کنند و نکته قابل توجه این‌که بیشترین درصد خرابی و مشکلات از آن نرم‌افزار است، اما به راستی چرا این‌گونه است؟ چرا در اکثر پروژه‌های نرم‌افزاری کشورمان این مشکل دیده می‌شود؟ تجربه شخصی من برای پاسخ دادن به این سؤالا‌ت، عدم توجه به هشت نکته مهم را دخیل می‌داند:
۱) یکی از مشکلات پروژه‌های نرم‌افزاری نداشتن برنامه کاری یا داشتن برنامه زمان‌بندی غیرحقیقی است. به عنوان مثال، در حالی که نظر کارشناسی این است که مدت زمان اتمام پروژه با توجه به اجزای آن چهار ماه طول خواهد کشید، شما به عنوان مدیر پروژه نرم‌افزاری نباید قول بدهید که پروژه دو ماه دیگر به اتمام می‌رسد. این کار باعث خواهد شد به دلیل کمبود وقت کیفیت نرم‌افزار کم شود.
۲) به‌کارگیری نرم‌افزاری که کیفیت پایینی داشته باشد حتماً با شکست روبه‌رو می‌شود. تصور کنید که روی اجزای سیستم‌های نرم‌افزاری آزمایش کاملی صورت نگیرد و از روش‌های آزمایش مکرر در هنگام برنامه‌نویسی استفاده نشود. اگر نیازهای کاربران (نه به صورت کامل بلکه جزئی) تغییر کند سیستم دیگر نمی‌تواند قابل استفاده باشد.
۳) نباید فکر کنیم اتفاق خارق‌العاده‌ای رخ می‌دهد و کاربران سیستم همان‌گونه که ما به آن‌ها می‌گوییم، با سیستم رفتار می‌کنند. شاید ورود اطلاعات زیاد و رفتارهای مختلف کاربران در سیستم تأثیر داشته باشد و باعث شود نتیجه خوبی از پروژه نگیریم.
۴) اگر چه تغییر کلی نیازهای کاربران پروژه نرم‌افزاری را با مشکل روبه‌رو می‌کند، اما باور کنید که کاربران نیازهای جدیدی خواهند داشت. بهتر است در پروژه‌های نرم‌افزاری از روش‌های آبشاری قدیمی استفاده نکنیم و از روش‌های نوین مانند test driven development بهره بگیریم.
۵) در پروژه‌های نرم‌افزاری از نیروهای آزموده و حرفه‌ای استفاده کنیم. اگر چه نیروهای غیرحرفه‌ای می‌توانند برنامه‌های کوچکی تولید کنند، اما پروژه‌های نرم‌افزاری بزرگ هم به تخصص و تجربه زیادی نیاز دارند. به صرف این‌که فردی تنها تحصیلات دانشگاهی عالی در رشته نرم‌افزار دارد نمی‌توان گفت که می‌تواند عضوی از تیم پروژه باشد. در انتخاب نیروهای پروژه دقت کنید، چون دلیل از بین رفتن اغلب پروژه‌های نرم‌افزاری استفاده از نیروهای غیرمتخصص است.
۶) برخی از کاربران سیستم که خود به استفاده از سیستم راغب نبودند و سرپرستشان آن‌ها را مجبور می‌کرد از سیستم استفاده کنند، در مقابل سیستم و نرم‌افزار مقاومت می‌کردند و می‌خواستند همچنان به صورت دفتری کار خود را انجام دهند، زیرا به نظر آن‌ها استفاده از سیستم‌های نرم‌افزاری حیطه وظایف آن‌ها را محدود می‌کند و نمی‌گذارد آن‌ها در انجام وظایف کوتاهی کنند (یا به عبارتی از زیر کار در بروند). شاید هم هنوز به نرم‌افزارها اعتماد ندارند و بر این گمانند که مغزشان در امور محاسباتی از کامپیوتر بهتر کار می‌کند.
۷) کاربران اصلی سیستم در طول مراحل طراحی نرم‌افزارها حضور ندارند، به همین دلیل است که وقتی نرم‌افزار آماده می‌شود می‌خواهند آن را تغییر دهند. کار آن‌ها مانند این موضوع است که تنها اندازه‌های خود را به خیاط بدهیم و بگوییم حوصله پرو را نداریم. حاصل کار شاید لباسی باشد که اندازهِ شما باشد، اما به احتمال خیلی زیاد کارایی کافی را نخواهد داشت.
۸) فرض کنید نرم‌افزار عاری از اشکال است و در اختیار کاربر قرار می‌گیرد. حال اگر کاربر به دلیلی وقت خود را صرف ایرادگیری از سیستم کند یا اطلاعات مورد نیاز را به آن وارد نکند پروژه نرم‌افزاری به نتیجه نخواهد رسید. برخی از کاربران سیستم فکر می‌کنند که وظیفه برنامه‌نویس وارد کردن اطلاعات به سیستم است.
در کشورهای صنعتی درصد مشکلات پروژه‌های نرم‌افزاری بسیار کمتر از کشور ما است. تجربه به ما نشان داده که تقریباً بیست‌درصد از پروژه‌های نرم‌افزاری کوچک و حدود ده تا پانزده درصد از پروژه‌های نرم‌افزاری بزرگ مشکل دارند. در واقع این پروژه‌ها آنقدر مشکل دارند که نمی‌توان آن‌ها را اصلاح کرد. جالب‌تر این‌که برخی از مدیران پروژه‌های نرم‌افزاری که پروژه‌‌هایشان با مشکل روبه‌رو می‌شود، نمی‌خواهند این واقعیت را بپذیرند که نرم‌افزارشان مرده است و دیگر نمی‌توان کاری برایش انجام داد.
به عنوان مثال، حدود دو سال پیش در یکی از سازمان‌های دولتی به وسیلهِ گروهی که تخصص نرم‌افزاری نداشته و تنها فنی بودند سیستمی طراحی شد و تیم نرم‌افزاری مسئولیت اجرای آن را به عهده گرفت. بعد از آماده سازی محصول کاربر سیستم تغییرات زیادی در سیستم به وجود آورد که ساختار کلی آن را تغییر داد و هنوز بعد از این همه مدت هیچ‌گاه سیستم عملیاتی نشده است.
نمی‌توانیم تمامی اشکالات را به کاربر یا مدیر پروژه نسبت بدهیم. به نظر من اگر بتوانیم تمامی هشت نکته‌ای را که در بالا اشاره شد، در نظر بگیریم، درصد کمتری از پروژه‌های نرم‌افزاری ما با شکست روبه‌رو می‌شوند.
معرفي سايت مرتبط با اين مقاله
سازمان‌های بزرگ هزینه‌های قابل‌توجهی را صرف خرید تجهیزات IT از سخت‌افزار گرفته تا نرم‌افزار و تجهیزات شبکه‌ای می‌کنند و نکته قابل توجه این‌که بیشترین درصد خرابی و مشکلات از آن نرم‌افزار است، اما به راستی چرا این‌گونه است؟ چرا در اکثر پروژه‌های نرم‌افزاری کشورمان این مشکل دیده می‌شود؟ تجربه شخصی من برای پاسخ دادن به این سؤالا‌ت، عدم توجه به هشت نکته مهم را دخیل می‌داند:
۱) یکی از مشکلات پروژه‌های نرم‌افزاری نداشتن برنامه کاری یا داشتن برنامه زمان‌بندی غیرحقیقی است. به عنوان مثال، در حالی که نظر کارشناسی این است که مدت زمان اتمام پروژه با توجه به اجزای آن چهار ماه طول خواهد کشید، شما به عنوان مدیر پروژه نرم‌افزاری نباید قول بدهید که پروژه دو ماه دیگر به اتمام می‌رسد. این کار باعث خواهد شد به دلیل کمبود وقت کیفیت نرم‌افزار کم شود.
۲) به‌کارگیری نرم‌افزاری که کیفیت پایینی داشته باشد حتماً با شکست روبه‌رو می‌شود. تصور کنید که روی اجزای سیستم‌های نرم‌افزاری آزمایش کاملی صورت نگیرد و از روش‌های آزمایش مکرر در هنگام برنامه‌نویسی استفاده نشود. اگر نیازهای کاربران (نه به صورت کامل بلکه جزئی) تغییر کند سیستم دیگر نمی‌تواند قابل استفاده باشد.
۳) نباید فکر کنیم اتفاق خارق‌العاده‌ای رخ می‌دهد و کاربران سیستم همان‌گونه که ما به آن‌ها می‌گوییم، با سیستم رفتار می‌کنند. شاید ورود اطلاعات زیاد و رفتارهای مختلف کاربران در سیستم تأثیر داشته باشد و باعث شود نتیجه خوبی از پروژه نگیریم.
۴) اگر چه تغییر کلی نیازهای کاربران پروژه نرم‌افزاری را با مشکل روبه‌رو می‌کند، اما باور کنید که کاربران نیازهای جدیدی خواهند داشت. بهتر است در پروژه‌های نرم‌افزاری از روش‌های آبشاری قدیمی استفاده نکنیم و از روش‌های نوین مانند test driven development بهره بگیریم.
۵) در پروژه‌های نرم‌افزاری از نیروهای آزموده و حرفه‌ای استفاده کنیم. اگر چه نیروهای غیرحرفه‌ای می‌توانند برنامه‌های کوچکی تولید کنند، اما پروژه‌های نرم‌افزاری بزرگ هم به تخصص و تجربه زیادی نیاز دارند. به صرف این‌که فردی تنها تحصیلات دانشگاهی عالی در رشته نرم‌افزار دارد نمی‌توان گفت که می‌تواند عضوی از تیم پروژه باشد. در انتخاب نیروهای پروژه دقت کنید، چون دلیل از بین رفتن اغلب پروژه‌های نرم‌افزاری استفاده از نیروهای غیرمتخصص است.
۶) برخی از کاربران سیستم که خود به استفاده از سیستم راغب نبودند و سرپرستشان آن‌ها را مجبور می‌کرد از سیستم استفاده کنند، در مقابل سیستم و نرم‌افزار مقاومت می‌کردند و می‌خواستند همچنان به صورت دفتری کار خود را انجام دهند، زیرا به نظر آن‌ها استفاده از سیستم‌های نرم‌افزاری حیطه وظایف آن‌ها را محدود می‌کند و نمی‌گذارد آن‌ها در انجام وظایف کوتاهی کنند (یا به عبارتی از زیر کار در بروند). شاید هم هنوز به نرم‌افزارها اعتماد ندارند و بر این گمانند که مغزشان در امور محاسباتی از کامپیوتر بهتر کار می‌کند.
۷) کاربران اصلی سیستم در طول مراحل طراحی نرم‌افزارها حضور ندارند، به همین دلیل است که وقتی نرم‌افزار آماده می‌شود می‌خواهند آن را تغییر دهند. کار آن‌ها مانند این موضوع است که تنها اندازه‌های خود را به خیاط بدهیم و بگوییم حوصله پرو را نداریم. حاصل کار شاید لباسی باشد که اندازهِ شما باشد، اما به احتمال خیلی زیاد کارایی کافی را نخواهد داشت.
۸) فرض کنید نرم‌افزار عاری از اشکال است و در اختیار کاربر قرار می‌گیرد. حال اگر کاربر به دلیلی وقت خود را صرف ایرادگیری از سیستم کند یا اطلاعات مورد نیاز را به آن وارد نکند پروژه نرم‌افزاری به نتیجه نخواهد رسید. برخی از کاربران سیستم فکر می‌کنند که وظیفه برنامه‌نویس وارد کردن اطلاعات به سیستم است.
در کشورهای صنعتی درصد مشکلات پروژه‌های نرم‌افزاری بسیار کمتر از کشور ما است. تجربه به ما نشان داده که تقریباً بیست‌درصد از پروژه‌های نرم‌افزاری کوچک و حدود ده تا پانزده درصد از پروژه‌های نرم‌افزاری بزرگ مشکل دارند. در واقع این پروژه‌ها آنقدر مشکل دارند که نمی‌توان آن‌ها را اصلاح کرد. جالب‌تر این‌که برخی از مدیران پروژه‌های نرم‌افزاری که پروژه‌‌هایشان با مشکل روبه‌رو می‌شود، نمی‌خواهند این واقعیت را بپذیرند که نرم‌افزارشان مرده است و دیگر نمی‌توان کاری برایش انجام داد.
به عنوان مثال، حدود دو سال پیش در یکی از سازمان‌های دولتی به وسیلهِ گروهی که تخصص نرم‌افزاری نداشته و تنها فنی بودند سیستمی طراحی شد و تیم نرم‌افزاری مسئولیت اجرای آن را به عهده گرفت. بعد از آماده سازی محصول کاربر سیستم تغییرات زیادی در سیستم به وجود آورد که ساختار کلی آن را تغییر داد و هنوز بعد از این همه مدت هیچ‌گاه سیستم عملیاتی نشده است.
نمی‌توانیم تمامی اشکالات را به کاربر یا مدیر پروژه نسبت بدهیم. به نظر من اگر بتوانیم تمامی هشت نکته‌ای را که در بالا اشاره شد، در نظر بگیریم، درصد کمتری از پروژه‌های نرم‌افزاری ما با شکست روبه‌رو می‌شوند.
معرفي سايت مرتبط با اين مقاله
تصاوير زيبا و مرتبط با اين مقاله
