3 information som behövs för att utforma ett informationssystem. Stadier av design av automatiserade informationssystem. Mappning av funktioner till moduler

Design informationssystem(IS) representerar en komplex flerstegs typ av verksamhet, utan den vetenskapliga organisation vars skapande och användning av modern komplex IS är otänkbar, inklusive inom utbildning, entreprenörskap, ledning och andra samhällsområden. Tillsammans med att skaffa de nödvändiga teoretiska kunskaperna för detta behöver IS-designern skaffa sig stabila praktiska färdigheter i denna typ av verksamhet.

Huvuddragen i design är att arbeta med ett objekt som ännu inte existerar. Detta är skillnaden mellan design och modellering, där ett objekt inte kan annat än existera.

IC-design täcker tre huvudområden:

Design av dataobjekt som kommer att implementeras i databasen;

Designa program, skärmformulär, rapporter som säkerställer utförandet av datafrågor;

Med hänsyn till den specifika miljön eller teknologin, nämligen: nätverkstopologi, hårdvarukonfiguration, använd arkitektur (fil-server eller klient-server), parallell bearbetning, distribuerad databehandling, etc.

Design av informationssystem börjar alltid med att definiera syftet med projektet. I allmänna termer kan målet med projektet definieras som att lösa ett antal sammanhängande uppgifter, inklusive att säkerställa vid tidpunkten för systemlansering och under hela driftperioden:

Systemets nödvändiga funktionalitet och nivån på dess anpassningsförmåga till förändrade driftsförhållanden;

Nödvändig bandbredd system;

Krävd systemsvarstid på en förfrågan;

Felfri drift av systemet;

Nödvändig säkerhetsnivå;

Enkel drift och systemstöd.

Designteknik

AIS designteknik är en uppsättning metoder och medel för AIS-design, såväl som metoder och medel för att organisera design (hantera processen för att skapa och modernisera ett AIS-projekt). Designtekniken är baserad på den teknologiska processen (TP), som bestämmer åtgärderna, deras sekvens, sammansättningen av utförare, de medel och resurser som krävs för att utföra dessa åtgärder.

TP av AIS-design är en uppsättning sekventiell-parallella, anslutna och underordnade kedjor av åtgärder, som var och en kan ha sitt eget ämne. De åtgärder som utförs vid design av en AIS kan definieras som odelbara tekniska operationer eller som delprocesser till tekniska operationer.

Alla åtgärder kan faktiskt utformas, som bildar eller modifierar designresultat, och utvärderande, som utvecklas enligt fastställda kriterier för bedömning av designresultat.

Således bestäms designtekniken av en reglerad sekvens av tekniska operationer som utförs i processen att skapa ett projekt baserat på en eller annan metod.

Ämnet för den valda designtekniken bör vara en återspegling av sammankopplade designprocesser i alla skeden livscykel AIS.

Huvudkraven för den valda designtekniken är följande:

Projektet som skapas med denna teknik måste uppfylla kundens krav;

Tekniken bör så mycket som möjligt återspegla alla stadier av projektets livscykel;

Tekniken måste säkerställa minimala arbets- och kostnadskostnader för design och projektstöd;

Tekniken bör bidra till att öka produktiviteten hos designers;

Tekniken måste säkerställa tillförlitligheten i utformningen och driften av projektet;

Tekniken ska underlätta underhållet av projektdokumentationen.

AIS designteknik implementerar en specifik designmetodik. I sin tur förutsätter designmetoden närvaron av ett visst koncept, designprinciper och implementeras av en uppsättning metoder och verktyg.

AIS designmetoder kan klassificeras efter graden av användning av automationsverktyg, standarddesignlösningar och anpassningsförmåga till förväntade förändringar.

Beroende på graden av automatisering finns det:

Manuell design;

Datorstödd design;

Baserat på graden av användning av standarddesignlösningar särskiljs de:

Original design;

Standarddesign;

Följande metoder skiljer sig åt i graden av anpassningsförmåga hos designlösningar:

Rekonstruktion - anpassning av designlösningar utförs genom att bearbeta relevanta komponenter;

Parametrering – designlösningar konfigureras i enlighet med specificerade och föränderliga parametrar;

Modellomstrukturering – modellen för ämnesområdet ändras, vilket leder till automatisk reformering av designlösningar.

Beroende på automationsobjektets komplexitet och uppsättningen av uppgifter som måste lösas när du skapar en specifik AIS, kan stadierna och faserna av arbetet ha olika arbetsintensitet. Det är möjligt att kombinera på varandra följande etapper och utesluta några av dem i alla skeden av projektet. Det är också tillåtet att påbörja arbetet med nästa steg innan det föregående är färdigt.

De viktigaste stegen för att skapa ett automatiserat informationssystem:

Utformning av krav för AIS;

Utveckling av AIS-konceptet;

Utveckling mandat;

Utveckling av en projektskiss;

Utveckling av den tekniska delen av projektet;

Utveckling arbetsdokumentation på AIS;

Driftsättning;

AIS-stöd.

Designmetodik

Grunden för teknik för design av informationssystem är metodik. Metodiken implementeras genom specifika teknologier och stödjande standarder, metoder och verktyg.

IS designmetoder kan klassificeras efter graden av användning av automationsverktyg, standarddesignlösningar och anpassningsförmåga till förväntade förändringar. Sålunda, beroende på graden av automatisering, är designmetoder indelade i:

1. Manual, där designen av IS-komponenter utförs utan användning av speciella mjukvaruverktyg, och programmering sker på algoritmiska språk;

2. Datorbaserat, där designlösningar genereras eller konfigureras (setup) baserat på användning av speciella mjukvaruverktyg.

Baserat på graden av användning av standarddesignlösningar särskiljs följande designmetoder:

1. Original (individuellt), när designlösningar utvecklas ”från grunden” i enlighet med kraven för AIS. Det kännetecknas av det faktum att alla typer av designarbete är fokuserade på att skapa individuella projekt för varje objekt, som återspeglar alla dess egenskaper i maximal utsträckning;

2. Standard, vilket innebär att konfigurera en IS från färdiga standarddesignlösningar (mjukvarumoduler). Utförs med utgångspunkt i erfarenheter från utveckling av enskilda projekt. Typiska projekt, som en generalisering av erfarenhet för vissa grupper av organisatoriska och ekonomiska system eller typer av arbete, är i varje specifikt fall förknippade med många specifika egenskaper och skiljer sig åt i graden av täckning av ledningsfunktioner, utfört arbete och utvecklad projektdokumentation.

Baserat på graden av anpassningsförmåga hos designlösningar särskiljs följande metoder:

1. Rekonstruktion, när anpassning av designlösningar utförs genom bearbetning av relevanta komponenter (omprogrammering av mjukvarumoduler);

2. Parametrering, när designlösningar konfigureras (genereras) i enlighet med de föränderliga parametrarna;

3. Modellomstrukturering, när modellen för problemområdet förändras, på basis av vilken designlösningar automatiskt återskapas.

Kombinationen av olika egenskaper hos klassificeringen av metoder bestämmer arten av de IC-designtekniker som används, bland vilka två huvudklasser särskiljs: kanonisk och industriell teknik. Industriell designteknik är i sin tur uppdelad i två underklasser: automatiserad (med CASE-teknik) och standarddesign (parameterorienterad eller modellorienterad). Användningen av industriell teknik utesluter inte användningen av kanoniska tekniker i vissa fall.

Design är en praktisk aktivitet, vars syfte är att hitta nya lösningar, presenterade i form av en uppsättning dokumentation. Sökprocessen är en sekvens av ömsesidigt beroende åtgärder och procedurer, som i sin tur involverar användning av vissa metoder. Komplexiteten i designprocessen (som alla andra kreativa aktiviteter), den icke-standardiserade karaktären hos design (livs) situationer kräver kunskap om olika metoder och förmågan att bemästra dem.

Designteknik definieras som en kombination av tre komponenter:

En steg-för-steg-procedur som bestämmer sekvensen av tekniska designoperationer;

Kriterier och regler som används för att utvärdera resultaten av tekniska operationer;

