Det er kjent at mange brukere (og, for å være ærlig, noen IT-spesialister) når de snakker om programvareutvikling, først og fremst betyr opprettelse og feilsøking av applikasjonskode. Det var en tid da slike ideer var nær nok til sannheten. Men moderne applikasjonsutvikling består ikke bare og ikke så mye av å skrive kode, men av andre prosesser, både forut for selve programmeringen og etter den. Egentlig vil de bli diskutert videre.

Applikasjonsutvikling livssyklus: drømmer og virkelighet

Det er ingen hemmelighet at mange kommersielt vellykkede produkter, både i Russland og i utlandet, ble implementert med bare applikasjonsutviklingsverktøy, og til og med dataene ble ofte designet på papir. Det ville ikke være en overdrivelse å si det av alle mulige verktøy for å lage programvare i Russland (og i mange europeiske land) nå hovedsakelig applikasjonsutviklingsverktøy og, i mindre grad, datadesignverktøy er populære (primært for prosjekter med et lite budsjett og stramme tidsfrister). All prosjektdokumentasjon, som starter med den tekniske oppgaven og slutter med brukermanualen, lages ved hjelp av tekstredigerere, og det faktum at noe av det er kildeinformasjonen til programmereren betyr bare at han bare leser den. Og dette til tross for at på den ene siden har kravstyringsverktøy, forretningsprosessmodellering, applikasjonstestverktøy, prosjektstyringsverktøy og til og med verktøy for generering av prosjektdokumentasjon eksistert i lang tid, og på den andre siden enhver prosjektleder ønsker naturlig å legge til rette for livet for seg selv og for andre utøvere.

Hva er årsaken til mange prosjektlederes mistro til verktøy som lar deg automatisere mange stadier av arbeidet til teamene de leder? Etter min mening er det flere årsaker til dette. Den første av dem er at verktøyene som brukes av selskapet svært ofte ikke integreres godt med hverandre. Tenk på et typisk eksempel: Rational Rose brukes til modellering, Delphi Professional brukes til å skrive kode, CA AllFusion Modeling Suite brukes til datadesign; integreringsverktøy for disse produktene er enten ikke tilgjengelige i det hele tatt for denne kombinasjonen av versjonene deres, eller de fungerer ikke korrekt med det russiske språket, eller de har rett og slett ikke blitt kjøpt. Som et resultat blir use case-diagrammer og andre modeller laget med Rose ikke annet enn bilder i designdokumentasjonen, og datamodellen fungerer hovedsakelig som en kilde for å svare på spørsmål som: "Hvorfor er dette feltet til og med nødvendig i den tabellen?" Og selv så enkle deler av applikasjonen som de russiske ekvivalentene til databasefeltnavn er skrevet av prosjektdeltakere minst tre ganger: én gang når man dokumenterer datamodellen eller applikasjonen, andre gang når man skriver brukergrensesnittkode, og tredje gang når man oppretter en hjelpesystemfil og brukermanualer.

Den andre, ikke mindre alvorlige grunnen til mistillit til programvarelivssyklusstøtteverktøy, er at igjen, på grunn av mangelen eller dårlig funksjonalitet til integreringsverktøy for slike produkter, kan det i mange tilfeller ikke være mulig å konstant synkronisere alle deler av prosjektet. med hverandre: prosessmodeller, datamodeller, applikasjonskode, databasestruktur. Det er tydelig at et prosjekt som implementerer det klassiske fossefallsskjemaet (fig. 1), hvor krav først formuleres, deretter modellering og design utføres, deretter utvikling og til slutt implementering (du kan lese om denne ordningen og andre prosjekter implementeringsmetodikk i en serie anmeldelser av Lilia Hough, publisert i vårt magasin), er mer en drøm enn en realitet – mens koden skrives vil kunden ha tid til å endre deler av prosessene eller ønske seg ekstra funksjonalitet. Som følge av prosjektet innhentes det ofte en søknad som er svært langt unna det som er beskrevet i mandat, Og database, som har lite til felles med den opprinnelige modellen, og synkroniseringen av alt dette med hverandre med det formål å dokumentere og overføre til kunden blir en ganske møysommelig oppgave.

En tredje grunn til at støtteverktøy for programvarelivssyklus ikke brukes alle steder der de kan være nyttige, er at de har så begrenset valg. På russisk marked to produktlinjer markedsføres aktivt: IBM/Rational-verktøy og Computer Associates-verktøy (hovedsakelig AllFusion Modeling Suite-produktlinjen), som for tiden i stor grad er fokusert på visse typer modellering, og ikke på den konstante prosessen med synkronisering av kode, database og modeller.

Det er en annen grunn som kan tilskrives kategorien psykologiske faktorer: det er utviklere som ikke i det hele tatt streber etter fullstendig formalisering og dokumentasjon av søknadene deres - tross alt blir de i dette tilfellet uunnværlige og verdifulle ansatte, og en person som er tvunget til å forstå etter oppsigelsen av en slik utvikler i hans kode eller bare følger med produktet hans vil føles i svært lang tid fullstendig idiot. Slike utviklere er selvfølgelig på ingen måte i flertall, likevel kjenner jeg minst fem bedriftsledere som har blitt bortskjemt med mye blod av slike tidligere ansatte.

Selvfølgelig vil mange prosjektledere, spesielt prosjekter med et lite budsjett og begrenset tid, gjerne ha et verktøy som de kan formulere krav til det utviklede programvareproduktet med ... og som et resultat få et ferdig distribusjonssett med en fungerende applikasjon. Dette er selvfølgelig bare et ideal, som man foreløpig bare kan drømme om. Men går du ned fra himmelen til jorden, så kan du formulere mer spesifikke ønsker, nemlig:

1. Verktøy for styring av krav bør forenkle opprettelsen av applikasjonsmodellen og datamodellen.

2. Basert på disse modellene bør en betydelig del av koden genereres (helst ikke bare klient, men også server).

3. En betydelig del av dokumentasjonen bør genereres automatisk, og på språket i landet som denne søknaden er ment for.

4. Ved oppretting av applikasjonskoden skal det skje automatiske endringer i modellene, og når modellen endres skal det skje automatisk kodegenerering.

5. Kode skrevet for hånd skal ikke forsvinne når det gjøres endringer i modellen.

6. Fremkomsten av et nytt kundekrav bør ikke forårsake alvorlige problemer knyttet til endringer i modeller, kode, database og dokumentasjon; alle endringer må gjøres synkront.

7. Versjonskontrollverktøy for alle de ovennevnte bør være praktiske når det gjelder å finne og spore endringer.

8. Og til slutt, alle disse dataene (krav, kode, modeller, dokumentasjon) bør være tilgjengelig for prosjektdeltakere nøyaktig i den grad de trenger dem for å utføre sine oppgaver - verken mer eller mindre.

Med andre ord bør applikasjonsutviklingssyklusen muliggjøre iterativ samarbeidsutvikling uten ekstra kostnad ved å endre kundekrav eller hvordan de implementeres.

Jeg vil ikke forsikre deg om at alle disse ønskene er helt umulige å implementere ved hjelp av IBM / Rational eller CA-verktøy - teknologier utvikles, nye produkter dukker opp, og det som var umulig i dag vil bli tilgjengelig i morgen. Men som praksis viser, er integrasjonen av disse verktøyene med de mest populære utviklingsverktøyene, dessverre, langt fra så ideell som det kan virke ved første øyekast.

Borland-produkter fra en prosjektleders perspektiv

Borland er en av de mest populære utviklerne av utviklingsverktøy: i tjue år har produktene vært velfortjent kjærlighet til utviklere. Inntil nylig tilbød dette selskapet hovedsakelig et bredt spekter av verktøy beregnet direkte for applikasjonskodere - Delphi, JBuilder, C++Builder, Kylix (vi har gjentatte ganger skrevet om alle disse produktene i magasinet vårt). Imidlertid bestemmes suksessen til et selskap i markedet i stor grad av hvor mye det følger trendene i utviklingen og hvor mye det forstår behovene til de som er forbrukere av produktene deres (i denne saken- selskaper og avdelinger som spesialiserer seg på applikasjonsutvikling).

Derfor er Borlands nåværende utviklingsstrategi å støtte hele applikasjonens livssyklus (Application Lifecycle Management, ALM), inkludert kravdefinisjon, design, utvikling, testing, implementering og vedlikehold av applikasjoner. Dette er bevist av oppkjøpet av en rekke selskaper av Borland Corporation i fjor - BoldSoft MDE Aktiebolag (en ledende leverandør av den nyeste modelldrevne arkitekturen applikasjonsutviklingsteknologi), Starbase (en leverandør avktøy for programvareprosjekter), TogetherSoft Corporation (en leverandør av programvareutviklingsløsninger). I tiden som har gått siden oppkjøpet av disse selskapene har det blitt gjort mye arbeid med å integrere disse produktene med hverandre. Som et resultat oppfyller disse produktene allerede behovene til prosjektledere for muligheten for iterativ samarbeidsutvikling. Nedenfor diskuterer vi hva Borland tilbyr til ledere og andre deltakere i prosjekter relatert til programvareutvikling (mange av produktene og integrasjonsteknologiene beskrevet nedenfor ble presentert av dette selskapet på utviklerkonferansene som ble holdt i San Jose, Amsterdam og Moskva i november) .

