Видение проекта пример. Глава восьмая Видение проекта: Понимание видения проекта спонсором
Формирование видения
Прототипирование
Прототипирование - ключевая стратегия выявления требований в большинстве современных методологий (подробнее см. в лекции 10). Программный прототип - "зеркало", в котором видно отражение того, как понял Исполнитель требования Заказчика. Процесс выявления требований путем прототипирования тем более интенсивен, чем это зеркало кривее. Документальный способ выявления требований всегда уступает живому общению. Анализ того, что сделано в виде интерфейсов пользователя дает еще больший эффект. Подключается правополушарный канал восприятия, который, как известно, работает у большинства людей на порядок эффективнее, чем вербальный.
Метод RAD - один из наиболее известных способов быстро создавать прототипы 1) .
RAD базируется на следующих базовых принципах:
- Эволюционное прототипирование;
- CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода;
- Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами;
- Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online;
- Жесткие временные рамки, как противоядие от "расползания границ" проекта: если команда не укладывается в срок - функционал сужается.
Работы по формированию видения продукта и границ проекта обычно начинаются на самой ранней фазе проекта, до начала широкомасштабных консультаций по выявлению подробных требований, хотя в целом наличие и последовательность данных шагов зависит от выбранной методологии. На практике данные работы зачастую совмещаются. Правила извлечения требований, рассмотренные в лекции 6, могут быть использованы и при формировании видения.
Анализируя литературу по рассматриваемой тематике, можно выделить следующие широко употребимые ключевые слова: с одной стороны - концепция, видение, образ, с другой - рамки, границы, контекст.
В первом случае речь идет о видении того, какой должна быть система. Обсуждаются высокоуровневые требования (возможности, свойства) продукта и наиболее существенные ограничения. Ряд авторов, напротив, настаивает на том, что видение должно быть "ничем не ограниченным".
Понятие видения широко употребимо в бизнес-анализе. Если у топ-менежмента компании имеется представление о том, какие ключевые цели, сегменты рынка, товарные позиции, прибыль должны быть достигнуты, допустим, через 5 лет - значит, компания имеет долгосрочное видение себя на рынке. Способ снятия ограничений при выработке видения позволяет выработать новый взгляд на вещи, "подняться над ситуацией", планировать будущее, отталкиваясь не от текущих ресурсов и ограничений, а от стратегических целей, применяя инновации, ноу-хау и т.п.
Данный опыт формирования видения во многом переносим и на процесс разработки информационных систем: нужно "увидеть" в горизонте средне- и (или) долгосрочного планирования, как АИС впишется в организационные процессы предприятия, какие ключевые выгоды она даст, какие проблемы позволит разрешить. При поиске новых методов и средств управления предприятием на основе информационных технологий зачастую приходится "перекраивать" существующие бизнес-процессы; по сути внедрение АИС, затрагивающей существенный процент процессов предприятия, неизбежно приводит к перестройке этих процессов с целью оптимизации деятельности предприятия, достижения ключевых факторов эффективности и пр.
Во втором случае (рамки, границы, контекст) обсуждаются такие вопросы, как граница системы и среды, требуемые ресурсы на создание системы, сроки. Построив "ничем не ограниченное видение", рано или поздно приходится вернуться к таким прозаическим вещам, как бюджет, календарное планирование, подбор персонала, вехи проекта.
Всегда ли нужно создавать документ "Концепция"? Следует ли разделять видение и границы?
Зачастую Заказчик осознает необходимость автоматизации, как способ решения накопившихся проблем. Сформулировав для себя проблему, Заказчик часто видит и вариант ее решения, с которым приходит к Исполнителю ("мне нужен сайт", "требуется CRM-система" и т.п.). Квалифицированный Исполнитель не должен, сломя голову, спешить решать задачу в формулировке Заказчика. По образному выражению Г.Калянова 1) автоматизировать процессы "как есть" - все равно, что асфальтировать дорожки, по которым ходят коровы.
В нотации RUP присутствует важная метафора: "Увидеть проблему за проблемой". Концепция как раз и служит для того, чтобы помочь Заказчику выявить именно те требования к системе, которые помогут ему оптимизировать работу своего предприятия в долгосрочной перспективе.
Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику и к Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями, чтобы разрабатываемое средство автоматизации действительно принесло пользу. Все вышесказанное ничуть не исключает возможность работы без концепции: либо речь идет о небольшом проекте, закладывать в бюджет которого этап выработки концепции просто нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы сформулировать требования к АИС, имея "концепцию в голове" и время для консультирования Разработчика.
Некоторые аргументы за разделение видения и границ были приведены выше. Провести четкую границу между этими понятиями предлагает, в частности, процесс MSF. В конечном итоге, вопрос "разделять или не разделять" определяется выбранной методологией.
Рассмотрим основные требования к выработке концепции, заложенные в отечественных ГОСТ, методологиях RUP и MSF.
Заказчик:
DABCC.COM
Исполнитель:
Douglas Brown, Owner
Проект:
Развертывание Citrix® MetaFrame® Access Suite
Стадия проверки концепции проекта предназначена для определения возможностей продлагаемого развертывания MetaFrame Access Suite с точки зрения достижения видения проекта. В процессе проверки концепции создан прототип среды MetaFrame Access Suite вместе со всеми необходимыми приложениями, принтерами и т.п. Приложения были тщательно протестированы для проверки их работоспособности в терминальной среде MetaFrame XP/Terminal Server. По каждому пункту задокументированы результаты и внесены необходимые корректировки. Этот документ является итоговым отчетом по процедурам проверки концепции.
Этот документ разделен на следующие разделы:
- Спецификация среды
- Процедура создания среды
- Тесты
- Корректировки тестов
- Заключение
1. Спецификация среды
1.2. Аппаратное обеспечение
| Имя: DB2KCTX1 Модель: Compaq ML 530 Роль: Citrix MetaFrame XP Server |
| 48x CDROM, второй - под Compaq Internal DLT 20/40 Дисковый контроллер - Smart Array 4200 4-канальный контроллер RAID 5 |
| Имя: DB2KWEB1 Модель: Compaq ML 530 Роль: Web Interface Web Server |
| Form Factor – монтируемый в стойку Процессор – 2 х 933MHz, Pentium III Xeon, 256KB level 2-Advanced Transfer Cache. Память – 1 GB 133 MHz ECC SDRAM, расширяемая до 4GB с использованием модулей 512 MB Сетевой адаптер - NC3123 Fast Ethernet NIC PCI 10/100 controller Отсеки под диски – 4 отсека 5.25" для съемных дисков и один 1.44 MB флоппи-привод. Один использован под привод 48x CDROM, второй - под Compaq DLT 20/40 Дисковые накопители - всего 218.4 GB Maximum Internal Hot Plug Storage Ultra2. Установлены три диска 18.2 GB Hot Plug Ultra 3 Дисковый контроллер - Smart Array 5300 RAID ADG, настроен на RAID 5 Интерфейсы - один порт RJ-45 Ethernet, два последовательных, один параллельный, клавиатуры, мышь, видео, внешний SCSI |
1.3. Среда операционных систем
| Конфигурация домена | |
| Active Directory или NT Domain? | Active Directory |
| (NT Domains) Модель домена (Single domain, Master domain, Multiple-master, etc.): | - |
| (Active Directory) Режим (native / mixed)? | Native |
| (Active Directory) Имя дерева: | DABCC.COM |
| (Active Directory) Имя домена: | DABCC.COM |
| (Active Directory) Пространство имен DNS: | DABCC.COM |
| (Active Directory) Внутреннее пространство имен: | DABCC |
| Имена серверов DNS: | DB2KAD1, DB2KAD2 |
| Имена серверов WINS: | DB2KAD2 |
| Имя сервера DHCP: | DB2KAD2 |
| Адреса TCP/IP | |
| Укажите информацию об адресах IP вашей сети | |
| Network Address: | 192.168.1.0 |
| Subnet Mask: | 255.255.255.0 |
| Gateway: | 192.168.1.254 |
| Primary WINS: | 192.168.1.1 |
| Secondary WINS: | Нет |
| Primary DNS: | 192.168.1.1 |
| Secondary DNS: | 192.168.1.2 |
| Укажите адреса серверов, перечисленных в разделе "Аппаратная среда": | |
| DB2KAD1 | 192.168.1.5 |
| DB2KAD2 | 192.168.1.6 |
| DB2KFS1 | 192.168.1.71 |
| DB2KWEB1 | 192.168.1.8 |
| Укажите адреса IP сетевых принтеров | |
| HP 4M | 192.168.1.15 |
| HP 4000 | 192.168.1.16 |
| HP 4000 | 192.168.1.17 |
| HP LaserJet 4050 Color | 192.168.1.18 |
| HP OfficeJet 720 | 192.168.1.19 |
| Укажите диапазон DHCP: | |
| Диапазон DHCP: | с 192.168.1.100 по 92.168.1.200 |
| Список OU | |
| Наименование | Описание |
| Built-in | Default OU |
| Computers | OU для конечных пользователей |
| DABCC Users | OU для пользователей и групп DABCC.COM |
| Domain Controllers | OU для контроллеров домена Windows 2000 Active Directory. Включает в себя DB2KAD1 и DB2KAD2. |
| Foreign Security/Principles | Default OU |
| Servers | OU для серверов Windows NT/2000. Включает: DB2KFS1 и DB2KWEB1 |
| Users | OU по умолчанию для пользователей и групп Active Directory |
| Информация о групповых политиках (если есть) | |
| Используются политики WinNT или Win2000? | Win2000 |
| Размещение файлов политик | - |
| Пользователи и группы, затрагиваемые политиками | Administrators, Users |
1.4. Скрипты входа
| net use h: \dabcc\\dfsroot\users\%username% |
Logon_admins.cmd
| net use j: \dabcc\\dfsroot\applications net use k: \dabcc\\dfsroot\drivers net use o: \dabcc\\dfsroot\citrix net use p: \dabcc\\dfsroot\public |
1.5. Среда печати
| Имя принтера | Имя сервера печати | Драйвер |
| HP4M | DB2KFS1 | HP 4M |
| HP4000West | DB2KFS1 | HP 4000 |
| HP4000East | DB2KFS1 | HP 4000 |
| HPColor | DB2KFS1 | HP LaserJet 4050 Color |
| HPOfficeJet | DB2KFS1 | HP OfficeJet 720 |
1.6. Клиентская среда
2. Процедура создания среды
Сервер Citrix MetaFrame Access Suite и все другие серверы, использованные на этапе проверки концепции, настроены в сооветствии с методологией D&D Consulting, включая безопасность и оптимизацию сервера. Это делается на тот случай, если проверка концепции будет успешной, то среда сервера будет основой для промышленного внедрения MetaFrame Access Suite в промышленную среду.
Подробности относительно проектирования MetaFrame XP, MetaFrame Secure Access Manager, Web Interface или Secure Gateway см. в документации, предложенной D&D Consulting.
Ниже приведен основной список шагов по созданию сервера MetaFrame XP:
- Установка операционной системы сервера, последнего сервис-пака и хотфиксов
- Установка необходимых служб и удаление ненужных служб
- Настройка сетевой и доменной идентификации сервера
- Изменение службы SNMP так, чтобы сообщество “public” имело право"чтение и запись"
- Настройка всех сетевых адаптеров сервера на 100 Mbps и Full Duplex
- Настройка локальной безопасности на сервере Citrix
- Активация сервера лицензирования Terminal Services Licensing и клиентских лицензий TS CAL
- Инсталляция последнего Feature Release на Citrix MetaFrame XP и последнего сервис-пака
- Настройка лицензирования Citrix на сервере
- Установка Citrix Installation Manager (если требуется)
- Установка Citrix Resource Manager (если требуется)
- Настройка на сервере SpeedScreen
- Настрока соединений
- Настройка ICA Client Update Configuration
- Настройка на сервере оптимизации
- Иолирование сервера с использованием прав доступа NTFS и системных политик
- Настройка печати на сервере
- Установка и настройка приложений
- Настройка SpeedScreen для индивидуальных приложений
- Публикация приложений
- Создание диска аварийного восстановления
- Установка остальных компонентов (MetaFrame Conferencing Manager, Web Interface, Secure Gateway, и т.п.)
- Проверка сервера и приложений
2.2. Процедура инсталляции приложений
Напишите подробную инструкцию инсталляции каждого приложения, которое
будет проверяться на этапе проверки концепции.
3.0. Тесты
4.0 Корректировка тестов
5.0 Заключение
После анализа результатов тестирования и необходимых корректировок, D&D Consulting и DABCC.COM определили, что получены достаточные основания для продолжения изначально спланированного проекта.
Предполагает определение тех ключевых качественных и количественных показателей, которых проект позволит достичь в будущем. Стратегическое видение позволяет искать и находить ответы на вопрос «Что изменится, когда проект будет завершен?» Кроме того, видение помогает субъектам внешней среды (партнерам, контрагентам и др.) оценивать намерения проектной организации относительно ее дальнейших действий и поведения в деловой среде, а также прогнозировать перспективы развития взаимоотношений и формировать требования к ответственности за принимаемые решения.
Миссию, видение и стратегические цели проекта рекомендуется разрабатывать на основе SWOT-анализа:
Strong - сила (преимущества, придающие дополнительные возможности, конкурентную привлекательность проекту);
Weak - слабость (отсутствие чего-то важного для функционирования проекта, то, что не удается в сравнении с другими или ставящее в неблагоприятные условия);
Opportunity - возможности (благоприятные условия, дающие шанс сделать что-то новое: создать новый продукт, услугу, внедрить новую технологию и т. п.);
Trouble - угрозы (то, что может нанести ущерб, лишить существенных преимуществ: риски, форсмажорные обстоятельства и др.)
Пример 2. Миссия Герценовского университета в программе стратегического развития на 2006-2010 гг.
«Миссия Герценовского университета в современных условиях, отражая основные ценности нового, характерного для начала третьего тысячелетия смысла университетского образования и лучшие традиции отечественного образования, ориентирует коллектив герценовцев на построение университета как пространства жизненного самоопределения Человека во всем многообразии его проявлений в современной культурной практике».
Еще по теме Видение проекта:
- ОСНОВЫ РАБОТЫ ПРОЕКТА ДОПОЛНИТЕЛЬНОГО ЭКОЛОГИЧЕСКОГО ОБРАЗОВАНИЯ"РЕЧНИКИ В ГАРМОНИИ С ПРИРОДОЙ"
- ОРГАНИЗАЦИОННО-СОДЕРЖАТЕЛЬНЫЕ АСПЕКТЫ РЕАЛИЗАЦИИ ПРОЕКТА "МОДЕЛЬ НЕПРЕРЫВНОГО ЭКОЛОГИЧЕСКОГО ОБРАЗОВАНИЯ И ВОСПИТАНИЯ НА ТЕРРИТОРИИ АСИНОВСКОГО РАЙОНА" В РАМКАХ ДОШКОЛЬНОГО УЧРЕЖДЕНИЯ
Маленькая ошибка в начале ведет к большой ошибке в конце.
Фома Аквинский
На этапе разработки видения проекта, которое является первым элементом гибкой модели проекта (КФУ 3), дается ответ на первый вопрос бизнеса: «Кому это нужно и зачем?».
От ответа на этот вопрос зависят ответы на другие вопросы бизнеса: «Что для этого надо сделать?», «Сможем ли мы с этим справиться?» и «Оно того стоит?». Видение проекта включает два взаимосвязанных компонента: видение спонсора и коллективное видение. На начальном этапе, еще до того, как будет сформирована команда, менеджер по управлению проектом должен понять, как видит проект спонсор. Коллективное видение - это видение спонсора, скорректированное с учетом обсуждения и согласования с основными участниками проекта. Таким образом, разработка видения проекта - это циклический процесс, включающий его разработку и пересмотр на рамочной встрече и совещании по планированию. Эта глава посвящена пониманию и уточнению того, как видит проект спонсор, то есть первой стадии разработки видения проекта. В девятой главе рассматривается переход от видения спонсора к коллективному видению (то есть видению основных участников проекта и других заинтересованных лиц, а также основной команды по управлению проектом)
В этой главе рассматриваются следующие вопросы:
модель «Цели - Конечный результат - Экономический эффект»;
как вести себя на встрече со спонсором;
как разработать черновой вариант Устава проекта и коротко изложить основные элементы проекта, включая краткое (не более трех строк) содержание проекта; границы проекта; императивы проекта; организационную структуру программы, в которую входит проект, видение конечного продукта; и семь условий успеха.
Большинство организаций страдают от избытка новых идей, проблем, требующих решения, и возможностей, требующих реализации. В результате проекты размножаются, как сорняки и начинают жить независимой жизнью. Они поглощают питательные вещества из почвы, на которой произрастают и действительно ценные проекты. К тому же, без официального спонсора реализация даже высоко прибыльных проектов весьма рискованна, так как может привести к замедлению работы над проектом или его провалу, даже в том случае, если он будет доведен до конца.
Кроме того, спонсор может иметь весьма туманные представления о том, чего он на самом деле хочет, и говорить что-то вроде «Оделяйте нам "ТО’еЬ-сайт. У наших конкурентов он уже есть». Или же, напротив, он может очень четко представлять, чего он, как он думает, хочет. Однако под воздействием внешних условий, под влиянием участников проекта и в силу скрытой необходимости и явных потребностей, обнаруживающихся при работе над проектом, его представления, скорее всего, будут часто и непредсказуемо меняться в течение всего срока реализации проекта.
Спонсор может иметь весьма туманные представления о том, чего он на самом деле хочет.
