alawiala
یک شنبه 22 آذر 1388, 13:33 عصر
بررسی مهندسی نرم افزار از دیدگاه Pete McBreen قسمت اول
Software Craftsmanship, The New Imperative
Pete McBreen
Publisher: Addison Wesley
First Edition August 01, 2001
ISBN: 0-201-73386-2, 208 pages
کتاب بسیار جالبی است که در مورد مهندسی نرم افزار سخن می گوید البته مخاطبین کتاب برنامه نویسان نیستند بلکه این کتاب برای مدیران و تصمیم گیرندگان شرکتهای نرم افزاری نوشته شده است
این کتاب در مورد مهندسی نرم افزار و مدیریت پروژه های نرم افزاری دیگاه متفاوتی دارد
که شاید برای خیلی از ماها عجیب باشد بد نیست آن را برای شما نقل قول کنم امیدوارم مفید باشد
خلاصه ای از این کتاب را برای شما نقل می کنم
در این کتاب نویسنده عقیده دارد که روشهای مهندسی نرم افزار برای بسیاری از پروژه ها مناسب نیست و این روشها تنها در پروژه های نرم افزاری بزرگ کارایی دارد اما در پروژه های متوسط تجاری کارآمد نیست. به چند دلیل :
1- روشهای مهندسی نر م افزار بسیار شبیه به روشهای مهندسی معماری و مکانیک است و این برای رشته ای که مهمترین عنصر ان نیروی انسانی و عنصر تفکر و ذهن است اصلا مناسب نیست
به عنوان مثال در مهندسی مکانیک می خواهند یک ماشین بسازند . ابتدا طراحی و تجزیه و تحلیل می کنند نیازمندیها را تشخیص می دهند هزینه ها را محاسبه می کنند چندین بار تست می کنند و زمان تولید را براورد می کنند و در نهایت با بودجه ای مشخص این ماشین تولید می شود .اما در مهندسی نرم افزار تمام این پروسه بالا طی می شود اما خروجی ان تنها یک نسخه از نرم افزار است که ممکن است نسخه نهایی نباشد و شاید مود پسند کاربر نهایی قرار نگیرد چرا که فرایند تحویل نرم افزار بسیار متفاوتتر از فرایند ماشین است .
همچنین در فرایند تولید نرم افزار سخت افزارها مهم نیستند بلکه نیروی انسانی و کیفیت این نیرو اهمیت دارد
اگر شما برنامه نویس حرفه ای داشته باشید خیلی راحت می تواند این فرایند را برای شما انجام دهد در حالی که ممکن است یک تیم نرم افزاری متوسط از انجام آن حتی در صورت استفاده از مهندسی نرم افزار عاجز باشد .
مثلا : اگر 2 نفر برای حفاری کردن زمینی به 2 روز زمان نیاز دارند حال اگر بخواهیم این کار را یک روزه انجام دهیم به چند نفر نیاز داریم . جواب 4 نفر است. اما این جواب ممکنه درست نباشد چراکه ممکن است بدلیل برخی محدودیتها 4 نفر نتوانند با هم کار کنند لذا جواب ما منتفی می شود.
2-روشهای مهندسی نرم افزار فرایندی برای بررسی میزان تخصص برنامه نویسان ندارد.بلکه تنها اقدا م به تقسیم وظایف می کند . در حالی که برنامه نویس حرفه ای مهمترین عنصر این فرایند باید باشد.
مثلا در اماری که در آمریکا جمع آوری شده بیش از دو سوم پروژه های نرم افزاری توسط مدیریت برنامه نویسان حرفه ای به سرانجام می رسد نه توسط روشهای مهندسی نرم افزار .
3- روشهای مهندسی نرم افزار پیشنهاد می کند که قبل از شروع نرم افزار طرحهایی را بر روی کاغذ داشته باشند در حالی که بیشتر برنامه نویسان حرفه ای حوصله اینکار را ندارند و سریعا سراغ کد نویسی می روند چرا که اینکار را مفید تر می دانند و سریعتر می توانند ایده های نرم افزار ی خود را به کاربر انتقال دهند چرا که بسیاری از سفارش دهندگان نرم افزار از طرحهای کاغذی چیزی نمی دانند.
4- روشهای مهندسی نرم افزار نقش تحلیلگر , برنامه نویس , تست کننده , مستند نویس , و غیره را از هم تفکیک می کند . و دلیل این کار را تخصص هر فرد می داند
اما در صنعت نرم افزار می بینیم بهترین کسی که می تواند نرم افزار را پشتیبانی کند که این نرم افزار را نوشته است و آن را تحلیل کرده است چرا که در جریان کل پروژه بوده است
در روشهای نرم افزاری چون هر کس جدا گانه برای ان نقش تعیین شده جوابگو نیست در حالی که ما اگر به پروژه های سورس باز نگاه کنیم می بینیم که اکثر این پروژه ها توسط چندنفر نوشته شده اند که همه در تمام مراحل حضور دارند در نتیجه وقتی اولین نسخه از نرم افزار حاضر می شود بدلیل مشارکت چند نفر در تمام مراحل خروجی خیلی بهتری داره و بیشتر مورد استقبال واقع می شود علاوه بر آن چون چند نفر در تمام مراحل حضور داشتن پس پشتیبانی هم توسط تمام افراد انجام می شود
در حالی که در روشهای مهندسی نرم افزار پشتیبانی توسط گروه دیگری انجام می شود که در فرایند تولید نرم افزار حضور نداشتن به همین دلیل نمی توانند خوب پشتیبانی کنند
حال در پروژه ای سورس باز بدلیل حضور چند نفر در کل فرایند همگی به پروژه تسلط دارند و اگر یکی از عناصر از پروژه خارج شد باعث توقف کار نمی شوند اما در روشهای مهندسی نرم افزار بدلیل تقسیم کار بین چند نفر منفصل اگر یکی از پروژه خارج شد ممکن است باعث به هم خوردن کار شود
سناریوی آخر ایجاد تغیرات در نرم افزار
در روشهای مهندسی نرم افزار برای انجام تغییری یا اصلاح فرایندی باید کل مستندات و نقشه های تجزیه و تحلیل برنامه را مجددا اصلاح کنیم و همچنین سورس نرم افزار را اصلاح کنیم در این حالت کد نویس باید همه چیز را مطالعه کند و سورس موجود را بفهمد (چون مکن است کد نویس قبلی رفته باشد و فرد دیگری جایگزین آن شده باشد) تا بتواند تغییرات جدید را در سورس اعمال کند که در صد خطا بسیار بالاست
اما در پروژهای سورس باز گروهی بدلیل اینکه چند نفر در انجام پروژه دخیل بوده اند انجام تغییرات بسیار ساده تر است
5- 5- در روشهای مهندسی نرم افزار ادعا می شود که نرم افزار را بصورت لایه ای یا اجزای جدا از هم بنویسیید تا بتوانید در آینده از هر کدام از لایه ها یا اجزا بصورت جدا گانه استفاده کنید یا مثلا از کامپوننتهای آماده استفاده کنید
اما یکی از بزرگترین غفلت این روشها این است که یادشون رفته که عمر هر لایه یا جز نرم افزار به سخت افزار ها هم بستگی دارد اگر امروز جزیی از برنامه شما تحت ویندوز 98 کار می کند از کجا معلومه که تحت ویندوز اکس پی هم کار کند
بعنوان مثال : آیا می دانید دلیل شکست سفر سفینه فضایی آریان 5 چی بود.دلیل آن استفاده مجدد از سیستم آریان 4 بود ؟ مشکل اینجا بود که متغیر عددی از نوع 64 بیتی اضافه کردند که سبب خطای overflow
شد چرا که یادشون رفته بود که سیستم آریان 4 زمانی طراحی شده بود که سخت افزارها ضعیفتر بودن و این تغییر را پشتیبانی نمی کرد.
Software Craftsmanship, The New Imperative
Pete McBreen
Publisher: Addison Wesley
First Edition August 01, 2001
ISBN: 0-201-73386-2, 208 pages
کتاب بسیار جالبی است که در مورد مهندسی نرم افزار سخن می گوید البته مخاطبین کتاب برنامه نویسان نیستند بلکه این کتاب برای مدیران و تصمیم گیرندگان شرکتهای نرم افزاری نوشته شده است
این کتاب در مورد مهندسی نرم افزار و مدیریت پروژه های نرم افزاری دیگاه متفاوتی دارد
که شاید برای خیلی از ماها عجیب باشد بد نیست آن را برای شما نقل قول کنم امیدوارم مفید باشد
خلاصه ای از این کتاب را برای شما نقل می کنم
در این کتاب نویسنده عقیده دارد که روشهای مهندسی نرم افزار برای بسیاری از پروژه ها مناسب نیست و این روشها تنها در پروژه های نرم افزاری بزرگ کارایی دارد اما در پروژه های متوسط تجاری کارآمد نیست. به چند دلیل :
1- روشهای مهندسی نر م افزار بسیار شبیه به روشهای مهندسی معماری و مکانیک است و این برای رشته ای که مهمترین عنصر ان نیروی انسانی و عنصر تفکر و ذهن است اصلا مناسب نیست
به عنوان مثال در مهندسی مکانیک می خواهند یک ماشین بسازند . ابتدا طراحی و تجزیه و تحلیل می کنند نیازمندیها را تشخیص می دهند هزینه ها را محاسبه می کنند چندین بار تست می کنند و زمان تولید را براورد می کنند و در نهایت با بودجه ای مشخص این ماشین تولید می شود .اما در مهندسی نرم افزار تمام این پروسه بالا طی می شود اما خروجی ان تنها یک نسخه از نرم افزار است که ممکن است نسخه نهایی نباشد و شاید مود پسند کاربر نهایی قرار نگیرد چرا که فرایند تحویل نرم افزار بسیار متفاوتتر از فرایند ماشین است .
همچنین در فرایند تولید نرم افزار سخت افزارها مهم نیستند بلکه نیروی انسانی و کیفیت این نیرو اهمیت دارد
اگر شما برنامه نویس حرفه ای داشته باشید خیلی راحت می تواند این فرایند را برای شما انجام دهد در حالی که ممکن است یک تیم نرم افزاری متوسط از انجام آن حتی در صورت استفاده از مهندسی نرم افزار عاجز باشد .
مثلا : اگر 2 نفر برای حفاری کردن زمینی به 2 روز زمان نیاز دارند حال اگر بخواهیم این کار را یک روزه انجام دهیم به چند نفر نیاز داریم . جواب 4 نفر است. اما این جواب ممکنه درست نباشد چراکه ممکن است بدلیل برخی محدودیتها 4 نفر نتوانند با هم کار کنند لذا جواب ما منتفی می شود.
2-روشهای مهندسی نرم افزار فرایندی برای بررسی میزان تخصص برنامه نویسان ندارد.بلکه تنها اقدا م به تقسیم وظایف می کند . در حالی که برنامه نویس حرفه ای مهمترین عنصر این فرایند باید باشد.
مثلا در اماری که در آمریکا جمع آوری شده بیش از دو سوم پروژه های نرم افزاری توسط مدیریت برنامه نویسان حرفه ای به سرانجام می رسد نه توسط روشهای مهندسی نرم افزار .
3- روشهای مهندسی نرم افزار پیشنهاد می کند که قبل از شروع نرم افزار طرحهایی را بر روی کاغذ داشته باشند در حالی که بیشتر برنامه نویسان حرفه ای حوصله اینکار را ندارند و سریعا سراغ کد نویسی می روند چرا که اینکار را مفید تر می دانند و سریعتر می توانند ایده های نرم افزار ی خود را به کاربر انتقال دهند چرا که بسیاری از سفارش دهندگان نرم افزار از طرحهای کاغذی چیزی نمی دانند.
4- روشهای مهندسی نرم افزار نقش تحلیلگر , برنامه نویس , تست کننده , مستند نویس , و غیره را از هم تفکیک می کند . و دلیل این کار را تخصص هر فرد می داند
اما در صنعت نرم افزار می بینیم بهترین کسی که می تواند نرم افزار را پشتیبانی کند که این نرم افزار را نوشته است و آن را تحلیل کرده است چرا که در جریان کل پروژه بوده است
در روشهای نرم افزاری چون هر کس جدا گانه برای ان نقش تعیین شده جوابگو نیست در حالی که ما اگر به پروژه های سورس باز نگاه کنیم می بینیم که اکثر این پروژه ها توسط چندنفر نوشته شده اند که همه در تمام مراحل حضور دارند در نتیجه وقتی اولین نسخه از نرم افزار حاضر می شود بدلیل مشارکت چند نفر در تمام مراحل خروجی خیلی بهتری داره و بیشتر مورد استقبال واقع می شود علاوه بر آن چون چند نفر در تمام مراحل حضور داشتن پس پشتیبانی هم توسط تمام افراد انجام می شود
در حالی که در روشهای مهندسی نرم افزار پشتیبانی توسط گروه دیگری انجام می شود که در فرایند تولید نرم افزار حضور نداشتن به همین دلیل نمی توانند خوب پشتیبانی کنند
حال در پروژه ای سورس باز بدلیل حضور چند نفر در کل فرایند همگی به پروژه تسلط دارند و اگر یکی از عناصر از پروژه خارج شد باعث توقف کار نمی شوند اما در روشهای مهندسی نرم افزار بدلیل تقسیم کار بین چند نفر منفصل اگر یکی از پروژه خارج شد ممکن است باعث به هم خوردن کار شود
سناریوی آخر ایجاد تغیرات در نرم افزار
در روشهای مهندسی نرم افزار برای انجام تغییری یا اصلاح فرایندی باید کل مستندات و نقشه های تجزیه و تحلیل برنامه را مجددا اصلاح کنیم و همچنین سورس نرم افزار را اصلاح کنیم در این حالت کد نویس باید همه چیز را مطالعه کند و سورس موجود را بفهمد (چون مکن است کد نویس قبلی رفته باشد و فرد دیگری جایگزین آن شده باشد) تا بتواند تغییرات جدید را در سورس اعمال کند که در صد خطا بسیار بالاست
اما در پروژهای سورس باز گروهی بدلیل اینکه چند نفر در انجام پروژه دخیل بوده اند انجام تغییرات بسیار ساده تر است
5- 5- در روشهای مهندسی نرم افزار ادعا می شود که نرم افزار را بصورت لایه ای یا اجزای جدا از هم بنویسیید تا بتوانید در آینده از هر کدام از لایه ها یا اجزا بصورت جدا گانه استفاده کنید یا مثلا از کامپوننتهای آماده استفاده کنید
اما یکی از بزرگترین غفلت این روشها این است که یادشون رفته که عمر هر لایه یا جز نرم افزار به سخت افزار ها هم بستگی دارد اگر امروز جزیی از برنامه شما تحت ویندوز 98 کار می کند از کجا معلومه که تحت ویندوز اکس پی هم کار کند
بعنوان مثال : آیا می دانید دلیل شکست سفر سفینه فضایی آریان 5 چی بود.دلیل آن استفاده مجدد از سیستم آریان 4 بود ؟ مشکل اینجا بود که متغیر عددی از نوع 64 بیتی اضافه کردند که سبب خطای overflow
شد چرا که یادشون رفته بود که سیستم آریان 4 زمانی طراحی شده بود که سخت افزارها ضعیفتر بودن و این تغییر را پشتیبانی نمی کرد.