Меню

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

  • Основен
  • Пъргаво Тестване
  • Казус: Как да премахнем недостатъците на водопада и гъвкавите процеси на развитие с помощта на хибриден модел

case study how eliminate flaws waterfall

Опитайте Нашия Инструмент За Премахване На Проблемите

Хибриден модел на пъргав водопад

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

Но моделът Waterfall има някои недостатъци.

Подвижната разработка на софтуер еволюира, за да премахне проблемите, които моделът Waterfall има. Той има напълно нова рамка. Докато моделът Waterfall има последователен дизайн, моделът Agile следва постепенно подход.

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

Хибриден модел на пъргав водопад

По този начин се е развила нова методология, която може да се нарече „хибридна“, за да се осигури стабилен краен продукт, като се изберат плюсовете както на Agile, така и на Waterfall моделите.

Нека първо да знаем за моделите за развитие на водопада и пъргавината и след това да преминем към „хибридния модел на пъргавия водопад“ с плюсове и минуси на всеки.

Какво ще научите:

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

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

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

=> Прочетете повече за модела на водопада тук.

Фигура 1 показва модела на водопада:

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

Предимства на модела на водопада:

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

Недостатъци на модела Waterfall:

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

Пъргав модел

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

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

=> Прочетете повече статии за Agile методологията тук.

(Щракнете върху изображението, за да видите увеличено)

Пъргав модел

Предимства на модела Agile:

какво е описателно програмиране в qtp
  • Участие на клиента в процеса.
  • Високата възвръщаемост на инвестициите като работещ софтуер се доставя често.
  • Дори късните промени в изискванията могат лесно да бъдат приспособени.
  • Непрекъснато подобряване както на продукта, така и на процеса.

Недостатъци на Agile Model:

  • Липса на акцент върху проектирането и документацията.
  • Екипът трябва да бъде стабилен и квалифициран.

Сътруднически (хибриден) модел

Моделът за сътрудничество има за цел да комбинира двата модела - Водопад и Пръстен. Използването на подхода Waterfall и Agile гарантира успеха на проекта. Той премахва недостатъците на двата модела; като същевременно обединява предимствата и на двете.

Моделът за сътрудничество може да бъде приложен в проект чрез изпълнение на:

Сътруднически (хибриден) модел

Така че Колаборативният модел може да бъде представен схематично, както по-долу:

Съвместен (хибриден) модел 2

Предимства на хибридния модел

  • Комбинира предимствата както на Agile, така и на Waterfall процеси.
  • Дизайнът на високо ниво е подготвен да прилага принципите на водопада.
  • Кодирането и тестването се извършват по гъвкава методология.

Хибриден модел на пъргав водопад - Научете чрез пример -Казус

Софтуерната фирма ‘ABC Software Service’ предоставя услуги на клиент, университет на име ‘XYZ University’ за разработване, тестване и поддръжка на техния софтуер (поддръжка на живо производство).

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

  1. ABC Software Services трябва да надграждат приложенията на XYZ University. Базата данни трябва да бъде надградена и всички приложения трябва да бъдат преработени до най-новите технологии, налични на пазара.
  2. Досега всички проекти, обработвани от ABC Software, се изпълняваха по модел Waterfall.
  3. Две от натоварения трафик и приложения с висок приоритет бяха планирани да бъдат преработени. Първият е „Онлайн регистрации“, вторият е „Онлайн изпити“.
  4. Клиентският университет XYZ сега искаше върху тези приложения да се работи, използвайки Agile модела на разработка на софтуер.

Първият проект в Agile модел за ABC Software беше онлайн регистрация. След изпълнението на този проект беше осъзнато в поредица от ретроспективи, че има много недостатъци в следваните процеси.

Тези недостатъци бяха отстранени при изпълнението на втория проект „онлайн изпити“ и следователно той беше изпълнен в хибриден модел.

Как да премахнем недостатъците на водопада и пъргавите процеси на развитие с помощта на хибриден модел:

Нека да ги обсъдим подробно един по един.

# 1. Няма документация:

Един от гъвкавите принципи в гъвкавия манифест гласи, че: Agile дава по-голяма стойност на „Работещ софтуер над изчерпателна документация“. Agile методологията смята, че документацията трябва да бъде „едва едва достатъчно добра“ и повече внимание се отделя на изпращането на работещ софтуер. Не се полагат много усилия по отношение на документацията, но за акаунти като XYZ University, със специален екип за поддръжка, който да работи по дефекти, открити на живи проекти, този навик може да се окаже пречка, ако го анализираме в дългосрочен план.

През годините, когато проектите се изпълняваха по модела Waterfall, документите се поддържаха и актуализираха, за да може екипът за поддръжка да разбере и да работи съответно. Проектиране на решения, технически дизайн, документи за упътване и др. Бяха някои от подготвените документи. След като проектът приключи, същият беше преместен в екипа за поддръжка.

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

Това беше основен извлечен урок и за следващия проект бяха написани и прехвърлени ефективно документи „онлайн изпити“.

=> Прочетете повече тук, защо е важна документацията.

# две. Без UAT / тестване от край до край:

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

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

=> Тестване от край до край на проект на живо.

Това има своите предимства:

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

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

Когато стартира проектът за онлайн изпити, SIT (System Integration Testing) беше направено и кодът беше популяризиран в среда на UAT, където беше направен вторият цикъл на тестване. Резултат: Всички дефекти с висок приоритет бяха уловени и отстранени. Компилацията беше стабилна преди пускането на живо.

# 3. Без Scrum Master:

откриване на изтичане на памет c ++

The Scrum Master е отговорен за гарантиране, че екипът живее според ценностите и практиките на Scrum. Scrum Master се счита за треньор на отбора, като помага на отбора да свърши най-добрата работа, която е възможно. Scrum Master може също да се разглежда като a собственик на процеса за отбора.

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

В проекта за онлайн изпити обаче беше включен специален Scrum Master. За проблемите на проекта и предизвикателствата се погрижи Scrum Master. Изготвени бяха докладите за проекта / спринта и екипът можеше да види напредъка им.

Също така, за всеки спринт се проведоха правилни срещи за планиране на спринт и ретроспективни срещи, които подобриха представянето на отбора. Екипът се концентрираше само върху работата си и изпълняваше задачите си, определени за този спринт. Цялото допълнително домакинство се извършва от Scrum Master.

# 4. Конвертиране на проектни документи в изоставане на Продукта:

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

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

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

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

# 5. Матрица на проследимост:

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

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

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

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

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

Приетият хибриден модел може да бъде представен изобразително по-долу:

Съвместен (хибриден) модел 3

Заключение:

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

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

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

Манифестът Agile ни моли да оценим:

  • Индивиди и взаимодействия над процеси и инструменти
  • Работещ софтуер над изчерпателна документация
  • Сътрудничество с клиенти над договарянето на договора
  • Отговаряне на промяната следвайки план

Докато хибридният модел не се придържа към тези 100%. Той предполага, че всички аспекти са еднакво важни. От клиентите / ръководителите на проекти зависи да решат кои аспекти да оценяват повече и кои аспекти да обезценяват.

За автора: Това е статия за гости от Harshpal Singh. Той има 7+ години опит в ръчно управление, бази данни, автоматизация и тестване на производителността и в момента работи като ръководител на екип във водеща MNC. Работил е по много проекти за осигуряване на качеството следвайки моделите за развитие на водопада, пъргави и хибридни.

Имате ли опит да работите по този хибриден модел за разработка и тестване? Нека обсъдим в коментари.

Препоръчително четене

^