1

Ang artikulo ay nakatuon sa mga isyu ng pagbuo ng isang sistema ng impormasyon na idinisenyo upang pag-aralan ang mga proyekto sa pamumuhunan na isinumite sa mga istrukturang pang-administratibo upang makakuha ng suportang pinansyal. Ang istraktura ng naturang sistema ay isang kumplikadong impormasyon na binubuo ng isang panlabas na module at ang pangunahing sistema. Ang panlabas na module ay idinisenyo upang ihanda ang paunang impormasyon sa proyekto at matatagpuan sa enterprise na kalahok sa kompetisyon. Sinusuri ng pangunahing sistema ang mga proyekto at matatagpuan sa administrative control body. Ang istraktura ng pangunahing sistema ay naglalayong ipatupad ang mga tampok ng pagsusuri ng mga proyekto sa pamumuhunan. Ang papel ay nagmumungkahi din ng mga pangunahing prinsipyo at pamamaraan para sa pagsusuri ng mga proyekto sa pamumuhunan. Upang suriin ang proyekto, maraming mga paunang tagapagpahiwatig ang nahahati sa mga grupo na nagpapakilala sa ilang mga aspeto ng kalagayang pinansyal ng organisasyon. Kasama rin ang mga karagdagang tagapagpahiwatig na mahalaga para sa panlipunan, kultura at iba pang pag-unlad ng teritoryo. Sa pagsasaalang-alang na ito, ang ipinakita na pamamaraan ay nagpapahintulot, sa proseso ng paggawa ng desisyon sa paglalaan ng mga pautang, upang i-ranggo ang mga proyekto sa pamumuhunan hindi lamang sa pamamagitan ng mga tagapagpahiwatig ng pananalapi, ngunit isinasaalang-alang din ang mga priyoridad ng istruktura ng organisasyong pang-administratibo na hindi direktang nauugnay sa ang kalagayang pinansyal ng organisasyong kalahok sa kompetisyon.

Sistema ng impormasyon

istraktura

metodolohiya

proyekto sa pamumuhunan

istrukturang administratibo

1. Brykin I.M., Beklemishev A.V. Pagsusuri, pagpili at pagsusuri ng mga proyekto sa pamumuhunan. - M .: LLC "International Media Group", 2011. - 47 p.

2. Bailey D.V., Sharp U.F., Alexander G.D. Mga pamumuhunan. – M.: INFRA-M, 2012. – 1028 p.

3. Vilensky P.L., Livshits V.N., Smolyak S.A. Pagsusuri ng pagiging epektibo ng mga proyekto sa pamumuhunan. Teorya at kasanayan: Proc. Benepisyo. – M.: Delo, 2008. – 888 p.

4. Kravchenko T.K., Presnyakov V.F. Mga teknolohiya ng Infocommunication ng pamamahala ng enterprise - M.: State University Higher School of Economics, 2003. - 272 p.

5. Lipsits I.V., Kossov V.V. Pagsusuri sa pamumuhunan. Paghahanda at pagsusuri ng mga pamumuhunan sa mga tunay na asset. – M.: INFRA-M, 2014. – 320 p.

6. Svetlov N.M., Svetlova G.N. Mga teknolohiya ng impormasyon para sa pamamahala ng proyekto - M.: INFRA-M, 2012. - 144 p.

7. Shuremov E. Pagsusuri ng negosyo sa kompyuter. // PC mundo. - 1998. - Hindi. 1. - P. 80–83.

Ang pagiging epektibo ng paggawa ng desisyon sa pamamahala sa pagkakaloob ng mga pamumuhunan sa larangan ng maliit na negosyo sa mga kondisyon ng merkado ay higit sa lahat ay nakasalalay sa mga tool na ginamit upang pag-aralan ang mga aktibidad sa pananalapi at pang-ekonomiya ng mga negosyo. Ang pagpili ng mga tool sa pagsusuri para sa mga istrukturang pang-organisasyon ng administratibo ay lalong mahalaga, kapag ang desisyon na magpahiram sa isang proyekto ay dapat na maimpluwensyahan hindi lamang ng pagganap sa pananalapi ng negosyo, kundi pati na rin ng mga priyoridad ng administratibong entidad sa ilalim ng kontrol ng istraktura ng organisasyong ito .

Ang mga problemang isinasaalang-alang sa artikulo ay nauugnay sa pagbuo ng mga sistema para sa pagsusuri ng mga aktibidad ng isang negosyo ng mga panlabas na organisasyon at pamamahala at kontrol na mga katawan. Ang layunin ng mga sistema ay hindi lamang upang masuri ang kalagayang pinansyal at pang-ekonomiya ng negosyo, kundi pati na rin ang mga posibilidad at mga prospect para sa pakikipag-ugnayan o pakikipagtulungan dito. Ang base ng impormasyon ng pagsusuri ay binubuo ng mga tagapagpahiwatig na nakuha sa isang paraan o iba pa mula sa karaniwang accounting, pag-uulat ng istatistika at mga bukas na mapagkukunan.

Kabilang sa mga umiiral na sistema ng pananalapi at analytical, maaari isa-isa ang mga pag-unlad ng naturang mga kumpanya tulad ng Expert Systems, Galaktika, INEK, Alt-Invest, gayunpaman, ang kanilang epektibong paggamit nang walang mga pagbabago ng mga istrukturang pang-organisasyon ay may problema, dahil ang mga sistemang ito ay hindi malulutas ang mga problema ng proyekto ng pagtatasa na may kaugnayan sa mga parameter na priyoridad para sa istrukturang pang-administratibo, ngunit hindi sa likas na pananalapi.

Istraktura ng sistema ng impormasyon

Ang pangangailangan at kaugnayan ng isang husay na pagsusuri ng daloy ng mga proyekto sa pamumuhunan at ang umiiral na mga pagkakaiba-iba sa mga interes ng isang ordinaryong mamumuhunan at isang mamumuhunan sa anyo ng isang istraktura ng administratibong organisasyon ay nagsasalin ng problema sa pagpili ng isang instrumento sa eroplano ng pag-unlad nito. Kasabay nito, ipinapayong italaga ang mga sumusunod na gawain sa binuo na sistema:

Pagsusuri ng kalagayan sa pananalapi ng negosyo, kabilang ang dinamika;

Pagsusuri ng pinansiyal na bahagi ng plano sa negosyo ng proyekto;

Pagsusuri ng epekto ng kredito sa kalagayang pinansyal ng negosyo;

Isinasaalang-alang ang mga priyoridad ng lungsod sa proseso ng pagsusuri ng proyekto;

Comparative analysis ng mga proyekto ng ilang negosyo;

Pagtataya ng pag-unlad ng negosyo at pagbabalik ng mga pautang.

Batay sa mga tampok at likas na katangian ng mga gawain na itinakda, ang isang block diagram ng sistema ng pagsusuri ay binuo, na ipinapakita sa figure.

Ang panlabas na module ng system ay isang autonomous na programa na idinisenyo upang ihanda ang paunang impormasyon na kinakailangan para sa paggawa ng desisyon sa paglalaan ng pautang para tustusan ang iminungkahing proyekto:

Balanse sheet at karagdagang mga dokumento ng balanse;

Pinansyal na bahagi ng plano sa negosyo ng proyekto;

Karagdagang impormasyon na kinakailangan upang isaalang-alang ang mga priyoridad ng administratibong awtoridad.

Nagbibigay ang module para sa parehong direktang pag-input ng impormasyon gamit ang keyboard, at gumagana sa mode ng pag-import ng data mula sa ibang mga system. Kasabay nito, sinusuri ng panlabas na module ang kawastuhan ng impormasyong ipinasok upang maibukod ang mga hindi sinasadyang pagkakamali.

Ang istraktura ng pangunahing bahagi ng system ay naglalayong ipatupad ang mga tampok ng pagsusuri ng mga proyekto sa pamumuhunan.

Ang pangunahing papel ay nilalaro ng "Module para sa pag-set up ng kapaligiran sa pagtatrabaho at sistema ng dalubhasa". Sa modyul na ito, nabuo ang iba't ibang mga senaryo ng pagsusuri, tinutukoy ang mga karagdagang tuntunin at pamantayan na sumasalamin sa mga interes ng lungsod at administrasyon, at itinakda ang mga kritikal na halaga ng mga ratios sa pananalapi.

Kinakalkula ng "Module para sa pagkalkula ng mga financial indicator" ang mga financial ratio.

Structural diagram ng sistema ng impormasyon para sa pagsusuri ng mga proyekto sa pamumuhunan

Ang "Pagsusuri ng proyekto at mga resulta ng visualization module" ay nagpapakita ng mga resulta ng pagsusuri sa analytical, graphical at tabular na paraan.

Ang "modul ng pagbuo ng ulat" ay nauugnay sa karaniwang software at nilayon para sa paghahanda ng mga materyales sa pag-uulat.

Ang sistema ng dalubhasa ay idinisenyo upang tumulong sa pagsusuri ng mga resultang nakuha.

Pamamaraan para sa pagsusuri ng mga proyekto sa pamumuhunan

Ang pamamaraan para sa pagsusuri ng mga proyekto sa pamumuhunan ay binubuo sa isang komprehensibong pagsusuri ng kalagayan sa pananalapi ng isang negosyo, kasama ang isang pagtatasa ng proyekto ng pamumuhunan mismo at pagtukoy ng rating ng proyekto para sa karagdagang paggawa ng desisyon sa paglalaan ng mga pautang.

Mayroong maraming mga paunang tagapagpahiwatig, na nahahati sa mga grupo na nagpapakilala sa ilang mga aspeto ng kondisyon sa pananalapi ng organisasyon. Ang mga pangkat ng mga tagapagpahiwatig na ito ay puro sa magkahiwalay na mga dokumento, halimbawa, isang ulat sa accounting, atbp.

Kaya, may mga L-grupo ng mga paunang tagapagpahiwatig , kung saan at L-mga pangkat ng mga kamag-anak na tagapagpahiwatig , kung saan , l ang bilang ng pangkat, at kl ang ordinal na numero ng tagapagpahiwatig sa pangkat.

Batay sa mga pangunahing tagapagpahiwatig, nabuo ang mga pangkat-Q ng mga pangalawang tagapagpahiwatig, kung saan ang q = 1, Q, , at mq ay ang ordinal na numero ng tagapagpahiwatig sa pangkat na ika-q. Tinatawag namin itong mga indicator coefficient.

Sa batayan ng mga tagapagpahiwatig at tagapagpahiwatig ng dinamika ng kanilang pagbabago ay nabuo sa ganap at kamag-anak na mga yunit ng uri

kung saan ang j - ay nagpapakilala sa bilang ng mga sukat ng indicator o coefficient.

Ang bawat tagapagpahiwatig at koepisyent ay naayos sa isang bilang ng mga punto ng oras. Ang nakuha na mga halaga ay nagbibigay-daan sa amin upang matukoy ang dinamika ng mga pagbabago sa mga tagapagpahiwatig at koepisyent sa paglipas ng panahon:

Tapos ako = J + 1.

Nakatakda ang mga kundisyon para sa mga coefficient. Ang pagsusulatan ng mga coefficient sa mga kondisyon ay nagpapakita na ang estado ng mga pangkalahatang katangian ng kondisyon sa pananalapi ng negosyo, na tinutukoy ng koepisyent na ito, ay normal.

Sa proseso ng pagsusuri ng isang proyektong pangnegosyo, hindi bababa sa tatlong pangunahing gawain ang nalutas:

a) pagtatasa ng posibilidad ng pagbabayad ng utang ng pinag-uusapang negosyo at, dahil dito, ang desisyon na isama ito sa listahan ng potensyal na angkop para sa pagpapahiram;

b) pagtatasa ng posibilidad ng pagpapahiram, batay sa mga priyoridad ng administrasyon;

Ang mga gawaing ito ay nalutas sa loob ng balangkas ng isang multilevel na pagsusuri ng mga coefficient at indicator.

Ang pagsusuri ay isinasagawa sa pagkalkula ng mga coefficient at pagsusuri ng mga kondisyon. Ang mga coefficient ay nahahati sa loob ng mga grupo sa mga subgroup ng higit pa at hindi gaanong mahalaga. Ang unang antas ng pagsusuri ay nauugnay sa pagtatasa ng katuparan ng mga kondisyon para sa mga napiling subgroup ng mga coefficient at higit sa lahat ay malulutas ang problema

a) Sa pangalawa at kasunod na mga antas, ang iba pang mga koepisyent at tagapagpahiwatig ay sinusuri, pati na rin ang dinamika ng kanilang pagbabago.

Ang mga resulta ng pagsusuri ay iginuhit sa anyo ng mga hiwalay na dokumento, na nagpapakilala sa iba't ibang aspeto ng negosyo at ang iminungkahing proyekto.

Sa susunod na yugto, ang isang pagtatasa ng proyekto ay nabuo ayon sa aytem

b) Upang isaalang-alang ang mga interes ng administrasyon, isang karagdagang pangkat ng mga tagapagpahiwatig (fh) at kundisyon (χh) ay ipinakilala, kung saan h = 1,H. Ang mga tagapagpahiwatig na ito ay maaaring kalkulahin o ipakita ng negosyo. Kung ang isang negosyo ay hindi nakakatugon sa pamantayan, ito ay hindi kasama sa pangkat ng mga potensyal na na-kredito.

a) mga opsyon para sa pagtukoy ng rating ng mga proyekto sa pamumuhunan ay nabuo, na nakatuon sa pagsusuri sa loob ng isang partikular na lugar, halimbawa, sa larangan ng produksyon ng pagkain, atbp. Ang mga pangunahing pagkakaiba sa pagitan ng mga opsyon, o tawagin natin silang mga sitwasyon, ay iyon:

Sa mga pangkat ng mga kamag-anak na tagapagpahiwatig at coefficient, ang mga hiwalay na elemento ay nakikilala, na isasaalang-alang kapag tinutukoy ang rating ng proyekto sa sitwasyong ito, i.e.

kung saan ang ζ ay ang numero ng senaryo;

Para sa mga piling indicator at coefficient, ang mga timbang ay nakatakda na nagpapakilala sa epekto ng indicator na ito sa rating sa pangkat na ito, i.e. ayon sa pagkakabanggit

Gayundin, ang mga timbang ay tinutukoy para sa mga pangkat ng mga tagapagpahiwatig at mga coefficient na lumalahok sa rating, i.e. , kung saan ang d ζ ay ang bilang ng pangkat, at ang D ζ ay ang kabuuang bilang ng mga pangkat na kalahok sa pagsusuri;

Ang mga timbang ay mas mababa sa 1, ang kabuuan ng mga timbang ng bawat hanay sa buong sample ay 1.

b) ang bersyon ng pinakamahusay na negosyo para sa pangkat ng mga nasuri na proyekto ay nabuo. Ang bersyon ng pinakamahusay na negosyo ay isang hanay ng mga dating napiling tagapagpahiwatig na may pinakamahusay na mga halaga sa buong hanay, i.e. ang mga halaga ng mga tagapagpahiwatig na ito ay maaaring kabilang sa iba't ibang mga negosyo. Ang bersyon na ito ay hindi nauugnay sa isang tunay na bagay at ginagamit para sa mga layunin ng pag-rate. Ang lahat ng karagdagang ratio para sa pagtatasa ng rating ay ibinibigay lamang para sa mga coefficient. Ang mga katulad na formula ay itinayo para sa mga parameter at fh .

Kaya, isang hanay ng mga tagapagpahiwatig ay nabuo , kung saan , kung mas mataas , mas mabuti, at kung hindi man. Narito ang bilang ng enterprise sa listahan, at ang halaga ng coefficient para sa s-th enterprise.

kung saan , kung ang paglago ng koepisyent ay nagpapakilala sa pagpapabuti sa kalagayang pinansyal ng negosyo at

e) kung mas mataas ang R ζ s, mas mataas ang rating ng s-th enterprise sa ζ-th assessment scenario.

Sa pamamagitan ng pag-normalize (R ζ s) sa pamamagitan ng , posibleng ayusin ang mga negosyo sa pataas o pababang pagkakasunud-sunod ng kanilang rating. Ang rating ayon sa mga indicator , at fh ay maaaring isagawa nang hiwalay.

Konklusyon

Ang ipinakita na pamamaraan ay nagbibigay-daan, sa proseso ng paggawa ng desisyon sa paglalaan ng mga pautang, upang i-ranggo ang mga proyekto sa pamumuhunan hindi lamang sa pamamagitan ng mga tagapagpahiwatig ng pananalapi, ngunit isinasaalang-alang din ang mga priyoridad ng istruktura ng organisasyong pang-administratibo na hindi direktang nauugnay sa kondisyon sa pananalapi ng ang organisasyong kalahok sa kompetisyon.

Kaya, ang sistema ng impormasyon, kapag ipinatupad, ay magiging isang makapangyarihang kasangkapan na nagsasama ng mga epektibong mekanismo ng suporta sa pagpapasya sa larangan ng aktibidad ng pamumuhunan at naglalayong magbigay ng pagsusuri ng parehong kalagayan sa pananalapi ng mga negosyo at mga proyekto sa pamumuhunan na isinumite para sa kumpetisyon.

