Mis on ALM? Rakenduse elutsükli halduse protsess (täisvorm)

Mis on ALM?

ALM on tarkvararakenduse spetsifikatsiooni, disaini, arendamise ja testimise protsess. See hõlmab kogu elutsüklit alates rakenduse ideest kuni arenduse, testimise, juurutamise, toe ja lõpuks kasutajakogemuse etapini. ALM-i täielik vorm on rakenduse elutsükli haldus (Application Lifecycle Management).

Sõltuvalt tarkvaraarendusmetoodikast (näiteks juga, agiilne või DevOps) võib ALM-i jagada erinevateks etappideks. ALM-protsess jaguneb peamiselt kolmeks elemendiks: juhtimine, arendus ja toimingud.

ALM-protsess

Siin on ALM-i põhivaldkonnad:

Juhtimine

See hõlmab nõuete haldamist, ressursside haldamist, andmeturvet, kasutajate juurdepääsu, ülevaatamist, auditeerimist, juurutamise juhtimist ja tagasipööramist.

Juhtimise eelised:

• Ühine äristrateegia
• Developing äriplaan
• Pakub pidevat jälgimist
• Suurima väärtusega projektide rahastamine
• Selge vastutus ja kontroll

Rakenduste arendamine

See hõlmab praeguste probleemide tuvastamist, rakenduse planeerimist, disaini, loomist, testimist ja juurutamist. See valdkond hõlmab traditsioonilisi arendaja ja rakenduse looja rolle.

Rakenduse toimimine

See valdkond hõlmab rakenduse juurutamist ja tehnoloogiapaketi hooldust. Juga-tüüpi tarkvaraarendusmeetodis on toimimine arendusest eraldi etapp. DevOps-meeskond ühendab toimingud ja arenduse täielikult integreeritud ja pidevaks protsessiks.

Miks on ALM oluline?

ALM-i kasutamise peamised põhjused on järgmised:

• Saate hea ülevaate projekti staatusest.
• Meeskonnad suudavad tõhusalt suhelda.
• Nõuded on kergesti määratletavad ja track.
• Tarkvara on piisavalt testitud.
• Lahenduse hooldus- ja kasutuskulud on piiratud.

ALM vs SDLC: kuidas need erinevad

ALM-i ja tarkvaraarenduse elutsüklit käsitletakse sageli sünonüümidena, mis tekitab segadust, kui meeskonnad üritavad ühte neist kasutusele võtta. SDLC asub ALM-i sees, mitte selle kõrval.

Aspekt	SDLC	ALM
Ulatus	Tarkvara loomine	Kogu toote eluiga ideest kuni pensionile jäämiseni
Algab kell	Ehituse nõuded	Esialgne äriplaan
Lõpeb kell	Selle väljalaske juurutamine	Rakenduse deaktiveerimine
Hõlmab juhtimist	Ei	Jah – rahastamine, juurdepääs, audit, vastavus
Tsüklite arv	Üks väljalaske kohta	Paljud SDLC-tsüklid ühe rakenduse eluea jooksul

Rakendus läbib tavaliselt palju SDLC iteratsioone, jäädes samal ajal ühte ALM elutsüklisse. Selle pesastamise mõistmine selgitab, miks allolevad etapid ulatuvad kaugemale koodi tarnimisest.

Rakenduse elutsükli haldamise (ALM) etapid

Siin on ALM-i erinevad etapid:

1) Nõuete haldamine

Nõuete haldamine on esimene ALM-i etapp. See aitab teil dokumenteerida, analüüsida, track, seadke prioriteedid ja leppige kokku nõuetes. See on pidev protsess, mis kestab kogu projekti elutsükli vältel. Vaadake ka meie parimate nimekirja nõuete haldamise tarkvara.

2) Kujundus

Disainijuhtimine on protsess, mis aitab suurendada klientide rahulolu ja lojaalsust, parandades kasutatavust. See kujundab ka kliendi ja toote vahelist interaktsiooni.

3) Ehitushaldus

