Программный инжиниринг при разработке компьютерных игр

1.

Программный инжиниринг
при разработке комп. игр
Айжулов Д.
[email protected]
Satbayev University

2.

Software Enginnering
• «Программная инженерия (ПИ) - это дисциплина, которая занимается всеми аспектами
разработки программного обеспечения от ранних этапов спецификации системы до
сопровождения системы после ее ввода в эксплуатацию.»
• Программная инженерия состоит из принципов, методов, приемов и инструментов для
• технической спецификации,
• разработки,
• менеджмента и
• эволюции
• программных систем
• Любой проект по разработке игр требует усилий множества творческих людей,
выполняющих самые разные работы. Среди этих людей есть те, кто разрабатывает игры,
создает графические ресурсы, сочиняет музыку и пишет диалоги. Программная инженерия
состоит из набора практик, применимых к разработке программного обеспечения.
• Программная инженерия приносит пользу всем, кто участвует в разработке игр, поскольку
позволяет разработчикам программного обеспечения находить и применять надежные,
проверенные методы в своих усилиях. Их усилия направлены на удовлетворение
потребностей других.

3.

• Программная инженерия - это совокупность знаний, которыми
руководствуются разработчики при разработке программного
обеспечения. Одна рекомендация, которую предлагает эта
совокупность знаний разработчикам, заключается в том, что они
должны тщательно собирать и анализировать требования к
программной системе, которую им было предложено создать. Другая
рекомендация - создать проект программного обеспечения, полностью
отвечающий требованиям. Также рекомендация, согласно которой
разработчики тестируют разрабатываемую ими систему, чтобы
убедиться, что ее дизайн и реализация в точности соответствуют
требованиям.

4.

Цели
• Выявление основных проблем возникающих при разработке больших
программных систем и рассмотреть процессы и методы создания таких
систем
• Рассмотреть управленческие задачи, специфические для разработки
программного обеспечения: оценка стоимости, управление качеством и
командная организация
• Изучить общие компоненты требований вне зависимости от
конкретного процесса разработки программного обеспечения

5.

Почему это важно
• Многие проекты терпят неудачу ... или не так успешны, как предполагалось
• низкое качество
• низкая надежность
• низкое удобство использования
• высокая стоимость
• сложность (обычно возрастает как нелинейная функция)
• плохая работа в команде
• нет готовых глобальных решений
• контекст всегда меняется
• множество примеров неудач при разработке программного обеспечения
• создание системы по неправильной причине
• создание неправильной системы
• неправильное создание системы

6.

Основные темы
• Разработка требований (requirements specification
• Проектирование, разработка и тестирование (Design, implementation
and testing)
• Управление проектом (Project management)
• Управление изменениями (Change management)
• Внедрение и поддержка (delivery and maintenance)
• Инструменты для поддержки SE

7.

Процесс разработки ПО
• Процесс разработки ПО - это набор действий и связанных результатов,
которые создают программный продукт (Sommerville)
• Четыре фундаментальных процесса
• Разработка требований (техническое задание) – понять что необходимо
• Разработка ПО (технический проект, разработка, тестирование) – понять как
удовлетворить необходимость
• Валидация – удовлетворена ли необходимость
• Эволюция – своевременно реагировать на изменения

8.

Процесс ПО
• Процесс разработки ПО - это структура, в которой методы и
инструменты используются определенным методологией образом.
• Следует выбрать соответствующий процесс(ы) для конкретной
проблемы и среды.
• Процессы должны разрабатываться и улучшаться.
• Нет единого процесса, подходящего для всех ситуаций («Серебряной
пули не существует» Фред Брукс)

9.

Модель ПИ
• Модель процесса разработки ПО - это упрощенное представление
программного процесса, представленное с определенной точки зрения.
• Некоторые примеры:
• Workflow model
• Dataflow (activity) model
• Role/Action model

10.

Признаки хорошего программного обеспечения
• Удобство обслуживания (maintainability) - изменения неизбежны,
программное обеспечение должно развиваться для удовлетворения
меняющихся потребностей клиентов
• Надежность (dependability) - программное обеспечение должно
соответствовать надлежащему уровню надежности, безопасности и
сохранности
• Эффективность (efficiency) - не растрачивает системные ресурсы
• Юзабилити - пригодный пользовательский интерфейс и поддержка
целевой группы пользователей

11.

Модель Водопада
Анализ и
определение
требований
Проектирование
системы и ПО
Разработка и
модульное
тестирование
Внедрение и
тестирование
системы
• Первая попытка применения
модели разработки
программного обеспечения
(Royce, 1970)
• Основан на традиционном
инженерном подходе
• Хорошо вписывается в структуру
управления проектом
• Много вариантов со времени
первоначального предложения,
но все они основаны на
последовательности этапов.

12.

Модель водопада (результаты)
• Определение требования (определение проблемы) и спецификация
требования (функциональная спецификация)
• Детальный проект (внутренняя спецификация), планы и график
тестирования, схема базы данных
• Компоненты программного обеспечения (протестированы и
задокументированы)
• Полная система (при условии тестирования после внедрения)
• Пользовательская документация,
• Техническая документация.

13.

Итерации модели водопада
• Существует много вариантов показанной модели; различные
методологии разбивают модель на несколько фаз или
обозначают их по-разному. Например, этап проектирования
часто делится на два этапа: архитектурное
(высокоуровневое) проектирование и детальное
проектирование.
• Независимо от конкретного варианта, все эти модели
страдают от одного и того же недостатка:
Анализ и
определение
требований
• Используя неформальные (полуформальные) методы
(основанные на тексте, диаграммах, псевдокоде и т. Д.),
результаты какой-либо конкретной фазы не являются
достаточно строгими в качестве входных данных для
следующей фазы.
Проектирование
системы и ПО
• Следовательно, мы должны выполнять итерацию, а не
«поток»!
Разработка и
модульное
тестирование
Внедрение и
тестирование
системы
• Реальная модель водопада включает в себя обратную связь
между фазами, чтобы устранить неоднозначности, упущения
и ошибки.
• Основной проблемой в разработке программного
обеспечения является контроль этой обратной связи и
обеспечение регистрации всех изменений. (Контроль
изменений, управление версиями, управление
конфигурацией)
• Другой проблемой в идеализированной модели водопада
является техническое обслуживание. Как только система
начинает работать, проблемы действительно начинаются!

14.

Итерационный подход при разработке игр
• Постоянно обновлять информацию о:
• Время.
• Энергия.
• Эффективность.
• Надежность.
• Ремонтопригодность.
• Соответствие.

15.

Верификация и валидация
Верификация и валидация - важные концепции в
любой моделе разработки ПО
• Верификация - это процесс подтверждения того,
что технически разработка прогрессирует
правильно. Все результаты должны быть
проверены как на
внутреннюю согласованность и на соответствие
с предыдущим результатам. Правильно ли мы
создаем продукт?
• Валидация - это процесс подтверждения того,
что разрабатываемый продукт это то, что хочет
пользователь. Мы создаем правильный
продукт?
Полуформальные методы используют экспертные
оценку, пошаговые проверки и проверки
программного кода (связано с управлением
качеством.)
Валидация обычно осуществляется посредством
презентаций для пользователей и обсуждения
проблем.

16.

Важность процесса разработки требований
• Определение (некоторых) требований является отправной точкой для
всех проектов разработки программного обеспечения независимо от
используемого метода разработки.
• При традиционной разработке стоимость исправления проблем после
поставки системы высока (возможно, в 100 раз больше стоимости
исправления ошибки реализации).
• Изменения требований неизбежны
• по мере развития понимания требований
• по мере развития программного обеспечения
• после поставки системы (обслуживание, развитие)

17.

Разработка требований (requirements engineering)
• Требования к системе - это описание того, что система должна делать: услуги,
которые она предоставляет, и ограничения на его работу. Эти требования
отражают потребности клиентов в системе, которая служит определенной
цели, такой как управление устройством, размещение заказа или поиск
информации. Процесс обнаружения, анализа, документирования и проверки
этих услуг и ограничений называется инженерия требований (Somerville).
• Пользовательские требования - это заявления на естественном языке плюс
диаграммы того, какие услуги система должна предоставлять пользователям
системы, а также ограничения, при которых она должна работать.
• Системные требования - это более подробное описание функций, служб и
операционных ограничений программной системы. Документ системных
требований (иногда называемый функциональной спецификацией) должен
точно определять, что должно быть реализовано. Это может быть частью
договора между покупателем системы и разработчиками программного
обеспечения.

18.

Пользовательские и системные требования
• Пользовательское требование
• MHC-PMS должен составлять ежемесячные управленческие отчеты, показывающие
стоимость лекарств, выписанных каждой клиникой в течение этого месяца.
• Системное требование
• 1.1 В последний рабочий день каждого месяца сводка лекарств
• назначаются, их стоимость и клиники, выписывающие рецепты, должны быть созданы.
• 1.2 Система автоматически формирует отчет для печати после 17.30 последнего
рабочего дня месяца.
• 1.3 Отчет должен быть создан для каждой клиники, и в нем должны быть перечислены
отдельные наименования лекарств, общее количество рецептов, количество
прописанных доз и общая стоимость прописанных лекарств.
• 1.4 Если лекарственные препараты доступны в разных единицах дозы (например, 10 мг,
20 мг), для каждой единицы дозы должны быть созданы отдельные отчеты.
• 1.5 Доступ ко всем отчетам о затратах должен быть ограничен авторизованными
пользователями, внесенными в список управления доступом.

19.

Зачем?
• Многие проекты провалились из-за неадекватного понимания
требований.
• Необходим системный подход к спецификации требований, со
следующими этапами:
• Технико-экономическое обоснование (feasibility study) - анализ затрат/выгод для
бизнеса и анализ рисков, подготовленный для принятия управленческих
решений
• Выявление и анализ требований (сбор или обнаружение требований) выяснение того, что требуется от клиентов
• Спецификация требований (в рамках договора?) для клиента и
непосредственного разработчика
• Валидация требований – отвечают ли специфицированные требования нуждам
клиента?

20.

Процесс разработки требований
ТЭО
Анализ
требований
Спецификация
требований
Валидация
требований
Модель
системы
Отчет
ТЭО
Пользов-кие и
сист. требования
Техническое
задание

21.

Stripes
• Команда может задокументировать разделение усилий на полосы в
описании дизайна программного обеспечения. В описании приведен
следующий список полос:

22.

Функциональные и нефункциональный требования
• Требования можно разделить на две основные категории:
функциональные и нефункциональные.
• Функциональные требования, как следует из названия, определяют
основные функции системы и обычно их довольно легко
идентифицировать и определять.
• Нефункциональные требования - это ограничения, которые
ограничивают продукт и процесс разработки, устанавливают внешние
условия, которым должен соответствовать продукт.
• Должен быть компромисс между функциональными и
нефункциональными требованиями

23.

Нефункциональные требования
• Должен быть объективным и поддающимся тестированию (например,
«система должна быть удобной для пользователя» является
субъективным, и нет никаких критериев для тестирования требования)
• Somerville разделяет нефункциональные требования на три основные
категории:
• Требования к продукту: удобство использования; экономичность
(производительность, пространство); надежность; портативность.
• Организационные требования: поставка; реализация; стандарты.
• Внешние требования: совместимость; юридические (безопасность,
конфиденциальность)
• Стандартный контрольный чеклист нефункциональных требований
можно найти в стандарте: IEEE Std-830-1993

24.

Примеры нефункциональных требований
• Совместимость с другими системами (внутренними или внешними)
• Информационная безопасность и коммуникации
• Производительность
• Пропускная способность (пр. транзакции в час)
• Время отклика
• Надежность
• Тест нагрузки
• MTBF, MTTR (mean time before failures, mean time to repair)
• Доступность (up time)

25.

Выявление и анализ требований
• Выявление, также называемое сбором требований, захватом или
обнаружением:
• Определение реальных требований клиентов
• Кто клиенты?
• Термин заинтересованная сторона (stakeholder) часто используется, а не клиент любой, кто имеет прямое или косвенное влияние на системные требования.
• Заинтересованными сторонами могут быть менеджеры, конечные
пользователи системы, другие части организации, внешние
организации, ...

26.

Выявление и анализ требований - проблемы
• У разных видов бизнеса есть своя собственная внутренняя
терминология (жаргон)
• У организаций есть своя собственная терминология и методы ведения
бизнеса, незнакомые разработчикам системы.
• Заинтересованные стороны не знают, чего хотят, или выдвигают
нереалистичные требования (например, технически невыполнимые или
слишком дорогие)
• Конфликт между требованиями заинтересованных сторон
• Организационная структура и политика (часто неявные)
• Организационная среда может измениться (в худшем случае
произойдет поглощение бизнеса или серьезная реструктуризация
организации)

27.

Выявление и анализ требований - процесс
• Понимание предметной области - область
применения и терминология
• Выявление требований - определение требований
путем общения с заинтересованными сторонами,
наблюдения за процессами, анализа данных и т. д.
• Классификация - систематизация собранной
информации, создание структуры (иерархии,
кластеры)
• Разрешение конфликтов - выявление и разрешение
конфликтов между требованиями различных
заинтересованных сторон.
• Расстановка приоритетов - определение наиболее
важных требований
• Валидация - полнота, последовательность и
реалистичность

28.

Выявление требований - подходы
• Поначалу выявление требований очень сложно. Даже если вы работаете с
официальным документом по игровому дизайну, вы все равно должны
проанализировать документ, чтобы обнаружить системные функции, которые вы
должны поддерживать. Для выполнения этой задачи вам потребуется информация
от других. Краткий список ресурсов для этой информации может быть следующим:
• Пользователи игры
• Ваш предыдущий опыт разработки игр
• Специалисты по маркетингу, графическому дизайну и другие специалисты, участвовавшие в
работе
• Игры, которые могут быть изменены (моды) для создания игры, которую вы хотите разработать.
• Дизайнеры игры, которую вы хотите создать
• Программисты, которые создадут новую систему

29.

Выявление
• Получение от руководителей объема игры
• Опрос клиентов
• Сопровождение разработчиков через уточнение требований
• Анализ требований для выявления основных свойств системы
• Ведение документов, в которых перечислены и подробно изложены требования
• Управление изменением требований в процессе разработки

30.

Выявление требований - подходы
• Интервью - планирование, запись и анализ; с менеджерами, клиентами (стратегами и платящими за
систему!)
• Структурированный, с заранее запланированными вопросами, можно использовать по телефону
• Неструктурированный, свободный формат, трудный для анализа
• Гибрид, где угодно между структурированным и неструктурированным!
• Обзор - изучение существующих записей, статистическая выборка; полезно там, где есть
большие объемы данных
• Наблюдение (этнография)
• наблюдение за деятельностью, процессами и рабочими процессами
• участие в мероприятиях с конечными пользователями
• видеозаписи деятельности, очень сложно анализировать
• Сценарии - обсудить различные сценарии с пользователями, чтобы понять нормальные и
исключительные процессы (что, если?)
• Прототипы - создание частичных прототипов, быстрое и «грязное», обычно сосредоточенное на
интерфейсах; опробовать идеи с пользователями (например, активный сценарий?)
• Анкеты - объемный, набросанный сбор инфы, сложный в дизайне; подходит для
сбора исходных данных (например, отношения клиентов)

31.

Классификация требований
• Нам необходимо классифицировать (систематизировать) требования,
чтобы упростить поиск конфликтов и избыточности.
• Очень мало материала о классификации в общих чертах!
• Три предлагаемых метода
• Разделение - идентификация агрегатов
• Абстракция - выявление обобщений
• Проекция - организация знаний с разных точек зрения

32.

Выявление конфликтов и приоритетов
• Анализ проекта набора требований на несоответствия между
требованиями.
• Использование контрольных списков (например, см. следующий слайд)
• Систематическая проверка на конфликты с помощью матрицы
взаимодействия
• Ведение переговоров с заинтересованными сторонами для разрешения
конфликтов
• Приоритезация согласованных требований либо для соблюдения
ограничений по стоимости, либо для поэтапной доставки

33.

Чеклист для внутренней валидации
• Преждевременный дизайн - раннее обязательство по разработке или
реализации
• Сложные требования - можно разбить на более простые части
• Ненужные требования - «gold plating»
• Использование нестандартной платформы - специального оборудования /
программного обеспечения
• Соответствие бизнес-целям - соответствие бизнес-целям (мандат проекта)
• Неоднозначность - разные возможные трактовки?
• Реализм - учитывая предложенную (доступную) технологию
• Возможность тестирования - вы можете написать тест на это требование?

34.

UML
• UML (унифицированный язык моделирования) — язык графического
описания для объектного моделирования в области разработки
программного обеспечения, для моделирования бизнес-процессов,
системного проектирования и отображения организационных структур.
• Use case (прецендент, сценарии использования, варианты использования) это метод обнаружения требований, который впервые был введен (Jacobson
et al., 1993). Сегодня являются фундаментальной фичей единого языка
моделирования. В простейшей форме идентифицирует участников,
участвующих во взаимодействии, и определяет тип взаимодействия. Затем
это дополняется информацией, описывающей взаимодействие с системой.
Дополнительная информация может быть текстовым описанием или одной
или несколькими графическими моделями, такими как последовательности
UML или диаграммы состояний.

35.

Use case
• Определяет некоторые функции системы.
• конкретная задача
• инкапсулирует значимую единицу деятельности
• В конечном итоге индивидуальный use case определяется подробным
описанием
• Термин «сценарий» часто используется для описания одного use case.
• Используются для:
• сбора требований
• планирования разработки системы (итерации системы)
• валидации системы

36.

Качества и ограничения
• Нефункциональные требования определяют желаемые качества
системы и ограничения, в рамках которых система должна быть
разработана
• Качества – определяют свойства и характеристики, которые система должна
продемонстрировать
• Ограничения – лимиты, стандарты, факторы среды, которые должны быть
учтены в решении

37.

Виды ограничений
Бизнес
Технические
• Нормативные
• Организационные
• Основанные на риск факторах
• Маркетинговые
• Сроки и бюджет
• Среда
• Навыки
• Интеграция с легаси
системами
• Существующая инфрастуктура
• Текущий уровень научно
технического прогресса
• ИТ стандарты
• Навыки

38.

Виды качеств
Производительность
Доступность
Управляемость
Безопасность
Юзабилити
Целостность (данных)
Масштабируемость
Портативность
Эффективность
Гибкость
Ремонтопригодность