Bibliographic na link

Klevtsov S.I., Klevtsova A.B. MODELO NG SISTEMA NG IMPORMASYON PARA SA PAGSUSURI NG MGA PROYEKTO NG INVESTMENT PARA SA MGA ISTRUKTURANG ADMINISTRATIB // Pangunahing Pananaliksik. - 2016. - Hindi. 12-1. - P. 58-61;
URL: http://fundamental-research.ru/ru/article/view?id=41046 (petsa ng access: 04/26/2019). Dinadala namin sa iyong pansin ang mga journal na inilathala ng publishing house na "Academy of Natural History"

Anumang negosyo, kompanya, organisasyon ay may sariling istraktura ng organisasyon. Ang istrukturang ito ay multidimensional at maaaring nahahati sa ilang magkakaugnay at magkakaugnay na mga substructure, na maaaring ituring bilang mga independiyenteng istruktura, istraktura ng pamamahala ng produksyon, istraktura ng tauhan, marketing, pinansyal, pang-ekonomiya, mga istruktura ng impormasyon.

Lahat sila ay nasa malapit na pakikipag-ugnayan at ito ang kanilang kumbinasyon na lilikha ng istraktura ng organisasyon ng negosyo. Ang isa sa mga pinakamahalagang lugar sa istrukturang ito ay inookupahan ng sistema ng impormasyon. Sa prinsipyo, ang anumang sistema ng pamamahala ay maaaring kinakatawan bilang isang sistema ng impormasyon na may iba't ibang mga daloy ng impormasyon sa anyo ng mga dokumento, mga order, mga kahilingan na tinutugunan sa loob ng organisasyon, papalabas o papasok mula sa panlabas na kapaligiran.

Sa nakalipas na mga dekada, ang dami ng impormasyon sa lipunan sa pangkalahatan at ang impormasyong ginagamit sa negosyo sa partikular ay tumaas nang husto. Ito ay dahil sa lumalagong bilis ng pag-unlad ng agham at teknolohiya, ang paglitaw ng mga bagong teknolohiya, at ang kanilang mabilis na turnover. Sa mga merkado ng mga hilaw na materyales at produkto, nabuo ang mga kondisyon na nangangailangan ng patuloy na pagsubaybay sa estado ng merkado, mga pagbabago nito, at mga uso sa pag-unlad nito; Ang lahat ng ito ay humahantong sa katotohanan na sa modernong mga kondisyon, ang mga pinuno ng negosyo ay kailangang harapin ang napakaraming impormasyon, mabilis itong nagbabago na madalas na nagiging imposibleng iproseso nang manu-mano. Bilang karagdagan, sa malalaking negosyo na may malaking turnover ng mga produkto at bilang ng mga empleyado, kailangang isaalang-alang at kontrolin ang isang malaking dami ng pinansyal, produksyon, tauhan, pagbili at marketing, impormasyon sa marketing. Sa pagsasaalang-alang na ito, mayroong pangangailangan na lumikha ng mga awtomatikong sistema para sa pagkolekta, pagproseso, pag-iimbak ng impormasyon. Dapat nilang pangasiwaan ang proseso ng pagtatrabaho sa impormasyong nagpapalipat-lipat sa negosyo.

Ang pagdating ng teknolohiya ng computer ay ginagawang posible na lumikha ng mga naturang sistema. Sa modernong mga negosyo, halos lahat ng trabaho na may impormasyon ay awtomatiko, may mga espesyal na programa na nagbibigay-daan sa iyo upang mapanatili ang mga talaan ng accounting, daloy ng trabaho, pananaliksik sa marketing, pagtataya at madiskarteng pagpaplano, at marami pang iba sa isang computer. Ngunit bilang karagdagan sa automation, ang tanong ng mahusay na pagbuo ng istraktura ng isang sistema ng impormasyon, pag-optimize ng mga daloy ng impormasyon, pag-screen ng hindi kinakailangang impormasyon, pagpapasimple sa paghahanap at pagkuha ng kinakailangang impormasyon ay mananatiling may kaugnayan. Ang pagkakaroon ng isang mahusay na itinatag na awtomatikong sistema ng impormasyon sa enterprise ay lubos na nagpapadali sa proseso ng pamamahala ng negosyo. Pinapayagan ka nitong mangolekta, mag-uri-uriin, magproseso ng kinakailangang impormasyon sa oras at gumawa ng tamang desisyon. Minsan, ang isang desisyon na kinuha sa maling oras, dahil sa kakulangan o hindi napapanahong pagtanggap ng impormasyon, ay maaaring humantong sa pagkamatay ng negosyo. Samakatuwid, kinakailangang bigyang-pansin ang paglikha at pagpapanatili ng epektibong paggana ng sistema ng impormasyon ng negosyo.

Ang mga pangunahing konsepto na ginamit sa teorya ng mga sistema ng impormasyon at mga awtomatikong sistema ng impormasyon ay impormasyon, sistema, sistema ng pagkuha ng impormasyon, awtomatikong sistema ng kontrol, awtomatikong lugar ng trabaho. Impormasyon - mula sa lat. Paglilinaw ng impormasyon, paglalahad ng impormasyon na orihinal na ipinadala ng mga tao nang pasalita, nakasulat o sa anumang iba pang paraan mula noong kalagitnaan ng ika-20 siglo, isang pangkalahatang konseptong pang-agham na kinabibilangan ng pagpapalitan ng impormasyon sa pagitan ng mga tao, isang tao at isang automat, isang automat at isang automat. Ang sistema ng grupo ay isang hanay ng mga nakaayos at magkakaugnay na mga elemento sa isang tiyak na paraan na may matatag na pagkakaisa, panloob na integridad, at awtonomiya ng pag-iral sa panlabas na kapaligiran. Ang sistema ng pagkuha ng impormasyon ng IPS ay isang hanay ng mga tool para sa pag-iimbak, paghahanap at pag-isyu ng kinakailangang impormasyon kapag hiniling, ang paghahanap para sa paglalagay ng impormasyon sa IPS ay isinasagawa nang manu-mano o gamit ang isang computer ayon sa ilang mga patakaran at alinsunod sa tinanggap wika ng impormasyon. Ang automated control system ACS ay isang hanay ng mga mathematical na pamamaraan, computer hardware, komunikasyon at mga organisasyonal na complex na nagbibigay ng makatwirang pamamahala ng isang kumplikadong object ng proseso alinsunod sa isang ibinigay na layunin. Automated workstation AWS workplace ng operator, dispatcher, designer, technologist, na nilagyan ng teknolohiya ng computer upang i-automate ang proseso ng pagproseso at pagpapakita ng impormasyong kinakailangan upang makumpleto ang gawain sa produksyon. Kamakailan lamang, ang papel ng impormasyon na ginagamit sa mga negosyo, sa iba't ibang mga organisasyon ay tumaas. Masasabi nating isa ito sa mga mapagkukunang ginagamit sa mga aktibidad ng negosyo. Gayunpaman, ang mga mapagkukunan ng impormasyon ay naiiba sa kanilang mga katangian mula sa mga mapagkukunan sa tradisyonal na konsepto ng materyal, enerhiya, teknolohikal.

Ang iba't ibang mga mananaliksik ay nagmungkahi ng iba't ibang paraan ng pag-uuri ng suporta sa impormasyon. Kaya, mula sa punto ng view ng pakikipag-ugnayan ng negosyo ng organisasyon sa kapaligiran, kaugalian na hatiin ang lahat ng impormasyon, pangunahin ang dokumentaryo, sa papasok at papalabas. Depende sa panahon ng pag-iimbak, ang isang pagkakaiba ay ginawa sa pagitan ng isang pare-pareho, isang kondisyon na pare-pareho, kung minsan ay na-update, at isang variable na regular na nagbabago. Ang impormasyon ay nahahati din ayon sa mga antas ng pamamahala ng pabrika, intra-factory, workshop, intra-shop. Sa pamamagitan ng likas na katangian ng aktibidad, disenyo at teknolohikal. accounting, accounting at pag-uulat, pagpaplano, marketing, tauhan, produksyon. Sa mga automated system, ang suporta sa impormasyon ay nahahati sa machine-based sa computer memory at off-machine. Ang mga klasipikasyong ito sa iba't ibang kumbinasyon ay ginagamit kapag nag-i-index ng iba't ibang mga dokumento ng mga liham, mga order, mga tagubilin at iba pang mga dokumento na ginagamit ng mga negosyo at organisasyon sa kanilang mga praktikal na aktibidad. Kasaysayan ng pag-unlad. Sa kasaysayan ng paglikha ng mga automated na sistema ng impormasyon, dalawang direksyon ang binuo na medyo independyente: 1. pagbuo ng mga awtomatikong sistema ng impormasyon ng AIS bilang mga automated na sistema ng kontrol para sa mga automated na sistema ng kontrol 2. pagbuo ng mga automated na sistema ng pang-agham at teknikal na impormasyon ASNTI. Ang paggawa sa kanilang paglikha ay nagsimula halos sabay-sabay noong dekada 60.

Ang unang direksyon - ang pag-unlad ng AIS at ACS - ay pinasimulan ng siyentipiko at teknolohikal na pag-unlad at ang mga problema ng pamamahala ng organisasyon na lumitaw na may kaugnayan sa pagtaas ng dami ng impormasyon, mga paghihirap sa manu-manong pagproseso nito. Ang dayuhang kasanayan ay sumunod sa landas ng pagbuo ng hiwalay na mga pamamaraan ng software, halimbawa, para sa accounting, accounting para sa mga materyal na asset, at ang pangunahing gawain ay isinasagawa sa direksyon ng pagsasaliksik at pagpapabuti ng mga kakayahan ng teknolohiya ng computer, pagbuo ng mga tool na nagbibigay ng pinaka makatwirang organisasyon ng mga array ng impormasyon, isang user-friendly na interface, at pagtaas ng memorya ng computer . Sa ating bansa, ang problema sa pagbibigay ng impormasyon sa mga managerial na empleyado ay agad na iniharap sa sistematikong paraan. Ang isang pag-uuri ng mga awtomatikong sistema ng kontrol ay binuo, kung saan, una sa lahat, ang mga awtomatikong sistema ng kontrol ng iba't ibang antas ng sistema ng pamamahala ay nakikilala - para sa antas ng mga negosyo at organisasyon, sektoral, republikano at rehiyonal, at isang pambansang awtomatikong sistema.

Katulad nito, sa antas ng mga negosyo, at lalo na sa mga nilikha noong 70s. ng mga asosasyon ng pananaliksik at produksiyon ng mga NPO, sa istruktura ng mga awtomatikong sistema ng kontrol o pinagsamang mga awtomatikong sistema ng kontrol ng mga asosasyon, ang mga antas ng stratum ay nakikilala - ang mga awtomatikong sistema ng kontrol ng isang asosasyon, mga awtomatikong sistema ng kontrol ng mga negosyo at mga organisasyon ng mga institusyong pananaliksik, mga bureaus ng disenyo na kasama sa Mga NPO, automated control system ng produksyon, workshop complex, automated control system ng mga workshop at site. Sa antas ng mga workshop at mga seksyon, ang mga awtomatikong sistema ng kontrol ay unang nahahati sa mga awtomatikong sistema ng kontrol para sa mga teknolohikal na proseso, mga awtomatikong sistema ng kontrol para sa teknikal at teknolohikal na paghahanda ng produksyon, at mga awtomatikong sistema ng kontrol para sa pag-aayos ng produksyon. Nasuspinde ang trabaho sa paglikha ng sentralisadong nationwide ACS at ASNTI dahil sa pagbabago ng 19-91. Gayunpaman, sa paglipat sa isang ekonomiya ng merkado, sa isang tuntunin ng batas, ang papel ng isa pang mahalagang uri ng impormasyon ay tumataas - ligal at regulasyon, pamamaraan, kinokontrol ang mga aktibidad ng mga negosyo habang binibigyan sila ng higit na kalayaan at binabawasan ang dokumentasyon ng organisasyon at administratibo. ng kasalukuyang mga order at order, auditing command at administrative management method. Sa hinaharap, habang ang mga negosyo at ang kanilang mga awtomatikong sistema ng kontrol ay nabuo, lalo na sa konteksto ng pagbibigay ng higit na kalayaan sa mga industriya at workshop at ang muling pamamahagi ng mga tungkulin sa pamamahala sa pagitan ng pangangasiwa ng negosyo at mga tagapamahala ng produksiyon at pagawaan, naging mas maginhawa din na kumatawan sa istraktura. ng mga automated control system sa anyo ng isang multi-level, stratified one. Ang paghahati ng automated control system sa functional at supporting parts, at ang huli - sa information support, teknikal, organisasyonal, software at iba pang uri ng suporta - naging posible na isama ang mga espesyalista sa mga lugar na ito upang linawin ang mga kaukulang uri ng suporta. Ang diskarte na ito sa pag-aayos ng pagbuo ng mga awtomatikong sistema ng kontrol ay nakatulong upang makayanan ang pagiging kumplikado ng system at mapabilis ang pagbuo ng mga awtomatikong sistema ng kontrol sa pamamagitan ng magkatulad na gawain sa pagsusuri at pagpili ng istraktura ng ilang mga uri ng suporta. Gayunpaman, kung ang mga hiwalay na proyekto ay binuo, pagkatapos pagkatapos ng pag-unlad mayroong isang medyo mahirap na gawain ng kanilang koordinasyon, pagkakabit ng mga tinatanggap na istruktura ng mga ganitong uri ng suporta, ang mga pamantayan na isinasaalang-alang sa kanilang pag-unlad, atbp. Samakatuwid, sa isang tiyak na yugto sa pag-unlad ng trabaho sa paglikha ng mga awtomatikong sistema ng kontrol, isang espesyal na prinsipyo ng pagkakaisa ng suporta sa impormasyon, hardware at software, bilang mga pangunahing uri ng suporta, ay nabuo kahit na. Sa kasalukuyan, mayroong isang malaking bilang ng mga handa na produkto ng software. Samakatuwid, kapag lumilikha ng isang awtomatikong sistema sa isang negosyo, hindi na kailangang makisali sa independiyenteng pagbuo ng software. Pagsusuri ng pagiging epektibo ng mga mapagkukunan ng impormasyon. Sa iba't ibang uri at anyo ng mga mapagkukunan ng impormasyon, ang problema ng kanilang pagsusuri ay tila halos hindi malulutas.

Sa katunayan, kung paano ihambing ang iba't ibang uri ng impormasyon Anong impormasyon ang dapat ibigay sa mga tagapamahala, tagapamahala, siyentipiko, taga-disenyo, technologist at iba pang empleyado ng negosyo Paano matukoy kung aling imbakan at pagkuha ng impormasyon ang mas mahalagang i-automate sa unang lugar Paano matukoy ang kahusayan ng paggamit ng mga mapagkukunan ng impormasyon sa pangkalahatan.

Ang pagtaas sa dami ng produksyon, ang dalas ng pag-update ng hanay ng mga produkto at teknolohiya, ang pagiging kumplikado ng pamamahala sa mabilis na umuunlad na mga rehiyon, mga sistema ng produksyon, at ang sektor na hindi pang-industriya ay humantong sa pagtaas at pagiging kumplikado ng mga daloy ng impormasyon. Sa ilalim ng mga kundisyong ito, naging kinakailangan upang suriin ang mga gastos ng mga mapagkukunan ng impormasyon, upang matukoy ang kanilang kontribusyon sa kahusayan ng paggana ng produksyon, pang-edukasyon at iba pang mga sistema.

Sinubukan ng iba't ibang agham ng impormasyon na sukatin ito. Upang masuri ang kasiyahan ng mga pangangailangan ng impormasyon sa teorya ng pang-agham at teknikal na impormasyon, ipinakilala ang mga sukat ng kaugnayan at kaugnayan. Ang kaugnayan ay tumutukoy sa pagsunod ng output sa kahilingan; under pertinence - ang pagsusulatan ng output sa mga pangangailangan ng user. Sa pagsasagawa, kapag tinatasa ang kahalagahan ng mga arrays ng impormasyon ng mga awtomatikong sistema ng kontrol, kung minsan ay ginagamit ang mga hindi direktang pagtatantya, tulad ng dalas ng pag-access sa array, ang bilang ng mga dokumentong inihanda batay sa batayan nito, ang bilang ng mga departamentong naseserbisyuhan, ang dami ng mga arrays, atbp. di-tuwirang dami ng mga katangian. Para sa paglutas ng mga partikular na problema, ang mga itinuturing na pamamaraan ng pagsusuri ng impormasyon kung minsan ay nagbibigay ng kasiya-siyang resulta. Gayunpaman, sa kaso ng pagsusuri sa buong hanay ng mga mapagkukunan ng impormasyon, ito ay kanais-nais na maihambing ang iba't ibang uri ng impormasyon, upang makakuha, kung hindi isang solong sukatan, pagkatapos ay hindi bababa sa maihahambing na mga pagtatantya ng pagiging kapaki-pakinabang ng iba't ibang mga mapagkukunan ng impormasyon para sa isang produksyon o iba pang sistema upang maglaan ng mga pondo para sa suporta sa impormasyon nang mas makatwiran. Halos hindi makatotohanang ilapat ang tradisyunal na sukatan ng gastos upang masuri ang pagiging epektibo ng mga mapagkukunan ng impormasyon. Posible, siyempre, upang suriin ang kahusayan sa ekonomiya at panahon ng pagbabayad ng automation ng imbakan at pagkuha ng ilang mga uri ng suporta sa impormasyon. Gayunpaman, sa batayan ng mga pagtatantya na ito, hindi maaaring hatulan ng isa ang kahalagahan ng impormasyon para sa pagpapabuti ng produksyon o mga sistema ng pamamahala ng organisasyon, ang pagiging kapaki-pakinabang ng impormasyon para sa siyentipikong pananaliksik, at mga solusyon sa disenyo. Batay sa pangunahing ideya ng paggamit ng mga representasyon ng system sa pag-aayos ng mga kumplikadong eksaminasyon, maaaring itakda ng isa ang gawain ng pagsusuri ng pagiging epektibo ng mga mapagkukunan ng impormasyon, bilang ang gawain ng pagtatasa ng antas ng kanilang impluwensya sa pagpapatupad ng mga circuits ng system.

