25.10. 2011 Ускорение разработки по, Методология rad.

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

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

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

Руководство пользователя должны содержать следующие разделы:

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

• Описание установки. Обычно содержит описание действий по установке ПП.

• Описание запуска. Описаны действия по запуску ПП и сообщения, которые будут получены.

• Инструкции по работе. Содержит описание режимов работы, формат ввода/вывода информации и возможность настроек.

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

Рекомендации по написанию руководства пользователю:

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

2. Излагайте мысли ясно, короткими предложениями.

3. Избегайте технического жаргона или узкоспециализированной терминологии.

4. Будьте точны и рациональны. Используйте схемы, диаграммы, таблицы и т.д.

Руководство системного программиста должно содержать следующие разделы:

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

• Структура. Должны быть приведены сведения о структуре программы, ее составных частях, о связях между этими частями и другими программами.

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

• Проверка программы. Описание способов работоспособности программы (тестовые или контрольные примеры).

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

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

Тестирование и отладка программы

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

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

• Модульное тестирование – тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция.

• Интеграционное тестирование – проверяется, есть ли какие либо проблемы в интерфейсе и взаимодействие между ними, а также интегрируемыми компонентами. Например, не передается информация или информация передается не корректно.

• Системное тестирование - тестируется интегрированная система, на ее соответствие исходным требованиям:

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

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

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

Виды ошибок и способы их обнаружения

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

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

Тестирование – это технико-экономическая проблема, основанная на компромиссе время полнота.

Желательные свойства хороших тестов:

• Детективность – тест должен, с большой вероятностью обнаруживать возможные ошибки

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

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

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

Используется два вида тестов:

1. Функциональные тексты – составляются исходя из спецификаций

2. Структурные тесты – составляются исходя из текста программы.

Виды критериев тестов и их функциональность

1. Функциональные

   1. Тестирование классов входных данных. Содержат представителей всех классов входных или выходных классов и точки на границах классов

   2. Тестирование функций. Каждая функция внешнего интерфейса должна быть проверена >= 1 раза

2. Структурные

   1. Тестирование команд. Каждая команда (оператор) должна быть выполнена более 1 раза. >= 1

   2. Критерий С1 – тестирование ветвей. Каждая ветвь должна быть выполнена больше одного раза Критерий С2 – тестирование путей. Каждый путь в графе программы должен быть выполнен более 1 раза.

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

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

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

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

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

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

Порядок разработки тестов

По внешней спецификации разрабатываются тесты:

1. Для каждого класса входных данных

2. Для граничных и особых значений входных данных

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

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

Аксиома тестирования:

1. Тест должен быть направлен на обнаружение ошибки, а не на подтверждение правильности программы.

2. Автор теста – не автор программы.

3. Тесты разрабатываются одновременно с программой либо до разработки, но не после.

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

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

6. Следует повторять полное тестирование, после внесения изменений в программу или переноса ее в новую среду.

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

Автоматизация тестирования

• Автоматизация прогона тестов – пишутся командные файлы, для запуска программы с каждым набором тестов и сравнение реального результата с ожидаемым.

• Средства автоматизации к подготовке тестов и анализа их результатов.

  • Генераторы случайных тестов в заданных областях входных данных

  • Отладчики для локализации ошибок

  • Анализаторы динамики, обычно входят в состав отладчиков

  • Средства автоматической генерации структурных тестов.

Модульное тестирование

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

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

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

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

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

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

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

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

2. На основе анализа потока данных. Когда элементы, которые должны быть покрыты, определяются на основе потока данных, т. Е. на основе информационного графа программы. Данный вид тестирования направлен на выявление ссылок, на неинициализированные переменные, а также указываются многомерные присвоения. Недостаток метода в том, что он не включает критерий С1, и не гарантирует покрытие решений.

Процесс построения набора тестов при структурном тестировании принято делить на три фазы:

1. Конструирование управляющего графа программы (УГП)

2. Выбор тестовых путей

3. Генерация тестов, соответствующих тестовым путям.

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

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

Вторая фаза обеспечивает выбор тестовых путей.

Выделяют три подхода к построение тестовых путей:

3. Статические методы.

4. Динамические методы.

5. Методы реализуемых путей.

Статические методы – самое простое и легко реализуемое решение. Построение каждого пути, посредством постепенного его удлинения, за счет добавления дуг, пока не будет достигнута выходная вершина УГП.

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

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

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

Основной идеей динамических тестов является подсоединение к начальным результируемым отрезкам пути дальнейших их частей так, чтобы:

1. Не терять результируемость

2. Покрыть требуемые элементы программы.

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

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

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

Метод реализуемых путей дает самый лучший результат.

Интеграционное тестирование

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

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

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

Два метода сборки модулей:

1. Монолитный, который характеризуется объединением всех модулей, в тестируемый комплекс;

2. Инкрементальный. Характеризуется пошаговым (помодульным) наращиванием комплекса программы, с пошаговым требованием собираемого комплекса. У данного метода есть две стратегии:

   1. «сверху вниз» и соответствующее ему восходящее тестирование

   2. «снизу вверх» и соответствующее ему нисходящие тестирование.

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

Сравнение монолитного и интеграционного подхода.

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

Сложность идентификации ошибок (одно дело на 5 строк, другое дело на 5000).

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

Монолитное тестирование представляет больше возможности распараллеливания робот, особенно на начальной стадии тестирования.

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

Недостатки нисходящего тестирования:

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

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

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

Особенности восходящего тестирования:

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

Системное тестирование

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

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

Категории тестов системного тестирования:

1. Полнота решения функциональных задач;

2. Стрессовое тестирование – тестирование на предельных объемах нагрузки входного потока;

3. Корректность использования ресурсов;

4. Оценка производительности;

5. Эффективность защиты от искажения данных и некорректных действий;

6. Проверка инсталяции и конфигурации на разных платформах;

7. Проверка корректности документации.

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

Эффективность и оптимизация программ

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

Средства оптимизации, используемые компилятором, делятся на две группы:

1. Машинно-зависимые, то есть ориентированные на конкретный машинный язык, выполняют оптимизацию кода, на уровне машинных команд.

2. Машинно-независимые, выполняют оптимизацию на уровне входного языка.

Способы экономии памяти

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

Способы уменьшения время выполнения

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

1. Выносить вычисления константы

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

3. Минимизировать преобразования типов в выражениях

4. Оптимизировать запись условных выражений (исключать лишние проверки)

5. Исключать многократные обращения к элементам массива по индексам

6. Избегать использования различных типов в выражениях.

Стиль программирования

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

Цели хорошего форматирования кода:

1. Точно представлять логическую структуру кода (отступы, пропуски и т.д.)

2. Единообразно показывать логическую структуру кода

3. Улучшить читабельность

4. Поддерживать процедуру исправления

В дополнение к этим критериям применяется задача уменьшения кол-ва строк кода.

Способы форматирования

1. Группировка взаимосвязанных выражений (смысловые блоки группируются в абзацы)

2. Пустые строки (взаимосвязанные операторы важно отделять от несвязанных выражений; 8-16% - оптимально)

3. Отступы (оптимальное кол-во 2-4%).

4. Скобки

Надежность ПО

Это комплексное свойство, которое включает две составляющие:

1. Безошибочность – соответствие спецификации

2. Устойчивость - способность продолжать правильно работать после отказа.

Отказ – нарушение работоспособности изделья или его соответствия требованиям ТЗ.

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

Классификация причин отказа

Физические

1. Внутренние (старение, износ)

2. Внешнее воздействие (радиация и т.д.)

Повреждения – неисправность, которая уже появилась , но еще не проявилась во вне.

Отказ компонента – повреждение системы.

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

Восстановление – возврат в рабочее состояние, одним из следующих путей:

1. Ручной ремонт, замена, исправление

2. Автоматически с задействованием резервов

3. Самопроизвольно (обычно быстро)

В третьем случае, отказ называется сбоем.

Сбой – это кратковременный самовосстанавливающийся отказ, остальные отказы, называются, устойчивыми.

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

Типичный пример восстановления – с помощью резервной копии данных. Если, выполнить восстановление в латентном периоде отказа, то он никогда не проявится во вне – идеальный принцип отказоустойчивости.

Количественные характеристики надежности программ

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

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

1. Среднее время безотказной работы (MTBF)

2. Коэффициент готовности

3. Интенсивность отказов (среднее кол-во отказов в единицу времени).

Предположений простейшего потока отказов P(t), отказы независимы, редки и их вероятность неизменна во времени. P(t) – вероятность безотказной работы, за время t (будет подчиняться закону Пуассона). Где лямбда – интенсивность отказов. Его первый момент M(P) – мат. ожидание, как раз и будет 1/лямбда.

Многие программные продукты имеют следующий характер изменения надежности:

1. Период приработки

2. Период полезной жизни

3. Период старения

Если отказ все таки произошел, время восстановления должно быть минимальным, данное время характеризуется показателем ремонтопригодности, коэффициента готовности k = (T-Tпp)\T, где Т – общее время работы, Тпр – время простоя системы из-за восстановления.

В ответственных системах требуется, чтобы значение k почти не отличалось от единицы. Для цифровых АТС это время два часа простоя суммарно за 15 лет. Для систем управления воздушным движением – 3 секунды за год.

Методы оценки изменения характеристик надежности

Внутренняя характеристика – число оставшихся ошибок (абсолютно или относительно). Считается, что в одной программе должно быть не более одной ошибки на 1000 строк кода. Для ответственных применения одна ошибка на 10000 строк кода.

Методы соответствия ПП:

1. Метод Милса (INM 1972г.) (метод меченых рыб). Группа тестирования засоряют программу искусственными ошибками и продолжает тестировать, анализируя долю внесенных ошибок среди обнаруженных.

2. Пусть внесено С ошибок, обнаружено Н собственных и М внесенных ошибок. Предполагаться, что вероятность обнаружения внесенных и собственных ошибок одинакова. Получим первоначальное кол-во оставшихся ошибок Н = С/М. Проверка гипотезы, осталось меньше собственных ошибок, тогда вносится еще С ошибок и тестирование продолжается, пока они не будут обнаружены. Пусть к этому моменту найдено Н собственных ошибок, тогда уровень значимости гипотезы (вероятность того, что на истина) равна единице, при Н>k.

3. Метод Руднера (1977г.). Тестирование осуществляется двумя независимыми группами тестов параллельно, в которых обнаруживают М1 и М2 ошибок соответственно, из которых М12 – общее кол-во ошибок. Используя гипергеометрическое распределение методом максимального правдоподобия, может быть найдена оценка содержащихся ошибок в системе.

4. Среднее число ошибок на 1000 строк исходного кода. Разработали метод оценки время тестирования без отказов, подтверждающую заданную надежность. Метод основан на известной зависимости Т = f(N,n,t), где Т – время окончательного тестирования без отказов, N – допустимое число ошибок в коде, n –общее число ошибок обнаруженных в ходе тестирования, t – время потраченное на выявление n ошибок и тестирование можно закончить. Если же отказ произошел во время испытания, оно продолжается, а функция t пересчитывается заново, для n+1 и t+tr. Функция T получено на базе одной из моделей надежности программ на основе оценок функций лямбда(t) которые экстраполируют динамику отладки (данные берем из журнала отладки).

Рассмотрим модель Джелинского-Моранды.

1. Интенсивность обнаружения ошибок f(t) пропорционально текущему числу ошибок в программе, то есть числу исходных ошибок минус обнаруженные.

2. Все ошибки равновероятны и их проявление не зависит друг от друга.

3. Ошибки постоянно исправляются перед внесением новых ошибок.

4. R(t) постоянно в промежутке между двумя смежными моментами обнаружения. Тогда R(t) ступенчато монотонно убывающая функция.

Преимущества парного программирования

1. Парное программирования экономически оправдано.

2. Быстрая обучаемость. При парном программировании сотрудники перенимают опыт работы друг-друга.

3. Работая вместе люди чувствуют себя увереннее так как партнер контролирует действия другого партнера, при этом увеличивается качество его работы.

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

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

Отладка программ

Локализация и исправление ошибок называется отладкой. Отладка – это процесс обнаружения причин возникновения ошибки и ее последующее исправление. Тестирование – процесс непосредственно обнаружение факта ошибки.

Отладка включает в себя элементы тестирования и разработки. В некоторых проектах отладка занимает до 50% времени разработки.

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

Методы отладки:

1. Ошибки синтаксиса языка. Как правило, определяются на стадии компиляции или первой интерпретации программы.

2. Ошибки во время выполнения – ошибки логики программы и алгоритмов программы (самой распространенной ошибкой является ошибка обращения к памяти).

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

4. Невоспроизводимые ошибки.

5. Ошибки инструментария и других компонентов системы.

Схема или путь выявления ошибок

1. Локализация ошибки, необходимо уменьшить кол-во данных на входе, чтобы можно было проанализировать выходные данные.

2. Отключение ненужных модулей программы.

3. Использование отладчиков. Возможности современных отладчиков:

1. Точки остановки на конкретных строках кода

2. Остановка на n-ой операции цикла

3. Остановка при изменении переменных

4. Остановка при присваивании конкретного значения

5. Прохождение кода построчно

6. Откат по программе

7. Исследование всех данных в программе, включая типы определенные пользователем

8. Присваивание новых значений переменным

9. Многоязыковая отладка

10. Запоминание установок

Сопровождение и мониторинг программных средств (ПС)

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

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

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

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

4. Комплексы программ, прошедшие широкие испытания гарантируют качество результатов функционирования у заказчика, а следовательно любые изменения имеют высокий риск внесения дополнительных ошибок и изменения качества данного ПС.

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

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

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