Системний аналіз

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.3. Зміст етапу "Системне проектування"

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

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

Етап системного проектування завершується формуванням детального (робочого) проекту інформаційної системи. Проект є серіями специфікацій і інструкцій користувачам.

У процесі проектування розрізняють етапи: (1) логічне проектування, (2) фізичне проектування, (3) системні специфікації.

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

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

• інформаційного забезпечення (концептуальних і зовнішніх моделей бази даних, словника елементів бази даних);

• призначеного для користувача інтерфейсу (командних лінійок, панелей меню, діалогових вікон, повідомлень, екранів вхідних і вихідних форм);

• програмного забезпечення (програм і процедур).

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

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

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

Цю метаінформацію про відношення елементів в інформаційній системі називають "суть-зв'язок" або ER-модель (скорочення від англійського Entity-Relationship model).

Правила інтеграції логічних елементів в окремі записи фіксуються в спеціальній таблиці відповідності записів та їх елементів. У першому стовпчику таблиці одноразово фіксується ім'я кожного унікального типу запису (наприклад, ПРИБУТТЯ-НА-СКЛАД), а в першому рядку заголовка цієї таблиці також один раз перелічені унікальні імена елементів всіх записів (НОМЕР-ДОКУМЕНТА, ДАТА-ОТРИМАННЯ, СУМА-НАРАХОВАНО і т. ін.). На перетині рядків і стовпчиків таблиці ставляться символи занесення елементів у записи. Для того, щоб уникнути неоднозначного використання елементів, в спеціальному словнику фіксується точне значення і роль кожного елементу бази даних. Словник містить текстові характеристики (тлумачення) всіх елементів з метою забезпечення однозначного розуміння їх значення (перш за все проектувальниками і користувачами, що беруть участь у проектуванні).

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

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

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

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

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

Дата добавления: 2014-01-03