Когда следует избегать повторной работы?

Сергей Кузнецов

Обзор сентябрьского 2005 г. номера журнала Computer (IEEE Computer Society, V. 38, No 9, Сентябрь, 2005).

Авторская редакция.
Также обзор опубликован в журнале "Открытые системы"

Темой сентябрьского номера журнала является разработка программного обеспечения ("Software Development"). Этой теме посвящены три из пяти больших статей, опубликованных в обозреваемом номере. Тематическая подборка делалась без привлечения приглашенных редакторов, поэтому вводная заметка отсутствует, и я сразу начну с первой статьи подборки.

Статья называется "Итеративная повторная работа: что хорошо, что плохо, что ужасно" ("Iterative Rework: The Good, the Bad, and the Ugly"). Авторы – Ричард Фейрли и Мэри Джейн Уилшаэ (Richard E. Fairley, Oregon Health and Science University, Mary Jane Willshire, Colorado Technical University).

Поскольку на созидательные процессы разработки и модификации программного обеспечения влияют бесчисленные внешние, изменчивые воздействия, за один проход удается произвести только простейшие программные продукты. Долговременный опыт показывает преимущества итерационной разработки, в которой на каждом шаге используется программное обеспечение, разработанное на предыдущей итерации, и к нему добавляются возможности, продвигающие продукт по направлению к следующей версии. Когда разработчики создают средства следующей версии и проверяют их правильность, они переделывают предыдущую версию с целью совершенствования ее возможностей и устранения дефектов, обнаруживаемых при интеграции старой и новой версий. Может иметься много форм итерационной разработки в зависимости от целей проекта. Итерационное прототипирование (iterative prototyping) может способствовать развитию пользовательских интерфейсов. Быстрая (agile) разработка является способом тесного привлечения предполагаемого заказчика в процесс, который может повторяться ежедневно. Инкрементное построение (incremental build) позволяет разработчикам производить еженедельные промежуточные варианты развивающегося продукта. Спиральная модель (spiral model) может помочь группе разработчиков оценивать и смягчать риски при развитии продукта. На каждой итерации производится определенный объем повторной работы для совершенствования и налаживания существующих возможностей (и это хорошо). Однако чрезмерный объем повторной работы может быть признаком наличия проблем в требованиях к продукту, в квалификации и мотивации разработчиков, в используемых процессах или технологии разработки, а может быть, и сразу во всех этих аспектах разработки (это плохо). Чрезвычайно высокий объем повторной работы приводит к неприемлемым ситуациям (это ужасно). С другой стороны, слишком незначительный объем повторной работы может свидетельствовать о недостаточно анализе и тестировании или о недостаточной продуманности возможностей продукта, которые требуется поддерживать в следующей версии (это плохо и может обернуться ужасным). Понимание и корректировка основных причин возникновения проблем, приводящих к избыточному или недостаточному объему повторной работы, могут существенно повысить производительность труда, качество разработки, уровень удовлетворенности заказчиков и улучшить моральное состояние разработчиков. Организациям, стремящимся к совершенствованию этих факторов, следует постараться ответить на следующие вопросы:

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

Следующая статья написана Дэвидом Янценом и Хуссейном Саедяном (David Janzen, Simex LLC, Hossein Saiedian, University of Kansas). Статья называется "Управляемая тестами разработка: понятия, таксономия и будущие направления" ("Test-Driven Development: Concepts, Taxonomy, and Future Direction").

Стратегия разработки, управляемой тестами, (Test-Driven Development, TDD) требует автоматизированного написания тестов до начала разработки функционального кода в течение нескольких коротких и быстрых итераций. Хотя TDD применяется разработчиками с различных формах уже несколько десятков лет, эта стратегия разработки программного обеспечения продолжает привлекать все возрастающее внимание как один из ключевых компонентов практики экстремального программирования (eXtreme Programming, XP). XP – это быстрый метод (agile method), позволяющий разрабатывать объектно-ориентированное программное обеспечение с привлечением очень коротких итераций с небольшим предварительным проектированием. Хотя исходно стратегия TDD не ассоциировалась с XP, позже ее стали описывать как неотъемлемый компонент технологии XP, необходимый для анализа, проектирования и тестирования, позволяющий также производить разработку на основе рефакторинга, совместного владения, непрерывной интеграции и отваги программистов. Наряду с применением TDD для программирования и рефакторинга в XP, стратегия привлекает и существенное самостоятельное внимание. Разработчики создают специальные инструментальные средства для поддержки TDD в различных языковых средах. В многочисленных книгах объясняется, как следует применять понятия TDD. Исследователи начали изучать влияние TDD на снижение числа дефектов и повышение качества академических и производственных программных сред. Преподаватели обдумывают пути интеграции TDD в педагогику компьютерной науки и технологии программирования. Некоторые из этих работ реализуются в контексте проектов XP, а многие другие – независимо от XP. В основной части статьи авторы, прежде всего, уточняют смысл термина TDD, выделяя три существенных аспекта: тестирование, управление разработкой и сама разработка. Далее анализируются исторический и современный контексты применимости TDD. В завершение статьи рассматривается современное состояние TDD с точки зрения индустрии и академии. Авторы отмечают, что TDD может продолжить существовать, даже если XP утратит популярность. Требуются дополнительные исследования в области применимости TDD для повышения качества программного обеспечения. Нужно найти место тематике TDD в программах учебных курсов. Это даст студентам возможность приступать к практической работе будучи более дисциплинированными и обладающими более высокой квалификацией в области проектирования и тестирования программного обеспечения, что позволит производить надежные, повторно используемые и качественные программные продукты.

