4. Разработка должна быть дружественной пользователю. Она должна быть для пользователя, а не пользователь для нее. Из этого следует несколько выводов:

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

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

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

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

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

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

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

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

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

Базис современной программной инженерии образуют следующие составляющие:

- процессы конструирования ПО;

- метрический аппарат, обеспечивающий измерения процессов и продуктов;

- аппарат формирования исходных требований к разработкам;

- аппарат анализа и проектирования ПО;

- аппарат визуального моделирования ПО;

- аппарат тестирования программных продуктов.

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

Хотелось бы обратить внимание на новейшие постобъектные методологии - аспектно-ориентированное и многомерное проектирование и программирование. Они представляют собой новую высоту в стремительном полете в компьютерный космос. Но это - тема другой отдельной работы.

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

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

Список литературы