ALM — lietojumprogrammu dzīves cikla pārvaldība — lietojumprogrammu dzīves cikla pārvaldība. Lietojumprogrammu dzīves cikla pārvaldības metodoloģijas koncepcija - ALM (Application Lifecycle Management)

utt.

"Dzīves cikla pārvaldība" ir saistīta ar nepieciešamību apgūt sistēmu inženierijā pazīstamās prakses:

• informācijas pārvaldība(“pareizajai informācijai jābūt pieejamai īstajām ieinteresētajām personām laikā un veidā, kas ir pieejama tās lietošanai”)
• konfigurācijas pārvaldība(“projekta informācijai jāatbilst prasībām, informācijai “kā uzbūvēts” ir jāatbilst projektam, tostarp projektēšanas pamatojumam, fiziskajai sistēmai ir jāatbilst informācijai “kā uzbūvēta”, un dažādām projekta daļām ir jāatbilst citai citai”, dažreiz daļu no šīs prakses sauc par "izmaiņu vadību").

LCMS pret PLM

Jaunizveidotā LCMS neizmanto PLM kā nepieciešamo programmatūras klasi, ap kuru tiek veidota šāda sistēma. Lielos inženiertehniskos projektos vienlaikus tiek izmantoti vairāki (visbiežāk ievērojami "mazattīstīti") dažādu piegādātāju PLM, un, veidojot LCMS, mēs parasti runājam par to starporganizāciju integrāciju. Protams, vienlaikus tiek risināti arī jautājumi, kā integrēt LCMS informāciju no tām sistēmām, kurām vēl nav savienojuma ar kādu no paplašinātā uzņēmuma PLM sistēmām. Termins "paplašināts uzņēmums" (paplašināts uzņēmums) parasti attiecas uz organizāciju, kas izveidota, izmantojot līgumu sistēmu no dažādu juridisko personu resursiem (cilvēkiem, instrumentiem, materiāliem), kuras piedalās noteiktā inženierprojektā. Paplašinātos uzņēmumos atbilde uz jautājumu, kurā PLM, kuru CAD / CAM / ERP / EAM / CRM / u.c. sistēmu dati ir integrēti, kļūst nenozīmīga: jūs nevarat likt dažādu uzņēmumu īpašniekiem izmantot programmatūru. no tā paša piegādātāja.

Un tā kā PLM sistēma joprojām ir programmatūra, un LCMS "pārvaldības sistēma" ir skaidri saprotama arī kā "pārvaldības sistēma", termins LCMS skaidri nozīmē organizatorisko aspektu, nevis tikai informācijas tehnoloģiju aspektu. Tādējādi frāze "PLM izmantošana dzīves cikla pārvaldības sistēmas atbalstam" ir diezgan nozīmīga, lai gan tā var būt mulsinoša, burtiski tulkojot tajā vārdu "PLM" krievu valodā.

Tomēr izpratne par "dzīves cikla pārvaldības sistēmu", ja to apstrādā IT cilvēki, nekavējoties samazinās līdz "tikai programmatūrai", kas aizdomīgi izskatās pēc PLM programmatūras. Un pēc šīs pārmērīgās vienkāršošanas sākas grūtības: “iepakotā” PLM sistēma no kāda projektēšanas automatizācijas programmatūras piegādātāja parasti tiek nekavējoties konstruktīvi parādīta kā programmatūras moduļu komplekts no šī piegādātāja kataloga, neņemot vērā atbalstītās inženierijas un vadības funkcijas, un tiek uzskatīts par šādu komponentu trio:

• uz datiem orientēta dzīves cikla datu krātuve,
• "darbplūsmas dzinējs", lai atbalstītu "pārvaldību",
• "portāls" repozitorija satura un darbplūsmas stāvokļa apskatei.

LCMS mērķis

Galvenais mērķis: LCMS atklāj un novērš sadursmes, kas ir neizbēgamas sadarbības attīstībā. Visas pārējās LCMS funkcijas ir atvasinājumi, kas atbalsta šo galveno funkciju.

Jebkuras mūsdienu LCMS galvenā ideja- šī ir precīza un konsekventa sistēmas un apkārtējās pasaules attēlojuma izmantošana paplašinātas organizācijas neizbēgami neviendabīgās un sākotnēji nesaderīgās datorsistēmās. Virtuālo izkārtojumu, informācijas modeļu, uz datiem orientētu projektēšanas informācijas repozitoriju izmantošana nodrošina sadursmju noteikšanu "būvniecības datorā", "virtuālās montāžas" laikā, nevis zīmējot rasējumus un citus projekta modeļus materiālā realitātē faktiskās būvniecības laikā. "metālā un betonā" un nodot ekspluatācijā.

Tāpēc LCMS ideja nav saistīta ar dažādu "dizaina automatizāciju", galvenokārt ar "ģeneratīvo dizainu" (ģeneratīvo dizainu) un "ģeneratīvo ražošanu" (ģeneratīvo ražošanu). LCMS vairs nav saistīta ar sintēzi, bet gan ar analīzi: tā atklāj un/vai novērš sadursmes atsevišķu apakšsistēmu projektēšanas rezultātos, kad tās ir saliktas kopā, izmantojot dažādas tehnoloģijas:

• projekta datu apvienošana vienā repozitorijā,
• darbojas integritātes pārbaudes algoritms inženiertehniskajiem datiem, kas izplatīti vairākos krātuvēs,
• veicot faktisku "virtuālo montāžu" un simulāciju īpaši izvēlētai projektēšanas datu apakškopai.

Uz modeļiem balstīta pieeja

LCMS izmantošana nozīmē ne tikai papīra dizaina, bet arī "elektroniskā papīra" noraidīšana(.tiff vai citi rastra formāti) un pāreja uz uz datiem orientētu informācijas attēlojumu. Salīdzināt divus modeļus, kas dažos apzīmējumos pastāv uz papīra, un atrast tajos neatbilstības ir daudz grūtāk un ilgāk nekā novērst sadursmes strukturētos elektroniskajos dokumentos, kuros tiek izmantoti inženierijas datu modeļi, nevis rastra grafika.

Datu modeli var izveidot atbilstoši kādai valodai, piemēram:

• ISO 24744 izstrādes metodes apraksta standarta ziņā),
• metamodelis (attiecībā uz OMG standartizācijas konsorciju),
• datu modelis/atsauces dati (atbilstoši ISO 15926 dzīves cikla datu integrācijas standartam).

Tieši šī pāreja uz strukturāli attēlotiem modeļiem jau pastāv projektēšanas sākumposmā un tiek saukta par "Model-based systems engineering" (MBSE, model-based systems engineering). Sadursmes, izmantojot datorizētu datu apstrādi, kļūst iespējams novērst jau agrākajos dzīves cikla posmos, pat pirms pilnvērtīgu būves 3D modeļu parādīšanās.

LCMS vajadzētu:

• nodrošināt mehānismu datu pārsūtīšanai no vienas lietojumprogrammas CAD/CAM/ERP/PM/EAM/u.c. citam- un elektroniskā strukturētā formā, nevis "elektroniskā papīra iepakojuma" veidā. Datu pārsūtīšana no vienas inženiertehniskās informācijas sistēmas (ar skaidru izpratni par to, kur, kur, kad, kas, kāpēc, kā) ir daļa no LCMS nodrošinātās funkcionalitātes. Tādējādi LCMS ir jāatbalsta darbplūsma (darba plūsma, ko daļēji veic cilvēki un daļēji datorsistēmas).
• versiju kontrole, proti, nodrošināt konfigurācijas pārvaldības funkciju – gan modeļus, gan sistēmas fiziskās daļas. LCMS uztur daudzpakāpju prasību taksonomiju un nodrošina līdzekļus, lai pārbaudītu daudzpakāpju dizaina lēmumus un to pamatojumu pretrunām ar šīm prasībām. Inženiertehniskās izstrādes gaitā jebkurš sistēmas apraksts, jebkurš no tās modeļiem tiek daudzkārt mainīts un papildināts, un tāpēc pastāv daudzās alternatīvās versijās ar dažādas pareizības pakāpes un dažādās pakāpēs, kas atbilst viena otrai. LCMS jānodrošina, ka pašreizējā darbā tiek izmantota tikai pareizā šo versiju kombinācija.

LCMS arhitektūra

LCMS arhitektonisko risinājumu var būt daudz, vienu un to pašu funkciju var atbalstīt dažādas struktūras un darbības mehānismi. Ir trīs arhitektūras veidi:

1. Tradicionālie mēģinājumi izveidot LCMS ir nodrošināt kritisku punktu-punktu datu pārsūtīšanu starp dažādām lietojumprogrammām. Šajā gadījumā var izmantot kādu specializētu darbplūsmas atbalsta sistēmu (BPM dzinējs, "biznesa procesu pārvaldības dzinējs") vai notikumu apstrādes sistēmu (sarežģītu notikumu apstrādes dzinēju). Diemžēl darba apjoms, kas saistīts ar apmaiņas nodrošināšanu no punkta uz punktu, izrādās vienkārši milzīgs: katru reizi ir nepieciešami speciālisti, kas saprot gan sasaistes sistēmas, gan informācijas pārsūtīšanas metodi.
2. Dzīves cikla datu integrācijas standarta izmantošana ISO 15926 saskaņā ar "ISO 15926 ārpuses" metodi, kad katram inženierijas pielietojumam tiek izstrādāts adapteris neitrālā attēlojumā, kas atbilst standartam. Tādējādi visi dati iegūst iespēju satikties kādā lietojumprogrammā un var konstatēt sadursmi starp tiem, taču lietojumprogrammai ir jāizstrādā tikai viens datu pārraides adapteris, nevis vairāki šādi adapteri (atbilstoši citu lietojumprogrammu skaitam, ar kurām tā tiek izmantota nepieciešams sazināties).
3. PLM(Teamcenter, ENOVIA, SPF, NET Platform utt.) - tiek izmantota standartizēta arhitektūra, ar vienīgo izņēmumu, ka katrā no šiem PLM izmantotais datu modelis ir mazāk universāls, lai atspoguļotu jebkuru inženierzinātņu priekšmetu jomu, kā arī nav neitrāls un pieejams visos formātos. Tātad ISO 15926 izmantošanu kā bāzes līniju datu pārsūtīšanai uz LCMS var uzskatīt par mūsdienu PLM faktiski īstenoto ideju tālāku attīstību.

Saskaņā ar konfigurācijas pārvaldības arhitektūru LCMS var iedalīt trīs veidos:

• "repozitorijs"(visu projekta datu aktuāla glabāšana vienā LCMS repozitorijā, kur dati tiek kopēti no vietas, kur tie tika izstrādāti),
• "reģistrēties"(LCMS uztur dzīves cikla datu adrešu sarakstu daudzos citu CAD sistēmu, inženiertehniskās simulācijas sistēmu, PLM, ERP utt. krātuvēs),
• "hibrīdā arhitektūra"-- kad daļa datu tiek kopēta LCMS centrālajā repozitorijā un daļa datu ir pieejama no citām vietām, izmantojot saites.

LCMS arhitektam arī jāapraksta:

• "portāls"(tai skaitā "tīmekļa portāls"), tā funkcijas un īstenošanas veids. Pati portāla klātbūtne ļauj nomierināt augstākos vadītājus, demonstrējot konfliktu neesamību. LCMS portāla arhitektoniskajiem risinājumiem tiek izvirzītas īpašas prasības.
• datu integritātes/konsekvences pārbaudes algoritmi dzīves cikls, kā arī šo algoritmu darbības apraksts:
  • standarta modulis atsevišķā lietojumprogrammā, kas strādā ar datiem šīs lietojumprogrammas repozitorijā - vai tas būtu CAD vai PLM;
  • Speciāli LCMS izstrādāta sadursmju pārbaudes programmatūra, kurai ir piekļuve datiem no dažādām lietojumprogrammām, kas atrodas LCMS centrālajā repozitorijā;
  • īpaši izstrādāts programmatūras rīks, kas caur internetu pa drošu kanālu piekļūst dažādām datu krātuvēm, kas atrodas dažādās organizācijās;
  • speciāli ieprogrammētas pārbaudes ar sadursmju kontroli, ielādējot dažādas inženierdatu kopas LCMS centrālajā repozitorijā;
  • visu uzskaitīto metožu kombinācija - atšķirīga dažāda veida sadursmēm; utt.
• veids, kā LCMS lietotāji mijiedarbojas(projektēšanas inženieri, pircēji, uzstādītāji, objektu projektu vadītāji utt.) un kā LCMS programmatūra atbalsta šo mijiedarbību bez sadursmēm. Sistēmu inženierijas standarti (īpaši ISO 15288 sistēmu inženierijas prakses standarts) paredz inženiertehnisko sarežģītu objektu dzīves cikla veida izvēli un norādi par to, kuras sistēmu inženierijas prakses iespējas tiks izmantotas. Dzīves cikla modelis ir viens no galvenajiem artefaktiem, kas kalpo kā organizatoriski pasākumi paplašinātā inženierprojekta organizācijas darba koordinēšanai. Koordinēts darbs kooperatīvās inženierijas (collaborative engineering) gaitā ir atslēga nelielam skaitam dizaina sadursmju. Kā tieši LCMS dzīves cikla modelis to atbalstīs? Tādējādi PLM sistēmas parasti neatrod vietu dzīves cikla modeļiem un vēl jo vairāk organizācijas modeļiem. Tāpēc LCMS ir jāmeklē citi risinājumi šo modeļu programmatūras atbalstam.
• Organizatoriskais aspekts pārejā uz LCMS izmantošanu. Pāreja uz LCMS izmantošanu var radīt būtiskas izmaiņas inženieru uzņēmuma struktūrā un pat personāla sastāvā: ne visi ekskavatori tiek ņemti par ekskavatoriem, ne visi kabīnes tiek ņemti par taksometru vadītājiem.

LCMS galvenais ir tas, kā piedāvātais risinājums veicina sadursmju agrīnu atklāšanu un pat novēršanu. Ja runa ir par kaut ko citu (jēgpilnu dzīves cikla veida izvēli atbilstoši projekta riska profilam, novecošanās pārvaldību, izmaksu pārvaldību un budžeta reformu, aksiomātiskā projektēšanas apgūšanu, būvniecību ar piegādēm tieši laikā, projektēšanas un būvniecības ģenerēšanu un daudz, daudz vairāk, arī ārkārtīgi noderīgi-moderni-interesanti), tad tas ir jautājums par citām sistēmām, citiem projektiem, citām metodēm, citām pieejām. LCMS būtu labi jādara savs darbs, nevis slikti jāatrisina milzīgs patvaļīgi izvēlētu ārvalstu uzdevumu kopums.

Tādējādi LCMS arhitektam ir divi galvenie uzdevumi:

• radīt vairākas labākās kandidātarhitektūras un to hibrīdus
• veikt vairāku kritēriju izvēli starp šīm arhitektūrām.
  • jēgpilns apsvērums (atlases kritēriju jēgpilnība)
  • rezultāta uzrādīšana (pamatojums).

Kritēriji LCMS arhitektoniskā risinājuma izvēlei

1. LCMS kvalitāte atbilst tā galvenajam mērķim: sadursmju atklāšanai un novēršanai Galvenais kritērijs ir: cik lielā mērā inženiertehnisko progresu var paātrināt, paātrinot sadursmju noteikšanu vai izvairīšanos no sadursmēm, izmantojot piedāvāto LCMS arhitektūru? Un, ja darba laiku nevar samazināt, tad par cik var palielināt darba apjomu tajā pašā laikā, izmantojot tos pašus resursus? Ieteicams izmantot šādas metodes:
   • Goldrata ierobežojumu teorija(TOC, ierobežojumu teorija) - arhitektūrai jānorāda, kuri sistēmas ierobežojumi tā noņem inženierprojekta kritisko resursu ceļā (nejaukt ar kritisko ceļu).
   • IA(investīciju atdeve) ieguldījumiem LCMS kandidātu arhitektūru padziļinātas pārskatīšanas rezultātu formalizācijas stadijā.
   Ir svarīgi izvēlēties apsvērumu robežas: inženierprojekta kopējo ātrumu var izmērīt tikai pie aplūkojamās organizācijas sistēmas robežas. Vienas juridiskas personas robežas var nesakrist ar paplašināta uzņēmuma robežām, kas veic liela mēroga inženierprojektu, un uzņēmums, kas piedalās tikai vienā dzīves cikla posmā, var nepareizi novērtēt tā lietderību un kritiskumu visam dzīves ciklam. sistēmas un izvēlēties nepareizu veidu, kā integrēties LCMS. Tad var izrādīties, ka LCMS izveide neietekmē kopējo projekta laiku un budžetus, jo nepatīkamākās sadursmes arī turpmāk jaunais LCMS nerisinās.
