Назначение базового профиля жизненного цикла программных средств.

Назначение базового профиля жизненного цикла программных средств.

В Беларуси создание и испытания систем, которые включают ПС и БД, регламентированы небольшой группой ГОСТов. В области обеспечения ЖЦ и качества сложных комплексов программ существует и применяется группа стандартов ГОСТ ЕСПД, которые отстают от мирового уровня на 5–8 лет. В них создание, сопровождение и совершенствование программных средств отражены недостаточно.

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

При создании и развитии сложных распределенных тиражируемых ПС целесообразно гибкое формирование и применение гармонизированных совокупностей базовых стандартов и нормативных документов разного уровня, выделение в них требований и рекомендаций, необходимых для реализации заданных функций ПС и обеспечения их высокого качества. Для унификации и регламентирования процессов ЖЦ ПС такие совокупности стандартов должны адаптироваться и конкретизироваться применительно к определенным классам проектов, процессов и компонентов ПС. В связи с этим выделилось и сформировалось понятие профилей стандартов.

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

· профили, регламентирующие процессы ЖЦ и системы обеспечения качества проектирования, разработки, применения, сопровождения и совершенствования ПС и их компонентов;

· профили, регламентирующие объекты: архитектуру и структуру ПС и их компонентов – функции, интерфейсы и протоколы взаимодействия, форматы данных.

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

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

 

 

Какие типы процессов и конкретные процессы вы запомнили?

Группы процессов ЖЦ ПО

Основные	Вспомогательные	Организационные
Заказа	Документирования	Управления
Поставки	Управления конфигурацией	Создания инфраструктуры
Разработки	Обеспечения качества: · верификации, · аттестации, · совместного анализа, · аудита	Усовершенствования
Эксплуатации	Обучения
Сопровождения
Решения проблем
Процесс адаптации

 

Отдельно описан процесс адаптации стандарта, содержащий основные работы, которые должны быть выполнены при адаптации настоящего стандарта к условиям конкретного программного проекта.

К числу основных относятся процессы:

· Заказа. Определяет работы заказчика, то есть организации, которая приобретает систему, программный продукт или программную услугу.

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

· Разработки. Определяет работы разработчика, то есть организации, которая проектирует и разрабатывает программный продукт.

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

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

Вспомогательными процессами являются:

· Документирования. Определяет работы по описанию информации, выдаваемой в процессе жизненного цикла.

· Управления конфигурацией. Определяет работы по управлению конфигурацией.

· Обеспечения качества. Определяет работы по объективному обеспечению того, чтобы программные продукты и процессы соответствовали требованиям, установленным для них, и реализовывались в рамках утвержденных планов. Совместные анализы, аудиторские проверки, верификация и аттестация могут использоваться в качестве методов обеспечения качества.

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

· Аттестации. Определяет работы (заказчика, поставщика или независимой стороны) по аттестации программных продуктов программного проекта.

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

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

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

Организационные процессы жизненного цикла:

· Управления. Определяет основные работы по управлению, включая управление проектом, при реализации процессов жизненного цикла.

· Создания инфраструктуры. Определяет основные работы по созданию основной структуры процесса жизненного цикла.

· Усовершенствования. Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.

· Обучения. Определяет работы по соответствующему обучению персонала.

 

 

 

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

Каскадная модель (водопад – waterfall) включает выполнение следующих фаз (рис.2.4).

Каскадная модель имеет следующие преимущества:

· проста и понятна заказчикам;

· проста и удобна в применении:

¨ процесс разработки выполняется поэтапно;

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

¨ она способствует осуществлению строгого контроля менеджмента проекта;

· каждую стадию могут выполнять независимые команды (все документировано);

· позволяет достаточно точно планировать сроки и затраты.

При использовании каскадной модели для «неподходящего» проекта могут проявляться следующие ее основные недостатки:

· попытка вернуться на одну или две фазы назад, чтобы исправить какую–либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике;

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

· запаздывание с получением результатов – если в процессе выполнения проекта требования изменились, то получится устаревший результат.

.

Это задачи типа:

· научно–вычислительного характера (пакеты и библиотеки научных программ типа расчета несущих конструкций зданий, мостов, деталей машин и т.п.);

· операционные системы и компиляторы;

· системы реального времени управления конкретными объектами.

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

Спиральная модель (по отношению к каскадной) имеет следующие очевидные преимущества:

· более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях;

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

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

· планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ;

· возможность разработки сложного проекта по частям, выделяя на первых этапах наиболее значимые требования.

Основные недостатки спиральной модели связаны с ее сложностью:

· сложность анализа и оценки рисков при выборе вариантов;

· сложность поддержания версий продукта (хранение версий, возврат к ранним версиям, комбинация версий);

· сложность оценки точки перехода на следующий цикл;

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

Спиральную модель целесообразно применять при следующих условиях:

· проект является сложным, дорогостоящим и обоснование его финансирования возможно только в процессе его выполнения;

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

· достижение успеха не гарантировано и необходима оценка рисков продолжения проекта;

· речь идет о применении новых технологий, что связано с риском их освоения и достижения ожидаемого результата;

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

Итерационная модель ЖЦ (рис.2.6) является развитием классической каскадной модели и предполагает возможность возвратов на ранее выполненные этапы.

 

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

 

V-образная модель (рис.2.7) была создана как итерационная разновидность каскадной модели. Целями итераций в этой модели является обеспечение процесса тестирования. Тестирование продукта обсуж­дается, проектируется и планируется на ранних этапах ЖЦ разработ­ки. План испытания приемки заказчиком разрабатывается на этапе планирования, а компоновочного испытания системы – на фазах анализа, разработки проекта и т.д. Этот процесс разработки планов испытания обозначен пунктирной линией между прямоугольниками V-образной модели. Помимо планов на ранних этапах разрабатываются также и тесты, которые будут выполняться при завершении параллельных этапов.

 

 

Назначение базового профиля жизненного цикла программных средств.

В Беларуси создание и испытания систем, которые включают ПС и БД, регламентированы небольшой группой ГОСТов. В области обеспечения ЖЦ и качества сложных комплексов программ существует и применяется группа стандартов ГОСТ ЕСПД, которые отстают от мирового уровня на 5–8 лет. В них создание, сопровождение и совершенствование программных средств отражены недостаточно.

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

При создании и развитии сложных распределенных тиражируемых ПС целесообразно гибкое формирование и применение гармонизированных совокупностей базовых стандартов и нормативных документов разного уровня, выделение в них требований и рекомендаций, необходимых для реализации заданных функций ПС и обеспечения их высокого качества. Для унификации и регламентирования процессов ЖЦ ПС такие совокупности стандартов должны адаптироваться и конкретизироваться применительно к определенным классам проектов, процессов и компонентов ПС. В связи с этим выделилось и сформировалось понятие профилей стандартов.

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

· профили, регламентирующие процессы ЖЦ и системы обеспечения качества проектирования, разработки, применения, сопровождения и совершенствования ПС и их компонентов;

· профили, регламентирующие объекты: архитектуру и структуру ПС и их компонентов – функции, интерфейсы и протоколы взаимодействия, форматы данных.

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

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