Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Курсак, записка.doc
Скачиваний:
13
Добавлен:
23.02.2016
Размер:
348.16 Кб
Скачать

3.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.

 

Рисунок 3.4– Діаграма Ганта

3.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.2– Виконання проекту за методом критичних шляхів

Етап проектування

Дата початку

Тривалість

Дата закінчення

03.09.

13.09.

14.09.

2 8.09.

3 0.09

29.09.

18.11.

25.11

19.11.

29.11.

03.12.

03.09.

05.12

09.12

1

Аналіз вимог і розробка

специфікації

03.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

05.12.

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 3.3– Діаграма за методом критичних шляхів

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

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

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