WBS (структура разбивки работ) и SRS (документ спецификации требований к программному обеспечению)

«WBS должен содержать 100% работы»… это означает, что мы должны учитывать все части работы, которые должны быть выполнены в рамках конкретного проекта. Элементы WBS определяются с точки зрения «результатов или результатов»… не все действия/детали, необходимые для получения этого результата (мельчайшие детали будут частью документа SRS и Low level Design и т. д.). Как определить уровень разбивки описано на http://en.wikipedia.org/wiki/Work_breakdown_structure

Целью WBS является определение и организация объема всего проекта для распределения обязанностей, распределения ресурсов, мониторинга проекта и управления проектом. Так что у него просто есть цели/результаты проекта. Но в случае SRS целью является охват всех функциональных и нефункциональных требований каждой цели/результата.

Для проекта малого/среднего уровня у нас обычно есть один документ WBS и несколько документов SRS. Для больших проектов мы делаем то же самое после разделения проектов на модули.

Надеюсь, это поможет. Добро пожаловать с дальнейшими конкретными вопросами. Спасибо.

Несмотря на хороший ответ Правина, я хочу обратиться к WBS, прогрессивной разработке и EVM. В то время как WBS любого конкретного проекта в любой данной отрасли должен содержать 100 % продукта/услуги, которые должны быть доставлены, а на более низких уровнях – действия, необходимые для производства продукта/услуги, нет требования, чтобы 100 % WBS было разработаны и/или известны до начала проекта. Во многих случаях и обстоятельствах просто неизвестно, что будет дальше, пока не будет выполнена определенная работа, которая может включать в себя разработку требований или спецификаций более низкого уровня.

Дальнейшая идентификация и повторение WBS по мере того, как вы становитесь «умнее», вполне приемлемы.

Проведение EVM в этом сценарии также вполне выполнимо. По мере дальнейшей проработки работы он информирует о плановых значениях, которые будут использоваться в базовом плане, и под контролем вы просто обрабатываете изменение базового плана и продолжаете работу. В этом сценарии вы можете ожидать, что BAC (базовый уровень на момент завершения) будет меняться, пока происходит уточнение. Хотя это нормально и ожидаемо, это становится проблемой коммуникации с заинтересованными сторонами.

РЕДАКТИРОВАТЬ, чтобы ответить Комментарии: С EVM у вас ВСЕГДА есть этот вариант, потому что, несмотря на массу неопределенности, с которой мы реализуем проекты, изменения на 100% надежны. Ваши возможности EVM должны быть в состоянии справиться с изменениями. Действительно, вы можете создать «базовый план» бюджета на основе приблизительных оценок стоимости работ, в которых вы не уверены. Когда вы узнаете больше, вы переоцените/уточните более поздние этапы работы и в соответствии с утвержденным процессом изменений соответствующим образом скорректируете свой бюджет.

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

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

Марк направил вас к MIL-STD-881 выше. Начните с этого. Есть и другие источники, вы можете найти там очень подробные инструкции.