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

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

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

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

2.4.3. Модель, основанная на преобразовании

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

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

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

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

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

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

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

Рис 5. Идеальная модель, основанная на преобразовании

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

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

Подход на основе преобразований исследовался как двойственный метод доказательства правильности небольших программ. Доказательства правильности программ представляют аналитический подход, основанный на математических законах: здесь демонстрируется формальная структура для анализа правильности программы апостериорно (основываясь на опыте), т. е. после того, как программа уже готова. Преобразования — наоборот, являются конструктивным, математическим подходом: при наличии программы р и ее спецификаций, относящихся к предусловию Pre и постусловию Post, доказательства правильности программы описывают верификацию истинности отношения {Pre} р {Post}. Подход на основе преобразований пытается создать программу р, корректность которой была бы гарантирована заранее, при наличии пары спецификации <pre, Post>.

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

2.4.4. Спиральная модель

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

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

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

Рис. 6. Модель спирального процесса разработки программного обеспечения

Основной характеристикой спиральной модели является то, что она циклична, а не линейна, как каскадная модель (см. рис. 6). Каждый цикл спирали состоит из четырех стадий, каждая стадия в свою очередь представлена одним квадрантом декартовой диаграммы. Радиус спирали представляет расходы, понесенные в процессе на данном этапе; угловой размер представляет развитие процесса.

Этап 1 определяет цели рассматриваемой части продукта в разрезе получения нужных качеств. Более того, на этом этапе определяются альтернативы, такие как возможность закупки программного обеспечения, разработки его своими силами или повторного использования уже существующего, а также ограничения на применение данных альтернатив. Затем, на этапе 2 альтернативные варианты оцениваются с определением и обсуждением потенциальных рисков. Оценка рисков может потребовать планирования определенных видов деятельности, например создания прототипов или моделирования. Этап 3 состоит из собственно разработки и верифицирования продукта следующего уровня; так же как и раньше, стратегия, которой придерживается процесс, определяется анализом рисков. Наконец, этап 4 состоит из рассмотрения результатов выполнения предыдущих этапов и из планирования (при необходимости) следующей итерации спиральной модели.

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