Programinės įrangos kūrimas: skirtumas tarp nuoseklaus požiūrio ir modulinio metodo

Perskaitykite šį straipsnį ir sužinokite apie skirtumą tarp nuoseklaus požiūrio ir modulinio požiūrio!

„Fertuck“ siūlo, kad tradicinis nuoseklus sistemos analizės ir projektavimo etapų procesas turėtų paskatinti naują procesą, apimantį grįžtamąjį ryšį keliais plėtros etapais.

Tradiciniai ir modernūs procesai pavaizduoti .7.5 pav.

Tradicinis sistemos analizės ir projektavimo procesas buvo nuoseklus, o vieno etapo užbaigimas buvo būtina sąlyga kitam etapui pradėti. Taigi, šis procesas suteikė nedaug lankstumo pokyčiams tarp etapų.

Ankstyvo vystymosi stadijos nebuvimas negalėjo būti ištaisytas netgi tada, kai jis buvo atsekamas vėlesniame etape, nes tai reikštų daugybę pokyčių, apimančių daug laiko reikalaujančius procesus. Taigi ji pasiūlė griežtas informacines sistemas ir leido ribotą atsakomybės delegavimą. Tai lėmė ilgesnius plėtros laikotarpius net ir mažesnėms informacinėms sistemoms.

Šiuolaikinis požiūris įveikia šiuos apribojimus ir naudoja modernius programinės įrangos įrankius, kurie suteikia lankstumo per visą kūrimo laikotarpį. Tai leidžia perduoti atsakomybę didesnėje grupėje ir pagreitinti plėtros procesą.

Kiekvieno proceso modulio darbas gali prasidėti beveik vienu metu, o kiekvieno modulio dizainas gali būti išbandytas vienu metu. Bet kokia modelyje nustatyta problema gali būti lengvai prižiūrima be didelių pakeitimų kitoje.

Tai įmanoma naudojant programinės įrangos priemones, kurios stengiasi automatizuoti kai kurias veiklos rūšis kiekviename programinės įrangos kūrimo etape.

Kiekvienas modulis čia apimtų tris pagrindines užduotis:

i. Sistemos analizė

ii. Naujos sistemos projektavimas

iii. Sistemos testavimas ir keitimas

Šios užduotys pateikiamos kiekvienam moduliui aukščiau esančioje diagramoje. Pažiūrėkime, kaip šios užduotys atliekamos kiekvienam moduliui ar žingsniui moderniame sistemos kūrimo procese.

Įmonių modulis:

Šiame sistemos analizės ir projektavimo pastangų skyriuje pateikiamas bendras įmonės vaizdas. Jame nurodomi subjektai, kuriuos organizacija renka ir suskirsto pagal jų tarpusavio ryšius. Šios grupės taip pat vadinamos sub sistemomis.

Subjektai gali būti tokie asmenys kaip klientai, pardavėjai, darbuotojai ir kt .; daiktai, pvz., produktai, įrenginiai ir įranga, kitas turtas ir kt .; įvykiai, pvz., pardavimai, pirkimai, išlaidos, įplaukos ir mokėjimai ir tt; darbo vietos, užduotys ir veikla ir tt Šie veiksmai yra tarpusavyje susiję ir šie santykiai sudaro jų grupavimo į sub sistemas pagrindą.

Visa sub-sistemų grupė sudaro įmonę. Didžiosios informacinės sistemos turi sutelkti dėmesį į visą posistemių spektrą. Kita vertus, smulkiojo verslo taikymas gali turėti ribotą taikymo sritį ir todėl gali atsižvelgti tik į kai kurias įmonės sistemas. Nustačius posistemius, nustatomi informacinės sistemos kūrimo prioritetai.

Įmonės modulio analizė apsiriboja tokių subjektų ir ryšių identifikavimu kiekvienoje iš posistemių. Šiame analizės etape nustatoma pagrindinė verslo proceso struktūra, pagrindiniai duomenų reikalavimai, remtinos veiklos ir nustatomi taikymo srities prioritetai.

Tikslūs duomenų reikalavimai šiame etape nėra žinomi ir bandoma gauti galutinės duomenų bazės apytikslį. Taigi, subjektų santykių analizė, šiuo metu yra preliminari ir trūksta duomenų, reikalingų duomenų bazėms kurti.

Šiame etape atlikta analizė taip pat apima veiklos, kurią turi remti informacinė sistema, nustatymą.

Tai turėtų apimti:

i. veiklos nustatymas įvairiuose įmonės lygiuose.

ii. juos struktūrizuojant atsižvelgiant į įmonės organizacinę struktūrą.

iii. identifikuoti subjektus, kuriuos naudoja kiekviena veikla ar įtaką.

iv. šios veiklos grupavimas į sub sistemas.

Duomenų bazės modulis:

Įmonės modulis suteikia pagrindinę duomenų reikalavimų sistemą. Duomenų bazės modulis sukuria išsamų duomenų bazių projektą. Šiame modulyje naudojamos išsamios ER diagramos, apibrėžiančios duomenų savybes. Atsižvelgiant į šias savybes, bandoma užtikrinti duomenų vientisumą.

Išsamios ER diagramos paverčiamos reliacinių duomenų bazių failų struktūra. Šios preliminarios bylos struktūros yra peržiūrimos konsultuojantis su vartotojais. Šiame modulyje normalizavimo procesas naudojamas siekiant pašalinti atleidimus ir anomalijas.

Sąsajų modulis:

Šiame modulyje įvesties ekrano formatas nustatomas naudojant ekrano generatorius. Taip pat nurodomi ataskaitų, kurių naudotojams reikės, formatai. Vartotojų dalyvavimas šiame modulyje galbūt yra giliausias iš visų kitų modulių.

Šiame modulyje apibrėžiamas pokalbio tarp vartotojo ir kompiuterinės sistemos būdas. Būtina užtikrinti įvesties ekrano formatų ir susijusių įvesties dokumentų suderinamumą. Jie taip pat turėtų būti išsamūs ir turėtų leisti greitai įvesti klaidą.

Taikymo modulis:

Šis modulis nustato procesus, kuriuos turi atlikti programa. Šie procesai taip pat padeda apibrėžti tikslią taikymo sritį. Dizaineriai dažniausiai naudoja duomenų srautų diagramas ir sistemos srautų schemas, kuriose išsamiai aprašomi įvairūs taikomieji procesai. Trumpai tariant, šis modulis apibrėžia, kaip įėjimai konvertuojami į norimus rezultatus.

Kai procesai yra tinkamai apibrėžti, sukuriami prototipai, siekiant gauti vartotojų atsiliepimus. Kai prototipai bus išbandyti ir modifikuoti atsižvelgiant į grįžtamąjį ryšį, atliekamas galutinis kodavimas ir įvairūs komponentai yra integruoti, kad būtų sukurta visa informacinė sistema.

Įgyvendinimas:

Įgyvendinimo procesas apima visą veiklos spektrą, pvz., Sistemos testavimą, pagrindinių duomenų įvedimą, naudotojų mokymą, sistemos diegimą, priežiūrą ir po priežiūros. Bandymas apima tai, ar sistema atitinka paraiškos reikalavimus. Įrenginys gali būti laipsniškas arba lygiagretus, priklausomai nuo paraiškos pobūdžio.