Kaskadutveckling. När är det optimalt att använda en iterativ modell? Vattenfall är en projektledningsteknik som innebär en sekventiell övergång från ett steg till ett annat utan att hoppa över eller återgå till tidigare steg.

En startup är ett projekt. Och när man gör ett projekt uppstår alltid frågan: hur man genomför det, hur man organiserar ett team. Kvaliteten på produkten och deadlines för färdigställande beror på metoden med vilken uppstarten implementeras.

Varför behövs metodik? Bara ta det och gör det!

Du föreställer dig ungefär din idé, ungefär tidsramen och vad som ska hända som ett resultat. Men "ungefär" är kaos.

Men i ett seriöst projekt som förväntar sig framgång ska det inte bli något kaos.

Metodiken strukturerar sinnet, teamet och bildar en tydlig bild. Du ser i vilket skede projektet är, vart det rör sig och vilket steg du ska ta härnäst.

Vi blev övertygade om att vi behövde ordning och reda. Allt som återstår är att välja vilken metod som ska väljas.

Som vi meddelade i titeln kommer striden att äga rum mellan Agile och Waterfall. Låt oss omedelbart notera att det inte finns något definitivt svar; valet beror på projektet.

Men vi kan prata om fördelar och nackdelar :)

Vattenfall

Vattenfall strukturerar tydligt utvecklingen av projektet vi har en plan som består av etapper. Efter dem får vi slutprodukten:

Produktidé

Det är med en idé som lyser upp över ditt huvud som en glödlampa som en start startar. Du måste tydligt förstå vilket budskap du förmedlar målgrupp och vilka mål du sätter upp för dig själv. Detta disciplinerar dig och skapar en vision för slutresultatet.

Initiering

Vi samlar ett team, fördelar tekniska uppgifter, deadlines och fördelar affärsansvar på papper eller ett speciellt program (ERP).

Analys

Vi letar efter det bästa sättet att implementera idén, undersöker marknaden och konkurrenter och förstår vem som är målgruppen.

Tack vare denna analys omvandlas idén, element som inte kommer att efterfrågas försvinner, och i deras ställe kommer nya funktioner in som är nödvändiga för implementering.

I Waterfall skiljer sig denna process åt. Hela designen och gränssnittet (frontend) utvecklas när mjukvarans innehåll är okänt (backend).

Utveckling

I detta skede kodar vi i sin helhet. Utvecklare anpassar sig till gränssnittet som designarna skapade och fyller det med nödvändig funktionalitet.

Testning

Vi blir av med buggar så att den perfekta produkten når våra kunder.

Produktlansering

Vi tar ut projektet på marknaden, lanserar marknadsföring och ser till att hela världen känner till produkten! (åtminstone målgruppen)

Utnyttjande

De första kunderna dyker upp som besöker sajten, köper en produkt eller laddar ner en applikation – beroende på uppstart.

Vattenfalls struktur är väldigt enkel, alla stadier följer varandra och vi vet vilket steg vi tar härnäst.

Vig

Agile är en flexibel utvecklingsmetodik. Teamet har inga strikta stadier de är alla sammankopplade och upprepade:

Projektet är uppdelat i iterationer - cykler. Var och en av dem involverar planering, analys, design, utveckling och testning.

Iterationer är uppdelade i sprints - 1 eller två veckor, för vilka varje lagmedlem har ett paket med uppgifter. Varje dag träffas teamet för genomgångar, sätter upp dagliga mål och rapporterar om föregående dags prestationer.

Designers är inte isolerade, de kommunicerar ständigt med utvecklare och testare, uppdaterar gränssnittet för maximal kvalitet och användbarhet för framtida kunder. Analysen genomförs kontinuerligt med samma mål.

Hela processen visar sig vara så flexibel som möjligt efter varje iteration får teamet en potentiellt fungerande produkt, som det analyserar och kan förbättra.

Låt oss titta på fördelarna och nackdelarna med båda metoderna:

Trots att noggrann planering är ett stort plus (alla uppskattningar, koncept, budgetar görs, risker är utarbetade) visar det sig för många projekt vara ett minus. Det första steget tar mycket tid och resurser att göra i processen. Samma situation uppstår med en enorm mängd dokumentation.

På grund av isoleringen av alla stadier är det inte möjligt att ändra något i utveckling och design. Programmerare tvingas anpassa sig till ett redan existerande gränssnitt. Kunden känner inte till sitt projekt förrän i testskedet, då det är för sent att göra ändringar.

Till skillnad från Waterfall är alla processer i Agile oskiljbara. Alla fel som testaren hittar korrigeras omedelbart av programmeraren, och gränssnittet kan ändras.

Agile har en stark tonvikt på produktkvalitet, och det förbättras och anpassas genom hela processen.

Ett stort plus med Agile är att kunden är fördjupad i projektet, han kan när som helst kontrollera hur arbetet går, delta i möten med teamet i slutet av iterationen och föreslå förändringar.

För att arbeta agilt måste du vara medveten om utmaningarna och veta hur du ska hantera dem:

• du måste vara helt delaktig i processerna för att inte bli förvirrad eftersom de alla sker samtidigt. I jakten på förbättringar, glöm inte kundens initiala krav.
• Tilldela inte för många uppgifter till en sprint, detta kommer att försämra kvaliteten på arbetet. Dela upp en stor uppgift i flera små.

När du väljer metod ska du vägledas av de principer som är viktigare för projektet. Vattenfall är bra när man har en fast kravlista och en tydlig vision av slutprodukten. Agile är fokuserat på branscher där standarder ständigt förändras och ny teknik växer fram. Och du kan anpassa dig till dem mitt i processen.

