بریده‌هایی از کتاب راز پروژه‌های نرم‌افزاری (تحلیل چرایی شکست پروژه‌ها)

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

مشکل اینجا نیست که کاربران نمی‌دانند چه می‌خواهند، بلکه مشکل این است که آن‌ها، حداقل تا زمانی که بخشی از پروژه تکمیل‌نشده باشد، قادر نیستند آن به‌طور کامل تصور کنند.

مدیران معمولاً از توسعه‌دهندگان می‌پرسند که دقیقاً چقدر طول می‌کشد تا یک خطا و یا همه خطاهای موجود در یک نرم‌افزار، برطرف شود. هر پاسخی که توسعه‌دهنده به این سؤال بدهد، چیزی بیشتر از یک حدس نیست. برطرف کردن یک خطا ممکن است چند دقیقه و یا چند هفته به طول بیانجامد.

این موضوع به‌خصوص برای چارچوب‌های کاربردی شرکت درست است، مجموعه ابزاری که جهت ساخت سیستم‌های نرم‌افزاری مدرن مورداستفاده قرار می‌گیرند. در طی چند سال گذشته، حرکتی از فناوری‌های اختصاصی و در جهت استانداردهای مشترک صورت گرفته است. در حال حاضر تنها دو چارچوب اصلی کاربردی سازمانی وجود دارد: نسخه سازمانی جاوا ۲ از Sun، IBM، BEA و.NET مایکروسافت. اما نوشتن کد به‌صورت C# برای.NET تا حدودی متفاوت از نوشتن کد در جاوا برای J۲EE است. دو فناوری از مفاهیم یکسان استفاده می‌نمایند و دارای شباهت‌های بیشتری هستند. استفاده از مهارت‌ها از یک تیم به دیگری آسان است.