6.3. Стадии и этапы проектирования экономических информационных систем.

МЕСТО И РОЛЬ СПЕЦИАЛИСТА УПРАВЛЕНИЯ В РЕАЛИЗАЦИИ ЭТАПОВ ЖИЗНЕННОГО ЦИКЛА ИС

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

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

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

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

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

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

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

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

специалистов управления и экспертов-консультантов) Степень участия (ответственности) в реализации этапа ЖЦ ИС: + + + + — очень высокая; + + + — высокая; + + — средняя; + — низкая; + (-) — низкая или отсутствует; - отсутствует.

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

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

В то же время выбор программного обеспечения, а также фирм — разработчиков ПО имеет принципиальное значение. Не­даром, как отмечают эксперты в области информационных техно­логий, выбирая «софт» — мы выбираем фирму-производителя. При этом очевидно, что, хотя создаваемые по индивидуальному заказу ИС потенциально могут обладать более высокими качественными характеристиками и иметь более высокую экономическую эффек­тивность, тем не менее, не имеет смысла осуществлять индивиду­альные разработки тех программных компонентов ИС, которые носят универсальный характер, имеются на рынке софта и доста­точно хорошо себя зарекомендовали. Однако и в этом случае по­мимо оценки надежности софтверной фирмы-партнера целесооб­разно предварительно оценить предполагаемый для приобретения программный продукт. Причем наряду с анализом функционально-технологических критериев на соответствие требованиям заказчи­ка даже применительно к российским условиям программный продукт может (а в принципе, и должен) быть оценен и по другим критериям. Так, например, на выбор любой IT-продукции огром­ное влияние оказывает состояние ЖЦ, на котором она находится. Причем наиболее объективные оценки могут быть получены при рассмотрении ЖЦ в системе рыночных координат «покупатель-поставщик». Кроме того, на выбор прикладного программного обеспечения могут повлиять результаты различных конкурсов, проводимых по различным номинациям специализированными фирмами, журналами и т.п. Выбор качественного программного обеспечения и определение степени надежности фирмы — произ­водителя ПО — ответственный момент, так как любая ошибка в решении этих вопросов чревата огромными безвозвратными поте­рями сил, средств и времени. В связи с этим на практике исполь­зуется целый арсенал различных методов, позволяющих сделать этот выбор вполне обоснованным. В частности, на Западе для этих целей используются такие рыночные показатели оценки IT-компаний, как, например, MB и ROE.

Показатель MB (market to book) представляет собой соотношение между рыночной (биржевой) стоимостью компании и ее балансо­вой стоимостью, причем положительным фактором в этом случае служит значение MB, большее единицы.

Другой показатель — ROE (return on equity) показывает рост ак­ционерного капитала и доходы на акцию.

Между показателями MB и ROE для всех областей ИТ имеется достаточно сильно выраженная линейная зависимость — более высокое ROE влечет за собой более высокое MB. При выборе фирмы информационной сферы особенно важно учитывать, что если ее ROE до 5%, она принадлежит к отстающей группе; от 5 до 20% — это фирма среднего уровня; свыше 20% — это процвета­ющая фирма.

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

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

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

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

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

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

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

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

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

Обычно такой отказ от разработки ИС силами собственных IT-специалистов объясняется тем, что:

• во-первых, не имеет смысла держать в штате большой постоян­ный состав высококвалифицированных специалистов — разработчиков ИС;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 6.3. Основные направления использования ИМ на различных этапах ЖЦ ИС

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

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

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

Рис. 6.4. Иллюстрация взаимосвязи между матричными и граф-моделями

Следует отметить, что в связи с внедрением различных CASE-средств (Computer Aided System/Software Engineering) в последнее время особенно популярными стали методы моделирования, ба­зирующиеся на графической интерпретации различных аспектов реализации управленческих процессов. Это, например, методы: SADT (Structured Analysis and Design Technique), DFD (Data Flow Diagrams), ERD (Entity-Relationship Diagrams), STD (State Transition Dia­grams) и др., изобразительные средства которых по своей сути пред­ставляют не что иное, как специфические граф-модели, имеющие заранее определенную (регламентированную) смысловую нагрузку и правила изображения узлов и дуг графа.

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

Управление

Механизм

Рис. 6.5. Графическая схема основных конструктивных элементов, используемых для построения DFD-моделей

