Modeller og verktøy for utvikling av automatiserte informasjonssystemer for bedriftsledelse oganesyan artak hamletovich. Stadier for å lage en AIS livssyklusmodell av AIS Hovedmetodene for å bygge en IS

Emne 1.2 Livssyklus for AIS og modeller Livssyklus AIS

AIS livssyklus -det er en kontinuerlig prosess fra det øyeblikket det tas en beslutning om behovet for å ta en beslutning om behovet for opprettelsen til den fullføres.

Livssyklusen til moderne AIS er ca. 10 år, noe som betydelig overstiger foreldelsen og den fysiske foreldelsen til teknisk og systemprogramvare som brukes i implementeringen av AIS. Derfor, i løpet av systemets livssyklus, utføres det som regel modernisering, hvoretter alle funksjonene til systemet skal utføres med ikke mindre effektivitet.

Å oppnå dette gjennom hele livssyklusen til AIS er en ganske vanskelig oppgave av en rekke objektive og subjektive årsaker, som et resultat av dette blir de aller fleste AIS-prosjekter gjennomført med brudd på kvalitet, tidsfrister eller estimater; nesten en tredjedel av prosjektene slutter å eksistere uferdige. I følge Standish Group i 1996 ble 84 % av AIS-prosjektene ikke fullført i tide, i 1998 falt dette tallet til 74 %, etter 2000 faller det ikke under 50 %. Hovedårsaken til denne situasjonen er at teknologinivået for å analysere og designe systemer, metoder og prosjektstyringsverktøy ikke samsvarer med kompleksiteten til systemene som lages, som stadig øker på grunn av komplikasjonen og raske endringer i virksomheten.

Det er kjent fra praksis i verden at kostnaden for å vedlikeholde AIS-applikasjonsprogramvare er minst 70 % av den totale kostnaden gjennom hele livssyklusen, så det er ekstremt viktig å designstadiet gi de nødvendige metodene og midlene for vedlikehold, inkludert metoder for konfigurasjonsstyring.

AIS-designprosessen er regulert av følgende dokumentasjon (standarder, metoder, modeller):

GOST 34.601-90- en standard for stadier og stadier for å lage AIS, tilsvarende kaskademodellen for programvarens livssyklus (diskutert nedenfor). Det gis en beskrivelse av innholdet i arbeidet på hvert trinn;

180/1EC 12207:1995- standard for prosesser og organisering av livssyklusen; gjelder alle typer tilpasset programvare; inneholder ikke en beskrivelse av faser, stadier og stadier;

Tilpasset utviklingsmetode(Oracle-metodikk) - teknologisk materiale for utvikling av anvendt AIS, detaljert til nivået av prosjektdokumenter som er tomme basert på bruk av Oracle. Det brukes for den klassiske livssyklusmodellen (alle arbeider, oppgaver og stadier er gitt), som samt for "rask utvikling"-teknologier (Fast Track) eller "lettvektstilnærming" anbefalt for små prosjekter.

Rasjonell enhetlig prosess(metodikk RUP) - teknologisk materiale for implementering av en iterativ utviklingsmodell, som inkluderer fire faser (utviklingssyklus): initiering, forskning, konstruksjon og implementering. Hver fase er delt inn i stadier (iterasjoner), hvis resultater er versjoner for intern eller ekstern bruk. Hver syklus avsluttes med generering av neste versjon av systemet. Hvis arbeidet med prosjektet ikke stopper etter det, fortsetter det resulterende produktet å utvikle seg og går gjennom de samme fasene igjen. Essensen av arbeid innenfor rammen av RUP-metodikken er opprettelse og vedlikehold av modeller basert på UML;

Microsoft Solution Framework(metodikk Leger Uten Grenser) - teknologisk materiale for implementering av en iterativ utviklingsmodell, lik RUP inkluderer fire faser: analyse, design, utvikling, stabilisering; innebærer bruk av objektorientert modellering. Leger Uten Grenser er mer fokusert på utvikling av forretningsapplikasjoner enn RUP;

Ekstrem programmering (XP)- ekstrem programmering (den nyeste blant de vurderte metodene); ble dannet i 1996. Grunnlaget for metodikken er teamarbeid, effektiv kommunikasjon mellom kunden og entreprenøren gjennom hele prosjektet; utviklingen av AIS utføres ved hjelp av suksessivt raffinerte prototyper.

ISO/IEC 12207-standarden i livssyklusrammeverket definerer prosessene som utføres når man oppretter AIS-programvare. Disse prosessene er delt inn i tre grupper:

hoved-(anskaffelse, forsyning, utvikling, drift og vedlikehold);

hjelpemiddel(dokumentasjon, konfigurasjonsstyring, kvalitetssikring, verifisering, validering, evaluering, revisjon og problemløsning);

organisatorisk(prosjektledelse, opprettelse av prosjektinfrastruktur, definisjon, evaluering og forbedring av selve livssyklusen, opplæring).

Blant hovedprosesser livssyklus de viktigste er utvikling, drift og akkompagnement. Hver prosess er preget av visse oppgaver og metoder for å løse dem, de første dataene innhentet på forrige trinn og resultatene.

Utvikling AIS inkluderer alt arbeid med å lage programvare og dens komponenter i samsvar med spesifiserte krav. Denne prosessen inkluderer også:

Utarbeidelse av design- og driftsdokumentasjon;

Forberedelse av materialer som er nødvendige for å teste det utviklede programvareprodukter;

Utvikling av materiell nødvendig for opplæring av ansatte.

Komponentene i utviklingsprosessen er som regel strategisk planlegging, analyse, design og implementering (programmering).

Å behandle utnyttelse relatere:

Konfigurere databasen og brukerens arbeidsstasjoner;

Gi brukere driftsdokumentasjon;

Opplæring.

Viktige operasjonelle aktiviteter inkluderer:

Direkte drift;

Lokalisering av problemer og eliminering av årsakene deres;

Programvare modifikasjon;

Utarbeidelse av forslag til forbedring av systemet;

Utvikling og modernisering av systemet.

Profesjonell, kompetent eskorte- nødvendig tilstand løse oppgaver utført av AIS. Tjenester teknisk støtte spille en svært fremtredende rolle i livet til enhver AIS. Feil på dette stadiet kan føre til åpenbare eller skjulte økonomiske tap som kan sammenlignes med kostnadene for selve systemet.

Til foreløpige handlinger i organisering Vedlikehold AIS inkluderer:

Identifisering av de mest kritiske nodene i systemet og bestemmelse av kritiskheten av nedetid for dem (dette vil tillate oss å identifisere de mest kritiske komponentene i AIS og optimere allokeringen av ressurser for vedlikehold);

Definisjon av vedlikeholdsoppgaver og deres inndeling i interne, løst av styrkene til serviceavdelingen, og eksterne, løst av spesialiserte serviceorganisasjoner (dermed er spekteret av funksjoner som utføres klart begrenset og ansvaret er fordelt);

Gjennomføre en analyse av de tilgjengelige interne og eksterne ressursene som er nødvendige for organisering av vedlikehold innenfor rammen av de beskrevne oppgavene og kompetansefordelingen (hovedkriteriene for analyse: tilgjengeligheten av en garanti for utstyr, tilstanden til reparasjonsfondet, kvalifikasjonene til personell);

Utarbeidelse av en plan for organisering av vedlikehold med definisjon av stadiene av handlingene som skal utføres, tidspunktet for utførelse av dem, kostnadene på stadiene, utøvernes ansvar.

Å sikre høykvalitets vedlikehold av sløyfesystemet krever involvering av høyt kvalifiserte spesialister som er i stand til å løse ikke bare daglige administrative oppgaver, men også raskt gjenopprette systemets ytelse i tilfelle feil og ulykker.

Blant støtteprosesser en av de viktigste er konfigurasjonsstyring, som støtter hovedprosessene i AIS-livssyklusen, først og fremst utviklings- og vedlikeholdsprosessene.

Utviklingen av kompleks AIS innebærer uavhengig utvikling av systemkomponenter, noe som fører til fremveksten av mange alternativer og implementeringsversjoner av både individuelle komponenter og systemet som helhet. Dermed er det et problem med å sikre bevaring av en enkelt struktur under utvikling og modernisering av AIS. Konfigurasjonsadministrasjon lar deg organisere, systematisk registrere og kontrollere endringer til ulike komponenter AIS i alle stadier av livssyklusen.

Organisatoriske prosesser er av stor betydning, siden moderne AIS er store komplekser, i opprettelsen og vedlikeholdet av hvilke mange mennesker med forskjellige spesialiteter er ansatt.

Prosess (prosessutøver)	Handlinger"	Inngang	Resultat
Oppkjøp (kunde)	Initiering. Utarbeidelse av søknadsforslag. Utarbeidelse av kontrakt. Leverandøraktivitetskontroll. AIS aksept	Beslutning om å starte arbeidet med implementering av AIS. Resultatene av en undersøkelse av kundens aktiviteter. Resultater av analysen av AIS/anbudsmarkedet. Levering/utviklingsplan. Omfattende AIS-test	Mulighetsstudie for innføring av AIS. Referansevilkår for AIS. Leverings-/utviklingskontrakt. Handlinger for aksept av stadier av arbeidet. Aksepttestrapport
Supply (AIS-utvikler)	Initiering. Svar på bud. Utarbeidelse av kontrakt. Planlegging av utførelse. Levering av AIS	Referansevilkår for AIS. Ledelsens beslutning om å delta i utviklingen. anbudsresultater. Referansevilkår for AIS. Prosjektledelsesplan. Utviklet AIS og dokumentasjon	Beslutningen om å delta i utviklingen. Kommersielle tilbud/bud. Leverings-/utviklingskontrakt. Prosjektledelsesplan. Implementering/justering. Aksepttestrapport
Utvikling (AIS-utvikler)	Opplæring. Analyse av krav til AIS. AIS-arkitekturdesign. Utvikling av programvarekrav. Design av programvarearkitektur. Detaljert programvaredesign. Programvarekoding og testing. Programvareintegrasjon og. IS-integrasjon og AIS-kvalifikasjonstesting	Referansevilkår for AIS. Referansevilkår for AIS, modell for livssyklus. Referansevilkår for AIS. AIS undersystemer. Kravspesifikasjoner for programvarekomponenter Programvarearkitektur Materialer for detaljert programvaredesign Programintegreringsplan, tester IS-arkitektur, programvare, IS-dokumentasjon, tester	Brukt livssyklusmodell, utviklingsstandarder. Arbeidsplan. Sammensetningen av delsystemer, utstyrskomponenter. Kravspesifikasjoner for programvarekomponenter. Sammensetningen av programvarekomponentene, grensesnitt med databasen, programvareintegrasjonsplan. Databasedesign, grensesnittspesifikasjoner mellom programvarekomponenter, testkrav. Tester av programvaremoduler, handlinger for autonom testing. Vurdering av programvarekompleksets samsvar med kravene til TOR. Samsvarsvurdering av programvare, database, teknisk kompleks og et sett med dokumentasjon til kravene i TOR

Prosjektledelse er relatert til spørsmålene om planlegging og organisering av arbeid, opprettelse av team av utviklere, overvåking av timingen og kvaliteten på arbeidet. Teknisk og organisatorisk støtte til prosjektet inkluderer:

Valg av metoder og verktøy for prosjektgjennomføring;

Definisjon av metoder for å beskrive tilstanden i utviklingsprosessen;

Utvikling av metoder og midler for å teste den opprettede programvaren;

Opplæring.

Designkvalitetssikring er relatert til problemene med verifisering, verifikasjon og testing av AIS-komponenter.

Bekreftelse - prosessen med å avgjøre om den nåværende utviklingstilstanden oppnådd på et gitt stadium oppfyller kravene til det stadiet.

Undersøkelse- prosessen med å bestemme samsvar med utviklingsparametere med de første kravene. Verifikasjon overlapper noe med testing, som utføres for å bestemme forskjellene mellom faktiske og forventede resultater, samt for å vurdere samsvar med AIS-ytelsen med de opprinnelige kravene.

I 2002 En standard for livssyklusprosesser for automatiserte systemer (ISO/IEC 15288 System Life cycle processes) er publisert. Eksperter fra ulike virksomhetsfelt deltok i utviklingen av standarden; praktisk erfaring med å lage systemer i offentlige, kommersielle, militære og akademiske organisasjoner ble tatt i betraktning. I henhold til ISO/IEC 15288-serien er følgende prosessgrupper inkludert i LC-strukturen.

1. Kontraktsmessige prosesser:

Oppkjøp (in-house løsninger eller eksterne leverandørløsninger);