Notationer (grafiska och textmässiga medel) som används för att beskriva systemet som designas.

Jämförande egenskaper hos designverktyg

Huvudsyftet med att välja en företagsstandard för organisationsdesign är att specificera ett gemensamt och obligatoriskt kommunikationsspråk för ledning, utvecklare av organisations- och tekniska processer och utförarna av dessa processer. Särskilda tillämpningar av sådana standarder är syntesen av krav på skapade system, föreskrifter om organisatoriska enheter, serviceinstruktioner etc.

Det finns ett 30-tal tekniker för att designa organisatoriska och tekniska system och flera hundra verktyg utformade för att automatisera denna process. Därför, med hänsyn till tidsfaktorn, begränsades den jämförande analysen till de fyra mest populära produkterna på den ryska marknaden: Bpwin/Erwin (Platinum Technology), Rational Rose (Rational Software Corporation), ARIS (Scheer AG) och Oracle Designer ( Oracle Developer Suite). Referensdata om CASE-teknologier och designverktyg ges nedan i texten och i tabell nr 1.

bord 1

Designverktyg och deras jämförande egenskaper

*) applikationsutvecklare kan börja arbeta med databasen först efter att dess design har slutförts.

CASE-teknologin är en IS-designmetodik, såväl som en uppsättning verktyg som låter dig visuellt modellera ett ämnesområde, analysera denna modell i alla stadier av IS-utveckling och underhåll och utveckla applikationer i enlighet med användarnas informationsbehov. De flesta befintliga CASE-verktyg är baserade på strukturella (mestadels) eller objektorienterade analys- och designmetoder, och använder specifikationer i form av diagram eller texter för att beskriva externa krav, relationer mellan systemmodeller, systembeteendedynamik och mjukvaruarkitektur.

Enligt en granskning av avancerad teknologi sammanställd av Systems Development Inc. 2007, baserat på resultaten från en undersökning av mer än 1 000 amerikanska företag, rankas CASE-tekniken för närvarande bland de mest stabila informationsteknikerna (hälften av alla tillfrågade användare använde den i mer än en tredjedel av sina projekt, varav 85 % var slutförts framgångsrikt). Men trots alla potentiella möjligheter hos CASE-verktyg finns det många exempel på deras misslyckade implementering, som ett resultat av vilket CASE-verktyg blir "hyllprogram". I detta avseende bör följande noteras:

1. CASE-verktyg har inte nödvändigtvis en omedelbar effekt; det kan bara tas emot efter en tid;

2. De faktiska kostnaderna för att implementera CASE-verktyg överstiger vanligtvis kostnaderna för att köpa dem;

3. CASE-verktyg ger möjligheter att erhålla betydande fördelar först efter framgångsrikt slutförande av deras implementeringsprocess.

På grund av den varierande karaktären hos CASE-verktyg skulle det vara felaktigt att göra några allmänna uttalanden om den faktiska tillfredsställelsen av en given förväntning från implementeringen. Följande faktorer kan listas som gör det svårt att avgöra den möjliga effekten av att använda CASE-verktyg:

1. Brett utbud av kvalitet och kapacitet hos CASE-verktyg;

2. Relativt kort tid att använda CASE-verktyg i olika organisationer och bristande erfarenhet av användningen av dem;

3. Stor variation i genomförandet av olika organisationer;

4. Brist på detaljerade mätvärden och data för redan avslutade och pågående projekt;

5. Brett utbud av ämnesområden för projekt;

6. Varierande grad av integration av CASE-verktyg i olika projekt.

Som ett resultat av dessa komplexiteter är den tillgängliga informationen om faktiska implementeringar extremt begränsad och inkonsekvent. Det beror på typen av verktyg, projektets egenskaper, supportnivå och användarupplevelse. Vissa analytiker tror att de verkliga fördelarna med att använda vissa typer av CASE-verktyg först kan realiseras efter ett eller två års erfarenhet. Andra tror att påverkan faktiskt kan inträffa under driftfasen av IS livscykel, när tekniska förbättringar kan leda till lägre driftskostnader.

SP-kategorin omfattar både relativt billiga system för persondatorer (PC) med mycket begränsad kapacitet och dyra system för heterogena datorplattformar och operativsystem. Den moderna mjukvarumarknaden omfattar alltså ett 30-tal olika CASE-system, varav de mest kraftfulla, på ett eller annat sätt, används av nästan alla ledande västerländska företag.

Användningen av SP kräver särskild förberedelse och utbildning från potentiella användare. Erfarenheten visar att implementeringen av SP går långsamt, men eftersom praktiska färdigheter och en allmän designkultur förvärvas ökar effektiviteten av att använda dessa verktyg kraftigt, och det största behovet av att använda SP upplevs i de inledande skedena av utvecklingen, nämligen kl. stadierna för analys och kravspecifikation. Detta förklaras av det faktum att kostnaden för fel som görs i de inledande stadierna är flera storleksordningar högre än kostnaden för fel som identifierats i senare utvecklingsstadier.

Idag den ryska marknaden programvara har följande mest utvecklade joint ventures:

ERWin/BPWin;

Rationell Rose;

Oracle Designer.

ARIS - Ett integrerat verktyg för affärsprocessmodellering som kombinerar en mängd olika systemmodellerings- och analysmetoder. För det första är det ett sätt att beskriva, analysera, optimera och dokumentera affärsprocesser än ett mjukvarudesignverktyg.

BPWin är ett verktyg för visuell modellering av affärsprocesser. ERWin är ett verktyg som används för att modellera och skapa databaser med godtycklig komplexitet baserade på entitetsrelationsdiagram.

Rational Rose är ett verktyg för att modellera objektorienterade informationssystem. Låter dig lösa nästan alla problem i designen av informationssystem: från affärsprocessanalys till kodgenerering i ett specifikt programmeringsspråk. Låter dig utveckla både högnivå- och lågnivåmodeller, och därigenom utföra antingen abstrakt eller logisk design.

Oracle Designer är ett funktionellt verktyg för att beskriva ett ämnesområde. Ingår i Oracle9i Developer Suite-uppsättningen verktyg för att designa mjukvarusystem och databaser som implementerar CASE-teknik och Oracles egen IP-utvecklingsmetodik - "CDM", vilket gör det möjligt för utvecklingsteamet att genomföra ett projekt, med start från affärsprocessanalys via modellering till kodgenerering och erhålla prototyp, och därefter slutprodukten. Det här verktyget är vettigt när man riktar in sig på hela Oracle-produktlinjen som används för att designa, utveckla och implementera ett komplext programvarusystem.

Analys av uppgifterna i tabellen visar att av de listade samriskföretagen är det bara ARIS-komplexet som till fullo uppfyller alla kriterier som accepteras som de viktigaste. Till exempel, i Rational Rose-komplexet säkerställs integriteten hos designdatabasen och en enhetlig end-to-end IC-designteknik genom att använda Corba-gränssnittet. Det bör noteras att var och en av de två produkterna i sig är en av de mest kraftfulla i sin klass.

Det mest utvecklade sättet att utveckla storskalig IS idag, enligt författaren, är alltså ARIS-komplexet.

Main

G.N. Smirnova, A.A. Sorokin, Yu.F. Telnov Design av ekonomiska informationssystem. Lärobok. M., "Finans och statistik", 2002

Vendrov A.M. Design av programvara för ekonomiska informationssystem. M., "Finans och statistik", 2000

Maklakov S.V. Skapa en IP med AllFusion Modeling Suite. M., "Dialogue-MEPhI", 2003

Grekul V.I., Denishchenko G.N., Korovkina N.L. IC design. Handledning. Internet University, M., 2005

Ytterligare

Kalyanov G.N. Teori och praktik för omorganisation av affärsprocesser. M., SINTEG, 2000

Kalyanov G.N. Strukturell systemanalys.

M., Lori, 1996

Marka D.A., McGowan K. SADT - metodik strukturanalys och design., M., Metatechnology, 1993

G. Butch D. Rambo A. Jacobson UML. Användarhandbok, 1999

M. Fowler K. Scott UML Fundamentals

T. Quatrani Rational Rose 2000 och UML. Visuell modellering. Moskva, 2001

Ytterligare

Koltunova E. Krav på informationssystem och livscykelmodell. Carabi Solutions, www.carabisolutions.sp.ru

Steg för automatiserad systemutveckling. GOST 34.601-90 Uppsättning av standarder för automatiserade system. IPK Standards Publishing House, M., 1997

ISO/IEC 12207:1995

Thiele D. Livscykelhantering med livscykelprocessstandarder. Abstrakt. http://www.fostas.ru/library/show_article.php? id=22

Design och utveckling av företagsinformationssystem. http://zeus.sai.msu.ru:7000/cfin/prcorpsys/index.sht ml.

Grundläggande koncept

IS designmetoder

1. Mål och innehåll för IS-designmetodiken

2. IS livscykel

IC Design metodik

I verkliga förhållanden är design ett sökande efter en metod som uppfyller kraven på systemfunktionaliteten med hjälp av tillgänglig teknik, med hänsyn till givna begränsningar.

Systemansats: Alla system är en samling sammankopplade element som fungerar tillsammans för att uppnå ett gemensamt mål.

Designmetod: en organiserad uppsättning processer för att skapa en serie modeller som beskriver olika aspekter av systemet som skapas med hjälp av en väldefinierad notation.

Designteknik: en uppsättning tekniska operationer i deras sekvens och sammankoppling, vilket leder till utvecklingen av en systemdesign.

IS delsystem

Informationsstödset

interaktion mellan arbetstagare med tekniska medel och sinsemellan i processen att utveckla och driva ett informationssystem.

Stadier av utveckling av IC-designteknologier

1. Metoden "bottom-up" är inte skapandet av replikerbara produkter, utan tjänsten för anställda vid en viss institution. Enskilda jobb som är viktiga ur ledningens synvinkel automatiseras framgångsrikt. Den övergripande bilden av det "automatiserade företaget" är inte tydligt, särskilt i framtiden.

("Patchwork Automation")

2. "Top-down" -metod - från hela spektrumet av problem identifierade utvecklarna de mest märkbara: automatisering av redovisningsanalytiska poster och tekniska processer. Systemen designades "från toppen", d.v.s. under antagandet att ett program bör tillfredsställa behoven hos alla användare: utvecklarnas kapacitet i strukturen av informationsuppsättningar i databasen, användningen av alternativ för skärmformulär, beräkningsalgoritmer är kraftigt begränsade och därför berövas förmågan att underhålla djup, ofta specifik analytisk och produktionsmässig och teknisk redovisning.

Stadier av utveckling av designteknik

(fortsättning)

3. Flerkomponentsmetod - anpassning av mjukvaruundersystemet till de driftförhållanden som accepteras i organisationen. Att uppgradera en av komponenterna påverkar inte den centrala delen (kärnan) och dess andra komponenter, vilket avsevärt ökar tillförlitligheten och livslängden automatiserat system och säkerställer den mest kompletta implementeringen av de nödvändiga funktionerna.

Stadier av design av automatiserade informationssystem. Två verksamhetsområden är direkt relaterade till utformningen av AIS: 1) den faktiska utformningen av AIS för specifika företag (industrier) på grundval av färdiga mjukvaru- och hårdvarukomponenter som använder speciella utvecklingsverktyg; 2) design av de nämnda AIS-komponenterna och verktygen, orienterad mot upprepad användning i utvecklingen av många specifika informationssystem.

Kärnan i den första riktningen kan uttryckas med orden "systemintegration". AIS-utvecklaren ska vara specialist inom området systemteknik och ha goda kunskaper om internationella standarder, tillståndet och trenderna i utvecklingen av informationsteknologi och mjukvaruprodukter, behärska applikationsutvecklingsverktyg (CASE-verktyg) och vara redo att uppfatta och analysera automatiserade applikationsprocesser i samarbete med specialister inom det relevanta ämnesområdet. Det finns ett antal företag som är specialiserade på utveckling av AIS-projekt (till exempel Price Waterhouse, Jet Info, Consistent Software, etc.).

Den andra riktningen är mer relaterad till utvecklingen av matematisk och mjukvara för implementering av AIS-funktioner - modeller, metoder, algoritmer, program baserade på kunskap om systemteknik, metoder för analys och syntes av designlösningar, programmeringsteknik, operativsystem etc. I varje klass av AIS (automatiserat styrsystem, CAD, GIS, etc.) finns det företag som är specialiserade på utveckling av mjukvara (och ibland hård- och mjukvara) system. Var och en av dem annonserar sin teknik för att skapa AIS och följer strategin för antingen en totalleverantör eller öppenhet och expansion av systemet med applikationer och tillägg från tredje part.

Både AIS själva och AIS-komponenterna är komplexa system, och när man designar dem är det tillrådligt att använda en top-down-stil av blockhierarkisk design, som inkluderar ett antal nivåer och stadier.

Den högsta nivån av AIS-design kallas ofta konceptuell design. Konceptuell design utförs i processen av pre-design forskning, formulering av ett tekniskt förslag och utveckling av en preliminär design.

Pre-design forskning utförs genom att analysera (kartläggning) verksamheten i företaget (företag, institution, kontor) där det automatiserade informationssystemet skapas eller moderniseras. Innan undersökningen utformas målen för undersökningen och under dess genomförande - identifiera möjligheter och resurser för att förbättra effektiviteten i företaget baserat på automatisering av hanterings-, design- och dokumentflödesprocesser. Innehållet i undersökningen är att identifiera företagets struktur, utförda funktioner, informationsflöden, erfarenhet och tillgängliga automationsverktyg. Undersökningen genomförs av systemanalytiker (systemintegratörer) tillsammans med representanter för kundorganisationen.

Baserat på analysen av undersökningsresultaten utvecklas det initiala konceptet för AIS. Detta koncept inkluderar förslag för att ändra företagets struktur och samspelet mellan divisioner, för val av grundläggande mjukvara och hårdvara, och förslagen måste ta hänsyn till prognosen för företagets utveckling. När det gäller hårdvara och särskilt mjukvara (mjukvara) är ett sådant val oftast valet av det företag som tillhandahåller de nödvändiga verktygen (eller åtminstone grundläggande mjukvara), eftersom korrekt gemensam drift av program från olika företag uppnås med stor svårighet .

Analysresultat - Tekniskt förslag och en affärsplan för att skapa en AIS presenteras för kunden för slutgiltigt godkännande.

Både på undersökningsstadiet och i efterföljande skeden är det tillrådligt att hålla sig till en viss disciplin för att registrera och presentera de erhållna resultaten, baserat på en eller annan metod för att formalisera specifikationer. Formalisering behövs för att utförare och kunder tydligt ska förstå de krav, begränsningar och fattade beslut.

I konceptuell design används ett antal specifikationer, bland vilka den centrala platsen upptas av modeller för transformation, lagring och överföring av information. De modeller som erhölls under undersökningen av företaget är modeller för dess funktion. I processen att utveckla AIS genomgår modeller som regel betydande förändringar och i sin slutliga form betraktas de som modeller av den designade AIS.

Det finns funktionella, informativa, beteendemässiga och strukturella modeller. Den funktionella modellen för ett system beskriver den uppsättning funktioner som utförs av systemet. Informationsmodellen speglar datastrukturer - deras sammansättning och samband. Beteendemodellen beskriver informationsprocesser (funktionsdynamik), den inkluderar sådana kategorier som systemets tillstånd, en händelse, en övergång från ett tillstånd till ett annat, övergångsförhållanden och en sekvens av händelser. Strukturell modell kännetecknar systemets morfologi (dess konstruktion) - sammansättningen av delsystem, deras relationer.

Innehållet i de efterföljande stadierna av top-down design är fastställandet av listor över köpt utrustning och färdiga mjukvaruprodukter, konstruktionen av en systemmiljö, detaljerad informationsdesign av databaser och deras initiala innehåll, utvecklingen av vår egen originalprogramvara, som , i sin tur, är uppdelad i ett antal stadier av top-down design.

