Автоматизированная система по учету жителей и их расчетов. Моя ДЗ. Автоматизована система житлоуправління з обліку мешканців та їх розрахунків

• Название: Автоматизована система житлоуправління з обліку мешканців та їх розрахунків
• Анкор: Автоматизированная система по учету жителей и их расчетов
• Дата: 07.09.2019
• Размер: 0.91 Mb.
• Имя файла: Моя ДЗ.docx
• Тип: Пояснювальна записка; #86171
• страница: 1 из 4

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ КИЇВСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ імені Тараса Шевченка ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ Кафедра програмних систем і технологій Дисципліна «Основи програмної інженерії» Пояснювальна записка на тему: «Автоматизована система житлоуправління з обліку мешканців та їх розрахунків»
Виконав:	Іваненко Іван Володимирович	Перевірила:	Поперешняк Світлана Володимирівна
Група	ІПЗ-11	Дата перевірки
Форма навчання	денна	Оцінка
Спеціальність	121
2019

Зміст

Вступ 3

Завдання 3

Опис предметної галузі 3

Модель життєвого циклу ПЗ 3

Стислий опис методів та засобів, які застосовуються при проектуванні 5

Специфікація проекту 5

Встановлення вимог 5

Спрощений зміст технічного завдання (документ опису вимог) 5

Діаграма варіантів використання (Use Case Diagram) 8

Календарне планування та планування ресурсів в Microsoft Project 14

WBS, OBS та двонаправлена модель управління проектом 17
Специфікування вимог 20

Class diagram (діаграма класів) 20

Package diagrams (діаграма пакетів). 21
Моделювання поведінки системи 21

Activity diagram (діаграма діяльності) 21

Іnteraction diagrams (діаграми взаємодії) 22

State diagram (діаграма стану) 23
Проектування архітектури ПЗ 24

Component diagram (діаграма компонентів) 24

Deployment diagram (діаграма розгортання) 25
Детальне проектування 26

Проектування інтерфейсу користувача 26
Генерація програмного коду 28

Висновок 33

Список літератури 34

Вступ

с

Завдання

Для виконання поставленої мети необхідно виконати наступні завдання:

• 
  розглянути принцип роботи ЖКГ;
  
• 
  розглянути основні документи (пов’язані зі стандартами);
  
• 
  визначити вимоги до розробки ПЗ;
  
• 
  розробити конкурентоспроможну модель автоматизованої системи житлоуправління;
  
• 
  переглянути результати виконаної роботи.
  

Опис предметної галузі

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

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

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

Під час вибору моделі життєвого циклу я використовував характеристики таких елементів розробки:

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

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

Використання W-моделі найбільш ефективно в наступних випадках:

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

W-модель доцільно використовувати в даному проекті з таких причин:

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

Стислий опис методів та засобів, які застосовуються при проектуванні.
В ході виконання роботи використовувались такі методи та засоби:

• 
  Microsoft Word — текстовий процесор, що випускається фірмою Майкрософт, входить до складу офісного пакету «Microsoft Office». Використовувався під час створення пояснювальної записки.
  
• 
  Microsoft PowerPoint — програма підготовки презентацій і перегляду презентацій, що є частиною Microsoft Office і доступна в редакціях для операційних систем Microsoft Windows і macOS. Матеріали, підготовлені за допомогою PowerPoint, призначені для відображення на великому екрані - через проектор або телевізійний екран великого розміру. Використовувався для створення презентації на основі пояснювальної записки.
  
• 
  Microsoft Project — система управління проектами, розроблена корпорацією Microsoft. Microsoft Project створений, щоб допомогти менеджерові проекту в розробці планів, розподілі ресурсів за завданнями, відстежуванні прогресу і аналізі обсягів робіт. Використовувався для створення календарного планування, планування ресурсів проекту та побудови діаграми Ганта.
  

• 
  Draw.io – онлайн програма для побудави діаграм. Draw.io має великий набір фігур, шаблони для малювання діаграм UML. Наявна велика кількість налаштувань текстів і фігур. Draw.io використовувався для створення UML-діаграм.
  
• 
  Moqups – програма для проектування інтерфейсу користувача.
  

Специфікація проекту

Встановлення вимог

Спрощений зміст технічного завдання (документ опису вимог):

1. 
   Загальні відомості:
   

• 
  повне найменування роботи – Автоматизована система житлоуправління з обліку мешканців та їх розрахунків.
  
• 
  умовне позначення – BSS
  
• 
  замовник – Україна
  
• 
  розробник системи – компанія “Bestation Software”
  
• 
  початок розробки проекту – Пн 04.02.19
  
• 
  кінець розробки проекту – Чт 21.01.21
  
• 
  відомості про джерела фінансування робіт – кошти з державного бюджету
  
• 
  порядок фінансування робіт – фінансування робіт відбувається згідно з договором №141626 між компанією - розробником та компанією - замовником.
  

2. 
   Призначення та цілі створення ПЗ:
   

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

3. 
   Характеристика об’єктів автоматизації:
   

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

4. 
   Вимоги до ПЗ в цілому:
   

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

5. 
   Функціональні вимоги, які виконуються ПЗ:
   

• 
  режим функціонування – цілодобовий
  
• 
  діагностування системи – погодинне діагностування системи
  

6. 
   Вимоги до видів забезпечення:
   

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

7. 
   Склад та зміст робіт зі створення системи:
   

• 
  перелік етапів – Специфікація(Постановка завдання (фіксація мети проекту), Планування (вироблення плану і бюджету), Визначення основних віх, Набір та відбір кадрів), Розроблення(Розробка інтерфейсу, Розробка модулів обробки даних, Розробка структури бази даних, Заповнення бази даних), Тестування(Комплексне тестування, Налагодження програмного комплексу, Контрольне тестування і виправлення помилок, Складання програмної документації), Супровід(Впровадження автоматизованої системи в масси, Розвиток ПЗ відповідно до потреб замовника)
  
• 
  терміни – з 04.02.19 по 21.01.21
  
• 
  результати – значне підвищення комфортності життя людей за рахунок спрощення їх розрахунків у сфері послуг та полегшення перепису населення за рахунок автоматизованого обліку мешканців. Прискорення процесу отримання і обробки інформації, отримання інформації про клієнта, видах наданих послуг, його оплатах, заборгованості тощо
  
• 
  фінансування – фінансування здійснюється компанією замовником згідно договору №141626
  

8. 
   Вимоги до документування:
   

• 
  перелік документів, які підлягають розробці – програмна документація
  

9. 
   Джерела розробки:
   

• 
  Перелік літератури та посилань – ГОСТ 34.602-89; договір №141626 між компанією - замовником та компанією – розробником та ін.
  

Діаграма варіантів використання:

Діаграма варіантів використання (Рис.1)


Вербальні специфікації прецедентів (рис.1)
Специфікація прецеденту “Авторизація в системі”:

1. 
   Короткий опис:
   

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

2. 
   Суб’єкт – користувач.
   
3. 
   Передумова:
   

Користувачеві надано особисті логін та пароль.

4. 
   Основний потік:
   

1. 
   Система відображає поля під назвою “Логін” та “Пароль” і кнопку “Авторизуватися”.
   
2. 
   При коректному введенні даних система авторизує користувача.
   
3. 
   Пре неправильному введенні даних виконується А1.
   
1. 
   Альтернативні потоки:
   

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

3. 
   Постумови:
   

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

1. 
   Короткий опис:
   

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

2. 
   Суб’єкт – користувач, банк.
   
3. 
   Передумова:
   

Авторизація користувача в системі.

1. 
   Основний потік:
   

1. 
   На екрані висвітлюється меню з послугами і кнопка “замовити”.
   
2. 
   Якщо користувач не обрав жодної послуги і натиснув кнопку “замовити” то виконується A1.
   
3. 
   Якщо користувач обрав хоча б одну послугу і натиснув кнопку “замовити”, то йому висвітлюється сумарна вартість обраних послуг і кнопка “оплатити”.
   
4. 
   Якщо при натисканні кнопки “оплатити” у користувача не достатньо коштів на рахунку, то виконується А2.
   
5. 
   Якщо при натисканні кнопки “оплатити” у користувача достатньо коштів на рахунку, то банк здійснює переказ коштів з рахунку користувача на рахунок адміністрації системи.
   
6. 
   Користувачеві у форматі pdf приходить квитанція про оплату.
   

5. 
   Альтернативні потоки:
   

А1. Не обрано жодної послуги. Користувачеві висвітлюється повідомлення про те, що він не обрав жодної послуги, і дві кнопки – вийти з меню “Послуги” і спробувати ще раз щось замовити.

А2. Не достатньо коштів. Користувачеві висвітлюється повідомлення про те, що оплата не пройшла так як на його рахунку не достатньо коштів, і прохання поповнити баланс рахунку.

6. 
   Постумови:
   

Користувач успішно здійснив замовлення і оплатив його. З рахунку користувача знято відповідну суму в розмірі вартості замовлених послуг.
Специфікація прецеденту “Змінити особисті дані”:

1. 
   Короткий опис:
   

Після авторизації в системі користувач натискає кнопку “Змінити особисті дані” і переходить у відповідне меню. В даному меню є поля для заповнення і кнопка “Змінити”. Після заповнення потрібних полів користувач натискає кнопку “Змінити”. В результаті в базі даних інформація про даного користувача змінюється.

2. 
   Суб’єкт – користувач.
   
3. 
   Передумова:
   

Авторизація користувача в системі.

4. 
   Основний потік:
   

4.1 Користувач натискає кнопку “Змінити особисті дані” і потрапляє у відповідне меню.

4.2 Меню має назву “Особисті дані” і наступні поля:

1. 
   Прізвище, ім’я, по-батькові.
   
2. 
   Дата народження.
   
3. 
   Код паспорту.
   
4. 
   Адреса.
   
5. 
   Особистий номер телефону.
   
6. 
   Електронна пошта.
   
7. 
   Банківська карта.(для розрахунку за надані послуги)
   

4.3. Користувач змінює потрібні йому поля і натискає кнопку “Змінити”.

4.4. Якщо користувач натискає на кнопку “Змінити” і хоча б одне з полів введено некоректно, то виконується А1.

4.5. Якщо користувач всі необхідні поля заповнив правильно і натиснув кнопку “Змінити”, то в базі даних змінюються відповідні дані про цього користувача.

5. 
   Альтернативні потоки:
   

А1. Некоректні дані. Користувачеві висвітлюється повідомлення про некоректно введені дані і вказівка на те що саме і чому потрібно змінити

6. 
   Постумови:
   

Змінення даних користувача пройшло успішно.
Специфікація прецеденту “Вийти із системи”:

1. 
   Короткий опис:
   

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

2. 
   Суб’єкт – користувач.
   
3. 
   Передумова:
   

Закінчення роботи із системою.

4. 
   Основний потік:
   

4.1. Користувач в головному меню натискає на кнопку “Вийти”.

4.2. На екрані висвітлюється повідомлення про те, чи впевнений користувач що хоче вийти із системи, і дві кнопки з написами “Так” і “Ні”.

4.3. Якщо користувач натискає кнопку “Ні”, то виконується А1.

4.4. Якщо користувач натискає кнопку “Так”, то він успішно виходить із системи.

5. 
   Альтернативні потоки:
   

А1. Відмова виходу. Користувач потрапляє назад в головне меню.

6. 
   Постумови:
   

Користувач успішно виходить із системи.
Специфікація прецеденту “Звернутися в техпідтримку”:

1. 
   Короткий опис:
   

Після виникнення певних питань або проблем,пов’язаних з роботою в системі, користувач натискає на кнопку “Техпідтримка” і надсилає відповідний лист з проханням допомогти.

2. 
   Суб’єкт – користувач.
   
3. 
   Передумова:
   

Під час роботи із системою у користувача виникли питання, або проблеми пов’язані із роботою системи.

4. 
   Основний потік:
   

4.1. Користувач в головному меню натискає на кнопку “Техпідтримка”.

4.2. Користувач потрапляє в меню під назвою “Техпідтримка”, в якому знаходиться поле для написання електронного листа, кнопки “Відправити” і “Повернутися в головне меню”.

4.3. Після опису свого питання або своєї проблеми в листі, користувач натискає на кнопку “Відправити”, після чого потрапляє в головне меню і очікує відповіді від Техпідтримки.

