17.Программотехника. Структурный подход к проектированию программного обеспечения.

Программотехника (software engineering) - технология разработки, отладки, верификации и внедрения программного обеспечения.

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

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

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

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

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

2) стратегия «черного ящика» — проверить соответствует ли программа внешним спецификациям. При этом логика модуля совершенно не принимается во внимание Методы:

А) эквивалентного разбиения — разработка теста осуществляется в два этапа: 1). Выделение классов эквивалентности — выделяют правильные и неправильные классы, разбиение на которые подчиняются следующим правилам:

- если входное условие описывает область значений, например,то определяется один правильный класс эквивалентности и два неправильных; - если входное условие описывает число значений,то определяется один правильный класс эквивалентности и два неправильных;

- если входное условие описывает множество входных значений, то определяются правильные классы эквивалентности для каждого значения и один неправильный;

- если входное условие описывает ситуацию “должно быть”,то определяется один правильный класс эквивалентности и один неправильный; - если есть основания считать, что различные элементы класса эквивалентности воспринимаются программой неодинаково, то данный класс эквивалентности разбивается на меньшие классы эквивалентности.

2). построение теста: - назначение каждому классу эквивалентности уникального номера;- проектирование новых тестов, каждый из которых покрывает как можно большее число непокрытых правильных классов эквивалентности, пока все правильные классы эквивалентности не будут покрыты тестами;- запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалентности. Каждый неправильный класс эквивалентности должен быть покрыт индивидуальным тестом. Б) метод граничных условий Анализ граничных значений отличается от эквивалентного разбиения в двух отношениях:- выбор любого элемента в классе эквивалентности в качестве представительного при анализе граничных значений осуществляется таким образом, чтобы проверить тестом каждую границу этого класса.

- при разработке тестов рассматривают не только входные условия (пространство входов), но и пространство результатов, то есть выходные классы эквивалентности.