Interacțiunea internă cu clientul în timpul proiectării. Client și Antreprenor - relațiile ca bază pentru succesul proiectului

Etapele generale ale interacțiunii cu clientul sunt următoarele puncte:

- Comunicare preliminară cu clientul: identificarea scopurilor și obiectivelor proiectului, identificarea principalelor cerințe pentru viitorul sistem, cunoașterea prealabilă cu firma Clientului, evaluarea prealabilă a calendarului și costului proiectului, pregătirea și transferul Ofertei Comerciale către client.
- Sondaj detaliat și colectarea cerințelor clienților: determinarea componenței echipei de proiect, colectarea cerințelor pentru sistem, intervievarea utilizatorilor cheie și specialiștilor tehnici ai Clientului, elaborarea și aprobarea Termenilor de referință.
- Dezvoltarea și testarea sistemului: după dezvoltarea sistemului sau a unei anumite părți din funcționalitatea acestuia, se efectuează o demonstrație către Client. Urmează etapa de detectare și eliminare a erorilor, dacă nu există, teste de acceptare.
- Funcționare de probă a sistemului: implementarea sistemului pe partea Clientului, instruirea utilizatorilor, colectarea de comentarii și sugestii pentru îmbunătățirea sistemului, eliminarea comentariilor.
- Operarea industriala a sistemului: operare independenta de catre Client, contactarea serviciului de suport al Companiei (daca este necesar), colectarea dorintelor pentru dezvoltarea sistemului.

O formă importantă de interacțiune cu clientul este documentația dezvoltată în timpul implementării proiectului, în conformitate cu cerințele GOST 34 și RUP.

Se formează grupuri de lucru pentru sarcini specifice proiectului. Sincronizarea acțiunilor se realizează prin consiliul delegaților din grupurile de lucru. Membrii grupurilor de lucru dezvoltă în mod independent principiile interacțiunii în grup. Grupurile pot implica membrii altor grupuri în rezolvarea problemelor. Forme de succes de interacțiune atât în cadrul grupurilor, cât și între grupuri pot fi adoptate de noii participanți la proiect

Lumea a recunoscut de mult timp că managementul proiectelor este un domeniu special de management, a cărui aplicare dă rezultate tangibile. Profesioniștii din acest domeniu sunt foarte apreciați (în SUA este a treia profesie cel mai bine plătită după avocați și medici), iar metodologia de management de proiect în sine a devenit standardul de management de facto în multe mii de întreprinderi și este folosită în diferite grade în aproape toate marile corporaţii. Anul trecut, au fost adoptate standardele ANSI de management de proiect și a fost elaborat un proiect de standarde de management de proiect ISO 10006.

Astăzi, procesul de creare a aplicațiilor software complexe nu poate fi imaginat fără împărțirea în etape ale ciclului de viață. Prin ciclul de viață al programului, ne referim la setul de etape:

Analiza domeniului subiect și realizarea specificațiilor tehnice (interacțiunea cu clientul)
Proiectarea structurii programului
Codare (un set de coduri de program conform documentației proiectului)
Testare și depanare
Implementarea programului
Suport program
Eliminare

Să aruncăm o privire mai atentă asupra procesului de proiectare. În timpul procesului de proiectare, un arhitect sau un programator experimentat creează documentația proiectului, inclusiv descrieri textuale, diagrame și modele ale viitorului program. În această problemă dificilă, limbajul UML ne va ajuta.

