Методология rad

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

Высокая скорость

Высокое качество

Низкая стоимость

RAD – жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества программного обеспечения, чем это возможно при традиционным подходе к проектированию.

Основные принципы RAD можно сформулировать следующим образом:

1. Работа ведется группами. Состав группы – это руководитель, аналитик, два программиста и технический писатель. Если проект сложный, то для него может быть выделено несколько RAD групп. Разработка проекта выполняется в условиях тесного взаимодействия между разработчиками и заказчиком.

2. Разработка базируется на моделях. Моделирование позволяет оценить проект и выполнить его декомпозицию на составные части, каждая из которых может разрабатываться отдельной RAD группой.

3. Итерационное прототипирование. Разработка системы и предъявление ее заказчику осуществляется в виде последовательности развиваемых прототипов. Любой из прототипов реализует определенную часть функциональности, требуемой от конечного продукта, при этом каждый последующий прототип включает всю функциональность, реализованную в предыдущем прототипе с добавлением новой. Число прототипов определяется на основе учета различных параметров – размер проекта, анализы рисков, пожелания заказчика и т.д. Для проектов средней сложности традиционно разрабатывается три прототипа. Первый содержит весь пользовательский интерфейс с нулевой функциональностью. Он дает возможность собрать замечания заказчика и после их устранения утвердить у него экранные и отчетные формы. Второй прототип содержит реализованную на 70-80% функциональность системы. Третий прототип содержит полностью реализованную функциональность. Основаниями для очередной интеррации являются – 1) если изменяются требования, то выполняется переоценка проекта и корректируются сроки и стоимость проекта. 2) детализация. Выполняется в программировании нереализованной части системы в соответствии с планом. 3) анализ результатов программирования. Исправляются ошибки, повышается эффективность программного кода.

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

5. Если проект сложный, то для него может быть выделено несколько RAD групп. Большие системы разбиваются на подсистемы и каждая подсистема разрабатывается независимой группой. В данном случае важно правильное разбиение системы на подсистемы. Все команды должны использовать общие стандарты. Обязательно финальное тестирование полной системы.

6. Обязательное использование инструментальных средств, автоматизирующих процесс разработки и методик их использования. Следствием чего является сокращение сроков разработки и повышение качества конечного продукта.

Принципы применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и проектирование. Жизненный цикл программного обеспечения по методологии RAD состоит из 4 фаз:

1. Фаза анализа и планирования требований

2. Фаза проектирования

3. Фаза построения

4. Фаза внедрения

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

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

Результатом данной фазы должны быть:

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

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

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

4. Построенные прототипы экранов, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE средств, которые будут использоваться в дальнейшем при построении системы.

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

Завершается физическое проектирование системы:

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

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

• Производится физическое проектирования бд

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

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

• Завершается разработка документации проекта

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

Данная методология RAD не может претендовать на универсальность. Она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика.

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

Лр 19. Разработка интерфейса пользователя в соответствии с требованиями технического задания и технического проекта

Лр 20. Проектирование схемы БД с использованием средств

Лр 21. Кодирование модулей и программной системы с целью создания прототипа

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

Организовать работу с документами на поступление и выбытие материальных ценностей.

Понятие экстремального программирования

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

Основные ценности экстремального программирования:

1. Общение. Необходимо максимально увеличить общение между членами команды разработчиков, а так же между программистами и заказчиками. Нельзя так же забывать об “общении” между артефактами и людьми.

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

3. Обратная связь. Лучший инструмент обратной связи – это непосредственно общение с заказчиком и набор автоматизированных тестов.

4. Смелость, кураж. Общение, простота и обратная связь дают возможность приступать к серьезному пересмотру системы или к большим изменениям в требованиях. Таким образом - это мощный инструмент для осуществления больших изменений в системе.

5. Уважение. Вы должны проявлять уважение к коллегам по работе и в кругу вашей компании, а так же к конечным пользователям программного продукта, в разработке которого вы принимаете участие.

Принципы экстремального программирования:

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

2. Экономика. Программное обеспечение должно обладать некой ценностью. В экстремальном программирование есть два ключевых экономических момента – ценность программного продукта на текущий момент и ценность дополнительных возможностей.

3. Взаимная выгода. Всякая деятельность должна приносить выгоду задействованным людям и организациям.

4. Сходство. Можно использовать одни и те же идеи для решения проблем возникающих в разных контекстах.

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

6. Разнообразие. В команде должны быть представители из разных областей знаний, с разными характерами. Это позволит лучше находить и решать проблемы. Данные команды умеют находить неожиданные решения в сложных ситуациях.

7. Обдумывание. Во время интерраций отведите некоторые время на обсуждение того как движется проект и какие улучшения можно было бы внести в процессе разработки.

8. Течение. Все виды деятельности о разработке программного обеспечения должны протекать непрерывно подобно потоку.

9. Новые возможности. В проблемах нужно видеть прежде всего возможность что-то улучшить.

10. Избыточность. Действительно сложные или критические для проекта проблемы надо решать несколькими способами одновременно.

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

12. Качество. Выпускать продукт низкого качества, чтобы сэкономить средства или время – это не правильное решение. Гораздо эффективнее попробовать какой-то вариант, выяснить в чем его недостатки и быстро их исправить.

13. Маленькими шажками. Гораздо надежнее продвигаться вперед маленькими шажками, постоянно получая отзывы и корректировать продвижение работ.

14. Ответственность. Ответственность можно взять на себя только в добровольном порядке. Человек сам должен принять решение, берет ли он на себя ответственность или пусть этой проблемой занимается кто-то другой.