Meni

Študija primera: Kako odpraviti pomanjkljivosti slapov in agilnih razvojnih procesov s pomočjo hibridnega modela

  • Glavni
  • Agilno Testiranje
  • Študija primera: Kako odpraviti pomanjkljivosti slapov in agilnih razvojnih procesov s pomočjo hibridnega modela

case study how eliminate flaws waterfall

Preizkusite Naš Instrument Za Odpravo Težav

Hibridni model okretnega slapa

Model Slap je bila idealna izbira za razvoj programske opreme. V tem modelu ideja postane uporabna programska oprema v zaporednem postopku, ki preide skozi faze iniciacije, analize, implementacije, testiranja in vzdrževanja.

Toda model Slap ima nekaj slabosti.

Agilen razvoj programske opreme se je razvil, da bi odpravil težave, ki jih ima model Slap. Ima povsem nov okvir. Medtem ko ima model Waterfall zaporedno zasnovo, je model Agile sledil postopnemu pristopu.

Ko so stranke, ki so sledile modelu Slap, prešle na Agile, je prehod prinesel veliko težav. Razlog je neprilagojenost drugačnemu pristopu k razvoju programske opreme. Končni izdelek se je izkazal za katastrofo.

Hibridni model okretnega slapa

Tako se je razvila nova metodologija, ki ji lahko rečemo „hibrid“, da bi zagotovili močan končni izdelek z izbiro prednosti modelov Agile in Waterfall.

Najprej se pozanimajmo o razvojnih modelih slapa in gibčnosti, nato pa preidimo na 'hibridni model okretnega slapa' z vsemi prednostmi in slabostmi.

Kaj se boste naučili:

Model slapa

Model Slap je pristop za razvoj programske opreme, ki projekt razdeli v končne faze. V naslednjo fazo se je treba preseliti šele, ko se pregleda in preveri predhodna faza.

V modelu slapa se faze ne prekrivajo.

=> Več o modelu Slap preberite tukaj.

Slika 1 prikazuje model slapa:

java intervju programi za sveže pdf

Model slapa

Prednosti modela Slap:

  • Preprosto in enostavno za razumevanje in uporabo.
  • Togi model - Vsaka faza ima posebne rezultate in postopke pregleda.
  • Dokumentacija in predmeti natančno vzdrževani.
  • Primerno za projekte, kjer so zahteve dobro razumljene.

Slabosti modela Slap:

  • Ni primeren za projekte, pri katerih obstaja tveganje, da se zahteve spremenijo.
  • Stroški odprave napak so zelo visoki, če jih odkrijemo pozneje.
  • Ni dober model za zapletene in dolge projekte.
  • Nobena delujoča programska oprema se ne proizvaja pozno v življenjskem ciklu.

Agile Model

Wikipedia opredeljuje Agile Model kot 'skupino metod za razvoj programske opreme, ki temelji na iterativnem in inkrementalnem razvoju, kjer se zahteve in rešitve razvijajo v sodelovanju med samoorganizirajočimi se, večfunkcionalnimi skupinami.'

Model ima svoja načela, ki postopke ponavadi pripeljejo na zadnji sedež.

=> Preberite več člankov o agilni metodologiji tukaj.

(Kliknite sliko za ogled povečave)

Agilen model

Prednosti modela Agile:

  • Vključenost stranke v postopek.
  • Visok donosnost naložbe kot delujoča programska oprema je na voljo pogosto.
  • Tudi pozne spremembe zahtev je enostavno prilagoditi.
  • Nenehno izboljševanje tako izdelka kot postopka.

Slabosti agilnega modela:

  • Pomanjkanje poudarka na oblikovanju in dokumentaciji.
  • Ekipa mora biti stabilna in usposobljena.

Skupni (hibridni) model

Cilj modela sodelovanja je združiti oba modela - slap in gibčnost. Izkoristek pristopa Slap in gibčnost zagotavlja uspeh projekta. Odstrani pomanjkljivosti obeh modelov; hkrati pa združuje prednosti obeh.

