- •1.Проблемы создания больших программ.
- •2. Основные понятия
- •3. Состав жизненного цикла по
- •1.Анализ требований
- •4.Стандартизация процессов жизненного цикла программ
- •5. Модели жизненного цикла программного обеспечения.
- •6.Техническое задание на разработку.
- •7.Документирование программ.
- •8.Выбор архитектуры по.
- •9.Структурный и объектный подходы к разработке программ.
- •10. Метод структурного анализа и проектирования sadt (idef0)
- •11. Диаграммы потоков данных dfd.
- •12. Диаграмма сущность – связь erm
- •13. Методы объектно-ориентированного анализа и проектирования. Язык uml.
- •14. Методы разработки структуры программной системы
- •15.Выбор языка программирования. Стиль программирования.
- •16.Защитное программирование.
- •17.Тестирование и отладка
- •18.Типичные ошибки
- •19.Отладка программных продуктов
- •20.Ввод в зксплуатацию
- •21.Ускорение разработки по. Технология rad
- •22. Экстремальное программирование
21.Ускорение разработки по. Технология rad
Одна из причин распространенности «хаотического» процесса создания программ — стремление сэкономить на стадии разработки, не затрачивая времени и средств на обучение разработчиков и внедрение технологического процесса создания ПО. Основная причина — «тяжесть» технологических процессов. «Тяжелый» процесс обладает следующими особенностями:
необходимость документировать каждое действие разработчиков;
множество рабочих продуктов (в первую очередь, документов), создаваемых в бюрократической атмосфере;
отсутствие гибкости;
детерминированность (долгосрочное детальное планирование и предсказуемость всех видов деятельности).
Альтернативой «тяжелому» процессу является адаптивный (гибкий) процесс, основанный на принципах быстрой разработки приложений, интенсивно развиваемых в последнее десятилетие.
Разработка спиральной модели жизненного цикла ПО и CASE-технологий позволили сформулировать условия, выполнение которых сокращает сроки создания ПО. Современная технология проектирования, разработки и сопровождения ПО должна отвечать следующим требованиям:
-поддерживать полный ЖЦ ПО;
-обеспечивать гарантированное достижение целей разработки информационной системы с заданным качеством и в установленное время;
-обеспечивать возможность выполнения крупных проектов в виде подсистем. Реализацию подсистем должны выполнять отдельные группы специалистов.
-Обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (от трех до семи человек).
-Обеспечивать минимальное время получения работоспособной системы. Речь идет не о сроках готовности всей системы, а о сроках реализации отдельных подсистем.
-Предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
-Обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);
-должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Этим требованиям отвечает технология RAD (Rapid Application Development — быстрая разработка приложений), ориентированная, как следует из названия, на максимально быстрое получение первых версий разрабатываемого ПО и предусматривающая выполнение следующих условий.
Разработка ведется небольшими группами разработчиков (от трех до семи человек), каждая из которых проектирует и реализует отдельные подсистемы проекта. Это позволяет улучшить управляемость проекта.
При разработке используют итерационный подход, что способствует уменьшению времени получения работоспособного прототипа. При этом создается четко проработанный график цикла, рассчитанный не более чем на три месяца, что существенно увеличивает эффективность работы.
Процесс разработки при этом делится на следующие этапы: анализ и планирование требований пользователей, проектирование, реализация, внедрение.
На этапе анализа и планирования требований формулируют наиболее приоритетные требования, что ограничивает масштаб проекта.
На этапе проектирования, используя имеющиеся CASE-средства, детально описывают процессы системы, устанавливают требования разграничения доступа к данным и определяют состав необходимой документации. По результатам анализа процессов определяют количество так называемых функциональных точек и принимают решение о количестве подсистем и, соответственно, команд, участвующих в разработке.
Под функциональной точкой в технологии RAD понимают любой из следующих функциональных элементов разрабатываемой системы:
-входной элемент приложения (входной документ, или экранная форма);
-выходной элемент приложения (отчет, документ, или экранная форма);
-запрос (пара «вопрос—ответ»);
-логический файл (совокупность записей данных, используемых внутри приложения);
-интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).
Нормы, рассчитанные исходя из экспертных оценок, для систем со значительной повторяемостью кодов определяются следующим образом:
менее 1 тыс. функциональных точек — 1 чел. ;от 1 до 4 тыс. — одна команда разработчиков; более 4 тыс. — одна команда на каждые 4 тыс. точек.
В соответствии с этими нормами разрабатываемую систему делят на подсистемы, слабо связанные поданным и функциям, и точно определяют интерфейсы между различными частями. Использование CASE-средств при этом позволяет избежать неконтролируемого искажения данных при передаче информации о проекте со стадии на стадию.
Далее разработку ведут группы разработчиков, продолжающих прорабатывать свои части системы. Действия их при этом должны быть хорошо скоординированы.
На этапе реализации выполняют итеративное построение реальной системы, причем при этом для контроля над выполнением требований к создаваемой системе привлекаются будущие пользователи.
Части постепенно интегрируют в систему, причем при подключении каждой части выполняют тестирование. На завершающих этапах разработки определяют необходимость создания соответствующих баз данных, которые разрабатывают и подключают к системе. Далее формулируют требования к аппаратным средствам, устанавливают способы увеличения производительности и завершают подготовку документации по проекту.
На этапе внедрения проводят обучение пользователей и осуществляют постепенный переход на новую систему, причем эксплуатация старой версии продолжается до полного внедрения новой системы.
Технология RAD хорошо зарекомендовала себя для относительно небольших проектов, разрабатываемых для конкретного заказчика. Такие системы не требуют высокого уровня планирования и жесткой дисциплины проектирования. Однако эта технология не применима для построения сложных расчетных программ, операционных систем или программ управления сложными объектами в реальном масштабе времени, т. е. программ с большим процентом уникального кода. Не годится она и в случае создания приложений, от которых зависит безопасность людей, например систем управления самолетами или атомными электростанциями, так как технология RAD предполагает, что первые несколько версий не будут полностью работоспособны, что в данном случае полностью исключается.