Об изготовлении программ и ежиках в тумане

2D1A3C8C-2D04-4881-BF35-3F78147D0ABD

По сути, в этой статье я говорю о PLM (Product Lifecycle Management system) в области разработки программных систем. Если задуматься, то мы находимся в ситуации "сапожник без сапог", PLM системы используются для изготовления разных изделий, но не для производства программных систем.

pdf
Имя файла: DE-2019-02-11
Размер файла: 1.1 mb
Скачать файл

Идентификаторы статьи

  • 10.34706/DE-2019-02-11

Читайте также:

 

Комментарии 10

Anatoly Kozyrev в 16.05.2019, 19:16

Спасибо, Алексей!
Не скрою, ждал очередного текста от Вас с нетерпением и надеждой.
В конце июня надеюсь быть в Н-ске, м.б. поговорим.

Спасибо, Алексей! Не скрою, ждал очередного текста от Вас с нетерпением и надеждой. В конце июня надеюсь быть в Н-ске, м.б. поговорим.

Крайне актуальная статья.

Крайне актуальная статья.

Очень актуальная проблема. С одной стороны, вроде бы, софт уже написан и бесплатен, но, с другой стороны, качество его таково, что часто легче написать, а проще и быстрее купить коммерческий аналог.
Что делать?
Может быть 2-3 группы разработчиков, объединив свою репутацию, могли бы … тут возможны варианты. Проще всего, например, сделать присуждаемый за качество знак. Наличие знака у софта значит, что за этот софт (за его качество, полноту его описания и пр.) кто-то отвечает. В случае проблем он обязуется помочь разобраться и, если понадобится, исправить свой софт. Если софт качеством не соответствует, и автор не выполняет - знак отбираем. Каждое успешное использование - повторный знак.
Тогда любой пользователь предпочтет софт с максимальным количеством значков. И заказать разработку у того, кто больше этих знаков набрал … и т.д.

Очень актуальная проблема. С одной стороны, вроде бы, софт уже написан и бесплатен, но, с другой стороны, качество его таково, что часто легче написать, а проще и быстрее купить коммерческий аналог. Что делать? Может быть 2-3 группы разработчиков, объединив свою репутацию, могли бы … тут возможны варианты. Проще всего, например, сделать присуждаемый за качество знак. Наличие знака у софта значит, что за этот софт (за его качество, полноту его описания и пр.) кто-то отвечает. В случае проблем он обязуется помочь разобраться и, если понадобится, исправить свой софт. Если софт качеством не соответствует, и автор не выполняет - знак отбираем. Каждое успешное использование - повторный знак. Тогда любой пользователь предпочтет софт с максимальным количеством значков. И заказать разработку у того, кто больше этих знаков набрал … и т.д.
Алексей Недоря в 17.05.2019, 21:59

Анатолий, поговорить - это здорово, только я давно живу/работаю в Питере, так что в Н-ск встретится никак не смогу

Анатолий, поговорить - это здорово, только я давно живу/работаю в Питере, так что в Н-ск встретится никак не смогу :)
Алексей Недоря в 17.05.2019, 22:02

"Может быть 2-3 группы разработчиков, объединив свою репутацию, могли бы … тут возможны варианты. Проще всего, например, сделать присуждаемый за качество знак" - на мой взгляд тут нужна работа ассоциации производителей ПО или государства. Из статьи я убрал слова по "Центры сертификации" (чтобы не перегружать), но делать что-то в этом направлении надо.

"Может быть 2-3 группы разработчиков, объединив свою репутацию, могли бы … тут возможны варианты. Проще всего, например, сделать присуждаемый за качество знак" - на мой взгляд тут нужна работа ассоциации производителей ПО или государства. Из статьи я убрал слова по "Центры сертификации" (чтобы не перегружать), но делать что-то в этом направлении надо.

Государству я попытался подсказать что делать. Мой опыт - в статье про "предцифровую горячку" здесь же примерно года полтора назад. Если бы я всерьез рассчитывал на реакцию государства, то настаивал бы на тех рекомендациях. но думаю, что 2-3 группы разработчиков белее реально.
А центы сертификации мне не нравятся: т.к. они быстро превратятся в еще одну кормушку для кормежки чиновников.

Государству я попытался подсказать что делать. Мой опыт - в статье про "предцифровую горячку" здесь же примерно года полтора назад. Если бы я всерьез рассчитывал на реакцию государства, то настаивал бы на тех рекомендациях. но думаю, что 2-3 группы разработчиков белее реально. А центы сертификации мне не нравятся: т.к. они быстро превратятся в еще одну кормушку для кормежки чиновников.
Алексей Недоря в 21.05.2019, 19:04

Почему я говорю про Центр сертификации (естественно не государственный и не имеющий право запрешать/разрешать)?

1) Работы много. Чтобы проверить качество, надо иметь свою систему тестирования, независимую от разработчика. Надо уметь проверять качество и адекватность не только кода, но и документации. Надо проверять все интерфейсы на стандартность взаимодействия. И так для каждой новой версии.

2) Чем будут зарабатывать себе на хлеб 2-3 команды разработчиков? У меня нет вариантов. Разве что им будут платят за то, что они такие хорошие , но тогда надо сначала эту "хорошесть" показать/доказать, а для этого нужно много поработать и деньги (catch 22).

На мой взгляд, единственным вариантом может быть некоммерческая ассоциация крупных разработчиков, возможно, с гос. участием, которые вкладывают деньги в независимую сертификацию. Но ассоциация может состоятся только когда крупные разработчики окончательно упрутся в тупик, а пока "все хорошо, прекрасная маркиза".

Добавлю, что стандартизация open source - это малая часть того, что надо сделать для выхода из тумана.

