معمولاً وقتی سازمان یا شركتی نرمافزاری را سفارش میدهد، هیچگاه به این موضوع فكر نمیكند كه ممكن است قبل از تحویل گرفتن آن، نرمافزار او بمیرد و از آن محصول نتواند استفاده كند. یا اگر نرمافزار را سالم تحویل بگیرد باز هم به این موضوع فكر نمیكند كه این نرمافزار روزی میمیرد.
سازمانهای بزرگ هزینههای قابلتوجهی را صرف خرید تجهیزات IT از سختافزار گرفته تا نرمافزار و تجهیزات شبكهای میكنند و نكته قابل توجه اینكه بیشترین درصد خرابی و مشكلات از آن نرمافزار است، اما به راستی چرا اینگونه است؟ چرا در اكثر پروژههای نرمافزاری كشورمان این مشكل دیده میشود؟ تجربه شخصی من (بعنوان برنامهنویس) برای پاسخ دادن به این سؤالات، عدم توجه به هشت نكته مهم را دخیل میداند:
1- یكی از مشكلات پروژههای نرمافزاری نداشتن برنامه كاری یا داشتن برنامه زمانبندی غیرحقیقی است. به عنوان مثال، در حالی كه نظر كارشناسی این است كه مدت زمان اتمام پروژه با توجه به اجزای آن چهار ماه طول خواهد كشید، شما به عنوان مدیر پروژه نرمافزاری نباید قول بدهید كه پروژه دو ماه دیگر به اتمام میرسد. این كار باعث خواهد شد به دلیل كمبود وقت كیفیت نرمافزار كم شود.
2- بهكارگیری نرمافزاری كه كیفیت پایینی داشته باشد حتماً با شكست روبهرو میشود. تصور كنید كه روی اجزای سیستمهای نرمافزاری آزمایش كاملی صورت نگیرد و از روشهای آزمایش مكرر در هنگام برنامهنویسی استفاده نشود. اگر نیازهای كاربران (نه به صورت كامل بلكه جزئی) تغییر كند سیستم دیگر نمیتواند قابل استفاده باشد.
3- نباید فكر كنیم اتفاق خارقالعادهای رخ میدهد و كاربران سیستم همانگونه كه ما به آنها میگوییم، با سیستم رفتار میكنند. شاید ورود اطلاعات زیاد و رفتارهای مختلف كاربران در سیستم تأثیر داشته باشد و باعث شود نتیجه خوبی از پروژه نگیریم.
4- اگر چه تغییر كلی نیازهای كاربران پروژه نرمافزاری را با مشكل روبهرو میكند، اما باور كنید كه كاربران نیازهای جدیدی خواهند داشت. بهتر است در پروژههای نرمافزاری از روشهای آبشاری قدیمی استفاده نكنیم و از روشهای نوین مانند test driven development بهره بگیریم.
