Рабочие продукты процесса

Рабочие продукты процесса

В традиционных проектах по созданию ПО основное внимание уделяется последовательной разработке рабочих продуктов: сформулируйте требования, сконструируйте удовлетворяющую этим требовани* ям проектную модель, создайте соответствующую этой модели реализацию, а затем скомпилируйте и протестируйте реализацию для ее внедрения. Такой процесс подходит для небольших, выполняемых исключительно на заказ разработок, в которых представление на этапе проектирования, представление на этапе реализации и представление на этапе внедрения тесно связаны. Например, определенная программа, предназначенная для выполнения на определенном компьютере определенного типа и состоящая целиком из компонентов специального назначения, созданных на заказ, может строиться таким образом, чтобы все представления вытекали одно из другого.
Ключевые моменты.
А Рабочие продукты процесса подразделяются на пять видов: управление, требования, проектирование, реализация и внедрение.
А Рабочие продукты управления содержат информацию, необходимую для синхронизации потребностей заинтересованных сторон. А Рабочие продукты требований, проектирования и внедрения ведутся в строгой нотации, которая допускает автоматизированный анализ и просмотр.
Однако такой подход не годится для современных программных систем, в которых системная сложность (по многим параметрам) приводит к такому бесчисленному количеству рисков и слабой взаимосвязи, что эффективно использовать упрощенный подход последовательных преобразований не представляется возможным. Большинство современных систем состоит из огромного числа компонентов (некоторые из них сделаны на заказ, другие предназначены для повторного использования, третьи являются коммерческим продуктом), способных работать в разнородной.
сети распределенных платформ. Для них требуются иные последовательности эволюции рабочих продуктов и совершенно иной подход к преемственности.
За последние 20 лет индустрия ПО достигла определенного уровня зрелости, а процесс управления стал итерационным. Вместо того чтобы создавать рабочие продукты последовательно, со всеми ними работают одновременно, а ограничения, различия в уровнях абстракции и степени свободы находятся в равновесии. Повторяющиеся в успешных проектах особенности показывают, что рабочие продукты развиваются вместе с уровнями детализации. Они не проходят однонаправленное линейное преобразование от требований к проектированию, реализации и внедрению. Выбор, касающийся реализации и внедрения, оказывает влияние на то, в каком виде формулируются требования, и на то, в каком направлении происходит проектирование. Информация и решения могут перетекать различными способами из одних рабочих продуктов в другие. Задача хорошего процесса разработки — исключить ненужные, непродуманные ограничения и приспособиться к реально существующим в разработке ограничениям.
Каково же влияние итерационного подхода на рабочие продукты? Главным отличием от традиционного подхода является то, что внутри каждой стадии жизненного цикла работа ни в одном направлении не развивается лишь поступательно, так же как создание рабочих продуктов не происходит монотонно от одних продуктов к другим. Напротив, различные виды деятельности направлены на повторное обращение к одним и тем же рабочим продуктам, что позволяет последовательно обогащать общее описание системы и сам процесс уроками, извлеченными при попытке сохранения равновесия между широтой и глубиной информации.