Зачем нам нужна разработка программного обеспечения?
Чтобы понять необходимость разработки программного обеспечения, мы должны остановиться кратко, чтобы взглянуть на недавнюю историю вычислений. Эта история поможет нам понять проблемы, которые стали очевидными в конце 60-х и начале 70-х годов, и решения, которые привели к созданию области разработки программного обеспечения. Некоторые из этих проблем назывались «Кризис программного обеспечения», названный так для симптомов проблемы. Ситуацию можно было бы также назвать «Барьер сложностей», названный так по первопричиной проблем. Некоторые относятся к программному кризису в прошедшем времени. Кризис еще далек от завершения, но благодаря разработке многих новых технологий, которые теперь включены под названием разработки программного обеспечения, мы сделали и продолжаем добиваться прогресса.
В первые дни вычислений основная проблема заключалась в со зданием или приобретением оборудования. Программное обеспечение почти ожидало, что позаботится о себе. По мнению консенсуса, «аппаратное обеспечение» «сложно» изменить, тогда как «программное обеспечение» «мягкое» или легко меняющееся. По словам, большинство людей в отрасли тщательно спланировали разработку аппаратного обеспечения, но предоставили значительно меньше предусмотрительности для программного обеспечения. Если бы программное обеспечение не работало, полагали они, было бы легко изменить его, пока он не сработает. В таком случае, зачем прикладывать усилия к планированию?
Стоимость программного обеспечения составляла такую небольшую часть стоимости аппаратного обеспечения, что никто не считал очень важным управлять ее разработкой. Однако все видели важность создания программ, которые были эффективными и быстро работали, потому что это экономит время на дорогостоящем оборудовании. Предполагалось, что время людей будет экономить машинное время. Для тех, кто добился успеха в работе, малопринято.
Этот подход оказался удовлетворительным в первые дни вычислений, когда программное обеспечение было простым. Тем не менее, по мере усложнения вычислений программы стали более сложными, а проекты стали больше, тогда как программы с тех пор регулярно определялись, записывались, управлялись и поддерживались одним и тем же лицом, программы начали разрабатываться командами программистов для удовлетворения чужих ожиданий. [19659002] Индивидуальные усилия уступили место командам. Общение и координация, которые когда-то проходили в голове одного человека, должны были возникать между головами многих людей, что усложняло весь процесс. В результате коммуникация, управление, планирование и документация стали критическими.
Рассмотрите эту аналогию: плотник может работать один, чтобы построить простой дом для себя, не более, чем общую концепцию плана. Он или она могут работать или корректировать работу по мере продвижения работы. Вот как написаны ранние программы. Но если дом более сложный, или если он построен для кого-то другого, плотник должен более тщательно планировать, как должен строиться дом. Планы необходимо пересмотреть с будущим владельцем до начала строительства. И если дом будет построен многими плотниками, весь проект, безусловно, должен быть спланирован до начала работы, так что, когда один плотник строит одну часть дома, другой не строит другую сторону другого дома. Планирование становится ключевым элементом, поэтому цементные подрядчики заливают стены подвала, прежде чем плотники начнут обрамление. Поскольку дом становится более сложным, и необходимо скоординировать работу большего количества людей, требуются чертежи и планы управления.
Поскольку программы стали более сложными, ранние методы, используемые для составления чертежей (блок-схем), уже не были удовлетворительными, чтобы представлять эту большую сложность , И таким образом стало трудно для одного человека, который нуждался в программе, написанной для передачи другому человеку, программисту, только то, что хотел, или для программистов, чтобы передать друг другу то, что они делали. На самом деле, без лучших методов представления, даже одному программисту стало сложно следить за тем, что он делает.
Время, необходимое для написания программ, и их затраты стали превышать все оценки. Для систем было необычно стоить более чем в два раза больше, чем ожидалось, и потребовалось несколько недель, месяцев или лет дольше, чем ожидалось. Системы, переданные клиенту, часто не работали правильно, потому что деньги или время закончились до того, как программы могут быть сделаны так, как они были изначально предназначены. Или программа была настолько сложной, что каждая попытка исправить проблему вызвала больше проблем, чем исправлено. Когда клиенты наконец увидели, что они получают, они часто передумали, чего они хотят. По крайней мере, один очень большой проект военных программных систем стоимостью в несколько сотен миллионов долларов был оставлен, потому что он никогда не мог работать должным образом.
Качество программ также стало большой проблемой. Поскольку компьютеры и их программы использовались для более важных задач, таких как мониторинг средств жизнеобеспечения, качество программы приобретает новый смысл. Поскольку мы увеличили нашу зависимость от компьютеров и во многих случаях больше не могли обойтись без них, мы обнаружили, насколько важно, чтобы они работали правильно.
Изменение в сложной программе оказалось очень дорогостоящим. Часто даже заставить программу делать что-то немного другое было так сложно, что было легче выбросить старую программу и начать все заново. Это, конечно, было дорого. Часть эволюции подхода к разработке программного обеспечения заключалась в обучении разработке систем, которые были построены достаточно хорошо в первый раз, так что простые изменения могут быть сделаны легко.
В то же время аппаратное обеспечение становилось все менее дорогостоящим. Трубы были заменены транзисторами, а транзисторы были заменены интегральными схемами, пока микро-компьютеры стоимостью менее трех тысяч долларов не достигли нескольких миллионов долларов. В качестве индикатора того, как быстро происходят изменения, стоимость данного количества вычислений уменьшается на полтора раза каждые два года. Учитывая эту перегруппировку, время и затраты на разработку программного обеспечения уже не были настолько малы по сравнению с аппаратным обеспечением, что их можно было игнорировать.
По мере того, как стоимость аппаратных средств падала, программное обеспечение продолжало писать люди, чья заработная плата была растет. Экономия от повышения производительности в разработке программного обеспечения от использования ассемблеров, компиляторов и систем управления базами данных не выполнялась так быстро, как экономия на стоимости оборудования. Действительно, сегодня стоимость программного обеспечения не только не может быть проигнорирована, они стали больше, чем затраты на оборудование. Некоторые текущие разработки, такие как непроцедурные (четвертое поколение) языки и использование искусственного интеллекта (пятое поколение), свидетельствуют о растущей производительности разработки программного обеспечения, но мы только начинаем видеть их потенциал.
Другая проблема заключалась в том, что в прошлые программы были часто до того, как он был полностью понят, что программа должна делать. Как только программа была написана, клиент начал выражать недовольство. И если клиент недоволен, в конечном итоге продюсер тоже был недоволен. Со временем разработчики программного обеспечения научились выкладывать бумагой и карандашом именно то, что они намеревались сделать перед запуском. Затем они могли просмотреть планы с клиентом, чтобы убедиться, что они соответствуют ожиданиям клиента. Проще и дешевле вносить изменения в эту версию для бумаги и карандаша, чем делать их после того, как система была построена. Использование хорошего планирования делает менее вероятным, что изменения должны будут быть сделаны после завершения программы.
К сожалению, до тех пор, пока несколько лет назад не было хорошего метода представления, чтобы описать удовлетворительные системы, такие сложные, как те, которые разрабатываются сегодня. Единственное хорошее представление о том, как будет выглядеть продукт, — это сам готовый продукт. Разработчики не могли показать клиентам то, что они планировали. И клиенты не могли понять, какое именно программное обеспечение было тем, чего они хотели, до тех пор, пока оно не было окончательно построено. Тогда было слишком дорого изменить.
Опять же, рассмотрим аналогию строительства здания. Архитектор может составить план этажа. Клиент обычно может получить некоторое представление о том, что запланировал архитектор, и дать ответ на вопрос, подходит ли оно. Поэтажные планы достаточно легки для понимания мирянами, потому что большинство людей знакомы с рисунками, представляющими геометрические объекты. Архитектор и клиент разделяют общие понятия о пространстве и геометрии. Но инженер-программист должен представлять для клиента систему, включающую логику и обработку информации. Поскольку у них еще нет языка общих понятий, инженер-программист должен научить нового языка клиенту, прежде чем он сможет общаться.
Кроме того, важно, чтобы этот язык был простым, чтобы его можно было быстро узнать.