Levering (interne løsninger eller løsninger fra ekstern leverandør).

2. Bedriftsprosesser:

Kontroll miljø bedrifter;

Kapitalforvaltning; i forvaltningen av livssyklusen til IP;

Ressursforvaltning;

Kvalitetskontroll.

3. Designprosesser:

Prosjektplanlegging;

Prosjektevaluering;

Prosjektkontroll;

Håndtering av risikoer;

Konfigurasjonsstyring;

Informasjonsflytstyring;

Å ta avgjørelser.

4. Tekniske prosesser:

Definisjon av krav;

Kravanalyse;

Utvikling av arkitektur;

gjennomføring;

Integrering;

Bekreftelse;

Overgang;

sertifisering;

Utnyttelse;

Eskorte;

Avhending.

5. Spesielle prosesser:

Definisjon og etablering av sammenhenger ut fra oppgaver og formål.

I tabellen. 1.4 viser listen over etapper og hovedresultatene når de er fullført i henhold til spesifisert standard.

På 1970-tallet IBM har foreslått Business System Planning (BSP) metodikk ellerk.

En metode for å strukturere informasjon ved bruk av skjæringsmatriser for forretningsprosesser, funksjonelle inndelinger av databehandlingssystemer (IS), informasjonsobjekter, dokumenter og databaser, forslag i BSP, deres sekvens (få toppledelsesstøtte, definer bedriftsprosesser, definer prosesser, dataklasser , ta med intervjuer, behandle og organisere intervjudata) finnes i nesten alle formelle metoder, samt i prosjekter implementert i praksis.

Tabell 1.4.AIS-opprettingsstadier (ISO/IEC 15288)

I følge publiserte data krever hvert trinn i AIS-utvikling en viss tid. Mesteparten av tiden (45-50%) brukes på koding, kompleks og frittstående testing (fig. 14). I gjennomsnitt tar utviklingen av AIS en tredjedel av hele livssyklusen til systemet (Figur 1.5).

Fig.1.4. Fordeling av tid i utviklingen av AIS

I. Byggesteiner av AIS. Metoder og designverktøy Design- prosessen med å lage et prototypeprosjekt, en prototype av et foreslått eller mulig objekt, dets tilstand. Moderne teknologi for å lage AIS er et sett med effektive designverktøy og metoder som gjør det mulig å forenkle denne prosessen, redusere kostnadene, redusere systemdesign-kalendertiden og, til slutt, på grunn av muligheten for et bredere utvalg av velprøvde progressive designløsninger, forbedre kvaliteten på utviklingen. Grunnleggende designverktøy: - standard midler for operativsystemer som gir automatisk passasje på en datamaskin av en viss klasse av oppgaver; - prosedyrer som implementerer typiske databehandlingsprosesser, for eksempel kontroll av utdatainformasjon og sortering av den; -verktøy, som inkluderer et sett med sammenhengende spesialprogramvareverktøy utviklet for å støtte individuelle elementer i AIS-designprosessen. Dette er opprettelse og oppdatering av en dataordbok, prosjektdokumentasjon, automatisering av designkontroll, etc.; - typiske komponenter presentert i form av standard designløsninger (TPR) og applikasjonsprogramvarepakker (APP). TPR - et sett med algoritmiske, programvare, instruktive og metodiske elementer som gir maskinimplementering av oppgaver eller et kompleks ved hjelp av passende tekniske midler. TPR - grunnlaget for opprettelsen av PPP, som inkluderer programvarepakker som sikrer driften av typiske konfigurasjoner av datateknologi, dialogsystemer ved løsning av typiske funksjonsproblemer; -datastyrt design (CAD)-systemer som involverer bruk av datamaskiner i alle stadier av opprettelsen av AIS og okkuperer det høyeste stadiet i utviklingen av systemdesignverktøy. Designmetoder skiller mellom klasser og underklasser: Klasser: -original design. Verktøy som brukes i denne metoden: - standardverktøy for operativsystemer; - prosedyrer som implementerer typiske databehandlingsprosesser. - standard design. Underklasser: elementer, undersystemer, objekt, gruppe. Verktøy: standardverktøy for operativsystemer; typiske komponenter (TPR, PPP); noen verktøy. - datastyrt design. Underklasser: modulære; andre verktøy: standardverktøy for CAD-operativsystemer; et sammenkoblet sett med verktøy. Designverktøy er delt inn i: - komplekse - disse er TPR, PPP, standard design av automatiserte systemer, CAD. - lokalt - et bredt utvalg, de inkluderer databasestyringssystemer, telebehandling, verktøy, etc. Generelle Kravå designe verktøy: -full dekning av hele prosessen med å lage AIS; -kompatibilitet, som krever koordinerte beslutninger både i prosessen med å lage et system og dets støttende delsystemer, og i prosessen med deres funksjon; -universalitet i sin klasse, som gir muligheten til å bruke de samme verktøyene for forskjellige objekter; -d.b. lett tilgjengelig, krever ikke mye innsats å lære og lett å implementere; - muligheten for å organisere designprosessen i modusen for interaktiv interaksjon mellom systemutvikleren, designeren og datamaskinen; -d.b. tilpasset og kostnadseffektiv. Opprinnelige designmetoder er tradisjonelle og fokusert på én bedrift. Karakteristisk- utvikling av originale metoder for å kartlegge et objekt, dets implementering, opprettelse av nødvendig prosjektdokumentasjon i form av et individuelt prosjekt. Verdighet - refleksjon i AIS-prosjektet av de spesifikke egenskapene til automatiseringsobjektet. Ulemper: relativt høy arbeidsintensitet og lang utviklingstid, lav funksjonell pålitelighet og tilpasningsevne til skiftende forhold. Prosjekter opprettet etter den opprinnelige metoden er mottagelig for modernisering, men denne metoden brukes sjelden i sin rene form. I implementeringen brukes det for tiden ulike designverktøy, og kun enkelte deler av prosjektet krever originale designløsninger. Så, systemomfattende designløsninger for utviklingen informasjonsstøtte inkludere metoder for å samle inn, kontrollere og overføre data, lage regulerings- og referanseinformasjonsmatriser på programvare, bestemme versjonen av operativsystemet, typisker, etc. Dette jevner litt ut sine mangler. Denne metoden er spesielt relevant ved automatisering av komplekse, ikke-vanlige objekter. Typisk design- Den industrielle metoden for å lage AIS, ved bruk av TPR og PPP, er preget av tilstedeværelsen av velprøvde, typiske organisatoriske, økonomiske, tekniske, informasjons-, matematiske og programvareverktøy for automatisering av kontroll. Fordeler: reduserer arbeidsintensiteten, reduserer kostnader og reduserer designtid, forbedrer kvaliteten ved mer fullstendig dekning av oppgavene til funksjonelle delsystemer, streng overholdelse av kravene normative dokumenter, anvendelse av avanserte tekniske løsninger. Standarddesign er designet for å eliminere duplisering av prosjekter, skape et grunnlag for å utvide utvekslingen av ferdige standardkomponenter, og lette utviklingen av anbefalinger for å endre organisasjonsstrukturen og styringsmetoder, under hensyntagen til industri og intra-økonomiske egenskaper. Prosessen med typisk design består i valg og binding av disse verktøyene i samsvar med kravene til et bestemt system. Den typiske delen av AIS er et kompleks av informasjon, programvare og teknisk støtte. Den typiske karakteren til den første oppnås ved streng overholdelse av strukturens enhet informasjonsgrunnlag, sammensetning av matriser, former for input og output dokumenter; den andre - om bruk av PPP, og den siste som et resultat av bruk av datamaskiner av samme eller felles typer. det grunnleggende elementær design er TPR - resultatet av flere sammenhengende teknologiske designoperasjoner, når du utvikler et prosjekt, er det allerede brukt nøkkelferdig løsning med mindre modifikasjoner, i stedet for å utvikle en ny. Komplekset av typiske designløsninger er delt inn i tre grupper: "Teknikk", "Oppgave", "Personal". Første gruppe tjener til å velge og fullføre alle typer tekniske midler til datasentre eller andre. organisasjonsformer søknadene deres. Sekund- inneholder dokumentasjon om den organisatoriske og økonomiske essensen av hver oppgave, algoritmer for deres løsning, beskrivelse av input og output informasjon, tilsvarende programvaremoduler med deres beskrivelser og bruksanvisninger. Tredje- stillingsbeskrivelser for alle kategorier av ansatte, som definerer deres rettigheter og plikter. TPR lages i henhold til det modulære prinsippet, når hver designløsning er delt inn i separate komponenter - moduler som implementerer en viss del av TPR. Dette lar deg lage et prosjekt av et nytt automatisert system ved å kombinere individuelle typiske moduler. Ved hjelp av delsystem metode mer enn høy grad integrasjon av typiske elementer i systemet, når prosjekter av løsninger og applikasjonspakker lages for hvert delsystem. Tildeling av delsystemer - avhengig av formålet med den økonomiske prosessen og produksjonsprosessen. For hvert av delsystemene utvikles egen automatisert designløsning og OPS, som kan være systemdekkende eller funksjonelle. Den første gruppen inkluderer PPP-datahåndtering, typiske prosedyrer for deres behandling, metoder for matematisk statistikk og diskret programmering, løsning av kontinuerlige problemer, for eksempel differensialligninger. Den andre gruppen inkluderer pakker fokusert på industribedrifter med en diskret eller kontinuerlig produksjon, på den ikke-industrielle sfæren og sektoriell ledelse. Et viktig krav for OPS er kompatibilitet, fordi ved utforming av AIS er det lurt å bruke flere pakker samtidig. Utformingen av systemer som bruker PPP kommer faktisk ned på å binde pakkene valgt av visse parametere til de spesifikke betingelsene for automatiseringsobjektet. Fordeler: mindre tidkrevende prosess, tar mindre tid sammenlignet med det opprinnelige designet, implementerer avanserte databehandlingsmetoder, forenkler prosjektdokumentasjon, fordi pakkedokumentasjon brukes, økes påliteligheten til de utformede systemene. Metode objektdesign er basert på bruk av standard design av automatiserte kontrollsystemer. Det er ikke mye brukt, pga det er for mange forskjellige objekter, og modifikasjon av en typisk systemdesign i samsvar med de spesifikke betingelsene for automatiseringsobjektet krever mye arbeid og materialkostnader. En egen gruppe skiller seg ut gruppedesignmetode. Dens essens: en gruppe gjenstander av samme type i henhold til deres egenskaper er foreløpig valgt. informasjonssystemer, blant dem er basisobjektet valgt, som prosjektet utvikles for, og ulike designmetoder og metoder kan brukes, det viktigste er å sikre dens høye tilpasningsevne. Hovedomfanget av denne metoden er ikke-industrielle anlegg (for eksempel varehus), fordi de er mer stabile fra det økonomiske informasjonssystemets ståsted. Blant de automatiserte metodene er en spesiell plass okkupert av modulære designmetoder. Opprettelsen og bruken av CAD gir et tilstrekkelig høyt nivå av funksjonell pålitelighet, omfattende dekning av alle teknologiske prosesser og en reduksjon i arbeidsintensitet. designarbeid med maksimal hensyntagen til automatiseringsobjektets interesser. Denne metoden er imidlertid ganske dyr og krever svært dyktige utviklere. Nøkkelkravet for CAD er evnen til å bygge og vedlikeholde i designsystemet i en tilstrekkelig tilstand av en global økonomisk informasjonsmodell av automatiseringsobjektet. Modell- Visning av informasjonskomponenter til automatiseringsobjektet og forholdet mellom dem, spesifisert eksplisitt. Hovedmålet med å bygge en modell er å lage et AIS-prosjekt tilsvarende denne modellen, som tar hensyn til og aktivt bruker alle egenskapene til objektet. En slik modell bør i formalisert form inneholde en beskrivelse av settene med informasjonskomponenter og forholdet mellom dem, inkludert informasjonslenker og algoritmisk interaksjon. Ved hjelp av den modulære designmetoden brukes en systematisk tilnærming, som bestemmer bruken av datamaskiner ikke bare i alle stadier av å lage et system, men også i ferd med å analysere resultatene av dets industrielle drift. Utviklingen og bruken av CAD forutbestemte overgangen til opprettelsen av individuelle prosjekter, men på et mye høyere nivå enn den opprinnelige designmetoden. Utvikling, implementering, vedlikehold og drift av bedriftens informasjonssystemer (eller CIS for kort) utføres av informasjonsteknologi (IT) spesialister. Informasjonsteknologi er et veldig vidt begrep, siden de definerer metodene og midlene for å skape, samle inn, registrere, overføre, behandle, lagre og utstede informasjon i informasjonssystemer. For tiden, sammen med navnet Corporate Information Systems (CIS), brukes for eksempel følgende navn: Automatiserte systemer ledelse (ACS); · Integrerte styringssystemer (IMS); · Integrerte informasjonssystemer (IIS); · Enterprise Management Information Systems (EMIS). Hovedstadiene for å designe automatiserte informasjonssystemer Før du starter utformingen av en AIS, er det nødvendig å begrunne i detalj behovet for opprettelsen, beskrive i detalj målene og målene for prosjektet, forventet fortjeneste, tidskostnader, tilgjengelige ressurser, begrensninger osv. Slikt arbeid kalles ofte strategisk planlegging av informasjonssystemet, og det utnevnes en prosjektleder til å utføre dem. Behovet for å utvikle AIS kan skyldes følgende faktorer: den økende betydningen av informasjonsmiljøet til bedriften; kompleksiteten til bedriftsstyringssystemet; behovet for å analysere potensielle muligheter og farer ved bedriften; behovet for å systematisere virksomheten til virksomheten; behovet for å kontinuerlig forbedre effektiviteten av bruken av anleggsmidler til bedriften, forbedre forholdet mellom pris og kvalitet; øke rollen til kapitalinvesteringer innen informatisering av bedriften; behovet for personellplanlegging for å sikre utviklingen av bedriften tilstrekkelig; veksten av kompleksitet og fullstendighet av eksisterende IS, som medfører komplikasjoner av funksjonelle krav til IS og deres utvikling. hovedfunksjon strategisk planlegging informasjonssystem ligger i at det er i denne perioden organisasjonens behov for informasjon spesifiseres, som avgjør mulige alternativer strukturer i informasjonssystemet. Avhengig av funksjonsintensiteten til informasjonsteknologikomplekset, skilles følgende grupper av organisasjoner ut: organisasjoner hvis utvikling avhenger av bruken av informasjonsteknologi til daglige aktiviteter (banker, Forsikringsselskap etc.); organisasjoner som ikke er avhengig av informasjonsteknologi, men som er i stand til å bruke dem mye i fremtiden for å oppnå konkurransefortrinn; organisasjoner i hvis aktiviteter informasjonsteknologi ikke kan bli en kilde til konkurransefortrinn; organisasjoner som bruker informasjonsteknologi for å støtte ikke-kjerneaktiviteter. For hver av de beskrevne gruppene utvikles informasjonssystemer som automatiserer tilsvarende områder av organisasjonens aktiviteter. Utviklingen og implementeringen av enhver AIS utføres i en bestemt rekkefølge i samsvar med referansevilkårene. Innholdet i den første fasen av styringssystemet bestemmes av sammensetningen av oppgavene med regnskap, analyse, planlegging og operasjonell ledelse, den mest mottagelige for automatisering og avgjørende for vedtaket ledelsesbeslutninger I organisasjonen. I prosessen med å utvikle de neste stadiene av systemet, utvidelse og integrasjon av informasjon, programvare og matematisk støtte, skjer modernisering av tekniske midler. AIS-livssyklusen lar oss skille mellom fire hovedperioder: forprosjekt, design, implementering, drift og vedlikehold. Teknologien for utforming av automatiserte informasjonssystemer bestemmes for tiden av gjeldende GOST 34.601-90, ifølge hvilken hele prosessen er delt inn i stadier og stadier. 1. Trinn "Utforming av krav til AIS": fastsettelse av omfanget av begrunnelse som er nødvendig for å opprette AIS (innsamling av data om automatiseringsobjektet og pågående aktiviteter, vurdering av kvaliteten på funksjonen, identifisering av problemer som kan løses ved hjelp av automatisering, vurdering av gjennomførbarheten av å lage AIS); dannelse av brukerkrav for AIS; utarbeidelse av rapport om utført arbeid og innlevering av søknad om utvikling av AIS. 2. Trinn "Utvikling av AIS-konseptet": studie av AIS-objektet; utføre nødvendig forskning og designarbeid; utvikling av AIS-variantkonsept og valg av alternativ som møter brukerens krav, vurdering av fordeler og ulemper ved alternative alternativer; utarbeidelse av rapport om utført arbeid. 3. Trinn "Terms of Reference": utvikling og utførelse av referansevilkår for opprettelse av AIS (generell informasjon, formål og mål for systemet som opprettes, egenskaper til automatiseringsobjektet, krav til systemet som helhet, dets funksjoner og oppgaver, typer støtte, arbeidsplaner for opprettelsen, innspill til handling og aksept). 4. Trinn "Utkastdesign": utvikling av foreløpige designløsninger for systemet og dets deler (funksjoner til AIS, dets undersystemer, oppgaveomfang, konsept og struktur av informasjonsbasen, sammensetning og hovedkarakteristika for tekniske midler); utvikling av dokumentasjon for AIS og dets elementer. 5. Trinn "Teknisk design": utvikling av utkast til beslutninger om systemet og dets elementer, om funksjonell, algoritmisk og organisasjonsstruktur systemer, strukturen til tekniske midler, organisering og vedlikehold av databasen, klassifiserings- og kodesystemet for informasjon, algoritmen for å løse problemer, programmeringsspråkene og programvaren som brukes; utvikling av AIS-dokumenter; utvikling og utførelse av dokumentasjon for levering av produkter for anskaffelse av AIS og tekniske krav til utvikling av dem; utvikling av designoppdrag. 6. Trinn "Detaljert design": utvikling av arbeidsdokumentasjon for systemet og dets deler; utvikling eller tilpasning av programmer. 7. Trinn "Igangkjøring": forberedelse av AIS for implementering; sette oppgaver og delsystemer i prøvedrift; utarbeidelse av igangsettingsrapport. 8. Stage "Support AIS": analyse av funksjonen til systemet; forfatterens tilsyn. Et trekk ved utviklingen av AIS er konsentrasjonen av kompleksitet og arbeidsintensitet i stadiene av forprosjektundersøkelsen, siden feil som gjøres på stadiene av undersøkelse, analyse og design gir opphav til ofte uløselige problemer med å nå målene og effektiviteten til ved hjelp av AIS på stadier av implementering og drift. Dannelsen av krav til systemet innebærer definisjonen av dens funksjonalitet, brukerkrav, krav til pålitelighet og sikkerhet, til eksterne grensesnitt etc. Arbeidsplanlegging inkluderer en foreløpig økonomisk vurdering av prosjektet, konstruksjon av arbeidsplan, opprettelse og opplæring av felles arbeidsgruppe. På dette stadiet utføres en systemanalyse av systemet som vurderes, som inkluderer en beskrivelse av strukturen til systemelementene og en undersøkelse av aktiviteten til det automatiserte objektet; analyse av funksjonsfordelingen på avdelinger og ansatte, informasjonsflyt innen avdelinger og mellom disse, eksterne objekter i forhold til organisasjonen og eksterne informasjonssamhandlinger. Faen ja. Analysen avsluttes med konstruksjonen av modeller for organisasjonens aktivitet, som involverer behandling av undersøkelsesmateriale og konstruksjon av funksjonelle og informasjonsmodeller av to typer: "som den er"-modellen ("som den er"), som gjenspeiler den nåværende tilstanden til saker i organisasjonen; modell "å være" ("som den burde være"), som gjenspeiler ideen om nye teknologier og forretningsprosesser i organisasjonen. Basert på resultatene av undersøkelsen bestemmes en liste over oppgaver, løsningen som er tilrådelig å automatisere, og sekvensen av deres utvikling (fig. 8.2). Ris. Undersøkelsesresultater Referansen er et dokument som definerer mål, krav og grunnleggende inputdata som er nødvendige for utvikling av AIS og nivåbestemmelse. økonomisk effektivitet dens gjennomføring. Innholdet og utformingen av referansevilkårene er regulert av kravene i GOST 34.602-89. Det foreløpige prosjekteringsstadiet innebærer et foreløpig valg av designmetoder og en vurdering av forventede resultater, men ofte inngår dette stadiet i den tekniske prosjekteringen. Det tekniske prosjektet utvikles for å bestemme hoveddesignbeslutningene for etableringen av systemet. På dette stadiet utføres et kompleks av forskningsarbeider for å velge de beste alternativene beslutninger, en eksperimentell evaluering av designløsninger og beregning av systemets økonomiske effektivitet gjennomføres. For hver oppgave som er inkludert i settet med prioriterte oppgaver, utføres en detaljert beskrivelse av oppgaven og utviklingen av en algoritme for løsningen. Hensikten med dette stadiet er dannelsen av en ny struktur av systemet og de logiske forholdene mellom elementene som vil fungere på det valgte teknologiske grunnlaget. Konstruksjonen av en systemarkitektur innebærer valg av elementer og moduler av informasjon, teknisk, programvare og andre støttende undersystemer, definisjon av informasjon og kontrollkoblinger mellom de valgte elementene og utvikling av. Detaljdesign inkluderer utvikling av spesifikasjoner for hver komponent og materialer som sikrer effektiv drift av AIS, som inneholder oppdaterte data og detaljerte systemdekkende designløsninger, programmer og instruksjoner for problemløsning, samt en oppdatert vurdering av kostnadseffektiviteten. av AIS. Den tekniske delen av arbeidsutkastet gir definisjon av tekniske midler, en beskrivelse av den teknologiske prosessen med databehandling, beregning og planlegging av lasting av et kompleks av tekniske midler, en beskrivelse av driftsmåten til AIS. Gjennomføringen av det utviklede prosjektet involverer følgende stadier: forberedelse av kontrollobjektet for implementering av AIS, pilotimplementering, dvs. kontroll av funksjonaliteten til elementene og modulene i prosjektet og eliminering av identifiserte feil, og industriell implementering - stadiet av igangkjøring og testing på funksjonsnivå, overvåking av samsvar med kravene formulert på stadiet av systemanalyse (fig. 8.3). På drifts- og vedlikeholdsstadiet samles det inn statistikk om kvaliteten på hver av systemkomponentene, de oppdagede manglene korrigeres, i noen tilfeller tas det en beslutning om behovet for å utvide funksjonaliteten til systemet (fig. 8.4) . Generelt inkluderer AIS-designprosessen betinget bare hovedstadiene, og det faktiske settet med stadier og teknologiske operasjoner avhenger i stor grad av den valgte designtilnærmingen. Ris. Hovedarbeidet utført på stadiet av AIS-implementering Fig. Arbeider utført på drifts- og vedlikeholdsstadiet

