Виды испытаний ПС.

Испытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде. Известны следующие виды испытаний ПС, проводимых с целью аттестации ПС: 1) испытания компонент ПС - это проверка (тестирование) работоспособности отдельных подсистем ПС. Проводятся только в исключительных случаях по специальному решению аттестационной комиссии. 2) системные испытания - это проверка (тестирование) работоспособности ПС в целом. Может включать те же виды тестирования, что и при комплексной отладке ПС. Проводится по решению аттестационной комиссии, если возникают сомнения в качестве проведения отладки разработчиками ПС. 3) приемо-сдаточные испытания являются основным видом испытаний при аттестации ПС. Именно с этих испытаний начинает работу аттестационная комиссия. Эти испытания начинаются с изучения представленной документации, в том числе, и документации по тестированию и отладке ПС. Если в документации отсутствуют достаточно полные результаты тестирования ПС, аттестационная комиссия может принять решение о проведении системных испытаний ПС или о прекращении процесса аттестации с рекомендацией разработчику провести дополнительное (более полное) тестирование ПС. Кроме того, во время этих испытаний могут выборочно пропускаться тесты разработчиков, а также контрольные задачи пользователей и дополнительные тесты, подготовленные комиссией для оценки качества аттестуемого ПС. 4) полевые испытания - это демонстрация ПС вместе с технической системой, которой управляет эта ПС, узкому кругу заказчиков в реальных условиях и осуществляется тщательное наблюдение за поведением ПС. Заказчикам должна быть предоставлена возможность задания собственных контрольных примеров, в частности, с выходов в критические режимы работы технической системы, а также с вызовом в ней аварийных ситуаций. Это дополнительные испытания, проводимые по решению аттестационной комиссии только для некоторых ПС, управляющих определенными техническими системами. 5) промышленные испытания - это процесс передачи ПС в постоянную эксплуатацию пользователям. Представляет собой период опытной эксплуатации ПС пользователями со сбором информации об особенностях поведения ПС и ее эксплуатационных характеристиках.

38 Нисходящий и восходящий подходы к проектированию ПС Нисходящим методом (сверху вниз) разработка программы ведется от общего к частному ко все большей детализации на каждом этапе, при этом сначала определяется задача в целом, а затем она декомпозируется на взаимосвязанную последовательность некоторых процессов или функций реализующих самостоятельные смысловые части алгоритма. При нисходящем методе используется КЕЙС средства как структурные так и объектно-ориентированные, при этом ключевым методом является декомпозиция, т.е берется большая задача, формируются модули, реализуют наиболее общие части этой системы. Процесс детализации алгоритма продолжается до тех пор, пока реализуемые части алгоритма не станут достаточно простыми и легко программируемыми. В результате этого формируются структура программы в виде дерева. Это дерево можно представить как направленный граф, определяющий взаимосвязь подпрограмм. На последнем этапе каждый модуль представляется в виде структуры алгоритма (схемы) которая собственно определяет процесс обработки данных. Альтернативным методом по отношению к нисходящему проектированию является метод восходящего проектирования(снизу вверх), при этом сначала разрабатываются модули низшего уровня, а затем они объединяются с помощью надстроек в виде модулей более высокого уровня, восходящее проектирование обычно используется при создании достаточно простых программ. На практике часто используют смешанный метод, при котором параллельно с определением структуры модулей верхнего уровня начинается проектирование и увязка отдельных компонентов нижнего уровня. Достоинством этого принципа является то, что при переходе к разработке модулей более высокого уровня иерархии модули нижних уровней можно считать готовыми и подключать их к модулям верхнего уровня на стадии отладки. Однако при таком подходе отсутствие целостного взгляда на КП с позиций верхнего уровня, определяющего цели построения комплекса, не позволяет в ряде случаев принимать верные решения, что приводит к повторной разработке или значительной корректировке модулей. Влияние повторной разработки сказывается тем тяжелее, чем выше уровень иерархии, на котором обнаружена ошибка. Разработка КП полностью по принципу снизу вверх возможна лишь для сравнительно небольших групп программ, ограниченных несколькими модулями, когда разработчики способны в любое время оценивать структуру и функции отдельных модулей на всех уровнях иерархии. Поэтому при разработке сложных КП, содержащих сотни модулей, наиболее рациональным принципом является проектирование сверху вниз.

39 Макетирование ПС Прототипирование – это процесс создания моделей требуемых программным продуктом. Данный метод применяется для того чтобы создать специальную модель имитирующую внешний вид и функционал будущей программы с тем чтобы снять неопределенность требований к заказчику. Тесть вместо реальной программы создается подобие, но большая часть функций не реализованы. Модели, используемые в качестве макета могут принять одну из 3 форм:

1. Бумажный макет – модель программы, отображенная на бумаге в виде схемы человеко-машинного диалога, набора шаблонов, экранных форм и.т.д;

2. Работающий макет – программа, которая выполняет небольшую часть своей функции, но по внешнему виду почти соответствует необходимой;

3. Продвинутый макет - Недоработанная программа характеристики, которой должны быть улучшены (бета версии);

Макетирование как метод основывается на многократном повторении итерации с участием заказчика и разработчика (или разработчика и массового пользователя) при этом в основном выполняется следующая последовательность действий:

1.Оценка ожидания заказчика (сбор и уточнение требований);

2. Построение или усовершенствование макета;

3. Оценка макета заказчиком (используется для уточнения требований);

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

Достоинства макетирования – обеспечивает определение полных требований к ПО. Недостатки макетирования: · заказчик может принять макет за продукт; · разработчик может принять макет за продукт.

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