En speciell plats bland designuppgifter upptas av utvecklingen av ett företags datornätverksprojekt, sedan teknisk support AIS har en nätverksstruktur.

Om AIS:en är placerad i punkter på avstånd från varandra, i synnerhet i olika städer, då är frågan om att hyra kommunikationskanaler för företagsnätverk, eftersom det alternativa alternativet att använda en dedikerad kanal i de flesta fall visar sig vara oacceptabelt på grund av det höga priset. Naturligtvis, i det här fallet, först och främst möjligheten att använda Internettjänster. Det är via Internet som företag som använder CALS-teknik (Computer Acquisition Life-Cycle System) kan interagera. De problem som uppstår i detta fall är relaterade till att säkerställa informationssäkerhet och tillförlitlighet för meddelandeleverans.

En av huvudtrenderna i den moderna datavetenskapsindustrin är skapandet av öppna system. Öppenhetsegenskapen innebär för det första att mjukvara kan överföras (mobilitet) till olika hårdvaruplattformar, och för det andra systemets anpassningsförmåga till dess modifieringar (modifierbarhet eller öppenheten i sig) och integration med andra system för att utöka det funktionalitet och/eller ge systemet nya egenskaper (integrerbarhet).

Steg I - förprojekt (inspektion, utarbetande av en rapport, genomförbarhetsstudie och tekniska specifikationer);

Steg II - design (utarbeta tekniska och detaljerade konstruktioner);

Steg III - genomförande (förberedelse för genomförande, genomförande pilottester och driftsättning i programdrift);

Steg IV - analys av funktion (identifiera problem, göra ändringar i designlösningar och befintliga AIS och AIT).

Figur 1.

På förprojekteringsstadiet genomförs en studie och analys av designobjektet. I synnerhet analyseras informationsbasen, alla ingångsdokument, deras volym, frekvens, algoritmer, utdatadokument och alla informationskopplingar för uppgifter. Denna data bearbetas och en informationsmodell av objekt byggs upp i form av tabeller och grafer.

Till metoder för att studera och analysera staten ekonomiskt objekt och dess kontrollsystem inkluderar:

muntlig och skriftlig enkät;

skriftlig enkät;

observation, mätning, utvärdering;

gruppdiskussion;

uppgiftsanalys;

analys av produktions-, lednings- och informationsprocesser.

Som ett resultat av undersökningen tas rekommendationer fram för att ändra organisationsstrukturen, nya övervägs Arbetsbeskrivningar, genomförbarheten av vissa dokument, sammansättningen av databaser bestäms, förslag för att ändra bearbetningsteknik bestäms, konfigurationen av datornätverket, antalet maskiner, sammansättningen av ekonomiska uppgifter, ordningen för deras datorisering bestäms, förslagen är utvecklad för genomförande av ekonomiska uppgifter med hjälp av programvarupaket.

På designstadiet utarbetas tekniska och arbetsprojekt för varje nivå av automatiserad arbetsplats. Arbetsutkastet speglar allmänna bestämmelser, sammansättning av tekniska medel, arkitektur, organisationsstruktur i nya förhållanden sätts uppgifter, informationsstöd utformas, informationsutbyte med andra arbetsstationer beräknas, ekonomisk effektivitet beräknas, instruktioner till utförare beräknas.

Design av tekniska processer inkluderar design av lösenord, program, scenarier för användardialog med PVM, inklusive design av hierarkiskt organiserade menyer och "fönster". Menyn innehåller en lista med block, moduler och program. Varje modul utför en specifik funktion Menystrukturen och scenen för dialogen mellan en person och en maskin utvecklas.Om färdiga paket med applikationsprogram används måste de innehålla en användarmanual för drift och en uppsättning maskinprogram på disketter.

Redogörelsen av problemet ger en omfattande förståelse av dess väsen, logiken i att transformera den initiala informationen för att få ett resultat.

I processen att ställa in uppgifter avslöjas följande:

dess organisatoriska och ekonomiska väsen (namn, syfte med beslutet, frekvens och tidpunkt för beslutet, källor och metoder för att ta emot data, konsumenter av den resulterande informationen och metoder för att skicka den, informationskopplingar med andra uppgifter);

beskrivning av källvariabeln och villkorligt konstant information (lista, presentationsformulär, volymetriska indikatorer, beskrivning av strukturella informationsenheter, metoder för att övervaka källdata);

beskrivning av den resulterande informationen (lista, presentationsformer, användare, strukturella informationsenheter, kontrollmetoder);

beskrivning av algoritmen för att lösa problemet (sekvens för att utföra aritmetiska och logiska operationer).

För närvarande är nästan all AIS decentraliserad, så det är viktigt för användaren att delta i pre-designstadiet, när han ställer in och implementerar uppgifter och analyserar hur AIT fungerar.

Introduktion

Design av informationssystem börjar alltid med att definiera syftet med projektet. Huvuduppgiften för någon framgångsrikt projektär att säkerställa att vid den tidpunkt då systemet startas och under hela dess drift:

• den erforderliga funktionaliteten hos systemet och graden av anpassning till de förändrade driftsförhållandena;
• erforderlig systemkapacitet;
• erforderlig systemsvarstid på en begäran;
• problemfri drift av systemet i det önskade läget, med andra ord systemets beredskap och tillgänglighet för att behandla användarförfrågningar;
• enkel drift och stöd för systemet;
• nödvändig säkerhet.

Prestanda är den viktigaste faktorn som avgör effektiviteten hos ett system. Bra design är grunden för ett högpresterande system.

Informationssystemdesign täcker tre huvudområden:

• designa dataobjekt som kommer att implementeras i databasen;
• designa program, skärmformulär, rapporter som säkerställer utförandet av dataförfrågningar;
• med hänsyn till en specifik miljö eller teknologi, nämligen: nätverkstopologi, hårdvarukonfiguration, använd arkitektur (fil-server eller klient-server), parallell bearbetning, distribuerad databehandling, etc.

I verkliga förhållanden är design ett sökande efter en metod som uppfyller kraven på systemfunktionaliteten med hjälp av tillgänglig teknik, med hänsyn till givna begränsningar.

Varje projekt är föremål för ett antal absoluta krav, till exempel maximal projektutvecklingstid, maximal ekonomisk investering i projektet etc. En av svårigheterna med design är att det inte är en så strukturerad uppgift som att analysera projektkrav eller implementera en viss designlösning.

Man tror att ett komplext system inte kan beskrivas i princip. Detta gäller i synnerhet företagsledningssystem. Ett av huvudargumenten är en förändring av systemets driftsvillkor, till exempel en direktivändring av vissa informationsflöden av ny ledning. Ett annat argument är volymen av tekniska specifikationer, som för ett stort projekt kan vara hundratals sidor, medan det tekniska projektet kan innehålla fel. Frågan uppstår: det kanske är bättre att inte genomföra undersökningar alls och inte göra några tekniskt projekt, och skriv systemet "med ren tavla"i hopp om att det kommer att ske någon mirakulös sammanträffande av kundens önskemål med vad programmerarna skrev, och även att allt detta kommer att fungera stabilt?

Om man tittar på det, är utvecklingen av systemet verkligen så oförutsägbar och är det verkligen omöjligt att få information om det? Förmodligen kan en uppfattning om systemet som helhet och sätten för dess utveckling föreslagna (av ledningen) fås genom seminarier. Efter detta, dela upp det komplexa systemet i enklare komponenter, förenkla kopplingarna mellan komponenterna, sörja för komponenternas oberoende och beskriv gränssnitten mellan dem (så att en förändring i en komponent inte automatiskt medför en betydande förändring av en annan komponent) , samt möjligheten att utöka systemet och "stubbar" för orealiserbara i en eller annan version av funktionssystemet. Utifrån sådana elementära överväganden ter sig beskrivningen av vad som ska implementeras i informationssystemet inte längre så orealistisk. Du kan följa klassiska tillvägagångssätt för utveckling av informationssystem, varav en - "vattenfall" -schemat (Fig. 1) - beskrivs nedan. Några andra tillvägagångssätt för utveckling av informationssystem kommer också att diskuteras kort, där användningen av de element som beskrivs i ”vattenfallsdiagrammet” också är acceptabel. Vilket av tillvägagångssätten som beskrivs nedan att följa (och om det är meningsfullt att komma med ett eget tillvägagångssätt) är till viss del en fråga om smak och omständigheter.

