Создание Самолета, использующего Гибкий? [закрытый]

Конечно, можно выполнить рефакторинг плоскости.

При одном рефакторинге изменяется исходный код, а не двоичные файлы. С самолетом то же самое: изменяются чертежи, а не сам самолет.

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

Рассмотрите относительные затраты на проектирование и строительство. Если мы включим кодирование как часть процесса разработки программного обеспечения, то дизайн определенно станет дорогой частью, а сборка будет до смешного простой и дешевой. Большинство проектов Agile планируется выпускать как минимум каждые несколько итераций. Таким образом, мы можем работать небольшими итерациями с непрерывным процессом сборки. Не все так просто, когда нужно собирать самолет раз в две недели. Хуже, если вы действительно планируете "выпустить" его. Возможно, вам также понадобится привлечь специалистов по летной годности и безопасности к Agile-процессу.

Я действительно хотел бы увидеть его опробовать.

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

Из проектирования с использованием программного обеспечения САПР вам нужно сделать форму, взять кусок волокна и положить его на плоскость. И т.д. Итак, здесь тривиальное изменение имеет нетривиальную стоимость. В Agile вы можете внести очень небольшие изменения, и они будут протестированы, построены и готовы к отправке через 20 минут. Если небольшие изменения обходятся дорого, то короткий цикл разработки и рефакторинг не так полезны. Ваш отзыв может занять больше недели, поэтому есть веская причина подумать заранее, как в модели водопада. И каждая попытка требует материальных затрат, если вы не программируете. Идея не нова. Плотники измеряют дважды. Программисты сначала кодируют, а потом тестируют.

В общем. Может быть какое-то сходство, но однозначно будет то же самое.

Agile в программном обеспечении и Agile в производстве на самом деле сильно отличаются, хотя у них общие принципы и ценности.

Agile в производстве возникла в Японии в 1950-х годах. Прочтите WE Deming и производственную систему Toyota, чтобы узнать больше. Все дело в постоянном улучшении процесса , посредством которого воспроизводится продукт.

Гибкое программное обеспечение развивалось в начале 1990-х как модель быстрой разработки. Все дело в постоянном улучшении продукта .

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

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

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

Toyota первой внедрила бережливое производство, за которым последовали гибкие методологии. Построение аппаратного обеспечения для производства самолетов будет оптимальным вариантом, а для программного обеспечения - гибкой методологией.

Подбирайте правильные инструменты для работы.

Отличная книга о том, как создавался и работает TPS. http://www.amazon.com/Machine-That-Changed-World-Production/dp/0060974176

http://en.wikipedia.org/wiki/Toyota_Production_System

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

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

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

Это история завода по производству авиационных двигателей (сентябрь 1999 г.). Их методы кажутся довольно гибкими:

http://www.fastcompany.com/magazine/28/ge.html

Я почти уверен, что ответ неуместен. Даже если бы вы могли, вам бы не позволили. Слишком много требований безопасности. Вам даже не разрешат разрабатывать программное обеспечение для полета с использованием Agile. Например, у вас нет Спецификации требований к программному обеспечению (SRS) в Agile. Тем не менее, для любого программного обеспечения авионики на борту самолета, которое может повлиять на безопасность полета, вам понадобится SRS.

Это взято из http://requirements.seilevel.com/blog/2008/06/inosis-2008-can-you-build-airplane-with.html

*** На самом деле, это неправда, ***

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

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

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

Agile Can Работа со сложными системами

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

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

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

Короткие итерации: Итерации в значительной степени неслыханны, потому что V-модель - это одноразовый проход через жизненный цикл разработки. Тем не менее, итерации прототипирования посредством тестирования во многих случаях могут быть выполнены в системной инженерии. Проблема заключается в доставке чего-то готового в конце каждой итерации. Он предполагает, что при крупных развертываниях это не так важно для заказчика, как снижение риска, проверка требований и т. Д. Это отличный момент, чтобы вспомнить пример с самолетом! Могли ли мы через 2 недели получить хоть какую-то рабочую часть самолета? Что насчет даже программного обеспечения для запуска подсистемы на самолете?

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

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

Проблема с самолетом - это проблема безопасность. Это означает, что необходимо принять все меры предосторожности, от правильной идентификации и интерпретации требований до проверки и подтверждения каждой отдельной строки кода.

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