Till exempel utvecklas IT-sektorn ständigt, nya trender dyker upp och med hjälp av Agile gör Artjoker ett fantastiskt jobb med startups!

Idag ska vi fördjupa oss i ämnet och prata om de verktyg som en chef använder i sitt arbete.

Till bokmärken

Metodik

Metod i projektledning är standardisering av projektgenomförande. Standardisering betyder här en beskrivning av arbetsstegen, checklistor för verifiering - en slags disposition som du kan kasta ett projekt i, och under överinseende av en chef kommer det att segla till slutförandet och den färdiga produkten. Eftersom varje projekt är unikt i en eller annan grad, är metodiken inte ett universalmedel som du fortfarande behöver tänka på.

Det finns en mängd olika projektledningsmetoder - de kan bara användas i ett företag, eller så kan de vara globala. Metoder kommer i form av verktyg (som Agile), de kommer i form stor bok med en uppsättning av dessa verktyg (PMBoK, även en metodik).

I mitt liv har jag använt och fortsätter att använda två av de mest populära metoderna - Vattenfall ("vattenfall" / "kaskad") och Agile (och dess utlöpare - Scrum), som kommer att diskuteras. För att vidga läsarens vyer ska jag berätta om andra saker jag vet. Om läsaren arbetar med digitala, så kommer "vattenfall" och "kant" att räcka för ögonen - du kan använda dem på jobbet, i livet, berätta för vänner och främlingar, på möten, medan du dricker en smoothie med en smart look.

Varifrån kom metoderna?

Naturligtvis kommer ingenting någonstans ifrån, och Peter den store hade inte hört något om agile. Metoder uppfinns av alla möjliga olika organisationer och föreningar, där smarta killar samlar sina problem i högar, sedan förstår hur de kunde ha undvikits och sedan delar lösningar med vanliga människor som jag till exempel. Ibland är metoder genomtänkta på statlig nivå - de löser också problem och samlar in bästa praxis (i det artiga samhället, uttryck det inte så) i böcker och manualer.

Agile och vattenfall

Idag kommer vi främst att prata om dessa två djur. Efter att ha läst detta avsnitt kan du tryggt gå och kräva den coolaste tjänsten som projektledare i den största lämpliga organisationen i staden.

Vattenfall

Vattenfall, kaskadmetod är den traditionella, mest populära och logiska projektledningsmetoden. I sin rena form kan den fungera i mycket enkla projekt. Låt oss säga att du behövde plantera ett träd. "By vattenfall" ser genomförandet av projektet ut så här:

• Köp en planta
• Gräva ett hål
• Placera en planta i den
• Strö över jord
• Vattna trädet

Varje steg i ett sådant projekt följer det föregående och kan inte slutföras före det föregående - det här är ett "vattenfall". Detta överlappar också med den "kritiska vägmetoden", men jag kommer att prata om det i en separat artikel - påminn mig.

Jag arbetar med projekt inom området webb- och mobilapplikationsutveckling. Utvecklingsstadierna för sådana vattenfallsprojekt är ungefär desamma:

• Skriva teknisk uppgift
• Rita en design
• Sminka designen
• Koda
• Testa
• Starta projektet

För att röra dig längs vattenfallet behöver du ha en tydlig teknisk specifikation och förståelse för stegen som följer på varandra. Från praktiken kommer jag att säga att det är orealistiskt att arbeta efter ett rent vattenfall - någonstans visar det sig alltid att något har missats, någonstans måste du rulla tillbaka till föregående steg och göra det parallellt med det nuvarande skedet. Men ju tydligare den tekniska specifikationen är, desto mindre sannolikt är det att projektet går åt sidan. För projekt där det är acceptabelt att "gå åt sidan" finns Agile.

Vig

"Agil" (eller "agile", eller "vad synd" - han har mycket coola namn) tillhör typen agil metodik. Dess huvudsakliga skillnad mot ett vattenfall är arbetsprodukten i varje skede av arbetet och den oklara finalen av projektet. I exemplet med samma träd, där varje steg är sekventiellt, kommer denna smidiga inte att fungera: ja, du köpte en planta, men vad är poängen? Agile har ett ganska brett utbud av applikationer, men mest av allt har det slagit rot inom IT. Och dess typer och undertyper täckte de angränsande områdena med en tjock film - affärsplanering, produktledning och så vidare och så vidare.

Som ett exempel på att arbeta "agilt", låt oss föreställa oss ett mer komplext projekt. Låt detta vara ett byggprojekt. Uppgift: bygga ett hus där du kan bo.

Produktionsstadier (låt oss föreställa oss att varje etapp tar exakt en sprint):

• Bygg en låda med väggar och tak
• Bygg ett tak och täck väggarna med gips
• Installera dörrar och fönster i huset
• Tillhandahålla el, vatten, avlopp
• Lägg laminatgolv och tapeter
• Ta med möbler och tv
• Släpp in katten

Vattenfall eller smidig?

Ingen metod är ett universalmedel. Den närmaste analogin jag kan dra är med checklistor - det här är en så cool sak (läs @salakhmir) som hjälper mycket i arbetet, men av någon anledning fungerar det inte för alla. Alla verktyg är bara ett verktyg och fungerar inte på egen hand. Föreställ dig att du lägger en spade på marken och väntar på att något ska hända - så här, för att något ska hända, måste du göra något.

Jag använder mig främst av en hybridmetodik (både vattenfall och agilt), där det finns en teknisk specifikation, stadierna är tydliga, men avvikelser förekommer under projektets gång. Utifrån kan det tyckas att kaos håller på att hända, huvudsaken är att sätta på sig ett show-off ansikte – allt går enligt plan. Avvikelser går ofta in i separata projekt, men oftare stannar de inom det nuvarande och leder till en ökning av tiden (budgeten) för projektet. Detta verkar dåligt, men inslaget av politik i att arbeta med människor (vi jobbar med människor, inte webbsidor, minns du?) kan inte uteslutas.

Metodikhanteringsorganisationer

Dessa organisationer sköter för det mesta utvecklingen av metoder – de är utvecklade av samma chefer som du en dag kommer att bli. Det finns inte många av dem i världen, men de är alla oerhört viktiga - för pengar och tid kan du få deras diplom och gå på intervjuer, vilket imponerar på intervjuarna.

PMI

Project Management Institute är vår vän. Jag har en speciell tillgivenhet för den här organisationen - de har en kraftfull gemenskap och en bra bas. Organisationen är baserad i USA, har funnits sedan 1969, och deras projektledningsstandarder är erkända av ANSI.

Huvudprodukten av PMI är kunskapsmassan om projektledning PBoK, den sjätte delen publicerades hösten 2017. Kunskapsmassan innehåller skisser av projektgenomförande i detalj - från insamling av intressentkrav till projektavslutning. Jag rekommenderar åtminstone att läsa boken - i den kan du läsa om vattenfall med agile, och om den kritiska vägmetoden och snabbpassmetoden - ämnena i en av mina framtida artiklar.

Utöver PMBoK har PMI följande grundläggande saker: portfölj- (projekt)- och programledningsstandarder, riskhanteringsstandarder och Scrum-guiden. PMBoK är ingen IT-bok, metoderna från koden är tillämpliga på praktiskt taget alla projekt (för vissa typer finns det separata tillägg) - ett måste i allmänhet.

PMI har ett gäng olika typer av certifieringar, med steg och ringsignaler. PMI-certifieringar är välkända och populära. Till exempel, PMP – projektledningsprofessionell – bekräftar liksom att man kan hantera projekt. Det är omöjligt att få organisationsbevis utan erfarenhet, eftersom de är mer som bekräftelse än som ditt universitetsexamen som du fick när du studerade.

IPMA

International Project Management Association är samma organisation som PMI, endast europeisk (Schweiz), och det hörs mindre om det. Det har funnits sedan 1965 och hette ursprungligen Internet (när det inte fanns några spår av Internet).

Vad de gör där är inte klart. Jo, de certifierar chefer. De ger ut sina egna tidningar – själva och under representationskontor. De tjänar pengar. Och ära till G-d.

PRINS2

"Prince" (PROjects IN Controlled Environments). Metodiken dök upp 1989 i Storbritannien (och separerades sedan). En nyckelfunktion i metodiken är den nytta som processerna inom projektet kommer att tillföra projektet. Minimera risker, bibehålla projektkvalitet. PRINCE2-projekt har också svårt organisationsstruktur med projektkommittén. Annars har sådana projekt, liksom projekt som använder andra metoder, en start, stadier och avslutningar - allt är bekant och bekant.

P2M

"En guidebok för projekt- och programledning för företagsinnovation." Japansk projektledningsmetod är färsk den här gången, den är från 1999. Nyckeln här är betoningen på innovation och hantering av intressenternas förväntningar. Jag har inte stött på det på nära håll, jag har inte studerat det, jag kan inte ge en bedömning.

Microsoft Solutions Framework

Den "proprietära" projektledningsmetoden, MSF, uppfanns och introducerades 1994 av Microsoft. Den är speciell genom att den utvecklades direkt för utvecklingen programvara, och anpassade sig inte, vilket kan sägas om samma PMBoK. Utåt ser det ut som en lista med interna rekommendationer (som den i ditt intro) för projektledare. Inte ens Microsoft används i sin rena form – de lägger till till exempel samma agila. Wikipedia har en informativ artikel om detta ramverk, gå dit - det finns mer där än jag kan berätta för dig.

Sammanfattning

Ingenting är ett universalmedel, men det är möjligt och nödvändigt att förstå principerna och ta det bästa ur dem. Medan jag skrev artikeln kom jag i ögonvrån på en artikel om Stakhanov - det fanns en sådan kille under sovjeterna, han användes i sovjetisk produktivitetspropaganda. Han arbetade också enligt metodiken (han bröt kol), men en dag insåg han att om han ordnade om folk lite och startade några processer parallellt så kunde han jobba bättre. Så jag skaffade mig en sida på Wikipedia. Det är samma sak här – testa, tillämpa och förbättra (dela sedan). Allt du möter, alla råd, är en hypotes som måste testas. Njut av det!

I nästa del ska jag försöka prata om planeringsuppgifter och tid, inklusive min egen mikrohantering. Artikeln ska hjälpa inte bara nybörjare utan även de som arbetar med dem. Om du har tillräckligt med passion kommer artikeln att publiceras denna vecka. Skriva brev.

Det är nödvändigt att ha en god förståelse för de grundläggande principerna livscykel Mjukvara, kundkrav för produkten som skapas, och även ta hänsyn till det ekonomiska möjligheter.. Det finns flera livscykelmodeller (vattenfallsmodell, spiralmodell, rapid prototyping, etc.). Valet av en viss livscykelmodell beror huvudsakligen på projektets innehåll och mål, samt på storleken på finansieringen.

Vi föredrar generellt spiralmodellen, som innehåller flexibla utvecklingsmetoder som kallas Agile. Men ibland använder vi vattenfallsmodellen (även kallad vattenfallsmodellen) och dess derivator för att slutföra små eller okomplicerade projekt. I den här artikeln kommer vi att beskriva vattenfallsmodellen, som är en klassisk typ av mjukvarulivscykel.

Enligt denna modell genomförs projektet steg för steg, i enlighet med den exakta sekvensen av åtgärder: samla in och studera krav, mjukvarudesign och utveckling, testning och teknisk support. Vattenfallsmodellen är ganska flexibel och vissa stadier kan överlappa varandra.

Låt oss titta på varje skede av livscykeln en efter en:

1. Kravanalys

I detta skede är det viktigt att dokumentera alla krav på framtida programvara. Det är nödvändigt att ägna tillräcklig tid åt att diskutera detaljerna i projektet med alla berörda parter. All inkommande data ska analyseras och systematiseras. Det är också viktigt att ta hänsyn till alla tekniska begränsningar som kan uppstå på kundens sida. Resultatet av detta steg bör vara skapandet av en detaljerad specifikation som uppfyller alla kundkrav. Du bör också vara uppmärksam på andra faktorer som kan komplicera utvecklingsprocessen. Dessa inkluderar deadlines som kunden fastställt, samt budgetrestriktioner.

Observera: Ju mer information du samlar in om projektet, desto mindre tid kommer du att lägga på att rätta fel, slutföra projektet, revidera budgeten, diskutera och lösa andra frågor.

Projektvision

En viktig uppgift är att skapa en detaljerad projektvisionsdokument (eller bild) vilket ingår kort beskrivning projekt, affärsmål, samt projektframgångskriterier, affärsriskfaktorer och en beskrivning av produktens slutanvändare.

Det färdiga dokumentet ska lämnas till kunden för godkännande för att säkerställa att alla krav har beaktats, och även för att informera denne om eventuella risker som kan uppstå efter att projektet släppts.

Samlingskrav

När alla större frågor har lösts rekommenderas det att ytterligare diskussioner och interaktiva workshops hålls med alla intressenter. Detta kommer att hjälpa till att identifiera alla icke-uppenbara punkter som senare kan orsaka ändringar i applikationsgränssnittet eller behovet av att skriva om kodmönster. Detta steg kan också innefatta att fylla i frågeformulär, granska ärenden, brainstorming etc.

Många projekt stannar på grund av ytterligare krav som dyker upp under utvecklingsstadiet. Därför är det mycket viktigt att förstå de initiala affärsmålen och huvudtanken framtida ansökan.

2. Mjukvarudesign

Nästa steg i mjukvarans livscykel är skapandet av ett dokument som beskriver projektets omfattning och gränser. Detta dokument innehåller mockups eller skisser av gränssnittet för den framtida applikationen, såväl som en detaljerad specifikation av programvarukrav. Det bör noteras att i vissa fall kan visiondokumentet (bilden) av projektet och dokumentet om projektets omfattning och gränser presenteras som ett enda dokument "Om projektets bild och gränser".

Projektets omfattning och gränser

Dokumentet som beskriver projektets omfattning och gränser bör lista huvudfunktionerna för programvaran som skapas. De bestäms utifrån projektets visionsdokument och givetvis med hänsyn till den angivna tidsramen och fastställda budgeten.
Dessutom innehåller detta dokument mockups eller skisser skapade utifrån projektets visionsdokument samt de insamlade kraven.
Du kan rita en skiss av användargränssnittet för hand eller använda mockup-program för detta och sedan komma överens om det med kunden. Nedan är en lista över användbara program för att skapa mockups som vi använder i praktiken:

Under diskussionen om projektet kan kunden få fler och fler nya idéer om dess genomförande. Därför rekommenderas det att ge honom tid att tänka på sitt projekt och dess krav, och sedan åter sammankallas och diskutera detaljerna i projektet så att ingenting förbises.
I detta skede uppstår också frågan om eftermarknadsservice för produkten. Du måste meddela kunden hur teknisk support kommer att tillhandahållas efter avslutad testfas och efterföljande lansering av produkten.
Observera att ett projektvisionsdokument och ett projektomfattningsdokument måste skapas innan kontraktet undertecknas.

Programvarukravspecifikation

En mjukvarukravsspecifikation (SRS) beskriver de krav som mjukvaran som byggs måste uppfylla. Det ska vara logiskt, konsekvent, tillgängligt och komplett. Krav kan uttryckas i olika former, till exempel i form av traditionella måste-uttalanden (till exempel "The Staff Manager-systemet måste stödja följande webbläsare: Google Chrome, Apple Safari, Mozilla Firefox, Opera, IE 8+") eller i form av användarberättelser (t.ex. "eftersom jag är chef behöver jag tillgång till personlig information alla anställda").
Det finns ett stort antal specifikationsmallar. Valet av en specifik mall beror på projektets detaljer. I de flesta fall innehåller specifikationen en beskrivning av produkten, användarklasser, funktionella och icke-funktionella krav på programvaran som utvecklas. Ibland innehåller mallen även en prototyp. Det viktigaste är att göra specifikationen tydlig, koncis och användbar för utvecklare.

För att skapa en prototyp måste du ta reda på följande:

• en metod för att ta emot och bearbeta inkommande data för att skapa nödvändiga utdata;
• i vilken form resultatet ska presenteras.

