121

Конференции Семинары и Тренинги / Re: [Спб] Круглый стол - Формирование базы знаний

« : 01 Декабря 2009, 11:07:52 »

Виталик, делить обязанности всеравно прийдется (хотябы по областям знаний). За документ не может отвечать вся группа, которая над ним работает.

Ира, я как раз за то, чтобы каждый делился СВОИМ опытом, а не пытался агрегировать это все в некое общее.
Такого общего уже много. Заняться хоть переводом BABOK - получишь общее.
Страницу в вики можно поделить - один пишет свою часть, другой свою и объединено это все единой темой.

Вот ты сейчас какими темами больше всего интересуешься?

Продуктовой разработкой и управлением требованиями.
Однако то, чем я интересуюсь, на данном этапе не может быть представлено как опыт, потому что это накопление знаний и применение их на практике. После некоторого времени я могу представить это ввиде знаний.

Записать сейчас могу свой опыт по вариантам использования, управлению изменениями и анализу существующих систем, что частично уже начал делать в своем блоге.

122

Конференции Семинары и Тренинги / [Спб] Круглый стол - Формирование базы знаний

« : 01 Декабря 2009, 10:45:53 »

Так Вики уже есть, нет людей которые могут что-то наполнять, материала уже куча.
http://uml2.mytrac.ru/

В данном случае имелось ввиду скорее всего накопление личного опыта специалистов и оформление его в неком доступном виде.
Например: 
1. Специалист много времени уделяет работе с заказчиком и имеет большой опыт в коммуникациях
2. Другой занимался больше анализом и UML...
Пусть каждый опишет свой опыт в определенной части, расскажет примеры и тп. и донесет это до аудитории. Такая база знаний наиболее полезна
Если мы просто разделим обязанности и раздадим задания - ты пиши это, а ты пиши то - получится пересказывание книг.

123

Термины и Определения / Re: [Термин] FEATURE

« : 30 Ноября 2009, 10:28:53 »

А вот для продуктовой разработки фича может содержать слово ДОЛЖНО. Например, есть отдел, который анализирует рынок, отклики покупателей, тенденции развития отрасли и выдает постановку задачи типа "Чтобы быть конкурентно-способными нам надо выпустить продукт, на коробке которого мы сможем написать: /список фич/". И с этого начинается проработка конкретных требований и прочего.

Мне кажется, это просто сформулированная мысль с использованием слова коробка. Так, наверное, маркетологам легче мыслить.
Может быть вы хотели сказать, что все выше перечисленные отделы формулируют список фич (исследуют, узнают, придумывают, оформляют коробку...), а до Вас доносят в виде формулировки "Должно быть на коробке...", Что нужно интерпретировать как "Продукт должен обладать следующими возможностями..."

А по сути без разницы, заказная разработка или коробочный продукт на рынок. Сначала требования, потом поставка.
В первом случае список фич пишут на сайте, как Вы сказали, а во втором - на коробке. Это лишь способ оформления информации о продукте (системе)

124

Термины и Определения / Re: [Термин] FEATURE

« : 27 Ноября 2009, 17:10:03 »

Фича продукта - это то, чем облает продукт (группа ф-ти, кот уже есть и чем этот продукт лучше конкурентов)

...или чем ДОЛЖЕН обладать продукт.
Не забывайте, что мы говорим о требованиях, а не поставке готового продукта на рынок и его рекламе
Тот факт, что фича после реализации попадает в описание продукта на коробке, это следствие того, что кто-то на начальном этапе ее придумал и далее реализовал

125

Термины и Определения / Re: [Термин] FEATURE

« : 27 Ноября 2009, 13:36:44 »

По-моему, сейчас, определение того что есть требование что есть фича - вопрос скорее религии, чем стандарта:)

Согласен. Мне кажется, Эд, не стоит сильно напрягаться и искать истину. Главное чтобы помогало.

126

Термины и Определения / Re: [Термин] FEATURE

« : 27 Ноября 2009, 10:16:27 »

Я придерживаюсь определения Лиффингуэла:

Feature
a service provided by the system that fulfills one or more stakeholder needs.

