1.3 Мета проектування

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

1.4 Регламентація функцій системи

Система повинна виконувати наступні три групи функцій:

1). Группа: Функції пов’язані зі створенням бази даних

№	Назва функції	Категорія
1.	Створення бази даних по заданій предметній області	очевидна
2.	Введення до бази даних таблиць, що відповідають головним сутностям: “Замовлення”, “Водій”, “Клієнт”, “Автомобіль”	очевидна
3.	Побудова між таблицями правильних логічних зв’язків	очевидна
4.	Приведення усіх таблиць до 2-ої нормальної форми	схована
5.	Виключення появи NULL-значень в базі даних	схована

2). Группа: Функційні вимоги до ситеми

№	Назва функції	Категорія
1.	Можливість авторизації у системі за логіном та паролем.	очевидна
2.	Забезпечення редагування,видалення та додавання нових записів у режимі адміністратора та додавання нових замовлень у режимі диспетчера.	очевидна
3.	Можливість додавання нового запису у вибрану таблицю в режимі адміністратора.	очевидна
4.	Забезпечити внесення інформації про оплату, тариф, ефір, відсутність оплати, пільгове замовлення у режимі диспетчера.	очевидна
5.	Забезпечити пошук клієнта по порядковому номеру.	очевидна

3). Группа: Функціональність графічного інтерфейсу користувача

№	Назва функції	Категорія
1.	Використати стандартні графічні компоненти	очевидна
2.	Забезпечити зручність інтерфейсу користувача	очевидна
3.	Компоненти для введення даних підбирати у відповідності із типом даних (наприклад, checkBoxдля типуbool)	схована
4.	Кольори компонентів обрати такі, що не подразнюватимуть око та психіку користувача	очевидна
5.	Передбачити можливість зміни розмірів вікон програми	очевидна

1.5 Атрибути системи:

• Форма заповнення бази даних = за допомогою форм.

• Форма опитування = діалогова панель.

• Тип Бази Даних = MySQL.

• Тип СУБД = MySQL Manager.

• Тип ГІТ бібліотеки = Swing.

• Час запросу до БД = не більше 0,5 секунди.

• Мова програмування = Java.

• Операційна система = додаток повинен бути кроссплатформовим.

• Розмір головного вікна = приблизно ¼ екрану користувача.

• Можливість використання в мережі = розглядається.

6. Словник термінів

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

Диспетчер- користувач, який буде мати доступ тільки до створення та введення даних нового замовлення. Фактично, користувач, що прийматиме замовлення.

Замовлення– фактично, новий запис в таблиці Замовлення з інформацією про замовлення.

Кроссплатформовість– можливість запуску програми на різних ОС (мінімум на двох).

Ефір водія– фіксована сума, яку водій повинен заплатити один раз в місяць, працюючи на підприємстві.

6. Організаційно-технічні фактори

Розробники вимог до системи:Алексеев Євген, Гребенюк Богдан, Жумела Андрій.

Розробники програмної системи:Гребенюк Богдан, Жумела Андрій.

Розробники документації: Алексеев Євген.

2. Обгрунтування вибору моделі життєвого циклу

Одним з ключових понять проектування інформаційних систем є життєвий цикл проекту - Project Life Cycle Management (PLCM). В загальному випадку, життєвий цикл визначається моделлю й описується у формі методології (методу). Модель або парадигма життєвого циклу визначає загальну організацію ЖЦ і, як правило, основні його фази та принципи переходу між ними. Методологія (метод) визначає комплекс робіт, їх детальний зміст і рольову відповідальність спеціалістів на всіх етапах вибраної моделі ЖЦ; рекомендує практики (best practices), які дозволяють максимально ефективно використовувати відповідну методологію та її модель.

Наведемо означення моделі життєвого циклу програмної системи:

Модель життєвого циклу - структура, що складається із процесів, робіт та задач, які включають в себе розробку, експлуатацію і супровід програмного продукту; охоплює життя системи від визначення вимог до неї до припинення її використання.

