📝 Модели разработки ПО

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

Модели разработки ПО разделяют на классические и гибкие. 

Классические модели делают акцент на последовательности, сроках и конечных требованиях к продукту.
К ним относят:
▪︎Code and Fix  - только пишем код, проверяем и устраняем ошибки;
 ▪︎Waterfall /каскадная модель - последовательный переход от одного этапа разработки на другой без пропусков и возвращений на предыдущие стадии.
 ▪︎V-Model - упор на тестирование в ходе разработки.Тесты проводятся параллельно с самим процессом создания продукта. 
▪︎ Инкрементная модель - разработка по частям. Проект делится на составные компоненты, команда по очереди готовит каждый из них, затем происходит финальная сборка;
▪︎ Спиральная модель представляет повторяющуюся последовательность циклов разработки с непрерывным контролем рисков.   
▪︎ Итеративная модель - сначала делается базовая модель продукта, затем следуют итерации по ее усовершенствованию;
▪︎ RAD-Model (скоростная разработка продукта) - все этапы создания продукта делятся не несколько отдельных блоков, с каждым из которых работает отдельная команда разработчиков. 

Гибкая модель разработки - Agile model, представляет итеративный подход, позволяет вносить изменения на каждом этапе проекта, может быть не ограничена во времени. 

Agile модель имеет множество вариаций и фреймворков, среди которых выделяют:
▪︎ Scrum - предписывает командам разбивать работу на цели, которые необходимо выполнить в рамках ограниченных по времени итераций, называемых спринтами 
▪︎ Kanban - предполагает обсуждение производительности в режиме реального времени и полную прозрачность рабочих процессов. Рабочие задачи визуально представлены на доске Kanban, что позволяет участникам команды видеть состояние каждой задачи в любой момент времени. 
▪︎ Экстремальное программирование (XP) - XP сосредоточена на упрощении процесса разработки, минимизации документации и максимизации обратной связи от заказчиков.
▪︎ Lean - это набор методик, с помощью которых удается добиться снижения потерь и увеличения ценности продукта.

Подробнее о наиболее популярных вариациях Agile модели читайте в следующих постах

#теория | @notes_analyst

📑 Требования безопасности: пособие для аналитика

Автор: Александра, ведущий системный аналитик отдела криптографии ИнфоТеКС.

В данной статье Александра делится рабочими подходами из общепринятой в их компании практики, которые помогут справиться с требованиями безопасности и ускорить освоение этой непростой темы. 

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

#статья | @notes_analyst

📑 Программа самоподготовки начинающего бизнес-аналитика от Systems Education

План программы

0. Введение в профессию
1. Погружение в бизнес: анализ и исследования
2. Scope проекта, бизнес-потребности и требования, анализ причин и последствий
3. Работа со стейкхолдерами
4. Моделирование бизнес-процессов
5. Пользовательские требования в форме User Story
6. Концептуальное моделирование предметной области
7. Поиск решения, сравнение альтернатив
8. Функционально-стоимостный анализ и имитационное моделирование
9. Анализ рисков
10. Финансовый анализ

Перейти к материалам

#материалы | @notes_analyst

​​Клиент-серверная архитектура. SA для самых маленьких

"Клиент-серверная архитектура — это модель взаимодействия в компьютерной сети, где задачи распределены между двумя основными компонентами: клиентами и серверами."

Содержание статьи:
• Двухуровневая архитектура
• Трехуровневая архитектура
• Плюсы и минусы клиент-серверной архитектуры
• Распределение трафика
• Толстый и тонкий клиент
• Асинхронные и синхронные вызовы

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

#статья | @notes_analyst

📝 ​​Agile-подходы гибкой разработки ПО: Scrum и Kanban.

Суть  Agile описана в Agile-манифесте, в котором на первое место выходят: 
▫️взаимодействие,
▫️работающий продукт,
▫️сотрудничество с заказчиком
▫️готовность к изменениям.
Подробнее:"Ценности и принципы Agile-манифеста"

К отдельным Аgile-подходам относятся Scrum и Kanban. 
Данные подходы гибкой разработки ориентированы на итеративный и инкрементальный процесс программирования, в котором:
🔹 разработка ПО разбивается на короткие циклы - итерации (в Scrum - спринты);
🔹формируется автономная и самоорганизующаяся команда;
🔹клиенты или представляющий их владелец продукта участвуют на всех стадиях проекта;
🔹требования могут документироваться менее подробно, чем в традиционных проектах;
🔹формируется Резерв  (backlog) проекта, содержащий список задач, которые должна выполнить команда;
🔹каждая задача должна быть актуальна (разрешается добавлять/удалять задачи), иметь вес (время, которое необходимо на её реализацию) и приоритет (может пересматриваться в ходе работы);
🔹для визуализации  данных подходов используют доски: физические или электронные, которые позволяют сделать рабочий процесс открытым и понятным для всех специалистов.

📌 Особенности и принципы Scrum:
▪️︎ над каждым проектом работает универсальная команда специалистов;
▪️︎ выделяют спец.роли: Владелец продукта и Scrum-мастер;
▪️︎ время работы делят на Спринты - одинаковые по длительности отрезки времени (напр.  2 недели);
▪️︎ перед спринтом формируются задачи на данный спринт, в конце – обсуждаются и презентуются  результаты: выполненные задачи заливаются на продакшн, а невыполненные — переносятся в другой спринт;
▪️︎ число задач в работе ограничивается их общим весом;
▪️︎ приоритеты задач расставляет Владелец продукта;
▪️︎ нельзя добавлять задачи в текущий спринт (новая важная и срочная задача -  только со следующего спринта);
▪️︎ основная цель - закончить спринт;
▪️︎ проведение ежедневных встреч для оценки результатов проделанной работы - основа процесса разработки.

📌Особенности и принципы Kanban:
▪️︎ над задачей может работать несколько узкопрофильных команд (дизайнеры, аналитики, разработчики…);
▪️︎ внутри команды нет выделенных ролей;
▪️︎ проект делят на итерации, длина которых может различаться;
▪️ рабочие задачи располагаются на доске, поделенной на колонки, каждая из которых отражает текущее состояние работ (стадии) - например: «Планируется», «Разрабатывается», «Тестируется», «Завершено»; 
▪️︎ каждая задача представляется в виде отдельной карточки;
▪️︎ основная цель - закончить задачу, т.е. пройти все стадии выполнения (когда задача завершает определённый этап, карточку с её описанием переносят в соответствующую колонку);
▪️︎ над задачей трудятся столько времени, сколько это необходимо до её завершения или утраты актуальности и отмены;
▪️︎ главный показатель эффективности -
среднее время прохождения задачи по доске;
▪️︎ приоритеты задач расставляет команда;
▪️︎ добавление новых задач - в любое время;
▪️︎ проводить ежедневные встречи не обязательно.

---------
Подробнее о принципах работы по Scrum  и Kanban можно прочитать в статьях:
📄 Scrum
📄 Kanban: принципы и возможности в управлении проектами
📄 Scrum vs Kanban: сходства и различия двух самых популярных Agile-подходов
📄 Сравнение Scrum и Kanban. Какая методика Agile подойдет вам?

#теория  | @notes_analyst

​​📑 ИБ для аналитика: требования и проектные решения

"Требования к обеспечению информационной безопасности – один из важнейших разделов ТЗ на ИС/АС. Рассмотрим основные концепции ИБ, которые надо знать аналитику при разработке требований к системе, а также разберемся, в каких проектных решениях могут реализоваться эти требования."

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

#статья | @notes_analyst

​​📑 Куда и как развиваться системному аналитику, если «потолок» уже близко

Автор: Алексей Лобзов, руководитель направления развития компетенции системного анализа в Альфа-Банке.

▪︎ Вариант №1: Лидер компетенции
Сценарий для тех, кому нравится помогать коллегам.

▪︎ Вариант №2. Solution архитектор
Сценарий карьеры для тех, кому интересны технологии.

▪︎ Вариант №3. Product Owner
Путь дипломатии.

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

#статья | @notes_analyst

​​Основы PostgreSQL для начинающих: от установки до первых запросов

Научитесь устанавливать и работать с PostgreSQL.
В этом руководстве рассматриваются основные команды, вы создадите первую базу данных и выполните простые SQL-запросы

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

​​📑 Документация по ГОСТ – не только ТЗ

"Когда при внедрении систем 1С всплывает слово «ГОСТ» – практически всегда речь идёт о документе «Техническое задание». И у большинства внедренцев падает настроение, как только им говорят, что надо «написать ТЗ по ГОСТу». Но опытные кулинары знают, как готовить это блюдо так, чтобы оно оставило после себя приятное послевкусие, а не горькое разочарование. О собственных рецептах приготовления документации по ГОСТу пойдет речь в статье."

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

#статья | @notes_analyst

📑 Реквием по SCRUM: всё равно уже хайп прошёл

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

​​📑 Распределенные транзакции для самых маленьких

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

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

#статья | @notes_analyst

​​📑 Сетевые протоколы и модели OSI: как всё устроено

"Как всё на самом деле работает в этом вашем TCP/IP и зачем ему столько уровней. Разбираем на простых примерах."

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

#статья | @notes_analyst

​​📑 OKR vs KPI: чем отличаются эти подходы к управлению и зачем они бизнес-аналитику

Автор Анна Вичугова
"Система управления на базе KPI – далеко не единственный инструмент современного менеджмента, который должен знать бизнес-аналитик. Сегодня на практических примерах разберем разницу между OKR и KPI, рассмотрим за что Objectives and Key Results так любят в продуктовой разработке и Agile-проектах, а также почему не стоит стоить привязывать OKR к ФОТ, в отличие от Key Performance Indicators."

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

#статья | @notes_analyst

📑 Cистемный аналитик с ЗП 400+. Найти за 30 дней

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

​​📑 Анализ, декомпозиция и оценка задач: от теории к практике

Автор - Максим, более 6 лет работает Frontend-разработчиком в IT-проектах и продуктах:

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

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

#статья | @notes_analyst

​​📑 Оценка задач в сторипоинтах: мой путь от абстрактного к конкретному

Автор: Артём Коньков, тимлид команды продуктовой разработки в Купере:
"У меня в команде шесть разработчиков, по два на каждый стек: мобилка, фронтенд, бекенд и два QA. В статье расскажу о том, как, став тимлидом в уже почти сложившейся команде, менял систему оценки задач и переводил абстрактные сторипоинты в конкретные."

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

#статья | @notes_analyst

📑 Как навести порядок в хаосе из требовании‌ и документации?

Автор: Егор Марюшко, архитектор решений в «Ростелеком Информационные Технологии» и основатель образовательного центра STENET school.

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

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

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

#статья | @notes_analyst

📑 Документации быть

"Документация программного обеспечения (ПО) — это совокупность всех письменных материалов, которые сопровождают программное обеспечение в процессе его разработки, тестирования, эксплуатации и сопровождения. Документация включает в себя требования, технические спецификации, руководства пользователя, инструкции по установке и эксплуатации, а также другие документы, необходимые для понимания и работы с программным обеспечением."

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

#статья | @notes_analyst

📑 Стандарты и шаблоны для ТЗ на разработку ПО

Основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

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

#статья | @notes_analyst