Разработка и анализ требований к программному обеспечению Практические работы

Практическое задание 1
Тема 1.3. Качество программного обеспечения, его метрики и
показатели
Цель работы: сформировать навыки оценки качества программных
систем.
Задание. Определите концептуальные различия основных
стандартов и методик оценки качества программных средств.
Стандарты
Фазы
жизненного
цикла ПС
Анализ
ISO/IEC 25010
Требования
и
требований
оценка качества
систем
и
программного
обеспечения
ISO/IEC 9126 — Проектирование
международный
стандарт,
определяющий
оценочные
характеристики
качества
программного
обеспечения.
Российский
аналог стандарта
ГОСТ
Р
ИСО/МЭК 912693
CMMI
Разработка
(Capability
Maturity Model
Integration)
Комплексная
модель производ
ительности
и
Показатели
качества
Функциональн
Методики
оценивания
качества ПС
Статический
ость
анализ
Надежность
Динамическое
тестирование
Удобство
Опрос
использования
пользователей
зрелости
–
набор моделей (
методологий)
совершенствова
ния процессов в
организациях
разных размеров
и
видов
деятельности.
SPICE (Software
Process
Improvement and
Capability
dEtermination) —
международный
стандарт
(ISO/IEC 15504)
для оценки и
улучшения
программных
процессов
ITIL (IT Infrastru
cture Library)
представляет
собой
мировую библиотеку,
содержащую
набор
лучших
практик
в
области
управления ITсервисами.
Agile, Scrum и K
anban —
это
инструменты
для групповой
работы, которые
позволяют
работать
эффективнее
Six
Sigma
фокусируется на
Внедрение
Эффективность Моделирование
процессов
Эксплуатация
Поддержива-
Аудит качества
емость
Поддержка
и Производи-
Инспекции
и
обновление
тельность
ревью
Все фазы
Стабильность
DMAIC (Define,
повышении
качества
выпускаемой
продукции
путем
выявления
и
устранения
причин
дефектов
(ошибок)
и
минимизации
изменчивости
(производственн
ых и бизнес -)
процессов.
Measure,
Analyze,
Improve,
Control)
подход
к
последовательн
ому
решению
проблем
и
совершенствова
нию
бизнес-
процессов,
используемый в
управлении
производством.
1.
Разработайте программу «Калькулятор» на любом языке
программирования.
Вот пример простой программы "Калькулятор" на языке Python,
которая может быть использована для выполнения базовых
математических операций. Эта программа может быть полезна в
гостиничном бизнесе для расчета стоимости проживания и других
финансовых операций.
def add(x, y):
return x + y
def subtract(x, y):
return x - y
def multiply(x, y):
return x * y
def divide(x, y):
if y == 0:
return "Ошибка: Деление на ноль!"
return x / y
def calculator():
print("Добро
пожаловать
в
Калькулятор
для
гостиничного
бизнеса!")
print("Выберите операцию:")
print("1. Сложение")
print("2. Вычитание")
print("3. Умножение")
print("4. Деление")
while True:
choice = input("Введите номер операции (1/2/3/4): ")
if choice in ['1', '2', '3', '4']:
num1 = float(input("Введите первое число: "))
num2 = float(input("Введите второе число: "))
if choice == '1':
print(f"{num1} + {num2} = {add(num1, num2)}")
elif choice == '2':
print(f"{num1} - {num2} = {subtract(num1, num2)}")
elif choice == '3':
print(f"{num1} * {num2} = {multiply(num1, num2)}")
elif choice == '4':
print(f"{num1} / {num2} = {divide(num1, num2)}")
else:
print("Неверный ввод, пожалуйста, выберите операцию от 1
до 4.")
next_calculation = input("Хотите выполнить еще одну операцию?
(да/нет): ")
if next_calculation.lower() != 'да':
break
if __name__ == "__main__":
calculator()
Описание функций:
 add(x, y): Сложение двух чисел.
 subtract(x, y): Вычитание второго числа из первого.
 multiply(x, y): Умножение двух чисел.
 divide(x, y): Деление первого числа на второе с проверкой на
деление на ноль.
Применение в гостиничном бизнесе:
Эта программа может быть использована для:
Расчета общей стоимости проживания (например, стоимость
номера на ночь умноженная на количество ночей).
Вычисления скидок, налогов и других финансовых операций.
Для сравнения программного продукта "Калькулятор" фирмы
Microsoft и разработанного калькулятора на Python мы можем
использовать
две
методики
оценки: анализ
функциональности и оценка удобства использования.
1. Анализ функциональности
Калькулятор Microsoft:
Функциональные возможности:
Поддерживает основные арифметические операции: сложение,
вычитание, умножение, деление.
Имеет расширенные функции: работа с процентами, квадратные
корни, тригонометрические функции и возможность работы с
большими числами.
Поддерживает
различные
режимы
(калькулятор,
научный
калькулятор, программный калькулятор и др.).
Разработанный калькулятор на Python:
Функциональные возможности:
Поддерживает базовые арифметические операции: сложение,
вычитание, умножение, деление.
Не имеет дополнительных функций, таких как работа с
процентами или тригонометрические функции.
Прост в использовании, но ограничен в функционале.
Сравнение:
Калькулятор Microsoft предлагает более широкий спектр функций
и возможностей, что делает его более универсальным инструментом.
Разработанный калькулятор ограничен базовыми арифметическими
операциями, что может быть недостаточно для более сложных
расчетов.
2. Оценка удобства использования
Калькулятор Microsoft:
Интерфейс:
Имеет графический интерфейс, который интуитивно понятен, с
кнопками, которые легко различить.
Поддерживает сенсорное управление, что делает его удобным для
использования на мобильных устройствах и планшетах.
Доступность:
Доступен на различных платформах (Windows, Android, iOS), что
позволяет использовать его в любом месте.
Разработанный калькулятор на Python:
Интерфейс:
Работает в текстовом режиме, что может быть менее удобно для
пользователей, которые предпочитают графический интерфейс.
Не
имеет
визуальных
элементов,
что
может
усложнить
взаимодействие для некоторых пользователей.
Доступность:
Запускается только в среде выполнения Python, что ограничивает
его доступность для пользователей, у которых нет установленного
Python.
Сравнение:
Калькулятор Microsoft предлагает более удобный интерфейс и
доступность,
что
делает
его
более
привлекательным
для
пользователей. Разработанный калькулятор, хотя и простой в
использовании, может показаться устаревшим и менее интуитивным
для пользователей, привыкших к графическим интерфейсам.
Заключение
В результате сравнения по методикам анализа функциональности
и
оценки
удобства
использования,
калькулятор
Microsoft
оказывается более мощным и удобным инструментом, в то время
как разработанный калькулятор на Python, хотя и полезен для
базовых расчетов, имеет ряд ограничений в функциональности и
интерфейсе, что может снизить его
привлекательность для
конечного пользователя.
Практическое задание 2
Тема 2.2. Программные требования
Цель работы: сформировать навыки работы с нормативными
документами в области разработки требований.
Задание.
Определите
концептуальные
различия
основных
стандартов и методологий для разработки требований.
К. Вигерс
Классификация
Описание
1. Функциональные
Описывают, что
требования
система должна
делать.
2. Нефункциональные
Описывают качества
требования
системы, такие как
производительность,
безопасность и
удобство
использования.
3. Ограничения
Определяют условия,
в которых система
должна работать
(например,
аппаратные
ограничения).
SWEBOK
1. Системный анализ
Изучение требований
и спецификаций.
2. Проектирование
Архитектура
и
проектирование
программных систем.
3. Реализация
Кодирование
и
интеграция
компонентов.
4. Тестирование
Процессы проверки и
валидации
программного
обеспечения.
5. Поддержка
Поддержка
и
обслуживание
программного
обеспечения после его
развертывания.
RUP
1. Инициация
Определение объема и
целей проекта.
2. Уточнение
Сбор
и
требований
требований
анализ
пользователей.
3. Проектирование
Архитектурное
проектирование
системы.
4. Реализация
Кодирование
и
подготовка системы к
развертыванию.
5. Тестирование
Проверка и валидация
системы
перед
запуском.
6. Поддержка
Обслуживание
обновление
и
системы
после развертывания.
IEEE830
1. Введение
Общая информация о
системе и её цели.
2. Общие описания
Общее
описание
функциональности
и
ограничений системы.
3. Функциональные
Подробное
описание
требования
функций системы.
4. Нефункциональные Описание
требования
производительности,
надежности,
безопасности
и
прочих качеств.
5. Дополнительные
Специфические
требования
требования, такие как
совместимость
и
стандарты.
ГОСТ 34
1. Определение
Описание
требований
формулирование
требований
и
к
программной системе.
2. Документация
Разработка
и
оформление
документации
на
программное
обеспечение.
3. Проектирование
Проектирование
системы
с
учетом
требований
и
ограничений.
4. Тестирование и
Испытания системы
валидация
для проверки
соответствия
требованиям.
5. Эксплуатация
Процессы, связанные
с развертыванием и
обслуживанием
системы.
Каждый из стандартов и методологий имеет свою уникальную
классификацию и подход к управлению требованиями и процессами
разработки
программного
обеспечения.
Они
обеспечивают
структуру и руководство, что позволяет улучшить качество и
надежность программных продуктов.
Вот текстовое представление ментальной карты, соответствующей
типам требований:
Типы требований
├── Функциональные требования
│
├── Описание функций системы
│
├── Взаимодействие с пользователями
│
├── Обработка данных
│
└── Ограничения на входные и выходные данные
│
├── Нефункциональные требования
│
├── Производительность
│
│
├── Время отклика
│
│
└── Пропускная способность
│
├── Надежность
│
│
├── Доступность
│
│
└── Восстановление после сбоев
│
├── Безопасность
│
│
├── Защита данных
│
│
└── Аутентификация и авторизация
│
└── Удобство использования
│
├── Интуитивный интерфейс
│
└── Доступность для пользователей с ограниченными
возможностями
│
├── Ограничения
│
├── Аппаратные ограничения
│
├── Программные ограничения
│
├── Сетевые ограничения
│
└── Законодательные и нормативные ограничения
│
└── Дополнительные требования
├── Совместимость
├── Стандарты
└── Лицензирование
Выводы:
Структурирование
помогает
требований:
структурировать
их,
Классификация
что
облегчает
требований
понимание
и
управление проектом. Четкое разделение на функциональные,
нефункциональные, ограничения и дополнительные требования
позволяет разработчикам и заинтересованным сторонам лучше
воспринимать ожидания и задачи.
Управление проектом: Классификации требований помогают в
управлении проектом, так как позволяют точно определить, какие
требования должны быть выполнены на разных этапах разработки.
Это также упрощает процесс оценки рисков и планирования
ресурсов.
Улучшение коммуникации: Четкая классификация требований
улучшает коммуникацию между членами команды, заказчиками и
заинтересованными
сторонами.
Это
уменьшает
вероятность
недопонимания и ошибок, связанных с требованиями.
Качество продукта: Использование классификаций требований
способствует повышению качества конечного продукта, так как
помогает выявить и учесть все важные аспекты, такие как
производительность, безопасность и удобство использования.
Практические аспекты использования классификаций требований:
Анализ требований: Команды разработки могут использовать
классификации
требований
для
систематического
анализа
и
проверки требований на соответствие, что позволяет избежать
ошибок на ранних этапах разработки.
Документация: Четкая структура требований улучшает качество
документации, позволяя создавать более понятные и доступные
спецификации для команды и пользователей.
Тестирование: Классификации требований могут служить основой
для создания тестовых сценариев и кейсов, обеспечивая, что все
аспекты системы будут протестированы.
Обратная связь: Классификация требований позволяет легче
собирать и анализировать обратную связь от пользователей, что
способствует улучшению продукта в будущих версиях.
Управление
изменениями:
При
изменении
требований
классификация помогает быстро оценить влияние изменений на
проект, что облегчает процесс управления изменениями и адаптации
к новым условиям.
Таким образом, классификация требований является важным
инструментом в процессе разработки программного обеспечения,
способствуя
повышению
качества,
эффективности
и
удовлетворенности пользователей.
Практическое задание 3
Тема 2.3. Функции типов требований
Цель работы: сформировать навыки разработки требований.
Задание. Рассмотрите предметную область и выявите бизнеспотребности.
Опишите
процесс
трансформации
бизнес-
потребностей в бизнес-требования, а затем в функциональные
требования.
Бизнес-потребности в гостиничном бизнесе
В гостиничном бизнесе можно выделить следующие бизнеспотребности:
 Повышение уровня обслуживания клиентов.
 Оптимизация процессов бронирования и регистрации.
 Увеличение доходов от дополнительных услуг (рестораны, спа,
экскурсии).
 Повышение уровня безопасности и защиты данных клиентов.
 Улучшение управления гостиничными ресурсами (номерами,
персоналом).
 Упрощение коммуникаций между персоналом и клиентами.
 Сбор и анализ данных о клиентах для улучшения сервиса.
Процесс
трансформации
бизнес-потребностей
в
бизнес-
требования и функциональные требования
 Бизнес-потребности: Обозначают высокоуровневые цели и
желания бизнеса.
 Бизнес-требования:
Конкретизируют,
что
необходимо
для
достижения бизнес-потребностей. Они более специфичны и
измеримы.
 Функциональные требования: Определяют, какие функции и
возможности должна иметь система, чтобы удовлетворить
бизнес-требования.
Пример трансформации:
 Бизнес-потребность:
Повышение
уровня
обслуживания
клиентов.
 Бизнес-требование: Внедрение системы онлайн-бронирования
с возможностью выбора услуг.
 Функциональные требования:
 Система должна позволять клиентам просматривать
доступные номера.
 Система
должна
предоставлять
возможность
добавления дополнительных услуг (например, завтрак,
транспорт).
 Система
должна
отправлять
подтверждение
бронирования на электронную почту клиента.
Анкета для заинтересованных сторон
Заказчики (клиенты):
1) Какие услуги вы ожидаете от гостиницы при бронировании?
2) Какой способ бронирования вы предпочитаете (онлайн, по
телефону, при личном визите)?
3) Что для вас важнее при выборе гостиницы: цена, качество услуг
или расположение?
4) Как вы оцениваете уровень обслуживания в нашей гостинице?
5) Какие дополнительные услуги были бы для вас интересны
(например, транспорт, экскурсии)?
6) Как вы предпочитаете получать информацию о специальных
предложениях?
7) Какие проблемы вы сталкивались при бронировании или
проживании?
Персонал гостиницы:
1) Какие трудности вы испытываете в процессе регистрации
гостей?
2) Как
вы
оцениваете
бронированиями?
текущую
систему
управления
3) Какие функции в системе управления гостиницей вам не
хватает?
4) Как часто возникают проблемы с коммуникацией между
отделами?
5) Какие дополнительные инструменты могли бы упростить вашу
работу?
6) Как вы собираете обратную связь от клиентов?
7) Какие возможности для повышения качества обслуживания вы
видите?
Управляющий гостиницей:
1) Какие ключевые показатели эффективности вы отслеживаете?
2) Как вы оцениваете уровень доходов от дополнительных услуг?
3) Какие проблемы вы видите в текущих процессах управления
ресурсами?
4) Как вы собираете и анализируете данные о клиентах?
5) Какие
изменения
в
системе
управления
вы
считаете
необходимыми?
6) Какие возможности для сокращения затрат вы видите?
7) Как вы оцениваете уровень удовлетворенности клиентов?
Анализ полученной информации
После анкетирования заинтересованных сторон можно выявить
следующие проблемы и потребности:
 Нехватка удобного и интуитивно понятного интерфейса для
