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

Какво е това?

Да започнем с дефиницията. Методологията за разработване на софтуер е набор от принципи, система от идеи, концепции, методи, методи и инструменти, които в крайна сметка определят стила на разработка на софтуер. С други думи, методологията тук е прилагането на конкретен стандарт. Какво е важно да се отбележи, стандартите тук са препоръчителни, а не подредени, както би трябвало да бъде. Следователно, пред създателя се запазва свободата на избор, адаптацията на теорията. Специфичните продукти се реализират чрез методологията за разработване на софтуер. Тя ще определи как специалистът ще изпълнява работата си. Днес има много такива методики - основните, които ще разгледаме в хода на материала. Какво влияе върху избора им единствено? Разграничават се големината на екипа, сложността и спецификата на даден проект, зрелостта и стабилността на процесите в компанията-работодател, личните предпочитания на създателя.


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

Методология на прогнозата

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


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

Адаптивни методологии

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

Гъвкави методологии

Гъвкави методологии за разработване на софтуер - английски език. Разработване на гъвкав софтуер. Оттук и второто име: гъвкави методи. Гъвкавите методологии за разработка на софтуер сакомплекс от подходи за разработване на софтуер, фокусиран върху използването на итеративното развитие, динамичното формиране на изискванията към проекта, осигуряване на осъществяването на края на непрекъснатото взаимодействие в работните самоорганизирани групи, съставени от специалисти от различни профили.
На първо място, това е ефективна практика на работата на малките екипи, занимаващи се с един и същ вид творчество. В комбинация с комбиниран (демократичен и либерален) метод на управление. Гъвкавите методологии за разработване на софтуер са насочени към минимизиране на рисковете чрез привеждане на съвместен проект в комплекс от кратки цикли (т.нар. Итерации), всеки от които трае 2-3 седмици. Итерацията тук е малък програмен проект, който включва всички задачи за осигуряване на функционален мини растеж. Като такива: планиране, анализ на изискванията, проектиране, програмиране, тестване на разработки, документация. Разбира се, отделна итерация тук не е достатъчна за освобождаване на крайния продукт. Ето и друго значение. До края на всяка итерация е готов гъвкав софтуер. Също така, в края на периода, екипът трябва да извърши преоценка на приоритетите за развитие. По време на всяка итерация (етапи на разработка на софтуер) се набляга на директната комуникация на специалистите "лице в лице". Повечето отбори са разположени в един офис. Уверете се, че имате „клиент“ - пълномощен представител, който прави изисквания за развитие. Тази роля се управлява от мениджърапроект, клиент-клиент, бизнес анализатор. Офисът може да включва и тестери, технически писатели, дизайнери на интерфейса и др.
Основният показател тук е крайният продукт. Плюс директното общуване на специалисти е, че има сравнително малък брой придружаващи писмени документи.

Agile Manifesto

Да разгледаме основните стандарти за разработка на софтуер. Първият е набор от процеси на развитие, наречени Agile. Той е дефиниран от Agile Manifesto. Важно е да се каже, че Agile не включва някои практически съвети, но съдържа ценностите и принципите, които трябва да се ръководят от екипа на разработчиците в тяхната работа. Agile Manifesto е разработен и приет на 1-13 февруари 2001 г. в ски курорт в планините Юта. Съдържа 4 основни идеи и 12 принципа на работа в екип без единен практически съвет. Представете си основните идеи на тази съвременна методология за разработване на софтуер:

Взаимодействието и хората са най-важните инструменти и процеси.

Работният продукт е над изчерпателната документация.

Сътрудничеството с клиента е най-важната хармонизация на индивидуалните договорни клаузи.

Готовността на екипа да се променя е по-важен от приемането на първоначалните планове.

Също така в манифеста Agile бяха посочени следните принципи на дейностите на предприемача:

Удовлетворяване на исканията на клиентите поради непрекъсната ранна доставка на ценни продукти.

Поздравления за променящите се изисквания дори след приключване на проекта. В крайна сметка това може да увеличи конкурентоспособността му.

Чести доставкиработен софтуер - всяка седмица.

В проекта са включени мотивирани лица, снабдени с удобни условия на труд, доверие и подкрепа.

Ежедневно тясно взаимодействие между екипа на клиента и разработчика.

Софтуерът ще бъде най-добрата мярка за напредък.

Потребителите, спонсорите и предприемачите трябва да поддържат избраното темпо за неопределен период от време.

Непрекъснато внимание към подобряването на дизайна на продукта, техническите изисквания.

Простотата е изкуството да не се работи в излишна работа.

Постоянно адаптиране към променящите се условия на дейност. Разработчиците трябва постоянно да намират начини да подобрят работата си, да ги следват по-късно.

Модел на водопада

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

Поради тази твърдост е лесно да се управлява проект по тази методология. Цената и времето на развитието са предопределени, защо работата е бърза. Но също така е важно да се помни този аспект: каскадният модел дава отличен резултат само в проекти с предварително определени ясно дефинирани изисквания, методи за тяхното изпълнение. Тук специалистите нямат възможност да „върнат”, тъй като тестването започва само след приключване на фазата. Ако изборът на такъв модел не е добре обоснованза продукта, тогава продукцията може да се види със значителни недостатъци. В крайна сметка, тяхното присъствие ще бъде известно след приключване на работата, поради строгата последователност от дейности. Фиксирането на грешки тук е доста скъпо. За да стартирате пластира, трябва да изчакате края на разработката.
Експертите съветват да се използва методология "водопад" в следните случаи:

