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

Мышление стратегическими схемами (выработка стратегии и соблюдение
стратегии).

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

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

Мышление "образами" (образы могут быть как идеальными, так и реальными: в виде
схем, загадочных, заманчивых рисунков, т. к. в методе особое внимание обращается на
положительное влияние эмоции в процессе проектирования.

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

Течтэмы объединены в семь групп:

1. Варианты решений – определить потребность, определить необходимый элемент, представить себе решение, принять временное решение, принять окончательное решение, отменить решение;
2. Варианты суждений – предположить, взвесить, взвесить и сравнить, экстраполировать, оставить без изменения, предсказать;
3. Варианты стратегий – продолжать в том же направлении, продолжать и расширить, изменить направление, сопоставить с прошлым, сопоставить с будущим, внимательно рассмотреть, разрешить конфликт, продолжать более интенсивно, прекратить;
4. Варианты тактик – оценить риск, проверить последствия, развить, сравнить с другими решениями, разделить действие, приспособить другое решение, сосредоточиться на малом участке, разложить на компоненты, проверить возможную причину, обдумать возможность нового решения, заменить решение на противоположное, проверить другие варианты;
5. Варианты отношений – хранить решение в памяти, выявить зависимость, отсрочить принятие решения, сообщить о решении, соотнести с ранее принятым решением, проверить на избыточность, проверить на несоответствие;
6. Варианты понятий – использовать новое понятие, изменить плоскость абстракции, использовать схему стратегии, изменить точку зрения, сравнить с существующей системой, сравнить с получающейся системой, применить первичное кольцо (см. группу 5 и перечень вопросов, данный ниже), применить вторичное кольцо (см. группу 6 и перечень вопросов, данный ниже);
7. Варианты препятствий – обойти препятствие, разрушить препятствие, устранить препятствие, начать новое действие с нуля, начать новое действие с принятого решения, действовать в одном, двух, трех или многих измерениях.

"Режимы мышления" предназначены для осознания, контроля и приспособления образа мышления к задачам проектирования. Методом Мэтчетта используется перечень контрольных вопросов:

1. Какие потребности являются: жизненно важными, очень важными, важными, желательными?
2. Каковы потребности: функциональной системы, потребителя, фирмы, внешнего мира?
3. Каковы потребности на каждом из перечисленных ниже 10 этапов существования изделия: проектирование и деталировка, отработка, изготовление деталей, сборка, испытание и отладка, окончательная отделка и упаковка, сбыт, монтаж, эксплуатация и использование, тех. обслуживание и уход?
4. Какие сведения можно получить, если задать 6 основных вопросов анализа трудовых операций: что нужно сделать (потребности), почему это нужно сделать (причина), когда это нужно сделать (время), где это нужно сделать (место), кем или с помощью чего это должно быть сделано (средства), как это сделать (метод)?
5. Каким образом каждую часть проекта можно: исключить, объединить с другими частями, унифицировать, перенести, модифицировать, упростить?
6. Какие эффекты, потребности, ограничения вызовет каждая деталь комплекса в отношении любой др. детали этого комплекса?

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

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

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

Рассмотрим некоторые основные методологии и средства, которые их используют.

SADT - методология структурного анализа и проектирования (Structured Analysis and Design Technique). Основана на понятиях функционального моделирования. Является методологией, отражающей такие системные характеристики, как управление, обратная связь и исполнители.

IDEF0 - методология функционального моделирования (INTEGRATION DEFINITION FOR FUNCTION MODELING). Применяется для описания рабочих процессов (Work Flow). Разработана на основе SADT. По сути одно и тоже.

DFD - методология моделирования потоков данных. Применяется для описания обмена данными между рабочими процессами.

IDEF3 - методология моделирования потоков работ. Является более детальной по отношению к IDEF0 и DFD. Позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций.

IDEF1X - методология описания данных. Применяется для построения баз данных.

IDEF4 - объектно-ориентированная методология. Отражает взаимодействие объектов. Удобна для создания программных продуктов на объектно-ориентированных языках (например С++). Пока широкого распространения не нашла. Более широко сейчас используется UML.

UML - (Unified Modeling Language) язык визуального моделирования, основанный на объектно-ориентированном подходе. UML включает в себя двенадцать типов диаграмм, которые позволяют описать статическую структуру системы и ее динамическое поведение.

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

IDEF0 - Function Modeling - методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique);

IDEF1 - Information Modeling - методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

IDEF1X (IDEF1 Extended) - Data Modeling - методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER - Entity-Relationship) как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 - Simulation Model Design - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN - Color Petri Nets);

IDEF3 - Process Description Capture - Документирование технологических процессов, IDEF3 - методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

IDEF4 - Object-Oriented Design - методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

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

IDEF6 - Design Rationale Capture - Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения "знаний о способе" моделирования, их представления и использования при разработке систем управления предприятиями. Под "знаниями о способе" понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, "знания о способе" интерпритируются как ответ на вопрос: "почему модель получилась такой, какой получилась?" Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF7 - Information System Auditing – Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF8 - User Interface Modeling - Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интефейсов в большей степени создают внешний вид интефейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интефеса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфес для выполнения операции);

IDEF9 - Scenario-Driven IS Design (Business Constraint Discovery method) - Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

IDEF10 - Implementation Architecture Modeling - Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF11 - Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF12 - Organization Modeling - Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF13 - Three Schema Mapping Design - Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

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

Похожая информация.

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

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

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

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

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

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

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

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

По видам разрабатываемых объектов выделяют следующие виды проектной деятельности:

Ø Проектирование технических систем, в том числе

§ техническое проектирование (технические устройства и оборудование);

§ электротехническое проектирование (электротехника и электроснабжение);

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

Ø Строительство, в том числе

§ архитектурно-строительное проектирование;

§ градостроительное проектирование;

§ технологическое проектирование;

Ø Дизайн, в том числе

§ дизайн интерьера;

§ промышленный дизайн;

§ ландшафтный дизайн;

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

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

§ прогнозное социальное проектирование (социальная технология, ориентированная на выработку образцов решений перспективных социальных проблем с учётом доступных ресурсов и намеченных целей социально-экономического развития. Его цель — предплановое научное обоснование управленческих решений.

Ø другие виды проектирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основные части проектирования

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

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

Нисходящее и восходящее проектирование

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

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

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

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

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

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

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

Стадии проектирования регламентированы стандартами ГОСТ 2.103-68 и ГОСТ Р 15.201-2000. Последовательность выполнения всех стадий образует официальную структуру процесса разработки проектной документации, которая, как правило, используется при официальных взаимоотношениях между заказчиком и исполнителем или между соисполнителями работ. Сама документация необходима для отчета перед заказчиком о проделанной работе, возможности проверки или повторения разработок другими исполнителями, подготовки производства и обслуживания изделия в период эксплуатации.

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

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

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

При необходимости на стадии ЭП проводят изготовление и испытание макетов разрабатываемого объекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

§ выбор метода решения, в том числе метода оптимизации,

§ решение,

§ анализ полученных результатов и принятие решения.

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

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

Эвристические методы

§ Метод итераций (последовательного приближения)

§ Метод декомпозиции

§ Метод контрольных вопросов

§ Метод мозговой атаки (штурма)

§ Теория решения изобретательских задач (ТРИЗ)

§ Метод морфологического анализа

§ Функционально-стоимостной анализ

§ Методы конструирования

Экспериментальные методы

§ Цели и виды экспериментальных методов

§ Планирование эксперимента

§ Машинный эксперимент

§ Мысленный эксперимент

Формализованные методы

§ Методы поиска вариантов решений

§ Методы автоматизации процедур проектирования

§ Методы оптимального проектирования

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

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

Технология проектирования АСОИУ – совокупность методологии, а также методов и средств организации процесса проектирования (управление процессом разработки и модернизации проекта).
Методология проектирования представляет собой концепцию / принципы проектирования, реализуемые набором методов проектирования, поддерживаемых средствами проектирования.
Метод (подход) проектирования – алгоритм / последовательность шагов по реализации той или иной стадии создания АСОИУ.
Главный принцип построения различных систем – принцип иерархической декомпозиции включает две группы методологий:

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

Структурно-функциональная методология

В структурном анализе и проектировании используются различные модели, описывающие:

1. Функциональную структуру системы;
2. Последовательность выполняемых действий;
3. Передачу информации между функциональными процессами;
4. Отношения между данными.

Наиболее распространенными реализациями этих моделей являются:

1. Функциональная модель SADT (Structured Analysis and Design Technique);
2. Модель IDEF3;
3. DFD (Data Flow Diagrams) - диаграммы потоков данных.
4. Диаграмма «сущность - связь» (ERD - Entity-Relationship Diagram).

Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. и успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном из стандартов этого семейства - IDEF0 последняя редакция которого была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). В 2000 г. постановлением Госстандарта России был введен в действие руководящий документ РД IDEF0 – 2000, содержащий основные сведения о методологии функционального моделирования IDEF0, о ее графическом языке и методике построения и практического применения функциональных моделей организационно-экономических и производственно-технических систем. Кроме того, РД IDEF0 – 2000 устанавливает правила оформления комплекта иерархических диаграмм.

В основе методологии IDEF0 лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарии.
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. На диаграмме функциональный блок изображается прямоугольником. Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

• верхняя сторона имеет значение «Управление» (Control);
• левая сторона имеет значение «Вход» (Input);
• правая сторона имеет значение «Выход» (Output);
• нижняя сторона имеет значение «Механизм» (Mechanism).

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

Метод моделирования IDEF3 , являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними.
Единицы работы - Unit of Work (UOW) (работы) , являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками и имеют имя, обозначающее процесс действия и номер (идентификатор).
Связи IDEF3 показывают взаимоотношения работ. Все связи в IDEF3 являются однонаправленными и имеют следующие типы:

• временное предшествование,
• объектный поток,
• нечеткое отношение.

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

Диаграммы потоков данных (Data Flow Diagrams - DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.

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

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

SADT создавалось как средство моделирования систем в целом, а DFD как средство проектирования ИС, поэтому DFD более перспективно для использования, тем более DFD согласовано с ERD, поскольку в DFD присутствует описание структур данных, непосредственно используемое для построения ERD.

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

Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD) , которая впервые введена Питером Ченом в 1976 г. Базовыми понятиями ERD являются: (сущности), их свойства (атрибуты) и отношения друг с другом (связи). Кроме того, ERD связываются с такими понятиями как: мощность и тип связи, первичный и внешние ключи, индексы, нормализация диаграммы и т.д.

Объектно-ориентированная методология

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

Объектно-ориентированный подход обладает следующими преимуществам:

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

К недостаткам объектно-ориентированного подхода относятся:

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

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

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

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

Введение в унифицированный язык моделирования (UML)

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

Мощный толчок к разработке этого направления информационных технологий дало распространение объектно-ориентированных языков программирования в конце 1980-х - начале 1990-х годов. Пользователям хотелось получить единый язык моделирования, который объединил бы в себе всю мощь объектно-ориентированного подхода и давал бы четкую модель системы, отражающую все ее значимые стороны. К середине девяностых явными лидерами в этой области стали методы Booch (Grady Booch), OMT-2 (Jim Rumbaugh), OOSE - Object-Oriented Software Engineering (Ivar Jacobson). Однако эти три метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе, ОМТ-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем, Booch лучше всего подходил для стадий дизайна и разработки.
Все шло к созданию единого языка, который объединял бы сильные стороны известных методов и обеспечивал наилучшую поддержку моделирования. Таким языком оказался UML.

Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов ОМТ и Booch. Осенью 1995 г. увидела свет первая черновая версия объединенной методологии, которую они назвали Unified Method 0.8. После присоединения в конце 1995 г. к Rational Software Corporation Айвара Якобсона и его фирмы Objectory, усилия трех создателей наиболее распространенных объектно-ориентированных методологий были объединены и направлены на создание UML.

В настоящее время консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

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

UML – это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами. UML включает внутренний набор средств моделирования (модулей?) («ядро»), которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения.

Пользователям языка предоставлены возможности:

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

Синтаксис и семантика основных объектов UML

UML – это набор диаграмм, которые позволяют создавать модели сложных программных систем.
Диаграммы UML разделяются на две группы.
1. Структурные диаграммы:

• Implementation Diagram (диаграммы реализации):
  • Deployment diagram (диаграммы топологии);
  • Component diagram (диаграммы компонент).
• Class diagram (диаграммы классов);

2. Диаграммы поведения:

• Use case diagram (диаграммы вариантов использования);
• Statechart diagram (диаграммы состояний);
  • Activity diagram (диаграммы активности);
• Interaction diagram (диаграммы взаимодействия);
  • Sequence diagram (диаграммы последовательности);
  • Collaboration diagram (диаграмма сотрудничества / кооперативная диаграмма);

Диаграмма прецедентов использования (Use Case Diagram)

Вариант использования определяется, прежде всего, своим именем и типом пользователя приложения, называемого действующим лицом.
Вариант использования состоит из типичного взаимодействия между действующим лицом и приложением. Например, команда «открыть файл» будет типичным вариантом использования текстового редактора с пользователем в качестве действующего лица. Один и тот же человек или внешняя система может использовать систему несколькими разными способами, принимая роли разных действующих лиц (актеров – actors). Актеры представляют именно роли, исполняемые людьми или внешними сущностями, а не конкретных людей или сущностей.
Прецедент описывает поведение, демонстрируемое системой с целью получения значимого результата для одного или более актеров.
Для детализации прецедента составляют спецификацию.

Таблица «Примерный вид спецификации прецедента»

