Карьера в IT. Системный аналитик, часть 5. Сбор требований
Всем привет.
Сегодня вернемся немного назад. Если про сами требования мы уже поговорили, про то, что это вообще такое, какими они бывают и какими качествами обладают, то вот про то, а как вообще их собирать - еще не проговорили.
Для этого придумали и сформулировали не мало методологий - давайте в них разберемся.
Интервьюирование
Интервью - это один из самых базовых и понятных способов сбора требований. Казалось бы, что в этом такого - просто взял заказчика под руку, отвел его в сторону и как давай спрашивать про всё подряд. Но тут кроются определенные тонкости.
Вообще, если говорить прям по теории-теории, то перед тем, как начать интервьюировать - надо определиться с теми лицами, которым нужно задавать вопросы.
Выглядит это так, что сначала нужно сформировать полный перечень заинтересованных лиц и потенциальных (или уже текущих) пользователей системы (тут важно понимать, что цели реальных пользователей системы могут сильно отличаться от целей бизнес-заказчиков, т.к. именно им работать с системой, а не заказчикам). Из каждой группы выделить одного или двух специалистов, чтобы избежать однобокого взгляда на проблему.
После этого уже требуется согласовать календарь встреч и желательно заложить время сразу на повторное интервью, обязательно заложив время между ними для того, чтобы вы могли осмыслить те ответы, которые вам были даны.
Это что касается теории. Однако на практике - в большинстве случаев это уже устарело, потому что у вас, почти всегда, будет ровно одна точка входа в бизнес-требования в виде PO или просто выделенного человека, достаточно высокой должности (уровня зам или руководителя определенного направления компании), которые сами ответят вам на все вопросы, без привлечения толпы лиц. И именно этот человек будет тем самым рупором, через который идет трансляция целей бизнеса на команду разработки.
Другой подход может быть, если вы внедряете какую-нибудь ERP\WMS систему на какое-нибудь предприятие, в этом случае я готов поверить, что та самая базовая теория будет актуальна для такого случая.
Пара важных моментов:
Всегда готовьтесь к интервью. Я не знаю почему, но даже опытные аналитики это не всегда делают, к моему сожалению. Не должно быть такого, что вы приходите на встречу, вам предлагают начать диалог и задавать вопросы, а вы такой: "Ой, да я даже не знаю, давайте вы расскажете просто что вам нужно". Очень желательно, заранее подготовить список вопросов или просто понять концепцию разговора, т.к. именно вы должны быть его драйвером.
Это нормально, когда после интервью у вас появляется больше вопросов, чем ответов - в этом случае, необходимо взять определенное время на проработку информации и потом собрать следующую встречу. Повторять до тех пор, пока не наступит достигните желаемой степени определенности в задаче.
Прототипирование
Еще один распространенный и интересный подход - это первичное создание прототипов системы. Прототип - это модель, позволяющая продемонстрировать интерфейс или поведение проектируемой системы. Сбор и уточнение требований прототипированием гораздо эффективнее проводить после выявления первичных требований любым другим способом, как минимум потому, что люди в большинстве своём визуалы и не особо готовы воспринимать большие полотна текста (как этот пост), но достаточно легко готовы идти на контакт и общаться, если вы показываете им картинки.
Тут важно понимать, что необходимо создать прототип, который отражает идеи реализации, близкие пользователям и заказчикам, которые они высказали при первичном обсуждении. Это поможет замотивировать их еще активнее вовлекаться в процесс диалога.
Прототип может быть:
Статическим, показывающим положение элементов в интерфейсе или структуры данных;
Динамическим - с возможностью демонстрации поведения системы по наступлению определенных событий;
Интерактивным - позволяющим пользователям и участникам заинтересованных сторон выполнять реальные действия так, как это будет работать в разрабатываемой системе.
Но у такого подхода есть и ряд минусов:
Сильно увеличивает трудозатраты, особенно если не удастся переиспользовать интерфейс для экономии времени разработки, т.к. стоит понимать, что сам процесс прототипирования отнимает достаточно большое количество времени, если это не на салфетке на встрече нарисованный макет интерфейса;
Заказчики могут акцентировать фокус своего внимания на красоту и дизайн прототипа их системы вместо обсуждения действительно важных вопросов реализации. Поэтому важно постоянно уводить нить их рассуждения от "Блин, тут кнопка не в наших корпоративных цветах, надо это поправить", к обсуждению того, как эта кнопка должна работать и что должно происходить по ее нажатию.
Анализ документации
Не менее основной подход к выявлению требований (особенно для системного аналитика), чем интервью, в случае если у заказчика уже есть какая-то система (или несколько), которые вам нужно доработать.
Данный подход выполняет сразу несколько целей:
Сократит время последующего анализа потребностей и проблем заказчика. Кроме этого облегчит взаимодействие с заказчиком и другими членами команды разработки, т.к. вы больше вникните в процесс и будете разговаривать на одном языке;
Возможно вы сможете получить ту информацию, которой уже (или еще) из представителей заказчика не обладает.
Для начала требуется определить с какой документацией необходимо и желательно работать. Это можно сделать у представителя заказчика, который может предоставить нам список необходимой “литературы”, релевантной относительно текущих процессов. Либо, если вам предоставили доступ к каким-либо информационным ресурсам заказчика - поискать такие документы самостоятельно.
Мозговой штурм
Мозговой штурм - наверно это метод, про который слышали все. Но как его правильно применять? Обычно, рекомендуется его использовать среди команды или в связке с командой и заказчиком, в случае, если нужно определить первичный набор идей.
Такой формат не позволит вам выбрать что-то наилучшее или оптимальное, однако позволит по накопившимся идеям получить быструю обратную связь, отследить реакцию заказчика на них, выбрать несколько наиболее подходящих и далее “копать” в том направлении, развивая эти идеи.
Перед тем как проводить такой штурм, в любом случае требуется определить цель. Без чёткой цели идеи будут предлагаться уж совсем несуразные. Возможно, вам будет весело, но вот продуктивно ли? Сомневаюсь.
Однако в процессе фонтанирования идеями нельзя сразу отбрасывать даже самые безумные и фантастичные на первый взгляд идеи. Как показывает практика, некоторые из них при более детальном рассмотрении оказывается совсем уж не сумасшедшими, а вполне даже дельными и гениальными.
И еще один принцип работы с таким подходом - ни в коем случае нельзя критиковать возникающие идеи, т.к. после этого человек, подвергнутый критике, вряд ли будет предлагать другие идеи (да, да, в IT люди очень нежные в большинстве своем). Просто в определенный момент, когда закончится поток идей - уже записанные идеи должны быть оценены, возможно проведением голосования и в следующий этап перейдут только наиболее популярные идеи.
Анализ конкурентных продуктов
Кроме всех вышеперечисленных способов - можно применить еще один, достаточно интересный. Если вы не разрабатываете что-то совсем новое и уникальное, не делаете “rocket science”, то скорее всего у вашего продукта или системы уже есть аналоги. И очень не глупой идеей будет проанализировать их, посмотреть на отзывы пользователей, самому попользоваться данной системой (если это возможно) и сделать на основании этого выводы о преимуществах и недостатках данного продукта.
И конечно же, чтобы не натыкаться на те же грабли - заранее исправить недостатки, которые уже не нравятся пользователям и позаимствовать удачные и интересные решения, которые каким-либо образом можно использовать в вашем продукте.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.S. Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
История одного слесаря
Вечер, тихо падает апрельский снег, задуваемый остатками зимнего ветра, ночной Питер подмигивает в окно рыжими фонарями, а я тихонько офигиваю от происходящего вокруг (в нашей стране в целом и в мире в частности). В такие моменты хочется ухватиться за прошлое как за спасительную ниточку, но не искать ответы "что было не так", а просто вспомнить хорошее, доброе, как у нас говорят - провести ретроспективу. Заварите себе чайку, если моё старческое бормотанье ещё вас не усыпило, текст может получиться длинным.
Пять лет уж прошло с того, как я решил резко (и почти без подготовки, но это выяснилось позже) изменить свою жизнь, а в частности, карьеру. Но началось всё ещё раньше, когда я родился. Ладно, расслабьтесь, не буду настолько издалека. Родился и вырос я в Питере, но из всех мыслимых плюсов этого статуса, которые вам сразу рисует воображение за этими словами, у меня была разве что прописка. Жили скромно, мама тянула как могла, поэтому к середине 9 класса у меня не было вопроса "как дальше" - конечно, ПТУ: профессия через 3 года, возможнотсть заработать на хлеб и перестать сидеть на шее у взрослых! А уж там как-нито выплыву, думал я, не особо углубляясь в планирование на такой длинный срок.
Так и получилось в итоге - учёба, практика, армия, работа, потом другая, и вот уже за спиной 8 лет стажа (за который бабушка до сих пор переживает иногда, так уж её приучили), на дворе 2017 год, а я понимаю, что топчусь на месте. Я тогда работал на радиоэлектронном производстве простым слесарем, периодически за грузчика, а годков-то было уже под 28 и я чувствовал, как опускаюсь в никуда: ни мои идеи, ни подходы к работе никому вокруг не нужы и не интересны, особенно начальству. Нормально работать вокруг никто не может или не хочет, кроме единиц стариков, на которых держится всё производство. Руководители помельче жрут друг друга как пауки в банке, руководители побольше - жрут бюджет и мою зарплату (которая могла бы быть больше минимум в половину, я примерно прикидывал перерасход на некоторых цепочках), а меня пожирают уныние и беспросветная тоска по светлым мирам, где замечательные люди ценят труд, уважают друг друга и не существуют. В смысле, не существуют, а живут полной жизнью.
Короче, толкнул меня на мысль тогда мой брат (младший, отец общий) - тыж, говорит, всё в своём Unity ковыряешься, может подучишься слегка да попробуешь себя в разработке? Да ну, отвечаю, это же просто хобби.
- Ты даже меня научил, - ответил он. - Давай, ты можешь.
Я задумался. Игры любил с детства, как в принципе всё вымышленное, компьютеры и приставки были тем немногим, что меня дейтвительно интересовало в окружающем мире (кроме физики, астрономии и научной фантастики), да и ковыряние в игровом движке уже как года три было моим хобби. На какие-то завершённые проекты меня не хватало (ни усидчивости, ни времени, ни знаний), но вот отдельные вещи иногда удавались неплохо: правдоподобный танк с физикой, плавная стратегическая камера (да, во многих компьютерных стратегиях движение камеры меня просто бесит), генератор лабиринтов...
В общем, первая попытка устроиться была просто провальной, хотя я и проработал целых 9 месяцев. Это было новое направление в новом отделе в компании, которая никогда не занималась разработкой, и сейчас я понимаю, насколько тогда директор, который лично одобрил всю эту затею, здорово рисковал и вообще верил в успех и в нас. Но мы всё равно что-то сделали по итогу, а вот у меня лично началась беда с дисциплиной, самооценкой, саморазвитием на почве отсутствия прогресса в навыках. Я в себе разочаровался, потому что чувствовал, что делаю какую-то херню. А как делать не херню, я тогда не знал. Потом был долгий перерыв, что-то вроде мини-депрессии, меня спасли только моя тогдашняя девушка и некоторая сумма денег (я не умел тода тратить, поэтому зп просто копилась), ибо длилось всё это почти четыре месяца. И вот, наконец, я намотал сопли на кулак, собрал в него же яйки и решил что всё - я теперь прахрамист и назад пути нет!
Вторым местом стала маленькая студия, выпускающая мобильные игрульки. В основном довольно простые, поэтому сами игры меня не заинтересовали, я просто пошёл к первым кто согласился меня взять. И вот тут я понял, почему про разработку мобилок столько мемов... Для меня тогдашнего это было норм, но сейчас я понимаю, насколько скучные были задачи: я интегрировал рекламу и статистику в приложениях, настраивал в аккаунтах паблишинг и прочие мерзкие слова, кроче, срамотой какой-то занимался. Единственным куском игрового функционала, который мне дали написать, стала система сохранения поля в игре судоку. И через два месяца мне сказали, что я не подхожу им. Ну и ладно, не очень-то и надо было. Хотя ребята были опытные, я у них многому научился, но некоторые из них были какие-то надменные, очень смузичные и, как сейчас говорят, наяривающие на всё американское (и стебущие попутно всё русское) - мне это не понравилось, хотя в целом я старался просто держать язык за зубами и не вклиниваться в общение.
Со следующией работой мне повезло, это были 3,5 года в маленькой, но очень дружной международной команде, где я получил много опыта в новой для себя сфере - разработке промышленных VR-симуляторов и тренажёров. Крутые интересные технологии, необычные задачи - например, симулятор прдводного робота и виртуальная экскурсия по буровой платформе. З/п была поначалу для меня непривычно хороша, и я, такой довольный, первые два года вообще не думал спросить о повышении. А когда осознал, что всё же стоит, долго набирался смелости. Попросил, дали - в два этапа по +10, я не решился просить много. По скиллу уже тогда я свою з/п перерос, а головой ещё не дошёл до этого факта. И тут грохнулась на всех нас пандемия, а затем и война, а и из-за давления инвесторов материнский офис принял решение российский филиал закрыть. Релокацию предлагали, я не поехал - не хочу на чужбине как беглец.
Отдохнул месяцок, как раз лето было, и снова в поиски. На этот раз, уже умудрённый опытом и работы, и собеседований, я умудрился продать себя прям дорого. Ну не так чтоб совсем, но по моим меркам - огого! 150% от предыдущей з/п. Но я себя успокоил тем, что во-первых, я вырос как специалист, а во-вторых, кризис-шмизис, айтишники чёт поразъехались (ха! сентябрь тогда ещё не загорелся) и вообще, хочу-могу-имеюправо!
Но то был прыжок выше головы. Тоже мобилки, но команда большая, несколько направлений, крутые ребята с опытом, дружные как семья, не заносчивые, какие-то простые, будто ты с ними в общаге живёшь и вот на кухню вышел, а там жизнь кипит. Честное слово, от этого коллектива у меня и сейчас слёзки готовы навернуться, они все такие классные! А вот задачи я не потянул. Во-первых, растерялся, испугался и начал тупить. В меня, оказывается, общество и родители вдолбили, что я всё должен сам, вот и не попросил помощи, когда надо было. В итоге опять сам себя закопал, как пять лет назад, загрузился и не вытащил, пришлось уходить. Хотя сейчас понимаю, что всё равно разработка мобилок не по мне, пусть даже и более крутых технически.
И вот, отгремел экономными салютами 2023-й Новый год, а я снова в поисках. На этот раз меня сами нашли, позвонили, пригласили в компанию, чью вакансию я даже не видел на ХХ. Местные ребята,небольшая команда, делают медицинский виар, что-то вроде простых тренажёров для терапевтов, только погружение "с головой". И знаете, что? Это так круто чувствовать себя снова на своём месте, делать важное и нужное дело и кайфовать от решения сложных задач! Не унывайте, верьте в себя и трудитесь! Если труд сделал из обезъяны человека, то у вас уже есть большая фора и хороший инструмент для движения вперёд.
Начало карьеры QA (тестировщика)
Привет. Немного устал отвечать в комментариях на однотипные посты, поэтому решил накатать свой и собрать все воедино. Расскажу о том стоит или нет вкатываться в IT с тестирования и как это делать правильно.
Для ЛЛ: учите программирование и качайте софт-скиллы.
В целом вкатываться то не поздно и IT это не очередной пузырь, это скорее поезд, который едет с ускорением и на него все сложнее впрыгнуть тому, кто стоит неподвижно в стороне. Сейчас нужно понять что происходит вокруг и что является результатом труда.
У каждого ремесла есть взлеты и падения. Так в 90е была востребованная профессия «эксперт по прокладке сетей», эксперт приходит и говорит где ставить розетки, где роутер и сколько чего, забирает свои 1000$ за консультацию и уходит, к началу нулевых профессия вымерла по причине ненужности.
В нулевые всем понадобились сайты и появляется очень востребованная профессия верстальщика. Ценник на сайт из трех страниц был от 500$ и до бесконечности. Постепенно верстку html страниц смогли делать все и верстальщиков стали нанимать за зарплату разнорабочего.
В середине нулевых всем захотелось делать активные сайты. Появилась востребованная профессия PHP-кодера. Ценник на такие сайты был от 1000$ за морду с оправкой формы и до бесконечности. В начале 2010х все стали уметь в CMS и PHP программистов стали нанимать за зарплату разнорабочего.
Во второй половине нулевых реклама сместилась с телевидения в интернет. Всем понадобилась посещаемость сайта и появилась востребованная профессия SEO, ценники были от 2000$… В середине 2010х поисковики создали кучу механизмов защиты от накруток, а CMS прекрасно делали базовую SEO и сеошников стали нанимать за зарплату разнорабочего.
И вот конец 00х. Появление СМС-платежей, еще свободные системы вебденег, бабло течет в рунет. Лучшее время для классических вебмастеров в рунете. Можно вообще не работать, иметь несколько сайтов, сливать через них трафик на партнерки, арбитраж, сапе и пр. Через несколько лет, население освоилось с смс платежами, а крупные компании подмяли под себя основные темы сбора денег (игры, жирные партнерки, и пр.), классические вебмастера стали зарабатывать как разнорабочие.
Все эти профессии отличает то, что результат труда человека обесценился, как правило, по причине банального прогресса. QA как профессия довольно молодая, книг мало, в вузах этому не учат, дипломов нет. Самое неприятное, что составить портфолио и презентовать кому-то знания и навыки крайне сложно, а работа предполагает какую-то команду и кооперацию. Совокупность навыков обычно делят по уровням на:
Обеспечение качества (Quality Assurance) — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.
Контроль качества (Quality Control) — анализ результатов тестирования и качества новых версий выпускаемого продукта.
Тестирование (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом.
Так вот, в данный момент Testing уже стал автоматизированным, потому что бизнесу важно получать обратную связь как можно быстрее для сохранения конкурентоспособности. QC стал полуавтоматизированным за счет CI/CD и мониторинга, в целом это больше про владение разными инструментами. А вот QA еще сильнее сместился в сферу коммуникации и разработки. И есть тенденции к эволюции этой схемы.
Нижние уровни сейчас и невостребованны, чтобы там не пели инфоцыгане. Если кто-то пишет, что не нужно уметь программировать, плюньте ему в рожу. То есть никому не интересно как виртуозно вы кликаете кнопочки, робот это будет делать всегда быстрее. Никому не нужны тест кейсы, потому что они и так будут в виде самодокументируемого кода автотестов, либо их можно сгенерировать на их основе, опять же автоматически. И хотя всегда будут программы, которые не автоматизируешь, гораздо больше будет бизнесов, которым нужны релизы раз в час. Потому что бабло и прогресс, а не потому что я так хочу.
Вот и получаем, что как не крутись, а на первый план выходит программирование и владение инструментами. Кто хочет легкого старта в IT, могут на этом и закрывать страницу, потому что легкого не будет. Если разработчики создают сам программный продукт, то современные тестировщики создают инструменты для обеспечения качества этого продукта. Знать и уметь в 2023 нужно почти как в разработке, да, не так хардкорно, но и вакансий/денег все же поменьше. Вот примеры. Быстро накатать скрипт для тестовых данных или создания нагрузки на сервис. Написать мок или знать как использовать готовый. Вытащить логи из потрохов бэкенда. Написать метрики для мониторинга.
А еще и в софты надо уметь. В каких-то случаях кодер может себе позволить самостоятельную работу, ну там бороду отрастить, запереться в подвале и писать код в полном уединении. Тестировщик так не сможет никогда, он член команды и всегда работает в команде. Вообще то их много разных и на все не стоит заморачиваться.
Я на первое место ставлю: любопытство, критическое мышление, эрудицию и ответственность. И каждый пункт можно раскрыть с очень необычной стороны, покажу на последнем примере.
Ответственность – это не кричать “Я!” и кидаться героически делать. Ответственность – это готовность иметь дело со всеми последствиями принятых нами решений. Даже если мы решаем ничего не менять – это тоже решение. У него тоже будут последствия. Допустим, по соседству со мной поселился алкаш, который орет по ночам и не дает мне спать. С недосыпу я становлюсь раздраженным, поэтому я сегодня съязвил в разговоре с коллегой, а вечером поругался с женой. Ну да ладно, объяснился, извинился – все уладили. Но дальше я решил, что алкаш со временем успокоится и не стал ничего делать. И так прошло полгода. Алкаш за полгода не успокоился, и сегодня ночью снова орал. Кто виноват, что я плохо спал? Ну, с натяжкой, по-прежнему алкаш. А кто виноват, что на работе у меня образ токсичного засранца и в семье разлад? Так что тут сложно что-то советовать, потому что софты качаются очень тяжело.
Если дочитали, до перейдем уже к тому, что делать для вкатывания. По моему опыту даже на начальные позиции гораздо охотнее берут без каких-то специфичных хард скиллов, зато с софт скиллами. Горящие глаза, продуктовое мышление, коммуникативные способности, обучаемость и все что выше будут ценнее, чем 10 лет кодинга на пыхе. Тестировщику важнее остальных развиваться не только в глубину, но в ширину знаний. Тут проще показать T-моделью:
Да, тест-дизайн рулит, но без нескольких лет практики вы этого не поймете, хоть зубрите Канера до дыр, но лучше осваивать инструменты и сопутствующие технологии, тем более, что это намного легче сделать самостоятельно без коммерческого опыта. Примеры: Git, SQL, CI/CD, Docker, мониторинг. Обязательно уметь хотя бы ориентироваться в юниксах и консоли. Ставье убунту или что душе угодно, WSL2 на винде, консоль в маке, ковыряйте роутеры, телефоны, телевизоры и все что под рукой. Ставьте виртуалки и контейнеры, придумывайте задачи, патчите KDE под FreeBSD и сритесь на форумах. Зарегайтесь на гитхабе, там есть бесплатный Actions или поставьте локальный CI/CD. Учите любой ЯП с прицелом на автоматизацию и инфраструктуру (java, python, go, js). Полезным будет знать любой скриптовый язык хотя бы поверхностно. Найдите или придумайте задачу, пет-проект, обложите его тестами, настройте интеграции и релизы. С таким багажом ходить по собесам будете недолго.
Вот несколько ссылок на материалы, которые я обычно советую:
Большая подборка ресурсов и сообществ для тестировщика / Хабр (habr.com)
https://vladislaveremeev.gitbook.io/qa_bible/
По этой причине платить и надеяться на курсы не стоит, если есть лишние деньги, лучше возьмите курсы по разработке, а еще лучше найдите ментора.
И еще не стоит молиться на сертификаты, это не MS/Oracle. В QA единственным авторитетом был ISTQB, но они там сейчас все поехавшие. Сначала нужно получить базовый сертификат «Сертифицированный тестировщик», который полностью основан на устаревшей водопадной модели, где есть отдел тестирования, который получает продукт от отдела разработки и начинает писать тест-кейсы, а потом мы получаем доступ к ещё одному базовому же сертификату «Тестирование в гибких методологиях», который уже основан на нормальном эджайле. Все остальные курсы основаны опять же на водопадной модели, как и первый сертификат. Получается ISTQB вместо того, чтобы переписать свои книги и сертификации, учитывая существования эджайл - просто добавили один эджайл сертификат и наплодили кучу разных водопадных сертификатов. Но переписывать ведь дорого, а если добавить сертификатов - то это только профит. И курсы и сертификаты созданы только для того, чтобы на них зарабатывали их авторы. Конкретно ISTQB может пригодиться только для релокации без профильного образования в иностранную бюрократизированную компанию.
Послесловие. Я в профессии 12 лет, но вижу ситуацию как и любой только со своей колокольни. Всегда и везде есть альтернативы. Просто сейчас высока вероятность, что они приведут примерно сюда:
Карьера в IT. Системный аналитик, часть 4, XML и JSON
Всем привет.
Сегодня продолжим наш экскурс в глубины системного анализа. Перед тем, как мы перейдем к интеграциям - логично было бы поговорить об XML\JSON.
XML
XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Отличается простотой синтаксиса и универсальностью. XML позволяет описывать документы с помощью тегов, которые можно задавать самостоятельно. Так что увидеть его использование можно и в API в том числе (хотя и намного реже, чем JSON).
XML позволяет:
записывать иерархию — «один подчиняется другому»;
размечать текст по смыслу от важного к второстепенному;
хранить типовые данные — скрипты, настройки программ, названия чего-либо;
размечать текст для машинного обучения;
хранить результаты работы текстовых редакторов.
У XML-файлов древовидная структура. Это значит, что в них используется набор тегов, внутри которых могут находиться другие теги со своими значениями. Самый верхнеуровневый узел называется корнем, а все, что находится внизу, — листьями.
Теги
В XML каждый элемент должен быть заключен в теги. Тег — это некий текст, обернутый в угловые скобки:
<tag>
Текст внутри угловых скобок — название тега.
Тега всегда два:
Открывающий — текст внутри угловых скобок
<tag>
Закрывающий — тот же текст (это важно!), но добавляется символ «/»
</tag>
С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается».
В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа.
Для примера давайте опишем объект Task нашей системы (см. первую практику) в формате XML.
<task type="issue"> (открывающий тег и корневой элемент заодно)
<topic> Не работает принтер</topic>
<priority> high</priority>
<isMass> false </isMass>
<description> Сломался принятер. Выключился ибольше не включается. Нужно срочно распечатать много документов, а не получается. Что делать? Просьба помочь</description>
</task> (закрывающая тег)
Пара особенностей, помимо перечисленных:
Все теги являются регистро-чувствительными. Это значит, что если, например, тег <user> закрыт </User>, документ будет оформлен некорректно;
Значения атрибутов должны быть заключены в кавычки. Атрибут — характеристика тега. Любые теги могут иметь атрибуты;
Вложенность тегов контролируется, поэтому важно следить за порядком открывающих и закрывающих тегов.
JSON
JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.
JSON обладает рядом преимуществ. К ним относят:
компактность;
простое чтение предложений, написанных подобным образом – актуально и для машины, и для человека;
легкость преобразования в структуры данных для разнообразных языков программирования;
наличие у большинства языков программирования функций и библиотек, которые помогут создавать и читать структуры JSON.
JSON-объект — это неупорядоченное множество пар «ключ:значение», которые разделены ",".
Давайте теперь тот же объект Task опишем в формате JSON и я думаю, что на этом примере сразу станет понятна структура, потому что она намного более простая и наглядная, чем XML
{ (открывающая скобка - начало объекта, закрывающая скобка - конец объекта)
"type" : "issue", (Слева - ключ, справа - значение)
"topic" : "Не работает принтер",
"priority" : "high",
"isMass" : "false",
"description" : "Сломался принятер. Выключился ибольше не включается. Нужно срочно распечатать много документов, а не получается. Что делать? Просьба помочь"
}
JSON на данный момент наиболее распространен и повсеместно используется в REST, например.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
В следующей части расскажу базовую теорию про интеграцию и начнем плавно переходить к REST'у.
Карьера в IT. Системный аналитик, часть 3.1, диаграммы. UML + BPMN
Всем привет.
Сегодня продолжу рассказывать о таком прикладном инструменте системного аналитика, как UML и также рассмотрим BPMN.
В прошлом посте мы поговорили об основных типах диаграмм, которые наиболее часто используются на данный момент. Сегодня расскажу о последней (и моей любимой) - диаграмме последовательности.
Самая любимая она потому, что с помощью нее можно показать почти любые процессы, у которых есть какая-то длительность.
Если говорить по-умному, то диаграмма последовательностей относится к диаграммам взаимодействия UML, описывающим поведенческие аспекты системы, но рассматривает взаимодействие объектов во времени. Другими словами, диаграмма последовательностей отображает временные особенности передачи и приема сообщений объектами. Но зачем нам это, верно?
Если говорить проще, то с помощью этой диаграммы можно показать взаимодействие объектов в рамках какого-либо сценария, с возможностью акцентирования внимания на сообщениях, которыми они обмениваются, и возвращаемых результатов, связанные с сообщениями.
Кроме того, можно описывать как бизнес-процессы, так и сугубо технически вещи - например, показать взаимодействие фронта и нескольких микросервисов в рамках какого-нибудь сценария.
Выглядит диаграмма следующим образом:
Тут, например, отображен бизнес-процесс покупки курса пользователем. По шагам описано взаимодействия пользователя с системой и дальнейшее взаимодействие системы с другими участниками процесса (такими же системами).
Даже без подготовки такую схему можно легко прочитать и пошагово понять, что происходит или должно происходит в рамках описываемого процесса.
BPMN
Теперь по поводу BPMN.
Business Process Model and Notation (нотация моделирования бизнес-процессов) — это система условных обозначений, которая отображает бизнес-процессы с помощью блок-схем.
BPMN диаграмма показывает в какой последовательности совершаются рабочие действия и перемещаются потоки информации.
Наглядная схема показывает, где в процессах есть узкие места или вовсе тупики, из-за которых клиенты уходят или не заканчивают целевое действие (заявка, покупка, звонок). BPMN подсвечивает места, которые можно улучшить и моделирует способы адаптации под новые условия.
BPMN-схемы описывают бизнес-процессы единым стандартизированным языком, который понятен всем участникам независимо от уровня их технических познаний.
Пример схемы:
Теперь немного о базовых объектах BPMN:
● Event – Событие;
● Activity – Действия;
● Gateway – Шлюзы или Развилки;
● Flow – Поток.
● Date – Данные;
● Artefact – Артефакты;
● Swimline – «плавательные дорожки»;
● Pool (Пул) — набор.
EVENT (СОБЫТИЕ)
События могут быть начальными, конечными или промежуточными.
Например, опишем процесс получения заказа от клиента по телефону:
● Событие Старт – это входящий звонок от клиента.
● Событие Финиш – это отправка готового расходного документа на печать.
ACTIVITY (ДЕЙСТВИЯ)
Activity – это те действия (задачи), которые должны быть выполнены на определенном этапе бизнес-процесса. Их при моделировании обычно обозначают в виде прямоугольников, в которые вписывают суть действия.
Действия могут быть элементарными, т.е. неделимыми на какие-то более простые действия, так и не элементарными, т.е. такими, которые при детализации делятся на последовательность определенных более простых действий.
GATEWAY (ШЛЮЗ, РАЗВИЛКА)
Gateway – это контрольный узел, который появляется в случае условного ветвления бизнес-процесса. Графически изображается в виде ромба.
Также шлюзы необходимы в случаях, когда порядок действий зависит от тех или иных факторов. Например, при работе с заказчиками шлюз появляется на этапе принятия клиентом решения о покупке – «да или нет». При положительном решении необходимо оформить покупку, при отрицательном – выяснить возможные причины отказа, провести работу с «отказом» и т.д.
FLOW (ПОТОК) И MESSAGE FLOWS (ПОТОК СООБЩЕНИЙ)
Поток Flow – это последовательность действий, обозначается как стрелка, и показывает, какое действие после какого необходимо совершить.
Message Flows – это пунктирные стрелки в бизнес-модели, которые показывают сообщения, которыми обмениваются участники бизнес-процесса. Например, если заказ переходит от клиента в обработку в отдел продаж, он сопровождается сообщением, которое содержит информацию об этом заказе. Также Message Flows могут связывать два отдельных пула в диаграмме.
Message Flows Association – еще один вид линий, в отличие от сообщений, которые являются пунктирными линиями, этот вариант отображается в виде последовательности не отрезков, а точек.
POOL (ПУЛ)
Пул – это объект описывающий какой-то один процесс на диаграмме. Он может быть не изображен на диаграмме, но он всегда есть. На одной диаграмме может быть несколько Пулов. Пул можно развернуть для просмотра деталей.
Пул может также содержать, так называемые, «дорожки». Они нужны для того, чтобы указать участников процессов, которые скрыты в пуле. Например, в процессе работы с клиентами участвует менеджер по продажам, руководитель отдела продаж, возможно, бухгалтер или кассир.
Итого.
Это основные объекты BPMN, которые чаще всего используются. Кроме перечисленных есть еще не мало других, но они используются уже реже и о них можно почитать отдельно.
И что еще важно - BPMN можно на самом деле использовать не только для построения бизнес-процессов, но и для описания тех же интеграций. Да, это не по фэншую, но кто нам может запретить?
Например (сорри за качество, так уж шакалится картинка):
Если то, что вы делаете устраивает вашу команду и помогает ей разобраться с процессам - вы молодцы, это значит, что инструмент использован не зря, как и время потраченное на него (хотя я уже ожидаю комментарии различного толка на этот счет).
P.S: Уже по традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
Поиграем в бизнесменов?
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.
Карьера в IT. Системный аналитик, часть 3, диаграммы. UML
Всем привет.
Сегодня поговорим о таком прикладном инструменте системного аналитика, как UML.
Зачастую у многих возникает вопрос - а зачем вообще рисовать любые диаграммы и схемы? Мы все такие замечательные, уже научились писать требования, оформлять разными способами (даже красивыми) - в общем-то, по этим требованиям же и так всё понятно?
И отчасти это так. Глобально - качественно собранных и поставленных требований к системе за глаза хватает для того, чтобы система была нормально разработана, без каких-либо проблем. Но зачем останавливать себя в желании "прибраться" в голове или наглядно объяснить что-нибудь команде - ведь наличие наглядной схемы позволяет решить все эти задачи и заметно упрощает жизнь.
Это я подвожу к тому, что если у тебя есть свободное время на создание схемы (а это бывает не так часто), то лучше ее сделать. А возможно и в целом начать аналитику именно с нее. Это поможет структурировать твои собственные мысли, увидеть возможные неточности или не проработанные моменты в том или ином процессе.
UML
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования систем.
UML использует в основном графические обозначения для выражения дизайна проектов. Использование UML помогает проектным группам лучше взаимодействовать между собой и легче вникать в проекты.
Основные цели дизайна UML:
Предоставить пользователям готовый, выразительный язык визуального моделирования, чтобы они могли разрабатывать и обмениваться осмысленными моделями;
Быть независимым от конкретных языков программирования и процессов разработки (важно);
Обеспечить формальную основу для понимания языка моделирования;
Поддержка высокоуровневых концепций разработки, таких как совместная работа, структуры, шаблоны и компоненты.
Преимущества и недостатки проектирования диаграмм:
Начнем с недостатков:
Дополнительная трата времени, которого может и не быть;
Необходимость знать и понимать различные нотации.
Преимущества:
Возможность посмотреть на задачу с разных точек зрения;
Другим членам команды (включая заказчиков) легче понять суть задачи и способ ее реализации;
Диаграммы сравнительно просты для чтения после достаточно быстрого ознакомления с их синтаксисом.
В UML диаграммы подразделяют на два типа — это структурные диаграммы и диаграммы поведения.
Структурные диаграммы показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь. Элементы в структурной диаграмме представляют значимые понятия системы и могут включать в себя абстрактные, реальные концепции и концепции реализации. Существует семь типов структурных диаграмм:
Диаграмма составной структуры
Диаграмма развертывания
Диаграмма пакетов
Диаграмма профилей
Диаграмма классов
Диаграмма объектов
Диаграмма компонентов
Диаграммы поведения показывают динамическое поведение объектов в системе, которое можно описать, как серию изменений в системе с течением времени. А к диаграммам поведения относятся:
Диаграмма деятельности
Диаграмма прецедентов
Диаграмма состояний
Диаграмма последовательности
Диаграмма коммуникаций
Диаграмма обзора взаимодействия
Временная диаграмма
Все мы рассматривать не будем (при желании это можно сделать самостоятельно) - разберем лишь основные, которые наиболее часто используются (по крайней мере в моей практике).
Диаграмма классов
Диаграмма классов — это центральная методика моделирования, которая используется практически во всех объектно-ориентированных методах. Эта диаграмма описывает типы объектов в системе и различные виды статических отношений, которые существуют между ними.
Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:
Ассоциация - представляет отношения между экземплярами типов. Например, человек работает на компанию, у компании есть несколько офисов;
Зависимость — это форма отношения использования, при которой изменение в одном классе - влечёт за собой изменение другого, причём обратное не обязательно.
Агрегация - это ассоциация типа «целое-часть». При этом обе части могут жить отдельно друг от друга (машина - колесо).
Композиция – это такая агрегация, где объекты-части не могут существовать сами по себе (дом - комната).
Пример:
Стоит еще рассказать про такую вещь как "Кратность". По сути между объектами может быть всего 3 типа кратности, которые уже могут варьироваться:
1 к 1. Это значит, что ровно одному объекту соответствует ровно один объект. Например - у одного человека может быть только один паспорт (не берем загранник);
1 ко многим. Одному объекту может соответствовать множество объектов (множество это может быть и 0). Например - один автор написал много книг;
Многие ко многим. Множеству объектов может соответствовать множество других объектов. Например - много поставщиков поставляют много товаров (в том числе пересекающихся).
При этом могут быть частные варианты, такие как, как 1 : 0..* (1 объекту соответствует множество объектов или ни одного. Например, у одного покупателя может быть множество заказов, но их может и не быть совсем). Или 1 : 3..*, т.е. одному объекту соответствует минимум три других и в целом любые возможные комбинации.
Диаграмма прецедентов
Диаграмма прецедентов - описывает функциональные требования системы с точки зрения того, как она будет использоваться людьми и/или взаимодействовать с другими системами.
Сущности, с которыми система должна взаимодействовать, называются actor’ами (эктор, актер), при этом каждый из них ожидает, что система будет вести себя строго определенным образом.
Актер - если упростить, то это какой-то конкретный пользователь или роль, или другая система, подсистема или класс.
Другой участник данный диаграммы - прецедент. Это описание отдельного аспекта поведения системы с точки зрения пользователя (да, это те самые UC, которые рассматривали в прошлой части).
Прецеденты и актеры соединяются с помощью линий. Часто на одном из концов линии изображают стрелку, причем направлена она к тому, у кого запрашивают сервис, другими словами, чьими услугами пользуются. Прецеденты могут включать другие прецеденты, расширяться ими, наследоваться и т. д.
Пример диаграммы:
В языке UML несколько стандартизированных видов отношений между актерами и вариантами использования:
Отношение ассоциации - самая обычная закрашенная стрелочка, которой можно соединять только актера и варианты использования. Она означает, что актер может выполнять действия, описанные вариантом использования.
Отношения обобщения - показывает, что определенный актёр или вариант использования может быть обобщён до другого актёра или варианта использования. Как на примере выше - UC "открытие счета ФЛ" и "открытие счета ФЛ" обобщены в UC "Открыть счет".
Отношение включения - показывает, что включенный UC должен быть обязательно выполнен, при выполнении другого варианта использования, в который он входит.
Например, при предоставлении кредита в банке всегда происходит проверка платежеспособности клиента.
Отношение расширения - показывает, что расширенный UC может быть выполнен в составе того UC, в который он входит, а может и не выполняться. Обязательности уже нет.
Например, при предоставлении кредита в банке может происходить с предоставлением налоговых льгот, при определенных условиях, но это не обязательно.
Диаграмма состояний
Диаграмма состояний - это тип диаграммы, используемый в UML для описания всех состояний системы и переходов между ними. Она отображает разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Кроме этого помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии.
Другими словами - такая диаграмма показывает то, как сущность переходит из одного состояния в другое.
На самом деле очень интересный тип диаграммы и их неплохо использовать для определения статусной модели ваших сущностей, для того, чтобы спроектировать какие у них могут быть статусы и при каких условиях они будут в эти статусы переходить.
Если рассматривать схему из примера, то это работает примерно так:
Стартовый статус нашей системы = "Бездействие". Дальше, если срабатывает триггер (допустим, получаем сообщение от датчика температуры, что она превысила установленную норму) - то система начинает переходить к общему статусу "Охлаждение". Он в свою очередь состоит из нескольких процессов - запуск компрессора, готовность и работа вентилятора.
Система находится в этом состоянии, до тех пор пока снова не срабатывает определенный триггер, например - получение сигнала от датчика температуры о том, что она вернулась в норму. В этом случае вентиляторы останавливаются и система снова переходит в статус = "Бездействие".
Или, например, случился сбой - система перешла в соответствующее состояние и, допустим, не может выйти из него без ручного вмешательства техника.
Послесловие.
Могу из своего опыта сказать, что диаграммы очень важны на проекте и желательно, чтобы при его документировании они использовались. Потому что одно дело бросить взгляд на диаграмму, прочитать ее и понять что происходит в нужном тебе процессе, другое дело вчитываться в пространное ТЗ с техническими подробностями, которые тебе, возможно, сейчас и не нужны.
Плюс, многие разработчики очень просят, чтобы диаграммы добавлялись в ТЗ, потому что им так намного проще осознавать что нужно сделать и что за чем идет (особенно актуально для интеграций). Да и в целом большинство людей визуалы.
P.S. Про UML это еще не всё, но пост получается очень большим, поэтому разобью на две части и добью остаток про UML в следующей. Заодно там же начну рассказывать про BPMN.
P.P.S: Завтра (25.02.2023 в 12.00 московского времени) у меня в телеграмме пройдет эфир где я буду отвечать на разные вопросы про карьеру/профессию/перспективы/развитие и т.д. В общем на все вопросы, которые мне будут задавать участники эфира.
Ничего продавать не буду, поэтому если хотите поболтать\послушать или даже есть какие-то вопросы на указанные темы - приходите, буду рад всем. Ссылка на телеграмм в моем профиле.