Проектування АРМ

Розглянемо змістовне наповнення основних типових етапів проектування ІС.

Рис. Модель розроблення і впровадження АРМ

1) Аналіз вимог.

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

Перелік вимог до АРМ повинен включати:

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

· опис функцій, що їх має виконувати АРМ;

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

Метою аналізу є перетворення загальних, нечітких знань про вимоги до майбутнього АРМ в точні (по можливості) визначення. Результатом етапу повинна бути модель вимог до системи (іншими словами — системний проект), що визначає:

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

· інтерфейси і поділ функцій між людиною і системою;

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

Модель вимог повинна включати:

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

· специфікації операцій нижнього рівня;

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

· зв'язку для інформаційного обміну між компонентами, вимоги до характеристик

· взаємозв'язків системи із суміжними системами, вимоги до функцій системи;

· концептуальну інформаційну модель вимог;

· пакет звітів і документів з інформаційної моделі;

· архітектуру системи з прив'язкою до концептуальної інформаційної моделі;

· пропозиції щодо організації структури для підтримки системи.

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

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

· описати, «побачити» і скоригувати майбутнє АРМ до його реалізації;

· зменшити витрати на розробку і впровадження АРМ;

· оцінити розробку за часом і результатами;

· досягнути взаєморозуміння між усіма учасниками розробки;

· поліпшити якість АРМ, а саме: виконати її функціональну декомпозицію і спроектувати оптимальну структуру інтегрованої бази даних.

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

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

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

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

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

2) Розробка технічного завдання.

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

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

· розробку вимог до технічних засобів;

· визначення вимог до програмних засобів;

· розробку топології, складу і структури локальної обчислювальної мережі;

· вимоги до етапів і термінів виконання робіт.

3) Проектування.

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

§ необхідну функціональність і ступінь адаптації до динамічних умов функціонування;

§ необхідну пропускну спроможність;

§ необхідний час реакції на запит;

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

§ простоту експлуатації і підтримки АРМ;

§ необхідну інформаційну безпеку.

Продуктивність є головним чинником, що визначає ефективність АРМ. Хороше проектне рішення служить основою високопродуктивного АРМ.

Проектування АРМ охоплює три основні сфери:

§ проектування об'єктів даних, які будуть реалізовані в базі даних;

§ проектування програм, екранних форм звітів для виконання професійних завдань;

§ моніторинг з боку користувача стану конкретного робочого середовища в АРМ.

У реальних умовах проектування АРМ — це пошук способу, який задовольняє вимогам функціональності системи управління засобами наявних ІТ з урахуванням заданих обмежень.

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

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

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

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

В результаті, повинна бути побудована модель реалізації, що демонструє, як АРМ задовольнятиме сформульовані вимоги (без технічних подробиць). Фактично модель реалізації є розвитком і уточненням моделі вимог, а саме проектування є мостом між аналізом і реалізацією.

4) Реалізація (програмування/адаптація).

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

5) Тестування і налагодження.

Коректність АРМ є її найважливішою властивістю і, без сумніву, головним предметом турботи розробників. У ідеальному випадку під коректністю АРМ мають на увазі відсутність у ній помилок. Однак для більшості складних програмних продуктів досягти цього неможливо — «у кожній програмі міститься принаймні одна помилка». Тому під «коректним» зазвичай розуміють програмний продукт, що працює відповідно до поставлених до нього вимог, іншими словами — продукт, для якого поки ще не знайдені такі умови, в яких він виявиться непрацездатним.

Встановлення коректності є головною метою етапу життєвого циклу, що розглядається. Треба зазначити, що етап тестування і налагодження — один із найбільш трудомістких, стомлюючих і не передбачуваних етапів розробки АРМ. У розробці традиційними методами цей етап займає в середньому від 1/2 до 1/3 всього часу розробки. У деяких випадках тестування і налагодження програми вимагають в декілька разів більше часу, ніж безпосередньо програмування.

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

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

· формулювання цілей тестування;

· критерії якості тестування, що дозволяють оцінити його результати;

· стратегію проведення тестування, що забезпечує досягнення заданих критеріїв якості;

· потреби в ресурсах для досягнення заданого критерію якості для обраної стратегії.

6) Експлуатація і супроводження.

Основними завданнями етапу експлуатації і супроводження є :

· забезпечення стійкості роботи системи і збереження інформації - адміністрування;

· своєчасна модернізація і ремонт окремих елементів - технічна підтримка;

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

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

В іншому випадку в межах існуючої системи можуть з'явитися фрагменти, які в майбутньому зроблять ефективну експлуатацію системи неможливою. Зараз за рубежем стало загальноприйнятим передавати функції технічної підтримки і частково адміністрування постачальникам системи або системним інтеграторам. Ця практика отримала назву «аутсорсинг». Часто в межах аутсорсингу стороннім організаціям передаються й такі функції, як створення і підтримка резервних сховищ даних і центрів виконання критичних бізнес-додатків, які задіюються у разі стихійного лиха або інших особливих умов.

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