Проектуванням інформаційних систем називається багатоступеневий процес їх створення та/або модернізації шляхом застосування впорядкованої сукупності методологій та інструментарію. Проектування (на відміну від моделювання) передбачає роботу з поки що неіснуючим об'єктом і спрямоване на створення інформаційної системи в області:
- обробки об'єктів майбутньої бази даних,
- написання програм (у тому числі - звітних та екранних форм), що забезпечують виконання запитів до даних,
- виконання обліку функціонування конкретного середовища (технології).
Якщо виділяти стадію проектування інформаційних систем як окремий етап, його можна розмістити між етапами аналізу та розробки. Однак на практиці чіткий поділ на етапи, як правило, утруднений або неможливий, оскільки проектування, формально починаючи з визначення Цілі проекту, часто продовжується на стадіях тестування та реалізації.
Мета проектування інформаційної системи та пов'язані поняття
Сучасні керівники державних і приватних організацій усвідомлюють, що швидкість обробки інформації, яка постійно змінюється і зростає в обсязі, – це питання виживання компанії на ринку та конкурентна перевага. Загалом цільові установки проектів зі створення інформаційних систем зводяться до забезпечення умов, що дозволяють цю інформацію отримувати, обробляти і використовувати шляхом створення функціональної безвідмовної системи з достатнім:
- рівнем адаптивності до змінних умов,
- пропускною здатністю,
- часом системної реакції на запит,
- рівнем безпеки,
- ступенем простоти експлуатації.
Інформаційною системою (ІВ) називають сукупність інформації, що міститься в базі даних, та технологій (а також технічних інструментів), що забезпечують обробку інформації. В даному випадку, до технологій відносять і методи виявлення, збору, обробки, зберігання, поширення інформації та способи, які дозволяють ці методи реалізувати. Інформаційне управлінняпри цьому зводиться до застосування даних методів контролю за процесами планування, дизайну, експлуатації та аналізу ІВ. В основі технології проектування лежить обрана для конкретного завдання методологія як сукупність принципів, що виражається в єдиній певній концепції.
Організація проектування ІВ
Організацію проектування ІС прийнято розділяти на 2 типи:
- Канонічне проектування відбиває особливості технології оригінального (індивідуального) процесу.
- Типове проектування, для якого типове типове проектне рішення (ТПР), тиражується і придатне до багаторазового використання.
Канонічне проектування відрізняє відбиток ручної технології проектування, здійснення лише на рівні виконавців, використання інструментарію універсальної комп'ютерної підтримки.
Застосовується канонічне проектування, головним чином для локальних і відносно невеликих ІС з мінімальним використанням типових рішень. Адаптація проектних рішень відбувається лише за допомогою перепрограмування програмних модулів. 
Організовується канонічний проектування з використанням каскадної моделі життєвого циклу. Це передбачає поділ процесу на наступні стадії та етапи:
- Передпроектна стадія. Виготовляється та складається технічне завдання. Тобто формуються вимоги до ІВ, розробляється її концепція, складається техніко-економічне обґрунтування та пишеться ТЗ.
- Проектна стадія передбачає складання ескізного та технічного проектів, розробку робочої документації.
- Післяпроектна стадія дає старт заходам щодо впровадження ІВ, навчання персоналу, аналізу результатів випробування. Частиною цієї стадії стає супровід ІС та усунення виявлених недоліків.
Етапи, у разі потреби, можна укрупнювати чи деталізувати – поєднувати послідовні етапи, виключати «зайві», розпочинати виконання чергової стадії до завершення попередньої.
Метод типового проектування відрізняється можливістю декомпозиції проектованої ІВ з поділом на компоненти, до яких входять програмні модулі, підсистеми, комплекси завдань та ін. Для реалізації компонентів можна скористатися типовими рішеннями, які вже існують на ринку, і налаштувати їх під потрібні конкретні організації. При цьому типове проектування передбачає обов'язкову наявність документації, що описує деталі ТПР і процедури налаштування.
Декомпозиція може мати кілька рівнів, що дозволяє виділити класи ТПР:
- елементні – за окремим завданням (елементом),
- підсистемні – за окремими підсистемами,
- об'єктні – галузеві типові проектні рішення, містять весь набір підсистем.
Можливість реалізації модульного підходу вважається перевагою елементних ТПР. Однак у разі несумісності різних елементів процес їхнього об'єднання призводить до збільшення витрат. Підсистемні ТПР, крім реалізації модульного підходу, дають можливість провести параметричну настройку на об'єкти різних рівнів управління. Проблеми з об'єднанням виникають у разі залучення продукту кількох різних виробників програмного забезпечення. Крім того, адаптивність ТПР з позицій безперервного реінжинірингу процесів вважається недостатньою. Об'єктні ТПР, в порівнянні з попередніми класами, відрізняються великою кількістю переваг:
- масштабованістю, що робить можливим застосування конфігурацій ІВ для різного числа робочих місць,
- методологічною єдністю компонентів,
- сумісністю компонентів ІВ,
- відкритістю архітектури – можливістю розгортати проектні рішення на платформах різного типу,
- конфігурованістю – можливістю застосування необхідного підмножини компонентів ІВ.
У ході реалізації типового проектування застосовуються параметрично-орієнтований та модельно-орієнтований підходи.
Основні методології проектування ІВ
Специфічні особливості процесу проектування дозволяють виділяти методології, побудовані на різних принципах. Серед основних сучасних методологій проектування ІС називають такі:
- SADT. Методологія функціонального моделювання робіт, яка заснована на структурному аналізі та графічному поданніорганізації, як системи функцій. Тут виділяється функціональна, інформаційна та динамічна моделі. В даний час методологія відома як нотація (стандарт) IDEF0. Аналізований процес графічно представляється як чотирикутника, де зверху зображуються регламентуючі і управляючі впливу, знизу – об'єкти управління, зліва – вхідні дані, а справа – вихідні.
- RAD. Методологія швидкої розробки програм. У RAD швидка розробка додатків можлива рахунок застосування компонентно-орієнтованого конструювання. Методологія застосовується на проектах з обмеженим бюджетом, нечіткими вимогами до ІВ, за стислих термінів реалізації. До неї вдаються, якщо інтерфейс користувача можна продемонструвати в прототипі, а проект розділити на функціональні елементи.
- RUP. У методології RUP реалізуються ітераційний та нарощуваний (інкрементний) підходи. Побудова системи відбувається з урахуванням архітектури інформаційної системи, а планування і проектне управління – з урахуванням функціональних вимог до ІВ. Розробка загальної інформаційної системи відбувається ітераціями, як комплекс окремих невеликих проектів зі своїми планами та завданнями. Для ітераційного циклу характерна періодичний зворотний зв'язок та адаптація до ядра ІВ.
Існують кілька класифікацій методологій: по використанню ТПР, по застосуванню засобів автоматизації та ін. супроводжується автоматичним генеруванням проектного рішення).
Сервісний центр - організація, що займається наданням послуг із сервісної підтримки та обслуговування техніки, обладнання та іншої продукції. Діяльність сервісних центрів включає передторговий, гарантійний та післяпродажний ремонт.
Підприємство ІП Михайлов А.О. займається ремонтом та обслуговуванням побутової технікита електроніки, а також комп'ютерів, телефонів та планшетів, які клієнти привозять до офісу, а також заправки картриджів та монтажу мереж та офісних АТС. За відсутності можливості доставити техніку самим клієнтом здійснюється виїзд на місце, та за необхідності доставляється силами сервісного центру. При зверненні клієнта до сервісного центру диспетчер оформляє заявку на прийняття замовлення. Проводиться аналіз об'єкта, внаслідок якого здійснюється висновок, чи буде виконано ремонт техніки, чи ні. Інженерний відділ складає прайс-лист з ремонту та обслуговування техніки, оскільки він працює з постачальниками запчастин та пристроїв для ремонту техніки. Ремонт проводиться спеціальним обладнаннямдотримуючись правил безпеки. Також підприємство займається продажем периферійних пристроїв для телефонів, планшетів і комп'ютерів. Підприємство займається купівлею б/в техніки та техніки, що вийшла з ладу.
На підприємстві працюють кваліфіковані спеціалістиз багаторічним досвідом роботи. Директор керує усією роботою підприємства.
Адреса підприємства:
Пермський край, м. Кунгур, вул. Леніна 66
Режим роботи:
ПН-ПТ: 10 - 19 без обіду
НД: вихідний.
Структурувавши перелік послуг, підприємство може підвищити свій прибуток, розширити межі підприємства або відкрити ще один сервісний центр в іншому місці, так само може підвищитися якість послуг, що надаються, і збільшитися кількість клієнтів.
Проведений аналіз предметної галузі надає повний опис предметної галузі підприємства ІП Михайлов А.О. для створення працездатної інформаційної системи з даного підприємства. Наведено опис роботи сервісного центру із зазначенням роботи інженерного відділу. Так само створено організаційну структуру підприємства, яка показує взаємодію директора та підлеглих.
Формування базових документів щодо управління проектом інформаційної системи
Проект – це сукупність завдань чи заходів, пов'язаних із досягненням запланованої мети, яка зазвичай має унікальний та неповторний характер.
Управління проектом (Project Management) – використання знань, навичок, методів, засобів та технологій при виконанні проекту з метою досягнення чи перевищення очікувань учасників проекту.
Щоб правильно управляти проектом інформаційної системи, потрібно сформувати базові документи з управління проектом. Базовими документами будуть Статут та План управління проектом.
Статут проекту
Статут проекту - це інструмент, який формально авторизує проект і є ланкою, що з'єднує майбутній проект поточною роботоюорганізації.
У Статуті проекту документуються початкові вимоги до проекту, які відповідають потребам та очікуванням заінтересованих сторін.
Є статут проекту.
Цей документ зазвичай відображає ситуацію з боку організації-замовника, випускається керівником, зовнішнім стосовно проекту, і призначає менеджера проекту, наділяючи його повноваженнями використання у проекті ресурсів організації.
Статут проекту має містити таку інформацію:
Вимоги до проекту та продукту проекту, у досить загальному вигляді;
Мета проекту;
Інформація про призначеного менеджера проекту та рівень його повноважень;
Розклад контрольних подій;
Відносини між учасниками проекту;
Функціональні організації та їх участь;
Допущення щодо організації та оточення, а також зовнішні припущення;
Обмеження щодо організації та оточення, а також зовнішні обмеження;
Реальна бізнес-ситуація, яка є обґрунтуванням проекту з даними про прибуток на інвестиції;
Бюджет проекту.
Статут проекту підвищує можливість успішного завершення проекту. Він документує наміри учасників проекту на самому початку проекту і може бути основною точкою вирішення спорів між учасниками проектної команди та організацією, що виконує.
При складанні статуту проекту було виконано встановлення статуту правил організації робіт за проектом за допомогою документування, стратегій, цілей, методології ведення проекту, рольових функцій та правил проекту, необхідних для досягнення бізнес-цілей проекту. Визначено відповідальних за управління та реалізацію.
Розробка статуту займає значний час. При створенні наступного проекту розроблений статут можна буде використовувати як шаблон, щоб розробка статуту зайняла менше часу. Статут проекту допомагає під час управління проектом, оскільки деяка інформація необхідна роботи у MS Project.
План управління проектом
План управління проектом (Project Management Plan) - пакет затверджених формальних документів, у яких зазначено, як проект виконуватиметься, і як відбуватиметься моніторинг та управління проектом. План може бути узагальненим або докладним, а також може містити один або кілька допоміжних планів управління та інші документи щодо планування.
p align="justify"> Процес розробки плану управління проектом є процес документації дій, необхідних для визначення, підготовки, інтеграції та координації всіх допоміжних планів. Коректно складений план управління проектом є основним джерелом інформації про те, як проект плануватиметься, оцінюватиметься, контролюватиметься та закриватиметься. План управління проектом оновлюється та редагується у рамках процесу здійснення інтегрованого управління змінами проекту.
1 Допоміжні плани управління проектом, до яких входять:
План управління змістом проекту;
План управління розкладом проекту;
План керування вартістю проекту;
План управління якістю проекту;
План керування забезпеченням персоналом;
План управління комунікаціями проекту;
План управління ризиками проекту;
План керування конфігурацією.
2 Базова лінія проекту, що складається з:
Базового розкладу проекту;
Базового плану вартості;
Базового плану з якості;
Базового плану конфігурації;
Реєстр ризиків.
3 Результати аналізу, проведеного проектною командою щодо змісту, обсягу та термінів проекту.
Для проекту інформаційної системи «Облік послуг» створено план управління проектом. (Додаток Б)
У першому пункті плану управління проектом зазначається назва проекту. Назва проекту не можна змінювати протягом усього життєвого циклу проекту.
У другому пункті визначаються цілі та завдання проекту. Цілі формуються виходячи з вимог замовника, які полягають у автоматизації основних бізнес-процесів підприємства. Були поставлені цілі, такі як залучення клієнтів та збільшення прибутку, підвищення якості послуг.
Третій пункт визначає вимоги до проектного рішення та результати проекту. Цей розділ є елементом базового змісту проекту. Для забезпечення зв'язку між вимогами замовника та результатами проекту рекомендується використовувати якість.
Четвертий пункт визначає межі проекту. Це базовий елемент змісту проекту. У межах проекту описується, що входить у проект, щоб виключити ситуацію, коли учасник проекту помилково вважає певний продукт, послугу чи результат які входять у проект.
П'ятий пункт визначає інструменти та технології для реалізації управління проектом.
У шостому пункті знаходиться ієрархічна структура робіт - модель, що розкриває проект за рівнем рівня до такої міри деталізації, яка необхідна для ефективного планування та контролю проекту.
Сьомий пункт визначає потреба у ресурсах. Вона визначається трудомісткістю робіт, відображених у розробленій раніше ІСР.
Восьмий пункт Плану показує укрупнений календарний план. Він розробляється на основі контрольних подій, інформації зі Статуту проекту та інформації із методології проектного управління, що використовується.
Дев'ятий пункт є критичні чинники успіху. Він визначає умови, забезпечення яких у проекті може бути запорукою успіху.
Десятий та одинадцяті пункти відображають припущення та обмеження з боку виконавця. При реалізації проекту обмеження може бути змінено.
Дванадцятий пункт спочатку сформульовані ризики. Вказуються вже відомі ризики та основні категорії потенційних ризиків.
Управління ризиками - це процеси, пов'язані з ідентифікацією, аналізом ризиків та прийняттям рішень, які включають максимізацію позитивних та мінімізацію негативних наслідків настання ризикових подій.
Планування управління ризиками - процес прийняття рішень щодо застосування та планування управління ризиками для конкретного проекту. Цей процес може включати рішення щодо організації, кадрового забезпечення процедур управління ризиками проекту, вибір кращої методології, джерел даних для ідентифікації ризику, тимчасовий інтервал для аналізу ситуації.
Планування управління ризиками - вибір підходів та планування діяльності з управління ризиками проекту.
1 Ідентифікація ризиків - визначення ризиків, здатних вплинути на проект, та документування їх характеристик.
2 Якісна оцінка ризиків - якісний аналіз ризиків та умов їх виникнення з метою визначення їхнього впливу на успіх проекту.
3 Кількісна оцінка - кількісний аналізймовірності виникнення та впливу наслідків ризиків на проект.
4 Планування реагування на ризики - визначення процедур та методів щодо ослаблення негативних наслідків ризикових подій та використання можливих переваг.
5 Моніторинг та контроль ризиків - моніторинг ризиків, визначення ризиків, що залишаються, виконання плану управління ризиками проекту та оцінка ефективності дій з мінімізації ризиків.
План управління ризиками наведено. (Додаток В)
План управління проектом інформаційної системи «Облік наданих послуг» дозволив створити документи та описати характеристики та межі проекту, пов'язані з ним послуги, а також методи приймання та управління змістом. Опис змісту дозволило оцінити бажаний результат і виступати як основа для складання базового плану змісту, якому необхідно слідувати під час виконання всіх робіт проекту.
Розробка базової документації з управління проектом інформаційної системи «Облік послуг» дозволила описати частину документів для якісної та благополучної реалізації управління проекту в MS Project. Запорукою успіху є розуміння необхідності цих документів у процесі управління проектами. Результатом даної роботи стали, розроблені статут проекту та план управління проектом, які будуть використані у подальшій роботі.
Результатом першого розділу стала структуризація проекту ІС «Облік послуг» для підприємства ІП Михайлов А.О., так само розроблено статут проекту та план управління проектом, які були використані в подальшій роботі з управління проектом. Процес формування базових документів це найважливіша частина управління проектом, оскільки вона впливає якість, тривалість і успішність проекту.
Вступ
Висновок
Література
Вступ
Розвиток різних сфер людської діяльностіна сучасному етапі неможливо без широкого застосування обчислювальної технікита створення інформаційних систем різного напряму. Обробка інформації у таких системах стала самостійним науково – технічним напрямом.
Після етапу побудови інформаційної моделірозпочинається проектування системи. На цьому етапі проводиться вибір технологічних рішень, на основі яких буде побудовано інформаційну систему.
Інформація в сучасному світіперетворилася на один із найважливіших ресурсів, а інформаційні системи (ІВ) стали необхідним інструментомпрактично у всіх сферах діяльності.
У реальних умовах проектування - це пошук способу, який відповідає вимогам функціональності системи засобами наявних технологій з урахуванням заданих обмежень.
Різноманітність завдань, розв'язуваних за допомогою ІВ, призвела до появи безлічі різнотипних систем, що відрізняються принципами побудови та закладеними в них правилами обробки інформації.
Метою контрольної роботиє – розглянути поетапно, процес створення інформаційних систем.
Завдання цієї роботи – з'ясувати головну мету проектування, і навіть мета створення інформаційних систем.
1. Проектування інформаційних систем
Проектування інформаційних систем завжди починається з визначення мети проекту. Основне завдання будь-якого успішного проектуполягає в тому, щоб на момент запуску системи та протягом усього часу її експлуатації можна було забезпечити:
· Необхідну функціональність системи і ступінь адаптації до умов її функціонування, що змінюються;
· Необхідну пропускну здатність системи;
· Необхідний час реакції системи на запит;
· безвідмовну роботу системи у необхідному режимі, іншими словами – готовність та доступність системи для обробки запитів користувачів;
· Простоту експлуатації та підтримки системи;
· Необхідну безпеку.
Продуктивність є основним чинником, визначальним ефективність системи. Хороше проектне рішення є основою високопродуктивної системи.
Проектування інформаційних систем охоплює три основні сфери:
· Проектування об'єктів даних, які будуть реалізовані у базі даних;
· Проектування програм, екранних форм, звітів, які забезпечуватимуть виконання запитів до даних;
· Облік конкретного середовища або технології, а саме: топології мережі, конфігурації апаратних засобів, використовуваної архітектури (файл-сервер або клієнт-сервер), паралельної обробки, розподіленої обробки даних і т.п.
Відповідно до сучасної методології, процес створення ІВ є процес побудови та послідовного перетворення низки узгоджених моделей на всіх етапах життєвого циклу (ЖЦ) ІВ. На кожному етапі ЖЦ створюються специфічні йому моделі - організації, вимог до ІВ, проекту ІВ, вимог до додатків тощо. Моделі формуються робочими групами команди проекту, зберігаються та накопичуються у репозиторії проекту. Створення моделей, їх контроль, перетворення та надання у колективне користування здійснюється з використанням спеціальних програмних інструментів – CASE-засобів.
Процес створення ІВ ділиться на ряд етапів (стадій), обмежених деякими тимчасовими рамками і закінчуються випуском конкретного продукту (моделей, програмних продуктів, документації та ін.).
Зазвичай виділяють такі етапи створення ІВ: формування вимог до системи, проектування, реалізація, тестування, введення в дію, експлуатація та супровід.
Початковим етапом процесу створення ІВ є моделювання бізнес-процесів, що протікають в організації та реалізують її цілі та завдання. Модель організації, описана у термінах бізнес-процесів та бізнес-функцій, дозволяє сформулювати основні вимоги до ІС. Це фундаментальне становище методології забезпечує об'єктивність у виробленні вимог до проектування системи. Безліч моделей опису вимог до ІС потім перетворюється на систему моделей, що описують концептуальний проект ІВ. Формуються моделі архітектури ІВ, вимог до програмного забезпечення (ПЗ) та інформаційне забезпечення(ІВ). Потім формується архітектура ПЗ та ІВ, виділяються корпоративні БД та окремі додатки, формуються моделі вимог до додатків та проводиться їх розробка, тестування та інтеграція.
Метою початкових етапів створення ІВ, виконуваних на стадії аналізу діяльності організації, є формування вимог до ІВ, які коректно і точно відображають цілі та завдання організації-замовника. Щоб специфікувати процес створення ІВ, що відповідає потребам організації, потрібно з'ясувати та чітко сформулювати, у чому полягають ці потреби. Для цього необхідно визначити вимоги замовників до ІВ та відобразити їх мовою моделей у вимоги до розробки проекту ІВ так, щоб забезпечити відповідність цілям та завданням організації.
Завдання формування вимог до ІВ є однією з найбільш відповідальних, важко формалізованих і найдорожчих і найважчих для виправлення у разі помилки. Сучасні інструментальні засоби та програмні продукти дозволяють досить швидко створювати ІС за готовими вимогами. Але найчастіше ці системи не задовольняють замовників, вимагають численних доопрацювань, що призводить до різкого подорожчання фактичної вартості ІВ. Основною причиною цього є неправильне, неточне чи неповне визначення вимог до ІС на етапі аналізу.
На етапі проектування передусім формуються моделі даних. Проектувальники як вихідна інформація отримують результати аналізу. Побудова логічної та фізичної моделей даних є основною частиною проектування бази даних. Отримана у процесі аналізу інформаційна модель спочатку перетворюється на логічну, а потім у фізичну модель даних.
Паралельно з проектуванням схеми бази даних виконується проектування процесів, щоб отримати специфікацію (опис) всіх модулів ІС. Обидва ці процеси проектування тісно пов'язані, оскільки частина бізнес-логіки зазвичай реалізується в базі даних (обмеження, тригери, процедури, що зберігаються). Головна мета проектування процесів полягає у відображенні функцій, отриманих на етапі аналізу, у модулі інформаційної системи. Під час проектування модулів визначають інтерфейси програм: розмітку меню, вид вікон, гарячі клавіші та пов'язані з ними дзвінки.
Кінцевими продуктами етапу проектування є:
· Схема бази даних (на підставі ER-моделі, розробленої на етапі аналізу);
· Набір специфікацій модулів системи (вони будуються на базі моделей функцій).
Крім того, на етапі проектування здійснюється також розробка архітектури ІВ, що включає вибір платформи (платформ) і операційної системи ( операційних систем). У неоднорідній ІВ можуть працювати кілька комп'ютерів на різних апаратних платформах та під керуванням різних операційних систем. Крім вибору платформи, на етапі проектування визначаються такі характеристики архітектури:
· Чи буде це архітектура "файл-сервер" або "клієнт-сервер";
· Чи буде це 3-рівнева архітектура з такими шарами: сервер, програмне забезпечення проміжного шару (сервер додатків), клієнтське програмне забезпечення;
· Чи буде база даних централізованою або розподіленою. Якщо база даних буде розподілена, то які механізми підтримки узгодженості та актуальності даних будуть використовуватись;
· чи буде база даних однорідною, тобто, чи будуть всі сервери баз даних продуктами одного і того ж виробника (наприклад, всі сервери тільки Oracle або всі сервери лише DB2 UDB). Якщо база даних не буде однорідною, то яке програмне забезпечення буде використане для обміну даними між СУБД різних виробників (вже існуюче або розроблене спеціально як частина проекту);
· чи будуть для досягнення належної продуктивності використовуватися паралельні сервери баз даних (наприклад, Oracle Parallel Server, DB2 UDB).
Етап проектування завершується розробкою технічного проекту ІС. На етапі реалізації здійснюється створення програмного забезпеченняексплуатаційної документації.
Після завершення розробки окремого модуля системи виконують автономний тест, який має дві основні цілі:
· Виявлення відмов модуля (жорстких збоїв);
· Відповідність модуля специфікації (наявність всіх необхідних функцій, відсутність зайвих функцій).
Після того, як автономний тест успішно пройде, модуль включається до складу розробленої частини системи та група згенерованих модулів проходить тести зв'язків, які повинні відстежити їх взаємний вплив.
Далі група модулів тестується на надійність роботи, тобто проходять, по-перше, тести імітації відмови системи, а по-друге, тести напрацювання на відмову. Перша група тестів показує, як добре система відновлюється після збоїв програмного забезпечення, відмов апаратного забезпечення. Друга група тестів визначає ступінь стійкості системи при штатній роботі та дозволяє оцінити час безвідмовної роботи системи. До комплекту тестів стійкості повинні входити тести, що імітують пікове навантаження на систему.
Потім весь комплект модулів проходить системний тест – тест внутрішнього приймання продукту, що показує рівень його якості. Сюди входять тести функціональності та тести надійності системи.
Останній тест інформаційної системи – приймально-здавальні випробування. Такий тест передбачає показ інформаційної системи замовнику та має містити групу тестів, що моделюють реальні бізнес-процеси, щоб показати відповідність реалізації вимог замовника.
1Стаття присвячена питанням побудови інформаційної системи, призначеної для аналізу інвестиційних проектів, що подаються до адміністративних структур з метою отримання фінансової підтримки. Структура такої системи є інформаційним комплексом, що складається із зовнішнього модуля та основної системи. Зовнішній модуль призначений для підготовки вихідної інформації щодо проекту та розміщений на підприємстві, що бере участь у конкурсі. Основна система здійснює аналіз проектів та розміщена в адміністративному органі управління. Структура основної системи спрямовано реалізацію особливостей аналізу інвестиційних проектів. У роботі також пропонуються основні засади та методика оцінки інвестиційних проектів. Для оцінки проекту безліч вихідних показників розбито на групи, що характеризують окремі сторони фінансового стануорганізації. Включено також додаткові показники, важливі для соціального, культурного та іншого розвитку території. У зв'язку з цим представлена методика дозволяє в процесі прийняття рішення про виділення кредитів здійснити ранжування інвестиційних проектів не тільки фінансовим показникам, але й врахувати пріоритети адміністративної організаційної структури, не пов'язані безпосередньо з фінансовим станом організації, що бере участь у конкурсі.
інформаційна система
структура
методика
інвестиційний проект
адміністративна структура
1. Брикін І.М., Беклемішев А.В. Оцінка, вибір та аналіз інвестиційних проектів. - М.: ТОВ «Міжнародна Медіа Група», 2011. - 47 с.
2. Бейлі Д.В., Шарп У.Ф., Александер Г.Д. Інвестиції. - М.: ІНФРА-М, 2012. - 1028 с.
3. Віленський П.Л., Лівшиць В.М., Смоляк С.А. Оцінка ефективності інвестиційних проектів. Теорія та практика: Навч. Допомога. - М.: Справа, 2008. - 888 с.
4. Кравченко Т.К., Пресняков В.Ф. Інфокомунікаційні технології управління підприємством - М.: ГУ ВШЕ, 2003. - 272 с.
5. Ліпсіц І.В., Коссов В.В. Інвестиційний аналіз. Підготовка та оцінка інвестицій у реальні активи. - М.: ІНФРА-М, 2014. - 320 с.
6. Свєтлов Н.М., Свєтлова Г.М. Інформаційні технологіїуправління проектами - М.: ІНФРА-М, 2012. - 144 с.
7. Шуремов Є. Комп'ютерний аналіз бізнесу. // Світ ПК. - 1998. - № 1. - С. 80-83.
Ефективність прийняття управлінських рішеньз надання інвестицій у галузі малого підприємництва умовах ринку багато в чому залежить від використовуваних інструментів аналізу фінансово-господарську діяльність підприємств. Особливо важливим є вибір інструментів аналізу для адміністративних організаційних структур, коли на рішення про кредитування проекту мають впливати не лише фінансові показники підприємства, а й пріоритети адміністративної освіти, що перебуває під управлінням цієї організаційної структури.
Проблеми, розгляду яких присвячено статтю, пов'язані з розвитком систем аналізу діяльності підприємства зовнішніми організаціямита органами управління та контролю. Метою систем є не лише оцінка фінансово-господарського стану підприємства, а й можливостей та перспектив взаємодії чи спільної роботи з ним. Інформаційну базу аналізу складають показники, тим чи іншим способом одержувані із стандартної бухгалтерської, статистичної звітностіта відкритих джерел.
Серед існуючих фінансово-аналітичних систем можна виділити розробки таких фірм, як «Експерт Системс», «Галактика», «ІНЕК», «Альт-Інвест», проте їх ефективне використання без доопрацювань адміністративними організаційними структурами є проблематичним, оскільки зазначені системи не вирішують завдань оцінки проекту у взаємозв'язку з параметрами, пріоритетними для адміністративної структури, але з фінансового характеру.
Структура інформаційної системи
Необхідність та актуальність якісного аналізу потоку інвестиційних проектів та наявні відмінності інтересів звичайного інвестора та інвестора у вигляді адміністративної організаційної структури переводять проблему вибору інструменту у площину його розробки. При цьому на систему доцільно покласти рішення наступних завдань :
Аналіз фінансового становища підприємства, зокрема у поступовій динаміці;
Аналіз фінансової частини бізнес-плану проекту;
Аналіз впливу кредиту на фінансове становище підприємства;
Врахування пріоритетів міста в процесі аналізу проекту;
Порівняльний аналіз проектів кількох підприємств;
Прогноз розвитку підприємства та повернення кредитів.
Виходячи з особливостей та характеру поставлених завдань, розроблено структурну схему системи аналізу, представлену на малюнку.
Зовнішній модуль системи є автономною програмою, яка призначена для підготовки необхідної для прийняття рішення про виділення кредиту на фінансування запропонованого проекту вихідної інформації:
Бухгалтерського балансу та додаткових документів щодо балансу;
фінансової частини бізнес-плану проекту;
Додаткову інформацію, потрібну для обліку пріоритетів адміністративного органу управління.
У модулі передбачається реалізувати як безпосереднє введення інформації за допомогою клавіатури, так і роботу в режимі імпорту даних з інших систем. Одночасно зовнішній модуль здійснює контроль правильності введення інформації щодо виключення ненавмисних помилок.
Структура основної частини системи спрямовано реалізацію особливостей аналізу інвестиційних проектів.
Ключову роль відіграє «Модуль налаштування робочого середовища та експертної системи». У цьому модулі проводиться формування різних сценаріїваналізу, визначення додаткових правилта критеріїв, що відображають інтереси міста та адміністрації, встановлення критичних значень фінансових коефіцієнтів.
"Модуль розрахунку фінансових показників" здійснює розрахунок фінансових коефіцієнтів.
Структурна схема інформаційної системи аналізу інвестиційних проектів
«Модуль аналізу проекту та візуалізації результатів» здійснює подання результатів аналізу аналітичними, графічними та табличними способами.
«Модуль генерації звітів» пов'язаний із стандартними програмними засобамита призначений для підготовки звітних матеріалів.
Експертна система покликана надавати допомогу під час аналізу отриманих результатів.
Методика аналізу інвестиційних проектів
Методика аналізу інвестиційних проектів полягає у комплексному аналізі фінансового стану підприємства спільно з оцінкою самого інвестиційного проекту та визначенням рейтингу проекту для подальшого ухвалення рішення про виділення кредитів.
Існує безліч вихідних показників, які розбиті на групи, що характеризують окремі сторони фінансового становища організації. Ці групи показників зосереджені окремих документах, наприклад бухгалтерському звіті та інших.
Таким чином, є L-груп вихідних показників , де L-груп відносних показників , де , l - номер групи, а kl - порядковий номер показника в групі.
За підсумками первинних показників формуються Q-груп вторинних показників , де q = 1, Q, , а mq - порядковий номер показника в q-ой групі. Ці показники назвемо коефіцієнтами.
На базі показників та формуються показники динаміки їх зміни в абсолютних та відносних одиницях виду
де j – характеризує номер вимірювань показника чи коефіцієнта.
Кожен показник та коефіцієнт фіксуються у ряді часових точок. Отримані значення дозволяють виявити динаміку зміни показників та коефіцієнтів у часі:
Тоді I = J+1.
Для коефіцієнтів встановлені умови. Відповідність коефіцієнтів умов показує, що стан узагальнених характеристик фінансового стану підприємства, що визначається цим коефіцієнтом, нормальний.
У процесі аналізу підприємницького проекту вирішуються принаймні три важливі завдання:
а) оцінка можливості повернення кредиту аналізованим підприємством і, отже, рішення про його включення до списку потенційно придатних для кредитування;
б) оцінка можливості кредитування виходячи з пріоритетів адміністрації;
Ці завдання вирішуються в рамках багаторівневого аналізу коефіцієнтів та показників.
Аналіз здійснюється з розрахунку коефіцієнтів та оцінки умов. Коефіцієнти розбиті всередині груп на підгрупи більш-менш важливих. Перший рівень аналізу пов'язані з оцінкою виконання умов виділених підгруп коефіцієнтів і вирішує переважно завдання
а) На другому та наступних рівнях аналізуються інші коефіцієнти та показники, а також динаміка їх зміни.
Результати аналізу оформляються як окремих документів, у яких дається характеристика різних сторін діяльності підприємства міста і запропонованого проекту.
На наступному етапі формується оцінка проекту за пунктом
б) Для врахування інтересів адміністрації вводиться додаткова група показників (fh) та умов (?h), де h = 1,H. Ці показники можуть бути розраховані чи представлені підприємством. Якщо підприємство відповідає критеріям, воно виключається із групи потенційно кредитуемых.
а) формуються варіанти визначення рейтингу інвестиційних проектів, орієнтовані на оцінку в рамках будь-якої спрямованості, наприклад, у галузі виробництва харчових продуктівта ін Основні відмінності варіантів, або назвемо їх сценаріями, полягають у тому, що:
У групах відносних показників та коефіцієнтів виділяються окремі елементи, які враховуватимуться щодо рейтингу проекту у цьому сценарії, тобто.
де ζ – номер сценарію;
Для виділених показників і коефіцієнтів встановлюються ваги, що характеризують вплив цього показника рейтинг у цій групі, тобто. відповідно
Також ваги визначаються які у рейтингу груп показників і коефіцієнтів, тобто. де d ζ - номер групи, а D ζ - загальна кількість груп, що беруть участь в оцінці;
Ваги менше 1, суми ваги кожного набору по всій вибірці дорівнюють 1.
б) формується версія кращого підприємства для групи проектів, що оцінюються. Версія кращого підприємства є набір раніше виділених показників із найкращими по всьому набору значеннями, тобто. Значення цих показників можуть належати різним підприємствам. Ця версія не пов'язана з реальним об'єктом і використовується для оцінки рейтингу. Усі подальші співвідношення для оцінки рейтингу наведено лише коефіцієнтів . Аналогічні формули будуються для параметрів і fh.
Таким чином, формується сукупність показників , де , якщо що вище , то краще, й інакше. Тут s – номер підприємства за списком, а – значення коефіцієнта для s-го підприємства.
де , якщо зростання коефіцієнта характеризує покращення фінансового стану підприємства та
д) що вищий R ζ s, то вище рейтинг s-го підприємства у ζ -му сценарії оцінки.
Нормуванням (R ζ s) по , можна розставити підприємства у порядку зростання або зменшення їх рейтингу. Рейтинг за показниками і fh можна проводити окремо.
Висновок
Подана методика дозволяє у процесі прийняття рішення про виділення кредитів здійснити ранжування інвестиційних проектів не лише за фінансовими показниками, а й врахувати пріоритети адміністративної організаційної структури, які не пов'язані безпосередньо з фінансовим станом організації, що бере участь у конкурсі.
Таким чином, інформаційна система при її реалізації буде потужним інструментом, що має у своєму складі ефективні механізми підтримки прийняття рішень у галузі інвестиційної діяльності та спрямованим на забезпечення аналізу як фінансового стану підприємств, так і інвестиційних проектів, що подаються на конкурс.
Бібліографічне посилання
Кльовцов С.І., Кльовцова А.Б. МОДЕЛЬ ІНФОРМАЦІЙНОЇ СИСТЕМИ АНАЛІЗУ ІНВЕСТИЦІЙНИХ ПРОЕКТІВ ДЛЯ АДМІНІСТРАТИВНИХ СТРУКТУР // Фундаментальні дослідження. - 2016. - № 12-1. - С. 58-61;URL: http://fundamental-research.ru/ru/article/view?id=41046 (дата звернення: 26.04.2019). Пропонуємо до вашої уваги журнали, що видаються у видавництві «Академія Природознавства»
Проектування інформаційних систем
Частина 1. Етапи розробки проекту: стратегія та аналіз
Вступ "Водоспад" - схема розробки проекту Стратегія Аналіз ER-діаграми Дуги Нормалізація Діаграми потоків даних Деякі принципи перевірки якості та повноти інформаційної моделі Якість сутностей Якість атрибутів Якість зв'язку Функції системи Уточнення стратегії
Вступ
Проектування інформаційних систем завжди починається з визначення мети проекту. Основне завдання будь-якого успішного проекту полягає в тому, щоб на момент запуску системи та протягом усього часу її експлуатації можна було забезпечити:
необхідну функціональність системи і ступінь адаптації до умов її функціонування, що змінюються;
необхідну пропускну спроможність системи;
необхідний час реакції системи на запит;
безвідмовну роботу системи у необхідному режимі, іншими словами - готовність та доступність системи для обробки запитів користувачів;
простоту експлуатації та підтримки системи;
необхідну безпеку.
Продуктивність є основним чинником, визначальним ефективність системи. Хороше проектне рішення є основою високопродуктивної системи.
Проектування інформаційних систем охоплює три основні сфери:
проектування об'єктів даних, які будуть реалізовані у базі даних;
проектування програм, екранних форм, звітів, які забезпечуватимуть виконання запитів до даних;
облік конкретного середовища чи технології, а саме: топології мережі, конфігурації апаратних засобів, використовуваної архітектури (файл-сервер або клієнт-сервер), паралельної обробки, розподіленої обробки даних тощо.
У реальних умовах проектування - це пошук способу, який відповідає вимогам функціональності системи засобами наявних технологій з урахуванням заданих обмежень.
До будь-якого проекту пред'являється ряд абсолютних вимог, наприклад, максимальний час розробки проекту, максимальні грошові вкладення в проект і т.д. Одна із складнощів проектування полягає в тому, що воно не є таким структурованим завданням, як аналіз вимог до проекту або реалізація того чи іншого проектного рішення.
Вважається, що складну систему неможливо описати у принципі. Це зокрема стосується систем управління підприємством. Одним з основних аргументів є зміна умов функціонування системи, наприклад, директивна зміна тих чи інших потоків інформації новим керівництвом. Ще один аргумент – обсяги технічного завдання, які для великого проекту можуть становити сотні сторінок, тоді як технічний проект може містити помилки. Виникає питання: а може, краще взагалі не проводити обстеження і не робити жодного технічного проекту, а писати систему "з чистого аркуша" в надії на те, що станеться якийсь чудовий збіг бажання замовника з тим, що написали програмісти, а також на те, що все це стабільно працюватиме?
Якщо розібратися, то чи так непередбачувано розвиток системи і чи дійсно отримати інформацію про неї неможливо? Ймовірно, уявлення про систему в цілому та про передбачувані (керівництво) шляхи її розвитку можна отримати за допомогою семінарів. Після цього розбити складну систему на простіші компоненти, спростити зв'язки між компонентами, передбачити незалежність компонентів та описати інтерфейси між ними (щоб зміна одного компонента автоматично не тягла за собою суттєвої зміни іншого компонента), а також можливості розширення системи та "заглушки" для нереалізованих у тій чи іншій версії системи функцій. З таких елементарних міркувань опис те, що передбачається реалізувати інформаційної системі, не здається настільки нереальним. Можна дотримуватись класичних підходів до розробки інформаційних систем, один з яких - схема "водоспаду" ( Мал. 1) - Описаний нижче. Коротко будуть розглянуті й деякі інші підходи до розробки інформаційних систем, де використання елементів, описаних у схемі водоспаду, також припустимо. Якого підходу з описаних нижче дотримуватися (і чи є сенс вигадувати власний підхід) - певною мірою справа смаку та обставин.
Мал. 1. Cхема «водоспаду»
Життєвий цикл програмного забезпечення є модель його створення та використання. Модель відображає його різні стани, починаючи з моменту виникнення необхідності в даному ПЗ і закінчуючи моментом його повного виходу з використання у всіх користувачів. Відомі такі моделі життєвого циклу:
Каскадні моделі. Перехід на наступний етап означає повне завершення робіт на попередньому етапі.
Поетапна модель із проміжним контролем. Розробка програмного забезпечення ведеться ітераціями з циклами зворотнього зв'язкуміж етапами Міжетапні коригування дозволяють зменшити трудомісткість процесу розробки, порівняно з каскадною моделлю; Час життя кожного з етапів розтягується протягом усього періоду розробки.
Спіральна модель. Особливу увагуприділяється початковим етапам розробки - виробленню стратегії, аналізу та проектування, де реалізованість тих чи інших технічних рішень перевіряється та обґрунтовується за допомогою створення прототипів (макетування). Кожен виток спіралі передбачає створення певної версії продукту чи якогось його компонента, у своїй уточнюються характеристики й цілі проекту, визначається його якість і плануються роботи наступного витка спіралі.
Нижче розглянемо деякі схеми розробки проекту.
На початок
"Водоспад" - схема розробки проекту
Дуже часто проектування описують як окремий етап розробки проекту між аналізом та розробкою. Однак насправді чіткого поділу етапів розробки проекту немає - проектування, як правило, не має явно вираженого початку та закінчення і часто продовжується на етапах тестування та реалізації. Говорячи про етапі тестування, також слід зазначити, що і етап аналізу, і етап проектування містять елементи роботи тестерів, наприклад для отримання експериментального обґрунтування вибору того чи іншого рішення, а також для оцінки критеріїв якості системи, що отримується. На етапі експлуатації доречна розмова і про супровід системи.
Нижче ми розглянемо кожен із етапів, детальніше зупинившись на етапі проектування.
На початок
Стратегія
Визначення стратегії передбачає обстеження системи. Основне завдання обстеження – оцінка реального обсягу проекту, його цілей та завдань, а також отримання визначень сутностей та функцій на високому рівні.
На цьому етапі залучаються висококваліфіковані бізнес-аналітики, які мають постійний доступ до керівництва фірми; етап передбачає тісну взаємодію з основними користувачами системи та бізнес-експертами. Основне завдання взаємодії - отримати якомога повнішу інформацію про систему (повне і однозначне розуміння вимог замовника) і передати цю інформацію у формалізованому вигляді системним аналітикам для подальшого проведення етапу аналізу. Як правило, інформація про систему може бути отримана в результаті розмов або семінарів з керівництвом, експертами та користувачами. Таким чином визначаються суть даного бізнесу, перспективи його розвитку та вимоги до системи.
По завершенні основної стадії обстеження системи технічні фахівці формують ймовірні технічні підходи і приблизно розраховують витрати на апаратне забезпечення, програмне забезпечення, що закуповується, і розробку нового програмного забезпечення (що, власне, і передбачається проектом).
Результатом етапу визначення стратегії є документ, де чітко сформульовано, що отримає замовник, якщо згодиться фінансувати проект; коли він отримає готовий товар (графік виконання робіт); скільки це буде коштувати (для великих проектів має бути складений графік фінансування на різних етапах робіт). У документі мають бути відображені не лише витрати, а й вигода, наприклад, час окупності проекту, очікуваний економічний ефект (якщо його вдається оцінити).
У документі обов'язково мають бути описані:
обмеження, ризики, критичні фактори, що впливають на успішність проекту, наприклад, час реакції системи на запит є заданим обмеженням, а не бажаним фактором;
сукупність умов, за яких передбачається експлуатувати майбутню систему: архітектура системи, апаратні та програмні ресурси, що надаються системі, зовнішні умови її функціонування, склад людей та робіт, які забезпечують безперебійне функціонування системи;
терміни завершення окремих етапів, форма здачі робіт, ресурси, що залучаються у процесі розробки проекту, заходи щодо захисту інформації;
опис виконуваних системою функцій;
майбутні вимоги до системи у разі її розвитку, наприклад, можливість роботи користувача з системою за допомогою Інтернету тощо;
сутності, необхідних виконання функцій системи;
інтерфейси та розподіл функцій між людиною та системою;
вимоги до програмних та інформаційних компонентів ПЗ, вимоги до СУБД (якщо проект передбачається реалізовувати для кількох СУБД, то вимоги до кожної з них, або Загальні вимогидо абстрактної СУБД та список рекомендованих для даного проектуСУБД, які задовольняють заданим умовам);
що не буде реалізовано у рамках проекту.
Виконана на даному етапіробота дозволяє відповісти на запитання, чи варто продовжувати цей проект і які вимоги замовника можуть бути задоволені за тих чи інших умов. Може виявитися, що проект продовжувати не має сенсу, наприклад, через те, що ті чи інші вимоги не можуть бути задоволені з якихось об'єктивних причин. Якщо приймається рішення про продовження проекту, то для проведення наступного етапу аналізу вже є уявлення про обсяг проекту та кошторис витрат.
Слід зазначити, що і етапі вибору стратегії, і етапі аналізу, і за проектуванні незалежно від методу, застосовуваного розробки проекту, завжди слід класифікувати плановані функції системи за рівнем важливості. Один з можливих форматів представлення такої класифікації - MoSCoW - запропонований Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.
Ця абревіатура розшифровується так: Must have - необхідні функції; Should have – бажані функції; Could have – можливі функції; Won't have - відсутні функції.
Реалізація функцій другої та третьої категорій обмежується тимчасовими та фінансовими рамками: розробляємо те, що необхідно, а також максимально можливе в порядку пріоритету кількість функцій другої та третьої категорій.
На початок
Аналіз
Етап аналізу передбачає докладне дослідження бізнес-процесів (функцій, визначених на етапі вибору стратегії) та інформації, необхідної для їх виконання (сутностей, їх атрибутів та зв'язків (стосунків)). У цьому етапі створюється інформаційна модель, але в наступному його етапі проектування - модель даних.
Вся інформація про систему, зібрана на етапі визначення стратегії, формалізується та уточнюється на етапі аналізу. Особливу увагу слід приділити повноті переданої інформації, аналізу інформації на предмет відсутності протиріч, а також пошуку інформації, що не використовується взагалі або дублюється. Як правило, замовник не відразу формує вимоги до системи загалом, а формулює вимоги до окремих її компонентів. Зверніть увагу на узгодженість цих компонентів.
Аналітики збирають та фіксують інформацію у двох взаємопов'язаних формах:
функції - інформація про події та процеси, що відбуваються у бізнесі;
сутності - інформація про речі, що мають значення для організації та про які щось відомо.
Двома класичними результатами аналізу є:
ієрархія функцій, яка розбиває процес обробки на складові (що робиться і з чого це складається);
модель "сутність-зв'язок" (Entry Relationship model, ER-модель), яка описує сутності, їх атрибути та зв'язки (відносини) між ними.
Ці результати є потрібними, але не достатніми. До достатніх результатів слід віднести діаграми потоків даних та діаграми життєвих циклівсутностей. Часто помилки аналізу виникають при спробі показати життєвий цикл сутності на діаграмі ER.
Нижче ми розглянемо три найбільш застосовувані методології структурного аналізу:
діаграми "сутність-зв'язок" (Entity-Relationship Diagrams, ERD), які служать для формалізації інформації про сутності та їх відносини;
діаграми потоків даних (Data Flow Diagrams, DFD), що служать для формалізації представлення функцій системи;
діаграми переходів станів (State Transition Diagrams, STD), які відображають поведінку системи, що залежить від часу; Діаграми життєвих циклів сутностей відносяться саме до цього класу діаграм.
На початок
ER-діаграми
ER-діаграми ( Мал. 2) використовуються для розробки даних і є стандартним способом визначення даних і відносин між ними. Таким чином, здійснюється деталізація сховищ даних. ER-діаграма містить інформацію про сутності системи та способи їх взаємодії, включає ідентифікацію об'єктів, важливих для предметної області (сутностей), властивостей цих об'єктів (атрибутів) та їх відносин з іншими об'єктами (зв'язків). У багатьох випадках інформаційна модель дуже складна та містить безліч об'єктів.
Мал. 2. Приклад ER-діаграми
Сутність зображується у вигляді прямокутника, вгорі якого знаходиться ім'я сутності (наприклад, TITLES). У прямокутнику може бути перераховані атрибути сутності; атрибути ER-діаграм, набрані жирним шрифтом, є ключовими (так Title Identity - ключовий атрибут сутності TITLES, інші атрибути ключовими не є).
Ставлення зображується лінією між двома сутностями (сині лінії малюнку).
Поодинока лінія справа ( Мал. 3) означає "один", "пташина лапка", зліва - "багато", а відношення читається вздовж лінії, наприклад "один до багатьох". Вертикальна риса означає "обов'язково", гурток - "не обов'язково", наприклад, для кожного видання в TITLE обов'язково має бути зазначений видавець у PUBLISHERS, а один видавець у PUBLISHERS може випускати кілька найменувань видань у TITLES. Слід зазначити, що зв'язки завжди коментуються (напис на лінії, що зображує зв'язок).
Мал. 3. Елемент ER-діаграми
Наведемо також приклад ( Мал. 4) зображення рефлексивного відношення "співробітника", де один співробітник може керувати кількома підлеглими і так далі вниз по ієрархії посад.
Мал. 4. ER-діаграма рефлексивного відношення
Слід звернути увагу, що таке ставлення завжди є необов'язковим, інакше це буде нескінченна ієрархія.
Атрибути сутностей можуть бути ключовими – вони виділяються напівжирним шрифтом; обов'язковими - перед ними ставиться знак "*", тобто їхнє значення завжди відоме, необов'язковими (optional) - перед ними ставиться О, тобто значення цього атрибуту в якісь моменти можуть бути відсутніми або невизначеними.
На початок
Дуги
Якщо сутність має набір взаємовиключних відносин з іншими сутностями, то кажуть, такі стосунки перебувають у дузі. Наприклад, банківський рахунок може бути оформлений або для юридичної особи, або для фізичної особи. Фрагмент ER-діаграми для такого типу відносин наведено на Мал. 5.
Мал. 5. Дуга
У цьому випадку атрибут ВЛАСНИК сутності РАХУНОК має особливе значення для даної сутності - сутність ділиться на типи за категоріями: "для фізичної особи" та "для юридичного лицяОтримані в результаті сутності називають підтипами, а вихідна сутність стає супертипом. Щоб зрозуміти, чи потрібен супертип чи ні, треба встановити, скільки однакових властивостей мають різні підтипи. Слід зазначити, що зловживання підтипами і супертипами є досить поширеною помилкою. як показано на Мал. 6.
Мал. 6. Підтипи (праворуч) та супертип (ліворуч)
На початок
Нормалізація
Щоб запобігти аномалій під час обробки даних, використовують нормалізацію. Принципи нормалізації для об'єктів інформаційної моделі такі самі, як і моделей даних.
Допустимі типи зв'язків. При найближчому розгляді зв'язку типу "один до одного" ( Мал. 7) майже завжди виявляється, що A і B є насправді різні підмножини одного і того ж предмета або різні точки зору на нього, що просто мають відмінні імена і по-різному описані зв'язки і атрибути.
Мал. 7. Зв'язки «один до одного»
Зв'язки "багато до одного" представлені на Мал. 8.
Мал. 8. Зв'язки «багато до одного»
I - досить сильна конструкція, що передбачає, що входження сутності B не може бути створене без одночасного створення щонайменше одного пов'язаного з ним входження сутності A.
II - це найбільш часто зустрічається форма зв'язку. Вона передбачає, що кожне та будь-яке входження сутності A може існувати тільки в контексті одного (і тільки одного) входження сутності B. У свою чергу, входження B можуть існувати як у зв'язку з входженнями A, так і без неї.
III – застосовується рідко. Як A, і B можуть існувати без зв'язку з-поміж них.
Зв'язки "багато до багатьох" представлені на Мал. 9.
Мал. 9. Зв'язки «багато хто до багатьох»
I - така конструкція часто має місце на початку етапу аналізу і означає зв'язок - або зрозумілу не до кінця і вимагає додаткового дозволу, або відбиває просте колективне відношення - двонаправлений список.
II – застосовується рідко. Такі зв'язки завжди підлягають подальшій деталізації.
Розглянемо тепер рекурсивні зв'язки ( Мал. 10).
Мал. 10. Рекурсивні зв'язки
I – рідко, але має місце. Відображає зв'язки альтернативного типу.
II - досить часто застосовується для опису ієрархій із будь-яким числом рівнів.
III – має місце на ранніх етапах. Часто відображає структуру "переліку матеріалів" (взаємна вкладеність компонентів). Приклад: кожен КОМПОНЕНТ може складатися з одного і більше КОМПОНЕНТІВ і кожен КОМПОНЕНТ може використовуватися в одному і більше КОМПОНЕНТІВ.
Неприпустимі типи зв'язків. До неприпустимих типів зв'язків належать такі: обов'язковий зв'язок "багато хто до багатьох" ( Мал. 11) та ряд рекурсивних зв'язків ( Мал. 12).
Мал. 11. Неприпустимі зв'язки «багато хто до багатьох»
Мал. 12. Неприпустимі рекурсивні зв'язки
Обов'язковий зв'язок "багато хто до багатьох" у принципі неможливий. Такий зв'язок означав би, що жодна з входжень A може існувати без B, і навпаки. Насправді кожна подібна конструкція завжди виявляється помилковою.
На початок
Діаграми потоків даних
Логічна DFD ( Мал. 13) показує зовнішні стосовно системи джерела та стоки (адресати) даних, ідентифікує логічні функції (процеси) та групи елементів даних, що пов'язують одну функцію з іншої (потоки), а також ідентифікує сховища (накопичувачі) даних, до яких здійснюється доступ. Структури потоків даних та визначення їх компонентів зберігаються та аналізуються у словнику даних. Кожна логічна функція (процес) може бути деталізована за допомогою нижнього рівня DFD; коли подальша деталізація перестає бути корисною, переходять до вираження логіки функції за допомогою специфікації процесу (міні-специфікації). Вміст кожного сховища зберігають у словнику даних, модель даних сховища розкривається за допомогою ER-діаграм.
Мал. 13. Приклад DFD
Зокрема, у DFD не показуються процеси, які управляють власне потоком даних і не наводяться відмінності між допустимими та неприпустимими шляхами. DFD містять безліч корисної інформації, а також:
дозволяють уявити систему з погляду даних;
ілюструють зовнішні механізми подачі даних, які вимагатимуть наявності спеціальних інтерфейсів;
дозволяють уявити як автоматизовані, і ручні процеси системи;
виконують орієнтоване дані секціонування всієї системи.
Потоки даних використовуються для моделювання передачі (або навіть фізичних компонентів) з однієї частини системи в іншу. Потоки на діаграмах зображуються іменованими стрілками, стрілки вказують напрямок руху інформації. Іноді інформація може рухатися в одному напрямку, оброблятися та повертатися до її джерела. Така ситуація може моделюватись або двома різними потоками, або одним двонаправленим.
Процес перетворює вхідний потік даних у вихідний відповідно до дії, що задається ім'ям процесу. Кожен процес повинен мати унікальний номер для посилань на нього у діаграмі. Цей номер може використовуватися разом із номером діаграми для отримання унікального індексу процесу у всій моделі.
Сховище даних (data storage) дозволяє ряді ділянок визначати дані, які зберігатимуться у пам'яті між процесами. Фактично сховище представляє "зрізи" потоків даних у часі. Інформацію, яку вона містить, можна використовувати у будь-який час після її визначення, при цьому дані можуть вибиратися у довільному порядку. Ім'я сховища має ідентифікувати його вміст. У разі коли потік даних входить (виходить) у (з) сховище і його структура відповідає структурі сховища, він повинен мати те саме ім'я, яке немає необхідності відображати на діаграмі.
Зовнішня сутність (термінатор) є сутністю поза контекстом системи, що є джерелом або приймачем системних даних. Її ім'я має містити іменник, наприклад "Клієнт". Передбачається, що об'єкти, представлені такими вузлами, не повинні брати участь у жодній обробці.
На початок
Діаграми зміни станів STD
Життєвий цикл сутності відноситься до класу STD-діаграм ( Мал. 14). Ця діаграма відображає зміну стану об'єкта з часом. Наприклад, розглянемо стан товару складі: товар може бути замовлений у постачальника, вступити складу, зберігатися складі, проходити контроль якості, може бути проданий, забракований, повернуто постачальнику. Стрілки на діаграмі показують допустимі зміни стану.
Рис.14. Приклад DFD
Існує кілька різних варіантів зображення подібних діаграм, на малюнку наведено лише один із них.
На початок
Деякі принципи перевірки якості та повноти інформаційної моделі (джерело - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)
Якщо ви хочете створити якісну модель, то доведеться вдаватися до допомоги аналітиків, які добре володіють CASE-технологією. Однак це не означає, що побудовою та контролем інформаційної моделі мають займатися лише аналітики. Допомога колег також може бути дуже корисною. Залучайте їх до перевірки поставленої мети та детального вивчення побудованої моделі як з погляду логіки, так і з погляду обліку аспектів предметної області. Більшість людей легше знаходять недоліки у чужій роботі.
Регулярно подайте вашу інформаційну модель або її окремі фрагменти, щодо яких у вас виникають сумніви, на схвалення користувачів. Особливу увагу приділяйте виняткам із правил та обмежень.
На початок
Якість сутностей
Основною гарантією якості сутності є у відповідь питання, чи справді об'єкт є сутністю, тобто важливим об'єктом чи явищем, інформація про яку має зберігатися у базі даних.
Список перевірочних питань для сутності:
Чи відбиває ім'я сутності суть даного об'єкта?
Чи немає перетину з іншими сутностями?
Чи є хоча б два атрибути?
Усього атрибутів не більше восьми?
Чи є синоніми/омоніми цієї сутності?
Сутність визначена повністю?
Чи є унікальний ідентифікатор?
Чи є хоча б один зв'язок?
Чи існує хоча б одна функція зі створення, пошуку, коригування, видалення, архівування та використання значення сутності?
Чи ведеться історія змін?
Чи має місце відповідність принципам нормалізації даних?
Чи немає такої ж сутності в іншій прикладній системі, можливо, під іншим ім'ям?
Чи не має суть надто загальний зміст?
Чи достатній рівень узагальнення, втілений у ній?
Список перевірочних питань для підтипу:
Чи немає перетину з іншими підтипами?
Чи має підтип якісь атрибути та/або зв'язки?
Чи мають усі свої власні унікальні ідентифікатори чи успадковують один на всіх від супертипу?
Чи є вичерпний набір підтипів?
Чи є підтип прикладом входження сутності?
Чи знаєте ви якісь атрибути, зв'язки та умови, що відрізняють цей підтип від інших?
На початок
Якість атрибутів
Слід з'ясувати, а чи справді це атрибути, тобто чи описують вони тим чи іншим чином цю сутність.
Список перевірочних питань для атрибуту:
Чи є найменування атрибуту іменником однини, що відображає суть позначається атрибутом властивості?
Чи не включає найменування атрибута ім'я сутності (цього бути не повинно)?
Чи має атрибут лише одне значення у кожний момент часу?
Чи відсутні значення, що повторюються (або групи)?
Чи описані формат, довжина, допустимі значення, алгоритм отримання тощо?
Чи не може цей атрибут бути пропущеною сутністю, яка стала б у нагоді для іншої прикладної системи (вже існуючої або передбачуваної)?
Чи не може він бути пропущеним зв'язком?
Чи є необхідність в історії змін?
Чи залежить його значення лише від цієї сутності?
Якщо значення атрибута є обов'язковим, завжди воно відомо?
Чи є необхідність створення домену для цього і йому подібних атрибутів?
Чи залежить його значення лише від якоїсь частини унікального ідентифікатора?
Чи залежить його значення від значень деяких атрибутів, не включених до унікального ідентифікатора?
