Самостоятельное описание требований
Документы - хороший источник информации, потому что они чаще всего доступны и их можно "опрашивать" в удобном для себя темпе. Чтение документов - прекрасный способ получить первоначальное представление о системе и сформулировать вопросы к экспертам.
Если опытный аналитик уже исследовал большое число систем такого же типа, что и на предприятии внедрения, он обладает фундаментальными знаниями в соответствующей предметной области, относительно определенного класса систем. Авторы методологии SADT рекомендуют проводить самоопрос с тем, чтобы получить максимальную пользу от своих знаний.
По результатам анализа документов и собственных знаний аналитик может составить описание требований и предложить его представителям Заказчика в качестве информации к размышлению, либо - основы для формирования технического задания.
Недостаток этой стратегии - опасность пропуска знаний, специфичных для объекта исследования (в случае самоопроса), либо - неформализованных знаний, эмпирических правил и процедур, широко используемых на практике, но не вошедших в документы.
Совместные семинары
Помимо классического интервью "тет а тет", существует значительное количество методик, предполагающих широкое участие представителей Заказчика и Исполнителя.
Правила мозгового штурма предполагают полную раскрепощенность и свободу мнений, даже самых вычурных и на первый взгляд "бредовых". Первое правило мозгового штурма - "полный запрет на любую критику". Всякое высказанное мнение представляет ценность, а полное отсутствие запретов позволяет полноценным образом подключить творческую фантазию.
|
|
|
Затем, на втором этапе, все высказанные мнения тщательным образом обсуждаются, заведомо неприемлемые варианты отсеиваются, формируются коллективные предложения.
Правила JAD-метода, считающегося одним из современных способов извлечения требований, были впервые сформулированы в конце 1970-х годов компанией IBM. Участники JAD-совещания:
Ведущий - специалист в области межличностных коммуникаций. Должен ориентироваться в предметной области, но не обязательно хорошо ориентироваться в проблемах IT.
Секретарь - стенографист встречи. Фиксирует ее результаты на компьютере. Возможно применение CASE-средств.
Заказчики - пользователи или руководители, основные участники, формирующие, обсуждающие требования и принимающие решения.
Разработчики - аналитики и другие участники проектной команды. Работают в большей части в пассивном режиме с целью наилучшего понимания проблемной области.
JAD (Joint Application Development or Design) - cовместная разработка (или проектирование) приложений. Согласно PMBOK, JAD – это семинар с участием модератора, использующийся в области разработки программного обеспечения. Метод направлен на предоставление пользователям возможности встретиться с командой разработчиков для улучшения процесса разработки программного продукта. Основная задача модератора – организовать поток информации от заказчика к клиенту, направленный на выявление требовании к программному обеспечению. Роль разработчика в процессе совещания в основном сводится к пассивному слушанию с целью наилучшего понимания проблемной области.
|
|
|
Совместные семинары, сохраняя все преимущества режима интервью, привносят дополнительные бонусы: работа в группе более продуктивна, группы быстрее обучаются, более склонны к квалифицированным заключениям, позволяют исключить многие ошибки.
Эта стратегия, очевидно, одна из самых затратных, однако она окупается за счет меньшего количества ошибок и отказе от формализации в пользу живого общения, выработке общего языка и пр. Некоторые методологии (например, XP) зиждутся на постоянном тесном контакте между Заказчиком и Исполнителем и, если такой возможности нет - XP-проект просто не сможет состояться.
|
|
|
"Разъясняющие встречи" [6.3] или "запланированный мозговой штурм" - термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков и т.п.
Как и проведение интервью, организация семинара требует соблюдения правил, с которыми можно познакомиться в [6.2,6.4].
Прототипирование
Прототипирование - ключевая стратегия выявления требований в большинстве современных методологий (подробнее см. в "Расширенный анализ требований. Иллюстрированные сценарии и прототипы" ). Программный прототип - "зеркало", в котором видно отражение того, как понял Исполнитель требования Заказчика. Процесс выявления требований путем прототипирования тем более интенсивен, чем это зеркало кривее. Документальный способ выявления требований всегда уступает живому общению. Анализ того, что сделано в виде интерфейсов пользователя дает еще больший эффект. Подключается правополушарный канал восприятия, который, как известно, работает у большинства людей на порядок эффективнее, чем вербальный.
Метод RAD - один из наиболее известных способов быстро создавать прототипы 4.
|
|
|
RAD базируется на следующих базовых принципах:
RAD (Rapid Application Development) – быстрая разработка приложений. Согласно словарю IT-терминологии Гарднер, http://blogs.gartner.com/it-glossary, RAD – это подход, ориентированный на небольшие группы (обычно двух до шести человек, но не более чем 10), позволяющий, на основе использования метода JAD и технологии итеративного прототипирования, строить интерактивные системы низкой и средней сложности в сроки от 60 до 120 дней.
· Эволюционное прототипирование;
· CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода;
· Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами;
· Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online;
· Жесткие временные рамки, как противоядие от "расползания границ" проекта: если команда не укладывается в срок - функционал сужается.
Дата добавления: 2021-03-18; просмотров: 113; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!