Реализация задач разработки

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

Содержание раздела

Оценка

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

Анализ разработки

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

Анализ кода

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

Рефакторинг

Интеграция изменений

Оценка

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

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

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

После создания и оценки задач необходимо использовать запрос "Декомпозиция работы" для просмотра декомпозиции всех требований и задач.Дополнительные сведения см. в разделе Общие запросы (CMMI).

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

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

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

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

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

Анализ разработки

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

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

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

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

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

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

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

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

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

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

Анализ кода

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

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

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

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

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

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

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

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

3. Запланируйте собрание для проверки и заблаговременно предоставьте всем проверяющим код для тщательного ознакомления.Планируйте продолжительность собрания для проверки в зависимости от объема кода для анализа.

Анализ кода

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

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

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

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

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

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

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

Интеграция изменений

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

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

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