Iekšējā mijiedarbība ar klientu projektēšanas laikā. Pasūtītājs un izpildītājs - attiecības kā projekta panākumu pamats

Vispārējie mijiedarbības ar klientu posmi ir šādi:

- Iepriekšēja komunikācija ar pasūtītāju: projekta mērķu un uzdevumu apzināšana, galveno prasību noteikšana topošajai sistēmai, iepriekšēja iepazīšanās ar Pasūtītāja uzņēmumu, projekta laika un izmaksu iepriekšējs novērtējums, Komercpiedāvājuma sagatavošana un nodošana Klientam.
- Detalizēta klientu prasību apsekošana un apkopošana: projekta komandas sastāva noteikšana, prasību apkopošana sistēmai, Pasūtītāja galveno lietotāju un tehnisko speciālistu intervēšana, Darba uzdevuma izstrāde un apstiprināšana.
- Sistēmas izstrāde un testēšana: pēc sistēmas vai noteiktas tās funkcionalitātes daļas izstrādes tiek veikta demonstrēšana Klientam. Pēc tam seko kļūdu atklāšanas un novēršanas posms, ja tādu nav, pieņemšanas testi.
- Sistēmas izmēģinājuma darbība: sistēmas izvietošana Klienta pusē, lietotāju apmācība, komentāru un ieteikumu apkopošana sistēmas pilnveidošanai, komentāru likvidēšana.
- Sistēmas rūpnieciskā darbība: patstāvīga darbība no Klienta puses, sazinoties ar Uzņēmuma atbalsta dienestu (ja nepieciešams), apkopojot vēlmes sistēmas attīstībai.

Svarīga mijiedarbības forma ar klientu ir dokumentācija, kas izstrādāta projekta īstenošanas laikā saskaņā ar GOST 34 un RUP prasībām.

Konkrētu projekta uzdevumu veikšanai tiek veidotas darba grupas. Darbību sinhronizācija tiek veikta ar darba grupu delegātu padomes starpniecību. Darba grupu dalībnieki patstāvīgi izstrādā mijiedarbības principus grupā. Grupas problēmu risināšanā var iesaistīt citu grupu dalībniekus. Veiksmīgas mijiedarbības formas gan grupās, gan starp grupām var pārņemt jauni projekta dalībnieki

Pasaule jau sen ir atzinusi, ka projektu vadība ir īpaša vadības joma, kuras pielietošana dod taustāmus rezultātus. Šīs jomas profesionāļi tiek augstu novērtēti (ASV tā ir trešā vislabāk apmaksātā profesija aiz juristiem un ārstiem), un pati projektu vadības metodoloģija ir kļuvusi par de facto vadības standartu daudzos tūkstošos uzņēmumu un tiek izmantota dažādās pakāpēs. gandrīz visas lielās korporācijas. Pērn tika pieņemti ANSI projektu vadības standarti, izstrādāts ISO 10006 projektu vadības standartu projekts.

Mūsdienās sarežģītu lietojumprogrammu izveides process nav iedomājams bez sadalīšanas dzīves cikla posmos. Programmas dzīves cikla ietvaros mēs domājam posmu kopumu:

Priekšmeta jomas analīze un tehnisko specifikāciju izveide (mijiedarbība ar klientu)
Programmas struktūras projektēšana
Kodēšana (programmas koda komplekts saskaņā ar projekta dokumentāciju)
Testēšana un atkļūdošana
Programmas īstenošana
Programmas atbalsts
Atbrīvošanās

Sīkāk aplūkosim projektēšanas procesu. Projektēšanas procesā arhitekts vai pieredzējis programmētājs veido projekta dokumentāciju, iekļaujot topošās programmas teksta aprakstus, diagrammas un modeļus. Šajā sarežģītajā jautājumā mums palīdzēs UML valoda.

UML ir grafiska valoda dažādu sistēmu (jo īpaši programmu) vizualizācijai, parametru aprakstīšanai, projektēšanai un dokumentēšanai. Diagrammas tiek veidotas, izmantojot īpašus CASE rīkus, piemēram, Rational Rose (http://www-01.ibm.com/software/rational/) un Enterprise Architect (http://www.sparxsystems.com.au/). Vienots informācijas modelis ir izveidots, pamatojoties uz UML tehnoloģiju. Iepriekš minētie CASE rīki spēj ģenerēt kodu dažādās objektorientētās valodās, un tiem ir arī ļoti noderīga reversās inženierijas funkcija. (Reversā inženierija ļauj izveidot grafisku modeli no esošā programmas koda un komentāriem pie tā.)

Apsveriet diagrammu veidus modeļa vizualizēšanai (tie ir obligāti, lai gan ir daudz vairāk veidu):

Izmantot gadījuma diagrammu

Projektētā sistēma tiek attēlota kā entītiju vai dalībnieku kopums, kas mijiedarbojas ar sistēmu, izmantojot tā sauktos precedentus. Šajā gadījumā aktieris (aktieris) vai aktieris ir jebkura vienība, kas mijiedarbojas ar sistēmu no ārpuses. Citiem vārdiem sakot, katrs lietošanas gadījums nosaka noteiktu darbību kopumu, ko sistēma veic, runājot ar aktieri. Tajā pašā laikā nekas netiek runāts par to, kā tiks īstenota dalībnieku mijiedarbība ar sistēmu.

Klases diagramma (klases diagramma)

Klases diagramma kalpo, lai attēlotu sistēmas modeļa statisko struktūru objektorientētās programmēšanas klašu terminoloģijā. Klases diagramma jo īpaši var atspoguļot dažādas attiecības starp atsevišķām priekšmetu jomas entītijām, piemēram, objektiem un apakšsistēmām, kā arī apraksta to iekšējo struktūru (lauki, metodes ...) un attiecību veidus (mantošana, saskarņu ieviešana). ..). Šī diagramma nesniedz informāciju par sistēmas darbības laika aspektiem. No šī viedokļa klašu diagramma ir projektētās sistēmas konceptuālā modeļa tālāka attīstība. Šajā posmā būtiskas ir zināšanas par OOP pieeju un dizaina modeļiem.

Stāvokļa diagramma (statkartes diagramma)

Šīs diagrammas galvenais mērķis ir aprakstīt iespējamās stāvokļu un pāreju secības, kas kopā raksturo modeļa elementa uzvedību tā dzīves cikla laikā. Stāvokļa diagramma attēlo entītiju dinamisko uzvedību, pamatojoties uz to reakcijas specifikāciju uz dažu konkrētu notikumu uztveri.

Secības diagramma

Objektu mijiedarbības modelēšanai UML valodā tiek izmantotas atbilstošas mijiedarbības diagrammas. Objektu mijiedarbību var aplūkot laikā, un pēc tam tiek izmantota secības diagramma, lai attēlotu ziņojumu nosūtīšanas un saņemšanas laiku starp objektiem. Mijiedarbojošie objekti apmainās ar kādu informāciju savā starpā. Šajā gadījumā informācija tiek sniegta pilnīgu ziņojumu veidā. Citiem vārdiem sakot, lai gan ziņojumam ir informatīvs saturs, tas iegūst papildu īpašību, tiešu ietekmi uz tā adresātu.

Sadarbības diagramma

Sadarbības diagrammā objekti, kas piedalās mijiedarbībā, ir attēloti taisnstūru veidā, kas satur objekta nosaukumu, klasi un, iespējams, atribūtu vērtības. Tāpat kā klašu diagrammā, asociācijas starp objektiem ir norādītas dažādu savienojošo līniju veidā. Šajā gadījumā varat skaidri norādīt asociācijas nosaukumus un lomas, ko objekti spēlē šajā saistībā.
Atšķirībā no secības diagrammas, sadarbības diagramma attēlo tikai attiecības starp objektiem, kuriem mijiedarbībā ir noteiktas lomas.

Komponentu diagramma

Komponentu diagramma, atšķirībā no iepriekš apskatītajām diagrammām, apraksta sistēmas fiziskā attēlojuma iezīmes. Komponentu diagramma ļauj noteikt izstrādājamās sistēmas arhitektūru, nosakot atkarības starp programmatūras komponentiem, kas var būt avota, binārais un izpildāmais kods. Daudzās izstrādes vidēs modulis vai komponents atbilst failam. Punktētās bultiņas, kas savieno moduļus, parāda atkarības attiecības, kas ir līdzīgas tām, kas rodas, kompilējot programmas pirmkodu. Komponentu diagrammas galvenie grafiskie elementi ir komponenti, saskarnes un atkarības starp tām.

Izvietošanas diagramma

Izvietošanas diagramma ir paredzēta, lai vizualizētu programmas elementus un komponentus, kas pastāv tikai tās izpildes stadijā (izpildlaikā). Šajā gadījumā tiek parādīti tikai programmas instances komponenti, kas ir izpildāmie faili vai dinamiskās bibliotēkas. Tie komponenti, kas netiek izmantoti izpildlaikā, nav parādīti izvietošanas diagrammā.
Izvietošanas diagrammā ir grafiski attēloti procesori, ierīces, procesi un attiecības starp tiem. Atšķirībā no loģiskā attēlojuma diagrammām, izvietošanas diagramma ir vienāda visai sistēmai, jo tai pilnībā jāatspoguļo tās ieviešanas iezīmes. Šī diagramma būtībā pabeidz OOAP procesu konkrētai programmatūras sistēmai, un tās izstrāde parasti ir pēdējais solis modeļa specifikācijā.

Tas noslēdz mūsu pārskatu par diagrammām un dizainu kopumā. Vērts atzīmēt, ka projektēšanas process jau sen kļuvis par programmatūras izstrādes standartu, taču nereti nākas saskarties ar skaisti uzrakstītu programmu, kas atbilstošas dokumentācijas trūkuma dēļ iegūst lieku sānu funkcionalitāti, kruķi, kļūst apgrūtinoša un zaudē savu bijusī kvalitāte. =(

Esmu pārliecināts, ka programmētājs primāri ir kodētājs - viņam NEDRĪKST komunicēt ar klientu, NAV jādomā par sistēmas arhitektūru, nevajadzētu izdomāt saskarni programmai, viņam tikai jākodē - jārealizē algoritmi, funkcionalitāte, izskats, lietojamība, bet ne vairāk... Projektētājam, sākot no abstraktām diagrammām (aprakstot priekšmeta jomu) līdz diagrammām, kas attēlo datu struktūru, klases un to mijiedarbības procesus, soli pa solim viss ir jāapraksta detalizēti. Tas ir, dizainera darba sarežģītībai un algai vajadzētu būt par kārtu lielākai nekā programmētājam == kodētājam. Atvainojos par izsmieklu....

1.1. Mijiedarbība ar klientiem (galvenās funkcijas)

1.1.1. Pasūtījuma meklēšana

7.2.3.1. Informācijai par produktu

1.1.2. Pirmslīguma darbs ar Pasūtītāju

Normatīvie dokumenti

2.2.1.2.1. Pirmslīguma darbs ar Pasūtītāju STP-1-01

ISO9000:2000 kvalitātes vadības sistēmas prasību 7.punkts

7.2.1.1. Klientu prasības produktiem, tostarp prasības par pieejamību, piegādi un apkopi

7.2.2.4. Noteikt spēju panākt atbilstību noteiktām prasībām

// Preču prasību analīze / Ar patērētāju saistītie procesi / PRODUKTU TIRDZNIECĪBA

1.1.3. Darba uzdevuma noformēšana

Normatīvie dokumenti

2.2.1.2.2. Līguma STP-2-01 analīzes un noslēgšanas procedūra // Uzņēmuma Ellat (STP) standarti / Kvalitātes vadības sistēmas dokumenti / Iekšējie normatīvie dokumenti / Noteikumi

ISO9000:2000 kvalitātes vadības sistēmas prasību 7.punkts

7.2.1.2. Prasības, kuras nav norādījis pasūtītājs, bet nepieciešamas paredzētajam vai noteiktajam lietojumam // Klientu prasību definēšana / Ar klientu saistīti procesi / PRODUKTU PĀRDOŠANA

7.2.1.3. Ar produktu saistīti pienākumi, tostarp obligātās prasības un tiesību normas // Klientu prasību definēšana / Ar klientu saistīti procesi / PRODUKTU PĀRDOŠANA

// Preču prasību analīze / Ar patērētāju saistītie procesi / PRODUKTU TIRDZNIECĪBA

7.2.2.2. Patērētāja prasību apstiprināšana pirms to pieņemšanas, ja patērētājs nesniedz rakstisku prasību paziņojumu // Preču prasību analīze / Ar patērētāju saistītie procesi / PRODUKTU TIRDZNIECĪBA

7.2.2.3. Līguma vai pasūtījuma prasību izmaiņu precizēšana, kas atšķiras no iepriekš iesniegtajām (piemēram, ar solīšanu vai saitēm) // Preču prasību analīze / Ar patērētāju saistītie procesi / PRODUKTU TIRDZNIECĪBA

7.3.1.1. Projektēšanas un/vai izstrādes procesu posmu noteikšana

7.3.2.2. Piemērojamās juridiskās un normatīvās prasības

7.3.2.3. Piemērojamie dati, kas iegūti no līdzīgām iepriekšējām norisēm // Ievaddati projektēšanai un izstrādei / Dizains un izstrāde / PRODUKTU PĀRDOŠANA

7.3.2.4. Citas prasības, kas ir svarīgas projektēšanai un izstrādei // Ievaddati projektēšanai un izstrādei / Dizains un izstrāde / PRODUKTU PĀRDOŠANA

7.3.4.1. Novērtēt spēju izpildīt prasības

1.1.4. Līgumu slēgšana

Normatīvie dokumenti

2.2.1.2.3. Noteikumi par līgumdarbu ar Pasūtītāju (STP-3-01) // Uzņēmuma standarti Ellat (STP) / Kvalitātes vadības sistēmas dokumenti / Iekšējie normatīvie dokumenti / Noteikumi

1.1.5. Līgumsaistību izpildes uzraudzība

Normatīvie dokumenti

2.2.1.2.3.2. Izmaiņu analīzes un izmaiņu veikšanas kārtība Līguma dokumentos // Noteikumi par līgumdarbu ar Pasūtītāju (STP-3-01) / Uzņēmuma standarti Ellat (STP) / Kvalitātes vadības sistēmas dokumenti / Iekšējie normatīvie dokumenti / Nolikums

2.2.1.2.4.1. Klienta sūdzību un pretenziju izskatīšanas kārtība

2.2.1.2.4.2. Pasūtītāja komentāru likvidēšanas kārtība // Korektīvo un preventīvo darbību noteikumi (STP-4-01) / Ellat Enterprise Standards (STP) / Kvalitātes vadības sistēmas dokumenti / Iekšējie normatīvie dokumenti / Noteikumi

ISO9000:2000 kvalitātes vadības sistēmas prasību 7.punkts

7.2.3.2. Pieprasījumu, līgumu, pasūtījumu apstrāde, ieskaitot izmaiņas // Komunikācija ar patērētāju / Ar patērētāju saistītie procesi / PRODUKTU TIRDZNIECĪBA

1.2. Projekta darba plānošana (galvenās funkcijas)

1.2.1. Kompleksa sastāva un izstrādes apjoma precizēšana

Normatīvie dokumenti

// Uzņēmuma standarti Ellat (STP) / Kvalitātes vadības sistēmas dokumenti / Iekšējie normatīvie dokumenti / Noteikumi

ISO9000:2000 kvalitātes vadības sistēmas prasību 7.punkts

7.2.2.1. Preču prasību definēšana // Preču prasību analīze / Ar patērētāju saistītie procesi / PRODUKTU TIRDZNIECĪBA

1.2.2. Projekta kvalitātes nodrošināšanas plānošana

Normatīvie dokumenti

2.2.1.2.5. Projekta kvalitātes nodrošināšanas programmas (STP-5-01) sastāvs un izstrādes procedūra // Uzņēmuma standarti Ellat (STP) / Kvalitātes vadības sistēmas dokumenti / Iekšējie normatīvie dokumenti / Noteikumi

ISO9000:2000 kvalitātes vadības sistēmas prasību 7.punkts

7.1.1. Produkta, projekta vai līguma kvalitātes mērķu noteikšana

7.1.3. Pārskatīšanas un apstiprināšanas darbību definīcija un pieņemšanas kritēriji // Pārdošanas procesu plānošana / PRODUKTU TIRDZNIECĪBA

7.2.2.5. Analīzes rezultātu fiksēšana un turpmākās turpmākās darbības (sk. 5.5.7. punktu) // Preču prasību analīze / Ar patērētāju saistītie procesi / PRODUKTU TIRDZNIECĪBA

7.3.1.2. Pārskatīšanas, verifikācijas un apstiprināšanas darbību definīcija katram projektēšanas un/vai izstrādes posmam // Dizaina un izstrādes plānošana / Dizains un izstrāde / PRODUKTU TIRDZNIECĪBA

1.2.3. Privāto tehnisko specifikāciju veidošana kompleksa sastāvdaļu izstrādei

Normatīvie dokumenti

2.2.1.2.7. Projekta īstenošanas tehnoloģija. Darba posmi un secība (STP-7-01) // Uzņēmuma standarti Ellat (STP) / Kvalitātes vadības sistēmas dokumenti / Iekšējie normatīvie dokumenti / Noteikumi

1.2.4. Projekta plānošana

Normatīvie dokumenti

// Uzņēmuma standarti Ellat (STP) / Kvalitātes vadības sistēmas dokumenti / Iekšējie normatīvie dokumenti / Noteikumi

ISO9000:2000 kvalitātes vadības sistēmas prasību 7.punkts

7.1.2. Nepieciešamības noteikšana procesu un dokumentācijas izveidei, nodrošinot produktam raksturīgus resursus un infrastruktūru // Pārdošanas procesu plānošana / PRODUKTU TIRDZNIECĪBA

1.2.5. Darba izpildes koordinēšana un operatīvā kontrole

Normatīvie dokumenti

2.2.1.2.4.3. Koriģējošās darbības procedūra // Korektīvo un preventīvo darbību noteikumi (STP-4-01) / Ellat Uzņēmumu standarti (STP) / Kvalitātes vadības sistēmas dokumenti / Iekšējie normatīvie dokumenti / Noteikumi

2.2.1.2.6. Nolikums par darba plānošanu (STP-6-01) // Uzņēmuma standarti Ellat (STP) / Kvalitātes vadības sistēmas dokumenti / Iekšējie normatīvie dokumenti / Noteikumi

ISO9000:2000 kvalitātes vadības sistēmas prasību 7.punkts

7.3.4.2. Problēmu identificēšana un priekšlikumu izstrāde turpmākajām darbībām // Dizaina un izstrādes analīze / Dizains un izstrāde / PRODUKTU PASTĀ

7.3.7. Dizaina un izstrādes izmaiņu vadība

1.3. Dizaina, programmatūras un ekspluatācijas dokumentācijas izstrāde (galvenās funkcijas)

1.3.1. Kompleksa aparatūras dokumentācijas izstrāde

Normatīvie dokumenti

2.3.3.3. Aparatūras izstrādes un ražošanas nodaļas darba plāns

1.3.2. Kompleksa programmatūras daļas izstrāde

Normatīvie dokumenti

2.3.3.4. Programmatūras izstrādes un ražošanas nodaļas darba plāns // Programmas un rīcības plāni / Uzņēmuma organizatoriskie un administratīvie dokumenti / Nolikums

1.3.4. Projektēšanas rezultātu analīze un apstiprināšana

Normatīvie dokumenti

ISO9000:2000 kvalitātes vadības sistēmas prasību 7.punkts

7.3.3.1. Atbilst projektēšanas un izstrādes ievades prasībām

7.3.3.2. Sniedziet atbilstošu informāciju par ražošanas un pakalpojumu darbībām (sk. 7.5.) // Dizaina un izstrādes produkcija / Dizains un izstrāde / PRODUKTU PASTĀ

7.3.3.4. Nosakiet produkta īpašības, kas ir būtiskas tā drošai un pareizai lietošanai. // Dizaina un izstrādes produkcija / Dizains un izstrāde / PRODUKTU PASTĀ

7.3.5.1. Izvades datu atbilstība ievades prasībām // Dizaina un izstrādes pārbaude / Dizains un izstrāde / PRODUKTU PĀRDOŠANA

7.3.6. Projektēšanas un izstrādes rezultātu apstiprināšana // Dizains un izstrāde / PĀRDOŠANAS PRODUKTI

Izglītība, attīstība, apmācības

Atslēgvārdi:

1 -1

Apsveriet pilnu mijiedarbības ar klientu shēmu tīmekļa vietnes izstrādes piemērā. Grafiski mijiedarbības posmus var attēlot kā šādu attēlu:

Primārais ir zvanu vai e-pasts, kurus apstrādā konta pārzinis. Vadītājs stāsta par uzņēmuma Beehive pakalpojumiem, sniedz atbildes uz visiem interesējošiem jautājumiem un izskaidro klientam tālāko mijiedarbības procesu.

* Vērts atzīmēt, ka klientam uz visu viņa projekta laiku tiek iedalīts personīgais menedžeris, kurš ir gatavs atbildēt uz visiem jautājumiem un palīdzēt visu problēmu risināšanā.

Tālāk vadītājs palīdz pabeigt īsa forma mājas lapas izstrādei, kas satur nepieciešamos precizējošos jautājumus par sadarbības tēmu un pievieno kontaktu iekšējai CRM sistēmai (Customer Relationship Management System).

Dati tiek ievadīti sistēmā, lai droši uzglabātu visus nepieciešamos klientu datus un nodrošinātu vietnes kvalitatīvu attīstību kopumā.

Pamatojoties uz aizpildīto instruktāžu, Bišu stropu speciālisti sagatavo individuāls komercpiedāvājums ar darba laika un izmaksu aprakstu, un vadītājs to nosūta klientam izskatīšanai.

Tālāk seko saskaņošanas process par sadarbības nosacījumiem, kura rezultāts ir līgums. Lai paātrinātu darbu uzsākšanu, līgumu paraksta abas puses un puses apmainās ar skenētām līguma kopijām. Līguma oriģinālus nosūta ierakstītā vēstulē (turpmāk visas papīra kopijas tiek apmaiņas ar pasta vai kurjera palīdzību). Pēc tam, kad puse ir saņēmusi oriģinālu papīra formā, viena kopija tiek nosūtīta atpakaļ pa pastu.

*Process no zvanīšanas līdz līguma parakstīšanai parasti ilgst ne vairāk kā 1-2 dienas.

Pēc līguma parakstīšanas un elektronisko skenēto kopiju apmaiņas klients iemaksā avansu, kura apmērs parasti ir 50% no kopējās līguma summas.

Pēc avansa maksājuma saņemšanas un priekšmeta analīzes veikšanas sākas izstrādes un apstiprināšanas posms darba uzdevums (TOR), kur ir noteiktas visas prasības izstrādātajai vietnei, dotas shēmas un izveidots detalizēts visas vietnes prototips. TK ir obligāts līguma pielikums, ko apstiprinājušas abas puses un parakstīts tāpat kā līgums.

* Jāsaprot, ka darba uzdevums ir ļoti svarīgs dokuments gan darbu izpildītājam, gan pasūtītājam. Tas ļauj kvalitatīvi un laikā izstrādāt un izpildīt interneta projektu.

Pēc visu prasību apstiprināšanas klients tiek nosūtīts nepieciešamo teksta un grafisko materiālu saraksts, kas pasūtītājam jānodrošina pirms izstrādes posma uzsākšanas (t.i., būvuzņēmēja projekta maketa izstrādes laikā pasūtītājs savāc un nodrošina visus nepieciešamos materiālus). Šajā sarakstā var būt: uzņēmuma apraksts, ar ko viņi sadarbojas, kādi apbalvojumi un sertifikāti viņiem ir, cenas un cenrāži, preču katalogs un preču apraksts, pakalpojumu apraksts, vietnē publicētā kontaktinformācija utt.

Dažkārt klientam pašam ir grūti aprakstīt savus pakalpojumus vai vienkārši tam neatliek laika. Šajā gadījumā darbuzņēmējs ir gatavs pabeigt darbu pie vietnes trūkstošā satura rakstīšanas (attēli, teksti, video utt.).

* Klienta nodrošināšana ar nepieciešamajiem materiāliem ir ļoti svarīga, jo:

ir nepieciešams pareizi ievadīt visu klienta sniegto saturu vietnes izkārtojumā uzreiz (nav jēgas veikt papildu darbu);
izpildītāja tehnoloģiskais process tiek plānots burtiski "pa minūtei" un mēs nevēlamies to pārkāpt un radīt papildu izmaksas;
aizpildīt interneta projektu ar testa informāciju arī nav jēgas (pirmkārt, atkal palielinās nevajadzīgā darba apjoms; otrkārt, meklētājprogrammas var pesimizēt mitinātu vietni ar testa saturu; treškārt, jūsu potenciālajiem klientiem var būt negatīva attieksme pret vietni, kas satur acīmredzami nederīgu informāciju);
Gan jums, gan mums ir svarīgi projektu pabeigt profesionāli un laikā.

* Cienījamie klienti, lūdzu, neaizkavējiet savas vietnes izstrādi un gūstiet no tās peļņu. Sniedziet saturu laikā! Pretējā gadījumā projekts tiks iesaldēts, līdz mēs saņemsim informāciju no jums, un attiecīgi tiks pārcelts vietnes iesniegšanas termiņš. Ja nav laika vākt un rakstīt informāciju, pasūtīt rakstīšanas tekstus un fotoattēlu apstrādi mums, tas ir lēti.

Paralēli tam tiek izveidota darba grupa projektam un sākas posms dizaina izkārtojuma izstrāde nākotnes vietne.
Pēc dizaina maketa gatavības tas tiek nosūtīts pasūtītājam apstiprināšanai. Pēc apstiprināšanas makets kļūst par derīgu dizainu.

* Atkarībā no projekta sarežģītības klientam var tikt nodrošināta pieeja projektu vadības sistēmai (piemēram, Redmine), kurā var augšupielādēt nepieciešamos projekta resursus, sekot līdzi izstrādes posmiem un publicēt komentārus.

Turpmākai darba turpināšanai obligāti jāsaņem no pasūtītāja visi nepieciešamie materiāli, kuru saraksts pasūtītājam tika nosūtīts agrāk.

Tiklīdz tiek saņemti trūkstošie materiāli. Svarīgs vietnes izstrādes posms saskaņā ar apstiprināto TOR.
Šis posms ietver lielu skaitu darbu veidu: tas ir vietņu izkārtojumu pārrobežu izkārtojums, nepieciešamo dizaina veidņu izstrāde izvēlētajai satura pārvaldības sistēmai (CMS), pašas CMS uzstādīšana un konfigurēšana, nepieciešamā uzstādīšana. moduļi un komponenti, trūkstošo moduļu izstrāde, visaptveroša vietnes darbības algoritmu izpēte, vietnes piepildīšana ar saturu, projekta izvietošana tehniskajā jomā un pāreja uz testēšanu.

Interneta projekta testēšanu veic darbuzņēmēja speciālisti, visas kļūdas un komentāri tiek novērsti, vietne tiek pieskaņota darbam.

Tiklīdz darbs ir pabeigts un vietnes testēšana tehniskajā jomā ir pabeigta, nodošanas posms. Šeit no pasūtītāja puses tiek pārbaudīta TOR prasību izpilde un viss interneta projekta darbības process.
Pēc tam, kad klients ir pieņēmis lēmumu par vietnes pilnīgu atbilstību TOR prasībām, vietne tiek nodota klientam un projekts tiek publicēts hostingā.

Rezultāts un apliecinājums par darbu nodošanu un pieņemšanu ir darba vieta un pieņemšanas akts, ko paraksta abas puses. Parakstīts akts kopā ar visu grāmatvedības dokumentu komplektu tiek nosūtīts pa pastu.

Pēc pieņemšanas akta parakstīšanas pasūtītājs saskaņā ar līgumu apmaksā atlikušās darba izmaksas.

Pēc galīgā aprēķina, kopā ar dokumentiem un vietni, klients saņem lietotāja rokasgrāmatu, vietnes kopija DVD formātā un bezmaksas tehniskā palīdzība 2-4 nedēļu laikā no vietnes pieņemšanas dienas.

Šajā diagrammā mēs centāmies pilnībā atspoguļot visus mijiedarbības aspektus no sākotnējā uzaicinājuma līdz projekta piegādei. Vienkāršos projektos dažas darbības var apvienot vai izlaist. Bet jebkurā gadījumā viss ir atspoguļots līgumā.

Pakalpojumu "Visaptveroša mājas lapas izstrāde", kā arī "Mājas lapas popularizēšana" darba shēma strukturāli atkārto iepriekš aprakstīto mijiedarbības procesu starp pasūtītāju un darbuzņēmēju un tāpēc neprasa detalizētu aprakstu.

Mēs ceram, ka aprakstītā mijiedarbības shēma ir pārskatāma un saprotama. Ja jums joprojām ir jautājumi, lūdzu

Projekts:	Elektroniskā kataloga vaicājumu sadalījums pēc meklēšanas indeksiem un meklēšanas vienumiem
Projekta apjoms:	13.02.2006 - 05.06.2006
Klients:	Petrozavodskas Valsts universitātes Zinātniskā bibliotēka.
Atbildīgais:	Gorškova Gaļina Anatoljevna, Dokumentu datorizētās apstrādes un katalogu veidošanas nodaļas vadītāja. E-pasts pasts: . Vergs. tālr.: 719602. Bibliotēka: kab. 102. Gurjevs Dmitrijs Borisovičs, RCNIT vadošais programmētājs. E-pasts pasts: . Vergs. tālr.: 784775. Interneta centrs.
Instruktors:	Kulakovs Kirils Aleksandrovičs E-pasts: . Biroja tālrunis: 711015. 215. kab
Informācija pasniedzējam:	Grupas numurs 13
Saistītie dokumenti:	Projekta pārskats Projekta plāna darba grafiks (Ganta diagramma) Prasības Specifikācija Dizains Tests Ieviešanas dokuments Pārbaudes dokuments Customer Engagement Developer Relations Reports Attīstības progresa glosārijs Lietotāja rokasgrāmata

Pirmā tikšanās ar klientu.

Pirmajā tikšanās reizē izstrādes komanda tika iepazīstināta ar klientu. Savukārt pasūtītājs stāstīja par PetrSU zinātnisko bibliotēku.

Bibliotēka darbojas uz automatizētās sistēmas "Foliant" bāzes. Elektroniskais katalogs ir daļa no bibliotēku sistēmas. Kataloga meklēšana tiek veikta, izmantojot vaicājumus. Operators ģenerē meklēšanas virknes, kas var saturēt lielu skaitu meklēšanas indeksu un meklēšanas vienumu. Katrs pieprasījums tiek ierakstīts žurnāla tabulā. Šajā tabulā ir dati par pieprasījuma laiku, klienta adresi, kurš veicis pieprasījumu, pašu pieprasījumu, pieprasījuma rezultātu.

Klientam pastāvīgi jāuzrauga žurnāla tabula un jāsniedz statistika par meklēšanas indeksu izmantošanu.

Tika prezentētas arī sākotnējās prasības īstenojamajam projektam. Viena no prasībām ir efektīva statistikas apkopošana. Tas ir, statistika ir jāparāda pēc saprātīga laika pēc pieprasījuma nosūtīšanas. Šīs prasības dēļ izstrādātāji tika mudināti izmantot servera puses procedūras PL/SQL.

Otrā tikšanās ar klientu.

Klients izstrādātājiem piešķīra pieteikumvārdu un paroli, lai iekļūtu elektronisko katalogu sistēmā, nodrošinot darbam divu tabulu kopijas - žurnāla tabulas un meklēšanas indeksu tabulas.

Gurjevs Dmitrijs Borisovičs mūs detalizētāk iepazīstināja ar darbu Oracle SQL*Plus DBMS klientā. Komanda iepazinās ar elektroniskā kataloga darbu.

Sistēma "Foliant" darbojas, pamatojoties uz RusMark standartu, kurā ir aptuveni 99 lauki. Katra bibliotēka, kas strādā ar AIBS "Foliant", atlasa laukus un apakšlaukus, kurus tā izmantos. Ir īpaši GOST, kas apraksta bibliotēkas datu glabāšanas noteikumus. Tā kā lauku ir liels skaits, mēs izveidojām meklēšanas indeksu sistēmu. Ir pakalpojumu un publiskie indeksi.

Direktoriju lietotāji ir sadalīti iekšējos un ārējos. Katrai nodaļai vai darbiniekam ir piešķirtas savas tiesības. Katrs ieraksts par objektu tiek parsēts atsevišķos elementos un netiek saglabāts kā veselums.

Trešā tikšanās ar klientu.

Klients mums rakstiski ir norādījis skaidras prasības.

Klientu interesē šāda statistika:

Pieprasījumu skaits elektroniskajam katalogam.

Par pēdējo mēnesi pa dienām.
Ikmēneša uzskaite par kārtējo gadu.
Grāmatvedība pa gadiem.
Izveidojiet informācijas vēsturi.

Pieprasījumu saraksts pēc katram meklēšanas rādītājs, kurā meklēšanas rezultāts bija nulle.

Bieži sastopamo pieprasījumu saraksts.

Pieprasījumu izpildes analīze noteiktā laika posmā. Ziņojumā jāiekļauj šāda statistika:

Pieprasījumu skaits.
Uzmeklēšanas pieprasījumu skaits.
Sarežģītu vaicājumu skaits.
Veiksmīgo atbilžu skaits.
Nulles atbilžu skaits.
Autors
Autors rev. prod.
Dokumenta veids.
Ģeogrāfiskā sadaļa.
Ievadiet datumu.
Publicēšanas datums.
Nosaukums.

Ceturtā tikšanās ar klientu.

Speciālists no klienta Guryev D.B. paskaidroja SQL*Plus utilīta instalēšanas un konfigurēšanas sarežģītību. Programmas palaišanas problēmas risinājums bija SQL * Net pakotnes instalēšana, arī Guryev D.B. sniedza izstrādātājiem precīzus tabulu nosaukumus, kā arī pievienoja vēl vienu tabulu, kas bija komandas rīcībā. Speciālists izpētīja arhitektūras dokumentu un ierosināja praktiski realizēt visu veidu arhitektūru un izvēlēties optimālāko. Tajā pašā laikā žurnālu - tabulu vēlams nepārbūvēt un, cik vien iespējams, risinot kādu konkrētu problēmu, vispārināt datus no žurnāla - tabulas tālākai izmantošanai dažādās vietējā statistikā.

Klients Gorškova G.A. iepazinās ar prasību dokumentu, tos apstiprinot.

Piektā tikšanās ar klientu.

Klienta speciālists Gurjevs Dmitrijs Borisovičs tika uzaicināts PetrSU apmācības serverī instalēt programmatūru, kas nepieciešama darbam ar "Oracle" DBVS. Šajā procesā no universitātes puses bija iesaistīts arī Vadims Anatoļjevičs Ponomarevs, kuram ir administratīvā piekļuve PetrSU serverim.