Прототипирование

Прототипирование - ключевая стратегия выявления требований в большинстве современных методологий (подробнее см. в лекции 10). Программный прототип - "зеркало", в котором видно отражение того, как понял Исполнитель требования Заказчика. Процесс выявления требований путем прототипирования тем более интенсивен, чем это зеркало кривее. Документальный способ выявления требований всегда уступает живому общению. Анализ того, что сделано в виде интерфейсов пользователя дает еще больший эффект. Подключается правополушарный канал восприятия, который, как известно, работает у большинства людей на порядок эффективнее, чем вербальный.

Метод RAD - один из наиболее известных способов быстро создавать прототипы¹⁾.

RAD базируется на следующих базовых принципах:

• Эволюционное прототипирование;

• CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода;

• Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами;

• Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online;

• Жесткие временные рамки, как противоядие от "расползания границ" проекта: если команда не укладывается в срок - функционал сужается.

1.10Формирование видения

1.10.1Видение продукта и границы проекта

Работы по формированию видения продукта и границ проекта обычно начинаются на самой ранней фазе проекта, до начала широкомасштабных консультаций по выявлению подробных требований, хотя в целом наличие и последовательность данных шагов зависит от выбранной методологии. На практике данные работы зачастую совмещаются. Правила извлечения требований, рассмотренные в лекции 6, могут быть использованы и при формировании видения.

Анализируя литературу по рассматриваемой тематике, можно выделить следующие широко употребимые ключевые слова: с одной стороны - концепция, видение, образ, с другой - рамки, границы, контекст.

В первом случае речь идет о видении того, какой должна быть система. Обсуждаются высокоуровневые требования (возможности, свойства) продукта и наиболее существенные ограничения. Ряд авторов, напротив, настаивает на том, что видение должно быть "ничем не ограниченным".

Понятие видения широко употребимо в бизнес-анализе. Если у топ-менежмента компании имеется представление о том, какие ключевые цели, сегменты рынка, товарные позиции, прибыль должны быть достигнуты, допустим, через 5 лет - значит, компания имеет долгосрочное видение себя на рынке. Способ снятия ограничений при выработке видения позволяет выработать новый взгляд на вещи, "подняться над ситуацией", планировать будущее, отталкиваясь не от текущих ресурсов и ограничений, а от стратегических целей, применяя инновации, ноу-хау и т.п.

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

Во втором случае (рамки, границы, контекст) обсуждаются такие вопросы, как граница системы и среды, требуемые ресурсы на создание системы, сроки. Построив "ничем не ограниченное видение", рано или поздно приходится вернуться к таким прозаическим вещам, как бюджет, календарное планирование, подбор персонала, вехи проекта.

Всегда ли нужно создавать документ "Концепция"? Следует ли разделять видение и границы?

Зачастую Заказчик осознает необходимость автоматизации, как способ решения накопившихся проблем. Сформулировав для себя проблему, Заказчик часто видит и вариант ее решения, с которым приходит к Исполнителю ("мне нужен сайт", "требуется CRM-система" и т.п.). Квалифицированный Исполнитель не должен, сломя голову, спешить решать задачу в формулировке Заказчика. По образному выражению Г.Калянова¹⁾ автоматизировать процессы "как есть" - все равно, что асфальтировать дорожки, по которым ходят коровы.

В нотации RUP присутствует важная метафора: "Увидеть проблему за проблемой". Концепция как раз и служит для того, чтобы помочь Заказчику выявить именно те требования к системе, которые помогут ему оптимизировать работу своего предприятия в долгосрочной перспективе.

Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику и к Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями, чтобы разрабатываемое средство автоматизации действительно принесло пользу. Все вышесказанное ничуть не исключает возможность работы без концепции: либо речь идет о небольшом проекте, закладывать в бюджет которого этап выработки концепции просто нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы сформулировать требования к АИС, имея "концепцию в голове" и время для консультирования Разработчика.

Некоторые аргументы за разделение видения и границ были приведены выше. Провести четкую границу между этими понятиями предлагает, в частности, процесс MSF. В конечном итоге, вопрос "разделять или не разделять" определяется выбранной методологией.

Рассмотрим основные требования к выработке концепции, заложенные в отечественных ГОСТ, методологиях RUP и MSF.