Dumowka

Гибкие методологии разработки:

Для начала определим кто такой менеджер?

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

С чем это связано?

Менеджер должен уметь правильно ставить задачи команде, следить за результатами поставками, он также должен знать основы Agile, Scrum, Kanban. Чтобы иметь представления как работать с командой.

Что такое Agile?

Agile (agile software development, от англ. agile – проворный, шустрый, сообразительный) – это семейство «гибких» подходов к разработке ПО.

А теперь простыми словами, некоторые считают что Agile это методология, но любой опытный Product Manager скажет Вам что Agile это способ мышления он не включает практики, а определяет принципы и ценности это некая философия, которыми руководствуется команда.

Подход к проектам по разработке ПО

• Гибкая методология разработки,

• Постоянное формирование требований на основе целевого видения продукта

• Короткие горизонты планирования (1-2 мес.)

• Реализация внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля

• Каждый участник процесса «конвейерной сборки» вовлекается в процесс переосмысления своих задач и общего дела; каждый может вносить изменения и даже остановить разработку

Agile Manifesto - основной документ, содержащий описание ценностей и принципов гибкой

1. Люди и взаимодействие важнее процессов и инструментов;

2. Работающий продукт важнее исчерпывающей документации;

3. Сотрудничество с заказчиком важнее согласования условий контракта;

4. Готовность к изменениям важнее следования первоначальному плану.

Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.

http://agilemanifesto.org/iso/ru/principles.html

Особенность реализации проектов

• Фиксированы срок и стоимость проекта.

• Лучший контроль качества – контроль результата каждой итерации

• Отсутствует конечный скоуп проекта - нет четко описанного результата

Что такое Scrum?

Scrum (в переводе с англ: схватка, потасовка, толпа) — методология управления проектами, применяется при необходимости гибкой разработки; методология делает акцент на качественном контроле процесса разработки

Scrum – самая популярная из гибких методологий разработки

Позволяет решать задачи

• меньшими силами

• в сжатые сроки

• с минимальными затратами.

РЕЗУЛЬТАТ КАЖДЫЕ 2 НЕДЕЛИ!

Процесс создания нового программного продукта ведется посредством создания спринтов - коротких рабочих сессий, как правило, продолжительностью 1–2 недели.

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт.

Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.

Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт.

ОЧЕНЬ ВАЖНА РОЛЬ ВЛАДЕЛЬЦА ПРОДУКТА, который постоянно участвует в проекте, понимает, что должно быть достигнуто, оценивает все риски и выгоды.

По методологии Scrum, оптимальной является группа из 5-9 ЧЕЛОВЕК.

Как максимизировать и выравнивать процессы?

На самом деле здесь уже все продумано, и придумать велосипед не нужно!

Используется всего четыре артефакта:

• Product Backlog

• Sprint Backlog

• Sprint Goal

• Sprint Burndown Chart.

Sprint backlog

Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на доске.

Sprint Goal

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

Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения задачи. Чтобы решения команды были осознанными, Product Owner определяет цель спринта.

Sprint Burndown Chart

• диаграмма сгорания

• в качестве “сгорающих” элементов выступают человеко-часы или идеальные единицы (Story Points).

• диаграмма обновляется каждый раз, когда завершается какая-либо задача.

Ритуалы

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

Ритуалы в скрам это:

• Sprint Planning Meeting

• Daily Meeting

• Sprint Review

• Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

• выполняется всей командой перед началом спринта

• команда выбирает требования из Product Backlog и формирует Sprint Backlog

• если требуется учесть взаимосвязи между операциями, то это делается здесь

• команда декомпозирует требования на задачи (tasks)

• каждая задача проходит оценку в трудозатратах или универсальных единицах

• во время встречи Product Owner отвечает на вопросы команды.

Daily Meeting (ежедневная встреча команды).

Основные принципы:

• проходит ежедневно и только в одно и то же время;

• встречи не более 15 минут;

• чтобы успеть каждый должен ответить всего на 3 вопроса: что я сделал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

