Структура жизненного цикла программы

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

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

Основным нормативным документом, регламентирующим ЖЦ, является международный стандарт ISO/IEC 12207: 1995 – «Информационные технологии – Процессы жизненного цикла программ» (ISO – International Organization of Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике).

Жизненный Цикл ПО. Уроки по тестированию. Обучение Junior qa

Структура ЖЦ по стандарту ISO/IEC 12207 базируется на трех группах процессов:

— основные процессы ЖЦ (приобретение, поставка, разработка, эксплуатация, сопровождение);

— вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, аттестация, аудит);

— организационные процессы (управление проектами, создание инфраструктуры проекта, улучшение самого ЖЦ, обучение).

Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.

Обеспечение качества проекта – верификация, тестирование ПО. Верификация – это процесс определения того, отвечает ли текущее состояние разработки требованиям данного этапа. Тестирование — поиск ошибок в программном продукте.

Управление проектом – планирование и организация работ, создание коллективов разработчиков, контроль за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, разработку методов и средств испытаний ПО, обучение персонала и т.п.

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

— каскадная модель (классический жизненный цикл, автор Уинстон Ройс, 1970) — старейшая парадигма процесса разработки ПО;

— спиральная модель (автор Барри Боэм, 1988) – наиболее распространенная в настоящее время модель ЖЦ.

Существуют 3 стратегии проектирования:

— однократный проход (каскадная или водопадная стратегия) — линейная последовательность этапов проектирования;

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

Видео 22. Жизненный цикл ПО. Этапы разработки ПО. Классическая модель разработки ПО

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

Характеристики стратегий конструирования ПО в соответствии с требованиями стандарта IEEE/EIA 12207.2 приведены в табл. 2.1.

Таблица 2.1- Характеристики стратегий проектирования

Стратегия	Определены ли все требования к началу процесса проектирования	Используется ли множество циклов конструирования	Распространяется ли промежуточное ПO
Однократный проход	Да	Нет	Нет
Инкрементная (запланированное улучшение продукта)	Да	Да	Может быть
Эволюционная	Нет	Да	Да

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

Расчетные и графические задания Равновесный объем — это объем, определяемый равенством спроса и предложения.

Кардиналистский и ординалистский подходы Кардиналистский (количественный подход) к анализу полезности основан на представлении о возможности измерения различных благ в условных единицах полезности.

Обзор компонентов Multisim Компоненты – это основа любой схемы, это все элементы, из которых она состоит. Multisim оперирует с двумя категориями.

Реформы П.А.Столыпина Сегодня уже никто не сомневается в том, что экономическая политика П.

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

Особенности массовой коммуникации Развитие средств связи и информации привело к возникновению явления массовой коммуникации.

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

ТЕОРИЯ ЗАЩИТНЫХ МЕХАНИЗМОВ ЛИЧНОСТИ В современной психологической литературе встречаются различные термины, касающиеся феноменов защиты.

Этические проблемы проведения экспериментов на человеке и животных В настоящее время четко определены новые подходы и требования к биомедицинским исследованиям.

Источник: studopedia.info

Тема 1.1. Структура жизненного цикла программы.

