Взаимодействие IT-специалистов и персонала управления при создании и эксплуатации информационных систем (Л. Еремин, "Финансовая газета", N 27, 28, 29, июль 2005 г.)

Взаимодействие IT-специалистов и персонала управления при создании и
эксплуатации информационных систем

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

Причем, если рассматривать проблему эффективности внедрения и эксплуатации информационных систем (ИС) с этих позиций, то необходимо выделить две ее составляющие:

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

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

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

Что касается содержательной стороны предмета общения руководителей и IТ-специалистов, то и она имеет определенные нюансы.

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

Таким образом, реально эффективность решения задачи совершенствования ИС при всей своей сложности и многогранности в первую очередь определяется профессионализмом в сфере бизнеса аппарата управления и только затем уже - уровнем их компетентности в области ИТ. В связи с этим топ-менеджеры компаний, в которых внедряются новые ИС, должны четко представлять место и задачи специалистов управления в реализации этапов ЖЦ ИС, реально оценивать и свои возможности, и возможности разработчика и исходя из этого обоснованно и правильно формулировать требования к разрабатываемой системе.

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

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

Для детального анализа путей решения всего спектра указанных проблем представляется целесообразным все точки сопряжения специалистов управления и IT-специалистов рассматривать в рамках реализации этапов ЖЦ ИС (рис. 1).

Стадия жизненного цикла ИС		Предпроектная		Проектирование и разработка ИС		Внедрение и эксплуатация
Этапы и проводимые работы		Принятие решения о создании ИС	Предпроектное обследование	Разработка технического проекта	Разработка рабочего проекта	Приемо- сдаточные испытания	Опытная эксплуатация	Приемо- сдаточные испытания	Промышленная эксплуатация
Документация		/-------\ | ТЭО |----- \-------/	/------\ | ТЗ |----- \------/	|/------\ || ТП |--- |\------/ |/----------- || Техно-р || про |\-----------	/------\| | РП ||- \------/| ---------\| бочий || кт || ---------/|	/-------\ --| Акт | \-------/	--------	/-------\ | Акт | \-------/
Роль специалиста управления реализации этапа	Высшего звена	++++	++	+	+	+	++++	+	++++
	Среднего звена	+	+++	+++	+++	+++	+++	++	+++
	Нижнего звена	+	+	++	++	+	+	+++	+
Роль консультантов- экспертов		+++	+++	+++	+++	+(-)	+++	+(-)	+++

Рис. 1. Структура жизненного цикла информационной системы (стадии,
этапы, работы, виды документов и роль специалистов управления и
экспертов-консультантов)

Условные обозначения:

Степень участия (ответственности) в реализации этапа ЖЦ ИС:

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

+ + + - высокая, + - низкая, (-) - отсутствует

Предпроектная стадия

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

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

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

какие затраты потребуются для разработки, реализации и поддержания ИС (с учетом специфики направлений этих затрат);

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

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

Для получения максимально объективных характеристик по различным позициям оценки ИС также можно прибегнуть к услугам независимых экспертов-консультантов по вопросам применения информационных технологий.

Далее на данном этапе определяется общая концепция организации программно-аппаратной платформы ИС.

Как показывает практика, при разработке ИС выбор поставщика аппаратной платформы, как правило, не вызывает особых проблем, чему в значительной мере способствовал принцип открытой архитектуры, обеспечивающий простоту компоновки различных конфигураций аппаратной части информационных систем различных производителей, а также возможность ее дальнейшей модернизации (upgrade).

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

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

MB - "market to book", т.е. соотношение между рыночной (биржевой) стоимостью компании и ее балансовой стоимостью, причем положительным фактором в этом случае служит значение МВ, большее чем 1.

ROE - "return on equity", или рост акционерного капитала и доходы на акцию.

Между показателями МВ и ROE для всех областей ИТ характерна достаточно сильно выраженная линейная зависимость - более высокое ROE влечет за собой более высокое МВ. Но особенно важно при выборе фирмы информационной сферы то, что, если ее ROE составляет:

до 5% - она принадлежит к отстающей группе;

от 5 до 20% - находится на среднем уровне;

свыше 20% - успешно развивается.

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

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

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

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

Таким образом, конечным результатом всех перечисленных мероприятий по оценке софтверных фирм и их программной продукции, осуществляемой в процессе взаимодействия ИT-специалистов (как правило, независимых экспертов по информационным технологиям) и специалистов управления, представляющих организацию-заказчика, на этом этапе ЖЦ ИС являются:

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

получение технико-экономического обоснования (ТЭО) по принимаемому решению о создании ИС;

выбор соответствующей организации-разработчика и поставщика софта.

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

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

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

