Эскизный проект википедия: Эскиз — Википедия – Технический проект — Википедия

Технический проект — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 26 февраля 2016; проверки требуют 3 правки. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 26 февраля 2016; проверки требуют 3 правки.

Технический проект — стадия разработки конструкторской документации на изделие[1] или стадия создания автоматизированной системы[2].

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

Разработку технического проекта на материальные изделия осуществляют в соответствии с Единой системой конструкторской документации (ЕСКД), на автоматизированные системы — в соответствии с Комплексом стандартов на автоматизированные системы (ГОСТ 34 серии).

Этапы выполнения работ по разработке изделия на стадии «Технический проект» (по ГОСТ 2.103-2013):

  1. Разработка технического проекта с присвоением документам литеры «Т».
  2. Изготовление и испытание макетов (при необходимости).
  3. Рассмотрение и утверждение технического проекта.

Требования к выполнению технического проекта устанавливает ГОСТ 2.120-73.
Номенклатуру конструкторских документов технического проекта устанавливает ГОСТ 2.102-2013 (табл. 3).

Технический проект на автоматизированную систему (ГОСТ 34)[править | править код]

Работы по созданию (развитию) автоматизированной системы, выполняемые на стадии «Технический проект», регламентируются документом ГОСТ 34.601-90 и в общем случае содержат следующие этапы:

  1. Разработка проектных решений по системе и её частям.
  2. Разработка проектной документации на автоматизированную систему и её части.
  3. Разработка и оформление документации на поставку изделий для комплектования автоматизированной системы и (или) технических требований (технических заданий) на их разработку.
  4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

Перечень документов, создаваемых на стадии «Технический проект», определяется документом ГОСТ 34.201-89.

Требования к содержанию документов технического проекта приведены в руководящем документе по стандартизации РД 50-34.698-90.

Проектирование — Википедия

Проекти́рование — процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части (ISO 24765).[1] Результатом проектирования является прое́кт — целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы.[2]:272

Проектирование, наряду с анализом требований, является частью большой стадии жизненного цикла системы, называемой определением системы (англ. system definition). Результаты этой стадии являются входной информацией для стадии реализации (воплощения) системы (англ. system realization).[2]:268

Проектирование системы направлено на представление системы, соответствующее предусмотренной цели, принципам и замыслам; оно включает оценку и принятие решений по выбору таких компонентов системы, которые отвечают её архитектуре и укладываются в предписанные ограничения.[2]:272

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

[2]:272 Детальное проектирование, в свою очередь, определяется как процесс детализации и расширения предварительного проекта (архитектуры) до такой степени, при которой проект полностью готов к реализации.[1]

История

В античные времена проектирование рассматривалось как «наука архитектора»[3]. Деятельность архитектора была связана не только с возведением зданий, но и с созданием строительных и военных машин. Описание системы знаний и принципов организации этой науки представлено в труде римского архитектора и механика Витрувия, жившего 2 тысячи лет назад в эпоху Цезаря и Августа.

Чертёж дверных конструкций

Проектирование в СССР

В ранний период истории СССР проектирование являлось одним из наиболее «узких мест» строительства. Существовало индивидуальное кустарное проектирование. Только в 1929 г. начинали создаваться специальные проектные организации[источник не указан 634 дня].

Проектные конторы разделялись на республиканские и местные. Республиканскими конторами, проектирующими гражданское строительство, являлись: Гипрогор и Коммунстрой, деятельность которых координировалась с проектными конторами областного значения — в частности по Москве — МосПроект, МособлжилСоюз, по Ленинграду — Жилгражданстрой и т. д. 3. В целях построения единого плана работ по проектированию гражданского строительства для 1932 г. как правило устанавливалось, что: а) программы республиканских проектных контор РСФСР по гражданскому строительству охватывали проектные работы для сверхлимитного индивидуального, типового и нижелимитного типового строительства; б) программы местных проектных контор (автономных республик, краевых и областных) охватывали проектные работы для нижелимитного не типового строительства и по приспособлению типовых проектов к земельным участкам; проектирование для сверхлимитного индивидуального и типового строительства допускалось в порядке плановой увязки этих работ с программами указанных выше республиканских проектных контор

[источник не указан 634 дня].

Понятие конструирования

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

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

Слово «конструкция» часто употребляется в значении «структура», «устройство», например, конструкция предложения в лингвистике или организация эстетического материала в искусстве.

Конструирование может осуществляться:

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

По отраслям деятельности

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

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

Функциональное проектирование

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

Наряду со словом «функция» часто используется слово «назначение», особенно при рассмотрении не технических объектов.

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

Оптимальное проектирование

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

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

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

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

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

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

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

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

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

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

  • Практическая полезность:
    • деятельность должна быть целенаправленной, устремленной на удовлетворение действительных потребностей реального потребителя или определенной социальной, возрастной или иной групп людей;
    • деятельность должна быть целесообразной. Важно вскрыть причины, препятствующие использованию существующих объектов для удовлетворения новых потребностей, выявить вызывающие их ключевые противоречия и сконцентрировать усилия на решении главных задач;
    • деятельность должна быть обоснованной и эффективной. Разумным будет использование не любого решения задачи, а поиск оптимального варианта;
  • Единство составных частей:
    • целесообразно любой объект, сложный ли он или простой, рассматривать как систему, внутри которой можно выделить логически связанные более простые части — подсистемы, единство частных свойств которых и образует качественно новые свойства объекта-системы;
    • разрабатываемые объекты предназначены для людей, ими создаются и эксплуатируются. Поэтому человек также обязан рассматриваться в качестве одной из взаимодействующих систем. При этом должно приниматься во внимание не только физическое взаимодействие, но и духовно-эстетическое воздействие;
    • внешняя, или как её ещё называют — жизненная среда, также должна рассматриваться в качестве системы, взаимосвязанной с проектируемым объектом;
  • Изменяемость во времени:
    • учёт этапов жизненного цикла объекта;
    • учёт истории и перспектив развития и применения разрабатываемого объекта, а также областей науки и техники, на достижениях которых базируются соответствующие разработки.
Нисходящее и восходящее проектирование

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

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

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

Структура проектирования

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

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

Стадии проектирования

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

Стадии проектирования регламентированы стандартами ГОСТ 2.103-2013[4] и ГОСТ Р 15.301-2016[5]. Последовательность выполнения всех стадий образует официальную структуру процесса разработки проектной документации, которая, как правило, используется при официальных взаимоотношениях между заказчиком и исполнителем или между соисполнителями работ. Сама документация необходима для отчёта перед заказчиком о проделанной работе, возможности проверки или повторения разработок другими исполнителями, подготовки производства и обслуживания изделия в период эксплуатации.

Стадии создания других систем регламентируются своими стандартами, например, для автоматизированных систем — ГОСТ 34.601-90[6].

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

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

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

Структура процесса проектирования

Процесс решения задачи проектирования

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

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

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

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

  • На этапе синтеза принципа действия отыскивают принципиальные положения, физические, социальные и т. п. эффекты, которые составят основу функционирования будущего изделия. Это могут быть основополагающие нормы, фундаментальные законы и правила, их частные случаи или следствия. Работа ведётся с принципиальными моделями и их графическим представлением — блок-схемами. Этому этапу соответствует заключительная стадия ТЗ и стадия технического предложения структуры проектирования по ГОСТ 2.103;
  • На этапе структурного синтеза на основе выбранного принципа действия создаются варианты начального графического представления объекта — структуры, схемы, алгоритмы, упрощённые эскизы. В соответствии с ГОСТ 2.103 этот этап включает стадию эскизного проектирования;
  • На этапе параметрического синтеза отыскиваются значения параметров объекта, находится численное, в том числе оптимальное, решение проектной задачи, создаётся подробная документация или описание объекта, чертежи изделия и его частей. Этот этап соответствует стадиям технического и рабочего проектирования.

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

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

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

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

Проекты повторного применения

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

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

  • Эвристические методы
    • Метод итераций (последовательного приближения)
    • Метод декомпозиции
    • Метод контрольных вопросов
    • Метод мозговой атаки (штурма)
    • Теория решения изобретательских задач (ТРИЗ)
    • Метод морфологического анализа
    • Функционально-стоимостной анализ
    • Методы конструирования
  • Экспериментальные методы
  • Формализованные методы
    • Методы поиска вариантов решений
    • Методы автоматизации процедур проектирования
    • Методы оптимального проектирования

См. также

Примечания

Литература

  • Сидоров А.И. Основные принципы проектирования и конструирования машин. — М.: Макиз, 1929. — 428 с.
  • Орлов П.И. Основы конструирования: Справочник: В 2-х книгах. — М.: Машиностроение, 1988. — ISBN 5-217-00222-0.
  • Хорошев А.Н. Введение в управление проектированием механических систем: Учебное пособие. — Белгород, 1999. — 372 с. — ISBN 5-217-00016-3. Электронная версия 2011 г.
  • ISO/IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary. — 2010.
  • ГОСТ Р ИСО/МЭК 15288—2008. Системная инженерия — Процессы жизненного цикла систем. — 2008.
  • Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. — 2-е изд. — Hoboken, New Jersey: A John Wiley & Sons, 2011. — 599 с. — ISBN 978-0-470-40548-2.
  • Pyster, A., D. Olwell, N. Hutchison, S. Enck, J. Anthony, D. Henry, and A. Squires (eds). Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0. — The Trustees of the Stevens Institute of Technology, 2012.

Жизненный цикл программного обеспечения — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 12 ноября 2018; проверки требуют 2 правки. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 12 ноября 2018; проверки требуют 2 правки.

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1].

  • ГОСТ 34.601-90
  • ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes» (российский аналог — ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств)

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС):

  1. Формирование требований к АС
    1. Обследование объекта и обоснование необходимости создания АС
    2. Формирование требований пользователя к АС
    3. Оформление отчета о выполнении работ и заявки на разработку АС
  2. Разработка концепции АС
    1. Изучение объекта
    2. Проведение необходимых научно-исследовательских работ
    3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
    4. Оформление отчета о проделанной работе
  3. Техническое задание
    1. Разработка и утверждение технического задания на создание АС
  4. Эскизный проект
    1. Разработка предварительных проектных решений по системе и её частям
    2. Разработка документации на АС и её части
  5. Технический проект
    1. Разработка проектных решений по системе и её частям
    2. Разработка документации на АС и её части
    3. Разработка и оформление документации на поставку комплектующих изделий
    4. Разработка заданий на проектирование в смежных частях проекта
  6. Рабочая документация
    1. Разработка рабочей документации на АС и её части
    2. Разработка и адаптация программ
  7. Ввод в действие
    1. Подготовка объекта автоматизации
    2. Подготовка персонала
    3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
    4. Строительно-монтажные работы
    5. Пусконаладочные работы
    6. Проведение предварительных испытаний
    7. Проведение опытной эксплуатации
    8. Проведение приёмочных испытаний
  8. Сопровождение АС.
    1. Выполнение работ в соответствии с гарантийными обязательствами
    2. Послегарантийное обслуживание

Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes».

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

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

  • процессы соглашения — два процесса;
  • процессы организационного обеспечения проекта — пять процессов;
  • процессы проекта — семь процессов;
  • технические процессы — одиннадцать процессов;
  • процессы реализации программных средств — семь процессов;
  • процессы поддержки программных средств — восемь процессов;
  • процессы повторного применения программных средств — три процесса.
  • Основные:
    • Приобретение (действия и задачи заказчика, приобретающего ПО)
    • Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
    • Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
    • Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)
    • Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение — внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
  • Вспомогательные
    • Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)
    • Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).
    • Обеспечение качества (обеспечение гарантий того, что ИС и процессы её ЖЦ соответствуют заданным требованиям и утверждённым планам)
    • Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
    • Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
    • Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
    • Аудит (определение соответствия требованиям, планам и условиям договора)
    • Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
  • Организационные
    • Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
    • Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
    • Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
    • Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

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

  1. Инициирование приобретения
  2. Подготовка заявочных предложений
  3. Подготовка и корректировка договора
  4. Надзор за деятельностью поставщика
  5. Приёмка и завершение работ

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

  1. Формирование требований к системе
  2. Формирование списка программных продуктов
  3. Установление условий и соглашений
  4. Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями[править | править код]

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

Стандарт ГОСТ Р ИСО/МЭК 12207-2010 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

  1. Стадии;
  2. Результаты выполнения работ на каждой стадии;
  3. Ключевые события — точки завершения работ и принятия решений.

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

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-2010, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

  1. ↑ Стандарт IEEE Std 610.12, Глоссарий
  • Братищенко В.В. Проектирование информационных систем. — Иркутск: Изд-во БГУЭП, 2004. — 84 с.
  • Вендров А.М. Проектирование программного обеспечения экономических информационных систем. — М.: Финансы и статистика, 2000.
  • Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. — М.: Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
  • Мишенин А.И. Теория экономических информационных систем. — М.: Финансы и статистика, 2000. — 240 с.

Концептуальное проектирование — Википедия

Материал из Википедии — свободной энциклопедии

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

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

Автоматизированные системы поддержки этапа концептуального проектирования[править | править код]

Образ объекта или его составных частей может создаваться в воображении человека в результате творческого процесса или генерироваться в соответствии с некоторыми алгоритмами в процессе взаимодействия человека и ЭВМ с помощью автоматизированных систем поддержки этапа концептуального проектирования. Работы по этой тематике велись такими учеными как А. И. Половинкин, М. Ф. Зарипов, Р. Коллер, Бутенко Л.Н., А. М. Дворянкин, Бутенко Д.В., В. Н. Глазунов, С. А. Фоменков, В. М. Цуриков и т. д..

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

  • Формализованное описание естественнонаучных и научно-технических эффектов на основе онтологии научно-технических характеристик.
  • Теория решения изобретательских задач (ТРИЗ).
  • Энерго-информационная модель цепей и метод структурных параметрических схем (ЭИМЦ).
  • Система структурирования физических знаний и поискового конструирования.
  • «Project on Creation of Knowledge Base on Physical and Technologocal Effects», Материалы международной конференции TC-1. Education in Measurements and Instrumentation — Challenges of New Technologies: Proceedings, Вроцлав — 2002, P. 171—176 ISBN 83-7085-647-0. Зарипова В. М., Зарипов М. Ф., Петрова И. Ю.
  • Применение объектных технологий для анализа и проектирования систем поиска новых технических решений (на примере систем Интеллект и Сапфит). Информационные технологии в образовании и медицине: Материалы международной конференции — 2004 г. — Волгоград: Издательство ВолгГТУ, 2004 г. Зарипова В. М., Камаев В. А.

Открытое проектирование — Википедия

Материал из Википедии — свободной энциклопедии

RepRap — 3D-принтер общего назначения, который не только может быть использован для создания структур на основе проектов с открытыми наработками, но и сам является проектом с открытыми наработками. RepRap разработан даже с возможностью копирования самого себя. Uzebox — игровая видеоприставка с общедоступными наработками.[1] Открытая мобильная платформа от Bug Labs.[2][3]

Открытое проектирование (англ. open design) — способ разработки и сопровождения эксплуатации физических изделий, а также машин и систем, путём использования публичной совместно используемой информации о конструкции. Процесс, как правило, идёт с использованием глобальной сети Интернет, лицензий Creative Commons и часто выполняется без монетизации вознаграждения. Цели и философия идентичны политике открытого кода, но применимо к разработке физических изделий, а не программного обеспечения.[4]

Корни движения открытого проектирования[править | править код]

Принципы открытого проектирования являются производными от принципов свободного программного обеспечения и политики открытого кода.[5] В 1997 году Эрик С. Рэймонд (англ. Eric S. Raymond), Тим О’Рейли (англ. Tim O’Reilly) и Лэрри Августин (англ. Larry Augustin) придумали выражение «открытый код» в качестве альтернативы «свободному программному обеспечению», и в 1997 году Брюс Перенс (англ. Bruce Perens) опубликовал основные положения, соответствующие новому определению. В конце 1998 года доктор Сепер Киани (англ. Sepehr Kiani) (кандидат наук в машиностроении Массачусетского Технологического Института) понял, что разработчики аппаратуры также могут использовать в своей работе положения политики «открытого кода», и в начале 1999 года убедил доктора Рьян Вэллэнце (англ. Ryan Vallance) и доктора Сэмир Нэйфех (англ. Samir Nayfeh) в потенциальных преимуществах открытия и публикации наработок, используемых в приложениях проектирования устройств.[6] Вместе они создали некоммерческую организацию — «Фонд открытого проектирования» (Open Design Foundation), в качестве устава которой и было решено определить основные положения открытого проектирования.[6]

Идея открытого проектирования была принята на вооружение либо тогда же, либо впоследствии и другими командами конструкторов, а также — одиночными разработчиками. Принципы открытого проектирования тесно связаны с принципами разработки открытого аппаратного обеспечения (открытой платформы), которые появились в марте 1998 года, когда Ренойуд Лэмбертс (англ. Reinoud Lamberts) из Делфтского технического университета предложил на его сайте, посвящённом «микросхемам с открытым дизайном», создать сообщество разработчиков устройств и аппаратуры в духе сообщества разработчиков свободного программного обеспечения.[7]

Текущие направления развития открытого проектирования[править | править код]

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

Открытое проектирование в сравнении с открытым исходным кодом[править | править код]

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

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

Организации, ведущие открытое проектирование[править | править код]

Эталонный проект VIA OpenBook в среде визуализации CAD.

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

  1. ↑ http://belogic.com/uzebox/
  2. ↑ Worldchanging: Bright Green: BugLabs and Open-Source Hardware Innovation
  3. ↑ First Pics of Bug Labs Open-Source Hardware
  4. ↑ Open collaborative design — AdCiv
  5. ↑ Vallance, Kiani and Nayfeh, Open Design of Manufacturing Equipment, CIRP 1st Int. Conference on Agile, 2001
  6. 1 2 R. Ryan Vallance, Bazaar Design of Nano and Micro Manufacturing Equipment, 2000
  7. ↑ Архивированная копия (неопр.) (недоступная ссылка). Дата обращения 5 октября 2007. Архивировано 12 августа 2007 года.
  8. ↑ J. M Pearce, C. Morris Blair, K. J. Laciak, R. Andrews, A. Nosrat and I. Zelenika-Zovko, «3-D Printing of Open Source Appropriate Technologies for Self-Directed Sustainable Development», Journal of Sustainable Development 3(4), pp. 17-29 (2010). [1]
  • Эпизоды коллективных изобретений — Питер Б. Мейер (англ. Peter B. Meyer), август 2003 — статья о нескольких исторических примерах, которые мы называем «открытым проектированием».
  • Политическая экономия за счёт использования программного обеспечения с открытым исходным кодом — Стивен Вебер (англ. Steven Weber), июнь 2000 — статья, посвящённая взгляду на разработку операционной системы Linux с точки зрения научно-политической перспективы. Заключение статьи предполагает, что модель распространения открытого проектирования удовлетворяет не только дисциплине развития программного обеспечения.
  • Архивы мировых изменений — Алекс Штеффен (англ. Alex Steffen), ноябрь 2006 — интервью с Лоуренсом Лессигом (англ. Lawrence Lessig) об использовании Лицензии для Развивающихся Наций (англ. Developing Nations License) движением «Архитектура для Человечества» для создания глобальной сети разработчиков.
  • Встреча команды открытого проектирования на ICED '09 (недоступная ссылка) — англ. Open Design Team Communication @ ICED '09.
  • Появление открытого проектирования и открытых производств — Мишель Баувенс (англ. Michel Bauwens), журнал «We Magazine» Том 2
  • designbreak — открытая научная, техническая и конструкторская некоммерческая организация, с акцентом на междисциплинарное сотрудничество для решения проблем здоровья и бедности.
  • В следующей промышленной революции, Атомы — новые единицы — Крис Андерсон (англ. Chris Anderson), журнал «Wired» февраль 2010

Проектирование взаимодействия — Википедия

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

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

В конце 1970-х — начале 1980-х исследователи, инженеры и дизайнеры нескольких компаний Силиконовой долины (Xerox PARC, SRI (англ.) и, позднее, Apple Computer) активно занимались вопросами взаимодействия людей с компьютерами. В 1984 году Билл Моггридж опубликовал идею новой дизайн-дисциплины, которую он называл тогда «soft-face». Термин «interactive design» был позже выработан Моггриджем совместно с Биллом Верпланком (англ.)русск. при работе над первым ноутбуком GRiD Compass[2][3].

Существует несколько определений. Проектирование взаимодействия:

  • …предназначено для того, чтобы сделать цифровые вещи пригодными для использования людьми[2];
  • …предназначено для улучшения повседневной жизни через цифровые продукты — для работы, игры, развлечения[4];
  • …есть деятельность по проектированию интерактивных цифровых изделий, сред, систем и услуг[5].

Проектирование взаимодействия возникло на стыке многих дисциплин, но, несмотря на это, имеет свой уникальный набор задач и методов. В нём присутствуют элементы графического дизайна, информационного дизайна, понятия из HCI, являющиеся основой для проектирования взаимодействия с компьютеризированными системами, однако проектирование взаимодействия нельзя свести ни к графическому дизайну, ни к архитектурному проектированию. Новая среда, создаваемая при помощи компьютерной техники, является одновременно активной и виртуальной, поэтому проектировщики этой среды нуждаются в разработке соответствующих принципов и практик, отражающих специфические свойства этой среды: подвижность и интерактивность. Дисциплина не является ни разделом информатики (англ. computer science)[6], ни частью когнитивной психологии, хотя и широко использует её базовые принципы[7]. Многие из этих принципов были впервые сформулированы Дональдом Норманом в книге «Дизайн привычных вещей (англ.)русск.»[8].

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

Алан Купер отметил, что не знает, откуда пошёл термин «дизайнер взаимодействия» (англ. interaction designer), но на этот счёт в Интернете имеется множество мнений[10].

Пять аспектов проектирования взаимодействия[править | править код]

Четыре из пяти аспектов (англ. dimension) проектирования были впервые введены в книге Моггриджа «Designing Interactions». По утверждению Джиллиан Крэмптон Смит, у «языка»[уточнить] проектирования взаимодействия есть четыре аспекта[11]. Дополнительный — пятый — аспект нашёл Кевин Силвер[7]. Такими аспектами являются:

  • слова;
  • визуальное представление;
  • физические объекты или пространства;
  • время;
  • поведение.

Стадии проектирования (по Верпланку)[править | править код]

Билл Верпланк представляет процесс проектирования состоящим из четырёх шагов[11]:

  1. Побуждающий стимул (англ. motivation): наличие проблемы и блестящее решение
  2. Замысел (англ. meaning): какие метафоры можно применить и в каком контексте
  3. Образ (англ. modes): создание концептуальной модели
  4. Схема (англ. mapping): проектирование отображения информации и управления

Прототипирование[править | править код]

Для обеспечения быстрой обратной связи с группой потенциальных пользователей дизайнеры взаимодействия могут использовать бумажное прототипирование[12]. Недостатком такого метода является отрыв от контекста физического устройства, поэтому был придуман также способ «бумага-на-экране» (англ. paper-in-screen), который работает с отсканированными набросками интерфейса, демонстрируемыми на целевом устройстве. Наконец, более дорогим, но менее гибким способом является высококачественное прототипирование на целевом устройстве[13].

Использование шаблонов[править | править код]

Вслед за Кристофером Александером дизайнеры приняли на вооружение метод паттернов (шаблонов) взаимодействия (англ.)русск.[14]. Сообществом веб-дизайнеров выработано множество шаблонов, которые можно классифицировать, например, по потребностям пользователей: базовое взаимодействие, выбор, ввод, навигация, поиск, работа с данными, персонализация, шопинг и другие[15].

Каркасные модели[править | править код]

На ранних стадиях проектирования интерфейса взаимодействие с системой может быть обозначено с помощью каркасных моделей (англ. wireframes) — черновых макетов интерфейса, состоящих из простых линий, форм, обозначений — без указания подробностей. Ознакомление заказчика с черновым вариантом дизайна помогает предотвратить переделки на более поздних стадиях проектирования. Модели могут быть выполнены от руки, с помощью специализированных программ или с помощью графического редактора[16].

  1. ↑ Cooper, Reimann, Cronin, 2007, pp. xxvii.
  2. 1 2 Jonas Lowgren. Interaction Design (англ.). The Interaction Design Foundation (2008). — «Interaction design is about shaping digital things for people’s use». Дата обращения 16 августа 2012. Архивировано 18 августа 2012 года.
  3. ↑ Cooper, Reimann, Cronin, 2007, pp. xxviii.
  4. ↑ Moggridge, 2007, p. xi: «It’s about shaping our everyday life through digital artifacts – for work, for play, and for entertainment».
  5. ↑ Cooper, Reimann, Cronin, 2007: «The practice of designing interactive digital products, environments, systems, and services».
  6. ↑ Terry Winograd, From Computing Machinery to Interaction Design (неопр.) (недоступная ссылка). Дата обращения 15 августа 2012. Архивировано 11 мая 2008 года.
  7. 1 2 Silver, Kevin What Puts the Design in Interaction Design (неопр.). UX Matters. Дата обращения 6 марта 2012. Архивировано 19 октября 2012 года.
  8. ↑ Норман, 2006.
  9. Иван Дегтяренко. Терминологические войны. Эпизод III (рус.). http://www.gui.ru+(9 апреля 2007). Дата обращения 22 августа 2012. Архивировано 19 октября 2012 года.
  10. ↑ Patton, 2008.
  11. 1 2 Moggridge, 2007.
  12. ↑ What is paper prototyping (неопр.) (недоступная ссылка). Дата обращения 27 августа 2012. Архивировано 19 октября 2012 года.
  13. ↑ Paper-in-Screen Prototyping by Diego Pulido
  14. ↑ Jenifer Tidwell, COMMON GROUND: A Pattern Language for Human-Computer Interface Design
  15. ↑ Список паттернов для информационного дизайна (Martijn van Welie) (англ.)
  16. ↑ Kayla Knight, Creating Web Design Wireframes: Tools, Resources and Best Practices
  • Alan Cooper, Robert Reimann, Dave Cronin. About Face 3: The Essentials of Interaction Design. — Wiley, 2007. — 610 с. — ISBN 978-0-470-08411-3.
  • Алан Купер, Роберт Рейман, Дэвид Кронин. Алан Купер об интерфейсе. Основы проектирования взаимодействия = About Face 3: The Essentials of Interaction Design. — Символ-Плюс, 2009. — 688 с. — ISBN 978-5-93286-132-5.
  • Дональд А. Норман. Дизайн привычных вещей = The Design of Everyday Things. — Вильямс, 2006. — 384 с. — ISBN 5-8459-0872-8.
  • Bill Moggridge. Designing Interactions. — The MIT Press, 2007. — ISBN 978-0-262-13474-3.
  • Rogers, Y. and Sharp, H. and Preece, J. Interaction Design: Beyond Human-Computer Interaction. — John Wiley and Sons Ltd. — ISBN 0-471-49278-7.
  • Jeff Patton. A Conversation with Alan Cooper: The Origin of Interaction Design // IEEE Software. — 2008. — Т. 25, № 6. — С. 15—17.
  • Heim, Steven. The Resonant Interface: HCI Foundations for Interaction Design. — Addison-Wesley Longman Publishing Co., Inc., 2007. — 688 p. — ISBN 0321375963.
Собрания примеров

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

Материал из Википедии — свободной энциклопедии


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

По Митчу: "создание устойчивых экосистем направленных на интеграцию человеческого общества и его окружающей среды в интересах обоих"[1]

Экологическое проектирование возникло как новая идея в ранних 60х, но потребовалось еще несколько десятилетий на уточнение её определения, её реализация еще корректируется и она получила широкое признание как новая парадигма сравнительно недавно. Экологическое проектирование было представлено Говардом Одумом и другими[2] как использование природных источников энергии в качестве основного подхода для манипуляции и контроля за экологическими системами. Митсч и Йоргенсен[3] были первыми кто дал определение экологическому инжинирингу и обеспечившими его основными принципами. Они определили и охарактеризовали Экологический инжиниринг в 1989 году в книге и подтвердили это в их следующей книге в 2004 году.[4] Они предположили, что цель Экологического проектирования это а)восстановление экосистем которые были повреждены человеческой активностью, такой как загрязнение или земельные нарушения. б)Развитие новых устойчивых экосистем которые имеют значение и для человека и для экологии Они собрали пять ключевых концепций Экологического проектирования

  • Базируется на самовоспроизводящих мощностях экосистем
  • Может быть полевым тестом для экологической теории
  • Полагается на подходах к комплексной системе
  • Сохраняет невозобновляемые источники энергии
  • Поддерживает биологическую консервацию

Берген и другие[5] определил Экологический инжиниринг как

  • Использует экологическую науку и теорию
  • Применяется ко всем типам экосистем
  • Адаптирует методы проектирования
  • Признает руководящую систему ценностей

Баретт(1999)[6] предлагал более буквальное определение термина: дизайн, строительство, пользование и управление ассоциированных сообществ растений и отных для выгоды человекаи, часто, природы. Баретт продолжает: другие термины с равными или схожими значениями включают экотехнологии и два широко использованных термина в поле борьбы с эрозие: почвенная биоинженерия и биотехническая инженерия. Однако экоинженерию нельзя путать с биотехнологиями которые используются для описания генной инженерии на клеточном уровне или «биоинженерию» означающую созданию искусственных частей тела. Это направление проектирования сочетает основные и добавленные науки Экологического проектирования, экономики, естественных наук, наук для восстановления и строительства водных и сухопутных экосистем. Поле деятельности Экологического проектирования растет вширь и вглубь по мере того как появляются большие возможности для создания и использования экосистем и по мере того, как взаимодействия между технологиями и окружающей средой исследуются. Реализация экологического проектирования направлена на создание или восстановление экосистем из деградировших болот до многоуровневых ванн и парников которые объединяют микробов, рыб и растений для превращение использованной человеком воды в такие продукты как, удобрения, цветы и питьевую воду. Потенциальное применение Экологического проектирования в городах включает в себя области ландшафтной архитектуры, градостроительства, строительства и городского садоводства, которые могут быть применены в городской ливневой системе. Потенциальное применение Экологического инжиниринга в сельской местности включает в себя обработку водно-болотных угодий и восстановление леса в сообществах с использованием экологических знаний.[7] Сегодняшний образ жизни и планирование мест обитания включают в себя движения пермакультуры.

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

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

Учебная программа была разработана для Экологического проектрования и ключевые учреждения США начали запуск этих программ.Ключевые элементы этой программы:

  • Количественная экология
  • Системная экология
  • Восстановительная экология
  • Экологическое моделирование
  • Экологический инжиниринг
  • Экономика экологического инжиниринга
  • Технические факультативы

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

  1. ↑ W.J. Mitsch & S.E. Jorgensen (1989), "Introduction to Ecological Engineering", In: W.J. Mitsch and S.E. Jorgensen (Editors), Ecological Engineering: An Introduction to Ecotechnology. John Wiley & Sons, New York, pp. 3-12.
  2. ↑ H.T. Odum et al. (1963), Experiments with Engineering of Marine Ecosystems, in: Publication of the Institute of Marine Science of the University of Texas, 9: 374—403.
  3. ↑ W.J. Mitsch and S.E. Jorgensen (1989), «Introduction to Ecological Engineering» In: W.J. Mitsch and S.E. Jorgensen (Editors), Ecological Engineering: An Introduction to Ecotechnology. John Wiley & Sons, New York, pp. 3-12.
  4. 1 2 W.J. Mitsch & S.E. Jørgensen (2003), «Ecological engineering: A field whose time has come», in: Ecological Engineering, 20(5): 363—377.
  5. ↑ S.D. Bergen et al. (2001), «Design Principles for Ecological Engineering», in: Ecological Engineering, 18: 201—210.
  6. ↑ Barrett, K. R. 1999. Ecological engineering in water resources: The benefits of collaborating with nature. Water International, Journal of the International Water Resources Association. v 24, p182-188.
  7. ↑ * S.A.W. Diemont and others (2006), «Lancandon Maya Forest Management: Restoration of Soil Fertility using Native Tree Species», in: Ecological Engineering, 28: 205—212.
  8. ↑ E.V. Krik
  • Howard T. Odum (1963), "Man and Ecosystem" Proceedings, Lockwood Conference on the Suburban Forest and Ecology, in: Bulletin Connecticut Agric. Station.
  • P.C. Kangas (2004) Ecological Engineering: Principles and Practice. Lewis Publishers, CRC Press, Boca Raton, Florida.
  • W.J. Mitsch (1993), Ecological engineering—"a cooperative role with the planetary life–support systems. Environmental Science & Technology 27:438-445.
  • W.J. Mitsch and S.E. Jørgensen (1989) Ecological Engineering: An Introduction to Ecotechnology, John Wiley and Sons, New York.
  • W.J. Mitsch and S.E. Jørgensen (2004) Ecological Engineering and Ecosystem Restoration, John Wiley and Sons, New York.
  • H.D. van Bohemen (2004), Ecological Engineering and Civil Engineering works, Doctoral thesis TU Delft, The Netherlands.
  • K. R. Barrett, 1999. Ecological engineering in water resources: The benefits of collaborating with nature. Water International, Journal of the International Water Resources Association. v 24, p182-188.

About Author


alexxlab

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *