Не всегда. Зачастую прекрасные специалисты попросту не хотят и\или не умеют руководить\брать на себя ответственность. И это не плохо, от них больше толка от количества написанных и отлаженных строчек кода будет, от забитой в голову витиеватой архитектуры. А тимлиды — это больше гаранты того, чтобы разработчик и команда в целом хорошо работала и не отвлекалась, имела настрой и дух. Больше прыгать и улыбаться, защищать и брать на себя даже чужие (подчинённых) ошибки, лишь бы всё склеилось в эффективное единое.
Давно думают и давно обещают, но пока хороших решений нет.
Да и кроме того, кроме функциональности, хотелось бы лишний раз не думать и не делать лишних движений. Взять-перетащить-скопировать. И быстро. И не громоздко. А уж когда понадобится… то и функции доставать.
Думаю, в недалёком будущем в облачных решениях будут уже рабочие механизмы.
Перцептрон с одним нейроном весьма частный случай.
Если уж статья и называется «Перцептрон», то не помешает рассказать, что это вообще за зверь, что бывают одно- и много-слойные…
И что такое: «нейронная сеть из одного перцептрона»? Что вы хотели сказать? Бывают из нескольких? (ответ: бывают; а зачем?).
А вообще конечно хорошо, что для чайников. Хотя больше интересно обучение и быстрые алгоритмы — на будущее.
Это одна из главных тем следующей статьи.
Разные решения используются. Одновременно два вычислителя не используются, один из них в горячем резерве. Либо используются три. Плюс для каждого «компьютера» (Flight Control Unit'a) есть самодиагностика и самоконтроль.
Проблемы сертификации оборудования.
Микросхемы должны иметь приёмку по стандартам авионики. Таких не так уж и много.
На самом деле, -O2 обычно хватает для всего (главная и критическая часть программы — это планирование задач). Если используются планируемые подпрограммы (задачи), которые куда-то надо записать, или, особенно, программы для наземного обслуживания, содержащие много кода для работы с терминалом, то обычно добавляется дополнительная быстрая Flash, которая почти неограниченно резиновая. Однако есть критичная часть программы, которая должна работать в режиме жесткого реального времени, что исключает возможность «просто добавить память».
К тому же за пару лет проблемы дефицита времени и пространства становятся всё менее актуальными, и поэтому есть тенденция переписывать код из спидхаков в легкочитаемый, но не очень оптимальный код, который, в конечном итоге, проще поддерживать даже лаборанту.
Да, к сожалению, в нашей науке и промышленности финансовые перспективы не радужные.
Хотя у молодежи желания работать над наукой куда больше, чем над софтом, считающим бублики в дырках. Даже при меньших зарплатных ожиданиях. С большим энтузиазмом. Но не все могут себе это позволить.
Насколько я понимаю, классическая модель водопада предполагает необратимость процесса.
Даже если принять во внимание обратные связи между этапами на одном уровне, о которых говорил Ройс, то что вы будете делать на этапе тестирования, если обнаружена ошибка в требованиях? Или, вообще как обеспечить возможность изменения требования без перезапуска всего водопада?
Я молчу про этап внедрения (т.е. полётов), когда обнаруживается необычное поведение, вызванное замерзанием конденсата внутри поверхностей крыла, требующее усовершенствования кода и протоколирования в документации. Эти риски, пусть и со скрипом, но учитывает V-модель.
Не всего можно избежать на ранних этапах, особенно при предельной сложности и многокомпонентности системы, требующей максимально возможное отсутствие ошибок.
Сейчас не буду углубляться в архитектуру и аппаратную часть, но тем не менее:
— есть код, который создается сертифицированными кодогенераторами
— есть код, который пишется вручную, да, даже переписываются драйвера
— есть комбинации
Для шасси используются все эти походы.
Могу оценить исключительно рукописную часть, которая, естественно, была наименьшей по объему. Порядка 100 модулей (если бы это было бы ООП, скажем, C++ то модули — аналоги классов). На каждый модуль в среднем 500-1000 строк кода, описывающего его интерфейс и методы. Итого порядка 50 тысяч строк кода. Плюс, помножив на два — 100.00-200.000 строк кода в зависимости от нерациональности кодогенераторов и наличия комментариев.
Как минимум необратимостью. Все ошибки выгодно обнаруживать на ранней стадии проекта.
В худшем случае он может быть полностью переработан вместе с требованиями (на моей практике такое случалось, хоть и в мелком проекте). Плюс, контроль и тестирование происходят при максимально разумно малом изменении кода. Это минимизирует, в конечном итоге, стоимость проекта и, главное, позволяет избежать ошибок в нём. Плюс, ошибка может быть пропущена в 39 итерациях, но обнаружена на 40. И такое случается.
З\п в США? Не хочу ставить под сомнение ваши слова, но у меня знакомый в США работает продавцом в местной ликёрке и то получает вдвое больше в пересчёте на рубли.
Да и про ГЛОНАСС наслышан из первых уст. Бардак-с.
Просто ответить «потому что» не получится. Тут выше уже сказали, что машина имеет свойство сильно бюрократизироваться. Объясню с точки зрения влияния на ПО. В идеале есть план, по плану надо поэтапно реализовывать спецификацию. Отчитываться. Однако, программам свойственно получать от их создателей ошибки, а спецификации — от своих. Тогда, после того, как ошибка обнаружена за пределами Iteration Package (т.е. за пределами того, когда программист написал свой код и отдебажил), чтобы хоть что-то изменить, надо менять уже документы, которые так легко не меняются. Т.е. каждое новое изменение в коде будет занимать почти вдвое больше времени в отличие от предыдущего почти исключительно по бюрократическим причинам.
Однако, это не так плохо. Такой процесс как раз направлен на ловлю ошибок и недопущение их.
Поэтому, если взгляните на картинку со спиральной моделью, можно заметить, о чём я сейчас говорю. Хотя тестирование на ней явно преуменьшено, но, в целом, проверка-перепроверка документации и сверка со всеми изменениями занимает половину всего времени. Процесс разработки авиационного ПО — процесс перманентной валидации.
Тем не менее, факторами, которые мешают просто написать, скажем, лимитирование команды актуатора являются то, что:
— существуют ошибки в симуляторе, и результат инженерных тестов и дебага не такой, как ожидается, и надо тогда допиливать симулятор.
— особенность аппаратной архитектуры такова, что 1 из 100 фреймов приходит неверный, что не ожидалось в спецификации (допустим, из-за округления на ADC Resolver'a), тогда, вероятно, надо менять калибровочные параметры или по-другому обрабатывать данные.
— внесены изменения в SRD — меняется архитектура и требования, что равносильно ещё одной незапланированной итерации
— появился justification от заказчика (нет, даже не технического плана). Нет, это без проблем, это он доплатил и увеличил сроки. Но, тем не менее, это значит, что на данной и последующей итерации должен быть проведет анализ на изменения всех документов на изменения кегля шрифтов или нежелания видеть в LLR намёки на ASSERT'ы.
— косяк сопряженной команды (я об этом расскажу в следующий раз), который приведёт к тому, что слишком сложный для исправления баг превращается в фичу для них, но ведёт к исправлениям для текущей команды разработчиков, т.к. они менее критичны и ресурсоёмки.
В итоге, если бы не надо было делать идеальный код и идеальные тесты, вылизанные до запятой и каждой опечатке в слове «menue», то код можно было бы написать и проинтегрировать за 0,5 года. Но качество порождает процесс, проверки и перепроверки. Отчёты и отчёты об отчётах.
Вы правы. Индусы действительно работают плохо. Но большей частью из-за того, что так всех устраивает. Ими удобно заткнуть дырку, в которой надо произвести, допустим, 100.000 страниц текста, состоящего из логов тестов. И не особо важно, что эти тесты будут очень плохими. Если высокоуровневые тесты будут хорошими (а так обычно оно и есть), то никто в работе индусов разбираться не будет.
Быть может это звучит плохо и не идеально, а какие-то ошибки будут пропущены, но это хороший вариант решить проблемы перегруженной системы в целом. Потому как для инициации изменения на поздних этапах одного typo или добавления лишней функции нужно менять неимоверно много готовых результатов. Механизм защищает систему от изменений и возможно новых ошибок, и заставляет учитывать максимально возможное количество нюансов на этапе проектирования. Это уменьшит и риски и стоимость продукта, избавляя его от бесконечных переработок.
В этом есть и плюсы, и минусы. Но такова реальность. Поэтому находить ошибки стараются на ранних этапах, привлекая не индийскую сторону, а, в том числе, русских специалистов для работы в режиме жестких deadline. И все заинтересованы не прокручивать машину по лишней итерации, а использовать хороших специалистов. Но, к сожалению, это не всегда возможно и не всегда просто даже для них. В худшем случае влетит не индусам, а руководителям проектов и архитекторам, которые осуществили ошибки управления.
Порой притормозить и как-то задокументировать русского заказчика очень тяжело.
Ибо в лучшем случае «мы придумали\хотим вундервафлю, надо сделать, запускай». С техпроцессами наследственная беда в России.
>на язык накладывается уйма ограничений, justification
В том числе и на C. Высокоуровневые сложнее и мощнее => работы над настраиванием системы justification больше. Для этого как раз нужен Coding стандарт.
>в России есть стандарты на авиационку в этом семействе
КТ-178B?
По поводу внутренних стандартов не скажу, но исходя из вышеуказанного, они должны быть.
Они не приняты. Так как на язык накладывается уйма ограничений, justification. И пользоваться тем же C++ или C# в его «модифицированном варианте» будет сложнее. Плюс, опять-таки кто-то такое исследование должен сделать, проанализировать байт-код на выходе, тулзы сертифицировать. Это долгий процесс. Потихоньку им занимаются.
Вам любопытный пример могу привести, что сертифицированный гаечный ключ для обслуживания механизации крыла стоит не два евро, а десять тысяч. Только потому, что его стоимость составилась из-за всех сертификационных процедур. Которые заняли не один год. Поэтому это:
а) дорого
б) долго, что ведёт к «запаздыванию» в технологиях до десятилетия
И думать будут обо мне, как мне удобно и понятно сортировать и выставлять теги.
Да и кроме того, кроме функциональности, хотелось бы лишний раз не думать и не делать лишних движений. Взять-перетащить-скопировать. И быстро. И не громоздко. А уж когда понадобится… то и функции доставать.
Думаю, в недалёком будущем в облачных решениях будут уже рабочие механизмы.
Если уж статья и называется «Перцептрон», то не помешает рассказать, что это вообще за зверь, что бывают одно- и много-слойные…
И что такое: «нейронная сеть из одного перцептрона»? Что вы хотели сказать? Бывают из нескольких? (ответ: бывают; а зачем?).
А вообще конечно хорошо, что для чайников. Хотя больше интересно обучение и быстрые алгоритмы — на будущее.
Разные решения используются. Одновременно два вычислителя не используются, один из них в горячем резерве. Либо используются три. Плюс для каждого «компьютера» (Flight Control Unit'a) есть самодиагностика и самоконтроль.
Микросхемы должны иметь приёмку по стандартам авионики. Таких не так уж и много.
На самом деле, -O2 обычно хватает для всего (главная и критическая часть программы — это планирование задач). Если используются планируемые подпрограммы (задачи), которые куда-то надо записать, или, особенно, программы для наземного обслуживания, содержащие много кода для работы с терминалом, то обычно добавляется дополнительная быстрая Flash, которая почти неограниченно резиновая. Однако есть критичная часть программы, которая должна работать в режиме жесткого реального времени, что исключает возможность «просто добавить память».
К тому же за пару лет проблемы дефицита времени и пространства становятся всё менее актуальными, и поэтому есть тенденция переписывать код из спидхаков в легкочитаемый, но не очень оптимальный код, который, в конечном итоге, проще поддерживать даже лаборанту.
плавно превращается в обычный:
Хотя у молодежи желания работать над наукой куда больше, чем над софтом, считающим бублики в дырках. Даже при меньших зарплатных ожиданиях. С большим энтузиазмом. Но не все могут себе это позволить.
Для представления можно ещё погуглить MISRA отдельно со всеми её правилами.
Даже если принять во внимание обратные связи между этапами на одном уровне, о которых говорил Ройс, то что вы будете делать на этапе тестирования, если обнаружена ошибка в требованиях? Или, вообще как обеспечить возможность изменения требования без перезапуска всего водопада?
Я молчу про этап внедрения (т.е. полётов), когда обнаруживается необычное поведение, вызванное замерзанием конденсата внутри поверхностей крыла, требующее усовершенствования кода и протоколирования в документации. Эти риски, пусть и со скрипом, но учитывает V-модель.
Не всего можно избежать на ранних этапах, особенно при предельной сложности и многокомпонентности системы, требующей максимально возможное отсутствие ошибок.
— есть код, который создается сертифицированными кодогенераторами
— есть код, который пишется вручную, да, даже переписываются драйвера
— есть комбинации
Для шасси используются все эти походы.
Могу оценить исключительно рукописную часть, которая, естественно, была наименьшей по объему. Порядка 100 модулей (если бы это было бы ООП, скажем, C++ то модули — аналоги классов). На каждый модуль в среднем 500-1000 строк кода, описывающего его интерфейс и методы. Итого порядка 50 тысяч строк кода. Плюс, помножив на два — 100.00-200.000 строк кода в зависимости от нерациональности кодогенераторов и наличия комментариев.
В худшем случае он может быть полностью переработан вместе с требованиями (на моей практике такое случалось, хоть и в мелком проекте). Плюс, контроль и тестирование происходят при максимально разумно малом изменении кода. Это минимизирует, в конечном итоге, стоимость проекта и, главное, позволяет избежать ошибок в нём. Плюс, ошибка может быть пропущена в 39 итерациях, но обнаружена на 40. И такое случается.
Да и про ГЛОНАСС наслышан из первых уст. Бардак-с.
Раз люди спрашивают про индусов, то развёрнуто ответил им в первую очередь. По логике, в это дерево, в подтверждение ваших слов.
Однако, это не так плохо. Такой процесс как раз направлен на ловлю ошибок и недопущение их.
Поэтому, если взгляните на картинку со спиральной моделью, можно заметить, о чём я сейчас говорю. Хотя тестирование на ней явно преуменьшено, но, в целом, проверка-перепроверка документации и сверка со всеми изменениями занимает половину всего времени. Процесс разработки авиационного ПО — процесс перманентной валидации.
Тем не менее, факторами, которые мешают просто написать, скажем, лимитирование команды актуатора являются то, что:
— существуют ошибки в симуляторе, и результат инженерных тестов и дебага не такой, как ожидается, и надо тогда допиливать симулятор.
— особенность аппаратной архитектуры такова, что 1 из 100 фреймов приходит неверный, что не ожидалось в спецификации (допустим, из-за округления на ADC Resolver'a), тогда, вероятно, надо менять калибровочные параметры или по-другому обрабатывать данные.
— внесены изменения в SRD — меняется архитектура и требования, что равносильно ещё одной незапланированной итерации
— появился justification от заказчика (нет, даже не технического плана). Нет, это без проблем, это он доплатил и увеличил сроки. Но, тем не менее, это значит, что на данной и последующей итерации должен быть проведет анализ на изменения всех документов на изменения кегля шрифтов или нежелания видеть в LLR намёки на ASSERT'ы.
— косяк сопряженной команды (я об этом расскажу в следующий раз), который приведёт к тому, что слишком сложный для исправления баг превращается в фичу для них, но ведёт к исправлениям для текущей команды разработчиков, т.к. они менее критичны и ресурсоёмки.
В итоге, если бы не надо было делать идеальный код и идеальные тесты, вылизанные до запятой и каждой опечатке в слове «menue», то код можно было бы написать и проинтегрировать за 0,5 года. Но качество порождает процесс, проверки и перепроверки. Отчёты и отчёты об отчётах.
Быть может это звучит плохо и не идеально, а какие-то ошибки будут пропущены, но это хороший вариант решить проблемы перегруженной системы в целом. Потому как для инициации изменения на поздних этапах одного typo или добавления лишней функции нужно менять неимоверно много готовых результатов. Механизм защищает систему от изменений и возможно новых ошибок, и заставляет учитывать максимально возможное количество нюансов на этапе проектирования. Это уменьшит и риски и стоимость продукта, избавляя его от бесконечных переработок.
В этом есть и плюсы, и минусы. Но такова реальность. Поэтому находить ошибки стараются на ранних этапах, привлекая не индийскую сторону, а, в том числе, русских специалистов для работы в режиме жестких deadline. И все заинтересованы не прокручивать машину по лишней итерации, а использовать хороших специалистов. Но, к сожалению, это не всегда возможно и не всегда просто даже для них. В худшем случае влетит не индусам, а руководителям проектов и архитекторам, которые осуществили ошибки управления.
Ибо в лучшем случае «мы придумали\хотим вундервафлю, надо сделать, запускай». С техпроцессами наследственная беда в России.
В том числе и на C. Высокоуровневые сложнее и мощнее => работы над настраиванием системы justification больше. Для этого как раз нужен Coding стандарт.
>в России есть стандарты на авиационку в этом семействе
КТ-178B?
По поводу внутренних стандартов не скажу, но исходя из вышеуказанного, они должны быть.
Вам любопытный пример могу привести, что сертифицированный гаечный ключ для обслуживания механизации крыла стоит не два евро, а десять тысяч. Только потому, что его стоимость составилась из-за всех сертификационных процедур. Которые заняли не один год. Поэтому это:
а) дорого
б) долго, что ведёт к «запаздыванию» в технологиях до десятилетия
По поводу аппаратной части — в следующий раз.