رهیافتی به انتخاب متدولوژی (۱)

مقدمه

    یکی از زمینه های مورد علاقه من مهندسی نرم افزار است. سعی می کنم در چند پست آینده مطالبی را در زمینه انتخاب متدولوژی بنویسم. این مطالب عموما برگرفته از نوشته های صاحبنظران متدولوژی به ویژه مارتین فولر است.

چرا متدولوژی؟

    در ابتدا که یک برنامه نویس شروع به کار می کند، کارهای خود را به صورت "کد زدن و رفع اشکال"  انجام می دهد. بالتبع تولید نرم افزار یا محصول با برنامه ریزی ناچیزی انجام می شود.  این روش برای سیستم های کوچک خوب جواب می دهد. ولی با بزرگ شدن سیستم مشکلات زیادی ایجاد می شود. اضافه کردن ویژگی جدید به سیستم و رفع اشکال بسیار سخت تر می شود.  از نشانه های این سیستم طولانی شدن فاز تست بعد از پیاده سازی کل سیستم است. در یک چنین سیستمی زمانبندی برای فاز تست تقریبا غیر ممکن می شود.

    برای رفع مشکل بی برنامه گی  ابتدا سعی شد که رهیافت مهندسی در سایر رشته های مهندسی را برای توسعه نرم افزار به کار گرفته شود. مشکل جدی این روش ها بروتراتیک بودن زیاد آنهاست. در پاسخ به این بروکراسی روش های چابک پیشنهاد شدند که در فضایی میان بدون فرایند بودن یا فرایند زیاد داشتن قرار می گیرند. این دو روش دو تفاوت عمده دارند:

روشهای چابک بیشتر تطبیق پذیرند تا پیش بینی کننده: روشهای مهندسی سعی می کنند تا قسمت بزرگی از فرایند نرم افزار را با جزییات زیاد در یک زمان طولانی بیان کنند. طبیعتا این روش ها در مقابل تغییرات مقاومت می کنند. در حالیکه فرایندهای چابک سعی می کنند که خود را با تغییرات وفق دهند.
روش های چابک بیشتر مبتنی بر افرادند تا مبتنی بر فرایند: روشهای مهندسی در صددند که فرایندی را تعریف کنند که با هر کسی که اجرا شود موفق باشند. در حالیکه هدف روشهای چابک کمک به تیم موجود است[۱].

روشهای پیش بینی کننده یا روشهای تطبیق پذیر

    متدولوژی های مهندسی از رشته های مهندسی مثل عمران یا مکانیک الهام گرفته شده است. در نتیجه بیشتر این متدولوژیها بر این اصل استوار است که فاز طراحی قبل از فاز ساخت انجام شود. با توجه با این اصل سعی می کنند که در فاز طراحی قسمت های مختلف سیستم را با جزییات کافی طراحی کنند. از نتایج این طراحی دقیق و با جزییات، برای اجرای طرح نیازی به افراد خبره و ماهر نیست. نتیجه دیگر این است که با توجه به طرح دقیق به راحتی می توان زمانبندی نسبتا دقیقی داد. در نتیجه در اینجا دو کار اساسی و از هم جدا وجود دارد: مرحله طراحی که به سختی قابل پیش بینی است و نیاز به افراد خبره و با تجربه دارد و مرحله ساخت یا پیاده سازی که به سادگی قابل پیش بینی بوده و نیازی به افراد خبره ندارد.

    حال برای اینکه طراحی از پیاده سازی جدا شود باید بتوان دید تا چه حد می توان به طراحی اعتماد کرد؟ به عبارت دیگر آیا طراحی قادر خواهد بود که فاز پیاده سازی را به یک فعالیت ساخت قابل پیش بینی تبدیل کند؟

    متداول ترین ابزار برای طراحی های نرم افزاری UML است. اگرچه طراحی هایی که با این روش انجام می شود ممکن است که  بر روی کاغذ شاید خیلی  مناسب به نظر برسند ولی وقتی می خواهند به کد تبدیل شوند معمولا مشکلات زیادی از خود بروز می دهند. در رشته های مهندسی مثل عمران، از مدلهایی استفاده می کنند که اولا بر روی مدل و مساله مشابه سالیان کار شده است. ثانیا طراحی را با تحلیل ریاضی تایید می کنند. ولی در مورد سیستم های کامپیوتری این تایید صرفا بر اساس مروری است که یک فرد با تجربه انجام می دهد. تجربه نشان داده است که حتی طراحان بسیار حرفه ای هم با مشکلاتی طراحی آنان در عمل پیدا می کند  شگفت زده می شوند[۱].  

نکته دیگر مقایسه نسبت هزینه طراحی به پیاده سازی پروژه با سایر رشته های مهندسی است. به عنوان مثال وقتی یک پل ساخته می شود، هزینه طراحی شاید حدو د۱۰ درصد هزینه کل باشد. ولی در سیستم های نرم افزاری همانطور که در [۲] نشان داده، حدود ۱۵ درصد  از هزینه های کل پروژه مربوط به کد و تست ها می شود. حتی اگر تمامی مرحله تست شامل تست جامعیت و استرس و کارایی و … را بخشی از ساخت پروژه بدانیم، هنوز ۵۰ درصد از هزینه پروژه صرف طراحی می شود.

این تفاوت اساسی منجر به این شد که عده ای پیشنهاد دهند[۳] که کدها هم قسمتی از مستندات فاز طراحی هستند و فاز ساخت تنها کامپایل کردن و لینک کردن کدهاست.

منابع:

[1] Martin Fowler, The New Methodology, http://martinfowler.com/articles/newMethodology.html#AgileManifesto

[2] Steve McConnell, Development: Taming Wild Software Schedules, ISBN 1556159005

[3] Alistair Cockburn, Characterizing People as Non-Linear, First-Order Components in Software Development,  4th International Multi-Conference on Systems, Cybernetics and Informatics, Orlando, Florida, June, 2000.