Объекты стандартизации в программотехнике

1) стандарты на программные продукты и их отдельные компоненты

2)регламентация процессов разработки программных продукций в соответствии с этапами программных циклов и управлением разработки проектов.

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

4) создание стандартизованных интерфейсов между приложениями программной системы, интерфейсов пользователя и интерфейсов между системами.

5) стандартизация структур и моделей данных, а также методов и средств описания данных, для обеспечения информационной совместимости между приложениями и совместимости систем при электронном обмене данных.

6) унификация документов и процессов документирования, включая регламентацию состава структуру и содержания, типовых форм, технологической и эксплуатационной документации, средства графического представления объектов, а также правила учёта, хранения, внесения изменений в документы.

7) стандартизация языков программирования и языков описания данных

8) стандартизация средств информационного обеспечения, включая методы кодирования, форматы обмена данных, лексику метода данных и др.

Программотехника базируется на 4-основных структурных принципах и включает в себя пять принципов программотехники. ^ Принцип сокрытия информации предполагает для каждого уровня декомпозиции представление только той информации о модуле, которая необходима для данного уровня детализации. Вся несущественная информация остается скрытой от разработчика. На основе принципа программный модуль рассматривается как «черный ящик», о котором известны входные и выходные данные и функция, выполняемая модулем. ^ Принцип локализации означает группирование логически связанных элементов; это относится к данным и этапом выполнения алгоритмов. Он реализуется через создание структур данных (массивы, записи) и программных структур типа отдельных подпрограмм или процедур. ^ Принцип концептуальной целостности требует следовать единому и непротиворечивому плану разработки проекта и принимать на каждом этапе разработки непротиворечивые решения: обеспечивая единый стиль в выполнении работ, унификацию архитектуры системы и четкий согласованный план работ; повышая понимаемость проекта и этапов его выполнения. ^ Принцип полноты (завершенности) определяет необходимость постоянного контроля для гарантии того, что ничто не пропущено и не включено лишнее на каждой фазе ЖЦПИ. ^ Принцип логической независимости предполагает, что при анализе и проектировании программного изделия логические функции полностью независимы от физической реализации, модели данных, представляющие логическую структуру данных, не зависят от их физической реализации, а общие словари данных – от конкретных приложений.

БИЛЕТ №18

Автоматизированные технологии разработки сложных программных средств.

Требования к технологии и средствам автоматизации разработки сложных программных средств

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

• к объекту разработки на данном этапе — к его программным и информационным компонентам, а также к интерфейсу между ними и внешней средой;

• к процессу, технологии и организации выполнения совокупности работ и документов каждого этапа;

• к методам и характеристикам средств автоматизации выполнения работ, обеспечивающим необходимую надежность функ­ционирования и качество ПС;

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

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

Требования к инструментальным средствам автоматизации разработки надежных ПС наиболее полно изложены в стандарте IEEE 1209-1992. Стандарт содержит рекомендации по оценке и выбору инструментальных средств, поддерживающих процессы жизненного цикла программных средств, включая процессы уп­равления проектами, процессы разработки и процессы, следую­щие за разработкой, а также интегральные процессы жизненно­го цикла ПС. Для оценки и выбора инструментальной среды и CASE-средств стандартом рекомендуется использовать приве­денные ниже наборы правил и критериев. Группы критериев в стандарте выделены и сформированы с учетом общих требова­ний стандарта ISO 9126:1991 по оценке качества программных продуктов.

БИЛЕТ №19

Тестирование программного средства, основные стратегии тестирования.

Тестирование ПО охватывает ряд видов деятельности аналогичной разработки

Сюда входит постановка задачи, проектирование, написание, тестирование теста.

Этап тестирования

Существует 2 крайних подхода

( тестирование по методу белого ящика и чёрного)

- тестирование по отношению к тексту

- тестирование по отношению к спецификации

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

Тестирование самой системы – по принципу чёрного ящика.

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

1. метод большого скачка – система собирается

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

Для метода пошагового тестирования широко применяются 2 стратегии ( восходящего и нисходящего) тестирования, которые близки по духу к нисходящему и восходящему программированию.

Восходящее тестирование

При восходящем подходе программа собирается и тестируется снизу вверх. Сначала тестируются модули самого нижнего уровня, которые не вызывают других модулей. Берётся уровень чуть выше… Следующий уровень охватывает обращение к предыдущим 2-м и т.д. процесс продолжается походу не будет вся система протестирована. При восходящем тестировании для каждого модуля необходимы некоторые драйверы, которые осуществляют вызов этого модуля, передача ему соответствующих параметров, анализ выходных результатов. Поэтому в настоящее время созданы и широко внедряются специальные тестирующие программы, которые имеют возможность подключения к ним произвольным модулей.

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

кодирование и тестирование программного продукта включает следующие задачи

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

2. Тестирование каждого компонента и базы данных на соответствие предъявляемых к ним требованиям. Результаты тестирования должны быть документированы. Осуществляется обновление при необходимости пользовательской документации и обновления при необходимости планов интеграции.

Интеграция предусматривает сборку разработанных компонентов в соответствии с планом интеграции и тестирование в их совокупности.

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

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

Квалификационное тестирование проводится разработчиком в присутствии заказчиков и ориентировано для демонстрации того, что пп удовлетворяет спецификациям.

Квалификационное тестирование выполняется по всем разделам требованиям при широком варьировании

При квалификационном тестировании обязательно проверяется полнота технической и пользовательской документации и её адекватность самим компонентам программного продукта.

Интеграция системы заключается в сборке всех её компонентов ( включая программное о и оборудование) после интеграции системы она вновь подвергается квалификационному тестированию

На этот раз проверяется спецификация самой системы. Производится полнота документации на всю систему.

БИЛЕТ №20

ГОСТ Р ИСО/МЭК 12119-2000. Тестирование программного средства.

ГОСТ Р ИСО/МЭК 12119-2000

Настоящий стандарт применяется для пакетов программ. Например, для текстовых процессо­ров, электронных таблиц, программ баз данных, графических пакетов, программ, реализующих технические и научные функции, и для сервисных программ (утилит).

Стандарт устанавливает:

• требования к пакетам программ (требования к их качеству);

• инструкции по испытанию пакета программ на соответствие его установленным требованиям (инструкции по тестированию, в частности по тестированию третьей стороной).