Просмотр сообщений
166
Управление Проектом / Планирование софтверного проекта: Источник WBS?
« : 15 Февраля 2007, 10:42:53 »
Не могу понять, есть ли какой-то единый принцип формирования иерархической структуры работ в проекте по созданию ПО и ИС, или хотя бы какой-то конкретный набор подходов.
Прежде всего интересует, откуда берутся первый-второй уровни WBS при планировании проекта или его конкретной итерации при итерационном подходе. В PMBOK ничего конкретного не нашёл.
Пока обнаружил следующие подходы с использованием источников:
A. Аналогичный проект, выполненный ранее, в качестве шаблона.
B. Бизнес-компоненты системы (Обработка заказов, Управление запасами, и т.д.) - для этого нужно иметь хотя бы концепцию системы. 2-й и более низкий уровень описывают работы, которые должны быть сделаны.
D. Дисциплины - в качестве первого уровня выступают "Менеджмент", "Бизнес-анализ", "Требования", "Проектирование", "Реализация", "Тестирование", "Документирование" и т.д.
F. Функции - система описана в виде набора функций. Похоже на B, но привязка не к бизнес-сегментам и бизнес-процессам, а бизнес/техническим функциям.
R. Дерево требований - похоже на B и F, только есть уже готовые 3-4 уровня требований, под которые осталось подложить задачи.
T. Технические компоненты (Интерфейс, Бизнес-логика, БД, подсистема интеграции, ...) - аналогично B, но техноцентрично.
U. Пользовательские истории (user stories), прецеденты (use-cases) - является по сути развитием F.
Похоже, что выбор того или иного подхода в основном связан c используемой методологией, но большая часть подходов на мой взгляд страдает неполнотой, т.к. сконцентированы только на создании системы, а не на достижении желаемого целевого состояния бизнеса (в широком смысле). Опускаются маркетинговые работы, подготовка технической инфраструктуры, часто опущено обучение, малое внимание уделяется обеспечению эффективности работы системы. На мой взгляд, это следствие отсутствия целостного, интегрированного подхода к планированию "из одной точки".
Прежде всего интересует, откуда берутся первый-второй уровни WBS при планировании проекта или его конкретной итерации при итерационном подходе. В PMBOK ничего конкретного не нашёл.
Пока обнаружил следующие подходы с использованием источников:
A. Аналогичный проект, выполненный ранее, в качестве шаблона.
B. Бизнес-компоненты системы (Обработка заказов, Управление запасами, и т.д.) - для этого нужно иметь хотя бы концепцию системы. 2-й и более низкий уровень описывают работы, которые должны быть сделаны.
D. Дисциплины - в качестве первого уровня выступают "Менеджмент", "Бизнес-анализ", "Требования", "Проектирование", "Реализация", "Тестирование", "Документирование" и т.д.
F. Функции - система описана в виде набора функций. Похоже на B, но привязка не к бизнес-сегментам и бизнес-процессам, а бизнес/техническим функциям.
R. Дерево требований - похоже на B и F, только есть уже готовые 3-4 уровня требований, под которые осталось подложить задачи.
T. Технические компоненты (Интерфейс, Бизнес-логика, БД, подсистема интеграции, ...) - аналогично B, но техноцентрично.
U. Пользовательские истории (user stories), прецеденты (use-cases) - является по сути развитием F.
Похоже, что выбор того или иного подхода в основном связан c используемой методологией, но большая часть подходов на мой взгляд страдает неполнотой, т.к. сконцентированы только на создании системы, а не на достижении желаемого целевого состояния бизнеса (в широком смысле). Опускаются маркетинговые работы, подготовка технической инфраструктуры, часто опущено обучение, малое внимание уделяется обеспечению эффективности работы системы. На мой взгляд, это следствие отсутствия целостного, интегрированного подхода к планированию "из одной точки".
На самом деле было бы правильнее написать "Высокоуровневые требования к внутреннему устройству системы". Т.е. вся эта таблица - попытка взлянуть на процесс разработки и проход от потребностей до кода через призму требований. В таком контексте Архитектура системы, которую создаёт Архитектор системы, есть ничто иное, как ещё одни требования, для него исходящие, а для проектировщиков подсистем (это роль) - входящие.