Stadiet med fysisk modellering skal på eksperimentelt nivå gi en verifisering av den reelle ytelsen til de opprettede AIS-modellene og deres tilstrekkelighet. For å implementere dette stadiet utvikles en fysisk (naturlig) modell av AIS. Fysisk modell av AIS- Dette er et sett med struktur, metoder og midler for en redusert fullskala implementering av AIS, designet for å teste ytelsen til et fremtidig system og tilstrekkeligheten til modellene under reelle forhold.

På en viss måte har den fysiske modellen til AIS egenskapene til et ekte system. For konstruksjonen er datamaskiner, perifere enheter, dokumenter, filer, databaser, databehandlingsprogrammer og andre komponenter som er nødvendige for å lage AIS involvert. Den fysiske modellen av AIS er redusert, d.v.s. dette er en redusert representasjon av det. Reduksjonen her er ikke mekanisk, ikke vilkårlig, men harmonisert. Den presenterer bare de egenskapene som utviklerne klassifiserte som grunnleggende, essensielle.

3. AIS design

Basert på de utviklede prinsippene, bestemmelsene, modellene, metodene og verktøyene for å bygge AIS oppnådd på forskningsstadiet, er systemet under utforming.

Designstadiet består av følgende trinn:

1) emneundersøkelse (PRO) av eksisterende (tradisjonell) IP;

2) utvikling av tekniske spesifikasjoner for etableringen av systemet;

3) utvikling av et teknisk prosjekt for å lage systemet;

4) utvikling av et arbeidsutkast for opprettelse av systemet.

Forutsatt at eksisterende IS er automatisert, er det to måter å designe på: modernisering av eksisterende AIS eller fullstendig erstatning med en nyopprettet AIS. Med relativt små volum designarbeid kan trinn 2 og 3 kombineres.

PRO-stadiet utføres for å studere og analysere egenskapene til objektet - den eksisterende tradisjonelle IS. Innsamling av materialer for design utføres - definisjonen av krav, studiet av designobjektet. Betingelsene for funksjonen til fremtidens AIS studeres, visse begrensninger på utviklingsforholdene etableres - tidspunktet for designstadiene, tilgjengelige og manglende ressurser, prosedyrer og tiltak for å sikre beskyttelse av informasjon, etc. Ta hensyn til ta hensyn til forstudiene, gjennomføres utvikling og valg av AIS konseptvarianten.

