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

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

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

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

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

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

Разумеется, при интеграции новых блоков ПО, необходима их тщательна проверка и тестирование на модели системы. Также необходимо обязательно сохранять все предыдущие версии замененных фрагментов ПО, для выполнения «отката» в случае неудачного исхода замены.

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

Например:

-отопления/охлаждения помещений операторов;

-охлаждения комнаты размещения серверов;

81

-обеспечение стабильной подачи и номинальных характеристик электропитания;

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

относится к сопровождению. Это такие работы как:

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

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

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

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

Работы по сопровождению можно разделить на два вида:

-периодические плановые работы, требующие специалистов средней квалификации;

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

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

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

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

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

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

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

Это такие средства как:

82

-удаленный терминальный доступ сотрудников Разработчика к системе Заказчика через Internet,

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

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

врежиме переписки, телефонных и видеоконференций.

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

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

4 Документационное обеспечение проектирования ИС

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

Основные задачи ведения документации:

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

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

др.

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

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

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

83

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

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

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

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

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

-подготовительную документацию;

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

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

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

Основные виды документации предопределяются используемым стандартом проектирования. Так, основные виды документации для стандарта ГОСТ 34.60190 очевидны из перечня стадий и этапов.

Основными проектными документами по ГОСТ 34.601-90 являются:

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

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

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

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

- рабочая конструкторская документация - комплект конструкторских документов, разрабатываемый с целью изготовления и проведения испытаний опытного образца изделия, в том числе учебнотренировочных средств, специального технологического оборудования и оснастки, предназначенных для обеспечения эксплуатации, технического обслуживания и ремонта изделия в процессе эксплуатации, а также программной документации (ГОСТ РВ 15.203-2001).

84

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

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

Перечень основных документов при проектировании описан в ГОСТ 34.201-89, приведенный в Приложении №3. Однако на взгляд автора, он является неполным.

Ниже предложен примерный перечень документации при проектировании ИС осуществляемой в соответствии со структурой стадий изложенной в ГОСТ 34.60190.

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

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

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

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

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

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

-рекомендации для приказа руководителя предприятия - Заказчика

оназначении ответственного за работу с Разработчиком;

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

- окончательный текст Технического задания с листами согласования с контролирующими организациями и листами ознакомления всех относящихся к автоматизации сотрудников Заказчика;

-схема (диаграмма) и описание технологии проектирования данного проекта;

-расчет-обоснование себестоимости реализации проекта;

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

-план-график реализации подэтапов;

-смета или сметный расчет плановой стоимости проектирования;

-проект плана-графика финансирования проекта Заказчиком;

85

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

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

-план-график закрепления сотрудников и технических средств Разработчика по подэтапам проектирования;

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

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

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

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

-ведомость покупных изделий по ГОСТ 2.106;

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

-протокол проведения верификации и проверки разработанной

системы;

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

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

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

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

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

иизложения) – полное или общее описание системы;

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

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

-паспорт информационной системы;

-акт выполненных работ по проектированию ИС;

-акт приемки-передачи результатов проектирования Заказчику. Документация необходимая для дальнейшей эксплуатации

разработанной системы.

Документы для проведения работ по внедрению:

-договор на внедрение разработанной системы;

-примерный план-график этапов работ по внедрению системы;

-план-график проведения обучения и тестирования сотрудников Заказчика;

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

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

-план-график приемочного тестирования системы;

86

-лист учета рабочего времени сотрудников Разработчика при работе на объекте Заказчика;

-протокол и перечень замечаний по результатам приемочного тестирования;

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

-план-график пробной эксплуатации;

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

-акт выполнения работы по проектированию ИС.

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

-договор на проведение работ по сопровождению;

-план-график проведения контрольных и сервисных проверок

системы;

-журнал работ по сопровождению;

-лист учета рабочего времени сотрудников Разработчика при работе на объекте Заказчика.

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

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

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

июридическими нормами. Главными требованиями ко всем документам являются:

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

-наглядность;

-полнота изложенной информации;

-актуальность информации.

Содержание некоторых основных документов определяется стандартом РД 50-34.698-90 «Автоматизированные системы требования к содержанию документов».

5 Внутренняя стандартизация разработчика ИС

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

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

87

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

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

Эти внутренние стандарты можно разделить на следующие:

-стандарт проектирования;

-стандарт оформления проектной документации;

-стандарт пользовательского интерфейса;

-стандарт структуры управления;

-стандарт контроля качества.

Стандарт проектирования организовывает и объединяет каждого разработчика для работы в составе рабочей группы при совместной работе над проектом.

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

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

-правила фиксации проектных решений на моделях (диаграммах),

втом числе:

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

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

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

в) настройки программ управления проектом и внутреннего

общения;

г) средства доступа к внутренним и внешним информационно-справочным ресурсам;

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

числе:

а) правила интеграции подсистем проекта; б) правила поддержания проекта в одинаковом для всех

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

88

г) правила проверки проектных решений на непротиворечивость и т. д.

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

Стандарт оформления проектной документации должен устанавливать: - комплектность, состав и структуру документации на каждой стадии проектирования;

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

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

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

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

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

Стандарт интерфейса пользователя должен устанавливать:

-правила оформления экранов (шрифты и цветовая палитра)

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

-правила использования клавиатуры и мыши;

-правила оформления текстов помощи;

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

-перечень стандартных сообщений;

-правила обработки реакции пользователя.

Структура управления предприятием Разработчика представляет собой иерархическую схему постоянного и оперативного управления предприятием-Разработчиком ИС. Данная схема вырабатывается и устанавливается как один из внутренних стандартов.

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

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

89

структура обычно называется проектной (или рабочей группой). Пример структуры проектной группы показан на рисунке 4.2.

Генеральный

директор

Рисунок 4.1 – Пример структуры предприятия – разработчика ИС

90