Необходимость в технологии создания ПО

Каждый программист думает, что он может написать любую программу. На самом деле это не так. Попробуйте в одиночку написать операционную систему, например, Linux. Или интегрированную среду программирования для С++. Совершенно ясно, что, даже если программист способен справится с такими задачами, ему потребуется для этого много времени. Конечно, среди нас всегда есть гении, которые в одиночку могут выполнить работу группы обычных людей-разработчиков и добиться в своей области успеха[1].

Фредерик Брукс[1] пишет: «Время от времени можно прочесть в газете о том, как в переоборудованном гараже пара программистов сделала замечательную программу, оставившую позади разработка больших команд. … Почему же до сих пор все профессиональные бригады программистов не заменены одержимыми дуэтами из гаражей? Нужно посмотреть на то, что, собственно, производится». Брукс различает программу, программный комплекс, программный продукт и комплексный программный продукт. «В гаражах» обычно создается программа. Разработка программного комплекса или программного продукта, по оценке Брукса, не менее чем в три раза более трудоёмка, чем создание программы. Создание же комплексного программного продукта обходится ещё втрое дороже.

Гради Буч[2] называет комплексные программные продукты промышленными программными продуктами. Примерами такого ПО являются операционная система, например, Windows, интегрированная среда программирования типа Visual Basic, система продажи билетов или система управления комическим полетом, например, станции «Мир». В России наиболее ярким примером является система 1С. Системы подобного типа обычно имеют большое время жизни, и большое количество пользователей оказывается в зависимости от их нормального функционирования.

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

· сложностью реальной предметной области, из которой исходит заказ на разработку;

• трудностью управления процессом разработки;

· неудовлетворительными способами описания поведения больших дискретных систем.

· необходимостью обеспечить достаточную гибкость программы;

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

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

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

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

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

3. Внутрикомпонентная связь обычно сильнее, чем связь между компонентами. Это обстоятельство позволяет отделять взаимодействия внутри компонентов от динамики взаимодействия между компонентами.

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

4. Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных.

Иными словам, разные сложные системы содержат одинаковые (или, по крайней мере, очень похожие) структурные части. Эти части могут использовать общие более мелкие компоненты. Посмотрите на мир флоры и фауны. Тело любого млекопитающего состоит практически из одинаковых частей: ноги, туловище, голова, хвост.

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

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

Сложность, о которой мы говорим, по-видимому, присуща всем большим программным системам. Говоря "присуща", мы имеем в виду, что эта сложность здесь неизбежна: с ней можно справиться, но избавиться от нее нельзя. В прошлом это факт не осознавался, хотя Майерс[28] обращает внимание на то, что еще в 1952 году было опубликовано следующее признание: «Те, кто регулярно программирует для электронных вычислительных машин, знают на собственном опыте, что солидная доля подготовительного этапа работы на ЭВМ уходит на устранение ошибок, сделанных при составлении программы. С помощью здравого смысла и отладочных подпрограмм большинство ошибок удается найти и исправить достаточно быстро. Однако некоторые из них настолько неуловимы, что не поддаются обнаружению удивительно долгое время».

В 70-х годах заговорили о кризисе программного обеспечения. Насколько это серьезно, показывают аналитические исследования в области разработки ПО. Вендров [7] приводит следующие данные. В 1995 году компания Standish Group проанализировала работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО. Только 16,2% проектов были завершены в срок, уложились в запланированный бюджет и реализовали все требуемые функции и возможности; 31,1% проектов были аннулированы до завершения; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме. Для проектов, которые были аннулированы или завершились с опозданием, бюджет в среднем был превышен на 89%, а срок выполнения – на 122%. В 1998 году процентное соотношение изменилось в лучшую сторону, но не намного (26%, 46%, 28% соответственно).

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

Определение 1. Программная инженерия – это совокупность инженерных методов и средств создания программного обеспечения.

Способ управления сложными системами был известен еще в древности - divide et impera (разделяй и властвуй). При разработке сложной программной системы необходимо разделять ее на все меньшие и меньшие подсистемы, каждую из которых можно развивать независимо. Это следует и из анализа признаков сложной системы. Однако при разработке ПО требуется управлять не только «пространством», но и временем.

Жизненный цикл ПО

Определение 2. Жизненный цикл программного обеспечения - это период времени от момента принятия решения о необходимости создания ПО и до момента его полного изъятия из эксплуатации.

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

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

· определение целей и требований;

· проектирование;

· реализация;

· испытания.

Возможна и более мелкая детализация, однако мы этого делать не будем.

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

Этап проектирования обычно делят на 2 стадии: внешнее и внутреннее проектирование. На первой стадии определяют, что должен делать программный продукт. А на второй стадии уже разрабатывают то, как он будет это делать. Результатом деятельности на первой стадии является документ (возможно, не один), определяющий архитектуру системы и её взаимоотношение с внешним миром. В американской литературе этот документ называют «внешние спецификации».

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

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

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

Таким образом, если говорить о предмете изучения «технология программирования», то необходимо рассматривать три разных технологии: технологию проектирования, технологию программирования и технологию проверки программного продукта. В данном курсе технология проектирования рассматривается обзорно, а основное внимание уделяется технологии программирования и технологии проверки.

Можно провести аналогию с любой сферой человеческой деятельности. Например, в строительстве выполняется три разных вида работ: создается архитектурный проект, затем разрабатывается инженерный проект, после чего выполняется ещё и проект производства работ. И только потом приступают непосредственно к строительству. После строительства дом сдается в эксплуатацию. То же самое можно увидеть и а любой производственной сфере, выпускающей некоторые крупные изделия, например, автомобили или самолеты. Сначала автомобиль конструируется до детального уровня. По сделанному проекту автомобиль создается на заводе. Затем проводят его испытания, после чего начинают тиражирование данной модели. Каждая стадия создания автомобиля имеет собственную сложившуюся технологию, закрепленную в многочисленных стандартизирующих документах.