Ais projektledning. AIS “Projektledning. Grundläggande begrepp för AIS -design

Det finns många metoder och alternativ för att utveckla AIS, vars användning beror på olika faktorer, till exempel företagens storlek och (eller) deras IS, syftet med att skapa en IS, tillgängliga resurser etc. Metoder och principer för utformning en IS diskuteras i föregående kapitel.

Mjukvaruprojektets livscykel är en uppsättning stadier och stadier av mjukvaruutveckling, från systemanalys och utveckling av initiala krav till dess installation (installation) på en dator.

Erfarenhet av utveckling och implementering av olika klasser av AIS har visat hög effektivitet (inklusive ekonomisk) för deras tillämpning, särskilt på stora företag. Det återspeglas i den goda organisationen av arbetskraft och produktion, att öka planeringen och genomföra de uppsatta uppgifterna, säkerställa rytmen i företaget, minska andelen manuellt arbete, effektivt (inklusive operativt) informationsstöd för olika kategorier av användare, etc. Den genomsnittliga återbetalningstiden för sådana system överstiger vanligtvis inte två år.

Vid utveckling av IS ges i de flesta fall standarddesignlösningar, anpassade efter kundens specifika förhållanden och kapacitet. Individuella projekt utvecklas i avsaknad av standardlösningar eller när organisationens grundparametrar skiljer sig väsentligt (med mer än 10-15%) från standardlösningar. Detta gäller vanligtvis stora och största organisationer.

Inget IC -utvecklingsschema är absolut. Olika alternativ är möjliga, till exempel beroende på de initiala förhållandena under vilka utvecklingen genomförs: ett helt nytt system utvecklas; en undersökning av företaget har redan genomförts och det finns en modell av dess verksamhet; företaget har redan en IS som kan användas som en initial prototyp eller bör integreras med den utvecklade.

Detaljerad utveckling av AIS -projektet förutsätter att det finns en komplett uppsättning organisations-, design-, teknologisk och operativ dokumentation.

Utformningen av alla objekt utförs med:

• a) bestämma dess funktionella syfte (varför behövs det, vad och hur det designade objektet gör),
• b) identifiera logiska kopplingar (hur det designade objektet uppfyller sitt funktionella syfte, vilken information som behandlas och i vilken sekvens),
• c) val av material för genomförandet av det designade objektet - den funktionella, tekniska och tekniska aspekten (media, databehandlingsverktyg, etc.),
• d) rumslig (territoriell) placering av materiella försäljningsmedel i tilldelade eller möjliga användningsområden,
• e) bildande av organisations- och ledningsstrukturen för det designade objektet (sammansättning av avdelningar, befogenheter och funktionella ansvar arbetare)

Efter att ha valt AIS -designmetoden är det nödvändigt att planera en uppsättning arbeten för att skapa ett system i enlighet med de typiska stadierna av dess utveckling. Projektet granskas och godkänns av kunden. AIS -design innebär implementering av vissa steg och steg.

För ett framgångsrikt genomförande av projektet är det nödvändigt att upprätta riktiga milstolpar med tydligt markerat start och slut. Utvecklingen av en detaljerad arbetsplan är förknippad med en beskrivning av processerna och deras sekvens som utförs i varje steg, nödvändiga specialister, medel och resurser. Detta tillvägagångssätt hjälper i större utsträckning att undvika utelämnanden och misstag. Det är nödvändigt för anställda som genomför implementeringen av ett automatiseringsprojekt och har också en positiv inverkan på de personer som finansierar det.

Ett effektivt stegvis genomförande av konstruktionsarbete är förknippat med behovet av att ta fram ett schema för deras genomförande, inklusive resurser och tidpunkter (steg) för deras genomförande (se tidigare scheman och siffror). Resurser inkluderar nödvändig personal, hårdvara, programvara, finansiering och infrastruktur. Samtidigt är det bättre att finansiera det separat för varje typ av arbete (inköp av medel och programvara, installation, utbildning, individuella designstadier, etc.).

För automatisering olika typer aktiviteter (förvaltning, design, forskning, etc.), inklusive deras kombinationer, använder bestämmelserna i GOST 34.601-90. Den innehåller följande steg och designstadier (tabell 1).

Tabell 2

Standarden säger också att:

• · Etapper och etapper som utförs av organisationer, deltagare i skapandet av AU, fastställs i kontrakt och uppdragsvillkor baserat på denna standard.
• · Det är tillåtet att utesluta steget ”Utkast till design” och separata arbetsfaser i alla steg, att kombinera ”Teknisk design” och ”Arbetsdokumentation” till ett steg ”Teknikarbetande design”. Beroende på de specifika egenskaperna hos de NPP som skapas och förutsättningarna för deras skapande, är det tillåtet att utföra enskilda arbetsfaser innan de föregående stadierna är slutförda, parallellt med tidens utförande av arbetsstadier, införandet av nya arbetsfaser.

Det tekniska projektet (preliminär design) innehåller kretsscheman och konstruktionsdokumentation av utvecklingsobjektet och dess komponenter, en lista över utvalda färdiga mjukvaruverktyg och teknisk support(inklusive datortyper, operativsystem, applikationsprogram, etc.), algoritmer för att lösa problem för utveckling av nya mjukvaruverktyg).

Detaljerad design - det sista designstadiet i allmänhet, som förfinar och detaljerar resultaten från de föregående stadierna, skapande och testning av en prototyp av automatiseringsobjektet, utveckling och testning av mjukvaruprodukter, teknisk och operativ dokumentation.

I den moderna praxisen att utforma automatiserade informationssystem (till exempel AIPS, ASNTI, ACS, etc.) kan det vara det första steget i deras genomförande i arbetet med organisationen eller tjänsten hos projektkunden eller chefen en i ett antal andra automatiserade organisationer, tjänster etc.

Detaljerad utveckling av systemkonstruktionen förutsätter att det finns en komplett uppsättning organisations-, design-, teknologisk och operativ dokumentation.

Statens standard GOST 19.102-77 fastställer följande steg i utvecklingen av programvarudokumentation:

• 1. Referensvillkor;
• 2. Utkast till projekt;
• 3. Teknisk design;
• 4. Arbetsutkast;
• 5. Genomförande.

Observera att antalet etapper kan minskas för små projekt.

Som en del av genomförandet av det första steget ”Kravbildning för AU” undersöks objektet och behovet av att skapa en AIS är motiverat, med hänsyn till användarens krav på den designade AIS. Dessa första konstruktionsfasprocedurer är en del av fördesignstudien. Detta kan också inkludera procedurerna i det andra stadiet av design - ”Utveckling av NPP -konceptet”.

Under processen med fördesignforskning genomförs en förstudie för möjligheten att skapa en AIS; utveckling av allmänna krav för utveckling av AIS.

I processen med fördesignforskning för att utföra nödvändigt designarbete identifieras följande:

• · materiella resurser,
• · finansiella resurser,
• · personalavdelning,
• · Tillfälliga resurser.

För närvarande har vilken organisation som helst tillgång till vissa materiella resurser, som regel, av heterogent ursprung. För att säkerställa säkerheten för dessa resurser är det nödvändigt att föra register och utse ansvariga personer. Lösningen på detta problem kan utföras med olika applikationer som 1C: Enterprise, AVARD och många andra. Men dessa program är mycket dyra, både vid köp och underhåll. Kräva specialutbildning och utbildning av personal.

Under design bör förstå processen för att skapa en prototyp av det föreslagna eller möjliga objektet.

Modern teknik för att skapa AIS är en kombination av effektiva designverktyg och metoder som förenklar denna process, minskar kostnaderna, minskar kalendertiden för systemdesign och förbättrar kvaliteten på utvecklingen genom ett brett urval av beprövade avancerade designlösningar.

Till huvudet designverktyg kan tillskrivas:

Typiska designlösningar (TPD) och applikationspaket (PPP). TPR - en uppsättning algoritmiska och programvaruelement som säkerställer genomförandet av uppgifter på en dator med hjälp av lämpliga tekniska medel;

Computer-aided design systems (CAD), som involverar användning av datorer i alla skeden av skapandet av AIS.

Allmänna krav för konstruktionsverktyg:

Full täckning av hela processen med att skapa AIS;

Kompatibilitet, dvs. konsekvens både i processen för att skapa ett system och i processen för dess funktion;

Mångsidighet, dvs. möjligheten att använda samma verktyg för olika objekt;

Tillgänglighet i utveckling och enkelhet (enkelhet) i genomförandet;

Möjlighet att organisera designprocessen i interaktivt läge mellan systemutvecklare, designer och dator;

Anpassningsförmåga och kostnadseffektivitet.

Bland designmetoder fördela:

Original design;

Typisk design och dess typer: elementärt, delsystem, modulärt, grupp;

Datorstödd design.

Den ursprungliga designmetoden är traditionell och fokuserad på ett specifikt företag. Karaktäristiskt drag Denna metod är utvecklingen av originalmetoder för objektinspektion och skapandet av nödvändig dokumentation i form av ett enskilt projekt. Fördelen med denna metod är återspeglingen av de specifika egenskaperna hos automatiseringsobjektet i AIS -projektet. Nackdelarna inkluderar en relativt hög arbetsintensitet och lång utvecklingstid, en låg indikator på funktionell tillförlitlighet och anpassningsförmåga till förändrade förhållanden. Projekt som skapats med den ursprungliga metoden lämpar sig dock för modernisering i ren form denna metod används sällan. Idag, under implementeringen, används olika designverktyg, och endast vissa delar av projektet kräver originella designlösningar. Detta utjämnar något sina brister. Denna metod förblir dock relevant vid automatisering av komplexa, extraordinära objekt.

V moderna förhållanden AIS är vanligtvis inte byggt från grunden. För närvarande, i ekonomin, på nästan alla ledningsnivåer och på alla ekonomiska enheter, fungerar automatiska informationsbehandlingssystem. Det ökade behovet av aktuell, högkvalitativ och operativ information kräver att AIS skapas på en ny teknisk och teknisk grund.

Sökandet efter rationella sätt att designa går i följande riktningar:

1. Utveckling av standarddesignlösningar implementerade i tillämpade mjukvarupaket (PPP) för att lösa ekonomiska problem med efterföljande koppling av PPP till de specifika villkoren för implementering och drift.

2. utveckling av automatiserade designsystem.

Det första sättet är möjligheten att använda standarddesignlösningar som ingår i paketen med tillämpade program.

Typisk design- en industriell metod för att skapa AIS med TPR och PPP. Denna metod kännetecknas av närvaron av beprövade, standardiserade organisatoriska och ekonomiska, tekniska, informativa, matematiska ocherktyg. Tillämpningen av denna metod gör det möjligt att minska arbetsintensiteten, minska kostnaderna och förkorta designtiden och förbättra designkvaliteten. Den typiska designprocessen består i val och bindning av stödjande delsystem i enlighet med kraven för en specifik AIS. Den typiska delen av AIS är ett komplex av information, programvara och hårdvara. Informationsstödets typiska karaktär uppnås genom strikt överensstämmelse med enhetens struktur i informationsbasen, sammansättningen av matriserna, inmatnings- och utmatningsdokumentens former. Programvarans typiska karaktär uppnås genom att använda PPP, och den typiska tekniska supporten uppnås genom att använda datorer av samma eller kombinerade typer.

1. En variant av den typiska designmetoden är metoden elementär design, som är baserad på TPR. När man utvecklar ett projekt används en färdig lösning med mindre ändringar, och en ny utvecklas inte.

2. Vid användning modulär metod TPR skapas modulärt när varje designlösning är uppdelad i separata komponentdelar - moduler som implementerar en viss del av TPR. Detta låter dig skapa ett projekt för ett nytt automatiserat system genom att kombinera enskilda standardmoduler.

3. Vid användning undersystemets konstruktionsmetod för varje delsystem skapas lösningsprojekt och applikationspaket - systemomfattande och funktionella. Tilldelningen av delsystem beror på syftet med den ekonomiska och produktionsprocessen. För vart och ett av delsystemen utvecklas en egen automatiserad designlösning och PPP, som kan vara systemomfattande eller funktionella. Systemomfattande PPP inkluderar datahanterings PPP, PPP med standard databehandlingsförfaranden, metoder för matematisk statistik och diskret programmering, etc. Funktionella PPP inkluderar paket riktade till industriföretag med en diskret eller kontinuerlig produktion, i den icke-industriella sfären, och sektoriell förvaltning.

Ett viktigt krav för RFP är kompatibilitet, eftersom vid utformning av AIS är det lämpligt att använda flera paket samtidigt. Utformningen av system som använder PPP reduceras faktiskt till bindning av paket som valts enligt vissa parametrar till de specifika villkoren för automatiseringsobjektet. Positiva egenskaper Detta tillvägagångssätt för design kan kallas: mindre arbetskrävande process, minskning av designtid jämfört med originaldesign, implementering av avancerade databehandlingsmetoder, förenkling av projektdokumentation (eftersom paketdokumentation används), ökad tillförlitlighet för utformad AIS.

4. Dessutom finns det gruppdesignmetod... Dess väsen ligger i det preliminära urvalet av en grupp objekt av samma typ när det gäller egenskaper. Bland dem väljs basobjektet, för vilket projektet utvecklas, och olika metoder och designmetoder kan användas. Det viktigaste här är att säkerställa hög anpassningsförmåga för projektet. Det huvudsakliga tillämpningsområdet för denna metod är icke-industriella anläggningar (till exempel lager).

Följande aktiviteter lämpar sig mest effektivt för automatisering:

1. redovisning, inklusive förvaltning och ekonomi. Det största antalet RFP har skapats för redovisningsändamål. Bland dem finns "1C: Accounting", "Turbo-Accountant", "Info-Accountant", "Parus", "ABACUS", "Bambi +", etc.;

2. Hjälp och informationstjänst ekonomisk aktivitet... Representeras av följande PPP: "GARANT" (skatter, redovisning, revision, företagande, bank, valutareglering, tullkontroll); "CONSULBTANT +" (skatter, redovisning, revision, företagande, bank, valutareglering, tullkontroll).

