Хочу поделиться с вами Key skils Systems Analyst которые нашла и сформировала для себя , чтобы в дальнейшем можно было легко оценить свой знания по всем пунктам.
Если на основе вашего обучения вы сделали срез и поняли, что вы обладаете базой то переходим к первым 13 вопросам которые у вас спросят на собеседовании:
Тут вопросы, быстрые ответы и ссылка на стать по ним.
1) Какие виды требований вы знаете?
Спецификация требований: Функциональные и не функциональные: раз, два.
Статьи для разработки ТЗ с нуля
2) Что входит в функциональные требования?
Описание поведения и требований от системы
Чат CgatGPT поможет вам на начальном этапе формировать требования
3) Что входит в нефункциональные требования?
Описание пользовательских требований
4) ГОСТ 19 и 34 для чего нужны и в чем разница между ними?
Если разрабатывается документация на программу, которую создают под конкретное предприятие, то используется ГОСТ 34.Если разрабатывается документация на массовую программу, то используется ГОСТ 19. Ссылка.
5) Критерии требований.
Для всего: Атомарность, Полнота, Краткость, Консистентность, Выполнимость, Приоритизированность, Тестируемость, Недвусмысленность, Понятность. Раз, два.
6) Заинтересованные лица (стейкхолдеры) - кто это и как с ними взаимодействовать?
Стейкхолдер (stakeholder)— это лицо, которое имеет интересы относительно проекта или организации или влияет на проект или организацию. Стейкхолдеры бывают внутренние (например, сотрудники и руководство) и внешние (например, клиенты, поставщики, общественность) Используем таблицу влияния на проект RACIКак управлять стейкхолдерами.
Кто такие и как их определять.
7) Что содержится в вашей типовой постановке задач?
Для разработчика макеты или ссылки на них, детали эксперимента, если он планируется, аналитика, платформы, на которых реализуется фича, ссылки на дизайн-доки/API,связанные задачи. Как написать Задачи разработчику: раз, два.
8) Чем Kanban отличается от Scrum?
Kanban- это метод работы через доску, тоесть задача состоит из следующей задачи (родительская, дочерняя) пока не закрыта одна задача, не можем перейти к другойScrum- это работа со спринатми и сдается в срок спринта.
9) Где можно применять Scrum и где нельзя?
Больше подходит к продуктовой разработке чем к аутсорс. Скрам плохо подходит для организации работы внутренних отделов — поддержка, юристы, маркетинг. Вывод: Скрам хорошо подходит для разработки новых продуктов в области программного обеспечения. И очень ограниченно подходит для аутсорсинговых проектов, тем более не софтверных. Ссылка.
10) Что такое XSD?XSD
Это язык описания структуры XML документа.
11) Чем SOAP отличается от REST?
Оба приложения обмениваются данными с помощью API, определяющего правила связи. SOAP и REST – это два разных подхода к разработке API. Подход SOAP отличается высокой степенью структурированности и использует формат данных XML. REST более гибкий и позволяет приложениям обмениваться данными в нескольких форматах. Ссылка.
12) Что такое XML и что в нем содержится?XML — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде. Ссылка.
13) Какие методы есть в RESTТрадиционно архитектура REST API использует четыре метода: GET— чтение информации. Запросы, сформированные таким методом, отвечают за простую передачу данных с сервера, но не удаляют и не исправляют их.DELETE— удаление данных.POST— создание или регистрация записей.PUT— изменение или обновление данных. Инструменты REST. Ссылка.
Надеюсь это было полезно :-)
Комментарии (8)
kost_tr
29.09.2023 06:08
b1ng0o
29.09.2023 06:08переходим к первым 13 вопросам которые у вас спросят на собеседовании
И вы ответити на них как джун который просто прочитал статьи на хабре :)
На самом деле в большенстве случаев каждый из "первых 13" вопросов раскроется в еще 5. Много чего можно добавить, что могут спросить и спрашивают на собеседованиях, я добавлю немного от себя:Документирование (нотации моделирования, docAsCode, и т.д.)
БД (типы БД, нормализация, типы связей, транзакции, оконные функции и т.д.)
Интеграции (не только REST, SOAP) - RPC(gRPC), GraphQL, очереди
Если говорить конкретно про REST, то "традиционно" применяют GET, POST. В остальном не плохо бы знать:
что такое PATCH и чем он отличается от PUT
какие методы идемпотентны, а какие нет
как не идемпотентный метод сделать таковым
К каждому из пунктов можно много чего добавить, но чем увереннее и правильнее вы ответите на вышестоящий вопрос интервьюера , тем меньше вытекающих вопросов получите :)
itGuevara
Это не так.
Вообще философия ГОСТ, причем не только указанных ЕСПД и АС (АСУ), но и ЕСКД, - она глубокая и практически забытая. Взять например, идею ТЗ-ТУ-ПМИ (это взаимоувязанный кластер, причем одно заимствовано из другого), что на программное, что на не программное изделие. Или например, схему деления изделия на составные части.
В листе не увидел нотации EPC и VAD (если говорят для "начинающего" - как раз бы с них начать), а также ссылку на что то концептуальное, терминологическое. Как пример массовой путаницы терминов "Business Function vs Business Process": https://habr.com/ru/articles/763910/
Olpop Автор
Это замечательно, что вы делитесь реальными навыками в этом вопросе! Так как данная информация это то что дается на многих обучающих курсах, но благодаря вам можно больше раскрутить эту тему и внести в нее ясность.
itGuevara
Боюсь, что парой критических формулировок не спасти положение. Книг по философии ГОСТ почти нет (с небольшими вкраплениями встречал только одну). Тем не менее, ГОСТы, включая 15 серию (во многом про системную инженерию), содержат богатый (глубокий), концепт проектирования, но часто он написан слишком бюрократически и много добавлено "воды". Его идеи можно прочувствовать только долго поработав с ГОСТ, причем со всеми сериями и желательно над крупной АСУ. Кстати, там сказаны и простые истины, например, что перед тем как что-то и изобретать (очередной велосипед) собери и проанализируй отечественный и зарубежный опыт, собери НТС и обсуди и т.п.
Сейчас по старым ГОСТ, включая 19, работать конечно вряд ли целесообразно, но их переработать с учетом современности - было бы полезно, например, освежить ГОСТ 19.701-90, добавить VAD, EPC и т.п., но главное связать подходы в целостную систему, включая связки "ТЗ-ТУ-ПМИ", схему деления программного изделия на составные части и др. (возможно что-то заимствовать из BABOK, SWEBOK/SEBOK, BPM CBOK - где тоже много "воды" и спорных утверждений). Только кто за это возьмется?
Helgich
15 серию просто так не возьмешь и не почитаешь.
На счет переработки ГОСТов, 34 серия потихоньку меняется, 15, кстати, тоже обновляется, но ввиду того, что некоторые системы разрабатываются не годами даже, десятилетиями, внедрение новых ГОСТов идет медленно.
itGuevara
Раньше и "РВ" лежал в интернете, сейчас не знаю как.
avf48
Не соглашусь, что в ГОСТ вообще есть "вода", там есть элементы, которые вас, в текущей ситуации/роли, не интересуют... Термины - да, с ними путАница... Но в ГОСТ по проектам, рискам, качестве, системам работа идёт, многое консолидировали/
консумировали.Например 34 я не пользуюсь, а вот 15 и 9 почти всегда. Но без понимания концепции ГОСТ 57195 и они не помогут...
Меня даже гугель поправил: "Вы написали skils. Возможно, вы имели в виду
skills" ????
За знание русского уже должно быть стыдно?
А про навыки Аналитика много, в комментариях, писали тут https://habr.com/ru/articles/741854/, но я считаю, что начинать нужно с профстандарта.