о функцій здійснюється за допомогою браузера Microsoft Internet Explorer.
При реалізації описаних вище підсистем використовувалися такі стандарти, мови і технології в галузі створення і підтримки створення програмного забезпечення та баз даних, а також програмні засоби сторонніх виробників:
в якості засобів розробки використовувалися: .NET (Microsoft Visual Studio .NET 2005, C #; бібліотеки Microsoft Ajax і Microsoft .NET framework 2.0, javascript на стороні клієнта);/SQL;
в якості операційної системи можуть використовуватися Windows 2000 Professional, Windows 2000 Server, Windows 2003 Server;
в якості СУБД використовується СУБД Oracle 10g або Oracle XE;
як Web-сервера застосовується IIS версії 6.0 і вище;
програмне забезпечення підсистеми (клієнтська частина) функціонує в середовищі Internet Explorer ® версії 6.5 або вище.
.3 Блок-схеми служби Service Desk
Основні поняття Управління змінами головним чином пов'язані з процесами і носять управлінський, а не технічний характер (тоді як Управління інцидентами в основному носить технічний характер з особливим акцентом на механічній природі деяких процесів). Тому в даному розділі зроблено акцент на надання інформації, необхідної, щоб ідентифікувати найбільш важливі компоненти для вашої організації.
Малюнки 2.6 та 2.7 представляють блок-схему основних процедур Управління змінами.
Малюнок 2.8 показує використання стандартних процедур Управління змінами (моделей Змін) в рамках життєвого циклу Зміни.
Малюнок 2.6 - Основні процедури Управління змінами
Малюнок 2.7 - Основні процедури Управління змінами.
Малюнок 2.8 - Підхід до стандартних процедур Управління змінами.
Стандартне Зміна (зміна в інфраструктурі за встановленою схемою) виникає досить часто і є прийнятним рішенням для задоволення певного вимоги або ряду вимог. Приклади можуть включати модернізацію ПК для отримання можливості використовувати певне ПЗ, нововведення в рамках організації, а також ПК, ПО і мережеві з'єднання для тимчасових або сезонних змін вимог. Особливо важливі такі елементи стандартних Змін:
завдання добре відомі і перевірені;
повноваження передані заздалегідь;
ланцюжок подій, як правило, ініціюється службою Service Desk;
затвердження бюджету зазвичай зумовлено або знаходиться в сфері контролю того, хто запитує Зміна.
Як тільки цей підхід встановлено та задокументовано, слід розробити і опублікувати процес стандартного Зміни, щоб переконатися, що такі Зміни продуктивно обробляються для підтримки бізнес-потреб.
Запити на Зміна.
У запитів на Зміна (RFC, або Request for Change) безліч причин і джерел. Причини можуть бути наступні:
потрібно рішення, вказане у звіті про Інциденті або Проблемі;
незадоволеність Користувача або Замовника, передана через зв'язок з Замовником або Управління рівнем обслуговування;
пропозицію про введення нового УЕ або видаленні УЕ;
пропозицію з модернізації деяких компонентів інфраструктури;
зміна вимог або напрямки бізнесу;
нововведення або зміни в законодавстві;
зміна місця розташування;
зміни в продуктах або послугах, що надаються постачальниками або подрядчікамі.могут бути пов'язані з будь-якою частиною інфраструктури або з будь-якою послугою або діяльністю, наприклад:
апаратне забезпечення;
програмне забезпечення;
документація;
телекомунікаційне обладнання;
спеціалізоване обладнання;
освітні курси;
процедури управління ІТ-інфраструктурою;
тактичні плани;
забезпечує інфраструктура., може зберігатися як у паперовій формі, так і в електронному вигляді.
Наступні елементи повинні бути включені в форму RFC (як паперового, так і електронного):
порядковий номер RFC (плюс перехресне посилання на номер звіту про Проблемі, якщо це необхідно);
опис та ідентифікація елемента (або елементів), який слід змінити (включаючи ідентифікацію УЕ, якщо використовується система Управління конфігураціями);
причина для внесення Зміни;
наслідки у випадку, якщо змін не буде впроваджено;
версія змінюваного елемента;
назву, місце розташування і телефонний номер людини, що пропонує Зміна;
дата, коли було запропоновано Зміна;
пріоритет Зміни;
оцінка впливу і ресурсів (яка може бути представлена ??в окремих формах, якщо це зручно;).
рекомендації САВ, коли це доречно; ці рекомендації можуть зберігатися окремо або разом з оцінками впливу і ресурсів, якщо це зручно;
авторизуйтесь підпис (може бути електронної);
дата і час авторизації;
плановане впровадження (ідентифікація Релізу та/або дати і часу);
місцеположення плану Релізу/впровадження; <...