Ris. 1. Vattenfallsdiagram

Programvarans livscykel är mönstret för dess skapelse och användning. Modellen återspeglar dess olika tillstånd, från det ögonblick då behovet av denna programvara uppstår och slutar i det ögonblick den är helt ur bruk för alla användare. Känd följande modeller livscykel:

• Cascade modell. Övergången till nästa steg innebär ett fullständigt slutförande av arbetet i föregående steg.
• Stegvis modell med mellanstyrning. Mjukvaruutveckling sker i iterationer med cykler respons mellan etapperna. Mellanstegsjusteringar gör det möjligt att minska komplexiteten i utvecklingsprocessen jämfört med vattenfallsmodellen; Livslängden för varje steg sträcker sig över hela utvecklingsperioden.
• Spiral modell. Särskild uppmärksamhet ägnas åt de inledande stadierna av utvecklingen - strategiutveckling, analys och design, där genomförbarheten av vissa tekniska lösningar testas och motiveras genom att skapa prototyper (layout). Varje varv av spiralen innebär skapandet av en viss version av produkten eller någon av dess komponenter, medan egenskaperna och målen för projektet förtydligas, dess kvalitet bestäms och arbetet med nästa varv av spiralen planeras.

Nedan kommer vi att titta på några projektutvecklingsprogram.

"Vattenfall" - projektutvecklingsdiagram

Mycket ofta beskrivs design som ett separat steg i projektutvecklingen mellan analys och utveckling. Men i verkligheten finns det ingen tydlig uppdelning av projektutvecklingsstadier - design har som regel inte en tydligt definierad början och slut och fortsätter ofta i test- och implementeringsstadierna. På tal om teststadiet bör det också noteras att både analyssteget och designstadiet innehåller delar av testarnas arbete, till exempel för att få en experimentell motivering för valet av en viss lösning, samt att utvärdera kvalitetskriterier för det resulterande systemet. På driftstadiet är det lämpligt att tala om systemunderhåll.

Nedan kommer vi att titta på vart och ett av stegen och fokusera mer i detalj på designstadiet.

Strategi

Att definiera en strategi innebär att undersöka systemet. Huvudsyftet med undersökningen är att bedöma projektets faktiska omfattning, dess mål och mål, samt att få fram definitioner på hög nivå av enheter och funktioner.

I detta skede lockas högt kvalificerade affärsanalytiker som har konstant tillgång till företagets ledning; Detta skede involverar nära interaktion med de huvudsakliga användarna av systemet och affärsexperter. Huvuduppgiften för interaktion är att få så fullständig information som möjligt om systemet (en fullständig och entydig förståelse av kundens krav) och överföra denna information i en formaliserad form till systemanalytiker för det efterföljande analysskedet. Typiskt kan information om systemet erhållas genom samtal eller seminarier med ledning, experter och användare. På så sätt bestäms essensen av denna verksamhet, utsikter för dess utveckling och krav på systemet.

När den huvudsakliga systemundersökningsfasen är klar, formulerar tekniker rimliga tekniska tillvägagångssätt och uppskattar kostnader för hårdvara, köpt mjukvara och ny mjukvaruutveckling (vilket är vad projektet faktiskt innebär).

Resultatet av strategidefinitionsstadiet är ett dokument som tydligt anger vad kunden kommer att få om han går med på att finansiera projektet; när han kommer att få den färdiga produkten (arbetsschema); hur mycket kommer det att kosta (för stora projekt en finansieringsplan bör upprättas i olika skeden av arbetet). Dokumentet ska inte bara spegla kostnader utan också fördelar, till exempel projektets återbetalningstid, den förväntade ekonomiska effekten (om den kan uppskattas).

Dokumentet ska beskriva:

• begränsningar, risker, kritiska faktorer som påverkar projektets framgång, till exempel är systemets svarstid på en förfrågan en given begränsning och inte en önskvärd faktor;
• en uppsättning villkor under vilka det framtida systemet förväntas drivas: systemarkitektur, hård- och mjukvaruresurser som tillhandahålls till systemet, yttre förhållanden dess funktion, sammansättningen av människor och verk som säkerställer att systemet fungerar oavbrutet;
• tidsfrister för slutförande av enskilda etapper, form för leverans av arbete, resurser involverade i processen för projektutveckling, åtgärder för att skydda information;
• beskrivning av de funktioner som utförs av systemet;
• framtida krav på systemet om det utvecklar till exempel användarens förmåga att arbeta med systemet via Internet etc.;
• enheter som är nödvändiga för att utföra systemfunktioner;
• gränssnitt och fördelning av funktioner mellan en person och systemet;
• krav på programvara och informationskomponenter i programvaran, krav på ett DBMS (om projektet är tänkt att implementeras för flera DBMS, då kraven för var och en av dem, eller Allmänna krav till ett abstrakt DBMS och en lista över DBMS som rekommenderas för detta projekt som uppfyller de specificerade villkoren);
• som inte kommer att genomföras inom projektet.

Det arbete som genomförts i detta skede gör att vi kan svara på frågan om detta projekt är värt att fortsätta och vilka kundkrav som kan tillgodoses under vissa förutsättningar. Det kan visa sig att projektet inte är meningsfullt att fortsätta, till exempel på grund av att vissa krav inte kan uppfyllas av några objektiva skäl. Om ett beslut fattas om att fortsätta projektet, så finns det redan en idé om projektets omfattning och kostnadsuppskattningar för nästa steg av analysen.

Det bör noteras att vid val av strategi, och i analysstadiet och under design, oavsett vilken metod som används för att utveckla projektet, bör de planerade funktionerna i systemet alltid klassificeras efter grad av betydelse. Ett möjligt format för att presentera en sådan klassificering, MoSCoW, föreslås i Clegg, Dai och Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Denna förkortning står för: Måste ha - nödvändiga funktioner; Bör ha - önskvärda funktioner; Kan ha - möjliga funktioner; Kommer inte ha - saknade funktioner.

Implementeringen av funktioner i den andra och tredje kategorin begränsas av tid och ekonomiska ramar: vi utvecklar det som behövs, såväl som det maximala antalet funktioner i den andra och tredje kategorin i prioritetsordning.

Analys

Analyssteget innefattar en detaljerad studie av affärsprocesser (funktioner definierade vid strategivalsstadiet) och den information som är nödvändig för deras implementering (enheter, deras attribut och kopplingar (relationer)). I detta skede skapas en informationsmodell och i nästa designskede skapas en datamodell.

All information om systemet som samlas in i strategidefinitionsstadiet formaliseras och förtydligas i analysstadiet. Särskild uppmärksamhet bör ägnas åt att den överförda informationen är fullständig, att analysera informationen för att säkerställa att det inte finns några motsägelser, samt att söka efter oanvänd eller dubblerad information. Kunden ställer i regel inte omedelbart krav på systemet som helhet utan ställer krav på dess enskilda komponenter. Var uppmärksam på konsistensen av dessa komponenter.

Analytiker samlar in och registrerar information i två sammanhängande former:

• funktioner - information om händelser och processer som inträffar i verksamheten;
• enheter - information om saker som är viktiga för organisationen och som något är känt om.

Två klassiska analysresultat är:

• hierarki av funktioner, som bryter ner bearbetningsprocessen i dess beståndsdelar (vad som görs och vad den består av);
• Entry Relationship Model (ER-modell), som beskriver entiteter, deras attribut och kopplingar (relationer) dem emellan.

Dessa resultat är nödvändiga, men inte tillräckliga. Tillräckliga resultat inkluderar dataflödesdiagram och entitetslivscykeldiagram. Ganska ofta uppstår analysfel när man försöker visa en entitets livscykel i ett ER-diagram.

Nedan tittar vi på de tre mest använda metoderna för strukturanalys:

• Entity-Relationship Diagrams (ERD), som tjänar till att formalisera information om enheter och deras relationer;
• Dataflödesdiagram (DFD), som tjänar till att formalisera representationen av systemfunktioner;
• State Transition Diagrams (STD), som återspeglar systemets tidsberoende beteende; Entitetslivscykeldiagram tillhör denna klass av diagram.

ER-diagram

ER-diagram (Figur 2) används för datautveckling och är ett standardsätt för att definiera data och relationerna mellan dem. Således utförs detaljeringen av datalager. Ett ER-diagram innehåller information om systemets entiteter och hur de interagerar, inklusive identifiering av objekt som är viktiga för ämnesområdet (entiteter), egenskaperna hos dessa objekt (attribut) och deras relationer med andra objekt (länkar). I många fall är informationsmodellen mycket komplex och innehåller många objekt.

Ris. 2. Exempel på ett ER-diagram

En enhet avbildas som en rektangel med namnet på enheten överst (till exempel TITLAR). Rektangeln kan lista attributen för en entitet; ER-diagramattribut skrivna i fetstil är nyckeln (till exempel är titelidentitet ett nyckelattribut för TITLES-enheten, andra attribut är inte nyckel).

En relation representeras av en linje mellan två enheter (blå linjer i figuren).

Den enkla raden till höger (Figur 3) betyder "en", "fågelfoten" till vänster betyder "många", och förhållandet läses längs linjen, som "en till många". Ett vertikalt streck betyder "obligatoriskt", en cirkel betyder "valfritt", till exempel för varje publikation i TITLE måste förlaget i PUBLISHERS anges, och ett förlag i PUBLISHERS kan publicera flera titlar på publikationer i TITLES. Det bör noteras att anslutningar alltid kommenteras (inskriptionen på raden som visar sambandet).

Ris. 3. ER-diagramelement

Låt oss också ge ett exempel (fig. 4) på ​​en bild av det reflexiva förhållandet ”anställd”, där en anställd kan hantera flera underordnade och så vidare ner i positionshierarkin.

Det bör noteras att ett sådant förhållande alltid är valfritt, annars kommer det att vara en oändlig hierarki.

Ris. 4. ER-diagram över reflexiv attityd

Entitetsattribut kan vara viktiga - de är markerade med fet stil; obligatoriska - de föregås av ett "*"-tecken, det vill säga deras värde är alltid känt, valfritt (valfritt) - de föregås av ett O, det vill säga värdena för detta attribut kan vara frånvarande eller osäkra vid vissa ögonblick.

Arcs

Om en enhet har en uppsättning ömsesidigt uteslutande relationer med andra enheter, sägs sådana relationer vara i en båge. Till exempel kan ett bankkonto skapas antingen för juridisk enhet, eller för enskild. Ett fragment av ett ER-diagram för denna typ av relation visas i fig. 5.

Ris. 5. Båge

I det här fallet har ACCOUNT-enhetens OWNER-attribut en speciell betydelse för denna enhet - enheten är indelad i typer efter kategori: "för en individ" och "för en juridisk person." De resulterande enheterna kallas undertyper, och den ursprungliga enheten blir en supertyp. För att förstå om en supertyp behövs eller inte, måste du fastställa hur många identiska egenskaper olika undertyper har. Det bör noteras att missbruk av subtyper och supertyper är ett ganska vanligt misstag. De är avbildade som visas i fig. 6.

Ris. 6. Undertyper (höger) och supertyp (vänster)

Normalisering

För att förhindra anomalier under databehandlingen används normalisering. Principerna för normalisering för informationsmodellobjekt är exakt desamma som för datamodeller.

Acceptabla typer av anslutningar. En närmare titt på en en-till-en-relation (Figur 7) avslöjar nästan alltid att A och B faktiskt är olika delmängder av samma sak eller olika punkter syn på det, helt enkelt ha olika namn och olika beskrivna samband och attribut.

Ris. 7. En-till-en-anslutningar

Många-till-en-relationer visas i fig. 8.

Ris. 8. Många-till-en-relationer

I är en ganska stark konstruktion som antyder att en förekomst av entitet B inte kan skapas utan att samtidigt skapa minst en associerad förekomst av entitet A.

II är den vanligaste kommunikationsformen. Den antar att varje förekomst av entitet A endast kan existera i sammanhanget av en (och endast en) förekomst av entitet B. I sin tur kan förekomster av B existera antingen med eller utan förekomster av A.

III - sällan använd. Både A och B kan existera utan någon koppling mellan dem.

Många-till-många-relationer visas i fig. 9.

Ris. 9. Många-till-många-relationer

I - denna konstruktion inträffar ofta i början av analysstadiet och innebär ett förhållande - antingen inte helt förstådd och kräver ytterligare upplösning, eller återspeglar ett enkelt kollektivt förhållande - en dubbelriktad lista.

II - sällan använd. Sådana anslutningar är alltid föremål för ytterligare detaljer.

Låt oss nu betrakta rekursiva samband (fig. 10).

Ris. 10. Rekursiva kopplingar

Jag - sällsynt, men förekommer. Återspeglar anslutningar av alternativ typ.

II - används ganska ofta för att beskriva hierarkier med valfritt antal nivåer.

III - förekommer i de tidiga stadierna. Reflekterar ofta strukturen hos "materialstyckan" (ömsesidigt kapsling av komponenter). Exempel: Varje KOMPONENT kan bestå av en eller flera (andra) KOMPONENTER, och varje KOMPONENT kan användas i en eller flera (andra) KOMPONENTER.

Ogiltiga anslutningstyper. Ogiltiga typer av relationer inkluderar följande: obligatoriska många-till-många-relationer (Fig. 11) och ett antal rekursiva relationer (Fig. 12).

Ris. 11. Ogiltiga många-till-många-relationer

Ett obligatoriskt många-till-många-förhållande är i princip omöjligt. Ett sådant förhållande skulle innebära att ingen förekomst av A skulle kunna existera utan B, och vice versa. Faktum är att varje sådan konstruktion alltid visar sig vara felaktig.

Ris. 12. Ogiltiga rekursiva relationer

Dataflödesdiagram

Logisk DFD (Fig. 13) visar källor och sänkor (mottagare) av data utanför systemet, identifierar logiska funktioner (processer) och grupper av dataelement som kopplar en funktion till en annan (flöden), och identifierar även datalager (enheter) , som nås. Dataflödesstrukturer och definitioner av deras komponenter lagras och analyseras i en dataordbok. Varje logisk funktion (process) kan detaljeras med hjälp av en lägre nivå DFD; när ytterligare detaljer inte längre är användbara, gå vidare till att uttrycka funktionens logik med hjälp av en processspecifikation (minispecifikation). Innehållet i varje förvar lagras också i en dataordbok, och datamodellen för förvaret avslöjas med hjälp av ER-diagram.

Ris. 13. DFD-exempel

I synnerhet visar DFD inte de processer som styr det faktiska dataflödet och gör ingen skillnad mellan giltiga och ogiltiga sökvägar. DFD innehåller många användbar information, och dessutom:

• låter dig föreställa dig systemet från en datasynpunkt;
• illustrera externa dataleveransmekanismer som kräver speciella gränssnitt;
• låter dig presentera både automatiserade och manuella systemprocesser;
• utföra datacentrerad partitionering av hela systemet.

Dataströmmar används för att modellera överföringen av information (eller till och med fysiska komponenter) från en del av ett system till en annan. Flöden i diagram representeras av namngivna pilar, pilarna anger i vilken riktning informationen strömmar. Ibland kan information röra sig i en riktning, bearbetas och återgå till sin källa. Denna situation kan modelleras antingen av två olika flöden, eller av ett dubbelriktat.

En process omvandlar en indataström till en utdataström enligt den åtgärd som specificeras av processnamnet. Varje process måste ha ett unikt nummer för referens i diagrammet. Detta nummer kan användas tillsammans med diagramnumret för att ge ett unikt processindex för hela modellen.

