ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 10.06.2019
Просмотров: 591
Скачиваний: 3
СОДЕРЖАНИЕ
1.2 Техническое задание на разработку
Программный продукт представляет собой развлекательный ресурс. Может использоваться любыми лицами.
1.2.3 Основание для разработки
1.2.4 Требование к программе или программному изделию
1.2.4.1 Требования к функциональным характеристикам
1.2.4.2 Требования к надежности.
1.2.4.4 Требования к составу и параметрам технических средств
1.2.4.5 Требования к информационной и программной совместимости
1.2.4.6 Требования к программной документации.
1.2.4.7 Стадии и этапы разработки.
1.2.4.8 Порядок контроля и приема.
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ
ДОНБАССКАЯ ГОСУДАРСТВЕННАЯ МАШИНОСТРОИТЕЛЬНАЯ
АКАДЕМИЯ
КАФЕДРА
КОМПЬЮТЕРНЫХ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к курсовой работе по дисциплине
«Теория создания программных продуктов»
Выполнил:
студент группы ИТ 14-1
Красовский А.В. ______________
(подпись)
Руководитель:
Добряк С. К. ______________
(подпись)
Дата защиты работы |
Оценка |
Подписи преподавателей |
|
|
|
Краматорск, 2017
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ
ДОНБАССКАЯ ГОСУДАРСТВЕННАЯ МАШИНОСТРОИТЕЛЬНАЯ АКАДЕМИЯ
Кафедра КИТ
ЗАДАНИЕ
на выполнение курсовой работы по дисциплине
"Технология создания программных продуктов"
Исполнитель: ст.гр.ИТ-14-1____ Красовский А.В.
1. Индивидуальное задание: разработать программный продукт
Игра «DeadShock»
2. Содержание курсовой работы: при выполнении курсовой работы должны быть реализованы следующие этапы:
-
анализ и формализация требований заказчика;
-
выбор модели взаимодействия с заказчиком и соответствующей модели разработки программного продукта;
-
разработка правовых документов (договора) на создание программного продукта;
-
разработка технического задания на создание программного продукта;
-
планирование процесса создания программного продукта;
-
разработка технического проекта программного продукта с использованием UML;
-
выбор инструментальных средств информационной платформы для реализации программного продукта;
-
выполнить реализацию программных модулей;
-
выполнить тестирование программных модулей;
-
выполнить рефакторинг программного кода;
-
выполнить интеграцию модулей - сборку программного продукта;
-
выполнить целостное тестирование программного продукта;
-
разработать комплекс мероприятий по внедрению и поддержке программного продукта, включая эксплуатационную документацию, приемочные тесты, правовые документы.
3. Оформление курсовой работы: пояснительная записка оформляется в соответствии с ДСТУ 3008.95 и должна содержать:
-
титульный лист – 1 с.
-
индивидуальное задание – 1 с.;
-
аннотацию работы – 1 с.;
-
содержание – 1 с.;
-
введение, отражающее краткую характеристику работы, включая постановку задачи способ ее решения –1-2 с.
-
анализ предметной области, результатом которого является выбор модели взаимодействия с заказчиком и соответствующей модели разработки программного продукта – 2-4 с.
-
техническое задание на создание программного продукта, включая расчет экономических показателей, в соответствии с ГОСТ 19.201-78–4–7 с.;
-
проект программного продукта, включающий, как минимум, следующие UML-диаграммы: прецедентов использования, классов, последовательностей, а также соответствующие спецификации описание использованных шаблонов проектирования – 5-7 с.;
-
модульные тесты для каждого класса, тестирующие в полном объеме его функциональность – 3-5 с.;
-
описание выполненных в процессе разработки операций рефакторинга – 2-4 с.;
-
описание сценария сборки – 1-2 с.;
-
приемочные тесты –1-3 с.;
-
эксплуатационную документацию (руководство пользователя) – 2-4с.;
-
приложения: договор на создание программного продукта, полные исходные коды программы, акт тестирования.
Задание выдал: Добряк С.К.
Задание получил: Красовский А.В.
1.2 Техническое задание на разработку 8 Программный продукт представляет собой развлекательный ресурс. Может использоваться любыми лицами. 8 1.2.3 Основание для разработки 8 1.2.4 Требование к программе или программному изделию 8 1.2.4.1 Требования к функциональным характеристикам 8 1.2.4.2 Требования к надежности. 9 1.2.4.3 Условия эксплуатации 9 1.2.4.4 Требования к составу и параметрам технических средств 9 1.2.4.5 Требования к информационной и программной совместимости 9 1.2.4.6 Требования к программной документации. 10 1.2.4.7 Стадии и этапы разработки. 10 1.2.4.8 Порядок контроля и приема. 11 |
||||||||||||||
|
|
|
|
|
КИТ 14-1 |
|
||||||||
|
|
|
|
|
|
|||||||||
Изд |
Лист |
№ Документа |
Подпись |
Дата |
|
|||||||||
Разработ. |
Красовский А. |
|
|
«Разработка программного продукта «DeadShock» |
Лит |
Лист |
Листов |
|
||||||
Проверил. |
Добряк С.К. |
|
|
|
|
|
2 |
27 |
|
|||||
|
|
|
|
ДГМА, ИТ 14-1 |
|
|||||||||
|
|
|
|
|
||||||||||
|
|
|
|
|
||||||||||
|
|
|
|
|
Аннотация
Курсовая работа по дисциплине «Технологии создания программных продуктов» студента группы ИТ 14-1 Красовский А.В. содержит описание процесса разработки программного продукта для проведения досуга в свободное время.
Курсовая работа содержит 26 страниц машинописного текста, 9 рисунков, 5 таблиц, 7 страниц приложений.
Цель разработки программного комплекса – создать программный продукт, который сможет обеспечить интересное времяпровождение.
DeadShock, ИГРА, JAVA, INTELLIJ IDEA.
Введение
Программа «DeadShock» предназначена для провождения досуга.
В качестве среды разработки выбрана среда Intelij Idea, разработанная компанией JetBrains. Это интегрированная среда разработки для работы на языке Java.
Intelij Idea – это мощный профессиональный и расширяемый инструмент разработчика. Она имеет богатый функционал, упрощающий разработку приложения на различных этапах, поддерживая и охватывая все современные требования для IDE. А именно, рефакторинг, профилирование, выделение синтаксических конструкций цветом, автодополнение набираемых конструкций на лету, множество предопределённых шаблонов кода и др.
1 АНАЛИЗ И ФОРМАЛИЗАЦИЯ ТРЕБОВАНИЙ К ПРОГРАММЕ «DeadShock»
-
Диаграмма прецедентов
Программа должна обеспечивать взаимодействие игрока с ИИ. В связи с этим разработаны следующие прецеденты:
Рисунок 1 – Диаграмма прецедентов
Диаграмма прецедентов представлена на рисунке 1. Описание прецедентов в таблицах 1-2.
Таблица 1– Описание прецедента «Убить противника»
Основной исполнитель – Главный герой Заинтересованные лица – Игрок |
Предусловия:
|
Входные данные:
|
Основной успешный сценарий(основной процесс):
|
Частота выполнения:
|
Постусловие(результаты):
|
Выходные данные:
|
Таблица 2– Описание прецедента «Покупка аммуниции»
Основной исполнитель – Главный герой Заинтересованные лица - Игрок |
Предусловия:
|
Входные данные:
|
Основной успешный сценарий(основной процесс):
|
Частота выполнения:
|
Постусловие(результаты):
|
Выходные данные:
|
1.2 Техническое задание на разработку
1.2.1 Введение
Программный продукт представляет собой развлекательный ресурс. Может использоваться любыми лицами.
1.2.3 Основание для разработки
Разработка выполняется на основании индивидуального задания на лабораторные работы по дисциплине «Технология программирования и создания программных продуктов», выданного руководителем работы Добpяком С.К. 11.09.2016. Условное обозначение разработки – DeadShock.
1.2.3 Назначение разработки
ПП предназначен для провождения досуга.
1.2.4 Требование к программе или программному изделию
1.2.4.1 Требования к функциональным характеристикам
В программном продукте должны быть предусмотрены следующие функции:
-
Погружать игрока в атмосферу игры;
-
работать в одиночном режиме;
-
количество уровней(2)
-
количество оружия(2)
-
количество плейлистов(4)
-
количество противников(16 – на первом уровне, 14 – на втором)
-
типы противников(2)
-
наличие энергетиков
-
типы энергетиков (2)
-
главный герой (Букер)
-
наличие компаньона(на втором уровне)
-
покупка амуниции
-
типы амуниции(3)
-
количество треков (28)
-
наличие торгового автомата
-
наличие жизней
-
наличие денег в игре
1.2.4.2 Требования к надежности.
-
ПП должен устойчиво функционировать и не приводить к сбоям операционной системы;
-
ПП должен обеспечивать обработку ошибочных действий пользователя с выдачей соответствующих сообщений.
1.2.4.3 Условия эксплуатации
Условия эксплуатации ПП определяются СанПиН 2.2.2 545-96 «Гигиенические требования к видео-дисплейным терминалам, персональным вычислительным машинам и организации работы».
1.2.4.4 Требования к составу и параметрам технических средств
Требования к параметрам технических средств:
-ОС Windows XP и выше.
-CPU Intel Atom 1.6 GHz и лучше.
-600мб свободного места на диске.
-ОЗУ 600мб свободного места.
- Клавиатура, мышь
1.2.4.5 Требования к информационной и программной совместимости
Программный продукт функционирует в среде платформы Java. ПП создается с использованием инструментального средства разработки приложений IntelliJ IDEA на языке Java.
1.2.4.6 Требования к программной документации.
Программная документация должна содержать:
-
Руководство пользователя.
-
Анализ и формализация требований заказчика.
-
Модель взаимодействия с заказчиком и соответствующей модели разработки программного продукта.
-
Правовой документ (договор) на создание программного продукта.
-
Техническое задания на создание программного продукта.
-
План процесса создания программного продукта.
-
Технический проект программного продукта с использованием UML.
-
Описание инструментальных средств и информационную платформу для реализации программного продукта.
-
Листинг программных модулей.
1.2.4.7 Стадии и этапы разработки.
Таблица 3 – Стадии и этапы разработки
№ |
Этап/ Срок выполнения |
Содержание работ |
1 |
Техническое задание 20.10.16 |
Анализ и формализация требования к
ПП, |
2 |
Эскизный проект 25.10.16 |
Предварительная разработка проекта ПП с использованием UML: диаграммы прецедентов использования, диаграммы классов и последовательности. |
3 |
Технический проект 20.11.16 |
Реализация рабочей версии ПП с основной функциональностью; модульные тесты. |
4 |
Рабочий проект 25.11.16 |
Корректировка и доработка программного
обеспечения; |
5 |
Внедрение 29.11.16 |
Разработка мероприятий по внедрению и сопровождению ПП |
1.2.4.8 Порядок контроля и приема.
Контроль корректности функционирования и пригодности ПП к эксплуатации выполняется совместно Разработчиком и Заказчиком ПП на основании приемочных тестов, предоставляемых Заказчиком. Решение о приеме в эксплуатацию принимается на основании акта тестовых испытаний.