Структуризація проекту інформаційної системи. Фундаментальні дослідження

14.08.2023

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

інформаційна система

структура

методика

інвестиційний проект

адміністративна структура

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). Пропонуємо до вашої уваги журнали, що видаються у видавництві «Академія Природознавства»

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

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

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

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

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

Різними дослідниками пропонувалися різні методи класифікації інформаційного забезпечення. Так з погляду взаємодії підприємства організації з навколишнім середовищем всю інформацію переважно документальну прийнято ділити на вхідну і вихідну. Залежно від термінів зберігання розрізняють постійну, умовно-постійну оновлювану і змінну, що регулярно змінюється. Поділяють інформацію та за рівнями управління заводська, внутрішньозаводська, цехова, внутрішньоцехова. За характером діяльності конструкторсько-технологічна. бухгалтерська, обліково-звітна, планова, маркетингова, кадрова, виробнича. У автоматизованих системах інформаційне забезпечення ділять на машинне у пам'яті ЕОМ та позамашинне. Ці класифікації у різних поєднаннях використовуються при індексуванні різних документів листів, наказів, інструкцій та інших документів, що використовуються підприємствами та організаціями у своїй практичній діяльності. Історія розвитку. В історії створення автоматизованих інформаційних систем щодо незалежно розвивалися два напрямки: 1. розробка автоматизованих інформаційних систем АІС як автоматизованих систем управління АСУ; 2. розробка автоматизованих систем науково-технічної інформації АСНТІ. Роботи щодо їх створення почалися практично одночасно у 60-ті рр. ХХ ст.

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

Аналогічно лише на рівні підприємств, і особливо створюваних у роки. науково-виробничих об'єднань НУО, у структурі АСУП чи інтегрованих АСУ об'єднань виділялися рівні страти – АСУ об'єднання, АСУ підприємств та організацій науково-дослідних інститутів, конструкторських бюро, що входять до НУО, АСУ виробництв, комплексів цехів, АСУ цехів та ділянок. На рівні цехів та ділянок АСУ спочатку поділялися на АСУ технологічними процесами, АСУ технічної та технологічної підготовки виробництва, АСУ організацією виробництва. Роботи зі створення централізованих загальнодержавних АСУ та АСНТІ були припинені у зв'язку із перетвореннями 19-91 рр. Однак, при переході до ринкової економіки, до правової держави зростає роль ще одного важливого виду інформації - нормативно-правової та нормативно-методичної, що регламентує діяльність підприємств при наданні їм більшої самостійності та скорочення організаційно-розпорядчої документації поточних наказів та розпоряджень, що ревізують командно-адміністративні. методи керування. Надалі, у міру розвитку підприємств та їх АСУ, особливо в умовах надання більшої самостійності виробництвам та цехам та перерозподілу управлінських функцій між адміністрацією підприємства та керівниками виробництв та цехів, також стало більш зручним представляти структуру АСУ у вигляді багаторівневої, стратифікованої. Поділ АСУ на функціональну та забезпечує частини, а останньої – на інформаційне забезпечення, технічне, організаційне, програмне та інші види забезпечення – дозволив залучити для уточнення відповідних видів забезпечення фахівців у цих галузях. Такий підхід до організації розробок АСУ допоміг упоратися зі складністю системи та прискорити розробку АСУ шляхом паралельного проведення робіт з аналізу та вибору структури окремих видів забезпечення. Однак, якщо розробляти окремі проекти, то після розробки виникає досить складне завдання їх узгодження, взаємопов'язання прийнятих структур цих видів забезпечення, критеріїв, що враховуються при їх розробці. Тому на певному етапі розвитку робіт зі створення АСУ було навіть сформульовано спеціальний принцип єдності інформаційного забезпечення, технічного та програмного, як основних видів забезпечення. В даний час існує безліч готових програмних продуктів. Тому немає необхідності при створенні на підприємстві автоматизованої системи займатися самостійною розробкою програмного забезпечення. Оцінка ефективності інформаційних ресурсів. При різноманітті видів та форм інформаційних ресурсів проблема їх оцінки видається практично нерозв'язною.

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

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

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

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

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

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

Програмний код усередині (але цього ніхто не бачить)

До чого тут лікарня, якщо ми розробляємо програмне забезпечення?

А ось і ні, дорогі розробники, керівники, аналітики, випробувачі.

Чи не програмне забезпечення ви розробляєте ... Візьмемо Android, - це ПЗ. А якщо, наприклад, перед вами бухгалтерська система, то ви вже маєте справу не просто з ПЗ, а з ІНФОРМАЦІЙНОЮ СИСТЕМОЮ.

Відмінність очевидна. Якщо ви купили телефон-все просто: вмикаєте його, запускається зелений чоловічок (Android), користуєтеся. А якщо ви придбали коробку з бухгалтерським ПЗ, то ясно, що тепер необхідні сервери, треба налаштувати мережу, налаштувати робочі станції, навчити співробітників, інтегрувати систему з іншими ІВ підприємства, поганяти систему в тестовому режимі. Та й бухгалтерів треба ще якось умовити перейти на новий софт, далеко не всі готові до новацій. Загалом, у будь-якому IT-проекті 10-20% це IT, а все інше - організаційні та адміністративні заходи, та й дуже щільна, ювелірна, робота з персоналом.

Інформаційна система (хіба це лише ПЗ?)

І, нарешті, згадаємо визначення системи ще з далеких 90-х років, яке ніхто не скасовував:

Автоматизована система: система, що складається з персоналуі комплексу засобів автоматизації його діяльності, що реалізує інформаційну технологію виконання встановлених функцій
ГОСТ 34.003-90. Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Терміни та визначення.

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

Як спроектувати лікарню

Припустимо, що ви будівельна організація, до вас приходить замовник і просить у такому місці побудувати лікарню. Ви відразу побіжите цеглу класти чи…? Якщо дивитися на те, як часто створюються Інформаційні Системи, то так і є: виконавці відразу починають «заважати бетон і закуповувати склопакети». Мовляв, вийде не так – перебудуємо! Будемо перебудовувати, доки не досягнемо потрібного результату.

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

Без проекту завжди так, навіть якщо цього не видно

Розглянемо тепер процес проектування докладніше. У ньому кілька стадій. Навіщо потрібно проходити кілька етапів, чому за один раз не зробити? Скільки років у школі вивчають операцію множення? Ви скажете - один-два місяці, і будете докорінно неправі. Так, як множити 5 на 6, проходять за тиждень. Ще певний час вивчають таблицю множення. А множення дробів, чисел зі ступенем, логарифмів, виразів у дужках, комплексних чисел, зведення у ступінь скільки вивчають? Майже усі шкільні роки! Виходить, ми одне й те саме множення вивчаємо щороку під різними кутами.
амі.

І чому таке не вивчають у першому класі?

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

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

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

Видно добре, але лише малу частину

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

Тепер нарешті перейдемо до розгляду стадій проектування.

1. Упорядкування загальних вимог

Отже, допустимо ви – проектант. До вас приходить замовник, "посланий" відповідальними будівельниками. Замовник, звичайно, просить вас розробити проект лікарні. Ви біжіть до кульмана і ... Ну гаразд, це вже давнину - запускаєте ArchiCAD і кресліть.

Але, звичайно, мова не про вас. Ви – професіонал і починаєте ставити купу «дурних» питань. І найголовніший із них – навіщо треба будувати лікарню. Яка мета будівництва? Якщо мета не зрозуміла, то ви не зможете відповісти на запитання, чи велика це має бути лікарня або маленька, якого профілю, ніж оснащена. На жаль, замовники найчастіше говорять дуже багато всього цікавого, крім головного, - яка їхня мета. Ось це треба «витягнути» з нього насамперед. І поставити питання маєте ви. Сам замовник – не фахівець, він має ідею, і на цьому він бачить свою роль виконаною. Він розуміє, який шлях необхідно пройти реалізації його ідеї. Як правило, замовник чекає старого доброго дива - прийти на берег моря, закинути невід (заплатити гроші), виловити рибку, і вона виконає його бажання… А трапляється як в анекдоті про багатого мужика, який упіймав золоту рибку, попросив виконати одне бажання: « Хочу, щоб у мене все було! - «Немає проблем, - відповіла рибка, - у тебе все було...»