3.ekonomiskt och finansiell verksamhet... Representeras av följande RFP:

a) "Ekonomisk analys och prognos för företaget, organisationen" (företaget "INEK"), som genomför funktionerna: ekonomisk analys företagets verksamhet, företag; upprättande av affärsplaner; förstudie för återbetalning av lån; analys och val av alternativ för aktiviteter; prognos för balans, kassaflöden och färdiga varor.

b) Fleranvändarnätverkskomplex för fullständig automatisering av Galaktika-bolaget (JSC Novy Atlant), vilket inkluderar planering, operativ hantering, redovisning och kontroll, analys, tillåter dessutom inom ramen för DSS att säkerställa lösningen av affärsplanering problem med PPP Project- Expert.

4. organisation av chefens arbete;

5. automatisering av dokumentcirkulation;

6. utbildning.

Nyligen föredrar företag och företag att köpa färdiga paket och teknik, och vid behov lägga till sin egen programvara till dem, eftersom utvecklingen av sin egen AIS är förknippad med höga kostnader och risker. Som regel utvecklas och föreslås ett grundläggande system som anpassas efter individuella kunders önskemål. Samtidigt får användarna konsultationer som hjälper till att minimera implementeringstiden för system och teknik, använda dem på det mest effektiva sättet och förbättra personalens kvalifikationer.

Datorstödd konstruktionssystem - det andra, snabbt utvecklande sättet att utföra designarbete.

Bland de datorstödda designmetoderna intar modelldesignmetoder en speciell plats. Skapandet och användningen av CAD -system ger en tillräckligt hög funktionell tillförlitlighet, omfattande täckning av alla tekniska processer, minskning av arbetsintensiteten i designarbete med maximal hänsyn till automatiseringsobjektets intressen. Denna metod är dock ganska dyr och kräver mycket skickliga utvecklare. Nyckelkravet för CAD är förmågan att bygga och underhålla en viss global ekonomisk informationsmodell för automatiseringsobjektet i designsystemet i ett adekvat tillstånd. En modell är en tydlig visning av informationskomponenter i ett automatiseringsobjekt och relationer mellan dem. Huvudmålet med att bygga en modell är att skapa ett AIS -projekt som motsvarar denna modell, med hänsyn till och aktivt använda alla objektets egenskaper. En sådan modell bör innehålla i en formaliserad form en beskrivning av uppsättningarna av informationskomponenter och förhållandet mellan dem, inklusive informationslänkar och algoritmisk interaktion. Med hjälp av modelldesignmetoden, systemmetod, som bestämmer användningen av datorer inte bara i alla stadier av skapandet av systemet, utan också i analysprocessen av resultaten av dess industriella drift. Utvecklingen och tillämpningen av CAD förutbestämde övergången till skapandet av enskilda projekt, men på en betydligt högre nivå än den ursprungliga designmetoden.

Under det senaste decenniet har en ny riktning vuxit fram inom området IC och IT -designautomation - CASE datorstödd mjukvaruutvecklingsteknik(CASE - Computer -Aided Software / System Engineering). Den ökande komplexiteten hos informationssystem, de ökande kraven på dem har lett till behovet av att industrialisera teknologier för deras skapande.

CASE -teknikär en uppsättning metoder för analys, design, utveckling och underhåll av IS, som stöds av en uppsättning sammankopplade automatiseringsverktyg. CASE är en verktygslåda för systemanalytiker, utvecklare och programmerare som automatiserar processen att designa och utveckla IC: er. CASE -system används som ett kraftfullt verktyg för att lösa forsknings- och designproblem, såsom strukturanalys av ämnesområdet, projektimplementering med den senaste generationen av programmeringsspråk, publicering av projektdokumentation, test av projektimplementering, planering och kontroll av utvecklingen, modellering affärsapplikationer för att lösa operativa problem. och strategisk planering och resurshantering etc.

Huvudmålet med CASE är att automatisera utveckling och drift av system så mycket som möjligt.

När man använder CASE-teknik förändras tekniken för arbete i alla skeden av livscykeln för automatiserade system. I CASE -system är design baserad på visuella visuella utvecklingsmetoder, medan diagram, diagram, tabeller, diagram och textförklaringar till dem används för att beskriva modellen för den designade IS. Sådana metoder ger en noggrann och beskrivande beskrivning av systemet som utformas, som börjar med en översikt över systemet och sedan går in mer i detalj och blir en hierarkisk struktur med ett ökande antal nivåer.

Programmeringsautomatisering är baserad på automatisk generering av programkoder som innehåller beskrivningar av data, huvudlogiken för deras bearbetning, databasscheman, gränssnittsbeskrivningsfiler etc. Koderna förfinas och förfinas ytterligare, men i vissa fall når automatiseringen 90%. Dessutom genererar CASE -tekniken nödvändig projektdokumentation redo att användas.

Vid användning av CASE-tekniken tillhandahålls stöd från en enda projektbas, dvs. all information om den utvecklade AIS placeras automatiskt i en enda projektdatabas. Detta bibehåller konsistens, konsistens, fullständighet och minimal redundans av designdata.

CASE-teknik ger teamarbete av utvecklingsteam, eftersom olika grupper av specialister får lämpliga verktyg, liksom möjligheten att konsekvent och korrekt göra ändringar i projektet av olika specialister i realtid.

CASE -teknik används framgångsrikt för att bygga nästan alla typer av AIS. CASE används också för att skapa systemmodeller som hjälper kommersiella strukturer att lösa problemen med strategisk planering, ekonomisk förvaltning, fast beslutsamhet, personalutbildning etc.

CASE har följande huvudsakliga fördelar:

Förbättra kvaliteten på den skapade IS (IT) med hjälp av automatisk kontroll (först och främst projektkontroll);

Låt på kort tid skapa en prototyp av framtida IS (IT), som gör att du snabbt, i ett tidigt skede, kan bedöma det förväntade resultatet;

Påskynda systemdesign och utvecklingsprocess;

Befria utvecklaren från rutinarbete, så att han helt kan koncentrera sig på den kreativa delen av designen;

De stöder utvecklingen och underhållet av ett redan fungerande IS.

Vid det här laget har en kraftfull CAS-industri uppstått, som sammanför hundratals företag och företag med olika inriktningar. Bland dem sticker ut:

Företag-utvecklare av verktyg för analys och design av IP och IT

Företagsutvecklare av specialverktyg med fokus på trånga ämnesområden eller på separata stadier av livscykeln för IP;

Utbildningsföretag som anordnar seminarier och utbildningar för specialister;

Konsultföretag som ger praktiskt stöd vid användning av CASE -paket för utveckling av specifika IS;

Företag specialiserade på publicering av tidskrifter och bulletiner om CASE -teknik.

Nbsp; AIS livscykelmodeller

AIS livscykelmodellär en struktur som beskriver de processer, åtgärder och uppgifter som utförs och utvecklingen, driften och underhållet under hela systemets livscykel.

Valet av en livscykelmodell beror på specifikationerna, skalan, komplexiteten i projektet och de villkor som AIS skapas och fungerar.

AIS livscykelmodell inkluderar:

Arbetsresultat i varje steg;

Viktiga händelser eller punkter för slutförande och beslutsfattande.

I enlighet med de välkända modellerna för programvarans livscykel bestäms modellerna för AIS: s livscykel - kaskad, iterativ, spiral.

I. Vattenfallsmodell beskriver det klassiska tillvägagångssättet för utveckling av system inom alla ämnesområden; användes mycket på 1970- och 1980 -talen.

Vattenfallsmodellen tillhandahåller sekventiell organisation av arbetet, och huvudfunktionen i modellen är uppdelning av allt arbete i etapper. Övergången från föregående etapp till nästa sker först efter att hela arbetet i det föregående har slutförts.

Fördela fem stabila utvecklingsstadier, praktiskt taget oberoende av ämnesområdet (fig. 1.1).

På först I detta skede genomförs en studie av problemområdet, kundens krav formuleras. Resultatet av detta skede är uppdraget (utvecklingsuppdrag), överenskommet med alla intresserade parter.

Under andra steg, enligt kraven i den tekniska uppgiften, utvecklas vissa designlösningar. Som ett resultat visas en uppsättning projektdokumentation.

Tredje steg - projektgenomförande; i huvudsak mjukvaruutveckling (kodning) i enlighet med designbesluten från föregående steg. I det här fallet är implementeringsmetoderna inte av grundläggande betydelse. Resultatet av detta steg är en färdig mjukvaruprodukt.

På fjärde I detta skede kontrolleras den mottagna programvaran för överensstämmelse med kraven i referensvillkoren. Försöksdrift gör att du kan identifiera olika sorters dolda brister som uppstår under AIS: s verkliga förhållanden.

Den sista etappen är kapitulation färdigt projekt, och det viktigaste här är att övertyga kunden om att alla hans krav uppfylls fullt ut.

Figur 1.1 Vattenfall AIS livscykelmodell

Arbetsstadierna inom ramen för vattenfallsmodellen kallas ofta delar av AIS -projektcykeln, eftersom stadierna består av många iterativa förfaranden för att klargöra systemkrav och designalternativ. AIS livscykel är betydligt mer komplicerad och längre: den kan innehålla ett godtyckligt antal cykler av förtydligande, ändringar och tillägg till redan antagna och implementerade designlösningar. I dessa cykler sker utvecklingen av AIS och moderniseringen av dess enskilda komponenter.

Kaskadmodellens fördelar:

1) i varje steg bildas en komplett uppsättning projektdokumentation som uppfyller kriterierna för fullständighet och konsekvens. I slutskedet utvecklas användardokumentation som täcker alla typer av AIS -stöd som tillhandahålls av standarderna (organisatorisk, informativ, programvara, teknisk, etc.);

2) den sekventiella implementeringen av arbetsstadierna låter dig planera tidpunkten för slutförandet och motsvarande kostnader.

Vattenfallsmodellen utvecklades ursprungligen för att lösa olika typer av tekniska problem och har inte tappat sin betydelse för det tillämpade fältet förrän nu. Dessutom är vattenfallsmetoden idealisk för utveckling av AIS, eftersom alla krav redan i början av utvecklingen kan formuleras ganska exakt för att ge utvecklare friheten att tekniskt genomföras. Sådana AIS, i synnerhet, inkluderar komplexa avvecklingssystem och realtidssystem.

Nackdelar med vattenfallsmodellen:

Betydande dröjsmål med att få resultat;

Fel och brister i vilket som helst skede uppträder som regel vid efterföljande arbetsskeden, vilket leder till behovet av att återvända;

Komplexiteten i det parallella arbetet med projektet;

Överdriven information övermättnad i vart och ett av stadierna;

Komplexitet i projektledning;

Hög risknivå och opålitliga investeringar.

Fördröjning i att ta emot resultat visar sig i det faktum att ett konsekvent tillvägagångssätt för utveckling av samordning av resultat med intressenter genomförs först efter att nästa arbetsskede har slutförts. Som ett resultat kan det visa sig att den utvecklade AIS inte uppfyller kraven, och sådana inkonsekvenser kan uppstå i alla utvecklingsstadier; Dessutom kan fel oavsiktligt införas av både analytiska formgivare och programmerare, eftersom de inte behöver vara insatta i ämnesområdena för vilka AIS utvecklas.

Återgå till tidigare skeden. Denna brist är en av manifestationerna av den föregående: steg-för-steg sekventiellt arbete med ett projekt kan leda till att misstag som gjorts i tidigare skeden upptäcks endast i efterföljande stadier. Som ett resultat återgår projektet till föregående steg, omarbetas och först sedan överförs till det efterföljande arbetet. Detta kan leda till ett avbrott i schemat och komplicera relationen mellan utvecklingsgrupperna som utför enskilda steg.

Det värsta alternativet är när bristerna i föregående steg inte upptäcks i nästa steg, men senare. Exempelvis kan det förekomma fel i beskrivningen av ämnesområdet i provningsstadiet. Detta innebär att en del av projektet måste återföras till det första arbetet.

Komplexitet i parallellt arbete i samband med behovet av att samordna olika delar av projektet Ju starkare förhållandet mellan de enskilda delarna av projektet är, desto oftare och mer grundligt bör synkronisering utföras, desto mer beroende av varandra är utvecklingsteamen. Som ett resultat går fördelarna med parallellt arbete helt enkelt förlorade. bristen på parallellitet påverkar organisationen av hela teamets arbete negativt.

Problem information övermättnad härrör från starka beroenden mellan olika utvecklingsgrupper. Faktum är att när du gör ändringar i en av projektets delar är det nödvändigt att meddela de utvecklare som använde (kunde använda) det i sitt arbete. Med ett stort antal sammankopplade delsystem blir synkroniseringen av intern dokumentation en separat kritisk uppgift: utvecklare måste ständigt bekanta sig med förändringarna och utvärdera hur dessa förändringar kommer att påverka de erhållna resultaten.

Komplexitet i projektledning främst på grund av den strikta sekvensen av utvecklingsstadier och närvaron av komplexa relationer mellan olika delar av projektet. Den reglerade arbetssekvensen leder till det faktum att vissa utvecklingsteam måste vänta på resultaten från andra teams arbete, så administrativa ingrepp krävs för att komma överens om tidpunkten och sammansättningen av den inlämnade dokumentationen.

Om det upptäcks fel i arbetet är det nödvändigt att återgå till föregående steg; det nuvarande arbetet för dem som gjort ett misstag avbryts. Konsekvensen av detta är vanligtvis en fördröjning i genomförandet av både det korrigerade och det nya projektet.

Det är möjligt att förenkla interaktionen mellan utvecklare och minska informationsöverbelastningen av dokumentation genom att minska antalet anslutningar mellan enskilda delar av projektet, men inte alla AIS kan delas in i löst kopplade delsystem.

Hög risknivå. Ju mer komplext projektet är, desto längre tar varje steg i utvecklingen och desto mer komplexa är sammankopplingarna mellan de enskilda delarna av projektet, vars antal också ökar. Dessutom kan utvecklingsresultaten verkligen ses och utvärderas endast på teststadiet, dvs efter att analys-, design- och utvecklingsfasen har slutförts, vars genomförande kräver betydande tid och pengar.

Sen utvärdering skapar allvarliga problem med att identifiera fel i analys och design - du måste gå tillbaka till tidigare steg och upprepa utvecklingsprocessen. Återgången till de föregående stadierna kan dock inte bara associeras med fel, utan också med förändringar som har skett inom ämnesområdet eller i kundens krav under utvecklingen. Samtidigt garanterar ingen att ämnesområdet inte kommer att ändras igen när nästa version av projektet är klart. I själva verket innebär detta att det finns en sannolikhet att "loopa" utvecklingsprocessen: projektets kostnader kommer ständigt att växa och tidsfristerna för leverans av den färdiga produkten skjuts hela tiden upp.

II. Iterativ modell består av en serie korta cykler (steg) av planering, genomförande, studier, åtgärder.

Skapandet av komplexa AIS innebär godkännande av designlösningar som erhållits vid genomförandet av enskilda uppgifter. Nedifrån-och-upp designmetoden kräver sådana iterationer av avkastning när designlösningar för enskilda uppgifter kombineras till vanliga systemiska. Samtidigt finns det ett behov av att revidera de tidigare utformade kraven.

Fördel den iterativa modellen är att stegvisa anpassningar ger mindre arbetskrävande utveckling jämfört med vattenfallsmodellen.

nackdelar iterativ modell:

· Livslängden för varje steg förlängs för hela arbetstiden.

· På grund av ett stort antal iterationer finns det inkonsekvenser i implementeringen av designlösningar och dokumentation;

· Arkitekturens inveckling;

· Svårigheter att använda konstruktionsdokumentation i implementerings- och driftstadierna kräver en omdesign av hela systemet.

III. Spiral modell, i motsats till kaskaden, men liknande den föregående, innebär det en iterativ process för AIS -utveckling. Samtidigt ökar betydelsen av de inledande stadierna, till exempel analys och design, där genomförbarheten av tekniska lösningar kontrolleras och motiveras genom att skapa prototyper.

Varje iteration representerar en komplett utvecklingscykel som leder till att en intern eller extern version av en produkt (eller en delmängd av slutprodukten) släpps, vilket förbättras från iteration till iteration för att bli ett komplett system (figur 1.2).

Ris. 1.2. Spiral modell av livscykel AIS

Således motsvarar varje spiralvridning skapandet av ett fragment eller en version av en mjukvaruprodukt, projektets mål och egenskaper specificeras på den, dess kvalitet bestäms, arbetet planeras för nästa spiralsväng. Varje iteration tjänar till att fördjupa och konsekvent konkretisera detaljerna i projektet, vilket leder till att ett rimligt alternativ för det slutliga genomförandet väljs.

Med hjälp av spiralmodellen kan du gå vidare till nästa steg i projektet utan att vänta på att den nuvarande är klar - det oavslutade arbetet kan slutföras vid nästa iteration. huvuduppgiften varje iteration - skapa en användbar produkt för demonstration för användare så snart som möjligt. Således är processen med att göra justeringar och tillägg till projektet mycket förenklad.

Den spiraliserade metoden för mjukvaruutveckling övervinner de flesta bristerna i vattenfallsmodellen, dessutom ger den ett antal ytterligare funktioner, vilket gör utvecklingsprocessen mer flexibel.

Fördelar iterativ metod:

Iterativ utveckling förenklar kraftigt att göra ändringar i projektet när kundens krav ändras;

När spiralmodellen används integreras AIS: s individuella element gradvis i en enda helhet. Eftersom integrationen börjar med färre element, är det mycket färre problem i genomförandet;

Minska risknivån (en följd av den tidigare fördelen, eftersom riskerna upptäcks exakt under integrationen). Riskerna är maximala i början av projektets utveckling; när utvecklingen fortskrider minskar den;

Iterativ utveckling ger mer flexibilitet i projektledning genom att låta taktiska ändringar göras i den produkt som utvecklas. Så du kan förkorta utvecklingstiden genom att minska systemets funktionalitet eller använda den som komponentdelar produkter från tredjepartsföretag i stället för deras egen utveckling (relevant i en marknadsekonomi, när det är nödvändigt att motstå marknadsföring av konkurrenters produkter);

En iterativ metod gör det lättare att återanvända komponenter, eftersom det är mycket lättare att identifiera (identifiera) gemensamma delar av projektet när de redan är delvis utvecklade än att försöka isolera dem i början av projektet. Analys av projektet efter flera första iterationer avslöjar vanliga återanvändbara komponenter som kommer att förbättras i efterföljande iterationer;

Spiralmodellen möjliggör ett mer pålitligt och stabilt system. Detta beror på det faktum att när systemet utvecklas upptäcks och korrigeras fel och svagheter vid varje iteration. Samtidigt justeras kritiska prestandaparametrar, som i fallet med en vattenfallsmodell endast är tillgänglig före implementeringen av systemet;

En iterativ metod förbättrar processen
utveckling - som ett resultat av analysen i slutet av varje iteration görs en utvärdering av förändringar i utvecklingsorganisationen; det förbättras vid nästa iteration.

Spiralcykelns huvudproblem- svårigheten att bestämma övergångsmomentet till nästa steg. För att lösa det är det nödvändigt att införa tidsgränser för varje steg i livscykeln. Annars kan utvecklingsprocessen bli en oändlig förbättring av det som redan har gjorts.

Genom att involvera användare i processen att designa och kopiera applikationen kan du ta emot kommentarer och tillägg till kraven direkt i processen att designa programmet, vilket minskar utvecklingstiden. Kundrepresentanter får möjlighet att styra processen för att skapa ett system och påverka dess funktionella innehåll. Resultatet är idrifttagning av ett system som tar hänsyn till de flesta av kundens behov.

Moderna metoder och AIS -designtekniker som implementerar dem levereras till i elektroniskt format tillsammans med CASE-verktyg och inkluderar bibliotek med processer, mallar, metoder, modeller och andra komponenter avsedda för att bygga programvara av den klass av system som metoden är inriktad på. Elektroniska metoder och tekniker utgör kärnan i en uppsättning överenskomna verktyg utveckling av AIS. Funktioner i moderna metodiska lösningar för att utforma AIS kan inte implementeras utan viss designteknologi som motsvarar projektets omfattning och specifika egenskaper.

AIS designteknikär en uppsättning metoder och verktyg för att designa AIS, samt metoder och verktyg för att organisera design (hantera processen för att skapa och modernisera ett AIS -projekt).

Enligt TP-design är AIS en uppsättning sekventiellt parallella, anslutna och underordnade handlingskedjor, som var och en kan ha sitt eget ämne. De åtgärder som utförs i utformningen av AIS kan definieras som odelbara tekniska operationer eller som delprocesser för tekniska operationer. Alla handlingar kan vara korrekta design, som formar eller ändrar designresultat, och beräknad, som är utvecklade enligt de fastställda kriterierna för utvärdering av designresultat.

Designtekniken fastställs således av en reglerad sekvens av tekniska operationer som utförs i processen att skapa ett projekt baserat på en viss metod.

Ämnet för den valda designtekniken bör vara reflektion av sammanhängande designprocesser i alla stadier av AIS -livscykeln.

De viktigaste kraven för den valda designtekniken är följande:

· Projektet som skapats med hjälp av denna teknik måste uppfylla kundens krav;

· Tekniken bör så mycket som möjligt återspegla alla stadier av projektets livscykel.

· Tekniken bör tillhandahålla minimikostnader för arbetskraft och kostnader för design och projektstöd.

· Tekniken bör bidra till tillväxten av designers arbetskraftsproduktivitet.

· Tekniken bör säkerställa tillförlitligheten i projektets design och drift.

· Tekniken ska underlätta enkelt underhåll av projektdokumentation.

AIS designteknik implementerar en specifik designmetodik. I sin tur antar designmetoden närvaron av vissa koncept, designprinciper och implementeras med en uppsättning metoder och verktyg.

AIS -designmetoder kan klassificeras efter graden av användning av automatiseringsverktyg, typiska designlösningar, anpassningsförmåga till förväntade förändringar.

Enligt graden av automatisering skiljer de sig från:

manuell design, där utformningen av AIS -komponenter utförs utan användning av speciella mjukvaruverktyg; programmering sker på algoritmiska språk;

datordesign, där generering eller konfiguration (tuning) av designlösningar utförs med hjälp av speciella mjukvaruverktyg.

Enligt graden av användning av typiska designlösningar skiljer de sig från:

original (individuellt) design, när designlösningar utvecklas "från grunden" i enlighet med kraven för AIS;

typisk design, förutsatt att konfigurationen av AIS från färdiga standarddesignlösningar (mjukvarumoduler).

Original design AIS antar maximal beaktande av funktionerna i en automatiserad anläggning.

Typisk design utförs på grundval färdiga lösningar och är en generalisering av erfarenheterna som gjorts tidigare vid skapandet av relaterade projekt.

Genom graden av anpassningsförmåga hos designlösningar följande metoder skiljer sig åt:

rekonstruktion- anpassning av designlösningar utförs genom bearbetning av motsvarande komponenter (omprogrammering av programvarumoduler);

parametrisering- designlösningar justeras i enlighet med de angivna och variabla parametrarna;

omstrukturering av modellen- domänmodellen förändras, vilket leder till automatisk reformering av designlösningar.

Kombinationen av olika funktioner i klassificeringen av designmetoder bestämmer arten av AIS -designtekniken som används. Det finns två huvudklasser av designteknik: kanonisk och industriell... Industriell designteknik är indelad i två underklasser: automatiserad(användning av CASE -teknik) och typisk(parametrisk eller modellorienterad) design.

Tabell 1.1.Egenskaper hos designtekniska klasser

Kanonisk AIS -design fokuserar på användningen av främst vattenfallsmodellen av AIS -livscykeln.

Beroende på komplexiteten hos automatiseringsobjektet och uppsättningen uppgifter som måste lösas när man skapar en specifik AIS kan stadierna och stadierna i arbetet ha olika arbetsintensitet. Det är tillåtet att kombinera sekventiella stadier och utesluta några av dem i alla stadier av projektet. Det är också tillåtet att påbörja arbetet i nästa etapp före slutet av det föregående.

Stadierna och stadierna för skapandet av AIS, utförda av deltagande organisationer, föreskrivs i kontrakt och uppdragsvillkor för utförande av arbete.

Steg 1. Kravbildning för AIS:

· Undersökning av anläggningen och motivering av behovet av att skapa AIS;

· Utformning av användarkrav för AIS;

· Upprättande av en rapport om utfört arbete och ett taktiskt och tekniskt uppdrag för utveckling.

Steg 2. Utveckling av AIS -konceptet:

· Studie av automatiseringsobjektet;

· Utföra det nödvändiga forskningsarbetet;

· Utveckling av alternativ för konceptet AIS, som uppfyller användarnas krav.

· Utarbetande av rapporten och godkännande av konceptet.

Steg 3. Teknisk uppgift:

Utveckling och godkännande av tekniska specifikationer för skapandet av AIS.

Steg 4. Preliminär design:

· Utveckling av preliminära designlösningar för systemet och dess delar;

· Utveckling av dispositionsdokumentation för AIS och dess delar.

Steg 5. Tekniskt projekt:

· Utveckling av designlösningar för systemet och dess delar;

· Utveckling av dokumentation för AIS och dess delar;

· Utveckling och utförande av dokumentation för leverans av komponenter;

· Utveckling av designuppdrag inom relaterade delar av projektet.

Steg 6. Arbetsdokumentation:

· Utveckling av arbetsdokumentation för AIS och dess delar;

· Utveckling och anpassning av program.

Steg 7. Idrifttagning:

· Förberedelse av automatiseringsobjektet; Personalutbildning;

· Komplett uppsättning AIS -levererade produkter (programvara och hårdvara, mjukvara och hårdvarukomplex, informationsprodukter);

· Bygg- och installationsarbete; idrifttagningsarbeten;

· Genomföra preliminära tester;

· Genomföra provdrift;

· Genomföra godkännandeprov.

Steg 8. AIS -eskort:

· Utförande av arbete i enlighet med garantiförpliktelser;

· Efter-garantiservice.

Undersökning- är studien och analysen av företagets organisationsstruktur, dess verksamhet och det befintliga systemet informationsbearbetning.

Materialet som erhållits som ett resultat av undersökningen används för:

Motivering för utveckling och etappvis implementering av system.

Utarbeta tekniska specifikationer för utveckling av system;

Utveckling av tekniska och arbetsprojekt för system.

I undersökningsskedet är det lämpligt att skilja på två komponenter: definiera AIS -implementeringsstrategi och en detaljerad analys av organisationens verksamhet.

Huvuduppgiften för den första etappen av undersökningen är att bedöma projektets verkliga volym, dess mål och mål baserat på de identifierade funktionerna och informationselementen för det höga automatiserade objektet. Dessa uppgifter kan genomföras antingen av AIS -kunden oberoende eller med hjälp av konsultorganisationer. Detta skede innebär nära interaktion med de potentiella huvudanvändarna av systemet och affärsexperter. Interaktionens huvuduppgift är att få en fullständig och otvetydig förståelse för kundens krav. Vanligtvis kan den information du behöver erhållas genom intervjuer, konversationer eller workshops med ledning, experter och användare.

När undersökningssteget är klart blir det möjligt att fastställa de troliga tekniska tillvägagångssätten för att skapa systemet och uppskatta kostnaderna för dess implementering (för hårdvara, för köpt programvara och för utveckling av ny programvara).