Поэтому грамотно составленное (с учетом оговоренной возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком ТЗ является одним из основополагающих документов проекта ИС.

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

На данном этапе IT-консультант играет важную роль, от его компетентности и опыта в первую очередь будут зависеть качество подготовленного ТЗ, а следовательно, в значительной мере и качественный уровень создаваемой ИС. Поэтому вместо приведенного примера ИТ-консультант должен сформулировать требование примерно следующим образом:

"ПО должно обеспечивать:

- систему "отката" не менее чем на *** шагов (здесь указывается конкретное количество шагов, обычно это 3-4 шага возврата по восстановлению предыдущего состояния системы, либо отмечается, что конкретное количество будет оговорено на последующих этапах ее разработки);

- поддержку системы иерархических меню;

- защиту от любых непрофессиональных действий пользователя;

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

- пресечение и фиксацию всех попыток выполнения несанкционированных действий со стороны пользователей;

- защиту от доступа и фиксацию всех попыток съема и искажения (изменения) информации извне системы;

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

- функции экспорта-импорта информации между программными системами (далее перечисляются программные системы общего и специального назначения, с которыми необходимо иметь общие форматы представления данных);

и лишь в завершении формулируется требование в самом общем виде:

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

Кроме того, к услугам независимых экспертов в области ИТ следует прибегать для получения более объективной оценки стоимости и возможных сроков разработки и реализации предполагаемого проекта ИС.

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

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

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

Включение в состав рабочей группы представителей заказчика должно быть подкреплено соответствующей мотивацией. Если разработчик заинтересован в быстром завершении работ, поскольку расчеты с ним осуществляются по конечным результатам, то представители заказчика, задействованные в создании и внедрении ИС, оказывают явное или скрытое сопротивление, так как эта работа выходит за рамки выполнения их обычных обязанностей. В таких случаях руководитель предприятия помимо ведения разъяснительной работы с сотрудниками должен материально заинтересовать их к освоению ИС. Обычно это реализуется в виде ежемесячных доплат (надбавок) к основной зарплате "за усложнение характера работ" и/или денежных премий специалистам организации-заказчика, входящим в группу внедрения, по результатам завершения отдельных этапов работ по подготовке и внедрению проекта ИС.

Целесообразность включения в состав группы внедрения специалистов своих собственных служб (и в первую очередь функциональных) при условии обеспечения их заинтересованности в конечных результатах обусловливается главным образом следующими факторами:

сокращаются сроки (а следовательно, и затраты) на проведение работ по подготовке и внедрению новой ИС;

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

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

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

Для этих целей лучше всего подходят методы и средства информационного моделирования процессов управления, т.е. информационные модели (ИМ), главное предназначение которых заключается в отражении в формализованном виде различных аспектов реализации ИС системы управления.

Под ИМ понимается формализованное представление различных аспектов управления как процессов сбора, передачи и обработки данных посредством отображения сведений о документах и маршрутах их движения, о показателях и связях между ними, о процедурах их формирования, функциях управления и аппарате, реализующем эти функции.

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

Информационные модели

       |                 |                   |                   |

/--------------\   /------------\ | /----------------\    /-------------\

|   Средство   |   |  Средство  | | |    Средство    |    |  Средство   |

|формализован- |   |формализации| | |   реализации   |    |моделирования|

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

|  и анализа   |   | разработки | | |      ных       |    |альтернатив- |

| существующей |   |компонентов | | | управленческих |    |ных вариантов|

|    и/или     |   |     ИС     | | |   процессов    |    |управленчес- |

|создаваемой ИС|   |            | | |                |    | ких решений |

\--------------/   \------------/ | \----------------/    \-------------/

/-------------------------------\ | /-----------------------------------\

|Этап разработки  и внедрения ИС| | |        Этап эксплуатации ИС       |

\-------------------------------/ | \-----------------------------------/

Рис. 2. Основные направления использования ИМ на различных этапах
жизненного цикла информационной системы

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

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

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

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

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

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

Таким образом, соответствующие ИМ становятся источником исходных данных, необходимых для специалистов, обеспечивающих информационную безопасность ИС. Это позволяет контролировать деятельность собственного персонала организации, в результате которой возможны искажения и "утечка" информации, и предоставлять ему возможность работать исключительно с той информацией и в рамках тех полномочий, которые необходимы для выполнения служебных обязанностей, а также фиксировать все несанкционированные попытки выйти за рамки установленных полномочий.

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

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

	Документ 1				Документ N
	показатель 11	показатель 21	...	показатель Z1	...	показатель 1N	...	показатель ZN
Пользователь "1"
Пользователь "2"
...
Пользователь "I"
...
Пользователь "M"

Стадия проектирования и разработки ИС

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

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

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

выполняется сортировка информации по определенным ключевым признакам (без описания самого алгоритма сортировки);

осуществляется передача информации (без конкретизации выполняемых действий);

организуется хранение информации (без интерпретации специфики реализации на физическом уровне) и т.п.

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

Этап рабочего проектирования*(1). Заключительным этапом разработки (создания) системы является этап рабочего проектирования, главная цель которого - реализация программных компонентов ИС и их увязка в систему, а также подготовка соответствующей проектной и эксплуатационной документации.

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

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

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

Стадия внедрения и эксплуатации

Этап приемо-сдаточных испытаний. Внедрение разработанной системы представляет процесс постепенного перехода от существующей ИС к эксплуатации новой. Он разделяется на два самостоятельных этапа: опытную и промышленную эксплуатацию. Каждому этапу внедрения в эксплуатацию предшествуют приемо-сдаточные испытания, на которых в соответствии с требованиями ТЗ последовательно осуществляются:

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

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

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

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

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

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

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

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

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

Целями работ, выполняемых на этапе опытной эксплуатации, являются:

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

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

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

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

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

Л. Еремин,

доцент кафедры ИТ Финансовой академии

при Правительстве Российской Федерации

"Финансовая газета", N 27, 28, 29, июль 2005 г.

-------------------------------------------------------------------------

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