Смекни!
smekni.com

Задачи и внедрение Бизнес-стратегия Стратегия в области ит основные тенденции развития ит (стр. 51 из 98)

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

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

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

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

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

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

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

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

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

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

Документ о завершении внедрения системы подписывают заказчик и разработчик.

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

Тестирование систем

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

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

"Рис. 22. Разработка программного обеспечения"

Методы и подходы тестирования

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

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

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

Тестирование по блокам заключается в проверке блока отдельно от остальной системы. Обычно блок представляет собой функцию или небольшой набор функций (библиотеки, классы), которые выполняются одним программистом. Основная отличительная характеристика блока состоит в том, что он достаточно небольшой по объему для проведения тщательной проверки, которую можно назвать исчерпывающей. Обычно тестирование "белый ящик" проводится разработчиками. Небольшой размер блоков позволяет обеспечить высокий уровень проверки кодов. Таким образом легче обнаружить и устранить ошибки на данном уровне тестирования.

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

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

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

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

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