Organisatsiooni infosüsteemi moodul. Ettevõtte infosüsteemide integreerimine. Ettevõtte infosüsteemi funktsionaalsed ülesanded ja kaasaegsete ettevõtte infosüsteemide põhimoodulid. moodulite integreerimine

Tööjaamad tuleb automatiseerida

Jõudlusnõuded

Loodud aruannete loend

4.4.2. Nõuded tootmise planeerimise ja kontrolli süsteemile

Infosüsteem peaks tagama ettevõtte ressursside planeerimise ja tellimuste tootmise juhtimise.

Nõuded IS-i funktsionaalsusele:

1. Valmistoodete konfiguratsioonihaldus (FP):

Normatiivse ja viiteinformatsiooni säilitamine perearsti koosseisu kohta koos võimalusega näidata spetsifikaadi asjakohasuse perioodi ja võimalusega olla mitme erineva spetsifikatsiooniga perearsti tootmises;

GP osaks olevate toodete tootmistehnoloogia normi- ja referentsteabe säilitamine oskusega näidata tehnoloogiate asjakohasuse perioodi ja võimalusega olla mitme erineva tehnoloogiaga GP tootmises;

2. Müügijuhtimine:

Kliendisuhete ajaloo vaatamine;

Kliendi avalduse registreerimine/parandus koos riigiettevõtete nimekirja, mahtude, tarnekuupäeva, müügihinna ja võimalike lisatingimuste äranäitamisega;

Vaata tellitud riigiettevõtte jooksvaid majandusnäitajaid (kuluprognoose);

3. Tootmise planeerimine:

Seadmete olemasolu ajakava koostamine, mis näitab vabade normtundide arvu planeeritud perioodi iga päeva kohta;

Tootmisplaani koostamine, kus on märgitud valmistatav toode, selle kogus, kasutatud seadmed, jaotused planeerimisperioodi igaks päevaks;

Materjalide ja komponentide tootmisnõuete plaani koostamine;

Seadmete laadimise kontroll ja juhtimine vastavalt moodustatud tootmisplaanile;

Tootmisplaani muudatuste tegemine selle täitmise ajal;

Tootmisplaani plaan-faktide analüüs;

4. Tootmise juhtimine:

Vahetustega tööülesannete (tellimuste) vormistamine toodete valmistamiseks;



Esitajate tellimustele määramine / ümberjaotamine ja tellimuste täitmise fikseerimine koos valmistatud toodete arvu, defektsete toodete arvu ja abielu sõlmimise põhjustega;

Laokaupade (kaubad ja materjalid) ladustamise ja liikumise juhtimine tootmises;

5. Tarnehaldus:

Ostutellimuse vormistamine lähtudes materjalide ja komponentide vajaduse plaanist, näidates ära tarnija, kaupade ja materjalide nomenklatuuri, koguse ja tarneaja;

Ostutellimuste vormistamine osakondade kaupade ja materjalide ühekordsete tellimuste alusel;

Ostutellimuste täitmise protsessi kontrollimine ja jälgimine;

Jääkide operatiivne kontroll;

Tarnete plaani-faktide analüüs;

6. Kulude juhtimine:

Riigiettevõtte planeeritava (standard)maksumuse kujundamine;

Tegelike tootmiskulude fikseerimine;

Riigiettevõtte tegeliku maksumuse arvutamine;

Plaani-tegelike kulude analüüs.

Tellimuse standardmaksumuse arvutamise nõuded

Toote ja kogu tellimuse standardmaksumus arvutatakse järgmiselt:

1. Toote standardmaksumuse otsene materjalikomponent moodustatakse selle toote standardkoostise (spetsifikaadi) ja käesolevas spetsifikatsioonis sisalduvate laoartiklite arvestuslike hindade kohta saadud teabe alusel. Spetsifikatsiooniks on lubatud kasutada mitmeid materjalikulu artikleid.

2. Otsepalga suurus arvutatakse toote standardse tegevuskoosseisu alusel. Täpsustatud: iga toimingu standardkestus, selle toimingu jaoks nõutav töötaja elukutse, samuti töötaja kategooria. Samuti kehtestab süsteem töötajate elukutsete ja nende kategooriate normtundide rahalised määrad.

3. Kaudsete kulude normväärtus arvutatakse protsendina määratud baasist (otseste kulude summa nimetatud kirje kohta).



Selle arvutuse tegemiseks peavad infosüsteemis olema kättesaadavad järgmised andmed:

1. Toote valmistamise spetsifikatsioon (samuti kõigi selle tootega hõlmatud meie enda toodangu pooltoodete valmistamise spetsifikatsioon);

2. Toote ja sellesse kuuluvate pooltoodete valmistamise tehnoloogia: milliseid toiminguid teha ja mis aja jooksul. Lisaks määratakse iga toimingu jaoks kindlaks töötaja elukutse ja kategooria, mis on selle rakendamiseks vajalikud (selle konkreetse toote vabastamiseks);

3. Kasutatud kaupade ja materjalide arvestushindade protokoll;

4. Kutsealade ja ametiastmete normtundide rahalised määrad.

Nõuded tellimuse tegeliku maksumuse arvutamiseks

Toote ja kogu tellimuse tegelik maksumus arvutatakse järgmiselt:

1. Toote väljastamise otsesed materjalikulud arvutatakse tsehhi materjalide maksumuse tegelike andmete alusel toodangu ümberjaotamiseks. Sel juhul arvutatakse esmalt kõigi selle tootega hõlmatud pooltoodete maksumus. Koguhindamine viiakse läbi ettevõtte arvestuspoliitikas omaks võetud metoodika kohaselt.

2. Otseste tootmistööliste töötasu arvutatakse kaupluste tellimuste sulgemise andmete alusel. Juhul, kui IS-is tellimuste arvestust ei peeta, viitab töötasu jaotamisele kuuluvatele otsestele kuludele, s.o. jaotatakse valmistatud toodete vahel vastavalt teatud baasile.

3. Otseste tootmisseadmete amortisatsioon arvatakse otseste kulude hulka, kui iga ümberjaotuse puhul on märgitud sellel ümberjaotamisel kasutatud seadmed (tööpingid).

4. Jaotatavad otsesed kulud:

Põhimaterjale tarbitakse harvemini kui iga ümberjaotamise korral (näiteks kemikaalid, mille kulu toodanguühiku kohta on nii väike, et nende vahelduvat tarbimist pole mõtet isegi sellise kiirusega arvestada);

Töötajate palgad, kui puudub teave nende jaotuse kohta käibe järgi;

Otsese seadmete amortisatsioon, kui saadaval on ainult selle igakuine kogusumma, ilma ümberjaotamiseta.

Sellised kulud jaotatakse toodetavatele esemetele vastavalt valitud turustusbaasile (näiteks proportsionaalselt otseste materjalikuludega).

1. Üldised tootmiskulud (konto 25 BU): jaotatakse toodetud toodetele proportsionaalselt valitud turustusbaasiga. Nende kulude osa võib, kuid ei pruugi jääda lõpetamata toodangu hulka vastavalt ettevõttes vastuvõetud arvestuspõhimõttele.

2. Üldised tegevus- ja müügikulud (kontod 26 ja 44) kajastatakse jooksva perioodi kuluna ja on seotud müügikuludega. Selliste kulude jaotust valmistoodete maksumusele saab näha spetsiaalse aruande abil.

Infosüsteemi jõudlusnõuded

<Раздел должен содержать требования к производительности Информационной системы. Вводится в шаблон>.

Usaldusväärsuse nõuded

<Раздел должен содержать требования к надежности Информационной системы. Например:>

Nõuded Infosüsteemi usaldusväärse (stabiilse) toimimise tagamiseks

Infosüsteemi töökindel (stabiilne) toimimine peab olema tagatud kliendi poolt organisatsiooniliste ja tehniliste meetmete kogumi rakendamisega, mille loetelu on toodud allpool:

1. Tehniliste seadmete katkematu toitevarustuse korraldamine;

2. Litsentsitud tarkvara kasutamine;

3. Regulaarne täitmine Tööministeeriumi soovitused ja sotsiaalne areng RF, mis on sätestatud 23. juuli 1998. aasta dekreedis "Personaalarvutite ja kontoriseadmete hoolduse ning tarkvara hooldamisega seotud tööstusharudevaheliste standardajanormide kinnitamise kohta";

4. GOST 51188-98 nõuete regulaarne täitmine. "Andmekaitse. Tarkvara saadavuse testimine arvutiviirused»;

5. Infosüsteemi andmekogude regulaarne varundamine Infosüsteemi enda või kasutatud andmekogude haldussüsteemi abil.

Sissejuhatus

Kõnealune lõputöö on kirjutatud Donetsk OJSC Donetsk Manufactory baasil Cleonelly kaupluse jaoks.

Donetsk Manufactory OJSC üks juhtivaid tegevusalasid toodab laias valikus rõivaid, peamiselt hommikumantleid, linasid ja rätikuid. Lisaks toodab ettevõte värvitud puuvillast lõnga kudumiseks ja kudumiseks.

Automatiseeritud infotehnoloogia areng käib käsikäes uut tüüpi tehniliste vahendite tekkimisega teabe töötlemiseks ja edastamiseks, arvutite kasutamise organisatsiooniliste vormide täiustamisega, infrastruktuuri küllastamisega uute sidevahenditega. Turusuhete areng on toonud kaasa uut tüüpi ettevõtlustegevuse tekkimise ja ennekõike infoäriga tegelevate ettevõtete loomise, infotehnoloogiate arendamise, nende täiustamise, automatiseeritud infotehnoloogia komponentide leviku, eelkõige tarkvaratooted, mis automatiseerivad teavet ja andmetöötlusprotsesse. Nende hulka kuuluvad ka arvutusseadmed, side, kontoritehnika ja teatud tüüpi teenused – teabe-, tehnilised ja nõustamisteenused, koolitus jne. See aitas kaasa infotehnoloogiate kiirele levikule ja tõhusale kasutamisele juhtimis- ja tootmisprotsessides, peaaegu nende laialdasele kasutamisele ja suurele mitmekesisusele.

Erinevatel eesmärkidel seadmete projekteerimise ja arendamisega tegelevad ettevõtted kasutavad praegu laialdaselt nii arvutipõhise projekteerimise - CAD (CAD) kui ka tootmisprotsesside jälgimise - ACS (SCADA / DCS) erinevaid vahendeid. Meie enda disainitud seadmete jaoks on aga vaja välja töötada oma vahendid nende toimivuse jälgimiseks ja tootekvaliteedi analüüsimiseks.

Cleanelly kaupluses laos olevate toodete arvestuse tehnoloogiline protsess sisaldab endas müüdud toodete üle arvestuse pidamise etappi.

Selle diplomitöö eesmärgiks on automatiseeritud tööjaama (AWP) juurutamine, mis võimaldab jälgida kaupluse laos olevaid tooteid.

Ülaltoodud eesmärgi saavutamiseks on vaja lahendada järgmised ülesanded:

¾ analüüsida kaupluse äriprotsesse;

¾ uurida infovooge, mis tekivad arendatava toote tarnimise etapis;

¾ arendada kontseptuaalseid ja loogilisi andmemudeleid;

¾ areneda tarkvara tootmisarvestuse AWP jaoks

¾ hinnata infosüsteemi majanduslikku efektiivsust.

1 Tarkvaranõuete väljatöötamine

1.1 Olemasolevate lahenduste analüüs

Praegu on suur hulk ettevõtteid, mis ühendavad nii otsese tootearenduse kui ka nende toodete juhtimissüsteemide arendamise. Selliseid süsteeme arendavad sellised tuntud ettevõtted nagu 1: C Enterprise ja Zvezda. Sellistes süsteemides toimub materjalide kontroll ja arvestus ning saadud teabe töötlemine.

"1C: Enterprise" on rakenduslike lahenduste süsteem, mis on üles ehitatud samadel põhimõtetel ja ühel tehnoloogilisel platvormil. Juht saab valida lahenduse, mis vastab ettevõtte hetkevajadustele ja areneb edasi ettevõtte kasvades või automatiseerimisülesannete laienedes.

Tarkvarasüsteem 1C: Enterprise on loodud lahendama paljusid raamatupidamise ja juhtimise automatiseerimise probleeme, millega seisavad silmitsi dünaamiliselt arenevad kaasaegsed ettevõtted. Kiireloomuliste raamatupidamis- ja juhtimisprobleemide lahendamine Süsteemi 1C: Enterprise programmide koosseis on keskendunud ettevõtete tegelikele vajadustele. Firma "1C" toodab jadatarkvaralahendusi, mis on loodud ettevõtete tavaliste raamatupidamis- ja juhtimisülesannete automatiseerimiseks. 1C väljaande lahenduste eripäraks on standardlahendustes sisalduvate funktsionaalsuste koostise põhjalik uurimine. Firma "1C" analüüsib süsteemi "1C: Enterprise" programme kasutavate kasutajate kogemusi ja jälgib muutusi nende vajadustes.

Minu hulgimüügi baasi süsteemi peamised eelised hõlmavad suhteliselt madalaid juurutamiskulusid see süsteem ja ka mitmeid muid eeliseid:

¾ Loodud rakenduste töökindlus. Tarkvarapakett (PC) peab olema vastupidav mitte ainult kasutaja vigadele, vaid ka riketele sidesüsteemis.

¾ liidese kasutusmugavus;

¾ Süsteemi kõrge turvalisuse tase, mis ei tähenda mitte ainult teatud süsteemiressursside kättesaadavuse ja teabeturbe kontrollimist kõigil tööetappidel, vaid ka teostatud toimingute jälgimist suure usaldusväärsusega.

1.2 Domeeni analüüs

Ainevaldkonna analüüsi eripära on see, et see võimaldab näha kogu organisatsiooni toimingute komplekti.

CASE on mõeldud äriprotsesside analüüsimiseks ja ümberkorraldamiseks. – Kõik Fusion Process Modeler (BPwin) tipptasemel tööriist, mis toetab IDEF0 (funktsionaalne mudel), DFD (Dataflow Diagram) ja IDEF3 (Workflow Diagram) metoodikaid. BPwin on võimas tarkvaratoode mudelite loomiseks keerukates äriprotsessides toimuvate muudatuste analüüsimiseks, dokumenteerimiseks ja planeerimiseks. BPwin pakub tööriista kogu vajaliku teabe kogumiseks ettevõtte toimimise ja graafiline pilt see teave sidusa ja järjepideva mudeli kujul.

Süsteemi funktsionaalsuse osas. IDEF0 (Integration Definition for Function Modeling) metoodika raames on äriprotsess kujutatud tööelementide kogumina, mis omavahel interakteeruvad ning näidatakse iga töö poolt tarbitavat informatsiooni, inim- ja tootmisressursse. Funktsionaalne mudel on loodud kirjeldama ettevõttes olemasolevaid äriprotsesse (nn AS-IS mudel) ja ideaalset asjade seisu. – mille poole püüelda (TO-BE mudel). IDEF0 metoodika näeb ette diagrammide hierarhilise süsteemi ehitamise, s.o. süsteemi fragmentide üksikud kirjeldused. Esiteks kirjeldatakse süsteemi kui tervikut ja selle interaktsiooni välismaailmaga (kontekstidiagramm), mille järel viiakse läbi funktsionaalne lagunemine – süsteem on jagatud alamsüsteemideks ja iga süsteemi kirjeldatakse eraldi (dekomposiitdiagrammid). Seejärel jagatakse iga alamsüsteem väiksemateks ja nii edasi, et saavutada soovitud detailsusaste.

Kui modelleerimise käigus on vaja esile tuua ettevõtte tehnoloogia spetsiifilised aspektid, võimaldab BPwin lülituda mudeli mis tahes harule DFD või IDEF3 tähistusele. Andmevoo diagrammi (DFD) diagrammid võivad täiendada IDEF3 mudelis juba kajastatut, kuna need kirjeldavad andmevooge, võimaldades teil jälgida, kuidas süsteemis ärifunktsioonide vahel teavet vahetatakse. Samal ajal eiravad DFD diagrammid ärifunktsioonide vahelisi koostoimeid.

Tehtavate tööde järjestuse poolest. Ja veelgi täpsema pildi saab, kui täiendada mudelit IDEF3 diagrammidega. See meetod juhib tähelepanu sündmuste teostamise järjekorrale. Loogika elemendid sisalduvad IDEF3-s, mis võimaldab modelleerida ja analüüsida alternatiivseid stsenaariume äriprotsesside arendamiseks.

Kaupluse laos jooksvate äriprotsesside arvestamiseks on vaja kasutada ainult kahte metoodikat IDEF0 ja DFD. Süsteemi modelleerimise protsess IDEF0-s algab konteksti määratlemisest, st. süsteemi või äriprotsesside üldisemalt kirjeldamise abstraktseim tase.

Mudel IDEF0... Äriprotsesside "Tarnija tellimuse vormistamine", "Kauba vastuvõtmine", "Kauba väljastamine" uurimiseks kaaluge diagramme, mis on esitatud IDEF0 diagrammi kujul. IDEF0 süsteem on esitatud interakteeruvate tegevuste või funktsioonide kogumina.

IDEF0 metoodika põhineb neljal põhikontseptsioonil.

Esimene on kontseptsioon funktsionaalne blokk (Tegevuskast)... Funktsionaalplokk on graafiliselt kujutatud ristküliku kujul ja personifitseerib mõnda konkreetset funktsiooni vaadeldava süsteemi raames

Funktsionaalploki igal neljal küljel on oma konkreetne tähendus (roll), samas kui:

Ülemine pool on Control;

Vasak pool on seatud sisendiks;

Parem pool omab väärtust "Väljund";

Alumine külg on seatud mehhanismile.

IDEF0 metoodika teine ​​"vaal" on liidese kaare (nool) kontseptsioon. Liidese kaare graafiline kuva on ühesuunaline nool. Igal liidesekaarel peab olema oma nimi (Arrow Label). Liideskaarte abil kuvatakse erinevaid objekte, mis ühel või teisel määral määravad süsteemis toimuvad protsessid. Sel juhul jagatakse nooled sõltuvalt sellest, millisele tööristküliku küljele nad sisenevad või millisest küljest lahkuvad:

Sisendnooled (sisalduvad funktsionaalploki vasakus servas) - tähistavad andmeid või objekte, mida töö teostamise käigus muudetakse;

Juhtnooled (sisalduvad funktsionaalse ploki ülaosas) - kujutavad reegleid ja piiranguid, millest tulenevalt tööd tehakse;

Väljunooled (väljumine funktsionaalse ploki paremalt küljelt) - tähistavad andmeid või objekte, mis ilmuvad töö tulemusena;

Mehhanismi nooled (sisalduvad funktsionaalse ploki alumisse serva) - tähistavad ressursse (näiteks seadmed, inimressursid).

IDEF0 standardi kolmas põhikontseptsioon on lagunemine. Lagundamise põhimõtet kasutatakse keeruka protsessi jaotamisel selle koostisosadeks.

Dekomponeerimine võimaldab süsteemimudelit järk-järgult ja struktureeritult esitada üksikute diagrammide hierarhilise struktuuri kujul, mis muudab selle vähem ülekoormatuks ja kergesti seeditavaks.

IDEF0 viimane kontseptsioon on sõnastik. Iga IDEF0 elemendi jaoks: diagrammid, funktsionaalsed plokid, liidese kaared, eeldab olemasolev standard asjakohaste definitsioonide, märksõnade, narratiivide jms komplekti loomist ja hooldamist, mis iseloomustavad selle elemendiga kuvatavat objekti. Seda komplekti nimetatakse sõnastikuks ja see kirjeldab selle elemendi olemust.

Mõelge OJSC DMM-i poe "Cleonelly" laos toimuvate äriprotsesside skeemidele:

Süsteemi üldiseks nähtavaks tegemiseks on vaja ehitada kontekst "Ettevõtte laotegevus" (vt joonis 1.1).

Joonis 1.1 - Diagramm "Ettevõtte laotegevus"

Pärast konteksti kindlakstegemist viiakse läbi lagunemine, s.o. koostades hierarhias järgmised diagrammid.

Iga järgmine diagramm on rohkem Täpsem kirjeldusüks ülaltoodud diagrammi töödest. Kontekstuaalse töö dekomponeerimise näide on toodud joonisel 1.2. Seega on kogu süsteem jagatud soovitud detailsusastmeni alamsüsteemideks, see süsteem on jagatud kolmeks tasandiks.

Joonis 1.2 – Esimese taseme lagunemise diagrammid


Joonis 1.3 – diagramm "Kauba vormistamine"

Joonis 1.4 – diagramm "Kauba probleem"


Joonis 1.5 - diagramm "Kauba postitamine"

DFD. See metoodika põhineb analüüsitava IS-i mudeli konstrueerimisel – projekteeritud või tegelikult olemasolevast. Vastavalt metoodikale on süsteemimudel määratletud kui andmevoo diagrammide (DFD) hierarhia, mis kirjeldab teabe asünkroonset teisendamist süsteemi sisendist selle kasutajale väljundisse. DFD diagrammid koostatakse tavaliselt organisatsiooni töövoosüsteemi praeguse töö visualiseerimiseks. Kõige sagedamini kasutatakse DFD diagramme IDEF0-s rakendatud äriprotsessimudeli täiendamiseks.

Andmevoo diagrammi põhikomponendid on järgmised:

Välised olemid (graafiliselt kujutatud ruuduna) – tähistavad materiaalset objekti või individuaalne, mis on teabe allikas või vastuvõtja. Näiteks: kliendid, personal, tarnijad, kliendid, ladu;

Süsteemid / alamsüsteemid (graafiliselt näeb välja nagu ümarate nurkadega ristkülik) - tööd, mis tähistavad funktsioone või protsesse, mis töötlevad ja muudavad teavet;

Andmesalvestusseadmed on abstraktne teabe salvestamise seade, mida saab igal ajal salvestusseadmesse panna ja mõne aja pärast taastada ning selle paigutamiseks ja hankimiseks võib olla mis tahes viise. Üldjuhul on andmesalv tulevase andmebaasi prototüüp ja sinna salvestatud andmete kirjeldus tuleks siduda infomudeliga;

Andmevood – määratleb teatud ühenduse kaudu allikast vastuvõtjasse edastatava teabe. Andmevoogu diagrammil kujutab joon, mis lõpeb noolega, mis näitab voo suunda.

Vaatleme probleemi andmevoo diagrammi (DFD) Joonis 1.6. See diagramm näitab dokumentide liikumist, kui organisatsiooni saabub "tootetaotlus".

Joonis 1.6 – DFD "Kauba väljastamise" diagramm

Mõelge järgmisele andmevooskeemile "Toote kliirens" (vt joonis 1.7). See näitab tööde teostamise protsessi ja dokumentide liikumist "kauba väljastamise" ajal.

Joonis 1.7 – DFD diagramm "Kauba vormistamine"

Andmevoo diagrammides annavad kõik kasutatavad sümbolid kokku suure pildi, mis annab selge ettekujutuse, milliseid andmeid kasutatakse ja milliseid funktsioone töövoosüsteem täidab. Samas selgub sageli, et olemasolevad ettevõtte tegevuseks olulised infovood ei rakendu usaldusväärselt ja vajavad ümberkorraldamist ******

Froteetooteid müüva ettevõtte organisatsioonilist struktuuri vaadeldakse Cleonelly poe ettevõtte OJSC “Donetsk Manufactura M” näitel:

Juhtimissüsteemide arendamise ja materjalide arvestuse suunas saavad nad edukalt lahendada probleeme:

1. See on kontroll tarnitud ja ladustatud kauba üle.

2. Teave tarnijate ja tarbijate kohta

3. See sisaldab ka teavet toote kohta ja toiminguid

4. Sisaldab väljastatud kauba aruande logi

5. Sisaldab kaupade kataloogi

6. Laofunktsioonide automatiseerimine (vastuvõtt, tarbimine, mahakandmine, kauba broneerimine)

7. Ostetud ja müüdud kaupade ja teenuste arvete registreerimine ja säilitamine, samuti ettemaksu, makse edasilükkamise ja kauba kohaletoimetamise arveldamine

8. Arvete koostamine ja väljastatud kaupade arvestus

9. Ladude inventuuri läbiviimine koos võrdluslehe, puuduse ja ülejäägi akti koostamisega

10. Kaubakomplektide koostamine

Nagu märgitud, on selle ettevõtte põhitegevusalaks puuvillatoodete müük. Projekteerimisprotsess hõlmab mitmeid etappe, mis on disainiettevõtete juhtimisstruktuuride poolt kogu elutsükli jooksul hoolikalt läbi töötatud. sellest ettevõttest. See protsess ei saa korraga muuta, kuna see hõlmab paljusid ettevõtte enda osakondi, väliseid alltöövõtjaid ja projektettevõtte kliente. Seetõttu on ettevõtted projekteerimis- ja arendusjuhtimisprotsessidega seotud infosüsteemide juurutamise suhtes ettevaatlikud. Reeglina kasutavad Venemaa ettevõtted selles valdkonnas oma arendusi.

1.3 Nõuete kogumine

"Hulgipoe tööjaama" infosüsteemi (IS) kujundamisel oli vaja koguda nõuded, mis aitaksid luua sellise liidese, et lõppkasutajal (poe töötajal) oleks mugav arendatud IS-iga töötada. .

Nõuete väljatöötamine on protsess, mis hõlmab spetsifikatsiooni sisaldava dokumendi loomiseks ja kinnitamiseks vajalikke tegevusi. Nõuded süsteemile.

Materjalide arvestuse ja kontrolli automatiseerimise protsessi rakendamiseks on vajalik, et infosüsteem suudaks täita järgmisi funktsionaalseid nõudeid:

¾ tulemuste dokumenteerimine.

¾ Infosüsteem tuleb realiseerida Visual Fox Pro integreeritud keskkonnal põhineva programmina.

Programm töötab operatsioonisüsteemis Windows 2000 / NT / XP.

Nõuete väljatöötamise protsessis on neli peamist etappi (joonis 1.8):

Süsteemi loomise tehnilise teostatavuse analüüs;

Nõuete kujundamine ja analüüs;

Nõuete täpsustamine ja vastava dokumentatsiooni koostamine;

Nõuete tõendamine.


Nõuete kogumine on tarkvara kujundamise oluline etapp, kuna just siin peavad kõik kliendi nõuded olema õigesti ja õigesti sõnastatud.

1.4 Nõuete spetsifikatsioon

