Комментарии 13
Если разрабатывается документация на программу, которую создают под конкретное предприятие, то используется ГОСТ 34.Если разрабатывается документация на массовую программу, то используется ГОСТ 19
Это не так.
Вообще философия ГОСТ, причем не только указанных ЕСПД и АС (АСУ), но и ЕСКД, - она глубокая и практически забытая. Взять например, идею ТЗ-ТУ-ПМИ (это взаимоувязанный кластер, причем одно заимствовано из другого), что на программное, что на не программное изделие. Или например, схему деления изделия на составные части.
В листе не увидел нотации EPC и VAD (если говорят для "начинающего" - как раз бы с них начать), а также ссылку на что то концептуальное, терминологическое. Как пример массовой путаницы терминов "Business Function vs Business Process": https://habr.com/ru/articles/763910/
Это замечательно, что вы делитесь реальными навыками в этом вопросе! Так как данная информация это то что дается на многих обучающих курсах, но благодаря вам можно больше раскрутить эту тему и внести в нее ясность.
Боюсь, что парой критических формулировок не спасти положение. Книг по философии ГОСТ почти нет (с небольшими вкраплениями встречал только одну). Тем не менее, ГОСТы, включая 15 серию (во многом про системную инженерию), содержат богатый (глубокий), концепт проектирования, но часто он написан слишком бюрократически и много добавлено "воды". Его идеи можно прочувствовать только долго поработав с ГОСТ, причем со всеми сериями и желательно над крупной АСУ. Кстати, там сказаны и простые истины, например, что перед тем как что-то и изобретать (очередной велосипед) собери и проанализируй отечественный и зарубежный опыт, собери НТС и обсуди и т.п.
Сейчас по старым ГОСТ, включая 19, работать конечно вряд ли целесообразно, но их переработать с учетом современности - было бы полезно, например, освежить ГОСТ 19.701-90, добавить VAD, EPC и т.п., но главное связать подходы в целостную систему, включая связки "ТЗ-ТУ-ПМИ", схему деления программного изделия на составные части и др. (возможно что-то заимствовать из BABOK, SWEBOK/SEBOK, BPM CBOK - где тоже много "воды" и спорных утверждений). Только кто за это возьмется?
15 серию просто так не возьмешь и не почитаешь.
На счет переработки ГОСТов, 34 серия потихоньку меняется, 15, кстати, тоже обновляется, но ввиду того, что некоторые системы разрабатываются не годами даже, десятилетиями, внедрение новых ГОСТов идет медленно.
Не соглашусь, что в ГОСТ вообще есть "вода", там есть элементы, которые вас, в текущей ситуации/роли, не интересуют... Термины - да, с ними путАница... Но в ГОСТ по проектам, рискам, качестве, системам работа идёт, многое консолидировали/консумировали.
Например 34 я не пользуюсь, а вот 15 и 9 почти всегда. Но без понимания концепции ГОСТ 57195 и они не помогут...
"Key skils Systems Analyst"
Меня даже гугель поправил: "Вы написали skils. Возможно, вы имели в виду
skills" ?
За знание русского уже должно быть стыдно?
А про навыки Аналитика много, в комментариях, писали тут https://habr.com/ru/articles/741854/, но я считаю, что начинать нужно с профстандарта.
Написали что это не так, а как должно быть не написали. Меня как новичка только запутали, вместо ответа получила философию(
переходим к первым 13 вопросам которые у вас спросят на собеседовании
И вы ответити на них как джун который просто прочитал статьи на хабре :)
На самом деле в большенстве случаев каждый из "первых 13" вопросов раскроется в еще 5. Много чего можно добавить, что могут спросить и спрашивают на собеседованиях, я добавлю немного от себя:
Документирование (нотации моделирования, docAsCode, и т.д.)
БД (типы БД, нормализация, типы связей, транзакции, оконные функции и т.д.)
Интеграции (не только REST, SOAP) - RPC(gRPC), GraphQL, очереди
Если говорить конкретно про REST, то "традиционно" применяют GET, POST. В остальном не плохо бы знать:
что такое PATCH и чем он отличается от PUT
какие методы идемпотентны, а какие нет
как не идемпотентный метод сделать таковым
К каждому из пунктов можно много чего добавить, но чем увереннее и правильнее вы ответите на вышестоящий вопрос интервьюера , тем меньше вытекающих вопросов получите :)
11 Вопрос
Не могу понять, почему все постоянно сравнивают SOAP и REST между собой. Повсюду во всех статьях аля "Что должен уметь аналитик" постоянно сравнивают ложку и верблюда. SOAP - это протокол, а не подход к разработке API. Поставьте меня на правильный путь, если я не прав.
Полезное для начинающего Системного аналитика