Поделиться через

Действия по проекту

  • Статья

Чтобы обеспечить наиболее эффективное использование программного обеспечения MSF for CMMI Process Improvement v5.0, следует разделить проект на ряд итераций продолжительностью обычно от четырех до восьми недель. Это поможет снизить риски, связанные с проектом, из-за изменения требований и затрат на реализацию. Итеративная структура проекта — важный вклад в решение задачи удовлетворения требований к управлению рисками CMMI.

Дополнительные сведения о CMMI см. в разделе Сведения о CMMI.

Начало проекта

Начало проекта

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

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

Дополнительные сведения см. в разделе Начало проекта.

Начальное планирование проекта

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

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

  • Разработка общей схемы или архитектуры системы. Если это ведет к работе на платформе, новой для участников команды, необходимо выделить некоторое время для экспериментов с этой платформой. На ранних итерациях разработка будет медленной.

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

  • Начальное назначение требований к продукту итерациям.

  • Назначение дат выпуска.

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

Начальное планирование проекта выполняется на итерации 0.

Дополнительные сведения см. в разделе Планирование проекта (CMMI).

Изучение существующего продукта

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

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

Ход проекта

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

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

Проверка

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

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

Дополнительные сведения см. в разделе Validating Customer Requirements.

Управление рисками

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

Управление изменениями

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

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

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

Дополнительные сведения см. в разделе Управление изменениями (CMMI).

Анализ плана создания продукта

Перед планированием каждой итерации проанализируйте план создания продукта. В плане проекта итерациям назначаются требования к продукту.

Ниже указаны две основные причины изменения плана.

  • Изменения требований.

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

На более поздних итерациях изменения обоих типов становятся реже.

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

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

Дополнительные сведения см. в разделе Планирование проекта (CMMI).

Перед получением основных версий продукта

Действия при развертывании продукта зависят от его типа и здесь не рассматриваются.

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

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

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

  • Выделите ресурсы на увеличение тестового покрытия и выполнение ручных тестов.