Жизненный цикл разработки по

1. Понятие ЖЦ разработки ПО. Основные понятия, связанные с ЖЦ разработки ПО.

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

Понятия

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

• модель ЖЦ - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ включает в себя стадии, результаты выполнения работ на каждой стадии и ключевые события - точки завершения работ и принятия решений.

2. Двойственность понятия разработки\проектирования ПО.

Существует два основных аспекта разработки\проектирования ПО: статический и динамический. UML предлагает использовать для описания архитектуры 8 видов диаграмм. Диаграммы UML делятся на две группы — статические и динамические диаграммы.

Статические диаграммы представляют постоянно присутствующие в системе сущности и связи между ними. К этому типу относятся диаграммы классов, объектов, компонентов и диаграммы развертывания.

Диаграммы классов (classdiagrams) показывают классы или типы сущностей системы, характеристики классов (поля и операции) и возможные связи между ними.

Диаграммы объектов (objectdiagrams) показывают часть объектов системы и связи между ними в некотором конкретном состоянии или суммарно, за некоторый интервал времени.

Диаграммы компонентов (componentdiagrams) представляют компоненты в нескольких смыслах — атомарные составляющие системы с точки зрения ее сборки, конфигурационного управления и развертывания.

Диаграммы развертывания (deploymentdiagrams) показывают декомпозицию системы на физические устройства различных видов — серверы, рабочие станции, терминалы, принтеры, маршрутизаторы и пр.

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

Диаграммы деятельности (activitydiagrams) иллюстрируют набор процессов-деятельностей и потоки данных между ними, а также возможные их синхронизации друг с другом.

Диаграммы сценариев (или диаграммы последовательности, sequencediagrams) показывают возможные сценарии обмена сообщениями или вызовами во времени между различными компонентами системы.

Диаграммы взаимодействия (collaborationdiagrams) показывают ту же информацию, что и диаграммы сценариев, но привязывают обмен сообщениями/вызовами не к времени, а к связям между компонентами.

Диаграммы состояний (statechartdiagrams) показывают возможные состояния отдельных компонентов или системы в целом, переходы между ними в ответ на какие-либо события и выполняемые при этом действия.

3. Понятие модели ЖЦ и ее роль в разработке ПО.

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

4. Каскадная модель ЖЦ и ее особенности.

Каскадная модель.

Каскадная модель (англ. waterfall model) — модель, жизненный цикл которой выглядит как поток, последовательно проходящий фазы анализа требований, проектирования. реализации, тестирования, интеграции и поддержки.

Жизненный цикл традиционно разделяют на следующие основные этапы:

• Анализ требований,

• Проектирование,

• Кодирование (программирование),

• Тестирование и отладка,

• Эксплуатация и сопровождение.

Достоинства модели:

• стабильность требований в течение всего жизненного цикла разработки;

• на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

• определенность и понятность шагов модели и простота её применения;

• выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие ресурсы (денежные. материальные и людские).

Недостатки модели:

• сложность чёткого формулирования требований и невозможность их динамического изменения на протяжении пока идет полный жизненный цикл;

• низкая гибкость в управлении проектом;

• последовательность линейной структуры процесса разработки, в результате возврат к предыдущим шагам для решения возникающих проблем приводит к увеличению затрат и нарушению графика работ;

• непригодность промежуточного продукта для использования;

Каскадная модель хорошо зарекомендовала себя при построении относительно простых ПО, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к продукту.

Реализовать Каскадную модель жизненного цикла затруднительно ввиду сложности разработки ПО без возвратов к предыдущим шагам и изменения их результатов для устранения возникающих проблем.

5. Итерационная модель ЖЦ и ее особенности.

Инкрементная модель

Инкрементная модель (англ. increment — увеличение, приращение) подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию.

Достоинства:

• затраты, которые получаются в связи с изменением требований пользователей, уменьшаются, повторный анализ и совокупность документации значительно сокращаются по сравнению с каскадной моделью;

• легче получить отзывы от клиента о проделанной работе — клиенты могут озвучить свои комментарии в отношении готовых частей и могут видеть, что уже сделано. Т.к. первые части системы являются прототипом системы в целом.

• у клиента есть возможность быстро получить и освоить программное обеспечение — клиенты могут получить реальные преимущества от системы раньше, чем это было бы возможно с каскадной моделью.

Недостатки:

• менеджеры должны постоянно измерять прогресс процесса.

• в случае быстрой разработки не стоит создавать документы для каждого минимального изменения версии;

• структура системы имеет тенденцию к ухудшению при добавлении новых компонентов — постоянные изменения нарушают структуру системы. Чтобы избежать этого требуется дополнительное время и деньги на рефакторинг. Плохая структура делает программное обеспечение сложным и дорогостоящим для последующих изменений. А прерванный Жизненный цикл ПО приводит еще к большим потерям.

• Схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к ПО. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ПО зафиксированы в виде технического задания на всё время её создания.