Software Requirements
Once we have established the feature set and have gained agreement with the customer, we can move on to defining the more specific requirements we will need to impose on the solution. If we build a system that conforms to those requirements, we can be certain that the system we develop will deliver the features we promised. In turn, since the features address one or more stakeholder needs, we will have addressed those needs directly in the solution.

В Sparx EA, как мне показалось, определение фичи другое

A Feature is a small, granular function or characteristic expressed in client-valued terms as a satisfaction of a requirement; for example: 'context-sensitive Help', or 'ability to reverse-engineer VB.Net'.

Features are the primary requirements-gathering artifact of the Feature-Driven Design (FDD) methodology. They define the product feature that satisfies what a Requirement element has formalized as a contractual, testable, expected deliverable (for example: requirement - 'every element must provide context-sensitive Help'; feature - 'every element provides context-sensitive Help'). One Feature might realize one or more Requirements, and one Requirement might be realized by more than one Feature.

Features also have relationships with Use Cases. A Use Case defines the interaction a user has with the system in order to satisfy one or more Requirements. The Feature identifies the facility that provides the means for that interaction.

Feature elements are non-UML and are not related to UML-defined features, which are either BehavioralFeatures (operations, or methods) or StructuralFeatures (Ports, Parts and attributes).

127

О Сайте и Форуме / Re: Заявки на новые подразделы форума

« : 27 Ноября 2009, 10:00:07 »

Предлагаю переименовать раздел «Системный анализ и требования» в «Разработка и управление требованиями». Внутри создать раздел «Управление требованиями», на том же уровне, что и «Варианты использования».
Раздел «Проектирование» переименовать в «Системный анализ и проектирование».

Вот оно правильное разделение
+1

128

Термины и Определения / Re: [Термин] FEATURE

« : 27 Ноября 2009, 09:52:51 »

Я под фичей понимаю некое высокоуровневое описание возможности системы, которое несколькими предложениями описывает кусок связанной функциональности или некое отличительное свойство системы (то что отличает наш продукт от других). Для разделения детальных требований от фич обычно использую шаблон "возможности" и "поддержка", т.е. для бизнеса или пользователя должна быть такая-то возможность..., или системе должна подерживать некий механизм или ноу-хау.
Пару примеров:

• FEAT.189 Поддержка обратной связи от пользователей
  Пользователю должна быть предоставлена возможность доведения до производителя личного мнения о продукте (жалобы, предложения, отзывы и т.п)
  Фаза: 1.0  Приоритет:Medium  Статус: Proposed
  
• FEAT.15 Поддержка портретной и альбомной ориентации экрана
  В системе должна быть предусмотрена поддержка портретной и альбомной ориентации экрана, а также автоматический поворот в соответствии с положением G-сенсора
  Фаза: 1.0  Приоритет:Medium  Статус: Approved
  

По фичам хорошо прослеживаются границы системы и удобно планировать. Далее уже начинаешь копать более детально
Как-то так.

129

Системный Анализ и Требования / Re: Управление требованиями. Атрибуты

« : 25 Ноября 2009, 10:20:15 »

стартап и опенсорс, "по моему скромному мнению" здесь не причем. Открытый исходник это вообще модель поставки продукта и относится к реализации более (не путать с ситуацией когда много народа кодят удаленно по кускам что-то общее без всяких спек). Есть такие опенсорс проекты, которые требуют не только аналитики но и много чего большего.

Планировать процесс и управление требованиями можно и нужно всегда. Просто вы начали не с того. Атрибуты это один из самых последних моментов в планировании управления требованиями. Начните с заинтересованных лиц, типов требований, попробуйте организовать трассировку (если есть время), сгруппировать требования, понять какие документы вы делаете и какие действительно нужны.
Для того, чтобы донести прогресс до руководства:
1. Выпишите список текущих проблем, которые вы хотите решить в части аналитики
2. Изучите текущий процесс и найдите слабые стороны в работе
3. Подумайте и предложите методы улучшения. Что-то типа плана развития (лучше внедрять их потихоньку и смотреть как они будут жить).
4. С предложениями уже стоит пойти к руководству и говорить, что Вы видите такие-то пути решения проблем, и такой-то предполагаемый эффект

