2.89M

Category:

informatics

Уведення в методологічні основи побудови програмного забезпечення військових інформаційних систем

1.

ВІЙСЬКОВИЙ ІНСТИТУТ ТЕЛЕКОМУНІКАЦІЙ ТА
ІНФОРМАТИЗАЦІЇ ім. ГЕРОЇВ КРУТ
МЕТОДОЛОГІЧНІ ОСНОВИ ПОБУДОВИ
ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ВІЙСЬКОВИХ ІНФОРМАЦІЙНИХ СИСТЕМ
ПРАКТИЧНЕ ЗАНЯТТЯ
Тема 1. Уведення в методологічні основи
побудови
програмного забезпечення
військових інформаційних
систем
Заняття 4. Практика у розробці технічного завдання на
створення інформаційної системи військового
призначення
2021

2.

ЦІЛЬОВА
НАСТАНОВА:
ЛІТЕРАТУРА:
1.Пояснити сутність формалізованого опису та реалізації потоків завдань
інформаційних систем, що створюються.
•Виховувати високу патріотичну та професійну спрямованість курсантів з
урахуванням досвіду проведення ООС, почуття відповідальності за
виконання покладених завдань.
ЛІТЕРАТУРА:
ЦІЛЬОВА НАСТАНОВА:
1.Методичні вказівки до виконання лабораторних робіт з дисципліни
«Інфраструктура інформаційних технологій» (Guidelines to perform laboratory
works on the course «IT infrastructure» – draft) для студентів спеціальності 151
– «Автоматизація та комп’ютерно-інтегровані технології» [Електронний
ресурс] / Уклад. В.М. Дубовой, О. Д. Никитенко, Т.В. Грищук, А.В. Галущак. –
Вінниця : ВНТУ, 2018. – 25 с.

3.

1. Засвоєння переліку нормативно-технічних
документів,
методичних
матеріалів,
що
використовуються при розробці технічного
завдання
2.
Визначення
призначення
та
цілей
інформаційної системи, що створюється.
3. Визначення переліку функціональних і
нефункціональних вимог до інформаційної
системи.
Створення
моделі
вимог
в
програмному пакеті Enterprise Architect

4.

Мета - вивчення особливостей формування розділу
«Загальні відомості» технічного завдання (ТЗ) на
створення автоматизованої системи (АС) згідно ГОСТ
34.602-89.
ТЗ на АС містить наступні розділи, які можуть бути
розділені на підрозділи:
• загальні відомості;
• призначення і мети створення (розвитку) системи;
• характеристика об'єктів автоматизації;
• вимоги до системи;
• склад і зміст робіт зі створення системи; порядок
• контролю та приймання системи;
• вимоги до складу та змісту робіт з підготовки об'єкта
автоматизації до введення системи в дію;
• вимоги до документування;
• джерела розробки.

5.

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

6.

До Технічних вимог передбачається внесення змін і доповнення в порядку,
який зазначений в ГОСТ 19.201-78. ЕСПД. Технічне завдання. Вимоги до
вмісту і оформленню.
Під час розробки і тестування Розробник повинен керуватися
вимогами наступних нормативних документів:
• Про затвердження переліку обов’язкових етапів робіт під час
проектування, впровадження та експлуатації засобів інформатизації:
Постанова Кабінету Міністрів України від 04 лютого 1998 року № 121;
• Про затвердження загальних вимог до програмних продуктів, які
закуповуються та створюються на замовлення державних органів :
Постанова Кабінету Міністрів України від 12 серпня 2009 року № 869;
• ГОСТ 19.101-77 Єдина система програмної документації: Види програм і
програмних документів;
• ГОСТ 19.202-78 ЕСПД. Специфікація. Вимоги до вмісту і оформленню;
• ГОСТ 19.301-79 ЕСПД: Програма і методика випробувань. Вимоги до
вмісту і оформленню;
• ГОСТ 19.401-78 ЕСПД. Текст програми. Вимоги до вмісту і оформленню;
• ГОСТ 19.402-78 ЕСПД. Опис програми;
• ГОСТ 19.505-79. ЕСПД. Керівництво оператора. Вимоги до вмісту і
оформленню;
• ГОСТ 2.105-95 Єдина система конструкторської документації. Загальні
вимоги до текстових документів.

7.

8.

9.

10.

Мета - вивчення особливостей формування розділу «Призначення і цілі
створення системи» технічного завдання (ТЗ) на створення автоматизованої
системи (ІС) згідно ГОСТ 34.602-89.
Завдання. Згідно обраної теми створити документ з розділом «Призначення і
цілі створення системи» технічного завдання.
2.1 Теоретичні положення
Даний розділ містить наступні підрозділи:
1) Призначення системи;
2) Цілі створення системи.
В підрозділі «Призначення системи» визначається вид діальності, що
підлягає автоматизації (управління, проектування і т. п.) і перелік об’єктів
автоматизації, на котрих передбачається застосувати процеси автоматизації.
В підрохділі «Цілі створення системи» наводиться найменування і значення
технічних, технологічних, виробничо-економічних, інших показників об’єкта
автоматизації, що вимогаються в процесі розробки, і котрі повинні бути
досягнуті в результаті створення автоматизованої інформаційної системи.
Також визначаються критерії оцінки досягнення цілей створення системи.
У більшості випадків даний підрозділ містить як формальний, так і реальний
опис цілей, що досягаються.

11.

Приклад 1: АІС “Кадри”
АІС “Кадри” призначена для інформаційно-аналітичного забезпечення
процесів військового навчального закладу у частині виконання таких
процесів:
− створення штатних розкладів;
− проведення розрахунку заробітної плати;
− оперативний облік руху кадрів;
− ведення адміністративного документообігу за персоналом та обліку праці;
− атестація та визначення потреб (навчання, підвищення кваліфікації)
працівників;
− рекрутинг персоналу на вакантні посади;
− ведення архівів без обмежень строків давнини;
− публікування відкритих частин інформації системи.

12.

Приклад 1: АІС “Кадри”
Цілі створення системи АІС “Кадри”
1. Заміщення наявної інформаційної системи, яка не надає можливість
комплексного
інформаційно-аналітичного
забезпечення
процесів,
перерахованих вище (у зв’язку із введенням нових нормативних правил
управління кадрами).
2. Підвищення ефективності виконання процесів шляхом скорочення часу
операції, уникнення дублювання операцій ведення даних, покращення
інформаційної взаємодії учасників процесу.
3. Підвищення якості прийняття управлінських рішень за рахунок
оперативності представлення, повноти, достовірності та зручності
форматів відображення інформації.
4. Підвищення інформаційної відкритості та прозорості діяльності органів
відділу кадрів (відділу особового складу та стройового), підвищення
зручності та комфорту (зниження фінансових та часових витрат) фізичних
та юридичних осіб при отриманні інформації про кадрові потреби ВНЗ.

13.

Для реалізації поставлених цілей система має
вирішувати такі задачі:
− оперативний облік кадрів;
− облік праці;
− розрахунок заробітної плати;
− побудова аналітичних звітів та виписок;
− інтеграцію із існуючими АІС агентства;
− створення сайту для відображення відкритих
частин інформації.

14.

15.

16.

17.

18.

19.

1.4. Планові терміни початку та закінчення роботи
Терміни виконання робіт з розробки КСПЗ “Ground control”
уточнюються після затвердження технічного завдання та
прийняття рішення щодо шляхів розробки Комплексу (власна
розробка силами розробника або залучення субпідрядника).
Терміни виконання робіт затверджуються замовником за
поданням розробника протягом місяця після затвердження цього
технічного завдання.
1.5. Відомості про джерела та порядок фінансування
Джерела та порядок фінансування робіт зі створення Комплексу
визначаються
Замовником
у
встановленому
чинним
законодавством порядку.

20.

21.

22.

23.

24.

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

25.

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

26.

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

27.

Схема структурна «as-is»

28.

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

29.

3.2.2 Визначення вимог
Матриця також дозволяє контролювати повноту і цілісність реалізації:
кожному автоматизованому бізнес-процесу повинна бути поставлена у
відповідність підсистема (підсистеми), а підсистема повинна реалізовувати
будь-який процес, відповідно.
МОДЕЛЬ УПРАВЛІННЯ ВИМОГАМИ ДЛЯ ПІДСИСТЕМИ «ЗАРАХУВАННЯ СТУДЕНТА»:

30.

Таблиця описів вимог має наступний вигляд:
Вимоги REQ009 і REQ010 є пропонованими для розширення
можливостей.
Вимога «Ведення залікових книжок» реалізується в рамках іншої
підсистеми.

31.

32.

Робочий простір додатки Enterprise Architect містить набір вікон, контекстних
меню і панелей інструментів. Разом ці елементи забезпечують просту і гнучку
роботу з додатком.
При запуску Enterprise Architect перше, що відображається це стартова
сторінка (рисунок 1.1).
Ця сторінка надає
наступні можливості:
.

33.

34.

35.

36.

37.

Браузер проекту (Project Browser) дозволяє переміщатися по простору
проекту Enterprise Architect. У ньому відображаються пакети, діаграми,
елементи і їх властивості (рисунок). Можна перетягувати елементи з папки
в папку або з браузера прямо на діаграму.
Браузер проекту служить для управління
та подання всіх елементів в моделі.
Браузер проекту можна розділити на
уявлення, кожне з яких містить діаграми,
пакети та інші елементи.

38.

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

39.

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

40.

1. Структурна схема системи логістичного забезпечення
УПРАВЛІННЯ ПЕРСОНАЛОМ
Модуль призначений для ведення обліку заробітної плати, контролю робочим
часом і організації даних про персонал. Підтримується планування і контроль
діяльності персоналу.

English Русский Rules