Resultatet av strategidefinitionsstadiet är ett dokument (förstudie - förstudie - projekt), där det tydligt formuleras vad kunden kommer att få om han går med på att finansiera projektet, när han får den färdiga produkten (arbetsschema) och hur mycket kommer det att kosta (för stora projekt - detta är ett finansieringsschema i olika arbetsskeden). Det är önskvärt att reflektera i dokumentet inte bara kostnaderna, utan också fördelarna med projektet, till exempel återbetalningstid för projektet, förväntat ekonomisk effekt(om det går att bedöma).

Begränsningar, risker, kritiska faktorer som kan påverka projektets framgång;

Uppsättningen av villkor under vilka det framtida systemet är tänkt att fungera - systemarkitektur, hårdvara och mjukvara, driftsförhållanden, servicepersonal och användare av systemet;

Villkor för slutförande av enskilda steg, formen för acceptans / leverans av arbetet, de inblandade resurserna, åtgärder för att skydda information;

Beskrivning av de funktioner som utförs av systemet;

Möjligheter för utveckling och modernisering av systemet;

Gränssnitt och fördelning av funktioner mellan en person och ett system;

krav för programvara och databashanteringssystem (DBMS).

I steget med detaljerad analys av organisationens verksamhet studeras aktiviteter som säkerställer genomförandet av ledningsfunktioner, organisationsstruktur, personal och innehåll i arbetet med företagsledning, liksom arten av underordning till högre ledningsorgan. Här är det nödvändigt att beskriva det instruktions-metodiska och direktivmaterialet, på grundval av vilket delsystemens sammansättning och uppgiftslistan, liksom möjligheten att använda nya metoder för att lösa problem, bestäms.

Analytiker samlar in och registrerar information i två sammanhängande former:

Funktioner - information om händelser och processer som sker i den automatiserade organisationen;

Enheter - Information om de klasser av objekt som är relevanta för organisationen och om vilken data som samlas in.

När du studerar varje funktionell kontrolluppgift bestäms följande:

Arbetsnamn; villkor och frekvens för sitt beslut;

Graden av formaliserbarhet av problemet;

Informationskällor som krävs för att lösa problemet;

Indikatorer och deras kvantitativa egenskaper;

Förfarandet för att korrigera information;

Operationsalgoritmer för beräkning av indikatorer och möjliga kontrollmetoder;

Befintliga sätt att samla in, överföra och behandla information;

Befintliga kommunikationsmedel;

Godkänd noggrannhet i problemlösningen;

Komplexiteten i att lösa problemet;

Befintliga former för presentation av initiala data och resultaten av deras behandling i form av dokument;

Konsumenter av den resulterande informationen om uppgiften.

En av de mest tidskrävande, om än väl formaliserade, uppgifterna i detta skede är beskrivningen av organisationens arbetsflöde. Vid undersökning av arbetsflödet upprättas ett diagram över hur dokumenten flyttas, vilket ska återspegla:

Antal dokument;

Plats för bildande av dokumentindikatorer;

Förhållandet mellan dokument under deras bildande;

Rutten och varaktigheten för dokumentets rörelse;

Plats för användning och lagring av detta dokument;

Intern och extern informationskommunikation;

Dokumentets volym i tecken.

Baserat på resultaten av undersökningen upprättas en lista över hanteringsuppgifter som jag ska automatisera och sekvensen för deras utveckling.

Under undersökningsfasen bör de planerade systemfunktionerna klassificeras efter deras betydelse. Ett av de möjliga formaten för att presentera en sådan klassificering är MuSCoW. Denna förkortning står för: Måste ha - nödvändiga funktioner; Bör ha - önskade funktioner; Kan ha - jag möjliga funktioner; Kommer inte att sakna funktioner.

Funktioner i den första kategorin är avgörande för I framgångsrikt arbete systemfunktioner. Genomförandet av funktionerna i den andra och tredje kategorin begränsas av tiden och den ekonomiska ramen: det nödvändiga, såväl som maximalt möjliga, i prioritetsordning, utvecklas antalet funktioner för den andra och tredje kategorin. Den sista kategorin av funktioner är särskilt viktig, eftersom det är nödvändigt att tydligt förstå gränserna för projekt I och den uppsättning funktioner som kommer att saknas i systemet.

Organisationsaktivitetsmodeller skapas i två typer 1:

Modellen "som den är" speglar de affärsprocesser som finns i organisationen;

Modellen ”att vara” återspeglar de nödvändiga förändringarna i affärsprocesser med beaktande av införandet av AIS. j

Redan i analysstadiet är det nödvändigt att involvera testgruppen i arbetet för att lösa följande uppgifter:

Erhålla jämförande egenskaper hos hårdvaruplattformar, operativsystem, DBMS, etc.

Utveckling av en arbetsplan för att säkerställa tillförlitligheten hos AIS och dess testning.

Att engagera testare tidigt i utvecklingen är en bra idé för alla projekt. Ju senare fel i designlösningar upptäcks, desto dyrare är det att fixa dem; det värsta scenariot är deras upptäckt under implementeringsfasen. Ju tidigare testteamen börjar identifiera fel i AIS, desto lägre blir kostnaden för att arbeta med systemet. Tid för att testa systemet och för att korrigera upptäckta fel bör ges inte bara i utvecklingsstadiet, utan också i designstadiet.

Speciella buggspårningssystem är utformade för att underlätta och öka testningens effektivitet. Deras användning gör att du kan ha ett enda arkiv av fel, spåra deras återkommande, kontrollera hastigheten och effektiviteten för felkorrigering, se de mest instabila systemkomponenterna och även upprätthålla kommunikation mellan utvecklingsteamet och testteamet.

Undersökningsresultaten utgör en objektiv grund för utformningen av tekniska specifikationer för AIS.

Teknisk uppgiftÄr ett dokument som definierar de mål, krav och grundläggande initiala data som är nödvändiga för utvecklingen av ett automatiserat styrsystem.

När du utvecklar ett tekniskt uppdrag (TOR) är det nödvändigt att lösa följande uppgifter:

· Att fastställa det allmänna syftet med att skapa AIS;

· Upprätta allmänna krav för det konstruerade systemet;

· Utveckla och underbygga kraven på information, matematik, programvara, hårdvara och tekniskt stöd;

· Att bestämma sammansättningen av delsystem och funktionella uppgifter;

· Utveckla och motivera kraven för delsystem.

· Att bestämma stadierna för att skapa systemet och tidpunkten för deras implementering;

Gör en preliminär beräkning av kostnaderna för att skapa ett system och bestäm nivån ekonomisk effektivitet genomförande;

· Att bestämma artisternas sammansättning.

Typiska krav för sammansättningen och innehållet i de tekniska specifikationerna anges i tabellen. 1.6.

Tablitsa 1.6. Sammansättningen och innehållet i den tekniska uppgiften (GOST 34.602-89)

Exklusivt projekt tillhandahåller utveckling av preliminära designlösningar för systemet och dess delar. Den preliminära designen är inte ett strikt obligatoriskt skede. Om huvuddesignlösningarna definieras tidigare eller är tillräckligt uppenbara för ett specifikt AIS- och automatiseringsobjekt, kan detta steg uteslutas från den allmänna sekvensen av verk.

AIS -funktioner;

Delsystemens funktioner, deras mål och den förväntade effekten av implementering;

Sammansättning av uppgiftskomplex och individuella uppgifter;

Informationsbas koncept och dess förstorade struktur;

Databashanteringssystemfunktioner;

Sammansättning av ett datasystem och andra tekniska medel;

Funktioner och parametrar för huvudprogramvaran.

Baserat på resultaten av det utförda arbetet utarbetas, överenskommes och godkänns dokumentation i det belopp som krävs för att beskriva hela uppsättningen av antagna konstruktionsbeslut och tillräckligt för ytterligare arbete med att skapa systemet.

I enlighet med GOST 19.102-77 innehåller det preliminära designstadiet två steg: utveckling av en preliminär design; godkännande av designutkastet.

Det första utvecklingsstadiet består av:

Preliminär utveckling av strukturen för in- och utdata;

Förfining av metoder för att lösa problemet;

Utveckling av en allmän beskrivning av algoritmen för att lösa problemet;

Utveckling av en förstudie;

Utveckling av en förklarande anmärkning.

I det här fallet är det tillåtet att kombinera och utesluta vissa verk.

Nedan finns en uppsättning dokument som bör och kan förberedas i slutet av skissdesignen.

Obligatoriska dokument:

1) uppdaterade referensvillkor för design och utveckling
arbete av AIS;

2) specifikation av kvalifikationskrav för AIS;

3) en uppsättning kravspecifikationer för funktionella programvarukomponenter och databeskrivningar;

4) kravspecifikation för komponentens interna gränssnitt och gränssnitt mot den yttre miljön;

5) en beskrivning av databashanteringssystemet, struktur och distribution av programvara och informationsobjekt i databasen;

6) utkast till riktlinjer för att skydda information och säkerställa tillförlitligheten för AIS: s funktion;

7) en preliminär version av AIS -administratörshandboken;

8) en preliminär version av AIS -användarhandboken;

9) en reviderad plan för genomförandet av projektet;

10) raffinerad plan för kvalitetssäkring av AIS;

11) förklarande anmärkning till det preliminära utkastet till AIS;

12) ett reviderat kontrakt (avtal) med kunden för en detalj-
ny design av AIS.

Dokument upprättade efter överenskommelse med kunden:

1) en preliminär beskrivning av AIS: s funktion;

2) ett diagram över dataflöden mellan AIS: s funktionella komponenter;

3) ett förfinat diagram över AIS -arkitekturen, interaktionen mellan programvara och informationskomponenter, dataprocessens organisation och allokering av resurser;

4) en beskrivning av kvalitetsindikatorerna för komponenterna och kraven för dem genom stadier av AIS -utveckling;

5) rapportera om tekniska och ekonomiska indikatorer, schema för genomförande av projekt, resursfördelning och budget;

6) en tabell över fördelning av specialister efter komponenter och efter arbetsstadier;

7) certifikat från utvecklare för rätten att använda teknik och automatiseringsverktyg för utveckling av AIS;

8) en beskrivning av kraven för de resulterande dokumentens sammansättning och former efter arbetsstadier;

9) en plan för felsökning av mjukvarukomponenter, förse den med metoder för testautomatisering och verktyg;

10) preliminär vägledning för detaljerad design
vaniya, programmering och felsökning av AIS -komponenter;

11) preliminär plan för försäljning och genomförande;

12) en beskrivning av databasens preliminära struktur.

Tekniskt projekt system är teknisk dokumentation som innehåller systemövergripande designlösningar, algoritmer för att lösa problem, samt en bedömning av AIS: s ekonomiska effektivitet. I detta skede utförs ett komplex av forsknings- och experimentarbete för att välja de huvudsakliga designlösningarna och beräkna systemets ekonomiska effektivitet. Det tekniska projektets sammansättning och innehåll anges i tabell. 1.7

Tabell 1.7. Innehåll i det tekniska projektet

I steget "Arbetsdokumentation" utförs skapandet av en mjukvaruprodukt och utvecklingen av all medföljande dokumentation. Dokumentationen bör innehålla all nödvändig och tillräcklig information för att säkerställa utförandet av arbetet med idrifttagning av AIS och dess drift, samt för att upprätthålla systemets operativa egenskaper (kvalitet). Den utvecklade dokumentationen måste vara korrekt upprättad, överenskommen och godkänd.

I steget "I drift" för AIS fastställs följande huvudtyper av tester: preliminära tester, försöksdrift och godkännandeprov. Vid behov är det tillåtet att dessutom utföra andra typer av tester av systemet och dess delar.

Beroende på förhållandet mellan AIS -komponenterna och automatiseringsobjektet kan testerna vara autonoma och komplexa. Systemkomponenter är inblandade i autonoma tester. De utförs så snart systemets delar är klara för driftsättning. Komplexa tester utförs för grupper av sammankopplade komponenter (delsystem) eller för systemet som helhet.

För att planera genomförandet av alla typer av tester utvecklas dokumentet "Program och testmetodik". Utvecklaren av dokumentet är etablerat i kontraktet eller TK. Tester eller testfall kan ingå i dokumentet som bilaga.

Felsökning är den mest tidskrävande designprocessen. Dolda fel uppstår ibland efter många års systemdrift. Det är omöjligt att helt undvika fel, vilket beror på det astronomiska antalet alternativ för systemets drift. Det är nästan omöjligt att kontrollera dem alla för korrekt funktion inom överskådlig framtid.

Kostnaden för att identifiera och eliminera fel i senare konstruktionsstadier ökar ungefär exponentiellt (figur 1.10).

Forskare räknar 169 typer av fel, sammanfattade i 19 stora klasser:

1) logiskt;

2) datahanteringsfel;

3) I / O -fel;

4) fel i beräkningar;

Ris. 1.10. Den relativa kostnaden för att upptäcka och fixa ett enda fel

5) fel i användargränssnitt;

6) fel i operativsystemet och hjälpprogram;

7) layoutfel;

8) fel i interprogrammeringsgränssnitt;

9) fel i gränssnitten "Program - systemprogramvara";

10) fel vid hantering av externa enheter;

11) fel i gränssnittet med databasen (DB);

12) databasinitieringsfel;

13) fel i ändringar på begäran utifrån;

14) fel relaterade till globala variabler;

15) repetitiva misstag;

16) fel i dokumentationen;

17) kränkning av tekniska krav;

18) okända fel;

19) operatörsfel.

Alla buggar kommer inte från utvecklaren. Enligt olika forskare orsakas från 6 till 19% av felen av fel i dokumentationen.

Förhållandet mellan utveckling och testning i olika stadier av AIS -design visas i fig. 1.11.

Denna kedja "sträcks" endast villkorligt till en linje. Det finns alltid återkommande slingor inuti den. För att identifiera fel skapar utvecklare speciella tester och genomför ett felsökningssteg. Om inga fel hittas betyder det inte att det inte finns några - kanske testet visade sig vara för svagt.

Ris. 1.11. Korrelation mellan utveckling och testning i etapper av AIS -design

Felsökningstekniken tar hänsyn till symptomen på eventuella fel:

Felaktig behandling (fel svar, resultat) - upp till 30%;

Felaktig överföring av kontroll - 16%;

Inkompatibilitet mellan program och data som används - 15%;

Inkompatibilitet för program för överförd data - upp till 9%.

När du utvecklar felsökningsuppgifter löses följande uppgifter:

Skrivprov;

Val av punkter, zoner och kontrollvägar;

Bestämning av listan över kontrollerade kvantiteter och förfarandet för att fastställa deras värden;

Inställning av testordning;

Bedömning av tillförlitligheten och komplexiteten i felsökning.

Programmet som felsöker måste åtminstone en gång arbeta igenom varje gren av algoritmen och samtidigt tilldela en serie värden till variablerna, fånga gränserna för intervallet, flera värden inom den, nollvärden och singulära punkter (om sådana finns). För specialiserade system utvecklas speciella felsökningsspråk. De kan innehålla ett relativt litet antal kommandon (20-30) med ytterligare inställningsparametrar för att lösa följande uppgifter:

Uttagskontroll;

Modellering av körningsprocessen för programmet som felsöker;

Utfärda tillståndet för minneskomponenter under programkörning;

Kontrollera villkoren för att uppnå vissa tillstånd i programkörningsprocessen;

Upprätta testvärden för de initiala data;

Implementering av villkorliga hopp i testning, beroende på resultaten av utförandet av andra makron eller olika tester;

Utför serviceoperationer för att förbereda programmet för testning.

Felsökningsprocessen kan inte klassificeras som fullständigt formaliserad, därför finns det empiriska rekommendationer för dess beteende, som ges nedan.

1. Använd ett semantiskt, medvetet tillvägagångssätt för felsökning, planera din felsökningsprocess och utforma noggrant testdatauppsättningar från de enklaste möjliga alternativen, vilket eliminerar de mest sannolika felkällorna.

2. Samla in och analysera information för att effektivisera testprocessen:

Funktioner och felstatistik;

Om detaljerna i de initiala uppgifterna och sekvensen för att ändra variabler i programmet och deras ömsesidiga inflytande;

Om algoritmens struktur och funktionerna i dess programvaruimplementering.

3. Leta bara efter ett fel i taget.

Använd metoderna för att logga och visa information om fel, inklusive i programmets speciella felsökningskod för att skriva ut provvärden för variabler, meddelanden om slutet av enskilda avsnitt i programmet, spårning, logiska förhållanden etc.

5. Studera den resulterande produktionen noggrant och jämför den med de förväntade, förberäknade resultaten.

6. Var uppmärksam på data, analysera programmets funktion noggrant när du använder gränsvärden och när du anger fel; kontrollera datatyper, intervall, fältstorlekar och precision.

7. Använd dataflöde och kontrollflödesanalys för att validera och upprätta datavidenskaper för olika vägar för programkörning.

8. Använd en mängd olika felsökningsverktyg samtidigt, utan att tänka på en enda möjlighet. Använd automatiserade verktyg och manuell felsökning och testning samtidigt, kontrollera programkoden för prestanda, med hänsyn till de mest troliga felen.

9. Dokumentera eventuella fel som har fastställts och åtgärdats, deras skillnader, plats och typ. Denna information kommer att vara användbar för att förhindra framtida fel.

10. Mät programmens komplexitet. I program med hög komplexitet finns det stor sannolikhet för specifikations- och designfel och med låg komplexitet - kodnings- och skrivfel.

11. Att öka erfarenheten och öva på att felsöka artificiellt placera fel i program. Efter en viss period av felsökning bör programmeraren peka på eventuella återstående fel som han inte hittade. Sådan "sådd" används i stor utsträckning för att uppskatta antalet oupptäckta fel (om både konstgjorda och verkliga fel detekteras och korrigeras enhetligt, kan det antas hur många av dem som finns kvar med andelen introducerade och verkliga fel som upptäcks).

Preliminära tester utförs för att fastställa systemets funktionsduglighet och för att lösa frågan om möjligheten att det accepteras i testdrift. Preliminära tester bör utföras efter att utvecklaren har felsökt och testat den medföljande programvaran och maskinvaran i systemet och lämnat relevanta dokument om deras beredskap för testning, samt efter att AIS -personalen har bekantat sig med den operativa dokumentationen.

Provning av systemet utförs för att bestämma de verkliga värdena för systemets kvantitativa och kvalitativa egenskaper och personalens beredskap att arbeta under förhållandena för dess funktion, samt för att bestämma den verkliga effektiviteten och justera vid behov dokumentationen.

Acceptationstester utförs för att fastställa systemets överensstämmelse med de tekniska specifikationerna, bedöma kvaliteten på försöksdriften och lösa frågan om möjligheten att acceptera systemet till permanent drift.

Skicka ditt bra arbete i kunskapsbasen är enkel. Använd formuläret nedan

Studenter, doktorander, unga forskare som använder kunskapsbasen i sina studier och arbete kommer att vara mycket tacksamma för dig.

Postat den http://www.allbest.ru/

Ministeriet för utbildning och vetenskap Ryska Federationen

Federal State Budgetary läroanstalt högre yrkesutbildning

Saint Petersburg State University of Technology and Design

Kursarbete

Efter disciplin: "Arkitektur av informationssystem"

Om ämnet: "Designa automatiserade informationssystem"

INTRODUKTION

För närvarande blir datortekniken mer och mer utbredd både i produktionen och i företagens arbetsflöde, och listan över uppgifter som omfattas av den blir bredare. Volymen och komplexiteten hos den information som bearbetas växer ständigt och nya typer av dess presentation krävs.

Här är bara några av fördelarna med att använda datorer för en organisation:

* Möjlighet till operativ kontroll över informationens riktighet;

* Minska antalet möjliga fel vid generering av härledd data;

* Möjlighet att snabbt komma åt data;

* Möjlighet att snabbt generera rapporter;

* Sparar arbetskostnader och tid åt informationsbehandling.

Alla dessa fördelar uppskattas för närvarande av många organisationer, därför pågår idag en process för snabb utveckling av automatiserade informationssystem och deras implementering i olika institutioners arbete. I detta avseende är ämnet jag har valt mycket relevant för närvarande.

Huvuddragen i industrin av automatiseringssystem för olika företag och institutioner, kännetecknade av ett brett spektrum av indata med olika vägar för behandling av dessa data, är koncentrationen av komplexitet i de inledande stadierna av kravanalys och utformning av systemspecifikationer med relativt låg komplexitet och mödosamhet i efterföljande steg. Det är faktiskt här som förståelsen för vad det framtida systemet kommer att göra, och hur det kommer att fungera för att uppfylla kraven för det, sker. Nämligen oklarhet och ofullständighet i systemkrav, olösta problem och misstag i analys- och designstadierna ger upphov till svåra, ofta olösliga problem i efterföljande stadier och leder i slutändan till att hela verket som helhet misslyckas. En enkel replikering av även ett mycket bra företagsledningssystem kommer aldrig att passa kunden helt, eftersom det inte kan ta hänsyn till dess specifika egenskaper. Dessutom uppstår i detta fall problemet med att välja exakt det system som är mest lämpligt för ett visst företag. Och detta problem kompliceras ytterligare av det faktum att sökorden som kännetecknar olika informationssystem är praktiskt taget desamma:

* Förenad informationsmiljö för företaget;

* Realtidsläge;

* Oberoende av lagstiftning;

* Integration med andra applikationer (inklusive system som redan finns i företaget);

* Etappvis implementering etc.

I själva verket har problemet med komplex automatisering blivit relevant för varje företag. Och för att göra komplex automatisering behöver du strukturerad kunskap inom detta område.

Syftet med detta arbete: Att bekanta sig med begreppet automatiserade informationssystem, att överväga designprocessen.

För att uppnå målet är det nödvändigt att lösa följande uppgifter:

§ Formulera definitioner av grundläggande begrepp och termer;

§ Tänk på designens mål och mål;

§ Bekanta dig med designens huvudstadier;

§ Markera faserna i utvecklingen av automatiserade informationssystem;

§ Tänk på sammansättningen och strukturen för det tekniska uppdraget och det tekniska projektet.

1. DEFINITION AV KONCEPT AUTOMATISKT INFORMATIONSSYSTEM (AIS), INFORMATIONSSYSTEM (IS), PROJEKT OCH DESIGN

När man strukturerar processer inom området mänsklig aktivitet används olika metoder för att isolera komponenter (delprocesser) och olika resultat erhålls, såsom forskning och utveckling, analys och syntes, etc.

Design är ganska acceptabelt att betrakta som ett generaliserande koncept för många intellektuella uppgifter som löses i tankeprocessen och utmärks på olika sätt.

Roten i orddesignen betonar sambandet mellan processen som har ett sådant namn och de viktigaste resultaten av denna process, enligt följande:

a) projektion - vad som erhålls genom att analysera komplexa fenomen för att få förenklade representationer, och

b) projekt - vad som erhålls genom att syntetisera komplexa representationer från en uppsättning enklare bilder.

Ovanstående två skäl tjänade som motivering för det nuvarande valet av orddesign som en term som betecknar kärnan i den huvudsakliga verksamheten som utförs inom datavetenskap.

I utformningen av informationssystem är informationssystem föremål för design, och detta är ganska naturligt för informatik (eftersom IS betraktas som huvudobjekt).

Som ni vet kan informationssystem i sig själva visa de mest olika fenomenen i universum, och därför visar sig alla fenomen också vara potentiella designobjekt.

Informationssystem visar sig i många fall vara föremål för design, d.v.s. de artister som utför själva designprocessen. Genom att studera designprocessen engagerar vi oss därmed i stor utsträckning i studier av informationssystem.

Ett system förstås som alla objekt som samtidigt betraktas både som en enda helhet och som en uppsättning heterogena element kombinerade för att uppnå de uppsatta målen. Systemen skiljer sig väsentligt från varandra både i sammansättning och i sina huvudmål.

Inom datavetenskap är begreppet ett system utbrett och har många semantiska betydelser. Oftast används det i förhållande till en uppsättning hårdvara och programvara. Tillägget till begreppet ordet informationssystem återspeglar syftet med dess skapande och funktion. Informationssystem tillhandahåller insamling, lagring, bearbetning, sökning och leverans av information som är nödvändig för att fatta beslut om problem från alla områden. De hjälper till att analysera problem och skapa nya produkter.

Informationssystem (IS) - en sammankopplad uppsättning verktyg, metoder och personal som används för att lagra, bearbeta och utfärda information för att uppnå målet.

Modern informationsteknik tillhandahåller ett brett utbud av IP -implementeringsmetoder, vars val är baserat på kraven från de avsedda användarna, som i regel förändras under utvecklingsprocessen.

Att lägga till termen "automatiserad" i begreppet "system" speglar sätten att skapa och fungera för ett sådant system.

Automatiserat system(enligt GOST) är ett system som består av en sammankopplad uppsättning organisatoriska enheter och en uppsättning aktiviteter automatiseringsverktyg som implementerar automatiserade funktioner för vissa typer aktiviteter.

Ett automatiserat informationssystem (AIS) är ett komplex av programvara, tekniska, informativa, språkliga, organisatoriska och tekniska verktyg och personal som är utformade för att lösa problemen med referens- och informationstjänster och (eller) informationsstöd för användare.

Ett automatiserat informationssystem är en samling information, ekonomiska och matematiska metoder och modeller, teknisk, mjukvara, tekniska verktyg och specialister som är utformade för att behandla information och fatta ledningsbeslut.

Huvudsyftet med automatiserade informationssystem är inte bara att samla in och spara elektroniska informationsresurser, utan också att ge användare tillgång till dem. En av de viktigaste funktionerna i AIS är organisationen av datahämtning i deras informationsarrayer (databaser).

Under AIS -projektet menar vi design och teknisk dokumentation, som ger en beskrivning av designlösningar för skapande och drift av IS i en specifik mjukvara och hårdvarumiljö.

Följande huvudsakliga särdrag hos projektet som ett förvaltningsobjekt kan särskiljas:

· Begränsat slutmål;

· Begränsad varaktighet;

· Begränsad budget;

· Begränsade resurser krävs;

· Nyhet för det företag som projektet genomförs för;

· Komplexitet;

· Juridiskt och organisatoriskt stöd.

Med tanke på projektplanering och förvaltning är det nödvändigt att tydligt förstå att vi talar om hantering av ett visst dynamiskt objekt. Därför måste projektledningssystemet vara tillräckligt flexibelt för att möjliggöra ändringar utan globala förändringar i arbetsprogram... Utförandet av arbeten säkerställs genom tillgången på nödvändiga resurser: material; Utrustning; personalavdelning. Ur teorin om styrsystem måste projektet som ett kontrollobjekt vara observerbart och kontrollerbart, det vill säga vissa egenskaper utmärker sig genom vilka det är möjligt att ständigt övervaka projektets framsteg. Dessutom behövs mekanismer för att påverka projektets framsteg i tid.

Utformningen av AIS förstås som processen för att konvertera ingångsinformation om ett objekt, metoder och erfarenhet av att designa objekt av liknande syfte i enlighet med GOST till ett IS -projekt.

Ur denna synvinkel reduceras utformningen av AIS till sekventiell formalisering av designlösningar i olika stadier av AIS -livscykeln: planering och analys av krav, teknisk och detaljerad design, implementering och drift av AIS.

Skalan på de system som utvecklas avgör sammansättningen och antalet deltagare i designprocessen. Med en stor volym och snäva deadlines för genomförandet av designarbete kan flera designteam (utvecklingsorganisationer) delta i utvecklingen av systemet. I det här fallet tilldelas moderorganisationen, som samordnar aktiviteterna för alla samverkande organisationer.

AIS designteknik är en uppsättning metodik och designverktyg för AIS, liksom metoder och medel för dess organisation (hantering av processen för att skapa och modernisera ett AIS -projekt).

Designtekniken är baserad på en teknisk process som bestämmer handlingarna, deras sekvens, erforderlig sammansättning av artister, medel och resurser.

