Saada oma head tööd teadmistebaasi on lihtne. Kasutage allolevat vormi
Üliõpilased, magistrandid, noored teadlased, kes kasutavad teadmistebaasi oma õpingutes ja töös, on teile väga tänulikud.
Majutatud aadressil http://www.allbest.ru/
- Sissejuhatus
- 1. Lähteülesanne
- 1.1 Üldine teave
- 1.2 Arengu alus
- 1.3 Süsteemi loomise eesmärk ja eesmärgid
- 1.4 Süsteeminõuded
- 1.4.1 Nõuded süsteemile tervikuna
- 1.4.2 Nõuded süsteemi poolt täidetavatele funktsioonidele (ülesannetele).
- 1.4.3 Nõuded tagatise liikidele
- 1.5 Automaatikaobjektide omadused
- 1.6 Nõuded dokumentidele
- 1.7 Etapid ja arenguetapid
- 1.7.1 Arendusetapid
- 1.7.2 Arenguetapid
- 1.7.3 Töö sisu etappide kaupa
- 1.8 Süsteemi kontrolli ja vastuvõtmise protseduur
- 1.8.1 Süsteemi ja selle komponentide tüübid, koostis, ulatus ja katsemeetodid
- 1.8.2 Üldnõuded tööde vastuvõtmisele etappide kaupa
- 1.8.3 Vastuvõtukomisjoni staatus (riiklik, osakondadevaheline, osakond)
- 2. Tehniline projekt
- 2.1 Funktsionaalne struktuur
- 2.1.1 Ainevaldkonna kirjeldus
- 2.1.2 Funktsioonid ja organisatsiooniline struktuur
- 2.1.3 Andmevoogude ja äriprotsesside kirjeldus
- 2.2 IC-süsteemi disain
- 2.2.1 ISi juurutamise kontseptsiooni, ehitusarhitektuuri ja platvormi väljatöötamine
- 2.2.2 Infosüsteemi struktuur, funktsionaalsete ja toetavate allsüsteemide koosseis
- 2.2.3 IS tehniline tugi
- 2.3 IP teabetugi
- 2.3.1 Infobaasi loogilise struktuuri kirjeldus
- 2.3.2 Andmebaasi füüsilise teostuse kirjeldus
- Järeldus
- Bibliograafia
Sissejuhatus
Kursusetöös käsitletakse lähteülesande loomist lennupiletite müügi ja broneerimise agentuuri süsteemi infosüsteemi arendamiseks. Töö eesmärk on tutvuda infosüsteemide ja nende tarkvara arendamise tehniliste spetsifikatsioonide koostamise aluspõhimõtetega ja omandada algoskused.
Töö infosüsteemi loomisel algab loodavale süsteemile kliendinõuete kujundamisest ja nende täitmisest tehnilise ülesande (TOR) vormis. TOR on peamine dokument, mis määratleb automatiseeritud süsteemi loomise nõuded ja korra, mille kohaselt süsteem töötatakse välja ja võetakse kasutusele. Lisaks toimub TOR-i alusel tööde arvestus, tööjõukulu täpsustamine.
TK koosneb kolmest etapist:
1. infosüsteemi arendamise vajaduse põhjendamine - probleemi püstitamine, allikmaterjalide kogumine, väljatöötatava süsteemi tulemuslikkuse ja kvaliteedi kriteeriumide valik ja põhjendamine, uurimisvajaduse põhjendamine;
2. Teadus- ja arendustegevus - sisend- ja väljundandmete struktuuri määramine, probleemide lahendamise meetodite eelvalik, väljatöötatud süsteemi kasutamise otstarbekuse põhjendamine, tehnilistele vahenditele nõuete määramine, probleemi lahendamise põhimõttelise võimaluse põhjendamine. ;
3. TOR väljatöötamine ja kinnitamine - programmidele nõuete määramine, süsteemi teostatavusuuringu väljatöötamine, süsteemi arendamise etappide, etappide ja tähtaegade ning selle dokumentatsiooni määramine, programmeerimiskeelte valik, vajaduse väljaselgitamine teadus- ja arendustegevuse viimastes etappides, traditsiooniliste omavahendite kooskõlastamine ja heakskiitmine.
TK täidab järgmisi funktsioone:
Organisatsioonifunktsioon – fikseeritud ülesanne Töövõtjale ja lõplikud nõuded Tellijalt.
Teabefunktsioon - tellimus Töövõtja protsessis ja Tellija soovide läbimõeldus.
Suhtlusfunktsioon – vastastikune kokkulepe "projekti teema" kohta, välja arvatud pretensioonid.
Juriidiline funktsioon – TK-l on võrdne juriidiline jõud "Lepinguga".
Väljatöötatava tehnilise projekti tulemus sõltub suuresti tehniliste kirjelduste koostamise terviklikkusest ja täpsusest.
1. Lähteülesanne
1.1 Üldine teave
Süsteemi täisnimi ja selle tähis: "Agentuuri automatiseeritud infosüsteem lennupiletite müügiks ja broneerimiseks". Reguleerimisala lühikirjeldus
Süsteem on mõeldud kasutamiseks kliendi organisatsioonis, meie puhul - lennupiletite müügi ja broneerimise agentuuris.
Süsteemi (selle osade), üksikute tööriistade (riistvara, tarkvara, teave) ning tarkvara ja riistvara (tarkvara ja metoodilised) süsteemide valmistamise ja kohandamise töö tulemuste registreerimise ja kliendile esitamise järjekord Süsteemi osa: AIS "Pilet" tarnitakse täidetavate moodulitena vastavalt kogu töömahu täitmisele, tehnilised vahendid ostab Klient iseseisvalt. Süsteemi loomise töö tulemuste registreerimine toimub Kliendi poolt süsteemi vastuvõtmise akti allkirjastamisega, kui Arendaja vastu ei ole pretensioone. Akt on koostatud kahes eksemplaris. Üks eksemplar on Kliendil, teine Arendajal.
1.2 Arengu alus
Lähteülesande väljatöötamise aluseks on kursuse "Infosüsteemide projekteerimine" kursusetöö ülesanne.
Arendusteema nimi on "Lennupiletite müügi ja broneerimise agentuuri infosüsteemi arendamine"
Arendusteema sümbol (teema kood) - "IS APB"
1.3 Süsteemi loomise eesmärk ja eesmärgid
Süsteemi funktsionaalne eesmärk: AIS "Ticket" on mõeldud lennupiletite müügi ja broneerimise agentuuri töö automatiseerimiseks.
Süsteemi tööeesmärk: Süsteemi peavad opereerima organisatsiooni töötajad.
Süsteemi eesmärgid: Süsteem kiirendab lennupiletite tellimise protsessi, lihtsustades seeläbi agentuuri tööd.
1.4 Süsteeminõuded
1.4.1 Nõuded süsteemile tervikuna
Nõuded süsteemi ülesehitusele ja toimimisele
Alamsüsteemide loetelu, nende eesmärk ja põhiomadused, nõuded hierarhia tasandite arvule ja süsteemi tsentraliseerituse astmele
AIS "pilet" sisaldab järgmisi alamsüsteeme:
Tellimuse vastuvõtmine;
Pileti väljastamine;
Raamatupidamine koos kliendiga.
Alamsüsteem "Tellimuse vastuvõtmine" on mõeldud lennupiletite tellimuse registreerimiseks.
Alamsüsteem "Kliendiga arveldamine" annab kliendile passiandmetega seotud broneeringu numbri (kaardiga maksmine).
Nõuded süsteemikomponentide vahelise teabevahetuse meetoditele ja sidevahenditele:
Teabevahetus toimub kohaliku võrgu kaudu.
Nõuded süsteemi töörežiimidele:
Süsteem peab toetama mitme kasutaja ja võrguühenduseta režiime. Kasutajad pääsevad süsteemile Interneti või kõnekeskuse kaudu.
Nõuded süsteemipersonali arvule ja kvalifikatsioonile
Nõuded personali kvalifikatsioonile, nende väljaõppe ning teadmiste ja oskuste kontrollile:
Administraatoril peavad olema kasutajatasemel arvutioskused. Töötajate arv võib olenevalt tellimuste mahust erineda.
Usaldusväärsuse nõuded
Süsteemi taastamine riistvara töövigade (v.a andmekandjad ja programmid) ja tarkvaraga (OS ja seadme draiverid) seotud vigade korral on taastamine OS-i kohustus.
Riistvara toitesüsteemi rikete korral, mis viivad OS-i taaskäivitamiseni, tuleks programm pärast OS-i taaskäivitamist ja süsteemi täitmisfaili käivitamist taastada.
Samuti peaks olema tagatud süsteemi kui terviku toimivus rikete, õnnetuste ja rikete korral üksikutes töökohtades. Seadmete kaitsmiseks pingetõusu ja lülitushäirete eest tuleks kasutada võrgufiltreid ning selleks, et voolukatkestuse korral oleks võimalik kasutajal andmeid salvestada, on soovitatav kasutada katkematuid toiteallikaid.
Turvanõuded
Tellija tagab, et allsüsteemi muutmisel ja arendamisel kasutatavad tehnilised lahendused vastavad kehtivatele standarditele, ohutuseeskirjadele, tuleohutuse ja plahvatusohutuse ning keskkonnakaitse nõuetele.
Nõuded süsteemi komponentide käitamisele, hooldusele, remondile ja ladustamisele
Allsüsteemi tehniliste vahendite töötingimused, samuti hoolduse liigid ja sagedus peavad vastama nende kohta tootja (tootja) dokumentatsioonis sätestatud käitamise, hoolduse, remondi ja ladustamise nõuetele.
Teabe kaitsmise nõudedt volitamata juurdepääs
Teabe kaitsmiseks volitamata juurdepääsu eest peab süsteem esitama:
a) kasutaja tuvastamine ja autentimine;
b) kasutaja juurdepääsuõiguste ja piirangute kontrollimine funktsioonide ja andmemassiivide tasemel süsteemiga töötamisel.
Nõuded teabe ohutusele õnnetusjuhtumite korral
On vaja ette näha võimalus süsteemiandmete varundamiseks arendaja tarnitava tarkvara abil.
Standardiseerimise ja ühtlustamise nõuded
Selle süsteemi jaoks tuleks rakendada tarkvara elutsükli kaskaadmudelit.
Süsteem peaks kasutama (vajadusel) ülevenemaalisi klassifikaatoreid ning ühtseid klassifikaatoreid ja sõnaraamatuid erinevat tüüpi tähtnumbrilise ja tekstilise teabe jaoks.
Süsteemi liides, abifailid ja kogu programmi tekstiline teave peavad olema vene keeles.
Ekraanivormid tuleks kujundada, võttes arvesse ühtlustamise nõudeid:
Kõik kasutajaliidese ekraanivormid peaksid olema tehtud ühtse graafilise kujundusega, põhiliste juhtnuppude ja navigeerimisega sama paigutusega.
1.4.2 Nõuded süsteemi poolt täidetavatele funktsioonidele (ülesannetele).
Iga alamsüsteemi jaoks automatiseerimist toetavate funktsioonide, ülesannete või nende komponentide loend (sh need, mis tagavad süsteemi osade koostoime)
Infosüsteem peaks pakkuma järgmisi funktsioone:
Tellimuste vastuvõtmise allsüsteem,
Kliendiga arveldamise allsüsteem.
1.4.3 Nõuded tagatise liikidele
Süsteemi teabetoele
Andmete süsteemi koostise, struktuuri ja korrastamise viiside juurde
Süsteemiandmed salvestatakse ühte kohalikku masinasse. Tellimuse kirjeldus saadetakse süsteemi sisendisse, väljundiks peab olema arve ja kliendi identifitseerimisnumber.
Andmete kogumise, töötlemise, süsteemis edastamise ja esitamise protsessi struktuuri juurde.
Andmed sisestatakse süsteemi käsitsi, töödeldakse ja väljastatakse kasutajale nõutud kujul (elektrooniliselt, trükituna).
Andmete kaitsmiseks õnnetuste ja süsteemi elektrikatkeste ajal hävimise eest
Tehniliste vahendite kompleks peaks sisaldama katkematut toiteallikat. Selle allika töö peaks süsteemi õigeks väljalülitamiseks olema vähemalt pool tundi.
Andmete haldamiseks, salvestamiseks, värskendamiseks ja taastamiseks
Süsteem peab toetama automaatset igapäevast varundust.
Süsteemi tarkvara nõuded
Süsteem peab töötama operatsioonisüsteemides Windows XP/Vista/7/8
Süsteemi riistvara nõuded
Tehniliste vahendite tüüpidele, sealhulgas tehniliste vahendite komplekside, tarkvara- ja riistvarakomplekside ning muude süsteemis kasutamiseks vastuvõetavate komponentide tüübile.
Tööjaamad;
Katkematu toiteallikas;
Andmeedastuskandja tööjaamade vahel (näiteks keerdpaar UTP 5e);
Printer.
Tehnilised vahendid ostab Klient iseseisvalt.
Süsteemi tehnilise toe vahendite funktsionaalsetele, konstruktiivsetele ja tööomadustele.
Protsessor Intel Pentium IV 2 GHz või kõrgem, RAM vähemalt 2 GB, kõvakettaruumi vähemalt 500 GB.
keha nõudedsüsteemi isolatsioon
Organisatsioonilise toe jaoks esitatakse järgmised nõuded:
Süsteemi toimimisega seotud või toimimist tagavate üksuste struktuurile ja funktsioonidele.
Süsteemi toimimise tagab süsteemiinsener, töösse on kaasatud 4 töötajat.
Süsteemi toimimise korraldusele ning TEJ personali ja automaatikaobjekti personali suhtluskorrale.
Organisatsiooniline tugi peaks olema piisav, et töötajad saaksid tõhusalt täita neile süsteemi funktsioonide elluviimisel pandud ülesandeid.
Kaitseks süsteemipersonali ekslike toimingute eest.
Kaitse personalivigade eest seisneb mõne välja andmete täitmise kontrollimises, algandmete taastamise ja hiljutiste muudatuste tühistamises, ligipääsu piiritlemises töötajate funktsioonide ja volituste järgi.
1.5 Automaatikaobjektide omadused
Lühike teave automatiseerimisobjekti kohta või lingid sellist teavet sisaldavatele dokumentidele
Automatiseerimisobjekt on lennupiletite tellimisega seotud protsess.
Teave automaatikaobjekti töötingimuste ja keskkonnaomaduste kohta
See süsteem paigaldatakse tööstus- ja kontoriruumidesse.
1.6 Nõuded dokumentidele
Süsteemi loomise erinevates etappides tuleks väljastada järgmised dokumendid:
Organisatsiooni struktuuri skeem;
Funktsionaalse struktuuri skeem;
Sisendsignaalide ja andmete loend;
Väljundsignaalide loend (dokumendid);
Tehnilise projekti seletuskiri;
Automatiseeritud funktsioonide kirjeldus;
Ülesande seadistuse kirjeldus (ülesannete kogum);
Infobaasi organisatsiooni kirjeldus;
Teabemassiivi kirjeldus;
Tarkvara kirjeldus;
Kasutusjuhend.
1.7 Etapid ja arenguetapid
1.7.1 Arendusetapid
Arendus peaks toimuma 6 etapis:
1. Lähteülesande väljatöötamine
2. Projekti dokumentatsiooni väljatöötamine
3. Eskiisprojekti koostamine
4. Detailprojekt
5. Kasutuselevõtt
6. Hooldus ja moderniseerimine
1.7.2 Arenguetapid
Lähteülesande väljatöötamise etapis tuleb läbida käesoleva lähteülesande väljatöötamise, kooskõlastamise ja kinnitamise etapp.
Projekti dokumentatsiooni väljatöötamise staadiumis peaks olema lõpetatud projektdokumentatsiooni väljatöötamise etapp.
Eskiisprojekti koostamise etapis tuleb tellijale eelesitamiseks koostada eskiisprojekt.
Detailprojekti etapis tuleks läbi viia järgmised tööetapid:
1) infosüsteemi arendamine;
2) dokumentatsiooni väljatöötamine.
Rakendusetapis tuleb lõpule viia programmi ettevalmistamine ja kliendile üleandmine.
Hoolduse ja kaasajastamise etapis tuleks teha tööd infosüsteemi praeguse versiooni täiustamiseks.
Lähteülesande väljatöötamise etapis tuleks teha järgmised tööd:
1) probleemi avaldus;
2) tehnilistele vahenditele esitatavate nõuete määratlemine ja täpsustamine;
3) infosüsteemile esitatavate nõuete määramine;
4) infosüsteemi ja selle dokumentatsiooni arendamise etappide, etappide ja tähtaegade määramine;
5) põhjendus ja vahendite valik;
6) lähteülesande kooskõlastamine ja kinnitamine.
Projekti dokumentatsiooni väljatöötamise etapis tuleks teha järgmised tööd:
1) peamiste äriprotsesside määratlemine (IDEF0 diagrammide kujul);
2) Süsteemi peamiste kasutusjuhtude määramine kolmele kasutajakategooriale (Külaline, Volitatud kasutaja, Administraator) kasutusjuhtude UML-skeemide kujul;
3) andmekogu struktuuri kujundamine kujul (ER diagramm);
4) Süsteemi põhikomponentide ja algoritmide kujundamine vastavate UML diagrammide kujul;
5) kasutajaliidese struktuuri kujundamine;
6) projekti dokumentatsiooni kooskõlastamine ja kinnitamine.
Arendusjärgus tuleks tegeleda projektidokumentatsioonil, kodeerimisel ja silumisel põhineva infosüsteemi väljatöötamisega.
Dokumentatsiooni väljatöötamise etapis tuleks läbi viia poliitikadokumentide väljatöötamine vastavalt nõuetele. Käesoleva lähteülesande "Programmi dokumentatsiooni esialgne koosseis".
Programmi koostamise ja üleandmise etapis tuleb teha tööd programmi ja programmi dokumentatsiooni ettevalmistamise ja kasutuselevõtuga.
Süsteemi praeguse versiooni täiustamise etapis tuleks teha tööd süsteemi uute versioonide loomiseks ja uute funktsioonide lisamiseks vanale versioonile.
1. IP nõuete analüüs
2. Nõuete kooskõlastamine tellijaga
3. Süsteemikontseptsiooni variandi valik ja väljatöötamine
4. Lähteülesande ja projekti väljatöötamine
5. Lähteülesande ja projekti kooskõlastamine ja kinnitamine
6. Töö plaani koostamine
7. Riistvara ettevalmistamine
8. Tarkvaraarendus
9. Kontrollige riist- ja tarkvara ühilduvust
10. Tarkvara ja riistvara integreerimine ja testimine
11. Muudatuste tegemine
12. IS-i kasutusjuhendi väljatöötamine
13. IP täieliku dokumentatsiooni registreerimine
14. IP kohaletoimetamine kliendile
Tabel 1 – Arvutamise algandmed
|
Töö nr. |
Tööde nimekiri |
Töö kestus, päevad |
||
|
1. IP nõuete analüüs |
||||
|
2. Nõuete kooskõlastamine tellijaga |
||||
|
3. Süsteemikontseptsiooni variandi valik ja väljatöötamine |
||||
|
4.Lähteülesande ja projekti väljatöötamine |
||||
|
5. Lähteülesande ja projekti kooskõlastamine ja kinnitamine |
||||
|
6. Töö plaani koostamine |
||||
|
7.Riistvara ettevalmistamine |
||||
|
8. Tarkvaraarendus |
||||
|
9. Riistvara ja tarkvara ühilduvuse kontroll |
||||
|
10. Tarkvara ja riistvara integreerimine ja testimine |
||||
|
11. Muudatuste tegemine |
||||
|
12.IS-i kasutusjuhendi väljatöötamine |
||||
|
13. IP täieliku dokumentatsiooni registreerimine |
||||
|
14. IP kohaletoimetamine kliendile |
Joonis 1 – Eesmärkide seadmine
Joonis 2 – Gantti diagramm
Joonis 3 - Tööde teostamise võrgugraafik
Võrgu kriitiline tee on: 0 1 2 3 4 5 6891011121314
Tabel 2 – sündmuste ajaparameetrid
|
Sündmuse number |
Sündmuse ajastus |
Reserveeri aeg |
||
Tabel 3 – Täis- ja vaba aja reservi arvestamine
|
Kestus, päevad |
Töö aja parameetrid, päevad |
Täielik reserv |
Tasuta reserv |
|||||
|
varajane algus |
varajane lõpp |
hiline algus |
hiline lõpp |
|||||
1.8 Süsteemi kontrolli ja vastuvõtmise protseduur
1.8.1 Süsteemi ja selle komponentide tüübid, koostis, ulatus ja katsemeetodid
Süsteemi testitakse suure andmemahu sisestamisega, sama info sisestamisega, erinevat tüüpi andmete info, suurema ulatusega andmed. Kontrollitakse ekraanivormide vastavust kasutusjuhendis toodud kirjeldusele (liidese testimine).
1.8.2 Üldnõuded tööde vastuvõtmisele etappide kaupa
Tarnimise ja vastuvõtmise viib läbi komisjon, kuhu kuuluvad Tellija ja Töövõtja esindajad. Vastuvõtmise tulemuste alusel allkirjastatakse vastuvõtukomisjoni akt.
Kõik selle töö raames loodud tarkvaratooted antakse Kliendile üle nii valmismoodulitena kui ka standardsel masinkandjal (CD-l) elektroonilisel kujul esitatavate lähtekoodidena.
1.8.3 Vastuvõtukomisjoni staatus (riiklik, osakondadevaheline, osakond)
Vastuvõtukomisjoni staatuse määrab Klient enne testimist.
2. Tehniline projekt
2.1 Funktsionaalne struktuur
2.1.1 Ainevaldkonna kirjeldus
Teemavaldkonnaks on lennupileteid müüv ja broneeriv agentuur.
Ettevõttes on haldusosakond (koosneb raamatupidajast ja juhist), tööjaamade käitamise osakond (infotehnoloogia juhtimine) (süsteemiadministraator ja tehnikud) ning operaatorid.
Teenuste kvaliteedi eest vastutab haldusosakond, kuhu kuuluvad raamatupidaja ja juhataja.
2.1.2 Funktsioonid ja organisatsiooniline struktuur
Ettevõtte struktuuri ülesehitamise võib jagada kolmeks etapiks: organisatsioonimudeli loomine, funktsionaalse mudeli loomine ja teabemudeli loomine.
Piletiagentuur koosneb järgmistest osakondadest:
direktor;
Haldusosakond;
Tööjaamade käitamise osakond;
Operaatorosakond.
Ettevõtte organisatsiooniline struktuur on näidatud joonisel 4.
Joonis 4 – Organisatsioonimudel
Direktor juhib ettevõtte tootmis-, majandus- ja finants- ja majandustegevuse üldjuhtimist, samuti korraldab kõigi selle struktuuriüksuste koostööd.
Tootmisosakond teostab tooteprojekti väljatöötamist, selle hilisemat valmistamist ja komplekteerimist.
Teenuse osutamise kvaliteedi eest vastutab haldusosakond, kuhu kuuluvad raamatupidaja ja juhataja.
Süsteemi seisukorra eest vastutab tööjaama käitamise osakond.
Operaatorid vastutavad tellimuse vastuvõtmise, andmete andmebaasi sisestamise eest.
2.1.3 Andmevoogude ja äriprotsesside kirjeldus
Äriprotsesside modelleerimine
Äriprotsess on omavahel seotud tegevuste või ülesannete kogum, mille eesmärk on luua tarbija jaoks konkreetne toode või teenus. Selguse huvides visualiseeritakse äriprotsessid äriprotsesside vooskeemi abil. Äriprotsesside modelleerimine on organisatsioonide mudelite moodustamise tegevus, mis hõlmab äriobjektide (jaotused, ametikohad, ressursid, rollid, protsessid, operatsioonid, infosüsteemid, infokandjad jne) kirjeldamist ja nendevaheliste suhete näitamist. Nõuded genereeritavatele mudelitele ja nende vastav sisu on määratud modelleerimise eesmärkidega. Ärimodelleerimist nimetatakse tarkvaraarenduse protsessis ka distsipliiniks ja eraldiseisvaks alamprotsessiks, mis kirjeldab ettevõtte tegevust ja määrab süsteemile esitatavad nõuded - need alamprotsessid ja toimingud, mis kuuluvad infosüsteemis automatiseerimisele, on arenenud.
Pärast agentuuri tegevuse analüüsimist ja projektieelse uuringu läbiviimist saab eristada AIS "Ticket" kolme peamist äriprotsessi:
1. Tellimuse vastuvõtmine.
2. Identifitseerimisnumbri väljastamine.
3. Kliendiga arveldamine.
Äriprotsesside funktsionaalset modelleerimist esindab IDEF0 metoodika. See kirjeldab neid äriprotsesse, mis toimuvad automatiseerimisobjektis. IDEF0 metoodika põhineb äriprotsesside kirjeldamise graafilisel keelel. IDEF0 mudelit esindab hierarhiliselt järjestatud ja loogiliselt seotud diagrammide komplekt. Iga diagramm asub eraldi lehel. Diagramme on nelja tüüpi:
A-0 kontekstdiagramm (igal mudelil võib olla ainult üks kontekstdiagramm);
Lagunemisdiagrammid (sealhulgas esimese lagunemisastme diagramm A 0, paljastades kontekstidiagrammi);
Sõlmepuu diagrammid;
Ainult kokkupuute diagrammid (FEO).
Kontekstidiagramm on diagrammide puustruktuuri ülaosa ja kujutab endast kõige üldisemat kirjeldust süsteemist ja selle interaktsioonist väliskeskkonnaga (siin on reeglina kirjeldatud modelleeritava objekti peamist eesmärki). Pärast süsteemi kui terviku kirjeldamist jagatakse see suurteks fragmentideks. Seda protsessi nimetatakse funktsionaalseks lagunemiseks ja diagramme, mis kirjeldavad iga fragmenti ja fragmentide koostoimet, nimetatakse lagunemisdiagrammideks. Pärast kontekstidiagrammi dekomponeerimist (st A 0 diagrammi saamist) jagatakse A 0 diagrammi iga plokk väiksemateks fragmentideks ja nii edasi, kuni saavutatakse soovitud detailsuse tase. Pärast iga lagunemisessiooni peetakse eksamisessioonid - aineeksperdid (tavaliselt on need analüütikute küsitletud ettevõtete töötajad) näitavad tegelike äriprotsesside vastavust loodud diagrammidele. Leitud ebakõlad parandatakse ja alles pärast eksami sooritamist ilma kommentaarideta saate liikuda järgmisele lagunemisseansile. See tagab mudeli vastavuse tegelikele äriprotsessidele mudeli igal tasemel. Süsteemi kui terviku ja iga selle fragmendi kirjeldamise süntaks on kogu mudelis sama.
"AIS Ticketi" põhitegevuseks on lennupiletite müük. Sisend on piletitellimus. Nädalavahetus – kviitung. Põhilise ärifunktsiooni täitmise tööriistad on Bilet OJSC töötajad (raamatupidaja, juht, IT-tehnikud, operaatorid).
Andmevoo diagramm
Nõuded on kujutatud andmevoogudega ühendatud protsesside hierarhiana. Andmevoo diagrammid näitavad, kuidas iga protsess muudab oma sisendid väljunditeks ja näitavad nende protsesside vahelisi seoseid. DFD diagramme kasutatakse edukalt IDEF0 mudeli täiendusena töövoo ja infotöötluse kirjeldamisel. Nagu IDEF0, esindab DFD modelleeritavat süsteemi seotud tegevuste võrgustikuna. DFD põhikomponendid (nagu eespool mainitud) on protsessid või töökohad, välised olemid, andmevood, andmesalved (salvestused). Erinevalt IDEF0 nooltest, mis on jäigad seosed, näitavad DFD nooled, kuidas objektid (sh andmed) liiguvad ühelt töölt teisele.
Erinevalt IDEF0-st, kus süsteemi vaadeldakse omavahel seotud tegevustena, vaatab DFD süsteemi üksuste kogumina. Kontekstiskeem sisaldab sageli teoseid ja välislinke. Töödele viidatakse tavaliselt süsteemi nimega, näiteks "Infotöötlussüsteem". Välislinkide lisamine kontekstidiagrammi ei tühista metoodika nõudeid määratleda selgelt modelleeritava süsteemi eesmärk, ulatus ja ühine vaatenurk.
DFD-s on tegevused (protsessid) süsteemifunktsioonid, mis muudavad sisendid väljunditeks. Kuigi töid kuvatakse ümarate ristkülikutena, on nende tähendus sama, mis IDEF0 ja IDEF3 töödel. Sarnaselt IDEF3 protsessidele on neil sisendid ja väljundid, kuid need ei toeta juhtelemente ja mehhanisme nagu IDEF0.
Välised olemid esindavad süsteemi sisenemisi ja/või süsteemist väljumisi. Välised olemid joonistatakse varjuga ristkülikuna ja asuvad tavaliselt diagrammi servades. Ühte välist olemit saab ühes või mitmes diagrammis kasutada mitu korda. Tavaliselt kasutatakse seda tehnikat selleks, et mitte joonistada liiga pikki ja segaseid nooli.
Töövood on kujutatud nooltega ja kirjeldavad objektide liikumist süsteemi ühest osast teise. Kuna töö kummalgi küljel ei ole DFD-s selget eesmärki, nagu IDEF0-s, võivad nooled minna töö ristküliku mis tahes küljele sisse ja välja. DFD kasutab ka kahepoolseid nooli, et kirjeldada käsu-vastuse dialooge tööde vahel, töö ja välise olemi vahel ning väliste olemite vahel.
Erinevalt nooltest, mis kirjeldavad liikuvaid objekte, kujutavad andmesalved objekte puhkeolekus.
2.2 IC-süsteemi disain
lähteülesanne kuluvate tööjõukulude broneerimine
2.2.1 ISi juurutamise kontseptsiooni, ehitusarhitektuuri ja platvormi väljatöötamine
Peamised aspektid IS-i ehitamise arhitektuuri valikul on kiirus, töökindlus, mastaapsus ja turvalisus.
Praegu on kõige levinumad arhitektuurid:
failiserver;
klient-server;
kihiline arhitektuur.
Failiserveri arhitektuur eeldab, et server täidab ainult andmete salvestamise funktsiooni ja töötlemine toimub kliendi masinates. See tähendab, et andmeid tuleb üle võrgu edastada, mille tulemuseks on tihe võrguliiklus. Ja see omakorda toob kaasa jõudluse vähenemise koos kasutajate arvu suurenemisega. Samuti lahendatakse failiserveri arhitektuuri juurutamisel detsentraliseeritult andmete terviklikkuse, järjepidevuse ja samaaegse juurdepääsu probleem: andmed salvestatakse serverisse ja töödeldakse kliendis. Selle tulemusena väheneb rakenduse usaldusväärsus. Teine puudus on iga kliendi tööjaama äriloogikateenuste uuendamise ja hooldamise kõrge hind. Sellel arhitektuuril on aga ka mitmeid eeliseid, nagu madal arenduskulu, suur arenduskiirus ning madal tarkvara uuendamise ja muutmise hind.
Klient-server arhitektuuril puuduvad ülaltoodud arhitektuuri puudused, kuna andmebaasiserver mitte ainult ei paku juurdepääsu jagatud andmetele, vaid ka töötleb neid. Klient saadab päringud serverile serverile "arusaadavas" keeles ja see omakorda töötleb päringu, kontrollides samal ajal andmete terviklikkust ja järjepidevust ning tagastab kliendile täidetud päringu tulemuse. Selle tulemusena väheneb võrgu koormus: klient ei pea enam töötlema vaheandmeid. Salvestus ja töötlemine on tsentraliseeritud, seega on see arhitektuur usaldusväärsem kui failiserveri arhitektuur. Klient-server arhitektuuri miinusteks on esiteks süsteemiarenduse piisav keerukus, mis tuleneb vajadusest teostada äriloogikat ja pakkuda kasutajaliidest ühes programmis ning samal põhjusel kõrged nõuded tööjaamadele.
IS-i arhitektuuride arendamise järgmiseks sammuks on saanud mitmetasandiline arhitektuur, mille puhul äriloogikat teostatakse rakendusserveris. Kihilisel arhitektuuril on järgmised eelised:
skaleeritavus;
konfigureeritavus - tasemete üksteisest eraldamine võimaldab teil süsteemi kiiresti ja lihtsalt ümber konfigureerida rikete korral või plaanilise hoolduse ajal ühel tasemel;
kõrge turvalisus;
kõrge töökindlus;
madalad nõuded terminalide ja rakendusserveri vahelise kanali (võrgu) kiirusele;
madalad nõuded terminalide jõudlusele ja tehnilistele omadustele, mille tulemusena vähenevad nende maksumus.
Vaatamata vaieldamatutele eelistele ei ole seda süsteemi levitatud järgmistel põhjustel:
mitmetasandilisel arhitektuuril põhinevate süsteemide arendamise keerukus, sest eri moodulitega on väga raske "liituda", eriti kui neid kirjutavad erinevad rühmad. Ja muudatus ühes moodulis põhjustab reeglina muudatuste laviini ülejäänud osas ja sellest vaatenurgast on isegi lihtsat mitmetasandilisel arhitektuuril põhinevat süsteemi 2 korda keerulisem rakendada;
rakendusserverite ja andmebaasiserverite kõrged jõudlusnõuded ning sellest tulenevalt serveri riistvara kõrge hind;
kõrged nõuded andmebaasiserveri ja rakendusserverite vahelise kanali (võrgu) kiirusele;
manustamise kõrge keerukus.
Arvestades iga arhitektuuri kõiki eeliseid ja puudusi, valime AIS Ticket süsteemi juurutamiseks klient-server arhitektuuri. Selline arhitektuur võimaldab optimaalselt jaotada tööd süsteemi kliendi ja serveri osade vahel: tööjaamas töötav rakendus ei loe andmebaasikirjeid "otse", vaid saadab päringud serverisse, kus neid järjestikku töödeldakse ja töötlemise tulemused on saadetakse tööjaama. Ja see vähendab oluliselt teabevoogusid kohtvõrgus.
Infosüsteemi toimimise ja ehituse skeem on näidatud joonisel 5.
Joonis 5 – arhitektuur "klient-server"
2.2.2 Infosüsteemi struktuur, funktsionaalsete ja toetavate allsüsteemide koosseis
Funktsionaalsed allsüsteemid - majandusülesannete kompleks, millel on kõrge teabevahetus (lingid) ülesannete vahel (mingi infotöötlusprotsess koos täpselt määratletud sisend- ja väljundinformatsiooni kogumiga. Funktsionaalsed allsüsteemid pakuvad infoteenust teatud tüüpi majandustegevuse jaoks süsteem (ettevõte), mis on iseloomulik selle struktuuriüksustele ja (või) juhtimisfunktsioonidele Funktsionaalsete allsüsteemide integreerimine ühtsesse süsteemi saavutatakse toetavate allsüsteemide loomise ja käitamise kaudu, näiteks:
Informatiivne;
Tehniline;
Tarkvara;
matemaatiline;
Keeleline.
Toetavad alamsüsteemid on ühised kogu IS-le, sõltumata konkreetsetest funktsionaalsetest alamsüsteemidest, milles teatud tüüpi tuge kasutatakse. Töös ühendatakse toetav ja organisatsiooniline allsüsteem üheks toetavaks alamsüsteemiks. Sellise otsuse põhjenduseks võib pidada seda, et nende komponendid tagavad süsteemi eesmärkide ja funktsioonide elluviimise.
Toetavate allsüsteemide koosseis ei sõltu valitud ainevaldkonnast ja sellel on:
funktsionaalne struktuur;
teabetugi;
Matemaatiline (algoritmiline ja tarkvara) tarkvara;
Tehniline abi;
organisatsiooniline tugi,
ja IS väljatöötamise etapis täiendavad sätted:
seaduslik;
Keeleline;
Tehnoloogiline;
metoodiline;
Liidesed välise IS-iga.
Infotugi on teabebaasi loomise vahendite ja meetodite kogum. See määratleb viisid ja vormid juhtobjekti oleku kuvamiseks IS-is olevate andmete, dokumentide, graafikute ja signaalide kujul väljaspool IS-i.
Matemaatiline tugi koosneb algoritmilisest ja tarkvarast.
Organisatsioonitugi on vahendite ja meetodite kogum tootmise korraldamiseks ja juhtimiseks IS-i juurutamise kontekstis.
Organisatsiooni toetamise eesmärk on: juhtimisülesannete valik ja püstitamine, juhtimissüsteemi ja selle täiustamise võimaluste analüüs, lahenduste väljatöötamine IS-i ja personali interaktsiooni korraldamiseks, juhtimisülesannete elluviimine. Organisatsiooniline tugi hõlmab klientidega suhtlemise meetodeid, paberimajanduse nõudeid, ametijuhendeid jne.
Algoritmitugi on matemaatiliste meetodite, mudelite ja algoritmide kogum, mida süsteemis kasutatakse probleemide lahendamiseks ja teabe töötlemiseks.
2.2.3 IS tehniline tugi
Tehniliste vahendite kompleks peaks sisaldama järgmisi elemente:
Tööjaamad;
Katkematud toiteallikad;
Vahendid kohtvõrgu ehitamiseks;
Andmebaasi server;
Printer.
Nõuded serverile:
Mälu 8 GB;
Protsessor 2,2 GHz Intel Xeon 5500 vähemalt;
Ajami kiirus SATA 8Gb/s;
Võrguadapter 10 Gb / s;
Operatsioonisüsteem Windows Server 2008.
Nõuded tööjaamale:
Protsessor 2 GHz;
Mälu 2 GB;
kõvaketas vähemalt 500;
Operatsioonisüsteem Windows 7;
Võrguadapter 100 Mbps.
ISi tehnilisi vahendeid kirjeldatakse arvestades rakendatava tarkvarakompleksi toimimise nõudeid. Tehnilised vahendid peaksid pakkuma:
Tehniliste vahendite ja seadmete kompleksi ööpäevaringne töö;
Garanteeritud kogu tarkvarapaketi täitmine seadme rikke või rikke korral;
Andmekaitse volitamata juurdepääsu eest;
Serverid ja tööjaamad peavad olema ühendatud kohaliku võrgu kaudu.
Joonis 2.3 näitab OJSC "Bileti" kohtvõrgu (LAN) topoloogiat.
Kõnealusel joonisel on näha, et 5 tööjaama on lüliti kaudu ühendatud andmebaasiserveri ja failiserveriga. Võrgu topoloogia on täht.
Joonis 6 - JSC "Klient" võrgu loogiline skeem
2.3 IP teabetugi
2.3.1 Infobaasi loogilise struktuuri kirjeldus
Loogiline (dataloogiline) disain on andmebaasiskeemi loomine, mis põhineb konkreetsel andmemudelil, näiteks relatsioonilisel andmemudelil. Relatsioonilise andmemudeli puhul on andmeloogiline mudel seoste skeemide kogum, mis tavaliselt tähistab primaarvõtmeid, aga ka suhete vahelisi "linke", mis on võõrvõtmed.
Kontseptuaalse mudeli muutmine loogiliseks mudeliks toimub reeglina formaalsete reeglite järgi. Seda sammu saab suures osas automatiseerida.
Normaalvorm on relatsiooniandmemudeli relatsiooni omadus, mis iseloomustab seda liiasuse mõttes, mis võib viia andmete valimi võtmise või muutmise loogiliselt ekslike tulemusteni. Normaalvormi määratletakse kui nõuete kogumit, millele seos peab vastama. Andmebaasi (DB) suhete teisendamist normaalvormidele vastavaks vormiks nimetatakse normaliseerimiseks. Normaliseerimise eesmärk on viia andmebaasi struktuur sellisele kujule, mis tagab minimaalse loogilise liiasuse, ning see ei ole mõeldud jõudluse vähendamiseks või suurendamiseks ega andmebaasi füüsilise mahu vähendamiseks või suurendamiseks. Normaliseerimise lõppeesmärk on vähendada andmebaasi salvestatud teabe võimalikku vastuolu. Normaliseerimisprotsessi üldine eesmärk on järgmine:
teatud tüüpi koondamise välistamine;
Mõne värskenduse anomaaliate kõrvaldamine;
Andmebaasiprojekti arendamine, mis kujutab endast üsna "kvaliteetset" tegelikku maailma, on intuitiivne ja võib olla hea alus hilisemaks laiendamiseks;
Lihtsustage vajalike terviklikkuse piirangute rakendamise protseduuri.
Üleliigsus kõrvaldatakse tavaliselt suhete lagundamisega selliselt, et igasse relatsiooni salvestatakse ainult esmased faktid (st faktid, mis ei tulene muudest salvestatud faktidest).
Loogilisel tasemel normaliseeritakse andmebaas, samuti võtmete eraldamine iga olemi jaoks. Loogilisi seoseid rakendatakse esmaste ja võõrvõtmete kaudu.
2.3.2 Andmebaasi füüsilise teostuse kirjeldus
Füüsiline disain – konkreetse DBMS-i jaoks andmebaasiskeemi loomine. Konkreetse DBMS-i eripärad võivad hõlmata andmebaasiobjektide nimetamise piiranguid, toetatud andmetüüpide piiranguid jne. Lisaks on konkreetse DBMS-i spetsiifika füüsilise projekteerimise käigus füüsilise andmesalvestuskeskkonnaga seotud lahenduste valik (kettasalvestuse haldusmeetodite valik, andmebaasi failideks ja seadmeteks jagamine, andmetele juurdepääsu meetodid), indeksite loomine, salvestuskeskkonnaga seotud lahenduste valik. jne.
Füüsiline andmemudel on üles ehitatud loogilise mudeli alusel ja kirjeldab andmeid konkreetse DBMS-i abil. Loogilise modelleerimise etapis välja töötatud seosed teisendatakse tabeliteks, atribuudid veergudeks, domeenid valitud konkreetses DBMS-is aktsepteeritud andmetüüpideks.
Need. füüsilises mudelis on objekti parameetrite ja sama füüsilise olemusega mudeli vahel üks-ühele vastavus. Sel juhul seostatakse süsteemi elementi füüsikaliste ekvivalentidega, mis reprodutseerivad uuritava objekti struktuuri, põhiomadusi ja seoseid. Füüsikalises modelleerimises, mis põhineb sarnasuse teoorial, säilitatakse looduses katse läbiviimise tunnused, jälgides samal ajal vastavate füüsikaliste parameetrite optimaalset muutuste ulatust.
Järeldus
Kursusetöö tulemusena valmis lennupiletite müügi ja broneerimise agentuuri infosüsteemi ja selle tarkvara arendamise lähteülesanne.
Infosüsteemi lähteülesanne on põhidokument, mis määratleb infosüsteemi loomise nõuded ja korra, mille kohaselt see välja töötatakse ja kasutuselevõtul vastu võetakse. See sisaldab põhinõudeid infosüsteemi funktsionaalsetele omadustele, töökindlusele, töötingimustele ja infoturbele ning kirjeldab ka süsteemi arendamise korda.
Vastavalt lähteülesandes püstitatud ülesannetele viidi läbi järgmised tehnilise projekti koostamise etapid:
- viidi läbi ainevaldkonna analüüs;
- töötati välja AIS "pileti" funktsionaalne skeem;
- töötati välja kontseptsioon, valiti ehituse arhitektuur ja platvorm süsteemi rakendamiseks;
1. Kavandati AIS "Ticket" kontseptuaalne mudel;
2. Kontseptuaalse mudeli alusel koostati AIS "Ticket" süsteemi loogiline mudel;
3. Määratletakse andmebaasiserveri füüsiline struktuur.
Bibliograafia
1. GOST 19.201-78 Programmide dokumentatsiooni ühtne süsteem. Tehniline ülesanne. Nõuded sisule ja kujundusele
2. GOST 34.602-89 Infotehnoloogia. Automatiseeritud süsteemide standardite kogum. Lähteülesanne automatiseeritud süsteemi loomiseks
3. RD 50-34.698-90 Automatiseeritud süsteemid. Nõuded dokumentide sisule
4. V.P. Romanov, N.Z. Emelyanova, T.L. Partyka Majandusinfosüsteemide projekteerimine. Metoodikad ja kaasaegsed tehnoloogiad. - M: Eksam, 2005.- 256 lk.;
5. Maklakov S.V. BPWin ja ERWin CASE - infosüsteemide arendustööriistad / Maklakov S.V. - M: MEPhI DIALOOG, 2001.-256s.;
6. Boyko V.V. Infosüsteemide andmebaaside kujundamine / Boyko V.V., Savinkov V.M. - 2. väljaanne - M.: Rahandus ja statistika, 1989. - 350 lk.
Majutatud saidil Allbest.ru
...Sarnased dokumendid
Lähteülesanne universaalse kauplemisbaasi haldamise automatiseeritud süsteemi ja laoarvestuse arendamiseks. Infosüsteemi kujundamine ja keskkonna valimine tarkvaratoote loomiseks. Liidese ja kasutusjuhendi loomine.
lõputöö, lisatud 11.07.2015
Vene Föderatsiooni normatiiv-õigusaktid infoturbe valdkonnas. Infosüsteemide infokaitse alase töö korraldamise järjekord. Üldine lähenemine lähteülesande väljatöötamisele selle piirkonna kaitsesüsteemi väljatöötamiseks.
kursusetöö, lisatud 05.05.2015
Lähteülesande loomine lennupileti tellimise infosüsteemi arendamiseks. Nõuded dokumentidele. Süsteemi kontrollimise ja vastuvõtmise järjekord. Infosüsteemi kontseptsiooni, ehituse arhitektuuri ja platvormi väljatöötamine.
kursusetöö, lisatud 13.05.2015
Infosüsteemi "Kuld" loomine, mis automatiseerib Juveelitöökoja tööd. Äriprotsesside modelleerimine IDEF0 ja UML diagrammide ning DFD ja scuence andmevoogudega. Tehnilise projekti ja ülesande koostamine GOST 34.602-89 alusel.
kursusetöö, lisatud 10.02.2013
Ekspertsüsteemi koosseis. Nõuded tehniliste vahendite kompleksile. Automaatse infosüsteemi tehnilise toe ülesehitus ja korraldus. Tehniline dokumentatsioon tarkvaratööriistade arendamiseks ja nende kasutamine.
abstraktne, lisatud 09.10.2014
Programmeerimiskeelte õppimine PHP, SQL, C++, HTML. Kohaliku Denweri serveri käitamise ja kasutamise reeglite ülevaatamine. Lähteülesande koostamine tarkvaratoote arendamiseks. Loodava mobiili- ja veebirakenduse kirjeldus.
kursusetöö, lisatud 04.07.2015
Remonditööde teostamise registreerimiseks ja jälgimiseks automatiseeritud infosüsteemi arendamine ning tarkvara arendusteenuste osutamine ettevõttele "MegionSoftOil", tarkvarasüsteemi ja moodulite rakenduste algoritmide väljatöötamine.
lõputöö, lisatud 29.06.2012
Infosüsteemi arendamise vajaduse põhjendus. Domeeni analüüs. EIS-i loomise lähteülesanne. Ettevõtte õiguslik seisund ja lühikesed majanduslikud omadused. Raamatupidamise ja analüütilise töö seis ettevõttes.
abstraktne, lisatud 01.09.2009
Reisifirma klientidega töötamiseks (taotluste vastuvõtmiseks ja töötlemiseks) automatiseeritud infosüsteemi (AIS) väljatöötamine ja juurutamine. Reisibüroo teostatavusuuring, selle AIS tarkvaraliidese algoritm ja skeem.
lõputöö, lisatud 21.07.2011
Funktsioonipunktide arvu loendamine. Tarkvara arendamise tööjõukulude arvutamine ja selle arendamise eeldatav aeg, elutsükli mudel. Tehniliste kirjelduste väljatöötamine automatiseeritud süsteemi loomiseks, nõuded sellele.
Infosüsteemi projekteerimise lähteülesanne. Lähteülesande põhijaotised. Lähteülesannet kirjeldavad standardid. Nõuete analüüs ja väljatöötamine.
Tehniline ülesanne- tehniline dokument (spetsifikatsioon), mis määrab süsteemile esitatavate nõuete kogumi ja mille on heaks kiitnud nii tellija/kasutaja kui ka süsteemi töövõtja/tootja. Selline spetsifikatsioon võib sisaldada ka süsteemi- ja katsenõudeid.
Lähtetingimused sisaldavad järgmisi jaotisi:
Üldine informatsioon. See jaotis sisaldab: arenduse täielikku nimetust, tellija ja töövõtja täielikku nime ja andmeid, arenduse aluseks olevate dokumentide loetelu, võimalikke tööde algus- ja lõppkuupäevi, menetlemise korda ja süsteemi või selle osade loomiseks tehtud töö tulemuste tutvustamine kliendile.
Arengu alused ja eesmärk. Arengu eesmärki mõistetakse kui automatiseeritud tegevusprotsesside tüüpi.
Nõuded süsteemile. Sisaldab alajaotisi nõuetega süsteemile kui tervikule ja süsteemi poolt täidetavatele funktsioonidele.
Süsteemi loomise töö koosseis ja sisu. Nimekiri teostest ja nende sisust, mida selle projekti raames tehakse
Süsteemi kontrollimise ja vastuvõtmise järjekord. Sisaldab eeldatavaid vahekontrolli kuupäevi ja eeldatavat kliendile tarnimise kuupäeva.
Nõuded töö koosseisule ja sisule, et koostada arendusobjekt süsteemi kasutuselevõtuks. Kirjeldatud on süsteemi kasutuselevõtu ettevalmistustööd.
Nõuded dokumentidele. Sisaldab süsteemi dokumentatsiooni loendit ja koostist.
Arendusallikad. Sisaldab loetelu dokumentidest, kirjandusest, mida kasutatakse süsteemi arendamisel.
IC projekteerimise lähteülesandeid kirjeldavad kolm standardit: GOST 34.602-89, GOST 19.201-78, GOST 19.102-77.
Nõuete väljatöötamist saab kujundada uuringute, ankeetide jms põhjal. Lisaks saab nõudeid kujundada ajurünnaku, tootmistegevuse vaatluse, regulatiivse dokumentatsiooni analüüsi, juba loodud IS analüüsi, kasutusel olevate IS-i versioonide analüüsi põhjal.
Nõuete väljatöötamisel tekivad sageli üksikute nõuete ebaselguse, ebatäielikkuse ja vastuolulisuse probleemid. Nende probleemide kõrvaldamine nõuete väljatöötamise etapis maksab mitu suurusjärku vähem kui samade probleemide lahendamine hilisemates arendusetappides.
Infosüsteemide kasutajaliides. Ehituse üldpõhimõtted. UI stiilid. Kasutajaliidese jõudluse kriteeriumid. Juhised kasutajaliidese ehitamiseks. Disainireeglid.
Kasutajaliides- see on infosüsteemi tarkvara osa, mis vastutab seadmete haldamise eest, millega kasutaja programmiga suhtleb.
Kasutajaliidese planeerimine ja kujundamine peaks põhinema järgmistel mudelitel:
- mentaalne mudel- mingid ootused inimesele, mis põhinevad reaalsustajul ning tema teadmistel ja kogemustel arvutiga.
- Kohandatud mudel- Jälgides, kuidas kasutajad enda jaoks uue liidesega töötavad ja analüüsides nende tagasisidet tööle, saab üldise ettekujutuse tulevasest liidesest. Oluline on, et kasutaja kaasataks IS-iga tehtavasse töösse võimalikult varakult.
- Programmeerija mudel- sünnib programmeerija peas, lähtudes tema ametialasest tegevusest.
UI stiilid. Peamist kasutajaliidese stiili on neli:
- Graafiline kasutajaliides (Graafiline kasutaja Liides, GUI) - See liides põhineb neljal põhielemendil: aknad, kursor (hiir), menüüd ja ikoonid. Kasutatakse ka muid elemente: nupud, lülitid, sisestusväljad jne. Selle liidese eripäraks on täiustatud ekraanikujundusvalikud ja juhtimine hiirekursori abil.
- võrk-liides (võrk kasutaja Liides, WUI) - liides meenutab GUI liidest, kuid oli algselt sellest kehvem. Eelkõige kasutati selles ühe akna režiimi ja objektide "lohistamise" võimalust ei olnud. JavaScripti ja Ajaxi arendamisega muutub see rohkem GUI-liideseks.
- LiidesHUI (inimene kasutaja Liides) on pihuseadmete kasutajaliides. Tavaliselt on nendel seadmetel väga väike ekraan. See sisaldab mõningaid GUI elemente, näiteks menüüüksusi ja ikoone.
- Liidese objekti stiil. Objekti programmeerimise võimalused võimaldavad objekti olemust kasutajaliidesesse üle kanda. Objekti lähenemisviisi iseloomustavad sellised funktsioonid nagu pukseerimine, kontekstimenüüd, tööriistaspikrid jne.
Mõelge kasutajaliidese kvaliteedikriteeriumide komplektile:
- kasutajate mõistmine - kuidas kasutajate vajadused programmi liideses kajastuvad.
- Projekteerimisprotsessi tõhusus– määrab, kas toode on hoolikalt läbi mõeldud ja disainitud.
- Vajadus projekti järele- kas tootel on majanduslik ja sotsiaalne tähtsus.
- Sobivus õppimiseks ja kasutamiseks– kui raske on toodet õppida ja kasutada.
- Kirjavahetus Kas toote disain on probleemide lahendamiseks sobiv.
- esteetilised tunded– kui esteetiliselt meeldiv on toote kasutamine.
- Muudetavus– kui palju saab disain vastavalt kasutaja nõudmistele muutuda.
- Kontrollitavus- mil määral rakendatakse toote juhitavuse funktsiooni: paigaldushaldus, koolitus, hooldus.
Graafilise liidese loomise üldpõhimõtted:
Ühe kasutajakeskkonna kasutamine nn töölaua kujul;
Graafikakende kasutamine andmete kuvamiseks;
Klaviatuurita sisendi kasutamine (hiire kasutamine).
Kasutajaliidese kujundamise reeglid:
- Kasutaja juhtimine - arendajad peaksid andma kasutajale IP üle kõige täielikuma kontrolli (nii palju kui turvalisus seda võimaldab). Mõelge selle põhimõtte mitmele konkreetsele rakendusele:
1) mälu koormuse vähendamine - kasutaja mälu pole nii suur ja mitte nii kiire.
2) liideste ühilduvus - kasutajate võimalus oma kogemusi ja teadmisi edasi anda uue tarkvaraga töötamiseks.
Infosüsteemide modelleerimine. Vajadus modelleerimiskeelte järele. KeelUML. Objektorienteeritud disaini põhimõtted. Keelediagrammide ülevaadeUML. Kasutage juhtumiskeeme ja klassiskeeme.
Modelleerimine- see on uuritava objekti (originaali) asendamine selle tingliku kujutisega või mõne muu objektiga (mudeliga) ja originaali omaduste uurimine mudeli omadusi uurides.
Simulatsiooni efektiivsust on võimalik saavutada, kui on täidetud kaks tingimust: mudel tagab originaali omaduste õige kuva; mudel välistab reaalsel objektil mõõtmiste tegemisel omased probleemid.
Modelleerimiskeel - see on enamasti graafiline märge, mida kasutatakse projektide kirjeldamiseks. Märge on mudelis kasutatud graafiliste objektide kogum. Märgistus on modelleerimiskeele süntaks. Ühelt poolt peaks modelleerimiskeel muutma disaineri otsused kasutajale arusaadavaks, teisalt andma projekteerijatele vahendid infosüsteemi kõige formaliseeritumaks esituseks. Graafiline pilt on sageli kõige arusaadavam teabe esitamise vorm.
UML (ühtne Modelleerimine keel– ühtne modelleerimiskeel) on graafiline kirjelduskeel objektide modelleerimiseks tarkvaraarenduse valdkonnas UML kasutab graafilist tähistust süsteemi abstraktse mudeli esitamiseks, mida nimetatakse UML mudeliks. See keel on välja töötatud IS-i modelleerimiseks UML ei ole programmeerimiskeel, vaid kood genereeritakse UML-i mudeli alusel.
Objektorienteeritud mudel on diagrammide kogum, mis kirjeldab UML-i keelt kasutades IS-i struktuuri ja käitumise erinevaid aspekte.
DiagrammUML- See on elementide komplekti graafiline esitus, mida enamasti kujutatakse tippude (olemite) ja servadega (relatsioonidega) graafikuna.
15. loeng
IS-i loomise lähteülesanne.
2. TK koosseis ja sisu
Soovituslik on väljavõte GOST 34.602-89 INFOSÜSTEEMI LOOMISE TINGIMUSTEST, mis määrab TK koostise ja sisu. RC rakendamise ajal on see lubatud õigustatud muutus TK koosseisus ja sisus.
ToR for IS on põhidokument, mis määratleb automatiseeritud süsteemi loomise (arendamise või kaasajastamise - edasise loomise) nõuded ja korra, mille kohaselt IS töötatakse välja ja võetakse kasutusele.
TOR-is sisalduvad nõuded IP jaoks peavad vastama teaduse ja tehnoloogia praegusele arengutasemele ega tohi olla madalamad kui samalaadsed nõuded parimatele kaasaegsetele kodumaistele ja välismaistele analoogidele.
Sõltuvalt automaatikaobjekti tüübist, eesmärgist, eripäradest ja süsteemi töötingimustest on lubatud TOR-i jaotisi koostada rakenduste vormis, võtta kasutusele täiendavaid, välistada või kombineerida TOR-i alajaotisi.
TK KOOSTIS JA SISU
1. Jaotis "Üldine informatsioon" märkige: süsteemi täisnimi ja selle sümbol; süsteemi arendaja ja tellija (kasutaja) ettevõtete (ühenduste) nimi ja andmed; süsteemi loomisega seotud tööde kavandatud algus- ja lõppkuupäevad .
2. Jaotis "Süsteemi loomise (arendamise) eesmärk ja eesmärgid" koosneb alajaotistest:
"Süsteemi eesmärk" näitab automatiseeritud tegevuse tüüpi (juhtimine, projekteerimine jne) ja automatiseerimisobjektide loendit, millel seda kasutatakse.
"Süsteemi loomise eesmärgid" annavad automaatikaobjekti tehniliste, tehnoloogiliste, tootmis-, majanduslike või muude näitajate nimetused ja nõutavad väärtused, mis tuleb saavutada IS-i loomise tulemusena, näitavad kriteeriumid saavutamise hindamiseks. süsteemi loomise eesmärgid.
Peatükis "Automatiseerimisobjekti omadused" anda lühiinfot automaatikaobjekti kohta või linke sellist informatsiooni sisaldavatele dokumentidele ning infot automaatikaobjekti töötingimuste ja keskkonnaomaduste kohta.
3. Jaotis "Nõuded süsteemile" koosneb järgmistest alajaotistest: nõuded süsteemile tervikuna; nõuded süsteemi poolt täidetavatele funktsioonidele (ülesannetele); nõuded turvaliikidele.
IS-i TOR-i selles jaotises sisalduvate süsteeminõuete koosseis määratakse sõltuvalt konkreetse süsteemi tüübist, eesmärgist, eripäradest ja töötingimustest.
Alajaotises "Nõuded süsteemile tervikuna" märkige:
nõuded süsteemi ülesehitusele ja toimimisele;
nõuded süsteemi töötajate arvule ja kvalifikatsioonile ning selle töörežiimile;
sihtkoha indikaatorid;
usaldusväärsuse nõuded;
ohutusnõuded;
nõuded ergonoomikale ja tehnilisele esteetikale;
teisaldatavuse nõuded mobiilsetele IC-dele;
süsteemi komponentide käitamise, hoolduse, remondi ja ladustamise nõuded;
nõuded teabe kaitsmiseks volitamata juurdepääsu eest;
nõuded teabe ohutusele õnnetusjuhtumite korral;
nõuded kaitseks välismõjude eest;
standardimise ja ühtlustamise nõuded;
Lisanõuded.
Süsteemi struktuuri ja toimimise nõuded hõlmavad järgmist:
1) allsüsteemide loetelu, nende eesmärk ja põhiomadused, nõuded hierarhia tasandite arvule ja süsteemi tsentraliseerituse astmele;
2) nõuded süsteemi komponentide vahelise teabevahetuse meetodite ja sidevahendite kohta;
3) nõuded loodava süsteemi ühenduste omadustele seotud süsteemidega, nõuded selle ühilduvusele, sealhulgas juhised teabe vahetamiseks (automaatselt, dokumente saates, telefoni teel jne);
4) nõuded süsteemi töörežiimidele;
5) nõuded süsteemi diagnoosimiseks;
6) arenguperspektiivid, süsteemi kaasajastamine.
Töötajate arvu ja kvalifikatsiooni ning IS-juhtimise nõuetes:
nõuded IS-i personali (kasutajate) arvule;
nõuded personali kvalifikatsioonile, selle väljaõppe ning teadmiste ja oskuste kontrolli kord;
IS personali nõutav töörežiim.
IP määramise näitajate nõuetes annavad nad parameetrite väärtused, mis iseloomustavad süsteemi vastavuse astet selle eesmärgile (süsteemi kohanemisvõime muutustega protsessides, juhtimismeetodites, juhtimisobjekti parameetrite kõrvalekalletega; ajakohastamise ja arendamise lubatavad piirid süsteem; tõenäosuslikud ja ajalised omadused, mille alusel säilitatakse süsteemi sihtotstarve).
Usaldusväärsuse nõuded hõlmavad järgmist:
1) süsteemi kui terviku või selle alamsüsteemide usaldusväärsuse näitajate koostis ja kvantitatiivsed väärtused;
2) loetelu hädaolukordadest, mille jaoks tuleks reguleerida töökindlusnõudeid, ja vastavate näitajate väärtused;
3) nõuded riist- ja tarkvara töökindlusele;
4) nõuded usaldusväärsuse näitajate hindamise ja seire meetoditele süsteemi loomise erinevates etappides vastavalt kehtivatele regulatiivsetele ja tehnilistele dokumentidele.
Turvanõuded hõlmavad nõuded ohutuse tagamiseks süsteemi tehniliste vahendite paigaldamisel, reguleerimisel, kasutamisel, hooldamisel ja remondil (kaitse elektrivoolu, elektromagnetväljade, akustilise müra jms mõju eest), vastavalt lubatud valgustuse, vibratsiooni ja müra tasemetele koormused.
Ergonoomika ja tehniline esteetika sisaldama IS-indikaatoreid, mis täpsustavad inimese ja masina suhtluse nõutavat kvaliteeti ja personali töötingimuste mugavust.
Mobiilsete IC-de puhul hõlmavad teisaldamise nõuded projekteerimisnõuded, mis tagavad süsteemi tehniliste vahendite transporditavuse, samuti nõuded sõidukitele.
Kasutus-, hooldus-, remondi- ja ladustamisnõuded hõlmavad:
1) töötingimused ja eeskirjad (režiim), mis peaksid tagama kindlaksmääratud tehniliste näitajatega süsteemi tehniliste vahendite (TS) kasutamise, sealhulgas süsteemi TS hoolduse tüübid ja sagedus või hoolduseta töö lubatavus ;
2) esialgsed nõuded süsteemi personali ja TS-i paigutuse lubatud aladele, toitevõrkude parameetritele jne;
3) nõuded hoolduspersonali arvule, kvalifikatsioonile ja nende tööviisidele;
4) nõuded varutoodete ja -seadmete komplekti koostisele, paigutusele ja säilitustingimustele;
5) nõuded hooldusgraafikule.
Nõuded teabe kaitsmiseks volitamata juurdepääsu eest sisaldama kliendi tööstuses (osakonnas) tegutsevas NTD-s kehtestatud nõudeid.
Teabe ohutuse nõuetes anda sündmuste loetelu: õnnetused, tehniliste vahendite rikked (sh voolukatkestus) jne, mille puhul tuleb tagada süsteemis oleva teabe ohutus.
Välismõjude eest kaitsmise vahendite nõuetes on toodud:
1) intellektuaalomandi varade elektroonilise kaitse nõuded;
2) välismõjude vastupidavuse, stabiilsuse ja tugevuse nõuded (kasutuskeskkond).
Patendiloa nõuetes märkida riikide loetelu, mille suhtes süsteem ja selle osad peavad olema patendivabad.
Standardiseerimise ja ühtlustamise nõuded hõlmavad järgmist: näitajad, mis määravad kindlaks standardsete standardite nõutava kasutusastme, ühtsed meetodid süsteemi funktsioonide (ülesannete) rakendamiseks, tarnitavad tarkvaratööriistad, tüüpilised matemaatilised meetodid ja mudelid, tüüpilised disainilahendused, GOST 6.10.1 kehtestatud juhtimisdokumentide ühtsed vormid , üleliidulised tehnilise ja majandusteabe klassifikaatorid ja muude kategooriate klassifikaatorid vastavalt nende ulatusele, tüüpiliste automatiseeritud tööjaamade, komponentide ja komplekside kasutamise nõuded.
Lisanõuded sisaldab:
1) nõuded süsteemi varustamiseks personali koolitusseadmetega (simulaatorid, muud sarnase otstarbega seadmed) ja nende dokumentatsioon;
2) nõuded hooldusseadmetele, süsteemielementide kontrollimise stendidele;
3) töö eritingimustega seotud süsteeminõuded;
4) erinõuded süsteemi arendaja või tellija äranägemisel.
Alajaotises “Nõuded funktsioonidele (ülesannetele)”, mida süsteem täidab, on toodud:
1) iga alamsüsteemi kohta automatiseeritavate funktsioonide, ülesannete või nende komplekside (sealhulgas need, mis tagavad süsteemi osade koostoimet) loetelu;
2) iga funktsiooni, ülesande (või ülesannete kogumi) täitmise ajakava;
3) nõuded iga funktsiooni (ülesande või ülesannete kogumi) teostamise kvaliteedile, väljundinformatsiooni esitamise vormile, nõutava täpsuse ja täitmisaja tunnustele, grupi täitmise samaaegsusele esitatavad nõuded. funktsioonid, tulemuste usaldusväärsus;
4) loetelu ja tõrkekriteeriumid iga funktsiooni kohta, millele on määratud töökindlusnõuded.
Alajaotises “Nõuded tagatise liikidele” on olenevalt süsteemi tüübist toodud järgmised nõuded:
Tarkvara jaoks süsteemid esitavad nõuded koostisele, ulatusele (piirangutele) ja meetoditele, matemaatiliste meetodite ja mudelite kasutamisele süsteemis, tüüpilistele arendatavatele algoritmidele ja algoritmidele.
Teabetoetuseks: süsteemijuhtmete nõuded:
1) süsteemis andmete koostisele, struktuurile ja korrastamise meetoditele;
2) infovahetuseks süsteemi komponentide vahel;
3) teabe ühilduvusele naabersüsteemidega;
4) antud ettevõttes tegutsevate üleliiduliste ja registreeritud vabariiklike, tegevusalade klassifikaatorite, ühtsete dokumentide ja klassifikaatorite kasutamise kohta;
5) andmekogude haldussüsteemide kasutamise kohta;
6) andmete kogumise, töötlemise, süsteemis edastamise ja esitamise protsessi ülesehitusele;
7) kaitsta andmeid hävimise eest süsteemi avariide ja elektrikatkestuse korral;
8) andmete kontroll, säilitamine, uuendamine ja taastamine;
Keeleliseks toeks süsteemid esitavad nõuded kõrgetasemeliste programmeerimiskeelte kasutamisele süsteemis, kasutaja suhtluskeeltele ja süsteemi tehnilistele vahenditele, samuti nõuded andmete kodeerimisele ja dekodeerimisele, andmete sisend-väljundkeeltele, andmetöötluskeeltele, ainevaldkonna kirjeldamise vahendid (automaatikaobjekt), dialoogi korraldamise viisid.
Tarkvara jaoks süsteemid pakuvad ostetud tarkvara nimekirja ja nõudeid: tarkvara sõltumatus kasutatavast CVT-st ja OS-ist; PS kvaliteedile, samuti selle pakkumise ja kontrolli meetoditele; kui on vaja vastvalminud tarkvara kooskõlastada algoritmide ja programmide fondiga.
Tehnilise toe jaoks süsteemijuhtmete nõuded:
1) tehniliste vahendite liikidele, sealhulgas tehniliste vahendite komplekside, tarkvara- ja riistvarakomplekside ning muude süsteemis kasutamiseks vastuvõetavate komponentide liikidele;
2) süsteemi tehnilise toe funktsionaalsetele, konstruktiivsetele ja tööomadustele.
Metroloogilise toe nõuetes juhtima (majandusteadlastele valikuline):
1) mõõtekanalite esialgne loetelu;
2) nõuded parameetrite mõõtmise täpsusele ja (või) mõõtekanalite metroloogilistele karakteristikutele;
3) nõuded süsteemi tehniliste vahendite metroloogilisele ühilduvusele;
4) süsteemi juhtimis- ja arvutuskanalite loetelu, mille täpsuskarakteristikuid on vaja hinnata;
Organisatsioonilise toetuse eest nõudma:
1) süsteemi toimimises või talitlust tagavates üksuste struktuuris ja funktsioonides;
2) süsteemi toimimise korraldusele ning IS-i personali ja automaatikaobjekti personali suhtlemise korrale;
3) kaitseks süsteemipersonali eksliku tegevuse eest.
Metodoloogiliseks toeks anda nõuded süsteemi regulatiivse ja tehnilise dokumentatsiooni koostisele (selle töö käigus kasutatud standardite, eeskirjade, meetodite jms loetelu).
Avaleht > LähtetingimusedVENEMAA FÖDERATSIOONI KULTUURIMINISTEERIUM
Peterburi Riiklik Kultuuri- ja Kunstiülikool
Informaatika ja infotehnoloogia osakond
INFOSÜSTEEMI DISAIN
TEHNILINE ÜLESANNE
arendamiseks
hariduse infosüsteem
< Süsteemi täisnimi ja selle sümbol >
4 lehel
välja antud __.__.200_
Peterburi
Üldine informatsioon
Arengu põhjused
- Tööde alustamise ja lõpetamise kavandatavad kuupäevad, samuti töötulemuste töötlemise ja Tellijale esitamise kord on määratud käesoleva TOR lõigetes 4 ja 5.
Hariduse infosüsteemi loomise eesmärk ja eesmärgid
- Eesmärk
- demonstreerida kursuse "Infosüsteemide projekteerimine ja kasutamine" sisu assimilatsiooniastet üliõpilase poolt, et kasutada seda eeskujuna edasises töös reaalse infosüsteemi loomisel või täiustamisel.
- Infosüsteemi haridusprojekti loomise eesmärgid
- õpilase saavutus süsteemi projekteerimise protsessi põhimõistetest arusaamises, põhimõistete ja projekteerimismeetodite vaheliste seoste valdamises, süsteemiprojekti ja selle dokumentatsiooni väljatöötamise oskuses, samuti reaalse IS loomises, demonstreerides projekti tulemusi. töö ja koolituskursuse sisu assimilatsiooniaste, luues aluse edasiseks tööks projekti ja selle praktilise elluviimise parendamiseks.
Nõuded hariduse infosüsteemi aruandlusmaterjalidele
- Nõuded materjalidele üldiselt
- Aruandlusmaterjalide koosseis. Aruandlusmaterjalid peaksid koosnema kahest põhiosast: projekti dokumentatsioon ja infosüsteemi paigutus (täidetud andmebaas koos päringu, vormide, aruannete, juurdepääsulehtedega), mis on rakendatud ACCESS DBMS-i (või mõne muu süsteemi) abil. Paigutus tuleb teostada vastavalt projektile. Kujundusmaterjalid peaksid kirjeldama paigutust ja selle võimalusi.
- Projekti dokumentatsiooni sisu
- Tiitelleht projekteeritava IC nimega, arendaja ja tellija märge. Jaotis "Teostatavusuuring", mis sisaldab teemavaldkonna lühikirjeldust:
- ainevaldkonna üldised omadused ja selle valdkonna teabetegevuse automatiseerimise töö seis; olemasolevate sarnaste süsteemide võimaluste ja omaduste analüüs; organisatsiooni struktuur, mille jaoks projekteeritav IS luuakse; mis on projekteeritavat IS-i kasutava organisatsiooni (süsteemi) eesmärk, selle funktsioonid (organisatsiooniline, "materiaalne", informatiivne); organisatsiooni tegevuse peamised tehnilised ja majanduslikud näitajad; infoprotsessid, nendevahelised seosed; kasutatavate dokumentide koosseis ja otstarve.
- Lühiülesanne. TOR peaks kajastama:
- IS loomise eesmärk ja eesmärk; nõuded süsteemile tervikuna; peamised automatiseeritud funktsioonid ja ülesanded, probleemide lahendamise ajalised omadused ja nõuded teabe esitamisele süsteemis;
- arendatava süsteemi efektiivsuse kriteeriumid (arendatava süsteemi kasulikkust määravad tegurid, nende hindamise kriteeriumid); etappide ja tööetappide loetelu ning nende teostamise ajastus, projekti dokumentatsiooni väljatöötamise ajastus.
- Jaotis "Tehniline projekteerimine", mis sisaldab järgmisi alajaotisi:
- süsteemi funktsionaalne mudel (esita kontekstdiagramm, esimese taseme diagramm ja üks või kaks teise taseme diagrammi; kirjeldada põhifunktsioonide koostist, nende seoseid: sisend, väljund, juhtimisvood); andmevoo mudel (esitage kontekstuaalne skeem, esimese taseme skeem ja üks või kaks teise taseme skeemi; kirjeldage draivide koostist, põhifunktsioone, nende infoühendusi: sisend- ja väljundvooge; iga andmedraivi puhul iseloomustage mahtu, uuenduste sagedus ja intensiivsus); infotoe kirjeldus: sisend- ja väljunddokumentide vormid, nende mahu tunnused, sagedus, uuendamise intensiivsus, nende struktuuri analüüs (detailid, kirjeldatud olemid), kasutatavad klassifikaatorid, kodeerimismeetodid, nõuded andmete usaldusväärsuse tagamiseks.
- Kasutatud allikate loetelu (kirjandus). Jaotis "Tööprojekt", mis sisaldab järgmisi alajaotisi:
- tarkvara kontseptuaalne skeem ja süsteemiandmebaasi füüsiline skeem (töötatud Power Designer süsteemi abil); konkreetse arenduse kirjeldus IP projekti elluviimiseks:
- andmebaasi skeemi kirjeldus ACCESSis (või mõnes teises DBMS-is), Tehnilises kavandis sõnastatud funktsioone realiseerivate ülesannete kirjeldus (sh nendes ülesannetes kasutatavad päringud, vormid, aruanded, juurdepääsulehed). Vajalikud on dialoogivormid ja juhised nende kasutamiseks. Kui projektil pole keerulisi vorme, aruandeid, vähendatakse punktisummat 1 punkti võrra.
- Järeldus: töö tulemuste kokkuvõte. Viide selle kohta, millised tehnilise projekti sätetest on teises osas rakendatud ja mitte rakendatud ja miks.
- Infosüsteemi paigutus
Infosüsteemi paigutus peab olema teostatud vastavalt projektile. See peaks olema täidetud andmebaas päringute, vormide, aruannetega, mis rakendavad projektis kirjeldatud ülesandeid.
- Nõuded dokumentidele
- aruandlusdokumendi osade ja alajagude koosseis peab vastama lõigus "Projektidokumentatsiooni sisu" loetletule, funktsionaalse mudeli skeemid, andmevoo mudelid, kontseptuaalne ja füüsiline mudel on koostatud kujul joonised ja need sisalduvad põhitekstis; ka päringu põhiteksti tekstides on lisadena toodud blankettide esitluse joonised, aruanded, juurdepääsulehed, näidisdokumendid, mudeleid kirjeldavad tabelid, andmebaasi väljade omadusi kirjeldavad tabelid.
Tööetappide loetelu ja nende teostamise tähtajad
Aruandlusmaterjalide kontrollimise ja vastuvõtmise kord
- Aruandlusmaterjalid esitatakse kahes osas:
- Sügissemestril esitatakse aruanne, mis vastab tunniplaani viiele esimesele punktile. Kevadsemestril esitatakse töö lõpptulemused: aruanne (sealhulgas eelmise semestri korrigeeritud tulemused), samuti andmebaas - väljatöötatud IS-i mudel.
- Tööde hindamine sügissemestril toimub kontrolltöö vormis. Kevadsemestril esitatakse kõik aasta tööd kursusetöödena. Eksamile lubatakse ainult kursusetöö kaitsnud üliõpilased. Karistused.
Aruandlusmaterjalide väljatöötamise tööde ajakava
Tabel 4.1.
| Lavanimi | Tähtaeg | Esitletud materjalid |
|
| SÜGISSEMESTR TÖÖD | |||
| 1 | Ainevaldkonna ja organisatsiooni valik, mille jaoks infosüsteem kavandada | Nädal pärast esimest loengut | IP nimi |
| 2 | Ainevaldkonna "uuring" (kirjanduses ja ekspertidega suhtlemise tulemusena) | Nädal pärast kolmandat loengut | |
| 3 | Funktsionaalse mudeli väljatöötamine | Nädal pärast neljandat loengut | Funktsionaalskeemid käsitsi kirjutatud kujul |
| 4 | Andmevoo mudeli väljatöötamine | Nädal pärast viiendat loengut | Käsitsi kirjutatud andmevoo skeemid |
| 5 | Sisend- ja väljunddokumentide kirjelduste väljatöötamine | Lõpp 25. november | Nõutav dokumendi struktuur, atribuutide funktsionaalsed sõltuvused |
| 6 | Projekti dokumentatsiooni väljatöötamine vastavalt punktidele 3.2.1 - 3.2.5 | Pooleli. praktiline klassid. | |
| 7 | Projekti dokumentatsiooni kohaletoimetamine | 20. detsember | Dokumentatsioon aruande vormis |
| KEVADSEMESTR TÖÖD | |||
| 8 | Kontekstuaalse domeeni skeemi väljatöötamine | Nädal pärast teist loengut | Tarkvara kontekstiskeem käsitsi kirjutatud kujul |
| 9 | Andmebaasi skeemi väljatöötamine valitud DBMS-i keeles | Teise praktilise osa lõpuks klassid | |
| 10 | Süsteemi juurutamine (andmebaasitabelite täitmine, päringute, vormide, aruannete, juurdepääsulehtede väljatöötamine) | Viienda praktilise seansi lõpuks | Täidetud andmebaas päringute, vormide jms; esitati õpetajale |
| 11 | Tulemuste registreerimine (projekt ja andmebaas) | Nädal pärast punkti 9 | Kursusetöö: dokumentatsioon aruande vormis ja toimikus; andmebaasi |
| 12 | Kursusetöö kaitsmine | Mitte varem kui nädal pärast eelmist tähtaega |
