Призначення

Введення.

Вчитель Дмитренко О.В.

Вчитель Коляда О.В.

Зміни в суспільно-політичному житті. Утворення української козацької держави — Війська Запорозького

Переможні битви 1648—1649 рр. дали можливість почати будівництво Української козацької держа­ви — Війська Запорозького (Гетьманщини) на основі традицій Запорозької Січі.

Територія Війська Запорозького згідно з умовами Зборівського договору складалася із земель Ки­ївського, Чернігівського й Брацлавського воєводств (столиця — м. Чигирин). Замість воєводств ство­рювалися 16 полків на чолі з полковниками й 272 сотні на чолі із сотниками.

Головою держави був обраний козаками гетьман, який мав вищу адміністративну, судову й військо­ву владу. Вищими органами влади були Генеральна (згодом Старшинська) Рада і Генеральна стар­шина. Найвищою судовою установою був Генеральний військовий суд при гетьманові.

Збройні сили складалися з піхоти, кінноти, артилерії, розвідки, обозної, санітарної та інших служб.

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

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

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

1.2. Угоди прийняті в документах.

За основу розробки документації взято стандарти групи IEEE, так розроблено специфікацію вимог за допомогою стандарту IEEE 830 в якому містяться рекомендації до структури і методам опису програмних вимог. Але особливістю виділення тексту є те, що всі заголовки повинні бути значущими та виділятися жирним шрифтом. Також для нумерації рисунків та правил оформлення додатків використовується стандарт ДСТУ3008-95.

1.3. Передбачувана аудиторія і рекомендації з читання.

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

· Підрозділ 1. Вступна частина (в якій описуються принципи використання даної специфікації, її структура, призначення, границі проекту, посилання та угоди, що прийняті в документах).

· Підрозділ 2. Загальний опис (в даному розділі описуються загальний погляд на продукт, особливості продукту, класи користувачів та особливості документації для них, а також операційне середовище, обмеження та залежності).

· Підрозділ 3. Функціональність системи (в розділі описаний весь функціонал та вимоги для нього, так детально як це необхідно для розробнків).

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

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

· Додатки. Додаток В містить словник термінів, необхідні для розуміння специфікації. Додаток А містить моделі аналізу (тобто графічне зображення діаграм потоків даних, IDEF0, IDEF3 і інше).

Рекомендації до послідовності читання різними групами користувачів специфікації:

Розробникам рекомендується починати переглядати специфікацію з пункту 1.1 (призначення), 1.3(рекомендації з читання) після чого перейти до пункту 1.4 (границі проекту) та далі продовжуючи перегляд всього розділу 2, крім пункту 2.6(документація для користувачів) та в випадку, якщо компанія не має досвіду з розробки подібних продуктів, то можна упустити перегляд пункту 2.1 (загального погляду на продукт). Після переглянутих пунктів необхідно прочитати повністю розділи 3, 4, 5, додаток А, та за необхідності додаток В.

Тестувальникам рекомендується починати переглядати специфікацію з пункту 1.3(рекомендації з читання), а потім перейти до пункту 2.1(загальний погляд на продукт), щоб виявити помилки, що були в попередніх версіях продукту, або в схожих версіях. Рекомендується також переглянути пункти 2.4 (операційне середовище), 2.5 (обмеження), 2.7(залежності), 4.2 - 4.4 (апаратні, програмні інтерфейси та передачі інформації). Обов’язковим є перегляд розділу 3, 5 та додатку А.

Менеджерам проекту рекомендується проглянути розділ 1 виключаючи пункт 1.2(угоди, що прийняті в документах), повністю розділ 2 та вибірково на розсуд пункти з розділів 3, 4 та 5.

Технічним описувачам рекомендується почати перегляд з пунктів 1.2 (угоди прийняті в документах), 1.3(рекомендації з читання), 1.5(посилання), 2.3 (класи користувачів), 2.6 (документація для користувачів), повністю 3,4 та 5 розділи та додаток В та А.

Персоналу по обслуговуванні та підтримці продукту необхідно починати розгляд з пунктів 1.3, 1.4 (границі проекту), після чого розглянути пункти 2.2 (особливості продукту), 2.3 (класи користувачів) та 2.7 (залежності продукту), потім для кращого розуміння функціональності переглянути розділ 3, та розділ 4 виключаючи пункт 4.1 (інтерфейси). Вибірково переглянути розділ 5 та додаток В.

1.4. Границі проекту.

Отже продукт забезпечує управління безпекою користувача. Бізнес цілями системи є:

· підвищення якості та надійності управління власного рахунку.

· забезпечення оперативного доступу до конфіденційних даних.

· підвищення зручності роботи з терміналами та безпеки при роботі з терміналами.

· забезпечення керування рівня доступу для різних пристроїв.

· підвищення обізнаності користувача в безпеці при виконанні банківських операцій.

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

Дата добавления: 2015-05-24