Зачем нам нужна разработка программного обеспечения? — Строительство

Зачем нам нужна разработка программного обеспечения?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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