онлайн-бронирования.
 Потребность в интеграции системы бронирования с другими
услугами гостиницы.
 Необходимость улучшения коммуникации между отделами
(рецепция, уборка, ресторан).
 Желание клиентов получать персонализированные предложения
на основе их предпочтений.
 Потребность в более эффективном управлении отзывами и
обратной связью от клиентов.
Преобразование
потребностей
в
бизнес-требования
и
функциональные требования
Бизнес-потребности
Бизнес-требования
Функциональные
требования
Повышение уровня
Внедрение системы
обслуживания клиентов онлайн-бронирования с
Система должна
позволять клиентам
возможностью выбора
просматривать
услуг
доступные номера и
добавлять
дополнительные
услуги.
Оптимизация
Интеграция системы
Система должна
процессов
бронирования с
отправлять
бронирования и
другими услугами
подтверждение
регистрации
гостиницы
бронирования на
электронную почту
клиента.
Увеличение доходов от
Предоставление
Система должна
дополнительных услуг
персонализированных
анализировать
предложений для
предпочтения клиентов
клиентов
и предлагать
соответствующие
услуги.
Улучшение управления
Внедрение
Система должна
гостиничными
комплексной системы
обеспечивать
ресурсами
управления ресурсами
возможность
и персоналом
отслеживания
занятости номеров и
управления графиками
персонала.
Упрощение
Разработка системы
Система должна
коммуникаций между
обратной связи для
позволять клиентам
персоналом и
клиентов и
оставлять отзывы и
клиентами
автоматизация
получать ответы от
обработки запросов
персонала гостиницы.
Сбор и анализ данных о Внедрение системы
Система должна
клиентах для
аналитики для
собирать данные о
улучшения сервиса
управления данными о
предпочтениях
клиентах
клиентов и
генерировать отчеты
для анализа.
Таким образом, процесс трансформации бизнес-потребностей в
бизнес-требования и функциональные требования является важным
этапом в разработке системы для гостиничного бизнеса. Он
позволяет
четко
определить,
какие
функции
необходимо
реализовать,
чтобы
удовлетворить
потребности
клиентов
и
улучшить качество обслуживания.
Практическое задание 4
Тема 3.1. Методы и инструменты выявления требований к
программному обеспечению
Цель
работы:
сформировать
навыки
работы
с
набором
инструментов для выявления требований.
Задание. На основе результатов задания 3 разработать контекстную
диаграмму, диаграмму вариантов использования и модели процесса
«КАК ЕСТЬ» и «КАК БУДЕТ».
Разработка
контекстной
диаграммы,
диаграмм
вариантов
использования и моделей бизнес-процессов «КАК ЕСТЬ» и «КАК
БУДЕТ» для гостиничного бизнеса включает несколько этапов. Вот
пошаговое руководство, как это можно сделать:
Контекстная диаграмма
Контекстная диаграмма описывает взаимодействие гостиницы с
внешними субъектами и системами. Она показывает, какие внешние
объекты взаимодействуют с гостиничной системой и какие данные
обменяются между ними.
Пример контекстной диаграммы для гостиничного бизнеса:
 Основные участники:
 Гости: резервируют номера, запрашивают дополнительные
услуги, оплачивают.
 Администраторы: управляют бронированиями, проверяют
оплату, регистрируют гостей.
 Поставщики: доставляют товары (еда, напитки, оборудование
и т.д.).
 Бухгалтерия: обрабатывает платежи и выставляет счета.
 Системы
онлайн-бронирования (например,
Booking.com):
отправляют информацию о бронированиях и передают
данные о платежах.

Информация на диаграмме:
 Входы: бронирование, оплата, запросы на обслуживание.
 Выходы: подтверждение бронирования, квитанция об оплате,
заказ товаров у поставщиков.
Диаграмма вариантов использования
Диаграмма вариантов использования (use case) для гостиничного
бизнеса
описывает
основные
взаимодействия
участников
с
системой. Она показывает, какие действия могут выполнять
пользователи, такие как бронирование номера, регистрация гостей,
обслуживание номеров и т.д.
Основные варианты использования:
1. Бронирование номера
 ID: UC-1
 Предусловие: пользователь выбрал гостиницу и доступные
даты для проживания.
 Главные актеры: Гость.
 Второстепенные актеры: Администратор, Система онлайнбронирования.
 Основной поток:
1. Гость выбирает даты и тип номера.
2. Система проверяет наличие свободных номеров.
3. Гость подтверждает бронирование.
4. Система отправляет подтверждение бронирования.
5. Постусловия:
Номер
забронирован,
гость
получает
подтверждение.
2. Регистрация гостя
 ID: UC-2
 Предусловие: гость прибыл в гостиницу.
 Главные актеры: Администратор.
 Второстепенные актеры: Гость.
 Основной поток:
1. Администратор проверяет бронирование.
2. Гость предоставляет удостоверение личности.
3. Администратор оформляет регистрацию и выдает ключ.
4. Постусловия: Гость зарегистрирован, данные добавлены в
систему.
3. Выезд гостя
 ID: UC-3
 Предусловие: Гость завершил проживание.
 Главные актеры: Администратор.
 Второстепенные актеры: Бухгалтерия.
 Основной поток:
1. Гость информирует администратора о выезде.
2. Администратор проверяет счет и подтверждает оплату.
3. Система закрывает бронирование.
4. Постусловия: Гость выехал, номер освобожден.
4.Заказ дополнительных услуг
 ID: UC-4
 Предусловие: Гость зарегистрирован в гостинице.
 Главные актеры: Гость.
 Второстепенные актеры: Обслуживающий персонал.
 Основной поток:
1. Гость делает заказ (например, заказ еды в номер).
2. Персонал обрабатывает запрос и выполняет заказ.
3. Гость получает услугу.
4. Постусловия: Услуга предоставлена.
Модели процесса «КАК ЕСТЬ» и «КАК БУДЕТ» (BPMN)
Процесс «КАК ЕСТЬ» (текущая ситуация)
Эта модель показывает текущий процесс работы гостиницы,
включая возможные неэффективности или задержки.
 Основные шаги:
1. Гость делает запрос на бронирование.
2. Администратор проверяет наличие свободных номеров
вручную.
3. Гость получает подтверждение бронирования.
4. По прибытии гость проходит регистрацию на стойке.
5. В конце проживания гость проходит процесс выезда, включая
оплату вручную.
 Недостатки:
 Ручной процесс проверки номеров.
 Очереди на регистрацию и выезд.
 Могут быть проблемы с учетом заказов дополнительных
услуг.
Процесс «КАК БУДЕТ» (с улучшениями)
Эта модель описывает целевой процесс с улучшениями, такими
как
автоматизация
бронирования
и
упрощение
процедуры
регистрации.
 Основные улучшения:
1. Гость
бронирует
номер
через
систему
онлайн-
бронирования, интегрированную с внутренней системой
гостиницы.
2. Система автоматически проверяет доступность номеров и
отправляет подтверждение.
3. По
прибытии
гость
может
использовать
самообслуживание для регистрации через киоск или
мобильное приложение.
4. Во
время
проживания
гость
может
заказывать
дополнительные услуги через приложение.
5. При выезде счет автоматически обрабатывается, и гость
может покинуть отель без задержки.
Пример BPMN диаграммы для «КАК ЕСТЬ» и «КАК БУДЕТ»:
 Пулы:
Гость,
Администратор,
Система
бронирования,
Бухгалтерия.
 Процессы:
 Для «КАК ЕСТЬ»: более последовательные шаги, возможно,
с ручной проверкой и очередями.
 Для «КАК БУДЕТ»: добавлены автоматизированные задачи,
киоск самообслуживания, мобильное приложение для заказов
и оплаты.
Эти модели помогают визуализировать текущее состояние и
потенциальные улучшения процессов в гостиничном бизнесе.
Использование контекстной диаграммы и диаграммы вариантов
использования облегчает понимание взаимодействия участников, а
BPMN помогает наглядно показать, как изменится процесс при
переходе к целевому состоянию.
рактическое задание 5
Тема 3.3. Область и схема разработки требований
Цель работы: сформировать навыки разработки требований к
программному обеспечению.
Задание. Разработать требования к программному обеспечению
заданной предметной области.
Требования к программному обеспечению для гостиничного
бизнеса
1. Функциональные требования:
 Управление бронированием:
 Возможность
создания,
редактирования
и
отмены
бронирований.
 Уведомления о статусе бронирования.
 Каталог услуг:
 Просмотр доступных услуг и цен.
 Фильтрация услуг по различным критериям (цена, тип,
доступность).
 Пользовательский интерфейс:
 Удобный интерфейс для клиентов и администраторов.
 Мобильная версия сайта или приложения.
2. Нефункциональные требования:
 Производительность:
 Быстрая загрузка страниц.
 Параллельное обслуживание нескольких пользователей.
 Безопасность:
 Защита персональных данных клиентов.
 Шифрование данных при передаче.
Анкета для пользователей
 Как часто вы пользуетесь услугами гостиниц?
 Какие критерии для вас наиболее важны при выборе гостиницы?
(цена, расположение, услуги и т.д.)
 Оцените ваш опыт использования существующих систем
