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

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

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

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

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

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

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

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

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

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

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

В основе RUP лежат следующие принципы:

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

Жизненный цикл разработки

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

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

Графическое представление процесса разработки по RUP

1. 
   Анализ объекта автоматизации. Методологии анализа. ARIS.

ARIS (акроним от англ. Architecture of Integrated Information Systems ) - методология и тиражируемый программный продукт для моделирования бизнес-процессов организаций. Продукт и методология принадлежат немецкой компании Software AG как результат поглощения компании IDS Scheer автора методологии Августа-Вильгельма Шеера (нем. August-Wilhelm Scheer ).

Методология

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

1. 
   eEPC (англ. extended event-driven process chain ) - метод описания процессов;
2. 
   ERM (англ. entity - relationship model ) - модель «сущность-связь» для описания структуры данных;
3. 
   UML (англ. unified modeling language ) - объектно-ориентированный язык моделирования.

Технология ARIS Script позволяет в автоматическом режиме производить:

1. 
   Формирование нормативных документов на основании моделей ARIS (например, паспорт процесса, регламент процесса).
2. 
   Формирование аналитических отчётов на основании моделей ARIS.
3. 
   Интеграцию ARIS Toolset с другими приложениями и базами данных.
4. 
   Формирование базы моделей ARIS на основании готовых спецификаций.

Концепция архитектуры ARIS.

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

Типы моделей.

В ARIS представлены более 100 видов моделей. Как выбрать наиболее подходящие с точки зрения подхода к описанию деятельности предприятия?

Как правило, в основе описания бизнес-процессов лежат цепочки процессов. Цепочки могут описаны как диаграммой VAD, которая рассматривает процесс со стратегических точек зрения и детальные диаграммы eEPC (от Extended Process Chain - расширенная цепочка процесса). eEPC-диаграммы являются стержнем, который описывает ход каждого процесса на предприятии (конечно когда рассматривается процессный аспект деятельности).

Потребности в моделировании организационно-штатных структур покрывают различные диаграммы, в том числе диаграмма Organization Chart - модель орг. структуры предприятия.

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

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

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

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

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

Критерии для выбора этих методов следующие:

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

Всем этим характеристикам удовлетворяет программное обеспечение ARIS компании IDs Sheer.

ARIS - это одновременно и нотация, и методология, и программный продукт, и архитектура. Когда говорят ARIS, то человек, прочитавший данную статью и другие книги, например, выпущенные компаниями "Весть-Мета Технология" и "Логика Бизнеса", всегда уточнит, о чем идет речь.

20 . Процессы проектирования. Проектирование системной архитектуры.

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

Проектирование, независимо от его содержания, это составная часть планирования.

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

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

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

21. ПП. Методики описания системной архитектуры.

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

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

22. ПП. Архитектурные стили и шаблоны проектирования.

Шаблон (нем. Schablone) - в строительстве приспособление или инструмент для вытягивания профильного карниза.

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

В 70-х годах двадцатого века архитектор Кристофер Александер (Christopher Alexander) составил набор шаблонов проектирования. В области архитектуры эта идея не получила такого развития, как позже в области программной разработки.
Архитектурный стиль, иногда называемый архитектурным шаблоном – это набор принципов, высокоуровневая схема, обеспечивающая абстрактную инфраструктуру для семейства систем. Архитектурный стиль улучшает секционирование и способствует повторному использованию дизайна благодаря обеспечению решений часто встречающихся проблем. Архитектурные стили и шаблоны можно рассматривать как набор принципов, формирующих приложение.
К ним относят такие шаблоны как клиент/сервер, многоуровневая архитектура, компонентная архитектура, архитектура, основанная на шине сообщений, и сервисно-ориентированная
В следующей таблице перечислены основные фокусные области и соответствующие архитектурные стили.
архитектура

23. ПП. Проектирование информационной архитектуры.

Информационная архитектура – систематизация информационного содержимого сайта и навигации по нему.

Цель информационной архитектуры – упрощение поиска нужной информации при помощи грамотно размещенных гиперссылок и организация комфортного пребывания посетителя на сайте.

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

Сайт, имеющий правильно спроектированную информационную архитектуру, имеет следующие достоинства:

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

24. ПП. Построение ER модели. Виды нотаций.

Модель сущность-связь (ER -модель) (англ. entity - relationship model , ERM) - модель данных , позволяющая описывать концептуальные схемы предметной области .

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

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

Нотация Питера Чена

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

Процесс формирования логической модели включает в себя следующие работы:

• 
  определение атрибутов (Attributes);
• 
  уточнение состава сущностей области хранения детальных данных (System of Records);
• 
  сопоставление данных систем-источников атрибутам сущностей логической модели данных;
• 
  определение иерархий (Hierarchy);
• 
  определение состава и типов медленно меняющихся измерений (SCD);
• 
  определение основных бизнес-запросов (Business Queries) - групп запросов пользователей к определенному набору данных;
• 
  проведение GAP-анализа:
  • 
    анализ логической модели (с учетом имеющихся данных в системах-источниках) на предмет выявления требований, которые не могут быть удовлетворены;
  • 
    принятие решений по требованиям, которые не могут быть удовлетворены;
• 
  определение состава и структуры агрегатов (Summary Area), витрин данных (Data Marts);
• 
  определение состава значений (Domains) для измерений и иерархий;
