Softwareudvikling: Forskellen mellem sekventiel tilgang og modulær tilgang

Læs denne artikel for at lære om forskellen mellem sekventiel tilgang og modulær tilgang!

Fertuck antyder, at den traditionelle sekventielle proces af trin i systemanalyse og design skal give plads til den nye proces, der inkorporerer tilbagemeldingen i flere udviklingsstadier.

De traditionelle og moderne processer er repræsenteret i figur 7.5.

Den traditionelle procesanalyse og design var sekventiel, og færdiggørelsen af ​​et trin var en forudsætning for begyndelsen af ​​den anden fase. Processen gav således lidt fleksibilitet til forandring mellem stadierne.

Et forfald på et tidligt udviklingsstadium kunne ikke afhjælpes, selv når det blev sporet på et senere tidspunkt, fordi det betød at mange ændringer med tidskrævende processer skulle medføre. Det gav således stive informationssystemer og tilladt begrænset delegation af ansvar. Dette resulterede i længere udviklingsperioder selv for mindre informationssystemer.

Den moderne tilgang overvinder disse begrænsninger og bruger moderne softwareværktøjer til at tilbyde fleksibilitet i hele udviklingsperioden. Det tillader delegering af ansvar i en større gruppe og fremskynder udviklingsprocessen.

Arbejdet på hvert af modulerne i processen kan begynde næsten samtidigt, og test af designet i hvert modul kan afsluttes samtidigt. Ethvert problem, der er identificeret i et modul, kan let tages hånd om uden meget modifikation i den anden.

Dette gøres muligt ved hjælp af softwareværktøjer, der forsøger at automatisere nogle af aktiviteterne i hvert trin i softwareudviklingen.

Hvert modul her indebærer tre grundlæggende opgaver:

jeg. Analyse af systemet

ii. Design af det nye system

iii. Test og modifikation af systemet

Disse opgaver er repræsenteret for hver af modulerne i diagrammet ovenfor. Lad os se, hvordan disse opgaver udføres for hvert modul eller trin i den moderne procesudvikling.

Enterprise Module:

Dette afsnit af systemanalysen og designindsatsen tager et samlet overblik over virksomheden. Det identificerer de enheder, som en organisation indsamler information om og grupperer dem på grundlag af deres indbyrdes forhold. Disse grupper betegnes også som delsystemer.

Enhederne kan være personer som kunder, leverandører, medarbejdere mv. ting som produkter, anlæg og udstyr, andre aktiver mv .; begivenheder som salg, køb, omkostninger, indtægter og betalinger mv .; job, opgaver og aktiviteter mv. Disse aktiviteter er indbyrdes forbundne, og disse relationer danner grundlag for at gruppere dem i subsystemer.

Hele sættet af delsystemer udgør virksomheden. De store informationssystemer skal fokusere på hele spektret af delsystemer. En applikation til små virksomheder kan derimod have et begrænset omfang og kan således kun tage højde for nogle af delsystemerne i virksomheden. Når delsystemerne er identificeret, prioriteres der for udviklingen af ​​informationssystemet.

Analysen i virksomhedsmodulet begrænser sig til identifikation af sådanne enheder og relationer i hvert af delsystemerne. Denne fase af analysen identificerer den grundlæggende struktur for forretningsprocessen, grundlæggende data krav, aktiviteter, der skal understøttes og bestemmer prioriteter for at definere anvendelsesområdet.

De nøjagtige datakrav er ikke kendt på dette stadium, og der er forsøgt at få en tilnærmelse af den endelige database. Analysen af ​​entitetsrelationer er således foreløbig og mangler detaljer, der ville være nødvendige for at designe databaser.

Analysen på dette stadium omfatter også identifikation af aktiviteter, som skal understøttes af informationssystemet.

Dette indebærer analyse for:

jeg. Identifikation af aktiviteter på forskellige niveauer i virksomheden.

ii. strukturere dem i lyset af virksomhedens organisationsstruktur.

iii. Identifikation af enheder, som hver aktivitet bruger eller påvirker.

iv. gruppering af disse aktiviteter i subsystemer.

Databasemodul:

Virksomhedsmodulet udgør den grundlæggende ramme for datakrav. Databasemodulet udarbejder det detaljerede design af databaser. Dette modul bruger detaljerede ER Diagrammer, der definerer dataens egenskaber. I betragtning af disse egenskaber forsøges der at sikre integriteten af ​​data.

De detaljerede ER diagrammer er oversat til struktur af relationelle database filer. Disse foreløbige filstrukturer gennemgås derefter ved hjælp af konsultationer med brugerne. I dette modul bruges normaliseringsprocessen til at eliminere redundans og anomalier.

Grænseflademodul:

I dette modul defineres skærmformatet for input ved hjælp af skærmgeneratorerne. Tilsvarende er formaterne for de rapporter, som brugerne har brug for, angivet. Brugerinddragelsen i dette modul er måske den dybeste af alle andre moduler.

Dette modul definerer, hvordan en samtale vil finde sted mellem bruger og computersystem. Det er vigtigt at sikre sammenhæng mellem inputskærmformater og relaterede inputdokumenter. De bør også være komplette og bør tillade hurtig, fejlfri dataindtastning.

Application Module:

Dette modul identificerer de processer, der skal udføres af applikationen. Disse processer hjælper også med at definere det eksakte anvendelsesområde. Designere bruger generelt data flowdiagrammer og system flowcharts med progressive detaljeringsniveauer til at definere forskellige processer involveret i applikationen. Kort sagt definerer dette modul, hvordan input konverteres til ønskede udgange.

Når processerne er korrekt defineret, udvikles prototyper for at få feedback fra brugerne. Når prototyperne er testet og modificeret i lyset af feedbacken, udføres den endelige kodning, og forskellige komponenter integreres til dannelse af et komplet informationssystem.

Implementering:

Implementeringsprocessen omfatter hele spektret af aktiviteter som test af systemet, indtastning af basale data, træning af brugerne, installation, vedligeholdelse og eftervedligeholdelsesevaluering af systemet. Testningen indebærer at fastslå, om systemet opfylder kravene i ansøgningen. Installationen kan være faset eller parallel afhængigt af ansøgningens art.