Затонский А.В. Пособие по полному жизненному циклу информационных систем

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

371

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

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

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

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

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

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

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

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

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

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

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

поставляемых ими ИС. Помимо этого, для некоторых ИС может быть

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

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

использование ИС в контексте процессов, происходящих в организации, а

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

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

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

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

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

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

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

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

разработчиков);

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

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

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

График и ресурсы

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

проведения работ. Ресурсы включают персонал, технические средства, ПО и

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

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

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

отдельно по каждому виду работ: приобретение ИС, установка, обучение,

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

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

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

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

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

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

372

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

ниже.

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

После того, как ИС выбрана, она должна быть приобретена,

интегрирована в среду предприятия и настроена в соответствии с требованиями

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

которые имели место в процессе оценки и выбора, а также от степени

модификации ИС, необходимой для ее использования в проекте.

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

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

данных рекомендаций. Эта деятельность требует затрат времени и

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

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

этапе из-за договорных разногласий.

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

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

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

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

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

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

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

параметрам среды функционирования ИС.

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

Настройка может включать модификацию интерфейсов, связанную с

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

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

возможностей, которые предоставляет сама ИС. Не следует заниматься

модификацией готовых продуктов на уровне исходных кодов.

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

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

требуемую интеграцию. Для интеграции новых ИС с существующими может

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

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

Поддержка

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

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

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

участие в работе групп пользователей.

Внутренняя поддержка должна осуществляться специалистами,

знакомыми с установкой ИС и работой с ними. Существует несколько

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

373

данной организации, имеющего опыт предшествующей работы с ИС;

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

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

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

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

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

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

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

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

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

результаты экспертиз должны служить мерой успешного использования ИС.

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

Пользователи ИС могут ожидать периодического обновления версий со

стороны поставщика в течение выполнения пилотного проекта. При этом

необходимо тщательное отношение к интеграции этих версий. Следует заранее

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

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

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

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

выполненную к этому моменту работу.

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

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

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

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

успеха пилотного проекта [15]. Такая оценка должна установить возможные

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

повлиять на пригодность ИС для организации. Она должна также указать

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

данная ИС является подходящей. Помимо этого, оценка может дать

информацию относительно совершенствования процесса внедрения в

дальнейшем.

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

свою позицию по следующим трем вопросам:

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

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

(или неудаче)?

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

выгоду от использования ИС?

374

Принятие решения о целесообразности внедрения

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

существенные инвестиции в ИС. Если ИС удовлетворила или даже превысила

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

достаточно просто и быстро.

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

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

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

дальнейшие вложения в ИС не гарантируют успеха.

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

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

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

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

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

ИС не удовлетворяет потребности организации. В этом случае

организация может принять решение не внедрять данную ИС, однако при

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

ИС.

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

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

обучение и недостаток ресурсов. В этом случае может оказаться

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

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

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

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

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

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

организации в целом. В этом случае следующим шагом является

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

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

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

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

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

просто не готова к успешному внедрению сложной ИС. В такой ситуации

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

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

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

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

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

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

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

375

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

наиболее рационального применения ИС в данной организации.

Важнейшие характеристики пилотного проекта, не являющиеся

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

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

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

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

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

• Ресурсы, выделенные на выполнение проекта, отличаются от тех,

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

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

проектам.

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

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

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

Например, если наиболее заинтересованные и квалифицированные участники

проекта столкнулись с серьезными трудностями в освоении ИС, то менее

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

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

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

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

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

ожидаемый эффект для различных подразделений или классов проектов. При

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

необходимой квалификацией или ресурсами для использования ИС.

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

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

• Внедрить ИС. В этом случае рекомендуемый масштаб внедрения должен

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

области.

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

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

неразрешенные вопросы относительно внедрения ИС в организации.

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

вопросы.

• Отказаться от ИС. В этом случае причины отказа от конкретной ИС

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

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

продолжить деятельность по внедрению ИС, потребности организации

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

376

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

показать, что организация либо не готова к внедрению ИС, либо

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

не дает никакого эффекта для организации. В этом случае причины

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

организации или критериев, которые остались неудовлетворенными. При

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

связанного с недостатками конкретной ИС.

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

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

Документирование ИС

Общие положения

Документация к информационной системе:

• Способствует успешному завершению каждой стадии разработки

• Концентрирует наиболее важную информацию, необходимую для начала

следующей стадии разработки

• Выступает как недвусмысленные средства связи и соглашения между

всеми сторонами, вовлеченными в проект.

Жизненный цикл документации несколько отличается от ЖЦ ПС и

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

• планирование;

• разработка;

• рецензирование;

• утверждение;

• выпуск.

План разработки документации включает:

• Состав документации

• Структура документов

• Графики рецензирования и выпуска документов

• Стиль оформления

• Система наименования и идентификации документов

• Система размещения документации

Виды документации

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

ИС

При разработке ИС создается и используется большой объем

разнообразной документации. Она необходима как средство передачи

информации между разработчиками ИС, как средство управления разработкой

ИС и как средство передачи пользователям информации, необходимой для

377

применения и сопровождения ИС. На создание этой документации приходится

большая доля стоимости ИС [24].

Эту документацию можно разбить на две группы:

• Документы управления разработкой ИС.

• Документы, входящие в состав ИС.

Документы управления разработкой ИС (software process documentation)

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

обеспечивая связи внутри коллектива разработчиков ИС и между коллективом

разработчиков и менеджерами ИС (software managers) − лицами,

управляющими разработкой ИС. Эти документы могут быть следующих

типов:

• Планы, оценки, расписания. Эти документы создаются менеджерами для

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

ИС.

• Отчеты об использовании ресурсов в процессе разработки. Создаются

менеджерами.

• Стандарты. Эти документы предписывают разработчикам, каким

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

разработки ИС. Эти стандарты могут быть как международными или

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

которой ведется разработка ИС.

• Рабочие документы. Это основные технические документы,

обеспечивающие связь между разработчиками. Они содержат фиксацию

идей и проблем, возникающих в процессе разработки, описание

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

версии документов, которые должны войти в ИС.

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

взаимодействия между менеджерами и разработчиками.

Документы, входящие в состав ИС (software product documentation),

описывают программы ИС как с точки зрения их применения пользователями,

так и с точки зрения их разработчиков и сопроводителей (в соответствии с

назначением ИС). Здесь следует отметить, что эти документы будут

использоваться не только на стадии эксплуатации ИС (в ее фазах применения и

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

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

быть проверены (протестированы) на соответствие программам ИС. Эти

документы образуют два комплекта с разным назначением:

• Пользовательская документация ИС (П-документация).

• Документация по сопровождению ИС (С-документация).

При разработке автоматизированных систем (АС), используемых в

различных видах деятельности (исследование, проектирование, управление и

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

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

• Формирование требований к АС

378

• Разработка концепции АС

• Техническое задание

• Эскизный проект

• Технический проект

• Рабочая документация

Допускается исключать стадию «Эскизный проект» и отдельные этапы

работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая

документация» в одну стадию «Технорабочий проект». В зависимости от

специфики создаваемых АС и условий их создания допускается выполнять

отдельные этапы работ до завершения предшествующих стадий, параллельное

во времени выполнение этапов работ, включение новых этапов работ.

Пользовательская документация

Пользовательская документация ИС (user documentation) объясняет

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

разрабатываемую ИС. Она необходима, если ИС предполагает какое-либо

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

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

инсталляции ИС (при установке ИС с соответствующей настройкой на среду

применения ИС), при применении ИС для решения своих задач и при

управлении ИС (например, когда разрабатываемое ИС будет

взаимодействовать с другими системами). Эти документы частично

затрагивают вопросы сопровождения ИС, но не касаются вопросов, связанных

с модификацией программ.

В связи с этим следует различать две категории пользователей ИС:

ординарных пользователей и администраторов. Ординарный пользователь

(end-user) использует ИС для решения своих задач (в своей предметной

области). Это может быть инженер, проектирующий техническое устройство,

или кассир, продающий железнодорожные билеты с помощью ИС. Он может и

не знать многих деталей работы компьютера или принципов

программирования. Администратор (system administrator) управляет

использованием ИС ординарными пользователями и осуществляет

сопровождение ИС, не связанное с модификацией программ. Например, он

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

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

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

как часть в другую систему.

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

пользователей, на которые ориентирована разрабатываемая ИС, и от режима

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

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

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

существенно зависит от точного определения аудитории, для которой он

379

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

информацию, необходимую для каждой аудитории.

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

определяющий, каким образом используется этот документ. Обычно

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

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

уточнения некоторой информации (использование в виде справочника).

Можно считать типичным следующий состав пользовательской

документации для достаточно больших ИС:

Общее функциональное описание ИС. Дает краткую характеристику

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

которые должны решить, насколько необходимо им данная ИС.

Руководство по инсталяции ИС. Предназначено для администраторов ИС.

Оно должно детально предписывать, как устанавливать системы в

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

считываемого носителя, на котором поставляется ИС, файлы,

представляющие ИС, и требования к минимальной конфигурации

аппаратуры.

Инструкция по применению ИС. Предназначена для ординарных

пользователей. Содержит необходимую информацию по применению ИС,

организованную в форме удобной для ее изучения.

Справочник по применению ИС. Предназначен для ординарных

пользователей. Содержит необходимую информацию по применению ИС,

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

деталей.

Руководство по управлению ИС. Предназначено для администраторов ИС.

Оно должно описывать сообщения, генерируемые, когда ИС

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

администратор на эти сообщения. Кроме того, если ИС использует

системную аппаратуру, этот документ может объяснять, как сопровождать

эту аппаратуру.

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

создания внешнего описания. Качество этой документации может существенно

определять успех ИС. Она должна быть достаточно проста и удобна для

пользователя (в противном случае это ИС, вообще, не стоило создавать).

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

создаются основными разработчиками ИС, к созданию их окончательных

вариантов часто привлекаются профессиональные технические писатели (см.

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

разработан ряд стандартов, в которых предписывается порядок разработки

этой документации, формулируются требования к каждому виду

пользовательских документов и определяются их структура и содержание.

380

Документация по сопровождению

Документация по сопровождению ИС (system documentation) описывает

ИС с точки зрения ее разработки. Эта документация необходима, если ИС

предполагает изучение того, как оно устроена (сконструирована), и

модернизацию его программ. Как уже отмечалось, сопровождение − это

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

ИС к этой работе привлекается специальная команда разработчиков-

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

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

(основных) разработчиков ИС, − с той лишь разницей, что эта документация

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

создавалась другой командой). Чтобы понять строение и процесс разработки

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

изучить эту документацию, а затем внести в нее необходимые изменения,

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

которых создавалось первоначальное ИС.

Документация по сопровождению ИС можно разбить на две группы:

• документация, определяющая строение программ и структур данных ИС

и технологию их разработки;

• документацию, помогающую вносить изменения в ИС.

Документация первой группы содержит итоговые документы каждого

технологического этапа разработки ИС. Она включает следующие документы:

• Внешнее описание ИС (Requirements document).

• Описание архитектуры ИС (description of the system architecture), включая

внешнюю спецификацию каждой ее программы (подсистемы).

• Для каждой программы ИС − описание ее модульной структуры, включая

внешнюю спецификацию каждого включенного в нее модуля.

• Для каждого модуля − его спецификация и описание его строения (design

description).

• Тексты модулей на выбранном языке программирования (program source

code listings).

• Документы установления достоверности ИС (validation documents),

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

ИС и как информация об установлении достоверности связывалась с

требованиями к ИС.

Документы установления достоверности ИС включают, прежде всего,

документацию по тестированию (схема тестирования и описание комплекта

тестов), но могут включать и результаты других видов проверки ИС, например,

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

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

Документация второй группы содержит руководство по сопровождению

ИС (system maintenance guide), которое описывает особенности реализации ИС

(в частности, трудности, которые пришлось преодолевать) и как учтены