روش رایج در همهٔ رشته‌های مهندسی این است که ابتدا محصول نهایی را «طراحی» می‌کنند و بعد از اینکه از صحت طراحی مطمئن شدند، پیاده‌سازی را انجام می‌دهند. به این روش Big Design Up Front (طراحی بزرگ در ابتدا) یا BDUF نیز می‌گویند. اگر غیر از این انجام شود، همگان - از مهندسان برق و عمران گرفته تا مهندسان نفت و پتروشیمی - توافق دارند که کار غیرحرفه‌ای و کم‌کیفیت انجام شده است. به همین دلیل در مهندسی نرم‌افزار سنتی هم فرض بر همین بوده: فقط وقتی کُدنویسی را باید شروع کرد که طراحی کاملاً انجام شده باشد.
اما تجربهٔ واقعی مهندسان نرم‌افزار چه بوده؟ آن‌ها مشاهده کرده‌اند که:
- نهایی کردن طراحی بسیار سخت است: چون نیازهای مشتری - همان‌طور که در مطلب قبلی گفتیم - در طول توسعه و نگهداری محصول مرتب عوض می‌شوند و گسترش می‌یابند، باید طراحی نیز مرتباً تغییر کند.
- محدودیت‌های جدیدی - که در زمان طراحی مشخص و واضح نبوده‌اند - در هنگام پیاده‌سازی یا نگهداری کشف می‌شوند که به خاطر آن‌ها طراحی باید تغییر کند، یا اینکه قابلیت‌های جدیدی در تکنولوژی پیاده‌سازی پیدا می‌شود که قبلاً طراحان از آن اطلاعی نداشته‌اند و در نتیجه طراحی‌شان بهینه نیست. مثلاً مشخص می‌شود که یک مؤلفهٔ آمادهٔ مورد استفاده، تحت بار زیاد دچار مشکلاتی در کارایی و پایداری می‌شود. یا اینکه یک کتابخانهٔ متن‌باز پیدا می‌شود که نیاز به توسعهٔ بخشی از سیستم را مرتفع می‌کند.
- و مهم‌تر از همه، در اکثر پروژه‌ها بعداً کشف می‌شود که طراحی، علی‌رغم وقت و انرژی زیادی که صرف آن شده بوده است، آنقدرها هم مناسب و بی‌نقص نبوده است: خیلی از نیازهای مشتری را نمی‌تواند پشتیبانی کند و در برخی قسمت‌ها هم بیش از حد پیچیده - و پرهزینه در پیاده‌سازی - شده است. مثلاً نیاز جدیدی پیش می‌آید که نیاز به تغییرات بزرگ در طراحی دارد. یا بالعکس، برخی از نیازها که در طراحی دیده شده بود، هیچ وقت پیش نمی‌آیند و فقط پیچیدگی طراحی برای ما می‌ماند!
به عبارت دیگر، بدون پیاده‌سازی و حتی تحویل نرم‌افزار نهایی به مشتری به طوری که در شرایط واقعی استفاده شود، نمی‌توان از مطلوب بودن طراحی مطمئن شد. البته راه‌هایی برای ارزیابی طراحی پیش از پیاده‌سازی و زیر بار رفتن نرم‌افزار وجود دارد، ولی در نهایت نمی‌توان صددرصد مطمئن شد، به‌خصوص که معمولاً مشکل در جایی به وجود می‌آید که پیش‌بینی نشده است.
طراحی تدریجی
بنابراین رویکرد نوین نسبت به طراحی نرم‌افزار این است که طراحی را کم‌کم انجام دهیم و هر بار با پیاده‌سازی و آزمون و ترجیحاً تحویل به مشتری و رفتن نرم‌افزار زیر بار، از خوب بودنش مطمئن شویم. منظور از «کم‌کم» این است که هر بار، طراحی را با توجه به بخش کوچکی از نیازمندی‌های مشتری تغییر دهیم طوری که این نیازمندی‌ها + نیازمندی‌های قبلاً محقق شده، برآورده شوند.
اما آیا چنین رویکردی در عمل ممکن است؟ لااقل اکثر ما مهندسان نرم‌افزار که به این روش عادت نداریم! اکثر ما دوست داریم یک طراحی را ابتدا نهایی کنیم و بعد پیاده‌سازی کنیم. یا اینکه حداقل قبل از شروع به کُد زدن، معماری کلان را نهایی کنیم. بعد از شروع برنامه‌نویسی، تغییر طراحی ریسک دارد، ممکن است باعث باگ یا خرابی در خیلی جاهای سیستم شود و خیلی هم وقت می‌بَرَد، مگر نه؟ در این باره در مطالب بعدی بیشتر خواهیم نوشت.