Datalagring låter dig definiera data i ett antal områden som kommer att lagras i minnet mellan processer. I själva verket representerar lagret "delar" av dataströmmar över tid. Informationen den innehåller kan användas när som helst efter att den har fastställts, och data kan väljas i valfri ordning. Namnet på förvaret måste identifiera dess innehåll. I det fall ett dataflöde går in i (ut ur) ett lager och dess struktur matchar lagrets struktur måste det ha samma namn, vilket inte behöver återspeglas i diagrammet.

En extern enhet (terminator) representerar en enhet utanför systemkontexten som är källan eller mottagaren av systemdata. Hennes namn måste innehålla ett substantiv, till exempel "Kund". Objekten som representeras av sådana noder förväntas inte delta i någon bearbetning.

STD-tillståndsövergångsdiagram

En entitets livscykel tillhör klassen av STD-diagram (fig. 14). Detta diagram visar förändringen i ett objekts tillstånd över tiden. Tänk till exempel på tillståndet för en produkt på ett lager: en produkt kan beställas från en leverantör, tas emot på lagret, förvaras på ett lager, genomgå kvalitetskontroll, säljas, avvisas eller returneras till leverantören. Pilarna på diagrammet indikerar acceptabla tillståndsändringar.

Ris. 14. Exempel på ett livscykeldiagram

Det finns flera olika alternativ bilder av liknande diagram, endast en av dem visas i figuren.

Några principer för kontroll av en informationsmodells kvalitet och fullständighet
(källa - Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)

Om du vill skapa en högkvalitativ modell måste du ta hjälp av analytiker som är flytande i CASE-teknik. Det betyder dock inte att endast analytiker ska vara med och bygga och följa upp informationsmodellen. Hjälp från kollegor kan också vara till stor hjälp. Involvera dem i att kontrollera det angivna målet och i en detaljerad studie av den konstruerade modellen, både ur logikens synvinkel och ur synpunkten att ta hänsyn till aspekter av ämnesområdet. De flesta har lättare att hitta fel på någon annans arbete.

Lämna regelbundet in din informationsmodell, eller delar av den som du är orolig över, för användargodkännande. Var särskilt uppmärksam på undantag och begränsningar.

Entitetskvalitet

Den huvudsakliga garantin för kvaliteten på en enhet är svaret på frågan om objektet verkligen är en enhet, det vill säga ett viktigt objekt eller fenomen, information om vilket bör lagras i databasen.

Lista över verifieringsfrågor för enheten:

• Återspeglar entitetsnamnet essensen av detta objekt?
• Finns det någon överlappning med andra enheter?
• Finns det minst två attribut?
• Det finns inte fler än åtta attribut totalt?
• Finns det några synonymer/homoonymer för denna enhet?
• Är enheten helt definierad?
• Finns det en unik identifierare?
• Finns det åtminstone en koppling?
• Finns det minst en funktion för att skapa, söka, redigera, ta bort, arkivera och använda ett entitetsvärde?
• Finns det en historia av förändringar?
• Finns det överensstämmelse med principerna för datanormalisering?
• Finns det samma enhet i ett annat applikationssystem, kanske under ett annat namn?
• Är essensen för allmän?
• Är nivån av generalisering som finns i den tillräcklig?

Lista över screeningfrågor för undertypen:

• Finns det någon överlappning med andra undertyper?
• Har subtypen några attribut och/eller relationer?
• Har de alla sina egna unika identifierare eller ärver de en för alla från supertypen?
• Finns det en heltäckande uppsättning undertyper?
• Är inte en undertyp ett exempel på en förekomst av en entitet?
• Känner du till några attribut, relationer eller villkor som skiljer denna subtyp från andra?

Attribut kvalitet

Det är nödvändigt att ta reda på om dessa verkligen är attribut, det vill säga om de beskriver denna enhet på ett eller annat sätt.

Lista över frågor om attributverifiering:

• Är attributnamnet ett singularsubstantiv som återspeglar essensen av egenskapen som anges av attributet?
• Inkluderar inte attributnamnet entitetsnamnet (det borde det inte)?
• Har ett attribut bara ett värde åt gången?
• Finns det några dubbletter av värden (eller grupper)?
• Beskrivs format, längd, acceptabla värden, förvärvsalgoritm etc.?
• Kan detta attribut vara en saknad enhet som skulle vara användbar för en annan applikationssystem(redan befintlig eller föreslagen)?
• Kan han vara en missad anslutning?
• Finns det någon hänvisning någonstans till ett attribut som en "designfunktion" som borde försvinna när man flyttar till applikationsnivå?
• Finns det behov av en förändringshistorik?
• Beror dess innebörd endast på denna enhet?
• Om attributets värde krävs, är det alltid känt?
• Finns det ett behov av att skapa en domän för detta och liknande attribut?
• Beror dess värde bara på någon del av den unika identifieraren?
• Beror dess värde på värdena för vissa attribut som inte ingår i den unika identifieraren?

Anslutningskvalitet

Vi måste ta reda på om relationerna faktiskt återspeglar de viktiga relationer som observeras mellan enheter.

Lista över kontrollfrågor för kommunikation:

• Finns det en beskrivning för varje inblandad part, återspeglar den korrekt innehållet i kommunikationen och passar den inom den accepterade syntaxen?
• Är det bara två parter inblandade?

Är inte anslutningen bärbar?

• Är graden av anknytning och engagemang specificerad för varje part?
• Är anslutningsdesignen acceptabel?

Är anslutningsdesignen en av dem som sällan används?

• Är det inte överflödigt?
• Förändras det inte med tiden?
• Om anslutningen är obligatorisk, speglar den då alltid förhållandet till den enhet som representerar den motsatta sidan?

För en exklusiv anslutning:

• Har alla ändarna på länkarna som omfattas av undantagsbågen samma typ av åtagande?
• Avser de alla samma enhet?
• Vanligtvis bågar korsar förgrenade ändar - vad kan du säga om det här fallet?
• En anslutning kan endast täckas av en båge. Är det så?
• Är alla ändarna på länkarna som täcks av bågen inkluderade i den unika identifieraren?

Systemfunktioner

Analytiker måste ofta beskriva ganska komplexa affärsprocesser. I det här fallet tillgriper de funktionell nedbrytning, som visar uppdelningen av en process i ett antal mindre funktioner tills var och en av dem inte längre kan delas upp utan att kompromissa med innebörden. Slutprodukten av nedbrytningen är en hierarki av funktioner, på den lägsta nivån av vilka det finns funktioner som är atomära i termer av semantisk belastning. Låt oss ge ett enkelt exempel (fig. 15) på en sådan sönderdelning. Låt oss överväga den enklaste uppgiften att utfärda en faktura till en kund när vi släpper varor från ett lager, förutsatt att uppsättningen varor som kunden vill köpa redan är känd (vi kommer inte att överväga i detta exempel produktvalsuppgift).

Ris. 15. Nedbrytningsexempel

Uppenbarligen kan operationen med att välja och beräkna rabatter också delas upp i mindre operationer, till exempel att beräkna rabatter för åtagande (kunden köper varor över tid) och beräkna rabatter för mängden inköpta varor. Atomfunktioner beskrivs i detalj, till exempel med DFD och STD. Uppenbarligen utesluter inte en sådan beskrivning av funktioner ytterligare verbala beskrivningar (till exempel kommentarer).

Det bör noteras att i analysstadiet bör uppmärksamhet ägnas analys- och bearbetningsfunktionerna möjliga fel och avvikelser från den avsedda standarden för systemdrift. De mest kritiska processerna för systemdrift bör identifieras och en särskilt noggrann felanalys bör tillhandahållas för dem. DBMS-felhantering (returkoder) är som regel en separat uppsättning funktioner eller en enda funktion.

Att klargöra strategin

I analysstadiet klargörs vilken hårdvara och mjukvara som valts för den slutliga implementeringen. Testgrupper och tekniska specialister kan vara involverade för detta ändamål. När man utformar ett informationssystem är det viktigt att ta hänsyn ytterligare utveckling system, till exempel en ökning av volymen bearbetade data, en ökning av intensiteten i flödet av förfrågningar, förändringar i tillförlitlighetskraven för informationssystemet.