Наконец, матричные модели и граф-модели обладают большой гибкостью (в плане приспособления к новым способам организа­ции технологических процессов обработки информации). Так, например, с появлением возможности организации электронного документооборота традиционные матричные информационные модели (матрицы смежности «исполнитель—документ», «испол­нитель—показатель» и т.п.), используемые для описания характера обработки исполнителем (специалистом управления) отдельных документов и показателей, приобретают возможность отражения нового смыслового содержания, а именно — уровня информаци­онных полномочий (доступа к информации и характера работы с ней) различных специалистов управления. Это важно для обеспе­чения защиты информационной системы от любых попыток не­санкционированного воздействия со стороны собственного пер­сонала (чему в настоящее время начинают придавать все большее значение при создании ИС, особенно в крупных организациях). Для решения этой проблемы указанные информационные модели необходимо лишь увязать с ЖЦ документов, циркулирующих в организации.

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

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

Вместе с тем необходимо учитывать, что в общем виде граф, отражающий информационную систему организации, может пред­ставлять собой достаточно сложную разветвленную сеть, которая не обеспечивает необходимой наглядности представления о всех функциональных и структурных связях организации. Кроме того, в нем бывает чрезвычайно трудно выделить иерархические уровни в образовании той или иной информации. В связи с этим более целесообразно представить ИМ формирования и движения инфор­мации в подразделениях организации с помощью графа ярусно-параллельной формы (ЯПФ), узлы которого «привязаны» к опре­деленным уровням, или ярусам, отражающим специфику форми­рования документов.

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

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

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

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

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

санкционированные попытки выйти за рамки установленных пол­номочий.

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

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

Стадия проектирования и разработки ИС включает в себя два этапа — технического и рабочего проектирования.

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

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

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

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

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

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

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

Заключительным этапом разработки (создания) системы является этап рабочего проектирования, главная цель которого — реализация программных компонентов ИС и их «увязка» в сис­тему, а также подготовка соответствующей проектной и эксплуа­тационной документации. На практике часто рабочее про­ектирование начинается до завершения этапа технического проектирования.

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

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

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

Придавая важную роль специалистам управления в разработке ИС, известный специалист в области программирования Дж. Мар­тин (инициатор развития такого его направления, как «Програм­мирование без программистов») вообще предлагал, чтобы макет создавали не профессиональные программисты, а конечные поль­зователи. Это, по мнению Дж. Мартина, позволяет резко ускорить процесс создания первой версии, так как пользователю значитель­но проще самому сделать первый, пусть далеко и не лучший, про­тотип будущей программы, чем пытаться объяснить программисту требования к такой программе. Естественно, что для этого поль­зователь — специалист управления должен иметь соответствующие инструментальные средства поддержки процесса создания таких прототипов. В качестве наиболее распространенного средства в настоящее время может выступать табличный процессор Excel.

На практике метод прототипирования нашел свое дальнейшее развитие а виде RAD-технологий (Rapid Application Development — ускоренная разработка приложений). Главное отличие RAD-технологий от простого прототипирования (когда прототипы ис­пользовались исключительно только для устранения неясностей в проекте, а затем просто игнорировались) заключается в том, что методология RAD-технологий предусматривает накопление прото­типов, их развитие и дальнейшее использование уже как части конечной системы.

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

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

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

И здесь особую роль также сыграет независимая экспертиза, поскольку могут быть привлечены консультанты-эксперты, име­ющие опыт работы с подобными системами. Причем следует иметь в виду, что привлечение в качестве консультантов тех же самых специалистов, которые участвовали в выборе разработчика (по­ставщика) системы, нежелательно, так как они, скорее всего, будут стремиться всячески сгладить возникающие противоречия между заказчиком и исполнителем. Кроме того, в настоящее время в на­шей стране имеются центры независимого тестирования програм­мной продукции. Например, компания «АйТи» оказывает услуги в проведении полномасштабной комплексной проверки программ­ных компонентов информационных систем с использованием спе­циализированных программных средств тестирования на базе тех­нологий такого мирового лидера в этой сфере софтверного бизне­са, как компания Rational Software Corp.

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

Данный этап — наиболее ответственный и наиболее «жесткий» в плане взаимодействия специалистов управления IT-специалистов — представителей разработчика. В противном случае заказчик может получить не просто систему с отдельными недоработками, но и вообще непригодную к эксплуатации.

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

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

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

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

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

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

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