27. Пошаговое тест-ие моДных прог-. Достоинства и недостатки подходов.*
30. Нисходящая стратегия разработки прог-.*
27. Пошаговое тест-ие моДных прог-. Достоинства и недостатки подходов.*
Методика восходящего тест-ия включает следующие щаги: Сначала тестируются ‘листья’ дерева стр-ы прог-ы, т.е. модули Е,C,F. Поскольку вызываемые прог-ы, то для их тест-ия прог-ируются драйверы. В его ф-и входит формирование тестовых д-х для отлаживаемого МОД и передача ему управ (вызов МОД). Затем аналогично тестируются модули вышележащего уровня совместно с уже оттестированными МОДми нижележащего уровня. Применительно к рассматриваемому нами примеру проектируются драйверы для тест-ия пар B-E и D-F. Пошаговый процесс продолжается до тех пор, пока не будет включен в процесс тест-ия последний МОД. Для нашего примера будет МОД А. Для его тест-ия совместно с вызываемыми прог-ами нижележащего уровня драйвер разрабатывать не требуется. Сначала компоненты нижнего уровня, затем предыдущего и этот.д
Альтернативное нисходящее тест-ие состоит из следующих действий: Тест-ие начинается с вызывающего МОД прог-ы. Для МОД нижележащего уровня (вызываемых) прог-ируются так называемые ‘заглушки’. После проверки ‘корня’ дерева стр-ы комплексной прог-ы переходят к тестированию нижележащих МОД. Причем, формализованной процедуры подключения к вызывающему модулю нижележащих вызываемых МОД не сущ-этот. Единственное ограничение, которым руководствуются при выборе очередного претендента на тест-ие, заключается в том, что этот МОД должен вызываться уже оттестированным модулем вышележащего уровня. If очередной тест-ый МОД вызывает модули еще нижележащего уровня, то аналогично пункту а) для нижележащих МОД прог-ируются ‘заглушки’ Процесс тест-ия продолжается до тех пор, пока не будет оттестирован последний МОД из ‘листьев’ дерева стр-ы прог-ы.
Сравнительный анализ приведенных методик тест-ия , показывает, что нисходящее тест-ие ставит перед прог-истом много проблем, касающихся разработки ‘заглушек’ и интерпретации результатов тест-ия. Меньшими недостатками обладает восходящее тест-ие.
30. Нисходящая стратегия разработки прог-.*
Нисходящий подход предполагает, что проектир-е и последующая реализация компонентов выполняется «сверху-вниз», этот. е. вначале проектируют компоненты верхних уровней иерархии, затем следующих и так далее до самых нижних уровней. В той же послед-ости выполняют и реализацию компонентов. При этом в процессе прог-ирования компоненты нижних, еще не реализованных уровней заменяют специально разработанными отладочными МОДми - «заглушками», что позволяет тестировать и отлаживать уже реализованную часть.
При использовании нисходящего подхода применяют иерархический, операционный и комбинированный методы определения послед-ости проектирования и реализации компонентов.
Иерархический метод предполагает выполнение разработки строго по уровням. Исключения допускаются при наличии зависимости по д-ым, этот. е. if обнаруживается, что нек-й МОД исп-ет результаты другого, то его рекомендуется прог-ировать после го МОД. Основная проблема - большое количество достаточно сложных заглушек. Кроме того, при использовании д-ого метода основная масса МОД разрабатывается и реализуется в конце работы над проектом, что затрудняет распределение человеческих ресурсов.
Операционный метод Послед-ые разработки МОД совпадает с порядком их выполнения при запуске прог-. модули вывода результатов должны разрабатываться одними из первых, чтобы не проектировать сложную заглушку, обеспечивающую вывод результатов при тестировании. С точки зрения распределения человеческих ресурсов сложным явл-я начало работ, пока не закончены все модули, находящиеся на так называемом критическом пути.
Комбинированный метод учитывает следующие факторы, влияющие на послед-ость разработки:
•достижимость МОД - наличие всех МОД в цепочке вызова д-ого МОД;
•зависимость по д-ым - модули, формирующие нек-е д-ые, должны создаваться раньше обрабатывающих;
•обеспечение возможности выдачи результатов - модули вывода результатов должны создаваться раньше обрабатывающих;
•готовность вспомогательных МОД - вспомогательные модули, например, модули закрытия файлов, завершения прог-ы, должны создаваться раньше обрабатывающих;
•наличие необходимых ресурсов.
Нисходящий подход обеспечивает:
•максимально полное определение спецификаций проектируемого компонента и согласованность компонентов м/у собой;
•раннее определение интерфейса пользователя, демонстрация к-го заказчику позволяет уточнить требования к создаваемому прог-ному обеспечению:
• возможность нисходящего тест-ия и комплексной отладки
5.Дайте определение модели жизн-ого цикла ПП. Приведите какую-либо модель ЖЦ и дайте необходимые пояснения.*
19. Этапы жизн-ого цикла (ЖЦ) прог-ных продуктов (ПП). Схема ЖЦ ПП.*
36. Спиральная модель жизн-ого цикла прог-ных продуктов.*
37. Дайте определение модели жизн-ого цикла ПП. Приведите каскадную и спиральную модели ЖЦ и дайте краткие пояснения.
5.Дайте определение модели жизн-ого цикла ПП. Приведите какую-либо модель ЖЦ и дайте необходимые пояснения.*
ЖЦ ПП- период t, нач с момента принятия реш о необх созд-я ПП и заканч в момент его полного изъятия из эксплуатации.
Под моделью ЖЦ разработки ПП понимается структура, опред-я последоват выполн и взаимосвязи процессов, действий, задач, выполняемых на протяжении ЖЦ разработки ПП
Каскадная модель - переход на след этап происходит после оконч предыдущего. На каждом этапе формируется законч набор проект документации, отвеч критериям полноты и согласованности. На заключ. Этапах также разрабатывается пользоват документация, охват-ая все предусмотренные стандартами виды обеспечения информационной системы: организационное, методическое, информационное, программное, аппаратное; Выполняемые в логичной последоват-и этапы работ позволяют планировать сроки завершения и соответ-ие затраты. Недостатки: 1) на практике часто принятые на предыдущем этапе(-ах) реш приходится пересматр из-за неверной интерпретации требований заказчика 2) задержка получения результатов 3)сложность управ проектом4)высокий уровень риска и ненадежности инвестиций.
Другая модель ЖЦ ПП строится по принципу с промежуточным контролем. Эта модель явл-я более жизнеспособной по сравнению с каскадной моделью, но наличие циклов обратных связей растягивает все этапы ЖЦ ПП на весь период разработки, что затрудняет планирование работ по созд-ю и внедрению ПП
При исп спиральной модели прикладное ПО созся в несколько итераций (витков спирали) методом прототипирования(действующий програмый компонент, реализ отдельные ф-и и внеш интерфейсы разрабат-го ПО. Это позволет уточнить требования, цели и характ-ки проекта, определить кач-о разработки, спланировать работы след-го витка спирали. Избавляет пользовател и разработч ПО от необходимости полного и точного формул-я требований к сист на нач стадии, поскольку они уточняются на каждой итерации. На каждой итер производ тщательная оценка риска превышения сроков и стоимости проекта, чтобы определ необход вып еще одной итер, степень полноты и точности понимания требований к сист, а также целесообразность прекращения проекта. Тем самым реализуется нисходящий принцип проектирования
Достоинством спиральной схемы –
начиная с нек-й итерации, продукт можно предоставлять пользователю.
сократить время до появления первых версий прог-ного продукта;
заинтересовать большое количество пользователей,;
ускорить формирование и уточнение спецификаций за счет появления практики использования продукта;
уменьшить вероятность морального устаревания сист за время разработки
19. Этапы жизн-ого цикла (ЖЦ) прог-ных продуктов (ПП). Схема ЖЦ ПП.*
Анализ( по средствам к-го осущ-я опис-е требований ПП)
Проектир-е (включ. Разработку иерархич. Стр-ы разработки ПО)
Прог-ирование
Тест-ие и отладка( в процессе к-х выявлен в соответствии ПП и его спецификации
Эксплуатация и сопровождение
Базовая схема ЖЦ ПП
21. Этапы тест-ия прог-. Стадии тест-ия в процессе разработки прог-ного обеспечения. Методы, исп-емые на каждой стадии.*
22. Ручной контроль как метод тест-ия.* *
21. Этапы тест-ия прог-. Стадии тест-ия в процессе разработки прог-ного обеспечения. Методы, исп-емые на каждой стадии.*
Тест-ие - процесс выполнения прог-ы, целью к-го явл-я выявление ошибок.
В тест-ие входят следующие этапы: а) постановка задачи для теста, б) проектир-е теста, в) написание тестов, г) тест-ие тестов, д) выполнение тестов, е) изучение результатов тест-ия.
Стадии:
1) автономное тест-ие компонентов прог-ного обеспечения (методы ручного контроля, покрытия операторов, покрытия реш, покрытия усл-й, комбинаторного покрытия).
2) комплексное тест-ие разрабатываемых прог- (восходящее и нисходящее тест-ие).
3) системное или оценочное тест-ие на соответствие основным критериям качества.
Для повышения качества тест-ия рекомендуется соблюдать следующие основные принципы:
предполагаемые результаты должны быть известны до тест-ия;
следует избегать тест-ия прог-ы автором;
необходимо досконально изучать результаты каждого теста;
необходимо проверять действия прог-ы на неверных д-х;
необходимо проверять прог-у на неожид-ые побочные эффекты на неверных д-х.