Utviklingsstadium av tekniske spesifikasjoner- en logisk fortsettelse av missilforsvarsfasen. Materialer oppnådd på ABM-stadiet brukes til å utvikle ToR. Her utføres analysen og utviklingen av de grunnleggende kravene til AIS av en bestemt kunde eller potensiell forbrukergruppe. Kravene til maskinvare, programvare, informasjon og organisasjonsjuridiske komponenter i AIS, etc. er formulert.

På trinn i teknisk design søket etter de mest akseptable løsningene for alle AIS-designoppgaver utføres. Hensikten med dette designstadiet er å konkretisere generell, noen ganger uklar kunnskap om kravene til det fremtidige systemet. På dette stadiet bestemmes følgende:

formålet, oppgavene, funksjonene til AIS, de ytre forholdene for systemets funksjon, fordelingen av funksjoner mellom dets komponenter vurderes også;

AIS-systemparametere - grensesnitt og fordeling av funksjoner mellom operatøren og systemet;

konfigurasjon av alle AIS-undersystemer som danner strukturen - dokumentarinformasjon, tekniske, programvare-matematiske og organisatoriske-juridiske komponenter i systemstrukturen;

struktur- og databasestyringssystem, språklige verktøy, sammensetning av informasjonsinnhentingsspråk, klassifiserere og kodifikatorer, metoder for indeksering av dokumenter og spørringer;

konfigurasjonsark for komplekset av tekniske midler til AIS og deres spesifikasjoner;

sammensetning og egenskaper av matematiske modeller, algoritmer og AIS-programmer;

system for funksjon av AIS, teknologisk prosess for databehandling, etc.;

jobb- og arbeidsinstrukser for AIS-personell;

oppdatert mulighetsstudie av prosjektet.

Hoveddelen av arbeidsintensiteten til detaljert design er arbeidet med utviklingen av algoritmer og relaterte programmer.

På detaljert designstadium den endelige foredlingen av de problemene som på stadium av teknisk design av visse grunner ikke kunne løses fullt ut, utføres. På dette stadiet utvikles et sett med programmer basert på algoritmer kompilert på stadiet av teknisk design. Strukturen til databasen blir spesifisert, de enhetlige formatene til dokumenter behandlet i AIS-teknologi blir justert.

På dette stadiet testes programmer, en serie med kontrolltester med behandling av ekte dokumenter, resultatene av testing og eksperimentell behandling, analyseres nødvendige justeringer av programmer.

Metoder og verktøy for utforming av AIS. AIS-design kan utføres:

tredjepartsutvikler. Dette firmaet har en stab av høyt kvalifiserte fagfolk. Arbeidet utføres på grunnlag av avtale mellom utbygger og kunden;

av personalespesialister fra kundeselskapet.

En kompromissløsning er også mulig: Kundefirmaet kan invitere en konsulent for utvikling av AIS på kontraktsbasis.

Det spesifikke valget bestemmes av mange faktorer, spesielt den økonomiske tilstanden til kundeselskapet, tilgjengeligheten av heltidsspesialister med passende profil og nivå, tidspunktet for opprettelsen av AIS, tilstedeværelsen i den gitte eller nærliggende regionen av det tilsvarende utbyggerselskapet, fagkonsulenter, selskapets taushetsregime mv.

Egnede metoder og verktøy brukes for å løse designproblemer. Blant dem bør man finne slike metoder som radikalt vil løse problemene med å utvikle AIS. En slik metode er strukturanalyse. Det er en metode for å studere et system som betrakter systemet som en hierarkisk struktur fra dets generelle nivå til det nødvendige laveste.

På stadiet av forprosjektundersøkelsen brukes metoder for å studere den faktiske tilstanden til den eksisterende (tradisjonelle) IP:

muntlig eller skriftlig avhør;

skriftlig undersøkelse;

observasjon, måling og evaluering;

diskusjon av mellomresultater;

oppgaveanalyse;

analyse av produksjon, ledelse og informasjon

prosesser.

Metoder for dannelsen av en gitt tilstand er forbundet med den teoretiske underbyggelsen av alle bestanddeler AIS tar hensyn til kundens mål, krav og betingelser. Disse inkluderer:

modellering av databehandlingsprosesser;

strukturell design;

dekomponering;

informasjonsteknologianalyse.

For en visuell representasjon av AIS-objekter og prosesser, brukes metoder for grafisk visning av faktiske og spesifiserte tilstander - flytskjemaer, grafer, tegninger, tegninger, skisser, diagrammer, etc.

4. AIS design automatisering

Datastøttede designsystemer er et effektivt middel for å forbedre AIS-designindikatorer. Innen design har det blitt dannet en spesiell retning - software engineering eller CASE-teknologier (Computer-Aided Software / System Engineering - et system for utvikling av dataprogramvare). CASE-teknologier er et sett med metoder for analyse, design, utvikling og implementering av AIS, støttet av et sett med sammenkoblede automasjonsverktøy. CASE-technologies er et verktøy for systemanalytikere, utviklere og programmerere som gir automatisering av AIS-designprosesser av ulike klasser og verdier.

Hovedmålet med CASE-teknologi er å automatisere utviklingsprosessen så mye som mulig og å skille designprosessen fra kodingen av AIS-programvare.

Strukturelle metoder for å bygge bedriftsmodeller. Det er vanlig å kalle en strukturell metode en slik metode for å studere et system eller en prosess som begynner med oversikt studieobjektet, og involverer deretter dens konsekvente detaljering. Strukturelle metoder har tre hovedtrekk:

Delingen av et komplekst system i deler, presentert som "svarte bokser", implementerer hver "svart boks" en viss funksjon av kontrollsystemet;

Hierarkisk rekkefølge av utvalgte elementer i systemet med definisjon av forhold mellom dem;

Bruke en grafisk representasjon av forholdet mellom systemelementer.

En modell bygget ved hjelp av strukturelle metoder er et hierarkisk sett med diagrammer som grafisk viser funksjonene som utføres av systemet og relasjonene mellom dem.

Som en del av metodikkene for strukturell analyse inkluderer de vanligste følgende:

SADT er en strukturell analyse- og designteknologi, og dens undergruppe er IDEFO-standarden.

DFD - Dataflytdiagrammer.

ERD - entity-relationship diagrams.

STD - tilstandsovergangsdiagrammer.

PÅ IDEFO metodikk fire grunnleggende konsepter brukes: funksjonsblokk, grensesnittbue, dekomponering, ordliste.

IDEFO-modellen begynner alltid med en prosessrepresentasjon av en enkelt funksjonell blokk med grensesnittbuer som strekker seg utover det betraktede området. Noen ganger er slike diagrammer utstyrt med konteksthjelp.

Målet fremhever de aktivitetsområdene til virksomheten som først og fremst bør vurderes. Målet setter retningen og nivået for dekomponering av den utviklede modellen.

PÅ DFD-metodikk prosessen som studeres er delt inn i delprosesser og presentert som et nettverk koblet sammen av datastrømmer. Eksternt ligner DFD på SADT, men er forskjellig i settet med elementer som brukes. Disse inkluderer prosesser, dataflyter og lagring.

ERD-metodikk brukes til å bygge databasemodeller, gir en standardisert måte å beskrive data og definere relasjoner mellom dem. Hovedelementene i metodikken er begrepene "essens", "relasjon" og "relasjon". En enhet definerer grunnleggende informasjonstyper, og relasjoner spesifiserer hvordan disse datatypene samhandler med hverandre. Relasjoner forbinder enheter og relasjoner.

STD-metodikk er mest praktisk for å modellere visse aspekter av systemdriften, på grunn av tid og respons på hendelser, for eksempel for å implementere en brukerforespørsel til AIPS i sanntid. De grunnleggende elementene i STD er begrepene "tilstand", "initial state", "overgang", "tilstand" og "handling". Ved hjelp av konsepter gjennomføres en beskrivelse av hvordan systemet fungerer i tid og avhengig av hendelser. STD-modellen er en grafisk representasjon - et diagram over systemets overganger fra en tilstand til en annen.

Objektorienterte metoder for å konstruere styresystemmodeller. Disse metodene skiller seg fra strukturelle metoder ved et høyere abstraksjonsnivå. De er basert på representasjonen av systemet som et sett med objekter som samhandler med hverandre ved å utveksle data. Spesifikke objekter eller abstrakte enheter - en ordre, en klient, etc. kan tjene som objekter for fagområdet. Den mest betydningsfulle metoden er G. Buch. Dette er en objektdesignteknikk med elementer av objektanalyse, som har fire stadier:

1) utvikling av et maskinvarediagram som viser prosesser, enheter, nettverk og deres tilkoblinger;

2) definisjon av en klassestruktur som beskriver forholdet mellom klasser og objekter;

3) utvikling av diagrammer over objekter som viser forholdet til et objekt med andre objekter;

4) utvikling av programvarearkitektur som beskriver den fysiske utformingen av systemet som lages.

De aller fleste eksisterende metoder objektorientert analyse og design inkluderer både et modelleringsspråk og verktøy for å beskrive modelleringsprosesser.

Den objektorienterte tilnærmingen er ikke i motsetning til den strukturelle tilnærmingen, men kan tjene som dens komplement.

5. Bygging og implementering av AIS

Etter at designarbeidet er fullført, begynner stadiet med å bygge AIS. Bygge AIS er et sett med organisatoriske og tekniske tiltak for gjennomføringen av AIS-prosjektet. Blant slike tiltak er økonomiske, informasjonsmessige, tekniske, programmatiske, juridiske, organisatoriske tiltak:

Identifisering av finansieringskilder og tildeling av midler til innkjøp nødvendig utstyr levert av prosjektet - "Spesifikasjonsark for AIS-utstyr";

Valg av leverandører og inngåelse av kontrakter for levering av utstyr;

Tildeling av lokaler for utplassering av AIS og forberedelse for installasjon av utstyr;

Plassering, montering, installasjon, konfigurasjon av AIS-utstyr i henhold til prosjektet;

Utvelgelse, organisering og opplæring av kategorier av vanlig AIS-personell for å utføre relevant arbeid for å sikre at AIS fungerer;

Utførelse av arbeid med kvalitetskontroll av utstyr (kontroll, testing). Hvis det oppdages mangler - registrering og presentasjon av reklamasjoner til leverandører;

Programvareinstallasjon og utførelse av arbeid med testing av AIS-programvarepakken. Med forbehold om påvisning av defekter - ta tiltak for å eliminere dem;

Fylle databasen, løse testcases for hele spekteret av AIS-oppgaver i henhold til prosjektet. Hvis det oppdages mangler, iverksettes tiltak for å eliminere dem. Hvis ingen mangler blir funnet - utarbeidelse av dokumenter for å sette AIS-en i prøvedrift.

Sammensetningen av tiltak og deres rekkefølge gjenspeiler hovedkontrollpunktene i konstruksjonen av AIS. Konstruksjonen av hvert spesifikke system vil ha sine egne spesifikasjoner både når det gjelder arten av oppgavene og deres rekkefølge. Funksjonene til konstruksjonen bestemmes av AIS-ens art, organisasjonsnivået til AIS-applikasjonen, driftsmåten, finansieringsbeløpet osv.

En av de viktige betingelsene for effektiviteten til AIS er implementeringen av et kompleks av arbeider for implementeringen. Innføringen av AIS begynner med det faktum at lederen av kundefirmaet utsteder en ordre for implementering av systemet som indikerer hovedstadiene, tidspunktet for implementeringen av dem, ansvarlige utførere, ressursstøtte, skjemaet for å presentere resultatene av implementeringen, den som er ansvarlig for å overvåke utførelsen av ordren etc. Ordren kan inneholde en gjennomføringsplan med angivelse av arbeidet i følgende ledd:

1) dokumentere resultater av igangkjøring av utstyr, samt kontrolltester av et sett med systemoppgaver;

2) opplæring av personell i AIS-teknologi og studie av relevante deler av prosjektdokumentasjonen;

3) gjennomføring av prøvedrift av systemet, analyse og korrigering av designfeil og utførelse av dokumentasjon basert på resultatene av prøvedrift;

4) sette AIS i produksjonsdrift med utførelse av relevant dokumentasjon.

På det første trinnet utvikles et program for kontrolltester av AIS som helhet. På andre trinn organiserer utvikleren og kunden opplæring for personell involvert i driften av AIS. På det tredje trinnet utføres pilotdriften av systemet. Avhengig av innholdet og omfanget av AIS-oppgaver, varer prøvedrift fra tre til seks måneder.

