Учебное пособие ТОАУ Ч.3 (Учебное пособие по ТАУ), страница 3

Рис. 3.

Поток работ "деловое моделирование" служит основой для анализа и формирования требований к АИС, позволяет избежать ошибок.

Поток работ "управление средой" предоставляет исходную информацию для рабочей группы АТ, регламентирующую форматы оформления, CASE-средства, регламенты работы.

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

Поток работ "анализ и проектирование" осуществляется на основе исходных данных, предоставленных АТ. В определенной мере эти потоки работ проводятся параллельно. При обнаружении проблем, связанных с требованиями, возникает обратная связь от этого потока работ к потоку работ АТ.

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

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

Выявление требований

Источники требований

Основным источником требований к информационной системе, безусловно, являются соображения, высказанные представителями Заказчика. В соответствии с иерархической моделью требований данная информация структурируется как минимум на 2 уровня: бизнес-требования и требования пользователей.

Другим важным источником информации, помимо выявления требований, являются артефакты, описывающие предметную область. Это могут быть документы с описанием бизнес-процессов предприятия, выполненные консалтинговым агентством, либо просто документы (должностные инструкции, распоряжения, своды бизнес-правил), принятые на предприятии. Одной из немногих методологий, в которой специально выделяется рабочий поток делового моделирования, является Rational Unified Process.

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

Стратегии выявления требований

Интервью. Ключевой стратегией выявления требований было и остается интервью с экспертами.

В ставшей уже классической, но ничуть не утерявшей актуальность монографии Д.Марко [6.1] в процессе проведения интервью предлагается выделить три подчиненных процесса: подготовку, проведение интервью (опроса) и завершение. Ниже приводится краткий обзор рекомендаций Д.Марко с акцентом на выявление требований (в монографии даны рекомендации по интервьюированию с целью формирования модели объекта исследования).

1. Подготовка

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

Шаги при подготовке интервью:

• выберите нужного собеседника;

• договоритесь о встрече;

• установите предварительную программу встречи;

• изучите сопутствующую информацию;

• согласуйте свои действия с группой проектирования .

При выборе собеседника для целей сбора требований определяющими являются две вещи:

Он действительно является экспертом по данному вопросу;

Его мнение действительно является ценным при формировании целевого набора требований .

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

Полезными приемами являются формирование программы беседы и ознакомление с ней респондента, подробное планирование беседы вплоть до записи подготовленных вопросов. Подготовленное таким образом интервью называют структурированным [6.2]. В дополнение к так построенному интервью автор [6.2] предлагает проводить неструктурированное интервью, "представляющее собой неформальную встречу, которой не свойственны заготовленные впрок вопросы или заранее поставленные цели". Цель такого интервью - пробудить респондента к креативу в области, в которой интервьюер недостаточно хорошо ориентируется.

2. Проведение опроса

Ниже приведена цитата из [6.1], с некоторыми сокращениями и исключением материала, не относящегося к АТ.

В проведении опроса самое важное - правильно организовать и поддерживать поток информации от эксперта к вам. Рекомендуется потратить время на обдумывание верного начала опроса, при сборе информации по возможности использовать записи, заканчивать разговор плавно. Обсудим подробнее каждый из этих пунктов.

Начиная разговор, не забудьте представиться и сформулировать цель встречи. Это поможет избежать недоразумений и даст беседе правильное направление. Кроме того, обговорите возможность ведения записей.

Затем сформулируйте первый вопрос. Помните, что первый вопрос часто задает тон всему разговору, поэтому хорошо продумайте его.

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

Прежде всего, не возражайте.

Никогда не задавайте наводящих вопросов или вопросов с короткими ответами "да" или "нет". Вместо этого записывайте то, что вам говорят, и просите подвести итог или дать пояснения.

Вы получите от опроса больше, если вы дадите эксперту возможность говорить то, что он хочет сказать, а не то, что вы хотите услышать.

3. Завершение

Следите за возникновением следующих ситуаций [6.1]:

• вы уже получили достаточно информации;

• вы получаете большой объем неподходящей информации;

• обилие информации вас подавляет;

• эксперт начинает уставать;

• у вас с экспертом часто возникают конфликты.

Любая из этих причин - достаточное основание для завершения беседы.

Анкетирование. Анкетирование - самый малозатратный для аналитика способ извлечения информации, он же - и наименее эффективный. Обычно применяется как дополнение к другим стратегиям выявления требований.

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

Наблюдение. Наблюдение за работой моделируемой организационной системы - полезная стратегия получения информации (хотя, строго говоря, по результатам наблюдения можно получить модель ОС, а не модель АТ).

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

Через наблюдение, а возможно, и участие аналитики получают информацию о происходящих день за днем операциях из первых рук. Во время наблюдения за работой системы часто возникают вопросы, которые никогда бы не появились, если бы аналитик только читал документы или разговаривал с экспертами.

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

Самостоятельное описание требований. Документы - хороший источник информации, потому что они чаще всего доступны и их можно "опрашивать" в удобном для себя темпе. Чтение документов - прекрасный способ получить первоначальное представление о системе и сформулировать вопросы к экспертам.

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

Недостаток этой стратегии - опасность пропуска знаний, специфичных для объекта исследования (в случае самоопроса), либо - неформализованных знаний, эмпирических правил и процедур, широко используемых на практике, но не вошедших в документы.

Совместные семинары. Помимо классического интервью "тет а тет", существует значительное количество методик, предполагающих широкое участие представителей Заказчика и Исполнителя.

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

Затем, на втором этапе, все высказанные мнения тщательным образом обсуждаются, заведомо неприемлемые варианты отсеиваются, формируются коллективные предложения.

Правила JAD-метода, считающегося одним из современных способов извлечения требований, были впервые сформулированы в конце 1970-х годов компанией IBM.

Участники JAD-совещания:

• Ведущий - специалист в области межличностных коммуникаций. Должен ориентироваться в предметной области, но не обязательно хорошо ориентироваться в проблемах IT.

• Секретарь - стенографист встречи. Фиксирует ее результаты на компьютере. Возможно применение CASE-средств.

• Заказчики - пользователи или руководители, основные участники, формирующие, обсуждающие требования и принимающие решения.

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

Прототипирование. Прототипирование - ключевая стратегия выявления требований в большинстве современных методологий . Программный прототип - "зеркало", в котором видно отражение того, как понял Исполнитель требования Заказчика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Концепция в ГОСТ РФ.

В соответствии с ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания" [7.2], после этапа формирования (выявления) требований к системе выполняется этап разработки концепции системы.