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

Определение функциональности

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

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

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

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

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

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

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

Функциональная спецификация

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

Функциональная спецификация занимает объем не более 30 страниц и состоит из следующих элементов.

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

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

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

Рис. 6.4. Уникально определенные с помощью иерархической нумерации функциональные требования

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

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

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

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

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

увеличить изображение
Рис. 6.5. Титульная страница демонстрационной функциональной спецификации

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

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

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