З другого боку, автор концепцій та практик гнучкого моделювання (Agile Modeling), Скот Амблер (Scott W. Ambler), пропонує наступні рівні ЖЦ, що визначаються відповідним вмістом робіт:

• програмне забезпечення - проектна діяльність з розробки і розгортання програмних систем;

• програмна система - включає розробку, розгортання, підтримку і супровід;

• інформаційні технології - вся діяльність ІТ-відділу;

• організація/бізнес - охоплює діяльність організації в цілому.

Архітектура життєвого циклу. У стандарті ISO/IEC 12207 визначено область застосування ІС, дано ряд важливих визначень (таких, як замовник, розробник, договір, оцінка, випуск - реліз, програмний продукт, атестація і т.п.), процеси життєвого циклу і включено ряд приміток щодо процесу і питанням адаптації стандарту. Стандарт описує 17 процесів ЖЦ, розподілених за групами процесів:

Основні процеси життєвого циклу - Primary Processes

• замовлення - Acqusition;

• поставка - Supply;

• розробка - Development;

• експлуатація - Operation;

• супровід - Maintenance.

Допоміжні процеси життєвого циклу - Supporting Processes

• документування - Documentation;

• управління конфігурацією - Configuration Management;

• верифікація - Verification;

• атестація - Validation;

• сумісний аналіз - Joint Review;

• рішення проблем - Problem Resolution.

• організаційні процеси життєвого циклу - Organizational Processes

• управління - Management;

• створення інфраструктури - Infrastructure;

• вдосконалення - Improvement;

• навчання - Training.

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

Каскадна (водоспадна) модель

Основна характеристика – cлідуючи каскадній моделі, розробник переходить від однієї стадії до іншої строго послідовно. Спочатку повністю завершується етап «визначення вимог», в результаті чого виходить список вимог до ПЗ. Після того, як вимоги повністю визначені, відбувається перехід до проектування, в ході якого створюються документи, що детально описують для програмістів спосіб і план реалізації зазначених вимог.

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

Рисунок 2.1 – Схема каскадної моделі ЖЦ

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

Каскадна модель виділяє такі основні етапи життєвого циклу програм:

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

• Проектування. Повинен бути вибраний метод вирішення задачі та спроектований відповідний алгоритм.

• Кодування, яке полягає в написанні тексту програми відповідно до розробленого алгоритму.

• Відлагодження, яке полягає у виявлення та виправленні помилок.

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

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

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

• Зняття з експлуатації.

До переваг каскадної моделі належать:

– на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти і узгодженості;

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

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

Недоліками каскадної моделі є те, що перехід від однієї фази проекту до наступної пропонує повну коректність результату попередньої фази. Одна неточність якої небудь вимоги чи некоректна його інтерпритація в результаті приводить до того, що необхідно буде провести "відкат" до фази в проекті яка була раніше. Такі дії приводять до збільшення затрат на проект і не виключенно, до завершення проекту в формі, в якій він спочатку планувався.

Обгрунтування вибору:

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

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

1. Керування вартістю проекту

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

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

Вхідними даними для оцінки вартості є:

1. Ієрархічна структура робіт. Ієрархічна структура робіт (WВS – структура), вона використовується для упорядкування оцінок вартості і для забезпечення того, щоб була оцінена вся необхідна робота.

2. Вимоги до ресурсів – це описання того, які типи ресурсів і в яких кількостях необхідні по кожному елементу ієрархічної структури робіт.

3. Ресурсні норми. Окрема особа (група осіб), що працює над оцінками, повинна знати одиничні норми (погодинну зарплату персоналу, вартість кубічного ярда матеріалу тощо) по кожному ресурсу, для того щоб розрахувати проектні вартості. Якщо фактичні норми невідомі, то можна оцінити самі норми.

4. Оцінка тривалості робіт. Оцінка тривалості робіт мас вплинути на оцінки вартості в будь-якому проекті, в якому бюджет включає витрати на фінансування робіт -капіталовкладення.

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

Керування вартістю включає в себе наступні процеси:

• оцінку вартості проекту;

• контроль вартості проекту;

• простійну оцінку фізичних витрат;

• порівняння з раніше запланованими в бюджеті.

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

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

Всі витрати можна класифікувати як прямі та накладні витрати; одноразові та ті, що повторюються.

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

Методи оцінки вартості:

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

2. Параметричне моделювання. Параметричне моделювання включає використання властивостей (параметрів) математичної моделі для прогнозу вартості проекту. Моделі можуть бути простими, або складними.

3. Оцінка «знизу - вверх». Метод полягає в оцінці вартості окремих елементів робіт і подальшому підсумовуванні їх для отримання результату по проекту.

Вартість і точність оцінки «знизу - вверх» залежать від розміру окремих елементів робіт: чим дрібніші елементи робіт, тим вищі вартість і точність.

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

2. Керування часовими параметрами

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

1. Визначення складу робіт – ідентифікація конкретних робіт, виконання яких необхідно для створення кожного із продуктів проекту.

2. Визначення послідовності робіт – ідентифікація і документування логічних зв`язків між роботами.

3. Оцінка тривалості робіт – первісна оцінка тривалості кожної з робіт тим чи іншим способом.

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

5. Контроль за виконанням графіку робіт – відслідковування ходу виконання проекту і змін, внесених в первісну версію графіка.

Оцінка параметрів часу для робіт проводиться так:

(строк реалізації робіт) = (об`єм працезатрат (люд.*год.)) / (об`єм призначених трудових ресурсів(люд.)).

У нашому випадку строк реалізації робіт є рівним 101 дню. Об`єм призначених трудових ресурсів дорівнює трьом людям. Отже, об`єм працезатрат знаходимо, помноживши строк реалізації на об`єм трудових ресурсів і отримуємо 303 (людино-години).

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

Втрати часу в ході реалізації проекту виражаються в додаткових витратах часу на перепланування графіка виконання робіт. Це може бути пов'язано з тим, що: були допущені помилки ключових учасників проекту на стадії визначення змісту робіт, що виражаються в неврахуванні деяких цілей проекту, неточності у визначенні учасників проекту, основних віх виконання проекту і розробці структури розбиття робіт; процес планування грунтується на неповних даних; на оцінку показників проекту відводиться мало часу; при виконанні оцінок не враховуються історичні дані та попередній досвід; планування графіка робіт проводиться виключно групою планування, тоді як в цьому процесі обов'язково повинні брати участь ті, хто буде виконувати графік; неправильно сплановані потреби в ресурсах. Те ж стосується планування потреби у фінансових ресурсах, постачанні матеріалів і т. д.; ніхто не знає останніх цілей і завдань; при плануванні графіка робіт не враховані ризики; план проекту не містить необхідної детальної інформації. Коли таке трапляється, важко передбачити можливі проблеми; фактичний стан проекту не знаходить відображення в поточному графіку виконання робіт. Це може бути пов'язано з нечіткою організацією обміну інформацією між виконавцями робіт і проектним офісом, з тим, що при виникненні проблем люди можуть впасти в паніку і взагалі забути про існування плану. У результаті не відстежуються розбіжності між поточним і базовим графіками робіт, не приймаються необхідні для проекту рішення - «план та проект існують окремо один від одного».

Втрати часу на усунення браку виникають в результаті виконання робіт не у відповідності з вимогою якості, наприклад, при використанні неякісних матеріалів, некваліфікованих людських ресурсів або їх надмірне завантаження; простоях/затримках у виконанні робіт, які пов'язані, перш за все, з відсутністю умов для їх виконання. Це може виражатися або в неробочих погодних умовах, або в перебоях з постачаннями матеріалів і устаткування з вини постачальників і т. д.

3. Керування якістю

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

Якість – це цілісна сукупність характеристик об'єкта, що відносяться до його здатності задовольняти встановлені або передбачувані потреби.

Відповідно до Державного стандарту України ISO 9000-2001 встановлено вісім принципів управління якістю, які найвище керівництво може використовувати для поліпшення показників діяльності організації:

1) Орієнтація на замовника.

Організації залежать від своїх замовників і тому повинні розуміти поточні та майбутні потреби замовників, виконувати їхні вимоги і прагнути до перевищення їхніх очікувань;

2) Лідерство.

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

3) Залучення працівників.

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

4) Процесний підхід.

Бажаного результату досягають ефективніше, якщо діяльністю та пов'язаними з нею ресурсами управляють як процесом;

5) Системний підхід до управління.

Ідентифікування, розуміння та управління взаємопов'язаними процесами як системою, сприяє організації у результативнішому та ефективнішому досягненні її цілей;

6) Постійне поліпшення.

Постійне поліпшення діяльності організації в цілому слід вважати незмінною метою організації;

7) Прийняття рішень на підставі фактів.

Ефективні рішення приймають на підставі аналізування даних та інформації;

8) Взаємовигідні стосунки з постачальниками.

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

Ці вісім принципів управління якістю формують основу стандартів та системи управління якістю, які входять до стандартів серії ISO 9000.

Організація робіт по забезпеченню якості проекту включає:

- визначення робіт, необхідних для досягнення потрібного рівня якості;

- визначення відповідальних за здійснення цих робіт;

- розподіл робіт на функціональні частини;

- визначення відповідальних та виконавців по кожній роботі;

- створення зв’язків між різними роботами.

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

На цих вимогах базується найбільш поширений сьогодні метод системного управління якістю. За кордоном цей метод називають — Total Quality Management (TQM).

Відповідно з цим методом встановлюється єдина схема розробки і впровадження системи управління якістю:

1. Проводиться дослідження виробництва і готується спеціальна доповідь;

2. На основі обстеження і аналізу фактичного стану виробництва здійснюється вибір системи управління якістю і розроблюється Програма якості;

3. Розробляється система управління якістю. Програма якості, Настанова по управлінню із встановленим строками виконання включаються до загального плану проекту;

4. На спеціальній нараді за участю фірми-консультанта обговорюють деталі, терміни й організацію виконання програми якості, вносять корективи і приймають рішення (у тому числі з питань навчання й атестації персоналу);

5. Заходи з програми вносять у загальний план реалізації проекту;

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

Поняття «якість» слід відрізняти від поняття«градація». Під останнім розуміється категорія або розряд, присвоєний об'єктам, що мають те ж функціональне застосування, але інші вимоги до якості. Низька якість – це завжди проблема, низький сорт – не обов'язково.

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

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

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

Найважливішим елементом керівництва є регламентація відповідальності по системі якості – аналог матриці відповідальності. Стандарти ISO 9001 і EN 29001 покликані забезпечити якість при проектуванні, розробці, виробництві, монтажі, обслуговуванні і включають в себе елементи: відповідальність керівників; систему якості; аналіз контрактів; управління проектуванням; управління документацією та даними; закупівлі; управління продукцією, яка постачається споживачем; ідентифікацію виробу; управління процесом створення продукції; контроль і випробування; управління устаткуванням для контролю, вимірювань та випробувань; статус контролю та випробувань; управління невідповідною продукцією; коригувальні та запобіжні дії; вантажно-розвантажувальні роботи, зберігання, упакування, консервацію і постачання; управління реєстрацією даних про якість; внутрішні перевірки якості; підготовку кадрів; обслуговування.

Стандарти ISO 9003 та EN29003 покликані забезпечити якість при контролі кінцевої продукції та її випробуванні. Зазначені стандарти припускають розробку, впровадження та актуалізацію в рамках системи менеджменту якості так званих методологічних інструкцій по кожному з 20 перерахованих вище елементів системи якості. Склад інструкцій регламентований наведеними вище стандартами.