Styring av krav

Kravhåndtering er en av de viktigste delene av utviklingsprosessen. Uten formulerte krav er det som regel nesten umulig å organisere arbeidet med prosjektet normalt, eller å forstå om kunden virkelig ønsket å få akkurat det som ble gjennomført.

I følge analytikere brukes minst 30 % av prosjektbudsjettet på det som kalles å omarbeide søknaden (og jeg personlig synes at dette tallet er sterkt undervurdert). Dessuten er mer enn 80% av dette arbeidet forbundet med feil eller unøyaktig formulerte krav, og korrigering av slike feil er vanligvis ganske dyrt. Og hvor mye kundene liker å endre krav når applikasjonen nesten er klar, vet nok alle prosjektledere ... Det er av denne grunn at kravstyring bør vies størst oppmerksomhet.

For kravstyring har Borland et produkt Borland CaliberRM, som i hovedsak er en plattform for automatisering av kravstyringsprosessen, og gir endringssporingsverktøy (fig. 2).

CaliberRM integreres med mange utviklingsverktøy fra både Borland og andre produsenter (for eksempel Microsoft), opp til å bygge inn en liste med krav i utviklingsmiljøet og generere kodestubber ved å dra kravikonet inn i koderedigereren med musen. I tillegg kan du lage dine egne løsninger basert på det - for dette er det et spesielt sett med verktøy CaliberRM SDK.

Merk at dette produktet brukes til å administrere krav, ikke bare for programvare, men også for andre produkter. Det er derfor kjent tilfeller av vellykket bruk i bilindustrien for å håndtere kravene til ulike kjøretøykomponenter (inkludert Jaguar-kjøretøyer). I tillegg, ifølge Jon Harrison, leder med ansvar for JBuilder-produktlinjen, forenkler bruken av CaliberRM for å lage Borland JBuilderX prosessen med å utvikle dette produktet.

Og til slutt, tilgjengeligheten av et praktisk kravstyringsverktøy forenkler i stor grad opprettelsen av prosjektdokumentasjon, og ikke bare i tidlige stadier. prosjektstadier, men også på alle etterfølgende.

Applikasjons- og datadesign

Design er en like viktig del av å lage en søknad og bør være basert på de formulerte kravene. Designresultatene er modeller som brukes av programmerere på stadiet av kodeoppretting.

For design av applikasjoner og data tilbyr Borland produktet Borland Together (fig. 3), som er en plattform for å analysere og designe applikasjoner som integreres med ulike utviklingsverktøy fra både Borland og andre produsenter (spesielt Microsoft). Det spesifiserte produktet tillater modellering og design av applikasjoner og data; samtidig er graden av integrasjon med utviklingsverktøy for øyeblikket slik at endringer i datamodellen fører til en automatisk endring i applikasjonskoden, så vel som endringer i koden fører til en endring i modellene ( denne teknologien integrering av modelleringsverktøy og utviklingsverktøy kalles LiveSource).

Borland Together kan brukes som et verktøy som kobler kravstyring og modelleringsoppgaver med utviklings- og testoppgaver og hjelper deg å forstå hva produktkravimplementeringen bør være.

Opprette applikasjonskoden

Oppretting av applikasjonskode er et område som Borland har spesialisert seg på gjennom sine 20 år. I dag produserer Borland utviklingsverktøy for Windows, Linux, Solaris, Microsoft .NET-plattformer, samt for en rekke mobile plattformer. Vi har gjentatte ganger skrevet om utviklingsverktøyene til dette selskapet, og vi vil ikke gjenta oss selv i denne artikkelen. Vi bemerker bare at de nyeste versjonene av utviklingsverktøyene til dette selskapet (Borland С#Builder, Borland C++BuilderX, Borland JBuilderX), så vel som forventet snart en ny versjon et av de mest populære utviklingsverktøyene i vårt land, Borland Delphi 8 for Microsoft .NET Framework, tillater tett integrasjon av Together-modelleringsverktøy og CaliberRM-kravstyringsverktøy med deres utviklingsmiljøer. Vi vil definitivt dekke Delphi 8 i en egen artikkel i neste nummer av magasinet vårt.

Testing og optimalisering

Testing er en helt essensiell del av å lage kvalitetsprogramvare. Det er på dette stadiet det kontrolleres om applikasjonen tilfredsstiller de formulerte kravene til den, og det gjøres passende endringer i applikasjonskoden (og ofte i modeller og databaser). Testfasen krever vanligvis bruk av applikasjonsytelsesanalyse og optimeringsverktøy, og Borland Optimizeit Profiler brukes til dette formålet. I dag er dette produktet også integrert i utviklingsmiljøer siste versjoner Borland utviklingsverktøy, samt inn i Microsoft Visual Studio .NET-miljøet (fig. 4).

Gjennomføring

Programvareimplementering er en av de viktigste komponentene for prosjektsuksess. Det bør utføres på en slik måte at produktet på prøvedriftsstadiet kan endres uten alvorlige kostnader og tap, det er lett å øke antall brukere uten å redusere påliteligheten. Siden applikasjonsadopsjon i dag skjer i en kontekst hvor bedrifter bruker forskjellige teknologier og plattformer og driver en rekke eksisterende applikasjoner, kan muligheten til å integrere en ny applikasjon med eldre systemer være viktig under utrulling. For dette formålet tilbyr Borland en rekke tverr(som Borland Janeva, som tillater integrasjon av .NET-applikasjoner med applikasjoner basert på CORBA- og J2EE-teknologier).

Endringsledelse

Endringshåndtering utføres i alle stadier av applikasjonsoppretting. Fra Borlands ståsted er dette den viktigste komponenten i prosjektet – det kan tross alt skje endringer i krav, og i kode, og i modeller. Det er vanskelig å styre et prosjekt uten å spore endringer – prosjektlederen må være klar over hva som akkurat skjer på dette stadiet og hva som allerede er implementert i prosjektet, ellers risikerer han å ikke fullføre prosjektet i tide.

For å løse dette problemet kan du bruke Borland StarTeam (fig. 5) et skalerbarttrasjonsverktøy som lagrer alle nødvendige data i et sentralisert depot og optimerer samhandlingen mellom ansatte som er ansvarlige for å utføre ulike oppgaver. Dette produktet gir et team av prosjektdeltakere en rekke verktøy for å publisere krav, administrere oppgaver, planlegge, arbeide, diskutere endringer, versjonskontroll, dokumenthåndtering.

Funksjonene til dette produktet er tett integrasjon med andre Borland-produkter, støtte for distribuerte utviklingsteam som samhandler over Internett, tilstedeværelsen av flere typer klientgrensesnitt (inkludert webgrensesnittet og Windows-grensesnittet), støtte for mange plattformer, og operativsystemer, tilstedeværelsen av StarTeam Software Development Kit (SDK), som er et applifor å lage løsninger basert på StarTeam, databeskyttelsesverktøy på klient- og serversiden, verktøy for tilgang til Merant PVCS Version Manager og Microsoft Visual SourceSafe repositories, integrasjon verktøy med Microsoft Project, datavisualisering, rapportering og beslutningsstøtteverktøy.

I stedet for en konklusjon

Hva er utseendet på det russiske markedet til det ovennevnte settet med produkter fra en kjent produsent hvis utviklingsverktøy er mye brukt i en rekke prosjekter? Som et minimum, det faktum at vi i dag vil kunne få ikke bare et sett med verktøy for ulike prosjektdeltakere, men også en integrert plattform for implementering av hele utviklingens livssyklus - fra kravdefinisjon til implementering og vedlikehold (fig. 6). . Samtidig vil denne plattformen, i motsetning til sine konkurrerende produktsett, garantere støtte for alle de mest populære utviklingsverktøyene og vil tillate deg å integrere komponentene dine i dem på nivået med full kodesynkronisering med modeller, krav og endringer. Og la oss håpe at prosjektledere puster lettet ut og sparer seg selv og sine ansatte for mange kjedelige og rutinemessige oppgaver...

Programvareutvikling er en ganske kompleks oppgave. Opprettelse av et programvareprodukt med tilstrekkelig veldefinerte egenskaper, utført med akseptabel kvalitet, innenfor det tildelte budsjettet og i tide, krever konstant koordinering av et stort antall handlinger mellom en rekke spesialister. I løpet av de siste 15 årene har utviklingen av programvareprodukter blitt en fullverdig industri, det er ikke plass for en udokumentert, rent individuell tilnærming, derfor er det naturlig at fremveksten av ledelsesmetodikk har blitt en merkbar trend. Livssyklus applikasjoner .

Selvfølgelig, i prosessen med programvareutvikling er det et sted for kunsten til talentfulle programmerere og faglig fortreffelighet andre deltakere i prosessene med å lage et programvareprodukt, men i dag har det blitt en sentral erkjennelse av at det i denne aktiviteten ikke er plass for usammenheng, udokumenterthet og diktat fra individet. En av de mest bemerkelsesverdige trendene i det første tiåret av dette århundret i programvaresystemindustrien var fremveksten av ALM (Application Lifecycle Management, ALM) - applikasjonslivssyklusadministrasjon .

En slik tilnærming bør bringe ledelsesdisiplin inn i utviklingen, vurdere etableringen av et programvareprodukt som en forretningsprosess og ta hensyn til dets sykliske natur. I samsvar med ideen om ALM, slutter ikke arbeidet med enhver programvareløsning på idriftsettelsesstadiet: systemet er modernisert og forbedret, nye versjoner utgis, som hver gang starter neste runde av applikasjonens livssyklus.

Forrester Research-analytikere sammenligner ALM med ERP for programvareindustrien. Riktignok er historien til ALM mye kortere og kan ennå ikke skilte med en sammenlignbar liste over vellykkede implementeringer. Analytikere erkjenner det til tross objektiv nødvendighet i slike løsninger er ALM-verktøy fortsatt av begrenset bruk, og deres marked er fortsatt fragmentert. Markedsovervåkere mener at ingen av de nåværende ALM-tilbudene fullt ut realiserer de fulle potensielle fordelene og mulighetene til automatiseringsverktøy forsjon. Utviklingen av utviklingen mot kontrollerte, forutsigbare, effektive prosesser for å lage pålitelig og høykvalitets programvare kan imidlertid ikke annet enn å bli ledsaget av fremveksten av passende plattformer for å automatisere disse prosessene.

ALM-leverandører tilbyr en rekke verktøy og teknologier for å støtte programvareutviklingsprosessen. Disse verktøyene går langt utover de tradisjonelle produktivitetsverktøyene til den enkelte utvikler. De er rettet mot å tilby metoder og verktøy fokusert på det kollektive arbeidet med programvareutvikling. For å skape en levedyktig ALM-løsning, må leverandører vurdere behovene til det "utvidede" programvareutviklingsteamet og inkludere roller i produktene deres som deltar i den større prosessen.

IT-ekspert D. Chappel advarer mot et forenklet syn på ALM, som ofte bare identifiseres med programvareutviklingens livssyklus (Software Development LifeCycle, SDLC): initiering, iterativ utviklingssyklus, produktutgivelse og implementering. Disiplinen til ALM dekker et bredere spekter av oppgaver, med tanke på alle aspekter ved eksistensen av en slik bedriftsressurs som applikasjoner. I henhold til D. Chappels definisjon inkluderer livssyklusen til en applikasjon alle stadier der en organisasjon investerer i denne ressursen på en eller annen måte - fra den første ideen om en programvareløsning til avhending av end-of-life programvare.

Denne definisjonen er ekstremt detaljert i HP - ifølge selskapet er syklusen bare ett av stadiene i en fullverdig modell

ALM er applikasjonsleveringsfasen (Figur 3.14), og i tillegg er det også planlegging, drift og dekommisjonering. Syklusen er stengt: til det øyeblikket når organisasjonen kommer til den endelige konklusjonen om ubrukeligheten av applikasjonen, fortsetter den å forbedre seg. Kompetent gjennomføring av ALM er blant annet rettet mot å forlenge løpetiden effektivt arbeid programvareløsning og som et resultat redusere kostnadene ved å kjøpe eller lage fundamentalt nye programvareprodukter.

Bedriftsbehovsanalyse

Prioritet og investering

Wor4dlenne SHSHDOISH "Overvåking av programmer

Fullkommenhet

Planlegger

Veiledende beslutninger

Korreksjon

feil

Overvåkning

innstilling

applikasjonens livssyklus

praksis

Korrespondanse

krav

Gjentatt

islopkyuvanis

Initiering

utviklingsiterasjoner

Leveranse

Fjerning fra tjeneste

Utgivelse

penetrasjon

Ris. 3.14. ALM-modell

D. Chappel utvider bildet av livssyklusen til en lineær, og fremhever tre hovedområder ved ALM: ledelse (styring), utvikling (utvikling) og drift (drift). Prosessene som tilsvarer disse områdene flyter, overlappende, fra begynnelsen av ideen om en ny applikasjon eller moderniseringen av en eksisterende, til stadiet av utplasseringen og til fullstendig fullføring av operasjonen.

Styring i ALM implementeres gjennom hele søknadens livssyklus og inkluderer alle prosesser og prosedyrer som er relevante for beslutningstaking og prosjektledelse. hovedoppgaven her - å sikre at applikasjonen oppfyller et eller annet forretningsmål, som bestemmer betydningen av denne komponenten av ALM. Til forvaltningsprosessene viser D. Chappel til utviklingen av et detaljert investeringsforslag (en business case som inneholder en analyse av kostnadene, fordelene og risikoene knyttet til en fremtidig søknad), som går foran utviklingsstadiet; utviklingsledelse ved bruk av metoder og verktøy for prosjekt- og porteføljestyring (Project Portfolio Management, PPM); administrere en løpende applikasjon som en del av bedriftsapplikasjonsporteføljeadministrasjon (Application Portfolio Management, AWP).

Applikasjonsutvikling skjer mellom det øyeblikk ideen er født og utrullingen av den ferdige løsningen. Utviklingsprosesser implementeres også etter distribusjon når det er behov for å oppgradere applikasjonen eller gi ut nye versjoner. Utvikling inkluderer kravdefinisjon, design, koding og testing, som alle vanligvis fullføres i flere iterasjoner.

Drift refererer til prosessene med å overvåke og administrere en kjørende applikasjon som er planlagt og startet kort tid før utviklingen er fullført og fortsetter til den blir skrotet. Inkludering av operasjonelle prosesser i programvarens livssyklus er sentralt punkt: det er fragmenteringen av utviklingsteam og driftspersonell som regnes som et av de mest akutte problemene med bedriftsapplikasjoner, og deres integrasjon ved hjelp av ALM lover en alvorlig økning i effektiviteten ved bruk av forretningsprogramvare. Det eneste problemet er at i ALM-miljøer er slik integrasjon fortsatt et godt mål, og ikke en reell implementering.

Det beskrevne generelle bildet av ALM i praksis transformeres til behovet for å planlegge og automatisere mange stadier av programvarens livssyklus. Det ideelle ALM-miljøet integrerer alle deltakere i applikasjonens livssyklus, gir dem konsekvent tilgang til de riktige ressursene og oppgavene, og forstår samtidig konteksten til hver enkelt rolle, og gir utøverne de riktige verktøyene.

Den utvidede listen over roller til deltakere i ALM-prosesser og oppgavene de utfører som må støttes av det tilsvarende verktøysettet inkluderer:

• toppledere - administrer prosjektporteføljer og bruk dashboards til å kontrollere viktige livssyklusberegninger for programvare, inkludert risiko og produktkvalitet;
• prosjektledere - planlegge og kontrollere gjennomføringen av prosjektet, analysere mulige risikoer og er ansvarlige for allokering av ressurser;
• analytikere - samhandle med forretningsbrukere, definere krav til et programvareprodukt, administrere krav og deres endringer gjennom hele prosjektet;
• arkitekter - modellarkitektur programvaresystem, inkludert funksjonelle komponenter, data og prosesser;
• utviklere - skrive kode ved å bruke integrerte utviklingsmiljøer og ulike kvalitetssikringsverktøy for programvare på kodingsstadiet;
• kvalitetsavdelingsingeniører - opprette og administrere tester, utføre funksjonell, regresjonstesting, ytelsestesting, inkludert bruk av automatiserte testverktøy;
• driftspersonale - overvåker og administrerer applikasjonen og implementerer tilbakemelding med utviklingsteamet om nye problemer;
• forretningsbrukere - ved hjelp av spesialiserte verktøy er de i stand til å formulere krav, rapportere applikasjonsfeil og spore status for endringer som er gjort.

Den "tradisjonelle" ALM-prosessen er imidlertid ikke i stand til å oppnå sitt fulle potensial for å generere profitt for organisasjonen. Poenget er at mange leverandører aggressivt presser begrensede ende-til-ende ALM-løsninger til markedet som tar sikte på å knytte kunder til lukkede teknologiplattformer. Kunder oppdager snart at disse løsningene ikke integreres med deres eksisterende utviklingsprosesser, verktøy og plattformer. Dessverre etterlater dette utviklingsteam alene med de siled prosesser og datahodgepodge av ALM, som igjen hindrer dem i å realisere det fulle potensialet til ALM.

Det enhetlige ALM-programvaremiljøet er designet for å gi verktøy for å arbeide og administrere prosesser basert på konfigurasjon og endringsadministrasjon og programvareversjonskontroll. Generelt lar implementeringen av ALM-tilnærminger og verktøy deg lage standardprosesser for å lage og drifte applikasjoner, kontrollere overholdelse av dem i alle prosjekter, implementere en streng endringsbehandlingsprosess, forutsi deres innvirkning på IT-miljøet og virksomheten som helhet , danner et system med kvalitetsmålinger, produktivitets- og utviklingsrisikoer , spor og analyser disse beregningene gjennom hele livssyklusen og sikrer til slutt at applikasjonene du bygger er virkelig i tråd med forretningsmålene dine.

Opprinnelig var noen av de få innovatørene som forsto viktigheten av ALM og endret produktutgivelsesstrategiene sine for å eksplisitt støtte det, Borland og IBM Rational. Som en reaksjon på de åpenbare mulighetene ble andre selskaper med på det vinnende ALM-konseptet: Microsoft, Telelogic, Mercury, Serena, Compuware, CollabNet og Mercury. I dag er ALM en etablert trend og en voksende bransje anerkjent av analytikere. ALM-leverandører tilbyr en rekke verktøy og teknologier for å støtte programvareutviklingsprosessen. Disse verktøyene går langt utover de tradisjonelle produktivitetsverktøyene til den enkelte utvikler. De er rettet mot å tilby metoder og verktøy fokusert på det kollektive arbeidet med programvareutvikling. For å skape en levedyktig ALM-løsning, må leverandører vurdere behovene til det større programvareutviklingsteamet og inkludere roller i produktene deres som deltar i den større prosessen.

En vanlig ulempe med de første ALM-systemene var den svake integrasjonen av moduler for ulike stadier av livssyklusen, både innenfor plattformen til én produsent og innenfor løsninger fra ulike leverandører. Da kundene ikke var i stand til å bruke en omfattende ALM-plattform, bygde den den fra forskjellige deler, noe som tvang dem til å implementere ende-til-ende-livssyklusprosesshåndtering manuelt, og dermed utjevne den største potensielle fordelen med ALM-automatisering. Derfor, for fire år siden, forutså Forrester-analytikere fremveksten av integrerte ALM 2.0-plattformer som hovedretningen for å forbedre ALM-miljøer, som ville gi felles tjenester for å støtte ulike roller i livssyklusen, bruke et enkelt fysisk eller virtuelt depot av utviklingsartefakter, administrere mikro- og makrolivssyklusprosesser, gitt integrasjon i ett enkelt miljø med verktøy for ulike roller, støttet ende-til-ende-rapporteringsfunksjoner for ulike stadier av livssyklusen.

I dag er det nye krav til ALM, og utbredt bruk av raske (smidige) utviklingsmetoder spiller en avgjørende rolle i dette. For noen år siden annonserte D. Sutherland, skaperen av en av de mest kjente tidlige Scrum-metodene, den kommende totaltilpasningen av ideene om tidlig utvikling. Det virket som en overdrivelse, men spådommen viste seg å stemme. I følge en felles studie fra Capgemini Group-analytikere og HP Software & Solutions brukte eller planla over 60 % av selskapene å bruke smidig utvikling i 2010, og blant deltakere i Forrester-undersøkelsen innrømmet bare 6 % at de fortsatt bare ser på raske metoder , alle de andre bruker dem i en eller annen grad, med 39 % som anser implementeringene deres for å være ganske modne.

Utviklere bruker smidige metoder og setter produktet i produksjon som ikke tar hensyn til realitetene ved smidig utvikling, noe som skaper alvorlige hindringer for responshastigheten til fungerende applikasjoner på endringer i forretningskrav og som et resultat av fleksibiliteten (smidighet) av selve virksomheten. Driftspersonells manglende evne eller vilje til å reagere på endringer i applikasjonsmiljøet gjort av utviklere er ofte forbundet med mangler i dokumentasjonen som sendes fra trinn til trinn uten å reflektere nøkkelavhengighetene mellom komponentene i den utgitte programvareversjonen, og mer globalt, med mangel på en pålitelig og automatisert kommunikasjonskanal mellom utviklere og driftspersonale. Dette problemet blir bare verre med spredningen av moderne automatiseringsverktøy for datasenteradministrasjon og nye tilnærminger til implementering av IT-infrastrukturer, inkludert skyer. Ekstremt automatisert og designet for å distribuere applikasjoner så raskt som mulig, vil slike miljøer ikke være i stand til å svare på endringer i fravær av en automatisert kommunikasjonskanal og uten implementering av ende-til-ende-prosesser mellom utviklings- og driftsstadier.

Bevissthet om alvorlighetsgraden av problemet og tendensen til å søke etter løsninger på det ga til og med opphav til det nye begrepet DevOps, brukt for å referere til konsepter og teknologier for å forbedre samspillet mellom utvikling og drift. Hovedhåpene for implementeringen av disse ideene er plassert av analytikere på den nye generasjonen ALM-miljøer, som i praksis, og ikke i teorien, vil sikre integrering av nøkkelstadier i applikasjonens livssyklus. Applikasjonene som lages i dag er i mange tilfeller sammensatte og integrerer, på grunnlag av tjenesteprinsipper, komponenter implementert i forskjellige programmeringsspråk for forskjellige plattformer, samt koden til eksterne systemer og eldre løsninger. For å administrere livssyklusen deres, må ALM-miljøet støtte flere utviklingsmiljøer og kjøretidsplattformer (som NET og J2EE) og gi muligheten til å kontrollere kildekoden, lisensiering og utviklingsstatus for eksterne applikasjonskomponenter.

Blant tegnene på utbredt bruk av smidige prosesser, peker analytikere på at organisasjoner beveger seg bort fra ortodoksi når det gjelder disse metodene. Utviklere er ikke redde for å kombinere ulike prosesser hvis det lar dem optimere arbeidet med nye systemer, så ALM 2.0-miljøet må støtte ulike prosesser og metoder innen utvikling, porteføljestyring og produktkvalitetssikring. Det siste er spesielt viktig: automatisering av ende-til-ende kvalitetsstyringsprosesser - fra kravdefinisjon til testing og drift - kan bli en av de mest styrker integrert ALM-plattform.

Rational-produktlinjen for å støtte ulike stadier av programvarens livssyklus har alltid vært preget av sin bredde og fokus på integrering av moduler seg imellom. Butler Group-analytikere vurderte IBM Rational Software and Systems Delivery-løsninger som den mest komplette på markedet når det gjelder utvalget av implementerte ALM-komponenter. Denne suiten inkluderer produkter for prosjektporteføljestyring, modellbasert design og utvikling, kravstyring, konfigurasjons- og endringsstyring, kvalitetsstyring, bygge- og utgivelsesstyring; orkestrere programvarelivssyklusprosesser og levere rapportering og dokumentasjon om disse prosessene. Ordet Systems i navnet dukket opp etter oppkjøpet av Telclogic, hvis løsninger er fokusert på å støtte systemutviklingsprosesser og nå er integrert i Rational-porteføljen. Deres inkludering i IBM ALM-miljøet gjenspeiler trenden med konvergens mellom programvare- og systemutviklingsprosesser og dannelsen av et enkelt livssyklusadministrasjonsmiljø for dem.

Men IBMs viktigste bidrag til utviklingen av ALM-teknologier er Jazzs langsiktige prosjekt for å skape en infrastruktur for implementering av en integrert plattform for livssyklusadministrasjon for bedriftsapplikasjoner. For nå hele linjen Rational-produktfamilien er allerede integrert med Jazz-plattformen, flere nye løsninger har blitt utgitt som er bygget for å kjøre på Jazz fra grunnen av, og i fremtiden vil støtte for Jazz-infrastrukturen bli gitt på tvers av alle komponentene i Rational. produkt linje.

Kjernen i Jazz er Jazz Foundation-plattformen, som kombinerer Jazz Team Server og en rekke ekstra integrasjonsmoduler. Jazz Team Server demonstrerer en ny tilnærming for ALM for å integrere komponenter for ulike stadier av livssyklusen (Fig. 3.15, ). Hvis en slik integrasjon tradisjonelt var basert på en punkt-til-punkt-forbindelse mellom individuelle produkter, implementerer Jazz en åpen distribuert tjenestearkitektur basert på REST-standarden, som gir en enkel interaksjon av instrumentelle komponenter med hverandre (en slags ALM Web) . RESTful-grensesnittet lar data og funksjonalitet til ulike moduler representeres som tjenester. Bruk av en nettstandardbasert tilnærming gjør Jazz svært skalerbar, noe som gjør plattformen til en allsidig løsning som kan støtte ALM-oppgaver i små team og store utviklingsteam.

Prosjekt og teamstruktur

hendelsesvarsling

Jazz Team Server

j * ;

Krav Elementer og relasjoner IlJ Hendelseshistorikk,

Bruk "cases ...... Varehistorikk trender

Bygger kildekode. Testtilfeller Testresultater

				visuelt studio
Klientplattform		Klientplattform		Klientplattform

Sikkerhet og tilgang

Ris. 3.15. Integrert bedriftsplattformsjon

Jazz Foundation tilbyr tjenester som er felles for alle ALM-komponenter for å aktivere nøkkelfunksjonene til et moderne miljø forsjon. Dette er for eksempel samarbeidstjenester som sikrer samspillet mellom ulike teammedlemmer i prosessen med å løse vanlige problemer, opprettholde relasjoner mellom ulike stadier av livssyklusen, og samtidig ta hensyn til konteksten for hver spesifikke rolle i ALM . Jazzdrevne samarbeidsverktøy bruker direktemeldinger, lange diskusjonsverktøy, wikier og andre populære Web 2.0-funksjoner. I dette tilfellet anses all interaksjon mellom teammedlemmer som prosjektressurser, som er lagret i forhold til de artefaktene som fungerte som kilden til disse interaksjonene (for eksempel defekter eller testtilfeller).

Jazz Foundation-tjenestene lar deg også definere og utføre prosesser i henhold til en rekke metoder, inkludert Rational Unified Process og ulike hurtigutviklingsalternativer. For dette tilbys verktøy for hendelsesvarsling, støtte for kommunikasjon mellom teammedlemmer ved utførelse av visse arbeidsflyter, innstilling og kontroll av implementering av regler, automatisering av grunnleggende oppgaver, organisering av arbeidsflyter ved hjelp av verktøy for ulike stadier av livssyklusen. Mye oppmerksomhet rettes mot å sikre gjennomsiktighet i livssyklusprosesser og prosessstyring, for hvilke presise prosessberegninger legges inn på status, problemer og risikoer for prosjektet og dashboards er tilgjengelig for å spore dem, inkludert i sanntid, på ulike nivåer, fra individuelle prosessdeltakere til team- og porteføljestyringsnivå. Andre Jazz Foundation-tjenester inkluderer søkemotorer, sikkerhetsverktøy, rollebasert tilgang og et distribuert depot for alle utviklingsressurser.

Jazz-plattformen integreres med Eclipse-utviklingsmiljøet ved å tilby en rekke visninger og projeksjoner. Noen Jazz-komponenter støtter også nettklienter. Jazz-rammeverket gir to viktige visninger for Eclipse: Team Central og Team Artifacts. Begge visningene brukes til å samle informasjon og kan utvides med Jazz-plattformkomponenter. Utviklet av Eclipse, noen komponenter av Jazz-plattformen lar brukere få tilgang til Jazz-serveren direkte fra en nettleser.

Jazz-nettbrukergrensesnittet gir denne muligheten. Dette grensesnittet er mer egnet for sporadiske eller sporadiske brukere i stedet for en IDE fordi det ikke krever noen spesiell programvare som skal installeres på klientdatamaskinen; alt du trenger er en nettleser. Hver Jazz-server har en hovedwebside hvor brukeren kan velge et prosjektområde og logge på. Når du er logget på, kan brukeren samhandle med Jazz-serveren og utforske informasjonen i Jazz-depotet, inkludert sjekke de siste hendelsene, legge inn og oppdatere arbeidsflytelementer og laste ned sammenstillinger.

Blant de mest spennende nye tilleggene til Rational-familien som er bygget spesielt for å kjøre på Jazz, er Rational Team Conceit (RTC), en pakke med samarbeids- og programvarelivssyklubygget utelukkende på Jazz-arkitekturen. IBM Rational Team Concert er et komplett miljø designet for å organisere utviklingen av informasjonssystemer i et flerprosjektmiljø der mange utviklere lærer. Verktøyet lar deg kombinere innsatsen til utviklingsspesialister, organisere dem effektiv interaksjon og opprettholde det høyeste nivået av kontroll over alle prosjektaktiviteter gjennom hele prosjektet.

RTC-systemet implementerertrasjon, oppgave- og byggeadministrasjon, samt iterasjonsplanlegging og prosjektrapportering, gir definisjoner forskjellige typer utviklingsprosesser og integreres med andre Rational-produkter for å støtte hele programvarens livssyklus. I 2009 ga IBM også ut Rational Quality Manager, en Jazz-basert testadministrasjonsportal, og Rational Insight, et ytelsesstyringsverktøy bygget for Jazz-plattformen ved å bruke Cognos-analyse for utviklingsprosjektporteføljestyring på høyt nivå.

De omfattende integreringsmulighetene til IBM Rational Team Concert gjør dette verktøyet helt unikt. Blant de eksisterende integrasjonene bør følgende bemerkes.

• 1. Integrasjon med IBM Rational Requirements Composer som en del av collaborative application lifecycle management (CALM), som lar deg knytte arbeidsordrer til krav generert eller modifisert på grunnlag av disse oppgavene, og omvendt, krav med oppgaver opprettet for arbeidsplanlegging for implementeringen av disse kravene.
• 2. Integrasjon med IBM Rational Quality Manager som en del av samarbeidendesjon, på grunnlag av hvilken det blir mulig å organisere feilsporing basert på resultatene av tester utført under testing av utgitte programvareprodukter.
• 3. Integrasjon med IBM Rational ClearQuest for å synkronisere arbeidsordrer og endringsforespørsler definert i det klassiske IBM Rational ClearQuest utviklingsadministrasjonsverktøyet.
• 4. Integrasjon med IBM Rational ClearCase for å synkronisere versjons- og konfigumellom de to verktøyene.

Den åpne jazzintegrasjonsarkitekturen som ligger til grunn basert på IBM Rational Team Concert åpner for ytterligere utvikling av nye integrasjonsmekanismer med andre systemer som kan distribueres og brukes aktivt i organisasjonen. Et av integreringsalternativene med disse systemene kan være bruken av RTC Email Reader-produktet fra Fineco Soft-selskapet, som gir synkronisering av IBM Rational Team Concert-arbeidsoppgaver i samsvar med e-postmeldinger i et forhåndsdefinert format. Omvendt synkronisering er imidlertid også mulig takket være det innebygde IBM Rational Team Concert-varslingssystemet.

Det bør også bemerkes at versjons- og konfigurasjonsadministrasjon basert på IBM Rational Team Concert kan organiseres i nesten alle prosjekter, selv om utviklingsmiljøet (IDE) ikke har direkte integrasjon med dette verktøyet. Dette er gjort mulig takket være deling"tykk klient" IBM Rational Team Concert og ikke-integrerbar IDE. Så hvis slike integrasjoner eksisterer for Eclipse IDE, IBM Rational Software Architect, IBM Rational Application Developer og Microsoft Visual Studio, må du for eksempel med Delphi i tillegg bruke IBM Rational Team Conceit "tykk klient", som ikke er veldig vanskelig.

Etc..

"Life cycle management" kommer ned til behovet for å mestre praksisene som er kjent for systemteknikk:

• informasjonshåndtering (« nødvendig informasjon bør være tilgjengelig for de rette interessentene til rett tid og i en brukbar form").
• konfigurasjonsstyring("designinformasjon må samsvare med kravene, informasjon "som bygget" må samsvare med prosjektet, inkludert designbegrunnelser, fysisk system må være konsistente med "som bygget"-informasjonen, mens de ulike delene av prosjektet må være konsistente med hverandre, noen ganger kalles en del av denne praksisen "endringsledelse").

LCMS vs PLM

Det nylig formulerte LCMS bruker ikke PLM som en obligatorisk klasse programvareverktøy som et slikt system er bygget rundt. I store ingeniørprosjekter brukes flere (oftest betydelig "underutviklede") PLM-er fra forskjellige leverandører samtidig, og når vi oppretter et LCMS, snakker vi vanligvis om deres interorganisatoriske integrasjon. Selvfølgelig, samtidig er spørsmålene om hvordan man integrerer i LCMS-informasjonen til de systemene som ennå ikke er koblet til noen av PLM-systemene til den utvidede virksomheten også løst. Begrepet "utvidet virksomhet" (utvidet virksomhet) refererer vanligvis til en organisasjon opprettet gjennom et system av kontrakter fra ressursene (mennesker, verktøy, materialer) som deltar i et spesifikt ingeniørprosjekt av forskjellige juridiske enheter. I utvidede virksomheter blir svaret på spørsmålet, i hvilken PLM dataene til hvilke bestemte CAD / CAM / ERP / EAM / CRM / etc.-systemer er integrert, ikke-trivielt: du kan ikke foreskrive eiere av forskjellige virksomheter å bruke programvare fra samme leverandør.

Og siden PLM-systemet fortsatt er programvareverktøy, og "styringssystemet" fra LCMS klart forstås blant annet som et "styringssystem", innebærer begrepet LCMS klart det organisatoriske aspektet, og ikke bare aspektet informasjonsteknologier. Dermed er uttrykket "bruke PLM for å støtte et livssyklusstyringssystem" ganske meningsfullt, selv om det kan være forvirrende når det bokstavelig talt oversetter "PLM" til russisk i den.

Imidlertid synker forståelsen av et "livssyklusstyringssystem" når det håndteres av IT-folk umiddelbart tilbake til "bare programvare" som ser mistenkelig ut som PLM-programvare. Og etter denne overforenklingen begynner vanskelighetene: et "innpakket" PLM-system fra en eller annen leverandør av presenteres vanligvis umiddelbart konstruktivt, som et sett med programvaremoduler fra katalogen til denne leverandøren, uten hensyn til støttede ingeniør- og administrasjonsfunksjoner, og regnes som en trio av følgende komponent:

• datasentrisk livssyklusdatalager,
• "arbeidsflytmotor" for å støtte "administrasjon",
• "portal" for å se innholdet i depotet og statusen til arbeidsflyten.

Hensikten med LCMS

Hovedhensikt: LCMS oppdager og forhindrer kollisjoner som er uunngåelige i samarbeidsutvikling. Alle andre LCMS-funksjoner er derivater som støtter denne hovedfunksjonen.

Hovedideen til ethvert moderne LCMS- dette er bruken av en nøyaktig og konsistent representasjon av systemet og verden rundt det i de uunngåelig heterogene og i utgangspunktet inkompatible datasystemene til en utvidet organisasjon. Bruk av virtuelle layouter, informasjonsmodeller, datasentriske depoter for designinformasjon sikrer deteksjon av kollisjoner under "konstruksjon i en datamaskin", "virtuell montering", og ikke når tegninger og andre prosjektmodeller tegnes inn i materiell virkelighet under selve konstruksjonen. «i metall og betong» og oppstart i drift.

Ideen om LCMS er dermed ikke relatert til ulike "designautomatisering", først og fremst til "generativ design" (generativ design) og "generativ produksjon" (generativ produksjon). LCMS er ikke lenger opptatt av syntese, men av analyse: det oppdager og/eller forhindrer kollisjoner i designresultatene til individuelle delsystemer når de settes sammen ved hjelp av en rekke teknologier:

• slå sammen prosjektdata til ett depot,
• kjører integritetssjekkalgoritmen for tekniske data distribuert i flere depoter,
• ved å gjennomføre faktisk "virtuell montering" og simulering for et spesielt utvalgt undersett av designdata.

Modellbasert tilnærming

Bruken av LCMS innebærer avvisning ikke bare av papir i design, men også av "elektronisk papir"(.tiff eller andre rasterformater) og overgangen til datasentrisk representasjon av informasjon. Å sammenligne to modeller som finnes på papir i noen notasjoner og finne inkonsekvenser i dem er mye vanskeligere og lengre enn å forhindre kollisjoner i strukturert elektroniske dokumenter som ikke bruker rastergrafikk, men tekniske datamodeller.

Datamodellen kan utformes i henhold til et eller annet språk, for eksempel:

• i forhold til ISO 24744-standarden for beskrivelse av utviklingsmetode),
• metamodell (i form av OMG-standardiseringskonsortiet),
• datamodell/referansedata (i form av ISO 15926rd).

Det er denne overgangen til strukturelt representerte modeller som allerede eksisterer på de tidlige stadiene av design og kalles "Model-based systems engineering" (MBSE, model-based systems engineering). Det blir mulig å fjerne kollisjoner ved hjelp av databehandling allerede i de tidligste stadiene av livssyklusen, selv før utseendet til fullverdige 3D-modeller av strukturen.

LCMS bør:

• gi en mekanisme for overføring av data fra en enkelt applikasjon CAD/CAM/ERP/PM/EAM/etc. til en annen- og i elektronisk strukturert form, og ikke i form av en "pakke med elektronisk papir." Overføring av data fra ett teknisk informasjonssystem (med en klar forståelse av hvor, hvor, når, hva, hvorfor, hvordan) er en del av funksjonaliteten som tilbys av LCMS. Dermed må LCMS støtte arbeidsflyt (arbeidsflyten, som delvis utføres av mennesker og delvis av datasystemer).
• versjonskontroll, det vil si å gi en konfi- både modeller og fysiske deler av systemet. LCMS opprettholder en taksonomi av lagdelte krav og gir en måte å se etter lagdelte designbeslutninger og deres begrunnelser for å komme i konflikt med disse kravene. I løpet av ingeniørutviklingen blir enhver beskrivelse av systemet, hvilken som helst av modellene endret og supplert mange ganger, og finnes derfor i mange alternative versjoner av varierende grad av korrekthet, og i varierende grad tilsvarende hverandre. LCMS skal sørge for at kun riktig kombinasjon av disse versjonene brukes for det aktuelle arbeidet.

LCMS-arkitektur

Det kan være mange arkitektoniske løsninger for LCMS, den samme funksjonen kan støttes av ulike strukturer og arbeidsmekanismer. Det er tre typer arkitektur:

1. Tradisjonelle forsøk på å lage et LCMS er å gi store sendinger data på punkt-til-punkt-basis mellom ulike applikasjoner. I dette tilfellet kan et spesialisert arbeidsflytstøttesystem (BPM-motor, "business process management engine") eller et hendelsesbehandlingssystem (kompleks hendelsesbehandlingsmotor) brukes. Dessverre viser arbeidsmengden med å tilby punkt-til-punkt-utveksling seg å være enorm: hver gang kreves det spesialister som forstår både koblingssystemene og metoden for informasjonsoverføring.
2. Brukerden ISO 15926 i henhold til "ISO 15926 utenfor"-metoden, når en adapter utvikles for hver ingeniørapplikasjon til en nøytral representasjon som samsvarer med standarden. Dermed får alle data muligheten til å møtes i en applikasjon og en kollisjon mellom dem kan oppdages - men applikasjonen trenger kun å utvikle en dataoverføringsadapter, og ikke flere slike adaptere (i henhold til antall andre applikasjoner den er med nødvendig for å gi kommunikasjon).
3. PLM(Teamcenter, ENOVIA, SPF, NET Platform, etc.) - en standardisert arkitektur brukes, med det eneste unntaket at datamodellen som brukes i hver av disse PLM-ene er mindre universell når det gjelder å reflektere ethvert ingeniørfagområde, og er heller ikke nøytral og tilgjengelig i alle formater. Så bruken av ISO 15926 som en baseline for overføring av data til LCMS kan betraktes som en videreutvikling av ideene som faktisk er implementert i moderne PLM.

I henhold til konfigurakan LCMS deles inn i tre typer:

• "oppbevaringssted"(oppdatert lagring av alle prosjektdata i ett LCMS-lager, hvor data kopieres fra der de ble utviklet),
• "registrere"(LCMS opprettholder en liste over livssyklusdataadresser i en rekke depoter for andre CAD-systemer, tekniske simuleringssystemer, PLM, ERP, etc.),
• "hybrid arkitektur"-- når deler av dataene kopieres til LCMS-sentrallageret og deler av dataene er tilgjengelige fra andre steder via lenker.

LCMS-arkitekten bør også beskrive:

• "portal"(inkludert "nettportal"), dens funksjoner og implementeringsmetode. Selve tilstedeværelsen av portalen lar deg berolige toppledere ved å demonstrere fraværet av konflikter. Det stilles spesifikke krav til arkitektoniske løsninger for LCMS-portalen.
• algoritmer for dataintegritet/konsistenssjekk livssyklus, samt en beskrivelse av driften av disse algoritmene:
  • en standardmodul i en egen applikasjon som fungerer på data i depotet til denne applikasjonen - det være seg CAD eller PLM;
  • Kollisjonskontrollprogramvare spesielt utviklet for LCMS, som har tilgang til data fra forskjellige applikasjoner som ligger i LCMS-sentrallageret;
  • et spesialutviklet programvareverktøy som får tilgang via Internett via en sikker kanal til forskjellige datalagre lokalisert i forskjellige organisasjoner;
  • spesialprogrammerte kontroller med kollisjonskontroll når du laster forskjellige tekniske datasett inn i LCMS-sentrallageret;
  • en kombinasjon av alle de listede metodene - forskjellige for forskjellige typer kollisjoner; etc.
• måten LCMS-brukere samhandler på(designingeniører, innkjøpere, installatører, anleggsprosjektledere osv.), og nøyaktig hvordan programvare LCMS støtter denne interaksjonen på en måte som unngår kollisjoner. Systemtekniske standarder (spesielt ISO 15288-standarden for systemteknikk) krever valg av livssyklustype for kompleks objektutvikling og en indikasjon på hvilke praksisalternativer for systemteknikk som vil bli brukt. Livssyklusmodellen er en av hovedartefaktene som fungerer som organisatoriske ordninger for å koordinere arbeidet til den utvidede ingeniørprosjektorganisasjonen. Koordinert arbeid i løpet av samarbeidsprosjektering er nøkkelen til et lite antall designkollisjoner. Hvordan vil LCMS-livssyklusmodellen støtte det? Så, PLM-systemer finner vanligvis ikke et sted for livssyklusmodeller, og enda mer for organisasjonsmodeller. Derfor, for LCMS, er det nødvendig å se etter andre løsninger for programvarestøtte for disse modellene.
• Organisatorisk aspekt ved overgangen til bruk av LCMS. Overgangen til bruk av LCMS kan føre til en betydelig endring i strukturen og til og med personellet til et ingeniørfirma: ikke alle gravere blir tatt som gravemaskiner, ikke alle drosjebiler blir tatt som drosjesjåfører.

Hovedsaken for LCMS er hvordan den foreslåtte løsningen bidrar til tidlig oppdagelse og til og med forebygging av kollisjoner. Hvis det kommer til noe annet (meningsfullt valg av livssyklustype i henhold til prosjektets risikoprofil, aldringsstyring, kostnadsstyring og budsjettreform, beherske aksiomatisk design, bygge med just-in-time leveranser, generere design og konstruksjon, og mye, mye mer, også ekstremt nyttig-moderne-interessant), så er dette et spørsmål om andre systemer, andre prosjekter, andre metoder, andre tilnærminger. LCMS bør gjøre jobben sin godt, og ikke dårlig løse et stort sett med vilkårlig utvalgte utenlandske oppgaver.

LCMS-arkitekten har dermed to hovedoppgaver:

• skaper en rekke toppkandidatarkitekturer og deres hybrider
• foreta et flerkriterievalg blant disse arkitekturene.
  • meningsfull vurdering (meningsfullhet av utvalgskriterier)
  • presentasjon av resultatet (begrunnelse).

Kriterier for valg av arkitektonisk løsning for LCMS

1. Kvaliteten på ytelsen til LCMS for hovedformålet: deteksjon og forebygging av kollisjoner Hovedkriteriet er: hvor mye kan den tekniske fremdriften akselereres ved å akselerere oppdagelsen eller unngåelsen av kollisjoner ved å bruke den foreslåtte LCMS-arkitekturen? Og hvis arbeidstiden ikke kan reduseres, hvor mye kan da arbeidsmengden økes på samme tid ved å bruke de samme ressursene? Følgende metoder anbefales:
   • Goldratts teori om begrensninger(TOC, theory of constraints) - arkitekturen skal indikere hvilke systembegrensninger den fjerner på den kritiske ressursbanen til et ingeniørprosjekt (ikke å forveksle med den kritiske banen).
   • ROI(avkastning på investeringer) for investeringer i LCMS på stadiet for formalisering av resultatet av en innholdsmessig gjennomgang av kandidatarkitekturer.
   Det er viktig å velge grensene for hensynet: den totale hastigheten til et ingeniørprosjekt kan bare måles ved grensen til det vurderte organisasjonssystem. Grensene til en enkelt juridisk enhet faller kanskje ikke sammen med grensene til et utvidet foretak som utfører et storstilt ingeniørprosjekt, og et foretak som deltar i bare ett stadium av livssyklusen kan feilaktig vurdere nytten og kritikaliteten for hele livssyklusen. av systemet og velger feil måte å integrere seg selv i LCMS. Da kan det vise seg at opprettelsen av LCMS ikke påvirker den generelle timingen og budsjettene til prosjektet, fordi de mest ubehagelige kollisjonene vil fortsette å være uadressert av det nye LCMS.
2. Evne til å ta i bruk inkrementell LCMS-utviklingslivssyklus Inkrementell i ISO 15288 er en slik livssyklus, der funksjonaliteten ikke gis til brukeren på en gang, men i etapper - men investeringer i utvikling skjer også ikke på en gang, men i etapper. Selvfølgelig, i dette tilfellet, må loven om avtagende nytte tas i betraktning: hver økning av LCMS (hver ny type kollisjoner oppdaget på forhånd) er dyrere, og fordelene fra det er mindre og mindre, inntil utviklingen av LCMS som har pågått i mange år dør ikke ut av seg selv. Hvis det viser seg at for noen av de foreslåtte arkitekturene, må det investeres mye penger i opprettelsen av LCMS på en gang, men fordelene kan oppnås umiddelbart i mengden 100% og først etter fem år på en nøkkelferdig grunnlag, så er dette en dårlig arkitektur. Hvis det viser seg at det er mulig å utvikle og sette i drift en kompakt LCMS-kjerne, og så mange, mange moduler av samme type for ulike typer kollisjoner med en klar mekanisme for utviklingen deres (for eksempel basert på bruk av ISO 15926), så er dette veldig bra. Det handler ikke så mye om å søke smidig utvikling» (smidige metoder) hvor mye å se for seg en modulær LCMS-arkitektur og foreslå en implementeringsplan for en prioritert liste over moduler – først de mest presserende, så de minst presserende osv. Må ikke forveksles med ICM (inkrementell forpliktelsesmodell), selv om meningen her er den samme: arkitekturen er bedre, der du kan få en form for avdragsbetaling for systemet, og få den nødvendige funksjonaliteten så tidlig som mulig - i for å få ytelsen (minst en liten en) tidlig, og betale for sen ytelse senere.
3. Grunnleggende økonomisk og intellektuell evne til å mestre og vedlikeholde teknologi Hvis vi beregner kostnadene ikke bare for LCMS selv, men også for alt personell og annen infrastruktur som kreves for gjennomføringen av prosjektet, må vi forstå hvor mye av disse investeringene i utdanning, datamaskiner og organisasjonsarbeid som vil forbli med betaler og eier av LCMS, og hvor mye vil avgjøres utenfor - med mange entreprenører , som selvfølgelig vil være takknemlige først for å motta et "stipend" for utvikling av ny teknologi, og deretter for å støtte systemet de har laget. Det nye er vanligvis ekstremt dyrt, og ikke fordi det er dyrt i seg selv, men fordi det forårsaker et snøskred av endringer det medfører. Det er dette punktet jeg tar i betraktning de totale eierkostnadene for LCMS, og det samme punktet inkluderer vurdering av hele livssyklusen, ikke lenger av et ingeniørsystem med dets unngåelige kollisjoner, men av selve LCMS.
4. Skalerbarhet av LCMS-arkitekturen Dette kriteriet er relevant for store ingeniørprosjekter. Siden du vil at systemet skal brukes av alle tusenvis av mennesker i den utvidede organisasjonen, må det vokse raskt i den grad. I hvilken grad kan "piloten" eller "polygonen" til LCMS kunne vokse raskt uten grunnleggende arkitektoniske endringer? Mest sannsynlig vil de ikke kunne vokse. Derfor trenger vi arkitektonisk ikke en "pilot" eller en "polygon", men umiddelbart et "første trinn". Kravet til skaleringskriteriet skjærer tett med kravet til inkrementalitetskriteriet, men påvirker et litt annet aspekt - ikke så mye utvidelsen av opprettelsen av LCMS i tid, men muligheten for utvidelse med det dekkede volumet. Erfaring viser at alle systemer takler testvolumer av designdata, men de kan ikke takle industrielle. Hvordan vil kostnadene for maskinvare og programvare øke ikke-lineært med veksten i volum/hastighet? Hvor lenge skal de utarbeide regelverket, når det viser seg at etter noen arbeidsplass går mer data gjennom enn det som kan sees meningsfullt av én person? Dårlig skalerbarhet kan ligge på lur ikke bare med teknisk side arkitektur av programvare- og maskinvareløsningen, men også fra siden av dens finansielle arkitektur. Dermed kan en liten lisenspris per LCMS-sete, eller til og med en liten pris per ny tilkobling på repositoryserveren, gjøre en mer eller mindre attraktiv løsning for ti seter til en absolutt økonomisk uholdbar løsning for målet tusen seter.
5. Evne til å møte uunngåelige organisatoriske utfordringer inkludert holdninger til kjære arvesystemer i den utvidede organisasjonen. Hvor mye ville den foreslåtte sentraliserte eller distribuerte arkitekturen kreve for å "gi bort funksjoner til andre avdelinger", "gi bort våre data" og generelt "gi bort" noe sammenlignet med dagens situasjon uten LCMS? Stormaskiner tapte massivt konkurransen til mini-datamaskiner, og de til personlige. Tilbake til sentraliserte systemer LCMS vises uunngåelig) er det nesten ingen måte, fordi alle dataene er i separate applikasjoner, og å trekke disse dataene inn i nye systemer er en veldig vanskelig organisatorisk oppgave. Hvordan er LCMS-arkitekturen strukturert: erstatter den nåværende eldre ingeniørapplikasjoner, bygger den på toppen av dagens IT-infrastruktur, installeres den "gratis" av ulike tjenester? Hvor mye organisatorisk/ledelsesmessig/konsulentinnsats vil det ta for å "skyve gjennom" ny teknologi? Hvor mange mennesker skal sparkes, hvor mange skal finne og ansette nye spesialister? Dette kriteriet om organisatorisk aksept er nært knyttet ikke bare til sentralisering/desentralisering, men også med hensynet til motivasjonssystemet i den utvidede virksomheten, d.v.s. å vurdere arkitekturen til LCMS mot dette kriteriet går langt utover en snever vurdering av LCMS alene, men krever en grundig analyse av prinsippene for å bygge den utvidede organisasjonen, opp til og med gjensyn med prinsippene som ligger til grunn for kontraktene den ble opprettet under. Men dette er essensen av systemtilnærmingen: ethvert målsystem (i dette tilfellet LCMS) anses først og fremst ikke "i dybden, fra hvilke deler", men "utover, en del av hva" - ikke dets design og mekanisme for operasjon er først og fremst interessante, men støttes. LCMS er kollisjonsunngåelsesfunksjonen i det eksterne supersystemet - og prisen som det eksterne supersystemet er villig til å betale for denne nye funksjonen. Derfor vurderes mulige LCMS-arkitekturer primært ikke i form av "anstendige teknologier som brukes, for eksempel fra programvareleverandøren XYZ" (dette er standard: alle foreslåtte arkitekturer er vanligvis teknologisk anstendige, ellers er de ikke alternativer!), men mht. de ovennevnte fem kriteriene.

LCMS-funksjoner

1. Unngå kollisjon
   1. Konfigurasjonsstyring
      1. Identifikasjon (klassifiseringer, kodinger)
      2. Konfigurasjonsregnskap (alle mulige grunnlinjer - ConOp, arkitektur, design, som bygget), inkludert dataoverføring til LCMS-depotet, inkludert støtte for arbeidsflytendringer, inkludert støtte for parallell engineering (arbeid under forhold med ufullstendige grunnlinjer)
      3. Versjon (inkludert gafler)
   2. Mangel på manuell dataoverføring (overføring av inn- og utdata mellom allerede eksisterende automatiseringsøyer, inkludert overføring av data fra øyene "rise to digital" av gamle designutviklinger)
   3. NSI-konfigurasjon
   4. Samarbeidende ingeniørstøttesystem (videokonferanser, eksterne prosjektøkter osv. - kanskje ikke det som ble brukt til å lage selve LCMS-systemet)
2. Kollisjonsdeteksjon
   1. Støtte for et register over sjekkede kollisjonstyper og kontrollteknologier tilsvarende registeret
   2. Dataoverføring for kontroll av kollisjoner mellom automatiseringsøyer (uten montering i LCMS-lageret, men ved hjelp av LCMS-integrasjonsteknologien)
   3. Arbeidsflyt for validering forskjellige typer kollisjoner
      1. i LCMS-depotet
      2. ikke i et depot, men ved hjelp av LCMS-integrasjonsteknologien
   4. Starte en kjøring av arbeidsflyten for å løse den funnet kollisjonen (sende varsler om kollisjoner, fordi kjøringen av arbeidsflyten for å løse ikke er CLMS-enes bekymring)
   5. Opprettholde en oppdatert liste over uløste kollisjoner
3. Utvikling(her regnes LCMS som et autopoietisk system, fordi "inkrementell implementering" er en av de viktigste egenskapene til selve LCMS - så dette er en funksjon av LCMS selv, og ikke en funksjon av støttesystemet for LCMS)
   1. Sikre kommunikasjon om utviklingen av LCMS
      1. Arbeidsplanlegging for utvikling av LCMS (veikart, utvikling av handlingsplan)
      2. Funksjon av LCMS-prosjektkontoret,
      3. Vedlikeholde et register over typer kollisjonskontroller (selve «Ønskeliste»-registeret og veikart for gjennomføring av kontroller)
      4. Organisatorisk og teknisk modellering (Enterprise Architecture) for LCMS
      5. Kommunikasjonsinfrastruktur for LCMS-utviklere (internettkonferanser, videokonferanser, kunnskapsadministrasjon, etc. -- kanskje ikke den som brukes i samarbeidsteknikk ved bruk av LCMS)
   2. Ensartethet av dataintegrasjonsteknologi (for eksempel ISO 15926-teknologi)
      1. Bruke en nøytral datamodell
         1. Støtte for referansedatabibliotek
         2. Utvikling av referansedata
      2. Teknologi for å støtte adaptere til en nøytral datamodell
   3. Uniform arbeidsflyt/BPM-integrasjonsteknologi (bred virksomhet)
4. Datasikkerhet(på omfanget av informasjonssystemer som opererer innenfor LCMS)
   1. Sikre enhet av tilgang (én pålogging og passord til alle informasjonssystemer deltar i arbeidsflyten)
   2. Administrere tilgangsrettigheter til dataelementer
   3. Sikkerhetskopiering

Ved å analysere utviklingen av utviklingsverktøymarkedet de siste 10-15 årene, kan man merke seg en generell trend med skiftende vekt fra teknologiene for å faktisk skrive programmer (som siden tidlig på 90-tallet var preget av fremveksten av RAD-verktøy - "rask applikasjonsutvikling") til behovet for en integrert administrasjon av hele livssyklusen til applikasjoner - ALM (Application Lifecycle Management) .

Etter hvert som kompleksiteten til programvareprosjekter øker, øker kravene til effektiviteten av implementeringen deres kraftig. Dette er desto viktigere i dag, når programvareutviklere er involvert i nesten alle aspekter av virksomhetens arbeid og antallet slike spesialister vokser. Samtidig tyder forskningsdata på dette området på at resultatene fra minst halvparten av de «in-house» ikke rettferdiggjør forhåpningene til dem. Under disse forholdene blir oppgaven med å optimalisere hele prosessen med å lage programvareverktøy med dekning av alle deltakerne - designere, utviklere, testere, støttetjenester og ledere - spesielt presserende. Application Lifecycle Management (ALM) ser på programvareutgivelsesprosessen som en stadig gjentakende syklus av sammenhengende stadier:

definisjon av krav (Krav);

design og analyse (Design & Analyse);

Utvikling (Utvikling);

testing (testing);

distribusjon og vedlikehold (Deployment & Operations).

Hvert av disse trinnene må overvåkes og kontrolleres nøye. Et riktig organisert ALM-system lar deg:

Reduser tiden det tar å bringe produkter til markedet (utviklere trenger bare å sørge for at programmene deres samsvarer med de formulerte kravene);

forbedre kvaliteten samtidig som du sikrer at applikasjonen vil møte brukernes behov og forventninger;

øke produktiviteten (utviklere får muligheten til å dele beste praksis i utvikling og implementering);

Akselerer utviklingen gjennom integrering av verktøy;

Reduser vedlikeholdskostnadene ved å hele tiden opprettholde konsistens mellom applikasjonen og dens prosjektdokumentasjon;

Få mest mulig ut av investeringen din i ferdigheter, prosesser og teknologi.

Strengt tatt er selve konseptet ALM selvfølgelig ikke noe fundamentalt nytt - en slik forståelse av problemene med programvareutvikling oppsto for rundt førti år siden, ved begynnelsen av dannelsen av industrielle utviklingsmetoder. Men inntil relativt nylig var hovedinnsatsen med å automatisere programvareutviklingsoppgaver rettet mot å lage verktøy direkte for programmering som det mest tidkrevende stadiet. Og først på 80-tallet, på grunn av komplikasjonen av programvareprosjekter, begynte situasjonen å endre seg betydelig. Samtidig har relevansen av å utvide funksjonaliteten til utviklingsverktøy (i vid forstand av begrepet) på to hovedområder økt kraftig: 1) automatisering av alle andre stadier av programvarens livssyklus og 2) integrering av verktøy med hverandre.

Mange bedrifter tok seg av disse oppgavene, men den ubestridte lederen her var Rational, som i mer enn tjue år, siden oppstarten, har spesialisert seg på automatisering av programvareutviklingsprosesser. En gang var det hun som ble en av pionerene med utbredt bruk visuelle metoder programdesign (og praktisk talt forfatteren av UML-språket, akseptert som en de facto-standard på dette området), skapte en felles ALM-metodikk og et tilsvarende sett med verktøy. Det kan sies at ved begynnelsen av dette århundret var Rational det eneste selskapet som hadde i sitt arsenal et komplett utvalg av produkter for å støtte ALM (fra forretningsdesign til vedlikehold), med unntak av en klasse verktøy - vanlige kodeverktøy. I februar 2003 opphørte den imidlertid å eksistere som en uavhengig organisasjon og ble en avdeling av IBM Corporation, kalt IBM Rational.

Inntil ganske nylig var Rational praktisk talt den eneste produsenten av integrerte utviklingsverktøy i ALM-klassen, selv om det fantes og er konkurrerende verktøy fra andre leverandører for visse stadier av programvareutvikling. For et par år siden ble imidlertid Borland Corporation, som alltid har hatt en sterk posisjon innen tradisjonelle applikasjonsutviklingsverktøy (Delphi, JBuilder, etc.), som faktisk er grunnlaget for selskapets ALM-kompleks, som ble utvidet gjennom oppkjøp av andre selskaper som produserer lignende produkter. Dette er den grunnleggende forskjellen i forretningsmodellene til de to selskapene, som åpner for potensielle muligheter for reell konkurranse. Etter at Rational ble en del av IBM, posisjonerer Borland seg som den eneste uavhengige leverandøren av en omfattende ALM-plattform i dag (det vil si at den ikke promoterer egne operativsystemer, språk osv.). På sin side bemerker konkurrentene at Borland ennå ikke har formulert en klar ALM-metodikk som gir grunnlag for å kombinere verktøyene de har.

En annen stor aktør innen utviklingsverktøy er Microsoft Corporation. Mens hun ikke truer med å lage sin egen ALM-plattform; promotering i denne retningen er bare innenfor rammen av samarbeid med andre leverandører, den samme Rational og Borland (begge ble de første deltakerne i Visual Studio Industry Partner-programmet). Samtidig utvider Microsofts flaggskip Visual Studio .NET utviklingsverktøy stadig funksjonalitet gjennom bruk av høynivåmodellerings- og prosjektstyringsverktøy, inkludert gjennom integrasjon med Microsoft Visio og Microsoft Project.

Det skal bemerkes at i dag har nesten alle ledende selskaper som utvikler teknologier og programvareprodukter (bortsett fra de som er oppført ovenfor, man kan nevne Oracle, Computer Associates, etc.) utviklet som ble opprettet som på egenhånd, og gjennom anskaffelse av produkter og teknologier skapt av små spesialiserte selskaper. Og selv om de, i likhet med Microsoft, ennå ikke planlegger å lage sin egen ALM-plattform, er CASE-verktøyene utgitt av disse selskapene mye brukt i visse stadier av programvarens livssyklus.