Схема структуры программного обеспечения

Схема структуры программного обеспечения
Схема структуры программного обеспечения
Схема структуры программного обеспечения

20.03.2018


КИС :: Управление проектами

Дмитрий Апачёв,
департамент консалтинга ЗАО «Ай-Теко»

15 May 2007 г

Модель базы данных При автоматизации процессов ITSM (IT Service Management) одним из основных факторов, определяющих успешность проекта, является структура базы данных внедряемой системы. Структура БД может быть представлена в виде моделей данных различного уровня. В данной статье речь будет идти о следующих:
  • Концептуальная модель данных — записанные знания о физических и логических объектах реального мира (люди, компоненты инфраструктуры, наряды на работу, договора, соглашения и т. д.), которыми необходимо управлять наиболее рациональным образом.
  • Логическая модель данных — описание объектов предметной области, их атрибутов и взаимосвязей между ними в том объеме, в котором они подлежат непосредственному хранению в базе данных системы. Строится на основе концептуальной модели данных.
  • Физическая модель данных — способ хранения данных в конкретной СУБД. Строится на основе логической модели данных.

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

Как же оценить качество модели данных и функциональности, предназначенной для работы с ней? Для этих целей можно использовать набор критериев PinkVerify, разработанный организацией Pink Elephant (участницей разработки методологии ITIL) специально для самостоятельной оценки системы автоматизации процессов ITSM. Критерии эти предназначены для оценки совместимости структуры системы автоматизации с методологией ITIL и распространяются бесплатно (www.pinkelephant.com).

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

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

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

  1. Выбор организацией-заказчиком системы автоматизации.
  2. Подготовка и настройка системы автоматизации организацией-интегратором.
  3. Взаимодействие заказчика и интегратора в ходе внедрения системы автоматизации.
  4. Взаимодействие заказчика и интегратора по вопросам поддержки системы автоматизации.

В каждой области описание структуры БД обеспечивает свои преимущества. Рассмотрим их подробно.

  1. Выбор организацией-заказчиком системы автоматизации
    Преимущества:
    • возможность оценки всех аспектов системы, полнота информации
    • удобство анализа предлагаемой системы сотрудниками организации-заказчика
    Возможности системы автоматизации определяются ее моделью данных. В среднем 60% времени анализа одного коммерческого предложения прямо или косвенно тратится на оценку именно модели данных системы. Подробное описание не только функциональности системы, но и структуры БД позволяет потенциальному клиенту осуществить комплексный обзор возможностей системы, оперировать всей необходимой информацией и создает значительное конкурентное преимущество компании-интегратору. Отсутствие же описания структуры БД с большой вероятностью приведет к вынесению отрицательного решения по системе и, скорее всего, по интегратору, ее предлагающему, — невозможность составления законченного представления о возможностях системы серьезно снижает общее впечатление о потенциальном исполнителе проекта.
  2. Выполнение настройки и внедрение системы автоматизации организацией-интегратором
    Преимущества:
    • упрощение логического проектирования процессов
    • упрощение настройки системы
    • упрощение разработки интеграции с другими системами
    За редким исключением, в организациях-интеграторах доля сотрудников, имеющих представление о модели данных системы, невелика. Особенно если клиентам предлагается система автоматизации сторонних производителей. Ситуации же, в которых сотрудникам, не связанным с проектированием и разработкой БД, требуется информация о логической или физической модели данных, возникают довольно часто. Информационный вакуум, образующийся вследствие отсутствия или сложности использования источника такой информации, ведет к возникновению узких мест в работе команды проекта — потребности в информации не могут быть оперативно удовлетворены. Если же любой сотрудник может получить необходимые ему сведения самостоятельно, то подобных узких мест не возникает — работа всей команды становится более слаженной, качественной и эффективной. Упрощается работа бизнес-аналитиков, технических специалистов, настраивающих систему и проектирующих интеграцию, а также взаимодействие между ними.
  3. Взаимодействие организаций заказчика и интегратора в ходе внедрения системы автоматизации
    Преимущества:
    • ускорение обучения и понимания сотрудниками организации-заказчика особенностей работы с внедряемым инструментарием
    • увеличение конечной системы прозрачности
    • увеличение эффективности приемочного тестирования (опытной эксплуатации)
    Успешность внедрения системы, автоматизирующей процессы ITSM, равно как и сложность осуществления этого процесса, зависит от множества факторов. Одним из ключевых является уровень взаимопонимания между сотрудниками заказчика и исполнителя. Качественное описание модели данных позволяет исполнителю найти «общий язык» с заказчиком по вопросам, связанным с системой автоматизации и ее эксплуатацией. И чем быстрее будет найден такой язык, тем быстрее и легче будет проходить обучение пользователей, тем больше у них останется времени, чтобы вникнуть в особенности работы с внедряемым инструментарием, тем эффективнее пройдет опытно-промышленная эксплуатация и самые серьезные проблемы будут решены до окончательной сдачи системы.
  4. Взаимодействие организаций заказчика и интегратора по вопросам поддержки системы автоматизации
    Преимущества:
    • увеличение количества проблем, устраненных заказчиком самостоятельно
    • облегчение взаимопонимания при описании проблем
    • увеличение скорости устранения проблем
    Если взаимоотношения заказчика и исполнителя не ограничиваются рамками одного проекта и обе организации нацелены на длительное сотрудничество, то четкое описание модели данных системы позволяет сгладить многие острые углы и значительно упростить коммуникации на уровне технических специалистов. Обладая полной информацией о базе данных, администраторы системы со стороны заказчика в большинстве случаев в состоянии самостоятельно устранить ошибки данных, хранящихся в БД, избегая потерь времени на объяснение проблемы представителям организации-интегратора. Если же ситуация все-таки требует вмешательства специалистов интегратора, то знание логической и физической моделей представителями обеих сторон позволяет существенно сократить время, затрачиваемое на выяснение деталей возникшей ошибки. При устранении же проблемы специалистами интегратора описание структуры БД позволяет увеличить скорость обработки заявки, так как предоставляет заинтересованным лицам необходимую информацию по объектам и таблицам системы, что становится особенно полезным по прошествии некоторого времени с момента внедрения.

Как описывать структуру БД? Как же описать структуру БД, чтобы максимальное количество упомянутых выше преимуществ стало ощутимым? Требования к документу, описывающему базу данных системы автоматизации, можно объединить в следующие направления:
  • Структура документа
  • Информация об объекте и таблице
  • Оформление документа
  1. Структура документа
    Документ должен описывать как логическую, так и физическую модели. В большинстве систем автоматизации эти модели практически совпадают, поэтому вполне можно обойтись перечнем таблиц, для каждой из которых указывается название типа объекта, в ней хранящегося. Однако в некоторых системах логическая и физическая модели существенно отличаются. Происходит это по следующим причинам:
    • Некоторые таблицы хранят несколько типов объектов
    • Атрибуты одного типа объекта хранятся в нескольких таблицах
    • Объекты имеют много логических атрибутов, то есть их значения не хранятся сами по себе, а являются результатом агрегации данных из других таблиц
    В таких случаях описание структуры БД должно содержать два раздела:
    • Перечень типов объектов, их атрибутов и взаимосвязей
    • Перечень таблиц БД, их состав и взаимосвязи
    К документу может быть приложена графическая схема объектов и/или таблиц системы. Однако создание такой схемы, если оно не происходит автоматически, крайне трудоемко и не всегда целесообразно — при больших количествах таблиц и объектов схема теряет смысл, так как трудно воспринимается пользователем. Таким образом, включение схем объектов/таблиц в описание структуры БД имеет смысл только в случае относительно простых систем.
  2. Информация о таблицах и объектах
    От полноты информации, предоставляемой по каждой таблице БД и по каждому типу объектов, зависит ее полезность для пользователя системы. Описание типа объектов эффективнее организовать в виде перечня атрибутов объекта данного типа, а описание таблицы — в виде списка полей. Перечень атрибутов объекта должен содержать следующую информацию о каждом атрибуте:
    • Наименование атрибута
    • Описание атрибута
    • Формат данных
    • Наименование таблицы и столбца, хранящего значение атрибута
    • Перечень взаимосвязей (как с объектами, так и с таблицами)
    Список полей таблицы должен описывать каждое поле следующим образом:
    • Наименование поля
    • Тип данных
    • Признак обязательности заполнения
    • Наименование объекта и атрибута, значение которого хранится в данном поле
    • Перечень взаимосвязей (с таблицами)
    Кроме того, для каждого типа объекта должен быть приведен перечень таблиц, хранящих значения атрибутов объектов этого типа, а для каждой таблицы — перечень типов объектов, значения атрибутов которых в ней хранятся.
  3. Оформление документа Разумеется, конкретные варианты оформления документации зависят от внутренних стандартов организации. Однако практика показывает, что неотъемлемым признаком легкого для восприятия и удобного для использования в электронном виде документа является оформление упоминаний объектов и таблиц БД в виде перекрестных ссылок. Применение перекрестных ссылок существенно упрощает работу с документом — навигация по объектам и таблицам и поиск интересующей информации становятся быстрыми и целенаправленными.

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

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

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


IT News

Комментарии

Страницы комментариев: 1 :: 2 :: следующая

Страницы комментариев: 1 :: 2 :: следующая

Комментарии заморожены.

Схема структуры программного обеспечения Схема структуры программного обеспечения Схема структуры программного обеспечения Схема структуры программного обеспечения Схема структуры программного обеспечения Схема структуры программного обеспечения Схема структуры программного обеспечения Схема структуры программного обеспечения Схема структуры программного обеспечения

Изучаем далее:



Подарок от крестного папы на крещение

Велосипеды для дрифта как сделать

Теневые узоры спицами схемы для пледа

Схема маршрута с расчетом времени

Изготовление двери из массива своими руками
Читать новость Схема структуры программного обеспечения фото. Поделитесь новостью Схема структуры программного обеспечения с друзьями!