Інформаційні системи 2 лютого

У реальному масштабі часу.

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

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

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

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

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

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

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

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

Правове забезпечення функціонування СОД включає:

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

• Правило користування інформацією, і порядок поділу сторін з приводу її достовірності.

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

Організаційні комп'ютерні ІС

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

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

Поняття життєвого циклу ІС

Поняття життєвого циклу ІС є одним з базових програм інженерії. Життєвий цикл ІС визначається як період часу, який починається з моменту прийняття рішень про необхідність створення ІС і закінчується в момент її повного вилучення з експлуатації. Основним нормативним документом який регламентує склад процесів життєвого циклу, є міжнародний стандарт ISO / IEC 12207.

Схема життєвий цикл ІС

На малюнку представлені етапи життєвого циклу ІС, що відображає основні процеси проектування.

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

Під моделлю ЖЦ ІС розуміється структура визначає послідовність виконання та взаємозв'язку процесів дій і завдань протягом життєвого циклу.

Серед моделей ЖЦ можна виділити наступне:

1. Каскадне (до 70г).

2. Інтернаціональна (70-80 рр..).

3. Спіральна (80-90 рр..).

Принциповою особливістю каскадного підходу є:

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

Переваги застосування каскадного способу полягає:

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

2. Їх в логічній послідовності стадій робіт, дозволяють планувати терміни завершення всіх робіт і відповідні витрати.

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

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

Спіральний метод проектування

Принциповою особливістю спірального методу є наступне:

• ІС створюється не відразу, як у разі каскадного підходу, а по частинах, з використанням методу проектування.

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

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

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

Підхід RAD (Rapid Application Development)

Одним з можливих підходів до розробки ІС в рамках спіральної моделі життєвого циклу є одержав широке поширення спосіб так званої швидкої розробки додатків (RAD). Підхід RAD передбачає наявність трьох складових:

1. Команди розробників від 3-7 чоловік (повинні представляти собою групи професіоналів мають досвід програмування і тестування програмного забезпечення).

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

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

Планування розробки ІС

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

Планування розробки ІС полягає в певних трьох основних компонентів:

1. Визначення мети і розробки.

2. Попередня економічна оцінка проекту.

1. Побудова графіка виконання робіт.

Планування розробки ІС має бути пов'язане із загальною стратегією побудови ІС організації. Суть цієї стратегії полягає у вирішенні таких основних завдань, як:

1. Визначення бізнес-планів та цілей і цілей організації з наступним виділенням її потреб в ІТ.

2. Оцінка показників вже існуючих ІС з метою виявлення їх сильних і слабких сторін.

3. Оцінка можливостей використання ІТ для досягнення конкурентно здатного переваги.

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

Визначення вимог до системи

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

1. Попереднє виявлення вимог до бедующей системі.

2. Визначення переліку цільових функцій організації.

3. Аналіз розподілу функцій по підрозділах і співробітникам.

4. Виявлення функціональних взаємодій між підрозділами; інформаційних потоків усередині підрозділів і між ними.

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

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

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

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

Проектування БД, вибір цільової СУБД і проектування користувальницького інтерфейсу

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

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

Логічне проектування БД - це процес створення моделі використовуваної на підприємстві при проектуванні з урахуванням вибраної моделі організації даних. Незалежно від типу цільової СУБД і інших фізичних аспектів реалізації. Мета логічного проектування полягає у створенні моделі даних для досліджуваної частини підприємств. Концептуальна модель даних створюється на попередньому етапі, уточнюється і перетвориться в логічну модель даних. Враховує особливості обраної моделі організації даних цільової СУБД. Однак на цьому етапі ігноруються всі інші аспекти обраної СУБД - наприклад будь-які особливості фізичної організації її структур зберігання даних і побудови індексів.

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

• Створення набору реляційних таблиць і обмеженнями на основі інформації, представленої в логічної моделі даних.

• Визначення конкретних структур зберігання даних і методів доступу до них, забезпечують негативну продуктивність системи з БД.

• Розробки засобів захисту створюваної системою.

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

Розробка додатків - це проектування інтерфейсу користувача та прикладних програм призначеної для роботи з БД. У ЖЦ ІС проектування БД і додатків виконуються паралельно. У більшості випадків проектування додатків не можна завершити до опису проектування БД. З іншого боку БД призначена для підтримки додатків.

Необхідно переконається, що всі функціональні можливості, передбачені в специфікаціях вимог користувачів, забезпечуються інтерфейсом користувача відповідних додатків. Це відноситься як проектування програм доступу до інформації баз даних, так і до проектування транзакцій, тобто проектування методів доступу до БД. В результаті виконання всіх етапів проектування буде підготовлено все, що необхідно для реалізації БД і прикладних програм. Реалізація БД здійснюється за допомогою створення її опису мовою визначення даних OLE, DDL. Команди DDL мови компілюються і використовуються для створення схем і порожніх файлів БД, на цьому ж етапі визначаються всі специфічні для користувача представлення.

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