Sa ganitong pahayag ng problema, kinakailangan upang malutas ang dalawang problema: 1 upang mabuo ang istraktura ng mga layunin ng mga pangunahing direksyon ng pag-unlad ng sistema na tumutukoy sa aktibidad nito sa kaukulang panahon ng pagkakaroon, 2 upang pumili ng isang diskarte sa pagtatasa ng antas ng impluwensya ng impormasyon sa pagkamit ng mga layunin. Upang matiyak ang pagkakumpleto ng pagsusuri ng mga aktibidad ng negosyo ng samahan, kapag bumubuo ng istraktura ng mga layunin, kinakailangan na mag-aplay ng mga pamamaraan para sa pag-istruktura ng mga layunin at pag-andar, ang pagpili kung saan ay tinutukoy ng naunang binuo na konsepto ng pag-unlad nito. Upang masuri ang antas ng pagsunod sa layunin, maaaring gamitin ang isang probabilistikong panukala, ibig sabihin, upang tantiyahin ang posibilidad na ang isang ibinigay na mapagkukunan ng impormasyon ay gagamitin upang makamit ang isang subgoal. Ang ganitong mga pagtatantya ay maaaring makuha bilang mga pagtatantya ng kamag-anak na kahalagahan, ang kaugnay na kontribusyon ng mapagkukunan ng impormasyon sa pagpapatupad ng kaukulang subgoal, ngunit ito ay nagpapataas ng problema na ang parehong impormasyon ay maaaring makaapekto sa higit sa isang subgoal. Posibleng gumamit ng sukatan ng impormasyon ng antas ng impluwensya ng mapagkukunan sa pagpapatupad ng mga subgoal, na nagbibigay-daan sa pagsasaalang-alang hindi lamang sa posibilidad na makamit ang subgoal p, kundi pati na rin ang posibilidad q na ang impormasyong ito ay gagamitin ng gumagawa ng desisyon sa pagpapatupad ng sublayunin. Ang pagtatasa ng potensyal ng impormasyon H ay mas maginhawa kaysa sa mga pagtatasa ng kamag-anak na kahalagahan, maaari silang mabuod, maaari mong isaalang-alang hindi lamang p kundi pati na rin q, ang konsepto ng potensyal ng impormasyon ay mas mahusay na nakikita ng mga empleyado ng managerial. Sa totoong mga kondisyon, maaaring gamitin ang mas kumplikadong mga pamamaraan.

Bakit hindi? Ito ay isang magandang halimbawa. Ang isang proyekto ay isang proyekto sa lahat ng dako: plus o minus ang parehong mga yugto, ang parehong pamamaraan ng pamamahala, daloy ng dokumento, pamamahala sa peligro, kontrol sa kalidad, at iba pa. Saanman mayroong mga kinakailangan para sa kagamitan, at para sa mga lugar, at para sa software. Tanong mo, ano ang maaaring maging mga kinakailangan para sa mga lugar sa Information System? Napakasimple: ang lokasyon ng mga lugar ng trabaho ng mga operator, mga server - pareho silang mangangailangan ng air conditioning. Narito ang mga kinakailangan para sa lugar. At halos walang sinuman ngayon ang nagdududa kung ang ospital ay nangangailangan ng software. Kung nais mong makasabay sa mga panahon, haharapin mo ang gawain ng paglikha ng isang awtomatikong institusyong medikal na may mga elektronikong medikal na rekord, kung saan ang mga doktor ay gumagawa ng mga pagsusuri gamit ang mga tablet, at, halimbawa, ang mga nars ay minarkahan ang hugasan na banyo hindi sa isang dahon, ngunit sa ang telepono. Magkakaroon ng maraming mga kinakailangan sa software sa kasong ito. At sa sandaling kailanganin ang software, kakailanganing mag-install ng mga server, ilagay ang administrator at mga operator sa isang lugar. Ang lahat ay magkakaugnay.

Pinili namin ang construction project dahil ito ang pinakamadaling paraan upang ipakita kung paano magdisenyo ng IC. Ang sistema ng impormasyon ay nakatago sa isang lugar sa loob, hindi namin ito nakikita, ngunit ang mga dingding ay narito sa harap namin: baluktot at pahilig, may mga dead-end na corridors, dahil ang proyekto ay ginawa sa tuhod, at kahit na ang customer ay nagbago ng kanyang mga kinakailangan ng isang daang beses sa kurso ng dula.

Program code sa loob (ngunit walang nakakakita nito)

Ano ang kinalaman ng ospital dito kung bumuo tayo ng software?

Ngunit hindi, mahal na mga developer, manager, analyst, tester.

Hindi ka nagde-develop ng software... Kunin natin ang Android, software ito. At kung, halimbawa, mayroon kang isang accounting system sa harap mo, kung gayon nakikipag-ugnayan ka na hindi lamang sa software, ngunit sa isang INFORMATION SYSTEM.

Ang pagkakaiba ay halata. Kung bumili ka ng telepono, ang lahat ay simple: i-on ito, magsisimula ang berdeng tao (Android), gamitin ito. At kung bumili ka ng isang kahon na may software ng accounting, kung gayon ay malinaw na ang mga server ay kailangan na ngayon, kailangan mong mag-set up ng isang network, i-configure ang mga workstation, sanayin ang mga empleyado, isama ang system sa natitirang bahagi ng IS ng enterprise, at i-drive ang system nasa test mode. Oo, at kailangan pa rin ng mga accountant na kahit papaano ay mahikayat na lumipat sa bagong software, hindi lahat ng mga ito ay handa na para sa mga pagbabago. Sa pangkalahatan, sa anumang proyekto sa IT, 10-20% ay IT, at lahat ng iba pa ay mga pang-organisasyon at administratibong hakbang, at napakahigpit, gawaing alahas sa mga tauhan.

Sistema ng impormasyon (software lang ba ito?)

At, sa wakas, alalahanin natin ang kahulugan ng sistema mula sa malayong 90s, na walang kinansela:

Automated system: isang sistema na binubuo mula sa mga tauhan At isang hanay ng mga paraan para sa pag-automate ng mga aktibidad nito, na nagpapatupad ng teknolohiya ng impormasyon para sa pagganap ng mga naitatag na function.

GOST 34.003-90. Teknolohiya ng impormasyon. Set ng mga pamantayan para sa mga automated system. Mga awtomatikong sistema. Mga Tuntunin at Kahulugan.

Iyon ay, ang IP sa unang lugar ay mga tao, kasama ang teknolohiya na tumutulong sa pag-automate ng kanilang mga aktibidad, at hindi kabaliktaran.

Paano magdisenyo ng isang ospital

Isipin na ikaw ay isang construction organization, isang customer ang lumapit sa iyo at humiling na magtayo ng ospital sa ganoon at ganoong lugar. Tatakbo ka ba agad para maglagay ng mga brick o ...? Kung titingnan mo kung paano madalas na nilikha ang Mga Sistema ng Impormasyon, kung gayon ito ay totoo: ang mga gumaganap ay agad na nagsimulang "makagambala sa kongkreto at bumili ng mga double-glazed na bintana." Tulad ng, hindi ito gagana sa ganoong paraan - bubuo kaming muli! Tayo ay muling bubuo hanggang sa makamit natin ang ninanais na resulta.

Gayunpaman, kung ikaw ay isang seryosong organisasyon, pagkatapos ay mag-alok muna sa customer ng isang construction PROJECT. Sumasang-ayon ka ba? Bakit hindi sa Information System? Marahil ito ay hindi tungkol sa mga pagkakaiba sa pagitan ng konstruksiyon at pagbuo ng software, ngunit sa kaso ng parehong ospital, una silang nag-iisip ng maraming, nagpaplano, at pagkatapos ay nagtatayo, habang ang software ay unang binuo at pagkatapos ay iniisip nila? Hindi ba iyan ang dahilan kung bakit marami kang naririnig tungkol sa mga baluktot na programmer, ngunit wala tungkol sa parehong mga guest na manggagawa sa isang lugar ng konstruksiyon? Gumagawa ang mga tagabuo sa isang proyekto, hindi katulad ng mga developer.

Kung walang project, laging ganito, kahit hindi mo nakikita

Isaalang-alang natin ngayon ang proseso ng disenyo nang mas detalyado. Ito ay may ilang mga yugto. Bakit kailangan mong dumaan sa ilang yugto, bakit hindi mo gawin ito nang sabay-sabay? Para sa kalinawan, magbibigay ako ng isang halimbawa ng paaralan ... Ilang taon na nilang pinag-aaralan ang pagpapatakbo ng multiplikasyon sa paaralan? Sasabihin mo - isa o dalawang buwan, at sa panimula ay mali ka. Oo, paano i-multiply ang 5 sa 6, pumasa sa isang linggo. Para sa isang tiyak na oras, natutunan nila ang talahanayan ng pagpaparami. At gaano nila pinag-aaralan ang multiplikasyon ng mga fraction, mga numero na may degree, logarithms, mga expression sa mga bracket, kumplikadong mga numero, pagtaas sa isang kapangyarihan? Halos lahat ng school years! Lumalabas na nag-aaral tayo ng parehong multiplikasyon bawat taon mula sa iba't ibang anggulo.
ami.

Bakit hindi ito itinuro sa unang baitang?

Kaya, ang anumang proseso ng parehong pag-aaral at pagdidisenyo ay paikot. Una, nakuha namin ang mga pangkalahatang konsepto ng mga numero, pagkatapos ay natutunan namin kung paano gawin ang pinakasimpleng mga aksyon sa kanila, pagkatapos ay natutunan namin ang tungkol sa mga fraction at natutunan kung paano magtrabaho sa kanila, at iba pa.

Una, naunawaan namin kung anong problema ang dapat naming lutasin sa tulong ng Information System. Pagkatapos ay natukoy namin ang hanay ng mga gawain na malulutas, naunawaan kung ANO ang dapat gawin ng system, kung anong mga aksyon ang dapat gawin ng mga tauhan. Pagkatapos ay natukoy namin kung PAANO dapat gawin ng system ang naunang tinukoy na mga gawain. Maaari mong laktawan ang mga yugtong ito, kailangan mo lang bumalik at gawing muli ang lahat: ang pagsukat ng pitong beses at ang pagputol ng isang beses ay mas mabilis kaysa sa kabaligtaran, at kukuha ito ng mas kaunting materyal.

Kumuha tayo ng isa pang halimbawa. Ikaw ay nasa tuktok ng isang bundok na nakatingin sa ibaba sa pamamagitan ng makapangyarihang mga binocular at sinusubukang i-mapa ang isang detalyadong ruta ng pagbaba. Sa pamamagitan ng eyepieces, makikita mo ang bawat maliit na bato sa landas, bawat lusak. Ngunit kung ang landas na ito ay tama at kung ito ay humahantong sa tuktok ay hindi nakikita sa pamamagitan ng mga binocular: walang pangkalahatang plano. Ang isang matalinong umaakyat ay unang magbabalangkas sa mga landas ng pagbaba sa mata, at pagkatapos ay susuriin ang mga ito sa ilalim ng malakas na paglaki. Sa sandaling mag-plunge ka sa detalye, mawawala mo ang pangkalahatang view ng proyekto. Ang pagkuha kaagad ng teleskopyo, perpektong ilalarawan mo ang 10 mga function, habang nakakalimutan ang tungkol sa 40 iba pa, hindi binabanggit ang mga ito sa lahat.

Ito ay nakikita nang maayos, ngunit isang maliit na bahagi lamang

Ang pagiging kumplikado ng phased na disenyo ay na sa simula ng proseso kailangan mong patakbuhin ang mga abstract na konsepto. Kaya gusto mong "pakiramdam" ang isang bagay na handa, at hindi pag-usapan ang ilang mga kinakailangan, pag-andar, gawain, proseso. Ang pagguhit kaagad ng user interface ay mas madali, ngunit mas madaling makaligtaan ang hindi bababa sa kalahati ng mga kinakailangan. Kung gagawa ka muna ng isang detalyadong listahan ng mga operasyon na dapat gawin ng user kapag nagtatrabaho sa isang partikular na form ng screen, ang taga-disenyo ay kailangan lamang gumuhit, at hindi magpantasya, gaya ng madalas na nangyayari.

Ngayon, sa wakas ay lumipat tayo sa mga yugto ng disenyo.

1. Pagguhit ng pangkalahatang mga kinakailangan

Kaya sabihin nating ikaw ay isang taga-disenyo. May customer na lumapit sa iyo, "ipinadala" ng mga responsableng tagabuo. Ang customer, siyempre, ay humihiling sa iyo na bumuo ng isang proyekto sa ospital. Tumakbo ka sa drawing board at... Buweno, ito ay sinaunang - simulan ang ArchiCAD at gumuhit.

Pero syempre hindi naman tungkol sayo. Ikaw ay isang propesyonal at magsimulang magtanong ng isang grupo ng mga "hangal" na mga tanong. At ang pinakamahalaga sa kanila - kung bakit kailangan mong magtayo ng ospital. Ano ang layunin ng gusali. Kung ang layunin ay hindi malinaw, pagkatapos ay hindi mo masasagot ang tanong, kung ito ay isang malaking ospital o isang maliit, kung ano ang profile, kung ano ang kagamitan. Sa kasamaang palad, ang mga customer ay madalas na nagsasabi ng maraming mga kagiliw-giliw na bagay, maliban sa pangunahing bagay - kung ano ang kanilang layunin. Ito ang kailangang "hugot" dito sa unang lugar. At dapat mong tanungin ang tanong. Ang customer mismo ay hindi isang espesyalista, mayroon siyang ideya, at dito nakikita niyang natupad ang kanyang tungkulin. Hindi niya maintindihan kung anong landas ang dapat tahakin upang maisakatuparan ang kanyang ideya. Bilang isang patakaran, ang customer ay naghihintay para sa isang magandang lumang himala - na dumating sa dalampasigan, naghagis ng lambat (magbayad ng pera), manghuli ng isda, at matutupad nito ang kanyang pagnanais ... At ito ay nangyayari tulad ng sa isang biro tungkol sa isang mayamang tao na, nang makahuli ng goldpis, humiling na tuparin ang isang hiling: " Gusto kong makuha ang lahat!" - "Walang problema," sagot ng isda, "nasa iyo ang lahat ..."

Upang maunawaan ang layunin ng proyekto, hindi sapat na gumawa ng isang pares ng mga pangungusap na may karaniwang hanay ng mga parirala. Ang layunin ng proyekto ay karaniwang tinutukoy batay sa pagsalungat: inilalarawan nila ang umiiral na modelo ng impormasyon (halimbawa, ang mga tao ay nakaupo sa archive at nag-uuri sa mga papel), pagkatapos ay ang mga pagkukulang nito (dahil sa kakulangan ng automation, 10 tao ang kasangkot sa archive, na malinaw na kalabisan, hindi makukuha ng ibang mga departamento ng ilang linggo mula sa archive ang impormasyong kailangan nila, atbp.) at nag-aalok ng solusyon (ipakilala ang software na magpapahintulot sa isang bilang ng mga operasyon na maisagawa sa isang awtomatikong mode, ang mga operasyon ay dapat na nakalista). Kung ang isang ganap na bagong uri ng serbisyo ay ipinakilala sa merkado, pagkatapos ay kinakailangan na pag-aralan ang umiiral na merkado at "punahin" ang mga tool na magagamit doon, pagkatapos ay mag-alok ng isang solusyon.

Bilang karagdagan, sa yugtong ito, kinakailangan upang matukoy kung anong mga ligal na kinakailangan ang dapat isaalang-alang, kung paano legal na gawing pormal ang ilang mga operasyon, kung paano pagkakakitaan ang bagong serbisyo, kung paano ito pinaplano na pumasok sa merkado, kung paano mag-interes sa panlabas. mga kalahok sa bagong sistema.

