2. Фаза «Создание»

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

1. Приказ о начале работ

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

• Легализация пребывания представителей разработчика на объек­те автоматизации.

• Доступ к необходимой информации.

• Организация рабочего места.

• Лояльность должностных лиц и персонала.

Наиболее приемлемой формой решения отмеченных и многих других вопросов считается подписание руководителем предприятия-заказчика так называемого «Приказа о начале работ». Этим приказом работники предприятия информируются о сроках, целях и задачах создания АС; на­значается генеральный конструктор АС со стороны заказчика¹⁷; раздают­ся поручения об оказании содействия представителям разработчика и ор­ганизации их пребывания на объекте автоматизации, а также назначают­ся ответственные за решение конкретных задач; определяются меры стимулирования участников создания АС и т. п. Ввиду специфичности содержания этого приказа разработчик должен участвовать в разработке его проекта. Отметим настоятельную необходимость разъяснить руково­дителям предприятия важность этого приказа для достижения целей соз­дания АС.

2. Дополнительное обследование объекта автоматизации

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

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

Цели и задачи обследования объекта автоматизации

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

Углубленное обследование объекта на фазе «Создание» существенно отличается от экспресс-обследования, проводимого на фазе «Обоснова­ние», по следующим признакам:

1. Легитимность разработчика.

2. Объем. Объект обследования локализуется техническим заданием на АС.

3. Длительность обеспечивает полноту собранных данных и ка­чество их анализа.

4. Глубина достаточная для построения аде­кватной модели создаваемой АС.

5. Документирование в виде отчетов становятся источником аналитической информации для разработчика и для руководства предприятия.

Важными задачами углубленного обследования считаются:

• Выявление нормативной базы функционирования объекта.

• Выявление организационной структуры объекта автоматизации.

• Изучение положений о подразделениях и должностных инструк­ций.

• Выявление функциональной структуры объекта автоматизации.

• Оценка использования информационных и коммуникационных технологий.

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

• Выявление алгоритмической базы автоматизируемых функций.

• Описание технологических процессов обработки данных. По каждому регулярному технологическому процессу выясняются:

• источники и получатели информации;

• носители информации;

• используемые методы (способы, алгоритмы) обработки данных;

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

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

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

• используемые каналы передачи данных;

• применяемые технические средства обработки данных.

Собранная информация формализуется и фиксируется в виде графи­ческих схем технологических процессов обработки данных, обеспечи­вающих наглядность отображения и облегчающих анализ и оптимизацию этих процессов. Для составления схем может использоваться любая гра­фическая нотация, но наиболее удобны символика схем алгоритмов, про­грамм, данных и систем (ГОСТ 19.701-90) и нотация IDEF0 (РД IDEF0-2000), чаще всего применяемые разработчиками АС. Несомненным дос­тоинством схем технологических процессов, составленных с применени­ем символики ГОСТ 19.701, считается их наглядность и прозрачность даже для неспециалистов в области информационных технологий. В то же время для составления, анализа и оптимизации IDEFO-диаграмм соз­даны и широко применяются многочисленные программные продукты, в том числе BPWin, «БИГ-структуризатор», IDEFO/EMTool, MS Visio и другие. Примеры схем технологических процессов представлены на рис. 4.1 и рис. 4.2.

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

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

Отчет о результатах обследования

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

В конструктивной части отчета уточняются задачи и цели создания автоматизированной системы, детализируются положения технического задания на АС, а в необходимых случаях — обосновывается целесообраз­ность изменения или дополнения этого документа. Но и без изменения ТЗ кон­структивная часть отчета по обследованию становится основой для эс­кизного и технического проектирования автоматизированной системы.

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

3. Эскизное проектирование

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

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

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

• Обобщенный (укрупненный) характер решений.

• Многовариантность решений.

• Возможность исследования эффективности рассматриваемых ва­риантов.

■ Краткость описания.

Эскизное проектирование оригинальной АС

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

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

2. Изменение организационной структуры предприятия. Направления изменений органи­зационной структуры:

а) сокращение конкретных рабочих мест;

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

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

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

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

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

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

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

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

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

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

Эскизное проектирование АС на базе типовых проектных решений

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

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

Анализ, документирование и согласование эскизных проектных решений

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

Экономический критерий характеризует стоимость реализации предложенного решения.

Технологический критерий определяет сложность реализации и ос­воения предлагаемого решения.

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

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

Документирование результатов эскизного проектирования, как прави­ло, не вызывает затруднений. Согласно ГОСТ 34.201, единственным специфическим проектным документом этой стадии считается «По­яснительная записка к эскизному проекту». Нормативная докумен­тация не устанавливает никаких требований к составу и содержанию записки, поэтому разработчик может самостоятельно выбирать сте­пень детализации и объем описания предлагаемых решений.

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

4. Техническое проектирование

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

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

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

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

Специфические особенности технического про­ектирования:

• Итерационный характер.

• Детализация описания технических решений должна быть достаточной для их последующей реализации.

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

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

а) общая грамотность;

б) минимальное использование синонимов для обозначения одних и тех же понятий;

в) отказ от псевдопрофес­сионального жаргона (сленга);

г) корректное применение специализи­рованной терминологии предметной области пользователя.

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

Этапы технического проектирования

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

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

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

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

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

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

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

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

Ниже приводится более подробное описание состава и содержания работ каждого упомянутого этапа.