Составление концептуальной разработки

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

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

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

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

Установка аппартного и программного обеспечения

Целью данного этапа является установка аппаратного и программного обеспечения в среде клиента. В идеале, если подобный проект осуществляется впервые, требуется наличие следующих сред:

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

Среда тестирования – более структурированная среда, где изменения являются более контролируемыми, обычно с помощью планируемого процесса миграции/построения. В этой среде группа тестирования выполняет и оценивает конкретные испытания в соответствии с планом.

Производственная среда – среда непосредственной обработки данных. В ней должны действовать те же средства управления и ограничения доступа, что и в других производственных средах клиента. Иногда программное обеспечение не устанавливается в этой среде, пока оно не будет полностью опробовано в среде тестирования.

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

Определение стратегии испытаний

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

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

Ниже приводятся наиболее значимые компоненты этой стратегии:

Возможность эксплуатировать решение

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

Скорость работы – время реагирования

Рекомендуется эксплуатационное испытание с полным объемом данных и на той же скорости, что и на производстве.

Наличие данных в нужное время

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

Точность и целостность данных

Рекомендуется имитация конверсии (при необходимости многократная), чтобы увидеть, как передаются данные и какого рода ошибки при этом возникают. Обычно цель здесь состоит в очистке данных до их реального запуска в работу.

Надежные точки интеграции систем

Рекомендуется испытание совместимости соответствующих систем. Используются образцы реальных данных, а интеграционные процессы должны имитировать производственную ситуацию.

Обеспокоен ли клиент вопросом взаимодействия разных систем? Не сталкивался ли он с этой проблемой раньше?

Рекомендуется комплексное испытание совместимости.

Обработка и устранение ошибок?

Следует протестировать пользовательские процедуры.

Конечные пользователи с тревогой ожидают перемен или имеют за плечами историю «неработающих систем»

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