Щоб вникнути у мету проекту, недостатньо скласти пару речень зі стандартним набором фраз. Мета проекту зазвичай визначається на основі протиставлення: описують існуючу інформаційну модель (наприклад, сидять люди в архіві та папірці перебирають), потім – її недоліки (через відсутність автоматизації в архіві задіяно 10 осіб, що явно надмірно, інші відділи не можуть тижнями отримати з архіву потрібну їм інформацію і т.д.) і пропонують рішення (впровадити програмне забезпечення, яке дозволить здійснювати в автоматизованому режимі ряд операцій, операції треба перерахувати). У випадку, якщо на ринок виводиться зовсім новий вид сервісу, то потрібно вивчити існуючий ринок і «покритикувати» інструменти, що є там, потім запропонувати рішення.

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

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

2. Вибір концепції системи

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

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

Склали загальні вимоги до лікарні, обрали концепцію. "Ну, - скаже замовник, - тепер все зрозуміло, можна креслити". Чи можна? Вимоги загальні, їх треба деталізувати. Наприклад, на першому етапі ви визначили, що має бути лабораторія з аналізу крові. Але яке там буде обладнання, скільки воно споживає електроенергії, стисненого повітря (а раптом?), чи потрібні кварцові лампи для дезінфекції, лабораторні столи, вентиляція? Без цього проектувати важко буде. Це по-перше. А по-друге, необхідно прописати план будівництва лікарні, підготовки та введення її в експлуатацію.

Для Інформаційної Системи розробка ТЗ () – центральна частина проекту. описує:

ЩО має робити система.
Якою має бути загальна структура системи.
Як створити систему |

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

При описі функцій системи (а це центральна частина ТЗ) слід розуміти – ми наводимо вимоги до того, ЩО має робити система, а не ЯК. Для вас має бути важливіше широта охоплення, а не глибина. Наприклад, на першій стадії (складання загальних вимог) ми виявили необхідність функції блокування входу користувача. У ТЗ вказали, що обліковий запис блокується при невикористанні протягом 90 днів або після 6 невдалих спроб входу, доступ може бути обмежений адміністратором на певний термін, при спробі входу заблокованого користувача необхідно виводити повідомлення і т.д. А в технічному проекті (забіжимо вперед), ми з вами намалюємо макет картки користувача з прапорцем блокування та датою розблокування, складемо сценарій входу в систему, в якому проводиться перевірка на блокування, автоматичне розблокування після встановленого терміну, блокування у разі невдалих спроб входу; визначимо, що виконується за клієнта, що - сервера.

Хочеться розвінчати кілька міфів, пов'язаних із розробкою.

Міф перший: У ТЗ містяться вимоги лише до виконавця.

Ні, ТЗ - те, як створити систему, й у техзадании є розділи, у яких можна описати розподіл відповідальності.

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

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

p align="justify"> При розробці технічного проекту Інформаційної Системи необхідні документи, що містять наступне: докладні сценарії, що описують роботу та взаємодію розроблюваної системи, користувачів і суміжних систем; детальні макети інтерфейсу користувача, що містять опис типу даних і поведінки кожного елемента інтерфейсу (значення за умовчанням, умови, за яких можна змінити значення поля, видимість, дії, що виконуються системою при зміні елемента і т.п.); опис протоколів для інтеграції із суміжними системами та обладнанням, форми звітів та опис алгоритму їх формування, структуру серверів та баз даних, якщо їх декілька.

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

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

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

