Технология разработки программного обеспечения

• Трудно провести точную оценку ресурсов при наличии ограниченного объема информации. Каскадная модель часто заставляет проводить оценку затрат и планирование проекта после проведения довольно ограниченного объема анализа.
• Спецификацией требований становится письменный документ, описывающий и ограничивающий разрабатываемый продукт. Независимо от скрупулезности этого документа, пользователю по-прежнему трудно понять, будет ли готовая система, созданная по спецификациям, соответствовать его ожиданиям. Независимо от "прозрачности" и "читабельности" текстовых и схематических описаний, он все равно останется "безжизненным" документом по сравнению с "живым" инструментальным средством, которое будет поставлено в конце концов. Реальная обратная связь станет возможной только по завершении поставки готовой системы заказчику. Более того, заказчик может утвердить даже самое непонятные и "размытые" спецификации требований, которые в итоге окажутся недостаточно ясной отправной точкой для разработки. Коротко говоря, верификация документа спецификации требований, выполненная заказчиком, может быть крайне неэффективной, и основание на ней будущих разработок может привести к серьезным проблемам.
• Пользователь часто не имеет представления о точных требованиях, предъявляемых к программному приложению. В некоторых случаях он (пользователь) и не может иметь такого представления. Например, какие требования предъявлялись к электронной таблице до того, как была создана и предложена пользователям самая первая из них? Таким образом, предположение о том, что все требования должны быть "заморожены" до начала разработки, является далеким от реальности.
• Каскадная модель не подчеркивает необходимости предусмотрения изменений. Как раз наоборот: базовой философией модели является то, что необходимо стремиться к линейности, "замораживая" максимум из того, что можно, на ранних стадиях. К сожалению, жизнь показывает, что изменения происходят гораздо чаще, чем их ожидают. Однако, поскольку модель не предполагает изменений, их внесение весьма трудоемко, ненадежно и связанно с дополнительными затратами.
• Модель вводит в жизнь стандарты, в очень большой степени основанные на создании определенных документов в заданный срок. Фактически, весь процесс уже был охарактеризован как "приводимый в действие документацией". Все это может привести к бюрократическому стилю работы, где придется заполнять и согласовывать множество бланков, а разработчику придется обращать больше внимания на навязываемый стандартом синтаксис, а не на его семантику. Таким образом, может случиться так, что достаточно хорошо проработанные спецификации, включающие в себя большое количество схем и таблиц, будут написаны для недостаточно понятных пользовательских интерфейсов и функций.

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

Более того, поскольку система, которая будет поставлена пользователю, может совсем не соответствовать его пожеланиям, обслуживание и сопровождение должно начинаться немедленно. Но здесь возникают договорные препятствия: кто оплачивает дополнительные расходы на сопровождение? Такое сопровождение рассматривается как исправление ошибок (что, по логике, оплачивается разработчиком) или как попытка привести в соответствие вновь объявившимся требованиям (тогда все расходы несет заказчик). Теоретически, точный ответ на этот вопрос должен содержаться в документе спецификации требований.

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

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

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

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

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

2.4.2. Эволюционные модели

Как уже отмечалось ранее, разработчик должен признать тот факт, что отказы в первой версии программного продукта неизбежно приведут к необходимости его (или его части) переработки. "Сделай это дважды" — таков принцип Брукса (Brooks) [1995]. Если следовать данному подходу, то первая версия продукта должна рассматриваться как проба, основной целью которой является оценка осуществимости продукта и верификации требований. После этого данный продукт откладывается, и на основе, значительно подкрепленной тщательно продуманными требованиями, начинается настоящая разработка. Пользуясь общепринятой терминологией, первую версию продукта можно рассматривать как прототип временного использования. Фактически, первоначальная версия, или прототип, используется временно для получения разработчиком необходимой обратной связи, связанной с рисками разработки приложения (т. е. для как можно более точного понимания им предъявляемых к приложению требований). После этого по модели каскадного процесса разрабатывается вторая версия. Такой подход обеспечивает частичное решение некоторых проблем, рассмотренных в предыдущем разделе, например устранение недостатков требований. Однако при этом не устраняется временной разрыв между изначальным определением требований и поставкой заказчику готового программного приложения. Также не делается никаких намеков на необходимость предусмотрения изменений. Данный подход можно рассматривать как шаг в направлении более гибких и нестрогих подходов к жизненному циклу программного обеспечения, называемых эволюционными или инкрементными, подробно описанными в современной компьютерной литературе. Жесткий и монолитный подход в подробностях описывает все аспекты определенной стадии разработки до перехода к следующей стадии; до полного окончания цикла разработки ничто не работает и не существует в готовом виде. В противовес этому, инкрементный подход заключается в пошаговой разработке, где какие-то части определенных этапов откладываются для создания полезных наборов функций на ранних стадиях разработки проекта.

Боэм (Boehm) [1988] определяет эволюционную модель процесса как "модель, стадии которой состоят из расширяющихся приращений оперативного программного обеспечения, с направлением эволюции, определяемым опытом работы". Приращения могут поставляться заказчику по мере их разработки: это называется эволюционной или инкрементной поставкой.

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

Стратегию разработки, скрывающуюся за моделью процесса эволюции, можно сформулировать в следующей простой форме (см. Гилб (Gilb) [1988]):

1. Представь нечто реальному пользователю.
2. Согласуй добавленное значение с пользователем по всем критичным направлениям.
3. Откорректируй проект и требования на основании того, что существует на самом деле.

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

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

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

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

Инкрементный подход можно распространить на все этапы жизненного цикла ПО с целью достижения более мелкого разбиения в рамках процесса. Подобный наиболее общий подход называется инкременшной моделью разработки и поставки. Здесь осуществляется переход к этапу, охватывающему системные цели, архитектуру и планирование. Разработка начинается с анализа приращения на уровне требований; затем каждое приращение отдельно проектируется, кодируется, тестируется, собирается и поставляется заказчику. Другими словами, по-прежнему происходит следование каскадной модели, но для каждого отдельного приращения; общая модель процесса, таким образом, является последовательностью "мини-каскадных" процессов. Приращения разрабатываются один за другим на основании обратной связи с заказчиком. На самом деле, по мере того, как все пользователи начинают работать с поставленными компонентами, они начинают лучше понимать свои потребности. Это приводит к внесению изменений в требования для введения последующих приращений и редакций первоначального плана. Поскольку каждое приращение по своей сути проще целой системы, то с точки зрения разработчика проще предсказать ресурсы, необходимые для завершения задачи разработки в приемлемые сроки.

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

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