• 
  формирование рабочего документа с описанием логической модели;
• 
  проведение внешнего аудита модели - сопоставление логической модели и требований на уровне показателей;
• 
  согласование логической модели с функциональными специалистами Заказчика.

26. ПП. Построение физической модели данных.

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

Процесс формирования физической модели заключается в:

• 
  определении правил наименования объектов базы данных;
• 
  разработке объектов хранения (таблиц, материализованных представлений, кубов и т.п.);
• 
  определении состава полей (Columns) и их типов данных (Data Types);
• 
  формирование первичных (Primary Keys) и внешних ключей (Foreign Keys);
• 
  уточнении состава значений (Domains) для измерений и иерархий;
• 
  проектирование состава и структуры разделов (Partitions), индексов (Indexes), последовательностей (Sequences) и т.д.
• 
  формирование рабочего документа с описанием физической модели;
• 
  согласование физической модели с техническими специалистами Заказчика.

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

Подобно тому, как проект здания может включать в себя элементы ранее созданных конструкций, так и реализация поддержки бизнес-процесса в информационной системе может использовать уже известные фрагменты программного кода и/или типовые конфигурации оборудования. Это позволяет, с одной стороны, значительно сократить сроки выполнения решения, с другой – уменьшить риски за счет использования фрагментов, проверенных на практике. Фактически речь идет о выборе и использовании подходящих шаблонов (patterns). Английский термин "pattern" имеет различные варианты перевода, в том числе "образец", "шаблон" и т.п. В данном случае мы будем использовать русский термин "шаблон", оставляя кальку "паттерн" для обозначения аналогичных объектов в области программной архитектуры. Шаблоны являются как бы проверенными способами построения какой-то части системы.

Одним из удачных определений шаблонов является следующее: "Шаблон – это общее решение некоторой повторяющейся проблемы в определенном контексте" .

Рис. 7.7. Шаблон – решение проблемы в контексте

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

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

Использование шаблонов имеет явные корни в строительной архитектуре. Определяющий вклад в формирование исходного понятия "pattern" принадлежит известному архитектору Кристоферу Александеру. В своей фундаментальной работе 1987 года он выделил более 250 типовых архитектурных решений, таких как лестницы, альковы, связи между офисами и др. Согласно Александеру, каждый такой прототип фактически определяет рекомендуемое решение отдельной проблемы в фиксированном контексте. В оригинале Александер выделяет контекст, воздействующие силы и особенности применения данного шаблона. В соответствии с аллегорическим комментарием Коупа, описание шаблона – это пьеса. Контекст задает место действия и определяет актеров, силы плетут заговор, найденное решение обеспечивает Катарсис.

Исходной целью этих работ Александера была не разработка каких-то новых идей, а, напротив, анализ накопленного опыта строительства – как отдельных зданий, так и целых городов – с целью выявления удачных архитектурных решений и способствовавших этому факторов. Конечно, критерии определения удачности в данной области во многом субъективны, так как зависят от общества, использующего данные постройки. В области информационных технологий такими критериями могут быть полнота выполнения требований, долговечность, эффективность реализации, а также, в соответствии с , ориентация, прежде всего, на расширение, а не на ограничение возможностей организации. Еще одним важным понятием из строительной архитектуры, которое нашло свое отражение в сфере информационных технологий, стал язык шаблонов (Pattern Language). В соответствии с определением Коупа, он является коллекцией взаимодействующих между собой шаблонов, образующих систему.

В приведенном выше определении шаблона имеется три ключевых словосочетания:

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

В области информационных технологий первоначально шаблоны получили признание в области программной архитектуры. В широко известной работе группы авторов (которых в англоязычной литературе по числу авторов книги часто называют "бандой четырех") описаны типовые конструкции для объектно-ориентированных языков программирования, таких как C++. Большое количество ссылок по данной тематике и примеров приведены на http://www.patterns.com. Но оказывается, что понятие шаблона оказывается весьма эффективно и в области архитектуры предприятия в целом!

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

Когда мы говорим о шаблонах, то речь не идет о конкретных моделях аппаратного или программного обеспечения. Как проиллюстрировано рисунком 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. От традиционной архитектуры – к архитектуре, использующей инфраструктурные шаблоны

Большой интерес при создании бизнес-архитектуры предприятия представляют бизнес-шаблоны. В соответствии с описание бизнес-шаблона включает:

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

Заинтересованным в этом вопросе читателям мы рекомендуем статью , которая опубликована в журнале Microsoft, посвященном вопросам архитектуры; в электронном виде публикацию можно найти по адресу http://msdn.microsoft.com/architecture/journ/.

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

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

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

В соответствии с предлагаемой схемой выделяются 4 основных бизнес-шаблона (см. табл. 7.1).

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

Эти шаблоны предназначены для описания таких типовых областей, как:

• 
  интерактивная – взаимодействие пользователя с предприятием (например, продажа товаров и услуг не по каталогам) – U2B;
• 
  программное взаимодействие между приложениями различных предприятий (B2B);
• 
  коллективная работа пользователей, включая электронную почту, обмен мгновенными сообщениями, общие форумы и т.п. – U2U;
• 
  поиск информации в каталогах и базах данных, анализ данных, подписки – U2D;
• 
  взаимодействие между приложениями "в рамках предприятия", в том числе и не обязательно с использованием web-интерфейсов;
• 
  централизованный доступ к системе на уровне выбранного интерфейса (портал) или на более общем уровне (Web, речевая телефония, мобильные устройства и т.п.);
• 
  обеспечение безопасности.

Шаблоны могут быть использованы по отдельности или в комбинации при реализации более сложных комплексных решений. Для идентификации классов этих решений общеупотребительным стали аббревиатуры, использующие сходное звучание в английском языке цифры 2 и отношения между двумя сторонами – системы типа B2B, B2C и т.д. Например, традиционный электронный магазин (B2C) может включать элементы прототипов U2D (User-to-Data – работа пользователя с каталогом товаров), U2B (User-to-Business – оформление заказа), U2U (User-to-User – консультация у продавца или обращение в службу поддержки).

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

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

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

Аналогичные архитектурные шаблоны в терминологии Microsoft представляют собой Решения уровня предприятия . Они группируются в виде специальной модели в соответствии с уровнем абстракции и архитектурным доменом (см. рис. 7.12).

Рис. 7.12. Категоризация архитектурных шаблонов Microsoft

При этом область шаблонов как бы "ограничена сверху" за счет включения в рассмотрение только реляционных баз данных, многоуровневой (layered) архитектуры объектно-ориентированных приложений и N-звенных систем. За счет такого ограничения (в частности, из рассмотрения исключены OLAP-системы и монолитные или исполняемые на одной платформе приложения) удается достичь существенной глубины проработки. В состав набора входят шаблоны для представления информации через Web, поддержки распределенных систем, предоставления сервисов, обеспечения производительности и надежности систем.
28. ПП. Проектирование программной архитектуры.

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

Языки описания архитектуры

Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации.

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

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

Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое внимание объектам или субъектам действия.

CASE-средства, поддерживающие объектно-ориентированное проектирование используют методологию RUP (Rational Unified Process) и нотации языка UML.

RUP – методология разработки ПО, в основе которой лежат 6 принципов:

1. Компонентная архитектура (реализуется и тестируется на ранних стадиях проекта).

2. Работа над проектом в сплоченной команде, ключевая роль в которой принадлежит архитекторам.

3. Ранняя идентификация и непрерывное устранение возможных рисков

4. Концентрация на выполнении требований заказчика.

5. Ожидание изменения в требованиях, проектных решениях и реализации в процессе разработки.

6. Постоянное обеспечение качества на всех этапах разработки проекта.

Представление системы на языке UML.

1. Представление использования – основная часть модели описания системы.

2. Логическое представление – описание функциональных возможностей системы.

3. Компонентное представление – описание структуры и взаимосвязей модулей системы.

4. Представление взаимодействия процессов– описание согласованных действий модулей системы.

5. Представление распределения – описание физической архитектуры системы.

Каждое представление состоит из диаграмм, которые строятся из своих нотаций. Для структурного подхода используется методология SADT (Structured Analysis and Design Technique). Главным разработчиком методологии был Дуглас Росс. Он разработал язык структурного анализа, используемый для описания исследуемого объекта. Этот язык лег в основу стандартов семейства IDEF . В настоящее время семейство IDEF включают следующие стандарты:

IDEF0 – стандарт функционального моделирования

IDEF1Х – стандарт моделирования потоков данных

IDEF2 – стандарт динамического моделирования систем

IDEF3 – стандарт документирования процессов

IDEF4 – стандарт построения объектно-ориентированных систем

IDEF5 – стандарт онтологического (принципиального, структурного) исследования систем.

Лекция 8. Язык UML

Диаграммы UML

Описание языка UML состоит из двух взаимодействующих частей:

1) семантики языка UML (это мета-модели, определяющие синтаксис и семантику понятий объектного моделирования на языке UML);

2) нотаций языка UML (графические нотации для визуального представления семантики языка).

Семантика определяется для двух видов объектной модели:

1) структурных моделей (они же статические модели), которые описывают структуру сущностей или компонентов системы;

2) модели поведения (они же динамические модели), которые описывают поведение или функционирование объектов системы.

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

В терминах языка UML определены следующие виды диаграмм:

1) диаграмма вариантов использования;

2) диаграмма классов (будет напоминать структуру БД);

3) диаграммы поведения (включают три вида диаграмм – диаграммы состояний, диаграммы деятельности, диаграммы взаимодействия, которые включают два вида диаграмм – диаграмма последовательности, диаграмма коопераций);

4) диаграммы реализации (включают два вида диаграмм – диаграммы компонентов и диаграммы развертывания).

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

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

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

Диаграмма реализации – физическая модель.

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

1) определение общих границ и контекста моделируемой предметной области;

2) формулирование общих требований к функциональному поведению проектируемой системы;

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

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

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

Основные элементы диаграммы:

1) действующее лицо – актер или сущность;

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

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

2) вариант использования;

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

3) отношения;

Отношение. Отношение – вариант использования представляет собой внешнюю спецификацию последовательности действий.

Здесь возможны следующие иды отношения: ассоциации, расширения, включение, обобщение.

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

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

Отношение расширения (<>) определяет взаимосвязь базового варианты использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий. Отношение расширения является отношением зависимости, то есть связью между объектами системы, при которой изменение спецификации одного объекта может повлиять на поведение другого объекта. Зависимость изображается прерывистой линией со стрелкой, направленной к объекту, от которого имеется зависимость.

