Programutveckling: Skillnaden mellan sekventiell tillvägagångssätt och modulär tillvägagångssätt

Läs den här artikeln för att lära dig om skillnaden mellan sekventiell tillvägagångssätt och modulärt tillvägagångssätt!

Fertuck föreslår att den traditionella sekventiella processen med steg i systemanalys och design bör ge plats åt den nya processen som inkorporerar återkopplingen vid flera utvecklingsstadier.

De traditionella och moderna processerna är representerade i figur 7.5.

Den traditionella processen med systemanalys och design var sekventiell och slutförandet av ett steg var förutsättning för början av andra etappen. Således erbjöd processen liten flexibilitet för förändring mellan stadierna.

Ett förfall i ett tidigt utvecklingsstadium kunde inte åtgärdas, även när det spåras i senare skede, eftersom det innebar att många förändringar medför tidskrävande processer. Därmed erbjöd den stela informationssystem och tillåten begränsad delegering av ansvar. Detta resulterade i längre utvecklingsperioder även för mindre informationssystem.

Det moderna tillvägagångssättet övervinner dessa begränsningar och använder moderna mjukvaruverktyg för att erbjuda flexibilitet under hela utvecklingsperioden. Det tillåter delegering av ansvar i en större grupp och påskyndar utvecklingsprocessen.

Arbetet på var och en av modulerna i processen kan börja nästan samtidigt och testning av designen i varje modul kan genomföras samtidigt. Eventuella problem som identifieras i en modul kan enkelt tas om hand utan att det sker någon förändring i den andra.

Detta görs möjligt med hjälp av programvaruverktyg som försöker automatisera några av aktiviteterna i varje steg i mjukvaruutvecklingen.

Varje modul här skulle innebära tre grundläggande uppgifter:

jag. Analys av systemet

ii. Designa det nya systemet

III. Test och modifiera systemet

Dessa uppgifter är representerade för var och en av modulerna i diagrammet ovan. Låt oss se hur dessa uppgifter vidtas för varje modul eller steg i den moderna processen med systemutveckling.

Företagsmodul:

Detta avsnitt i systemanalysen och designarbetet tar en överblick över företaget. Det identifierar de enheter som en organisation samlar in information om och grupperar dem på grundval av deras relationer. Dessa grupper benämns även som delsystem.

Enheterna kan vara personer som kunder, säljare, anställda etc. saker som produkter, anläggningstillgångar, andra tillgångar, etc .; händelser som försäljning, inköp, kostnader för kostnader, intäkter och betalningar mm; jobb, uppgifter och aktiviteter etc. Dessa aktiviteter är inbördes samband och dessa relationer utgör grunden för att gruppera dem i delsystem.

Hela uppsättningen av delsystem utgör företaget. De stora informationssystemen ska fokusera på hela spektret av delsystem. En applikation för småföretag kan däremot ha en begränsad räckvidd och kan därmed endast ta hänsyn till några av delsystemen i företaget. När delsystemen har identifierats läggs prioriteringar för utvecklingen av informationssystemet.

Analysen i företagsmodulen begränsar sig till identifiering av sådana enheter och relationer i vart och ett av delsystemen. Denna fas av analysen identifierar den grundläggande strukturen i affärsprocessen, grundläggande datakrav, aktiviteter som ska stödjas och bestämmer prioriteringar för att definiera ansökans omfattning.

De exakta datakraven är inte kända i detta skede och försök görs för att få en approximation av den slutliga databasen. Således är analysen av entitetsrelationer i nuvarande skede preliminär och saknar detaljer som skulle behövas för att designa databaser.

I analysen ingår också identifiering av aktiviteter som ska stödjas av informationssystemet.

Detta skulle innebära analys för:

jag. Identifiering av aktiviteter på olika nivåer i företaget.

ii. strukturera dem med tanke på företagets organisationsstruktur.

III. Identifiering av enheter som varje aktivitet använder eller påverkar.

iv. gruppering av dessa aktiviteter i delsystem.

Databasmodul:

Företagsmodulen ger den grundläggande ramen för datakrav. Databasmodulen beskriver den detaljerade utformningen av databaser. Denna modul använder detaljerade ER-diagram som definierar dataens egenskaper. Med tanke på dessa egenskaper görs försök för att säkerställa integriteten av data.

De detaljerade ER-diagrammen översätts till struktur av relationsdatabasfiler. Dessa preliminära filstrukturer granskas sedan med hjälp av konsultationer med användarna. I denna modul används normaliseringsprocessen för att eliminera redundans och anomalier.

Gränssnittsmodul:

I denna modul definieras skärmformatet för ingång med hjälp av skärmgeneratorer. På samma sätt anges formatet för de rapporter som användarna behöver. Användarengagemanget i denna modul är kanske det djupaste av alla andra moduler.

Den här modulen definierar hur ett samtal ska äga rum mellan användaren och datorsystemet. Det är viktigt att säkerställa överensstämmelse mellan ingångsskärmsformat och relaterade inmatningsdokument. De bör också vara kompletta och bör tillåta snabb, felfri datainmatning.

Applikationsmodul:

Den här modulen identifierar de processer som måste utföras av applikationen. Dessa processer hjälper också till att definiera programmets exakta omfattning. Designers använder generellt dataflödesdiagram och systemflödesschema med progressiva detaljeringsnivåer för att definiera olika processer som är involverade i applikationen. Kortfattat definierar denna modul hur ingångar konverteras till önskade utgångar.

När processerna är ordentligt definierade, utvecklas prototyper för att få feedback från användarna. När prototyperna testats och modifierats i ljuset av återkopplingen utförs den slutliga kodningen och olika komponenter integreras för att bilda ett fullständigt informationssystem.

Genomförande:

Genomförandeprocessen omfattar hela spektret av aktiviteter som att testa systemet, ange grundläggande data, träna användarnas, installation, underhåll och eftervärderingsutvärdering av systemet. Testningen innefattar att fastställa huruvida systemet uppfyller kraven i ansökan eller inte. Installationen kan fasas eller parallellt beroende på ansökans art.