Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Технологии создания программного обеспечения 381

ляет собой основу для последующей оценки проекта. Для фор-

мирования такой основы необходимо выполнить следующие

действия:

• описать проект в терминах ожидаемых результатов (т.е. ко-

нечного продукта). Описание должно включать форму

представления и содержание результатов. Должны быть чет-

ко определены договорные требования и соответствующие

стандарты;

• определить общие цели проекта, а именно: насколько хоро-

шо и до какой степени ТС ПО планируется использовать в

среде данного проекта. Примером цели может быть опреде-

ление степени улучшения качества проектной документа-

ции в результате применения ТС ПО;

• определить конкретные задачи, реализующие поставленные

цели. Каждой цели можно поставить в соответствие одну

или несколько конкретных задач с количественно оценива-

емыми результатами. Примером такой задачи может быть

сравнительный анализ качества документации, полученной

с помощью

ТС

ПО

без

нее.

Документация может включать

спецификацию требований к ПО, высокоуровневые и де-

тальные проектные спецификации;

• установить критерии оценки

результатов.

Чтобы определить

степень успеха пилотного проекта, необходимо использо-

вать набор критериев, основанных на упомянутых выше за-

дачах. Примером критерия может быть степень непротиво-

речивости проектной документации и контролируемости

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

ПО.

Значения критериев должны

сравниваться с базовыми значениями, полученными до вы-

полнения пилотного проекта.

Персонал

Специалисты, выбранные для участия в пилотном проекте,

должны иметь соответствующий авторитет

влияние и быть сто-

ронниками новой ТС ПО.

Группа

должна включать как техничес-

ких специалистов, так и менеджеров, заинтересованных в новой

ТС ПО и разбирающихся в ее использовании. Группа должна об-

ладать высокими способностями к коммуникации, знанием осо-

бенностей организационных процессов и процедур, а также

предметной области. Группа не должна, тем

*не

менее, состоять

382 Глава 5

полностью из специалистов высшего звена, она должна пред-

ставлять средний уровень организации.

После завершения пилотного проекта группа должна быть

открыта для обмена информацией с остальными специалистами

организации относительно возможностей нового средства

опы-

та, полученного при его использовании. Может оказаться жела-

тельным рассредоточить проектную фуппу по всей организации

в целях распространения их опыта и знаний.

Процедуры

соглашения

Необходимо четко определить процедуры и соглашения, ре-

гулирующие использование ТС ПО в пилотном проекте. Эта за-

дача, скорее всего, может оказаться более долгой и сложной, чем

ожидается, при этом может оказаться необходимым привлечение

сторонних экспертов. Примерами процедур и соглашений, кото-

рые могут повлиять на успех пилотного проекта, являются мето-

ды,

технические соглашения

(в

частности, соглашения по наиме-

нованиям и структуре каталогов, стандарты проектирования и

профаммирования) и организационные соглашения (в частнос-

ти,

правила учета использования ресурсов, авторизации и конт-

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

ства и подготовки отчетов).

пилотном проекте по возможности должны использоваться

существующие

организации процедуры

соглашения.

другой

стороны, в течение пилотного проекта неэффективные или че-

ресчур ограничивающие процедуры и соглашения могут разви-

ваться и совершенствоваться по мере накопления опыта приме-

нения средства. При этом те изменения, которые предлагается в

них вносить, должны документироваться.

Обучение

Должны быть определены виды и объем обучения, необходи-

мого для пилотного проекта. Планируемое обучение должно

обеспечивать три вида потребностей: технические, управленчес-

кие и мотивационные. Ресурсы, требуемые для обучения (учеб-

ные аудитории и оборудование, преподаватели и учебные мате-

риалы), должны соответствовать плану пилотного проекта.

График обучения должен определять как специалистов, под-

лежащих обучению, так и виды обучения, которое они должны

пройти. Обучение, которое проводится в период выполнения

Технологии создания программного обеспечения 383

проекта, должно начинаться как можно быстрее после начала

проекта. Обучение средствам, процессам или методам, которые

не будут использоваться в течение нескольких месяцев после на-

чала проекта, должно планироваться в то время, когда в них воз-

никнет реальная потребность.

Поставщики ТС ПО обычно предлагают обучение использо-

ванию поставляемых ими средств. Помимо этого для некоторых

средств может быть необходимо обучение методологии. Некото-

рые виды обучения могут быть недоступны со стороны коммер-

ческих организаций, они должны выполняться собственными

силами. Такие виды обучения включают использование ТС ПО в

контексте процессов, происходящих

организации,

также

со-

вокупности с другими средствами в данной среде. Часть плана

пилотного проекта, связанная с обучением, должна использо-

ваться в качестве входа для плана практического внедрения.

При выборе необходимого обучения должны приниматься во

внимание следующие факторы:

• квалификация преподавателей;

• соответствие обучения характеристикам конкретных групп

специалистов (например, обзорные курсы для менеджеров,

подробные курсы для разработчиков);

• возможность проведения курсов непосредственно на рабо-

чих местах;

• возможность проведения расширенных курсов;

• возможность подготовки самих преподавателей.

График и

ресурсы

Должен быть разработан график, включающий ресурсы и

сроки (этапы) проведения работ. Ресурсы включают персонал,

технические средства, ПО

финансирование. Данные о персона-

ле могут определять конкретных специалистов или требования к

квалификации, необходимой для успешного выполнения пилот-

ного проекта. Финансирование должно определяться отдельно

по каждому виду работ: приобретение ТС ПО, установка, обуче-

ние,

отдельные этапы проектирования.

Выполнение пилотного проекта

Пилотный проект должен выполняться в соответствии с пла-

ном. Организационная деятельность, связанная с выполнением

пилотного проекта

подготовкой

отчетов,

должна осуществлять-

384 Глава 5

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

специального внимания к вопросам приобретения, поддержки,

экспертизы и обновления версий.

Приобретение, установка

интеграция

После того как

ТС

ПО выбрана, она должна быть приобрете-

на, интефирована в проектную среду и настроена

соответствии

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

зависят от

тех

действий, которые имели место в процессе оценки

и выбора, а также от степени модификации средства, необходи-

мой для его использования в проекте.

Процесс приобретения может включать подготовку контрак-

та, переговоры, лицензирование и другую деятельность, которая

выходит

за

рамки данных рекомендаций.

Эта

деятельность требу-

ет

затрат времени

человеческих

ресурсов,

которые должны

быть

учтены при планировании. План должен предусматривать отказ

от выбранной ТС ПО на данном этапе из-за договорных разно-

гласий.

После приобретения средства должны быть установлены, от-

тестированы и приняты

эксплуатацию. Тестирование позволяет

убедиться, что поставленный продукт соответствует требованиям

контракта, обладает необходимой полнотой и корректностью.

Этап приемки может быть предусмотрен контрактом, его реаль-

ный срок может отличаться от того, который был предусмофен

первоначально в плане пилотного проекта. Особое внимание не-

обходимо уделить соблюдению всех фебований поставщика к

парамефам среды функционирования ТС ПО.

После завершения приемки может пофебоваться некоторая

насфойка и интефация. Насфойка может включать модифика-

цию интерфейсов, связанную

требованиями специалистов про-

ектной фуппы, а также с установкой прав доступа и привилегий.

Насфойка должна оставаться в рамках тех возможностей, кото-

рые предоставляет сама ТС ПО.

Если новые средства должны использоваться в совокупности

с некоторыми другими средствами, необходимо определить взаи-

модействие средств и фебуемую интефацию. Для интефации

новых средств с существующими может понадобиться посфое-

ние специальных оболочек. Сложная интефация может пофебо-

вать привлечения сторонних экспертов.

Технологии создания программного обеспечения 385

Поддержка

Доступная поддержка должна включать (по соглашению) «го-

рячую линию» поставщика и поддержку местного поставщика,

поддержку в самой организации, контакты с опытными пользо-

вателями

других организациях

участие

работе групп пользо-

вателей.

Внутренняя поддержка должна включать

доступ

к специалис-

там, знакомым с установкой средств и работой с ними. Сущест-

вует несколько возможных вариантов получения такой поддерж-

ки (например, от специалиста данной организации, имеющего

опыт предшествующей работы со средством; участников процес-

са оценки и выбора или опытного консультанта). Такой тип под-

держки должен специальным образом планироваться и админи-

стрироваться. Особое внимание должно быть уделено средствам,

работающим

сетях или обладающих репозиториями, поддержи-

вающими многопользовательскую работу.

Периодические экспертизы

Обычные процедуры экспертизы проектов, существующие в

организации, должны выполняться

для пилотного проекта, при

этом особое внимание должно уделяться именно пилотным ас-

пектам проекта. Помимо этого результаты экспертиз должны

служить мерой успешного использования ТС ПО.

Обновление версий

Пользователи ТС ПО могут ожидать периодического обнов-

ления версий со стороны поставщика в течение выполнения пи-

лотного проекта. При этом необходимо тщательное отношение к

интеграции этих версий. Следует заранее оценить влияние этих

обновлений на ход проекта. Новые версии могут как обеспечить

новые возможности, так и породить новые проблемы. В то же

время новая версия может потребовать видоизмененного или до-

полнительного обучения, а также может оказать отрицательное

воздействие на уже выполненную к этому моменту работу.

Оценка пилотного проекта

После завершения пилотного проекта его результаты необхо-

димо оценить и сопоставить с начальными потребностями орга-

низации, критериями успешного внедрения ТС ПО, базовыми

386 Глава 5

метриками и критериями успеха пилотного проекта. Такая оцен-

ка должна установить возможные проблемы и важнейшие харак-

теристики пилотного проекта, которые могут повлиять на при-

годность

ТС ПО для

организации.

Она

должна также указать про-

екты или структурные подразделения внутри организации, для

которых данная ТС ПО является подх^одящей. Помимо этого

оценка может дать информацию относительно совершенствова-

ния процесса внедрения

дальнейшем.

В процессе оценки пилотного проекта организация должна

определить свою позицию по следуюш.им трем вопросам.

• Целесообразно ли внедрять ТС ПО?

• Какие конкретные особенности пилотного проекта привели

к его успеху (или неудаче)?

• Какие проекты или подразделения в организации могли бы

получить выгоду от использования ТС ПО?

Принятие решения о внедрении

На данном этапе процесса внедрения организация должна

сделать существенные инвестиции в ТС ПО. Если ТС ПО удов-

летворила или даже превысила ожидания организации, то реше-

ние об ее внедрении может быть принято достаточно просто и

быстро.

С другой стороны, может оказаться, что в рамках пилотного

проекта ТС ПО не оправдала тех ожиданий, которые на нее воз-

лагались, или же в пилотном проекте она использовалась удов-

летворительно, однако опыт показал, что дальнейшие вложения

в ТС ПО не гарантируют успеха.

Возможны четыре варианта результатов и соответствующих

действий.

• Пилотный проект потерпел неудачу, и его анализ показал

неадекватность ожиданий организации.

этом случае орга-

низация может пересмотреть результаты проекта в контекс-

те более реалистичных ожиданий.

• Пилотный проект потерпел неудачу,

и его

анализ показал, что

выбранные средства не удовлетворяют потребности органи-

зации.

этом случае организация может принять решение не

внедрять данные средства, однако при этом также пересмот-

реть свои потребности и подход к оценке и выбору

ТС

ПО.

• Пилотный проект потерпел неудачу, и его анализ показал

наличие таких проблем, как неудачный выбор пилотного

Технологии создания программного обеспечения 387

проекта, неадекватное обучение и недостаток ресурсов. В

этом случае может оказаться достаточно сложным принять

решение о том, следует ли вновь выполнить пилотный про-

ект, продолжить работу по внедрению или отказаться от ТС

ПО.

Однако независимо от принятого решения процесс

внедрения нуждается в пересмотре и повышенном внима-

нии.

• Пилотный проект завершился успешно, и признано целесо-

образным внедрять ТС ПО в некоторых подразделениях

или, возможно, во всей организации.

этом случае следую-

щим шагом является определение наиболее подходящего

масштаба внедрения.

ряде случаев анализ пилотного проекта может показать, что

причиной неудачи явился более чем один фактор. Последующие

попытки внедрения ТС ПО должны четко выявить все причины

неудачи.

экстремальных случаях тщательный анализ может по-

казать, что в настоящий момент организация просто не готова к

успешному внедрению сложных ТС ПО.

такой ситуации орга-

низация может попытаться решить свои проблемы другими сред-

ствами.

Особенности пилотного проекта

Очень важно провести анализ пилотного проекта

тем, чтобы

определить его элементы, являющиеся критическими для успеха,

и степень отражения этими элементами организации в целом.

Например, если в пилотном проекте участвуют самые лучшие

специалисты организации, он может закончиться успешно даже

вопреки использованию ТС ПО, а не благодаря ей. С другой сто-

роны,

ТС

ПО может

быть

применена

для

разработки приложений,

для которых она явно не подходит

по

своим характеристикам. Тем

не менее, такое использование могло бы указать на область наи-

более рационального применения ТС ПО

данной организации.

Отметим важнейшие характеристики пилотного проекта, не

являющиеся представительными для организации в целом:

• процессы в пилотном проекте в чем-либо отличаются от

процессов во всей организации;

• квалификация фуппы пилотного проекта не отражает ква-

лификацию остальных специалистов организации;

• ресурсы, выделенные на выполнение проекта, могут отли-

чаться от

тех,

которые выделяются для обычных проектов;

388 Глава 5

• предметная область или масштаб проекта могут отличаться

от других

проектов.

Выгода от использования

ТС

ПО

Результаты пилотного проекта следует сопоставить с возмож-

ностями организации в целом. Например, если наиболее заинте-

ресованные и квалифицированные участники проекта столкну-

лись с серьезными трудностями в освоении ТС ПО, то менее за-

интересованным и квалифицированным профаммистам из дру-

гих подразделений потребуется существенно большее обучение.

Пилотный проект может также показать, что ТС ПО целесо-

образно использовать для некоторых классов проектов и нецеле-

сообразно - для других. Например, средство формальной вери-

фикации может подходить для жизненно важных приложений и

не подходить для менее критических приложений.

Перед разработкой плана перехода организация должна оце-

нить ожидаемый эффект

для

различных подразделений или клас-

сов проектов. При этом следует учитывать, что некоторые под-

разделения могут не обладать необходимой квалификацией или

ресурсами для использования ТС ПО.

Варианты

решения

о внедрении

Возможным решением должно быть одно из следующих.

• Внедрить ТС ПО. В этом случае рекомендуемый масштаб

внедрения должен быть определен в терминах структурных

подразделений и предметной области.

• Выполнить дополнительный пилотный проект. Такой вари-

ант должен рассматриваться только

том случае, если оста-

лись конкретные неразрешенные вопросы относительно

внедрения ТС ПО в организации. Новый пилотный проект

должен быть таким, чтобы ответить на эти вопросы.

• Отказаться

от ТС

ПО.

этом случае причины отказа

от

конк-

ретной ТС ПО должны быть определены в терминах потреб-

ностей организации или критериев, которые остались неу-

довлетворенными. Перед тем как продолжить деятельность

по внедрению ТС ПО, потребности организации должны

быть пересмотрены на предмет своей обоснованности.

• Отказаться от использования ТС ПО вообще. Пилотный

проект может показать, что организация либо не готова к

внедрению ТС ПО, либо автоматизация данного аспекта

Технологии создания программного обеспечения 389

процесса создания и сопровождения ПО не дает никакого

эффекта для организации.

этом случае причины отказа от

ТС ПО должны быть также определены в терминах потреб-

ностей организации или критериев, которые остались неу-

довлетворенными. При этом необходимо понимать отличие

этого варианта от предыдущего, связанного с недостатками

конкретной ТС ПО.

Результатом данного этапа является документ, в котором об-

суждаются результаты пилотного проекта и детализируются ре-

шения по внедрению.

5.3.6.

ПРАКТИЧЕСКОЕ ВНЕДРЕНИЕ ТС ПО

Процесс перехода к практическому использованию ТС ПО

начинается с разработки и последующей реализации плана пере-

хода. Этот план может отражать поэтапный подход к переходу -

от

тщательно выбранного пилотного проекта

до

проектов

суще-

ственно возросшим разнообразием характеристик.

Разработка

плана

перехода

План перехода должен охватывать:

• информацию относительно целей, критериев оценки, гра-

фика и возможных рисков, связанных с реализацией плана;

• информацию относительно приобретения, установки и

настройки ТС ПО;

• информацию относительно интефации с существующими

средствами, включая как интеграцию средств друг

другом,

так и их интефацию в процессы разработки и эксплуатации

ПО,

существующие в организации;

• ожидаемые потребности в обучении и ресурсы, используе-

мые

течение и после завершения процесса перехода;

• определение стандартных процедур использования ТС ПО.

Цели, критерии оценки, график и риски, связанные с планом

перехода

Данная информация должна включать:

• типы проектов,

которых

конечном счете будет использо-

ваться ТС ПО;

• фафик перехода к практическому использованию ТС ПО в

отдельных проектах;

390 Глава 5

• график внедрения ТС ПО в терминах количества пользова-

телей, включая необходимое обучение;

• возможные риски и непредвиденные обстоятельства;

• источники существующих (базовых) данных и метрики для

оценки изменений, вызванных использованием ТС ПО.

дополнение к сказанному следует уделить особое внимание

вопросам контроля изменений. Роли высшего руководства, субъ-

ектов и объектов изменений должны быть уточнены по сравне-

нию с пилотным проектом, поскольку технология подлежит ши-

рокому распространению в организации.

Подразумевается, что план перехода успешно выполнен, ког-

да не требуется больше специального планирования поддержки

использования ТС ПО.

этот момент использование ТС ПО сог-

ласуется с тем, что от нее ожидалось, и план работы с ней вклю-

чается в общий план текущей поддержки ПО, существующий в

организации.

Приобретение, установка

настройка

ТС

ПО

Приобретение, установка и настройка, выполненные в рам-

ках пилотного проекта, могут потребоваться в более широком

масштабе. При этом необходима следующая информация:

• совокупность программных компонентов и документации,

которые следует приобретать для каждой отдельной плат-

формы;

• необходимое обучение;

• механизм получения новых версий;

• настройка средств для выполнения существующих в орга-

низации процедур и соглашений;

• наличие лица или подразделения, ответственного за уста-

новку, интеграцию, настройку и эксплуатацию средств;

• план конвертирования данных и снятия старых средств с

эксплуатации.

Задачи приобретения, установки и настройки должны быть

как можно быстрее переданы из фуппы пилотного проекта в су-

ществующую службу системной поддержки ПО организации.

Интеграция средств ТС ПО с существующими средствами и

процессами

Интефация новых средств с существующими средствами и

процессами является важным шагом в полномасштабном внед-