Послушайте, про конспирологию и про рептилоидов здесь пишете именно вы. Равно, как и про 30-процентную инфляцию.
Я же пишу про то, что некоторые положения вашей статьи и циферки, использованные вами в статье, мягко говоря, притянуты за уши. Фактически, если убрать из статьи воду, ваш основной аргумент - надо верить в цифры Росстата, потому, что более других нет и все "эксперты" и эксперты верят Росстату.
Я просто постараюсь как-то почетче обозначить свой тезис: поводов доверять в циферки Росстата у меня как не было, так и нет. Равно как и в заявления всяких других "Рос-" организаций. Если, например, Роскомнадзор не стесняется врать, то с какой стати я буду верить циферкам Росстата, тем более, что ни у меня, ни у многих моих знакомых эти циферки с реальностью не бьются никак?
В то, что чиновники Росстата, якобы, только собирают и считают циферки, и по шапке им за эти циферки не прилетит - вот совсем не верится. В конце 2018-го главу Росстата как раз таки сняли. И, как говорят, именно что за неудобные циферки. Поставили нового и циферки стали более правильные, видимо.
Для чего занижать официальную инфляцию - я тут уж распинаться не буду, не маленькая, сами знаете.
И, кстати, за 3-ку в Москве я вот прямо сейчас плачу без малого 10 тыр. Не бьются ваши циферки.
Все верно. В юности серьезно занимался лёгкой атлетикой. Так вот, мой тренер говорил: "Чтобы лучше бегать надо больше бегать". Так что, рецепт действительно прост и подходит для любой деятельности.
Требования к содержанию документа и перечню подразделов основных разделов
технического задания регламентируются РД 50-34.698-90
Ой, Екатерина...Боюсь вас огорчить, но РД-шку отменили уже несколько лет назад, да и состав и содержание ТЗ она никогдашеньки не регламентировала, только документы ТП и РД.
По п. 9 "Составление технического задания": зачем изобретать свой собственный велосипед, когда есть ГОСТ 34.602-2020, в котором приведены состав и содержание документа. Необязательно целиком следовать ГОСТу, можно адаптировать под себя.
То же самое относится и к п.13 - есть ГОСТ Р 59795-2021, в котором приведены состав и содержание самых разных документов, разрабатываемых для ИС - берите, адаптируйте под себя и пользуйтесь.
Еще странность - тестирование системы есть, а сдачи/приемки - нет. Сдача/приемка, по опыту, отдельная песня, особенно в случаях, когда у заказчика собственная служба эксплуатации.
ИБ - не включает требования и этапы работ по аттестации ИС.
Можно и еще накидать, но, в общем и целом, получилась этакая смесь 34-ого ГОСТа (ныне ГОСТ Р 59793-2021) и 676-ого ПП. Работать конечно будет, но далеко не для всех систем и не для всех заказчиков.
На моей практике неплохо зарекомендовал себя подход, когда аналитик при разработке логической модели сразу пилит эту модель на "куски" и выделяет в отдельные диаграммы: НСИ, например, рисуем отдельно, управление доступом отдельно, и т.д. "Рисование" ведем в общем инструменте типа EA.
Понятно, что, как правило, решения по "физике" принимаются позже и как правило уже архитектором: сколько и каких будет баз, сколько и каких будет сервисов или будет монолит.
В этом случае, рисование "физики" на последующих этапах упрощается: можно на стадии проектирования делать и монолит и микросервисы, можно разделять по разным базам, можно эти "куски" отдавать в разные команды. При этом, "куски" всегда можно склеить в одну физическую модель БД и сгенерить общий DDL.
Дмитрий, во первых РД 50-34.698-90 не является ГОСТом, во-вторых, он отменен в 2019 году, а в третьих, в этом году вступил в действие ГОСТ Р 59795-2021, вместо этой РД-шки.
Если у вас в одной строке столько неточностей, то и остальное читать, видимо, не стоит.
Валерий, насчет "сегодняшних реалий" вы, пожалуй, погорячились. В ваших реалиях - да, возможно. В моей реальности не попадалось ни одного заказчика, способного сделать вменяемый бизнес-анализ.
Agile - не серебряная пуля, и чем дальше, тем очевидней, что привнося что-то полезное, он создает и новые, дополнительные проблемы. Вы же сами отмечали замечательный аджайл-тезис об отсутствии документации и о проблемах, которые в связи с этим возникают на этапе эксплуатации. Кстати, документация по ГОСТ делается достаточно легко, при любой модели. Проблема аджайла в том, что он ставит телегу - "работающий код" впереди лошади - документированных проектных решений. По такой технологии можно тяп-ляп запилить прототип, но энтерпрайз-система - она же не об этом, ее надо эксплуатировать и развивать потом не один год. А для этого нужна документация.
Что касается бизнес- и системного анализа - в разных организациях это устроено и называется по разному. И потом - мы же не о штатных должностях, а о проектных ролях. Разработка систем - такой же бизнес-процесс, как любой другой. Есть проектные роли, у них есть соответсвующие обязанности, процессы и все такое. В моем мире системный аналитик никогда не делал базы данных, этим занимался DBA, а за его отсутствием - архитектор.
Ну и вобщем, не спора ради - я об организации процесса разработки. Есть процесс, в нем есть роли, у них есть обязанности. Монолит, микросервисы, RESTы/SOAPы - это конкретные технические решения, которые принимаются не за ради модных и красивых слов, а на определенной стадии проекта, в соответствии с определенными - чисто конкретными - требованиями к системе. Ну а требования - они опять же, от бизнес-процессов заказчика. Ни один заказчик (ну мне такие не встречались) не скажет - мне нужна система на микросервисах. Заказчик скажет - мне нужна система, которая должна мне автоматизировать те-то и те-то функции. В-общем, мой пойнт в том, что решает процесс разработки, если он нормально организован, то проблем с применением тех или иных технических решений не возникает, будь то микросервисы, будь то хоть что угодно другое.
Довольно много спорных тезисов. Почему "отмирает" бизнес-архитектура? Почему "отмирает" ГОСТ 19/34 ?
А что такое "архитектура" энтерпрайз-систем вообще? "Микросервисная архитектура" - вообще говоря - и не архитектура вовсе, а так - паттерн, один из многих.
При любом раскладе, начиная разработку информационной системы надо понять для начала, а что, собственно, мы будем автоматизировать? Какие процессы? Для этого и нужен бизнес-анализ деятельности, которую мы собираемся автоматизировать нашей системы. И проводить его будет - бизнес-аналитик.
А дальше, надо эти процессы представить в виде ролей пользователей, функций системы и объектов, которыми эти функции управляют. В нашей парадигме этим занимается как раз системный аналитик.
Дальше - компонентная модель, архитектура данных, архитектура размещения, архитектура интеграции - это уже архитектор.
При таком раскладе по барабану что делать - монолит, микросервисы или гибрид. Просто каждый в проекте отвечает за свой кусок работы. А проджект отвечает за все.
И главное правило : сначала думаем, потом пишем проектную документацию, а потом только кодим. И забываем про аджайл, в период эксплуатации так получается дешевле и быстрее.
Послушайте, про конспирологию и про рептилоидов здесь пишете именно вы. Равно, как и про 30-процентную инфляцию.
Я же пишу про то, что некоторые положения вашей статьи и циферки, использованные вами в статье, мягко говоря, притянуты за уши. Фактически, если убрать из статьи воду, ваш основной аргумент - надо верить в цифры Росстата, потому, что более других нет и все "эксперты" и эксперты верят Росстату.
Я просто постараюсь как-то почетче обозначить свой тезис: поводов доверять в циферки Росстата у меня как не было, так и нет. Равно как и в заявления всяких других "Рос-" организаций. Если, например, Роскомнадзор не стесняется врать, то с какой стати я буду верить циферкам Росстата, тем более, что ни у меня, ни у многих моих знакомых эти циферки с реальностью не бьются никак?
Хорошая попытка, но нет - не убедили.
В то, что чиновники Росстата, якобы, только собирают и считают циферки, и по шапке им за эти циферки не прилетит - вот совсем не верится. В конце 2018-го главу Росстата как раз таки сняли. И, как говорят, именно что за неудобные циферки. Поставили нового и циферки стали более правильные, видимо.
Для чего занижать официальную инфляцию - я тут уж распинаться не буду, не маленькая, сами знаете.
И, кстати, за 3-ку в Москве я вот прямо сейчас плачу без малого 10 тыр. Не бьются ваши циферки.
Все верно. В юности серьезно занимался лёгкой атлетикой. Так вот, мой тренер говорил: "Чтобы лучше бегать надо больше бегать". Так что, рецепт действительно прост и подходит для любой деятельности.
"220 получает, 127 отдает, а на остальное гудит"
Тем более, через Госуслуги
Я бы вот тоже "вышел" бы...Не знаю только куда, а статья таки ответа не дает. Есть же тут те, кто "вышедши" - рассказали бы, как оно там.
В таком случае просьба - освещать вашу борьбу по возможности подробно.
Muti-Edit, на мой взгляд, вообще был шедевром. Всегда предпочитал его, даже несмотря на наличие вышедших уже Turbo- Borland- Quick- и прочих IDE'шек.
Подсветка синтаксиса для любых языков, а писать тогда приходилось на всем - и Pascal и C/C++ и QBasic и Assembler.
Плюс возможность компиляции/сборки не выходя из среды + подключение внешних отладчиков. Шедевр, одним словом.
Выше - это на мотив ВСВ "Был побег на рывок"
А вот еще пара строк под вечер:
Ноут на кармане, я - тимлид в шалмане
Аналитик, с$ка, спеку мне зажал
Был релиз в продуктив
Глупый, глючный, кривой
(да еще и в пятницу вечером)
...
В понедельник братва
Откатила релиз без меня
Ой, Екатерина...Боюсь вас огорчить, но РД-шку отменили уже несколько лет назад, да и состав и содержание ТЗ она никогдашеньки не регламентировала, только документы ТП и РД.
По п. 9 "Составление технического задания": зачем изобретать свой собственный велосипед, когда есть ГОСТ 34.602-2020, в котором приведены состав и содержание документа. Необязательно целиком следовать ГОСТу, можно адаптировать под себя.
То же самое относится и к п.13 - есть ГОСТ Р 59795-2021, в котором приведены состав и содержание самых разных документов, разрабатываемых для ИС - берите, адаптируйте под себя и пользуйтесь.
Еще странность - тестирование системы есть, а сдачи/приемки - нет. Сдача/приемка, по опыту, отдельная песня, особенно в случаях, когда у заказчика собственная служба эксплуатации.
ИБ - не включает требования и этапы работ по аттестации ИС.
Можно и еще накидать, но, в общем и целом, получилась этакая смесь 34-ого ГОСТа (ныне ГОСТ Р 59793-2021) и 676-ого ПП. Работать конечно будет, но далеко не для всех систем и не для всех заказчиков.
Все верно и по делу, автору + за хорошие формулировки.
Не только прототипы.
Вот для такой штуки в конце 80-ых - начале 90-ых в одном СКБ я писал софт.
Можно коллекцию добавить еще например IPX/SPX
На моей практике неплохо зарекомендовал себя подход, когда аналитик при разработке логической модели сразу пилит эту модель на "куски" и выделяет в отдельные диаграммы: НСИ, например, рисуем отдельно, управление доступом отдельно, и т.д. "Рисование" ведем в общем инструменте типа EA.
Понятно, что, как правило, решения по "физике" принимаются позже и как правило уже архитектором: сколько и каких будет баз, сколько и каких будет сервисов или будет монолит.
В этом случае, рисование "физики" на последующих этапах упрощается: можно на стадии проектирования делать и монолит и микросервисы, можно разделять по разным базам, можно эти "куски" отдавать в разные команды. При этом, "куски" всегда можно склеить в одну физическую модель БД и сгенерить общий DDL.
Дмитрий, во первых РД 50-34.698-90 не является ГОСТом, во-вторых, он отменен в 2019 году, а в третьих, в этом году вступил в действие ГОСТ Р 59795-2021, вместо этой РД-шки.
Если у вас в одной строке столько неточностей, то и остальное читать, видимо, не стоит.
Если рекрутерша симпатичная, я бы сыграл в лотерейку
Добрый!
Валерий, насчет "сегодняшних реалий" вы, пожалуй, погорячились. В ваших реалиях - да, возможно. В моей реальности не попадалось ни одного заказчика, способного сделать вменяемый бизнес-анализ.
Agile - не серебряная пуля, и чем дальше, тем очевидней, что привнося что-то полезное, он создает и новые, дополнительные проблемы. Вы же сами отмечали замечательный аджайл-тезис об отсутствии документации и о проблемах, которые в связи с этим возникают на этапе эксплуатации. Кстати, документация по ГОСТ делается достаточно легко, при любой модели. Проблема аджайла в том, что он ставит телегу - "работающий код" впереди лошади - документированных проектных решений. По такой технологии можно тяп-ляп запилить прототип, но энтерпрайз-система - она же не об этом, ее надо эксплуатировать и развивать потом не один год. А для этого нужна документация.
Что касается бизнес- и системного анализа - в разных организациях это устроено и называется по разному. И потом - мы же не о штатных должностях, а о проектных ролях. Разработка систем - такой же бизнес-процесс, как любой другой. Есть проектные роли, у них есть соответсвующие обязанности, процессы и все такое. В моем мире системный аналитик никогда не делал базы данных, этим занимался DBA, а за его отсутствием - архитектор.
Ну и вобщем, не спора ради - я об организации процесса разработки. Есть процесс, в нем есть роли, у них есть обязанности. Монолит, микросервисы, RESTы/SOAPы - это конкретные технические решения, которые принимаются не за ради модных и красивых слов, а на определенной стадии проекта, в соответствии с определенными - чисто конкретными - требованиями к системе. Ну а требования - они опять же, от бизнес-процессов заказчика. Ни один заказчик (ну мне такие не встречались) не скажет - мне нужна система на микросервисах. Заказчик скажет - мне нужна система, которая должна мне автоматизировать те-то и те-то функции. В-общем, мой пойнт в том, что решает процесс разработки, если он нормально организован, то проблем с применением тех или иных технических решений не возникает, будь то микросервисы, будь то хоть что угодно другое.
Довольно много спорных тезисов. Почему "отмирает" бизнес-архитектура? Почему "отмирает" ГОСТ 19/34 ?
А что такое "архитектура" энтерпрайз-систем вообще? "Микросервисная архитектура" - вообще говоря - и не архитектура вовсе, а так - паттерн, один из многих.
При любом раскладе, начиная разработку информационной системы надо понять для начала, а что, собственно, мы будем автоматизировать? Какие процессы? Для этого и нужен бизнес-анализ деятельности, которую мы собираемся автоматизировать нашей системы. И проводить его будет - бизнес-аналитик.
А дальше, надо эти процессы представить в виде ролей пользователей, функций системы и объектов, которыми эти функции управляют. В нашей парадигме этим занимается как раз системный аналитик.
Дальше - компонентная модель, архитектура данных, архитектура размещения, архитектура интеграции - это уже архитектор.
При таком раскладе по барабану что делать - монолит, микросервисы или гибрид. Просто каждый в проекте отвечает за свой кусок работы. А проджект отвечает за все.
И главное правило : сначала думаем, потом пишем проектную документацию, а потом только кодим. И забываем про аджайл, в период эксплуатации так получается дешевле и быстрее.