4.4. Якщо користувач натискає кнопку “Повернутися в головне меню” то виконується А1.

5. 
   Альтернативні потоки:
   

А1. Зникнення необхідності відправляти лист. Користувач потрапляє назад в головне меню.

6. 
   Постумови:
   

Користувач успішно відправляє лист і очікує відповіді від Техпідтримки.
Специфікація прецеденту “Обробка замовлення”:

1. 
   Короткий опис:
   

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

2. 
   Суб’єкт – майстер, користувач.
   
3. 
   Передумова:
   

Формування заявки користувачем.

4. 
   Основний потік:
   

4.1. Майстер отримує повідомлення від системи про нову заявку.

4.2. Якщо майстер не здатний виконати завдання, то виконується А1.

4.3. Якщо майстер здатний виконати завдання, то він його виконує.

4.4. Майстер формує і надсилає звіт про успішне виконання замовлення.

5. 
   Альтернативні потоки:
   

А1. Не виконання завдання. Майстер формує і надсилає відповідний звіт, який пов'язаний із причинами невиконання завдання. Користувачу, який замовив дану послугу пропонується інший майстер або повернення затрачених коштів.

6. 
   Постумови:
   

Майстер успішно виконує замовлення користувача.
Специфікація прецеденту “Обробка заявок”:

1. 
   Короткий опис:
   

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

2. 
   Суб’єкт – працівники техпідтримки, користувач.
   
3. 
   Передумова:
   

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

4. 
   Основний потік:
   

4.1. Працівникам техпідтримки приходить повідомлення від користувача.

4.2. Повідомлення аналізується працівником техпідтримки.

4.3. Якщо працівник техпідтримки не може відповісти на питання користувача або вирішити його проблему то виконується А1.

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

5. 
   Альтернативні потоки:
   

А1. Не здатність техпідтримки допомогти. Техпідтримка надсилає повідомлення користувачу, про те що на даний момент вона не може вирішити його проблему, і прохання зачекати кілька днів, поки не знайдеться крінь проблеми.

6. 
   Постумови:
   

Проблему користувача (жильця) успішно вирішено.
Специфікація прецеденту “Формування звіту”:

1. 
   Короткий опис:
   

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

2. 
   Суб’єкт – адміністратор.
   
3. 
   Передумова:
   

Кінець місяця.

4. 
   Основний потік:
   

4.1. Адміністратор проводить повний аналіз системи.

4.2. На основі попереднього аналізу адміністратор формує звіт.

4.3. Адміністратор відправляє звіт директору.

5. 
   Постумови:
   

Звіт успішно сформовано і надіслано директору.
Календарне планування та планування ресурсів у Microsoft Project
Календарне планування у Microsoft Project (рис.2)

Планування ресурсів у Microsoft Project (рис.3)



Діаграма Ганта (рис.4)

Вербальний опис календарного планування (рис.4):

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

• 
  Складання вимог до проекту і планування - визначаються системні вимоги і виконується планування робіт;
  
• 
  Валідація - перевірка того, що продукт відповідає очікуванням і потребам користувачів.
  
• 
  Верифікація - підтвердження того, що певні вимоги були виконані.
  
• 
  Складання вимог до продукту і їх аналіз - складається повна специфікація вимог до програмного продукту;
  
• 
  Високорівневе проектування - визначається структура програмного забезпечення, взаємозв'язку між основними його компонентами і реалізовані ними функції;
  
• 
  Детальне проектування - визначається алгоритм роботи кожного компонента;
  
• 
  Кодування - виконується перетворення алгоритмів в готове програмне забезпечення;
  
• 
  Модульне тестування - виконується перевірка кожного компонента або модуля програмного продукту;
  
• 
  Інтеграційне тестування - здійснюються інтеграція програмного продукту і його тестування;
  
• 
  Системне тестування - виконується перевірка функціонування програмного продукту після поміщення його в апаратне середовище відповідно до специфікації вимог;
  
• 
  Експлуатація та супровід - запуск програмного продукту у виробництво. На цій фазі в програмний продукт можуть вноситься поправки і може виконуватися його модернізація.