Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Комп’ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2015
Тип роботи:
Методичні вказівки
Предмет:
Управління ІТ-проектами
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
УПРАВЛІННЯ IT-ПРОЕКТАМИ
МЕТОДИЧНІ ВКАЗІВКИ ТА ІНДИВІДУАЛЬНІ ЗАВДАННЯ
до лабораторних робіт з курсу
“Управління ІТ-проектами”
для студентів базового напряму 050101
“Комп’ютерні науки”
Затверджено
на засіданні кафедри
автоматизованих систем управління.
Протокол № _ від _____2015 р.
Львів – 2015
Управління ІТ-проектами : методичні вказівки та індивідуальні завдання до лабораторних робіт для студентів базового напряму 050101 «Комп’ютерні науки» / уклад. : О.Б. Шуневич – Львів : Видавництво Львівської політехніки, 2014. – 27 с.
Укладачі Шуневич О.Б., канд. техн. наук, асис.,
Відповідальний за випуск Батюк А.Є., канд. техн. наук, доц.
Рецензент Медиковський М.О., д-р техн. наук, проф.
ПОРЯДОК ВИКОНАННЯ ЛАБОРАТОРНИХ РОБІТ
Готуючись до лабораторного заняття, студент повинен:
повторити відповідний теоретичний матеріал та ознайомитися з прикладами, що пов’язані з тематикою виконуваної лабораторної роботи, використовуючи конспект лекцій, а також підтручники, навчальні посібники та методичні розробки до цієї теми;
уважно прочитати всі пункти завдання лабораторної роботи, занотувати у звіт тему роботи, мету та своє індивідуальне завдання.
Чітко визначити, що має бути отримане як результат розв’язування задачі і які вхідні дані для цього потрібні.
На лабораторному занятті студент повинен:
відповісти на поставлені йому запитання за темою лабораторної роботи;
використовуючи засоби інтегрованого інструментального середовища програмування, ввести, відредагувати та налагодити текст програми;
виконати програму для підготовлених наборів вхідних даних і зафіксувати отримані результати;
у разі необхідності внести в алгоритм розв’язування і текст програми необхідні зміни та доповнення і повторно виконати пункти 2 та 3;
оформити та захистити звіт про виконання лабораторної роботи.
ОФОРМЛЕННЯ ЗВІТУ ПРО ВИКОНАННЯ ЛАБОРАТОРНОЇ РОБОТИ
Звіти про виконання лабораторних робіт оформляють в окремому зошиті, який в кінці семестру (після захисту всіх лабораторних робіт) здають на кафедру. Можна оформляти звіти на аркушах формату А4 – в цьому випадку перед здаванням на кафедру всі звіти необхідно зброшувати.
Звіт до кожної роботи повинен починатися з нової сторінки і містити такі розділи:
заголовок лабораторної роботи;
тема лабораторної роботи;
мета виконання лабораторної роботи;
результати виконання кожного пункту завдання – дії, що виконувались відповідно до цього пункту завдання і засоби, що використовувались для їхньої реалізації;
індивідуальне завдання (формулювання);
постановка задачі (у випадку, коли формулювання індивідуального завдання потребує доповнення або конкретизації);
алгоритм розв’язування задачі – у формі блок-схем і/або стислого словесного опису вибраних методів та основних кроків процесу реалізації задачі;
текст програми мовою C# і ін;
результати комп’ютерної реалізації програми для різних наборів вхідних даних, які підтверджують правильність роботи програми і встановлюють область її застосування – треба вказати форму введення даних та їхні значення, а також форму і значення отриманих результатів для кожної реалізації;
висновки, в яких необхідно зазначити, які знання отримано під час виконання роботи; а також навести коротку характеристику розробленої програми і зазначити можливі варіанти її застосування та вдосконалення.
Звіт має бути написаний чітко, грамотно, з дотриманням норм ділової документації. Кожен розділ звіту слід виділяти відповідним заголовком і візуально (підкресленням, розміром літер тощо). Оформлений звіт після захисту лабораторної роботи підписує викладач.
ЗАВДАННЯ ДО ЛАБОРАТОРНОЇ РОБОТИ
Лабораторна робота №1
Тема роботи: Структуризація та планування проекту. Робота в Microsoft Project.
Мета роботи: навчитися документувати вимоги до проекту; здобути навики щодо формування цілей проекту і плану проекту; навчитися працювати в середовищі Microsoft Project і розробляти модель виконання проектних робіт.
1. ТЕОРЕТИЧНІ ВІДОМОСТІ
1.1. Планування проекту – встановлення і документування вимог
Встановлення вимог – перший етап життєвого циклу розроблення системи. Мета встановлення вимог полягає у тому, щоб дати розгорнуте визначення функціональних – а також нефункціональних вимог, які учасники проекту очікують затвердити у системі, що реалізується.
Вимоги визначають послуги що очікуються від системи і обмеження, яким система повинна підкорятися.
Вимоги необхідно отримати від замовників (майбутніх користувачів і власників системи). Цей вид діяльності, що називається «виявленням вимог» здійснюється аналітиком бізнес-процесів (або системним аналітиком). Для цього підходять різні методи, починаючи з традиційних інтерв’ю із замовником і закінчуючи побудовою програмного прототипу, за допомогою якого розкриваються додаткові вимоги.
Зібрані вимоги повинні бути піддані ретельному аналізу для виявлення повторень і суперечностей. Це призводить до перегляду вимог і іх повторного погодження з замовником.
Вимоги, задовільні з точки зору замовника, документуються. При цьому вимогам дають визначення, класифікують, нумерують і присвоюють їхні пріоритети. Хоча документ, що фіксує вимоги, містить в значній мірі описовий характер, цілком можливо включити у нього високорівневу схематичну бізнес-модель. На цьому зупинимось детальніше.
Більшість організацій виробляють документ опису вимог відповідно до заздалегідь визначеного шаблону [2-Мацяшек].
Під час документування вимог виконують:
словесний опис отриманої інформації;
створюють графічні моделі у вигляді діаграм, графіків, схем, потоків;
формальні специфікації і ін.
У вступній частині документа розглядається бізнес-контент проекту, включаючи назву проекту, суть проекту, цілі проекту. Наступним розділом є інформація про зацікавлених осіб і ресурси: інформація про керівника проекту і його повноваження; зацікавлені особи і ресурси (замовник проекту, ключові користувачі, спонсор, куратор, команда проекту, інфраструктура).
Ядро документа опису вимог складається з формулювання (викладу) вимог до продукту. Вимоги можуть бути згруповані у вигляді формулювань сервісів (часто називають функціональними вимогами) і формулювань обмежень. Формулювання суті сервісів можуть бути потім розділені на функціональні вимоги і вимоги до даних. Функціональні вимоги включають ряд користувацьких сценаріїв (use cases), які описують всі варіанти взаємодії між користувачем і програмним забезпеченням.
Ближче до завершальної частини документа піднімаються інші проектні питання, включаючи: план-графік виконання проектних робіт; обмеження проекту (дата завершення і бюджет проекту, обмеження по виконанні і організації робіт); ризики і ін.
Шаблон специфікації програмного забезпечення. Існують різні державні, галузеві і корпоративні стандарти щодо написання специфікації програмного забезпечення. Шаблони для документів опису вимог широко доступні. Їх можна знайти в підручниках, стандартах організацій ISO, IEEE і т.п., на Web-сторінках консалтингових фірм, програмних засобах розроблення і.т.д. Як вже зазначалось, з часом кожна організація розробляє свої власні стандарти, які відповідають прийнятій у організації практиці, корпоративній культурі, типам систем що розробляються і т.д.
Шаблон визначає структуру, стиль і містить детальні вказівки про зміст кожного розділу докумена.
Найбільш розповсюдженими в Україні є наступні шаблони:
IEEE 830-1998 “Recommended Practice for Software Requirements Specification”.
ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».
Перелічені шаблони не є догмою і їх слід модифікувати при необхідності у відповідності до природи і потребам проекту.
В таблиці 1 подано типічний зміст документа опису вимог.
Таблиця 1. Базовий приклад змісту шаблону специфікації вимог.
1
Вступ
1.1 Назва проекту
1.2 Суть проекту
1.1 Ціль проекту
1.2 Межі проекту
1.3 Посилання
2
Зацікавлені особи і ресурси
2.1 Замовник проекту
2.2 Куратор проекту
2.3 Команда проекту, її ролі
2.4 Класи і характеристики користувачів створюваної системи
2.5 Операційне середовище
3
Специфікація вимог
3.1 Функціональні вимоги
3.1.1 Опис і пріоритети
3.1.2 Послідовність «дія-реакція»
3.1.3 Перелік варіантів використань
3.2 Графічне представлення моделі системи
3.2.1 Діаграма прецедентів
3.2.2 Діаграма класів
3.2.3 Діаграма компонентів
3.3 Інші вимоги
3.2.1 Зручність використання
3.2.2 Вимоги до ліцензування
3.2.3 Вимоги до даних
4
Вимоги до зовнішнього інтерфейсу
4.1 Інтерфейс користувача
4.2 Інтерфейс обладнання
4.3 Інтерфейси передачі інформації
5
Нефункціональні вимоги (системні обмеження)
5.1 Вимоги дизайну і реалізації
5.2 Вимоги до продуктивності
5.3 Вимоги до безпечності
5.4 Вимоги до гнучкості системи
5.5 Експлуатаційні вимоги
6
Проектні питання
6.1 Відкриті питання
6.2 План-графік виконання робіт
6.3 Ризики
6.4 Попередній бюджет
Додаток А. Словник термінів
Додаток Б. Список запитань
Наступні розділи включають пояснення до наведеного вище змісту.
На початку документа слід ясно позначити цілі і рамки проекту. Основна частина документа опису вимог присв’ячена опису функціональних вимог. Ця частина може займати половину всього об’єму документа. Функціональні вимоги подають у вигляді текстового опису і за допомогою діаграм прецедентів (подано нижче). Вимоги до даних можна подавати за допомогою діаграм класів (подано нижче), але так само як і у випадку функціональних вимог, діаграма класів не дає повного визначення структур даних для бізнес-процесів. Тому кожний бізнес-клас потребує подальших пояснень.
Вимоги до інтерфейсу визначають як система взаємодіє з користувачами.
В залежності від області системи вимоги щодо продуктивності можуть відігравати доволі вагому роль в успішності проекту. У вузькому сенсі вони задають швидкість, з якою повинні виконуватися різні задачі. В широкому сенсі, вимоги до продуктивності включають інші обмеження – у відношенні надійності, готовності, пропускної спроможності і т.д.
Вимоги безпеки описують користувацькі права доступу до інформації, що контролюється системою. Користувачам може бути наданий обмежений доступ до даних або обмежені права на виконання визначених операцій з даними.
Кінцева частина документа опису вимог звертається до інших проектних питань. Тут піднімаються всі питання, які можуть вплинути на успіх проекту і які не розглядалися в інших розділах документу. Сюди можна віднести будь-які потенціальні проблеми і відхилення в поведінці системи, які можуть появитися у зв’язку з розгортанням системи. В цьому ж розділі слід представити попередній план-графік виконання основних проектних задач. Сюди відноситься попередній розподіл людських і інших ресурсів. Для розроблення планових графіків можна використати програмні засоби управління проектами: Microsoft Project, Time Line, Open Plan, Suretrak, Spider Project, TurboProject і ін. Для ілюстрації плану робіт широко використовують діаграму Ґанта (подано нижче).
Прямим результатом складання плану-графіка може бути розроблення попереднього бюджету.
1.2. Види UML – діаграм
UML (Unified Modeling Language) – графічна мова для специфікацій, візуалізацій, проектування і документування систем. За допомогою UML можна розробити детальну схему створюваної системи, що буде відображати не тільки її концепцію, але і конкретні особливості реалізації. В рамках UML-моделі всі представлення про систему фіксуються у вигляді спеціальних графічних конструкцій, що отримали назву діаграми.
На сьогодні існує понад дванадцять типів UML-діаграм, які можна розбити на дві підгрупи. Перша підгрупа – загальні діаграми, які практично не залежать від предмета моделювання і можуть застосовуватися в будь-якому програмному проекті без прив’язки до предметної області. Для простих систем немає необхідності будувати всі без виключення діаграми. Важливо пам’ятати, що перечень діаграм залежить від специфіки проекту що розробляється і визначається розробником.
Найпопулярнішими діаграмами є: - діаграма прецедентів; - діаграма класів; - діаграма об’єктів; - діаграма послідовностей; - діаграма взаємодії; - діаграма станів; - діаграма активності; - діаграма розгортання.
Діаграма прецедентів (use case diagram)
Що таке варіанти використання? Основна мета створення будь-якої програмної системи – створення такого програмного продукту, який допомагає користувачу виконати свої повсякденні завдання. Для створення таких програм в першу чергу визначають вимоги, яким повинна задовільняти система. Однак якщо дати користувачам написати ці вимоги на папері, то часто можна отримати список функцій, по якому важко буде судити чи майбутня система виконає своє призначення і чи зможе вона полегшити користувачеві виконання його роботи вцілому. Незрозуміло які із виконуваних функцій більш важливі і для кого.
Для того, щоб краще зрозуміти як повинна працювати система, часто використовується опис функціональності системи через варіанти використання (use case або прецеденти). Варіанти використання – це опис послідовності дій, які може здійснювати система у відповідь на зовнішні впливи користувачів або інших програмних систем.
Навіщо потрібні варіанти використань? Юзкейси використовуються для створення функціональних вимог до програмної системи. Всі основні види діяльності такі як аналіз, проектування, тестування виконуються на основі варіантів використання. Під час аналізу і проектування варіанти використання дозволяють зрозуміти яким чином результати, які хоче отримати користувач впливають на архітектуру системи і як повинні себе вести компоненти системи, для того щоб реалізувати потрібну для користувача функціональність.
В процесі тестування, описані раніше варіанти використань дозволяють простіше оцінити точність реалізації вимог користувачів і дозволяють провести покрокову перевірку цих вимог.
Опис прецедентів дозволяє виявити схожі варіанти використання і систематизувати картину однакових операцій виконуваних різними акторами (сутностями).
Юзкейси це впершу чергу тексти, які читаються практично всіма, хто має відношення до програмної системи, що розроблюється. Тому надзвичайно важливе значення має техніка написання цих текстів, оскільки вони повинні бути зрозумілими і більше того, корисні людям, які мають різні інтереси по відношенню до цієї системи (включаючи команду розробників і замовників).
Склад діаграми Use Case. Будь-які системи проектуються з врахуванням того, що в процесі своєї роботи вони будуть використовуватися людьми і/або взаємодіяти з іншими системами. Сутності, з якими взаємодіє система в процесі своєї роботи, називаються акторами. Тому, діаграма прецедентів в UML – діаграма, що відображає відносини між акторами і прецедентами і є складовою частиною моделі прецедентів, що дозволяє описати систему на концептуальному рівні.
Елементами діаграми прецедентів є:
Актор – графічно зображається «чоловічком», що позначає набір ролей користувача, який взаємодіє з деякою сутністю (системою, підсистемою, класом, залізом). Актори не можуть бути зв’язаними між собою (за виключенням відношень узагальнення/успадкування). Актори активні. Вони керують процесом, вони активують прецеденти посилаючи їм повідомлення про подію.
Прецедент – еліпс з надписом, що позначає виконувані системою дії (опис окремого аспекту поведінки системи з точки зору користувача). Надпис може бути іменем або описом того, «що» робить система (а не «як»). Ім’я прецедента зв’язано з сценарієм – конкретною послідовністю дій, що ілюструє поведінку. В ході сценарію актори обмінюються з системою повідомленнями. Сценарій може бути приведений на діаграмі прецедентів у вигляді UML-коментаря. З одним прецедентом може бути зв’язано декілька різних сценаріїв.
Лінії, що зв’язують акторів і прецедентів – це не потоки даних. Ці лінії зв’язку представляють потік подій, що надходять від акторів (суб’єктів) і потік відгуків, що виходять з прецедентів.
Слід зауважити, що інколи на діаграмах прецедентів границі системи позначають прямокутником, у верхній частині якого може бути вказано назву системи.
/
Рис.1 Use-Case діаграма на прикладі інтернет-магазину
Отже, можна виділити такі цілі створення діаграм прецедентів:
визначення межі і контексту предметної області що моделюється на ранніх етапах проектування;
формування загальних вимог до поведінки системи що проектується;
розроблення концептуальної моделі системи для її подальшої деталізації;
підготовка документації для взаємодії з замовником і користувачами системи.
Діаграма класів (class diagram)
Під об’єктом в UML розуміється деяке абстрактне представлення конкретного об’єкта предметної області. Кожний об’єкт має стан, поведінку і індивідуальність. Поведінка об’єкта визначає як об’єкт взаємодіє з іншими об’єктами.
Класи – це будівельні блоки будь-якої об’єктно-орієнтованої системи. Вони являють собою опис совокупності об’єктів з спільними властивостями (атрибутами), поведінкою, операціями, відношеннями і семантикою. Клас є шаблоном для створення нових об’єктів. При проектуванні об’єктно-орієнтованої системи діаграми класів обов’язкові.
Класи використовуються в процесі аналізу предметної області для створення словника предметної області системи що розробляється. Це можуть бути як абстрактні поняття предметної області, так і класи, на які опирається розроблення і які описують програмні або апаратні сутності.
Кожний клас має назву, атрибути (властивості) і операції (методи, функції). Клас на діаграмі зображується у вигляді прямокутника, розділеного на три області. У верхній міститься назва класу, в середній – опис атрибутів (властивостей), в нижній – назви операцій, що виконує цей клас.
/
Рис.2 Приклад зображення класу в UML
Якщо система містить велику кількість класів, то вони можуть бути об’єднані в пакети (package).
Базовими відношеннями на діаграмі класів є: - відношення асоціації (association); - відношення узагальнення (generalization); - відношення агрегації (aggregation); - відношення композиції (composition); - відношення залежності (dependency).
Відношення асоціації свідчить про наявність довільного відношення між класами.
/
Рис.3 Відношення асоціації
Відношення узагальнення є відношення класифікації між більш загальними елементами (батьківськими) і більш частковими або спеціальними (дочірніми або потомками).
/
Рис.4 Відношення узагальнення
Суть відношення агрегації: один із класів представляє собою деяку сутність, яка включає в себе в якості складових інші сутності. Застосовується таке відношення для представлення системних взаємозв’язків типу «частина-ціле».
/
Рис.5 Відношення агрегаціїї
Відношення композиції є частковим випадком відношення агрегації: частини не можуть виступати окремо від цілого, тобто із знищенням цілого знищуються складові частини.
Відношення залежності використовується в такій ситуації, коли деяка зміна одного елемента моделі може вимагати зміну іншого елемента.
/
Рис.6 Діаграма класів
Діаграма станів (state machine diagram)
На сьогоднішній день при приектуванні складної системи прийнято ділити її на частини, кожну з яких потім розглядати окремо. Таким чином, при об’єктній декомпозиції система розбивається на об’єкти або компоненти, які взаємодіють один з одним, обмінюючись повідомленнями. Повідомлення описують або представляють собою деякі події. Отримання об’єктом повідомлення активізує його і спонукає виконувати певні запрограмовані програмним кодом дії.
При цьому підході система стає подієво-керованою, тому розробникам часто важливо знати, як повинен реагувати той чи інший об’єкт на певні події. Ініціатором подій можуть бути як об’єкти самої системи, так і її зовнішнє оточення.
Описати поведінку окремого взятого об’єкта допомагає діаграма станів. Діаграма станів – це один з п’яти видів діаграм в мові UML, що використовується для моделювання динамічних аспектів системи (до їх числа відносяться також діаграма послідовностей і кооперацій, діаграма діяльності і діаграма прецедентів). Також часто діаграма станів використовується аналітиками для опису послідовності переходів об’єкта з одного стану в інший. Діаграма станів покаже нам всі можливі стани, в яких можуть перебувати об’єкти, а також процес зміни станів в результаті зовнішнього впливу. Часто кажуть, що діаграма станів моделює поведінку реактивних об’єктів. Реактивним називається об’єкт, поведінка якого найкраще характеризується його реакцією на подію, що відбулася поза його власним контентом. У реактивного об’єкта є чітко виражений життєвий цикл, коли поточна поведінка зумовлена минулим. Діаграми станів можна приєднювати до класів, прецедентів або системи в цілому для візуалізації, специфікації, конструювання та документування динаміки окремого об’єкта.
Основними елементами діаграми станів є «Стан» і «Перехід». Ключовою різницею між цими термінами є те, що тривалість перебування системи в окремому стані суттєво перевищує час, який затрачається на перехід з одного стану в інший. Іншоми словами перехід об’єкта з стану в стан відбувається миттєво.
В загальному виді діаграма станів представляє динамічні аспекти системи що моделюється у вигляді орієнтованого графа, вершини якого відповідають станам, а дуги – переходам. При цьому поведінка моделюється як послідовне переміщення по графу станів від вершини до вершини по зв’язуючим дугам з урахуванням їх орієнтації.
Стан і його графічне зображення. Моделювання поведінки об’єктів і системи в цілому базується на понятті стан.
Стан (state) – умова або ситуація під час життєвого циклу об’єкта, протягом якого він задовільняє логічну умову, виконує певну діяльність або очікує події. Стан може бути заданий у вигляді набору конкретних значень атрибутів об’єкта класу, при цьому зміна окремих значень цих атрибутів буде відображати зміну стану об’єкта, що моделюється або системи в цілому.
Стан на діаграмі відображається прямокутником з заокругленими вершинами (рис. 7). Цей прямокутник, в свою чергу, може бути розділений на дві секції горизонтальною лінією. Якщо вказана тільки одна секція, то в ній записується тільки ім’я стану. В іншому випадку у першій із секцій записується ім’я стану, в другій - список деяких внутрішніх дій або переходів в даному стані. При цьому під дією в мові UML розуміють деяку атомарну операцію, виконання якої призводить до зміни стану або повернення деякого значення (наприклад, «true» або «false»).
Дія (action) – специфікація здійснюваного твердження, яка утворює абстракцію обчислювальної процедури. Дія зазвичай призводить до зміни стану системи, і може бути реалізована за допомогою передачі повідомлення об’єкта, модифікацією зв’язку або значення атрибута. Для деяких станів може знадобитися додаткове вказування дій, які повинні бути виконані елементами, що моделюються. Для цієї цілі служить додаткова секція в позначенні стану, що містить перелік внутрішніх дій або діяльностей, які здійснюються в процесі знаходження модельованого елемента в даному стані. Кожна дія записується у вигляді окремого рядка і має наступний формат: <мітка дії ‘/’ вираз дія>. Мітка дії вказує на обставини або умови, при яких буде виконуватися діяльність, що визначена виразом дії.
Список дій є фіксованим і включає наступні значення:
Вхідна дія (entry action) – дія, яка виконується в момент переходу у даний стан. Позначається за допомогою ключового слова – мітки дії entry.
Дія виходу (exit action) – дія, що відбувається при виході з даного стану. Позначається за допомогою ключового слова – exit.
Внутрішня діяльність (do activity) – виконувана діяльність протягом усього часу, доки об’єкт знаходиться в даному стані.
Перехід і подія. Перебування модельованого об’єкта або системи в стані може супроводжуватися виконанням деяких внутрішніх дій або діяльності. При цьому зміна поточного стану об’єкта буде можлива або після завершення цих дій (діяльності), або при виникненні деяких зовнішній подій. В обох випадках кажуть, що відбувається перехід об’єкта з одного стану в інший.
Перехід (transition) – відношення між двома станами, яке вказує на то, що об’єкт в першому стані повинен виконати певну дію і перейти в другий стан.
Перехід відбувається при наступленні деякої події: завершення виконання діяльності (do activity), отримання об’єктом повідомлення, отримання сигналу або подія таймеру. На переході вказується ім’я події, а також дії, що виробляються об’єктом у відповідь на зовнішні події при переході з одного стану в інший. Перехід може бути направлений в той же стан, з якого він вийшов. На діаграмі станів перехід зображається суцільною стрілкою, яка виходить із вихідного стану і спрямована в цільовий стан.
В мові UML події відіграють роль стимулів, які ініціюють переходи з одних станів в інші. В якості подій можна розглядати сигнали, виклики, закінчення фіксованих проміжків часу або моменти закінчення виконання певних дій. Залежно від виду подій, що відбуваються – стимулів в мові UML розрізняють два типи переходів: тригерні і нетригерні.
Якщо перехід ініціюється будь-якою подією, то він вважається тригерним. В цьому випадку рядом зі стрілкою тригерного переходу обов’язково вказується ім’я події у формі текстової стрічки.
Перехід називається нетригерним, якщо усі операції поточного стану виконані. Для них рядом з стрілкою переходу не вказується ніякого імені події.
Розрізняють наступні види подій:
Подія виклику (call event) – подія, що виникає при виклику метода класу. При спрацюванні даного виду події об’єктом асинхронно створюється сигнал, який отримує інший об’єкт.
Подія сигналу (signal event) – подія, що виникає під час посилання сигналу. Якщо подія сигналу представляє збудження сигналу, то подія виклику призначена для опису виконаня операції. Тобто перехід відбувається при отриманні сигналу від іншого об’єкта.
Подія таймера (time event) – виникає, коли минув заданий інтервал часу з моменту потрапляння автомата в даний стан. В UML подія часу моделюється за допомогою ключового слова after (після), за яким слідує вираз, що вираховує певний проміжок часу.
Подія зміни (change event) – подія, що виникає, коли деяка логічна умова стає істинною, будучи до цього хибною.
Якщо при спрацюванні переходу можливе розгалуження, в імені переходу використовується сторожова умова. Сторожова умова (guard condition) завжди записується в прямих дужках після події-тригера і являє собою деякий булівський вираз.
Також ім’я переходу може містити вираз дії (action expression). В даному випадку вказана дія виконується зразу при спрацюванні переходу і до початку будь-яких дій в цільовому стані. В загальному випадку вираз дії може містити цілий список окремих дій, розділених символом «;».
Окрім основних вузлів, на діаграмі станів можуть використовуватися так звані псевдостани – вершини, що не володіють поведінкою, і об’єкт в них як правило не знаходиться, а миттєво цю вершину проходить.
Якщо необхідно відобразити знищення об’єкта – використовується вузол завершення (terminate node), псевдостан, вхід в який означає завершення виконання поведінки кінцевого автомата в контексті його об’єкта.
/
Рис.7 Тригерний і нетригерний переходи на діаграмі станів
При використанні діаграми станів важливо дотримуватися наступних правил:
Діаграма станів повинна створюватися тільки для об’єктів, що володіють реактивною поведінкою. Не слід розробляти діаграму автоматів для всіх класів або об’єктів, достатньо вибрати тільки основні класи або об’єкти, що володіють складною поведінкою.
Діаграма станів повинна бути зосереджена на описі тільки одного аспекта поведінки об’єкта.
На діаграмі станів доцільно використовувати тільки ті елементи, які важливі для розуміння аспекту, що описується.
1.3. Побудова мережевої діаграми. Робота у Microsoft Project 2013
Перш, ніж перейти до безпосередньої роботи у Microsoft Project дамо визначення деяким термінам:
Що таке проект? Діяльність будь-якої організації складається із виконання операцій і проектів. Головна різниця між операціями і проектами в тому, що операції відбуваються постійно і повторяються, тоді як проекти тимчасові і унікальні. Виходячи з цього, проект визначається як тимчасове зусилля, яке виконується для створення унікального продукту або послуги. «Тимчасове» означає, що проект має точно визначену дату початку і закінчення. Говорячи про унікальність продукту або послуги, маємо на увазі, що вони мають помітні відмінності від усіх аналогічних продуктів або послуг.
Складові проектного плану. Проект робиться для досягнення певного результату у визначені строки та за певні гроші. План проекту складається для того, щоб визначити, за допомогою яких робіт буде досягатися результат проекту, які люди і обладнання потрібні для виконання цих робіт і в який час ці люди й устаткування будуть зайняті роботою по проекту. Тому проектний план містить три основні елементи: завдання (Task), ресурси (Resource) і призначення (Assignment).
Задачі. Задачею називається робота, що здійснюється в рамках проекту для досягнення певного результату. Оскільки зазвичай проект містить багато задач, то для зручності відстеження плану їх об’єднують в групи, або фази. Сукупність фаз проекту називається його життєвим циклом.
Тривалість задачі – це період робочого часу, який необхідний для того, щоб виконати її.
Залежності та зв’язки. Задачі в плані проекту взаємозв’язані, наприклад, часто одна задача не може розпочатися, поки інша незавершена (зведення стін не може початися раніше закладки фундамента).
Під ресурсами в MS Project розуміють співробітників та обладнання, які необхідні для виконання проектних завдань.
Призначення – це зв’язок певної задачі і ресурсів, необхідних для її виконання. При цьому на одну задачу можуть бути призначені декілька ресурсів, як матеріальних, так і нематеріальних.
Отже, Microsoft Project – система управління проектами, що допомагає менеджерові проекту у розробленні планів, розподілі ресурсів за завданням, відстежуванні прогресу і аналізі обсягів робіт.
Для полегшення розуміння базові можливості програми будуть описуватися по ходу роботи над проектом – розроблення сайту.
Припустимо, ви є керівником невеликої команди розробників, в яку входять окрім вас ще чотири людини: дизайнер, верстальник, програміст і людина, що займається наповненням і розкручуванням сайтів («контент-менеджер»).
До Вас приходить замовник і просить розробити нескладний сайт, який буде складатися з декількох сторінок, що описують його компанію, каталог товарів і форму зворотнього зв’язку, через яку відвідувачі могли б залишати замовлення або відгуки. При цьому сайт повинен включати версію для стаціонарних ПК і для мобільних пристроїв. В подальшому замовник планує час від часу змінювати дизайн сайту.
Отже, нам слід зробит наступні роботи:
Продумати ідею сайту, визначити основні його елементи.
Намалювати дизайн-макет. Це будуть картинки, що описують взаємне розташування елементів, кольорову гамму, логотипи, атрибути шрифта і т.д.
По готовому дизайн-макету слід буде зверстати html-сторінки з використанням таблиць стилів – css (cascading style sheets).
Оскільки на сайті планується регулярно оновлюватися каталог товарів з можливістю пошуку, буде потрібно застосувати скрипти. У нашому прикладі мова програмування неважлива. Для роботи скриптів потрібна база даних, де буде зберігатися вся інформація. Тому слід грамотно спроектувати базу даних і написати скрипти.
Замовник бажає мати дві версії сайту – для стаціонарних ПК і мобільних пристроїв, а також планує час від часу оновлювати дизайн. Полегшити наше завдання допоможе застосування мови XML для виводу даних і таблиць стилів XSL, за допомогою яких єдиний файл даних буде перетворюватися в потрібний формат. Таким чином, при зміні логіки сайту нам не буде потрібно переписувати кілька скриптів, так само як і при зміні дизайну основного сайту.
Останній етап перед здачею замовнику – реєстрація в пошукових машинах і розкручування.
Базові можливості Microsoft Project 2013. MS Project, як і всі інші програми, що зв’язані з пакетом Microsoft Office 2013, використовується стрічковий інтерфейс.
При першому запуску створюється новий проект (рис. 8). Ліворуч відображається таблиця схожа на листок Excel, праворуч – поле з календарем. Також MS Project 2013 відображає вспливаюче віконце з інформацією «планування відбувається в ручному режимі».
/
Рис.8 Вікно Microsoft Project 2013
Для першого знайомства з програмою краще переключитися в автоматичний режим (рис. 9):
/
Рис.9 Переключаємось в автоматичний режим планування
Проект (в нашому випадку – розроблення сайту) складається із множини невеликих задач, які необхідно виконати для успішного завершення. Всі вони вводяться в стовбець таблиці «Ім’я завдання». Після введення кожної задачі, натискайте клавішу <Enter> або переходіть на нову стрічку будь-яким іншим відомим вам способом. Не слід писати в назві довгих текстів (рис. 10).
/
Рис.10 Первинний ввід задач
Отже, введено вісім задач не вказуючи ніяких деталей. В такому вигляді це не приносить ніякої користі, однак MS Project вже зараз намагається задати тривалість робіт. На календарі при цьому показуються невеликі відрізки – це значки діаграми Ганта.
Тепер слід взяти управління в свої руки і вказати ймовірну тривалість робіт. Можна це зробити в явному вигляді, вводячи дати початку і завершення кожної роботи, але тоді ви позбавитися гнучкості в управлінні. Краще вказувати ймовірну тривалість в відповідному стовпці. За замовчуванням цифри інтерпретуються як робочі дні, але ви можете вказати і інші часові відрізки (тижні, місяці, роки, години, мінути і т.д.). Просто вписуйте поряд з цифрою потрібну одиницю часу повністю або скорочено, наприклад, «2тижні» для двотижневого строку. Знак запитання в цьому стовпці означає ймовірну тривалість, але ми покищо не будемо користуватися цією можливістю.
/
Рис.11 Проект після введення тривалості задач
На рисунку 11 видно збільшення довжини часових відрізків. Зверніть увагу, що за замовчуванням MS Project 2013 використовує календар з п’ятиденним робочим тижнем.
На даний момент ми маємо не зовсім коректну картину, оскільки задачі не повинні починатися в один час – між ними є певні залежності. Так, програмування слід починати після розроблення проекту бази даних, XSL-верстка здійснюється на основі html-шаблону, а розкручування незавершеного сайту робити неможливо. Давайте задамо залежності між нашими завданнями.
Найпростіший спосіб встановлення зв’язків – перетягування одного часового відрізку на інший.
Після того, як Ви відпустите ліву кнопку миші, відрізки розташуються таким чином, щоб друга задача починалася по закінченні першої. Між ними також буде візуальний зв’язок у вигляді стрілки (рис. 12). Ви можете задавати залежність від декілької процесів. В нашому прикладі наповнення сайту відбувається по завершенні програмування і верстки, а після завершенні етапу продумування ідей паралельно починається створення дизайн-макету і проектування бази даних.
Оскільки всі інтервали діаграми Ганта не вміщалися на екрані без прокрутки, було зменшено масштаб відображення за допомогою кнопки «мінус» в нижньому правому куті вікна.
/
Рис.12 Проект після визначення зв’язків між задачами
Якщо Ви помилилися при створенні залежності, двічі клікніть по стрілці і в віконці натисніть кнопку «Видалити» (рис. 13).
/
Рис.13 Управління залежностями
В списку задач MS Project 2013 також вказує дати початку та завершення кожної частини проекту. Якщо все піде за нашим планом, то проект буде завершено 24 жовтня (при умові, що процес розпочнеться 25 серпня). Разом – 2 місяці. Це добре видно по часовій шкалі у верхній частині рисунку 12.
Також, досить зручним може бути відображення так званої сумарної задачі проекту. Щоб її
06.12.2015 18:12-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора