Цель лекции: Настало время обсудить то, как в результате процессов анализа возникают готовые архитектуры информационных систем. Именно в этом нам помогает проектирование. Этот тип активности направлен на то, чтобы из кирпичиков целостной, но разнородной информации собрать комплексные информационные системы.
Анализ данных направлен на то, чтобы разложить на конкретные составляющие любую проблему, а проектирование (синтез) — на то, чтобы из результатов анализа сложить комплексную картину. Анализ направлен на сбор необходимых данных, а проектирование приводит к созданию конкретной информационной системы. Результат процесса проектирования — информационная архитектура.
 |
 |
«Архитектура — мать всех искусств. Если у нас нет своей архитектуры, у нашей цивилизации нет своей души»[1]. |
Каждая архитектура должна обладать свойствами, которые будут разработаны по ходу процесса проектирования. Очень подробно эти свойства мы разобрали в главе, где говорилось о системном анализе. На сегодня существует три основных подхода к проектированию — канонический, типовой и автоматизированный. Каждый из этих подходов имеет свои преимущества, недостатки и область применения. Они, по сути, являются эволюционирующими подходами, каждый из которых востребован для определенных условий создания систем. Все эти подходы имеют свои методологии:
Нельзя сказать, что какой-то из этих подходов устарел — все они востребованы.
 |
 |
Архитектура — это то, за что могут уволить архитектора и руководителя проекта. |
Проектирование — это процесс. Результат этого процесса – архитектура. Архитектура, как и проектирование, требует проведения анализа. Архитектура и проектирование, «по Маслоу», — это то, что лежит не в фундаменте пирамиды создания информационных систем, это уровни, которые достигаются и удовлетворяются только тогда, когда закрыты базовые потребности, то есть проведен анализ и есть достаточное количество ресурсов, чтобы принять взвешенные решения о том, как будет выглядеть информационная система, чтобы удовлетворять стратегические и тактические нужды ее потребителей. Проектирование оперирует системными абстракциями, каждая из которых представляет собой модель предметной области. Абстракции, или модели, направлены на то, чтобы архитектура удовлетворяла определенным аспектам (рис. 44).
Рис. 44
Эти аспекты мы обсудим подробнее, когда будем говорить о структуре и функциях проектирования.
Информационные технологии — очень молодая сфера деятельности. Она еще набирает обороты, и в ней много этапов и активностей, которые только начинают формироваться и оформляться как самодостаточные виды деятельности. В начале, около 70 лет назад, специалисты учились по ходу создания работающих информационных продуктов. Показатель «система работает» считался главным. Затем, около 40 лет назад, специалисты стали учиться делать систему правильно и вовремя. Главным показателем стал «система сделана вовремя». Потом, около 25 лет назад, учились не просто создавать работающую систему в срок, а именно так, как нужно заказчику. Настало время показателя «система приносит результат». В наше время те, кто вовлечен в сферу информационных технологий, учатся реализовывать ожидания заказчика путем достижения тактических и стратегических целей, и теперь роль проектирования сложно переоценить. На первых этапах, когда нужно было разбираться в предметной области и контексте, главную роль играл анализ данных, но по мере того, как фокус ожиданий смещался от настоящего к будущему, фокус дисциплин сферы информационных технологий начал смещаться именно в сторону проектирования. Ожидание от такого смещения — информационный продукт, который эффективно поддерживает текущие процессы и способствует быстрому внедрению новых процессов и модификации существующих. На этом этапе ярко выделены роли системного аналитика и архитектора. Системный аналитик работает над структурой разрабатываемой системы, а архитектор отвечает за то, чтобы структурные компоненты были самодостаточными, переиспользуемыми и масштабируемыми.
Принципы проектирования и разработки информационных систем не должны зависеть от контекста создаваемой системы. Эти принципы — основа любого подхода к проектированию. Полнота и корректность их применения определяют качество создаваемой системы и ее компонентов. Но система может разрабатываться в разных окружениях и с разными условиями. Эти условия определяют типы проектирования, которые будут использоваться. Итак, традиционно выделяют три основных типа проектирования — каноническое, автоматизированное и типовое (рис. 45).
Рис. 45
Каноническое проектирование эволюционно является первым типом. Это компиляция первоначального опыта, который был получен в ходе первого этапа становления области информационных технологий. Каноническое проектирование представляет собой полный стандартизированный цикл проектирования, в который включены все основные этапы. Этот подход к проектированию сильно зависит от опыта и компетенций специалиста, который проводит проектирование. Именно за счет его компетенций создается система, которая должна полностью отвечать собранным требованиям. Для этого типа проектирования не важны используемые инструментальные средства; он не требователен к тому, как именно будут создаваться рабочие модели. Каноническое проектирование сосредоточено на уникальных предметных областях, для которых требуются небольшие информационные системы, заточенные под конкретные нерегламентированные нужды, информацию по которым нужно собирать от стейкхолдеров. Для канонического проектирования важны упорядоченность и последовательность рабочих процессов, в которых каждый задействованный специалист должен отработать от начала и до конца, используя все свои профессиональные навыки и возможности. Каноническое проектирование, как и другие типы проектирования, имеет свои преимущества и недостатки. Из недостатков нужно отметить тот, что оно сильно зависит от компетенций ролей, участвующих в нем. Этот недостаток порождает следующий, который является следствием первого, — возможно низкое качество системы, если проектировщики и разработчики не будут иметь навыков, достаточных для ее создания в соответствии с первоначально обозначенными аспектами. Еще один недостаток — проблематичное развитие продукта, которое может стать сложным, а иногда и невозможным. В качестве преимуществ канонического проектирования мы выделим его адаптируемость для конкретных ролей, а также гибкость этого подхода, который позволяет сконцентрироваться на главном. Ну и главное достоинство этого типа проектирования — в том, что он позволяет реализовывать любые идеи, следуя каноническому процессу (рис. 46).
Рис. 46
Следующий тип проектирования, о котором мы поговорим, — автоматизированное проектирование. Этот тип во главу угла ставит уровень автоматизации самого процесса проектирования за счет использования конкретных инструментов и технологий и его сквозной автоматизации. Автоматизированное проектирование позволяет снизить риски некачественного тестирования и разработки за счет единой формы общения на языке схем, диаграмм и псевдокода на уже знакомом нам UML. Этот тип проектирования требует большого количества автоматизированных систем, в которых будет выполняться анализ и проектирование, а также навыков работы с таким специализированным программным обеспечением.
Автоматизированное проектирование применяется для разработки систем, в которых требования можно собирать не только от конкретных стейкхолдеров, но и из нормативных документов, стандартов и отраслевых регламентов. Этот тип проектирования поддерживает как каскадную модель разработки, так и спиральный рабочий процесс. Автоматизированное проектирование появилось как эволюционный виток развития каскадного процесса. Оно постаралось учесть недостатки каскадного процесса и устранить их системно, на уровне рабочих подходов. Именно поэтому мы видим в нем большое количество автоматизаций и высокий уровень использования специализированного программного обеспечения, которые нивелируют проявления человеческого фактора.
В качестве основных недостатков автоматизированного проектирования выделяется его дороговизна. Много трат приходится на системы и квалифицированный персонал — этот тип сильно зависит от инструментов и применяемых технологий и для него очень сложно находить и наращивать ресурсы, использование которых ограничено его рамками. Но, с другой стороны, автоматизированное проектирование дает ряд преимуществ — это его масштабируемость, выраженная в виде легкости запуска проектирования для новых проектов разработки и внедрения очередных информационных систем; также автоматизированное проектирование способствует достижению гарантированных результатов. С помощью этого типа проектирования можно легко рассчитать эффект на основе имеющейся базы уже проведенных проектов. И еще автоматизированное проектирование стабильно и понятно. Существуют информационные системы, которые формируют понятные артефакты, главное — выполнить понятную работу с заданным уровнем качества (рис. 47).
Рис. 47
Последний тип, который мы рассмотрим, — шаблонное проектирование. Суть этого подхода состоит в реализации процесса проектирования за счет автоматизации и использования шаблонов, каждый из которых применяется в контексте, наиболее подходящем для него. Этот вид проектирования используется для отраслей, которые четко регламентированы или нуждаются в такой регламентации. Так мы используем шаблонные решения, которые наиболее полно подходят к описанному профилю использования. Шаблонное проектирование зависит от поставщика решения, по которому выполняется шаблонизация вида деятельности. В таких условиях надо фокусироваться на выборе конкретных шаблонов, которые будут использоваться для автоматизации и наиболее точно отображают автоматизацию, нужную для компании. Именно поэтому важно, чтобы шаблонизация выполнялась в соответствии с регламентацией, в которой заинтересованы основные заказчики. Этот тип проектирования поддерживает любой жизненный цикл. В нем на первый план выходит не разработка, а настройка конкретного решения под собранный профиль, под шаблон. Основной недостаток шаблонного проектирования — его зависимость от поставщика услуг. Этот тип имеет сложности с адаптацией каких-то уникальных требований, не подходящих под шаблоны, и эта адаптация будет очень затратной. В таких условиях именно шаблон определяет то, что является правильным, и во многом под это правильное необходимо приспосабливать свои автоматизируемые процессы. В качестве преимуществ шаблонного проектирования выделяют масштабируемость и гарантированность результатов проводимых работ (рис. 48).
Рис. 48
Представленные выше подходы являются базовыми для понимания сути работ по проектированию информационных систем.
Проектирование информационных систем развивается во многих направлениях. На текущем витке развития попытка выделить основных личностей, которые повлияли на актуальный образ проектирования, приводит к дилемме. С одной стороны, нужно поговорить о тех, кто исторически влиял на эту сферу, но тогда наше обсуждение будет направлено в сторону процессов разработки и тех личностей, кто заимствовал шаблоны проектирования информационных систем у строительных объектов.
|
 |
Шаблон проектирования, или паттерн (англ. design pattern), в разработке программного обеспечения — повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста[2]. |
Здесь можно выделить Кристофера Александра, который составил набор шаблонов проектирования наиболее популярных и распространенных структурных объектов.
 |
Кристофер Александр, архитектор и дизайнер, создатель более 200 архитектурных проектов в Калифорнии, Японии, Мексике и в других частях мира. Создал и внедрял на практике «язык шаблонов» в архитектуре[3] |
Его идеи не получили широкого развития в области строительной архитектуры, но прижились и развились в области информационных технологий. Основная же заслуга в адаптации этих концептов для создания информационных систем принадлежит Эриху Гамме.
 |
Эрих Гамма, программист из Швейцарии, один из четырех авторов классической книги «Design Patterns» о шаблонах проектирования. Команда авторов книги также известна под названием «банда четырех» (англ. Gang of Four, GoF)[4] |
Затем заложенные идеи постепенно распространились в области информационных технологий и с течением времени стали лучшей практикой в области создания эффективных систем. Так формализовался подход, которых фактически стал стандартным для разработки и внедрения любой информационной системы. Его мы обсуждали ранее — это идеология «4+1», предложенная Филиппом Кратченом.
 |
Филипп Кратчен, профессор Университета Британской Колумбии, ученый и практик в области информационных технологий |
Накопление информации о практическом применении принципов проектирования в определенных контекстах деятельности привело к тому, что проектирование и архитектура стали важными составными частями успешной коммерческой разработки программных продуктов. Большой труд в области популяризации этой информации принадлежит евангелисту Мэтью Бассу.
 |
Мэтью Басс, профессор Университета Карнеги Меллон. Популяризатор, ученый, евангелист проектирования и архитектуры информационных систем. В соавторстве с П. Клементсом и Р. Кацманом он создал книгу «Архитектура программного обеспечения на практике»[5] |
Мы упомянули лишь основных личностей, но при желании, основываясь на приведенной тут информации и упоминаниях, можно расширить свое представление о тех, кто заслуживает внимания, когда речь заходит о проектирования информационных систем. Ищите информацию о «банде четырех» и архитектурных шаблонах проектирования.
Назначение проектирования состоит в гарантированном достижении ожиданий пользователей через создание информационного артефакта — архитектуры информационной системы.
 |
|
Проектирование — это вид активности, направленный на создание уникального продукта (услуги), последовательность этапов реализации которого будет определяться «внешними» факторами и определять его конечные преимущества и недостатки[6]. |
Проектирование как вид деятельности и архитектура как ее результат представляют собой самодостаточный тип деятельности, назначение которого — удовлетворить ожидания заказчиков. Стоит добавить, что удовлетворение как таковое может быть подтверждено только после того, как архитектура приобретет материальное воплощение в виде конкретного информационного продукта. И тут мы открываем дополнительную грань проектирования, которая не относится к этому виду деятельности напрямую, но влияет на его успешность, — это воплощение архитектуры во всей полноте и деталях. Воплощение архитектуры принято относить к обязанностям другой роли, участвующей в процессе разработки, — роли менеджера проекта или продукта, но это не совсем верно. Архитектура сама по себе — интеллектуальный артефакт, отражающий теоретическое представление о создаваемой системе. Это теоретическое представление не имеет реальной ценности до того момента, пока оно не будет реализовано на практике, и тот, кто ответственен за проектирование, должен иметь это в виду.
Проектирование реализует компиляцию требований к создаваемой системе в единый информационный продукт, который удовлетворяет интересы заинтересованных сторон (рис. 49). Оно выступает связующим звеном между требованиями, процессом разработки и сбором модулей создаваемой системы в единое решение. Проектирование позволяет подтвердить, что все необходимое для функционирования системы собрано в непротиворечивое решение, которое может быть реализовано. Это его назначение, и, таким образом, проектирование вносит ценность в процесс разработки эффективного бизнес-решения. Существует много подходов к тому, как выполнять проектирование, но основной вклад в это вносит архитектура, то есть представление о том, каким должно быть решение, чтобы удовлетворить нужды и ожидания заказчиков с учетом понятных организационных и технических ограничений.
Рис. 49
Ограничениями являются:
Все это влияет на то, как пройдет процесс проектирования и каким будет результат, то есть архитектура.
Структура самого целевого артефакта, ожидаемого от процесса проектирования, перекликается со структурой создаваемой модели (рис. 50). Ей мы много внимания уделять не будем, а обсудим структуру самого процесса проектирования. Стимул старта процесса проектирования — необходимость проведения изменений.
|
|
|
Сти́мул (лат. Stimulus) — палка погонщика ослов или острый металлический наконечник на шесте, которым погоняют буйвола (быка), запряженного в повозку[7]. |
Изменения — спусковой крючок, на который должен реагировать проектировщик для того, чтобы выполнять свое предназначение. Каналы поступления изменений определяются окружением и средой, в которой выполняется проектирование. Перед внедрением в процесс проектирования изменения должны быть провалидированы на предмет:
В управлении требованиями для валидирования используется процесс, который мы уже обсуждали ранее, — трассировка, после которой изменения попадают к проектировщику. В качестве основных каналов поступления изменений можно выделить следующие:
Так складывается структура процесса проектирования решений (рис. 50).
Рис. 50
Процесс проектирования должен быть настроен на то, чтобы своей деятельностью приносить удовлетворенность заказчикам и упорядочивать процесс работы с информацией с момента ее поступления на проектировочный конвейер. Структура этого процесса должна агрегировать в себе результаты аналитической деятельности и процесс разработки, на вход которому поступают результаты процесса проектирования. Результат проектирования, то есть модели системы и процессов, могут быть представлены в виде моделей, о которых мы говорили ранее, или в любом другом виде, удовлетворяющем условиям контекста, в котором выполняется проектирование. Использование специальных программных средств не является обязательным, с оговоркой, что для определенных видов проектирования (например, автоматизированного) — это необходимое условие выстраивания рабочего процесса.
Необходимо, чтобы процесс проектирования учитывал все иерархические уровни контекста рассматриваемой проблемы. Анализ каждого уровня должен приводить к формулировке параметров, важных для проектирования конечной информационной системы. Ведь когда мы говорим об информационной системе, то имеем нечто большее, чем набор кодовых строк. Это ценность, которая будет реализовываться через выстроенные процессы взаимодействия пользователей с создаваемым информационным продуктом в определенной бизнес-среде. При проектировании важно учесть все точки соприкосновения создаваемого продукта с окружением. Если какие-то точки соприкосновения остаются за бортом рассмотрения, то мы сужаем рассматриваемую область и фокусируемся только на части проблемы, нарушая баланс факторов, оказывающих воздействие на ценность, которую мы должны реализовать.
|
|
Ядром проектирования должны быть требования, подверженные наименьшему внешнему влиянию. Это требования, которые составляют для компаний наибольшую ценность. |
Ядро создаваемой системы — функции, выполнение которых является целью создания информационного продукта. Вокруг этого ядра будут выстраиваться процессы, направленные на поставку исходных данных и передачу преобразованной информации, представляющей основной интерес заказчиков и спонсоров нашей системы. Процессы сбора, передачи, преобразования информации изменчивы, и на них могут и будут оказывать сильное влияние внешние факторы. Проектирование должно учитывать эти факторы и находить им отражение в кодифицируемых потоках поставки данных в алгоритмы, представляющих основу создаваемых информационных систем. Так складываются информационные слои. Такую структуру архитектуры еще называют «луковой» (onion).
 |
 |
Onion-архитектура представляет собой разделение приложения на уровни. Существует один независимый уровень, который находится в центре архитектуры. От этого уровня зависит второй уровень, от второго — третий и т. д. То есть получается, что на первый независимый уровень наслаивается второй — зависимый, на второй наслаивается третий, который также может зависеть и от первого. Образно это может быть выражено в виде лука, в котором также есть сердцевина, на которую наслаиваются все остальные слои вплоть до шелухи[8]. |
Количество уровней может отличаться, они могут быть представлены не в виде слоев, а в виде этапов работ, между которыми передается информация (тогда мы получаем другой вид архитектуры, которая называется «Каналы и фильтры»), но в центре всегда находится модель предметной области и основной алгоритм обработки информации. Структура архитектуры, созданной в результате процесса проектирования, может быть разной, но она должна удовлетворять условию учета всех факторов, важных для потребителя и владельца создаваемой системы.
Функции проектирования должны реализовывать построение архитектуры и отвечать на вопрос о том, что делает процесс проектирования. Краткий ответ по пунктам:
А теперь давайте раскроем приведенные пункты.
Основная функция проектирования — разработка архитектуры. Архитектура должна описывать конечное решение, согласовываться с ранее собранными требованиями и реализовывать цели, заложенные в требованиях. Вот за что отвечает проектировщик решения:
Требования — основа проектирования. Есть популярная концепция, которую мы уже разобрали, заключающаяся в разделении требований на две категории: функциональные (что должна делать система) и нефункциональные (как должна функционировать система). Нефункциональные требования связаны с функциональными и следуют из них. Любой аспект поведения системы определяется тем, что эта система должна делать. Если нет возможностей сформулировать критерии качества системы (нефункциональные требования), значит, нужно дополнительно уточнять функциональные требования по тем направлениям, которых не хватает. Функция проектирования состоит в разработке архитектуры за счет соединения всех собранных требований в единое бизнес-решение, воплощенное в конкретном виде. Из этого следует вопрос: каким должен быть этот вид? Есть традиционное разделение людей на 5 категорий, основными из которых являются текстуалы, то есть те, кто лучше воспринимает текст, и визуалы — те, кто лучше воспринимает изображения. На одного текстуала приходится примерно 9 визуалов. Эта информация трактуется следующим образом — если проектировщик создает иллюстрации и изображения, у него больше шансов охватить аудиторию и быть понятым, чем если он напишет текст, поэтому оптимальная формализация и визуализация архитектуры должны быть именно в формате изображений с небольшими текстовыми пояснениями. Чтобы понять, какие модели для отображения какой информации строить, вы можете вернуться к главе о моделировании — в ней мы разобрали всю необходимую специфику.
Главный артефакт процесса проектирования — архитектура, детище архитектора.
Мы обосновали, из чего состоит архитектура и какие функции выполняет, но не объяснили, какой она должна быть. Сейчас настало время поговорить об этом. Итак, мы подошли к наиболее известному архитектурному подходу «4+1» (рис. 51).
Этот подход был предложен Филиппом Кратченом в 1995 году. Данная методика позиционировалась как способ описания архитектуры систем, основанных на активном использовании программного обеспечения. «4+1» предлагает использование пяти различных представлений для описания архитектуры сложных систем, каждое из которых представляет собой модель UML. Логическое представление предназначено для описания системы в виде набора взаимодействующих классов и соответствующих методов. Потребители этого описания — прежде всего аналитики и тестировщики. Процессное представление предназначено для описания различных аспектов параллельного исполнения и синхронизации процессов в системе. В нем заинтересованы интеграторы —специалисты, внедряющие информационные системы. Представление развертывания предназначено для описания размещения программных компонент системы на аппаратных платформах. Наиболее заинтересованы в данном представлении архитекторы. Существует и представление уровня разработки, где описание архитектуры структурируется с помощью указанных четырех представлений и затем отображается набором сценариев использования, или представления прецедентов, которые становятся пятым, центральным представлением системы. Представления строятся на основе конкретных диаграмм UML, которая, как мы уже обсуждали, оперирует диаграммами двух типов (рис. 52).
Рис. 51
Рис. 52
Статические диаграммы, описывающие структуру систем, — типы объектов, которые важны для моделирования системы и понимания того, как разные структуры связаны между собой в единое структурное представление. Также существуют динамические диаграммы, или диаграммы поведения. Они описывают жизненный цикл объектов и то, как они взаимодействуют друг с другом для обеспечения запланированной функциональности. В совокупности диаграммы описывают наиболее важные и значимые части архитектуры, которые необходимо держать в фокусе внимания для полноценной реализации задуманного.
С помощью UML становится возможным описать любую, даже самую сложную архитектуру. UML содержит строительные блоки, которые представлены в виде технических сущностей, отношений между ними и диаграмм. Эти строительные блоки объединяются в механизмы, которые, в свою очередь, описываются спецификациями, использующими принятые деления на диаграммы и дополняемые возможными точечными продуманными расширениями. Все это используется для построения стройной переиспользуемой архитектуры.
Путь специалиста в области проектирования / проектировщика / архитектора начинается с момента осознанной практической деятельности. Это время становления и самоопределения на выбранном профессиональном пути. Традиционно тот, кто решил заниматься проектированием, мигрирует в эту сферу из других, более трудоемких и востребованных сфер — анализа данных, разработки или тестирования. Проектирование как вид деятельности предполагает владение анализом и/или разработкой и/или тестированием. Именно поэтому архитектор — это как ступень в развитии аналитика, разработчика, тестировщика, но это ступень качественного преобразования, что предполагает проведение определенной профессиональной метанойи.
 |
