В информационных системах мы работаем с данными. Добавляя или меняя очередную функциональность, я всегда прокручиваю в голове комбинацию из четырех букв — CRUD.

Что такое CRUD-модель, чем она полезна, как ее применять при анализе требований и проектировании систем? Ответы на эти вопросы я разбираю и показываю на примере ✍️

Читать

Хочу познакомить Вас с роботом-помощником GetAnalyst 🤖🦭

Он только-только запустился 🚀 Его цель - знакомить вас с миром алитики и развивать профессиональные навыки.

Он уже знает о разработке требований, проектировании БД, историю профессии аналитиков и готов с вами поделиться 😉

Это начало, он еще пополнит базу знаний!

Давайте дружить 🤖

Confluence - база знаний

Инструмент для ведения базы знаний команды разработки:
+ проектная документация,
+ требования,
+ ПМИ,
+ сценарии тестирования,
+ отчеты.

Все знания коллекционаинруем в нем. Документы версионируются. Всегда можно узнать когда были внесены изменения в документацию и, соответственно, в функциональность системы.

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

Интегрируется с кучей сервисов. Есть классный опыт автоматического создания Confluence-страниц на основе PostgreSQL базы данных.

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

✔️информация оптимизируется в одном месте (отчёты, задачи и т. д.)
✔️помогает вести протоколы встреч, решений и задач; ✔️позволяет создавать задачи в Jira и отслеживать их исполнение
✔️можно создавать справочную информацию для бизнес-заказчиков
✔️позволяет контролировать изменения в версиях документов
😬сложно следить за изменением форматирования документов (гигансткие отчеты при сравнении версий документов)
😬 приходит много отчётов на почту, но можно настроить фильтры
😬 кто-то ругается на неудобную навигацию, но тоже решаемо за счет крутой оргнизации структуры
😬 подвисает при входе и выходе в режим редактирования, в отличии от notion

Разработчик ПО Confluence, как и у Jira - Attlassian. Условия использования такие же. Регистрация под VPN, есть бесплатная версия, можно платно.

Notion - хранение требований и документации, управления задачами

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

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

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

✔️ нет ничего лишнего: всё просто и понятно
✔️ всё файлы в одном месте, не нужно скачивать дополнительные приложения
✔️ интегрируется другими сервисами: Google Docs, GitHub, Figma, Miro, Invision
❌ нельзя одновременно работать над одним документом в реальном времени
❌ нет русскоязычной версии

Есть бесплатная и платная версии.

Ссылка: notion.so/

Я использую Notion для небольших проектов. Он очень популярен в образовательных бизнесах. Удобно пистаь в нем регламенты, инструкции, планы. В больших проектах разработки больше доверяю Confluence - он удобнее.

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

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

Важно помнить, что разработка требований – это постоянный процесс, который может претерпевать изменения в течение всего проекта

Требования – это целевое видение того, что должна получить команда разработки в результате их работы.

При разработке требований к приложениям выделяют следующий список характеристик, которые необходимо описать:
• Функциональность
• Производительность
• Внешний вид (UI)
• Компоненты
• Безопасность
• API-интерфейсы для интеграций
• Удобство (UX)

Для каждой характеристики требуется понять, что именно должно быть реализовано.
Например, у UI-дизайна могут быть:
• Сведения о цветовой схеме, названиях элементов и прочих свойствах
• Примеры для того, чтобы удостовериться, что все они должны быть удовлетворяющими
• Инструменты, которые разработчику помогут сделать дизайн
• Дополнительные связанные с UI-дизайном функции, например, ответственность за адаптивность приложения к различным гаджетам.

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

Разработки требований – это важный этап разработки программного обеспечения. За него на проекте отвечает Системный аналитик.

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

На практике роль системного аналитика может выглядеть так:
▫️Заказчик желает разработать приложение для учета финансов.
▫️Системный аналитик проводит интервью с заказчиком, чтобы уточнить его потребности и ожидания.
▫️Затем, он формулирует требования к приложению, учитывая все пожелания заказчика и технические возможности.
▫️После этого, он предоставляет требования команде разработки, которая использует их для создания приложения.

Если вы заинтересованы в разработке требований к программному обеспечению и хотите улучшить свои навыки в этой области, то курс "Системный аналитик: с нуля до опыта работы на проекте" идеально подойдет для вас!

Я создала комплексный курс, который включает в себя лекции, практические занятия и практику на воркшопах, где я даю индивидуальную обратную связь!

Весь курс мы будем работать над созданием одного проекта! Вы научитесь аналитике, участвуя в стартап-проекте:
✔️ соберете требования, сформулируете требования к программному обеспечению,
✔️ освоите методики, как учитывать все пожелания заказчиков и технические возможности приложений,
✔️ как работать с командой разработчиков,
✔️ определять и анализировать технические риски 💻

Не пропустите шанс улучшить свои навыки и стать экспертом в области системного анализа!

Записывайтесь на курс уже сегодня и начинайте свой путь к успеху 🚀 А если вам нужна помощь с выбором обучения, то вы всегда можете записаться к нам на бесплатную диагностическую консультацию 🙂

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

Какими достижениями делятся ребята:

✔️ Появилась возможность работать в новой, интересной и развивающейся сфере
✔️ Есть те, кому удаленная профессия помогла переехать в другой город/страну
✔️ Получили повышение на работе или перешли на другую должность
✔️ Повысили доход
✔️ Получили должность в крупной компании

В такие моменты нередко вспоминаю ролик, который сейчас часто встречаю в соцсетях. Там главная фраза:
«Кто вообще придумал поговорку «Не умеешь — не берись?». «Не умеешь — научись!»

Невозможно не согласиться. Всегда придерживаюсь того же принципа 😉

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

💻 Производительность — это мера того, насколько эффективно приложение использует ресурсы системы для выполнения действий, которые вы создали для этого.

Аналитик, понимая бизнес-метрики и бизнес-процессы, может влиять на требования к:
▫️мощности оборудования,
▫️структуре кода,
▫️эффективности использования памяти,
▫️скорости получения данных из базы
и т.д.

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

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

Нефункциональные требования - это требования, которые не касаются непосредственно функциональности приложения, но влияют на его удобство использования.

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

Поэтому, работая над требованиями к приложениям, думаем про:
💥 Надежность - способность приложения работать бесперебойно на протяжении определенного времени, без ошибок
💥 Безопасность - способность защищать данные и систему от внешних угроз, доступность персональных данных пользователей, авторизация
💥 Удобство использования - эргономика, интуитивно понятный интерфейс
💥 Производительность - скорость и эффективность работы приложения
💥 Масштабируемость - способность приложения адаптироваться к росту нагрузки и изменению требований
💥 Совместимость - способность приложения работать с разными системами и устройствами

Сохраняйте в заметки, чтобы не потерять, и использовать при постановке очередной задачи или написании ТЗ!

А еще есть такое понятие у тестировщиков, как нефункциональное тестирование. Это проверка соответствия НФТ (нефункциональным требованиям) для приложений.

Примеры тестовых сценариев для НФТ:
▫️Производительность: Время загрузки приложения не должно превышать 3 секунд при одновременном доступе к нему до 1000 пользователей.
▫️Совместимость: Программное обеспечение должно быть установлено на всех версиях Windows и Mac.
▫️Доступность: Все веб-изображения должны иметь теги alt.

А это наиболее распространенные типы нефункционального тестирования:
✔️ Тестирование производительности
✔️ Нагрузочное тестирование
✔️ Тестирование отказоустойчивости
✔️ Тестирование совместимости
✔️ Юзабилити-тестирование
✔️ Стресс-тестирование
✔️ Тестирование ремонтопригодности
✔️ Тестирование масштабируемости
✔️ Объемное тестирование
✔️ Тестирование безопасности
✔️ Тестирование аварийного восстановления
✔️ Тестирование переносимости
✔️ Тестирование эффективности
✔️ Проверка надежности
✔️ Тест на выносливость
✔️ Тестирование документации
✔️ Тестирование восстановления
✔️ Тестирование интернационализации
✔️ Тестирование локализации

Пишете требования? Давайте подумаем заранее, что тестировщики или пользователи могут нам подкинуть 😉

Работе с разными видами требований я учу на программе:
🎓 Системный аналитик: с нуля до опыта работы на проекте
которая стартовала в GetAnalyst!

Аналитики, которые уже прошли этот курс, могут с легкостью выявить любые нефункциональные требования и точно знают, когда на них стоит обратить внимание 🧐

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

Будем вести проект с нуля на протяжении трех месяцев! Сбор и анализ требований, бизнес-требования и User Story, Функциональные требования и Use Cases, Нефункциональные требования, работа с ТЗ, ГОСТы и их применение.... Все, и даже больше, будем осваивать на практике!

Лучшая инвестиция - саморазвитие! Спасибо, что вы выбираете пройти этот путь со мной 🚀

Привет-привет!

После вчерашних постов в чате увидела хороший вопрос:
Могли бы вы привести привер, как эти теоритеческие знания о НФТ можно применить на практике при постановке задачи на разработку?
Тереотический список НФТ плюс минус статичен. Но как применить на практике - вот тут вопрос у меня.

Люблю я хорошие вопросы. И приземление теории на суровую реальность.

Моя цель сделать так, чтобы вы знали как теоретические знания о НФТ, и не только, внедрить на практике.

Давайте опубликую ответ сюда 😉

P.S. Вика, спасибо за идеи постов на сегодня

"Совместимость - способность приложения работать с разными системами и устройствами".

☑️ Когда пишем ТЗ на разработку мобильных приложений, всегда прописываем под Android и iOS дотошно версии ОС на которых все будет работать. Был опыт - закачик за наш счет попросил починить верстку и несколько системных багов, когда очередной iPhone вышел с новой ОС. И на стареньком Android, который казалось бы вышел из оборота, приложение крашилось (вылетало).

☑️ С браузерами такая же тема. Был прецедент, когда на Firefox и Mozilla все работало прекрасно, а на Safari часть кнопок нажималась, но реакции на нажатие не было. И другие баги. Кстати, поэтому тестировщики обычно тестируют веб-приложения в нескольких браузерах.
Есть еще проблема, что версии браузеров иногда неудачно обновляются.

☑️ А при работе с оборудованием (например, кард-ридеры) это особенная боль. Нужно четко прописыаать в ТЗ версии встраиваемых библиотек.

☑️ При интеграциях с библиотеками то же самое.

На заказной разработке требования к совместимости особенно важны. А то будет "мы ждали, что все и везде будет работать идеально". Но увы, не всегда все и везде идеально.

"Надежность - способность приложения работать бесперебойно на протяжении определенного времени, без ошибок".

☑️ Требования к SLA в ТЗ на сопровождение системы. Например, некоторые гос. системы требуют в SLA время работы без перебоев от 99,90% в год.

☑️ Какое время простоя допустимо у системы, если всплывет баг. Тоже в ТЗ на сопровождение системы. Это время на решение инцицента: от момента обнаружения до выката хотфикса в релиз. 4 часа, например. Тогда у вас есть дежурные разработчики по ночам и стоимость сопровождения проекта растет.

☑️ Требования к резервному копированию данных. Может быть включено в ТЗ на разработку. Когда надо поставить задачу на DevOps-ов, чтобы они с Backend-разработчиками проработали резервное копирование, например.

☑️ Влияние на выбор инфраструктуры: переключение ПО между серверами, расположенными физически в разных местах, в случае сбоев.

Еще немного про нефункциональные требования... мне очень нравится это видео.
Была на этом докладе лично. Бывшие коллеги. Очень бодро, с крутой сюжетной линией 🙃 Доклад зацепил!

Привет!

Пока я готовлю новые крутые материалы для вас и вебинары на февраль, рекомендую посетить мероприятие коллег 👇🏻

Спикеры IT_One расскажут об управлении новыми проектами и проработке системных требований для фич высоконагруженных аналитических систем.

📆 7 февраля, 18:00, онлайн, бесплатно — IT_One System Analysis Meetup при поддержке JUG RU Group.

В программе:
✔ Анастасия Кузьмина — «Как действовать бизнес-аналитику в новом проекте: хроника провалов и успехов».
✔ Андрей Белякин — «Как проработать системные требования различных фич высоконагруженной аналитической системы».

Вы сможете задать вопросы спикерам и подискутировать с другими участниками. Авторы лучших вопросов получат футболки. Также будут разыгрывать два комплекта мерча от IT_One среди тех, кто пройдет опрос и оставит отзыв о митапе 🎁

Регистрируйтесь и участвуйте — это бесплатно.

Привет!

Активно идет обсуждение, что GPTChat, созданный на основе искусствнного интеллекта (AI), в ближайшем будущем заменит junior-специалистов в IT, как минимум. А то и middle тоже. Аналитиков в частности.

Шансы есть. Штука действительно умная. Но все же кто-то должен уметь делать запросы, проверять реультаты и корректировать решения AI под специфику проекта - управлять процесом.

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

На скрине к этому посту я попросила его написать код для интеграции с Битрикс24. И он помчал!

Результат в целом верный. Осталось только в нужное место проекта вставить код и немного скорректировать. Junior-программистов он точно подменит. Но аналитики останутся нужны.

Бизнесы - уникальны. И GPTChat пока не может вести интервью с заказчиками, собирать требования и проводить глубокий анализ. Он оперирует существующими знаниями. А как мы знаем - каждый проект уникален!

Его решения в части аналитических задач пока общие. Дают много идей и подсказок, но слишком мало конкретики. Приходится их дорабатывать.

На русском, кстати, думает медленнее, чем на английском.

Будущее наступает. Мир движется. Но аналитика останется нужна. А что вы думаете по этому поводу? Пишите в комментарии ✍️

Привет! Ну что, давайте смотреть на монстра.

Как GPTChat помогает описывать бизнес-процессы аналитикам

Если раньше надо было долго гуглить, то теперь волшебный AI гуглит и структурирует информацию за нас. Стать бизнес-аналитиком в IT становится немного проще :) А для системных аналитиков, совмещающих в себе роли, появляются возможности глубже погружаться в тех. требования, а не в бизнес.

Задача:
Разработать систему для заключения сделок по купле-продаже недвижимости в США

Запрос в GPTChat:
Сделай описание бизнес-процесса заключения сделки на покупку недвижимости в США с учетом всех документов