Класифікація автоматизованих інформаційних систем (АІС). АІС загального призначення. Структура АІС

· від несанкціонованого доступу;

· від різних типів вірусів;

· від витоку інформації по каналах електромагнітного випромінювання

 

. Критерії надійності  та якості інформаційних систем.

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

1. Адекватність  відображення предметної області.

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

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

4. Здатність  адаптуватись до умов, що змінюються.

5. Здатність  функціонувати в реальних умовах  людської діяльності.

6. Забезпечення  перевірки вірогідності даних  при введенні в систему.

7. Можливість  взаємодії з користувачами різних  категорій і в різних режимах.

8. Технологічність  обробки даних (дружній інтерфейс, прийнятні тимчасові характеристики  об'єкта і т.п.).

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

Для визначення загального рівня розвитку технологічних процесів у програмних організаціях SEI і Університет Карнегі-Меллона розробили спеціальну систему оцінки зрілості технологічних процесів в організаціях, що спеціалізуються на випуску ПЗ. Запропонована ними модель Capability Maturity Model (CMM) заснована на так називаних рівнях зрілості (maturity levels). Усього їх п'ять, і кожний із них характеризує визначений ступінь якості, що випускаються виробів.

Рівень 1. Початковий (initial). На даному етапі процес розробки носить неструктурований і випадковий характер. У організації відсутнє стабільне середовище розробки й супроводи. Терміни випуску продуктів, як правило, не витримується. За оцінкою SEI, у даний час біля 75% софтверних фірм перебувають на початковому рівні.

Рівень 2. Повторюваний (repeatable). Успішна реалізація проектів стає можливою завдяки жорсткому управлінню, плануванню та контролю. Акцент у даному випадку робиться на вироблення вихідних вимог, методи оцінки і конфігураційний менеджмент. Розробка нових проектів ведеться на основі раніше накопиченого досвіду і відповідно до визначених стандартів на розробку ПО. Даний рівень може забезпечити біля 15% організацій. Як показує практика, перехід із першого рівня на другий найбільше складний, оскільки вимагає комплексного впровадження основних технологічних процедур.

Рівень 3. Фіксований (defined). Процеси, що відносяться до сфери управління й інженерної діяльності, повністю документовані, стандартизовані й інтегровані в єдиний технологічний потік, контрольований керівним персоналом. Цей рівень у стані підтримувати 8% софтверних компаній.

Рівень 4. Керований (managed). Організації намагаються оцінити якість процесів і готового продукту кількісно. Для контролю над процесами використовуються кількісні показники (метрики). Усі процеси передбачувані й, укладаються в заздалегідь визначені рамки. Даного рівня досягло біля 1,5% організацій.

Рівень 5. Такий, що оптимізується (optimizable).

Компанії прагнуть поліпшити свою роботу, керуючись кількісними критеріями якості. Є засоби локалізації вузьких місць у виробничих процесах. Основна ціль - випуск бездефектних продуктів, у яких усі помилки усунуті ще на стадії внутрішнього тестування. Тільки 0,5% компаній можуть підтримувати настільки високий рівень технологічної зрілості.

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

 

 

 

 

 

 

2.3. Відкриті системи.

 

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

 

В информатике открытая система обозначает аппаратуру и/или программное обеспечение, которое обеспечивает переносимость и совместимость, а часто и их вместе с другими компьютерными системами.

 

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

 

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

 

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

 

III. Автоматизація процесів проектування та супроводу автоматизованих інформаційних систем

3.1. CASE-технології.

CASE (Computer-Aided Software/System Engineering) - технологія являє собою сукупність методологій аналізу, проектування, розробки і супроводу складних систем програмного забезпечення (ПЗ), підтриману комплексом взаємозалежних засобів автоматизації, це інструментарій що дозволяє автоматизувати процес проектування і розробки ПЗ. Основна мета CASE складає в тому, щоб відокремити проектування ПО від його кодування і наступних етапів розробки, а також сховати від розроблювачів усі деталі середовища розробки і функціонування ПЗ.

Крім автоматизації структурних методологій та можливості застосування сучасних методів системної і програмної інженерії, CASE мають наступні основні переваги:

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

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

звільняють розроблювача від рутинної роботи, дозволяючи йому цілком зосередитися на творчій частині розробки;

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

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

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

Серед різноманіття засобів розв'язання даних задач у методологіях структурного аналізу найчастіше й ефективно застосовуваними є наступні:

DFD (Data Plow Diagrams) - діаграми потоків даних спільно зі словниками даних і специфікаціями процесів або мініспецифікаціями;

ERD (Entity-Relationship Diagrams) - діаграми "сутність-зв'язок";

STD (State Transition Diagrams) - діаграми переходів станів.

Логічна DFD показує зовнішні відносно системи джерела і стоки (адресати) даних, ідентифікує логічні функції (процеси) і групи елементів даних, що зв'язують одну функцію з інший (потоки), а також ідентифікує сховища (нагромаджувачі) даних, до яких здійснюється доступ. Структури потоків даних і визначення їх компонентів зберігаються й аналізуються в словнику даних. Кожна логічна функція (процес) може бути деталізована за допомогою DFD нижнього рівня; коли подальша деталізація перестає бути корисної, переходять до виразу логіки функції за допомогою специфікації процесу (мініспецифікації). Вміст кожного сховища також зберігають у словнику даних, модель даних сховища розкривається за допомогою ERD. У випадку наявності реального часу DFD доповнюється засобами опису залежного від часу поведінки системи, що розкриваються за допомогою STD.

Діаграми потоків даних (DFD) є основним засобом моделювання функціональних вимог проектованої системи. З їхньою допомогою ці вимоги розбиваються на функціональні компоненти (процеси) і представляються у вигляді мережі, зв'язаної потоками даних. Головна ціль таких засобів - продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також виявити відношення між цими процесами. Декомпозиція DFD здійснюється на основі процесів: кожен процес може розкриватися за допомогою DFD нижнього рівня.

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

Діаграммы "сутність-зв’язок" (ERD) призничені для розробки моделей даних и забезпечують стандартний спосіб визначення даних и зв’язків між ними. Фактично за допомогою ERD реалізується деталізація сховищ даних системи, що проектується, а також документуються сутності системи і способи їх взаємодії, включаючи ідентифікацію об’ектів, важливих для предметної області (сутностей), властивостей цих об’ектів (атрибутів) і їх зв’язки з іншими об’ектами.

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

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

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

Перехід визначає переміщення системи, що моделюється із одного стана в інший. Ця подія звичайно складається з керуючого потоку (сигнала), що виникає як у зовнішньому світі, так: и всередині системи, що моделюється. На STD стани представляются вузлами, а переходи - дугами.  ·

 

 

3.2. Інструментальні засоби розробки інформаційних технологій.

Технології, засоби розробки та проектування

 

Операційні системи Windows 95 / 98 / NT / 2000 Unix for Intel (SCO, BSD) Linux (United Linux, RedHat, SuSE) HP-UX Novell Netware	Бази даних і сховища MS SQL Oraсle IBM/Informix DB2 Sybase InterBase Gupta Lotus Domino Btrieve	Мови програмування та інструментальні засоби Borland Delphi Borland JBuilder Power Builder Oracle Internet Developer MS Visual Basic MS Visual C++ C / C++ VB Script Assambler Unix Shell Perl
Мови запитів і доступ до даних SQL / SPL ODBC Oracle OCI JDBC API	Технології enterprise J2EE ASP JSP	Інструменти системного контролю і моніторингу IBM Tivoli HP Open View CA Unicenter
Системи управління підприємством Microsoft Dynamics NAV MS Exchange Hummingbird Enterprise MS Sharepoint Portal	Контентні мови HTML XML, XSL PDF	Засоби аналізу даних Crystal Reports Crystal Enterprise Oracle Express Hummingbird BI Business Objects
Системи підтримки транзакцій MS Transaction Server	Проміжне ПЗ COM / DCOM Corba MS MQ IBM MQ Series	Web сервери і сервери додатків  MS Internet Information Server Oracle Application Server Apache Tomcat .NET
Project технології  MS Project CA AllFusion ERwin Data Modeler CA AllFusion BPwin Business Process Modeler UML Tools Rational Rose Oracle Designer	Industry Information management CI Technologies products Siemens Building Technologies products	Індустріальні стандарти Industrial Ethernet Profibus ASI Modbus LON EIB

 

 

 

 

 

 

 

3.3. Методологія проектування, мови реалізацій, тестування, оцінка ефективності.

Методологія

Програми набувають високої якості не стільки в результаті комплексного тестування кінцевого продукту, скільки в процесі його розробки. Якщо методологія створення ПО така, що помилки "виловлюються" на регулярній основі і на всіх стадіях виконання проекту, то на виході "програмного конвеєра" постає продукт, у котрому практично немає помилок. Корпорація IBM пропонує методологію створення складних програмних комплексів, що одержала назву Cleanroom Software Engineering. Вона орієнтована на професіоналів, що бажають удосконалити свої методи розробки ПО, і охоплює такі сторони програмістської практики, як реалізація моделі CMM, планування і керування проектами, власне розробку програм (виробітку специфікацій, проектування, кодування), профілактику помилок, тестування і супровід. Cleanroom - це сукупність адміністративно-технологічних процесів, що дозволяють колективам розроблювачів планувати, вимірювати, специфікувати, проектувати, кодувати, тестувати і сертифікувати програмні продукти. Методологія Cleanroom побудована на трьох концепціях: модульному принципі специфікування і проектування, математичному доказі слушності застосовуваних алгоритмів і використанні статистики за результатами тестування як основи для оцінки надійності програм (сертифікації).

Тестування надійності

Інструментом автоматизованого тестування й оцінки надійності ПЗ в методології Cleanroom служить середовище Cleanroom Certification Assistant, в основі якої лежить ідея використання статистичних результатів тестування для підрахунку надійності ПО математичними методами. Спеціальний компонент Statistical Test Generation Facility (STGF) має власна мова опису тестових даних, що дозволяє запрограмувати сценарій тестування - характер розподілу даних, моменти виникнення критичних подій і т.д. У результаті STGF генерує код на мові C, що після компіляції і запуску подає на вхід тестує програми спробні дані. Другий компонент - Cleanroom Certification Model - фіксує результати тестування у вигляді показників MTTF (Mean Time To Failure - середній час наробітку на відмову), що і використовуються для обчислення метрик надійності.

Інша відома програма виробництва IBM - Workstation Interactive Test Tool - у сполученні з STGF дозволяє створювати додатки, що самостійно тестуються.

Верифікація і тестування

Під верифікацією ПО розуміють перевірку готового продукту або його проміжних версій (як це прийнято, наприклад, у технології Cleanroom Software Engineering) на відповідність вихідним вимогам. При цьому мається на увазі не тільки тестування самої програми, але й аудит проекту, користувацької і технічної документації і т.д. На ринку існує множина продуктів, що дозволяють автоматизувати процес верифікації. Серед них Purify, TestCenter, Logiscope і ін. Пакет Logiscope компанії Verilog - це сімейство інструментальних програм (TestChecker, CodeChecker, RuleChecker, ImpactChecker і Viewer), об'єднаних загальною ціллю: допомогти користувачам поліпшити якість і провести всебічне тестування створюваного ПО. У основі продукту лежить ідея аналізу вихідного коду. Його остання версія здатна обробляти тексти програм, написані більш ніж на 80 мовах, включаючи C, C++, Pascal, Cobol, Fortran, PL1, ADA і навіть мови асемблера Intel і Motorola. Результати аналізу представляються у вигляді числових показників (метрик, що існує більш 50 типів), що дозволяють судити про якість вихідного коду програм.