Без развития методов проектирования структур управления затрудняется совершенствование управления и повышение эффективности производства, так как:
во-первых , в новых условиях в целом ряде случаев нельзя оперировать старыми организационными формами, которые не удовлетворяют требованиям рыночных отношений, создают опасность деформации самих задач управления;
во-вторых , в сферу хозяйственного управления невозможно переносить закономерности управления техническими системами. Комплексный подход к совершенствованию организационного механизма во многом был подменен внедрением и использованием автоматизированных систем управления (АСУ) - работой исключительно важной, но не единственной в развитии управления на всех уровнях. Создание автоматизированных систем управления нередко ведется в отрыве от улучшения структуры управления, недостаточно связано с организационными факторами;
в-третьих , создание структуры должно опираться не только на опыт, аналогию, привычные схемы и, наконец, интуицию, но и на научные методы организационного проектирования;
в-четвертых , проектирование сложнейшего механизма – механизма управления - должно возлагаться на специалистов, владеющих методологией формирования организационных систем.
При разработке принципов и методики проектирования структур управления важно отойти от представления структуры как застывшего набора органов, соответствующих каждой специализированной функции управления. Организационная структура управления – понятие многостороннее. Оно прежде всего включает систему целей и их распределение между различными звеньями, поскольку механизм управления должен быть ориентирован на достижение целей. Сюда же относятся состав подразделений, которые связаны определенными отношениями; распределение задач и функций по всем звеньям; распределение ответственности, полномочий и прав внутри организации, отражающее соотношение централизации и децентрализации управления. Важными элементами структуры управления являются коммуникации, потоки информации и документооборот в организации. Наконец, организационная структура – это поведенческая система, это люди и их группы, постоянно вступающие в различные взаимоотношения для решения общих задач.
Такая многосторонность организационного механизма несовместима с использованием каких-либо однозначных методов–либо формальных, либо неформальных. Именно поэтому необходимо исходить из сочетания научных методов и принципов формирования структур (системного подхода, программно-целевого управления, организационного моделирования) с экспортно-аналитической работой, изучением отечественного и зарубежного опыта, тесным взаимодействием разработчиков и тех, кто практически будет внедрять и использовать проектируемый организационный механизм. В основу методологии проектирования структур должно быть положено четкое формулирование целей организации. Сначала формулируются цели, а затем – механизм их достижения. При этом организация рассматривается как многоцелевая система, поскольку ориентация на одну цель не отражает ее многообразную роль в развитии экономики.
Особое значение имеют характер влияния внешней среды на построение организации и система связей элементов структуры с элементами внешней среды (рис. 28.1).
Системность подхода к формированию организационной структуры проявляется в следующем: 1) не упускать из виду ни одну из управленческих задач, без решения которых реализация целей окажется неполной; 2) выявить и взаимоувязать применительно к этим задачам систему функций, прав и ответственности по вертикали управления – от генерального директора предприятия до мастера участка; 3) исследовать и организационно оформить все связи и отношения по горизонтали управления, т. е. по координации деятельности разных звеньев и органов управления при выполнении общих текущих задач и реализации перспективных межфункциональных программ; 4) обеспечить органическое сочетание вертикали и горизонтали управления, имея в виду нахождение оптимального для данных условий соотношения централизации и децентрализации с управлении. Все это требует тщательно разработанной поэтапной процедуры проектирования структур, детального анализа и определения системы целей, продуманного выделения организационных подразделений и форм их координации.
Основные методологические принципы проектирования
Существует несколько определений термина «проектирование». В основном они характеризуют его с двух сторон, как общераспространенное понятие и с научно-технической позиции :
Проектирование -деятельностьчеловека илиорганизации (ий)по созданиюпроекта, то естьпрототипа, прообраза предполагаемого или возможного объекта, состояния; комплекта документации, предназначенной для создания определённого объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых был разработан данный объект.
От специфического для машиностроения,строительстваи других отраслей науки и техники понятия«проект» (англ. design) в значении «проектная документация» следует отличать используемое в области деятельностиуправление проектами в контекстеменеджмента понятие«проект» (англ. project, отлат.projectus - брошенный вперёд, выступающий) в значении «некоторая задача с определёнными исходными данными и требуемыми результатами (целями), обусловливающими способ её решения», «программа», «комплекс работ» и т. п.
Проектирование может включать несколько этапов от подготовки технического задания до испытания опытных образцов. Объектом проектирования являетсяпроект материальногопредмета .
Понятие «проектирование» не включает в себя стадию реализации проекта.
Проектирование обладает своей методологией , которая включаетструктуру деятельности,принципы инормы деятельности,субъектов ,объект и егомодели ,методы и др.
Методы проектирования
Основная статья: Методы проектирования
Метод итераций (последовательного приближения)
Метод декомпозиции
Метод контрольных вопросов
Метод мозговой атаки (штурма)
Теория решения изобретательских задач (ТРИЗ)
Метод морфологического анализа
Функционально-стоимостной анализ
Методы конструирования
Эвристические методы
Цели и виды экспериментальных методов
Планирование эксперимента
Машинный эксперимент
Мысленный эксперимент
Экспериментальные методы
Методы поиска вариантов решений
Методы автоматизации процедур проектирования
Методы оптимального проектирования
Формализованные методы
3 Процесс формирование организационной структуры
|
|
|
Методологии, технологии и инструментальные средства проектирования ПО составляют основу проекта любой информационной системы (ИС). Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ. Технология проектирования
Технология проектирования определяется как совокупность трех составляющих:
пошаговой процедуры, определяющей последовательность технологических операций проектирования;
критериев и правил, используемых для оценки результатов выполнения технологических операций;
нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:
должна поддерживать полный ЖЦ ПО;
должна обеспечивать достижение целей разработки ИС с заданным качеством и в установленное время;
должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей);
должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
должна обеспечивать минимальное время получения работоспособной информационной системы;
должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (СУБД, операционных систем, языков и систем программирования);
должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие:
стандарт проектирования;
стандарт оформления проектной документации;
стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов;
требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта;
механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов), правила проверки проектных решений на непротиворечивость.
Стандарт оформления проектной документации должен ус- танавливать:
комплектность, состав и структуру документации на каждой стадии проектирования;
требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц), правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
правила использования клавиатуры и мыши;
правила оформления текстов помощи;
перечень стандартных сообщений;
правила обработки реакции пользователя. CASE-средства
Общая характеристика и классификация
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
Обычно к CASE-средствам относят программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком;
интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:
репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
средства разработки приложений и генераторы кодов;
средства конфигурационного управления;
средства документирования;
средства тестирования;
средства управления проектом;
средства реинжиниринга.
Современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit), и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
применяемым методологиям и моделям систем и БД;
степени интегрированности с СУБД;
доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.
Вспомогательные типы включают:
средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
средства конфигурационного управления (PVCS (Intersolv));
средства тестирования (Quality Works (Segue Software));
средства документирования (SoDA (Rational Software)). Методология RAD
Одним из возможных подходов к разработке ПО является методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны уметь трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
фаза анализа и планирования требований;
фаза проектирования;
фаза построения;
фаза внедрения. На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС. На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков.
CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60-90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:
общая информационная модель системы;
функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
точно определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами;
построенные прототипы экранов, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация. На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:
определяется необходимость распределения данных;
производится анализ использования данных;
производится физическое проектирование базы данных;
определяются требования к аппаратным ресурсам;
определяются способы увеличения производительности;
завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям. На фазе внедрения производится обучение пользователей, организационные изменения и, параллельно с внедрением новой системы, осуществляется работа с существующей системой (до полного внедрения новой). Планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.
Следует отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша, в первую очередь, для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, то на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода. Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом: менее 1 000 функциональных элементов - один человек; 1 000-4 000 функциональных элементов - одна команда разработчиков; более 4 000 функциональных элементов - из расчета 4 000 функциональных элементов на одну команду разработчиков.
Отметим основные принципы методологии RAD:
разработка приложений итерациями;
необязательность полного завершения работ на каждом из этапов жизненного цикла;
обязательное вовлечение пользователей в процесс разработки ИС;
необходимое применение CASE-средств, обеспечивающих целостность проекта;
применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
необходимое использование генераторов кода;
использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
тестирование и развитие проекта, осуществляемое одновременно с разработкой;
ведение разработки немногочисленной, хорошо управляемой командой профессионалов;
грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ. Инструменты разработки программных средств
При разработке программных средств используется, в той или иной мере, компьютерная поддержка процессов разработки и сопровождения ПО. Это достигается путем представления некоторых программных документов ПО (прежде всего, программ) и предоставлению в распоряжение разработчика ПО специальных программных средств (ПС), или включенных в состав компьютера специальных устройств, созданных для какой-либо обработки таких документов. В качестве такого специального ПС можно указать компилятор с какого-либо языка программирования.
В качестве специального устройства, поддерживающего процесс разработки ПО, можно указать, например, эмулятор какого-либо языка. ПС, предназначенное для поддержки разработки ПО, будем называть программным инструментом разработки ПО, а устройство компьютера, специально предназначенное для поддержки разработки ПО, будем называть аппаратным инструментом разработки ПО.
Инструменты разработки ПО могут использоваться в течение всего жизненного цикла ПО для работы с разными программными документами. Так, текстовый редактор может использоваться для разработки практически любого программного документа.
С точки зрения функций, которые инструменты выполняют при разработке ПО, их можно разбить на следующие четыре группы:
редакторы;
анализаторы;
преобразователи;
инструменты, поддерживающие процесс выполнения программ. Редакторы поддерживают конструирование (формирование) программных документов на различных этапах жизненного цикла. На этапе программирования (кодирования) вместо текстового редактора может оказаться более удобным синтаксически управляемый редактор, ориентированный на используемый язык программирования. Анализаторы производят либо статическую обработку документов, осуществляя различные виды их контроля, выявление определенных свойств и накопление статистических данных (например, проверку соответствия документов указанным стандартам), либо динамический анализ программ (например, с целью выявление распределения времени работы программы по программным модулям). Преобразователи позволяют автоматически приводить документы к другой форме представления (например, форматеры) или переводить документ одного вида к документу другого вида (например, конверторы или компиляторы), синтезировать какой-либо документ из отдельных частей и т.п. Инструменты, поддерживающие процесс выполнения программ, позволяют выполнять на компьютере описания процессов или отдельных их частей, представленных в виде, отличном от машинного кода, или машинный код с дополнительными возможностями его интерпретации. Примером такого инструмента является эмулятор кода другого компьютера. К этой группе инструментов следует отнести и различные отладчики.
Рассмотрим основы проектирования. Методы, применяемые в нем, зависят от специфики создаваемых чертежей.
Архитектурное проектирование
Фото- и кинопроектирование
Эти современные технологии открыли перед архитекторами огромные возможности анализа создаваемой модели здания путем имитации существования людей в пространстве предполагаемой постройки. Благодаря проектированию современные архитекторы создают совершенные композиции, снижают вероятность ошибок, происходящих при переносе «бумажного проекта» в реальность. Законы математики, логики, средства оргтехники, автоматизированные машины упрощают процедуру подготовки документации, ускоряют проектирование офисных зданий и бытовых объектов.
Системы и методы проектирования предполагают обработку большого объема информации, поэтому важно изыскивать дополнительные ресурсы для того, чтобы оптимизировать процесс, отвечать тем требованиям, которые диктует стремительно меняющееся общество.
Все методы, используемые в современном строительстве, основываются на Они невозможны без использования современных электронных средств и автоматизированной техники. При разработке генеральных планов, прорабатывании этажности зданий, выполнении расчетов, архитекторы активно пользуются ИК-технологиями.
Задача проектирования
Искомый метод направлен на разработку проектов на основе оптимального суммирования эстетических, социальных, научных, технических, природных, строительных и иных условий с целью получения готовых и верных решений. С помощью автоматизации и моделирования на электронных машинах последнего поколения можно поддерживать процессы систематизации, накопления, переработки потока информации. Проектирование предполагает аналитическое сравнение готовых вариантов с запрограммированными параметрами и выбором лучшего варианта решения, его технической и графической фиксации, а также в получении необходимого количества проектной документации. Фототелеграфная аппаратура, кинокамеры, голографические аппараты, запоминающие устройства, копировальные центры, пульты управления стали неотъемлемыми частями при создании проектов зданий и офисных помещений. Все эти элементы являются ускоряющими инструментами в работе любого проектировщика.
Особенности архитектурной графики
Она является направлением изобразительного искусства, которое охватывает творческий процесс образов и идей в проектировании с архитектурным дизайном. Осуществляется детальная разработка плана будущего сооружения в чертеже с определенным масштабом. Для этого применяют определенные обозначения пилонов, стен, фундамента, колонн, отметками для расположения дверей и окон. На генеральном плане показано расположение ансамбля сооружений либо отдельного здания на определенной местности с расположением сторон света. Архитекторский чертеж взаимосвязан с математическими расчетами и указаниями реальных размеров создаваемого здания, демонстрирует соотношение его составных частей. В настоящее время предполагается подразделение архитектурной графики на цифровую и классическую. В классической графике применяются в качестве основных инструментов такие предметы, как краски, карандаши, бумага. Цифровая графика невозможна без использования современных вычислительных систем.
Последовательность проектирования
Данный творческий процесс осуществляется в нашей стране по определенным государственным стандартам и нормам в разных отраслях хозяйства. Разработка проектной документации осуществляется на таких стадиях:
- разработка эскизного проекта;
- проработка материала;
- оформление рабочей документации;
- утверждение готового проекта.
Рассмотрим этапы проектирования. На первом этапе не предполагается согласование материалов с органами исполнительной власти, государственным надзором. Нюансами эскиза профессионалы считают продумывание основных деталей будущего объекта до того, как будет принято окончательное решение по его внедрению в реальное строительство.
С помощью эскизного проекта решают следующие проблемы:
- градостроительное обоснование расположения на местности нового строительного объекта;
- демонстрация внутренней планировки и внешнего вида создаваемого объекта;
- выявление привлекательности проекта с точки зрения инвесторов;
- определение историко-культурных, градостроительных, санитарно-гигиенических и экологических требований.
Эскизный проект имеет пояснительную записку, с близлежащими территориями, генеральный план, поэтажные планы, транспортные схемы, фасады, разрезы со специальными «прослойками», варианты объемных и цветовых решений фасадов, фотомонтаж, 3D визуализацию.
Особенности проектирования
Данная методика применяется не только в строительной отрасли, но и в организационной структуре управления. Она заключается в выборе оптимального варианта организации на производстве управления, благодаря чему повысится работоспособность персонала, увеличится объем выпускаемой продукции. Риск в управленческом аспекте определяется как уровень неопределенности прогнозирования результата. Он всегда связан с выбором альтернатив и проведением расчетов вероятности получаемого результата по каждой отдельной альтернативе.
Проектирование структур в производственно-хозяйственной организации рассматривается как сложный объект, включающий экономические, административно-организационные, информационные, экономические взаимодействия, поддающиеся непосредственной проработке и рациональному проектированию, а также социально-психологическим связям и характеристикам. Они напрямую связаны с уровнем квалификации и способностями сотрудников, стилем руководства, отношением к своим служебным обязанностям. Особенность проблемы проектирования структуры организационного управления заключается в том, что она не должна быть адекватно представлена в виде задачи формального подбора идеального варианта организационной структуры по сформулированному, математически обоснованному критерию оптимальности. Проблема предполагает сразу несколько критериев, поэтому для ее решения сочетают научные методы современного анализа, моделирования, оценки организационных систем с функционированием руководителя, эксперта и специалиста по подбору и оценке идеальных вариантов организационных решений.
Организационное проектирование предполагает последовательное приближение к модели оптимальной структуры управления, при котором методам проектирования принадлежит вспомогательная роль при оценке, рассмотрении, принятии к внедрению в реальность самых результативных способов организационных решений. Осуществляется проектирование управленческих структур на основе методов, дополняющих друг друга:
- аналогии;
- структуризации;
- экспертно-аналитического подхода;
- организационного моделирования.
Метод аналогий заключается в использовании механизмов управления и организационных форм, оправдавших себя в компаниях с аналогичными организационными параметрами, а именно целями, размерами, по сравнению с проектируемой организацией. К методике аналогий относят выработку типовых способов управления производственно-хозяйственными организациями. Каковы задачи проектирования? Метод аналогий применяется на основе двух подходов, которые взаимно дополняют друг друга. Первый заключается в выявлении определённых значений и закономерностей изменения основных организаций механизмов управления, которые будут эффективными при определенных исходных условиях. Вторая позиция предполагает совокупность общих решений о взаимоотношениях и характере отдельных звеньев управления и должностей с учетом деятельности организации, направления ее деятельности, а также создание специальных нормативных параметров аппарата управления для организаций такого типа.
Экспертно-аналитический метод предполагает обследование и детальное изучение компании. Для этого привлекаются квалифицированные специалисты, именно от их заключения зависит подбор инструментов для проектирования.
Заключение
Любая деятельность человека тесно связана с применением проектных технологий. Помимо строительной отрасли, проектная методика широко используется в образовательных учреждениях. Индивидуальные предприниматели, начинающие собственное производство, сначала внимательно изучают теоретические основы проектирования, чтобы повысить эффективность компании, минимизировать ненужные расходы, понизить себестоимость выпускаемой продукции. Любое действие, при совершении которого можно разработать новое интересное дело, называют проектной технологией. Министерством образования Российской Федерации были разработаны образовательные стандарты второго поколения, в которых проектные методики являются обязательным условием формирования гармонично развитой личности.
При написании статьи у меня возникли большие трудности с поиском информации. Информации просто не было. После долгого копания в страницах гугла обнаружилось, что терминология проектирования в русском языке несколько отличается. В русском языке проектирование это один из этапов разработки программного обеспечения, а дисциплина, изучающая проблематику создания и управления проектами, методологий проектирования и т.д. называется программной инженерией или технологией промышленного программирования(если совсем по русски). Если еще остались те кто этого не знал, то возможно мое замечание, вам, немного поможет.
С чего все начиналось
История развития управления проектами как таковыми восходит к Ноеву Ковчегу и коллективной охоте первобытных людей на мамонта. Более того некоторые элементы управления проектами можно усмотреть в поведении хищников, охотящихся стаями.В античные времена проектирование связывали с «наукой архитектора» и связывали данную науку не только с возведением зданий, но и созданием строительных и военных машин.Римский инженер и архитектор Марк Витрувий в 1 в. до нашей эры в своем трактате «10 книг об архитектуре» дал проектированию следующее определение:
В теории - показать и обосновать исполнение в соответствии с требованиями искусства и целесообразности.
В практическом смысле - выполнение руками человека работ из любого материала по данному чертежу.
Однако, история развития проектного менеджмента как дисциплины относительно молода: ее относят к 30-м годам XX века и связывают с разработкой специальных методов координации инжиниринга крупных проектов в США - авиационных в «US Air Corporation» и нефтегазовых в фирме «Exon». В СССР в этот же период начала развиваться теория и практика поточной организации работ по реализации крупных строительных проектов.
Появление новой дисциплины
Предпосылки для внедрения принципов проект-менеджмента в процесс разработки ПО зародились в конце 60х - начале 70-х годов прошлого века, когда произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость ПО стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-х годов все человечество будет заниматься разработкой ПО для компьютера. Развитие микроэлектроники привело к резкому увеличению производительности ЭВМ при значительном снижении стоимости. Начали уходить ограничения для аппаратных средств, оставшиеся ограничения приходятся на долю ПО. Это приводило к тому, что умение строить новые программы отставало от требований к новым программам.Другая тенденция развития зародилась внутри самой отрасли и была основана на усилении взгляда на разработку программ, как на более чем простое «кодирование». Вместо этого программное обеспечение рассматривается как имеющее полный жизненный цикл, начинающийся с появления концепции и проходящий стадии проектирования, разработки, ввода в действие, сопровождения и развития. Смещение фокуса внимания с кодирования породил разработку методологий и развитого инструментария, вооруживших команды инженеров, занятых на всех этапах жизненного цикла программного обеспечения.
Тогда и заговорили о программной инженерии(технологии промышленного программирования) как о некоторой дисциплине, целью которой является сокращение стоимости программ. Такая проблема должна решаться более грамотной организацией процесса разработки. Это и привело к развитию методологий проектирования ПО и возведения его в главенствующие составляющие разработки.
Термин программная инженерия был в первые использован в 1968 году в качестве темы конференции, посвященной вопросам максимальной загрузки самых мощных (по тем временам) компьютеров.
Определение заложило основы новой научно-практической дисциплины: нужно было создать систему инженерных принципов, применимую к разработки ПО, обеспечить экономичность и надежность разработки, а также эффективную работоспособность конечного продукта на различных реальных машинах.
Итак программная инженерия - это инженерная дисциплина, которая связана со всеми аспектами производства ПО от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию.
Методологии в программной инженерии
С этого момента программирование «обрастает» различными дополнительными видами деятельности: разработкой требований, планированием, тестированием, конфигурационным управлением, проектным менеджментом, созданием различной документации (проектной, пользовательской и пр.). Разработка программного кода предваряется анализом и проектированием (первое означает создание функциональной модели будущей системы без учета реализации, для осознания программистами требований и ожиданий заказчика; второе означает предварительный макет, эскиз, план системы на бумаге).Все эти и другие дополнительные виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов и будем называть программной инженерией. Получается, что так мы обозначаем, во-первых, некоторую практическую деятельность, а во-вторых, специальную область знания. Или другими словами, научную дисциплину. Ведь для облегчения выполнения каждого отдельного проекта, для возможности использовать разнообразный положительный опыт, достигнутый другими командами и разработчиками, этот самый опыт подвергается осмыслению, обобщению и надлежащему оформлению. Так появляются различные методы и практики (best practices) – тестирования, проектирования, работы над требованиями и пр., архитектурных шаблонов и пр. А также стандарты и методологии, касающиеся всего процесса в целом. Вот эти-то обобщения и входят в программную инженерию как в область знания.
Таким образом методологии в программной инженерии являются одной из самых динамично развивающихся составляющих области знаний, т.к. несут в себе практическую составляющую.
Современная классификация методологий управление проектом или моделей жизненного цикла проекта согласно SWEBOK выглядит следующим образом.
Методологии управления проектами:
- традиционная(каскадная, водопадная) модель;
- cпиральная модель;
- итеративная и инкрементная модель(эволюционный подход).
Подробнее о методологиях
Как видно из названия традиционные методологии построены на последовательном выполнении всех фаз проекта и конечный продукт будет получен только после выполнения всех этапов. Возвращение на предыдущий этап не предусмотрено и при появлении критических ошибок весь проект начинается сначала. Основным примером таких методологий разработки является каскадная модель или модель Водопад. Источником данной модели принято считать статью Уинстона Ройса вышедшею в 1970 году. Однако, сам Ройс описывал эту модель как пример противопоставленный итеративной модели, применимый только для очень простых проектов и сам пользовался итеративными методологиями. Так же Ройс писал, что в особо сложных местах проекта и при применении новых, ранее не используемых технологий, промежуточные этапы можно повторить дважды и заказчик по окончанию проекта получает вторую версию продукта. Такой подход нельзя назвать итеративным, но и однозначно последовательным тоже. На начальном периоде она сыграла ведущую роль как метод регулярной разработки сложного ПО. В 70x - 80x годах XX века модель была принята как стандарт министерства обороны США.По мере развития методологий каскадная модель подвергалась жесткой критики со стороны всех исследователей, предлагавших свои методологии. Последовательное выполнение этапов разработки не дает изменить требования к программному продукту до самого релиза. Чем больше проект тем больше накапливается проблем в процессе проектирования. И реализация изменений в следующей версии продукта иногда становится не целесообразной. Продукт необходимо писать с 0 . Таким образом стоимость работоспособной версии не оправдано сильно растет. А процент успешно завершенных проектов ничтожно мал. Однако, можно ли назвать традиционные методологии разработки отжившими свой век? Не совсем. Для проектов затрагивающих безопасность жизнедеятельности строго поставленные требования и высокая степень формализации является основополагающим и необходимым фактором.
Кроме того, несмотря, на модную сейчас критику традиционной модели, она играет важную роль, потому что налагает на процесс разработки требование крайне необходимой для него дисциплинированности, с помощью которой удается благополучно обходить неструктурированные процессы типа «пишем и правим». Данная модель внесла фундаментальный вклад в понимание процессов разработки ПО следующими утверждениями:
- процесс должен подчиняться дисциплине, разумному планированию и управлению;
- реализация продукта должна быть отложена до полного понимания целей этой реализации.
Спиральная модель ЖЦ стала следующим (после водопадной) этапом развития методологий разработки, поскольку она решает основную проблему каскадной модели. Каждая фаза водопадного процесса разработки в спиральной методологии завершается этапом прототипирования и управления рисками. Этап прототипирования после каждой фазы проекта позволяет определить, насколько текущее состояние проекта соответствует первоначальному плану. По итогам прототипирования выполняется либо переход к следующей фазе, либо возвращение на одну из предыдущих фаз. Однако фазы и последовательность фаз остаются линейными. Автором данной модели является Барри Боэм, опубликовавший в 1988 году статью «A Spiral Model of Software Development and Enhancement». Не смотря на то, что в SWEBOK данная модель выделена отдельно от итеративной, при описании моделей напрашивается вывод об отнесении спиральной методологии к семейству итеративных. Это обуславливается и возможностью изменения требований между этапами и выпуска прототипов продукта после каждого цикла. Возможно такое разделение связано с авторской принадлежностью методологий.
Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Упоминания о данной методологии начали появляться задолго до статьи У. Ройса и появления самой программной инженерии. Истоки концепции итеративной разработки прослеживаются в относящихся к 30-м годам работах эксперта по проблемам качества продукции Уолтера Шеварта из Bell Labs. Важной вехой в истории является осуществленный в 50-е годы проект по разработке сверхзвукового реактивного самолета X-15. По мнению участников этих работ, применение данной методологии в значительной степени определило успех проекта.
Наиболее обсуждаемые сейчас гибкие методологии разработки (Agile методологии) относятся именно к итеративным моделям ЖЦ. При описании любой из гибких методологий упоминается принцип разделения на итерации. Однако, особенность данных методологий это упор на человеческий фактор, а не на документацию проекта, что никак не обозначается в описании итеративной и инкрементной методологии.
Гибкие методологии разработки начали появляться на фоне быстрорастущего усложнения технологий и всеобщей информатизации. Теперь заказчиком в большинстве случаев является лицо далекое от информационных технологий. Для такого заказчика главным является готовый продукт, а не фолианты документации. При экспоненциально растущем темпе развития информационных технологий сроки на разработку ПО сократились и стали жестче. Теперь нет времени на долгое планирование, написание документации и полновесное тестирование. Программный продукт может устареть еще до релиза. В противовес традиционным методологиям разработки итеративные методологии делят выполнение проекта на короткие итерации, ограниченные по времени. После каждой итерации заказчику продукта предоставляется результат. Предусмотрен откат на предыдущие итерации. Появление гибких методологий не привязано к конкретной дате, так как начиная с середины 90х годов начали появляться и внедряться практически параллельно. Это были методологии разработки такие как: Scrum (1995), экстремальное программирование (1996), Crystal Clear, Lean, Kanban и другие. Созданный в феврале 2001 года, Agile-манифест, провозгласил философию гибких методологий разработки и задал вектор развития данных методологий.
Современный этап развития методологий
Сейчас выбор методологии проектирования как никогда подвержен влиянию маркетинга. Все больше появляется консультантов по внедрению agile, коучеров, проводящих бесконечные тренинги, семинары, вэбинары, бесконечные встречи, конференции, круглые столы. Все эти мероприятия направлены на продажу внедрения в ИТ-компаниях за большие деньги приглашенными специалистами или повышения рейтинга компаний, которые уже внедрили гибкие методологии.Гибкие методологии сейчас - это в большей степени свод знаний по организации работы людей с психологической точки зрения. Такие методологии помогают команде проявлять творческую составляющую, умение работать в команде, навыки коммуникации и прочее. Техническая сторона организации работ все больше уходит на второй план. Только ХР(Экстремальное программирование) имеет в своем арсенале такие инженерные практики как разработка через тестирование, метафоры и рефакторинг. Эти практики с успехом применяются в сочетании с другими методологиями. При некачественном внедрении Agile мы получаем то, что сейчас происходит на рынке IT продуктов. Рынок перенасыщен некачественными, нестабильными продуктами, не отвечающими требованиям не к функционалу, ни к интерфейсу. При этом, что скорость выпуска таких продуктов, благодаря пропагандируемому Agile принципу непрерывной интеграции, постоянно растет.
С набирающим обороты снижением качества выпускаемых IT продуктов стали появляться методологии, стремящиеся это качество повысить. Такой методологией стал DEvOps.
Термин «devops» был популяризирован на конференции «Дни DevOps» («DevOps Days») в 2009 году в Бельгии. С тех пор такая методология все больше набирает популярность.Это отчасти связано с тем, что принципы DevOPs пропагандируют не отказ от действующей в организации методологии, а сочетание с ней. Общая концепция DevOps заключается в усилении кооперации между группами разработки(DEVelopments) и эксплуатации(OPerations) в рамках одной организации, несущими ответственность за разработку ПО. Данная методология это без преувеличения новый виток эволюции методологий разработки поскольку ориентирована не только на удовлетворение требований заказчика в жестко определенные сроки, но и повышение качества и стабильности продукта.
В заключении хочется добавить, что раскрываемая в статье тема является одной из составляющих моего дипломного проекта. Именно поэтому цель данной статьи мнение опытных и знающих людей в этом вопросе, поэтому комментарии любого толка(а особенно по теме) очень приветствуются.
Источники
Управление проектами разработки ПО. Дисциплина «Гибкие технологии разработки программного обеспечения» автор: Д.Г. ШопыринВ широком смысле, проектирование - это составление первичного описания, которое позволяет создавать ещё не существующий объект для определённых заданных условий. С латинского языка слово «projectus» и переводится как «брошенный вперёд». Для описания, которое можно в будущем воплотить в виде реального объекта, используют текстовые записи, расчёты, чертежи таблицы, а для выражения условной последовательности действий применяют алгоритмы. В целом, после проведённой детализации, расчётов, дополнений и оптимизации описание объекта становится основой для воплощения идеи в жизнь.
Работа с объектом, который до его создания ещё не имеет материального выражения (не существует), принципиально отличает проектирование от моделирования. С точки зрения этапности, проектирование может быть как финальной фазой стадии исследования, так и начальной фазой стадии производства (строительства). Но современное проектирование - процесс многообразный и многоплановый, имеющий свою специфику и правила в каждой отдельной отрасли: начиная с проектирования систем управления и заканчивая проектированием в строительстве. И, поскольку развитие отраслей меняет условия рабочих процессов, правила проектной деятельности тоже со временем претерпевают изменения.
Проектирование как основа формирования любой деятельности
Всякое инженерное проектирование берёт начало в выраженной общественной потребности, направленной на необходимость возникновения тех или иных технических объектов. К таким объектам относятся результаты строительной деятельности промышленные изделия, программное обеспечение, процессы и др. И первым этапом любого проектирования становится выражение этой потребности в виде технического задания или разработки технического предложения.
Чаще всего техническое задание фигурирует в виде документа (или документов), представляя собой исходное первичное описание объекта. На выходе авторы получают итоговый комплект документации, в котором содержатся сведения, достаточные для изготовления объекта в тех или иных условиях. В узком смысле слова, такую документацию, представляющую собой окончательное описание, и называют проектом. Поэтому часто современное проектирование и описывают как процесс перехода исходного описания объекта в итоговое путём выполнения комплекса исследовательских, расчётных и конструкторских работ.
Такой процесс преобразования обуславливает возникновение ряда промежуточных описаний, каждое из которых подводит некие итоги решения этапных задач. В некоторых моделях проектирования (например, при итерационных подходах) такие промежуточные итоги зачастую становятся основой при обсуждении вопросов о необходимости продолжения проектирования и о направлениях развития процесса в случае одобрения промежуточных результатов. В других моделях (например, в классической поэтапной модели проектирования в строительстве) промежуточные описания (эскизных проект, инженерные изыскания и др.) становятся обязательной вехой в создании полного пакета документации.
Как часть инженерной деятельности современное проектирование имеет ряд особенностей, которые отражают содержание этого процесса.
По тому, используется или не используется в процессе осуществления проектной деятельности специализированное программное обеспечение и ручной труд, выделяют:
- автоматизированное проектирование, основанное на взаимодействии ЭВМ и человека,
- автоматическое проектирование, выполняемое на промежуточных этапах без участия человека,
- ручное.
Подавляющее большинство проектов пока осуществляется по автоматизированному типу, а автоматическое проектирование применимо к относительно несложным объектам. Но и в этом соотношении доля участия компьютера постоянно растёт.
Подходы к проектированию
Основные принципы и идеи проектирования выражены в системном подходе, для которого характерно рассмотрение частей сложной системы или явления в условиях их взаимодействия. Для этого выявляется структура объектной системы, типизируются связи, определяются атрибуты и анализируется влияние внешней среды. Решение этих задач в рамках воплощения системного подхода выливается в создание дисциплин различного уровня обобщения. Так, «Теория систем», например, исследует проектирование сложных и чаще слабоструктурированных экономических, социальных систем.
В технике сложные технические системы исследуются в рамках дисциплины «Системотехники», которая аналогична теории систем. Помимо процесса создания и эксплуатации технической системы, дисциплина изучает принципы и методы её проектирования. Для этого важно чётко сформулировать системные цели и с этой точки зрения организовать рассмотрение системы. Это позволяет отказаться при проектировании от малозначимых элементов и частей, сосредоточившись на оптимизационных задачах.
Конкретизация и интерпретация исходных идей системного подхода находит своё отражение в других производных подходах к проектированию:
- Структурный подход . Он предполагает синтез вариантов системы из блоков-компонентов. При частичном переборе компонентов можно предварительно спрогнозировать их характеристики.
- Блочно-иерархический подход . Сущность такого подхода к проектированию в том, что на первой стадии объект рассматривается как закрытый «чёрный ящик», внутренняя структура которого неизвестна. Затем постепенно, уровень за уровнем, начиная с первого, объект детализируется, устанавливается связь между блоками. Первыми, соответственно, детализируются блоки 1-го уровня, после чего появляются и детализируются блоки уровня № 2 и так – вплоть до получения блоков нижнего уровня с достаточно простой и прозрачной структурой. При таком подходе различные специалисты могут занимать работой над отдельными блоками, но сложность в том, что последующая стыковка решений может создать затруднения (в том числе – и из-за виртуальной природы проектируемых объектов). В целом подход предполагает декомпозицию сложных описаний.
- Объектно-ориентированный подход . При этом подходе вносится большая структурная определённость, связанная с распределением данных между классами объектов. Кроме того, благодаря иерархии и отношениям наследования уменьшается объём спецификаций и снижается вероятность искажения данных.
В социальном проектировании все подходы к процессу принято разделять по критерию их ориентированности на 3 типа:
- с ориентацией на объект (объектно-ориентированные),
- с ориентацией на субъект (субъектно-ориентированные, или тезариусные),
- с ориентацией на проблему (проблемно-ориентированные).
Необходимость увеличивать скорость реализации проектной стадии работ обуславливает появление новых подходов к проектированию.
Методы проектирования
Для многих областей деятельности трудно адекватно представить проблему проектирования в качестве задачи формального выбора лучшего и наиболее эффективного варианта как однозначного математического выражения оптимальности. Поэтому разнообразные методы проектирования выбираются в зависимости от конкретных условий и дополняют друг друга, приобретая специфические черты в различных областях деятельности.
- Графический метод .
К нему применимы законы начертательной геометрии, согласно которым объект изображается на плоскости. Все мысли, идеи, образы и сравнения, анализ и изучение задания на проектирование, детальная техническая разработка сопровождаются графическим изложением в виде схем, таблиц, эскизов, чертежей, графиков, текстов. На каждой ступени процесса преобладают свои специфические приёмы.
Достоинства метода в том, что он отвечает условиям процесса проектирования всех элементов различных объектов, не требует сложного инструмента и оборудования, легко справляется с разным масштабом и детализацией, а результаты проектирования графическим методом одинаково понятны любому технически подготовленному грамотному специалисту. Это и сделало данный метод международным языком проектной деятельности. Другие методы тоже не обходятся без графических изображений, поэтому данный метод считается опорным или основным.
В основе метода лежит процедура компоновки объёмных моделей и их элементов непосредственно в пространстве. При наличии набора унифицированных условных модельных элементов, а также моделей оборудования и конструкций можно рассмотреть множество вариантов компоновок, чтобы выбрать лучшую. Применение метода ограничено разнообразием составляющих макетотики, которая есть в распоряжении проектировщика, но в серьёзных проектных организациях разнообразие элементов постоянно растёт, а при наличии 3- принтеров внедрение метода в повсеместную проектную практику – вопрос скорого времени. Практическая ценность и важность этого метода состоит ещё и в том, что идея моделирования как основы научного эксперимента становится при создании модели частью проектирования.
- Макетно-графический метод .
Как способ сочетания композиционного мышления, графического мастерства и масштабного моделирования объёмов этот комплексный метод в наибольшей степени отвечает существу процесса проектирования, особенно когда речь идёт об архитектурном проектировании промышленных предприятий. В его помощью проектирование осуществляется на всех ступенях, начиная с идеи сооружения и заканчивая созданием рабочих макетов генеральных планов.
Макетно-графический метод и сам активно развивается как универсальный метод, и служит основой для отдельных ответвлений в проектировании – например, фото- и кинопроектирования. С помощью современной техники с многочисленных реальных точек зрения имитируется натурное движение людей в пространстве будущего объекта. При грамотном применении это позволяет создавать наиболее совершенные композиции, что, в свою очередь, снижает вероятность композиционных ошибок, допускаемых при переходе проекта к натуре.
- Автоматизированный метод (с применением электронной техники) .
Метод позволяет справляться со всем объёмом информации, который нужно безошибочно и быстро переработать во время проектирования. Предыдущие методы, основанные в первую очередь на труде человека, имеют объективные ограничения, которые помогает преодолеть применение автоматизированной и электронной техники.
Проекты, созданные с применение этого метода, отличаются оптимизацией в задаче синтезирования строительных, технических, социальных, эстетических, научных сторон проекта. Пока наиболее проблемным этапом в применении данного метода становится этап поиска идеи как художественно-инженерного и эмоционально-философского высказывания.
При всей технической сложности в обеспечении автоматизированного метода он и макетно-графический метод относятся к двум самым быстроразвивающимся методам проектирования.
Структура проектирования
Проектирование делится на процедуры, этапы и стадии. Проектирование сложных объектов включает стадии:
- научно-исследовательских работ,
- опытно-конструкторских работ,
- технического проекта,
- рабочего проекта,
- стадию испытания опытного образца.
Первая стадия зачастую делится на стадии предпроектных исследований, технического предложения и технического задания. Содержание деятельности на этих стадиях сводится к:
- последовательному изучению потребности общества в новых изделиях с заданным целевым назначением,
- исследованиям физических, конструктивных, технологических и информационных принципов создания изделий,
- прогнозированию возможных характеристик объектов и их параметров.
Результатом научно-исследовательских работ становится техническое задание на разработку будущего объекта. На стадии опытно-конструкторских работ создаётся эскизный проект изделия, а также конкретизируются, проверяются и корректируются принципы, установленные на предыдущей стадии. Стадии технического проекта «отвечает» за детальные технические решения. А стадия рабочего проекта – за полный (достаточный для изготовления) комплект конструкторской и технологической документации. На завершающей стадии испытания опытного образца по результатам испытания выявляются ошибки проекта и принимаются меры по устранению недоработок.
Как правило, за проектирование отвечают специализированные проектные организации. Так в строительстве классической считается модель, при которой заказчик обращается к проектной компании и та, после согласования с заказчиком общего концепта и получения технического задания с исходными данными, вступает в многоэтапный проектный процесс.
При некоторых видах договора подряда функцию взаимодействия с проектными организациями берёт на себя генеральный подрядчик. Международные стандарты инжиниринга предусматривают несколько вариантов, среди которых самые распространённые соглашения – это договоры в стандарте EPC (Engineering Procurement Construction) и в стандарте EPCM (+Management). В первом случае контрактор предоставляет заказчику услуги по проектированию (а также по закупке оборудования и строительству) «под ключ». Во втором случае, контрактор занимается менеджментом этих процессов (в том числе, и менеджментом проектирования).
Различают нисходящее проектирование (сверху вниз), при котором задачи более высоких иерархических уровней решаются первыми, и восходящее проектирование (снизу вверх), при котором наблюдается обратная последовательность – от задач нижестоящих в иерархии структур. В сложных системах функциональное проектирование чаще всего носит нисходящий характер, а конструкторское проектирование – восходящий.