Почему я говорю про Центр сертификации (естественно не государственный и не имеющий право запрешать/разрешать)? 1) Работы много. Чтобы проверить качество, надо иметь свою систему тестирования, независимую от разработчика. Надо уметь проверять качество и адекватность не только кода, но и документации. Надо проверять все интерфейсы на стандартность взаимодействия. И так для каждой новой версии. 2) Чем будут зарабатывать себе на хлеб 2-3 команды разработчиков? У меня нет вариантов. Разве что им будут платят за то, что они такие хорошие :), но тогда надо сначала эту "хорошесть" показать/доказать, а для этого нужно много поработать и деньги (catch 22). На мой взгляд, единственным вариантом может быть некоммерческая ассоциация крупных разработчиков, возможно, с гос. участием, которые вкладывают деньги в независимую сертификацию. Но ассоциация может состоятся только когда крупные разработчики окончательно упрутся в тупик, а пока "все хорошо, прекрасная маркиза". Добавлю, что стандартизация open source - это малая часть того, что надо сделать для выхода из тумана.
Гость - Comdiv в 25.05.2019, 00:08

Алексей, можете привести экономические расчёты предполагаемой модели разработки для разного количества людей, вовлечённых в разработку - от микро до макро уровня?

Алексей, можете привести экономические расчёты предполагаемой модели разработки для разного количества людей, вовлечённых в разработку - от микро до макро уровня?
Гость - Alex в 25.05.2019, 11:34

Отлично! "Agile - это палка для слепого, это технология от бедности и от отчаяния"

Все перечисленные странности - 20+ летней давности.

Почему архитектуру делает "Конструктор"? "описание системы задает архитектуру системы, только не нарисованную, действующую - живую" - вот есть такая -https://bpm.com/blogs/executable-architecture-of-software-defined-enterprises

Отлично! "Agile - это палка для слепого, это технология от бедности и от отчаяния" Все перечисленные странности - 20+ летней давности. Почему архитектуру делает "Конструктор"? "описание системы задает архитектуру системы, только не нарисованную, действующую - живую" - вот есть такая -https://bpm.com/blogs/executable-architecture-of-software-defined-enterprises
Алексей Недоря в 28.05.2019, 14:29

"вот есть такая -https://bpm.com/blogs/executable-architecture-of-software-defined-enterprises"

Посмотрел статью. Интересный подход к частной задаче (Enterprise Management System). Вы предлагаете собрать IT систему по бизнес архитектуре из микросервисов.

Вопрос: А как вы будете решать основные проблемы (не наблюдаемость, сложные и противоречивые настройки/конфигурации, несовместимость, отсутствие стабильных интерфейсов, отсутствие адекватной документации)?

Слова сказаны хорошие, но вот решения за ними я не вижу.

Решения нет, сказал мудрец брадатый.
Другой смолчал и стал пред ним ходить.
Иль все же смог он возразить?

Это было первое возражение, теперь второе и главное. Вы предлагаете (насколько я понял) связать верхней архитектурой набор микросервисов/подсистем. Но если при этом не озаботится устройством и правилами построения самими подсистемами, то мы получим красивую обертку над кучей частей, собранных из говна и палок. Полагаю, что и все система будет скорее г., чем конфеткой.

На мой взгляд, поза "архитектура сверху" не решает задачу. Архитектура должна быть не сверху, а снизу и между. Для лучшего понимания, вместо слова "архитектура" стоит использовать "основа" или "скелет". Сначала надо собирать скелет (без компонент, микросервисов, подсистем), и только потом подключать те части, которые "совместимы" со скелетом. Скелет должен обеспечивать: наблюдаемость, конфигурируемость, отказоустойчивость, расширяемость, масштабируемость и т.п.

Скелет естественно должен быть гибким, и вся система должна изначально строится как максимально гибкая (динамичная), а потом оптимизироваться (там где возможно и в идеале только автоматически).

"вот есть такая -https://bpm.com/blogs/executable-architecture-of-software-defined-enterprises" Посмотрел статью. Интересный подход к частной задаче (Enterprise Management System). Вы предлагаете собрать IT систему по бизнес архитектуре из микросервисов. Вопрос: А как вы будете решать основные проблемы (не наблюдаемость, сложные и противоречивые настройки/конфигурации, несовместимость, отсутствие стабильных интерфейсов, отсутствие адекватной документации)? Слова сказаны хорошие, но вот решения за ними я не вижу. Решения нет, сказал мудрец брадатый. Другой смолчал и стал пред ним ходить. Иль все же смог он возразить? Это было первое возражение, теперь второе и главное. Вы предлагаете (насколько я понял) связать верхней архитектурой набор микросервисов/подсистем. Но если при этом не озаботится устройством и правилами построения самими подсистемами, то мы получим красивую обертку над кучей частей, собранных из говна и палок. Полагаю, что и все система будет скорее г., чем конфеткой. На мой взгляд, поза "архитектура сверху" не решает задачу. Архитектура должна быть не сверху, а снизу и между. Для лучшего понимания, вместо слова "архитектура" стоит использовать "основа" или "скелет". Сначала надо собирать скелет (без компонент, микросервисов, подсистем), и только потом подключать те части, которые "совместимы" со скелетом. Скелет должен обеспечивать: наблюдаемость, конфигурируемость, отказоустойчивость, расширяемость, масштабируемость и т.п. Скелет естественно должен быть гибким, и вся система должна изначально строится как максимально гибкая (динамичная), а потом оптимизироваться (там где возможно и в идеале только автоматически).
Уже зарегистрированы? Войти на сайт
08.10.2024

Подождите минутку, пока генерируется календарь