Анализ и проектирование систем

Официальный сайт движения за изменение системы единиц времени.

Здесь я подробно напишу на русском языке объяснение.

Несколько лет назад Леруа Мерлен начала масштабную программу ИТ-трансформации с использованием таких прогрессивных течений, как микросервисная архитектура, предметно-ориентированное проектирование (оно же DDD) и формирование собственных in-house-команд разработки. Пилотным проектом этой программы стало построение омниканальной платформы продаж, то есть возможность для клиента сделать взаимодействие с компанией удобным и доступным через любой существующий канал продаж, будь то сайт, магазин, колл-центр и т. д., в том числе наша платформа дает возможность взаимодействовать с различными партнерами для получения бизнес-синергии. Этой статьей мы начинаем рассказ об опыте использования open-source-платформы Camunda.

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

Даже частные компании могут требовать документацию по ГОСТу, считая, что следование стандартам гарантирует качество ПО. Однако, хотя такой подход обоснован в производстве мороженого и многих других продуктов, в IT-индустрии у него есть определенные минусы — и в статье мы рассмотрим их подробнее. 

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

Кому будет полезна статья:

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

- тендерным специалистам со стороны как заказчика (специалистам по закупкам), так и исполнителя;

- заинтересованным лицам команды разработки (аккаунтам, ПМ, аналитикам).

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

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

Статья написана для IT-руководителя, участвующего в проекте запуска внутреннего корпоративного портала в крупной компании. Говорим о задачах, технических рисках и лучших практиках.

Сегодня я публикую перевод доклада «An Examination of Open System Architectures for Avionics Systems– An Update» сделанного Joyce L. Tokar, PhD, Pyrrhus Software, LLC, в марте 2017.

Признавая необходимость доступных и эффективных решений для развития систем авионики, Министерство обороны США (Department of Defense, DoD ) в указаниях по повышению эффективности военных расходов (Better Buying Power 3.0, BBP), Инструкции 5000.02 и Руководстве по оборонным закупкам (Defense Acquisition Guidebook, DAG) призывает к использованию решений на базе Систем с отрытой архитектурой (Open System Architecture, OSA ). Цели руководства и указаний - избежать привязки к одному поставщику, сделать доступными развитие возможностей и /продвижение инноваций. В настоящее время осуществляются несколько инициатив по разработке стандартов OSA для использования в системах военной авионики. В этой статье будут рассмотрены три таких направления: Управление беспилотными системами (UxS ), Архитектура сегмента управления (UCS ), инициатива Открытые системы управления полетом (Open Mission Systems, OMS ) и реализация Перспективной среды авиационных бортовых систем (FACE​) выполненная открытой группой (Open Group). Эта статья начнется с уточнения определения систем с открытой архитектурой в понимании Министерства обороны США. Далее будет краткое описание этих трех стандартов OSA, мероприятий, которые проводятся в соответствии с указаниями Министерства обороны США. Документ затем представит анализ этих OSA на основе рекомендаций Министерства обороны США. И наконец, в документе будет обобщено состояние этих OSA и даны рекомендации для дальнейшей работы.

Как выбрать ИБП для дата-центра? Ответить на этот вопрос нам помогли самые популярные запросы в Google и «Яндексе», а также эксперты: Сергей Батраков, пресейл-инженер центра сетевых решений компании «Инфосистемы Джет», и менеджер по продукции Digital Energy из Huawei Алексей Емельянов. Их ответы на семь самых популярных Google- и «Яндекс»-вопросов по теме — под катом. Бонус: рассказ о том, как электрик умудрился вывести из строя батарейные модули ИБП, перепутав плюс и минус.

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

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

Несколько цитат:

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

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

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

Эта статья является переводом материала «Cohesion and Coupling: the difference». 

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

Продолжение цикла "Занимательная бухгалтерия".
Попробуем спроектировать базу данных модуля "Бухгалтерия" на PostgreSQL.

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

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

BEEPTOOLKIT - Инструментальная платформа для разработки автоматики, робототехники и смарт систем.

Ведущий бизнес-аналитик отдела кассового обслуживания управления анализа и проектирования департамента производства казначейских решений ГК «ОТР» Ирина Метелева рассказала о разработке калькулятора, который помогает планировать трудозатраты в условиях неизвестности. Это одна из наиболее сложных задач для новичков, но и она элегантно автоматизируется при должном подходе.

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

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

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

·        местоимения заменены на наименования компаний;

·        предложения разделены в список.

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

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

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

Всем привет! Меня зовут Виктория, в Typeable я занимаюсь вопросами архитектуры приложений и не могла пройти мимо вечного вопроса: быть или не быть? Точнее переводить нам наши решения на микросервисы или нет. И с целью это понять я провела небольшое исследование возможных причин и анти-причин, выводы по которому и привожу здесь.

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

Сам подход оформился на стыке технологий из конкурентной необходимости мгновенно вывести бизнес на новый уровень, и поэтому решения развивались лавинообразно и быстро обзаводились надстройками, паттернами и CI/CD обвеской. Для бизнеса причины не теряют актуальности и интерес к микросервисам также не угасает последние десять лет. При этом сделать решение на микросервисах для ИТ команды – задача творческая, интеллектуальная, позволяющая опробовать современные подходы и уложить на лопатки драконов консерватизма предыдущих решений. То есть, вполне благородный вызов. 

Но вот стоит ли поддаваться этой магии — большой вопрос. 

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

Впрочем, давайте разбираться.

На связи Сергей Петров, UX-проектировщик в Почтовых Технологиях — компании, создающей цифровые продукты для Почты России. Эта статья — эссе о системном рассмотрении рассмотрении большой платформы с позиции. Предполагаю, что рассказ будет интересен и полезен UX/UI-проектировщикам, архитекторам, системным и бизнес-аналитикам, менеджерам продукта, а может быть и front-end-разработчикам.

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

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

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

Я расскажу, как мы в Plesk сократили расходы на AWS-инфраструктуру одного из наших сервисов без применения уличной магии.

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