Терминология IT

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

Для наглядности я постепенно буду оформлять и заполнять WBS в Google Sheets и делиться скриншотами. В конце статьи вы найдёте ссылку на готовый шаблон для скачивания.

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

Это серия из трёх постов предназначена для новичков, которые уже находятся в процессе перехода в IT или только планируют сменить нишу.

Здесь будут собраны базовые термины из IT-индустрии, которые стоит знать начинающим Проджект и Продакт Менеджерам, Продукт-Овнерам, а также тем, кто ещё не определился со своей ролью.

В конце статьи оставлю ссылки на 2 других статьи из серии.

Это серия из трёх постов предназначена для новичков, которые уже находятся в процессе перехода в IT или только планируют сменить нишу.

Здесь будут собраны базовые термины из IT-индустрии, которые стоит знать начинающим Проджект и Продакт Менеджерам, Продукт-Овнерам, а также тем, кто ещё не определился со своей ролью.

В конце статьи оставил ссылки на 2 других из серии.

Это серия из трёх постов предназначена для новичков, которые уже находятся в процессе перехода в IT или только планируют сменить нишу.

Здесь будут собраны базовые термины из IT-индустрии, которые стоит знать начинающим Проджект и Продакт Менеджерам, Продукт-Овнерам, а также тем, кто ещё не определился со своей ролью.

В конце статьи я оставлю ссылку на свой Telegram-канал и вторую статью из серии.

1 Терминология

В «Надежность в процессах. Часть 1» [OpRes24-1] были определены (упрощены): надежность, процесс и надежность в процессах. Надежность – это способность безотказно работать (работать без отказов). Надежность процесса – это как способность безотказно работать («главное процесс»), так и выдавать требуемый результат («главное результат»). Количественно – это вероятность безотказной работы (вероятность застать процесс работоспособным) и вероятность требуемого результата на выходе процесса.

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

Это относится как ИТ-системе (кластер серверов) и не ИТ-системе (сейф), так и к системе процессов (операций) и составных частей процесса, включая его ресурсы.

Если в классической теории надёжности (Надёжность в технике [27.002]) обычно рассматриваются внутренние воздействующие деструктивные факторы на техническую систему типа отказ \ сбой оборудования \ ПО, то «Надежность в процессах и операциях» (операционная надёжность) рассматривает также непреднамеренные ошибки персонала (операционные риски) и внутреннее мошенничество, внешние атаки на процессы компании, клиентов компании (социальная инженерия), стихийные бедствия (техногенные катастрофы). В конечном счете неважно: «система процессов» отказала (не выполнила задачу) из-за какой-либо поломки или из-за ее перегрузки (от нежданного «наплыва клиентов» до DDoS-атаки), поэтому в состав показателей Надежность в процессах добавляем «доступность»:

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

В этой статье мы поговорим о том, что такое MRP, обсудим особенности этой методологии, ее возможности, отличия от различных информационных систем и многое другое. Расшифровывается эта аббревиатура как «Material Requirements Planning», что означает планирование потребности в материалах. А начали ее применять для расчетов еще до появления сложных IT-систем и даже без использования ЭВМ в принципе. Но обо всем по порядку.

Прежде, чем объединяться, нам надо решительно размежеваться (Business continuity management vs Business Process Continuity vs Dependability in technics)

Синонимы: Надежность в процессах = надежность процессов = надежность операций = операционная надежность (с учетом синонимии словосочетаниями «сущ. + сущ.» [Морф23]).

En: dependability, reliability, resilience (availability, stability) Business Process. Непрерывность процессов — в контексте «business continuity» (Business Process Continuity, BPC) и т. п.

1 апреля 2024 года введён в действие новый ГОСТ "Статический анализ программного обеспечения". Если в ГОСТ Р 56939–2016 говорится о необходимости использования статического анализа при разработке безопасного программного обеспечения (РБПО), то ГОСТ Р 71207–2024 уточняет, что именно это означает.

В стандарте:

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

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

Вебинары вытекают один из другого, но в принципе они достаточно независимые, и вы можете начать знакомиться с новым ГОСТ с просмотра любого из них. Но обо всём по порядку.

Мне часто пишут и задают вопросы о моих прошлых статьях по IDEF0, MRP, ERP, BPMN и т.д. И очень часто звучит один и тот же вопрос, «устарел ли» тот самый IDEF0 или другая методология, технология, система. Также часто задают вопрос, а что лучше, например, «BPMN или ERP». В целом, все эти вопросы можно объединить в один – «устарела ли та или иная технология». Потому я решил поговорить о том, как в принципе стоит относиться к технологиям, и можно ли оценивать их с точки зрения времени, прошедшего с их выпуска, т.е. говорить об устаревании.

Майнинг — это поддержание криптовалютной платежной системы в рабочем состоянии.

Что такое "криптовалютная платежная система"?
Это децентрализованная платёжная система, которая:

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

Западные игроки, например, Adobe, Atlassian, IBM и др., покинули РФ, оставив вакуум, нарушивший бизнес‑процессы. Отечественные компании столкнулись с вопросами, на которые ни у кого в мире не было ответа. Внезапно для части отечественного бизнеса, выяснилось, что выстроенные бизнес‑процессы оказались хрупкими, позиционирование не строиться на конкурентном сравнении, маркетинговые стратегии свелись к постам в соцсетях — и все это не приносит ожидаемого результата.

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

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

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

Всё это сподвигло нас к анализу накопленного опыта и имеющихся материалов в области процессов разработки с акцентом на взаимоотношения в коллективах. Мы — это Евгений Филимонов и Андрей Клюйков, инженеры по тестированию КОМПАС-3D.

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

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

Привет, меня зовут Ольга Громыко. Я работаю техническим писателем в R‑Style Softlab и создаю документацию по банковскому ПО, которая помогает пользователям разобраться в работе сервисов. В статье подробно расскажу, чем занимается технический писатель, какие навыки помогают ему в работе и какие перспективы есть у таких специалистов.

Привет, Хабр! На связи Дмитрий Секачев — корпоративный архитектор службы развития ИТ-архитектуры ВТБ. Я занимаюсь корпоративной архитектурой в дочерних компаниях банка. Сегодня расскажу вам про новый архитектурный продукт — «Референтная прикладная архитектура как АрхПродукт» (РПА как АрхПродукт).

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

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

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

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

Начну с «исправления имен» как базы для совершенствования (меткое наблюдение конфуцианства) на примере того, как у нас переводится базовый принцип построения микросервисной архитектуры: «low coupling and high cohession». И как понимание терминологии помогает отличить профанов, изображающих с помощью птичьего языка некое знание, от действительно понимающих суть людей.

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

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

О проектировании микросервисной архитектуры с использованием фреймворка Single SPA и технологиях, связанных с его использованием.

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

Чуть-чуть обо мне

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

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

Кто такой этот ISTQB и зачем его сдавать

ISTQB - некоммерческая организация, занимающаяся определением различных принципов развития сферы тестирования ПО, таких как структура и правила аккредитации, сертификации и т.п. (с сайта RSTQB)

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

Зачем сдавать? Судя по вакансиям, в России данная сертификация не очень популярна, но для своего собственного развития и возможности в будущем претендовать на трудоустройство на международном рынке, оно того стоит.

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

Привет, Хабр! Меня зовут Александр Троицкий, я автор канала AI для чайников, и я продолжаю серию коротких статей по метрикам качества моделей для машинного обучения!