
- •А. М. Минитаева разработка и стандартизация программных средств и информационных технологий
- •Isbn 978-5-8149-1063-9 введение
- •1.2. Какова структура нормативной базы предприятия и как ее выбрать?
- •1.3. Цели, задачи и состав нормативно-методического обеспечения
- •Все ли надо стандартизировать?
- •1.4. Нужно ли пользоваться международными стандартами или разрабатывать свои, российские?
- •Состав и статус дополнительных стандартов.
- •P.S. Кто должен разрабатывать стандарты?
- •1.5. Почему возрастает роль технологии при разработке программного обеспечения?
- •1.6. Стандартизация в области технологии разработки по
- •2. Общие положения о стандартах
- •2.1. Нормативные документы по стандартизации и виды стандартов
- •2.2. Стандарты в области программного обеспечения
- •2.3. Международные организации, разрабатывающие стандарты
- •2.4. Национальные организации, разрабатывающие стандарты
- •2.5. Внутрифирменные (внутрикорпоративные) стандарты
- •2.6. Организация разработки внутрифирменных стандартов
- •2.7. Хранение аналитической информации
- •3. Стандартизация разработки программных средств
- •3.1. Характеристики процессов жц пс согласно гост р исо/мэк 12207
- •3.2. Основные процессы жизненного цикла программного продукта
- •3.3. Вспомогательные (поддерживающие) процессы жизненного цикла программного продукта
- •3.4. Организационные процессы жизненного цикла программного продукта
- •3.5. Взаимосвязь между процессами жизненного цикла программного продукта
- •3.6. Технология разработки программного обеспечения
- •4. Жизненный цикл программного продукта
- •4.1. Общие принципы стандартизации жизненного цикла программных средств
- •4.2. Понятие жизненного цикла программного продукта
- •5. Модели жизненного цикла разработки программного продукта
- •5.1. Общие принципы моделирования жизненного цикла программных средств
- •5.2. Понятие модели жизненного цикла разработки программного продукта
- •5.3. Классическая каскадная, или «водопадная» модель
- •5.4. Модифицированная каскадная, или модель «водоворота»
- •5.5. Модель «сделал-исправил»
- •5.6. Прототипирование
- •5.7. Спиральная модель жц пс
- •5.8. Другие модели жц пс
- •5.9. Модель быстрой разработки приложений (rad-модель)
- •5.10. Многопроходная модель
- •6. Проектирование программного продукта
- •6.1. Общая характеристика и компоненты проектирования
- •6.2. Эволюция разработки программного продукта
- •6.3. Структурное программирование
- •6.4. Объектно-ориентированное проектирование
- •7. Основные этапы работы по созданию программного продукта
- •7.1. Длительность основных этапов
- •7.2. Характеристика основных этапов
- •Библиографический список
5.9. Модель быстрой разработки приложений (rad-модель)
В RAD-модели (рис. 5.7) конечный пользователь играет решающую роль. В тесном взаимодействии с разработчиками он участвует в формировании требований и апробации их на работающих прототипах. Таким образом, в начале жизненного цикла на конечного пользователя выпадает большая часть работы, но в результате этого создаваемая система формируется более быстро.
В традиционном жизненном цикле разработки большую часть работы составляют программирование и тестирование. При автоматизации программирования и повторном использовании кода, применяемых в RAD-модели, большую часть работы составляют планирование и проектирование.
На рисунке 5.7, поясняющем принцип RAD-модели, указаны этапы процесса разработки и отображено участие заказчиков (штриховая линия) на каждом из них.
Рис. 5.7. RAD-модель
Модель включает в себя следующие фазы: составление требований и планирование – осуществляются с использованием так называемого метода совместного планирования требований (планирование работ по созданию ПП и составление требований к ПП выполняются одновременно), который заключается в структурном анализе и обсуждении решаемых задач; описание пользователя – проектирование ПП, выполняемое при непосредственном участии заказчика; создание – детальное проектирование, кодирование и тестирование ПП, а также поставка его заказчику; сопровождение – приемочные испытания, установка ПП и обучение пользователей.
Модель обладает следующими достоинствами: использование современных инструментальных средств позволяет сократить время цикла разработки; привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым ПП; повторно используются компоненты уже существующих программ.
В то же время ей присущи и недостатки: если заказчики не могут постоянно участвовать в процессе разработки, то это может негативно сказаться на ПП; для работы нужны высококвалифицированные кадры, умеющие пользоватъся современными инструментальными средствами; существует риск, что работа над ПП никогда не будет завершена, так как может быть зациклена, поэтому всегда надо вовремя остановиться.
Рассмотренную RAD-модель можно применять при разработке ПП, которые хорошо поддаются моделированию, когда требования к ПП хорошо известны, а заказчик может принять непосредственное участие в процессе разработки.
5.10. Многопроходная модель
Многопроходная модель (рис. 5.8) – это несколько итераций процесса построения прототипа ПП с добавлением на каждой следующей итерации новых функциональных возможностей или повышением эффективности ПП.
Рис. 5.8. Многопроходная модель
Предполагается, что на ранних этапах жизненного цикла разработки (планирование, анализ требований и разработка проекта) выполняется конструирование ПП в целом. Тогда же определяется и число необходимых инкрементов и относящихся к ним
функций. Каждый инкремент затем проходит через оставшиеся фазы жизненного цикла (кодирование и тестирование). Сначала выполняются конструирование, тестирование и реализация базовых функций, составляющих основу ПП. Последующие итерации направлены на улучшение функциональных возможностей ПП [1, 2].
Преимущества многопроходной модели: в начале разработки требуются средства только для разработки и реализации основных функций ПП; после каждого инкремента получается функциональный продукт; снижается риск неудачи и изменения требований; улучшается понимание как разработчиками, так и пользователями ПП требований для более поздних итераций; инкременты функциональных возможностей легко поддаются тестированию.
Недостатки многопроходной модели: не предусмотрены итерации внутри каждого инкремента; определение полной функциональности должно быть осуществлено в самом начале жизненного цикла разработки; может возникнуть тенденция оттягивания решения трудных задач; общие затраты на создание ПП не будут снижены по сравнению с другими моделями; обязательным условием является наличие хорошего планиропания и проектирования.
Многопроходная модель может быть применена, если большинство требований к ПП будут сформулированы заранее, а для выполнения проекта будет выделен большой период времени.