Внешнее проектирование программного изделия

Нижнее проектирование включает в себя 3 процесса:

1. Анализ и разработка требований.

2. Определение целей создания программного изделия.

3. Разработка внешних спецификаций проекта.

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

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

1. Выявить наличие информации, необходимой для выполнения планируемых функций.

2. Определить трудоемкость и стоимость предстоящей работы.

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

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

Анализ требований способствует лучшему пониманию решаемой проблемы и компромиссных ситуаций, что помогает выбрать оптимальное решение. Требования разрабатываются в 2 этапа:

1. На этом этап определяется реализуемость, устанавливаются цели, оцениваются затраты. В результате получается

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

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

2. …

3. ….

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

При описании цели возможно возникновение следующих ошибок:

• Противоречивость

• Наличие поверхностно выявленных целей, не отражающих специфических особенностей разрабатываемого ПО.

• Цели создания программного изделия с точки зрения пользователя и проектировщика могут быть противоречивы.

Цели проекта – это цели, которые должны быть достигнуты в процессе проектирования.

Цели проекта должны содержать следующую информацию:

• Стоимостные ограничения;

• Календарный план выполнения работ;

• задача каждого этапа тестирования;

• цели в области адаптируемости;

• уровень надежности на каждом этапе разработки.

• Критерии завершения разработки и начала адаптации.

Цели проекта должны быть ясными, обоснованными и измеримыми. Цель должны быть подробна, но не должна предполагать конкретных методов решения.

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

Разработка внешних спецификаций разбивается на 2 части: предварительный внешний проект и детальный.

Белый ящик – разработчик имеет доступ к исходному коду и может писать код, которые связан с библиотеками тестируемого ПО. Стратегия тестирования по принципу белого ящика, так же называемая стратегиями тестирования управляемая логикой программы позволяет проверить внутреннюю структуру программы. Стратегия БЯ включает в себя следующие методы тестирование:

1. Покрытие операторов.

2. Покрытие решений.

3. Покрытие условий.

4. Покрытие решений и условий.

5. Комбин арное покрытие условий.

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

Покрытие решений

Покрытие решений условий все возможные результаты каждого условия выполнялись по крайней мере один раз и каждой точке управления передается, по крайней мере, один раз. Недостатки данного метода:

• Не всегда можно проверить все условия;

• Невозможно проверить условия, которые скрыты другими условиями;

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

Покрытие тестов можно осуществить 8-ю способами:

1. A>1, B=0

2. A>1, B :=0

3. A <=1, B=0

4. A <=1, B :=0

5. A=2, X>1

6. A=2, X <=1

7. A:=2, X>1

8. A:=2, X<=1

При проведении интеграционного тестирования важным является порядок сбора модулей в единую программу.

Преимущества БЯ:

1. Проверить код, возможно в каждой отрасли.

2. Данный принцип показывает скрытые ошибки в коде.

3. Более тщательное тестирование кода.

Но так же есть недостатки:

1. Метод не обнаруживает пропущенные маршруты.

2. Не обнаруживает ошибок, появление которых зависит от обрабатываемых данных.

3. Не дает гарантии, что программа соответствует описанию.

4. Сложность отслеживать вычисление времени исполнения.

Черный ящик – объект исследования, внутренне устройство которого не известно. Характеризуется функцией перехода и функцией выхода.

К первому виду относят к любой черный ящик, который может рассматриваться как автомат и называться «конечным» или «бесконечным». Ко второму виду относятся такие ЧЯ, поведение которых может быть наблюдаемых только в эксперименте.

Практическая ценность метода ЧЯ заключается в:

1. Возможность исследования

2. Возможность замены одного ящика на другой.

Тестирование по стратегии. Разумное тестирование – тестирование программы ограничивается небольшим подмножеством всевозможных наборов данных.

Свойство правильно выбранного теста:

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

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

Методы стратегии черного ящика:

1. Эквивалентное разбиение.

2. Анализ граничных значений.

3. Анализ причинно следственных связей

4. Предположение об ошибках.

Эквивалентное разбиение – методика тестирования ЧЯ, когда набор вводимых значений разделяем на классы данных, из которых можно получить тест Кейса.

1. Исходные данные необходимо разбить на тесты эквивалентности.

2. Каждый тест должен включать по возможности максимальное число классов эквивалентности, чтобы минимизировать число тестов.

Анализ причинно следственных связей.

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

Предположении об ошибке. Такая методика полностью основано на опыте тестировщика.

Которые перечисляют возможности.

Достоинства и недостатки тестирования ЧЯ. Тестировщик может не обладать глубокими знаниями. Затруднительно определить все данные за время тестирования именно поэтому написание тестов превращается в долгий процесс. Во время такого тестирования могут быть пропущены некоторые пути тестирования.

Разработка спецификаций разбивается на 2 этапа:

1. Предварительный внешний проект.

2. Детальный внешний проект.

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

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

Характеристики надежности. Описывается влияние всех возможных отказов функции на систему.

Эффективность. Описываются ограничения по ресурсам, которые накладываются на эффективность функции.

Замечания по программированию. Указание некоторых идей относительно внутренних…

При завершении этапа внешнего проектирования. Заканчивается рассмотрение взаимодействия пользователя и программного обеспечения. Любое изменения порождают новые ошибки.

Чтобы изменения в проекте не приводили к новым ошибкам следует соблюдать следующие правила:

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

2. Фиксировать результаты каждого процесса наблюдения.

3. Требования и цели фиксируются после их утверждения.

4. Внешняя спецификация после успешного завершения проверки их правильности.

5. Изменения должны проходить формальную процедуру утверждения.

6. Проверять каждое внесенное изменение до такой степени, до которой проверялось исходное решение.

7. Необходим контроль, чтобы все изменения…