Розробка прикладного програмного забезпечення

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Курсовий проект

Розробка прикладного програмного забезпечення

Вступ

Поняття "інформаційна технологія" (ІТ) у сучасному контексті набуває особливої багатогранності та поширюється на всі області діяльності людини, оскільки інформація, що трансформується у дані, знання, інформаційні та програмні продукти, технологічні винаходи - є невід'ємною частиною сьогодення. Тому для ефективного вивчення ІТ-галузі необхідний усесторонній підхід, який дозволить об'єднати та узагальнити відомості ряду навчальних дисциплін, таких як "Комп'ютерні мережі та телекомунікації", "Інформаційні системи і технології" та "Сучасні Інтернет-технології". У навчальному посібнику авторами представлено нову концепцію комплексного аналізу ІТ-галузі, починаючи від базових термінів, таких як "технологія" та "інформація", до задач оптимізації створення інформаційного продукту, його захисту, технологій проектування інформаційних систем (ІС) і моделювання бізнес-процесів. Запропонований підхід орієнтований на економічну сторону ІТ та розглядає економічну інформацію, її властивості, способи формалізованого опису для класифікації та узагальнення. Проведений аналіз структури ІТ у посібнику дозволяє трактувати технологію як сукупність процесів, що використовують засоби та методи накопичення, обробки і передачі первинної інформації для отримання інформації нової якості про стан об'єкту, процесу або явища (інформаційного продукту). Створення нового інформаційного продукту, як правило, вимагає видобування знань шляхом обробки і узагальнення різнотипних даних економічного характеру, отриманих із різних джерел. Ця задача може бути вирішена з різним ступенем ефективності та великими часовими затратами, документальними способами отримання знань, такими як методи математичної статистики. Проте, ці методи не дозволяють знаходити і видобувати знання з масивів даних, а високі вимоги до кваліфікації кінцевих користувачів обмежують їх використання. Розглянуті у посібнику експертні технології видобування знань та прийняття рішень - виявлення знань в базах даних (Knowledge Discovery in Databases), технологія аналітичної обробки даних в реальному часі (OLAP), технологія аналізу сховищ даних (Data Mining), нейромережні технології штучного інтелекту та експертні системи дозволяють з більшою ефективністю отримати знання на основі аналізу прихованих закономірностей у масивах даних та прийняти оптимальне у певній ситуації рішення, використовуючи сучасні програмні засоби. Оскільки призначення ІТ полягає у виготовленні інформаційного продукту номінальної якості з оптимальними витратами, у посібнику досліджується галузь математичного моделювання бізнес-процесів та методів прийняття рішення з оптимізацією за заданим критерієм, з точки зору технологій динамічного програмування. Тенденція об'єднання комп'ютерів у мережі на сьогоднішній день набула завершеного вигляду, що втілилось у активний розвиток ІТ комп'ютерних мереж і, в тому числі, всесвітньої мережі Інтернет, а також галузі електронної комерції. У навчальному посібнику стисло викладено відомості про базові мережні технології, протоколи та сервіси, механізми пошуку, електронні платіжні системи. Окрему увагу приділено гіпертекстовій технології та технологіям створення web-вузлів - темі, що представляє особливий інтерес для творчих особистостей. Зважаючи на іншу сторону стрімкого розвитку ІТ, у посібнику неможливо було обминути гостро актуальні питання інформаційного піратства, розвинуті технології якого становлять суттєву загрозу інформаційному продукту. У посібнику розглянуто види інформаційних та програмних продуктів і можливі загрози для них в сучасному комп'ютерному середовищі. Детально досліджено питання захисту персональної інформації і протидії інформаційним та програмним продуктам шкідливого характеру, технологію забезпечення безпеки інформаційних систем, поняття ідентифікації, аутентифікації, політики безпеки тощо. Результати проведених досліджень та здійснених узагальнень щодо перетворення інформації на шляху до інформаційного продукту, необхідно враховувати і при проектуванні ІС, яка буде створювати інформаційний продукт. Для цього у навчальному посібнику проаналізовано етапи створення ІС та моделі її життєвого циклу, включно з архітектурою. Розглянуто також основні технології, що використовуються на кожному з етапів життєвого циклу ІС, для оптимізації процесів її проектування та функціонування.

1. Технічне завдання

1.1 Завдання проекту

Створити програму, що допоможе диспечеру таксі виконувати повсякденну роботу.

Зберігати дані водіїв, дані автомобілів, замовлення. Передбачити внесення інформації про оплату, тариф, ефір, відсутність оплати, пільгове замовлення.

Передбачити: Додавання, видалення та перегляд інформації.

1.2 Споживачі системи

Споживачем виступає юридична особа підприємства таксопарку та фізичні особи їх працівників. Фактично, споживачами будуть - диспетчери та адміністрація таксопарку.

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.

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

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

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

1.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лідуючи каскадній моделі, розробник переходить від однієї стадії до іншої строго послідовно. Спочатку повністю завершується етап «визначення вимог», в результаті чого виходить список вимог до ПЗ. Після того, як вимоги повністю визначені, відбувається перехід до проектування, в ході якого створюються документи, що детально описують для програмістів спосіб і план реалізації зазначених вимог.

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

Схема каскадної моделі ЖЦ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.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 перерахованих вище елементів системи якості. Склад інструкцій регламентований наведеними вище стандартами.

2.4 Діаграма Ганта

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

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

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

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

	Етап проектування	Дата початку	Тривалість	Дата закінчення	03.09.- 13.09.	14.09.- 2 8.09.	29.09.-18.11.	19.11.-29.11.	05.12.
1	Аналіз вимог і розробка специфікації	3.09.	10	13.09.
2	Проектування	14.09.	14	28.09.
3	Реалізація	29.09.	51	18.11.
4	Налагодження і тестування	19.11.	11	29.11.
5	Розробка документації	03.09.	98	09.12.

2.5 Метод критичних шляхів

Метод критичного шляху -- це метод планування робіт в рамках проекту, включаючи управління цими роботами і складання графіку їхнього виконання. Ключовим моментом методу є поняття «критичного шляху».

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

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

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

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

Резерв часу = дата пізнього початку -- дата раннього початку.

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

	Етап проектування	Ранній початок	Раннє закінчення	Пізній початок	Пізнє закінчення	Загальний часовий розрив
1	Аналіз вимог і розробка специфікації	3.09.	13.09.	3.09.	13.09.	0
2	Проектування	14.09.	28.09.	14.09.	30. 09.	2
3	Реалізація	29.09.	18.11.	29. 09.	25.11.	7
4	Налагодження і тестування	19.11.	29.11.	19.11	3.12.	5
5	Розробка документації	03.09.	05.12.	3.09.	9.12	5

3. UML-діаграми

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

При проектуванні вищеописаної системи були використанні такі UML-діаграми: діаграма варіантів використання, діграма слідування, діаграма класів та звісно ж концептуальна діаграма бази даних оскільки проектована програмна система буде містити базу даних (не відноситься до UML-діаграм).

3.1 Діаграма варіантів використання

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

Як видно з діаграми в даній системі є тільки 4 дійових особи:

· Замовник

· Диспетчер

· Водій TAXI

· Адміністратор

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

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

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

Діаграма варіантів використання.

3.2 Діаграма класів

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

Діаграма класів

3.3 Концептуальна діаграма бази даних

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

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



Концептуальна схема бази даних

3.4 Діаграма слідування

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

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

Діаграма слідування

4. Управління ризиками

Ризик (з грець. risikon -- стрімчак) -- небезпека втрат, непередбачуваних подій та дій розрахунку на щасливий випадок. Ризик є об'єктивним явищем, природа якого викликана неоднозначністю, невизначеністю подій. Невизначеність -- це множина станів внутрішнього та зовнішнього середовища проекту. Проектний ризик -- це небезпека небажаних відхилень від очікуваних станів проекту в майбутньому, із розрахунку яких і приймаються рішення в даний момент. Ризик у проекті є комбінацією обмежень і невизначеності. Можна звести до мінімуму ризик в проекті шляхом або усунення обмежень (що є достатньо проблематичним), або пошуку і зниження невизначеності. Планування та реалізація проектів відбувається в умовах невизначеності, яка породжується зміною внутрішнього та зовнішнього середовищ. Під невизначеністю розуміють відсутність повної та достовірної інформації про умови реалізації проекту. За характером дії ризики поділяють на прості та складні. Складні ризики є комбінацією простих ризиків. Прості ризики зумовлюються дією сукупності незалежних між собою подій. Отже ми визначили, що ризик у проекті є комбінацією обмежень і невизначеності.

Невизначеність в проекті може бути спричинена неспроможністю:

- визначити цілі проекту;

- зрозуміти, хто є зацікавленими особами цього проекту;

- призначення кваліфікованих фахівців, які підтримуються керівником, в команду проекту;

- точно оцінити витрати;

- визначити точно кінцевих користувачів результатів проекту;

- забезпечити хороші умови роботи команді проекту;

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

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

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

Ризик має три основні атрибути:

1) випадок, що містить ризик;

2) ймовірність;

3) наслідок (дія ризику).

Необхідно зрозуміти природу ризику і визначати, в яких ситуаціях він може виникнути

Ймовірність виникнення можна виміряти в кількісних (ведеться імовірнісна оцінка події в межах 0-100%), рідше в якісних показниках.

Ймовірність ризику (risk probability) -- це міра можливості того, що наслідок ризику дійсно буде мати місце.

Загроза ризику (risk impact) -- міра серйозності негативних наслідків, рівень збитків або оцінка потенційних можливостей, пов'я-заних з ризиком.

Є декілька видів випадків, які містять ризик для проекту:

1.  Випадки, які можуть статися.

2.  Випадки, які матимуть великі наслідки, якщо вони відбудуться.

3.  Випадки поза вашим контролем.

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

В залежності від джерела виникнення:

- природно-кліматичні;

- технічні;

- виробничі;

- економічні;

- ринкові;

- фінансові;

- соціальні;

- політичні;

- інноваційні;

- регіональні;

- галузеві;

- ризики навмисних дій (вандалізм, нечесність).

В залежності від місця виникнення:

- зовнішні;

- внутрішні.

В залежності від тяжкості проявів:

- втрачена вигода;

- збитки;

- втрата;

- банкрутство.

За ступенем передбачуваності:

- передбачувані з малою ймовірністю;

- непередбачувані.

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

...