2. Spēja pieņemt pakāpenisku LCMS izstrādes dzīves ciklu Inkrementāls ISO 15288 ir tāds dzīves cikls, kurā funkcionalitāte lietotājam tiek dota nevis uzreiz, bet pa posmiem – taču arī investīcijas attīstībā notiek nevis uzreiz, bet pa posmiem. Protams, šajā gadījumā ir jāņem vērā lietderības samazināšanās likums: katrs LCMS pieaugums (katrs jauns sadursmju veids, kas tiek atklāts iepriekš) ir dārgāks, un ieguvumi no tā kļūst arvien mazāki, līdz tiek izstrādāts. LCMS, kas turpinās jau daudzus gadus, izzūd pats no sevis. Ja izrādīsies, ka kādai no piedāvātajām arhitektūrām LCMS izveidē jāiegulda uzreiz daudz naudas, bet ieguvumu var iegūt uzreiz 100% apmērā un tikai pēc pieciem gadiem uz nolikto atslēgu tad šī ir slikta arhitektūra. Ja izrādās, ka ir iespējams izstrādāt un nodot ekspluatācijā kādu kompaktu LCMS kodolu, un pēc tam daudzus, daudzus viena veida moduļus dažāda veida sadursmēm ar skaidru to izstrādes mehānismu (piemēram, pamatojoties uz ISO 15926), tad tas ir ļoti labs. Runa nav tik daudz par "agilas izstrādes" (agilas metodoloģijas) izmantošanu, bet gan par LCMS modulāras arhitektūras nodrošināšanu un plāna ierosināšanu prioritāra moduļu saraksta ieviešanai – vispirms aktuālāko, pēc tam mazāk aktuālo un tā tālāk. Nejaukt ar ICM (inkrementālo saistību modeli), lai gan nozīme šeit ir viena: labāka ir arhitektūra, kurā par sistēmu var saņemt kaut kādu nomaksu un iegūt nepieciešamo funkcionalitāti pēc iespējas ātrāk - lai saņemtu pabalstus (vismaz nelielus) agri, un vēlāk samaksātu par nokavēto pabalstu.
3. Fundamentālas finansiālas un intelektuālas spējas apgūt un uzturēt tehnoloģijas Ja rēķinām izmaksas ne tikai pašam LCMS, bet arī visam personālam un citai projekta īstenošanai nepieciešamajai infrastruktūrai, tad jāsaprot, cik no šiem ieguldījumiem izglītībā, datoros un organizatoriskajā darbā paliks maksātājs un LCMS īpašnieks, un cik norēķināsies ārpusē - ar daudziem darbuzņēmējiem , kuri, protams, būs pateicīgi vispirms par "stipendijas" saņemšanu jaunu tehnoloģiju izstrādei, bet pēc tam par atbalstu viņu izveidotajai sistēmai. Jaunais parasti ir ārkārtīgi dārgs, un nevis tāpēc, ka tas ir dārgs pats par sevi, bet gan tāpēc, ka tas izraisa pārmaiņu lavīnu, ko tas izraisa. Tieši šajā punktā es ņemu vērā kopējās LCMS īpašumtiesību izmaksas, un tajā pašā punktā ir iekļauta visa dzīves cikla apsvēršana, nevis inženiersistēmas ar tās novēršamām sadursmēm, bet gan pašai LCMS.
4. LCMS arhitektūras mērogojamībaŠis kritērijs attiecas uz lieliem inženiertehniskiem projektiem. Tā kā vēlaties, lai sistēmu izmantotu visi tūkstošiem paplašinātās organizācijas cilvēku, tai būs tik strauji jāattīstās. Cik lielā mērā LCMS "pilots" vai "daudzstūris" var ātri augt bez būtiskām arhitektūras izmaiņām? Visticamāk, tie nespēs izaugt. Tāpēc arhitektoniski mums ir vajadzīgs nevis "pilots" vai "daudzstūris", bet gan uzreiz "pirmais posms". Mērogošanas kritērija prasība cieši krustojas ar inkrementalitātes kritērija prasību, taču ietekmē nedaudz citu aspektu - ne tik daudz LCMS izveides pagarināšanu laikā, bet gan paplašināšanas iespēju aptvertajā apjomā. Pieredze rāda, ka visas sistēmas tiek galā ar projektēšanas datu pārbaudes apjomiem, taču tās nevar tikt galā ar rūpnieciskajām. Kā aparatūras un programmatūras izmaksas pieaugs nelineāri, pieaugot apjomam/ātrumam? Cik ilgi tiks izstrādāti noteikumi, kad izrādīsies, ka cauri darba vietai iziet vairāk datu, nekā viens cilvēks spēj jēgpilni apskatīt? Slikta mērogojamība var gaidīt ne tikai no programmatūras un aparatūras risinājuma arhitektūras tehniskās puses, bet arī no tā finanšu arhitektūras puses. Tādējādi neliela licences cena par vienu CLMS vietu vai pat neliela cena par jaunu savienojumu repozitorija serverī var pārvērst vairāk vai mazāk pievilcīgu risinājumu desmit vietām par absolūti finansiāli neilgtspējīgu risinājumu mērķa tūkstoš vietu.
5. Spēja risināt neizbēgamas organizatoriskas problēmas ietverot attieksmi pret mīļotajām mantotajām sistēmām paplašinātajā organizācijā. Cik daudz prasītu piedāvātā centralizētā vai dalītā arhitektūra, lai "atdotu funkcijas citiem departamentiem", "atdotu mūsu datus" un vispār kaut ko "atdotu", salīdzinot ar pašreizējo situāciju bez LCMS? Lieldatori masveidā zaudēja konkurenci minidatoriem un personīgajiem datoriem. Atpakaļceļa gandrīz nav (pie centralizētām sistēmām, ko LCMS neizbēgami uzrāda), jo visi dati atrodas atsevišķās lietojumprogrammās, un šo datu ievilkšana jaunās sistēmās ir ļoti sarežģīts organizatoriskais uzdevums. Kā ir strukturēta LCMS arhitektūra: vai tā aizstāj pašreizējās mantotās inženiertehniskās lietojumprogrammas, vai tā tiek veidota, izmantojot pašreizējo IT infrastruktūru, vai to "bez maksas" uzstāda dažādi pakalpojumi? Cik daudz organizatorisku/vadības/konsultāciju pūļu būs nepieciešams, lai ieviestu jaunas tehnoloģijas? Cik cilvēku atlaist, cik atrast un pieņemt darbā jaunus speciālistus? Šis organizācijas pieņemamības kritērijs ir cieši saistīts ne tikai ar centralizāciju/decentralizāciju, bet arī ar motivācijas sistēmas ievērošanu paplašinātajā uzņēmumā, t.i. LCMS arhitektūras izvērtēšana, pamatojoties uz šo kritēriju, ir daudz plašāka nekā tikai šaura LCMS apskate, bet ir nepieciešama rūpīga paplašinātās organizācijas veidošanas principu analīze, līdz pat to principu pārskatīšanai, kas ir pamatā līgumiem, saskaņā ar kuriem tā tiek veikta. izveidots. Bet tā ir sistēmas pieejas būtība: jebkura mērķa sistēma (šajā gadījumā LCMS) tiek uzskatīta, pirmkārt, nevis "padziļināti, no kurām daļām", bet gan "uz āru, daļa no kā" - nevis tās dizains. un darbības mehānisms galvenokārt ir interesanti, bet atbalstīti LCMS ir sadursmju novēršanas funkcija ārējā supersistēmā - un cena, ko ārējā supersistēma ir gatava maksāt par šo jauno funkciju. Tāpēc iespējamās LCMS arhitektūras tiek aplūkotas galvenokārt nevis pēc "pienācīgām tehnoloģijām, ko izmanto, piemēram, no programmatūras pārdevēja XYZ" (tā ir noklusējuma vērtība: visas piedāvātās arhitektūras parasti ir tehnoloģiski pienācīgas, pretējā gadījumā tās nav izvēles iespējas!), bet gan iepriekšminētie pieci kritēriji.

LCMS funkcijas

1. Izvairīšanās no sadursmēm
   1. Konfigurācijas pārvaldība
      1. Identifikācija (klasifikācijas, kodējumi)
      2. Konfigurācijas uzskaite (visas iespējamās bāzes līnijas — ConOp, Arhitektūra, dizains, kā uzbūvēts), ieskaitot datu pārsūtīšanu uz LCMS repozitoriju, ieskaitot atbalstu darbplūsmas izmaiņām, ieskaitot atbalstu paralēlai projektēšanai (darbs nepilnīgu bāzes līniju apstākļos)
      3. Versiju noteikšana (ieskaitot dakšas)
   2. Manuālas datu pārsūtīšanas trūkums (ievades un izvades datu pārsūtīšana starp jau esošajām automatizācijas salām, ieskaitot datu pārsūtīšanu no vecā dizaina izstrādes "pieaugšanas uz digitālo" salām)
   3. NSI konfigurācija
   4. Sadarbības inženiertehniskā atbalsta sistēma (videokonferences, attālās projektu sesijas utt. — iespējams, ne tā, ko izmantoja pašas LCMS sistēmas izveidei)
2. Sadursmes noteikšana
   1. Atbalsts pārbaudīto sadursmju veidu reģistram un reģistram atbilstošām pārbaudes tehnoloģijām
   2. Datu pārsūtīšana sadursmju pārbaudei starp automatizācijas salām (bez montāžas LCMS repozitorijā, bet ar LCMS integrācijas tehnoloģijas palīdzību)
   3. Darbplūsmas palaišana dažādu veidu sadursmju pārbaudei
      1. LCMS repozitorijā
      2. nevis repozitorijā, bet ar LCMS integrācijas tehnoloģijas palīdzību
   4. Darbplūsmas palaišana, lai atrisinātu atrasto sadursmi (paziņojumu sūtīšana par sadursmēm, jo ​​darbplūsmas izpilde, lai atrisinātu, nav CLMS uzdevums)
   5. Atjaunināta neatrisināto sadursmju saraksta uzturēšana
3. Attīstība(šeit LCMS tiek uzskatīta par autopoētisku sistēmu, jo "inkrementālā ieviešana" ir viena no pašas LCMS vissvarīgākajām īpašībām - tātad tā ir pašas LCMS funkcija, nevis LCMS atbalsta sistēmas funkcija)
   1. Komunikācijas nodrošināšana par LCMS attīstību
      1. Darba plānošana LCMS izstrādei (ceļvedis, rīcības plāna izstrāde)
      2. LCMS projektu biroja darbība,
      3. Sadursmju pārbaužu veidu reģistra uzturēšana (pats "Vēlmju saraksta" reģistrs un pārbaužu īstenošanas ceļvedis)
      4. Organizatoriskā un tehniskā modelēšana (Enterprise Architecture) LCMS
      5. Komunikācijas infrastruktūra LCMS izstrādātājiem (interneta konferences, videokonferences, zināšanu pārvaldība utt. — iespējams, ne tā, ko izmanto sadarbības projektēšanā, izmantojot LCMS)
   2. Datu integrācijas tehnoloģijas vienveidība (piemēram, ISO 15926 tehnoloģija)
      1. Neitrālu datu modeļa izmantošana
         1. Atsauces datu bibliotēkas atbalsts
         2. Atsauces datu izstrāde
      2. Tehnoloģija neitrāla datu modeļa adapteru atbalstam
   3. Vienota darbplūsmas/BPM integrācijas tehnoloģija (plašs uzņēmums)
4. Datu drošība(informācijas sistēmu mērogā, kas darbojas LCMS)
   1. Piekļuves vienotības nodrošināšana (viens pieteikšanās vārds un parole visām informācijas sistēmām, kas piedalās darbplūsmā)
   2. Piekļuves tiesību pārvaldība datu elementiem
   3. Dublējums

Kerolīna Pampino (IBM)
Lietojumprogramma: Rational Team Concert Beta 3, Rational Quality Manager Beta 3, Beta 3

Pārskats

Spēcīga konkurence liek daudzām organizācijām radīt produktus īsākā laikā, vienlaikus padarot tos vēl novatoriskākus. Programmatūras izstrāde pati par sevi ir sarežģīts uzdevums, tāpēc arī sistēmas, ko veido organizācijas, kas izstrādā informācijas sistēmas un ierīces, ir ārkārtīgi sarežģītas. Komandām, kurām ir stingri termiņi, tas jādara, nezaudējot kvalitāti vai nepalielinot budžetu. Lai to izdarītu, viņu stratēģijai vajadzētu būt programmatūras izstrādes efektivitātes uzlabošanai. Šīs dilemmas risinājums ir uzlabot dzīves cikla mijiedarbību, izmantojot lietojumprogrammu dzīves cikla pārvaldību (LCM).

Paredzēti programmatūras izstrādes projektu atbalstam, lietojumprogrammu dzīves cikla pārvaldības risinājumi koordinē cilvēkus, procesus un rīkus iteratīvā programmatūras izstrādes ciklā, kas ietver saistītās darbības: plānošana, izmaiņu pārvaldība, prasību noteikšana un pārvaldība, arhitektūras pārvaldība, programmatūras konfigurācijas pārvaldība, izveide un izvietošana. automatizācija, kvalitātes vadība. Papildus galvenajām LCA risinājumu iezīmēm tie ietver dzīves cikla artefaktu izsekošanu, procesa definīciju un pārliecību, kā arī pārskatu sniegšanu.

Svarīgākais PLC risinājuma ieguvums ir spēja koordinēt projektā iesaistītos cilvēkus, procesus, informāciju un rīkus, lai radītu inovatīvus produktus projektā iesaistītajām pusēm. Tā kā nav universāla risinājuma, mēs iesakām saviem klientiem, ieviešot dzīves cikla pārvaldību, kas vislabāk atbilst viņu organizācijas kultūrai un videi, koncentrēties uz šādiem principiem:

• Izmantojiet reāllaika plānošanu;
• Nodrošināt saistīto artefaktu dzīves cikla izsekošanu;
• Sniegt iespējas mijiedarbībai kontekstā;
• Pielietot biznesa analīzi attīstībai;
• Ieviest pastāvīgus uzlabojumus attīstības procesā.

Reālā laika plānošana

Mēs plānojam, jo ​​vēlamies sasniegt noteiktu mērķi un vēlamies zināt, kad tas tiks sasniegts. Ir tikai viens veids, kā uzzināt, kad darbs ir paveikts. Lai to izdarītu, ir jānodrošina, lai plāni būtu pilnībā integrēti projekta izpildē un vienmēr būtu aktuāli. Nākamajā tabulā ir uzskaitītas dažas tipiskas plānošanas darbības, kuras jums vajadzētu vai nevajadzētu darīt.

Nākamajā attēlā ir parādīts, cik ātri pavadītā laika atjaunināšana tieši no darba vienuma atvieglo plānu precizitāti.

Rīsi. 1. Patērētā laika atjaunināšana no darba pozīcijas saglabā plānus precīzus

Nākamajos trīs attēlos ir parādīti dažādi viena un tā paša iterācijas plāna skati. Skatu izmantošana palīdz komandai līdzsvarot darbu, efektīvi plānot un ātrāk reaģēt uz izmaiņām.

Rīsi. 2. Ieplānotā laika skats parāda, kad dažiem komandas locekļiem ir vairāk darba nekā citiem

Rīsi. 3. Elektronisko uzdevumu paneļa skatu var izmantot elastīgas komandas, kas atrodas ģeogrāfiski

Rīsi. 4. Attīstības plāna skatā tradicionālākā veidā tiek parādīts uzdevumu sadalījums pa dienām un nedēļām

Tālāk esošajā attēlā ir parādīts izlaišanas plāns programmā Rational Team Concert ar saitēm uz saistīto produktu krājumu, prasību kolekcijām programmā Rational Requirements Composer un pārbaudes plāns programmā Rational Quality Manager .

Rīsi. 5. Ar plānošanu ir saistītas prasību kolekcijas un pārbaudes plāni.

IBM Rational risinājums sadarbības dzīves cikla pārvaldībai ietver pilnībā integrētu, reāllaika plānošanu.

Dzīves cikla izsekošana

Izsekošana nav vēl viena jauka programmatūras izstrādes dzīves cikla funkcija. Izsekošana palīdz saprast, ko dara visi pārējie komandā. Piemēram, prasību analītiķis labi zina, kādas prasības viņš ir uzrakstījis, taču viņam ir arī jāzina, vai konkrēta prasība tiks ņemta vērā noteiktā izstrādes iterācijā, un, ja jā, tad kurā. Vai arī viņš vēlas uzzināt, vai šīs prasības izpilde ir pārbaudīta un kāds ir rezultāts.

PLC risinājums, kas ļauj izsekot dzīves cikla artefaktiem, palīdz komandām atbildēt uz sarežģītiem jautājumiem par sava projekta statusu. Izveidojot saites starp artefaktiem, komandām ir vieglāk atbildēt uz tādiem jautājumiem kā: "Kuras prasības ietekmē defekti?" un "Kuri darba vienumi ir gatavi testēšanai?"

Rīsi. 6. Svarīgi jautājumi, uz kuriem atbild LCA risinājums

Izsekošana palīdz katram komandas loceklim saprast, ko dara pārējā komanda un kā tas ietekmē darba apjomu kopumā. Ja strādājat ārēji ierobežotā vidē, izsekošana palīdzēs jums atbildēt uz tādiem auditoru jautājumiem kā "Kādas izmaiņas ir iekļautas šajā būvniecībā, kādi testi tika veikti un ar kādiem rezultātiem?"

Tālāk ir norādītas tipiskas darbības, kas saistītas ar izsekošanu.

Tālāk esošajā attēlā ir parādīts izsekošanas skats laidiena plānam, kurā ir ietvertas prasības un testa gadījumu asociācijas. Plānā ir arī kolonna defektu attēlošanai, kas ietekmē plāna elementus. Šis ir integrēta plāna ar izsekošanas informāciju piemērs. Atšķirībā no novecojušiem, periodiski ģenerētiem izsekošanas ziņojumiem, izmantojot integrētu plānu ar iebūvētu izsekošanas skatu, artefaktu trūkums kļūst acīmredzams un projektā viegli novēršams.

Rīsi. 7. Izlaišanas plāns, kas aptver izstrādi, prasības un testēšanu

Kad ir izveidotas izsekošanas saites, IBM Rational Collaborative Lifecycle Management automātiski izveido izsekošanas saites, pamatojoties uz testēšanas laikā konstatētajiem defektiem. Zemāk redzamajā attēlā redzams defekts ar tam izveidotajām maršrutēšanas saitēm. Kad testēšanas laikā pievienojat defektu, tiek automātiski izveidotas defekta saites uz testa rezultātiem, testa gadījumu, testa plānu, plāna vienumu un prasību.

Rīsi. 8. Dzīves cikla saites, kas automātiski ģenerētas defektam, parāda pārbaudes gadījumus, plāna elementus un prasības, kuras tas ietekmē

Mijiedarbība kontekstā

Mijiedarbība neaprobežojas tikai ar draudzīgu un darba attiecību uzturēšanu. Mijiedarbība uzlabo kvalitāti un rada pievienoto vērtību ieinteresētajām pusēm, kas nozīmē, ka mijiedarbība ir svarīga inovācijai. Sadarbības iespējas LCA risinājumā var uzlabot komandas locekļu spēju sazināties vienam ar otru, reaģēt uz izmaiņām un veicināt projekta paredzamību.

Arī sadarbības rīki palīdz komandām koncentrēties uz svarīgāko. Komandām jāmeklē visas iespējas automatizēt manuālus un neradošus uzdevumus. Labs PLC risinājums ietver būvēšanas un testu izpildes automatizāciju, taču tajā jāiekļauj arī statusa ziņošanas un informācijas piekļuves automatizācija. Projekta informācijas paneļiem un personīgajiem informācijas paneļiem ir svarīga loma, automātiski nodrošinot komandai nepieciešamo informāciju, nodrošinot komandas redzamību un piekļuvi jaunākajiem datiem, izmantojot komandas pārskatus un vaicājumus. Labi izstrādāts lietotāja interfeiss automatizē piekļuvi informācijai, piegādājot informāciju tieši lietotājiem, neliekot viņiem "mainīt kontekstu", pārslēdzoties uz citu lietojumprogrammu. Šādā veidā automatizācija tieši veicina labāku mijiedarbību.

Tālāk esošajā attēlā ir parādīta informācijas paneļu kopa ar logrīkiem, kas satur informāciju no Rational Team Concert, Rational Requirements Composer un Rational Quality Manager. Informācijas paneļos esošie dati parāda pašreizējo projekta statusu.

Rīsi. 9. Informācijas paneļi ar datiem no dažādiem avotiem, nodrošina darba caurskatāmību visām funkcionālajām komandām

Tālāk esošajā attēlā ir redzams mini informācijas panelis, kas vienmēr ir pieejams lietotāja interfeisa malā un var tikt piestiprināts pa kreisi vai pa labi. Tas darbojas kā personalizēts mini informācijas panelis, kas seko lietotājam visā LCA risinājumā un var tikt paslēpts vai parādīts jebkurā laikā.

Rīsi. 10. Mini panelis, kas pieejams no jebkuras lietotāja saskarnes vietas

Nākamajā attēlā redzams personīgais mini bārs programmā Rational Team Concert. Šajā panelī ir logrīks, kas parāda Rational Requirements Composer prasību izmaiņas. Šis ir mini paneļa piemērs ar informāciju no dažādiem avotiem. Novietojot kursoru virs prasības, tiek parādīts priekšskatījums ar informāciju par prasības statusu prasību sastādītājā. Lietotāji, kuriem nepieciešama ātra piekļuve informācijai, ātri pieradīs pie mini paneļiem.

Biznesa inteliģence attīstībai

Kā zināt, vai kaut kas uzlabojas, ja nedefinējat veiksmes rādītājus? Vai jebkurā projekta brīdī varat pateikt, vai komanda virzās uz veiksmīgu iznākumu? Jomu noteikšana, kurās nepieciešami uzlabojumi, mērķu noteikšana un progresa izsekošana šo mērķu sasniegšanai ir tas, kas palīdz attīstīt biznesa inteliģenci attīstībai.

Saskaņā ar Capers Jones 1, projekti, kuros plaši tiek izmantota mērīšanas prakse, ir daudz veiksmīgāki nekā tie, kas to nedara.

Rīsi. 12. Projektiem, kuros tiek izmantota mērīšanas prakse, ir lielāka iespēja gūt panākumus

Piemēram, šādus trīs rādītājus izmanto mazāk nekā 50% Capers Jones pētniecības organizāciju.

• Kvalitātes rādītāji 45%
• Produktivitātes rādītāji 30%
• Gatavības rādītāji 15%

Tālāk esošajā attēlā ir parādīti izstrādes komandas pārskati projekta informācijas panelī. Kad darba vienums tiek atjaunināts, pārskati atspoguļo komandas darbību un virzienu. Izmantojiet progresa diagrammas, lai izsekotu komandas progresam ieplānotā darba pabeigšanā. Vai arī izmantojiet diagrammas, kas parāda izmaiņas darba vienumu skaitā stāvokļos "Atvērts", "Notiek procesā" un "Aizvērts" (ideālā gadījumā vienumu skaits stāvokļos "Atvērts" un "Notiek". vajadzētu samazināties, savukārt tiem, kas atrodas "Slēgtā" - augt).

