Тема 1. Вступ. Основні поняття: системи, інформаційні системи.

ВСТУП

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

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

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

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

Тема 1. Вступ. Основні поняття: системи, інформаційні системи.

План

1. Основні визначення і поняття інформаційної системи

2. Розподіл інформаційних систем за технічним рівнем

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

Розподіл інформаційних систем за технічним рівнем

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

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

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

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

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

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

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

Питання для контролю

1. Визначте поняття системи та інформаційної системи.

2. Яка головна мета інформаційної системи?

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

4. Розкрийте елементи розподілу інформаційних систем за характером опрацьованої інформації.

5. Розкрийте поняття і приклади ручних інформаційних систем.

6. Як відбувається функціонування механізованих інформаційних систем?

7. Розкрийте поняття автоматизованих та автоматичних інформаційних систем.

8. Яка відмінність автоматизованих інформаційних систем від автоматичних?

9. Які інформаційні системи називаються оперативними?

10. Які системи називають управлінськими?

11. Які інформаційні системи відносяться до інформаційно-розрахункових систем?

12. Які інформаційні системи відносяться до інформаційно-логічних систем?

План

1. Етапи розвитку інформаційних систем.

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

3. Основні складові корпоративних інформаційних систем.

4. Співвідношення між складовими інформаційної системи.

Питання для контролю

1. Назвіть основні етапи розвитку інформаційних систем.

2. Які загальні властивості, характерні для інформаційних систем?

3. Які основні складові корпоративних інформаційних систем?

4. Які співвідношення між складовими інформаційної системи ви знаєте?

План

1. Сфера застосування інформаційних технологій.

2. Приклади реалізації інформаційних систем.

3. Життєвий цикл інформаційних систем.

Питання для контролю

1. Яка сфера застосування притаманна інформаційним систем?

2. Наведіть приклади реалізації ІС.

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

4. Охарактеризуйте каскадну модель життєвого циклу.

5. Охарактеризуйте спіральну модель життєвого циклу.

6. Охарактеризуйте модель «швидкого прототипу» життєвого циклу.

План

1. Поняття баз даних та її структурних елементів

2. Журналізація

3. Підтримка мов баз даних

Журналізація

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

- м'які збої пов'язані з раптовою зупинкою роботи комп'ютера. Зазвичай є наслідком раптового виключення живлення або "зависання" операційної системи (що особливо характерно для операційних систем Windows);

- жорсткі збої характеризуються втратою інформації на носіях зовнішньої пам'яті.

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

У будь-якому випадку для відновлення інформації в базі даних необхідно мати деяку додаткову інформацію. Таким чином, для підтримки надійності зберігання даних вимагається надмірність даних. Причому та частина інформації, яка використовується для відновлення, повинна зберігатися особливо надійно. Найбільш поширеним методом підтримки такої надлишкової інформації є ведення журналу змін бази даних. Журнал є особливою частиною бази даних, недоступною користувачам СУБД і підтримувану з особливою ретельністю (іноді використовуються дві копії журналу, що розташовуються на різних фізичних дисках), в яку поступають записи про усі зміни основної частини бази даних. У різних СУБД зміни бази даних журналізуються на різних рівнях: іноді запис в журналі відповідає деякій логічній операції зміни бази даних, іноді – мінімальній внутрішній операції модифікації сторінки зовнішньої пам'яті. Можуть також використовуватися одночасно обидва підходи. У усіх випадках дотримуються стратегії "попереджуючого" запису в журнал (так званого протоколу Write Ahead Log – WAL). Образно можна сказати, що ця стратегія полягає в тому, що запис про зміну будь-якого об'єкту бази даних має бути занесений в журнал до того, як буде виконана і зафіксована зміна цього об'єкту. Якщо в СУБД коректно реалізується протокол WAL, то за допомогою журналу можна вирішити усі проблеми відновлення бази даних після будь-якого збою.

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

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

Підтримка мов баз даних

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

- мова визначення схем даних (Schema Definition Language, SDL) служить головним чином для визначення логічної структури бази даних;

- мова маніпулювання даними (Data Manipulation Language, DML) містить набір операторів маніпулювання даними, тобто операторів, що дозволяють заносити дані в базу, а також видаляти, модифікувати або вибирати існуючі дані.

Декілька різних спеціалізованих мов баз даних підтримувалося лише в ранніх СУБД. У сучасних СУБД зазвичай підтримується єдина інтегрована мова, що містить усі необхідні засоби для роботи з базою даних, починаючи від її створення, і забезпечуючи базовий користувацький інтерфейс з базами даних. Стандартною мовою найбільш поширених нині реляційних СУБД є мова SQL (Structured Query Language). Таким чином, вказані вище мови баз даних на сьогодні фактично є підмножинами єдиного стандартного мови SQL.

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

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

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

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

