Защо софтуерното инженерство не е като другите инженерни дисциплини и как променя играта

Изчислено е, че към 2014 г. има над 11 милиона професионални софтуерни разработчици по целия свят. Когато започнах като програмист през 1973 г., един от сивобрадите в първата компания, в която работех, ми даде някои съвети. Той каза: „Научете нещата, които никога не се променят.“

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

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

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

По времето, когато настъпи 90-те, тъй като компютърното програмиране стана толкова голяма част от това, което се наричаше компютърни науки, много университети бяха добавили курс със заглавие „Софтуерно инженерство“ към учебната си програма по компютърни науки. Популярните учебници, използвани по това време за преподаване на тези курсове, включват учебника на Иън Сомървил, озаглавен: „Софтуерно инженерство“. От 1992 до 1994 г. използвах четвъртото издание на този учебник, за да преподавам софтуерно инженерство в университета Бингамтън. Днес учебникът на Иън Сомървил все още се използва в много университети по света – сега в своето девето издание. Това води до въпрос:

Защо трябва да преразглеждаме учебник приблизително на всеки 3-4 години, който уж преподава на нашите студенти основите на софтуерното инженерство?

Ако погледнете учебниците, използвани по гражданско инженерство, машиностроене и електротехника, по-голямата част от тези книги не изискват ревизии почти толкова често. За да разберем защо това е така, трябва да разгледаме по-отблизо какво се преподава в повечето университети по света под името „Софтуерно инженерство“.

Когато погледнете по-внимателно, ще откриете, че ние обучаваме нашето следващо поколение софтуерни професионалисти на това, което в момента е популярно по отношение на софтуерните практики и методи. Популярните софтуерни практики и методи днес са известни с модни думи като Agile, Use Cases, User Stories, RUP, XP, Scrum Lean, PSP, TSP и списъкът продължава и продължава…

Проблемът с този подход към преподаване на софтуерно инженерство е, че софтуерните практики и методи често идват и си отиват и ще продължат да идват и си отиват, поради което Сомървил трябва непрекъснато да актуализира своя учебник. Това води до друг въпрос:

Ами онзи сива брада в първата компания, в която работех през 1973 г., който ми каза да науча нещата, които никога не се променят? Лош съвет ли ми даде? Ако не, на какво учим нашето следващо поколение софтуерни професионалисти по отношение на нещата, които никога не се променят в софтуерното инженерство?

Преди да отговорим на тези въпроси, нека първо да се върнем назад и да зададем няколко различни въпроса:

Съществува ли набор от неща, които никога не се променят в софтуерното инженерство?

Ако съществуват, знаем ли какви са?

Ако знаем какви са те, преподаваме ли ги по последователен начин на нашето следващо поколение софтуерни професионалисти, така че когато излязат от университета, те са готови да се държат като софтуерни професионалисти?

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

Доброволците, участващи в тази инициатива (известни като SEMAT – Метод и теория на софтуерното инженерство), работят по тази задача от 2010 г. През изминалата година SEMAT постигна важен етап с обявяването от Object Management Group, международен консорциум за стандарти, че те са приели „Essence“ като официален OMG стандарт.

Така че това води до още няколко въпроса:

Колко различен е стандартът на Essence от това, което се преподава на нашите софтуерни разработчици днес и се преподава през последните 40 години под името Софтуерно инженерство?

И:

Дали разликите наистина ще помогнат за проблемите, които мнозина смятат, че все още тормозят софтуерната индустрия по отношение на общия бюджет, превишаването на графика и лошото качество на софтуера?

От една гледна точка това, което Essence улавя, не е ново. Стандартът Essence включва общи думи като заинтересовани страни, възможност, изисквания, софтуерна система, екип, работа и начин на работа. Но от друга гледна точка това, което Essence улавя, е драматично ново. Всъщност някои го наричат ​​“смяна на парадигмата“, която много от „старата гвардия“ ще имат големи трудности дори да разберат.

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

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

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

Но моят ръководител на проекта не искаше да обсъжда с клиента дали тези заявки са в обхвата или извън обхвата. Неговото виждане беше – както мнозина гледаха софтуера тогава и го гледат днес – че е по-лесно да смените софтуера, отколкото да ангажирате клиента в дискусия.

Тъй като софтуерът е мек, ние сме склонни да го разглеждаме като лесен за промяна. Не е като хардуер. Металът не се огъва лесно. Тази гледна точка променя цялата игра, когато става въпрос за софтуер.

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

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

Когато промените кода, вие може също да повлияете на изискванията, както и да засегнете други възможности в софтуерната система, тествана преди това. Промяната на кода означава допълнителна работа, допълнително тестване, евентуални промени в поддържащите потребителски ръководства и т.н…. Всичко това се отразява на бюджета и графика и внася допълнителен риск за качеството на софтуера.

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

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

Малко след началото на инициативата SEMAT през март 2010 г., един от първоначалните подписалите SEMAT ми изпрати черновик на книга, върху която работеше да прегледа. Уотс Хъмфри, който планираше да бъде много активен в ранната работа на SEMAT, се разболя точно когато работата по SEMAT се подготвяше и бях помолен да му помогна да осъществи планираните си усилия. В края на август същата година Уотс ми изпрати следния имейл само няколко месеца преди смъртта му. Той се съгласи, че мога да споделя този имейл с други:

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

Когато го направят, техните възпитаници ще могат да преговарят с ръководството си и да вършат превъзходна работа…. Това трябва да правят професионалистите… Добро начало в тази посока би било да ги убедим в необходимостта да имат хора със софтуер измерват собствената си работа. Тъй като работата със софтуера, както казахме, е работа на знания, всички наистина точни мерки трябва да бъдат взети от самите софтуерни специалисти. …Уотс Хъмфри

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

Днес Уотс щеше да бъде окуражен от работата на SEMAT, която се извършва в академичната общност. Първият пълен университетски курс, базиран на новия стандарт Essence, е разработен и се предоставя на студентите тази година от д-р Карлос Сапата в Universidad Nacional de Columbia в Меделин, Колумбия, а Essence се използва през първата и втората година курсове по софтуерно инженерство в KTH Royal Institute of Technology в Швеция под ръководството на д-р Мира Кайко-Матсън. Има и теренни проучвания на Essence, проведени със студенти от д-р Сесил Перер в Carnegie-Mellon West в Съединените щати. Следващата стъпка за общността на SEMAT е да демонстрира как Essence може да помогне в индустрията, като публикува казуси за действителна употреба и измерени резултати по индустриални проекти.

Empfohlene Artikel

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert