Цель: системный синтез информации, изложенной в ходе курса для успешного освоения тем: создание архитектур программного обеспечения, организация основных процессов, которые создают ценность информационной архитектуры и пр.
В совокупности, успешное применение в практической деятельности уже известной Вам информации, позволит выйти на новый уровень понимания значимости информационных продуктов для современного мира и применения профессиональных компетенций для реализации успешных и конкурентоспособных информационных систем.
После того, как программный продукт вышел на стадию промышленной эксплуатации, начинается процесс его сопровождения.
Под сопровождением программного продукта мы понимаем не столько обеспечение работоспособности реализованной архитектуры и функциональности на заданном уровне качества, а активности эволюции информационной систем. При этом тренд "эволюционности" сопровождения будет определяться множеством разнообразных факторов, наиболее важный из которых это управленческая воля и желание развивать программный продукт в соответствии с видением на развитие бизнес домена, который поддерживается информационной системой.
Если "видение" будет иметь достаточно четкие цели, то функциональность и архитектура программного продукта постепенно эволюционируют в направлении повышения качества бизнес процессов компании. Это будет сказываться на эффективности деятельности и результатах.
Если же руководство организации не имеет планов и целей развития бизнеса, компания подобна кораблю без капитана, а архитектура и функциональность, в лучшем случае, будут находиться в "законсервированном" состоянии, а в худшем, относительно быстро устареют и не смогут адекватно реагировать на запросы бизнеса.
Чтобы не допустить подобного развития ситуации, архитектура, так же как и программный продукт, должны иметь план развития, подкрепленный необходимыми ресурсами.
Но, к сожалению, подобные планы наблюдаются относительно редко в современных организациях, которые подчинены диктатуре коммерческих, зарабатывающих подразделений, приносящих предприятию наибольшую прибыль и во многом определяющих и корректирующих на постоянной основе все пути развития информационных систем организаций.
В таких реалиях особенно высока роль системного/бизнес архитектора, который сможет определить тренд, на основе имеющихся или потенциальных требований, к развитию информационной системы и организовать соответствующим образом процессы по сопровождению информационного продукта.
Несмотря на то, что должность архитектора программного продукта становится все более и более распространенной в современном мире информационных технологий, существует значительная неясность в определении данной роли в процессах жизненного цикла конкретного программного продукта и организации-владельце информационной системы.
Множество руководителей испытывают определенные проблемы с наймом сотрудников на должность системного архитектора.
Достаточно обширный специфический и разнообразный круг обязанностей, продиктованный важностью данной роли, а с другой стороны в дополнение к системному архитектурному анализу и проектированию, управленческие процедуры, которые способствуют рассеиванию архитектурной "фокусировки" и отказу от активностей полноценной стратегии развития в пользу организационной и бизнес составляющей процессов реализации программного продукта.
Немного отвлекшись и проведя параллели с недавним прошлым (советские времена), можно констатировать, что должности системного архитектора не было, но былая схожая роль главного конструктора (не путать с главным инженером). Сотрудники, которые ее выполняли, постепенно проходили длительную цепочку через постепенный профессиональный рост, образование/самообразование и накопление различного опыта и навыков. В реалиях современной жизни, в силу конфликтов с процедурами управления коммерческих организаций, развитие системных архитекторов в определенных компаниях затруднительно, поэтому системные архитекторы во многом вырастают только за счет самообразования. Эти специалисты должны иметь энциклопедические знания в нескольких бизнес доменах, иметь определенные лидерские и харизматические качества (обсудим далее), а не быть профессионалами в области проектного менеджмента, как это подразумевается во многих компаниях.
Один из "отцов" современного витка развития области информационных технологий, Мартин Фаулер, выделяет следующие архитектурные роли:
Многообразие характеристик, которые выделяет Фаулер, говоря о архитекторе свидетельствует о том, что на современной стадии развития области информационных технологий нет устоявшегося профиля данной профессии и многое определяется на уровне личных качеств конкретного сотрудника.
Системный архитектор – это не столько роль в процессах реализации программного продукта, влияние которое не описано и явно не учитывается ни в одной современной методологии разработки ПО, сколько определенный человек с очень конкретным набором знаний, навыков, опыта и коммуникационных способностей. Системный архитектор сам по себе не существует. Наличие архитектора в организации подразумевает командную работу. Именно команда, их умения, способности, опыт, эффективность внутренней и внешней коммуникации определяют успешность проектирования архитектуры. Одна из основных задач сотрудника с ролью системный архитектор состоит в создании процессов коммуникации между "игроками" его команды настолько тесной, насколько это необходимо для разработки программного продукта с заданным уровнем качества.
В небольших и динамичных командах, которые не ставят перед собой целью создание мощной и надежной корпоративной информационной системы, успех будет определяться опытом архитектора, который сможет достаточно быстро донести до участников процессов разработки "проект" эффективного будущего продукта. Но, стоит отметить, что текущий тренд развития области софтверной разработки явно демонстрирует, что таких проектов становится все меньше и меньше.
Когда речь заходит о крупных и ответственных задачах разработки масштабного программного обеспечения, то без ряда продуманных диаграмм и прочих технических атрибутов, синхронизирующих понимание и ожидания, как бизнес пользователей, так и технических специалистов вряд ли обойдешься. Организация актуальных потребностей бизнеса процессов разработки программных продуктов - это еще одна задача, управлять и контролировать которую, дополнительная "головная боль" системного архитектора.
Процесс эффективных взаимоотношений группы технических специалистов с представителями бизнеса удается реализовать в том случае, если учесть и попытаться консолидировать ожидания бизнес пользователей с результатами работы представителей технократии. Участие в проекте системного архитектора проектируемого программного продукта является наилучшим из известных способов решения этой задачи. Именно системный архитектор обеспечивает надежный базис эффективного взаимодействия разработчиков и менеджмента путем следования достигнутым бизнес правилам, техническим параметрам и ограничениям, процессной системе, которая может гарантировать успех.
Далее мы приведем список качеств и их "содержание", которые позволят системным архитекторам быть эффективными и добиваться поставленных результатов.
Пожалуй, самая важная и значимая характеристика системного архитектора, грамотное развитие и балансирование которой приносит наибольший вклад в достижение конечного результата. Авторитет системного архитектора не стоит путать с авторитетом, "заработанным" на позициях, в которых находился сотрудник, двигаясь по пути к роли системного архитектора. Безусловно, базис навыков, закладываемый успешным опытом позиций разработчика/аналитика/консультанта/тестировщика важен, но если системный архитектор не будет в состоянии предлагать результативные, и при этом эффективные, решения для продукта в целом, то он будет выглядеть недостаточно компетентным. Команда должна быть успешной. Доступность в общении системного архитектора не всегда способствует в достижении этой цели, а в большинстве случае, наоборот, мешает наработке авторитета и обоснованности вопросов к нему, заменяя это "дружеским" общением и подмене значимости архитектора, как проводника и "реализатора" архитектурных замыслов. Архитектор будет вынужден каждый раз не просто объяснять, а доказывать каждому члену команды целесообразность и необходимость каждого, даже самого мелкого решения, тратя на это бесценные силы.
Авторитет – фактор ментальный, но играет значимую роль, особенно в длинных и сложных проектах.
Если же авторитет достаточный, то сотруднику важно уметь контролировать свое профессиональное и личностное поведение и не "придавливать" им слишком сильно своих коллег. Если постулировать режим диктатуры, то со временем архитектор рискует попасть в собственноручносозданную ловушку профессионального одиночества, основными типичными признаками которой являются:
Если вы задумали совсем не адекватный концепт, оторванный от функциональной реальности программного продукта (иногда, но случается с каждым), никто вам об этом не скажет, опасаясь последующих репрессий. Команда будет упорно пытаться этому решению следовать, пока чаша народного терпения не переполнится.
Если в сбалансированных командах основные решения в той или иной степени обсуждаются и одобряются основными действующими лицами, цена ошибки не так велика, так как при ее реализации каждый понимает оптимальный путь исправления, но если это было единоличное решение, ответственность и тяжесть полного исправления целиком ляжет на лицо, принявшего это решение.
Системный архитектор может просто-напросто разучиться конструктивно, обсуждать идеи с окружающими, и потерять свой коммуникационный навык переговорщика, а это не очень полезно.
Высокий уровень деловой коммуникабельности - это черта, которую предстоит успешно и в полном объеме освоить каждому, претендующему на роль системного архитектора.
Ему предстоит грамотно и точечно отбирать квалифицированный персонал, который сможет взять на себя инициативу (в допустимых объемах) по соблюдению рамок требований к разрабатываемой архитектуре или функциональности программного продукта и учета бизнес интересов. Системный архитектор должен не только предлагать обоснованные решения, но и прогнозировать возможные тренды развития архитектуры и предвидеть связанные с этим проблемы, причем важно до того момента, как они начнут оказывать свое влияние на процесс проектирования и развития системы. Архитектор программного обеспечения должен добиться согласования технических алгоритмов и методик с реальными задачами бизнес домена.
Рабочая методология должна оказывать стимулирующее воздействие на всех заинтересованных сторон в процессе проектирования и разработки информационной системы. Системный архитектор должен контролировать жизненный цикл процессов разработки программного продукта (будет описано ниже) и своевременно определять, какие из используемых инструментов малоэффективны или какие из методов дают постоянные сбои и этим влияют на качество результата. При этом, важно оперативно менять рабочие средства и новые результативные подходы.
Системному архитектору приходится часто вести дискуссии для достижения компромиссных решений по различным техническим аспектам разрабатываемых программных продуктов. Причины конфликтов, как правило, кроются в:
Системному архитектору нужно уметь точно оценить имеющиеся возможности и наметить оптимальные пути и методы реализации проекта, сочетающие в себе как необходимые ограничения, так и требования всех заинтересованных сторон, но главная концепция и базовой структуры системы, определяющая ее практическую значимость и ценность, должна быть сохранена.
Системный архитектор должен обладать внутренними, профессионально честолюбивыми стимулами к решению проблем проектирования и разработки информационной системы.
Системный архитектор не только поддерживает собственный уровень инициативности на должном качественном уровне, но и развивает это качество в членах своей команды.
Он часто предоставляет своим сотрудникам не просто набор необходимых требований, отслеживая рамки их соблюдения, но и демонстрирует им проект структурной модели системы, побуждая в них повышение эффективности проектирования. "Зрелый" кандидат на роль специалиста по системной архитектуре берет на себя инициативу не только в организации продуктивного рабочего взаимодействия, но также и в оперативном решении спектра текущих, "злободневных" проблем, обычно без соответствующих указаний сверху.
Системный архитектор должен уметь трансформировать неопределенное выражение, сформулированное в виде набора разрозненных бизнес или "околотехнических" понятий, в четкий и осязаемый результирующий артефакт процессов архитектурного проектирования, который смогут оценить все заинтересованные стороны разрабатываемого программного продукта. Его задача состоит в диагностировании абстрактных образов и связывании их с конкретными терминами и выражениями. Кандидаты на эту роль (о теме откуда "брать" системных архитекторов мы поговорим немного позже) часто берут на себя ответственность объяснить коллегам и руководству запутанные и трудноразрешимые проблемы, возникающие на протяжении всего жизненного цикла информационных систем. К ним быстро приходят оптимальные идеи, и они способны представить их в виде конкретных практических предложений, позволяющих продолжить успешное движение к достижению поставленных целей. Архитектор, безусловно, должен обладать глубокими знаниями и опытом для эффективного решения технических проблем, но он также должен четко представлять себе, как конечные пользователи будут взаимодействовать с разрабатываемым функционалом программного продукта.
После того, как мы обсудили значимые характеристики, которыми должен обладать каждый системный архитектор, целесообразно немного поговорить о его непосредственных обязанностях в рамках отдельных стадий процесса разработки информационной системы.
На данной стадии системный архитектор должен быть поглощен изучением различных бизнес аспектов и связями между ними, а также окружения, в котором будет осуществляться разработка программного продукта. Он должен использовать весь свой опыт в области программного обеспечения, оценивать все возможные риски.
На стадии архитектурного проектирования системный архитектор собирает и увязывает между собой абстрактные элементы бизнес домена для того, чтобы его команда смогла создать модель проектируемой системы. Он проводит распределение и "внутреннюю" приоритезацию требований к проектируемой системе по функциональным элементам в ее структуре. Системный архитектор не должен выступать на центральных ролях в процессе рабочего проектирования, а он необходим для контроля корректности распределения составных элементов определенным системным модулям. Таким образом, можно сказать, что он оценивает корректность структурной компоновки блоков проектируемой системы.
На стадии реализации архитектор программного продукта руководит процессом, являясь гарантом валидности разработанного продукта базовой системной архитектуре. Также он должен руководить технической частью процесса управления изменениями, оптимально адаптировать систему для реализации этих изменений и контролировать тесную связь различных функциональных блоков.
Архитектор контролирует процесс тестирования системы на предмет эффективной интеграции и приемлемости параметров системы для заказчика. В рамках этой обязанности системный архитектор осуществляет оценку результатов тестирования для возможного внесения изменений.
На этой стадии он будет инициировать и управлять обсуждениями на тему системной интеграции. Независимо от того, входит ли в обязанности архитектора вопросы согласования системы с компонентами ИТ-инфраструктуры компании или обеспечения технического взаимодействие между ее подразделениями, он должен четко и однозначно представлять себе прикладное назначение реализуемой программной системы в целом. Это знание позволит быстро изучить архитектуру связанных с ней дочерних приложений и эффективно связать элементы интеграции с сопутствующими рисками для эффективного управления ими.
Мы не хотим, чтобы на основе обсуждаемых тем у Вас сложилось впечатление, что системный архитектор - это средство к наведению порядка в процессах разработки и умах ответственных исполнителей. Системный архитектор, по своей профессиональной природе, должен иметь и развивать навыки менеджера, но в его обязанности не входит планирование и координация обмена мнениями между разработчиками и заказчиками – это, как правило, прерогатива руководителя проекта, значимость которого так же очень высока, но нами не обсуждается.
Где же найти этих людей, которые смогут с успехом выполнять задачи системного архитектора? В каких учебных заведениях их готовят (и готовят ли)?
Прежде всего, системным архитектором может быть только сотрудник, который детально знает специфику определённого бизнес направления, для которого разрабатывается программный продукт, с учетом понимания приоритетов большинства бизнес процессов этого домена. Образование, которым должен обладать системный архитектор, тема неоднозначная, с одной стороны есть множество высококлассных разработчиков, которые не обладают законченным профильным высшим образованием, но когда мы говорим об определенных, достаточно сложных и ответственных процессах, таких как проектирование, синтез данных в полноценную рабочую модель и т.д., то необходимо констатировать, что системный архитектор должен обладать, по крайней мере, одним высшим образованием. Тенденции современного мира таковы, что в ближайшем будущем речь будет идти о нескольких высших образованиях или научных степенях, подтверждающих не только профессионализм архитектора, но и богатый рабочий кругозор. На сегодня, к услугам жаждущих стать системными архитекторами – многочисленные справочно-информационные, инструментальные ресурсы и множество разнообразных образовательных программ, пройти которые можно как в России, так и за рубежом. Любая длинная дорога начинается с первого шага, сделать который может только самый заинтересованный.
Перспективным кандидатом на роль системного архитектора становится специалист, способный организовывать, управлять и активно участвовать в дискуссиях по разнообразным профессиональным вопросам, связанным с текущими проектами, стремясь при этом не защищать позицию одной из сторон, а найти оптимальное компромиссное решение, которое будет соответствовать не только бизнес целям, но и техническим возможностям конкретного программного продукта.
Кроме аспектов образования и самообразования необходимо привести аспекты "внешней" среды, в которой формирование системных архитекторов происходит более плодотворно, по сравнению с другими компаниями.
Окружение, способствующее эволюции специализированных специалистов в системные архитекторы, может быть частью вполне логичной и эффективной политики компании в области информационных технологий. Организация, при желании развития компетенций института системной архитектуры должна создать систему поддерживающих процессов для становления соответствующих специалистов.
После того, как мы рассмотрели основные процессы, инструментарий и факторы, связанные с созданием и развитием архитектуры программных продуктов, целесообразно приступить к вспомогательным процессам, поддерживающим и обеспечивающим результативность и эффективность информационной архитектуры.
В качестве первого мы рассмотрим процесс мониторинга за "жизнедеятельностью" архитектуры и ее качеством. На сегодняшний день, на рынке информационных систем присутствует целый ряд специализированных программных продуктов, каждый из которых направлен на определенные типы процессов мониторинга за функционированием информационных систем. Наибольшей популярностью пользуются комплексные системы мониторинга работоспособности программных продуктов, которые позволяют осуществлять автоматизированный и непрерывный контроль мониторинга за работоспособностью ИТ-систем.
Встроенные в жизненный цикл программных продуктов, подобные системы способствуют повышению качества работы информационных подразделений организации за счет своевременного обнаружения и последующего устранения сбоев в программных архитектурах, функциональности и инфраструктуре предприятия в целом. В последующем, при соответствующей работе над ними, они способны выявлять и предотвращать сбои в работе критичных для бизнеса информационных систем и обеспечивать их целенаправленное совершенствование и развитие. Комплексные системы мониторинга способствуют решению следующих задач:
При выборе системы мониторинга и разработке соответствующих процессов необходимо не только полностью и однозначно представлять основные бизнес процессы, над которыми будет выполняться мониторинг, но и оптимально интегрировать друг с другом различные компоненты программного продукта и различные информационные системы. Такой подход позволит достичь:
Возможны несколько подходов к построению системы мониторинга:
При подобном подходе система мониторинга создается один раз и в последствии, новые программные продукты, подключаемые к системе мониторинга, начинают контролироваться по согласованным ранее правилам. Подобный подход является наиболее системным и требует для своей реализации достаточно большое количество ресурсов на проектирование первоначальной архитектуры системы мониторинга;
Данный подход к созданию системы мониторинга подразумевает поэтапное построение комплекса мониторинга на основании конкретных требований к по каждому отдельному процессу. Этот подход является относительно недорогим, но при бесконтрольном развитии, возможно, что каждый следующий процесс будет противоречить предыдущим требованиям к мониторингу;
Третий подход, как это часто бывает в современных методологиях различных направлений сферы информационных технологий, сочетает в себе достоинства первого и второго, при этом в нем предприняты попытки к минимизации большинства недостатков, составляющих его методов. Он предполагает формирование в компании Каталога ИТ-услуг и согласуется с идеологией сервисного подхода в управлении ИТ (ITSM). Изложенные действия позволяют реализовывать систему мониторинга одновременно с двух противоположных "концов".
Наиболее оптимальным, как Вы успели отметить, является комбинированный подход к реализации систем мониторинга. Как правило, в этом подходе для каждой необходимой функциональности программного продукта, мониторинг которой необходим, разрабатывается ресурсная модель, которая отображает структуру взаимосвязей между функциональностью программного продукта, архитектурными компонентами и аппаратными элементами ИТ-инфраструктуры. Эта связка артефактов обеспечивает:
Для реализации систем мониторинга используются различные специализированные программные инструменты. Наибольшую популярность получили системы таких крупнейших вендоров, как HP и IBM. Многие программные продукты предлагаются на рынке в комплекте с предустановленными настройками для выполнения мониторинга. Но обольщаться и рассчитывать на то, что эти настройки подойдут каждой компании не стоит. Организация сама должна провести ряд мероприятий, направленных на адаптацию системы под свои особенные реалии работы.
В процессе адаптирования должен быть подготовлен пакет документации, на основе которого станет возможно развитие и сопровождение реализованной системы мониторинга.
После того, как информационная система сдана в промышленную эксплуатацию, по жизненному циклу любого программного продукта начинается стадия его сопровождения. Важность и критичность наличия стратегий и политик развития направления информационных технологий в конкретной организации, обосновывающих тренд сопровождения конкретного программного продукта мы уже упоминали ранее и повторно подробно обсуждать эту тему не будем. Скажем только, что процессы развития (тему развития раскроем в следующем пункте) и совершенствования информационных систем, которые, как правило, ассоциируются с этапом сопровождения - это разные процессы. Соответственно, подход к их организации должен быть разным, но при этом оба должны управляться и контролироваться в общей информационной архитектуре предприятия, в зависимости от имеющихся для этого ресурсов.
Эффективность этапа сопровождения определяется качеством и эффективностью, в рамках конкретных условий, реализованного программного продукта. Качество, как мы выяснили ранее, понятие относительное и рассчитывать на то, что продукт, по абсолютным шкалам измерения, будет идеальным - неправильно, но вот заранее задуматься о возможности его оптимизации – правильно, но с учетом определенных требований, которые должны быть выявлены в процессе анализа и архитектурного проектирования.
Среди многих профессионалов бытует мнение, что преждевременная оптимизация вредна, и это абсолютно верно. Только это высказывание имеет определенный контекст, который накладывает ограничение на его использование:
Оптимизация преждевременна в тех случаях, когда мы можем утверждать, что требования к реализуемой архитектуре и функциональности не предполагают на близлежащей и отдаленной перспективе процесса сопровождения функциональности, которая должна поддерживать оперативность и высокоточные характеристики бизнесс процесса, для которого оно разрабатывается. Можно привести следующий пример: Раз в месяц/квартал необходимо формировать агрегированный отчет. Его генерация занимает час рабочего времени, но может быть выполнена в фоне, без ущерба основным процессам. Конечно, можно путем оптимизации кода уменьшить это время в N раз, но, зачем и для кого?
Если речь идет о сложном и комплексном программном продукте, то заранее задуматься об оптимизации просто необходимо. Как правило, на сложные информационные системы стэйкхолдеры возлагают обширные надежды (явные и что более опасно скрытые) и воспринимают их как "магическое" решение большинства их бизнес проблем и задач.
Сложность программного продукта не только определяет его возможную бизнес универсализацию, но и сложность соответствующей программной архитектуры. Если в процессе проектирования не заложить достаточный процент функциональности, в котором будет поддерживаться программная гибкость, адаптивности и изменяемость, то реалии разработки могут не удовлетворять потребностям бизнеса и ситуации могут быть критичными для компании в целом.
Именно подобными мотивами должны руководствоваться сотрудники, занятые вопросами разработки программных продуктов и их возможной оптимизацией.
Для прогнозируемого и предсказуемого процесса сопровождения, стадию разработки информационной системы необходимо выполнять с учетом:
Кроме прочего, для возможности сопровождения системы, по любому из представленных способов, необходимо, чтобы она была задокументирована на большинстве архитектурных уровней. Это позволит поддерживать единую, стройную архитектуру, единообразный стиль и порядок.
В прошлом абзаце мы затронули тему различия процессов совершенствования имеющегося программного продукта и его возможного развития. Особенно подробно и обоснованно данные понятия раскрываются в специализированных курсах, к примеру можно привести дисциплину системной инженерии. Наши коллеги, при наличии соответствующего желания, могут познакомиться с данными учебными дисциплинами. Мы уделим внимание тому аспекту, что выбранная стратегия работы над архитектурой программного продукта будет определять не только ее образ, а что более важно - гибкость и адаптируемость реализованного функционала:
Большинство профессионалов в сфере разработки архитектуры программного обеспечения и бизнес процессов, по складу своего мышления, являются людьми достаточно консервативными. Они неоднозначно относятся к постоянной смене пути, но реалии бизнес условий современного мира демонстрируют, что строгая и тщательно продуманная архитектура, разработанная до начала создания программного продукта, не всегда работает хорошо в проектах по разработке программного обеспечения и может приводить к увеличению ресурсов, необходимых для из реализации. Это ознаменовало начало "agile" эры в разработке программных продуктов. Основные идеи этой эры сформулированы и продемонстрированы Мартином Фаулером в его работах. Он предложил начинать возводить архитектуру с реализации наиболее простых требований к решению, этот принцип получил название "YAGNI".
В нем изложен метод формирования первоначального архитектурного базиса и последующего возведения архитектуры, по мере дополненения основных требований и их постепенного изменения, с помощью применения техники рефакторинга. Рефакторинг предполагает совершение поэтапных изменений путем эволюционного преобразования и актуализации архитектуры информационной системы. Принцип создания программного обеспечения методом рефакторинга позволяет не только разрабатывать гибкие и адаптивные программные продукты, но и соответствовать принципам развития при их сопровождении. Даже когда мы говорим об архитектуре базы данных, традиционно наиболее фундаментальной части архитектуры информационной системы, Мартин Фаулер приводит данные об успешном использовании принципа рефакторинга и других гибких методик для её эволюционного развития.
Возможность эволюционирования – это очень важная характеристика программного продукта. Она приучает команду и всех заинтересованных сторон к пониманию того, что архитектура и функциональность не являются статичными, а разработаны для того, чтобы быть динамичным атрибутами современного мира, при условии соответствующего сопровождения.
Один из основных аспектов, влияющих на успех создания оптимальной архитектуры программного продукта, является роль системного архитектора. В современном динамичном мире не стоит недооценивать профессиональную интуицию и способность адекватно реагировать на изменения и смену курса развития программного обеспечения, актуальность которого определяется способностью поддерживать требования рынка и стэйкхолдеров к определенной области бизнеса, автоматизированной конкретным программным продуктом. Системный архитектор не только "наполняет" процессы разработки программных продуктов оптимальными шаблонами проектирования, необходимым инструментарием, но и выстраивает систему эффективных коммуникаций, привносит свои наиболее успешные и хорошо зарекомендовавшие себя предпочтения, навыки, опыт, которые участвуют в формировании создаваемой системы намного больше, чем инженерные техники, UML-диаграммы и прочие значимые, но не определяющие артефакты процессов реализации программного обеспечения.
Так же необходимо отметить, что эффективно сформированная система мониторинга может способствовать не только результативному функционированию разработанного программного обеспечения, но и предопределять направление его сопровождения, успех которого будет зависеть от многих факторов, основным из которых является видение заинтересованных сторон того, что должно происходить с информационной системой в настоящем и будущем.
Данная лекция является завершающей лекцией курса "Разработка требований. Архитектурное проектирование программного обеспечения". В курсе мы привели множество факторов, которые заслуживают пристального внимания и дополнительного анализа коллегами, под призмой их профессионального опыта.
Мы осветили наиболее значимые исторические предпосылки, которые привели к выделению и формированию области архитектурного проектирования и способствуют ее актуальности на сегодняшний момент, причем, можно констатировать, что в будущем интерес к данной теме будет только усиливаться. Выполнили обзор практик и стилей создания архитектуры, а также различных типов и видов требований, зависимости между ними и то, как они предопределяют архитектуру создаваемых программных продуктов. Показали основные объекты современных архитектур, их связи как друг с другом, так и с окружением, события которого так же предопределяют образ создаваемого программного обеспечения. Рассмотрели необходимый набор документации, его состав и структуру, инструментарий разработки и моделирования требований к процессам и архитектуре информационных систем, которые необходимы для того, чтобы создаваемая система могла в дальнейшем поддерживаться и развиваться в соответствии с ожиданиями заинтересованных сторон.
В завершении мы оценили то, как современные стандарты в области информационных технологий влияют на процессы архитектурного проектирования, способствуют минимизации возможных рисков и предложили коллегам задуматься о том, как эффективно и результативно выстроить и организовать процессы мониторинга и сопровождения информационных продуктов.
Архитектурное проектирование и обеспечивающие его процессы, на которых сконцентрирован основной фокус нашего курса, занимают определяющее место в разработке программного обеспечения. Создавая этот курс, мы планировали не только раскрыть тему требований под углом архитектуры и функциональности конкретного разрабатываемого программного продукта, но способствовать распространению и популяризации сферы архитектурного проектирования. Но не стоит думать, что курс будет полезен только коллегам, которые ищут свой путь в области информационных технологий или уже встали на рельсы проектирования и постепенно набирают оптимальный для них ход развития. Информация, изложенная нами, может быть использована руководящими менеджерами подразделений, в функции которого входит создание специализированных программных продуктов. На основе приведенных данных могут быть оптимизированы процессы развития, отбора, найма квалифицированных специалистов по проектированию информационных систем, а также улучшено планирование и управление информационными технологиями конкретной организации.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.