Способы проектирования информационных систем

Некоторые заметки по проектированию информационных систем

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

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

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

Уважаемые программисты, для того, чтобы выяснить, ЧТО должна делать система, нужно знать вовсе не C# или JAVA, а владеть предметной областью. Для проектирования логистической системы, надо быть логистом: иметь опыт работы в этой сфере или в нескольких смежных, похожих сферах. Поэтому и существуют бизнес-аналитики, задача которых как раз определить функциональный облик системы.

Заказчик в лучшем случае выдаст 30-50% нужной информации, остальное следует додумать самостоятельно. Причем додумать крайне критически. Вначале заказчик не знает, чего хочет! Как правило, происходит совместная разработка бизнес-модели, и только потом составляется список функций.

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

Заметки по Agile

Agile — это новая религия?

Обсуждение темы Agile vs. Проектная технология (каскад, водопад, waterfall) больше похоже на спор религиозных фанатиков! Статья вообще была не про Agile, но все комментарии — именно про «гибких». Ребята! Ну неужели нельзя взглянуть шире и увидеть, что для обоих методик есть место под солнцем?!

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

Agile годится не всюду, как и проектная технология

Как написал один из прокомментировавших, «Agile не для ИТ, и не про ИТ. Agile для бизнеса и про бизнес». Действительно, иногда нужно получить очень быстрый результат, выйти на рынок хоть с чем-то, чтобы застолбить место и найти инвесторов. Или идет отработка новых технологий, требования по которым составить проблематично. Это однозначно ниша Agile.

С другой стороны, а где вы найдете достаточно заказчиков, согласных работать по гибким технологиям? 70-80% заказов на рынке — это госструктуры, где используется стандартная проектная технология. Более того, по ГОСТ 34. И за это неплохо платят.
Кроме того, эти методы можно сочетать в одной разработке: ядро создается по проектной технологии, а некоторые части — методом проб и ошибок (Agile). Ну не все возможно продумать заранее. Кроме того, и в проектной технологии есть гибкость: имеется такое понятие, как опытная эксплуатация, в процессе которой многое может меняться.

Agile — это как мыслят разработчики

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

Мы поняли, что Agile — это суть мышления разработчиков. Но заказчик-то думает иначе! И заказчику хочется понять, за что он платит, «пощупать» будущий результат, до начала разработки. А то получается игра в одни ворота: разработчикам удобно, а заказчик по ночам не спи, думай, получится или нет, а если получится, то что получится, когда получится, и сколько это будет стоить. Зато программисту лафа — спокойно работаю, что сделаю, то и сделаю, когда закончу, тогда и закончу, сколько запрошу, столько и заплатят. Не так что ли?

Но иногда заказчику так и следует сказать: мы делаем новое, поэтому спрогнозировать ни сроки, ни стоимость, ни результат не готовы. Согласны? Тогда делаем. Это хотя бы по-честному.

Голову надо включать всегда

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

Чтобы что-то критиковать, надо это изучить

Когда критикуют либо проектную технологию, либо Agile, критики редко знают предмет своего возмущения. Очень мало тех, кто реально изучал (в том числе и стандарты: ГОСТ, ISO, IEEE) и пытался серьезно применять проектную технологию. Но критиков ее хватает. Очень мало команд, которые реально успешно (так, чтобы клиент был доволен!) применяет Agile, но «проповедников» хватает.

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

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

Источник

Методы и средства проектирования информационных систем

Рубрика: Технические науки

Дата публикации: 30.04.2017 2017-04-30

Статья просмотрена: 13423 раза

Библиографическое описание:

Дерюгин, С. В. Методы и средства проектирования информационных систем / С. В. Дерюгин. — Текст : непосредственный // Молодой ученый. — 2017. — № 17 (151). — С. 51-56. — URL: https://moluch.ru/archive/151/42973/ (дата обращения: 18.11.2021).

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

General approaches to the design of information systems have been considered, conceptual modeling has been performed using the example of multichip module production control system. The feasibility of structural-functional and object-oriented approaches has been considered. As a result of simulation the class diagram has been obtained that makes possible the proceeding to the physical implementation of the system.

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

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

1 Общие подходы кпроектированию ИС.

Основные этапы проектирования ИС представлены в табл. 1.

Основные этапы разработки ИС

Этап

Методы решения, характеристики

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

Структурно-функциональное и/или объектно-ориентированное моделирование

Разработка логической модели ИС

Информационное моделирование (создание диаграммы сущность-связь)

Разработка физической модели и программного обеспечения ИС

Реализация объектов логической модели, разработка программного кода

Тестирование и отладка ИС

Корректировка программного обеспечения

Поддержка ИС после ввода в эксплуатацию

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

Рис. 1. Этапы и методы проектирования ИС

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

С появлением большого числа методов концептуального моделирования появилась проблема выбора и обоснованного использования того или иного средства. Из рис. 1 видно, что на первом этапе разработки могут использоваться два основных класса методов проектирования ИС: структурно-функциональное и объектно-ориентированное моделирование. Рассмотрим применение данных методов проектирования в разработке ИС для высокотехнологичного электронного компонента «многокристальный модуль» (МКМ), представляющего собой несколько полупроводниковых кристаллов в одном корпусе.

