65
«по команде из-пэров» подхода без лидера доминирующей проекта. Оба прин-
ципа не только улучшить качество программного обеспечения, но и то, как он по-
строен. Microsoft предоставляет несколько шаблонов для артефактов, рекомендо-
ванных в MSF. Поскольку MSF не включает в себя огромный набор рекомендуе-
мых средств (которые будут меняться с следующей версией Visual Studio), она
может быть легко интегрирована в существующую среду разработки.
Экстремальное программирование представляет собой совершенно новый
подход к разработке программного обеспечения. Для небольших проектов, XP
предлагает хороший подход для достижения высокого качества программного
обеспечения. Тесное вовлечение клиента, основное внимание на тестировании, и
подход к снижению ИКР поддержки этой цели. Тем не менее, XP может привести
к организационным проблемам при применении в больших проектах. Для боль-
шинства проектов, тесная интеграция клиента в процессе разработки трудно до-
стичь.
Основными критериями для выбора стандарта ЖЦ будут в таблице 2.1:
Итерационной – для того, чтобы установить более высокое качество про-
граммного обеспечения, процесс разработки программного обеспечения должен
использовать итеративный и инкрементный подход к развитию. Итерационные
циклы включают все виды деятельности в области развития анализа, проектиро-
вания, реализации, тестирования и, наконец, развертывание. Контроль качества
может применяться более эффективно в течение всего процесса. При использова-
нии итеративного подхода, процесс приобретает большую гибкость при работе с
изменяющимися требованиями или областью. Выпуски продукта из произведения
силы ранней обратной связи от клиентов и заинтересованных сторон, которая
имеет жизненно важное значение для улучшения общего качества программного
обеспечения. Однако, итеративная разработка должна быть поддержаны управле-
ниями рисками и ранним вовлечением конечных пользователей для достижения
своего полного потенциала. XP основывается на очень строгий итеративный под-
ходе, требующий ежедневную сборку всех компонентов. Это ограничивает время,
необходимое для столкнуться с ошибками и разработчиков сил, чтобы решить
проблему как можно скорее. Конечно, неполные компоненты или отдельные ме-
тоды исключены из ежедневной сборки. Структура декомпозиции работ должна