Жизненный цикл программного изделия и его модели

Жизненный цикл и методологии программирования

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

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

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

А правомерно ли переносить такой поход из сферы материального производства на программирование? Если да, то мы должны с самого начала разграничить два вида деятельности в этой области:

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

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

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

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

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

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