Учебное пособие ПИС

21

22

Информация, приведенная в таблице 2.2 не является полной, однозначной и применимой для всех Заказчиков. Эта информация содержит лишь перечень наиболее распространенных рисков, которые могут серьёзно осложнить планирование, сроки, стоимость и управляемость процесса проектирования, если их проигнорирует руководитель проекта от Разработчика. Приведенные сведения указывают на наличие этих рисков, но необязательно это может отрицательно повлиять на процесс проектирования. В каждом конкретном случае необходимо оценивать каждый риск, и при переговорах с Заказчиком ставить задачи по снижению влияния факторов риска на результат проектирования.

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

23

Internet-канала, повышения квалификации системного администратора Заказчика или установки средств дистанционного администрирования.

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

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

Основными действиями собственных IT специалистов Заказчика при подготовке к автоматизации является выполнение работ стадии 1

ГОСТ 34.601-90:

-обоснование необходимости автоматизации;

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

-формирование первоначальных требований.

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

-соответствие по специализации;

-количество специалистов;

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

-цены за типовые операции по проектированию;

-опыт работы по специализации (лет);

-отчет собственного IT подразделения об анализе концепции автоматизации предложенной Разработчиком;

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

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

-гарантийные и послегарантийные предложения Разработчика;

24

- количество «знаков подтверждения качества» (сертификатов дипломов, соответствие региональным, национальным или международным стандартам качества).

2.4 Формирование требований к автоматизированной системе

Формирование требований к ИС – представляет собой предварительный комплекс работ направленный на сбор сведений для подготовки обоснованного предложения о необходимости и реализуемости создания информационной системы, а также это начальный этап по сбору информации для подготовки Технического задания. Главным результатом этих работ является документ «техникоэкономическое обоснование» (ТЭО).

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

Началом формирования требований к ИС является изучение объекта Заказчика.

Первым этапом является составление структурной схемы объекта по состоянию на текущий момент. Структурная схема составляется в графическом и текстовом виде. Даже при автоматизации части предприятия Заказчика, необходимо составление полной схемы предприятия. Это позволит увидеть роль объекта автоматизации как части всего предприятия и взаимосвязи с другими частями предприятия. При составлении структурной схемы объекта следует также уделить внимание взаимодействию объекта с внешней средой. Более подробно о составлении структурных и функциональных схем описано далее – в разделе 2.6.

В комментариях к схеме объекта необходимо указать для каждого элемента структуры:

-полные названия всех элементов структуры;

-реальное месторасположение;

-описание назначения и основных характеристик;

-результаты функционирования (состав, объем и качество);

-описание взаимосвязей с другими элементами.

Участки, которые предполагается автоматизировать и связанные с ними необходимо комментировать максимально подробно и тщательно.

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

25

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

Второй этап – это составление схемы информационных потоков, на основе и со ссылками на структурную схему предприятия.

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

Внутренние информационные потоки циркулируют между объектами структурной схемы объекта.

Внешние информационные потоки показывают движение информации между автоматизируемым объектом и другими связанными с ним объектами.

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

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

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

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

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

26

В результате изучения или восстановления документации на существующую ИС сотрудник Разработчика должен представлять ее структуру и функционирование в достаточном для объективного анализа объеме.

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

-назначение, состав и основные функции существующей ИС;

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

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

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

-качественные и количественные характеристики работы ИС, которые предстоит улучшить в новой ИС;

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

-возможность поэтапной или поэлементной замены существующей ИС на новую ИС.

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

Основными показателями проектирования являются:

-ориентировочная общая стоимость проекта;

-период времени от момента начала проектных работ до начала ввода систему в режим рабочей эксплуатации;

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

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

-распределение работ между сотрудниками Разработчика и собственными IT-специалистами заказчика;

27

- срок окупаемости проекта и др.

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

Основными результатами обследования объекта является:

-первоначальный перечень требований к разрабатываемой

системе;

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

-технико-экономическое обоснование проекта автоматизации. Целью ТЭО является определение показателей и их

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

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

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

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

вТЭО, является:

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

-средняя величина потерь предприятия из-за ошибок в результате «человеческого фактора», сбоев устаревших технических средств и ПО;

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

-затраты на обслуживание существующей ИС;

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

28

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

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

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

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

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

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

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

-повышение имиджа предприятия с точки зрения клиентов и партнеров и др.

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

Основной целью составления ТЭО является предоставление руководителю Заказчика, для принятия решения, информации о необходимости и окупаемости проведения автоматизации.

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

иоплачена как отдельная работа под названием, например: «аудит менеджмента предприятия» или «составление модели бизнес процессов».

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

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

29

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

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

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

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

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

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

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

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

Структура и оформление технического задания устанавливается стандартом ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» [4].

Целями составления технического задания являются:

-формализация модели и всех требований к создаваемой системе;

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

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

системы;

30