Рубрика «Анализ и проектирование систем» - 117

в 13:15, , рубрики: data structure, Microservices, Анализ и проектирование систем, Блог компании Mail.Ru Group, микросервисы, Профессиональная литература, хранение данных

image

В статье «Данные снаружи и данные внутри» 2005 года Пэт Хелланд размышляет о данных в сервис-ориентированных архитектурах. В настоящее время СОА принято считать «микросервисной архитектурой», состоящей из «микросервисов». Хелланд показывает, что для инкапсулированных данных и данных, которыми обмениваются сервисы, требуются совершенно разные подходы. Переход от монолитной структуры к микросервисам более глубокий, чем просто рефакторинг кода в удобные, независимо развёртываемые модули:
Читать полностью »

в 5:54, , рубрики: ics, IEC 61508, IT-стандарты, plc, project management, scada, автоматизация, Анализ и проектирование систем, асу тп, информационная безопасность, критически важные системы, Промышленное программирование, стандартизация, стандарты, функциональная безопасность

Функциональная безопасность, часть 4 из 4. Процессы управления и оценивания - 1

Безопасности на хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда.

Данная статья продолжает серию публикаций на тему функциональной безопасности.

Часть 1 является вводной.
В части 2 рассмотрена общая структура стандарта МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems) и используемая в нем терминология.
В части 3 требования МЭК 61508 разложены «по полочкам» на основе их общей классификации.

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

в 2:14, , рубрики: blockchain, smart contracts, Алгоритмы, Анализ и проектирование систем, блокчейн, информационная безопасность, Криптовалюты

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

в 11:32, , рубрики: IT-стандарты, onlyoffice, ONLYOFFICE Document Editors, open source, Анализ и проектирование систем, Блог компании ONLYOFFICE, десктопные приложения, офисное по

Этот день настал: мы открыли исходный код десктопных редакторов ONLYOFFICE. Теперь они абсолютно бесплатны для домашнего и коммерческого использования. Лицензия AGPLv3, скачать на сайте, код на GitHub.

A в этой статье мы просто приведем несколько аргументов в пользу того, чтобы при отказе от Microsoft Office по экономическим или идеологическим причинам переходить на ONLYOFFICE, а не на Libre. Читайте далее, чтобы испытать боль.

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

ONLYOFFICE или Libre: о битве форматов и совместном редактировании - 1
Читать полностью »

в 9:20, , рубрики: Анализ и проектирование систем, как написать техническое задание, как написать ТЗ, как обновлять ТЗ, каким может быть ТЗ, навигация по техническим заданиям, навигация по ТЗ, обновление технического задания, Проектирование и рефакторинг, техническое задание образец, метки: , , , , , , ,

Представьте, что у вас есть корпоративная информационная система в развитие которой вкладывается 100 млн. рублей ежегодно. С момента внедрения документация на систему превратилась из одного Технического задания на 600 страниц в 300 Технических заданий, у каждого из которых есть дополнение в количестве от 1 до 10 штук, и теперь она занимает объем 3 офисных шкафов и это ещё не конец… Фабрика по производству ПО исправно и ритмично (с периодичностью в месяц) выпускает обновление системы и документирует изменения.

image

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

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

  • Как в этом объеме документов найти те, что описывают работу определенного функционала системы?
  • Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?
  • Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?

Читать полностью »

в 6:55, , рубрики: 1С, 1С-Битрикс, apaas, cloud platform, SaaS, SaaS / S+S, saas-сервис, Анализ и проектирование систем, Блог компании 1С, облачные сервисы, облачные технологии

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

Картинка для привлечения внимания: автор статьи с помощью подручных средств (облака, флаг, самолет, парашют) иллюстрирует тезис «1С в облаках».

1С в облаках - 1
Читать полностью »

в 21:38, , рубрики: highload, Lua, lua-nginx-module, nginx, Анализ и проектирование систем, архитектура, высокая производительность, высоконагруженные приложения

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

Есть несколько вариантов решения такого класса задач. Наиболее оптимальное и распространенное решение – это подписка на события. Как это реализуется в нагруженных проектах?
Читать полностью »

в 14:44, , рубрики: big data, Hadoop, MapReduce, netty, realtime mapreduce, s-expressions, spark, sql, Алгоритмы, Анализ и проектирование систем, Блог компании Яндекс, инфраструктура, Промышленное программирование, языки запросов

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

Как писать меньше кода для MR, или Зачем миру ещё один язык запросов? История Yandex Query Language - 1

Очень скоро мы поняли, что тут мог бы здорово помочь общий высокоуровневый язык запросов, который бы предоставлял единообразный доступ к уже имеющимся системам, а также избавлял от необходимости заново реализовывать типовые абстракции на низкоуровневых примитивах, принятых в этих системах. Так началась разработка Yandex Query Language (YQL) — универсального декларативного языка запросов к системам хранения и обработки данных. (Сразу скажу, что мы знаем, что это уже не первая штука в мире, которая называется YQL, но мы решили, что это делу не мешает, и оставили название.)

В преддверии нашей встречи, которая будет посвящена инфраструктуре Яндекса, мы решили рассказать о YQL читателям Хабрахабра.

Читать полностью »

в 8:57, , рубрики: Анализ и проектирование систем, архитектура, Программирование, проектирование, Проектирование и рефакторинг, Промышленное программирование, системы

Маленькая архитектура - 1

Я хочу стать архитектором ПО:

Это хорошая цель для разработчика

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

Хм. Ну, тогда ты вовсе не хочешь стать архитектором ПО.

Конечно хочу! Я хочу быть тем человеком, который принимает все важные решения.

Это хорошо, но ты не перечислил важных решений. Ты перечислил решения, не играющие особой роли.

В смысле? База данных – это не важное решение? Знаешь, сколько мы денег тратим на них?

Скорее всего слишком много. И нет, база данных – это не одно из самых важных решений.

Как можно такое говорить? База данных находится в самом центре системы! Там собраны все данные, они сортируются, индексируются и к ним осуществляется доступ. Без нее не будет системы!

База данных это просто устройство ввода-вывода. Так получилось, что она предоставляет некоторые полезные инструменты для сортировки, запросов и отчетов, но все это – вспомогательные аспекты в рамках системной архитектуры.Читать полностью »

в 12:13, , рубрики: UML, UML Design, Анализ и проектирование систем, Блог компании Luxoft, Документирование требований, сценарии использования, метки:

Уже несколько лет я, как аналитик, довольно широко использую в своей работе сценарии использования (СИ) и диаграммы СИ для документирования требований. Вообще, у сценариев использования есть разные названия. Их называют use cases, варианты использования и даже прецеденты. Помню, как в середине 2000-х, на некоторых аналитических ресурсах шло жаркое обсуждение того, как же перевести термин use case на русский язык. Вот тогда это страшное слово «прецедент» и появилось, даже более того, некоторые товарищи утверждали, что русский язык ущербен и не позволяет передать все тонкости понятия use case. Но как показало время, понятие сценарий использования (или вариант использования) вполне себе подходит и довольно приятно на слух.
Читать полностью »

1...1020...116117118...120130...156
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js