Технология Rapid Application Development

Введение
С момента появления первых электронно-вычислительных машин разработка программного обеспечения прошла длинный путь: от возможности написать простую программу для вычисления формулы до осознания того, что именно от технологии разработки программного обеспечения зависит прогресс в вычислительной технике [2, с.4]. Сначала развитие вычислительной техники было сосредоточено на решении технических проблем, основное внимание уделялось аппаратуре, а программирование зависело от заинтересованных в нем лиц. По мере того, как вычислительные машины становились мощнее и надежнее, повышалось значение программного обеспечения. Важным этапом считают появление языков программирования высокого уровня (в конце 50-х годов). Они упростили процесс программирования и существенно расширили круг задач, которые стали решаться с помощью вычислительной техники. Но затем создатели программного обеспечения стали отмечать, что имеющихся в их арсенале средств и приемов недостаточно для успешного решения поставленной задачи. Развитие объектно-ориентированного подхода в технологии программирования подтолкнуло развитие сред визуального программирования. Каждое новое достижение в аппаратном либо в программном обеспечении обычно приводит к попыткам расширить сферу применения ЭВМ, тем самым ставит новые задачи, для решения которых нужны новые возможности.Целью написания данного реферата является изучение теоретических аспектов технологии программирования.Из выше указанной цели можно выделить следующие задачи: технология Rapid Application Development, рациональный унифицированный процесс Rational Unified Process итехнология Extreme Programming.1 Технология Rapid Application Development1.1 Понятие технологии Rapid Application DevelopmentТехнология RAD (англ. Rapid Application Development) основана на спиральной модели жизненного цикла и обеспечивает ускорение разработки ИС благодаря широкому привлечению к процессу проектирования будущих пользователей. Для данной технологии характерно перенесение основных объемов работ с предпроектной стадии на стадию проектирования [3, с.10]. Представители заказчика получают возможность контролировать весь процесс создания системы, оперативно влиять на состав и реализацию ее функций. Основателем RAD считается сотрудник IBM Дж. Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Б. Бема и С. Шульца. В 1991 году Дж. Мартин опубликовал книгу, в которой детально изложил концепцию RAD и возможности ее применения.1.2 Особенности технологии RAD Применение технологии RAD целесообразно в тех случаях, когда: Требования к программному обеспечению (ПО) определены нечетко или не полностью. Во многих случаях заказчик весьма приблизительно представляет себе работу будущей системы и не может четко сформулировать все требования к ней. Интерфейс пользователя является для заказчика главным фактором. RAD-технология дает возможность продемонстрировать этот интерфейс в прототипе почти сразу после начала проекта. Требуется выполнение проекта в сжатые сроки. Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня. Если система проектируется долго, то высока вероятность того, что за это время существенно изменятся условия деятельности организации, т. е. система морально устареет еще до завершения ее проектирования. Проект выполняется в условиях ограниченности бюджета. Разработка ведется небольшими RAD-группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения. ПО не обладает большой вычислительной сложностью. RAD применима для систем средней сложности, обладающих элементами новизны. Если проектируемая система велика, то она должна допускать разбиение на более мелкие функциональные компоненты. Они могут выпускаться последовательно или параллельно. К основным приемам RAD относятся [3, с.11]: Использование прототипирования, позволяющего полнее выяснить потребности пользователей. Вовлечение пользователей в процесс разработки системы. Разработка приложений итерациями, многократное возвращение к более ранним этапам ЖЦ. Необязательность полного завершения работ на одном этапе жизненного цикла для начала работ на следующем этапе. При итеративном подходе пропущенные работы можно выполнить впоследствии. Переход к следующему этапу ЖЦ осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах. Высокая степень параллельности работ. Повторное использование частей проекта. Применение CASE-средств (CASE – Computer Aided System Engineering), обеспечивающих техническую целостность проекта на всех этапах проектирования, в том числе использование генераторов (мастеров). Применение средств управления конфигурациями, облегчающее внесение изменений в проект и сопровождение готовой системы. Как уже отмечалось, технология RAD является примером использования спиральной модели жизненного цикла ИС. Жизненный цикл ИС состоит из многократно повторяемых четырех стадий: Анализ требований и планирование. Проектирование. Реализация. Внедрение версии. Работа над проектом ведется группами. Типичный состав группы – руководитель, аналитик, два-три программиста, технический писатель. Если проект сложный, то для него может быть выделено несколько RAD-групп. При этом системы разбиваются на подсистемы, и каждая подсистема разрабатывается независимой группой. Проект выполняется в условиях тесного взаимодействия между разработчиками и заказчиком. RAD-группа всегда работает только над одним прототипом. Это обеспечивает единство целей, лучшую наблюдаемость и управляемость процессом разработки, что в итоге повышает качество конечного продукта. Используемые инструментальные средства должны обеспечивать групповую разработку и конфигурационное управление проектом. Ключевой фактор успеха здесь – правильное разбиение системы на подсистемы. Все группы должны использовать общие стандарты проектирования. Обязательно проводится финальное тестирование всей системы. Создание прототипов ИС делает требования более реальными, приближает варианты использования к жизни и закрывает пробелы в понимании требований. Прототипы предоставляют пользователям экспериментальную модель новой системы, стимулируя их мышление и активизируя обсуждение требований. Обсуждение прототипов на ранних стадиях процесса разработки помогает заинтересованным в проекте лицам прийти к общему пониманию требований к системе, что уменьшает риск неудачи проекта. Традиционно для проектов среднего уровня сложности разрабатываются три прототипа. Первый содержит весь пользовательский интерфейс с нулевой функциональностью. Он дает возможность собрать замечания заказчика и после их устранения утвердить экранные формы и документы. Второй прототип содержит реализованную на 70–80 % функциональность системы, третий – полностью реализованную функциональность [3, с.12]. RAD-технология не является универсальной, ее применение целесообразно не всегда. Например, в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется, и более эффективным может быть каскадный метод. То же касается проектов, сложность которых определяется необходимостью реализации сложных алгоритмов, причем роль и объем пользовательского интерфейса невелики. 2 Рациональный унифицированный процесс Rational Unified Process2.1 Понятие технологии Rational Unified ProcessRational Unified Process (RUP) – рациональный унифицированный процесс, созданный в 1996 г. корпорацией Rational при участии Гради Буча, Айвара Якобсона и Джима Румбаха [1, с.7]. Продукты, поддерживающие методику RUP: Rose (используется практически на всех этапах разработки), SoDA (автодокументирование), RequisitePro (управление требованиями), ClearQuest (запросы на изменения), ClearCase (версионность), Administrator (управление репозиторием проекта), WorkBrench (настройка корпоративных процессов), Quantify (тестирование скорости кода), Purify (определение утечек памяти), PureCoverage (тест охвата кода), Robot (автоматизированное тестирование), SiteLoad (нагрузочное тестирование), SiteCheck (проверка «мертвых» Web-ссылок). В настоящее время доступен RUP, интегрированный в среду разработки Microsoft .NET (под названием Rational XDE). 2.2 Методология и особенности Rational Unified ProcessМетодология RUP широко использует так называемые прецеденты, или сценарии использования – описание последовательностей действий, которые может осуществлять система, взаимодействуя с внешними действующими факторами. Прецеденты создаются при помощи UML и включают варианты как правильных, так и ошибочных последовательностей (исключений) [3, с.33].Прецеденты служат для документирования требований заказчика к проектируемой информационной системе. Прецедент описывает целостный фрагмент поведения системы в виде последовательности сообщений, которыми система обменивается с действующими лицами. Другие существенные черты методологии RUP: заранее предусматриваются изменения в требованиях и проектных решениях в течение всего процесса разработки, постоянное обеспечение качества на всех этапах разработки ИС, компонентная архитектура используется начиная с ранних стадий проекта. 2.3 Процессы и стадии RUP RUP использует итеративную модель разработки. В конце каждой итерации (продолжительностью в несколько недель) команда разработчиков должна получить функционирующую версию конечного продукта, позволяющую достичь запланированных на данную итерацию целей [3, с.33]. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта. Полный жизненный цикл разработки ИС состоит из четырех фаз, описываемых ниже. Каждая фаза может включать в себя одну или несколько итераций процесса создания системы. Начальная стадия В фазе начальной стадии: формируется единая точка зрения на проект у заказчиков и разработчиков, а также определяются границы проекта;создается экономическое обоснование разработки; определяются основные требования, ограничения и функциональность системы;создается базовая версия модели прецедентов;оцениваются риски. Уточнение В фазе «Уточнение» производится анализ исходных данных для проектирования и выбор архитектуры ИС. Фаза включает в себя: анализ требований заказчика, включая детальное описание для большинства прецедентов; проектирование архитектуры ИС, спецификация функций и пользовательского интерфейса;планирование работ по проекту и всех необходимых ресурсов. Построение В фазе «Построение» происходит итеративная реализация требуемых функций ИС. Это основная фаза проектирования и создания программного кода. Фаза завершается выпуском бета-версии системы. Внедрение В фазе «Внедрение» финальная версия системы внедряется у ее заказчика. Фаза включает проведение испытаний системы, обучение пользователей, а также оценку качества ИС. В том случае, если качество системы не соответствует требованиям заказчика, фаза «Внедрение» выполняется повторно. Выполнение всех требований и достижение целей проекта означает завершение полного цикла разработки [3, с.35]. Приведем список наиболее распространенных программных продуктов, поддерживающих RUP. Rational Rose – CASE-средство визуального моделирования информационных систем, имеющее возможности генерирования элементов кода. Специальная редакция продукта – Rational Rose RealTime – позволяет на выходе получить исполняемый модуль. Rational Requisite Pro – средство управления требованиями, позволяющее создавать, структурировать, устанавливать приоритеты, контролировать изменения требований, возникающие на любом этапе разработки компонентов приложения. Rational ClearQuest – продукт для управления изменениями и отслеживания дефектов в проекте, тесно интегрирующийся со средствами тестирования и управления требованиями и представляющий собой единую среду для связывания всех ошибок и документов между собой. Rational SoDA – продукт для автоматического генерирования проектной документации, позволяющий установить корпоративный стандарт на внутрифирменные документы.3 Технология Extreme Programming3.1 Понятие технологии Extreme ProgrammingТехнология XP (англ. Extreme Programming), как и RAD, базируется на спиральной модели жизненного цикла. Авторами технологии являются К. Бек, У. Каннингем, М. Фаулер. Название технологии связано со стремлением авторов поднять существующие методы разработки ИС (и программного обеспечения в целом) на новый, «экстремальный» уровень [3, с.30]. Для оценки проектов с точки зрения применимости XP применяются два показателя – критичность и масштаб. Критичность определяется последствиями, вызываемыми дефектами ПО, и может иметь один из четырех уровней: C – дефекты вызывают потерю удобства. D – дефекты вызывают потерю возместимых ресурсов. E – дефекты вызывают потерю невозместимых ресурсов. L – дефекты могут создавать угрозу для человеческой жизни. Масштаб определяется количеством разработчиков, участвующих в проекте: от 1 до 6 человек – малый масштаб; от 6 до 20 человек – средний масштаб; свыше 20 человек – большой масштаб. По оценке специалиста по разработке ПО А. Коберна, XP применима в проектах малого и среднего масштаба с низкой критичностью (C или D). 3.2 Особенности технологии Extreme ProgrammingРазработка в XP ведется небольшими трехнедельными итерациями, в течение которых уточняются и реализуются требования к системе. При разработке применяется рефакторинг – методика улучшения кода без изменения его функциональности. Программный код в процессе работы над проектом неоднократно переделывается, в том числе и на поздних стадиях проекта [3, с.30]. Для того чтобы эти переделки не привели к неработоспособности системы, используется методика TDD (Test-Driven Development – разработка через тестирование). Технология XP предполагает написание автоматических тестов – специальных программ, написанных для тестирования других программ. Ручная прогонка тестов здесь невозможна, т. к. количество тестов слишком велико. Тесты пишутся еще до того, как начинается создание системы, поэтому риск получения неработоспособной версии из-за постоянно вносимых изменений существенно снижается – любую новую версию тут же можно протестировать. В процессе создания системы применяются такие характерные для XP методы, как парное программирование, непрерывная интеграция, упрощенное проектирование. Парное программирование предполагает, что программы создается парами программистов, работающих за одним компьютером. Один из них пишет непосредственно текст программы, другой оценивает его работу, благодаря чему становится возможной постоянная проверка программного кода. В течение работы над проектом пары не фиксируются: это делается с той целью, чтобы каждый программист в команде имел хорошее представление обо всей системе. Повышение эффективности при работе парой программистов подтверждено специальными исследованиями. Непрерывная интеграция (сборка) системы позволяет поддерживать ее целостность в течение всего процесса разработки. В традиционных методиках интеграция выполняется в самом конце работы над продуктом, когда все составные части разрабатываемой системы полностью готовы. Интеграционные проблемы обладают способностью накапливаться и наслаиваться друг на друга, что может даже привести к провалу проекта. В XP интеграция системы выполняется несколько раз в день после того, как все модули прошли положенные для них тесты. Это позволяет выявить проблемы интеграции на возможно более ранней стадии разработки и заблаговременно принять необходимые шаги к их преодолению [3, с.31]. Упрощенное проектирование применяется в XP из-за того, что в процессе работы требования к системе могут неоднократно меняться, что снижает ценность проекта, выполненного целиком в самом начале разработки. Для XP характерно непрерывное проектирование, выполняемое в течение всего времени работы над проектом. Проектирование должно выполняться небольшими этапами, с учетом постоянно изменяющихся требований. В каждый момент времени следует использовать наиболее простые решения, которые подходят для решения текущей задачи, и менять его по мере того, как условия задачи меняются. Согласно К. Беку, упрощенное проектирование обеспечивает корректное выполнение всех тестов, не порождает дублирующего кода, включает наименьшее количество классов и методов, ясно выражает цель программиста [3, с.32]. Помимо перечисленного, все члены команды в ходе работы должны соблюдать общие требования стандартов программирования, что существенно облегчает рефакторинг и снижает риски проекта, связанные с текучкой кадров. В идеале соблюдение стандартов программирования должно полностью исключить индивидуальные черты стиля разработки – программный продукт должен выглядеть как результат работы одного человека. Коллективное владение означает, что каждый член команды несет ответственность за весь исходный код. Каждый вправе вносить изменения в любой участок программы. Сопутствующие риски от вносимых изменений устраняются мощной системой тестирования. Однако это не порождает безответственности, поскольку существует требование, согласно которому каждый программист должен сам исправить сделанные им ошибки. Важное преимущество коллективного владения кодом состоит в том, что оно ускоряет процесс разработки, поскольку при необходимости любой программист может оперативно внести изменения в любую часть кода. Существенным считается и наличие метафоры системы – простой аналогии, понятной всем участникам проекта, которая с достаточной точностью описывает функционирование и внутреннюю структуру ИС.

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

Пацей Н. В. Технология разработки программного обеспечения : учеб.- метод. пособие по курсовому проектированию для студентов по направлению специальности «Информационные системы и технологии (издательско-полиграфический комплекс)» / Н. В. Пацей, Д. В. Шиман, И. Г. Сухорукова. – Минск : БГТУ, 2011. – 130 с.Родионова Т. Е. Технологии программирования: учебное пособие для студентов направления 01.03.04 / Т. Е. Родионова. — Ульяновск: УлГТУ, 2018. — 115 с.Солонин Е. Б. Современные методики разработки информационных систем: методические рекомендации к самостоятельным работам по курсу «Методы и средства проектирования информационных систем и технологий» для студентов всех форм обучения / Е. Б. Солонин. – Екатеринбург: УФУ, 2015. – 44 с.