Этапы создания базы данных

Значение сопровождения в жизненном цикле больших программ стало осознаваться специалистами лишь в последние годы, когда выяснилось, что затраты на их сопровождение могут составлять до 60% затрат на программное обеспечение, или 50% общих затрат на вычислительную технику. Жизненный цикл программного обеспечения длится около 5—7 лет, в течение которых требования к нему могут существенно меняться. Различие между большими и малыми программами проявляется не только и не столько в их разработке, сколько в сопровождении.

Большую программу по понятным причинам нельзя переделать заново, но при изменении и дополнении больших программ на стадии сопровождения приходится в какой-то степени повторять все предыдущие стадии разработки, что приводит к большим затратам и множеству ошибок. Типичным является следующее распределение ресурсов для больших систем: 100 чел. в течение 2 лет заняты разработкой программного обеспечения и 35 чел. в течение 8 лет — сопровождением. Один из путей упрощения стадии сопровождения состоит в учете особенностей этого этапа на остальных стадиях разработки программного изделия.

 

 

6. Виды тестирования

Процесс тестирования можно классифицировать по:

а) возможности доступа к исходному коду:

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

• тестирование "черного ящика"

б) по тому, нужно ли выполнять исходный код:

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

• статическое тестирование (анализ исходного кода)

в) по охвату тестируемого приложения

• модульное тестирование (unit-тесты)

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

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

• альфа и бета тестирование

• приемо-сдаточные испытания

• пилотное тестирование

г) по тестируемым областям работы приложения:

• "дымовое" тестирование (может содержать тесты любого из следующих видов)

• функциональное тестирование

• нагрузочное тестирование

• тестирование безопасности

• тестирование удобства использования (usability тестирование)

 

7. Разработка тестов для задачи

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

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

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

Рисунок 1. Экран приветствия

После создания и оценки задач используйте запрос "Разбиение работ" для просмотра разбиения всех требований и задач. 

Документация по проекту

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

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

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

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

Анализ проекта

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

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

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

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

Проверка качества

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

Создание рабочего элемента анализа для проекта

Рабочий элемент анализа создается для документирования результатов анализа проекта. Команда проверяющих должна составить план дальнейших действий по проектированию, который во многом зависит от масштабов необходимых изменений. Если никакие изменения не требуются, необходимо задать для состояния рабочего элемента значение "Закрыто", в качестве причины закрытия указать "Принято (как есть)" и пометить, что для данного проекта можно начинать работу по созданию кода. Если требуются незначительные изменения, необходимо задать для состояния рабочего элемента значение "Разрешено", а в качестве причины указать "Принято с незначительными изменениями". Это означает, что работу над кодом можно начинать после внесения незначительных изменений в проект. Если требуются значительные изменения, необходимо задать для состояния рабочего элемента значение "Разрешено", а в качестве причины указать "Принято со значительными изменениями". Проект необходимо переделать и провести еще одну проверку до начала работы над кодом.

Модульные тесты

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

Анализ кода

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

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

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

Процесс анализа кода

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

1. Создайте рабочий элемент анализа для отслеживания принятых в ходе анализа решений. Если никакие изменения не требуются, необходимо задать для состояния рабочего элемента значение "Закрыто", в качестве причины закрытия указать "Принято (как есть)" и пометить, что для данного проекта можно начинать работу по созданию кода. Если требуются незначительные изменения, необходимо задать для состояния рабочего элемента значение "Разрешено", а в качестве причины указать "Принято с незначительными изменениями", что означает, что работу по созданию кода можно начинать после внесения незначительных изменений. Если требуются значительные изменения, необходимо задать для состояния рабочего элемента значение "Разрешено", а в качестве причины указать "Принято со значительными изменениями". Проект необходимо переделать и провести еще одну проверку до начала работы над кодом.
2. Определите состав участников анализа кода. Как правило, в анализе участвуют как минимум главный разработчик и ответственный за соответствующую область кода разработчик.
3. Запланируйте собрание по проверке и заблаговременно предоставьте всем проверяющим код для тщательного ознакомления.Спланируйте продолжительность собрания по проверке в зависимости от объема кода для анализа.

Анализ кода

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

Таблица 4. Анализ кода

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

 

Рефакторинг кода

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

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

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

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