Ира,
Ты с Димой контактировала?
Канешна!
Собственно, предварительно получается нечто подобное:
10:00 – 10:15 Открытие встречи
10:15 – 12:15 Разработка и документирование требований
Докладчик:
Дмитрий Мороз
Бизнес Аналитик, EPAM Systems (Киев)
работал на финансовых проектах аналитиком (Ренесанс кэпитал, Хадсон, Блумберг), сэйлс консультантом на Оракл, биржах, Лондонский Офис-Шэдоу
План:
1. Что понимается под бизнес аналитиком. Какие типы аналитиков бывают в ай-ти и что они делают
2. Зачем вообще нужен БА на проекте. Как начинается проект: причины и цели
3. Какие типы требований бывают
4. Написать требования – полбеды. Но как их получить и осмыслить
5. Как добиться идеальных требований, какие они?
6. Какие требования бывают скрыты и как их определить
7. Основные ошибки бизнес анализа и как их избежать
12:15 – 12:30 Перерыв на кофе
12:30 – 13:30 Проектирование пользовательских интерфейсов, как инструмент Аналитика
Докладчик:
Ирина Крючкова
Аналитик, Softline (Киев)
Профиль:
http://kryuchkova-i4.moikrug.ru/Описание:
Прототипирование интерфейсов, которое плотно вошло в жизнь разработчиков веб-сайтов, забыто, и, возможно, незаслуженно, в процессе разработки функциональных приложений. Вполне объяснимо внимание к прототипированию в случае, когда внешний вид, а именно, пользовательский интерфейс – один из основных вопросов (как в случае с сайтами), однако (хоть это и не так очевидно) в случаях, когда приоритет отдается функциональности, а внешний вид отходит на второй план, прототипирование также может сослужить хорошую службу. А именно, в момент обсуждения/согласования будущей функциональности приложения, часто одна наглядная картинка может стоить многих слов описания возможностей системы.
13:30 – 14:30 Перерыв на обед
14:30 – 15:30 Проблемы выявления и анализа требований и их решение. Круглый стол.
Докладчик:
Александр Байкин
Ведущий аналитик, Автомир (Москва)
Один из создателей и идеологов ресурса
www.uml2.ruПрофиль:
http://baikin.moikrug.ru/Описание:
На протяжении многих лет написано огромное количество книг и статей по методам Выявления Требований и их применению, но все хорошо в теории. На практике же Аналитики, раз за разом, натыкаются на одни и те же грабли: не выявлены все требования; заказчик не знает, что хочет; "да, но +" синдром и т.д. На данном круглом столе мы обсудим основные проблемы, с которыми сталкиваются Аналитики на этапе Выявления Требований и попытаемся найти пути их решения.
План:
1. Немного о работе с Требованиями
2. Основные техники Выявления и Анализа Требований
3. Обсуждение основных проблемы Аналитика
4. Поиск решений проблем Выявления и Анализа Требований
15:30 – 15:45 Перерыв на кофе
15:45 – 17:15 Тестирование требований
Докладчик:
Игорь Лужанский
Руководитель проектов Deutche Bank, Luxoft Украина
Описание:
На производстве одна из функций отдела контроля качества – это входной контроль, который гарантирует качество поступающего в производство сырья. Такой подход гарантирует более высокое качество конечного продукта выпускаемого производственной линией. Аналогично в производстве ПО необходимо проверять качество требований («сырья») для того что бы создавать качественный продукт, удовлетворяющий потребностям заказчика. Тестировать требования важно, поскольку приложение, созданное на основе некачественных требований, будет однозначно некачественным, несмотря на качественный код, стройную архитектуры и отсутствие дефект.
План:
В этом докладе будет подробно освещена тема тестирования требований. В докладе будут даны ответы на такие вопросы:
1. Кем и когда должно выполняться тестирование требований?
2. Каковы критерии качественного требования?
3. Какие существуют техники и инструменты для тестирования требований?
А так же проиллюстрированы практические примеры качественных и некачественных требований, а так же и методы тестирования требований.
17:15 – 17:30 Заключительная часть
Замечания/возражения?
Открытым остается вопрос с докладом kidman (нужно определиться с темой, временем и тогда спланировать, куда его поместить)
Кроме того, я познакомилась еще с одним мегаопытным аналитиком, который тоже готов поделиться знаниями, но уже совсем не влазит в регламент.
В связи с чем у меня есть несколько альтернативных предложений:
1. Я могу уступить место выступающего (тем более, что на фоне других докладов, моя тема не кажется слишком важной)
2. Может быть мы попытаемся превратить наш семинар в двухдневный?
3. Как уже говорилось выше, можно начать планировать следующую встречу