·        Інформаційний взаємозв'язок - результати рішення одних задач є вхідними даними для рішення інших. Ця особливість впливає на склад і зміст інформаційної бази комп'ютерної системи, вимагаючи також вибору способів і методів нагромадження і збереження інформації в системі.
·        Масовість і груповий характер рішення. Економічні розрахунки виконуються у визначений термін, причому визначається не одна, а група взаємозалежних економічних показників. Ця особливість впливає на структуру алгоритмів рішення задач, а також на склад і зміст програмного забезпечення систем.
·        Необхідність різноманітного рішення. Це стосується задач прогнозування, планування і прийняття рішень. Саме тому в комп'ютерній системі повинні бути передбачені відповідні спеціальні інструментальні й апаратні засоби, наприклад база моделей для задоволення згаданої потреби.
·        Чітко регламентовані терміни представлення вхідних даних і результатів рішення задач, а також вимоги до точності вхідних даних і результатів рішення задач. Тому при створенні комп'ютерної ІС необхідно вирішувати питання контролю інформації на всіх етапах її переробки (перетворення).
·        Постійні зміни складу економічних показників і методик їхнього розрахунку. Ця особливість впливає на склад і зміст програмного забезпечення, особливо на його прикладну частину.
Розмаїтість розв'язуваних у комп'ютерних інформаційних системах задач вимагає їхньої класифікації. Класифікація задач обробки даних по шести основних ознаках, що найбільше часто зустрічаються в спеціальній літературі, приведена в таблиці 4.

Таблиця 4.
Класифікація задач інформаційної системи

Рис. 3. Задачі інформаційних систем

2.3. Елементи комп'ютерної інформаційної системи

2.3.1. Види елементів комп'ютерної інформаційної системи

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

2.3.2. Компоненти інформаційної системи, що забезпечують

Компоненти, що забезпечують, представляють забезпечення інформаційної системи (таблиця 2.)
Таблиця 2.
Забезпечення інформаційної системи

 

2.3.3. Інформаційна технологія

Інформаційне, технічне і програмне забезпечення входить до складу інформаційної технології.
Інформаційна технологія – це комплекс методів і процедур, за допомогою яких реалізуються функції збору, передачі, обробки, збереження і доведення до користувача інформації в організаційно-управлінських системах з використанням обраного комплексу технічних засобів.
Принципова відмінність інформаційної технології від виробничої технології полягає в тім, що вона крім рутинних операцій містить елементи творчого характеру, що не можуть бути регламентовані і формалізовані.
Основні компоненти інформаційної технології:
·        Комп'ютерні апаратні засоби – це фізичне устаткування, використовуваний для процесів уведення, обробки і висновку даних в інформаційній системі.
·        Програмне забезпечення - програмні модулі реалізуючі детально описані, запрограмовані інструкції, що керують і координують компоненти комп'ютерних апаратних засобів в інформаційній системі.
·        Технологія збереження - фізичні засоби збереження даних і програмне забезпечення, що керує організацією даних на фізичних засобах збереження інформації.
·        Телекомунікаційна технологія - фізичні пристрої і програмне забезпечення, що зв'язують різні фрагменти апаратних засобів й які забезпечують передачу даних.
Зміна характеру інформаційної технології
·     Зростаюча міць і падіння цін на інформаційні технології й устаткування: - комп'ютери і периферійні пристрої.
·     Легкість і приступність використання систем навіть для непідготовлених новачків.
·     Можливість проектувати власні додатки і прості системи без допомоги професійних програмістів.
Взаємозалежність між організаціями й інформаційними технологіями
У сучасних системах мається зростаюча взаємозалежність між, з одного боку, діловою організаційною стратегією, правилами і процедурами і, з іншого боку, інформаційними технологіями. Зміни в стратегії, правилах і процедурах вимагають усе великих і великих змін в апаратних засобах, програмному забезпеченні, базах даних і передачі даних. Існуючі системи можуть діяти як обмеження на організації. Часто те, що організація хотіла б робити, залежить того, що системи дозволяють робити

Рис. 1. Взаємозалежність між організаціями й інформаційними технологіями

 

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

Функціональний підхід до структури інформаційних систем дає можливість виділити підсистеми (компоненти) при різному визначенні поняття «функція керування». Найбільшого поширення придбало створення функціональних підсистем по ознаці керування об'єктами (елементами) бізнес - процесу (функціональні області) і по ознаці стадій керування (рівні керування) (таблиця 3.).
Кожен рівень керування має різні інформаційні потреби і висуває свої вимоги до підсистеми інформаційній системі:
·        старші менеджери приймають довгострокові стратегічні рішення по виробах і послугам, які необхідно зробити.
·        середні менеджери забезпечують проведення програми і планів головного керування.
·        операційні менеджери відповідають за поточний контроль щоденних операцій фірми.
Таблиця 3.
Функціональні підсистеми інформаційної системи
Призначення будь-якої функціональної підсистеми інформаційної системи - рішення економічних задач прийняття управлінських рішень, що базується на результатах обробки даних.

Рис. 2. Функціональні підсистеми інформаційної системи організації
2.3.5. Інформаційна архітектура організації
У сукупності, інформаційні системи, а також мети, структура і функції організації формують інформаційну архітектуру організації.
Інформаційна архітектура – специфічна форма, що приймає інформаційна технологія, щоб досягти обраних цілей і функцій організації.
Основні питання по інформаційній архітектурі:
·     Централізація або децентралізація даних.
·     Централізація або децентралізація обробки.
·     Оренда або створення власних засобів телекомунікацій.

Рис. 3. Інформаційна архітектура організації

 

ТЕМА 2. ЕКОНОМІЧНА ІНФОРМАЦІЯ І ЗАСОБИ ЇЇ ФОРМАЛІЗОВАНОГО ОПИСУ

1.                Поняття економічної інформації, її види та властивості.
2.                Структура, форми подання та відображення економічної інформації.
3.                Оцінка економічної інформації.
4.                Інформаційні процедури.
5.                Характеристика засобів формалізованого описання економічної інформації.
6.                Методи класифікації та кодування економічної інформації.
7.                Категорії класифікаторів, порядок їх розробки, упровадження та ведення.
8.                Моделювання елементів економічної інформації.

 

ТЕМА 3. ПРОЦЕСИ ОБРОБЛЕННЯ ЕКОНОМІЧНОЇ ІНФОРМАЦІЇ

1.                Характеристика та класифікація технологічних операцій.
2.                Технологічні процеси автоматизованої обробки економічної інформації.
3.                Типові технологічні операції та їх виконання в інформаційних системах.
4.                Загальна характеристика режимів роботи ЕОМ.
5.                Організація пакетного режиму обробки інформації.
6.                Організація діалогового режиму обробки інформації.

 

ТЕМА 4. ОРГАНІЗАЦІЯ ІНФОРМАЦІЙНОЇ БАЗИ СИСТЕМ ОБРОБЛЕННЯ ЕКОНОМІЧНОЇ ІНФОРМАЦІЇ

1.                Носії інформації, їхній склад та характеристика.
2.                Уніфікована система первинної документації, поняття, склад та вимоги.
3.                Вхідні документи.
4.                Розробка форм та вибір засобів виводу.
5.                Поняття машинного інформаційного забезпечення.
6.                Поняття і класифікація АБД.
7.                Характеристика інфологічної та даталогічної моделі баз даних.
8.                Методи створення оптимальної моделі баз даних.
9.                Теорія нормалізації відношень.

ТЕМА 5. ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ В БІЗНЕСІ

1.                Класифікація систем управління.
2.                Системи оперативного управління та обліку: системи бюджетування та управління проектами.
3.                Аналітичні системи, яки інтегруються (DSS, OLAP).
4.                Аналітичні системи, яки тиражуються.
5.                Системи фінансового аналізу: відкриті та зачинені.
6.                Системи бізнес-планування.
7.                Системи планування та аналізу маркетингу. Системи прогнозування.
1. Класифікація систем керування
У цілому підприємство будь-якої галузі можна розглядати як суб'єкт економічної діяльності, що споживає необхідні ресурси і досягає визначеного запланованого результату. Рис. 1. графічно представляє систему керування підприємством.

Рис. 1. Система керування підприємством
Система керування підприємством представляє піраміду, яку можна умовно розбити на два шари: нижній - оперативний і верхній - стратегічний. На вхід системи керування надходить інформація про основні ресурси, якими необхідно керувати (фінансових, матеріальних, кадрових, інформаційних), у той час як її виходом є результат основної діяльності підприємства. У міру того як ми рухаємося нагору по піраміді, переходячи із шару в шар, відбувається структурування первинної інформації, її згортка і фільтрація, так що звіти, що попадають до вищого керівництва, уже містять усього кілька величин, однак самого істотних для вироблення стратегічних рішень по керуванню і розвиткові.
Використовуючи модель керування підприємством можна ввести класифікацію систем керування, представлену в таблиці 1.
Таблиця 1.
Інформаційні системи керування
На практиці не завжди вдається застосувати дану класифікацію "у чистому виді", оскільки не існує чіткої границі між корпоративними інформаційними системами й інтегрованими системами керування підприємством, що включають широкий набір функцій.
2. Корпоративні інформаційні системи (КІС)
Весь спектр інтегрованих систем керування від великих КІС (EIS - Enterprise Information System) до "коробкових" бухгалтерських програм можна розділити на чотири групи по ступені інтеграції: великі, середні, малі і локальні системи. Вони розрізняються по наборі функцій, вартості і складності впровадження. Найбільш відомі системи представлені в таблиці 2.
Таблиця 2.
Корпоративні інформаційні системи
Великі КІС, найчастіше, не є готовим продуктом, але являють собою сукупність програмних модулів і баз даних, а також технологію їхнього настроювання і застосування. У зв'язку з високою вартістю і складністю таких систем, вони доступні тільки великим підприємствам. Процес упровадження КІС на підприємстві звичайно займає від 6 до 18 місяців. При цьому передбачається, що підприємство має чітко визначену структуру керування, що не піддана різким змінам. Модель цієї організаційної структури закладається в основу інформаційної системи. Підприємство, що знаходиться на етапі вибору стратегії розвитку, що не має чітко визначеної ефективної організаційної структури, не в змозі впровадити КІС. Таким підприємствам потрібні недорогі засоби, що набудовуються легко, оперативного керування і підтримки прийняття рішень. Повноцінні КІС зустрічаються досить рідко. Навіть великі підприємства найчастіше не мають таких систем.
3. Системи оперативного керування й обліку
Системи оперативного керування й обліку - системи, що обслуговують нижній і середній рівень керування підприємством. Їхнє впровадження є перехідним етапом до освоєння більш складних інтегрованих систем керування.
Автоматизація оперативного рівня керування, обліку фінансових і матеріальних ресурсів здобуває масовий характер. Широко поширені програми бухгалтерського і складського обліку. Торговельні підприємства не обходяться без систем обліку торговельних операцій. Наступними по ступені поширення є системи автоматизації документообігу, що забезпечують підготовку і транспортування документів усередині організації, а також збереження й оперативний пошук документів.
Особливого розгляду заслуговують два типи продуктів, що відносяться до систем оперативного рівня керування: системи бюджетування і системи керування проектами. Необхідність у них виникає на етапі організаційної зрілості підприємства і знаменує ріст управлінської культури, оскільки ці продукти мають властивості аналітичних інструментів.
Системи керування проектами
Системи керування проектами – системи планування і контролю виконання робіт. Вони підтримують організаційну діяльність керівників різних рівнів.
В основі систем цього класу лежать алгоритми сіткового планування і розрахунку тимчасових параметрів проекту по методу критичного шляху. Вони дозволяють представити проект у виді мережі, розрахувати ранні і пізні дати початку і закінчення робіт проекту і відобразити роботи на тимчасовій осі у виді діаграми Гантта. Крім того, маються можливості ресурсного і вартісного планування, контролю над ходом виконання робіт.
Групи систем керування проектами:
·     системи "вищого" класу (вартістю понад $1000);
·     прості системи ( щопродаються за ціною нижче $1000).
Вартісні розходження визначаються повнотою і гнучкістю функцій, необхідних для розробки плану й оперативного керування проектом, а також якістю представлення інформації з проекту (діаграми Ганта і PERT) і кількісними характеристиками пакета, такими, як швидкість обчислень, печатки, зміни екранів.
Найбільш відомі системи керування проектами представлені в таблиці 3.Таблиця 3.

Системи керування проектами

Системи бюджетування

Системи бюджетування - інструменти планування бюджету компанії і контролю над його виконанням. Такі продукти задовольняють потреба компаній у керуванні фінансовими ресурсами й організації управлінського обліку, що не забезпечується малими і середніми системами керування, орієнтованими на бухгалтерський облік. Компаніям, що мають велику інтегровану систему керування немає необхідності у використанні окремої системи бюджетування, оскільки ці функції реалізовані в КІС.
Таблиця 4.
Системи бюджетування
4. Аналітичні інформаційні системи
Аналітичні інформаційні системи застосовуються на стратегічному рівні керування компанією. Потреба в них виникає в міру досягнення компанією досить високої культури керування. У свою чергу, упровадження таких систем стимулює ріст кваліфікації керуючого персоналу.
Групи аналітичних інформаційні систем:
·     Інтегровані аналітичні системи – системи, що використовують великі структури даних, що утримуються в інформаційній системі керування підприємством. Використовувані на цьому рівні спеціальні математичні методи дозволяють прогнозувати динамікові різних показників, аналізувати витрати по різних видах діяльності, усвідомлювати їхню детальну структуру, формувати докладні бюджети по різних схемах. Такі засоби, як правило, не входять до складу інтегрованих систем керування підприємством, а є розробками третіх фирм. системи унікальні, дороги, вимагають висококваліфікованої підтримки в процесі впровадження й експлуатації. Сучасний підхід до створення інтегрованих аналітичних систем заснований на концепції "корпоративного сховища даних" (Data Warehousing), OLAP-технології аналізу багатомірних даних (On-Line Analytic Processing), спеціальних математичних моделях підтримки прийняття рішень, що нерідко використовує методи штучного інтелекту.
Найбільш могутні представники:
¨                 Системи підтримки прийняття рішень (Decision Support System - DSS), що можуть містити в собі ситуаційні центри,
¨                 Засобу багатомірного аналізу даних та інші інструменти аналітичної обробки (On-Line Analytic Processing - OLAP).
·     Аналітичні системи, яки тиражуються - автономні програмні продукти, призначені для аналітичної обробки управлінської інформації, підготовки аналітичної звітності, експертизи й аналізу рішень. Найбільш розвиті з цих систем мають засобу інформаційного обміну з зовнішніми базами даних і можуть використовуватися як аналітичні модулі системи керування підприємством.
Таблиця 5.
Інструментальних засобах створення систем підтримки прийняття рішень

Аналітичні системи, яки тиражуються

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

Таблиця 8.
"Закриті" програми фінансового аналізу

Назва програми	Фірма виробник	Характеристика програми
Business Performance Software	UNIDO	Комплекс із трьох програм: Pharos, Best, Fit. Принцип дії досить простий: користувач уводить мінімальну кількість даних про діяльності підприємства, програма відображає набір різноманітних індексів, що характеризують підприємство з різних точок зору. Так, програма Financial Improvement Toolkit (Fit) демонструє фінансові показники попередньої діяльності підприємства; Business Environment Toolkit (Best) оцінює план розвитку підприємства; Business Navigator (Pharos) відслідковує поточну діяльність підприємства по показниках, що відбиває рівень витрат, рух грошових коштів, якість продукції. Спрощений підхід до опису діяльності підприємства виключає можливість практичного застосування програм. Проте, вони з успіхом можуть застосовуватися в якості автоматизованого навчального посібника для вивчення методів керування й аналізу.
CBATool (Cost Benefit Analysis Tool)	Legacy Systems Research	Програма допомагає оцінити альтернативи розвитку бізнесу на підставі критеріїв, що характеризують витрати і прибуток. Користувач повинний описати очікувані витрати і прибуток для кожного альтернативного варіанта. Програма виконує розрахунок показників, дає оцінку альтернативам, проводить аналіз чутливості.

Таблиця 9.

Аналітичні системи бізнесу-планування

Планування й аналіз маркетингу

Класи програм планування й аналізу маркетингу:
·     Аналіз маркетингу. Моделювання стратегії, аналіз положення компанії на ринку, розробка плану маркетингу.
·     Аналіз продажів. Інформаційна підтримка й аналіз процесу продажів, моделювання каналів збуту.
Таблиця 10.
Аналіз маркетингу
Таблиця 11.
Аналіз продажів
Аналітичні системи прогнозування
Основною проблемою для користувачів програм прогнозування є складність математичних моделей, що лежать в основі методів прогнозування. Для того, щоб правильно підготувати вихідні дані, установити параметри й інтерпретувати отримані результати користувач повинний розуміти умови й обмеження використовуваних моделей.
Класи аналітичних систем прогнозування по ступені складності:
·     Професійні пакети, призначені для користувачів, добре знайомих з методами математичної статистики;
·     Прикладні пакети, з якими можуть працювати фахівці - практики, що не мають глибокої математичної підготовки.
Таблиця 12.
Професійні пакети прогнозування
Таблиця 13.

Прикладні пакети прогнозування

ТЕМА 6. ОРГАНІЗАЦІЙНО-МЕТОДИЧНІ ОСНОВИ СТВОРЕННЯ І ФУНКЦІОНУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

1.                Організація робіт, спрямованих на створення та впровадження інформаційних систем.
2.                Впровадження, супроводження і модернізація інформаційних систем.
3.                Документація на розробку інформаційних систем.
4.                Технічне завдання.
5.                Ескізний проект.
6.                Технічний проект.
7.                Робочий проект.
2.4. Документація на розробку інформаційних сістем

2.4.1. Основні документи на розробку інформаційної системи

Види і комплектність документів на інформаційні системи визначає ДСТ 34.201-89 (Інформаційна технологія. Види, комплектність і позначки документів при створенні автоматизованих систем).
Основні документи на розробку інформаційної системи
1.     Звіт про обстеження.
2.     Звіт про науково-дослідну роботу.
3.     Технічне завдання.
4.     Ескізний проект.
5.     Технічний проект.
6.     Робочий проект.
Звіти про обстеження, науково-дослідну роботу й ескізний проект формуються в довільній формі, їхня структура і зміст можуть бути погоджені між замовником і розроблювачем систем.
Зміст і структуру технічного завдання, технічного і робочого проектів визначають державні стандарти.

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

Технічне завдання - основний документ, що визначає вимоги і порядок створення або модернізації інформаційної системи.
Технічне завдання може містити такі розділи:
1.     Загальні зведення.
2.     Призначення і ціль створення системи
3.     Характеристика об'єктів автоматизації.
4.     Вимоги до системи.
5.     Склад і зміст робіт зі створення систем.
6.     Порядок контролю і прийом системи.
7.     Вимоги до складу і змісту робіт з підготовки об'єкта автоматизації до введення системи в дію.
8.     Вимоги до документації.
9.     Джерела розробки.
Дозволяється не вносити в технічне завдання деякі розділи або поєднувати і деталізувати окремі з них (див. Таблицю 3.).

Таблиця 3.
Розділи технічного завдання

 

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

Ескізний проект - короткий попередній опис системи, яку потрібно створювати.
Структуру і зміст ескізного проекту державний стандарт не визначає, і тому ці характеристики проекту визначаються за узгодженням між проектувальником і замовником у залежності від його призначення.
Зміст ескізного проекту:
1.     функції інформаційної системи;
2.     форми первинних і вихідних документів;
3.     відео кадри;
4.     структура інформаційних масивів або їхні назви і головне призначення;
5.     найважливіші алгоритми (формули) розрахунків;
6.     місце розташування і кількість ЕОМ для впровадження системи
7.     порядок створення і впровадження системи і т.п.
Іноді ескізний проект створюється для того, щоб ознайомити експертів або керівництво організації з основними методами, розрахунками, документами, функціями, що будуть властиві інформаційній системі. У такому випадку ескізний проект може виконувати рекламну функцію для розроблювачів системи. Він застосовується, щоб зацікавити організації в тієї або іншій інформаційній системі.
Основні положення ескізного проекту здобувають подальше розвитку в технічному і робочому проектах.

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

Технічний проект може бути оформлений як один документ, а може складатися з окремих документів. Якщо технічний проект оформляється як один документ, то перераховані документи можуть складати розділи технічного проекту (див. Таблицю 4.). Розділи технічного проекту формуються згідно РД 50-34.698-90.

Таблиця 4.
Зміст технічного проекту

 

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

Робочий проект майже ніколи не оформляється як один документ. Він складається з різних документів, що повинні використовуватися під час експлуатації системи. До складу робочого проекту крім паперових документів входять тексти програм на машинних носіях інформації або так називані виконуваний модуль, що працює під керуванням операційної системи і дозволяє обробляти інформацію на ЕОМ. Склад робочого проекту представлений у таблиці 5.
Таблиця 5.
Склад робочого проекту
Керівництво користувача
Керівництво користувача визначається РД 50-34.698-90 і повинно мати такі підрозділи: уведення, призначення й умови використання, підготовка до роботи, опис операцій, аварійні ситуації, рекомендації щодо освоєння. Розділи керівництва користувача представлені в таблиці 6.
Таблиця 6.
Розділи керівництва користувача

 

