Является ли гибкое программирование слишком… специальным для систем, критичных к безопасности?[закрыто]

Question

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

Заметьте, я не совсем понимаю Agile.

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

Определение применимости гибких практик к миссиям и жизненно важным системам

Фильтры гибкой пригодности

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

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

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

Answer 5

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

Answer 6

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

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

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

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

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

Например:Уровень А:HUD, реверсии тяги, силовые системы, FADEC (управление двигателем) Уровень B:Вторичная коммутационная логика, системы голосовой связи.Уровень С:В ссылках на полетные данные.Уровень Д:Развлекательные системы в полете.

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

Answer 7

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

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

Answer 8

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

Так что это не очень Agile, но ...: -)

Answer 9

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

Answer 10

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