Вътрешно взаимодействие с клиента по време на проектирането. Клиент и Изпълнител – взаимоотношенията като основа за успеха на проекта

Общите етапи на взаимодействие с клиента са следните точки:

- Предварителна комуникация с клиента: идентифициране на целите и задачите на проекта, идентифициране на основните изисквания към бъдещата система, предварително запознаване с фирмата на клиента, предварителна оценка на времето и стойността на проекта, подготовка и предаване на търговска оферта към Клиента.
- Детайлно проучване и събиране на изискванията на клиента: определяне на състава на проектния екип, събиране на изискванията към системата, интервюиране на ключови потребители и технически специалисти на клиента, разработване и утвърждаване на Техническо задание.
- Разработване и тестване на системата: след разработването на системата или определена част от нейната функционалност се извършва демонстрация пред Клиента. Следва етапът на откриване и отстраняване на грешки, ако няма такива, тестове за приемане.
- Пробна експлоатация на системата: внедряване на системата от страна на клиента, обучение на потребителите, събиране на коментари и предложения за подобряване на системата, отстраняване на коментари.
- Индустриална експлоатация на системата: независима работа от Клиента, свързване с поддръжката на компанията (ако е необходимо), събиране на желания за развитие на системата.

Важна форма на взаимодействие с клиента е документацията, разработена по време на изпълнението на проекта в съответствие с изискванията на GOST 34 и RUP.

Сформират се работни групи за конкретни задачи по проекта. Синхронизирането на действията се осъществява чрез съвета на делегатите от работните групи. Членовете на работните групи самостоятелно разработват принципите на взаимодействие в групата. Групите могат да включват членове на други групи в решаването на проблеми. Успешни форми на взаимодействие както в рамките на групи, така и между групи могат да бъдат възприети от нови участници в проекта

Светът отдавна признава, че управлението на проекти е специална област на управление, прилагането на която дава осезаеми резултати. Професионалистите в тази област са високо ценени (в САЩ това е третата най-добре платена професия след адвокати и лекари), а самата методология за управление на проекти се превърна в де факто стандарт за управление в много хиляди предприятия и се използва в различна степен в почти всички големи корпорации. Миналата година бяха приети стандарти за управление на проекти ANSI и беше разработен проект на стандарти за управление на проекти ISO 10006.

Днес процесът на създаване на сложни софтуерни приложения не може да се представи без разделяне на етапи от жизнения цикъл. Под жизнения цикъл на програмата имаме предвид набор от етапи:

Анализ на предметната област и създаване на технически спецификации (взаимодействие с клиента)
Проектиране на структурата на програмата
Кодиране (набор от програмен код според проектната документация)
Тестване и отстраняване на грешки
Изпълнение на програмата
Програмна поддръжка
Изхвърляне

Нека разгледаме по-отблизо процеса на проектиране. По време на процеса на проектиране архитект или опитен програмист създава проектна документация, включваща текстови описания, диаграми и модели на бъдещата програма. В този труден въпрос езикът UML ще ни помогне.

