3. Итеративный подход управляемый рисками

Риск — это проектный фактор, который подвергает проект опасности. Это «вероятность того, что проект может столкнуться с нежелательной ситуацией, такой, как отставание от плана, перерасход средств или прекращение работ»

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

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

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

4. Обобщенная итерация

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

5. Заключение

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