Сообщение Re[29]: Элита! от 24.08.2018 16:31
Изменено 24.08.2018 16:37 vdimas
Re[29]: Элита!
Здравствуйте, IB, Вы писали:
IB>Я ничего не определял, я сделал логический вывод о том, что из одного не обязятельно следует другое. Поскольку, повторюсь, работа в команде над научным проектом и работа над коммерческим это совершенно разный опыт, так как цели другие.
Смотрю и молчание продолжается, и в плане формулировок на этой итерации еще сложности, продолжаются слова общего плана. ))
Что помешало в двух словах описать те тонкости "алгоритма промышленной разработки", про который намекаете ты и НС?
Что мешает мне описать ВАШИ алгоритмы — понятно, в случае чего, мол, это я за вас расписался и будет удобно обвинить меня в разговоре с голосами в голове.
Но так-то вы каждый уже в течении 3-х постов, хоть и туманно, но намекали, например, вот на такое вполне известное происходящее:
— от заказчика постоянно приходят хотелки, которые трансформируются в уточнения требований;
— разработка получается итеративной, версии выходят регулярно и не патамушта багфикс, а потому еще, что аж новые фичи и при этом крайне желательно, чтобы старые фичи не отвалились.
(4-й курс профильного ВУЗ-а по дисциплине "системы/комплексы" — описание одного из этапов жизненного цикла системы)
Я ХЗ почему НС дважды делал вид, что такой характер разработки зело уникальный, а его оппонент и вовсе "всё равно не поймёт". ))
Наша контора тоже выпускает обновления каждую неделю, обычно более чем для одного продукта (т.е. редкая неделя без обновлений) и в 99.9% это новые фичи, а не багфиксы.
Но фиг с ним.
Разумеется, тут упомянута лишь малая часть процесса, но коль вы намекали именно на эту часть, то пару слов о ней:
Это классика жанра. ТЧК.
Итерации, уточнение требований на каждой итерации, поддержка регрессией сверху, планирование итераций, организация условий их осуществления, контроль/верификация достигнутых результатов и т.д..
Такой характер работ прямо предписывается на всех этапах разработки сложных комплексов.
Т.е. даже начиная с эксизного проекта.
И даже со стадии постановки задачи.
Взять обсуждаемые рядом самолёты и движки.
Вот их разрабатывают по 10 лет.
Почему?
Казалось бы, нарисовал и готово.
Дудки.
Такая же точно итеративность и даже период итераций зачастую близок.
Рекомендуется длительность итерации от 2-х недель до 2-х месяцев.
Каждая команда в большом проекте реализует требования, выкатывает свою часть.
Иногда просто теоретическую или 3D (зависит от стадии проекта).
Далее продолжает работу над следующей итерацией, одновременно с этим на уровне интеграции или самого что ни есть академического матана/исследований гоняется текущий результат. К началу следующей итерации готовы уточнённые требования. И так по кругу несколько лет. Когда доходят до "железной" части — аналогично. Когда отлаживают технологию производства — тоже. Всегда происходит одно и то же.
Или взять даже советский "шаблон" не на коробочный проект, а на проект-заказуху:
http://it-gost.ru/content/view/56/40
Но это же относится и к серийному продукту и к софтовой "коробке".
В разных по характеру проектах по-разному распределены роли, вот в чём отличие.
Ключевая роли — это роли источника функциональных и нефункциональных требований и роли контролирующего органа.
И назови ты их как хочешь, хоть даже исключтельно английскими аббревиатурами, смысл не поменяется. ))
Поэтому, вот всё, на что НС глубокомысленно намекал, но так и не сформулировал — это обязательная часть процесса разработки любых более-менее сложных систем.
Итого.
Какой бы аспект происходящего (из десятков их) вы не взяли из своей разработки — ничего уникального там нет.
Абсолютно любой происходящий у вас аспект разработки в нынешней ли её испостаси, или "как оно было 5 лет назад" — не важно, всё это хорошо известные и разобранные до уровня молекул вещи.
И это я еще не прошёлся по принципам проектирования сложных систем.
А то тоже порой слышу "в реальном продакшене всё по-другому".
Святая простота. ))
IB>Да, я уже понял, что настоящих системотехников готовят только в севастпольском политехе, и выпускники МГУ, Физтеха, МИФИ, Бауманки и НГУ им в подметки не годяться
Я говорил лишь, что конкретно ты не системотехник по образованию.
Других сюда не вплетай.
Что касается системотехников, то они вообще поголовно свалили из страны сразу же после ВУЗ-а, бо их отрывали тогда с руками и ногами.
Ты ж вспомни, времена тогда были не настолько софтовые-высокоуровневые как сегодня.
Тогда ЛЮБАЯ более-менее серьёзная разработка содержала в себе до 70% (минимум) объема "платформенного" или, если угодно, "ядерного" кода.
Сейчас весь такой код дан "откуда-то сверху" и почти всегда на сейчас даром.
Взять для примера 1С (работает там один из одногруппников, т.е. не "мальчик одинэсник", а именно разрабатывает её), в этом продукте хорошо заметно разделение на "ядро" и "остальное" — такое разделение прямо в конторе, и оно именно так и обзывается.
IB>ко мне до сих пор по этим статьям приходят и просят проконсультировать, значит не зря писал.
Боже упаси мне сказать, что зря писал.
Это направление нужное и важное, ес-но.
РЕчь о том, что ты опять как-то по-странному отметился по такому направлению, на которое не натаскивался.
Это бросается в глаза.
При этом малость не с той стороны зашёл, т.е. опять блокируешь, собсно, сам обмен опытом.
Так-то со стороны если, твоё желание участвовать в обсуждениях подобных тем выдаёт здоровое любопытство прожённого технаря и мне даже где-то странно, что у тебя случилась малость другая специализация по-жизни. Без сарказма.
Cтатьи твои, если начистоту, написаны в хорошо знакомом мне ключе.
Сплошное де жа вю.
По складу ума ты тот самый технарь, роющий самую суть вещей, из которого только и может получиться грамотный аналитик.
Из других не получается обычно, они всегда на пол-дороге где-то застревают. ))
Просто, блин, потрачена эта "манна" была на такую тему... это как микроскопом гвозди забивать.
IB>Я ничего не определял, я сделал логический вывод о том, что из одного не обязятельно следует другое. Поскольку, повторюсь, работа в команде над научным проектом и работа над коммерческим это совершенно разный опыт, так как цели другие.
Смотрю и молчание продолжается, и в плане формулировок на этой итерации еще сложности, продолжаются слова общего плана. ))
Что помешало в двух словах описать те тонкости "алгоритма промышленной разработки", про который намекаете ты и НС?
Что мешает мне описать ВАШИ алгоритмы — понятно, в случае чего, мол, это я за вас расписался и будет удобно обвинить меня в разговоре с голосами в голове.
Но так-то вы каждый уже в течении 3-х постов, хоть и туманно, но намекали, например, вот на такое вполне известное происходящее:
— от заказчика постоянно приходят хотелки, которые трансформируются в уточнения требований;
— разработка получается итеративной, версии выходят регулярно и не патамушта багфикс, а потому еще, что аж новые фичи и при этом крайне желательно, чтобы старые фичи не отвалились.
(4-й курс профильного ВУЗ-а по дисциплине "системы/комплексы" — описание одного из этапов жизненного цикла системы)
Я ХЗ почему НС дважды делал вид, что такой характер разработки зело уникальный, а его оппонент и вовсе "всё равно не поймёт". ))
Наша контора тоже выпускает обновления каждую неделю, обычно более чем для одного продукта (т.е. редкая неделя без обновлений) и в 99.9% это новые фичи, а не багфиксы.
Но фиг с ним.
Разумеется, тут упомянута лишь малая часть процесса, но коль вы намекали именно на эту часть, то пару слов о ней:
Это классика жанра. ТЧК.
Итерации, уточнение требований на каждой итерации, поддержка регрессией сверху, планирование итераций, организация условий их осуществления, контроль/верификация достигнутых результатов и т.д..
Такой характер работ прямо предписывается на всех этапах разработки сложных комплексов.
Т.е. даже начиная с эксизного проекта.
И даже со стадии постановки задачи.
Взять обсуждаемые рядом самолёты и движки.
Вот их разрабатывают по 10 лет.
Почему?
Казалось бы, нарисовал и готово.
Дудки.
Такая же точно итеративность и даже период итераций зачастую близок.
Рекомендуется длительность итерации от 2-х недель до 2-х месяцев.
Каждая команда в большом проекте реализует требования, выкатывает свою часть.
Иногда просто теоретическую или 3D (зависит от стадии проекта).
Далее продолжает работу над следующей итерацией, одновременно с этим на уровне интеграции или самого что ни есть академического матана/исследований гоняется текущий результат. К началу следующей итерации готовы уточнённые требования. И так по кругу несколько лет. Когда доходят до "железной" части — аналогично. Когда отлаживают технологию производства — тоже. Всегда происходит одно и то же.
Или взять даже советский "шаблон" не на коробочный проект, а на проект-заказуху:
http://it-gost.ru/content/view/56/40
в зависимости от условий создания АС возможны различные совмещения функций заказчика, разработчика, поставщика и других организаций, участвующих в работах по созданию АС
Но это же относится и к серийному продукту и к софтовой "коробке".
В разных по характеру проектах по-разному распределены роли, вот в чём отличие.
Ключевая роли — это роли источника функциональных и нефункциональных требований и роли контролирующего органа.
И назови ты их как хочешь, хоть даже исключтельно английскими аббревиатурами, смысл не поменяется. ))
Поэтому, вот всё, на что НС глубокомысленно намекал, но так и не сформулировал — это обязательная часть процесса разработки любых более-менее сложных систем.
Итого.
Какой бы аспект происходящего (из десятков их) вы не взяли из своей разработки — ничего уникального там нет.
Абсолютно любой происходящий у вас аспект разработки в нынешней ли её испостаси, или "как оно было 5 лет назад" — не важно, всё это хорошо известные и разобранные до уровня молекул вещи.
И это я еще не прошёлся по принципам проектирования сложных систем.
А то тоже порой слышу "в реальном продакшене всё по-другому".
Святая простота. ))
IB>Да, я уже понял, что настоящих системотехников готовят только в севастпольском политехе, и выпускники МГУ, Физтеха, МИФИ, Бауманки и НГУ им в подметки не годяться
Я говорил лишь, что конкретно ты не системотехник по образованию.
Других сюда не вплетай.
Что касается системотехников, то они вообще поголовно свалили из страны сразу же после ВУЗ-а, бо их отрывали тогда с руками и ногами.
Ты ж вспомни, времена тогда были не настолько софтовые-высокоуровневые как сегодня.
Тогда ЛЮБАЯ более-менее серьёзная разработка содержала в себе до 70% (минимум) объема "платформенного" или, если угодно, "ядерного" кода.
Сейчас весь такой код дан "откуда-то сверху" и почти всегда на сейчас даром.
Взять для примера 1С (работает там один из одногруппников, т.е. не "мальчик одинэсник", а именно разрабатывает её), в этом продукте хорошо заметно разделение на "ядро" и "остальное" — такое разделение прямо в конторе, и оно именно так и обзывается.
IB>ко мне до сих пор по этим статьям приходят и просят проконсультировать, значит не зря писал.
Боже упаси мне сказать, что зря писал.
Это направление нужное и важное, ес-но.
РЕчь о том, что ты опять как-то по-странному отметился по такому направлению, на которое не натаскивался.
Это бросается в глаза.
При этом малость не с той стороны зашёл, т.е. опять блокируешь, собсно, сам обмен опытом.
Так-то со стороны если, твоё желание участвовать в обсуждениях подобных тем выдаёт здоровое любопытство прожённого технаря и мне даже где-то странно, что у тебя случилась малость другая специализация по-жизни. Без сарказма.
Cтатьи твои, если начистоту, написаны в хорошо знакомом мне ключе.
Сплошное де жа вю.
По складу ума ты тот самый технарь, роющий самую суть вещей, из которого только и может получиться грамотный аналитик.
Из других не получается обычно, они всегда на пол-дороге где-то застревают. ))
Просто, блин, потрачена эта "манна" была на такую тему... это как микроскопом гвозди забивать.
Re[29]: Элита!
Здравствуйте, IB, Вы писали:
IB>Я ничего не определял, я сделал логический вывод о том, что из одного не обязятельно следует другое. Поскольку, повторюсь, работа в команде над научным проектом и работа над коммерческим это совершенно разный опыт, так как цели другие.
Смотрю и молчание продолжается, и в плане формулировок на этой итерации еще сложности, продолжаются слова общего плана. ))
Что помешало в двух словах описать те тонкости "алгоритма промышленной разработки", про который намекаете ты и НС?
Что мешает мне описать ВАШИ алгоритмы — понятно, в случае чего, мол, это я за вас расписался и будет удобно обвинить меня в разговоре с голосами в голове.
Но так-то вы каждый уже в течении 3-х постов, хоть и туманно, но намекали, например, вот на такое вполне известное происходящее:
— от заказчика постоянно приходят хотелки, которые трансформируются в уточнения требований;
— разработка получается итеративной, версии выходят регулярно и не патамушта багфикс, а потому еще, что аж новые фичи и при этом крайне желательно, чтобы старые фичи не отвалились.
(4-й курс профильного ВУЗ-а по дисциплине "системы/комплексы" — описание одного из этапов жизненного цикла системы)
Я ХЗ почему НС дважды делал вид, что такой характер разработки зело уникальный, а его оппонент и вовсе "всё равно не поймёт". ))
Наша контора тоже выпускает обновления каждую неделю, обычно более чем для одного продукта (т.е. редкая неделя без обновлений) и в 99.9% это новые фичи, а не багфиксы.
Но фиг с ним.
Разумеется, тут упомянута лишь малая часть процесса, но коль вы намекали именно на эту часть, то пару слов о ней:
Это классика жанра. ТЧК.
Итерации, уточнение требований на каждой итерации, поддержка регрессией сверху, планирование итераций, организация условий их осуществления, контроль/верификация достигнутых результатов и т.д..
Такой характер работ прямо предписывается на всех этапах разработки сложных комплексов.
Т.е. даже начиная с эксизного проекта.
И даже со стадии постановки задачи.
Взять обсуждаемые рядом самолёты и движки.
Вот их разрабатывают по 10 лет.
Почему?
Казалось бы, нарисовал и готово.
Дудки.
Такая же точно итеративность и даже период итераций зачастую близок.
Рекомендуется длительность итерации от 2-х недель до 2-х месяцев.
Каждая команда в большом проекте реализует требования, выкатывает свою часть.
Иногда просто теоретическую или 3D (зависит от стадии проекта).
Далее продолжает работу над следующей итерацией, одновременно с этим на уровне интеграции или самого что ни есть академического матана/исследований гоняется текущий результат. К началу следующей итерации готовы уточнённые требования. И так по кругу несколько лет. Когда доходят до "железной" части — аналогично. Когда отлаживают технологию производства — тоже. Всегда происходит одно и то же.
Или взять даже советский "шаблон" не на коробочный проект, а на проект-заказуху:
http://it-gost.ru/content/view/56/40
Но это же относится и к серийному продукту и к софтовой "коробке".
В разных по характеру проектах по-разному распределены роли, вот в чём отличие.
Ключевая роли — это роли источника функциональных и нефункциональных требований и роли контролирующего органа.
И назови ты их как хочешь, хоть даже исключтельно английскими аббревиатурами, смысл не поменяется. ))
Поэтому, вот всё, на что НС глубокомысленно намекал, но так и не сформулировал — это обязательная часть процесса разработки любых более-менее сложных систем.
Итого.
Какой бы аспект происходящего (из десятков их) вы бы не взяли из своей разработки — ничего уникального там нет.
Абсолютно любой происходящий у вас аспект разработки в нынешней ли её испостаси, или "как оно было 5 лет назад" — не важно, всё это хорошо известные и разобранные до уровня молекул вещи.
И это я еще не прошёлся по принципам проектирования сложных систем.
А то тоже порой слышу "в реальном продакшене всё по-другому".
Святая простота. ))
IB>Да, я уже понял, что настоящих системотехников готовят только в севастпольском политехе, и выпускники МГУ, Физтеха, МИФИ, Бауманки и НГУ им в подметки не годяться
Я говорил лишь, что конкретно ты не системотехник по образованию.
Других сюда не вплетай.
Что касается системотехников, то они вообще поголовно свалили из страны сразу же после ВУЗ-а, бо их отрывали тогда с руками и ногами.
Ты ж вспомни, времена тогда были не настолько софтовые-высокоуровневые как сегодня.
Тогда ЛЮБАЯ более-менее серьёзная разработка содержала в себе до 70% (минимум) объема "платформенного" или, если угодно, "ядерного" кода.
Сейчас весь такой код дан "откуда-то сверху" и почти всегда на сейчас даром.
Взять для примера 1С (работает там один из одногруппников, т.е. не "мальчик одинэсник", а именно разрабатывает её), в этом продукте хорошо заметно разделение на "ядро" и "остальное" — такое разделение прямо в конторе, и оно именно так и обзывается.
IB>ко мне до сих пор по этим статьям приходят и просят проконсультировать, значит не зря писал.
Боже упаси мне сказать, что зря писал.
Это направление нужное и важное, ес-но.
РЕчь о том, что ты опять как-то по-странному отметился по такому направлению, на которое не натаскивался.
Это бросается в глаза.
При этом малость не с той стороны зашёл, т.е. опять блокируешь, собсно, сам обмен опытом.
Так-то со стороны если, твоё желание участвовать в обсуждениях подобных тем выдаёт здоровое любопытство прожённого технаря и мне даже где-то странно, что у тебя случилась малость другая специализация по-жизни. Без сарказма.
Cтатьи твои, если начистоту, написаны в хорошо знакомом мне ключе.
Сплошное де жа вю.
По складу ума ты тот самый технарь, роющий самую суть вещей, из которого только и может получиться грамотный аналитик.
Из других не получается обычно, они всегда на пол-дороге где-то застревают. ))
Просто, блин, потрачена эта "манна" была на такую тему... это как микроскопом гвозди забивать.
IB>Я ничего не определял, я сделал логический вывод о том, что из одного не обязятельно следует другое. Поскольку, повторюсь, работа в команде над научным проектом и работа над коммерческим это совершенно разный опыт, так как цели другие.
Смотрю и молчание продолжается, и в плане формулировок на этой итерации еще сложности, продолжаются слова общего плана. ))
Что помешало в двух словах описать те тонкости "алгоритма промышленной разработки", про который намекаете ты и НС?
Что мешает мне описать ВАШИ алгоритмы — понятно, в случае чего, мол, это я за вас расписался и будет удобно обвинить меня в разговоре с голосами в голове.
Но так-то вы каждый уже в течении 3-х постов, хоть и туманно, но намекали, например, вот на такое вполне известное происходящее:
— от заказчика постоянно приходят хотелки, которые трансформируются в уточнения требований;
— разработка получается итеративной, версии выходят регулярно и не патамушта багфикс, а потому еще, что аж новые фичи и при этом крайне желательно, чтобы старые фичи не отвалились.
(4-й курс профильного ВУЗ-а по дисциплине "системы/комплексы" — описание одного из этапов жизненного цикла системы)
Я ХЗ почему НС дважды делал вид, что такой характер разработки зело уникальный, а его оппонент и вовсе "всё равно не поймёт". ))
Наша контора тоже выпускает обновления каждую неделю, обычно более чем для одного продукта (т.е. редкая неделя без обновлений) и в 99.9% это новые фичи, а не багфиксы.
Но фиг с ним.
Разумеется, тут упомянута лишь малая часть процесса, но коль вы намекали именно на эту часть, то пару слов о ней:
Это классика жанра. ТЧК.
Итерации, уточнение требований на каждой итерации, поддержка регрессией сверху, планирование итераций, организация условий их осуществления, контроль/верификация достигнутых результатов и т.д..
Такой характер работ прямо предписывается на всех этапах разработки сложных комплексов.
Т.е. даже начиная с эксизного проекта.
И даже со стадии постановки задачи.
Взять обсуждаемые рядом самолёты и движки.
Вот их разрабатывают по 10 лет.
Почему?
Казалось бы, нарисовал и готово.
Дудки.
Такая же точно итеративность и даже период итераций зачастую близок.
Рекомендуется длительность итерации от 2-х недель до 2-х месяцев.
Каждая команда в большом проекте реализует требования, выкатывает свою часть.
Иногда просто теоретическую или 3D (зависит от стадии проекта).
Далее продолжает работу над следующей итерацией, одновременно с этим на уровне интеграции или самого что ни есть академического матана/исследований гоняется текущий результат. К началу следующей итерации готовы уточнённые требования. И так по кругу несколько лет. Когда доходят до "железной" части — аналогично. Когда отлаживают технологию производства — тоже. Всегда происходит одно и то же.
Или взять даже советский "шаблон" не на коробочный проект, а на проект-заказуху:
http://it-gost.ru/content/view/56/40
в зависимости от условий создания АС возможны различные совмещения функций заказчика, разработчика, поставщика и других организаций, участвующих в работах по созданию АС
Но это же относится и к серийному продукту и к софтовой "коробке".
В разных по характеру проектах по-разному распределены роли, вот в чём отличие.
Ключевая роли — это роли источника функциональных и нефункциональных требований и роли контролирующего органа.
И назови ты их как хочешь, хоть даже исключтельно английскими аббревиатурами, смысл не поменяется. ))
Поэтому, вот всё, на что НС глубокомысленно намекал, но так и не сформулировал — это обязательная часть процесса разработки любых более-менее сложных систем.
Итого.
Какой бы аспект происходящего (из десятков их) вы бы не взяли из своей разработки — ничего уникального там нет.
Абсолютно любой происходящий у вас аспект разработки в нынешней ли её испостаси, или "как оно было 5 лет назад" — не важно, всё это хорошо известные и разобранные до уровня молекул вещи.
И это я еще не прошёлся по принципам проектирования сложных систем.
А то тоже порой слышу "в реальном продакшене всё по-другому".
Святая простота. ))
IB>Да, я уже понял, что настоящих системотехников готовят только в севастпольском политехе, и выпускники МГУ, Физтеха, МИФИ, Бауманки и НГУ им в подметки не годяться
Я говорил лишь, что конкретно ты не системотехник по образованию.
Других сюда не вплетай.
Что касается системотехников, то они вообще поголовно свалили из страны сразу же после ВУЗ-а, бо их отрывали тогда с руками и ногами.
Ты ж вспомни, времена тогда были не настолько софтовые-высокоуровневые как сегодня.
Тогда ЛЮБАЯ более-менее серьёзная разработка содержала в себе до 70% (минимум) объема "платформенного" или, если угодно, "ядерного" кода.
Сейчас весь такой код дан "откуда-то сверху" и почти всегда на сейчас даром.
Взять для примера 1С (работает там один из одногруппников, т.е. не "мальчик одинэсник", а именно разрабатывает её), в этом продукте хорошо заметно разделение на "ядро" и "остальное" — такое разделение прямо в конторе, и оно именно так и обзывается.
IB>ко мне до сих пор по этим статьям приходят и просят проконсультировать, значит не зря писал.
Боже упаси мне сказать, что зря писал.
Это направление нужное и важное, ес-но.
РЕчь о том, что ты опять как-то по-странному отметился по такому направлению, на которое не натаскивался.
Это бросается в глаза.
При этом малость не с той стороны зашёл, т.е. опять блокируешь, собсно, сам обмен опытом.
Так-то со стороны если, твоё желание участвовать в обсуждениях подобных тем выдаёт здоровое любопытство прожённого технаря и мне даже где-то странно, что у тебя случилась малость другая специализация по-жизни. Без сарказма.
Cтатьи твои, если начистоту, написаны в хорошо знакомом мне ключе.
Сплошное де жа вю.
По складу ума ты тот самый технарь, роющий самую суть вещей, из которого только и может получиться грамотный аналитик.
Из других не получается обычно, они всегда на пол-дороге где-то застревают. ))
Просто, блин, потрачена эта "манна" была на такую тему... это как микроскопом гвозди забивать.