Просмотр исходного текста страницы Блог:Максима Цепкова/2011-06-07: V-модель и роли в разработке

{|

|
[[Файл:Systems Engineering Process II.svg|thumb|400px|Рисунок 1]]

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

Для визуальной иллюстрации использована [http://en.wikipedia.org/wiki/V-Model_(software_development) V-модель] процесса разработки, которая была позаимствована из системной инженерии. Диаграмма модели, позаимствованная из статьи по ссылке приведена на рисунке 1. По нисходящей ветви идет конструирование и создание программного артефакта, а по восходящей - его тестирование и внедрение.

|-
|
[[Файл:Systems Engineering Process 3 roles.svg|thumb|400px|Рисунок 2]]

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

|-
|

[[Файл:Systems Engineering Process 2 roles.svg|thumb|400px|Рисунок 3]]

Второй вариант разделения обязанностей представлен на рисунке 3. Здесь Аналитик по общению с конечным заказчиком формулирует задание на разработку и выступает в роли заказчика для разработчика, принимая результат и, в свою очередь, передавая бизнес-заказчику. Такая конструкция тоже достаточно распространена и, в частности, ее высказывал [http://www.req-labs.ru/rapporteurs/detail/1978/ Пауль Тернер на Req-Labs]. Большим преимуществом этой конструкции является гораздо большая ответственность аналитика за качество тех артефактов, которые он передал для разработчики и за конечный результат - поскольку он знает, что именно ему надо будет сдавать результат заказчику. Недостатком же этой модели, если рассматривать ее в чистом виде, является достаточно большая нагрузка на аналитика, которые обычно представляют собой дефицитный ресурс. Это может быть решено за счет промежуточной модели, в которой тестировщики появляются, но окончательная передача все равно остается на аналитике.

|}

{{wl-publish: 2011-06-07 20:58:31 +0400 | MaksTsepkov }}
[[Категория:Люди]]
[[Категория:Роли]]