3) opis dejanj operaterja pri delu s programi (pravila za zagon programov, zaporedje dela, dejanja v morebitnih nestandardnih situacijah itd.).
Opis testnega primera vključuje opis:
1) funkcije in parametre programske opreme, ki jo testira testni primer;
2) sestava tehničnih sredstev, potrebnih za preverjanje programske opreme v tem primeru;
3) vhodne informacije;
4) rezultate izvajanja programov glede na podatke testnega primera;
5) dejanja operaterja pri preverjanju programa na testnem primeru;
6) rezultati testa (kontrolni standard) programov na testnem primeru.
Postopek prenosa programske dokumentacije
Vsi programi in navodila, ki jih razvijalec preveri na testnem primeru, se predajo naročniku po aktu, ki potrjuje sprejem v poskusno delovanje.
Programska oprema, navodila in opisi algoritmov, ki se predajo naročniku, morajo ustrezati zahtevam glede sestave in vsebine delovnega projekta informacijskega sistema. Stranka prejme programe, posnete na magnetnem nosilcu. Stranka razvijalcu zagotovi magnetne medije in računalniški čas, ki je potreben za poskusno delovanje programov in njihovo podvajanje (če je potrebno).
Sprejem niza nalog (podsistemov) za poskusno delovanje je sestavljen iz reševanja testnega primera s strani posebej usposobljenega osebja stranke v prisotnosti predstavnikov razvijalcev, čemur sledi analiza rezultatov. Po dogovoru lahko testni primer izvede razvijalec v prisotnosti stranke.
Na podlagi rezultatov prevzema se podpiše potrdilo o sprejemu programske opreme za poskusno delovanje. Odkriti
napake razvijalca v programih in tehnični dokumentaciji se odpravljajo v postopku poskusnega delovanja.
Organizacijska in administrativna dokumentacija
Za glavno delo, opravljeno v fazi "delovnega načrtovanja", je sestavljena naslednja organizacijska in administrativna dokumentacija:
1) za izvedbo dela na odru v skladu z urnikom organizacijski in tehnični ukrepi;
2) urnik skupnega dela izvajalca in naročnika;
3) akt preverjanja na testnih primerih in sprejem v poskusno delovanje delovnih programov;
4) akt o pripravljenosti normativne in referenčne dokumentacije;
5) dejanje izvajanja organizacijskih in tehničnih ukrepov za pripravo podjetja na implementacijo informacijskega sistema.
5.5. Zagon informacijskega sistema
Zagon informacijskega sistema in njegovih posameznih elementov je proces postopnega prehoda z obstoječih načinov upravljanja na avtomatizirane metode upravljanja.
Zagon informacijskega sistema organizira in izvede naročnik s sodelovanjem razvijalca in izvajalskih organizacij. Interakcija organizacij naročnika, razvijalca in soizvajalcev se izvaja na podlagi pogodbenih pogojev in terminskega načrta za začetek obratovanja informacijskega sistema.
Zagon se izvaja po fazah, začenši od faze razvoja tehnične zasnove, takoj ko je delovna dokumentacija pripravljena, in zagona tehničnih sredstev, ki zagotavljajo uvedbo čakalnih vrst ali objektov informacijskega sistema, ki lahko samostojno delujejo.
Informacijski sistem bi morali začeti uporabljati, če imate:
1) izvedeni dokumenti o izvajanju akcijskega načrta za pripravo objekta;
2) delovna dokumentacija za izvedbo namenske čakalne vrste ali informacijskega sistema kot celote;
3) usposobljeno osebje, ki skrbi za pripravo na zagon
delovanje in delovanje namenske čakalne vrste informacijskega sistema;
4) tehnična sredstva informacijskega sistema, ki so bila vzpostavljena za zagotavljanje delovanja izvedenih kompleksov nalog.
Organizacija dela
Izvede:
1) poskusno delovanje posameznih nalog in njihovih kompleksov;
2) prevzem kompleksov nalog za industrijsko delovanje;
3) izvajanje sprejemnih preizkusov;
4) sprejem sistema v industrijsko obratovanje.
Sestavo in zaporedje del določajo dogovorjeni terminski načrti, ki navajajo sestavo in časovni razpored naslednjih del:
1) za gradnjo, montažo, zagon in testiranje objektov informacijskega sistema od trenutka prejema delovne dokumentacije do zagona objektov za industrijsko obratovanje;
2) za poskusno delovanje in sprejemni testi kompleksov nalog;
3) zagotoviti prehod z obstoječih metod upravljanja
Za metode, ki jih predvideva projekt informacijskega sistema.
V fazi "Začetek delovanja informacijskega sistema"
naročnik je dolžan:
1) končati izvedbo organizacijski in tehnični ukrepi za pripravo podjetja na implementacijo informacijskega sistema in njihovo izdajo z akti;
2) zagotoviti, da osebje podjetja upošteva uradna in tehnološka navodila;
3) uvede v obratovanje tehnična sredstva, potrebna za izveden tehnološki proces obdelave podatkov;
4) izda nalog z urnikom za izvajanje poskusnega delovanja informacijskega sistema in skupaj z razvijalcem analizira rezultate poskusnega delovanja;
5) dokončanje poskusnega delovanja kompleksov nalog, ki so del informacijskega sistema, in njihov sprejem v industrijsko obratovanje;
6) spreminjati organizacijsko strukturo podjetja v skladu s projektom informacijskega sistema;
7) pripravi osnutek odredbe o sestavi sprejemne komisije;
8) razviti in se dogovoriti z razvijalcem osnutka programa sprejemni testi;
9) organizira delo sprejemne komisije, ji zagotovi potrebno dokumentacijo in izvaja preizkuse informacijskega sistema;
10) preveriti učinkovitost implementiranih rešitev v industrijskem obratovanju in na podlagi rezultatov analize delovanja sistema razviti priporočila za njegov nadaljnji razvoj.
V fazi "Začetek delovanja informacijskega sistema"
razvijalec je dolžan:
1) pravilna tehnična dokumentacija na podlagi rezultatov poskusnega delovanja informacijskega sistema;
2) sodeluje pri izdelavi osnutka programa sprejemnih preizkusov informacijskega sistema;
3) zagotavlja metodološko vodenje in sodeluje pri izvajanju nalog (sklopov nalog) za industrijsko obratovanje;
4) sodeluje pri delu komisije za sprejem informacijskega sistema v industrijsko obratovanje.
Postopek testnega delovanja
Začetek poskusnega delovanja nalog (kompleksov nalog), pogoji delovanja in sestava komisije za sprejem določene naloge ali podsistema se določijo z naročilom, ki ga izda naročnik in se dogovori z razvijalcem. Naročilu je priložen dogovor z
razvijalec je program poskusnega delovanja, ki določa pogoje za preverjanje kompleksov nalog, postopek preverjanja tehničnih sredstev pri reševanju kompleksov nalog (podsistemov) in postopek za odpravo pomanjkljivosti, ugotovljenih med poskusnim delovanjem.
Dodatne zahteve naročnika, ki so nastale v postopku poskusnega obratovanja, ki niso predvidene v projektnem zasnovi in tehnični zasnovi, niso podlaga za negativno oceno rezultatov poskusnega obratovanja in se lahko izpolnijo z dodatnim dogovorom. v dogovorjenem roku.
S pozitivnimi rezultati poskusnega delovanja nalog (podsistemov) se pripravi dvostranski akt o njihovem sprejemu v industrijsko obratovanje.
Po sprejemu informacijskega sistema v industrijsko obratovanje je naročnik odgovoren za njegovo delovanje v okviru sprejetih kompleksov nalog in sredstev.
Začetni in poročevalski dokumenti med testiranjem programske opreme informacijskega sistema
Skupne preizkuse izvaja komisija naročnika, ki vključuje vodjo razvoja in nekaj vodilnih razvijalcev. Testno komisijo vodijo naslednji dokumenti:
1) s strani pooblaščenega naročnika in dogovorjenega z razvijalcem pogojev izdelave informacijskega sistema;
2) trenutni državni in industrijski standardi za načrtovanje in testiranje programske in tehnične dokumentacije;
3) testni program za vse tehnične zahteve
4) preskusne metode za vsak odsek zahtev tehnične naloge.
Testni program, metode njihovega izvajanja in vrednotenja
Rezultate skupaj razvijata stranka in razvijalec ter jih je treba dogovoriti in odobriti. Vsebujejo pojasnila zahtev tehničnih specifikacij za določen sistem in morajo zagotoviti njihovo pravilno preverjanje. Sistemska dokumentacija bi morala
v celoti skladno s preizkušenimi programi, zagotavljanje prepoznavnosti sistema s strani serviserja ter zagotavljanje možnosti razvoja in posodabljanja programov za podaljšanje njihovega življenjskega cikla.
Testni program Je načrt za serijo eksperimentov. Razvit je z vidika čim manjše količine testiranja glede na zanesljivost pridobljenih rezultatov in dogovorjen s stranko. Za to se določi zaporedje in obseg vsakega preskušanja v postopku preskušanja, da se preveri izpolnjevanje zahtev tehnične naloge z minimalnimi stroški. Še posebej težko je izbrati nabor stresnih situacij v delovanju sistema, v katerem naj bi se izvajali testi. Testni program mora vsebovati naslednje jasno oblikovane razdelke:
1) testni objekt, njegov namen in seznam glavnih dokumentov, ki so določali njegov razvoj;
2) namen preskusov z navedbo osnovnih zahtev tehničnih specifikacij, ki jih je treba preveriti, in omejitev preskušanja;
3) pravzaprav testni program ki vsebuje preverjanje popolnosti razvitega sistema v skladu s projektnimi nalogami in testni načrt za preverjanje delovanja programov v vseh razdelkih nalog in dodatnih zahtev, formaliziranih z ločenimi rešitvami;
4) testnih postopkov, ki nedvoumno opredeljuje vse koncepte testiranih lastnosti, pogoje testiranja, sredstva, ki se uporabljajo za testiranje, metode obdelave in vrednotenja rezultatov testiranja za vsak odsek testnega programa.
Velika količina heterogenih testnih podatkov
programske opreme ter raznolikost možnih načinov njihove obdelave, interpretacije in vrednotenja vodi v dejstvo, da so najpomembnejši dejavniki za obdelavo rezultatov testov metode obdelave in vrednotenja rezultatov... V skladu s preskusnimi metodami morajo orodja za avtomatizacijo zagotavljati popolnost preverjanj delovanja za vsak odsek metod in razvoj
verifikacijskih protokolov po točkah testnega programa. Kompleksnost programske opreme in tesna povezava med njenimi različnimi značilnostmi vodita v potrebo po skrbni formulaciji vseh pogojev testiranja in vrednosti parametrov, pod katerimi je treba opraviti preverjanje.
Rezultati testov so zabeleženi v protokolih ki običajno vsebujejo naslednje razdelke:
1) namen preskušanja in del zahtev tehnične naloge, po katerem se preskus izvaja;
2) navedbo metod, v skladu s katerimi so bili opravljeni testi, obdelavo in vrednotenje rezultatov;
3) pogoji testiranja in značilnosti začetne
4) splošne rezultate preskusov z njihovo oceno skladnosti z zahtevami tehničnih specifikacij in drugih predpisov;
5) sklepi o rezultatih testov in stopnji skladnosti ustvarjene programske opreme s posebnim delom zahtev tehnične naloge.
Protokoli za celoten program so povzeti v aktu, ki ima za posledico
se sklepa o skladnosti sistema z zahtevami naročnika in o zaključku dela s pozitivnim ali negativnim rezultatom. Če so vse zahteve tehnične naloge v celoti izpolnjene, je naročnik dolžan sistem sprejeti in delo se šteje za opravljeno.
Vendar, kot je bilo že omenjeno, je za kompleksne programske pakete težko predvideti in pravilno oblikovati vse zahteve tehnične naloge v začetnih fazah načrtovanja. Zato se med odpravljanjem napak in testiranjem pogosto razkrije, da nekatere zahteve tehnične naloge niso izpolnjene in jih včasih celo v osnovi ni mogoče izpolniti z najbolj vestnim odnosom do tega s strani razvijalca. V tem primeru je treba pri zaključku testov in izdelavi sklepa sodelovati med stranko in razvijalcem pri iskanju kompromisne rešitve. Nekatere pomanjkljivosti programskega paketa se med postopkom testiranja le evidentirajo in evidentirajo v načrtu za odpravo pripomb komisije,
ki je opravil teste. Ta načrt je priloga k aktu o rezultatih testiranja in vam omogoča ločevanje kasnejših sprememb od neposrednih testov.
Postopek za izvedbo sprejemnih testov
Stranka je odgovorna za organizacijo in izvedbo prevzema v industrijsko obratovanje. Prevzem informacijskega sistema v industrijsko obratovanje se izvede po zaključku prevzema s strani naročnika vseh kompleksov nalog (podsistemov) za industrijsko obratovanje.
Naloge, kompleksi nalog (podsistemi) in tehnična sredstva informacijskega sistema, ki niso predvideni v opisu nalog, ampak jih naročnik izvaja samostojno, se lahko vključijo v kompleks informacijskega sistema, ki se preda samo po dogovoru z razvijalca in po ustreznih spremembah projektnega pooblastila za izdelavo informacijskega sistema.
Na zahtevo naročnika ali razvijalca se lahko v prevzem informacijskega sistema vključijo predstavniki podizvajalcev.
Stranka informacijski sistem predstavi sprejemni komisiji. Poleg članov komisije se lahko v sprejem s svetovalnim glasom vključijo strokovnjaki za določena vprašanja oblikovanja informacijskih sistemov. Naročnik je dolžan zagotoviti normalne delovne pogoje komisije v skladu s sprejetim prevzemnim programom informacijskega sistema. Za hitro reševanje organizacijskih vprašanj, ki nastanejo v postopku sprejemanja informacijskega sistema, se po odredbi vodje organizacije razvijalcev dodeli odgovorni predstavnik organizacije razvijalcev.
Naročnik skupaj z razvijalcem pripravi osnutek programa testiranja in prevzema informacijskega sistema ter ga posreduje sprejemni komisiji v obravnavo in potrditev. Program navaja: ime informacijskega sistema, ki se preda, dokumente direktive, na podlagi katerih je bil sistem razvit (če obstajajo), sestavo sprejemne komisije in številko odredbe o njegovem imenovanju, namen, cilje. , prostornina, lokacija in
zaporedje testov, preskusni postopek in ocena rezultatov.
Stranka pripravi skupaj z razvijalcem in komisiji prenese v začasno uporabo naslednje dokumente:
1) naročila, naročila, načrti, pogodbe, ki predvidevajo vzpostavitev informacijskega sistema;
2) tehnične in ekonomske utemeljitev, naloge, tehnična zasnova, delovna zasnova informacijskega sistema;
3) akti obravnave in odobritve tehničnega projekta;
4) dvostranski akti naročnika in razvijalca o dostavi nalog, kompleksov nalog (podsistemov), naprav in njihovih kompleksov za industrijsko obratovanje v skladu z odobrenim projektom.
Komisija za sprejem zagotavlja:
1) preverjanje dokumentacije in delovanja informacijskega sistema;
2) organizacija delovnih skupin in porazdelitev odgovornosti med člane komisije za preverjanje posameznih podsistemov;
3) preverjanje izračuna ekonomske učinkovitosti ustvarjenega informacijskega sistema;
4) organizacija delavnic in priprava prevzemnih potrdil za informacijski sistem.
Preverjanje pogojev delovanja in načina delovanja tehni
sredstva informacijskega sistema se izvaja hkrati s preverjanjem delovanja kompleksov (podsistemov) nalog. Pripravljenost osebja, odgovornega za delovanje informacijskega sistema, se ugotavlja v skladu s programom usposabljanja in opisom delovnih mest, ki so del delovnega projekta. Rezultati preverjanja so obravnavani na delavnicah in dokumentirani v minutah.
Končna faza dela komisije je priprava akta, ki navaja:
1) sestava komisije, delovna mesta in delovna mesta članov komisije;
2) rok (datum) prevzema sistema;
3) sestavo izvajalcev (organizacij, podjetij), ki so sodelovali pri oblikovanju informacijskega sistema;
4) razloge za prevzem (naročila, navodila in
5) seznam predložene dokumentacije informacijskega sistema
in oceno njegove skladnosti s trenutnimi regulativni in tehnični dokumenti;
6) skladnost dejansko izvedenih in izvedenih del s projektom;
7) pripravljenost vseh vrst podpore in strukturnih oddelkov naročnika za izvajanje in delovanje informacijskega sistema;
8) informacije o učinkovitosti informacijskega sistema (primerjava razpoložljivih ali pričakovanih dejanskih podatkov o obsegu in virih nastalih prihrankov z izračunanimi podatki);
9) sklepi komisije o možnosti prevzema informacijskega sistema;
Potrdilo o prevzemu v petih izvodih podpišejo predsednik in vsi člani komisije. Datum začetka delovanja informacijskega sistema je dan podpisa akta s strani komisije.
6. Ekipa razvijalcev informacijskih sistemov
Ker je ustvarjanje sodobnega informacijskega sistema kompleksen proces, ki zahteva skupna prizadevanja velikega števila različnih strokovnjakov, je v sodobnih razmerah zelo pomembno oblikovanje ekipe, ki se ukvarja z načrtovanjem, razvojem in implementacijo informacijskega sistema.
Organizacija ekipe in distribucija dela s strani strokovnjakov se lahko izvaja po več načelih:
1) na podlagi distribucije sistemske analize (algoritmizacije) in razvoja programov za različne ekipe;
Sistem upravljanja IT: tri komponente ...
V okviru te problematike pod sistemom upravljanja IT mislimo avtomatiziran sistem za vodenje dejavnosti IT oddelka, zgrajen na podlagi specializiranih pristopov, metodologij, standardov in programskih rešitev za IT industrijo. Konceptualna osnova za izgradnjo takšnega sistema je »servisni pristop«, to je organizacija vodenja IT storitve kot servisnega oddelka in usmeritev vsega kadrovskega dela v opravljanje storitev podjetju. Zato se tak sistem vodenja pogosto imenuje "sistem upravljanja IT storitev", njegova implementacija pa se imenuje "ITSM Solution Implementation" ali "ITSM Project".
Sistem upravljanja IT seveda ni omejen na orodja za avtomatizacijo. Končni rezultat projekta ITSM je delujoč sistem upravljanja IT na ključ. To je kombinacija treh komponent - "procesi", "ljudje", "orodja za avtomatizacijo". Ko govorimo o komercialni izvedbi oziroma izvajanju izvedbenih storitev, so vse te komponente praviloma vključene v pogodbo z izvajalcem (sistemski integrator, svetovalno podjetje) kot formalni predmeti dostave.
"Procesi" je tako imenovana procesna dokumentacija, to je celoten kompleks organizacijskih in upravnih dokumentov, ki opisujejo in vzpostavljajo pravila za delo osebja IT oddelka, področja odgovornosti in postopek interakcije. Konceptualna osnova sodobnega sistema upravljanja IT (poleg že omenjenega storitvenega pristopa) je vodenje procesov v kombinaciji z industrijskim modelom, opisanim v knjižnici ITIL. Konkreten ITSM projekt zajema enega ali več med seboj povezanih procesov, za katere je razvita procesna dokumentacija.
»Ljudje« so zaposleni v IT oddelku, ki sodelujejo v procesu implementacije in nato postanejo uporabniki sistema. So nosilci izkušenj in znanja o specifičnih tehnologijah in praksah organizacije ter pomembno ustvarjalno prispevajo k oblikovanju sistema.
»Orodja za avtomatizacijo« so nabor strojnih in programskih orodij, ki avtomatizirajo dejavnosti znotraj procesov. Samim programskim orodjem ne bomo posvečali posebne pozornosti, povejmo le, da je na sodobnem trgu predstavljenih veliko specializiranih panožno specifičnih programskih rešitev.
Za Jet Infosystems so vodilne rešitve (po abecednem vrstnem redu) linija izdelkov BMC Remedy ITSM Suite in HP Software Service Management Center. Tako je implementacija rešitve ITSM namenska sprememba treh komponent sistema upravljanja IT: regulativne dokumentacije, kadrovskih veščin in orodij za avtomatizacijo za omejeno število dejavnosti (procesov). Po temeljni odločitvi o potrebi po spremembi sistema upravljanja IT (zagon ITSM projekta) se začne faza načrtovanja. Tu se določijo ključni parametri projekta, izpostavijo njegovi sestavni deli (naloge), določi se zahtevana količina sredstev, določi zaporedje dela in določi proračun.
Na tej stopnji organizacija sprejme številne pomembne odločitve. Najprej: na kakšen način izvesti projekt, samostojno ali s pomočjo svetovalcev? Katero programsko opremo morate uporabiti? Za odgovor na ta vprašanja v pomoč organizaciji, obstaja zadostno število virov, vključno z raziskavami, ocenami in pregledi lastnikov takšnih sistemov. Pogosta orodja za iskanje najboljših rešitev so zahtevanje tehničnih in komercialnih predlogov vodilnih integratorjev, organizacija tehničnih predstavitev in demonstracij različnih ponudnikov ter zagon pilotnih projektov za primerjavo platform.
S skrbnim pristopom organizacij k načrtovanju v smislu izbire programske opreme in ekipe izvajalcev ostaja tehnološki vidik načrtovanja projektov v večini primerov v zakulisju: kaj bo vzeto za osnovo nastajajočega sistema, čemu obseg in kako bo ta podlaga spremenjena, da se doseže končni rezultat. Vprašanje izbire načina razvoja in izvedbe v fazi priprave projekta praviloma ni izrecno postavljeno, ta metoda je tako rekoč skrita znotraj podrobnih projektnih načrtov in ostaja v presoji izvajalca.
Po našem mnenju nezadostno jasna izbira razvojne metode pomeni velika tveganja nepopravljivih odstopanj od načrta (to je tistih, ki zahtevajo znatno preoblikovanje in razjasnitev komponent projekta). Odprta razprava in dogovor o pričakovanjih naročnika in izvajalca glede načina izvedbe bosta pripomogla k zmanjšanju vpliva tovrstnih tveganj.
Z vso raznolikostjo platform in bogastvom funkcionalnosti, ki je predstavljena na trgu za specializirano programsko opremo "industrijskega" razreda, ima organizacija na voljo le tri alternativne načine njihove uporabe za izgradnjo nadzornega sistema. Poimenujmo jih pogojno: »Rešitev proizvajalca«, »Najboljša praksa« in »Individualna rešitev«.
"Rešitev proizvajalca" - namestitev sistema avtomatizacije "iz škatle" in začetek dela po referenčnih tehnoloških shemah proizvajalca (z naknadno prilagoditvijo v procesu vzdrževanja). To je najhitrejši in najcenejši način, da svoje delo organizirate na nov način.
"Najboljša praksa" je namestitev standardne rešitve, ki jo je predhodno izdelal integrator na podlagi svojih izkušenj. To je najbolj zagotovljen način za resnično delujoč sistem.
"Individualna rešitev" - razvoj individualne rešitve, začenši s procesnim modelom in procesnimi predpisi ter konča s posebnostmi nastavitev uporabniškega vmesnika. Ta metoda je najboljši način za upoštevanje želja zaposlenih in obstoječega razvoja v organizaciji.
Ob izbiri rešitve proizvajalca organizacija prejme sistem avtomatizacije z vnaprej konfigurirano poslovno logiko in dokumentacijo, ki je vključena v standardni nabor licenc. Delo integratorja pri postavitvi takšne rešitve obsega namestitev in testiranje na naročnikovem strojnem kompleksu, vnos referenčnih podatkov o lokaciji storitvenih objektov, organizacijski strukturi, storitvah, uporabnikih. Integracija s poštnim sistemom se izvaja tudi za pošiljanje obvestil. To je običajno dovolj za začetek usposabljanja zaposlenih in upravljanja sistema vodenja.
"Best Practice" (avtorska rešitev podjetja integrator) zagotavlja vsaj priročen, ne preobremenjen uporabniški vmesnik in niz avtomatiziranih funkcij, ki zadostujejo za delo. Izvedba takšne rešitve poleg namestitve in izpolnjevanja referenčnih knjig vključuje tudi nekaj prilagoditev procesne dokumentacije in dopolnitev sistema avtomatizacije, predvsem s prilagajanjem, ne s programiranjem. Ključni predpogoji za uspešno izvedbo: pravilna ocena uporabnosti za določeno panogo in kupca, razpoložljivost enostavnega in lepega vmesnika, kakovostna dokumentacija in operativna zanesljivost.
Prvi dve možnosti ("rešitev prodajalca" in "najboljša praksa") imata veliko skupnega. To so že pripravljene rešitve, ki niso razvite v okviru projekta. Njihovo izvajanje se v bistvu začne z razporeditvijo in usposabljanjem. Izvedbeni načrti za tovrstne rešitve so razviti vnaprej, večkrat preizkušeni in se ne spreminjajo od projekta do projekta. Če je organizacija sledila eni od teh možnosti za posodobitev nadzornega sistema, so najbolj kritična vprašanja pri projektu vprašanja izbire pravega proizvajalca (platforme) in pravega integratorja.
Najmanj predvidljiva in zato bolj zanimiva za obravnavo z vidika udeležencev projekta je "Individualna rešitev", v okviru katere se najprej načrtuje in razvija sistem, značilen za določeno organizacijo. poteka. Izvedbeni projekti za posamezne rešitve se lahko bistveno razlikujejo po stroških in časovnem razporedu. Po naših izkušnjah je pri tem najpomembnejši način, kako je projekt organiziran.
Kot metodološka podlaga za načrtovanje in implementacijo posameznih rešitev so na splošno standardi projektnega vodenja, standardi in osnovni regulativni dokumenti za upravljanje življenjskega cikla programske opreme ter metodologije načrtovanja programske opreme znanih proizvajalcev (Microsoft, Oracle, HP, BMC, itd.) se uporabljajo. ). Na njihovi podlagi integratorsko podjetje oblikuje lasten profil standardov in metod, ki urejajo načrtovanje, razvoj, delovanje in razvoj informacijskega sistema. Vsi ti standardi in tehnike so prilagojeni in konkretizirani glede na določene razrede projektov, v našem primeru na ITSM projekte.
riž. 1. Zemljevid izdelka
Rezultat je niz specifičnih smernic, zahtev, lastnosti in kazalnikov kakovosti, ki označujejo način organizacije razvoja in implementacije sistema. Drugi del značilnosti posamezne rešitve - predvsem funkcionalne in tehnične - naročnik in izvajalec kreativno določata že v procesu razvoja.
Tako je tudi za posamezno rešitev v fazi projektiranja pomemben del projektnih rešitev vnaprej določen in poznan izvajalcu. Zato je smiselno, da se razprava o načinu razvoja izenači z vprašanji priprave projekta, kot sta izbira platforme (prodajalca) in izbira arhitekture.
V kakšnem zaporedju bodo doseženi rezultati projekta? Kako se bodo oblikovali in zbirali komentarji stranke? V kakšnem vrstnem redu in v kakšnem obsegu bodo pripombe sprejete in odpravljene? Lahko se zastavijo ta in druga vprašanja, ki označujejo način organizacije projekta, ki ga uporablja izvajalec
v fazi načrtovanja, tudi zato, da bi natančneje primerjali konkurenčne ponudbe in izbrali najboljšo.
Glavno vprašanje razvojne metode: kako pridemo do produktov projekta? Da bi to sami razumeli, o tem povedali stranki in, kar je najtežje, uresničili svoje načrte, uporabljamo kartice produktov projekta. Zemljevid izdelka je diagram vmesnih in končnih rezultatov oblikovalskega dela, ki določa, kaj in v kakšnem vrstnem redu bo izvedeno med projektom (glej). Metodološka osnova za izdelavo zemljevida izdelkov je metoda načrtovanja na podlagi izdelka iz Prince2, uporabljena za razvoj strukture razčlenitve dela.
Naše zemljevide so »obložene« po fazah projekta, na katere so produkti projekta aplicirani v obliki pravokotnikov. Pravokotniki so povezani s povezavami, povezave določajo, na podlagi katerih izdelkov se razvijejo naslednji izdelki. Tako zemljevid izdelka določa tehnologijo izdelave krmilnega sistema.
Vse izdelke lahko razdelimo v dve skupini. Prva skupina - "zunanja", ki so na voljo stranki. Drugi je »notranji«, ki je projektnemu timu nujen praviloma kot tehnološka komponenta, da dobi enega od »zunanjih« izdelkov.
Uporabljamo drugo klasifikacijo izdelkov: "obvezno" in "neobvezno". Izdelki, ki jih morate imeti, so izdelki, katerih razvoj je s tehnološkega vidika nujen (brez njih ni mogoče doseči končnega rezultata ITSM projekta). "Neobvezni" izdelki so izdelki, ki se jim lahko opustimo. "Neobvezni" izdelki so vključeni v kartico izdelka, običajno na željo stranke.
Sestava, zaporedje in razmerja izdelkov, ki sestavljajo glavno vrednost zemljevida, so določeni hevristično, težko si je predstavljati univerzalni algoritem za sestavljanje takšne karte. To je rezultat dolgoletnih izkušenj pri izvajanju, ogromnega števila napak, temeljnih ideoloških sporov, nenadnih odkritij, preizkušenj, ki so prestali preizkus časa in resničnih projektov.
Na podlagi zemljevida izdelkov lahko jasno pokažete glavne razlike in značilnosti obravnavane razvojne metode. Večino projektov, ki smo jih izvedli, lahko pripišemo enemu od dveh načinov organizacije dela. Pogojno jih poimenujmo "Klasični" in "Iterativni" in razmislimo o vsakem posebej.
Vsak primer izdelka v članku je opisan v skladu z naslednjim diagramom:
- Oblika;
- Imenovanje;
- Vsebina;
- Možnosti, priporočila.
Bistvo "klasične" metode izvajanja je postopen razvoj sistema, začenši s študijem predmetnega področja in konča z implementacijo sistema "na ključ" in nadaljnjo podporo. Izpostavljamo (in preslikavamo) naslednje faze projekta:
Pri »klasičnem« načinu izvajanja so faze zelo pomembne, saj rezultati, dobljeni na koncu faze (projektni produkti), predstavljajo osnovo za naslednjo stopnjo, njihova revizija pa je skoraj nemogoča brez sprememb v projekt. Razmislimo o glavnih produktih projekta na vsaki stopnji.
Cilja stopnje anketiranja sta dva: pridobiti predstavo o trenutni praksi na predmetnem področju in razjasniti izjavo problema. Glavni rezultat te faze je poročilo o anketi. Če sledite zemljevidu, je prvi produkt faze "Struktura objekta upravljanja" (imenovan tudi "Anketni model"). Ne izda se kupcu, je "interni" izdelek. V njem je po isti shemi "ljudje - procesi - orodja za avtomatizacijo" zabeleženo: kaj je treba raziskati v okviru raziskave, katere dokumente pridobiti in preučiti, s katerimi ljudmi opraviti razgovore, katera orodja za avtomatizacijo so uporabljena s strani stranke upoštevati.
Poročilo o anketi
Oblika
Besedilni dokument (večinoma), predstavitev.
Imenovanje
Anketno poročilo je najbolj zanimiv in zanimiv projektni dokument za branje. Na začetku projekta je poročilo uporabno za ustvarjanje ozračja medsebojnega razumevanja v skupni projektni skupini "Naročnik - Izvajalec": svetovalci izkazujejo razumevanje posebnosti in prednostnih nalog organizacije, predstavniki strank pa sprejemajo in soglašajo z uporabo izrazi in orodja projektov ITSM, na primer "struktura vlog procesa" in "stopnja zrelosti".
Druga življenjska doba "Poročila" se začne ob koncu projekta, ko je treba prikazati učinek uvedbe novega sistema (bil je - bil). Kasneje, po začetku delovanja krmilnega sistema, postane nepotreben in se praktično ne uporablja.
Glede na razvito
Svetovalci sestavijo poročilo na podlagi svojih zapiskov med razgovorom, pa tudi na podlagi zbranih dokumentov organizacije: predpisov, navodil itd. Natančnost in kakovost sta sorazmerni s kvalifikacijami svetovalcev in njihovim številom na razgovoru (en svetovalec je slab). Če je bila anketa izvedena med anketiranjem (kar se ne zgodi vsakič), se rezultati obdelajo in vključijo v poročilo v agregirani obliki.
Tipično poročilo je običajno razdeljeno na tri glavne bloke: splošne informacije, opis trenutnega stanja, zaključke.
Splošni podatki so navedeni cilji raziskave, meje raziskave (organizacijske in funkcionalne), seznam uporabljenih dokumentov in anketiranih oseb. Opisuje tudi metodologijo raziskovanja, vključno z metodami zbiranja informacij, metodami združevanja in posploševanja, metodami in merili vrednotenja.
Opis trenutnega stanja je strukturirana predstavitev trenutne prakse "kot je", včasih z uporabo grafičnih diagramov in slik. Za vsa raziskovana področja dejavnosti organizacije se uporablja enotna opisna struktura. Na primer, to:
- Organizacijska in vloga struktura;
- Procesne dejavnosti;
- Podpora dokumentaciji;
- informacijska podpora;
- Orodja za avtomatizacijo.
Pogosto bo razdelek vseboval zahteve vodstva in predloge za izboljšave, zbrane med raziskavo, čim bolj nespremenjene.
V rubriki Sklepi so rezultati analize trenutnega stanja. Skoraj vedno so to rezultati ocenjevanja stopnje zrelosti procesov ter ugotovljenih ozkih grl in s tem povezanih tveganj.
Po razdelku »Sklepi« se zdi logično, da obstaja nekaj priporočil, vendar lahko v okviru tekočega projekta ITSM prihranite pri tem: projekt se začne, proračun je odobren, zahteve so oblikovane - čas je začeti z oblikovanjem.
Naročnikovo projektno ekipo pogosto zanima vsebina intervjujev, ki jih opravijo svetovalci z vodilnimi IT in predstavniki podjetij. Za zadovoljitev takšnega interesa je priporočljivo, da se z vodstvom vnaprej dogovorite za objavo obravnavanih tem v poročilu ali prisotnost vodje naročnikove projektne skupine na razgovoru.
Na njegovi podlagi se razvije vmesni produkt "Načrt ankete", izpeljanka iz njega pa je "zunanji" produkt "Urnik ankete". Izdelek "Urnik ankete" se šteje za pripravljenega, ko je dogovorjen s stranko. V tem trenutku imamo jasno predstavo, kako bo pregled potekal. Poleg načrta ankete je »notranji« izdelek nabor materialov, ki sestavljajo rezultate ankete – vse, kar je zbrano v anketi. Nato se izdela "poročilo o anketi" - glavni rezultat faze. Iz njega je mogoče izpeljati »izbirni« izdelek »Predstavitev rezultatov ankete«.
Namen faze načrtovanja je predlagati in z naročnikom dogovoriti organizacijske in tehnične rešitve, ki bodo osnova izdelanega sistema upravljanja IT. Glavni rezultati faze - "Model sistema upravljanja IT" in podrobno "Opisi (predpisi) procesov".
Procesni model
Oblika
Besedilni dokument, predstavitev (večinoma).
Imenovanje
Procesni model je skupek ključnih značilnosti ustvarjenega krmilnega sistema. To so najdražji elementi načrtovanja prihodnjega sistema, za katere se je treba odločiti zgodaj v projektu, da se izognemo večjim predelavam. Procesni model je kompakten, vsebuje samo tisto, kar je pomembno, priročno za razpravo in dogovor.
Glede na razvito
Začetne omejitve pri razvoju procesnega modela so opredelitev projekta v organizaciji in pripadajoča določila pogodbe z izvajalcem. Praviloma je sestava procesov - podsistemov prihodnjega nadzornega sistema - vnaprej določena. Cilji projekta so znani in odobreni, na primer »Izvedba v oddelku IT procesnega pristopa, usmerjenega na poslovne potrebe. Implementacija elementov svetovne "najboljše prakse" upravljanja IT".
Zunanji viri, uporabljeni pri razvoju modela, so sprejeti standardi, »najboljše prakse« in tudi prejšnje izkušnje članov ekipe.
Glavni vir razvoja projekta je anketno poročilo oziroma opis trenutne prakse in ozkih grl v njej. Novi model bi moral ohraniti dobre prakse upravljanja in odpraviti pomanjkljivosti.
Pri opisu procesnega modela se je smiselno opreti na široko razširjeno delitev sistema na tri sestavne dele – »procese«, »ljudje«, »orodja za avtomatizacijo«.
Za vsak proces praviloma model zajema naslednje elemente odločanja:
- Pogoji in definicije;
- Profil uporabljenih standardov in praks upravljanja;
- Ciljna stopnja zrelosti in njene značilnosti;
- Cilji procesa;
- Vhodi in izhodi (rezultati) procesa;
- Informacijski objekti;
- Dejavnosti, splošna shema procesa.
Nabor drugih ključnih značilnosti (z drugimi besedami - "politike"), vključenih v model, je specifičen za vsak proces. Za upravljanje incidentov je to lahko število podpornih linij, organizacija službe za pomoč uporabnikom (centralizirana ali porazdeljena, reševanje ali beleženje), podprte metode za vzpostavitev stika s službo za pomoč uporabnikom.
Glede na strukturo vlog sistema ("ljudje") model opredeljuje sestavo in odgovornost vlog za vrste dejavnosti procesov. Za vsako vlogo je treba oceniti možnost dodelitve ali najema osebja. Če je treba spremeniti organizacijsko strukturo, je treba to jasno navesti.
Kar zadeva orodja za avtomatizacijo, če do tega trenutka še niso bila izbrana in kupljena, potem model procesa vključuje seznam programskih orodij, načrtovanih za uporabo, in določa potrebo in metode integracije s povezanimi sistemi (viri podatkov o zaposlenih, inventar sistemi, poštni program itd.) itd.).Da se model procesa ne spremeni v marketinško gradivo ali recimo samoporočilo projektne ekipe (pri čemer bi rad prihranil), je priporočljivo, da vanj vključimo tiste sistemske elemente, za katere so bile obravnavane alternativne možnosti oblikovanja. .
Model je osrednji produkt odra. Razvoj in potrditev modela poteka v več ponovitvah z vključevanjem najširše možne delovne skupine naročnika. Napake, nastale med razvojem modela, se bodo zagotovo občutile v naslednjih fazah projekta. Cena izdaje: vsaj pomembna obdelava že pridobljenih rezultatov in nezadovoljstvo stranke. Na podlagi dogovorjenega modela se razvijejo »Procesni diagrami« kot vmesni korak pri razvoju »Opisov (predpisov) procesov«.
Procesni predpisi
Oblika
Besedilni dokument, ki vsebuje grafične diagrame.
Imenovanje
Po branju predpisov bi morali udeleženci procesa in deležniki (na primer revizorji) dobiti predstavo o naslednjih stvareh: za kakšen namen in katera dejanja se izvajajo v procesu (brez podrobnega opisa, kako natančno) in kdo je odgovoren za kaj.
Glede na razvito
Polizdelek za razvoj predpisov je procesni model. Predhodno dogovorjene vrste aktivnosti so razdeljene na postopke, določijo se udeleženci v postopkih in odgovorni. Opisani so sami postopki, pogojni in brezpogojni prehodi med njimi, podrobneje - na točkah prenosa nadzora.
Uredba je skladen formalni opis dejavnosti procesa z navedbo odgovornega. Tukaj je primer strukture uredbe (vzemimo upravljanje incidentov):
- Pogoji in definicije;
- Splošne določbe:
- Cilji in cilji procesa;
- Prednosti procesa;
- Obseg in meje procesa;
- Vložki v proces upravljanja incidentov;
- Izstopi iz procesa upravljanja incidentov;
- Splošna shema in opis postopka;
- Procesna orodja;
- Vloge in odgovornosti udeležencev v procesu:
- Funkcionalne vloge;
- Matrika odgovornosti;
- Procesni predpisi:
- Sprejem in registracija;
- Klasifikacija in primarna podpora;
- Imenovanje;
- Dovoljenje, izvedba;
- Zapiranje;
- lastništvo;
- Meritve procesa:
- Komponente in poročila, ki jih zagotavlja proces;
- Dodatek A – Pravila razvrščanja;
- Priloga B - Pravila za določanje prioritet;
- Dodatek B – Pravila eskalacije.
Za namen uporabe predpisov, torej prebranih do konca, je priporočljivo, da se vse moteče podrobnosti, ki kršijo logično skladen opis, vključijo v priloge ali druge dokumente (specifikacije in navodila).
Namen razvojne faze je izdelava orodij za avtomatizacijo in razvoj procesne dokumentacije.
Na podlagi "Opisov (predpisov) procesov" se razvijejo "Specifikacije procesov". Za vsak nadzorni proces znotraj sistema se razvijejo tri specifikacije: specifikacija delovnega toka, specifikacija meritev in specifikacija integracije. Na njihovi podlagi se razvijejo "Scenariji testiranja CA".
Specifikacija postopka
Oblika
Besedilni dokument.
Imenovanje
Specifikacija postopka podrobno opisuje predpise. Če pravilnik določa, kaj in v kakšnem zaporedju se izvaja v procesu, potem specifikacija odgovarja na vprašanje: kako natančno in s kakšnimi rezultati se postopki izvajajo. Kot projektni dokument specifikacija vsebuje osnovne funkcionalne zahteve za razvoj avtomatiziranega sistema. V prihodnosti se uporablja kot osnova za pripravo testnih scenarijev in delovnih navodil za udeležence procesa.
Glede na razvito
Specifikacija je izdelana na podlagi predpisov in podrobno opisuje njene postopke ob upoštevanju omejitev in zmožnosti izbranih orodij za avtomatizacijo.
V specifikaciji so procesni postopki razdeljeni na zaporedje korakov – elementarne operacije udeležencev procesa (uporabnikov sistema). Struktura opisa postopka je približno naslednja:
- Opis postopka:
- Številka (identifikator) postopka;
- Ime postopka;
- Opis postopka (iz pravilnika);
- Odgovoren izvajalec (vloga);
- Vstop v postopek (dogodek, ki aktivira postopek);
- Operacije.
Za vsako operacijo je navedeno:
- številka operacije;
- Ime operacije;
- Izvedena dejanja;
- Rezultat operacije.
Po uvedbi sistema vodenja v obratovanje je zaradi znižanja stroškov vzdrževanja priporočljivo narediti spremembe najprej v uredbi in specifikaciji, nato pa "izrezati" iz specifikacijskih navodil in scenarijev.
Hkrati potekajo dela pri izdelavi orodij za avtomatizacijo: ustvari se vmesni izdelek "Osnovno stojalo CA (sistemi avtomatizacije)", nato "Delovno stojalo CA" - s postavitvijo osnovnega stojala po specifikacijah. "Zunanji" izdelek "Eksperimentalno CA stojalo" je pridobljen na podlagi "CA testne mize" in nabora "CA testnih scenarijev": s prizadevanji ekipe preizkuševalcev in inženirjev je sistem avtomatizacije pripravljen za predstavitev stranki, usposabljanje in poskusno delovanje.
Na podlagi specifikacij in "CA Test Stand" se razvija nabor izdelkov "CA User Instructions". Nastali "zunanji" produkt odra je "Demonstracija CA" strankini projektni skupini.
Izbirni "zunanji" izdelki na tej stopnji so lahko: "Pogoji poslovanja" (na podlagi specifikacij), "Metodologija testiranja" (na podlagi "testnih scenarijev"), "Opis kazalnika" (na podlagi niza "Specifikacije meritev" ”).
Namen faze uvajanja je pripraviti nadzorovani objekt za pilotno ali pilotno industrijsko uporabo sistema avtomatizacije.
Pilotni (pilotni) načrt delovanja
Oblika
Besedilni dokument, načrt v MS Project.
Imenovanje
Dokument služi kot orodje za načrtovanje in organizacijo skupnih akcij udeležencev za zagotavljanje doseganja ciljev poskusnega delovanja v določenem obdobju (praviloma od dveh tednov do enega meseca in pol).
Glede na razvito
Načrt obsega dva velika dela: pravilnik o poskusnem obratovanju in sam načrt.
Pravilnik o poskusnem delovanju odgovarja na naslednja vprašanja:
- Kakšni so cilji, ki jih je treba doseči?
- Kakšni so pogoji poskusnega delovanja?
- Kateri oddelki in zaposleni so vključeni?
- Kakšne vloge so jim dodeljene v procesih?
- Katera učna gradiva so na voljo udeležencem in kje so objavljena?
- Na koga in na katera vprašanja se obrniti, v kakšnem časovnem okviru in kako?
- V kakšnem načinu se uporabljajo »stari« sistemi in tehnologije?
- Ali bo med poskusnim delovanjem prišlo do sprememb v sistemu?
Načrt poskusnega delovanja vključuje seznam faz in nalog z navedbo odgovornih, trajanja in terminov za posamezen dogodek. Primeri takšnih dejavnosti so lahko »zagon in testiranje sprejemanja zahtev uporabnikov s pomočjo spletnega vmesnika«, »izvajanje revizije konfiguracije«.
Rezultati te faze so večinoma "zunanji" - vidni stranki. Če sledite znani strukturi »ljudi«, »procesi« in »orodja za avtomatizacijo«, so to naslednji izdelki: »Usposobljeno osebje«, »Organizacijske aktivnosti« (za zagon in začetek delovanja sistema upravljanja IT) in »Avtomatizacija orodja", nameščena na strankinem mestu. Za pridobitev teh rezultatov se razvijejo "Načrt usposabljanja", "Načrt za uvajanje CA", "Načrt za izdajo naročil in naročil" ob začetku pilotne operacije in se dogovorijo z naročnikom. Vzporedno se v interesu naslednje faze razvija "zunanji" izdelek "Pilotni operativni načrt".
Namen faze pilotnega delovanja je preizkusiti sistem upravljanja IT v proizvodnem okolju na lokaciji naročnika. Na podlagi "Pilotnega operativnega načrta" se med etapo oblikuje "notranji" produkt "Rezultati pilotnega obratovanja", na podlagi katerega sta "zunanja" produkta "Poročilo o poskusnem industrijskem obratovanju" in "Protokol komentarjev" in izboljšave" bodo pripravljene. »Neobvezni zunanji« produkt etape je lahko »Predstavitev rezultatov pilotne operacije«.
Osrednji dogodek faze zagona industrijskega delovanja je začetek uporabe sistema upravljanja IT v industrijskem načinu. Za to je treba odpraviti pripombe, oblikovane v fazi pilotnega delovanja. Na podlagi "Experimental CA stand" in "Zapisnika pripomb in sprememb" se razvija "zunanji" izdelek "Industrial CA stand". Nastala faza in projekt kot celota je »zunanji« produkt »Predstavitev rezultatov projekta«.
Z vidika načrtovanja in organizacije dela je tehnična podpora in vzdrževanje sistema upravljanja IT bolj procesna kot projektna in je zgrajena po različnih pravilih. Zato se na našem zemljevidu produkti projekta, povezani s podpornimi in vzdrževalnimi dejavnostmi, ne odražajo.
Tako smo s pomočjo produktne karte preučili tehnologijo za izvedbo razvojnega projekta in izvedbo »individualne rešitve« za sistem upravljanja IT po »klasični« shemi. Treba je opozoriti, da je bila zaradi poenostavitve sestava projektnih izdelkov poenostavljena. V dejanskih zemljevidih, ki jih uporabljamo, je lahko za en projektni produkt na voljo več vmesnih izdelkov. Na primer, "Izdelek" postane najprej "Osnutek izdelka", nato po internem sprejetju "Projektni izdelek" in šele po dogovoru s stranko - dejanski "Izdelek". Z drugimi besedami, zemljevid lahko prikazuje ne le izdelke in njihove odnose, temveč tudi življenjske cikle posameznih izdelkov.
Ko dokončate ta zemljevid izdelka, lahko nadaljujete s pripravo načrta projekta, na primer z uporabo Microsoft Projecta. Projektni produkti v načrtu bodo predstavljeni v obliki mejnikov, ki jih je treba s projektiranjem podrobneje opredeliti. To zahteva, da je vsak niz vhodnih povezav izdelkov oblikovan v obliki nalog za izdelavo izdelka, ki temelji na prejšnjih. Po oceni trajanja nastalih projektnih nalog dobimo osnovni projektni načrt.
"Klasični" način izvajanja je najbolj razširjen na trgu svetovalnih storitev, je zelo priljubljen in časovno preizkušen. Kljub temu ima eno pomanjkljivost oziroma lastnost, ki v današnjih razmerah postaja vse bolj pomembna tako za naročnika kot za izvajalca. Gre za trajanje. Projekti implementacije sistemov vodenja na "klasični" način se redko izvajajo v manj kot treh mesecih. Nasprotno, ni nenavadno, da takšni projekti trajajo več kot eno leto. V tem času se lahko spremenijo zunanji pogoji, v katerih podjetje deluje,
pa tudi načrti, poslovne prioritete. Zamisel vodij IT storitev o tem, kako naj bi sistem upravljanja deloval, se preoblikuje. Vsi ti dejavniki, pa tudi napake pri načrtovanju, se kopičijo in vodijo v to, da se v srednji in poznejši fazi projekta povečuje želja po zmanjšanju zaostankov na račun bodisi kakovosti bodisi količine produktov projekta.
Metoda "iterativnega" izvajanja bistveno zmanjša vpliv teh tveganj. Namenjen je predvsem možnosti prilagajanja napredka izvajanja, pri čemer se ob vsaki ponovitvi predlaga revizija nadaljnjih načrtov.
Očitno se rezultat "iterativnega projekta" za formalne objekte dostave ne bi smel razlikovati od "klasičnega projekta". Tu je splošen diagram formalnega niza predmetov dostave:
Vse te izdelke je treba pridobiti v »iterativnem projektu«, tako kot jih dobimo v »klasičnem projektu«.
Iteracija vključuje ponavljanje. V našem primeru se bodo ponovile naslednje skupine nalog:
Očitno "sprejemanje izdaje" tako v mini razvojnem ciklu kot v ciklu glavne ponovitve vodi bodisi do prehoda na novo ponovitev bodisi do ponovitve (do neke mere) trenutne, da bi odpravili pomanjkljivosti. .
Torej, opisali smo, kaj je treba pridobiti (projektni izdelki) in na kakšen način bomo to naredili (cikel ene iteracije). Ostaja še pokazati, koliko ponovitev bo izdelek razvit, in malo podrobno opisati delo znotraj vsake ponovitve. Verjamemo, da bo optimalno število ponovitev tri, četrto in naslednje je mogoče izvesti v okviru tehnične podpore in vzdrževanja sistema upravljanja IT. Tako kot pri »klasičnem« načinu razvoja, razmislimo o logiki pridobivanja glavnih produktov projekta v okviru treh iteracij projekta.
Skupina projektnih nalog "Raziskave" v okviru prve iteracije vključuje veliko dela, ki se v "klasičnem" razvoju izvaja v fazah pregleda in projektiranja:
Naloge, vključene v skupino "Razvoj", se izvajajo za pridobitev prototipa sistema, pripravljenega za predstavitev stranki.
Prvo ponovitev razvoja zaključi skupina projektnih nalog "Sprejem", ki bo vključevala naslednja dela:
Tako pod vnaprej dogovorjenimi pogoji in omejitvami dobimo nekoliko popolno, delujočo rešitev (pilot release), ki vključuje naslednje izdelke:
Skupina projektnih nalog "Raziskave" v drugi iteraciji ima bistveno manjši obseg kot pri pilotni izdaji in vključuje eno nalogo:
Skupina projektnih nalog "Določanje meja sprostitve" je sestavljena iz naslednjih del:
Nastali produkti ponovitve 2 so:
Za pridobitev industrijske izdaje je skupina projektnih nalog "Raziskave" namenjena širjenju kroga udeležencev za globljo in kakovostnejšo potrditev rešitve v pogojih, ki so čim bolj podobni resničnim.
Poročilo o poskusnem (pilotnem) obratovanju
Oblika
Besedilni dokument.
Imenovanje
Dokument določa rezultate ocenjevanja dela udeležencev v poskusnem delovanju z vidika ciljev te faze projekta ter prikazuje tudi trenutno stanje nadzornega sistema, njegovo pripravljenost za industrijsko uporabo in navodila za izboljšava.
Glede na razvito
Poročilo služi za primerjavo načrtovanih kazalnikov z dejanskimi, zato sta pri razvoju uporabljeni dve skupini virov informacij. Kot podlago za oceno se upošteva načrt poskusnega obratovanja in metodološka gradiva za udeležence v procesih (predpisi, navodila ipd.), dejanske podatke pa oblikujejo udeleženci poskusnega obratovanja v procesu dela in jih analizirajo svetovalci. med revizijo sistema.
Tipično poročilo vsebuje tri dele: splošne informacije, vrednotenje izvajanja načrta poskusnega delovanja, vrednotenje aktivnosti v okviru reorganiziranih procesov.
Splošne informacije so najprej viri podatkov in merila vrednotenja, ki se uporabljajo za izdelavo poročila. Zaželeno je, da izbrani kriteriji zajemajo tako kontrolo procesov kot izvajanje postopkov procesov in rezultate izvedbe načrta poskusnega obratovanja.
Vrednotenje izvajanja načrta poskusnega obratovanja se izvaja za vsako postavko načrta. V primeru popolne ali delne neizpolnitve se navedejo razlogi. Razdelek lahko vsebuje nekatere pomembne kvantitativne in kvalitativne značilnosti rezultatov, na primer število napak in pripomb.
Ocenjevanje aktivnosti v okviru procesov se izvaja po razvitih kriterijih z oblikovanjem posplošene ocene uspešnosti zagona posameznega procesa in sistema vodenja kot celote. V tem primeru se lahko uporabijo orodja za merjenje in poročanje, ki so del implementiranega sistema. Koristen del tega dela poročila je opis ugotovljenih pomanjkljivosti, s tem povezanih tveganj ter priporočila za ublažitev njihovega vpliva.
Pri uvajanju kompleksnega, funkcionalno bogatega sistema na velikem območju (na primer, ko delovanje ni eksperimentalno, ampak pilotno-industrijsko) je koristno pripraviti kratko vmesno poročilo en do dva tedna po zagonu.
Skupina bo vključevala naslednja dela:
Skupina projektnih nalog "Razvoj" po svoji vsebini ponavlja tudi prejšnjo ponovitev. Iteracija se zaključi s skupino projektnih nalog "Sprejem", ki bo vključevala naslednja dela:
Torej so produkti ponovitve 3:
Na ta način iterativni pristop izvajanja zagotavlja, da so vsi ključni produkti projekta na mestu, kar ustvarja dodano vrednost v obliki zmožnosti nenehnega pregleda napredka projekta. Značilnost iterativne metode je, da ima stranka kot rezultat vsake ponovitve celoten nabor dokumentov, orodij za avtomatizacijo in osebja. S takšnim naborom ima organizacija možnost nadaljevati razvoj sistema upravljanja IT ob upoštevanju novih okoliščin in v novih razmerah, vse do opustitve storitev tretjega ponudnika.
V članku smo govorili o več alternativnih možnostih za implementacijo avtomatiziranega sistema za vodenje dejavnosti IT oddelka. To so »proizvajalčeva rešitev«, »najboljša praksa« in »rešitev po meri«, ki jih je mogoče razviti tako na »klasičen« kot »iterativni« način.
Obravnavane možnosti se ne razlikujejo le po kakovostnih značilnostih. Med osnovno postavitvijo sistema avtomatizacije "out of the box" in implementacijo večkrat potrjene "individualne" rešitve je bistvena razlika v terminih in stroških projekta za naročnika.
Nobenega dvoma ni, da se dodatni čas in sredstva, ki jih organizacija porabi za analizo in izbiro načina izvajanja v fazi priprave projekta, poplačajo s natančnejšim "zadetom" rezultatov projekta v načrtovani proračun in pričakovanja deležnikov. .
Uspešnih projektov vam!
NAROČIO RAZVOJU, DOGOVORU IN ODOBRITVI V JSC "RZD" NAVODIL O VRSTITU STORITVE IN O ORGANIZACIJI PROMETA NA ŽELEZNIŠKI CESTI JAVNE RABE, TUDI V OBJEKTIH VOZIL
Za izboljšanje enotnega postopka za pripravo, soglasje in odobritev navodil o postopku vzdrževanja in organiziranja prometa na železniškem tiru, ki ni javni, je železniški tir v pristojnosti funkcionalne podružnice ali strukturne enote Ruskih železnic in ne - javni železniški tir:
1. Za odobritev in uveljavitev priloženega:
1.1. Postopek za razvoj, usklajevanje in odobritev navodil JSC Ruske železnice o postopku servisiranja in organiziranja prometa na nejavnem železniškem tiru, pa tudi na železniškem tiru v pristojnosti funkcionalne podružnice ali strukturne enote Ruskih železnic (v nadaljevanju postopek).
1.2. Navodila o postopku za vzdrževanje in organiziranje prometa na nejavnem železniškem tiru v lasti Ruskih železnic, pa tudi železniškem tiru, ki ga upravlja funkcionalna podružnica ali strukturna enota Ruskih železnic (v nadaljnjem besedilu: Navodilo).
2. Vodje funkcionalnih podružnic in strukturnih oddelkov Ruskih železnic seznanijo s postopkom in navodili vpletene zaposlene, lastnike in uporabnike nejavnih železniških tirov, tirov, ki jih upravljajo funkcionalne podružnice ali strukturne enote Ruskih železnic, in zagotoviti skladnost z uveljavljenim postopkom.
3. Razglasiti za neveljavno odredbo JSC "Ruske železnice" z dne 2. avgusta 2011 N 1686r "O razvoju, odobritvi in odobritvi s strani JSC" Ruske železnice "navodil o postopku za servisiranje in organizacijo prometa na nejavni železnici. skladba".
4. Nadzor nad izvajanjem tega ukaza se zaupa podpredsedniku - vodji direkcije za vleko A. Vorotilkinu, vodji Centralnega direktorata za nadzor prometa P. Ivanovu, vodji Centralnega direktorata za infrastrukturo VN Suprunu, vodji Centralni direktorat tirnih vozil za motorna vozila Sizov S.V., vodja Centralnega direktorata za popravilo tirov I. Ya Pimenov, vodja Direktorata za popravilo vlečnih tirnih vozil A.P. Akulova. v skladu s funkcionalno pristojnostjo vprašanj.
Višji podpredsednik Ruskih železnic
A. A. Krasnoshchek
preklicano / razveljavljeno Izdaja iz 18.02.1991
"LISTINA AVTOMOBILNEGA PROMETA RSFSR" (s spremembami dne 18.02.91)
Avtoceste in dostopne ceste
16. Avtoceste splošne rabe, ki se nahajajo na ozemlju RSFSR, so razdeljene na ceste državnega, republiškega in lokalnega pomena. Regionalne ceste se razlikujejo od lokalnih cest.
Avtoceste državnega in republiškega pomena so v pristojnosti Ministrstva za gradnjo in delovanje avtocest RSFSR.
Avtoceste republiškega pomena prenese Ministrstvo za avtomobilski promet in avtoceste RSFSR v stalno službo cestnim organom ustreznih svetov ministrov avtonomnih republik in izvršnih odborov regionalnih (teritorialnih) svetov ljudskih poslancev.
Avtoceste lokalnega pomena so v pristojnosti Ministrstva za avtomobilski promet in avtoceste RSFSR in Svetov ministrov avtonomnih republik, izvršnih odborov regijskih (teritorialnih) svetov ljudskih poslancev.
Avtoceste v mestih in delavskih naseljih so v pristojnosti ustreznih izvršnih odborov sovjetov ljudskih poslancev.
od 28.11.69 N 648, od 16.05.80 N 253)
17. Ministrstvo za ceste RSFSR, sveti ministrov avtonomnih republik, izvršni odbori sovjetov ljudskih poslancev, pa tudi kolektivne kmetije, državne kmetije in druga podjetja in organizacije so dolžni vzdrževati avtoceste, prometne znake, smerne table in druga tehnična sredstva za urejanje prometa v stanju, ki ga nadzorujejo, zagotavljajo nemoteno in varno gibanje avtomobilov ter sprejemajo potrebne ukrepe za izboljšanje prometa na teh cestah.
(spremembe s sklepi Sveta ministrov RSFSR z dne 28. 11. 69 N 648 z dne 16. 5. 80 N 253)
18. Avtoprometna podjetja in organizacije ter druga podjetja, organizacije in ustanove, ki imajo avtomobile, so pri prevozu blaga, potnikov, prtljage in pošte po avtocestah dolžni zagotoviti prometno varnost in varnost v cestnem prometu.
Na avtocestah je prepovedano:
a) prehod vozil, katerih skupna višina s tovorom presega mere, navedene na prometnih znakih;
b) prevoz blaga, ki štrli v širino preko mer vozil, določenih z državnim standardom ali tehničnimi specifikacijami, ter blaga, ki štrli več kot 2 metra nad prtljažnimi vrati ali se vleče po cesti;
c) prehod vseh vrst vozil z osnimi obremenitvami, ki presegajo norme, določene z državnimi standardi ali označene na prometnih znakih.
Prevoz prevelikega tovora se v nekaterih primerih lahko izvaja z dovoljenjem cestnih organov in organov Državnega avtomobilskega inšpektorata na način, predpisan s Pravilnikom.
19. Ministrstvo za avtomobilski promet RSFSR in Ministrstvo za avtomobilske ceste RSFSR zagotavljata tehnično pomoč tirnim voznim parkom na cestah, ne glede na njihovo pripadnost, s plačilom stroškov opravljenih storitev po tarifah.
Na avtocestah državnega pomena je tehnična pomoč železniškim voznim parkom na poti organizirana s pomočjo organizacij za vzdrževanje cest Ministrstva za avtoceste RSFSR. Na istih cestah tehnično pomoč tirnim voznim parkom zagotavljajo avtomobilski bencinski servisi in podjetja za motorni promet Ministrstva za avtomobilski promet RSFSR na njihovi lokaciji.
Seznam cest, na katerih je organizirana tehnična pomoč, odobri Ministrstvo za avtomobilski promet RSFSR skupaj z Ministrstvom za avtoceste RSFSR in je objavljen v Zbirki pravil za promet in tarif za avtomobilski promet RSFSR.
Postopek organizacije tehnične pomoči tirnim voznim parkom na avtocestah je določen s Pravilnikom o organizaciji tehnične pomoči tirnim voznim parkom na avtocestah v RSFSR, ki ga odobri Ministrstvo za avtomobilski promet RSFSR skupaj z Ministrstvom za avtoceste RSFSR. .
(spremembe s sklepi Sveta ministrov RSFSR z dne 28. 11. 69 N 648 z dne 16. 5. 80 N 253)
20. Začasna prekinitev ali omejitev prevoza blaga, potnikov, prtljage in pošte po cestah v RSFSR se lahko izvede le v primeru naravnih pojavov ali zaradi cestnih in podnebnih razmer.
Odločbe o prenehanju ali omejitvi prevoza blaga, potnikov, prtljage in pošte z navedbo roka veljavnosti prenehanja oziroma omejitve prevoza po avtocestah državnega pomena sprejema Ministrstvo za gradbeništvo in obratovanje avtocest Republike Slovenije. RSFSR, na drugih javnih cestah - s strani svetov ministrov avtonomnih republik ali izvršnih odborov regionalnih (regionalnih) svetov ljudskih poslancev.
O začasna ustavitev ali omejitev prometa na avtocestah državnega pomena.
V nujnih primerih lahko organi Državnega avtomobilskega inšpektorata prepovejo ali omejijo gibanje vozil, ki opravljajo prevoz, na določenih odsekih ulic in cest, če njihova uporaba ogroža prometno varnost.
(spremembe s sklepi Sveta ministrov RSFSR z dne 28. 11. 69 N 648 z dne 16. 5. 80 N 253)
21. Pošiljatelji in prejemniki so dolžni imeti dostopne ceste od avtocest do nakladalnih in razkladalnih mest in te tire vzdrževati v dobrem stanju ter zagotavljati nemoteno in varno gibanje vozil ter njihovo prosto manevriranje v vsakem trenutku prevoza.
22. Skladnost stanja avtocest in dostopnih cest, ki se nahajajo na ozemlju ZSSR, z zahtevami varnosti prometa in varnosti tovora in tirnih vozil skupaj ugotavljajo pristojni organi za ceste, podjetja za motorni promet ali organizacije in organi države. Avtomobilski pregled.
Dostava blaga po cesti se najpogosteje izvaja "od vrat do vrat", to je, da prevoznik blago prevzame neposredno od pošiljatelja in ga izroči prejemniku. To je nedvomna prednost cestnega prometa pred drugimi vrstami - železniškim, vodnim in zračnim. Za opravljanje cestnega prometa je potrebna le cesta, primerna za gibanje tovornega prometa. In če javne ceste najpogosteje omogočajo vožnjo po njih (čeprav so v Rusiji možne možnosti), potem dostopne ceste do krajev nakladanja, razkladanja in nakladanja in razkladanja niso vedno primerne za gibanje tovornega prometa.
Pogosto se tak problem pojavi na gradbiščih in vozniki se z njim soočajo pri prevozu razsutega gradbenega materiala - drobljenca, gramoza, peska itd. in delovodja odločno zahteva vpoklic. Poznana situacija? Ugotovimo.
Najprej morate razumeti, kaj je "dovoz". Zakonodaja ne opredeljuje pojma "cestna dostopna cesta", zato je treba voditi njegovo dobesedno razlago - to je pot, ki povezuje gradbišče in objekte državne in zasebne lastnine z državnim in zasebnim cestnim omrežjem.
Zakonodaja, ki ureja razmerja med strankama prevozne pogodbe, ne vsebuje neposrednih navodil o ravnanju voznika v primeru, da se zaradi pomanjkanja dovozne ceste ni mogoče približati kraju nakladanja ali razkladanja. UATiGNET * in PPGAT ** prav tako ne vsebujeta nobene omembe te dokaj pogoste situacije.
Do konca marca 2018 so na ozemlju Ruske federacije veljala Splošna pravila za cestni prevoz blaga (potrjena s strani Ministrstva za promet RSFSR 30.7.1971). Oddelek 5, razdelek 5, "Pravila za nakladanje in razkladanje tovora" se dobesedno glasi: zagotovite ustrezno osvetlitev za večerno in nočno delo ". Z odredbo Ministrstva za promet Ruske federacije z dne 23. 3. 2018 št. 113 so bili OPPGAT razglašeni za neveljavne.
Vsekakor pa obveznost pošiljatelja in prejemnika, da vzdržujeta dostopne ceste in nakladalno-razkladalne površine v ustreznem stanju, ni v nasprotju z drugimi pravnimi pravili. Poleg tega je ta zahteva skladna z domnevo dobre vere strank v civilnih pravnih razmerjih (člen 10 Civilnega zakonika Ruske federacije).
Po drugi strani pa zakonodajna dejanja strank v primeru takšne situacije niso jasno opredeljena, zato je priporočljivo, da se v pogodbi predvidi postopek za obvestila in dejanja prevoznika, če je to nemogoče ali pretežko. zapeljati do kraja nakladanja ali razkladanja. Tak pogoj disciplinira pošiljatelje in prejemnike, in če se pri razkladanju ni mogoče približati ali manevrirati, se izogniti težavam pri ugotavljanju in potrditvi tega dejstva.
