Учебное пособие 1438

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

Рис. 3. Поэтапная модель разработки ПО

3. Спиральная модель (86 – 90 гг., автор Барри Боэм) является типичным примером эволюционной стратегии, когда каждый виток соответствует созданию новой версии или фрагмента ПО. Требования не определены в начале разработки, а уточняются в ее процессе. На каждом витке планируются новые изменения и анализируется связанный с ними риск для создания нового витка. Планирование изменений строится на основе оценок прототипа заказчиком и внесенных заказчиком предложений. Создание прототипа может быть выполнено по каскадной модели ЖЦ или заменено макетом ПО. Анализ риска дает ответ на вопрос о целесообразности продолжении проекта: проект может быть остановлен или продвинут к более универсальной модели системы. Основной упор делается на анализе требований и проектировании. На первых 2-х этапах

13

создаются прототипы, проверяются и обосновываются технические решения.

Рис. 4. Спиральная модель ЖЦ

Преимущества спиральной модели состоят в:

накоплении и повторном использовании моделей, прототипов, программных средств;

ориентации на модификацию ПО при проектировании;

анализе риска и затрат при проектировании;

наиболее адекватном отражении реального процесса разработки ПО.

Но и спиральная модель не лишена недостатков, заключающихся в:

трудности планирования работ и определения сроков окончательной разработки;

необходимости постоянного присутствия при разработке квалифицированного заказчика.

14

Классическими считаются приведенные выше модели. Описанные ниже модели считаются лишь различными вариантами спиральной модели. Безусловно, эти типы моделей предполагают инкрементную стратегию разработки, но наличие значительных отличий, некой «изюминки», а также их широкое применение, выросшее в целую индустрию, могут привести к рассмотрению их как самостоятельных типов моделей ЖЦ.

Компонентно-ориентированная методика разработки,

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

Экстремальное программирование (Extreme Programming, XP) – применяется для маленьких коллективов разработчиков (обычно до 10 человек), при коротких сроках разработки в быстро меняющихся условиях на разработку или нечетком их определении. Предполагается многократное повторение этапов ЖЦ (инкрементная стратегия) и выпуск соответствующих версий, дополняющих возможности предыдущих. Автором XP является Бек Кент (1999 г.) [15].

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

15

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

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

2).Small release (частая смена версий), т.к. новую версию дает каждая итерация, длящаяся около 2-х недель.

3). Metaphor (метафора) обеспечивает глобальное видение проекта: каждый разработчик понимает, как работает система в целом.

4). Simple design (простое проектирование) - означает выбор самого простого решения на текущий момент. Любые сложности и «навороты» достойны только корзины.

5). Testing (тестирование) – сначала пишется тест, а затем код. Для модулей, которые должны выполняться эффективно и правильно, тесты пишутся постоянно. Для функциональной проверки ПС тесты разрабатывает заказчик.

6). Refactoring (реорганизация) – ПС может изменяться, но ее функции остаются постоянными. Изменения в ПС связаны с повышением ее эффективности, гибкости и упрощением.

7). Pair programming (парное программирование) – за одним компьютером код пишется двумя программистами.

8). Collective ownership (коллективное владение кодом)

– каждый разработчик может улучшать код в любое время.

16

9). Continuous integration (непрерывная интеграция) –

интеграция по несколько раз в день по мере завершения задач. После интеграции проводится тестирование поп полной программе.

10). 40-hour week (40 –часовая рабочая неделя) без авралов и прочих штурмов.

11). On-site customer (локальный заказчик) – заказчик всегда присутствует в группе разработчиков для оперативных ответов на возникающие вопросы.

12). Coding standarts (стандарты кодирования) – во всех частях программ используются одинаковые правила кодирования.

XP предполагает минимум проектной документации, т.к. постоянно происходит реорганизация ПС и, следовательно, происходит постоянное перепроектирование. Обычно после написания кода проектная документация выбрасывается, а остается лишь тогда, когда заказчик не может определить новые требования. Но и в этом случае пишется 5 – 10 страниц к данной версии.

Изменения требований объединяются заказчиком в истории, определяются их приоритеты, далее истории выстраиваются в порядке приоритета. Управляется XP с помощью специальной метрики, называемой скоростью проекта и опреде-

ляемой как количество историй заданного размера, которые могут быть реализованы за 1 итерацию.

Быстрая разработка приложений (Rapid Application Development -RAD) использует инкрементную стратегию разработки при малых сроках в 2 -3 месяца, основывается на всевозможных средствах автоматизации и компонентноориентированной технологии. Очень часто RAD используются при разработке информационных систем. Это вполне понятно, т.к. существует целый ряд распространенных программных продуктов (ERWIN, BPWIN, Rational Rose и др.), автоматизи-

17

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

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

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

Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПС с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей. Кроме того, RAD-технология не может обеспечивать разработку сложных продуктов, содержащих много фрагментов, программирование которых занимает более двух недель. Эта технология ориентирована скорее на разработку достаточно простой ПС, чем на промышленное производство систем.

Жизненный цикл ПС по методологии RAD состоит из четырех фаз:

18

анализа и планирования требований;

проектирования;

построения;

внедрения.

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

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

19

рабатываемой системы и принимается решение о разделении ее на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время, т.е. порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами. Результатом данной фазы должны быть:

общая информационная модель системы;

функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

точно определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами;

построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должны быть получены с при-

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

20

из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят изменения, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.

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

определяется необходимость распределения данных;

производится анализ использования данных;

производится физическое проектирование базы данных;

определяются требования к аппаратным ресурсам;

определяются способы увеличения производительно-

сти;

завершается разработка документации проекта. Результатом фазы является готовая система, удовлетво-

ряющая всем согласованным требованиям.

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

21

чального прототипа или должна быть интегрирована с разрабатываемой.

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

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

22