Является ли гибкое программирование ... специальным для критически важных систем?

Question

Например, было бы невероятно опасно сделать это для авионики?

Примечание. Я не совсем понимаю Agile.

Answer 1

Я работал над системами управления воздушным движением, используя, по существу, процесс водопада, и эти проекты могли бы определенно воспользоваться гибкими практиками. Мне не нравится думать о том, какая часть кода работает «случайно», без какого-либо автоматизированного регрессионного тестирования на уровне единицы. И все, что нужно, - это что-то вроде красной селедки. Хотя это правда, что аэрокосмические системы, вероятно, настолько близки, насколько вы можете добираться до заданных требований к фронту, у вас еще есть аргументы в пользу значения двусмысленных требований, которые появляются только тогда, когда система должна принимать тестирование. Или у вас проблемы с пропускной способностью, которые никто не считал последними в игре из-за большой интеграции. Тест-первые, шип-решения, непрерывная интеграция, парное программирование - я думаю, что все это улучшило бы проекты, над которыми я работал.

ОБНОВЛЕНИЕ: Не говоря уже о том, как часто «проектные документы» были пакетом лжи к концу проекта, потому что дизайн обязательно эволюционировал перед лицом реальности. Agile признает факт появления дизайна, который так же реален в проектах Waterfall, как и в любом другом, вместо того, чтобы пытаться притвориться, что вы можете получить дизайн до того, как начнете писать код.

Answer 2

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

Answer 3

Вы можете использовать гибкий подход, но первый проход должен включать в себя аспекты безопасности и безопасности или, по крайней мере, обеспечивать их, чтобы вы не стреляли в ногу и в конечном итоге переписывали все это , Но я согласен с Брайаном, вам, вероятно, лучше использовать подход «Водопад» для таких проектов.

Answer 4

Determining the Applicability of Agile Practices to Mission and Life-Critical Systems

Agile Suitability Filters

Короче говоря, нет "Проворный" программирования. Существует множество практик. Некоторые из них лучше других, но в целом любой проект будет полезен для некоторых из этих практик.

Самой большой областью, с которой люди, как правило, занимаются, является Моделирование и архитектура. Есть много команд, которые используют гибкие методы - например, я знаю членов Fun3d team с NASA - они используют гибкие методы и имеют дело с вещами, такими как Space Shuttle.

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

Answer 5

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

Answer 6

Я работаю в аэрокосмической промышленности (специально для спутников), и мы используем гибридный подход, потому что перед нами стоят две разные проблемы: требования к реальному миру и требования к бизнес-процессам.

Мы используем подход, основанный на водопаде, для требований к космическим аппаратам и критических участков, потому что изменения на спутнике происходят медленно и редко, а прикручивание там плохое.

Но для постоянно меняющихся бизнес-процессов мы используем гибкий подход, поскольку , так как они летают на космическом аппарате, постоянно меняются из-за требований клиентов. Привинчивание означает, что в худшем случае пользователь получает не-хорошие результаты.

Answer 7

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

Но если требования безопасности применяются к строительному процессу, это может противоречить гибким методам.

Answer 8

На самом деле существует вариация модели водопада под названием V-модель, которая предпочтительнее, например, IEC61508. Это разновидность водопада, но с положениями о повторной итерации (-ях) основного проектного цикла. Основной целью повторных итераций в этом случае является рассмотрение проблем, обнаруженных на разных этапах процесса. Основная идея заключается в том, что в дальнейшем по дороге, с которой вы сталкиваетесь, проблема, в дальнейшем в вашем процессе вы должны пойти, чтобы позаботиться и проанализировать влияние ваших изменений.

Так что это на самом деле не Проворный, но ... :-)

Answer 9

Есть много соображений. Во-первых, ваша критическая безопасность. Если ваш ответ «A» или «B» (и действительно «A»), то абсолютно НЕ. Вам не удастся сделать Agile в любом случае в форме или форме. Существуют очень строгие стандарты кодирования, стандарты документации и стандарты процесса, требуемые от программного обеспечения уровня A (мой опыт около 15 лет). Это включает в себя:

• Полная прослеживаемость.
• Полный охват отрасли.
• Полный многоуровневый охват.
• Основные документы, провозглашенных DO-178B включают в себя: SRD, SDD, SCI, SCMP, SDP, TQP, SCI ...

Так вы не только должны удостоверить свой код, дизайн и требования, но вы также должны сертифицировать наборы инструментов, компиляторы, автоматизированное тестовое оборудование и т. д.

Короче говоря, это действительно не маленький подвиг, и это не будет сделано с небольшой командой. Аналогично, интерфейсы действительно прочные и очень специфичные, а также статические. Для изменения интерфейсов обычно требуется координация с 3+ компаниями (производство Airframe, Vender 1 - Vender 2).

Честно говоря, изменение кода на 12 строк может стоить до 170 000 долларов США. Конечно, изменение 500 строк кода составит 190 000 долларов. Короче говоря, есть огромные накладные расходы процесса, связанные с кодом уровня A (гораздо меньше с уровнем B, даже меньше с C и очень мало с уровнем D), делая небольшие итерации очень дорогостоящими; то есть. это стоит много денег, чтобы получить полностью заправленный и летающий 777, чтобы протестировать небольшое изменение. Даже системные тестовые лаборатории крупных коммерческих самолетов будут иметь скорость горения 10 000 долл. США в день.

Например: Уровень A: HUD, реверс тяги, Power-Systems, FADEC (управления двигателя) Уровня B: Вторичное переключение логика, система Vocal связь. Уровень C: В каналах передачи данных. Уровень D: В развлекательных системах полета.

Уровень D и, возможно, уровень C, могут быть кандидатами на Agile.

Answer 10

На конференции EuroStar 2009 Gittie Ottosen рассказала о том, как они проворны в своей компании. Что впечатляет, так это то, что эта компания Systematic создает программное обеспечение для воздушных судов, военных и т. Д. Они делают это в соответствии с CMMI 5, ISO 9001 и AQAP 150 & 2110. Поэтому я считаю, что гибкий может применяться к системам с высокими требованиями. Возможно, попытайтесь найти эту презентацию и попытайтесь получить от него больше информации.