Глава 3: Типы тестов ... 59

При анализе и оценке требований к продукту и его функциональных характеристик специалисты прежде всего пытаются выяснить следующее.

• Адекватны ли эти требования? Действительно ли именно такой продукт компания хочет создать?

• Полны ли они? Не упущены ли какие-нибудь еще полезные или даже жизненно необходимые функции? Нельзя ли ослабить какие- либо из перечисленных требований?

• Совместимы ли требования между собой? Требования к продукту (и его функции) могут оказаться логически или психологически несовместимыми. Логическая несовместимость означает их противо­речивость, а психологическая — концептуальные разногласия (разоб­равшись с одной из функций, пользователь может не понять другую).

• Выполнимы ли они? Не требуется ли для нормальной эксплуатации продукта более быстрое аппаратное обеспечение, больший объем памяти, более высокая пропускная способность, большее разреше­ние (и т.д.), чем указано в документации?

• Разумны ли они? К сожалению, качество продукта и его рентабель­ность стоят по разную сторону баррикад: с одной стороны — про­изводительность продукта, его надежность и нетребовательность к ресурсам, а с другой — время и стоимость его разработки. Найдено ли самое оптимальное соответствие между всеми этими характери­стиками? Не требуется ли от продукта абсолютная безупречность, молниеносная работа и готовность конкурировать с программным обеспечением, которого еще нет и в проекте, — и все это на ком­пьютерах i286? Отдельные из тих требований вполне достижимы, но не одновременно и не для одного и того же продукта. Поэтому одним из ключевых вопросов планирования является правильная расста­новка приоритетов.

• Поддаются ли они тестированию? Насколько легко можно будет определить, соответствует ли инженерно-проектная документация требованиям к программному продукту.

Если вам нужно будет выполнить анализ требований к продукту, опи­райтесь на перечисленные выше вопросы. О других важных проблемах и соображениях на эту тему можно почитать у Данна (Dunn, 1984), Гауса и Вейнберга (Gause & Weinberg, 1989) и в документе ANSI/IEEE Standard 830.

Ну а теперь, выяснив, что прежде всего интересует группу аналитиков, давайте перейдем к более подробному обсуждению методов их работы.

60 Часть I: Основы

Сравнительный анализ существующих программных продуктов

Чтобы выполнить сравнительный анализ продуктов, специалист выяс­няет, какие похожие продукты уже имеются на рынке и чем продукт его фирмы будет от них отличаться. Что поможет выиграть в конкурентном соревновании? Какие функции имеющихся продуктов необходимо вклю­чить и в свой?

Для такого анализа необходимы или рабочие копии конкурирующих продуктов, или, по крайней мере, их демонстрационные версии или опи­сания, если ничего больше достать не удастся. Составляется перечень их функций, их сильных и слабых сторон и тех характеристик, которые отме­чаются в прессе и профессиональных изданиях как достоинства и недостат­ки этих продуктов. Продукты разделяются по занимаемым ими сегментам рынка или по специфическим назначениям. Затем составляется детальный отчет обо всех конкурирующих продуктах, включая и те, которые только собираются появиться на рынке. В отчет включается четко структурирован­ное описание каждого продукта, и такое же описание составляется для будущего продукта компании. На основании отобранных таким образом данных можно ответить на ключевые вопросы проводимого анализа. На­сколько конкурентоспособен разрабатываемый продукт? Почему потенци­альные пользователи захотят купить именно его?

Вначале такой анализ ведет к расширению требований к продукту и его функциональных характеристик. Специалисту хочется реализовать в нем все лучше, что имеется у конкурентов, воплотить в нем сотни почерпну­тых им замечательных идей. Но тут наступает самое время вспомнить о здравом смысле. Реализация всех этих идей стоит слишком дорого и не может быть выполнена в реальные сроки. Кроме того, они основаны на различных концепциях и просто не уживутся в одной программе. Но даже если отобрать из них только совместимые с выбранной концепцией, про­граммный продукт, имеющий столько функций (пусть даже самых распрек­расных), будет таким сложным и громоздким, что едва ли кому-нибудь понравится. (За дополнительной информацией по этому вопросу обратитесь к книгам Рубенштейна и Херша (Rubenstein & Hersh, 1984) и Нормана (Norman, 1988)).

Бывает, что специалисты игнорируют проблемы совместимости функ­ций и сложности программного продукта. Они составляют длинный список удачных идей конкурентов. Сам по себе этот список может быть очень полезным, но если рассматривать его как требования к продукту, тогда его нужно очень серьезно сократить. И помогут отобрать самое существенное два следующих метода: дискуссионные группы и обследование объекта.