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

Создание систем программного обеспечения — это сложная и трудоемкая работа, требующая высокой квалификации участвующих в ней специалистов. Однако создание таких систем выполняется на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования программного обеспечения. По данным Института программной инженерии (Software Engineering Institute, SEI) в последние годы до 80% всего эксплуатируемого программного обеспечения разрабатывалось без использования какой-либо дисциплины проектирования, методом «code and fix» (кодирования и исправления ошибок).

В конце 60-х годов прошлого века в США было отмечено явление под названием «software crisis» (кризис программного обеспечения). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

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

Актуальность исследования определяется современными тенденциями проектирования программного обеспечения распределенных информационных систем со структурным и объектно-ориентированным подходом.

Цель исследования состоит в изучении взаимосвязи структурного и объектно-ориентированного подходов к проектированию программного обеспечения распределенных информационных систем.

Для достижения цели определены следующие задачи исследования:

• 1. Проведение анализа научно-технической литературы в аспекте структуры и содержания курсов, ориентированных на изучение объектно-ориентированного и структурного программирования.
• 2. Изучение теоретических основ структурного и объектно-ориентированного подходов, технологии создания программного обеспечения.
• 3. Ознакомление с методическими основами создания программного обеспечения.
• 4. Рассмотрение внедрения технологий создания программного обеспечения в организации для реализации выполнения пилотного проекта.
• 5. Обосновать сопоставление и взаимосвязь структурного и объектно-ориентированного подходов при создании программного обеспечения распределенных информационных систем.

Объект исследования — процесс обучения объектно-ориентированному программированию с предварительным рассмотрением алгоритмических конструкций структурного языка.

Предмет исследования — теоретические и методические подходы к обучению структурного и объектно-ориентированного программирования.

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

Для решения поставленных задач использованы следующие методы исследования: анализ работ в области теоретической информатики, ресурсов сети Интернет по проблемам объектно-ориентированного программирования; наблюдение, выявление взаимосвязанности структурного и объектно-ориентированного программирования.

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

Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Результаты исследований, выполненных в 1995 году компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой программного обеспечения, выглядели следующим образом:

• — только 16, 2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;
• — 52, 7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;
• — 31, 1% проектов были аннулированы до завершения;
• — для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения — на 122%.

В 1998 году процентное соотношение трех перечисленных категорий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).

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

В числе причин возможных неудач, по мнению разработчиков, фигурируют:

нечеткая и неполная формулировка требований к программному обеспечению;

недостаточное вовлечение пользователей в работу над проектом;

отсутствие необходимых ресурсов;

неудовлетворительное планирование и отсутствие грамотного управления проектом;

частое изменение требований и спецификаций;

новизна и несовершенство используемой технологии;

недостаточная поддержка со стороны высшего руководства;

недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.

Объективная потребность контролировать процесс разработки сложных систем программного обеспечения, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания программного обеспечения и появлению совокупности инженерных методов и средств создания программного обеспечения, объединенных общим названием «программная инженерия» (software engineering). В основе программной инженерии лежит одна фундаментальная идея: проектирование программного обеспечения является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания программного обеспечения позволяет повысить его качество, обеспечить управляемость процесса проектирования программного обеспечения и увеличить срок его жизни. В то же время, попытки чрезмерной формализации процесса, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) привели к ряду серьезных проблем. После двух десятилетий напрасных ожиданий повышения продуктивности процессов создания программного обеспечения, возлагаемых на новые методы и технологии, специалисты в индустрии программного обеспечения пришли к пониманию, что фундаментальная проблема в этой области — неспособность эффективного управления проектами создания программного обеспечения. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически, в режиме «тушения пожара». Бессистемное применение технологий создания программного обеспечения, в свою очередь, порождает разочарование в используемых методах и средствах (анализ мнений разработчиков показывает, что среди факторов, влияющих на эффективность создания программного обеспечения, используемым методам и средствам придается гораздо меньшее значение, чем квалификации и опыту разработчиков). Если в таких условиях отдельные проекты завершаются успешно, то этот успех достигается за счет героических усилий фанатично настроенного коллектива разработчиков. Постоянное повышение качества создаваемого программного обеспечения и снижение его стоимости может быть обеспечено только при условии достижения организацией необходимой технологической зрелости, создании эффективной инфраструктуры как в сфере разработки программного обеспечения, так и в управлении проектами. В соответствии с моделью SEI СММ (Capability Maturity Model), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества процессов создания программного обеспечения на протяжении всего жизненного цикла программного обеспечения и на уровне всей организации.

Одна из причин распространенности «хаотического» процесса создания программного обеспечения — стремление сэкономить на стадии разработки, не затрачивая времени и средств на обучение разработчиков и внедрение технологического процесса создания программного обеспечения. Эти затраты до недавнего времени были довольно значительными и составляли, по различным оценкам (в частности, Gartner Group), более $ 100 тыс. и около трех лет на внедрение развитой технологии создания программного обеспечения, охватывающей большинство процессов жизненного цикла программного обеспечения, в многочисленной команде разработчиков. Причина — в «тяжести» технологических процессов. «Тяжелый» процесс обладает следующими особенностями:

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

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

В начале 2001 года ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит, Кент Бек и другие) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке программного обеспечения, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка программного обеспечения» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки программного обеспечения» (Agile Alliance’s Manifesto) и заключающихся в следующем:

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

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

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

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

• — C — дефекты вызывают потерю удобства;
• — D — дефекты вызывают потерю возместимых средств (материальных или финансовых) ;
• — E — дефекты вызывают потерю невозместимых средств;
• — L — дефекты создают угрозу человеческой жизни.

Масштаб определяется количеством разработчиков, участвующих в проекте:

• — от 1 до 6 человек — малый масштаб;
• — от 6 до 20 человек — средний масштаб;
• — свыше 20 человек — большой масштаб.

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

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

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