В теме 11 ответов, и 5 участников, последнее обновление сделано пользователем 
Denis Syropushchinsky 13 г назад.
-
Сообщения
-
Готовлю обзорный семинар по основам анализа. Основная аудитория — тестировщики и начинающие аналитики.
Перерыл материалы форума, книги и другие имеющиеся материалы и сделал первую болванку со следующей структурой:
1. ВВЕДЕНИЕ
1.1 ЦЕЛЬ ДОКУМЕНТА
1.2 ЦЕЛЕВАЯ АУДИТОРИЯ
1.3 ГЛОССАРИЙ
1.4 ИСТОРИЯ ИЗМЕНЕНИЙ
2. ОБЩИЕ ВОПРОСЫ ПО РАБОТЕ С ТРЕБОВАНИЯМИ
2.1 КЛАССИФИКАЦИЯ ТРЕБОВАНИЙ
2.2 ПРОЦЕСС РАЗРАБОТКИ И УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ
Разработка требований (Requirements Development)
Управление требованиями (Requirements Management)
2.3 ХАРАКТЕРИСТИКИ ТРЕБОВАНИЙ
Характеристики отдельных положений спецификации требований
Характеристики спецификации требований
2.4 ОСНОВНЫЕ ОШИБКИ ПРИ РАЗРАБОТКЕ ТРЕБОВАНИЙ
3. АНАЛИТИКИ
3.1 ВИДЫ АНАЛИТИКОВ
3.2 АНАЛИТИКИ В ПРОДУКТОВЫХ КОМПАНИЯХ
3.3 ФУНКЦИИ И ОБЯЗАННОСТИ АНАЛИТИКА (СВОД АКТИВНОСТЕЙ)
3.4 КАЧЕСТВА/НАВЫКИ/ЗНАНИЯ, НЕОБХОДИМЫЕ АНАЛИТИКАМ
3.5 ВИДЫ ДОКУМЕНТАЦИИ, РАЗРАБАТЫВАЕМОЙ АНАЛИТИКАМИ
4. РАБОТА АНАЛИТИКА НА ПРОЕКТЕ
4.1 ЦИКЛ УЧАСТИЯ АНАЛИТИКА В ПРОЕКТЕ
4.2 СТАРТ АНАЛИТИКИ
4.3 ПОСЛЕДОВАТЕЛЬНОСТЬ СБОРА ВЫСОКОУРОВНЕВЫХ ТРЕБОВАНИЙ
4.4 ВАЛИДАЦИЯ ДОКУМЕНТОВ
4.5 ПРОВЕРКА ПОЛНОТЫ ПОКРЫТИЯ ПРОЕКТА
4.6 РЕКОМЕНДАЦИИ АНАЛИТИКУ
Общение с заказчиком
Взвешенный подход к вопросам
5. ТЕОРИЯ, ИНСТРУМЕНТАРИЙ И ССЫЛКИ
5.1 ПРИКЛАДНОЕ ПО АНАЛИТИКА
5.2 ОБЯЗАТЕЛЬНАЯ ТЕОРИЯ
5.3 ПОЛЕЗНЫЕ ССЫЛКИ
5.4 ШАБЛОНЫ
6. ПРИЛОЖЕНИЯ
6.1 ПРИМЕР СТРУКТУРЫ ДОКУМЕНТА VISION
6.2 ПРИМЕР СТРУКТУРЫ ДОКУМЕНТА SRS (ПО ВИГЕРСУ)Возможно у кого-нибудь будут идеи и предложения, что ещё можно включить в список?
В связи с вопросами хочу отметить, что семинар пока что планируется сугубо внутри компании.
Для публикации его материалы надо шлифовать и обсуждать, пока что не понятно, надо ли это, и соответственно будет ли это делаться.Привет,На мой взгляд в целом все отлично. Я бы немного другую структуру тем и порядок выбрал, но это скорее зависит от специфики работы аналитика в каждой компании.
Что можно добавить (просто список, без структуризации):- Основы разработки ПО в целом (типы проектов, процессов, участники)
- Requirements Management Systems
- Use Cases — моделирование и описание
- Визуализация требований (UML, BPMN; инструментарий)
- Прототипирование (статические и динамические прототипы; инструментарий).Привет!
Рекомендую добавить материал по концептуальному моделированию данных, и бизнес-процессов. Также рекомендую привести кейсы на решение практических задач, таких как: конкурентные требования, борьба со scope creep, и т.д.Разумная подборка — я бы приблизительно это и включила при подготовке аналогичного семинара.
Единственное: я бы начала с жизненного цикла проекта вкратце и места аналитика в нем (активности аналитика на разных стадиях). Хотя может это лично мое восприятие мира — люблю все систематизировать и двигаться от общего к частному, чтобы знать "откуда ноги растут".Как я понимаю, задача семинара — ввести в курс дела, чтобы они знали в какую сторону саморазвиваться, т.к. начинающих аналитиков и тестировщиков в качестве аналитиков все равно никто в одиночку в проект не поставит. Поэтому сильный упор на практику я бы не делала (все равно под боком будет опытный коллега). Но если время будет позволять можно потренироваться в выдуманном проекте, где ведущий семинара — заказчик, а участники семинара должны собрать от него требования, обработать, показать как они умеют управлять ими, возможно что-то задокументировать в виде юзкейсов и диаграмм, продумать модули системы, возможно нарисовать макеты и т.д. (мне самой лет 5 назад, когда я только начинала опытный коллега делал такое — было интересно и полезно).
PS мне кажется, если все это рассказывать даже в общих чертах, "не копая вглубь" семинар на неделю получится (без еды, воды и сна)
У меня 2 группы — одна начинающие, им будут даваться азы без копания вглубь. Семинар будут построен на основе презентации с выборкой самого важного. Для Follow-up готовиться отдельный большой документ, систематизирующий теорию.Вторая группа — тестировщики senior уровня, многие из которых работали в том числе аналитиками. Им теория будет даваться выборочно, основной упор — обсуждение актуальных вопросов и проблем, которые заранее собраны.
За 1,5-2 часа будем стараться уложиться.
Привет!
Рекомендую добавить материал по концептуальному моделированию данных, и бизнес-процессов.Сомневаюсь в необходимости. Скорее нужна общая информация, что это одна из задач аналитика, и список языков и нотаций, которые могут потребоваться аналитику.
У нас есть отдельный семинар по UML на основе всем известного примера с банкоматомТакже рекомендую привести кейсы на решение практических задач, таких как: конкурентные требования, борьба со scope creep, и т.д.
Да, вполне можно. Отдельным разделом — Проблемы при работе с заказчиком.
Но если время будет позволять можно потренироваться в выдуманном проекте, где ведущий семинара — заказчик, а участники семинара должны собрать от него требования, обработать, показать как они умеют управлять ими, возможно что-то задокументировать в виде юзкейсов и диаграмм, продумать модули системы, возможно нарисовать макеты и т.д. (мне самой лет 5 назад, когда я только начинала опытный коллега делал такое — было интересно и полезно).
Делали отдельный семинар когда-то, было интересно. Наработки есть.
типы проектов, процессов
Можешь пояснить, что именно ты имел в виду?
Да ничего сверхъестественного
Типы проектов: outsourcing/product development
Процессы: водопад, спираль, RUP, agile (скрам, XP) и т.д.Вот кстати что-что, а Основы разработки ПО в целом (типы проектов, процессов, участники) я бы добавила обязательно. Считаю большим упущением, что этого не рассказывают в ВУЗах, не учат студентов работе в коллективе (хотя все возможности для этого есть).А что подразумевается под разделом 4.6 РЕКОМЕНДАЦИИ АНАЛИТИКУ? Если планируется, что он будет состоять только из подразделов "Общение с заказчиком" и "Взвешенный подход к вопросам", по-моему, можно вполне добавить еще несколько таких подразделов с рекомендациями, например, "Основы деловой переписки", "Основы юзабилити" (да-да, я считаю, что каждый уважающий себя аналитик должен представлять, что это такое) и т.п.
Gerych
Ага, понятно.
В типы ещё добавлю FP/TM.Belle Morte
В этот раздел закинуты рекомендации, составленные когда-то на основе опыта. Чтобы не потерять.Аналитик (да и любой специалист в целом) должен знать много "поддерживающих" дисциплин. Но их основы — не часть семинара по основам анализа.
p.s. слабо представляю себе "основы юзабилити" Вот здесь действительно тема необъятная.
Вы должны авторизироваться для ответа в этой теме.
