В основе всей разработки ПО лежат требования, которые могут быть сформулированы в форме простого запроса на изменение. Проекты по обслуживанию предоставляют возможность испробовать новые методы разработки требований безопасно и в малом масштабе. Заманчиво считать, что небольшое улучшение не означает необходимости написания требований. Давление, которое оказывается при выпуске следующей версии, может заставить вас решить, что у вас нет времени на требования. Но усложнение проектов позволит вам постепенно обучаться. Таким образом, к следующему крупному проекту вы будете чувствовать себя опытным и уверенным, применяя эффективные приемы при разработке требований.
Предположим, отдел маркетинга или клиент требуют добавления к уже сформированному продукту новой функции. Изучите эту функцию с точки зрения вариантов использования, обсудив с инициатором запроса задачи, которые клиенты будут выполнять с ее помощью. Если до этого вы не имели дела с вариантами использования, попробуйте задокументировать их с помощью стандартного шаблона, как показано на рис. 8-6. Если вы опробуете приемы работы с вариантами использования, то снизите первоначальный риск их применения в проекте, разрабатываемом с нуля, поскольку именно от вашей квалификации может зависеть успех или неудача. Вы можете опробовать в малом масштабе и другие приемы при обслуживании продукта, например:
· создание словаря данных (глава 10);
· рисование моделей анализа (глава 11);
· определение атрибутов качества и целей производительности (глава 12);
· построение пользовательского интерфейса и технических прототипов (глава 13);
· проверку спецификации к требованиям (глава 15);
|
|
· написание вариантов тестирования на основе требований (глава 15); определение критерия приемлемости для пользователей (глава 15).
Перемещайтесь по цепочке трассируемости
Требования трассируемости данных помогут программисту по обслуживанию определить, какие компоненты следует модифицировать после изменения определенного требования. Однако в плохо задокументированной действующей системе информации о трассируемости нет. Когда кому-то из вашей команды доведется модифицировать существующую систему, он должен позаботиться о создании частичной матрицы трассируемости требований для того, чтобы связать новые или измененные требования с соответствующими элементами проектирования, кода и вариантами тестирования. Собирать связи трассируемости по мере разработки не сложно, тогда как воссоздать их в завершенной системе — практически нереально.
| Дополнительная информация Глава 20 посвящена трассируемости требований. |
Из-за возникновения «кругов на воде» при многих модификациях вам необходимо убедиться, что каждое изменение требования корректно сказывается на продуктах, связанных с разрабатываемым. Отличный способ проверить согласованность изменений — экспертиза. Ниже перечислены четыре точки зрения (им посвящена Глава 15), которые должны представлять эксперты; это касается и тех, кто занимается обслуживанием:
· автора требований - при модификациях или улучшениях;
· клиента, инициирующего запрос, или представителя отдела маркетинга, которые могут подтвердить, что в новых требованиях точно описаны необходимые изменения;
|
|
· разработчиков, тестировщиков или других сотрудников, которые будут работать, руководствуясь новыми требованиями;
· людей, на чью работу могут повлиять вносимые изменения.
Обновляйте документацию
Все существующие представления требований следует обновлять по мере обслуживания, чтобы они адекватно отражали возможности модифицируемой системы. Если обновление обременительно, то им часто будут пренебрегать, поскольку занятые люди стараются сразу перейти к следующему запросу на обновление. А устаревшая документация по требованиям и проектированию вряд ли окажется полезной при дальнейшем обслуживании. В индустрии ПО бытует страх того, что написание документации всегда уходит слишком много времени, поэтому вырабатывается условный рефлекс - пренебрегать всяким обновлением документации к требованиям. Однако какова цена того, что вы не обновляете требования и специалисту по обслуживанию (а, может, им станете вы сами!) придется воссоздавать информацию? Ответив на этот вопрос, вы сможете принять толковое решение о том, следует ли исправлять документацию требований при изменении ПО.