Sa madaling salita, kailangan mong lumikha ng isang modelo ng negosyo. Sa isang banda, ito ay, parang, hindi ang gawain ng mga developer, ngunit, sa kabilang banda, nang walang malinaw na kahulugan ng layunin at mga pamamaraan para sa pagpapatupad nito, hindi malinaw kung anong mga gawain ang dapat lutasin ng system. At kung ang customer mismo ay hindi pa malinaw na nabalangkas kung ano ang kailangan niya, malamang na hindi siya masiyahan sa kahit ilang resulta.

2. Pagpili ng konsepto ng system

Sa yugtong ito, kinakailangan na pumili ng mga pangkalahatang teknikal na solusyon kung saan maaaring matugunan ang mga kinakailangan na iginuhit sa nakaraang yugto. Ito ba ay isang web application o native, makapal na kliyente o manipis, sentralisadong database o distributed, relational DBMS o noSQL, monolith o microservices, Java o Python. Kadalasan ang mga isyung ito ay nakalimutan na talakayin sa oras, at pagkatapos ay lumalabas na ang isa sa mga programmer ay nakapag-iisa na pumili ng isang tiyak na tool, at sa huli ay hindi pinapayagan ng desisyon na ito na makamit ang layunin.

3. Pagbuo ng Mga Tuntunin ng Sanggunian

Gumawa kami ng mga pangkalahatang kinakailangan para sa ospital, pinili ang konsepto. "Well," sasabihin ng customer, "ngayon malinaw na ang lahat, maaari kang gumuhit." pwede ba? Ang mga kinakailangan ay pangkalahatan, kailangan nilang detalyado. Halimbawa, sa unang hakbang, natukoy mo na dapat mayroong laboratoryo ng dugo. Ngunit anong uri ng kagamitan ang naroroon, gaano karaming kuryente, naka-compress na hangin ang natupok nito (paano kung?), Kailangan mo ba ng mga lampara ng kuwarts para sa pagdidisimpekta, mga talahanayan ng laboratoryo, bentilasyon? Kung wala ito, magiging mahirap ang disenyo. Ito ang una. At pangalawa, kinakailangan na magreseta ng isang plano para sa pagtatayo ng isang ospital, ang paghahanda at pag-commissioning nito.

Para sa Sistema ng Impormasyon, ang pagbuo ng TK () ang sentrong bahagi ng proyekto. naglalarawan:

1. ANO ang dapat gawin ng sistema.
2. Ano ang dapat na pangkalahatang istraktura ng system.
3. Paano lumikha ng isang sistema.

Iyon ay, ang TOR ay naglalaman ng functional at non-functional na mga kinakailangan, pati na rin ang mga kinakailangan para sa mga yugto ng pag-unlad, pagtanggap, dokumentasyon. Gayundin, dapat ilarawan nang maikli ng TOR ang mga prosesong aktwal nating ino-automate.

Kapag inilalarawan ang mga function ng system (at ito ang gitnang bahagi ng TOR), dapat itong maunawaan na nagbibigay kami ng mga kinakailangan para sa ANO ang dapat gawin ng system, at hindi PAANO. Ang lapad ay dapat na mas mahalaga sa iyo kaysa sa lalim. Halimbawa, sa unang yugto (pagsasama-sama ng mga pangkalahatang kinakailangan), natukoy namin ang pangangailangan para sa isang function upang harangan ang pag-login ng user. Ipinahiwatig ng TOR na ang account ay naharang kapag hindi ginamit sa loob ng 90 araw o pagkatapos ng 6 na hindi matagumpay na pagtatangka sa pag-login, ang pag-access ay maaaring limitahan ng administrator para sa isang tiyak na panahon, kapag sinubukan ng isang naka-block na user na mag-log in, isang mensahe ay dapat na ipakita, atbp. At sa teknikal na proyekto (tumatakbo sa unahan), gagawa kami ng layout ng user card na may lock flag at petsa ng pag-unlock, gagawa ng script sa pag-login na tumitingin ng lock, awtomatikong magbubukas pagkatapos ng nakatakdang panahon, at magla-lock kung sakaling hindi matagumpay ang pag-login mga pagtatangka; Tukuyin natin kung ano ang ginagawa sa panig ng kliyente at kung ano ang nasa panig ng server.

Gusto kong i-debunk ang ilang mga alamat na may kaugnayan sa .

Myth one: Ang TOR ay naglalaman ng mga kinakailangan para lamang sa contractor.

Hindi, ang TOR ay kung paano lumikha ng isang sistema, at may mga seksyon sa mga tuntunin ng sanggunian kung saan maaari mong ilarawan ang pamamahagi ng responsibilidad.

4. Pagbuo ng isang teknikal na proyekto

Kaya't magpatuloy tayo. Dito sa harap mo (pinagpalagay namin na ikaw ay isang taga-disenyo) Mga Tuntunin ng Sanggunian para sa pagtatayo ng isang ospital na may malaking listahan ng mga kinakailangan. Umupo ka, malungkot na tumingin sa 100 pages ng TK, at hindi mo alam kung saan magsisimula. Pagkatapos ang larawan ay unti-unting nagsisimulang lumiwanag. Sa tingin mo: oo, kailangan natin ng napakaraming metro para sa mga ward, napakaraming para sa kusina, napakarami para sa lugar ng libangan, laboratoryo, mga silid ng pag-aalaga, at iba pa at iba pa. Pagkatapos ay maraming mga sketch, sketch, mga pagpipilian ang dumating sa liwanag, gagawin mo ito, baguhin ang mga lugar sa mga lugar, sa madaling salita, naghahanap ka ng mga pinakamainam na ratios. Pagkatapos ay pumunta sa mga detalye - mga guhit, mga guhit, mga guhit: mga dingding, mga pintuan, mga bintana, mga cable channel, mga kable, mga tubo, bentilasyon, mga interfloor na kisame, mga materyales sa dingding, mga pagtatapos ... at iba pa, at iba pa, at iba pa. Sa pangkalahatan, sa pinakamaraming detalye hangga't maaari, balangkasin kung paano dapat tumingin at gumana ang ospital pagkatapos makumpleto ang konstruksyon.

Kapag bumubuo ng isang teknikal na proyekto ng isang Sistema ng Impormasyon, kinakailangan ang mga dokumento na naglalaman ng mga sumusunod: mga detalyadong sitwasyon na naglalarawan sa pagpapatakbo at pakikipag-ugnayan ng binuong sistema, mga gumagamit at mga kaugnay na sistema; detalyadong mga layout ng user interface na naglalaman ng paglalarawan ng uri ng data at pag-uugali ng bawat elemento ng interface (default na halaga, mga kondisyon kung saan maaaring baguhin ang halaga ng field, visibility, mga aksyon na ginawa ng system kapag nagbago ang elemento, atbp.); paglalarawan ng mga protocol para sa pagsasama sa mga kaugnay na sistema at kagamitan, mga form ng ulat at paglalarawan ng kanilang generation algorithm, istraktura ng mga server at database, kung mayroong ilan sa kanila.

Kadalasan ito ay higit pa sa sapat upang makapagbigay ng mga dokumento sa mga developer at makakuha ng magandang resulta. Ang mga detalyadong layout at script ay nagbibigay ng sapat na impormasyon tungkol sa pag-uugali ng system at interface pati na rin ang istraktura ng data. Ang mga developer ay ilalagay sa isang mahigpit na balangkas kung saan maaari kang magpantasya, ngunit pagkatapos ay hindi ka makakalabas.

Umaasa ako na sa mga sumusunod na artikulo ay titingnan natin nang mabuti kung paano isakatuparan ang mataas na kalidad na teknikal na disenyo, kung paano bumuo ng mga layout, mga sitwasyon, kung anong mga dokumento ang kailangang iguhit.

5. Pagbuo ng dokumentasyon sa pagtatrabaho

Ang isang lohikal na tanong ay kung anong uri ng dokumentasyong gumagana para sa isang ospital? Talagang mga tagubilin para sa paglilinis ng koridor?! Joking aside, kailangan bang serbisyuhan ang fire system? Kailangan. At ang mga elevator? Paano naman ang mga computer network? At ang pagtutubero? "Well, hindi ito nauugnay sa proyekto ng ospital!" - sabi mo. Oo, ito ay bahagyang totoo. Gayunpaman, ang ospital ay inuupahan sa customer sa kabuuan, at lahat ng mga sistema ay dapat may naaangkop na dokumentasyon sa pagpapatakbo. At para maging mabilis, matagumpay ang paghahatid, gagawa ka ng isang listahan ng mga kinakailangan na maaari mong suriin sa harap kung ang lahat ay maayos.

Ang pagkakaroon ng mga manwal ng user at administrator para sa IS ay isang pamantayan, ang lahat ay malinaw dito. Ngunit ang proseso ng paghahatid at pagtanggap ng system sa customer ay madalas na iniisip sa huling sandali. At walang kabuluhan. Upang gawin ito, mayroong isang mahusay na dokumento na "Programa at Mga Paraan ng Pagsubok", kadalasang nauugnay din sa mga gumaganang dokumento. Ito ay isang uri ng checklist na naglalaman ng paglalarawan ng mga pamamaraan ng pag-verify. Kung ang dokumentong ito ay iginuhit nang maaga (at ang script ay maaaring hiramin mula sa teknikal na proyekto bilang batayan), kung gayon ang mga developer ay magkakaroon ng isang malinaw na pamantayan para sa pagtanggap ng kanilang trabaho. Hindi mo kailangan ng sarili mo o outsourced na mga programmer para patunayan na tama ka - may script, dapat itong gawin. At walang magiging problema sa customer - ang pantasya ay limitado na ng dokumento.

Saan ang lugar para sa Agile dito?

Ang ilang mga tao ay lahat para sa Agile (o iba pang "maliksi" na mga paraan ng pag-unlad), habang ang iba ay mahigpit na laban dito. Ang may-akda ng artikulo ay may sariling opinyon: Ang maliksi ay napakahusay, ngunit wala sa lugar. At karaniwan nilang ginagamit ito para sa iba pang mga layunin.

Sabihin sa akin, mga mahilig sa Agile, posible ba, gamit ang teknolohiyang ito, upang matukoy ang resulta na makukuha mo sa pagtatapos ng pag-unlad, ang gastos at tiyempo? Hindi? Well, gaano karaming mga tanga ng mga customer ang makikita mo kung sino ang sasali sa trabaho na may hindi malinaw na resulta, badyet at tagal? Mag-uutos ka ba ng pagkukumpuni ng apartment sa isang Agile team? Kaya, may lugar ang Agile, ngunit para sa mga panloob na proyekto. Magagawa mong ayusin ang iyong sarili hangga't gusto mo at suriin ang lahat nang maraming beses. Para sa mga panlabas na customer, ito ay isang scam na tinatawag ng isang matalinong termino (siyempre, hindi ka sasang-ayon sa mga salitang ito, ngunit subukang kumbinsihin ang kliyente ng pareho).

Iniisip ng kostumer: at gaano pa nila ako dadalhin sa isang bilog sa pamamagitan ng ilong?

Pangalawa, magaling ang Agile sa innovation, kung saan hindi malinaw kung ano ang resulta na kailangan makuha, o hindi malinaw ang paraan para makamit ito. Ito ay tinatawag na R&D, developmental development. O kahit na R&D - gawaing pananaliksik at pagpapaunlad. Sa anumang planta mayroong isang eksperimentong pagawaan, kung saan may isang file, muling paggawa ng maraming beses, ang mga prototype ay nakuha. Isipin na kailangan mong muling idisenyo ang touchscreen, lahat ng kilos at gawi. Dito mo talaga dapat subukan at subukan, hindi mo mailarawan nang maaga ang pag-uugali. Ngunit gaano ka kadalas nahaharap sa ganitong uri ng mga gawain? Ito ay kinakailangan upang makilala sa pagitan ng engineering development at pananaliksik. Karaniwan, kami ay mga inhinyero ng sistema ng impormasyon.

Pangatlo, sa isang malaking proyekto ay maaaring may mga yugto kung saan kinakailangan ang OCD, at pagkatapos ay makakatulong ang Agile. Walang nakikialam sa paggamit ng mga sprint sa antas ng pagpaplano ng pagpapatakbo. Sa kabaligtaran, isang napaka-maginhawang teknolohiya: magplano para sa isang linggo o dalawa at patuloy na subaybayan ang resulta. Sa madiskarteng antas - pagpaplano ng kaskad, sa taktikal - umuulit. At walang kontradiksyon!

Sa kasamaang palad, napakadalas, sa pamamagitan ng "pangangaral" Agile, sinusubukan ng mga developer na itago ang kanilang kawalan ng kakayahan na bumuo ng isang disenyo ng system (o hindi man lang alam na posible ito). Kumilos sila sa pinaka-maginhawang paraan para sa kanila: tatapusin at tatapusin namin ang pera ng customer. Hangga't walang kumokontrol sa mga gastos, maaari kang makatakas dito. Ngunit pagkatapos ay ang isang tagamasid sa labas (mga boss) ay maaaring makakuha ng pakiramdam na ang proseso ay naroroon, ngunit ang dulo at ang gilid, at ang resulta ay hindi nakikita. Subukang tumingin hindi lamang mula sa iyong kampanilya.

Saan ako maaaring matuto nang higit pa tungkol sa disenyo ng mga sistema ng impormasyon?

Mayroong maraming mga libro sa paksang ito. Makapal at hindi masyadong makapal. Ngunit ang libro ay palaging karanasan ng iba. At mayroon kang ibang karakter, isang mahusay na sitwasyon at proyekto. Mayroong tulad ng isang sistema ng TRIZ - ang teorya ng mapag-imbento na paglutas ng problema. Sinusubukan ng may-akda nito, si Altshuller, na ipaliwanag ang mga hakbang na dapat gawin upang mag-imbento ng isang bagay. Iyon pala? Bilang isang tuntunin, hindi. Ang mga prinsipyo ay nakasaad na kawili-wili, kapaki-pakinabang, ngunit ang isang solong template ayon sa imbensyon ay hindi lalabas. Ang bawat tao ay nag-iisip at lumilikha sa kanyang sariling paraan, at imposibleng ituro ito, maaari ka lamang matuto. Kailangang gumamit ng karanasan ng iba, katangahan ang hindi gamitin, ngunit dapat itong maranasan (iproseso) mo, ilipat sa IYONG pag-iisip. Hindi mo maaaring kopyahin ang isang himala.

Mga Tag: Magdagdag ng mga tag

Disenyo ng mga sistema ng impormasyon

Bahagi 1. Mga yugto ng pagbuo ng proyekto: diskarte at pagsusuri

Panimula "Waterfall" - scheme ng pagbuo ng proyekto Diskarte Pagsusuri Mga diagram ng ER mga arko Normalisasyon Mga diagram ng daloy ng data Ilang mga prinsipyo para sa pagsuri sa kalidad at pagkakumpleto ng modelo ng impormasyon Kalidad ng entidad Kalidad ng Katangian Kalidad ng koneksyon Mga function ng system Pagpipino ng Diskarte

Panimula

Ang disenyo ng mga sistema ng impormasyon ay palaging nagsisimula sa kahulugan ng layunin ng proyekto. Ang pangunahing gawain ng anumang matagumpay na proyekto ay upang matiyak na sa oras ng paglulunsad ng system at sa buong panahon ng operasyon nito posible na magbigay ng:

ang kinakailangang pag-andar ng system at ang antas ng pagbagay sa pagbabago ng mga kondisyon ng paggana nito;

kinakailangang throughput ng system;

ang kinakailangang oras ng pagtugon ng system sa isang kahilingan;

walang problema na operasyon ng system sa kinakailangang mode, sa madaling salita, ang kahandaan at kakayahang magamit ng system upang iproseso ang mga kahilingan ng user;

kadalian ng operasyon at suporta ng system;

ang kinakailangang seguridad.

Ang pagganap ay ang pangunahing salik na tumutukoy sa kahusayan ng isang sistema. Ang mahusay na disenyo ay ang pundasyon ng isang mataas na pagganap ng sistema.

Ang disenyo ng mga sistema ng impormasyon ay sumasaklaw sa tatlong pangunahing lugar:

pagdidisenyo ng mga bagay ng data na ipapatupad sa database;

pagdidisenyo ng mga programa, mga screen form, mga ulat na magtitiyak sa pagpapatupad ng mga query sa data;

isinasaalang-alang ang isang partikular na kapaligiran o teknolohiya, katulad ng: topology ng network, configuration ng hardware, ginamit na arkitektura (file-server o client-server), parallel processing, distributed data processing, atbp.

Sa totoong mga kondisyon, ang disenyo ay isang paghahanap para sa isang paraan na nakakatugon sa mga kinakailangan ng pag-andar ng system sa pamamagitan ng mga magagamit na teknolohiya, na isinasaalang-alang ang ibinigay na mga paghihigpit.

