Компонентно-ориентированная модель

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

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

Рис.7. Компонентно-ориентированная модель

Достоинства компонентно-ориентированной модели:

1. уменьшает на 30% время разработки программного продукта;
2. уменьшает стоимость программной разработки до 70%;
3. увеличивает в полтора раза производительность разработки.

Прогнозирующие и адаптивные процессы

В XXI веке потребности общества в программном обеспечении информационных технологий достигли экстремальных значений. Программная индустрия буквально «захлебывается» от потока самых разнообразных заказов.

Традиционно для упорядочения и ускорения программных разработок предлагались строго упорядочивающие тяжеловесные (heavyweight) процессы. В этих процессах прогнозируется весь объем предстоящих работ, поэтому они называются прогнозирующими (predictive) процессами. Порядок, который должен выполнять при этом человек-разработчик, чрезвычайно строг – «шаг вправо, шаг влево – виртуальный расстрел!». Иными словами, человеческие слабости в расчет не принимаются, а объем необходимой документации способен отнять покой и сон у «совестливого» разработчика.

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

Таким образом, в современной инфраструктуре программной инженерии существуют два семейства процессов разработки:

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

У каждого семейства есть свои достоинства, недостатки и область применения:

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

XP-процесс

Экстремальное программирование (eXtreme Programming, XP) – облегченный (подвижный) процесс (или методология), главный автор которого – Кент Бек (1999) . XP-процесс ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требовании.

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

Большинство принципов, поддерживаемых в XP (минимальность, простота, эволюционный цикл разработки, малая длительность итерации, участие пользователя, оптимальные стандарты кодирования и т.д.), продиктованы здравым смыслом и применяются в любом упорядоченном процессе. Просто XP эти принципы, как показано в табл. 2, достигают «экстремальных значений».

Тот, кто принимает принцип «минимального решения» за хакерство, ошибается, в действительности. ХР — строго упорядоченный процесс. Простые решения, име­ющие высший приоритет, в настоящее время рассматриваются как наиболее цен­ные части системы, в отличие от проектных решений, которые пока не нужны, а могут (в условиях изменения требований и операционной среды) и вообще не понадобиться.

Таблица 2 Экстремумы в экстремальном программировании

Базис ХР образуют перечисленные ниже двенадцать методов.

1. Игра планирования (Planning game) – быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продвижение (прогресс)

1. Частая смена версий (Small releases) – быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.
2. Метафора (Metaphor) – вся разработка проводится на основе простой, общедоступной истории о том, как работает вся система.
3. Простое проектирование (Simple design) – проектирование выполняется на­столько просто, насколько это возможно в данный момент.
4. Тестирование (Testing) – непрерывное написание тестов для модулей, которые должны выполняться безупречно; заказчики пишут тесты для демонстрации законченности функций. «Тестируй, а затем кодируй» означает, что вход­ным критерием для написания кода является «отказавший» тестовый вариант.
5. Реорганизация (Refactoting) – система реструктурируется, но ее поведение не изменяется; цель – устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.
6. Парное программирование (Pair programming) – весь код пишется двумя про­граммистами, работающими на одном компьютере.
7. Коллективное владение кодом (Collective ownership) – любой разработчик может улучшать любой код системы в любое время.
8. Непрерывная интеграция (Continuous integration) – система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гаранти­рует, что изменения требований не приведут к регрессу функциональности.
9. 40-часовая неделя (40-hour week) – как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.
10. Локальный заказчик (On-site customer) – в группе все время должен нахо­диться представитель заказчика, действительно готовый отвечать на вопросы
    разработчиков.
11. Стандарты кодирования (Coding standards) – должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.

Игра планирования и частая смена версий зависят от заказчика, обеспечивающего набор «историй» (коротких описаний), характеризующих работу, которая будет выполняться для каждой версии системы. Версии генерируются каждые две неде­ли, поэтому разработчики и заказчик должны прийти к соглашению о том, какие истории будут осуществлены в пределах двух недель. Полную функциональность, требуемую заказчику, характеризует пул историй; но для следующей двухнедель­ной итерации из пула выбирается подмножество историй, наиболее важное для заказчика. В любое время в пул могут быть добавлены новые истории, таким обра­зом, требования могут быстро изменяться. Однако процессы двухнедельной гене­рации основаны на наиболее важных функциях, входящих в текущий пул, следо­вательно, изменчивость управляется. Локальный заказчик обеспечивает поддержку этого стиля итерационной разработки.

«Метафора» обеспечивает глобальное «видение» проекта. Она могла бы рас­сматриваться как высокоуровневая архитектура, но ХР подчеркивает желатель­ность проектирования при минимизации проектной документации. Точнее гово­ря, ХР предлагает непрерывное пере проектирование (с помощью реорганизации), при котором нет нужды в детализированной проектной документации, а для ин­женеров сопровождения единственным надежным источником информации является программный код. Обычно после написания кода проектная доку­ментация выбрасывается. Проектная документация сохраняется только в том случае, когда заказчик временно теряет способность придумывать новые исто­рии. Тогда систему помещают в «нафталин» и пишут руководство страниц на пять-десять по «нафталиновому» варианту системы. Использование реоргани­зацииприводит к реализации простейшего решения, удовлетворяющего теку­щую потребность. Изменения в требованиях заставляют отказываться от всех «общих решений».

Парное программирование — один из наиболее спорных методов в ХР, оно влияет на ресурсы, что важно для менеджеров, решающих, будет ли проект использовать ХР. Может показаться, что парное программирование удваивает ресурсы, но ис­следования доказали: парное программирование приводит к повышению качества и уменьшению времени цикла. Для согласованной группы затраты увеличивают­ся на 15%, а время цикла сокращается на 40-50%. Для Интернет-среды увеличение скорости продаж покрывает повышение затрат. Сотрудничество улучшает процесс решения проблем, улучшение качества существенно снижает затраты сопровож­дения, которые превышают стоимость дополнительных ресурсов по всему циклу разработки.

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

«Тестируй, а затем кодируй» — эта фраза выражает акцент ХР на тестировании. Она отражает принцип, по которому сначала планируется тестирование, а тесто­вые варианты разрабатываются параллельно анализу требований, хотя традици­онный подход состоит в тестировании «черного ящика». Размышление о тестировании в начале цикла жизни — хорошо известная практика конструирования ПО (правда, редко осуществляемая практически).

Основным средством управления ХР является метрика, а среда метрик — «боль­шая визуальная диаграмма». Обычно используют 3-4 метрики, причем такие, ко­торые видимы всей группе. Рекомендуемой в ХР метрикой является «скорость проекта» — количество историй заданного размера, которые могут быть реализо­ваны в итерации.

При принятии ХР рекомендуется осваивать его методы по одному, каждый раз выбирая метод, ориентированный на самую трудную проблему группы. Конечно, все эти методы являются «не более чем правилами» — группа может в любой мо­мент поменять их (если ее сотрудники достигли принципиального соглашения по поводу внесенных изменений). Защитники ХР признают, что ХР оказывает силь­ное социальное воздействие, и не каждый может принять его. Вместе с тем, ХР — это методология, обеспечивающая преимущества только при использовании за­конченного набора базовых методов.