Логічне питання – яка така робоча документація для лікарні? Невже інструкція з прибирання коридору? Жарти жартами, а протипожежну систему треба обслуговувати? Потрібно. А ліфти? А комп'ютерні мережі? А водопровід? "Ну, це до проекту лікарні не відноситься!" – скажете ви. Так, це так. Однак лікарня здається замовнику як єдине ціле і всі системи повинні мати відповідну експлуатаційну документацію. І щоб здавання було швидким, успішним, ви складете перелік вимог, навпроти яких можна ставити галочку, якщо все гаразд.

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

А де тут місце для Agile?

Одні люди двома руками за Agile (або інші "гнучкі" методи розробки), інші різко проти. У автора ж статті своя думка: Agile дуже хороша, але доречна. А використовують його зазвичай за призначенням.

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

Замовник думає: і скільки мене ще по колу за ніс водитимуть?

По-друге, Agile гарний в інноваціях, там, де не зрозуміло, який результат потрібно отримати, чи не зрозумілий шлях його досягнення. Називається це ДКР, дослідно-конструкторськими розробками. Або навіть НДДКР - науково-дослідні та дослідно-конструкторські роботи. На будь-якому заводі є дослідний цех, де з напилком, кілька разів переробляючи, одержують дослідні зразки. Уявимо, що потрібно розробити заново тачскрін, всі жести та поведінку. Тут справді слід пробувати та пробувати, заздалегідь поведінку не опишеш. Але чи часто перед вами завдання такого штибу? Слід розрізняти інженерні розробки та науково-дослідні. Здебільшого ми – інженери з конструювання інформаційних систем.

По-третє, у великому проекті можуть бути етапи, де потрібно саме ДКР, і тоді Agile на допомогу. Ніхто не заважає на рівні оперативного планування скористатися спринтами. Навпаки, дуже зручна технологія: планувати на тиждень чи два і постійно контролювати результат. На стратегічному рівні – каскадне планування, на тактичному – ітеративне. І жодних протиріч!

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

Де дізнатись детальніше про проектування інформаційних систем?

Книжок на цю тему багато. Толстих і не дуже. Але книжка - це завжди Чужий досвід. А у вас інший характер, чудова ситуація та проект. Є така система ТРВЗ – теорія вирішення винахідницьких завдань. Її автор, Альтшуллер, намагається пояснити кроки, які потрібно зробити, щоб винайти щось. Виходить? Як правило, ні. Принципи викладаються цікаві, корисні, але єдиного шаблону винаходу не виходить. Кожна людина думає та творить по-своєму, та й неможливо цьому навчити, можна лише навчитися. Чужий досвід використовувати треба, безглуздо не використовувати, але він має бути пережитий (перероблений) вами, перекладений на ВАШЕ мислення. Скопіювати диво не вдасться.

Теги: Додати теги

Проектування інформаційних систем

Частина 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-технологією. Однак це не означає, що побудовою та контролем інформаційної моделі мають займатися лише аналітики. Допомога колег також може бути дуже корисною. Залучайте їх до перевірки поставленої мети та детального вивчення побудованої моделі як з погляду логіки, так і з погляду обліку аспектів предметної області. Більшість людей легше знаходять недоліки у чужій роботі.

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

На початок

Якість сутностей

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

Список перевірочних питань для сутності:

Чи відбиває ім'я сутності суть даного об'єкта?

Чи немає перетину з іншими сутностями?

Чи є хоча б два атрибути?

Усього атрибутів не більше восьми?

Чи є синоніми/омоніми цієї сутності?

Сутність визначена повністю?

Чи є унікальний ідентифікатор?

Чи є хоча б один зв'язок?

Чи існує хоча б одна функція зі створення, пошуку, коригування, видалення, архівування та використання значення сутності?

Чи ведеться історія змін?

Чи має місце відповідність принципам нормалізації даних?

Чи немає такої ж сутності в іншій прикладній системі, можливо, під іншим ім'ям?

Чи не має суть надто загальний зміст?

Чи достатній рівень узагальнення, втілений у ній?

Список перевірочних питань для підтипу:

Чи немає перетину з іншими підтипами?

Чи має підтип якісь атрибути та/або зв'язки?

Чи мають усі свої власні унікальні ідентифікатори чи успадковують один на всіх від супертипу?

Чи є вичерпний набір підтипів?

Чи є підтип прикладом входження сутності?

Чи знаєте ви якісь атрибути, зв'язки та умови, що відрізняють цей підтип від інших?

На початок

Якість атрибутів

Слід з'ясувати, а чи справді це атрибути, тобто чи описують вони тим чи іншим чином цю сутність.

Список перевірочних питань для атрибуту:

Чи є найменування атрибуту іменником однини, що відображає суть позначається атрибутом властивості?

Чи не включає найменування атрибута ім'я сутності (цього бути не повинно)?

Чи має атрибут лише одне значення у кожний момент часу?

Чи відсутні значення, що повторюються (або групи)?

Чи описані формат, довжина, допустимі значення, алгоритм отримання тощо?

Чи не може цей атрибут бути пропущеною сутністю, яка стала б у нагоді для іншої прикладної системи (вже існуючої або передбачуваної)?

Чи не може він бути пропущеним зв'язком?

Чи є необхідність в історії змін?

Чи залежить його значення лише від цієї сутності?

Якщо значення атрибута є обов'язковим, завжди воно відомо?

Чи є необхідність створення домену для цього і йому подібних атрибутів?

Чи залежить його значення лише від якоїсь частини унікального ідентифікатора?

Чи залежить його значення від значень деяких атрибутів, не включених до унікального ідентифікатора?

Вступ

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

Проектування інформаційних систем охоплює три основні сфери:

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

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

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

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

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

«Водоспад» – схема розробки проекту

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

Стратегія

У документі обов'язково мають бути описані:

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

Ця абревіатура розшифровується так: Must have – необхідні функції; Should have – бажані функції; Could have – можливі функції; Won't have – відсутні функції.

Аналіз

Аналітики збирають та фіксують інформацію у двох взаємопов'язаних формах:

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

Двома класичними результатами аналізу є:

ієрархія функцій, яка розбиває процес обробки на складові (що робиться і з чого це складається);
модель "сутність-зв'язок" (Entry Relationship model, ER-модель), яка описує сутності, їх атрибути та зв'язки (відносини) між ними.

Нижче ми розглянемо три найбільш застосовувані методології структурного аналізу:

діаграми "сутність-зв'язок" (Entity-Relationship Diagrams, ERD), які служать для формалізації інформації про сутності та їх відносини;
діаграми потоків даних (Data Flow Diagrams, DFD), що служать для формалізації представлення функцій системи;
діаграми переходів станів (State Transition Diagrams, STD), які відображають поведінку системи, що залежить від часу; Діаграми життєвих циклів сутностей відносяться саме до цього класу діаграм.

Нормалізація

Допустимі типи зв'язків. При найближчому розгляді зв'язку типу «один до одного» (рис. 7) майже завжди виявляється, що A і B є насправді різними підмножинами одного і того ж предмета або різними точками зору на нього, що просто мають відмінні імена і по-різному описані зв'язки та атрибути.

Зв'язки «багато до одного» представлені на рис. 8 .

III – застосовується рідко. Як A, і B можуть існувати без зв'язку з-поміж них.

Зв'язки «багато хто до багатьох» представлені на рис. 9 .

II – застосовується рідко. Такі зв'язки завжди підлягають подальшій деталізації.

Розглянемо тепер рекурсивні зв'язки (рис. 10).

I – рідко, але має місце. Відображає зв'язки альтернативного типу.

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

III – має місце на ранніх етапах. Часто відбиває структуру «переліку матеріалів» (взаємна вкладеність компонентів). Приклад: кожен КОМПОНЕНТ може складатися з одного і більше КОМПОНЕНТІВ і кожен КОМПОНЕНТ може використовуватися в одному і більше КОМПОНЕНТІВ.

Неприпустимі типи зв'язків. До неприпустимих типів зв'язків належать такі: обов'язковий зв'язок «багато хто до багатьох» (рис. 11) та ряд рекурсивних зв'язків (рис. 12).

Обов'язковий зв'язок «багато хто до багатьох» у принципі неможливий. Такий зв'язок означав би, що жодна з входжень A може існувати без B, і навпаки. Насправді кожна подібна конструкція завжди виявляється помилковою.

Діаграми потоків даних

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

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

Сховище даних (data storage) дозволяє ряді ділянок визначати дані, які зберігатимуться у пам'яті між процесами. Фактично сховище є «зрізами» потоків даних у часі. Інформацію, яку вона містить, можна використовувати у будь-який час після її визначення, при цьому дані можуть вибиратися у довільному порядку. Ім'я сховища має ідентифікувати його вміст. У разі коли потік даних входить (виходить) у (з) сховище і його структура відповідає структурі сховища, він повинен мати те саме ім'я, яке немає необхідності відображати на діаграмі.

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

Деякі принципи перевірки якості та повноти інформаційної моделі
(Джерело - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

Якість сутностей

Список перевірочних питань для сутності:

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

Список перевірочних питань для підтипу:

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

Якість атрибутів

Слід з'ясувати, а чи справді це атрибути, тобто чи описують вони тим чи іншим чином цю сутність.

Список перевірочних питань для атрибуту:

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

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

Список перевірочних питань для зв'язку:

Чи є її опис для кожної сторони, чи точно вона відображає зміст зв'язку і чи вписується в прийнятий синтаксис?
Чи беруть у ній участь лише дві сторони?

Чи не є зв'язок переносимим?

Чи задані ступінь зв'язку та обов'язковість для кожної сторони?
Чи допустима конструкція зв'язку?

Чи не відноситься конструкція зв'язку до тих, що рідко використовуються?

Чи не є вона надмірною?
Чи не змінюється вона з часом?
Якщо зв'язок є обов'язковим, чи завжди він відображає ставлення до сутності, що представляє протилежну сторону?

Для виключного зв'язку:

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

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

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

Уточнення стратегії

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

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

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

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

Комп'ютерПрес 9"2001

Структуризація проекту інформаційної системи. Фундаментальні дослідження

Бібліографічне посилання

До чого тут лікарня, якщо ми розробляємо програмне забезпечення?

Як спроектувати лікарню

1. Упорядкування загальних вимог

2. Вибір концепції системи

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

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

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

А де тут місце для Agile?

Де дізнатись детальніше про проектування інформаційних систем?

«Водоспад» – схема розробки проекту

Стратегія

Аналіз

Нормалізація

Діаграми потоків даних

Деякі принципи перевірки якості та повноти інформаційної моделі
(Джерело - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

Якість сутностей

Якість атрибутів

Уточнення стратегії

Цікавістатті

Цікавістатті

Бібліографічне посилання

До чого тут лікарня, якщо ми розробляємо програмне забезпечення?

Як спроектувати лікарню

1. Упорядкування загальних вимог

2. Вибір концепції системи

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

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

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

А де тут місце для Agile?

Де дізнатись детальніше про проектування інформаційних систем?

«Водоспад» – схема розробки проекту

Стратегія

Аналіз

Нормалізація

Діаграми потоків даних

Деякі принципи перевірки якості та повноти інформаційної моделі (Джерело - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)

Якість сутностей

Якість атрибутів

Уточнення стратегії

Цікавістатті

Цікавістатті

Деякі принципи перевірки якості та повноти інформаційної моделі
(Джерело - Richard Barker, Case Method: Entity Relationship Modelling, Addison-Wesley, 1990)