Ang anumang proyekto ay napapailalim sa isang bilang ng mga ganap na kinakailangan, halimbawa, ang pinakamataas na oras ng pagbuo ng proyekto, ang pinakamataas na pamumuhunan sa pananalapi sa proyekto, atbp. Ang isa sa mga kahirapan ng disenyo ay hindi ito kasing balangkas ng pagsusuri ng mga kinakailangan sa proyekto o ang pagpapatupad ng isang partikular na solusyon sa disenyo.

Ito ay pinaniniwalaan na ang isang kumplikadong sistema ay hindi maaaring inilarawan sa prinsipyo. Ito, sa partikular, ay may kinalaman sa mga sistema ng pamamahala ng negosyo. Ang isa sa mga pangunahing argumento ay isang pagbabago sa mga kondisyon para sa paggana ng sistema, halimbawa, isang direktiba na pagbabago sa ilang mga daloy ng impormasyon ng bagong pamunuan. Ang isa pang argumento ay ang saklaw ng mga tuntunin ng sanggunian, na para sa isang malaking proyekto ay maaaring daan-daang mga pahina, habang ang teknikal na proyekto ay maaaring maglaman ng mga error. Ang tanong ay lumitaw: marahil mas mahusay na huwag magsagawa ng mga survey at huwag gumawa ng anumang teknikal na proyekto, ngunit isulat ang sistema "mula sa simula" sa pag-asa na magkakaroon ng ilang mahimalang pagkakataon ng pagnanais ng customer sa isinulat ng mga programmer, at din na ang lahat ng ito ay gagana nang matatag?

Kung titingnan mo, napaka unpredictable ba talaga ng development ng system at imposibleng makakuha ng impormasyon tungkol dito? Malamang na ang isang ideya ng sistema sa kabuuan at ang mga paraan (pamamahala) na inilaan para sa pag-unlad nito ay maaaring makuha sa pamamagitan ng mga seminar. Pagkatapos nito, hatiin ang kumplikadong sistema sa mas simpleng mga bahagi, gawing simple ang mga koneksyon sa pagitan ng mga bahagi, magbigay ng kalayaan ng mga bahagi at ilarawan ang mga interface sa pagitan ng mga ito (upang ang pagbabago sa isang bahagi ay hindi awtomatikong nangangailangan ng isang makabuluhang pagbabago sa isa pang bahagi) , pati na rin ang posibilidad ng pagpapalawak ng system at "mga stub" para sa hindi maisasakatuparan sa isa o ibang bersyon ng sistema ng mga pag-andar. Batay sa mga elementarya na pagsasaalang-alang, ang paglalarawan ng kung ano ang dapat na ipatupad sa sistema ng impormasyon ay hindi na tila hindi makatotohanan. Maaari mong sundin ang mga klasikal na diskarte sa pagbuo ng mga sistema ng impormasyon, isa sa kung saan ay ang "waterfall" scheme ( kanin. 1) ay inilarawan sa ibaba. Ang ilang iba pang mga diskarte sa pagbuo ng mga sistema ng impormasyon ay isasaalang-alang din sa madaling sabi, kung saan ang paggamit ng mga elemento na inilarawan sa "waterfall" na pamamaraan ay katanggap-tanggap din. Aling diskarte mula sa mga inilarawan sa ibaba ang dapat sundin (at kung makatuwirang gumawa ng sarili mong diskarte) ay sa ilang lawak ay isang bagay ng panlasa at mga pangyayari.

kanin. 1. Waterfall scheme

Ang ikot ng buhay ng software ay isang modelo para sa paglikha at paggamit nito. Ang modelo ay sumasalamin sa iba't ibang mga estado nito, simula sa sandaling kailanganin ang software na ito at magtatapos sa sandaling ito ay ganap na hindi magagamit para sa lahat ng mga gumagamit. Ang mga sumusunod na modelo ng siklo ng buhay ay kilala:

modelo ng cascade. Ang paglipat sa susunod na yugto ay nangangahulugan ng kumpletong pagkumpleto ng gawain sa nakaraang yugto.

Nakatanghal na modelo na may intermediate na kontrol. Ang pagbuo ng software ay isinasagawa sa mga pag-ulit na may mga loop ng feedback sa pagitan ng mga yugto. Ang mga pagsasaayos sa pagitan ng mga yugto ay maaaring mabawasan ang pagiging kumplikado ng proseso ng pag-unlad kumpara sa modelo ng talon; ang buhay ng bawat isa sa mga yugto ay nakaunat para sa buong panahon ng pag-unlad.

modelong spiral. Ang partikular na atensyon ay binabayaran sa mga unang yugto ng pag-unlad - pagbuo ng diskarte, pagsusuri at disenyo, kung saan ang pagiging posible ng ilang mga teknikal na solusyon ay nasuri at nabigyang-katwiran sa pamamagitan ng paglikha ng mga prototype (prototyping). Ang bawat pagliko ng spiral ay nagsasangkot ng paglikha ng isang tiyak na bersyon ng produkto o alinman sa mga bahagi nito, habang ang mga katangian at layunin ng proyekto ay tinukoy, ang kalidad nito ay tinutukoy, at ang gawain ng susunod na pagliko ng spiral ay binalak.

Sa ibaba ay isasaalang-alang natin ang ilan sa mga scheme ng pagbuo ng proyekto.

Sa simula

"Waterfall" - scheme ng pagbuo ng proyekto

Kadalasan, ang disenyo ay inilarawan bilang isang hiwalay na yugto ng pagbuo ng proyekto sa pagitan ng pagsusuri at pag-unlad. Gayunpaman, sa katotohanan, walang malinaw na dibisyon ng mga yugto ng pagbuo ng proyekto - ang disenyo, bilang panuntunan, ay walang malinaw na tinukoy na simula at wakas, at madalas na nagpapatuloy sa mga yugto ng pagsubok at pagpapatupad. Sa pagsasalita tungkol sa yugto ng pagsubok, dapat ding tandaan na ang parehong yugto ng pagsusuri at yugto ng disenyo ay naglalaman ng mga elemento ng gawain ng mga tagasubok, halimbawa, upang makakuha ng isang pang-eksperimentong katwiran para sa pagpili ng isang partikular na solusyon, pati na rin upang suriin ang pamantayan ng kalidad. ng resultang sistema. Sa yugto ng operasyon, angkop na pag-usapan ang tungkol sa pagpapanatili ng system.

Sa ibaba ay isasaalang-alang namin ang bawat isa sa mga yugto, tirahan nang mas detalyado sa yugto ng disenyo.

Sa simula

Diskarte

Ang pagtukoy sa isang diskarte ay nagsasangkot ng pagsusuri sa sistema. Ang pangunahing gawain ng survey ay upang masuri ang tunay na saklaw ng proyekto, ang mga layunin at layunin nito, pati na rin upang makakuha ng mga kahulugan ng mga entidad at pag-andar sa isang mataas na antas.

Sa yugtong ito, ang mga mataas na kwalipikadong analyst ng negosyo ay kasangkot, na may patuloy na pag-access sa pamamahala ng kumpanya; ang yugto ay nagsasangkot ng malapit na pakikipag-ugnayan sa mga pangunahing gumagamit ng system at mga eksperto sa negosyo. Ang pangunahing gawain ng pakikipag-ugnayan ay upang makakuha ng kumpletong impormasyon tungkol sa system hangga't maaari (isang kumpleto at hindi malabo na pag-unawa sa mga kinakailangan ng customer) at ilipat ang impormasyong ito sa isang pormal na anyo sa mga analyst ng system para sa kasunod na yugto ng pagsusuri. Bilang isang patakaran, ang impormasyon tungkol sa system ay maaaring makuha bilang isang resulta ng mga pag-uusap o seminar sa pamamahala, mga eksperto at mga gumagamit. Kaya, ang kakanyahan ng negosyong ito, ang mga prospect para sa pag-unlad nito at ang mga kinakailangan para sa system ay tinutukoy.

Sa pagkumpleto ng pangunahing yugto ng survey ng system, ang mga technician ay bumubuo ng malamang na mga teknikal na diskarte at tinatantya ang mga gastos ng hardware, biniling software, at pagbuo ng bagong software (na, sa katunayan, ay ipinapalagay ng proyekto).