Den tekniska processen för att designa AIS som helhet är uppdelad i en uppsättning sekventiellt parallella, anslutna och underordnade handlingskedjor, som var och en kan ha sitt eget ämne. Designtekniken bestäms således av en reglerad sekvens av tekniska operationer som utförs på grundval av en eller annan metod, vilket resulterar i att det blir tydligt inte bara vad som ska göras för att skapa ett projekt, utan också hur, av vem, och i vilken sekvens.

Föremålet för valfri designteknik bör vara reflektion av sammanhängande designprocesser i alla stadier av AIS -livscykeln. De viktigaste kraven för den valda designteknologin inkluderar följande:

· Det skapade projektet måste uppfylla kundens krav;

· Maximal reflektion av alla stadier av projektets livscykel;

· Säkerställa minimikostnaderna för arbetskraft och kostnader för design och projektstöd;

· Teknik bör ligga till grund för kommunikation mellan design och projektstöd.

· Ökad produktivitet hos designern;

· Tillförlitlighet för projektets utformning och drift;

· Enkelt underhåll av projektdokumentation.

AIS -designtekniken är baserad på den metodik som definierar essensen, de främsta särpräglade tekniska egenskaperna.

En designmetodik förutsätter närvaron av vissa koncept, designprinciper, implementerade med en uppsättning metoder, som i sin tur måste stödjas på något sätt.

Organiseringen av design innebär definition av metoder för interaktion mellan designers och med kunden i processen att skapa ett AIS -projekt, som också kan stödjas av en uppsättning specifika verktyg.

datorstött konstruktionsinformationssystem

2. DESIGNENS MÅL OCH MÅL

Att designa informationssystem börjar alltid med att definiera projektets mål. Syftet med designen är val av teknisk och bildande av information, matematisk, programvara och organisatoriskt och juridiskt stöd.

Valet av tekniskt stöd bör vara sådant att det säkerställs att insamling, registrering, överföring, lagring, fyllning och behandling av information sker i rätt tid.

Informationsstöd bör tillhandahålla skapande och drift av en enda informationsfond i systemet, representerad av en mängd olika informationsarrayer, en datamängd eller en databas.

Bildandet av det matematiska stödet för system inkluderar en komplett uppsättning metoder och algoritmer för att lösa funktionella problem. Vid utveckling av mjukvarusystem ägnas särskild uppmärksamhet åt skapandet av en uppsättning program och användarinstruktioner och val av effektiva mjukvaruprodukter.

Huvuduppgiften för alla framgångsrika projekt är att se till att vid start av systemet och under hela dess drift skulle det vara möjligt att säkerställa:

· Systemets erforderliga funktionalitet och graden av anpassning till de förändrade funktionsförhållandena;

· Den nödvändiga genomströmningen av systemet;

· Systemets erforderliga svarstid på begäran;

· Problemfri drift av systemet i önskat läge, med andra ord - systemets beredskap och tillgänglighet för att behandla användarförfrågningar;

· Lätt att använda och stödja systemet;

· Nödvändig säkerhet.

Prestanda är den viktigaste faktorn för systemeffektivitet. Bra design är grunden för ett högpresterande system.

Utformningen av automatiserade informationssystem täcker tre huvudområden:

· Design av dataobjekt som kommer att implementeras i databasen;

· Utforma program, skärmar, rapporter som säkerställer genomförandet av frågor till data;

· Med beaktande av en specifik miljö eller teknik, nämligen: nätverkstopologi, hårdvarukonfiguration, använd arkitektur (filserver eller klient-server), parallellbehandling, distribuerad databehandling, etc.

Under verkliga förhållanden är design en sökning efter en metod som uppfyller kraven för systemets funktionalitet med hjälp av tillgänglig teknik, med hänsyn till de givna begränsningarna.

Ett antal absoluta krav ställs på alla projekt, till exempel maximal projektutvecklingstid, maximal finansiell investering i projektet etc. En av svårigheterna med design är att det inte är en så strukturerad uppgift som att analysera kraven för ett projekt eller implementera en särskild designlösning.

3. STEG AV DESIGN

Processen att skapa AIS är uppdelad i ett antal steg (steg), begränsad av en viss tidsram och slutar med att en specifik produkt släpps.

Varje projekt, oavsett komplexitet och volym av arbete som krävs för dess genomförande, går igenom vissa stater i sin utveckling. Från staten när "projektet inte finns ännu" till staten när "projektet inte längre finns". Uppsättningen av utvecklingsstadier från uppkomsten av en idé till projektets fullständiga uppdelning brukar delas in i faser.

Syftet med de inledande stadierna för att skapa AIS, som utförs i analysstadiet av organisationens verksamhet, är att formulera krav för AIS som korrekt och exakt återspeglar målen och målen för kundorganisationen. För att specificera processen för att skapa en AIS som uppfyller organisationens behov är det nödvändigt att ta reda på och tydligt formulera vad dessa behov är. För att göra detta är det nödvändigt att fastställa kraven från kunderna för AIS och kartlägga dem på modellspråket till kraven för utvecklingen av AIS -projektet för att säkerställa att organisationens mål och mål följs.

Följande faser av utvecklingen av automatiserade informationssystem kan särskiljas:

3.1 Konceptets utformning. Konceptuell fas

Detta inkluderar:

· Idébildning;

· Bildande av ett nyckelprojektlag;

· Studera kundens och andra deltagares motiv och krav;

· Insamling av inledande data och analys av den befintliga staten;

· Fastställande av grundläggande krav och restriktioner, nödvändigt material, ekonomiska resurser och arbetskraftsresurser;

· Jämförande utvärdering av alternativ;

· Inlämning av förslag, granskning och godkännande.

Uppgiften att utforma kraven för AIS är en av de viktigaste, svåra att formalisera och den dyraste och svåra att korrigera vid fel. Med moderna verktyg och mjukvaruprodukter kan du snabbt skapa AIS enligt färdiga krav. Men ofta tillfredsställer dessa system inte kunderna, kräver många ändringar, vilket leder till en kraftig ökning av kostnaden för den faktiska kostnaden för AIS. Huvudorsaken till denna situation är felaktig, felaktig eller ofullständig definition av kraven för AIS i analysfasen.

3.2 Utarbetande av ett tekniskt förslag

§ utveckling av huvudinnehållet i projektets grundstruktur;

§ utveckling och godkännande av tekniska specifikationer;

§ planering, sönderdelning av projektets grundläggande strukturella modell;

§ upprätta uppskattningar och budget för projektet;

§ utveckling kalenderplaner och förstorade arbetsscheman;

§ teckna kontrakt med kunden;

§ sätta i drift projektdeltagarnas kommunikationsmedel och kontrollmedel över arbetets framsteg.

3.3 Design

I designfasen identifieras delsystem, deras samband och de mest effektiva sätten att projicera och använda resurser väljs ut. Typiska verk i denna fas:

§ utförande av grundläggande konstruktionsarbete;

§ utveckling av privata tekniska specifikationer;

§ implementering av konceptuell design;

§ utarbeta tekniska specifikationer och instruktioner;

§ presentation av designutveckling, granskning och godkännande.

I designstadiet bildas först datamodeller. Designers får analysresultat som input. Att bygga logiska och fysiska datamodeller är en väsentlig del av databasdesign. Informationsmodellen som erhållits under analysen omvandlas först till en logisk och sedan till en fysisk datamodell.

3.4 Utveckling

I utvecklingsfasen genomförs samordning och operativ kontroll av projektarbetet, delsystem tillverkas, kombineras och testas.

Efter att det autonoma testet har godkänts ingår modulen i den utvecklade delen av systemet och en grupp genererade moduler genomgår kommunikationstester, som ska spåra deras ömsesidiga inflytande.

Vidare testas en grupp moduler med avseende på driftsäkerhet, det vill säga de klarar för det första tester för att simulera systemfel och för det andra tester av driftstid mellan fel. Den första gruppen tester visar hur bra systemet återhämtar sig från programvarufel, maskinvarufel. Den andra gruppen tester bestämmer systemets stabilitet under normal drift och låter dig uppskatta systemets drifttid. Stabilitetsprovningen bör innehålla tester som simulerar toppbelastningen på systemet.

Sedan genomgår hela uppsättningen moduler ett systemtest - ett internt godkännandeprov av produkten, som visar kvaliteten på dess kvalitet. Detta inkluderar funktionstester och systemtillförlitlighetstester.

Det senaste automatiserade testet informationssystem- godkännandeprov. Ett sådant test innefattar att visa informationssystemet för kunden och måste innehålla en grupp tester som simulerar verkliga affärsprocesser.

3.5 Idrifttagning av systemet

I det skede då systemet tas i drift utförs tester, systemet testas under verkliga förhållanden, förhandlingar pågår om projektets resultat och om möjliga nya kontrakt.

Huvudtyper av arbete:

§ komplexa tester;

§ utbildning av personal för drift av systemet som skapas;

§ utarbetande av arbetsdokumentation, leverans av systemet till kunden och driftsättning;

§ ackompanjemang, support, service;

§ utvärdering av projektresultat och utarbetande av slutdokument.

4. SAMMANSÄTTNING OCH STRUKTUR FÖR TEKNISK DESIGN OCH TEKNISK DESIGN

1. Allmänna bestämmelser

1.1. Uppdragsvillkoren (TOR) är det huvudsakliga dokumentet som definierar kraven och proceduren för skapandet (utveckling eller modernisering - vidare skapande) av informationssystemet, i enlighet med vilket utvecklingen av IS genomförs och dess acceptans vid idrifttagande. .

1.2. TK är utvecklat för systemet som helhet, utformat för att fungera självständigt eller som en del av ett annat system.

1.3. Krav på IS i den volym som fastställts genom denna standard kan ingå i uppdraget för utformning av ett nyskapat informationsobjekt. I detta fall är TK inte utvecklat.

1.4. Krav som ingår i TK måste överensstämma med den nuvarande utvecklingsnivån informationsteknik och inte ge efter för liknande krav för de bästa moderna inhemska och utländska motsvarigheterna. Kraven i TK bör inte begränsa systemutvecklaren när det gäller att hitta och implementera de mest effektiva tekniska, tekniska, ekonomiska och andra lösningarna.

1.5. TK innehåller endast de krav som kompletterar kraven för system av denna typ och bestäms av detaljerna i ett visst objekt som systemet skapas för.

1.6. Ändringar i TK upprättas genom ett tillägg eller ett protokoll undertecknat av kunden och utvecklaren. Tillägget eller det angivna protokollet är en integrerad del av TK på IP. På TK: s titelsida bör det finnas en post "Gäller från ...".

2. Sammansättning och innehåll

2.1. TK innehåller följande avsnitt, som kan delas in i undersektioner:

1) allmän information;

2) syftet och målen med skapandet (utvecklingen) av systemet;

3) egenskaper hos föremål;

4) systemkrav;

5) sammansättning och innehåll i arbetet med skapandet av systemet;

6) förfarandet för kontroll och godkännande av systemet;

7) krav på sammansättning och innehåll i arbetet med att förbereda utvecklingsobjektet för att sätta systemet i drift;

8) krav på dokumentation;

9) utvecklingskällor.

TK kan inkludera applikationer.

2.2. Beroende på typ, syfte, specifika funktioner i projektet och villkoren för systemets funktion är det tillåtet att formalisera delar av TK i form av ansökningar, införa ytterligare, utesluta eller kombinera undersektioner av TK.

TK för delar av systemet inkluderar inte avsnitt som duplicerar innehållet i TK -sektionerna som helhet.

2.3. I avsnittet "Allmän information" anger du:

1) systemets fullständiga namn och dess symbol;

2) ämnets kod eller kontraktets kod (nummer);

3) namnet på företagen till utvecklaren och kund (användare) av systemet och deras uppgifter;

4) en förteckning över dokument på grundval av vilka systemet skapas, av vem och när dessa dokument godkändes;

5) planerade start- och slutdatum för skapandet av systemet;

6) information om källor och förfarande för finansiering av arbetet;

7) proceduren för registrering och presentation för kunden av resultaten av arbetet med skapandet av systemet (dess delar), om tillverkning och justering av individuella medel (hårdvara, programvara, information) och programvara och hårdvara (programvara och metodik ) komplex av systemet.

2.4. Avsnittet "Syfte och mål för skapande (utveckling) av systemet" består av undersektioner:

1) syftet med systemet;

2) syftet med att skapa systemet.

2.4.1. I underavsnittet "Syfte med systemet" anger du systemets typ av aktivitet (hantering, design, etc.) och listan över informationsobjekt (objekt) som det ska användas på.

2.4.2. I underavsnittet "Syftet med systemskapandet" anges namnen och erforderliga värdena för tekniska, tekniska, produktionsekonomiska eller andra indikatorer för informationsobjektet, som måste uppnås som ett resultat av skapandet av IS. , och kriterierna för bedömning av uppnåendet av målen för att skapa systemet anges.

2.5. I avsnittet "Egenskaper för föremålet för informatisering" anges:

1) kort information om föremålet för information eller länkar till dokument som innehåller sådan information;

2) information om driftsförhållandena för automatiseringsobjektet.

2.6. Avsnittet Systemkrav består av följande underavsnitt:

1) krav på systemet som helhet;

2) krav på de funktioner (uppgifter) som utförs av systemet;

3) krav på typer av säkerhet.

Sammansättningen av kraven för systemet, som ingår i detta avsnitt av TK för IS, fastställs beroende på typ, syfte, specifika egenskaper och villkor för ett visst systems funktion.

2.6.1. I avsnittet "Krav för systemet som helhet" anger du:

krav på systemets struktur och funktion;

krav på antalet och kvalifikationerna för personalen i systemet och arbetssättet;

destinationsindikatorer;

tillförlitlighetskrav;

säkerhetskrav;

krav på ergonomi och teknisk estetik;

krav för drift, underhåll, reparation och lagring av systemkomponenter;

krav på skydd av information från obehörig åtkomst;

krav på informationens säkerhet vid olyckor;

krav på skydd mot påverkan av yttre påverkan;

krav på patentrenhet;

krav på standardisering och enhetlighet;

Ytterligare krav.

2.6.1.1. Kraven för systemets struktur och funktion inkluderar:

1) en förteckning över delsystem, deras syfte och grundläggande egenskaper, krav för antalet hierarkiska nivåer och graden av centralisering av systemet.

2) krav på metoder och kommunikationsmedel för informationsutbyte mellan systemkomponenter;

3) krav på egenskaperna hos systemets sammankopplingar med angränsande system, krav på dess kompatibilitet, inklusive instruktioner om hur man utbyter information (automatiskt, genom att skicka dokument, via telefon, etc.);

4) krav på systemets driftsätt;

5) krav för diagnos av systemet;

6) utsikter för utveckling, modernisering av systemet.

2.6.1.2. Kraven på antal och kvalifikationer för IS -personal inkluderar:

§ krav på antalet personal (användare) av IS;

§ krav på personalens kvalifikationer, proceduren för deras utbildning och kontroll av kunskaper och färdigheter;

§ krävs arbetssätt för IS -personal.

2.6.1.3. I kraven för indikatorerna för IS: s syfte anges värdena för parametrarna som kännetecknar graden av systemets överensstämmelse med dess syfte.

2.6.1.4. Tillförlitlighetskrav inkluderar:

1) sammansättning och kvantitativa värden för tillförlitlighetsindikatorer för systemet som helhet eller dess delsystem;

2) en förteckning över nödsituationer för vilka tillförlitlighetskraven måste regleras och värdena för motsvarande indikatorer;

3) krav på maskinvarans och programvarans tillförlitlighet;

4) krav på metoder för att bedöma och övervaka tillförlitlighetsindikatorer i olika stadier av systemskapandet i enlighet med gällande reglerings- och tekniska dokument.

2.6.1.5. Säkerhetskraven inkluderar säkerhetskrav för leverans, idrifttagning, drift och underhåll av systemet.

2.6.1.6. Kraven på ergonomi och teknisk estetik inkluderar IP-indikatorer som ställer den erforderliga kvaliteten på interaktionen mellan människa och maskin och komforten i arbetsförhållandena för personal.

2.6.1.7. Kraven för att skydda information från obehörig åtkomst inkluderar de krav som industrin ställer och kundens informationsmiljö.

2.6.1.8. I kraven för informationssäkerhet ges en lista över händelser: olyckor, brister i tekniska medel (inklusive strömförlust), etc., där informationen i systemet måste säkerställas.

2.6.1.9. Kraven på patentrenhet anger en lista över länder för vilka patentets renhet i systemet och dess delar måste säkerställas.

2.6.1.10. Ytterligare krav inkluderar speciella krav efter eget gottfinnande av systemutvecklaren eller kunden.

2.6.2. I avsnittet "Krav för funktioner (uppgifter)" som utförs av systemet ges följande:

§ för varje delsystem, en lista över funktioner, uppgifter eller deras komplex (inklusive de som säkerställer interaktionen mellan delar av systemet) som ska automatiseras;

§ när du skapar ett system i två eller flera köer - en lista över funktionella delsystem, enskilda funktioner eller uppgifter som tas i drift i den första och efterföljande köerna;

§ tidsschema för genomförandet av varje funktion, uppgift (eller uppsättning uppgifter);

§ krav på kvaliteten på genomförandet av varje funktion (uppgift eller komplex av uppgifter), för form av presentation av utdatainformation, egenskaper hos erforderlig noggrannhet och körtid, krav för samtidig utförande av en grupp funktioner, tillförlitlighet för resultat;

§ lista och felkriterier för varje funktion, för vilka tillförlitlighetskrav ställs.

2.6.3. I underavsnittet "Krav för typer av stöd", beroende på systemtyp, ges krav på matematisk, informativ, språklig, mjukvara, teknisk, metrologisk, organisatorisk, metodisk och annan typ av systemstöd.

2.6.3.2. För informationsstöd för systemet ges följande krav:

1) till sammansättning, struktur och metoder för att organisera data i systemet;

2) informationsutbyte mellan systemets komponenter;

3) informationskompatibilitet med relaterade system;

4) om tillämpning av databashanteringssystem;

5) strukturen för processen att samla in, bearbeta, överföra data i systemet och presentera data;

6) till dataskydd;

7) kontroll, lagring, uppdatering och återställning av data;

2.6.3.3. För språkligt stöd för systemet ges krav för användning av programmeringsspråk på hög nivå i systemet, språk för interaktion mellan användare och systemets tekniska medel, samt krav för kodning och avkodning av data, för datainmatning-utdataspråk, språk för datamanipulation, medel för att beskriva ämnesområdet, för metoder för att organisera en dialog.

2.6.3.4. För systemets programvara ges en lista över köpt programvara samt kraven:

1) beroende av mjukvara på driftsmiljön;

2) till kvaliteten på programvaran, liksom till metoderna för dess tillhandahållande och kontroll;

2.6.3.5. För teknisk support av systemet ges följande krav:

1) till de typer av tekniska medel, inklusive till de typer av komplex av tekniska medel, programvara och hårdvarukomplex och andra komponenter, som är tillåtna för användning i systemet;

2) till funktionella, konstruktions- och driftskarakteristika för systemets tekniska support.

2.6.3.6. Kraven på metrologiskt stöd inkluderar:

1) en preliminär lista över mätkanaler;

2) krav på noggrannheten hos mätningar av parametrar och (eller) för mätkanalernas metrologiska egenskaper;

3) krav på metrologisk kompatibilitet för systemets tekniska medel;

4) en lista över systemets styr- och beräkningskanaler för vilka det är nödvändigt att utvärdera noggrannhetskarakteristika;

5) krav på metrologiskt stöd för hårdvara och mjukvara som ingår i systemets mätkanaler, medel, inbyggd styrning, metrologisk lämplighet för mätkanaler och mätinstrument som används vid installation och testning av systemet;

6) typ av metrologisk certifiering (stat eller avdelning) med en indikation på förfarandet för dess genomförande och de organisationer som utför certifieringen.

2.6.3.7. För organisationsstöd ges kraven:

1) struktur och funktioner för underavdelningar som deltar i systemets funktion eller tillhandahåller drift;

2) för organisationen av systemets funktion och interaktionsordningen mellan IS -personalen och personalen i informationsobjektet;

3) för att skydda mot felaktiga handlingar från systemets personal.

2.7. Avsnittet "Sammansättning och innehåll i arbetet med skapandet (utvecklingen) av systemet" måste innehålla en lista över stadier och stadier av arbetet med skapandet av systemet, tidpunkten för deras genomförande, en lista över organisationer - verkställare av arbetet , länkar till dokument som bekräftar samtycke från dessa organisationer för att delta i skapandet av systemet, eller en post som identifierar den person som är ansvarig (kund eller utvecklare) för att utföra dessa arbeten.

Detta avsnitt innehåller också:

1) en förteckning över dokument som presenteras i slutet av de relevanta stadierna och stadierna av arbetet.

2) typ och förfarande för granskning av teknisk dokumentation (steg, stadium, volymen av den kontrollerade dokumentationen, expertorganisation);

3) ett arbetsprogram som syftar till att säkerställa den pålitliga nivån för det system som utvecklas (om det behövs);

4) en lista över arbeten om metrologiskt stöd i alla stadier av skapandet av systemet, som anger deras tidsfrister och utför organisationer (om det behövs).

2.8. I avsnittet "Procedur för kontroll och acceptans av systemet" anger du:

1) system, sammansättning, omfattning och testmetoder för systemet och dess komponenter;

2) allmänna krav för acceptans av arbete i etapper, förfarande för samordning och godkännande av godkännandedokumentation;

2.9. I avsnittet "Krav på sammansättning och innehåll i arbetet med att förbereda automatiseringsobjektet för idrifttagning av systemet" är det nödvändigt att tillhandahålla en lista över huvudaktiviteterna och deras utförare, som bör utföras när projektet förbereds. för idrifttagning av IS.

Listan över huvudaktiviteter inkluderar:

1) införa informationen i systemet (i enlighet med kraven på information och språkligt stöd);

2) skapande av villkor för projektets funktion, enligt vilket det skapade systemets överensstämmelse med kraven i TOR garanteras;

3) skapande av underavdelningar och tjänster som är nödvändiga för systemets funktion;

4) tidpunkten och proceduren för bemanning och personalutbildning.

2.10. I avsnittet "Krav på dokumentation" anges följande:

1) en lista över uppsättningar och typer av dokument som ska utvecklas, som godkänts av utvecklaren och systemkunden;

2) en lista över dokument som utfärdats på maskinmedia;

3) i avsaknad av statliga standarder som bestämmer kraven för att dokumentera systemelement, inkludera dessutom krav på sammansättning och innehåll av sådana dokument.

2.11. I avsnittet "Utvecklingskällor" bör listas dokument och informationsmaterial på grundval av vilket TK utvecklades och som bör användas när systemet skapas.

3. Designregler.

3.1. Sektioner och undersektioner av TK bör placeras i den ordning som fastställs i avsnittet. 2 i denna standard.

3.2. Antalet ark (sidor) läggs ner, med början från det första bladet efter titelsidan, i den övre delen av arket (ovanför texten, i mitten) efter beteckningen av TK -koden på IP: n.

3.3. Titelsidan innehåller kundens, utvecklarens och godkännandeföretagens signaturer som är förseglade. Vid behov är titelbladet upprättat på flera sidor. Underskrifterna från TK -utvecklarna och tjänstemännen som deltar i godkännandet och behandlingen av utkastet till TK på undersökningsperioden finns på det sista bladet.

Formen för TK: s titelblad finns i bilaga 2. Formuläret för TK: s sista sida finns i bilaga 3.

3.4. Titelbladet till tillägget till TK är upprättat på samma sätt som titelbladet för det tekniska uppdraget. I stället för namnet "Referensvillkor" skriver de "Tilläggsnummer ... till TK för AC ...".

3.5. På de efterföljande arken av tillägget till TK placeras grunden för ändringen, innehållet i ändringen och länkar till dokumenten, i enlighet med vilka dessa ändringar görs.

3.6. När texten i ett tillägg till TK presenteras bör numren på de relevanta klausulerna, delklausulerna, tabellerna för huvud-TK, etc. anges och orden "ersätt", "komplettera", "utesluta", "omformuleras" " borde användas.

Förfarandet för utveckling, samordning och godkännande av TK för IS.

1. Utkastet till TK utvecklas av organisationsutvecklaren av systemet med deltagande av kunden på grundval av tekniska krav (applikationer, taktiska och tekniska specifikationer, etc.).

I den konkurrensutsatta organisationen av arbetet överväger alternativen för utkastet till TK av kunden, som antingen väljer det föredragna alternativet eller, på grundval av en jämförande analys, förbereder den slutliga versionen av TK för AC med deltagande av framtida IS -utvecklare.

2. Behovet av godkännande av utkastet till TK med de statliga övervakningsmyndigheterna och andra intresserade organisationer bestäms gemensamt av systemets kund och utvecklaren av utkastet till TK på IS,

Arbetet med att godkänna utkastet till TK för IC utförs gemensamt av utvecklaren av TK och systemkunden, var och en i organisationerna i sitt ministerium (avdelning).

3. Giltighetstiden för utkastet till TK i varje organisation bör inte överstiga 15 dagar från dagen för mottagandet. Det rekommenderas att skicka kopior av utkastet till TK (kopior) samtidigt till alla organisationer (avdelningar) för godkännande.

4. Kommentarer till utkastet till TOR bör lämnas in med en teknisk motivering. Beslut om kommentarer bör fattas av utvecklaren av TK -utkastet och systemkunden innan TK: n godkänner IS.

5. Om det uppstår meningsskiljaktigheter mellan utvecklaren och kunden (eller andra intresserade organisationer) när man kommer överens om utkastet till TK, då upprättas ett protokoll med oenigheter (godtycklig form) och ett specifikt beslut fattas i upprättad ordning.

6. Godkännandet av utkastet till TK får utarbeta ett separat dokument (brev). I det här fallet, under rubriken "Godkänt" gör en länk till detta dokument.

7. TK: s godkännande utförs av cheferna för företagen hos utvecklaren och systemkunden.

8. Kopior av den godkända TK: n inom 10 dagar efter godkännande skickas av utvecklaren av TK till deltagarna i skapandet av systemet.

9. Samordning och godkännande av tillägg till TK utförs på det sätt som fastställts för TK på IP.

10. Ändringar av TK får inte godkännas efter att systemet har lämnats in eller dess kö för godkännandeprov.

Grunden för utvecklingen av systemets tekniska projekt är det tekniska uppdrag som godkänts av kunden.

Den tekniska konstruktionen av systemet är teknisk dokumentation godkänd på föreskrivet sätt, som innehåller systemövergripande designlösningar, en algoritm för att lösa problem, samt en bedömning av den ekonomiska effektiviteten hos ett automatiserat styrsystem och en lista över åtgärder för att förbereda en objekt för implementering.

Det tekniska projektet utvecklas för att fastställa de viktigaste designlösningarna för skapandet av systemet. I detta skede utförs ett komplex av forskning och experimentellt arbete för att välja de bästa lösningarna, experimentell verifiering av huvuddesignlösningarna och beräkning av systemets ekonomiska effektivitet utförs.

Faktum är att det tekniska projektet innehåller ett komplex av ekonomiska, matematiska och algoritmiska modeller.

En komplett uppsättning teknisk design för systemet innehåller 10 dokument:

1. Förklarande anmärkning.

2. Systemets funktionella och organisatoriska struktur.

3. Problemmeddelande och lösningsalgoritm.

4. Organisation av informationsbasen.

5. Album med former av dokument.

6. Programvarusystem.

7. Principen att konstruera ett komplex av tekniska medel.

8. Beräkning av systemets ekonomiska effektivitet.

9. Åtgärder för att förbereda anläggningen för implementering av systemet.

10. Förteckning över dokument.

Från listan ovan utförs dokument 3 "Uttalande av uppgifter och algoritmen för lösning" för varje enskild uppgift som ingår i EIS, resten av dokumenten är gemensamma för hela systemet. Dessutom kan dokument 1, 2, 5, 8 och 9 utvecklas för enskilda delsystem.

Alla listade dokument kan grupperas och presenteras i form av fyra huvuddelar av ett tekniskt projekt: ekonomiska och organisatoriska, informativa, matematiska och tekniska.

Den ekonomiska och organisatoriska delen av det tekniska projektet innehåller en förklarande anmärkning som motiverar systemets utveckling, en lista över utvecklarorganisationer, en kort beskrivning av objektet som anger de viktigaste tekniska och ekonomiska indikatorerna för dess funktion och kopplingar till andra objekt, kort information om de viktigaste designlösningarna för systemets funktionella och stödjande delar.

I det avsnitt av det tekniska projektet, som ägnas åt systemets organisatoriska och funktionella struktur, ges följande: motivering för de tilldelade delsystemen, deras lista och syfte; en lista över uppgifter som ska lösas i varje delsystem, med en kort beskrivning av deras innehåll; ett diagram över informationslänkar mellan delsystem och mellan uppgifter inom varje delsystem.

För varje uppgift som ingår i uppsättningen prioriterade uppgifter utförs dess uttalande och algoritmen för att lösa den. Detta avsnitt av den tekniska designen inkluderar:

§ problemets organisatoriska och ekonomiska väsen (namn, syfte med lösningen, sammanfattning, metod, frekvens och tid för att lösa problemet, metoder för att samla in och överföra data, länka problemet med andra uppgifter, karaktären av att använda resultaten av lösningen där de används);

§ ekonomisk och matematisk modell av problemet (strukturell och detaljerad presentationsform);

§ inmatning av operativ information (indikatorers egenskaper, deras betydelse och förändringsintervall, presentationsformulär);

§ normativ referensinformation (NSI) - innehåll och presentationsformer;

§ information lagrad för kommunikation med andra uppgifter;

§ information som samlats in för efterföljande lösningar på detta problem;

§ information om ändringar (system för att göra ändringar och en lista med information som kan ändras);

§ algoritm för att lösa problemet (sekvens av beräkningssteg, diagram, beräkningsformler);

§ testfall (en uppsättning inmatningsdokumentformulär fyllda med data, villkorliga dokument med ackumulerad och lagrad information, utmatade dokumentformulär ifyllda baserat på resultaten av att lösa ett ekonomiskt och tekniskt problem och i enlighet med den utvecklade beräkningsalgoritmen).

Dokumentet "Beräkning av systemets ekonomiska effektivitet" innehåller en konsoliderad uppskattning av kostnaderna i samband med driften av systemen, beräkningen av den årliga ekonomiska effektiviteten tillhandahålls, vars källor är optimering av produktionsstrukturen för ekonomi (förening), minskning av produktionskostnaderna på grund av rationell användning av produktionsresurser och minskning av förluster, ledningsbeslut.

Dokumentet "Åtgärder för att förbereda anläggningen för systemets implementering" innehåller en lista över organisatoriska åtgärder för att förbättra den befintliga ledningsstrukturen, en lista över arbetet med implementeringen av systemet som måste utföras i steget med detaljerad design, vilket anger tidpunkten och ansvariga personer.

Den informativa delen av det tekniska projektet förenar dokument 4 och 5. Dokumentet "Organisation av informationsbasen" speglar: informationskällor och metoder för överföring för att lösa det primära komplexet av funktionella uppgifter; en uppsättning indikatorer som används i systemet; sammansättning av dokument, villkor och mottagningsfrekvens; grundläggande designlösningar för organisationen av NSI -fonden; NSI: s sammansättning, inklusive förteckningen över krav, deras definition, betydelse, ändringsintervall och listan över dokument från NSI; lista över datamängder med referensdata, deras volym, ordning och frekvens för informationskorrigering; förslag om enande av dokumentation, ett testfall för ändring av NSI; strukturell form av NSI med en beskrivning av förhållandet mellan elementen; krav på tekniken för att skapa och underhålla en fond; metoder för lagring, sökning, modifiering och kontroll, bestämning av volymer och informationsflöden för referensdata.

"Album med blanketter av dokument" innehåller former av referensdata.

Den matematiska delen av det tekniska projektet innehåller motiveringen för programvarans struktur, motiveringen för valet av programmeringssystem, inklusive listan över standardprogram.

Den tekniska delen av det tekniska projektet inkluderar: beskrivning och motivering av processdiagram för teknisk databehandling; motivering av krav för utveckling av icke-standardiserad utrustning; underbyggande och val av strukturen för komplexet av tekniska medel och dess funktionella grupper; en uppsättning åtgärder för att säkerställa tillförlitligheten hos tekniska medel.

SLUTSATS

Utvecklingen av ett informationssystem, som regel, utförs för ganska ett specifikt företag... Specifikationerna för företagets ämnesaktivitet påverkar naturligtvis informationssystemets struktur, men samtidigt liknar olika företags strukturer i allmänhet varandra. Varje organisation, oavsett dess typ av verksamhet, består av ett antal divisioner som direkt utför en eller annan typ av företagsaktivitet, och denna situation gäller för nästan alla organisationer, oavsett vilken typ av aktivitet de bedriver.

Införandet av modern informationsteknik gör att du kan minska den tid som krävs för att förbereda specifika marknadsförings- och produktionsprojekt, minska icke-produktiva kostnader under deras genomförande, eliminera risken för fel vid beredning av redovisning, teknisk och andra typer av dokumentation, vilket ger ett kommersiellt företag en direkt ekonomisk effekt.

Naturligtvis, för att avslöja alla möjliga möjligheter som användningen av datorer innebär, är det nödvändigt att i sitt arbete använda en uppsättning programvara och hårdvara som närmast matchar de uppsatta uppgifterna. Därför finns det för närvarande ett stort behov av kommersiella företag i datorprogram som stöder företagets ledning, samt information om hur man bäst utnyttjar företagets datorutrustning.

Implementering av AIS -design innebär att konstruktörer använder en viss designteknologi som motsvarar skalan och egenskaperna hos det projekt som utvecklas.

LISTA ÖVER ANVÄND LITTERATUR

1. Riktlinjer för studier av disciplinen "Automatiserade informationssystem" [Elektronisk resurs]. - Moskva, 2006. - Åtkomstläge:

http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Titel. från skärmen.

2. Wikipedia, den fria encyklopedin [Elektronisk resurs]/Artikel "Informationssystem" - Åtkomstläge: http://ru.wikipedia.org/wiki/Informationssystem.

3. Datapress: Internettidning. - Elektron. Dan. - [B.m., 2001]. - Åtkomstläge: http://compress.ru/article.aspx?id=12282.

4. Vendrov AM, "Designa programvara för ekonomiska informationssystem" / А.М. Vendra. - M.: "Finans och statistik", 2000. - 364 sid.

5. "Referensvillkor för skapandet av ett automatiserat system" / - M.: GOST 34.602-89, 1990.

6. Grekul V.I. "Designa informationssystem" / V.I. Grekul, G.N. Denischenko, N.L. Korovkin. - M.: Internet University of Information Technologies, 2008.

Publicerat på Allbest.ru

Liknande dokument

Utveckling av informationssystem. Modern marknad programvara för finansiell och ekonomisk tillämpning. Fördelar och nackdelar med att implementera automatiserade informationssystem. Metoder för att designa automatiserade informationssystem.

avhandling, tillagd 2015-11-22


Typer av automatiserade informationssystem. Utarbetande av tekniska specifikationer, utveckling av ett informationssystem, utarbetande av en användarmanual för programmet. Programmeringsverktyg för distribuerade informationsbehandlingssystem.

övningsrapport, tillagd 2016-04-16


Livscykel för automatiserade informationssystem. Grundläggande metoder för att utforma automatiserade system baserade på CASE -teknik. Fasen av analys och planering, konstruktion och implementering av ett automatiserat system. Vattenfall och spiral modell.

terminsrapport tillagd 2010-11-11


Begreppet informationssystem, typer av informationssystem. Analys av verktyg för utveckling av automatiserade informationssystem. Krav för programmet och mjukvaruprodukten. Utveckling av former för grafiskt gränssnitt och databaser.

avhandling, tillagd 23/06/2015


Principerna för att organisera ett system bestående av personal och en uppsättning verktyg för att automatisera sin verksamhet. Design av företagsautomatiserade informationssystem. Struktur, in- och utströmningar, begränsningar av automatiserade system.

presentation tillagd 14/10/2013


Informationssystem koncept. Stadier i utvecklingen av informationssystem. Processer i informationssystemet. Informationssystem för att hitta marknadsnischer, för att minska produktionskostnaderna. Informationssystemets struktur. Teknisk support.

abstrakt, tillagd 17/11/2011


Informationssystemets organisation, arkitektur och struktur. Indikatorer på hur effektivt hennes arbete är. Mål och mål för analysen av ACS. Komponenter i automatiserade system. Beskrivning av ämnesområdet, in- och utdata. Skapa ett användningsfallsschema.

term paper, tillagt 2014-04-11


Skapande och organisation av automatiserade informationssystem (AIS). Huvudkomponenter och tekniska processer i AIS. Etapper och stadier av skapandet av AIS från positionen som organisationens ledning. Utveckling av komplex av designlösningar för ett automatiserat system.

abstrakt, tillagd 18/10/2012


De viktigaste faktorerna som påverkar historien om utvecklingen av företagsautomatiserade informationssystem. Deras allmänna egenskaper och klassificering. Sammansättning och struktur för integrerad AIS. ERP -system som en modern typ av företagsinformationssystem.

presentation tillagd 14/10/2013


Analys av ämnesområdet, stadier av utformning av automatiserade informationssystem. Verktygssystem för mjukvaruutveckling. CASE-verktygs roll i utformningen av informationsmodellen. Den logiska modellen för den designade databasen.

Den 1 december 2015 ägde ett öppet försvar av Automated Project Management Information System (AIS PU) skapat genom order från Rysslands industri- och handelsministerium. I försvaret, under ledning av den första biträdande ministeren för industri och handel i Ryska federationen, Gleb Nikitin, deltog departementschefer i departementet, representanter för ministeriet för ekonomisk utveckling och Ryska federationens försvarsministerium.

Det automatiska projektledningssystemet är utformat för att förbättra effektiviteten hos Rysslands industri- och handelsministerium när det gäller stöd, underhåll och genomförande av projekt som bland annat syftar till importbyte, ökad export, teknisk utveckling av produktion, skapande och modernisering av högpresterande jobb och utveckling av industriell infrastruktur (industriparker, teknikparker, centra industriell design och teknik).

De huvudsakliga användarna av det skapade systemet, tillsammans med ledningen och anställda vid ministeriet som ansvarar för genomförandet av statliga program och federala målprogram, kommer att vara industriföretag som genomför sina egna investeringsprojekt, federala verkställande myndigheter som tillhandahåller statligt stöd till företag, banker, institutionella investerare och andra finansinstitut som deltar i finansiering av investeringsprojekt för industriföretag och projekt för utveckling av industriell infrastruktur.

Systemet skapades av den ryska systemintegratören "Inline-Technologies" med deltagande av den inhemska mjukvaruutvecklaren "LM-Soft". AIS PU utvecklades på grundval av den ryska 1C -plattformen med fri programvara och mjukvara av egen design.

Baserat på resultaten av att studera systemets funktionalitet, fick positiv feedback både från ledningen och anställda vid ministeriet för industri och handel och från ministeriet för ekonomisk utveckling, som ansvarar för genomförandet av projektledningsmekanismer i regeringen kroppar. Dessutom gavs positiv feedback om AIS PU: s kapacitet från industriföretag som presenterade sina pilotprojekt som en del av utvecklingen av systemet. I synnerhet gav representanter för Krylov State Scientific Center, JSC Scientific and Production Corporation Uralvagonzavod och Federal State Enterprise Scientific Research Institute Geodesy positiv feedback om pilotoperationen av AIS PU. Det bör också noteras att representanter för Garrison JSC, som ligger under försvarsministeriets jurisdiktion, liksom representanter för vissa banker med statligt deltagande, visade stort intresse för systemet och intresse för gemensamt samarbete vid genomförandet av projektledning .

”Det skapade projektledningssystemet kommer inte bara att öka effektiviteten hos ministeriets anställda, utan det kommer också att göra det möjligt att organisera effektiv interaktion med deltagare i industriprojekt från industriföretag, statliga organ och utvecklingsinstitutioner och finansinstitut. AIS PU arbetar efter principen om ett ”enda fönster” med maximal användning av elektronisk dokumenthanteringsteknik ”, kommenterade Sergey Valuev, chef för avdelningen för informationsteknologi och PR vid ministeriet för industri och handel om genomförandet av systemet.

”Huvudmålet med att införa AIS PU är att förbättra kvaliteten på kontroll och hanterbarhet, att underlätta interaktion mellan myndigheter och utförare av storskaliga projekt. Vid utvecklingen av systemet togs först och främst hänsyn till branschstandarder, förordningar och order från regeringen, presidentens förordningar och order från industri- och handelsministern samt de bästa inhemska och utländska sedvänjorna. Mer än 600 komponenter har utformats för AIS PU, mer än 20 000 referensböcker, ordböcker och klassificerare har laddats upp. Som en del av det fortsatta arbetet med utvecklingen av AIS PU är det planerat att integrera systemet som ett av delsystemen i det statliga informationssystemet för industrin som för närvarande skapas av Rysslands industri- och handelsministerium, säger Sergey Valuev.

Införandet av projektledningsmetoder definieras som ett av de viktigaste verktygen för modernisering av den offentliga förvaltningen och är förankrad i den nya upplagan av "Huvudinriktningar för verksamheten för Ryska federationens regering för perioden fram till 2018", undertecknad av Prime Minister Dmitrij Medvedev.