ТЕМА 7. ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ

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

Рис. 1. Процес розробки системи
Системний аналіз
Системний аналіз - аналіз проблеми, що організація пробує вирішувати за допомогою інформаційної системи.
Системний аналіз виконує системний аналітик.
Ціль системного аналітика - повне розуміння існуючої організації і системи, ідентифікація проблемних областей і визначення шляхів рішення.
Задачі системного аналітика:
·                   Ідентифікація первинних власників і користувачів даних в організації.
·                   Короткий опис існуючих апаратних засобів і програмного забезпечення.
·                   Визначення деталей проблем в існуючих системах.
·                   Дослідження документів, робочих паперів і процедур.
·                   Спостереження роботи системи.
·                   Інтерв'ю основних користувачів системи
Кроки системного аналізу
Кроки системного аналізу, виконувані системним аналітиком, представлені в таблиці 2. Результати системного аналізу оформляються у виді документів: звіті про обстеження, звіт про науково-дослідну роботу і технічне завдання.
Таблиця 2.
Кроки системного аналізу
Проектування
Проект інформаційної системи - генеральний план або модель системи.
Проектування інформаційної системи - визначення моделі системи, що задовольняє інформаційним вимогам, отриманим на етапі системного аналізу.
Проектування інформаційних систем - напружена і творча задача, що вимагає уяви, чутливості до деталей і великого досвіду.
Мети проектування:
·                   Розгляд альтернативних конфігурацій технології.
·                   Керування і контроль технічною реалізацією системи.
·                   Визначення і деталізація технічних специфікацій системи
Види проектування
Існує два основних види проектування логічну і фізичне (див. таблицю 3.)
Таблиця 3.
Види проектування
Проектні альтернативи
Перш, ніж проект інформаційної системи буде довершений, аналитики повинні оцінити різні проектні альтернативи. Базуючи на визначенні вимог і системному аналізі, аналитики створюють высокоуровневые логічні моделі проекту. Потім вони досліджують витрати, вигоди, міцність і слабість кожної альтернативи.
Основні проектні альтернативи:
·                   централізовані або розподілені;
·                   інтерактивні або пакетні;
·                   частково ручні або цілком автоматизовані;
·                   інші.

Роль кінцевих користувачів
Користувачі повинні мати достатній контроль над процесом проектування, щоб гарантувати, що система відбиває їхні ділові пріоритети й інформаційні потреби, а не лінію технічного персоналу
Робота над проектом збільшує розуміння користувачів і прийняття системи, зменшує проблеми, викликані передачею влади, конфліктом між групами, і незнайомством з новими функціями системи і процедурами. Недостатня участь користувача в конструкторських роботах - головна причина невдачі системи.
Характер і рівень участі користувача в проекті змінюється від системи до системи. Існує мала потреба участі користувача в системах із простими або прямими вимогами, чим у ті, де вимоги є складними, комплекси або невизначеними. Системи обробки транзакций і операційного контролю традиційно вимагали малої участі користувача, чим системи стратегічного планування, інформаційних звітів і підтримки рішень. Менш структуровані системи мають потребу в більшій участі користувачів у визначенні вимог і можуть зажадати багатьох версій проекту перш, ніж специфікації будуть бути довершені.
Проектні специфікації
Результатом проектування є проектні специфікації, що входять до складу ескізного і технічного проекту. Найбільш розповсюджені проектні специфікації представлені в таблиці 4.
Таблиця 4.
Проектні специфікації
Програмування
Програмування - процес перекладу проектних специфікацій у комп'ютерне програмне забезпечення.
Складає меншу частину циклу розробки систем, чим проектування і можливе дії по іспиті. Результати програмування оформляються в робочому проекті.
Таблиця 1.
Учасники етапу програмування
Тестування
Тестування - вичерпний і ґрунтовний процес, що відповідає на запитання: чи робить системи необхідні результати при відомих умовах.
50 відсотків від усього бюджету на розробку програмного забезпечення може бути витрачене на іспити. Іспит також вимагає дуже багато часу: повинні бути ретельно підготовлені дані іспити, розглянуті результати і зроблені виправлення в системі.
Види тестування:
·                   тестування модулів або тестування програми – незалежне тестування кожної програми в системі.
·                   Тестування системи - перевірка функціонування інформаційної системи в цілому.
·                   Приймальне тестування - заключна сертифікація готовності системи до використання у виробничих умовах.
Роль користувачів у процесі тестування:
·                   Ідентифікація повного діапазону даних і умов обробки системи.
·                   Визначення повного діапазону умов, включених в іспити буде повним.
·                   Ідентифікація частих і менш загальних транзакций.
·                   Попередження незвичайних умов і більшості загальних типів помилок при використанні системи.
·                   Перевірка ручних процедур у системі.
Якість іспитів значно підвищується, якщо вони проводяться на основі плану іспитів.
План іспитів - список усіх готувань до серії іспитів, що будуть виконані на системі.
Конверсія
Конверсія - процес заміни старої системи нової.
Стратегії конверсії представлені в таблиці 2.
Таблиця 2.
Стратегії конверсії
Якість конверсії значно підвищується, якщо вона проводиться на основі плану конверсії.
План конверсії - список усіх дій, необхідних для установки нової системи.
Проблеми конверсії
Створення плану конверсії.
Конверсія даних.
Навчання кінцевих користувачів використанню нової системи.
Створення детальної технічної і користувальницької документації.
При проведенні конверсії оформляється документація на інформаційну систему, що входить у робочий проект: опис програм, інструкції з операцій технологічного процесу, керівництво користувача, класифікатори техніко-економічної інформації.
Документація - описи роботи інформаційної системи з технічної або користувальницької точки зору.
Реалізація і супровід
Заключними етапами процесу розробки є реалізація і супровід.
Реалізація - процес оцінки системи користувачами і технічними фахівцями на її відповідність первісним цілям розробки і визначення необхідних змін.
Супровід - процес зміни апаратних засобів, програмного забезпечення, документації або процедур працюючої системи з метою виправлення помилок, виконання нових вимог або підвищення ефективності обробки.
Розподіл часу супроводу
Налагодження або виправлення проблем реалізації - 20%.
Зміни даних, файлів, звітів, апаратних засобів або програмного забезпечення - 20%.
Створення розширень користувача, поліпшення документації і перекодування компонентів системи для підвищення ефективності обробки - 60%.
Час супроводу може бути значно скорочене завдяки кращому системному аналізові й ефективним методам проектування.
Види стратегій розробки інформаційних систем
Існує безліч альтернативних підходів до створення нових інформаційних систем. Системи можуть розроблятися цілком силами організацій або за допомогою використання пакетів програм і інших стратегій, щоб скоротити час, витрати і збільшити ефективність. Основні стратегії розробки систем представлені в таблиці 1.
Таблиця 1.
Стратегії розробки інформаційних систем
Проблеми вибору стратегії розробки інформаційної системи
Немає підходу, що може використовуватися для всіх ситуацій і типів систем. Кожний з цих підходів має переваги і недоліки, і кожний забезпечує менеджерів діапазоном виборів. У таблиці 2 представлені основні проблеми вибору стратегії розробки інформаційної системи.
Таблиця 2.
Проблеми вибору стратегії розробки інформаційної системи
Життєвий цикл систем.
Життєвий цикл систем самий старий метод створення інформаційних систем і усе ще сьогодні використовується для середніх або великих складних проектів систем.
Життєвий цикл систем - формальний підхід до створення систем, що припускає, що інформаційна система має життєвий цикл подібно будь-якому живому організмові: з початком, серединою і кінцем і розділяє процес розробки систем на різні стадії і формує інформаційну систему послідовно, стадія за стадією.
Методологія життєвого циклу також має формальний поділ праці між кінцевими користувачами і фахівцями інформаційними систем.
Поділ відповідальності між розроблювачами і кінцевими користувачами:
Технічні фахівці: системні аналитики і програмісти відповідальні за проведення системного аналізу, проектування і робіт з реалізації;
Кінцеві користувачі відповідальні за забезпечення інформаційних вимог і експертизу роботи технічного персоналу.
По завершенню кожного етапу потрібні формальні висновки або угоди між кінцевими користувачами і технічними фахівцями.
Рис. 1. показує результати кожної стадії життєвого циклу, що є підставами для формального висновку.

Рис. 1. Методологія життєвого циклу
У таблиці 3. представлено детальної опис кожної стадії життєвого циклу системи.

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

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

2.5. Структурний аналіз.

2.5.1. Традиційні методології розробки.

На зорі програмування існувало небагато методологій. Відсутність методологій приводило до створення складних, негнучких, ненадійних систем, супровід яких було майже неможливим. У 70-их з'явилися методології, що включають ряд методів або технік для виконання основних функцій розробки проекту. Таблиця 1 демонструє важливість використання методологій розробки.
Таблиця 1. Відсутність і використання методології розробки
Концепція традиційних методологій розробки
Традиційні методології виходять з парадигми: інформаційна система містить два типи сутностей:
·                   деякий аналог програми - операційні сутності, що виконують деяку обробку;
·                   дані - пасивні сутності, що зберігають інформацію, доступну для пошуку, читання і заміни.
В основі традиційних методологій лежить структурний підхід, відповідно до якого при розробці системи виконується функціональна (алгоритмічна) декомпозиція по методу «зверху вниз» – системи розбиваються на складові частини, кожна з яких розглядається окремо від інших, декомпозиція виконується доти поки не буде досягнутий необхідний рівень деталізації.
Основні характеристики традиційних методологій розробки
Основні характеристики традиційних методологій представлені в таблиці 2.
Таблиця 2.
Характеристики традиційних методологій розробки
Методологія структурної розробки або структурний підхід виділяють у традиційних методологіях:
·                   Структурний аналіз.
·                   Структурне проектування.
·                   Структурне програмування.

2.5.2. Структурний аналіз

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

Таблиця 3.
Структурний аналіз

 

2.5.3. Діаграми структурного аналізу

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

Рис. 1. Елемент IDEF0-діаграми
Діаграма потоку даних (Data flow diagram (DFD)) - основний інструмент структурного аналізу, що графічно ілюструє складені процеси системи і потік даних між ними.
Діаграми потоку даних створюються за допомогою використання чотирьох базових позначень, показаних на мал. 3.
Основні елементи діаграми потоку даних

Рис. 3. Позначення діаграми потоку даних
Діаграми можуть використовуватися, щоб представляти процеси високого рівня також, як деталі нижчого рівня. За допомогою розділених на рівні діаграм потоку даних, складний процес може бути розбитий на проміжні рівні деталізації. Повна система може бути розділена на підсистеми з діаграмою потоку даних високого рівня. Кожна підсистема, у свою чергу, може бути розділена в додаткові підсистеми з діаграмами потоку даних нижчого рівня, а підсистеми нижчого рівня можуть бути розбиті знову, поки не буде досягнутий найнижчий рівень деталізації.
Контекстна діаграма - діаграма потоку даних загального представлення, що зображує повну систему як єдиний процес з його головними введеннями і висновками.
На мал. 4. представлено контекстну діаграму системи ведення обліку пенсій і виплат. Ця діаграма надає короткий огляд повної системи ведення обліку пенсійних посібників і виплат, показуючи її головні введення і висновки. Контекстна діаграма зображує повну систему як єдиний процес, що може бути розбитий на більш детальні діаграми потоку даних більш низького рівня. Потік даних до і від цієї системи ведення обліку пенсійних посібників і виплат. Зовнішні сутності – відділ виплат, статистик страхового суспільства і службовець.
Рис. 5. представляє діаграму потоку даних нульового рівня для системи ведення обліку пенсійних посібників і виплат. Ця діаграма потоку даних розбиває контекстну діаграму в більш детальне представлення систем ведення обліку пенсійних посібників і виплат. Вона показує, що система складається з п'яти головних процесів, що можуть, у свою чергу, бути розбиті на більш детальні діаграми потоку даних.

Рис. 4. Контекстна діаграма системи ведення обліку пенсій і виплат
.
Рис. 5. Діаграма потоку даних нульового рівня для системи ведення обліку пенсійних посібників і виплат

 

2.5.4. Засоби документування структурного аналізу

Засобу документування структурного аналізу представлені в таблиці 5.
Таблиця 5.
Засобу документування структурного аналізу
Словник даних, використовуваний у структурному аналізі, може бути розширений і використовуватися протягом процесу розробки систем, щоб допомогти системним розроблювачам стежити за всіма деталями відносно даних, функцій і процесів, що накопичуються для кожної системи.
Наприклад, вхід словника даних для потоку даних "Вихідна допомога":
Вихідні допомога = Сума звичайної вихідної допомоги
+ Дата звичайної оплати
+ Передчасна вихідна допомога
+ Дата передчасної оплати
+ Опція з нагоди втрати годувальника
Таблиця рішень представляє рішення графічно в таблиці, що виражає ряд умов. Коли деякі умови виконуються (так, немає), рішення робляться відповідно до зазначених правил. Таблиця повинна визначити всі можливі умови, що впливають на рішення.
Формат таблиці рішень
·                   Заголовок, що ідентифікує таблицю.
·                   Стовпчики умов із входами для кожної можливої умови.
·                   Інструкції дії з входами для кожної можливої дії, що могло бути прийняте. Такі дії будуть визначені представленими умовами і правилами прийняття рішень, що керують процесом прийняття рішень.
На мал. 6. представлено таблицю рішень для щомісячних виписок рахунка грошового ринку. Таблиця рішень на цьому малюнку документує логікові обробки для посилки щомісячних виписок по рахунку. Вона зображує умови – баланс рахунка і рівень активності рахунка, що визначають, чи дійсно інвестиційний фонд грошового ринку посилає щомісячні виписки по балансі рахунка з попередженнями інвесторам.

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

Рис. 7. Дерево рішень для щомісячних виписок рахунка грошового ринку

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

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

Рис. 9. Псевдокод для щомісячної виписки по рахунку грошового ринку

2.6. Структурне проектування і програмування

2.6.1. Структурне проектування

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


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

Рис. 2. Детальна структурна діаграма системи платіжної відомості

 

2.6.2. Структурне програмування

Структурне програмування розширює керуючі принципи структурного проектування до написання програм.
Структурне програмування - дисципліна організації і кодування програм, що спрощує способи контролю для того, щоб програми могли бути легкі для розуміння і зміни.
Основне правило структурного програмування – спадна розробка програми і розбивка її на модулі.
Структурне програмування використовує основні керуючі структури і модулі, що мають тільки одну крапку входу й одну крапку виходу. Вимоги до модулів програми представлені в таблиці 1.
Таблиця 1.
Вимоги до модулів програми
Основні керуючі конструкції
Структурне програмування довело, що будь-яка програма може бути написана, за допомогою трьох основних керуючий конструкцій:
·                   конструкція послідовності - виконання інструкцій у порядку, у якому вони з'являються, з керуванням, безумовно, що переходить від однієї інструкції до наступної.
·                   конструкція вибору - перевірка умови і виконання однієї з двох альтернативних команд, заснованих на результатах перевірки.
·                   ітеративна конструкція - повторення сегмента коду, поки перевірка умови не поверне істину.
Керуючі конструкції представлені на мал. 3.

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

Рис. 4. Вкладені керуючі конструкції

 

2.6.3. Блок-схеми

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

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

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

Рис. 7. Детальна блок-схема системи платіжної відомості

 

2.6.4. Обмеження традиційних методів

Традиційний структурний підхід добре служив професіоналам інформаційних систем і їхньому співтовариству користувачів. Проте, він має свої недоліки. Більшість критиків думає, що структурні методології будуть повільному і байдужними до швидко змінюється діловому світові. Основні проблеми традиційних методів представлені в таблиці 3.
Були розроблені нові структурні методи, щоб вирішити багато хто з цих проблем.
Нові структурні підходи до розробки
·                   Спільний прикладний проект (Join application design (JAD)) - метод проектування, що збирає користувачів і професіоналів разом в одній кімнаті для інтерактивного проектування системи. Належним образом підготовленої і забезпечені, сесії JAD можуть значно прискорити фазу проектування при включенні користувачів у проект, на рівні попередньо не можливому.
·                   Макетування. Макетування прискорює проект при більшому залученні користувачів і збільшує гнучкість усього процесу.
Таблиця 3.
Обмеження традиційних методів

ТЕМА 8. УПРАВЛІННЯ ПРОЦЕСАМИ ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ

1.                Інформаційна система, яка за планове організаційна зміна.
2.                Перепроектування бізнес-процесів.
3.                Учасники розробки систем.
4.                Управління процесом розробки.
5.                Проектний менеджмент.
6.                Концепція методів планування, організації та контролю проектів.
1. Інформаційні системи як запланована організаційна зміна
Інформаційна система - социотехнический об'єкт, сукупність технічних і соціальних елементів.
Уведення нової інформаційної системи включає набагато більше, ніж нові апаратні засоби і програмне забезпечення. Воно також включає зміни в роботах, уміннях, керуванні й організації. Коли ми розробляємо нову інформаційну систему, ми перепроектуємо організацію.
Один з найбільш важливих моментів, якому потрібно знати при створенні нової інформаційної систем - те, що цей процес є одним видом запланованої організаційної зміни.
2. Перепроектування бізнесів-процесів
Нові інформаційні системи можуть бути могутніми інструментами для організаційних змін. Вони не тільки допомагають раціоналізувати організаційні процедури і документообіг, але вони можуть фактично використовуватися для зміни того, як організація виконує бізнес або навіть безпосередній характер бізнесу
Бізнес-процес - набір логічно зв'язаних задач, виконуваних, для досягнення визначеного ділового результату.
Мети перепроектування бізнесів-процесів:
·     Радикальне поліпшення швидкості і якості, обслуговування.
·     Підвищення віддачі інформаційних технологій.
·     Реорганізація трудових процесів об'єднання кроків по скороченню витрат і усуненню повторів, паперово-інтенсивних задач
·     Перепроектування бізнесу.
Завдяки перепроектуванню своєї системи обробки і процесу роботи з заявками на позичку, Banc One здатний обробити більша кількість документів. Замість щорічної обробки 55,000 позик Banc One щорічно обробляє 500,000 позик (див. Рис. 1.).

Рис. 1. Перепроектування обробки позички в Banc One
3. Учасники розробки систем

Таблиця 1. Групи - учасники створення систем
Області відповідальності розроблювачів систем:
·     технічна якість інформаційної системи;
·     інтерфейс користувача.
·     облік загального впливу на організацію.
·     загальне керування процесом проектування і реалізації.

Джерела системних ідей

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

Рис. 2. Управлінський контроль розробки систем
Таблиця 2.
Склад і функції груп керування процесом розробки
1. Характеристики проекту
Основні характеристики проекту представлені в таблиці 1.
Таблиця 1.
Характеристики проекту
Відмінність проекту від виробничої системи
Відмінність проекту від виробничої системи полягає в тім, що проект є однократної, не циклічною діяльністю. Серійний же випуск продукції не має заздалегідь визначеного кінця в часі і залежить лише від наявності і величини попиту. Коли зникає попит, виробничий цикл кінчається. Виробничі цикли в чистому виді не є проектами. Однак, останнім часом проектний підхід усі частіше застосовується і до процесів, орієнтованим на безперервне виробництво. Наприклад, проекти збільшення виробництва до зазначеного рівня в плині визначеного періоду, виходячи з заданого бюджету, або виконання визначених замовлень, що мають договірні терміни постачання.
Концепція проекту, однак, не суперечить концепції фірми або підприємства і цілком сумісна з нею. Навпроти, проект часто стає основною формою діяльності фірми.
2. Керування проектом
Керування проектом - діяльність, спрямована на реалізацію проекту з максимально можливою ефективністю при заданих обмеженнях за часом, коштам (і ресурсам), а також якості кінцевих результатів проекту (документованих, наприклад, у технічному завданні).
Методика керування діяльністю на основі проекту була розроблена на основі наслідку Лермана:
·                   Закон Лермана: "Будь-яку технічну проблему можна перебороти, маючи досить часу і грошей",
·                   Наслідок Лермана: "Вам ніколи не буде вистачати або часи, або грошей". Основні поняття, зв'язані з керуванням проектом представлені в таблиці 2.
Таблиця 2.
Керування проектом
3. Життєвий цикл проекту
Любою проект проходить через визначені фази у своєму розвитку. Стадії життєвого циклу проекту можуть розрізнятися в залежності від сфери діяльності і прийнятої системи організації робіт. Поняття життєвого циклу проекту є одним з найважливіших для менеджера, оскільки саме поточна стадія визначає задачі і види діяльності менеджера, використовувані методики й інструментальні засоби.
Керівники проектів розбивають цикл життя проекту на етапи різними способами. Наприклад, у проектах по розробці програмного забезпечення часто виділяються такі етапи як усвідомлення потреби в інформаційній системі, формулювання вимог, проектування системи, кодування, тестування, експлуатаційна підтримка. Однак, найбільш традиційним є розбивка проекту на чотири великих етапи: формулювання проекту, планування, здійснення і завершення.
Основні стадії життєвого циклу проекту представлені в таблиці 3.