Главная Коллекция "Otherreferats" Программирование, компьютеры и кибернетика Автоматизоване робоче місце підприємця: облік комп’ютерної техніки

Автоматизоване робоче місце підприємця: облік комп’ютерної техніки

Проект комплексу спеціального програмного забезпечення автоматизованого робочого місця підприємця. Вимоги замовника до продукту. Розробка моделі на основі платформи ARIS, побудова діаграми взаємодії і діяльності. Оцінка якості ПЗ інформаційної системи.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 08.12.2021
Размер файла 3,6 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

Размещено на http://www.Allbest.Ru/

Курсова робота

з дисципліни «Технологія розробки програмного забезпечення»

Тема:

Автоматизоване робоче місце підприємця: облік комп'ютерної техніки

Список використаних скорочень

ПЗ

-

програмне забезпечення;

ІС

-

інформаційна система;

СУБД

-

система управління бази даних;

БД

-

база даних;

ОС

-

операційна система;

МНПЗ

-

модель надійності програмного забезпечення;

ПК

-

персональний комп'ютер;

ЦПП

-

центральний процесорний пристрій;

ОЗП

-

оперативний запам'ятовуючий пристрій;

HDD

-

англ. Hard disk drive, жорсткий диск;

IVR

-

англ. Interactive Voice Response, інтерактивне голосове меню;

3D

-

англ. 3-dimensional, тривимірний простір;

АРМ

-

автоматизоване робоче місце;

ЗП

-

заробітна плата;

LOC

-

англ. Lines of code, рядки коду;

ТЗ

-

технічне завдання;

ПДВ

-

податок на додану вартість.

Зміст

  • Вступ
  • 1. Програмно-апаратні засоби
  • 2. Провести анкетування та скласти бланк анкети
  • 3. Список зацікавлених юридичних та фізичних осіб
  • 4. Аналіз вимог замовника до програмного продукту
  • 5. Аналіз ризиків. Функціональні та нефункціональні вимоги
  • 6. Мережева діаграма етапів проекту
  • 7. Організаційна модель на основі платформи ARIS
  • 8. Побудувати діаграми взаємодії і діяльності
  • 9. eEPC - модель
  • 10. Модель даних
  • 11. Оцінювання розміру проекту
  • 12. Загальний обсяг трудовитрат та вартості робіт
  • 13. Розрахунки показників надійності ПЗ
  • 14. Оцінка складності ПЗ
  • 15. Оцінка якості програмного забезпечення
  • 16. Використання розподіленої системи керування версіями файлів
  • Висновки
  • Список використаної літератури
  • Вступ
  • Актуальність дослідження. Протягом кількох десятиліть стоїть завдання пошуку повторюваного, передбачуваного процесу або методології, яка б поліпшила продуктивність, якість і надійність розробки. Досвід управління розробкою програм відбивається у відповідних посібниках, звичаях і стандартах. Інформатика як наукова дисципліна пропонує і використовує на базі методів структурного програмування технологію надійної розробки ПЗ, використовуючи тестування програм та їх верифікацію на основі методів доказового програмування для систематичного аналізу правильності алгоритмів і розробки програм без алгоритмічних помилок. При виборі методології розробки ПЗ слід керуватися тим, що складність методології порівнянна з складністю структури програмного продукту, і невиправдана для продукту даної складності складність методології тільки невиправдано збільшить вартість розробки. Саме тому обрана проблематика дослідження є вельми актуальною на даний момент.
  • Мета дослідження. Метою є вивчення та дослідження методологій розробки ПЗ, аналіз процесів і результатів проектування комплексу спеціального ПЗ.
  • Завдання дослідження. Досягнення мети дослідження передбачало розв'язання таких завдань:
  • - здійснити розподіл ролі в групі розробників;
  • - дослідити основні підходи до формування вимог;
  • - проаналізувати відмінність користувацьких та системних вимог;
  • - дослідити основні методики оцінки характеристик проекту ІС;
  • - дослідити основні моделі оцінки якості програмного забезпечення ІС;
  • - проаналізувати зміст діаграм процесів та часових діаграм;
  • - набути навички створення проектної документації.
  • Об'єктом дослідження є процес розроблення проекту комплексу спеціального ПЗ.
  • Предметом дослідження є особливості розроблення проекту комплексу спеціального ПЗ.
  • 1. Програмно-апаратні засоби
  • При виконанні курсової роботи було використано наступні програмно-апаратні засоби:
  • 1) Табличний процесор: Microsoft Excel 2019
  • 2) Текстовий редактор: Mircosoft Word 2019
  • 3) Онлайн-сайт для побудови діаграм: Creately

4) Інтегроване середовище розробки: Microsoft Visual Studio 201

5) Векторний редактор: Adobe Illustrator 2021

6) Програма для побудови діаграм: ARIS Express

7) Онлайн-сайт для побудови часових діаграм: GanttPRO

8) Власний ПК

2. Провести анкетування та скласти бланк анкети

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

Частина 2: Оцінка проблеми. Чому існує така проблема, як вона вирішується в даний час і як замовник хотів би її вирішити.

Частина 3: Розуміння середовища користувача. Хто такі користувачі, яка в них освіта, які в них навики в комп'ютерній області, чи мають вони досвід роботи з даним типом застосувань (додатків), яка платформа використовується, які замовник хоче використовувати платформи в майбутньому.

Частина 4: Резюме. Повторити за замовником те, що він говорив, щоб він зрозумів, чи правильно була зрозуміла інформація дана ним.

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

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

Частина 7: Оцінка можливості розповсюдження. Хто в організації потребує дане застосування, скільки користувачів буде використовувати дане застосування.

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

Частина 9: Інші вимоги. Вимоги законодавства, інформаційного середовища, інструкція та стандарти які мають бути підтримані.

Частина 10: Закінчення. Запитують чи існують питання, на які не дали відповіді (які не були задані).

Частина 11: Висновок аналітика.

Анкета

Частина 1. Визначення профілю замовника.

1. Ім'я

2. Компанія

3. Галузі

4. Продукція, яку продаєте

5. Які основні проблеми, що виникають в вашій діяльності

6. Як спростити вашу роботу, діяльність

Частина 2. Оцінка проблеми

7. Основні проблеми, у вирішенні яких ви потребуєте допомоги

8. Назвіть ці проблеми і чому вони існують

9. Як ви їх вирішуєте на даний момент і як би ви хотіли їх вирішити

Частина 3: Розуміння середовища користувача

10. Вкажіть, хто ваші користувачі

11. Освіта, яку вони мають

12. Навички, які вони мають у комп'ютерній сфері

13. Платформи, які ви використовуєте

14. Ваші подальші плани стосовно цих платформ

15. Чи використовуєте ви інші додатки до даного додатку(якщо так то розкажіть про них)

16. Очікування замовника відносно даного продукту

17. Приблизний термін для навчання володіння ПЗ

18. Вигляд, в якому повинна надаватися додаткова інформація для користувача

Частина 4: Резюме

Частина 5: Пропозиції аналітика стосовно проблеми замовника

Частина 6: Оцінка рішення, що було запропоноване

19. Чи погоджуєтесь з запропонованими рішеннями

Частина 7: Оцінка можливості розповсюдження

20. Хто в організації потребує дане застосування

21. Скільки користувачів буде використовувати дане застосування

Частина 8: Оцінка необхідного рівня надійності і продуктивності

22. Ваші очікування стосовно надійності проекту

23. Якою по вашому повинна бути продуктивність

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

25. Які ваші вимоги стосовно безпеки

26. Чи існують спеціальні вимоги до ліцензування

27. Як буде розподілене ПЗ

Частина 9: Інші вимоги

28. Інші вимоги, які мають бути підтримані (законодавства, інформаційного середовища, інструкція та стандарти)

Частина 10: Закінчення

29. Чи існують питання, які не були задані? Наведіть їх та дайте відповідь

Частина 11: Висновок аналітика

3. Список зацікавлених юридичних та фізичних осіб

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

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

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

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

Лідер проекту. Це найбільш авторитетна людина в команді проекту, до чиєї думки прислухаються, той хто приймає більшість технічних рішень по ходу проекту. Часто лідер і менеджер проекту - одна особа.

Замовник. Ця особа або організація, які отримують результати проекту у власність того чи іншого виду.

Користувачі. Це особи і організації, безпосередньо використовують результати проекту в своєї діяльності.

Організація-виконавець. Це організація, в якій проводиться проект і яка несе відповідальність перед замовником за його виконання. Така організація може бути створена для проведення одного конкретного проекту і складатися тільки з його команди.

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

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

Рис. 1 - Взаємини між зацікавленими особами проекту

4. Аналіз вимог замовника до програмного продукту

Що має робити система?

1) Вести облік комп'ютерної техніки з можливістю зміни типу товарів під потреби організації.

2) Вести облік послуг з постачання, встановлення, налагодження, налаштування комп'ютерної техніки фізичним та юридичним особам.

3) Вести облік клієнтів і постачальників товарів.

4) Складати відповідні документи та звіти, проводити форматизацію, автоматизоване редагування та друк.

5) Вести облік погодинної, відрядної оплати праці співробітників, усіх видів відрахувань, податків та утримань.

6) Розраховувати заробітну плату, посадові оклади працівників.

Модель даних:

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

Платформа:

Програмний продукт повинен підтримувати роботу в рамках ОС сімейства Windows.

Варіанти використання:

1. Простий зручний інтерфейс для користувача.

2. Висока надійність та живучість.

3. Всі документи генеруються в Excel.

Користувачі системи:

1. Працівники фінансового відділу.

2. Менеджери компанії.

3. Фахівці з постачання та закупівель.

Рівень знань персоналу - користувач ПК.

Принцип побудови:

1. Програмгий продукт має бути побудований на будь-якій зручній для розробників мові програмування.

2. Всі документи та звіти формуються на основі Excel шаблонів, починаючи з версії Excel 2003.

3. Всі платежі та нарахування коштів здійснюються в режимі реального часу.

Вимоги до функціональних характеристик:

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

2. Облік надходжень і витрат товару.

3. Облік товару на складі в наявності.

4. Облік наданих послуг.

5. Облік виконаних робіт.

6. Нарахування зарплати працівникам організації з почасовою і відрядною формою оплати праці.

7. Облік руху грошей у будь-якій формі (банк, каса).

8. Формування звітних і первинних документів (прайс-лист, товар в наявності на складі, книга продажів та покупок за даний інтервал дат, платіжне доручення, рахунок, рахунок-фактура, накладні, прибутковий касовий ордер, акт виконаних робіт, товарний чек).

Вимоги до інтерфейсу:

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

Ергономічні характеристики:

1. Користувач додатку не повинен бути прив'язаний до робочого місця та повинен мати змогу працювати з наданою інформацією дистанційно.

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

3. Автоматичне структурування даних на каталоги та підкаталоги для розділів документації.

Вимоги до програмного алгоритму:

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

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

3. Використання в умовах алгоритмічної обробки даних переважно арифметичних та логічних операцій.

Вимоги до надійності:

1. Реалізація функцій автозбереження, збереження через задану кількість хвилин, створення резервної копії даних.

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

3. Мати засоби, що забезпечують захист бази даних від несанкціонованого доступу.

Вимоги до програмної сумісності:

1. Сумісність ПЗ із Microsoft Excel (версії 2003-2019).

2. Можливість роботи з БД на основі Microsoft Access, MySQL.

3. Експорт даних в файл txt-формату.

4. Підтримка веб-браузерів.

5. Аналіз ризиків. Функціональні та нефункціональні вимоги

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

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

1. Ризики для проекту, які впливають на графік робіт або ресурси, необхідні для виконання проекту.

2. Ризики для розроблювального продукту, що впливають на якість або продуктивність розроблювального програмного продукту.

3. Бізнес-ризики, що ставляться до організації-розроблювачеві або постачальникам. Конкретні типи ризиків, які можуть вплинути на даний проект, залежать від виду створюваного програмного продукту й від організаційного оточення, де реалізується програмний проект. Разом з тим багато типів ризиків здатні вплинути на будь-які програмні проекти, ці ризики наведені в таблиці.

Таблиця 1

Можливі ризики програмних проектів

Ризик

Типи ризику

Опис ризику

Плинність розроблювачів

Ризик для проекту

Досвідчені розроблювачі залишають проект до його завершення

Зміна в управлінні організацією

Ризик для проекту

Організація міняє свої пріоритети в управління проектом

Неготовність апаратних засобів

Ризик для проекту

Апаратні засоби, які необхідні для проекту, не зробили вчасно або не готові до експлуатації

Зміна вимог

Ризик для проекту й для розроблювального продукту

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

Недооцінка розміру розроблювальної системи

Ризик для проекту й для розроблювального продукту

Розмір системи значно перевищив первісну оцінку

Недостатня ефективність case-засобів

Ризик для розроблювального продукту

Case-засоби, призначені для підтримки проекту, виявилися менш ефективними, чим очікувалося

Зміни в технології розробки ПЗ

Бізнес-Ризик

Основні технології побудови програмної системи заміняються новими

Поява конкуруючого програмного продукту

Бізнес-Ризик

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

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

1. Імовірність ризику вважається дуже низкою, якщо вона має значення менш 10%; низкою, якщо її значення від 10 до 25%; середньою при значеннях від 25 до 50%; високою, якщо значення коливається від 50 до 75%; дуже високою при значеннях більш 75%.

2. Можливий збиток від ризикових ситуацій можна підрозділити на катастрофічний, серйозний, терпимий та незначний.

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

Таблиця 2

Аналіз ризиків проекту

Ризик

Імовірність

Ступінь збитку

Проблемний інтерфейс користувача знижує ефективність роботи

3-5% (дуже низька)

Терпима

Неможливо підібрати працівників із професійним рівнем, що вимагається

50% (висока)

Катастрофічна

Виникнення критичної програмної помилки

4-8% (дуже низька)

Серйозна

Помилки перетворення даних призводять до надмірних обрахунків

3% (дуже низька)

Терпима

СУБД втрачає дані

11% (низька)

Катастрофічна

Недооцінки часу виконання проекту

70-75% (дуже висока)

Серйозна

Виникнення дифіциту процессорної пам'яті

2% (дуже низька)

Катастрофічна

Відстеження небезпечної функції як безпечної

25% (середня)

Терпима

Відстеження безпечної функції як небезпечної

25% (середня)

Терпима

Апаратні затримки знижують продуктивність

5-10% (низька)

Серйозна

Розмір системи значно перевищує спочатку розрахований

50% (висока)

Терпима

Планування ризиків полягає у визначенні стратегії керування кожним значимим ризиком, відібраним для моніторингу після аналізу ризиків. Тут також не існує загальноприйнятих підходів для розробки таких стратегій - багато чого ґрунтується на «чуття» і досвіді менеджера проекту.

Існує три категорії стратегій управління ризиками.

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

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

3. Планування «аварійних» ситуацій. Згідно із цими стратегіями необхідно мати план заходів, які слід виконати у випадку прояву ризикової ситуації. У табл. 7 це стратегія поведінки при виникненні фінансових проблем в організації-розроблювача.

Таблиця 3

Стратегії управління ризиками проекту

Ризик

Стратегія

Фінансові проблеми організації

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

Невдалі програмні рішення

Експертна оцінка програмного проекту досвідченим стороннім консультантом; використання "шаблонних" рішень з вдалих попередніх програмних проектів при управлінні ризиками розроблення ПЗ.

Проблеми некваліфікованого персоналу

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

Дефектні системні компоненти

Замовлення частини компонент розроблюваного ПЗ в компаній-підрядників.

Зміни вимог

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

Реорганізація компанії-розроблювача

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

Недостатня продуктивність бази даних

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

Недооцінки часу виконання проекту

Використання сучасних генераторів програмного коду з можливістю його адаптації до архітектури ПЗ.

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

Функціональні вимоги:

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

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

3. Облік надходжень і витрат товару.

4. Облік товару на складі в наявності.

5. Облік наданих послуг.

6. Облік виконаних робіт.

7. Нарахування зарплати працівникам організації з почасовою і відрядною формою оплати праці.

8. Облік руху грошей у будь-якій формі (банк, каса).

9. Формування звітних і первинних документів (прайс-лист, товар в наявності на складі, книга продажів та покупок за даний інтервал дат, платіжне доручення, рахунок, рахунок-фактура, накладні, прибутковий касовий ордер, акт виконаних робіт, товарний чек).

Нефункціональні вимоги (англ. Non-Functional Requirements) -- це вимоги до програмного забезпечення, які задають критерії для оцінки якості його роботи. На відміну від функціональних вимог, які визначають що система повинна робити, нефункціональні вимоги визначають якою система повинна бути. Нефункціональні вимоги до програмного забезпечення визначаються на першій стадії процесу розробки ПЗ -- на етапі аналізу вимог.

Нефункціональні вимоги можна поділити на такі категорії: апаратні та програмні вимоги, вимоги до інтерфейсу та організаційні вимоги.

Нефункціональні вимоги:

1. Апаратні та програмні вимоги:

- центральний процесор (ЦПП) - не гірше 2Core x 2,0 GHz;

- оперативна пам'ять (ОЗП) - не менше 2 Gb;

- вільне місце на жорсткому диску (HDD) - не менше 5 Gb;

- мережевий порт - не менше 10Mbit;

- склад наявного програмного забезпечення повинен містити: ОС Microsoft Windows 7(8, 10) 32(64) bit; антивірусне програмне забезпечення Eset NOD 32 (або аналогічне);

2. Організаційні вимоги:

- розробка системи повинна виконуватися будь-якою зручною мовою для розробника;

- програмне забезпечення повинно використовуватися на автоматизованому робочому місці користувача з урахуванням вимог Закону України «Про захист інформації в інформаційно-телекомунікаційних системах».

3. Вимоги до інтерфейсу:

- система повинна взаємодіяти з іншими системами (мережа Інтернет, онлайн банкінг;

- система повинна бути сумісною з потребами та можливостями користувача;

- система повинна забезпечувати простоту переходу від виконання однієї функції до іншої;

- система буде прийнятна для користувачів (адміністраторів) або замовника;

- система повинна забезпечувати користувача на високому рівні вказівками стосовно його можливих дій, а також генерувати належний зворотний зв'язок на його запити;

- реакція системи на всі типи запитів також повинна бути однозначною і зрозумілою і, по можливості, простою;

- інтерфейс не повинен містити зайвих декоративних деталей, які відволікають від головної задачі;

- система не повинна розкривати конфіденційної інформації про дані в системі.

6. Мережева діаграма етапів проекту

Побудова моделі керування проектом починається з визначення всіх етапів проекту, залежних етапів, визначення тривалості етапів. Результати занесено в Таблицю 4.

Таблиця 4

Етапи проекту розроблення ПЗ.

Код

Назва етапу

Попередній етап

Тривалість (Діб)

Т1

Формулювання цілей та склад ПЗ

-

14

Т2

Збір та аналіз вимог

Т1

14

Т3

Розробка архітектури

Т2

42

Т4

Первинне планування

Т3

14

Т5

Реалізація прототипу та випробовування

Т4

42

Т6

Аналіз результату випробувань та зміни в проекті

Т5

11

Т7

Розробка та налаштування інтерфейсу для користувачів

Т6

21

Т8

Реалізація

Т7

42

Т9

Тестування

Т8

21

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

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

Таблиця 5

Розподіл виконавців по етапах

Етап

Виконавець

Т1

Артур

Т2

Кирилл

Т3

Кирилл, Семен

Т4

Артур

Т5

Артур, Семен

Т6

Кирилл

Т7

Семен

Т8

Артур, Кирилл

Т9

Семен

За цими даними, та згідно часового розподілу будуємо діаграму розподілу

Рис. 2 - Часова діаграма етапів проекту та розподілу працівників по етапах

Побудова мережевої діаграми. Мережева діаграма - це графічне відображення робіт проекту та їхніх взаємозв'язків. Мережа - це повний комплекс робіт проекту із встановленими між ними зв'язками. Ці зв'язки показані в Таблиці 6.

Таблиця 6

Залежність етапів проекту

Етап

Тривалість (Діб)

Залежність

Т1

14

-

Т2

14

-

Т3

42

Т2(М1)

Т4

14

-

Т5

42

Т4(М2)

Т6

11

Т5(М3)

Т7

21

Т6(М4)

Т8

42

Т7

Т9

21

Т8(М5)

За даними цієї таблиці будуємо мережеву діаграму. Контрольні оцінки й контрольні проектні елементи показані у вигляді овалів і позначені (як і в табл. 2) буквою М з відповідним номером.

Рис. 3 - Мережева діаграма проекту

Початок розробки ПЗ заплановано розпочати з 24.11.2020, а кінець 17.06.2021. Тривалість розробки ПЗ очікується в 205 діб.

7. Організаційна модель на основі платформи ARIS

Рис. 4 - Організаційна структура компанії

Опис моделі:

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

Компанія IT-Blok вже більше 16 років є одним з лідерів на ринку комп'ютерної техніки. Тут можна придбати готові комп'ютери, комплектуючі, периферію, аксесуари для комп'ютера і багато іншого.

- Керівник компанії - генеральний директор (виділений зеленим кольором на моделі).

- В компанії функціонує 6 відділів (виділені червоним кольором та курсивом на моделі). Кожний відділ очолює відповідальна особа (виділена синім кольором та підкреслена на моделі):

· відділ обслуговування клієнтів;

· комерційний відділ;

· фінансовий відділ;

· відділ закупівель та постачання;

· технічний відділ;

· відділ обслуговування обладнання.

Таблиця 7

Відповідальні особи функціонуючих відділів компанії «IT-BLOK»

№

Відділ

Відповідальна особа

1

Обслуговування клієнтів

Головний менеджер

2

Комерційний

Начальник відділу

3

Фінансовий

Головний фінансист

4

Закупівель і постачання

Начальник відділу

5

Технічний

Начальник відділу

6

Обслуговування обладнання

Головний інженер

Таблиця 8

Працівники функціонуючих відділів компанії «IT-BLOK»

Відділ

Працівники

Обслуговування клієнтів

Перший заступник, консультант, менеджер, оператор зв'язку

Комерційний

Спеціаліст з продажів, менеджер з питань регіональног розвитку

Фінансовий

Фінансист, бухгалтер, помічник бухгалтеру

Закупівель і постачання

Провідний фахівець із закупівель, фахівець із постачання, товарознавець

Технічний

Адміністратор БД, заступник, технік, системний адміністратор

Обслуговування обладнання

Лаборант, інженер, оператор, механік-водій

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

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

Фінансовий відділ відповідає за розрахунки заробітної платні працівникам, планування фінансових витрат, проплату різних рахунків підприємства, отримання проплати рахунків клієнтів.

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

Технічний відділ відповідає за наявність та справність технічних засобів (приладів) підприємства. Співробітники відділу впроваджують новітні технології проектування у виробничих відділах інституту, у тому числі - 3D проектувань з використанням останніх світових досягнень в цій області.

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

8. Побудувати діаграми взаємодії і діяльності

Діаграма взаємодії - це діаграма, на якій представлено взаємодію, що складається з множини об'єктів і відносин між ними, включаючи і повідомлення, якими вони обмінюються.

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

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

Рис. 5.1 - Діаграма взаємодії компанії з клієнтом у веб просторі

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

Рис. 5.2 - Діаграма взаємодії менеджеру з підлеглим

Із всієї можливої керуючої інформації два її види мають істотне значення. По-перше, це умова, що показує в якому випадку посилається повідомлення. Наприклад, можна ввести умову: [Звіт застарів() = true]. Тоді запит на оновлення звіту буде посилатися тільки при виконанні цієї умови. По-друге, корисним керуючим маркером є маркер ітерації, який показує, що повідомлення посилається багато разів для множини об'єктів-адресатів (наприклад, *оновити).

Діаграма діяльності

Рис. 6.1 - Діаграма діяльності (замовлення техніки)

Рис. 6.2 - Діаграма діяльності (запит повернення техніки)

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

Переваги діаграми діяльності:

ь Дозволяє автоматизувати замовлення;

ь Формує довідники необхідні для роботи: з замовником, постачальником, товаром (продуктами);

ь Дозволяє автоматизувати створення документації підприємства;

ь Автоматизує складський облік.

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

9. eEPC - модель

Рис. 7 - Опис процесів компанії “IT-BLOK”

Нотація ARIS eEPC розшифровується як - extended Event Process Chain - розширений ланцюг процесу, керуючий подіями.

Опис моделі:

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

Початок роботи та ініціалізація

Рис. 8 - Опис початкових процесів

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

Система надає право менеджеру проводити такі процедури:

· оформлення нового замовлення;

· оформлення заявки на повернення комплектуючих;

Процес оформлення нового замовлення:

Замовлення має 4 розгалуження:

· замовлення на обслуговування комп'ютера/комплектуючого;

· замовлення на купівлю комп'ютера/комплектуючого;

· замовлення на встановлення комп'ютера/комплектуючого;

· замовлення на повернення комп'ютера/комплектуючого;

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

Рис. 9 - Опис процесів оформлення нового замовлення

Кінцевий результат робочого процесу зберігається у:

· БД даних менеджерів;

· БД товарів;

· БД замовлень;

· БД договорів;

· БД послуг.

Процес оформлення заявки на повернення запчастин:

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

? встановлення причини повернення комплектуючих;

? оформлення заявки на повернення комплектуючих;

? повернення коштів клієнту;

Рис. 9 - Опис процесів оформлення за'явки на повернення комплектуючих

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

програмний забезпечення автоматизований робочий місце

Модель даних

Рис. 10 - Модель даних ІС «АРМ підприємця»

Опис моделі

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

Загалом система має 7 баз даних для збереження інформації про товари, замовлення, послуги, контрагентів, укладені договори та працівників організації. Основною БД має назву «Замовлення» так як включає дані з інших БД системи.

БД «Менеджер»

Рис. 11 - Модель БД «Менеджер»

БД «Менеджер» включає атрибути:

· Код менеджера (первинний ключ);

· Код працівника (зовнішній ключ);

· Логін;

· Пароль;

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

Первинний ключ «Код менеджера» дозволяє БД «Замовлення» отримувати дані про дані менеджера. Зовнішній ключ «Код працівника» дозволяє отримувати дані про особисту інформацію менеджера (ПІБ, посада та ін.).

БД «Замовлення»

БД «Замовлення» включає атрибути:

· Номер замовлення (первинний ключ);

· Код менеджера (зовнішній ключ);

· Код товару (зовнішній ключ);

· Код контрагента (зовнішній ключ);

· Код послуги (зовнішній ключ);

· Стан замовлення - на якому етапі виконання знаходиться замовлення (заявка оформлена, на складі, доставляється, очікує на пошті, обслуговується, виконана, відмінена);

· Дата замовлення - дата коли було зроблено замовлення;

· Дата виконання - дата до якої має бути виконане замовлення;

· Спосіб доставки (самовивіз зі складу, відправлення поштою, доставка від компанії);

· Спосіб оплати (готівковий розрахунок, на банківський рахунок);

· Адреса доставки - адреса клієнта(вказується при виборі способу доставки поштою або курєром).

Ця БД необхідна для оформлення замовлення в системі. Після заповнення відповідних даних для заповнення заявки, її перевірки та оплати клієнтом, стан замовлення змінюється на «Заявка оформлена», що ініціює процес виконання замовлення.

Первинний ключ «Номер замовлення» забезпечує унікальність заявки. Зовнішні ключі «Код менеджера», «Код товару», «Код контрагента», «Код послуги» дають змогу звертатися до атрибутів відповідних БД для оформлення за'явки.

Рис. 12 - Модель БД «Замовлення»

БД «Товари»

Ця БД необхідна для ведення обліку надходжень та витрат товару. Структура дозволяє вести облік будь-якого товару.

Рис. 13 - Модель БД «Товари»

БД «Товари» включає атрибути:

· Код товару (первинний ключ);

· Найменування товару;

· Тип товару;

· Ціна товару;

· Модель - для визначення різновидів техніки;

· Місце знаходження (в наявності, очікується поставка, немає в наявності).

БД «Контрагенти»

Ця БД необхідна для ведення обліку клієнтів та постачальників компанії. Перед замовленням товару чи послуги, дані про контрагента заносяться до БД. Також є можливість використання як архів для швидкого пошуку і відбору необхідних даних.

БД «Контрагенти» включає атрибути:

· Код контрагнета (первинний ключ);

· Роль (клієнт, постійний клієнт, постачальник);

· ПІБ;

· Номер телефону;

· Адреса;

Рис. 14 - Модель БД «Контрагенти»

БД «Працівники»

Ця БД необхідна для ведення обліку працівників організації, їхніх корпоративних та особистих даних.

Рис. 15 - Модель БД «Працівники»

БД «Працівники» включає атрибути:

· Код працівника (первинний ключ);

· ПІБ;

· Посада - відповідна посада в організації;

· Відділ - назва відділу компанії працівника;

· Дата найму;

· Дата звільнення;

· Номер банківського рахуну - номер рахунку на який здійснюється нарахування зарплатні працівнику.

БД «Послуги»

Ця БД необхідна для ведення обліку послуг та робіт, які надаються компанією «IT-BLOK».

Рис. 16 - Модель БД «Послуги»

БД «Послуги» включає атрибути:

· Код послуги (первинний ключ);

· Найменування послуги (виклик майстра, встановлення додаткового ПЗ, тощо);

· Ціна послуги;

БД «Договори»

Ця БД необхідна для ведення обліку та збереження укладених договорів з контрагентами для ведення звітності роботи компанії та архіву. Перед оформленням замовлення система перевіряє наявність укладених договорів з вказаним клієнтом чи постачальником для перевірки відповідності замовленння.

БД «Договори» включає атрибути:

· Код договору (первинний ключ);

· Код контрагента (зовнішній ключ);

· Найменування - назва документа (платіжне доручення, рахунок, накладна, товарний чек, тощо).

Рис. 17 - Модель БД «Договори»

Зовнішній ключ «Код контрагента» дозволяє звертатися до атрибутів БД «Контрагенти» для швидкого відбору та сортування договорів з конкретним контрагентом.

11. Оцінювання розміру проекту

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

Відповідно, очікувана LOC-оцінка всієї програми буде сумою очікуваних LOC-оцінок всіх її функцій.

Показник LOC залежить від мови програмування. Це оціночна метрика. Вона може призвести до оптимізації кількості рядків коду, а не проекту в цілому. Дозволяє спрогнозувати трудовитрати, час і вартість розробки, а також необхідну кількість програмістів для виконання проекту. LOC-оцінка впливає на оцінку величини змін обсягу коду в часі.

Програма повинна мати 14 функцій для виконання функціональних вимог проекту. Обчислимо LOC-оцінку для кожної.

Функції ведення БД:

1) Товарів: ;

2) Послуг: ;

3) Контрагентів: ;

4) Укладених договорів: ;

5) Працівників організації:;

Функції обліку:

6) Надходжень і витрат товару:

;

7) Товару на складі в наявності:

;

8) Наданих послуг:;

9) Виконаних робіт:;

10) Руху грошей: ;

Функції нарахування зарплати працівникам:

11) З почасовою формою оплати:

;

12) З відрядною формою оплати:

;

13) Функція формування звітних і первинних документів:

;

14) Інтерфейс: .

Відповідно, очікувана LOC-оцінка всієї програми буде сумою очікуваних LOC-оцінок всіх її функцій:

.

Загальна оцінка LOC: 6485 рядків коду програми.

12. Загальний обсяг трудовитрат та вартості робіт

Оцінка робіт з написання коду:

Створення утиліти установки;

Створення утиліти конфігурації (можливо, їх буде кілька: первинна настройка, настройка системних параметрів, налаштування безпеки);

Створення утиліти первинної заливки даних і, можливо, утиліту міграції на нову версію;

Створення утиліт діагностики (утиліти, які допоможуть перевірити, чи всі встановлено правильно, і допоможуть виявляти несправності);

Створення модуля протоколювання (логування). Навіть якщо замовнику він не потрібен - він значною мірою допоможе виявляти помилки і недоліки;

Створення модуля безпеки.

Цифри і коефіцієнти з статистики:

Введення в проект співробітника і установки йому середовища розробки заплановано не менше 40 годин (1 тиждень).

Щотижневі зустрічі розробників - 4 години щотижня для кожного розробника.

Первинна установка рішення на тестовий сервер - планується 80 годин (2 тижні).

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

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

Перша установка в тестове середовище замовника - 40 годин.

Перша установка в робоче середовище замовника - 40 годин.

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

Доопрацювання та виправлення несправностей (refactoring) - 25% від розробки.

Завдання по тестуванню 30-50% від часу, витраченого на розробку (розробку документа вимог, розробку ТЗ, функціоналу та інше).

Час на ризики - принаймні, 10% від загального часу.

Час на зміни - принаймні, 10% від загального часу.

Управління проектом - 15% від усього часу проекту.

Аналітик в середньому (з статистики розробки ПЗ по Україні) створює 1 сторінку затвердженої документації за 3 години.

Розрахунок для даного проекту

Проаналізувавши завдання на розробку (включаючи проектування), вийшло 1200 годин на людину.

Прийнято рішення, що завдання по розробці вестимуть 3 розробника. Тоді роботи по розробці займатимуть 10 тижнів.

Необхідно написати і погодити багато документації, що включає вимоги, ТЗ, архітектуру рішення, інструкції користувачам та інше. Загальний обсяг на виході - 400 сторінок.

