Управление рисками позволяет детализировать, с какими финансовыми, практическими или социальными проблемами может столкнуться бизнес. Выявление рисков помогает бизнесу создавать более совершенные продукты и процессы, а также повышать прибыль за счёт выявления и снижения потенциального негативного воздействия этих рисков. Риск-менеджмент может стать важнейшим навыком для менеджеров и владельцев бизнеса.
В этой статье мы обсудим, как научиться иденифицировать риски и почему это важно, а также рассмотрим восемь рекомендаций по определению рисков.
Если вы когда-нибудь думали о проведении юнит-тестирования в Xcode, вы наверняка обращали внимание на XCTest. Это довольно простой фреймворк на Objective-C и Swift. Однако тестирование асинхронного кода всегда было немного сложным из-за таких конструкций, как делегаты и коллбэки (функции обратного вызова).
В этой статье мы начнём с рассмотрения классического способа тестирования асинхронного кода, чтобы убедиться, что мы все на одной волне относительно плюсов и минусов классического асинхронного теста. После этого мы рассмотрим, как async / await кардинально меняет способ написания юнит-тестов для асинхронного кода, и как он может повлиять на то, что тесты оказываются успешными и неудачными.
Многие модели, практики и методы управления были созданы и развиты на основе инициатив в области информационных технологий. Появился Agile, развилась дисциплина управления проектами, а бизнес-операции и цифровые операции стали единым целым.
Однажды президент одной крупной организации привлёк внешнего консультанта для урегулирования конфликта между двумя вице-президентами. Отношения между ними испортились настолько, что они общались только через сообщения, почту и посредников. В начале сессии оба вице-президента отказывались даже смотреть друг на друга. Со временем они начали понимать, как их действия влияют друг на друга, и стали искать новые способы взаимодействия — и тогда их внешняя враждебность уступила место более тесному сотрудничеству. К концу сессии вице-президенты разговаривали и даже смеялись вместе. Однако, хотя поначалу все были довольны результатом, результаты вмешательства оказались недолговечными: уже через месяц вице-президенты возобновили свою борьбу за влияние — в ущерб компании в целом.
В этой статье поговорим о том, почему важно тестировать электронные письма, какие элементы следует проверять в первую очередь и как облегчить процесс тестирования.
Когда-то компания Sigma Tech (вымышленное название) была одной из самых успешных компаний малого бизнеса в США, с фокусом на гуманитарной деятельности и высокой прибыльностью. Сотрудники были преданы ценностям компании, имели долю в её будущем через акции. Генеральный директор активно стремился к расширению бизнеса, а команда вице-президентов была молодой, целеустремленной и амбициозной. В общем, в компании были все предпосылки для позитивного будущего.
BPMN — это язык визуального моделирования бизнес-процессов, использующий графические блок-схемы. Это открытый стандарт, созданный консорциумом Object Management Group (OMG).
Процессный движок Flowable позволяет разворачивать процессы в соответствии с международным отраслевым стандартом BPMN 2.0. Каждый процесс BPM представляет собой последовательность объектов, связанных с действиями и имеющих стартовое и конечное события.
BPMN используется для автоматизации бизнеса — например, в управлении пользовательским/клиентским опытом или управлении мероприятиями. Он упрощает и ускоряет разработку, уменьшая количество ошибок.
Инструменты для тестирования методом «чёрного ящика» сосредоточены на анализе входных и выходных данных программного обеспечения, его поведения и функциональности с точки зрения конечного пользователя. Они используются для различных типов тестирования, включая функциональное, системное и приёмочное, не требуя доступа к исходному коду.
Преимущества этих инструментов заключаются в их способности обеспечить объективную оценку внешних функций программного обеспечения. Они помогают убедиться в том, что разрабатываемый софт соответствует требованиям пользователей и ведёт себя ожидаемым образом в реальных ситуациях. Эти инструменты особенно полезны для выявления несоответствий в функциональности и интерфейсе программы, что делает их идеальными для тестировщиков без глубоких технических знаний о внутреннем устройстве софта. Такой подход способствует ориентированности на пользователя. В этой статье представлен обзор 13 инструментов для тестирования методом чёрного ящика.
Тестирование баз данных включает в себя тестирование методом «чёрного ящика», «белого ящика» и набор требований ACID — атомарность, согласованность, изоляция и устойчивость. В этом руководстве я объясню все необходимые определения, расскажу, как оно проводится, и приведу примеры.
В этой статье мы поговорим о SafeTest — революционной библиотеке, которая предлагает свежий взгляд на сквозные (E2E) тесты для веб-приложений с пользовательским интерфейсом.
Риски представляют собой любые трудности, факторы, события или проблемы, которые могут оказать положительное или отрицательное влияние на проект или конкретный бизнес-процесс. Эффективное управление рисками необходимо для того, чтобы риски, которые всё же возникают, не влияли негативно на общие цели. Менеджеры, ответственные за планирование и инициирование проектов, часто придерживаются стратегий, направленных как на избегание, так и на снижение потенциальных рисков. В этой статье мы поговорим об избегании и снижении рисков, а также о том, что следует учитывать при разработке стратегии управления рисками.
Эта статья отражает моё личное мнение и профессиональные взгляды, учитывающие различные точки зрения в сообществе Android-разработчиков. Кроме того, я регулярно просматриваю руководства от Google для Android.
Важно подчеркнуть: некоторые хорошие инструменты, паттерны и архитектуры я не упомянул в статье в явном виде, но это не отменяет их потенциал в качестве ценных альтернатив для разработки Android-приложений.
Анализ рисков проекта помогает управлять проектом от начала до конца, чтобы исключить или сократить потери или неудачи в бизнесе. Причины рисков зависят от типа, сложности и продолжительности проекта. Цель анализа рисков проекта состоит в том, чтобы выявить возможные угрозы и сделать предварительную оценку последствий, а также запланировать меры по их снижению.
В этой статье мы постараемся понять, зачем организация должна проводить анализ и управлять рисками проекта, а также приведём примеры некоторых распространённых рисков, с которыми сталкиваются в управлении проектами, и тех рисков, которые можно выявить при анализе проектных рисков.
Представляем вам Asserts — платформу для анализа и отслеживания метрик. Сканируя метрики вашего приложения в любой совместимой с Prometheus базе данных временных рядов (time-series database, TSDB), Asserts в реальном времени:
— создаёт карту архитектуры приложения и инфраструктуры, — строит дашборды, — отслеживает цели уровня обслуживания (service level objectives, SLOs) — и запускает автоматические проверки для выявления изменений и потенциальных проблем.
Наша задача — снизить усталость от предупреждений и сократить время поиска первопричины.
Меня не покидают размышления — что на самом деле значит быть Delivery Manager-ом? И почему мой опыт в этой роли часто расходится с опытом и ожиданиями других?
Реализация защиты от сбоев из-за фрагментации кучи и повышение скорости выполнения с помощью STL-альтернативы std::allocator, работающей с блоками памяти фиксированного размера.
В этой статье описывается реализация STL-совместимого аллокатора, ориентированного на выделение и высвобождение блоков памяти фиксированного размера. Предложенный аллокатор предотвращает сбои, вызванные фрагментированной кучей, и обеспечивает стабильное время выполнения выделения/высвобождения памяти. Моей главной целью при создании stl_allocator было устранение ошибок памяти. Вдобавок использование STL-совместимого блочного аллокатора открывает возможность использования функций стандартной библиотеки шаблонов (STL) C++ в проектах, в которых иначе это было бы невозможно.
В этой статье я постараюсь развеять один из самых распространенных мифов о разработке по Agile: «Необязательно иметь в команде тестировщиков. Разработчики могут тестировать сами». Я думаю, такой подход возможен в некоторых «особых» сценариях, но в любом случае это было бы не очень эффективно.
