Mga yugto ng karaniwang disenyo ng ais. Disenyo ng isang automated na warehouse accounting system gamit ang Rational Rose CASE tool. Mga pamamaraan para sa pagsasagawa ng gawaing disenyo
Mga yugto ng pag-unlad ng mga sistema ng CASE
Sa nakalipas na dekada, lumitaw ang isang bagong direksyon sa disenyo ng mga sistema ng impormasyon - disenyong tinutulungan ng computer gamit ang mga tool ng CASE. Ang terminong CASE (Computer Aided System/Software Engineering) ay orihinal na tinutukoy lamang sa automation ng software development; sinasaklaw na nito ngayon ang buong proseso ng pagbuo ng kumplikadong AIS.
Sa una, ang mga teknolohiya ng CASE ay binuo upang mapagtagumpayan ang mga pagkukulang ng pamamaraan ng disenyo ng istruktura (kahirapan sa pag-unawa, mataas na lakas ng paggawa at gastos sa paggamit, kahirapan sa paggawa ng mga pagbabago sa mga detalye ng disenyo, atbp.) sa pamamagitan ng automation at pagsasama ng mga sumusuportang kasangkapan.
Ang mga teknolohiya ng CASE ay hindi umiiral sa kanilang sarili at hindi independyente. I-automate at ino-optimize nila ang paggamit ng nauugnay na pamamaraan at ginagawang posible upang mapataas ang kahusayan ng aplikasyon nito.
Sa ibang salita, Mga teknolohiya ng CASE kumakatawan sa isang hanay ng mga pamamaraan para sa pagsusuri, disenyo, pag-unlad at pagpapanatili ng mga kumplikadong sistema ng software, suportado ng isang hanay ng mga magkakaugnay na mga tool sa automation na nagbibigay-daan sa iyo upang biswal na imodelo ang lugar ng paksa, pag-aralan ang modelong ito sa lahat ng mga yugto ng pag-unlad at pagpapanatili ng AIS at bumuo ng mga aplikasyon alinsunod sa mga pangangailangan ng impormasyon ng mga gumagamit.
Sinasaklaw ng mga modernong CASE tool ang malawak na hanay ng suporta para sa maraming teknolohiya ng disenyo ng AIS - mula sa simpleng mga tool sa pagsusuri at dokumentasyon hanggang sa full-scale na mga tool sa automation na sumasaklaw sa buong cycle ng buhay ng AIS. Ang pinakamalaking pangangailangan para sa paggamit ng mga sistema ng CASE ay nararanasan sa mga unang yugto ng pag-unlad - sa mga yugto ng pagsusuri at pagtutukoy ng mga kinakailangan para sa AIS. Ang mga pagkakamali na ginawa dito ay halos nakamamatay, ang kanilang gastos ay makabuluhang lumampas sa halaga ng mga pagkakamali sa mga huling yugto ng pag-unlad.
Ang mga pangunahing layunin ng mga tool ng CASE ay upang paghiwalayin ang mga unang yugto (pagsusuri at disenyo) mula sa mga kasunod at hindi pasanin ang mga developer ng mga detalye ng kapaligiran ng pag-unlad at pagpapatakbo ng system.
Karamihan sa mga modernong CASE system ay gumagamit ng mga pamamaraan istruktural at/o pagsusuri sa object-oriented At disenyo, batay sa paggamit ng mga visual na tsart, mga graph, mga talahanayan at mga diagram.
Sa wastong paggamit ng mga tool ng CASE, ang isang makabuluhang pagtaas sa produktibidad ng paggawa ay nakakamit, na may halaga (ayon sa mga pagtatantya ng mga dayuhang kumpanya na gumagamit ng mga teknolohiya ng CASE) mula 100 hanggang 600%, depende sa dami, pagiging kumplikado ng trabaho at karanasan sa CASE. Kasabay nito, ang lahat ng mga yugto ng ikot ng buhay ng AIS ay nagbabago, ngunit ang pinakamalaking pagbabago ay nauugnay sa pagsusuri at mga yugto ng disenyo (Talahanayan 2.5, 2.6).
Talahanayan 2.5. Mga pagtatantya ng mga gastos sa paggawa ayon sa mga yugto ng ikot ng buhay ng AIS
Talahanayan 2.6. Paghahambing ng paggamit ng CASE at tradisyonal pag-unlad
Ang paggamit ng mga tool ng CASE ay hindi lamang nag-automate ng structural methodology at ginagawang posible na gumamit ng mga modernong pamamaraan ng system at software engineering, ngunit nagbibigay din ng iba pang mga pakinabang (Larawan 2.22), sa partikular:
1. pinapabuti ang kalidad ng binuong software sa pamamagitan ng awtomatikong pagbuo at kontrol;
2. nagbibigay-daan sa iyo na bawasan ang oras para sa paglikha ng isang prototype ng AIS, na ginagawang posible upang masuri ang kalidad at pagiging epektibo ng proyekto sa mga unang yugto;
3. pinapabilis ang proseso ng disenyo at pagbuo;
4. nagbibigay-daan sa iyo na muling gamitin ang mga nabuong bahagi;
5. sumusuporta sa suporta ng AIS;
6. nagpapalaya sa iyo mula sa karaniwang gawain sa pagdodokumento ng proyekto, dahil gumagamit ito ng built-in na dokumenter;
7. pinapadali ang pagtutulungan ng magkakasama sa proyekto.
kanin. 2.22. Mga kalamangan ng pagbuo ng AIS gamit ang mga teknolohiya ng CASE: A- koepisyent ng pagbawas sa gastos ng proyekto; b - kadahilanan ng pagbabawas ng oras ng pag-unlad
Karamihan sa mga tool ng CASE ay batay sa apat na pangunahing konsepto: pamamaraan, pamamaraan, notasyon, tool [ 11,15, 16].
Pamamaraan tumutukoy sa mga alituntunin para sa pagsusuri at pagpili ng mga solusyon sa disenyo at pagbuo ng AIS, mga yugto ng trabaho, ang kanilang pagkakasunud-sunod, mga panuntunan para sa pamamahagi at layunin ng mga pamamaraan.
Paraan - mga pamamaraan para sa pagbuo ng mga bahagi at ang kanilang mga paglalarawan.
Mga notasyon ay nilayon upang ilarawan ang pangkalahatang istraktura ng system, mga elemento ng data, mga yugto ng pagproseso, maaaring magsama ng mga graph, diagram, talahanayan, flowchart, pormal at natural na mga wika.
Mga Pasilidad- mga tool para sa pagsuporta at pagpapalakas ng mga pamamaraan; Sinusuportahan ang gawain ng mga user kapag gumagawa at nag-e-edit ng proyekto sa isang interactive na mode, tumutulong sa pag-aayos ng proyekto sa anyo ng isang hierarchy ng mga antas ng abstraction, at sinusuri ang pagsunod ng mga bahagi.
Pag-uuri ng mga tool ng CASE
Wala pa ring matatag na pag-uuri ng mga tool sa CASE ang natukoy na lamang depende sa iba't ibang pamantayan sa pag-uuri. Nasa ibaba ang ilan sa mga ito.
Tumutok sa mga teknolohikal na yugto at proseso ng ikot ng buhay ng AIS:
1. mga kasangkapan sa pagsusuri at disenyo. Ginagamit upang lumikha ng mga pagtutukoy at disenyo ng system. Sinusuportahan nila ang mga kilalang pamamaraan ng disenyo;
2. mga tool sa disenyo ng database. Magbigay ng lohikal na pagmomodelo ng data, pagbuo ng mga istruktura ng database;
3. mga kasangkapan sa pamamahala ng mga kinakailangan;
4. mga tool sa pamamahala ng pagsasaayos ng software. Suportahan ang programming, pagsubok, awtomatikong pagbuo ng software mula sa mga detalye;
5. mga tool sa dokumentasyon;
6. mga kasangkapan sa pagsubok;
7. Mga tool sa pamamahala ng proyekto. Suportahan ang pagpaplano, kontrol, pakikipag-ugnayan;
8. reverse engineering tool na idinisenyo upang ilipat ang isang umiiral na sistema sa isang bagong kapaligiran.
Mga suportadong pamamaraan ng disenyo[ 11, 12, 15, 16]:
1. function-oriented (structure-oriented);
2. object-oriented;
3. complex-oriented (set ng mga pamamaraan ng disenyo).
Mga sinusuportahang graphical charting notation:
1. na may nakapirming notasyon;
2. na may hiwalay na notasyon;
3. na may pinakakaraniwang notasyon.
Degree ng integration:
1. mga pantulong na programa (Mga Tool), na nakapag-iisa na nilulutas ang isang autonomous na problema;
2. development packages (Toolkit), na isang set ng mga tool na nagbibigay ng tulong para sa isa sa mga klase ng software task;
3. mga hanay ng pinagsama-samang mga tool na konektado sa pamamagitan ng isang karaniwang disenyo ng data base - isang repositoryo, pag-automate ng lahat o bahagi ng trabaho sa iba't ibang yugto ng paglikha ng isang AIS (Workbench).
Kolektibong pagbuo ng proyekto:
1. walang suporta para sa sama-samang pag-unlad;
2. nakatutok sa pagbuo ng proyekto sa totoong oras;
3. nakatutok sa paraan ng pagsasama-sama ng mga subproyekto.
Mga uri ng CASE tool:
1. mga tool sa pagsusuri (Upper CASE); sa mga espesyalista sila ay tinatawag na mga tool sa pagpaplano ng computer. Gamit ang mga tool na ito ng CASE, isang modelo ang binuo na sumasalamin sa lahat ng umiiral na mga detalye. Ito ay naglalayong maunawaan ang pangkalahatan at tiyak na mga mekanismo ng paggana, magagamit na mga kakayahan, mapagkukunan, at mga layunin ng proyekto alinsunod sa layunin ng kumpanya. Binibigyang-daan ka ng mga tool na ito na pag-aralan ang iba't ibang mga sitwasyon, pag-iipon ng impormasyon para sa paggawa ng pinakamainam na mga desisyon;
2. mga tool sa pagsusuri at disenyo (Middle CASE); ay itinuturing na mga tool upang suportahan ang pagsusuri ng mga kinakailangan at mga yugto ng disenyo ng mga detalye at istraktura ng AIS. Ang pangunahing resulta ng paggamit ng isang average na tool ng CASE ay isang makabuluhang pagpapasimple ng disenyo ng system, dahil ang disenyo ay nagiging isang umuulit na proseso ng pagtatrabaho sa mga kinakailangan para sa AIS. Bilang karagdagan, ang karaniwang mga tool ng CASE ay nagbibigay ng mabilis na dokumentasyon ng mga kinakailangan;
3. software development tools (Mababa); sumusuporta sa mga sistema ng pagbuo ng software ng AIS. Naglalaman ang mga ito ng mga diksyonaryo ng system at mga graphical na tool na nag-aalis ng pangangailangan na bumuo ng mga pisikal na detalye - may mga pagtutukoy ng system na direktang isinalin sa mga code ng programa ng system na binuo (hanggang sa 80% ng mga code ay awtomatikong nabuo). Ang mga pangunahing bentahe ng lower CASE tool ay isang makabuluhang pagbawas sa oras ng pag-develop, mas madaling pagbabago, at suporta para sa pagtatrabaho sa mga prototype.
Ang mga tool ng CASE ay inuri din ayon sa uri at arkitektura ng teknolohiya ng computer, at ayon sa uri ng operating system.
Sa kasalukuyan, ang merkado ng software ay kinakatawan ng isang malawak na iba't ibang mga software, kabilang ang mga tool ng CASE ng halos alinman sa mga nakalistang klase.
Mga katangian ng mga tool ng CASE
Silverrun. CASE tool na Silverrun mula sa American company na Computer Systems Advisers, Inc. (CSA) ay ginagamit para sa pagsusuri at disenyo ng business-class na AIS at mas nakatutok sa spiral life cycle model. Naaangkop ito upang suportahan ang anumang pamamaraan batay sa hiwalay na pagbuo ng mga modelo ng pagganap at impormasyon (mga diagram ng daloy ng data at mga diagram ng relasyon sa entity).
Ang pagpapasadya para sa isang partikular na pamamaraan ay tinitiyak sa pamamagitan ng pagpili ng kinakailangang graphical na notasyon ng mga modelo at isang hanay ng mga panuntunan para sa pagsuri sa mga detalye ng disenyo. Ang system ay may mga nakahanda nang setting para sa pinakakaraniwang pamamaraan: DATARUN (ang pangunahing pamamaraan na sinusuportahan ng Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Para sa bawat konsepto na ipinakilala sa proyekto, posibleng magdagdag ng sarili mong mga deskriptor. Binibigyang-daan ka ng arkitektura ng Silverrun na palaguin ang iyong kapaligiran sa pag-unlad kung kinakailangan.
meron si Silverrun modular na istraktura at binubuo ng apat na module, ang bawat isa ay isang independiyenteng produkto at maaaring bilhin at gamitin nang hiwalay.
1. Module para sa pagbuo ng mga modelo ng proseso ng negosyo sa anyo ng mga diagram ng daloy ng data, binibigyang-daan ka ng Business Process Modeler (BPM) na imodelo ang paggana ng isang automated na organisasyon o isang nilikhang automated na sistema ng impormasyon. Ang kakayahang magtrabaho sa mga napaka-kumplikadong modelo ay ibinibigay ng mga function ng awtomatikong muling pag-numero, nagtatrabaho sa puno ng proseso (kabilang ang visual na pag-drag ng mga sanga), pagtanggal at pag-attach ng mga bahagi ng modelo para sa kolektibong pag-unlad. Maaaring ipakita ang mga diagram sa ilang paunang natukoy na mga notasyon, kabilang ang Yourdon/DeMarco at Gane/Sarson. Posible ring gumawa ng sarili mong mga notasyon, halimbawa, magdagdag ng mga field na tinukoy ng user sa bilang ng mga descriptor na ipinapakita sa diagram.
2. Module ng Pagmomodelo ng Konseptwal na Data Nagbibigay-daan sa Entity-Relationship eXpert (ERX) ang pagbuo ng mga modelo ng data ng entity-relationship na hindi nakatali sa isang partikular na pagpapatupad. Binibigyang-daan ka ng built-in na expert system na lumikha ng tamang normalized na modelo ng data sa pamamagitan ng pagsagot sa mga makabuluhang tanong tungkol sa kaugnayan ng data. Ang awtomatikong pagbuo ng isang modelo ng data mula sa mga paglalarawan ng mga istruktura ng data ay ibinigay. Ang pagsusuri sa mga functional na dependency ng mga katangian ay ginagawang posible upang suriin ang pagsunod ng modelo sa mga kinakailangan ng ikatlong normal na anyo at matiyak ang kanilang katuparan. Ang na-verify na modelo ay ipinapasa sa module ng Relational Data Modeler.
3. Relational Modeling Module Nagbibigay-daan sa iyo ang Relational Data Modeler (RDM) na lumikha ng mga detalyadong modelo ng entity-relationship para sa pagpapatupad sa isang relational database. Ang module na ito ay nagdodokumento ng lahat ng mga construct na nauugnay sa pagbuo ng isang database: mga index, trigger, stored procedures, atbp. Ang flexible, nababago na notation at extensibility ng repository ay nagbibigay-daan sa iyo upang gumana sa anumang pamamaraan. Ang kakayahang lumikha ng mga subschema ay sumusunod sa diskarte ng ANSI SPARC upang kumatawan sa isang database schema. Parehong ibinahagi ang mga node sa pagpoproseso at mga view ng user ay nakamodelo sa subcircuit na wika. Ang module na ito ay nagbibigay ng disenyo at kumpletong dokumentasyon ng mga relational database.
4. Manager ng Repository ng Workgroup Ang Workgroup Repository Manager (WRM) ay ginagamit bilang isang diksyunaryo ng data upang mag-imbak ng impormasyon na karaniwan sa lahat ng mga modelo, at nagbibigay din ng pagsasama-sama ng mga module ng Silverrun sa isang kapaligiran ng disenyo.
Ang bentahe ng tool na Silverrun CASE ay ang mataas na flexibility at iba't ibang visual na paraan para sa pagbuo ng mga modelo, at ang kawalan ay ang kakulangan ng mahigpit na kontrol sa isa't isa sa pagitan ng mga bahagi ng iba't ibang mga modelo (halimbawa, ang kakayahang awtomatikong magpalaganap ng mga pagbabago sa pagitan ng mga DFD ng iba't ibang mga antas ng agnas). Dapat tandaan, gayunpaman, na ang kawalan na ito ay maaari lamang maging makabuluhan kung ang isang waterfall life cycle model ay ginagamit.
Kasama sa Silverrun ang:
1. awtomatikong pagbuo ng mga schema ng database para sa pinakakaraniwang DBMS: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase;
2. paglilipat ng data sa mga tool sa pagbuo ng application: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.
Kaya, posibleng ganap na tukuyin ang database core gamit ang lahat ng feature ng isang partikular na DBMS: trigger, stored procedures, referential integrity constraints. Kapag gumagawa ng isang application, ang data na inilipat mula sa imbakan ng Silverrun ay ginagamit upang awtomatikong bumuo ng mga object ng interface o upang mabilis na gawin ang mga ito nang manu-mano.
Upang makipagpalitan ng data sa iba pang mga tool sa automation ng disenyo, lumikha ng mga espesyal na pamamaraan para sa pagsusuri at pagsuri sa mga detalye ng disenyo, at pag-compile ng mga espesyal na ulat alinsunod sa iba't ibang mga pamantayan, ang Silverrun system ay nagbibigay ng tatlong paraan upang mag-output ng impormasyon ng disenyo sa mga panlabas na file.
1. Sistema ng pag-uulat. Ang mga ulat ay output sa mga text file.
2. Export/import system. Hindi lamang ang mga nilalaman ng export file ang tinukoy, kundi pati na rin ang mga record separator, field separator sa mga record, at start at end marker ng mga text field. Ang mga nasabing export file ay maaaring mabuo at ma-upload sa repositoryo. Ginagawa nitong posible na makipagpalitan ng data sa iba't ibang mga system: iba pang CASE tool, DBMS, text editor at spreadsheet.
3. Pag-iimbak ng repositoryo sa mga panlabas na file na may access gamit ang mga driver ng ODBC. Upang ma-access ang data ng repository mula sa mga pinakakaraniwang DBMS, posibleng direktang iimbak ang lahat ng impormasyon ng proyekto sa format ng mga DBMS na ito.
Sinusuportahan ng Silverrun ang dalawang paraan ng pangkatang gawain:
1) ang karaniwang bersyon ng single-user ay may mekanismo para sa kinokontrol na paghahati at pagsasama ng mga modelo. Ang modelo ay maaaring hatiin sa mga bahagi at ipamahagi sa ilang mga developer. Pagkatapos ng detalyadong pag-unlad, ang mga bahagi ay muling pinagsama sa isang solong modelo;
2) ang bersyon ng network ng Silverrun ay nagbibigay-daan sa parallel group work sa mga modelong nakaimbak sa isang network repository batay sa Oracle, Sybase o Informix DBMS. Kasabay nito, maraming developer ang maaaring gumana sa parehong modelo, dahil nangyayari ang pag-lock ng object sa antas ng mga indibidwal na elemento ng modelo.
JAM. Ang application development tool na JYACC's Application Manager (JAM) ay produkto ng JYACC Ang pangunahing tampok ay ang pagsunod sa RAD methodology, dahil pinapayagan ka ng JAM na mabilis na ipatupad ang application development cycle, na binubuo ng pagbuo ng susunod na bersyon ng application prototype. isinasaalang-alang ang mga kinakailangan na tinukoy sa nakaraang hakbang, at ipakita ito sa gumagamit.
Ang JAM ay may modular na istraktura at binubuo ng mga sumusunod na bahagi:
1. system kernels;
2. JAM/DBi - mga dalubhasang interface module sa DBMS (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC, atbp.);
3. JAM/RW - module ng generator ng ulat;
4. JAM/CASEi - mga dalubhasang interface module sa CASE tools (JAM/CASE-TeamWork, JAM/CASE-Inno-vator, atbp.);
5. JAM/TPi - mga dalubhasang interface module para sa mga transaction manager (halimbawa, JAM/TPi-Server TUXEDO, atbp.);
6. Jterm - isang espesyal na X-terminal emulator.
Ang core ng system ay isang kumpletong produkto at maaaring malayang gamitin para sa pagbuo ng application. Ang lahat ng iba pang mga module ay karagdagang at hindi maaaring gamitin nang nakapag-iisa.
Kasama sa core ng system ang mga sumusunod na pangunahing bahagi:
1. screen editor. Ang screen editor ay may kasamang screen development environment, isang visual object repository, sarili nitong JAM DBMS - JDB, isang transaction manager, isang debugger, isang style editor;
2. editor ng menu;
3. isang set ng mga auxiliary utilities;
4. paraan ng paggawa ng pang-industriyang bersyon ng aplikasyon.
Kapag gumagamit ng JAM, ang pagbuo ng panlabas na interface ng isang application ay isang visual na disenyo at bumababa sa paglikha ng mga form ng screen sa pamamagitan ng paglalagay ng mga istruktura ng interface sa mga ito at pagtukoy sa mga field ng screen para sa input/output ng impormasyon. Ang disenyo ng interface sa JAM ay tapos na gamit editor ng screen. Ang mga application na binuo sa JAM ay may multi-window interface. Ang pagbuo ng screen ay nagsasangkot ng paglalagay ng mga elemento ng interface dito, pagpapangkat sa kanila, at pagtatakda ng mga halaga ng kanilang mga katangian.
Editor ng menu nagbibigay-daan sa iyong bumuo at mag-debug ng mga system ng menu. Naipatupad na ang kakayahang bumuo ng mga pictographic na menu. Ang pagtatalaga ng mga item sa menu sa mga object ng application ay ginagawa sa editor ng screen.
Ang single-user relational DBMS JDB ay binuo sa core ng JAM. Ang pangunahing layunin ng JDB ay ang pag-prototyp ng mga application sa mga kaso kung saan ang pagtatrabaho sa isang karaniwang DBMS ay imposible o hindi praktikal. Ipinapatupad ng JDB ang mga kinakailangang pinakamababang kakayahan ng mga relational na DBMS, na hindi kasama ang mga index, nakaimbak na pamamaraan, trigger at view. Gamit ang JDB, maaari kang bumuo ng database na kapareho ng target na database (maliban sa mga feature na nawawala sa JDB), at bumuo ng isang makabuluhang bahagi ng application.
Ang debugger ay nagbibigay-daan para sa komprehensibong pag-debug ng application na binuo. Ang lahat ng mga kaganapan na nagaganap sa panahon ng pagpapatupad ng aplikasyon ay sinusubaybayan.
Mga utility Kasama sa mga JAM ang tatlong pangkat:
1) mga nagko-convert ng JAM screen file sa text. Sine-save ng JAM ang mga screen bilang mga native na binary file;
2) configuration ng input/output device. Ang JAM at mga application na binuo kasama nito ay hindi gumagana nang direkta sa mga I/O device. Sa halip, ina-access ng JAM ang mga lohikal na I/O device (keyboard, terminal, ulat);
3) pagpapanatili ng mga screen library.
Ang isa sa mga karagdagang module ng JAM ay generator ng ulat. Ginagawa ang layout ng ulat sa editor ng screen ng JAM. Ang operasyon ng ulat ay inilarawan gamit ang isang espesyal na wika. Binibigyang-daan ka ng generator ng ulat na tukuyin ang data na ipinapakita sa ulat, ang pagpapangkat ng impormasyon ng output, pag-format ng output, atbp.
Ang mga application na binuo gamit ang JAM ay maaaring gawin bilang mga executable na module. Upang gawin ito, ang mga developer ay dapat magkaroon ng isang C compiler at isang linker.
Naglalaman ang JAM built-in na programming language JPL (JAM Procedural Language), kung saan, kung kinakailangan, maaaring isulat ang mga module na nagpapatupad ng mga partikular na aksyon. Ang wikang ito ay binibigyang kahulugan. Posibleng makipagpalitan ng impormasyon sa pagitan ng visually built na kapaligiran ng application at mga naturang module. Bilang karagdagan, ipinapatupad ng JAM ang kakayahang kumonekta sa mga panlabas na module na nakasulat sa mga wika na katugma sa wikang C sa mga tuntunin ng mga function na tawag.
Si JAM ay sistemang nakatuon sa kaganapan, na binubuo ng isang hanay ng mga kaganapan - pagbubukas at pagsasara ng mga bintana, pagpindot sa key ng keyboard, pag-trigger ng timer ng system, pagtanggap at paglilipat ng kontrol ng bawat elemento ng screen. Ipinapatupad ng developer ang logic ng application sa pamamagitan ng pagtukoy ng handler para sa bawat kaganapan.
Mga tagapangasiwa ng kaganapan Maaaring maglaman ang JAM ng parehong built-in na JAM function at function na isinulat ng developer sa C o JPL. Kasama sa set ng mga built-in na function ang higit sa 200 function para sa iba't ibang layunin; magagamit ang mga ito para sa mga tawag mula sa mga function na nakasulat sa parehong JPL at C.
Industrial na bersyon ng application, binuo gamit ang JAM, ay binubuo ng mga sumusunod na bahagi:
1. executable module ng application interpreter;
2. mga screen na bumubuo sa application (ibinibigay bilang hiwalay na mga file, bilang bahagi ng mga screen library, o nakapaloob sa katawan ng interpreter);
3. panlabas na JPL modules (ibinigay sa anyo ng mga text file o sa precompiled form; precompiled
4. panlabas na JPL modules - sa anyo ng hiwalay na mga file at bilang bahagi ng mga screen library);
5. application configuration file - keyboard at terminal configuration file, system messages file, pangkalahatang configuration file.
Ang direktang pakikipag-ugnayan sa DBMS ay ipinatutupad ng mga module ng JAM/DBi (Database interface). Ang mga pamamaraan para sa pagpapatupad ng pakikipag-ugnayan sa JAM ay nahahati sa dalawang klase: manu-mano at awtomatiko.
Sa manu-manong paraan Ang developer ay nakapag-iisa na nagsusulat ng mga query sa SQL, kung saan ang mga pinagmulan at destinasyon para sa pagtanggap ng mga resulta ng query ay maaaring parehong mga elemento ng interface ng isang visual na dinisenyong panlabas na antas at mga panloob na variable na hindi nakikita ng end user.
Auto mode ipinatupad ng JAM transaction manager. Ito ay magagawa para sa mga tipikal na karaniwang uri ng mga pagpapatakbo ng database, ang tinatawag na QBE (Query By Example - mga query batay sa isang sample), na isinasaalang-alang ang medyo kumplikadong mga relasyon sa pagitan ng mga talahanayan ng database at awtomatikong kontrol ng mga katangian ng mga field ng input-output ng screen depende sa uri ng transaksyon (pagbasa, pagsulat at iba pa) kung saan lumalahok ang nabuong kahilingan.
Binibigyang-daan ka ng JAM na bumuo ng mga application upang gumana sa higit sa 20 DBMS: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-compatible DBMS, atbp.
Ang isang natatanging tampok ng JAM ay ang mataas na antas ng application portability sa pagitan ng iba't ibang platform (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS, atbp.); maaaring may kinakailangan na "redraw" ang mga static na field ng text sa mga screen na may Russian text kapag naglilipat sa pagitan ng DOS-Windows-UNIX na kapaligiran. Bukod pa rito, ang portability ay pinadali ng katotohanan na sa JAM, ang mga application ay binuo para sa mga virtual na I/O na device kaysa sa mga pisikal. Kaya, kapag naglilipat ng isang application mula sa platform patungo sa platform, karaniwang kailangan mo lang imapa ang mga pisikal na I/O device sa kanilang mga lohikal na representasyon para sa application.
Ang paggamit ng SQL bilang paraan ng pakikipag-ugnayan sa DBMS ay nakakatulong din na matiyak ang portability sa pagitan ng mga DBMS. Kung ililipat ang istraktura ng database, maaaring hindi nangangailangan ng anumang pagbabago ang mga application, maliban sa pagsisimula ng sesyon ng trabaho. Posible ito kung ang application ay hindi gumamit ng mga DBMS-specific na SQL extension.
Kapag ang pag-load sa system ay tumaas at ang pagiging kumplikado ng mga gawain ay nalutas (pamamahagi at heterogeneity ng mga mapagkukunang ginamit, ang bilang ng sabay-sabay na konektadong mga gumagamit, ang pagiging kumplikado ng lohika ng aplikasyon) ay ginagamit three-tier na modelo ng arkitektura"client - server" gamit ang mga transaction manager. Ang mga bahagi ng JAM/TPi-Client at JAM/TPi-Server ay ginagawang medyo madali upang lumipat sa isang three-tier na modelo. Sa kasong ito, ang module ng JAM/TPi-Server ay gumaganap ng isang mahalagang papel, dahil ang pangunahing kahirapan sa pagpapatupad ng isang three-tier na modelo ay nakasalalay sa pagpapatupad ng lohika ng aplikasyon sa mga serbisyo ng manager ng transaksyon.
Ang interface ng JAM/CASE ay nagbibigay-daan sa pagpapalitan ng impormasyon sa pagitan ng imbakan ng object ng JAM at ng imbakan ng tool ng CASE. Ang palitan ay katulad ng kung paano ini-import ang isang istraktura ng database sa isang repositoryo ng JAM nang direkta mula sa database. Ang pagkakaiba ay ang palitan sa pagitan ng mga repositoryo ay bidirectional.
Bilang karagdagan sa mga module ng JAM/CASEi, mayroon ding module ng Kit ng Developer ng JAM/CASEi Gamit ang module na ito, maaari kang mag-isa na bumuo ng isang interface (ibig sabihin, isang espesyal na module ng JAM/CASEi) para sa isang partikular na tool ng CASE, kung mayroong isang. yari na JAM/CASEi module para dito ay wala.
Mayroong isang interface na nagpapatupad ng pakikipag-ugnayan sa pagitan ng tool na Silverrun CASE at JAM. Inililipat nito ang schema ng database at mga form ng screen ng application sa pagitan ng tool na Silverrun-RDM CASE at bersyon ng JAM 7.0; may dalawang operating mode:
1) direct mode (Silverrun-RDM->JAM) ay inilaan para sa paglikha ng CASE dictionary objects at JAM repository elements batay sa representasyon ng mga schema sa Silverrun-RDM. Batay sa representasyon ng mga modelo ng data ng interface sa Silverrun-RDM, nabuo ang mga screen at mga elemento ng imbakan ng JAM. Ang tulay ay nagko-convert ng RDM relational schema table at mga relasyon sa isang pagkakasunod-sunod ng mga object ng JAM ng mga naaangkop na uri. Ang pamamaraan para sa pagbuo ng mga modelo ng data ng interface sa Silverrun-RDM ay nagsasangkot ng paggamit ng isang subcircuit na mekanismo para sa pag-prototyping ng mga screen ng application. Batay sa paglalarawan ng bawat isa sa mga RDM subcircuits, ang tulay ay bumubuo ng isang JAM screen form;
2) ang reverse mode (JAM->Silverrun-RDM) ay inilaan para sa paglilipat ng mga pagbabago ng mga bagay sa diksyunaryo ng CASE sa Silverrun-RDM relational model.
Ang reengineering mode ay nagbibigay-daan sa mga pagbabago ng lahat ng JAM screen properties na dating na-import mula sa RDM na mailipat sa Silvcrrun schema. Upang kontrolin ang integridad ng database, ang mga pagbabago sa schema sa anyo ng pagdaragdag o pagtanggal ng mga talahanayan at mga field ng talahanayan ay hindi pinapayagan.
Ang JAM core ay may built-in na interface sa configuration management tools (PVCS sa Windows platform at SCCS sa UNIX platform). Ang mga screen library at/o mga repository ay inililipat sa ilalim ng kontrol ng mga system na ito. Sa kawalan ng ganitong mga sistema, independiyenteng ipinapatupad ng JAM ang ilan sa mga function upang suportahan ang pagpapaunlad ng grupo.
Sa MS-Windows platform, ang JAM ay may built-in na interface sa PVCS, at ang mga pagkilos sa pagkuha/pag-checkout ay direktang isinasagawa mula sa kapaligiran ng JAM.
Vantage Team Builder (Westmount I-CASE). Ang Vantage Team Builder ay isang pinagsama-samang produkto ng software na idinisenyo upang ipatupad at ganap na suportahan ang waterfall lifecycle model.
Nagbibigay ang Vantage Team Builder ng mga sumusunod na function:
1. pagdidisenyo ng mga data flow diagram, entity-relationship diagram, data structures, program block diagram at sequence ng mga screen form;
2. pagdidisenyo ng mga diagram ng arkitektura ng system - SAD (pagdidisenyo ng komposisyon at komunikasyon ng mga tool sa pag-compute, pamamahagi ng mga gawain ng system sa pagitan ng mga tool sa pag-compute, pagmomodelo ng mga relasyon sa client-server, pagsusuri sa paggamit ng mga tagapamahala ng transaksyon at mga tampok ng paggana ng mga system sa real time);
3. pagbuo ng program code sa wika ng target na DBMS na may buong suporta sa kapaligiran ng software at pagbuo ng SQL code para sa paglikha ng mga talahanayan ng database, mga index, mga hadlang sa integridad at mga nakaimbak na pamamaraan;
4. programming sa wikang C na may built-in na SQL;
5. bersyon at pagsasaayos ng pamamahala ng proyekto;
6. multi-user access sa repository ng proyekto;
7. pagbuo ng dokumentasyon ng proyekto gamit ang pamantayan at indibidwal na mga template;
8. pag-export at pag-import ng data ng proyekto sa CDIF format (CASE Data Interchange Format).
Ang Vantage Team Builder ay may iba't ibang configuration depende sa DBMS na ginamit (ORACLE, Informix, Sybase o Ingres) o mga tool sa pagbuo ng application (Uniface). Ang Vantage Team Builder para sa Uniface configuration ay naiiba sa iba sa bahagyang pagtutok nito sa spiral life cycle model dahil sa mabilis nitong prototyping na kakayahan. Ang isang malaking hanay ng mga diagram ay ginagamit upang ilarawan ang proyekto ng AIS.
Kapag nagtatayo ng lahat ng uri ng mga diagram, ang kontrol ay ibinibigay para sa pagsunod ng mga modelo sa syntax ng mga pamamaraan na ginamit, pati na rin ang kontrol ng pagsusulatan ng mga elemento ng parehong pangalan at ang kanilang mga uri para sa iba't ibang uri ng mga diagram.
Kapag gumagawa ng mga diagram ng daloy ng data ng DFD, sinusubaybayan ang pagsunod ng mga diagram sa iba't ibang antas ng agnas. Ang kawastuhan ng pinakamataas na antas ng DFD ay sinusubaybayan gamit ang ELM event list matrix. Upang kontrolin ang agnas ng mga pinagsama-samang stream ng data, maraming mga opsyon para sa paglalarawan ng mga ito ang ginagamit: sa form mga diagram ng istruktura ng data DSD o mga notasyon BNF (Backus - Naur form).
Upang bumuo ng SAD, ginagamit ang isang pinahabang notasyon ng DFD, na ginagawang posible na ipakilala ang mga konsepto ng mga processor, mga gawain at mga peripheral na aparato, na nagsisiguro ng kalinawan ng mga solusyon sa disenyo.
Kapag bumubuo ng isang modelo ng data sa anyo ng isang ERD, ito ay na-normalize at ang kahulugan ng mga pisikal na pangalan ng mga elemento ng data at mga talahanayan ay ipinakilala na gagamitin sa proseso ng pagbuo ng pisikal na schema ng data ng isang partikular na DBMS. Posibleng matukoy ang mga alternatibong key ng mga entity at field na bumubuo ng karagdagang mga entry point sa talahanayan (mga index field), at ang kapangyarihan ng mga ugnayan sa pagitan ng mga entity.
Ang pagkakaroon ng isang unibersal na sistema ng pagbuo ng code batay sa tinukoy na paraan ng pag-access sa repositoryo ng proyekto ay nagpapahintulot sa mga developer na mapanatili ang isang mataas na antas ng pagpapatupad ng disiplina sa disenyo: isang mahigpit na pagkakasunud-sunod ng pagbuo ng modelo; matibay na istraktura at nilalaman ng dokumentasyon; awtomatikong pagbuo ng mga source code ng programa, atbp.; lahat ng ito ay nagsisiguro ng pagtaas sa kalidad at pagiging maaasahan ng mga binuo na IC.
Maaaring gamitin ang FrameMaker, Interleaf o Word Perfect na mga sistema ng pag-publish upang maghanda ng dokumentasyon ng proyekto. Ang istraktura at komposisyon ng dokumentasyon ng proyekto ay na-configure alinsunod sa mga tinukoy na pamantayan. Ginagawa ang mga setting nang hindi binabago ang mga solusyon sa disenyo.
Kapag bumubuo ng malaking AIS, ang buong sistema sa kabuuan ay tumutugma sa isang proyekto bilang isang kategorya ng Vantage Team Builder. Ang proyekto ay maaaring mabulok sa isang bilang ng mga sistema, na ang bawat isa ay tumutugma sa ilang medyo autonomous na subsystem ng AIS at binuo nang nakapag-iisa sa iba. Sa hinaharap, ang mga sistema ng proyekto ay maaaring isama.
Ang proseso ng disenyo ng AIS gamit ang Vantage Team Builder ay ipinatupad sa anyo ng apat na magkakasunod na yugto (yugto) - pagsusuri, arkitektura, disenyo At pagpapatupad, sa kasong ito, ang mga nakumpletong resulta ng bawat yugto ay ganap o bahagyang inilipat (na-import) sa susunod na yugto. Ang lahat ng mga diagram, maliban sa ERD, ay na-convert sa ibang uri o binabago ang kanilang hitsura alinsunod sa mga katangian ng kasalukuyang yugto. Kaya, ang mga DFD ay na-convert sa mga SAD sa yugto ng arkitektura, ang mga DSD sa mga DTD. Kapag nakumpleto na ang pag-import, ang lohikal na koneksyon sa nakaraang yugto ay nasira, ibig sabihin, lahat ng kinakailangang pagbabago ay maaaring gawin sa mga diagram.
Tinitiyak ng Vantage Team Builder para sa Uniface configuration ang pagbabahagi ng dalawang system sa loob ng iisang teknolohikal na disenyong kapaligiran, habang ang mga database schemas (SQL models) ay inililipat sa Uniface repository, at vice versa, ang mga application model na nabuo ng Uniface tools ay maaaring ilipat sa Vantage Imbakan ng Team Builder . Ang mga posibleng pagkakaiba sa pagitan ng mga repositoryo ng dalawang sistema ay inaalis gamit ang isang espesyal na utility. Ang pagbuo ng mga form ng screen sa kapaligiran ng Uniface ay isinasagawa batay sa mga diagram ng pagkakasunud-sunod ng form ng FSD pagkatapos i-import ang modelo ng SQL. Ang teknolohiya para sa pagbuo ng AIS batay sa pagsasaayos na ito ay ipinapakita sa Fig. 2.23.
Ang istraktura ng repository na naka-imbak sa target na DBMS at ang Vantage Team Builder na mga interface ay bukas, na sa prinsipyo ay nagbibigay-daan sa pagsasama sa anumang iba pang mga tool.
Uniface. Ang produkto ng Compuware ay isang development environment para sa malakihang mga application sa isang client-server architecture at may sumusunod na component architecture:
1. Application Objects Repository (application object repository) ay naglalaman ng metadata na awtomatikong ginagamit ng lahat ng iba pang bahagi sa buong AIS life cycle (mga modelo ng application, mga paglalarawan ng data, mga panuntunan sa negosyo, mga form ng screen, mga global na bagay at mga template). Maaaring maimbak ang repositoryo sa alinman sa mga database na sinusuportahan ng Uniface;
kanin. 2.23. Pakikipag-ugnayan sa pagitan ng Vantage Team Builder at Uniface
2. Sinusuportahan ng Application Model Manager ang mga modelo ng application (mga modelong E-R), na ang bawat isa ay kumakatawan sa isang subset ng pangkalahatang schema ng database mula sa punto ng view ng isang partikular na application, at may kasamang kaukulang graphical na editor;
3. Rapid Application Builder - isang tool para sa mabilis na paglikha ng mga screen form at mga ulat batay sa mga object model ng application. May kasamang graphical na form editor, prototyping, debugging, pagsubok at mga tool sa dokumentasyon. Isang interface na may iba't ibang uri ng mga kontrol sa window ang Open Widget Interface ay ipinatupad para sa mga umiiral na graphical na interface - MS Windows (kabilang ang VBX), Motif, OS/2. Ang Universal Presentation Interface ay nagpapahintulot sa iyo na gamitin ang parehong bersyon ng application sa iba't ibang mga graphical na interface nang hindi binabago ang program code;
4. Ginagamit ang Mga Serbisyo ng Developer upang suportahan ang malalaking proyekto at ipatupad ang kontrol sa bersyon (Uniface Version Control System), mga karapatan sa pag-access (paghihiwalay ng mga kapangyarihan), mga pandaigdigang pagbabago, atbp. Nagbibigay ito sa mga developer ng mga tool para sa parallel na disenyo, kontrol ng input at output, paghahanap, pagtingin, pagpapanatili at pag-isyu ng mga ulat sa data ng version control system;
5. Deployment Manager (pamamahala ng pamamahagi ng application) - mga tool na nagbibigay-daan sa iyong ihanda ang nilikhang application para sa pamamahagi, i-install at mapanatili ito (sa kasong ito, ang platform ng user ay maaaring iba sa platform ng developer). Kasama sa mga ito ang mga driver ng network at mga driver ng DBMS, isang application server (polyserver), pamamahagi ng aplikasyon at mga tool sa pamamahala ng database. Sinusuportahan ng Uniface ang interface sa halos lahat ng kilalang hardware at software platform, DBMS, CASE tool, network protocol at transaction manager;
6. Ang Personal na Serye (personal na tool) ay ginagamit upang lumikha ng mga kumplikadong query at ulat sa graphical na anyo (Personal Query at Personal na Access - PQ/PA), gayundin sa paglilipat ng data sa mga system tulad ng WinWord at Excel;
7. Distributed Computing Manager - tool sa pagsasama sa mga transaction manager na Tuxedo, Encina, CICS, OSF DCE.
Ganap na sinusuportahan ng bersyon ng Uniface 7 ang distributed computing model at ang three-tier client-server architecture (na may kakayahang baguhin ang application decomposition scheme sa runtime). Ang mga application na nilikha gamit ang Uniface 7 ay maaaring isagawa sa magkakaibang mga operating environment gamit ang iba't ibang mga protocol ng network, nang sabay-sabay sa ilang magkakaibang mga platform (kabilang ang Internet).
Ang mga bahagi ng Uniface 7 ay kinabibilangan ng:
1. Uniface Application Server - server ng aplikasyon para sa mga distributed system;
2. WebEnabler - server software para sa mga operating application sa Internet at intranet;
3. Name Server - server software na nagsisiguro sa paggamit ng mga distributed application resources;
4. PolyServer - isang tool para sa pag-access ng data at pagsasama ng iba't ibang mga system.
Kasama sa listahan ng mga sinusuportahang DBMS ang DB2, VSAM at IMS; Nagbibigay din ang PolyServer ng pakikipag-ugnayan sa MVS OS.
Designer/2000 + Developer/2000. Ang Designer/2000 2.0 mula sa ORACLE ay isang pinagsamang CASE tool na, kasama ng mga application development tool na Developer/2000, ay nagbibigay ng suporta para sa isang kumpletong ikot ng buhay ng software para sa mga system na gumagamit ng ORACLE DBMS.
Ang Designer/2000 ay isang pamilya ng mga pamamaraan at mga produkto ng software na sumusuporta sa kanila. Ang Basic methodology Designer/2000 (CASE*Method) ay isang structural methodology para sa system design na ganap na sumasaklaw sa lahat ng stages ng AIS life cycle. Sa yugto ng pagpaplano, ang mga layunin ng paglikha ng sistema, mga priyoridad at mga limitasyon ay natutukoy, ang arkitektura ng system at ang plano ng pag-unlad ng AIS ay binuo. Sa panahon ng proseso ng pagsusuri, ang mga sumusunod ay binuo: isang modelo ng mga pangangailangan ng impormasyon (entity-relationship diagram), isang functional hierarchy diagram (batay sa AIS functional decomposition), isang cross-reference matrix at isang data flow diagram.
Sa yugto ng disenyo, nabuo ang isang detalyadong arkitektura ng AIS, idinisenyo ang isang relational database schema at mga module ng software, at ang mga cross-reference ay itinatag sa pagitan ng mga bahagi ng AIS upang pag-aralan ang kanilang impluwensya sa isa't isa at kontrolin ang mga pagbabago.
Sa yugto ng pagpapatupad, ang isang database ay nilikha, ang mga sistema ng aplikasyon ay binuo, ang mga ito ay nasubok, nasuri ang kalidad at pagsunod sa mga kinakailangan ng gumagamit. Ang dokumentasyon ng system, mga materyales sa pagsasanay at mga manwal ng gumagamit ay nilikha. Sa mga yugto ng operasyon at pagpapanatili, ang pagganap at integridad ng system ay sinusuri, sinusuportahan at, kung kinakailangan, ang pagbabago ng AIS ay isinasagawa.
Nagbibigay ang Designer/2000 ng isang graphical na interface para sa pagbuo ng iba't ibang mga modelo (diagram) ng lugar ng paksa. Sa panahon ng proseso ng pagbuo ng mga modelo, ang impormasyon tungkol sa mga ito ay ipinasok sa imbakan. Kasama sa Designer/2000 ang mga sumusunod na bahagi.
disenyo ng AIS
Detalyadong pag-unlad disenyo ng sistema, na naglalaman ng kumpletong hanay ng dokumentasyong pang-organisasyon, disenyo, teknolohikal at pagpapatakbo nito. Alinsunod sa GOST 34.601-90. Ang disenyo ng mga awtomatikong sistema ay nagsasangkot ng pagpapatupad ng isang bilang ng mga yugto, kabilang ang: pagbuo ng mga kinakailangan para sa AS, pagbuo ng konsepto ng AS, pagbuo ng mga teknikal na pagtutukoy, paunang disenyo, teknikal na disenyo at pag-unlad ng dokumentasyong nagtatrabaho. Bilang karagdagan sa disenyo, kasama rin sa mga yugto ng paglikha ng isang NPP ang: pagkomisyon at pagpapanatili ng NPP. Ang bawat yugto ay nahahati sa mga yugto. Tinutukoy din ng mga annexes sa pamantayang ito ang:
· Listahan ng mga uri ng organisasyong nakikilahok sa gawain.
Depende sa likas na katangian ng object ng disenyo at ang mga tiyak na kondisyon nito, pinapayagan ng GOST 34.601-90 ang pagbubukod ng mga indibidwal na yugto, pati na rin ang kanilang kumbinasyon. Isinasaalang-alang ang pangmatagalang kasanayan sa Russia kapag lumilikha ng mga awtomatikong sistema ng impormasyon (" AIS”) ang mga sumusunod na yugto ng disenyo ay karaniwang isinasagawa: survey bago ang disenyo, disenyong pangkonsepto, paunang disenyo, disenyong teknikal at detalyadong disenyo. Iba pang mga pamantayan ng estado na kumokontrol sa iba't ibang aspeto ng disenyo ng speaker:
· GOST 34.602-89 Set ng mga pamantayan para sa mga automated system. Mga tuntunin ng sanggunian para sa paglikha ng isang awtomatikong sistema. Pumasok noong 01/01/90.
· Pamantayan 34.603-92 Teknolohiya ng impormasyon. Mga uri ng mga pagsubok sa AC.
· Mga Pamantayan 34. (971, 972,973, 974, 981) - 91 Information technology. Pagkakaugnay ng mga bukas na sistema.
· Pamantayan 34.91. Teknolohiya ng impormasyon. Mga lokal na network ng lugar, atbp.
Survey bago ang proyekto- Koleksyon at pagproseso ng impormasyon tungkol sa organisasyon at mga tampok ng paggana ng object ng automation, kabilang ang data sa pakikipag-ugnayan nito sa panlabas na kapaligiran at iba pang mga bagay, pati na rin ang pagpapatupad pag-aanalisa ng systema, pagbuo ng isang pag-aaral sa pagiging posible para sa pagiging posible ng automation at pagbuo ng mga pangkalahatang kinakailangan para sa pagbuo ng isang awtomatikong sistema. Ang nilalaman ng trabaho sa panahon ng pag-inspeksyon ng pre-proyekto ng isang pasilidad ng automation ay tumutugma sa yugto na "Pagbuo ng mga kinakailangan para sa isang awtomatikong sistema" GOST 34.601-90, mga yugto: "Inspeksyon ng bagay at pagbibigay-katwiran sa pangangailangan na lumikha ng isang awtomatikong sistema ", "Pagbubuo ng mga kinakailangan ng user para sa isang awtomatikong system", "Pagbuo ng isang ulat sa gawaing isinagawa at isang aplikasyon para sa pag-unlad AS - mga taktikal at teknikal na pagtutukoy."
Konseptwal na disenyo- Naaayon sa mga yugto ng disenyo alinsunod sa GOST 34.601-90 - "Pagbuo ng konsepto ng NPP" (mga yugto: "Pagbuo ng mga opsyon para sa konsepto ng NPP at pagpili ng opsyon sa konsepto ng NPP na nagbibigay-kasiyahan sa gumagamit", "Paghahanda ng isang ulat sa ang gawaing isinagawa") at "Pagbuo ng mga teknikal na pagtutukoy". Ang mga uri ng panghuling dokumento ng trabaho sa yugtong ito ay paunang proyekto(ginagamit din ang mga pangalan - " Konseptwal na disenyo ”, “Pilot project") o Programa paglikha ng isang sistema na kinabibilangan ng:
· Maikling paglalarawan ng paunang estado ng automation object at ang kapaligiran kung saan ito gumagana;
· Indikasyon ng mga pangunahing layunin at listahan ng mga gawain sa automation;
· Paglalarawan ng pinalaki na istraktura ng organisasyon at functional ng napiling opsyon (o mga opsyon) para sa pagbuo ng system na nilikha;
· Pagaaral ukol sa posibilidad ng negosyo;
· Pinagsanib na paglalarawan at mga pangunahing kinakailangan para sa impormasyon at mga tool sa suporta sa wika;
· Pangkalahatang mga kinakailangan para sa software at hardware;
· Ilista at pinalaki ang mga katangian ng mga yugto ng paglikha ng system, ang timing ng kanilang pagpapatupad, ang komposisyon ng mga gumaganap at ang inaasahang resulta ng kanilang pagpapatupad;
· Paunang pagtatasa ng mga tagapagpahiwatig ng gastos ng trabaho;
· Mga teknikal na detalye para sa system sa kabuuan at/o mga pangunahing bahagi nito (mga subsystem, software at hardware system at tool, indibidwal na gawain, atbp.), na inaprubahan ng Customer.
Disenyo ng eskematiko- Pagbuo ng mga paunang solusyon sa disenyo para sa system at mga bahagi nito. Ang huling dokumento para sa pagsasagawa ng trabaho sa yugtong ito ng disenyo ay paunang disenyo, na naglalaman ng pangunahing disenyo at mga solusyon sa circuit ng object ng pag-unlad, pati na rin ang data na tumutukoy sa layunin nito at mga pangunahing parameter (kapag nagdidisenyo software sistema, ang paunang disenyo ay dapat maglaman ng isang kumpletong pagtutukoy Ginagawa pa lamang mga programa).
Teknikal na disenyo - Ang yugto ng trabaho sa disenyo ng sistema ng speaker, na kinabibilangan ng:
· Pagbuo ng mga solusyon sa disenyo para sa system at mga bahagi nito;
· Pagbuo ng dokumentasyon para sa NPP at mga bahagi nito;
· Pag-unlad at pagpapatupad ng dokumentasyon para sa pagbibigay ng mga produkto para sa pagkumpleto ng NPP at/o mga teknikal na kinakailangan (mga teknikal na detalye) para sa kanilang pag-unlad;
· Pagbuo ng mga pagtatalaga ng disenyo sa mga katabing bahagi ng proyekto ng pasilidad ng automation.
Ang huling dokumento ng yugto ng disenyo na ito ay teknikal na proyekto, na naglalaman, bilang karagdagan sa mga nakalistang materyales, mga diagram ng circuit at dokumentasyon ng disenyo ng object ng pag-unlad at mga bahagi nito, isang listahan ng mga napiling handa na mga tool software at hardware(kabilang ang mga computer, operating system, mga programa sa aplikasyon atbp.), at gayundin mga algorithm paglutas ng mga problema para sa pagbuo ng mga bagong software tool, atbp.
Detalyadong disenyo- Pangwakas na yugto disenyo, na, bilang karagdagan sa pagbuo ng dokumentasyon ng pagtatrabaho para sa system at mga bahagi nito na kinakailangan ng GOST 34.601-90, sa pangkalahatan ay nagbibigay para sa paglilinaw at pagdedetalye ng mga resulta ng mga nakaraang yugto, ang paglikha at pagsubok ng isang prototype at/o pilot na pang-industriyang modelo ng isang automation object, ang pagbuo at pagsubok ng mga produkto ng software, teknolohikal at pagpapatakbo na dokumentasyon. Ang mga resulta ay ipinakita sa manggagawa o proyektong teknikal na gawain. Sa modernong disenyo ng pagsasanay awtomatikong sistema ng impormasyon(Halimbawa, ABIS, ASTI, ACS atbp.) ito ang paunang yugto ng kanilang pagpapatupad sa gawain ng isang kumpanya, organisasyon o serbisyo na customer ng proyekto, o ang magulang ng ilang iba pang mga automated na kumpanya, organisasyon, serbisyo, atbp.
Siklo ng pag-unlad (disenyo).) software - Set ng mga yugto ng pag-unlad software Simula sa pag-aanalisa ng systema at pagbuo ng mga paunang kinakailangan bago ito isagawa.
Mga Prinsipyo ng Disenyo ng AIS- Isang hanay ng mga panuntunan o mga kinakailangan na itinatag ng maraming taon ng magkakaibang karanasan sa paglikha at pagpapatakbo ng AIS. Ang pinakakaraniwan ay:
· Pagkakakilanlan- ang pagbuo ng isang bago, ang pagpapabuti ng isang umiiral na, o ang pagpapatupad ng isang panlabas na nakuha na AIS ay mga pang-agham at teknikal na mga problema na magkapareho sa nilalaman, naiiba sa isa't isa lamang sa nilalaman ng isang bilang ng mga yugto at mga parameter ng oras ;
· Paggawa: ang automated na teknolohiya ay nangangahulugang ang pagbuo ng isang bagong teknolohiya o ang modernisasyon ng isang umiiral na sa mga kondisyon ng AIS at hindi pinapayagan ang simpleng paggamit ng binuo na software at hardware sa mga kondisyon ng mga lumang tradisyonal na teknolohiya;
· Pagpapatuloy, phasing at pagpapatuloy ng pag-unlad at pag-unlad: Ang AIS ay mga sistema na patuloy na umuunlad sa kanilang batayan; ang bawat pagbabago ay nagsisilbing isang pag-unlad ng mga pangunahing prinsipyo ng sistema at nakamit na ang kalidad;
· Kakayahang umangkop: Ang mga bahagi ng AIS ay dapat may mga katangian na nagsisiguro ng mabilis na pag-angkop ng mga sangkap na ito sa mga pagbabago sa panlabas na kapaligiran at mga bagong paraan;
· Modular na prinsipyo ng pagbuo ng software at hardware: ipinapalagay na ang komposisyon ng mga tool na ito ay binubuo ng mga bloke ("modules") na nagbibigay ng posibilidad na palitan o baguhin ang mga ito upang mapabuti ang paggana ng AIS o ang pagbagay nito sa mga bagong kundisyon;
· Teknolohikal (kabilang ang - network) pagsasama: ipinapalagay ang pagkakaisa para sa buong sistema ng teknolohiya para sa paglikha, pag-update, pag-iimbak at paggamit ng mga mapagkukunan ng impormasyon at, sa partikular, isang beses na pagproseso ng mga dokumento at data, pati na rin ang kanilang maramihang at maraming layunin na paggamit;
· Kumpletuhin ang normalisasyon ng mga proseso at ang kanilang pagsubaybay: Ang multi-purpose na paggamit ng impormasyon ng AIS ay nangangailangan ng pagtiyak ng mataas na pagiging maaasahan ng data sa system. Upang gawin ito, sa iba't ibang yugto ng pagproseso at pagpasok ng mga dokumento ng impormasyon, kinakailangan na gumamit ng iba't ibang anyo ng kontrol ng impormasyon, ang mga kinakailangan kung saan maaaring mabuo mula sa komposisyon ng mga gawain na nalutas at ang data na pinoproseso. ang patuloy na pagsubaybay ay kinakailangan din upang makakuha ng mga katangian ng husay at dami ng paggana ng AIS batay sa built-in at espesyal na binuo na mga tool sa matalinong istatistika;
· Regulasyon: Ang AIS ay nakatuon sa paggana sa isang pang-industriyang mode, na nagbibigay ng mass flow processing ng mga dokumento ng impormasyon; Ang pagproseso na ito ay kinokontrol ng mga pamantayan, ruta at mga teknolohiya sa pagpapatakbo, mga pamantayan para sa mga tagapagpahiwatig ng mapagkukunan at oras, at isang binuo na serbisyo sa pagpapadala.
· Kahusayan sa ekonomiya: ang paglikha ng isang AIS ay dapat isama ang pagpili ng mga naturang solusyon sa disenyo (kabilang ang software, teknikal at organisasyon-teknolohiya), na, napapailalim sa pagkamit ng mga itinakdang layunin at layunin, tiyakin ang pagliit ng mga gastos ng mga mapagkukunang pinansyal, materyal at paggawa.
· Uri ng mga solusyon sa disenyo: ang pagbuo at pag-unlad ng AIS at kanilang mga network ay isinasagawa na may pagtuon sa interlibrary na kooperasyon at kooperasyon, gayundin alinsunod sa mga patakaran at protocol ng internasyonal na pagpapalitan ng impormasyon;
· Pinakamataas na paggamit ng mga handa na solusyon: upang mabawasan ang gastos at oras ng pag-unlad at pagpapatupad ng AIS, pati na rin upang mabawasan ang mga error sa disenyo ng parehong sistema sa kabuuan at ang mga indibidwal na bahagi nito, inirerekomenda na gumamit ng mga handa na solusyon at tool hangga't maaari. Sa planong ito, kapag lumilikha ng isang bagong sistema, ang isang malaking halaga ng trabaho ay nauugnay sa pagsusuri ng mga alternatibong opsyon para sa mga posibleng solusyon, ang pagpili ng pinaka-angkop para sa object ng automation at ang pagbagay nito sa mga bagong kondisyon ng aplikasyon;
· Diwang pang-korporasyon: kapag nagdidisenyo ng isang automated system na bahagi ng isang mas mataas na antas na sistema (lungsod, departamento, republika, atbp.), ang hardware, software, linguistic at pagkakatugma ng impormasyon nito sa ibang mga kalahok sa system at/o AIS network ay dapat ibigay. Ang mga kinakailangan ng pagkakakilanlan ng kumpanya ay maaaring sumalungat sa mga kinakailangan o desisyon na idinidikta ng iba pang mga prinsipyo, halimbawa, pagpapatuloy ng mga desisyon sa disenyo;
· Oryentasyon sa mga unang tao ng object ng automation: matagumpay na pagpapatupad ng trabaho sa paglikha ng isang awtomatikong sistema ng impormasyon, ang pag-unlad at pagpapatakbo nito ay posible lamang kung sila ay walang pasubali na suportado ng unang tao ng object ng automation (halimbawa, ang direktor ng isang library o ahensya ng impormasyon) at direktang responsibilidad para sa ang kanilang pagpapatupad ay itinalaga sa pamamagitan ng pagkakasunud-sunod ng organisasyon sa isang tagapamahala sa antas ng hindi bababa sa representante na direktor
REGULATORY AT METHODOLOGICAL SUPPORT PARA SA PAGLIKHA NG AIS.
Mga pangunahing konsepto ng disenyo ng AIS
Sa mga pangkalahatang tuntunin, ang AIS ay kinabibilangan ng: user (consumer), mga mapagkukunan ng impormasyon, mga carrier ng impormasyon, paraan ng pagkolekta, pag-iimbak, pagproseso ng impormasyon, at paraan ng pagpapadala ng impormasyon.
Ang disenyo ng AIS ay batay sa dalawang magkakaugnay na bahagi:
Mga Pamantayan sa Disenyo;
Pamamaraan ng disenyo.
Ang mga pangunahing konsepto, diskarte at kahulugan ng disenyo ng AIS ay kinokontrol ng tatlong uri ng disenyo at dokumentasyon ng software:
- pinag-isang sistema ng dokumentasyon ng disenyo (ESKD);
- pinag-isang sistema ng dokumentasyon ng programa (USPD);
- isang hanay ng mga dokumento ng gabay para sa AIS.
Ang komposisyon ng dokumentasyon ng proyekto ay isang hanay ng mga pamantayan at alituntunin batay sa AIS GOST 24.104-85, GOST 34.003-90, GOST 34.201-90, na kinabibilangan ng mga alituntunin para sa mga teknolohiya ng impormasyon at mga awtomatikong sistema, pati na rin ang mga kinakailangan para sa nilalaman ng mga dokumento.
Ang layunin ng disenyo ay kilalanin ang isang medyo simpleng panloob na istraktura, na tinatawag na arkitektura ng system.
Ang AIS ay binuo bilang isang proyekto. Maraming mga tampok ng pamamahala ng proyekto at ang yugto ng pagbuo ng proyekto (mga yugto ng siklo ng buhay) ay karaniwan, na independyente hindi lamang sa lugar ng paksa, kundi pati na rin sa likas na katangian ng proyekto. Ang konsepto ng isang proyekto ay isang kumplikadong konsepto at mahirap makahanap ng hindi malabo na pormulasyon para dito.
Proyekto– ito ay isang limitadong oras, may layuning pagbabago sa isang hiwalay na sistema na may malinaw na tinukoy na mga layunin sa una, ang pagkamit nito ay tumutukoy sa pagkumpleto ng proyekto, pati na rin sa mga itinatag na kinakailangan para sa timing, mga resulta, panganib, balangkas para sa paggastos ng mga pondo at mapagkukunan , at para sa istruktura ng organisasyon.
Para sa ekonomiya system, sa pamamagitan ng proyekto ng EIS ang ibig naming sabihin ay disenyo at dokumentasyon ng engineering, na nagbibigay ng paglalarawan ng mga solusyon sa disenyo para sa paglikha at pagpapatakbo ng EIS sa isang partikular na kapaligiran ng software at hardware.
Sa ilalim ng disenyo ng EIS nauunawaan ang proseso ng pag-convert ng impormasyon ng input tungkol sa isang disenyo ng bagay, mga pamamaraan ng disenyo at karanasan sa pagdidisenyo ng mga bagay na may katulad na layunin alinsunod sa GOST sa isang proyekto ng EIS. Mula sa puntong ito, ang disenyo ng isang EIS ay bumaba sa pare-parehong pormalisasyon ng mga solusyon sa disenyo sa iba't ibang yugto ng siklo ng buhay ng EIS: pagsusuri sa pagpaplano at mga kinakailangan, teknikal at detalyadong disenyo, pagpapatupad at pagpapatakbo ng EIS.
Disenyo ng mga bagay Ang EIS ay mga indibidwal na elemento o ang kanilang mga complex ng functional at sumusuportang mga bahagi. Kaya, ang mga functional na elemento, alinsunod sa tradisyonal na agnas, ay mga gawain, hanay ng mga gawain at mga tungkulin sa pamamahala. Bilang bahagi ng sumusuportang bahagi ng EIS, ang mga bagay sa disenyo ay ang mga elemento at ang kanilang mga kumplikadong impormasyon, software at hardware na suporta ng system.
Bilang isang paksa Ang disenyo ng EIS ay nagsasangkot ng mga pangkat ng mga espesyalista na nagsasagawa ng mga aktibidad sa disenyo, kadalasan bilang bahagi ng isang dalubhasang (disenyo) na organisasyon, at ang organisasyon ng customer kung saan kinakailangan na bumuo ng isang EIS. Tinutukoy ng sukat ng mga system na binuo ang komposisyon at bilang ng mga kalahok sa proseso ng disenyo. Sa malaking dami at masikip na mga deadline para sa pagkumpleto ng gawaing disenyo, maaaring lumahok ang ilang mga team ng disenyo (mga organisasyon sa pag-unlad) sa pagbuo ng system. Sa kasong ito, natukoy ang isang parent na organisasyon na nag-coordinate sa mga aktibidad ng lahat ng co-executing na organisasyon.
Ang anyo ng pakikilahok ng mga co-executor sa pagbuo ng isang proyekto ng system ay maaaring iba. Ang pinakakaraniwang anyo ay kung saan ang bawat co-executor ay nagsasagawa ng gawaing disenyo mula simula hanggang katapusan para sa ilang bahagi ng system na binuo. Kadalasan ito ay isang functional subsystem o isang magkakaugnay na hanay ng mga gawain sa pamamahala. Ang hindi gaanong karaniwan ay ang anyo ng pakikilahok ng mga co-executor, kung saan ang mga indibidwal na co-executor ay gumaganap ng trabaho sa ilang mga yugto ng proseso ng disenyo. Posible ang isang opsyon kung saan pinagsama ang mga function ng customer at ng developer, iyon ay, ang EIS ay dinisenyo sa loob ng bahay.
Ang pagsasagawa ng disenyo ng isang EIS ay nagsasangkot ng paggamit ng mga taga-disenyo ng isang tiyak na teknolohiya ng disenyo na naaayon sa sukat at mga tampok ng proyektong binuo.
Teknolohiya ng disenyo ng EIS- ito ay isang hanay ng mga pamamaraan at mga tool para sa pagdidisenyo ng isang EIS, pati na rin ang mga pamamaraan at paraan para sa pag-aayos ng disenyo (pamamahala sa proseso ng paglikha at pag-modernize ng isang proyekto ng EIS)
Pamamaraan (konsepto + pamamaraan)
Organisasyon ng Mga Tool
disenyo ng disenyo
Ang teknolohiya ng disenyo ay batay sa isang teknolohikal na proseso na tumutukoy sa mga aksyon, ang kanilang pagkakasunud-sunod, ang komposisyon ng mga gumaganap, ang mga paraan at mapagkukunan na kinakailangan upang maisagawa ang mga pagkilos na ito.
Kaya, ang teknolohikal na proseso ng pagdidisenyo ng isang EIS sa kabuuan ay nahahati sa isang hanay ng mga sunud-sunod na parallel, konektado at subordinate na mga kadena ng mga aksyon, na ang bawat isa ay maaaring magkaroon ng sarili nitong paksa. Ang mga aksyon na ginagawa kapag nagdidisenyo ng isang EIS ay maaaring tukuyin bilang hindi mahahati na mga teknolohikal na operasyon o bilang mga subprocess ng mga teknolohikal na operasyon. Ang lahat ng mga aksyon ay maaaring mga aksyon sa disenyo mismo, na bumubuo o nagbabago ng mga resulta ng disenyo, at mga aksyong pagsusuri, na binuo ayon sa itinatag na pamantayan para sa pagtatasa ng mga resulta ng disenyo.
Kaya, ang teknolohiya ng disenyo ay tinukoy ng isang regulated sequence ng mga teknolohikal na operasyon na isinagawa sa proseso ng paglikha ng isang proyekto batay sa isang partikular na pamamaraan, bilang isang resulta kung saan ito ay magiging malinaw hindi lamang ANO ang dapat gawin upang lumikha ng proyekto, ngunit din PAANO, KUNG KANINO at sa ANONG PAGKAKASUNOD ito dapat gawin.
Ang paksa ng anumang napiling teknolohiya ng disenyo ay dapat na isang salamin ng magkakaugnay na mga proseso ng disenyo sa lahat ng mga yugto ng ikot ng buhay ng EIS.
Ang mga pangunahing kinakailangan para sa napiling teknolohiya ng disenyo ay kinabibilangan ng mga sumusunod:
Ang proyektong ginawa gamit ang teknolohiyang ito ay dapat matugunan ang mga kinakailangan ng customer;
Ang napiling teknolohiya ay dapat sumasalamin hangga't maaari sa lahat ng mga yugto ng ikot ng buhay ng proyekto;
Dapat tiyakin ng napiling teknolohiya ang kaunting gastos sa paggawa at gastos para sa disenyo at suporta sa proyekto;
Ang teknolohiya ay dapat na maging batayan ng koneksyon sa pagitan ng disenyo at pagpapanatili ng proyekto;
Ang teknolohiya ay dapat tumulong sa pagtaas ng produktibidad ng taga-disenyo;
Dapat tiyakin ng teknolohiya ang pagiging maaasahan ng disenyo at pagpapatakbo ng proyekto;
Dapat mapadali ng teknolohiya ang madaling pagpapanatili ng dokumentasyon ng proyekto.
Ang batayan ng teknolohiya ng disenyo ng EIS ay isang pamamaraan na tumutukoy sa kakanyahan, ang pangunahing natatanging tampok na teknolohikal.
Pamamaraan ng disenyo ipinapalagay ang pagkakaroon ng isang tiyak na konsepto, mga prinsipyo ng disenyo, na ipinatupad ng isang hanay ng mga pamamaraan ng disenyo, na, sa turn, ay dapat na suportado ng ilang mga tool sa disenyo.
Ang organisasyon ng disenyo ay nagsasangkot ng pagtukoy ng mga paraan ng pakikipag-ugnayan sa pagitan ng mga taga-disenyo sa kanilang sarili at sa customer sa proseso ng paglikha ng isang proyekto ng EIS, na maaari ding suportahan ng isang hanay ng mga partikular na tool.
Ang mga pamamaraan ng disenyo ng EIS ay maaaring uriin ayon sa antas ng paggamit ng mga tool sa automation, mga karaniwang solusyon sa disenyo, at kakayahang umangkop sa mga inaasahang pagbabago.
Oo, ayon sa degree automation Ang mga pamamaraan ng disenyo ay nahahati sa mga pamamaraan:
disenyo ng kamay, kung saan ang disenyo ng mga bahagi ng EIS ay isinasagawa nang hindi gumagamit ng mga espesyal na tool sa software, at ang programming ay ginagawa sa mga wikang algorithm;
disenyo ng kompyuter, na bumubuo o nagko-configure (nagse-set up) ng mga solusyon sa disenyo batay sa paggamit ng mga espesyal na tool sa software.
Batay sa antas ng paggamit ng mga karaniwang solusyon sa disenyo, ang mga sumusunod na pamamaraan ng disenyo ay nakikilala:
Orihinal (indibidwal) na disenyo, kapag ang mga solusyon sa disenyo ay binuo "mula sa simula" alinsunod sa mga kinakailangan para sa EIS;
Karaniwang disenyo, na kinabibilangan ng pagsasaayos ng isang EIS mula sa mga yari na karaniwang solusyon sa disenyo (mga module ng software).
Ang orihinal (indibidwal) na disenyo ng EIS ay nailalarawan sa pamamagitan ng katotohanan na ang lahat ng mga uri ng gawaing disenyo ay nakatuon sa paglikha ng mga indibidwal na proyekto para sa bawat bagay, na sumasalamin sa lahat ng mga tampok nito sa pinakamataas na lawak.
Ang karaniwang disenyo ay isinasagawa batay sa karanasan na nakuha sa pagbuo ng mga indibidwal na proyekto. Ang mga tipikal na proyekto bilang generalization ng karanasan para sa ilang partikular na grupo ng mga sistemang pang-organisasyon at pang-ekonomiya o mga uri ng trabaho sa bawat partikular na kaso ay nauugnay sa maraming partikular na tampok at naiiba sa antas ng saklaw ng mga function ng pamamahala, gawaing isinagawa at dokumentasyon ng proyekto na binuo.
Ayon sa antas ng kakayahang umangkop ng mga solusyon sa disenyo, ang mga pamamaraan ng disenyo ay inuri sa mga pamamaraan:
Ang muling pagtatayo, kapag ang pagbagay ng mga solusyon sa disenyo ay isinasagawa sa pamamagitan ng pagproseso ng mga kaugnay na bahagi (reprogramming software modules);
Parameterization, kapag ang mga solusyon sa disenyo ay nababagay (regenerated) alinsunod sa mga nabagong parameter;
Ang pagbabagong-tatag ng modelo, kapag nagbabago ang modelo ng lugar ng problema, batay sa kung aling mga solusyon sa disenyo ang awtomatikong muling nabuo.
Ang kumbinasyon ng iba't ibang mga katangian ng pag-uuri ng mga pamamaraan ng disenyo ay tumutukoy sa likas na katangian ng teknolohiya ng disenyo ng EIS na ginamit, bukod sa kung saan dalawang pangunahing namumukod-tangi:
klase: canonical at industrial na teknolohiya (Talahanayan 2.1). Ang teknolohiyang pang-industriya na disenyo, naman, ay nahahati sa dalawang subclass: automated (gamit ang mga teknolohiya ng CASE) at standard (parameter-oriented o model-oriented) na disenyo. Ang paggamit ng mga teknolohiyang pang-industriya na disenyo ay hindi ibinubukod ang paggamit ng canonical na teknolohiya sa ilang mga kaso.
Talahanayan 2.1 Mga katangian ng mga klase ng teknolohiya sa disenyo
Ang mga partikular na uri ng mga teknolohiya sa disenyo ay nailalarawan sa pamamagitan ng paggamit ng ilang partikular na tool sa pagpapaunlad ng EIS na sumusuporta sa pagpapatupad ng parehong indibidwal na gawain sa disenyo, mga yugto, at mga kumbinasyon ng mga ito. Samakatuwid, ang mga developer ng EIS, bilang panuntunan, ay nahaharap sa gawain ng pagpili ng mga tool sa disenyo na, sa mga tuntunin ng kanilang mga katangian, pinakamahusay na nakakatugon sa mga kinakailangan ng isang partikular na negosyo.
Ang mga tool sa disenyo ay dapat na:
Sa klase nito, invariant sa object ng disenyo;
Sakop sa pinagsama-samang lahat ng mga yugto ng ikot ng buhay ng EIS;
Sa teknikal na paraan, tugma ang software at impormasyon;
Madaling matutunan at gamitin;
Magagawa sa ekonomiya.
Ang mga tool sa disenyo ng EIS ay maaaring nahahati sa dalawang klase: nang walang paggamit ng computer at sa paggamit ng computer.
Ang mga tool sa disenyo nang hindi gumagamit ng computer ay ginagamit sa lahat ng yugto at yugto ng disenyo ng EIS. Bilang isang patakaran, ang mga ito ay paraan ng organisasyonal at metodolohikal na suporta para sa mga pagpapatakbo ng disenyo at, una sa lahat, iba't ibang mga pamantayan na kumokontrol sa proseso ng disenyo ng system. Kasama rin dito ang isang pinag-isang sistema ng pag-uuri at coding ng impormasyon, isang pinag-isang sistema ng dokumentasyon, mga modelo para sa paglalarawan at pagsusuri ng mga daloy ng impormasyon, atbp.
Ang mga tool sa disenyo gamit ang isang computer ay maaaring gamitin kapwa sa indibidwal at sa lahat ng mga yugto at yugto ng proseso ng disenyo ng EIS at, nang naaayon, sinusuportahan ang pagbuo ng mga elemento ng disenyo ng system, mga seksyon ng disenyo ng system, at ang disenyo ng system sa kabuuan. Ang buong hanay ng mga tool sa disenyo gamit ang mga computer ay nahahati sa apat na subclass.
Kasama sa unang subclass ang mga tool sa pagpapatakbo na sumusuporta sa disenyo ng mga operasyon sa pagpoproseso ng impormasyon. Kasama sa subclass ng mga tool na ito ang mga algorithmic na wika, mga library ng mga karaniwang subroutine at object class, macrogenerators, program generator para sa mga tipikal na operasyon sa pagpoproseso ng data, atbp., pati na rin ang mga tool para sa pagpapalawak ng mga function ng mga operating system (utility). Kasama rin sa klase na ito ang mga simpleng tool sa disenyo bilang mga tool para sa pagsubok at pag-debug ng mga programa, pagsuporta sa proseso ng dokumentasyon ng proyekto, atbp. Ang kakaiba ng pinakabagong mga programa ay na sa kanilang tulong, ang pagiging produktibo ng mga taga-disenyo ay nadagdagan, ngunit ang isang kumpletong solusyon sa disenyo ay hindi binuo.
Kaya, ang mga tool ng subclass na ito ay sumusuporta sa mga indibidwal na operasyon ng disenyo ng EIS at maaaring magamit nang hiwalay sa isa't isa.
Kasama sa pangalawang subclass ang mga tool na sumusuporta sa disenyo ng mga indibidwal na bahagi ng isang proyekto ng EIS. Kasama sa subclass na ito ang mga tool para sa pangkalahatang layunin ng system:
Mga sistema ng pamamahala ng database (DBMS);
Mga pakete na nakatuon sa pamamaraan ng mga application program (paglutas ng mga problema sa discrete programming, mga istatistika ng matematika, atbp.)
Mga processor ng talahanayan;
Statistical PPP;
Mga shell ng ekspertong sistema;
Graphic editor;
Mga editor ng teksto;
Pinagsamang software (isang interactive na kapaligiran na may mga built-in na kakayahan sa dialog na nagbibigay-daan sa iyong isama ang mga tool sa software sa itaas).
Ang mga nakalistang tool sa disenyo ay nailalarawan sa pamamagitan ng kanilang paggamit para sa pagbuo ng mga teknolohikal na subsystem ng EIS: input ng impormasyon, organisasyon ng imbakan at pag-access sa data, mga kalkulasyon, pagsusuri at pagpapakita ng data, paggawa ng desisyon.
Kasama sa ikatlong subclass ang ibig sabihin na suporta disenyo ng mga seksyon ng proyekto ng EIS. Kasama sa subclass na ito ang mga functional na tool sa disenyo.
Ang mga functional na tool ay naglalayong bumuo ng mga automated system na nagpapatupad ng mga function, set ng mga gawain at mga control task. Ang iba't ibang mga lugar ng paksa ay nagbibigay ng iba't ibang mga tool ng subclass na ito, na nakatuon sa uri ng sistema ng organisasyon (pang-industriya, hindi pang-industriya na lugar), antas ng pamamahala (halimbawa, enterprise, workshop, departamento, site, lugar ng trabaho), pamamahala function (pagpaplano, accounting, atbp.) .
Kasama sa mga functional na tool sa disenyo para sa mga system sa pagpoproseso ng impormasyon ang mga karaniwang solusyon sa disenyo, mga functional na pakete ng mga application program, at karaniwang mga proyekto.
Kasama sa ikaapat na subclass ng mga tool sa disenyo ng EIS ang mga tool na sumusuporta sa pagbuo ng proyekto sa mga yugto at yugto ng proseso ng disenyo. Kasama sa klase na ito ang isang subclass ng EIS design automation tools (CASE tools).
Ang mga modernong CASE tool, sa turn, ay inuri pangunahin ayon sa dalawang pamantayan:
1) sa pamamagitan ng mga yugto na saklaw sa proseso ng pagbuo ng EIS;
2) ayon sa antas ng pagsasama: hiwalay na mga lokal na tool (mga tool), isang hanay ng mga hindi pinagsamang tool na sumasaklaw sa karamihan ng mga yugto ng pag-unlad ng EIS (toolkit) at ganap na pinagsama-samang mga tool na naka-link ng isang karaniwang database ng disenyo - isang imbakan (workbench).
Ang pagdidisenyo ng AIS ay isang malikhaing proseso. Ang bawat proyekto ay dumaan sa ilang partikular na estado sa pagbuo nito: mula sa estado kung kailan “wala pa ang proyekto” hanggang sa estado kapag “wala na ang proyekto.” Ang hanay ng mga yugto ng pag-unlad mula sa paglitaw ng isang ideya hanggang sa kumpletong pagkumpleto ng isang proyekto ay karaniwang nahahati sa mga yugto (mga yugto, mga yugto). Mayroong ilang mga pagkakaiba sa pagtukoy ng bilang ng mga yugto (phase) at kanilang nilalaman, ngunit gayunpaman ang kakanyahan ng nilalaman ng siklo ng buhay ng pag-unlad ng AIS ay pareho sa iba't ibang mga diskarte.
Sa ilalim ng disenyo dapat maunawaan ng isa ang proseso ng paglikha ng isang prototype ng isang dapat o posibleng bagay.
Ang modernong teknolohiya para sa paglikha ng AIS ay isang hanay ng mga epektibong tool at pamamaraan ng disenyo na ginagawang posible upang gawing simple ang prosesong ito, bawasan ang mga gastos, bawasan ang oras ng kalendaryo para sa disenyo ng system at pagbutihin ang kalidad ng pag-unlad sa pamamagitan ng malawak na seleksyon ng mga napatunayang advanced na solusyon sa disenyo.
Sa pangunahing mga kasangkapan sa disenyo maaaring maiugnay:
Mga karaniwang solusyon sa disenyo (TDS) at application software packages (APP). TPR - isang hanay ng mga elemento ng algorithmic at software na tinitiyak ang pagpapatupad ng mga gawain sa isang computer gamit ang naaangkop na teknikal na paraan;
Computer-aided design (CAD) system, na kinabibilangan ng paggamit ng mga computer sa lahat ng yugto ng paglikha ng AIS.
Pangkalahatang mga kinakailangan para sa mga tool sa disenyo:
Buong saklaw ng buong proseso ng paglikha ng AIS;
Pagkakatugma, i.e. pare-pareho sa proseso ng paglikha ng system at sa proseso ng paggana nito;
Versatility, i.e. ang kakayahang gumamit ng parehong paraan para sa iba't ibang mga bagay;
Accessibility upang matuto at pagiging simple (simplicity) upang ipatupad;
Ang kakayahang ayusin ang proseso ng disenyo sa mode ng interactive na pakikipag-ugnayan sa pagitan ng developer ng system, designer at computer;
Kakayahang umangkop at pagiging epektibo sa gastos.
Among mga pamamaraan ng disenyo highlight:
Orihinal na disenyo;
Standard na disenyo at mga uri nito: elemental, subsystem, modular, grupo;
Awtomatikong disenyo.
Ang orihinal na paraan ng disenyo ay tradisyonal at nakatuon sa isang partikular na negosyo. Ang isang tampok na katangian ng pamamaraang ito ay ang pagbuo ng mga orihinal na pamamaraan para sa pagsusuri ng isang bagay at ang paglikha ng kinakailangang dokumentasyon sa anyo ng isang indibidwal na proyekto. Ang bentahe ng pamamaraang ito ay ang pagmuni-muni ng mga partikular na tampok ng object ng automation sa proyekto ng AIS. Kabilang sa mga disadvantage ang medyo mataas na labor intensity at mahabang oras ng pag-unlad, mababang functional reliability at adaptability sa pagbabago ng mga kondisyon. Ang mga proyektong nilikha ng orihinal na pamamaraan ay maaaring gawing moderno, ngunit ang pamamaraang ito ay bihirang ginagamit sa dalisay nitong anyo. Ngayon, kapag ipinatupad ito, iba't ibang mga tool sa disenyo ang ginagamit at ilang bahagi lamang ng proyekto ang nangangailangan ng mga orihinal na solusyon sa disenyo. Ito ay medyo nagpapakinis sa mga pagkukulang nito. Gayunpaman, ang pamamaraang ito ay nananatiling may kaugnayan kapag nag-automate ng mga kumplikado, hindi pangkaraniwang mga bagay.
Sa modernong mga kondisyon, ang AIS, bilang panuntunan, ay hindi nilikha mula sa simula. Sa kasalukuyan, sa ekonomiya, ang mga awtomatikong sistema ng pagpoproseso ng impormasyon ay tumatakbo sa halos lahat ng antas ng pamamahala at sa lahat ng mga pasilidad sa ekonomiya. Ang tumaas na pangangailangan para sa napapanahong, mataas na kalidad at impormasyon sa pagpapatakbo ay nangangailangan ng paglikha ng isang awtomatikong sistema ng impormasyon sa isang bagong teknikal at teknolohikal na batayan.
Ang paghahanap para sa makatwirang mga landas sa disenyo ay isinasagawa sa mga sumusunod na direksyon:
1. pagbuo ng mga standard na solusyon sa disenyo na ipinatupad sa application software packages (APP) upang malutas ang mga problemang pang-ekonomiya sa kasunod na pag-uugnay ng PPP sa mga partikular na kondisyon ng pagpapatupad at operasyon;
2. pagbuo ng mga automated na sistema ng disenyo.
Ang unang paraan ay ang kakayahang gumamit ng mga karaniwang solusyon sa disenyo na kasama sa mga pakete ng software ng application.
Karaniwang disenyo- isang pang-industriyang paraan ng paglikha ng AIS gamit ang TPR at PPP. Ang pamamaraang ito ay nailalarawan sa pagkakaroon ng napatunayan, karaniwang pang-organisasyon, pang-ekonomiya, teknikal, impormasyon, matematika at mga tool sa automation ng pamamahala ng software. Ang paggamit ng paraang ito ay ginagawang posible na bawasan ang lakas ng paggawa, bawasan ang gastos, paikliin ang oras ng disenyo, at pagbutihin ang kalidad ng disenyo. Ang karaniwang proseso ng disenyo ay binubuo ng pagpili at pag-link ng mga sumusuportang subsystem alinsunod sa mga kinakailangan ng isang partikular na AIS. Ang karaniwang bahagi ng AIS ay isang kumplikadong impormasyon, software at hardware. Ang karaniwang katangian ng suporta sa impormasyon ay nakakamit sa pamamagitan ng mahigpit na pagsunod sa pagkakaisa ng istraktura ng base ng impormasyon, ang komposisyon ng mga array, at ang mga anyo ng input at output na mga dokumento. Ang karaniwang katangian ng software ay nakakamit sa pamamagitan ng paggamit ng software, at ang karaniwang katangian ng hardware ay nakakamit sa pamamagitan ng paggamit ng mga computer ng pareho o magkasanib na uri.
1. Ang isang pagkakaiba-iba ng karaniwang paraan ng disenyo ay ang pamamaraan elementong disenyo, ang batayan nito ay TPR. Kapag bumubuo ng isang proyekto, isang handa na solusyon na may maliit na pagbabago ang ginagamit, sa halip na isang bago na binuo.
2. Kapag gumagamit modular na pamamaraan Ang mga TPR ay nilikha sa isang modular na batayan, kapag ang bawat solusyon sa disenyo ay nahahati sa magkakahiwalay na mga bahagi - mga module, na nagpapatupad ng isang tiyak na bahagi ng TPR. Nagbibigay-daan ito sa iyo na lumikha ng isang proyekto para sa isang bagong automated system sa pamamagitan ng pagsasama-sama ng mga indibidwal na karaniwang module.
3. Kapag gumagamit pamamaraan ng disenyo ng subsystem Para sa bawat subsystem, nilikha ang mga solusyon sa proyekto at application software package - sa buong system at gumagana. Ang paglalaan ng mga subsystem ay nakasalalay sa layunin ng proseso ng ekonomiya at produksyon. Para sa bawat isa sa mga subsystem, ang sarili nitong automated na solusyon sa disenyo at PPP ay binuo, na maaaring maging system-wide o functional. Kasama sa buong sistema ang mga PPP para sa pamamahala ng data, mga PPP para sa karaniwang mga pamamaraan sa pagpoproseso ng data, mga pamamaraan ng matematikal na istatistika at discrete programming, atbp. Kasama sa mga functional na PPP ang mga pakete na naglalayon sa mga pang-industriyang negosyo na may discrete o tuluy-tuloy na katangian ng produksyon, ang non-industrial sphere, at pamamahala sa industriya.
Ang isang mahalagang kinakailangan para sa PPP ay ang pagiging tugma, dahil Kapag nagdidisenyo ng isang AIS, ipinapayong gumamit ng ilang mga pakete nang sabay-sabay. Ang pagdidisenyo ng mga system gamit ang PPP ay talagang bumababa sa pagli-link ng mga package na pinili ayon sa ilang mga parameter sa mga partikular na kundisyon ng automation object. Ang mga positibong katangian ng diskarteng ito sa disenyo ay maaaring tawaging: isang mas kaunting proseso ng paggawa, isang pagbawas sa oras ng disenyo kumpara sa orihinal na disenyo, ang pagpapatupad ng mga advanced na pamamaraan sa pagproseso ng data, pagpapagaan ng dokumentasyon ng proyekto (dahil ginagamit ang dokumentasyon ng pakete), at tumaas na pagiging maaasahan ng dinisenyong AIS.
4. Bilang karagdagan, itinatampok nila paraan ng disenyo ng pangkat. Ang kakanyahan nito ay nakasalalay sa paunang pagpili ng isang pangkat ng mga bagay na may katulad na mga katangian. Kabilang sa mga ito, ang isang batayang bagay ay napili kung saan binuo ang proyekto, at maaaring magamit ang iba't ibang mga pamamaraan at pamamaraan ng disenyo. Ang pangunahing bagay ay upang matiyak ang mataas na kakayahang umangkop ng proyekto. Ang pangunahing lugar ng aplikasyon ng pamamaraang ito ay mga pasilidad na hindi pang-industriya (halimbawa, mga bodega).
Ang mga sumusunod na uri ng aktibidad ay pinaka-epektibo sa automation:
1. accounting, kabilang ang managerial at financial. Ang pinakamalaking bilang ng mga PPP ay nilikha para sa mga layunin ng accounting. Kabilang sa mga ito ang "1C: Accounting", "Turbo-Accountant", "Info-Accountant", "Parus", "ABACUS", "Bambi+", atbp.;
2. mga serbisyo ng sanggunian at impormasyon para sa mga gawaing pang-ekonomiya. Kinakatawan ng sumusunod na PPP: "GARANT" (mga buwis, accounting, audit, entrepreneurship, pagbabangko, regulasyon ng pera, kontrol sa customs); "CONSULTANT+" (mga buwis, accounting, audit, entrepreneurship, banking, currency regulation, customs control).
3. mga gawaing pang-ekonomiya at pananalapi. Kinakatawan ng sumusunod na PPP:
a) "Pagsusuri sa ekonomiya at pagtataya ng mga aktibidad ng isang kumpanya, organisasyon" (firm "INEK"), na nagpapatupad ng mga pag-andar: pagsusuri sa ekonomiya ng mga aktibidad ng isang kumpanya, negosyo; pagguhit ng mga plano sa negosyo; feasibility study ng pagbabayad ng utang; pagsusuri at pagpili ng mga opsyon sa aktibidad; pagtataya ng balanse, mga daloy ng salapi at mga natapos na produkto.
b) Multi-user network complex ng buong automation ng Galaktika Corporation (JSC New Atlant), na kinabibilangan ng pagpaplano, pamamahala sa pagpapatakbo, accounting at kontrol, pagsusuri, bilang karagdagan, ay nagbibigay-daan, sa loob ng balangkas ng DSS, na magbigay ng mga solusyon sa negosyo mga problema sa pagpaplano gamit ang PPP Project- Expert.
4. organisasyon ng trabaho ng manager;
5. automation ng daloy ng dokumento;
6. pagsasanay.
Kamakailan lamang, mas gusto ng mga negosyo at kumpanya na bumili ng mga handa na pakete at teknolohiya, at kung kinakailangan, magdagdag ng kanilang sariling software sa kanila, dahil ang pagbuo ng kanilang sariling AIS ay nauugnay sa mataas na gastos at panganib. Bilang isang patakaran, ang isang pangunahing sistema ay binuo at inaalok, na inangkop ayon sa kagustuhan ng mga indibidwal na kliyente. Kasabay nito, ang mga gumagamit ay binibigyan ng mga konsultasyon na makakatulong upang mabawasan ang oras ng pagpapatupad ng mga system at teknolohiya, gamitin ang mga ito nang pinakamabisa, at mapabuti ang mga kwalipikasyon ng mga tauhan.
Mga awtomatikong sistema ng disenyo - ang pangalawa, mabilis na pagbuo ng paraan ng pagsasagawa ng gawaing disenyo.
Kabilang sa mga awtomatikong pamamaraan ng disenyo, ang mga pamamaraan ng disenyo ng modelo ay sumasakop sa isang espesyal na lugar. Ang paglikha at paggamit ng CAD ay nagsisiguro ng isang medyo mataas na antas ng functional na pagiging maaasahan, komprehensibong saklaw ng lahat ng mga teknolohikal na proseso, na binabawasan ang labor intensity ng disenyo ng trabaho na may pinakamataas na pagsasaalang-alang sa mga interes ng automation object. Gayunpaman, ang pamamaraang ito ay medyo mahal at nangangailangan ng mataas na kwalipikadong mga developer. Ang pangunahing kinakailangan para sa CAD ay ang kakayahang bumuo at magpanatili sa sistema ng disenyo sa isang sapat na estado ng ilang pandaigdigang modelo ng impormasyon sa ekonomiya ng object ng automation. Ang isang modelo ay isang pagpapakita ng mga bahagi ng impormasyon ng isang bagay ng automation at ang mga ugnayan sa pagitan ng mga ito, na tahasang tinukoy. Ang pangunahing layunin ng pagbuo ng isang modelo ay upang lumikha ng isang proyekto ng AIS na naaayon sa modelong ito, na isinasaalang-alang at aktibong ginagamit ang lahat ng mga katangian ng bagay. Ang nasabing modelo ay dapat maglaman ng isang pormal na paglalarawan ng mga hanay ng mga bahagi ng impormasyon at ang mga ugnayan sa pagitan ng mga ito, kabilang ang mga koneksyon ng impormasyon at pakikipag-ugnayan ng algorithm. Gamit ang paraan ng disenyo ng modelo, ginagamit ang isang sistematikong diskarte, na nagtatakda ng paggamit ng mga computer hindi lamang sa lahat ng mga yugto ng paglikha ng isang sistema, kundi pati na rin sa proseso ng pagsusuri ng mga resulta ng pang-industriyang operasyon nito. Ang pagbuo at aplikasyon ng CAD ay paunang natukoy ang paglipat sa paglikha ng mga indibidwal na proyekto, ngunit sa isang mas mataas na antas kumpara sa orihinal na paraan ng disenyo.
Sa larangan ng automation ng disenyo ng IS at IT, isang bagong direksyon ang lumitaw sa nakalipas na dekada - CASE teknolohiya para sa automated software development(CASE - Computer-Aided Software/System Engineering). Ang pagtaas ng pagiging kumplikado ng mga sistema ng impormasyon at ang pagtaas ng mga kinakailangan para sa mga ito ay humantong sa pangangailangan na gawing industriyalisado ang mga teknolohiya para sa kanilang paglikha.
CASE teknolohiya ay isang hanay ng mga pamamaraan para sa pagsusuri, pagdidisenyo, pagbuo at pagpapanatili ng IS, na sinusuportahan ng isang hanay ng magkakaugnay na mga tool sa automation. Ang CASE ay isang toolkit para sa mga system analyst, developer at programmer na nagbibigay-daan sa iyong i-automate ang proseso ng pagdidisenyo at pagbuo ng IS. Ang mga sistema ng CASE ay ginagamit bilang isang makapangyarihang tool para sa paglutas ng mga problema sa pananaliksik at disenyo, tulad ng pagsusuri sa istruktura ng isang paksa, pagpapatupad ng mga proyekto gamit ang pinakabagong henerasyon ng mga programming language, paglabas ng dokumentasyon ng proyekto, pagsubok ng pagpapatupad ng proyekto, pagpaplano at kontrol ng mga pagpapaunlad, pagmomodelo ng mga aplikasyon sa negosyo upang malutas ang mga problema sa pagpapatakbo at madiskarteng pagpaplano at pamamahala ng mapagkukunan, atbp.
Ang pangunahing layunin ng CASE ay upang i-maximize ang automation ng pagbuo at pagpapatakbo ng mga system.
Kapag gumagamit ng mga teknolohiya ng CASE, nagbabago ang teknolohiya para sa pagsasagawa ng trabaho sa lahat ng yugto ng ikot ng buhay ng mga automated system. Sa mga sistema ng CASE, ang disenyo ay nakabatay sa malinaw na visual na mga paraan ng pag-unlad, habang ang mga graph, diagram, talahanayan, diagram at mga textual na paliwanag para sa mga ito ay ginagamit upang ilarawan ang modelo ng dinisenyong IS. Ang ganitong mga pamamaraan ay nagbibigay ng isang mahigpit at visual na paglalarawan ng idinisenyong sistema, na nagsisimula sa pangkalahatang pangkalahatang-ideya nito at pagkatapos ay nagiging detalyado, na nakakakuha ng hierarchical na istraktura na may tumataas na bilang ng mga antas.
Ang pag-automate ng programming ay batay sa awtomatikong pagbuo ng mga code ng programa na naglalaman ng mga paglalarawan ng data, ang pangunahing lohika ng kanilang pagproseso, mga schema ng database, mga file ng paglalarawan ng interface, atbp. Ang mga code ay kasunod na pino at tinatapos, ngunit sa ilang mga kaso ang automation ay umabot sa 90% . Bilang karagdagan, ang teknolohiya ng CASE ay bumubuo ng kinakailangang dokumentasyon ng proyekto, na handa nang gamitin.
Kapag gumagamit ng teknolohiya ng CASE, ibinibigay ang suporta para sa isang base ng proyekto, i.e. lahat ng impormasyon tungkol sa binuong AIS ay awtomatikong inilalagay sa isang database ng proyekto. Ito ay nagpapanatili ng pagkakapare-pareho, pagkakapare-pareho, pagkakumpleto at kaunting redundancy ng data ng disenyo.
Tinitiyak ng teknolohiya ng CASE ang pagtutulungan ng mga pangkat ng pagbuo, dahil ang iba't ibang grupo ng mga espesyalista ay binibigyan ng sapat na mga tool, pati na rin ang kakayahang mag-coordinate at gumawa ng tama ng mga pagbabago sa proyekto ng iba't ibang mga espesyalista sa real time.
Ang mga teknolohiya ng CASE ay matagumpay na ginagamit upang bumuo ng halos lahat ng uri ng AIS. Ginagamit din ang CASE upang lumikha ng mga modelo ng system na tumutulong sa mga komersyal na istruktura na malutas ang mga problema ng estratehikong pagpaplano, pamamahala sa pananalapi, pagtukoy sa mga patakaran ng kumpanya, pagsasanay sa mga tauhan, atbp.
Ang CASE ay may mga sumusunod na pangunahing bentahe:
Pagbutihin ang kalidad ng nilikha na mga sistema ng impormasyon (IT) sa pamamagitan ng awtomatikong kontrol na paraan (pangunahin ang kontrol ng proyekto);
Pinapayagan ka nilang lumikha ng isang prototype ng isang hinaharap na IS (IT) sa maikling panahon, na nagbibigay-daan sa iyo upang mabilis na masuri ang inaasahang resulta sa isang maagang yugto;
Pabilisin ang proseso ng disenyo at pag-unlad ng system;
Pinalalaya nila ang developer mula sa karaniwang gawain, na nagpapahintulot sa kanya na ganap na tumutok sa malikhaing bahagi ng disenyo;
Suportahan ang pagbuo at pagpapanatili ng gumagana nang mga sistema ng impormasyon.
Sa ngayon, nabuo ang isang malakas na industriya ng CASE, na pinag-iisa ang daan-daang mga kumpanya at kumpanya ng iba't ibang oryentasyon. Kabilang sa mga ito ay:
Mga kumpanyang gumagawa ng mga tool sa pagsusuri at disenyo para sa IS at IT
Mga kumpanyang gumagawa ng mga espesyal na tool na may pagtuon sa makitid na mga paksa o sa mga indibidwal na yugto ng ikot ng buhay ng IS;
Mga kumpanya ng pagsasanay na nag-aayos ng mga seminar at mga kurso sa pagsasanay para sa mga espesyalista;
Mga consulting firm na nagbibigay ng praktikal na tulong sa paggamit ng mga CASE package para sa pagbuo ng partikular na IS;
Mga kumpanyang nag-specialize sa paggawa ng mga periodical magazine at bulletin sa mga teknolohiya ng CASE.
Pamahalaan ng Rehiyon ng Belgorod Automated information system "Project Management" AIS "Project Management" Regulatory framework Ang solusyon ay nilikha alinsunod sa mga pamantayang itinatag sa Russian Federation, na nakasaad sa: 1. GOST R 54869—2011 "Project Management. Mga kinakailangan para sa pamamahala ng proyekto." 2. GOST R 54870—2011 “Pamamahala ng proyekto. Mga kinakailangan para sa pamamahala ng portfolio ng proyekto." 3. GOST R 54871—2011 “Pamamahala ng proyekto. Mga kinakailangan para sa pamamahala ng programa." Kapag lumilikha at nagse-set up ng system, ang mga probisyon ng Pamahalaan ng Rehiyon ng Belgorod noong Mayo 31, 2010 N 202-pp "Sa pag-apruba ng Mga Regulasyon sa pamamahala ng proyekto sa mga ehekutibong awtoridad at mga katawan ng gobyerno ng Rehiyon ng Belgorod" ay isinasaalang-alang. . 2 AIS “Project Management” Development technology Internet Network Local network Ang solusyon ay binuo batay sa platform ng Motiware Melody One. Salamat sa web interface ng system, lahat ng mga kalahok ng proyekto ay may access sa kinakailangang data anumang oras at mula saanman sa mundo. Upang ma-access ang system, kailangan mo lamang ng koneksyon sa Internet at isang naka-install na browser. Server part 3 ng AIS “Project Management” Goals Mga Layunin para sa paglikha at pagpapatupad ng system: . Upang madagdagan ang kahusayan ng pagpapatupad ng proyekto sa teritoryo ng isang constituent entity ng Russian Federation sa pamamagitan ng pagbibigay ng mga koponan ng proyekto ng napapanahon, kumpleto at maaasahang impormasyon. . Pahusayin ang pakikipag-ugnayan sa pagitan ng mga awtoridad ng estado at mga lokal na pamahalaan sa mga mamamayan at negosyo sa mga tuntunin ng pagsisimula at pagpapatupad ng mga proyekto. . Bigyan ang lahat ng mga kalahok sa proyekto ng mga maginhawang tool at tool sa pamamahala ng proyekto. . Pasimplehin ang pagsubaybay sa progreso ng proyekto sa pamamagitan ng pagbawas sa oras na ginugol sa paghahanda at pagsusuri ng data ng pag-uulat. 4 AIS “Project Management” System functions Ang system ay nagbibigay-daan sa iyo na ayusin ang buong cycle ng proyekto at/o portfolio ng proseso ng pamamahala ng mga proyekto. Ang isang proyekto sa system ay sunud-sunod na dumaan sa ilang mga yugto - mula sa pagrehistro ng isang inisyatiba na aplikasyon hanggang sa paglipat ng natapos na proyekto sa archive. . Pagsasaalang-alang ng mga aplikasyon ng inisyatiba. Pagtanggap sa bagong kasapi. Pagpaplano. Pagpapatupad at Pagkontrol. Pagkumpleto ng 5 AIS "Pamamahala ng Proyekto" Makipagtulungan sa mga aplikasyon ng inisyatiba AIS "Pamamahala ng Proyekto" Mga Proyekto Mga aplikasyon para sa Inisyatiba Portal ng pakikipag-ugnayan sa mga mamamayan at negosyo Archive (mga tinanggihang aplikasyon) 6 AIS "Pamamahala ng Proyekto" Yugto ng pagsisimula ng proyekto 2. Pagsisimula ng proyekto. Awtomatikong pagtatalaga ng isang natatanging numero ng pagpaparehistro sa proyekto. . Pagbubuo ng project card batay sa data na tinukoy sa inisyatiba na aplikasyon. 7 AIS “Project Management” Yugto ng pagsisimula ng proyekto 3. Pagbuo ng pasaporte ng proyekto. Posibilidad ng sunud-sunod na pag-edit ng passport card ng proyekto (mga patlang). . Accounting para sa badyet ng proyekto sa pamamagitan ng mga mapagkukunan ng pagpopondo. . Pagbuo ng isang pangkat ng proyekto na nagsasaad ng mga tungkulin ng mga kalahok. . Pagpasok at pag-edit ng mga katangian ng proyekto. . Pagbuo ayon sa itinatag na form at pag-upload mula sa system ng isang pasaporte ng proyekto sa *.docx na format. 8 AIS "Pamamahala ng Proyekto" Yugto ng pagpaplano ng proyekto 4. Paglikha ng isang plano sa pamamahala ng proyekto. Pagtatanghal ng plano sa pamamahala ng proyekto gamit ang isang Gantt chart. . Pagpaplano ng trabaho sa proyekto, na nagpapahiwatig ng mga petsa ng pagsisimula at pagtatapos, mga responsableng tagapagpatupad at mga kinakailangan para sa mga resulta ng trabaho. . Paglikha ng isang hierarchical na listahan ng mga gawa para sa proyekto. . Pagbuo ayon sa itinatag na form at pag-download mula sa system ng isang plano sa pamamahala ng proyekto sa *.docx na format. 9 AIS “Project Management” Implementation and control stage 5. Organisasyon ng proseso ng paggawa ng mga pagbabago sa pasaporte at plano sa pamamahala ng proyekto. Paglikha at pag-edit ng mga bagong bersyon ng pasaporte at/o plano sa pamamahala ng proyekto. . Pagbubuo ayon sa itinatag na modelo at pag-upload mula sa system ng isang listahan ng mga pagbabago sa *.docx na format. . Koordinasyon ng listahan ng mga pagbabago sa monitoring at control group. 10 AIS “Project Management” Implementation and control stage 6. Accounting para sa pagpapatupad ng trabaho sa proyekto. Ang kakayahan para sa mga performer na mag-attach ng mga file ng ulat sa pagkumpleto ng trabaho. . Accounting para sa aktwal na mga petsa ng pagkumpleto ng trabaho at mga paglihis mula sa mga nakaplanong petsa. . Pagsubaybay sa paparating at overdue na mga milestone. 11 AIS “Project Management” Completion stage 7. Pagbuo ng final report. Pagkalkula ng pagtatasa ng tagumpay ng proyekto. . Pagbubuo ayon sa itinatag na template at pag-upload ng huling ulat mula sa system sa *.docx na format. 12 AIS “Project Management” Project archive 8. Pagpapanatili ng project archive. Paglikha ng isang solong warehouse ng data tungkol sa lahat ng mga proyektong pinasimulan sa teritoryo ng isang nasasakupang entity ng Russian Federation. . Access sa kumpletong impormasyon tungkol sa mga natapos at naka-archive na proyekto. . Proteksyon laban sa mga pagbabago sa mga natapos na proyekto. 13 Mga Ulat at analytics ng "Pamamahala ng Proyekto" ng AIS Ang isa sa mga layunin ng system ay upang bigyan ang mga kalahok sa mga aktibidad ng proyekto ng impormasyon sa pag-uulat tungkol sa mga proyekto sa isang maginhawa at visual na anyo. Binibigyang-daan ka ng AIS na awtomatikong bumuo ng dokumentasyon ng proyekto: . Pasaporte ng proyekto. . Plano sa pamamahala ng proyekto. . Panghuling ulat. 14 AIS "Pamamahala ng Proyekto" Impormasyon sa pagpapatupad Higit sa AIS "Pamamahala ng Proyekto" ay matagumpay na ginamit upang isagawa ang mga aktibidad ng proyekto ng mga awtoridad ng rehiyon ng Belgorod. 4,200 proyekto 5,000 user ng AIS “Project Management” 60,000 gawa (control events) 19 municipal districts 3 city districts 15 Government of the Belgorod Region Salamat sa iyong atensyon! 16