¾ общая информационная модель системы;
¾ функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
¾ точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
¾ построенные прототипы экранов, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:
¾ определяется необходимость распределения данных;
¾ производится анализ использования данных;
¾ производится физическое проектирование базы данных;
¾ определяются требования к аппаратным ресурсам;
¾ определяются способы увеличения производительности;
¾ завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, метод определения которых представлен в 4.2.
Таблица 4.2 – определение размера приложения по методологии RAD
| < 1000 функциональных элементов | один человек |
| 1000-4000 функциональных элементов | одна команда разработчиков |
| > 4000 функциональных элементов | 4000 функциональных элементов на одну команду разработчиков |
В качестве итога перечислим основные принципы методологии RAD:
¾ разработка приложений итерациями;
¾ необязательность полного завершения работ на каждом из этапов жизненного цикла;
¾ обязательное вовлечение пользователей в процесс разработки ИС;
¾ необходимое применение CASE-средств, обеспечивающих целостность проекта;
¾ применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
¾ необходимое использование генераторов кода;
¾ использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
¾ тестирование и развитие проекта, осуществляемые одновременно с разработкой;
¾ ведение разработки немногочисленной хорошо управляемой командой профессионалов;
¾ грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ [39].
Целью программного проекта является разработать и внедрить информационную систему первоначального учета граждан в поселении администрации для отдела воинского учета. Разработанная информационная система будет представлена в виде взаимосвязанных модулей, которые обеспечивают эффективный ввод, обработку и передачу информации с сохранением в серверной базе данных.
К модулям относятся:
¾ Индивидуальная карточка – которая содержит необходимые сведения для постановки гражданина на первоначальный учет;
¾ Отчеты, создаваемые по введенным критериям;
Область действия данной информационной системы не выходит за рамки отдела Воинского учета администрации села. Информационная система не будет применяться в операционных, отличных от Windows.
Процесс создания Информационной системы для отдела Воинского учета представляется в виде перечня работ, реализованном в прикладном пакете MicrosoftOfficeProject 2003 и включающий следующие этапы:
¾ анализ требований;
¾ изучение бизнес-цели проекта;
¾ постановка задач;
¾ создание технического задания;
¾ определение спецификаций проекта;
¾ оценка стоимости проекта;
¾ проектирование;
¾ определение логических объектов;
¾ построение схем взаимодействия объектов;
¾ определение функций системы;
¾ определение вариантов использования;
¾ проектирование уровня данных;
¾ проектирование уровня бизнес-логики;
¾ проектирование пользовательского интерфейса
¾ реализация;
¾ разработка уровня данных;
¾ разработка уровня бизнес-логики;
¾ разработка пользовательского интерфейса;
¾ интеграция системы;
¾ тестирование;
¾ отладка.
Разработка руководства по использованию системы, краткая характеристика и требования системы;
Все работы можно классифицировать по своим характеристикам: длительности, трудозатратам и количеству людских ресурсов. Данные параметры связаны друг с другом: трудозатраты задачи равны произведению длительности на количество людских ресурсов. Задачи в плане проекта могут быть трех типов: с фиксированными длительностью, трудозатратами и количеством ресурсов. Для того чтобы реализовать ту или иную задачу необходимы ресурсы. Рассмотрим подобно все задачи и ресурсы с помощью которых реализуются эти задачи.
Таблица 4.3 – Ресурсы проекта
| Задачи | Ресурсы |
| Анализ требований | Разработчик |
| Создание черновой версии спецификации проекта | Разработчик |
| Создание предварительного бюджета | Разработчик |
| Обсуждение спецификаций программного продукта | Руководитель проекта |
| Разработка графика сдачи | Разработчик |
| Получение разрешений на продолжение | Разработчик |
| Разработка общей информационной модели системы | Разработчик |
| Разработка функциональных моделей системы в целом, а также подсистем | Разработчик |
| Точное определение интерфейсов | Разработчик |
| Построение прототипов экранных форм, диалогов, отчетов | Разработчик |
| Определение параметров модульной и уровневой архитектуры | Разработчик |
| Назначение персонала для разработки | Руководитель проекта |
| Разработка кода | Разработчик |
| Разработка планов тестирования модулей с использованием спецификации продукта | Инженер-испытатель |
| Тестирование модулей | Инженер-испытатель |
| Тестирование интеграции | Инженер-испытатель |
| Тестирование интеграции модулей | Инженер-испытатель |
| Выявление ошибок и недоработок | Инженер-испытатель |
| Изменение кода | Разработчик |
| Повторное тестирование измененного кода | Инженер-испытатель |
Для оценки размера описываемого приложения был применен метод оценки количества строк кода LOC(LinesofCode). Данный метод заключается в подсчете созданных классов, а так же определенных методах в классах приложения. В данной разрабатываемой системе количество созданных классов будет равняться 10, а количество методов приходящихся на каждый класс будет рано в среднем 12. Так же необходимо определить какое количество строк кода(LOC) приходится на один метод. В зависимости от функций выполняемых определенным методом, количество строк кода будет колебаться от 10 – до 30. В общем же количество строк кода разрабатываемой системы равно 1700. Данные цифры являются усредненными, т.к. невозможно подсчитать точную цифру на этапе проектирования или разработки информационной системы.