I analysstadiet bestäms uppsättningar av uppgiftsmodeller att erhålla jämförande egenskaper vissa DBMS som övervägdes vid fastställandet av strategin för implementering av informationssystemet. I strategidefinitionsstadiet kan ett DBMS väljas. Det finns redan mycket mer data om systemet på analysstadiet, och det är mer detaljerat. De erhållna uppgifterna, såväl som de egenskaper som sänts av testteamen, kan visa att valet av DBMS vid strategidefinitionsstadiet var felaktigt och att det valda DBMS inte kan uppfylla vissa krav i informationssystemet. Samma data kan erhållas angående val av hårdvaruplattform och operativsystem. Att erhålla sådana resultat initierar en förändring av data som erhålls vid strategidefinitionsstadiet, till exempel beräknas kostnadsberäkningen för projektet om.

Valet av utvecklingsverktyg förtydligas också i analysstadiet. På grund av att analysstadiet ger en mer komplett bild av informationssystemet än vad det var vid strategidefinitionsstadiet kan arbetsplanen justeras. Om det utvecklingsverktyg som valdes i föregående skede inte tillåter att en eller annan del av arbetet slutförs inom den givna tidsramen, fattas beslut om att ändra tidsfristerna (vanligtvis en ökning av utvecklingsperioden) eller att ändra utvecklingsverktyg. När du väljer vissa verktyg bör du ta hänsyn till närvaron av högt kvalificerad personal som är skicklig i de valda utvecklingsverktygen, såväl som närvaron av administratörer för det valda DBMS. Dessa rekommendationer kommer också att förtydliga uppgifterna vid valet av strategi (den uppsättning villkor under vilka det framtida systemet förväntas fungera).

Begränsningar, risker och kritiska faktorer specificeras också. Om några krav inte kan tillgodoses i informationssystemet implementerat med hjälp av DBMS och mjukvara som valts vid strategidefinitionsstadiet, initierar detta också förtydliganden och förändringar i mottagna data (i slutändan kostnadsuppskattningar och arbetsplaner, och eventuellt förändringar i kundkrav för system, till exempel deras försvagning). De funktioner som inte kommer att implementeras i systemet beskrivs mer i detalj.

Design av informationssystem börjar alltid med att definiera målet för projektet. I allmänna termer kan målet med projektet definieras som att lösa ett antal sammanhängande uppgifter, inklusive att säkerställa vid tidpunkten för systemlansering och under hela driftperioden:

• den erforderliga funktionaliteten hos systemet och nivån på dess anpassningsförmåga till förändrade driftsförhållanden;
• erforderlig systemgenomströmning;
• erforderlig systemsvarstid på en begäran;
• problemfri drift av systemet;
• erforderlig säkerhetsnivå;
• enkel drift och systemstöd.

Enligt modern metodik, är processen att skapa ett IS en process för att konstruera och sekventiellt transformera ett antal konsekventa modeller över alla livscykelstadier(LC) IS. I varje skede av livscykeln skapas modeller som är specifika för det - organisation, IS-krav, IS-projekt, applikationskrav, etc. Modeller bildas av projektgruppens arbetsgrupper, sparade och ackumulerade i projektförrådet. Skapandet av modeller, deras kontroll, omvandling och tillhandahållande för kollektivt bruk utförs med hjälp av speciella mjukvaruverktyg - CASE-verktyg.

Processen att skapa en IP är uppdelad i en serie etapper(steg [1.1]), begränsad av en viss tidsram och slutar med lanseringen av en specifik produkt (modeller, mjukvaruprodukter, dokumentation, etc.).

Vanligtvis särskiljs följande stadier av IP-skapande: bildande av systemkrav, design, implementering, testning, driftsättning, drift och underhåll [1.1] [1.2]. (De två sista stegen diskuteras inte vidare eftersom de ligger utanför kursens omfattning.)

Det inledande skedet av skapandet av IS är modellering av affärsprocesser som förekommer i en organisation och förverkligande av dess mål och mål. Organisationsmodellen, beskriven i termer av affärsprocesser och affärsfunktioner, tillåter oss att formulera de grundläggande kraven för IS. Denna grundläggande ställning för metodiken säkerställer objektivitet vid utveckling av systemdesignkrav. Uppsättningen av modeller för att beskriva IS-krav omvandlas sedan till ett system av modeller som beskriver den konceptuella designen av IS. Modeller av IS-arkitektur, mjukvarukrav och informationsstöd(OCH OM). Därefter formas mjukvaru- och informationsarkitekturen, företagsdatabaser och enskilda applikationer identifieras, applikationskravmodeller formas och deras utveckling, testning och integration genomförs.

Syftet med initialen stadier av IP-skapande utförs i det skede av analys av organisationens aktiviteter, är bildandet av krav på informationssystem som korrekt och korrekt återspeglar målen och målen för kundorganisationen. För att specificera processen för att skapa informationssystem som möter organisationens behov är det nödvändigt att ta reda på och tydligt formulera vilka dessa behov är. För att göra detta är det nödvändigt att fastställa kundkrav för IS och mappa dem på modellspråk till kraven för att utveckla ett IS-projekt för att säkerställa överensstämmelse med organisationens mål och mål.

Uppgiften att ställa krav på informationssystem är en av de viktigaste, svåra att formalisera, och den dyraste och svåraste att rätta till vid fel. Moderna verktyg och mjukvaruprodukter gör att du snabbt kan skapa IP enligt färdiga krav. Men ofta tillfredsställer dessa system inte kunderna och kräver många modifieringar, vilket leder till en kraftig kostnadsökning verklig kostnadÄR. Huvudorsaken till denna situation är den felaktiga, felaktiga eller ofullständiga definitionen av IS-kraven i analysstadiet.

På designstadiet bildas först datamodeller. Designers får analysresultat som initial information. Att bygga logiska och fysiska datamodeller är huvuddelen databasdesign. Informationsmodellen som erhålls under analysprocessen omvandlas först till en logisk modell och sedan till fysisk datamodell.

Parallellt med design databasscheman Processdesign utförs för att få specifikationer (beskrivningar) av alla IS-moduler. Båda dessa designprocesser är nära besläktade eftersom en del av affärslogiken vanligtvis implementeras i databasen (begränsningar, triggers, lagrade procedurer). huvudmålet processdesign består av att kartlägga de funktioner som erhålls vid analysstadiet till moduler i informationssystemet. Vid design av moduler bestäms programgränssnitt: menylayout, fönsterutseende, snabbtangenter och relaterade anrop.

De slutliga produkterna i designfasen är:

• databasdiagram (baserat på ER-modellen som utvecklades i analysstadiet);
• utrustning modulspecifikationer system (de är byggda på basis av funktionsmodeller).

Dessutom, på designstadiet, genomförs även utvecklingen av IS-arkitekturen, inklusive val av plattform (plattformar) och operativsystem (operativsystem). I en heterogen IS kan flera datorer köras på olika hårdvaruplattformar och köra olika operativsystem. Förutom att välja en plattform, bestäms följande arkitekturegenskaper vid designstadiet:

• om det kommer att vara en fil-server- eller klient-server-arkitektur;
• kommer det att vara en arkitektur i tre nivåer med följande lager: server, mellanprogram (applikationsserver), klientprogramvara;
• om databasen kommer att centraliseras eller distribueras. Om databasen distribueras, vilka mekanismer kommer då att användas för att upprätthålla datakonsistens och relevans;
• om databasen kommer att vara homogen, det vill säga om alla databasservrar kommer att vara från samma tillverkare (till exempel är alla servrar enbart Oracle eller alla servrar endast DB2 UDB). Om databasen inte är homogen, vilken programvara kommer då att användas för att utbyta data mellan DBMS från olika tillverkare (redan befintlig eller speciellt utvecklad som en del av projektet);
• kommer parallella databasservrar (till exempel Oracle Parallel Server, DB2 UDB, etc.) att användas för att uppnå korrekt prestanda?

Designfasen avslutas med utveckling tekniskt projektÄR.

Vid implementeringsstadiet skapas systemmjukvaran, hårdvara installeras och driftdokumentation utvecklas.