Хочу подготовить связанную серию бесплатных семинаров, но не знаю какой лучше взять вектор. Есть 2 варианта:

1. Двигаться вдоль методологии разработки ПО
1.1. Общий обзор методологий и роли Аналитика в процессе разработки ПО
1.2. Бизнес анализ. Рассказать что Аналитик делает в данной дисциплине, зачем нужна данная дисциплина, какие готовятся артефакты, как моделировать БП и БО и зачем это нужно
1.3. Системный анализ + Требования. Рассказать что Аналитик делает в данной дисциплине, зачем нужна данная дисциплина, как моделировать требования к ПО и зачем это нужно
1.4. Проектирование. Рассказать что Аналитик делает в данной дисциплине, зачем нужна данная дисциплина, как моделировать архитектуру  ПО и зачем это нужно
1.5. Разработка+Тестирование+Внедрение. Что делает Аналитик в этих дисциплинах и как используется здесь документы Аналитика
1.6. Управление изменениями. Как правильно управлять изменениями с т.з. Требований
1.7. Управление проектом (УП). Что Аналитик должен знать про УП и как он работает в проектной команде
1.8. ПО Аналитика. Обзор необходимого ПО Аналитика.
+Примеры

2. Двигаться вдоль дисциплины управления требованиями
1.1. Общий обзор требований и роли Аналитика
1.2. Сбор требований. Зачем, как нужно и как не нужно
1.3. Анализ требований.
1.4. Документирование требований
1.5. Моделирование требований.
1.6. Проверка требований.
1.7. Изменение требований
1.8. Требования в различных дисциплинах разработки ПО (БА, СА, Проектирование, ....)
+ Примеры

Что бы Вам было более интересно?

Саш, мне все интересно. За оба направления проголосовать можно?

Если я все правильно понял, то пункт 2 является декомпозицией пункта 1.3.

Так вот наиболее интересно мне было бы узнать о всех пунктах варианта 1 на уровне варианта 2.

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

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

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

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

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

:-) Может, конечно, и можно, но у меня первая ассоциация по этой теме "Есть ли жизнь на Марсе, нет ли жизни на Марсе, науке это неизвестно"

Интересный подход у народа. Голоса пока разделились поровну 3х3

ИМХО второй подход более теоритизированный, т.е. умения могут быть, но как применять их на практике не совсем понятно. + Не совсем понятно как проводить практические занятии например по разделу Сбору Требований
Второй ИМХО более практичный подход. Естественно за основу возьму РУП, но так же буду показывать что и где можно облегчить и выкинуть, а что нельзя.

Понятно, что хорошо бы начать со второго и закончить первым, но сил на это не хватит пока. Так что надо выбрать что-то одно. Голосуем товарищи

А я бы проголосовала за первый вариант, мне как раз интересны ответы на вопросы типа "Есть ли жизнь на Марсе?". =)) Более конкретные вещи легче найти, прочитать и ассимилировать самостоятельно.

Анна, так Вы за первый или второй вариант?

Первый. Я просто форму голосования сразу не заметила.

Немного поправил описание направлений.

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

Поговорили мы с Ирой по аське и пришли к мнению, что нужно сначала выписать цели каждого направления.

Если брать 1ое направление, то цель следующая:
Научить слушателей применять знания Аналитика на практике в процессе разработки ПО

Если брать 2ое направление, то цель:
Научить слушателей правильно работать с Требованиями

Т.е. логичнее идти от 2ого курса, кот. дает как раз знания Аналитика, а потом уже применять их на практике. С другой стороны 1ый курс более приближен к реалям разработки и даст практические советы по работе Аналитика в процессе разработке ПО (что, когда и как нужно делать).

В общем я весь в смятении, что выбрать

Ира, кстати, предложила такую идею:

кстати, можно на семинаре 2-3 части делать:
1 - связь с какой-то дисциплиной,
2 - то, чем должен владеть аналитик для этого,
3 - пример

Но тогда получается что в дисциплинах Бизнес Анализа и Анализа Требований нужно говорить о всех знаниях Аналитика

А что бы не сделать семинар на действительно волнующую многих тему, например, «Как писать ТЗ»? )

Ну по идеи такой семинар должен входить и в первое и во второе направление.