Комплексы программ создаются, эксплуатируются и развиваются во времени. Жизненный цикл программных средств включает в себя все этапы развития: от возникновения потребности в программе, определением целевого назначения, до полного прекращения использования этого программного ср-ва, вследствии его морального старения или потере необ-ти решения соответствующих задач. По длительности жизненного цикла, ПС можно разделить на два класса: с малым и большим временем жизни. Этим классам программ соответствует гибкий (мягкий) подход к их созданию и использованию и жесткий промышленный подход регламентированного проектирования и эксплуатации промышленных изделий. В научных организациях и вузах преобладают разработки программ 1 класса. А в проектных и промышленных организациях – второго. Программы с малой длительностью эксплуатации создаются в основном для решения научных и инженерных задач, для получения конкретных рез-тов выч-ний. Такие программы относительно не велики от 1 до 10000 команд. Разрабатываются как правило одним специалистом или маленькой группой, не предназначены для тиражирования и передачи для последующего использования в другие коллективы. ЖЦ таких программ состоит из длительного интервала системного анализа и форматизации проблемы, значительного этапа проектирования программ и относительно небольшого времени эксплуатации и получения рез-тов. Требования предъявляемые к функциональным и конструктивным хар-кам, как правило не формализуются, отсутствуют оформленные испытания программ и показатели их качества контролируются только разработчиками, в соответствии с неформальными представлениями. Сопровождение и модификация таких программ не нужны и их ЖЦ завершается после получения рез-тов вычислений. Основные затраты в ЖЦ таких программ приходятся на этапы системного анализа и проектирования, к-ые продолжаются от месяца до одного или двух лет. В рез-те ЖЦ редко превышает три года, т.е. основное время идет на анализ и проектирование. Программы с большой длительностью эксплуатации создаются для регулярной обработки инф-ции и управления в процессе функционирования сложных вычислительных систем. Размеры программных средств могут изменяться в широких пределах (от 1 до бесконечности команд), однако все они обладают свойством познаваемости и возможности модификации в процессе использования различными специалистами. Программы такого класса допускают тиражирование. Они сопровождаются документацией как промышленные изделия и представляют собой отчуждаемый программный продукт. Проектированием и эксплуатацией программного средства могут заниматься большие коллективы специалистов, для чего необ-ма формализация требуемых технических хар-к комплекса программ и их компонент. А также формализированные испытания и определение достигнутых показателей качества программных средств. ЖЦ таких программных средств составляет 10-20 лет, из которых 70-90% приходиться на эксплуатацию и сопровождение. Вследствии массового тиражирования и длительного сопровождения совокупные затраты в процессе эксплуатации и сопровождения могут значительно превышать затраты на системный анализ и проектирование. ЖЦ рассматриваемых программ включает в себя следующие основные этапы:

Появление потребности, постановка задачи

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

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

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

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

• Макетирование начинается со сбора и уточнения требований к создаваемому ПО. Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить.
• Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю.
• Быстрое проектирование приводит к построению макета.
• Макет оценивается заказчиком и используется для уточнения требований к ПО.

Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и, тем самым, не даст возможность разработчику понять, что должно быть сделано. Достоинство макетирования: обеспечивает определение полных требований к ПО. Недостатки макетирования:

1. заказчик может принять макет за продукт;
2. разработчик может принять макет за продукт.

Поясним суть недостатков. Когда заказчик видит работающую версию ПО, он перестает сознавать, что детали макета скреплены «жевательной резинкой и про­волокой»; он забывает, что в погоне за работающим вариантом оставлены нере­шенными вопросы качества и удобства сопровождения ПО. Когда заказчику гово­рят, что продукт должен быть перестроен, он начинает возмущаться и требовать, чтобы макет «в три приема» был превращен в рабочий продукт. Очень часто это отрицательно сказывается на управлении разработкой ПО. С другой стороны, для быстрого получения работающего макета разработчик часто идет на определенные компромиссы. Могут использоваться не самые подходящие язык программирования и ОС. Для простой демонстрации возможностей может применяться неэффективный алгоритм. Спустя время разработчик забывает о причинах, по которым эти средства не подходят. В результате далеко не идеальный выбранный вариант интегрируется в систему. Стратегии конструирования ПО. Существуют 3 стратегии конструирования ПО:

• однократный проход (водопадная стратегия) — линейная последовательность этапов конструирования;
• инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланиро­ванных возможностей, следующая версия реализует дополнительные возмож­ности и т. д., пока не будет получена полная система;
• эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.

Инкрементная модель является классическим примером инкрементной стратегии конструирования. Она объединяет элементы последовательной водопадной модели с итерационным макетированием. Каждая линейная последовательность вырабатывает поставляемый инкремент ПО. Первый инкремент приводит к получению базового продукта, реализующего базовые требования (многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность. По своей природе инкрементный процесс итеративен, но в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт. Быстрая разработка приложений. Модель быстрой разработки приложений (Rapid Application Development) – второй пример применения инкрементной стратегии конструирования.

RAD-модель обеспечивает экстремально короткий цикл разработки. RAD-высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, Rad-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:

• бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется инф-ция? Кто генерирует ее? Где инф-ция применяется? Кто ее обрабатывается?
• моделирование данных. Информационный поток, определенный на этапе биз­нес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, ат­рибуты) каждого объекта, определяются отношения между объектами.
• моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описании обработ­ки для добавления, модификации, удаления или нахождений (исправлений) объектом данных;
• генерация приложения. Предполагает использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации.
• тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).

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

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

