Вимоги, що пред'являються до КІС

Лекція 4.

АРХІТЕКТУРА КІС ТА ВИМОГИ ДО НИХ

Архітектура КІС

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

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

Спочатку системи такого рівня базувалися на класичній дворівневій клієнт-серверній архітектурі(рис. 1).

Рис.1. Дворівнева клієнт-серверна архітектура

Ця клієнт-серверна архітектура характеризується наявністю двох взаємодіючих самостійних модулів – автоматизованого робочого місця (АРМа) і сервера бази даних, в якості якого може виступати Microsoft SQL Server, Oracle, Sybase і інші. Сервер БД відповідає за зберігання, управління і цілісність даних, а також забезпечує можливість одночасного доступу декількох користувачів. Клієнтська частина представлена так званим “товстим” клієнтом, тобто додатком (АРМ) на якому сконцентровані основні правила роботи системи і розташований призначений для користувача інтерфейс програми. При усій простоті побудови такої архітектури, вона володіє безліччю недоліків, найбільш суттєві з яких – це високі вимоги до мережевих ресурсів і пропускної спроможності мережі компанії, а також складність оновлення програмного забезпечення із-за бізнес-логіки, що “розмита”, між АРМом і сервером БД. Крім того, при великій кількості АРМів зростають вимоги до апаратного забезпечення сервера БД, а це, як відомо, найдорожчий вузол у будь-якій інформаційній системі.

Як бачимо, мінусів у такої архітектури досить, а рішення тривіальне – треба відокремити бізнес-логіку від клієнтської частини і СУБД, виділивши її в окрему частину. Так і поступили розробники і наступним кроком розвитку клієнт-серверної архітектури стало впровадження середнього рівня, що реалізовує завдання бізнес-логіки і управління механізмами доступу до БД (рис. 2).

Рис. 2. Трирівнева клієнт-серверна архітектура (Three - tier architecture)

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

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

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

Рис. 3. Розподілена архітектура системи

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

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

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

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

Така архітектура системи також дозволяє організувати розподілені обчислення між клієнтськими машинами. Наприклад, розрахунок якого-небудь завдання, що вимагає великих обчислень, можна розподілити між сусідніми АРМами завдяки тому, що вони, як правило, мають одну інформацію у своїх БД і, таким чином, добитися максимальної продуктивності системи.

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

Вимоги, що пред'являються до КІС

КІС повинні відповідати цілому набору обов'язкових вимог:

1. В першу чергу, варто відмітити використання архітектури клієнт-сервер з можливістю застосування більшості промислових СУБД

2. Підтримку розподіленої обробки інформації

3. Модульний принцип побудови з незалежних функціональних блоків з розширенням за рахунок відкритих стандартів (API, COM+, CORBA і інші)

4. Забезпечувати підтримку технологій Internet/intranet.

Гнучкість

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

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

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

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

Надійність

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

Ефективність

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

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

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

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

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

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

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

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

Безпека

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

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

Система, що не відповідає вимогам безпеки, може заподіяти збиток інтересам замовника, передусім майновим.

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

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

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

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

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