Banner Advertisement
 
Advertisements
 
پربيننده‌ترين مطالب
در هفت روز گذشته
 
آخرين خبرها
 
جديدترين مقالات
 
 
ارسال براي دوستان
نسخه مناسب چاپ
ديدگاه / چرا نرم‌افزارها مي‌ميرند؟

امين صفايي
ماهنامه شبکه - ارديبهشت ۱۳۸۷ شماره 88

اشاره :

معمولاً وقتي سازمان يا شركتي نرم‌افزاري را سفارش مي‌دهد، هيچ‌گاه به اين موضوع فكر نمي‌كند كه ممكن است قبل از تحويل گرفتن آن، نرم‌افزار او بميرد و از آن محصول نتواند استفاده كند. يا اگر نرم‌افزار را سالم تحويل بگيرد باز هم به اين موضوع فكر نمي‌كند كه اين نرم‌افزار روزي مي‌ميرد.


معمولاً وقتي سازمان يا شركتي نرم‌افزاري را سفارش مي‌دهد، هيچ‌گاه به اين موضوع فكر نمي‌كند كه ممكن است قبل از تحويل گرفتن  آن، نرم‌افزار او بميرد و از آن محصول نتواند استفاده كند. يا اگر نرم‌افزار را سالم تحويل بگيرد باز هم به اين موضوع فكر نمي‌كند كه اين نرم‌افزار روزي مي‌ميرد.

سازمان‌هاي بزرگ هزينه‌هاي قابل‌توجهي را صرف خريد تجهيزات IT از سخت‌افزار گرفته تا نرم‌افزار و تجهيزات شبكه‌اي مي‌كنند و نكته قابل توجه اين‌كه بيشترين درصد خرابي و مشكلات از آن نرم‌افزار است، اما به راستي چرا اين‌گونه است؟ چرا در اكثر پروژه‌هاي نرم‌افزاري كشورمان اين مشكل ديده مي‌شود؟ تجربه شخصي من براي پاسخ دادن به اين سؤالا‌ت، عدم توجه به هشت نكته مهم را دخيل مي‌داند:

 1- يكي از مشكلات پروژه‌هاي نرم‌افزاري نداشتن برنامه كاري يا داشتن برنامه زمان‌بندي غيرحقيقي است. به عنوان مثال، در حالي كه نظر كارشناسي اين است كه مدت زمان اتمام پروژه با توجه به اجزاي آن چهار ماه طول خواهد كشيد، شما به عنوان مدير پروژه نرم‌افزاري نبايد قول بدهيد كه پروژه دو ماه ديگر به اتمام مي‌رسد. اين كار باعث خواهد شد به دليل كمبود وقت كيفيت نرم‌افزار كم شود.

 2- به‌كارگيري نرم‌افزاري كه كيفيت پاييني داشته باشد حتماً با شكست روبه‌رو مي‌شود. تصور كنيد كه روي اجزاي سيستم‌هاي نرم‌افزاري آزمايش كاملي صورت نگيرد و از روش‌هاي آزمايش مكرر در هنگام برنامه‌نويسي استفاده نشود. اگر نيازهاي كاربران (نه به صورت كامل بلكه جزئي) تغيير كند سيستم ديگر نمي‌تواند قابل استفاده باشد.

 3- نبايد فكر كنيم اتفاق خارق‌العاده‌اي رخ مي‌دهد و كاربران سيستم همان‌گونه كه ما به آن‌ها مي‌گوييم، با سيستم رفتار مي‌كنند. شايد ورود اطلاعات زياد و رفتارهاي مختلف كاربران در سيستم تأثير داشته باشد و باعث شود نتيجه خوبي از پروژه نگيريم.

 4- اگر چه تغيير كلي نيازهاي كاربران پروژه نرم‌افزاري را با مشكل روبه‌رو مي‌كند، اما باور كنيد كه كاربران نيازهاي جديدي خواهند داشت. بهتر است در پروژه‌هاي نرم‌افزاري از روش‌هاي آبشاري قديمي استفاده نكنيم و از روش‌هاي نوين مانند test driven development بهره بگيريم. (براي اطلاعات بيشتر به اين نشاني مراجعه کنيد)

 5- در پروژه‌هاي نرم‌افزاري از نيروهاي آزموده و حرفه‌اي استفاده كنيم. اگر چه نيروهاي غيرحرفه‌اي مي‌توانند برنامه‌هاي كوچكي توليد كنند، اما پروژه‌هاي نرم‌افزاري بزرگ هم به تخصص و تجربه زيادي نياز دارند. به صرف اين‌كه فردي تنها تحصيلات دانشگاهي عالي در رشته نرم‌افزار دارد نمي‌توان گفت كه مي‌تواند عضوي از تيم پروژه باشد. در انتخاب نيروهاي پروژه دقت كنيد، چون دليل از بين رفتن اغلب پروژه‌هاي نرم‌افزاري استفاده از نيروهاي غيرمتخصص است.

 6- برخي از كاربران سيستم كه خود به استفاده از سيستم راغب نبودند و سرپرستشان آن‌ها را مجبور مي‌كرد از سيستم استفاده كنند، در مقابل سيستم و نرم‌افزار مقاومت مي‌كردند و مي‌خواستند همچنان به صورت دفتري كار خود را انجام دهند، زيرا به نظر آن‌ها استفاده از سيستم‌هاي نرم‌افزاري حيطه وظايف آن‌ها را محدود مي‌كند و نمي‌گذارد آن‌ها در انجام وظايف كوتاهي كنند (يا به عبارتي از زير كار در بروند). شايد هم هنوز به نرم‌افزارها اعتماد ندارند و بر اين گمانند كه مغزشان در امور محاسباتي از كامپيوتر بهتر كار مي‌كند.

 7- كاربران اصلي سيستم در طول مراحل طراحي نرم‌افزارها حضور ندارند، به همين دليل است كه وقتي نرم‌افزار آماده مي‌شود مي‌خواهند آن را تغيير دهند. كار آن‌ها مانند اين موضوع است كه تنها اندازه‌هاي خود را به خياط بدهيم و بگوييم حوصله پرو را نداريم. حاصل كار شايد لباسي باشد كه اندازهِ شما باشد، اما به احتمال خيلي زياد كارايي كافي را نخواهد داشت.
 8- فرض كنيد نرم‌افزار عاري از اشكال است و در اختيار كاربر قرار مي‌گيرد. حال اگر كاربر به دليلي وقت خود را صرف ايرادگيري از سيستم كند يا اطلا‌عات مورد نياز را به آن وارد نكند پروژه نرم‌افزاري به نتيجه نخواهد رسيد. برخي از كاربران سيستم فكر مي‌كنند كه وظيفه برنامه‌نويس وارد كردن اطلاعات به سيستم است.

در كشورهاي صنعتي درصد مشكلات پروژه‌هاي نرم‌افزاري بسيار كمتر از كشور ما است. تجربه به ما نشان داده كه تقريباً بيست‌درصد از پروژه‌هاي نرم‌افزاري كوچك و حدود ده تا پانزده درصد از پروژه‌هاي نرم‌افزاري بزرگ مشكل دارند. در واقع اين پروژه‌ها آنقدر مشكل دارند كه نمي‌توان آن‌ها را اصلاح كرد. جالب‌تر اين‌كه برخي از مديران پروژه‌هاي نرم‌افزاري كه پروژه‌‌هايشان با مشكل روبه‌رو مي‌شود، نمي‌خواهند اين واقعيت را بپذيرند كه نرم‌افزارشان مرده است و ديگر نمي‌توان كاري برايش انجام داد.

به عنوان مثال، حدود دو سال پيش در يكي از سازمان‌هاي دولتي به وسيلهِ گروهي كه تخصص نرم‌افزاري نداشته و تنها فني بودند سيستمي طراحي شد و تيم نرم‌افزاري مسئوليت اجراي آن را به عهده گرفت. بعد از آماده سازي محصول كاربر سيستم تغييرات زيادي در سيستم به وجود آورد كه ساختار كلي آن را تغيير داد و هنوز بعد از اين همه مدت هيچ‌گاه سيستم عملياتي نشده است. نمي‌توانيم تمامي اشكالات را به كاربر يا مدير پروژه نسبت بدهيم. به نظر من اگر بتوانيم تمامي هشت نكته‌اي را كه در بالا اشاره شد، در نظر بگيريم، درصد كمتري از پروژه‌هاي نرم‌افزاري ما با شكست روبه‌رو مي‌شوند.

     
   
مطالب مرتبط
Debugger خود باشيد!
( برنامه نويسي )
مايكرو كاپوچينو! J2ME؛ جاوا در قلمرو موبايل‌
( برنامه نويسي )
يك داستان اپن‌سورس ‌- قسمت پاياني
( برنامه نويسي )
اگر به جاي رييس مايكروسافت بودم...
( برنامه نويسي )
نسخه كپي ممنوع، حريم خصوصي ممنوع !
( كدنبشته‌ها )
چگونه يك سرويس ويندوز بسازيم؟
( برنامه نويسي )
تست كنيد!
( كدنبشته‌ها )
آيا آندروئيد دگرگون‌‌ساز خواهد بود؟
( برنامه نويسي )
نگاهي به NET Compact Framework.
( برنامه نويسي )
يك پنجره كوچولو براي تمام فصول‌؛ آشنايي با برنامه‌نويسي به زبان ++C براي ويندوز موبايل‌
( برنامه نويسي )
شوق برنامه‌نويسي‌
( برنامه نويسي )
زبان‌هاي جديد برنامه‌نويسي‌
( كدنبشته‌ها )
نور فلاش يا پرتو نقره‌اي؟
( برنامه نويسي )
دات‌نت فريم‌ورك چگونه كار مي‌كند؟
( برنامه نويسي )
اخلاق حرفه‌اي در برخورد با مشتري‌
( كدنبشته‌ها )
Visual Studio 2008 در راه است!
( كدنبشته‌ها )
مسابقات برنامه‌نويسي دانشجويي ACM
( برنامه نويسي )
كدام زبان برنامه‌نويسي را انتخاب كنيم؟
( برنامه نويسي )
برنامه‌نويسي تحت وب سريع با ‌Ruby on Rails
( كدنبشته‌ها )
گارسون! يك پرس XML لطفاً
( برنامه نويسي )
پشت پنجره‌هاي زنده‌ - نگاهي به کيت توسعه نرم افزاري Windows Live
( برنامه نويسي )
DIP؛ يك اصل مهم در طراحي چابكانه
( كدنبشته‌ها )
تجمع گوگلولوژيست‌هاي باوفا!
( برنامه نويسي )
يک اصل مهم: هم باز و هم بسته
( كدنبشته‌ها )
تنها يك دليل براي تغيير كافي است!
( كدنبشته‌ها )
برنامه‌نويسي پاپ!
( برنامه نويسي )
چرا نرم‌افزارها باگ ‌دارند؟
( برنامه نويسي )
طراحي چابكانه - Agile Software Development
( كدنبشته‌ها - برنامه نويسي )
ميانگين نظر خوانندگان از ميان 3 نظر ارسال شده :
خيلي ضعيف
متوسط
عالي
نظر شما درباره این مطلب چیست و به آن چه امتیازی می دهید؟ اگر پيرامون موضوع مطرح شده در اين مطلب (صرف ‌نظر از چگونگي ارائه آن در اينجا) نظر يا عقيده‌اي داريد، مي‌توانيد ديدگاه خود را با ما در ميان بگذاريد.
يادآوري:
1 - مجله شبکه هر ماه گزيده‌اي از نظرات، پيشنهادات و انتقادات بازديدکنندگان سايت را در بخش ويژه‌اي تحت عنوان "روي خط شبکه" به چاپ مي‌رساند.
2 - اگر مايليد پاسخ پيام شما را درصورت لزوم برايتان بفرستيم، حتما آدرس ايميل خود را بنويسيد.
3 - مي‌توانيد بدون نوشتن مشخصات و نظر خود يا همراه با آن، به اين مطلب نمره بدهيد - براي نمره دادن کافي است يکي از شش گزينه زير را انتخاب و دکمه ارسال را فشار دهيد
نام
Email
آدرس سايت
اگر از سيستم‌عامل ويندوز و مرورگر IE استفاده مي‌کنيد وضعيت صفحه کليد خود را در حالت انگليسي نگهداريد و از Ctrl+Shift براي تغيير زبان استفاده کنيد
 
نظر (حداکثر 1000 کاراکتر)
پيام شما شامل 0 کاراکتر است
 
 
 

کلیه حقوق مادی و معنوی این سایت متعلق به ماهنامه شبکه می باشد

© 1998-2007 Shabakeh Magazine. All Right Reserved.

|
|
|
|
|
|