39

II. ОРГАНИЗАЦИОННО- ТЕХНИЧЕСКИЕ ПРОБЛЕМЫ СОЗДАНИЯ БД

Проблемы создания БД

Организация проектирования

Принципы проектирования

Рекомендации по созданию БД

Любая информация становится бесполезной, если ее невозможно получить своевременно.

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

Билл Гейтс, глава компании Microsoft

Проблемы создания БД

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

Информационные системы, созданные на основе БД, характеризуется следующими особенностями:

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

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

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

• необходимость интеграции существующих и вновь разрабатываемых приложений;

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

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

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

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

• противоречие целей заказчика и подрядчика;

• недостаточная вовлеченность заказчика работы по проектированию БД;

• противоречивые подходы к разработке требований;

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

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

• проблемы коммуникаций между заказчиком и подрядчиком;

• применение инструментов, не оправдавших ожиданий.

Следующие факторы влияют на развитие БД.

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

Подходы к технической и программной реализации компонент БД. Параллельно с развитием технических средств, происходит постоянный поиск новых более удобных и универсальных методов программно-технологической реализации БД. В связи с активным развитием телекоммуникационных сетей появляются все большие возможности работы с удаленными подразделениями, открываются широкие перспективы электронной коммерции, обслуживания покупателей через Интернет и многое другое. Несмотря на то, что разработчики программного обеспечения стараются поддерживать свои разработки в соответствии со всеми современными возможностями и стандартами при создании БД возникает много ошибок. Типичными ошибками при определении требований к БД являются :

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

• ошибки или неполнота описания бизнес-логики;

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

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

Шаги, ведущие к успеху по созданию БД:

• постановка цели, приносящей реальную пользу;

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

• причастность всех сотрудников предприятия к процессу создания БД на различных этапах ее создания.

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

Проваленные проекты, колоссальные потери времени и средств — типичная картина современной автоматизации крупных предприятий. Не спасают ни высокие технологии, ни продукты, ни авторитет известных фирм. Статистика провалов безжалостна и к проектам на базе готовых проектных решений, и к проектам заказных БД. До 15% всех программных проектов так и не достигают своего завершения. Превышение стоимости проектов на 100-200% является обычным явлением. Превышение стоимости на 30% в программной индустрии считается настоящим успехом.

Проблемами реализации проектов по созданию БД (по уровню влияния) являются [5]:

1. недостатки планирования производственных процессов;

2. недостаточность контроля за созданием БД;

3. закупка не эффективного оборудования;

4. помехи со стороны правительства;

5. технологические факторы;

6. внешние воздействия.

Эти проблемы связаны:

• недостаточным тестированием и плохой интеграцией программного обеспечения;

• ошибками проектирования системы;

• ошибками в планировании работ над проектом и некачественное внедрение;

• плохим управлением проектом;

• неверным выбором коммерческого программного обеспечения;

• неумение заключать договора.

Большинство неудач создания БД закладываются на первоначальных этапах их создания. Потому что разработчики имеют слабое представление о работе пользователей (и наоборот); представления разработчиков об этой фазе проектирования БД отличны от представлений об этом пользователей.

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

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

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

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

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

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

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

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

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

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

Главным принципом отбора информации является вопрос о том, кто и что с ней будет делать, для принятия каких решений она будет использована? Актуализацию информации необходимо производить по мере необходимости. В этой ситуации необходимо рассматривать весь цикл обработки информации: кто, где, когда будет собирать (или получать) информацию, проверять, вводить в компьютер, существуют ли ограничения доступа, как будут решаться вопросы информационной безопасности (безопасности информации и безопасности от неправильного ее использования), кто и когда будет потребителем (пользователем) БД, на каких условиях, характерные временные интервалы получения информации, предполагаемые объемы [4].

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

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

Р исунок 1 - Зависимость качества управления от ценности информации

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

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

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

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

• информация постоянно изменяется;

• используются слабые поисковые средства;

• поиск ведется по нечетким критериям;

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