Спиральная модель – классический пример применения эволюционной стратегии конструирования. Спиральная модель базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих парадигмах. Спиральная модель: 1- начальный сбор требований и планирование проекта, 2- та же работа, на основе рекомендаций заказчика, 3- анализ риска на основе начальных требований, 4-анализ риска на основе реакции заказчика, 5- переход к комплексной системе, 6- начальный макет системы, 7-следующий уровень макета, 8- сконструированная система, 9-оценование заказчиком. Как показано на рисунке, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

1. планирование – определение целей, вариантов и ограничений.
2. анализ риска – анализ вариантов и распознавание/выбор риска
3. конструирование – разработка продукта следующего уровня
4. оценивание – оценка заказчиком текущих результатов конструирования.

Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации. Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим ЖЦ или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по иерее продвижения от центра спирали. Достоинства спиральной модели:

1. наиболее реально (в виде эволюции) отображает разработку ПО
2. позволяет явно учитывать риск на каждом витке эволюции разработки
3. включает шаг системного подхода в итерационную структуру разработки
4. использует моделирование для уменьшения риска и совершенствования программного изделия

Недостатки спиральной модели:

1. новизна (отсутствует достаточная статистика эффективности модели)
2. повышенные требования к заказчику
3. трудности контроля и управления временем разработки.

Источник: studfile.net

Вопрос 3. Стандарты, регламентирующие жизненный цикл программного обеспечения. Структура жизненного цикла.

Вопрос 3. Стандарты, регламентирующие жизненный цикл программного обеспечения. Структура жизненного цикла.

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

В России создание ПО первоначально, в 70-е гг., регламентировалось стандартами серии ГОСТ 19.ХХХ — Единая система программной документации ( ЕСПД ): ГОСТ 19.001-77. ЕСПД. Общие положения; ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов; ГОСТ 19.102-77. ЕСПД. Стадии разработки; ГОСТ 19.105-78.

ЕСПД. Общие требования к программным документам; ГОСТ 19.201-78. ЕСПД. Техническое задание , требования к содержанию и оформлению; ГОСТ 19.201-78. ЕСПД.

Схемы алгоритмов , программ, данных и систем и т.д.

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

Процессы создания ав­томатизированных систем, в состав которых входит и ПО, рег­ламентированы стандартами серии ГОСТ 34.ХХХ — Комплекс стандартов на АС: ГОСТ 34.601-90. Информационная технология. АС. Стадии создания; ГОСТ 34.602-89. Информационная технология. Техническое задание на создание АС; ГОСТ 34.603-92. Информационная технология.

Виды испытаний АС; ГОСТ 34.201-89. Информационная технология. Виды, комплектность и обозначение документов при создании АС и т.д.

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

Основным зарубежным нормативным документом, наиболее полно и подро­б­но регламентирующим ЖЦ ПО , является международный стандарт ISO/IEC 12207 . ( ISO — International Organization of Standardization — Международная организация по стандартизации, IEC — International Electrotechnical Commission — Международная комиссия по электротехнике.)

Этапы работ в ГОСТ соответствуют процессам в ISO / IEC 12207. Сопоставление разных стандартов (ГОСТ и ISO ) показывает, что они в принципе регламентируют одни и те же работы при создании ПО . Но все же в отечественных разра­ботках целесообразно использовать современные международные стан­дарты.

Выбор стандарта на практике зависит от проекта (не бывает двух одинаковых проектов), от организационных основ коллективов специалистов, от стратегии их работы, от числа задействованного персонала и сторон-участников.

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

В результате для каждого серьезного проекта приходится создавать комплекты норматив­ных и методических документов , регламентирующих процессы созда­ния конкретного прикладного ПО .

Если проект не удается закончить к определенному сроку, если он не укладывается в предусмотренную смету или приводит к появлению плохих программ, то причину неудачи чаще всего следует искать в ошибках планирования всего ЖЦ или того или иного этапа ЖЦ.

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

Источник: dmtsoft.ru