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

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

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

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

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

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

(ИС - информационная система!)

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

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

Во втором случае потребуется более серьёзная проработка требований и технических решений, влекущая за собой увеличение сроков выполнения и стоимости проекта.

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

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

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

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

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

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


9. Особенности натурного анализа

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



10. Изучение аналогов и образцов

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

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

Проектирование в реальной действительности осуществляется по некоторым устоявшимся правилам и закономерностям. Проектирование всегда предполагает некоторое приращение к исходному состоянию объекта проектирования. Результат проектирования может быть представлен как некоторая исходная система (ИС) и добавка (приращение) А.

Процесс выявления проблемы и поиск ее решения происходит по определенной схеме. Часто эта схема не осознается (остается в подсознании). Весь процесс проектирования может быть условно разделен на три больших этапа :

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

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

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

11. Изучение нормативов

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

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

раздел Безопасность включает (Противопожарные нормы, нагрузки и воздействия, основания зданий и сооружений) и многое другое,

Раздел Конструкции охватывает всевозможные бетонные и железобетонные, алюминиевые, асбестоцементные и прочие конструкции

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

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

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

Качество владения этими знаниями формирует пользу, прочность, красоту, и экономичность сооружаемого объекта.

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

Значение термина

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

Основные задачи

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

Основные цели

Концептуальная модель преследует следующие цели:

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

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

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

Разработка концептуальной модели

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

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

Важные компоненты

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

  • Концептуальное (инфологическое) проектирование (КП) системы – это конструирование информационных моделей предметной области(ОУ), котрые не зависят от условий программной и аппаратной реализации.

    Здесь выполняется три функции:

    1. определение типов сущностей предметной области

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

    3. определение атрибутов и связывание их с типами сущностей и связей.

    4. создание локальных концептуальных моделей данных в виде диаграмм “сущность - связь”.

    5. обсуждение ЛКИМД с пользователями.

    Рис. 3.1.3.1 Соответствие этапов проектирования и элементов архитектуры ANSI/SPARC.

    Этап логического проектирования.

    Логическое проектирование – это конструирование информационных моделей на базе существующих концептуальных модулей. Т.е. на этом этапе концептуальная модель данных преобразовывается в локальную логическую модель данных и далее в глобальную логическую модель данных(ГЛМД) с учетом типа используемой СУБД. Этот этап содержит 2 подэтапа:

    На первом подэтапе выполняется:

    1. преобразование локальной концептуальной модели данных (ЛКМД) в локальную логическую модель данных(ЛЛМД);

    2. определение набора отношений(таблиц) исходя из структуры ЛЛМД;

    3. проверка ЛЛМД с помощью правил нормализации;

    4. проверка ЛЛМД в отношении транзакции пользователей;

    5. создание окончательной диаграммы «сущность-связь» для каждой ЛЛМД;

    6. определение требований к ЛЛМД с точки зрения обеспечения целостности данных;

    7. обсуждение ЛЛМД с конечными пользователями.

    На втором подэтапе выполняется:

    1. слияние ЛЛМД в ГЛМД;

    2. проверка и корректировка ГЛМД;

    3. создание окончательного варианта диаграммы «сущность-связь», отображающей ГЛМД;

    4. обсуждение ГЛМД с конечными пользователями.

    Т.о. концептуальное и логическое проектирование позволяет решить следующие задачи:

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

    2 преобразовать ЛКМД в ЛЛМД

    3 объединить ЛЛМД в ГЛМД

    Этап физического проектирования

    Этот этап состоит из 3-х подэтапов:

    1. внедрение ГЛМД в среду конкретной СУБД:

    Проектируются основные таблицы в среде СУБД

    Реализация функций связанных с управлением ПО или т.н. бизнес-правил для ПО

    2. создание проекта физического представления БД:

    Выбор конкретной структуры хранения данных

    Определение требований к внешней памяти

    3. разработка средств защиты БД:

    Разработка и учет пользовательских представлений о защите данных

    Определение правил доступа для разных типов пользователей

    На этом же этапе необходимо рассмотреть вопросы мониторинга и настройки всей системы.

    Выбор СУБД.

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

    Общий список параметров включает:

    1. физические параметры:

    предусмотрены ли файловые структуры в данной СУБД;

    наличие средств индексирования;

    наличие средств сжатия данных;

    возможность шифрования данных;

    требуемые объемы ОЗУ и ПЗУ для данной СУБД и т.д.

    2. параметры определения данных:

    тип базовой модели организации данных;

    наличие поддержки в расширении первичных ключей;

    наличие средств поддержки целостности данных;

    предусмотренные типы данных;

    3. общие параметры:

    стоимость СУБД;

    наличие поддержки работы СУБД в Internet;

    производительность данной СУБД;

    4. параметры, определяющие доступность в плане создания приложений:

    возможности языка запросов;

    наличие многопользовательского доступа;

    возможность использования языков современного уровня;

    5. группа параметров, описывающих средства технологии разработки ИС:

    наличие инструментов для работы с оконным интерфейсом;

    наличие case-инструментов;

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

    Разработка приложений.

    Цель разработки приложений заключается:

    1. создание проекта транзакций

    2. создание проекта интерфейса пользователя.

    Проектирование транзакций.

    Транзакций – одно действие или последовательность действий, выполняемых одним и тем же пользователем и/или одной прикладной программой(ПП), в результате чего появляется возможность обеспечить доступ к БД и/или изменить её содержимое (пример транзакций – регистрация клиента в БД какого-либо банка).

    Обычно транзакция выполняется частично персоналом АИС, а частично ПП или самой СУБД.

    Основные типы транзакций:

    1. транзакции извлечения – действия, обозначающие выборку данных из базы

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

    3. смешанные транзакции

    При проектировании транзакций необходимо определить и задокументировать характер(свойства) всех транзакций, которые будут реализовываться в АИС. В их числе:

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

    2. выходные данные, формируемые транзакцией;

    3. функциональные характеристики транзакций;

    4. степень важности транзакции для пользователя;

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

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

    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 с. и др.