Время — деньги. Создание команды разработчиков программного обеспечения
Шрифт:
Мы в NuMega всегда пытались сделать выпуск каждого продукта волнующим событием, претендуя на самый короткий срок его создания, либо на первенство в использовании новых технологий, вплоть до того, что целью ряда наших проектов было получение премий в нашей отрасли. Вот ряд идей, которые в прошлом позволили эффективно объединить наши усилия по разработке:
• закрыть путь на рынок новым конкурентам, предоставив программистам на языке C/C++ продукт с самым полным набором функций по обнаружению ошибок;
• создать продукт для анализа производительности, самый простой в эксплуатации во всей отрасли, и добиться признания этого факта;
• создать самый мощный
Мы руководствовались этими идеями при выборе функций продукта и в процессе их реализации. Они также играли главную роль, когда приходилось идти на компромисс. Например, если приходилось выбирать одну из двух взаимоисключающих возможностей, достаточно было одного взгляда на центральную идею проекта, чтобы стало ясно, какую из них выбрать.
Сформулировав центральную идею проекта, надо сосредоточиться на потребностях пользователя. На этом этапе процесса формулирования требований следует рассматривать те проблемы, что необходимо решить пользователю, а не конкретные действия, которые он хотел бы выполнять. Возьмём в качестве примера одну из формулировок идеи проекта из предыдущего раздела. Если нужно предоставить программистам на C/C++ наиболее полный продукт для обнаружения ошибок, то надо выяснить, какие ошибки являются наиболее распространёнными и труднее всего поддаются обнаружению. Вот ещё один пример: если нужен самый простой в использовании продукт для анализа производительности, нужно понять, какие сведения о производительности критичны для пользователей и в каком виде они хотели бы их получить.
Чтобы понимать пользовательские проблемы, важно поддерживать обратную связь с клиентами для проверки сделанных предположений. Лучший способ убедиться в разумности своих планов и преодолеть внутренние разногласия — иметь обратную связь, заслуживающую доверия.
Из собственного опыта
При работе над BoundsChecker 3.0 было много прений вокруг набора функций продукта. Несколько недель обсуждения этого предмета, порой доходившего до жарких споров, прошли без видимого прогресса. Было принято совместное соглашение оставить этот вопрос, чтобы избежать возобновления споров. Чтобы выйти из тупика и поднять боевой дух группы, мы решили пригласить группу заказчиков и потенциальных пользователей на вечеринку с угощением и раздачей призов. Там мы продемонстрировали разные идеи о возможных функциях программы и попросили приглашённых высказать своё мнение. На основе информации извне стало намного легче прийти к компромиссу и выработать решение, у которого были неплохие шансы на успех.
Формулирование требований
Когда установлено общее видение проекта и достигнуто понимание пользовательских проблем, пора переходить к определению требований. Как сформулировать требования, насколько подробными должны быть формулировки и как ничего не упустить?
Один из лучших способов дать чёткое описание набора требований к проекту — представить его в виде схемы. Самый высокий уровень схемы занимают общие требования. Они объединяют совокупности частных требований, которые, таким образом, можно обсуждать, оценивать, сравнивать и утверждать как единое целое. Нужно иметь возможность анализа общих
• разработать интерфейс на базе браузера;
• повысить производительность до уровня, приемлемого для Web-пользователей;
• организовать рассылку уведомлений о выполнении заказов по электронной почте;
• добавить к программе новые возможности, которые повысят производительность пользователей;
• предусмотреть применение в будущем в качестве клиентской платформы карманных компьютеров.
Каждое общее требование должно подразделяться на несколько частных. С последними могут быть связаны и другие требования, конкретизирующие или поясняющие функциональность требований более высокого уровня. В результате документация может принять такой вид:
• Общее требование 1
•• Частное требование 1
••• Частное требование нижнего уровня 1.1
••• Частное требование нижнего уровня 1.2
•• Частное требование 2
••• Частное требование нижнего уровня 2.1
••• Частное требование нижнего уровня 2.2
Ниже приводится пример некоторых общих и частных требований, организованных в соответствии с вышеописанной структурой.
• Разработать интерфейс на базе браузера для приложения по обработке заказов.
• Функциональные требования.
•• При размещении заказа:
••• Ввести для каждого заказа следующую информацию (по пунктам).
••• Проверить идентификатор покупателя.
•• Удалить заказ.
•• Проверить статус заказа.
•• Сгенерировать подтверждение заказа.
• Обеспечить поддержку следующих браузеров:
•• Microsoft Internet Explorer версии X.
•• Netscape версии Y.
• Производительность должна быть приемлема для Web-пользователя.
• Требования ко времени реакции системы:
•• Размещение заказа должно занимать менее 3 секунд.
•• Удаление заказа должно занимать менее 6 секунд.
•• Проверка статуса заказа должна занимать менее 4 секунд.
•• Подтверждение заказа должно занимать менее получаса.
• Облегчить использование приложения с помощью новых возможностей:
•• Разрешить заказ нескольких товаров в одном заказе.
•• Разрешить пользователю просмотр его идентификатора покупателя.
Как видно из этого примера, каждое общее требование включает набор поддерживающих его требований, которые конкретизируют или разъясняют содержание «родительского». Каждое поддерживающее требование сформулировано просто и ясно, что позволяет легко проследить его реализацию в данном выпуске ПО. Следует расширять степень детализации спецификации требований, пока не будут описаны все ключевые элементы функциональности и вы не останетесь довольны созданным описанием.
Определение требований должно быть полным. Рассмотрите все аспекты нового выпуска, даже те, что нельзя свести к набору частных требований. Далее приводится список общих категорий требований, применимый практически ко всем проектам по созданию программ. Я не предлагаю использовать этот список в том виде, в каком он представлен здесь, хотя возможно и такое; однако при составлении собственного списка требований рассмотрите каждую из следующих категорий.