Отношение включения (<>) также является разновидностью отношения зависимости, оно устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве составного фрагмента в последовательность поведения другого варианта использования. Это также пунктирная линия со стрелкой, направления от базового варианта использования к включаемому варианту использования.

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

4) примечания.

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

Глазычев В.Л.: Несколько слов, чтобы вам было немножко понятнее, с кем вы имеете дело. В команде, которая разворачивала работы в области проектирования и в области методологии, народ был с самого начала достаточно пёстрый. Мой древний приятель, (я надеюсь, вы с ним встретитесь) вышел из физики. Я когда-то кончал Московский архитектурный институт. Среди нас есть географы по происхождению. Единственное, кого почти совсем нет, это тех, кто по диплому называются философами. И Петр Георгиевич Щедровицкий кончал вовсе даже педагогический институт.

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

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

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

В школьных учебниках написано обычно много разных легенд про то, как Египет строил пирамиды. Гораздо правильнее перевернуть это сочетание слов и сказать: «Это пирамиды построили Египет». Система организации деятельности на формирование этих грандиозных сооружений, система организации труда, очень тщательно, очень тонко разведенного по разным специализациям, выступает как некий образец, в известном смысле, на все времена. И в выражении «пирамиды построили Египет» нет серьёзного преувеличения. Вот не далее, как в прошлом году, наконец раскопали некрополь, кладбище строителей пирамид. Реальное, не воображаемое. И одна из первых гробниц, уже сейчас в Интернете она предъявлена, можно посмотреть: очень трогательно, это гробница столяра, в которой одновременно представлены три его портретных изображения. Очень грубые, очень примитивные, но настоящие: где он маленький, где он юноша с пробивающимися усиками и где он зрелый муж. Как вы понимаете, если в гробнице представлена такого рода история персонажа, то все греческие байки про рабов, которые создавали пирамиды, наверное, разлетаются в пыль. Никакими рабами пирамиды построить было нельзя. Это было ясно и раньше, но сейчас просто появилось дополнительное подтверждение.

Знаете ли вы, что в организации процесса создания этих изумительных сооружений была впервые записана технология. Была сформирована система поощрения высоко производительного дофеодального труда, поэтому существовала система премий, которые выдавались лепешками, пивом, и прочим (денег же в Египте не было), была система расчленения на рабочие роты. Слово «роты» здесь наиболее точно отвечает делу. Каждой роте был придан не только врач, но и заклинатель змей от укусов. Иными словами, когда мы, не только оглядывая эти замечательные сооружения (мне это довелось делать, это достаточно сильно), но влезая под кожу процесса их создания, впервые мы сталкиваемся с тем, что некий выброшенный вперед как якорь, к которому можно притягиваться, мощный образ, имидж. В этом отношении имидж всегда является частью проекта, не обязательно основанием, но частью непременно, потянул за собой соорганизацию чрезвычайно сложной машины, составленной из десятков тысяч людей, в расчете на 10-15-20 лет непрерывного совместного производства. По крайней мере получается, что в этом отношении принципиальная проектная ориентация имеет, хочешь не хочешь, хороших пять с лишним тысяч лет истории.

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

Меня сейчас интересует другое. Бог с ними с пятью тысячами лет. Вот совсем недавно, в середине и конце 99-го года я был вовлечён в сооружение проекта, который был достаточно любопытен по структуре своей, поэтому я его постараюсь пошагово вам описать, тем более, что я был просто прямым носителем оного.

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

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

И вот тогда, сначала (по-русски нет точно такого слова, inspiration), была сформирована первая чёрточка, которая была способна или перерасти в проект, или не перерасти. И вот здесь я прошу вас на это обратить внимание. Когда говорят «проект», очень часто смешивают с ним то, что является просто ситуативной творческой находкой, увидел — сделал. В своё время мне приходилось отрабатывать долги за кооперативную квартиру, иллюстрируя журнал «Знание — сила », я с удовольствием делал его макет и картинки в него. Формирование таких картинок — классический предмет такого мгновенно вспыхивающего решения. Мгновенно, потому что времени нет, и вы не можете себе позволить месяцами думать, как положено говорить, выхаживать образ, и прочее. Картинка должна быть послезавтра, или ты «горишь» как профессионал. Возникали картинки, и некоторые из них были достаточно любопытные, и хотя общие черты, используемые в проектировании и в такого рода импровизационном художественном творчестве есть, но в действительности это совершенно разное. Такие картинки проектами не являются, и замысел этих картинок проектом тоже не является. А вот когда возникла такого рода вспышка, связанная с конкретной политической ситуацией, возникло то, что могло вырасти в проект, и выросло.

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

Было решено так: необходимо осуществить замещение задач. Задача, макро-задача, была вам знакома по недавней практике — прорыв в парламент силы, у которой не было ясно выраженной опоры. Практически не было денег, вернее, их было очень мало. Вам это тоже знакомо, тем, кто участвовал в недавней здесь политической компании, это хорошо ясно. Не было, собственно, когорты, не было ядра организаторов. Было только одно — понимание того, что необходимо заявить себя достаточно жёстко и сильно. И вот тогда возникла идея, способная превратиться в проект.

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

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

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

