Apskaitos informacinės sistemos kūrimas: įmonių, duomenų bazių ir sąsajų moduliai

Apskaitos informacinės sistemos kūrimas: įmonių, duomenų bazių ir sąsajų moduliai!

Yra daug apskaitos programinės įrangos paketų, siūlančių įvairias funkcijas. Jie kainuoja daug mažiau nei tai, ką kainuotų individuali apskaitos programa. Tačiau šie programinės įrangos paketai siūlo tik apskaitos informacinių sistemų struktūrą. Daugiausia jie mažina apskaitos informacinių sistemų programavimo pastangas.

Image Courtesy: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg

Apskaitos informacinių sistemų kūrimas yra daug daugiau nei programinė įranga, skirta knygų skelbimui ir ataskaitų formavimui. Tai taip pat apima duomenų ir platinimo procedūrų nustatymą, taip pat apskaitos informacijos analizę.

Apskaitos informacinės sistemos plėtojimas paaiškinamas ypatingai atsižvelgiant į vidutinės ir didelės apimties verslo įmonės reikalavimus. Tačiau šie veiksmai būtų bendri daugumai kitų verslo įmonių informacinių sistemų.

1. Įmonių modulis:

Informacinių sistemų kūrimo įmonių modulis apima pagrindinių subjektų ir jų tarpusavio ryšių nustatymą, pagrindinių veiklos rūšių nustatymą ir šių veiklos pergrupavimą į posistemius. Tada prioritetai nustatomi remiantis įmonės sąnaudų ir naudos analize.

Identifikuojantys subjektai:

Verslo įmonėje yra daug įmonių, o sąrašas yra toks pat įvairus, kaip ir verslo veikla. Tačiau šiame etape pagrindinis tikslas yra nustatyti plačius subjektus, kurių kiekvienas turi grupę elementarių subjektų. Kerner ⁵ nurodo šešis pagrindinius verslo įmonės subjektus.

Jie yra klientai, produktai, pardavėjai, personalas, įranga ir pinigai. Apskaitos informacinėje sistemoje yra trys pagrindiniai subjektai: sandoriai, sąskaitos ir apdorojimo laikotarpiai. Sąsajos tarp šių subjektų gali būti išreikštos naudojant ER diagramas, kaip parodyta 8.2 pav.

Sandoriai turi būti įvairių rūšių, pavyzdžiui, įplaukos, mokėjimai, pardavimas, pirkimas, turto įsigijimas arba įsipareigojimų grąžinimas ir tt, ir kiekvienas iš jų gali būti vadinamas žemesnio lygio subjektu. Panašiai sąskaitos gali būti įvairių rūšių, pvz., Turtas, įsipareigojimai, pajamos ir sąnaudos.

Kiekvienas iš šių vadovų gali turėti žemesnio lygio subjektus, tokius kaip ilgalaikis turtas ir trumpalaikis turtas. Šie subjektai gali būti toliau suskirstyti į dar žemesnius subjektus, pvz., Žemę ir pastatus, įrenginius ir mašinas. Tačiau šiame etape reikia nustatyti plačius subjektus. Išsami informacija yra sukurta kuriant duomenų bazes.

Subjektai yra identifikuojami atsižvelgiant į informacinės sistemos taikymo sritį ir tikslą bei atsižvelgiant į tai. Pavyzdžiui, jei informacinė sistema yra vertinama kaip strateginė informacinė sistema, plačiosios įmonės turi būti identifikuojamos atsižvelgiant į strategines iniciatyvas, kurias įmonė ketina teikti savo veiklai informacinės sistemos pagalba.

Tai gali būti sąnaudų mažinimas, klientų aptarnavimas, produktų diferencijavimas ir strateginiai aljansai. Tokiais atvejais pagrindiniai subjektai būtų klientai, kanalai, konkuruojančios įmonės, produktai ir kt.

Veiklos analizė:

Kitas svarbus įmonės modulio aspektas yra su ūkio subjektais susijusių veiklos rūšių identifikavimas. Šios veiklos rūšys plačiai apibūdinamos kaip ryšiai ER diagramose. Tačiau detalės gaunamos naudojant veiklos analizę. Esama organizacinė struktūra yra svarbus informacijos apie įmonės vykdomą veiklą šaltinis.

Tačiau, norint sukurti informacines sistemas, nepriklausomas nuo dabartinės organizacinės struktūros, veiklos analizę būtina pagrįsti pagrindiniais jau anksčiau apibrėžtais subjektais. Kitas veiklos analizės lygis apima gyvavimo ciklo veiklos nustatymą. Jei „sandoriai“ yra vienas iš pagrindinių apskaitos informacinės sistemos subjektų, yra keturios plačios gyvavimo ciklo veiklos, ty:

1. Pirkimo gyvavimo ciklas

2. Gamybos gyvavimo ciklas

3. Pajamų gyvavimo ciklas

4. Investicijų gyvavimo ciklas

Panašiai tvarkymo laikotarpis turi dvi pagrindines gyvavimo ciklo veiklos rūšis:

a. Planavimo ir kontrolės gyvavimo ciklas

b. Vidinis ir išorinis ataskaitų teikimo ciklas

Šios gyvavimo ciklo veiklos yra nuolatinės veiklos ir yra atliekamos nuolat. Kiekviena iš šių veiklų gali būti nuosekliai susijusi su kita veikla. Trečiasis veiklos analizės lygis apima gyvavimo ciklo veiklos suskirstymą į funkcijas.

Pavyzdžiui, kiekvienas sandorio tipas turi būti inicijuotas ir pripažintas; tada duomenys apie sandorį turi būti užfiksuoti, koduojami būsimai klasifikacijai, klasifikuoti, apibendrinti ir pateikti. Šios funkcijos turi būti atliekamos skirtingai skirtingų rūšių sandoriams. Funkcijų apibrėžimo procesas sutelkiamas tik į tas veiklas, kurios sukuria, atnaujina ar naudoja informaciją įmonės duomenų bazėje.

Šiame veiklos analizės lygmenyje veikla yra savarankiška, turi aiškiai apibrėžtus pradžios ir pabaigos įvykius arba mazgus ir identifikuojamą asmenį arba asmenų grupę, atsakingą už šios funkcijos vykdymą.

Tada šias funkcijas galima suskirstyti į sub-funkcijas, kol funkcijos bus pakankamai specifinės, kad būtų galima nustatyti kompiuterių programų modulį. Gyvavimo ciklo veiklos suskirstymas į funkcijas ir subfunkcijas padeda nustatyti funkcijas, kurios kartojamos daugiau nei vienoje gyvavimo ciklo veikloje.

Pavyzdžiui, užfiksuotų duomenų klasifikavimo funkcija gali būti atliekama perkant ir parduodant gyvavimo ciklus. Tokia veiklos analizė padeda nustatyti galimybes pagerinti esamą dizainą:

1. pašalinti nereikalingas funkcijas

2. dubliavimosi funkcijų derinimas

3. supaprastinti ir tobulinti apdorojimo metodus

Atleidimą galima nustatyti kruopščiai analizuojant veiklą. Veikla, kuri gali suteikti galimybių tobulinti apdorojimą, apima veiklą:

a. Tai atliekama ir kitur

b. Tai galima derinti su kita veikla

c. Tai gali tvarkyti ir kitas asmuo

d. Tai gali būti atliekama kitu gyvavimo ciklo etapu, kuris nepateikia jokios vertės informacinės sistemos produktui ar paslaugai.

Atsargumo žodis yra tai, kad ne visi atleidimai yra blogi. Iš tiesų, kai kurie atleidimai ar dubliavimasis gali būti sąmoningai leidžiami į sistemą. Tai gali būti daroma siekiant pagerinti sistemos veikimą ir patikimumą.

Pavyzdžiui, kai kurie dubliavimai gali būti reikalingi procedūrų paprastumui užtikrinti ir apdorojimo greičiui gerinti. Dėl atleidimo iš darbo gali atsirasti „visų kiaušinių įdėjimas į vieną krepšį“ ir tai gali turėti įtakos patikimumui. Netikėtų pasekmių rizika ir mažas grąžinimas iš siūlomo naujo metodo ar procedūros yra kiti veiksniai, kurie nusipelno dėmesio prieš siūlant pakeitimus informacinėje sistemoje.

Veiklų grupavimas į posistemius:

Po to, kai veikla apibrėžiama taikant pirmiau pateiktą metodą „iš viršaus į apačią“, jie pergrupuojami į sub sistemas. Svarbus sprendimas, kuris turi būti priimtas šiame etape, yra susijęs su grupavimo pagrindu. Gali būti, kad nėra vieno objektyvaus kriterijaus, pagal kurį būtų nuspręsta, kuri sub sistema yra veikla.

Dabartinė organizacijos struktūra gali būti vienas iš veiklos grupavimo pagrindų. Tačiau dabartinė organizacijos struktūra gali keistis, o informacinės sistemos naudingumas gali būti prarastas.

Norėdami suskirstyti veiklą į posistemę, mes teikiame pagalbą iš organizacijos teorijos. Vienas iš pagrindinių bet kurios geros organizacijos struktūros bruožų yra tas, kad juo siekiama palengvinti veiklos koordinavimą.

Veiksminga bendravimo sistema yra būtina geresnio koordinavimo sąlyga. Todėl labai svarbu grupuoti veiklą taip, kad grupėje būtų palengvintas bendravimas ir kad būtų sumažintas tarpsektorinių ryšių poreikis.

Siekiant atstovauti ir dokumentuoti veiklos grupes į posistemius, naudojamos struktūrinės diagramos arba hierarchinės blokų diagramos. 8.3 paveiksle pateikiama struktūrinė diagrama, kurioje pateikiami pajamų ciklo komponentai.

Panašios struktūros schemos gali būti parengtos kitoms veiklos grupėms, ir, galiausiai, šios posistemės yra tarpusavyje integruotos, teikiant apskaitos informacinės sistemos pagrindinius elementus.

Tokiu būdu suskirstytos veiklos sub-sistemos yra rimtos pretendentės, kad jos būtų organizacijos struktūros subjektai. Veiklos grupavimo metodo privalumas yra tas, kad grupė yra pagrįsta funkcijomis ir ištekliais, o ne geografiniais regionais.