Õigete nõuete kindlaksmääramine on ilmselt tarkvaraprojekti kõige kriitilisem samm. On väga oluline, et projekti formaat vastaks arendusmeeskonna poolt kokku pandud tarkvaranõuetele, vastasel juhul ei saa neid nõudeid tarkvaratootes toetada ja esitada. Tarkvaranõuete spetsifikatsioon (SRS) on kogu tarkvaraarenduse elutsükli kesksel kohal. See ei ole ainult tuletatud dokument, mis määratleb tarkvaraprojekti spetsifikatsioonid, vaid ka peamine dokument, mida kasutatakse kvalifitseerimise ja vastuvõtutestide läbiviimiseks. Atesteerimine on hinnang projektijuhtide töö kvaliteedile. See määrab tarkvaratoote kehtestatud nõuetele vastavuse taseme. SRS-i spetsifikatsioon toimib mehhanismina süsteeminõuete registreerimiseks, mida kasutatakse atesteerimise kriteeriumidena.

SRS-i alusel saavutatakse kokkulepe klientide ja tarkvaratoote tootjate vahel. SRS-i spetsifikatsioon kirjeldab täielikult funktsioone, mida arendatud tarkvaratoode peab täitma. See võimaldab potentsiaalsetel kasutajatel kindlaks teha, mil määral toode vastab nende vajadustele, samuti viisid, kuidas toodet muuta nii, et see oleks nende probleemide lahendamisel kõige kasulikum.

Vähendab arendusaega. SRS-i spetsifikatsiooni koostamisse on kaasatud erinevad grupid kliendi organisatsioonis. Nad uurivad kõiki nõudeid põhjalikult juba enne projekti tegeliku arendamise algust. See vähendab hilisema ümberkujundamise, kodeerimise ja testimise tõenäosust.

SRS-i spetsifikatsiooni nõuete hoolikas uurimine võib paljastada möödalaskmisi, arusaamatusi ja ebakõlasid arendustsükli alguses, kui probleeme on palju lihtsam parandada kui hiljem.

SRS-i spetsifikatsioon saab kulude prognoosimise ja ajakava koostamise aluseks. Tootekirjeldus on reaalne alus projekti maksumuse hindamisel. Keskkonnas, kus ametliku ettepaneku kontseptsioon on olemas, kasutatakse SRS-i pakkumise või hinna hinnangu kinnitamiseks.

Hästi kirjutatud spetsifikatsioonidega saavad SRS-id organisatsiooni tasandil välja töötada palju produktiivsemad sertifitseerimis- ja auditiplaanid. Arenduslepingu raames annab SRS võrdlusaluse spetsifikatsioonidele vastavuse hindamiseks.

SRS-i spetsifikatsioon muudab tarkvaratoote uutele kasutajatele ülekandmise ja ka teistesse arvutitesse installimise lihtsamaks. Seega muutub klientidel lihtsamaks tarkvaratoote üleandmine organisatsiooni teistesse osakondadesse ja arendajatel teistele klientidele.

SRS-i spetsifikatsioon on moderniseerimise aluseks. See dokument käsitleb toodet ennast, mitte projekti arendusprotsessi, seega saab seda kasutada valmistoote laiendusena.

Kui nõuete määratlemise ja täpsustamise protsess on lõppenud, on vaja nõuded valideerida.

Tarkvaraprojekti nõuete täpsustus esitatakse lisas A.

1.5 Nõuete tõendamine

Valideerimine peab näitama, et nõuded määratlevad tõeliselt süsteemi, mida klient soovib. Nõuete valideerimine on oluline, kuna viga nõuete spetsifikatsioonis võib põhjustada süsteemi ümbertöötamist ja suuri kulutusi, kui see avastatakse süsteemi arendusprotsessi käigus või pärast selle tootmisse laskmist.

Atesteerimise käigus peavad nõuded olema täidetud erinevad tüübid nõuete dokumentatsiooni kontroll:

1. Nõuete õigsuse kontrollimine.

2. Järjepidevuse kontrollimine.

3. Täielikkuse kontrollimine.

4. Teostatavuse kontroll.

On mitmeid nõuete tõendamise meetodeid, mida saab kasutada koos või igaüht eraldi:

1. Nõuete läbivaatamine.

2. Prototüüpimine.

3. Testskriptide genereerimine.

4. Järjepidevuse automatiseeritud analüüs.

Prototüüpimine on süsteemi kliendile kõige nähtavam.

Enne prototüüpimise alustamist saate luua kasutajaliidese vooskeemi. Seda diagrammi kasutatakse kasutajaliidese põhielementide vaheliste seoste uurimiseks.

Nõuete valideerimise järgmine samm on otsene prototüüpimine.

Tarkvara prototüüp on kavandatava uue toote osaline või võimalik teostus. Prototüübid võimaldavad teil täita kolme peamist ülesannet: nõuete formuleerimise protsessi selgitamine ja lõpuleviimine, alternatiivsete lahenduste uurimine ja lõpptoote loomine.

Selle mooduli peamenüü prototüüp on näidatud joonisel 1.9.

1.6 Infosüsteemi projekteerimise metoodika valimine

IS-i arendamise struktuurse lähenemise olemus seisneb selle lagunemises (jagamises) automatiseeritud funktsioonideks: süsteem jaguneb funktsionaalseteks alamsüsteemideks, mis omakorda jagunevad alamfunktsioonideks, jaotatakse ülesanneteks jne. Jaotamisprotsess jätkub konkreetsete protseduurideni. Samal ajal säilitab automatiseeritud süsteem tervikliku vaate, milles kõik koostisosad on omavahel ühendatud.

Kõik levinumad struktuurse lähenemise metoodikad põhinevad mitmel üldpõhimõttel. Järgmisi põhimõtteid kasutatakse kahe põhiprintsiibina:

Jaga ja valluta – keeruliste probleemide lahendamise põhimõte, jagades need paljudeks väiksemateks iseseisvateks probleemideks, mida on lihtne mõista ja lahendada;

Hierarhilise järjestamise põhimõte on põhimõte organiseerida probleemi koostisosad hierarhilisteks puustruktuurideks, lisades igal tasandil uusi detaile.

Struktuurianalüüsis kasutatakse peamiselt kahte rühma tööriistu, et illustreerida süsteemi poolt täidetavaid funktsioone ja andmete vahelisi seoseid. Iga fondide rühm vastab teatud tüüpi mudelitele (skeemidele), kõige levinumad, mille hulgas on järgmised:

SADT (Structured Analysis and Design Technique) mudelid ja nendega seotud funktsionaalsed diagrammid;

DFD (Data Flow Diagrams) andmevoo diagrammid;

ERD (Entity-Relationship Diagrams) olemi-relatsiooni diagrammid.

IS-i projekteerimise etapis laiendatakse, täiustatakse ja täiendatakse skeemidega, mis kajastavad tarkvara struktuuri: tarkvara arhitektuur, programmide plokkskeemid ja ekraaniskeemid.

Loetletud mudelid koos annavad Täielik kirjeldus IP olenemata sellest, kas see on olemasolev või äsja välja töötatud. Diagrammide koosseis sõltub igal konkreetsel juhul süsteemi kirjelduse nõutavast täielikkusest.

2 INFOSÜSTEEMI KUJUNDAMINE

2.1 Arhitektuurne projekteerimine

Mis tahes keeruka infosüsteemi loomisel on kriitiliseks aspektiks selle arhitektuur, kus see kujutab endast kontseptuaalset nägemust tulevaste funktsionaalsete protsesside ja tehnoloogiate struktuurist süsteemi tasandil ja seotuses. Tavaliselt kujundatakse organisatsioonide keerukad infosüsteemid kõrgetasemeliste interakteeruvate komponentide kompositsioonina, mis võivad ise olla süsteemid. Organisatsiooni infosüsteemi arhitektuur muudab süsteemi arusaadavamaks, määratledes selle funktsionaalsuse ja struktuuri viisil, mis paljastab disainiotsused ja võimaldab vaatlejal esitada küsimusi disaininõuete täitmise, funktsionaalsuse jaotamise ja komponentide juurutamise kohta.

Organisatsiooni infosüsteemi arhitektuur on mudel, kuidas infotehnoloogia toetab automatiseeritud rajatise peamisi eesmärke ja arengustrateegiat. See võimaldab teil kriitiliselt mõelda ja sõnastada nägemuse sellest, kuidas integreeritud infosüsteemide komplektid tuleks nende eesmärkide saavutamiseks üles ehitada. Infosüsteemi arhitektuur kirjeldab, kuidas infosüsteemid, rakendused ja inimesed töötavad kogu organisatsioonis ühtsel ja ühtsel viisil.

Seega sisaldab infosüsteemi arhitektuur üldtunnustatud komponentide komplekti, mis annavad infosüsteemi "ehituskivid". Need "ehitusplokid" ja nende omadused on määratletud sobival üksikasjalikkuse tasemel, et vastata planeerimisotsuste vajadustele.

Kaasaegsete organisatsioonide infosüsteemide kavandamisel tuleks nende arhitektuur välja töötada paljusid huvigruppe arvesse võttes, see peaks olema kasutajatele arusaadav, võimaldama arendajatel süsteemi planeerida ja ajastada, võimaldada määratleda võtmeliideseid, funktsioone ja tehnoloogiaid ning võimaldada ka hinnata. projekti ajakava ja eelarve. See eeldab kaasaegsete infosüsteemide arhitektidelt vastutust luua süsteemist rahuldav ja toimiv kontseptsioon juba selle arendamise varases staadiumis, säilitada selle kontseptsiooni terviklikkus kogu arenduse vältel ning teha kindlaks loodud süsteemi sobivus kasutamiseks. klient. Infosüsteemi arhitektuur seevastu on protsess, mille käigus kirjeldatakse infosüsteemide arhitektuure piisavalt üksikasjalikult, et muuta need infosüsteemide kujundamisel kasulikumaks.

Välismaiste kogemuste uurimine näitab, et arenenud riikides peavad infosüsteemi arhitektuuri arendamisel olema täidetud järgmised tingimused:

¾ keskenduda organisatsiooni missioonile;

¾ keskendumine nõuetele;

¾ keskendumine arengule;

¾ kohanemisvõimet;

¾ vajadus paindlikkuse järele.

Kõigi nende tingimuste täitmine võimaldab arendada organisatsiooni infosüsteemi arhitektuuri täiuslikumaks ja tõhusamaks.

Peamised praegu rakendatavad tarkvaraarhitektuurid on järgmised:

¾ failiserver;

¾ klient-server;

¾ mitmetasandiline.

Failiserver... See tsentraliseeritud andmebaasi arhitektuur koos juurdepääsu võrgule hõlmab ühe võrgus oleva arvuti määramist spetsiaalseks serveriks, mis salvestab tsentraliseeritud andmebaasi failid. Vastavalt kasutaja soovidele kantakse failiserverist failid kasutajate tööjaamadesse, kus toimub suurem osa andmetöötlusest. Keskserver täidab peamiselt ainult failide salvestamise rolli, osalemata ise andmete töötlemises. Pärast töö lõpetamist kopeerivad kasutajad töödeldud andmetega failid tagasi serverisse, kust teised kasutajad saavad neid võtta ja töödelda. Sellisel andmehoolduse korraldusel on mitmeid puudusi, näiteks kui mitu kasutajat pääseb korraga juurde samadele andmetele, langeb tööjõudlus järsult, kuna tuleb oodata, kuni andmetega töötav kasutaja oma töö lõpetab. Vastasel juhul võivad mõnede kasutajate tehtud muudatused teiste kasutajate tehtud muudatustega üle kirjutada.

Klient-server... See kontseptsioon põhineb ideel, et lisaks andmebaasifailide hoidmisele peab keskserver tegema suurema osa andmetöötlusest. Kasutajad pääsevad keskserverisse spetsiaalse struktureeritud päringukeele (SQL, Structured Query Language) abil, mis kirjeldab serveri sooritatavate ülesannete loendit. Kasutajate päringud võtab vastu server ja genereerib selles andmetöötlusprotsesse. Vastuseks saab kasutaja juba töödeldud andmestiku. Kliendi ja serveri vahel ei edastata mitte kogu andmehulka, nagu see juhtub failiserveri tehnoloogias, vaid ainult neid andmeid, mida klient vajab. Vaid mõne rea pikkune kasutajapäring võib genereerida andmetöötlust, mis hõlmab paljusid tabeleid ja miljoneid ridu. Vastuseks saab klient vaid mõne numbri. Klient-server tehnoloogia võimaldab vältida tohutute infohulkade edastamist üle võrgu, nihutades kogu andmetöötluse keskserverisse. Lisaks väldib vaadeldav lähenemine failiserveri tehnoloogiale omaseid konflikte samade andmete muutmisel mitme kasutaja poolt. Kliendi-serveri tehnoloogia rakendab andmete järjepidevat muutmist mitme kliendi poolt, tagades andmete automaatse terviklikkuse. Need ja mõned muud eelised on muutnud klient-server tehnoloogia väga populaarseks. Selle tehnoloogia puudused hõlmavad keskserveri kõrgeid jõudlusnõudeid. Mida rohkem kliente serverile ligi pääseb ja mida suurem on töödeldavate andmete hulk, seda võimsam peab olema keskserver.

Nendest kaalutlustest lähtuvalt võeti AWS-i arhitektuuri kavandamisel aluseks klient-server tehnoloogia. Paigutusskeemid näitavad füüsilisi seoseid tarkvara ja riistvara komponentide vahel süsteemis.)

2.2 Infosüsteemi liidese kujundamine