бронирования (от 1 до 5).
 Что бы вы хотели улучшить в процессе бронирования?
 Как вы узнали о нашей гостинице? (реклама, рекомендации,
интернет и т.д.)
 Что для вас важнее: цена или качество услуг?
 Какие дополнительные услуги вы бы хотели видеть в гостинице?
Анализ полученной информации
На основе ответов анкеты можно выявить основные предпочтения
и потребности пользователей.
Важно учесть, что большинство пользователей ценят удобство и
простоту интерфейса, а также наличие дополнительных услуг.
Системные требования к программному обеспечению
Аппаратные требования:
 Сервер для размещения базы данных и веб-приложения.
 Резервное копирование данных на внешние носители.
Программные требования:
 Операционная система: Windows Server или Linux.
 Система управления базами данных: MySQL или PostgreSQL.
 Язык программирования: Python, Java или PHP
Диаграмма компонентов
Эта диаграмма отражает основные компоненты системы, их
взаимодействие и потоки информации.
Практическое задание 6
Тема 3.4. Спецификации требований к программному
обеспечению
Цель работы: сформировать навыки разработки спецификации
требований к программному обеспечению.
Задание. Создайте схему спецификации требований к вашему
программному обеспечению по следующему шаблону.
Спецификация требований к программному обеспечению для
гостиничного бизнеса
1. Введение
1.1. Цель
Цель данного документа — определить спецификации для
разработки программного обеспечения для гостиничного бизнеса,
включающего управление бронированиями, учет клиентов и
операции по управлению гостиницей.
1.2. Целевая аудитория
 Разработчики программного обеспечения
 Тестировщики
 Менеджеры проектов
 Заинтересованные стороны из разных отделов: руководство,
маркетинг, продажи
 Персонал
гостиницы
(администраторы,
обслуживающий персонал)
1.3. Использование по назначению
менеджеры,
Программное обеспечение предназначено для автоматизации
процессов
управления
гостиницей,
упрощения
управления
бронированиями и улучшения клиентского обслуживания.
1.4. Сфера применения
Программное обеспечение будет использоваться в различных
типах гостиниц: от небольших семейных гостиниц до крупных
отелей и курортов. Оно будет интегрировано с другими системами,
такими как платежные системы и платформы бронирования.
1.5. Определения и сокращения
 CRM (Customer Relationship Management) — Управление
взаимоотношениями с клиентами
 PMS (Property Management System) — Система управления
объектами недвижимости
2. Общее описание
2.1. Потребности пользователей
Пользователи требуют простоты в использовании, доступности
нужной информации и быстрого доступа ко всем функциям системы
для повышения качества обслуживания.
2.2. Предположения и зависимости
 Система будет функционировать на платформах Windows и
Linux.
 Пользователи имеют базовые знания в работе с компьютером.
 Система должна взаимодействовать с платежными шлюзами и
системами учета.
3. Системные характеристики и требования
3.1. Функциональные требования
1. Регистрация клиентов и управление профилями.
2. Управление бронированиями (создание, изменение, отмена).
3. Управление финансами (выдача счетов, обработка платежей).
4. Отчеты по occupancy (заселение) и доходам.
5.
Настройки
—
изменение
параметров
работы
системы
(например, номера, ставки).
3.2. Требования к внешнему интерфейсу
 Приложение должно иметь интуитивно понятный графический
интерфейс.
 Поддержка нескольких языков (например, русский, английский,
испанский).
 Адаптивный интерфейс для работы на различных устройствах
(ПК, планшет, мобильный телефон).
3.3. Особенности системы
 Высокая скорость обработки данных.
 Поддержка многопользовательского доступа.
 Возможность интеграции с социальными медиа и сторонними
сервисами для маркетинга.
3.4. Нефункциональные требования
 Система должна быть надежной и иметь уровень доступности
99.9%.
 Должен быть механизм резервного копирования данных.
 Обеспечение безопасности личной информации клиентов.
4. Остальные требования
4.1. Целевая платформа
Программное обеспечение должно быть доступно как в виде
настольного приложения, так и в веб-формате.
4.2. Технические ограничения
Ограничения по выделяемым ресурсам (память, процессор) для
обеспечения работы в условиях высокой нагрузки в сезон.
4.3. Документация
 Потребуется разработать полную документацию пользователя.
 Предоставить руководство для администраторов системы.
Эта спецификация служит основой для дальнейших этапов
разработки программного обеспечения. Все заинтересованные
стороны будут вовлечены в обсуждения и сбор обратной связи для
улучшения итогового продукта.
Цель программного продукта и предполагаемая аудитория
пользователей
Целью программного продукта является создание эффективной и
интуитивно понятной системы управления гостиничным бизнесом,
которая
позволит
автоматизировать
процессы
бронирования,
управления клиентами и учета финансов. Это повысит качество
обслуживания, упростит операции для персонала и предоставит
аналитические данные для улучшения бизнеса.
Предполагаемая аудитория пользователей
Разработчики — ответственные за создание и техническую
поддержку системы.
Тестировщики —
занимающиеся
проверкой
программного
обеспечения на предмет ошибок и соответствия требованиям.
Менеджеры проектов — контролирующие сроки и ресурсы
разработки.
Персонал
гостиницы —
администраторы,
менеджеры,
обслуживающий персонал, использующие систему в повседневной
работе.
Заинтересованные стороны из других отделов — руководство,
отделы продаж и маркетинга, использующие данные для принятия
стратегических решений.
Сфера применения и перспектива программного продукта
Программное
обеспечение
охватывает
различные
аспекты
управления гостиничным бизнесом, включая:
 Управление бронированиями и клиентами
 Обработка платежей
 Генерация отчетов по доходности и загрузке
 Интеграция с другими системами (например, CRM, бухгалтерия)
Перспектива программного продукта
Программный продукт будет работать в связке с другими
приложениями и системами гостиничного бизнеса. Блок-схема
может выглядеть так:
Ссылки и другие ресурсы
 Платформы бронирования, такие как Booking.com и Airbnb
 Платежные системы, такие как PayPal и Stripe
 Инструменты аналитики, такие как Google Analytics
3. Общий обзор продукта и ограничения
Общий обзор продукта
Программное обеспечение предназначено для автоматизации
процессов управления гостеприимством на всех уровнях. Оно
включает в себя интерфейс для работы персонала, а также
предоставляет аналитические данные руководству для принятия
решений.
Среда применений
Программное обеспечение будет работать как на настольных, так
и на мобильных устройствах, поддерживая многоуровневый доступ
и возможности для интеграции с существующими системами.
Известные ограничения, предположения и зависимости
Система предполагает наличие доступа к интернету для работы с
платежными шлюзами.
Необходимость
обучения
персонала
работе
с
новыми
технологиями.
Зависимость от сторонних API для интеграции с другими
сервисами.
4. Функции системы и их приоритет
 Функции системы
 Управление бронированиями (высший приоритет)
 Выдача счетов и обработка платежей (высший приоритет)
 Отчеты по загрузке и доходности (средний приоритет)
 Управление профилями клиентов (средний приоритет)
 Настройки и интеграции (низкий приоритет)
5. Конкретные функциональные требования
 Регистрация и управление клиентскими профилями.
 Возможность создания, изменения и отмены бронирования.
 Обработка и хранение данных о платежах.
 Генерация отчетов по заполненности и доходам.
 Интерактивный
календарь
для
управления
доступными
номерами.
 Поддержка многопользовательского доступа с различными
уровнями прав.
6. Логические характеристики пользовательского интерфейса
Логические характеристики
Главный экран: интуитивно понятный интерфейс с основными
разделами на видном месте (Бронирования, Клиенты, Отчеты).
Форма бронирования: заполнение полей с выбором даты, типа
номера, с автоматической проверкой доступности.
Панель управления: доступ к статистике, уведомлениям и
настройкам в виде виджетов для быстрого доступа.
Мобильный
смартфонов,
интерфейс:
адаптируемый
обеспечивающий
оптимизированным дизайном.
основные
интерфейс
для
функции
с
7. Нефункциональные требования
 Производительность:
время
отклика
системы
не
должно
превышать 2 секунд на этапе загрузки и обработки данных.
 Надежность: система должна функционировать без сбоя в
течение 99.9% времени.
 Безопасность: обеспечение защиты личных данных клиентов с
использованием шифрования.
 Поддержка:
система
должна
обеспечивать
техническую
поддержку пользователям в рабочее время.
 Масштабируемость: возможность добавления новых функций и
модулей без значительного изменения базовой структуры
системы.