Mandat for utvikling av et pedagogisk informasjonssystem. Referansevilkår for opprettelse av et automatisert informasjonssystem
Tekniske spesifikasjoner for design informasjon System. Hoveddeler av de tekniske spesifikasjonene. Standarder som beskriver teknisk oppgave. Analyse og utvikling av krav.
Teknisk oppgave- et teknisk dokument (spesifikasjon) som spesifiserer et sett med krav til systemet og er godkjent av både kunde/bruker og entreprenør/produsent av systemet. En slik spesifikasjon kan også inneholde Systemkrav og testkrav.
De tekniske spesifikasjonene inneholder følgende avsnitt:
Generell informasjon. Denne delen inkluderer: hele navnet på utviklingen, fullt navn og detaljer om kunden og entreprenøren, en liste over dokumenter som er grunnlaget for utviklingen, mulige start- og sluttdatoer for arbeidet, prosedyren for behandling og presentasjon for kunden resultatene av arbeidet med å lage systemet eller dets deler.
Årsaker og formål med utvikling. Formålet med utvikling refererer til typen automatiserte aktivitetsprosesser.
Systemkrav. Inneholder underavsnitt med krav til systemet som helhet og funksjonene som utføres av systemet.
Sammensetning og innhold i arbeidet for å lage systemet. Liste over arbeider og deres innhold som forventes utført innenfor rammen av dette prosjektet
Prosedyre for kontroll og aksept av systemet. Inneholder omtrentlige datoer for mellomkontroll og omtrentlig dato for levering til kunden.
Krav til sammensetning og innhold av arbeid med å forberede utviklingsobjektet for å sette systemet i drift. Forarbeidene for å sette anlegget i drift er beskrevet.
Dokumentasjonskrav. Inneholder en liste og sammensetning av systemdokumentasjon.
Kilder til utvikling. Inneholder en liste over dokumentasjon og litteratur som skal brukes i utviklingen av systemet.
Det er tre standarder som beskriver de tekniske spesifikasjonene for å designe en IS: GOST 34.602-89, GOST 19.201-78, GOST 19.102-77.
Kravutvikling kan baseres på undersøkelser, spørreskjemaer mv. I tillegg kan det dannes krav på grunnlag av idédugnad, observasjon av produksjonsaktiviteter, analyse av regulatorisk dokumentasjon, analyse av allerede opprettet IS, analyse av versjoner av IS som brukes.
Ved utvikling av krav oppstår ofte problemer med tvetydighet, ufullstendighet og inkonsekvens av individuelle krav. Å fikse disse problemene under kravutviklingsstadiet koster flere størrelsesordener mindre enn å fikse de samme problemene senere i utviklingen.
Brukergrensesnitt av informasjonssystemer. Generelle prinsipper for konstruksjon. Brukergrensesnittstiler. Ytelseskriterier brukergrensesnitt. Retningslinjer for design av brukergrensesnitt. Designregler.
Brukergrensesnitt– dette er programvaredelen av informasjonssystemet, ansvarlig for å administrere enhetene som brukeren kommuniserer med programmet.
Planlegging og design av brukergrensesnitt bør være basert på følgende modeller:
- Mental modell– noen forventninger til en person basert på en følelse av virkelighet og på hans kunnskap og erfaring med å jobbe med en datamaskin.
- Tilpasset modell- ved å observere hvordan brukere jobber med et nytt grensesnitt og analysere deres tilbakemeldinger på arbeidet, kan du danne deg generelle ideer om det fremtidige grensesnittet. Det er viktig at brukeren inkluderes i arbeidet med IS så tidlig som mulig.
- Programmerer modell– er født i programmererens hode og er basert på hans profesjonelle aktiviteter.
Brukergrensesnittstiler. Det er fire hovedstiler for brukergrensesnitt:
- Grafisk brukergrensesnitt (Grafisk Bruker Grensesnitt, GUI) – dette grensesnittet er basert på fire grunnleggende elementer: vinduer, pekere (mus), menyer og ikoner. Andre elementer brukes også: knapper, brytere, inndatafelt osv. En funksjon i dette grensesnittet er de avanserte mulighetene for skjermdesign og kontroll ved hjelp av musepekeren.
- Web-grensesnitt (Web Bruker Grensesnitt, WUI) – Grensesnittet ligner GUI-grensesnittet, men var i utgangspunktet dårligere enn det. Spesielt brukte den en enkelt vindu-modus og hadde ikke muligheten til å "dra og slippe" objekter. Med utviklingen av JavaScript og Ajax blir det mer som et GUI-grensesnitt.
- GrensesnittHUI (Menneskelig Bruker Grensesnitt) er brukergrensesnittet til håndholdte enheter. Vanligvis har slike enheter en veldig liten skjerm. Den inneholder noen GUI-elementer, for eksempel menyelementer og ikoner.
- Objektgrensesnittstil. Objektprogrammeringsevner bringer objektenes natur inn i brukergrensesnittet. Objekttilnærmingen er preget av evner som å dra elementer, kontekstmenyen, verktøytips osv.
Vurder et sett med kvalitetskriterier for brukergrensesnitt:
- Forstå brukere - i hvilken grad brukerbehov gjenspeiles i programgrensesnittet.
- Effektivitet i designprosessen– avgjør om produktet er nøye gjennomtenkt og designet.
- Nødvendigheten av prosjektet– om produktet har økonomisk og sosial betydning.
- Egnethet for studier og bruk– hvor vanskelig produktet er å lære og bruke.
- Korrespondanse– om produktdesignet samsvarer med å løse problemene som stilles.
- Estetiske følelser– hvor estetisk tiltalende produktet er å bruke.
- Foranderlighet– hvor mye designet kan endres i henhold til brukerkrav.
- Kontrollerbarhet– i hvilken grad er primplementert: installasjonsadministrasjon, opplæring, support.
Generelle prinsipper for å konstruere et grafisk grensesnitt:
Bruk av et enkeltbrukermiljø i form av et såkalt skrivebord;
Bruke grafiske vinduer for å vise data;
Bruker ikke-tastaturinndata (ved hjelp av en mus).
Utformingsregler for brukergrensesnitt:
- Brukerkontroll - utviklere må gi brukeren den mest komplette kontroll over IP-en (så langt sikkerheten tillater det). La oss vurdere flere spesielle implementeringer av dette prinsippet:
1) redusere minnebelastningen - brukerens minne er ikke så stort og ikke så raskt.
2) grensesnittkompatibilitet – brukernes evne til å overføre sin erfaring og kunnskap til å jobbe med ny programvare.
Modellering av informasjonssystemer. Behovet for modelleringsspråk. SpråkUML. Prinsipper for objektorientert design. Oversikt over språkdiagrammerUML. Bruk kasusdiagrammer og klassediagrammer.
Modellering– dette er erstatning av objektet som studeres (original) med dets konvensjonelle bilde eller et annet objekt (modell) og studiet av egenskapene til originalen ved å studere egenskapene til modellen.
Effektiviteten til modellering kan oppnås hvis to betingelser er oppfylt: modellen gir en korrekt visning av egenskapene til originalen; Modellen eliminerer problemene som ligger i å ta målinger på et virkelig objekt.
Modelleringsspråk – er en notasjon, primært grafisk, som brukes til å beskrive prosjekter. Notasjon representerer en samling grafiske objekter som brukes i modellen. Notasjon er syntaksen til et modelleringsspråk. Modelleringsspråket skal på den ene siden gjøre designerens beslutninger forståelige for brukeren, og på den andre siden gi designere midler for den mest formaliserte representasjonen av informasjonssystemet. Grafisk representasjon er ofte den mest forståelige formen for å presentere informasjon.
UML (Samlet Modellering Språk– enhetlig modelleringsspråk)- Språk grafisk beskrivelse for objektmodellering i programvareteknikk.UML bruker grafisk notasjon for å representere en abstrakt modell av et system, kalt en UML-modell. Dette språket er utviklet for modellering av IS. UML er ikke et programmeringsspråk, men kode er generert basert på UML-modellen.
Objektorientert modell er et sett med diagrammer som beskriver, ved hjelp av UML-språket, ulike aspekter av strukturen og oppførselen til IS.
DiagramUML- Dette grafisk representasjon et sett med elementer, oftest avbildet som en graf med toppunkter (entiteter) og kanter (relasjoner).
Utvikling av et informasjonssystem for registrering av arbeidet til en byggevirksomhet
2. Mandat for opprettelse av et informasjonssystem
2.1 Generell informasjon
Automatisert informasjonssystem "Byggebedrift"
2.2 Mål med å lage et informasjonssystem
For å løse problemene med kontroll og regnskap for design, produksjon og salg, opprettes et automatisert informasjonssystem i denne virksomheten, som er designet i ACCESS DBMS-miljøet.
Informasjon i skjemaet distribuert base Dataene lagres dels på filserveren og dels på arbeidsstasjoner som er en del av det lokale datanettverket til salgsavdelingen. En type automatisert aktivitet er regnskap.
De viktigste driftsmidlene til dette selskapet er bygningene til bedriften ZAO UniStroy - NN, som huser kontrollautomatiseringsutstyr (datamaskiner - arbeidsstasjoner, servere, så vel som andre tekniske enheter).
Hovedfunksjonene som IS løser:
· Overvåke driften av virksomheten;
· Regnskap for selskapets salg;
· Regnskap for resultater (foretakets inntekter og utgifter).
Systematisering og automatisk kontroll over virksomhetens arbeid, salg, bestillinger.
2.3 Kjennetegn på automasjonsobjekter
Hoved aktivitet av denne bedriften er organiseringen av design og salg av varer, noe som betyr at regnskapsvirksomheten til den økonomiske avdelingen vil være hovedobjektet for automatisering.
2.4 Systemkrav
2.4.1 Krav til inn-, referanse- og utdatainformasjon
Inndatainformasjonen til design-, produksjons- og salgsavdelingen inkluderer dataene som er nødvendige for å løse alle problemene som er løst i denne avdelingen. I primærformen kommer disse dataene i form av papirdokumenter. Hovedinndatainformasjonen inkluderer følgende data:
· Dokumenter mottatt fra økonomiplanavdelingen en gang i måneden, som inneholder planlagte oppgaver for design og salg;
· Data som kommer fra markedsavdelingen, som inneholder forespørsler om levering av varer og annet arbeid, informasjon om etablerte priser;
Utdatainformasjonen kan presenteres i form av et papirdokument, i skjemaet informasjonsmelding eller som en fil ( elektronisk dokument) på magnetiske medier.
Disse dataene presenteres i form av en databasetabell, i form av en spørring, og også i form av en rapport på skjermen og på papir.
Utgangsresultatene for å løse problemet med å regnskapsføre resultatene av en virksomhets aktiviteter vises:
· Til skriveren og til harddisken i design- og produksjonsavdelingen, og salgsavdelingen;
· Overført via kommunikasjonskanal til regnskapsavdelingen og økonomiplanavdelingen.
Utgangsdata utgis hvert kvartal.
2.4.2 Forslag til koding og klassifisering av opplysninger
Koding av inputinformasjon må utføres under hensyntagen til følgende krav:
· Redusere tid og andre kostnader for å løse problemer i kontrollsystemet;
· Sikre informasjon av høy kvalitet.
Informasjonssystemet bruker en ordinær metode for koding av inputinformasjon (Tabell: Design- og produksjonsregnskap, felt - postnummer, Salgsregnskap - postnummer).
Disse dataene er kodet ved hjelp av ordinalmetoden. Fordelen er brukervennlighet, ulempen er kodeoverløp.
Klassifisering av informasjon.
Det er 2 klassifiseringsmetoder:
· Hierarkisk - denne klassifiseringsmetoden forstås som en metode der et gitt sett er sekvensielt delt inn i underordnede undergrupper, gradvis spesifisere objektet for klassifisering. I dette tilfellet er divisjonsgrunnlaget en utvalgt egenskap. Helheten av de resulterende grupperingene danner en hierarkisk trestruktur i form av en forgrenende graf, hvis noder er grupperingene.
· Fasett - denne klassifiseringsmetoden innebærer parallell inndeling av mange objekter i uavhengige klassifiseringsgrupper. I dette tilfellet forutsettes det ikke en rigid klassifiseringsstruktur og forhåndskonstruerte endelige grupperinger. Klassifiseringsgrupperinger dannes ved å kombinere verdier hentet fra de tilsvarende fasettene.
Kvaliteten på informasjon i styringssystemer er et sett med egenskaper som bestemmer egnetheten til data for å møte behovene til styringssystemet. De viktigste egenskapene til informasjon som brukes i kontrollsystemer er:
Ш Kumulativitet - fullstendighet av informasjon;
Ш Pålitelighet - fravær av skjulte feil;
Ш Sikkerhet - umulighet for uautorisert tilgang;
Ш Effektivitet - aktualitet;
Ш Homomorphy - data må presenteres i en form;
Ш Identitet - korrespondanse av objekter for øyeblikket;
Ш Konfidensialitet - hemmelighold.
Den viktigste programvaremetoden for å overvåke kvaliteten på informasjonen som brukes i styringssystemet er:
· Logisk - semantisk sjekk, dvs. kontroll ved avvik, i henhold til en gitt sekvens av poster
· Programvare.
I dette arbeidet utføres informasjonskvalitetskontroll ved å bruke knappen "Reliability Control". Tabellene kontrolleres: produkter, prosjekter og salgsregnskap. Hvis tabellen inneholder negative verdier for produksjonskostnad, salgspris, designkostnad og mengde, oppdages en feil når knappen trykkes. Ellers meldes det at det ikke er noen feil.
2.4.4 Foreslåtte tiltak for å beskytte informasjon mot uautorisert tilgang
Uautorisert tilgang - innhenting av informasjon uten tillatelse fra eieren.
Dens typer:
1. Indirekte - lytteenheter, eksterne fotografier, radioavlytting, etc.
2. Direkte - direkte tyveri av lagringsmedier, lesing av data fra disken, innlogging på systemet ved hjelp av andres passord, maskering av forespørsler under systemforespørsler, infeksjon med programvarevirus osv.
Den mest sårbare delen av informasjonen er beskyttet ved hjelp av følgende metoder:
· Prosedyremessige - organisatoriske - tekniske tiltak - identifikasjon av alle datamaskiner og brukere, etablering av arbeidsreglement, spesifikke databaser og programmer.
· Programvare - databasebeskyttelse og applikasjonsprogrammer fra kopiering, antivirusprogrammer, kryptering, sikkerhetskopiering av informasjon
Informasjonssystemet bruker programvaremetoden beskyttelse (virusskanning).
Databasen ble opprettet i ACCESS DBMS-systemet fordi den er mer fokusert på den gjennomsnittlige brukeren, sammenlignet for eksempel med FOXPRO DBMS, som er fokusert på applikasjonsprogrammereren. Valget av DBMS bestemmes av kompleksitetsnivået til forvaltningsoppgavene som løses som en del av AIS. Derfor for dette kursarbeid ACCESS DBMS er optimal.
2.4.5 Krav til databasen (DB) og DB-styringssystem
Databasestyringssystemet som vil bli brukt i det automatiserte systemet er ACCES DBMS, siden det er mer fokusert på den gjennomsnittlige brukeren, og FOXPRO DBMS er mer fokusert på applikasjonsprogrammereren.
2.4.6 Krav til tekniske midler
Det anbefales å bruke PC med Pentium prosessor-IV, med RAM på minst 256 MBt, med diskminne med en kapasitet på minst 200 Gb. Dette vil sikre høyytelses LAN-drift ved bruk av hvilken som helst topologi og operativsystem.
Krav til hjelpeenheter. For å jobbe på nettverket er 32-bit installert nettverksadaptere EtherNet med ISA-protokoll eller TokenRing-adaptere med MicroChannel-protokoll, eller ArcNet-nettverksadaptere med ISA-protokoll.
Nettverksskriveren må oppfylle følgende krav:
· Ha høy produktivitet;
· Ha tilstrekkelig bufferminne;
· Ha høy driftssikkerhet;
· Gi høy kvalitet printing;
· Det anbefales å kunne kopiere dokumenter.
Ut fra dette gjelder det laserskriver- HP LaserJet 1100.
For å øke påliteligheten til nettverket, er det nødvendig å installere enheter avbruddsfri strømforsyning UPS, spesielt for filservere.
3. Teknisk arbeidsutkast (Designløsning)
Automatisering av plagiatsøkeprosessen
Automatisering av teknisk støtte for brukere
I samsvar med GOST 34.601-90 gjelder denne standarden for automatiserte systemer (AS) som brukes i ulike typer aktiviteter (forskning, design, ledelse, etc.), inkludert deres kombinasjoner opprettet i organisasjoner...
Automatisering av beregninger for lønn ved å bruke eksemplet til Nechkinskoye OJSC, Sarapul-distriktet i Udmurt-republikken ved å bruke 1C:Enterprise 8.0-programmet
Automatisert informasjonssystem for vannforbruksmåling
Generell informasjon Fullt navn på systemet og dets symbol Informasjonssystem for regnskapsføring av vannforbruk ved å bruke eksemplet med aksjeselskapet "Vodosnabzhenie" (AIS URV "Vodosnabzhenie")...
Automatisert informasjonssystem for registrering av lagring og vedlikehold av kontroll- og måleinstrumenter
Referansevilkårene ble utviklet i samsvar med GOST 34.602-89 "Informasjonsteknologi. Et sett med standarder for automatiserte systemer. Referansevilkår for opprettelse av et automatisert system"...
Virtuelt dekankontor
For å oppdatere nettstedet gir avdelingen ny informasjon, bilder og mediefiler som må erstattes på noen av sidene. Utskifting utføres ved å følge instruksjonene i trinn 2...
Informasjonssystem "Klinnik"
1. Bestemme formålet med den utviklede IS: Forbedre kvaliteten på kundeservicen for organisasjonen, fremskynde dokumentasjonsprosessen. 2...
Informasjonsstøtte for ATP
Utvalg teknisk støtte Vi produserer under hensyntagen til organisasjonsstrukturen til bensinstasjonen...
Design av informasjonsnettverk
Hensikten med kursene vil være å utvikle informasjonsnettverk i kommunalt utdanningsinstitusjon gymsal nr. 7, fysisk plassert i en enetasjes bygning...
Utvikling av en organisasjons nettside (basert på materiale fra Avtomir LLC, Gomel)
La oss vurdere nivået på teknisk støtte hos Avtomir LLC. Alle jobber i organisasjonen er automatisert. Personlige datamaskiner er installert på arbeidsplasser...
Utvikling og design av informasjonssystem for salongen mobil kommunikasjon med hjelp Microsoft Access i språket Visuell programmering Grunnleggende
Et av stadiene for å designe et automatisert informasjonssystem er utvikling og godkjenning av tekniske spesifikasjoner for opprettelsen av systemet. Den tekniske spesifikasjonen er hoveddokumentet...
Utvikling av et informasjonssystem for nettverksadministratoren til organisasjonen LLC "WestCall"
Utvikling av regnskapssystem for data- og kontorutstyr og Rekvisita
1 Generell informasjon. 1.1 Fullt navn på systemet og dets symbol "Bentec IT & Soft invent" 2. Hensikt og mål med å lage systemet. 2.1 Formålet med systemet...
Utvikling av tekniske spesifikasjoner for automatisering av Bukva-butikken
Generell informasjon Navn på systemet: automatisert system for registrering av aktivitetene til butikken "Bukva-Serov". Kundeselskapet er Etalon LLC...
Opprette en gruppeside
1) Produkttype: Dynamisk gruppenettsted; 2) Mål: Oppretting av et gruppenettsted for å gjøre det enklere å informere gruppestudenter i løpet av ikke-skole- og akademiske timer; 3) Målgruppe: Gruppestudenter og universitetslærere; 4) Krav til nettstedet: 1) Praktisk...
Hjem > Tekniske spesifikasjonerKULTURDEPARTEMENTET I RF
St. Petersburg State University kultur og kunst
Institutt for informatikk og informasjonsteknologi
INFORMASJONSSYSTEMER DESIGN
TEKNISK OPPGAVE
for utvikling
pedagogisk informasjonssystem
< Fullt navn på systemet og dets symbol >
på 4 ark
__.__.200_ utstedt
Saint Petersburg
Generell informasjon
Årsaker til utvikling
- De planlagte datoene for oppstart og fullføring av arbeidet, samt prosedyren for å behandle og presentere resultatene av arbeidet til kunden, er bestemt i paragraf 4 og 5 i denne TOR.
Hensikt og mål med å skape et pedagogisk informasjonssystem
- Hensikt
- å demonstrere i hvilken grad studenten mestrer innholdet i emnet «Design og bruk av informasjonssystemer», til bruk som layout i videre arbeid ah om å lage eller forbedre et ekte informasjonssystem.
- Mål med å lage et pedagogisk informasjonssystemprosjekt
- å oppnå av studenten en forståelse av de grunnleggende konseptene i systemdesignprosessen, mestre sammenhengene mellom grunnleggende konsepter og designmetoder, evnen til å utvikle et systemdesign og dets dokumentasjon, samt lage en ekte IP, demonstrere resultatene av arbeidet og graden av mestring av kursinnholdet, skaper grunnlag for videre arbeid med å forbedre prosjektet og dets praktiske gjennomføring.
Krav til rapporteringsmateriell til utdanningsinformasjonssystemet
- Krav til materialer generelt
- Sammensetning av rapporteringsmateriell. Rapporteringsmateriell bør bestå av to hoveddeler: prosjektdokumentasjon og et oppsett av informasjonssystemet (en fullført database sammen med forespørsler, skjemaer, rapporter, tilgangssider), implementert ved hjelp av ACCESS DBMS (eller annet system). Oppsettet skal gjennomføres i henhold til prosjektet. Designmaterialene skal beskrive utformingen og dens muligheter.
- Innhold i prosjektdokumentasjon
- Tittelside med navnet på designet IP, angivelse av utvikler og kunde. Avsnittet "Feasibility Study", som inneholder en kort beskrivelse fagområde:
- generelle egenskaper fagområde og tilstand av automatiseringsarbeid informasjonsaktiviteter i dette området; analyse av evnene og funksjonene til eksisterende lignende systemer; organisasjonsstrukturen til organisasjonen som den utformede IS blir opprettet for; hva er formålet med organisasjonen (systemet) som bruker den utformede IS, dens funksjoner (organisasjonsmessig, "materiell", informasjonsmessig); viktigste tekniske og økonomiske indikatorer for organisasjonens aktiviteter; informasjonsprosesser, forbindelser mellom dem; sammensetningen av dokumentene som brukes og deres formål.
- Korte tekniske spesifikasjoner. De tekniske spesifikasjonene må gjenspeile:
- formål og mål for å skape IP; krav til systemet som helhet; grunnleggende automatiserte funksjoner og oppgaver, tidsegenskaper for å løse problemer og krav til presentasjon av informasjon i systemet;
- kriterier for effektiviteten til systemet som utvikles (faktorer som bestemmer nytten av systemet som utvikles, kriterier for deres evaluering); liste over stadier og faser av arbeidet og frister for gjennomføring, frister for utvikling av prosjektdokumentasjon.
- Seksjon "Teknisk design", som inneholder følgende underseksjoner:
- funksjonell modell av systemet (presenter et kontekstdiagram, et førstenivådiagram og ett eller to andrenivådiagrammer; beskriv sammensetningen av hovedfunksjonene, deres tilkoblinger: inngang, utgang, kontrollstrømmer); dataflytmodell (presenter et kontekstdiagram, et førstenivådiagram og ett eller to andrenivådiagrammer; beskriv sammensetningen av stasjoner, hovedfunksjoner, deres informasjonslenker: inn- og utstrømmer; for hver datalagringsenhet, karakteriser volumet, frekvensen og intensiteten av oppdateringen); beskrivelse av informasjonsstøtte: former for inn- og utdatadokumenter, karakteristikker av deres volum, frekvens, intensitet av oppdatering, analyse av deres struktur (detaljer, beskrevne enheter), brukte klassifikatorer, kodingsmetoder, krav for å sikre datapålitelighet.
- Liste over kilder som er brukt (litteratur). Seksjon "Arbeidsutkast", som inneholder følgende underseksjoner:
- programvare konseptuelle diagram og fysisk diagram systemdatabaser (utviklet ved hjelp av Power Designer-systemet); beskrivelse av den spesifikke utviklingen for gjennomføringen av IP-prosjektet:
- beskrivelse av databaseskjemaet på ACCESS (eller i et annet DBMS), beskrivelse av oppgaver som implementerer funksjonene formulert i Teknisk Design (inkludert spørringer, skjemaer, rapporter, tilgangssider brukt i disse oppgavene). Det er nødvendig å ha dialogskjemaer og bruksanvisninger. Hvis prosjektet ikke har komplekse former, rapporterer, er poengsummen redusert med 1 poeng.
- Konklusjon: Oppsummering av arbeidet. En indikasjon på hvilke av bestemmelsene i Teknisk Design som er implementert og ikke implementert i andre del, og hvorfor.
- Oppsett av informasjonssystem
Oppsettet av informasjonssystemet skal implementeres i henhold til prosjektet. Det skal være en utfylt database med spørringer, skjemaer, rapporter som implementerer oppgavene beskrevet i prosjektet.
- Dokumentasjonskrav
- Sammensetningen av seksjoner og underseksjoner i rapporteringsdokumentet må samsvare med det som er oppført i avsnittet "Innhold i prosjektdokumentasjonen", diagram. funksjonell modell, dataflytmodeller, konseptuelle og fysiske modeller er presentert i form av tegninger og inkludert i hovedteksten; I hovedteksten er også tekster til spørsmål, tegninger av presentasjon av skjemaer, rapporter, tilgangssider, eksempeldokumenter, tabeller som beskriver modeller, tabeller som beskriver egenskapene til databasefelt er gitt som vedlegg.
Liste over arbeidsstadier og frister for gjennomføring
Prosedyren for kontroll og aksept av rapporteringsmateriell
- Rapporteringsmateriell sendes inn innen to frister:
- I høstsemesteret leveres en rapport som tilsvarer de fem første punktene i timeplanen. I vårsemesteret leveres de endelige resultatene av arbeidet: en rapport (inkludert reviderte resultater fra forrige semester), samt en database - et oppsett av den utviklede IS.
- Vurdering av arbeid i høstsemesteret gjennomføres i form av en prøve. I vårsemesteret tas alt av årets arbeid som kurs. Kun studenter som har fullført sitt kursarbeid får gå opp til eksamen. Straffer.
Arbeidsplan for utvikling av rapporteringsmateriell
Tabell 4.1.
| Artistnavnet | Frist | Innsendt materiale |
|
| JOBBER TIL HØSTSEMESTER | |||
| 1 | Velge fagområde og organisasjon som informasjonssystemet skal utformes for | En uke etter første forelesning | IP-navn |
| 2 | "Forskning" av fagområdet (basert på litteratur og som et resultat av kommunikasjon med eksperter) | En uke etter tredje forelesning | |
| 3 | Utvikling av en funksjonell modell | En uke etter den fjerde forelesningen | Funksjonsdiagrammer i håndskrevet form |
| 4 | Utvikling av en dataflytmodell | En uke etter den femte forelesningen | Håndskrevne dataflytdiagrammer |
| 5 | Utvikling av beskrivelser av inn- og utdatadokumenter | Avsluttes 25. november | Dokumentdetaljer struktur, funksjonelle avhengigheter av detaljer |
| 6 | Utvikling av designdokumentasjon i samsvar med punktene 3.2.1 – 3.2.5 | I prosess. praktisk klasser. | |
| 7 | Levering av prosjektdokumentasjon | 20. desember | Dokumentasjon i form av rapport |
| VÅRESSEMESTER FUNGERER | |||
| 8 | Utvikling av et domenekontekstdiagram | En uke etter andre forelesning | Kontekstuell programvarediagram i håndskrevet form |
| 9 | Utvikling av et databaseskjema på språket til valgt DBMS | Ved slutten av den andre praktiske. klasser | |
| 10 | Implementering av systemet (fylle ut databasetabeller, utvikle spørringer, skjemaer, rapporter, tilgangssider) | Ved slutten av den femte praktiske leksjonen | Fullført database med spørringer, skjemaer, etc.; presentert for læreren |
| 11 | Registrering av resultater (prosjekt og database) | En uke etter punkt 9 | Kursarbeid: dokumentasjon, presentert i form av en rapport og i en fil; database |
| 12 | Forsvar selvfølgelig arbeid | Ikke tidligere enn en uke etter forrige forfallsdato |
Send ditt gode arbeid i kunnskapsbasen er enkelt. Bruk skjemaet nedenfor
Studenter, hovedfagsstudenter, unge forskere som bruker kunnskapsbasen i studiene og arbeidet vil være deg veldig takknemlig.
Lagt ut på http://www.allbest.ru/
- Introduksjon
- 1. Tekniske spesifikasjoner
- 1.1 Generell informasjon
- 1.2 Årsaker til utvikling
- 1.3 Hensikt og mål med å lage systemet
- 1.4 Systemkrav
- 1.4.1 Krav til systemet som helhet
- 1.4.2 Krav til funksjoner (oppgaver) som utføres av systemet
- 1.4.3 Krav til typer sikkerheter
- 1.5 Kjennetegn på automasjonsobjekter
- 1.6 Dokumentasjonskrav
- 1.7 Stadier og milepæler i utviklingen
- 1.7.1 Utviklingsstadier
- 1.7.2 Utviklingsstadier
- 1.7.3 Arbeidets innhold etter trinn
- 1.8 Prosedyre for kontroll og aksept av systemet
- 1.8.1 Typer, sammensetning, omfang og testmetoder for systemet og dets komponenter
- 1.8.2 Generelle krav til etappevis aksept av arbeid
- 1.8.3 Status for akseptkomiteen (statlig, interdepartemental, avdelingsvis)
- 2. Teknisk design
- 2.1 Funksjonell struktur
- 2.1.1 Beskrivelse av fagområdet
- 2.1.2 Funksjoner og organisasjonsstruktur
- 2.1.3 Beskrivelse av datastrømmer og forretningsprosesser
- 2.2 IC-systemdesign
- 2.2.1 Utvikling av konsept, arkitektur og implementeringsplattform for IS
- 2.2.2 Informasjonssystemets struktur, sammensetning av funksjonelle og støttende delsystemer
- 2.2.3 IS teknisk støtte
- 2.3 IS informasjonsstøtte
- 2.3.1 Beskrivelse logisk struktur informasjonsgrunnlag
- 2.3.2 Beskrivelse av den fysiske implementeringen av databasen
- Konklusjon
- Bibliografi
Introduksjon
Kursarbeidet undersøker problemstillingene med å lage tekniske spesifikasjoner for utvikling av et informasjonssystem for et system for et byrå for salg og reservasjon av flybilletter. Formålet med arbeidet er å studere de grunnleggende prinsippene og oppnå grunnleggende ferdigheter i å utarbeide tekniske spesifikasjoner for utvikling av informasjonssystemer og deres programvare.
Arbeidet med å lage et informasjonssystem begynner med dannelsen av kundekrav til systemet som opprettes og deres formalisering i form av tekniske spesifikasjoner (TOR). Den tekniske spesifikasjonen er hoveddokumentet som definerer kravene og prosedyren for å lage et automatisert system, i henhold til hvilket systemet er utviklet og akseptert ved igangkjøring. I tillegg, basert på de tekniske spesifikasjonene, beregnes arbeidet og lønnskostnader spesifiseres.
TK består av tre stadier:
1. begrunnelse for behovet for å utvikle et informasjonssystem - problemstilling, samling utgangsmaterialer, valg og begrunnelse av kriterier for effektiviteten og kvaliteten til det utviklede systemet, begrunnelse av behovet for forskningsarbeid;
2. Forskningsarbeid - fastsettelse av strukturen til input og output data, forhåndsvalg metoder for å løse problemer, rettferdiggjøre muligheten for å bruke det utviklede systemet, bestemme kravene til tekniske midler, rettferdiggjøre den grunnleggende muligheten for å løse problemet;
3. utvikling og godkjenning av tekniske spesifikasjoner - fastsettelse av programkrav, utvikling av en mulighetsstudie av systemet, fastsettelse av stadier, stadier og tidspunkt for systemutvikling og dokumentasjon for det, valg av programmeringsspråk, fastsettelse av behovet for forskning på sene stadier, koordinering og godkjenning av tekniske spesifikasjoner.
TK utfører følgende funksjoner:
Organisasjonsfunksjon - en fast oppgave for Leverandøren og endelige krav fra Kundens side.
Informasjonsfunksjon - rekkefølge i prosessen til Leverandøren og omtanke for ønsker fra Kundens side.
Kommunikasjonsfunksjonen er en gjensidig avtale om "prosjektets emne", unntatt krav.
Juridisk funksjon - TK har like rettskraft med "Avtalen".
Resultatet av det utviklede tekniske prosjektet avhenger i stor grad av fullstendigheten og nøyaktigheten av å utarbeide de tekniske spesifikasjonene.
1. Tekniske spesifikasjoner
1.1 Generell informasjon
Fullt navn på systemet og dets symbol: "Automatisk informasjonssystem for byrået for salg og reservasjon av flybilletter." en kort beskrivelse av Bruksområder
Systemet er beregnet for bruk i kundens organisasjon, i vårt tilfelle - et byrå for salg og reservasjon av flybilletter.
Prosedyren for registrering og presentasjon for kunden av resultatene av arbeidet med å lage systemet (dets deler), om produksjon og justering av individuelle verktøy (maskinvare, programvare, informasjon) og programvare og maskinvare (programvare og metodisk) komplekser av system: AIS "Billett" leveres i form av kjørbare moduler iht. Ved fullføring av hele arbeidsomfanget kjøpes teknisk utstyr av Kunden selvstendig. Resultatene av arbeidet med å lage systemet formaliseres ved å signere en handling om aksept av systemet av kunden i fravær av krav mot utvikleren. Akten er trukket i to eksemplarer. En kopi er hos kunden, den andre er hos utvikleren.
1.2 Årsaker til utvikling
Grunnlaget for utviklingen av tekniske spesifikasjoner er oppgaven for kursarbeidet for emnet «Design av informasjonssystemer».
Navnet på utviklingstemaet er "Utvikling av informasjonssystem for et byrå for salg og reservasjon av flybilletter"
Symbol for utviklingsemnet (emnekode) - "IS APB"
1.3 Hensikt og mål med å lage systemet
Funksjonell hensikt med systemet: AIS "Ticket" er designet for å automatisere arbeidet til et byrå for salg og reservasjon av flybilletter.
Driftsformål med systemet: Systemet skal driftes av ansatte i organisasjonen.
Mål med å lage systemet: Systemet fremskynder prosessen med å bestille flybilletter, og forenkler derved byråets arbeid.
1.4 Systemkrav
1.4.1 Krav til systemet som helhet
Krav til systemets struktur og funksjon
Liste over delsystemer, deres formål og hovedegenskaper, krav til antall hierarkinivåer og graden av sentralisering av systemet
AIS "Billett" inkluderer følgende undersystemer:
Aksept av ordre;
Billettregistrering;
Oppgjør med kunden.
"Order Acceptance"-delsystemet er beregnet for registrering av en flybillettbestilling.
Delsystemet "Oppgjør med kunden" gir kunden et reservasjonsnummer knyttet til passdata (betaling med kort).
Krav til metoder og kommunikasjonsmidler for informasjonsutveksling mellom systemkomponenter:
Informasjonsutveksling skjer via et lokalt nettverk.
Krav til systemdriftsmoduser:
Systemet må støtte multi-user og offline driftsmoduser. Brukere får tilgang til systemet via Internett eller Call Center.
Krav til antall og kvalifikasjoner til systempersonell
Krav til personellkvalifikasjoner, prosedyre for opplæring og kontroll av kunnskap og ferdigheter:
Den ansatte som er involvert i å ta imot søknader må ha kompetanse i å arbeide med personlig datamaskin på brukernivå. Antall ansatte kan variere avhengig av ordrevolumet.
Krav til pålitelighet
Gjenoppretting av systemet i tilfelle feil i driften av maskinvare (unntatt lagringsmedier og programmer) og feil knyttet til programvare (OS og enhetsdrivere), gjenoppretting av funksjonalitet er operativsystemets ansvar.
Hvis det er feil i strømforsyningssystemet til maskinvaren, som fører til en omstart av OS, må programmet gjenopprettes etter omstart av OS og start kjørbar fil systemer.
Driftsevnen til systemet som helhet må også sikres ved feil, ulykker og feil på enkelte arbeidsstasjoner. For å beskytte utstyr mot spenningsstøt og bryterforstyrrelser, nettverksfiltre, og for å la brukeren lagre data i tilfelle strømbrudd, anbefales det å bruke avbruddsfri strømforsyning.
Sikkerhetskrav
Kunden sikrer etterlevelse tekniske løsninger, brukt i modifikasjon og utvikling av delsystemet, gjeldende standarder, sikkerhetsforskrifter, brann- og eksplosjonssikkerhet, miljøvern.
Driftskrav vedlikehold, reparasjon og lagring av systemkomponenter
Driftsforhold, samt typer og hyppighet av vedlikehold tekniske midler delsystemer skal overholde kravene til drift, vedlikehold, reparasjon og lagring som er angitt i dokumentasjonen til produsenten (produsenten) for dem.
Krav til beskyttelse av informasjon omt uautorisert tilgang
For å beskytte informasjon mot uautorisert tilgang, må systemet gi:
a) identifikasjon og autentisering av brukeren;
b) sjekke brukerrettigheter og tilgangsbegrensninger på funksjonsnivå og datamatriser ved arbeid med systemet.
Krav til informasjonssikkerhet ved ulykker
Det er nødvendig å gi muligheten Reserver eksemplar systemdata ved hjelp av programvare levert av utvikleren.
Krav til standardisering og ensretting
En kaskademodell bør brukes for dette systemet Livssyklus AV.
Må brukes i systemet (om nødvendig) all-russiske klassifiserere og enhetlige klassifiseringer og ordbøker for forskjellige typer alfanumerisk og tekstinformasjon.
Systemgrensesnitt, hjelpefiler og evt tekstinformasjon Programmet må være på russisk.
Skjermskjemaer må utformes med hensyn til foreningskravene:
Alle skjermformer for brukergrensesnittet må kjøres i en enkelt grafisk design, med samme utforming av hovedkontrollene og navigasjonen.
1.4.2 Krav til funksjoner (oppgaver) som utføres av systemet
For hvert delsystem, en liste over funksjoner, oppgaver eller deres komponenter (inkludert de som sikrer interaksjon mellom deler av systemet) som støtter automatisering
Informasjonssystemet skal gi følgende funksjoner:
Undersystem for ordreaksept,
Kundeoppgjørsdelsystem.
1.4.3 Krav til typer sikkerheter
Til informasjonsstøtten til systemet
Til sammensetning, struktur og metoder for å organisere data i systemet
Systemdata lagres på én lokal maskin. Systeminngangen er en beskrivelse av bestillingen, utgangen skal være en faktura og et identifikasjonsnummer kunde.
Til strukturen i prosessen med å samle inn, behandle, overføre data i systemet og presentere data.
Data legges inn i systemet manuelt, behandles og leveres til brukeren i ønsket form (elektronisk, trykt).
For å beskytte data mot ødeleggelse under ulykker og strømbrudd i systemet
Komplekset av tekniske midler må inkludere en avbruddsfri strømforsyning. Jobb denne kilden bør være minst en halvtime før systemet slår seg av på riktig måte.
For å kontrollere, lagre, oppdatere og gjenopprette data
Systemet skal støtte automatiske daglige sikkerhetskopier.
Systemprogramvarekrav
Systemet må fungere inn operativsystemer Windows XP/Vista/7/8
Systemmaskinvarekrav
Til typer tekniske midler, inkludert typer komplekser av tekniske midler, programvare- og maskinvarekomplekser og andre komponenter som er akseptable for bruk i systemet.
arbeidsstasjoner;
Uavbrutt strømkilde;
Dataoverføringsmedium mellom arbeidsstasjoner (for eksempel vridd UTP-par 5e);
En skriver.
Tekniske midler kjøpes av kunden uavhengig.
Til funksjonelle, konstruktive og operasjonelle egenskaper hjelp av teknisk støtte til systemet.
prosessor Intel Pentium IV 2 GHz eller høyere, RAM på minst 2 GB, harddiskkapasitet på minst 500 GB.
Krav til kroppensystemstøtte
For organisasjonsstøtte er følgende krav gitt:
Til strukturen og funksjonene til enhetene som er involvert i driften av systemet eller sørger for drift.
Systemets funksjon sikres av en systemingeniør; 4 ansatte er involvert i driften.
Til organisering av funksjonen til systemet og rekkefølgen av samhandling mellom anleggspersonell og personell på automasjonsanlegg.
Organisatorisk støtte må være tilstrekkelig for at personell effektivt kan utføre sine tildelte oppgaver når de utfører funksjonene til systemet.
For å beskytte mot feilaktige handlinger fra systempersonell.
Beskyttelse mot menneskelige feil består i å kontrollere fullføringen av data i enkelte felt, muligheten til å gjenopprette originale data og kansellere nylige endringer, og begrense tilgangen til ansattes funksjoner og krefter.
1.5 Kjennetegn på automasjonsobjekter
Kort informasjon om automatiseringsobjektet eller lenker til dokumenter som inneholder slik informasjon
Automatiseringsobjektet er prosessen knyttet til bestilling av flybilletter.
Informasjon om driftsforholdene til automatiseringsobjektet og miljøegenskaper
Dette systemet skal installeres i produksjons- og kontorlokaler.
1.6 Dokumentasjonskrav
Følgende dokumenter må utstedes for systemet på ulike stadier av opprettelsen:
Organisasjonsstrukturdiagram;
Funksjonell strukturdiagram;
Liste over inngangssignaler og data;
Liste over utgangssignaler (dokumenter);
Forklarende notat til det tekniske prosjektet;
Beskrivelse av automatiserte funksjoner;
Beskrivelse av oppgavebeskrivelsen (oppgavesett);
Beskrivelse av organiseringen av informasjonsbasen;
Beskrivelse av informasjonsarrayet;
Beskrivelse av programvaren;
Brukerhåndboken.
1.7 Stadier og milepæler i utviklingen
1.7.1 Utviklingsstadier
Utviklingen bør utføres i 6 trinn:
1. Utvikling av tekniske spesifikasjoner
2. Utvikling av prosjektdokumentasjon
3. Oppretting av et foreløpig design
4. Detaljdesign
5. Igangkjøring
6. Vedlikehold og modernisering
1.7.2 Utviklingsstadier
På utviklingsstadiet av de tekniske spesifikasjonene må utviklingsstadiet, koordineringen og godkjenningen av denne tekniske spesifikasjonen fullføres.
På stadiet med utvikling av prosjektdokumentasjon, må stadiet med å utvikle prosjektdokumentasjon fullføres.
På stadiet med å lage en foreløpig design, må en foreløpig design fullføres for foreløpig innsending til kunden.
På detaljprosjekteringsstadiet må følgende stadier av arbeidet fullføres:
1) utvikling av et informasjonssystem;
2) utvikling av dokumentasjon.
På implementeringsstadiet skal programmet utarbeides og overføres til kunden.
På vedlikeholds- og moderniseringsstadiet bør det utføres forbedringsarbeid gjeldende versjon informasjon System.
På utviklingsstadiet av tekniske spesifikasjoner må følgende arbeid utføres:
1) redegjørelse for problemet;
2) fastsettelse og klargjøring av krav til tekniske midler;
3) fastsettelse av krav til informasjonssystemet;
4) bestemme stadier, faser og tidspunkt for utviklingen av informasjonssystemet og dokumentasjon for det;
5) begrunnelse og valg av verktøy;
6) koordinering og godkjenning av tekniske spesifikasjoner.
På utviklingsstadiet av prosjektdokumentasjon må følgende arbeid utføres:
1) identifikasjon av hovedforretningsprosesser (i form av IDEF0-diagrammer);
2) identifikasjon av hovedbrukstilfellene for systemet for tre kategorier brukere (Gjest, Autorisert bruker, Administrator) i form av UML-bruksdiagrammer;
3) designe databasestrukturen i form av (ER-diagram);
4) design av hovedkomponentene og algoritmene til systemet i form av tilsvarende UML-diagrammer;
5) utforming av brukergrensesnittstrukturen;
6) koordinering og godkjenning av prosjektdokumentasjon.
På utviklingsstadiet må det jobbes med å utvikle et informasjonssystem basert på designdokumentasjon, koding og feilsøking.
På dokumentasjonsutviklingsstadiet bør utvikling gjennomføres programdokumenter i henhold til krav. "Foreløpig sammensetning programdokumentasjon" av denne tekniske spesifikasjonen.
Ved utarbeidelse og overføring av programmet skal det arbeides med å utarbeide og overføre program- og programdokumentasjon i drift.
På stadiet med å forbedre den nåværende versjonen av systemet, bør det arbeides med å lage nye versjoner av systemet og legge til nye funksjoner i den gamle versjonen.
1. Analyse av IP-krav
2. Samordning av krav med kunden
3. Valg og utvikling av en variant av systemkonseptet
4. Utvikling av tekniske spesifikasjoner og prosjekt
5. Koordinering og godkjenning av tekniske spesifikasjoner og prosjekt
6. Lage en arbeidsplan
7. Forberedelse av maskinvare
8. Programvareutvikling
9. Sjekker for maskinvare- og programvarekompatibilitet
10. Integrasjon og testing av programvare og maskinvare
11. Gjør endringer
12. Utvikling av instruksjoner for drift av IS
13. Utarbeidelse av fullstendig dokumentasjon for IP
14. Levering av IP til kunden
Tabell 1 - Startdata for beregning
|
Jobb nr. |
Liste over verk |
Arbeidets varighet, dager |
||
|
1. Analyse av IP-krav |
||||
|
2. Samordning av krav med kunden |
||||
|
3.Utvalg og utvikling av en variant av systemkonseptet |
||||
|
4.Utvikling av tekniske spesifikasjoner og prosjekt |
||||
|
5. Koordinering og godkjenning av tekniske spesifikasjoner og prosjekt |
||||
|
6. Lage en arbeidsplan |
||||
|
7. Forberedelse av maskinvare |
||||
|
8. Programvareutvikling |
||||
|
9.Sjekker for maskinvare- og programvarekompatibilitet |
||||
|
10.Integrasjon og testing av programvare og maskinvare |
||||
|
11. Gjør endringer |
||||
|
12. Utvikling av instruksjoner for drift av IS |
||||
|
13. Registrering av fullstendig dokumentasjon for IP |
||||
|
14. Levering av IP til kunden |
Figur 1 - Oppgaveerklæring
Figur 2 - Gantt-diagram
Figur 3 - Arbeidsplan for nettverket
Kritisk bane nettverksgrafikk vil være som følger: 0 1 2 3 4 5 6891011121314
Tabell 2 - Tidsparametere for hendelser
|
Hendelsesnummer |
Tidspunkt for arrangementet |
Tidsreserve |
||
Tabell 3 - Beregning av fulle og ledige tidsreserver
|
Varighet, dager |
Tidsparametere for arbeid, dager |
Full reserve |
Gratis reserve |
|||||
|
tidlig start |
Tidlig slutt |
Sen start |
Sen finish |
|||||
1.8 Prosedyre for kontroll og aksept av systemet
1.8.1 Typer, sammensetning, omfang og testmetoder for systemet og dets komponenter
Systemet testes ved å introdusere stor kvantitet data, inntasting av samme informasjon, informasjon om en annen type data, data større rekkevidde. Samsvarskontroll gjennomføres skjermskjemaer beskrivelse i brukermanualen (grensesnitttesting).
1.8.2 Generelle krav til etappevis aksept av arbeid
Levering og aksept utføres av en kommisjon bestående av representanter for Kunden og Leverandøren. Basert på resultatene av aksept, undertegnes en handling fra akseptkomiteen.
Alt skapt innenfor av dette arbeidet programvareprodukter overføres til Kunden, både i form av ferdige moduler og i form av kildekoder levert i elektronisk skjema på standard maskinmedier (CD).
1.8.3 Status for akseptkomiteen (statlig, interdepartemental, avdelingsvis)
Status for akseptkomiteen bestemmes av Kunden før testing.
2. Teknisk design
2.1 Funksjonell struktur
2.1.1 Beskrivelse av fagområdet
Fagområdet er et byrå for salg og reservasjon av flybilletter
Selskapet inkluderer en administrativ avdeling (består av en regnskapsfører og en leder), en driftsavdeling for arbeidsstasjoner (administrasjon av informasjonsteknologi) (systemadministrator og teknikere), og operatører.
Administrativ avdeling, bestående av en regnskapsfører og en leder, har ansvar for kvaliteten på tjenestene.
2.1.2 Funksjoner og organisasjonsstruktur
Å bygge en virksomhetsstruktur kan deles inn i tre trinn: bygge en organisasjonsmodell, bygge en funksjonell modell og bygge en informasjonsmodell.
Billettbyrået består av følgende avdelinger:
Regissør;
Administrativ avdeling;
Arbeidsstasjoner Driftsavdeling;
Operatøravdeling.
Organisasjonsstrukturen til bedriften er vist i figur 4.
Figur 4 - Organisasjonsmodell
Direktøren utfører generell ledelse produksjon, økonomisk og finansiell-økonomisk virksomhet i foretaket, samt organiserer samspillet mellom alle dets strukturelle divisjoner.
Produksjonsavdelingen utfører utviklingen av produktdesignet, dets påfølgende produksjon og montering.
Administrativ avdeling, bestående av en regnskapsfører og en leder, har ansvar for kvaliteten på tjenesteytingen.
Driftsavdelingen for arbeidsstasjonen er ansvarlig for systemytelsen.
Operatører er ansvarlige for å akseptere bestillinger og legge inn data i databasen.
2.1.3 Beskrivelse av datastrømmer og forretningsprosesser
Forretningsprosessmodellering
En forretningsprosess er et sett med sammenhengende aktiviteter eller oppgaver som tar sikte på å lage et spesifikt produkt eller en tjeneste for forbrukere. For klarhetens skyld visualiseres forretningsprosesser ved hjelp av et flytskjema for forretningsprosesser. Forretningsprosessmodellering er aktiviteten for å lage modeller av organisasjoner, inkludert en beskrivelse av forretningsobjekter (divisjoner, posisjoner, ressurser, roller, prosesser, operasjoner, informasjonssystemer, lagringsmedier, etc.) og indikere forbindelsene mellom dem. Kravene til de genererte modellene og deres tilsvarende innhold bestemmes av målene for modelleringen. Forretningsmodellering kalles også en disiplin og en egen delprosess i programvareutviklingsprosessen, som beskriver virksomhetens aktiviteter og bestemmer kravene til systemet – de delprosessene og operasjonene som er gjenstand for automatisering i informasjonssystemet som utvikles.
Etter å ha analysert byråets aktiviteter og gjennomført en forprosjektstudie, kan vi identifisere tre hovedforretningsprosesser for AIS «Billett»:
1. Aksept av bestillingen.
2. Utstedelse av et identifikasjonsnummer.
3. Oppgjør med kunden.
Funksjonell modellering av forretningsprosesser er representert ved IDEF0-metodikken. Den beskriver forretningsprosessene som foregår i automatiseringsobjektet. IDEF0-metodikken er basert på et grafisk språk for å beskrive forretningsprosesser. En modell i IDEF0 er representert ved en samling hierarkisk ordnede og logisk relaterte diagrammer. Hvert diagram er plassert på eget ark. Det er fire typer diagrammer:
Kontekstdiagram A-0 (hver modell kan bare ha ett kontekstdiagram);
Dekomponeringsdiagrammer (inkludert diagrammet over det første nivået av dekomponering A 0, som avslører det kontekstuelle);
Node tre diagrammer;
Kun eksponeringsdiagrammer (FEO).
Kontekstdiagrammet er toppen av trestrukturen til diagrammer og representerer den mest generelle beskrivelsen av systemet og dets interaksjon med det ytre miljøet (som regel er hovedformålet med det modellerte objektet beskrevet her). Etter å ha beskrevet systemet som helhet, er det delt inn i store fragmenter. Denne prosessen kalles funksjonell dekomponering, og diagrammene som beskriver hvert fragment og samspillet mellom fragmentene kalles dekomponeringsdiagrammer. Etter å ha dekomponert kontekstdiagrammet (dvs. oppnådd A 0-diagrammet), dekomponeres hver blokk i A 0-diagrammet i mindre fragmenter, og så videre, inntil ønsket nivå av beskrivelsesdetaljer er oppnådd. Etter hver dekomponeringsøkt gjennomføres undersøkelsesøkter - fageksperter (vanligvis bedriftsansatte intervjuet av analytikere) indikerer korrespondansen mellom ekte forretningsprosesser og de opprettede diagrammene. Eventuelle inkonsekvenser som blir funnet blir korrigert, og først etter bestått eksamen uten noen kommentarer kan neste nedbrytningsøkt begynne. Dette sikrer at modellen matcher reelle forretningsprosesser på alle nivåer av modellen. Syntaksen for å beskrive systemet som en helhet og hvert av dets fragmenter er den samme gjennom hele modellen.
Hovedforretningsfunksjonen til "AIS Ticket" er salg av flybilletter. Inndataene er rekkefølgen på billetter. I helgene - kvittering. Verktøyene for å utføre hovedforretningsfunksjonen er de ansatte i Bilet OJSC (regnskapsfører, leder, IT-teknikere, operatører).
Dataflytdiagram
Krav er representert som et hierarki av prosesser forbundet med datastrømmer. Dataflytdiagrammer viser hvordan hver prosess transformerer sine input til utganger og avslører relasjonene mellom disse prosessene. DFD-diagrammer er vellykket brukt som et tillegg til IDEF0-modellen for å beskrive dokumentflyt og informasjonsbehandling. I likhet med IDEF0, representerer DFD systemet som modelleres som et nettverk relaterte arbeider. Hovedkomponentene i DFD (som nevnt ovenfor) er prosesser eller arbeid, eksterne enheter, datastrømmer, datalagring (lagring). I motsetning til IDEF0-piler, som representerer stive relasjoner, viser DFD-piler hvordan objekter (inkludert data) beveger seg fra en jobb til en annen.
I motsetning til IDEF0, som ser på systemet som relaterte aktiviteter, ser DFD på systemet som en samling av elementer. Et kontekstdiagram inkluderer ofte verk og eksterne lenker. Verk blir vanligvis referert til med navnet på systemet, for eksempel "Informasjonsbehandlingssystem." Å inkludere eksterne referanser i et kontekstdiagram erstatter ikke metodikkens krav om å klart definere formålet, omfanget og felles synspunkt for systemet som modelleres.
I DFD er aktiviteter (prosesser) systemfunksjoner som transformerer input til output. Selv om verkene er avbildet som rektangler med avrundede hjørner, deres betydning sammenfaller med betydningen av verkene IDEF0 og IDEF3. Akkurat som IDEF3-prosesser har de innganger og utganger, men støtter ikke kontroller og mekanismer som IDEF0.
Eksterne enheter representerer systeminnganger og/eller utganger. Eksterne enheter er avbildet som et rektangel med en skygge og er vanligvis plassert i kantene av diagrammet. En enkelt ekstern enhet kan brukes flere ganger på tvers av ett eller flere diagrammer. Denne teknikken brukes vanligvis for å unngå å tegne for lange og forvirrende piler.
Arbeidsflyter er representert med piler og beskriver bevegelsen av objekter fra en del av systemet til en annen. Siden i DFD hver side av verket ikke har en klar hensikt som i IDEF0, kan piler komme inn og ut av hvilken som helst side av arbeidsrektangelet. DFD bruker også toveispiler for å beskrive kommando-svar-samtaler mellom jobber, mellom en jobb og en ekstern enhet, og mellom eksterne enheter.
I motsetning til piler som beskriver objekter i bevegelse, viser datavarehus objekter i ro.
2.2 IC-systemdesign
vilkår beregning arbeidskostnader booking
2.2.1 Utvikling av konsept, arkitektur og implementeringsplattform for IS
Hovedaspektene ved valg av IS-arkitektur er ytelse, pålitelighet, skalerbarhet og sikkerhet.
For øyeblikket er de vanligste arkitekturene:
filserver;
klient server;
flernivåarkitektur.
Filserverarkitektur betyr at serveren kun overtar funksjonen med å lagre data, og behandlingen utføres på klientmaskiner. Dette betyr at data må overføres over nettverket, noe som vil resultere i stor belastning nettverkstrafikk. Og dette vil igjen føre til en nedgang i ytelsen ettersom antall brukere øker. Også når du implementerer en filserverarkitektur, løses problemet med integritet, konsistens og samtidig tilgang til data på en desentralisert måte: dataene lagres på serveren og behandles på klienten. Som et resultat avtar applikasjonens pålitelighet. En annen ulempe er de høye kostnadene ved å oppgradere og vedlikeholde forretningslogikktjenester på hver klientarbeidsstasjon. Imidlertid har denne arkitekturen også en rekke fordeler, for eksempel lave utviklingskostnader, høy hastighet utvikling og ikke høy pris programvareoppdateringer og endringer.
Klient-server-arkitekturen har ikke ulempene til den ovenfor beskrevne arkitekturen, fordi Databaseserveren gir ikke bare tilgang til delte data, men behandler dem også. Klienten sender forespørsler til serveren på et språk "forståelig" for serveren, og den behandler på sin side forespørselen, mens den overvåker integriteten og konsistensen til dataene, og returnerer resultatet av den behandlede forespørselen til klienten. Som et resultat reduseres nettverksbelastningen: klienten trenger ikke lenger å behandle mellomdata. Lagring og prosessering er sentralisert, så denne arkitekturen er mer pålitelig enn filserverarkitekturen. Ulempene med klient-server-arkitekturen inkluderer for det første den tilstrekkelige kompleksiteten til systemutvikling på grunn av behovet for å utføre forretningslogikk og gi et brukergrensesnitt i ett program og høye krav til arbeidsstasjoner av samme grunn.
Det neste trinnet i utviklingen av IS-arkitekturer var en flernivåarkitektur der forretningslogikk blir utført på applikasjonsserveren. Flernivåarkitektur har følgende fordeler:
skalerbarhet;
konfigurerbarhet - isolering av nivåer fra hverandre lar deg raskt og enkelt rekonfigurere systemet når feil oppstår eller når planlagt vedlikehold på et av nivåene;
høy sikkerhet;
høy pålitelighet;
lave krav til kanal (nettverk) hastighet mellom terminaler og applikasjonsserver;
lave krav til ytelse og tekniske egenskaper til terminaler, noe som resulterer i en reduksjon i kostnadene deres.
Til tross for de ubestridelige fordelene, dette systemet ble ikke mye brukt av følgende grunner:
vanskeligheten med å utvikle systemer basert på flernivåarkitektur, fordi det er veldig vanskelig å "bli med" forskjellige moduler, spesielt hvis de er skrevet av forskjellige grupper. Og en endring i en modul forårsaker som regel skredlignende endringer i resten, og fra dette synspunktet, til og med enkelt system basert på en flerlagsarkitektur vil være 2 ganger vanskeligere å implementere;
høye krav til ytelsen til applikasjonsservere og databaseservere, og derfor de høye kostnadene for serverutstyr;
høye krav til kanal (nettverk) hastighet mellom databaseserveren og applikasjonsservere;
høy kompleksitet i administrasjonen.
Etter å ha vurdert alle fordelene og ulempene ved hver arkitektur, velger vi klient-server-arkitekturen for å implementere AIS Ticket-systemet. Denne arkitekturen tillater optimal fordeling av arbeidet mellom klient- og serverdelen av systemet: applikasjonen som kjører på arbeidsstasjonen leser ikke databaseposter "direkte", men sender forespørsler til serveren, hvor de behandles sekvensielt, og behandlingsresultatene sendes til arbeidsstasjon. Og dette reduserer betraktelig informasjonsflyter i LAN.
Ordningen for funksjon og konstruksjon av informasjonssystemet er presentert i figur 5.
Figur 5 - Klient-server-arkitektur
2.2.2 Informasjonssystemets struktur, sammensetning av funksjonelle og støttende delsystemer
Funksjonelle delsystemer - komplekse økonomiske oppgaver med høy grad av informasjonsutveksling (forbindelser) mellom oppgaver (en viss informasjonsbehandlingsprosess med et klart definert sett av input og output informasjon. Funksjonelle delsystemer gir informasjonstjenester visse typer aktiviteter økonomisk system(bedrift), karakteristisk for dens strukturelle divisjoner og (eller) ledelsesfunksjoner. Integrering av funksjonelle delsystemer i et enkelt system oppnås gjennom opprettelse og drift av støttende delsystemer, for eksempel:
Informasjonsinformasjon;
Teknisk;
Programvare;
Matematisk;
Språklig.
Støttedelsystemer er felles for hele IS, uavhengig av de spesifikke funksjonelle undersystemene der visse typer støtte brukes. I arbeidet er støttende og organisatoriske delsystemer kombinert til ett støttende delsystem. Begrunnelsen for en slik beslutning kan anses som at deres komponenter sikrer implementeringen av målene og funksjonene til systemet.
Sammensetningen av de støttende delsystemene avhenger ikke av det valgte fagområdet og har:
Funksjonell struktur;
Informasjonsstøtte;
Matematisk (algoritmisk og programvare) programvare;
Teknisk støtte;
Organisasjonsstøtte,
og på stadiet av IS-utviklingen ytterligere støtte:
Lovlig;
Språklig;
teknologisk;
Metodisk;
Grensesnitt med eksterne ICer.
Informasjonsstøtte er et sett med midler og metoder for å konstruere en informasjonsbase. Den definerer metodene og formene for å vise tilstanden til et kontrollobjekt i form av data inne i IS, dokumenter, grafer og signaler utenfor IS.
Matematisk programvare består av algoritme og programvare.
Organisasjonsstøtte er et sett med midler og metoder for å organisere produksjon og administrere dem under betingelsene for å introdusere IP.
Formålet med organisasjonsstøtte er: valg og innstilling av styringsoppgaver, analyse av styringssystemet og måter å forbedre det på, utvikling av løsninger for organisering av samspillet mellom informasjonssystemer og personell, implementering av styringsoppgaver. Organisasjonsstøtte inkluderer metoder for å kommunisere med kunder, krav til papirarbeid, stillingsbeskrivelser, etc.
Algoritmisk programvare er et sett med matematiske metoder, modeller og algoritmer som brukes i systemet for å løse problemer og behandle informasjon.
2.2.3 IS teknisk støtte
Komplekset av tekniske midler bør inneholde følgende elementer:
arbeidsstasjoner;
Avbruddsfri strømforsyning;
Verktøy for å bygge et LAN;
DB server;
En skriver.
Serverkrav:
Minne 8 GB;
Prosessor 2,2 GHz Intel Xeon 5500 minimum;
Hastighet SATA-stasjon 8 Gbps;
Nettverksadapter 10 Gbps;
Operasjonssal Windows-system Server 2008.
Krav til arbeidsstasjon:
Prosessor 2 GHz;
Minne 2 GB;
Harddisk ikke mindre enn 500;
Operativsystem Windows 7;
Nettverksadapter 100 Mbit/s.
De tekniske midlene til IS er beskrevet under hensyntagen til kravene til funksjonen tilt. Tekniske midler må gi:
Døgnet rundt drift av et kompleks av tekniske midler og utstyr;
Garantert utførelse av hele programvarepakken i tilfelle feil eller feil på en del av utstyret;
Databeskyttelse mot uautorisert tilgang;
Servere og arbeidsstasjoner må være koblet til et lokalt nettverk.
Figur 2.3 viser topologien til det lokale datanettverket (LAN) for JSC "Bilet".
Den aktuelle figuren viser at gjennom overgangen til databaseserveren og filserver 5 arbeidsstasjoner er tilkoblet. Nettverkstopologien er stjerne.
Figur 6 - Logisk krets nettverk av JSC "Customer"
2.3 IS informasjonsstøtte
2.3.1 Beskrivelse av den logiske strukturen til informasjonsbasen
Logisk (datalogisk) design - lage et databaseskjema basert på en spesifikk datamodell, f.eks. relasjonsmodell data. For en relasjonsdatamodell er en datalogisk modell et sett med relasjonsdiagrammer, vanligvis indikerer primærnøkler, samt "koblinger" mellom relasjoner, som er fremmednøkler.
Transformasjonen av en konseptuell modell til en logisk modell utføres vanligvis etter formelle regler. Dette stadiet kan i stor grad automatiseres.
Normal form er en egenskap til en relasjon i en relasjonsdatamodell, som karakteriserer den fra et redundanssynspunkt, noe som potensielt kan føre til logisk feilaktige resultater av sampling eller endring av data. Normalform er definert som et sett med krav som en relasjon skal tilfredsstille. Prosessen med å konvertere databaserelasjoner (DB) til et skjema som møter normale former kalles normalisering. Normalisering er ment å bringe databasestrukturen til en form som gir minimal logisk redundans, og er ikke ment å redusere eller øke arbeidsproduktiviteten eller redusere eller øke det fysiske volumet til databasen. Det endelige målet med normalisering er å redusere potensialet for inkonsekvens i informasjonen som er lagret i en database. Generelt formål Normaliseringsprosessen er som følger:
Eliminering av visse typer redundans;
Rettet noen oppdateringsavvik;
Å utvikle et databasedesign som er en god nok representasjon av den virkelige verden er intuitivt og kan tjene som et godt grunnlag for senere utvidelse;
Forenkle prosedyren for å bruke nødvendige integritetsbegrensninger.
Eliminering av redundans utføres som regel ved å dekomponere relasjoner på en slik måte at kun primærfakta lagres i hver relasjon (det vil si fakta som ikke er utledet fra andre lagrede fakta).
På det logiske nivået utføres databasenormalisering, samt nøkkelallokering for hver enhet. Logiske forbindelser implementeres gjennom primær- og fremmednøkler.
2.3.2 Beskrivelse av den fysiske implementeringen av databasen
Fysisk design - lage et databaseskjema for et spesifikt DBMS. Spesifikasjonene til en bestemt DBMS kan omfatte begrensninger på navngivning av databaseobjekter, begrensninger på støttede datatyper, etc. I tillegg inkluderer spesifikasjonene til et bestemt DBMS under fysisk design valg av løsninger relatert til fysisk miljø datalagring (velge diskminnebehandlingsmetoder, dele opp databasen i filer og enheter, datatilgangsmetoder), lage indekser, etc.
Den fysiske datamodellen er bygget på grunnlag av en logisk modell og beskriver dataene ved hjelp av en bestemt DBMS. Relasjoner utviklet på scenen logisk modellering, konverteres til tabeller, attributter til kolonner, domener til datatyper akseptert i den valgte spesifikke DBMS.
De. V fysisk modell Det er en en-til-en samsvar mellom parametrene til et objekt og en modell av samme fysiske natur. I dette tilfellet tildeles systemets element fysiske ekvivalenter som gjengir strukturen, grunnleggende egenskaper og relasjoner til objektet som studeres. På fysisk modellering, som er grunnlaget for likhetsteorien, blir funksjonene ved å utføre et eksperiment i naturen bevart samtidig som det optimale spekteret av endringer i de tilsvarende fysiske parametrene opprettholdes.
Konklusjon
Som et resultat av kursarbeidet ble det gjennomført en teknisk oppgave for utvikling av et informasjonssystem for et byrå for salg og reservasjon av flybilletter og dets programvare.
Referansevilkårene for et informasjonssystem er hoveddokumentet som definerer kravene og prosedyren for å lage et informasjonssystem, i samsvar med hvilke det er utviklet og akseptert ved igangkjøring. Den inneholder de grunnleggende kravene til funksjonelle egenskaper, pålitelighet, driftsforhold og informasjonsbeskyttelse av informasjonssystemet, og beskriver også prosedyren for utvikling av systemet.
I samsvar med målene for de tekniske spesifikasjonene ble følgende stadier av å lage et teknisk prosjekt fullført:
- analyse av fagområdet ble utført;
- et funksjonsdiagram av AIS "Billett" ble utviklet;
- et konsept er utviklet, arkitekturen og implementeringsplattformen til systemet er valgt;
1. designet konseptuell modell AIS "Billett";
2. en logisk modell av AIS "Ticket"-systemet ble designet basert på den konseptuelle modellen;
3. Den fysiske strukturen til databaseserveren bestemmes.
Bibliografi
1. GOST 19.201-78 ett system programvaredokumentasjon. Teknisk oppgave. Krav til innhold og design
2. GOST 34.602-89 Informasjonsteknologi. Sett med standarder for automatiserte systemer. Referansevilkår for opprettelse av et automatisert system
3. RD 50-34.698-90 Automatiserte systemer. Krav til innhold i dokumenter
4. V.P. Romanov, N.Z. Emelyanova, T.L. Partyka Design av økonomiske informasjonssystemer. Metoder og moderne teknologier. - M: Eksamen, 2005.- 256 s.;
5. Maklakov S.V. BPWin og ERWin CASE - verktøy for utvikling av informasjonssystemer / Maklakov S.V. - M: DIALOG MEPhI, 2001.-256 s.;
6. Boyko V.V. Design av informasjonssystemdatabaser / Boyko V.V., Savinkov V.M. - 2. utg. - M.: Finans og statistikk, 1989. - 350 s.
Skrevet på Allbest.ru
...Lignende dokumenter
Mandat for utvikling av et automatisert system og lagerregnskap forvaltning av en universell handelsbase. Designe et informasjonssystem og velge et miljø for opprettelse programvareprodukt. Oppretting av grensesnitt og brukermanual.
avhandling, lagt til 07.11.2015
Forskrifter Den russiske føderasjonen i området informasjonssikkerhet. Prosedyren for organisering av arbeid for å beskytte informasjon i informasjonssystemer. En generell tilnærming til utvikling av tekniske spesifikasjoner for utvikling av et beskyttelsessystem på dette området.
kursarbeid, lagt til 05.05.2015
Oppretting av tekniske spesifikasjoner for utvikling av et informasjonssystem for bestilling av flybillett. Dokumentasjonskrav. Prosedyre for kontroll og aksept av systemet. Utvikling av konsept, arkitektur og implementeringsplattform for informasjonssystemet.
kursarbeid, lagt til 13.05.2015
Opprettelse av informasjonssystemet "Gull", som automatiserer arbeidet til Smykkeverkstedet. Forretningsprosessmodellering ved hjelp av IDEF0 og UML diagrammer og DFD og sicuence datastrømmer. Utarbeide et teknisk prosjekt og spesifikasjoner basert på GOST 34.602-89.
kursarbeid, lagt til 02.10.2013
Sammensetning av ekspertsystemet. Krav til et sett med tekniske midler. Struktur og organisering av teknisk støtte for et automatisk informasjonssystem. Teknisk dokumentasjon for utvikling av programvareverktøy og metoder for deres bruk.
sammendrag, lagt til 10.09.2014
Språklæring PHP programmering, SQL, C++, HTML. Gjennomgang av lansering og bruksregler lokal server Denwer. Utarbeide tekniske spesifikasjoner for utvikling av et programvareprodukt. Beskrivelse av mobil- og nettapplikasjonen som opprettes.
kursarbeid, lagt til 04.07.2015
Utvikling av et automatisert informasjonssystem for regnskap og kontroll av reparasjonsarbeid, og levering av programvareutviklingstjenester til selskapet "MegionSoftOil", utvikling av applikasjonsalgoritmer programvaresystem og moduler.
avhandling, lagt til 29.06.2012
Begrunnelse for behovet for å utvikle et informasjonssystem. Domeneanalyse. Referansevilkår for opprettelse av en EIS. Juridisk status og korte økonomiske kjennetegn ved bedriften. Status for regnskaps- og analysearbeid i bedriften.
sammendrag, lagt til 01.09.2009
Utvikling og implementering av et automatisert informasjonssystem (AIS) for arbeid med kunder til et reiseselskap (mottak og behandling av søknader). Teknisk og økonomisk vurdering av et reisebyrå, algoritme og grensesnittdiagram for AIS-programvaren.
avhandling, lagt til 21.07.2011
Å telle antall funksjonspunkter. Beregning av lønnskostnader for utvikling programvareverktøy og estimert tidspunkt for utviklingen, livssyklusmodell. Utvikling av tekniske spesifikasjoner for å lage et automatisert system, krav til det.