Kasutajaliidese all mõistetakse sageli ainult programmi välimust. Tegelikkuses aga tajub kasutaja enda kaudu kogu süsteemi tervikuna, mis tähendab, et selline arusaam temast on liiga kitsas. Tegelikkuses hõlmab kasutajaliides kõiki disaini aspekte, mis mõjutavad kasutaja ja süsteemi vahelist suhtlust. Kasutaja ei näe ainult ekraani. Kasutajaliides koosneb paljudest komponentidest, näiteks:

kasutaja ülesannete kogum, mida ta süsteemi abil lahendab;

süsteemi juhtnupud;

navigeerimine süsteemiplokkide vahel;

programmiekraanide visuaalne kujundus.

Siin on mõned hea kasutajaliidese kõige olulisemad ärilised eelised.

kasutajavigade arvu vähendamine;

süsteemi ülalpidamiskulude vähendamine;

töötajate tootlikkuse kaotuse vähendamine süsteemi juurutamisel ja kaotatud tootlikkuse kiirem taastumine;

personali moraali parandamine;

kasutajaliidese muutmise kulude vähendamine kasutajate soovil;

süsteemi funktsionaalsuse kättesaadavus maksimaalse arvu kasutajate jaoks.

AWP hulgimüügibaas on arendatud kliendi-serveri tehnoloogiat kasutava rakendusena.

2.2.1 Juhtprogrammi kasutajaliides

"AWP hulgimüügibaasi" põhimoodul on moodul Luck.exe, mis võimaldab realiseerida jaotise 1.4 joonisel 1.9 näidatud kasutusjuhtude diagrammi põhifunktsioonid.

Infosüsteemi arendamisel on üheks peamiseks ülesandeks luua võimalikult lihtne ja laadimata liides. See on tarkvaratoote liides, mis aitab kasutajatel infosüsteemiga "suhelda", toimides dialoogina kasutaja ja süsteemi vahel.

Programmi liides, haldusosa:

1. programmi algusvorm. See vorm käivitatakse tarkvaratoote käivitamisel, moodustades seeläbi kasutaja dialoogi alguse süsteemiga (joonis 2.3);

2. administraatori vorm. Sellisel kujul viiakse läbi infosüsteemi terviklik haldamine, s.o. andmete lisamine, kustutamine, muutmine andmebaasis, samuti vajadusel aruannete vaatamine ja printimine (joonis 2.4);

3. vorm "Kliendid", tänu sellele vormile näete täielikku teavet ettevõtte klientide kohta (joonis 2.7);

4. Vorm "Tarnijad", tänu sellele vormile näete täielikku teavet ettevõtte klientide kohta (joonis 2.8).

Programmi kasutajaliides:

Kauba saabumise aknas käib kauba registreerimine. Valides selle vormi vahekaardi, peab kasutaja esmalt

Kulumenüüs on laotöötaja poolt teostatavad toimingud kauba väljastamiseks ja müügiks.

Menüüsaldodes loetakse kaubad, lattu ladustatud esemete nimetused.

Kassa menüüs salvestatakse siin teave kreeditkorralduste ja sularaha väljavoolu korralduste kohta. (Ekraanipildid)

2.2.2 Juhtkomponentide kasutajaliidesed

Joonis 2.0 Programmi peamenüü

