Требования удовлетворены?

Цель тестирования — продемонстрировать корректность ПО и выявить дефекты, касающиеся программных функций, ПИ, справочной системы, средств обучения, времени отклика, надежности и других важных аспектов ПО. Тестирование выявляет ошибки, за счет дополнительной разработки ПО конструируются исправления, кото­рые применяются к ПО, а дополнительное тестирование проверяет корректность ис­правлений и отсутствие новых ошибок как результат исправления предыдущих.

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

Функциональные дефекты. Обычно дефекты функциональности иден­тифицируются, классифицируются по серьезности и отслеживаются до тех пор, пока они не будут устранены до истечения назначенного срока. Если критерий по количе­ству открытых дефектов различной серьезности не превышен, программный продукт считается пригодным к развертыванию (например, если отсутствуют дефекты 1-го и 2-го уровня серьезности или имеется менее 10 дефектов 3-го уровня серьезности).

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

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

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

Уступки, компромиссы и неожиданности

Аналогично другим этапам разработки ПО, конструирование изобилует неожи­данностями, вследствие которых приходится идти на уступки или прибегать к ком­промиссам. Зачастую возможны приемлемые варианты проектных решений, которые позволяют удовлетворить требования в рамках ограничений. Иногда подобные вари­анты невозможны, и компромиссы снижают некоторые желаемые характеристики системы. Как обычно, следует постоянно привлекать пользователей к участию в про­цессе разработки. Если в конце процесса разработки развернутый проект представля­ет собой разумное приближение первоначальных проектных намерений — это просто отлично!

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

Практический результат. Когда все сказано и сделано, результаты тести­рования оцениваются и выносится решение о готовности продукта к развертыванию. Если некоторые требования не удовлетворены, продукт может быть признан гото­вым к развертыванию при условии составления и ввода в действие плана по исправ­лению недостатков. Если продукт в крайней степени не удовлетворяет стандартам, развертывание откладывается до внесения исправлений или же заказ на продукт ан­нулируется.

Полезное правило. Обычно принятию решения о готовности продукта к раз­вертыванию предшествуют переговоры. В конце концов, развертывание нового продукта должно принести ощутимую выгоду пользователям, разработчикам и ор­ганизациям, финансирующим проект.

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

Закрытие реализации. Прежде чем завершить реализацию, следует сделать несколько полезных шагов, которые вошли в практику разработки.

• Просмотр программного кода.

• Испытания практичности и приемочные испытания.

• Просмотр тестовых прецедентов и результатов.

• Демонстрация проекта для того, чтобы показать, что требования удовлетво­рены.

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

Полезное правило. Запоздалые изменения могут погубить проект.