При написании статьи у меня возникли большие трудности с поиском информации. Информации просто не было. После долгого копания в страницах гугла обнаружилось, что терминология проектирования в русском языке несколько отличается. В русском языке проектирование это один из этапов разработки программного обеспечения, а дисциплина, изучающая проблематику создания и управления проектами, методологий проектирования и т.д. называется программной инженерией или технологией промышленного программирования(если совсем по русски). Если еще остались те кто этого не знал, то возможно мое замечание, вам, немного поможет.
С чего все начиналось
История развития управления проектами как таковыми восходит к Ноеву Ковчегу и коллективной охоте первобытных людей на мамонта. Более того некоторые элементы управления проектами можно усмотреть в поведении хищников, охотящихся стаями.В античные времена проектирование связывали с «наукой архитектора» и связывали данную науку не только с возведением зданий, но и созданием строительных и военных машин.Римский инженер и архитектор Марк Витрувий в 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) в рамках одной организации, несущими ответственность за разработку ПО. Данная методология это без преувеличения новый виток эволюции методологий разработки поскольку ориентирована не только на удовлетворение требований заказчика в жестко определенные сроки, но и повышение качества и стабильности продукта.
В заключении хочется добавить, что раскрываемая в статье тема является одной из составляющих моего дипломного проекта. Именно поэтому цель данной статьи мнение опытных и знающих людей в этом вопросе, поэтому комментарии любого толка(а особенно по теме) очень приветствуются.
Источники
Управление проектами разработки ПО. Дисциплина «Гибкие технологии разработки программного обеспечения» автор: Д.Г. ШопыринРассмотрим основы проектирования. Методы, применяемые в нем, зависят от специфики создаваемых чертежей.
Архитектурное проектирование
Фото- и кинопроектирование
Эти современные технологии открыли перед архитекторами огромные возможности анализа создаваемой модели здания путем имитации существования людей в пространстве предполагаемой постройки. Благодаря проектированию современные архитекторы создают совершенные композиции, снижают вероятность ошибок, происходящих при переносе «бумажного проекта» в реальность. Законы математики, логики, средства оргтехники, автоматизированные машины упрощают процедуру подготовки документации, ускоряют проектирование офисных зданий и бытовых объектов.
Системы и методы проектирования предполагают обработку большого объема информации, поэтому важно изыскивать дополнительные ресурсы для того, чтобы оптимизировать процесс, отвечать тем требованиям, которые диктует стремительно меняющееся общество.
Все методы, используемые в современном строительстве, основываются на Они невозможны без использования современных электронных средств и автоматизированной техники. При разработке генеральных планов, прорабатывании этажности зданий, выполнении расчетов, архитекторы активно пользуются ИК-технологиями.
Задача проектирования
Искомый метод направлен на разработку проектов на основе оптимального суммирования эстетических, социальных, научных, технических, природных, строительных и иных условий с целью получения готовых и верных решений. С помощью автоматизации и моделирования на электронных машинах последнего поколения можно поддерживать процессы систематизации, накопления, переработки потока информации. Проектирование предполагает аналитическое сравнение готовых вариантов с запрограммированными параметрами и выбором лучшего варианта решения, его технической и графической фиксации, а также в получении необходимого количества проектной документации. Фототелеграфная аппаратура, кинокамеры, голографические аппараты, запоминающие устройства, копировальные центры, пульты управления стали неотъемлемыми частями при создании проектов зданий и офисных помещений. Все эти элементы являются ускоряющими инструментами в работе любого проектировщика.
Особенности архитектурной графики
Она является направлением изобразительного искусства, которое охватывает творческий процесс образов и идей в проектировании с архитектурным дизайном. Осуществляется детальная разработка плана будущего сооружения в чертеже с определенным масштабом. Для этого применяют определенные обозначения пилонов, стен, фундамента, колонн, отметками для расположения дверей и окон. На генеральном плане показано расположение ансамбля сооружений либо отдельного здания на определенной местности с расположением сторон света. Архитекторский чертеж взаимосвязан с математическими расчетами и указаниями реальных размеров создаваемого здания, демонстрирует соотношение его составных частей. В настоящее время предполагается подразделение архитектурной графики на цифровую и классическую. В классической графике применяются в качестве основных инструментов такие предметы, как краски, карандаши, бумага. Цифровая графика невозможна без использования современных вычислительных систем.
Последовательность проектирования
Данный творческий процесс осуществляется в нашей стране по определенным государственным стандартам и нормам в разных отраслях хозяйства. Разработка проектной документации осуществляется на таких стадиях:
- разработка эскизного проекта;
- проработка материала;
- оформление рабочей документации;
- утверждение готового проекта.
Рассмотрим этапы проектирования. На первом этапе не предполагается согласование материалов с органами исполнительной власти, государственным надзором. Нюансами эскиза профессионалы считают продумывание основных деталей будущего объекта до того, как будет принято окончательное решение по его внедрению в реальное строительство.
С помощью эскизного проекта решают следующие проблемы:
- градостроительное обоснование расположения на местности нового строительного объекта;
- демонстрация внутренней планировки и внешнего вида создаваемого объекта;
- выявление привлекательности проекта с точки зрения инвесторов;
- определение историко-культурных, градостроительных, санитарно-гигиенических и экологических требований.
Эскизный проект имеет пояснительную записку, с близлежащими территориями, генеральный план, поэтажные планы, транспортные схемы, фасады, разрезы со специальными «прослойками», варианты объемных и цветовых решений фасадов, фотомонтаж, 3D визуализацию.
Особенности проектирования
Данная методика применяется не только в строительной отрасли, но и в организационной структуре управления. Она заключается в выборе оптимального варианта организации на производстве управления, благодаря чему повысится работоспособность персонала, увеличится объем выпускаемой продукции. Риск в управленческом аспекте определяется как уровень неопределенности прогнозирования результата. Он всегда связан с выбором альтернатив и проведением расчетов вероятности получаемого результата по каждой отдельной альтернативе.
Проектирование структур в производственно-хозяйственной организации рассматривается как сложный объект, включающий экономические, административно-организационные, информационные, экономические взаимодействия, поддающиеся непосредственной проработке и рациональному проектированию, а также социально-психологическим связям и характеристикам. Они напрямую связаны с уровнем квалификации и способностями сотрудников, стилем руководства, отношением к своим служебным обязанностям. Особенность проблемы проектирования структуры организационного управления заключается в том, что она не должна быть адекватно представлена в виде задачи формального подбора идеального варианта организационной структуры по сформулированному, математически обоснованному критерию оптимальности. Проблема предполагает сразу несколько критериев, поэтому для ее решения сочетают научные методы современного анализа, моделирования, оценки организационных систем с функционированием руководителя, эксперта и специалиста по подбору и оценке идеальных вариантов организационных решений.
Организационное проектирование предполагает последовательное приближение к модели оптимальной структуры управления, при котором методам проектирования принадлежит вспомогательная роль при оценке, рассмотрении, принятии к внедрению в реальность самых результативных способов организационных решений. Осуществляется проектирование управленческих структур на основе методов, дополняющих друг друга:
- аналогии;
- структуризации;
- экспертно-аналитического подхода;
- организационного моделирования.
Метод аналогий заключается в использовании механизмов управления и организационных форм, оправдавших себя в компаниях с аналогичными организационными параметрами, а именно целями, размерами, по сравнению с проектируемой организацией. К методике аналогий относят выработку типовых способов управления производственно-хозяйственными организациями. Каковы задачи проектирования? Метод аналогий применяется на основе двух подходов, которые взаимно дополняют друг друга. Первый заключается в выявлении определённых значений и закономерностей изменения основных организаций механизмов управления, которые будут эффективными при определенных исходных условиях. Вторая позиция предполагает совокупность общих решений о взаимоотношениях и характере отдельных звеньев управления и должностей с учетом деятельности организации, направления ее деятельности, а также создание специальных нормативных параметров аппарата управления для организаций такого типа.
Экспертно-аналитический метод предполагает обследование и детальное изучение компании. Для этого привлекаются квалифицированные специалисты, именно от их заключения зависит подбор инструментов для проектирования.
Заключение
Любая деятельность человека тесно связана с применением проектных технологий. Помимо строительной отрасли, проектная методика широко используется в образовательных учреждениях. Индивидуальные предприниматели, начинающие собственное производство, сначала внимательно изучают теоретические основы проектирования, чтобы повысить эффективность компании, минимизировать ненужные расходы, понизить себестоимость выпускаемой продукции. Любое действие, при совершении которого можно разработать новое интересное дело, называют проектной технологией. Министерством образования Российской Федерации были разработаны образовательные стандарты второго поколения, в которых проектные методики являются обязательным условием формирования гармонично развитой личности.
В основе RUP лежат следующие принципы:
Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).
Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Жизненный цикл разработки
RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций:
Графическое представление процесса разработки по RUP
Анализ объекта автоматизации. Методологии анализа. ARIS.
Методология
Среди большого количества возможных методов описания можно выделить следующие:
eEPC (англ. extended event-driven process chain ) - метод описания процессов;
ERM (англ. entity - relationship model ) - модель «сущность-связь» для описания структуры данных;
UML (англ. unified modeling language ) - объектно-ориентированный язык моделирования.
Формирование нормативных документов на основании моделей ARIS (например, паспорт процесса, регламент процесса).
Формирование аналитических отчётов на основании моделей ARIS.
Интеграцию ARIS Toolset с другими приложениями и базами данных.
Формирование базы моделей ARIS на основании готовых спецификаций.
Концепция архитектуры ARIS.
Архитектура ARIS создает основу для разработки и оптимизации интегрированных информационных систем, а также для описания их реализации. Выбор уровней и типов описаний формирует архитектуру ARIS, которая используется в качестве модели для построения процессов, связанных с управлением бизнесом, их анализа и оценки.Типы моделей.
В ARIS представлены более 100 видов моделей. Как выбрать наиболее подходящие с точки зрения подхода к описанию деятельности предприятия?Как правило, в основе описания бизнес-процессов лежат цепочки процессов. Цепочки могут описаны как диаграммой VAD, которая рассматривает процесс со стратегических точек зрения и детальные диаграммы eEPC (от Extended Process Chain - расширенная цепочка процесса). eEPC-диаграммы являются стержнем, который описывает ход каждого процесса на предприятии (конечно когда рассматривается процессный аспект деятельности).
Потребности в моделировании организационно-штатных структур покрывают различные диаграммы, в том числе диаграмма Organization Chart - модель орг. структуры предприятия.
Потребности в моделировании данных и информационных хранилищ могут быть обеспечены при использовании всевозможных ERM- и UML-диаграмм. Эти диаграммы дают полное представление о структуре данных и составе информационных средств предприятия.
Функциональные модели предназначены для моделирования функциональной структуры, когда процессный подход не применим или недостаточно укрепил позиции в организации.
Существуют модели выходов/управления, которые не рассматриваются в программных средствах ARIS, но занимают не менее важное место в процессе моделирования. Эти диаграммы содержатся в других разделах и в каждой части здания ARIS есть свои диаграммы выходов и управления.
Некоторые диаграммы невозможно отнести к тому или иному признаку, т.к. их характеристики подпадают под многие параметры. В этом случае в ARIS активно практикуется метод "свободного" моделирования, когда используются те диаграммы, которые интуитивно понятны, как специалистам в области консалтинга, так и руководству и программистам, реализующим отдельные программные модули.
Таким образом, мы зафиксировали в архитектуре ARIS набор типов моделей, каждая из которых «расписывается » по уровням. Вместе с описанием проблем бизнеса, которое служит стартовой точкой для анализа, они составляют тринадцать компонент архитектуры ARIS. Теперь необходимо выбрать и представить методы описания каждой компоненты архитектуры.
Критерии для выбора этих методов следующие:
простота и выразительность средств изображения,
поддержка смыслового содержания, для отображения специфики предмета,
возможность использования полного набора методов для различных типов приложений,
степень знакомства с методами и наличие необходимой литературы,
определенная степень независимости методов от технической реализации в информационных и коммуникационных системах.
ARIS - это одновременно и нотация, и методология, и программный продукт, и архитектура. Когда говорят ARIS, то человек, прочитавший данную статью и другие книги, например, выпущенные компаниями "Весть-Мета Технология" и "Логика Бизнеса", всегда уточнит, о чем идет речь.
20 . Процессы проектирования. Проектирование системной архитектуры.
Проектирование - процесс разработки проекта , то есть комплекта документации, предназначенной для создания определённого объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых был разработан данный объект. Проектирование - длительный процесс и включает этапы от подготовки технического задания до испытания опытных образцов.
Проектирование, независимо от его содержания, это составная часть планирования.
Объектом проектирования может быть материальный предмет, выполнение работы, оказание услуги.
Проектирование обладает своей методологией , которая включает структуру деятельности, принципы и нормы деятельности, субъектов , объект и его модели , методы и др.
Системное проектирование комплексно решает поставленные задачи, принимает во внимание взаимодействие и взаимосвязь отдельных объектов-систем и их частей как между собой, так и с внешней средой, учитывает социально-экономические и экологические последствия их функционирования. Системное проектирование основывается на тщательном совместном рассмотрении объекта(модели, элементная база) проектирования и процесса(структура, принципы,законы,методы) проектирования, которые в свою очередь включают ещё ряд важных частей,
21. ПП. Методики описания системной архитектуры.
Системное проектирование должно базироваться на системном подходе. На сегодняшний день нельзя утверждать, что известен его полный состав и содержание применительно к проектной деятельности, однако можно сформулировать наиболее важные из них:
Практическая полезность:
деятельность должна быть целенаправленной , устремленной на удовлетворение действительных потребностей реального потребителя или определенной социальной, возрастной или иной групп людей;
деятельность должна быть целесообразной . Важно вскрыть причины, препятствующие использованию существующих объектов для удовлетворения новых потребностей, выявить вызывающие их ключевые противоречия и сконцентрировать усилия на решении главных задач;
деятельность должна быть обоснованной и эффективной . Разумным будет использование не любого решения задачи, а поиск оптимального варианта ;
Единство составных частей:
целесообразно любой объект, сложный ли он или простой, рассматривать как систему , внутри которой можно выделить логически связанные более простые части - подсистемы , единство частных свойств которых и образует качественно новые свойства объекта-системы;
разрабатываемые объекты предназначены для людей, ими создаются и эксплуатируются. Поэтому человек также обязан рассматриваться в качестве одной из взаимодействующих систем. При этом должно приниматься во внимание не только физическое взаимодействие, но и духовно-эстетическое воздействие;
внешняя, или как её ещё называют - жизненная среда , также должна рассматриваться в качестве системы, взаимосвязанной с проектируемым объектом;
Изменяемость во времени:
учёт этапов жизненного цикла объекта;
учёт истории и перспектив развития и применения разрабатываемого объекта, а также областей науки и техники, на достижениях которых базируются соответствующие разработки.
22. ПП. Архитектурные стили и шаблоны проектирования.
Шаблон (нем. Schablone) - в строительстве приспособление или инструмент для вытягивания профильного карниза.
Шаблоны проектирования (паттерн, англ. design pattern) - это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения. Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код, скорее это описание или образец для того, как решить задачу, таким образом, чтобы это можно было использовать в различных ситуациях. Объектно-ориентированные шаблоны зачастую показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться. Алгоритмы не рассматриваются как шаблоны, так как они решают задачи вычисления, а не проектирования.
В 70-х годах двадцатого века архитектор Кристофер Александер (Christopher Alexander) составил набор шаблонов проектирования. В области архитектуры эта идея не получила такого развития, как позже в области программной разработки.
Архитектурный стиль, иногда называемый архитектурным шаблоном – это набор принципов, высокоуровневая схема, обеспечивающая абстрактную инфраструктуру для семейства систем. Архитектурный стиль улучшает секционирование и способствует повторному использованию дизайна благодаря обеспечению решений часто встречающихся проблем. Архитектурные стили и шаблоны можно рассматривать как набор принципов, формирующих приложение.
К ним относят такие шаблоны как клиент/сервер, многоуровневая архитектура, компонентная архитектура, архитектура, основанная на шине сообщений, и сервисно-ориентированная
В следующей таблице перечислены основные фокусные области и соответствующие архитектурные стили.
архитектура
23. ПП. Проектирование информационной архитектуры.
Информационная архитектура – систематизация информационного содержимого сайта и навигации по нему.
Цель информационной архитектуры – упрощение поиска нужной информации при помощи грамотно размещенных гиперссылок и организация комфортного пребывания посетителя на сайте.
Проектирование информационной архитектуры состоит из анализа содержимого ресурса и процесса разработки его структуры, которая будет помогать пользователю, находить необходимую информацию (например, поиск нужного товара, получение ответа на вопрос и др.).
Сайт, имеющий правильно спроектированную информационную архитектуру, имеет следующие достоинства:
высокое положение в индексе поисковых систем: информационная архитектура выделяет ключевые элементы, используемые поисковыми системами для вычисления релевантности страниц (например, названия страниц, ключевые слова и фразы, названия каталогов, файлов и др.);
улучшение Usability: информационная архитектура упрощает работу с ресурсом (оптимальное расположение ключевых элементов навигации);
файлы удобно размещены и разбиты по категориям, как следствие, меньше затрачивается времени на их поиск;
пропадает необходимость полного обновления сайта при добавлении новых материалов.
Модель сущность-связь (ER -модель) (англ. entity - relationship model , ERM) - модель данных , позволяющая описывать концептуальные схемы предметной области .
ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных . С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER -диаграмма)
Нотация Питера Чена
Множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью.Процесс формирования логической модели включает в себя следующие работы:
определение атрибутов (Attributes);
уточнение состава сущностей области хранения детальных данных (System of Records);
сопоставление данных систем-источников атрибутам сущностей логической модели данных;
определение иерархий (Hierarchy);
определение состава и типов медленно меняющихся измерений (SCD);
определение основных бизнес-запросов (Business Queries) - групп запросов пользователей к определенному набору данных;
проведение GAP-анализа:
анализ логической модели (с учетом имеющихся данных в системах-источниках) на предмет выявления требований, которые не могут быть удовлетворены;
принятие решений по требованиям, которые не могут быть удовлетворены;
определение состава и структуры агрегатов (Summary Area), витрин данных (Data Marts);
определение состава значений (Domains) для измерений и иерархий;
формирование рабочего документа с описанием логической модели;
проведение внешнего аудита модели - сопоставление логической модели и требований на уровне показателей;
согласование логической модели с функциональными специалистами Заказчика.
Физическое проектирование - создание схемы базы данных для конкретной СУБД . Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.
Процесс формирования физической модели заключается в:
определении правил наименования объектов базы данных;
разработке объектов хранения (таблиц, материализованных представлений, кубов и т.п.);
определении состава полей (Columns) и их типов данных (Data Types);
формирование первичных (Primary Keys) и внешних ключей (Foreign Keys);
уточнении состава значений (Domains) для измерений и иерархий;
проектирование состава и структуры разделов (Partitions), индексов (Indexes), последовательностей (Sequences) и т.д.
формирование рабочего документа с описанием физической модели;
согласование физической модели с техническими специалистами Заказчика.
Мы уже отмечали выше актуальность интеграции приложений и использования общих компонент информационных систем (сервисов). Отражением этого факта является существующая тенденция выделения данных аспектов в отдельные области архитектуры предприятия. Существенную роль при реализации этих областей играют стандартизованные элементы.
Подобно тому, как проект здания может включать в себя элементы ранее созданных конструкций, так и реализация поддержки бизнес-процесса в информационной системе может использовать уже известные фрагменты программного кода и/или типовые конфигурации оборудования. Это позволяет, с одной стороны, значительно сократить сроки выполнения решения, с другой – уменьшить риски за счет использования фрагментов, проверенных на практике. Фактически речь идет о выборе и использовании подходящих шаблонов (patterns). Английский термин "pattern" имеет различные варианты перевода, в том числе "образец", "шаблон" и т.п. В данном случае мы будем использовать русский термин "шаблон", оставляя кальку "паттерн" для обозначения аналогичных объектов в области программной архитектуры. Шаблоны являются как бы проверенными способами построения какой-то части системы.
Одним из удачных определений шаблонов является следующее: "Шаблон – это общее решение некоторой повторяющейся проблемы в определенном контексте" .
Рис. 7.7.
Шаблон – решение проблемы в контексте
То есть важным аспектом, связанным с шаблонами, является то, что они сопровождаются определенными обоснованиями того, почему данное решение является хорошим в условиях заданного контекста. Шаблоны являются следующим шагом в понимании и применении моделей. Шаблон показывает, что делает некоторую модель хорошим решением и как создать некоторое решение для определенной проблемы.
Осознание важности шаблонов привело к тому, что, например, методика описания архитектуры Gartner выделяет шаблоны в качестве отдельного "слоя" архитектуры.
Использование шаблонов имеет явные корни в строительной архитектуре. Определяющий вклад в формирование исходного понятия "pattern" принадлежит известному архитектору Кристоферу Александеру. В своей фундаментальной работе 1987 года он выделил более 250 типовых архитектурных решений, таких как лестницы, альковы, связи между офисами и др. Согласно Александеру, каждый такой прототип фактически определяет рекомендуемое решение отдельной проблемы в фиксированном контексте. В оригинале Александер выделяет контекст, воздействующие силы и особенности применения данного шаблона. В соответствии с аллегорическим комментарием Коупа, описание шаблона – это пьеса. Контекст задает место действия и определяет актеров, силы плетут заговор, найденное решение обеспечивает Катарсис.
Исходной целью этих работ Александера была не разработка каких-то новых идей, а, напротив, анализ накопленного опыта строительства – как отдельных зданий, так и целых городов – с целью выявления удачных архитектурных решений и способствовавших этому факторов. Конечно, критерии определения удачности в данной области во многом субъективны, так как зависят от общества, использующего данные постройки. В области информационных технологий такими критериями могут быть полнота выполнения требований, долговечность, эффективность реализации, а также, в соответствии с , ориентация, прежде всего, на расширение, а не на ограничение возможностей организации. Еще одним важным понятием из строительной архитектуры, которое нашло свое отражение в сфере информационных технологий, стал язык шаблонов (Pattern Language). В соответствии с определением Коупа, он является коллекцией взаимодействующих между собой шаблонов, образующих систему.
В приведенном выше определении шаблона имеется три ключевых словосочетания:
Общее решение. Это означает, что шаблон не дает полного законченного решения. Он, скорее, определяет класс проблемы и то, как эта проблема может быть решена с использованием определенного подхода, с демонстрацией аргументов в пользу этого подхода. Сила шаблона состоит в том, что он сформулирован на достаточно высоком уровне абстракции, чтобы быть использованным в большом количестве ситуаций;
Повторяющаяся проблема. Это означает, что шаблоны используются в тех случаях, когда проблема не является уникальной, и они наиболее полезны для решения часто встречающихся проблем;
Определенный контекст. Это означает, что шаблон обеспечивает решение проблемы, границы которой в общих чертах определены. Понимая условия, в которых предлагаемое решение в форме шаблона является хорошим, вы далее строите свое собственное решение на основе этого шаблона.
В отношении информационных технологий можно сказать, что шаблоны являются логическими моделями технологий: это проектировочные идеи, которые могут быть многократно использованы в рамках предприятия в целом . Как правило, эти решения служат, в каком-то смысле, индустриальными стандартами и обычно существуют продолжительное время. Их можно рассматривать как некоторые схемы, которые определяют компоненты решения, т.е. логический уровень проектирования (например, сервер данных или сервер приложений), и которые показывают роли, взаимодействия и связи компонент на этом уровне абстракции.
Когда мы говорим о шаблонах, то речь не идет о конкретных моделях аппаратного или программного обеспечения. Как проиллюстрировано рисунком 7.8, интерес представляет другое: как серверы взаимодействуют между собой и как они совместно обеспечивают работу с системой клиента, использующего персональный компьютер? Какие роли играет каждый компонент? Какие типы коммуникаций необходимы между ними?
Рис. 7.8.
Шаблон показывает взаимодействие компонент системы между собой
Важность шаблонов для архитектуры предприятия в целом обусловлена следующими причинами:
если используются корректные шаблоны, то вероятность получения адекватно работающей физической реализации архитектуры возрастает;
разработка и использование шаблонов в рамках предприятия в целом обеспечивает преимущества, связанные с их многократным использованием для решения различных проблем. Это дает архитекторам возможности по использованию опыта и стандартизации решений при создании новых систем;
использование шаблонов отделяет логический уровень от физического уровня архитектуры. Это позволяет создать долговременно работающие решения и придает гибкость, поскольку на последующем этапе эти достаточно постоянные конструкции могут быть связаны с конкретными технологическими решениями.
Рис. 7.9.
Архитектура, шаблоны и модели
В рамках предприятия целесообразно создать репозиторий шаблонов. Характерное для предприятия число различных шаблонов составляет порядка 30. Это включает шаблоны использования унаследованных и старых клиент/серверных систем, модели для будущей архитектуры (например, сервис-ориентированной) и т.д.
Описание шаблонов может выполняться с различной степенью детализации и соответствия реальным условиям. В зависимости от этого уровня можно рассматривать элементы языка шаблонов различной степени абстракции – идиомы, шаблоны дизайна (design patterns) и рамочные модели (frameworks). При этом идиомы представляют собой шаблоны самого "низкого уровня", которые зависят от конкретной технологии. Шаблоны дизайна обладают определенной независимостью, но в то же время не могут рассматриваться как система в целом. Хорошим примером являются шаблоны стандартных классов. Например, понятие "Фабрики Объектов" в объектно-ориентированных приложениях, вообще говоря, не зависит от выбора конкретного языка программирования и может быть реализовано схожим образом и на С++, и на Java. Наконец, рамочные модели представляют собой "частично законченные" системы, которые либо демонстрируют наиболее принципиальные элементы реализации, либо являются полностью работоспособными системами для определенных упрощенных, ограниченных или идеализированных внешних условий. Эти модели могут быть использованы как основа для специализированных доработок, а также для быстрого создания модели системы в целом на основе таких отдельных компонент.
Далее концепция шаблонов была расширена и в область инфраструктуры, так что теперь можно вести речь о соответствующих комплексных программно-аппаратных решениях. Для нашего рассмотрения наибольший интерес представляют шаблоны достаточно высокого уровня. Применение таких решений значительно облегчает задачу реализации новых элементов информационных систем. Каждый такой шаблон может объединять конкретное прикладное ПО, операционную систему, сервер СУБД, аппаратную платформу или несколько распределенных платформ, интерфейсы, метаданные и т.п. Типичными примерами являются шаблон B2B (Business-to-Business) для взаимодействия с Клиентами/Поставщиками или B2E (Business-to-Employee), описывающий взаимодействие между информационной системой и сотрудниками.
Инфраструктурные шаблоны можно определить как стандартизированный набор требований, компонент и сервисов, которые в совокупности формируют необходимую адекватную инфраструктуру для данной прикладной системы и реализации логики бизнес-процессов . Рисунок 7.10 иллюстрирует общее определение инфраструктурного шаблона в форме многоуровневой классификации функций и примерного списка технологических компонент на каждом уровне.
Рис. 7.10.
Пример инфраструктурного шаблона
Организация инфраструктуры с помощью набора шаблонов позволяет единообразно определять компоненты и функциональные возможности, в результате чего эта часть ИТ-инфраструктуры может многократно использоваться для различных типов прикладных систем, имеющих общие требования к инфраструктуре. Это соответствует тому принципу, который мы сформулировали в лекции 6 , когда говорили о том, что различные стили и типы прикладных систем и бизнес-процессов предъявляют различные требования к инфраструктуре. Таким образом, вместо того, чтобы строить инфраструктуру для каждого приложения, ее разрабатывают как набор нескольких шаблонов, каждый из которых оптимально предназначен для определенной группы прикладных систем так, как показано на рис. 7.11.
Рис. 7.11.
От традиционной архитектуры – к архитектуре, использующей инфраструктурные шаблоны
Большой интерес при создании бизнес-архитектуры предприятия представляют бизнес-шаблоны. В соответствии с описание бизнес-шаблона включает:
описание поддерживаемой бизнес-функции;
данные, которые требуются для выполнения описанной бизнес-функции;
бизнес-компоненты, которые являются представлением данных и функций бизнеса на языке информационных технологий;
возможно, описание инфраструктуры, которая необходима для поддержки функций, данных и компонент.
В качестве другого примера рассмотрим возможности предложенных компанией IBM "шаблонов для электронного бизнеса" .
Так как практически все приложения для электронного бизнеса сталкиваются с необходимостью решения таких вопросов, как масштабируемость, надежность, доступность, безопасность, то представляется, что использование относительно небольшого числа стандартизованных решений может оказаться полезным. Эти решения можно, в свою очередь, подразделить в зависимости от уровня абстракции – соответственно на бизнес-шаблоны, архитектурные шаблоны, шаблоны уровня приложений и т.п. При этом:
бизнес-шаблоны (Business pattern) предназначены для описания взаимодействия между участниками процесса;
шаблоны дизайна (Design pattern) отражают внутреннюю компонентную структуру системы;
шаблоны уровня приложений (Application pattern) определяют различные варианты взаимодействия между пользователями, приложениями и данными в системе, а также соответствующий прототип уровня выполнения;
шаблоны уровня выполнения (Runtime pattern) описывают привязку компонент системы к физическим узлам и определяют конкретные возможные продукты и их комбинации.
Кроме этого, выделяют также два служебных шаблона: соответственно интеграции доступа и интеграции приложений.
Эти шаблоны предназначены для описания таких типовых областей, как:
интерактивная – взаимодействие пользователя с предприятием (например, продажа товаров и услуг не по каталогам) – U2B;
программное взаимодействие между приложениями различных предприятий (B2B);
коллективная работа пользователей, включая электронную почту, обмен мгновенными сообщениями, общие форумы и т.п. – U2U;
поиск информации в каталогах и базах данных, анализ данных, подписки – U2D;
взаимодействие между приложениями "в рамках предприятия", в том числе и не обязательно с использованием web-интерфейсов;
централизованный доступ к системе на уровне выбранного интерфейса (портал) или на более общем уровне (Web, речевая телефония, мобильные устройства и т.п.);
обеспечение безопасности.
Для реализации на практике единой архитектуры предприятия особое значение приобретают шаблоны интеграции приложений. Прежде всего, стоит выделить две категории, связанные с уровнем реализации взаимодействия, – интеграция на уровне процессов и интеграция на уровне данных. Первая категория используется, если данные из одного процесса непосредственно используются в другом процессе, связанном с первым. Примером может служить использование средств обмена сообщениями для гарантированной доставки данных из филиала банка в центральное отделение. Другая категория связана с синхронизацией данных между несвязанными непосредственно между собой процессами (например, загрузка агрегированных данных из системы биллинга клиентов в систему управления маркетингом).
Собственно шаблоны строятся на основе набора предварительно определяемых общих служб, которые могут входить в шаблон в необходимой комбинации. Примерами таких общих служб могут являться:
преобразование данных (в частности, объединение/разделение, подстановки, округления, перевод c языка на язык, использование XSL для преобразования XML->XML и т п);
маршрутизация сообщений (в том числе оптимизация маршрута, мультипликация/демультипликация для доставки один-ко-многим, динамическая маршрутизация в зависимости от содержания и т.п.);
гарантированная доставка;
репозиторий сообщений и метаданных;
управление транзакциями, в том числе распределенными;
планирование задач и активностей;
журналирование и аудит;
управление нагрузкой (в том числе поддержка кластеров, динамическая балансировка, горячая замена и т.п.);
управление системами, в том числе обнаружение ошибок, мониторинг параметров;
служба каталогов;
безопасность, включая шифрование данных.
Рис. 7.12.
Категоризация архитектурных шаблонов Microsoft
При этом область шаблонов как бы "ограничена сверху" за счет включения в рассмотрение только реляционных баз данных, многоуровневой (layered) архитектуры объектно-ориентированных приложений и N-звенных систем. За счет такого ограничения (в частности, из рассмотрения исключены OLAP-системы и монолитные или исполняемые на одной платформе приложения) удается достичь существенной глубины проработки. В состав набора входят шаблоны для представления информации через Web, поддержки распределенных систем, предоставления сервисов, обеспечения производительности и надежности систем.
28. ПП. Проектирование программной архитектуры.
Введение
Процесс проектирования организационных систем основан на совместном применении взаимодополняющих методов. Одной из важнейших задач управления на современном этапе является исследование и совершенствование методологии проектирования организационных систем в соответствии с изменяющимися условиями.
Научно обоснованное проектирование организационных систем – актуальная задача современного этапа адаптации хозяйствующих субъектов к рыночной экономике. В новых условиях необходимо широко использовать принципы и методы проектирования организации на основе системного подхода.
Без развития методов проектирования организационных систем будет затруднено дальнейшее совершенствование управления и повышение эффективности производства. В новых условиях в целом ряде случаев нельзя оперировать старыми организационными формами, которые не удовлетворяют требованиям рыночных отношений, создают опасность деформации самих задач управления. Создание структуры должно опираться не только на опыт, аналогию, привычные схемы и интуицию, но и на научные методы организационного проектирования.
1. Методология проектирования организационных систем
Процесс организационного проектирования состоит в последовательности приближения к модели рациональной структуры управления, в котором методы проектирования играют вспомогательную роль при рассмотрении, оценки и принятия к практической реализации наиболее эффективных вариантов организационных решений.
Проектирование организационных систем – сложный процесс. Специфика подобного проектирования заключается в том, что нет однозначного критерия оптимальности. Как всякая многокритериальная проблема, она для своего решения требует сочетания различных методов.
Методы проектирования организационных систем:
· Системный подход;
· Метод аналогий (метод функционального моделирования);
· Нормативный метод (или экспертно-аналитический метод);
· Метод структуризации целей;
· Метод организационного моделирования.
Системный подход основан на представлении о системе как о чём-то целостном, обладающем новыми свойствами по сравнению со свойствами составляющих её элементов. Новые свойства при этом понимаются очень широко. Они могут выражаться, в частности, в способности решать новые проблемы или достигать новых целей. Для этого требуется определить границы системы, выделив её из окружающего мира, и затем соответствующим образом изменить и преобразовать.
Основные принципы системного подхода:
· Целостность, позволяющая рассматривать одновременно систему как единое целое и в то же время как подсистему для вышестоящих уровней.
· Иерархичность строения, то есть наличие множества (по крайней мере, двух) элементов, расположенных на основе подчинения элементов низшего уровня элементам высшего уровня. Реализация этого принципа хорошо видна на примере любой конкретной организации. Любая организация представляет собой взаимодействие двух подсистем: управляющей и управляемой. Одна, как правило, подчиняется другой.
· Структуризация, позволяющая анализировать элементы системы и их взаимосвязи в рамках конкретной организационной структуры. Как правило, процесс функционирования системы обусловлен не столько свойствами её отдельных элементов, сколько свойствами самой структуры.
· Множественность, позволяющая использовать множество кибернетических, экономических и математических моделей для описания отдельных элементов и системы в целом.
Системный подход - это подход, при котором любая система рассматривается как совокупность взаимосвязанных элементов (компонентов), имеющая выход (цель), вход (ресурсы), связь с внешней средой, обратную связь. Это наиболее сложный подход.
Развернутое определение системного подхода включает также обязательность изучения и практического использования следующих восьми его аспектов:
1. системно-элементного или системно-комплексного, состоящего в выявлении элементов, составляющих данную систему. Во всех социальных системах можно обнаружить вещные компоненты (средства производства и предметы потребления), процессы (экономические, социальные, политические, духовные и т. д.) и идеи, научно-осознанные интересы людей и их общностей;
2. системно-структурного, который заключается в выяснении внутренних связей и зависимостей между элементами данной системы и позволяет получить представление о внутренней организации (строении) исследуемой системы;
3. системно-функционального. Предполагает выявление функций, для выполнения которых созданы и существуют соответствующие системы;
4. системно-целевого, означающего необходимость научного определения целей и подцелей системы, их взаимной увязки между собой;
5. системно-ресурсного. Заключается в тщательном выявлении ресурсов, требующихся для функционирования системы, для решения системой той или иной проблемы;
6. системно-интеграционного, состоящего в определении совокупности качественных свойств системы, обеспечивающих её целостность и особенность;
7. системно-коммуникационного, означающего необходимость выявления внешних связей данной системы с другими, то есть, её связей с окружающей средой;
8. системно-исторического, позволяющего выяснить условия во времени возникновения исследуемой системы, пройденные ею этапы, современное состояние, а также возможные перспективы развития.
Практически все современные науки построены по системному принципу. Важным аспектом системного подхода является выработка нового принципа его использования - создание нового, единого и более оптимального подхода (общей методологии) к познанию.
Метод аналогий (метод функционального моделирования) заключается в использовании организационных форм управления, которые оправдали себя в организациях со схожими характеристиками. Здесь происходит выработка типовых структур управления и определение условий их применения.
Применение метода аналогий основано на двух подходах.
· Первый из них заключается в том, что выявляются главные организационные характеристики и соответствующие им организационные формы, которые эффективны для определенного набора исходных условий.
· Второй подход представляет, по сути, типизацию наиболее общих принципиальных решений построения и функционирования организаций. Типизация решений является средством повышения общего уровня организации управления. Однако типовые решения не должны быть однозначными и их необходимо регулярно корректироваться и допускать отклонения по ряду параметров.
Нормативный метод (экспертно-аналитический метод) заключается в аналитическом изучении и исследовании организации, проводимыми квалифицированными специалистами с привлечением руководства организации.
Данный метод имеет многообразные формы реализации:
1. Диагностический анализ проблем и «узких мест» в управлении;
2. Проведение экспертных опросов;
3. Применение научных принципов формирования организационных систем;
4. Разработка графических и табличных описаний процессов управления и организационных структур.
Метод структуризации целей предусматривает выработку целей организации и оценку организационных систем с точки зрения соответствия их системе целей.
Использование этого метода предусматривает выполнение следующих этапов:
1. Разработка дерева целей исходя из конечных результатов;
2. Экспертный анализ предлагаемых вариантов организационных систем с точки зрения обеспечения целей;
3. Составления карт прав и ответственности за достижение целей.
Метод организационного (параметрического) моделирования представляет собой разработку формализованных математико-кибернетических, графо-аналитических, математико-статистических и натуральных моделей организационных структур. С помощью данного метода происходит синтез организационных систем на основе анализа и исследования сложившихся соотношений между характеристиками организации управления и систем управления.
Процесс проектирования основан на совместном применении вышеперечисленных методов. Выбор определенного метода зависит от характеристики организации, от возможностей проведения исследований, квалификации разработчиков.
Методология проектирования организационных систем должна быть организована в соответствии с общими для любой практической деятельности закономерностями, то есть должна иметь свои фазы, стадии и этапы, свою логическую и временную структуру, а так же свои характеристики. (Рис. 1.1. отражает специфику таких этапов)
Рис. 1.1. Логика постановки и решения задачи
В основании методологии проектирования лежит культура управления качеством и непрерывных улучшений. Ее использование позволило по-новому подойти к вопросам разработки стратегии, процессов и подсистем управления. Модель организационного проектирования состоит из четырех основных этапов. (Рис. 1.2.)
Рис. 1.2. Цикл организационного проектирования систем
Этапы взаимосвязаны и образуют замкнутый цикл, в котором оценка результатов внедрения является материалом для дальнейшего моделирования изменений и улучшений действующей модели.(Рис. 1.3.)
Рис. 1.3. Этапы цикла
Для модели основа - не бюрократический способ управления, свойственный большинству крупных организаций, а менеджмент качества и культура постоянных совершенствований.
Одним из подходов к управлению крупными организациями является менеджмент качества. В основе теории менеджмента качества (МК) - фундаментальный вопрос: как обеспечить производство и продажу качественной продукции экономически эффективным образом? Основой управленческой системы становится непрерывное совершенствование всех типов производственных и организационно-управленческих процессов. Главным в моделировании организационной деятельности становится процессный подход, позволяющий с единых методологических позиций проектировать, анализировать и осуществлять поиск резервов повышения качества и эффективности процессов различной природы. Под качеством стоит понимать уровень гармонизации производственных и организационных процессов, соответствия их выходов требованиям внутренних и внешних потребителей, общесистемным целям. Полное использование резервов повышения качества и эффективности возможно только в том случае, если система организационных механизмов стимулирует коллективные действия, обеспечивает мобилизацию интеллектуального потенциала работников, осуществляющих процессы. Для этого в крупных компаниях, использующих такой стиль управления, создается система организационных политик и стандартов, стимулирующих приверженность работников корпоративным целям, взаимодействие в команде и единую корпоративную культуру.
Проектирование — процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части (ISO 24765). Результатом проектирования является проект — целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы.
Проектирование, наряду с анализом требований, является частью большой стадии жизненного цикла системы, называемой определением системы (англ. system definition). Результаты этой стадии являются входной информацией для стадии реализации (воплощения) системы (англ. system realization).
Проектирование системы направлено на представление системы, соответствующее предусмотренной цели, принципам и замыслам; оно включает оценку и принятие решений по выбору таких компонентов системы, которые отвечают её архитектуре и укладываются в предписанные ограничения.
В настоящее время существует сильная тенденция рассматривать архитектурное и детальное проектирование как различные виды деятельности; делаются попытки определить их как отдельные практики, однако эти виды проектирования в значительной мере «переплетены». Архитектурные решения в сравнении с «обычными» проектными решениями рассматриваются как более абстрактные, концептуальные и глобальные; они нацелены на успех всей миссии и на наиболее высокоуровневые структуры системы. Детальное проектирование, в свою очередь, определяется как процесс детализации и расширения предварительного проекта (архитектуры) до такой степени, при которой проект полностью готов к реализации.
Внутри процесса проектирования, наряду с расчетными этапами и экспериментальными исследованиями, часто выделяют процесс конструирования.
Конструирование — деятельность по созданию материального образа разрабатываемого объекта, ему свойственна работа с натурными моделями и их графическими изображениями (чертежи, эскизы, компьютерные модели). Эти модели и изображения, а также некоторые виды изделий называют конструкциями. Например, конструирование форм одежды, конструирование интерьеров, разработка конструкции машины, конструктивные и объёмно-планировочные решения объекта капитального строительства, металлоконструкция, строительные конструкции.
Виды проектирования
По отраслям деятельности
По видам разрабатываемых объектов выделяют следующие виды проектной деятельности:
Ø Проектирование технических систем, в том числе
§ техническое проектирование (технические устройства и оборудование);
§ электротехническое проектирование (электротехника и электроснабжение);
§ проектирование инженерных систем (вентиляции, газопроводов, электросетей и др.инфраструктуры);
Ø Строительство, в том числе
§ архитектурно-строительное проектирование;
§ градостроительное проектирование;
§ технологическое проектирование;
Ø Дизайн, в том числе
§ дизайн интерьера;
§ промышленный дизайн;
§ ландшафтный дизайн;
Ø Проектирование программного обеспечения;
Ø Социальное проектирование, социология (определение вариантов развития социальных процессов и явлений с целью коренного изменения конкретных социальных институтов. Применяется при проектировании новых городов и новых производств), в том числе
§ прогнозное социальное проектирование (социальная технология, ориентированная на выработку образцов решений перспективных социальных проблем с учётом доступных ресурсов и намеченных целей социально-экономического развития. Его цель — предплановое научное обоснование управленческих решений.
Ø другие виды проектирования.
По подходу к проектированию
Функциональное проектирование
Любой объект служит лишь материальным носителем функции, то есть функция — первична, объект — вторичен и создается по причине невозможности иными, нематериальными средствами удовлетворить потребности людей. Так, автомобиль нужен для перевозки грузов и людей (функция — перемещать в пространстве, создан вследствие нереальности перемещения предметов только усилием мысли), назначение ручки — писать, а книги — хранить информацию и т. д.
Наряду со словом «функция» часто используется слово «назначение», особенно при рассмотрении не технических объектов.
Функциональное проектирование нацелено, прежде всего, на создание эффективно работающего объекта. Выполнение требуемой функции — главная цель и основа разработки объекта. Во внимание принимаются, прежде всего, функциональные показатели качества и показатели надёжности.
Оптимальное проектирование
Процесс проектирования всегда подчинён необходимости учёта интересов двух групп людей: производителей и потребителей продукции (товаров, работ, услуг). Каждая из групп стремится к удовлетворению своих требований к продукции, часть из которых может быть взаимоисключающей. Также, процесс решения практической задачи всегда многовариантен, и перед разработчиком встаёт проблема аргументированного выбора окончательного варианта. Например, автомобиль должен не только обладать высокой скоростью и мощностью двигателя, но и низкой стоимостью, комфортабельностью, экологичностью, быть выгодным для производителя и т. д.
Проектирование, целью которого является не только поиск функционально эффективных решений, но и удовлетворение разных, порой противоречивых потребностей людей, обоснованный выбор окончательного варианта, стали называть оптимальным проектированием (критериальным проектированием, вариантным проектированием). Активно оно начало применяться со второй половины 20 века благодаря достижениям теории принятия решений и теории исследования операций и широкому распространению вычислительной техники, позволившим разработать соответствующие методы, в обозримые сроки просчитывать многочисленные варианты и решать сложные математические задачи.
Большое значение в оптимальном проектировании отводится подготовке на этапе технического задания полного перечня требований к разрабатываемому объекту, выделению среди них показателей качества и преобразованию наиболее важных из них в критерии оптимизации. Показателен в этой связи девиз одной японской фирмы — «Мы не создаем технику, мы создаем человека».
К типовым требованиям к научно-технической продукции относят требования функциональные (показатели назначения), надёжности, технологичности, стандартизации и унификации, ограничения вредных воздействий (эргономичность и экологичность), эстетичность, экономичность, патентно-правовые. Требования к другим видам продукции во многом совпадают с перечисленными.
Системное проектирование
К концу XX века не только существенно возросла сложность проектируемых объектов, но и их воздействие на общество и окружающую среду, тяжесть последствий аварий из-за ошибок разработки и эксплуатации, высокие требования к качеству и цене, сокращению сроков выпуска новой продукции. Необходимость учёта этих обстоятельств заставляла вносить изменения в традиционный характер и методологию проектной деятельности.
При создании объектов их уже необходимо было рассматривать в виде систем, то есть комплекса взаимосвязанных внутренних элементов с определенной структурой, широким набором свойств и разнообразными внутренними и внешними связями. Сформировалась новая проектная идеология, получившая название системного проектирования.
Системное проектирование комплексно решает поставленные задачи, принимает во внимание взаимодействие и взаимосвязь отдельных объектов-систем и их частей как между собой, так и с внешней средой, учитывает социально-экономические и экологические последствия их функционирования. Системное проектирование основывается на тщательном совместном рассмотрении объекта проектирования и процесса проектирования, которые в свою очередь включают ещё ряд важных частей.
Основные части проектирования
Принципы системного проектирования
Системное проектирование должно базироваться на системном подходе. На сегодняшний день нельзя утверждать, что известен его полный состав и содержание применительно к проектной деятельности, однако можно сформулировать наиболее важные из них:
Нисходящее и восходящее проектирование
Ведение разработки объекта последовательно от общих черт к детальным называется нисходящим проектированием. Его результатом будут требования к отдельным частям и узлам. Возможен ход разработки от частного к общему, что образует процесс восходящего проектирования. Такое проектирование встречается, если одна или несколько частей уже являются готовыми (покупными или уже разработанными) изделиями.
Нисходящее и восходящее проектирование обладают своими достоинствами и недостатками. Так, при нисходящем проектировании возможно появление требований, впоследствии оказывающихся нереализуемыми по технологическим, экологическим или иным соображениям. При восходящем проектировании возможно получение объекта, не соответствующего заданным требованиям. В реальной жизни, вследствие итерационного характера проектирования, оба его вида взаимосвязаны.
Структура проектирования
Проектирование, как осознанная целенаправленная деятельность, обладает определённой структурой, то есть последовательностью и составом стадий и этапов разработки проекта, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.
В настоящее время существуют два представления структуры проектирования, подобные по форме, но различные по целям и подходам к деятельности. Это — структура в виде стадий разработки проектной документации (стадий проектирования) и структура процесса проектирования.
§ Стадии проектирования
§ Стадии разработки проектной документации
Стадии проектирования регламентированы стандартами ГОСТ 2.103-68 и ГОСТ Р 15.201-2000. Последовательность выполнения всех стадий образует официальную структуру процесса разработки проектной документации, которая, как правило, используется при официальных взаимоотношениях между заказчиком и исполнителем или между соисполнителями работ. Сама документация необходима для отчета перед заказчиком о проделанной работе, возможности проверки или повторения разработок другими исполнителями, подготовки производства и обслуживания изделия в период эксплуатации.
Стадии создания других систем регламентируются своими стандартами, например, для автоматизированных систем — ГОСТ 34.601-90.
Структура устанавливает стадии разработки конструкторской документации на изделия всех отраслей промышленности и этапы выполнения работ внутри каждой стадии, то есть состав документации и виды работ, что помогает ответить на вопрос «Что нужно делать?» в процессе проектирования. Основные стадии структуры включают:
Эскизный проект (ЭП) — совокупность документов, содержащих принципиальные решения и дающих общее представление об устройстве и принципе работы разрабатываемого объекта, а также данные, определяющие его назначение, основные параметры и габаритные размеры. В случае большой сложности объекта этому этапу может предшествовать аван-проект (предпроектное исследование), обычно содержащий теоретические исследования, предназначенные для обоснования принципиальной возможности и целесообразности создания данного объекта.
При необходимости на стадии ЭП проводят изготовление и испытание макетов разрабатываемого объекта.
Технический проект (ТП) — совокупность документов, которые должны содержать окончательные технические решения, дающие полное представление об устройстве проектируемого объекта, исходные данные для разработки рабочей документации.
На стадии рабочего проекта (РП) сначала разрабатывают подробную документацию для изготовления опытного образца и последующего его испытания. Испытания проводят в ряд этапов (от заводских до приемо-сдаточных), по результатам которых корректируют проектные документы. Далее разрабатывают рабочую документацию для изготовления установочной серии, её испытания, оснащения производственного процесса основных составных частей изделия. По результатам этого этапа снова корректируют проектные документы и разрабатывают рабочую документацию для изготовления и испытания головной (контрольной) серии. На основе документов окончательно отработанных и проверенных в производстве изделий, изготовленных по зафиксированному и полностью оснащенному технологическому процессу, разрабатывают завершающую рабочую документацию установившегося производства.
Завершает цикл работ этап, подводящий итог проектной деятельности, — сертификация . Её назначение — определение уровня качества созданного изделия и подтверждение его соответствия требованиям тех стран, где предполагается его последующая реализация. Необходимость выделения этого этапа в виде самостоятельного вызвана тем, что в настоящее время экспорт продукции или её реализация внутри страны во многих случаях недопустимы без наличия у неё сертификата качества. Сертификация может быть обязательной или добровольной. Обязательной сертификации подлежат товары, на которые законами или стандартами установлены требования, обеспечивающие безопасность жизни и здоровья потребителей, охрану окружающей среды, предотвращение причинения вреда имуществу потребителя. Добровольная сертификация проводится по инициативе предприятий. Обычно это делается с целью официального подтверждения характеристик продукции, изготавливаемой предприятием, и, как следствие, повышения доверия к ней у потребителей.
В процессе разработки проектной документации в зависимости от сложности решаемой задачи допускается объединять между собой ряд этапов. Этапы постановки ТЗ и технического проектирования могут входить в цикл научно-исследовательских работ (НИР), а этапы технического предложения и эскизного проектирования — образовывать цикл опытно-конструкторских работ (ОКР).
Проектирование — это ещё и целенаправленная деятельность, которая обладает последовательностью процедур, ведущих к достижению эффективных решений. Соответственно, должна быть структура процесса решения задачи проектирования, которая помогает ответить на вопрос «Как это делать?». В настоящее время предложен ряд структур и алгоритмов проектирования, совпадающих в основных чертах и различающихся только в содержании или названии отдельных этапов.
Решение любой задачи начинается с её осмысления и уточнения исходных данных. Те (технические) требования (ТТ), которые выдаются заказчиком, формулируются на языке потребителя-неспециалиста и не всегда бывают технически чёткими и исчерпывающими. Перевести требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, то есть сформулировать техническое задание (ТЗ), — первый и обязательный этап работы. Исполнитель выполняет его в тесном контакте с заказчиком.
В машиностроении этот этап иногда называют внешним проектированием. Этим подчеркивают, что разработка объекта уже начинается с постановки задачи (ТТ) и формирования ТЗ и активно ведётся совместно с заказчиком. Важным результатом этапа является согласование целей разработки и назначения проектируемого объекта (его функций), системы показателей качества.
Следующие этапы образуют внутреннее проектирование. Они нацелены на поиск решения задачи и выполняются разработчиком. Сюда входят этапы синтеза принципа действия, структуры и параметров проектируемого объекта:
На этапе синтеза принципа действия отыскивают принципиальные положения, физические, социальные и т. п. эффекты, которые составят основу функционирования будущего изделия. Это могут быть основополагающие нормы, фундаментальные законы и правила, их частные случаи или следствия. Работа ведется с принципиальными моделями и их графическим представлением — блок-схемами. Этому этапу соответствует заключительная стадия ТЗ и стадия технического предложения структуры проектирования по ГОСТ 2.103;
На этапе структурного синтеза на основе выбранного принципа действия создаются варианты начального графического представления объекта — структуры, схемы, алгоритмы, упрощённые эскизы. В соответствии с ГОСТ 2.103 этот этап включает стадию эскизного проектирования;
На этапе параметрического синтеза отыскиваются значения параметров объекта, находится численное, в том числе оптимальное, решение проектной задачи, создаётся подробная документация или описание объекта, чертежи изделия и его частей. Этот этап соответствует стадиям технического и рабочего проектирования.
Вследствие неполноты начальных знаний о задаче процесс проектирования — итеративен, с каждым циклом итерации цели проектирования всё более уточняются, появляется необходимость в дополнительных функциях и, как следствие, — потребность в разработке дополнительных частей и узлов. Решение частных проектных задач, дополняющих основное решение, также проводится в соответствии с представленной последовательностью.
На каждом этапе внутреннего проектирования выполняются следующие процедуры:
§ выбор модели (то есть основополагающего принципа, вида блок-схемы и расчетной схемы),
§ выбор метода решения, в том числе метода оптимизации,
§ решение,
§ анализ полученных результатов и принятие решения.
Замечено, что эффективность проектируемого объекта определяется: в первую очередь — выбранным принципом действия, во вторую — предложенной структурой и в третью — соотношением параметров.
Методы проектирования
Эвристические методы
§ Метод итераций (последовательного приближения)
§ Метод декомпозиции
§ Метод контрольных вопросов
§ Метод мозговой атаки (штурма)
§ Теория решения изобретательских задач (ТРИЗ)
§ Метод морфологического анализа
§ Функционально-стоимостной анализ
§ Методы конструирования
Экспериментальные методы
§ Цели и виды экспериментальных методов
§ Планирование эксперимента
§ Машинный эксперимент
§ Мысленный эксперимент
Формализованные методы
§ Методы поиска вариантов решений
§ Методы автоматизации процедур проектирования
§ Методы оптимального проектирования
Проектирование — это один из видов работ, результатом которых является продукция-проект. Поэтому участников этих работ можно разделить на потребителей (заказчиков проектных работ) и поставщиков (исполнителей этих работ). Исполнителя-специалиста по разработке проекта обобщенно называют проектировщиком или разработчиком. Если продукция создается для собственного потребления, то возможно соединение в одном лице заказчика и исполнителя.