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

Доброго времени суток! Я самоучка, никогда не получал образования в сфере IT, не работал программистом и не проходил каких-либо специализированных курсов в этой сфере. Акцентирую внимание на этом в самом начале для того, чтобы было понимание, что данная статья не претендует на статус профессионального руководства “как надо работать с Elasticsearch (далее по тексту просто ES)”, это не панацея, если можно так выразиться. Все описанное, лишь основано на моем личном опыте и понимании схемы и структуры документов, ориентированной на использовании для построения фасетного поиска в интернет-магазине к которому я пришел при изучении и разработке. Т.е статья рассчитана больше на новичков без личного опыта и представления работы с NoSQL базами данных, коей и является ES.

NULL - это специальное значение, которое используется в SQL для обозначения отсутствия данных. Оно отличается от пустой строки или нулевого значения, так как NULL означает отсутствие какого-либо значения в ячейке таблицы.

История появления NULL в SQL довольно интересна и длинна. В начале 1970-х годов Д. Камерер (D. Chamberlin) и Р. Бойд (R. Boyce) предложили использовать реляционную модель для полной замены иерархических и сетевых моделей данных, которые были актуальны в то время. Полная замена предполагала возможность хранения значений NULL в таблицах структуры базы данных.

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

Когда была разработана SQL, NULL был реализован как специальное значение или маркер, который указывает на отсутствие значения в столбце. Таким образом, в SQL NULL означает отсутствие значения или неопределенное значение.

Однако, NULL создал некоторые проблемы при работе с данными в SQL. Например, если вы выполняете операцию на столбце, содержащем NULL значение, результат операции также будет NULL. Это означает, что использование NULL может приводить к нежелательным результатам, таким как непредсказуемое поведение.

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

“Сможет ли ChatGPT заменить меня на работе?”. Вопрос ведь далеко не новый. Статья дает на него ответ в контексте профессии архитектора ПО. На реальном примере взаимодействия с "чатом" предлагается разбор преимуществ и недостатков использования для решения рабочих задач.

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

Но… Что делать, если ты эту игру прошел или очень близок к ее прохождению?! Почивать на лаврах или переходить на следующий уровень за пределы функции анализа?

В сети вы можете найти множество статей на тему «UML мертв», «Почему системным аналитикам не нужен UML» и множество подобного. Работая на протяжении последних 15 лет в совершенно разных компаниях, с совершенно разным жизненным циклом приложений и систем, с различной структурой и методологиями разработки я вижу одно и тоже — попытки ускорения time‑to‑market за счет отказа от процесса управления требованиями, подаваемые под разными прекрасными аргументами, приводят 100% компаний к необходимости переписывать приложения не потому, что оно не отвечает требованиям, а потому что «никто не знает как или почему оно так работает».

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

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

Чтение ФТ — занятие непростое. Восприятие новой информации и её анализ требуют продолжительной концентрации и расходуют главный ресурс IT‑шника — внимание.
Если текст сложный, читатель спотыкается в нём и увязает, перечитывает по несколько раз, тратя время и ресурс внимания.

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

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

Автор: Кри­во­ше­ев Роман Ва­си­лье­вич, яв­ля­ет­ся изоб­ре­та­те­лем прин­ци­пи­аль­но но­во­го под­хо­да к ре­ше­нию транс­порт­ных про­блем «Эко­ло­ги­за­ция ур­ба­ни­за­ции», и со­от­вет­ствен­но, пер­во­ис­точ­ни­ком пред­став­лен­ной ин­фор­ма­ции.

На­чать пред­ла­гаю с са­мо­го на­ча­ла, то есть, с тех­ни­че­ско­го за­да­ния (ТЗ) на ИТС. Так как транс­порт­ная наука яв­ля­ет­ся при­клад­ной, то же­ла­тель­но, чтобы ТЗ пи­са­ли бы сами поль­зо­ва­те­ли. При­чём в фор­ма­те того, что нужно имен­но поль­зо­ва­те­лям, а не того, что со­вре­мен­ная транс­порт­ная наука может ре­а­ли­зо­вать. Эти за­про­сы поль­зо­ва­те­лей, не про­ти­во­ре­ча­щие за­ко­нам фи­зи­ки, но без учёта тех­ни­че­ской воз­мож­но­сти и спо­со­бов их ре­а­ли­за­ции, будем на­зы­вать «хо­тел­ка­ми». То есть, те­ле­пор­та­ция не под­хо­дит, а вот от­сут­ствие про­бок и ав­то­хам­ства под­хо­дит. Тогда, иде­аль­ной транс­порт­ной си­сте­мой будем счи­тать си­сте­му, удо­вле­тво­ря­ю­щую ВСЕМ тре­бо­ва­ни­ям ВСЕХ по­тре­би­те­лей в мак­си­маль­ном тео­ре­ти­че­ском объ­ё­ме с учё­том нетранс­порт­ных огра­ни­че­ний ре­аль­но­го мира.

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

Всем привет! Меня зовут Валентина Ляликова. Я ведущий бизнес-аналитик в X5 Tech и преподаватель направления «Пользовательские истории и критерии приёмки» в Школе бизнес-анализа X5 Tech. 

Большой опыт работы на разнообразных проектах помог сформировать мне список правил, которых я придерживаюсь каждый день при написании User Story и Acceptance Criteria (US+AC). В этой статье хочу поделиться ими с вами и показать на примерах ошибочных вариантов написания документа US+AC, почему так важно применять эти правила в работе.

Аннотация

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

Статья начинается с краткого обзора литературы.

Во второй главе обсуждается разница между автономностью и автоматизацией.

В третьей главе дается определение современного производства и описываются процессы, наиболее подходящие для автоматизации.

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

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

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

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

1. Указывайте количественно и качественно выраженные достижения

Это самый главный и мощный пункт.

Большинство людей пишут какие-то беспомощные аморфные функции и фразы про обязанности и участие — «состоял, привлекался, принимал участие». Это выглядит, как свидетель из Фрязино, а не мощный проектный специалист, который будет двигать проект вперёд.

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

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

Как обычно пишут:

Функции и задачи:

* разрабатывал требования, общался с клиентами, командой, отвечал на вопросы, рисовал схемы…

Как надо: ...

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

Service Mesh — подход, который еще вчера был на вершине хайпа, а сегодня становится стандартной технологией для Backend. В этой части посмотрим, как теория накладывается на практику и на что обратить внимание, выбирая Service Mesh для своих задач.

Меня зовут Максим Чудновский, я занимаюсь развитием интеграционной платформы Platform V Synapse в СберТехе. В платформе реализован RPC и Service Mesh, которым я и занимаюсь. В этой статье продолжу рассказывать о технологии и поделюсь соображением о том, как выбрать конкретное решение для ваших задач.

Сейчас в IT-сфере набирают популярность так называемые low-code и no-code системы. Разработчики таких систем твердят, что с помощью их продуктов бизнес может создавать прикладное ПО без профессиональных разработчиков. Еще и весь интернет набит статьями, которые преподносят low-code и no-code как что-то кардинально новое и очень крутое для людей, которые не умеют программировать. Так ли это на самом деле?

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

Подход к использованию концепции Digital twin для создания производства нового типа - автономной масштабируемой смарт фабрики.

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

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

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

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

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

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