Билет №13

1. Управление конфигурацией в стандартах СММ и ISO/IES 12207.

Российский стандарт ГОСТ РИСО/МЭК 12 207 рассматривает процессы ЖЦ ПС и подразделяет их на 3 группы: 1) основные, 2) вспомогательные и 3) организационные.

Стандарт ГОСТ РИСО/МЭК 12 207 устанавливает общую структуру ЖЦ ПК, определяет процессы, работы и з-чи, выполнимые в ходе ЖЦ ПС. Данный процесс состоит из следующих работ:

1) подготовка процесса(должен быть разработан план управления конфигурации. План должен определять:

1) план;

2) процедуры и график выполнения данных работ;

3) организацию, ответственную за выполнение данных работ;

4) связь данной организации с др. организациями, напр., по разработке и сопровождению ПС.

План должен быть документально оформлен и выполнен. Примечание: данный план должен быть частью плана конфигурации системы);

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

– док-ция, в которой фиксируется состояние её конфигурации;

– эталонные версии и др. элементы обозначения);

3) контроль конфигурации(анализ и оценка изменений; принятие или неприятие заявки; реализация, верификация и выпуск программного объекта.

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

Должны быть выполнены контроль и аудиторская проверка всех доступных контролю программных объектов, которые связаны с критическими фун-ми, безопасность или защиты);

4) учёт состояний конфигурации (должны быть подготовлены протоколы управления, отчёты о состоянии, которые отражают состояние и хронологию изменения контролируемых программных объектов, включая состояния их конфигурации. Отчёты о состоянии должны включать кол-ва изменений в данном проекте, в последней версии программных объектов, обозначения выпущенных версий, кол-во выпусков и сравнение прог-ных объектов различных выпусков);

5) оценка конфигурации(должны быть определены и обеспечены:

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

– физ-ая завершённость прог-ных объектов с точки зрения реализации в проекте и прог-ах, всех внесённых изменений);

6) управление выпуском и подстановк (должны официально контролироваться выпуск и поставка прог-ных продуктов вместе с соот-щей док-цией. Оригиналы программ и док-ции должны сопровождаться а ЖЦ.

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

Управление конфигурацией с точки зрения Capability Matyrity Model CMM – модель зрелости процесса создания ПО или эволюционную модель развития способности компании разрабатывать качественное ПО).

2. Порядок разработки программного модуля (ПМ).

При разработке ПМ целесообразно придерживаться след. порядка:

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

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

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

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

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

6) компиляция модуля(обозначает завершение проверки модуля с помощью компилятора и переход к процессу отладки модуля)