СТАДИИ И ЭТАПЫ ПРОЕКТИРОВАНИЯ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ. МЕСТО И РОЛЬ СПЕЦИАЛИСТА УПРАВЛЕНИЯ В РЕАЛИЗАЦИИ ЭТАПОВ ЖИЗНЕННОГО ЦИКЛА ИС

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

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

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

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

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

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

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

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

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

специалистов управления и экспертов-консультантов)

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

+ + — средняя; + — низкая; + (—) — низкая или отсутствует; — — отсутствует.

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

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

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

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

20% — это фирма среднего уровня; свыше 20% — это процветающая фирма.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основная задача ИМ — это отражение в удобном для восприятия и обработки виде данных, характеризующих различные аспекты информационной системы объекта управления — от состава и компоновки ее структурных элементов до их информационных, алгоритмических и логических связей. В целом же диапазон использования ИМ на различных этапах жизненного цикла И С очень велик — от задач, связанных с разработкой и модернизацией ИС, до непосредственного применения ИМ в качестве инструмента самой ИС для информационной поддержки О/ЛР-техноло- гий, реализации процессов, связанных с альтернативным выбором возможных вариантов управленческих решений, обеспечением защиты информации и т.д. (рис. 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 Diagrams) и др., изобразительные средства которых по своей сути представляют не что иное, как специфические граф-модели, имеющие заранее определенную (регламентированную) смысловую нагрузку и правила изображения узлов и дуг графа.

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

Графическая схема основных конструктивных элементов, используемых для построения &Ш7-моделей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >