Эффективное системное проектирование: ключевые аспекты

Системное проектирование

Какие основные задачи решаются в процессе проектирования системы?

1. Создайте определение дизайна

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

2. Определите атрибуты дизайна

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

3. Рассмотрите свои варианты получения компонентов

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

4. Организуйте дизайн

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

Каковы различные подмножества проектирования системы?

Подмножества проектирования системы следующие:

1. Логический дизайн

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

2. Физический дизайн

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

3. Архитектурный дизайн

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

Архитектура имеет особую область применения

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

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

Рисунок 3: области применения различных терминов

Элементы, показанные на рисунке 3:

  • Архитектура программного обеспечения (Software), главная тема данной статьи, как было определено выше;
  • Архитектура аппаратного обеспечения (Hardware), которое включает такие элементы, как ЦПУ, память, жесткие диски, периферийные устройства, например, принтер, а также элементы, используемые для их соединения;
  • Архитектура организации (Organization), которая включает элементы, имеющие отношение к бизнес-процессам, структурам организации, ролям и ответственности, а также основные области специализации организации;
  • Структура информации (Information), включающая структуры, которые упорядочивают информацию;
  • Архитектура программного обеспечения, архитектура аппаратного обеспечения, архитектура организации и архитектура информации, которые являются подмножеством целостной архитектуры системы (System), рассматривались ранее в данной статье;
  • Архитектура корпорации (Enterprise), которая похожа на архитектуру системы тем, что тоже включает элементы, а именно: аппаратное и программное обеспечение и людей. Однако архитектура корпорации более сильно связана с бизнесом, так как она концентрируется на достижении бизнес-целей и занимается такими объектами, как быстрое реагирование на возникающие ситуации и эффективность организации. Архитектура корпорации может выходить за границы компании.

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

И сейчас, когда мы рассмотрели эти определения, многие вопросы остались без ответа. В чем заключается разница между архитектурой корпорации и архитектурой системы? Является ли корпорация системой? Архитектура информации и архитектура данных, которая встречается в некоторых преимущественно-информационных программах — это одно и то же? К сожалению, на эти вопросы нет согласованных ответов.

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

Анализ и моделирование

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

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

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

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

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

Границы архитектуры

Относительность архитектуры — необходимость разделения архитектурной и неархитектурной частей.

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

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

Границу между архитектурным проектированием (architecting) и непосредственно проектированием системы (designing) можно провести исходя из целей (применения) архитектуры и проекта:

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

За пределами технологий

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

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

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

В процессе разработки продукта он приобретает больше функионала, становится более сложным. У него есть определенный внутренний порядок, который необходимо сохранять и поддерживать. И в этом заключается одна из основных трудностей как в области технологий, так и в области управления проектами. С точки зрения последнего это похоже на Shape Up или Scaled Agile, как должно было быть — более длинные итерации, которые включают в себя этапы стратегического проектирования, последовательный рабочий процесс. В значительной степени так можно поддерживать и legacy-системы.

Эволюция

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

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

Рассмотрим участвующие эволюционные силы как третий набор паттернов высокого уровня:

Красные линии — ограничивающие функции.

Верхняя — предел применимости энергоэффективных (простых) инструментов для комплексных решений. Действительно, легко подобрать очень энергоэффективные инструменты, например, Excel или shell, но эти инструменты нельзя использовать для создания больших, сложных приложений. Чем более совершенное и сложное решение требуется, тем более сложные (менее энергоэффективные с точки зрения человеческого мозга) нужны инструменты.

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

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

Иерархичность и структурированность

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

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

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

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

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

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

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

Применение процессного подхода. Цели проекта

Основными целями проектирования
интегрированной системы Компании являлись:

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

Базовые, общие и перспективные технологии

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

К базовым технологиям, которые
необходимо автоматизировать, относятся:

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

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

Общие технологии, являющиеся неотъемлемыми
частями базовых, включают:

  • консультирование;
  • растаможивание/затаможивание
    товаров;
  • рекламу и маркетинг;
  • сертификацию.

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

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


Рис 1. Взаимодействие базовых и общих технологий
работы Компании

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

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

Подробно базовые и общие технологии работы Компании, а также модель верхнего уровня
рациональной технологии ее работы, обычно описываются в
функционально-информационно-стоимостных моделях рациональных технологий деятельности
Компании (например, в стандартах IDEF0/SADT и ABC).
Фрагменты одной из моделей представлены на рис. 2-3.


Рис. 2. Фрагмент функционально-информационной
модели

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


Рис. 3. Фрагмент функционально-информационной
модели (прод.)

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

Два подхода к проектированию

Можно выделить два основных подхода к
проектированию систем управления предприятием и
информационных
систем их поддержки: структурный
и процессный
.

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

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

О важности и
структуре Системного проекта авторы уже писали в
статье “Реорганизация АСУ промышленных
предприятий” (КомпьютерПресс № 7’97) и в статье
“Методологический подход проектирования
корпоративной информационной системы
предприятия” (материалы конференции
“Корпоративные системы’96”, компания
“СофтСервис”). Хорошо, если на предприятии есть
обученные специалисты, способные быстро и
качественно актуализировать этот документ

Но
это только начало! Ведь актуализировать надо
также и саму информационную систему! Как правило, это достаточно трудоемкий,
длительный и утомительный процесс.

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

Процессный подход подводит к необходимости
перехода на так называемое тощее производство
или тощую ресурсосберегающую организационную
структуру (Lean production). Основными чертами такой
реорганизации являются:

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

Далее мы рассмотрим, каким образом процессный
подход был применен при проектировании
информационной системы одного из предприятий
пищевой промышленности (далее “Компании”).

Интеграция и взаимодействие

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

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

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

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

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

2.3 Майлстоун

Майлстоун (milestone) — метафора, которой в software development обозначают промежуточный этап разработки проекта.

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

Майлстоун фиксирует все принятые решения, чтобы у разработчиков не возникало соблазна переделывать всё до бесконечности.

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

Milestone — этапы разработки, каждая из которых имеет свой номер (1, 2, 3 и т.д.). Это может быть как пре-альфа, как и бета, так и ранний этап разработки (раньше пре-альфы). Некоторые этапы разработки могут помечаться как pre-. Например pre-Milestone 1.

Рассмотрим каждый этап Milestone.

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

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

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

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

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

Следующая стадия используется крайне редко — Beta Escrow. Другое название стадия бета-тестирования, релиз-кандидат на Beta.

Релиз-кандидат – одна из основных стадий.

Релиз-кандидат или RC (англ. release candidate), Пре-релиз или Pre — стадия — кандидат на то, чтобы стать стабильной. В программах на этой стадии были найдены и исправлены все найденные ошибки, то есть они прошли комплексное тестирование. Тем не менее, не исключено появление некоторого числа ошибок, которые были не найдены на тестировании.

Стадия RC Escrow – это релиз, который готов получить звание релиз-кандидата. В этом релизе могут быть ещё ошибки.

Стадия релиз или RTM (англ. release to manufacturing промышленное издание) – это выпуск программного продукта, который готов к тиражированию. Обычно — это стабильная версия программного обеспечения, который прошел все предыдущие стадии. На предыдущих стадиях были исправлены основные ошибки. Также существует малая вероятность появления новых, ранее не замеченных, ошибок.

Стадия RTM Escrow – это конечный этап разработки программы, которая готова стать RTM-релизом.

Стадия Пост-релиз или Post-RTM (англ. post-release to manufacturing) — это издание продукта, у которого есть несколько отличий от RTM. Иногда из этой стадии получается первая стадия разработки следующего продукта. Такие релизы продаются, а раздаются бета-тестерам. Это может быть как и стабильная (если не замечено ошибок) либо с ошибками.

Эти стадии разработки (Beta Escrow, RC Escrow, RTM Escrow и Post-RTM) бывают редко. Beta-Escrow, RC-Escrow, RTM-Escrow — статус, указывающий, что на определенном этапе продукт не имеет серьезных ошибок в коде. Сборки с этим статусом передаются для тестирования ключевым и TAP-партнерам. Если тестирование не выявляет серьезных проблем — код подписывается для публичного тестирования

Таблица 2.1 — Календарный план

Вид работы

Сроки

выполнения

Вид документа

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

10.07.08 —

13.09.08

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

Разработка технического задания

10.07.08 —

13.09.08

Техническое задание

Разработка моделей данных

