Legacy-süsteemi uuendamine

Legacy-süsteemi uuendamine etapiti, ilma toimivat tööd pimesi asendamata.

Kaardistame vananenud veebisüsteemi kasutajad, andmed, ühendused ja kriitilised tegevused ning valime sobiva uuendustee: piiratud paranduse, moodulite kaupa asendamise, migratsiooni või uue lahenduse. Säilitamist ei lubata enne lähteolukorra kontrolli.

Räägime projektist

Millal moderniseerimine muutub vajalikuks

Muudatused on ebaproportsionaalselt riskantsed

Väike funktsioon puudutab tundmatuid sõltuvusi, testid puuduvad või käivitamine vajab käsitsi samme, mida teab ainult üks inimene.

Kasutajad töötavad süsteemist mööda

Puuduvad vaated, aeglane töö või jäik andmemudel sunnib hoidma paralleelseid tabeleid ja käsitsi kontrollnimekirju.

Tehniline piir takistab ühendusi

Vana autentimine, andmekuju või käituskeskkond ei sobi uue teenuse, turvanõude või integratsiooniga ning vajab eraldatud üleminekuplaani.

Uuendada, eraldada või asendada

Inventuur näitab tegeliku ulatuse

Koondame kasutatavad funktsioonid, andmebaasid, failid, tööd, liidestused, URL-id ja käituse. Kasutamata kood ei saa automaatselt migratsiooninõudeks.

Etapid vähendavad katkestuse riski

Võimalusel eraldame ühe mooduli või töövoo, loome selle ümber kontrollid ning alles siis liigume järgmise sõltuvuse juurde.

Andmete kvaliteet on eraldi töö

Väljade vastendus, duplikaadid, puuduvad seosed, säilitamise alus ja kontrollsummad vajavad oma proovimigratsiooni ja vastuvõttu.

Moderniseerimise võimalik esimene etapp

Moderniseerimise võimalik esimene etapp

  • Funktsioonide, andmete ja sõltuvuste inventuur
  • Riskide ning säilitamisvajaduse otsustuslogi
  • Sihtarhitektuur ja etapiline üleminekuplaan
  • Proovimigratsioon või piiratud mooduliparandus
  • Testid, jälgimine ja tagasipöördumise plaan

Mida vajame sisuliseks kaardistuseks

Tänane töö ja vastutajad

Kirjeldage, kes lahendust kasutab, millised tegevused tehakse täna käsitsi või eri tööriistades ning kes vastutab põhiandmete ja otsuste eest. Olemasolevad ekraanid, protsessijoonis ja näidisjuhtumid aitavad eristada igapäevast tööd harvadest eranditest.

Andmed, ühendused ja piirangud

Koondame kasutatavad süsteemid, andmeallikad, ligipääsureeglid, keeled ja vajalikud liidestused. Kui dokumentatsioon või testkeskkond puudub, märgime selle sõltuvusena ega eelda välise süsteemi käitumist.

Edu ja vastuvõtu tunnused

Lepime kokku, milline lõpetatav tegevus peab esimeses etapis töötama, kuidas tulemust kontrollitakse ning millised vead või katkestused peavad olema nähtavad. Mõõdik lisatakse ainult siis, kui selle lähteandmed ja arvutusviis on teada.

Kuidas töö liigub otsusest toimiva etapini

01

Kaardistus

Vaatame koos läbi kasutajad, eesmärgi, tänase töö, andmed, sõltuvused ja kriitilised erandid. Tulemuseks on kontrollitav ulatus, mitte oletustel põhinev funktsioonide nimekiri.

02

Struktuur ja prototüüp

Seome põhitegevused, olekud ja infoarhitektuuri ekraanideks või tehniliseks vooskeemiks. Enne arendust kontrollime, et kasutaja ja haldaja jõuavad mõlemad lõpetatava tulemuseni.

03

Arendus ja ühendused

Teostame kokkulepitud liidese, serveripoolse loogika ning integratsioonid väikeste kontrollitavate osadena. Vigade käsitlemine, õigused ja logitavad sündmused kuuluvad sama etapi vastuvõttu.

04

Testimine ja üleandmine

Kontrollime tavavoogu, olulisemaid erandeid, eri seadmeid ja kokkulepitud andmevahetust. Enne käivitamist fikseerime teadaolevad piirangud, vastutajad, jälgimise ja tagasipöördumise võimaluse.

Piirid, mis peavad enne teostust selged olema

Piirid, mis peavad enne teostust selged olema

  • Esimese etapi kasutajad, rollid ja lõpetatav põhitegevus
  • Põhiandmete omanikud, kohustuslikud väljad ja säilitamise vajadus
  • Kokkulepitud välised süsteemid, ligipääsud ja testimisvõimalus
  • Kriitilised erandid, veateated, õigused ja auditit vajavad sündmused
  • Vastuvõtukontroll, käivitamise vastutus ja järgmise etapi nimekiri

Käivitamine, jälgimine ja edasine vastutus

Üleandmine ei piirdu valmis ekraanidega. Koondame kokkulepitud funktsioonid, ligipääsu- ja haldusjuhised, väliste ühenduste sõltuvused, teadaolevad piirangud ning kontrollid, millega meeskond saab lahenduse tööd jälgida. Käivitamise viis, andmete ülemineku hetk, tagasipöördumise võimalus ja järgmise etapi prioriteedid lepitakse kokku vastavalt süsteemi riskile; neid ei esitata enne kaardistust kindla lubadusena.

Tõendite piir moderniseerimisel

Legacy-süsteemi uuendamine

Avalik portfell tõendab GoMedia veebisüsteemide, e-poodide, broneerimise ja integratsioonide tööd, kuid ei tõenda nimetatud täielikku legacy-moderniseerimise case’i. Seetõttu kirjeldab leht meetodit ega luba konkreetset säilitamise tulemust.

Küsimused legacy-süsteemi uuendamise kohta

Mitte alati. Inventuur võib näidata, et mõistlik on parandada kriitiline moodul, eraldada ühendus või asendada lahendus etappide kaupa.

Seda saab kinnitada pärast skeemi, kvaliteedi, mahu, seoste ja õigusliku säilitamisvajaduse kontrolli ning proovimigratsiooni.

Mõnikord küll, kui andmeomanik, sünkroonimise suund, konfliktid ja ülemineku lõpp on selgelt kavandatud.

Kasutame etapilist vastuvõttu, kontrollitavaid andmeid, varundust, jälgimist, selget otsustushetke ja reaalselt proovitud tagasipöördumise varianti.

Legacy-süsteemi uuendamine etapiti, ilma toimivat tööd pimesi asendamata.

Kirjeldage lühidalt eesmärki, kasutajaid, tänast lahendust ja funktsioone, mida vajate. Esimeses vestluses täpsustame küsimused ning lepime kokku, millist kaardistust on enne pakkumist vaja.

Räägime projektist