Sprint Review – сдача спринта Product Owner

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

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

Структура встречи:

• команда зачитывает требования из Sprint Backlog

• по каждому критерию приемки происходит демонстрация полученных результатов

• каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже

• каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

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

• какие проблемы мешают команде выполнять взятые на себя обязательства?

• как улучшить взаимодействие с Product Owner’ом?

• какие ошибки совершает команда и почему.

Scrum Poker (Planning Poker):

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

Алгоритм таков: всем участникам дается набор карт и задачи, которые будут реализованы. Каждый из участников дает свою оценку. Берется самое минимальное и максимальное значение. Затем каждый участник, поставивший такую оценку, должен объяснить, почему именно так. После обсуждения начинается вторая фаза проставления оценок. Таких фаз проводится 3. Если на последней фазе расхождения остаются, то берется максимальная оценка.

Agile. Kanban:

Kanban, это система управления бережливыми производством (перевод с японского: «сигнал»/«карточка»), которая использует информационные карточки для передачи заказа на всех этапах изготовления. Простыми словами, мы отслеживаем весь путь продукта, от идеи до выхода “на полку магазина”.

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

Kanban используют для реализации проектов.

Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Если вчера разработчик залил выполненную задачу, а сегодня получили данные с "передовой" и узнали, что вот эта штука не работает так, как было задумано, то дают новые требования. Дополненные новые задачи поднимаются вверх и программист берет эту задачу «сверху», выполняет ее и, к вечеру все работает как надо. Все счастливы и эффективны как никогда.

В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи.

Карточки, на которых указаны информация о сроках выполнения, описание или номер процесса и имя исполнителя, прикрепляются , к доске с расчерченными колонками:

Бэклог — задачи, которые надо выполнить

Задачи, которые в данный момент разрабатываются

Задачи, которые выполнены, но еще не переданные тестировщикам

Задачи, готовы к передаче отделу тестирования

Задачи, которые проходят проверку проект-менеджером (ПМ)

Выполненные задачи

Основной инструмент отображения статуса по задачам. Главный принцип: мы видим на каком этапе производственного процесса находится та или иная задача. Плюс, отслеживается время на всех участках, то есть всегда можно обнаружить “узкие места” в системе и поработать с ними.

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

4 базовых принципа «Kanban»

1) Отталкивайтесь от того, что у вас есть сейчас

2) Стремиться к поэтапным, постоянным и эволюционным изменениям

3) Уважайте поточные процессы и роли

4) Поддерживать лидерство на всех уровнях

Почему важно визуализировать?

Kanban — это в первую очередь визуализация

- Визуальное отображение задач. Все задачи должны быть представлены в виде карточек и отражены на доске.

- Фокус на невыполненных задачах

- Постоянное улучшение

- Уделяйте внимание мелочам

Kanban на первом месте задачи. команда работает над задачей с самого начала и до завершения

Kanban имеет и недостатки:

Система плохо работает с командами численностью более 5 человек

Он не предназначен для долгосрочного планирования.

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.

Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей

Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile

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

Клиент-серверная архитектура.
Клиент-серверная архитектура - это такая архитектура, в которой сетевая нагрузка распределяется между поставщиками услуг (серверы) и заказчиками услуг (клиенты).

Плюсы:

• Отсутствует дублирование кода программы сервера программами клиента.

• Так как все вычисления происходят на сервере, то требования к мощностям клиента снижаются.

• Все данные хранятся на сервере и это является более безопасным вариантом, чем хранения данных на машинах клиентов.

Минусы:

• Если перестанет работать сервер, то вся вычислительная сеть тоже не будет работать.

Виды архитектуры:

• Двухуровневая - имеется клиент и сервер.

• Трехуровневая - имеется клиент, сервер и база данных.

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

Виды клиентов:

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

• Толстый клиент - это приложение, которое обеспечивает расширенную функциональность независимо от центрального сервера. Часто в таком случае сервер является каким-то хранилищем данных, а вся работа по обработке и предоставлению этих данных переносится на машину клиента (пример - 1с бухгалтерия, онлайн игры).

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

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

Веб - сервис - это прикладной программный интерфейс (API), который работает на сервере и предоставляет клиенту данные через HTTP через стандартизированную систему обмена сообщениями.

ИЛИ

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

• SOAP (Simple Object Access Protocol)

• REST (Representational State Transfer)

SOAP - это протокол обмена сообщениями, который позволяет распределённым элементам приложения обмениваться данными. SOAP может передаваться по множеству стандартных протоколов, он гибкий и независимый. Это позволяет разработчикам писать API на разных языках, а ещё добавлять различные функции и функциональные возможности.

Информационный набор Extensible Markup Language (XML) используется для SOAP в качестве формата сообщений, а передача и их согласование происходит с помощью протоколов прикладного уровня – таких, как HTTP.

XSD (XML Schema Definition) - описание структуру XML документа и типы данных, которые там могут храниться.

WSDL (Web Services Description Language) - это файл, написанный на языке WSDL, который описывает сообщения, заголовки, события, которые свойственны для веб-сервиса. Он является обязательным для SOAP.

Правила написания XML:

• Только один корневой элемент

• Все элементы должны иметь закрывающие теги

• Название регистрозависимые

• Элементы не должны пересекаться

• Все значение атрибутов в кавычках

• <,>,& нельзя использовать в текстовых блоках

• Нужно использовать:

• Объявления XML - первая строка

REST - это аббревиатура от Representational State Transfer («передача состояния представления»). Это согласованный набор архитектурных принципов для создания более масштабируемой и гибкой сети. Эти принципы отвечают на ряд вопросов. Какие у системы компоненты? Как они должны взаимодействовать друг с другом? Как быть уверенным, что можно заменять различные части системы в любое время? Как система может масштабироваться для обслуживания миллиардов пользователей?

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

RESTful - это любая сеть, которая отвечает принципам (ограничениям) REST.

Большинство RESTful-реализаций используют такие стандарты, как HTTP, URL, JSON и, реже, XML.

JSON (JavaScript Object Notation) - текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования. Состоит он из неупорядоченного множества пар «ключ:значение».

Отличия между REST и SOAP:

• REST поддерживает различные форматы

• REST работает только по протоколам HTTP и HTTPS

• SOAP во время чтения не может быть помещен в кэш

• REST - архитектурный стиль, у которого нет огромного количества правил, которым он должен подчиняться, а SOAP - протокол, который сильно ограничен правилами, которые к нему предъявляются

• За REST скорость, простота, расширяемость, поддержка многих форматом, отсутствие жесткой привязанности к правилам, а в случае SOAP - больше возможностей по безопасности и больше возможностей проводить тестирование качественно из-за наличия WSDL, где будут прописаны образцы запросов (из-за этого нужно реже обращаться к разработчикам)

HTTP (HyperText Transfer Protocol) Протокол.

Протокол - набор правил передачи информации.

HTTP — это гипертекстовый протокол передачи данных прикладного уровня в сетевой модели OSI. Главная особенность HTTP — представление всех данных в нём в виде простого текста. Через HTTP разные узлы в сети общаются между собой. Модель клиент-серверного взаимодействия классическая: клиент посылает запрос серверу, сервер обрабатывает запрос и возвращает ответ клиенту. Полученный ответ клиент обрабатывает и решает: прекратить взаимодействие или продолжить отправлять запросы.

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

HTTPS (HTTP Secure) — это надстройка над протоколом HTTP, которая поддерживает шифрование посредством криптографических протоколов SSL и TLS. Они шифруют отправляемые данные на клиенте и дешифруют их на сервере. Это защищает данные от чтения злоумышленниками, даже если им удастся их перехватить.

Сетевые модели:

На уровне сетевых интерфейсов передаются какие-то физические импульсы (например - оптоволокно).