Авторами третьей и последней статьи тематической подборки являются Томас Месерви и Курт Фенстермахер (Thomas O. Meservy, Kurt D. Fenstermacher, University of Arizona). Название статьи – "Преобразовательная разработка программного обеспечения: дорожная карта MDA" ("Transforming Software Development: An MDA Road Map").

Комедийный актер Стивен Райт однажды пошутил: "У меня есть карта Соединенных Штатов … реального размера. В ней говорится, что ‘масштаб: 1 миля = 1 миля’. Я провел прошлое лето, складывая эту карту". Карта – это модель, представляющая географическую область в удобной для использования форме с сохранением только уместных подробностей; конечно, карта реального размера не соответствует этой характеристике. Подобно тому, как картографы создают различные виды карт с разной детализацией для моделирования различных географических аспектов, разработчики программного обеспечения традиционно концентрируются на единственной модели: код, который является эквивалентом фотоснимка, отображающего реальный размер. Модели широко используются для гибкого представления сложных систем. Модели могут рассматриваться на многих уровнях абстракции, и взаимно дополняющие виды моделей могут комбинироваться для обеспечения более понятного и точного представления систем, чем то, которое может обеспечить единственная модель. Многие специалисты в области разработки программного обеспечения в течение долгого времени пропагандировали использование моделей для понимания проблем, на решение которых направлена разработка программной системы, в то время, как в группах разработчиков модели обычно используются только на ранних стадиях проектов. Часто при начале конструирования системы разработчики забывают о модели и не обновляют ее при изменении своего понимания проекта. Многие разработчики программного обеспечения согласятся, что моделирование должно играть свою роль в каждом проекте. Однако отсутствует полное согласие относительно того, в чем должна состоять эта роль, как следует разработчикам интегрировать моделирование с другими процессами разработки, и кто должен участвовать в процессе моделирования. В 2001 г. международный консорциум Object Management Group (OMG) выступил с инициативой модельно-управляемой архитектуры (Model Driven Architecture, MDA, www.omg.org/mda) c претенциозной целью сдвига фокуса разработки программного обеспечения с написания кода на моделирование. Суть подхода MDA можно кратко охарактеризовать следующим образом. После формирования набора требований разработчики создают системную модель, удовлетворяющую этим требованиям. В исходной модели фиксируются эти требования, но отсутствует привязка к какой-либо конкретной технологической платформе. С использованием набора правил среда модельно-управляемой разработки затем преобразует эту платформенно-независимую модель (Platform-Independent Model, PIM) в модель конкретной платформы (Platform-Specific Model, PSM). Термин платформа в спецификациях MDA используется достаточно свободно, означая не только конкретную операционную систему, но и языковую платформу, например, Java или Python, и даже распространенные практические приемы разработки, такие как создание методов доступа к атрибутам класса. С идейной точки зрения, эти преобразования понижают уровень абстракции путем уточнения некоторых аспектов PIM. Поскольку уровень абстракции PSM все еще слишком высок для осуществления компиляции на заданный язык программирования, в среде MDA требуется второй набор преобразований для отображения конструкций PSM в программный код. При использовании MDA код программ не пишется напрямую программистами, а производится средой поддержки MDA из моделей, создаваемых разработчиками. При изменении проектных решений разработчики обновляют модель, а среда синхронизует код с измененной моделью. Модель не отбрасывается в начале кодирования, а находится в центре процесса разработки. MDA является частью более крупной тенденции индустрии программного обеспечения к наслаиванию дополнительных уровней абстракции над используемыми аппаратными средствами: языки высокого уровня заменяют языки ассемблера, библиотеки и каркасы заменяют изолированные сегменты кода, облегчая повторное использование, паттерны проектирования заменяют код, специфичный для отдельного проекта. Конечно, конечной целью процесса разработки программного обеспечения всегда будет работающий код программ. Перед MDA стоит важная проблема доведения моделей до конечной реализации, а на это не способны как имеющаяся сегодня технология, так и опытные программисты. Тем не менее, позволяя квалифицированным разработчикам преобразовывать наиболее потребные элементы моделей, MDA может помочь группам разработчиков программного обеспечения сконцентрировать свои усилия на моделировании и генерации большей части требуемого формального кода, позволяя квалифицированным разработчикам преобразовывать наиболее потребные элементы моделей.

Вне тематической подборки в номере представлены две статьи. Майкл Зида (Michael Zyda, USC Information Sciences Institute) написал статью "От виртуальной имитации к виртуальной реальности; от виртуальной реальности к играм" ("From Visual Simulation to Virtual Reality to Games").

В течение двух последних десятилетий разработки в области виртуальной реальности основывались на синтезе результатов, ранее полученных в областях интерактивной трехмерной графики, пользовательских интерфейсов и визуальная имитация. Это позволило разработчикам создать более открытую технологию, чем это было возможно в сообществе визуальной имитации, увеличить число людей, работающих с трехмерной графикой, а также развить науку, технологию и язык, существенно выходящие за пределы области визуальной имитации. После публикации в 1997 отчета National Research Council (NRC) "Modeling and Simulation—Linking Entertainment and Defense" (http://www.nap.edu/books/0309058422/html/index.html) сообщество видеоигр продвинулось в область, представлявшую до этого интерес, главным образом, для сообщества виртуальной реальности. Конечно, и в области виртуальной реальности происходит переход к работам, стимулируемым видеоиграми, и таким образом, оказывается влияние на эту индустрию. Поскольку большая часть исследований и разработок, выполняемых в сообществе игр, происходит параллельно с исследовательскими работами в области виртуальной реальности, появляется возможность воздействия на более широкую аудиторию. При наличии этих тенденций исследователи из области виртуальной реальности, стремящиеся к сохранению значимости своей работы, должны перенаправлять свои усилия в направлении исследований и разработки игр. Исследования в области игр оказывают влияние не только на индустрию развлечений, но и на правительственные и коммерческие организации, извлекающие пользу из возможностей имитации и обучения, обеспечиваемых серьезными играми.

Последняя большая статья сентябрьского номера – "Распределенное управление доступом в мультимедийных центрах данных Internet" ("Distributed Access Management in Multimedia IDCs") – написана Рафаи Бхатти, Базитом Шафиком, Мохамедом Шахабом и Арифом Гафуром (Rafae Bhatti, Basit Shafiq, Mohamed Shehab, Arif Ghafoor, Purdue University). Достижения в области Internet и родственных технологий совместно с быстрым распространением во Всемирной путине мультимедийных данных порождают бесчисленные возможности для бизнес-сообщества по обеспечению повсеместно доступных мультимедийных услуг. Компании могут использовать основанную на Web модель электронного предприятия не только для предоставления своих услуг в оперативном режиме разнообразным и распределенным заказчикам, но и для упрощения администрирования соответствующих служб. В базовой архитектуре центра данных Internet (Internet Data Center, IDC) обеспечиваются хранение и доставка огромному числу заказчиков больших объемов мультимедийных данных из единого виртуального местоположения. Обычно инфраструктурой IDC, хранящей данные, вычислительной и сетевой, владеют сторонние компании, взимающие плату с поставщиков контента за размещение служб. Хотя использование IDC дает возможность предприятиям обеспечивать услуги клиентам на основе инфраструктуры сторонней компании, динамическая природа этой среды заставляет серьезно относиться к политике управления доступом в разнородных доменах предприятий. Применение IDC для обслуживания мультимедийных данных усложняет проблемы, связанные с обеспечением сложных механизмов контроля доступа, которые обеспечивают безопасное распространение мультимедийного контента в Web. Поскольку, скорее всего, разнообразное использование мультимедийных данных будет возрастать, наличие этих проблем может отрицательно сказаться на применении в будущем IDC для обеспечения соответствующих услуг. В качестве практического примера рассматривается инициатива цифрового здравоохранения, выдвинутая несколькими штатами США. Использование технологии IDC для архивации, управления и распространения электронных историй болезней пациентов – от оцифрованных рентгеновских снимков до видеозаписей диагностических обследований, производимых ведущими практикующими врачами – может сделать возможным обеспечение системы здравоохранения в масштабах штата. Например, в ближайшем будущем в штате Индиана планируется образовать цифровую инфраструктуру для обеспечения медицинской помощи, включая, среди прочего, использование развитых средств биовизуализации для удаленного мониторинга и диагностирования пациентов. При обеспечении доступа к этому виду мультимедийной информации возникают определенные затруднения, касающиеся безопасности и конфиденциальности. Этот пример демонстрирует потребность в обеспечении безопасности мультимедийных служб, основанных на IDC, без отрицательного влияния на функциональные цели предприятий. Для решения этой проблемы авторы предлагают архитектуру программного обеспечения, абстрагируемую от специфики приложений и обеспечивающую основу построения среды, которая опирается на понятие описания класса служб в качестве источника формирования политики контроля доступа.

Приближается конец года, пора задуматься насчет возобновления своего членства в IEEE Computer Society. Всю необходимую информацию вы можете найти на сайте www.computer.org, а если что-то будет непонятно, обращайтесь ко мне. К вашим услугам, Сергей Кузнецов.