Interna interakcija s stranko med projektiranjem. Naročnik in izvajalec – odnosi kot osnova za uspeh projekta

Splošne faze interakcije s stranko so naslednje točke:

- Predhodna komunikacija s stranko: prepoznavanje ciljev in ciljev projekta, prepoznavanje glavnih zahtev za prihodnji sistem, predhodna seznanitev z naročnikovim podjetjem, predhodna ocena časovnega okvira in stroškov projekta, priprava in prenos komercialne ponudbe. Stranki.
- Podroben pregled in zbiranje zahtev naročnika: določitev sestave projektne skupine, zbiranje zahtev za sistem, razgovor s ključnimi uporabniki in tehničnimi strokovnjaki naročnika, razvoj in potrditev projektne naloge.
- Razvoj in testiranje sistema: po razvoju sistema ali določenega dela njegove funkcionalnosti se izvede demonstracija naročniku. Sledi faza odkrivanja in odprave napak, če teh ni, sprejemni testi.
- Poskusno obratovanje sistema: postavitev sistema na strani naročnika, usposabljanje uporabnikov, zbiranje pripomb in predlogov za izboljšavo sistema, odprava pripomb.
- Industrijsko delovanje sistema: samostojno delovanje s strani stranke, kontaktiranje službe za podporo podjetja (če je potrebno), zbiranje želja za razvoj sistema.

Pomembna oblika interakcije s stranko je dokumentacija, razvita med izvajanjem projekta v skladu z zahtevami GOST 34 in RUP.

Delovne skupine se oblikujejo za posamezne projektne naloge. Usklajevanje delovanja poteka preko sveta delegatov iz delovnih skupin. Člani delovnih skupin samostojno razvijajo principe interakcije v skupini. Skupine lahko v reševanje problemov vključijo člane drugih skupin. Novi udeleženci projekta lahko sprejmejo uspešne oblike interakcij tako znotraj skupin kot med skupinami

Svet je že dolgo spoznal, da je projektno vodenje posebno področje vodenja, katerega uporaba daje oprijemljive rezultate. Strokovnjaki na tem področju so zelo cenjeni (v ZDA je to tretji najbolje plačani poklic za odvetniki in zdravniki), sama metodologija vodenja projektov pa je postala dejanski standard vodenja v več tisoč podjetjih in se uporablja v različni meri v skoraj vse velike korporacije. Lani so bili sprejeti standardi projektnega vodenja ANSI in izdelan osnutek standardov projektnega vodenja ISO 10006.

Danes si procesa ustvarjanja kompleksnih programskih aplikacij ni mogoče predstavljati brez razdelitve na stopnje življenjskega cikla. Pod življenjskim ciklom programa mislimo na niz stopenj:

Analiza vsebine in izdelava tehničnih specifikacij (interakcija s stranko)
Oblikovanje strukture programa
Kodiranje (nabor programske kode po projektni dokumentaciji)
Testiranje in odpravljanje napak
Izvedba programa
Programska podpora
Odstranjevanje

Oglejmo si podrobneje postopek oblikovanja. Med projektiranjem arhitekt ali izkušen programer izdela projektno dokumentacijo, vključno s tekstovnimi opisi, diagrami in modeli bodočega programa. V tej težki zadevi nam bo pomagal jezik UML.

