قسمت دوم
تیم نرم افزاری در صنعت نرم افزار
1- نویسنده اعتقاد دارد که بزرگترین پروژه نرم افزاری در صنعت نمی تواند بیش از 20 سال زمان ببرد
2- برخی از پروژه های نرم افزاری را نمی توان بر اساس روشهای مهندسی نرم افزار بصورت تدریجی تکامل و تحویل داد چرا که هر گز خطا پذیر نیستن مانند نرم افزار های مورد استفاده در صنعت فضا و هواپیمایی پس روشهای مهندسی نرم افزار فقط برای پروژ ه های تجاری کارایی دارد
3- پروژه هایی که برای سخت افزارها نوشته می شوند مانند درایورها ؛ جدا کردن فاز تجزیه و تحلیل و کد نویسی منطقی است چرا که برنامه نویس باید منتظر باشد تا سخت افزار آماده شود
صنعت نرم افزار بسیار شبیه به صنعت نجاری و آهنگری است
چرا که این صنعتها به استاد ماهر و خلاق نیاز دارد و نرم افزار هم نیاز به برنامه نویس حرفه ای و خلاق نیاز دارد.
مهمترین روشی که نویسنده برای حرفه ای شدن به برنامه نویسان پیشنهاد می کند , شاگردی کردن نزد برنامه نویسان حرفه ای است چرا که آشنایی با زبانهای برنامه نویسی و متدهای مهندسی نرم افزار فقط ابزار کار هستند
و اما خصوصیات یک معلم برنامه نویسی حرفه ای
1- دایما در حال مطالعه و بروز رسانی اطلاعاتش باشد
2- از تکنولوژیهای پایدار و قابل استمرار استفاده می کند (در اینجا نویسنده تکنولوژیهای مایکروسافت و جاوا را پیشنهاد نمی کند چرا که همیشه در حال تغییر هستند و آنها را در مراحل بعدی آموزش قرار داده است)
3- دارای توانایی قوی و سریع در فراگیری تکنولوژیهای جدید چرا که اساس تمام آنها یکی است
چگونه معلم برنامه نویسی حرفه ای را تشخیص دهیم
معلم برنامه نویسی خوب کسی است که بتواند برنامه ای را بنویسد و ان را برای سالها پشتیبانی کند و ارتقا و توسعه دهد حداقل تجربه باید 15 سال باشد !!!!!!!!!!!!!
روش کار در تیم برنامه نویسی
تیم برنامه نویسی از معلم برنامه نویسی یا همان برنامه نویس ارشد و برنامه نویسان دیگر تشکیل می شود
به ترتیب زیر
1- برنامه نویس ارشد یا همان معلم
مسوول اول و آخر پروژه خواهد بود و با اعتبار فنی خودش کار می کند بطوری که وقتی کارفرما نام برنامه نویس ارشد را بشنود برای او موجب دلگرمی و اطمینان شود هر پروژه باید دارای تعداد کمی برنامه نویس ارشد باشد
2- برنامه نویسان متوسط
برنامه نویسان متوسط البته که دارای حداقل 5 سال به بالا , که به همراه برنامه نویس ارشد برنامه را تحلیل و کد نویسی می کنند
3- برنامه نویسان مبتدی که تازه آغاز به کار کرده اند که کارهای ساده تر را به آنها محول می کنییم و پله پله پیشرفت می کنند .
Software Craftsmanship, The New Imperative
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 زمانی طراحی شده بود که سخت افزارها ضعیفتر بودن و این تغییر را پشتیبانی نمی کرد.