Почему ИТ-индустрия не может быстро и эффективно выполнять большие, безупречные проекты, как в других отраслях?

После просмотра серии MegaStructures в National Geographic меня удивило, как быстро завершаются крупные проекты. Когда предварительная работа (дизайн, спецификации и т. Д.) Выполняется на бумаге, сама реализация огромных проектов занимает всего несколько лет или иногда несколько месяцев .

Например, Airbus A380

479 голосов | спросил 5 revs, 5 users 62%
Arseni Mourzenko
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

30 ответов


321

Марш смерти Марта Эд Тейдона затрагивает число этих вопросов типа мета.

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

  • Стандартизация и разбивка рабочих элементов.

    • Это, безусловно, стало лучше, но конструктивных конструкций все еще не существует, чтобы вырвать большую систему. В некотором смысле, программное обеспечение не может даже согласиться с тем, что необходимо для данного проекта, а тем более неспособным сломать вещи на компоненты.
    • Аэрокосмическая промышленность, строительство зданий, авто и т. д. все имеют архитектуру с очень сложными компонентами с достаточно жесткими интерфейсами, позволяющими полностью параллельную разработку. Программное обеспечение по-прежнему допускает слишком много кровотока в соответствующих областях.
  • Большое количество успешных аналогичных проектов. A380 не был первым большим самолетом, построенным Airbus . Есть много больших программных приложений, но многие из них сильно пострадали в каком-то аспекте или другом и не приблизились бы к тому, чтобы их называли «успешными».

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

  • «Никогда», строя одно и то же дважды. Во многих отношениях самолет подобен любому другому самолету. У него есть крылья, двигатели, сиденья и т. Д. Крупные проекты программного обеспечения редко повторяются. Каждое ядро ​​ОС существенно отличается. Посмотрите на несоответствие в файловых системах. И в этом отношении, сколько действительно уникальных ОС есть? В какой-то момент большие становятся клонами базового элемента. AIX , Solaris , HP-UX , ... вернуться к AT&T System V . У Windows было невероятное количество перетаскивания вперед через каждую итерацию. Варианты Linux, как правило, все возвращаются к тому же ядру, что и Linus. Я поднимаю его, потому что варианты, как правило, распространяются быстрее, чем действительно уникальные, запатентованные ОС.

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

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

  • Постоянно измеряемая квалификация. Как правило, люди говорят о том, сколько лет они работали на языке X или в программировании. Время используется в качестве замены калибра или качества мастерства. Как уже упоминалось много раз, интервью и поиск хороших талантов в программировании сложно. Часть проблемы заключается в том, что определение «добро» остается очень субъективным.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
435

Ответ на удивление прост: у этих «других отраслей» do высокая частота отказов. Мы просто сравниваем неправильные вещи. Написание программного обеспечения часто называют «сборкой», поэтому мы сравниваем его с этапами производства или строительства в других отраслях. Но если вы посмотрите на это, это не конструкция вообще: это дизайн . Проекты программного обеспечения написаны в коде, а создание осуществляется с помощью компьютеров, будь то путем компиляции программного обеспечения или непосредственного интерпретации его на лету.

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

Итак, что мы делаем, когда планируем программное обеспечение? Ну, мы все еще разрабатываем, но на более ранней стадии.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
173

Чтобы указать некоторые цифры:

  1. Изменение требований после запуска ; например, когда первый завод Airbus A380 начал создаваться на заводе, я не могу поверить, что если бы кто-то захотел еще 200 мест, они были бы там поставлены; но в большом программном проекте даже после того, как программисты начали разработку, можно добавить еще 5 типов пользователей.
  2. Сложность - крупные программные проекты чрезвычайно сложны; вероятно, самые сложные проекты, разработанные и разработанные человеком,
  3. Недостаточно ресурсов тратится на архитектуру и фазу проектирования ;
  4. Незрелость поля - разработка программного обеспечения относительно молодая дисциплина по сравнению с другими инженерными сестрами; это имеет два значения: a) Не так много эвристики и передовой практики; b) Не так много очень опытных специалистов;
  5. Отсутствие математического доказательства - в большинстве случаев математические формальные методы не используются, чтобы доказать, что часть программного обеспечения работает по мере необходимости; вместо этого используется тестирование. Это справедливо в других областях техники, которые в большей степени полагаются на математику; причина этого - сложность;
  6. Rush - у многих менеджеров есть недостижимые сроки; поэтому качество кода помещается во-вторых, из-за крайнего срока.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