Innføringen av AIS er en ganske vanskelig oppgave både organisatorisk og teknisk. Kunden skal forberede implementeringen av systemet. Denne tilstanden krever en viss organisatorisk, faglig og psykologisk innsats fra personellet i kundeselskapet, til en viss grad involvert i driften av AIS. Administrasjonen av selskapet må gi slike forhold som gjør at teamet i selskapet vil ha en positiv holdning til implementeringen av systemet og hjelpe dets implementering, utvikling og utvikling. Da vil man kunne anta at målet om å innføre og drifte AIS ved virksomheten nås.

6. Metodikk for beregning av teknisk og økonomisk effektivitet ved automatisert informasjonsbehandling

En av hoveddelene av AIS-prosjektet er mulighetsstudien av AIS generelt og prosessene for automatisert behandling av økonomisk informasjon spesielt. Dette krever hensiktsmessige beregninger av teknisk og økonomisk effektivitet.

Den økonomiske effektiviteten til automatisert databehandling sikres av følgende hovedfaktorer:

høy hastighet utføre operasjoner for innsamling, overføring, behandling og utstedelse av informasjon, hastigheten på tekniske midler;

Maksimal reduksjon av tid for å utføre individuelle operasjoner;

Forbedring av kvaliteten på databehandling og mottatt informasjon.

Den generelle effektiviteten til automatisert problemløsning er direkte avhengig av reduksjonen i databehandlingskostnader og er en direkte økonomisk effektivitet. Oppnå effekten av systemdekkende kvalitetsforbedringsløsninger informasjonstjeneste brukere gir indirekte økonomisk effektivitet.

Direkte økonomiske effektivitetsindikatorer bestemmes ved å sammenligne kostnadene ved databehandling for flere designalternativer. I hovedsak er dette en sammenligning av to alternativer - grunnleggende og designet. Det eksisterende systemet med automatisert eller tradisjonell (manuell) databehandling tas som basisversjon, og resultatet av moderniseringen av det eksisterende systemet eller en nyutviklet AIS tas som designet versjon.

Absolutt indikatorøkonomisk effektivitet av det utviklede AIS-prosjektet - reduksjon av årlige kostnader og lønnskostnader for den teknologiske prosessen med databehandling sammenlignet med den grunnleggende versjonen av TPOD.

Sparing av økonomiske kostnader på grunn av automatisering av databehandling bestemmes basert på beregningen av forskjellen i kostnadene for de grunnleggende og anslåtte databehandlingsalternativene ved å bruke formelen:

C e \u003d C b - C p (1)

hvor C e - mengden kostnadsreduksjon for databehandling;

C b - kostnader for basissaken;

C n - kostnader for det prosjekterte alternativet.

Den relative indikatoren på den økonomiske effektiviteten til AIS-prosjektet er kostnadseffektivitetsforholdet (K e) og kostnadsendringsindeksen (I c).

K e \u003d C e / C b * 100 % (2)

Kostnadseffektivitetsforholdet viser hvilken del av kostnadene som vil bli spart med det prosjekterte AIS-alternativet, eller med hvor mange prosent kostnadene vil reduseres.

Verdien av kostnadsendringsindeksen kan bestemmes av formelen:

I s \u003d C e / C b. (3)

Denne indeksen angir hvor mange ganger kostnaden for databehandling vil bli redusert under gjennomføringen av AIS-prosjektet.

Når du implementerer et AIS-prosjekt, er det nødvendig å ta hensyn til ekstra kapitalkostnader, hvis verdi (K 3) kan bestemmes av formelen:

K 3 \u003d K p - K b (4)

hvor K p og K b - henholdsvis kapitalkostnader utformet og grunnleggende systemer databehandling.

Effektiviteten til kapitalutgifter bestemmes av tilbakebetalingsperioden (T) for ytterligere kapitalutgifter for IS-modernisering:

T \u003d K 3 / C e (5)

E \u003d C e / K 3 \u003d 1 / T. (6)

Sammen med beregningen av kostnadskostnader er det nyttig å få indikatorer på reduksjonen i lønnskostnader for databehandling. Den absolutte indikatoren for lønnskostnadsreduksjon (t) er forskjellen mellom de årlige lønnskostnadene for de grunnleggende og utformede databehandlingsalternativene:

t = T b. – T p (7)

hvor T b. og T p - henholdsvis den årlige arbeidsintensiteten til driften av de grunnleggende og utformede alternativene for databehandling.

Verdien av den relative indikatoren for lønnskostnadsreduksjon kan vises med lønn(K):

K t \u003d t / T b. (åtte)

Indeksen for endring i lønnskostnader (I t) karakteriserer veksten i arbeidsproduktivitet på grunn av utviklingen av en mer arbeidsbesparende versjon av databehandlingsprosjektet, den kan bestemmes av formelen:

I t \u003d T b / T s. (9)

Den absolutte lønnskostnadsreduksjonen (P) brukes til å bestemme den potensielle utgivelsen arbeidsressurser(utøvere) fra databehandlingssystemet:

P \u003d (t / T f) * f (10)

der Tf er det årlige tidsforbruket til én utøver ansatt i databehandlingsteknologi;

f er en koeffisient som gjenspeiler muligheten for en fullstendig frigjøring av arbeidere, på bekostning av tidsfondet som verdien av t ble beregnet av.

Definisjonen av direkte besparelser fra implementeringen av det prosjekterte (moderniserte) databehandlingssystemet utføres på grunnlag av en sammenligning av indikatorer som gjenspeiler arbeids- og kostnadskostnader for driften av både det tradisjonelle og det prosjekterte databehandlingssystemet.

Spare arbeidskostnader (E tz) i automatisert behandling av informasjon om prosjektet kan bestemmes av formelen

E tz \u003d T o6sch - T owls (11)

der T o6sh er kompleksiteten til databehandling på tradisjonell måte med basistilfellet;

T owls - kompleksiteten til automatisert databehandling i designversjonen.

De økonomiske kostnadsbesparelsene ved implementering av et psammenlignet med en manuell base case kan bestemmes på lignende måte.

Innsamlingen av innledende data for substitusjon i formlene ovenfor og utførelsen av beregninger for å bestemme den økonomiske effektiviteten utføres ved å registrere og måle relevante parametere i stadiene av den teknologiske prosessen med databehandling. I tillegg kan innledende data for en lang periode innhentes ved å analysere registrerings(teknologiske) logger til AIS-kontrolleren og andre former for registrering.

AIS eksisterer som regel over lang tid, og går suksessivt gjennom flere stadier av kombinert utvikling i utviklingen. Livssyklus(LC) systemer:

1) forprosjektundersøkelse (eller analyse) av organisasjonen,

2) AIS-design,

3) implementering av AIS,

4) introduksjon av AIS,

5) fungerer (drift, bruk)

6) AIS-eskorte,

7) modernisering av AIS-prosjektet.

Livssyklusen er perioden for opprettelse og bruk av et informasjonssystem, som dekker dets ulike tilstander, fra det øyeblikket behovet for dette informasjonssystemet oppstår og slutter med det øyeblikket det er helt ute av drift.

Det skal bemerkes at AIS er et produkt av informasjonsproduksjon, akkurat som en bil er et produkt av ingeniørproduksjon, pølse - matproduksjon, etc., derfor stadier av livssyklusen til AIS med 1 til 5 ligner stadiene i livssyklusen til et produkt.

AIS livssyklus, som en bil, kan ende som følge av fysisk slitasje, hvis i livssyklusen støttefasen ikke fungert, det vil si reparasjon og vedlikehold, for eksempel, av datamaskiner og programmer som er en del av AIS (uten støtte vil systemet ikke fungere selv på seks måneder). Med kvalifisert eskorte kan AIS eksistere lenge, men det er en trussel avslutning av AIS-livssyklusen på grunn av foreldelse, AIS foreldelse, hvis det ikke er noen oppgraderingsfase AIS (uten modernisering vil systemet ikke fungere i mer enn 2 år).

Fysisk avskrivning av AIS er manglende evne til å oppfylle organisasjonens krav til AIS på grunn av sammenbrudd, feil eller feil på systemkomponenter.

Foreldelse av AIS er avslutningen av å oppfylle kravene til organisasjonen og dens ansatte for AIS, som et resultat av bruk av utdaterte automatiserte informasjonsteknologier og mangel på støtte for nye brukerkrav.

Hvis organisasjonen din nærmet seg automatisering på en ansvarlig og omfattende måte, organiserte alle stadier og stadier deretter, AIS livssyklus begrenser kun levetiden til organisasjonen din, som betyr at midlene brukt på AIS-en ikke vil bli kastet i søpla sammen med den fysisk eller moralsk foreldede AIS-en.

Alle stadier av AIS-livssyklusen ble listet opp ovenfor, men noen av dem går parallelt, så de tildeler kun 5 stadier i AIS livssyklus(fig.35):

På det første stadiet " Forprosjektundersøkelse» (Fig. 33) er det vanlig å skille mellom to hovedundertrinn og ett ekstra undertrinn:

1.1. gjennomføre en forprosjektundersøkelse og samle inn undersøkelsesmateriell;

1.2. analyse av undersøkelsesmateriell og utvikling basert på analysen av en mulighetsstudie (FS) og oppdrag (TOR);

1.3. valg og utvikling av en variant av systemkonseptet.

Målene for forprosjektundersøkelsen er som følger:

· å formulere behovene for en ny AIS, dvs. identifisere alle mangler ved den eksisterende IS;

· velge retning og bestemme den økonomiske gjennomførbarheten av å designe AIS.

Kartleggingsarbeidet starter med analyse av primærkrav og arbeidsplanlegging, som tar fra 2 dager til 4 uker. Deretter utføres selve undersøkelsen av bedriften (undersøkelsens varighet er 1-2 uker.)

Først lages en beskrivelse og den aktuelle virksomhetens eller organisasjonens virkemåte analyseres i henhold til kravene (målene) som gjelder for den. De organisatoriske og topologiske strukturene til bedriften bestemmes. De funksjonelle aktivitetene til hver av virksomhetens avdelinger og de funksjonelle interaksjonene mellom dem, informasjonsflyter innenfor divisjonene og mellom dem, objekter utenfor virksomheten og eksterne informasjonsinteraksjoner identifiseres. En liste over måloppgaver (funksjoner) til bedriften bestemmes og en analyse av funksjonsfordelingen etter avdelinger og ansatte utføres.

Listen over automatiseringsmidler som brukes ved virksomheten fastsettes.

Videre behandles resultatene av undersøkelsen og følgende to typer virksomhetsaktivitetsmodeller bygges (merk at konstruksjonen av hver av de nødvendige modellene krever intensivt arbeid av 6-7 kvalifiserte systemanalytikere innen 2-4 måneder).

1. Under bygging "som den er"-modellen som er et "øyeblikksbilde" av tingenes tilstand i bedriften (organisasjonsstruktur, interaksjoner mellom avdelinger, vedtatte teknologier, automatiserte og ikke-automatiserte forretningsprosesser, etc.) på tidspunktet for undersøkelsen og lar deg forstå hva den gjør og hvordan den fungerer denne bedriften fra et synspunkt av systemanalyse, så vel som på grunnlag av automatisk verifisering, identifisere en rekke feil og flaskehalser og formulere en rekke forslag for å bedre situasjonen.

2. Dannet "Som det skal"-modellen integrere lovende forslag fra ledelsen og ansatte i bedriften, eksperter og systemanalytikere og tillate å danne en visjon om nye rasjonelle teknologier for driften av bedriften. Hun representerer konseptet for fremtidens AIS.

Opprettelsen av konseptet for det fremtidige systemet inkluderer følgende arbeider:

Detaljert studie av automatiseringsobjektet;

Nødvendig forskningsarbeid (FoU) knyttet til å finne måter og vurdere muligheten for å implementere brukerkrav;

Utvikling av alternative alternativer for konseptet med den opprettede AIS og planer for implementering av dem;

Vurdering av de nødvendige ressursene for implementering og sikring av at de fungerer;

Evaluering av fordeler og ulemper ved hvert alternativ;

Sammenligning av brukerkrav og egenskaper ved det foreslåtte systemet og valg det beste alternativet;

Fastsettelse av prosedyren for å vurdere kvaliteten og betingelsene for aksept av systemet;

Evaluering av effektene mottatt fra systemet;

Utarbeidelse av en rapport som inneholder en beskrivelse av utført arbeid;

Beskrivelse og begrunnelse av den foreslåtte versjonen av systemkonseptet.

