Процесс разработки и управления требованиями

В зале «Ярославль» в 12:45 (длительность 20 минут)
Доклад о том, почему качественный процесс разработки требований критически важен для успеха проекта и о том, что собой представляет этот процесс, какие уровни требований существуют и как их структурировать.
Совершенствование web-технологий и усложнение задач, решаемых с помощью инструментов среды web, привело к усложнению проектов, которые приходят на разработку. С каждым днем доля сложных информационных web-систем растет в общем количестве сайтов.
Для сложных проектов характерна сложность процессов предметной области и информации, описывающей эти процессы. Требования к таким проектам выражаются огромным потоком неструктурированной информации. Разработчики начинают сталкиваться с недостатком ресурсов и методик для обработки таких требований, для документирования и выстраивания логичной концепции будущего продукта.
На данный момент оформилась необходимость в ходе разработки некоторых сложных web-систем использовать формализованные методы описания и анализа предметной области, методы описания и управления требованиями. Мой доклад о том, как выглядит общий процесс разработки требований для комплексных информационных систем общего пользования, о том, как структурировать информацию в ходе предпроектного анализа и о том, почему разработка требований к системе критически важна для успеха проекта.

Автор

Александр Зверев
ITECH.group (Ульяновск)

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

Комментарии (9)

Николай Никульников:
Хотелось бы понять более подробно о чем будет доклад. Если можно ссылки на методики было бы замечательно!
Ведь по идее веб-разработка является частным случаем просто разработки ПО.
А разработка ПО вещь уже достаточно старая и имеет свои решения по многим вопросам.
Татьяна Храмова:
Александр, очень много сложных и длинных предложений написано. Не видно сути.
Александр Зверев:
Приветствую, Николай и Татьяна. Дело в том, что недавно я столкнулся с ситуацией, когда на разработку в нашу веб-студию пришел сложный и высокотехнологичный проект, таких еще не было. Требований к проекту было множество, поэтому возникли сложности именно в методологии сбора данных и их структурирования. Я задался целью и изучил общую методологию сбора и управления требованиями. Заявил доклад для того, чтобы поделиться с ТЕМИ собратьями проектировщиками, КОТОРЫЕ ИСПЫТЫВАЮТ ПОДОБНЫЕ ТРУДНОСТИ И КОТОРЫМ НЕ ХВАТАЕТ ТЕОРИИ. Убежден, что использовать общую методологию следует только в крайней степени, когда проекты действительно представляют информационные системы. То есть доклад об общем процессе сбора требований к ПО (по книгам Вигерса, Халл и иже с ними). Надеюсь, ответил на ваш вопрос.
Татьяна Храмова:
Александр, спасибо за ответ. Обязательно буду на Вашем докладе.
Денис Бесков:
Ура, редкая для веба тема! )

Александр, будет описана адаптация процесса под веб-специфику - малые сроки и бюджеты, совмещение ролей, неэффективность документов?

2-й и 3-й абзац про корабли, бороздящие просторы Большого Театра я бы убрал )

Лучше в начале озвучить проблемы — «Заказчик не доволен результатом? Приходится много переделывать? (и т.д.) Научитесь работать с требованиями!»
Денис Бесков:
@Николай Никульников: В книге Карла Вигерса помимо процесса (про который собирается рассказывать Александр) можно найти несколько десятков методик работы с требованиями - методик выявления, анализа, документирования, согласования и управления изменениями. Изложить их в форме одного доклада нереально (у Вигерса 600 страниц).
Александр Зверев:
Спасибо за рекомендации, Денис, подумаю над ними и применю. По поводу самого процесса: да, действительно, у Вигерса (да и не только у него) про требования написано достаточно много. Я об этом тоже намереваюсь сказать, что я при всем желании не упакую всю информацию в один доклад. Возможно, я буду делать цикл докладов на эту тему. Каждый будет посвящен своему аспекту: документирование, по докладу на каждый из уровней требований, case-средства для фиксации требований и т. д.

По поводу малых сроков и бюджета. По-моему, использовать процесс разработки требований в том виде, в котором я буду его представлять, стоит только для крупных проектов, больших и сложных информационных систем для общего пользования со сложной интеграцией с другими системами. Такие проекты, как правило, имеют немалый бюджет и адекватные сроки (иначе нет смысла браться за подобные проекты, они будут нерентабельны для разработчика).
Евгений Савицкий:
Александр, не смогу присутствовать на Вашем докладе, но хочу порекомендовать инструмент по управлению требованиями для небольших и средних по размеру команд: http://pm.devprom.ru

Надеюсь он послужит для Вас хорошей площадкой для управления требованиями в Ваших проектах.
Дмитрий Зимин:
Александр, свяжитесь, пожалуйста, со мной: i@dzimin.ru Хочу обсудить порядок докладов, так как наши темы друг друга дополняют и пересекаются.

Организаторы фестиваля

Студия Доминион
Студия Турбомилк

Генеральный спонсор

Microsoft
Генеральный спонсор

Спонсоры

NetCat
Спонсор
1c-bitrix
Спонсор
Авис дизайн
Спонсор
Формикс
Спонсор

Партнеры

Red bull
Партнер
У Палыча
Партнер
iBag
Партнер
Метромакс
Провайдер
Холидэй Инн
Партнер

Информационные партнеры

ХабраХабр
Генеральный информационный партнер
Проект «Zi. Интернет-коэффициент»
Информационный партнер
CMS magazine
Информационный партнер
ruformator
Информационный партнер
ТРК Терра
Информационный партнер
Портал «samara24.ru»
Информационный партнер
Журнал «Город»
Информационный партнер
Телерадиокомпания «СКАТ»
Информационный партнер
BTL Состав
Информационный партнер
marketingpeople
Информационный партнер
Вход через популярные сервисы
Вход через Open ID
Вход через аккаунт на 404fest.ru
(Напомнить пароль)