SDLC Guide - Softwareudvikling Livscyklusfaser og -metoder

Da jeg besluttede at lære mig selv at kode for næsten fire år siden, havde jeg aldrig hørt om, endsige tænkt på, livscyklus for softwareudvikling.

Som en helt ny udvikler var jeg fokuseret på at lære de teknologier, der ville hjælpe mig med at lande det eftertragtede første udviklerjob, ikke nuancerne i, hvordan disse hold fungerede.

Da jeg lærte om dem, troede jeg, at de ville være ubrugelige for mig, fordi jeg betragtede mig selv som en webudvikler ikke en softwareudvikler.

Jeg har siden lært, at dette ikke kunne være længere væk fra sandheden, og disse principper / praksis spiller en stor rolle i mine daglige aktiviteter (hvad enten jeg er klar over det eller ej).

Jeg er heldig nok til at se, hvordan den kode, jeg skriver, de funktioner, jeg bygger, og de fejl, som jeg utilsigtet introducerer (mere end jeg bryder mig om at indrømme) påvirker slutbrugeren og deres oplevelse. Denne erfaring har været med til at forme, hvordan jeg tænker på processen med at opbygge produkter og løse problemer for mine brugere.

Jeg har haft lidt tid til at tænke over forskellene (og lighederne), som hver af disse tilgange tilbyder. I deres kerne er hver især fokuseret på at levere software af høj kvalitet så effektivt og så omkostningseffektivt som muligt.

Professionelt har jeg kun brugt en eller to af disse metoder. Men jeg finder stadig værdi i mindst en grundlæggende forståelse af dem alle.

Alle disse metoder følger en række faser svarende til dette diagram:

Så her er softwareudviklingens livscyklusmetoder (i ingen særlig rækkefølge):

  • Læne
  • Adræt
  • Vandfald
  • Iterativ
  • Spiralformet
  • Dev Ops

Lad os grave ind i forskellene og lighederne for hver metode.

Læne

Lean-metoden er stærkt afhængig af og består af syv principper.

I ingen specifik rækkefølge er de:

  1. Fjern affald
  2. Forstær læring
  3. Beslut så sent som muligt
  4. Lever så hurtigt som muligt
  5. Giv holdet styrke
  6. Byg integritet
  7. Se / Optimer det hele

Hvert princip har et specifikt formål med fordele, der komplimenterer hinanden.

Fjernelse af spild (ekstra funktioner, ufuldstændigt arbejde, ledelsesmæssige engagementer osv.) Skaber mere værdi for kunden, hvilket igen øger tilfredsheden.

Forstærkende læring giver hold mulighed for at geninvestere i deres evne til at levere produkter til kunder.

At beslutte så sent som muligt henviser til alle større beslutninger, hvilket giver holdene en valgbaseret eller en sætbaseret tilgang. Dette giver hold mulighed for at samle fakta snarere end meninger for at hjælpe med at påvirke beslutninger, når de træffes.

At levere så hurtigt som muligt er selvforklarende - bygg produktet så hurtigt som muligt for at levere det til kunderne til evaluering / iteration.

I et typisk scenario uddeler lederne opgaver / arbejde til udviklerne. I Lean-metoden lærer udviklere "ledere", hvordan man lytter til "folk i skyttegravene" og påvirker således ledelsens beslutninger / valg.

Dette hjælper holdene med at føle sig mere bemyndigede til at tale om ider og løsninger.

At gøre integritet til en regel i stedet for en undtagelse betyder, at kunden er fortrolig med det system, der bygges. Kunden ved, at systemet er bygget til at modstå den passende mængde vækst og "strækning", hvis det er nødvendigt.

Jeg kan godt lide at tænke på integritetsdelen i samme retning som at sidde i en stol. Når du sidder i stolen, tror du, at den var konstrueret med det bedste materiale, der holder dig op, hver gang du sidder i den hele stolens levetid. Kunden har brug for den samme tillid til det produkt, der bygges.

Endelig henviser og ser og optimering af hele til hele systemet, der bygges. Ved at optimere for helheden ser vi ikke på software som en sum af mange komponenter, men som en stor enhed, der er optimeret til effektivitet.

Dette betyder, at produktet under udvikling er opdelt i håndterbare stykker, og at utilsigtede fejl ikke kun opdages, men løses hurtigt.

Adræt

Dette er den "fail hurtigt" tilgang til bygning af software.

Det lægger vægt på små, trinvise frigivelser med løbende frigivelsescyklusser. Med hver iteration stræber teams efter at identificere og løse små problemer, før de bliver store problemer.

Dette betyder også, at holdene skal engagere interessenter (personer / organisationer, som koden i sidste ende kan påvirke som ledere, tekniske kundeemner, CTO'er og kunder) for at få deres feedback.

Hvis du er freelance, vil dine interessenter være dine kunder - i sidste ende skal du sikre deres tilfredshed med arbejdet, inden du går videre.

Agile er teknisk set et udløb for Lean-metoden med nogle bemærkelsesværdige forskelle - primært prioriterer det kundetilfredshed fra starten og giver holdene mulighed for at reagere hurtigt på kundefeedback.

Selvom det ligger uden for denne artikels anvendelsesområde, er der en anden mere kompleks ramme inden for Agile, der kaldes SCRUM. Denne metode bruges til store, ekstremt komplekse projekter og er endda blevet brugt uden for softwareudvikling.

Vandfald

Vandfaldsmetoden er af de fleste konti den ældste på listen. Det var aldrig meningen, at det skulle være en model til softwareudvikling og fik sin start i bygge- og produktionsverdenen.

Denne tilgang er enkel i sin struktur - afslut alle dele af en fase, inden du går videre til den næste fase med mere momentum, der bygger op mod projektets afslutning, når etaper er afsluttet. Begyndelsen af ​​hvert trin (med undtagelse af det første) og afslutningen er betinget af, at det forrige trin er færdiggjort / overført information.

Under vandfaldstilgangen har hvert trin sin egen stive projektplan, der afsluttes med test for tidligere afsluttet arbejde. Det skal bemærkes, at denne fremgangsmåde ikke anbefales til større / længerevarende projekter på grund af den ovennævnte stivhed.

Tænk på oprindelsen af ​​denne metode, og du vil forstå det mere. Det kom fra bygge- / fremstillingsverdenen, hvor det er almindeligt at gennemføre en fase ad gangen. Under opførelsen af ​​et hus vil du ikke begynde at lægge VVS inden rammen er sat op.

Sådan fungerer softwareudvikling generelt ikke. Som vi alle ved, bliver det nogle gange nødvendigt at revidere en fase, som man tidligere troede var afsluttet.

Iterativ

Dette er kendt som den "gentagne tilgang" eller "gør det bedre næste gang rundt" tilgang på grund af de forskellige muligheder, det giver for at forbedre produktet med hver cyklus iteration.

Jeg er partisk (som vi alle er: D), men dette er tilfældigvis min foretrukne livscyklus til udvikling. Jeg tror, ​​det fungerer bedst for min nuværende situation både i min freelance- og karrierevej, fordi det giver mig mulighed for konstant "at komme videre, mens jeg gør tingene bedre."

Med den iterative tilgang implementerer teams en løsning, tester løsningen, evaluerer dens effektivitet / gennemstrømning og fastlægger derefter yderligere forbedringsområder. Dette sker for hver cyklus (iteration) af udviklingsprocessen.

Med hver frigivet version kommer en anden iteration, indtil det endelige produkt er afsluttet og klar til implementering til brugerne.

En af de store træk ved den iterative tilgang er, at du og dit team får en fungerende version af software tidligt i udviklingsprocessen. Dette kan være særligt nyttigt at vise interessenter at måle deres svar / feedback.

En af de store ulemper ved denne tilgang er, at den kan forbruge en stor mængde ressourcer meget hurtigt. Forestil dig alle de mennesker, timer, fejlrettelser og lønninger, der går ind i hver iteration af udviklingscyklussen, og du får et godt billede af ressourceforbruget.

Inden for denne tilgang er en delmængde af principper udviklet af Rational Software Corporation (købt af IBM) kaldet Rational Unified Process (RUP), som består af 4 faser:

  • Start
  • Udarbejdelse
  • Konstruktion
  • Overgang (produktudgivelse)

Dette sæt principper er beregnet til at være fleksibelt og skræddersyet til hvert teams behov, der bruger det.

Spiralformet

Spiralmetoden er sandsynligvis den mest fleksible ud af de seks. Det er en metode, der bygger på risici - identificere og negere dem. Risiko (identifikation og aversion) styrer enhver beslutning i denne model. Det er opdelt i fire underfaser:

  • Planlægning (mål)
  • Risikoanalyse (identificer mulige vejspærringer)
  • Udvikling og test (nuværende og næste version)
  • Evaluering (gennemgang af nuværende fase & plan for næste fase)

Hver iteration af hver fase begynder med planlægning af den næste fase. På denne måde identificeres potentielle risici, inden de støder på. Dette giver også mulighed for en handlingsplan, når de nævnte risici opstår.

I faser arbejder teams også på at afbøde disse risici og deres indvirkning på fremtidige gentagelser af spiraludviklingen.

Efterhånden som udviklingsprocessen fortsætter, gentages hver af disse fire underfaser i spiralform. Dette giver mulighed for flere raffineringsrunder for hver underfase indtil afslutning.

Dev Ops

Hvis du foretager en hurtig søgning, vil du ikke finde mangel på information om denne udviklingslivscyklusmetode. Det er det nye barn på blokken, der bringer softwareudvikling og informationsteknologidriftsteam i samme fold.

Disse hold arbejder sammen om at levere små, men effektive, opdateringer til produkter, der kommer i et hyppigt tempo. Til gengæld skaber dette en kontinuerlig feedback- og forbedringsløkke, der driver udvikling.

Denne særlige metode er også kendt for at automatisere de manuelle dele af udviklingen (tænk implementering).

Det overordnede mål med denne metode er som de fleste andre at forkorte udviklingslivscyklussen og levere kvalitetsprodukter.

En af ulemperne ved denne metode er de vigtige tankegang og kulturændringer inden for en organisation. Hold, der måske har været vant til at arbejde på mange ting, finder deres opgaver indsnævret til kun en eller to.

For eksempel kan en generel udvikler måske finde ud af, at de nu kun får til opgave at teste delen eller slutbrugerens oplevelsesdel.

At bringe det hele hjem

Jeg håber, du nu kan se vigtigheden og fordelene ved hver af disse metoder. Hver af disse har deres egne styrker og svagheder.

De er på deres mest basale niveau et sæt retningslinjer og principper, der søger at levere højt, effektivt arbejde til interessenter.

Da jeg først begyndte at lære at kode, havde jeg ikke en mentor. Ved at dele det, jeg har lært, håber jeg at hjælpe dem, der lærer at kode, når / hvor de kan.

Jeg vil dele så meget information og erfaring som jeg overhovedet kan med andre udviklere. Hvis du lærer dig selv at kode, eller hvis du er en erfaren udvikler, håber jeg, at denne artikel hjælper, selvom det er lille.

Tjek min blog, hvor jeg ofte skriver artikler om webudvikling.

Mens du er der, hvorfor ikke tilmelde dig mit nyhedsbrev? Du kan gøre det øverst til højre på hovedblogsiden. Jeg kan godt lide at sende interessante artikler (mine og andre), ressourcer og værktøjer til udviklere i ny og næ.

Hvis du har spørgsmål om denne artikel eller bare generelt, er mine DM'er åbne - kom og sig hej på Twitter eller nogen af ​​mine andre sociale mediekonti, som du kan finde under nyhedsbrevet, tilmeld dig på hovedsiden eller på min profil her :)

Hav en fantastisk dag og god kodning, ven!