Programmi peaaken on näidatud joonisel fig. 1.9. Nagu jooniselt näha, sisaldab see lisaks juba ülalkirjeldatud peamenüüle ka juhtpaneeli (nupud "Sissetulek", "Tarbimine", "Juurdepääs", "Saldod", "Kassa", "Ümberhindlus". ", "Analytics", " Kataloogid "," Teenus "ja" Välju programmist ").

Joonis 2.1 Laos laekumise või laekumise menüüaken.


Joonis 2.2 Tarbimise menüü aken

Joonis 2.2 Programmi juurdepääsuõigusi reguleeriv menüüaken.

Joonis 2.3 Ülejäänud kauba menüü aken.

Joonis 2.4 Kassaaparaadi menüü aken.


Joonis 2.4 Ümberhindluse menüü aken.

2.3 Andmebaasi disain

Andmebaasi kujundamisel kasutati ERwin 4.0 ettevõttelt Computer Associates Int.

ERwin on võimas ja lihtsalt kasutatav andmebaaside kujundamise tööriist, mis on kogunud laialdast tunnustust ja populaarsust. See pakub andmebaasipõhiste rakenduste arendamisel ja hooldamisel suurimat tootlikkust. Kogu protsessi vältel – alates andmebaasi defineerivate teabenõuete ja ärireeglite loogilisest modelleerimisest kuni füüsilise mudeli optimeerimiseni vastavalt määratud omadustele – võimaldab ERwin visuaalselt kuvada andmebaasi struktuuri ja põhielemente.

ERwin pole mitte ainult parim andmebaasi kujundamise tööriist, vaid ka tööriist selle kiireks loomiseks. ERwin optimeerib mudelit vastavalt sihtandmebaasi füüsilistele omadustele. Erinevalt teistest tööriistadest säilitab ERwin automaatselt loogilise ja füüsilise skeemi järjepidevuse ning tõlgib loogilised konstruktsioonid, nagu paljud-mitmele seosed, füüsilisteks rakendusteks. Hõlbustab andmebaasi kujundamist. Selleks piisab graafika loomisest E-R mudel(relatsiooniobjekt), mis vastab kõigile andmenõuetele ja tutvustab ärireegleid, et luua loogiline mudel, mis kuvab kõik elemendid, atribuudid, seosed ja rühmitused. Erwinil on mudeliesitluses kaks taset – loogiline ja füüsiline. Loogiline tasand on andmete abstraktne vaade, sellel esitatakse andmed nii, nagu need reaalses maailmas välja näevad, ja seda võib nimetada nii, nagu neid pärismaailmas nimetatakse, näiteks " Püsiklient"," Osakond "või" Töötaja perekonnanimi ". Mudelobjekte, mis on esindatud loogilisel tasemel, nimetatakse olemiteks ja atribuutideks. Andmemudeli loogiline tase on universaalne ja sellel pole mingit pistmist DBMS-i konkreetse teostusega. Andmemudeli loogilisel tasemel on kolm alamtasandit, mis erinevad andmete esitamise sügavuse poolest:

Entity Relationships Diagram (ERD);

Võtmepõhine mudel (KB);

Täielikult omistatud mudel (FA).

Olemidiagramm – seos hõlmab oleme ja suhteid, mis kajastavad domeeni põhilisi ärireegleid. Selline diagramm ei ole liiga detailne, see sisaldab põhilisi üksusi ja nendevahelisi seoseid, mis vastavad põhinõuetele. Olemidiagramm – seos võib sisaldada paljusid-mitmele seoseid ja mitte sisaldada võtmekirjeldusi. Tavaliselt kasutatakse ERD-d esitlusteks ja andmestruktuuri arutamiseks teemaekspertidega. Võtmepõhine andmemudel on andmete üksikasjalikum vaade. See sisaldab kõigi olemite ja primaarvõtmete kirjeldust ning on mõeldud kirjeldama andmestruktuuri ja võtmeid, mis vastavad teemavaldkonnale.

Loogiline mudel on andmestruktuuri kõige üksikasjalikum esitus: see esitab andmeid kolmandal normaalkujul ja sisaldab kõiki oleme, atribuute ja seoseid (vt lisa B).

Füüsiliste andmete mudel vastupidi, see sõltub konkreetsest DBMS-ist, olles tegelikult süsteemikataloogi kuva. Mudeli füüsiline kiht sisaldab teavet kõigi andmebaasis olevate objektide kohta. Kuna andmebaasiobjektide standardid puuduvad (näiteks puudub andmetüüpide standard), siis mudeli füüsiline kiht sõltub DBMS-i konkreetsest teostusest. Järelikult võib mudeli samale loogilisele tasemele vastata erinevate mudelite mitu erinevat füüsilist taset. Kui mudeli loogilisel tasandil pole suurt vahet, mis konkreetset andmetüüpi atribuut omab (kuigi abstraktsed andmetüübid on toetatud), siis mudeli füüsilisel tasandil on oluline kirjeldada kogu infot konkreetsete füüsiliste objektide kohta - tabelid, veerud, indeksid, protseduurid jne ... Andmemudeli jagamine loogiliseks ja füüsiliseks tasandiks võimaldab lahendada mitmeid olulisi probleeme.

Füüsiline andmemudel on esitatud lisas B.

2.4 Infosüsteemi loomise platvormi valiku põhjendus

Visual FoxPro on visuaalne relatsiooniline andmebaasihaldussüsteem, mis on praegu saadaval Microsoftilt. Uusim versioon on 9.0. Kasutab FoxPro programmeerimiskeelt. Süsteemi versioon 7.0 saab töötada operatsioonisüsteemides Windows 9x ja NT tuumades, versioonid 8.0 ja 9.0 – ainult operatsioonisüsteemides Windows XP, 2000, 2003.

FoxPro on üks xBase programmeerimiskeele dialektidest. Seda kasutatakse peamiselt relatsioonilise DBMS-i arendamiseks, kuigi seda on võimalik kasutada ka teiste klasside programmide arendamiseks Nagu eespool märgitud, on VFP keel tugevalt täiendatud ja laiendatud xBase keel. Visual FoxPro puhul on programmeerimiskeel, st keele põhikonstruktsioon on klassi mõiste. XBase'i algversioon on puhtalt struktureeritud keel, millel on protseduuride ja funktsioonide põhikontseptsioon. Seega võimaldab kaasaegne programmeerimiskeel Visual FoxPro kombineerida nii "vanaaegset" programmeerimist, kirjeldades protseduuride massi, kui ka OOP-stiilis, luues keeruka klasside hierarhia.

Valisin selle programmeerimiskeele, kuna sellel on mitmeid järgmisi eeliseid:

¾ Tuntud andmebaasi tabelivorming, mis hõlbustab teabevahetuse korraldamist teiste rakendustega Microsoft Windows.

Relatsiooniandmebaaside kaasaegne korraldus, mis võimaldab salvestada teavet andmebaasi tabelite, nende omaduste, indeksite ja seoste kohta, seada vastavustingimusi referentsiaalne terviklikkus, luua kohalikke ja kaugvaateid, serveriühendusi, salvestatud protseduure, mis käivitatakse, kui rohkem kui 50 erinevad tüübid sündmused (VFP 7.0-9.0).

Kiire töö suurte andmebaasidega.

Andmebaasidega töötamise hea nähtavus: multifunktsionaalne Data seansi aken võimaldab näha avatud andmebaasitabelite loendit, nende seoseid, filtreid, indeksi järjekorda, puhverdusrežiime, lülituda struktuuri muutmise režiimidele, töötada tabeliteabega jne.

Kiire rakenduste arendus, kasutades programmi teksti kirjutamisel viisardeid, kujundajaid, ehitajaid, IntelliSense'i vihjete režiimi, programmide silumise ja testimise süsteemi.

Võimalus arendada klient-server tehnoloogial põhinevaid rakendusi andmetega, mida majutatakse Oracle'i ja Microsofti andmebaasiserverites SQL Server ja teiste Microsoft Windowsi rakendustega, mis kasutavad ODBC-d ja OLE-d

VFP-süsteem on mõeldud kasutamiseks professionaalsetele programmeerijatele, mistõttu pole mõtet selle menüüd ja keelt venestada – iga programmeerija jaoks on algoritmilise keele ingliskeelne süntaks tuttavam kui vene keel.

2.5 Moodulite kujundamine

Vaatleme üksikasjalikumalt ühe programmimooduli kujundust ja kaalume selle näitel projekti loomiseks vajalikke samme.

Näitena käsitlen kasutusjuhtumit "Väljastab sisseastumisavalduse" rakendava mooduli disaini.

Esiteks kirjeldame sellel kasutusjuhul esinevaid sündmuste vooge.

Kasutusjuhtumi eelduseks on kliendilt päringu saamine.

5. Kasutusjuhtum algab siis, kui klient esitab avalduse.

6. Juht avab Kviitungi vormi.

7. Juhataja määrab taotluse esitamise kuupäeva.

8. Juht paneb toote nimetuse.

9. Juhataja sisestab saadud kauba koguse.

10. Juhataja sisestab taotluse summa.

11. Juhataja sulgeb vormi.

12. Kasutusjuhtum lõpeb.

Kasutusjuhtumi järeltingimuseks on avalduse registreerimine süsteemis ja uue kliendi ilmumine põhivormi päevikusse.

Mõelge järjestusskeemile see valik kasutada. Nagu sellelt diagrammil näha, põhjustab juht saabumise vormi avades mitme toimingu sooritamise - automaatselt (halduri vaatenurgast) täidetakse avalduse kuupäev. Avalduse esitamisel täidetakse baasist klientide nimekiri esmase infoga. Pärast seda sisestab haldur kõik vajalikud andmed ja klõpsab nuppu "Nõustu". Sel juhul tehakse järgmised toimingud. Kõik andmed edastatakse salvestatud protseduurile.

3 Infosüsteemi juurutamine ja valideerimine

3.1 Rakenduse juurutamine

Rakenduse juurutamine on oma olemuselt infosüsteemi arendaja jaoks üks töömahukaid etappe, sest kliendi poolt esitatavad nõuded peavad olema selgelt ja korrektselt süsteemi integreeritud. Seni puuduvad tarkvaratooted, mis suudaksid "kohandada" nn kliendi nõudmistele ja pakkuda süsteemi juurutamiseks teatud funktsioonide komplekti, mis neile nõuetele vastaks. Seetõttu peab iga arendaja valima süsteemi arendamiseks optimaalse keskkonna, kuid tuleb tähele panna, et rakenduse juurutamisel ei saa ilma programmikoodi kirjutamata hakkama. Just programmikoodi kirjutamisel rakendatakse teatud funktsioone, mida süsteem peab täitma. Olenevalt süsteemi juurutamiseks valitud keskkonnast näeb programmikood välja erinevalt, sellises keskkonnas nagu Microsoft Visual FoxPro on üks programmikood, Visuaalne põhi teine ​​jne.

Sel juhul rakendati rakendus Microsoft Visual FoxPro-s.

Süsteemi põhifunktsioone kirjeldatakse allpool:

1. Süsteemi algusvorm. See vorm on nupuvorm ja vastavalt sellele täidab iga nupp oma funktsiooni. Administraatori registreerimisnupp on näidatud joonisel 3.1 See nupp täidab funktsiooni, mis avab administraatori paneeli, kui kasutajal on selles süsteemis sellised õigused.

2. Menüünupu saabumine. See nupp võimaldab jälgida kaupluse lattu saabuvaid kaupu Joonis 3.2.

3. Menüü nupul peetakse kulu arvestust laost välja antud kaupade kohta Joonis 3.3.

4. Juurdepääsumenüü nupul on reguleeritud selle programmi kasutamise õigused Joonis 3.4.

5. Menüü nupule "jäägid" on salvestatud info kaupluse laos hoitavate materjalide kohta Joonis 3.5.

6. Kassa menüünupp salvestab info sissetulevate ja väljaminevate kassakorralduste kohta Joonis 3.6.

7. Menüünupu ümberhindluses muutub hind uus hind kaubad joonis 3.7.

Joonis 3.1 – Süsteemi algusvorm


Joonis 3.2 - Kauba lattu laekumise arvestuse vorm.

Joonis 3.3 – Vabastatud kauba arvestuse vorm.

Joonis 3.4 – Programmi juurdepääsuõigusi reguleeriv vorm.


Joonis 3.5 – Ülejäänud kauba vorm laos.

Joonis 3.5 — Vorm sularaha laekumiste ja kassakviitungite kohta.


Joonis 3.6 – Kaubaga tehtavate toimingute vorm.

Rakenduse testimine

Testimine on programmi käivitamise protsess vigade tuvastamiseks. Testimine annab:

Vigade tuvastamine;

Programmi funktsioonide eesmärgile vastavuse demonstreerimine;

Programmi omadustele esitatavate nõuete täitmise demonstreerimine;

Töökindluse kuvamine programmi kvaliteedi näitajana.

Joonisel 3.2 on näidatud testimisprotsessi infovood.


Testimisprotsessi sissepääsu juures on kolm voogu:

Programmi tekst;

Algandmed programmi käivitamiseks;

Oodatud tulemused.

Tehakse testid ja hinnatakse kõiki saadud tulemusi. See tähendab, et tegelikke testitulemusi võrreldakse oodatud tulemustega. Kui leitakse mittevastavus, salvestatakse viga ja algab silumine.

Pärast testitulemuste kogumist ja hindamist algab tarkvara kvaliteedi ja töökindluse kuvamine. Kui regulaarselt tuleb ette tõsiseid vigu, mis nõuavad kujunduse muutmist, siis on tarkvara kvaliteet ja töökindlus kahtlane ning on välja toodud vajadus testimist tugevdada.

Testimise käigus kogunenud tulemusi saab hinnata formaalsemalt. Selleks kasutatakse tarkvara töökindluse mudeleid, mis ennustavad usaldusväärsust veamäära reaalsete andmete põhjal.

Tarkvara testimisel on kaks põhimõtet:

Funktsionaalne testimine (musta kasti testimine);

Struktuuri testimine (valge kasti testimine).

"Valge kasti" meetodi testimisel on teada programmi sisemine struktuur. Testimise objektiks ei ole siin mitte väline, vaid programmi sisemine käitumine. Kontrollitakse programmi kõigi elementide ülesehituse õigsust ja nende üksteisega suhtlemise õigsust.

Musta kasti testimine (funktsionaalne testimine) võimaldab teil saada sisendandmete kombinatsioone, mis tagavad programmi kõigi funktsionaalsete nõuete täieliku kontrolli //. Tarkvaratoodet käsitletakse siin kui "musta kasti", mille käitumist saab kindlaks teha ainult selle sisendeid ja vastavaid väljundeid uurides.

Musta kasti põhimõte ei ole alternatiiv valge kasti põhimõttele. Pigem on see üksteist täiendav lähenemisviis, mis tuvastab erinevat tüüpi vigu.

Musta kasti testimine otsib järgmisi veakategooriaid:

Valed või puuduvad funktsioonid;

Liidese vead;

Vead välistes andmestruktuurides või juurdepääsul väline alus andmed;

Iseloomulikud vead (nõutav mälumaht jne);

Initsialiseerimise ja lõpetamise vead.

Erinevalt valge kasti testimisest, mis viiakse läbi testimisprotsessi alguses, kasutatakse musta kasti testimist testimise hilisemates etappides. Musta kasti testimisel jäetakse tähelepanuta programmi juhtimisstruktuur. Siin keskendutakse tarkvarasüsteemi määratluse teabealale. Testimine selles etapis keskendub lahenduse sobivusele reaalajas tootmiskeskkonda. Põhirõhk on vigade parandamisel ja nende tõsiduse määramisel ning toote vabastamiseks ettevalmistamisel.

Testimise etapis lahendatakse kaks peamist ülesannet:

Lahenduste testimine – planeerimisfaasis koostatud ning arendusfaasis laiendatud ja testitud katseplaanid täidetakse;

Pilootoperatsioon - lahenduse juurutamine testkeskkonnas ja testimine koos tulevaste kasutajate kaasamisega ning reaalsete süsteemi kasutamise stsenaariumide rakendamine. See ülesanne tehakse enne juurutamisetapi algust.

Testimisfaasi eesmärk on vähendada riski, mis tekib lahenduse kasutuselevõtul.

Testimisfaasi õnnestumiseks tuleb muuta suhtumist projekti ja arendaja lülituda uute funktsioonide väljatöötamiselt lahenduse korraliku kvaliteedi tagamisele.

Infosüsteemi arendamise selles etapis tuleks läbi viia järgmist tüüpi testimine:

Põhitestimine on madala tasemega tehniline testimine. Programmikoodi kirjutamise käigus viib selle läbi arendaja ise. Rakendatakse "valge kasti" meetodit, suur vigade oht.

Kasutatavuse testimine – kõrgetasemeline testimine, mida teostavad testija ja toote tulevased kasutajad. Rakendatakse "musta kasti" meetodit.

Alfa- ja beetatestimine – MSF-i mõistes on alfakood põhimõtteliselt kogu MSF-i protsessimudeli arendusfaasis loodud lähtekood ja beetakood on kood, mida testimisetapis testiti. Seetõttu testitakse alfakoodi MSF protsessimudeli arendusfaasis ja beetakoodi testimise etapis.

Ühilduvuse testimine – arendatav lahendus on vajalik olemasolevate süsteemide integreerimiseks ja koostoimimiseks tarkvaralahendused... See testimisvorm on keskendunud väljatöötatud lahenduse integreeritavuse ja olemasolevate süsteemidega suhtlemise võime testimisele. Sel konkreetsel juhul kontrollitakse rakenduse korrektset toimimist kasutaja seadmes ja kasutaja kasutatavat tarkvara.

Jõudlustestimine – keskendub kontrollimisele, kas rakendus vastab jõudlusnõuetele ja kiiruse mugavuse tasemele.

Testimisdokumentatsioon ja abisüsteem- testitakse kõiki väljatöötatud tugidokumente ja abisüsteeme.

Pilootoperatsioon katsetab lahendust tööstuskeskkonnas. Pilootoperatsiooni põhieesmärk on näidata, et lahendus on võimeline stabiilselt töötama tööstuslikes tingimustes ja vastab ärinõuetele. Piloottöö käigus testitakse lahendust reaalsetes tingimustes. Pilootfunktsioon võimaldab kasutajatel anda tagasisidet toote toimivuse kohta. Sellest arvamusest juhindudes kõrvaldab arendaja kõik võimalikud probleemid või koostab tegevusplaani ettenägematute asjaolude ilmnemisel. Lõppkokkuvõttes võimaldab pilootoperatsioon otsustada, kas alustada täielikku kasutuselevõttu või lükata edasi, kuni on lahendatud probleemid, mis võivad kasutuselevõttu häirida.

Arendatava infosüsteemi piloottööprotsessi plaan on toodud tabelis 3.2.

Tabel 3.2 – Pilootoperatsiooni plaan

Tegevus

Kirjeldus

1. Edu kriteeriumide valik

Arendaja ja testijad määratlevad edukriteeriumid ja lepivad need kokku.

2. Kasutajate valik ja paigalduskoht

Moodustatakse eksperimentaalses testimises osalejate meeskond kasutajate ja arendajate poolelt. Määratakse kindlaks pilootprotsessi juurutamise asukoht.

3. Kasutajate ja paigalduskohtade ettevalmistamine

Toimub kasutajate - katses osalejate koolitus. Paigalduskoht on ettevalmistamisel.

4. Arendusversiooni juurutamine

Eksperimentaalne versioon on installitud ja kaasatud töösse.

5. Prototüübi versiooni tugi ja jälgimine

Kasutajate ja süsteemi töö jälgimine, abi osutamine toimimisel, info kogumine süsteemi toimimise kohta

6. Kasutajate tagasiside ja tulemuste hindamine

Kasutajad avaldavad oma arvamust süsteemi toimimise kohta, toovad välja puudused ja vead.

7. Muudatuste ja täienduste tutvustamine

Parandatakse vead, tehakse disaini või protsessi muudatusi. Parandatud tulemused antakse kasutajatele töötamiseks ja hindamiseks.

8. Kasutusotsused

Kui piloottestimise tulemused kasutajaid rahuldavad, otsustatakse süsteem kasutusele võtta.

3.2 Rakenduse juurutamise metoodika

Selles etapis võtab arendaja (või meeskond) kasutusele lahenduseks vajalikud tehnoloogiad ja komponendid, projekt liigub hoolduse ja toe staadiumisse ning klient kiidab selle lõpuks heaks. Pärast juurutamist hindab meeskond projekti ja küsitleb kasutajaid, et teha kindlaks nende rahulolu.

Juurutamisetapi eesmärgid:

¾  viia lahendus üle tööstuskeskkonda;

¾  tellija kinnitus projekti valmimise kohta.

Kohapõhiste komponentide juurutamine hõlmab mitut etappi: ettevalmistus, paigaldamine, koolitus ja ametlik heakskiit.

Süsteemi juurutamise etapi tulemused on hooldus- ja tugisüsteemid, dokumendihoidla, kus asuvad kõik projekti käigus välja töötatud dokumentide ja koodi versioonid.

Arendatava süsteemi kasutuselevõtuks koostati tegevuskava, mis on toodud tabelis 3.1.

Tabel 3.1 – Rakenduse juurutusplaan

Tegevus

Tegevuse kirjeldus

1. Varukoopia

Toodetud varukoopia kasutaja andmed tema osalusel ja nõusolekul, edastades teabe irdkandjale (CD, DVD)

2. Lahenduse põhikomponentide paigaldus

Tehnoloogiate kasutamine, mis tagavad lahenduse toimimise. Sel juhul Visual FoxPro komponendi installimine

3. Kliendirakenduse installimine

Ülekanne kasutaja arvutisse ning väljatöötatud IS-i ja andmebaasi lõpliku versiooni installimine

4. Koolitus

Kasutajad on koolitatud süsteemiga töötama, arendaja on veendunud klientide IP töö õigsuses ja arusaamises.

5. Projekti teadmistebaasi üleandmine tellijale

Kogu projekti dokumentatsioon antakse üle tellijale

6. Projekti sulgemine

Koostatakse projekti lõpetamise aruanne. Klient allkirjastab vastuvõtuakti.

AWP normaalseks toimimiseks on see vajalik operatsioonisüsteem Microsoft WindowsXP.

4 Infoprojektide juhtimine

4.1 Arenduselutsükli valimine

Üks neist põhimõisted IS-i kavandamise metoodika on selle tarkvara (elutsükli tarkvara) elutsükli kontseptsioon. Tarkvara elutsükkel on pidev protsess, mis algab hetkest, mil tehakse otsus selle loomise vajaduse kohta ja lõpeb selle täieliku kasutusest kõrvaldamise hetkega.

Peamine regulatiivne dokument, mis reguleerib tarkvara elutsüklit, on rahvusvaheline standard ISO / IEC 12207 (ISO - International Organization of Standardization - International Organisation for Standardization, IEC - International Electro Technical Commission - International Commission on Electrical Engineering). See määratleb elutsükli struktuuri, mis sisaldab protsesse, toiminguid ja ülesandeid, mida tarkvara loomisel tuleb täita.

ISO / IEC 12207 ei paku konkreetne mudel Elutsükkel ja tarkvara arendamise meetodid. Elutsükli mudelit võib mõista kui struktuuri, mis määrab elutsükli jooksul sooritatavate protsesside, toimingute ja ülesannete järjekorra ning seose. Elutsükli mudel sõltub IS-i spetsiifikast ning selle loomise ja toimimise tingimuste eripärast.

Tänapäeval on tarkvara elutsükli mudeleid palju, kuid kõige populaarsemad ja levinumad on kaks mudelit:

Spiraalne mudel(vt joonis 4.1);

Iteratiivne mudel.


Joonis 4.1 – Tarkvara elutsükli spiraalmudel

Infosüsteemi loomiseks, s.o. Valituks osutus iteratiiv "Laotöötajate hulgilao automatiseeritud töökoht". Iteratiivse mudeli eripäraks on see, et see on formaalne meetod, koosneb üksteisest sõltumatutest faasidest, mis viiakse läbi järjestikku ja mida vaadatakse sageli üle (joonis 4.2). Iteratiivne lähenemine on end hästi tõestanud IS-de ehitamisel, mille jaoks on juba arenduse alguses kõik nõuded piisavalt täpselt ja täielikult sõnastatud, et anda arendajatele vabadus neid tehnilisest aspektist võimalikult hästi rakendada. vaatest.

Iteratiivse mudeli eelised:

mudel on mittetarkvaratarbijatele ja lõppkasutajatele hästi teada.

Mugavus ja kasutusmugavus, sest kõik tööd tehakse etapiviisiliselt (vastavalt mudeli faasidele);

Nõuete stabiilsus;

Mudel on arusaadav;

Mudeli struktuurist saavad juhinduda isegi halvasti koolitatud töötajad (kogenematu kasutaja);

Mudel käsitleb keerukust korrapäraselt ja töötab hästi projektide puhul, mis on mõistlikult arusaadavad;

Mudel hõlbustab projektijuhtimise range kontrolli rakendamist;

Hõlbustab projektijuhi tööd arendusmeeskonna planeerimisel ja komplekteerimisel.

Joonis 4.2 – Tarkvara elutsükli iteratiivne mudel

Mudeli etapid:

Analüüsi etapis määratletakse funktsioonid, mida süsteem peaks täitma, tuuakse esile kõige prioriteetsemad, mis nõuavad eelkõige läbitöötamist, kirjeldatakse teabevajadusi;

Projekteerimisetapis käsitletakse süsteemi protsesse üksikasjalikumalt. Funktsionaalmudelit analüüsitakse ja vajadusel korrigeeritakse. Ehitatakse süsteemi prototüüpe;

Süsteemi arendatakse juurutamise etapis;

Rakendamise etapis viiakse valmistoode organisatsiooni olemasolevasse süsteemi. Käimas on kasutajakoolitus;

Hooldusetapis toimub tarkvaratoote hooldus (kõik lisad või muudatused toote funktsionaalsemaks toimimiseks).

Tarkvaraarenduse elutsükli mudeli valimine on oluline samm. Seetõttu saab projekti jaoks tarkvaraarenduse elutsükli mudeli valiku teha järgmiste protsesside kasutamise käigus.

Tabelitesse paigutatud projekti eristavate kategooriate analüüs.

Vastake iga kategooria küsimustele, tõstes esile sõnad "jah" ja "ei".

Järjesta tähtsuse järgi iga kategooriaga seotud kategooriad või küsimused seoses projektiga, mille jaoks valitakse vastuvõetav mudel.

Arendusmeeskond... Arendusmeeskonna personali valimine toimub vastavalt võimalustele juba enne tarkvaraarenduse elutsükli mudeli valimise aega. Sellise meeskonna omadused (vt lisa G, tabel G.1) mängivad olulist rolli elutsükli mudeli valiku protsessis, mis tähendab, et meeskond saab tarkvaratoote elutsükli mudeli valimisel oluliselt kaasa aidata, kuna see vastutab väljatöötatud elutsükli mudeli eduka rakendamise eest. ...

Kasutajate meeskond... Projekti algstaadiumis saate täieliku pildi kasutajate meeskonnast (vt lisa JA tabel I.1), kes töötavad arendatud tarkvaraga, ning selle tulevastest suhetest arendusmeeskonnaga kogu projekti vältel. Selline vaade aitab valida sobivat mudelit, kuna mõned mudelid nõuavad kasutaja suuremat osalust projekti väljatöötamisel ja uurimisel, kuna arendusprotsessi käigus saab kasutaja nõudeid veidi muuta, siis peab arendaja neid muudatusi teadma ja kuidas neid muudatusi tarkvaras esitada.

4.2 Tarkvaraprojekti eesmärgi ja ulatuse määramine

Väljatöötatud tarkvaratoode kaupade arvestuseks laos automatiseerib laos olevate kaupade kohta andmete vastuvõtmise, struktureerimise ja säilitamise protsessi, samuti lihtsustab aruannete väljastamise protsessi.

Tarkvaraprojekti eesmärkideks on - kaupade arvestuse süsteemi loomine ja juurutamine. See süsteem on mõeldud asutusesiseseks kasutamiseks Cleonelly töötajatele, peamiselt ettevõtte laotöötajatele.

Tarkvaratoote ulatuse kindlaksmääramiseks kirjeldatakse allpool, mis peaks või ei peaks olema tarkvaraprojekt.

Tarkvaraprojekt peab olema:

Organisatsioonisiseseks kasutamiseks;

Projekt mitme kasutaja juurdepääsu rakendamiseks;

Projekt, millel on võimalus sisestada, muuta ja salvestada teavet ettevõtte toote kohta;

Projekt, millel on võimalus süsteemi kasutajate kohta teavet sisestada, muuta ja salvestada;

Projekt, millel on võimalus sisestada, muuta ja säilitada teavet sõlmitavate tehingute objektiks olevate organisatsiooni klientide ja tarnijate kohta;

Projekt, mis viib läbi välisaruandluse moodustamise.

4.3 Struktuuri loomine tööde samm-sammult loetelu jaoks

Unikaalse toote või teenuse (projekti tulemuse) loomiseks peate läbi viima teatud tööjada. Projekti planeerimise ülesanne on täpselt hinnata nende tööde ajastust ja maksumust. Mida täpsem on hinnang, seda kvaliteetsem on projekti plaan. Täpse hinnangu andmiseks peab teil olema hea arusaam projekti mahust, st teadma, millist tööd on vaja selle tulemuse saamiseks teha. Alles pärast projekteerimistööde nimekirja koostamist hinnatakse iga tööde kestust ja eraldatakse nende teostamiseks vajalikud ressursid. Ja alles siis saate hinnata iga ülesande maksumust ja ajastust ning lisamise tulemusena projekti kogumaksumust ja kestust. Seetõttu on töö ulatuse määratlemine projekti planeerimise esimene samm. Projekteerimistööde ulatuse kindlaksmääramine algab projekti etappide (või etappide) määratlemisest. Näiteks süsteemi "Laos olevate kaupade arvestus" loomise projektis saab esile tõsta järgmised etapid:

Tarkvaranõuete väljatöötamine;

Infosüsteemide projekteerimine;

Infosüsteemi juurutamine ja sertifitseerimine;

Süsteemi juurutamine.

Pärast faaside koostise ja nende tulemuste kindlaksmääramist on vaja kindlaks määrata nende faaside järjestus üksteise suhtes ja nende rakendamise tähtajad. Seejärel tuleb määrata, millistest töödest faasid koosnevad, millises järjestuses neid töid tehakse ja millistest tähtaegadest tuleb nende valmimisel kinni pidada.

Samm-sammuline tööde loend (Joonis 4.3) koostati tarkvaratoote nagu MS Project 2003 abil.


Joonis 4.3 – Samm-sammult tööde loetelu

4.4 Tarkvaraarenduse kestuse ja maksumuse hindamine

Kestuse hinnang. See määratakse pärast tööde järkjärgulise loendi koostamist (joonis 4.3, punkt 4.3). Seda hinnangulist kestust saab näha Gantti diagrammi abil (lisa K).

Diagrammid on graafiline vahend projektifailis sisalduva teabe kuvamiseks. Diagrammidelt saate visuaalse ettekujutuse ülesannete järjestusest, nende suhtelisest kestusest ja projekti kui terviku kestusest.

Gantti diagramm on üks populaarsemaid viise projektiplaani graafiliseks esitamiseks ja seda kasutatakse paljudes projektihaldusprogrammides.

MS Projectis on Gantti diagramm projektiplaani peamine visualiseerimistööriist. See diagramm on horisontaalse ajaskaala ja vertikaalse ülesannete loendiga graafik. Sel juhul on ülesandeid tähistavate segmentide pikkus võrdeline ülesannete kestusega.

Gantti diagrammil saab tulpade kõrval kuvada lisainfot (ülesannete kõrval kuvatakse nendega seotud ressursside nimetused ja nende laadimine ülesande täitmisel).

Kulude prognoos

Projekt koosneb ülesandeid , ehk teatud tulemuse saavutamisele suunatud tegevused. Et ülesanne saaks täidetud, ressursse .

Ressursside oluline omadus on nende projektis kasutamise maksumus (Cost). MS Projectis on kahte tüüpi ressursikulusid: ajapõhine määr ja kasutuskulu.

Ajapõhine määr (Rate) väljendatakse ressursi kasutamise kuluna ajaühiku kohta, näiteks 100 rubla tunnis või 1000 rubla päevas. Sel juhul on ressursi projektis osalemise maksumuseks see aeg, mille jooksul see projektis töötab, korrutatuna tunnitasuga.

Sel juhul kasutati ajamäära (Joonis 4.4) Ressursi kasutamise kogukulu on näha joonisel 4.5.

Joonis 4.4 – Ressursikasutuse ajamäär

Sellel joonisel näete, et süsteemiarendaja saab projekti täitmisel 50 rubla tunnis; ärianalüütik saab 45 rubla tunnis, testija 38 rubla tunnis. Ületundide tasud ei ole hinna sees.


Joonis 4.5 - Projekti ressursside kasutamise kogukulud

4.5 Projektiressursside eraldamine

Fragment "Varude arvestuse" süsteemi ressursside jaotusest on näha joonisel 4.6


Joonis 4.6 – Projekti ressursside jaotuse fragment

Iga projektis tehtud töö jaoks määratakse ressurss, mis toimib see töö... Joonisel on näidatud tööjõu kogusumma iga ressursi ja konkreetne summa konkreetsel päeval veedetud tunnid.

4.6 Projekti majandusliku efektiivsuse hindamine

Projekti majandusliku efektiivsuse arvutamine on oluline samm. Siin hakatakse arvutama projekti majanduslikku efektiivsust. See arvutus näitab, kui tulus on projekt või täiesti kahjumlik projekt. Projekti majandusliku efektiivsuse arvutamisel tuleb arvutada projekti tasuvusaeg. Tasuvusaeg näitab perioodi, mille jooksul projekt end ära tasub.

Sisendandmed.

Täiendav kasum projekti rakendamisest (DP) = 38 000 rubla. Lisakasumit ennustasid ettevõtte eksperdid.

Esialgne investeering (IC) = 39396,47 rubla. Esialgsed investeeringud vastavad projekti ressursside kasutamise kogukuludele (Joonis 4.5, p 4.6)

Diskontomäär (i) = 12%.

Ajavahemik, milleks projekt on kavandatud (n) = 2 aastat.

Täiendav kasum projekti rakendamisest (DP) = 38 000 rubla.

Projekti rakendamise aastakulud (Z 1) = 15 000 rubla.

Projekti aastakulud (Z 2) = 10 000 rubla.

Aastane sularaha laekumine (R 1) = 23 000 rubla.

Aastane sularaha laekumine (R 2) = 28 000 rubla.

Investeerimisprojektide hindamisel kasutatakse nüüdispuhasväärtuse arvutamise meetodit, mis näeb ette rahavoogude diskonteerimise: kõik tulud ja kulud viiakse ühte ajahetke.

Keskseks näitajaks vaadeldava meetodi puhul on NPV (puhas nüüdisväärtus) – rahavoogude nüüdisväärtus. See on investeerimistegevuse üldine lõpptulemus absoluutarvudes.

Oluline punkt on diskontomäära valik, mis peaks kajastama eeldatavat keskmist laenuintressi finantsturul.

Nüüdispuhasväärtus (NPV) arvutatakse valemi 4.2 abil

(4.2)

R k - iga-aastased kassalaekumised n aasta kohta.

k - aastate arv, kui kauaks projekti kavandatakse.

IC – stardiinvesteeringud.

i - diskontomäär.

Vastavalt selle valemi arvutustele NPV = 3460,67 RUB

NPV on absoluutne kasv, kuna see hindab, kui palju praegune sissetulek kattub praeguste kuludega. Kuna NPV> 0, tuleks projekt vastu võtta.

Investeeringutasuvus (ROI) arvutatakse valemiga 4.3

(4.3)

Arvutatud (ROI) = 108,78%

Tabel 4.1  Abitabel projekti tasuvusaja arvutamiseks

= 1,84

Tasuvusaeg n ok = 1,84 aastat (1 aasta ja 11 kuud)

Kuna ROI => 100% (nimelt = 108,78%), loetakse projekti kasumlikuks.

(4.4)

Seega on tasuvusindeks (PI) = 1,2

Riis. 6.2.
  • (Ettevõtte infosüsteem)
  • Ettevõtte infosüsteemide sisseostmine
    Ettevõtte infosüsteemidel põhinev tootmisfunktsioonide ja äriprotsesside sisseostmine võimaldab kasutada kaasaegse juhtimise uusimaid saavutusi ja "parimaid praktikaid". Ettevõtte infosüsteemide juurutamine on äriprotsesside ümberkujundamise keskmes (Äriprotsess...
     (Väljahange ja tööjõu väljaostmine: juhtimistehnoloogia kõrgtehnoloogia)
  • Ettevõtte infosüsteemide integratsioonimustrid
    Infosüsteemide integreerimise mustrid on ülemine tase disainimustrite klassifikatsioon. Sarnaselt madalamate klassifikatsioonitasemete mustritega eristatakse integratsioonimustrite hulgas struktuurimustrite rühma. Struktuurimustrid kirjeldavad ühe integreeritud ...
    (Sissejuhatus tarkvaraarhitektuuri)
  • ETTEVÕTTE INFOSÜSTEEMI FUNKTSIOONILISED ÜLESANDED JA ETTEVÕTTE KAASAEGSTE INFOSÜSTEEMIDE PÕHIMOODULID. MOODULITE INTEGREERIMINE
    Mooduli mõiste tähenduslik tähendus eeldab funktsionaalsete alamsüsteemide, funktsionaalsete ülesannete võrdlemist funktsionaalse ülesandepõhise lähenemisega tänapäevaste põhimoodulitega. Riis. 6.2. Funktsionaalsete ülesannete võrdlus ettevõtte kaasaegsete ICISP infosüsteemide põhimoodulitega, ...
    (Ettevõtte infosüsteem)
  • ETTEVÕTTE INFOSÜSTEEMIDE MÕISTE, ARENGUAJALUGU JA KLASSIFIKATSIOON. ETTEVÕTE INTEGREERITUD ETTEVÕTETE INFOSÜSTEEMID
    Infosüsteemide mõiste ja klassifikatsioon muutuvad nende ajaloolise arengu käigus. Eesmärk jääb aga konstantseks ja on seotud ettevõtte juhtimise efektiivsuse saavutamisega. Ettevõtte juhtimise tõhusus sõltub paljude tegurite koosmõjust, nende hulgas: filosoofilised, ajaloolised, ...
    (Ettevõtte infosüsteem)
  • KAASAEGSTE INFOTEHNOLOOGIA OMADUSED ETTEVÕTTE INFOSÜSTEEMIDES
    KAASAEGSED TEHNOLOOGIAD ETTEVÕTETE INFOSÜSTEEMIDES ANDMESISESTUSE KORRALDAMISEKS Teave äritehingute kohta tuleks õigeaegselt sisestada operatiivandmebaasi kõigist selle päritoluallikatest. See võimaldab tõhusalt korraldada edasist andmetöötlust teabes ...
    (Ettevõtte infosüsteem)

    • Arendatava infosüsteemi eesmärgist lähtuvalt kujundame edasi rakenduse moodulstruktuuri. Modulaarse struktuuri defineerimiseks kasutame UML 2.0 notation Component Diagram (Joonis 3.4).

    Riis. 3.4

    Infosüsteem koosneb kolmest komponendist:

    • 1. Liides. Infosüsteemiga kasutaja suhtluse rakendamine. Sisaldab järgmisi mooduleid:
      • · Sisend / väljund - info sisendi ja väljundi organiseerimine IS-iga töötamisel;
      • · Aruandlus - aruandluse korraldamine vastavalt kehtestatud dokumentatsioonivormidele personaliasutuse erinevate valdkondade jaoks;
      • · Otsing – kandidaatide ja vabade töökohtade otsingu korraldamine vastavalt määratud parameetritele;
    • 2. Andmetöötlus. Infotöötlusfunktsioonide rakendamine: andmete otsimine andmebaasist, matemaatiline mudel dokumentide esmase analüüsi ülesandeks jne;
    • 3. DB. Andmesalve rakendus, mis sisaldab teavet klientide kohta.

    Andmebaasi struktuuri kujundamine

    Nagu varem mainitud, salvestatakse infosüsteemis kogu teave ühtsesse andmebaasi. Andmebaasi loogilise struktuuri modelleerimiseks kasutati IDEF1x metoodikat. Selle metoodika järgi ehitusprotsess teabemudel koosneb järgmistest sammudest:

    • · Üksuste määratlus; üksuste vaheliste sõltuvuste määratlemine;
    • · Primaarsete ja alternatiivsete võtmete määramine;
    • · Olemite atribuutide määratlemine;
    • · Mudeli viimine normaalvormi nõutavale tasemele;
    • · üleminek füüsiline kirjeldus mudelid: vastavuste määramine olemi nimi - tabeli nimi, olemi atribuut - tabeli atribuut;
    • · Päästikute, protseduuride ja piirangute määramine;
    • · Andmebaasi genereerimine.

    Olemi-seoste diagramm, mis kirjeldab andmebaasi IDEF1.x mõistes, koosneb kolmest põhiplokist – olemitest, atribuutidest ja suhetest. Kui käsitleme diagrammi domeenireeglite graafilise esitusena, siis olemid ja atribuudid on nimisõnad ning seosed tegusõnad.

    Kuna selle andmebaasi tulevane IS teeb otsinguid, valiti dokumendi peamisteks atribuutideks:

    • - dokumendi nimi;
    • - dokumendi arhiivi saabumise kuupäev (arhiiviteenust osutavad advokaadibürood jälgivad dokumentide säilitusaega. Igal dokumendil on oma säilitusaeg. Paljud väärtpaberid kaotavad aja jooksul oma aktuaalsuse, nende väärtus langeb nullini. Sellised dokumendid tuleks hävitada.Selliste paberite õigeaegne väljavalimine ja dokumentide hävitamine sisaldub advokaadibüroode poolt pakutavate arhiiviteenuste paketis.Säilitusse vastuvõtmisel määratakse igale dokumendile pärast spetsiaalset ekspertiisi säilitusaeg.Pärast seda perioodi , dokument esitatakse hävitamiseks);
    • - dokumendi kuuluvus (liik) (kuna kõik dokumendid jaotati 7 liiki, mille jaoks koostati paremusjärjestus tähtsuse järjekorras);
    • -veeru number;
    • - riiuli number;
    • - kelgu number (need 3 parameetrit on vajalikud dokumendi asukoha määramiseks arhiivis);
    • - dokumendi olemasolu selle lahtris (peate teadma, kas dokument on arhiivis või väljastati see taotlejale).

    Kõigi ühele kliendile kuuluvate dokumentide valimise päringu tulemus peaks välja nägema järgmine, vt joonis 3.5. Esitatud näites oli dokumentide arv tahtlikult piiratud 20-ga.

    Vaatleme nüüd üksikasjalikumalt arendatava infosüsteemi loogilist andmemudelit, mis on toodud joonisel 3.6.


    Riis. 3.5


    Riis. 3.6

    Esitatud andmemudelist on näha, et see sisaldab kolme olemit, millest igaühel on oma atribuutide komplekt ja kaks neist on sõltuvad ja üks mitte.

    Olemil "Töötaja", mis on sõltumatu üksus, on järgmised atribuudid.

    • · Töötaja identifitseerimisnumber – on selle olemi esmane võti;
    • · Töötaja täisnimi;
    • · Spetsialiseerumisvaldkond;
    • · Hinnang;
    • · Lisainformatsioon.

    Klient-üksus on Töötaja-üksusest sõltuv olem, mis tähendab, et iga töötaja saab teenindada palju kliente. Kliendi olemil on järgmised atribuudid:

    • · Passi seeria ja number – on selle olemi esmane võti;
    • · Töötaja identifitseerimisnumber – on selle olemi teisene võti;
    • · Töötaja täisnimi;
    • · Spetsialiseerumisvaldkond;
    • · Hinnang;
    • · Lisainformatsioon.

    Üksus "Dokument" on olemi "Klient" olem, mis tähendab, et iga klient saab arhiivis salvestada palju erinevaid dokumente. Dokumendi olemil on järgmised atribuudid:

    • · Dokumendi identifikaator – on selle olemi esmane võti;
    • · Passi seeria ja number – on selle olemi teisene võti;
    • · Dokumendi nimi;
    • · Kviitungi kuupäev;
    • · gruppi kuulumine;
    • · Veeru number;
    • · Riiuli number;
    • · Kelgu number;
    • · Dokumendi olemasolu lahtris.

    Elemendid, mis tagavad IS-i mis tahes otstarbel toimimise, on loetletud definitsioonis. Mõned neist - vahendid, meetodid ja personal - tagavad IS-i toimimise, teised - teabe säilitamine, töötlemine ja väljastamine - viitavad funktsionaalsetele omadustele, s.o. määrata, millistest infoprotsessidest IS toimimine koosneb. Seetõttu käsitletakse IS-i struktuuri kahel erineval viisil: funktsionaalset struktuuri ja IS-i kui toetavate alamsüsteemide kogumi struktuuri.

    Definitsiooni kohaselt on IS-i funktsionaalsed elemendid järgmised protsesside rühmad (plokid):

      teabe sisestamine välistest või sisemistest allikatest;

      sisendinfo töötlemine ja selle esitamine mugaval kujul;

      teabe väljastamine tarbijatele esitamiseks või teise IS-i edastamiseks;

      tagasiside on informatsioon, mida töötlevad antud organisatsiooni inimesed sisendinfo parandamiseks.

    Funktsionaalne struktuur infosüsteemid on esitatud plokkskeemi kujul (joonis 1), kus süsteemi iga element on esitatud ploki kujul (joonisel - ristkülik) ning näidatud on lingid ja nende suunad noolte abil.

    Üksikuid osi (süsteemiplokke) nimetatakse alamsüsteemideks.

    Funktsionaalsete allsüsteemide hulk ja omavahelised seosed sõltuvad igal konkreetsel juhul ainevaldkonnast ja ettevõtte tegevuse spetsiifikast, mille tegevust infosüsteem pakub.

    IS-i struktuuri võib kujutada ka toetavate alamsüsteemide kompleksina (joonis 2).

    Joonis 1. IC üldistatud funktsionaalne plokkskeem.

    AIS-i puhul, mis erinevad teabetöötluse olemuse ja tüüpide poolest, erineb aga funktsionaalne diagramm töötlemise alamsüsteemide komplekti poolest. Näiteks AIPS (raamatukogu, muuseum, õigusviide jne) toodab kasutaja soovil informatsiooni sisendit, süstematiseerimist, talletamist, otsimist ja edastamist ilma keerukate andmete teisendusteta. Infootsustavad süsteemid: ASOD, ACS, DSS - töötlevad andmebaasi infot kindla algoritmi järgi, kuid erinevad ka infotöötluse alamsüsteemide koostiselt. Projekteerimise automatiseerimisele spetsialiseerunud CAD-süsteemil on ülesehituses spetsiaalsed alamsüsteemid: tehniline dokumentatsioon, ülesannete moodustamine, simulatsioon, arvutuslik ja mõnel võib olla ka ekspertsüsteem (vt plokkskeem joonisel 2).

    Joonis 2. CAD plokkskeem

    Mõelge teist tüüpi IS-struktuurile: toetavate alamsüsteemide kompleksina (joonis 3).

    Infosüsteemi struktuuri võib vaadelda kui allsüsteemide kogumit, sõltumata ulatusest. Alamsüsteem on süsteemi osa, mis on valitud mõne atribuudi järgi. Sel juhul räägivad nad klassifikatsiooni struktuurilisest tunnusest ja alamsüsteeme nimetatakse pakkuvaks.

    Seega saab mis tahes infosüsteemi struktuuri esindada toetavate alamsüsteemide komplektiga.

    Joonis 3. IS struktuur toetavate allsüsteemide tüübi järgi.

    Toetavatest allsüsteemidest eristatakse tavaliselt teavet, tehnilist, matemaatilist, tarkvaralist, organisatsioonilist ja juriidilist tuge.

    Teabe tugi- infoandmete kogum, ühtne teabe klassifitseerimise ja kodeerimise süsteem, ühtsed dokumentatsioonisüsteemid, organisatsioonis ringlevate infovoogude skeemid, samuti andmebaaside koostamise metoodika. Infotoe alamsüsteemi eesmärk on juhtimisotsuste tegemiseks usaldusväärse teabe õigeaegne moodustamine ja edastamine.

    Ühtsed dokumentatsioonisüsteemid luuakse riiklikul, vabariiklikul, valdkondlikul ja piirkondlikul tasandil. Peamine eesmärk on tagada erinevate sotsiaalsete tootmisvaldkondade näitajate võrreldavus. Välja on töötatud standardid, kus on kehtestatud nõuded:

      ühtsetele dokumentatsioonisüsteemidele;

      erinevate juhtimistasandite dokumentide ühtsetele vormidele;

      detailide ja näitajate koostisele ja struktuurile;

      ühtsete dokumentide vormide rakendamise, pidamise ja registreerimise korrale.

    Vaatamata ühtse dokumentatsioonisüsteemi olemasolule paljastab enamiku organisatsioonide uuring terve rea tüüpilisi puudusi:

      äärmiselt suur dokumentide maht käsitsi töötlemiseks;

      samu näitajaid dubleeritakse sageli erinevates dokumentides;

      suure hulga dokumentidega töötamine segab spetsialiste koheste probleemide lahendamiselt;

      on indikaatorid, mida luuakse, aga ei kasutata jne.

    Nende puuduste kõrvaldamine on üks teabetoe loomise ülesandeid.

    Infovoo diagrammid kajastavad info liikumise marsruute, selle mahtusid, esmase informatsiooni tekkekohti ja sellest tuleneva info kasutamist. Selliste skeemide struktuuri analüüsides on võimalik välja töötada meetmed kogu juhtimissüsteemi täiustamiseks.

    Infovooskeemide koostamine ja üksikasjalik analüüs, mis võimaldab tuvastada teabe marsruute ja mahtusid, näitajate dubleerimist ja nende töötlemise protsesse, annab:

      dubleeriva ja kasutamata teabe kõrvaldamine;

      teabe klassifitseerimine ja ratsionaalne esitamine.

    Andmebaasi loomise metoodika tuginedes nende disaini teoreetilistele alustele.

    Metoodika põhimõisted:

      selge arusaam kogu organisatsiooni juhtimissüsteemi eesmärkidest, eesmärkidest, funktsioonidest;

      teabe liikumise tuvastamine selle esinemise hetkest kuni selle kasutamiseni erinevatel valitsustasandid esitatakse analüüsiks infovoo diagrammide kujul;

      dokumendihaldussüsteemi täiustamine;

      klassifikatsiooni- ja kodeerimissüsteemi olemasolu ja kasutamine;

      teadmised info omavahelist seotust kajastavate kontseptuaalsete info-loogiliste mudelite loomise metoodikast;

      infomassiivide loomine arvutikandjatele, mis eeldab kaasaegset tehnilist tuge.

    Seda kontseptsiooni rakendatakse praktiliselt kahes etapis.

    1. etapp - ettevõtte kõigi funktsionaalsete osakondade uurimine eesmärgiga:

      mõista oma tegevuse spetsiifikat ja struktuuri;

      koostada infovoogude diagramm;

      analüüsida olemasolevat dokumendihaldussüsteemi;

      määratleda infoobjektid ja nende omadusi ja eesmärki kirjeldav atribuutide (parameetrite, tunnuste) vastav koostis.

    2. etapp - kontseptuaalse info-loogilise andmemudeli koostamine 1. etapi küsitluse tulemuste põhjal. Selles mudelis tuleb luua ja optimeerida kõik seosed objektide ja nende atribuutide vahel. Infoloogiline mudel on aluseks, millele andmebaas luuakse.

    Tehniline abi- infosüsteemi tööks ette nähtud tehniliste vahendite komplekt, samuti nende vahendite ja tehnoloogiliste protsesside vastav dokumentatsioon

    Tehniliste vahendite kompleks koosneb:

      mis tahes mudeliga arvutid;

      seadmed teabe kogumiseks, salvestamiseks, töötlemiseks, edastamiseks ja väljastamiseks;

      andmeedastusseadmed ja sideliinid;

      kontoriseadmed ja seadmed automaatseks teabeotsinguks;

      töömaterjalid jne.

    Dokumentatsioon vormistab tehniliste vahendite eelvaliku, nende töökorralduse, andmetöötluse tehnoloogilise protsessi, tehnoloogilised seadmed. Dokumentatsiooni võib laias laastus jagada kolme rühma:

      kogu süsteemi, sealhulgas riiklikud ja tööstuslikud tehnilise toe standardid;

      spetsialiseerunud, mis sisaldab meetodite komplekti tehnilise toe arendamise kõigi etappide jaoks;

      normatiivne viide, mida kasutatakse tehnilise toe arvutuste tegemisel.

    Praeguseks on tehnilise toe korraldamisel kaks peamist vormi (tehniliste vahendite kasutamise vormid): tsentraliseeritud ja osaliselt või täielikult detsentraliseeritud.

    Tsentraliseeritud tehniline tugi põhineb suurte arvutite ja arvutuskeskuste kasutamisel infosüsteemis. Selline korraldusvorm hõlbustab standardimise juhtimist ja rakendamist, kuid vähendab personali vastutust ja algatusvõimet.

    Tehniliste vahendite detsentraliseerimine hõlmab funktsionaalsete alamsüsteemide rakendamist personaalarvutites otse töökohtadel. Sel juhul nõutakse personalilt rohkem isiklikku vastutust, juhtkonnal on keerulisem standardimist rakendada.

    Praegu on levinum osaliselt detsentraliseeritud lähenemine – tehnilise toe korraldamine lähtuvalt hajutatud võrgud mis koosneb personaalarvutitest ja suurarvutist mis tahes funktsionaalsete alamsüsteemide jaoks ühiste andmebaaside salvestamiseks.

    Matemaatika ja tarkvara- matemaatiliste meetodite, mudelite, algoritmide ja programmide kogum infosüsteemi eesmärkide ja eesmärkide elluviimiseks, samuti tehniliste vahendite kompleksi normaalseks toimimiseks.

    Fondidele tarkvara seotud:

      tööriistad juhtimisprotsesside modelleerimiseks;

      tüüpilised juhtimisülesanded;

      matemaatilise programmeerimise meetodid, matemaatiline statistika, järjekorrateooria jne.

    osa tarkvara hõlmab kogu süsteemi hõlmavaid ja spetsiaalseid tarkvaratooteid ning tehnilist dokumentatsiooni.

    TO kogu süsteemi hõlmav tarkvara sisaldab kasutajatele suunatud programmide komplekse, mis on mõeldud teabe töötlemise tüüpiliste probleemide lahendamiseks. Nende eesmärk on laiendada arvutite funktsionaalsust, juhtida ja hallata andmetöötlusprotsessi.

    Spetsiaalne tarkvara on konkreetse infosüsteemi loomisel välja töötatud programmide kogum. See hõlmab rakendustarkvarapakette (APP), mis rakendavad väljatöötatud erineva adekvaatsusastmega mudeleid, mis kajastavad reaalse objekti toimimist.

    Tarkvara arendamise tehniline dokumentatsioon peab sisaldama ülesannete kirjeldust, algoritmiseerimise ülesannet, ülesande majanduslikku ja matemaatilist mudelit, testnäiteid.

    Organisatsiooniline tugi See on meetodite ja vahendite kogum, mis reguleerib töötajate suhtlemist tehniliste vahenditega ja omavahel IS väljatöötamise ja käitamise protsessis.

    Organisatsioonitugi rakendab järgmisi funktsioone:

      IS-i kasutama hakkava organisatsiooni olemasoleva juhtimissüsteemi analüüs ja automatiseeritavate ülesannete väljaselgitamine;

      ülesannete koostamine arvutis lahendamiseks, sh lähteülesanne IS-i kujundamiseks ja selle efektiivsuse tasuvusuuring;

      juhtimisotsuste väljatöötamine organisatsiooni koosseisu ja struktuuri kohta, juhtimissüsteemi efektiivsuse tõstmisele suunatud probleemide lahendamise metoodika.

    Organisatsioonitugi luuakse vastavalt projektieelse küsitluse tulemustele andmebaasi ehitamise 1. etapis.

    Juriidiline tugi- infosüsteemide loomist, õiguslikku seisundit ja toimimist määravate õigusnormide kogum, mis reguleerib teabe hankimise, muutmise ja kasutamise korda.

    Õigusabi peamine eesmärk on õigusriigi tugevdamine. Õigusraamistik hõlmab seadusi, määrusi, riigiasutuste otsuseid, korraldusi, juhendeid ja muid ministeeriumide, osakondade, organisatsioonide, kohalike omavalitsuste normatiivdokumente. Õigusabis saab eristada üldosa, mis reguleerib mis tahes infosüsteemi toimimist, ja lokaalset osa, mis reguleerib konkreetse süsteemi toimimist.

    Infosüsteemi arendamise etappide õiguslik tugi hõlmab arendaja ja tellija lepinguliste suhetega seotud regulatsioone ning lepingust kõrvalekaldumise õiguslikku regulatsiooni.

    Infosüsteemi toimimise etappide õigusabi hõlmab:

      infosüsteemi olek;

      personali õigused, kohustused ja vastutus;

      teabe loomise ja kasutamise kord jne.

    See alamsüsteemide komplekt on peaaegu kõigi AIS-tüüpide jaoks üldine. Siiski sõltub toetavate alamsüsteemide struktuur ja keerukus AIS-i tüübist, rakendusalast ja muudest teguritest. Niisiis toimub matemaatilise toe alamsüsteem algse tarkvaraarenduse AIS-is - standardtarkvaraga AIS-is see puudub. Õigusabi alamsüsteem võib ettevõttesisesel otstarbel AIS-is puududa - sel juhul on võimalik piirduda organisatsioonilise toe alamsüsteemiga, milles muuhulgas lahendatakse õigusabi küsimused; Sõltumatutel eesmärkidel kasutataval AIS-il, näiteks infoteenuste süsteemidel, võib olla juriidilise toe alamsüsteem. Faktilist andmebaasi omavatel AIS-idel on ainult infotoe alamsüsteem, milles võib osutuda vajalikuks teatud keeleliste küsimuste lahendamine. Dokumentaalfilmi AIPS-il on välja töötatud keelelise toe alamsüsteem, kuna need süsteemid lahendavad keerukaid probleeme, mis on seotud kasutajapäringute semantilise asjakohasuse tagamisega väljaantud dokumentide sisuga. Ja see pole reeglina mitte ainult morfoloogilise analüüsi tarkvaramoodulid, vaid ka sõnaraamatute komplekt ja nende hooldamise reeglid.

    IP loomise ja rakendamise eesmärgid.

    Mida võib oodata infosüsteemide juurutamiselt?

    Infosüsteemide kasutuselevõtt võib kaasa aidata:

    1. töötajate vabastamine rutiinsest tööst ja selle kiirendamine automatiseerimise tõttu;

    2. paberandmekandjate asendamine magnetketaste või -lintidega, mis toob kaasa paberkandjal dokumentide mahu vähenemise ja seega võimaluse arvutis infotöötlust ratsionaalsemalt korraldada;

    3. infovoogude struktuuri ja dokumendihaldussüsteemi parandamine ettevõttes tänu järjepidevuse mõjule: ühekordne andmesisestus - mitme- ja mitmeotstarbeline kasutamine ";

    4. ratsionaalsemate võimaluste saamine juhtimisprobleemide lahendamiseks (läbi matemaatiliste meetodite ja intelligentsete süsteemide kasutuselevõtu jne):

      uute turuniššide leidmine;

      toodete ja/või teenuste tootmise kulude optimeerimine;

      suhete optimeerimine ostjate ja tarnijatega.

    Infosüsteemide arenguetapid

    IP arengulugu on jagatud etappideks (tabel 2), mis vastavad ligikaudu aktsepteeritud eesmärkide numeratsioonile - lähenemine IP kasutamisele on muutumas.

    Tabel 2. IP arendamise etapid.

    Ajavahemik

    Infokasutuse kontseptsioon

    Infosüsteemide tüüp

    Kasutusotstarve

    1950–1960

    Arveldusdokumentide pabervoog

    Infosüsteemid arveldusdokumentide töötlemiseks elektromehaanilistel arvestusmasinatel

    Dokumentide töötlemise kiiruse suurendamine

    Lihtsustatud arvete töötlemine ja palgaarvestus

    1960–1970

    Hädavajalik abi aruannete koostamisel

    Juhtimisinfosüsteemid tootmisinfo jaoks

    Aruandlusprotsessi kiirendamine

    1970–1980

    Juhtimiskontroll juurutamise (müügi) üle

    Otsustamist toetavad süsteemid

    Süsteemid kõrgemale juhtkonnale

    Kõige ratsionaalsema lahenduse valim

    1980-2000

    Info on strateegiline ressurss, mis annab konkurentsieelise

    Strateegilised infosüsteemid

    Automatiseeritud kontorid

    Ettevõtte ellujäämine ja õitseng

    Esimesed infosüsteemid tekkisid eelmise sajandi keskel. 1950. aastatel olid need mõeldud arvete töötlemiseks ja palkade arvutamiseks ning rakendati elektromehaanilistel arvestusmasinatel. See tõi kaasa kulude ja paberdokumentide ettevalmistamise aja vähenemise.

    60ndad neid iseloomustab suhtumise muutumine infosüsteemidesse. Nendelt saadud infot hakati kasutama mitmel viisil perioodiliseks aruandluseks. Sel päeval vajasid organisatsioonid üldotstarbelisi arvutiseadmeid, mis oleksid võimelised täitma mitmesuguseid funktsioone, mitte ainult arveid töötlema ja palkasid arvutama, nagu varem.

    70ndatel - 80ndate alguses. infosüsteeme hakatakse laialdaselt kasutama juhtimiskontrolli vahendina, mis toetab ja kiirendab otsustusprotsessi.

    80ndate lõpuks. infosüsteemide kasutamise kontseptsioon on taas muutumas. Need muutuvad strateegiliseks teabeallikaks ja neid kasutatakse mis tahes profiiliga organisatsiooni kõigil tasanditel. Selle perioodi infosüsteemid, mis annavad õigel ajal vajalikku teavet, aitavad organisatsioonil saavutada edu oma tegevuses, luua uusi tooteid ja teenuseid, leida uusi müügiturge, pakkuda endale väärilisi partnereid, korraldada toodete väljalaskmist madala hinnaga, ja palju muud.

    Kaasaegne arusaam infosüsteemist hõlmab personaalarvuti kasutamist teabe töötlemise peamise tehnilise vahendina. Suurtes organisatsioonides koos personaalarvuti infosüsteemi tehniline baas võib sisaldada suur- või superarvutit. Lisaks ei tähenda infosüsteemi tehniline teostus iseenesest midagi, kui ei võeta arvesse selle isiku rolli, kellele teave on mõeldud ja kelleta pole seda võimalik saada ja esitada.