Разделы презентаций
- Разное
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
В. В. Шилов Жизненный цикл программных средств Москва, 201 8 год ВВЕДЕНИЕ В
Содержание
- 1. В. В. Шилов Жизненный цикл программных средств Москва, 201 8 год ВВЕДЕНИЕ В
- 2. Жизненный цикл (ЖЦ) – совокупность процессов и
- 3. Жизненный цикл программного обеспечения – период времени
- 4. Процессы жизненного цикла Международный стандарт ISO /IEC 12207:1995 “Information
- 5. Стандарт определяет структуру ЖЦ, содержащую: - процессы, - действия, -
- 6. Согласно стандарту ISO / IEC 12207, все процессы ЖЦ ПО разделены на три группы.
- 7. I. Основные процессы5 основных процессов:
- 8. Процесс приобретения состоит из действий и задач
- 9. Задачи инициирования приобретения: - определение
- 10. Заявочные предложения должны содержать: -
- 11. Задачи подготовки и корректировки договора:
- 12. В процессе приемки подготавливаются и выполняются необходимые
- 13. Процесс поставки охватывает действия и задачи поставщика,
- 14. Инициирование поставки – рассмотрение поставщиком заявочных предложений
- 15. Процесс разработки – действия и задачи, выполняемые
- 16. Подготовительная работа начинается с выбора модели ЖЦ ПО,
- 17. Процесс эксплуатации охватывает действия и задачи оператора,
- 18. Процесс сопровождения охватывает действия и задачи сопровождающей
- 19. Действия:- подготовительная работа (планирование действий и работ,
- 20. Действия:- перенос ПО в другую среду (конвертирование
- 21. II. Вспомогательные процессы8 вспомогательных процессов:
- 22. Процесс документирования предусматривает формализованное описание информации, созданной
- 23. II.2 Процесс управления конфигурациейКонфигурация ПО – совокупность его
- 24. Действия:- подготовительная работа (планирование управления конфигурацией);- идентификация
- 25. - оценка конфигурации – определение функциональной полноты компонентов ПО,
- 26. Процесс обеспечения качестваII.3 Качество ПО – совокупность свойств, которая
- 27. Действия:- подготовительная работа (координация с другими вспомогательными
- 28. Процесс верификации – установление того факта, что результирующее
- 29. - корректность описания в проектных
- 30. II.5 Процесс аттестации – определение полноты соответствия
- 31. Процесс совместной оценки – оценка состояния работ по проекту и
- 32. II.7 Процесс аудита – определение соответствия проекта и
- 33. II.8 Процесс разрешения проблемПредусматривает анализ и разрешение проблем (включая
- 34. III. Организационные процессы4 организационных процесса:
- 35. III.1 Процесс управления – состоит из действий
- 36. III.2 Процесс создания инфраструктуры – выбор и
- 37. III.3 Процесс усовершенствования – оценка, измерение, контроль и собственно
- 38. III.4 Процесс обучения – первоначальное обучение и
- 39. Классы программМалые. Сравнительно небольшие программы, создаваемые одним
- 40. Классы программБольшие. Крупномасштабные комплексы программ, оформляемые в виде программных продуктов с гарантированными качествами.
- 41. Модели процессов жизненного циклаМодель ЖЦ ПО – структура,
- 42. Стадии жизненного цикла программной системыформирование требований к
- 43. Каскадная модель ЖЦ
- 44. W. Royce. Managing the development of large
- 45. Преимущества каскадной модели: на каждой стадии формируется законченный
- 46. Недостатки каскадной модели:- выявление и устранение ошибок производится
- 47. Далеко не всегда удается детально проработать проект
- 48. Итерационная модель ЖЦ
- 49. Стратегии конструирования ПООднократный проход – линейная последовательность
- 50. Инкрементная модель ЖЦПример инкрементной стратегии конструирования. Объединяет
- 51. Каждая линейная последовательность вырабатывает поставляемый инкремент ПО.
- 52. Барри Боэм, 1986 г.Спиральная (эволюционная) модель ЖЦ
- 53. Базируется на лучших свойствах классического жизненного цикла,
- 54. С каждой итерацией по спирали строятся все
- 55. Достоинства спиральной модели:- наиболее реально (в виде эволюции)
- 56. Сравнение характеристик стратегий конструирования
- 57. СПАСИБОЗА ВНИМАНИЕ!
- 58. Скачать презентанцию
Жизненный цикл (ЖЦ) – совокупность процессов и этапов развития организмов живой природы, технических систем, продуктов производства, процессов и услуг от моментов зарождения или появления потребности в их создании и использовании до
Слайды и текст этой презентации
Слайд 1В. В. Шилов
Жизненный цикл программных средств
Москва, 2018 год
ВВЕДЕНИЕ
В ПРОГРАММНУЮ
ИНЖЕНЕРИЮ
Слайд 2Жизненный цикл (ЖЦ) – совокупность процессов и этапов развития организмов
живой природы, технических систем, продуктов производства, процессов и услуг от
моментов зарождения или появления потребности в их создании и использовании до прекращения функционирования или применения.Жизненный цикл
Слайд 3Жизненный цикл программного обеспечения – период времени от зарождения замысла
создания до момента, когда его дальнейшее использование становится нецелесообразным.
Жизненный цикл
программного обеспечения – период времени, который начинается с момента принятия решения о необходимости создания ПС и закачивается в момент ее полного изъятия из эксплуатации.
Слайд 4Процессы жизненного цикла
Международный стандарт ISO /IEC 12207:
1995 “Information Technology – Software Life Cycle Process”
(ISO – International
Organization for Standardization – Международная организация по стандартизации,
IEC – International Electrotechnical Commission –
Международная комиссия по электротехнике).
Основной
нормативный документ, регламентирующий состав процессов ЖЦ ПС.
Слайд 5Стандарт определяет структуру ЖЦ, содержащую:
- процессы,
- действия,
- задачи,
которые должны быть
выполнены во время создания ПС.
В этом стандарте ПС (или программный продукт)
определяется как набор компьютерных программ, процедур и, возможно, связанной с ними документации, и данных.Процесс – совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные.
Каждый процесс характеризуется определенными задачами и методами их решения.
Каждый процесс разделен на набор действий, а каждое действие – на набор задач.
Слайд 7I. Основные процессы
5 основных процессов:
• приобретение,
• поставка,
• разработка,
• эксплуатация,• сопровождение.
Слайд 8Процесс приобретения состоит из действий и задач заказчика, приобретающего ПС.
Действия:
- инициирование приобретения;
- подготовка заявочных
предложений;- подготовка и корректировка договора;
- надзор за деятельностью поставщика;
- приемка и завершение работ.
I.1
Слайд 9Задачи инициирования приобретения:
- определение заказчиком своих потребностей
в приобретении, разработке или усовершенствовании системы, программных продуктов или
услуг;- анализ требований, предъявляемых к системе;
- принятие решения относительно приобретения, разработки или усовершенствования существующего ПО;
- проверка наличия необходимой документации, гарантий, сертификатов, лицензий и поддержки в случае приобретения программного продукта;
- подготовка и утверждение плана приобретения, включающего требования к системе, тип договора, ответственность сторон и др.
I. Основные процессы
I.1. Процесс приобретения.
Действие: Инициирование приобретения
I.1
Слайд 10Заявочные предложения должны содержать:
- требования, предъявляемые к
системе;
- перечень программных продуктов;
-
условия приобретения и соглашения;- технические ограничения (например, по среде
функционирования системы).
Заявочные предложения направляются к выбранному поставщику (в случае тендера – нескольким поставщикам).
Поставщик – организация, которая заключает договор с заказчиком на поставку системы или ПО на условиях, оговоренных в договоре.
I. Основные процессы
I.1. Процесс приобретения.
Действие: Подготовка заявочных предложений
I.1
Слайд 11Задачи подготовки и корректировки договора:
- определение заказчиком
процедуры выбора поставщика, включающей критерии оценки предложений возможных поставщиков;
- выбор конкретного поставщика на основе анализа предложений;- подготовка и заключение договора с поставщиком ;
- внесение изменений (при необходимости) в договор в процессе его выполнения.
I. Основные процессы
I.1. Процесс приобретения.
Действие: Подготовка и корректировка договора
I.1
Слайд 12
В процессе приемки подготавливаются и выполняются необходимые тесты. Работы по договору завершаются
при удовлетворении всех условий приемки.
I. Основные процессы
I.1. Процесс приобретения.
Действие:
Надзор за деятельностью поставщикаНадзор за деятельностью поставщика осуществляется в соответствии с действиями, предусмотренными в процессах совместной оценки и аудита.
I.1. Процесс приобретения.
Действие: Приемка и завершение работ
I.1
Слайд 13Процесс поставки охватывает действия и задачи поставщика, снабжающего заказчика программным
продуктом.
Действия:
- инициирование поставки;
- подготовка
ответа на заявочные предложения;- подготовка договора;
- планирование работ по договору;
- выполнение, контроль и оценка работ;
- поставка и завершение работ.
I.2
Слайд 14Инициирование поставки – рассмотрение поставщиком заявочных предложений и принятие решения,
соглашаться ли с выставленными требованиями и условиями или предложить и
согласовать свои.Планирование включает задачи:
- принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;
- разработка поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответственности, технические требования к среде разработки и ресурсам, управление субподрядчиками и др.
I. Основные процессы
I.2. Процесс поставки.
Действие: Инициирование поставки
I.2
Слайд 15Процесс разработки – действия и задачи, выполняемые разработчиком; охватывает работы по созданию ПО и
его компонентов в соответствии с заданными требованиями.
Действия:
-
подготовительная работа;- анализ требований, предъявляемых к системе;
- проектирование архитектуры системы;
- анализ требований, предъявляемых к ПО;
- проектирование архитектуры ПО;
- детальное проектирование ПО;
- кодирование и тестирование ПО;
- интеграция ПО;
- квалификационное тестирование ПО;
- интеграция системы;
- квалификационное тестирование системы;
- установка ПО;
- приемка ПО.
I.3
Слайд 16Подготовительная работа начинается с выбора модели ЖЦ ПО, соответствующей масштабу, значимости
и сложности проекта. Действия и задачи процесса разработки должны соответствовать
выбранной модели. Разработчик должен выбирать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки, а также составить план выполнения работ.Действие: Анализ требований, предъявляемых к системе
Анализ требований, предъявляемых к системе – определение ее функциональных возможностей, пользовательских требований, требований к надежности, безопасности, требований к внешним интерфейсам, производительности и т.д. Требования к системе оцениваются, исходя из критериев реализуемости и возможности проверки при тестировании.
<…>
I.3
I. Основные процессы
I.3. Процесс разработки.
Действие: Подготовительная работа
Слайд 17Процесс эксплуатации охватывает действия и задачи оператора, эксплуатирующего систему.
Действия:
- подготовительная работа, включающая проведение оператором задач:
планирование действий и работ, выполняемых в процессе эксплуатации, установка эксплуатационных стандартов;определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации;
- эксплуатационное тестирование каждой очередной редакции программного продукта перед ее передачей в эксплуатацию;
- собственно эксплуатация системы, которая выполняется в предназначенной для этого среде в соответствии с пользовательской документацией;
- поддержка пользователей – оказание помощи и консультации при обнаружении ошибок в процессе эксплуатации ПО.
I.4
Слайд 18Процесс сопровождения охватывает действия и задачи сопровождающей организации при изменениях
(модификациях) программного продукта и соответствующей документации.
I.5
Эти изменения могут быть
вызваны возникшими проблемами или потребностями в модернизации или адаптации ПО.
Слайд 19Действия:
- подготовительная работа (планирование действий и работ, определение процедур локализации
и разрешения проблем, возникающих в процессе сопровождения);
- анализ проблем и
запросов на модификацию ПО (анализ сообщений о возникшей проблеме или запроса на модификацию, оценка масштаба, стоимости модификации, получаемого эффекта, оценка целесообразности модификации);- модификация ПО (внесение изменений в компоненты программного продукта и документацию в соответствии с правилами процесса разработки);
- проверка и приемка (в части целостности модифицируемой системы);
I.5
I. Основные процессы
I.5. Процесс сопровождения.
Слайд 20Действия:
- перенос ПО в другую среду (конвертирование программ и данных,
параллельная эксплуатация ПО в старой и новой среде в течение
некоторого периода времени);- снятие ПО с эксплуатации по решению заказчика при участии эксплуатирующей организации, службы сопровождения и пользователей. При этом программные продукты и документация подлежат архивированию в соответствии с договором.
I.5
I. Основные процессы
I.5. Процесс сопровождения.
Слайд 21II. Вспомогательные процессы
8 вспомогательных процессов:
• документирование,
• управление конфигурацией,
•
обеспечение качества,• верификация,
• аттестация,
• совместная оценка,
• аудит,
• разрешение проблем.
Слайд 22Процесс документирования предусматривает формализованное описание информации, созданной в течение ЖЦ ПО.
Состоит
из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают,
редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких как руководство, технические специалисты и пользователи системы.Действия:
- подготовительная работа;
- проектирование и разработка;
- выпуск документации;
- сопровождение.
II.1
II. Вспомогательные процессы
Слайд 23II.2
Процесс управления конфигурацией
Конфигурация ПО – совокупность его функциональных и физических
характеристик, установленных в технической документации и реализованных в ПО.
Стандарт IEEE-90
Управление
конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.Стандарт ISO / IEC 15288
"Information Technology. Software Life Cycle Process. Configuration Management for Software".
II. Вспомогательные процессы
Слайд 24Действия:
- подготовительная работа (планирование управления конфигурацией);
- идентификация конфигурации (установление правил,
с помощью которых однозначно идентифицируются компоненты ПО и их версии.
При этом каждому компоненту однозначно соответствует комплект документации);- контроль конфигурации – систематическая оценка предлагаемых модификаций ПО и их координированная реализация с учетом эффективности каждой модификации и затрат на ее выполнение;
- учет состояния конфигурации – регистрация состояния компонентов ПО. Обеспечивает подготовку отчетов о реализованных и отвергнутых модификациях версий компонентов ПО. Совокупность отчетов дает однозначное отражение текущего состояния системы и ее компонентов, а также обеспечивает ведение истории модификаций.
II. Вспомогательные процессы
II.2. Процесс управления конфигурацией.
II.2
Слайд 25- оценка конфигурации – определение функциональной полноты компонентов ПО, а также соответствия
их физического состояния текущему техническому описанию;
- управление выпуском и поставка,
охватывающие изготовление эталонных копий программ и документации, их хранение и поставку пользователям в соответствии с порядком, принятым в организации.II. Вспомогательные процессы
II.2. Процесс управления конфигурацией.
II.2
Слайд 26Процесс обеспечения качества
II.3
Качество ПО – совокупность свойств, которая характеризует способность ПО удовлетворять заданным
требованиям.
Процесс обеспечения качества должен происходить независимо от субъектов, непосредственно связанных
с разработкой программного продукта. При этом могут использоваться результаты других вспомогательных процессов, таких как верификация, аттестация, совместная оценка, аудит и разрешение проблем.II. Вспомогательные процессы
Слайд 27Действия:
- подготовительная работа (координация с другими вспомогательными процессами и планирование
самого процесса обеспечения качества ПО с учетом используемых стандартов, методов,
процедур и средств);- обеспечение качества продукта, подразумевающего гарантированное полное соответствие ПО и его документации требованиям заказчика, предусмотренным в договоре;
- обеспечение качества процесса, предполагающее гарантированное соответствие процессов ЖЦ ПО, методов разработки, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам;
- обеспечение прочих показателей качества ПО, осуществляемое в соответствии с условиями договора и стандартом качества ISO 9001.
II.3
II. Вспомогательные процессы
II.3. Процесс обеспечения качества.
Слайд 28Процесс верификации – установление того факта, что результирующее ПО полностью удовлетворяет
требованиям.
II.4
Процесс верификации включает анализ, оценку, тестирование.
В ходе верификации
проверяются:- непротиворечивость требований, предъявляемых к системе, и степень учета потребностей пользователей;
- возможность поставщика выполнить заданные требования;
- соответствие выбранных процессов ЖЦ ПО условиям договора;
- адекватность стандартов, процедур и среды разработки процессам ЖЦ ПО;
- соответствие проектных спецификаций ПО заданным требованиям;
II. Вспомогательные процессы
Слайд 29 - корректность описания в проектных спецификациях входных и
выходных данных, последовательности событий, интерфейсов, логики и т.д.;
-
соответствие кода проектным спецификациям и требованиям;- тестируемость и корректность кода, его соответствие принятым стандартам кодирования;
- корректность интеграции компонентов ПО в систему;
- адекватность, полнота и непротиворечивость документации.
Верификацию могут проводить инстанции с различными степенями независимости (от самого исполнителя до специалистов другой организации, не зависящей от поставщика, разработчика и т.д.).
II.4
II. Вспомогательные процессы
II.4. Процесс верификации.
Слайд 30II.5
Процесс аттестации – определение полноты соответствия заданных требований и
созданного ПО их конкретному функциональному назначению (требованиям потребителя).
Под аттестацией обычно понимается подтверждение
и оценка достоверности проведенного тестирования программного продукта.Аттестация должна гарантировать полное соответствие ПО спецификациям, требованиям и документации, а также возможность безопасного и надежного применения ПО пользователем.
Как и верификация, может осуществляться с различными степенями независимости (вплоть до организации, не зависящей от поставщика, разработчика, оператора или службы сопровождения).
II. Вспомогательные процессы
II.5. Процесс аттестации.
Слайд 31Процесс совместной оценки – оценка состояния работ по проекту и программному продукту, создаваемому
при выполнении этих работ.
II.6
Сосредоточен в основном на контроле планирования и
управления ресурсами, персоналом, аппаратурой и инструментальными средствами проекта.Оценка применяется как на уровне управления проектом, так и на уровне технической реализации проекта и проводится в течение всего срока действия договора.
Этот процесс может выполняться двумя сторонами, участвующими в договоре, при этом одна сторона проверяет другую.
II. Вспомогательные процессы
II.6. Процесс совместной оценки.
Слайд 32II.7
Процесс аудита – определение соответствия проекта и продукта требованиям, планам
и условиям договора.
Аудит – ревизия (проверка), проводимая компетентным органом (лицом) для
обеспечения независимой оценки степени соответствия ПО или процессов установленным требованиям.Аудит служит для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Аудиторы не должны иметь прямой зависимости от разработчиков ПО. Они определяют состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность тестирования и др.
Аудит может производиться двумя любыми сторонами, участвующими в договоре, когда одна сторона проверяет другую.
II. Вспомогательные процессы
II.7. Процесс аудита.
Слайд 33II.8
Процесс разрешения проблем
Предусматривает анализ и разрешение проблем (включая обнаруженные несоответствия), которые
обнаружены в ходе разработки, эксплуатации или других процессов независимо от
их происхождения или источника.II. Вспомогательные процессы
Слайд 34III. Организационные процессы
4 организационных процесса:
• управление,
• создание инфраструктуры,
•
усовершенствование,• обучение.
Слайд 35III.1
Процесс управления – состоит из действий и задач, которые
могут выполняться любой стороной (менеджером), управляющей своими процессами.
Действия:
- инициирование и определение области управления – менеджер должен убедиться, что необходимые для управления ресурсы (персонал, оборудование и технология) имеются в его распоряжении в достаточном количестве;- планирование, как действие, подразумевает выполнение следующих задач:
составление графиков выполнения работ;
оценка затрат;
выделение требуемых ресурсов;
распределение ответственности;
оценка рисков, связанных с конкретными задачами;
создание инфраструктуры управления.
III. Организационные процессы
Слайд 36III.2
Процесс создания инфраструктуры – выбор и поддержка технологий, стандартов
и инструментальных средств, используемых для разработки, эксплуатации или сопровождения ПО.
Действия:
- подготовительная работа;- создание инфраструктуры;
- сопровождение инфраструктуры.
Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к соответствующим процессам.
Инфраструктура, в свою очередь, является одним из объектов управления конфигурацией.
III. Организационные процессы
Слайд 37III.3
Процесс усовершенствования – оценка, измерение, контроль и собственно усовершенствование процессов ЖЦ ПО.
Действия:
- создание процесса;
- оценка процесса;
- усовершенствование процесса.Цель – повышение производительности труда всех участвующих в них специалистов.
Посредством: совершенствования используемой технологии, методов управления, выбора инструментальных средств и обучения персонала.
Основано на анализе достоинств и недостатков каждого процесса. Анализу способствует накопление в организации исторической, технической, экономической и иной информации по реализованным проектам.
III. Организационные процессы
Слайд 38III.4
Процесс обучения – первоначальное обучение и последующее постоянное повышение
квалификации персонала.
Действия:
- подготовительная работа;
-
разработка учебных материалов;- реализация планов обучения.
III. Организационные
процессы
Слайд 39Классы программ
Малые. Сравнительно небольшие программы, создаваемые одним специалистом или небольшим
коллективом.
Назначение: получение конкретных результатов при автоматизации научных исследований, анализ
относительно простых процессов самими разработчиками программ;Не предназначены для массового тиражирования и распространения как программного продукта на рынке;
Не имеют конкретного независимого заказчика-потребителя, определяющего требования к программам и их финансирование;
Не ограничены стоимостью, трудоемкостью и сроками создания, требованиями заданного качества и документирования;
Не подлежат независимому тестированию, гарантированию качества и/или сертификации.
Их ЖЦ носит непредсказуемый характер по всем параметрам.
Слайд 40Классы программ
Большие. Крупномасштабные комплексы программ, оформляемые в виде программных продуктов
с гарантированными качествами.
Слайд 41Модели процессов жизненного цикла
Модель ЖЦ ПО – структура, определяющая последовательность выполнения
и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель
ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.Стандарт ISO /IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО. Стандарт описывает структуру процессов ЖЦ ПО, но не конкретизирует, как реализовывать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ любого конкретного ПО определяет характер процесса его создания, – совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии (фазы) работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям.
Слайд 42Стадии жизненного цикла программной системы
формирование требований к ПО;
исследование и описание
основных концепций;
проектирование и разработка;
испытания системы;
внедрение;
распространение и продажа;
эксплуатация;
сопровождение и мониторинг;
снятие с
эксплуатации (утилизация).
Слайд 44W. Royce. Managing the development of large software systems. 1970
Другое
название – водопадная (waterfall) модель.
Особенность модели – переход на следующую
ступень осуществляется только после того, как полностью завершается работа на предыдущей стадии; возвраты на пройденные стадии не предусмотрены. 
Слайд 45Преимущества каскадной модели:
на каждой стадии формируется законченный набор проектной документации,
отвечающей критериям полноты и согласованности;
стадии работ выполняются в логической
последовательности, что позволяет планировать сроки завершения всех работ и соответствующие затраты.Каскадный подход хорош при построении ПС, для которых в самом начале проекта можно полно и четко сформулировать все требования.
Слайд 46Недостатки каскадной модели:
- выявление и устранение ошибок производится только на стадии
тестирования, которое может существенно растянуться;
- реальные проекты часто требуют отклонения
от стандартной последовательности шагов;- цикл основан на точной формулировке исходных требований к ПС, в действительности в начале проекта требования заказчика быть определены лишь частично;
- результаты работ доступны заказчику только по завершении проекта.
Слайд 47Далеко не всегда удается детально проработать проект будущей системы, поскольку
многие аспекты ее функционирования меняются, пока система создается. Потребовалось изменить
процесс разработки так, чтобы гарантировать внесение необходимых исправлений после завершения какого-либо этапа разработки. Так появилась итерационная модель ЖЦ ПС.В итерационной модели недостатки проектирования и программирования могут быть устранены путем частичного возврата на предыдущую стадию. Чем ниже уровень обнаружения ошибки, тем дороже ее исправление.
Итерационная модель ЖЦ
Слайд 49Стратегии конструирования ПО
Однократный проход – линейная последовательность этапов конструирования (каскадная
стратегия).
Инкрементная стратегия. В начале процесса определяются все пользовательские и системные
требования, конструирование выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т.д., пока не будет получена полная система.Эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определяются не все требования. Требования уточняются в результате разработки версий.
Слайд 50Инкрементная модель ЖЦ
Пример инкрементной стратегии конструирования. Объединяет элементы последовательной водопадной
модели с итерационной.
Предложена Б. Боэмом как усовершенствование каскадной модели.
Слайд 51Каждая линейная последовательность вырабатывает поставляемый инкремент ПО. Например, ПО для
обработки текстов в 1-м инкременте (версии) реализует функции базовой обработки
файлов, функции редактирования и документирования; во 2-м инкременте – более сложные возможности редактирования и документирования; в 3-м инкременте – проверку орфографии и грамматики.1-й инкремент приводит к получению базового продукта, реализующего базовые требования (хотя многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность.
Инкрементный процесс итеративен и обеспечивает на каждом инкременте работающий продукт.
Инкрементная модель ЖЦ
Слайд 53Базируется на лучших свойствах классического жизненного цикла, к которым добавляется
новый элемент – анализ риска, отсутствующий в этих парадигмах.
Модель определяет
четыре действия, представленные четырьмя квадрантами спирали:Планирование – определение целей, вариантов и ограничений.
Анализ риска – анализ вариантов и распознавание/выбор риска.
Конструирование – разработка продукта следующего уровня.
Оценивание – оценка заказчиком текущих результатов конструирования.
Спиральная (эволюционная) модель ЖЦ
Слайд 54С каждой итерацией по спирали строятся все более полные версии
ПС. В первом витке спирали определяются начальные цели, варианты и
ограничения, распознается и анализируется риск.Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде “продолжать, не продолжать”. Если риск слишком велик, проект может быть остановлен.
Спиральная (эволюционная) модель ЖЦ
Слайд 55Достоинства спиральной модели:
- наиболее реально (в виде эволюции) отображает разработку программного
обеспечения;
- позволяет явно учитывать риск на каждом витке эволюции разработки;
-
включает в итерационную структуру разработки элементы системного подхода.Недостатки спиральной модели:
- предъявляет повышенные требования к заказчику;
- трудности контроля и управления временем разработки.
Спиральная (эволюционная) модель ЖЦ
