Разработка программного продукта при моделировании экологических систем

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

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

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

В техническое задание включают:

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

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

Кроме явно описанных  в техническом задании требований, следует придерживаться общепринятых правил разработки программ с учётом выбранной парадигмы программирования:

• программа не должна содержать избыточные элементы (все элементы программы адекватны поставленной задаче: нет циклов, массивов и т. п. элементов, без которых можно обойтись).
• алгоритм должен быть структурирован: для функционального стиля программирования - адекватное разбиение на функции (процедуры), для объектно-ориентированного - адекватная иерархия классов. Каждая функция (метод класса) должна реализовывать ровно одно действие.
• у функций (методов классов) должны быть параметры. Следует избегать использования в функциях глобальных переменных.
• программа должна аккуратно использовать память: работать с динамическими массивами, в ней не должно быть неиспользуемых блоков памяти, лишних переменных.
• должны проверятся диапазоны вводимых пользователем значений и параметров, передаваемых между модулями программы.
• при использовании в программе каких-либо готовых компонент (библиотечных функций, классов) если функция или метод класса может завершиться неудачей, необходимо обязательно проверять это, не полагаясь на незначительность вероятности такого события.
• программа должна быть конфигурируема (важные параметры программы следует выделить в единый блок).

1.4 Методы тестирования

ВОСХОДЯЩЕЕ ТЕСТИРОВАНИЕ

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

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

НИСХОДЯЩЕЕ ТЕСТИРОВАНИЕ

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

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

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

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

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

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

1.5 Тестирование программы

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

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

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

• Функциональное тестирование
• Тестирование производительности
• Нагрузочное тестирование
• Стресс - тестирование
• Тестирование стабильности
• Тестирование удобства использования
• Тестирование интерфейса пользователя
• Тестирование безопасности
• Тестирование локализации
• Тестирование совместимости

По знанию системы:

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

По степени автоматизации:

• Ручное тестирование
• Автоматизированное тестирование
• Полу автоматизированное тестирование

По степени изолированности  компонентов:

• Компонентное (модульное) тестирование
• Интеграционное тестирование
• Системное тестирование

По времени проведения тестирования:

• Альфа - тестирование:
• Тестирование при приёмке
• Тестирование новой функциональности
• Регрессионное тестирование
• Тестирование при сдаче
• Бета - тестирование

По признаку позитивности сценариев:

• Позитивное тестирование
• Негативное тестирование

По степени подготовленности к тестированию:

• Тестирование по документации
• ad hoc тестирование или интуитивное тестирование

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

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

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

Статическое и динамическое тестирование

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