Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: bas от 15 Мая 2008, 13:12:57
-
Представим себе ситуацию. Есть компания, большая компания, бизнес которой связан или не связан с ИТ, типа Лукойла, Роснефти, МТС, Люксофт и т.д.
Так вот у них много подрядчиков, в том числе на разработку ПО и в частности на разработку ТЗ и требований. Так же есть свое подразделение Разработки, которая пишет ПО, разрабатывает требования. Компания хочет ревьюировать внешние ТЗ и создавать у себя базу знаний требований, чтобы была возможность безболезненного смены подрядчика и следовательно чтобы у них всегда была актуальная база требований.
Как в таком случае можно управлять требованиями, а скорее кучей приходящих ТЗ??
Есть три варианта:
1. Принимать ТЗ и складировать их у себя в проектных папках. Но тогда встает вопрос про связывание требований, их синхронизации и прав доступа
2. Принимать ТЗ из вне и тупо перебивать их в СУТ (система управления требований). Тогда быстро произойдет рассинхронизация
3. Заставить подрядчиков работать во внутренней СУТ. Вариант хороший, но какие есть подводные камни??
-
Чтобы заставить подрядчиков работать во внутренней СУТ, их нужно, во-первых, формально обучить работе с этим конкретным инструментом, а во-вторых, заставить следовать, может быть, некоторым неформальным правилам, принятым в компании.
По моему опыту, само слово "требования" до сих пор каждый понимает по-разному.
Пример не о СУТ, но, на мой взгляд, ситуация похожая.
У нас, например, есть два трекера запросов - "внешний" на сайте компании (с входом для зарегтистированных партнёров) и "внутренний". Точнее, было два. Внешний уже два года мёртвенький - ни одного запроса. Оглядываясь назад, можно сказать, что это результат нашей недальновидной политики: сначала мы создали этот внешний трекер, чтобы переложить часть работы по сбору требований и учёту запросов на партнёров, а потом обнаружили, что "перевод запросов на человеческий язык" требует ещё бОльших трудозатрат. Поэтому вернулись к старой схеме: собираем запросы многочисленными способами (встречи, телефон, mail, онлайн-мессенджеры), а учитываем их в удобном для нас виде только после "первичной обработки".
Сейчас вот пытаемся упорядочить типовые требования с помощью заранее подготовленных шаблонов. Но трудный это процесс - большинство клиентов предложение заполнить наши шаблоны пока просто игнорирует, приходится добывать из них информацию по крупицам.
Тут я должен отметить, что практически не знаком с коммерческими системам учёта требований и "большими процессами" типа RUP. Может, в них реализованы некоторые волшебные возможности, которые в конечном итоге позволяют всем участникам разговаривать на одном языке? (честно говоря, слабо верится) Когда-то имел дело с ГОСТами (в испытательной организации-представителя заказчика), но тогда у меня сложилось впечатление (возможно, ошибочное), что работать "строго по госту" могут себе позволить только предприятия ВПК, у которых в избытке ресурсов и которым некуда спешить.
-
1. Ситуация не похожая. В вашем случае Вы зависите от Клиентов, они вас могут и вправе послать вас ... заполнять самим эти шаблоны. Тут же наоборот - мы диктуем что хотим, а подрядчики исполнят
2. На счет обучения и следования правил. Да ты прав, тут надо как минимум писать регламенты и инструкции
3. Про ГОСТ - это ты зря, выкидываем что не нужно и заполняем действительно ценные разделы, как например цели и задачи :)
-
но тогда у меня сложилось впечатление (возможно, ошибочное), что работать "строго по госту" могут себе позволить только предприятия ВПК, у которых в избытке ресурсов и которым некуда спешить.
Про ГОСТ - это ты зря, выкидываем что не нужно и заполняем действительно ценные разделы, как например цели и задачи :)
А по моему ничего не зря, что это за ГОСТ из которого все выкидываешь. И опять же о чем речь о ТЗ или о всех спектрах работ и оформлений документаций?
Если только о ТЗ - то слов из песни не выкинешь, а если о процессе по ГОСТ - ну так это же само собой.
Правда еще вопрос ГОСТ какой?
-
...Так вот у них много подрядчиков, в том числе на разработку ПО и в частности на разработку ТЗ и требований. Так же есть свое подразделение Разработки, которая пишет ПО, разрабатывает требования. Компания хочет ревьюировать внешние ТЗ и создавать у себя базу знаний требований, чтобы была возможность безболезненного смены подрядчика и следовательно чтобы у них всегда была актуальная база требований.
Как в таком случае можно управлять требованиями, а скорее кучей приходящих ТЗ??
1. Компании нужно для начала создать корпоративный стандарт на документацию требований и форму их представления и заставить подрядчиков следовать ему.
2. Компании нужно заставить подрядчиков вносить изменения в ТЗ при их наличии, чтобы требования были актуальны. Т.е. имеем поставленный в компании процесс работы с требованиями вообще.
3. Создать единый репозиторий требований на базе некого тула и загонять все туда. При необходимости давать доступ туда подрядчикам, чтобы сами вколачивали требования.
Такое решение не идеально, т.к. потребует затрат на поддержку репозитория требований, его анализ, связи ... но, я бы сказал так -- для такой компании для начала нужно бы выстроить EA, потом внедрить процесс управления изменениями (в контексте EA как минимум), и требованиями как таковыми. Тогда станет видна СИСТЕМА и связи м/у различными приложениями, а следовательно и требований к ним. Вот где появится базис для анализа! Очевидно, что при такой постановки вопроса требования будут являться органичной частью этой системы.
-
Первые три пункта понял :)
Юра,
Под EA ты видимо имел в виду - Enterprise Аrchitecture (http://en.wikipedia.org/wiki/Enterprise_architecture)
В общем, в данном случае относительно требований надо продумать политику (регламент) их изменения + построить первоначальный репозиторий требований, так?
3. Создать единый репозиторий требований на базе некого тула и загонять все туда. При необходимости давать доступ туда подрядчикам, чтобы сами вколачивали требования.
Ну тут как раз и очень вероятна рассинхронизация, если не давать доступ к тулзе подрядчикам. Или при изменении требований подрядчики должны оповестить что и где поменялось??
-
Первые три пункта понял :)
Юра,
Под EA ты видимо имел в виду - Enterprise Аrchitecture (http://en.wikipedia.org/wiki/Enterprise_architecture)
В общем, в данном случае относительно требований надо продумать политику (регламент) их изменения + построить первоначальный репозиторий требований, так?
Ну тут как раз и очень вероятна рассинхронизация, если не давать доступ к тулзе подрядчикам. Или при изменении требований подрядчики должны оповестить что и где поменялось??
Да, соори забыл что под EA еще можно понимать тул от Sparx :-), я имел ввиду именно Enterprise Architecture.
Худшим для организации, с т.з. затрат будет случай, когда подрядчики просто приносят новую версию ТЗ в виде файла Word, и нужно сажать аналитика (можно конечно стажера), который скурпулезно будет изучать документ, выяснять что изменилось и делать правки руками в репозитории требований. Это просто получается трудоемко. Но за все приходится платить, удешевить можно, только работой стажеров :-).
Вобщем идеальный вариант -- навязать подрядчикам использование процесса, формата и правил документирования требований и использование репозитория с тулом. Типа условие контракта. Иначе -- самим придется все отслеживать.
По середине вариант -- формальный процесс управления изменениями (в отношении требований в данном случае), тогда все изменения будут очевидны и не потребуют скурпулезного изучения каждый раз новой версии документа.
-
Юра,
Можешь раскрыть - что ты конкретно понимаешь под "формальный процесс управления изменениями (в отношении требований в данном случае)"??
-
Думаю, что это управление конфигурациями, которое Йордон считает самым главным процессом в безнадежных проектах. Configuration management в RUP. И я с ним согласна.
-
Это я тоже понял, я представляю процесс изменений и ЖЦ требований.
Но что именно Юра предлагает добавить в простой процесс внесения изменений в требование и отправку ее на разработку и тестирование??
-
В данном случае речь идет о том, что прежде чем изменить требование (непосредственно в документе или в репозитории, в данном случае не столь важно) - нужно внести некое предложение по изменению и пройти формальный approvement (с анализом конечно) по каждому изменению. Тогда становиться очевидным, КАКИЕ пункты документа (или items в репозитории) должны измениться. После утверждения - это изменение вносится. Предусловия -- требования должны быть recognisable, т.е. должны быть построены по определенным правилам (например иерархия + правила формулировка) и иметь свой ID. Тогда процесс внесения изменений упрощается в разы, особенно если сравнивать с ситуацией, когда приходит слабоструктурированный текст ТЗ в документе, где идентифицируются только разделы.
Как вариант по идентифицируемости требований -- старый добрый способ нумеровать подпункты для каждого отдельного statement в ТЗ, при этом подходе уже можно к чему-то адресоваться при изменениях. И для больших контор с советским прошлым такой формат написания ТЗ протащить легче ибо он часто использовался при написании ТЗ.
-
Юра,
Теперь понятно. Спасибо.
-
Возможно, имеет смысл завести СУТ для относительно редко изменяющихся высокоуровневых бизнес-требований, количество которых измеряется десятками, а также первичных документов, из которых они взяты (протоколов интервью, схем БП, анкет, регламентов, бланков и т.д.). И требовать от исполнителей общаться по бизнес-требованиям только через эту СУТ. В качестве подобной СУТ подойдёт практически любая wiki-подобная система. Например TikiWiki (http://info.tikiwiki.org/tiki-index.php (http://info.tikiwiki.org/tiki-index.php)), в ней поддерживается история редактирования.
А системные требования дать на откуп исполнителям: всё равно их чаще всего пишут неправильно, перемешивая с домыслами и элементами архитектуры, и если один исполнитель начнёт изучать системные требования, написанные другим, получится вдвойне испорченный телефон.
-
Вообще на входе требований в головную организацию должен быть выстроен жесткий процесс ревью требований с соответствующими шаблонами, регламентами и жестким контролем, тогда без разницы о каком уровне требований мы говорим.
На роль СУТ в данном случае может претендовать один из известных Wiki движков.