• информация недоступна;

• нет навыков поиска информации.

Организация проектирования

Перед началом проектирования БД следует ответить на следующие вопросы:

• Какие функции возлагаются на БД, каково ее место среди других БД?

• Что необходимо для их создания (определить перечень работ) и функционирования?

• Какие необходимы организационно-технические мероприятия, материальные, временные и людские ресурсы?

• Какой эффект можно ожидать от создания БД?

При создании БД необходимо [1]:

• определить внешние и внутренние цели БД;

• выделить систему из среды, изучить отношения создаваемой БД с внешней средой;

• рассмотреть возможные подсистемы;

• прогнозировать поведение БД;

• описать информационные потоки в БД;

• выбрать методы управления её функционированием.

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

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

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

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

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

Рисунок 2 - Зависимость затрат от времени нахождения ошибок

Таблица 1 - Показатели различных подходов к автоматизации предприятий с использованием БД

Показатели подхода	Лоскутная автоматизация	СУБД	СУБД +ТПР
Адаптация к текущим условиям и организационной структуре предприятия	Есть	Нет, следование условиям проекта
Запаздывание работ во времени	Минимальное	Высокое	Среднее
Управляемость изменениями	Высокая	Низкая	Минимальная
Риск неудачи проекта	Низкий	Очень высокий	Высокий
Открытость системы для заказчика	Высокая	Минимальная	Определяется свойствами СУБД
Гибкость и оптимизация в управлении разработкой	Высокая	Низкая	Нет данных
Оптимизация технологических решений	Высокая	Средняя	Низкая
Доступность системы для заказчика	Высокая	Низкая	Низкая
Размерность работ (число шагов и время для достижения результата)	Минимальная	Высокая	Высокая
Единое терминологическое и понятийное пространство	Да, релевантный язык общения с пользователями	Нет, требуется подстраиваться под конкретный проект
Скорость адекватных изменений, вносимых в ИС	Средняя	Низкая	Низкая
Реактивность технологии создания/сопровождения	Максимальная	Низкая	Низкая
Разновидность вносимых изменений на разработку	Высокая	Средняя	Низкая
Преемственность и сохранность результатов этапов создания ИС	Максимальная.	Низкая.	Средняя
Потребность в техно-рабочей документации	Минимальная	Высокая	Высокая
Время создания требуемой документации	Минимальное	Максимальное	Малое
Время обучения пользователей	Минимальное	Среднее	Максимальное
Потребность в реструктуризации предприятия	Отсутствует	Отсутствует	Имеется
Потребность в информационно-технологической реструктуризации	Отсутствует	Средняя	Высокая.
Сложность в переходе от лоскутной автоматизации на «серьезную» систему	Высокая	Средняя	Высокая
Относительная стоимость	Низкая	Высокая	Средняя

При создании БД необходимо использовать ГОСТ 34.601-90 Информационные технологии. «Стадии и этапы создания Автоматизированной Системы», который определяет:

• Формирование требований к АС (обследование объекта);

• Разработка концепции АС (изучение объекта, разработка вариантов концепции АС);

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

• Эскизный проект;

• Технический проект;

• Рабочая документация;

• Ввод в действие;

• Сопровождение АС;

• Тестовые примеры;

• Проектную документацию;

• Исходные коды системы;

• Описание структуры БД системы;

• Шаблоны БД системы;

• Исполняемые модули системы;

• Документацию для пользователя;

• Документацию системного администратора;

• Документацию администратора БД;

• Документацию прикладного программиста;

• Документацию системного программиста;

• Пакеты презентаций и материалы демонстраций для заказчиков и пользователей;

• Протоколы испытаний;

• Результаты тестирования;

• Акты устранения замечаний.

Кроме ГОСТ 34.601-90 необходимо использовать:

• ГОСТ 34.201-89 Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем

• ГОСТ 34.602-89 Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

• ГОСТ 34.603-92 Виды испытаний автоматизированных систем

• РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

Этапы проектирования БД представлены на рис.3.