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

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

 

7. V-образная модель жизненного цикла ПС. Достоинства и недостатки. Варианты реализации. Область применения.

Назнач-е – обеспеч  планиров-я, тестир-я сист и ПС на ранних стадиях проекта. Отличие  от каскад модели: здесь выделены связи  м/у шагами  предшеств-ми программиров и соответсв видами тест-я и испытаний. 

1,2,3 этапы соответствуют этапам процесса разраб ПС. 4 этап - 5 и 6 работы . 5 э – 7 раб, 6 э – 8,9 раб, 7 э – 10, 11 раб, 8 э – 12,13 раб, 9 э – основ этап :WGC/

Расписваем все этапы. На этапе 2 выполн разраб плана ввода в действие и обеспеч приемки. На 3 этапе помимо основ д-й разраб план квалиф испыт сист. На 4 этапе разраб план сборки ПС и план квалиф испыт ПС. 5 и 6 понятно. На 7 – подтвержд рез-ты этапа проектир сист. На 8 выполн приемочн испытания, их цели – проверка пользователем соответ-я системы исходным требованиям к системе.

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

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

Недост-ки: 1) поздние сроки тестирования требований; 2) отсутствие действий, напр на анализ рисков.

Вариант реализации с обрат связями, те возм-ю вернутся на предыд шаг. Все остальное как  в каскад модели.

 

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) неприменимость в условиях высоких технических рисков, при использовании новых технологий.

Области примен-я:

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

9. RAD-модель жизненного цикла ПС, основанная на моделировании. Достоинства и недостатки. Область применения.

Функц модел-е  – опред-е и анализ функц  и инфор потоков предм обл, напр IDEF0. Модел-е данных – на базе инф потоков выделяемых на пред этапе  разраб инф модель предм обл. модел-е повед-я – динамич моделир предм обл(IDEF3). На этапе автоматической кодогенерации 3x вышестоящ моделей выполняется генерация текстов программных компонентов. На этапе сборки и квалификационных испытаний выполняется сборка и испытания резул-й системы, подсистемы или ПС.

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

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

Области примен-я:

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

10. 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) неприменимость в условиях высоких технических рисков, при использовании новых технологий.

Области примен-я:

8. при разработке систем и продуктов, которые удовлетворяют хотя бы одному из следующих свойств: поддаются моделированию; требования для них хорошо известны; предназначены для концептуальной проверки; являются некритическими; имеют небольшой размер; имеют низкую производительность; относятся к известной разработчикам предметной области; являются информационными системами; для них имеются пригодные к повторному использованию компоненты.
9. если пользователь может принимать постоянное участие в процессе разработки;
10. если в проекте заняты разработчики, обладающие достаточными навыками в использовании инструментальных средств разработки;
11. при выполнении проектов в сокращенные сроки (как правило, не более чем за 60 дней);
12. при разработке систем, для которых требуется быстрое наращивание функциональных возможностей на последовательной основе;
13. при разработке проектов, для которых затраты и соблюдение графика не являются очень важными;
14. при невысокой степени технических рисков.

 

 

 

 

 

 

 

 

 

 

 

 

 

11. Инкрементная модель ЖЦПС. Дост-ва и недостатки. Область применения.

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

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

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