Автоматизоване робоче місце підприємця: облік комп’ютерної техніки
Проект комплексу спеціального програмного забезпечення автоматизованого робочого місця підприємця. Вимоги замовника до продукту. Розробка моделі на основі платформи ARIS, побудова діаграми взаємодії і діяльності. Оцінка якості ПЗ інформаційної системи.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | украинский |
| Дата добавления | 08.12.2021 |
| Размер файла | 3,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
фахівець з тестування або архітектор
1
40 годин
40 годин
Тестування з боку замовника
Перше встановлення рішення в середовищі тестування
Архітектор
1
40 годин
40 годин
Постачання бета версій
Архітектор
1
10 поставок по 8 годин
80 годин
Доопрацювання та виправлення несправностей
Розробники
2
25% від розробки
300 годин
Впровадження
Установка на працюючий сервер
Архітектор
1
3 рази по 4 години
12 годин
Навчання користувачів
Аналітик
1
3 рази по 4 години
12 годин
Написання документації
Аналітик
1
405 сторінок по 3 на кожну
1080 годин
Перевірка документації
Тест-інженер
1
30% від її написання
320 годин
Разом
4868 годин
Додатково
Час на ризики
10% від розробки
120 годин
Час на зміни
10% від розробки
120 годин
Управління проектом
Керівник проекту
1
10% від проекту
487 годин
Всього
Приблизно: 5575 годин
Розрахунок вартості робіт
Згідно методики оцінювання вартості робіт, кінцева формула визначається як:
Година = ЗП / 45,
Де ЗП - це середня зарплата групи розробників, зайнятих у проекті, а число 45 - це обчислене відношення собівартості години роботи до повної зарплати розробника за місяць.
Зміст робіт по розробці ПЗ складається з:
· аналізу вимог, проектування можливостей ПЗ;
· проектування архітектури та інтерфейсів;
· розробка документації та плану інтеграції;
· кодування та збирання ПЗ;
· тестування продукту;
· інсталяція, кваліфікаційний тест;
· супровід (рефакторинг, виправлення коду, підтримка версійності) - 30% від ємності.
Про 30% від ємності. Багато компаній-розробників не включають супровід до складу робіт і, відповідно, в фінальну вартість. В результаті замовник додатково сплачує за будь-який баг або за найменше виправлення коду.
Ми вважаємо за краще працювати з високим ступенем відповідальності, поставляти клієнтам, так би мовити, «софт під ключ» і забезпечувати повну технічну підтримку, бо розробляти складне ПЗ, працюючи за принципом аутсорсингу - несерйозно. За даними статистики, клієнти швидше погодяться платити за підтримку понад необхідного, ніж звалювати на себе проблеми із супроводу коду.
Оплата праці включає:
ь зарплата, включаючи ПДВ 13%;
ь премія - зробив все в термін, клієнтові подобається - отримай премію;
ь виплати в пенсійний фонд і фонд соціального страхування 14% (соціальний податок для розробників ПЗ - пільговий);
ь Медичне страхування 1% від зарплати;
ь Компенсація харчування 2% від зарплати.
Кількість робочих днів у році взято з виробничого календаря, прибрано 20 днів відпустки і розділено на кількість місяців. Адже у відпустці люди не працюють, а відпускні сплачуються.
Вийшло: (247-20) / 12 = 18,9 ... днів в середньому в місяць працює співробітник.
Вважаємо, що в повному робочому дні 8 годин. Тут постає завдання зрозуміти, скільки грошей витрачається на оплату праці співробітників за годину розробки. В розробку продукту, крім розробників, залучені тестувальники, проектувальники і група впровадження. Співвідношення їх зарплат таке:
Тестувальники - 50% від зарплати розробників.
Співробітники підрозділу впровадження отримують стільки ж, скільки і розробники.
Проектувальники - 75% від зарплати розробників.
Розробники в середньому 2,4 години на день супроводжують код, а 5,6 годин в день його розробляють. Тестувальники - аналогічно витрачають 5,6 годин на розробку. Проектувальники і впроваджувачі займаються всі 8 годин на день своїми роботами, що передують і завершують розробку.
Для прикладу беремо за основу зарплати програмістів Java за даними порталу Superjob.ua - 40 000 гривень на місяць - і складаємо табличку калькуляції витрат на оплату години праці співробітника в перерахунку на годину розробки:
Таблиця 10
Розрахунок вартості години розробки
|
Співробітники |
Годин роботи на час розробки |
Середня заробітня плата |
Витрат на годину(загалом) |
Витрат на годину розробки |
|
|
Проектування(керівник проекту, аналітик) |
35% |
30 000 |
264,68 |
92,75 |
|
|
Розробка(розробники) |
100% |
40 000 |
505,38 |
505,38 |
|
|
Тестування(Тест-інженер) |
50% |
20 000 |
252,92 |
121,50 |
|
|
Тестування навантаження(впровадження) |
5% |
40 000 |
353,76 |
17.7 |
|
|
впровадження(впровадження) |
5% |
40 000 |
353,76 |
17.7 |
|
|
Технічна документація(виробництво) |
5% |
20 000 |
505,38 |
25.25 |
|
|
Разом виплат співробітникам на 1 (одну) годину розробки, грн /год |
780,28 |
||||
|
Накладні і загальногосподарські витрати в перерахуванні на годину розробника, грн / год |
109.2 |
||||
|
Разом собівартість години розробки і в тому числі ПДВ |
889,48 |
||||
|
Відношення собівартості години розробки до з / п розробника |
44,9 |
Зрозуміло, що люди повинні десь сидіти (як мінімум, на стільцях, і непогано б поставити ці стільці поруч з кондиціонером), працювати з пристойною технікою, мати хороші канали зв'язку для роботи із зовнішніми програмами, серверами, командами. Співробітників повинен хтось шукати, хтось - видавати їм зарплату, хтось - стежити за офісом і так далі. Висока кваліфікація співробітників тягне за собою певний рівень витрат на їх утримання і адміністрування. Такі фактори, як «умови» і соцпакет на ринку праці відіграють не останню роль. Всі ці міркування привели до того, що в дану методологію повинні бути включені загальногосподарські та адміністративні витрати - 20% від зарплати розробників.
Цикл розробки передбачає наступні моменти:
Щоб забезпечити роботу розробника протягом години, проектувальник повинен витратити приблизно третину години на проектування вимог, тестувальник півгодини працювати над тестуванням і так далі. Наочно все це представлено в таблиці 11, і з неї ж очевидний висновок: час безпосередньої розробки вимагає години додаткових витрат.
Зазначимо, що технічні письменники, які готують документацію, отримують таку ж зарплату, як тестувальники.
Таблиця 11
Розрахунок витрат на оплату години роботи співробітника
|
Розробники |
Тестувальники |
Впровадження |
Проектування |
||
|
Заробітна плата співробітника грн/місяць |
40 000 |
20 000 |
40 000 |
30 000 |
|
|
Мед страхування 1% від ЗП |
400 |
200 |
400 |
300 |
|
|
Компенсація харчування 2% від ЗП |
800 |
400 |
800 |
600 |
|
|
Ставка соціальних податків |
14% |
14% |
14% |
14% |
|
|
Соціальні податки на співробітника, грн/місяць |
5500 |
2750 |
5500 |
4000 |
|
|
Премія 15% від ЗП |
6000 |
3000 |
6000 |
4500 |
|
|
Податки на премію |
840 |
420 |
840 |
620 |
|
|
Робочих діб на рік |
247 |
247 |
247 |
247 |
|
|
Тривалість відпустки |
20 |
20 |
20 |
20 |
|
|
Робочих діб у місяці з урахуванням відпустки, годин |
18,9 |
18,9 |
18,9 |
18,9 |
|
|
Витрат часу в день на супровід коду і підтримку в актуальному стані, годин |
2,4 |
2,4 |
|||
|
Витрат годин в день на розробку |
5,6 |
5,6 |
|||
|
Витрат годин на добу |
8,0 |
8,0 |
|||
|
Витрат на оплату праці в перерахунку на годину розробки, грн |
505,38 |
252,92 |
|||
|
Витрат на оплату праці в перерахунку на годину розробки, грн |
353,76 |
264,68 |
Точне визначення собівартості години розробки в гривні залежить, таким чином, від зарплати, яку отримує розробник в конкретній компанії. Якщо, наприклад, вважати за даними Superjob.ua (40 000 грн на місяць), то година праці розробника обійдеться роботодавцю в 889,48 грн з ПДВ.
13. Розрахунки показників надійності ПЗ
Для розрахунку показників надійності ПЗ використаємо модель Нельсона. Дана модель заснована на виконанні k-прогонів програми при тестуванні й дозволяє визначити її надійність а також враховує ймовірність вибору певного тестового набору для чергового виконання програми. Припускається, що область даних для тестування ПЗ розділяється на K взаємовиключаючих підобластей Zi.
Модель Нельсона була розроблена з врахуванням основних властивостей ПЗ та використовує методи теорії ймовірностей лише в тих випадках, коли неможливим є одержання повної інформації про той чи інший фактор. Тому її можна вважати саме математичною моделлю.
Надійність ПЗ визначають за формулою:
Де: Pi - ймовірність того, що набір даних Zi буде обраний для чергового виконання програми;
Ni - число прогнозів програми, що було виконано до моменту оцінки на Zi наборі даних; ni - кількість прогнозів, що завершилися відмовою.
Розрахунок надійності ПЗ за моделлю Нельсона:
Для тестування програми область даних була розподілена на 7 взаємовиключаючих підобластей (табл. 12).
Таблиця 12
|
№ підобласті |
Ймовірність вибору підобласті |
Кількість прогонів програми |
Кількість відмов |
|
|
1 |
0.15 |
7 |
0 |
|
|
2 |
0.07 |
10 |
2 |
|
|
3 |
0.14 |
12 |
1 |
|
|
4 |
0.21 |
5 |
0 |
|
|
5 |
0.09 |
8 |
2 |
|
|
6 |
0.28 |
14 |
0 |
|
|
7 |
0.06 |
9 |
1 |
За результатами прогонів вирахуємо показник надійності ПЗ:
Таким чином, розроблена система має високий показник надійності та може бути допущена та впроваджена до експлуатації замовником.
14. Оцінка складності ПЗ
На підставі характеристик метрики Холстеда можна визначити складність ПЗ. Метрика Холстеда відноситься до метрик, яка обчислюється на підставі аналізу числа рядків і синтаксичних елементів вихідного коду програми.
Основу метрики Холстеда становлять чотири вимірювані характеристики програми:
NUOprtr (Number of Unique Operators) - число унікальних операторів програми, включаючи символи-роздільники, імена процедур і знаки операцій (словник операторів);
NUOprnd (Number of Unique Operands) - число унікальних операндів програми (словник операндів);
NOprtr (Number of Operators) - загальне число операторів в програмі;
NOprnd (Number of Operands) - загальне число операндів в програмі.
Складність програми (Halstead Difficulty, HDiff) розраховується за формулою:
HDiff = (NUOprtr / 2) * (NOprnd / NUOprnd).
Така оцінка впливає на точність прогнозів оцінки трудомісткості та на розуміння того, наскільки інтелектуально-витратною для розробника буде та чи інша функція.
Загальний розмір ПЗ розрахований на 6485 рядків коду.
Характерисика NUOprtr приблизно розрахована в 51 унікальний оператор.
Загальне число операндів в програмі Noprnd - 12974 операндів.
Число унікальних операндів програми NUOprnd - 921 операнд.
Підставивши всі отримані дані в формулу і обчисливши її, отримаємо:
Оцінивши отримане значення складності ПЗ (357), можна зробити висновок, що розроблюване програмне забезпечення має середній рівень складності внаслідок його розміру (глобальності проекту).
Не варто забувати про оцінку зусиль програміста при розробці програми: HEff = HDiff * HPVol - вказує, наскільки ефективна праця розробника. Для її знаходження потрібно обчислити ще одну характеристику Холстеда:
HPVoc = NUOprtr + NUOprnd - словник програми.
Обчислюємо зусилля програміста при розробці програми:
Так як в команді проекту 3 розробники, то HEff показує сумарну оцінку зусиль всіх розробників, які беруть участь в розробці ПЗ.
Оцінивши отримане значення зусиль програмістів (347004), можна зробити висновок, що праця кожного програміста має високу цінність і велику ефективність розробки ПЗ.
15. Оцінка якості програмного забезпечення
Запропонований метод базується на обчисленні оцінок експертів за певним набором критеріїв, що максимально повно зображають якість ПЗ по різним параметрам. Оцінка ПЗ проводиться двома групами експертів: статичні експерти і динамічні експерти. До першої групи відносяться авторитетні фахівці із напрямків розробки, наприклад, спеціаліст галузі, в якій буде впроваджене ПЗ, юзабіліті фахівець, для оцінки зрозумілості застосування і головний програміст, для оцінки супроводу і доробки ПЗ у майбутньому. До другої групи відносяться кінцеві користувачі програмного забезпечення, зауваження і побажання яких безпосередньо впливають на якість і зручність використання програмного забезпечення.
Для оцінювання якості програмного забезпечення було відібрано і проаналізовано десять критеріїв, що найбільш всесторонньо характеризують ПЗ із позицій адаптованості до галузі застосування і подальшого вдосконалення за побажанням клієнта. Відібрані критерії і початкові ваги експертів по кожному критерію наведені в Таблиці 12.
Таблиця 13
Критерії і їх початкові ваги для експертів
|
Критерії/Вага |
Експерт галузі |
Експерт юзабіліті |
Експерт з програмування |
Користувачі |
|
|
Точність керування і обчислень |
8 |
5 |
9 |
7 |
|
|
Ступінь стандартності інтерфейсів |
4 |
9 |
6 |
4 |
|
|
Функціональна повнота |
10 |
3 |
9 |
6 |
|
|
Стійкість до помилок |
6 |
4 |
10 |
7 |
|
|
Розширюваність |
4 |
3 |
10 |
2 |
|
|
Зручність роботи |
9 |
9 |
7 |
10 |
|
|
Простота роботи |
9 |
7 |
5 |
10 |
|
|
Відповідність стандартам переносимості між програмним/апаратним забезпеченням |
5 |
3 |
10 |
2 |
|
|
Зручність навчання |
7 |
8 |
5 |
10 |
У таблиці наведено початкові ваги, що визначено емпіричним шляхом. Так, ваги для Експерт галузі мають найбільший показник для тих критеріїв, які безпосередньо відносяться до галузі, в якій буде впроваджено ПЗ, а критерії які характеризують технічну частину або юзабіліті мають оцінку приблизно середню із використовуваної шкали [1..10]. Це твердження справедливе і для двох інших статичних експертів (Експерт юзабіліті і експерт з програмування). Ваги для динамічних експертів (користувачі) мають більший показник для критеріїв, що характеризують галузь застосування ПЗ і використання ПЗ у повсякденній роботі.
Оцінка одного експерта обчислюється за формулою (1)
(1), де
.
Загальна оцінка якості ПЗ обчислюється за формулою (2):
де
Таблиця 14
Вага кожного експерта
|
Експерт |
Вага |
|
|
Експерт з програмування |
9 |
|
|
Експерт юзабіліті |
8 |
|
|
Експерт галузі |
7 |
Нехай при оцінці якості ПЗ маємо по одному експерту з кожної газулі. Експерти оцінили якість ПЗ за даними критеріями наступним чином, результати подано у вигляді таблиці (див. таб. 15):
Таблиця 15
Отримані оцінки експертів
|
Критерії/Оцінка |
Експерт галузі Х1 |
Експерт юзабіліті Х2 |
Експерт з програмування Х3 |
|
|
Точність керування і обчислень |
10 |
9 |
10 |
|
|
Ступінь стандартності інтерфейсів |
8 |
8 |
9 |
|
|
Функціональна повнота |
10 |
10 |
10 |
|
|
Стійкість до помилок |
10 |
10 |
10 |
|
|
Розширюваність |
8 |
8 |
8 |
|
|
Зручність роботи |
9 |
8 |
10 |
|
|
Простота роботи |
8 |
6 |
8 |
|
|
Відповідність стандартам переносимості між програмним/апаратним забезпеченням |
6 |
6 |
7 |
|
|
Зручність навчання |
7 |
8 |
8 |
Обчислимо, персональну оцінку кожного експерта (формула 1):
Обчислимо загальну оцінку якості ПЗ за оцінками експертів (формула 2):
Отримали досить високу оцінку якості ПЗ за оцінками експертів - 8.53. Враховуючи, що оцінка рахується за 10-ти бальною шкалою, 8.53
16. Використання розподіленої системи керування версіями файлів
У зв'язку із підвищеними ризиками поширенням епідеміологічної ситуації, пов'язаної із коронавірусом COVID-19 та постанови Кабінету Міністрів України від 11.03.2020 №211 “Про запобігання поширенню на території України коронавірусу COVID-19” наказом керівника проекту було постановлено: робота в офісі тимчасово зупинена. На цей час продовжити розробку програмного забезпечення в дистанційному режимі. Для цього створити розподілену систему керування версіями файлів.
1. Всі учасники проекту були зареєстровані в системі GitHub.
Рис. 18 - Сторінка репозиторію проекту
2. Було створено віддалений репозиторій для проекту «ProjectRepoTRPZ»:
Рис. 19 - Додані учасники проекту
3. Було додано учасників проекту
4. Для кожного учасника було створено особисту гілку для внесення змін у проект
5. Кожен учасник вніс зміни в проект та злив свою гілку з master:
Рис. 20 - Сторінка гілок репозиторію
Рис. 21 - Зміни, внесені в гілці «Kirill branch»
Рис. 22 - Успішне злиття гілки «Kirill branch» з «master»
Рис. 23 - Зміни, внесені в гілці «Artur branch»
Рис. 24 - Успішне злиття гілки «Artur branch» з «master»
Рис. 25 - Зміни, внесені в гілці «Semen branch»
При спробі злиття останньої гілки виник конфлікт злиття. Для його вирішення було вручну обрано рядки, які потрібно залишити в основній гілці та видалено всі індикатори конфлікту, створені Git:
Рис. 26 - Виникнення конфлікту при злитті гілки «Semen branch» з «master»
Рис. 27 - Файл з конфліктом
Рис. 28 - Успішне злиття гілки «Semen branch» з «master» після усунення конфлікту
На час дистанційного режиму, віддалений репозиторій проекту розробки ПЗ було створено на веб-сервісі GitHub. Було створено чотири гілки: основна - master, гілка курсанта МИКИТЕНКА - Artur branch, гілка курсанта ГЛУМА - Kirill branch, гілка курсанта КУЛИКА - Semen branch.
На кожній гілці було зроблено певну задачу: Artur branch - створення нового файлу та його злиття без конфліктів, Kirill branch - редагування існуючого файлу та його злиття без конфліктів, Semen branch - редагування існуючого файлу, виникнення конфлікту та його вирішення.
Висновки
В результаті дослідження проблеми курсової роботи, було успішно виконано проект ІС «Автоматизоване робоче місце підприємця: облік комп'ютерної техніки». Використовуючи додаткову літературу та попередні напрацювання було реалізовано задачі, описані в технічному завданні курсової роботи. Крім того було виконано низку додаткових робіт, а саме:
1. Було здійснено розподіл в команді проекту (на керівника проекту, тестувальник, системний аналітик), досліджено основні підходи з формування вимог. Окремим досягненням виділимо дослідження оцінки характеристик проекту и оцінки якості програмного забезпечення ІС.
2. Проведено аналіз діаграм процесів та часових діаграм, що дало підгрунтя для раціонального оцінювання вартості проекту і оцінки трудовитрат проекту по розробці ПО.
3. За допомогою метрики Холстеда простими розрахунками було оцінено та виміряно складність та розмір програмного забезпечення. Також за моделлю Нельсона було розраховано кількісні показники надійності, базуючись на даних про поведінку ПЗ в процесі тестування де поява відмов розглядається в часі. Але недоліком для проведення оцінки була умова, що під час тестування, налаштування ПЗ мають бути фіксовані, не модифікуватися а помилки - не виправлятися.
4. Обчисленно значення показників якості програмного забезпечення та отримано оцінку чисельністю «8.53», що описує дуже добру якість розробленого програмного забезпечення. Отже, обраний метод дає можливість проводити оцінку якості ПЗ за набором критеріїв від різних груп учасників процесу розробки і зручного зображення результуючих даних.
5. Побудувавши діаграми діяльності було змодельовано послідовність та паралельність кроків процесів ІС. Це дає змогу однозначно визначити кожну дію, що виконується в цей момент, та може змінювати стан системи або передавати повідомлення.
6. Було вивчено основні етапи методології керування проектами, закріплено навички створення проектної документації, досліджено основні методики оцінки етапів проектування ПЗ, проаналізовано зміст діаграм процесів та часових діаграм.
7. На етапі визначення обсягу трудовитрат та вартості робіт було запропоновано формулу: Година = ЗП / 45
Вона дає точне визначення собівартості години розробки в гривні. Собівартість залежить, таким чином, від зарплати, яку отримує розробник в конкретній компанії. За результатами обчислень, використовуючи дані Таблиці №10, година праці розробника обійдеться роботодавцю в 889,48 грн з ПДВ.
8. І на останок було досліджено основні методики керування версіями файлів при сумісній роботі, проаналізовано популярні сервіси для організації сумісної роботи над проектом ПЗ.
Варто усвідомлювати, що розвиток сучасних технологій розроблення ПЗ вимагає динамічного розвитку засобів оцінки основних характеристик ПЗ ще на етапі його проектування для заощадження грошових та часових витрат. Це дасть можливість обрати той рівень вартості та якості програмного продукту, які будуть задовольняти замовника. Зокрема, оцінка вартості ПЗ проводитися з метою визначення ресурсів, необхідних для розробки, верифікації та валідації програмного продукту, а також для виявлення невизначеності і ризику, пов'язаних з цією оцінкою.
Отже, беручи до уваги сучасні тенденції можна зробити висновок про те, що сучасний ринок програмних продуктів підданий величезній конкуренції. Тому розробка нових програмних продуктів повинна обов'язково супроводжуватися виконанням всіх перерахованих робіт та завдань з проектування та реалізації ПЗ для забезпечення повноцінного функціонування та підтримки отриманої системи.
Список використаної літератури
1. Петрик М.Р. Петрик О.Ю. Моделювання програмного забезпечення: науково-методичний посібник. Тернопіль: Вид-во ТНТУ імені Івана Пулюя, 2015. - 200 с.
2. Діаграма діяльності: Лекція.
3. Дегтярьова Л.М., Гроза П.М. Навчальний посібник з дисципліни «Технології розробки програмного забезпечення» для студентів спеціальності 123 «Комп'ютерна інженерія». Полтава: ПНТУ, 2017. - 218 с.
4. Лавріщева К.М. Програмна інженерія. Київ: Академія, 2008. - 319 с.
5. Боцула М.П. Про проблему експертизи якості матеріалів дистанційних курсів / Боцула М.П., Моргун І.А.; Наукові праці ВНТУ. 2008. - №4. - С. 1-7.
6. Боцула М.П. Метод отримання комплексної оцінки якості веб-матеріалів з використанням полярної системи координат / Боцула М.П., Моргун І.А.; Вісник ВПІ.-2011. - №1. - С. 84-89.
7. Боцула М.П. Методика розрахунку критеріїв оцінки якості електронних матеріалів з використанням нечітких множин / Боцула М.П., Мітюшкін Ю.І., Моргун І.А.; Вісник ВПІ.-2011. - №3.
8. Що таке Git і Github - керівництво для початківців.
9. Башинська, І.О., Новак Н.Г. Ефективне управління проектами підприємства. Інфраструктура ринку: електронний науково-практичний журнал. Одеса: Одеський національний політехнічний університет, 2017. №6. С. 75-78.
10. Поморова О.В. Інтелектуальний метод оцінювання результатів проектування та прогнозування характеристик якості програмного забезпечення / О.В. Поморова, Т.О. Говорущенко // Радіоелектронні і комп'ютерні системи. - 2010. - №6. - С. 211-218.
11. Горбань Г.В. Об'єктні бази даних: методичні вказівки до виконання лабораторних робіт. - Миколаїв: Вид-во ЧНУ ім. П. Могили, 2019. - 108 с.
12. Кучеров Д.П., Артамонов Є.Б. Інженерія програмного забезпечення: навч. посібник - К.: НАУ, 2017. - 388 с.
13. Табунщик Г.В., Каплієнко Т.І., Петрова О.А. Проектування та моделювання програмного забезпечення сучасних інформаційних систем: Навчальний посібник, ? Запоріжжя: Дике Поле, 2016. - 250 c.
14. Смірнов В.В., Смірнова Н.В. Технологія проектування програмних систем: Методологічні вказівки до виконання курсового проектування для студентів денної форми навчання 7.05010201 “Комп'ютерні системи та мережі” - Кіровоград: КНТУ, 2013. - 70 с.
15. Орлов С. А. Технологии разработки программного обеспечения: Учебник. Санкт-Петербург: Питер, 2002. - 464 с.
16. ISO/IEC TR 19759:2015 Software Engineering - Guide to the software engineering body of knowledge (SWEBOK).
17. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы, 1989.
18. Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. Москва: Бином. Лаборатория знаний, Интернет-университет информационных технологий, 2008. 368 с.
19. Скляр В.В. Оценка качества и экспертиза программного обеспечения. Лекционный материал. Харьков: НАУ “ХАИ”, 2008. 204 с.
20. UML. Діаграма діяльності.
Размещено на allbest.ru
Подобные документы
Сутність автоматизованого робочого місця фахівця з розрахунку заробітної платні у медичному закладi. Розробка діаграми класів для програмного комплексу. Опис взаємодії між структурними елементами програмного комплексу. Показники якості аналогічних систем.
курсовая работа [2,2 M], добавлен 03.06.2019Основні функціональні можливості програми для забезпечення комп'ютерної системи дистанційного управління приладами. Функція пульта дистанційного керування мартфонів. Реалізація пультів дистанційного управління на основі апаратно-програмного комплексу.
дипломная работа [1,7 M], добавлен 09.07.2015Структура системи автоматизованого проектування засобів обчислювальної техніки. Опис життєвого циклу продукту за методом Зейда. Основні поняття про системи автоматизованого виробництва. Проектування інформаційних систем та побудова мережевого графіка.
реферат [1,5 M], добавлен 13.06.2010Аналіз сучасних методів та технологій проектування програмного забезпечення. Вибір цільової мобільної платформи. Розробка екранних форм, діаграми класів. Вимоги до програмного продукту. Аналіз небезпечних факторів у відділі роботи з фізичними особами.
дипломная работа [508,1 K], добавлен 02.12.2015Програмне забезпечення та шляхи автоматизації інформаційної системи управління школи. Побудова імітаційної моделі управлінських процесів за допомогою ППЗ MS Project. Розробка бази даних "Школа". Дослідження автоматизованого робочого місця секретаря.
курсовая работа [210,9 K], добавлен 10.11.2012Класифікація об'єктно-орієнтованих мов програмування. Розробка алгоритмічного та програмного забезпечення комп'ютерної системи управління процесом випалювання будівельних матеріалів. Тестування програмного забезпечення, оцінка його ефективності.
курсовая работа [1,6 M], добавлен 25.04.2015Розробка інформаційних моделей та програмного забезпечення автоматизованого робочого місця управління замовленнями малого підприємства. Трудомісткість та тривалість написання програми, розрахунок поточних витрат її реалізації та мінімальної ціни продажу.
дипломная работа [2,0 M], добавлен 19.11.2010Підхід до побудови користувацького інтерфейсу об’єкту проектування. Інтернет-проекти на основі AJAX технології. Побудова діаграми сценаріїв користування. Оцінка програмного забезпечення веб-сервера. Програмування авторизації та реєстрації користувачів.
дипломная работа [290,1 K], добавлен 15.12.2013Незалежно компільований програмний модуль. Програми: "Облік програмного забезпечення" та "Інвентаризація програмного забезпечення на комп'ютерах мережі". Вимоги до функціональних характеристик основної частини системи. Вимоги до програмної документації.
курсовая работа [660,9 K], добавлен 14.12.2010Роль комп'ютерної техніки в різних сферах сучасного суспільства, необхідність його комп’ютеризації. Поняття про програмне забезпечення, складові, коротка характеристика його основних типів. Опис, призначення і можливості електронних таблиць MS Excel.
реферат [2,3 M], добавлен 10.10.2009
