Защо се нуждаем от софтуерно инженерство?

За да разберем необходимостта от софтуерно инженерство, трябва да спрем за кратко, за да погледнем назад към скорошната история на изчислителната техника. Тази история ще ни помогне да разберем проблемите, които започнаха да стават очевидни в края на шейсетте и началото на седемдесетте години, и решенията, довели до създаването на областта на софтуерното инженерство. Тези проблеми бяха посочени от някои като „Кризата на софтуера“, наречена така заради симптомите на проблема. Ситуацията може също да се нарече „Бариерата на сложността“, наречена така заради основната причина за проблемите. Някои говорят за софтуерната криза в минало време. Кризата далеч не е приключила, но благодарение на разработването на много нови техники, които сега са включени под заглавието софтуерно инженерство, ние постигнахме и продължаваме да постигаме напредък.

В ранните дни на компютрите основната грижа беше изграждането или придобиването на хардуера. От софтуера почти се очакваше да се оправя сам. Консенсусът гласи, че „хардуерът“ е „труден“ за промяна, докато „софтуерът“ е „мек“ или лесен за промяна. Според повечето хора в индустрията внимателно са планирали разработката на хардуер, но са обмисляли значително по-малко софтуера. Те вярваха, че ако софтуерът не работи, ще бъде достатъчно лесно да се промени, докато не заработи. В такъв случай, защо да правите усилия да планирате?

Цената на софтуера възлизаше на толкова малка част от цената на хардуера, че никой не смяташе за много важно да управлява неговото развитие. Всички обаче видяха важността на създаването на програми, които са ефективни и работят бързо, защото това спестява време за скъпия хардуер. Приема се, че времето на хората спестява машинно време. Правенето на ефективния процес на хората не получи голям приоритет.

Този подход се оказа задоволителен в ранните дни на компютрите, когато софтуерът беше прост. Въпреки това, тъй като компютрите узряваха, програмите ставаха по-сложни и проектите ставаха все по-големи, докато програмите оттогава бяха рутинно специфицирани, написани, работещи и поддържани от един и същ човек, програмите започнаха да се разработват от екипи от програмисти, за да отговорят на очакванията на някой друг.

Индивидуалните усилия отстъпиха място на екипните. Комуникацията и координацията, които някога се случваха в главата на един човек, трябваше да възникнат между главите на много хора, правейки целия процес много по-сложен. В резултат на това комуникацията, управлението, планирането и документацията станаха критични.

Помислете за тази аналогия: един дърводелец може да работи сам, за да построи проста къща за себе си без повече от обща концепция за план. Той или тя може да изработи нещата или да направи корекции, докато работата напредва. Така са написани ранните програми. Но ако домът е по-сложен или ако е построен за някой друг, дърводелецът трябва да планира по-внимателно как ще бъде построена къщата. Плановете трябва да бъдат прегледани с бъдещия собственик преди началото на строителството. И ако къщата трябва да бъде построена от много дърводелци, целият проект със сигурност трябва да бъде планиран преди началото на работата, така че докато един дърводелец изгражда една част от къщата, друг да не изгражда другата страна на друга къща. Графикът се превръща в ключов елемент, така че изпълнителите на цимент да излеят стените на мазето, преди дърводелците да започнат рамкирането. Тъй като къщата става по-сложна и работата на повече хора трябва да бъде координирана, са необходими чертежи и планове за управление.

Тъй като програмите ставаха по-сложни, ранните методи, използвани за създаване на чертежи (блок-схеми), вече не бяха задоволителни, за да представят тази по-голяма сложност. И така стана трудно за един човек, който се нуждаеше от програма, написана, за да предаде на друг човек, програмиста, точно това, което иска, или за програмистите да предадат един на друг какво правят. Всъщност без по-добри методи за представяне стана трудно дори за един програмист да следи какво прави.

Времето, необходимо за писане на програми и техните разходи, започнаха да надвишават всички оценки. Не беше необичайно системите да струват повече от два пъти над прогнозираните и да отнемат седмици, месеци или години повече от очакваното за завършване. Системите, предадени на клиента, често не работеха правилно, защото парите или времето бяха изтекли, преди програмите да могат да работят, както първоначално е предназначено. Или програмата е била толкова сложна, че всеки опит за отстраняване на проблем създава повече проблеми, отколкото коригира. Когато клиентите най-накрая видяха какво получават, те често промениха мнението си за това, което искат. Поне един много голям проект за военни софтуерни системи, струващ няколкостотин милиона долара, беше изоставен, защото никога не можеше да бъде накаран да работи правилно.

Качеството на програмите също стана голямо безпокойство. Тъй като компютрите и техните програми бяха използвани за по-важни задачи, като наблюдение на животоподдържащо оборудване, качеството на програмата придоби ново значение. Тъй като бяхме увеличили зависимостта си от компютрите и в много случаи вече не можехме да се справяме без тях, открихме колко важно е те да работят правилно.

Извършването на промяна в рамките на сложна програма се оказа много скъпо. Често дори да накарате програмата да направи нещо малко по-различно беше толкова трудно, че беше по-лесно да изхвърлите старата програма и да започнете отначало. Това, разбира се, струваше скъпо. Част от еволюцията в подхода на софтуерното инженерство беше да се научим да разработваме системи, които са изградени достатъчно добре от първия път, така че лесни промени да могат да се правят лесно.

В същото време хардуерът ставаше все по-евтин. Лампите бяха заменени от транзистори, а транзисторите бяха заменени от интегрални схеми, докато микрокомпютрите, струващи по-малко от три хиляди долара, станаха няколко милиона долара. Като индикация за това колко бързо е настъпила промяната, цената на дадено количество изчисления намалява наполовина на всеки две години. Като се има предвид това пренастройване, времето и разходите за разработване на софтуера вече не бяха толкова малки в сравнение с хардуера, че да могат да бъдат пренебрегнати.

Тъй като цената на хардуера падна рязко, софтуерът продължи да се пише от хора, чиито заплати нарастваха. Икономиите от подобрения на производителността при разработката на софтуер от използването на асемблери, компилатори и системи за управление на бази данни не се развиват толкова бързо, колкото спестяванията в разходите за хардуер. Наистина, днес разходите за софтуер не само вече не могат да бъдат пренебрегвани, те са станали по-големи от разходите за хардуер. Някои настоящи разработки, като непроцедурните (четвърто поколение) езици и използването на изкуствен интелект (пето поколение), показват обещание за увеличаване на производителността на разработката на софтуер, но ние едва започваме да виждаме техния потенциал.

Друг проблем беше, че в миналото програмите често бяха преди да се разбере напълно какво трябва да направи програмата. След като програмата беше написана, клиентът започна да изразява недоволство. И ако клиентът е недоволен, в крайна сметка и производителят е бил недоволен. С течение на времето разработчиците на софтуер се научиха да очертават с хартия и молив точно какво възнамеряват да направят, преди да започнат. След това те биха могли да прегледат плановете с клиента, за да видят дали отговарят на очакванията на клиента. По-лесно и по-евтино е да правите промени в тази версия на хартия и молив, отколкото да ги правите след като системата е била изградена. Използването на добро планиране намалява вероятността да се наложат промени, след като програмата приключи.

За съжаление, допреди няколко години не съществуваше добър метод за представяне, който да опише задоволително толкова сложни системи, колкото тези, които се разработват днес. Единственото добро представяне на това как ще изглежда продуктът беше самият завършен продукт. Разработчиците не можаха да покажат на клиентите какво планират. И клиентите не можеха да видят дали софтуерът е това, което искат, докато най-накрая не беше изграден. Тогава беше твърде скъпо за смяна.

Отново помислете за аналогията със строителството на сгради. Архитектът може да начертае етажен план. Клиентът обикновено може да разбере какво е планирал архитектът и да даде обратна информация дали е подходящо. Етажните планове са сравнително лесни за разбиране от неспециалистите, тъй като повечето хора са запознати с чертежите, представящи геометрични обекти. Архитектът и клиентът споделят общи концепции за пространството и геометрията. Но софтуерният инженер трябва да представлява за клиента система, включваща логика и обработка на информация. Тъй като те все още нямат език на общи концепции, софтуерният инженер трябва да научи нов език на клиента, преди да могат да общуват.

Освен това е важно този език да е прост, за да може да се научи бързо.

Empfohlene Artikel

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.