Курсовая работа (т): Разработка приложения, реализующего метод Флойда

·    инструментальную поддержку процесса разработки, минимизацию времени и трудозатрат;

·        использование прототипа для уточнения требований заказчика;

·        цикличность разработки - каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком;

·        постепенное расширение функциональности;

·        распределение ролей в команде разработчика, возможность их совмещения;

·        управление проектом создания программного продукта.

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

Инкрементная модель объединяет элементы последовательной водопадной модели с итерационной основой макетирования.

Рисунок 2. Схема выполнения проектных работ по модели RAD

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

Эволюционная стратегия получила свое воплощение в ряде моделей: спиральной, компонентно-ориентированной. Автором спиральной модели является американский ученый Б. Боэм (1988).

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

) планирование - определение целей, вариантов, ограничений;

) анализ риска - анализ вариантов и распознавание (выбор) риска;

) конструирование - разработка продукта следующего уровня;

) оценивание - оценка заказчиком текущих результатов разработки.

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

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

2.      Разработка архитектуры системы, определяющей концепцию построения программного продукта, открытой для изменений.

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

Рисунок 3. Схема выполнения проектных работ по спиральной модели: 1 - планирование проекта и жизненного цикла; 2 - концепция эксплуатации; 3 - спецификация требований; 4 - проверка требований; 5 - детальный дизайн; 6 - кодирование; 7 - модульное тестирование; 8 - интеграция и тестирование; 9 - приемочное тестирование; 10 - развертывание.

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

1.4 Тестирование программных средств

История развития тестирования программного обеспечения.

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

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

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

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

В 2000-х появилось еще более широкое определение тестирования, когда в него было добавлено понятие "оптимизация бизнес-технологий" (en:business technology optimization, BTO). BTO направляет развитие информационных технологий в соответствии с целями бизнеса. Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки ПО для достижения необходимого уровня качества, производительности, доступности.

Тестирование программного обеспечения - процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта. алгоритм интерфейс delphi

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

·    по объекту тестирования;

·        по знанию системы;

·        по знанию системы;

·        по степени автоматизированности;

·        по степени изолированности компонентов;

·        по времени проведения тестирования;

·        по признаку позитивности сценариев;

·        по степени подготовленности к тестированию.

Уровни тестирования.

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

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

Системное тестирование - тестируется интегрированная система на её соответствие требованиям.

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

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

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

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

Тестирование "белого ящика" и "чёрного ящика".

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

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

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

Тестирование программного обеспечения.

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

По объекту тестирования:

1.   Функциональное тестирование (functional testing)- это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.

функциональные требования включают в себя:

·    функциональная пригодность (англ. suitability);

·        точность (англ. accuracy);

·        способность к взаимодействию (англ. interoperability);

·        соответствие стандартам и правилам (англ. compliance);

·        защищённость (англ. security).

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

Тестирование производительности - это одна из сфер деятельности развивающейся в области информатики инженерии производительности, которая стремится учитывать производительность на стадии моделирования и проектирования системы, перед началом основной стадии кодирования.

Направления тестирования производительности.

В тестировании производительности различают следующие направления:

·    нагрузочное (load);

·        стресс (stress);

·        тестирование стабильности (endurance or soak or stability);

·        конфигурационное (configuration);

Возможны два подхода к тестированию производительности программного обеспечения:

·    в терминах рабочей нагрузки: программное обеспечение подвергается тестированию в ситуациях, соответствующих различным сценариям использования;

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

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

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