Interakcja wewnętrzna z klientem podczas projektowania. Klient i Wykonawca – relacje jako podstawa sukcesu projektu

Ogólne etapy interakcji z klientem to następujące punkty:

- Wstępna komunikacja z Klientem: określenie celów i zadań projektu, określenie głównych wymagań dla przyszłego systemu, wstępna znajomość z firmą Klienta, wstępna ocena terminu i kosztów projektu, przygotowanie i przekazanie Oferty Handlowej dla klienta.
- Szczegółowa ankieta i zbieranie wymagań Klienta: ustalenie składu zespołu projektowego, zebranie wymagań dla systemu, wywiady z kluczowymi użytkownikami i specjalistami technicznymi Klienta, opracowanie i zatwierdzenie SIWZ.
- Rozwój i testowanie systemu: po opracowaniu systemu lub pewnej części jego funkcjonalności przeprowadzana jest demonstracja dla Klienta. Potem następuje etap wykrywania i eliminacji błędów, jeśli ich nie ma, testy akceptacyjne.
- Próbna eksploatacja systemu: wdrożenie systemu po stronie Klienta, szkolenie użytkowników, zbieranie uwag i propozycji usprawnień systemu, eliminacja uwag.
- Przemysłowa eksploatacja systemu: niezależna eksploatacja przez Klienta, kontakt z działem wsparcia firmy (jeśli to konieczne), zbieranie życzeń dotyczących rozwoju systemu.

Ważną formą interakcji z klientem jest dokumentacja opracowana podczas realizacji projektu zgodnie z wymaganiami GOST 34 i RUP.

Tworzone są grupy robocze do konkretnych zadań projektowych. Synchronizacja działań odbywa się za pośrednictwem rady delegatów z grup roboczych. Członkowie grup roboczych samodzielnie opracowują zasady interakcji w grupie. Grupy mogą angażować członków innych grup w rozwiązywanie problemów. Skuteczne formy interakcji zarówno w grupach, jak i między grupami mogą zostać przyjęte przez nowych uczestników projektu

Świat od dawna uznał, że zarządzanie projektami to szczególny obszar zarządzania, którego zastosowanie daje wymierne efekty. Specjaliści w tej dziedzinie są wysoko cenieni (w USA jest to trzeci najlepiej płatny zawód po prawnikach i lekarzach), a sama metodologia zarządzania projektami stała się de facto standardem zarządzania w wielu tysiącach przedsiębiorstw i jest w różnym stopniu wykorzystywana w prawie wszystkie duże korporacje. W ubiegłym roku przyjęto standardy zarządzania projektami ANSI oraz opracowano projekt standardów zarządzania projektami ISO 10006.

Dziś nie można sobie wyobrazić procesu tworzenia złożonych aplikacji bez podziału na etapy cyklu życia. Pod cyklem życia programu mamy na myśli zestaw etapów:

Analiza tematu i tworzenie specyfikacji technicznych (interakcja z klientem)
Projekt struktury programu
Kodowanie (zestaw kodu programu zgodnie z dokumentacją projektową)
Testowanie i debugowanie
Realizacja programu
Wsparcie programu
Sprzedaż

Przyjrzyjmy się bliżej procesowi projektowania. W procesie projektowania architekt lub doświadczony programista tworzy dokumentację projektową, w tym opisy tekstowe, schematy i modele przyszłego programu. W tej trudnej sprawie pomoże nam język UML.