Слово есть: «Московская альтернатива». Есть несколько человек, готовые сыграть в эту игру, по разным соображениям. Сергей Владиленович Кириенко, по молодости лет, по разозленности на свои неполные 100 дней премьерства, понимающий опасность провалиться «в никуда» и быть забытым, ведь прошло уже достаточно много времени, — один из этих людей. Мой старый приятель Глеб Павловский — второй. Кстати, с Павловским мы когда-то начинали проект под названием «Мемориал», общество «Мемориал». Вот, и это тоже был проект достаточно интересный, драматический и просто часть моей жизни. И ещё несколько человек. Но ведь сказать слова — не значит ничего. Плюс средств заведомо ничтожно мало, и добыть их можно мало. Каким образом выражение «московская альтернатива» сделать не слоганом, не лозунгом, не выражением «вот, вы такие, а мы — альтернатива», а альтернатива — это что? Это означило соорганизовать иксы и игреки, потому что они были неизвестны заранее.

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

Выстройка системы «плюс-минус» — вещь простая. Никакого проектного мышления не требуется. Предполагается только одно: вот есть здание московской политики, и у него есть определённые значки, где стоит плюс. Кольцевая дорога — плюс, третье кольцо внутри — плюс, реально приведенный в чувство городской центр — плюс. Выстроить к этим плюсам систему минусов. Да, приведенный в порядок, причесанный центр. Но в этом центре нечего делать людям, у которых в кармане меньше десяти долларов, потому что схема, введенная в жизнь, оказалась рассчитанной на людей с толстым кошельком. А значит, из этого центра уходит жизнь. Уходит молодёжь, у которой, как правило, таких денег нет, уходит и не молодёжь, и возникает бутиковая пустыня. Фиксируем.

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

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

Сам факт появления в виртуальном пространстве Интернета площадки, на которой начинается анализ действительного существования дел за вывеской под названием «Москва», должен был вызвать неадекватную реакцию. Реакцию возмущения и иронии. Если бы наши противники, наши оппоненты были мудрее, они бы могли переиграть этот проект. Они бы могли его просто не заметить. Если бы они его проигнорировали, мы бы проиграли. Но точный расчёт был на психологию, на художественное восприятие действительности, а мэр Москвы, Юрия Михайлович Лужков — художник в душе, поэтому и возникают все эти художества в городе. Власти не могли этого стерпеть. И что начали? Начали отвечать, начали огрызаться. С этого момента они попали в ловушку. По одной простой причине. Голиаф тяжел и мощен. Бюрократическая система означает проведение сигнала, любого сигнала в течение нескольких дней, правда? Он не может сработать в секунду. По определению, сложная бюрократия должна провести сигнал снизу вверх, сверху вниз, промежуточные уровни должны его фильтровать. А маленький Давид, в виде группы проектантов, обладает мгновенной реакцией, и поэтому как только выходит статья или радиовысказывание с их стороны, ровно через 45 минут появлялся ответ. Соответственно, большая машина начинала все время стрелять по тени, по хвосту, а юркая машинка уже давно убежала вперед.

Возникла система, которая должна была породить постоянно действующую, подогреваемую интригу. При малых деньгах вы можете работать только на интриге. Более того, соединив интернет-сайт с горячей линией по телефону, а это небольшие деньги, мы получили шанс выходить на действительные источники информации, что входило изначально в проектную схему. Наш доклад по проблемам лужковской Москвы публиковался частями каждую неделю, что также было просчитано: очень важно было порционирование информации, что позволяло проводить еженедельный же брифинг для СМИ. Я опускаю множество деталей, вроде того, что мы верно сориентировались на силу неприязни ельцинской России к Москве, и потому анализ хостинга показывал: региональные и местные пользователи залезали на наш сайт чаще и больше, чем московские. Так или иначе, хотя официально мы набрали чуть более 12% голосов (по нескольким округам, где велся настоящий контроль, было было 30%), СПС прошел в парламент. Более того, в последующие полтора года московские власти более-менее верно отреагировали на дюжину ключевых претензий, содержавшихся в нашей программе.

Выйдем за рамки актуальности и собственные горизонты.

Всем известны американские автомобили «Форд». В 50-е годы у Форда начали падать продажи. Для выхода из сложившейся ситуации понадобилось внешнее отношение, видение этой компании в совокупном контексте культуры. Совершенно конкретный человек по имени Джорж Нельсон, не имеющий отношение к Форду, предложил вещь, которая сначала вызвала полный шок. Вся его идея заключалась в следующем. Почему вы не можете продать свои автомобили? Потому, что они надоели тому слою, кто покупал Форд. Люди, так сказать, средне-нижних доходов, в основном молодые профессионалы, младшие квалифицированные работники. Вы им надоели! Нужно то, что даст им ощущение свежести и новизны. Что было тогда ощущением свежести и новизны в начале 60-х годов? Начали выходить фильмы серии об агенте 007, Джеймсе Бонде. Он ездил в первых сериях на роскошной, специально сделанной машине с совершенно драгоценными спортивными колесами. Джорж Нельсон нарисовал молдинг, изображающий спицы на штампованных дисках. Он перестроил образ типового фордовского автомобиля, психологически опознаваемый как родственник машины Джеймса Бонда. Продажи форда «Мустанг» подскочили на 750, а потом на миллион автомобилей.

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

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

Вопрос: Есть ли какие-то этапы разворачивания, осуществления проекта?

