|
|
3. Життєвий цикл проекту
Любою проект проходить через визначені фази у своєму розвитку. Стадії життєвого циклу проекту можуть розрізнятися в залежності від сфери діяльності і прийнятої системи організації робіт. Поняття життєвого циклу проекту є одним з найважливіших для менеджера, оскільки саме поточна стадія визначає задачі і види діяльності менеджера, використовувані методики й інструментальні засоби.
Керівники проектів розбивають цикл життя проекту на етапи різними способами. Наприклад, у проектах по розробці програмного забезпечення часто виділяються такі етапи як усвідомлення потреби в інформаційній системі, формулювання вимог, проектування системи, кодування, тестування, експлуатаційна підтримка. Однак, найбільш традиційним є розбивка проекту на чотири великих етапи: формулювання проекту, планування, здійснення і завершення.
Основні стадії життєвого циклу проекту представлені в таблиці 3.
Таблиця 3.
Стадії життєвого циклу проекту
Стадія
Опис
Формулювання проекту
· Ініціюється в силу виникнення потреб, які потрібно задовольнити.
· В умовах дефіциту ресурсів неможливо задовольнити всі потреби без винятку.
· Вибір проекту:
¨ рішення приймаються виходячи з наявності ресурсів, і в першу чергу фінансових можливостей, порівняльної важливості задоволення одних потреб і ігнорування інших, порівняльної ефективності проектів.
¨ рішення по доборі проектів до реалізації тим важливіше, ніж масштабніше передбачається проект, оскільки великі проекти визначають напрямок діяльності на майбутнє (іноді на роки) і зв'язують наявні фінансові і трудові ресурси.
¨ визначальним показником є альтернативна вартість інвестицій.
¨ для порівняльного аналізу проектів застосовуються методи проектного аналізу: фінансовий, економічний, комерційний, організаційний, екологічний, аналіз ризиків і інші види аналізу проекту.
· Системи для планування і керування проектами використовуються в обмеженому виді.
Планування
· Виробляється в плині всього терміну реалізації проекту.
· На самому початку розробляється неофіційний попередній план - грубе представлення про те, що буде потрібно виконати у випадку реалізації проекту. Рішення про вибір проекту в значній мірі ґрунтується на оцінках попереднього плану.
· Формальне і детальне планування проекту починається після ухвалення рішення про реалізації проекту.
· Визначаються ключові крапки (віхи) проекту, формулюються задачі (роботи) і їхня взаємна залежність.
· Використовуються системи для керування проектами - набір засобів для розробки формального плану:
¨ засобу побудови ієрархічної структури робіт;
¨ сіткові графіки і діаграми Гантта;
¨ засобу призначення і гистограммы завантаження ресурсів.
· Твердження формального плану.
· План проекту в міру здійснення проекту піддається постійному коректуванню з урахуванням поточної ситуації.
Здійснення
В міру здійснення проекту керівники зобов'язані постійно контролювати хід робіт:
· збір фактичних даних про хід робіт і порівняння їх із плановими;
· аналіз можливого впливу відхилень у виконаних обсягах робіт на хід реалізації проекту в цілому і вироблення відповідних управлінських рішень.
Завершення
· Проект закінчується коли досягнуті поставлені перед ним мети.
· Керівник повинний виконати ряд заходів, конкретний характер яких залежить від характеру самого проекту:
¨ при використанні в проекті устаткування, треба зробити його інвентаризацію і передати його для нового застосування;
¨ при підрядних проектах треба визначити, чи задовольняють результати умовам підряду або контракту.
¨ необхідно скласти остаточні звіти, а проміжні звіти по проекті організувати у виді архіву.
4. Концепція методів планування, організації і контролю проектів
Основні визначення і концепції методів планування представлені в таблиці 3.
Таблиця 3.
Концепція методів планування
Поняття
Визначення
Опис
Робота
Діяльність, необхідна для досягнення конкретних результатів (кінцевих продуктів нижнього рівня).
· Основний елемент діяльності на самому нижньому рівні деталізації, на виконання якого потрібен час, і який може затримати початок виконання інших робіт.
· Основа для організації даних у системах керування проектами.
· Момент закінчення роботи означає факт одержання кінцевого продукту.
Віха (подія)
Подія або дата в ході здійснення проекту.
· Не має тривалості
· Відображення стану завершенности робіт.
· Позначення важливих проміжних результатів, що повинні бути досягнуті в процесі реалізації проекту.
Зв'язку предшествования (логічні залежності)
Відображення природи залежностей між роботами.
· Зв'язку "кінец-почало" - наступний робот мог поча_ тільки по завершенн попередн робот.
· Структура мережі.
· Послідовність виконання робіт.
Мережна діаграма
Графічне відображення робіт проекту і їхніх взаємозв'язків.
· Логічні залежності між елементарними роботами.
· Не відображає входи, процеси і виходи
· Не допускає повторюваних циклів або петель.
· Основні види мереж:
¨ Мережа «вершина-робота»;
¨ Мережа «вершина-подія».
Критичний шлях
Максимальний по тривалості повний шлях у мережі.
Роботи, що лежать на критичному шляху називаються критичними роботами.
· Найменша загальна тривалість робіт.
· Тривалість проекту може бути скорочена за рахунок скорочення тривалості задач, що лежать на критичному шляху.
· Затримка виконання задач критичного шляху спричинить збільшення тривалості проекту.
Метод критичного шляху
Метод розрахунку можливих календарних графіків виконання комплексу робіт на основі описаної логічної структури мережі й оцінок тривалості виконання кожної роботи.
· Концентрація уваги менеджера на критичних роботах.
· Можливість маніпулювання термінами виконання задач, що не лежать на критичному шляху.
Часовий резерв
Різниця між самим раннім можливим терміном завершення роботи і самим пізнім припустимим часом її виконання.
· Дозволяє менеджерові затримати роботу, що має часовий резерв, без впливу на загальну тривалість проекту.
· Роботи, що лежать на критичному шляху, мають часовий резерв, дорівнює нулеві.
Діаграма Ганта
Горизонтальна лінійна діаграма, на якій задачі проекту представляються протяжними в часі відрізками, що характеризуються датами початку і закінчення, затримками і можливо іншими тимчасовими параметрами.
Ресурсна гистограмма
Гистограмма, що відображає потреби проекту в тім або іншому виді ресурсів у кожен момент часу.
Ресурси
Компоненти діяльності, що забезпечують, що включають виконавців, енергію, матеріали, устаткування і т.д.
З кожною роботою можна зв'язати функцію потреби в ресурсах.
Призначення і вирівнювання ресурсів.
Методика, що дозволяє менеджерові проаналізувати мережний план, побудований за допомогою методу критичного шляху для того, щоб забезпечити приступність і використання визначених ресурсів протягом усього часу виконання проекту.
· Визначення потреби кожної роботи в різних типах ресурсів.
· Программно-реализованные евристичні алгоритми планування при обмежених ресурсах, що допомагають створити реальний розклад проекту, з урахуванням потреби проекту в ресурсах і фактично доступних у даний момент часу ресурсів.
Ресурсне календарне планування
Планування термінів початку робіт при обмежених наявних ресурсах.
· Зіставлення функцій наявності і потреби в ресурсах проекту в цілому.
· Зрушуючи некритичні роботи аж до їхніх пізніх термінів початку (закінчення), можна видозмінити ресурсний профіль, забезпечуючи оптимальне використання ресурсів.
· Допомагає загострити увага менеджера і членів команди на тих моментах робіт, де ефективне керування ресурсами буде ключовим фактором успіху.
Вихідний план
План виконання робіт проекту, що містить вихідні зведення про основні тимчасові і вартісні параметри робіт, що прийнятий до виконання.
· Обсяги робіт.
· Планові дати початку і закінчення задач проекту. Тривалості задач.
· Розрахункові вартості задач.
ТЕМА 9. АВТОМАТИЗАЦІЯ ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ
1. Проблема якості інформаційних систем.
2. Засоби CASE.
3. Достоїнства CASE.
4. Основі елементи CASE.
5. Класифікація засобів CASE.
6. Можливості та характеристики CASE.
Автоматизована розробка програмного забезпечення (CASE) - автоматизація покрокових методологій для розробки програмного забезпечення і систем, щоб зменшити кількість повторюваної роботи, що повинний робити розроблювач.
Достоїнства використання CASE
Звільнення розроблювача для виконання більш творчих проблемних задач.
Створення ясної документації і координація проектно-конструкторських робіт групи.
Організація спільної роботи групи.
Розробка більш надійного і потребуючого меншого ремонту систем.
Використання микроэвм, з могутніми графічними можливостями для створення схем і діаграм, генераторами екранів і звітів, словниками даних, великими засобу формування звітів, інструментальними засобами аналізу і перевірки, генераторами коду і генераторами документації.
Застосування структурних методологій.
Підтримка объектно-ориентированной розробки.
Збільшення продуктивність і якості.
Задачі CASE
Розпорядження стандартної методології розробки і проектної дисципліни:
ефективна координація великі групи і програмні проекти;
цілісність проекту і загальних проектно-конструкторських робіт.
Поліпшення зв'язку між користувачами і технічними фахівцями.
Організація і взаємозв'язок проектних компонентів і забезпечення швидкого доступу до них через репозитарий проектів.
Автоматизація стомлюючих і підданих помилкам частин аналізу і проекту.
Автоматизація перевірки і контролю відкоту.
Основні елементи CASE описані в таблиці 1.
Таблиця 1.
Основні елементи CASE
Елемент
Опис
Інструментальні засоби побудови діаграм
Графічні інструментальні засоби для малювання символів, зв'язаних з визначеною методологією:
діаграми потоку даних;
структурні схеми;
діаграми сутність-зв'язок;
інші типи діаграм.
Верификатор синтаксису
Перевірка точності і закінченості інформації, введеної в систему відповідно до правил визначеної структурної методології.
Інструментальні засоби макетування
Дозволяють намалювати необхідний макет екрана і звіту або шляхи меню в системі без складного форматування специфікацій або програмування:
генератори екранів;
генератори звітів;
генератори меню.
Інформаційний репозитарий
Координує, інтегрують і стандартизують різні частини інформації для полегшення доступу, спільного і багаторазового використання в майбутній програмній роботі.
Центральна інформаційна база даних для збереження всіх типів засобів програмного забезпечення:
макети екранів і звітів;
діаграми;
визначення даних;
код програми;
розкладу проекту;
інша документація.
Генератори коду
Генерують модулі коду, що виконується, зі специфікацій верхнього рівня.
Методологія розробки
Контроль і керування всім проектом розробки систем.
Запитальники або коментарі, що деталізують усю методологію розробки.
Інструментальні засоби керування проектом
Планування проектів і оцінка ресурсів
3. Класифікація інструментальних засобів CASE
Інструментальні засоби CASE класифікуються на підставі того, чи підтримують вони вхідні або вихідні операції процесу розробки систем. Класи інструментальних засобів CASE представлені в таблиці 2.
Таблиця 2.
Класифікація інструментальних засобів CASE
Вид
Опис
Вхідні
Прихильність структурним методологіям.
Фіксація інформації аналізу і проекту на ранніх стадіях розробки систем.
Автоматизація процесу створення, збереження і редагування діаграм:
діаграми потоку даних;
структурні схеми;
діаграми сутність-зв'язок;
інші специфікацій.
Вихідні
Підтримка операцій по кодуванню, тестуванню і супроводові
Автоматичне перетворення специфікацій у код програми.
Склад:
текстові редактори;
форматеры;
засобу контролю синтаксису;
компілятори;
генератори перехресних посилань;
компоновщики;
символічні отладчики;
профилировщики виконання;
генератори коду;
генератори прикладних програм.
4. Можливості інструментальних засобів CASE
Що інструментальні засоби CASE можуть і не можуть робити представлені в таблиці 3.
Таблиця 3.
Що інструментальні засоби CASE можуть і не можуть робити
Інструментальні засоби CASE можуть
Інструментальні засоби CASE не можуть
Автоматизувати багато ручних задач розробки систем.
Сприяти стандартизації, заснованої на єдиній методології.
Сприяти більшої послідовності і координація протягом проекту розробки.
Генерувати велику частину документації для системи, типу діаграм потоку даних, моделей даних, структурних схем або інших специфікацій.
Автоматично надати функціональну, доречну систему
Легко погоджувати бази даних і мови четвертого покоління.
Автоматично примушувати аналітиків використовувати задану методологію або створювати методологію, коли вона не існує.
Радикально перетворити системний аналіз і процес проектування.
Застосування сучасних інструментальних засобів CASE
Вхідна робота з проектування й аналізу, що зменшує кількість помилок, який необхідно пізніше виправити.
Створення технічно правильних діаграм, обробка описів і введення словника даних за допомогою текстових і графічних редакторів CASE
Побудова діаграми за допомогою стандартного набору символів.
Автоматичний зв'язок елементів даних із процесами, де вони використовуються.
Перевірка вірогідності проекту, автоматичне балансування діаграм потоку даних і перевірки діаграм і специфікацій на закінченість і послідовність.
Ітеративна розробка, автоматизація переглядів і змін і забезпечення засобів макетування.
Збереження всієї проектної інформації (діаграми потоку даних, структурні схеми, діаграми сутність-зв'язок, визначення даних, специфікації процесів, формати екран і звітів, записи і коментарі, перевірку результатів і оцінок, вихідний текст, інформація про стан і ревізію й оцінці часу і витрат) в інформаційному репозитарии (база даних CASE).
Спільне використання членами проектної групи й обмеження можливості зміни база даних CASE
Основні проблеми використання CASE представлені в таблиці 4.
Таблиця 4.
Проблеми використання CASE
Проблема
Опис
Потрібно більше організаційної дисципліни, чим при ручному підході
Кожен член проекту розробки повинний твердо притриматися загального зводу угод про імена, стандартів і методології розробки.
Аналитики і проектувальники намагаються зберегти своїх старі способи розробки систем і будуть намагатися включати інструмент CASE у процес.
Інструментальні засоби CASE пропонують загальні методи і стандарти, що не можуть використовуватися в ситуаціях, коли бракує організаційної дисципліни.
Фактична продуктивність, отримана від використання CASE важко визначна.
Продуктивність, отримана в програмній розробці, традиційно був важкий для виміру і кількісного визначення.
CASE - не чарівна панацея
Не може автоматично розробляти системи або гарантувати, що ділові вимоги будуть виконані.
Проектувальники систем повинні розуміти ділові потреби фірми і як бізнес працює.
Системний аналіз і проектування усе ще залежать від навичок аналітика / проектувальника.
Деякі збільшення продуктивності - результат роботи системних розроблювачів, що поліпшили зв'язок, координацію і програмну цілісність, домовилися про стандартну методологію, а не результат використання CASE.
Недолік методології
Для автоматизації процес розробки програмного забезпечення, він повинний бути визначений відповідно до методології.
При відсутності методології, CASE можуть використовуватися, щоб автоматизувати непорівнянні, і часто несумісні, дії скоріше, ніж інтегрувати або стандартизувати підхід розробки систем.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
При использовании материалов активная ссылка на источник обязательна.