Интересную тут штуку заметил и сформулировал: хотя у ChatGPT есть известная проблема с вычислениями (он трактует числа как текст, разбивая их так же "на слоги", токенизируя), он удивительно хорошо прикидывает.
Например, я несколько раз просил оценить сроки проекта — получалось очень близко к экспертной оценке. Я решил проверить, и взял методику оценки от московского ДИТа — она публично доступна. Методика использует метод функциональных точек с весами и поправочными коэффициентами. Она довольно сложная, и я не стал рассчитывать коэффициент совмещения для должностей, то есть взял максимальную оценку сверху — получилось 38 человеко-месяцев. ChatGPT по описанию проекта дал оценку 6 человек и 4-6 месяцев, то есть 36 человеко-месяцев.
Так же я пробовал спрашивать про оценку рынка — и по известным мне рынкам оценки от ChatGPT хорошо совпадают с отраслевыми отчётами. Возможно, он эти числа из этих же отчетов и берет :)
В случае же с оценками сроков — тут можно объяснить точность самим принципом работы языковой модели — она ведь подставляет статистически вероятный токен, ну вот на базе собранных публикаций эти сроки и есть наиболее вероятные! :)
Например, я несколько раз просил оценить сроки проекта — получалось очень близко к экспертной оценке. Я решил проверить, и взял методику оценки от московского ДИТа — она публично доступна. Методика использует метод функциональных точек с весами и поправочными коэффициентами. Она довольно сложная, и я не стал рассчитывать коэффициент совмещения для должностей, то есть взял максимальную оценку сверху — получилось 38 человеко-месяцев. ChatGPT по описанию проекта дал оценку 6 человек и 4-6 месяцев, то есть 36 человеко-месяцев.
Так же я пробовал спрашивать про оценку рынка — и по известным мне рынкам оценки от ChatGPT хорошо совпадают с отраслевыми отчётами. Возможно, он эти числа из этих же отчетов и берет :)
В случае же с оценками сроков — тут можно объяснить точность самим принципом работы языковой модели — она ведь подставляет статистически вероятный токен, ну вот на базе собранных публикаций эти сроки и есть наиболее вероятные! :)
👍17
Свежая статистика по зарплатам в вакансиях. Вчера как раз зарубились на эту тему на круглом столе на конференции "Анализ & Управление в ИТ проектах" – специализированная конференция 1С-аналитиков, куда меня позвали рассказать про ChatGPT. У 1С сейчас бум – во-первых, проекты стали сложнее, и запросов от бизнеса больше – и на интеграции, и на анализ данных, и на более дружелюбные интерфейсы; во-вторых – многие компании ищут замену SAP. При этом раньше массово такой роли, как аналитик, в 1С не было, а сейчас это очень горячая тема, и ребята активно осваивают все методы, существующие в других областях.
Вчера как раз был круглый стол на тему "откуда брать аналитиков" и чему их учить. Интересно, что разработчиков 1С сейчас гораздо больше, чем аналитиков, и спрос на них меньше, такой вот парадокс. Так что передайте своим знакомым 1С-программистам, пусть приходят к нам учиться методам системного и бизнес-анализа :)
Вчера как раз был круглый стол на тему "откуда брать аналитиков" и чему их учить. Интересно, что разработчиков 1С сейчас гораздо больше, чем аналитиков, и спрос на них меньше, такой вот парадокс. Так что передайте своим знакомым 1С-программистам, пусть приходят к нам учиться методам системного и бизнес-анализа :)
👍8
( Отдельно зафиксирую, что планка в 400 тыс. – это что-то новое, раньше такого вроде не было. Такие суммы обычно готовы платить архитекторам, а не аналитикам. Видимо, спрос на квалифицированные кадры продолжает расти)
👍5❤2
Послушал несколько дискуссий про роль аналитика на проекте, и, кажется, очень часто понимание работы (со стороны руководителей!) сводится к механическим вещам: сколько требований описано, насколько документация процессов или системы соответствует реальности, то есть, аналитик выступает таким механизмом для составления компактного описания системы — "модели" в классическом понимании, как "более простой системы, которая несёт информацию о более сложной системе".
При этом разговор про качество модели почему-то идёт туго, сбиваясь на "описание системы соответствует системе", то есть где-то тут есть неразличение описания и модели. Соответственно, возникает непонимание способов оценки качества работы аналитика. Количественно, по строкам документов? Так их должно быть наоборот меньше — чем выше соотношение "объяснительная сила модели" / "размер модели" — тем лучше. По отзывам от потребителей — чем меньше уточняющих вопросов от программистов / тестировщиков — тем лучше? Хорошая характеристика, но лукавая — может, программист вообще эти постановки не читает, тогда и вопросов не будет :)
Вообще, с точки зрения бизнеса, мне кажется, основная ответственность аналитика — уменьшение двух рисков: 1) что мы сделаем не то, что нужно; 2) что мы не сделаем того, что нужно. Я об этом уже когда-то писал. И метрикой тут становится почти шуточное "количество раз, когда заказчик или архитектор воскликнули: О! Об этом мы как-то не подумали!..". Если, конечно, вы оцениваете этот риск, как высокий, и вообще собираетесь что-то с ним делать. Правда, такой анализ влечет увеличение объема проекта (от 30% до 300% иногда!), но лучше об этом узнать заранее.
Другая распространенная история, когда аналитик транслирует требования в постановки. По сути, делает непонятное понятным. Было непонятно, что делать, теперь стало понятно. Тут возникает неясность: насколько подробной и исчерпывающей должна быть постановка задачи? Нужно ли программисту максимально четко написать, что делать, или достаточно описать общую потребность, а дальше программист уже сам решит? Такие обсуждения тоже были, но ответ обычно "это зависит от многих параметров". От чего конкретно зависит, правда, мало кто говорит. Ну, от опыта программиста зависит. Тут происходит интересная подмена: если аналитик ставит задачу детально, то он уже не аналитик, а проектировщик — он принял решение по тому, как система должна быть сделана, а не по тому, что можно делать при помощи системы. Это происходит незаметно, поэтому и оценить это сложно. И это меня сильно тревожит, так как сутевая часть работы заметается под ковер.
При этом разговор про качество модели почему-то идёт туго, сбиваясь на "описание системы соответствует системе", то есть где-то тут есть неразличение описания и модели. Соответственно, возникает непонимание способов оценки качества работы аналитика. Количественно, по строкам документов? Так их должно быть наоборот меньше — чем выше соотношение "объяснительная сила модели" / "размер модели" — тем лучше. По отзывам от потребителей — чем меньше уточняющих вопросов от программистов / тестировщиков — тем лучше? Хорошая характеристика, но лукавая — может, программист вообще эти постановки не читает, тогда и вопросов не будет :)
Вообще, с точки зрения бизнеса, мне кажется, основная ответственность аналитика — уменьшение двух рисков: 1) что мы сделаем не то, что нужно; 2) что мы не сделаем того, что нужно. Я об этом уже когда-то писал. И метрикой тут становится почти шуточное "количество раз, когда заказчик или архитектор воскликнули: О! Об этом мы как-то не подумали!..". Если, конечно, вы оцениваете этот риск, как высокий, и вообще собираетесь что-то с ним делать. Правда, такой анализ влечет увеличение объема проекта (от 30% до 300% иногда!), но лучше об этом узнать заранее.
Другая распространенная история, когда аналитик транслирует требования в постановки. По сути, делает непонятное понятным. Было непонятно, что делать, теперь стало понятно. Тут возникает неясность: насколько подробной и исчерпывающей должна быть постановка задачи? Нужно ли программисту максимально четко написать, что делать, или достаточно описать общую потребность, а дальше программист уже сам решит? Такие обсуждения тоже были, но ответ обычно "это зависит от многих параметров". От чего конкретно зависит, правда, мало кто говорит. Ну, от опыта программиста зависит. Тут происходит интересная подмена: если аналитик ставит задачу детально, то он уже не аналитик, а проектировщик — он принял решение по тому, как система должна быть сделана, а не по тому, что можно делать при помощи системы. Это происходит незаметно, поэтому и оценить это сложно. И это меня сильно тревожит, так как сутевая часть работы заметается под ковер.
🔥21👍11
Оказывается, сервис, который я проектировал в Московской электронной школе — портфолио учащегося — получил Премию Рунета 2022. Это прямо признание. Теперь у меня один проект в 2016 в шортлисте — "Открытое образование", и один — лауреат. Приятно.
🔥44👏20❤3😱2
На конфе "Анализ & Управление в ИТ-проектах" от Infostart мне очень понравился мастер-класс по ТРИЗ. ТРИЗ часто вспоминают в связи с ИТ, но толком мало кто может рассказать, как его системно применять. Тут тоже не было особо сильной привязки к ИТ, но зато наглядно показано, как сама техника работает, и почему очень важно найти и правильно сформулировать противоречие.
У нас в системном анализе есть фетиш: непротиворечивые требования. Так и в книгах, и в стандартах написано: требования к системе должны быть непротиворечивы. Если они противоречивы, то аналитик плохо выполнил работу. А в ТРИЗе другой подход, вообще противоположный: если вы не нашли противоречивых требований, то вы плохо сделали анализ! Не выявили ключевую проблему.
И ТРИЗ, вместо избегания противоречий или проектирования слабых компромиссных решений предлагает стремиться к такому решению, которое выполняет оба противоречащих условия! Только такие решения становятся прорывными. На мастер-классе предлагалось несколько вариантов рассуждений для выработки таких решений. Например, мне очень понравилась техника "обострение конфликта": вывод значения какого-то показателя далеко за рамки обычного диапазона. Например, противоречие: при торговле на фондовом рынке трейдер должен проанализировать риск сделки, и одновременно должен как можно быстрее сделать сделку, чтобы не упустить выгодные условия. Уведем значение "принятие решения о сделке" в запредельный диапазон, например - миллисекунды. Пусть трейдер принимает решение о сделке за микросекунды, и передает приказ о покупке или продаже за миллисекунды. Понятно, что при такой скорости трейдер не может быть человеком, а объем каждой сделки должен быть крайне небольшим, чтобы снизить риск (в идеале, сделки должны быть вообще безрисковые). Решение называется "высокочастотный трейдинг" (HFT), и сейчас до 40% объема торгов генерируется именно таким методом. Не уверен, что при изобретении HFT применяли ТРИЗ, но решение хорошо иллюстрирует пример рассуждения :)
Тут использованы несколько приемов ТРИЗ:
🔸 разделение конфликта по условию (используем не для всех сделок, а только для безрисковых)
🔸 новый принцип действия (человека заменяем алгоритмом, прошитым на FPGA)
🔸 переход в надсистему (HFT требует организации инфраструктуры со стороны биржи и не имеет смысла для одного трейдера, это услуга сразу для многих)
🔸 разделение конфликта во времени (трейдер заранее продумывает алгоритм принятия решения, а не в момент сделки)
🔸 разделение в пространстве (трейдер сидит в банке, а плата с FPGA устанавливается прямо в сервер биржи, иначе задержки передачи пакетов съедят всё время на принятие решения)
Другие приемы, упомянутые на МК:
🔸 разделение конфликтующих элементов в структуре системы (вот тут я сразу вспомнил DDD - ограничил контексты, и часть конфликтов уже ушла, а микросервисами можно регулировать противоречащие требования к надежности, скорости и безопасности)
🔸 объединение с антисистемой (вот тут не очень придумывается пример из ИТ, если у вас есть - пишите в комментариях)
Говорят, у Альтшуллера - создателя ТРИЗ - была таблица с типовыми техническими противоречиями. Вот бы такую таблицу для ИТ-систем составить. С типовыми же решениями. Чтобы деятельность архитектора из искусства превратить в инженерную практику.
У нас в системном анализе есть фетиш: непротиворечивые требования. Так и в книгах, и в стандартах написано: требования к системе должны быть непротиворечивы. Если они противоречивы, то аналитик плохо выполнил работу. А в ТРИЗе другой подход, вообще противоположный: если вы не нашли противоречивых требований, то вы плохо сделали анализ! Не выявили ключевую проблему.
И ТРИЗ, вместо избегания противоречий или проектирования слабых компромиссных решений предлагает стремиться к такому решению, которое выполняет оба противоречащих условия! Только такие решения становятся прорывными. На мастер-классе предлагалось несколько вариантов рассуждений для выработки таких решений. Например, мне очень понравилась техника "обострение конфликта": вывод значения какого-то показателя далеко за рамки обычного диапазона. Например, противоречие: при торговле на фондовом рынке трейдер должен проанализировать риск сделки, и одновременно должен как можно быстрее сделать сделку, чтобы не упустить выгодные условия. Уведем значение "принятие решения о сделке" в запредельный диапазон, например - миллисекунды. Пусть трейдер принимает решение о сделке за микросекунды, и передает приказ о покупке или продаже за миллисекунды. Понятно, что при такой скорости трейдер не может быть человеком, а объем каждой сделки должен быть крайне небольшим, чтобы снизить риск (в идеале, сделки должны быть вообще безрисковые). Решение называется "высокочастотный трейдинг" (HFT), и сейчас до 40% объема торгов генерируется именно таким методом. Не уверен, что при изобретении HFT применяли ТРИЗ, но решение хорошо иллюстрирует пример рассуждения :)
Тут использованы несколько приемов ТРИЗ:
🔸 разделение конфликта по условию (используем не для всех сделок, а только для безрисковых)
🔸 новый принцип действия (человека заменяем алгоритмом, прошитым на FPGA)
🔸 переход в надсистему (HFT требует организации инфраструктуры со стороны биржи и не имеет смысла для одного трейдера, это услуга сразу для многих)
🔸 разделение конфликта во времени (трейдер заранее продумывает алгоритм принятия решения, а не в момент сделки)
🔸 разделение в пространстве (трейдер сидит в банке, а плата с FPGA устанавливается прямо в сервер биржи, иначе задержки передачи пакетов съедят всё время на принятие решения)
Другие приемы, упомянутые на МК:
🔸 разделение конфликтующих элементов в структуре системы (вот тут я сразу вспомнил DDD - ограничил контексты, и часть конфликтов уже ушла, а микросервисами можно регулировать противоречащие требования к надежности, скорости и безопасности)
🔸 объединение с антисистемой (вот тут не очень придумывается пример из ИТ, если у вас есть - пишите в комментариях)
Говорят, у Альтшуллера - создателя ТРИЗ - была таблица с типовыми техническими противоречиями. Вот бы такую таблицу для ИТ-систем составить. С типовыми же решениями. Чтобы деятельность архитектора из искусства превратить в инженерную практику.
🔥30👍3👏2🆒1
Наша школа расширяется, и мы хотим сохранять практику, когда у нас преподают только опытные аналитики, поэтому сейчас ищем новых тренеров. С нас — обучение приемам ведения, методическое сопровождение, прокачка тренерских скиллов и личного бренда (мы активно записываем вебинары и статьи с нашими ведущими, помогаем с подготовкой выступлений на конференциях). Ну и достойная оплата, само собой, на тренерах мы не экономим. С вас — жгучее желание поделиться своим опытом с коллегами.
Я к объявлению добавлю, что мы развиваем направление интеграций, проектирования и архитектуры (systems design, UX), так что если вы чувствуете себя уверенно в этих областях — приходите делать новые курсы! Писать можно мне или Денису (по ссылке в объявлении).
Я к объявлению добавлю, что мы развиваем направление интеграций, проектирования и архитектуры (systems design, UX), так что если вы чувствуете себя уверенно в этих областях — приходите делать новые курсы! Писать можно мне или Денису (по ссылке в объявлении).
👍7🤔2
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
Ищем тренеров по системному анализу и проектированию
на дистанционную работу
Ищем в команду школы опытных системных аналитиков, которым интересно собственное развитие через обучение других:
— проведение контактных групповых онлайн-занятий в малых группах (до 12-15 человек)
— проверка домашних работ
— разработка учебных материалов (по желанию)
Мы ждём, что вы хорошо знакомы c 3-4 профессиональными темами из:
— классическая инженерия требований
— проектирование взаимодействия в форматах use case и user story
— современные фасилитационные практики Event Storming, Impact Mapping, Story Mapping
— моделирование структур данных и применение SQL
— интеграция информационных систем и проектирование API
— проектирование пользовательских интерфейсов
учебные курсы, которые надо вести:
— Системный анализ и Разработка требований в ИТ-проектах
— Systems Analyst Bootcamp
— Проектирование интеграций через брокеры сообщений
основное время проведения занятий
— суббота и воскресенье с 10 до 14 мск
загрузка от 8 до 24 часов в месяц по договорённости
пишите о себе Денису @beskov
на дистанционную работу
Ищем в команду школы опытных системных аналитиков, которым интересно собственное развитие через обучение других:
— проведение контактных групповых онлайн-занятий в малых группах (до 12-15 человек)
— проверка домашних работ
— разработка учебных материалов (по желанию)
Мы ждём, что вы хорошо знакомы c 3-4 профессиональными темами из:
— классическая инженерия требований
— проектирование взаимодействия в форматах use case и user story
— современные фасилитационные практики Event Storming, Impact Mapping, Story Mapping
— моделирование структур данных и применение SQL
— интеграция информационных систем и проектирование API
— проектирование пользовательских интерфейсов
учебные курсы, которые надо вести:
— Системный анализ и Разработка требований в ИТ-проектах
— Systems Analyst Bootcamp
— Проектирование интеграций через брокеры сообщений
основное время проведения занятий
— суббота и воскресенье с 10 до 14 мск
загрузка от 8 до 24 часов в месяц по договорённости
пишите о себе Денису @beskov
По поводу одного из предыдущих постов возникла дискуссия про зрелость программной архитектуры, как инженерной дисциплины. Тема крайне дискуссионная и требует более подробного анализа, но вот что я вспомнил. Сейчас общее место для архитектуры - стили и паттерны. Мы говорим про тактические паттерны DDD, паттерны интеграций приложений, паттерны объектно-ориентированных языков. Даже популярная тема systems design обсуждается в виде типовых решений и шаблонов. Обычно разговор про паттерны возводят к книге Кристофера Александера "Язык шаблонов", но ещё немного раньше - в конце XVII - начале XVIII века - жил в Швеции гениальный механик и преподаватель Кристофер Полхем. Он для своего времени был пионером - например, спроектировал и построил фабрику, автоматически производившую несколько (!) видов товаров (это ещё до паровых двигателей, на воде, как мельница!). Его называли "северным Дедалом".
Так вот Полхем в образовательных целях собрал так называемый "Механический алфавит" - набор узлов, из которых можно собрать любой механизм. Сейчас бы это назвали "паттерны проектирования механизмов", но такого предмета в современных университетах нет, есть "теория машин и механизмов", разработанная и математически обоснованная на 100 лет позже, в середине XIX в., во многом стараниями русского учёного Чебышёва, который сам был как раз математиком. Так что у нас в проектировании систем пока уровень паттернов, "архитектурного алфавита", дисциплина ждёт своего Чебышёва.
А "Механический алфавит" можно увидеть в Национальном музее науки и технологий в Швеции, ну или на сайте: https://digitaltmuseum.se/search/?q=mekaniskt+alfabet
Это вам не книжка, это настоящие физические деревянные модели!
Так вот Полхем в образовательных целях собрал так называемый "Механический алфавит" - набор узлов, из которых можно собрать любой механизм. Сейчас бы это назвали "паттерны проектирования механизмов", но такого предмета в современных университетах нет, есть "теория машин и механизмов", разработанная и математически обоснованная на 100 лет позже, в середине XIX в., во многом стараниями русского учёного Чебышёва, который сам был как раз математиком. Так что у нас в проектировании систем пока уровень паттернов, "архитектурного алфавита", дисциплина ждёт своего Чебышёва.
А "Механический алфавит" можно увидеть в Национальном музее науки и технологий в Швеции, ну или на сайте: https://digitaltmuseum.se/search/?q=mekaniskt+alfabet
Это вам не книжка, это настоящие физические деревянные модели!
🔥15👍4
Элементы "Механического алфавита", Кристофер Полхем, эскизы моделей, паттерны организации пространства Кристофера Александера.
❤5👍3
Не смог в этом году поехать на ЛАФ, но пристально слежу за докладами (и читаю обзоры Макса Цепкова, большое ему спасибо!). Всегда очень интересно — про что говорит сообщество, какие темы актуальны.
Встретил упоминание доклада "Практические подходы к измерению KPI аналитиков на Agile-проектах", и тут у меня прямо всё встрепенулось! KPI и Agile в одном предложении! Тут, как говорится, или крестик снимите, или трусы наденьте. Из разных миров слова. Или уж KPI и прочие корпоративные радости, или agile с самоорганизующимися командами и самоулучшающимся процессом, уважением к способу работы команды и фокусом на поставке бизнес-ценности.
А работа по спринтам — это ещё не agile, это просто способ организации работ короткими итерациями, при чем тут agile. Из него, наоборот, ту ещё соковыжималку можно сделать при желании.
Интересно, конечно, будет сам доклад посмотреть — что там автор про KPI думает и про Agile. А у вас, дорогие читатели, какой опыт?
Встретил упоминание доклада "Практические подходы к измерению KPI аналитиков на Agile-проектах", и тут у меня прямо всё встрепенулось! KPI и Agile в одном предложении! Тут, как говорится, или крестик снимите, или трусы наденьте. Из разных миров слова. Или уж KPI и прочие корпоративные радости, или agile с самоорганизующимися командами и самоулучшающимся процессом, уважением к способу работы команды и фокусом на поставке бизнес-ценности.
А работа по спринтам — это ещё не agile, это просто способ организации работ короткими итерациями, при чем тут agile. Из него, наоборот, ту ещё соковыжималку можно сделать при желании.
Интересно, конечно, будет сам доклад посмотреть — что там автор про KPI думает и про Agile. А у вас, дорогие читатели, какой опыт?
👍6🔥2❤1
К вопросу про инженерные практики. Несомненно, одним из признаков инженерной деятельности, кроме справочников, являются стандарты. И по требованиям, конструированию и архитектурному проектированию систем стандарты как раз есть, и даже много. Причем не только ГОСТ 34 родом из 70-х, который только состав документов регламентирует (и который, вообще говоря, очень хорош, как чек-лист, если вы проектируете в целом систему, а не только ПО). Есть и более современные и интересные стандарты.
Например, ГОСТ Р 59795-2021, заменяющий старый РД 50-34.698-90, в котором указано - что именно писать в разных документах, про которые рассказывает ГОСТ 34.201-2020 и, в частности, именно про документ Технического задания по ГОСТ 34.602-2020. Там, конечно, свой язык, и не всегда можно догадаться, что "Схема функциональной структуры" - это контекстная диаграмма + диаграмма контейнеров из модной C4model, "Ведомость покупных изделий" по сути является списком зависимостей, а "распределение действий между персоналом и техническими средствами при возникновении различных ситуаций при решении задачи (комплекса задач)" мы сейчас называем use case'ом.
Но есть и более крутые стандарты! Например, горячо любимый мной ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. Меня часто спрашивают про книги, а я сам уже давно почти никаких книг не читаю, разве что по архитектуре (по ней пока мало стандартов). Я читаю стандарты и руководства, да ещё научные статьи. И по инженерии требований рекомендую в первую очередь ISO 29148 и Руководство по написанию требований от INCOSE. К сожалению, найти их в свободном доступе довольно сложно (если вы инженер, то вам компания этот стандарт купит за какие-то там жалкие 208 CHF). К счастью, пару недель назад Константин Валеев сделал прекрасный обзор этого стандарта на канале моего коллеги по Школе системного анализа и проектирования: https://www.youtube.com/live/H71XEhXBsHY
Эти два документа - стандарт и руководство - единственные из известных мне говорят о том, как же, всё-таки, писать требования, а не просто о чём их писать. Какие формулировки использовать. Как управлять требованиями, какие у них есть атрибуты, и что писать в сами требования, а что в атрибуты. Как отличить качественные требования, и что вообще означает "качество" применительно к требованиям. На русский язык этот стандарт не переведен (в отличие от Руководства, которое, впрочем не так-то просто купить, хотя оно на русском как раз есть, я даже немного участвовал в его переводе).
Зато на русском есть удивительный ГОСТ Р 59194―2020. Это стандарт представляет перевод некоторой части ISO 29148, касающуюся как раз формулировок и атрибутов требований (впервые на русском!). Например, там есть пункт "Каждое требование должно быть уникально идентифицировано для обеспечения прослеживаемости в ходе разработки. Уникальный идентификатор требования не изменяется в ходе ЖЦ объекта, в том числе при внесении изменений
в требование.", что, по сравнению с ГОСТом 34 невероятный прогресс! (Ссылки на ГОСТы 34 серии там присутствуют, так что можно использовать их совместно, и перестать жаловаться на "морально устаревший" ГОСТ 34).
Да что там, в этом стандарте даже есть разделение на исходные и проектные требования: "Для разрабатываемых объектов на основании утвержденной спецификации исходных требований разрабатывают спецификацию проектных требований, обусловленных принятыми при проектировании и в результате анализа исходных требований техническими решениями.", что совсем прекрасно! Та самая тема, о которой я давно говорю: как только вы принимаете какое-то техническое решение - например, "данные будут выводиться в виде таблицы" - тут же возникает целый куст новых требований, связанных с таблицей (перенос строк, отображение изображений и значков в ячейках таблицы, возможность сортировки и фильтрации, изменения ширины, скрытия и перестановки столбцов, и т.д. - требования, которые не возникли бы, если бы для вывода использовался другой способ).
Например, ГОСТ Р 59795-2021, заменяющий старый РД 50-34.698-90, в котором указано - что именно писать в разных документах, про которые рассказывает ГОСТ 34.201-2020 и, в частности, именно про документ Технического задания по ГОСТ 34.602-2020. Там, конечно, свой язык, и не всегда можно догадаться, что "Схема функциональной структуры" - это контекстная диаграмма + диаграмма контейнеров из модной C4model, "Ведомость покупных изделий" по сути является списком зависимостей, а "распределение действий между персоналом и техническими средствами при возникновении различных ситуаций при решении задачи (комплекса задач)" мы сейчас называем use case'ом.
Но есть и более крутые стандарты! Например, горячо любимый мной ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. Меня часто спрашивают про книги, а я сам уже давно почти никаких книг не читаю, разве что по архитектуре (по ней пока мало стандартов). Я читаю стандарты и руководства, да ещё научные статьи. И по инженерии требований рекомендую в первую очередь ISO 29148 и Руководство по написанию требований от INCOSE. К сожалению, найти их в свободном доступе довольно сложно (если вы инженер, то вам компания этот стандарт купит за какие-то там жалкие 208 CHF). К счастью, пару недель назад Константин Валеев сделал прекрасный обзор этого стандарта на канале моего коллеги по Школе системного анализа и проектирования: https://www.youtube.com/live/H71XEhXBsHY
Эти два документа - стандарт и руководство - единственные из известных мне говорят о том, как же, всё-таки, писать требования, а не просто о чём их писать. Какие формулировки использовать. Как управлять требованиями, какие у них есть атрибуты, и что писать в сами требования, а что в атрибуты. Как отличить качественные требования, и что вообще означает "качество" применительно к требованиям. На русский язык этот стандарт не переведен (в отличие от Руководства, которое, впрочем не так-то просто купить, хотя оно на русском как раз есть, я даже немного участвовал в его переводе).
Зато на русском есть удивительный ГОСТ Р 59194―2020. Это стандарт представляет перевод некоторой части ISO 29148, касающуюся как раз формулировок и атрибутов требований (впервые на русском!). Например, там есть пункт "Каждое требование должно быть уникально идентифицировано для обеспечения прослеживаемости в ходе разработки. Уникальный идентификатор требования не изменяется в ходе ЖЦ объекта, в том числе при внесении изменений
в требование.", что, по сравнению с ГОСТом 34 невероятный прогресс! (Ссылки на ГОСТы 34 серии там присутствуют, так что можно использовать их совместно, и перестать жаловаться на "морально устаревший" ГОСТ 34).
Да что там, в этом стандарте даже есть разделение на исходные и проектные требования: "Для разрабатываемых объектов на основании утвержденной спецификации исходных требований разрабатывают спецификацию проектных требований, обусловленных принятыми при проектировании и в результате анализа исходных требований техническими решениями.", что совсем прекрасно! Та самая тема, о которой я давно говорю: как только вы принимаете какое-то техническое решение - например, "данные будут выводиться в виде таблицы" - тут же возникает целый куст новых требований, связанных с таблицей (перенос строк, отображение изображений и значков в ячейках таблицы, возможность сортировки и фильтрации, изменения ширины, скрытия и перестановки столбцов, и т.д. - требования, которые не возникли бы, если бы для вывода использовался другой способ).
YouTube
Константин Валеев. Управление требованиями по ISO/IEEE-29148: обзор действующего стандарта
На этом вебинаре, мы посмотрим на стандарт IEEE-29148 Requirements engineering — это актуальный стандарт по управлению требованиями, с которым должен быть знаком каждый системный аналитик.
Разберемся, какие темы он покрывает, чем может быть полезен аналитику…
Разберемся, какие темы он покрывает, чем может быть полезен аналитику…
👍11🔥7❤1
Стандарт также (наконец-то!) вводит шаблон формулировки требования: [Условие]Субъект,Действие,Объект[Значение/Ограничение].
Кроме того, постулируется, что требования включаются в документацию конфигурации, и управление ими происходит по правилам ГОСТ Т Р 59193–2020 (Управление конфигурацией). Это тоже замечательно, потому что там есть, например, такое понятие, как "класс изменения конфигурации" и процедуры, которые нужно исполнить при изменении конфигурации. Приятно, что все эти стандарты на русском, и доступны на сайте ТК482 (см. в ветке обсуждения прямые ссылки)
Кроме того, постулируется, что требования включаются в документацию конфигурации, и управление ими происходит по правилам ГОСТ Т Р 59193–2020 (Управление конфигурацией). Это тоже замечательно, потому что там есть, например, такое понятие, как "класс изменения конфигурации" и процедуры, которые нужно исполнить при изменении конфигурации. Приятно, что все эти стандарты на русском, и доступны на сайте ТК482 (см. в ветке обсуждения прямые ссылки)
🔥10
По нашим опросам, одна из самых неинтересных аналитикам тем — это технические средства и протоколы передачи информации. Ну вот эти все процессоры, память, диски, каналы, все эти железяки. Грустный физический мир со своими физическими ограничениями, которые вносят несовершенство в идеальные логические модели (при построении физической модели БД происходит денормализация, какой ужас!)
Вторая скучная тема — НФТ, нефункциональные требования. Они связаны и понятным образом опираются на физические ограничения. Но это такая техника, не хочется с этим разбираться. Ещё традиционно нелюбимые темы — безопасность и мониторинг. Зато самая востребованная тема среди аналитиков — архитектура и микросервисы! Очень все хотят про это знать. Вот ведь парадокс.
А вот и картинка про типичные заблуждения о работе распределенных систем. Для архитекторов.
1) Сеть и её компоненты никогда не падают
2) Задержек при передачи по сети не существует
3) Ширина канала бесконечна
4) Сеть абсолютно безопасна
5) Топология сети никогда не меняется
6) Есть только один администратор
7) Расходов на передачу информации не существует
8) Сеть гомогенна (все устройства в сети одинаковы)
Даже среди архитекторов, похоже, эти заблуждения распространены. Как же вы собираетесь проектировать такие системы, не вникая в детали передачи и обработки данных?
Вторая скучная тема — НФТ, нефункциональные требования. Они связаны и понятным образом опираются на физические ограничения. Но это такая техника, не хочется с этим разбираться. Ещё традиционно нелюбимые темы — безопасность и мониторинг. Зато самая востребованная тема среди аналитиков — архитектура и микросервисы! Очень все хотят про это знать. Вот ведь парадокс.
А вот и картинка про типичные заблуждения о работе распределенных систем. Для архитекторов.
1) Сеть и её компоненты никогда не падают
2) Задержек при передачи по сети не существует
3) Ширина канала бесконечна
4) Сеть абсолютно безопасна
5) Топология сети никогда не меняется
6) Есть только один администратор
7) Расходов на передачу информации не существует
8) Сеть гомогенна (все устройства в сети одинаковы)
Даже среди архитекторов, похоже, эти заблуждения распространены. Как же вы собираетесь проектировать такие системы, не вникая в детали передачи и обработки данных?
🔥15👍3🥰3