Всё о деятельности технических писателей
State & Transition Diagramm (сокращенно S&T) — схема состояний и переходов. Техника для визуализации ТЗ. Она наглядно показывает, как некий объект переходит из одного состояния в другое.
Вот объект находился в состоянии А, потом произошло какое-то действие, и он попал в состояние В. Потом он попадет в состояние С и другие... Принцип не меняется, было одно состояние, стало другое.
Поговорим о том, какие инструменты хотелось бы иметь при описании бизнес-процессов. Инструментов BPMS (BPM systems) много, но выбрать то особо нечего …
Ниже перечислим некоторые важные инструментальные возможности некоторых сред моделирования процессов (в основном ARIS и MS visio).
Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинатору условий из ТЗ.
Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям.
В тестировании таблица решений используется для того, чтобы на основе требований составить тест-кейсы. И ничего не забыть при сложных комбинациях входных условий! Ведь каждая строка или столбец таблицы → готовый тест-кейс.
Decision Table относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:
Сейчас нужно написать краткое введение о том, что важно проводить аналитику для задачи на разработку: оценить влияние изменений, проработать все возможные сценарии и т.д.
Понимание сути и объема задачи должно появиться до первой строки кода. Писать сколь угодно емкое введение о важности этого этапа можно долго, но кажется, что все мы понимаем, что самые дорогие ошибки — на этапе проектирования.
Разработчику с проектированием и документированием решения задачи помогает аналитик.
Когда разрабатывается новый функционал, аналитик пишет требования, а тестировщик их проверяет. До того, как начать реализацию. Потому что на этом этапе внести исправления дешевле всего.
Вот только на что обращать внимание при тестировании? Есть набор основных характеристик, которыми должна обладать хорошая документация:
Наверняка многие, желая создать интернет-магазин, сталкивались с вопросами. Выгодно ли? Насколько трудно создать? Сколько стоит? Какие подводные камни? Давайте попробуем разобраться.
Когда мы говорим о тестировании документации, то обычно подразумеваем тестирование требований, ТЗ. И это тестирование на полносту, однозначность и прочая. Смотрим, как новый функционал будет коррелировать со старым, не будет ли проблем. Заранее продумываем свои тесты, обсуждаем реализацию...
Однако помимо ТЗ есть еще куча другой документации, которую тоже стоит проверить. Как минимум вычитать, нет ли ошибок. Давайте посмотрим, какая бывает документация:
При написании требований часто возникает вопрос, до какого уровня стоит детализировать требования и какие артефакты должны появится в результате системного анализа.
Я стараюсь придерживаться позиции, что это сугубо индивидуально и зависит от команды и кому как комфортно работать. Случается, что разработчикам достаточно use-case для того, чтобы сделать дизайн, а тестировщикам этого достаточно, чтобы написать тест-кейсы. Поэтому я буду писать о тех артефактах, которые могут возникнуть при написании требований и о которых надо точно задуматься к моменту завершения разработки, а вы сами решайте и договаривайтесь внутри команды, когда это стоит описывать. Однозначно только, что к концу разработки документация должна содержать все то, о чем далее пойдет речь.
В феврале 2021 Atlassian прекращает продажу лицензий на серверные версии Confluence. В этой статье я поделюсь своим виденьем Xwiki в качестве аналога Confluence, закрывающего потребности по документированию для небольшой команды разработчиков.
Процесс документирования архитектуры программного обеспечения может показаться пугающим. Но на самом деле достаточно всего 5 диаграмм, чтобы объяснить структуру вашей системы практически любому.
Мы решили продолжить наш цикл статей про разработку пользовательской документации, но на этот раз нам захотелось рассказать об еще одном способе создания инструкций для пользователей — это съемка видеороликов. Мы расскажем о процессе их производства: от возникновения идеи до загрузки ролика на YouTube-канал. У нас нет студии и профессиональных актеров, мы все делаем сами и хотим показать вам, что это не так сложно. Здесь вы найдете: идеи, готовые алгоритмы и, быть может, вдохновитесь на съемку своей видеоинструкции.
Бенчмарк эффективности решения задач манипуляции предметами (MPE)
Назначение: Бенчмарк предназначен для оценки эффективности применения робототехнического комплекса в практических задачах манипуляции предметами по сравнению с другими системами автоматизации (в т.ч. роботизации) или использованием ручного человеческого труда.
Разработано: Лаборатория робототехники Сбера
Внимание! Если вы перешли сюда по ссылке из поисковой системы!
Корректная ссылка на статью: https://habr.com/ru/post/534954/
Блокчейн технологии переживают очередной ренессанс на фоне роста криптовалютного рынка и развития инициатив стейблкоинов и CBDC. Можно сказать, что это два отдельных мира. В одном блокчейн является основой для построения нерегулируемой криптоэкономики, в другом блокчейн как технология для создания новых регулируемых бизнес-процессов.
Что может объединить эти два мира? Ответ: диалог экспертов этих двух миров (криптоэкономического и корпоративного) по вопросам стандартизации технологический и лучших практик, а также принятие общих технологических подходов. Такой диалог потенциально сможет упростить последующие интеграционные процессы и ускорить принятие блокчейн-технологий широкими массами.
Но как этого достичь? В коммерческой среде, когда нужно наладить взаимодействие участников какого-либо сектора экономики, создаются ассоциации и консорциумы. В чисто технологических вопросах такими площадками выступают центры стандартизации, например МСЭ-Т(ITU-T), ИСО (Международная организация по стандартизации). В России такой независимой площадкой объединения экспертов блокчейн-технологий выступает Технический Комитет по стандартизации "Программно-аппаратные средства технологий распределённого реестра и блокчейн" (http://bccmt.ru).
Как руководитель одной из рабочих групп (с декабря 2019 года) и эксперт ISO TC 307 DLT (TC 307 - Blockchain and distributed ledger technologies) я хочу поделиться информацией по стандартизации блокчейн технологий в России и мире. А также привлечь внимание экспертов блокчейн рынка к работе ТК 159, как площадке взаимодействия, которая может многое дать своим участникам.
Когда появляется необходимость документировать схемы баз данных, разные DBMS предоставляют свои инструменты для подобных задач. И большинство из них поддерживает DESC table_name, в том числе и ClickHouse. Однако, результат этой команды не столь выразителен, как хотелось бы.
DESCRIBE TABLE data_lr
name type default_type default_expression comment codec_expression ttl_expression
Path String ZSTD(3)
Value Float64 Gorilla, LZ4
Time UInt32 DoubleDelta, LZ4
Date Date DoubleDelta, LZ4
Timestamp UInt32 DoubleDelta, LZ4При этом, системные таблицы tables и columns содержат исчерпывающую информацию, объединив которую, можно получить вот такой симпатичный результат:
В прошлой статье я обещала, что расскажу, как сделать документы легче для восприятия. Есть два основных направления: текстовка и структура документа. Сегодня поработаем с текстами. Технические документы на русском читаются особенно тяжело, и добиться легкости в них сложнее, чем в английском. Как можно исправить многословные, громоздкие документы? Давайте попробуем сделать их конкретнее, проще, короче, и последовательнее.
