Читаем The Programmers` Stone (Программистский камень) полностью

Недавно возник большой интерес к "Реинженирингу бизнес-процессов" (`Business Process Re-Engineering' -- BPR). Это практика изучения бизнес-процессов для определения, можно ли их улучшить, и часто это необходимо сделать просто потому, что со временем изменилась природа бизнеса организации. Иногда превозносят точку зрения, что программная инженерия всегда включает значительный компонент BPR, поскольку в противном случае потребитель обнаружит, что компьютерная система автоматизирует бизнес-процесс, не учитывающий появление компонентов, которые руководство реализовало в ответ на потребности бизнеса, и систему ожидает крах. Таким образом, первая обязанность инженера-программиста -- помочь потребителю понять природу их собственных требований. В примере простейшей программы -- это кристаллизация желания из общего ощущения дискомфорта в специфическую потребность в большей освещенности. Инженер-программист руководствуется в этой работе дисциплиной, накладываемой необходимостью писать программу для компьютера. В работающем коде невозможно скрыть неоднозначности, как это можно сделать в текстовом отчете. Полезные ТП, таким образом, составляют настолько ясное понимание потребностей пользователя, насколько это возможно в начале проекта, как это понято пользователем и инженером, на языке пользователя. ТП обязательно потребуют уточнения в дальнейшем, по мере того, как дисциплина программирования выявит неоднозначности, независимо от того, будут ли эти поправки включены в документ или нет.

Причина, которая вызывает большую путаницу -- двоякое назначение ТП. С точки зрения инженера ТП должны быть живым документом, но из соображений коммерческих и правовых он занимает место эталонного документа на все время работы над проектом. Эти две цели совершенно различны. Когда они смешиваются, мы получаем комедию инженеров, не обремененных юридическими знаниями (что на самом деле так), пытающихся написать "Декларацию независимости", в то время как критические моменты бизнес процессов остаются неисследованными.

Иногда единственный способ выйти из этого положения -- написать два документа. Один определяет контрактный минимум и, если придерживаться некоторых методик, может быть с успехом написан полностью пользователем. Другой -- это живой, внутренний документ, который говорит нам, что же "приведет пользователя в восторг". Это то, чем мы стараемся руководствоваться в его интересах. Как удовлетворить пользователя, если единственной подсказкой как это сделать, является нечто, служащее нашим коллегам из коммерческого подразделения на поле закона? Рамки, до которых потребитель видит "настоящие ТП" зависят от коммерческих соображений.

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

Требования к программному обеспечению

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

Говорят, скульптор думает о своей законченной работе, как о заключенной внутри глыбы камня или куска дерева, и которую нужно оттуда извлечь, отсекая лишнее. Это помогает. Точно так же, мы можем представить себя глядящими глазами пользователя на наше творение в один из дней в будущем. Если мы смотрим на него используя свойства (черты) системы, мы можем спросить себя: "Как это должно быть реализовано?" Тогда очень легко получить описание потребностей пользователя на языке инженера-программиста.

Архитектурный проект