Файл: Проектирование программ, этапы создания программного обеспечения.pdf

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

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

Существуют 2 основные процесса разработки обеспечения:

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

Такая модель следующие этапы создания ПО:

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

Далее программный можно внедрять и внедрения осуществлять вносить новый ликвидировать ошибки. Так, все разработки программного при использовании модели выполняются последовательно. Не происходит предыдущей фазе или следующую, а также фаз. Основные достоинства разработки: – четкая документация процесса; – точное определение бюджета; – определение сроков проекта; – низкая степень человеческого фактора Минусы: – длительные сроки от старта предоставления первого – большой объем документов; – длительные согласования промежуточных документов; – невозможность внесения динамическом режиме.

---

2.Гибкая разработки программного (Agile software Ряд методологий программного обеспечения, совместную работу заказчика и разработчиков. В гибкого метода лежит итеративный динамическое формирование реализация короткими Результатом каждого этапа, включающего итераций, является малый программный проект,

Способов гибкой несколько, из наиболее Scrum, экстремальное DSDM.

Основные достоинства разработки: – минимизация рисков; – постепенное наращивание программного продукта; – небольшой объем документации; – запуск базовой программы в кратчайшие Недостатки: – невозможность точного бюджета проекта; – невозможность определения сроков готовности – не подходит для бюджетных организаций; – требует мотивации от представителей заказчика.

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

Глава 2. Стратегии тестирования программного обеспечения

2.1 Исследование стратегий тестирования программного обеспечения

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

---

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

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

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

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

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

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

---

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

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

Рис. 1. Тестирование методом черного ящика

Методы функционального тестирования: 1) Эквивалентное разбиение — метод, когда по спецификации выделяются классы эквивалентности (множество тестов со сходными параметрами, протестировав один из них, можно считать, что протестированы и все остальные) входных данных и создаются тесты, моделирующие попадание данных в эти классы. 2) Анализ граничных условий — метод, при котором проверяются границы классов эквивалентности. Строятся тесты для границ классов, для минимальных и максимальных значений. 3) Метод функциональных диаграмм — метод, в котором функциональная диаграмма формально является текстом, в который транслируется спецификация.

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

---

Выделяют следующие особенности методов функционального тестирования:

‒ Тестирование системы в целом, включая отдельные модули и интерфейсы между ними.

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

‒ Тесты основаны на спецификации и не зависят от исходного кода.

‒ Удобство автоматизации и регрессионного тестирования на базе тестов, построенных на основе стратегии «черного ящика».

‒ Некоторые возникающие ситуации не будут проверены вследствие того, что тесты покрывают основную функциональность.

Метод тестирования «черного ящика» до сих пор является самым распространенным в повседневной практике, но у него есть некоторый ряд недостатков, например, невозможно найти взаимоуничтожающиеся ошибки и некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и поэтому их трудно найти и воспроизвести.

Стратегия структурного (модульного) тестирования (Рис. 2) предполагает создание тестов на основе структуры системы и ее реализации. Такой подход иногда называют тестированием методом «белого ящика», чтобы отличать его от тестирования методом «черного ящика». Структурное тестирование так же называют тестированием путем покрытия логики.

Рис. 2. Структурное тестирование

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

Основными методами структурного тестирования являются покрытие операторов программы, ветвей программы, условий. Критерии структурного тестирования: С0 — условие тестирования команд, заключается в выполнении каждого оператора хотя бы один раз. С1 — условие тестирование ветвей, требуется выполнение каждой ветви программы не менее 1 раза. C2 — критерий покрытия всех путей в управляющем графе программы. Кроме перечисленных выше критериев используют критерий покрытиях всех условий и критерия покрытия условий/решений, который совмещает C1 и критерий покрытия условий.

---