Технічні вимоги до інформаційної системи

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

Загальне розуміння питання

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

Увагу всім деталям

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

Які бувають?

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

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

Вимоги: звідки їх взяти?

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

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

Не все так однозначно

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

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

Як це виглядає?

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

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

Продовжуючи роботу

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

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

Крок за кроком

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

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

Опорні точки зору

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

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

Альтернативний підхід

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

Точка зору може означати думка зовнішнього отримувача сервісу, реалізованого через ІС. На підставі ТЗ можна виявити дані, які використовуються при втіленні сервісів системи, управлінні ними. Цей підхід прийнято вважати найефективнішим. Він ліг в основу Viewpoint-Oriented Вимога Definition – специфічного методу виявлення вимог, що дозволяє визначати інформацію та ефективно аналізувати її.

Робота з точками зору

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

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

Не поспішати!

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

Атестація вимог

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

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