Спасибо. Правда я не уверен в полезности для студентов данного подхода, мне казалось это больше для малой коммерции. Хотя я сам на айти не учился, поэтому не уверен чему там учат, просто как мне казалось преподаватели рады если студент в принципе справился с поставленным заданием, а не оценивают удовлетворенность гипотетических пользователей и эффективность оптимизации бизнес-процессов. Но первые три пункта конечно это де-факто стандарт
Цели, задачи и требования к подсистемам, это в некотором роде базис описания, в котором формулируется, что и как должно быть реализовано. А сценарии, они ближе к приемочным испытаниям которые по логике возникают позже, к тому же будет сложно описать как пользоваться системой которая еще не описана. Т.е. в требованиях к подсистемам мы, в том числе, например, описали интерфейс включая кнопки на нем и логику их работы, какие-то сервисы и т.д., и вот уже в сценариях мы пишем что нажали такую-то кнопку, произошло то-то, перешли в другой интерфейс под другим юзером и увидели там какие-то объекты, с опциями и т.д. Конечно нужно понимать что нужно сделать до того как описывать требования к подсистемам, но они все же должны формироваться исходя из задач. Например если у нас есть цель: "автоматизация выпуска эцп" и задачи: "реализовать возможность юзера сделать запрос на выпуск эцп", "интеграция с налоговой в части формирования запроса", "реализовать функционал активации выпущенной эцп юзером" и т.д.. Так вот на основание этого и формируется образ системы, а сценарии фактически уже, в некотором роде, демонстрируют как этим можно будет пользоваться, на сколько это юзабельно и удовлетворяет требованиям. И вот после формирования и анализа сценариев, уже могут быть скорректированы требования к подсистемам. А что касается описания объекта автоматизации, то возможно это уже не столь критично в начале он или в конце, просто я его разместил в конце, т.к. сначала мне хочется узнать что вообще нужно сделать, а потом понять как это интегрировать в существующую систему, и что уже там есть, а не слушать пролог не понимая к чему это все. Хотя возможно на этот счет вы правы. На счет формулировок: задачи, как я понимаю, это как раз то "что мы хотим сделать", описание подсистем уже "как мы хотим это сделать", а вот сценарии уже то "как мы этим планируем пользоваться".
Да, и мне тяжело, но ты не волнуйся. У нас великая страна, мы были первые в космосе, Менделеев изобрел таблицу Менделеева, и хоть мы не научились делать красивые машины, но во многих областях нам нет равных. Мы бы не пропали даже если бы оказались на единственном континенте, окруженном мировым океаном. Нужно только верить друг в друга и поддерживать, не важно где ты, важно кто с тобой рядом.
Все гениальное просто. Очень хорошо если вы понимаете как и зачем это писать, а также описываете требования к подсистемам и именно в такой последовательности, а не просто перечисляете список пожеланий за циферками. Это базис который необходим, но мало кто так делает. А также полезно описать сценарии применения, вот это обычно никто в техническом задание не пишет, даже по ГОСТу, там это появляется уже перед этапом приемки, и называется "программа и методика испытаний". А если включить это в требования, то это будет как "Бритва Оккама", для описания подсистем, и фактически исключит двусмысленность в формулировках. Возможно вы живете в мире где все друг друга понимают, но на практике зачастую, то что говорят, как это понимают и что имелось ввиду, обычно как выясняется разные вещи. И это не для студентов, как вы правильно заметили.
Спасибо обновил. Не сказать что я слежу за изменениями в ГОСТах, а то что указанная РД была отменена, еще не повод не требовать его соблюдать. И как вы понимаете разбираться во всех тонкостях ГОСТов не просто для обывателя, даже если ты имел опыт с ними работать.
На госзаказ могут выйти и небольшие компании, есть даже специальные категории тендеров, только для субъектов МСП. И действительно нет проблемы с ними разобраться. Речь не о том чтобы упразднить применение ГОСТов, там где они сейчас используются. Но в небольших коммерческих контрактах тоже не помешало бы чуть более серьезно относится к техническому описанию.
Это видимо юмор, т.к. это не продукт чтобы им замещать что-то, да и ГОСТы которые я упоминаю наши российские, да и они неплохие впрочем, качество технических заданий на госзаказе вполне приличное. Просто на малобюджетном коммерческом рынке мало кто их придерживается зачастую и технические задания очень абстрактные и сулят большие проблемы при приемке. А тот вариант который я описал может помочь грамотно структурировать ТЗ не вдаваясь в тонкости сложного описания по ГОСТу
Здравствуйте, подскажите а позволяет ли Istio организовать сеть так чтобы можно было подключить один замещающий сервис из выделенного окружения? Поясню что имею ввиду, одно из преимуществ микросервисов что их можно разрабатывать отдельным командам, т.е. группа которая не имеет доступа ко всем проектам и т.д. может писать свой компонент. Но вот как дебажить в таком случае? Себе все не поднять (доступа нет допустим просто у внешней команды к другим проектам). А как то подебажить в процессе разработки в общем окружение было бы полезно. Допустим есть DEV окружение где все сервисы запущены и вот мы хотим подключиться к этой сетке заменив только один сервис и только для определенного клиента. Т.е. чтобы для других команд DEV окружение не изменилось (особенно учитывая что над одним сервисом теоретически могут работать несколько разработчиков одновременно). Т.е. надо как-то создать наследуемую сетку с заменой части конфигурации в зависимости от входной точки. Например есть какой-то сервис который вызывается в середине стека RPC вызовов и вот, надо чтобы в стеке RPC вызовов при запуске через выделенный фронт (team-51.some-service.ru), например который предоставлен root командной, вызывалась копия определенного сервиса (service-x) который запущен на каком-нибудь внешнем узле (service-x.team-51.ru).
Может я не с того края пытаюсь проблему решить, просто как изолированно разрабатывать один микросервис с интеграцией в общее RPC окружение, без поднятия в облаке или локально полной сетки сервисов для каждого разработчика?
Здравствуйте, уточните пожалуйста какую версию «kubernetes federation» вы сравнивали: v1 или v2? Просто похоже что даже 1-я версия (которая уже deprecated) например поддерживает «Federated Secrets», а во второй уже даже поддерживается «Custom Resource Definitions», что подчеркивается в ряде источников. Хочется понимать, если сейчас стартовать multi-dc cluster, — можно уже спокойно использовать «kubernetes federation»?
Относительно PMBoK, PRINCE/PRINCE2 — данные стандарты будут описаны в другой моей статье, посвященной международным и национальным стандартам управления информационными проектами (данную статью, которая посвящена методологиям, назвал так до этого по ошибке, уже переименовал). Что касается связи PMBoK и других стандартов, то если вам будет инересно, есть одно исследование С. Гашика, согласно которому процессы PMBOK на 95 процентов аналогичны описанным в международном стандарте по управлению проектами ISO 21500.
Спасибо за замечание, статья должна называться иначе (переименовал), а «Международные и национальные стандарты управления информационными проектами» называется другая моя статья. Относительно анализа обстоятельств возникновения сложившихся подходов, интересная идея, однако это уже было бы целое исследование, а это раздел из первой (теоретической) главы моей основной работы.
Спасибо. Правда я не уверен в полезности для студентов данного подхода, мне казалось это больше для малой коммерции. Хотя я сам на айти не учился, поэтому не уверен чему там учат, просто как мне казалось преподаватели рады если студент в принципе справился с поставленным заданием, а не оценивают удовлетворенность гипотетических пользователей и эффективность оптимизации бизнес-процессов. Но первые три пункта конечно это де-факто стандарт
Цели, задачи и требования к подсистемам, это в некотором роде базис описания, в котором формулируется, что и как должно быть реализовано. А сценарии, они ближе к приемочным испытаниям которые по логике возникают позже, к тому же будет сложно описать как пользоваться системой которая еще не описана. Т.е. в требованиях к подсистемам мы, в том числе, например, описали интерфейс включая кнопки на нем и логику их работы, какие-то сервисы и т.д., и вот уже в сценариях мы пишем что нажали такую-то кнопку, произошло то-то, перешли в другой интерфейс под другим юзером и увидели там какие-то объекты, с опциями и т.д. Конечно нужно понимать что нужно сделать до того как описывать требования к подсистемам, но они все же должны формироваться исходя из задач. Например если у нас есть цель: "автоматизация выпуска эцп" и задачи: "реализовать возможность юзера сделать запрос на выпуск эцп", "интеграция с налоговой в части формирования запроса", "реализовать функционал активации выпущенной эцп юзером" и т.д.. Так вот на основание этого и формируется образ системы, а сценарии фактически уже, в некотором роде, демонстрируют как этим можно будет пользоваться, на сколько это юзабельно и удовлетворяет требованиям. И вот после формирования и анализа сценариев, уже могут быть скорректированы требования к подсистемам. А что касается описания объекта автоматизации, то возможно это уже не столь критично в начале он или в конце, просто я его разместил в конце, т.к. сначала мне хочется узнать что вообще нужно сделать, а потом понять как это интегрировать в существующую систему, и что уже там есть, а не слушать пролог не понимая к чему это все. Хотя возможно на этот счет вы правы. На счет формулировок: задачи, как я понимаю, это как раз то "что мы хотим сделать", описание подсистем уже "как мы хотим это сделать", а вот сценарии уже то "как мы этим планируем пользоваться".
Боюсь предположить что это должно значить
Да, и мне тяжело, но ты не волнуйся. У нас великая страна, мы были первые в космосе, Менделеев изобрел таблицу Менделеева, и хоть мы не научились делать красивые машины, но во многих областях нам нет равных. Мы бы не пропали даже если бы оказались на единственном континенте, окруженном мировым океаном. Нужно только верить друг в друга и поддерживать, не важно где ты, важно кто с тобой рядом.
Это же был сарказм, или я вас неправильно понял ?
Все гениальное просто. Очень хорошо если вы понимаете как и зачем это писать, а также описываете требования к подсистемам и именно в такой последовательности, а не просто перечисляете список пожеланий за циферками. Это базис который необходим, но мало кто так делает. А также полезно описать сценарии применения, вот это обычно никто в техническом задание не пишет, даже по ГОСТу, там это появляется уже перед этапом приемки, и называется "программа и методика испытаний". А если включить это в требования, то это будет как "Бритва Оккама", для описания подсистем, и фактически исключит двусмысленность в формулировках. Возможно вы живете в мире где все друг друга понимают, но на практике зачастую, то что говорят, как это понимают и что имелось ввиду, обычно как выясняется разные вещи. И это не для студентов, как вы правильно заметили.
Т.е. подчеркну что эта статья не для таких корифеев как вы, а скорее для тех кто в ГОСТы не погружался.
Спасибо обновил. Не сказать что я слежу за изменениями в ГОСТах, а то что указанная РД была отменена, еще не повод не требовать его соблюдать. И как вы понимаете разбираться во всех тонкостях ГОСТов не просто для обывателя, даже если ты имел опыт с ними работать.
Ага, есть такое. Очень много политики, с выраженным негативом если ты хоть немного лояльную, к чему-то российскому, точку зрения озвучил.
Ну извините, видимо мои скромные труды не помогут вам гордиться отчизной. Спасибо за политическую ноту
На госзаказ могут выйти и небольшие компании, есть даже специальные категории тендеров, только для субъектов МСП. И действительно нет проблемы с ними разобраться. Речь не о том чтобы упразднить применение ГОСТов, там где они сейчас используются. Но в небольших коммерческих контрактах тоже не помешало бы чуть более серьезно относится к техническому описанию.
Это видимо юмор, т.к. это не продукт чтобы им замещать что-то, да и ГОСТы которые я упоминаю наши российские, да и они неплохие впрочем, качество технических заданий на госзаказе вполне приличное. Просто на малобюджетном коммерческом рынке мало кто их придерживается зачастую и технические задания очень абстрактные и сулят большие проблемы при приемке. А тот вариант который я описал может помочь грамотно структурировать ТЗ не вдаваясь в тонкости сложного описания по ГОСТу
Может я не с того края пытаюсь проблему решить, просто как изолированно разрабатывать один микросервис с интеграцией в общее RPC окружение, без поднятия в облаке или локально полной сетки сервисов для каждого разработчика?