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

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

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

Процедура передачи может регулироваться, например, управленческими правилами делегирования, а именно:

Краткий гайд по наведению порядка HTTP status code и тому, как действовать если реальность становится по-настоящему пугающей.

Представим совершенно невероятную ситуацию: компания-стартап почувствовала потребность в системном аналитике и наняла своего первого специалиста. Знакомство с командой прошло позитивно, аналитик получил все необходимые доступы сразу. Он  изучает продукт компании и получает первую задачу: спроектировать новый API endpoint с применением архитектурного стиля REST. 

Он запускает несколько методов… и дальше начинает происходить что-то сверхъестественное:

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

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

Обо всем этом и поговорим.

Давайте разбираться!

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

Каждое улучшение ускоряет поток. Но в этом потоке остаётся одна переменная, которая почти никогда не входит в расчёты. Это сам человек — тот, кто проходит через интерфейсы, переключается между задачами, принимает решения. И тот, чьё восприятие оказывается вне внимания системы.

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

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

Теперь есть продолжение про абсолютную инкапсуляцию-изоляцию.

Мы любим говорить: «Нужно делать CustDev». Или: «Нужно считать Юнит-экономику». Или: «Нарисуем CJM — и станет ясно».

Проблема в том, что эти артефакты часто делаются изолированно: JTBD не связывается с User Story, Юнит-экономика существует в вакууме, Use Cases живут отдельно от гипотез, а гипотезы накапливаются и становится непонятно, почему они появились именно в таком порядке.

В результате — знания есть, но целостной картины видения продукта нет.

Привет! Это Маша и Серёжа, в прошлом тексте мы научились анализировать связи между двумя качественными переменными, а сегодня расскажем, как анализировать линейную зависимость между двумя количественными.

В этой части цикла мы поговорим о центральном элементе GraphQL — схеме. Именно она является точкой соприкосновения клиента и сервера. И если нет схемы — то нет и API.

Привет, всем!

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

Разработка браузерного расширения началась с простой идеи: упростить поиск по закладкам и открытым вкладкам, а также попробовать свои силы в создании проекта с элементами монетизации. В этой статье я расскажу, как за две недели прошёл путь от прототипа до публикации в Chrome Web Store и Firefox Add-ons, какие технологии использовал и с какими трудностями столкнулся. Надеюсь, мой опыт вдохновит других разработчиков попробовать свои силы в создании подобных проектов. Полный код проекта доступен на GitHub.

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

Внедрения ERP‑систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко‑дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP‑систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4].

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

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

Меня зовут Александр Елизаров, я работаю в группе аналитики ключевых показателей в бизнес‑группе Поиска и рекламных технологий. В течение нескольких лет нам приходилось прогнозировать большое количество временных рядов разных доменных областей: от поисковой доли Яндекса до DAU определённых сервисов. Чтобы успешно справляться с этой задачей, мы вместе с коллегами разработали собственный прогнозный фреймворк. В этой статье я расскажу, как создать универсальный и гибкий пайплайн для прогнозирования. Под катом рассмотрим:

— правильно выстроенную иерархию данных;

— методы консистентного предсказания абсолютных и относительных метрик;

— частые проблемы моделей и то, как мы их фиксили;

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

Привет! Это команда курса «Python для анализа данных». Собрали для вас подборку бесплатных ресурсов для изучения Python с нуля. Здесь вы найдёте как интерактивные курсы с практическими заданиями, так и теоретические материалы с подробными объяснениями.

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

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

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

Меня зовут Вячеслав Кудряшов, я исполнительный директор Mission Control Center в Сбере. Предлагаю порассуждать о том, что такое «неподходящий момент» и как бороться со сбоями в этот период.

Привет, Хабр! Меня зовут Маша, я бренд-аналитик, провожу разные исследования, а в перерывах пишу на Хабр. Коллеги из команды спецпроектов попросили меня протестировать на моих реальных задачах MWS Tables и сравнить со своими привычными сервисами. Я проверила его для проведения опросов, обработки данных и отслеживания задач на канбан-доске — и готова поделиться впечатлениями.

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

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

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

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

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

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

Сегодня в блоге ЛАНИТ на Хабр я хочу поделиться десятью шагами из своего опыта, которые помогали моей команде справляться с ситуациями, когда требования росли быстрее, чем их успевали зафиксировать.

Добро пожаловать в четвёртую и заключительную часть серии о новом Flowable Async Executor. До этого момента путь был довольно насыщенным:

Однако остаётся один важный вопрос: как мы пришли к текущей реализации? Что подтолкнуло нас к этим изменениям и почему? Как мы нашли узкие места и использовали эти данные для создания лучшего подхода? И, учитывая, что первая версия появилась более десяти лет назад, как Async Executor эволюционировал, сохраняя обратную совместимость?

Именно этому посвящена эта часть. Мы воспользуемся возможностью оглянуться назад и вспомнить различные реализации, которые появлялись за это время. Мы выделили четыре поколения Async Executor и кратко рассмотрим каждое из них. Поскольку Flowable является форком Activiti, история начинается с первой версии Activiti (5.0.0).