Методы и средства инженерии программного обеспечения
Трассирование требований - часть 2
Механизмы трассировки должны учитывать следующее:
1) вместо простых связей вводить более сложные отношения (например, транзитивное отношение для выделения цепочек связей) или вводить специфические отношения;
2) использовать сложные и гибкие пути трассировки;
3) поддержать базы данных объектов трассировки и отношений между ними.
Желательно наличие механизмов поддержки возможностей объектно-ориентированного программирования, операций над классами, а также механизмов унификации функций и отношений (1:1, 1:N, N:M), уничтожение и изменение связей, установка стандартных связей.
Трассировка может быть выборочной для определенных объектов, беспорядочной проверкой объектов, связанных с другими объектами, а также с возможными переходами от одного объекта к другим. Она проводится с использованием механизмов поддержания контекста и отношений, соответствующих данной ситуации (например, трассировка с регулярными выражениями, когда контекст может быть изменен только при модификации соответствующего регулярного выражения).
Человеческий фактор. Любой процесс постановки требований напрямую связан с умением людей контактировать друг с другом, кооперироваться или эффективно распределять разноплановые производственные функции между собой. Необходимо уметь достигнуть соглашения в спорных вопросах, касающихся дизайна или технических решений. Организационные функции не должны выходить за рамки понимания проблемы. Важно чтобы лица, работающие над проектом на разных уровнях, имели возможность эффективно общаться друг с другом.
Технологии проекта должны обращать внимание на динамику людских отношений в коллективе. Они должны способствовать эффективному достижению согласия и управления разногласиями, давать возможность снижать сложность отношений в группе сотрудников, работающих над проектом, особенно в повседневной работе при создании высококачественного продукта.
Наиболее привычной и результативной моделью отношений между заказчиком и проектировщиком является модель типа «учитель – ученик».На практике заказчик наблюдает за работой проектировщика системы. Когда заказчик его не беспокоит, проектировщик обращает внимание на примеры и сам отвечает себе на возникающие вопросы. В порядке исключения, заказчик может остановить свою работу, обдумать поставленный вопрос для пояснения и удовлетворения проектировщика.
Это даже помогает разработчику разобраться в деталях своей работы и избавляет его от описания излишних абстракций. Проектировщик должен сформировать свои независимые идеи относительно проектировки будущей системы и постоянно консультироваться с заказчиком, что избежать ошибок на самых ранних этапах проектирования системы Использование данной модели на практике возможно только при хороших взаимоотношениях между заказчиком и исполнителем проекта.
