2011-06-07: V-модель и роли в разработке

Ссылки сюда (1) →

Рисунок 1 Существует два различных варианта представления роли Аналитика в процессе создания программного обеспечения. Каждый из них имеет свои плюсы и минусы, и потому может быть использован в реальной жизни. Обязанности аналитика в этих вариантах сильно отличаются и, как следствие, сильно различаются требования к компетенциям аналитика. К сожалению, участники многих обсуждений, придерживаясь различных взглядов, не формулировали явно свое представление о роли аналитика, каждый подразумевал свое понимание единственным. И от этого возникали недоразумения. В этой статье визуально иллюстрируются оба подхода, что позволит при необходимости осознать различия и вести эффективную дискуссию. Для визуальной иллюстрации использована V-модель процесса разработки, которая была позаимствована из системной инженерии. Диаграмма модели, позаимствованная из статьи по ссылке приведена на рисунке 1. По нисходящей ветви идет конструирование и создание программного артефакта, а по восходящей - его тестирование и внедрение.

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

Рисунок 3 Второй вариант разделения обязанностей представлен на рисунке 3. Здесь Аналитик по общению с конечным заказчиком формулирует задание на разработку и выступает в роли заказчика для разработчика, принимая результат и, в свою очередь, передавая бизнес-заказчику. Такая конструкция тоже достаточно распространена и, в частности, ее высказывал Пауль Тернер на Req-Labs. Большим преимуществом этой конструкции является гораздо большая ответственность аналитика за качество тех артефактов, которые он передал для разработчики и за конечный результат - поскольку он знает, что именно ему надо будет сдавать результат заказчику. Недостатком же этой модели, если рассматривать ее в чистом виде, является достаточно большая нагрузка на аналитика, которые обычно представляют собой дефицитный ресурс. Это может быть решено за счет промежуточной модели, в которой тестировщики появляются, но окончательная передача все равно остается на аналитике.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 19:58, 7 июня 2011 • нет комментариев