137

Посылка вопроса немного испорчена. Как A380, так и Boeing 787 были доставлены в течение многих лет.

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

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

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

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

Крупные сложные проекты трудны для людей во всех областях.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
105

Небоскреб парень. Не уверен, могу ли я ответить на ваш вопрос, но я могу, конечно, пролить свет на различные предметы в теме. Здания действительно происходят очень быстро. Основным ограничением является локаль (правила). Но в целом для высотного здания от начала до конца требуется от 3 до 10 лет.

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

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

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

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

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

Что касается аргумента дизайна и развития, я думаю, что оба процесса построены по дизайну. Звучит здорово, что они разделены, но дизайн невозможен, если вы не знаете, как все работает. Вы просто увеличиваете риск отказа.

Общая моя (потенциально неправильная) оценка в соответствии с вопросом OP заключается в том, что программирование - это скорее искусство, чем инженерное дело. Почему люди получают удовольствие и даже делают это бесплатно, находят выражение и элегантность в нем? Информатика также (как и на олове) больше науки, чем инженерии. Почему вы пытаетесь доказать алгоритмы вместо того, чтобы просто связывать существующие части и работать над тем, чтобы все работало? Не уверен, что это имеет смысл; Я не специалист по программному обеспечению.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
43

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
37

Представьте себе, что в середине дизайна Airbus A380 кто-то собрался на встречу и сказал: «Хе, мог бы построить его как триплан?» Другие присоединились к слову: «Да, да, триплан. Больше крыльев лучше». Следующие следующие годы потрачены на превращение дизайна A380 в триплан. На другой встрече кто-то говорит: «Триплан? Это уже старый. Мы хотим биплан. Просто удалите одно из крыльев».

Или представьте, что в середине проекта строительства моста кто-то говорит: «Хе-хе, мы только договорились с судоходной компанией. Им нужен мост еще на 40 футов выше, потому что их корабли намного выше. Спасибо. "

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
20

Как человек, работающий в области ИТ, я часто задавался вопросом о причинах низкого успеха в ИТ.

Как и другие в этой теме, я также часто объяснял неудачи незрелости ИТ, отсутствие подробных стандартов (да, я серьезно, вы когда-нибудь проверяли стандартный лист простого болта?) и отсутствие стандартных компонентов и модулей.

В других отраслях, таких как строительство зданий или строительство судов, также есть гораздо более «избитые пути»: знания и опыт конкретного прототипа решения, который - в индивидуальной форме - повторно используется снова и снова. Вы когда-нибудь задумывались, почему здания, корабли или самолеты разного размера и назначения каким-то образом выглядят так похожими? (есть исключения из правила, конечно ...)

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
15

Я боюсь, что я не согласен с вашим заявлением.

Airbus и Boeing являются двумя примерами компаний, которые строят самолеты. Сколько компаний, которые строят самолеты, есть? Очень немногие, если вы сравните его с тем, сколько компаний строят программное обеспечение.

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

Посмотрите на машины; Есть высококачественные производители, которые строят очень прочные и высокотехнологичные автомобили (думаю, Land Rover, Mercedes), и есть те, которые строят автомобили, которые не будут длиться год без необходимости их ремонта (думаю, Kia или Cherry). Это прекрасный пример отрасли с чуть более низким барьером входа, если бы у вас были слабые игроки.

Программное обеспечение ничем не отличается. С другой стороны, у вас много ошибок, Windows, Office, Linux, Chrome или Google Search - это очень качественные проекты, которые были доставлены вовремя и имели аналогичный уровень качества, как и самолет.

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
9