АРМ має складну бізнес-логіку, тому тестування ПЗ вимагатиме більше часу (отже беремо 40% від розробки).

Плануємо 5 зустрічей із замовником для виявлення вимог.

Плануємо 3 зустрічі із замовником для узгодження рішень проекту.

Плануємо 4 демонстрації продукту замовнику на етапах розробки.

Плануємо 10 поставок на тестове середовище замовника.

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

- 3 розробника;

- 1 тест інженер;

- 1 бізнес-аналітик;

- 1 системний аналітик (архітектор, він же буде виконувати інфраструктурні завдання);

- 1 керівник проекту.

Завдання і їх час на виконання:

Таблиця 9

Розрахунок загального обсягу трудовитрат компанії

Завдання

Ролі

Кількість осіб

Час

Загалом

Етап аналізу і збору вимог

Керівник, аналітик

2

2 доби

48 годин

Зустрічі із замовником для проведення інтерв'ю та доповіді про результати

Керівник, аналітик, архітектор

3

5 разів х 4 години

60 годин

Написання документа вимог

Аналітик, архітектор

2

3 години

6 годин

Тестування вимог

Тест інженер

1

12 годин

12 годин

Написання та погодження договору та інших ініціюючих проектних документів

Керівник проекту

1

6 годин

6 годин

Проектування рішення

Написання ТЗ + затвердження

Аналітик, архітектор

2

1 тиждень

164 години

Написання архітектури рішення

Архітектор

1

40 годин

40 годин

Тестування ТЗ і архітектури рішення

Тест інженер

1

10 годин

10 годин

Навчання фахівців з предметної області

Усі

7

40 годин

280 годин

Встановлення середовищ розробки

Архітектор, розробники

4

16 годин

64 години

Встановлення середовища тестування

Тест інженер або архітектор

1

40 годин

40 годин

Написання тест-плану і варіантів тестування системи

Тест інженер

1

10 годин

10 годин

Зустрічі із замовником

Керівник, аналітик, архітектор

3

3 рази по 4 години

36 годин

Розробка і внутрішнє тестування

Щотижневі зустрічі розробників

Архітектор, розробники

4

10 зустрічей по 4 години

160 годин

Програмування

Розробники

3

400 годин

1200 годин

Поліпшення коду

Архітектор

1

3 етапи по 100 годин

300 годин

Підготовка демонстрації

Архітектор

1

4 демонстрації по 8 годин

32 години

Проведення демонстрації

Архітектор, керівник проекту, аналітик

3

3 рази по 4 години

36 годин

Завдання тест-інженера (проходження тест кейсів)

Тест-інженер

1

10 етапів по 48 годин

480 годин

Перше встановлення рішення в середовищі тестування

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены