Nbsp; Тестирование на этапе разработки требований

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

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

1. Сравнительный анализ

2. Дискуссионные группы и

3. Обследование объекта.

Результаты каждой из этих процедур могут привести к значительному пересмотру существующих планов.

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

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

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

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

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

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

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

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

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

Рекомендуется писать прототипы на том же языке, на котором будет реализован конечный продукт: если про­тотип окажется удачным, то конечный продукт может разрабатываться прямо на его основе. Однако, на наш взгляд, так поступать не стоит, и вот почему.

• Многие языки или системы разработки не подходят для создания быстрого и дешевого прототипа.

• Хороший совет: отложить первый черновик программы и начать ее разработку с чистого листа. Особенно это касается прототипа. Ведь от него не требуется хорошая внутренняя организация. Он может работать медленно и неэффективно, а то и вообще неправильно. Согласитесь, что такая программа не лучшая основа для хорошей разработки. Да и разработчики прототипа будут чувствовать себя гораздо свободнее, если будут думать только о скорости и не беспокоиться, что допущенные ими ошибки и неверные решения впоследствии затруднят программирование.