Известен ряд методов проверки внешних спецификаций. Обычно эти методы не исключают друг друга и рекомендуются для последовательного использования. [c.120]
Ш а г 3. Проверка внешних спецификаций модуля. Желательно, чтобы спецификация для каждого модуля была бы проверена путем сравнения ее с информацией интерфейса, разработанного при проектировании структуры программы. Спецификация данного модуля должна быть просмотрена программистами всех модулей, вызывающих данный модуль. [c.143]
П10 — Р10— сбор запросов пользователей для составления соглашения о требованиях Р10 —П20 —проверка соглашения о требованиях Р10 — Д01 — подготовка плана поддержки Р28 — РЗО — проверка внешних спецификаций Б01 — Б10 — проверка плана выпуска документации Д01—Д10 —реакция на пересмотр плана поддержки Р20 —Д11— подготовка рекламных материалов Д11—Д12 — реакция на пересмотр рекламных материалов ДЮ — Д13 — подготовка плана обучения Д12 — Д20 — издание рекламных материалов РЗО — Д2 — подготовка учебных пособий Б11 — Б12 — проверка первоначальных вариантов справочных материалов Д21 — ДЗО — выпуск учебных пособий И32 — ПЗО — проверка отчета об испытаниях класса В Д20 — О20 — рассылка рекламных материалов. [c.182]
Из рис, 1 3 также видно, что очередной этап деятельности группы поддержки — проверка внешних спецификаций — начинается сразу после начала проверки плана выпуска документов и заканчивается раньше, чем закончится проверка этого плана. Группа разработки представляет внешние спецификации на всеобщее обсуждение для того, чтобы получить конструктивные критические замечания. Так как в это время группа поддержки имеет последнюю возможность повлиять на проект, она самым тщательным образом изучает внешние спецификации и формулирует соответствующие предложения, касающиеся их усовершенствования. [c.183]
Деятельность группы поддержки достигает первого максимума после передачи плана поддержки на рассмотрение в другие группы (рис. 11.2). Как видно из рис. 11.3, группа поддержки одновременно занята подготовкой рекламного материала, проверкой внешних спецификаций и изучением плана выпуска документов. В этот период важно установить определенную приоритетность работ, чтобы уложиться в запланированные сроки. Лучше всего выполнять их по очереди, однако это может значительно увеличить время проектирования. Хотя календарные планы отдельных проектов в чем-то отличаются друг от друга, группа поддержки всегда стремится выполнять свои работы в следующем порядке , сначала изучить внешние спецификации, затем проверить план выпуска документов, отреагировать на замечания к плану поддержки и, наконец, подготовить рекламный материал. Эта очередность работ наилучшим образом соответствует хорошему стилю планирования и требованиям декомпозиции проекта. [c.183]
Другой подход предполагает получение тестовых последовательностей на основе анализа логики программы. Здесь задача заключается в разработке таких тестовых последовательностей, при реализации которых каждая команда программы выполняется по меньшей мере один раз. Основной целью данного метода является проверка логики выполнения всех ветвей программы. При этом тестовая последовательность генерируется без учета внешних спецификаций. [c.166]
При проектировании функционального теста внешнюю спецификацию рекомендуется разделить на частные внешние функции а затем тщательно проверить каждую из. них. Для этих целей могут использоваться подходы, рассмотренные для случая тестирования единичного модуля. Они могут быть распространены на все входные условия и режимы, а также на все границы входных и выходных потоков данных. Эти способы обеспечивают также проверку программы на предмет ее поведения на функциональных границах и при появлении недействительных (ошибочных) или неожиданных данных на входе. . [c.176]
Некоторые из вопросов, поднимаемых в фазовых обзорах, относятся к сфере текущей интерпретации предварительных соглашений. Всякое несоответствие должно устраняться по ходу его обнаружения, будь то результат проверки или обновления более ранних документов. Следует помнить, что соглашение о требованиях всегда должно правильно отражать реальную ситуацию, а внешняя спецификация должна быть в любой момент времени законченным документом, который правильно описывает, что представляет собой программное изделие. Правильное конфигурационное управление требует также, чтобы каждая существующая в данный момент времени версия программного изделия имела свою собственную внешнюю спецификацию или четко изложенное описание в рамках внешней спецификации. Управление созданием программного изделия — своего рода игра, основанная на осуществлении контроля и сведении балансов группа планирования постоянно следит за расхождением между реальным положением дел, связанных с проектированием программного изделия, планами и спецификациями. Механизм рассмотрения и утверждения должен обеспечивать возможность выявления расхождений и последующего их устранения. Технические советы, объединенные комиссии и фазовые обзоры как раз и являются таким механизмом. [c.85]
В фазе программирования группа выпуска документации представляет на рассмотрение ряд вариантов справочных материалов. В середине фазы программирования группой испытаний представляются для рассмотрения спецификации испытаний. Группа разработки тщательно изучает варианты документации и спецификации испытаний с тем, чтобы в них не было ошибок, порожденных неверными исходными предположениями. Если группа разработки в свое время подготовила корректные внешние спецификации, то их анализ не вызовет больших затруднений, хотя и займет немало времени. Если же некоторые положения внешних спецификаций пропущены или изложены недостаточно полно, то их проверка не только отнимет много времени, но и вызовет большие трудности. В этом случае придется изменять внешние спецификации, что может свести на нет запас времени, имеющийся в календарном плане проектирования. [c.113]
Испытания класса В представляют собой независимую проверку программного изделия на соответствие спецификациям, в -частности соглашению о требованиях и внешним спецификациям. Программное изделие считается готовым к проведению испытаний класса В после успешного завершения приемочных испытаний. Группа разработки составляет отчет об испытаниях класса А, подытоживающий результаты этих испытаний, в том числе приемочных, и свидетельствующий о готовности программного изделия к испытаниям класса В. [c.114]
Полная функциональная проверка. Цель этой категории испытаний — показать, что изделие обладает всеми функциональными возможностями, указанными во внешней спецификации, и работает правильно. Если объектом испытаний является новая версия существующего изделия, проверке подвергаются как новые, так и старые функциональные возможности изделия, отдельно и во взаимодействии друг с другом. Испытания этой категории обычно включаются в состав испытаний классов А и В. [c.154]
П10 —утверждено распределение бюджета П20 — утверждено соглашение о требованиях ПЗО — изделие готово к распространению Р10 — представлено соглашение о требованиях Р11 — начата разработка внутренней спецификации Р20 — представлена внешняя спецификация-Р21 — начато программирование РЗО — утверждена внешняя спецификация Р31 — закончена подготовка внутренней спецификации Р40 — начаты испытания класса А Р41 — проведена демонстрация в действии Р42 — выполнен прогон приемочных тестов О10 — установлено оборудование, необходимое для проектирования ОН — информационный листок выпуска готов к печати О12 — информационный листок выпуска издан О20 — закончено распространение изделия Б01 — представлен план выпуска документации Б02 —начата разработка справочных материалов Б10 — утвержден план выпуска документации Б11 —начата техническая проверка Б12 — начато окончательное утверждение документации Б20 — справочные материалы отданы в печать Б21 — справочные материалы изданы И01 — представлен план испытаний И10 — утвержден план испытаний ИП — представлена спецификация испытаний И12 —начата разработка контрольных примеров И13 —утверждена спецификация испытаний И20 — разработаны приемочные тесты ИЗО — начаты испытания класса В И31 — начат последний цикл испытаний И32 —выпущен отчет об испытаниях класса В Д01 — представлен план поддержки Д10 — утвержден план поддержки Д11 — представлены рекламные материалы Д12 — рекламные материалы отданы в печать Д13 — издан план обучения Д20 — распространены рекламные материалы Д21 — подготовлен учебный курс ДЗО — завершен курс обучения СЮ — прекращено внесение исправлений С20 — завершена под- [c.260]
Проверка корректности и полноты внешней спецификации должна проводиться еще до начала программирования с использованием методов, изложенных в работах [58—60]. Независимо от имеющегося опыта составления внешних спецификаций всегда целесообразно перед программированием организовывать рассмотрение этого документа пользователями или их представителями. [c.269]
Исполнительное инвариантное ядро PS продукционной управляющей системы реального времени считывает загрузочные файлы настройки, в которых описаны структура и состав информационной базы прикладной системы продукции управления, контроля, мониторинга, принятия решений и диалога правила разрешения конфликтов данные, необходимые для активации продукций, а также спецификации форматов входных и выходных сообщений и команд, которыми система обменивается с внешними объектами. Эти данные управляют действиями системы в заданном прикладном применении. Внутренняя структура исполнительного ядра системы описана в работах [96-98]. Его основные функции состоят в проверке условий и выполнении действий правил, разрешении конфликтов между ними, выполнении преобразований базы, формировании и выводе команд [c.187]
Для испытания одной внешней функции должна выполняться последовательность действий. Один из проверяющих (не автор спецификаций) разрабатывает сначала ряд тестовых случаев на бумаге для функции список отдельных вводимых данных для функций. Это лицо и автор спецификации далее имитируют ввод этих случаев в систему, используя спецификацию как описание поведения системы. Там, где спецификация не дает точного и полного описания выводимых данных и изменений для конкретного ввода, обнаруживается ошибка. Прежде чем начинается процесс прокрутки, обычно необходимо установить первоначальное состояние системы, такое, как описание первоначального содержания для любого файла, и потом корректировать это описание по мере выполнения преобразований. Этот процесс может быть также использован для испытания сочетаний функций путем генерации тестовых данных, описывающих сложные сценарии вводимых данных. Целью такой проверки является нахождение ошибок, но не исправление на ходу . Исправление ошибок должно быть отсрочено до тех пор, пока все возможные ошибки не будут обнаружены. Также важно иметь кого-нибудь другого, но не автора спецификации, для создания тестовых случаев и объяснения спецификации. [c.121]
Р10 — П20— анализ соглашения о требованиях Р10 — И01 — подготовка плана испытаний И01 — И10 — переработка плана испытаний Р20 — РЗО — проверка внешней спецификации Р29—ИИ—подготовка спецификации испытаний И12 —И20 —разработка контрольных npuMtpoa для приемочных испытаний Р40—И20 — отладка контрольных примеров для приемочных испытаний И12 —ИЗО— разработка контрольных примеров ИЗО — И31 — проведение испытаний класса В ИЗО — Б12 — оценка первоначальных рукописей справочных иятепналон И31 — И32 — проведение испытаний класса В подготовка отчета об испита- [c.164]
При первом подходе предполагается, что проверку построения архитектуры системы выполняют разоаботчики внешних спецификаций и разработчики структуры поог-рамм (каждой компоненты). Разработчики внешних спецификаций проверяют полноту удовлетворения и аккуратность выполнения внешних спецификаций системы. Разработчики компонентов системы проверяют возможности построения предполагаемого компонента и доступность требований архитектуры системы. В связи с тем, что процесс построения архитектуры системы может выполняться параллельно с процессом внешнего проектирования, важно своевременно согласовать выходы и входы этих процессов. [c.129]
Для проверки правильности проведения работ по проектированию системы могут быть применены различные способы Одним из них может быть проверка проект ной документации автором архитектуры системы (авто ром внешних спецификаций) и проектировщиком после дующего процесса (разработчиком модулей) с целью обеспечения работоспособности, понятности, соответствия используемому языку программирования, а также совмес тимости с общей системой, частью которой является проект. [c.138]
Тестирование модуля включает проведение определен ного объема работ проектирование набора тестовых -комбинаций на основе анализа внешних Спецификаций и программы модуля написание программы тестирования-и ее проверку и выполнение- программы тестирования Расемотр>ш содержание этих работ. " [c.173]