Инвариантные проблемы разработки ПО

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

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

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

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

Практика создания ПО способствует разработке систем из настраиваемых программных пакетов — решений на основе COTS-продуктов или ERP-систсм (Enterprise Resource Planning System- система планирования корпоративных ресурсов). Программный пакет может обеспечить функции стандартного бухгалтерского учета, компьютерной обучающей системы или системы управления кадрами. Акцент смещается от разработки «с чистого листа» к «настройке» программного обеспечения, однако процесс производства все равно занимает значительное место.

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

Задачи программирования могут быть разными, но характер деятельности по анализу требований и системному проектированию, связанной с этими конструкциями, при разработке «с нуля» аналогичен. Таким образом, концептуальная конструкция (модель) сохраняется, несмотря на всевозможные изменения се представления (реализации).

Что еще более важно маловероятно, чтобы организация могла найти программный пакет для автоматизации ее ключевых бизнес-процессов. То, что заставляет компанию работать (и конкурировать), должно разрабатываться «с нуля» (или переделываться из унаследованной системы). Как верно было подмечено Шипсрским (Szyperski), «стандартные (программные) пакеты создают лишь гладкое игровое поле, а умение играть приходит совсем с другой стороны» [138].

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

• • CORBA (Common Object Request Broker Architecture — Общая архитектура брокера объектных запросов) от OMG (Object Management Group);
• • DCOM (Distributed Component Object Mode — Распределенная модель компонентных объектов) от Microsoft;
• • EJB (EnterpriseJavaBeans — Корпоративная технология для Java-приложений) от Sun.

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