يك مكالمه فرضي:

– شغل شما چيست؟

– جواب: من در زمينه توليد نرم افزار فعاليت ميكنم.

– چه خوب، پس برنامه نويسي مي‌كنيد!

بحثهاي اساسي

يكي از جدي ترين افراد در زمينة فلسفه مهندسي نرم افزار بي شك Steven McConnell است. او در كتاب متفاوت خود “Professional Software Develompment” مي‌گويد:

بهترين تصور از توسعه نرم افزار چيست؟ آيا علم است؟ يا هنر است؟ يا شايد هم يكجور مهارت باشد؟ شايد هم كلاً مقوله ديگريست؟

افرادي كه از هنري بودن برنامه نويسي دفاع مي‌كنند به جنبه‌هاي زيبايي شناسي توسعه نرم افزار اشاره مي‌نمايند و استدلال مي‌كنند كه علم، الهام و خلاقيت را به بند مي‌كشد.

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

پرسش صحيح اين نيست كه “توسعه نرم افزار در حال حاضر چه چيزي است؟” بلكه سئوال درست اين است كه : “توسعه نرم افزار چه بايد بشود؟” به عقيده من، جواب سئوال مشخص است: توسعة حرفه‌اي نرم افزار بايد مهندسي باشد. آيا اكنون اين گونه است؟ خير ولي بي شك بايد بشود.[McC03]

هدف از نقل قول اين مطالب اين بود كه نشان دهم Steven McConnell به عنوان يكي از تأثيرگذارترين افراد در تاريخ نرم افزار به همراه تعداد كثيري از افرادي كه درحوزه ادبيات مهندسي نرم افزار فعال هستند، رأي به “مهندسي” بودن فرآيند توليد نرم افزار داده‌اند.

فكر نمي‌كنم صحبت در زمينه اثبات مناسب بودن ديدگاه “مهندسي” براي نرم افزار لازم باشد، بحثهاي مهمتري وجود دارد…

در جستجوي تعريف مناسب

حال كه پذيرفتيم “مهندسي” راه چاره توليد نرم افزار است، بهتراست تعريفي از “مهندسي نرم افزار” نيز ارائه شود.

ابتدا بهتر است به مفهوم واژه “مهندسي” اشاره كنيم:

مهندسي عبارتست از بكارگيري اصول علمي و رياضي براي مقاصد عملي[منبع ندارد]

منابع متعددي اقدام به تعريف مهندسي نرم افزار كرده اند، اجازه بدهيد تعريف IEEE كه بيشتر از بقيه مورد تأييد است[PRE01] را ذكر كنم:

اعمال يك رويكرد قائده‌مند، منظم و قابل سنجش در زمينة توسعه، بهره برداري و نگهداري نرم افزار، كه به آن كاربرد مهندسي در نرم افزار گفته ميشود.[IEE04]

اين تعريف شايد شما را از مهندسي نرم افزار فراري دهد يا اين فكر را در ذهن بياورد كه مهندسي نرم افزار منابع زيادي را بيهوده هدر مي‌دهد.

در اين زمينه Steven McConnell به صراحت بيان مي‌كند كه:

برخي تصور مي‌كنند ديدگاه مهندسي نسبت به توسعة نرم افزار به منزله استفاده از روشهاي سختگيرانه – نوشتن برنامه همانند اثبات رياضي – مي‌باشد. عقل و تجربه نشان داده است كه انجام اين كار براي اكثر پروژه‌ها، زياده روي است. برخي نيز برخلاف گروه اول اعتقاد دارند كه نرم افزار تجاري آنقدر از تغيير شرايط بازار تحت تأثير قرار مي‌گيرد كه نمي‌توان مهندسي دقيق و زمانبري بر روي آن اجرا نمود.

اين استدلالهاي متناقض، بر اساس ديد محدود و اشتباه از مهندسي بنا نهاده شده است. مهندسي كاربرد قوانين علمي در راستاي اهداف عملي است. اگر مهندسي كاربردي نباشد، مهندسي خوبي نيست. ايدة اعمال روشهاي سختگيرانه به همه پروژه‌هاي نرم افزاري به اندازه استفاده از روش ساخت و ترميم (Build and Fix) مضر است. [McC03]

در واقع پروژه شما در هر ابعاد و اندازه‌اي كه باشد مي‌تواند از “مهندسي” سود ببرد، به اين شرط كه روشهاي موجود را شناخته و از آنها با توجه به مشخصات پروژه سود ببريد.

در بخش بعدي مشكلات مهندسي شدن نرم افزار را بررسي مي‌كنيم.