Процесс разработки программы и методология построения приложений для интернета

Определения и сокращения

• Определить любые потенциально непонятные термины, используемые в данном документе или в сфере деятельности владельца.
• Определить сокращения, используемые в любых местах документа и в сфере деятельности владельца.

Данная область определяет термины для предотвращения путаницы, она также фиксирует номенклатуру проекта. Приводимые здесь названия используются для описания сущностей и предотвращают применение нескольких терминов к одной и той же концепции.

Функциональные задачи

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

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

Вне области

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

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

Допущения

• Указывать любую новую информацию, которая поможет разобраться в деталях программного продукта, влияющих на вынесение решения.

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

Окна программного решения

• Перечислить все окна, являющиеся частью решения. Имена окон должны использоваться в тексте документа.

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

Стиль сайта

• Описать внешний вид и стиль (шрифт, использование браузера и расположение окна) всего сайта в целом.

Данная область не является обязательной. Многие организации придерживаются определенных стилей, определяющих внешний вид сайта, а также обработку определенных условий или расположения окна. Например, следующая инструкция определяет тип расположения окна.

Запрос у конечного пользователя параметров запроса требует открытия нового окна браузера; в противном случае все содержимое отображается в том же самом окне браузера, обеспечивающем переход по сайту. Единовременно открывается не более двух окон браузера для правильного использования сайта.

Области функциональных задач

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

Для каждой функциональной задачи, определенной в области Functional Objectives (Функциональные задачи), должна присутствовать область функциональной задачи. Эта область подробно описывает функциональную задачу: бизнес-логику, которой она принадлежит, способ функционирования (с точки зрения владельца) компонентов решения, относящихся к задаче. Следует определить и обрисовать экранные и системные процессы, привести структуру каждого окна, определить сценарии для успешных и неудачных операций. Общей ошибкой в функциональных задачах является отсутствие описания того, что происходит в случае успешных и неудачных событий. Явное описание разрешенных и запланированных событий конечного пользователя и ожидаемых результатов позволит избежать ошибок при определении функциональности. Например, можно составить таблицу, описывающую события и соответствующие ожидаемые ответы программного решения (см. рис. 6.6).

Рис. 6.6. Демонстрационные сценарии и исключения функциональной спецификации

Приложение

• Представить use-case документацию.
• Представить другую полезную информацию, связанную с функциональностью проекта.

В приложении размещается самая разная информация. Если информация важна для проекта и может пригодится членам команды, работающей над проектом, то ее следует разместить в приложении.

Сбор функциональных требований

Для написания функциональной спецификации ее автор должен знать функциональные требования. Он должен выполнить сбор функциональных требований, консультируясь с бизнес-аналитиком, обсудившим функциональность программного решения с владельцем. Успех данного исследования зависит от места расположения владельца, который либо доступен для беседы с аналитиком, либо не может предоставить необходимую информацию. Бизнес-аналитик помогает владельцу сосредоточиться на важной и полезной для проекта информации, исключая технические детали построения проекта.

Бизнес-аналитик обдумывает информацию, предоставленную владельцем, и создает подробную функциональную спецификацию, после чего команда разработки эффективно разрабатывает программное решение. Аналитик идентифицирует все требования программного решения, начиная с документов, описывающих область работы.

Затем с помощью UML составляются диаграммы use-case бизнес-процессов. Как и многие другие задачи, диаграммы use-case создаются с максимальном количеством деталей для более точного описания бизнес-процессов. Диаграммы UML упрощают документацию use-case и облегчают ее понимание и сверку.

После сбора аналитиком всей необходимой информации use-case она документируется в виде формы или таблицы. Шаблон или форма для документирования информации use-case включает в себя следующие элементы.

• Имя use-case. Короткое информативное имя.
• Идентификатор use-case. Уникальный буквенно-цифровой код.
• Действующие лица. Все конечные пользователи, принимающие участие в use case.
• Предварительные условия. Часть среды, присутствующая в реализации use-case.
• Процесс. Что происходит в процессе use-case.
• Последующие условия. Что представляет собой среда после выполнения use-case.

Например:

Имя: Поиск рецепта.
Идентификатор: UC001.
Действующие лица: Пользователь.
Предварительные условия: Пользователь должен осуществить успешный вход на сайт.

Процесс:

1. Пользователь щелкает на ссылке "Поиск рецепта".
2. В окне браузера открывается окно "Поиск рецепта".
3. Пользователь вводит в диалоговом окне ключевое слово, которое присутствует в искомом рецепте.
4. Пользователь нажимает на клавишу Enter.
5. Окно обновляется с отображением результатов поиска.
6. Если пользователь получает искомое имя рецепта:
   1. Пользователь щелкает на ссылке для получения рецепта.
   2. Рецепт отображается в окне браузера.
7. Если пользователь не получает искомого имени рецепта:
   1. Пользователь вводит новый критерий поиска рецепта в диалоговом окне ввода ключевого слова.
   2. Пользователь осуществляет поиск, до тех пор пока рецепт не будет найден.

Последующие условия: пользователю в окне браузера отображается нужный рецепт.

Такой тип анализа помогает при разработке решений. Шаблон use-case соответствует шаблону функционирования самого кода программы. Секция "Процесс" последовательности use-case является алгоритмом, который является частью создаваемого программного решения.

После проверки и подтверждения владельцем задокументированных последовательностей use-case их связывают с требованиями, определенными владельцем. Если use-case-не соответствуют этим требованиям, то они либо отбрасываются, либо определяются другие требования.

По завершении работы над функциональной спецификацией следует проверить оценку и план, представленные на этапе выявления области работы. Для внесения изменений следует определить вспомогательные функциональные требования, позволяющие увеличить сроки или использовать дополнительные ресурсы. Если владелец согласится с новым расписанием, переходите к выполнению следующего этапа проекта. В противном случае измените область работы для удовлетворения требованиям по доставке готового продукта.