​​Мини-курс "Введение в API".Брайан Кукси
(перевод под редакцией Артема Стукалова и Дениса Бескова)

Содержание:
 ▪︎ Глава 1: Введение
 ▪︎ Глава 2: Протоколы
 ▪︎ Глава 3: Форматы данных
 ▪︎ Глава 4: Аутентификация, часть 1
 ▪︎ Глава 5: Аутентификация,  часть 2
 ▪︎ Глава 6: Проектирование API
 ▪︎ Глава 7: Связь в реальном времени
 ▪︎ Глава 8: Реализация

Скачать оригинал в формате PDF

#API | @notes_analyst

Шпаргалка по SQL - JOINs

Скачать в формате pdf

#sql | @notes_analyst

​​📑 Как правильно писать User Stories

User stories (пользовательские истории) представляют исходные требования от заказчика о целях пользователей в общем виде.
Каждая Пользовательская История – это повод к обсуждению, а не конечное требование к системе.

Для написания Пользовательских историй часто используют шаблон:

Как <тип пользователя>, я хочу <цель>, чтобы <причина>.

Авторы статьи на примере разбирают возможные ошибки при написании User stories и способы их исправления.

Перейти к статье

#работастребованиями | @notes_analyst

​​📑 Частые ошибки бизнес-/системного аналитика

Виктор Дмитриев - практикующий бизнес-/системный аналитик с опытом управления командой / глубокого бизнес-анализа / запуска Web и Mobile проектов, подготовил список ошибок , которые часто допускают бизнес-/системные аналитики в своей ежедневной работе, и даёт рекомендации, как их не допустить:

Статья 1:
▪︎ Ошибка 1. Принимаем требования заказчика без уточнения его реальных потребностей
▪︎ Ошибка 2. Создали и продолжаем поддерживать систему-франкенштейн
▪︎ Ошибка 3. Забыли обработать исторические данные
▪︎ Ошибка 4. Принимаем слова руководителей за «чистую монету»

Статья 2:
▪︎ Ошибка 5. Забыли получить согласование ТЗ
▪︎ Ошибка 6. Не привлекаете дизайнера на интервью заказчика
▪︎ Ошибка 7. В процессе сбора требований вы общаетесь не с тем человеком
▪︎ Ошибка 8. Не фиксируете все договоренности в заметках встреч

#статья | @notes_analyst

​​📚 Путь аналитика. Практическое руководство IT-специалиста. А.Перерва, В. Иванова

"Как воплотить неясные ожидания заказчика в блестящий и прибыльный проект? Как избежать ошибок на начальном этапе? Как стать эффективным аналитиком? Авторы отвечают на эти вопросы и делятся своими ноу-хау, которые позволят вам стать гуру в разработке программного обеспечения. Главное достоинство книги — ее практическая направленность. В ней собрана полезная информация со ссылками на теоретические материалы из разных областей разработки программного обеспечения: анализа, архитектуры, управления проектами, лидерства и управления персоналом — все, что понадобится в реальных производственных проектах.."

Прочитать об авторах, о том, для кого предназначена данная книга и что вы в ней найдёте, а чего нет - можно тут

Скачать 📗

#литература | @notes_analyst

Шпаргалка по оконным функциям SQL

Скачать в формате pdf

#sql | @notes_analyst

​​📑 REST, что же ты такое? Понятное введение в технологию для ИТ-аналитиков.

- Какие принципы вложил в парадигму REST её автор и как они могут помочь при проектировании систем?

- Почему существует терминологическая путаница вокруг REST?

- Как связаны HTTP и REST?

- Почему REST противопоставляют SOAP?..

Ответы на эти и другие вопросы, касающиеся REST , можете найти в видео Андрея Буракова или  в статье, составленной по его вебинару.

#rest | @notes_analyst

​​📑 Уровни тестирования.

Как минимум каждый второй системный аналитик так или иначе участвует в тестировании.
В связи с этим хотелось бы несколько постов посвятить теме:  #тестирование

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

Выделяют 4 базовых уровня:

1️⃣ Модульное/компонентное тестирование
проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.)

На этом уровне тестирования создаются модульные тесты (unit тесты), которые проверяют правильность работы модуля в тестовых условиях.

2️⃣ Интеграционное тестирование фокусируется на взаимодействии между компонентами / модулями / подсистемами / системами.

Выделяют два подтипа:
▪︎ Компонентное интеграционное тестирование - проверяет работу модулей в связке друг с другом.
▪︎ Системное интеграционное тестирование - проверяет связи между подсистемами / системами. 

Существует несколько подходов интеграционного тестирования:
▪︎ Большой взрыв - тестируются все или практически все разработанные модули, собранные вместе в виде законченной системы или ее основной части.
▪︎ Снизу вверх - все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. Далее собирается и тестируется следующий уровень модулей.
▪︎ Сверху вниз - вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые.
▪︎ Гибридная интеграция (сэндвич)- представляет собой комбинацию подходов «сверху вниз» и «снизу вверх».

3️⃣ Системное тестирование- заключается в проверке как функциональных, так и нефункциональных требований в системе в целом. 

Можно выделить два подхода к системному тестированию:
▪︎ на базе требований, когда для каждого отдельного требования пишутся тест-кейсы;
▪︎ на базе вариантов использования (use case)

4️⃣ Приемочное тестирование предназначено для проверки соответствия системы заявленным требованиям. Позволяет заказчику системы убедиться в соответствии системы спецификации.

Существует несколько форм приемочного тестирования:
▪︎ Пользовательское приемочное тестирование - проверяет пригодность системы к эксплуатации конечными пользователями;
▪︎ Эксплуатационное приемочное тестирование - тестирование с позиции тех, кто будет поддерживать работу программы;
▪︎ Контрактное приемочное тестирование - проводится в соответствии с критериями, указанными в контракте приемки специального ПО;
▪︎ Альфа- и бета-тестирование - используются для получения обратной связи от потенциальных или существующих клиентов. 

#тестирование | @notes_analyst

Друзья, привет!
Напишите, пожалуйста, в комментариях:

✏ Какую проф.литературу вы бы порекомендовали к прочтению?

Интересно как для начинающих, так и опытных специалистов в области бизнес-/системного анализа.

​​📑 Apache Kafka: основы технологии

Apache Kafka (брокер сообщений) распределенная система обмена сообщениями между серверными приложениями в режиме реального времени.

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

Apache Kafka можно использовать, например, для: связи микросервисов между собой; организации потоков данных; агрегации записей; сбора логов..

Разобраться в том, чем Kafka отличается от популярных систем обмена сообщениями, как хранит данные и обеспечивает гарантию сохранности, а так же, как записываются и читаются данные, поможет статья: Apache Kafka: основы технологии

#kafka | @notes_analyst

​​📑 Курс по документированию API.

(вольный перевод курса Documenting APIs: a guide for technical writers, составленного Томом Джонсоном, техническим писателем Amazon)

На курсе вы разберете API на составные части, узнаете о конечных точках, параметрах, типах данных, аутентификации, curl, JSON, командной строке, консоли разработчика Chrome, JavaScript и прочих деталях, связанных с REST API.

Модули курса:
▪︎ Введение в REST API
▪︎ Используем API как разработчики
▪︎ Документирование конечных точек
▪︎ Спецификация OpenAPI и Swagger
▪︎ Тестирование документации
▪︎ Концептуальные разделы
▪︎ Публикация документации
▪︎ Работа технического писателя
▪︎ Нативные библиотеки API
▪︎ Глоссарий API и источники
▪︎ Документирование кода

#api | @notes_analyst

​​📑 MVP - минимально жизнеспособный продукт.

MVP (Minimum Viable Product) - это самая ранняя версия продукта, которая обладает только необходимыми функциями, достаточными для того, чтобы донести основополагающие ценности до аудитории и проверить их на первых пользователях.

Основная задача MVP - сократить время и усилия на тестирование идеи до начала разработки полноценного продукта. 

MVP позволяет: 
▪︎ проверить гипотезу на основе реальных данных и доказать жизнеспособность идеи; 
▪︎ снизить возможность финансовых убытков при запуске неудачного продукта;
▪︎ уменьшить стоимость разработки за счёт отказа от ненужных функций;
▪︎ выявить неучтённые потребности клиентов; 
▪︎ оптимизировать тестирование продукта и ускорить поиск ошибок; 
▪︎ собрать начальную базу клиентов до полномасштабного запуска; 
▪︎ выйти на рынок и привлечь инвесторов. 

О том, что на самом деле представляет из себя минимально жизнеспособная версия продукта, с чем её не стоит путать и как её создавать, читайте в статье:
"Ещё раз об MVP"

#mvp | @notes_analyst

​​PostgreSQL. Основы языка SQL: учеб. пособие / Е. П. Моргунов; под ред. Е. В. Рогова, П. В. Лузанова
#литература

В пособии рассматриваются следующие темы:

° Введение в базы данных и SQL
° Создание рабочей среды
° Основные операции с таблицами
° Типы данных СУБД PostgreSQL
° Основы языка определения данных
° Запросы
° Изменение данных
° Индексы
° Транзакции
° Повышение производительности

Скачать книгу можно тут

Сегодня рекомендация - полезный тг-канал Belarus: хочу в IT

Советуем Вам полезный тг-канал Belarus: хочу в IT, где Вы cможете найти:

✅ свежие вакансии

✅ стажировки

✅ карьерные рекомендации

✅ качественные курсы

Рекомендуем! 😉

#партнерский_пост

​​📑 Как задавать требования к внешнему качеству ПО в цифрах?

Из множества возможных внешних  атрибутов качества (качества при эксплуатации) стоит выделить наиболее важные, которые встречаются в большинстве проектов:
▪︎ Производительность
▪︎ Масштабируемость
▪︎ Доступность
▪︎ Надёжность
▪︎ Информационная безопасность

Подробнее о том, как формулировать требования к первым 4-м аспектам внешнего качества, читайте в статье: Как задавать требования к качеству ПО в цифрах?, авторы которой так же приводят примеры:
- ситуаций, при которых может потребоваться выявлять атрибуты качества;
- того, как недостаточное внимание к качеству системы может привести к плачевным последствиям.

Читать статью

#атрибутыкачества | @notes_analyst

Шпаргалка по Python для начинающих

Скачать в формате pdf

#python | @notes_analyst

​​📹 Цикл открытых вебинаров по BPMN2

▪︎ Часть 1: BPM, BPMN, BPMS что это за термины и что они значат
▪︎ Часть 2: основы BPMN
▪︎ Часть 3: делаем хорошие схемы
▪︎ Часть 4: остальные символы BPMN и межпроцессное взаимодействие
▪︎ Часть 5: межпроцессное взаимодействие
▪︎ Часть 6: ТЗ на процессное приложение
▪︎ Часть 7: практика создания диаграмм аналитического уровня

Перейти к плейлисту

#bpmn | @notes_analyst

​​📑 Удачный шаблон документации на API, который будут читать

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

Читать статью

#документация | @notes_analyst

Знаете же про шутку такую - нажать на кнопку «Сделать хорошо»? Есть такой целый канал Кнопка хорошо. Автор канала - Анастасия Борисюк - руководитель проектной группы в Актион Диджитал.

Настя пишет про софтскилы, управление людьми, внедрение продуктовых практик и карьеру. Фишка канала - авторские иллюстрации и инфостиль, чтобы читателям было ясно, понятно.

Пара постов, чтобы познакомиться с каналом:
🍓Переговоры о зарплате - что мы делаем не так, и о чем слишком паримся, вместо того, чтобы начать разговор.
🍓Как принимать резкий фидбек - как реагировать, если фидбек подан негативно или заставляет тебя пребывать в унынии.
🍓Что делать, когда через вас «перепрыгивают»? - что делать, когда заказчик или коллега, не понимает твою роль и какие проблемы ты решаешь.
🍓Все, что нужно внедрить в свое резюме - первая часть памятки для резюме, маст-хэв для внедрения на поиск работы зарубежом.