UML е графичен език за визуализация, описание на параметри, проектиране и документиране на различни системи (в частност програми). Диаграмите се създават с помощта на специални CASE инструменти като Rational Rose (http://www-01.ibm.com/software/rational/) и Enterprise Architect (http://www.sparxsystems.com.au/). Единен информационен модел е изграден на базата на UML технологията. Горните CASE инструменти са в състояние да генерират код на различни обектно-ориентирани езици и също имат много полезна функция за обратно инженерство. (Обратното инженерство ви позволява да създадете графичен модел от съществуващия програмен код и коментари към него.)

Помислете за видовете диаграми за визуализиране на модела (те са задължителни, въпреки че има много повече видове):

Диаграма на случаи на използване

Проектираната система е представена като набор от обекти или актьори, взаимодействащи със системата, използвайки така наречените прецеденти. В този случай актьор (актьор) или актьор е всеки субект, който взаимодейства със системата отвън. С други думи, всеки случай на използване дефинира определен набор от действия, които системата изпълнява, когато говори с актьор. В същото време не се казва нищо за това как ще се реализира взаимодействието на актьорите със системата.

Класова диаграма (класова диаграма)

Класовата диаграма служи за представяне на статичната структура на модела на системата в терминологията на класовете за обектно-ориентирано програмиране. Диаграмата на класа може да отразява по-специално различни връзки между отделни обекти на предметната област, като обекти и подсистеми, и също така описва тяхната вътрешна структура (полета, методи ...) и видове връзки (наследяване, реализация на интерфейси . ..). Тази диаграма не предоставя информация за времевите аспекти на работата на системата. От тази гледна точка класовата диаграма е по-нататъшно развитие на концептуалния модел на проектираната система. На този етап познаването на OOP подхода и моделите на проектиране е от съществено значение.

Диаграма на състоянието (диаграма на състоянието)

Основната цел на тази диаграма е да опише възможните последователности от състояния и преходи, които заедно характеризират поведението на моделен елемент по време на неговия жизнен цикъл. Диаграмата на състоянието представлява динамичното поведение на обектите, базирано на спецификацията на техния отговор на възприемането на някои конкретни събития.

Диаграма на последователността

Използват се подходящи диаграми на взаимодействие за моделиране на взаимодействието на обекти в езика UML. Взаимодействията на обектите могат да се разглеждат във времето и след това се използва диаграма на последователност, за да се представи времето на предаване и получаване на съобщения между обекти. Взаимодействащите обекти обменят някаква информация помежду си. В този случай информацията е под формата на пълни съобщения. С други думи, въпреки че съобщението има информационно съдържание, то придобива допълнителното свойство да упражнява насочено въздействие върху своя получател.

Диаграма на сътрудничество

В диаграмата на сътрудничество обектите, участващи във взаимодействието, са изобразени под формата на правоъгълници, съдържащи името на обекта, неговия клас и, евентуално, стойности на атрибути. Както в диаграмата на класовете, асоциациите между обектите са посочени под формата на различни свързващи линии. В този случай можете изрично да посочите имената на асоциацията и ролите, които обектите играят в тази асоциация.
За разлика от диаграмата на последователността, диаграмата на сътрудничество изобразява само връзки между обекти, които играят определени роли във взаимодействие.

Диаграма на компонентите

Диаграмата на компонентите, за разлика от обсъдените по-горе диаграми, описва характеристиките на физическото представяне на системата. Диаграмата на компонентите ви позволява да определите архитектурата на разработваната система чрез установяване на зависимости между софтуерни компоненти, които могат да бъдат изходен, двоичен и изпълним код. В много среди за разработка модул или компонент съответства на файл. Пунктираните стрелки, свързващи модулите, показват връзки на зависимост, подобни на тези, които възникват при компилирането на изходния код на програмата. Основните графични елементи на диаграмата на компонентите са компоненти, интерфейси и зависимости между тях.

Диаграма на разполагане

Диаграмата за внедряване е предназначена да визуализира елементите и компонентите на програмата, които съществуват само на етапа на нейното изпълнение (време на изпълнение). В този случай се представят само компоненти на екземпляр на програма, които са изпълними файлове или динамични библиотеки. Тези компоненти, които не се използват по време на изпълнение, не се показват в диаграмата за разполагане.
Диаграмата на внедряване съдържа графични изображения на процесори, устройства, процеси и връзките между тях. За разлика от логическите диаграми за представяне, диаграмата на разгръщане е една и съща за системата като цяло, тъй като тя трябва напълно да отразява характеристиките на нейното изпълнение. Тази диаграма по същество завършва процеса на OOAP за определена софтуерна система и нейното разработване обикновено е последната стъпка в спецификацията на модела.

Това завършва нашия преглед на диаграмите в частност и дизайна като цяло. Струва си да се отбележи, че процесът на проектиране отдавна се е превърнал в стандарт за разработка на софтуер, но често трябва да се справяте с красиво написана програма, която поради липсата на подходяща документация придобива ненужна странична функционалност, патерици, става тромава и губи своята предишно качество. =(

Убеден съм, че програмистът е преди всичко програмист - той НЕ трябва да общува с клиента, НЕ трябва да мисли за архитектурата на системата, не трябва да измисля интерфейс към програмата, той трябва само да кодира - да внедрява алгоритми, функционалност, външен вид, използваемост, но не повече... Дизайнерът, започвайки от абстрактни диаграми (описващи предметната област) до диаграми, представящи структурата на данните, класовете и процесите на тяхното взаимодействие, трябва да опише всичко стъпка по стъпка в детайли. Тоест сложността на работата и заплатата на дизайнера трябва да бъде с порядък по-висока от тази на програмист == кодер. Съжалявам за изказването....

1.1. Взаимодействие с клиенти (Основни функции)

1.1.1. Търсене на поръчка

7.2.3.1. За информация за продукта

1.1.2. Преддоговорна работа с клиента

Нормативни документи

2.2.1.2.1. Преддоговорна работа с клиента STP-1-01

ISO9000:2000 Изисквания към системата за управление на качеството, клауза 7

7.2.1.1. Изисквания на клиентите към продуктите, включително изисквания за наличност, доставка и поддръжка

7.2.2.4. Определяне на способността за постигане на съответствие с определени изисквания

// Анализ на продуктовите изисквания / Процеси, свързани с потребителя / ПРОДАЖБА НА ПРОДУКТИ

1.1.3. Оформяне на техническо задание

Нормативни документи

2.2.1.2.2. Процедурата за анализ и сключване на договор STP-2-01 // Стандарти на Enterprise Enterprise Ellat (STP) / Документи на системата за управление на качеството / Вътрешни нормативни документи / Правила

ISO9000:2000 Изисквания към системата за управление на качеството, клауза 7

7.2.1.2. Изисквания, които не са посочени от клиента, но са необходими за предвидената или определена употреба // Дефиниране на изискванията на клиентите / Процеси, свързани с клиента / ПРОДАЖБИ НА ПРОДУКТИ

7.2.1.3. Задължения, свързани с продукта, включително задължителни изисквания и законови разпоредби // Дефиниране на изискванията на клиентите / Процеси, свързани с клиента / ПРОДАЖБИ НА ПРОДУКТИ

// Анализ на продуктовите изисквания / Процеси, свързани с потребителя / ПРОДАЖБА НА ПРОДУКТИ

7.2.2.2. Потвърждаване на изискванията на потребителя преди тяхното приемане, ако потребителят не предостави писмено изложение на изискванията // Анализ на продуктовите изисквания / Процеси, свързани с потребителя / ПРОДАЖБА НА ПРОДУКТИ

7.2.2.3. Изясняване на промени в изискванията на договора или поръчката, които се различават от представените по-рано (например чрез наддаване или връзки) // Анализ на продуктовите изисквания / Процеси, свързани с потребителя / ПРОДАЖБА НА ПРОДУКТИ

7.3.1.1. Определяне на етапите на процесите на проектиране и/или разработка

7.3.2.2. Приложими законови и регулаторни изисквания

7.3.2.3. Приложими данни, извлечени от подобни предишни разработки // Входни данни за проектиране и разработка / Проектиране и разработка / ПРОДАЖБИ НА ПРОДУКТИ

7.3.2.4. Други изисквания, важни за проектирането и разработката // Входни данни за проектиране и разработка / Проектиране и разработка / ПРОДАЖБИ НА ПРОДУКТИ

7.3.4.1. Оценяване на способността за удовлетворяване на изискванията

1.1.4. Сключване на договори

Нормативни документи

2.2.1.2.3. Правила за договорна работа с клиента (STP-3-01) // Enterprise Standards Ellat (STP) / Документи на системата за управление на качеството / Вътрешни нормативни документи / Наредби

1.1.5. Следене на изпълнението на договорните задължения

Нормативни документи

2.2.1.2.3.2. Процедурата за анализиране на промените и извършване на промени в договорните документи // Правила за договорна работа с клиента (STP-3-01) / Enterprise Standards Ellat (STP) / Документи на системата за управление на качеството / Вътрешни нормативни документи / Правила

2.2.1.2.4.1. Ред за разглеждане на жалби и рекламации на Клиента

2.2.1.2.4.2. Процедурата за премахване на коментарите на клиента // Регламенти за коригиращи и превантивни действия (STP-4-01) / Ellat Enterprise Standards (STP) / Документи за системата за управление на качеството / Вътрешни нормативни документи / Регламенти

ISO9000:2000 Изисквания към системата за управление на качеството, клауза 7

7.2.3.2. Обработка на заявки, договори, поръчки, включително промени // Комуникация с потребителя / Процеси, свързани с потребителя / ПРОДАЖБА НА ПРОДУКТИ

1.2. Планиране на работа по проекта (Основни функции)

1.2.1. Уточняване на състава на комплекса и обхвата на разработката

Нормативни документи

// Enterprise Standards Ellat (STP) / Документи на системата за управление на качеството / Вътрешни нормативни документи / Наредби

ISO9000:2000 Изисквания към системата за управление на качеството, клауза 7

7.2.2.1. Дефиниране на изискванията към продукта // Анализ на продуктовите изисквания / Процеси, свързани с потребителя / ПРОДАЖБА НА ПРОДУКТИ

1.2.2. Планиране за осигуряване на качеството на проекта

Нормативни документи

2.2.1.2.5. Състав и процедура за разработване на програма за осигуряване на качеството на проекта (STP-5-01) // Enterprise Standards Ellat (STP) / Документи на системата за управление на качеството / Вътрешни нормативни документи / Наредби

ISO9000:2000 Изисквания към системата за управление на качеството, клауза 7

7.1.1. Поставяне на качествени цели за продукт, проект или договор

7.1.3. Дефиниране на дейности по преглед и одобрение и критерии за приемане // Планиране на търговски процеси / ПРОДАЖБИ НА ПРОДУКТИ

7.2.2.5. Фиксиране на резултатите от анализа и последващи последващи действия (вижте точка 5.5.7) // Анализ на продуктовите изисквания / Процеси, свързани с потребителя / ПРОДАЖБА НА ПРОДУКТИ

7.3.1.2. Дефиниране на дейностите по преглед, проверка и одобрение за всеки етап на проектиране и/или разработка // Планиране на проектиране и разработка / Дизайн и разработка / ПРОДАЖБА НА ПРОДУКТИ

1.2.3. Формиране на частни технически спецификации за разработване на компонентите на комплекса

Нормативни документи

2.2.1.2.7. Технология на изпълнение на проекта. Етапи и ред на работа (STP-7-01) // Enterprise Standards Ellat (STP) / Документи на системата за управление на качеството / Вътрешни нормативни документи / Наредби

1.2.4. Планиран проект

Нормативни документи

ISO9000:2000 Изисквания към системата за управление на качеството, клауза 7

7.1.2. Определяне на необходимостта от установяване на процеси и документация, осигуряване на ресурси и инфраструктура, специфични за продукта // Планиране на търговски процеси / ПРОДАЖБИ НА ПРОДУКТИ

1.2.5. Координация и оперативен контрол на изпълнението на работата

Нормативни документи

2.2.1.2.4.3. Процедура за коригиращи действия // Регламенти за коригиращи и превантивни действия (STP-4-01) / Ellat Enterprise Enterprise Standards (STP) / Документи за системата за управление на качеството / Вътрешни нормативни документи / Регламенти

2.2.1.2.6. Наредба за планиране на работата (STP-6-01) // Enterprise Standards Ellat (STP) / Документи на системата за управление на качеството / Вътрешни нормативни документи / Наредби

ISO9000:2000 Изисквания към системата за управление на качеството, клауза 7

7.3.4.2. Идентифициране на проблеми и разработване на предложения за последващи действия // Анализ на дизайна и разработката / Дизайн и разработка / ИЗПРАЩАНЕ НА ПРОДУКТИ

7.3.7. Управление на промените в дизайна и разработката

1.3. Разработване на проектна, софтуерна и експлоатационна документация (Основни функции)

1.3.1. Разработване на документация за хардуера на комплекса

Нормативни документи

2.3.3.3. Работен план за отдела за разработка и производство на хардуер

1.3.2. Разработване на софтуерната част на комплекса

Нормативни документи

2.3.3.4. Работен план на отдела за разработка и производство на софтуер // Програми и планове за действие / Организационни и разпоредителни документи на дружеството / Правилник

1.3.4. Анализ и одобрение на резултатите от проектирането

Нормативни документи

ISO9000:2000 Изисквания към системата за управление на качеството, клауза 7

7.3.3.1. Съответства на входните изисквания за проектиране и разработка

7.3.3.2. Осигурете подходяща информация за производствени и сервизни операции (вижте 7.5) // Резултати от проектиране и разработка / Дизайн и разработка / ИЗПРАЩАНЕ НА ПРОДУКТИ

7.3.3.4. Определете характеристиките на продукта, които са от съществено значение за неговата безопасна и правилна употреба. // Резултати от проектиране и разработка / Дизайн и разработка / ИЗПРАЩАНЕ НА ПРОДУКТИ

7.3.5.1. Съответствие на изходните данни с входните изисквания // Проверка на дизайна и разработката / Дизайн и разработка / ПРОДАЖБА НА ПРОДУКТИ

7.3.6. Одобрение на резултатите от проектирането и разработката // Дизайн и разработка / ПРОДАЖБА ПРОДУКТИ

Образование, развитие, обучения

Ключови думи:

1 -1

Помислете за пълната схема на взаимодействие с клиента на примера за разработка на уебсайт. Графично етапите на взаимодействие могат да бъдат представени като следната фигура:

Основно е повикванеили електронна поща, които се обработват от акаунт мениджъра. Мениджърът говори за услугите на компанията Beehive, дава отговори на всички въпроси от интерес и обяснява по-нататъшния процес на взаимодействие с клиента.

* Заслужава да се отбележи, че на клиента се разпределя личен мениджър за целия период на неговия проект, който е готов да отговори на всички въпроси и да помогне при решаването на всички проблеми.

След това мениджърът помага да завърши кратка формаза изработка на уебсайт, който съдържа необходимите уточняващи въпроси по темата за сътрудничество и добавя контакт към вътрешната CRM система (Customer Relationship Management System).

Данните се въвеждат в системата, за да се съхраняват сигурно всички необходими клиентски данни и да се гарантира качественото развитие на сайта като цяло.

Въз основа на попълнения бриф специалистите на Beehive изготвят индивидуална търговска офертас описание на времето и цената на работата и мениджърът го изпраща на клиента за разглеждане.

Следва процесът на съгласуване на условията за сътрудничество, резултатът от който е договор. За да се ускори започването на работа, договорът се подписва от двете страни и страните си разменят сканирани копия на договора. Оригиналите на договора се изпращат с препоръчана поща (по-нататък всички хартиени копия се разменят по пощата или по куриер). След като страната получи оригинала на хартиен носител, едно копие се изпраща обратно по пощата.

*Процесът от обаждане до подписване на договор обикновено отнема не повече от 1-2 дни.

След подписване на договора и размяна на електронни сканирани копия, клиентът заплаща аванс, чийто размер обикновено е 50% от общата сума на договора.

След получаване на авансово плащане и извършване на анализ на обекта, започва етапът на разработване и одобрение задание (ТЗ), където са предписани всички изисквания към изработвания обект, дадени са схеми и е създаден подробен прототип на целия обект. ТЗ е задължително приложение към договора, одобрено от двете страни и подписано по същия начин като договора.

* Трябва да се разбере, че техническото задание е много важен документ както за изпълнителя, така и за клиента. Тя ви позволява да проектирате и изпълните интернет проект с високо качество и в срок.

След като всички изисквания са одобрени, клиентът се изпраща списък на необходимите текстови и графични материали, които клиентът трябва да предостави преди началото на етапа на разработка (т.е. по време на разработването на оформлението на проекта от изпълнителя, клиентът събира и предоставя всички необходими материали). Този списък може да включва: описание на компанията, с кого си сътрудничат, какви награди и сертификати имат, цени и ценови листи, продуктов каталог и описание на стоките, описание на услугите, информация за контакт, публикувана на сайта и др.

Понякога за клиента е трудно сам да опише услугите си или просто няма време за това. В този случай изпълнителят е готов да довърши работата по написването на липсващото съдържание за сайта (снимки, текстове, видео и др.).

* Предоставянето на клиента на необходимите материали е критично, защото:

необходимо е правилно да въведете цялото съдържание, предоставено от клиента, в оформлението на сайта наведнъж (няма смисъл да правите допълнителна работа);
технологичният процес на изпълнителя е разписан буквално "по минути" и не искаме да го нарушаваме и да си налагаме допълнителни разходи;
запълването на интернет проект с тестова информация също няма смисъл (първо, количеството ненужна работа отново се увеличава; второ, търсачките могат да песимизират хостван сайт с тестово съдържание; трето, вашите потенциални клиенти може да имат негативно отношение към сайта, което съдържа очевидно безполезна информация);
Важно е както за вас, така и за нас да изпълним проекта професионално и в срок.

* Уважаеми клиенти, моля не отлагайте изработката на собствен сайт и печелете от него. Предоставяйте съдържание навреме! В противен случай проектът ще бъде замразен до получаване на информация от Вас и съответно срокът за изпращане на сайта е отложен. Ако няма време за събиране и писане на информация, поръчайте писане на текстове и обработка на снимки при нас, това е евтино.

Успоредно с това се създава работна група по проекта и започва етапът разработване на дизайн оформлениебъдещ сайт.
След като проектното оформление е готово, то се изпраща на клиента за одобрение. Веднъж одобрен, макетът става валиден дизайн.

* В зависимост от сложността на проекта, на клиента може да бъде предоставен достъп до системата за управление на проекти (например Redmine), където можете да качвате необходимите ресурси на проекта, да наблюдавате етапите на разработка и да публикувате коментари.

За по-нататъшно продължаване на работата е задължително да получите от клиента всички необходими материали, чийто списък е бил изпратен на клиента по-рано.

Веднага след получаване на липсващите материали. Важно етап на развитие на сайтав съответствие с одобреното ТЗ.
Този етап включва голям брой видове работа: това е кросбраузърно оформление на оформления на сайта, разработване на необходимите шаблони за дизайн за избраната система за управление на съдържанието (CMS), инсталиране и конфигуриране на самата CMS, инсталиране на необходимите модули и компоненти, разработване на липсващи модули, цялостно проучване на алгоритмите за работа на уебсайта, попълване на сайта със съдържание, внедряване на проекта в техническата област и преминаване към тестване.

Тестването на интернет проекта се извършва от специалисти на изпълнителя, всички грешки и коментари са отстранени, сайтът е прецизно настроен за работа.

Веднага след като работата приключи и тестването на сайта в техническия домейн приключи, етап на предаване. Тук от страна на клиента се проверява изпълнението на изискванията на ТЗ и целия процес на функциониране на интернет проекта.
След като клиентът вземе решение относно пълното съответствие на сайта с изискванията на ТЗ, сайтът се прехвърля на клиента и проектът се публикува на хостинга.

Резултатът и потвърждението за предаване и приемане на работите е работещ обект и акт за приемане, който се подписва от двете страни. Подписаният акт, заедно с целия комплект документи за осчетоводяване, се изпраща по пощата.

След подписване на акта за приемане, клиентът, в съответствие с договора, заплаща останалата стойност на работата.

След окончателното изчисление, заедно с документите и сайта, клиентът получава ръководство за употреба, копие на сайта на DVDи безплатно техническа поддръжкав рамките на 2-4 седмици от датата на приемане на обекта.

В тази диаграма се опитахме да отразим напълно всички аспекти на взаимодействията от първоначалното обаждане до доставката на проекта. За прости проекти някои от стъпките могат да бъдат комбинирани или пропуснати. Но във всеки случай всичко е отразено в договора.

Схемата на работа за услугите „Комплексна разработка на уеб сайт“, както и „Популяризиране на уебсайт“ структурно повтаря описания по-горе процес на взаимодействие между клиента и изпълнителя и следователно не изисква подробно описание.

Надяваме се, че описаната схема на взаимодействие е прозрачна и разбираема. Ако все още имате въпроси, моля

Проект:	Разпределение на заявките към електронния каталог по индекси за търсене и термини за търсене
Обхват на проекта:	13.02.2006 - 05.06.2006
Клиент:	Научна библиотека на Петрозаводския държавен университет.
Отговорник:	Горшкова Галина Анатолиевна, ръководител на отдела за компютърна обработка на документи и създаване на каталози. електронна поща поща: . роб. тел.: 719602. Библиотека: каб. 102. Гуриев Дмитрий Борисович, водещ програмист на RCNIT. електронна поща поща: . роб. тел. 784775 Интернет център.
Инструктор:	Кулаков Кирил Александрович Електронна поща: . Служебен телефон: 711015. Стая 215
Информация за инструктора:	Група номер 13
Свързани документи:	Общ преглед на проекта План на проекта Работен график (диаграма на Гант) Изисквания Спецификация Тест за проектиране Документ за изпълнение Тестов документ Customer Engagement Developer Relations Отчети Напредък на разработката Речник на потребителя

Първа среща с клиента.

На първата среща екипът за разработка беше представен на клиента. Клиентът от своя страна говори за научната библиотека на ПетрГУ.

Библиотеката работи на базата на автоматизираната система "Фолиант". Електронният каталог е част от библиотечната система. Търсенето в каталог се извършва чрез заявки. Операторът генерира низове за търсене, които могат да съдържат голям брой индекси за търсене и думи за търсене. Всяка заявка се записва в лог таблица. Тази таблица съдържа данни за часа на заявката, адреса на клиента, направил заявката, самата заявка, резултата от заявката.

Клиентът трябва постоянно да наблюдава таблицата с регистрационни файлове и да предоставя някои статистически данни за използването на индекси за търсене.

Бяха представени и първоначалните изисквания към изпълнявания проект. Едно от изискванията е ефективното събиране на статистика. Тоест статистиката трябва да се показва след разумно време след изпращане на заявката. Поради това изискване разработчиците бяха насърчавани да използват процедури от страна на сървъра в PL/SQL.

Втора среща с клиента.

Клиентът предостави на разработчиците потребителско име и парола за влизане в електронната каталожна система, като предостави копия на две таблици за работа - журнална таблица и таблица с индекси за търсене.

Гуриев Дмитрий Борисович ни запозна по-подробно с работата в клиента на СУБД Oracle SQL*Plus. Екипът се запозна с работата на електронния каталог.

Системата "Фолиант" работи на базата на стандарта RusMark, който съдържа около 99 полета. Всяка библиотека, работеща с AIBS "Фолиант", избира полетата и подполетата, които ще използва. Има специални GOST, които описват правилата за съхранение на библиотечни данни. Тъй като има голям брой полета, създадохме система от индекси за търсене. Има служебни и обществени индекси.

Потребителите на справочника се делят на вътрешни и външни. Всеки отдел или служител има свои собствени права. Всеки запис за обект се анализира на отделни елементи и не се съхранява като цяло.

Трета среща с клиента.

Клиентът ни е предоставил писмено ясни изисквания.

Клиентът се интересува от следните статистики:

Броят на заявките към електронния каталог.

За последния месец по ден.
Месечно счетоводство за текущата година.
Счетоводство по години.
Създайте история на информацията.

Списък на заявките от за всекииндекс на търсене, където резултатът от търсенето е нулев.

Списък с често срещани заявки.

Анализ на изпълнението на заявки за определен период. Докладът трябва да включва следните статистически данни:

Броят на заявките.
Брой заявки за търсене.
Броят на сложните заявки.
Броят на успешните отговори.
Брой нулеви отговори.
Автор
Автор преп. произв.
Тип документ.
Географски раздел.
Въведете дата.
Дата на публикуване.
Заглавие.

Четвърта среща с клиента.

Специалист от клиента Guryev D.B. обясни тънкостите на инсталирането и конфигурирането на помощната програма SQL*Plus. Решението на проблема със стартирането на програмата беше инсталирането на пакета SQL * Net, също Guryev D.B. предостави точните имена на таблиците за разработчиците и добави още една таблица на разположение на екипа. Специалистът проучи архитектурния документ и предложи да се приложат практически всички видове архитектура и да се избере най-оптималната. В същото време е желателно да не се изгражда отново таблицата с дневник и, доколкото е възможно, като се реши конкретен проблем, да се обобщят данните от таблицата с дневник за по-нататъшно използване в различни местни статистики.

Клиент Gorshkova G.A. се запознаха с документа с изискванията, като ги одобриха.

Пета среща с клиента.

Гуриев Дмитрий Борисович, специалист от страна на клиента, беше поканен да инсталира необходимия софтуер за работа с СУБД "Oracle" на обучителния сървър на PetrSU. Вадим Анатолиевич Пономарев, който има административен достъп до сървъра на PetrSU, също участва в този процес от страна на университета.