Ang resulta ng yugto ng pagtukoy ng diskarte ay isang dokumento na malinaw na nagsasaad kung ano ang matatanggap ng customer kung siya ay sumang-ayon na tustusan ang proyekto; kapag natanggap niya ang tapos na produkto (iskedyul ng trabaho); magkano ang magagastos nito (para sa malalaking proyekto, isang iskedyul ng pagpopondo sa iba't ibang yugto ng trabaho ang dapat iguhit). Dapat ipakita ng dokumento hindi lamang ang mga gastos, kundi pati na rin ang mga benepisyo, halimbawa, ang oras ng pagbabayad ng proyekto, ang inaasahang epekto sa ekonomiya (kung maaari itong tantiyahin).

Dapat ilarawan ng dokumento ang:

mga paghihigpit, mga panganib, mga kritikal na salik na nakakaapekto sa tagumpay ng proyekto, halimbawa, ang oras ng pagtugon ng system sa isang kahilingan ay isang ibinigay na limitasyon, at hindi isang kanais-nais na kadahilanan;

isang hanay ng mga kondisyon kung saan ito ay dapat na patakbuhin ang hinaharap na sistema: arkitektura ng system, mga mapagkukunan ng hardware at software na ibinigay sa system, mga panlabas na kondisyon para sa paggana nito, komposisyon ng mga tao at trabaho na nagsisiguro sa maayos na paggana ng system;

mga deadline para sa pagkumpleto ng mga indibidwal na yugto, ang anyo ng paghahatid ng trabaho, mga mapagkukunan na kasangkot sa proseso ng pagbuo ng proyekto, mga hakbang upang maprotektahan ang impormasyon;

paglalarawan ng mga pag-andar na isinagawa ng system;

mga kinakailangan sa hinaharap para sa system sa kaganapan ng pag-unlad nito, halimbawa, ang kakayahan ng gumagamit na magtrabaho kasama ang system gamit ang Internet, atbp.;

mga entity na kinakailangan upang maisagawa ang mga function ng system;

mga interface at pamamahagi ng mga function sa pagitan ng isang tao at isang system;

mga kinakailangan para sa software at mga bahagi ng impormasyon ng software, mga kinakailangan para sa DBMS (kung ang proyekto ay dapat na ipatupad para sa ilang DBMS, kung gayon ang mga kinakailangan para sa bawat isa sa kanila, o pangkalahatang mga kinakailangan para sa abstract na DBMS at isang listahan ng DBMS na inirerekomenda para sa proyektong ito na matugunan ang tinukoy na mga kondisyon);

na hindi ipapatupad sa loob ng balangkas ng proyekto.

Ang gawaing isinagawa sa yugtong ito ay nagpapahintulot sa amin na sagutin ang tanong kung ito ay nagkakahalaga ng pagpapatuloy ng proyektong ito at kung anong mga kinakailangan ng customer ang maaaring matugunan sa ilalim ng ilang mga kundisyon. Maaaring lumabas na ang proyekto ay hindi makatuwiran na magpatuloy, halimbawa, dahil ang ilang mga kinakailangan ay hindi masisiyahan para sa ilang mga layunin na dahilan. Kung ang isang desisyon ay ginawa upang magpatuloy sa proyekto, kung gayon ang isang ideya ng saklaw ng proyekto at pagtatantya ng gastos ay magagamit na para sa susunod na yugto ng pagsusuri.

Dapat pansinin na sa yugto ng pagpili ng isang diskarte, at sa yugto ng pagsusuri, at sa panahon ng disenyo, anuman ang pamamaraan na ginamit sa pagbuo ng proyekto, dapat palaging pag-uri-uriin ang mga nakaplanong pag-andar ng system sa pagkakasunud-sunod ng kahalagahan. . Ang isang posibleng format para sa kumakatawan sa naturang klasipikasyon, ang MoSCoW, ay iminungkahi sa Clegg, Dai at Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Ang pagdadaglat na ito ay nangangahulugang: Dapat mayroon - mga kinakailangang function; Dapat magkaroon - kanais-nais na mga pag-andar; Maaaring magkaroon ng - posibleng mga function; Hindi magkakaroon ng - nawawalang mga function.

Ang pagpapatupad ng mga pag-andar ng ikalawa at pangatlong kategorya ay limitado ng oras at pinansiyal na balangkas: binubuo namin kung ano ang kinakailangan, pati na rin ang maximum na posibleng bilang ng mga pag-andar ng ikalawa at ikatlong kategorya sa pagkakasunud-sunod ng priyoridad.

Sa simula

Pagsusuri

Ang yugto ng pagsusuri ay nagsasangkot ng isang detalyadong pag-aaral ng mga proseso ng negosyo (mga function na tinukoy sa yugto ng pagpili ng diskarte) at ang impormasyong kinakailangan para sa kanilang pagpapatupad (mga entidad, kanilang mga katangian at relasyon (mga relasyon)). Sa yugtong ito, ang isang modelo ng impormasyon ay nilikha, at sa susunod na yugto ng disenyo, isang modelo ng data ay nilikha.

Ang lahat ng impormasyon tungkol sa system na nakolekta sa yugto ng kahulugan ng diskarte ay pormal at pino sa yugto ng pagsusuri. Ang partikular na atensyon ay dapat bayaran sa pagkakumpleto ng ipinadala na impormasyon, ang pagsusuri ng impormasyon para sa kawalan ng mga kontradiksyon, pati na rin ang paghahanap para sa impormasyon na hindi ginagamit o nadoble. Bilang isang tuntunin, ang customer ay hindi agad bumubuo ng mga kinakailangan para sa system sa kabuuan, ngunit binabalangkas ang mga kinakailangan para sa mga indibidwal na bahagi nito. Bigyang-pansin ang pagkakapare-pareho ng mga sangkap na ito.

Kinokolekta at itinatala ng mga analyst ang impormasyon sa dalawang magkakaugnay na anyo:

function - impormasyon tungkol sa mga kaganapan at proseso na nangyayari sa negosyo;

entity - impormasyon tungkol sa mga bagay na mahalaga sa organisasyon at kung saan alam ang isang bagay.

Ang dalawang klasikong resulta ng pagsusuri ay:

isang hierarchy ng mga function na naghahati sa pagproseso sa mga bahaging bahagi nito (kung ano ang ginagawa at kung ano ang binubuo nito);

entity-relationship model (Entry Relationship model, ER-model), na naglalarawan sa mga entity, kanilang mga katangian at koneksyon (relasyon) sa pagitan nila.

Ang mga resultang ito ay kinakailangan ngunit hindi sapat. Kasama sa mga sapat na resulta ang mga diagram ng daloy ng data at mga diagram ng ikot ng buhay ng entity. Kadalasan, nangyayari ang mga error sa pagsusuri kapag sinusubukang ipakita ang cycle ng buhay ng isang entity sa isang ER diagram.

Sa ibaba ay susuriin natin ang tatlong pinakakaraniwang ginagamit na pamamaraan ng pagsusuri sa istruktura:

Entity-Relationship Diagrams (ERD), na nagsisilbing gawing pormal ang impormasyon tungkol sa mga entity at kanilang mga relasyon;

mga diagram ng daloy ng data (Data Flow Diagrams, DFD), na nagsisilbing gawing pormal ang representasyon ng mga function ng system;

state transition diagrams (State Transition Diagrams, STD), na sumasalamin sa gawi ng system, depende sa oras; Ang mga diagram ng ikot ng buhay ng entity ay nabibilang sa klase ng mga diagram na ito.

Sa simula

Mga diagram ng ER

ER diagram ( kanin. 2) ay ginagamit upang magdisenyo ng data at ito ay isang karaniwang paraan ng pagtukoy ng data at mga relasyon sa pagitan ng mga ito. Kaya, ang pagdedetalye ng mga warehouse ng data ay isinasagawa. Ang diagram ng ER ay naglalaman ng impormasyon tungkol sa mga entity ng system at kung paano sila nakikipag-ugnayan, kasama ang pagkakakilanlan ng mga bagay na mahalaga para sa lugar ng paksa (mga entidad), ang mga katangian ng mga bagay na ito (mga katangian) at ang kanilang mga kaugnayan sa iba pang mga bagay (mga link). Sa maraming kaso, ang modelo ng impormasyon ay napakakumplikado at naglalaman ng maraming bagay.

kanin. 2. Isang halimbawa ng ER diagram

Ang isang entity ay ipinapakita bilang isang parihaba na may pangalan ng entity sa itaas (halimbawa, TITLES). Maaaring ilista ng kahon ang mga katangian ng isang entity; Ang mga katangian ng mga ER-diagram, na na-type nang bold, ay susi (kaya ang Title Identity ay isang pangunahing katangian ng TITLES entity, ang ibang mga attribute ay hindi susi).

Ang isang relasyon ay kinakatawan ng isang linya sa pagitan ng dalawang entity (mga asul na linya sa figure).

Isang linya sa kanan ( kanin. 3) ay nangangahulugang "isa", "paa ng ibon", sa kaliwa ay "marami", at ang kaugnayan ay binabasa sa linya, tulad ng "isa sa marami". Ang patayong bar ay nangangahulugang "mandatory", ang isang bilog ay nangangahulugang "opsyonal", halimbawa, para sa bawat publikasyon sa TITLE, ang isang publisher ay dapat na nakasaad sa PUBLISHERS, at ang isang publisher sa PUBLISHERS ay maaaring mag-publish ng ilang mga pamagat sa TITLES. Dapat tandaan na ang mga link ay palaging nagkomento (isang inskripsiyon sa linya na naglalarawan sa link).

kanin. 3. ER diagram na elemento

Nagbibigay din kami ng isang halimbawa ( kanin. 4) mga larawan ng mapanimdim na relasyon na "empleyado", kung saan maaaring pangasiwaan ng isang empleyado ang ilang mga subordinates at iba pa pababa sa hierarchy ng mga posisyon.

kanin. 4. ER diagram ng isang reflexive na relasyon

Tandaan na ang ganitong relasyon ay palaging opsyonal, kung hindi, ito ay magiging isang walang katapusang hierarchy.

Maaaring maging susi ang mga katangian ng entity - naka-bold ang mga ito; ipinag-uutos - sila ay pinangungunahan ng "*" sign, iyon ay, ang kanilang halaga ay palaging kilala, opsyonal (opsyonal) - sila ay pinangungunahan ng O, iyon ay, ang mga halaga ng katangiang ito sa ilang mga punto ay maaaring wala o hindi natukoy.

Sa simula

mga arko

Kung ang isang entity ay may isang set ng mutually exclusive na relasyon sa ibang entity, kung gayon ang mga naturang relasyon ay sinasabing nasa isang arko. Halimbawa, ang isang bank account ay maaaring maibigay para sa isang legal na entity o para sa isang indibidwal. Ang isang fragment ng ER diagram para sa ganitong uri ng relasyon ay ipinapakita sa kanin. 5.

kanin. 5. Arc

Sa kasong ito, ang katangian ng OWNER ng entity ng ACCOUNT ay may espesyal na kahulugan para sa entity na ito - nahahati ang entity sa mga uri ayon sa mga kategorya: "para sa isang indibidwal" at "para sa isang legal na entity." Ang mga resultang entity ay tinatawag na mga subtype, at ang orihinal na entity ay nagiging supertype. Upang maunawaan kung ang isang supertype ay kailangan o hindi, ito ay kinakailangan upang itatag kung gaano karami sa parehong mga katangian ay may iba't ibang mga subtype. Dapat tandaan na ang pang-aabuso ng mga subtype at supertype ay isang pangkaraniwang pagkakamali. Ang mga ito ay inilalarawan tulad ng ipinapakita sa kanin. 6.

kanin. 6. Mga subtype (kanan) at supertype (kaliwa)

Sa simula

Normalisasyon

Upang maiwasan ang mga anomalya sa pagproseso ng data, ginagamit ang normalisasyon. Ang mga prinsipyo ng normalisasyon para sa mga object ng modelo ng impormasyon ay eksaktong kapareho ng para sa mga modelo ng data.

Pinapayagan ang mga uri ng link. Sa mas malapit na pagsusuri, isa-sa-isang relasyon ( kanin. 7) halos palaging lumalabas na ang A at B ay talagang magkaibang mga subset ng parehong bagay o magkaibang pananaw dito, na may magkaibang pangalan at magkaibang inilarawang mga relasyon at katangian.

kanin. 7. One-to-one na relasyon

Ipinapakita ang maraming-sa-isang relasyon kanin. 8.

kanin. 8. Maraming-sa-Isang Relasyon

Ang I ay isang malakas na konstruksyon na ang isang entry ng entity B ay hindi maaaring gawin nang hindi sabay na lumilikha ng kahit isang nauugnay na entry ng entity A.

II ay ang pinakakaraniwang paraan ng komunikasyon. Ipinapalagay nito na ang bawat paglitaw ng entity A ay maaari lamang umiral sa konteksto ng isa (at isa lamang) na paglitaw ng entity B. Sa turn, ang mga paglitaw ng B ay maaaring umiral kapwa may kaugnayan sa mga paglitaw ng A, at kung wala ito.

III - bihirang gamitin. Ang parehong A at B ay maaaring umiral nang walang koneksyon sa pagitan nila.

Ipinapakita ang maraming-sa-maraming relasyon kanin. 9.

kanin. 9. Many-to-Many Relationships

I - ang ganitong konstruksiyon ay madalas na nagaganap sa simula ng yugto ng pagsusuri at nangangahulugan ng isang koneksyon - alinman ay hindi lubos na nauunawaan at nangangailangan ng karagdagang pahintulot, o sumasalamin sa isang simpleng kolektibong relasyon - isang dobleng naka-link na listahan.

II - bihirang gamitin. Ang ganitong mga link ay palaging napapailalim sa karagdagang detalye.

Isaalang-alang ngayon ang mga recursive na link ( kanin. 10).

kanin. 10. Recursive na mga link

Ako - bihira, ngunit nangyayari. Sumasalamin sa mga link ng isang alternatibong uri.

II - medyo madalas na ginagamit upang ilarawan ang mga hierarchy na may anumang bilang ng mga antas.

III - nagaganap sa mga unang yugto. Madalas na sumasalamin sa istraktura ng "listahan ng mga materyales" (mutual nesting ng mga bahagi). Halimbawa: ang bawat COMPONENT ay maaaring binubuo ng isa o higit pang (ibang) COMPONENT at ang bawat COMPONENT ay maaaring gamitin sa isa o higit pang (ibang) COMPONENT.

Di-wastong mga uri ng link. Kabilang sa mga di-wastong uri ng relasyon ang sumusunod: Mandatoryong relasyong marami-sa-maraming ( kanin. labing-isa) at isang bilang ng mga recursive na link ( kanin. 12).

kanin. 11. Di-wastong maraming-sa-maraming relasyon

kanin. 12. Di-wastong recursive links

Ang isang ipinag-uutos na many-to-many na relasyon ay karaniwang imposible. Ang ganitong relasyon ay nangangahulugan na wala sa mga pangyayari ng A ang maaaring umiral nang walang B, at kabaliktaran. Sa katunayan, ang bawat naturang konstruksiyon ay palaging lumiliko na mali.

Sa simula

Mga diagram ng daloy ng data

Logic DFD ( kanin. 13) ay nagpapakita ng mga pinagmumulan at paglubog (mga destinasyon) ng data sa labas ng system, kinikilala ang mga lohikal na function (proseso) at mga pangkat ng mga elemento ng data na nagkokonekta sa isang function sa isa pa (mga stream), at kinikilala din ang mga imbakan ng data (accumulators) na naa-access. Ang mga istruktura ng daloy ng data at ang mga kahulugan ng mga bahagi nito ay iniimbak at na-parse sa diksyunaryo ng data. Ang bawat lohikal na function (proseso) ay maaaring detalyado gamit ang mas mababang antas ng DFD; kapag ang karagdagang detalye ay hindi na kapaki-pakinabang, ang isa ay nagpapatuloy sa pagpapahayag ng lohika ng function gamit ang isang detalye ng proseso (mini-specification). Ang nilalaman ng bawat tindahan ay iniimbak din sa isang diksyunaryo ng data, at ang modelo ng data ng tindahan ay inilalantad gamit ang mga ER diagram.

kanin. 13. Halimbawa ng DFD

Sa partikular, hindi ipinapakita ng DFD ang mga prosesong kumokontrol sa aktwal na daloy ng data at hindi nakikilala ang pagitan ng wasto at di-wastong mga landas. Ang mga DFD ay naglalaman ng maraming kapaki-pakinabang na impormasyon, at bilang karagdagan:

pinapayagan kang ipakita ang system sa mga tuntunin ng data;

ilarawan ang mga panlabas na mekanismo ng feed ng data na mangangailangan ng mga espesyal na interface;

payagan na kumatawan sa parehong awtomatiko at manu-manong mga proseso ng system;

magsagawa ng data-oriented na partitioning ng buong system.

Ang mga daloy ng data ay ginagamit upang imodelo ang paglilipat ng impormasyon (o maging ang mga pisikal na bahagi) mula sa isang bahagi ng isang sistema patungo sa isa pa. Ang mga daloy sa mga diagram ay kinakatawan ng pinangalanang mga arrow, ang mga arrow ay nagpapahiwatig ng direksyon ng daloy ng impormasyon. Minsan ang impormasyon ay maaaring lumipat sa isang direksyon, maproseso at ibalik sa pinagmulan nito. Ang ganitong sitwasyon ay maaaring imodelo ng alinman sa dalawang magkaibang daloy, o ng isang bidirectional na isa.

Binabago ng isang proseso ang isang input stream sa isang output stream ayon sa aksyon na tinukoy ng pangalan ng proseso. Ang bawat proseso ay dapat magkaroon ng isang natatanging numero upang i-reference ito sa loob ng diagram. Maaaring gamitin ang numerong ito kasabay ng numero ng diagram upang magbigay ng natatanging index ng proseso sa buong modelo.

Ang imbakan ng data (imbakan ng data) ay nagbibigay-daan sa iyo na tukuyin ang data sa isang bilang ng mga lugar na maiimbak sa memorya sa pagitan ng mga proseso. Sa katunayan, ang imbakan ay kumakatawan sa "mga hiwa" ng mga stream ng data sa oras. Ang impormasyong nilalaman nito ay maaaring gamitin anumang oras pagkatapos itong matukoy, at ang data ay maaaring mapili sa anumang pagkakasunud-sunod. Ang pangalan ng repository ay dapat tukuyin ang mga nilalaman nito. Sa kaso kapag ang daloy ng data ay pumasok (umalis) sa (mula sa) imbakan at ang istraktura nito ay tumutugma sa istraktura ng imbakan, dapat itong magkaroon ng parehong pangalan, na hindi kailangang ipakita sa diagram.

Ang isang panlabas na entity (terminator) ay kumakatawan sa isang entity sa labas ng konteksto ng system, na siyang pinagmulan o tagatanggap ng data ng system. Ang pangalan nito ay dapat maglaman ng isang pangngalan, gaya ng "Kliyente". Ipinapalagay na ang mga bagay na kinakatawan ng naturang mga node ay hindi dapat lumahok sa anumang pagproseso.

Sa simula

STD State Transition Diagram

Ang ikot ng buhay ng isang entity ay kabilang sa klase ng mga STD diagram ( kanin. 14). Ang diagram na ito ay sumasalamin sa pagbabago sa estado ng isang bagay sa paglipas ng panahon. Halimbawa, isaalang-alang ang estado ng isang produkto sa isang bodega: ang isang produkto ay maaaring mag-order mula sa isang supplier, maihatid sa isang bodega, naka-imbak sa isang bodega, sumailalim sa kontrol sa kalidad, ibenta, tinanggihan, ibalik sa isang supplier. Ang mga arrow sa diagram ay nagpapakita ng mga pinapayagang pagbabago sa estado.

Fig.14. Halimbawa ng DFD

Mayroong maraming iba't ibang mga pagpipilian para sa pagpapakita ng gayong mga diagram, ang figure ay nagpapakita lamang ng isa sa kanila.

Sa simula

Ilang mga prinsipyo para sa pagsuri sa kalidad at pagkakumpleto ng isang modelo ng impormasyon (pinagmulan - Richard Barker, Paraan ng Kaso: Entity Relationship Modeling, Addison-Wesley, 1990)

Kung nais mong lumikha ng isang de-kalidad na modelo, kakailanganin mong gumamit ng tulong ng mga analyst na bihasa sa teknolohiya ng CASE. Gayunpaman, hindi ito nangangahulugan na ang mga analyst lamang ang dapat na kasangkot sa pagbuo at kontrol ng modelo ng impormasyon. Malaki rin ang maitutulong ng tulong ng mga kasamahan. Isali sila sa pagsuri sa layunin at sa isang detalyadong pag-aaral ng binuo na modelo, kapwa sa mga tuntunin ng lohika at sa mga tuntunin ng pagsasaalang-alang sa mga aspeto ng paksa. Karamihan sa mga tao ay mas madaling makahanap ng mga bahid sa trabaho ng ibang tao.

Regular na ipakita ang iyong modelo ng impormasyon o ang mga indibidwal na fragment nito kung saan mayroon kang mga pagdududa para sa pag-apruba ng mga user. Bigyang-pansin ang mga pagbubukod sa mga patakaran at paghihigpit.

Sa simula

Kalidad ng entidad

Ang pangunahing garantiya ng kalidad ng isang nilalang ay ang sagot sa tanong kung ang bagay ay talagang isang nilalang, iyon ay, isang mahalagang bagay o kababalaghan, impormasyon tungkol sa kung saan dapat na nakaimbak sa database.

Listahan ng mga tanong sa pag-verify para sa entity:

Ang pangalan ba ng isang entity ay nagpapakita ng kakanyahan ng bagay na ito?

Mayroon bang intersection sa ibang entity?

Mayroon bang hindi bababa sa dalawang katangian?

Mayroon bang hindi hihigit sa walong mga katangian sa kabuuan?

Mayroon bang anumang kasingkahulugan/homonym para sa entity na ito?

Ang entity ba ay ganap na tinukoy?

Mayroon bang natatanging identifier?

Mayroon bang kahit isang koneksyon?

Mayroon bang kahit isang function para sa paglikha, paghahanap, pag-update, pagtanggal, pag-archive, at paggamit ng halaga ng entity?

Mayroon bang kasaysayan ng mga pagbabago?

Mayroon bang pagsunod sa mga prinsipyo ng normalisasyon ng data?

Umiiral ba ang parehong entity sa ibang sistema ng aplikasyon, marahil sa ilalim ng ibang pangalan?

Masyado bang pangkalahatan ang kakanyahan?

Sapat ba ang antas ng paglalahat na nakapaloob dito?

Listahan ng mga tanong sa screening para sa subtype:

Mayroon bang anumang mga overlap sa iba pang mga subtype?

Ang subtype ba ay may anumang mga katangian at/o mga relasyon?

Lahat ba sila ay may sariling natatanging identifier, o lahat ba sila ay nagmamana ng isa mula sa supertype?

Mayroon bang kumpletong hanay ng mga subtype?

Hindi ba ang isang subtype ay isang halimbawa ng isang pangyayari sa entity?

May alam ka bang anumang mga katangian, relasyon, at kundisyon na nagpapakilala sa subtype na ito mula sa iba?

Sa simula

Kalidad ng Katangian

Kinakailangang malaman kung ang mga ito ay talagang mga katangian, iyon ay, kung inilalarawan nila ang entity na ito sa isang paraan o iba pa.

Listahan ng mga tanong sa seguridad para sa isang katangian:

Ang pangalan ba ng isang katangian ay isang pangngalan na sumasalamin sa kakanyahan ng ari-arian na tinutukoy ng katangian?

Hindi ba kasama sa pangalan ng attribute ang pangalan ng entity (hindi dapat)?

Ang katangian ba ay may isang halaga lamang sa isang pagkakataon?

Mayroon bang nawawalang mga dobleng halaga (o mga grupo)?

Inilalarawan ba ang format, haba, wastong mga halaga, derivation algorithm, atbp?

Maaari bang ang attribute na ito ay isang inalis na entity na magiging kapaki-pakinabang para sa isa pang system ng application (umiiral o iminungkahi)?

Maaaring ito ay isang hindi nasagot na link?

Kailangan ba ng kasaysayan ng mga pagbabago?

Nakadepende lang ba ang halaga nito sa ibinigay na entity?

Kung ang halaga ng isang katangian ay kinakailangan, ito ba ay palaging kilala?

Kailangan bang lumikha ng isang domain para dito at sa mga katulad na katangian?

Nakadepende lang ba ang halaga nito sa ilang bahagi ng natatanging identifier?

Nakadepende ba ang halaga nito sa mga halaga ng ilang katangian na hindi kasama sa natatanging identifier?

Panimula

Ang disenyo ng mga sistema ng impormasyon ay palaging nagsisimula sa kahulugan ng layunin ng proyekto. Ang pangunahing gawain ng anumang matagumpay na proyekto ay upang matiyak na sa oras ng paglulunsad ng system at sa buong panahon ng operasyon nito posible na magbigay ng:

• ang kinakailangang pag-andar ng system at ang antas ng pagbagay sa pagbabago ng mga kondisyon ng paggana nito;
• kinakailangang throughput ng system;
• ang kinakailangang oras ng pagtugon ng system sa isang kahilingan;
• walang problema na operasyon ng system sa kinakailangang mode, sa madaling salita, ang kahandaan at kakayahang magamit ng system upang iproseso ang mga kahilingan ng user;
• kadalian ng operasyon at suporta ng system;
• ang kinakailangang seguridad.

Ang pagganap ay ang pangunahing salik na tumutukoy sa kahusayan ng isang sistema. Ang mahusay na disenyo ay ang pundasyon ng isang mataas na pagganap ng sistema.

Ang disenyo ng mga sistema ng impormasyon ay sumasaklaw sa tatlong pangunahing lugar:

• pagdidisenyo ng mga bagay ng data na ipapatupad sa database;
• pagdidisenyo ng mga programa, mga screen form, mga ulat na magtitiyak sa pagpapatupad ng mga query sa data;
• isinasaalang-alang ang isang partikular na kapaligiran o teknolohiya, katulad ng: topology ng network, configuration ng hardware, ginamit na arkitektura (file-server o client-server), parallel processing, distributed data processing, atbp.

Sa totoong mga kondisyon, ang disenyo ay isang paghahanap para sa isang paraan na nakakatugon sa mga kinakailangan ng pag-andar ng system sa pamamagitan ng mga magagamit na teknolohiya, na isinasaalang-alang ang ibinigay na mga paghihigpit.

Ang anumang proyekto ay napapailalim sa isang bilang ng mga ganap na kinakailangan, halimbawa, ang pinakamataas na oras ng pagbuo ng proyekto, ang pinakamataas na pamumuhunan sa pananalapi sa proyekto, atbp. Ang isa sa mga kahirapan ng disenyo ay hindi ito kasing balangkas ng pagsusuri ng mga kinakailangan sa proyekto o ang pagpapatupad ng isang partikular na solusyon sa disenyo.

Ito ay pinaniniwalaan na ang isang kumplikadong sistema ay hindi maaaring inilarawan sa prinsipyo. Ito, sa partikular, ay may kinalaman sa mga sistema ng pamamahala ng negosyo. Ang isa sa mga pangunahing argumento ay isang pagbabago sa mga kondisyon para sa paggana ng sistema, halimbawa, isang direktiba na pagbabago sa ilang mga daloy ng impormasyon ng bagong pamunuan. Ang isa pang argumento ay ang saklaw ng mga tuntunin ng sanggunian, na para sa isang malaking proyekto ay maaaring daan-daang mga pahina, habang ang teknikal na proyekto ay maaaring maglaman ng mga error. Ang tanong ay lumitaw: marahil ito ay mas mahusay na hindi magsagawa ng mga survey at hindi gumawa ng anumang teknikal na proyekto, ngunit upang isulat ang sistema "mula sa simula" sa pag-asa na ang ilang mga mahimalang pagkakataon ng pagnanais ng customer sa kung ano ang isinulat ng mga programmer, at din na na ang lahat ng ito ay gagana nang matatag?

Kung titingnan mo, napaka unpredictable ba talaga ng development ng system at imposibleng makakuha ng impormasyon tungkol dito? Malamang na ang isang ideya ng sistema sa kabuuan at ang mga paraan (pamamahala) na inilaan para sa pag-unlad nito ay maaaring makuha sa pamamagitan ng mga seminar. Pagkatapos nito, hatiin ang kumplikadong sistema sa mas simpleng mga bahagi, gawing simple ang mga koneksyon sa pagitan ng mga bahagi, magbigay ng kalayaan ng mga bahagi at ilarawan ang mga interface sa pagitan ng mga ito (upang ang pagbabago sa isang bahagi ay hindi awtomatikong nangangailangan ng isang makabuluhang pagbabago sa isa pang bahagi) , pati na rin ang posibilidad ng pagpapalawak ng system at "mga stub" para sa hindi maisasakatuparan sa isa o ibang bersyon ng sistema ng mga pag-andar. Batay sa mga elementarya na pagsasaalang-alang, ang paglalarawan ng kung ano ang dapat na ipatupad sa sistema ng impormasyon ay hindi na tila hindi makatotohanan. Maaari mong sundin ang mga klasikal na diskarte sa pag-unlad ng mga sistema ng impormasyon, isa sa kung saan - ang "waterfall" scheme (Larawan 1) - ay inilarawan sa ibaba. Ang ilang iba pang mga diskarte sa pagbuo ng mga sistema ng impormasyon ay isasaalang-alang sa madaling sabi, kung saan ang paggamit ng mga elemento na inilarawan sa waterfall scheme ay katanggap-tanggap din. Aling diskarte mula sa mga inilarawan sa ibaba ang dapat sundin (at kung makatuwirang gumawa ng sarili mong diskarte) ay sa ilang lawak ay isang bagay ng panlasa at mga pangyayari.

Ang ikot ng buhay ng software ay isang modelo para sa paglikha at paggamit nito. Ang modelo ay sumasalamin sa iba't ibang mga estado nito, simula sa sandaling kailanganin ang software na ito at magtatapos sa sandaling ito ay ganap na hindi magagamit para sa lahat ng mga gumagamit. Ang mga sumusunod na modelo ng siklo ng buhay ay kilala:

• modelo ng cascade. Ang paglipat sa susunod na yugto ay nangangahulugan ng kumpletong pagkumpleto ng gawain sa nakaraang yugto.
• Nakatanghal na modelo na may intermediate na kontrol. Ang pagbuo ng software ay isinasagawa sa mga pag-ulit na may mga loop ng feedback sa pagitan ng mga yugto. Ang mga pagsasaayos sa pagitan ng mga yugto ay maaaring mabawasan ang pagiging kumplikado ng proseso ng pag-unlad kumpara sa modelo ng talon; ang buhay ng bawat isa sa mga yugto ay nakaunat para sa buong panahon ng pag-unlad.
• modelong spiral. Ang partikular na atensyon ay binabayaran sa mga unang yugto ng pag-unlad - pagbuo ng diskarte, pagsusuri at disenyo, kung saan ang pagiging posible ng ilang mga teknikal na solusyon ay nasuri at nabigyang-katwiran sa pamamagitan ng paglikha ng mga prototype (prototyping). Ang bawat pagliko ng spiral ay nagsasangkot ng paglikha ng isang tiyak na bersyon ng produkto o alinman sa mga bahagi nito, habang ang mga katangian at layunin ng proyekto ay tinukoy, ang kalidad nito ay tinutukoy, at ang gawain ng susunod na pagliko ng spiral ay binalak.

Sa ibaba ay isasaalang-alang natin ang ilan sa mga scheme ng pagbuo ng proyekto.

"Waterfall" - scheme ng pagbuo ng proyekto

Kadalasan, ang disenyo ay inilarawan bilang isang hiwalay na yugto ng pagbuo ng proyekto sa pagitan ng pagsusuri at pag-unlad. Gayunpaman, sa katotohanan, walang malinaw na dibisyon ng mga yugto ng pagbuo ng proyekto - ang disenyo, bilang panuntunan, ay walang malinaw na tinukoy na simula at wakas, at madalas na nagpapatuloy sa mga yugto ng pagsubok at pagpapatupad. Sa pagsasalita tungkol sa yugto ng pagsubok, dapat ding tandaan na ang parehong yugto ng pagsusuri at yugto ng disenyo ay naglalaman ng mga elemento ng gawain ng mga tagasubok, halimbawa, upang makakuha ng isang pang-eksperimentong katwiran para sa pagpili ng isang partikular na solusyon, pati na rin upang suriin ang pamantayan ng kalidad. ng resultang sistema. Sa yugto ng operasyon, angkop na pag-usapan ang tungkol sa pagpapanatili ng system.

Sa ibaba ay isasaalang-alang namin ang bawat isa sa mga yugto, tirahan nang mas detalyado sa yugto ng disenyo.

Diskarte

Ang pagtukoy sa isang diskarte ay nagsasangkot ng pagsusuri sa sistema. Ang pangunahing gawain ng survey ay upang masuri ang tunay na saklaw ng proyekto, ang mga layunin at layunin nito, pati na rin upang makakuha ng mga kahulugan ng mga entidad at pag-andar sa isang mataas na antas.

Sa yugtong ito, ang mga mataas na kwalipikadong analyst ng negosyo ay kasangkot, na may patuloy na pag-access sa pamamahala ng kumpanya; ang yugto ay nagsasangkot ng malapit na pakikipag-ugnayan sa mga pangunahing gumagamit ng system at mga eksperto sa negosyo. Ang pangunahing gawain ng pakikipag-ugnayan ay upang makakuha ng kumpletong impormasyon tungkol sa system hangga't maaari (isang kumpleto at hindi malabo na pag-unawa sa mga kinakailangan ng customer) at ilipat ang impormasyong ito sa isang pormal na anyo sa mga analyst ng system para sa kasunod na yugto ng pagsusuri. Bilang isang patakaran, ang impormasyon tungkol sa system ay maaaring makuha bilang isang resulta ng mga pag-uusap o seminar sa pamamahala, mga eksperto at mga gumagamit. Kaya, ang kakanyahan ng negosyong ito, ang mga prospect para sa pag-unlad nito at ang mga kinakailangan para sa system ay tinutukoy.

Sa pagkumpleto ng pangunahing yugto ng survey ng system, ang mga technician ay bumubuo ng malamang na mga teknikal na diskarte at tinatantya ang mga gastos ng hardware, biniling software at pagbuo ng bagong software (na, sa katunayan, ay ipinapalagay ng proyekto).

Ang resulta ng yugto ng pagtukoy ng diskarte ay isang dokumento na malinaw na nagsasaad kung ano ang matatanggap ng customer kung siya ay sumang-ayon na tustusan ang proyekto; kapag natanggap niya ang tapos na produkto (iskedyul ng trabaho); magkano ang magagastos nito (para sa malalaking proyekto, isang iskedyul ng pagpopondo sa iba't ibang yugto ng trabaho ang dapat iguhit). Dapat ipakita ng dokumento hindi lamang ang mga gastos, kundi pati na rin ang mga benepisyo, halimbawa, ang oras ng pagbabayad ng proyekto, ang inaasahang epekto sa ekonomiya (kung maaari itong tantiyahin).

Dapat ilarawan ng dokumento ang:

• mga paghihigpit, mga panganib, mga kritikal na salik na nakakaapekto sa tagumpay ng proyekto, halimbawa, ang oras ng pagtugon ng system sa isang kahilingan ay isang ibinigay na limitasyon, at hindi isang kanais-nais na kadahilanan;
• isang hanay ng mga kondisyon kung saan ito ay dapat na patakbuhin ang hinaharap na sistema: arkitektura ng system, mga mapagkukunan ng hardware at software na ibinigay sa system, mga panlabas na kondisyon para sa paggana nito, komposisyon ng mga tao at trabaho na nagsisiguro sa maayos na paggana ng system;
• mga deadline para sa pagkumpleto ng mga indibidwal na yugto, ang anyo ng paghahatid ng trabaho, mga mapagkukunan na kasangkot sa proseso ng pagbuo ng proyekto, mga hakbang upang maprotektahan ang impormasyon;
• paglalarawan ng mga pag-andar na isinagawa ng system;
• mga kinakailangan sa hinaharap para sa system sa kaganapan ng pag-unlad nito, halimbawa, ang kakayahan ng gumagamit na magtrabaho kasama ang system gamit ang Internet, atbp.;
• mga entity na kinakailangan upang maisagawa ang mga function ng system;
• mga interface at pamamahagi ng mga function sa pagitan ng isang tao at isang system;
• mga kinakailangan para sa software at mga bahagi ng impormasyon ng software, mga kinakailangan para sa DBMS (kung ang proyekto ay dapat na ipatupad para sa ilang DBMS, kung gayon ang mga kinakailangan para sa bawat isa sa kanila, o pangkalahatang mga kinakailangan para sa abstract na DBMS at isang listahan ng DBMS na inirerekomenda para sa proyektong ito na matugunan ang tinukoy na mga kondisyon);
• na hindi ipapatupad sa loob ng balangkas ng proyekto.

Ang gawaing isinagawa sa yugtong ito ay nagpapahintulot sa amin na sagutin ang tanong kung ito ay nagkakahalaga ng pagpapatuloy ng proyektong ito at kung anong mga kinakailangan ng customer ang maaaring matugunan sa ilalim ng ilang mga kundisyon. Maaaring lumabas na ang proyekto ay hindi makatuwiran na magpatuloy, halimbawa, dahil ang ilang mga kinakailangan ay hindi masisiyahan para sa ilang mga layunin na dahilan. Kung ang isang desisyon ay ginawa upang magpatuloy sa proyekto, kung gayon ang isang ideya ng saklaw ng proyekto at pagtatantya ng gastos ay magagamit na para sa susunod na yugto ng pagsusuri.

Dapat pansinin na sa yugto ng pagpili ng isang diskarte, at sa yugto ng pagsusuri, at sa panahon ng disenyo, anuman ang pamamaraan na ginamit sa pagbuo ng proyekto, dapat palaging pag-uri-uriin ang mga nakaplanong pag-andar ng system sa pagkakasunud-sunod ng kahalagahan. . Ang isang posibleng format para sa kumakatawan sa naturang klasipikasyon, ang MoSCoW, ay iminungkahi sa Clegg, Dai at Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Ang pagdadaglat na ito ay nangangahulugang: Dapat mayroon - mga kinakailangang function; Dapat magkaroon - kanais-nais na mga pag-andar; Maaaring magkaroon ng - posibleng mga function; Hindi magkakaroon ng - nawawalang mga feature.

Ang pagpapatupad ng mga pag-andar ng ikalawa at pangatlong kategorya ay limitado ng oras at pinansiyal na balangkas: binubuo namin kung ano ang kinakailangan, pati na rin ang maximum na posibleng bilang ng mga pag-andar ng ikalawa at ikatlong kategorya sa pagkakasunud-sunod ng priyoridad.

Pagsusuri

Ang yugto ng pagsusuri ay nagsasangkot ng isang detalyadong pag-aaral ng mga proseso ng negosyo (mga function na tinukoy sa yugto ng pagpili ng diskarte) at ang impormasyong kinakailangan para sa kanilang pagpapatupad (mga entidad, kanilang mga katangian at relasyon (mga relasyon)). Sa yugtong ito, ang isang modelo ng impormasyon ay nilikha, at sa susunod na yugto ng disenyo, isang modelo ng data ay nilikha.

Ang lahat ng impormasyon tungkol sa system na nakolekta sa yugto ng kahulugan ng diskarte ay pormal at pino sa yugto ng pagsusuri. Ang partikular na atensyon ay dapat bayaran sa pagkakumpleto ng ipinadala na impormasyon, ang pagsusuri ng impormasyon para sa kawalan ng mga kontradiksyon, pati na rin ang paghahanap para sa impormasyon na hindi ginagamit o nadoble. Bilang isang tuntunin, ang customer ay hindi agad bumubuo ng mga kinakailangan para sa system sa kabuuan, ngunit binabalangkas ang mga kinakailangan para sa mga indibidwal na bahagi nito. Bigyang-pansin ang pagkakapare-pareho ng mga sangkap na ito.

Kinokolekta at itinatala ng mga analyst ang impormasyon sa dalawang magkakaugnay na anyo:

• function - impormasyon tungkol sa mga kaganapan at proseso na nangyayari sa negosyo;
• entity - impormasyon tungkol sa mga bagay na mahalaga sa organisasyon at kung saan alam ang isang bagay.

Ang dalawang klasikong resulta ng pagsusuri ay:

• isang hierarchy ng mga function na naghahati sa pagproseso sa mga bahaging bahagi nito (kung ano ang ginagawa at kung ano ang binubuo nito);
• entity-relationship model (Entry Relationship model, ER-model), na naglalarawan sa mga entity, kanilang mga katangian at relasyon (relasyon) sa pagitan nila.

Ang mga resultang ito ay kinakailangan ngunit hindi sapat. Kasama sa mga sapat na resulta ang mga diagram ng daloy ng data at mga diagram ng ikot ng buhay ng entity. Kadalasan, nangyayari ang mga error sa pagsusuri kapag sinusubukang ipakita ang cycle ng buhay ng isang entity sa isang ER diagram.

Sa ibaba ay susuriin natin ang tatlong pinakakaraniwang ginagamit na pamamaraan ng pagsusuri sa istruktura:

• Entity-Relationship Diagrams (ERD), na nagsisilbing gawing pormal ang impormasyon tungkol sa mga entity at kanilang mga relasyon;
• mga diagram ng daloy ng data (Data Flow Diagrams, DFD), na nagsisilbing gawing pormal ang representasyon ng mga function ng system;
• state transition diagrams (State Transition Diagrams, STD), na sumasalamin sa gawi ng system, depende sa oras; Ang mga diagram ng ikot ng buhay ng entity ay nabibilang sa klase ng mga diagram na ito.

Normalisasyon

Upang maiwasan ang mga anomalya sa pagproseso ng data, ginagamit ang normalisasyon. Ang mga prinsipyo ng normalisasyon para sa mga object ng modelo ng impormasyon ay eksaktong kapareho ng para sa mga modelo ng data.

Pinapayagan ang mga uri ng link. Ang mas malapit na pagsusuri sa one-to-one na relasyon (Figure 7) ay halos palaging nagpapakita na ang A at B ay talagang magkaibang mga subset ng parehong paksa o magkaibang punto ng pananaw dito, na may magkaibang pangalan at magkaiba ang paglalarawan. mga link at katangian.

Ang marami-sa-isang relasyon ay ipinapakita sa Fig. 8 .

Ang I ay isang malakas na konstruksyon na ang isang entry ng entity B ay hindi maaaring gawin nang hindi sabay na lumilikha ng kahit isang nauugnay na entry ng entity A.

II ay ang pinakakaraniwang paraan ng komunikasyon. Ipinapalagay nito na ang bawat paglitaw ng entity A ay maaari lamang umiral sa konteksto ng isa (at isa lamang) na paglitaw ng entity B. Sa turn, ang mga paglitaw ng B ay maaaring umiral kapwa may kaugnayan sa mga paglitaw ng A, at kung wala ito.

III - bihirang gamitin. Ang parehong A at B ay maaaring umiral nang walang koneksyon sa pagitan nila.

Ang maraming-sa-maraming relasyon ay ipinapakita sa Fig. 9 .

I - ang ganitong konstruksiyon ay madalas na nagaganap sa simula ng yugto ng pagsusuri at nangangahulugan ng isang koneksyon - alinman ay hindi lubos na nauunawaan at nangangailangan ng karagdagang pahintulot, o sumasalamin sa isang simpleng kolektibong relasyon - isang dobleng naka-link na listahan.

II - bihirang gamitin. Ang ganitong mga link ay palaging napapailalim sa karagdagang detalye.

Isaalang-alang natin ngayon ang mga recursive link (Larawan 10).

Ako - bihira, ngunit nangyayari. Sumasalamin sa mga link ng isang alternatibong uri.

II - medyo madalas na ginagamit upang ilarawan ang mga hierarchy na may anumang bilang ng mga antas.

III - nagaganap sa mga unang yugto. Madalas na sumasalamin sa istraktura ng "listahan ng mga materyales" (mutual nesting ng mga bahagi). Halimbawa: ang bawat COMPONENT ay maaaring binubuo ng isa o higit pang (ibang) COMPONENT at ang bawat COMPONENT ay maaaring gamitin sa isa o higit pang (ibang) COMPONENT.

Di-wastong mga uri ng link. Kabilang sa mga di-wastong uri ng relasyon ang sumusunod: ang mandatoryong relasyong marami-sa-maraming (Figure 11) at ang hanay ng mga recursive na relasyon (Figure 12).

Ang isang ipinag-uutos na many-to-many na relasyon ay karaniwang imposible. Ang ganitong relasyon ay nangangahulugan na wala sa mga pangyayari ng A ang maaaring umiral nang walang B, at kabaliktaran. Sa katunayan, ang bawat naturang konstruksiyon ay palaging lumiliko na mali.

Mga diagram ng daloy ng data

Ang lohikal na DFD (Larawan 13) ay nagpapakita ng mga pinagmumulan ng data at mga lababo (destinasyon) sa labas ng system, kinikilala ang mga lohikal na pag-andar (mga proseso) at mga pangkat ng mga elemento ng data na nag-uugnay sa isang function sa isa pa (mga stream), at kinikilala din ang mga imbakan ng data (mga accumulator), kung saan ginagawa ang pag-access. Ang mga istruktura ng daloy ng data at ang mga kahulugan ng mga bahagi nito ay iniimbak at na-parse sa diksyunaryo ng data. Ang bawat lohikal na function (proseso) ay maaaring detalyado gamit ang mas mababang antas ng DFD; kapag ang karagdagang detalye ay hindi na kapaki-pakinabang, ang isa ay nagpapatuloy sa pagpapahayag ng lohika ng function gamit ang isang detalye ng proseso (mini-specification). Ang nilalaman ng bawat tindahan ay iniimbak din sa isang diksyunaryo ng data, at ang modelo ng data ng tindahan ay inilalantad gamit ang mga ER diagram.

Sa partikular, hindi ipinapakita ng DFD ang mga prosesong kumokontrol sa aktwal na daloy ng data at hindi nakikilala ang pagitan ng wasto at di-wastong mga landas. Ang mga DFD ay naglalaman ng maraming kapaki-pakinabang na impormasyon, at bilang karagdagan:

• pinapayagan kang ipakita ang system sa mga tuntunin ng data;
• ilarawan ang mga panlabas na mekanismo ng feed ng data na mangangailangan ng mga espesyal na interface;
• payagan na kumatawan sa parehong awtomatiko at manu-manong mga proseso ng system;
• magsagawa ng data-oriented na partitioning ng buong system.

Ang mga daloy ng data ay ginagamit upang imodelo ang paglilipat ng impormasyon (o maging ang mga pisikal na bahagi) mula sa isang bahagi ng isang sistema patungo sa isa pa. Ang mga daloy sa mga diagram ay kinakatawan ng pinangalanang mga arrow, ang mga arrow ay nagpapahiwatig ng direksyon ng daloy ng impormasyon. Minsan ang impormasyon ay maaaring lumipat sa isang direksyon, maproseso at ibalik sa pinagmulan nito. Ang ganitong sitwasyon ay maaaring imodelo ng alinman sa dalawang magkaibang daloy, o ng isang bidirectional na isa.

Binabago ng isang proseso ang isang input stream sa isang output stream ayon sa aksyon na tinukoy ng pangalan ng proseso. Ang bawat proseso ay dapat magkaroon ng isang natatanging numero upang i-reference ito sa loob ng diagram. Maaaring gamitin ang numerong ito kasabay ng numero ng diagram upang magbigay ng natatanging index ng proseso sa buong modelo.

Ang imbakan ng data (imbakan ng data) ay nagbibigay-daan sa iyo na tukuyin ang data sa isang bilang ng mga lugar na maiimbak sa memorya sa pagitan ng mga proseso. Sa katunayan, ang imbakan ay kumakatawan sa "mga hiwa" ng mga daloy ng data sa oras. Ang impormasyong nilalaman nito ay maaaring gamitin anumang oras pagkatapos itong matukoy, at ang data ay maaaring mapili sa anumang pagkakasunud-sunod. Ang pangalan ng repository ay dapat tukuyin ang mga nilalaman nito. Sa kaso kapag ang daloy ng data ay pumasok (umalis) sa (mula sa) imbakan at ang istraktura nito ay tumutugma sa istraktura ng imbakan, dapat itong magkaroon ng parehong pangalan, na hindi kailangang ipakita sa diagram.

Ang isang panlabas na entity (terminator) ay kumakatawan sa isang entity sa labas ng konteksto ng system, na siyang pinagmulan o tagatanggap ng data ng system. Ang kanyang pangalan ay dapat na naglalaman ng isang pangngalan, tulad ng "Kliyente". Ipinapalagay na ang mga bagay na kinakatawan ng naturang mga node ay hindi dapat lumahok sa anumang pagproseso.

Ilang mga prinsipyo para sa pagsuri sa kalidad at pagkakumpleto ng modelo ng impormasyon
(pinagmulan - Richard Barker, Paraan ng Kaso: Pagmomodelo ng Relasyon ng Entity, Addison-Wesley, 1990)

Kung nais mong lumikha ng isang de-kalidad na modelo, kakailanganin mong gumamit ng tulong ng mga analyst na bihasa sa teknolohiya ng CASE. Gayunpaman, hindi ito nangangahulugan na ang mga analyst lamang ang dapat na kasangkot sa pagbuo at kontrol ng modelo ng impormasyon. Malaki rin ang maitutulong ng tulong ng mga kasamahan. Isali sila sa pagsuri sa layunin at sa isang detalyadong pag-aaral ng binuo na modelo, kapwa sa mga tuntunin ng lohika at sa mga tuntunin ng pagsasaalang-alang sa mga aspeto ng lugar ng paksa. Karamihan sa mga tao ay mas madaling makahanap ng mga bahid sa trabaho ng ibang tao.

Regular na ipakita ang iyong modelo ng impormasyon o ang mga indibidwal na fragment nito kung saan mayroon kang mga pagdududa para sa pag-apruba ng mga user. Bigyang-pansin ang mga pagbubukod sa mga patakaran at paghihigpit.

Kalidad ng entidad

Ang pangunahing garantiya ng kalidad ng isang nilalang ay ang sagot sa tanong kung ang bagay ay talagang isang nilalang, iyon ay, isang mahalagang bagay o kababalaghan, impormasyon tungkol sa kung saan dapat na nakaimbak sa database.

Listahan ng mga tanong sa pag-verify para sa entity:

• Ang pangalan ba ng isang entity ay nagpapakita ng kakanyahan ng bagay na ito?
• Mayroon bang intersection sa ibang entity?
• Mayroon bang hindi bababa sa dalawang katangian?
• Mayroon bang hindi hihigit sa walong mga katangian sa kabuuan?
• Mayroon bang anumang kasingkahulugan/homonym para sa entity na ito?
• Ang entity ba ay ganap na tinukoy?
• Mayroon bang natatanging identifier?
• Mayroon bang kahit isang koneksyon?
• Mayroon bang kahit isang function para sa paglikha, paghahanap, pag-update, pagtanggal, pag-archive, at paggamit ng halaga ng entity?
• Mayroon bang kasaysayan ng mga pagbabago?
• Mayroon bang pagsunod sa mga prinsipyo ng normalisasyon ng data?
• Umiiral ba ang parehong entity sa ibang sistema ng aplikasyon, marahil sa ilalim ng ibang pangalan?
• Masyado bang pangkalahatan ang kakanyahan?
• Sapat ba ang antas ng paglalahat na nakapaloob dito?

Listahan ng mga tanong sa screening para sa subtype:

• Mayroon bang anumang mga overlap sa iba pang mga subtype?
• Ang subtype ba ay may anumang mga katangian at/o mga relasyon?
• Lahat ba sila ay may sariling natatanging identifier, o lahat ba sila ay nagmamana ng isa mula sa supertype?
• Mayroon bang kumpletong hanay ng mga subtype?
• Hindi ba ang isang subtype ay isang halimbawa ng isang pangyayari sa entity?
• May alam ka bang anumang mga katangian, relasyon, at kundisyon na nagpapakilala sa subtype na ito mula sa iba?

Kalidad ng Katangian

Kinakailangang malaman kung ang mga ito ay talagang mga katangian, iyon ay, kung inilalarawan nila ang entity na ito sa isang paraan o iba pa.

Listahan ng mga tanong sa seguridad para sa isang katangian:

• Ang pangalan ba ng isang katangian ay isang pangngalan na sumasalamin sa kakanyahan ng ari-arian na tinutukoy ng katangian?
• Hindi ba kasama sa pangalan ng attribute ang pangalan ng entity (hindi dapat)?
• Ang katangian ba ay may isang halaga lamang sa isang pagkakataon?
• Mayroon bang nawawalang mga dobleng halaga (o mga grupo)?
• Inilalarawan ba ang format, haba, wastong mga halaga, derivation algorithm, atbp?
• Maaari bang ang attribute na ito ay isang inalis na entity na magiging kapaki-pakinabang para sa isa pang system ng application (umiiral o iminungkahi)?

Kailangan nating alamin kung ang mga relasyon ay nagpapakita ng mga talagang mahalagang relasyon na naobserbahan sa pagitan ng mga entity.

Listahan ng mga tanong sa pagpapatunay para sa komunikasyon:

• Mayroon bang paglalarawan para sa bawat partidong kasangkot, tumpak ba itong nagpapakita ng nilalaman ng relasyon, at akma ba ito sa tinatanggap na syntax?
• Dalawa lang ba ang kasali?

Hindi ba portable ang koneksyon?

• Tinukoy ba ang antas ng koneksyon at obligasyon para sa bawat partido?
• Pinapayagan ba ang istraktura ng koneksyon?

Ang disenyo ba ng koneksyon ay isa sa mga bihirang ginagamit?

• Hindi ba redundant?
• Hindi ba ito nagbabago sa paglipas ng panahon?
• Kung ang koneksyon ay sapilitan, ito ba ay palaging nagpapakita ng kaugnayan sa entity na kumakatawan sa kabaligtaran na bahagi?

Para sa eksklusibong asosasyon:

• Ang lahat ba ng dulo ng link na sakop ng isang eksklusibong arko ay may parehong uri ng pagbubuklod?
• Lahat ba ng mga ito ay tumutukoy sa parehong entity?
kanin. 15) tulad ng isang agnas. Isaalang-alang ang pinakasimpleng problema ng pag-isyu ng invoice sa isang customer kapag ang mga kalakal ay inilabas mula sa isang bodega, sa kondisyon na ang hanay ng mga kalakal na gustong bilhin ng customer ay alam na (hindi namin isasaalang-alang ang problema sa pagpili ng mga kalakal sa halimbawang ito).

Malinaw, ang operasyon ng pagpili at pagkalkula ng mga diskwento ay maaari ding hatiin sa mas maliliit na operasyon, tulad ng pagkalkula ng mga diskwento para sa katapatan (ang customer ay bumibili ng mga kalakal sa loob ng mahabang panahon) at pagkalkula ng mga diskwento para sa dami ng mga kalakal na binili. Ang mga pag-andar ng atom ay inilarawan nang detalyado, halimbawa gamit ang DFD at STD. Malinaw, ang gayong paglalarawan ng mga pag-andar ay hindi nagbubukod ng karagdagang pandiwang paglalarawan (halimbawa, mga komento).

Dapat pansinin na sa yugto ng pagsusuri, dapat bigyang pansin ang mga pag-andar ng pagsusuri at pagproseso ng mga posibleng pagkakamali at paglihis mula sa inaasahang pamantayan ng system. Ang mga pinaka-kritikal na proseso para sa pagpapatakbo ng system ay dapat na matukoy at isang partikular na mahigpit na pagsusuri ng error ay dapat ibigay para sa kanila. Ang DBMS error handling (return codes), bilang panuntunan, ay isang hiwalay na hanay ng mga function o isang solong function.

Pagpipino ng Diskarte

Sa yugto ng pagsusuri, ang hardware at software na pinili para sa panghuling pagpapatupad ay pino. Para dito, maaaring kasangkot ang mga grupo ng pagsubok at mga teknikal na espesyalista. Kapag nagdidisenyo ng isang sistema ng impormasyon, mahalagang isaalang-alang ang karagdagang pag-unlad ng system, halimbawa, isang pagtaas sa dami ng naprosesong data, isang pagtaas sa intensity ng daloy ng mga kahilingan, mga pagbabago sa mga kinakailangan para sa pagiging maaasahan. ng sistema ng impormasyon.

Sa yugto ng pagsusuri, ang mga hanay ng mga modelo ng gawain ay tinutukoy upang makakuha ng mga paghahambing na katangian ng iba't ibang DBMS na isinasaalang-alang sa yugto ng pagtukoy ng diskarte para sa pagpapatupad ng sistema ng impormasyon. Sa yugto ng pagtukoy ng diskarte, maaaring pumili ng isang DBMS. Marami nang data tungkol sa system sa yugto ng pagsusuri, at mas detalyado ang mga ito. Ang data na nakuha, pati na rin ang mga katangian na ipinadala ng mga pangkat ng pagsubok, ay maaaring magpakita na ang pagpili ng DBMS sa yugto ng pagtukoy ng diskarte ay hindi tama at na ang napiling DBMS ay hindi maaaring matugunan ang ilang mga kinakailangan ng sistema ng impormasyon. Ang parehong data ay maaaring makuha tungkol sa pagpili ng hardware platform at operating system. Ang pagkuha ng mga naturang resulta ay nagpapasimula ng pagbabago sa data na nakuha sa yugto ng pagtukoy ng diskarte, halimbawa, ang pagtatantya ng gastos para sa proyekto ay muling kinalkula.

Ang pagpili ng mga tool sa pag-unlad ay tinukoy din sa yugto ng pagsusuri. Dahil ang bahagi ng pagsusuri ay nagbibigay ng isang mas kumpletong larawan ng sistema ng impormasyon kaysa sa ginawa nito sa yugto ng pagtukoy ng diskarte, ang plano sa trabaho ay maaaring isaayos. Kung ang tool sa pag-unlad na pinili sa nakaraang yugto ay hindi pinapayagan ang isa o ibang bahagi ng trabaho na makumpleto sa loob ng tinukoy na oras, pagkatapos ay isang desisyon ang ginawa upang baguhin ang mga deadline (bilang isang panuntunan, ito ay isang pagtaas sa oras ng pag-unlad) o para baguhin ang development tool. Kapag pumipili ng isa o ibang tool, dapat isaalang-alang ng isa ang pagkakaroon ng mataas na kwalipikadong tauhan na nagmamay-ari ng mga napiling tool sa pag-unlad, pati na rin ang pagkakaroon ng mga administrator ng napiling DBMS. Pipino rin ng mga rekomendasyong ito ang data ng yugto ng pagpili ng diskarte (ang hanay ng mga kundisyon kung saan dapat patakbuhin ang hinaharap na sistema).

Ang mga limitasyon, panganib, kritikal na mga kadahilanan ay tinukoy din. Kung ang anumang mga kinakailangan ay hindi masiyahan sa sistema ng impormasyon na ipinatupad gamit ang DBMS at mga tool sa software na pinili sa yugto ng pagtukoy ng diskarte, kung gayon ito rin ang magsisimula ng pagpipino at pagbabago ng data na nakuha (sa huli, mga pagtatantya sa gastos at mga plano sa trabaho, at posibleng magbago sa mga kinakailangan ng customer para sa system, halimbawa, ang kanilang pagpapahina). Ang mga tampok na hindi ipapatupad sa system ay inilalarawan nang mas detalyado.

ComputerPress 9 "2001