63385

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

Лекция

Информатика, кибернетика и программирование

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

Русский

2014-06-19

431 KB

0 чел.

PAGE  38

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.

Рисунок 3 - Этапы проектирования

Для подготовки документации используется система технической документации на АСУ (ГОСТ серии 24) и описание программного обеспечения (ГОСТ серии 19):

  •  ГОСТ 24.102-80 Обозначение документов
  •  ГОСТ 24.103-84 Автоматизированные системы управления. Общие положения
  •  ГОСТ 24.104-85 Автоматизированные системы управления. Общие требования  
  •  ГОСТ 24.201-79 Требования к содержанию документа «Техническое задание»
  •  ГОСТ 24.202-80 Требования к содержанию документа «Технико-экономическое обоснование»
  •  ГОСТ 24.203-80 Требования к содержанию общесистемных документов
  •  ГОСТ 24.204-80 Требования к содержанию документа «Описание постановки задачи»
  •  ГОСТ 24.205-80 Требования к содержанию документов по информационному обеспечению
  •  ГОСТ 24.206-80 Требования к содержанию документов по техническому обеспечению
  •  ГОСТ 24.207-80 Требования к содержанию документов по программному обеспечению
  •  ГОСТ 24.208-80 Требования к содержанию документов стадии «Ввод в эксплуатацию»
  •  ГОСТ 24.209-80 Требования к содержанию документов по организационному обеспечению
  •  ГОСТ 24.210-82 Требования к содержанию документов по функциональной части
  •  ГОСТ 24.211-82 Требования к содержанию документа «Описание алгоритма»
  •  ГОСТ 24.301-80 Общие требования к выполнению текстовых документов.
  •  ГОСТ 24.302-80 Общие требования к выполнению схем
  •  ГОСТ 24.304-82 Требования к выполнению чертежей
  •  ГОСТ 24.703-85 Типовые проектные решения. Основные положения.

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

Разработка концепции БД включает:

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

На этом же этапе определяются:

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

Создание БД включает:

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

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

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

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

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

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

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

В обобщенной форме переход от концепции к архитектуре БД представлен на рис.4.

Рисунок 4 – От концепции к архитектуре БД

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

В рамках проектирования БД (ТЗ, ТП, РП) должно быть осуществлено:

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

Технический проект должен включать:

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

Технический проект позволяет:

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

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

В рабочем проекте должны быть определены этапы и стадии выполнения работ по разработке, внедрению и сопровождению БД. На этапе разработки необходимо:

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

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

На этапе внедрения и настройки БД необходимы [2]:

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

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

На этапе сопровождения и дальнейшего развития БД необходимо:

  •  текущее администрирование БД;
  •  обучение пользователей;
  •  дальнейшая работа по модернизации БД.

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

Создание БД это сложный процесс, в котором участвуют команды заказчика и исполнителя, взаимодействие этих команд показано на рис.5.

Рисунок 5 - Взаимодействие команд заказчика и исполнителя [3]

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

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

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

В разработке приложений к БД могут участвовать «новички», «кодеры» и программисты.

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

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

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

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

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

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

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

Введение принципа непрерывности проектирования обусловлено длительностью проектирования БД, с одной стороны, и развитием техники, с другой стороны. Например, процесс развития системы обработки океанографических данных длится уже более 30 лет. За эти годы менялись решения, внедряемые в рамках создаваемой БД, ее элементы и техническая база, на которой строилась БД (трижды сменились поколения ЭВМ). Разработанные и предъявленные к сдаче подсистемы сбора данных в момент внедрения уже отставали от уровня развития техники. Так технология занесения данных на перфокарты существовала до 1985 г., а на УПДМЛ до 1995 г. Разработанная система занесения данных для ПЭВМ работала в ДОС до 2000 г. Кроме того, многие решения требуют своего улучшения по результатам опытной проверки. Например, оперативное обеспечение пользователей гидрометеорологической информацией по каналам связи внедрялось еще в начале восьмидесятых годов, но из-за высокой стоимости эксплуатации системы, недостаточной надежности техники (ЭВМ Единой Серии) от такого режима работы пришлось отказаться. Поэтому сразу после начала эксплуатации любой системы следует приступить к ее экспериментальной оценке и совершенствованию, что означает продолжение проектирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

Список литературы

  1.  Бойко В.В., Савинков В.М. Проектирование информационной базы на основе СУБД. – М.: Финансы и статистика. 1982. – 174 с.
  2.  Грекул В.И. Управление внедрением БД. - Интернет-университет информационных технологий - ИНТУИТ.ру 2008. Видеокурс. DVD-box: 2 диска.
  3.  Кайдалов А. Команда ИТ-проекта: как избежать проблем. [Электронный ресурс]. – Режим доступа: http://www.cnews.ru/reviews/articles/index.shtml?2005/06/20/180560_1, свободный. – Загл. с экрана.
  4.  Тиори Т., Фрай Дж. Проектирование структур БД. Кн. 1 и 2. - М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.
  5.  Хансен Гэри, Хансен Джеймс. Базы данных: разработка и управление: Пер. с англ. - М.: ЗАО "Издательство БИНОМ", 1999. - 704 с.

Перечень вопросов для самопроверки

  1.  Как можно обеспечить надежность хранения данных?
  2.  Назовите проблемы создания БД
  3.  Какие этапы проектирования необходимо выполнить?
  4.  Какие требования должны выставляться к создаваемой БД?


 

А также другие работы, которые могут Вас заинтересовать

51177. АСУ ТП технологического процесса «АСУ ТП технологического процесса теплообмена 78.31 KB
  Датчик давления Метран 55 предназначен для измерения давления жидкости в том числе агрессивных сред пара газа. Выпускают: а датчик для измерения избыточного давления – Метран 55 ДИ Метран55ЕхДИ – взрывозащищенное исполнение. Верхний предел измерений:01 МПа ÷ 100 МПа; б датчик для измерения давления разрежения – Метран 55 ДВ Метран55ЕхДВ – взрывозащищенное исполнение. Пределы измерений: 37 01 МПа ÷ 006 МПа; в датчик для измерения абсолютного давления – Метран55ДА...
51180. Изучение последовательного порта UART 33.85 KB
  Цели работы Изучить схему подключения микроконтроллера к компьютеру. Изучить особенности работы последовательного асинхронного порта UART. Освоить методику расчета скорости последовательного порта. Изучить особенности программирования UART. Изучить способы отладки программ на учебном лабораторном стенде LESO1.
51182. Банкет за столом с частичным обслуживанием с официантами на 30 персон по случаю Дня Рождения 512.5 KB
  Ресторан - предприятие общественного питания с широким ассортиментом блюд сложного приготовления, включая заказные и фирменные, вино-водочные, табачные и кондитерские изделия, с повышенным уровнем обслуживания в сочетании с организацией досуга.
51183. Изучение таймеров микроконтроллера 39.03 KB
  Цели работы Изучить особенности работы таймеров микроконтроллера. Изучить методику конфигурирования таймеров. Научиться формировать с помощью таймера временные интервалы. Изучить способы отладки программ на учебном лабораторном стенде LESO1.
51185. Работа с клавиатурой матричного типа 40.12 KB
  Цель работы Изучить особенности работы параллельных портов микроконтроллера. Изучить схемы подключения кнопок и матричной клавиатуры к микроконтроллеру. Научиться определять состояние кнопок при помощи программы.