На сетевом уровне происходит передача физических сигналов в виде битов или байтов.

На транспортном уровне происходят транспортные взаимодействия.

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

• UDP протокол - информация передается беспрерывным потоком без проверки того, дошли данные до клиента или нет (применяется в онлайн играх).

На прикладном уровне взаимодействие происходит посредством протоколов.

Составные части протокола HTTP:

• Основная часть (payload)

• Служебная информация (headers - заголовки)

HTTP - request:

HTTP - response:

Методы HTTP - запроса:

GET - запрашивает представление ресурса. Запросы с использованием этого метода могут только извлекать данные.

HEAD - запрашивает ресурс так же, как и метод GET, но без тела ответа.

POST - используется для отправки сущностей к определённому ресурсу. Часто вызывает изменение состояния или какие-то побочные эффекты на сервере.

PUT - заменяет все текущие представления ресурса данными запроса.

DELETE - удаляет указанный ресурс.

CONNECT - устанавливает "туннель" к серверу, определённому по ресурсу.

OPTIONS - используется для описания параметров соединения с ресурсом.

TRACE - выполняет вызов возвращаемого тестового сообщения с ресурса.

PATCH - используется для частичного изменения ресурса.

Коды ошибок:

Неплохая статья по HTTP - https://habr.com/ru/companies/avito/articles/710660/

Различия HTTP 1.0 от HTTP 2.0:

https://seob.ru/blog/protocol-http-2
https://vc.ru/seo/442112-http-2-chto-eto-i-zachem-on-vam

Web Glossary.

IP-адрес (от англ. Internet Protocol) — уникальный числовой идентификатор устройства в компьютерной сети, работающий по протоколу TCP/IP.

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

URL - это URI, который, помимо идентификации ресурса, предоставляет ещё и информацию о местонахождении этого ресурса.

URN — это URI, который только идентифицирует ресурс в определённом пространстве имён (и, соответственно, в определённом контексте), но не указывает его местонахождение.

Маска подсети:

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

Допустим у вас есть IP-адрес, записанный в двоичном виде:

Красным цветом отмечены биты, ответственные за номер сети, зеленым – за номер хоста. Да, так тоже можно. Тут нет жесткой привязки к байтам.

Маской подсети будет называться такое число, где битам подсети будут соответствовать единички, а битам хоста – нули. Пример маски подсети для предыдущего адреса:

Все биты подсети равны 1 (красный), все биты хоста равны 0 (зеленый).

Пример выделения номера сети и идентификатора хоста в IP-адресе:

Важно: Всегда зарезервировано два ip-адреса (самый первый - адрес подсети, самый последний - широковещательный адрес (Broadcast Address) (широковещательный адрес - это такой IP адрес, который позволяет передать сетевые данные одновременно на все хосты заданной подсети, вместо передачи на конкретный хост).

MAC - адрес - это физический адрес устройства. Он прописывается при производстве сетевой карты.

DNS (Domain Name System) - это глобальное распределенное хранилище ключей и значений. Она необходима, в первую очередь, для соотнесения IP-адресов устройств в сети и более удобных для человеческого восприятия символьных имен.

Кэш (cash) - данные, которые загружаются с ПК при повторном посещении сайта для ускорения загрузки сайта (например - различные элементы дизайна сайта, изображения, музыка и т.п.).

Куки (cookies) - это небольшие текстовые файлы, сгенерированные сайтами. В них записана информация о посещении сайта. Эти файлы хранятся на компьютере. Cookie нужны, чтобы идентифицировать пользователя. Когда вы вернётесь на сайт, он узнает вас и автоматически подстроится. Формы регистрации будут заполнены, языковые и региональные настройки заданы. Если на сайте вы выбирали товары, то новые будут предложены на основе ваших предпочтений.

• B2B (business-to-business) - одна компания продает продукт другой компании.

• B2C (business-to-customer) - компания продает продукт конечному потребителю или частному лицу.

• B2G (business-to-government) - компания продает продукт гос. учреждениями.

• C2C (customer-to-customer) - частное лицо продает продукт частному лицу (например, авито).

  Тестирование - поиск несоответствия между фактическим и ожидаемым результатом.

  SDLC (Software Development Life Cycle) - жизненный цикл разработки.

  Этапы:

• Анализ требований - отвечает на вопрос «Какие проблемы требуют решений?»

• Планирование - отвечает на вопрос «Что мы хотим сделать?»

• Проектирование и дизайн - отвечает на вопрос «Как мы добьемся наших целей?»

• Разработка ПО -  регулирует процесс создания продукта.

• Тестирование -  регулирует обеспечение качественной работы продукта.

• Развертывание -  регулирует использование финального продукта.

Также еще можно выделить два этапа:

• Инициация (идея) - у заказчика появилась идея и он ищет компанию, которая будет это реализовывать.

• Вывод из эксплуатации - бизнес решает прекратить поддержку продукта.

Для чего нужно тестирование:

• Обеспечить продукту надлежащее качество.

• Уменьшить расходы за создание продукта (например, если не ранней стадии не найти баг, то в дальнейшем стоимость его исправления обойдется значительно дороже)

Принципы тестирования:

• Тестирование показывает наличие дефектов (нельзя найти все баги).

• Исчерпывающее тестирование невозможно.

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

• Скопление дефектов (в небольшом количестве модулей сокрыто большое количество дефектов)

• Парадокс пестицида (если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты).

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

• Заблуждение об отсутствии ошибок.

Жизненный цикл тестирования:

Цели тестирования:

• Оценка рабочих продуктов (требования, пользовательские истории, проектирование и код).

• Все ли указанные требования выполнены.

• Завершен ли объект тестирования и работает, как ожидают пользователи и заинтересованные лица.

• Создание уверенности в уровне качества объекта тестирования.

• Предотвращение и обнаружение отказов и дефектов.

• Предоставление заинтересованным лицам достаточной информации, позволяющей им принять обоснованные решения.

• Снижение уровня риска ненадлежащего качества программного обеспечения.

• Соблюдение договорных, правовых или нормативных требований, или стандартов и/или проверка соответствия объекта тестирования им.

Отладка (debugging) - это деятельность разработки для нахождения, анализа и исправления таких дефектов. Последующее подтверждающее тестирование проверяет, устранены ли исправленные дефекты.

Контроль качества (quality control) - набор действий, предназначенных для оценивания качества компонента или системы.

Обеспечение качества (quality assurance) - активности, направленные на обеспечение уверенности в том, что требования к качеству будут выполнены.

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

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

(QC работает над продуктом, а QA работает над процессами)

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

Верификация (verification) - доказанное объективными результатами исследования подтверждение того, что определенные требования были выполнены. (Делаем ли мы продукт правильно?)

Валидация (validation) - доказанное объективными результатами исследования подтверждение того, что требования для ожидаемого конкретного исследования приложения были выполнены. (Делаем ли мы правильный продукт?)

(Валидация сконцентрирована на требовании (нужды заказчика), а валидация - на ожидании пользователя (нужды пользователя)).

Получилось конечно прям мало, так что нужно будет на следующей неделе прям хорошенечко поработать. Спасибо что дочитали. Если есть какие-то советы, пожелания и т.п., то жду вас :)

6) Java. Тут у меня какие-то знания да есть, так что тут я буду делать акцент на коллекциях, stream api, ООП. Также нужно изучить рефлексию. Планируемый источник информации - статьи и ютюб.

7) CI/CD. Тут у меня тоже очень не очень знания. Планируемый источник информации - статьи и ютюб.

8) Docker. Аналогичная ситуация, что и с CI/CD. Планируемый источник информации - статьи и ютюб.

9) SQL. У меня есть знания для написания простеньких запросов, хочу расширить свои знания по нему. Планируемый источник информации - статьи и ютюб.

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

Спасибо что прочитали ^_^