Тестування програм та систем

1 Методологія створення інформаційних систем

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

─ забезпечувати створення ІС, що відповідають пропонованим до них вимогам по автоматизації ділових процесів, цілям і задачам організації;

─ гарантувати створення системи із заданою якістю в заданий термін і в рамках виділеного бюджету;

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

─ забезпечувати створення ІС, що відповідають вимогам відкритості, переносу та масштабованості;

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

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

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

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

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

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

Сутність методології. Розглянута методологія створення ІС складається із двох основних взаємозалежних частин:

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

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

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

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

Таким чином, фундамент пропонованої методології становлять:

─ ітераційна модель життєвого циклу ІС;

─ комплекс систем погоджених моделей, що розвиваються;

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

─ методологія синтезу ІС.

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

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

Ці процеси в тому або іншому ступені присутні на кожному з етапів. Процеси керування проектом: планування, організація, контроль.

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

2 Стадії і етапи життєвого циклу ІС

1. Аналіз.

1.1. Обстеження та створення моделей функціонування організації.

1.2. Аналіз моделей існуючих інформаційних мереж.

1.3. Формування вимог до інформаційної мережі організації.

1.4. Розробка плану створення інформаційної мережі організації.

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

2.1. Концептуальне проектування інформаційної мережі організації.

2.2. Розробка архітектури інформаційної мережі організації.

2.3. Проектування спільної моделі даних.

2.4. Формування вимог до додатків.

3. Розробка.

3.1. Розробка, прототипування та тестування додатків.

3.2. Розробка інтегральних тестів.

3.3. Розробка документації для користувача.

4. Інтеграція та тестування.

4.1. Інтеграція та тестування додатків у складі системи.

4.2. Оптимізація додатків і баз даних.

4.3. Підготовка експлуатаційної документації.

4.4. Тестування системи.

5. Впровадження.

5.1 Навчання користувачів.

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

5.3 Інсталяція баз даних.

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

5.5 Здійснення приймально-здавальних випробувань.

6. Супровід.

6.1. Реєстрація, діагностика та локалізація помилок.

6.2. Внесення змін і тестування.

6.3. Керування режимами роботи ІС.

За допомогою CASE-засобів (Computer Aided Software Engineering – комп'ютерне проектування програмних засобів) моделі створюються, перетворюються та контролюються.

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

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

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

Ця особливість визначає можливості:

─ оперативного й швидкого перегляду вимог і розроблених рішень на основі сучасних засобів;

─ нерівномірної, паралельної розробки різних частин проекту;

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

─ версійного характеру зміни проекту за підтримкою CASE-засобів.

3 Моделі життєвого циклу ПЗ

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

Модель ЖЦ ПЗ - це структура, що визначає послідовність виконання і взаємозв'язок процесів, дій, задач протягом ЖЦ.

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

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

Найбільшого поширення набули дві моделі: каскадна (водоспадна), створена в 1970-1985 pp., та спіральна, створена в 1986-1990 рр.

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

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

Рисунок 2.5.1 - Каскадна модель життєвого циклу 1С

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

Переваги застосування каскадної моделі:

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

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

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

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

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

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

Для подолання перерахованих проблем у середині 1980-х років була запропонована спіральна модель ЖЦ ПЗ (рис. 2.5.2).

Спіральна модель (spiral model) була розроблена Барі Боемом. Вона ґрунтується на класичному циклі Демінга PDCA (plan-do-check-act). При використанні цієї моделі ІС створюється в кілька ітерацій (витків спіралі) методом прототипування.

Нині ця модель досить поширена. Найвідоміші приклади її реалізації - це RUP (Rational Unified Process) фірми Rational і MSF (Microsoft Solution Framework). Створення ІС за такої моделі має ітераційниЙ характер і рухається по спіралі, проходячи стадії, де на кожному витку уточнюються характеристики майбутнього інформаційного продукту.

Рисунок 2.5.2 - Модель спірального процесу розроблення ІС

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

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

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

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

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

4 Методи розробки моделей інформаційних систем

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

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

Структурні методи мають три основні особливості:

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

─ ієрархічне впорядкування виділених елементів системи з визначенням взаємозв'язків між ними;

─ використання графічного подання взаємозв'язків елементів системи.

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

У числі методологій структурного аналізу до найпоширеніших можна віднести наступні:

─ SADT (Structured Analysis and Design Technique) – технологія структурного аналізу та проектування і її підмножина стандарт IDEF (IcamDefinition);

─ DFD (Data Flow Diagrams) - діаграми потоків даних;

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

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

Нижче ми коротко розглянемо сутність цих методологій.

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

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

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

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

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

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

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

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

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

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

Ці моделі оперують такими поняттями, як класи, екземпляри, інкапсуляція, поліморфізм, спадкування та ін. У результаті застосування об’єктно-орієнтованого підходу модель системи так само, як і при використанні структурних методів, представляється сукупністю діаграм, які будуються за певними правилами. Одним із прикладів об’єктно-орієнтованих методологій може служити методологія UML (Unified Modeling Language). Об’єктно-орієнтований підхід не протиставляється структурному, а може служити його доповненням. Наприклад, для формалізації моделі бізнесу може використовуватися методологія IDEF, а при побудові моделі системи керування - методологія UML.

5 Стратегії розробки інформаційних систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 Документація на розробку ІС

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

Склад комплексу матеріалів ІС може включати окремі документи:

1. Загальні положення (звіт про обстеження, науково-дослідну роботу)

2. Технічне завдання

3. Ескізний проект

4. Технічний проект

5. Робочий проект.

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

Технічне завдання може містити:

1) загальні відомості;

2) призначення та мету розробки ;

3) характеристику об‘єктів ІС;

4) загальні положення і основні вимоги;

5) склад та зміст робіт зі створення ІС;

6) порядок контролю та приймання ІС;

7) вимоги до складу і змісту робіт до вводу ІС в дію;

8) вимоги до документації;

9) джерела розробки.

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

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

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

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

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

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

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

Технічний проект: може складатись з переліка документів:

─ опис постановки задачі;

─ опис алгоритму;

─ опис інформаційного забезпечення;

─ опис технічного забезпечення;

─ опис організаційного забезпечення.

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

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

─ загальні положення та основні умови використання ІС;

─ схема взаємозв‘язків;

─ функціональні можливості;

─ тексти програм;

─ опис програм;

─ посібник програміста;

─ посібник оператора;

─ посібник системного програміста;

─ опис контрольного прикладу.