Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Сless

Страницы: « 1 2 3 4 5 »
16
Пока по существу только один вопрос: что значит "открытый"?

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

Сама идея мне нравится, и содержание хорошее, но, имхо - обьем материала стоит сократить раз в 3 - 5 - 7. А то, есть вероятность того, что тренинг превратится в семинар:)
По поводу объема я сомневаюсь только в первом модуле,  многое будет зависеть начальной подготовки участников

Мне вот эта тема очень интересна. Я с ней познакомился у Басса, Клемента и Кратца(вроде).
Да собственно это оно только адаптировано под Аналитиков

Может поближе к столице Родины ?)))

Вопрос про "открытость" поддерживаю!!!!

Про открытость я ответил, А по поводу близости - в Москве сейчас идет столько открытых и местами бесплатных  тренингов по управлению требованиями, что не уверен  что набереться группа , если наберутся желающие - проведем :-)

Какие будут даны практические упражнения?
Я планирую уточнить практики по мере анкетирования участников . Пока планирую так
Мини дискуссии по каждой теме и крупные "практики"
1. 1-й
- Парное Интервьюирование  ( Или игра в вопросы)
- Мозговой штурм /Ролевая игра по формированию ТЗ
- Формулировка + Классификация
- Соcтавление CR
1.2
- Выявление и классификация ЗС
- Формулирование проблемы или позиционирование продукта
- Контекстная диаграмма
- Формулировка Features или простой UC
2.1 й Модуль
- Обсуждение либо практика по сложному UC
- Формирование модели UC
- Оптимизация модели
2.2
- Переформулирование "простых" нефункциональных требований , вспомогательные вопросы для выявления НТ
- Работа в группах над генерирующими сценариями для Атрибутов качества
- Обсуждение кейса возможно ролевая игра по requirements workshop по извлечению АК

Где то так  Буду благодарен за дополнительные идеи :-)

17
Коллеги добрый день !

  Прошу вас высказать свое мнение по программе серии открытых тренингов для Аналитиков. Ближайшей тренинг по программе планируется провести в Минске.   
В результате участия в тренинге начинающие специалисты формируют ключевые структуры для накопления и развития своих знаний и навыков, а сформировавшиеся специалисты переосмысливают уже существующий опыт и получают возможность усовершенствовать отдельные элементы.
Для удобства обучающихся тренинги собраны в блоки по два однодневных тренинга ( 8 уч. Часов каждый).
Методология обучения:
В рамках тренингов участники получают ключевой материал в виде презентаций тренера, выполняют практические задания и участвуют в дискуссиях.
Участникам тренингов предоставляются материалы лекций, базовые  шаблоны, примеры и ссылки на дополнительные ресурсы.
 
Модуль 1-й, тренинг 1-й.  Управление требованиями и их изменениями
Главная задача данного тренинга - обобщить и систематизировать знания и навыки по работе с первичными требованиями (сбору, систематизации и управлению собранными требованиями). Особое внимание в данном курсе уделяется формированию спецификаций и вопросам оптимизации трудозатрат при работе в формальных условиях
Аудитория
Начинающие аналитики и  руководители проектов
Основные темы
•   Общие вопросы при работе с требованиями
o   Контекст процесса управления требованиями
o   Участники процесса
o   Аналитик: кто он ?
o   Стандарты и лучшие практики в области управления требованиями
•   Ключевые правила работы с документами.
•   Спецификации. Документы требований в соответствии с ГОСТ и RUP
•   Сбор требований
o   Интервью и анкетирование. Подготовка опросного листа
o   Тонкости подготовки и проведения интервью
o   Протоколирование результатов, плюсы и минусы. Шаблон протокола
•   Систематизация и классификация требований
o   Виды требований
o   Цели и методы классификации
o   Классификация FURPS+
o   Требования к качеству требований
o   Базовые атрибуты
•   Управление изменениями
o   Источники изменений
o   Как враги становятся друзьями
o   Процесс управления изменениями. Совет по контролированию изменений
o   Жизненный цикл запроса на изменение
o   Анализ влияния изменений
o   Управление версиями документов
Модуль 1-й, тренинг 2-й.  Разработка требований
Управление требованиями - это необходимый минимум для выживания в проектах, связанных с разработкой ПО. Однако настоящее достижение эффективности связано с трансформацией первичных требований и созданием образа продукта, который нужен заказчику и удобен для разработки.
Аудитория
Начинающие Аналитики, Продукт Менеджеры  и  Руководители Проектов
Основные темы
•   Системный подход к решению задач клиента. Процесс разработки требований
•   Заинтересованные лица и их потребности
o   Классификация заинтересованных лиц
•   Инструменты аналитика для взаимодействия с заинтересованными лицам:
o   Концепция
o   Рабочие группы
o   Семинары
•   Постановка задачи (определение проблемы), как инструмент для достижения успешности проекта
•   Границы продукта, проекта и системы
•   Возможности продукта.
o   Отбор и приоритезация возможностей продукта. Прототипирование
o   Гибкий процесс управления требованиями
•   Создание базовых сценариев использования
•   План управления требованиями. Типы требований к системе
o   Возможные иерархии типов требований
o   Гибкий процесс управления требованиями. Как бы выглядел план управления требованиями для «гибкого» проекта, если бы его написали.
•   Трассировка требований
Модуль 2-й, тренинг 1-й. Мастерство работы над сценариями использования системы
Один из наиболее действенных современных инструментов аналитика - это сценарий использования системы. В данном тренинге рассматривается классический подход по работе над сценарием использования и наиболее сложные моменты, которые чаще всего возникают при работе над ними.
Участникам тренинга предоставляются все необходимые шаблоны  и примеры.
Аудитория
Аналитики, Продукт Менеджеры  и  Руководители Проектов, интересующиеся постановкой процесса управления требованиями в своем проекте
Основные темы
•   Работа по оптимизации модели сценариев использования
•   Работа над полным сценарием
•   Критерии оценки качества сценария использования
•   Типичные ошибки
•   Сложные вопросы
o   Определение бизнес правил
o   Как связать сценарий использования. Алгоритмы, Бизнес правила и т.д.
o   Визуализация сценария использования
o   Типовые сценарии использования, как минимизировать затраты
o   А у нас Wiki
o   Сценарии использования и Agile проекты
Модуль 2-й, тренинг 2-й. Мастерство работы над нефункциональными требованиями.
Жесткие условия конкуренции требуют не философских рассуждений на тему качества программного обеспечения, а конкретной работы с нефункциональными требованиями, позволяющими их выявить, согласовать, реализовать и валидировать. В нашем  тренинге рассматриваются ключевые техники по работе со сценариями атрибутов качества системы.
Участникам тренинга предоставляются все необходимые шаблоны  и примеры.
Аудитория
Аналитики, Продукт Менеджеры, Архитекторы и Руководители служб тестирования
Основные темы
•   Основные виды нефункциональных требований (ИСО 9126)
•   Атрибуты качества их связь с Архитектурой ПО
•   Методы выявления требований к качеству ПО.
•   Систематизация и управление атрибутами качества (Сценарии реализации атрибутов качества)
•   Рассмотрение примеров сценариев атрибутов качества
o   Готовность,
o   Модифицируемость,
o   Производительность,
o   Безопасность,
o   Контролепригодность,
o   Практичность (юзабилити)

Последняя версия программы с форматированием и т.д. размещена по адресу http://www.system-approach.ru/2010/01/reqd-open/ 


18
Боюсь, до конца месяца (точнее, года) никак не успею. Слишком много необработанного видео накопилось ...

Ну как праздники помогли  ?

19
А есть нарисованная метамодель для данной системы ?

20
Хм я что-то пропустил , или целей сообщества так и не появилось ?

21
Думаю что следует задать главный вопрос:
Для какой цели Вы планируете использовать количественную оценку работы аналитика ?

22
Каким бы простым не казалось  «колесо компетенций»,  каждый переход  из состояния в состояние требует  знаний и навыков, которые связаны не только с Карта неведенияпредметной областью развиваемой компетенции,  но  и  с общей и когнитивной  областями.

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

   1. Осознание на собственном опыте. Оказаться  в ситуации необходимости применения компетенции,  причем таким образом, чтобы мы могли оценить результат.
   2. Осозннание через наблюдение. Наблюдать за применением компетенции другим человеком.

Давайте проанализируем, какие компетенции требуются для этого.
http://www.system-approach.ru/2009/11/ignorance/

23
Наиболее полный список лежит в WiKi
http://en.wikipedia.org/wiki/List_of_UML_tools

Там же есть таблица сравнения

24
Всем привет !
Ок Если  буду в Москве то обязательно  :-)
Если буду в Киеве то вероятнее всего :-)
Но есть еще вариант что в это время буду в поезде :-/

25
В общем случае определяется договорными обязательствами.

Вы могли бы уточнить вопрос ?

26
Исходя из объявленной скидки , есть вероятность что участники класса на UML2 найдутся.

Очень хотелось бы получить объективный отзыв на тренинг ! :D

27
Подскажите, как реализовать следующую схему:
Таблица содержит иерархическую структуру подразделений некой организации. Необходимо реализовать отношение «подразделение» —1—взаимодействует—N— «подразделение», причем возможна ситуация, когда одно подразделение взаимодействует со всеми остальными подразделениями. Взаимодействие начинает свое действие на основании документа, и ограничено периодом, указанным в документе.

Если честно то абсолютно не понял что Вам необходимо реализовать - Диарамму классов, ERD диаграмму,  Организационно оформить, нарисовать UI или что-то еще. ..
Потрудитесь пожалуйста корректно сформулировать вопрос ...

p.s. Интересно как много предложений решений получено, на неполно сформулированную задачу

28
Вебинар то был давно ,

Btw Прикрутил бы что нибудь при автопостинге

29
Могу ошибаться, но что-то подобное мелькало в работах Маклакова. Но я тоже не понимаю зачем нужен SADT, есть более продвинутые методологии и нотации

Когда да то в Открытом Университете MIT я познакомился с лекциями по проектированию (6-8 лет назад). В них утверждается что подход к проектированию сложных систем методом функциональной декомпозиции  сверху вниз себя изжил. 
Ключевая проблема подход сверху вниз  порождает крайне высокую связанность системы, что неизбежно сказывается на возможности стабилизировать и развивать систему. С учетом неизбежности изменений в ходе самого проекта чаще всего масштабные  проекты основанные на SADT просто обречены.

Все необходимое для структурирования решения в ООП на самом деле есть.

Но к сожалению, пояснительная сила, багаж и некомптентность тащат это "барохло" из методологии в методологию ..

p.s. Это не значит что такой подход не применим , это значит что он не применим там где могут быть ИЗМЕНЕНИЯ

30
Ок Судя по всему background отличный, но исходя из того что это бакалавры рассчитывать на наличие необходимого практического опыта который иногда встречается у магистров , я бы сформулировал следующую главную цель курса :
Привить правильное (системное  ;)) понимание контекста ИС, и дать опыт участия в формировании соответствующего Архитектурного описнаия

В курс тогда вошли бы:
1.Введенеие. Стандарт 15288 глубоко (терминология, ЖЦ и т.д.), ITIL и MOF ознакомительно - если они не присутствуют в отдельных курсах
2. Захман framework + TOGAF
3. Курсовая работа групповая разработка  Архитектурного описания по методологии TOGAF  ( В качестве подопытной системы можно использовать ИС ВУЗа :-))

p.s. Если удастся раздобыть и включить в курс ISO/IEC 42010:2007 http://www.iso.org/iso/catalogue_detail.htm?csnumber=45991 Будет вообще замечательно, думаю что на эту тему можно попробовать связаться с Анатолием Левенчуком .

p.s.2 TOGAF Симпатичен лично мне и относительно недавно был обновлен , думаю что здесь выбор не принципиален .
p.s.3 Еще нужно посмотреть что планируется в направлении Архитектуры у магистров и согласовать линию :-)

Страницы: « 1 2 3 4 5 »