Тарифы Услуги Сим-карты

Концептуальное проектирование с использованием методологии IDEF1X. Концептуальное проектирование

Концептуальное проектирование оперирует информацией, независимой от любой фактической реализации (ᴛ.ᴇ. от любой конкретной системы технического или программного обеспечения). Цель концептуального проектирования именно в том состоит, чтобы представить информацию в доступной пользователю форме, не зависящей от спецификации системы, но реализуемой несколькими системами.

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

В большинстве случаев пользователи описывают свои информационные требования в терминах сущностей, атрибутов и связей (диаграмма типа "сущность – связь" или ER-диаграммы) или в терминах записей, элементов и наборов, используя языки описания данных СУБД.

Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, концептуальное проектирование можно рассматривать с двух точек зрения – обычного представления и моделирования сущностей, указанных на рисунке.

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

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

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

Сущность представляет собой основное содержание того явления или процесса, о котором крайне важно собрать информацию, она является узловой точкой сбора информации. В качестве сущности может выступать личность, место или вещь, информацию о которых нужно хранить. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных предметов или вещей, выступающему как целое. Экземпляр сущности относится к конкретной вещи в наборе. К примеру, типом сущности может быть СЛУЖАЩИЙ, а экземпляром сущности – Петров В.М., Сидоров А.Г., Терентьев М.С. и т.д.

Средством, с помощью которого определяются свойства сущностей, являются атрибуты. Атрибут - ϶ᴛᴏ поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различных типов сущностей (к примеру, ЦВЕТ может быть определœен для многих сущностей). Хотя сущности существуют сами по себе, атрибуты используются для определœения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности СЛУЖАЩИЙ являются ИМЯ. АДРЕС. ОТДЕЛ и т.д. Здесь также существует основное различие между типом и экземпляром. Тип атрибута ОТДЕЛ имеет множество экземпляров или значений: ОПТ, ОГМ и т.д. При этом каждому экземпляру сущности присваивается только одно значение атрибута.

Атрибут имеет следующие характеристики:

Наименование – уникальное имя атрибута.

Описание – повествовательное изложение смысла атрибута.

Роль – конкретное использование атрибута. Атрибут может быть использован в любой роли, описанной ниже.

Наиболее часто встречающейся ролью атрибута является описание свойства сущности. Другой важной ролью является идентификация сущности, когда атрибут может использоваться для однозначного распознавания экземпляров сущности. К примеру, атрибут ТАБЕЛЬНЫЙ-НОМЕР, имеющий уникальный набор значений, позволяет отличать друг от друга экземпляры сущности СЛУЖАЩИЙ, даже если несколько служащих имеют одну и ту же фамилию. Среди других ролей атрибута крайне важно отметить:

1. представление связей между сущностями:

