Обсуждение

Вписываться, оказаться в толпе - характерная терминология. Она сходу вызывает отвращение.

А у меня вызывает отвращение идея Маугли и Робинзона Крузо, а особенно идеология "опоры на собственные силы" -- чучхеизм во всех его проявлениях.

Положим, северокорейские чучхеисты побили "встроившихся" южнокорейских власовцев в космических технологиях. :)) И не надо тут разводить про "уровень жизни". Если Юг обложить такой же блокадой, он сдохнет.

О, озабоченность "самостоятельностью" на непонятном уровне количества (от десятков тысяч до десятков миллионов человек) детектед. Махровость можно будет уточнить попозже, но вероятность обнаружения так же велика.

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

Инженерия требований потихоньку развивается, хотя и не так быстро, как хотелось бы: там ведь задача реинженерии использующей подсистемы, что очень и очень непросто, это ведь исследования по факту. Так что "на основе чего" -- люди и над этим думают.

Инженерия требований потихоньку развивается Я работаю в этой области. Я бы сказал, что вижу я не развитие, а деградацию.

Будущее уже здесь, только оно распределено неравномерно. Возможно, вы попадаете не в те точки, где это будущее. Я же его целенаправленно отыскиваю. 1. GORE (это помимо use cases) и motivational модели (довольно много работ по инженерии требований и requirements management уже не имеют даже слово "требования" в их заголовках -- те же motivational models в инженерии предприятий как пример). Это связки с user needs и архитектурой -- вводится много понятий, помогающих разработке требований. Попытки разных языков описания требований сюда. 2. Чёткое понимание, что разработка требований -- это восстановление конструкции использующей системы в некоторых случаях (чаще всего -- выход на рынок). 3. Чёткое понимание, что требований много всяких разных, в том числе задающих появление описания "чёрного ящика" на разных стадиях жизненного цикла и разными командами с разной целью. 4. Связь требований с испытаниями и assurance case. Увы, всякие AP233 или RIF никакого отношения к развитию этой предметной области не имеют. А к инициативам типа Goals and Contracts Specification Language я пока не знаю, как относиться. Ибо пересматриваю сейчас своё отношение к системам работы с требованиями в части автоматизации работы с полнотекстовыми требованиями.

Возможно, вы попадаете не в те точки, где это будущее. Я попадаю во все точки. И к безумным учёным, что строят воздушные замки, и в реальные проекты (причём, совсем не веб), где реальные люди делают реальные вещи. вводится много понятий, помогающих разработке требований. С точки зрения в индустрии одна эта строчка уже воспринимается как очередной анекдот. Остальные три пункта банальны и тоже далеки от реальности в ИТ, а в железе присутствовали в каком-то виде с самого начала.

Ну, среднестатистическая "индустрия" меня сейчас мало волнует: в ней в силу массовости и большого притока малообученных людей как раз регресс и идёт. Я, кстати, забыл ещё приписать, что кроме моделей GORE с полнотекстовыми определениями понятий есть ещё и разные структурные модели, фиксирующие устройство using system (всякие Modelica и т.д.).

Регресс идёт в околотребовательной науке. Люди всё дальше и дальше отрываются от реальности. Дело в том, что я видел применение этого изнутри и на нижнем уровне.

"Люди всё дальше и дальше отрываются от реальности" -- мой пункт в том, что реальностей много. Так что и точек отрыва (и векторов отрыва) тоже может быть много, но в некоторых случаях всё работает. Со сложностью помогает бороться переход к моделям, их легче поддерживать в работоспособном состянии. дальше можно обсуждать, какие модели перспективны, а какие тупиковы.

в некоторых случаях всё работает Нет такой технологии, которая не работала бы в тепличных условиях, при безграничном бюджете и в руках команды экспериментаторов. Вопрос в том, настолько ли она надёжна, чтобы выдержать грязь реальной жизни и давление горящих сроков. Про модели у меня была картинка. Даже в элементарных случаях моделирование в ИТ превращается в вещь в себе. Модели не упрощают, а скрывают сложность. Это разные вещи. В результате потом передняя линяя программистов под эти подпихивает горы заплаток.

Модели не упрощают сложность, а отражают (документируют, capture) её. Если они не отражают сложности, значит нужны или другие модели, или другие модельеры. Когда-то и фортран работал в тепличных условиях, при безграничном бюдете и в руках команды экспериментаторов. До сих пор его кое-где дустом изводят, настолько неприхотлив. Даже IDEF0 сейчас дустом не удаётся вытравить, хотя многие его используют вместо IDEF3 и не догадываются об этом. Нельзя обсуждать отдельно дисциплины, технологии, компетенции и конкретные проекты с их особенностями. Каждый проект и каждая команда несчастлива в требованиях по-своему. Но когда-то не знали, что use cases помогают с требованиями, а сейчас знают. В этом и фишка, развитие идёт. В сегодняшнем месиве новинок трудно разобраться, а через тридцать лет после заматерения выжившей новинки она не будет уже новинкой. Так что или мы говорим о том, что выбираем из сегодняшних новинок и пытаемся применить в наших конкретных проектах, или это пустой трёп. Вот я тоже сейчас буду заниматься требованиями по самое не балуйся, а из "айтишных" там будут требования к АСУ ТП (то есть это не веб-разработка и не корпоративный софт). Ничего, прорвёмся -- хотя счастья быстро и дёшево не будет по определению, но всё лучше, чем если вообще требованиями не заниматься в проекте и подходить к приёмкам и проверкам без хорошо документированных их хоть как-то оттрассированных требований. Конечно, GORE там если и будет, то на каких-то крошечных участках работы. Там и use cases не будет, я думаю.

Вместе с Фортраном возникло дофига других языков. Естественный отбор оставил единицы. Да и для матрасчётов лучше него ничего нет. Я обсуждаю не "каждую команду", а условия выживаемости технологий. use cases, кстати, понимают единицы. Остальные рисуют разрекламированные коммерческими тулами диаграммки и тем счастливы. Да, какими бы крутыми ни были тулы моделирования у инженеров-механиков, одним из основных инструментов у них остаётся напильник.

Главное не раскачивать и пилить пока осталось.

а на кого ещё надеяться, если не на себя? на потенциальных санкционеров, что ли? это противоречит требованиям госбезопасности...

Мне на безопасность не плевать, я люблю безопасность. А на госбезопасность -- кто именно там вызвался формулировать эти требования, почему это я должен с этими дурацкими требованиями быть согласен кроме как под угрозой применения силы самих этих госбезопасников?! Какого государства именно безопасность, и что такое это "государство"? Звиняйте, но я довольно много лет занимался теорией в этом вопросе, а когда-то и практикой (эх, на что надеялся?!). Даже спорить не буду сейчас, тут уже полгода всё окончательно завонялось в интернетах на эту тему -- серьёзный разговор невозможен, увы, в том числе и про санкции, и даже про добровольную (с точки зрения кучки чиновников и политиков, но недобровольную для меня, например) и стремительную чучхеизацию страны.

Так самостоятельность - это непременное условие для того, чтобы сделать нечто стоящее. А тот, кто думает "встроиться" или "бежать в толпе", всегда будет следовать чужому мнению.

Прислушиваться к чужим мнениям очень важно. Я, когда был молод и горяч, много из-за этого неприслушивания ошибок наворотил. А ведь мог бы прислушиваться, и создавать нечто стоящее, при этом тратить меньше сил.