Mockups (eller prototyper) överlämnas till UI/UX-designers som förvandlar dem till färgglada mallar.

3. Mjukvaruutveckling

Det bör noteras att mjukvaruutveckling också kan innefatta skapandet av en interaktiv prototyp, som i huvudsak är grunden för den framtida applikationen. En sådan prototyp hjälper till att definiera arkitekturen för systemet som helhet. I detta skede skrivs lite kod: till exempel knappkod och enkla former för att ge kunden en allmän uppfattning om hur slutprodukten kommer att prestera. Därför inkluderade vi prototyper i mjukvaruutvecklingsfasen.

När den interaktiva prototypen och applikationsdesignen är klar och godkänd av kunden påbörjas utvecklingen av applikationsstandarder (namnkonventioner, metod för att dokumentera kod, instruktioner för slutanvändaren etc.). Efter detta kan du säkert gå vidare till nästa steg i livscykeln, nämligen mjukvaruutveckling. Mjukvaruutveckling kan delas upp i små delar, eller enheter, och varje enhet utvecklas och testas av utvecklare för att verifiera dess funktionalitet (enhetstestning).

4. Programvarutestning

När utvecklingsfasen är avslutad måste produkten genomgå rigorösa tester för att säkerställa att den uppfyller de specificerade kraven. Acceptanstestning kräver att kunden försöker använda produkten lokalt på exakt samma sätt som de kommer att använda den efter release. När huvudfelen är korrigerade kan programvaran implementeras. För att korrigera mindre fel kan ett enkelt spårningssystem användas, vilket gör att eventuella defekter kan korrigeras under mjukvaruunderhållsstadiet.

5. Teknisk support för programvara

Efter att produkten har testats och distribuerats på kundens server börjar nästa fas i mjukvaruutvecklingens livscykel, som kallas underhåll eller teknisk support FÖRBI. I allmänhet innebär underhåll att åtgärda mindre buggar som upptäcks i detta skede.
Det är dock möjligt att du måste göra några ändringar i den skapade programvaran, trots alla ansträngningar du har gjort i de tidigare stegen. Kunden kan besluta att göra ändringar i den utvecklade produktens funktionalitet. Därför måste du samla in, beskriva och diskutera nya krav med kunden för att göra nödvändiga ändringar av produkten. I I detta fall, du måste arbeta med ett nytt vattenfallsprojekt, och alla ovanstående steg måste upprepas från början.

Slutsats

Vi tittade på de viktigaste utvecklingsstadierna som krävs för att skapa kvalitetsmjukvara. För att ditt projekt ska bli framgångsrikt är det nödvändigt att diskutera alla krav för den framtida applikationen med den direkta kunden, samt dokumentera i detalj allt arbete som måste utföras i varje utvecklingsstadium.

Kaskadmodellen används nödvändigtvis när man skapar livsuppehållande system som används i militära angelägenheter, rymdutveckling och medicin, till exempel vid utveckling av programvara för flygkontroll, krockkuddesystem, etc. Den kan också användas vid utveckling av små och okomplicerade projekt. Men om på en av inledande skeden Om ett misstag görs finns det en möjlighet att det upptäcks först under utvecklings- eller teststadiet. Därför rekommenderas det att använda denna modell endast om alla krav är mycket tydliga och inte kommer att förändras över tiden.

Den här artikeln utarbetades under ledning av erfarna affärsanalytiker på XB Software.

Följande två flikar ändrar innehållet nedan.

Utveckling mjukvaruprodukt känner till många värdefulla metoder - med andra ord etablerade bästa praxis. Valet beror på projektets detaljer, budgeteringssystemet, subjektiva preferenser och till och med chefens temperament. Artikeln beskriver metoder som vi regelbundet möter på Edison.

1. "Vattenfallsmodell" (kaskadmodell eller "vattenfall")

En av de äldsta, innebär sekventiell passage av etapper, som var och en måste slutföras helt innan nästa börjar. Vattenfallsmodellen gör det enkelt att hantera ett projekt. Tack vare dess styvhet går utvecklingen snabbt, kostnaden och deadline är förutbestämda. Men det här är ett tveeggat svärd. Vattenfallsmodellen ger utmärkta resultat endast i projekt med tydliga och fördefinierade krav och sätt att implementera dem. Det finns inget sätt att ta ett steg tillbaka testningen börjar först efter att utvecklingen är klar eller nästan klar. Produkter utvecklade enligt denna modell utan ett motiverat val kan ha brister (listan över krav kan inte justeras när som helst), som blir kända först i slutet på grund av den strikta sekvensen av åtgärder. Kostnaden för att göra ändringar är hög eftersom det kräver att man väntar tills hela projektet är klart för att initiera det. Den fasta kostnaden uppväger dock ofta nackdelarna med tillvägagångssättet. Det är möjligt att rätta till brister som upptäcks under skapandet och, enligt vår erfarenhet, krävs ett till tre ytterligare avtal till kontraktet med en liten teknisk specifikation.

Med hjälp av vattenfallsmodellen skapade vi många projekt från grunden, inklusive utveckling av endast tekniska specifikationer. Projekt som skrivits om på Habré: medium - , small - .

När ska man använda vattenfallsmetoden?

• Endast när kraven är kända, förstådda och registrerade. Det finns inga motstridiga krav.
• Det finns inga problem med tillgängligheten av programmerare med de kvalifikationer som krävs.
• I relativt små projekt.

2. "V-modell"

Ärvde "steg för steg"-strukturen från kaskadmodellen. Den V-formade modellen är tillämpbar på system där oavbruten drift är särskilt viktig. Till exempel applikationsprogram på kliniker för patientövervakning, integrerad mjukvara för styrmekanismer för akuta krockkuddar i fordon och så vidare. En speciell egenskap hos modellen är att den syftar till att noggrant kontrollera och testa en produkt som redan är i inledningsskedet av designen. Teststeget genomförs samtidigt med motsvarande utvecklingssteg, till exempel skrivs enhetstester under kodning.

Ett exempel på vårt arbete baserat på V-metoden - mobil app för europeiska Mobil operatör, vilket sparar roamingkostnader när du reser. Projektet genomförs enligt en tydlig specifikation, men det inkluderar ett betydande teststeg: gränssnittsbekvämlighet, funktionalitet, belastning och inklusive integration, vilket ska bekräfta att flera komponenter från olika tillverkare samverkar stabilt, stöld av pengar och lån är omöjlig.

När ska man använda V-modellen?

• Om grundlig testning av en produkt krävs, kommer V-modellen att motivera sin inneboende idé: validering och verifiering.
• För små och medelstora projekt där kraven är tydligt definierade och fasta.
• I förhållande till tillgänglighet för ingenjörer med nödvändiga kvalifikationer, särskilt testare.

3. "Inkrementell modell" (inkrementell modell)

Inkrementella modeller används där individuella ändringsförfrågningar är tydliga och enkelt kan formaliseras och implementeras. I våra projekt använde vi den för att skapa DefView-läsaren och sedan nätverket elektroniska bibliotek Vivaldi.

Som ett exempel kommer vi att beskriva essensen av ett steg. ersatt DefView. DefView ansluten till en dokumentserver och kan nu ansluta till många. En lagringsserver installeras på platsen för en institution som vill sända sitt innehåll till en specifik publik, som direkt kommer åt dokument och konverterar dem till önskat format. Rotelementet i arkitekturen har dykt upp - den centrala Vivaldi-servern, som fungerar som en singel sökmotoröver alla lagringsservrar installerade i olika institutioner.

När ska man använda den inkrementella modellen?

• När de grundläggande kraven för systemet är tydligt definierade och förstådda. Samtidigt kan vissa detaljer förfinas med tiden.
• Tidig introduktion av produkten på marknaden krävs.
• Det finns flera riskabla funktioner eller mål.

4. "RAD-modell" (snabb applikationsutvecklingsmodell eller snabb applikationsutveckling)

Modellen för snabb applikationsutveckling inkluderar följande faser:

• Affärsmodellering: definiera en lista över informationsflöden mellan olika avdelningar.
• Datamodellering: informationen som samlats in i föregående steg används för att bestämma de objekt och andra enheter som är nödvändiga för informationscirkulationen.
• Processmodellering: Informationsflöden länkar objekt för att uppnå utvecklingsmål.
• Bygg applikationen: Använder automatiserade monteringsverktyg för att konvertera CAD-modeller till kod.
• Testning: nya komponenter och gränssnitt testas.

Kan endast användas med högt kvalificerade och högt specialiserade arkitekter. Projektbudgeten är stor att betala för dessa specialister tillsammans med kostnaden för färdiga automatiserade monteringsverktyg. RAD-modellen kan väljas med säker kunskap målverksamhet och behovet av akut produktion av systemet inom 2-3 månader.

5. "Agil modell" (flexibel utvecklingsmetodik)

I den "agila" utvecklingsmetoden kan kunden efter varje iteration observera resultatet och förstå om det tillfredsställer honom eller inte. Detta är en av fördelarna med den flexibla modellen. Dess nackdelar inkluderar det faktum att det på grund av bristen på specifika formuleringar av resultaten är svårt att uppskatta de arbetskostnader och kostnader som krävs för utveckling. Extrem programmering(XP) är en av de mest kända tillämpningarna av den agila modellen i praktiken.

Denna typ är baserad på korta dagliga möten - "Scrum" och regelbundet återkommande möten (en gång i veckan, en gång varannan vecka eller en gång i månaden), kallade "Sprint". Vid dagliga möten diskuterar teammedlemmarna:

• rapportera om det arbete som gjorts sedan senaste Scrum;
• en lista över uppgifter som den anställde måste utföra innan nästa möte;
• svårigheter under arbetets gång.

När ska man använda Agile?

• När användarnas behov ständigt förändras i en dynamisk verksamhet.
• Agila förändringar implementeras till en lägre kostnad på grund av frekventa ökningar.
• Till skillnad från vattenfallsmodellen kräver den smidiga modellen bara lite planering för att få igång ett projekt.

6. "Iterativ modell" (iterativ eller iterativ modell)

Diagrammet visar den iterativa "utvecklingen" av Mona Lisa. Som du kan se finns det i den första iterationen bara en skiss av Mona Lisa, i den andra visas färgerna och den tredje iterationen lägger till detaljer, mättnad och fullbordar processen. I den inkrementella modellen byggs produktens funktionalitet upp bit för bit, produkten är uppbyggd av delar. Till skillnad från den iterativa modellen representerar varje del ett komplett element.

Ett exempel på iterativ utveckling är röstigenkänning. Den första forskningen och förberedelserna av den vetenskapliga apparaten började för länge sedan, först i tankar, sedan på papper. Med varje ny iteration förbättrades kvaliteten på igenkänningen. Men perfekt erkännande har ännu inte uppnåtts, därför har problemet ännu inte lösts helt.

När är det optimalt att använda en iterativ modell?