UML je grafični jezik za vizualizacijo, opis parametrov, načrtovanje in dokumentiranje različnih sistemov (predvsem programov). Diagrami so ustvarjeni s posebnimi orodji CASE, kot sta Rational Rose (http://www-01.ibm.com/software/rational/) in Enterprise Architect (http://www.sparxsystems.com.au/). Enotni informacijski model je zgrajen na osnovi tehnologije UML. Zgornja orodja CASE so sposobna generirati kodo v različnih objektno usmerjenih jezikih in imajo tudi zelo uporabno funkcijo obratnega inženiringa. (Vzvratno inženirstvo vam omogoča, da ustvarite grafični model iz obstoječe programske kode in komentarjev k njej.)

Razmislite o vrstah diagramov za vizualizacijo modela (teh je treba imeti, čeprav obstaja veliko več vrst):

Diagram primera uporabe

Načrtovani sistem je predstavljen kot niz entitet ali akterjev, ki komunicirajo s sistemom z uporabo tako imenovanih precedensov. V tem primeru je igralec (akter) ali igralec vsaka entiteta, ki je v interakciji s sistemom od zunaj. Z drugimi besedami, vsak primer uporabe definira določen niz dejanj, ki jih sistem izvede, ko se pogovarja z igralcem. Hkrati se nič ne pove o tem, kako se bo izvajala interakcija akterjev s sistemom.

Razredni diagram (razredni diagram)

Diagram razredov služi za predstavitev statične strukture modela sistema v terminologiji razredov objektno orientiranega programiranja. Diagram razredov lahko odraža predvsem različne odnose med posameznimi entitetami predmetnega področja, kot so objekti in podsistemi, opisuje pa tudi njihovo notranjo strukturo (polja, metode ...) in vrste odnosov (dedovanje, implementacija vmesnikov . ..). Ta diagram ne zagotavlja informacij o časovnih vidikih delovanja sistema. S tega vidika je razredni diagram nadaljnji razvoj konceptualnega modela zasnovanega sistema. Na tej stopnji je nujno poznavanje pristopa OOP in vzorcev oblikovanja.

Diagram stanja (diagram stanja)

Glavni namen tega diagrama je opisati možna zaporedja stanj in prehodov, ki skupaj označujejo obnašanje elementa modela v njegovem življenjskem ciklu. Diagram stanja predstavlja dinamično vedenje entitet, ki temelji na specifikaciji njihovega odziva na zaznavanje določenih dogodkov.

Diagram zaporedja

Za modeliranje interakcije objektov v jeziku UML se uporabljajo ustrezni interakcijski diagrami. Interakcije objektov lahko obravnavamo v času, nato pa se uporabi diagram zaporedja za predstavitev časa prenosa in sprejema sporočil med objekti. Medsebojno delujoči objekti med seboj izmenjujejo nekatere informacije. V tem primeru so informacije v obliki popolnih sporočil. Z drugimi besedami, čeprav ima sporočilo informacijsko vsebino, pridobi dodatno lastnost izvajanja usmerjenega vpliva na prejemnika.

Diagram sodelovanja

V diagramu sodelovanja so predmeti, ki sodelujejo v interakciji, prikazani v obliki pravokotnikov, ki vsebujejo ime predmeta, njegov razred in po možnosti vrednosti atributov. Kot v diagramu razredov so povezave med objekti označene v obliki različnih povezovalnih črt. V tem primeru lahko eksplicitno določite imena povezave in vloge, ki jih predmeti igrajo v tej povezavi.
Za razliko od diagrama zaporedja, diagram sodelovanja prikazuje samo odnose med objekti, ki igrajo določene vloge v interakciji.

Diagram komponent

Komponentni diagram za razliko od prej obravnavanih diagramov opisuje značilnosti fizične predstavitve sistema. Diagram komponent vam omogoča, da določite arhitekturo sistema, ki se razvija, tako da vzpostavite odvisnosti med komponentami programske opreme, ki so lahko izvorna, binarna in izvršljiva koda. V mnogih razvojnih okoljih modul ali komponenta ustreza datoteki. Pikčaste puščice, ki povezujejo module, prikazujejo razmerja odvisnosti, podobna tistim, ki se pojavijo pri prevajanju izvorne kode programa. Glavni grafični elementi diagrama komponent so komponente, vmesniki in odvisnosti med njimi.

Diagram razmestitve

Diagram uvajanja je zasnovan tako, da vizualizira elemente in komponente programa, ki obstajajo le v fazi njegovega izvajanja (runtime). V tem primeru so predstavljene samo komponente primerka programa, ki so izvršljive datoteke ali dinamične knjižnice. Tiste komponente, ki se med izvajanjem ne uporabljajo, niso prikazane v diagramu razmestitve.
Diagram razmestitve vsebuje grafične predstavitve procesorjev, naprav, procesov in odnosov med njimi. Za razliko od diagramov logične predstavitve je diagram uvajanja enak za sistem kot celoto, saj mora v celoti odražati značilnosti njegove izvedbe. Ta diagram v bistvu zaključi postopek OOAP za določen programski sistem, njegov razvoj pa je običajno zadnji korak v specifikaciji modela.

S tem smo zaključili naš pregled zlasti diagramov in oblikovanja na splošno. Omeniti velja, da je proces oblikovanja že dolgo postal standard razvoja programske opreme, a pogosto se morate soočiti z lepo napisanim programom, ki zaradi pomanjkanja ustrezne dokumentacije pridobi nepotrebne stranske funkcionalnosti, bergle, postane okoren in izgubi svoj nekdanja kakovost. =(

Prepričan sem, da je programer predvsem koder - NE sme komunicirati s stranko, NE sme razmišljati o arhitekturi sistema, ne sme izumiti vmesnika do programa, on mora samo kodirati - implementirati algoritme, funkcionalnost, videz, uporabnost, več pa ne.... Oblikovalec, začenši od abstraktnih diagramov (ki opisujejo predmetno področje) do diagramov, ki predstavljajo strukturo podatkov, razrede in procese njihove interakcije, mora vse podrobno opisati korak za korakom. To pomeni, da bi morala biti kompleksnost dela in plača oblikovalca za red velikosti višja od tistega programerja == koderja. Oprosti za tarnanje....

1.1. Interakcija s strankami (glavne funkcije)

1.1.1. Iskanje po naročilu

7.2.3.1. Za informacije o izdelku

1.1.2. Predpogodbeno delo s stranko

Regulativni dokumenti

2.2.1.2.1. Predpogodbeno delo s stranko STP-1-01

Zahteve sistema vodenja kakovosti ISO9000:2000, člen 7

7.2.1.1. Zahteve strank za izdelke, vključno z zahtevami glede razpoložljivosti, dostave in vzdrževanja

7.2.2.4. Ugotavljanje sposobnosti doseganja skladnosti z določenimi zahtevami

// Analiza zahtev izdelkov / Procesi povezani s potrošnikom / PRODAJA IZDELKOV

1.1.3. Oblikovanje projektnih nalog

Regulativni dokumenti

2.2.1.2.2. Postopek za analizo in sklenitev pogodbe STP-2-01 // Standardi podjetja Enterprise Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

Zahteve sistema vodenja kakovosti ISO9000:2000, člen 7

7.2.1.2. Zahteve, ki jih stranka ne določi, vendar so potrebne za predvideno ali določeno uporabo // Opredelitev zahtev kupca / Procesi povezani s kupcem / PRODAJA IZDELKOV

7.2.1.3. Obveznosti, povezane z izdelkom, vključno z obveznimi zahtevami in zakonskimi določbami // Opredelitev zahtev kupca / Procesi povezani s kupcem / PRODAJA IZDELKOV

// Analiza zahtev izdelkov / Procesi povezani s potrošnikom / PRODAJA IZDELKOV

7.2.2.2. Potrditev zahtev potrošnika pred njihovim sprejemom, če potrošnik ne poda pisne izjave o zahtevah // Analiza zahtev izdelkov / Procesi povezani s potrošnikom / PRODAJA IZDELKOV

7.2.2.3. Pojasnitev sprememb v zahtevah pogodbe ali naročila, ki se razlikujejo od predhodno oddanih (na primer s ponudbami ali povezavami) // Analiza zahtev izdelkov / Procesi povezani s potrošnikom / PRODAJA IZDELKOV

7.3.1.1. Določitev stopenj procesov oblikovanja in/ali razvoja

7.3.2.2. Veljavne pravne in regulativne zahteve

7.3.2.3. Veljavni podatki izhajajo iz podobnih prejšnjih dogodkov // Vhodni podatki za projektiranje in razvoj / Dizajn in razvoj / PRODAJA IZDELKOV

7.3.2.4. Druge zahteve, pomembne za načrtovanje in razvoj // Vhodni podatki za projektiranje in razvoj / Dizajn in razvoj / PRODAJA IZDELKOV

7.3.4.1. Ocenjevanje sposobnosti izpolnjevanja zahtev

1.1.4. Sklenitev pogodb

Regulativni dokumenti

2.2.1.2.3. Pravilnik o pogodbenem delu s stranko (STP-3-01) // Enterprise Standards Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

1.1.5. Spremljanje izpolnjevanja pogodbenih obveznosti

Regulativni dokumenti

2.2.1.2.3.2. Postopek analiziranja sprememb in spreminjanja pogodbene dokumentacije // Predpisi o pogodbenem delu s stranko (STP-3-01) / Enterprise Standards Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

2.2.1.2.4.1. Postopek obravnavanja pritožb in zahtevkov naročnika

2.2.1.2.4.2. Postopek za odpravo pripomb stranke // Predpisi o korektivnih in preventivnih ukrepih (STP-4-01) / Ellat Enterprise Standards (STP) / Dokumenti sistema vodenja kakovosti / Interni regulativni dokumenti / Predpisi

Zahteve sistema vodenja kakovosti ISO9000:2000, člen 7

7.2.3.2. Obdelava zahtevkov, pogodb, naročil, vključno s spremembami // Komunikacija s potrošnikom / Procesi povezani s potrošnikom / PRODAJA IZDELKOV

1.2. Načrtovanje projektnega dela (glavne funkcije)

1.2.1. Pojasnitev sestave kompleksa in obsega razvoja

Regulativni dokumenti

// Enterprise Standards Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

Zahteve sistema vodenja kakovosti ISO9000:2000, člen 7

7.2.2.1. Opredelitev zahtev za izdelek // Analiza zahtev izdelkov / Procesi povezani s potrošnikom / PRODAJA IZDELKOV

1.2.2. Načrtovanje zagotavljanja kakovosti projekta

Regulativni dokumenti

2.2.1.2.5. Sestava in postopek za izdelavo programa zagotavljanja kakovosti projekta (STP-5-01) // Enterprise Standards Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

Zahteve sistema vodenja kakovosti ISO9000:2000, člen 7

7.1.1. Določanje ciljev kakovosti za izdelek, projekt ali pogodbo

7.1.3. Opredelitev dejavnosti pregleda in odobritve ter kriterijev sprejemljivosti // Načrtovanje prodajnih procesov / PRODAJA IZDELKOV

7.2.2.5. Določanje rezultatov analize in kasnejših nadaljnjih ukrepov (glejte klavzulo 5.5.7) // Analiza zahtev izdelkov / Procesi povezani s potrošnikom / PRODAJA IZDELKOV

7.3.1.2. Opredelitev dejavnosti pregleda, preverjanja in odobritve za vsako stopnjo načrtovanja in/ali razvoja // Načrtovanje oblikovanja in razvoja / Oblikovanje in razvoj / PRODAJA IZDELKOV

1.2.3. Oblikovanje zasebnih tehničnih specifikacij za razvoj komponent kompleksa

Regulativni dokumenti

2.2.1.2.7. Tehnologija izvedbe projekta. Faze in vrstni red dela (STP-7-01) // Enterprise Standards Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

1.2.4. Načrtovanje projekta

Regulativni dokumenti

// Enterprise Standards Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

Zahteve sistema vodenja kakovosti ISO9000:2000, člen 7

7.1.2. Določitev potrebe po vzpostavitvi procesov in dokumentacije, zagotavljanju virov in infrastrukture, specifičnih za izdelek // Načrtovanje prodajnih procesov / PRODAJA IZDELKOV

1.2.5. Koordinacija in operativni nadzor izvedbe dela

Regulativni dokumenti

2.2.1.2.4.3. Postopek korektivnih ukrepov // Predpisi o korektivnih in preventivnih ukrepih (STP-4-01) / Ellat Enterprise Enterprise Standards (STP) / Dokumenti sistema vodenja kakovosti / Interni regulativni dokumenti / Predpisi

2.2.1.2.6. Uredba o načrtovanju dela (STP-6-01) // Enterprise Standards Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

Zahteve sistema vodenja kakovosti ISO9000:2000, člen 7

7.3.4.2. Identifikacija problemov in razvoj predlogov za nadaljnje ukrepe // Analiza oblikovanja in razvoja / Oblikovanje in razvoj / POŠILJANJE IZDELKOV

7.3.7. Upravljanje sprememb pri načrtovanju in razvoju

1.3. Razvoj konstrukcijske, programske in obratovalne dokumentacije (Glavne funkcije)

1.3.1. Razvoj dokumentacije za strojno opremo kompleksa

Regulativni dokumenti

2.2.1.2.7. Tehnologija izvedbe projekta. Faze in vrstni red dela (STP-7-01) // Enterprise Standards Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

2.3.3.3. Delovni načrt oddelka za razvoj in proizvodnjo strojne opreme

1.3.2. Razvoj programskega dela kompleksa

Regulativni dokumenti

2.2.1.2.7. Tehnologija izvedbe projekta. Faze in vrstni red dela (STP-7-01) // Enterprise Standards Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

2.3.3.4. Delovni načrt oddelka za razvoj in proizvodnjo programske opreme // Programi in akcijski načrti / Organizacijski in upravni akti družbe / Predpisi

1.3.4. Analiza in odobritev rezultatov projektiranja

Regulativni dokumenti

2.2.1.2.7. Tehnologija izvedbe projekta. Faze in vrstni red dela (STP-7-01) // Enterprise Standards Ellat (STP) / Dokumenti sistema vodenja kakovosti / Notranji regulativni dokumenti / Predpisi

Zahteve sistema vodenja kakovosti ISO9000:2000, člen 7

7.3.3.1. Skladnost z zahtevami za načrtovanje in razvoj

7.3.3.2. Zagotovite ustrezne informacije za proizvodne in storitvene dejavnosti (glejte 7.5) // Izhod oblikovanja in razvoja / Oblikovanje in razvoj / POŠILJANJE IZDELKOV

7.3.3.4. Določite lastnosti izdelka, ki so bistvene za njegovo varno in pravilno uporabo. // Izhod oblikovanja in razvoja / Oblikovanje in razvoj / POŠILJANJE IZDELKOV

7.3.5.1. Skladnost izhodnih podatkov z vhodnimi zahtevami // Verifikacija dizajna in razvoja / Dizajn in razvoj / PRODAJA IZDELKOV

7.3.6. Odobritev rezultatov načrtovanja in razvoja // Oblikovanje in razvoj / PRODAJA IZDELKOV

Izobraževanje, razvoj, treningi

Ključne besede:

1 -1

Razmislite o celotni shemi interakcije s stranko na primeru razvoja spletnega mesta. Grafično lahko faze interakcije predstavimo kot naslednjo sliko:

Primarno je klic oz E-naslov, ki jih obdeluje upravitelj računa. Vodja govori o storitvah podjetja Beehive, daje odgovore na vsa vprašanja in stranki razloži nadaljnji proces interakcije.

* Omeniti velja, da je stranki za celotno obdobje njegovega projekta dodeljen osebni vodja, ki je pripravljen odgovoriti na vsa vprašanja in pomagati pri reševanju vseh težav.

Nato upravitelj pomaga dokončati kratka oblika za razvoj spletne strani, ki vsebuje potrebna pojasnjevalna vprašanja na temo sodelovanja in dodaja kontakt v interni sistem CRM (Customer Relationship Management System).

Podatki se vnesejo v sistem za varno shranjevanje vseh potrebnih podatkov o strankah in zagotavljanje kakovostnega razvoja strani kot celote.

Na podlagi izpolnjenega briefa strokovnjaki Beehive pripravijo individualno komercialno ponudbo z opisom časovnega okvira in stroškov dela in ga upravitelj pošlje stranki v obravnavo.

Sledi proces dogovora o pogojih sodelovanja, katerega rezultat je pogodba. Zaradi hitrejšega začetka del pogodbo podpišeta obe stranki in si izmenjata skenirani kopiji pogodbe. Izvirniki pogodbe se pošljejo priporočeno po pošti (v nadaljevanju vsi papirni izvodi se izmenjujejo po pošti ali kurirju). Ko stranka prejme izvirnik v papirni obliki, se en izvod vrne po pošti.

*Postopek od klica do podpisa pogodbe običajno ne traja več kot 1-2 dni.

Po podpisu pogodbe in izmenjavi elektronskih skeniranih kopij kupec plača avans, katerega znesek običajno znaša 50% celotne pogodbene vrednosti.

Po prejemu predplačila in opravljeni analizi predmetnega področja se začne faza razvoja in odobritve mandat (TOR), kjer so predpisane vse zahteve za spletno stran, ki se razvija, podane so sheme in izdelan podroben prototip celotne strani. TK je obvezen aneks k pogodbi, ki ga potrdita obe stranki in podpišeta na enak način kot pogodba.

* Treba je razumeti, da je projektna naloga zelo pomemben dokument tako za izvajalca kot za stranko. Omogoča vam, da kakovostno in pravočasno načrtujete in izvedete internetni projekt.

Ko so vse zahteve odobrene, je stranka poslana seznam potrebnih besedilnih in grafičnih materialov, ki jih mora naročnik zagotoviti pred začetkom razvojne faze (tj. med izdelavo idejne zasnove s strani izvajalca, naročnik zbere in zagotovi vse potrebne materiale). Ta seznam lahko vključuje: opis podjetja, s katerim sodelujejo, katere nagrade in certifikate imajo, cene in cenike, katalog izdelkov in opis blaga, opis storitev, kontaktne podatke, objavljene na spletnem mestu itd.

Včasih je stranka težko sama opisati svoje storitve ali pa za to enostavno zmanjka časa. V tem primeru je izvajalec pripravljen dokončati delo pri pisanju manjkajoče vsebine za spletno stran (slike, besedila, videi itd.).

* Zagotavljanje stranki potrebnih materialov je ključnega pomena, ker:

v postavitev spletnega mesta je treba naenkrat pravilno vnesti vso vsebino, ki jo zagotovi stranka (nima smisla opravljati dodatnega dela);
tehnološki proces izvajalca je načrtovan dobesedno "na minuto" in ga ne želimo kršiti ter imeti dodatnih stroškov;
polnjenje internetnega projekta s testnimi informacijami prav tako nima smisla (prvič, spet se poveča količina nepotrebnega dela; drugič, iskalniki lahko pesimizirajo gostujoče spletno mesto s testno vsebino; tretjič, vaše potencialne stranke imajo lahko negativen odnos do spletnega mesta, kar vsebuje očitno neuporabne informacije);
Tako za vas kot za nas je pomembno, da projekt izvedemo strokovno in v roku.

* Drage stranke, prosimo, ne odlašajte z razvojem lastnega spletnega mesta in iz tega zaslužite. Posredujte vsebino pravočasno! V nasprotnem primeru bo projekt zamrznjen, dokler ne prejmemo informacij od vas, zato je bil rok za oddajo strani prestavljen. Če ni časa za zbiranje in pisanje informacij, nam naročite pisanje besedil in obdelavo fotografij, je poceni.

Vzporedno se oblikuje delovna skupina za projekt in faza se začne razvoj načrta oblikovanja prihodnje mesto.
Ko je postavitev oblikovanja pripravljena, se pošlje stranki v odobritev. Ko je model odobren, postane veljaven dizajn.

* Odvisno od kompleksnosti projekta lahko stranki omogočite dostop do sistema za vodenje projektov (na primer Redmine), kjer lahko naložite potrebne vire projekta, spremljate razvojne faze in objavite komentarje.

Za nadaljnje nadaljevanje dela je obvezno od naročnika prejeti vse potrebne materiale, katerih seznam je bil naročniku predhodno poslan.

Takoj ko prejme manjkajoče materiale. Pomemben stopnja razvoja mesta v skladu s potrjenim TOR.
Ta stopnja vključuje veliko število vrst dela: to je navzkrižna postavitev postavitev spletnega mesta, razvoj potrebnih oblikovalskih predlog za izbrani sistem za upravljanje vsebin (CMS), namestitev in konfiguracija samega CMS, namestitev potrebnih moduli in komponente, razvoj manjkajočih modulov, celovita študija algoritmov delovanja spletnega mesta, polnjenje spletnega mesta z vsebino, uvedba projekta na tehnično področje in prehod na testiranje.

Testiranje internetnega projekta izvajajo strokovnjaki izvajalca, vse napake in komentarji so odpravljeni, spletno mesto je natančno prilagojeno za delo.

Takoj, ko je delo končano in testiranje spletnega mesta na tehničnem področju, se stopnja predaje. Tu se s strani naročnika preveri izpolnjevanje zahtev TOR in celoten proces delovanja internetnega projekta.
Ko stranka sprejme odločitev o popolni skladnosti spletnega mesta z zahtevami TOR, se spletno mesto prenese na stranko in projekt se objavi na gostovanju.

Rezultat in potrdilo o predaji in prevzemu del je izvedljiva lokacija in prevzemni akt, ki ga podpišeta obe strani. Podpisan akt se skupaj s celotno dokumentacijo za računovodstvo pošlje po pošti.

Po podpisu prevzemnega potrdila naročnik v skladu s pogodbo plača preostanek stroškov dela.

Po končnem izračunu skupaj z dokumentacijo in spletno stranjo stranka prejme navodila za uporabo, kopija spletnega mesta na DVD-ju in brezplačno tehnična podpora v 2-4 tednih od datuma sprejema mesta.

V tem diagramu smo poskušali v celoti prikazati vse vidike interakcij od začetnega klica do izvedbe projekta. Pri preprostih projektih se lahko nekateri koraki združijo ali izpustijo. Toda v vsakem primeru se vse odraža v pogodbi.

Shema dela za storitve "Celoviti razvoj spletnega mesta" kot tudi "Promocija spletnega mesta" strukturno ponavlja zgoraj opisani proces interakcije med stranko in izvajalcem in zato ne potrebuje podrobnega opisa.

Upamo, da je opisana shema interakcije pregledna in razumljiva. Če imate še vprašanja, prosim

Projekt:	Porazdelitev poizvedb v elektronski katalog po iskalnih indeksih in iskalnih izrazih
Obseg projekta:	13.02.2006 - 05.06.2006
Stranka:	Znanstvena knjižnica Petrozavodske državne univerze.
Odgovorni:	Gorshkova Galina Anatolyevna, vodja oddelka za računalniško obdelavo dokumentov in ustvarjanje katalogov. E-naslov pošta: . Suženj. tel.: 719602. Knjižnica: kab. 102. Guryev Dmitry Borisovich, vodilni programer RCNIT. E-naslov pošta: . Suženj. tel.: 784775. Internetni center.
Inštruktor:	Kulakov Kiril Aleksandrovič E-naslov: . Poslovni telefon: 711015. Soba 215
Informacije za inštruktorja:	Skupina številka 13
Sorodni dokumenti:	Pregled projekta Načrt projekta Delovni načrt (Gantogram) Zahteve Specifikacija Preizkus zasnove Izvedbeni dokument Preizkusni dokument Customer Engagement Poročila o odnosih z razvijalci Poročila o napredku razvoja Slovar Uporabniški priročnik

Prvo srečanje s stranko.

Na prvem sestanku se je razvojna ekipa predstavila stranki. Stranka pa je govorila o znanstveni knjižnici PetrSU.

Knjižnica deluje na osnovi avtomatiziranega sistema "Foliant". Elektronski katalog je del knjižničnega sistema. Iskanje po katalogu poteka s pomočjo poizvedb. Operater ustvari iskalne nize, ki lahko vsebujejo veliko število iskalnih indeksov in iskalnih izrazov. Vsaka zahteva se zabeleži v dnevniški tabeli. Ta tabela vsebuje podatke o času povpraševanja, naslovu naročnika, ki je povpraševal, samem povpraševanju, rezultatu povpraševanja.

Stranka mora stalno spremljati dnevniško tabelo in zagotoviti nekaj statističnih podatkov o uporabi iskalnih indeksov.

Predstavljene so bile tudi začetne zahteve za projekt, ki se izvaja. Ena od zahtev je učinkovito zbiranje statistik. To pomeni, da je treba statistiko prikazati po razumnem času po pošiljanju zahteve. Zaradi te zahteve so razvijalce spodbujali k uporabi postopkov na strani strežnika v PL/SQL.

Drugi sestanek s stranko.

Stranka je razvijalcem zagotovila prijavo in geslo za vstop v elektronski kataloški sistem ter zagotovila kopije dveh tabel za delo - tabelo dnevnika in tabelo iskalnih indeksov.

Gurjev Dmitrij Borisovič nas je podrobneje seznanil z delom v odjemalcu DBMS Oracle SQL*Plus. Ekipa se je seznanila z delom elektronskega kataloga.

Sistem "Foliant" deluje na osnovi standarda RusMark, ki vsebuje približno 99 polj. Vsaka knjižnica, ki dela z AIBS "Foliant", izbere polja in podpolja, ki jih bo uporabljala. Obstajajo posebni GOST-i, ki opisujejo pravila za shranjevanje knjižničnih podatkov. Ker je polj veliko, smo izdelali sistem iskalnih indeksov. Obstajajo storitveni in javni indeksi.

Uporabnike imenika delimo na notranje in zunanje. Vsakemu oddelku ali zaposlenemu so dodeljene lastne pravice. Vsak zapis o objektu je razčlenjen na ločene elemente in ni shranjen kot celota.

Tretje srečanje s stranko.

Stranka nam je pisno podala jasne zahteve.

Stranko zanimajo naslednji statistični podatki:

Število zahtevkov za elektronski katalog.

Za zadnji mesec po dnevih.
Mesečno obračunavanje tekočega leta.
Računovodstvo po letih.
Ustvarite zgodovino informacij.

Seznam zahtevkov po vsakemu iskalni indeks, kjer je bil rezultat iskanja nič.

Seznam pogosto pojavljajočih se zahtev.

Analiza izvajanja zahtevkov za določeno obdobje. Poročilo mora vsebovati naslednje statistične podatke:

Število zahtevkov.
Število zahtev za iskanje.
Število kompleksnih poizvedb.
Število uspešnih odgovorov.
Število ničelnih odgovorov.
Avtor
Avtor rev. proizv.
Vrsta dokumenta.
Geografski odsek.
Vnesite datum.
Datum objave.
Naslov.

Četrti sestanek s stranko.

Specialist stranke Guryev D.B. razložil zapletenost namestitve in konfiguracije pripomočka SQL*Plus. Rešitev problema zagona programa je bila namestitev paketa SQL * Net, tudi Guryev D.B. zagotovil natančna imena tabel za razvijalce in dodal še eno tabelo, ki je na voljo ekipi. Strokovnjak je preučil arhitekturni dokument in predlagal praktično izvedbo vseh vrst arhitekture in izbiro najbolj optimalne. Hkrati je zaželeno, da ne obnovite dnevnika - tabele in, kolikor je mogoče, pri reševanju določenega problema posplošite podatke iz dnevnika - tabele za nadaljnjo uporabo v različnih lokalnih statistikah.

Stranka Gorshkova G.A. se seznanil z dokumentom zahtev in jih potrdil.

Peto srečanje s stranko.

Guryev Dmitry Borisovich, strokovnjak s strani stranke, je bil povabljen, da namesti programsko opremo, potrebno za delo z DBMS "Oracle", na strežniku za usposabljanje PetrSU. V ta proces s strani univerze je bil vključen tudi Vadim Anatolyevich Ponomarev, ki ima administrativni dostop do strežnika PetrSU.