Прототипирование программ как стихийный подход к программированию и анализ эволюционной модели быстрого прототипирования применительно к программированию на Форте Введение«Г-н Журден. Честное слово, я и не подозревал, что вот уже
более сорока лет говорю прозой» Жан-Батист Мольер. Мещанин во дворянствеДля любого программного продукта применимо понятие «жизненный цикл», которое включает в себя все этапы его существования, от планирования до вывода из эксплуатации. Различные модели жизненного цикла предполагают те или иные мероприятия и подходы к разработке, а поскольку каждая модель имеет свои достоинства и недостатки, при использовании неподходящей модели жизненного цикла можно получить существенное снижение качества получаемой программы. Стихийно сложилось положение, когда жизненный цикл программных продуктов в действительности представляет собой модель быстрого прототипирования (см. эпиграф). Для такой модели характерен «случайный» подход к программированию, когда кодирование и эксперименты с полученной программой имеют существенный приоритет над планированием, упорядоченным тестированием и документированием.
Поскольку в реальной ситуации ни одна из распространенных моделей жизненного цикла, видимо, не обеспечит идеального совпадения с имеющимися условиями, процесс разработки программ предполагает адаптацию модели жизненного цикла. Такой процесс подразумевает анализ известных недостатков выбранной модели и выбор методов их устранения или компенсации. Преимущества и недостатки эволюционной модели быстрого прототипирования изложены по [1].
Преимущества структурной эволюционной модели быстрого прототипированияКонечный пользователь может «увидеть» системные требования в процессе их сбора командой разработчиков; таким образом, взаимодействие заказчика с системой начинается на раннем этапе разработки
Исходя из реакции заказчиков на демонстрации разрабатываемого продукта, разработчики получают сведения об одном или нескольких аспектах поведения системы, благодаря чему сводится к минимуму количество неточностей в требованиях
Снижается возможность возникновения путаницы, искажения информации или недоразумений при определении системных требований, что несомненно приводит к созданию более качественного конечного продукта
В процесс разработки можно внести новые или неожиданные требования пользователя, что порой необходимо, так как реальность может отличаться от концептуальной модели реальности
Модель представляет собой формальную спецификацию, воплощенную в рабочую модель
Модель позволяет выполнять гибкое проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла
При использовании модели образуются постоянные, видимые признаки прогресса в выполнении проекта, благодаря чему заказчики чувствуют себя уверенно
Возможность возникновения разногласий при общении заказчиков с разработчиками минимизирована
Ожидаемое качество продукта определяется при активном участии пользователя в процесс на ранних фазах разработки
Возможность наблюдать ту или иную функцию в действии пробуждает очевидную необходимость в разработке функциональных дополнительных возможностей
Благодаря меньшему объему доработок уменьшаются затраты на разработку
Благодаря тому, что проблема выявляется до привлечения дополнительных ресурсов, сокращаются общие затраты
Обеспечивается управление рисками
Документация сконцентрирована на конечном продукте, а не на его разработке
Принимая участие в процессе разработки на протяжении всего жизненного цикла, пользователи в большей степени будут довольны полученными результатами
Недостатки структурной эволюционной модели быстрого прототипированияСубъективная оценка автором степени существенности недостатка помечена цветом. Ниже дан комментарий.
Модель может быть отклонена из-за создавшейся среди консерваторов репутации о ней как о «разработанном на скорую руку» методеНедостаток явно несущественен, поскольку в форт-сообществе не наблюдается консерваторов такого рода.
Разработанные «на скорую руку» прототипы, в отличие от эволюционных ускоренных прототипов, страдают от неадекватной или недостающей документацииКрайне актуальный недостаток, который устраняется в считанных вариантах форт-систем.
Если цели прототипирования не согласованы заранее, процесс может превратиться в упражнение по созданию хакерского кодаДостаточно актуальный недостаток в настоящее время. Более того, хакерский код регулярно приветствуется в Форте в противовес хорошо проработанным решениям с известными характеристиками. Существуют точки зрения, обосновывающие допустимость хакерских решений исключительными особенностями Форта и элитарностью языка.
С учетом создания рабочего прототипа, качеству всего ПО или долгосрочной эксплуатационной надежности может быть уделено недостаточно вниманияНи «качеству всего ПО», ни «эксплуатационной надежности» в стихийном прототипировании не уделяется вообще никакого внимания. Критерии качества не имеют сформулированных метрических показателей (исключение – «прохождение теста на ANSI»), эксплуатационная поддержка осуществляется нестабильно, на основе багрепортов. Характерна реакция вида «эта реализация Форта имеет открытые исходные тексты, значит, заметивший ошибку пользователь должен исправить ее и отправить авторам исправленную версию».
Иногда в результате использования модели решение трудных проблем может отодвигаться на будущее. В результате это приводит к тому, что последующие полученные продукты могут не оправдать надежды, которые возлагались на прототипНедостаток характерен для разработок, выполняемых энтузиастами. На устранение этого недостатка негативно влияет тенденция публикации исходных текстов с целью привлечения других разработчиков для решения сложных проблем. При этом авторы, как правило, не разъясняют (или не осознают) незавершенность продукта, а кажущаяся простота дальнейшего развития привлекательна для программистов с недостаточной квалификацией. Поэтому вместо разработки собственной реализации Форта или решения трудных проблем ими продолжается реализация вспомогательных слов и алгоритмов низкой сложности.
Если пользователи не могут участвовать в проекте на итерационной фазе быстрого прототипирования жизненного цикла, на конечном продукте могут отразиться неблагоприятные воздействия, включая проблемы, связанные с его качественной характеристикойНедостаток проявляется ограниченно. Пользователи разрабатываемых форт-систем участвуют в их развитии ограниченно, не существует однозначного механизма реализации обратной связи – подходящие замечания могут включаться в список будущих исправлений, тогда как неподходящие игнорируются. Формулирование требований фортерами-пользователями также неоднозначно, смешиваются требования к эксплуатационным характеристикам форт-системы и к способам достижения этих характеристик, т.е. фрагментам кода и техническим решениям.
На итерационном этапе прототипирования быстрый прототип представляет собой частичную систему. Если выполнение проекта завершается досрочно, у конечного пользователя останется только лишь частичная система.Это общая проблема проектов, переводимых в открытый код после кратковременной стадии прототипирования с целью привлечения других разработчиков. Подразумевается, что при наличии доступа к исходным текстам проект будет в короткие сроки доработан, однако этого не происходит в силу того, что опубликованные материалы имеют характер прототипа. Поэтому разработчики привлекаются фактически для продолжения прототипирования, что требует существенных усилий по координации работ, а не для выполнения кодирования по готовым спецификациям.
Несовпадение представлений заказчика и разработчиков об использовании прототипа может привести к созданию другого пользовательского интерфейса.Существует как минимум три варианта использования Форта – консольное приложение, оконное приложение, системная служба/подключаемая библиотека. Вопросы адаптации интерфейса к целевой ОС слабо зависят от используемого языка, и в Форте проработаны неравномерно.
Заказчик может предпочесть получить прототип, вместо того, чтобы ждать появления полной, хорошо продуманной версииНедостаток не является существенным, поскольку в данном случае предпочтения заказчика могут основываться на его желании самостоятельно доработать продукт, осознавая его незавершенность.
Если язык или среда прототипирования не сочетаются с производственным языком или окружением, всесторонняя реализация продукционной системы может быть задержана.Как правило, неактуально вследствие того, что разработка финальной версии ведется с помощью тех же инструментов, что и прототипа
Прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл «кодирование – устранение ошибок» (code-and-fix cycle), что приводит к дорогостоящим незапланированным итерациям прототипированияКрайне существенный негативный фактор, тормозящий развитие способностей программиста к самоорганизации. Фортеры имеют тенденцию к пренебрежению организационными мероприятиями, противопоставляя им «открытость» и «гибкость» языка. Это приводит к насыщению восприятия разработчика и торможению проекта на уровне, когда он еще может быть удержан в «операционном поле» одного человека.
Разработчики и пользователи не всегда понимают, что когда прототип превращается в конечный продукт, все еще существует необходимость в традиционной документации. Если она отсутствует, модифицировать модель на более поздних этапах может оказаться более дорогостоящим занятием, чем просто не воспользоваться созданным прототипомВажный недостаток, подтверждаемый крайне недостаточной документированностью многих реализаций Форта. Необходимость документирования часто противопоставляется «гибкости» и «расширяемости», а также наличию исходных текстов. Распространение исходных текстов может способствовать фиксации текущего решения, и разработчики попадают в цикл бесконечной модификации распространяемых текстов.
Когда заказчики, удовлетворенные прототипом, требуют его немедленной поставки, перед менеджером программного проекта возникает соблазн пойти им навстречу.Для Форта данная проблема проявляется как реакция «возьмите мое, я уже давно написал». Предложение собственной реализации транслятора или утилиты, несмотря на их незавершенность или частичную пригодность, является частым явлением в форт-сообществе. Предложение мотивируется простотой доработки Форта, хотя на деле заказчику предлагается самостоятельно решить сложные проблемы (см. выше об откладывании на будущее решения сложных проблем).
На заказчиков могут неблагоприятно повлиять сведения об отличии между прототипом и полностью разработанной системой, готовой к реализации.Ввиду относительно небольшого объема форт-системы отличия между прототипом и полностью разработанной системой заключаются в основном в объеме словаря.
На заказчиков может оказать негативное влияние тот факт, что они не располагают информацией о точном количестве итераций, которые будут необходимыЕсли заказчики программ на Форте являются пользователями Форта, они, как правило, существенно вовлечены в процесс разработки.
На разработку системы может быть потрачено слишком много времени, так как итерационный процесс демонстрации прототипа и его пересмотр могут продолжаться бесконечно без надлежащего управления процессом. У пользователей может возникнуть стремление пополнять список элементов, предназначенных для прототипирования, до тех пор, пока проект не достигнет масштаба, значительно превышающего рамки, определенные анализом осуществимости проектного решенияЗначимый недостаток, регулярно проявляющийся в чрезмерно перегруженных списках требований, которые формируются вместо технических спецификаций. Простота Форта необоснованно принимается за простоту разработки программ на нем как таковых, независимо от степени сложности решаемой задачи. Компактность реализации и возможность расширения синтаксиса также необоснованно принимаются за способ кардинально уменьшить трудоемкость любой разработки, независимо от возможного наличия в ней объективно высокой алгоритмической сложности, не зависящей от используемого языка.
При выборе инструментальных средств прототипирования (операционные системы, языки и малопродуктивные алгоритмы) разработчики могут остановить свой выбор на менее подходящем решении, только чтобы продемонстрировать свои способностиНедостаток является существенным. В определенной степени, Форт сам по себе является языком, демонстрирующим способности программиста. Поэтому он провоцирует использование неуместных приемов программирования, которые демонстрировали бы исключительность Форта, вне зависимости от того, помогают ли эти приемы достижению эффективных результатов.
Структурные методы не используются, чтобы не помешать выполнению анализа. При прототипировании необходимо провести «реальный» анализ требований, осуществить проектирование и обратить внимание на качество с целью создания программы, допускающей сопровождение, точно так же, как и в любой другой модели жизненного цикла (хотя на эти действия может понадобиться меньше времени и ресурсов).Данный недостаток лежит в основном в организационной области и мало соотносится со свойствами языка программирования.
Итоговый анализ недостатков дает следующую статистику:
Несущественных – 6
Неопределенной степени важности - 3
Существенных – 9
В конечном итоге можно сделать вывод, что стихийный подход к программированию на Форте, выражающийся в использовании (по факту) модели эволюционного прототипирования, имеет более 50% существенных недостатков, что и затрудняет разработку качественных программных продуктов. Для повышения качества разработки (имея в виду не код, а процесс выпуска программного обеспечения в целом) следует либо обратить особое внимание на устранение рассмотренных недостатков, либо использовать другие модели жизненного цикла, смягчающие остроту проблем.
Литература:1. Фатрелл Р.Т., Шафер Д.Ф., Шафер Л.И. — Управление программными проектами