Model sodelovanja je mogoče v projektu izvesti z izvajanjem:

Skupni (hibridni) model

Model sodelovanja je torej mogoče shematično predstaviti spodaj:

Skupni (hibridni) model 2

Prednosti hibridnega modela

  • Združuje prednosti agilnih in slapovskih procesov.
  • Zasnova na visoki ravni je pripravljena na uporabo načel slapa.
  • Kodiranje in testiranje poteka po agilni metodologiji.

Hibridni model okretnega slapa - naučite se z zgledi -Študija primera

Programsko podjetje „ABC Software Service“ stranki, univerzi z imenom „XYZ University“, ponuja storitve za razvoj, testiranje in vzdrževanje njihove programske opreme (podpora za produkcijo v živo).

Glavne značilnosti računa so:

  1. ABC Software Services morajo nadgraditi aplikacije Univerze XYZ. Podatkovno bazo je treba nadgraditi in vse aplikacije je treba razviti po najnovejši tehnologiji, ki je na voljo na trgu.
  2. Do zdaj so bili vsi projekti, s katerimi se ukvarja ABC Software, izvedeni v modelu Waterfall.
  3. Dve od prometnih in visoko prioritetnih aplikacij naj bi bili zdaj ponovno razviti. Prvo je 'Spletne prijave', drugo pa 'Spletni izpiti'.
  4. Naročnik XYZ University je zdaj želel, da se na teh aplikacijah dela z uporabo agilnega modela razvoja programske opreme.

Prvi projekt v agilnem modelu za programsko opremo ABC so bile spletne registracije. Po izvedbi tega projekta so v seriji retrospektiv ugotovili, da je bilo v postopkih veliko napak.

Te napake so bile odpravljene med izvajanjem drugega projekta 'spletni pregledi' in je bil zato izveden v hibridnem modelu.

Kako s hibridnim modelom odpraviti pomanjkljivosti slapov in agilnih razvojnih procesov:

O njih se podrobno pogovorimo posamezno.

# 1. Ni dokumentacije:

Eno od agilnih načel v agilnem manifestu navaja, da: Agile daje večjo vrednost 'delujoči programski opremi prek celovite dokumentacije'. Agile metodologija meni, da bi morala biti dokumentacija 'komaj dovolj dobra', večji poudarek pa je namenjen oddaji delujoče programske opreme. Za dokumentacijo se ne trudi veliko, toda za račune, kot je Univerza XYZ, z namensko podporno skupino za odpravljanje napak pri projektih v živo ta navada lahko ovira, če jo analiziramo dolgoročno.

V preteklih letih, ko so se projekti izvajali po modelu Slap, so se vodili in posodabljali dokumenti, da je podporna skupina razumela in delala v skladu s tem. Nekateri pripravljeni dokumenti so bili rešitve, tehnična zasnova, predstavitveni dokumenti itd. Po končanem projektu je bil isti premeščen v podporno skupino.

Toda v primeru projekta „spletnih registracij“ takšni dokumenti niso bili pripravljeni in se je to izkazalo za drago. Ko je projekt zaživel, so končni uporabniki zbrali veliko vstopnic in podporna skupina ni vedela, kako z njimi delati. Skupina ni imela nobenega referenčnega dokumenta.

To je bila glavna pridobljena lekcija in za naslednji projekt so bili dokumenti o „spletnih pregledih“ napisani in učinkovito preneseni.

=> Preberite več tukaj, zakaj je dokumentacija pomembna.

#dve. Brez UAT / preskušanja od konca do konca:

V agilnem načinu razvoja programske opreme preizkuševalci dobijo gradnje, ki jih preskušajo v korakih. Te gradnje se nadaljujejo z integracijo, dokler končna gradnja ni popolnoma zgrajena. Preizkuševalci preizkusijo zahteve, zajete v vsakem sprintu, in še naprej izvajajo regresijsko testiranje gradnje, ki se še naprej sešteva.

Ko pa bodo vsi sprinti končani in bo končna gradnja pripravljena in integrirana, mora preizkuševalec preizkusiti celoten sistem in opraviti preskušanje od konca do konca. To je treba storiti v popolnoma novem okolju.

=> Preskušanje na koncu projekta v živo.

To ima svoje prednosti:

  • Celoten sistem je postavljen v novo okolje in preizkuševalec preizkusi celoten pretok.
  • Gradi zaupanje, ker je na koncu gradnjo treba uporabiti kot celoto v živem okolju.

Ko je bil projekt spletnih registracij preizkušen, je bil izveden v testnem okolju. Po preizkusu sistema in ponovnem preizkusu vseh napak je bil prijavljen za odjavo. V idealnem primeru to ni bilo promovirano v drugo okolje za drug cikel preizkušanja sistema. (V idealnem primeru, UAT se zgodi po preizkusu sistema , toda v tem primeru so bili člani ekipe UAT vključeni v prvi cikel testiranja, zato drugi cikel ni bil predviden)

Ko se je začel projekt spletnih pregledov, je bilo izvedeno SIT (System Integration Testing) in koda je bila promovirana v okolje UAT, kjer je bil opravljen drugi cikel testiranja. Rezultat: Vse visoko prioritetne napake so bile zajete in odpravljene. Gradnja je bila stabilna pred izidom.

# 3. Brez Scrum Master:

The Scrum mojster je odgovoren za to, da ekipa živi v skladu z vrednotami in praksami Scruma. Scrum Master velja za trenerja ekipe, tako da ji pomaga, da opravi najboljše delo, kar je mogoče. Scrum Master si lahko predstavljamo tudi kot lastnik procesa za ekipo.

Skupina za spletne prijave je bila ustanovljena brez Scrum Masterja. Pomembnost posebnega Scrum Masterja se ni zdela pomembna. To je povzročilo, da se veliko vprašanj ni rešilo pravočasno, čas za dokončanje projekta pa je pogosto presegel rok.

Vendar je bil v projekt spletnih izpitov vključen predan Scrum Master. Za projektna vprašanja in izzive je poskrbel Scrum Master. Pripravljena so bila poročila o projektu / sprintu in ekipa je lahko videla njihov napredek.

Prav tako so za vsak sprint potekali ustrezni sestanki za načrtovanje sprintov in retrospektivni sestanki sprinta, ki so izboljšali delovanje ekipe. Ekipa se je osredotočila le na svoje delo in izpolnjevanje nalog, določenih za ta sprint. Vsa dodatna gospodinjstva je vodil Scrum Master.

# 4. Pretvorba projektnih dokumentov v zaostanek izdelka:

Začetni projektni dokumenti, ki so pripravljeni v modelu slapa, so specifikacija poslovnih zahtev (BRS), oblikovanje na visoki ravni, funkcionalno načrtovanje itd. Te dokumente je treba pretvoriti v zaostanek izdelkov, da se izvedejo faze kodiranja, preskušanja in izvedbe. v agilnem načinu. To je zelo pomemben korak.

Zaostanek izdelkov je izhodišče agilnega projekta. Zaostanek izdelka je prednostni seznam zahtev, ki se vodi za izdelek. Sestavljen je iz funkcij, popravkov napak, nefunkcionalnih zahtev itd. Je vse večji dokument, ki postaja večji in boljši na podlagi povratnih informacij strank, spreminjanja zahtev itd.

Ker je prvi artefakt katerega koli projekta, je najpomembneje, da naštejemo zahteve in jim dodelimo prednostne naloge. Pretvorba projektnih dokumentov slapa v zaostanke izdelkov je sama po sebi velika naloga in zahteva pametno oživitev celotne ekipe skupaj s stranko / deležnikom.

Ko so stranke navedene in soglašane z vsemi zahtevami, je naslednja naloga določiti prednostne naloge, da jih lahko poberejo v sprintih.

# 5. Matrika sledljivosti:

Drug pomemben artefakt, ki se običajno ohranja v modelu slapa, je matrika sledljivosti. Torej, da zagotovimo, da nobena zahteva ne bo zamujena; treba je oblikovati in vzdrževati tudi matriko sledljivosti . Običajno takšna matrica ni zasnovana v agilnih sistemih.

To je najboljša praksa v katerem koli projektu. Vzporedno z zaostanki izdelka je treba pripraviti matriko sledljivosti. In preveriti bi ga bilo treba med testnimi primeri, izvedenimi med uporabniškim sprejemnim preskusom / preskušanjem od konca do konca (ta stopnja je razložena v naslednji točki). Tudi če se katera koli zahteva zamudi, jo je mogoče enostavno vključiti tudi v poznih fazah razvoja, saj okretnost zagotavlja dodatno prilagodljivost in prilagodljivost.

Ko je projekt spletnih registracij začel delovati, so aplikacijo dostopali končni uporabniki (študentje, ki so se želeli registrirati). V prijavi so se soočili z veliko težavami. Rezultat tega je bilo veliko vstopnic, zbranih za ekipo za podporo produkciji. Dvignjene vstopnice lahko označimo kot incidente, težave ali spremembe. Rešenih je bilo veliko vprašanj, ki predvidevajo, da bo aplikacija postala stabilna. Toda tudi takrat je bilo v naslednjih izdajah načrtovanih več kot ducat zahtev / izboljšav za spremembe. Te izboljšave naj bi stabilizirale aplikacijo in izboljšale izkušnjo končnega uporabnika.

Na koncu so se stroški projekta povečali za večkrat. Če torej projekt ni pravilno prestavljen na agilnega, lahko proračun preseže. To je nujno za načrtovanje temeljitega prehoda projekta na Agile. Prav tako je treba načrtovanje izvesti v obsegu, ki ga potrebuje projekt, da se izvede v gibčnem načinu. Za določen projekt je treba oblikovati ustrezne hibridne modele.

Pred začetkom projekta za prijavo na izpit je bilo za ta vidik dobro poskrbljeno. Zamislili smo hibridni model in odločili smo se, da bomo fazo analize zahtev in fazo načrtovanja na visoki ravni izvedli v modelu slapa, ostale faze pa v agilnem modelu.

Sprejeti hibridni model lahko slikovito predstavimo spodaj:

Skupni (hibridni) model 3

Zaključek:

Očitno je, da imata model Slap in model Agile svoje pomanjkljivosti. Zato je povsem realno, da se odločimo za hibridni model, ki je pristop k njemu izkoriščanje najboljšega iz obeh svetov.

Najpomembnejši vidik začetka katerega koli projekta je odločitev o modelu, ki ga bo ekipa sprejela. To zahteva obsežno načrtovanje. Pri sprejemanju programskega modela je treba upoštevati dejavnike, kot so proračun, čas, poraba virov, zapletenost zahtev itd.

Hibridni model je še vedno v nastajajoči fazi. Ker ga bo sprejemalo vedno več podjetij, bomo o tem konceptu izvedeli več.

Manifest Agile nas prosi, da ocenimo:

  • Posamezniki in interakcije nad procesi in orodji
  • Delovna programska oprema obsežno dokumentacijo
  • Sodelovanje s strankami čez pogajanja o pogodbi
  • Odziv na spremembe nad sledenjem načrtu

Hibridni model pa se teh 100% ne drži. Predlaga, da so vsi vidiki enako pomembni. Naročniki / vodje projektov se morajo odločiti, katere vidike bodo bolj cenili in katere nevredne.

O avtorju: To je članek gosta avtorja Harshpal Singh. Ima 7+ let izkušenj z ročnimi, zbirkami podatkov, avtomatizacijo in preizkušanjem zmogljivosti in trenutno dela kot vodja ekipe v vodilnem MNC. Delal je na številnih projektih za zagotavljanje kakovosti po modelih slapa, gibčnosti in hibridnega razvoja.

Ali imate izkušnje z delom na tem hibridnem modelu za razvoj in testiranje? Pogovorimo se v komentarjih.

Priporočeno branje

^