Имя прецедента – отглагольное существительное в стиле UpperCamelCase
Идентификатор (1.1 – прецедент.№альтернативного потока)
Краткое описание – цель прецедента
Актеры: главные актеры инициируют прецедент; второстепенные актеры – взаимодействуют с прецедентом после его инициации
Предусловия определяют условия, которые должны быть истинными для того, чтобы прецедент мог быть инициирован
Основной поток – этапы осуществления прецедента. Этапы принято записывать в виде: <номер> <кто-либо><действие> 1. Покупатель заполняет в форме свои имя и адресДля представления ответвления используется ключевое слово «Если» 2. Если покупатель выбирает «удалить позицию» 2.1. Система удаляет позицию из корзиныПовторения моделируют с помощью ключевых слов «Для» или «Пока» 3. Если система находит необходимые продукты, тогда 1.1 Для каждого найденного продукта 1.1.1 Система выводит на экран представление продукта 1.1.2 Система выводит на экран цену продукта
Постусловия определяю, какие условия будут истинными после выполнения прецедента
Альтернативные потоки – альтернативные пути в прецеденте, которые перехватывают ошибки, ответвления и прерывания основного потока (наиболее значимые с т.з. функционирования альтернативные потоки документируются отдельно).

Диаграммы вариантов использования позволяют показать специфические взаимоотношения между прецедентами:

• обобщение,
• включение и
• расширение.

Обобщение прецедентов выносит поведение, общее для одного или более прецедентов, в родительский прецедент.

Рисунок «Обобщение прецедентов»

При построении диаграмм вариантов использования необходимо:

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

Однако, на диаграммах встречается последовательное соединение прецедентов, но при этом используются специальные типы связей:
Отношение «include» устанавливаемое между прецедентами, позволяет включить поведение одного прецедента в поток другого прецедента. Это означает, что при выполнении прецедента «Просмотреть Индексную Карточку УММ» обязательно должен быть выполнен прецедент «Поиск УММ». Для обозначения отношения включения в UML используется пунктирная стрелка, направленная от исходного варианта использования (включающего) к целевому (включаемому).

Рисунок «Использование отношений «include» и «extend»»

Таблица «Структура спецификации прецедента, включающей отношение «include»»

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

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

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

Диаграммы прецедентов определяют зачем (или с какой целью) актеры взаимодействуют с системой. Прецеденты и их описание являются важнейшим артефактом этапа анализа требований.
Для того, что бы ответить не только на вопрос «Зачем происходит взаимодействие с системой? Но и как происходит взаимодействие?» необходимо будет обратиться к диаграммам взаимодействия (sequence и collaboration) и деятельности (activity).

Диаграммы взаимодействия (Interaction Diagram)

Взаимодействие актеров с системой в целом или взаимодействие отдельных модулей (классов) системы между собой происходит посредством обмена сообщениями (или запросами). Для моделирования такого взаимодействия UML включает в свой состав диаграммы взаимодействия: диаграмма последовательности действий (Sequence Diagram) и диаграмма сотрудничества (Collaboration Diagram), которые позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе. Как правило, диаграммы взаимодействия охватывает поведение объектов в рамках одного конкретного варианта использования.

Sequence Diagram (диаграммы последовательности)

Для построения диаграммы последовательности необходимо:

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

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

Если объекты разрушаются в какой-то момент для освобождения ресурсов системы, то их линия жизни обрывается в момент уничтожения. Для обозначения такого момента используется специальный символ в форме латинской буквы «X».
Объекты на диаграмме последовательности могут находиться в двух состояниях, активном - непосредственно выполняя какие-либо действия, и пассивном, ожидая сообщения от других объектов. Чтобы явно выделить подобную активность объектов, применяется фокус управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона – окончание фокуса управления (окончание активности).

Рисунок – Диаграмма последовательностей для варианта использования «Добавление файла УММ для обработки»

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

• Simple (1) - простая посылка сообщения;
• Synchronous (2) - операция происходит только в том случае, когда клиент посылает сообщение, а сервер может принять сообщение клиента;
• Самоделегирование (3) - распространенное явление в ООП, например, когда объект вызывает свой собственный (как правило, защищенный) метод;
• Balking (4) - операция происходит только в том случае, когда сервер готов немедленно принять сообщение, если сервер не готов к приему, клиент не выдает сообщение;
• Timeout (5) - клиент отказывается от выдачи сообщения, если сервер в течение определенного времени не может его принять;
• Procedure Call (6) - клиент вызывает процедуру сервера и полностью передает ему управление;
• Asynchronous (7) - клиент выдает сообщение, и, не ожидая ответа сервера, продолжает выполнение своего программного кода;
• Return (8) - определяет, что происходит возврат из процедуры;

Частота посылки сообщений может иметь два варианта:

• Periodic – сообщения поступают от клиента с заданной периодичностью;
• Aperiodic – сообщения поступают от клиента нерегулярно.

Рисунок – Виды сообщений на диаграмме последовательностей

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

Как и все прочие диаграммы UML, диаграммы последовательностей проходят две стадии детализации:

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

Рисунок – Диаграмма последовательностей для варианта использования «Добавить файл УММ для обработки»

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

Рисунок – Диаграмма сотрудничества

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

• Связь Link To Self (связь с самим собой) показывает, что объект имеет обратную связь с самим собой.
• Link Message / Reverse Link Message (передача сообщения / обратная передача) позволяет отразить связь, которая подразумевает обязательную передачу сообщения в прямом (обратном) направлении.
• Data Flow / Reverse Data Flow (поток данных) позволяет отразить связь показывающую, что происходит передача данных от одного объекта другому в прямом / обратном направлении.

Отличительной особенностью диаграммы сотрудничества по сравнению с диаграммой взаимодействия является возможность использовать более богатый набор синтаксических конструкций. На рис. смоделирована ситуация, которая предусматривает наличие у экземпляра класса «ConcreteStateA» метода «create». Метод «create» в цикле позволяет создать мультиобъект (коллекцию) «ConcreteStateB». Причем, поскольку метод «create» вызывается с аргументом, то это означает, что при создании используется конструктор с параметрами.

Рисунок – Циклы на диаграмме сотрудничества

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

Диаграмма деятельности (Activity Diagram)

Диаграммы деятельности (Activity Diagram) позволяет изобразить поток операций в системном, производственном или технологическом процессе. Диаграммы деятельности используется для моделирования прецедента в виде последовательности действий (activity), описывающих взаимодействие актера с системой. Эта диаграмма концентрирует внимание на том, какие действия выполняются и кто несет ответственность за их выполнение. Деятельность изображается на диаграмме в виде

Деятельность может быть двух типов:

• action – действие.
• send event – посылка события.

В свою очередь действие (action) может имеет имя (name) и выполняться по входу (on Entry), по выходу (on Exit), во время (Do) и при возникновении события (on Event). Семантика деятельности «Подготовка диска» в состав которого входит действие «Форматирование», которое выполняется по входу имеет след. вид:

Рисунок – Изображение действия на диаграмме деятельности

При инициализации действия по событию (on Event) можно указать имя события, передаваемые аргументы (arguments) и условие, которое должно выполниться для инициализации действия по данному событию. Семантика деятельности «Технологический процесс», включающее действие «Звонок», которое выполняется при возникновении события «ПроцессЗакончен» с аргументом «time» и условием «time=0» имеет след. вид:

Рисунок – Изображение действия с событием

Если деятельность имеет тип «send event» - послать событие, то, кроме указания момента инициализации данной деятельности (on Entry, on Exit, Do, on Event) можно указать посылаемые аргументы (Send arguments) и целевую деятельность (Send target). Действие «Звонок» деятельности «Технологический процесс» выполняется при возникновении события «ПроцессЗакончен» с аргументом «time» и условием «time=0» и заключается в посылке сообщения деятельности «Завершение процесса» с аргументами (статус и полное время). В этом случае семантика деятельности «Технологический процесс» имеет следующий вид:
Рисунок – Изображение действия с событием и условием осуществления

Диаграмма деятельности кроме собственно деятельностей (activity) может включать в свой состав:

• состояния (State),
• синхронизации (Synchronizations),
• узел решения (слияния) – decision и
• разделы (swimlanes-плавательные дорожки).

Состояние (State) – это ситуация в жизни объекта на протяжении которой он удовлетворяет некоторому условию при этом объект осуществляет определенные действия или ожидает некоторого события. Так же как и Деятельность состояние может быть двух типов: action – состояние в котором выполняется заданное действие и send event – состояние, которое посылает событие с аналогичными настройками момента перехода в состояние или посылки сообщения.

Перемещение объекта от одной деятельности (состояния) к другой отражается с помощью стрелки (transition).
Спецификация перехода включает в себя:

• событие (event) – это то, что вызывает переход от одной деятельности к другой. Имя события помещается над связью между состояниями. У события могут быть аргументы.
• защитные условия (guard conditions) – условия, наложенные на осуществление перехода. Защитные условия указываются вдоль линии перехода после имени события и заключаются в квадратные скобки.
• действие (action), которое должно быть выполнено в процессе перехода (указывается вдоль линии перехода после «/»).
• событие, которое может быть послано (send event) целевой деятельности (send target) с аргументами (send arguments)

Рисунок – Семантика условного перехода

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

Узел синхронизации (Synchronizations) предназначен для разделения потока на несколько параллельных потоков или, напротив, объединяет несколько входящих потоков на один исходящий.
Узел решения – decision должен сопровождаться указанием условия перехода в виде комментария. При этом каждая ветвь потока должна снабжаться сторожевым условием (guard condition). Он становится узлом слияния, если объединяет несколько потоков.
Разделы (swimlanes-плавательные дорожки) предназначены для разделения деятельностей с помощью их группировки по прецедентам, классам, компонентам, ролям и т.д.
Историческое состояние (обозначается «Н») – это псевдосостояние, которое восстанавливает предыдущее активное состояние в композитном состоянии. Оно позволяет композитному состоянию OpenState запоминать, какое из вложенных состояний (StopState или StartState) было текущим в момент выхода из OpenState, для того, чтобы любой из переходов в OpenState возвращался именно в это вложенное состояние, а не в начальное.

Рисунок – Изображение «Исторического состояния»

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

Рисунок – Пример построения диаграммы деятельности

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

Диаграмма классов (Class Diagram)

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

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

Например, на рис. представлена диаграмма классов основного сценария варианта использования П.1 «Добавление файла УММ для обработки», где Спецификация загрузок УММ моделирует таблицу БД, в которую будут сохраняться данные (логин пользователя, дата, имя файла) о загружаемых на сервер файлах УММ. В Спецификации УММ для каждой УММ сохраняется атрибутивная информация (название УММ, год издания, кол-во страниц и т.д.), состав которой перечислен в ТЗ.

Рисунок - Диаграмма классов варианта использования «Добавить файл УММ для обработки»

На диаграмме класс изображается в виде прямоугольника, снабженного тремя внутренними зонами: имя класса, атрибуты, операции. Операция устанавливает форму функции или процедуры (ее сигнатуру). Конкретной реализацией операции является метод. В качестве имени класса следует использовать существительное в ед. числе.

Рисунок – Изображение класса на диаграмме классов

Объекты обмениваются сообщениями через соединения - связи. Но, для того, что бы между объектами была связь, между классами этих объектов должна существовать ассоциация, так как связь между объектами – это экземпляр ассоциации между классами.
Ассоциация – это связь между классами, отражающая некоторое значимое отношение между ними.
В процессе анализа ассоциаций необходимо придерживаться принципами минимализма, поскольку, если МПО будет состоять из N классов, то теоретически между ними можно будет установить N(N-1). В этой связи, в модель включают только те ассоциации, знания о которых необходимо сохранять в течение некоторого периода.
Не только ассоциация в целом может иметь имя, но и классам на обоих концах ассоциации могут быть присвоены имена ролей, исполняемые объектами классов, когда они связаны экземпляром данной ассоциации. Стрелка показывает направление передачи информации (например, посылки сообщения) от одного объекта к другому.
Например, предположим, что компания нанимает n служащих. Ограничения кратности (множественность - multiplicity) «1» и «n» означают, что объекты Person в данный момент времени могут быть наняты только одним объектом Company и Person не могут быть безработными. Объект Company может посылать сообщения объектам Person, но не наоборот.

Рисунок – Использование символов множественности на диаграмме классов

Недооцененная кратность ограничивает гибкость приложения , например, некоторые персональные менеджеры не позволяют охранять несколько телефонов для одного человека.
Частным случаем ассоциации является ассоциация-класс (Association Class), которая обладает как свойствами класса, так и свойствами ассоциации. Ассоциация-класс – это место, где хранятся относящиеся к ассоциации атрибуты и операции.
Имена полюсов ассоциаций являются обязательными, когда класс имеет ассоциацию с самим собой (рефлексивная ассоциация), которая означает, что объекты данного класса имеют связи с другими объектами этого же класса.
Каждый объект Directory может иметь связь с объектами Directory, выступающими в роли subdirectory, число которых может меняться от 0 до n. C другой стороны у подкаталога родитель может быть только 1 или не иметься вообще. Кроме того, Directory может иметь связь с произвольным числом объектов File.

Рисунок – Пример использования рефлексивной ассоциации на диаграмме классов

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

Рисунок – Класс-ассоциация

Конкретизированные формы ассоциации (association):

• зависимость (dependency) – однонаправленная связь, показывающая, что один класс зависит от определений, сделанных в другом. Такая связь имеет место, например, если один класс использует другой в качестве параметра операции. При генерации кода к исходному классу атрибуты целевого класса добавлены не будет, но в код будет добавлен оператор типа «#include».
• агрегация (aggregation) – частный случай ассоциации, который выражает отношение целое-часть (например, автомобиль-двигатель). Агрегация является транзитивной: если А является частью В, а В – частью С, то А - часть С. Агрегация изображается с помощью ромба, который ставится около полюса, являющегося агрегатом. Жизненный цикл объекта–части совпадает с ЖЦ объекта-целого. Более сильная разновидность агрегации – это связь типа «композиция» (объединение – composition), которая накладывает на ассоциацию два дополнительных ограничения:
  • (i) составляющая часть может принадлежать не более чем одному агрегату;
  • (ii) составляющая часть получает срок жизни агрегата. Композиция обозначается закрашенным ромбом. Таким образом, агрегация – это способ встраивания нескольких объектов в один объект-контейнер и использование встраиваемых объектов для реализации методов контейнера.

Код:

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

Рисунок – Наследование на диаграмме классов

Поскольку обобщение транзитивно, экземпляр подкласса одновременно является экземпляром всех его предков, т.е. обладает значениями всех атрибутов всех классов-предков и может вызывать любую операцию, указанную у любого из его предков. Не следует создавать слишком глубокую иерархию классов, поскольку это затруднит восприятие модели – иерархия с количеством уровней не превышающих 3, как правило, всегда приемлема; 5-6 уровней иерархии может быть как приемлемо, так и нет в зависимости от особенностей проектируемой системы.
Кроме того, обобщение следует использовать только там, где по крайней мере один из подклассов обладает атрибутами, операциями или ассоциациями, неприменимыми к суперклассу. Например, не следует использовать обобщение, когда существуют подклассы одинаковые по своей сигнатуре и поведению с суперклассом (масть карты Таким образом, ассоциации типа «обобщение» позволяют обеспечить полиморфизм:
добавляя новый подкласс автоматически наследуется поведение суперкласса и, более того, новый подкласс не нарушает работу существующего класса.
Следует отметить, что некоторыми языками программирования поддерживается множественное наследование, которое позволяет классу наследовать составляющие от нескольких классов одновременно.

На рисунке показано дерево классов , в котором SubClass является подклассом (дочерним классом) по отношению к двум суперклассам (базовым классам) – SuperClass1 и SuperClass22. Object1 и Object2 – экземпляры класса SubClass, наследующие атрибуты класса SubClass (x и y). В свою очередь SubClass наследует атрибуты z и w классов SuperClass1 и SuperClass2, переопределяет3 атрибут x и добавляет атрибут y.
Таким образом, при вызове, например Object1.x или Object2.x будет использоваться атрибут SubClass.x, находящийся на один уровень выше в иерархии наследования; при вызове Object1.z или Object2.z будет использоваться атрибут SuperClass1.z, поскольку класс SuperClass1 находится левее в дереве по сравнению с SuperClass2, то SubClass будет наследовать атрибуты SuperClass1 в первую очередь. Таким образом, при использовании множественного наследования следует иметь в виду, что порядок классов, перечисленных в строке заголовка инструкции class наследующего класса, определяет порядок наследования атрибутов.

Рисунок – Множественное наследование

Рисунок – Листинг кода, демонстрирующий множественное наследование

Множественное наследование стараются избегать или путем реструктурирования модели на этапе проектирования или с помощью механизма реализации «делегирование».

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

• public (общий) – любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции;
• protected (защищенный) – только класс или потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком «#»;
• private (закрытый) – только данный класс может пользоваться закрытыми атрибутами. Обозначаются символом «-»;
• package or implementation (пакетный) – атрибут является общим в пределах пакета в котором расположен класс. Обозначаются символом «~».

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

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

Еще одной важной характеристикой атрибутов и операций классов является область действия (scope), которая определяет к чему относится данная составляющая: к объекту или к классу. У объектов есть собственные копии атрибутов, принимающих разные значения и операций. Область действия этих атрибутов и операций instance (экземпляр) – у каждого экземпляра класса есть собственное значение данного свойства. Однако иногда нужно определить атрибуты, которые имеют единственное, общее для всех объектов класса значение. Аналогично нужны операции, не относящиеся ни к одному конкретному экземпляру класса (например, операция создания объекта - конструктор). Такие атрибуты и операции имеют область действия classifier (классификатор) – все экземпляры совместно используют общее значение данного свойства (выделяется на диаграммах подчеркиванием).
В этом случае оно называется статическим.
Для группировки классов, обладающих общностью, применяют пакеты, которые являются средством организации модели в процессе разработки, повышения ее управляемости и читаемости. Диаграмма пакетов – диаграмма, содержащая пакеты классов и зависимости между ними. Кроме того, пакеты используются для представления подсистем (модулей) системы в процессе проектирования. Подсистема, включающая совокупность классов, реализует набор операций, которые определены в ее интерфейсе.

Рисунок – Диаграмма пакетов

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

Рисунок – Сопоставление пакетов проектным слоям

Каждый пакет представляет пространство имен (namespace), следовательно каждый класс внутри собственного пакета должен иметь уникальное имя. Чтобы отличить один класс от другого, можно использовать полностью определенное имя (fully qualified name), то есть имя, которое указывает на структуру, владеющую пакетом. В языке UML в именах пакетов используются двойные двоеточия, поэтому классы дат могут иметь имена System::Date.
Можно показывать только имя пакета или имя вместе с его содержимым.
Согласно концепции UML классы в пакетах могут быть открытыми (public) или закрытыми (private). Открытые классы представляют часть интерфейса пакета и могут быть использованы классами из других пакетов; закрытые классы недоступны извне. Можно сделать это, присвоив всем классам модификатор видимости private (закрытый), так чтобы они были доступны только классам данного пакета, а также создав дополнительные открытые классы для внешнего использования. Эти дополнительные классы, называемые Facades (Фасады), делегируют открытые операции другим классам пакета.

Диаграмма компонент (Component Diagram)

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

• Package (пакет) - объединяет группу компонентов в модели;
• Main program (главная программа);
• Subprogram body (тело подпрограммы);
• Package specification/body (определение/тело пакета).

Рисунок - Диаграмма компонент

Диаграмма размещения (Deployment Diagram)

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

Рисунок – Диаграмма размещения

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

Традиционная (Каскадная) методология управления проектами

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

1. Определение требований
2. Проектирование
3. Реализация (строительство, производство…)
4. Внедрение
5. Тестирование и отладка
6. Установка
7. Эксплуатация и сопровождение

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

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

Методология управления проектами PRINCE 2

PRINCE2 (Projects in Controlled Environments) так же является структурированной методологией к проектному управлению. Это одна из самых популярных методологий управления проектами, широко используемая в Великобритании в управлении как в бизнесе, так в органах власти. PRINCE2 – это процессно-ориентированная проектная методология, которая фокусируется на процессах верхнего уровня (управление, организация, контроль), а не на низших задачах (декомпозиция работ, разработка графиков). Методология PRINCE2 базируется на семи принципах, семи темах и семи процессах. Принципы являются центральным элементом методологии: если хотя бы один из них не выполняется, то нельзя говорить о том, что проект выполняется в рамках PRINCE2.

Принципы методологии PRINCE2:

1. Постоянная оценка экономической необходимости — остается ли неизменной экономическая выгода от проекта на протяжении всего жизненного цикла проекта
2. Обучение на опыте – команда проекта должна постоянно искать и изучать опыт предыдущих проектов
3. Определение ролевой модели – команда проекта должна иметь ясную организационную структуру и вовлекать подходящих людей для решения нужных задач
4. Управление по этапам – необходимо, чтобы проекты были спланированы, а также подвергались мониторингу и контролю на каждом этапе выполнения;
5. Управление по отклонениям – следует четко обозначить допустимые границы отклонений в проекте, чтобы установить границы ответственности
6. Фокус на продуктах – необходимо концентрироваться на определении и достижении качества продуктов (результатах проекта)
7. Адаптация к проектной среде – следует адаптировать процессы и инструменты управления проектом к требованиям проектной среды, а также к масштабу работ, их сложности, важности, квалификационным требованиям и степени риска

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

Аспекты методологии управления проектами PRINCE2 :

1. Обоснование проекта: какую ценность проект принесёт организации?
2. Организация : каким образом необходимо распределить роли и ответственность между членами проектной команды для того, чтобы эффективно управлять проектом
3. Качество : какие имеются требования и критерии к качеству и каким образом можно их обеспечить
4. Планы : шаги, требуемые для разработки плана, и инструменты PRINCE2, необходимые к использованию
5. Риски : каким образом менеджмент проекта будет разрешать проблему наличия неопределённостей в плане проекта и во внешней среде
6. Изменение : как руководство проекта будет оценивать влияние непредвиденных задач и изменений и реагировать на них
7. Прогресс : реализуемость проекта, выполнение планов и дальнейшее развитие проекта

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

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

1. запуск проекта
2. руководство проектом
3. инициация проекта
4. контроль этапов
5. управление созданием продукта
6. управление границами этапов
7. закрытие проекта

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

Гибкая методология управления проектом (Agile Project Management)

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

В соответствии с данной методологией управления проектами, ответственность за результат делится между тремя ролями:

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

Методология Agile является гибкой и позволяет легко изменить параметры проекта, что является значимым для таких сервисно-ориентированных проектов, как разработка программного обеспечения или графический дизайн. Но это методология не подходит для проектов со строго заданными параметрами и требованиями.

Методология быстрой разработки приложений (Rapid Application Development — RAD)

Быстрая разработка приложений (RAD) – это проектная методология, чаще всего используемая в проектах по разработке ПО, основной целью которых является быстрое и качественное создание приложения. Данная методология управления проектами выделяет 4 стадии проекта:

• Планирование
• Пользовательское проектирование
• Быстрое конструирование
• Переключение

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

• Не существует универсальной «наилучшей» методологии управления проектом – выбор определяется типом проекта и спецификой окружающей среды
• Если вы работаете над проектом с возможными небольшими изменениями содержания работ, например, в области строительства, выбирайте каскадную модель
• Для разработки программного обеспечения, графического дизайна и других сервисно-ориентированных проектов выбирайте Agile методологию
• Используйте методологию быстрой разработки приложений для небольших IT проектов с сжатыми сроками
• Если вам необходимо минимизировать риски и требуются структурированный подход в исполнении крупного или среднего масштаба проекта, выбирайте PRINCE2
• Не бойтесь использовать другие, менее популярные методологии, если они в большей степени подходят к вашему проекту

Бизнес идеи