Доброго времени суток, дорогие наши подписчики!

Прошедшая неделя была богата событиями:

• Круглый стол "Серебряной пули нет! А что есть?"
• 8-я международная конференция PHPCONF 2009
• Семинар "Разработка требований и Проектирование интерфейсов - как они связаны?"
• Первый семинар по системному анализу в г.Киеве

Аналитики могли выбирать город и событие, которое им хотелось бы посетить. Мы расскажем о двух семинарах этой недели.

Темы нашего выпуска сегодня:

• Книги по управлению требованиями к ПО
• Прошедшие конференции и семинары

1. К. Вигерс, Разработка требований к программному обеспечению
   Эта книга посвящена разработке качественных требований к продукту. Здесь описаны дюжины проверенных на практике способов выявления, формулирования, разработки, проверки, утверждения и тестирования требований к ПО, которые помогут разработчикам ПО, менеджерам и маркетологам создать эффективное ПО. Основная аудитория - аналитики требований и разработчики продукта, а также дизайнеры, программисты, тестеровщики ПО и другие члены команды, задача которых понять и удовлетворить чаяния клиентов, а также маркетологи, менеджеры по продуктам и менеджеры проекта, которые должны проникнуться "духом" и особенностями продукта, чтобы сделать его в полной мере конкурентоспособным. Вы узнаете, как: задавать достижимые требования к функциональности и качеству; включать бизнес-правила в процесс разработки приложения; применять варианты использования для выявления требований пользователей; замедлять увеличение объема требований и управлять запросами на изменения; работать с требованиями при обслуживании продукта, в случае комплексных решений и проектов, выполняемых сторонними организациями; сдерживать желание "позолотить" свои программы; воспитывать профессиональных аналитиков требований; значительно снижать объем доработок и затраты; создавать более качественное программное обеспечение.Неважно, какое ПО вы создаете и какую роль играете в процессе разработки, - в этой книге вы найдете советы экспертов и проверенные "в полевых условиях" методы, которые обеспечат успех вашему будущему продукту.


2. А. Коберн, Современные методы описания функциональных требований к системам
   Практика создания вариантов использования как средств уточнения требований к поведению программных систем и бизнес-процессов быстро завоевывает популярность. Варианты использования обеспечивают эффективное планирование проекта, показывая, как будет применяться будущая система. На первый взгляд идея вариантов использования кажется простой. Однако разработчиков ждет трудная задача: приступая к созданию наборов вариантов использования, необходимо выяснить, насколько точными они должны быть.
   Данная книга эксперта по объектной технологии Алистера Коберна служит новейшим практическим руководством по написанию вариантов использования. Богатый опыт в этой области помогает автору расширить классическое толкование вариантов использования. В книге представлены начальная, промежуточная и расширенная концепция, поэтому она подходит читателям с разным уровнем подготовки. Инструкции подкреплены наглядными примерами и упражнениями.


3. У. Леффингуэлл, Принципы работы с требованиями к программному обеспечению. Унифицированный подход.
   Книга посвящена вопросам формирования требований и работе с ними при разработке сложных систем программного обеспечения. Недостаточное внимание к этому аспекту разработки может привести к превышению расходов, затягиванию сроков выполнения или даже полной неудаче проекта. Авторы предлагают хорошо зарекомендовавшие себя методы выявления, документирования, реализации и тестирования требований, используя для их описания как прецеденты, так и более традиционные методы. Особое внимание уделяется пониманию потребностей пользователей, определению масштаба проекта и обработке изменений. Все этапы иллюстрируются обсуждением полномасштабного рабочего примера. Книга предназначена для всех участников проекта - как членов команды разработчиков, так и пользователей или заказчиков. Ее задача - помочь создать в рамках отведенного времени и бюджета высококачественную систему программного обеспечения, удовлетворяющую реальные потребности клиентов.

1. Серия семинаров от uml2.ru
   В Москве продолжается Серия семинаров от uml2.ru:
8 октября 2009 года Денис Бесков рассказал о процессе разработки требований и его взаимосвязи с процессом проектирования интерфейсов.
Описание
Видеозапись и презентация будут опубликованы в разделе: семинары сайта uml2.ru
Обсуждение на форуме


Отчет о семинаре "Разработка требований и Проектирование интерфейсов - как они связаны?"

Последовательность подачи информации Денисом меня всегда радует: сначала он вводит понятия "требования, типы требований, бизнес-аналитик, системный аналитик", на примерах поясняет, в чем заключается работа этих самых аналитиков, а потом показывает взаимосвязи работ аналитика и проектировщика интерфейсов, а также их место в процессе создания ПО. Таким образом, общий контекст темы выстроен и понятен, особых вопросов не вызывает. Поэтому вопросы задают почему-то про тестирование: а кто формирует требования к тестированию, как из usecase'ов получить testcase'ы и т.д. На этом заканчивается первая часть семинара.


Вторая часть, "Выстраивание работы в области требований в разных ситуациях"; уже не базовая, постоянная, а как раз вариативная, отвечающая на любимый вопрос новичков: "А как правильно?!" А правильно так, как целесообразно/оптимально/эффективно для вашего проекта. Первым делом Денис срывает башню медитативным треугольником ценностей и интересов (великая вещь, очень рекомендую!), дальше добивает своей классификацией проектов - для меня она реально объяснила, почему чаще всего аналитики и проектировщики интерфейсов не встречаются в одном проекте. А дальше, пояснив различия в среде обитания и навыках этих профессий, Денис предложил действия по созданию эффективных коммуникаций, если все-таки эти товарищи встретятся на одном поле, в одном проекте. Дальше шли примеры для команд разных размеров и дискуссия зала с Дмитрием Безуглым: кто такой маркетолог и зачем он нужен (так же как и вопросы по тестированию, дискуссия возникла спонтанно после просмотра треугольника и была прекращена в связи с недостатком времени). Так как семинар проходил в рамках встречи проектировщиков интерфейса, которые в основном работают в проектах без выделенного аналитика, Денис предложил свое видение вариантов ролей, которые могут заменить аналитика на проекте. И последний слайд "Какой объем требований нужен?" описал варианты степени полноты требований в зависимости от рисков и бюджета проекта. Таким образом, уровень детализации требований и набор аналитических документов необходимо подбирать в зависимости от типа, рисков и бюджета проекта, а также размеров и ролевого состава проектной команды.


На мой взгляд, тема изложена полно и добротно, а с учетом того, что через 2 дня после этого семинара в Киеве затрагивалась тема прототипирования, как инструмента аналитика, похоже, что тема проектирования GUI становится все более популярной и востребованной.

Автор: Ирина Сурова


2. Первый семинар по системному анализу в г.Киеве
   Описание
   Видеозапись и презентации будут опубликованы в разделе: семинары сайта uml2.ru
   Обсуждение на форуме
   Отчет о семинаре на сайте uml2.ru (смотрите ниже сокращенную версию)
   Еще один отчет о семинаре
   

   Отчет о Первом семинаре по системному анализу в г.Киеве

   10 октября 2009 года в УЦ "Люкософт-Украина" проходил Первый семинар по системному анализу в г.Киеве, организованный Сообществом системных аналитиков.
   Семинар объединил несколько тем, касающихся работы аналитика:
   
   • Прототипирование
   • Выявление и документирование требований
   • Проблемы выявления и анализа требований и их решение
   В качестве приветствия Вячеслав Панкратов показал ролик об управлении проектами "Кордебалет". Казалось бы, детский мультфильм, а как точно иллюстрирует распределение ролей внутри IT-команды.
   
   Ирина Крючкова рассказала об инструменте Аналитика - проектировании пользовательских интерфейсов. В докладе были рассмотрены виды прототипов, преимущества и недостатки прототипирования, инструментарий для прототипирования пользовательских интерфейсов.
   
   Прототипы пользовательских интерфейсов можно использовать для изучения доступного и подходящего проекта пользовательского интерфейса, который удовлетворяет требованиям, что помогает устранить разницу между тем, что требуется (выражено посредством выявления требований), и тем, что осуществимо. Основным назначением создания прототипа пользовательского интерфейса является возможность "тестирования" проекта пользовательского интерфейса, включая удобство работы, до начала фактической разработки. Таким образом, можно убедиться, что будет создана правильная система, до того, как будет затрачено слишком много средств и ресурсов на разработку. В то же время прототип может стать хорошим инструментом для согласования и даже выявления требований.
   
   По мнению Ирины условиями успеха прототипирования являются:
   
   • Прототип должен быть похож на будущую систему.
   • Прототипирование должно быть значительно дешевле разработки конечного продукта.
   • Пользователи, с которыми будет обсуждаться прототип, должны быть заинтересованы в системе/обсуждении/прототипе.
   • Прототип не должен быть очень громоздким.
   • Создавать прототип стоит не совсем "с нуля", не имея четкого представления о будущей системе.
   
   Дмитрий Мороз затронул вопросы выявления и документирования требований. Цель выступления Дмитрия - снабдить минимально необходимым набором теоретических знаний и показать, как применить на практике положения теории. В докладе были рассмотрены типы и зоны ответственности аналитиков в IT-проектах, типы и взаимосвязь требований, даны рекомендации по выявлению и управлению требованиями:
   
   1. Что понимается под бизнес аналитиком. Какие типы аналитиков бывают в IT и что они делают?
   2. Зачем вообще нужен БА на проекте? Как начинается проект: причины и цели.
   3. Какие типы требований бывают?
   4. Написать требования - полбеды. Но как их получить и осмыслить.
   5. Как добиться идеальных требований, какие они?
   6. Какие требования бывают скрыты и как их определить?
   7. Основные ошибки бизнес-анализа и как их избежать?
   
   Александр Байкин провел круглый стол посвященный проблемам выявления и анализа требований и их решению. Участникам круглого стола были предложены следующие проблемы:
   • Пропасть между Аналитиком и Заказчиком
   • "Да, но..." синдром
   • Заказчик не знает что хочет
   • Нет доступа к Заказчику
   • Заказчики противоречат
   • Нет Заказчика
   • Нет Документации
   • Требования постоянно меняются
   • Необнаруженные Требования
   • Распределенная команда
   • Заказчику ничего не надо
   • Руководство гонит
   Иногда бывает невозможно увлекательно пересказать фильм - его нужно посмотреть. Так и круглый стол Александра Байкина. Все пришедшие на семинар, активно предлагали решения проблем, спорили, приводили примеры. Надо отметить, что Александр предлагал и свои способы решения проблем выявления и анализа требований. И каждый раз казалось, что это решение естественно в данной ситуации, но почемуто никому не приходило в голову озвучить его во время обсуждения проблемы.
   
   Хочется поблагодарить организаторов семинара: Ирину Крючкову и Елену Голубенко за интересный семинар, Вячеслава Панкратова - за предоставленное помещение, Григория Печёнкина - за видеосъемку, докладчиков - за поднятые темы и вопросы, которые дали возможность узнать что-то новое, заставили задуматься о некоторых аспектах работы аналитика.
   
   Автор: Ирина Векленко