Toks klasterizavimas funkcijų pagrindu užtikrina homogeniškumą tarp grupės narių, susijusių su kiekviena iš posistemių. Informacinių sistemų organizavimo įtaka organizacijos struktūrai nėra neįprasta.

Dažnai informacinių sistemų diegimą lydėjo pokyčiai organizacinėse struktūrose, nes naujos informacinės sistemos keičia žmonių darbo organizavimo būdą.

Todėl dar svarbiau yra tai, kad informacinių sistemų projektuotojai aktyviai bendradarbiautų su organizacijos plėtros žmonėmis, o grupuojant veiklą į grupes ir sub-sistemas. Tai užtikrina ne tik tai, kad nauja struktūra yra pragmatiškesnė, bet ir labiau priimtina žmonėms. Tokiais atvejais perėjimas nuo senosios sistemos į naują yra mažiau skausmingas ir pigesnis.

Nustatyti prioritetus:

Nustačius ir integruojant visas sistemas, prioritetai turi būti nustatyti tarp įvairių sistemų ir požymių. Informacinei sistemai reikės finansinių išteklių.

Be to, gali būti netiesioginės naujos sistemos išlaidos, atsirandančios dėl būtinų operacijų proceso pakeitimų. Todėl labai svarbu įvertinti kiekvieno posistemio ir posistemio privalumus ir trūkumus prieš juos suprojektuojant ir įgyvendinant.

Kiekviena posistemė yra vertinama remiantis aiškiai apibrėžtais vertinimo kriterijais, apibrėžtais kritiniais sėkmės veiksniais (CSF). Šie veiksniai jau nustatyti 8.2 skirsnyje.

Kitas metodas yra „protingumas“, kuriame atitinkami organizacijos nariai susiburia, kad nustatytų prioritetus nustatančius veiksnius. Pirmuoju etapu skatinamas laisvas idėjų srautas.

Pagrindinis principas yra tai, kad šiame etape jokia idėja nėra kvaila ar nesvarbi. Antruoju etapu prasideda pašalinimo procesas ir po diskusijų baigiami pasiūlymai.

Baigę sudaryti veiksnių sąrašą, priskiriami santykiniai svoriai, o kiekvienos siūlomos apskaitos informacinės sistemos komponentui įvertinti yra apibrėžta kriterijaus funkcija.

2. Duomenų bazės modulis:

Apskaitos informacinė sistema apdoroja didelį duomenų kiekį. Vadinasi, duomenų tvarkymas yra vienas iš svarbiausių aspektų jos kūrimo procese. Yra du pagrindiniai duomenų projektavimo metodai:

a. Tradicinis, į taikymą orientuotas požiūris ir. \ T

b. Duomenų bazės metodas.

Tradicinis požiūris:

Tradicinis požiūris į duomenų projektavimą yra orientuotas į taikymą tuo požiūriu, kad kiekvienai programai sukuriama atskira duomenų rinkmena, atitinkanti jos reikalavimus. Kitaip tariant, duomenų failai yra skirti konkrečiai programai ir yra „priklausantys“ programai.

Pavyzdžiui, sąskaitos gautinų sumų paraiškoje turi būti pagrindinis kliento duomenų failas, pardavimo sandorio failas ir klientų sandorių failo gavimas. Šios duomenų bylos naudojamos tik gautoms sumoms.

Šis požiūris tinka mažesnėms apskaitos informacinėms sistemoms dėl savo paprastumo. Tačiau, kadangi informacinė sistema auga duomenų apimties ir analizės sudėtingumo požiūriu, taip pat kyla tam tikrų problemų.

Pagrindinė problema, susijusi su tradiciniu metodu, yra ta, kad taikomosios programos priklauso nuo naudojamų ir manipuliuojamų duomenų rinkmenų. Todėl dėl bet kokio duomenų failo pakeitimo (duomenų papildymo ar ištrynimo požiūriu) būtina keisti visas programas, naudojant duomenų rinkmeną.

Ši duomenų priklausomybė trukdo keisti duomenų rinkmenas, dėl kurių atsiranda nelankstumas. Nesant jokių įrankių rutininiams duomenų tvarkymo veiksmams atlikti, tokie įrenginiai turi būti įtraukti į programas, naudojant duomenų rinkmeną. Tai apsunkina programą. Kita problema susijusi su ad hoc užklausos įvykdymu.

Dėl netikėto tipo užklausos reikia parašyti specialias programas. Tokioms specialiosioms programoms reikia laiko, kad būtų išvystyta ir kad jos būtų naudojamos tik vieną kartą ir todėl yra brangios. Duomenų elementų įrašymo metu yra daug dubliavimosi.

Pavyzdžiui, duomenų elementai, pvz., Kliento pavadinimas, sąskaitos faktūros numeris, kaina ir kt., Gali būti įtraukti į sandorių rinkmenas, skirtas pardavimo užsakymų apdorojimo programai, taip pat gautinų sumų paraiškoms. Tai sukelia duomenų nereikalingumą.

Duomenų redundacija lemia neefektyvų duomenų laikmenų naudojimą. Jis taip pat turi įtakos duomenų kokybei, nes tam tikro duomenų elemento atnaujinimas negali vykti visose rinkmenose, kuriose tas duomenų elementas yra saugomas.

Duomenų bazės metodas:

Šiuolaikinis požiūris į duomenų projektavimą yra duomenų bazės metodas. Šis požiūris grindžiamas prielaidomis, kad kelioms programoms reikalingi daug bendrų duomenų rinkinių. Todėl geriau turėti bendrą duomenų saugyklą, kuri atitiktų kiekvienos informacinės sistemos duomenų reikalavimus.

Bendra saugykla vadinama duomenų baze ir ją valdo valdymo sistema, vadinama duomenų bazių valdymo sistema (DBMS). DBVS yra programinė įranga, specialiai sukurta duomenų bazėms tvarkyti pagal taikomųjų programų prašymus, taip pat iš tų, kurie tiesiogiai gaunami iš vartotojų. 8 pav. Parodyta duomenų bazės aplinkos koncepcinė struktūra.

Duomenų bazės metodas rūpinasi programų taikymo problemomis. Jis užtikrina duomenų nepriklausomumą, nes DBVS rūpinasi duomenų srautu iš duomenų bazės į programų programas. Naudotojui nereikia nerimauti dėl duomenų vietos duomenų bazėje. Išlaikomas duomenų žodynas, o duomenys gali būti skambinami naudojant žodyną, nurodytą duomenų žodynuose.

Duomenų bazės metodas taip pat sumažina taikomųjų programų dydį ir sudėtingumą, nes įprastos duomenų apdorojimo operacijos, tokios kaip rūšiavimas, atliekamos DBVS. DBVS taip pat naudojamas ad hoc užklausos poreikiams patenkinti. DBVS naudoja struktūrinę užklausos kalbą (SQL) kaip bendravimo tarp vartotojo ir duomenų bazės kalbą.

Kalba yra labai paprasta ir gana arti anglų kalbos. Tai užtikrina, kad vartotojas gali gauti informaciją iš duomenų bazės, kai tai reikalinga. Mokytojų, kuriems reikia ad hoc užklausų, mokymas yra minimalus, o kelias valandas treniruočių gali suteikti pagrindinius įgūdžius vartoti kalbą. Galbūt svarbiausias duomenų bazės metodo privalumas yra duomenų bazių atleidimo sumažinimas.

Yra daug modelių, kurie paprastai naudojami kuriant duomenų bazes. Tačiau modernus požiūris yra laikytis ER duomenų bazės modelio. Šis požiūris yra „iš viršaus į apačią“ metodas, o ankstesniuose verslo modulyje parengti ER grafikai tampa pradiniu tašku.

Kiekvienam subjektui ir santykiams atributai identifikuojami ir dokumentuojami išplėstinėse ER diagramose (EER diagramose). Apskaitos informacinėje sistemoje EER gali būti sudarytas kiekvienam subjektui (sandoris ir sąskaitos), o sandorių sąskaitų santykis (efektas) parodytas ER diagramoje. Pavyzdžiui, pardavimo sandoriui atributai gali būti nurodyti ir dokumentuoti, kaip parodyta 8.6 pav.

Šie atributai tampa duomenų elementais (laukais) kiekvienos įmonės duomenų failo įraše (šiuo atveju pardavimo sandorio failas). Panašiai kitiems subjektams ir santykiams sudaromos tokios išplėstinės ER (EER) diagramos.

Nustačius šiuos požymius, tikėtina, kad kai kurie atributai yra bendri skirtingose ​​EER diagramose. Siekiant išvengti tokių bendrų požymių dubliavimosi, atliekamas duomenų normalizavimas.

3. Sąsajos modulis:

Sąsajos modulis apibrėžia duomenų elementų šaltinius ir sistemoje naudojamų įvesties / išvesties ir dialogo ekranų formatus. Taip pat apibrėžiami ataskaitų formatai ir ekranai, skirti navigacijai iš vienos informacinių sistemų dalies į kitą.

Kitaip tariant, modulis susijęs su vartotojo ir mašinos sąsajos apibrėžimu. Sąsajos modulio svarba padidėjo dėl padidėjusio vartotojų ir informacijos sistemų ryšio.

Duomenų įvedimo ir duomenų užklausos tapo interaktyvios. Daugeliu atvejų įvesties formos pašalinamos iš proceso ir duomenų įvedimas vyksta tiesiogiai. Keičiantis duomenų užklausos reikalavimams daugelis ataskaitų formų yra pernelyg standžios. Interaktyvūs ataskaitų ekranai suteikia daugiau lankstumo duomenų užklausoje ir leidžia vartotojams nustatyti ataskaitų formatus peržiūrai ir spausdinimui.

Įvesties ekranai:

Įvesties ekranai apibrėžiami atsižvelgiant į natūralų verslo veiklos procesą. Todėl jie pirmiausia priklauso nuo formų, kurios yra naudojamos įrašyti duomenis rankiniu būdu, kai juos pirmą kartą gauna įmonė. Šios formos, apskaitos informacinėje sistemoje, gali apimti sąskaitą faktūrą, pirkimo užsakymą, pardavimo užsakymą, išlaidų čekį ir kt.

