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

Ще видим как ще стане…

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

Разработка „Как се оказва“

Какво ще кажете за итеративния подход? Уви, по правило не се използва в такива проекти. На първо място, защото щеше да даде възможност още в първите итерации проектът да бъде оценен като изключително съмнителен и изискващ спешна намеса от висшето ръководство за възстановяване на реда. Наистина, в итеративен проект традиционният отговор на програмиста, че той има всичко 90% готово, продължава само до завършването на първата итерация...

Структурни методологии

Структурни методологии

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

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

Освен това всички тези методологии изискват силно формализиран подход, въпреки че в тях могат да бъдат намерени твърдения за разумно количество документация. Един от неочевидните примери, че методологиите за разработка на софтуер се развиват не само на Запад, е цитат от книга, издадена у нас в началото на 80-те години, в която се казва, че степента на формализиране на програмна задача трябва да се определя въз основа на това колко добре анализаторът и програмистът. И това въпреки факта, че темата на книгата включваше разработването на доста критични, както сега се наричат, системи, грешките в които водят до сериозни загуби или дори бедствия.

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

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

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

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

eXtreme Programming или XP (екстремно програмиране)

Методологията XP, разработена от Кент Бек, Уорд Кънингам и Рон Джефрис, е най-известната от гъвкавите методологии днес. Понякога самата концепция за „гъвкави методологии“ изрично или имплицитно се идентифицира с XP, който проповядва комуникация, простота, обратна връзкаи смелост. Описва се като набор от практики: игра за планиране, кратки версии, метафори, опростен дизайн, рефакторинг, разработка с тест напред, програмиране по двойки, споделена собственост върху кода, 40-часови работни седмици, постоянно присъствие на клиенти и стандарти за код . Интересът към XP нарастваше отдолу нагоре - от разработчици и тестери, измъчвани от болезнения процес, документация, метрики и друг формализъм. Те не отхвърлиха дисциплината, но не искаха безсмислено да се придържат към формалните изисквания и търсеха нови, бързи и гъвкави подходи за разработване на висококачествени програми.

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

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

Кристално чист

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

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

Основни характеристики на Crystal Clear:

• итеративно постепенно развитие;
• автоматично регресионно тестване;
• потребителите са поканени да участват активно в проекта;
• съставът на документацията се определя от участниците в проекта;
• Обикновено се използват инструменти за контрол на версията на кода.

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

Разработка, управлявана от функции

Разработка, управлявана от функции (FDD) работи с концепцията за функция или характеристика на система, която е доста близка до концепцията за случай на употреба, използвана в RUP. Може би най-съществената разлика е допълнително ограничение: „всяка функция трябва да позволява внедряване за не повече от две седмици.“ Тоест, ако случаят на използване е достатъчно малък, той може да се счита за функция, а ако е голям, тогава трябва да бъде разделен на няколко относително независими функции.

FDD включва пет процеса, като последните два се повтарят за всяка функция:

• развитие общ модел;
• съставяне на списък с необходимите системни функции;
• планиране на работата по всяка функция;
• функционален дизайн;
• функционална конструкция.

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

Разработчиците във FDD се делят на „класни ръководители“ и „главни програмисти“. Основните програмисти включват собствениците на включените класове в работата по следващото свойство. За сравнение, в XP няма лица, отговорни за класове или методи.

Общи черти

Списъкът с гъвкави методологии в момента е доста широк. Въпреки това методологиите, които описахме, предоставят много пълна картина на цялото семейство.

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

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

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

ГОСТ стандарти

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

В момента в Русия са в сила старите GOST от 19-та и 34-та серия и по-новият GOST R ISO IEC 122207. GOST от 19-та и 34-та серия са строго фокусирани върху каскадния подход към разработката на софтуер. Разработването в съответствие с тези GOST се извършва на етапи, всеки от които включва изпълнението на строго определена работа и завършва с издаването на доста голям брой много формализирани и обширни документи. По този начин незабавното стриктно придържане към тези стандарти не само води до каскаден подход, но също така осигурява много висока степенформализиране на развитието.

Изисквания на GOST

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

По този начин GOST 12207 позволява итеративна и по-малко формализирана разработка на софтуер.

Модели на зрялост на процеса на разработка (CMM, CMMI)

В допълнение към държавните и международните стандарти има няколко подхода за сертифициране на процеса на разработка. Най-известните от тях в Русия са, очевидно, CMM и CMMI.

CMM (Capability Maturity Model) е модел на зрялост на процесите за създаване на софтуер, който е предназначен да оцени нивото на зрялост на процеса на разработка в конкретна компания. Според този модел има пет нива на зрялост на процеса на развитие. Първото ниво съответства на развитието „както се случва“, когато разработчиците подхождат към всеки проект, сякаш е подвиг. Вторият съответства на повече или по-малко установени процеси, когато можете да разчитате с разумна увереност на положителен резултат от проекта. Третият съответства на наличието на развити и добре описани процеси, използвани при разработката, а четвъртият съответства на активното използване на метрики в процеса на управление за поставяне на цели и наблюдение на тяхното постигане. И накрая, петото ниво се отнася до способността на компанията да оптимизира процеса според нуждите.

Изисквания за CMM и CMMI

След появата на CMM започнаха да се разработват специализирани модели за зрялост информационни системи, за процеса на избор на доставчик и някои други. Въз основа на тях е разработен интегриран модел CMMI (Capability Maturity Model Integration). В допълнение, CMMI направи опит да преодолее недостатъците на CMM, появили се по това време - преувеличаване на ролята формални описанияпроцеси, когато наличието на определена документация е оценено значително по-високо от просто добре установен, но неописан процес. Въпреки това, CMMI също се фокусира върху използването на много формализиран процес.

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

Връзката между CMM и CMMI и итеративното развитие е по-непряка. Формално нито едното, нито другото поставят конкретни изисквания за придържане към каскаден или итеративен подход. Въпреки това, според някои експерти, CMM е по-съвместим с подхода на водопада, докато CMMI също позволява използването на итеративен подход.

RUP

Разбира се, RUP е итеративна методология. Въпреки че задължителното изискване за завършване на всички фази или определен минимален брой итерации не е официално посочено никъде в RUP, целият подход е фокусиран върху факта, че има доста от тях. Ограниченият брой итерации не позволява пълното използване на предимствата на RUP. В същото време RUP може да се използва и в практически водопадни проекти, които всъщност включват само няколко итерации: едната във фазата „Изграждане“, а другата във фазата „Прехвърляне“. Между другото, в проекти за водопади този брой итерации всъщност се използва. В края на краищата, тестването и пробната експлоатация на системата включва извършване на корекции, които могат да включват определени действия, свързани с анализ, проектиране и разработка, тоест всъщност те са още едно преминаване през всички фази на разработка.

RUP методология

Що се отнася до формалността на методологията, RUP предоставя на потребителя много широк набор от възможности. Ако свършите цялата работа и задачи, създадете всички артефакти и проведете всички прегледи съвсем формално (с официален рецензент, изготвяне на пълен преглед под формата на електронен или хартиен документ и т.н.), RUP може да се окаже бъде изключително формална, тежка методология. В същото време RUP ви позволява да разработвате само онези артефакти и да изпълнявате само онези работни места и задачи, които са необходими в конкретен проект. И избраните артефакти могат да бъдат изпълнени и прегледани с произволни степени на формалност. Можете да изисквате подробно изработване и внимателно изпълнение на всеки документ, предоставяне на също толкова внимателно попълнен и изпълнен преглед и дори, следвайки старата практика, одобрение на всеки такъв преглед от научно-техническия съвет на предприятието. Или можем да се ограничим чрез имейлили скица на хартия. Освен това винаги има още една възможност: да оформите документ в главата си, тоест да помислите по съответния въпрос и да вземете конструктивно решение. И ако това решение засяга само вас, тогава се ограничете, например, до коментар в програмния код.

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

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

Ще обсъдим защо това е толкова важно в следващата част.

1. Каскада (англ. waterfall) - стандартен модел на развитие

Каскадният модел на развитие е модел, при който всички етапи на развитие се извършват последователно - следващият етап започва след пълно завършване на предходния.

Този модел включва следните етапи от процеса на разработка на софтуер:

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

След пълно завършване на дизайна, програмистите извършват изпълнението (изграждането) на проекта. На етапа на изпълнение се осъществява интегрирането на всички компоненти на проекта. Едва след като тези етапи са напълно завършени, крайният продукт се тества и отстранява грешки. След това софтуерният продукт може да се внедри и след внедряването да се осигури поддръжка – въвеждане на нови функционалности и отстраняване на грешки.

Основните предимства на развитието на водопада:

2. Гъвкава методология за разработка на софтуер

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

Резултатът от всеки такъв етап, включително цикъл от итерации, е определен миниатюрен софтуерен проект,

Има няколко гъвкави метода за разработка, като най-известните са Scrum, екстремно програмиране, DSDM.

Основните предимства на гъвкавото развитие:

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

Манифест за гъвкава разработка на софтуер Постоянно откриваме по-добри техники за разработка на софтуер, като го правим сами и помагаме на другите да направят същото. Благодарение на свършената работа успяхме да осъзнаем, че: Хора и взаимодействиепо-важни от процеси и инструменти Работещ продуктпо-важно от изчерпателната документация Сътрудничество с клиентапо-важно от съгласуването на условията на договора Желанието за промяна е по-важноследвайки първоначалния план Тоест, без да отричаме важността на това, което е отдясно, ние все пак ценим повече това, което е отляво.

Принципи на гъвкавото развитие:

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

Анотация: Разглеждат се гъвкавият подход при създаването на софтуер и основните принципи на гъвкавото развитие. Предоставен е списък от техники, които до известна степен съответстват на принципите на гъвкавото разработване на софтуер. Анализирани са основните ценности и принципи на гъвкавото развитие.

Можете да изтеглите презентацията за тази лекция.

Цел на лекцията:

Получете разбиране за целта и основните принципи на гъвкавото разработване на софтуер.

Въведение

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

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

Принципи и значение на гъвкавото развитие

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

• хората и техните взаимодействия;
• доставка на работещ софтуер;
• сътрудничество с клиента;
• реакция на промяна.

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

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

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

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

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

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

Принципите на гъвкавото развитие се подкрепят от 12 принципа. Специфични методологии за гъвкаво развитие дефинират процеси и правила, които повече или по-малко се придържат към тези принципи. Гъвкавите методологии за създаване на софтуерни продукти се основават на следните принципи:

1. Най-високият приоритет е да се задоволят желанията на клиента чрез доставка на полезен софтуер за кратко време, последван от непрекъснати актуализации. Гъвкавите методологии включват бърза доставка на първоначалната версия и чести актуализации. Целта на екипа е да достави работеща версия в рамките на няколко седмици след стартиране на проекта. По-нататък софтуерни системис прогресивно по-голяма функционалност трябва да се доставя на всеки няколко седмици. Клиентът може да започне търговска експлоатация на системата, ако я счита за достатъчно функционална. Също така, клиентът може просто да се запознае с текущата версия на софтуера и да предостави своята обратна връзка с коментари.
2. Не пренебрегвайте променящите се изисквания, дори в късните етапи на развитие. Гъвкавите процеси позволяват промените да бъдат адаптирани, за да осигурят на клиента конкурентно предимство. Екипите, използващи гъвкави методи, се стремят да осигурят висококачествена програмна структура с минимално въздействие на промените върху системата като цяло.
3. Доставяйте често нови работещи версии на софтуера, на интервали от една седмица до два месеца, с предпочитание към по-кратки срокове. Целта е да се достави програма, която отговаря на нуждите на потребителя с минимум придружаваща документация.
4. Клиентите и разработчиците трябва да работят заедно по време на целия проект. Смята се, че за успешен проект клиентите, разработчиците и всички заинтересовани страни трябва да комуникират често и широко, за да подобрят целенасочено софтуерния продукт.
5. Проектите трябва да се изпълняват от мотивирани хора. Създайте нормални условия за работа на екипа по проекта, осигурете необходимата подкрепа и доверие, че членовете на екипа ще доведат работата докрай.
6. Най-ефективният и ефикасен метод за предаване на информация на екипа за разработка и обмен на мнения в него е разговорът лице в лице. В гъвкавите проекти основният начин на комуникация е простото човешко взаимодействие. Писмените документи се създават и актуализират постепенно с разработването на софтуера и само когато е необходимо.
7. Работната програма е основният индикатор за напредъка на проекта. Напредъкът на един гъвкав проект към завършване се оценява по степента, в която е постигнат този моментпрограмата отговаря на изискванията на клиента.
8. Гъвкавите процеси насърчават дългосрочното развитие. Клиентите, разработчиците и потребителите трябва да могат да поддържат постоянно темпо за неопределено време.
9. Безмилостният фокус върху техническото съвършенство и качествения дизайн увеличава въздействието на гъвкавите технологии. Членовете на Agile екипа се стремят да произвеждат качествен код чрез редовен рефакторинг.
10. Простотата е изкуството да постигаш повече, като правиш по-малко. Членовете на екипа решават текущи проблеми възможно най-просто и ефективно. Ако възникне някакъв проблем в бъдеще, възможно е да направите промени във висококачествен код без големи разходи.
11. Най-добрите архитектури, изисквания и проекти идват от самоорганизиращи се екипи. В гъвкавите екипи задачите се възлагат не на отделни членове, а на екипа като цяло. Екипът решава как най-добре да изпълни изискванията на клиента. Членовете на екипа работят заедно по всички аспекти на проекта. Всеки участник има право да допринесе за общата кауза. Няма член на екипа, който да е единствено отговорен за архитектурата, изискванията или тестовете.
12. Екипът трябва редовно да мисли как да стане още по-ефективен и след това да коригира и коригира поведението си съответно. Един гъвкав екип непрекъснато коригира своята организация, правила, споразумения и взаимоотношения.

Горните принципи до известна степен съответстват на редица методологии за разработка на софтуер:

AgileModeling	набор от концепции, принципи и техники (практики), които ви позволяват бързо и лесно да извършвате моделиране и документиране в проекти за разработка на софтуер;
AgileUnifiedProcess (AUP)	опростена версия на IBM RationalUnifiedProcess(RUP), която описва просто и разбираемо приближение (модел) за създаване на софтуер за бизнес приложения;
Отвори	Това е итеративно-инкрементален метод за разработка на софтуер. Позициониран като олекотена и гъвкава версия на RUP;
AgileDataMethod	група от итеративни методи за разработка на софтуер, при които изискванията и решенията се постигат чрез сътрудничеството на различни многофункционални екипи;
DSDM	методология за разработване на динамични системи, базирана на концепцията за бързо разработване на приложения (RapidApplicationDevelopment, RAD). Това е итеративен и постепенен подход, който набляга на непрекъснатото участие на потребителя/потребителя в процеса;
Екстремно програмиране (XP)	екстремно програмиране;
Адаптивна разработка на софтуер (ADD)	разработка на адаптивен софтуер;
Разработка, управлявана от функции (FDD)	развитие, насочено към постепенно добавяне на функционалност;
GettingReal	итеративен подход без функционални спецификации, използван за уеб приложения;
MSFogAgileSoftwareDevelopment	Гъвкава методология за разработка на софтуер на Microsoft;
Scrum	установява правила за управление на процеса на разработка и ви позволява да използвате съществуващи практики за кодиране, коригиране на изисквания или извършване на тактически промени [

1. Кодиране

На етапа на разработка на софтуер се извършват следните основни действия: кодиране; тестване; разработване на ПП помощна система; създаване на потребителска документация; създаване на версия и инсталиране на софтуер,

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

Когато кодирате, трябва да следвате стандарта за избрания език, например за езика C това е ANSI C, а за C++ е ISO/IEC 14882 „Стандарт за езика за програмиране C++“.

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

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

На етапа на кодиране програмистът пише програми и ги тества сам. Този тип тестване се нарича тестване на единици. Всички въпроси, свързани с тестването на софтуера, са разгледани в гл. 10, тук също е описана технологията за тестване, която се използва на етапа на разработка на софтуер. Тази технология се нарича тестване "стъклена кутия" (glassbox);понякога се нарича още тестване "бяла кутия" (бяла кутия)за разлика от класическата концепция за „черна кутия“.

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

При тестване на „стъклена кутия“ ситуацията е съвсем различна. Тестерът (в този случай самият програмист) разработва тестове въз основа на познаване на изходния код, до който има достъп пълен достъп. В резултат на това той получава следните предимства.

1. Посока на тестване. Програмистът може да тества програмата на части, да разработи специални тестови подпрограми, които извикват тествания модул и му предават данните, които представляват интерес за програмиста. Много по-лесно е да тествате отделен модул като „стъклена кутия“.

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

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

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

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

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

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

Когато извършвате модулно тестване, можете да използвате или структурна, или функционална технология за тестване, или и двете.

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

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

Обект на изпитване може да бъде не само пълен пътпрограмата (последователността от команди, които тя изпълнява от началото до края), но също и нейните отделни секции. Абсолютно нереалистично е да се тестват всички възможни начини за изпълнение на една програма. Следователно специалистите по тестване се отличават от всички възможни начинитези групи, които трябва да бъдат тествани. За избор те използват специални критерии т.нар критерии за покритие (coveragecriteria),които определят много реален (дори и доста голям) брой тестове. Тези критерии понякога се наричат критерии за логическо покритие,или критерии за пълнота.

3. Разработване на помощна система за програмния продукт. Създаване на потребителска документация

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

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

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

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

1. Лекота на използване. Ако софтуерът е добре документиран, той е много по-лесен за прилагане. Потребителите го учат по-бързо, правят по-малко грешки и в резултат на това вършат работата си по-бързо и по-ефективно.

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

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

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

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

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

Основните принципи на структурния подход са:

o принцип " разделяй и владей“;

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

Основните от тези принципи са:

o абстракция - подчертаване на съществените аспекти на системата;

o последователност - валидност и последователност на елементите на системата;

o структуриране на данни - данните трябва да бъдат структурирани и йерархично организирани.

Методологични основи на технологиите за създаване на софтуер

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

Графичните (визуални) модели са инструменти за визуализиране, описване, проектиране и документиране на системната архитектура. Съставът на използваните модели във всеки конкретен проект и степента на тяхната детайлност обикновено зависят от следните фактори:

o трудности на проектираната система;

o необходимата пълнота на описанието му;

o знания и умения на участниците в проекта;

o време, отделено за проектиране.

Визуалното моделиране повлия значително върху развитието на CASE инструментите в частност. Концепцията за CASE (Computer Aided Software Engineering) се използва в широк смисъл. Първоначалното значение на тази концепция, ограничено само до задачите за автоматизация на разработката на софтуер, вече е придобито нов смисъл, обхващащ повечето процеси от жизнения цикъл на софтуера.

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