Rīsi. 13. Informācijas panelis ar pārskatiem un metriku uzlabojumu mērīšanai

Informācijas paneļi un atskaites ir galvenā LCA risinājuma sastāvdaļa, kas ir atbildīga par komandas pašreizējā progresa mērīšanu un reaģēšanu uz to.

Attīstības procesa nepārtraukta uzlabošana

Process ir vairāk nekā dokumentēts darbību kopums. Mēs izstrādājam procesus, pamatojoties uz labāko praksi, kas iegūta no nozares pieredzes, lai uzlabotu komandas komunikāciju un palielinātu izredzes gūt panākumus. Uzvedību lielā mērā nosaka ieradums. Kad jūs definējat vai maināt procesu, jūs faktiski lūdzat visu komandu mainīt savus ieradumus un pieņemt uzvedību, kas viņiem var nebūt skaidra no pirmā acu uzmetiena. Ir diezgan grūti mainīt viena cilvēka ieradumus. Lai mainītu procesu, bieži vien ir jāmaina cilvēku domāšanas un uzvedības veids. Labi izstrādāts LCM risinājums ļauj pakāpeniski mainīt procesu, uzlabojot komandas dinamiku un turpinot virzīties uz lielāku efektivitāti.

Analizējot izstrādes rīku tirgus attīstību pēdējo 10-15 gadu laikā, var atzīmēt vispārēju tendenci, ka uzsvars tiek novirzīts no programmu faktiskās rakstīšanas tehnoloģijām (kas kopš 90. gadu sākuma iezīmējās ar RAD instrumenti - "ātrā lietojumprogrammu izstrāde") līdz nepieciešamībai pēc integrētas visa lietojumprogrammu dzīves cikla pārvaldība - ALM (Application Lifecycle Management) .

Pieaugot programmatūras projektu sarežģītībai, strauji pieaug prasības to ieviešanas efektivitātei. Tas ir vēl jo svarīgāk mūsdienās, kad programmatūras izstrādātāji ir iesaistīti gandrīz visos uzņēmumu darba aspektos un šādu speciālistu skaits pieaug. Tajā pašā laikā pētījumu dati šajā jomā liecina, ka vismaz pusei "iekšējo" programmatūras izstrādes projektu rezultāti neattaisno uz tiem liktās cerības. Šādos apstākļos īpaši steidzams kļūst uzdevums optimizēt visu programmatūras rīku izveides procesu, aptverot visus tā dalībniekus - dizainerus, izstrādātājus, testētājus, atbalsta pakalpojumus un vadītājus. Lietojumprogrammu dzīves cikla pārvaldība (ALM) uzskata programmatūras izlaišanas procesu kā pastāvīgi atkārtotu savstarpēji saistītu posmu ciklu:

prasību definēšana (Prasības);

projektēšana un analīze (Design & Analysis);

Attīstība (Attīstība);

testēšana (pārbaude);

izvietošana un uzturēšana (Deployment & Operations).

Katra no šīm darbībām ir rūpīgi jāuzrauga un jākontrolē. Pareizi organizēta ALM sistēma ļauj:

Samazināt laiku, kas nepieciešams produktu laišanai tirgū (izstrādātājiem ir tikai jārūpējas par savu programmu atbilstību formulētajām prasībām);

uzlabot kvalitāti, vienlaikus nodrošinot, ka lietojumprogramma atbildīs lietotāju vajadzībām un cerībām;

palielināt produktivitāti (izstrādātāji iegūst iespēju dalīties ar labāko praksi izstrādē un ieviešanā);

Paātrināt attīstību, integrējot rīkus;

· samazināt uzturēšanas izmaksas, pastāvīgi saglabājot konsekvenci starp pieteikumu un tā projekta dokumentāciju;

Iegūstiet maksimālu labumu no ieguldījumiem prasmēs, procesos un tehnoloģijās.

Stingri sakot, pati ALM koncepcija, protams, nav nekas principiāli jauns – šāda izpratne par programmatūras izveides problēmām radās pirms aptuveni četrdesmit gadiem, rūpnieciskās attīstības metožu veidošanās rītausmā. Tomēr vēl salīdzinoši nesen galvenie centieni programmatūras izstrādes uzdevumu automatizācijā bija vērsti uz rīku izveidi tieši programmēšanai kā laikietilpīgākajam posmam. Un tikai 80. gados programmatūras projektu sarežģītības dēļ situācija sāka būtiski mainīties. Vienlaikus ir strauji pieaugusi attīstības rīku funkcionalitātes paplašināšanas aktualitāte (jēdziena plašā nozīmē) divās galvenajās jomās: 1) visu pārējo programmatūras dzīves cikla posmu automatizācija un 2) rīku integrācija ar viens otru.

Ar šiem uzdevumiem tika galā daudzi uzņēmumi, taču šeit neapšaubāms līderis bija Rational, kas jau vairāk nekā divdesmit gadus, kopš dibināšanas, ir specializējies programmatūras izstrādes procesu automatizācijā. Savulaik tieši viņa kļuva par vienu no pionierēm plašā vizuālo metožu izmantošanā programmu projektēšanai (un praktiski UML valodas autore, kas de facto tika pieņemta kā standarts šajā jomā), izveidoja kopīgu ALM. metodiku un atbilstošu instrumentu kopumu. Var teikt, ka līdz šī gadsimta sākumam Rational bija vienīgais uzņēmums, kura arsenālā bija pilns produktu klāsts ALM atbalstam (no biznesa dizaina līdz apkopei), izņemot vienu instrumentu klasi - parastie kodēšanas rīki. Tomēr 2003. gada februārī tā beidza pastāvēt kā neatkarīga organizācija un kļuva par IBM korporācijas nodaļu ar nosaukumu IBM Rational.

Vēl pavisam nesen Rational bija praktiski vienīgais ALM klases integrēto izstrādes rīku ražotājs, lai gan noteiktiem programmatūras izstrādes posmiem bija un ir konkurējoši rīki no citiem pārdevējiem. Taču pirms pāris gadiem tradicionālo aplikāciju izstrādes rīku (Delphi, JBuilder u.c.) jomā vienmēr spēcīgas pozīcijas ieņēma Borland Corporation, kas faktiski ir korporācijas ALM kompleksa pamatā, kas tika paplašināts cauri. citu uzņēmumu, kas ražo līdzīgus produktus, iegāde. Tā ir fundamentālā atšķirība starp abu uzņēmumu biznesa modeļiem, kas paver potenciālas iespējas reālai konkurencei. Pēc tam, kad Rational kļuva par daļu no IBM, Borland pozicionē sevi kā vienīgo neatkarīgo visaptverošas ALM platformas piegādātāju mūsdienās (tas ir, tas nereklamē savas operētājsistēmas, valodas utt.). Savukārt konkurenti atzīmē, ka Borland vēl nav formulējis skaidru ALM metodiku, kas dotu pamatu tam esošo rīku apvienošanai.