Класифікація ІС за масштабом

Багаторівнева архітектура

Класифікація ІС за масштабом

За масштабом інформаційні системи поділяються на наступні групи: одинарні, групові, корпоративні.

Одинарні інформаційні системи реалізуються, як правило, на автономному ПК (мережа не використовується). Така система може містити декілька простих застосувань, пов'язаних загальним інформаційним фондом, і розрахована на роботу одного користувача або групи користувачів, що розділяють за часом одне робоче місце. Подібні застосування створюються за допомогою так званих настільних або локальних систем управління базами даних (СУБД). Серед локальних СУБД найбільш відомими є Clarion, Clipper, FoxPro, Paradox, dBase і Qicrosoft Access.

Групові інформаційні системи орієнтовані на колективне використання інформації членами робочої групи і найчастіше будуються на базі локальної обчислювальної мережі. При розробці таких застосувань використовуються сервери баз даних (звані також SQL-серверами) для робочих груп. Існує досить велика кількість різних SQL-серверів, як комерційних, так і вільно поширюваних. Серед них найбільш відомі такі сервери баз даних, як Oracle, DB2, Qicrosoft SQL Server, InlerBase, Sybase, Inforqix.

Корпоративні інформаційні системи є подальшим етапом розвитку систем для робочих груп, вони орієнтовані на великі компанії і можуть підтримувати територіально розподілені вузли або мережі. В основному вони мають ієрархічну структуру з декількох рівнів. Для таких систем характерна архітектура «клієнт-сервер» із спеціалізацією сервером або ж багаторівнева архітектура. При розробці таких систем можуть використовуватися ті ж сервери баз даних, що і при розробці групових інформаційних систем. Проте у великих інформаційних системах найбільшого поширення набули сервери Oracle, DB2 і Qicrosoft SQL Server.

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

Багаторівнева архітектура

Багаторівнева архітектура стала розвитком архітектури «клієнт-сервер» і у своїй класичній формі складається з трьох рівнів:

· нижній рівень є застосуваннями клієнтів, що виділені для виконання функцій і логіки представлень PS і PL і мають програмний інтерфейс для виклику застосування на середньому рівні;

· середній рівень є сервером застосувань, на якому виконується прикладна логіка BL;

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

Подібну концепцію обробки даних пропагують, зокрема фірми Oracle, Sun, Borland та ін.

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

Централізація логіки застосування спрощує адміністрування і супровід. Чітко розділяються платформи і інструменти для реалізації інтерфейсу і прикладної логіки, що дозволяє з найбільшою віддачею реалізовувати їх фахівцями вузького профілю. Нарешті, зміни прикладної логіки не зачіпають інтерфейсу, і навпаки. Але оскільки межі між компонентами PL, BL і DL розмиті, прикладна логіка може з'явитися на усіх трьох рівнях. Сервер застосувань за допомогою монітора транзакцій забезпечує інтерфейс з клієнтами і іншими серверами, може управляти транзакціями і гарантувати цілісність розподіленої бази даних. Засоби видаленого виклику процедур найбільш відповідають ідеї розподілених обчислень: вони забезпечують з будь-якого вузла мережі виклик прикладної процедури, розташованої на іншому вузлі, передачу параметрів, видалену обробку і повернення результатів.

Із поширенням систем «клієнт-сервер» необхідність трьох рівнів стає усе більш очевидною. Продукти для триланкової архітектури, так звані монітори транзакцій, є відносно новими. Ці інструменти в основному орієнтовані на середовище UNIX, проте прикладні сервери можна будувати на базі Windows NT з використанням виклику віддалених процедур для організації зв'язку клієнтів з сервером. На практиці в локальній мережі може використовуватися змішана архітектура (дворівневі і трирівневі) з одним і тим же сервером БД. З урахуванням глобальних зв'язків архітектура може мати більше трьох ланок. Нині з'явилися нові інструментальні засоби для гнучкої сегментації застосувань «клієнт-сервер» по різних вузлах мережі.

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

Тема 6. Управління проектами

План

Класифікація проектів

Класифікація проектів

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

Клас проекту визначається по складу і структурі проекту. Зазвичай розрізняють:

· монопроект (окремий проект, який може бути будь-якого типу, виду і масштабу);

· мультипроект (комплексний проект, що складається з ряду монопроектів і вимагає застосування багатопроектного управління)

Тип проекту визначається по основних сферах діяльності, в яких здійснюється проект. Можна виділити п'ять основних типів проекту :

1) технічний;

2) організаційний;

3) економічний;

4) соціальний;

5) змішаний.

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

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

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

Масштаб проекту визначається за розмірами бюджету і кількості учасників:

· дрібні проекти;

· малі проекти;

· середні проекти;

· великі проекти.

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

План

Концептуальна фаза

Розробка технічної пропозиції

Концептуальна фаза

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

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

Можна виділити наступні фази розвитку інформаційної системи:

1. формування концепції;

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

3. проектування;

4. виготовлення;

5. введення системи в експлуатацію.

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

Розглянемо кожну з фаз детальніше.

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

· формування ідеї, постановку мети ІС;

· формування ключової команди проекту;

· вивчення мотивації і вимог замовника та інших учасників;

· збір початкових даних і аналіз існуючого стану;

· визначення основних вимог і обмежень, необхідних матеріальних, фінансових та трудових ресурсів;

· порівняльну оцінку альтернатив;

· представлення пропозиції, їх експертизу і твердження.

Розробка технічної пропозиції

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

· розробка основного змісту проекту, його базової структури;

· розробка і затвердження технічного завдання;

· планування, декомпозиція базової структурної моделі проекту;

· складання кошторису і бюджету проекту, визначення потреби в ресурсах;

· розробка календарних планів та графіків робіт;

· підписання контракту із замовником;

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

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

· виконання базових проектних робіт;

· розробка приватних технічних завдань;

· виконання концептуального проектування;

· складання технічних специфікацій і інструкцій;

· представлення проектної розробки, експертиза і твердження.

Розробка

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

· виконання робіт по розробці програмного забезпечення;

· виконання підготовки до впровадження системи;

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

Примітка

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

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

· помилки у визначенні інтересів замовника;

· концентрація на маловажних, сторонніх інтересах;

· неправильна інтерпретація початкової постановки завдання;

· неправильне або недостатнє розуміння деталей;

· неповнота функціональних специфікацій (системних вимог);

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

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

Примітка

ISO - International Organization of Standardization (міжнародна організація по стандартизації).

IEC - International Bectrotechnical Commission (міжнародна комісія з електротехніки).

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

· основні процеси життєвого циклу (придбання, постачання, розробка, експлуатація, супровід);

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

· організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка і поліпшення самого життєвого циклу, навчання).

Розглянемо кожну з вказаних груп детальніше.

Розробка

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

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

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

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

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

Експлуатація

Експлуатаційні роботи можна підрозділити на підготовчі і основні.

До підготовчих відносяться:

· конфігурація бази цих і робочих місць користувачів;

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

· навчання персоналу.

Основні експлуатаційні роботи включають:

· безпосередньо експлуатацію;

· локалізацію проблем і усунення причин їх виникнення;

· модифікацію програмного забезпечення;

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

· розвиток і модернізацію системи.

Супровід

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

Основними попередніми діями при підготовці до організації технічного обслуговування інформаційної системи являються наступні:

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

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

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

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

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

Допоміжні процеси

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

Організаційні процеси

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

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

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

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

· навчання персоналу.

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

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

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

Лекція 9

Початкова стадія

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

Ділове застосування включає:

· критерії успіху розробки;

· оцінку ризику;

· оцінку ресурсів, необхідних для виконання розробки;

· календарний план з вказівкою термінів завершення основних етапів.

Стадія уточнення

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

Стадія конструювання

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

Стадія переходу

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

Моделі життєвого циклу інформаційної системи

Моделлю життєвого циклу інформаційної системи називатимемо деяку структуру, що визначає послідовність здійснення процесів, дій і завдань, що виконуються упродовж життєвого циклу інформаційної системи, а також взаємозв'язку між цими процесами, діями і завданнями. У стандарті ISO/TEC 12207 не конкретизуються в деталях методи реалізації і виконання дій і завдань, що входять в процеси життєвого циклу інформаційної системи, а лише описуються структури цих процесів. Це цілком зрозуміло, оскільки регламенти стандарту є загальними для будь-яких моделей життєвого циклу, методологій і технологій розробки. Модель же життєвого циклу залежить від специфіки інформаційної системи і умов, в яких вона створюється і функціонує. Тому не має сенсу, а пропонувати які-небудь кон-кретные моделі життєвого циклу і методи розробки інформаційних систем для загального випадку, без прив'язки до певної предметної області. До теперішнього часу найбільшого поширення набули наступні дві основні моделі життєвого циклу :

· каскадна модель, іноді також звана моделлю "водоспад" (waterfall);

· спіральна модель.

Лекція 10

Недоліки каскадної моделі

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

· істотна затримка отримання результатів;

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

· складність розпаралелювання робіт за проектом;

· надмірна інформаційна перенасиченість кожного з етапів;

· складність управління проектом;

· високий рівень ризику і ненадійність інвестицій.

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