- •Базовые стратегии разработки пс и систем. Каскадная стратегия. Сущность. Достоинства и недостатки. Области использования.
- •Инкрементная стратегия разработки программных средств и систем. Сущность. Достоинства и недостатки. Области использования.
- •Эволюционная стратегия разработки программных средств и систем. Сущность. Достоинства и недостатки. Области использования.
- •Классическая каскадная модель жизненного цикла пс и варианты ее реализации. Достоинства и недостатки. Область применения.
- •Каскадная модель по гост р исо/мэк то 15271-2002. Достоинства и недостатки. Область применения.
- •8. Базовая rad-модель быстрой разработки приложений жизненного цикла пс. Достоинства и недостатки. Область применения.
- •Инкрементная модель жцпс. Дост-ва и недостатки. Область применения.
- •Вариант инкрементной модели по гост р исо/мэк то 15271-2002. Достоинства и недостатки. Область применения.
- •Структурная эволюционная модель быстрого прототипирования. Достоинства и недостатки. Область применения.
- •13. Эволюционная модель жизненного цикла пс по гост р исо/мэк то 15271-2002. Достоинства и недостатки. Область применения.
- •Эволюционная модель прототипирования по гост р исо/мэк то 15271-2002. Достоинства и недостатки. Область применения.
- •17. Упрощенная спиральная модель жц пс института качества sqi. Достоинства и недостатки. Область применения.
- •18. Упрощенная спиральная модель жц пс Института Управления проектами. Достоинства и недостатки. Область применения.
- •Модель «win-win» жизненного цикла пс. Достоинства и недостатки. Область применения.
- •20. Спиральная модель жизненного цикла пс Консорциума по вопросам разработки программного обеспечения. Достоинства и недостатки. Область применения.
- •21. Компонентно-ориентированная модель жизненного цикла пс. Достоинства и недостатки. Область применения.
- •22. Классификация проектов по разработке пс и систем, ориентированная на выбор модели жц. Категории и критерии классификации проектов.
- •23. Процедура выбора модели жц разработки пс и систем института sqi
- •25. Модульное проектирование программ. Признаки модульности программы. Достоинства и недостатки модульности. Классификация методов проектирования модульных программ.
- •26. Нисходящее проектирование программ и его стратегии. Стратегия, основанная на использовании псевдокода. Достоинства и недостатки. Пример.
- •27. Стратегия пошаг проект-я при нисходящем проектировании программ, основанная на использовании комментариев. Виды и нормы комментариев. Пример.
- •28. Стратегия анализа сообщений при нисходящем проектировании программ. Пример.
- •29. Метод восходящего проектир. Сущность. Целесообразность использования. Недостатки. Способы сочетания с другими методами.
- •30. Метод Джексона. Сущность. Основ констр постр структур дан. Примен к иерархич, сетев и реляц структурам данных. Примеры.
- •31. Первый этап метода Джексона. Виды документов, создаваемых на данном этапе. Пример.
- •33. Третий этап метода Джексона. Цель. Сущность. Подэтапы. Пример.
- •34. Четвертый этап метода Джексона. Цель. Сущность. Контрольный перечень операций. Пример.
- •35. Пятый этап метода Джексона. Цель. Сущность. Пример.
8. Базовая rad-модель быстрой разработки приложений жизненного цикла пс. Достоинства и недостатки. Область применения.
Модель быстрой разработки приложений - Rapid Application Development. Данная модель может поддерживать как инкрементную, так и эволюционную стратегию разработки системы или программного средства. Как правило, данная модель используется в составе другой модели для ускорения цикла разработки прототипа (версии) системы или ПС. Основа RAD модели – использов мощн инструм ср-в разраб – CASE или языки 4 поколения. Характерной чертой RAD-модели является короткое время перехода от анализа требований до создания полной системы или программного средства. Рис – баз модель для реализ отдел итерац эволюц модели.
На этапе анализа треб выполн 2я работа Проц разраб. Проектир-е - проек-е сист арх-ры, анализ треб к ПС, проек-е прогр арх-ры и техн проек-е ПС(работы 3-6). Программ и испыт-я – 7-11 работы. Ввод в д-е – 12-13 работы.
Дост-ва: 1) сокращение продолжительности цикла разработки и всего проекта в целом, сокращение количества разработчиков, а следовательно, и стоимости проекта за счет использования мощных инструментальных средств; 2) сокращение риска, связанного с соблюдением графика, за счет использования принципа временного блока и связанное с этим упрощение планирования; 3) сокращение риска, связанного с неудовлетворенностью заказчика разработанным продуктом, за счет его привлечения на постоянной основе к циклу разработки; возрастание уверенности, что система будет соответствовать требованиям; 4) возможность повторного использования существующих компонентов.
Недост-ки: 1) необходимость в постоянном участии пользователя в процессе разработки, что часто невыполнимо и в итоге сказывается на качестве конечного продукта; 2) необходимость в высококвалифицированных разработчиках, умеющих работать с инструментальными средствами разработки; 3) возможность применения только для систем или программных средств, для которых отсутствует требование высокой производительности; 4) жесткость временных ограничений на разработку прототипа; 5) сложность ограничения затрат и определения сроков завершения работы над проектом; 6) неприменимость в условиях высоких технических рисков, при использовании новых технологий.
Области примен-я:
при разработке систем и продуктов, которые удовлетворяют хотя бы одному из следующих свойств: поддаются моделированию; требования для них хорошо известны; предназначены для концептуальной проверки; являются некритическими; имеют небольшой размер; имеют низкую производительность; относятся к известной разработчикам предметной области; являются информационными системами; для них имеются пригодные к повторному использованию компоненты.
если пользователь может принимать постоянное участие в процессе разработки;
если в проекте заняты разработчики, обладающие достаточными навыками в использовании инструментальных средств разработки;
при выполнении проектов в сокращенные сроки (как правило, не более чем за 60 дней);
при разработке систем, для которых требуется быстрое наращивание функциональных возможностей на последовательной основе;
при разработке проектов, для которых затраты и соблюдение графика не являются очень важными;
при невысокой степени технических рисков.
RAD-модель жизненного цикла ПС, основанная на моделировании. Достоинства и недостатки. Область применения.
Функц модел-е – опред-е и анализ функц и инфор потоков предм обл, напр IDEF0. Модел-е данных – на базе инф потоков выделяемых на пред этапе разраб инф модель предм обл. модел-е повед-я – динамич моделир предм обл(IDEF3). На этапе автоматической кодогенерации 3x вышестоящ моделей выполняется генерация текстов программных компонентов. На этапе сборки и квалификационных испытаний выполняется сборка и испытания резул-й системы, подсистемы или ПС.
Дост-ва: 1) сокращение продолжительности цикла разработки и всего проекта в целом, сокращение количества разработчиков, а следовательно, и стоимости проекта за счет использования мощных инструментальных средств; 2) сокращение риска, связанного с соблюдением графика, за счет использования принципа временного блока и связанное с этим упрощение планирования; 3) сокращение риска, связанного с неудовлетворенностью заказчика разработанным продуктом, за счет его привлечения на постоянной основе к циклу разработки; возрастание уверенности, что система будет соответствовать требованиям; 4) возможность повторного использования существующих компонентов.
Недост-ки: 1) необходимость в постоянном участии пользователя в процессе разработки, что часто невыполнимо и в итоге сказывается на качестве конечного продукта; 2) необходимость в высококвалифицированных разработчиках, умеющих работать с инструментальными средствами разработки; 3) возможность применения только для систем или программных средств, для которых отсутствует требование высокой производительности; 4) жесткость временных ограничений на разработку прототипа; 5) сложность ограничения затрат и определения сроков завершения работы над проектом; 6) неприменимость в условиях высоких технических рисков, при использовании новых технологий.
Области примен-я:
при разработке систем и продуктов, которые удовлетворяют хотя бы одному из следующих свойств: поддаются моделированию; требования для них хорошо известны; предназначены для концептуальной проверки; являются некритическими; имеют небольшой размер; имеют низкую производительность; относятся к известной разработчикам предметной области; являются информационными системами; для них имеются пригодные к повторному использованию компоненты.
если пользователь может принимать постоянное участие в процессе разработки;
если в проекте заняты разработчики, обладающие достаточными навыками в использовании инструментальных средств разработки;
при выполнении проектов в сокращенные сроки (как правило, не более чем за 60 дней);
при разработке систем, для которых требуется быстрое наращивание функциональных возможностей на последовательной основе;
при разработке проектов, для которых затраты и соблюдение графика не являются очень важными;
при невысокой степени технических рисков.
RAD-модель быстрой разраб прил по ГОСТ Р ИСО/МЭК ТО 15271-2002.
1 – функцион моделир; 2 – модел данных; 3 – модел обраб(повед); 4 – автоматич кодогенер; 5 – сборка сист.
Осуществимость – (1 работа), анализ делов деят(1), соответ графику(1), опред функ прототипа(3-8), созд ф-и прототипа(3-8), анализ ф-и прототипа(9), соотв графику(1), опис прототипа проекта(3), созд протот проекта(3-8), анализ прототипа проекта(9), приемка пользователем(12,13,5), обучение польз(12), ввод в д-е(проц эксплуат), анализ практ(11).
На этапе осуществимости выполняется анализ проекта на основе критических факторов успешности реализации RAD-модели. На этапе анализа дел деят опред обл применения проекта и разраб план прототипа. В цикле функциональной модели с помощью инструментальных средств быстрой разработки (CASE-средств) разрабатывается функциональный прототип, формулируются нефункциональные требования и стратегия реализации прототипа. В цикле проектирования и создания на основе функционального прототипа создается ПС (или система), прошедшее квалификационные испытания и удовлетворяющее всем функциональным и нефункциональным требованиям. На этапе реализации выполняется внедрение ПС (или системы) в среде пользователя, его документирование и обучение соответствующего персонала.
Дост-ва: 1) сокращение продолжительности цикла разработки и всего проекта в целом, сокращение количества разработчиков, а следовательно, и стоимости проекта за счет использования мощных инструментальных средств; 2) сокращение риска, связанного с соблюдением графика, за счет использования принципа временного блока и связанное с этим упрощение планирования; 3) сокращение риска, связанного с неудовлетворенностью заказчика разработанным продуктом, за счет его привлечения на постоянной основе к циклу разработки; возрастание уверенности, что система будет соответствовать требованиям; 4) возможность повторного использования существующих компонентов.
Недост-ки: 1) необходимость в постоянном участии пользователя в процессе разработки, что часто невыполнимо и в итоге сказывается на качестве конечного продукта; 2) необходимость в высококвалифицированных разработчиках, умеющих работать с инструментальными средствами разработки; 3) возможность применения только для систем или программных средств, для которых отсутствует требование высокой производительности; 4) жесткость временных ограничений на разработку прототипа; 5) сложность ограничения затрат и определения сроков завершения работы над проектом; 6) неприменимость в условиях высоких технических рисков, при использовании новых технологий.
Области примен-я:
при разработке систем и продуктов, которые удовлетворяют хотя бы одному из следующих свойств: поддаются моделированию; требования для них хорошо известны; предназначены для концептуальной проверки; являются некритическими; имеют небольшой размер; имеют низкую производительность; относятся к известной разработчикам предметной области; являются информационными системами; для них имеются пригодные к повторному использованию компоненты.
если пользователь может принимать постоянное участие в процессе разработки;
если в проекте заняты разработчики, обладающие достаточными навыками в использовании инструментальных средств разработки;
при выполнении проектов в сокращенные сроки (как правило, не более чем за 60 дней);
при разработке систем, для которых требуется быстрое наращивание функциональных возможностей на последовательной основе;
при разработке проектов, для которых затраты и соблюдение графика не являются очень важными;
при невысокой степени технических рисков.
