База даних взаємовідносин з клієнтами станції технічного обслуговування автотранспорту

Не рекомендується включати до таблиці дані, які є результатом виразу. У таблиці має бути вся необхідна інформація. Інформацію слід розбивати на найменші логічні одиниці (наприклад, поля "Ім'я" і "Прізвище", а не загальне поле «Ім'я»).

Поставити ключове поле. Для того щоб Microsoft Access міг зв'язати дані з різних таблиць, наприклад, дані про клієнта і його замовлення, кожна таблиця повинна містити поле чи набір полів, які будуть задавати індивідуальне значення кожного запису в таблиці. Таке поле чи набір полів називають основним ключем.

Визначити зв'язки між таблицями. Після розподілу даних по таблицях і визначення ключових полів необхідно вибрати схему для зв'язку даних у різних таблицях. Для цього потрібно визначити зв'язки між таблицями.

Ще раз переглянути структуру бази даних і виявити можливі недоліки. Бажано це зробити на даному етапі, поки таблиці не заповнені даними.

Додати дані і створити інші об'єкти бази даних. Якщо структури таблиць відповідають поставленим вимогам, то можна вводити всі дані. Потім можна створювати будь-які запити, форми, звіти, макроси і модулі.

Використовувати засоби аналізу в Microsoft Access. У Microsoft Access існує два інструменти для вдосконалення структури баз даних. Майстер аналізу таблиць досліджує таблицю, в разі потреби пропонує нову її структуру та зв'язки, а також переробляє її. Аналізатор швидкодії досліджує всю базу даних, дає рекомендації щодо її поліпшення, а також здійснює їх.

Створення бази даних

Логічне проектування

Створення БД представляє собою наступну фазу, після планування та швидкого аналізу. Після створення вихідної БД можна почати розробку меню, після чого слідує розробка функцій, тобто створюється робоча модель. Потім модель демонструють користувачеві з метою отримання пропозицій щодо її удосконалення, які об'єднуються в послідовні ітерації до тих пір, поки робоча модель не задовільнить споживача. Потім отримують офіційне схвалення користувачем функціональних можливостей прототипу.

Предметом дослідження дипломного проекту є БД обліку технічного обслуговування автотранспорту.

Адміністратору БД СТО може знадобитися інформація про власників транспортного засобу, робітників, які несправності містить транспорт, а також час ремонту та звіт роботи СТО.

Розроблювана інформаційна система повинна виконувати наступні функції:

Надання великої сукупності інформації у вигляді таблиць БД

Формування різних запитів по:

обслуговування автотранспорту, номер його госреєстації, марка транспорту, модель, колір, № двигуну, № кузову, рік випуску, пробіг транспорту на момент реєстрації, та певні примітки;

дефекти (опис та можливий спосіб усунення);

робітники (Ф.І.ПБ., паспортні дані, телефон, спеціалізація);

власники транспорту (паспортні дані, Ф.І.ПБ., телефон);

система взаємовідносин з клієнтами яка повинна містити в собі клієнтів, спосіб звернення, робітника який обслуговував, тему за якою звертаються, суть проблеми, дії по зверненню, дата виконання та оцінку на скільки задоволений клієнт.

Вивід інформації у вигляді звітів.

На основі швидкого аналізу, для наглядного представлення компонентів БД була розроблена концептуальна модель (рис. 3.3) На концептуальному рівні здійснюється інтегрований опис предметної області, для якої розглядається БД, незалежно від її сприйняття окремими користувачами та способів реалізації в комп'ютерній системі.

Рисунок 3.3 Ї Концептуальна модель

Концептуальна модель бази даних Ї це високорівнева об'єктно-орієнтована модель предметної області, що представляє об'єктну область у вигляді набору об'єктів, що володіють певними властивостями і знаходяться в деяких відносинах [44]. Основна мета розробки високорівневої моделі даних полягає у створенні моделі користувацького сприйняття даних та узгодження великої кількості технічних аспектів, пов'язаних з проектуванням бази даних. Концептуальна модель даних не прив'язана до конкретної фізичної реалізації баз даних і не залежить від конкретної СКБД. Концептуальна модель створюється на основі уявлень про предметну область кожного типу користувачів, що представляють собою набір даних, необхідних користувачеві для вирішення своїх завдань. Основні концепції моделі включають такі поняття як сутність (об'єкт), відношення (зв'язок), типи сутностей, типи зв'язків та атрибути.

При проектуванні БД слід дотримуватися правил нормалізації таблиць [45]:

Кожне поле будь-якої таблиці повинне бути унікальним.

Кожна таблиця повинна мати унікальний ідентифікатор (первинний ключ), який може складатися з одного або декількох полів таблиці.

Для кожного значення первинного ключа повинно бути одне і тільки одне значення кожного з стовпців даних, і це значення повинно ставитися до об'єкта таблиці.

Повинна бути можливість змінювати значення будь-якого поля (не входить в первинний ключ), і це не повинно спричинити за собою зміну іншого поля [].

З описання предметної області виведемо всі типи сутностей:

Власники;

Транспорт;

Дефекти;

Робітники;

Замовлення;

Види робіт;

Категорія дефектів;

Спосіб звернення;

Задоволеність клієнта.

Тепер для кожного об'єкту встановимо потенційний ключ, після чого здійснимо вибір первинного ключа. При виборі первинного ключа будемо керуватися правилами:

Будемо використовувати ключ з мінімальним набором атрибутів.

Використовувати слід той ключ, ймовірність зміни значень якого мінімальна.

Значення ключа повинно мати мінімальну довжину.

З обраним ключем користувачеві буде зручніше працювати.

Фізичне проектування

На етапі фізичного проектування створюються таблиці. Нижче представлені рисунки таблиць, та відповідними типами даних полів (рис. 3.4 -- 3.16).

Рисунок 3.4 -- Структура таблиці «Власники»

Рисунок 3.5 -- Структура таблиці «Робітники»

Рисунок 3.6 -- Структура таблиці «Транспорт»



Рисунок 3.7 -- Структура таблиці «Замовлення»

Рисунок 3.8 -- Структура таблиці «Дефект»

Рисунок 3.9 -- Структура таблиці «Види робіт»

Рисунок 3.10 -- Структура таблиці «Категорія дефектів»

Рисунок 3.11 -- Структура таблиці «Спосіб звернення»

Рисунок 3.12 -- Структура таблиці «Задоволеність клієнта»



Рисунок 3.13 -- Структура таблиці «Дефект транспорту»

Рисунок 3.14 -- Структура таблиці «Власники транспорту»

Рисунок 3.15 -- Структура таблиці «Послуги замовлення»

Рисунок 3.16 -- Структура таблиці «Взаємодії з клієнтом»

Структура БД

Структура БД -- це визначення таблиць і атрибутів (полів) з їх типами, властивостями, умовами на значення.

Існують 3 типи структур даних [46]:

Деревовидна (ієрархічна) -- її зручно використовувати при опису даних про родовід від одного предка.

Мережева - використовується для задання даних про родовід від двох предків.

Реляційні структури -- дані організовуються в двовимірних таблицях.

В сучасних СКБД використовується реляційна структура. Ця конструкція була запропонована в 1970 році Коддом. Він показав що представлення даних з допомогою ієрархічної чи мережевої структури може бути зведена до реляційної структури.

Реляційні модель на сьогоднішній день набули великої популярності і практично всі сучасні СБД орієнтовані на таке представлення даних.У реляційних моделях таблиця розглядається як безпосереднє сховище даних. Традиційно в реляційних системах таблицю називають відношенням.Рядок таблиці називають кортежем, а стовпчик атрибутом, при цьому атрибути мають унікальні (в межах відношення) імена. Кількість кортежів в таблиці називають кардинальним числом, а кількість атрибутів степенем.

У відношень є такі основні властивості:

в загальному випадку в відношеннях не буває двох однакових кортежів;

кортежі не впорядковані з верху в низ, тому що в відношеннях відсутнє поняття позиційного номеру;

атрибути не впорядковані з ліва на право.

значення атрибутів складаються з логічно неділимих одиниць.

Після того, як були обрані первинні ключі, наступним кроком є подання зв'язків між таблицями. В реляційній моделі всі зв'язки представляються шляхом приміщенняпервинного ключа однієї таблиці в іншу. У другій таблиці такий ключ називется зовнішнім.

Між двома сутностями, наприклад, А і В можливі три види зв'язків.

Перший тип -- зв'язок ОДИН-ДО-ОДНОГО (1:1): у кожен момент часу кожному представнику (екземпляру) сутності А відповідає 1 або 0 представників сутності В:

Другий тип -- зв'язок ОДИН-ДО-БАГАТЬОХ (1: М): одному представнику сутності А відповідають 0, 1 або кілька представників сутності В.

Третій тип -- зв'язок БАГАТО-ДО-БАГАТЬОХ (N: М): Access не підтримує такий тип. Такий зв'язок є спірним (як би не існуючим).

В даному проекті присутній один вид зв'язку -- зв'язок ОДИН-ДО-БАГАТЬОХ, який продемонстрований на рис 3.17.

Рисунок 3.17 Ї Схема даних «Структура БД»Функції системи

Розробка запитів, та звітів

Запитам притаманна велика кількість функцій. За допомогою запитів можна переглядати, аналізувати і змінювати дані з однієї і навіть кількох таблиць. Запити дозволяють також відновити або видалити одночасно декілька записів, виконати вбудовані або спеціальні обчислення Вони також використовуються в якості джерела даних для форм і звітів. Але в першу чергу запити призначені для відбору даних на підставі критеріїв.

В Access існує два способи побудови запитів: конструктор та режим SQL. SQL Ї це мова програмування, призначена для роботи з наборами фактів і відносинами між ними. Для прикладу розглянемо декілька запитів. Спочатку розглянемо запит створений за домопогою конструктору (рис. 3.18).

Рисунок 3.18 Ї Запит «Дефекти транспорту»

Цей запит виводить замість коду категорії (числа) - назву категорії.

Розглянемо запит, який будується мовою SQL. (рис. 19).

Рисунок 3.19 -- Запит «Історія звернень клієнта»

Джерелами даних для звітів можуть бути дані однієї таблиці, дані з декількох таблиць і запити як однотабличні, так і багатотабличні. При виборі полів для звіту допускається вибір декількох таблиць або кількох запитів. У практичній діяльності найбільше застосування знаходять звіти на основі багатотабличних запитів.

В однотабличних звітах можуть створюватися обчислювані поля для підсумкових розрахунків.

Створимо однотабличний звіт у якому вказується список усіх клієнтів «Список клієнтів» (рис. 3.20). Окрім цього на звіті вказується дата, час, скільки всього клієнтів, та нумеруються сторінки.

Рисунок 3.20 -- Звіт «Власники»

Звіт «Власники транспорту» (рис. 3.21) виводить інформацію про власника та його транспорт.

Рис 3.21 Ї Звіт «Власники транспорту»

Звіт «Робітники» виводить основну інформацію про персонал (рис 3.22).

Рис. 3.22 -- Звіт «Список робітників»

Ітеративне прототипування та користувацький інтерфейс

Потім починається ітераційний цикл швидкого прототипування. Розробник проекту демонструє прототип, а користувач оцінює його функціонування. Після цього визначаються проблеми, над усуненням яких спільно працюють користувач і дизайнер. Цей процес продовжується до тих пір, поки користувач не буде задоволений тим, яким чином система відображає поставлені до неї вимоги. Команда розробників проекту продовжує виконувати цей процес до тих пір, поки користувач не погодиться, що швидкий прототип в точності відображає системні вимоги.

Для простоти перегляду, введення та зміни даних безпосередньо в таблиці Ї створюються форми. При відкритті форми -- Microsoft Access відбирає дані з однієї або більше таблиць і виводить їх на екран. У формі можуть відображатися поля з кількох таблиць. Крім того, форма дозволяє відображати малюнки та інші об'єкти. Форми є тим типом об'єктів БД, який зазвичай використовується для відображення даних в БД. Форму можна також використовувати як кнопкову форму, що відкриває інші форми або звіти, а також як діалогове вікно для введення даних і виконання дій, що визначаються введеними даними.

Розглянемо форму «Список клієнтів» (рис. 3.23). Дана форма представляє собою список усіх клієнтів СТО. В ній міститься код власника, за яким легко можна ідентифікувати особу, а також паспортні дані, прізвище, ім'я, по батькові та телефон. Для зручності пошуку необхідного клієнта є 3 поля: за фамілією, ім'ям та по батькові. Якщо потрібно видалити клієнта то потрібно лише вписати у поле «код клієнта» відповідний запис та натиснути кнопку «видалити».

Для збереження цілісності даних зміна полів не доступна. Щоб зареєструвати нового клієнта потрібно натиснути кнопку «Добавити клієнта» після чого відкриється форма «Реєстрація нового клієнта» (рис. 3.24), куди необхідно буде ввести основні дані стосовно власника та його транспорту.

Рисунок 3.23 -- Форма «Список клієнтів»



Рисунок 3.24 -- Форма «Реєстрація нового клієнта»

Для швидкого переходу за необхідною інформацією певного власника потрібно зробити два кліки на конкретне поле з записом і відбудеться перехід до форми «Відомості про клієнта» (рис. 3.25)

У даній формі міститься 3 вкладки: власник, транспорт та дефект транспорту.

На вкладці власник знаходиться вся інформація про клієнта, тут присутні персональний код власника, який не може повторюватись, паспортні дані, прізвище, ім'я, по батькові, телефон, та поле для певних приміток. Для необхідності можна змінювати, або доповнювати дані в таких полях як: телефон та примітки.

Рисунок 3.25 -- Форма «Відомості про клієнта», вкладка «Власник»

Розглянемо наступну вкладку «Транспорт» (рис. 3.26). На даній вкладці міститься повністю вся інформація про транспортний засіб. Вона включає наступні поля: № госреєстрації, марка транспорту, модель, колір кузову, № двигуна, № кузову, рік випуску, пробіг (на момент реєстрації транспортного засобу), та примітки. У цій вкладці можна змінювати та добавляти дані у всі поля окрім № госреєстрації.

Рисунок 3.26 -- Форма «Відомості про клієнта», вкладка «Транспорт»

Остання вкладка у даній формі -- «Дефект транспорту» (рис 3.27). Вона містить дві підпорядковані форми. Основна -- це дефекти даного транспорту конкретного власника, яка виводить наступну інформацію: № госреєстрації транспорту, дата та пробіг (на момент реєстрування дефекту), код дефекту, його опис, та спосіб усунення, також присутня категорія дефекту. Для легкого пошуку певного дефекту та способу його усунення представлена друга підпорядкована форма, яка містить список усіх дефектів. Якщо необхідний дефект присутній у списку, то для добавлення дефекту необхідного транспорту потрібно лише вписати у поле «код дефекту» потрібні значення і автоматично заповняться поля: опис, спосіб усунення, та категорія.

Рисунок 3.27 - Форма «Відомості про клієнта», вкладка «Дефект транспорту»

Розглянемо форму «Робітники» (рис. 3.28). У даній формі виводиться вся інформація про працівників СТО, та містить наступні поля: паспортні дані, Ф.І.ПБ. (фамілія, ім'я, по батькові), номер телефону, спеціалізація, та примітки. Для швидкого пошуку певного робітника необхідно ввести Ф.І.ПБ. у поле «пошук робітника». До речі, для полегшення введення даних, спеціалізація вибирається із списку.

Розглянемо форму «Замовлення» (рис. 3.29). Дана форма виводить інформацію про замовлення, яке зробив клієнт. Вона містить наступні поля: код замовлення, який не потребує введення, він генерується самостійно; дата замовлення; № госреєстрації транспорту; прізвище, ім'я та по батькові клієнта; Ф.І.ПБ. робітника який приймав замовлення; сума замовлення та примітки. Для статистики, присутнє поле, яке відображає загальну суму замовлень за весь період.

Рисунок 3.28 - Форма «Робітники»

Для реєстрації нового замовлення потрібно натиснути відповідну кнопку, відкриється форма «Реєстрація нового замовлення» (рис. 3.30). Для видалення запису необхідно натиснути кнопку «видалити запис».

Рисунок 3.29 - Форма «Замовлення»

Розглянемо форму «Реєстрація нового замовлення» (рис. 3.30). Дана форма містить наступні поля: код замовлення, який вводиться автоматично; дата; код власника, код транспорту, код робітника який обслуговував; сума заказу та примітки. Форма була створена для зручного добавлення нового замовлення за рахунок полів зі списком (код власника, код транспорту, код робітника), де відображаються усі клієнти, транспорт та робітники відповідно.

Рисунок 3.30 - Форма «Реєстрація нового замовлення»

Розглянемо форму «Взаємодія з клієнтами» (рис. 3.31). Дана форма найголовніша серед інших, так як вона включає CRM - систему. Форма містить наступні поля: код власника, паспортні дані, ім'я, фамілія, по батькові клієнта. Підпорядкована форма виводить інформацію про усі звернення клієнта, та містить наступні поля: код власника, дата звернення, спосіб звернення, Ф.І.ПБ робітника який обслуговував, тема звернення, суть проблеми, дії по зверненню, та поле яке вказує чи задоволеним залишився клієнт. Для швидкого переходу до певного клієнта форма містить поле зі списком, в якому відображаються усі клієнти. Щоб зареєструвати нове звернення потрібно натиснути відповідну кнопку і відкриється нова форма «Реєстрація проблеми звернення» (рис. 3.32)



Рисунок 3.31 - Форма «Взаємодія з клієнтами»

Розглянемо форму «Реєстрація проблеми звернення» (рис. 3.32). Вона включає в себе наступні поля: код власника, дата звернення, спосіб звернення, тема, суть проблеми, дії по зверненню, який робітник обслуговував та дата виконання. Форма призначена для комфортного та швидкого реєстрування проблеми за рахунок полів зі списком (код власника, спосіб звернення, та який робітник обслуговував).

Рисунок 3.32 - Форма «Реєстрація проблеми звернення»

Після створення основних форм можна приступити до створення головної кнопкової форми.

Форма «Станція технічного обслуговування автотранспорту» (рис. 3.33) являється головною кнопковою формою, за допомогою якої здійснюється легке та швидке управління БД. Вона містить 4 кнопки: клієнти, замовлення, персонал та вихід.

Рисунок 3.33 - Головна форма «СТО»

При натисканні кнопки «клієнти» відкривається інший список кнопок, за допомогою яких можна виконувати дії стосовно клієнтів, тобто відкрити потрібну форму або звіт. Також можна повернутися до головної форми (рис. 3.34).

Рисунок 3.34 - Головна форма «СТО»

Після виконаних дій над клієнтами, можна повернутися на головну форму і перейти до «замовлень» (рис. 3.35).

Рисунок 3.35 - Головна форма «СТО»

При натисканни на кнопку «Персонал» відкривається наступна форма (рис. 3.36)

Рисунок 3.36 - Головна форма «СТО»

Підгонка проектних вимог та програмного забезпечення

При розробці виробничої версії програми, може виникнути необхідність у додатковій роботі. Може знадобитися більш високий рівень функціональних можливостей, різні системні ресурси, необхідні для забезпечення повного робочого навантаження, або обмеження в часі.

Отримавши схвалення користувача, швидкий прототип перетворюють в детальний проект, і систему налаштовують на виробниче використання. Саме на цьому етапі налаштування, прискорений прототип стає повністю діючою системою, яка замінює собою часткову систему, отриману в ітераційному циклі прототипування.

Деталізований проект можна також отримати на основі прототипів. В цьому випадку настройка прототипу виконується при використанні коду або зовнішніх утиліт. Дизайнер використовує затверджені вимоги в якості основи для проектування виробничого ПО.

При розробці виробничої версії програм, може виникнути необхідність у додатковій роботі. Може знадобитися більш високий рівень функціональних можливостей, різні сістемні ресурси, необхідні для забезпечення повно робочого навантаження, або обмеження в часі.

Можливі шляхи розвитку системи

Оскільки БД СТО автотранспорту є прототипом, то можна розглянути шляхи подальшого розвитку системи.

Створивши базу знань, БД зможе аналізувати дані клієнтів, транспорту, дефектів, що дасть змогу системі самостійно оцінити можливість поломки, чи необхідність проведення техогляду автотранспорту (рис. 3.37).

Рисунок 3.37 -- Взаємодія БД з базою знань

Можна розглянути її в якості хмарного сервісу (рис.3.8.).

Рисунок 3.38 -- Хмарний сервіс «СТО»

У разі розширення підприємства, робітники зможуть при огляді транспорту, з периферійного пристрою відразу заповнити необхідні форми, що значно підвищить швидкість, та зручність.

ВИСНОВКИ

В результаті виконаного дипломного проекту розглянуті основні принципи побудови систем взаємовідносин з клієнтами. Як елемент таких систем була обрана задача створення бази даних обслуговування клієнтів СТО. Для реалізації задачі був проведений огляд моделей життєвих циклів створення програмного продукту та обрана модель прототипування для реалізації поставлених завдань.

На її основі створена структура БД взаємовідносин з клієнтами СТО, яка включає в себе блоки інформації про клієнта, транспортний засіб, дефекти, недоліки та способи їх усунення. Встановлені основні типи зв'язків між елементами структури. Для зручного використання створеної БД СТО був розроблений інтерфейс який дозволяє ефективно та надійно використовувати інформацію про взаємовідносини «клієнт-СТО».

Реалізація бази даних була відтворена у середовищі розробки MS Access. Реалізація програмного коду прототипу системи дасть змогу легко розширити структуру бази за рахунок внесення нових елементів, об'єктів тощо, для більш детального аналізу взаємовідносин «клієнт-СТО».

Запропонована структура бази даних може стати основою для створення бази знань за особливостями ремонту певних видів автотранспорту та його окремих вузлів, за рахунок автоматизації обліку дефектів та способів їх усунення.

Створена БД була практично випробувана на реальних даних по обслуговуванню клієнтів СТО м. Славутич, за результатами якої був отриманий позитивний відгук.

СПИСОК ПОСИЛАНЬ:

1. International Organization for Standardization. [Електронний ресурс] / Режим доступу: http://www.iso.staratel.com/

2. Всё о CRM: [Customer Relationship Management] А. Албитов, Е. Соломатин. / Информация и бизнес. -- 2007. № 2

3. CRM [Електронний ресурс] / Википедия -- свободная энциклопедия. Режим доступу: http://ru.wikipedia.org/wiki/Crm

4. Что такое SFA? [Електронний ресурс] / Режим доступу:

http://www.softservebs.com/company/press-room/e/108/

5. ERP системы. Современное планирование и управление ресурсами предприятия. Выбор, внедрение, эксплуатация. --Дэниел О'Лири. -- с.56

6. Вертоградов В. Развертывание CRM-системы как рациональный первый шаг в постановке маркетинга. [Електронний ресурс] / Режим доступу: http://www.intalev.ru/agregator/marketing/id_3489/

7. Кадыков М. Битва за клиента: «Фронт» и «Тыл» / М. Кадыков // Отдел Маркетинга -- 2006. -- № 10. -- 32-33 с.

8. Всё о CRM [Електронний ресурс] / Режим доступу: http://all-crm.org.ua/

9. Пейн Є. Руководство по CRM. -- Минск: Гревцов Паблишер, 2007. -- 374 с.

10. Баканов М. И., Шеремет А. Д. Теория экономического анализа. М.: Финансы и статистика, 2003 -- 200 с.

11. Синило Л. Сложнее, чем кажется -- внедрение CRM / Л. Синило // Новый Маркетинг. -- 2006. -- № 3. -- 87-95 с.

12. Джил Діше. CRM-навігатор: посібник з управління взаєминами з клієнтами / Джил Діше; пер. з англ. О. Сисоєвої. -- К.: Видавництво Олексія Капусти підрозділ Агентства «Стандарт», 2006. -- 375 с.

13. Анализ финансово-хозяйственной деятельности предприятия: Учебное пособие. Под ред. Чернышёва Ю. Г., Чернышёва Э. А. -- Москва: ИКЦ «МарТ»; Ростов н/Д: Издательский центр «МарТ», 2003 г. -- 304 с.

14. Международная научная лаборатория по внедрению нечетко-множественных подходов в экономических исследованиях. CRM как инструмент развития банка [Електронний ресурс] / Режим доступу: http://www.ifel.ru/br6/5.pdf

15. Туроператор [Електронний ресурс] / Режим доступу:

http://franchising.ua/franshiza/119/join-up/

16. Особенности CRM в страховых компаниях [Електронний ресурс] / Режим доступу: http://www.norbit.ru/press/articles/crm/933.html

17. Microsoft Dynamics CRM [Електронний ресурс] / Режим доступу: http://iqusion.com/ru/productsandservice/business/crm/320-md

18. SAP CRM [Електронний ресурс] / Режим доступу:

http://inneti.com.ua/konsaltynh/biznes-konsaltynh/crm-sistemy/sap-crm/

19. CRM для IT-компаний [Електронний ресурс] / Режим доступу: http://www.itjob.kh.ua/product.php3?product=41

20. Иллюстрированный самоучитель по SQL для начинающих. --123 с. [Електронний ресурс] / Режим доступу

http://www.books-online.org.ua/b3_2/b3_2_p122.htm

21. Основи SQL-технології [Електронний ресурс] / Режим доступу:

http://buklib.net

22. Хоменко, О.Д. Основи сучасних комп'ютерних технологій: підручник / А.Д. Хоменко. -- М.: Гардаріки, 2005. -- 415 с.

23. Пушкар О.І. Система управління базами даних Microsoft Access і її застосування в економіці. Навчальний посібник / А.І. Пушкар, І.П. Коврижних, А.М. Мокринська. -- Харків: Вид. ХГЕУ, 2002. -- 112 с.

24. Дейт К.Дж. Введення в системи баз даних -- Introduction to Database Systems. -- 8-е изд. -- М.: «Вільямс», 2006. -- 236 с.

25. Фрідланд А.Я. Інформатика і комп'ютерні технології. А.Я. Фрідланд, Л.С. Ханамірова. -- М.: Астрель., 2003. -- 204 с.

26. Управление взаимоотношениями с клиентами СТО [Електронний ресурс] / Режим доступу: http://www.a-master.com.ua/site/content/page/professional-articles-110-management-101

27. ISO/IEC TR 24748-1. Systems and software engineering -- Life cycle management -- Part 1: Guide for life cycle management

28. Якунин, Ю.Ю. Технологии разработки программного обеспечения: учеб. пособие / Ю.Ю. Якунин. -- Красноярск: ИПК СФУ, 2008. -- 232 с.

29. Братищенко В.В. Проектирование информационных систем. -- Иркутск: Изд-во БГУЭП, 2004. -- 84 с.

30. Cавельев М.В. ООП. Объектно-ориентированное проектирование программных продуктов. Курс лекций. Раздел ІІ -- Славутич, 2009. -- 79 с.

31. Избачков Ю.С., Петров В.Н. Информационные системы. Учебник для вузов. -- СПб.: Питер, 2005. -- 656 с.

32. Брауде Э. Технология разработки программного обеспечения -- СПб,: Питер, 2004. -- 655 с.

33. Карпенко С.Н. Введение в программную инженерию. Учебно-методические материалы по программе повышения квалификации «Информационные технологии и компьютерное моделирование в прикладной математике». Нижний Новгород, 2007. -- 103 с.

34. Глухова Л.А. Технологии разработки программного обеспечения. Белорусский государственный университет информатики и радиоэлектроники, 2007. -- 178 с.

35. Chapter 1 -- Introduction to the Microsoft Solutions Framework. [Електронний ресурс] / Режим доступу:

http://technet.microsoft.com/en-us/library/bb497060.aspx

36. Соммервилл, Иан. Инженерия программного обеспечения, 6-е издание.: Пер. с англ. -- М.: Издательский дом «Вильямс», 2002. -- 624 с.

37. Бобров Л.К., Савиных Н.Н., Бабченко Г.Л., Новосибирский государственный университет экономики и управления, Новосибирск, Россия. Обоснованный выбор модели жизненного цикла как фактор повышения качества разработки информационных систем, 2009.

38. Вендров А.М. Обзор средств проектирования информационных систем [Электронный ресурс] / Режим доступу:

http://www.citforum.ru/database/kbd96/42.shtml.

39. Шафер Дональд Ф., Фатрелл Роберт Т., Шафер Линда И. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. -- М.: Издательский дом «Вильямс», 2003. -- 1136 с.

40. Лаборатория информационные технологии. [Електронний ресурс] / Режим доступу: http://www.itlab.unn.ru/MiniProjects/LCM/

41. Диаграмма Ганта [Електронний ресурс] / Режим доступу:

http://ru.wikipedia.org/Диаграмма_Ганта

42. Структура Декомпозиции Работ WBS [Електронний ресурс] / Режим доступу:

/ http://www.pmsoft.ru/knowledgebase/articles/detail.php?ID=1506

43. Microsoft Project [Електронний ресурс] / Режим доступу:

http://ru.wikipedia.org/wiki/Microsoft_Project

44. Андон Ф. И., Яшунин А. Е., Резниченко В. А. Логические модели интеллектуальных информационных систем. -- К.: Наук. Думка, 1999. --396 с.

45. Пасічник В. В., Резніченко В. А. Організація баз даних та знань. -- К.: Видавнича група BHV, 2006. -- 384 с.

46. Джексон Г. Проектирование реляционных баз данных для использования с микро ЭВМ. -- М.: Мир, 1991. -- 252 с.

Размещено на Allbest.ru

...