Глазычев В.Л.: Это очень хороший вопрос. Почему? Потому что есть опасность спутать собственно проектную парадигму, которая предполагает живую машину. Живая машина состоит из живых людей. Если вы будете воображать себе их как отливки, вы мгновенно соскочите из проектной модальности в классическую схему линейного управления, где все выстраиваются по уставу. Поэтому «все предусмотреть» противоречит самой логике проектной ориентации. Это как в слаломе. Вы можете обойти под таким углом, под таким, с большим радиусом, с меньшим радиусом, но вам надо обойти эту вешку. Способ обхода этих вешек, это вопрос живого наполнения традиций. В этом есть принципиальное отличие от классически научной, прагматической парадигмы. Если вы ставите проектно-ориентированную задачу, вас будут интересовать не коэффициенты, вас будут интересовать правила поведения поля ценностей. Вы залезаете в совершенно чужой карман и начинаете шарить в нем для того, чтобы найти тот инструмент, с помощью которого вы имеете шанс, управляя чем-то, выстроить проектную машину изменения ситуации. Прогноз жесток, хотя и вариативен. Проект жесток по организации, но абсолютно мягок по отношению к взаимодействию и с контекстом, и с человеческой машиной, соответственно, он выстраивает план собственной реализации, тогда как сам скорее вырастает как деревце.

Есть ещё вопросы?

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

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

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

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

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

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

А что такое США? Их декларация о независимости — как проект, созданный абсолютно конкретными людьми. Адамс и Джеферсон монтировали свой образ, свой продукт из того, что было под рукой. А что было под рукой? Классические античные тексты, опыт уже нарывавшей французской революции, стремление опереться на живое чувство народа, а в ход могло идти все что угодно, вплоть до абсолютных фальшивок, вроде т.н. Бостонского чаепития. Значит, проекты уже выстраивались.

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

Чтобы было понятней. Сейчас я играю с несколькими своими друзьями в занятный тип деятельности. Формально это называется Центр стратегических исследований Приволжского Федерального Округа . Почему Приволжского совершенно понятно. Уже пройдя некий путь вместе с Сергеем Кириенко, как-то глупо бросать все на пол-дороги. Судьба поставила его в очень любопытную позицию рамки, не имеющей содержания. Идея округов, кроме того, что немного нагнуть губернаторов, никакого содержание не имела. Это ситуация для включения проектной работы.

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

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

Схема линейного управления, а любая военная схема управления является линейной, то есть по уставу, по предписанию, по долженствованию. Что это означает? Есть понятие застава. Застава вроде бы где? На границе. Но физически она же не на границе. Может находится за 26 км от границы. Я видел такие. Совершенно параноидальная ситуация. Это примитивное видение.

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

Значит, правило номер один в методологически окрашенном проектном сознании — взвесьте, оцените на зуб ключевое слово. Усомните ключевое слово. За этим усомневанием может последовать иная операция. Операция замещения другим ключевым словом, вашим ключевым словом, которое входит в тело вашего будущего проекта. В моем случае, смотрите, лёгкая подтасовка, вместо слова «граница», появляется слово «приграничье». Другое даже по роду. Граница — женский род, приграничье — средний. То есть, что-то, что около границы. Это некое понятие, приграничье, обладающее чувственной очевидностью. Любой человек мгновенно реагирует на содержание этого понятия. Понятно о чем речь.

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

Что происходит дальше? Пространство приграничья не имеет пределов, пока вы их не задали. Если мы с вами тянули, даже на уровне понятия, нечто, что вовлекает в себя взаимодействие живых людей, а значит, и живых оргструктур, соорганизованностей? Как только вы ввели новое, объемлющее понятие, вы получаете шанс работать с этими соорганизованностями. Смотрите, я же не могу сформулировать такую понятийную конструкцию — развитие границы. Меня не поймут. Я и сам себя не пойму. А развитие приграничья — запросто. Значит, понятийные конструкции здесь оказываться теми вешками слаломного спуска, о которых я говорил раньше. Заместить понятие необходимо. Если не заместили, проиграли заранее. Потому что существующие линейные конструкции управления сильнее вас. Переиграть их можно, только вклиниваясь между ними. Проектное сознание работает на том, что врезается в трещины больших массивов, а они всегда имеют трещины.

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

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

Отсюда правило номер три. Ключевое. Собственно проектное мышление. Проектные конструкции. Методология проектного отношения имеет шанс возникнуть там, где есть принципиальный дефицит иных форм знаний . Знания такого нет. Можно сложить руки и ничего не делать. Можно заниматься сугубо спазматическими действиями по вдохновению. Можно выстраивать макропроектную действительность. Я начинаю сейчас новый тип проектно-аналитической работы. В чем она заключается? Только часть проектного замысла превращает эту работу в действительность. Я сейчас провожу семинары. Эти семинары показывают: 1) Произошла кадровая революция, неопознанная и неосмысленная. Уровень мышления руководителей низового звена подскочил на порядок. И тут возникает, как говорит Генисаретский , проектная готовность. Человек ещё не умеет проектировать, но он уже готов, чтобы его втягивали, у него уже достаточно широкий горизонт. 2) За два дня интенсивной работы можно получить 4-5 дееспособных, конкретных проектов, реализуемых, в принципе, здесь и сейчас. За этим следует принципиально важная вещь. Если в нескольких местах можно «наколоть» практику таким образом и получить результат, значит, мы получаем принципиально новую конструкцию для формулирования проектной идеологии. Если ещё недавно мы должны были рассчитывать исключительно на людей из столицы, если на самом деле мы можем рассчитывать на людей, относящихся к элите на районном уровне, это значит, что всю систему проектной работы надо переструктурировать. Она строится уже не на отдельных тренингах, а на создании сети, на сетевом принципе. На задействовании формирования человеческих машин, растянутых в огромном пространстве, взаимодействующих напрямую.