Ehitushaldus, tuntud ka kui koodihaldus, on lähtekoodifailide teisendamise protsess iseseisvaks tarkvarakomponendiks. Selles etapis teisendatakse rakenduse idee tegelikuks rakenduseks.

Selles etapis rakendus luuakse, testitakse ja juurutatakse ning testija hakkab testimisfaasi jaoks testjuhtumeid ette valmistama ja testiskripte kirjutama.

4) SCM

Tarkvara konfiguratsioonihaldus (SCM) on ALM-i etapp, kus arendusmeeskond süstemaatiliselt korraldab, haldab ja kontrollib dokumentide, koodi ja muude üksuste muudatusi rakenduse arendustsükli jooksul.

5) Operaja hooldus

Selles etapis algab rakenduse jälgimine, haldamine ja pidev arendamine. DevOpsis hõlmab see etapp „väljaandmist“, „konfigureerimist“ ja „jälgimist“.

Selles etapis leiad ja lahendad vigu. See etapp aitab sul planeerida ja tähtsuse järjekorda seada toote järgmisi värskendusi.

6) Testide haldamine

Testimise faasis kontrollivad testijad, kas rakendus vastab protsessi algfaasis määratletud nõuetele.

Samuti tagavad nad, et rakendus vastab kasutajate ootustele ja kõigi teiste seda kogu elutsükli vältel toetavate sidusrühmade vajadustele, isegi kui neid ootusi nõuete etapis korralikult ei arvestatud.

7) Kasutajakogemus

Hooldus ehk kasutajakogemus on traditsiooniliselt ALM-i pikim etapp, kuid see on ka etapp, kus testimis- ja arendusmeeskondade osalemine on tavaliselt kõige väiksem.

Kui rakendus on välja töötatud, tuleb kasutajate roll mängu. Nad harjutavad kogu rakendust ja jagavad oma kogemusi tagasiside kaudu ning seejärel valmib lõplik rakendus.

ALM-i eelised

ALM-i kasutamise eelised on järgmised:

• ALM aitab teil süsteemi hallata, korraldades ja trackuninglik töö.
• Defekte saab projektide vahel jagada, mis vähendab dubleerivat riski.
• ALM pakub integratsiooni teiste testimistööriistadega.
• See annab rakendusele enne selle loomist selge suuna.
• Ilma ALM-ita on tarkvaraarendusmeeskonnal raske toota tarkvara konkurentsis püsimiseks vajaliku kiiruse ja paindlikkusega.
• ALM pakub tarkvara tõhusalt ja minimaalse meeskonna üldkuluga.

ALM-tööriistad

Siin on mõned olulised ALM-tööriistad:

1) Kovair ALM Studio

Kovair on üks kõige ulatuslikumaid rakenduse elutsükli halduse tooteid. See suudab hallata kõiki arenduse elutsükli etappe alates nõuetest kuni väljalaskeni.

Funktsioonid:

• Võtke kasutusele täielikult veebipõhine lahendus ilma kliendipoolse tarkvarata, vähendades tugiteenuste koormust
• Harjuta mis tahes arendusmetoodikat: juga, agiilne või hübriid
• Tõhususe ja tootlikkuse suurendamiseks rakendage konfigureeritav ülesandepõhine töövoomootor
• Saate reaalajas märguandeid igas tegevuses
• Kaasake iga arendusetappi täielikult, võimaldades vastavust standarditele
• Võimaldab artefaktide staatuse reaalajas vaatamist, mis suurendab läbipaistvust ja avaldamise prognoositavust

Link: https://www.kovair.com/alm-studio/

2) OpenText Rakenduste kvaliteedijuhtimine (endine Micro Focus ALM)

See tööriist toetab lean-, agiil- ja DevOps-põhist tarnimist.ping organisatsioonid avaldavad tarkvara kiiremini. See võimaldab igas suuruses meeskondadel pakkuda kvaliteetseid rakendusi suurema kiirusega. Toode on mitu korda omanikku vahetanud: algselt töötas selle välja Mercury, mille HP omandas, kanti üle Micro Focusele ja sellest ajast alates OpenText omandas Micro Focuse 2023. aasta jaanuaris see on müüdud kui OpenText Rakenduse kvaliteedijuhtimine.

