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

Процесс разработки ПО можно в общем разделить на следующие этапы:

1. Описание потребностей и их анализ
2. Дизайн программного продукта
3. Разработка
4. Проверка
5. Выпуск и внедрение продукта
6. Обслуживание продукта

Описание потребностей и их анализ

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

Дизайн программного продукта

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

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

• Надёжность
• Возможность внесения изменений
• Понятность
• Возможность повторного использования.

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

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

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

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

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

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

Зачастую полезно делить исходную задачу на модули, используя подход «снизу-вверх», а их уже в свою очередь разрабатывать, используя подход «сверху-вниз».

Методы разработки программного обеспечения

Для разработки ПО используются некоторые методы проектирования, основными из которых являются: структурное и объектно-ориентированное (ОО) проектирование.

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

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

В случае ОО проектирования на этапах анализа и дизайна часто используются инструменты UML (англ. UML - Unified Modeling Language (Единый Язык Моделирования)) .