UML este un limbaj grafic pentru vizualizare, descrierea parametrilor, proiectarea și documentarea diferitelor sisteme (în special programe). Diagramele sunt create folosind instrumente speciale CASE, cum ar fi Rational Rose (http://www-01.ibm.com/software/rational/) și Enterprise Architect (http://www.sparxsystems.com.au/). Un singur model de informare este construit pe baza tehnologiei UML. Instrumentele CASE de mai sus sunt capabile să genereze cod în diferite limbaje orientate pe obiect și au, de asemenea, o caracteristică de inginerie inversă foarte utilă. (Ingineria inversă vă permite să creați un model grafic din codul programului existent și să faceți comentarii la acesta.)

Luați în considerare tipurile de diagrame pentru vizualizarea modelului (acestea sunt elemente obligatorii, deși există mai multe tipuri):

Diagrama de caz de utilizare

Sistemul proiectat este reprezentat ca un set de entități sau actori care interacționează cu sistemul folosind așa-numitele precedente. În acest caz, un actor (actor) sau un actor este orice entitate care interacționează cu sistemul din exterior. Cu alte cuvinte, fiecare caz de utilizare definește un anumit set de acțiuni pe care sistemul le realizează atunci când vorbește cu un actor. În același timp, nu se spune nimic despre modul în care va fi implementată interacțiunea actorilor cu sistemul.

Diagrama de clasă (diagrama de clasă)

Diagrama de clase servește la reprezentarea structurii statice a modelului de sistem în terminologia claselor de programare orientată pe obiecte. O diagramă de clasă poate reflecta, în special, diverse relații între entitățile individuale ale domeniului subiectului, cum ar fi obiecte și subsisteme, și, de asemenea, descrie structura lor internă (câmpuri, metode ...) și tipuri de relații (moștenire, implementare de interfețe). ..). Această diagramă nu oferă informații despre aspectele de timp ale funcționării sistemului. Din acest punct de vedere, diagrama de clase este o dezvoltare ulterioară a modelului conceptual al sistemului proiectat. În această etapă, cunoașterea abordării POO și a modelelor de proiectare este esențială.

Diagrama de stare (diagrama de stat)

Scopul principal al acestei diagrame este de a descrie posibilele secvențe de stări și tranziții care caracterizează împreună comportamentul unui element model în timpul ciclului său de viață. Diagrama de stări reprezintă comportamentul dinamic al entităților, pe baza precizării răspunsului acestora la percepția unor evenimente specifice.

Diagrama secvenței

Diagramele de interacțiune adecvate sunt folosite pentru a modela interacțiunea obiectelor în limbajul UML. Interacțiunile obiectelor pot fi luate în considerare în timp, iar apoi o diagramă de secvență este utilizată pentru a reprezenta momentul transmiterii și recepționării mesajelor între obiecte. Obiectele care interacționează fac schimb de informații unele cu altele. În acest caz, informațiile iau forma unor mesaje complete. Cu alte cuvinte, deși mesajul are conținut informațional, el capătă proprietatea suplimentară de a exercita o influență direcționată asupra destinatarului său.

Diagrama de colaborare

În diagrama cooperării, obiectele care participă la interacțiune sunt reprezentate sub formă de dreptunghiuri, care conțin numele obiectului, clasa acestuia și, eventual, valorile atributelor. Ca și în diagrama de clasă, asocierile dintre obiecte sunt indicate sub formă de diferite linii de legătură. În acest caz, puteți specifica în mod explicit numele asociației și rolurile pe care obiectele le joacă în această asociere.
Spre deosebire de diagrama de secvență, o diagramă de colaborare descrie doar relațiile dintre obiecte care joacă anumite roluri într-o interacțiune.

Diagrama componentelor

Diagrama componentelor, spre deosebire de diagramele discutate anterior, descrie caracteristicile reprezentării fizice a sistemului. Diagrama componentelor vă permite să determinați arhitectura sistemului în curs de dezvoltare prin stabilirea dependențelor între componentele software, care pot fi cod sursă, binar și executabil. În multe medii de dezvoltare, un modul sau componentă corespunde unui fișier. Săgețile punctate care conectează modulele arată relații de dependență similare cu cele care apar la compilarea codului sursă al programului. Elementele grafice principale ale unei diagrame de componente sunt componentele, interfețele și dependențele dintre ele.

Diagrama de implementare

Diagrama de implementare este concepută pentru a vizualiza elementele și componentele programului care există doar în stadiul execuției acestuia (runtime). În acest caz, sunt prezentate numai componentele instanței de program care sunt fișiere executabile sau biblioteci dinamice. Acele componente care nu sunt utilizate în timpul execuției nu sunt afișate în diagrama de implementare.
O diagramă de implementare conține reprezentări grafice ale procesoarelor, dispozitivelor, proceselor și relațiilor dintre ele. Spre deosebire de diagramele de reprezentare logică, diagrama de implementare este aceeași pentru sistemul în ansamblu, deoarece trebuie să reflecte pe deplin caracteristicile implementării sale. Această diagramă completează în esență procesul OOAP pentru un anumit sistem software, iar dezvoltarea sa este de obicei ultimul pas în specificarea modelului.

Aceasta încheie prezentarea noastră de ansamblu asupra diagramelor în special și a designului în general. Este demn de remarcat faptul că procesul de proiectare a devenit de mult un standard de dezvoltare software, dar de multe ori trebuie să aveți de-a face cu un program frumos scris, care, din cauza lipsei unei documentații adecvate, capătă funcționalități laterale inutile, cârje, devine greoaie și își pierde calitatea anterioară. =(

Sunt convins că un programator este în primul rând un codificator - NU trebuie să comunice cu clientul, NU ar trebui să se gândească la arhitectura sistemului, nu ar trebui să inventeze o interfață cu programul, ar trebui doar să codifice - să implementeze algoritmi, funcționalitate, aspect, utilizare, dar nu mai mult... Proiectantul, pornind de la diagrame abstracte (care descriu domeniul) până la diagrame care reprezintă structura datelor, clasele și procesele interacțiunii lor, trebuie să descrie totul pas cu pas în detaliu. Adică, complexitatea muncii și salariul unui designer ar trebui să fie cu un ordin de mărime mai mare decât cel al unui programator == coder. Imi pare rau pentru dezvatare....

1.1. Interacțiunea cu clienții (funcții principale)

1.1.1. Căutare de comandă

7.2.3.1. Pentru informatii despre produs

1.1.2. Lucru precontractual cu Clientul

Documente de reglementare

2.2.1.2.1. Lucru precontractual cu Clientul STP-1-01

Cerințe ale sistemului de management al calității ISO9000:2000 Clauza 7

7.2.1.1. Cerințele clienților pentru produse, inclusiv cerințele privind disponibilitatea, livrarea și întreținerea

7.2.2.4. Determinarea capacității de a realiza respectarea anumitor cerințe

// Analiza cerințelor produsului / Procese legate de consumator / VANZARE DE PRODUSE

1.1.3. Formarea Termenilor de Referință

Documente de reglementare

2.2.1.2.2. Procedura de analiză și încheiere a contractului STP-2-01 // Standardele Întreprinderii Ellat (STP) / Documente ale sistemului de management al calității / Documente de reglementare interne / Regulamente

Cerințe ale sistemului de management al calității ISO9000:2000 Clauza 7

7.2.1.2. Cerințe nespecificate de client, dar necesare pentru utilizarea prevăzută sau specificată // Definirea cerințelor clienților / Procese legate de clienți / VÂNZĂRI DE PRODUSE

7.2.1.3. Obligații legate de produs, inclusiv cerințe obligatorii și prevederi legale // Definirea cerințelor clienților / Procese legate de clienți / VÂNZĂRI DE PRODUSE

// Analiza cerințelor produsului / Procese legate de consumator / VANZARE DE PRODUSE

7.2.2.2. Confirmarea cerințelor consumatorului înainte de acceptarea acestora, dacă consumatorul nu furnizează o declarație scrisă a cerințelor // Analiza cerințelor produsului / Procese legate de consumator / VANZARE DE PRODUSE

7.2.2.3. Clarificarea modificărilor cerinţelor contractului sau comenzii care diferă de cele transmise anterior (de exemplu, prin licitare sau linkuri) // Analiza cerințelor produsului / Procese legate de consumator / VANZARE DE PRODUSE

7.3.1.1. Determinarea etapelor proceselor de proiectare și/sau dezvoltare

7.3.2.2. Cerințe legale și de reglementare aplicabile

7.3.2.3. Date aplicabile derivate din evoluții anterioare similare // Date de intrare pentru proiectare și dezvoltare / Proiectare și dezvoltare / VÂNZĂRI DE PRODUSE

7.3.2.4. Alte cerințe importante pentru proiectare și dezvoltare // Date de intrare pentru proiectare și dezvoltare / Proiectare și dezvoltare / VÂNZĂRI DE PRODUSE

7.3.4.1. Evaluarea capacității de a îndeplini cerințele

1.1.4. Încheierea Acordurilor

Documente de reglementare

2.2.1.2.3. Reglementări privind munca contractuală cu Clientul (STP-3-01) // Enterprise Standards Ellat (STP) / Documente ale sistemului de management al calității / Documente de reglementare interne / Regulamente

1.1.5. Monitorizarea indeplinirii obligatiilor contractuale

Documente de reglementare

2.2.1.2.3.2. Procedura pentru analizarea modificărilor și efectuarea modificărilor la Documentele Contractuale // Reglementări privind munca contractuală cu Clientul (STP-3-01) / Standardele întreprinderii Ellat (STP) / Documente ale sistemului de management al calității / Documente de reglementare interne / Regulamente

2.2.1.2.4.1. Procedura de tratare a reclamațiilor și reclamațiilor Clientului

2.2.1.2.4.2. Procedura de eliminare a comentariilor Clientului // Reglementări privind acțiunile corective și preventive (STP-4-01) / Ellat Enterprise Standards (STP) / Documente privind sistemul de management al calității / Documente de reglementare interne / Regulamente

Cerințe ale sistemului de management al calității ISO9000:2000 Clauza 7

7.2.3.2. Procesarea cererilor, contractelor, comenzilor, inclusiv modificărilor // Comunicare cu consumatorul / Procese legate de consumator / VANZARE DE PRODUSE

1.2. Programarea lucrărilor la proiect (funcții principale)

1.2.1. Clarificarea compoziției complexului și domeniului de dezvoltare

Documente de reglementare

// Enterprise Standards Ellat (STP) / Documente ale sistemului de management al calității / Documente de reglementare interne / Regulamente

Cerințe ale sistemului de management al calității ISO9000:2000 Clauza 7

7.2.2.1. Definirea cerințelor produsului // Analiza cerințelor produsului / Procese legate de consumator / VANZARE DE PRODUSE

1.2.2. Planificarea Asigurarii Calitatii Proiectului

Documente de reglementare

2.2.1.2.5. Compoziția și procedura pentru elaborarea unui program de asigurare a calității proiectului (STP-5-01) // Enterprise Standards Ellat (STP) / Documente ale sistemului de management al calității / Documente de reglementare interne / Regulamente

Cerințe ale sistemului de management al calității ISO9000:2000 Clauza 7

7.1.1. Stabilirea obiectivelor de calitate pentru un produs, proiect sau contract

7.1.3. Definirea activităților de revizuire și aprobare și a criteriilor de acceptare // Planificarea proceselor de vânzare / VÂNZAREA PRODUSELOR

7.2.2.5. Fixarea rezultatelor analizei și acțiunilor ulterioare de urmărire (a se vedea clauza 5.5.7) // Analiza cerințelor produsului / Procese legate de consumator / VANZARE DE PRODUSE

7.3.1.2. Definirea activităților de revizuire, verificare și aprobare pentru fiecare etapă de proiectare și/sau dezvoltare // Proiectare și planificare dezvoltare / Proiectare și dezvoltare / VÂNZĂRI DE PRODUSE

1.2.3. Formarea specificațiilor tehnice private pentru dezvoltarea componentelor complexului

Documente de reglementare

2.2.1.2.7. Tehnologia de implementare a proiectelor. Etape și ordine de lucru (STP-7-01) // Enterprise Standards Ellat (STP) / Documente ale sistemului de management al calității / Documente de reglementare interne / Regulamente

1.2.4. Planificarea proiectului

Documente de reglementare

// Enterprise Standards Ellat (STP) / Documente ale sistemului de management al calității / Documente de reglementare interne / Regulamente

Cerințe ale sistemului de management al calității ISO9000:2000 Clauza 7

7.1.2. Determinarea necesității de stabilire a proceselor și documentației, asigurarea resurselor și infrastructurii specifice produsului // Planificarea proceselor de vânzare / VÂNZAREA PRODUSELOR

1.2.5. Coordonarea si controlul operational al performantei muncii

Documente de reglementare

2.2.1.2.4.3. Procedura de acțiune corectivă // Reglementări privind acțiunile corective și preventive (STP-4-01) / Ellat Enterprise Enterprise Standards (STP) / Documente privind sistemul de management al calității / Documente de reglementare interne / Regulamente

2.2.1.2.6. Regulamentul privind planificarea muncii (STP-6-01) // Enterprise Standards Ellat (STP) / Documente ale sistemului de management al calității / Documente de reglementare interne / Regulamente

Cerințe ale sistemului de management al calității ISO9000:2000 Clauza 7

7.3.4.2. Identificarea problemelor și elaborarea propunerilor de acțiuni ulterioare // Analiză proiectare și dezvoltare / Proiectare și dezvoltare / PRODUCT MAILING

7.3.7. Managementul schimbării proiectării și dezvoltării

1.3. Dezvoltare de proiectare, software și documentație operațională (funcții principale)

1.3.1. Elaborarea documentației pentru hardware-ul complexului

Documente de reglementare

2.3.3.3. Plan de lucru pentru departamentul de dezvoltare și producție hardware

1.3.2. Dezvoltarea componentei software a complexului

Documente de reglementare

2.3.3.4. Plan de lucru pentru departamentul de dezvoltare și producție software // Programe și planuri de acțiune / Documente organizatorice și administrative ale companiei / Regulamente

1.3.4. Analiza si aprobarea rezultatelor proiectarii

Documente de reglementare

Cerințe ale sistemului de management al calității ISO9000:2000 Clauza 7

7.3.3.1. Conform cerințelor de intrare de proiectare și dezvoltare

7.3.3.2. Furnizați informații adecvate pentru operațiunile de producție și service (vezi 7.5) // Proiectare și dezvoltare / Proiectare și dezvoltare / PRODUCT MAILING

7.3.3.4. Determinați caracteristicile produsului care sunt esențiale pentru utilizarea în siguranță și corectă a acestuia. // Proiectare și dezvoltare / Proiectare și dezvoltare / PRODUCT MAILING

7.3.5.1. Conformitatea datelor de ieșire cu cerințele de intrare // Verificare proiectare și dezvoltare / Proiectare și dezvoltare / VÂNZARE PRODUSE

7.3.6. Aprobarea rezultatelor de proiectare și dezvoltare // Proiectare și dezvoltare / PRODUSE DE VÂNZARE

Educație, Dezvoltare, Instruire

Cuvinte cheie:

1 -1

Luați în considerare schema completă de interacțiune cu clientul pe exemplul dezvoltării site-ului web. Grafic, etapele interacțiunii pot fi reprezentate în următoarea figură:

Primar este apel sau e-mail, care sunt procesate de managerul de cont. Managerul vorbește despre serviciile companiei Beehive, dă răspunsuri la toate întrebările de interes și explică clientului procesul de interacțiune ulterioară.

* Este de remarcat faptul că clientului i se alocă un manager personal pentru întreaga perioadă a proiectului său, care este gata să răspundă la toate întrebările și să ajute la rezolvarea tuturor problemelor.

În continuare, managerul ajută la finalizare formă scurtă pentru dezvoltarea unui site web care să conțină întrebările clarificatoare necesare pe tema cooperării și să adauge un contact la sistemul intern CRM (Customer Relationship Management System).

Datele sunt introduse în sistem pentru a stoca în siguranță toate datele necesare clienților și pentru a asigura dezvoltarea calitativă a site-ului în ansamblu.

Pe baza briefului completat, specialistii Beehive se pregatesc oferta comerciala individuala cu o descriere a timpului și a costului lucrării, iar managerul o trimite clientului spre considerare.

Urmează procesul de acordare a condițiilor de cooperare, al cărui rezultat este tratat. Pentru a accelera începerea lucrărilor, contractul este semnat de ambele părți, iar părțile schimbă copii scanate ale contractului. Originalele contractului se trimit prin scrisoare recomandată (în continuare, toate copiile pe hârtie sunt schimbate prin poștă sau curier). După ce partea primește originalul pe hârtie, un exemplar este trimis înapoi prin poștă.

*Procesul de la apel până la semnarea contractului nu durează, de obicei, mai mult de 1-2 zile.

După semnarea contractului și schimbul de copii electronice scanate, clientul plătește un avans, a cărui sumă este de obicei de 50% din valoarea totală a contractului.

După primirea unei plăți în avans și efectuarea unei analize a domeniului subiectului, începe etapa de dezvoltare și aprobare termeni de referință (TOR), unde sunt prescrise toate cerințele pentru site-ul în curs de dezvoltare, sunt date scheme și este creat un prototip detaliat al întregului sit. TK este o anexă obligatorie la contract, aprobată de ambele părți și semnată în același mod ca și contractul.

* Trebuie inteles ca termenii de referinta sunt un document foarte important atat pentru antreprenor cat si pentru client. Vă permite să proiectați și să executați un proiect Internet de înaltă calitate și la timp.

După ce toate cerințele sunt aprobate, clientul este trimis lista de materiale text și grafice necesare, pe care clientul trebuie să le furnizeze înainte de începerea etapei de dezvoltare (adică în timpul dezvoltării planului de proiectare de către antreprenor, clientul colectează și furnizează toate materialele necesare). Această listă poate include: o descriere a companiei, cu cine cooperează, ce premii și certificate au, prețuri și liste de prețuri, un catalog de produse și descrierea mărfurilor, o descriere a serviciilor, informații de contact publicate pe site etc.

Uneori este dificil pentru client să-și descrie singur serviciile sau pur și simplu nu are timp pentru asta. În acest caz, antreprenorul este pregătit să finalizeze lucrările de scriere a conținutului lipsă pentru site (imagini, texte, videoclipuri etc.).

* Furnizarea clientului cu materialele necesare este esențială deoarece:

este necesar să introduceți corect tot conținutul furnizat de client în aspectul site-ului simultan (nu are sens să faceți muncă suplimentară);
procesul tehnologic al interpretului este programat literal „cu minut” și nu dorim să-l încălcăm și să suportăm costuri suplimentare;
completarea unui proiect de internet cu informații de testare nu are nici un sens (în primul rând, cantitatea de muncă inutilă crește din nou; în al doilea rând, motoarele de căutare pot pesimiza un site găzduit cu conținut de testare; în al treilea rând, clienții potențiali pot avea o atitudine negativă față de site, ceea ce conține informații în mod evident inutile);
Este important atât pentru tine, cât și pentru noi să finalizezi proiectul profesional și la timp.

* Dragi clienți, vă rugăm să nu întârziați dezvoltarea propriului site și să profitați de el. Furnizați conținut la timp! În caz contrar, proiectul va fi înghețat până când vom primi informații de la dumneavoastră și, în consecință, termenul limită de depunere a site-ului a fost amânat. Dacă nu avem timp să colectăm și să scrieți informații, să ne comandați texte de scriere și să procesați fotografii, este ieftin.

În paralel, se creează un grup de lucru pentru proiect și începe etapa dezvoltarea layout-ului de proiectare viitorul site.
După ce aspectul de proiectare este gata, acesta este trimis clientului pentru aprobare. Odată aprobată, macheta devine un design valabil.

* În funcție de complexitatea proiectului, clientului i se poate oferi acces la sistemul de management al proiectelor (de exemplu, Redmine), unde puteți încărca resursele necesare pentru proiect, puteți monitoriza etapele de dezvoltare și puteți publica comentarii.

Pentru continuarea lucrărilor, este obligatoriu să primiți de la client toate materialele necesare, a căror listă a fost trimisă clientului anterior.

Imediat ce materialele lipsă sunt primite. Un important etapa de dezvoltare a site-uluiîn conformitate cu TOR aprobat.
Această etapă include un număr mare de tipuri de lucrări: aceasta este un aspect cross-browser a layout-urilor site-ului, dezvoltarea șabloanelor de proiectare necesare pentru sistemul de management al conținutului (CMS) selectat, instalarea și configurarea CMS-ului în sine, instalarea necesarului module și componente, dezvoltarea modulelor lipsă, un studiu cuprinzător al algoritmilor de funcționare a site-ului web, completarea site-ului cu conținut, implementarea proiectului pe domeniul tehnic și trecerea la testare.

Testarea proiectului Internet este efectuată de specialiștii contractorului, toate erorile și comentariile sunt eliminate, site-ul este ajustat pentru funcționare.

Imediat ce lucrarea este finalizată și testarea site-ului pe domeniul tehnic este finalizată, etapa de predare. Aici, din partea clientului, se verifică îndeplinirea cerințelor TOR și întregul proces de funcționare a proiectului Internet.
După ce clientul ia o decizie cu privire la conformitatea deplină a site-ului cu cerințele TOR, site-ul este transferat clientului și proiectul este publicat pe hosting.

Rezultatul și confirmarea livrării și recepției lucrărilor este un șantier funcțional și un act de acceptare, care este semnat de ambele părți. Actul semnat, împreună cu întregul set de documente pentru contabilitate, se transmite prin poștă.

După semnarea certificatului de recepție, clientul, în conformitate cu contractul, plătește costul rămas al lucrării.

După calculul final, împreună cu documentele și site-ul web, clientul primește un manual de utilizare, o copie a site-ului pe DVD si gratis suport tehnicîn termen de 2-4 săptămâni de la data acceptării site-ului.

În această diagramă, am încercat să reflectăm pe deplin toate aspectele interacțiunilor de la apelul inițial până la livrarea proiectului. Pentru proiecte simple, unii dintre pași pot fi combinați sau omisi. Dar, în orice caz, totul se reflectă în contract.

Schema de lucru pentru serviciile „Dezvoltare completă a site-ului web”, precum și „Promovarea site-ului” repetă structural procesul de interacțiune dintre client și antreprenor descris mai sus și, prin urmare, nu necesită o descriere detaliată.

Sperăm că schema de interacțiune descrisă este transparentă și de înțeles. Dacă mai aveți întrebări, vă rog

Proiect:	Distribuirea interogărilor către catalogul electronic prin indici de căutare și termeni de căutare
Domeniul proiectului:	13.02.2006 - 05.06.2006
Client:	Biblioteca științifică a Universității de Stat din Petrozavodsk.
Responsabil:	Gorshkova Galina Anatolyevna, șef al departamentului de prelucrare computerizată a documentelor și creare de cataloage. E-mail Poștă: . Sclav. tel.: 719602. Biblioteca: cab. 102. Guryev Dmitri Borisovich, programator principal al RCNIT. E-mail Poștă: . Sclav. tel.: 784775. Centru internet.
Instructor:	Kulakov Kiril Alexandrovici E-mail: . Telefon birou: 711015. Camera 215
Informații pentru instructor:	Grupa numărul 13
Documente relatate:	Prezentare generală a proiectului Planul proiectului Programul de lucru (diagrama Gantt) Cerințe Specificație Test de proiect Document de implementare Document de testare Angajamentul cu clienții Relații cu dezvoltatorii Rapoarte Evoluția dezvoltării Glosar Ghid de utilizare

Prima întâlnire cu clientul.

La prima întâlnire, echipa de dezvoltare a fost prezentată clientului. Clientul, la rândul său, a vorbit despre biblioteca științifică a PetrSU.

Biblioteca funcționează pe baza sistemului automatizat „Foliant”. Catalogul electronic face parte din sistemul bibliotecii. Căutarea în catalog se realizează folosind interogări. Operatorul generează șiruri de căutare care pot conține un număr mare de indici de căutare și termeni de căutare. Fiecare cerere este înregistrată într-un tabel de jurnal. Acest tabel conține date despre momentul solicitării, adresa clientului care a făcut cererea, cererea în sine, rezultatul solicitării.

Clientul trebuie să monitorizeze în mod constant tabelul de jurnal și să furnizeze unele statistici privind utilizarea indicilor de căutare.

Au fost prezentate și cerințele inițiale pentru proiectul în curs de implementare. Una dintre cerințe este compilarea eficientă a statisticilor. Adică, statisticile ar trebui să fie afișate după un timp rezonabil de la trimiterea cererii. Datorită acestei cerințe, dezvoltatorii au fost încurajați să utilizeze proceduri de pe server în PL/SQL.

A doua întâlnire cu clientul.

Clientul a oferit dezvoltatorilor un login și o parolă pentru a intra în sistemul de catalog electronic, oferind copii a două tabele pentru lucru - un tabel de jurnal și un tabel de indici de căutare.

Guryev Dmitry Borisovich ne-a familiarizat mai detaliat cu munca din clientul DBMS Oracle SQL*Plus. Echipa s-a familiarizat cu activitatea catalogului electronic.

Sistemul „Foliant” funcționează pe baza standardului RusMark, care conține aproximativ 99 de câmpuri. Fiecare bibliotecă care lucrează cu AIBS „Foliant” selectează câmpurile și subcâmpurile pe care le va folosi. Există GOST-uri speciale care descriu regulile de stocare a datelor din bibliotecă. Deoarece există un număr mare de câmpuri, am creat un sistem de indici de căutare. Există indicii de servicii și publici.

Utilizatorii directorului sunt împărțiți în interni și externi. Fiecărui departament sau angajat îi sunt atribuite propriile drepturi. Fiecare înregistrare despre un obiect este analizată în elemente separate și nu este stocată ca un întreg.

A treia întâlnire cu clientul.

Clientul ne-a furnizat cerințe clare în scris.

Clientul este interesat de următoarele statistici:

Numărul de solicitări către catalogul electronic.

Pentru ultima lună de zi.
Contabilitatea lunară pentru anul curent.
Contabilitatea pe ani.
Creați un istoric al informațiilor.

Lista cererilor de către Pentru fiecare index de căutare unde rezultatul căutării a fost nul.

Lista cererilor care apar frecvent.

Analiza executării cererilor pe o anumită perioadă. Raportul trebuie să includă următoarele statistici:

Numărul de cereri.
Numărul de solicitări de căutare.
Numărul de interogări complexe.
Numărul de răspunsuri reușite.
Numărul de răspunsuri nule.
Autor
Autor rev. prod.
Tip de document.
Secțiunea geografică.
Introduceți data.
Data publicării.
Titlu.

A patra întâlnire cu clientul.

Specialist de la clientul Guryev D.B. a explicat complexitățile instalării și configurării utilitarului SQL*Plus. Soluția la problema lansării programului a fost instalarea pachetului SQL * Net, tot Guryev D.B. a furnizat denumirile exacte ale tabelelor pentru dezvoltatori și a adăugat, de asemenea, un alt tabel la dispoziția echipei. Specialistul a studiat documentul de arhitectură și și-a propus să implementeze practic toate tipurile de arhitectură și să o aleagă pe cea mai optimă. În același timp, este de dorit să nu se reconstruiască jurnalul - tabel și, pe cât posibil, să se rezolve o problemă specifică, să se generalizeze datele din jurnalul - tabel pentru utilizare ulterioară în diverse statistici locale.

Clientul Gorshkova G.A. s-a familiarizat cu documentul de cerințe, după ce le-a aprobat.

A cincea întâlnire cu clientul.

Guryev Dmitry Borisovich, un specialist din partea clientului, a fost invitat să instaleze software-ul necesar pentru lucrul cu SGBD-ul „Oracle” pe serverul de instruire al PetrSU. Vadim Anatolyevich Ponomarev, care are acces administrativ la serverul PetrSU, a fost implicat în acest proces și din partea universității.