Липаев В.В. Сертификация программных средств. Учебник

Подождите немного. Документ загружается.

Лекция 3. Базовые стандарты сертификации...

ноя система обеспечения жизненного цикла проекта. Такая ин-

формационная система представляет собой комплекс формальных и

неформальных каналов обмена информацией между участниками

проекта, ее накопления и обработки. Степень формализации может

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

технических заданий до личных бесед между специалистами. Таким

образом, целевое управление проектами позволяет планировать, кон-

тролировать и анализировать информацию о состоянии и тенденциях

изменения объекта разработки, его качестве и затраченных ресурсах.

При этом должны сохраняться основные стратегические цели про-

екта и главные процессы их достижения. Это позволяет рассмат-

ривать альтернативы технических решений и предотвращает от со-

средоточения внимания на частных задачах или вариантах решений,

которые кажутся полезными и интересными, но мало отражаются на

достижении главной цели.

Основная цель системного проектирования - подготовить,

обосновать и согласовать замыслы и решения заказчика (потребите-

ля) и разработчика (поставщика) о необходимости, направлениях и

концепции создания или модернизации существующего ПС и изме-

нениях его качества на базе современных стандартов. Методы и

средства системного проектирования должны подготавливать эффек-

тивную технологическую базу для обеспечения всего жизненного

цикла ПС требуемого качества. Характеристики качества комплексов

программ должны анализироваться и формулироваться в начале их

жизненного цикла и определять эффективность всех последующих

процессов. Результатом этих работ должны быть системный проект,

техническое задание и контракт на продолжение проектирования или

решение о его нецелесообразности

и/или

прекращении. В системном

проекте должны быть обобщены и отражены следующие основные

результаты выполненных исследований и разработок:

• обобщенный анализ проведенного обследования объекта

информатизации, функций существующей системы, качества ее ос-

новных программных компонентов и базы данных;

• совокупность предварительных исходных требований к

функциям и характеристикам качества создаваемого комплекса

программ;

• оценки имеющихся и потенциально доступных ресурсов

(финансовых, вычислительных средств, специалистов) для обеспе-

В.В.

Липаев.

Сертификация программных средств

чения всего жизненного цикла и требуемого качества проекта ком-

плекса программ;

• результаты предварительного анализа архитектуры ком-

плекса программ на основе моделей и прототипов аналогичных

систем, позволяющие наметить планы разработки и всего жизнен-

ного цикла проекта ПС;

• цели, задачи и функции предполагаемой новой или модер-

низированной системы, обобщенные в

концепции

создания соот-

ветствующего программного средства;

• проекты планов жизненного цикла, гарантирования требуе-

мого качества ПС, защиты и обеспечения безопасности его функ-

ционирования;

• результаты технико-экономического обоснования целесооб-

разности и основных направлений продолжения проектирования и

всего ЖЦ ПС;

• предварительный план организации работ, требования к со-

ставу и квалификации специалистов для выполнения проекта и всего

жизненного цикла ПС;

• проект формализованного

технического задания

специфи-

кации требований

ПС,

а также предложения по его финансирова-

нию

обеспечению ресурсами;

•

системный

проект,

обобщающий проведенные исследова-

ния и разработки, позволяющий заключить контракт между разра-

ботчиком и заказчиком на финансирование и продолжение проек-

тирования и/или на весь жизненный цикл ПС.

Разработка

исходных требований

для

технического

зада-

ния на проект

программного средства

начинается с анализа ре-

зультатов обследования объекта информатизации и оценки доступ-

ных ресурсов для реализации проекта. Эта деятельность требует

специальной организации специалистов наивысшей квалификации

и тесной совместной работы представителей заказчика и разработ-

чика. Наличие обычно ряда неформализованных, неструктуриро-

ванных и противоречивых содержательных требований заказчика и

разработчика требует их совместной обработки, согласования и

корректировки.

Предварительный

анализ и

моделирование процессов

обра-

ботки данных при проектировании должны проходить этапы от

простого установления базовых отношений между понятиями, че-

Лекция 3. Базовые стандарты сертификации... 73

рез определение интерфейсов доступа и атрибутов, к проекту моде-

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

процессами ПС. Итеративный характер построения формализованно-

го описания проекта системы предопределен изначально не только

потому, что не удается сразу получить непротиворечивое и полное

описание из-за неясностей в исходном описании, но и потому, что

сложную систему можно описывать только, начиная с основной части

ее предметной области, которая затем постепенно расширяется и де-

тализируется. Схемы потоков данных, потоков управления, сущ-

ность-связь и другие составляют комплекс удобных и гибких гра-

фических методов и средств описания систем, облегчающих взаи-

мопонимание между разработчиками и заказчиками на разных

уровнях детализации функций, качества и архитектуры ЖЦ ПС.

Одним из наиболее эффективных направлений сокращения

затрат и повышения качества комплексов программ является актив-

ное использование методического, технологического, алгоритмиче-

ского и программного задела из предшествующих проектов, кото-

рое может быть названо прототипированием в широком смысле

слова [12]. Математические модели и прототипы различных компо-

нентов и функций систем и ПС обеспечивают возможность приме-

нять готовые апробированные решения, а также выделять и иссле-

довать принципиально новые методы и процессы для реализации их

в ПС. Прототипирование позволяет наглядно представить заказчику

и пользователю функции будущей системы, виды и динамику при-

менения экранов, меню, отчетов и форм запросов, а также откор-

ректировать их для развития ПС на всех этапах жизненного цикла.

Для этого следует анализировать и выбирать прототипы комплек-

сов программ, характеристики которых наиболее близки к созда-

ваемой версии ПС и которые позволили бы получить в результате

объекты с необходимыми характеристиками качества.

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

и ПС должно содержать долгосрочные цели развития комплекса

программ определенного функционального назначения. Планы

должны отражать предварительные проекты всего будущего жиз-

ненного цикла ПС, обеспечения их качества, защиты и безопасно-

сти функционирования, верификации и тестирования, управления

конфигурацией и сопровождения. По этим данным руководителем

разработки и заказчиком принимается решение о целесообразности

В.В.

Липаев.

Сертификация программных средств

продолжения проектирования и осуществляется стратегическое пла-

нирование ЖЦ проекта, которое формализуется в проекте и в техни-

ческом задании на ПС. В процессе проектирования последовательно

уточняются характеристики объекта и среды разработки, вследствие

чего появляется возможность более полно и точно

спланировать

обосновать весь последующий жизненный цикл

ПС.

Такое постепенное повышение достоверности прогнозов жиз-

ненного цикла приводит к целесообразности оценки достигаемых

значений качества по этапам и к возможности разработки укруп-

ненного, поэтапного плана выполнения всего комплекса работ. Ес-

ли необходимые требования к функциям и качеству ПС не могут

быть удовлетворены при доступных ресурсах, технологиях и спе-

циалистах, то возможны решения по прекращению дальнейшей

разработки проекта. Таким образом, производится технико-

экономическое обоснование проекта, определяются приближен-

ные значения трудоемкости и длительности всей разработки ПС, а

также число необходимых специалистов, что позволяет оценить

предварительный укрупненный план создания и всего ЖЦ ПС в за-

данных условиях, ресурсах и сроках.

Вследствие творческого характера большинства работ на этом

этапе невозможно составить жесткий план их выполнения. Помочь

может типовой перечень частных работ, представленный в стан-

дартах

ЖЦ ПС и ориентировочный график, иллюстрирующий их

взаимосвязь. При этом следует подготовить

требования

к доку-

ментации

обеспечить их

реализацию,

которая должна быть од-

нозначной - написана в стандартизированных терминах, которые

допускают только единственную интерпретацию, уточняемую, если

необходимо, соответствующими комментариями [15]. Если заказ-

чик удовлетворен результатами проектирования, то возможно

оформление акта

завершения работ и утверждение системного

проекта комплекса программ с требуемыми характеристиками ка-

чества для новой или модернизированной системы, а также кон-

тракта (договора) на детальное

проектирование

или на весь

жизненный цикл

ПС.

Лекция 3. Базовые стандарты сертификации,..

Процессы управления проектами программных средств

на основе модели - CMMI

Достижение высоких значений качества программ существенно

зависит от качества - зрелости технологии и инструментальных

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

цикла ПС [16]. Уровень зрелости автоматизации, качество техноло-

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

ПС,

обычно сильно коррелирован с достигаемым качеством комплек-

сов программ, а также с качеством средств автоматизации для их

оценивания. Оценивание зрелости технологической базы ЖЦ позво-

ляет прогнозировать возможное качество ПС и ориентировать заказ-

чика и пользователей при выборе разработчика и поставщика для оп-

ределенного проекта с требуемыми характеристиками. Поэтому оп-

ределение уровня зрелости технологической поддержки процессов

жизненного цикла, организационного и инструментального обеспе-

чения ПС, непосредственно связано с оцениванием реальных или

возможных характеристик качества конкретного комплекса про-

грамм. Значительные достижения в организации, планировании, раз-

витии и применении современных методов и технологии обеспечения

проектов программных средств сосредоточены в методологии и

стандарте де-факто Capability Maturity Model Integration (CMMI) for

Systems Engineering/Software Engineering/Integrated Product and

Process Development - Интегрированная модель оценивания зрелости

для инженерии систем/инженерии программных средств/интегриро-

ванных продуктов и процессов разработки.

Эту комплексную модель CMMI, уточняющую и совершенст-

вующую предшествовавшие модели СММ, а также учитывающую

основные требования существующих международных стандар-

тов в области менеджмента программных средств американский ин-

ститут программной инженерии (SEI) опубликовал в 2003 году.

Внедрение этой модели акцентировано на улучшении процессов

управления проектами ПС, обеспечении их высокого качества и кон-

курентоспособности, с основной целью - сделать процессы проектов

более управляемыми, а результаты - предсказуемыми.

Назначение методологии CMMI - состоит в предоставлении

необходимых общих рекомендаций и инструкций предприятиям и

специалистам, производящим программные продукты, по выбору

В.В.

Липаев.

Сертификация программных

средств

стратегии совершенствования качества, процессов и продуктов путем

анализа степени их производственной зрелости и оценивания факто-

ров,

в наибольшей степени влияющих на качество ЖЦ ПС, а также

посредством выделения процессов, требующих модернизации. Для

достижения устойчивых результатов в процессе развития технологии

и организации управления жизненным циклом ПС рекомендуется ис-

пользовать эволюционный путь, который позволяет совершенство-

вать и постепенно повышать качество процессов и продуктов, вскры-

вать преимущества и недостатки предприятия. Уровни зрелости ха-

рактеризуются степенью формализации, адекватностью измерения

и документирования процессов и продуктов ЖЦ ПС, широтой при-

менения стандартов и инструментальных средств автоматизации ра-

бот, наличием и полнотой реализации функций системой обеспечения

качества технологических процессов и их результатов.

Два варианта модели CMMI созданы для возможности непре-

рывного оценивания процессов в определенной области создания ПС

и/или для поэтапного оценивания и совершенствования зрелости

предприятия, а также организации его производства комплексов про-

грамм в целом. Модели CMMI представляют помощь проектировщи-

кам при организации и совершенствовании их продуктов, по обслу-

живанию процессов разработки и сопровождения ПС. Компоненты

непрерывной и поэтапной моделей в значительной степени подобны

и могут выбираться и применяться в разном составе и последователь-

ности использования в зависимости от свойств и характеристик про-

ектов. Варианты моделей построены по единой схеме, которая со-

держит основные разделы:

4-й раздел - содержание уровней и главные компоненты каждо-

го варианта модели (разработка целей и процедур);

5-й раздел - структура процедур - четыре категории CMMI

процессов:

• менеджмент процессов;

• управление проектом;

• инженерия- технология;

• поддержка - сопровождение.

6-й раздел - использование CMMI моделей.

Последний, седьмой раздел самый большой в каждом варианте

стандарта и занимает около 500 страниц из полного объема докумен-

та до 700 страниц. В этом разделе представлены подробныерекомен-

Лекция 3. Базовые стандарты сертификации... 77

дации для реализации каждого из перечисленных выше четырех про-

цессов, которые учитывают особенности конкретных моделей.

Первый вариант непрерывной модели отражает документ:

CMMI-SE/SW/IPPD, Vl.l, Continuous - Интегрированная модель

оценивания зрелости для инженерии продуктов и процессов разра-

ботки -непрерывное представление. В этой модели седьмой раздел

содержит детализацию процессов 5-го раздела - рис. 3.2.

Второй вариант представляет документ: CMMI-SE/SW/ IPPD,

VI.1,

Staged - Интегрированная модель оценивания зрелости для ин-

женерии продуктов и процессов разработки - поэтапное представ-

ление. Модель базируется на концепции пяти уровней зрелости -

рис.3.3.

Уровень 1 - Начальный. Массовые разработки проектов ПС

характеризуются относительно небольшими объемами программ в

несколько тысяч строк, создаваемых несколькими специалистами.

Они применяют простейшие не формализованные технологии с ис-

пользованием типовых инструментальных компонентов операцион-

ных систем. Основные процессы ЖЦ ПС на этом уровне не регламен-

тированы, выполняются не совсем упорядоченно и зависят от не ко-

ординированных индивидуальных усилий и свойств отдельных спе-

циалистов. Успех проекта, как правило, зависит от энергичности, та-

ланта и опыта нескольких руководителей и исполнителей. Процессы

на первом уровне характеризуются своей непредсказуемостью по

трудоемкости и срокам

связи с тем, что их состав, назначение и по-

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

зависимости от текущей ситуации.

Уровень 2 - Управляемый - базовое управление. Для сложных

проектов ПС объемом

десятки и сотни тысяч строк, в которых уча-

ствуют десятки специалистов разной квалификации, необходимы ор-

ганизация, регламентирование технологии и унификация процессов

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

нируются, их выполнение контролируется, чем достигается предска-

зуемость результатов и времени выполнения этапов, компонентов и

проекта в целом. Основной особенностью второго уровня является

наличие формализованных и документированных процессов управ-

ления проектами, которые пригодны для модернизации, а их резуль-

таты,

поддаются количественной оценке.

В. В.

Липаев. Сертификация программных средств

Первый вариант непрерывной модели

CMMI

Менедлсмепт процессов:

- содержание (усовершенствование)

организационных процессов;

- определение организационных процессов;

- обучение организации;

- организация процессов изменений;

- организация инноваций и расширений.

Управление проектом:

- планирование проекта;

- мониторинг и контроль процессов проекта:

- управление поставщиками;

- интегрированное управление процессами и

продуктами проекта;

- управление рисками;

- интеграция команды разработчиков;

- количественное управление проектом.

Инженерия - технология:

- управление требованиями;

- разработка требований;

- технические решения;

- интеграция продукта;

- верификация;

- валидация - аттестация.

Поддержка - сопровождение:

- управление конфигурацией;

- обеспечение качества процессов и продуктов;

- измерение п анализ;

- анализ и принятие решений на изменения;

- организация окружения для интеграции;

- анализ причин и разрешение проблем -

устранение дефектов.

Рис. 3.2

Лекция

Базовые стандарты

сертификации...

Второй вариант

поэтапная модель

CM Ml

Уровень

- Оптимизационный -

непрерывное улучшение процессов:

управление изменением и качен

ном

процессов

продукт:

инновации, количественное управление

процессами и обеспечением ресурсами:

совершенствование качества и управления

процессами и продуктами:

непрерывное измерение и улучшение

качесгва

ПРОДУКТОВ

процессов.

Уровень 4 - Предсказуемый -

КОЛИЧСС1

венное

управление процессами:

измерение характеристик комноненюн.

продукта

процессов:

количественное управление процессами,

за

фатами

и характсриешками качесгва;

распределение,

кош

роль

и обеспечение

процессов ресурсами:

количественный контроль и управление

рисками процессов, ресурсов и качесгва:

контроль и управление поставкой

ПРОДУКТОВ.

Уровень 3 - Определенный

стандартизации процессов:

разрабопса требовании;

технические решения:

•• ни

1еграцпя

продукта;

•

верификации:

валидация -аттестация:

сосредоточение на организации процессов;

обеспечение

тандар!HOI

процесса,

организация обучения;

итерированное управление процессами и

продуктами проекта;

управление рисками;

аи;иип и разрешение проб нем •-

>с

гранение

дефекюв

Уровень

- Управляемый - базовое

iправление

процессами:

управление iребованиями;

планирование проекта;

монишрннг

контроль проекта;

управление поставщиками:

ишерепие и анализ;

обеспечение качесша процессов и

продуктов:

управление конфигурацией.

Уровень

- Начальный:

приближенная опенка процессов,

рашера paooi, ресурсов и результатов.

Рис.3.3

В. В.

Липаев. Сертификация программных средств

На этом уровне акценты управления сосредоточиваются на

предварительном упорядочении и регламентировании процессов соз-

дания, сопровождения и оценивания качества программного средства,

однако для крупномасштабных проектов ПС с гарантированным ка-

чеством, риск провала может оставаться еще достаточно большим.

Уровень 3 - Определенный - стандартизация процессов. При

высоких требованиях заказчика

пользователей к конкретным харак-

теристикам качества сложного ПС и к выполнению ограничений по

использованию ресурсов, необходимо дальнейшее совершенствова-

ние и повышение уровня зрелости процессов ЖЦ ПС. Процессы ЖЦ

ПС на этом уровне должны быть стандартизированы, и представлять

собой единую технологическую систему, обязательную для всех под-

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

качества ЖЦ ПС, для каждого проекта могут разрабатываться допол-

нительные процессы последовательного оценивания качества про-

дуктов с учетом их особенностей. Описание каждого процесса долж-

но включать условия его выполнения, входные данные, рекоменда-

ции стандартов и процедуры выполнения, механизмы проверки каче-

ства результатов, выходные данные, условия и документы заверше-

ния процессов. В описания процессов включаются сведения об инст-

рументальных средствах, необходимых для их выполнения, роль, от-

ветственность и квалификация специалистов.

Уровень 4 -Предсказуемый - количественное управление. Для

реализации проектов крупномасштабных, особенно сложных ПС в

жестко ограниченные сроки и с высоким гарантированным качест-

вом,

необходимы активные меры для предотвращения и выявления

дефектов и ошибок на всех этапах ЖЦ ПС. Управление должно обес-

печивать выполнение процессов в соответствии с текущими требова-

ниями к характеристикам качества компонентов и ПС в целом. На

этом уровне, должна применяться система детального поэтапного

оценивания характеристик качества, как технологических процессов

ЖЦ,

так и самого создаваемого программного продукта и его компо-

нентов. Должны разрабатываться и применяться методики количест-

венной оценки реализации процессов и их качества. Одновременно с

повышением сложности и требований к качеству ПС следует совер-

шенствовать управление проектами за счет сокращения текущих кор-

ректировок и исправлений дефектов при выполнении процессов. Ре-

зультаты процессов становятся предсказуемыми по срокам и качеству