В этой книге описана разработка требований для только создаваемого, нового ПО или системы, т.е. речь идет о проекте с чистого листа (green-field project). Однако многие организации тратят массу сил на обслуживание существующих систем или построение следующих версий уже установленного коммерческого продукта. Другие компании создают новые системы с нуля, вместо того чтобы заняться интеграцией, настройкой и расширением готовых коммерческих (коробочных) продуктов (commercial off-the-shelf, COTS) для удовлетворения своих потребностей. Есть еще и такие, что разработку ПО доверяют сторонним организациям. В этой главе описываются различные приемы работы над требованиями для таких типов проектов, а также для неожиданно возникающих проектов с непостоянными и неопределенными бизнес-потребностями.
Требования к проектам по обслуживанию
Обслуживание (maintenance) означает изменения, вносимые в эксплуатируемое в настоящее время ПО. Иногда на обслуживание, которое часто называют продолжающейся разработкой (continuing engineering или ongoing development), тратится большая часть ресурсов организации, специализирующейся на разработке ПО. Программисты, занимающиеся поддержкой, обычно исправляют ошибки, добавляют новые функции или сообщения к существующим системам, а также приводят функциональность в соответствие с изменившимися бизнес-правилами. Немногие действующие системы имеют адекватную документацию. Тех разработчиков, которые стояли у истоков системы и держали всю информацию в головах, давно уже нет. Приемы, описанные в этой главе, помогут вам разбираться с требованиями для обслуживания и поддержки действующих проектов, чтобы сделать продукт более качественным и лучше выполнять дальнейшее обслуживание (Wiegers, 2001).
| Пропавшая спецификация В спецификации требований для следующей версии сформировавшейся системы часто пишут так: «Новая система должна делать то же, что и старая, кроме того, что будут добавлены новые функции и исправлены ошибки». Как-то аналитик получила именно такую спецификацию для пятой версии важного продукта. Чтобы точно выяснить, что же текущая версия делает, она заглянула в спецификацию требований к четвертой версии этого ПО. К сожалению, по существу там было сказано вот что: «Версия 4 должна делать то же, что и версия 3, кроме того, что будут добавлены новые функции и исправлены ошибки». Она подняла все предыдущие документы, но так и не смогла найти настоящую спецификацию к требованиям. В каждой спецификации пречислялись отличия новой версии от предыдущей, однако нигде не было описания первоначальной системы. Как следствие, у каждого сложилось свое понимание возможностей текущей системы. Если вы оказались в такой ситуации, задокументируйте требования для следующей версии более подробно, чтобы все заинтересованные лица смогли разобраться в том, что же все-таки система делает. |
Начните сбор информации
При отсутствии точной документации к требованиям, специалисты по обслуживанию должны заняться обратной инженерией, т.е. разобраться в функциях системы исходя из ее кода. Я называю эту работу «археологией программного обеспечения». Чтобы она оказалась максимально выгодной, «археологи» должны документировать результаты своих изысканий в форме описания требований или дизайна. Аккуратно фиксируя информацию об определенных частях текущей системы, команда облегчит себе работу по дальнейшему улучшению системы.
Возможно, ваша текущая система представляет собой бесформенный сгусток истории и загадок, как на рис. 16-1. Представьте, что вас попросили реализовать некую новую функциональность в области А на этом рисунке. Начните с документирования новых требований в структурированной, пусть и неполной, спецификации требований к ПО или воспользуйтесь утилитой для управления требованиями. Когда вы добавите новую функциональность, вам придется сообразить, как новые экраны и функции будут взаимодействовать с существующей системой. Эти взаимодействия показаны на рис. 16-1 в виде мостов между областью А и текущей системой. Анализируя ситуацию, вы получите представление о белой области текущей системы — области В. Так вывыявите новую информацию, которую необходимо зафиксировать.
Один из полезных приемов — нарисовать карту диалогов для новых экранов, которые вы собираетесь добавить, показав перемещения от существующих элементов экрана и к ним. Вы также можете воспользоваться и другими приемами моделирования: диаграммами классов и взаимодействия, диаграммами потоков данных и диаграммами «сущность-связь». Контекстная диаграмма или диаграмма варианта использования продукта отображает внешние объекты или лица, взаимодействующие с системой. Еще один способ получения недостающий информации — добавлять в словарь данных новые понятия и изменять существующие определения при добавлении новых элементов к системе.
Рис. 16-1. Добавляя ясный и понятный фрагмент А к аморфной документации уже работающей системы, вы проясняете данные в области В документации
При построении представления требований, в которое включены фрагменты текущей системы, решаются три задачи:
· останавливается непроизводительное растрачивание данных, поэтому специалисты по обслуживанию лучше разбираются в изменениях, внесенных только что;
· собирается информация о текущей системе, которая ранее не была задокументирована. При обслуживании системы команда сможет расширять эти раздробленные представления данных, таким образом, непрестанно улучшая документацию к системе. Растущая стоимость документирования этой вновь найденной информацией невелика по сравнению с ценой, которую кому-то придется заплатить в будущем, чтоб «раскопать» ее заново;
· обеспечивается проверка полноты функциональности системы посредством набора действующих тестов. (С другой стороны набор тестов пригодится в качестве первоначального источника информации при восстановлении требований к ПО.)
Если вам нужно оказать хирургическое вмешательство в ПО в связи с вводом новых, пересмотром старых правительственных постановлений или изменением политики компании, составьте список бизнес-правил, влияющих на систему. Если вы не сделаете этого, вся важная информация останется только в головах членов команды. Поскольку люди по-разному интерпретируют важность влияния бизнеса на ваш проект, раздробленную информацию можно считать жалким вкладом в общее дело.
Множество проблем выявляется на стадии работы над взаимодействующими элементами, включая особенности взаимодействия различных ПО, ПО и оборудования, ПО и людей. При реализации изменений выделите время на документирование обнаруженной информации о текущих внешних пользователях, ПО, оборудовании и коммуникационных интерфейсах. Структурные данные о совместной работе компонентов системы помогут вам в будущем добавлять расширения более безопасно и эффективно. Однажды подрядчику потребовалось внести существенное улучшение в систему управления роботом, над созданием которой работала моя команда. Наши модели дизайна помогли ему, и он смог эффективно совместить новые функции с архитектурой существующей системы. Если бы мы не предоставили эту информацию, подрядчику пришлось заниматься обратной инженерией кода, чтобы разобраться в архитектуре и дизайне.
Разработка полной спецификации требований к ПО для всей производственной системы не всегда целесообразна. Между двумя крайностями — работой безо всякой документацией и воссозданием идеальной спецификации — существует множество промежуточных стадий. Если вы знаете, зачем вам нужны задокументированные требования, то сможете решить, будут ли оправданы затраты на воссоздание всей спецификации или ее части. Чем на более ранней стадии цикла разработки ПО вы находитесь, тем боле ценно наличие задокументированных требований.
Как-то я работал с командой, которая только что начала заниматься требованиями для второй версии крупного продукта со встроенным ПО. Требования для версии, которая в тот момент реализовывалась, были проработаны не очень хорошо. Ведущий аналитик требований желал знать, стоит ли возвращаться и исправлять требования для версии. Руководство же компании полагало, что эта производственная линия будет основных источником дохода в течение по крайней мере 10 лет, а также планировало повторно воспользоваться некоторыми основными требованиями в нескольких побочных продуктах. В этом случае стоило улучшить документацию требований для версии 1, поскольку она лежала в основе всей последующей работы над продуктами этого семейства. Если бы команда в тот момент работала над версией 5.3 предыдущей системы, которую планировалось изъять из производства в течение года, тогда не стоило бы воссоздавать спецификацию требований к ПО.
| От кода через требования к тестированию Компания A. Datum Corporation нуждалась в полном наборе вариантов тестирования для основного продукта, сложного и крайне важного бухгалтерского приложения, разработанного несколько лет назад. Специалисты компании решили воссоздать варианты использования на основе существующего кода, а затем, опираясь на них, разработать варианты тестирования. Сначала аналитик воссоздал диаграммы классов разработанного ПО с помощью средств, способных создавать модели из исходного кода. Затем он составил описания вариантов использования для типичных пользовательских задач, причем некоторые были весьма сложными. Эти варианты использования затрагивали все возможные пользовательские сценарии, а также множество условий исключений. Аналитики нарисовали диаграммы последовательностей UML (Unified Modeling Language — унифицированный язык моделирования) для того, чтобы связать варианты использования и классы систем (Armour и Miller, 2001), И последнее: они вручную собрали большой набор вариантов тестирования, чтобы обработать все нормальные и исключительные случаи вариантов использования. Создавая требования и тестируя функциональность посредством обратной инженерии, вы можете быть уверены, что они отражают реальную систему и ее известные модели использования. |