ЖИЗНЕННЫЙ ЦИКЛ ПО ИС - презентация, доклад, проект скачать

Нажмите для полного просмотра!

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему ЖИЗНЕННЫЙ ЦИКЛ ПО ИС. Доклад-сообщение содержит 36 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

ЖИЗНЕННЫЙ ЦИКЛ ПО ИС

Слайд 2

Описание слайда:

Слайд 3

Описание слайда:

Жизненный цикл ПО ИС это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207. Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС.

Слайд 4

Описание слайда:

Слайд 5

Описание слайда:

Слайд 6

Описание слайда:

Слайд 7

Описание слайда:

Слайд 8

Описание слайда:

Слайд 9

Описание слайда:

Слайд 10

Описание слайда:

Стандартный подход В соответствии со стандартным подходом (основан на стандарте ISO 12207) структура ЖЦ разработки ПО базируется на 3 группах процессов: Основные Вспомогательные Организационные

Слайд 11

Описание слайда:

Основные процессы приобретение; поставка; разработка; эксплуатация; сопровождение.

Слайд 12

Описание слайда:

Процесс приобретения состоит из действий и задач заказчика: Действие - инициирование приобретения - включает задачи: определение заказчиком своих потребностей в приобретении; анализ требований к системе; принятие решения относительно приобретения; проверку наличия необходимой документации, гарантий, сертификатов, лицензий и поддержки в случае приобретения ПО; подготовку и утверждение плана приобретения, включающего требования к системе, тип договора, ответственность сторон

Слайд 13

Описание слайда:

Действие – подготовка заявочных предложений. Заявочные предложения должны содержать: требования к системе; перечень программных продуктов; условия и соглашения; технические ограничения (например, среда функционирования системы).

Слайд 14

Описание слайда:

Действие - подготовка и корректировка договора - включает задачи: определение заказчиком процедуры выбора поставщика, включающей критерии оценки предложений возможных поставщиков; выбор конкретного поставщика на основе анализа предложений.; подготовку и заключение договора с поставщиком;

Слайд 15

Описание слайда:

Вспомогательные процессы: документирование; управление конфигурацией; обеспечение качества; верификация; аттестация; совместная оценка; аудит; разрешение проблем.

Слайд 16

Описание слайда:

Организационные процессы: управление; усовершенствование; создание инфраструктуры; обучение.

Слайд 17

Описание слайда:

Классический подход Кроме стандартного, т. е. основанного на стандарте ISO 12207, набора процессов ЖЦ ПО, существует набор классический, включающий основные процессы, сложившиеся исторически в результате практического опыта разработки программного обеспечения. Процессы классического набора фактически являются подмножеством стандартного

Слайд 18

Описание слайда:

В классическом наборе можно выделить девять технологических процессов: возникновение и исследование идеи; управление; анализ требований; проектирование; программирование; тестирование и отладка; ввод в действие; эксплуатация и сопровождение; завершение эксплуатации;

Слайд 19

Описание слайда:

Модель ЖЦ ПО ИС Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов на протяжении ЖЦ. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.

Слайд 20

Описание слайда:

Модель ЖЦ ИС включает в себя: Модель ЖЦ ИС включает в себя: Стадии Результаты выполнения работ на каждой стадии Ключевые события — точки завершения работ и принятия решений. Модель ЖЦ - пример каскадная спиральная

Слайд 21

Описание слайда:

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

Слайд 22

Описание слайда:

Каскадно-возвратная

Слайд 23

Описание слайда:

Спиральная модель

Слайд 24

Описание слайда:

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

Слайд 25

Описание слайда:

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

Слайд 26

Описание слайда:

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

Слайд 27

Описание слайда:

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

Слайд 28

Описание слайда:

Преимущества спиральной модели

Слайд 29

Описание слайда:

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

Слайд 30

Описание слайда:

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

Слайд 31

Описание слайда:

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

Слайд 32

Описание слайда:

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

Слайд 33

Описание слайда:

Недостатки каскадной модели – подробно Сложность параллельного ведения работ. Отмеченные проблемы возникают вследствие того, что работа над проектом строится в виде цепочки последовательных шагов. Причем даже в том случае, когда разработку некоторых частей проекта (подсистем) можно вести параллельно, при использовании каскадной схемы распараллеливание работ весьма затруднительно. Сложности параллельного ведения работ связаны с необходимостью постоянного согласования различных частей проекта. Отсутствие параллелизма негативно сказывается и на организации работы всего коллектива разработчиков. Работа одних групп сдерживается другими. Пока производится анализ предметной области, проектировщики, разработчики и те, кто занимается тестированием и администрированием, почти не загружены. Кроме того, при последовательной разработке крайне сложно внести изменения в проект после завершения этапа и передачи проекта на следующую стадию. Так, например, если после передачи проекта на следующий этап группа разработчиков нашла более эффективное решение, оно не может быть использовано. Это связано с тем, что более раннее решение уже, возможно, реализовано и связано с другими частями проекта. Поэтому исключается (или, по крайней мере, существенно затрудняется) доработка проекта после его передачи на следующий этап.

Слайд 34

Описание слайда:

Недостатки каскадной модели – подробно Информационная перенасыщенность. Проблема информационной перенасыщенности возникает вследствие сильной зависимости между различными группами разработчиков. Данная проблема заключается в том, что при внесении изменений в одну из частей проекта необходимо оповещать всех разработчиков, которые использовали или могли бы использовать эту часть в своей работе. Когда система состоит из большого количества взаимосвязанных подсистем, то синхронизация внутренней документации становится важной самостоятельной задачей. При этом синхронизация документации на каждую часть системы — не более чем процесс оповещения групп разработчиков. Самим же разработчикам необходимо ознакомиться с изменениями и оценить, не сказались ли эти изменения на уже полученных результатах. Все это может требовать проведения повторного тестирования и даже внесения изменений в уже готовые части проекта. Причем эти изменения, в свою очередь, должны быть отражены во внутренней документации и разосланы другим группам разработчиков. Как следствие, объем документации по мере разработки проекта растет очень быстро, так что требуется все больше времени для составления документации и ознакомления с ней. Следует также отметить, что, помимо изучения нового материала, не отпадает необходимость в изучении старой информации. Это связано с тем, что вполне вероятна ситуация, когда в процессе разработки изменяется состав группы разработчиков (этот процесс носит название ротации кадров). Новым разработчикам необходима информация о том, что было сделано до них. Причем чем сложнее проект, тем больше времени требуется, чтобы ввести нового разработчика в курс дела.

Слайд 35

Описание слайда:

Недостатки каскадной модели – подробно Сложность управления проектом при использовании каскадной схемы в основном обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между различными частями проекта. Последовательность разработки проекта приводит к тому, что одни группы разработчиков должны ожидать результатов работы других команд. Поэтому требуется административное вмешательство для согласования сроков работы и состава передаваемой документации. В случае же обнаружения ошибок в выполненной работе необходим возврат к предыдущим этапам выполнения проекта. Это приводит к дополнительным сложностям в управлении проектом. Разработчики, допустившие просчет или ошибку, вынуждены прервать текущую работу (над новым проектом) и заняться исправлением ошибок. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов. Требовать же от команды разработчиков ожидания окончания следующей стадии разработки нерационально, так как приводит к существенным потерям рабочего времени. Упростить взаимодействие между группами разработчиков и уменьшить информационную перенасыщенность документации можно, сокращая количество связей между отдельными частями проекта. Однако это обычно весьма непросто. Далеко не каждую информационную систему можно разделить на несколько слабо связанных подсистем.

Слайд 36

Описание слайда:

Недостатки каскадной модели – подробно Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого из этапов разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество которых также увеличивается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, то есть после завершения анализа, проектирования и разработки — этапов, выполнение которых требует значительного времени и средств. Как уже было отмечено, запоздалая оценка порождает серьезные проблемы при выявлении ошибок анализа и проектирования — требуется возврат проекта на предыдущие стадии и повторение процесса разработки. Однако возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими в предметной области или в требованиях заказчика за время разработки. Причем возврат проекта на доработку вследствие этих причин не гарантирует, что предметная область снова не изменится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность того, что процесс разработки «зациклится», и система никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового продукта постоянно откладываться.

Теги ЖИЗНЕННЫЙ ЦИКЛ

Похожие презентации