- •Пояснительная записка
- •Задание
- •Игра «DeadShock»
- •Аннотация
- •Введение
- •1 Анализ и формализация требований к программе «DeadShock»
- •1.2 Техническое задание на разработку
- •1.2.4.2 Требования к надежности.
- •1.2.4.7 Стадии и этапы разработки.
- •1.2.4.8 Порядок контроля и приема.
- •3.2.1 Скрытие методов
- •3.3 Сборка
- •3.4 Руководство пользователя
- •Приложение а расчет капитальных затрат на разработку программного продукта
- •Приложение б Описание классов приложения.
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 Порядок контроля и приема.
Контроль корректности функционирования и пригодности ПП к эксплуатации выполняется совместно Разработчиком и Заказчиком ПП на основании приемочных тестов, предоставляемых Заказчиком. Решение о приеме в эксплуатацию принимается на основании акта тестовых испытаний.
2 Проектирование программыdeadshock
2.1 Диаграмма классов
Проанализировав предметную область, требования к программному продукту (ПП), получаем следующую диаграмму классов базы данных, изображенную на рисунке 2.
Рисунок 2 – Диаграмма классов приложения «DeadShock»
Подробное описание классов в приложении В.
2.3 Диаграмма последовательностей
По разработанным прецедентам и диаграмме классов создана диаграммы последовательностей, представленная на рисунке 3.
Рисунок 3 – Диаграмма последовательностей стрельбы в «DeadShock»
3 Разработка программы «DeadShock»
3.1 Модульные тесты
Далее представлено описание функциональных тестов cпомощьюJUnit.
Test— библиотека для модульного тестирования программного обеспечения на языкеJava[3].
Рисунок 4 – Результат модульных тестов
3.2 Рефакторинг
Рефа́кторинг (англ. refactoring) или реорганизация кода — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости.