Що таке контрольна точка проекту. 5 страница

Функції:

1.Розробка концепції (аналіз, визначення цілей, збирання вхідних даних, обмеження, аналіз альтернатив, задачі – результати, час, ресурси, інше)

2.Визначення ПО проекту (критерії, планування організації і управління, декомпозиція робіт, базове описання).

3.Розподіл робіт.(комплекси робіт, контрольні точки, контакти)

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

5.Введення системи контролю(контроль змін проекту, контроль робіт, контроль документації, контроль закупок і поставок, контроль специфікацій)

6.Завершення проектів(оформлення дослідних даних про фактичне виконання проекту, заключний аналіз і зведений звіт)

121. Що таке зміни у проекті, коли вони виникають і які можуть мати наслідки?

Зміна в проекті – це модифікація раніше погоджених продуктів і послуг, термінів виконання і вартості робіт, управлінських і технологічних процесів і т.п.

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

З погляду ваги наслідків зміни можуть бути класифіковані:

1)Планові втрати (враховані в плані керування проектом).

2)Припустимі втрати (незначні незаплановані витрати).

3)Небажані втрати (значні незаплановані витрати).

4)Неприпустимі втрати (незаплановані витрати, що є неприйнятними для одного або декількох учасників проекту).

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

122. Що таке стратегія управління змінами у проекті? Які бувають стратегії змін?

Зміна в проекті – це модифікація раніше погоджених продуктів і послуг, термінів виконання і вартості робіт, управлінських і технологічних процесів і т.п.

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

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

Часто стратегія змін визначається тим, що, принаймні, по одній з осей зміни не повинні приводити до виходу з області планових утрат. А це означає необхідність зсуву в одному або відразу в двох інших вимірах. Так якщо відомо, що замовник орієнтований, насамперед, на дотримання запланованого рівня якості продукту, те повинні бути передбачені варіанти змін, зв'язаних з маніпулюванням ресурсами і/або термінами (стратегія "Упертий замовник").

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

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

Зміна в проекті – це модифікація раніше погоджених продуктів і послуг, термінів виконання і вартості робіт, управлінських і технологічних процесів і т.п.

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

127. Сутність управління якістю та його основні функції на всіх стадіях проекту.

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

Складові якості проекту:

* матеріали, що використовуються, обладнання, сировина;

* якість робіт, що виконуються;

* якість отриманих результатів.

128. Підходи до розроблення системи управління і забезпечення якості програмних продуктів відповідно до стандарту ISO-9000.

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

Система якості передбачає наявність:

· Інструкції з якості, яка включає методики системи якості компанії;

· Опис структури документації, що використовується в системі якості.

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

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

129. Які комплекси стандартів включає стандарт ISO-9000?

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

Є чотири частини ISO -9000:

1) 9000-1 - настанови щодо вибору і застосування

2) 9000-2 - настанови щодо застосування ISO -9001, ISO -9002 та ISO -9003

3) 9000-3 - настанови щодо застосування ISO -9001 до розроблення, поставляння та супроводження ПЗ.

4) 9000-4 - настанови щодо управління програмною надійністю.

ISO -9001 - системи якості(СЯ) модель забезпечення якості в процесі проектування розроблення, виробництва, монтажу та обслуговування. Цей стандарт є найбільш повним. Він специфікує модель забезпечення якості на всіх етапах життєвого циклу товару/послуги.

ISO -9002 - СЯ- модель забезпечення якості в процесі виробництва, монтажу та обслуговування.

ISO-9003 - СЯ - модель забезпечення якості в процесі контролю готової продукції та її випробування.

ISO-9004-1 - управління якістю та елементи системи якості:

Частина 1: настанови

Частина 2: настанови щодо послуг.

Частина 3: настанови щодо перероблюваних матеріалів.

Частина 4: настанови щодо поліпшення якості.

130. Необхідність розроблення системи управління із забезпечення якості ПП. Сутність стадій при розробленні системи управління і забезпечення якості ПП відповідно до ISO-9000.

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

· Чітка організація спільної роботи команди розробників;

· Загальне управління проектом, яке включає не тільки розподіл обов’язків, а і розподіл відповідальності.

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

Цей стандарт включає усі положення загального стандарту ISO-9001, а також необхідні доповнення до них, що стосуються розробки, поставки та обслуговування ПЗ.

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

131. Загальна характеристика стандартів ISO-9000 із забезпечення якості продукції чи послуг.

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

ISO-9000, не є стандартом якості власне для товарів та послуг, що виробляє підприємство. Схема “покриває” всі етапи виробничого циклу випуску товарів/послуг:

- закупку сировини і матеріалів

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

- створення і доставка товарів

- обслуговування клієнтів

- навчання персоналу

Власне ISO-9000 регламентує два ключових момента:

1)наявність і документування відповідного бізнес-процесу

2)вимірювання його якості

Є чотири частини ISO -9000:

- 9000-1 - настанови щодо вибору і застосування

- 9000-2 - настанови щодо застосування ISO -9001, ISO -9002 та ISO -9003

- 9000-3 - настанови щодо застосування ISO -9001 до розроблення, поставляння та супроводження ПЗ.

- 9000-4 - настанови щодо управління програмною надійністю.

ISO -9001 - системи якості(СЯ) модель забезпечення якості в процесі проектування розроблення, виробництва, монтажу та обслуговування. Цей стандарт є найбільш повним. Він специфікує модель забезпечення якості на всіх етапах життєвого циклу товару/послуги.

ISO -9002 - СЯ- модель забезпечення якості в процесі виробництва, монтажу та обслуговування.

ISO-9003 - СЯ - модель забезпечення якості в процесі контролю готової продукції та її випробування.

ISO-9004-1 - СЯ - управління якістю та елементи системи якості:

Частина 1: настанови

Частина 2: настанови щодо послуг.

Частина 3: настанови щодо перероблюваних матеріалів.

Частина 4: настанови щодо поліпшення якості.

132. Які складові має система якості? За що відповідальне керівництво компанії у системах якості?

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

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

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

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

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

133. Які дії з аналізу контракту передбачає система якості відповідно до ISO-9000?

Система якості передбачає певні дії з аналізу контракту.

ПП може розроблятись:

1)За контрактом із замовником;

2)Як комерційний продукт для певного сектора ринку;

3)Як система, вмонтована в апаратне забезпечення;

4)Як система підтримки бізнес-процесів постачальника.

Загальні положення аналізу контрактів, визначені в ISO 9000-3, прийнятні для будь-якої з цих ситуацій.

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

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

Наприклад, можуть аналізуватися:

1)узгоджені із замовником критерії прийняття або відмови від готової системи;

2)термінологія;

3)ступінь участі замовника у спільній роботі;

4)відповідальність замовника за надання певних даних або обладнання;

5)зобов”язання замовника перед постачальником із заміни на нові версії системи або зобов”язання постачальника підтримувати старі версії, тощо.

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

134. Які дії з управління проектуванням ПП передбачає система якості відповідно до ISO-9000. Як модель ЖЦ проекту розроблення ПП пов’язана з моделлю ЖЦП, пропонованою стандартом ISO-9000-3?

Розділ стандарту IS0 9000-3 містить вказівки з таких основних дій в процесі розробки:

- аналіз вимог до проекту;

- проектування архітектури системи;

- детальне проектування та кодування;

- планування розробки.

Проект розробки ПП організується за певною моделлю ЖЦ. ISO 9000-3 не визначає, якою повинна бути модель ЖЦ, це залежить від специфіки задачі. Стандарт наводить лише визначення моделі ЖЦ як сукупності процесів. Модель показує, коли ці процеси і як підключаються до реалізації проекту.

Розробка системи – це процес початкових вимог до кінцевого продукту. Стандарт оговорює, що цей процес повинен проводитись у чітко визначеному порядку. Вимога строго дотримуватись дисципліни процесу розробки означає наявність та підтримку в робочому стані документованих процедур, які і стануть гарантією того,що ПП створюється у відповідності з заданими вимогами та планами розробки і забезпечення якості.

Управління проектом повинно враховувати такі аспекти як:

- метод проектування та його відповідність конкретній задачі;

- досвід попередніх проектів;

- вимоги наступних процесів;

- тестування, установки, супроводу та використання;

- вимоги до захисту та безпеки;

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

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

План повинен включати також плани, пов’язані з основним процесом: забезпечення якості; управління ризиками; управління конфігурацією; плани інтеграції; плани установки; плани навчання співробітників та ін.

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

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

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

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

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

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

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

135. Які дії з управління документацією і даними передбачає система якості відповідно до ISO-9000?

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

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

136. Які дії, пов’язані із закупками, ідентифікацією та відсліковуванням продукції, передбачає система якості відповідно до ISO-9000.

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

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

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

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

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

137. Які дії, пов’язані з управлінням процесами, контролем і випробуваннями, передбачає система відповідно до ISO-9000?

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

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

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

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

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

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

138. Які дії, пов’язані з управлінням продукцією, що не відповідає вимогам, коригуючими та запобіжними діями передбачає система якості відповідно до ISO-9000?

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

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

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

139. Які дії, пов’язані з вантажно-розвантажувальними роботами, зберіганням, упаковкою, консервацією та постачанням передбачає с-ма якості відповідно ISO-9000

Дії, пов’язані з вантажно-розвантажувальними роботами, зберіганням, упаковкою, консервацією та постачанням ПЗ передбачає с-ма якості, конкретизована у стандарті ISO-9000-3

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

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

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

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

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

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

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

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

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

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

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

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

141. Сутність і ф-ції управління часом на всіх стадіях проекту.

У кожному проекті час – це один з найважливіших визначальних чинників при оцінці досягнень (успіхів) проекту. Час є основним ресурсом проекту, але, на жаль “негнучким” ресурсом. Згаяний час не може бути поновленим. Звідси потреба особливої уваги до функції управління часом.

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

Ø аналізу часових характеристик проекту та його частин (тривалість, дати початку та закінчення проекту та його окремих етапів, робіт);

Ø календарного планування робіт;

Ø контролю графіків виконання робіт, їх актуалізації і коригування.