Размещено на http://www.allbest.ru/

Зміст

Вступ

1. Аналіз вимог

1.1 Основні положення

1.1.1 Мета

1.1.2 Контекст

1.1.3 Означення і скорочення

1.1.4 Посилання

1.1.5 Короткий зміст

1.2 Позиціонування

1.2.1 Ділові переваги

1.2.2 Визначення проблеми

1.2.3 Визначення позиції продукту

1.3 Описи користувачів

1.3.1 Відомості про користувачів

1.3.2 Призначене для користувача середовище

1.3.3 Профілі користувачів

1.3.4 Ключові потреби користувачів

1.4 Короткий огляд продукту

1.4.1 Контекст використання системи

1.4.2 Зведення можливостей

1.4.3 Припущення і зв'язки

1.5 Можливості продукту

1.5.1 Інтерактавний розрахунок рахунку клієнтів

1.5.2 Оперативне використання даних

1.5.3 Розподіл обов'язків

1.5.4 Інтерактивна взаємодія працівників

1.6 Обмеження

1.7 Показники якості

1.7.1 Застосовність

1.7.2 Надійність

1.8 Інші вимоги до продукту

1.8.1 Вживані стандарти

1.8.2 Системні вимоги

1.8.3 Експлуатаційні вимоги

1.9 Вимоги до документації

1.9.1 Керівництво користувача

1.9.2 Інтерактивна довідка

1.9.3 Керівництво по установці і конфігурації, файл Read Me

1.10 Маркування і пакетування

2. Пошук акторів і варіантів використання

2.1 Виявлення акторів

2.2 Виявлення варіантів використання

2.3 Розробка діаграм варіантів використаня

3. Виявлення класів

3.1 Створення діаграми класів

4. User Story

5. Реалізація програмного продукту

Висновок

Список використаної літератури



Вступ

Компанія "Комуненерго" займається обліком електроенергії. На сервер надходять показники спожитою електроенергії користувачами. У кожного користувача є власний тариф, показник, заборгованість і пільги. Термін перевірки показників 30 днів з моменту останньої перевірки.

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

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



1. Аналіз вимог

1.1 Основні положення

1.1.1 Мета

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

1.1.2 Контекст

Цей документ розробляється в рамках проекту автоматизації діяльності компанії "Комуненерго".

1.1.3 Визначення і скорочення

Основні визначення приведені в документі " Глосарій проекту".

1.1.4 Посилання

Бачення базується на документі "Автоматизація Комуненерго" від 8.02.2012.

1.1.5 Короткий зміст

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

1.2 Позиціонування

1.2.1 Ділові переваги

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

1.2.2 Визначення проблеми

Визначення проблем приведене у табл.1. 2.1

Таблиця 1.2.1 Визначення проблем

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



1.2.3 Визначення позиції продукту

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

Таблиця1.2.2 Визначення позиції продукту

Для	Компанії "Комуненерго"
Якій	Потрібно оптимізувати процес диспетчиризації обчислень.
(Назва продукту)	АІС "Диспетчер"
який	Заснованій на СУБД і високонадійний.
На відміну від	Існуючого механізму на основі електронних таблиць.
Наш продукт	Виключає помилки в розрахунках,втрату даних.

1.3 Описи користувачів

1.3.1 Відомості про користувачів

У системи існують три основні користувачі: диспетчер, менеджер, кур'єр.

Менеджер - вводить дані про клієнтів, що поступили. Диспетчер - обробляє дані,проводить розрахунки.

Кур'єр - збирає показники клієнтів, інформує їх.

1.3.2 Призначене для користувача середовище

На підприємстві є 1 офіс, 2 менеджери, 3диспечери, 10 курє'рів. Збільшення кількості диспетчерів в найближчих 5 років - максимально 8, менеджерів - максимально 5, курєрів - максимально 20.

Система працюватиме на платформі IBM РС.

Операційна система: Microsoft Windows XP.



1.3.3 Профілі користувачів

У табл. 1.3.1 представлено профілі користувачів.

Таблиця1.3.1 Профілі користувачів

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

1.3.4 Ключові потреби користувачів

Диспетчер витрачає велику кількість годин на проведення розрахунків.

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

1.4 Короткий огляд продукту

1.4.1 Контекст використання системи

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



1.4.2 Зведення можливостей

Вигоди замовника представлено у табл. 1.4.1.

Таблиця1. 4.1 Вигоди замовника і підтримуючи можливості

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

1.4.3 Припущення і зв'язки

Система використовуватиметься на територіально зосередженому (без зовнішніх філій) підприємстві.

У разі змін у формах документів АІС повинна зазнати незначних змін (потрібно буде модифікувати звітні форми).

1.5 Можливості продукту

1.5.1 Інтерактавний розрахунок рахунку клієнтів

Диспечер отримує показники користувача, а система обчислює суму в залежності від тарифу користувача,заборгованості і пільг.

1.5.2 Оперативне використання даних

Усі дані про користувачів зберігаються відповідно до їх паспортного номера.

1.5.3 Розподіл обов'язків

Кожен працівник займається конкретною роботою.



1.5.4 Інтерактивна взаємодія працівників

Кожен працівник може брати необхідну йому інформацію у іншого працівника.

1.6 Обмеження

Впровадження системи не повинне займати більше 3 місяців.

У ядрі системи повинна бути представлена промислова СУБД

1.7 Показники якості

1.7.1 Застосовність

Час необхідний для навчання звичайних користувачів, - 4 робочих дні (32 години), для навчання досвідчених користувачів - 1 робочий день (8 годин).

Час відгуку для типових завдань - не більше 5 секунд, для складних завдань - не більше 20 секунд.

1.7.2 Надійність

Доступність - час, що витрачається на обслуговування системи не повинен перевищувати 4% від загального часу роботи.

Середній час безвідмовної роботи - 20 робочих днів. Максимальна норма помилок або дефектів - 3 помилка на десять тисяч рядків коду.

1.8 Інші вимоги до продукту

1.8.1 Вживані стандарти

Система повинна відповідати всім стандартам інтерфейсу користувача Microsoft® Windows®.



1.8.2 Системні вимоги

Мінімальні системні вимоги:

128 Mb пам'яті;

35 Mb вільного дискового простору;

процесор з тактовою частотою 850 MHz;

Операційна система Windows ХР.

1.8.3 Експлуатаційні вимоги

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

1.9 Вимоги до документації

1.9.1 Керівництво користувача

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

1.9.2 Інтерактивна довідка

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



1.9.3 Керівництво по установці і конфігурації, файл Read Me

Система повинна мати керівництво по установці у файлі ReadMe.txt, який повинен додаватися до системи. Файл ReadMe.txt повинен містити докладну інструкцію по установці даної системи, щоб у разі потреби користувач зміг провести установку самостійно без допомоги адміністратора.

1.10 Маркування і пакетування

Система розповсюджуватиметься на компакт-диску, на якому знаходитиметься сама система, а також інтерактивна довідка, керівництво по установці і керівництво користувача до неї.

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



2. Пошук акторів і варіантів використання

2.1 Виявлення акторів

На рисунку 1 представлені основні кандидати в актори системи.

Рис. 1. Аналіз акторів системи

Інтерв'ю, яке було проведене з вказаними вище кандидатами показало, що молодший менеджер і старший менеджер припускають використовувати ІС, що розроблюється, однотипно. Це дозволило узагальнити ці 2 ролі в одну. Аналогічна ситуація - з кур'єрами, див. рис. 1.

Короткий опис акторів представлено в табл. 1.

Таблиця. 2.1. Виявлення акторів

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

2.2 Виявлення варіантів використання

Виявлені варіанти використання зведені в таблицю 2.1.



Таблиця. 2.2. Виявлення варіантів використання

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

2.3 Розробка діаграм варіантів використання

Всі варіанти використання показані на рис. 2.1

Рис. 2.1. Діаграма прецедентів системи



3. Виявлення класів

3.1 Створення діаграми класів

Діаграми класів будемо розглядати з концептуальної точки зору. Для спрощення завдання і щоб не захаращувати діаграми несуттєвими деталями методи setX, getX для кожного атрибута Х класів ставити не будемо.

Заповнення діаграми почнемо з визначення класів-сутностей. Розглянутий сценарій складається з:

* Клієнта;

* Рахунку клієнта;

* Тарифу.

Створимо класи-сутності Client (Клієнт), Tarif(Тариф) і AcountClient (Рахунок клієнта). Опишемо кожен клас.

Таблиця 3.1 Класс Client:

Параметр	Значення
Коментар	Клас,який описуэ собой клієнта фірми
Атрибути	name : String - назва клієнта address : String - адреса клієнта phone : String - телефон клієнта index: int - показник клієнта IdAccount - номер рахунку клієнта Всі атрибути мають модифікатор доступу - private
Операції	AddClient() - додавання нового клієнта RemoveClient() - видалення існуючого клієнта GetInfo() - отримати інформацію про клієнта Всі операції мають модифікатор доступу - public

Таблиця 3.1 Класс tarif

Параметр	Значение
Коментар	Клас, містить інформацію про тарифи
Атрибути	Name - String; імя тарифу Prise - Float; ціна за 1 Вт електроенерції Duration - Date; термін дії Id- int; порядковий номер
Операції	Create() -створення нового тарифу SetInfo() - занесення інформації про тариф GetInfo() - получення інформації про тариф Всі операції мають модифікатор доступу - public

Таблиця 3.2 Класс AcountClient:

Параметр	Значение
Коментар	Класс, клас представляє рахунок клієнта
Атрибути	IdTarif-номер тарифу; AOEC- Float; кількість спожитої електроенергії; Som- Float; внесена сума; Arrears- Float; заборгованість;
Операції	Create() - створення нового акаунта SetInfo() - занесення інформації GetInfo() - отримання інформації Calculation()- нарахування Всі операції мають модифікатор доступу - public

Результат створення класів-сутностей зображений на рис. 3.1:

Рисунок 3.1. Створені класи-сутності

Додамо відносини між класами (рис.3. 2):

* клас Client I Tarif - відношення асоціації, оскільки дані два класи просто пов'язані один з одним і ніякі інші типи зв'язків тут застосувати не можна. Один клієнт може мати тільки один тариф, а тарив може вміщати декількох клієнтів,тому кратність біля Client -1,а біля Tarif -1 .. n

* клас Client і Account- відношення композиції, оскільки рахунок клієнта є частиною клієнта, і без нього існувати не може. Один клієнт може мати тільки один рахунок і навпаки, тому кратність зв'язку з боку Client і Order 1.

Рисунок 3.2. Класи-сутності та відносини між ними



4. User Story

Таблиця 4.1. Опис "User Story"

Як	Я хочу	Тому
Менеджер	Мати дані про клієнта	Можу ввести інформації про клієнтів
Кур'єр	Ввести показники клієнтів	Я знаю що вводжу показники
Диспеччер	Мати показники клієнтів	Можу провести розрахунки
Менеджер	Мати інформацію про заборгованість	Можу передати її курєрам
Менеджер	Мати плани роботи на рік	Можу призначити термін зняття показників
Менеджер	Мати інформацію про клієнтів які залишили нашу фірму	Можу видалити інформацію про клієнта

користувач файл програмний конфігурація



5. Реалізація програмного продукту

Увійшовши в систему потрібно вибрати під яким актором ви будете працювати. Є три актори Менеджер, Диспечер, Кур'єр.(рис.5.1)

Рис.5.1.Вибір актора

При виборі актора потрібно ввести логін і пароль.(рис.5.2.)

Рис.5.2.Авторизацій.

Залежно від авторизації переходимо на форми акторів

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



Рисунок 5.3. Вікно менеджера

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

Рисунок 5.4.Реєстрація клієнта

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



Рисунок 5.5. Видалення клієнта

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

Рисунок 5.6. Вікно диспетчера

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



Рисунок 5.7.Вікно кур'єра

Висновок

Отже я навчився проводити аналіз вимог до програмних систем, описувати акторів і класи, а також описувати User-ctory. Дана система полегшує роботу диспетчера,менеджера і взаємодію між працівниками. Також забезпечує надійне зберігання даних і швидкий доступ до них. Програма матє високих системних вимого, оскільки машини на підприємстві старі.



Список використаних джерел

1. Анализ требований к автоматизированным информационным системам [Електронний ресурс] / Ю.А. Маглинец // Интернет университет -- Режим доступу: http://www.intuit.ru/department/itmngt/analisis/.

2. Документація. Звіти у сфері науки і техніки. Структура і правила оформлення: ДСТУ 3008-95. -- [Чинний від 1996-01-01]. -- К. : Держстандарт України, 1995. -- 38 с.

3. Орлов С. Технологии разработки програмного обеспечения: Учебник / С. Орлов. - СПб.: Питер, 2002. - 464 с.

4. Соммервилл И. Инженерия программного обеспечения, 6-е издание.: Пер. с англ. / Иан Соммервилл. - М.: Издательский дом "Вильямс", 2002. - 624 с.

Размещено на Allbest.ru