Как только вы вводите сетевую конструкцию в схему проектного метода, вы радикальнейшим образом меняете парадигму организации собственного мышления. Потому что классическая досетевая, проектная идеология тоже линейная, тоже диктаторская. Несколько умных, оснащённых людей способны реализовать свой проект, эксплуатируя разные интересы и устремления самого разного круга людей. Это классическая схема проектирования. Мы в ней вырастали. Описание пока существует только на нее. Как только вы вводите сетевую конструкцию в основание проекта, у вас меняется все. Сетью нельзя управлять — по определению. У сети нет якорной верхушки —по определению. В нее можно только вбросить импульс. Как этот импульс будет претворен, соорганизован, переосмыслен, мы увидим. Гигантская возможность, которая открылась только сейчас, но для того, чтобы этой возможностью воспользоваться, необходимо многое понять.

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

И последнее. Поскольку мы имеем дело с человеческой машиной, постольку мы должны научиться работать с пустыми рамками, только векторально связанными рамками, а не пытаться изображать предмет. Если я, вместо фермеров, сочиню проект как им организовать обслуживание их железок, которыми они пользуются, то я могу его сочинить, но шансы его врастания в жизнь нулевые. Если этот проект создан вместе с оценкой людей из местных сельсоветов и т.д., тогда у них возникает представления горизонтальной связанности, что у соседей может быть общий проект, не идущий сверху. Тогда вы создаёте рамку, в которой один обнаруживает, что у него тысячи здоровых мужиков уволенных из офицеров, которым нечего делать, а у другого давно вымерли последние механизаторы и некому чинить эти железки. Тогда вы создали рамку, в которой они это обнаружили и начинают нащупывать способ взаимодействия. Значит мои проекты становятся вовсе не железом, вовсе не способом борьбы с сельской беспризорностью, а превращаются в создание рамки, в создание цепи этого типа семинаров, способов их проведения так, чтобы вовлечённые в них люди перестанут стесняться мыслить и бояться говорить. Я должен спроектировать эту цепь, вовлечь новый тип чиновников в эту цепь. Есть у нас эти новые чиновники, которые надзирают на уровне округов, у них нет власти, но есть авторитет. Молодые и очень интересные люди. Часть моего проекта заключается в следующем. Я приглашаю на семинар федерального инспектора области, в которой проходил семинар, инспектора области, в которой проходит семинар, инспектора области, в которой будет семинар. Происходит скользящий процесс обучения этих новых чиновников, не встроенных в обычную систему управления и становящихся узлами нашей сети проектного способа мышления. Где здесь критерий успешности проекта? Вообще, где критерий успешности проекта, реализуемого в действительности? Только в одном. Если его автор становится невидимым. Если действительность выталкивает автора за ненадобностью, проект успешен. Если автору необходимо оставаться внутри, чтобы все скрипело и двигалось, значит, проект неудачен.

Вопрос — Вы говорили о проектной готовности. А что, если нет времени для зондирования и подходит момент, когда проект должен сработать, либо не сработать? Что в этом случае делать? Например, выборы.

Глазычев В.Л.: Я скажу жёстко, поскольку я переживал подобную операцию. В принципе, проект «Озимое поколение» имеет достаточно большие шансы на реализацию. Но он только сейчас их приобрел. Только сейчас. Потому что только дуриком можно было проскочить через систему просчета при неконтролируемых избирательных участках. Только совершенно нелепым фартом можно было бы одолеть. Независимо от того, какие бы вы усилия вкладывали, без 100 миллионов — и не гривен отнюдь, решить эту задачу невозможно. Но вы и ваши коллеги добились огромной победы. Потому что до того как формально произошел подсчёт голосов, абсолютное большинство традиционно мыслящих экспертов оценивало шансы на уровне социологической ошибки. Даже те 2,4%, которые формально пропустила здесь казённая машина, это на порядок выше, чем то, что давали эксперты. Это колоссальный прорыв. Сейчас время развертывания своего проекта. Такого рода проект не спазматический. Тот пример, который я вам приводил, он же был замещающий. Сосредоточение всех небольших сил на одной точке для того, чтобы внимание к этой точке потянуло за собой шлейф вокруг.

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

Под проектной готовностью я имею в виду достижение нескольких специфических качеств, разочарованности во всех шаблонных формах. Эта разочарованность должна быть полной. Возникает проектная готовность. Я встречал ситуацию, где со слезами на глазах страдали бывшие советские руководители говорили: «Госзаказ, госзаказ…». Они всё ещё верили, что будет госзаказ. Тогда ещё нет проектной готовности. Пока есть вера в то, что завтра кто-то даст госзаказ, зачем проектное мышление?

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

Вопрос — Человек ничего не делает просто так. Какова ваша миссия пребывания на Украине? Это часть проекта?

Глазычев В.Л.: Я это делаю просто так, для удовольствия. А если говорить абсолютно серьёзно, то здесь есть две вещи. Первая причина. Меня об этом попросил мой друг и товарищ Петр Георгиевич Щедровицкий. Этого уже было бы достаточно. В нашем кругу единомышленников так принято. Я не буду долго допрашиваться: зачем. Надо — значит надо. А вторая причина более глубокая. Нет ничего более важного, чем понимание и выработка проектной модальности отношений России с Украиной. Украина это ваш вопрос, но и для России более существенного вопроса, чем Украина, нет. Все остальное — чепуха собачья. Это, к сожалению, недоосмыслено многими людьми в России.

Вопрос — Вы упомянули проект «Озимого поколения». Провальный проект. Есть ли смысл на месте проваленного проекта строить какой-то новый: с теми же людьми, с теми же знаками и т.д., или чаще приходиться ориентироваться на создание совершенно нового проекта? Насколько негатив проваленного проекта может повлиять на следующий проект?

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

Если посмотреть, сколько набрали «озимые», а это 700 тысяч голосов, то, господа, это безумно много. Если 70 тысяч, т.е. 1/10 из них сделать каркасом сетевого строительства, можно и горы свернуть. Как? Это уже не вопрос этой лекции.

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

Глазычев В.Л.: Это очень хороший вопрос, на который разные персонажи дадут разные ответы. В моей позиции, да, провальных проектов не бывает. Потому что из каждого независимого формального результата извлекается материал для других. Но это моя точка зрения. Моя позиция дистанцированная. Проектно-методологическая. Разумеется, для того, кто ставит все на одну карту и играет прямо в игру под названием политика или бизнес, цена неудачи стремительно возрастает. Хотя плюс в этой неудаче тоже есть. Есть одна деталь. Вы знаете в чем была проектная идея Генри Форда? Очень многие по ошибке считают, что это была низкая цена машины. Это не верно. В том же Детройте было около двух десятков мастерских, которые изготовляли машины по меньшей цене, чем это делал Форд. Гениальность его заключалась в том, что он, не называя ещё того по имени, первым ввел в оборот понятие цена-качество, как число признаков предмета соотнесенных с ценой. Так же он увидел тип потребителя, который никто эмпирическим образом увидеть не мог, потому что тот не был проявлен. Он увидел в фермерах покупателей автомобилей, тогда как все остальные считали автомобиль предметом роскоши. От этого был только один шаг до признания собственных рабочих покупателями собственных автомобилей.

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

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

Технология проектирования определяется как совокупность трех составляющих:

 пошаговой процедуры, определяющей последовательность технологических операций проектирования;

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

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

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

 должна поддерживать полный ЖЦ ПО;

 должна обеспечивать достижение целей разработки ИС с заданным качеством и в установленное время;

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

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

 должна обеспечивать минимальное время получения работоспособной информационной системы;

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

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

 должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

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

 стандарт проектирования;

 стандарт оформления проектной документации;

 стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

 набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

 правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов;

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

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

Стандарт оформления проектной документации должен ус- танавливать:

 комплектность, состав и структуру документации на каждой стадии проектирования;

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

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

 требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

 правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

 правила использования клавиатуры и мыши;

 правила оформления текстов помощи;

 перечень стандартных сообщений;

 правила обработки реакции пользователя. CASE-средства

Общая характеристика и классификация

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

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

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

 мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком;

 интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

 использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

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

 графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

 средства разработки приложений и генераторы кодов;

 средства конфигурационного управления;

 средства документирования;

 средства тестирования;

 средства управления проектом;

 средства реинжиниринга.

Современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit), и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

 применяемым методологиям и моделям систем и БД;

 степени интегрированности с СУБД;

 доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

 средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

 средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

 средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

 средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

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

Вспомогательные типы включают:

 средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

 средства конфигурационного управления (PVCS (Intersolv));

 средства тестирования (Quality Works (Segue Software));

 средства документирования (SoDA (Rational Software)). Методология RAD

Одним из возможных подходов к разработке ПО является методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента:

 небольшую команду программистов (от 2 до 10 человек);

 короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

 фаза анализа и планирования требований;

 фаза проектирования;

 фаза построения;

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

CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60-90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

 общая информационная модель системы;

 функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

 точно определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами;

 построенные прототипы экранов, отчетов, диалогов.

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

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

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

 определяется необходимость распределения данных;

 производится анализ использования данных;

 производится физическое проектирование базы данных;

 определяются требования к аппаратным ресурсам;

 определяются способы увеличения производительности;

 завершается разработка документации проекта.

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

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

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода. Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом: менее 1 000 функциональных элементов - один человек; 1 000-4 000 функциональных элементов - одна команда разработчиков; более 4 000 функциональных элементов - из расчета 4 000 функциональных элементов на одну команду разработчиков.

Отметим основные принципы методологии RAD:

 разработка приложений итерациями;

 необязательность полного завершения работ на каждом из этапов жизненного цикла;

 обязательное вовлечение пользователей в процесс разработки ИС;

 необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

 необходимое использование генераторов кода;

 использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;

 тестирование и развитие проекта, осуществляемое одновременно с разработкой;

 ведение разработки немногочисленной, хорошо управляемой командой профессионалов;

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

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

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

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

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

 редакторы;

 анализаторы;

 преобразователи;

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