|
Метано́йя (др.-греч. μετάνοια — «сожаление (о совершившемся), раскаяние», греч. μετάνοια — «перемена ума», «перемена мысли», «переосмысление») — термин, обозначающий перемену в восприятии фактов или явлений, обычно сопровождаемую сожалением, раскаянием (особенно в психологии и психотерапии). В религиозной (особенно христианской) традиции метанойя имеет значение покаяния[9]. |
Метанойя предполагает, что специалист не будет по инерции тащить за собой приобретенные рабочие подходы и осмыслять новые знания под фильтром уже имеющихся, а возьмет свой опыт и будет беспристрастно и рационально использовать его для выполнения более качественного, комплексного, осознанного проектирования востребованных информационных решений. Владение стандартами и подходами в области анализа помогает архитектору/проектировщику принимать более взвешенные и оправданные решения в ситуации недостающих требований. Это не значит, что требования не нужно дополнительно уточнять, но на имеющемся опыте архитектор может ускорить и направить в нужное русло сам процесс их дополнительного уточнения, ответственность за который лежит на аналитике. Так же нужно воспринимать и трактовать опыт в области разработки. Понимание подходов и принципов разработки программного обеспечения помогает в формализации и «упаковке» каждого отдельного программного модуля в самодостаточный переиспользуемый компонент, который должен удовлетворять следующим необходимым архитектурным аспектам (рис. 53):
Проведем калибровку и самопроверку по вопросам проектирования (рис. 53.1).
Рис. 53
[1] https://vk.com/@koleso_360-arhitektor-korotko-o-samom-glavnom
[2] https://ru.wikipedia.org/wiki/Шаблон_проектирования
[3] https://ru.wikipedia.org/wiki/Александер,_Кристофер
[4] https://famous-birthdays.ru/data/13_marta/gamma_yerih.html
[5] https://www.labirint.ru/books/87540/
[6] https://intuit.ru/studies/courses/3509/751/lecture/29032
[7] https://ru.wikipedia.org/wiki/Стимул
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.
