Контрольная работа по "Экономике"

Недост-ки: 1)необходимость полного функционального определения системы или программного средства в начале жизненного цикла для обеспечения определения инкрементов, планирования и управления проектом; 2)возможность текущего изменения требований к системе или программному средству, которые уже реализованы в предыдущих инкрементах; 3)необходимость хорошего планирования и проектирования, грамотного распределения работы; 4)наличие тенденции к оттягиванию решения трудных проблем на поздние инкременты, что может нарушить график работ.

Области прим-я: 1)при разработке проектов, в которых большинство требований можно сформулировать заранее, но часть из них могут быть сформулированы через определенный период времени; 2)при необходимости быстро поставить на рынок продукт, имеющий функциональные базовые свойства; 3) для выполнения проектов с большим периодом разработки (один год и более); 4)при разработке проектов с низкой или средней степенью риска; 5)при выполнении проекта с применением новой технологии.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

12. Вариант инкрементной модели по ГОСТ Р ИСО/МЭК ТО 15271-2002. Достоинства и недостатки. Область применения.

Основан на использовании  полного заранее сформированного  набора требований и их постепенной  реализации в отдельных инкрементах. Учитывает возможность как частично парал разработки инкрементов, так  и их последовательной разработки. Разработка каждого инкремента состоит из трех укрупненных этапов: проектирование, программирование и тестирование, ввод в действие и обеспечение приемки. Инкрементную модель можно комбинировать с другими моделями. Зачастую ее объединяют со спиральной или V-образной моделью, что позволяет снизить затраты и риски при разработке ПС (системы).

 

Дост-ва: 1)возможность получения функционального продукта после реализации каждого инкремента; 2)короткая продолжительность создания инкремента; это приводит к ускорению начального графика поставки и снизить затраты поставки ПП; 3)предотвращение реализации громоздких перечней требований; возможность учета изменившихся требований; 4)снижение риска неудачи и изменения требований по сравнению с каскадной моделью; 5)включение в процесс пользователей, что позволяет оценить самые важные функциональные возможности продукта на более ранних этапах разработки и приводит к повышению качества ПП, снижению затрат и времени на его разработку; 6)стабильн треб-й во врем созд-я опред-го инкремента, возм-ти учета измен-ся треб-й.

Недост-ки: 1)необходимость полного функционального определения системы или программного средства в начале жизненного цикла для обеспечения определения инкрементов, планирования и управления проектом; 2)возможность текущего изменения требований к системе или программному средству, которые уже реализованы в предыдущих инкрементах; 3)необходимость хорошего планирования и проектирования, грамотного распределения работы; 4)наличие тенденции к оттягиванию решения трудных проблем на поздние инкременты, что может нарушить график работ.

Области прим-я: 1)при разработке проектов, в которых большинство требований можно сформулировать заранее, но часть из них могут быть сформулированы через определенный период времени; 2)при необходимости быстро поставить на рынок продукт, имеющий функциональные базовые свойства; 3) для выполнения проектов с большим периодом разработки (один год и более); 4)при разработке проектов с низкой или средней степенью риска; 5)при выполнении проекта с применением новой технологии.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

13. Эволюционная модель жизненного цикла ПС по ГОСТ Р ИСО/МЭК ТО 15271-2002. Достоинства и недостатки. Область применения.

В данном случае разработка каждой версии программного средства (системы) выполняется на основе каскадной модели, содержащей четыре этапа: разработка требований, проектирование, программирование и тестирование, ввод в действие и поддержка приемки. При разработке первой версии формулируются наиболее важные (базовые) требования к продукту. На основе данных требований разрабатывается и вводится в действие первая версия системы (программного средства). При разработке каждой очередной версии требования уточняются, при необходимости вводятся новые или изменяются уже реализованные требования. На основе уточненных требований разрабатывается и вводится в действие очередная версия продукта. Процесс продолжается, пока все требования не будут окончательно уточнены и полностью реализованы.

Дост-ва: 1)возможность уточнения и внесения новых требований в процессе разработки; 2)пригодность для использования промежуточного продукта; 3)возможность обеспечения управления рисками; 4)реализация преимуществ инкрементной стратегии (выпуск версий, повторное использование результатов, сокращение графика работ); 5)обеспечение широкого участия пользователя в проекте, начиная с ранних этапов, что минимизирует возможность разногласий между заказчиками и разработчиками и обеспечивает создание продукта высокого качества; 6) уменьшение общих затрат на разработку за счет раннего решения проблем и меньшего объема доработок.

Недост-ки: 1)сложность определения критериев для продолжения процесса разработки на следующей итерации, неизвестность точного количества необходимых итераций; это затрудняет планирование проекта и может вызвать задержку реализации конечной версии системы или программного средства 2) сложность управления проектом; необходимость грамотного управления с целью ограничения количества итераций до разумного; 3)необходимость активного участия пользователей в проекте, что не всегда возможно в реальной жизни; 4)необходимость мощных инструментальных средств и методов прототипирования; 5)возможность отодвигания решения трудных проблем на последующие циклы, что может привести к несоответствию полученных продуктов требованиям заказчиков.

Области применения: 1) при разработке проектов, для которых требования слишком сложны, неизвестны заранее, непостоянны или их следует уточнить; 2) при разработке больших и долгосроч  проектов; 3) при разраб проектов использ новые технологии.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

14. Структурная эволюционная модель быстрого прототипирования. Достоинства и недостатки. Область применения.

При использовании структурной  эволюционной модели быстрого прототипирования система или программное средство строится в виде последовательности прототипов.