Taigi sąsajos modulyje taip pat peržiūrimos formos; pertvarkyti ir įvesties ekranai apibrėžiami atsižvelgiant į įmonės naudojamas formas. Apskaitos informacinėje sistemoje reikia atidžiau stebėti ekrano dizainą.

Nedidelis įvesties ekrano patobulinimas, kuris taupo duomenų įvedimą, gali sukelti didelių santaupų, nes duomenų įvedimo ekrano naudojimas yra labai didelis. Projektuojant įvesties ekraną gali būti atsižvelgiama į šiuos veiksnius:

a) atitikimas formoms:

Įvesties ekrano formatas turi atitikti įvesties formas. Kartais mokama priimti tą patį formatą, kurį naudoja įvesties forma. Kiek įmanoma, net ekrano fono spalva gali būti suderinta su įvesties formos spalva.

(b) Interaktyvus:

Įvesties ekranas turėtų būti interaktyvus. Ji turėtų nurodyti duomenų įvedimo klaidas atvykimo metu ir leisti pataisymus. Kiekvienas duomenų elementas turi turėti tam tikrą duomenų patvirtinimo sąlygą ir bet koks tokių duomenų patvirtinimo sąlygų pažeidimas turėtų būti automatiškai paryškintas įvedant duomenis.

Pavyzdžiui, duomenų įvedimo langas, skirtas sąskaitos faktūros įvedimui, turi nurodyti klaidą įrašant datą, jei data yra neteisinga. Data gali būti negaliojanti, nes ji yra už ataskaitinio laikotarpio ribų arba įvestas mėnuo yra didesnis nei dvylika.

c) Nuoseklumas:

Įvesties ekranai turėtų būti nuoseklūs apibrėžiant terminus ir vietą tam tikrų tipų duomenų elementams. Jis padeda sumažinti mokymo laiką, nes jis pagerina supratimą; pavyzdžiui, sandorio data visada gali būti nurodyta kiekvieno sandorio dokumento dešiniajame kampe.

d) Paprastumas:

Vienas pagrindinių gero įvesties ekrano bruožų yra paprastumas. Per daug pabrėžtų sekcijų, vertybių ar atributų mirkymas arba per daug dėžių ir pabrėžimas tik padidina sudėtingumą ir painiavą. Kartais pyptelėjimais nurodomos duomenų įvedimo klaidos. Tokie pyptelėjimai turėtų būti protingai naudojami ir apskritai jie turėtų būti vengiami.

e) Lankstumas:

Įvesties ekranas turi būti pakeistas. Ji turėtų leisti vartotojams atlikti pakeitimus duomenų elemento papildymo ar ištrynimo ir perkėlimo požiūriu. Pakeitimo procedūra turėtų būti paprasta. Šiomis dienomis iš įvairių programinės įrangos gamintojų prieinami ekrano generatoriai siūlo tokias funkcijas, kaip vilkimas ir pataisymas / išskleidimas iš bet kokio duomenų elemento iš ekrano, naudojant įprastą rodymo įtaisą, pvz., Pelę.

f) Individualus:

Ekranai turi būti pritaikyti kiekvienai vartotojų kategorijai. Tai sumažintų pernelyg ilgas pradžios ir atvykimo procedūras.

Ataskaitų ekranai:

Ataskaitos gali būti parengtos tolesnei analizei, kurią atlieka kita kompiuterio programa arba pats vartotojas. Duomenys, skirti apdoroti kompiuterinėmis programomis, pvz., Skaičiuoklės, statistiniai paketai, tekstų procesoriai, saugomi duomenų rinkmenose.

Geriau juos įtraukti į standartinį duomenų formatą, kad juos būtų galima lengvai pasiekti. Vartotojams skirtos ataskaitos paprastai laikomos teksto, lentelių ir grafikų pavidalu. Turėtų būti stengiamasi užtikrinti, kad ataskaitos būtų parengtos ir pateikiamos laiku, tiksliai, aiškiai ir pigiai.

Dialogo ekranai:

Dialogo ekranai yra tie, kurie naudojami identifikuoti ir atlikti informacinės sistemos užduotis. Jie apibrėžia, ką galima padaryti naudojantis informacine sistema, kaip naršyti iš vienos užduoties / procedūros į kitą ir kaip atlikti įvairias užduotis, kurias leidžia informacinė sistema.

Šie ekranai turėtų būti paprasti ir nedviprasmiški. Paprastumą galima įdiegti pateikiant grafinę vartotojo sąsają (GUI) ir turint ribotą skaičių meniu elementų viename ekrane. Navigacijos procedūra iš vieno meniu į kitą turėtų būti paprasta, teisinga ir lengvai sekama. Ji taip pat turėtų atkreipti dėmesį į klaidų naudojimą pasinaudodama pasirinkimo galimybėmis ir paraginti ištaisyti procedūrą.

CASE įrankiai ekrano dizainui:

Formų, ekranų ir ataskaitų projektavimui yra prieinami įvairūs CASE įrankiai. Šie įrankiai turi pranašumą, nes siūlome projektavimo aplinką, kuri yra lanksti ir paprasta suprasti net ir naujam vartotojui.

Kadangi šiose priemonėse yra ekrano prototipų kūrimo įrenginiai, vartotojai gali aktyviau dalyvauti ekranų kūrimo procese. Žinoma, tokios priemonės leidžia greitai keisti programuotojus ir pagerinti jų produktyvumą, sukurdamos galutinio įgyvendinimo kodus. Dėl to sumažėja kūrimo laikas.

Kai formos, įvesties / išvesties ekranai ir dialogo langai yra paruošti, jie turi būti išbandyti ir atitinkamai modifikuoti. „CASE“ įrankiais sukurtas formas ir ekranus galima lengvai keisti. Todėl reikia stengtis pagerinti sistemos priimtinumą tinkamai išbandant ir keičiant formas ir ekranus.

4. Programų modulis:

Šis modulis praplečia subjekto sistemas, jau nustatytas įmonės modulyje. Šiame modulyje išsamiai aprašytos kiekvienos struktūros schemoje nurodytos posistemės.

Kitaip tariant, taikymo modulis pirmiausia susijęs su procesais, susijusiais su įvesties duomenų konvertavimu į vertybes, kurios sudaro ataskaitų dalį, kaip apibrėžta sąsajos modulyje. Galima pažymėti, kad turi būti apibrėžti tik tie procesai

a) keisti duomenų bazėse esančias vertes; \ t

(b) kurios nėra duomenų bazės dalys, bet yra reikalingos sąsajos modulyje apibrėžtose ataskaitose.

Duomenys, kurie jau yra duomenų bazėje, gali būti pasiekiami naudojant DBVS užklausos kalbą, kaip naudotojų reikalavimą, nesukuriant šiam tikslui programų. Taigi, taikomojo modulio užduotis yra sumažinta jau atliktu darbu duomenų bazės projektavimo ir ekrano dizaino metu.

Duomenų srauto schema:

Vadovo vaidmuo šiame modulyje iš esmės yra pagrindinė apdorojimo procedūra. Išsamius algoritmus paprastai apibrėžia ir dokumentuoja informacinės sistemos specialistas, žinoma, su aktyvia vadovo pagalba.

Priemonė, naudojama norint išreikšti įvesties duomenis konvertuojant į produkciją, yra duomenų srauto diagrama (DFD). Jame aprašomas duomenų srautas. Jame apibrėžiama, kas turi būti padaryta ir ignoruojama, kaip tai turi būti padaryta ar kaip ji buvo daroma anksčiau. Šis požiūris leidžia keisti sistemą, o dabartinės sistemos trūkumai gali būti pašalinti pagal šį metodą.

DFD simboliai:

DFD naudoja keturis pagrindinius simbolius. Jie yra:

i) Terminatorius:

Terminatorius yra išorinis duomenų srauto šaltinis arba išorinis duomenų kriauklė. Tai išorinis subjektas arba objektas, pvz., Klientas, pardavėjas, akcininkai ir tt Kadangi terminatoriai yra išoriniai subjektai, ryšys tarp terminalų yra pašalintas iš sistemos. Terminalą simbolizuoja stačiakampis (paprastai, šešėlis), o etiketė dedama į stačiakampį.

ii) Duomenų srautas:

Duomenų srautui būdingas duomenų elementų, susijusių su įvykiu, kurį inicijuoja terminalas, serija. Jis simbolizuojamas su rodykle DFD ir srauto kryptis nurodoma rodyklės kryptimi. Rodyklės paprastai yra pažymėtos, nebent jos nukreiptos į duomenų rinkmenas arba iš jų. Kaip minėta anksčiau, DFD neįtraukti duomenų srautai tarp dviejų galinių įrenginių, todėl duomenys negali tekėti tiesiogiai tarp dviejų terminalų.

iii) procesas:

Procesas gaunamus duomenis paverčia peradresavimu į duomenų saugyklą arba terminatorių. Jį simbolizuoja stačiakampis su apvaliais kampais arba apskritimu. Žinoma, jis yra paženklintas veiksmažodžiu.

(iv) Duomenų saugykla:

Failai yra duomenų saugyklos informacinėse sistemose ir yra pateikiami DFD atviruose stačiakampiuose. Paprastai jie atitinka duomenų bazių lenteles. 8.7 pav. Pateiktas dalinis pardavimo užsakymų apdorojimo duomenų srauto diagramos vaizdas.

Galima pažymėti, kad yra naudojami ir kai kurie papildomi simboliai ir nedideli simbolių, kurie atstovauja įvairiems DFD komponentams, pokyčiai. Pirmiau minėti simboliai yra dažniausiai naudojami ir tokie, kaip Gane ir Sarson pasiūlyta grafinė konvencija.

Daugelis laiko, vadybininkas randa DFD piešinį labai sunku ir varginantis patyrimas. Kiekvieną kartą, kai gaunamas DFD, pastebima, kad ignoravo vieną ar kitą duomenų srauto aspektą. Laimei, esamos CASE priemonės turi įrenginių DFD kūrimui ir modifikavimui. Tačiau pradedantiesiems patariama išspręsti šią problemą:

(a) Nustatykite visus įvesties duomenų srautus ir išvesties duomenis atskirai kartu su terminatoriais, įvedant įvesties duomenų srautus kairėje pusėje ir išėjimo duomenų srautą į dešinę.

b) Pažymėkite terminatorius naudodami duomenų srauto daiktavardį arba būdvardžių pavadinimus.

(c) Nustatykite procesus, vykstančius iš įvesties duomenų srautų, ir atgal nuo išvesties duomenų srautų, kol jie susitiks viduryje.

(d) Pažymėkite procesus naudodami veiksmažodžių pavadinimus.

Vadybininkas turi būti pasirengęs perrašyti DFD, nes daug laiko, duomenų srautai valdytojui tampa aiškūs tik po DFD. Vartotojų dalyvavimas šiame etape yra labai naudingas ne tik mažinant valdytojo pastangas, bet ir tobulinant DFD.

DFD testavimas:

Siūloma, kad DFD būtų kruopščiai išbandyta prieš jį baigiant. Toliau pateikiamos kelios dažniausios DFD dizaino klaidos:

a. Terminatoriaus etiketė gali būti asmens ar įmonės pavadinimas, o ne klasė. Pavyzdžiui, terminatorius gali būti pažymėtas kaip M / s. BR Ltd. vietoj vienintelio pardavėjo. Kita klaida gali būti ta, kad vežėjas yra vietoj išorinio subjekto, kuris tiesiogiai susijęs su duomenų srautu, kaip terminatorius.

b. Duomenys gali tekti tiesiogiai iš vieno terminalo į kitą terminatorių.

c. Duomenų srautas negali būti nurodytas procesui arba iš jo.

d. Duomenų srautas nurodomas iš terminatoriaus į duomenų saugyklą (failą) arba iš failo į terminatorių arba tarp dviejų failų be apdorojimo.

e. Procesai yra pažymėti kaip objektai, pvz., Sąskaita arba daiktavardis, pvz., Užsakymo sekretorius.

Po kiekvienos posistemės DFD parengimo, būsimos duomenų apdorojimo detalės gali būti išdėstytos ir aprašytos struktūrizuotu anglų kalba (psedo kodai). Šie psedo kodai vėliau naudojami programoms koduoti. Vadovo vaidmuo šiame procese apsiriboja tik informacinių sistemų specialisto padėjimu nustatyti ir suprasti apdorojimo algoritmus.

5. Įgyvendinimo modulis:

Šis modulis pirmiausia susijęs su sistemos testavimu, naudotojų mokymu ir sistemos diegimu.

Sistemos testavimas:

Įvairių modulių testavimas atliekamas įvairiais kūrimo etapais. Auksinė taisyklė, į kurią reikia atkreipti dėmesį bandant, yra ta, kad bandymai turėtų būti atliekami siekiant nustatyti, kaip sistema gali žlugti. Nereikėtų įrodyti, kad sistema veiks pagal projektavimo specifikaciją. Sistemos testavimas yra atsakymų į du pagrindinius klausimus paieškos procesas:

1. Ar informacinė sistema tenkina įmonės informacijos poreikius? Procesą, kuriuo siekiama atsakyti į šį klausimą, informacinių sistemų specialistai vadina sistemos patvirtinimo procesu.

2. Ar informacinė sistema veikia tinkamai? Tikrinimo procese siekiama atsakyti į šį klausimą.

Kadangi klaidų pobūdis ir laipsnis yra skirtingi skirtinguose sistemos kūrimo etapuose, skirtingi moduliai ir visa sistema atlieka skirtingus testus.

Vieneto testas:

Modulio lygiu naudojami bandymai gali būti vadinami vieneto bandymais. Šie bandymai atliekami siekiant nustatyti sąsajų, duomenų bazių, aritmetinių operacijų ir valdymo logikos klaidas. Jie atliekami naudojant informacinės sistemos modulį, skirtą bandymų duomenims, specialiai suprojektuotiems patikrinti, ar sistema:

a. Priima neteisingus duomenų tipus (pvz., Priima vardinę skaitmeninę vertę);

b. Priima iš galiojančių intervalo duomenų (pvz., Priima datą su mėnesiu, kuris yra didesnis nei 12);

c. Neteisingai pereina nuo procedūros į kitą procedūrą.

Sistemos testas:

Kadangi vieneto bandymai atliekami atskirai, būtina, kad integracijos bandymai būtų atliekami siekiant patikrinti, ar šie įrenginiai veikia kaip grupė. Dėl klaidų pobūdžio skirtumų tikrinant galiojimą ir patikrinant sistemą reikia laikytis skirtingų testavimo strategijų. „Fertucksug“ siūlo tris informacinės sistemos bandymo strategijas:

a) Išvalyti langelių bandymus:

Šioje strategijoje bandymai yra skirti nustatyti, ar apdorojimo procedūros atitinka paraiškos reikalavimus. Tai gali būti pasiekta padedant kitiems informacinių sistemų specialistams, kurie nebuvo tiesiogiai susiję su kūrimo etapu.

Taip pat gali būti naudojamas struktūrizuotas metodas. Šiuo metodu asmenų grupė peržiūri procedūras, pirmiausia pažiūrėdama į klaidas nulemiančias dalis ir nustato pataisas, kurias reikia atlikti. Tada grupės nariai įvertina išvesties, kurią sistema siūlys tam tikram įvesties tipui, rezultatus ir patikrins, ar sistemos išvestis yra teisinga.

b) juodųjų dėžių bandymai:

Šioje strategijoje sistema tikrinama dėl negaliojančių duomenų ar duomenų, kurie gali sukelti klaidų sistemos veikime. Išėjimas patikrinamas, siekiant nustatyti, ar įvyko klaida. Pavyzdžiui, duomenys gali turėti neigiamos vertės užsakytam kiekiui arba dalinės vertės kintamajam, kuris gali užimti tik visą vertę.

c) Bandymo langeliuose bandymas:

Šioje strategijoje daroma prielaida, kad niekada neįmanoma pateikti visiškai klaidų be informacijos sistemos. Taigi, atlikus visus bandymus ir modifikacijas, būtina įvertinti sistemoje likusių klaidų skaičių. Norėdami įvertinti šį skaičių, sistemoje gali būti kelios klaidos. Tada bandymai vėl atliekami siekiant nustatyti klaidas.

Nustatytų įvestų klaidų dalis laikoma tikrųjų klaidų, nustatytų ankstesniais bandymais, santykiu. Taigi, jei 90% įvestų klaidų buvo aptikta tikrinant langelį, tuo tarpu, kai iš pradžių buvo nustatyta 450 klaidų, kai buvo atliktas aiškus bandymas ir juodųjų dėžių bandymai, tai reiškia, kad sistemoje vis dar lieka 50 realių klaidų.

Diegimas:

Diegimas - tai senosios sistemos pakeitimo nauja sistema. Apskritai yra keturi diegimo būdai. „Šaltas“ įrengimas atliekamas, kai senoji sistema nedelsiant nutraukiama ir pakeičiama nauja sistema.

Toks įrenginys turi greitesnį psichologinį koregavimą, nes naujoji sistema bus naudojama. Tačiau toks požiūris gali būti netinkamas, jei senieji ankstesnės sistemos duomenys yra vertingi arba nauja sistema turi tam tikrų problemų. Įdiegiant apskaitos informacines sistemas, šis požiūris nebuvo priimtinas. Alternatyvūs metodai yra šie:

a) Bandomasis įrenginys:

Sistema gali būti įdiegta naudoti tik pasirinktos reprezentatyvios vartotojų grupės, kuri išbando sistemą iš tikrųjų ją naudodama. Kiti naudotojai ir toliau naudoja seną sistemą. Kai rūpinasi sistemos problemomis, kiti vartotojai pradeda naudotis sistema. Šis požiūris taip pat nėra labai populiarus apskaitos informacinėse sistemose, nes visą apskaitos duomenų bazę reikia atnaujinti, kad ją galėtų naudoti vartotojai.

Naudotojo informacijos reikalavimai perkelia organizacijos struktūrą ir padalinius. Tačiau šis metodas gali būti taikomas visoms apskaitos įmonėms, pvz., Filialui, regioniniam biurui ir pan. Taigi, pasirinktos šakos gali naudoti apskaitos informacinę sistemą. Nustačius, kad jie yra be klaidų, juos gali naudoti ir kitos šakos.

b) Įrenginys, kuriame įdiegiamas etapas:

Pagal šį metodą įrengimas vyksta etapais. Šie etapai yra nepriklausomi informacinės sistemos komponentai. Taigi, apskaitos informacinės sistemos pajamų gyvavimo ciklas gali būti pirmą kartą įdiegtas ir kiti gyvavimo ciklai gali būti vienas po kito. Šis požiūris padeda sutelkti dėmesį į pasirinktą sistemos dalį. Tai padeda pagerinti sistemos priimtinumą tarp vartotojų, nes leidžia vartotojui lengvai susidoroti su pokyčiais.

c) Lygiagretus įrengimas:

Lygiagretus įrengimas reiškia tiek senosios, tiek naujos sistemos valdymą tam tikrą laiką, kol bus įrodyta naujos sistemos nauda. Šis metodas yra populiariausias apskaitos informacinėje sistemoje, nes tai yra saugiausias iš visų kitų metodų. Vienintelis sunkumas čia yra lygiagrečios veiklos sąnaudos ir tendencija pratęsti lygiagrečiai veikiančius laikotarpius tiems, kurie priešinasi pokyčiams.

Post įgyvendinimo apžvalga:

Kiekviena sistema turi būti peržiūrėta, kai įgyvendinimas bus baigtas. Tokia apžvalga ne tik padeda nustatyti sistemos silpnąsias vietas, bet ir rengia ateities pakeitimų darbotvarkę. Tiesą sakant, tai yra mokymosi procesas. Sistemos auditas taip pat gali būti atliekamas siekiant ištirti, kaip sėkmingai sistema yra išlaidų, pristatymo grafiko, išsamumo ir kokybės požiūriu.