برای درک ضرورت مهندسی نرم افزار، باید به طور خلاصه به تاریخ اخیر محاسبات نگاه کنیم. این تاریخچه به ما کمک می کند تا مشکلاتی را که در اواخر دهه شصت و اوایل دهه هفتاد آشکار شد و راه حل هایی که منجر به ایجاد رشته مهندسی نرم افزار شده است را درک کنیم. برخی از این مشکلات به عنوان “بحران نرم افزاری” نامیده می شوند که به دلیل علائم این مشکل نامگذاری شده است. این وضعیت ممکن است “موانع پیچیدگی” نیز نامیده شود، که به دلیل اصلی مشکلات نامگذاری شده است. برخی به بحران نرم افزاری در زمان گذشته اشاره می کنند. بحران هنوز به پایان نرسیده است، اما به لطف توسعه بسیاری از تکنیک‌های جدید که اکنون تحت عنوان مهندسی نرم‌افزار گنجانده شده‌اند، ما پیشرفت کرده‌ایم و به پیشرفت خود ادامه می‌دهیم.
در روزهای اولیه محاسبات، نگرانی اصلی ساخت یا دستیابی به سخت افزار بود. تقریباً انتظار می رفت که نرم افزار از خودش مراقبت کند. اجماع بر این باور بود که تغییر «سخت‌افزار» «سخت» است، در حالی که «نرم‌افزار» «نرم» یا تغییر آسان است. طبق گفته‌ها، بیشتر افراد در صنعت توسعه سخت‌افزار را با دقت برنامه‌ریزی کردند، اما به میزان قابل توجهی کمتر به نرم‌افزار فکر کردند. آنها معتقد بودند که اگر نرم افزار کار نمی کرد، تغییر آن تا زمانی که کار نمی کرد به اندازه کافی آسان بود. در این صورت، چرا برای برنامه ریزی تلاش می کنید؟
هزینه‌های نرم‌افزار به قدری جزئی از هزینه سخت‌افزار بود که هیچ‌کس مدیریت توسعه آن را بسیار مهم نمی‌دانست. با این حال، همه اهمیت تولید برنامه‌هایی را دیدند که کارآمد و سریع اجرا شوند، زیرا این امر باعث صرفه‌جویی در زمان سخت‌افزار گران قیمت می‌شود. زمان مردم برای صرفه جویی در زمان ماشین در نظر گرفته شد. کارآمد کردن فرآیند مردم از اولویت کمی برخوردار بود.
این رویکرد در روزهای اولیه محاسبات، زمانی که نرم افزار ساده بود، رضایت بخش بود. با این حال، وقتی محاسبات به بلوغ رسید، برنامه‌ها پیچیده‌تر شدند و پروژه‌ها بزرگتر شدند، در حالی که برنامه‌ها از آن زمان به طور معمول توسط یک فرد مشخص، نوشته، اجرا و نگهداری می‌شدند، برنامه‌ها توسط تیم‌هایی از برنامه‌نویسان شروع به توسعه کردند تا انتظارات دیگران را برآورده کنند.
تلاش فردی جای خود را به تلاش تیمی داد. ارتباط و هماهنگی که زمانی در سر یک فرد انجام می‌شد، باید بین سر بسیاری از افراد اتفاق می‌افتاد و کل فرآیند را بسیار پیچیده‌تر می‌کرد. در نتیجه ارتباطات، مدیریت، برنامه ریزی و مستندسازی حیاتی شد.
این قیاس را در نظر بگیرید: یک نجار ممکن است به تنهایی کار کند تا یک خانه ساده برای خود بسازد، بدون اینکه بیش از یک مفهوم کلی از یک نقشه باشد. او می تواند با پیشرفت کار، مسائل را حل کند یا تنظیماتی را انجام دهد. برنامه های اولیه اینگونه نوشته می شد. اما اگر خانه پیچیده‌تر باشد، یا اگر برای شخص دیگری ساخته شده باشد، نجار باید با دقت بیشتری برنامه‌ریزی کند که چگونه خانه باید ساخته شود. قبل از شروع ساخت و ساز باید نقشه ها با مالک آینده بررسی شود. و اگر قرار است خانه توسط بسیاری از نجارها ساخته شود، مطمئناً کل پروژه باید قبل از شروع کار برنامه ریزی شود تا همانطور که یک نجار بخشی از خانه را می سازد، دیگری طرف دیگر خانه دیگری را نمی سازد. برنامه ریزی به یک عنصر کلیدی تبدیل می شود به طوری که پیمانکاران سیمان دیوارهای زیرزمین را قبل از اینکه نجارها شروع به قاب بندی کنند می ریزند. همانطور که خانه پیچیده تر می شود و کار افراد بیشتری باید هماهنگ شود، نقشه ها و برنامه های مدیریتی مورد نیاز است.
با پیچیده‌تر شدن برنامه‌ها، روش‌های اولیه مورد استفاده برای ساختن نقشه‌ها (نمونه‌های جریان) دیگر برای نشان دادن این پیچیدگی بیشتر رضایت‌بخش نبودند. و به این ترتیب برای شخصی که به برنامه ای نوشته شده نیاز داشت تا آنچه را که می خواستند به شخص دیگر، یعنی برنامه نویس منتقل کند، یا برای برنامه نویسان برای انتقال آنچه که انجام می دادند به یکدیگر دشوار شد. در واقع، بدون روش‌های بهتر بازنمایی، پیگیری کارهایی که انجام می‌دهد حتی برای یک برنامه‌نویس دشوار شد.
زمان های مورد نیاز برای نوشتن برنامه ها و هزینه های آنها از همه تخمین ها فراتر رفت. برای سیستم‌ها غیرعادی نبود که بیش از دو برابر برآورد شده هزینه داشته باشند و هفته‌ها، ماه‌ها یا سال‌ها بیشتر از آنچه انتظار می‌رفت طول بکشد. سیستم‌هایی که به مشتری تحویل داده می‌شوند، اغلب به درستی کار نمی‌کنند، زیرا پول یا زمان قبل از اینکه برنامه‌ها طبق برنامه‌ریزی اولیه کار کنند تمام شده بود. یا برنامه به قدری پیچیده بود که هر تلاشی برای رفع یک مشکل بیشتر از رفع مشکل، مشکلاتی را ایجاد می کرد. هنگامی که مشتریان سرانجام آنچه را که به دست می آورند دیدند، اغلب نظر خود را در مورد آنچه می خواهند تغییر دادند. حداقل یک پروژه سیستم‌های نرم‌افزاری نظامی بسیار بزرگ با هزینه چند صد میلیون دلاری رها شد زیرا هرگز نمی‌توانست به درستی کار کند.
کیفیت برنامه ها نیز به یک دغدغه بزرگ تبدیل شد. از آنجایی که رایانه ها و برنامه های آنها برای کارهای حیاتی تر مانند نظارت بر تجهیزات پشتیبانی زندگی استفاده می شد، کیفیت برنامه معنای جدیدی پیدا کرد. از آنجایی که ما وابستگی خود را به رایانه افزایش داده بودیم و در بسیاری موارد دیگر نمی توانستیم بدون آنها کنار بیاییم، متوجه شدیم که چقدر مهم است که آنها به درستی کار کنند.
ایجاد تغییر در یک برنامه پیچیده بسیار گران تمام شد. اغلب حتی واداشتن برنامه به انجام کاری کمی متفاوت به قدری سخت بود که حذف برنامه قدیمی و شروع دوباره آسانتر بود. این البته هزینه بر بود. بخشی از تحول در رویکرد مهندسی نرم‌افزار یادگیری توسعه سیستم‌هایی بود که در اولین بار به اندازه کافی خوب ساخته می‌شدند تا بتوان تغییرات ساده را به راحتی ایجاد کرد.
در همان زمان، سخت‌افزار کم‌هزینه‌تر رشد می‌کرد. لوله ها با ترانزیستورها و ترانزیستورها با مدارهای مجتمع جایگزین شدند تا اینکه میکرو کامپیوترهای کمتر از سه هزار دلار به چندین میلیون دلار تبدیل شدند. به عنوان نشانه ای از سرعت رخ دادن تغییرات، هزینه مقدار معینی از محاسبات هر دو سال یک نصف کاهش می یابد. با توجه به این تغییر، زمان ها و هزینه های توسعه نرم افزار در مقایسه با سخت افزار دیگر آنقدر کم نبود که بتوان آنها را نادیده گرفت.
با کاهش شدید هزینه‌های سخت‌افزار، نرم‌افزار همچنان توسط انسان‌هایی نوشته می‌شد که دستمزدشان در حال افزایش بود. صرفه جویی حاصل از بهبود بهره وری در توسعه نرم افزار ناشی از استفاده از اسمبلرها، کامپایلرها و سیستم های مدیریت پایگاه داده به سرعت صرفه جویی در هزینه های سخت افزاری انجام نشد. در واقع، امروزه هزینه های نرم افزاری نه تنها دیگر قابل چشم پوشی نیستند، بلکه از هزینه های سخت افزاری نیز بزرگتر شده اند. برخی از پیشرفت‌های کنونی، مانند زبان‌های غیر رویه‌ای (نسل چهارم) و استفاده از هوش مصنوعی (نسل پنجم)، نویدبخش افزایش بهره‌وری توسعه نرم‌افزار است، اما ما تازه در حال مشاهده پتانسیل آنها هستیم.
مشکل دیگر این بود که در گذشته برنامه ها اغلب قبل از اینکه به طور کامل درک شود که برنامه چه کاری باید انجام دهد بود. هنگامی که برنامه نوشته شد، مشتری شروع به ابراز نارضایتی کرد. و اگر مشتری ناراضی باشد، در نهایت تولیدکننده نیز ناراضی بوده است. با گذشت زمان، توسعه‌دهندگان نرم‌افزار یاد گرفتند که دقیقاً آنچه را که قصد داشتند قبل از شروع کار انجام دهند، با کاغذ و مداد ترسیم کنند. سپس آنها می توانند برنامه ها را با مشتری بررسی کنند تا ببینند آیا آنها انتظارات مشتری را برآورده می کنند یا خیر. ایجاد تغییرات در این نسخه کاغذی و مدادی ساده تر و کم هزینه تر از ایجاد آنها پس از ساخت سیستم است. استفاده از برنامه‌ریزی خوب باعث می‌شود که پس از اتمام برنامه، تغییراتی کمتر انجام شود.
متأسفانه، تا چندین سال پیش، هیچ روش نمایش خوبی برای توصیف رضایت بخش سیستم هایی به پیچیدگی سیستم هایی که امروزه در حال توسعه هستند، وجود نداشت. تنها نمایانگر خوب ظاهر محصول، خود محصول نهایی بود. توسعه‌دهندگان نمی‌توانستند به مشتریان برنامه‌ریزی خود را نشان دهند. و کلاینت‌ها نمی‌توانستند ببینند که آیا نرم‌افزار همان چیزی است که می‌خواهند تا زمانی که در نهایت ساخته شد. سپس برای تغییر آن بسیار گران بود.
مجدداً قیاس ساخت و ساز ساختمان را در نظر بگیرید. یک معمار می تواند یک پلان طبقه را ترسیم کند. مشتری معمولاً می تواند درک درستی از آنچه معمار برنامه ریزی کرده است به دست آورد و در مورد مناسب بودن آن بازخورد بدهد. درک پلان های طبقه برای افراد غیرمجاز به راحتی آسان است زیرا اکثر مردم با نقشه هایی که اشیاء هندسی را نشان می دهند آشنا هستند. معمار و مشتری مفاهیم مشترکی در مورد فضا و هندسه دارند. اما مهندس نرم افزار باید سیستمی را برای مشتری ارائه دهد که شامل منطق و پردازش اطلاعات است. از آنجایی که آنها قبلاً زبانی از مفاهیم مشترک ندارند، مهندس نرم افزار باید قبل از برقراری ارتباط، زبان جدیدی را به مشتری آموزش دهد.
علاوه بر این، مهم است که این زبان ساده باشد تا بتوان آن را به سرعت یاد گرفت.