2 Структурно-функциональное моделирование ИС.

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

Для получения необходимой информации о ТП производства рассматриваемого объекта создадим структурно-функциональную модель «как есть» в нотации графического моделирования IDEF0. На верхнем уровне система представляет собой контекстную диаграмму (рис. 2).

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

Рис. 2. Контекстная диаграмма ТП изготовления МКМ

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

Рис. 3. Первый уровень декомпозиции ТП изготовления МКМ

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

Рис. 4. Дерево узлов ТП изготовления МКМ

3 Объектно-ориентированное моделирование ИС.

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

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

Рис. 5. Диаграмма вариантов использования ТП изготовления МКМ

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

Рис. 6. Диаграмма классов ТП изготовления МКМ

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

Заключение.

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

1. Гамма Э., Хелм Р. Приемы объектно-ориентированного проектирования. Паттерны проектирования. М.: Изд-во Питер, 2016. – 366 с.
2. Рамбо Д., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. М.: Изд-во Питер, 2007. – 544 с.
3. Федоров Ю. Н. Справочник инженера по АСУТП: проектирование и разработка. М.: Изд-во Инфра-Инженерия, 2008 г. – 928 с.
4. Фаулер М. Архитектура корпоративных программных приложений. М.: Изд-во Вильямс, 2006. – 544 с.
5. Иванова Г. С. Технология программирования: учебник для вузов — 3-е изд., перераб. и доп. — М.: Изд-во МГТУ им. Н. Э. Баумана, 2006. — 334 с.
6. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. М.: Изд-во Диалог-МИФИ, 2005. – 432 с.
7. Власов А. И., Лыткин С. Л., Яковлев В. Л. Краткое практическое руководство по языку PL/SQL. — М.: Изд-во Машиностроение — 2000. 64 с.

Похожие статьи

Разработка объектно—ориентированной модели процесса.

Существуют различные методы моделирования для разработки требований (диаграммы потоков данных, диаграммы состояний, методы перспектив и т. д.). Объектно—ориентированное моделирование, а именно методология UML, позволяет, в том.

Анализ методов искусственного интеллекта САПР.

Рис. 1. Концептуально-абстрактная модель разработки экспертной системы.

На верхнем уровне декомпозиции (рисунок 2) работы экспертной системы представлена в общем виде (контекстная диаграмма в нотации IDEF0).

Модель подсистемы расчета налога на добычу полезных.

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

Для моделирования потоков данных структурные методы DFD и IFD являются наиболее подходящими чем объектно—ориентированный метод UML.

Основные принципы и этапы моделирования информационных.

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

На ряду с принципами выделим и основные этапы моделирования информационных систем управленческого учета, рисунок 1.

Анализ современных методов и программных средств.

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

информационные модели в виде диаграмм сущность-отношение, геометрические модели-чертежи.

Функциональное моделирование информационной системы.

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

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

Моделирование технологических процессов производства.

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

Особенности разработки контекстной диаграммы структурно-функциональной модели.

Основные термины (генерируются автоматически): контекстная диаграмма, визуальное моделирование, IDEF, технологический.

Обучение объектно ориентированной парадигме.

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

Проектирование базы данных. Роль процесса в создании.

Именно о процессе проектирования базы данных, его особенностях, методах, этапах и

Её разработка начинается с построения инфологической модели (она обеспечивает

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

Разработка объектно—ориентированной модели процесса.

Существуют различные методы моделирования для разработки требований (диаграммы потоков данных, диаграммы состояний, методы перспектив и т. д.). Объектно—ориентированное моделирование, а именно методология UML, позволяет, в том.

Анализ методов искусственного интеллекта САПР.

Рис. 1. Концептуально-абстрактная модель разработки экспертной системы.

На верхнем уровне декомпозиции (рисунок 2) работы экспертной системы представлена в общем виде (контекстная диаграмма в нотации IDEF0).

Модель подсистемы расчета налога на добычу полезных.

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

Для моделирования потоков данных структурные методы DFD и IFD являются наиболее подходящими чем объектно—ориентированный метод UML.

Основные принципы и этапы моделирования информационных.

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

На ряду с принципами выделим и основные этапы моделирования информационных систем управленческого учета, рисунок 1.

Анализ современных методов и программных средств.

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

информационные модели в виде диаграмм сущность-отношение, геометрические модели-чертежи.

Моделирование технологических процессов производства.

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

Особенности разработки контекстной диаграммы структурно-функциональной модели.

Основные термины (генерируются автоматически): контекстная диаграмма, визуальное моделирование, IDEF, технологический.

Функциональное моделирование информационной системы.

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

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

Обучение объектно ориентированной парадигме.

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

Проектирование базы данных. Роль процесса в создании.

Именно о процессе проектирования базы данных, его особенностях, методах, этапах и

Её разработка начинается с построения инфологической модели (она обеспечивает

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

Источник