UML to graficzny język do wizualizacji, opisu parametrów, projektowania i dokumentacji różnych systemów (w szczególności programów). Diagramy są tworzone przy użyciu specjalnych narzędzi CASE, takich jak Rational Rose (http://www-01.ibm.com/software/rational/) i Enterprise Architect (http://www.sparxsystems.com.au/). Pojedynczy model informacji budowany jest w oparciu o technologię UML. Powyższe narzędzia CASE są w stanie generować kod w różnych językach obiektowych, a także posiadają bardzo przydatną funkcję inżynierii wstecznej. (Inżynieria odwrotna pozwala na stworzenie modelu graficznego z istniejącego kodu programu i komentarzy do niego.)

Rozważ rodzaje diagramów do wizualizacji modelu (są to niezbędne, chociaż jest ich znacznie więcej):

Diagram przypadków użycia

Projektowany system jest reprezentowany jako zbiór podmiotów lub aktorów wchodzących w interakcję z systemem za pomocą tzw. precedensów. W tym przypadku aktor (aktor) lub aktor to dowolna jednostka, która wchodzi w interakcję z systemem z zewnątrz. Innymi słowy, każdy przypadek użycia definiuje pewien zestaw działań, które system wykonuje podczas rozmowy z aktorem. Jednocześnie nic nie mówi się o tym, jak będzie realizowana interakcja aktorów z systemem.

Diagram klas (diagram klas)

Diagram klas służy do reprezentacji statycznej struktury modelu systemu w terminologii klas programowania obiektowego. Diagram klas może odzwierciedlać w szczególności różne relacje między poszczególnymi podmiotami obszaru przedmiotowego, takimi jak obiekty i podsystemy, a także opisywać ich wewnętrzną strukturę (pola, metody…) oraz rodzaje relacji (dziedziczenie, implementacja interfejsów ). ...). Diagram ten nie dostarcza informacji o czasowych aspektach działania systemu. Z tego punktu widzenia diagram klas jest dalszym rozwinięciem modelu koncepcyjnego projektowanego systemu. Na tym etapie niezbędna jest znajomość podejścia OOP i wzorców projektowych.

Diagram stanów (diagram diagramów stanów)

Głównym celem tego diagramu jest opisanie możliwych sekwencji stanów i przejść, które razem charakteryzują zachowanie elementu modelu podczas jego cyklu życia. Diagram stanu przedstawia dynamiczne zachowanie podmiotów, oparte na określeniu ich reakcji na percepcję określonych zdarzeń.

Diagram sekwencyjny

Odpowiednie diagramy interakcji służą do modelowania interakcji obiektów w języku UML. Interakcje obiektów można rozpatrywać w czasie, a następnie diagram sekwencji służy do reprezentowania czasu transmisji i odbioru komunikatów między obiektami. Obiekty wchodzące w interakcje wymieniają ze sobą pewne informacje. W takim przypadku informacja ma postać kompletnych wiadomości. Innymi słowy, mimo iż przekaz posiada treść informacyjną, zyskuje dodatkową właściwość wywierania ukierunkowanego wpływu na jego odbiorcę.

Schemat współpracy

Na diagramie współpracy obiekty uczestniczące w interakcji przedstawione są w postaci prostokątów, zawierających nazwę obiektu, jego klasę i ewentualnie wartości atrybutów. Podobnie jak na diagramie klas, powiązania między obiektami są wskazane w postaci różnych linii łączących. W takim przypadku można jawnie określić nazwy powiązania i role, jakie obiekty pełnią w tym powiązaniu.
W przeciwieństwie do diagramu sekwencji diagram współpracy przedstawia tylko relacje między obiektami, które odgrywają określone role w interakcji.

Schemat komponentów

Diagram komponentów, w przeciwieństwie do wcześniej omawianych diagramów, opisuje cechy fizycznej reprezentacji systemu. Diagram komponentów pozwala określić architekturę tworzonego systemu poprzez ustalenie zależności między komponentami oprogramowania, które mogą być kodem źródłowym, binarnym i wykonywalnym. W wielu środowiskach programistycznych moduł lub komponent odpowiada plikowi. Kropkowane strzałki łączące moduły pokazują relacje zależności podobne do tych, które występują podczas kompilowania kodu źródłowego programu. Główne elementy graficzne diagramu komponentów to komponenty, interfejsy i zależności między nimi.

Schemat wdrożenia

Diagram wdrożeniowy służy do wizualizacji elementów i komponentów programu, które istnieją tylko na etapie jego wykonania (runtime). W tym przypadku prezentowane są tylko komponenty instancji programu, które są plikami wykonywalnymi lub bibliotekami dynamicznymi. Te składniki, które nie są używane w czasie wykonywania, nie są wyświetlane na diagramie wdrażania.
Diagram wdrażania zawiera graficzną reprezentację procesorów, urządzeń, procesów i relacji między nimi. W przeciwieństwie do diagramów reprezentacji logicznej diagram wdrożenia jest taki sam dla systemu jako całości, ponieważ musi w pełni odzwierciedlać cechy jego implementacji. Diagram ten zasadniczo kończy proces OOAP dla konkretnego systemu oprogramowania, a jego rozwój jest zwykle ostatnim krokiem w specyfikacji modelu.

Na tym kończymy nasz przegląd schematów w szczególności i ogólnie projektowania. Warto zauważyć, że proces projektowania od dawna stał się standardem tworzenia oprogramowania, ale często mamy do czynienia z pięknie napisanym programem, który przez brak odpowiedniej dokumentacji zyskuje niepotrzebną funkcjonalność poboczną, kule, staje się niewygodny i traci swoją dawna jakość. =(

Jestem przekonany, że programista to przede wszystkim programista - NIE powinien komunikować się z klientem, NIE powinien myśleć o architekturze systemu, nie powinien wymyślać interfejsu do programu, powinien tylko kodować - implementować algorytmy, funkcjonalność, wygląd, użyteczność, ale nie więcej…. Projektant, zaczynając od abstrakcyjnych diagramów (opisujących obszar tematyczny) do diagramów przedstawiających strukturę danych, klasy i procesy ich interakcji, musi wszystko szczegółowo opisać krok po kroku. Oznacza to, że złożoność pracy i wynagrodzenie projektanta powinny być o rząd wielkości wyższe niż programisty == kodera. Przepraszam za tyradę....

1.1. Interakcja z Klientami (Główne funkcje)

1.1.1. Wyszukiwanie zamówień

7.2.3.1. Informacje o produkcie

1.1.2. Praca przedkontraktowa z Klientem

Dokumenty regulacyjne

2.2.1.2.1. Prace przedkontraktowe z Klientem STP-1-01

ISO9000:2000 Wymagania dotyczące systemu zarządzania jakością, punkt 7

7.2.1.1. Wymagania klienta dotyczące produktów, w tym wymagania dotyczące dostępności, dostawy i konserwacji

7.2.2.4. Określenie zdolności do osiągnięcia zgodności z określonymi wymaganiami

// Analiza wymagań produktowych / Procesy związane z konsumentem / SPRZEDAŻ PRODUKTÓW

1.1.3. Tworzenie SIWZ

Dokumenty regulacyjne

2.2.1.2.2. Procedura analizy i zawarcia umowy STP-2-01 // Standardy Przedsiębiorstwa Enterprise Ellat (STP) / Dokumenty systemu zarządzania jakością / Wewnętrzne dokumenty regulacyjne / Regulaminy

ISO9000:2000 Wymagania dotyczące systemu zarządzania jakością, punkt 7

7.2.1.2. Wymagania nie określone przez klienta, ale niezbędne do zamierzonego lub określonego zastosowania // Definicja wymagań klienta / Procesy związane z klientem / SPRZEDAŻ PRODUKTÓW

7.2.1.3. Obowiązki związane z produktem, w tym bezwzględnie obowiązujące wymagania i przepisy prawne // Definicja wymagań klienta / Procesy związane z klientem / SPRZEDAŻ PRODUKTÓW

// Analiza wymagań produktowych / Procesy związane z konsumentem / SPRZEDAŻ PRODUKTÓW

7.2.2.2. Potwierdzenie wymagań konsumenta przed ich akceptacją, jeżeli konsument nie przedstawi pisemnego oświadczenia o wymaganiach // Analiza wymagań produktowych / Procesy związane z konsumentem / SPRZEDAŻ PRODUKTÓW

7.2.2.3. Wyjaśnienie zmian w wymaganiach umowy lub zamówienia, które różnią się od wcześniej zgłoszonych (np. poprzez licytację lub linki) // Analiza wymagań produktowych / Procesy związane z konsumentem / SPRZEDAŻ PRODUKTÓW

7.3.1.1. Określenie etapów procesu projektowania i/lub rozwoju

7.3.2.2. Obowiązujące wymagania prawne i regulacyjne

7.3.2.3. Obowiązujące dane pochodzące z podobnych wcześniejszych zmian // Dane wejściowe do projektowania i rozwoju / Projektowanie i rozwój / SPRZEDAŻ PRODUKTÓW

7.3.2.4. Inne wymagania ważne dla projektowania i rozwoju // Dane wejściowe do projektowania i rozwoju / Projektowanie i rozwój / SPRZEDAŻ PRODUKTÓW

7.3.4.1. Ocena zdolności do spełnienia wymagań

1.1.4. Zawarcie Umów

Dokumenty regulacyjne

2.2.1.2.3. Regulamin pracy kontraktowej z Klientem (STP-3-01) // Enterprise Standards Ellat (STP) / Dokumenty systemu zarządzania jakością / Wewnętrzne dokumenty regulacyjne / Regulacje

1.1.5. Monitorowanie wypełniania zobowiązań umownych

Dokumenty regulacyjne

2.2.1.2.3.2. Procedura analizowania zmian i wprowadzania zmian w Dokumentach Umownych // Regulamin pracy kontraktowej z Klientem (STP-3-01) / Enterprise Standards Ellat (STP) / Dokumenty systemu zarządzania jakością / Wewnętrzne dokumenty regulacyjne / Regulamin

2.2.1.2.4.1. Procedura rozpatrywania reklamacji i roszczeń Klienta

2.2.1.2.4.2. Procedura usuwania uwag Klienta // Regulamin działań korygujących i zapobiegawczych (STP-4-01) / Ellat Enterprise Standards (STP) / Dokumenty systemu zarządzania jakością / Wewnętrzne dokumenty regulacyjne / Rozporządzenia

ISO9000:2000 Wymagania dotyczące systemu zarządzania jakością, punkt 7

7.2.3.2. Przetwarzanie wniosków, umów, zamówień, w tym zmian // Komunikacja z konsumentem / Procesy związane z konsumentem / SPRZEDAŻ PRODUKTÓW

1.2. Harmonogramowanie prac projektowych (główne funkcje)

1.2.1. Wyjaśnienie składu kompleksu i zakresu zabudowy

Dokumenty regulacyjne

// Enterprise Standards Ellat (STP) / Dokumenty systemu zarządzania jakością / Wewnętrzne dokumenty regulacyjne / Regulacje

ISO9000:2000 Wymagania dotyczące systemu zarządzania jakością, punkt 7

7.2.2.1. Definicja wymagań dotyczących produktu // Analiza wymagań produktowych / Procesy związane z konsumentem / SPRZEDAŻ PRODUKTÓW

1.2.2. Planowanie zapewnienia jakości projektu

Dokumenty regulacyjne

2.2.1.2.5. Skład i procedura opracowania programu zapewnienia jakości projektu (STP-5-01) // Enterprise Standards Ellat (STP) / Dokumenty systemu zarządzania jakością / Wewnętrzne dokumenty regulacyjne / Regulacje

ISO9000:2000 Wymagania dotyczące systemu zarządzania jakością, punkt 7

7.1.1. Wyznaczanie celów jakościowych dla produktu, projektu lub umowy

7.1.3. Definicja czynności przeglądu i zatwierdzenia oraz kryteriów akceptacji // Planowanie procesów sprzedaży / SPRZEDAŻ PRODUKTÓW

7.2.2.5. Ustalanie wyników analizy i kolejnych działań następczych (patrz punkt 5.5.7) // Analiza wymagań produktowych / Procesy związane z konsumentem / SPRZEDAŻ PRODUKTÓW

7.3.1.2. Definicja czynności związanych z przeglądem, weryfikacją i zatwierdzeniem dla każdego etapu projektowania i/lub rozwoju // Projektowanie i planowanie rozwoju / Projektowanie i rozwój / SPRZEDAŻ PRODUKTÓW

1.2.3. Tworzenie prywatnych specyfikacji technicznych dla rozwoju komponentów kompleksu

Dokumenty regulacyjne

2.2.1.2.7. Technologia realizacji projektów. Etapy i kolejność pracy (STP-7-01) // Enterprise Standards Ellat (STP) / Dokumenty systemu zarządzania jakością / Wewnętrzne dokumenty regulacyjne / Regulacje

1.2.4. Planowanie

Dokumenty regulacyjne

// Enterprise Standards Ellat (STP) / Dokumenty systemu zarządzania jakością / Wewnętrzne dokumenty regulacyjne / Regulacje

ISO9000:2000 Wymagania dotyczące systemu zarządzania jakością, punkt 7

7.1.2. Określenie potrzeby ustanowienia procesów i dokumentacji, zapewnienie zasobów i infrastruktury specyficznej dla produktu // Planowanie procesów sprzedaży / SPRZEDAŻ PRODUKTÓW

1.2.5. Koordynacja i kontrola operacyjna wykonania pracy

Dokumenty regulacyjne

2.2.1.2.4.3. Procedura działań naprawczych // Regulamin działań korygujących i zapobiegawczych (STP-4-01) / Ellat Enterprise Standards (STP) / Dokumenty systemu zarządzania jakością / Wewnętrzne dokumenty regulacyjne / Rozporządzenia

2.2.1.2.6. Rozporządzenie w sprawie planowania pracy (STP-6-01) // Enterprise Standards Ellat (STP) / Dokumenty systemu zarządzania jakością / Wewnętrzne dokumenty regulacyjne / Regulacje

ISO9000:2000 Wymagania dotyczące systemu zarządzania jakością, punkt 7

7.3.4.2. Identyfikacja problemów i opracowanie propozycji działań następczych // Analiza projektowania i rozwoju / Projektowanie i rozwój / PRODUCT MAILING

7.3.7. Zarządzanie zmianami w projektowaniu i rozwoju

1.3. Opracowanie projektu, oprogramowania i dokumentacji operacyjnej (Główne funkcje)

1.3.1. Opracowanie dokumentacji sprzętowej kompleksu

Dokumenty regulacyjne

2.3.3.3. Plan pracy dla działu rozwoju sprzętu i produkcji

1.3.2. Rozwój oprogramowania części kompleksu

Dokumenty regulacyjne

2.3.3.4. Plan pracy dla działu rozwoju oprogramowania i produkcji // Programy i plany działania / Dokumenty organizacyjno-administracyjne firmy / Regulamin

1.3.4. Analiza i zatwierdzenie wyników projektowania

Dokumenty regulacyjne

ISO9000:2000 Wymagania dotyczące systemu zarządzania jakością, punkt 7

7.3.3.1. Zgodność z wymaganiami wejściowymi do projektowania i rozwoju

7.3.3.2. Zapewnij odpowiednie informacje dotyczące działalności produkcyjnej i usługowej (patrz 7.5) // Wyniki projektowania i rozwoju / Projektowanie i rozwój / PRODUCT MAILING

7.3.3.4. Określ cechy produktu, które są niezbędne do jego bezpiecznego i prawidłowego użytkowania. // Wyniki projektowania i rozwoju / Projektowanie i rozwój / PRODUCT MAILING

7.3.5.1. Zgodność danych wyjściowych z wymaganiami wejściowymi // Weryfikacja Projektu i Rozwoju / Projekt i Rozwój / SPRZEDAŻ PRODUKTÓW

7.3.6. Zatwierdzenie wyników projektowania i rozwoju // Projektowanie i rozwój / PRODUKTY SPRZEDAŻY

Edukacja, Rozwój, Szkolenia

Słowa kluczowe:

1 -1

Rozważ pełny schemat interakcji z klientem na przykładzie tworzenia strony internetowej. Graficznie etapy interakcji można przedstawić na poniższym rysunku:

Podstawowym jest połączenie lub e-mail, które są przetwarzane przez menedżera konta. Kierownik opowiada o usługach firmy Beehive, udziela odpowiedzi na wszystkie interesujące pytania i wyjaśnia klientowi dalszy proces interakcji.

* Warto zauważyć, że klientowi na cały okres realizacji projektu przydzielany jest osobisty menedżer, który jest gotowy odpowiedzieć na wszystkie pytania i pomóc w rozwiązaniu wszelkich problemów.

Następnie kierownik pomaga dokończyć krótki formularz za stworzenie strony internetowej, która zawiera niezbędne pytania wyjaśniające na temat współpracy oraz dodaje kontakt do wewnętrznego systemu CRM (Customer Relationship Management System).

Dane są wprowadzane do systemu w celu bezpiecznego przechowywania wszystkich niezbędnych danych klienta i zapewnienia jakościowego rozwoju witryny jako całości.

Na podstawie wypełnionego briefu specjaliści Beehive przygotowują indywidualna oferta handlowa z opisem czasu i kosztów pracy, a kierownik przesyła go klientowi do rozpatrzenia.

Następnie następuje proces uzgadniania warunków współpracy, którego wynikiem jest: traktat. Aby przyspieszyć rozpoczęcie prac, umowę podpisują obie strony, a strony wymieniają zeskanowane kopie umowy. Oryginały umowy wysyłane są listem poleconym (dalej wszystkie kopie papierowe wymieniane są pocztą lub kurierem). Po otrzymaniu przez stronę oryginału w formie papierowej, jeden egzemplarz jest odsyłany pocztą.

*Czas od rozmowy telefonicznej do podpisania umowy trwa zwykle nie dłużej niż 1-2 dni.

Po podpisaniu umowy i wymianie elektronicznych zeskanowanych kopii klient wpłaca zaliczkę, której wysokość wynosi zazwyczaj 50% całkowitej kwoty umowy.

Po otrzymaniu zaliczki i przeprowadzeniu analizy przedmiotowego obszaru rozpoczyna się etap opracowania i akceptacji specyfikacja istotnych warunków zamówienia (TOR), gdzie określone są wszystkie wymagania dla tworzonej witryny, podawane są schematy i tworzony jest szczegółowy prototyp całej witryny. TK jest obowiązkowym załącznikiem do umowy, zatwierdzonym przez obie strony i podpisanym w taki sam sposób jak umowa.

* Należy rozumieć, że SIWZ jest bardzo ważnym dokumentem zarówno dla wykonawcy jak i klienta. Pozwala na zaprojektowanie i wykonanie projektu internetowego o wysokiej jakości i na czas.

Po zatwierdzeniu wszystkich wymagań klient zostaje wysłany lista niezbędnych materiałów tekstowych i graficznych, które klient musi dostarczyć przed rozpoczęciem etapu rozwoju (tj. podczas opracowywania makiety projektowej przez wykonawcę, klient zbiera i dostarcza wszystkie niezbędne materiały). Lista ta może zawierać: opis firmy, z którą współpracują, jakie posiada nagrody i certyfikaty, ceny i cenniki, katalog produktów i opis towarów, opis usług, dane kontaktowe publikowane na stronie itp.

Czasami klientowi trudno jest samemu opisać swoje usługi lub po prostu nie ma na to czasu. W takim przypadku wykonawca jest gotowy do dokończenia pracy nad napisaniem brakujących treści na stronę (zdjęcia, teksty, filmy itp.).

* Dostarczenie klientowi niezbędnych materiałów ma kluczowe znaczenie, ponieważ:

konieczne jest prawidłowe wprowadzenie wszystkich treści dostarczonych przez klienta do układu strony od razu (nie ma sensu wykonywać dodatkowej pracy);
proces technologiczny wykonawcy jest zaplanowany dosłownie „na minutę” i nie chcemy go naruszać i ponosić dodatkowych kosztów;
wypełnianie projektu internetowego informacjami testowymi również nie ma sensu (po pierwsze, ilość niepotrzebnej pracy znowu wzrasta; po drugie, wyszukiwarki mogą pesymizować hostowaną stronę treścią testową; po trzecie, Twoi potencjalni klienci mogą mieć negatywny stosunek do strony, co zawiera oczywiście bezużyteczne informacje);
Zarówno dla Ciebie, jak i dla nas ważne jest profesjonalne i terminowe wykonanie projektu.

* Drodzy klienci, proszę nie zwlekać z rozwojem własnej strony i czerpać z niej korzyści. Dostarczaj treści na czas! W przeciwnym razie projekt zostanie zamrożony do czasu otrzymania od Ciebie informacji i odpowiednio przesunie się termin przesłania strony. Jeśli nie ma czasu na zbieranie i pisanie informacji, zlecanie nam pisania tekstów i obróbki zdjęć, jest to niedrogie.

Równolegle powstaje grupa robocza dla projektu i rozpoczyna się etap opracowanie układu projektu przyszłej stronie.
Po przygotowaniu makiety projektowej jest on wysyłany do klienta do akceptacji. Po zatwierdzeniu makieta staje się ważnym projektem.

* W zależności od złożoności projektu klient może otrzymać dostęp do systemu zarządzania projektami (np. Redmine), gdzie można wgrać niezbędne zasoby projektu, monitorować etapy rozwoju i publikować komentarze.

Do dalszej kontynuacji prac obligatoryjne jest otrzymanie od klienta wszystkich niezbędnych materiałów, których wykaz został przesłany klientowi wcześniej.

Jak tylko otrzymamy brakujące materiały. Ważne etap zagospodarowania terenu zgodnie z zatwierdzonym TOR.
Ten etap obejmuje dużą liczbę rodzajów pracy: jest to układ układów stron w różnych przeglądarkach, opracowanie niezbędnych szablonów projektowych dla wybranego systemu zarządzania treścią (CMS), instalacja i konfiguracja samego CMS, instalacja niezbędnych moduły i komponenty, opracowanie brakujących modułów, kompleksowe badanie algorytmów działania serwisu, wypełnienie serwisu treścią, wdrożenie projektu w domenie technicznej i przejście do testów.

Testowanie projektu internetowego przeprowadzają specjaliści wykonawcy, wszystkie błędy i komentarze są eliminowane, strona jest dopracowana do pracy.

Po zakończeniu prac i zakończeniu testowania witryny w domenie technicznej, etap przekazania. Tutaj ze strony klienta sprawdzane jest spełnienie wymagań TOR oraz cały proces funkcjonowania projektu internetowego.
Po podjęciu przez klienta decyzji o pełnej zgodności strony z wymaganiami TOR, strona jest przekazywana klientowi, a projekt publikowany na hostingu.

Wynikiem i potwierdzeniem dostarczenia i odbioru robót jest miejsce pracy i akt odbioru, który jest podpisany przez obie strony. Podpisany akt wraz z kompletem dokumentów księgowych wysyłany jest pocztą.

Po podpisaniu protokołu odbioru klient zgodnie z umową płaci pozostały koszt prac.

Po ostatecznej kalkulacji wraz z dokumentami i stroną internetową klient otrzymuje instrukcję obsługi, kopia strony na DVD i wolne pomoc techniczna w ciągu 2-4 tygodni od daty akceptacji serwisu.

Na tym schemacie staraliśmy się w pełni odzwierciedlić wszystkie aspekty interakcji od pierwszego naboru do realizacji projektu. W przypadku prostych projektów niektóre kroki można połączyć lub pominąć. Ale w każdym razie wszystko znajduje odzwierciedlenie w umowie.

Schemat pracy dla usług „Kompleksowa realizacja serwisu” oraz „Promocja serwisu” w sposób strukturalny powtarza opisany powyżej proces interakcji pomiędzy klientem a wykonawcą i dlatego nie wymaga szczegółowego opisu.

Mamy nadzieję, że opisany schemat interakcji jest przejrzysty i zrozumiały. Jeśli nadal masz pytania, proszę

Projekt:	Dystrybucja zapytań do katalogu elektronicznego według indeksów wyszukiwania i wyszukiwanych haseł
Zakres projektu:	13.02.2006 - 05.06.2006
Klient:	Biblioteka Naukowa Uniwersytetu Państwowego w Pietrozawodsku.
Odpowiedzialny:	Gorshkova Galina Anatolyevna, kierownik działu komputerowego przetwarzania dokumentów i tworzenia katalogów. E-mail Poczta: . Niewolnik. tel.: 719602. Biblioteka: dok. 102. Guryev Dmitrij Borisovich, czołowy programista RCNIT. E-mail Poczta: . Niewolnik. tel.: 784775. Centrum internetowe.
Instruktor:	Kułakow Cyryl Aleksandrowicz E-mail: . Telefon biurowy: 711015. Pokój 215
Informacje dla instruktora:	Numer grupy 13
Powiązane dokumenty:	Przegląd projektu Plan projektu Harmonogram prac (wykres Gantta) Specyfikacja wymagań Projekt Test Dokument wdrożeniowy Dokument testowy Zaangażowanie klienta Relacje z programistami Raporty Postęp rozwoju Słownik Przewodnik użytkownika

Pierwsze spotkanie z klientem.

Na pierwszym spotkaniu zespół programistów został przedstawiony klientowi. Klient z kolei mówił o bibliotece naukowej PetrSU.

Biblioteka działa w oparciu o zautomatyzowany system „Foliant”. Katalog elektroniczny jest częścią systemu bibliotecznego. Wyszukiwanie w katalogu odbywa się za pomocą zapytań. Operator generuje ciągi wyszukiwania, które mogą zawierać dużą liczbę indeksów wyszukiwania i wyszukiwanych terminów. Każde żądanie jest rejestrowane w tabeli dziennika. Ta tabela zawiera dane dotyczące czasu żądania, adresu klienta, który złożył żądanie, samego żądania, wyniku żądania.

Klient musi stale monitorować tabelę logów i dostarczać pewne statystyki dotyczące korzystania z indeksów wyszukiwania.

Przedstawiono również wstępne wymagania dla realizowanego projektu. Jednym z wymogów jest sprawne zestawianie statystyk. Oznacza to, że statystyki powinny być wyświetlane po rozsądnym czasie po wysłaniu żądania. Ze względu na to wymaganie zachęcano programistów do korzystania z procedur po stronie serwera w PL/SQL.

Drugie spotkanie z klientem.

Klient przekazał programistom login i hasło umożliwiające wejście do systemu elektronicznego katalogu, dostarczając do pracy kopie dwóch tabel - logu i tabeli indeksów wyszukiwania.

Guryev Dmitry Borisovich zapoznał nas bardziej szczegółowo z pracą w kliencie Oracle SQL*Plus DBMS. Zespół zapoznał się z pracą katalogu elektronicznego.

System „Foliant” działa w oparciu o standard RusMark, który zawiera około 99 pól. Każda biblioteka współpracująca z AIBS „Foliant” wybiera pola i podpola, których będzie używać. Istnieją specjalne GOST, które opisują zasady przechowywania danych bibliotecznych. Ponieważ istnieje duża liczba pól, stworzyliśmy system indeksów wyszukiwania. Istnieją indeksy usługowe i publiczne.

Użytkownicy katalogu dzielą się na wewnętrznych i zewnętrznych. Każdy dział lub pracownik ma przypisane własne prawa. Każdy zapis dotyczący obiektu jest analizowany na osobne elementy i nie jest przechowywany jako całość.

Trzecie spotkanie z klientem.

Klient przedstawił nam na piśmie jasne wymagania.

Klient jest zainteresowany następującymi statystykami:

Liczba zapytań do katalogu elektronicznego.

Przez ostatni miesiąc po dniu.
Rozliczenie miesięczne za rok bieżący.
Rachunkowość przez lata.
Stwórz historię informacji.

Lista próśb wg do każdego indeks wyszukiwania, w którym wynik wyszukiwania miał wartość NULL.

Lista najczęściej występujących żądań.

Analiza realizacji wniosków za określony okres. Raport powinien zawierać następujące statystyki:

Liczba wniosków.
Liczba żądań wyszukiwania.
Liczba złożonych zapytań.
Liczba udanych odpowiedzi.
Liczba pustych odpowiedzi.
Autor
Autor ks. szturchać.
Rodzaj dokumentu.
Sekcja geograficzna.
Wpisz datę.
Data publikacji.
Tytuł.

Czwarte spotkanie z klientem.

Specjalista od klienta Guryev D.B. wyjaśnił zawiłości instalacji i konfiguracji narzędzia SQL*Plus. Rozwiązaniem problemu uruchomienia programu było zainstalowanie pakietu SQL*Net, również Guryev D.B. podał dokładne nazwy tabel dla deweloperów, a także dodał kolejną tabelę do dyspozycji zespołu. Specjalista przestudiował dokument architektoniczny i zaproponował wdrożenie praktycznie wszystkich typów architektury i wybór najbardziej optymalnego. Jednocześnie wskazane jest, aby nie przebudowywać log-tablicy iw miarę możliwości, rozwiązując konkretny problem, uogólniać dane z log-tablicy do dalszego wykorzystania w różnych statystykach lokalnych.

Klient Gorshkova G.A. zapoznał się z dokumentem wymagań, po ich zatwierdzeniu.

Piąte spotkanie z klientem.

Guryev Dmitry Borisovich, specjalista ze strony klienta, został zaproszony do zainstalowania oprogramowania niezbędnego do pracy z DBMS „Oracle” na serwerze szkoleniowym PetrSU. Ze strony uczelni w proces ten zaangażowany był również Vadim Anatolyevich Ponomarev, który ma dostęp administracyjny do serwera PetrSU.