Funktsioonid:

• Pakub rakendusi kiiruse, kvaliteedi ja ulatusega
• Võimaldab sidusrühmadel projekti eesmärkide saavutamiseks suhelda ja koordineerida tegevust
• Pakub vastupidavust tracjuhtimine ja aruandlus ning projektiga seotud ülesannete sujuv integreerimine
• Võimaldab projekti detailset analüüsi ja tõhusat juhtimist
• Loob ühenduse e-posti süsteemidega ja teavitab meeskonnaliikmeid muudatustest

Link: https://www.opentext.com/products/application-quality-management

3) Digital.ai Agility (endine VersionOne)

Paindlikkus lihtsustab tooteplaneerimist lihtsa tellimuste haldamise abil. See on loodud DevOps ja pakub otsast lõpuni pidevat edastamist lohistamisliidese kaudu. Toode käivitati nime all VersionOne, see kolis CollabNeti ja tarnitakse nüüd nime all Digital.ai Väledus.

Funktsioonid:

• Võimaldab kasutajatel lohistamise abil lugusid ja defekte tähtsuse järjekorda seada
• Halda ärialgatusi portfelliüksuste abil
• Võimaldab esemeid teemade kaupa grupeerida
• Annab tulemusi vastavalt ärieesmärkidele
• Salvestab kõik funktsioonitaotlused ühte kohta
• Aitab tagada ettevõtte eesmärkide ja tooteväljundite kooskõla
• Annab projektijuhile ülevaate ja tervikliku ülevaate

Link: https://digital.ai/products/agility/

Tööriista valik on vähem oluline kui see, kuidas protsessi iga päev kasutatakse, mida illustreerivad kaks allolevat stsenaariumi.

Kasutage ALM-i juhtumistsenaariumit arendaja vaatenurgast

• Arendaja alustab tööd ja kontrollib talle määratud ülesannete nimekirja.
• Nad vaatavad ülesanded prioriteedi järgi üle ja valivad ühe.
• Nad muudavad ülesande staatuse olekuks „Pooleliolev”.
• Nad kontrollivad koodi lähtekoodi hoidlast.
• Nad rakendavad testimisraamistiku abil ühiktesti.
• Nad käivitavad testi standardse ehitusskriptiga. Code kontroll annab teada ebaseaduslikest nimetamiskonventsioonidest või võimalikest vigadest.
• Nad parandavad koodi ja teevad testi uuesti.
• Kui katvusmäär saavutab eesmärgi, kinnitavad nad koodi ülesande ID-ga.
• Seejärel kontrollivad nad koodi ja käivitavad ehitusskripti.
• Kood kompileeritakse ja paigutatakse lavastusmasinasse.
• Test käivitatakse. Kui see katki läheb, saadetakse arendajale ja projektijuhile automaatselt teade.
• Arendaja võtab koodi lähtekoodihoidlas ja testimismasinas tagasi.
• Kui test läbib, käivitatakse koodi kontroll ja katvuse analüüs. Kõikidest probleemidest teatatakse; vastasel juhul teavitatakse arendajat, et kõik implementatsioonid on edukalt lõpule viidud.
• Nad salvestavad oma tööajaloo ülesannete haldamise süsteemi.
• Projektijuhti teavitatakse ülesande lahendamisest ja ta vaatab tulemuse üle.

Kasutage ALM-i juhtumistsenaariumi projektijuhi vaatenurgast

• Projektijuht avab veebibrauseri ja läheb ALM-i armatuurlaua lehele.
• Igal projektil on oma armatuurlaua leht.
• See kuvab avatud ülesannete arvu, ootel ülesannete arvu ja kõiki avatud kriitilisi ülesandeid.
• Armatuurlaud teavitab projektijuhti võimalikest riskidest ja näitab projekti üldist seisukorda.
• Iga muudatus ja muudatused kajastatakse automaatselt.
• Seega välistab ALM-protsess vajaduse koosoleku või telefonikõne järele, et kontrollida kriitiliste ülesannete pideva integratsiooni olekut.

KKK