• Kraven för det slutliga systemet är tydligt definierade och förstådda i förväg.
• Projektet är stort eller mycket stort.
• Huvudmålet måste definieras, men implementeringsdetaljer kan utvecklas över tiden.

7. "Spiralmodell" (spiralmodell)

”Spiralmodellen” liknar den inkrementella modellen, men med tonvikt på riskanalys. Det fungerar bra för att lösa kritiska affärsproblem när misslyckanden är oförenlig med företagets aktiviteter, i samband med lanseringen av nya produktlinjer, när vetenskaplig forskning och praktiska tester är nödvändiga.

Spiralmodellen innefattar 4 steg för varje tur:

1. planera;
2. riskanalys;
3. design;
4. utvärdering av resultatet och, om kvaliteten är tillfredsställande, övergång till ett nytt skede.

Låt oss sammanfatta

Bilden visar skillnaderna mellan de två vanligaste metoderna.

I modern praktik är modeller för mjukvaruutveckling multivariata. Det finns ingen rätt modell för alla projekt, startvillkor och betalningsmodeller. Även Agile, så älskad av oss alla, kan inte tillämpas överallt på grund av att vissa kunder är oförberedda eller omöjligheten med flexibel finansiering. Metodikerna överlappar delvis medelvärden och liknar delvis varandra. Vissa andra begrepp användes endast för att marknadsföra sina egna kompilatorer och förde inte ut något nytt i praktiken.

Om utvecklingsteknik:
.
.
.
.

Endast registrerade användare kan delta i undersökningen. Kom in, snälla.

Utveckling av mjukvaruprodukter kan många värdefulla metoder - med andra ord etablerade bästa praxis. Valet beror på projektets detaljer, budgeteringssystemet, subjektiva preferenser och till och med chefens temperament. Artikeln beskriver metoder som vi regelbundet möter på Edison.

1. "Vattenfallsmodell" (kaskadmodell eller "vattenfall")

En av de äldsta, innebär sekventiell passage av etapper, som var och en måste slutföras helt innan nästa börjar. Vattenfallsmodellen gör det enkelt att hantera ett projekt. Tack vare dess styvhet går utvecklingen snabbt, kostnaden och deadline är förutbestämda. Men det här är ett tveeggat svärd. Vattenfallsmodellen ger utmärkta resultat endast i projekt med tydliga och fördefinierade krav och sätt att implementera dem. Det finns inget sätt att ta ett steg tillbaka testningen börjar först efter att utvecklingen är klar eller nästan klar. Produkter utvecklade enligt denna modell utan ett motiverat val kan ha brister (listan över krav kan inte justeras när som helst), som blir kända först i slutet på grund av den strikta sekvensen av åtgärder. Kostnaden för att göra ändringar är hög eftersom det kräver att man väntar tills hela projektet är klart för att initiera det. Den fasta kostnaden uppväger dock ofta nackdelarna med tillvägagångssättet. Det är möjligt att rätta till brister som upptäcks under skapandet och, enligt vår erfarenhet, krävs ett till tre ytterligare avtal till kontraktet med en liten teknisk specifikation.

Med hjälp av vattenfallsmodellen skapade vi många projekt från grunden, inklusive utveckling av endast tekniska specifikationer. Projekt som skrivs om på Habré: medium - röntgenmikrotomografi, små - automatisk uppdatering av Windows-tjänst på AWS.

När ska man använda vattenfallsmetoden?

• Endast när kraven är kända, förstådda och registrerade. Det finns inga motstridiga krav.
• Det finns inga problem med tillgängligheten av programmerare med de kvalifikationer som krävs.
• I relativt små projekt.

2. "V-modell"

Ärvde "steg för steg"-strukturen från kaskadmodellen. Den V-formade modellen är tillämpbar på system där oavbruten drift är särskilt viktig. Till exempel applikationsprogram på kliniker för övervakning av patienter, integrerad mjukvara för kontrollmekanismer för akuta krockkuddar i fordon, och så vidare. En speciell egenskap hos modellen är att den syftar till att noggrant kontrollera och testa en produkt som redan är i inledningsskedet av design. Teststeget genomförs samtidigt med motsvarande utvecklingssteg, till exempel skrivs enhetstester under kodning.

Ett exempel på vårt arbete baserat på V-metoden är en mobilapplikation för en europeisk mobiloperatör som sparar roamingkostnader under resor. Projektet genomförs enligt en tydlig specifikation, men det inkluderar ett betydande teststeg: gränssnittsbekvämlighet, funktionalitet, belastning och inklusive integration, vilket ska bekräfta att flera komponenter från olika tillverkare samverkar stabilt, stöld av pengar och lån är omöjlig.

När ska man använda V-modellen?

• Om grundlig testning av en produkt krävs, kommer V-modellen att motivera sin inneboende idé: validering och verifiering.
• För små och medelstora projekt där kraven är tydligt definierade och fasta.
• I förhållande till tillgänglighet för ingenjörer med nödvändiga kvalifikationer, särskilt testare.

3. "Inkrementell modell" (inkrementell modell)

Inkrementella modeller används där individuella ändringsförfrågningar är tydliga och enkelt kan formaliseras och implementeras. I våra projekt använde vi den för att skapa DefView-läsaren och sedan Vivaldis nätverk av elektroniska bibliotek.

Som ett exempel kommer vi att beskriva essensen av ett steg. Vivaldis nätverk av elektroniska bibliotek ersatte DefView. DefView är ansluten till en dokumentserver och kan nu ansluta till många. En lagringsserver installeras på platsen för en institution som vill sända sitt innehåll till en specifik publik, som direkt kommer åt dokumenten och konverterar dem till önskat format. Arkitekturens rotelement har dykt upp - den centrala Vivaldi-servern, som fungerar som en enhetlig sökmotor för alla lagringsservrar installerade i olika institutioner.

När ska man använda den inkrementella modellen?

• När de grundläggande kraven för systemet är tydligt definierade och förstådda. Samtidigt kan vissa detaljer förfinas med tiden.
• Tidig introduktion av produkten på marknaden krävs.
• Det finns flera riskabla funktioner eller mål.

4. "RAD-modell" (snabb applikationsutvecklingsmodell eller snabb applikationsutveckling)

Modellen för snabb applikationsutveckling inkluderar följande faser:

• Affärsmodellering: definiera en lista över informationsflöden mellan olika avdelningar.
• Datamodellering: informationen som samlats in i föregående steg används för att bestämma de objekt och andra enheter som är nödvändiga för informationscirkulationen.
• Processmodellering: Informationsflöden länkar objekt för att uppnå utvecklingsmål.
• Bygg applikationen: Använder automatiserade monteringsverktyg för att konvertera CAD-modeller till kod.
• Testning: nya komponenter och gränssnitt testas.

Kan endast användas med högt kvalificerade och högt specialiserade arkitekter. Projektbudgeten är stor att betala för dessa specialister tillsammans med kostnaden för färdiga automatiserade monteringsverktyg. RAD-modellen kan väljas med säker kunskap om målverksamheten och behovet av akut produktion av systemet inom 2-3 månader.

5. "Agil modell" (flexibel utvecklingsmetodik)

I den "agila" utvecklingsmetoden kan kunden efter varje iteration observera resultatet och förstå om det tillfredsställer honom eller inte. Detta är en av fördelarna med den flexibla modellen. Dess nackdelar inkluderar det faktum att det på grund av bristen på specifika formuleringar av resultaten är svårt att uppskatta de arbetskostnader och kostnader som krävs för utveckling. Extreme Programming (XP) är en av de mest kända tillämpningarna av den agila modellen i praktiken.

Denna typ är baserad på korta dagliga möten - "Scrum" och regelbundet återkommande möten (en gång i veckan, en gång varannan vecka eller en gång i månaden), kallade "Sprint". Vid dagliga möten diskuterar teammedlemmarna:

• rapportera om det arbete som gjorts sedan senaste Scrum;
• en lista över uppgifter som den anställde måste utföra innan nästa möte;
• svårigheter under arbetets gång.

När ska man använda Agile?

• När användarnas behov ständigt förändras i en dynamisk verksamhet.
• Agila förändringar implementeras till en lägre kostnad på grund av frekventa ökningar.
• Till skillnad från vattenfallsmodellen kräver den smidiga modellen bara lite planering för att få igång ett projekt.

6. "Iterativ modell" (iterativ eller iterativ modell)

Diagrammet visar den iterativa "utvecklingen" av Mona Lisa. Som du kan se finns det i den första iterationen bara en skiss av Mona Lisa, i den andra visas färgerna och den tredje iterationen lägger till detaljer, mättnad och fullbordar processen. I den inkrementella modellen byggs produktens funktionalitet upp bit för bit, produkten är uppbyggd av delar. Till skillnad från den iterativa modellen representerar varje del ett komplett element.

Ett exempel på iterativ utveckling är röstigenkänning. Den första forskningen och förberedelserna av den vetenskapliga apparaten började för länge sedan, först i tankar, sedan på papper. Med varje ny iteration förbättrades kvaliteten på igenkänningen. Men perfekt erkännande har ännu inte uppnåtts, därför har problemet ännu inte lösts helt.

När är det optimalt att använda en iterativ modell?

• Kraven för det slutliga systemet är tydligt definierade och förstådda i förväg.
• Projektet är stort eller mycket stort.
• Huvudmålet måste definieras, men implementeringsdetaljer kan utvecklas över tiden.

7. "Spiralmodell" (spiralmodell)

”Spiralmodellen” liknar den inkrementella modellen, men med tonvikt på riskanalys. Det fungerar bra för att lösa kritiska affärsproblem när misslyckanden är oförenlig med företagets aktiviteter, i samband med lanseringen av nya produktlinjer, när vetenskaplig forskning och praktiska tester är nödvändiga.

Spiralmodellen innefattar 4 steg för varje tur:

1. planera;
2. riskanalys;
3. design;
4. utvärdering av resultatet och, om kvaliteten är tillfredsställande, övergång till ett nytt skede.

Låt oss sammanfatta

Bilden visar skillnaderna mellan de två vanligaste metoderna.

I modern praktik är modeller för mjukvaruutveckling multivariata. Det finns ingen rätt modell för alla projekt, startvillkor och betalningsmodeller. Även Agile, så älskad av oss alla, kan inte tillämpas överallt på grund av att vissa kunder är oförberedda eller omöjligheten med flexibel finansiering. Metodikerna överlappar delvis medelvärden och liknar delvis varandra. Vissa andra begrepp användes endast för att marknadsföra sina egna kompilatorer och förde inte ut något nytt i praktiken.

Om utvecklingsteknik:
Återigen om de sju huvudsakliga utvecklingsmetoderna.
10 huvudsakliga misstag i skalningssystem.
8 utvecklingsplaneringsprinciper som gör livet förenklat.
5 huvudrisker vid utveckling av anpassad mjukvara.

Endast registrerade användare kan delta i undersökningen. , Snälla du.