В результате предъявления первого прототипа заказчику были получены протокол рассмотрения итогов создания прототипа, список замечаний по составу ролевых функций, список замечаний по составу реализованных в базе данных системы сущностей предметной области, соглашение по внешнему виду системы с приложением к протоколу в виде бумажных копий экранов с замечаниями на них.
При реализации второго прототипа были зафиксированы перечень и состав ролевых функций системы и способы их реализации, структура базы данных системы, проверены выполнения требований к первому прототипу и сбор замечаний по функциональности экранов и логикам формирования отчетов.
Результатами второго прототипа явились протокол рассмотрения итогов создания 2-го прототипа, список замечаний по функциональности экранов и логикам формирования отчетов, приложение к протоколу в виде бумажных копий экранов с замечаниями на них.
Результаты третьего прототипа были аналогичны.
Перед вводом системы в опытную эксплуатацию были созданы рабочая база данных системы, рабочие места пользователей, системы автоматизированного версионного управления версиями ПО и автоматизированного сбора замечаний, проведено обучение пользователей.
Таблица 1. Таблица характеристик проекта
| Объекты проекта | Общее количество |
| Файлы экранов | 217 |
| Файлы отчетов | 74 |
| Файлы меню | 33 |
| Файлы моделей архитектуры | 41 |
| Файлы моделей данных | 18 |
Характеристики проекта при традиционном подходе: Сложность проекта ~ 1850 ф.т. Типичная норма выработки - 18 ф.т. на человеко-месяц Проект потребует - 103 человеко-месяца 5 человек - более 20 месяцев при спиральной модели жизненного цикла: Сложность проекта ~ 1850 ф.т. Проект потребовал - 38 человеко-месяцев Норма выработки - 48,5 ф.т. на человеко-месяц. (см. Приложение рис. 2)
Высокая производительность проекта достигалась за счет использования средств автоматизации анализа и проектирования (CASE SilverRun), языка четвертого поколения (JAM), за счет автоматизации всей технологической цепочки (мост SR-(JAM), использования средств конфигурационного управления (PVCS), средства автоматизации тестирования QualityWorks.
2.3. Применение подхода RAD в других областях
Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается.
Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки информационных систем с максимальным повторным использованием программных компонентов, определяется следующим образом:
Таблица 2. Определение размера приложения по методологии RAD
| < 1000 функциональных элементов | один человек |
| 1000-4000 функциональных элементов | одна команда разработчиков |
| > 4000 функциональных элементов | 4000 функциональных элементов на одну команду разработчиков |
Заключение
Недостатки традиционного (каскадного) подхода к построению жизненного цикла программного обеспечения хорошо известны. Жестко зафиксированные требования к разрабатываемой системе в самом начале жизненного цикла, отсутствие в процессе реализации участия конечного пользователя приводят к тому, что проект растягивается на годы, выходит за рамки установленного бюджета, полученная в результате система не удовлетворяет требованиям пользователей.
Развитие информационных технологий, появление средств автоматизации практически всех этапов жизненного цикла привели к возникновению разнообразных моделей жизненных циклов современных информационных систем. Современные методологии разработки программных продуктов позволяют создавать в сжатые сроки системы высокого качества, удовлетворяющие требованиям пользователей. Многие из современных методологий поддерживаются современными инструментальными средствами.
Наиболее широкое распространение получила методология быстрой разработки приложений RAD (rapid application development), которая охватывает все этапы жизненного цикла современных информационных систем.
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД и т.д., на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
В качестве итога перечислим основные принципы методологии RAD:
· разработка приложений итерациями;
· необязательность полного завершения работ на каждом из этапов жизненного цикла;
· обязательное вовлечение пользователей в процесс разработки информационных систем;
· необходимое применение CASE-средств, обеспечивающих целостность проекта;
· применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
· необходимое использование генераторов кода;
· использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
· тестирование и развитие проекта, осуществляемые одновременно с разработкой;
· ведение разработки немногочисленной хорошо управляемой командой профессионалов;
· грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Список литературы
1. Автоматизированные информационные технологии в экономике/Под ред. И.Т. Трубилина. – М.: Финансы и статистика, 2000.
2. Автоматизированные информационные технологии в экономике: Учебник/Под ред. Г.А. Титоренко. – М.: Компьютер: ЮНИТИ, 1998.
3. Благодатских В.А. Экономика, разработка и использование программного обеспечения ЭВМ. – М: Финансы и статистика, 1995.
4. Благодатских В.А., Волнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств. – М: Финансы и статистика, 2003.
5. Вендров А.М. Пректирование программного обеспечения экономических информационных систем – М: Финансы и статистика, 2002.
6. Вендрова А.М. Практикуме по проектированию программного обеспечения экономических информационных систем – М: Финансы и статистика, 2002.
7. Информатика. Базовый курс // Под ред. С.В. Симоновича, СПб., 2000.
8. Компьютерные технологии обработки информации./Под. ред. С.В. Назарова. – М.: Финансы и статистика, 1995.
9. Котов С.Л. Нормирование жизненного цикла программной продукции. – М.: ЮНИТИ-ДАНА, 2002.
10. Липаев В.В. Надежность программных средств – М: СИНТЕГ, 1998.
11. Орлов С.А. Технологии разработки программного обеспечения: Разработка сложных программных систем: Учебное пособие для студентов вузов, обуч. по напр. Подготовки акалавров и магистров «Информатика и выч.техника». – СПб.: Питер, 2002.
12. Черемных С.В., Семенов И.О., Ручкин В.С. Моделирование и анализ систем: IDEF-технологии: практикум – М: Финансы и статистика, 2002.
13. Черемных С.В., Семенов И.О., Ручкин В.С. Структурный анализ систем: IDEF-технологии – М: Финансы и статистика, 2001.