Подраздел Контрольный пример — документ, позволяющий осуществить полную проверку функционирования разработанного программного обеспечения.
Подраздел Контрольный пример должен включать следующие пункты:
— назначение, основные функции;
В «назначении» должны содержаться перечень параметров и краткая характеристика функций, проверяемых с помощью контрольного примера.
Пункты «исходные данные» и «результаты расчета» должны включать соответственно описания исходных и результатных данных для проверки программы (комплекса программ) и сами эти данные (данные можно разместить в соответствующие приложения).
Заключительный пункт «проверка программы» должен содержать описания процедур формирования исходных данных, вызова проверяемой программы и получения результатов расчета, а также инструкции для работы оператора (пользователя) при подготовке исходных данных и в процессе проверки программного комплекса.
Процесс проверки функционирования программы должен сопровождаться рисунками и подробными описаниями действий программы.
Контрольный пример в 1С. Что это, как делать и зачем?
4.5.2.4 Руководство оператора (пользователя)
Структура и оформление программного документа «Руководство оператора (пользователя)» устанавливаются в соответствии с ГOCT 19.105 — 78. Руководство оператора должно содержать:
— сведения о назначении программы и информацию, достаточную для понимания функций программы и ее эксплуатации;
— условия, необходимые для выполнения программы (минимальный и (или) максимальный состав аппаратных и программных средств и т. п.);
— последовательность действий пользователя, обеспечивающих загрузку, запуск, выполнение и завершение программы; описание функций, возможных вариантов команд, с помощью которых пользователь осуществляет загрузку и управляет выполнением программы, а также ответы программы на эти команды;
— тексты сообщений, выдаваемых в ходе выполнения программы, описание их содержания и соответствующие действия пользователя (в случае сбоя, возможности повторного запуска программы).
Воспользуйтесь поиском по сайту:
studopedia.org — Студопедия.Орг — 2014-2023 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.009 с) .
Источник: studopedia.org
Большая Энциклопедия Нефти и Газа
Разработка контрольного примера сводится к подготовке исходных данных, на которых можно было бы испытать программу или комплекс программ. В том случае, когда контрольный пример предназначается для проверки правильности результатов, получаемых с помощью программ, разработка контрольного примера не ограничивается лишь выбором данных, которые нужно использовать для испытания программ. Необходимо также вручную рассчитать ожидаемые промежуточные и / или окончательные результаты. Это не всегда возможно, если учесть сложность процедур обработки, реализуемых некоторыми программами. Тем не менее следует попытаться вручную определить ожидаемые вели чины некоторых наиболее важных результатов или хотя бы диапазоны возможных значений. [2]
Как учителя проверяют тетради!
Разработка контрольных примеров ( и определение ожидаемых результатов), проведение испытаний программ и их отладка требуют длительной и напряженной работы ( пятый главный этап, разд. Однако эта работа должна быть выполнена особенна тщательно, поскольку именно от нее зависит эффективность решения задачи. [3]
Это происходит потому, что разработка контрольных примеров начинается сразу после составления спецификации испытаний и продолжается вплоть до последнего дня испытаний. Правда, все тесты, перечисленные в спецификации испытаний, должны быть подготовлены до-окончания фазы программирования, после чего создаются лишь те контрольные примеры, которые будут предложены на основе результатов испытаний в фазе оценки. [5]
Все положения, высказанные в отношении разработки контрольного примера для оценки характеристик комплекса программ каждого функционального блока ( разд. Кроме того, следует учесть факторы экономического и финансового характера. Это означает, что, как только будут известны потребности в ресурсах и во времени ( машинном и сетевом), окажется возможным пересчитать оценки затрат на эксплуатацию задачи, полученные на этапе функционального анализа ( см. разд. [6]
По тем же причинам, которыми объяснялась — выше необходимость разработки контрольного примера для оценки объемно-временных характеристик каждого программного блока, контрольные примеры для оценки общих характеристик комплексов программ каждого функционального блока должны быть подготовлены на этапе алгоритмического представления задачи. [7]
На заключительном этапе проектирования задачи осуществляются: уточнение задания на программирование, разработка и описание макроблок-схемы программы, разработка и описание микроблок-схемы программы, разработка программы в условных адресах, разработка программы в действительных адресах, разработка дополнительных вспомогательных программ и стандартных подпрограмм, необходимых для данной задачи, отладки отдельных частей программы, комплексная отладка программы на контрольном примере; описание программы, разработка контрольного примера . [8]
РЗО — внешние спецификации утверждены; Р31 — составление внутренних спецификаций завершено; Р40 — начаты испытания класса А; Р41 — демонстрация изделия проведена; Р42 — приемочные испытания проведены; О10 — требуемые по проекту средства установлены; ОН — информационный листок выпуска готов к печати; О12 — информационный листок выпуска издан; О20 — изделие передано на распространение; Б01 — план выпуска документации составлен; Б02 — подготовка справочных материалов начата; Б10 — план выпуска документации утвержден; Б11 — техническое редактирование начато; Б12 — утверждение справочных материалов начато; Б20 — справочные материалы готовы к печати; Б21 — справочные материалы изданы; И01 — план испытаний составлен; И10 — план испытаний утвержден; И11 — спецификации испытаний составлены — И12 — разработка контрольных примеров начата; И13 — спецификации испытаний утверждены; ИД) — состав приемочных испытаний определен; ИЗО — начаты испытания класса В; И31 — последний цикл испытаний начат; И32 — отчет об испытаниях класса В издан; Д01 — план поддержки составлен; Д1С — план поддержки утвержден; Д11 — рекламные интервалы подготовлены; Д12 — рекламные материалы сданы в печать; Д13 — план обучения издан; Д20 — рекламные материалы распространены; Д21 — учебные пособия подготов-лены; ДЗО — обучение закончено; С10 — внесение изменений запрещено; С20 — спецификация сопровождения готова. [10]
Разработка контрольного примера сводится к подготовке исходных данных, на которых можно было бы испытать программу или комплекс программ. В том случае, когда контрольный пример предназначается для проверки правильности результатов, получаемых с помощью программ, разработка контрольного примера не ограничивается лишь выбором данных, которые нужно использовать для испытания программ. Необходимо также вручную рассчитать ожидаемые промежуточные и / или окончательные результаты. Это не всегда возможно, если учесть сложность процедур обработки, реализуемых некоторыми программами. Тем не менее следует попытаться вручную определить ожидаемые вели чины некоторых наиболее важных результатов или хотя бы диапазоны возможных значений. [11]
В этом случае разработчики затратят массу сил и времени на отладку самих тестов; общение между ними и испытателями будет происходить на очень низком уровне взаимопонимания; наконец, у руководства появится ложное чувство уверенности в изделии, которое скоро будет рассеяно плохой репутацией программных средств среди потребителей. Если группа испытаний сложилась таким образом, как было описано выше, то по крайней мере ее ядро должны составлять в высшей степени компетентные и опытные люди, знающие свое дело. Из хороших проектировщиков и программистов редко получаются хорошие испытатели. Чаще всего они выходят из среды системных программистов или специалистов по прикладному системному анализу ( либо из персонала группы поддержки, помогающей потребителям в освоении программных изделий), а также из среды специалистов, занимающихся обучением пользователей. В хорошо организованной группе испытаний должны быть предусмотрены самостоятельные пути служебного роста для людей, чья деятельность связана с прогоном тестов, разработкой контрольных примеров , составлением планов и спецификаций испытаний, критическим анализом проектных решений. [12]
Источник: www.ngpedia.ru
Сдача-приемка на контрольном примере
Одним из самых проблемных моментов любой доработки или любой проектной задачи является сдача-приемка. Очень многие разработчики даже не задумываются об этом неизбежном финале его текущей работы. Очень часто, спросив программиста или консультанта о том, как он собирается сдавать обсуждаемые доработки заказчику, приходится наблюдать настоящее смятение или полную беззаботность. А простое (и, казалось бы, очевидное) указание ни в коем случае не заниматься задачами, которые невозможно сдать , довольно часто вызывает горячие возражения со стороны разработчика.
Какие задачи принципиально невозможно сдать? В первую очередь это задачи, сформулированные общими словами: «Чтобы все хорошо работало». Затем это задачи, в которых заказчик слабо представляет себе конечный результат. Наконец, это разработка программных функций, результат которых заказчик не может увидеть, когда что-то в системе пересчитывается или оптимизируется, но убедится в этом пользователю крайне сложно или невозможно, потому что в его рабочем месте ничего не происходит.
Конечно, иногда можно просто убедить заказчика подписать протокол выполнения работ или акт используя его доверие к вам и вашей компетентности, объяснив необходимость и важность выполненных работ. Но гораздо лучше работать так, чтобы заказчику не приходилось напрягать свое доверие слишком часто. Ведь легко представить себе ситуацию, когда заказчик доверился вам, а программисты подвели, и сделали задачу плохо или неправильно.
Даже если задача поставлена и сформулирована так, что проверить ее выполнение в принципе можно, это не означает, что она будет сдана. При сдаче-приемке часто возникают споры между разработчиком и заказчиком относительно данных, на которых следует проверить работу созданной функции.
Заказчик может требовать провести все больше и больше проверок, и сдача может затянуться, а в конце вы вполне можете услышать «Ну, мне надо тут еще потестировать, и когда я все проверю – приму работу». При сдаче пользователь может выполнить действия, которые разработчик не предусматривал. В проверку могут попасть данные, возможность которых разработчик не учел, а может быть их просто еще не было в системе на момент постановки задачи. На работу созданной вами функции может повлиять доработка, внесенная собственным программистом заказчика. В общем, если о процедуре сдаче-приемки не подумать заранее, ее результат может быть каким угодно.
Для того, чтобы исключить сюрпризы при сдаче-приемки задачи по программной доработке, лучше всего использовать метод контрольных примеров. Он заключается в том, что при постановке задачи вы заранее договариваетесь с заказчиком о том, на каких конкретных данных вы будете проводить сдачу-приемку.
Контрольный пример состоит из трех простых компонентов:
— Сценарий демонстрации;
— Входные данные;
— Выходные данные.
Процедура проведения сдачи-приемки заключается в том, что для проверки работы созданной вами функции разработчик совместно с заказчиком производит в системе действия, описанные в сценарии демонстрации. Если при этом нужно ввести какие-то данные, они вводят то, что указано, как входные данные контрольного примера. Если при завершении сценария в системе сформировались данные, соответствующие выходным данных контрольного примера, то задача сдана.
Например, мы сдаем доработку по помещению части поступивших на склад товаров в «карантин». В сценарии указано, что необходимо создать документ «Приходный ордер на товары». Состав товаров, количество и склад ордера указаны, как входные данные.
Далее надо заполнить созданную разработчиком закладку «Карантин», состав и количеств товаров, направленных в «карантин», также указано, как входные данные. Затем надо провести документ. Для получения информации о товарах в «карантине» нужно сформировать созданный вами отчет «Карантин». Результат отчета должен совпасть с выходными данными контрольного примера.
Состав контрольного примера для каждой задачи готовится либо самим заказчиком или разработчиком (за деньги!) с последующим обязательным согласованием с заказчиком. Контрольный пример должен учитывать все возможные варианты действия созданной или доработанной функции системы или, по крайней мере, все наиболее частые случаи. Чем больше будет пример, тем качественнее будет выполнена разработка и тем надежнее будет сдача-приемка. Заказчик заинтересован в полноте контрольного примера, но, в тоже время, от крайностей его удерживает необходимость самому подготовить его или оплатить вам его подготовку.
Сдача-приемка на контрольном примере никогда не делается в рабочей базе. Только в специально существующей для этого копии! Потому что данные в рабочей базе могут непредсказуемо измениться, ведь в ней ежедневно ведется работа пользователей. А нам для достижения уверенности в том, что написанный нами код работает правильно, нужно быть уверенным в том, что никаких сюрпризов в данных нет. В документе, описывающем контрольный пример, можно так и написать: сдача-приемка выполняется на контрольном примере, подготовленным в копии рабочей базы от такого-то числа.
Очень важно еще на старте проекта договориться с заказчиком, что после сдачи-приемки на контрольном примере задача считается выполненной. Если заказчик хочет провести дополнительное тестирование – ради Бога, подписывай протокол выполнения работ или акт, и тестируй сколько душе угодно! Разумеется, если контрольный пример при сдаче не проходит, то есть выдаются ошибки или результат прохождения сценария не похож на выходные данные, то задача – не сдана, и отправляется на устранение замечаний. А все новые идеи и пожелания, возникшие у заказчика при сдаче-приемке (в том числе и выявление некорректной работы системы на каких-то данных, не вошедших в пример) считаются новыми требованиями, и реализуются в рамках новой задачи за отдельные деньги.
Не все задачи непременно требуют контрольного примера. Надо помнить, что главная цель этого подхода – дать заказчику возможность убедится, что задача выполнена. Есть тривиальные требования, например, изменение дизайна форм, где убедится в выполнении задачи можно и без контрольного примера. Но любая задача сложнее изменение цвета кнопок потребует контрольного примера.
Разумеется, иногда приходится сталкиваться с задачами, для которых придумать контрольный пример не так просто, и для этого нужно хорошенько поломать голову. Но решение, как правило всегда находится. Если же сдать задачу на контрольном примере совсем невозможно (допустим, что такая ситуация все же иногда возникает), это повод для отдельных договоренностей с заказчиком.
Сдача на контрольном примере – обязательный элемент всех серьезных методик разработки информационных систем. Например, в ГОСТе контрольный пример скрывается под видом документа «Программа и методика испытаний», про который проектировщики часто забывают, ограничиваясь техническим заданием. А в SRUM контрольный пример мимоходом описан, как «критерий готовности» или Definition of Done, (DoD).
Для руководителя проекта главная ценность контрольного примера в том, что он позволяет полностью устранить какую-либо неопределенность относительно того, сдана задача или нет, что существенно облегчает управление проектом и очень сильно снижает все риски, связанные со сдачей-приемкой.
Источник: sstud.ru