2011-06-07: V-модель и роли в разработке
м (Новая страница: «<div style="float:right; width:40%; padding: 0em .5em; margin: 0em 0em 0em 1em; background-color: Lavender; border: dashed 1px darkBlue"> {{Файл:Systems Engineer...») |
м |
||
Строка 1: | Строка 1: | ||
+ | {| | ||
+ | | | ||
+ | [[Файл: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 }} |
Версия 01:51, 10 ноября 2014
Существует два различных варианта представления роли Аналитика в процессе создания программного обеспечения. Каждый из них имеет свои плюсы и минусы, и потому может быть использован в реальной жизни. Обязанности аналитика в этих вариантах сильно отличаются и, как следствие, сильно различаются требования к компетенциям аналитика. К сожалению, участники многих обсуждений, придерживаясь различных взглядов, не формулировали явно свое представление о роли аналитика, каждый подразумевал свое понимание единственным. И от этого возникали недоразумения. В этой статье визуально иллюстрируются оба подхода, что позволит при необходимости осознать различия и вести эффективную дискуссию. Для визуальной иллюстрации использована V-модель процесса разработки, которая была позаимствована из системной инженерии. Диаграмма модели, позаимствованная из статьи по ссылке приведена на рисунке 1. По нисходящей ветви идет конструирование и создание программного артефакта, а по восходящей - его тестирование и внедрение. |
Классическое разделение ролей при создании программного продукта следует за процессом, как это изображено на рисунке 2. Сначала аналитики занимается сбором требований и конструированием, далее разработчик реализует его и передает тестировщикам и внедренцам. Разделение ролей внутри процесса может быть и более детальным, например, с выделением отдельных ролей бизнес-аналитика и системного аналитика. При таком разделении аналитик общается с заказчиком и создает артефакты, которые передаются разработчикам и используются для создания программного продукта. |
Второй вариант разделения обязанностей представлен на рисунке 3. Здесь Аналитик по общению с конечным заказчиком формулирует задание на разработку и выступает в роли заказчика для разработчика, принимая результат и, в свою очередь, передавая бизнес-заказчику. Такая конструкция тоже достаточно распространена и, в частности, ее высказывал Пауль Тернер на Req-Labs. Большим преимуществом этой конструкции является гораздо большая ответственность аналитика за качество тех артефактов, которые он передал для разработчики и за конечный результат - поскольку он знает, что именно ему надо будет сдавать результат заказчику. Недостатком же этой модели, если рассматривать ее в чистом виде, является достаточно большая нагрузка на аналитика, которые обычно представляют собой дефицитный ресурс. Это может быть решено за счет промежуточной модели, в которой тестировщики появляются, но окончательная передача все равно остается на аналитике. |