Ортиков Камронбек 3-прак. Практическая работа 3 по дисциплине Введение в программный инжиниринг Ортиков Камронбек Мамарасул углы
 Скачать 41.98 Kb.
|
|
МИНИСТЕРСТВО РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ РЕСПУБЛИКИ УЗБЕКИСТАН ТАШКЕНТСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ ПРАКТИЧЕСКАЯ РАБОТА № - 3 по дисциплине «Введение в программный инжиниринг» Выполнил: Ортиков Камронбек Мамарасул углы Проверил: Ишмухамедов Азиз Хамидуллаевич Ташкент 2022 Задание: Составление планов верификации, валидации и инспекции на программный модуль, "Кадровое агентство". Содержание: Разработка ТЗ. Разработка плана верификации. Разработка план валидации. 1. Разработка ТЗ на верификацию Как известно — грамотный подход к разработке ТЗ избавляет от множества проблем на протяжении всего проекта. ТЗ на верификацию должно описывать полный и всеобъемлющий набор функций и возможностей блока, которые необходимо проверить. В идеале ТЗ на верификацию должен писать тимлид группы верификации. Это крайне важно в особенности при малом опыте работы верификатора, который будет заниматься тестированием. В состав ТЗ должно входить следующие пункты: • перечисление всех блоков, которые будут входить в состав "Кадровое агентство" и работу которых необходимо проверить; • перечисление всех режимов работы, функций, возможностей "Кадровое агентство" , которые требуют проверки; • перечисление функций и классов ТО, которое будет использоваться повторно из других "Кадровое агентство" (к примеру набор функций по расчету контрольных сумм или по работе с интерфейсами передачи данных). Естественно, написание ТЗ должно начинаться после получения всей необходимой информации по данному "Кадровое агентство". 2.1 Разработка плана верификации Процесс планирования возможно самый важный и наиболее пренебрегаемый этап функциональной верификации. Создание плана верификации определяется разработкой стратегий и тактик работы с "Кадровое агентство" до его начала. План верификации представляет собой руководство для команды по работе с "Кадровое агентство". Без грамотного плана верификации команды часто выбирают неправильный путь поиска ошибок. План верификации включает набор всех тестов с подробным описанием. План верификации главный документ для команды верификации ПЛИС. Вся последующая работа будет основываться на этом документе. Все «забугорные монстры» систем на кристалле Synopsys и Cadence рекомендуют начинать с плана верификации перед началом разработки ТО. По сути план верификации представляет более подробное ТЗ на верификацию. В подробном описании каждого теста должно быть указаны все необходимые программируемые параметры, текущие режимы работы, входные, выходные и эталонные данные. 2.2 Разработка ТО Надо помнить, что разработка конфигурации ПЛИС и разработка ТО должны начинаться и выполняться параллельно. Данный порядок оптимален с точки зрения минимального времени разработки проекта, потому как процессы верификации занимают более 70% времени разработки всего "Кадровое агентство". На основании информации всех предыдущих этапов можно приступать к созданию тестового окружения (далее ТО). ТО принято писать на языках программирования созданных специально для целей верификации, потому как они имеют весь необходимый инструментарий для этого. System Verilog один из наиболее подходящих языков. Данный язык довольно сильно похож на С++ вместе с инкапсуляцией, полиморфизмом, наследованием. При разработке тестового окружения требуется очень рекомендуются не забывать о «реюзабельности». Если нет подходящих функций, то написать их с учетом возможного использования в будущем. Если же есть функций, то использовать. Требуется организовать ТО так, чтобы каждый тест мог модифицироваться без возможности повредить другие тесты. Это избавит от проблем в будущем, потому как в процессе проведения тестов все равно придется вводить какие-то изменения в код ТО. 2.3 Тестирование На данном этапе верификатору приходится наиболее плотно работать с разработчиком. Во время проведения тестов будут обнаруживаться ошибки, а они будут обнаруживаться. Если не будут – значит ваше ТО работает неправильно. После обнаружения ошибки требуется сообщить разработчику об ошибке. Затем после исправления верификатору требуется запустить тест повторно и убедиться, что ошибка устранена. Идеальным образом было бы использование систем баг-трекинга для осуществления связи между верификатором и разработчиком. Это позволит позже отследить какие проблемы часто встречаются в том или ином проекте, или у того или иного разработчика. А заодно и будет доказательством, что верификатор не зря ест свой хлеб. Я полагаю следует добавить, что не каждый разработчик и не всегда признает свои ошибки. В данном случае требуется ссылаться на ТЗ, в котором должно однозначно описана работа "Кадровое агентство". План валидации На производстве проводят оба вида проверки: и валидацию, и верификацию. Результаты верификации дают ответ на вопрос: «Выполнены ли установленные требования к объекту?» Само по себе соблюдение этих требований уже позволяет выпустить продукт, который можно использовать по назначению. Результаты валидации отвечают на вопрос: «Можно ли использовать объект по его назначению?» Это страховка от ситуаций, когда требования к объекту установили ошибочно и они не соответствуют реальности. На Таймыре МЧС пользуется техникой, которую разрабатывали для спасательных работ в условиях Крайнего Севера и бездорожья. Техника соответствует техническим нормативам и заявкам, но спасатели все равно потом дорабатывали ее под себя ретроспективно: утепляли, усиливали конструкции, добавляли дополнительные отсеки. Валидация на производстве проходит в шесть шагов. Шаг 1. Спецификация требований. Собирают в один документ ожидания и требования пользователей "Кадровое агентство". Шаг 2. Спецификация функций. Принимают решение, как нужно изменить "Кадровое агентство", чтобы выполнить требования пользователей. Компания решает, что нужно укоротить сотрудники для работы и улучшить место работы, чтобы нанять больше сотрудников. Шаг 3. Техническая спецификация. Описывают все технические и проектные характеристики "Кадровое агентство" и процесса его структуры. Шаг 4. Оценка монтажа. Подтверждают, что "Кадровое агентство" соответствует требованиям и стандартам. Шаг 5. Проверка функционала продукта. Проверяют "Кадровое агентство" на соответствие требованиям спецификации функций. Шаг 6. Проверка эксплуатации. Проверяют, как работает готовый продукт "Кадровое агентство" в реальных условиях. Компания проверяет, сможет ли программа так работать с загрузкой. После всех этапов валидации можно ожидать, что продукт "Кадровое агентство" будет использоваться по назначению успешно. Требования к программным средствам, используемым программой Системные программные средства, используемые программой, должны быть представлены локализованной версией операционной системы. Основой для системы должна стать база данных, в которой будет храниться вся информация. База данных включает в себя следующие таблицы: Соискатель, Заказчик, Вакансия. |