Comments 96
"… привлекаются ресурсы аутсорса в Индии..." О Боже!!! Я больше не полечу!
Ждемс когда похолодает, океан замерзнет, бум пешком ходить через океан.
Пытаются экономить, а потом сотни невинных жертв.
На самом деле не зависит от расовой принадлежности разработчика. Там идиотов не держат. Более того что пишут эти люди — проходит строжайший контроль.
Там идиотизм несколько на другом уровне и не зависит от принадлежности: процесс разработки авиационного ПО настолько бюрократизирован, что зачастую заставить даже очень сильного разработчика его выполнять — задача не из легких.
Вы правы. Индусы действительно работают плохо. Но большей частью из-за того, что так всех устраивает. Ими удобно заткнуть дырку, в которой надо произвести, допустим, 100.000 страниц текста, состоящего из логов тестов. И не особо важно, что эти тесты будут очень плохими. Если высокоуровневые тесты будут хорошими (а так обычно оно и есть), то никто в работе индусов разбираться не будет.
Быть может это звучит плохо и не идеально, а какие-то ошибки будут пропущены, но это хороший вариант решить проблемы перегруженной системы в целом. Потому как для инициации изменения на поздних этапах одного typo или добавления лишней функции нужно менять неимоверно много готовых результатов. Механизм защищает систему от изменений и возможно новых ошибок, и заставляет учитывать максимально возможное количество нюансов на этапе проектирования. Это уменьшит и риски и стоимость продукта, избавляя его от бесконечных переработок.
В этом есть и плюсы, и минусы. Но такова реальность. Поэтому находить ошибки стараются на ранних этапах, привлекая не индийскую сторону, а, в том числе, русских специалистов для работы в режиме жестких deadline. И все заинтересованы не прокручивать машину по лишней итерации, а использовать хороших специалистов. Но, к сожалению, это не всегда возможно и не всегда просто даже для них. В худшем случае влетит не индусам, а руководителям проектов и архитекторам, которые осуществили ошибки управления.
Быть может это звучит плохо и не идеально, а какие-то ошибки будут пропущены, но это хороший вариант решить проблемы перегруженной системы в целом. Потому как для инициации изменения на поздних этапах одного typo или добавления лишней функции нужно менять неимоверно много готовых результатов. Механизм защищает систему от изменений и возможно новых ошибок, и заставляет учитывать максимально возможное количество нюансов на этапе проектирования. Это уменьшит и риски и стоимость продукта, избавляя его от бесконечных переработок.
В этом есть и плюсы, и минусы. Но такова реальность. Поэтому находить ошибки стараются на ранних этапах, привлекая не индийскую сторону, а, в том числе, русских специалистов для работы в режиме жестких deadline. И все заинтересованы не прокручивать машину по лишней итерации, а использовать хороших специалистов. Но, к сожалению, это не всегда возможно и не всегда просто даже для них. В худшем случае влетит не индусам, а руководителям проектов и архитекторам, которые осуществили ошибки управления.
Коллега, вы меня простите, но если вы глянете в мой профайл, то увидите, что я вам не только не оппонирую, но еще и нахожусь с вами на одном игровом поле. И в целом, знаком и с разработкой авиационного ПО и с индусами в этой прекрасной области.
Как-то пришлось пару суток не спать из-за нагенеренных индусами тестовых логов.
Как-то пришлось пару суток не спать из-за нагенеренных индусами тестовых логов.
Ничего не имею против индийских разработчиков, но в индийской культуре присутствует несколько наплевательское отношение к жизни и смерти. Обратите внимание на новости: постоянно то поезд сойдет с рельс и куча народу погибнет, то полный автобус с пассажирами в пропасть рухнет, то еще что-то аналогичное. Просто люди не заморачиваются чрезмерным соблюдением техники безопасности. Ну утонул паром с сотней пассажиров, ну бывает :)
UFO just landed and posted this here
UFO just landed and posted this here
Ну, топ-авторы в своё время тоже по одной-две статьи аналогичной крутости написали (а как иначе в топ было попасть?). Другое дело, что постоянно писать на том же уровне не получается — никто не является спецом во всём, а на одну и ту же тему писать постоянно не будешь. Вот Вам эта статья понравилась, вторую на ту же тему тоже прочитаете с удовольствием. А пятую? А семнадцатую?
Не удержалась и вспомнила вот эту статью:) www.anafor.ru/other/russianproject.htm
Надеюсь, аналогии безосновательны
Надеюсь, аналогии безосновательны
Если не секрет, откуда происходит личный опыт автора?
Я работал на МиГе, все описанное здесь не имеет ничего общего с суровой реальностью этого предприятия.
Что-то заграничное или Иркут?
Я работал на МиГе, все описанное здесь не имеет ничего общего с суровой реальностью этого предприятия.
Что-то заграничное или Иркут?
А ваш опыт секретен или вы можете изложить его в статье? Интересно.
Сейчас уже не секретен, подписка о неразглашении не действует. Да и не видел я ничего секретного.
В одном из комментариев ниже человек «поностальгировал» так, что будто рядом со мной работал.
Но у меня все-таки были свои особенности:
Для начала, я пришел туда в 2010 году на должность техника-стажера (студент 3 курса). В мою задачу входило моделирование САУ — так вот, моё рабочее место состояло из компьютера с 386 процессором и матлабом версии, кажется, 2.1. Без гуя, естественно. При этом это рабочее место я делил с человеком, который уже давно там работал. То есть если за компьютером был он (программировал на паскале), то я слонялся по территории или читал книжки.
Однажды в своей зарплатной ведомости увидел сумму около 100 тысяч рублей (при зарплате в 3). Поинтересовался что это — оказывается со студентов они не платят какой-то налог и через меня провели банкет. Восхитительно!
О плюсах — во многих отделах работают ребята-энтузиасты, которые пробивают получение нового оборудования, внедряют новые системы, занимаются интересными вещами. Моё наблюдение: если количество молодежи (<40 лет) переваливает за 30%, то отдел начинает работать. В моем, например, я был единственным человеком, который попытался узнать — а вообще кому-то нужна наша работа?
Энтузиастов мало ввиду смешной зарплаты. Растет она исключительно от выслуги лет, никак не от достижений.
Кажется, на этом мой поток сознания окончен.
p.s. О разработке даже не заикаюсь, в своём отделе ни разу не видел работающего программиста.
В одном из комментариев ниже человек «поностальгировал» так, что будто рядом со мной работал.
Но у меня все-таки были свои особенности:
Для начала, я пришел туда в 2010 году на должность техника-стажера (студент 3 курса). В мою задачу входило моделирование САУ — так вот, моё рабочее место состояло из компьютера с 386 процессором и матлабом версии, кажется, 2.1. Без гуя, естественно. При этом это рабочее место я делил с человеком, который уже давно там работал. То есть если за компьютером был он (программировал на паскале), то я слонялся по территории или читал книжки.
Однажды в своей зарплатной ведомости увидел сумму около 100 тысяч рублей (при зарплате в 3). Поинтересовался что это — оказывается со студентов они не платят какой-то налог и через меня провели банкет. Восхитительно!
О плюсах — во многих отделах работают ребята-энтузиасты, которые пробивают получение нового оборудования, внедряют новые системы, занимаются интересными вещами. Моё наблюдение: если количество молодежи (<40 лет) переваливает за 30%, то отдел начинает работать. В моем, например, я был единственным человеком, который попытался узнать — а вообще кому-то нужна наша работа?
Энтузиастов мало ввиду смешной зарплаты. Растет она исключительно от выслуги лет, никак не от достижений.
Кажется, на этом мой поток сознания окончен.
p.s. О разработке даже не заикаюсь, в своём отделе ни разу не видел работающего программиста.
Да, к сожалению, в нашей науке и промышленности финансовые перспективы не радужные.
Хотя у молодежи желания работать над наукой куда больше, чем над софтом, считающим бублики в дырках. Даже при меньших зарплатных ожиданиях. С большим энтузиазмом. Но не все могут себе это позволить.
Хотя у молодежи желания работать над наукой куда больше, чем над софтом, считающим бублики в дырках. Даже при меньших зарплатных ожиданиях. С большим энтузиазмом. Но не все могут себе это позволить.
Мне по работе приходилось бывать в ГСС, КБ Туполева, общаться с сотрудниками КБ Сухого. Соглашусь с Вами полностью — в тех отделах, где треть — молодежь — движуха и интерес.
Единственное предприятие, выбивающееся из списка — Пермский Авиадвигатель. КБ очень продвинуто в сфере ИТ и у всех горят глаза. И молодежи там работает больше, чем 30%.
Единственное предприятие, выбивающееся из списка — Пермский Авиадвигатель. КБ очень продвинуто в сфере ИТ и у всех горят глаза. И молодежи там работает больше, чем 30%.
ГосНИИАС?
Напишите статью, если не секрет.
Если в этой статье речь про суперджет, то понятно откуда столько новшеств в процессе.
Это не новшества. Это переложение западных стандартов на наши рельсы.
все описанное здесь не имеет ничего общего с суровой реальностью этого предприятия
Видимо, для МиГа было бы новшеством.
Видимо, для МиГа было бы новшеством.
МиГ занимается военной авиацией, в которой действуют правила кардинально отличающиеся от правил разработки ПО для гражданской.
Там самолеты по-другому что ли летают?
Автор комментария явно посетовал на убогость процесса на МиГе. Разве нет? Видимо, он желает внедрения некоторого подобия процесса, описанного в статье, и там.
Автор комментария явно посетовал на убогость процесса на МиГе. Разве нет? Видимо, он желает внедрения некоторого подобия процесса, описанного в статье, и там.
Насколько я знаю, военные как-раз чем-то таким сейчас и занимаются. Но это процесс небыстрый.
Подозреваю, что требования несколько отличаются. Вернее их приоритет. Скажем разная соотношение цен ошибок первого и второго рода. Или если для пассажирских самолетов основным требованием является, наверное, безопасность пассажиров любой ценой, то для военных это может быть возможность выполнения боевой задачи, пускай даже ценой гибели машины и пилота.
Вы не правы. В военных проектах, во всяком случае, проектах Евросоюза действуют те же самые правила и зачастую те же версии документов и стандартов. Только компьютеры всегда под замком, документы в сейфах. Человек за спиной.
Liebherr-Aerospace, которая как раз делала систему управления RRJ.
Не только Суперджет, да с ним я и не так много работал. В-основном все процессы, описанные тут — опыт разработки с нуля Superjet'a (в нём, как в первом блине, не всё так гладко) и опыта работы Bombardier и Airbus.
Не только Суперджет, да с ним я и не так много работал. В-основном все процессы, описанные тут — опыт разработки с нуля Superjet'a (в нём, как в первом блине, не всё так гладко) и опыта работы Bombardier и Airbus.
Огромное спасибо за статью, очень толково написана и читать просто.
Единственное, чего я не понимаю, это как гигантские объемы работы и количество кода сочетается с вероятностью отказа = 10^-9. В общем, с нетерпением жду следующую часть )
Единственное, чего я не понимаю, это как гигантские объемы работы и количество кода сочетается с вероятностью отказа = 10^-9. В общем, с нетерпением жду следующую часть )
UFO just landed and posted this here
Ок, в следующей статье приведу подробные примеры.
Яростно плюсую, может кто где видел?
www2.research.att.com/~bs/JSF-AV-rules.pdf
Вот это топик! Читал с удовольствием.
Спасибо!
Спасибо!
7. Внесение результатов в систему контроля версий и отчётов (IBM Rational ClearCase\ClearQuest).
На всякий случай: простая система контроля версий в разработке авиационного ПО применена просто так быть не может. Нужна система конфигурационного управления (7-я глава КТ-178B).
Вкратце: в стандарте сформулировано большое количество целей, достичь которые без специальной настройки внедрения административно-инструментальных ограничений невозможно. Причем, некоторые из этих ограничений в принципе не могут быть достигнуты на современных широко распространенных системах версионного контроля и учета изменений.
На всякий случай: простая система контроля версий в разработке авиационного ПО применена просто так быть не может. Нужна система конфигурационного управления (7-я глава КТ-178B).
Вкратце: в стандарте сформулировано большое количество целей, достичь которые без специальной настройки внедрения административно-инструментальных ограничений невозможно. Причем, некоторые из этих ограничений в принципе не могут быть достигнуты на современных широко распространенных системах версионного контроля и учета изменений.
Так и есть. Это относительно «шага» в труде программиста. А «версией» в данном случае является целый набор документов, отчётов и т.п…
И кстати, я видел процессы, когда все начиналось не с Design Document, а с SRD — например, изменение уже готовой функциональности.
В моём случае, к счастью, такое только встречалось для драйверов Framework'a. В плане исследования или упрощения кода.
ТО есть флайт-тестов еще не было?
В смысле? Framework один на все проекты, и на большие, и на малые самолёты. Но у него отдельная система итераций. В проекте конкретной системы управления указывается, какая именно версия используется (что подразумевает собой, что разработка framework завершена).
Для Суперджета флайт-тесты были и успешно все прошли. Соответственно и эти драйверы отлетали и сертифицированы. Но фреймворк же развивается на перспективу, и в новом проекте его код когда-нибудь тоже пойдёт во флайт-тест.
Для Суперджета флайт-тесты были и успешно все прошли. Соответственно и эти драйверы отлетали и сертифицированы. Но фреймворк же развивается на перспективу, и в новом проекте его код когда-нибудь тоже пойдёт во флайт-тест.
Возможно, не очень внимательно прочёл.
Какие, собственно, языки принято использовать для разработки в этой сфере?
Я слышал что Ada считается де-факто стандартом «надёжного» языка.
Какие, собственно, языки принято использовать для разработки в этой сфере?
Я слышал что Ada считается де-факто стандартом «надёжного» языка.
Pure C, assembler.
Т.е. в аппаратных оковах данной сферы более высокоуровневые языки малополезны?
И процессоры каких архитектур обычно используются для авионики? RISC/CISC?
В любом случае, спасибо за статью и за ответ.
И процессоры каких архитектур обычно используются для авионики? RISC/CISC?
В любом случае, спасибо за статью и за ответ.
Они не приняты. Так как на язык накладывается уйма ограничений, justification. И пользоваться тем же C++ или C# в его «модифицированном варианте» будет сложнее. Плюс, опять-таки кто-то такое исследование должен сделать, проанализировать байт-код на выходе, тулзы сертифицировать. Это долгий процесс. Потихоньку им занимаются.
Вам любопытный пример могу привести, что сертифицированный гаечный ключ для обслуживания механизации крыла стоит не два евро, а десять тысяч. Только потому, что его стоимость составилась из-за всех сертификационных процедур. Которые заняли не один год. Поэтому это:
а) дорого
б) долго, что ведёт к «запаздыванию» в технологиях до десятилетия
По поводу аппаратной части — в следующий раз.
Вам любопытный пример могу привести, что сертифицированный гаечный ключ для обслуживания механизации крыла стоит не два евро, а десять тысяч. Только потому, что его стоимость составилась из-за всех сертификационных процедур. Которые заняли не один год. Поэтому это:
а) дорого
б) долго, что ведёт к «запаздыванию» в технологиях до десятилетия
По поводу аппаратной части — в следующий раз.
Кто не приняты? Высокоуровневые?
В том же семействе IEC 61508 явно говорится, что в чистом виде C использовать нельзя, потому что есть огромное количество возможностей выстрелить себе в ногу. Не уверен, что в России есть стандарты на авиационку в этом семействе, но у атомщиков есть, у железнодорожников.
Вы используете какие-нибудь руководящие документы по использованию C?
В том же семействе IEC 61508 явно говорится, что в чистом виде C использовать нельзя, потому что есть огромное количество возможностей выстрелить себе в ногу. Не уверен, что в России есть стандарты на авиационку в этом семействе, но у атомщиков есть, у железнодорожников.
Вы используете какие-нибудь руководящие документы по использованию C?
>на язык накладывается уйма ограничений, justification
В том числе и на C. Высокоуровневые сложнее и мощнее => работы над настраиванием системы justification больше. Для этого как раз нужен Coding стандарт.
>в России есть стандарты на авиационку в этом семействе
КТ-178B?
По поводу внутренних стандартов не скажу, но исходя из вышеуказанного, они должны быть.
В том числе и на C. Высокоуровневые сложнее и мощнее => работы над настраиванием системы justification больше. Для этого как раз нужен Coding стандарт.
>в России есть стандарты на авиационку в этом семействе
КТ-178B?
По поводу внутренних стандартов не скажу, но исходя из вышеуказанного, они должны быть.
UFO just landed and posted this here
Просто ответить «потому что» не получится. Тут выше уже сказали, что машина имеет свойство сильно бюрократизироваться. Объясню с точки зрения влияния на ПО. В идеале есть план, по плану надо поэтапно реализовывать спецификацию. Отчитываться. Однако, программам свойственно получать от их создателей ошибки, а спецификации — от своих. Тогда, после того, как ошибка обнаружена за пределами Iteration Package (т.е. за пределами того, когда программист написал свой код и отдебажил), чтобы хоть что-то изменить, надо менять уже документы, которые так легко не меняются. Т.е. каждое новое изменение в коде будет занимать почти вдвое больше времени в отличие от предыдущего почти исключительно по бюрократическим причинам.
Однако, это не так плохо. Такой процесс как раз направлен на ловлю ошибок и недопущение их.
Поэтому, если взгляните на картинку со спиральной моделью, можно заметить, о чём я сейчас говорю. Хотя тестирование на ней явно преуменьшено, но, в целом, проверка-перепроверка документации и сверка со всеми изменениями занимает половину всего времени. Процесс разработки авиационного ПО — процесс перманентной валидации.
Тем не менее, факторами, которые мешают просто написать, скажем, лимитирование команды актуатора являются то, что:
— существуют ошибки в симуляторе, и результат инженерных тестов и дебага не такой, как ожидается, и надо тогда допиливать симулятор.
— особенность аппаратной архитектуры такова, что 1 из 100 фреймов приходит неверный, что не ожидалось в спецификации (допустим, из-за округления на ADC Resolver'a), тогда, вероятно, надо менять калибровочные параметры или по-другому обрабатывать данные.
— внесены изменения в SRD — меняется архитектура и требования, что равносильно ещё одной незапланированной итерации
— появился justification от заказчика (нет, даже не технического плана). Нет, это без проблем, это он доплатил и увеличил сроки. Но, тем не менее, это значит, что на данной и последующей итерации должен быть проведет анализ на изменения всех документов на изменения кегля шрифтов или нежелания видеть в LLR намёки на ASSERT'ы.
— косяк сопряженной команды (я об этом расскажу в следующий раз), который приведёт к тому, что слишком сложный для исправления баг превращается в фичу для них, но ведёт к исправлениям для текущей команды разработчиков, т.к. они менее критичны и ресурсоёмки.
В итоге, если бы не надо было делать идеальный код и идеальные тесты, вылизанные до запятой и каждой опечатке в слове «menue», то код можно было бы написать и проинтегрировать за 0,5 года. Но качество порождает процесс, проверки и перепроверки. Отчёты и отчёты об отчётах.
Однако, это не так плохо. Такой процесс как раз направлен на ловлю ошибок и недопущение их.
Поэтому, если взгляните на картинку со спиральной моделью, можно заметить, о чём я сейчас говорю. Хотя тестирование на ней явно преуменьшено, но, в целом, проверка-перепроверка документации и сверка со всеми изменениями занимает половину всего времени. Процесс разработки авиационного ПО — процесс перманентной валидации.
Тем не менее, факторами, которые мешают просто написать, скажем, лимитирование команды актуатора являются то, что:
— существуют ошибки в симуляторе, и результат инженерных тестов и дебага не такой, как ожидается, и надо тогда допиливать симулятор.
— особенность аппаратной архитектуры такова, что 1 из 100 фреймов приходит неверный, что не ожидалось в спецификации (допустим, из-за округления на ADC Resolver'a), тогда, вероятно, надо менять калибровочные параметры или по-другому обрабатывать данные.
— внесены изменения в SRD — меняется архитектура и требования, что равносильно ещё одной незапланированной итерации
— появился justification от заказчика (нет, даже не технического плана). Нет, это без проблем, это он доплатил и увеличил сроки. Но, тем не менее, это значит, что на данной и последующей итерации должен быть проведет анализ на изменения всех документов на изменения кегля шрифтов или нежелания видеть в LLR намёки на ASSERT'ы.
— косяк сопряженной команды (я об этом расскажу в следующий раз), который приведёт к тому, что слишком сложный для исправления баг превращается в фичу для них, но ведёт к исправлениям для текущей команды разработчиков, т.к. они менее критичны и ресурсоёмки.
В итоге, если бы не надо было делать идеальный код и идеальные тесты, вылизанные до запятой и каждой опечатке в слове «menue», то код можно было бы написать и проинтегрировать за 0,5 года. Но качество порождает процесс, проверки и перепроверки. Отчёты и отчёты об отчётах.
UFO just landed and posted this here
Сейчас не буду углубляться в архитектуру и аппаратную часть, но тем не менее:
— есть код, который создается сертифицированными кодогенераторами
— есть код, который пишется вручную, да, даже переписываются драйвера
— есть комбинации
Для шасси используются все эти походы.
Могу оценить исключительно рукописную часть, которая, естественно, была наименьшей по объему. Порядка 100 модулей (если бы это было бы ООП, скажем, C++ то модули — аналоги классов). На каждый модуль в среднем 500-1000 строк кода, описывающего его интерфейс и методы. Итого порядка 50 тысяч строк кода. Плюс, помножив на два — 100.00-200.000 строк кода в зависимости от нерациональности кодогенераторов и наличия комментариев.
— есть код, который создается сертифицированными кодогенераторами
— есть код, который пишется вручную, да, даже переписываются драйвера
— есть комбинации
Для шасси используются все эти походы.
Могу оценить исключительно рукописную часть, которая, естественно, была наименьшей по объему. Порядка 100 модулей (если бы это было бы ООП, скажем, C++ то модули — аналоги классов). На каждый модуль в среднем 500-1000 строк кода, описывающего его интерфейс и методы. Итого порядка 50 тысяч строк кода. Плюс, помножив на два — 100.00-200.000 строк кода в зависимости от нерациональности кодогенераторов и наличия комментариев.
«чтобы не пугать, о безопасности и отказоустойчивой архитектуре речь пойдёт в следующий раз»
А я вот попугать вас хочу… про специалистов-разработчиков сложных систем, которых нехватает не то, что у нас, но и в Америке. У меня есть знакомый, из города, где производят ПО, для спутников(вроде бы там же их и запускают)…
Общаясь с ним, года 2 назад, он сообщал свою з\плату — аж 20 тыщ рублей. При бюджете на запуск одного спутника в 200 миллионов рублей… и говорил — если кто-то что-то не то накодил, то спутник улетел не туда… и такое, он отметил, бывает довольно часто. :)
А я вот попугать вас хочу… про специалистов-разработчиков сложных систем, которых нехватает не то, что у нас, но и в Америке. У меня есть знакомый, из города, где производят ПО, для спутников(вроде бы там же их и запускают)…
Общаясь с ним, года 2 назад, он сообщал свою з\плату — аж 20 тыщ рублей. При бюджете на запуск одного спутника в 200 миллионов рублей… и говорил — если кто-то что-то не то накодил, то спутник улетел не туда… и такое, он отметил, бывает довольно часто. :)
З\п в США? Не хочу ставить под сомнение ваши слова, но у меня знакомый в США работает продавцом в местной ликёрке и то получает вдвое больше в пересчёте на рубли.
Да и про ГЛОНАСС наслышан из первых уст. Бардак-с.
Да и про ГЛОНАСС наслышан из первых уст. Бардак-с.
Про 20 тыщ, как я понял, имелось ввиду не в США, а у нас.
А вообще да, ситуация с з\п в авиаотрасли плачевна.
Я вот тоже занимаюсь разработкой авиаПО, но свою зарплату даже озвучивать не стану, а то можете не поверить, что за эти деньги работать можно.
А вообще да, ситуация с з\п в авиаотрасли плачевна.
Я вот тоже занимаюсь разработкой авиаПО, но свою зарплату даже озвучивать не стану, а то можете не поверить, что за эти деньги работать можно.
В начале было сказано:
«модель водопада или гибкой разработки могут быть не лучшим вариантом».
Насчет гибкой разработки понятно, а чем Waterfall здесь не подходит?
«модель водопада или гибкой разработки могут быть не лучшим вариантом».
Насчет гибкой разработки понятно, а чем Waterfall здесь не подходит?
Как минимум необратимостью. Все ошибки выгодно обнаруживать на ранней стадии проекта.
В худшем случае он может быть полностью переработан вместе с требованиями (на моей практике такое случалось, хоть и в мелком проекте). Плюс, контроль и тестирование происходят при максимально разумно малом изменении кода. Это минимизирует, в конечном итоге, стоимость проекта и, главное, позволяет избежать ошибок в нём. Плюс, ошибка может быть пропущена в 39 итерациях, но обнаружена на 40. И такое случается.
В худшем случае он может быть полностью переработан вместе с требованиями (на моей практике такое случалось, хоть и в мелком проекте). Плюс, контроль и тестирование происходят при максимально разумно малом изменении кода. Это минимизирует, в конечном итоге, стоимость проекта и, главное, позволяет избежать ошибок в нём. Плюс, ошибка может быть пропущена в 39 итерациях, но обнаружена на 40. И такое случается.
Водопад предлагает неплохие приемы по раннему обнаружению и предотвращению рисков разработки (вспоминая 5 приемов от Ройса).
С вашего комментария выбор именно В-методологии не ясен.
С вашего комментария выбор именно В-методологии не ясен.
Насколько я понимаю, классическая модель водопада предполагает необратимость процесса.
Даже если принять во внимание обратные связи между этапами на одном уровне, о которых говорил Ройс, то что вы будете делать на этапе тестирования, если обнаружена ошибка в требованиях? Или, вообще как обеспечить возможность изменения требования без перезапуска всего водопада?
Я молчу про этап внедрения (т.е. полётов), когда обнаруживается необычное поведение, вызванное замерзанием конденсата внутри поверхностей крыла, требующее усовершенствования кода и протоколирования в документации. Эти риски, пусть и со скрипом, но учитывает V-модель.
Не всего можно избежать на ранних этапах, особенно при предельной сложности и многокомпонентности системы, требующей максимально возможное отсутствие ошибок.
Даже если принять во внимание обратные связи между этапами на одном уровне, о которых говорил Ройс, то что вы будете делать на этапе тестирования, если обнаружена ошибка в требованиях? Или, вообще как обеспечить возможность изменения требования без перезапуска всего водопада?
Я молчу про этап внедрения (т.е. полётов), когда обнаруживается необычное поведение, вызванное замерзанием конденсата внутри поверхностей крыла, требующее усовершенствования кода и протоколирования в документации. Эти риски, пусть и со скрипом, но учитывает V-модель.
Не всего можно избежать на ранних этапах, особенно при предельной сложности и многокомпонентности системы, требующей максимально возможное отсутствие ошибок.
Понастольгировал. Довелось поработать в смежной области, правда для боевых ЛА (работал над СППЗ). Из собственного опыта могу сказать следующее:
1) Действительно бюрократизированный аппарат;
2) Лично у нас никаких систем контроля (кроме бумажек и total commander) впомине не было (там даже и не знают, что такое git/svn);
3) Очень трудно контактировать с людьми и получать более или менее внятное Т.З. Обычно на то, чтобы понять задачу и формализовать — уходило очень много времени (трудно понимать лётчика — а ему программиста);
4) Никаких тестировщиков(всё было на уровне — сам нагадил — сам и протестил);
5) Попытка включить что-либо новое(тот же git) — каралась расстрелом :);
6) Виноводочные напитки решали многие проблемы (неформальные отношения процветают и растут);
7) Чем сильнее вы программируете — тем сложнее работать в команде;
8) Иногда доходило до маразма получения библиотеки от стороннего отдела (куча бумажек, «тянемвремя» и т.д.) — но это пункт 1 (в общем то он главный).
9) Никакого единого стиля кода и т.д. (каждый пишет так как хочет) — к примеру со мной же работал дедок (довольно умный дяденька) — всю жизнь проработавший там программистом — но стиль его написания был С-подобным — о классах/шаблонах и т.д. не было и речи. (хотя и ТАКИМ людям от всей души выражаю благодарность), ибо именно благодаря ему, я познал всю тайну битовых полей, указателей на указатель на указатель и т.д.
10) Если есть женщины(бальзаковского возраста) в отделе — «чёс языка» — неизбежен.
В общем далеко от идеала. И самое интересное то, что попытки привлечь грамотных специалистов — заканчивались провалом — обычно они просто уходили — поняв «систему».
1) Действительно бюрократизированный аппарат;
2) Лично у нас никаких систем контроля (кроме бумажек и total commander) впомине не было (там даже и не знают, что такое git/svn);
3) Очень трудно контактировать с людьми и получать более или менее внятное Т.З. Обычно на то, чтобы понять задачу и формализовать — уходило очень много времени (трудно понимать лётчика — а ему программиста);
4) Никаких тестировщиков(всё было на уровне — сам нагадил — сам и протестил);
5) Попытка включить что-либо новое(тот же git) — каралась расстрелом :);
6) Виноводочные напитки решали многие проблемы (неформальные отношения процветают и растут);
7) Чем сильнее вы программируете — тем сложнее работать в команде;
8) Иногда доходило до маразма получения библиотеки от стороннего отдела (куча бумажек, «тянемвремя» и т.д.) — но это пункт 1 (в общем то он главный).
9) Никакого единого стиля кода и т.д. (каждый пишет так как хочет) — к примеру со мной же работал дедок (довольно умный дяденька) — всю жизнь проработавший там программистом — но стиль его написания был С-подобным — о классах/шаблонах и т.д. не было и речи. (хотя и ТАКИМ людям от всей души выражаю благодарность), ибо именно благодаря ему, я познал всю тайну битовых полей, указателей на указатель на указатель и т.д.
10) Если есть женщины(бальзаковского возраста) в отделе — «чёс языка» — неизбежен.
В общем далеко от идеала. И самое интересное то, что попытки привлечь грамотных специалистов — заканчивались провалом — обычно они просто уходили — поняв «систему».
Надо нашему начальнику отдела качества и директорам дать это почитать. Ато ведь так и будет «ладно, на станции доделаем как всегда».
Я один картинок не вижу?
Если кто-то не читал: Они пишут правильную вещь
Скажите, а есть ли какая-то объективная причина, кроме проблем с сертификацией оборудования, по которой ПО ютится в 128 кБ? Мне кажется, дешевле выйдет сэкономить на оптимизации, при такой-то стоимости каждой правки кода, купив вдвое больше памяти, чем нужно. То же относится к вычислительной мощности.
Проблемы сертификации оборудования.
Микросхемы должны иметь приёмку по стандартам авионики. Таких не так уж и много.
На самом деле, -O2 обычно хватает для всего (главная и критическая часть программы — это планирование задач). Если используются планируемые подпрограммы (задачи), которые куда-то надо записать, или, особенно, программы для наземного обслуживания, содержащие много кода для работы с терминалом, то обычно добавляется дополнительная быстрая Flash, которая почти неограниченно резиновая. Однако есть критичная часть программы, которая должна работать в режиме жесткого реального времени, что исключает возможность «просто добавить память».
К тому же за пару лет проблемы дефицита времени и пространства становятся всё менее актуальными, и поэтому есть тенденция переписывать код из спидхаков в легкочитаемый, но не очень оптимальный код, который, в конечном итоге, проще поддерживать даже лаборанту.
плавно превращается в обычный:
Микросхемы должны иметь приёмку по стандартам авионики. Таких не так уж и много.
На самом деле, -O2 обычно хватает для всего (главная и критическая часть программы — это планирование задач). Если используются планируемые подпрограммы (задачи), которые куда-то надо записать, или, особенно, программы для наземного обслуживания, содержащие много кода для работы с терминалом, то обычно добавляется дополнительная быстрая Flash, которая почти неограниченно резиновая. Однако есть критичная часть программы, которая должна работать в режиме жесткого реального времени, что исключает возможность «просто добавить память».
К тому же за пару лет проблемы дефицита времени и пространства становятся всё менее актуальными, и поэтому есть тенденция переписывать код из спидхаков в легкочитаемый, но не очень оптимальный код, который, в конечном итоге, проще поддерживать даже лаборанту.
bBoolValue = (bool_t)((0-(nVar1^TargetConst_C))>>SHIFT_31_BIT_C)^0x1;плавно превращается в обычный:
if (nVar1 == TargetConst_C)
bBoolValue = TRUE;
else
bBoolValue = FALSE;
Вопрос, везде написано, что используется схема с двумя компьютерами, собранными на разной элементной базе, с независимым программным обеспечение т.п. Как осуществляется резервирование? Как узнать какой из компьютеров выдаёт ложные команды? Если бы их было три, то можно было бы предположить резервирование, но их-то два.
Спасибо за статью. Заглянуть за кулисы такой закрытой области — дорогого стоит :)
Вопрос по тексту. Вы говорите
> Внесение результатов в систему контроля версий и отчётов (IBM Rational ClearCase\ClearQuest).
Я правильно понимаю — внесение идёт только после всех предыдущих шагов? Как насчёт сохранения промежуточных результатов? Обмен дельтой внутри команды? Можно где-то подробнее прочитать именно про SW configuration management и version control в вашем проекте?
Вопрос по тексту. Вы говорите
> Внесение результатов в систему контроля версий и отчётов (IBM Rational ClearCase\ClearQuest).
Я правильно понимаю — внесение идёт только после всех предыдущих шагов? Как насчёт сохранения промежуточных результатов? Обмен дельтой внутри команды? Можно где-то подробнее прочитать именно про SW configuration management и version control в вашем проекте?
Правильно понимимаете. После всех шагов, т.е. после окончания baseline.
Процесс ориентирован на то, чтобы не было промежуточных результатов => не было расхождений. Каждый разработчик выполняет свою часть, т.е. свою iteration package. Не трогая функциональности других людей (т.к. все пересечения должны быть выполнены на уровне создания архитектуры).
Однако, как вы правильно заметили, CVS действительно отсутствует, и если надо сравнить что-то, то используются разные компарсеры. Будь то в NPP или diff. И обмен в команде copy-paste. Се ля ви.
Возможно, в других местах используются git\svn, но в моей практике их не было.
Процесс ориентирован на то, чтобы не было промежуточных результатов => не было расхождений. Каждый разработчик выполняет свою часть, т.е. свою iteration package. Не трогая функциональности других людей (т.к. все пересечения должны быть выполнены на уровне создания архитектуры).
Однако, как вы правильно заметили, CVS действительно отсутствует, и если надо сравнить что-то, то используются разные компарсеры. Будь то в NPP или diff. И обмен в команде copy-paste. Се ля ви.
Возможно, в других местах используются git\svn, но в моей практике их не было.
Тогда другой вопрос — как часто выпускатся бэйзлайны? Ведь если между ними недели работы, то хранение нескольких версий кода ложится на плечи девелопера, а не SCM организации… Это чревато потерей данных, невозможность отследить разные версии своего кода и вообще много чем нехорошим. Лично вы как код сохраняете между бэйзлайнами и как это обычно делают другие?
В зависимости от проекта. В среднем 3-6 месяцев.
К сожалению всё так, как вы говорите. Можно локально для себя поднять SVN, можно складывать всё в разные папочки по версиям и по «Release_Super_New_Updated_3_1». Т.к. у меня были разные машины в разных местах планеты, то приходилось пользоваться вторым вариантом. В лучшем случае на удалённом диске на общем сервере, в худшем — на флешке.
Вообще это большая проблема, но из-за консерватизма с ней централизовано тяжело бороться. Хотя локально никто не мешает сделать жизнь лучше. Если есть походный ноут — так вообще без проблем.
К сожалению всё так, как вы говорите. Можно локально для себя поднять SVN, можно складывать всё в разные папочки по версиям и по «Release_Super_New_Updated_3_1». Т.к. у меня были разные машины в разных местах планеты, то приходилось пользоваться вторым вариантом. В лучшем случае на удалённом диске на общем сервере, в худшем — на флешке.
Вообще это большая проблема, но из-за консерватизма с ней централизовано тяжело бороться. Хотя локально никто не мешает сделать жизнь лучше. Если есть походный ноут — так вообще без проблем.
Если не секрет, какие операционные системы используются в авиации. Ну на нижнем уровне там понятно, скорее всего «голый си» на микроконтроллерах, а на верхних? Отображение, логика, etc?
Sign up to leave a comment.
Разработка ПО авионики