Если руководство не принимает, всегда можно попробовать "снизу".
После того, как вы улучшите слабые места и докажите, что процесс приносить значение, можно развиваться далее и писать уже "мега-гига RMP" и внедрять новые технологии.
Не надо начинать строить дом с крыши.

130

Сообщество Аналитиков / Re: Какие проблемы вас волнуют больше всего?

« : 25 Ноября 2009, 10:02:25 »

1. Как организовать взаимодействие между менеджерами продуктов и аналитиками
2. Как управлять и вести требования для матрицы продуктов-сервисов (много сервисов на много платформ)
3. Как согласовывать и учитывать потребности большого количества заинтересованных лиц (больше 10)
4. Как "вырастить" хорошего аналитика и сделать так, чтобы он не сбежал

131

Системный Анализ и Требования / Re: Управление требованиями. Атрибуты

« : 24 Ноября 2009, 14:07:36 »

Хочу предложить нашему руководству ввести систему управления требованиями. Сейчас пишу План по управлению требованиями.
Раздел про предлагаемые атрибуты требований я составила максимально подробно (вычеркивать всегда проще, чем добавлять).
Уважаемые господа, оцените/покритикуйте, пожалуйста список атрибутов и возможные значений для них
http://www.developmentontheedge.com/~exotica/requirements/attributes.xls

Советую идти не от атрибутов, а от понимания того, как вы будете это использовать на практике в вашем проекте, как вы будете управлять требованиями и для чего оно вам нужно? т.е как поможет решить Вашу проблему?
Именно с этого нужно начинать, чтобы доказать руководству, что возврат от вложенных усилий будет положительный.
Я так понимаю, вы ранее требованиями не управляли и сейчас основываетесь более на теоретических знаниях, чем на опыте.
Также учтите, что
1. поддержка большого количества атрибутов занимает много времени
2. часто не обосновано и не исходит от реальных потребностей

132

Работа / Re: СПб проектировщик взаимодействия

« : 24 Ноября 2009, 13:59:12 »

Мое почтение!
Хочется узнать, востребована ли данная роль в СПб?
Есть большое желание разрабатывать ПО на основе требований конечного пользователя, а не так как это себе видит разработчик.
На текущем месте работы, к большому сожалению, этому не уделяют должного внимания.
А как с этим обстоит дело в других компаниях?

Как и везде. Разработчики считают себя пользователями и думают, что так как они делают это удобно

133

Системный Анализ и Требования / Re: Система управления требованиями

« : 23 Ноября 2009, 15:17:11 »

Виталь, все-таки Raquest дает дополнительное удобство работы с требованием, которого нет в ЕА. Вполне возможно ты и прав, посмотрим в ходе использования.

Какие удобства он дает?

Тогда поставим еще вопрос: кто-то использует ЕА в качестве системы управления требованиями и какие впечатления?

Мы используем EA. В корпоративной разработке ИС уже живет и работает, в продуктовой разработке процесс сейчас ставим и пытаемся внедрить, далее будем смотреть как живет и вносить коррективы. Меня пока все устраивает более или менее в части ведения требований и их управления (даже без RaQuest). Документы генерим, хотя в rtf есть свои минусы. Есть также трудности по внедрению инструмента "далее аналитиков", но думаю это дело времени и созревания команды

134

Примеры / Re: Uml-модель экономической системы общества.

« : 22 Ноября 2009, 21:27:04 »

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

Ну вроде бы я никак не противоречил этому. Анализ есть разбиение целого на части. Его для того и придумали чтобы понимать составляющие системы (мира) - ее компоненты и идентифицировать связи между ними. Например тот же IDEF0. Я же не говорил, что части независимы друг от друга, просто каждая обычно отвечает за определенное направление деятельности - так легче анализировать систему, когда понимаешь ее составляющие и так делают люди.
Если у вас свой собственный подход, тогда будет здорово если ваши цели будут достигнуты и вы поделитесь опытом.

135

Системный Анализ и Требования / Re: Система управления требованиями

« : 22 Ноября 2009, 20:52:33 »

Кроме RaQuest+EA наверное из дешевых других альтернатив нет.

А зачем Raquest? Sparx EA и без него не плохо работает и если вести требования списками то и диаграммы не нужны. Тем более что продукт сырой.