Пример. Пример для 17. Система бронирования железнодорожных билетов
 Скачать 136.39 Kb.
|
|
Пример. Выработка концепции “Система бронирования железнодорожных билетов”. Видение проекта Формулировка видения (vision statement) должна быть достаточно краткой для запоминания, достаточно ясной для понимания и достаточно сильной для мотивирования. Представим возможный вариант. Разработанная система бронирования билетов позволит компании “РЖД” повысить эффективность управления рейсами и даст возможность клиентам компании самостоятельно подбирать маршруты (в том числе с пересадками) с оптимальной стоимостью. Через год разработанное решение позволит компании увеличить число своих клиентов не менее чем в 1.5 раза. Формирование команды Пусть проектная группа состоит из 6 человек. Представим возможное распределение ролей, позволяющее выполнить поставленную задачу. Несмотря на то, что модель проектной группы MSF выделяет ровно 6 ролей, идею о том, чтобы каждому участнику команды выдать по одной роли и на этом успокоиться, следует оставить, как в корне неверную. При таком подходе, мы должны будем взвалить тяжесть разработки системы на одного человека, что, конечно же, не приведет к успеху. Отсюда очевидно, что разработчиков должно быть больше одного, а остальные роли придется совмещать. Во-первых, следуя рекомендациям MSF по объединению ролей, необходимо дать одному из разработчиков еще и роль архитектора. Во-вторых, разработчиками не могут быть все. Отдельный участник команды должен заниматься тестированием. Ему же можно выдать “в нагрузку” роль бизнес-аналитика. Незадействованными остались ролевые группы “Управление программой” и “Управление выпуском”. Соответственно роли менеджер проекта и релиз-менеджер достаются еще одному участнику. В итоге получаем следующее (возможное) распределение: Участник 1 – менеджер проекта и релиз-менеджер Участник 2 – архитектор и разработчик Участник 3 – бизнес-аналитик и тестер Участник 4 – разработчик Участник 5 – разработчик Участник 6 – разработчик Концепция решения Концепция решения (solution concept) предоставляет общее описание подходов, которые проектная группа предполагает использовать для разрешения проблем и/или удовлетворения потребностей заинтересованных сторон. Цели и Задачи Формирование концепции решения начинается с выяснения у заинтересованных сторон, описания и фиксации проектной группой целей проекта. Далее каждая цель разбивается на измеримые компоненты – задачи. В нашем случае цели системы: работать с ж/д вокзалами и рейсами; подобрать клиенту оптимальный маршрут. Задачи системы: решать однокритериальную задачу на графах (критерий – цена); работать с базой данных РЖД; бронировать билеты; … Предположения и Ограничения В процессе формирования концепции решения проектная группа постоянно взаимодействует с заинтересованными сторонами, собирая необходимую информацию о требованиях к функциональности будущего решения. Тем не менее, неизбежная неполнота информации приводит к тому, что относительно некоторых функциональных возможностей решения могут потребоваться предположения (assumptions). Помимо функциональных требований заинтересованные стороны могут выдвигать качественные требования, задающие ограничения на создаваемое решение. Также ограничения могут порождаться средой, в которой должно будет функционировать решение после внедрения. В нашем случае на первый вариант системы накладываются следующие ограничения: система не является распределенной; нет разграничения прав между менеджерами и пользователями; интерфейс системы представлен в одном окне; система должна наглядно демонстрировать формы и способы хранения и взаимодействия данных. Пользователи Основой формулировки требований является анализ использования, включающий определение пользователей (users) и описание того, как пользователи будут взаимодействовать с решением. В системе будет две группы пользователей: Менеджеры РЖД; Покупатели билетов Сценарии использования Сценарии использования (usage scenarios) определяют последовательности действий, которые пользователи выполняют при взаимодействии с решением. MSF не специфицирует явным образом способы описания сценариев использования. Один из возможных (и достаточно распространенных) вариантов – язык UML. Начнем с диаграммы использования.  Затем расшифруем отдельные сценарии.      Рамки Рамки (scope) определяют пространство параметров, в котором будет создаваться решение, детализируя функциональность, определяя, что останется за рамками решения и указывая критерии, по которым заинтересованные лица будут судить о готовности решения. Рамки создаются на основе единого видения, являются результатом компромисса между сформулированными целями и условиями реальности и отражают приоритезацию заказчиком имеющихся требований к создаваемому решению. Частью процесса определения рамок проекта является вынесение менее важной функциональности из текущего проекта в планы на будущее. Рамки решения (solution scope) определяют функциональность решения и его возможности (включая те, что не относятся к программному обеспечению). Возможность (функциональность, составляющая, feature) – это требуемый или желаемый аспект программного или аппаратного обеспечения. Например, предварительный просмотр перед печатью может быть возможностью текстового процессора; шифрование почтовых сообщений – возможностью почтовой программы. Сопроводительные руководства пользователей, интерактивные файлы помощи, операционные руководства и обучение также могут быть составляющими решения. Рамки проекта (project scope) определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения. Функциональность решения Хранилище находится в оперативной памяти Добавление ж/д вокзалов по нажатию кнопки Проверка корректности введены данных Проверка существования ж/д вокзала с введенным номером Создание визуальной формы для отображения ж/д вокзала Добавление рейсов Проверка корректности введены данных Проверка существования рейса с введенным номером Проверка на существование ж/д вокзалов рейса Добавление в визуальные формы ж/д вокзалов информации о добавленных рейсах Удаление ж/д вокзалов Удаление всех сопутствующих рейсов Удаление рейсов Поиск минимального по стоимости маршрута Заказ билетов на найденные маршруты За рамками решения Распределенное хранилище не будет реализовано в первой версии Раздельное приложение для менеджеров и клиентов не будет реализовано в первой версии Поиск всех имеющихся маршрутов не будет реализован в первой версии Фаза планирования Результатами фазы планирования являются: Функциональная спецификация. План управления рисками. Сводный план и сводный календарный график проекта. Шаблон спецификации 1. Введение. 2. Общее описание 3. Функции системы 4. Требования к данным 5. Требования к внешним интерфейсам 6. Атрибуты качества 7. Требования по интернационализации и локализации 8. Остальные требования 1. Введение 1.1. Назначение Эта спецификация требований к “Системе бронирования железнодорожных билетов” описывает функциональные и нефункциональные требования к выпуску ИС. Этот документ предназначен для команды, которая будет реализовывать и проверять корректность работы системы. 1.2. Границы проекта “Система бронирования железнодорожных билетов” позволит сотрудникам предлагать наилучшие варианты и бронировать билеты через Интернет. Детальное описание продукта приведено в сопутствующей документации, где перечислены функции, полная или частичная реализация которых запланирована в этом выпуске. 2. Общее описание 2.1 Общий взгляд на продукт “Система бронирования железнодорожных билетов” – это система, которая заменяет текущие ручные процессы поиска и бронирования билетов. Контекстная диаграмма на рис.1 показывает внешние объекты и системные интерфейсы. Предполагается выпустить несколько версий системы, чтобы в конечном итоге удалось встроить ее в систему бронирования, работающую через Интернет. 2.2. Классы и характеристики пользователей
2.3. Операционная среда “Система бронирования железнодорожных билетов”работает со следующими браузерами: … “Система бронирования железнодорожных билетов”установлена на сервере, работающем под управлением текущих утвержденных корпорацией версий … “Система бронирования железнодорожных билетов”. должна допускать доступ пользователей через корпоративную интрасеть, VPN-канал и со смартфонов и планшетов под управлением Android, iOS, Windows. 2.4. Ограничения дизайна и реализации Документация системы по дизайну, коду и сопровождению должна соответствовать Process Impact Intranet Development Standard. Система должна использовать текущую версию СУБД Oracle, являющуюся корпоративным стандартом. Весь код HTML должен соответствовать стандарту HTML 5.0. 3. Системные функции 3.1. Описание Клиент, личность которого подтверждена, может забронировать билет. Клиент может отменить бронь. Приоритет — высокий. 3.2. Функциональные требования
4. Требования к данным 4.1. Словарь данных
4.2. Отчеты
5. Требования к внешним интерфейсами5.1. Пользовательские интерфейсыЭкраны “Система бронирования железнодорожных билетов”должны соответствовать «Process Impact Internet Application User Interface Standard 2.0». “Система бронирования железнодорожных билетов” должна обеспечивать ссылку на справку на каждой HTML-странице, объясняющую, как пользоваться этой страницей. Интернет-страницы должны предоставлять полную возможность навигации и выбор блюд только при помощи клавиатуры, в дополнение к использованию мыши и клавиатуры. 5.2 Интерфейсы ПО Система учета запасов ж/д вокзалов “Система бронирования железнодорожных билетов” должна передавать количество единиц забронированных билетов в систему учета ж/д вокзалов через программный интерфейс. “Система бронирования железнодорожных билетов” должна опрашивать систему учета запасов для определения наличия запрашиваемого билета. Когда система учета запасов сообщает “Система бронирования железнодорожных билетов”, что определенного билета нет в наличии, “Система бронирования железнодорожных билетов” должна убирать это направление на текущую дату. Передавать запрос на оплату приобретенного билета. Возвращать полностью или частично предыдущую оплату, если клиент отменил заказ. 5.3. Интерфейсы оборудования Интерфейсы оборудования не выявлены. 5.4. Коммуникационные интерфейсы “Система бронирования железнодорожных билетов” должна отправлять клиенту сообщение электронной почты или СМС-сообщение (определяется параметрами учетной записи) с подтверждением бронирования и ценой. “Система бронирования железнодорожных билетов” должна отправлять клиенту сообщение электронной почты или СМС-сообщение (определяется параметрами учетной записи) о любых проблемах, возникших с бронированием. 6. Атрибуты качества 6.1. Требования по удобству использования Система должна позволять клиенту извлечь ранее забронированные билеты одной операцией. 95 % новых пользователей должны суметь успешно забронировать без ошибок с первой попытки. 6.2. Требования к производительности Все веб-страницы, генерируемые системой, должны полностью загружаться не более чем за 4 секунды после запроса их по интернет-подключению со скоростью 20 Мбит/сек. Система должна выводить пользователю сообщение о подтверждении в среднем за 3 секунды и не более чем через 6 секунд после того, как пользователь отослал информацию системе. 6.3. Требования безопасности Все сетевые транзакции, включающие финансовую или поддающуюся учету личную информацию, должны быть зашифрованы. Пользователи обязательно регистрируются для входа ивыполнения всех операций. Система должна позволять только сотрудникам, внесенным в список авторизованных менеджеров меню, создавать или изменять наличие билетов. Система должна позволять клиентам просматривать только заказы, размещенные ими лично, но не другими клиентами. 6.4. Требования к надежности Если соединение между пользователем и системой разрывается до того, как заказ подтвержден или отменен, “Система бронирования железнодорожных билетов” должна позволять пользователю восстановить незавершенный заказ и продолжить работу. |