10.07.08 —

13.09.08

Информационное обеспечение

Описание математических методов и алгоритмов расчетов

1.02.09 —

15.02.09

Математическое обеспечение

Описание языков проектирования и программирования

15.02.09 —

25.02.09

Лингвистическое обеспечение

Обоснование выбора общесистемного и базового ПО

25.02.09 —

5.03.09

Программное обеспечение

Обоснование выбора комплекса технических средств

5.03.09 —

15.03.09

Техническое обеспечение

Разработка методических указаний

15.03.09 — 25.03.09

Методическое обеспечение

Расчет технико-экономической части

25.03.09 — 5.04.09

Технико-экономическое обоснование

Описание технических факторов, влияющих на экологию

5.04.09 -15.04.09

Промышленная экология

Описание технических факторов, влияющих на здоровье человека

30.03.09 -15.04.09

Охрана труда и техника безопасности

Выполнение и оформление графической части

15.04.09 -1.05.09

Графическая часть

Популярные статьи

1

Расчет себестоимости

Расчет себестоимости – очень сложный процесс

Важно не только правильно обобщить все затраты. Надо..

17.03.2020

 • 
Ольга Воробьева

2

PEST-анализ: что это такое и как его провести на примерах

Стратегический менеджмент – это работа с неопределенностью во внутренней и, особенно, во вне…

23.08.2019

 • 
Евгения Чернова

3

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

Анализ финансовых результатов деятельности предприятия дает понимание, насколько эффективно оно ра…

31.01.2020

 • 
Ольга Воробьева

4

Система 5S на производстве: секреты успешного внедрения

Термин «5S» стал популярен в 1980-х годах в производственном секторе Японии. В это время успехи ко…

22.07.2019

 • 
Ильнар Фархутдинов

Совмещение подходов к описанию процессов

Практика эффективного описания бизнес-процессов показала целесообразность совмещения на разных уровнях двух видов описания — вертикального и горизонтального.

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

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

Практики архитектурного проектирования

  1. Общие подходы
    • иерархическое проектирование систем и декомпозиционные подходы;
    • модульное проектирование;
    • проектирование на основе матрицы проектной структуры (DSM, Design Structure Matrix) — метод разбиения системы на модули;
    • проектирование на основе многокритериального принятия решений (см. СППР);
    • морфологический анализ;
    • объектно-ориентированное проектирование;
    • проектирование на основе компонентов.
  2. Формальные подходы к системному проектированию
    • аксиоматическое проектирование;
    • формальные методы проектирования.
  3. Оптимизация
    • многодисциплинарная оптимизация;
    • методы смешанного целочисленного нелинейного программирования;
    • различные методы глобальной оптимизации;
    • нелинейная многоцелевая оптимизация;
    • многоцелевая эволюционная оптимизация, включающая генетические алгоритмы.
  4. Подходы на основе методов искусственного интеллекта
    • специальные экспертные системы и системы на основе баз знаний;
    • проектирование на основе грамматических описаний систем, включая подходы к проектированию составных систем;
    • методы проектирования на основе многоагентных подходов;
    • методы проектирования на основе задач выполнимости (constraint satisfaction problems).
  5. другое…
    • ТРИЗ как метод совмещения логической и физической архитектур;
    • огромное число методов, практикующихся в рамках одного-двух университетских или промышленных исследовательских центров/лабораторий (реже – центров разработки);
    • архитектурные расчёты, в которых принципиальная схема “живая” и по ней можно вести мультифизические расчёты. Например акаузальный язык мультифизического моделирования Modelica;
    • Системная инженерия на основе поиска;

1.3. СИСТЕМНЫЙ ПОДХОД И ПРОГРАММИРОВАНИЕ

Скрыть рекламу в статье

1.3. СИСТЕМНЫЙ ПОДХОД И ПРОГРАММИРОВАНИЕ

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

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

Структурный анализ — выявление элементов объекта и связей между ними.

Функциональный анализ — рассмотрение объекта как комплекса выполняемых им полезных и вредных функций.

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

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

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

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

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

Локальная оптимизация подразумевает улучшение параметров внутри каждой простой задачи.

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

Повторяемость — в использовании существующего опыта проектирования.

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

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

Оглавление книги

Оцените статью