Изискванията на проекта са известни, разбрани и фиксирани. Между тях няма противоречия.

Няма проблем в програмирането на изискващите се квалификации.

Проектът е сравнително малък.

V-модел

Етапите на разработване на софтуер също са последователни. Тази функция V-модел "наследи" от "водопад". Особено добре за онези системи, където се изисква безпроблемна работа. Добър пример е създаването на приложен софтуер за клиники, използвани за непрекъснато наблюдение на пациенти. Или софтуер, който контролира механизмите на въздушните възглавници в превозните средства. Или заявление за мобилен оператор, предназначено да спести на потребителски разходи за роуминг при пътувания в чужбина. Проектът се изпълнява едновременно с ясните точки на творческата задача. Въпреки това, значителна роля се отдава на навременното тестване: функционален, интеграционен, натоварващ, лесен за употреба интерфейс. Когато е необходимо да се използва тази методология за развитие:

В случаите, когато се изисква внимателно тестване на продукта.

За малки и средни проекти с ясно определени изисквания.

Vусловия, когато са на разположение инженери, тестери на определена квалификация.

Инкрементален модел

В тази технология за разработка на софтуер сложните изисквания на системата са разделени на компилация. С други думи, това е описание на поетапно изграждане. Няколко цикъла на разработване на проекти са в комплекс, наречен "мулти-водопад". Цикълът, от своя страна, е разделен на отделни лесни за създаване модули. Всеки от тях преминава през етапите на определяне на изискванията, проектиране, изпълнение, тестване, кодиране. Особеност тук е, че на първия голям етап се издава основният модел на развитие. След това към него се добавят увеличения - нови функции. Такъв процес продължава до създаването на пълен комплекс. Един допълнителен модел е добър, когато индивидуалните искания за промяна са ясни, могат просто да бъдат формализирани и изпълнени. Да опишем случаите, в които използването на инкременталния модел е оправдано:

Ясно определени и разбираеми изисквания за крайния продукт.

Допуска се някои подробности да се уточнят с течение на времето.

Има няколко рискови цели.

На пазара е необходимо ранно заключение.

Модел RAD

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

Бизнес симулация. Това е дефинирането на информационните потоци между спектъра на единиците.

Симулиране на информация. Данните, събрани на първия етап, се използват за идентифициране на образуванията, необходими за разпространението на информация.

Моделиране на процеси. По време на тази фаза информационните потоци свързват определени обекти, за да постигнат целта на развитието.

Изготвяне на програмата. Тук използваме автомобилни сглобки за преобразуване на дизайнерските модели в код.

Тестване. Проверка на нови компоненти и интерфейси.

Използвайте този метод за разработка на софтуер само когато има висококвалифицирани и "тесни" специалисти в екипа. Бюджетът на проекта със сигурност е голям: необходимо е да се плати работата на професионалистите, цената на готовите инструменти на автоматизираното сглобяване. Моделът е избран с увереното познаване на целевия бизнес в случаите, когато е необходимо да се представят кратките крайни продукти - в рамките на 2-3 месеца.

Итеративен модел

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

Изискванията за окончателния вариант на разработката са ясни и ясно определени.

Проектът е много голям.

Основната задача е предварително определена. Но нека да подобрим нейните детайли, да променим процеса на работа.

Спирален модел

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

Планиране.

Анализ на риска.

Строителство.

Оценка на резултатите. Ако е положително, тогава предприемачът се премества в новата "нишка" на проекта.

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

LD

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

Насърчаване на всеки служител за особено успешна дейност.

Настоящите цели на проекта се променят само в случай на крайна необходимост или по искане на клиента.

Строго изпълнение на плана. Супер работата се счита за знак за загуба на време и ресурси.

Изпълнение на общата концепция за дейността: "Широко мислене, бърза грешка, малко работа, учене бързо".

XP

Един много интересен пример е методологията на т.нар. Екстремпрограмиране. Какво е скрито тук? Това е развитие в условията на постоянно променящи се изисквания към продукта. Посоката на методологията има следните отличителни черти:

"Планиране на играта". В началото на работата е представен само приблизителен план. С всеки завой на развитието му рязкостта се увеличава.

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

Контакт с клиента. За следната методология е важно бързо да се изпълнят всички изисквания на клиента - да се отговори бързо на всички негови коментари и желания.

Рефакториране. Качеството на кода се подобрява, без да се намалява неговата функционалност.

Изпълнение на стандартен код. По лицето или следвайки общите правила, или липсата на несъответствия в процеса на разработване.

Колективна отговорност. Така че всеки член на екипа е зает с определена област на работа. Но за цялостния резултат целият екип вече е отговорен.

FDD

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

Развитието на всеки голям проект е системна дейност.

Всички процеси следва да бъдат прости и добре проектирани.

Логиката и стойността на всеки процес трябва да бъдат разбрани от всеки член на екипа.

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

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