Basert på det konstruerte konseptet av systemet og resultatene av undersøkelsen av virksomheten når det gjelder å identifisere krav til det fremtidige systemet, dannes et systemprosjekt (kravmodell), som er første fase av utviklingen av selve automasjonssystemet (nemlig fasen av analysen av krav til systemet), hvor kundens krav spesifiseres, formaliseres og dokumenteres.

Faktisk, på dette stadiet, gis et svar på spørsmålet: "Hva skal det fremtidige systemet gjøre?". Det er her nøkkelen til suksessen til hele automatiseringsprosjektet ligger. I praksisen med å lage store programvaresystemer er det mange eksempler på mislykket implementering nettopp på grunn av ufullstendighet og uklar definisjon av systemkrav.

På dette stadiet bestemmes følgende:

§ arkitekturen til systemet, dets funksjoner, ytre forhold for dets funksjon, fordeling av funksjoner mellom maskinvare- og programvaredelene;

§ grensesnitt og fordeling av funksjoner mellom en person og et system;

§ krav til programvare og informasjonskomponenter i systemet, nødvendige maskinvareressurser, databasekrav, fysiske egenskaper til systemkomponentene, deres grensesnitt;

§ sammensetningen av personer og jobber knyttet til systemet;

§ begrensninger i utviklingsprosessen (direktivfrister for gjennomføring av enkelttrinn, tilgjengelige ressurser);

§ organisatoriske prosedyrer som sikrer beskyttelse av informasjon.

Som en del av systemdesign utføres følgende:

Bestemmelse av sammensetningen, strukturen og egenskapene til funksjonelle oppgaver innenfor rammen av aktivitetene til strukturelle divisjoner;

Bestemmelse av sammensetning og struktur av automatiseringsprogramvare for problemløsningsteknologi, tatt i betraktning eksisterende verktøy i strukturelle inndelinger;

Bestemmelse av strukturen og egenskapene til informasjonsstøtteteknologi for å løse problemer;

Utvikling av tekniske løsninger for konstruksjon av informasjonsstøtte (logiske databasestrukturer, klassifiseringsstrukturer);

§ utvikling av sammensetningen av automatiserte arbeidsflytprosedyrer.

Systemprosjekt bør inkludere:

en komplett funksjonell modell av krav til det fremtidige systemet;

Kommentarer til funksjonsmodellen (prosessspesifikasjoner på lavere nivå i tekstform);

en pakke med rapporter og dokumenter om en funksjonell modell, inkludert beskrivelse av modelleringsobjektet, liste over delsystemer, krav til metoder og kommunikasjonsmidler for informasjonsutveksling mellom komponenter, krav til egenskapene til systemets sammenkoblinger med tilstøtende systemer, krav for systemfunksjoner;

· konseptuell modell av den integrerte databasen (pakke med diagrammer);

systemarkitektur med referanse til den konseptuelle modellen;

· forslag til organisasjonsstruktur for å støtte systemet.

Systemprosjektet inneholder således funksjonelle, informasjonsmessige og eventuelt hendelsesmodeller av krav til det fremtidige systemet. Typene og rekkefølgen av arbeid i konstruksjonen av disse kravmodellene er lik det tilsvarende arbeidet med konstruksjonen av aktivitetsmodeller. I tillegg inkluderer systemprosjektet mandat for oppretting av et automatisert system.

Det er nødvendig å merke seg følgende fordel med systemprosjektet. Tradisjonell utvikling er preget av implementering av de innledende stadiene på håndverksmessige ikke-formaliserte måter. Som et resultat kan kunder og brukere se systemet for første gang etter at det i stor grad allerede er implementert. Naturligvis er dette systemet annerledes enn det de forventet å se. Derfor følger flere flere iterasjoner av utviklingen eller modifikasjonen, noe som krever ekstra (og betydelige) kostnader med penger og tid. Nøkkelen til å løse dette problemet er systemprosjektet, som tillater:

Beskriv, "se" og korriger det fremtidige systemet før det implementeres fysisk;

Reduser kostnadene ved å utvikle og implementere systemet;

Evaluere utviklingen med tanke på tid og resultater;

Oppnå gjensidig forståelse mellom alle deltakere i arbeidet (kunder, brukere, utviklere, programmerere, etc.);

For å forbedre kvaliteten på det utviklede systemet, nemlig: å lage en optimal struktur for en integrert database, for å utføre en funksjonell dekomponering av typiske moduler.

Et systemprosjekt er helt uavhengig og kan skilles fra spesifikke utviklere, krever ikke vedlikehold av skaperne, og kan smertefritt overføres til andre personer. Dessuten, hvis bedriften av en eller annen grunn ikke er klar til å implementere systemet basert på prosjektet, kan det legges "på hylla" til behovet oppstår. I tillegg kan den brukes til uavhengig utvikling eller korrigering av programvareverktøy som allerede er implementert på grunnlag av programmererne in.

Formålet med utviklingen av «Feasibility Study» av AIS-prosjektet er å vurdere hovedparametrene som begrenser prosjektet, begrunne valget og vurdere hoveddesignbeslutningene for enkeltkomponenter i prosjektet. Samtidig er det organisatoriske parametere som karakteriserer måtene å organisere prosessene for informasjonstransformasjon i systemet på, informasjonsmessige og økonomiske parametere som karakteriserer kostnadene ved å opprette og drifte systemet, og sparer fra driften. Hovedobjektene for parametrisering i systemet er oppgaver, oppgavekomplekser, økonomiske indikatorer,. Etter at det er fattet vedtak om å utføre videre arbeid, iverksettes en rekke organisatoriske tiltak, for eksempel må det gis passende pålegg om arbeid; Ansvarlig for områder bør utpekes mv.

Uten slik støtte fra ledelsen i virksomheten er det meningsløst å starte et prosjekt i det hele tatt.

Figur 33. Arbeidssekvensen på pre-designstadiet av AIS-livssyklusen.

Deretter opprettes et referansevilkår (TOR) for prosjektet, som reflekterer spesifikasjoner og krav til fremtidens AIS, samt restriksjoner på designressurser. Hvis prosjektet krever vitenskapelig studie av komponentene, er konseptet for fremtidens AIS utviklet basert på TOR.

Som en del av dannelsen av TOR utvikles forslag til automatisering basert på de identifiserte og avtalte kravene, som inkluderer:

utarbeide en liste over automatiserte arbeidsplasser i bedriften og måter for samhandling mellom dem;

Anvendbarhetsanalyse eksisterende systemer bedriftsledelse (primært MRP- og ERP-klasser) for å løse de nødvendige oppgavene og dannelsen av anbefalinger for å velge et slikt system;

Felles beslutningstaking med oppdragsgiver velge et spesifikt virksomhetsstyringssystem eller utvikle ditt eget systemer.

Utvikling av forslag til tekniske midler;

Utvikling av programvareforslag;

Utvikling av topologi, sammensetning og struktur i lokalnettverket;

Utvikling av forslag til stadier og vilkår for automatisering.

Hvis det ble besluttet å velge et spesifikt kontrollsystem, hoppes noen trinn over.

Andre fase" Design» (Fig. 34) utfører følgende undertrinn:

1) foreløpig design: avklaring av kravene til TOR, utførelse og godkjenning av foreløpig design;

2) teknisk design: utvalg av designløsninger for alle aspekter av AIS-utvikling, beskrivelse av alle AIS-komponenter, utførelse og godkjenning av et teknisk prosjekt;

3) detaljert design: valg og utvikling av matematiske metoder og algoritmer av programmer, justering av strukturen til databaser (DB), opprettelse av dokumentasjon for levering og utvikling av programvareprodukter, valg av et sett med AIS-maskinvare, opprettelse av dokumentasjon for levering og installasjon av maskinvare, utvikling av et arbeidsutkast til AIS .

Målene for denne fasen er:

· utvikle en funksjonell arkitektur av AIS, som gjenspeiler strukturen og sammensetningen av funksjonelle delsystemer, for automatisert støtte for visse ledelsesfunksjoner i organisasjonen;

· å utvikle systemarkitekturen til den valgte AIS-varianten, det vil si sammensetningen av de støttende delsystemene.

For komplekse store AIS, automatisering stor bedrift, holding, kropper statsmakt osv., i undertrinn 1 " Foreløpige design» foreløpige løsninger er formulert for fremtidens AIS som helhet og dets komponenter, som et resultat av at et utkast til design (DS) blir laget. Utvikling av foreløpige designløsninger for systemet og dets deler inkluderer:

Definisjon av AIS-funksjon;

Definisjon av funksjonen til delsystemer, deres mål og effekter;

Bestemmelse av sammensetningen av oppgavekomplekser og individuelle oppgaver;

Definisjon av konseptet for informasjonsbasen, dens utvidede struktur;

Definisjon av;

Bestemmelse av sammensetningen av datasystemet;

Definisjon av funksjonen og parameterne til de viktigste programvareverktøyene.

Utvikling av dokumentasjon for denne delen av prosjektet.

Hvis prosjektet som utvikles ikke er veldig komplekst, anta at en liten bedrift blir automatisert, hoppes arbeidstrinnet over.

På undertrinn 2. Teknisk design » Det arbeides med logisk utvikling og valg av de beste alternativene for designløsninger, som et resultat av at et teknisk prosjekt (TP) opprettes. Som en del av opprettelsen av et teknisk prosjekt utføres følgende:

- transformasjon av et systemprosjekt til et teknisk prosjekt(implementeringsmodell), som inkluderer følgende handlinger: foredling av den logiske modellen (utvikling av detaljert logikk for hver prosess ved bruk av dataflytdiagrammer og prosessspesifikasjoner), design av en fysisk database, konstruksjon av et hierarki av modulfunksjoner som skal programmeres, estimering av gjennomføringskostnader.

Det opplistede arbeidet bør utføres av konsulentanalytikere sammen med systemdesignere – det er her grensen går mellom rådgivning og utvikling. Ikke desto mindre er det ønskelig at konsulenten på stadium av systemimplementering også handler i kundens interesser, nemlig: han kontrollerer samsvaret til det opprettede programvaresystemet med systemet og tekniske prosjekter, og deltar også i arbeidet med utvidelsen av det. og modifikasjon, fordi utvidelser bør planlegges ut fra kravmodellen.

- teknisk designarbeid:

Utvikling av generelle løsninger for systemet og dets deler,

Utvikling av generelle løsninger for den funksjonelle-algoritmiske strukturen til systemet,

Utvikling av felles beslutninger om personalfunksjoner og organisasjonsstruktur,

Utvikling av felles løsninger for strukturen av tekniske midler,

Utvikling av generelle løsninger for problemløsningsalgoritmer og språk som brukes,

Utvikling av felles løsninger for organisering og vedlikehold av en informasjonsbase,

Utvikling av felles løsninger for systemet for klassifisering og koding av informasjon,

Utvikling av felles programvareløsninger;

Gjennomføre utvikling, utførelse av dokumentasjon for alle deler av prosjektet, inkludert dokumentet "Formulering av problemet",

Utvikling og utførelse av dokumentasjon for levering av produkter for anskaffelse av AIS og/eller tekniske krav (tekniske spesifikasjoner) for deres utvikling;

Utvikling av designoppgaver i tilstøtende deler av prosjektet av automasjonsobjektet.

Undertrinn 3." Fungerende design » knyttet til den fysiske gjennomføringen av det valgte prosjektalternativet og mottak av den detaljerte designdokumentasjonen (DP).

Denne delfasen utføres:

Utvikling og utførelse av arbeidsdokumentasjon som inneholder all nødvendig og tilstrekkelig informasjon for å sikre gjennomføringen av arbeidet med idriftsettelse av AIS og driften, samt opprettholde nivået av operasjonelle egenskaper (kvalitet) til systemet i samsvar med vedtatte. designbeslutninger og koordinering og godkjenning av denne dokumentasjonen;

Utvikling av programmer og programvareverktøy for systemet, samt valg, tilpasning og/eller binding av kjøpte programvareverktøy,

Utvikling av programvaredokumentasjon.

Organisering av anbud for levering av AIS-komponenter (programvare og maskinvare, programvare- og maskinvaresystemer, informasjonsprodukter).

Figur 34. Arbeidssekvensen på designstadiet av AIS-livssyklusen.

I nærvær av designerfaring og en liten kompleksitet av prosjektet, kombineres alle tre deltrinn til ett, som et resultat av at et enkelt teknoarbeidsprosjekt (TDP) oppnås. I dette tilfellet blir prosjektet konsekvent, ettersom deltrinnene er fullført, transformert fra et utkast til et detaljert design.

Den tredje fasen Gjennomføring» (Fig. 35) er den fysiske utformingen av systemet i følgende rekkefølge:

1) mottak og installasjon av tekniske midler;

2) koding, testing og utvikling av programmer;

3) skaffe og installere programvare;

4) opprettelse av informasjonsstøtte, inkludert fylling av databaser;

5) utvikling av instruksjoner for drift av programvare og maskinvare, samt stillingsbeskrivelser for ansatte.

Disse arbeidene kan praktisk talt utføres parallelt.

På den fjerde fasen av AIS-livssyklusen " Gjennomføring» det er følgende undertrinn:

1) pilotimplementering:

igangkjøring av teknisk utstyr,

igangkjøring av programvareverktøy, gjennomføring av prøvedrift av alle komponenter og systemer som helhet,

· opplæring og sertifisering av personell.

Pilotimplementering består i å kontrollere funksjonaliteten til elementer og moduler i prosjektet, eliminere feil på elementnivå og koblinger mellom dem.

På dette stadiet arbeides det med den organisatoriske forberedelsen av automatiseringsobjektet for idriftsettelse av AIS, inkludert:

Implementering av designbeslutninger om organisasjonsstrukturen til AIS;

å gi enheter av kontrollobjektet instruktive og metodiske materialer;

Innføring av informasjonsklassifiserere;

Opplæring,

Kontrollerer dens evne til å sikre at AIS fungerer.

På samme trinn kompletteres AIS med leverte produkter (programvare og maskinvare, programvare og maskinvaresystemer, informasjonsprodukter), samt konstruksjon og installasjon, igangkjøring, fortester:

Utfør tester av AIS for ytelse og overholdelse av referansevilkårene i samsvar med programmet og metodikken for foreløpige tester forberedt på forhånd;

Feilsøking og forbedring (om nødvendig) av programvaren, foreta endringer i AIS-dokumentasjonen, inkludert driftsdokumentasjon i henhold til testprotokollen.

Pilotimplementeringsarbeidet avsluttes utarbeide en lov om ferdigstillelse av prøvedrift.

2) industriell implementering (sette i kommersiell drift):

igangkjøring,

Signering av handlinger om aksept og levering av verk.

Igangkjøring består i å organisere en prosjektverifisering på funksjonsnivå og overvåke overholdelse av kravene formulert på forhåndsprosjektundersøkelsesstadiet, dvs.:

Gjennomfør en test for overholdelse av referansevilkårene i samsvar med programmet og metodikken som er utarbeidet på forhånd akseptprøver;

Analyse av AIS-testresultatene og eliminering av mangler identifisert under testene.

Ferdig med arbeidet utarbeide en lov om godkjenning av AIS for permanent drift.

På den siste femte fasen av AIS-livssyklusen, drift, vedlikehold og modernisering programvare, maskinvare og hele prosjektet.

AIS eskorte ligger i utførelse av arbeid iht garantiforpliktelser, gjennomføring av arbeid for å eliminere manglene identifisert under driften av AIS innenfor det etablerte garantiperioder og i gjennomføringen av arbeidet med innføringen nødvendige endringer i AIS-dokumentasjonen.

Service etter garantien består av:

I gjennomføringen av arbeidet med analyse av funksjonen til systemet;

Ved å identifisere avvik av de faktiske operasjonelle egenskapene til AIS fra designverdiene;

Ved å fastslå årsakene til disse avvikene;

Ved å eliminere de identifiserte manglene og sikre stabiliteten til de operasjonelle egenskapene til AIS;

Ved å gjøre nødvendige endringer i dokumentasjonen for AIS.

Avhengig av spesifikasjonene til den opprettede AISen og betingelsene for deres opprettelse, er det tillatt å utføre individuelle stadier av arbeidet før fullføringen av de forrige stadiene, parallell utførelse av arbeidsstadier i tid, inkludering av nye stadier av arbeidet.

Figur 35. AIS livssyklusstadier.

Livssyklusen er vanligvis iterativ av natur: de implementerte stadiene av livssyklusen, med start fra de tidligste, gjentas syklisk i samsvar med nye krav og endringer i ytre forhold. På hvert stadium av livssyklusen dannes et sett med dokumenter og tekniske løsninger, som er utgangspunktet for påfølgende beslutninger.

Den mest utbredte tre livssyklusmodeller:

kaskademodell (til 70-tallet) - en sekvensiell overgang til neste trinn etter fullføringen av den forrige;

· iterativ modell (70-80-tallet) - med iterativ tilbakevending til de forrige stadiene etter fullføring av neste etappe;

· spiralmodell (80-90-tallet) - en prototypemodell, som forutsetter en gradvis utvidelse av AIS-prototypen.

Til kaskade livssyklusmodell automatisering av separate urelaterte oppgaver er typisk, som ikke krever informasjonsintegrasjon og kompatibilitet, programvare, teknisk og organisatorisk grensesnitt. Som en del av å løse individuelle problemer rettferdiggjorde kaskademodellen seg med tanke på utviklingstid og pålitelighet. Anvendelsen av denne livssyklusmodellen på store og komplekse prosjekter, på grunn av designprosessens lange varighet og variasjonen av krav i løpet av denne tiden, fører til at de praktisk talt ikke kan realiseres.

Iterativ livssyklusmodell. Opprettelsen av kompleks AIS innebærer kobling av designløsninger oppnådd ved implementering av individuelle oppgaver. «bottom-up»-designtilnærmingen nødvendiggjør slike iterative avkastninger, når designløsninger for enkeltoppgaver kompletteres til generelle systemløsninger, og samtidig er det behov for å revidere tidligere formulerte krav. Som regel, på grunn av et stort antall iterasjoner, oppstår avvik i de fullførte designbeslutningene og dokumentasjonen. Intrikaten til funksjons- og systemarkitekturen til den opprettede AIS-en, vanskeligheten med å bruke designdokumentasjon, forårsaker umiddelbart behovet for å redesigne hele systemet på stadiene av implementering og drift. Den lange livssyklusen for å utvikle et informasjonssystem ender med implementeringsfasen, etterfulgt av livssyklusen for å lage en ny AIS.

Spiral livssyklusmodell. En top-down tilnærming for å organisere design av AIS brukes når sammensetningen av funksjonelle delsystemer først bestemmes, og deretter innstillingen av individuelle oppgaver. Følgelig utvikles først slike systemomfattende problemer som organisering av en integrert database, teknologien for innsamling, overføring og akkumulering av informasjon, og deretter teknologien for å løse spesifikke problemer. Innenfor rammen av oppgavekomplekser utføres programmering i retning fra hovedprogrammodulene til modulene som utfører individuelle funksjoner. Samtidig kommer spørsmålene om interaksjon mellom grensesnittene til programmoduler med hverandre og med databasen i forgrunnen, og implementeringen av algoritmer kommer i bakgrunnen.

Hver omdreining av spiralen tilsvarer en trinn-for-trinn-modell for å lage et AIS-fragment. Den klargjør målene og egenskapene til prosjektet, bestemmer kvaliteten og planlegger arbeidet med neste sving i spiralen. Det er en konsekvent utdyping og konkretisering av detaljene i prosjektet, dens underbyggede versjon dannes, som bringes til implementering.

Spiralmodellen av livssyklusen er basert på bruk av prototypeteknologi eller RAD-teknologi (rask applikasjonsutvikling).

I henhold til denne teknologien er AIS utviklet ved å utvide programvareprototyper, følge veien fra spesifikasjon av krav til spesifikasjon av programkode.

Naturligvis, med prototypeteknologi, reduseres antall iterasjoner og det er færre feil og inkonsekvenser som må korrigeres ved påfølgende iterasjoner, og selve designen utføres i et raskere tempo, og opprettelsen av prosjektdokumentasjon er forenklet. For mer nøyaktig å matche designdokumentasjonen utviklet av AIS, alle større verdi er gitt til vedlikehold av et systemomfattende depot og designautomatisering, spesielt bruken av CASE-teknologier (Computers Aids System Engineering).

Når du bruker spiralmodellen:

· det er en akkumulering og gjenbruk av designløsninger, designverktøy, modeller og prototyper av AIS og informasjonsteknologi;

· Orientering utføres på utvikling og modifikasjon av systemet og teknologiene i prosessen med design;

· det gjennomføres en risiko- og kostnadsanalyse i systemdesignprosessen.

Et grensesnitt er en sammenkobling av deler av programvare og maskinvare, data, en teknologi for kommunikasjon mellom en person og en datamaskin, der all informasjon, logiske, fysiske og elektriske parametere oppfyller etablerte standarder.

Prototype - minimumsversjonen av systemet som brukes til generering eller utvikling fullversjon

Depotet inneholder informasjon om objektene til den designet AIS og relasjonene mellom dem, alle undersystemer utveksler data med det.

Kaskadetilnærmingen har vist seg i å bygge IS-er, som helt i begynnelsen av utviklingen er mulig å formulere alle kravene ganske nøyaktig og fullstendig for å gi utviklere friheten til å implementere dem teknisk best mulig. Denne kategorien omfatter komplekse systemer med et stort antall oppgaver av beregningsmessig karakter, sanntidssystemer osv.

AIS livssyklusmodell- er en struktur som beskriver prosessene, aktivitetene og oppgavene som utføres under utvikling, drift og vedlikehold gjennom hele systemets livssyklus.

Valget av en livssyklusmodell avhenger av spesifikasjonene, skalaen, kompleksiteten til prosjektet og settet med forhold som AISen er opprettet og fungerer under.

AIS livssyklusmodellen inkluderer:

Resultatene av arbeidet på hvert trinn;

Nøkkelhendelser eller punkt for fullføring og beslutningstaking.

I samsvar med de velkjente programvarelivssyklusmodellene, bestemmes AIS livssyklusmodeller - kaskade, iterativ, spiral.

I. Kaskademodell beskriver den klassiske tilnærmingen til utvikling av systemer innen alle fagområder; ble mye brukt på 1970- og 80-tallet.

Kaskademodellen sørger for en sekvensiell organisering av arbeidet, og hovedtrekket i modellen er inndelingen av alt arbeid i stadier. Overgangen fra forrige trinn til neste skjer først etter at alt arbeidet til den forrige er fullført.

Tildele fem stabile utviklingstrinn, praktisk talt uavhengig av fagområdet

På først På scenen studeres problemområdet, kundens krav formuleres. Resultatet av dette stadiet er mandatet (utviklingsoppgave), avtalt med alle interesserte parter.

Under sekund trinn, i henhold til kravene i referansevilkårene, utvikles visse designløsninger. Resultatet er et sett med prosjektdokumentasjon.

Den tredje stadium - prosjektgjennomføring; i hovedsak programvareutvikling (koding) i samsvar med designbeslutningene fra forrige trinn. Implementeringsmetoder er ikke av grunnleggende betydning. Resultatet av etappen er et ferdig programvareprodukt.

På fjerde På stadiet blir den mottatte programvaren kontrollert for samsvar med kravene angitt i referansevilkårene. Prøvedrift gjør det mulig å avsløre ulike typer skjulte mangler som manifesterer seg under reelle forhold ved AIS-drift.

Den siste fasen er leveringen av det ferdige prosjektet, og det viktigste her er å overbevise kunden om at alle kravene hans er fullt oppfylt.

Fig. 1.1 AIS LC kaskademodell

Arbeidsstadiene innenfor fossefallsmodellen omtales ofte som deler av AIS-prosjektsyklusen, siden stadiene består av mange iterative prosedyrer for å avgrense systemkrav og designalternativer. Livssyklusen til AIS er mye mer komplisert og lengre: den kan inkludere et vilkårlig antall sykluser med foredling, endringer og tillegg til allerede vedtatte og implementerte designbeslutninger. I disse syklusene foregår utviklingen av AIS og moderniseringen av dens individuelle komponenter.

Fordeler med fossefallsmodellen:

1) på hvert trinn dannes et komplett sett med designdokumentasjon som oppfyller kriteriene for fullstendighet og konsistens. I sluttfasen utvikles brukerdokumentasjon som dekker alle typer AIS-støtte gitt av standardene (organisatorisk, informasjonsmessig, programvare, teknisk, etc.);

2) sekvensiell utførelse av arbeidsstadiene lar deg planlegge tidspunktet for ferdigstillelse og de tilsvarende kostnadene.

Kaskademodellen ble opprinnelig utviklet for å løse ulike typer tekniske problemer og har ikke mistet sin betydning for det anvendte området til dags dato. I tillegg er fossefallstilnærmingen ideell for utvikling av AIS, da det allerede i begynnelsen av utviklingen er mulig å formulere alle kravene ganske nøyaktig for å gi utviklere friheten til teknisk implementering. Slike AIS inkluderer spesielt komplekse oppgjørssystemer og sanntidssystemer.

Ulemper med fossefallsmodellen:

Betydelig forsinkelse i å oppnå resultater;

Feil og mangler på noen av stadiene vises som regel på etterfølgende stadier av arbeidet, noe som fører til behovet for retur;

Kompleksiteten i parallelt arbeid med prosjektet;

Overdreven informasjonsoverbelastning av hvert av trinnene;

Kompleksiteten til prosjektledelse;

Høyt risikonivå og upålitelighet av investeringer.

Forsinkelse med å få resultater Det manifesteres i det faktum at i en konsistent tilnærming til utvikling, blir resultatene avtalt med interessenter først etter fullføring av neste trinn i arbeidet. Som et resultat kan det vise seg at den utviklede AIS-en ikke oppfyller kravene, og slike inkonsekvenser kan oppstå på ethvert utviklingsstadium; i tillegg kan feil utilsiktet introduseres av både analytikere og programmerere, siden det ikke kreves at de er godt kjent med fagområdene AIS utvikles for.

Gå tilbake til tidligere stadier. Denne ulempen er en manifestasjon av den forrige: det trinnvise sekvensielle arbeidet med prosjektet kan føre til at feil som er gjort på tidligere stadier, bare oppdages i påfølgende stadier. Som et resultat går prosjektet tilbake til forrige fase, blir behandlet og først deretter overført til påfølgende arbeid. Dette kan forårsake en forstyrrelse i tidsplanen og komplisere forholdet mellom utviklingsteam som utfører individuelle stadier.

Det verste alternativet er når feilene i forrige stadium ikke blir funnet på neste stadium, men senere. For eksempel, på prøvedriftsstadiet, kan det oppstå feil i beskrivelsen av fagområdet. Dette betyr at deler av prosjektet må tilbake til startfasen av arbeidet.

Kompleksiteten i parallelt arbeid knyttet til behovet for å harmonisere de ulike delene av prosjektet Jo sterkere relasjonen mellom enkelte deler av prosjektet er, jo oftere og mer nøye må synkronisering utføres, jo mer avhengig av hverandres utviklingsteam. Som et resultat går fordelene ved parallelt arbeid rett og slett tapt; mangelen på parallellitet påvirker organiseringen av arbeidet til hele teamet negativt.

Problem for mye informasjon oppstår fra den sterke avhengigheten mellom ulike grupper av utviklere. Faktum er at når du gjør endringer i en av delene av prosjektet, er det nødvendig å varsle de utviklerne som brukte (kunne bruke) det i arbeidet sitt. Med et stort antall sammenkoblede delsystemer blir synkroniseringen av intern dokumentasjon en egen hovedoppgave: Utviklere må hele tiden sette seg inn i endringer og vurdere hvordan disse endringene vil påvirke de oppnådde resultatene.

Prosjektledelsens kompleksitet hovedsakelig på grunn av den strenge sekvensen av utviklingstrinn og tilstedeværelsen av komplekse forhold mellom ulike deler av prosjektet. Den regulerte arbeidsrekkefølgen fører til at noen utviklingsgrupper må vente på resultatene av arbeidet til andre team, derfor er det nødvendig med administrativ inngripen for å bli enige om tidspunktet og sammensetningen av den overførte dokumentasjonen.

Ved påvisning av feil i arbeidet er det nødvendig med en tilbakevending til de foregående stadiene; det nåværende arbeidet til de som har gjort en feil blir avbrutt. Konsekvensen av dette er vanligvis en forsinkelse i gjennomføringen av både de korrigerte og de nye prosjektene.

Det er mulig å forenkle samspillet mellom utviklere og redusere informasjonsoverbelastningen av dokumentasjon ved å redusere antall koblinger mellom individuelle deler av prosjektet, men ikke alle AIS kan deles inn i løst koblede delsystemer.

Høyt risikonivå. Jo mer komplekst prosjektet er, jo lenger varer hvert utviklingstrinn og jo mer komplekst er forholdet mellom de enkelte delene av prosjektet, og antallet øker også. Dessuten kan resultatene av utviklingen faktisk sees og evalueres bare på teststadiet, det vil si etter fullføringen av analysen, design og utvikling - stadier, hvis implementering krever betydelig tid og penger.

Forsinket evaluering genererer alvorlige problemer hvis analyse- og designfeil blir identifisert, er det nødvendig med en tilbakevending til tidligere stadier og en repetisjon av utviklingsprosessen. En tilbakevending til tidligere stadier kan imidlertid ikke bare være forbundet med feil, men også med endringer som har skjedd i fagområdet eller i kundekrav under utviklingen. Samtidig er det ingen som garanterer at fagområdet ikke endres igjen når neste versjon av prosjektet er klar. Faktisk betyr dette at det er en mulighet for en "syklus" av utviklingsprosessen: kostnadene for prosjektet vil stadig vokse, og fristene for levering av det ferdige produktet vil bli konstant forsinket.

II. Iterativ modell (Etappevis modell med mellomstyring) er en serie med korte sykluser (trinn) av planlegging, implementering, studier, handling.

Opprettelsen av kompleks AIS innebærer koordinering av designløsninger oppnådd under gjennomføringen av individuelle oppgaver. "bottom-up" designtilnærmingen nødvendiggjør slike gjentakelser av returer, når designløsninger for individuelle oppgaver kombineres til felles systemløsninger. I dette tilfellet er det behov for å revidere de tidligere dannede kravene.

Fordel av den iterative modellen er at justeringer mellom trinn gir mindre arbeidsintensitet i utviklingen sammenlignet med kaskademodellen.

ulemper iterativ modell:

· levetiden til hvert trinn er strukket for hele arbeidsperioden;

· på grunn av det store antallet iterasjoner, er det avvik i implementeringen av designbeslutninger og dokumentasjon;

forviklinger av arkitekturen

Vanskeligheter med å bruke prosjektdokumentasjon på stadier av implementering og drift nødvendiggjør redesign av hele systemet.

III. spiralmodell, i motsetning til kaskaden, men lik den forrige, innebærer en iterativ prosess for å utvikle AIS. Samtidig øker betydningen av de innledende stadiene, som analyse og design, som kontrollerer og begrunner gjennomførbarheten av tekniske løsninger ved å lage prototyper.

Hver iterasjon er en komplett utviklingssyklus som fører til utgivelsen av en intern eller ekstern versjon av et produkt (eller en undergruppe av sluttprodukt) som forbedres fra iterasjon til iterasjon til å bli et komplett system (figur 1.2).

Ris. 1.2. Spiralmodell av AIS livssyklus

Dermed tilsvarer hver sving av spiralen opprettelsen av et fragment eller en versjon av et programvareprodukt, den spesifiserer målene og egenskapene til prosjektet, bestemmer kvaliteten og planlegger arbeidet med neste sving av spiralen. Hver iterasjon tjener til å utdype og konsekvent spesifisere detaljene i prosjektet, som et resultat av at et rimelig alternativ for den endelige implementeringen velges.

Ved å bruke spiralmodellen kan du gå til neste fase av prosjektet uten å vente på at den nåværende skal fullføres - det uferdige arbeidet kan gjøres ved neste iterasjon. Hovedoppgaven for hver iterasjon er å lage et brukbart produkt for demonstrasjon for brukere så raskt som mulig. Dermed forenkles prosessen med å innføre presiseringer og tillegg til prosjektet betraktelig.

Spiraltilnærmingen til programvareutvikling overvinner de fleste manglene ved fossefallsmodellen, i tillegg gir den en rekke tilleggsfunksjoner som gjør utviklingsprosessen mer fleksibel.

Fordeler iterativ tilnærming:

Iterativ utvikling forenkler i stor grad innføringen av endringer i prosjektet ved endring av kundekrav;

Når du bruker spiralmodellen, integreres individuelle elementer av AIS gradvis til en enkelt helhet. Siden integrasjonen starter med færre elementer, er det langt færre problemer under implementeringen;

Redusere risikonivået (en konsekvens av den tidligere fordelen, siden risikoer oppdages under integrering). Risikonivået er maksimalt i begynnelsen av prosjektutviklingen, ettersom utviklingen skrider frem, avtar den;

Iterativ utvikling gir større fleksibilitet i prosjektledelsen ved å tillate taktiske endringer i produktet under utvikling. Så det er mulig å redusere utviklingstiden ved å redusere funksjonaliteten til systemet eller bruke produktene til tredjepartsselskaper i stedet for deres egen utvikling som komponenter (relevant i en markedsøkonomi, når det er nødvendig å motstå markedsføring av konkurrenter ' Produkter);

Den iterative tilnærmingen gjør det lettere å gjenbruke komponenter fordi det er mye lettere å identifisere (identifisere) fellesdelene av prosjektet når de allerede er delvis utviklet enn å prøve å isolere dem helt i starten av prosjektet. Analyse av designet etter flere innledende iterasjoner avslører vanlige gjenbrukbare komponenter som vil bli forbedret i påfølgende iterasjoner;

Spiralmodellen lar deg få et mer pålitelig og stabilt system. Dette er fordi etter hvert som systemet utvikler seg, blir feil og svakheter funnet og fikset ved hver iterasjon. Samtidig justeres kritiske ytelsesparametere, som i tilfelle av en fossefallsmodell kun er tilgjengelig før implementeringen av systemet;

En iterativ tilnærming gir mulighet for prosessforbedring
utvikling - som et resultat av analysen på slutten av hver iterasjon, utføres en vurdering av endringer i utviklingsorganisasjonen; det forbedres ved neste iterasjon.

Hovedproblemet med spiralsyklusen- vanskeligheten med å bestemme tidspunktet for overgangen til neste trinn. For å løse det er det nødvendig å innføre tidsbegrensninger for hvert av stadiene i livssyklusen. Ellers kan utviklingsprosessen bli en endeløs forbedring av det som allerede er gjort.

Ved å involvere brukere i prosessen med å designe og kopiere applikasjonen kan du motta kommentarer og tillegg til kravene direkte i prosessen med å designe applikasjonen, noe som reduserer utviklingstiden. Representanter for kunden får muligheten til å kontrollere prosessen med å lage systemet og påvirke dets funksjonelle innhold. Resultatet er en idriftsettelse av et system som tar hensyn til de fleste behovene til kundene.

Livssyklusmodell og designteknologi

Tidligere sa vi at designteknologien setter rekkefølgen av handlinger som er nødvendige for å oppnå et IP-prosjekt. Åpenbart betyr utførelsen av hver av disse handlingene overgangen til informasjonssystemet fra en stat til en annen. Dermed beskriver enhver designteknologi entydig en livssyklusmodell. På den annen side, ved å bygge en livssyklusmodell for informasjonssystem, det vil si ved å definere:

oppgaver, sammensetning og rekkefølge av utført arbeid;

· resultatene av hver utførte handling;

Metoder og midler som er nødvendige for utførelse av arbeid;

deltakernes roller og ansvar;

annen informasjon som er nødvendig for planlegging, organisering og styring av den kollektive utviklingen av IP,

vi vil få en entydig beskrivelse av designteknologien vi har valgt. Dermed er livssyklusmodellen en integrert og viktig del av designteknologien for informasjonssystemer.

Stadier og stadier av design

Begrepene "stadium" og "stadium" av design er ofte forvirret. Noen ganger snakker de om etapper eller faser Livssyklus, trinn design. Spørsmålet oppstår: hva er den riktige måten?

Det bør huskes at terminologien som brukes kan variere i forskjellige internasjonale standarder. Vi vil om mulig fokusere på terminologien til innenlandske GOST-er. Designstadiet vi vil kalle delen av prosessen med å lage en IS, begrenset av en viss tidsramme og slutter med utgivelsen av et spesifikt produkt (modell, dokumentasjon, programtekst, etc.). I henhold til felles mål kan designstadier kombineres til etapper. For eksempel «Teknisk design»-stadiet, «Implementering»-stadiet, etc.

I følge publiserte data krever hvert trinn i AIS-utvikling en viss tid. Mesteparten av tiden (45-50%) brukes på koding, kompleks og frittstående testing. I gjennomsnitt opptar utviklingen av AIS en tredjedel av hele livssyklusen til systemet.

Ris. Fordeling av tid i utviklingen av AIS

AIS-opprettingsstadier (ISO/IEC 15288)

ISO/IEC 12207-standarden definerer et livssyklusrammeverk som inneholder prosessene, aktivitetene og oppgavene som må utføres under opprettelsen av et informasjonssystem.