Цифровые строительные блоки могут быть 1 или 0. Между ними нет.

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
8

Я часто задавался вопросом то же самое. Конечно, чувствует себя (иногда), как будто мы - кучка любителей, которые не знают, что мы делаем. Мне не нравятся объяснения, которые возлагают вину на менеджеров или другие внешние факторы - мы, разработчики, должны нести ответственность за то, что мы создаем.

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

Это создало культуру, в которой ошибки являются частью повседневной жизни . Их принимают с пожиманием плечами. Хотя некоторые ошибки, вероятно, неизбежны, должны ли они доминировать наша повседневная работа ? Я полностью понимаю менеджеров, которые не чувствуют, что QA стоит того, потому что они ожидают ошибок. Я не понимаю программистов, которые не прикладывают никаких усилий для создания безошибочного кода, потому что исправление ошибок скучно, как черт.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
7

Инженерные стандарты и практика очень различны в ИТ (как независимая отрасль), чем в аэрокосмической отрасли , Это, пожалуй, наиболее легко понять, рассматривая, как ИТ-специалисты реагируют, когда сталкиваются с документами стандартов для ИТ в аэрокосмической сфере . Например, Joint Strike Fighter Стандарты C ++ , которые в последнее время пробиваются по Интернету.

Многие выражают недоумение или задумчивую отставку (мы бы могли сделать так); и многие из них обманывают, утверждая, что нет практического способа доставки потребительских товаров таким образом. Это может быть даже правильным, учитывая ожидания, а не потребителей, но управления. Существует много недоверия к кодировщикам, которые просто кода и кода в течение нескольких недель, а не демонстрации чего-либо. Бог поможет кодеру, который просто разрабатывает что-то в течение двух недель. Не так с самолетами.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
5

Некоторые вещи от меня:

1- Стандарты и части: они являются плоскими изготовителями , а не разработчиками. Я не совсем уверен, но я предполагаю, что многие части переданы на аутсорсинг. Они не строят свои собственные электронные /инструменты, они получают места от какой-то компании, двигатели, вероятно, разработаны в другом месте и т. Д.

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

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

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

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

Программное обеспечение, с другой стороны, имеет инкрементные изменения, которые часто просто «строят, что работает», но не обязательно готовые продукты. Кроме того, в ИТ нередко говорить «эй, давайте добавим еще один багажник в наш самолет, который вмещает еще 50 тонн».

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
5

Я думаю, что ответ довольно прост:

1). Физическое построение и реализация были до тех пор, пока люди имеют - у нас было тысячи лет, чтобы разработать наши методы и методы для реализации физических проектов. Программное обеспечение «строительство», которое требует совершенно нового и различного набора навыков, составляет не более 50 лет - нам еще не хватило времени, чтобы понять, что все это.

2) Виртуальное построение сложнее - вы должны «видеть» в себе все, что не имеет физической реальности вообще. Это требует от вас анализа и абстрактного много информации, прежде чем вы даже знаете, что должен выглядеть ваш продукт, и шаги, которые он предпримет, чтобы создать его. Не так, когда вы строите мост или здание.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
4

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

  

По сравнению с чем?

     

Прошивка - самая дорогая вещь во Вселенной. В своем замечательном   книга «Законы Августина», Норман Огастин, бывший генеральный директор Lockheed Martin,   рассказывает раскрывающуюся историю о проблеме, с которой сталкивается защита   сообщества. Высокопроизводительный истребитель представляет собой тонкий баланс   противоречивых потребностей: диапазон топлива и производительность. Скорость против веса. Это   кажется, что к концу 70-х годов бойцы были примерно такими же тяжелыми, как и   Когда-нибудь. Подрядчики, всегда добиваясь большей прибыли, смотрели напрасно   за что-то, что они могли бы добавить, что стоило много, но весило   ничего.

     

Ответ: прошивка. Бесконечная стоимость, нулевая масса. Авионика теперь счета   для более половины стоимости истребителя. Это часть изменений, когда   вы считаете, что последний американский истребитель F-22 стоит прохладно третьего   миллиарда поп-музыки. Огастин практически с радостью смеется, когда он   связывает эту историю.

     

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

     

Рассмотрим следующий вид пузыря, бесстыдно снятый из Википедии   и не проверяется на точность:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}
     

Это всего лишь 110 непространственных символов, возможно, отброшенных через час или   два. Предположим, у нас не было программного обеспечения, и мне пришлось реализовать сортировку, используя   другая стратегия. Что это будет стоить?

     

Инженер-механик может похвастаться тем, что его профессия построила сортировщиков   задолго до компьютеров. Рассмотрите сортировщик карт модели IBM на модели 1949 года   ( http://www.columbia.edu/acis/history/sorter.html) с пропускной способностью   из 650 карт в минуту, что меньше, чем наш фрагмент кода.   управлять даже на частоте 4 МГц Z80. Модель 82, конечно, только отсортирована   столбец карты за раз; полностью сортировать колоду можно   десятки проходов.

     

Сколько времени потребовалось для проектирования и создания этого зверя? Годы, без сомнения.   И его функциональность бледнеет по сравнению с нашим кодом, который так много   быстрее и может обрабатывать гигантские наборы данных. Но это было в 1949 году.   долгое время понадобилось бы для создания пузырьковой сортировки с электронных компонентов -   без FPGA и VHDL или CPU?

     

Через час мне удалось провести грубую блок-диаграмму, выше уровня чипа   (блоки имеют такие имена, как «сумматор», «16-битная защелка» и т. п.). Но   логика секвенций явно довольно грязная, поэтому я просто бросил в PLD,   предполагая, что в какой-то момент было бы нелегко написать   соответствующие уравнения. И, да, возможно, это нарушает   не-программируемое логическое правило, но для разработки и отладки всей этой логики   использование ворот в любое разумное время так маловероятно, как   газ-галлон.

     

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

     

Перевод грубой блок-схемы на схему может занять день.   Тогда настало время разработать и изготовить печатную плату, заказать и загрузить   (и изменить дизайн, чтобы справиться с неожиданным, но   неизбежные проблемы с окончанием срока службы), а затем, конечно, сделать схему   Работа. Мы могли бы говорить за несколько недель усилий и много денег для   борта, частей и соответствующего испытательного оборудования.

     

Все это, чтобы заменить 7 маленьких строк кода. Немного реальных встроенных программ   менее 10 000; многие превышают миллион. Сколько оборудования и как   потребуется много инженерных средств для замены реального, сверхразмерного   компьютерная программа?

     

Рассмотрим настоящую программу, такую ​​как электронная таблица. Сколько схем было бы   нужно сделать один без процессора? Это может быть размер   город.

     

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

Так вот! Программное обеспечение /прошивка имеет беспрецедентную сложность.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

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

Из-за относительной молодости разработки программного обеспечения и управления как дисциплины существует некоторая дезинформация и ложность, которые по-прежнему воспринимаются как факт (

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

Не все разработчики созданы одинаково. Некоторые из них хороши, другие, ну, нет.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

Соборы, используемые для строительства до 100 лет.

Для некоторых самолетов Airbus требуется 1 миллион строк кода.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

Крупные проекты часто встречаются в крупных организациях. Если вы никогда не работали в крупной организации, есть одна вещь, которая гарантирована, чтобы убить производительность и производительность: бюрократия.

Удивительно, но многие люди не знают, что такое бюрократия (ее часто путают с политикой), или даже если /когда у них проблема с бюрократией.

Недавно мы завершили проект по внедрению аутентификации смарт-карт. Первоначально он оценивался в три месяца. Прошло 15 месяцев. Не было никаких затрат, бюджета, объема или технических причин задержки. Объем был довольно узким - только для учетных записей с повышенными привилегиями (учетные записи администратора), около 1200 учетных записей.

Другим важным фактором являются ваши деловые партнеры. К ним относятся поставщики. Если у ваших партнеров возникла проблема, связанная с задержкой в ​​вашем проекте, не так много вариантов, которые действительно будут устранять проблему с задержкой. Они не работают непосредственно для вас, и вы не сможете уволить этого человека на партнера, который может быть причиной. Партнер может быть уволен или может быть подвергнут финансовым санкциям или сдерживающим факторам, но это не меняет того факта, что проект понесла задержка. Именно это произошло с Boeing, когда они взяли стратегию поиска мамонта с помощью Boeing 787 Dreamliner .

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

У меня для вас более короткая версия:

Все, что легко сделать или упростить, мы пишем программу, чтобы сделать это вместо нас.

А затем сражайтесь с метапроцессом.

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

Отсутствие ответственности ... Люди получают иск, когда самолет падает. Сектор программного обеспечения отказывается от какой-либо ответственности в любом программном дефекте, поэтому создает недостаток стимулов для создания надежного и безопасного продукта.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
2

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
2

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

Однако, когда дело доходит до программного обеспечения, оно становится намного сложнее . Например, как именно вы реализуете защищенную учетную запись для входа в систему и учетную запись пользователя? Какие библиотеки и инструменты вы можете использовать? С какими библиотеками и инструментами вы знакомы? Как именно вы собираетесь писать функцию хэширования + соления и , как вы гарантируете ее безопасность? . Вы можете сделать это во многих отношениях, что невозможно установить какие-либо фактические практические шаблоны проектирования /em> для такого рода вещей. Да, указанные шаблоны проектирования do существуют в меньших масштабах как «лучшие практики», но каждая отдельная программная система сильно отличается от других, и поле развивается и изменяется так быстро, что это существенно невозможно не отставать.

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

Определение «большого проекта» искажено.

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

  • Клон Pac-Man.
  • Калькулятор
  • Текстовый редактор

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

Хотя это вряд ли единственное, о чем можно было бы сказать , я думаю, что одна из основных вещей стоит отметить. Большинство продуктов предназначены для соответствия существующему поведению. Даже продукт, который является радикальным прорывом (например, автомобиль), как правило, построен в соответствии с существующим поведением и просто делает его немного проще /проще /дешевле /что бы это ни было. Да, часто существует побочный эффект some на существующее поведение (например, получение топлива для автомобиля вместо еды для лошадей), но большинство из них, как правило, является довольно незначительным побочным эффектом.

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

Airbus A380 не был успешным проектом, как вы уже упоминали. Я, случается, работаю в компании CAD /CAM, и мне сказали, что это (у нас тоже был prioject Airbus) было отложено на несколько лет, потому что они использовали другую версию программного обеспечения в разных компаниях. То есть различные части разрабатывались в разных частях света. И, объединившись, они узнали, что дизайн дизайна не интегрирован, поэтому они должны перепроектировать его в одной версии. Поэтому, глядя на него, я не думаю, что это было успешным. Если бы это произошло 2-3 года назад, это было бы сменой игры для Airbus.

Кроме того, что касается надежного программного обеспечения, вы смотрите на любой самолет, автомобиль (ABS, EPS, климат-контроль и т. д.) или космический челнок, у них есть более 50% программного обеспечения, которые управляют ими, и верьте мне, что они очень надежны. Просто мы ближе к программному обеспечению, и есть еще много программ, поэтому мы видим больше ошибок в них.

Посетите: http://www.globalprojectstrategy.com/lessons/case. PHP? ID = 23 и посмотрите, насколько успешным был Airbus A380.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

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

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

В чем-то вроде построения и большинства форм техники, вещи, которые в противном случае были бы в «библиотеке» в программном обеспечении, уже полностью разработаны. Хотите построить башню? Просто скопируйте и вставьте планы из существующей структуры с несколькими изменениями.

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

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

Огляните назад, насколько стандарты полностью изменились, от сборки до C на C ++ до Java, JavaScript, C #, PHP и т. Д. Существует не много кода, который можно перерабатывать с 10 или 20 лет назад. Это совсем другое, чтобы сказать ... автомобильная или авиационная промышленность, когда вы можете продолжать совершенствоваться по проектам с десятилетий назад.

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

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

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

У вас есть методы программирования, которые используют обширное тестирование, например экстремальное программирование (которое фактически использовалось на программные мегапроекты). Но с жесткими сроками (которые могут быть сделаны более целенаправленно), заманчиво пропустить все это программирование и запустить с ошибками. Стиль Joel Spolsky «всегда исправляющий все ошибки» сэкономит больше времени в долгосрочной перспективе, но недисциплинированные пропустят это и потерпят неудачу.

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

Я видел, что миллионные ИТ-проекты работали менее чем на 10 человек. Больше людей замедлили бы проект и добавили ненужную бюрократию. WhatsApp - пример небольшого проекта стоимостью в миллиарды долларов. Дело не в том, что крупные проекты невозможны, но вам просто не нужны тысячи людей, чтобы зарабатывать миллиарды долларов в программном обеспечении.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
0

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
-1

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

Использовать случаи

Сколько вариантов использования имеет самолет? Большая часть из них - просто летать из одного места в другое. Может быть, таких больше, как радар, управление трафиком и т. Д., Но прецедент ясен и не очень. В разработке программного обеспечения мы сталкиваемся с неясными требованиями и пользователями, которые не знают, чего они хотят. Различные пользователи нуждаются в различной конфигурации /потоке, может ли самолет быть настроен по желанию пользователя (я хочу иметь телевизор и холодильник!)?

Пользователь

Кто управляет самолетом? Пилот, соавтор, некоторые стюарды (если считаются) и операторы башни. Они все профи и имеют свои описания работы. Программное обеспечение используется noobs и манекенами, не говоря уже о злых хакерах и взломщиках, но все же необходимо интегрировать их с другими модулями (например, OpenID или Google AdSense ). Если самолет может эксплуатироваться под манекенами, все еще выживая от ракет или разбойников ниндзя, то вы можете сказать, что самолет имеет такое же качество с программным обеспечением.

Перекрестные платформы

Самолет летает только на небе земли. Я не уверен, как они справляются с туманным или ветреным или жарким, холодным и влажным климатом, но самолет не предназначен для полета на разных уровнях гравитации (я буду поражен, если он сможет летать до Марс ). Иногда приложение должно пережить разные платформы, например Internet Explorer, Google Chrome , Firefox и Safari для браузера (извините Опера ) , или Windows XP /7/8, или Linux для ОС. Не говоря уже о мобильных устройствах и разных разрешениях и ориентациях.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
-1

Если вы считаете, что другие отрасли без проблем завершают проекты, вы должны прочитать рассказ о здании Citigroup Center, построенном в 1977 году. Даже после почти 7 лет планирования и строительства здание было завершено с серьезным недостатком дизайна, что вызвало бы крах от события шторма, ожидаемого каждые 16 лет.

  

Другими словами, на каждый год Citicorp Center стоял, было около 1-в-16 шанс, что он рухнет.

Оригинальные дизайнеры не знали о проблемах, но, к счастью, его поймал студент, изучающий здание.

  

все казалось просто прекрасным - пока, как говорит ЛеМессурье, он получил телефонный звонок. По словам ЛеМессурье, в 1978 году студент-студент-архитектор связался с ним с смелым утверждением о здании ЛеМессурье: Центр Citicorp мог нанести удар по ветру.

Ремонт был сделан буквально на обложке ночи, в котором участвовало наименьшее количество людей, чтобы сохранить секретность дефекта дизайна.

Был подготовлен план аварийной эвакуации для радиуса 10 блоков, окружающего здание.

  

Они спаривались всю ночь и уходили на рассвете, так же, как жители жилища возвращались на работу.

     

История оставалась секретом, пока писатель Джо Моргенштерн не услышал, как ее рассказывают на вечеринке, и дал интервью LeMessurier. Моргенштерн сломал историю в The New Yorker в 1995 году.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132