Vēl viens nozīmīgs spēlētājs izstrādes rīku jomā ir Microsoft Corporation. Kamēr viņa nedraud izveidot savu ALM platformu; veicināšana šajā virzienā ir tikai sadarbības ietvaros ar citiem piegādātājiem, to pašu Rational un Borland (abi kļuva par pirmajiem Visual Studio Industry Partner programmas dalībniekiem). Tajā pašā laikā Microsoft vadošais Visual Studio .NET izstrādes rīks pastāvīgi paplašina funkcionalitāti, izmantojot augsta līmeņa modelēšanas un projektu pārvaldības rīkus, tostarp integrējot ar Microsoft Visio un Microsoft Project.

Jāatzīmē, ka mūsdienās gandrīz visi vadošie uzņēmumi, kas izstrādā tehnoloģijas un programmatūras produktus (izņemot iepriekš uzskaitītos, var nosaukt Oracle, Computer Associates u.c.), ir izstrādājuši programmatūras izveides tehnoloģijas, kuras tika radītas gan pašu spēkiem, gan ar programmu starpniecību. produktu iegāde.un mazo specializēto uzņēmumu radītās tehnoloģijas. Un, lai gan, tāpat kā Microsoft, viņi vēl neplāno izveidot savu ALM platformu, šo uzņēmumu izlaistie CASE rīki tiek plaši izmantoti atsevišķos programmatūras dzīves cikla posmos.

ALM sistēmas ļauj nodrošināt caurspīdīgumu, skaidru izpratni par aplikāciju izstrādes procesu un pasniegt to kā vienu no biznesa procesiem. Tomēr ALM nevajadzētu uzskatīt tikai par līdzekli atbilstības uzraudzībai un kontrolei, brīdina analītiķi. Šīs sistēmas ir paredzētas ne tik daudz kontrolei, cik izstrādes procesa automatizēšanai un dažādu rīku integrēšanai.

Lielākā problēma ar ALM rīku ieviešanu ir tā, ka cilvēki nesaprot izstrādes procesu. Bieži vien vadība pieņem, ka ALM spēs paveikt lietas precīzi definētā veidā. Tomēr visu iepriekš nav iespējams plānot. Lietojumprogrammu izstrādē bieži katrā solī ir jāiziet vairākas iterācijas, jāizlaiž starpposma versijas un pakāpeniski jāpalielina lietojumprogrammas funkcionalitāte. ALM sistēmai nevajadzētu ierobežot izstrādātāju darbības, bet gan atvieglot procesu.

IT nozarei ļoti patīk runāt par šķēršļiem starp IT un biznesu, taču pašā IT organizācijā ir daudz mazāk pamanāmu šķēršļu, kas var traucēt neuzmanīgam sistēmu integratoram.

Apsveriet, piemēram, vienu no šodien vispretrunīgākajām un karstāk apspriestajām tēmām IT jomā - DevOps metodoloģiju un visu, kas ar to saistīts. Īsi raksturojot visas darbības, kas saistītas ar izstrādātās aplikācijas nodošanu IT servisam reālai darbībai, šie vārdi izklausās pietiekami nekaitīgi. Bet kopumā starp uzņēmuma lietojumprogrammu izstrādātājiem un speciālistiem, kas pārvalda uzņēmuma IT infrastruktūru, pastāv pārpratumu siena. Programmētāji bieži vaino IT elastības trūkumā, un cilvēki, kas pārvalda ikdienas IT darbības, ignorē ražošanas infrastruktūras ierobežojumus un prasības, kurā jādarbojas viņu izveidotajām lietojumprogrammām.

Šī spriedze veicina pieaugošu interesi par lietojumprogrammu dzīves cikla pārvaldības tehnoloģiju. ALM), kas ir vadīklu kopa, kas paredzēta, lai programmētājiem un IT darbiniekiem sniegtu skaidrāku izpratni par izstrādājamās lietojumprogrammas būtību un infrastruktūru, kurā lietojumprogrammai jādarbojas. Galvenā ideja ir tāda, ka, atvieglojot sadarbību starp izstrādātājiem un IT speciālistiem, tiks nodrošināta efektīvāka visas korporatīvās informācijas vides darbība. Problēma ir tā, ka ALM ieviešanai ir mazas izredzes situācijā, kad divas puses, kuru sadarbība ir nepieciešama projekta veiksmīgai īstenošanai, sāk novelt atbildību par radušajām grūtībām viena uz otru.

Lai veiksmīgi ieviestu ALM metodoloģiju, sistēmas integratoram ir jāpaceļas virs IT nodaļas pārmetumu līmeņa. Saskaņā ar Gina Poole, nodaļas mārketinga viceprezidente IBM Rational programmatūra, tas nozīmē, ka jāatrod un jāpieņem darbā IT direktors vai finanšu direktors, kurš spēj saprast, cik daudz naudas klients zaudē visu IT nodaļas dienestu koordinēta darba trūkuma dēļ. Kļūdu labošana lietojumprogrammā izstrādes projekta vēlīnā stadijā nozīmē ārkārtīgi lielas izmaksas. Ja nepieciešamību pēc šādas korekcijas rada izstrādātāja iepriekšējie pieņēmumi par vidi, kurā aplikācija darbosies, un šie pieņēmumi beigu beigās izrādās nepareizi, tad visa projekta izmaksas ievērojami pieaug, vai arī pasūtītājs būt spiestam attiecīgi uzlabot savu infrastruktūru.

Protams, šādu pretrunu atrisināšana organizācijas IT infrastruktūrā var izmaksāt dārgi. Taču šī darba vienīgajam gala mērķim jābūt tāda pārvaldības tehnoloģiju kopuma izveidei un ieviešanai, kas ļautu programmētājiem un IT operāciju speciālistiem pārstāt iejaukties viens otra darbā. Jo vairāk laika programmētāji pavada, apspriežot sadarbību ar IT, jo mazāk laika viņiem atliek reālai attīstībai. Jo vairāk aplikāciju tiks izveidots, jo attīstītāka infrastruktūra būs nepieciešama, un tā, protams, ir laba ziņa tālākpārdevējiem.

Kopumā DevOps debates noteikti ir izdevīgas tālākpārdevējiem un integratoriem. Problēma ir neiesaistīties iekšējos konfliktos, kas saistīti ar vēlmi paralēli vadīt pārāk daudz IT projektu. Ja klients nepieņem pašu ALM koncepciju, tas patiesībā ir ļoti labs rādītājs viņa brieduma trūkumam un vājajai kompetencei IT vadībā. Tas pats par sevi liecina, ka tālākpārdevējam ir labāk palikt tālāk no šāda klienta, jo pastāv liela varbūtība, ka šāds klients radīs vairāk problēmu nekā peļņas.