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

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

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

pdf
Имя файла: Prgmk
Размер файла: 548 kb
Скачать файл

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

 

Комментарии 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 систему по бизнес архитектуре из микросервисов. Вопрос: А как вы будете решать основные проблемы (не наблюдаемость, сложные и противоречивые настройки/конфигурации, несовместимость, отсутствие стабильных интерфейсов, отсутствие адекватной документации)? Слова сказаны хорошие, но вот решения за ними я не вижу. Решения нет, сказал мудрец брадатый. Другой смолчал и стал пред ним ходить. Иль все же смог он возразить? Это было первое возражение, теперь второе и главное. Вы предлагаете (насколько я понял) связать верхней архитектурой набор микросервисов/подсистем. Но если при этом не озаботится устройством и правилами построения самими подсистемами, то мы получим красивую обертку над кучей частей, собранных из говна и палок. Полагаю, что и все система будет скорее г., чем конфеткой. На мой взгляд, поза "архитектура сверху" не решает задачу. Архитектура должна быть не сверху, а снизу и между. Для лучшего понимания, вместо слова "архитектура" стоит использовать "основа" или "скелет". Сначала надо собирать скелет (без компонент, микросервисов, подсистем), и только потом подключать те части, которые "совместимы" со скелетом. Скелет должен обеспечивать: наблюдаемость, конфигурируемость, отказоустойчивость, расширяемость, масштабируемость и т.п. Скелет естественно должен быть гибким, и вся система должна изначально строится как максимально гибкая (динамичная), а потом оптимизироваться (там где возможно и в идеале только автоматически).
Уже зарегистрированы? Войти на сайт
Гость
13.11.2019

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

КОММЕНТАРИИ

Гость - Сергей Ботуз Утопия, антиутопия и квантовые эффекты в экономике внимания (к докладу на Ученом совете ЦЭМИ РАН 18.11.2018)
13 ноября 2019
Экономику будущего следует называть «Экономикой времени и жизненных ресурсов»
Гость - Аппаратно-программный комплекс ... Сетевые (цифровые) стратегии государственного планирования основных процессов защиты и сопровождения субъектов и объектов интеллектуальной собственности
05 ноября 2019
1. Ботуз С.П. Аппаратно-программный комплекс графоаналитического анализа многоспектральных изображений \ Материалы 13-ой научно-техн. конф. «Перспективные технологии в средствах передачи информации – ПТСПИ - 2019» / Владим. гос. универ-ситет, в 2-х т...
Гость - Василий ЦИФРОВАЯ ЭКОНОМИКА: УПРАВЛЕНИЕ КАЧЕСТВОМ ЖИЗНИ ЧЕЛОВЕКА
05 ноября 2019
Статью следовало бы назвать «Будущее управление качеством жизни человека в цифровой экономике». Убрать термин "самоуправление" как ошибочный, так как управлением качеством жизни человека занимаются врач, преподаватель, руководитель (совместно с самим...
Гость - Интеллектуальный рэкет отечественного изобретателя Сетевые (цифровые) стратегии государственного планирования основных процессов защиты и сопровождения субъектов и объектов интеллектуальной собственности
31 октября 2019
Утверждение . Уведомление об отказе (УО) может быть подготовлено патентным – экспертом (ПЭ) так, что специалист в данной предметной области не сможет аргументировано доказать соответствие заявленного ИЗ/ПМ условиям патентоспособности.Док-во. Текст...
Александр Самарин Обсуждаем документ "Государство как платформа"
28 октября 2019
"К сожалению рецензент не дает четких рекомендаций по пересмотру рисков применения документа, хоть и отмечает, что риски возрастут." - для этого надо расписать другую архитектуру
Александр Самарин Обсуждаем документ "Государство как платформа"
28 октября 2019
Рецензия на документ «Государство как платформа» https://www.csr.ru/wp-content/uploads/2018/05/GOSUDARSTVO-KAK-PLATFORMA_internet.pdf
Гость - Дмитрий Обсуждаем документ "Государство как платформа"
27 октября 2019
Не понятно, на что рецензия......??
Гость - Что делать с рисками Обсуждаем документ "Государство как платформа"
27 октября 2019
Рецензия дает возможность осмыслить последствия применения документа как есть или подвергнутого переработке. К сожалению рецензент не дает четких рекомендаций по пересмотру рисков применения документа, хоть и отмечает, что риски возрастут. Действител...