В даний час будь-яка СУБД має утиліту завантаження вже існуючих файлів в нову БД.

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

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

• Контроль продуктивності системи. Якщо продуктивність падає нижче прийнятного рівня, то може знадобитися додаткова настройка або реорганізація БД.

• Супровід та модернізація ІС. Нові вимоги включаються в додатки БД при повторному виконанні попередніх етапів ЖЦ.

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

У відповідності зі стандартом ISO / IEC 12207 всі процеси життєвого циклу розділені на 3 групи.

Основні процеси Придбання Постачання Розробка Експлуатація Супровід	Допоміжні процеси Документування Управління конфігурацією Забезпечення якості Верифікація Атестація, спільна оцінка Аудит Дозвіл проблем
Організаційний процес Управління Створення інфраструктури Удосконалення Навчання

Процеси життєвого циклу програмного забезпечення

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

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

Основні процеси життєвого циклу

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

Даний процес охоплює такі дії:

1. Ініціювання придбання.

2. Підготовка заявочних додатків.

3. Підготовка до коригування договору.

4. Нагляд за діяльністю постачальника.

5. Приймання і завершення роботи.

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

1. Ініціювання поставки.

2. Підготовка відповіді на заявочні пропозиції.

3. Підготовка договору.

4. Планування.

5. Виконання та контроль.

6. Постачання і завершення роботи.

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

1. Підготовка роботи.

2. Аналіз вимог до системи.

3. Проектування архітектури системи.

4. Аналіз вимог до програмного забезпечення.

5. Проектування архітектури.

6. Детальне проектування.

7. Підготовка і тестування ПЗ.

8. Інтеграція ПЗ.

9. Кваліфікаційне тестування ПЗ.

10. Інтеграція системи.

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

1. Підготовчу роботу.

2. Аналіз проблем і запитів на модифікацію ПЗ.

3. Модифікація.

4. Перевірку та приймання.

5. Перенесення ПЗ в інше середовище.

6. Зняття ПЗ з експлуатації.

Використання case коштів

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

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

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

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

2. Інтеграція окремих компонентів case коштів забезпечують керованість процесом розробки ІС.

3. Використання спеціальним чином організованого сховища проектних метаданих.

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

Російський стандарт ГОСТ 34.602-89

ІТ комплекс стандартів на автоматизованій системі, технічне завдання на створення автоматизованих систем. ГОСТ 34.601-90 автоматизовані системи, стадії створення.

Всі ці стандарти утворюють групу ГОСТ 34. Згідно ГОС 34 проект має наступні стадії:

1. Формування вимог до автоматизованої системи, стадії формування системи.

• Обстеження об'єкта та обгрунтування необхідності проектування.

• Визначення вимог замовника.

• Звіт про роботу.

• Заявка на розробку технічних завдань.

2. Розробка концепції.

• Вивчення об'єкта.

• Проведення НДР (науково-дослідницькі роботи).

• Розробка варіантів автоматизованих систем і звіт про роботу.

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

4. Розробка ескізного проекту автоматизованої системи.

• Попереднє рішення по всій системі і окремих компонентів.

• Розробка документації.

5. Розробка технічного проекту.

• Ретельне опрацювання всієї системи в цілому і окремих компонентів.

• Розробка та оформлення технічної документації.

6. Розробка документації.

• Розробка і адаптація ПЗ.

7. Введення розробленої системи в дію.

• Підготовка об'єкта автоматизації.

• Підготовка персоналу.

• Комплектація автоматизованої системи програмами і технічними засобами.

• Монтажні роботи.

• Пуско-наладка.

• Попередні випробування.

• Досвідчені експлуатації.

• Приймальні випробування.

8. Супроводження.

• Виконання робіт відповідно до гарантованими зобов'язаннями.

• Після гарантійне обслуговування.

Принципи та стандарти документування ІС

Документацію на програмні засоби розробляються під час розробки самого програмного засобу (тобто на всіх етапах ЖЦ).

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

Всю документацію на програмні засоби можна розділити на:

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

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

Технологічна документація

1. Визначає структуру і зміст вихідних і звітних документів по всіх етапах ЖЦ ІС.

2. Численну структуру програмних та інформаційних компонентів і БД ІС.

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

4. Мова і правила програмування, коментування тексту в програмах.

5. Методи тестування випробувань та атестація.

Експлуатаційна документація

1. Керівництва адміністраторів і операторів для використання і безпосереднього управління.

2. Керівництво операторів користувача.

3. Документація супроводу.

4. Довідник з управління.

5. Навчальні керівництва по роботі з програмами.

Організація документування

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

1. Склад підрозділів та посадових осіб, які будуть відповідати за документування.

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

3. Перелік категорій фахівців, кількість штатних одиниць та їх функціональної обов'язків.

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