2. использование в процессе получения других выводимых величин:

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

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


  • - Концептуальное проектирование

    Концептуальное проектирование является центральной частью, ядром всего процес­са проектирования баз данных. Подходы к концептуальному проектированию, излагаемые в разных литературных источниках и реализованные в разнообразных CASE-системах, отли­чаются друг от друга.... [читать подробенее]

    СПИСОК ЛІТЕРАТУРИ ПОСЛІДОВНИК Стратегія конкурентного поводження послідовника полягає в тому, що він не намагається атакувати лідера, однак чітко охороняє свою частку ринку. Послідовник намагається утримувати своїх клієнтів, хоча і не відмовляється від одержання... [читать подробенее]


  • - Концептуальное проектирование

    ПРОЦЕСС ПРОЕКТИРОВАНИЯ В процессе проектирования традиционно выделяют три части: 1. Концептуальное проектирование – учёт требований пользователя и автоматизируемой предметной области. 2. Логическое проектирование – учёт требований аналитиков. 3. Физическое...

  • Концептуальное проектирование порой называют техническим . Его основными этапами являются:

    1) предварительное проектирование,

    2) эскизное (рабочее или техно-рабочее) проектирование,

    3) изготовление, испытания и доводка опытного образца системы (рис. 4.3).

    Рис. 4.3. Этапы концептуального проектирования.

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

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

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

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

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

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

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

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

    Результатом концептуальной стадии проектирования АИС является итоговый документ – “Концептуальный проект”, “Аванпроект”, “Пилотный проект” или “Концепция и программа создания…”. В дальнейшем будут преимущественно использоваться термины “Концептуальный проект” и “Концепция” или “программа создания…”.

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

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

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

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

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

    Можно выделить три основных вида проектирования объектов и систем по степени их сложности, объёму и ряду других показателей: крупные, средние и малые (мелкие) проекты.

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

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

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

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

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

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

    Объект – абстрактное множество предметов, все предметы которого имеют одни и те же характеристики.

    На выбор средств проектирования могут существенно повлиять следующие особенности методов проектирования:

    · ориентация на создание уникального или типового проекта;

    · итерационный характер процесса проектирования;

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

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

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

    ER-модели
    Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В 1976 году Чен (Chen) предложил для проектирования ИС (баз данных) использовать ER-модели (Entity Relationship model – модель «сущность-связь»), представляющие концептуальные модели данных. Они получили широкое распространение в современных CASE-системах, поддерживающих автоматизированное проектирование ИС и обычно используются на этапе информационно-логического моделирования.

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

    Таблица понятий: сущность, связь и атрибут.

    Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь «Руководство» имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь «Участие» имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать много сотрудников. На рисунке приведен пример ER-диаграммы.

    На основе ER-моделей последовательно формируют реляционные БД.

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

    ГОСТ 24.602-86 . Автоматизированные системы управления. Состав и содержание работ по стадиям создания. (Введён с 01.01.89.–М.: Изд-во стандартов, 1986.–12 с.).

    ГОСТ 34.601-90 . Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания (Введён с 29.12.90, 24.601-86. 24.602-86. 1997 г.).

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

    ГОСТ 34.603-92 . Информационная технология. Виды испытаний автоматизированных систем.

    РД 50-640-87 . Системы автоматизированного проектирования. Порядок выполнения работ при создании систем: Инструкция.–М.: Изд-во стандартов, 1987.–28 с. и др.

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

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

    Статика и динамика систем

    Современное концептуальное проектирование - это статика. Условия применения результатов интеллектуальной деятельности человека - это всегда динамика. Сама человека - это непрерывное развитие (динамика).

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

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

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

    Сбор и анализ информации

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

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

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

    Статика и жесткое конструирование

    Человек не всегда придает объективное значение своей деятельности. Дело вовсе не в том, что он к этому не стремится, просто часто он ставит перед собой одни цели, но достигает другие. Концептуальное проектирование существовало всегда, но «сознательно» человек к этому отнесся только с появлением компьютерной техники и программирования.

    Между тем, ассоциации: «концепция = информационная система» не существует. Во всяком случае: об этом свидетельствует современное положение вещей.

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

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

    Современный мир виртуальных технологий мало чем отличается от пирамиды Хеопса. Изменить что-либо в созданной информационной системе крайне сложно. Любое изменение чревато существенными затратами стороннего труда (разработчика, программиста, автора): сама информационная система ничего «для себя сделать не может».

    Объективные законы физического мира

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

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

    Теория решения изобретательских задач (ТРИЗ), одно из заметных достижений прошлого века, была выполнена одним человеком, но привлекла внимание многочисленных специалистов, которые развили и использовали ее в реальной практике.

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

    ТРИЗ - заметное, но не монументальное достижение. Альтшуллер, Шапиро и тысячи их последователей внесли вклад в теорию, практику и изобретательское дело, но результат «ничтожен»: последователи и правообладатели, фантастические рассказы и статьи о сильном мышлении... в сравнении: Леонардо Да Винчи своими исследованиями полетов птиц и кардинально новой идеей: «не крыло должно махать, но аэроплан должен лететь» - прославился больше и украсил свои многочисленные концептуальные изобретения загадочной Джакондой.

    Субъективные положения социального мира

    ТРИЗ не строилась на фундаменте технического задания, а ее родоначальник Альтшуллер не руководствовался какими-либо методами выполнения работ. «Мастера» теории решения изобретательских задач и тысячи их учеников довольствовались малым:

    1. все искусственные системы развиваются по определенным законам;
    2. все системы развиваются, преодолевая противоречия;
    3. для одинаковых противоречий, решения проблем могут сильно различаться.

    С точки зрения общественного сознания, актуальности и полезности целевая установка ТРИЗ социально значима и имеет реальное практическое применение.

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

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

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

    Обозначить - не значит использовать: концептуально о базовых постулатах ТРИЗ

    Постулат «1»: нет разницы между естественной и искусственной системой, потому. как и то, и другое развивается не по определенным, а по объективным законам. То, что человек не познал или не понимает объективности законов Природы, ровным счетом для этих законов ничего не значит.

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

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

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

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

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

    Методы и средства проектирования

    Интересная особенность поисковой выдачи по запросу: «методы и средства концептуального проектирования»: 97 % результатов связаны с информационными системами, программированием, базами данных и другими направлениями в области компьютерного дела и информационных технологий; остальные 3 % придутся на «более практичные» сферы социальных и производственных потребностей: авиационные двигатели, производственные процессы, социальные или природоохранные проекты и другое.

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

    Концептуальное проектирование: примеры из области разработки программного обеспечения.

    1) В настоящее время принято выделять следующие методологии разработки ПО:

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

    2) Основными этапами КП являются:

    • Предварительное проектирование.
    • Эскизное (рабочее или техно-рабочее) проектирование.
    • Изготовление, испытания и доводка опытного образца системы.

    3) Есть два подхода к КП:

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

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

    Объективный подход к проектированию

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

    Наука и практика обязаны теории решения изобретательских задач. Это было на самом деле великое дело: систематизировать физические, химические, социальные и другие достижения, практические решения, изобретения, технологические процессы. Задача сформулировать системы физических эффектов или определить объективные закономерности - воистину актуальна, была всегда, и в современном мире ее актуальность стремительно растет.

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

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

    Человек и пчела

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

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

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

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

    Понятие концептуального проектирования относится к начальной стадии проектирования ИС и примерно соответствует стадиям 1 – 3 разработки АС по ГОСТ 34 или этапам от определения требований до проектирования в моделях жизненного цикла.

    Определению требований к ИС предшествует определение целей, для которых эта система будет разрабатываться. Цели ИС определяют границы предметной области, объекты которой, их свойства и взаимосвязи существенны с точки зрения поставленных целей и которые будут представлены в ИС (это информация о предметной области – ПО-информация). Цели ИС также определяют, каких пользователей и какие именно информационные потребности система будет обслуживать (это информация о потребностях пользователей – ПП-информация). Две эти составляющие: ПО-информация (являющаяся объективным отражением предметной области) и ПП-информация (отражающая отчасти субъективные представления пользователей) одинаково необходимы и важны для построения концептуальной модели, что и показано на рис. 14 7 . Иногда превалирует второе слагаемое в концептуальной модели, основанной на учёте текущих и предвидимых приложений, т.к. это позволяет быстрее и легче создать систему. Однако такие системы оказываются плохо приспособленными для обработки неформализованных, изменяющихся и непредвиденных заранее задач и запросов. Адекватное отражение в системе ПО-информации придает ей необходимую гибкость и адаптивность к изменяющимся условиям.

    Общая схема концептуального проектирования:

    Схема на рис. 16 представляет два этапа проектирования: сбор и содержательный анализ информации о предметной области и прикладных задачах пользователей; концептуальный анализ данных и синтез концептуальной модели.

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

    Модели ис и методики проектирования

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

    К проектированию ИС непосредственное отношение имеют два направления деятельности: 1) собственно проектирование ИС конкретных организаций на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки; 2) проектирование упомянутых компонентов ИС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных информационных систем. 8

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

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

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

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

    Различают функциональные, информационные, поведенческие и структурные модели 9 . Функциональная модель системы описывает совокупность выполняемых системой функций. Информационные модели отражают структуры данных – их состав и взаимосвязи. Поведенческие модели описывают информационные процессы (динамику функционирования), в них фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий. Структурные модели характеризуют морфологию системы (её построение) – состав подсистем, их взаимосвязи.

    Таким образом, функции (отвечающие на вопрос "Что сделать?") в совокупности с исходными данным ("Над чем произвести действия?"), ограничениями (время, финансовые и материальные средства, нормативные документы или бизнес-правила и т.п.), средствами реализации ("Чем сделать?") и результатом ("Что сделано?") описывают проектируемую ИС.

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

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

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

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

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

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

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

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

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

      DFD (Data Flow Diagrams) - диаграммы потоков данных или SADT (Structured Analysis and Design Technique) диаграммы, иллюстрирующие функции, которые система должна выполнять;

      ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь", моделирующие отношения между данными;

      STD (State Transition Diagrams) - диаграммы переходов состояний, моделирующие зависящее от времени поведение системы (аспекты реального времени).

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

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

    При использовании спиральной модели:

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

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

    - проводится анализ риска и издержек в процессе проектирования систем и технологий.

    2.3.2. Концептуальное проектирование

    Концепция информационной системы

    В предыдущем разделе было показано (рис. 2.3.2), что трудовые и финансовые затраты постепенно растут в первых двух фазах жизненного цикла и резко возрастают в фазе практической реализации информационной системы. Между тем, ошибки, допущенные на первых двух этапах, порождают на последующих этапах трудные, часто неразрешимые проблемы, а также могут серьезно повлиять на стоимость, график работ и, в конечном итоге, на результаты работ в целом. С учетом излагаемых ниже причин имеются основания для выделения их в самостоятельный и специфический вид деятельности – концептуальное проектирование информационных систем. Результатом концептуального проектирования является концепция информационной системы , под которой будем понимать системно взаимосвязанную совокупность структурных решенийS ti S t , реализующих требуемое качество информационного обеспеченияQ t .

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

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

    Определим задачу концептуального проектирования через его компоненты.

    Объектом концептуального проектирования является существующее состояние информационной системы

    Sc =(Sc

    S c ),

    где S c – состояние существующей информационной системы,S c

    S с

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

    Субъект концептуального проектирования. По общепринятой в отече-

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

    Система целей концептуального проектирования. Основная цель кон-

    цептуального проектирования может быть сформулирована следующим образом: определение множества состояний информационной системы S t , реали-

    зующих требуемый уровень качества информационного обеспечения Q t .

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

    S ti= (S ti

    S ti

    S ti

    ; S ti

    – i -ое перспективное решение, соответственно:

    где S ti

    ; S ti

    - организационно-техническое (целевое состояние организационной и технической структур);

    - процедурное (целевое состояние процедурной структуры);

    - информационное (целевое состояние информационной структуры). Практическая активность . Для достижения целей концептуального про-

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

    W i o ={w i o } – работы, направленные на совершенствование организационнотехнической структуры до состоянияS ti ;

    W i p ={w i p } – работы, направленные на совершенствование функциональной структуры до состоянияS ti p ;

    W i i ={w i i } – работы, направленные на совершенствование информационной структуры до состоянияS ti i .

    Задача концептуального проектирования информационных систем.

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

    В выражении (3.8) S t – множество целевых в смысле выражения состояний информационной системы, вектор цели концептуального проектирования. За-

    данные условия S * включают вектор текущего состояния информационной системыS с и множество допустимых операторовW , переводящих информацион-

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

    < S с ,W ,S t >.

    Подобное представление определяет концептуальное проектирование информационных систем как процесс постановки и решения задачи (3.9).

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

    Проблема концептуального проектирования информационных систем: состояние и пути решения

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

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

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

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

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

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

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

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

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

    - соотношении организационных, технических, функциональных и информационных решений;

    - необходимых финансовых, технических и других ресурсах;

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

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

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

    - изучать конъюнктуру рынка;

    - определять реальные цели проектов,

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

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

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

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

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

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

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

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

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

    Выделяют следующие особенности, определяемые сущностью проблемы совершенствования информационного обеспечения.

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

    2. Собственная сложность конечных результатов проектной деятельности (проектов).

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

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

    5. Необходимость непрерывного решения проблемы совершенствования информационного обеспечения.

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

    7. Отсутствие формальных методов решения проблемы.

    Особенности, определяемые современным состоянием проблемы.

    1. Отсутствие системных разработок ("фрагментарность" решений). До настоящего времени вопросы разработки научно-методологической базы совершенствования информационного обеспечения находятся в начальной стадии.

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

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

    3. Перманентно существующая организационная перестройка.

    4. Динамичность информационных технологий, определяемая достижениями научно-технического прогресса.

    4. Ошибки планирования и ценообразования.

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

    6. Ограниченное финансирование работ.

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

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

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

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

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

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

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

    3. Ответственность за взаимоотношения и координацию может быть нечеткой или неопределенной из-за параллелизма или неправильного распределения обязанностей. Это замедляет и усложняет процесс принятия решений и оказывает отрицательное влияние на весь проект.

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

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

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

    1. Информационная система является большой и сложной. Проект представляет собой систему, состоящую из подсистем, которые должны быть объединены в единое функционально связанное целое.

    2. Проект является технически сложным.

    3. Необходимость финансового контроля на всех стадиях проекта.

    4. Наличие ограничений в смете и календарных графиках.

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

    6. Привлечение к проекту большого числа функциональных подразделений

    и охват значительного числа видов работ.

    7. Возможность серьезных изменений в организационной структуре.

    8. Необходимость в больших закупках и поставках материалов, оборудования, услуг.

    мость быстро-

    серьезных

    Техническая

    в смете и

    го реагирова-

    изменений

    сложность

    календарном

    негативных

    ния на изме-

    в структуре

    воздействий

    нения условий

    УСЛОВИЯ НЕОБХОДИМОСТИ ПРОЕКТ

    КОНЦЕПТУАЛЬНОГО ПРОЕКТИРОВАНИЯ

    Рис. 2.3.3. Условия необходимости концептуального проектирования

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

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

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

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

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

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

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