Начало модели –в центре. На основ плана выполн быстр анализ треб-й, во время кот разраб умышл  неполн треб-я. Затем на основ умышл  неполн треб произв укрупн проектир прототипа, программирование и ввод в действие. Потом начин цикл итераций быстрого прототипир-я. Структ его аналог структ 1го цикла. Далее, после того как пользователь оценил прототип и принял его, осуществл детализир разраб сист или ПС. Отличие дан модели от др эволюц моделей: С целью ускорения разраб рез-ты промежут циклов представл-ся в виде прототипов, не доводятся до уровня рабочей версии, и как следствие в эксплуатацию не сдаются. Назначение прототипа – уточнение требований.

Недост-ки:  1) обычная недостаточность или неадекватность документации по ускоренным прототипам; 2) вероятность недостаточного качества результирующего ПС (или системы) за счет его создания из рабочего прототипа (при детальной разработке ПС или системы из последнего прототипа может оказаться сложной или невозможной реализация функций, не реализованных при итерационном прототипировании); 3) возможность задержки реализации конечной версии ПС (системы) при несочетании языка или среды прототипирования с рабочим языком или средой программирования.

 

15.  Эволюционная модель прототипирования по ГОСТ Р ИСО/МЭК ТО 15271-2002. Достоинства и недостатки. Область применения.

Основой эффективного применения данной модели жизненного цикла является максимально возможная детализация  на ранних этапах проекта (анализ требований к системе и проектирование системной архитектуры). Данные этапы выполняются в модели один раз. Однократное выполнение этих этапов достигается за счет тесных связей разработчиков с пользователями проекта. Требования к системе, в первую очередь, функции системы и внешние интерфейсы определяются пользователями в начале ЖЦ, деловые процессы уточняются при проведении пользователем серии оценок прототипов системы.

В данной модели при создании каждой версии ПС используется прототипирование. При разработке каждого прототипа уточняются требования к нему. Затем выполняется программирование прототипа в среде 4GL. При выполнении данного этапа инструментальная среда 4GL используется в первую очередь для быстрого проектирования и сборки ПС, а также оперативного наращивания, изменения и уточнения ПС. Языки 4GL осуществляют частичную автоматическую кодогенерацию ПС.

Проверка и оценка каждого прототипа осуществляется пользователем в реальной эксплуатационной среде.

В модели ЖЦ определен  фиксированный период проведения прототипирования и произвольное количество итераций.

Из описания данной модели видно, что при разработке прототипов фактически используется RAD-модель жизненного цикла.

 

Дост-ва: 1)возможность уточнения и внесения новых требований в процессе разработки; 2)пригодность для использования промежуточного продукта; 3)возможность обеспечения управления рисками; 4)реализация преимуществ инкрементной стратегии (выпуск версий, повторное использование результатов, сокращение графика работ); 5)обеспечение широкого участия пользователя в проекте, начиная с ранних этапов, что минимизирует возможность разногласий между заказчиками и разработчиками и обеспечивает создание продукта высокого качества; 6) уменьшение общих затрат на разработку за счет раннего решения проблем и меньшего объема доработок.

Недост-ки: 1)сложность определения критериев для продолжения процесса разработки на следующей итерации, неизвестность точного количества необходимых итераций; это затрудняет планирование проекта и может вызвать задержку реализации конечной версии системы или программного средства 2) сложность управления проектом; необходимость грамотного управления с целью ограничения количества итераций до разумного; 3)необходимость активного участия пользователей в проекте, что не всегда возможно в реальной жизни; 4)необходимость мощных инструментальных средств и методов прототипирования; 5)возможность отодвигания решения трудных проблем на последующие циклы, что может привести к несоответствию полученных продуктов требованиям заказчиков.

Области применения: 1) при разработке проектов, для которых требования слишком сложны, неизвестны заранее, непостоянны или их следует уточнить; 2) при разработке больших и долгосроч  проектов; 3) при разраб проектов использ новые технологии.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

16. Спиральная модель Боэма жизненного цикла ПС. Достоинства и недостатки. Область применения.

Спиральная модель объединяет в себе преимущества других видов  моделей, в нее включены анализ и  управление рисками, процессы поддержки  и управления, предусмотрены возможности использования прототипирования и быстрой разработки приложений. Каждый цикл разработки (итерация) представляет собой набор операций, соответствующий шагам в каскадной модели. Каждому витку спирали модели Боэма соответ фаза разработки. Кажд фаза мот выполнятся за 1 или несколько циклов.

A. Фаза разработки концепции (соответствует первому витку спирали).

1. –  определение потребности;
2. –  анализ рисков фазы разработки концепции;
3. –  концептуальное прототипирование;
4. – разработка концепции требований к системе или программным средствам;

          5–  планирование проекта и  процесса разработки.

B. Фаза анализа требований (соответствует второму витку спирали).

6. – анализ целей, альтернатив и ограничений, связанных с системой/программным средством;
7. –  анализ рисков фазы анализа требований;
8. –  демонстрационное прототипирование;
9. –  оценка характеристик системы/продукта;

 

10. –   разработка требований к системе/продукту;
11. –   планирование перехода на фазу проектирования системы/продукта.

C. Фаза проектирования системы/продукта (соответствует 3 витку). 

 

12. – анализ целей, альтернатив и ограничений, связанных с текущим циклом проектирования системы/продукта;
13. –   анализ рисков фазы проектирования системы/продукта;
14. –   оценочное прототипирование проектирования системы/продукта;

9 –     см. выше;

15. –   проектирование системной/программной архитектуры;
16. – планирование перехода на фазу технического проектирования ПС, программирования и сборки.