Материал: DO178 Учебное пособие_в183

10. Конфигурационное управление

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

Конфигурационное управление, как правило, состоит в установлении правил именования составляющих компонентов программного проекта с поддержанием их версионного контроля (version control), и в обеспечении их быстрого восстановления в случае утраты путем регулярного резервного копирования. В проекте определяется перечень его рабочих продуктов и компонентов, подпадающих под управление конфигурацией, который включает не только программные модули создаваемого продукта, но и все инструментальные средства и платформы, на которых эти компоненты создаются, а также все тесты и тестовые процедуры для их верификации и валидации.

Рис. 19. Укрупненная структура системы конфигурационного управления

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

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

Второй составляющей системы конфигурационного управления является какое-либо инструментальное средство автоматизации управления версионным контролем и базой данных компонентов программного продукта, например CVS (Control Version System) или ClearCase.

Одной из важных составляющих системы конфигурационного управления является совет по управлению конфигурацией (Configuration Management Board), который обычно состоит из представителя администрации и по одному представителю всех проектов. В обязанности совета входит оценивание подготовленных предложений по изменению конфигурации и принятие решения об их утверждении или отклонении. Совет также определяет и утверждает базовые версии программного продукта для каждого проекта. В обоих случаях по результатам заседания составляется отчет о состоянии конфигурации продукта на дату заседания совета.

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

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

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

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

11. Метрики

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

Все эти метрики, как правило, должны обладать следующими свойствами:

• простота для понимания и точная определенность – для упрощения их вычисления и анализа;

• дешевизна – для минимизации связанных с ними расходов на их сбор, анализ и дальнейшее применение;

• устойчивость – чтобы изменения в их значениях в ходе проекта имели осмысленную интерпретацию;

• согласованность между собой и с длительной историей использования – чтобы максимизировать свою ценность для исполнителей и заказчика;

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

В программном проекте различают три типа метрик:

метрики самого процесса разработки (Process Metrics) – для улучшения разработки и сопровождения, такие как:

• эффективность сдерживания дефектов (Defect Containment Effectiveness) в процентах числа дефектов, выявленных до сдачи продукта, от общего числа дефектов (выявленных до сдачи плюс выявленных уже после сдачи);

• себестоимость программной разработки (Cost of Software Development) в суммарных затратах на одного участника разработки в денежном выражении в месяц, включая оборудование и накладные расходы;

• производительность труда (Productivity) в KAELOC на 1 человеко-месяц;

метрики разрабатываемого продукта (Product Metrics) – для улучшения его качества, такие как:

• размер исходного кода (Source Code Size) в KLOC или KAELOC;

• сложность программного кода (Code Complexity) в единицах, определяемых выбранной моделью оценки сложности;

• объем разработанной документации (Documentation Size) в числе страниц или строк текста;

• стоимость разработки (Development Cost) в денежном выражении на KLOC или KAELOC продукта;

• пост-релизные дефекты (Post-Release Defects) в количестве дефектов, выявленных уже после сдачи продукта, как на стороне заказчика, так и исполнителя в течение определенного срока (обычно 1 год или 6 месяцев), на 1 KLOC или KAELOC;

метрики данного проекта (Project Metrics) – для его улучшения, такие как:

• количество разработчиков и тестировщиков (Staffing) в количестве ставок и фактическом количестве людей при использовании неполных ставок;

• количество различных методов и инструментов, используемых в разработке (Methods and Tools), включая лицензии на ПО;

• уже понесенные трудозатраты (Effort) в человеко-днях или человеко-месяцах;

• суммарная текущая стоимость проекта (Project Cost) в денежном выражении;

• достигнутый процент прохождения тестов из запланированного тестового набора (Tests Passed);

• достигнутый процент покрытия тестами (Test Coverage) требований из спецификации и(или) кода по различным критериям покрытия;

• обнаруженная плотность ошибок/дефектов (Defect Density) в количестве обнаруженных дефектов (ошибок) на 1 KLOC или 1 KAELOC продукта;

• достигнутое качество кода (Product Quality) в оценке количества еще не выявленных дефектов плюс число уже известных, но еще не устраненных дефектов, на 1 KLOC или 1 KAELOC продукта;

• достигнутая степень завершенности проекта (Project Completion) в процентах по объему готового кода или по количеству готовых модулей;

• точность следования графику (Schedule Accuracy) в процентах отклонений фактических дат запланированных событий проекта от плановых дат;

• точность поставок (On Time Delivery) в проценте поставок, сделанных точно в срок, от всех совершенный поставок в данном проекте;

• затраты на обеспечение качества (Cost of Quality) в процентах от всех трудозатрат в данном проекте;

• затраты на переделки (Cost of Poor Quality) в процентах от всех трудозатрат в данном проекте; включают в себя затраты на поиск найденных ошибок, их исправление и повторение разработки до верификации сделанных исправлений включительно; входят как часть в затраты на обеспечение качества;

• текущая удовлетворенность заказчика ходом проекта (Customer Satisfaction) в баллах (обычно от 1 – самая низкая до 10 – самая высокая).

Для сравнения вот значения некоторых метрик, взятые из [8]:

Табл. 13. Эталонные данные по промышленности США

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

12. Повышение квалификации

Обычно в организации-разработчике имеется выделенное лицо – координатор программы повышения квалификации (training program coordinator), которое несет ответственность за планирование и координацию технического обучения, и повышение квалификации всех сотрудников во всех проектных группах. Этот координатор обычно готовит и проводит большинство курсов обучения для сотрудников, используя как внутренние ресурсы организации, так и привлекая внешние источники, в рамках единой для организации программы технического обучения. Эта программа, как правило, составляется на несколько лет вперед и регулярно обновляется.

Цель деятельностей по повышению квалификации заключается в создании условий для развития навыков и знаний у исполнителей проектов для более эффективного выполнения ими поставленных задач. Непрерывное плановое повышение квалификации является важным элементом организационной дисциплины и состоит в планомерном развитии навыков и знаний конкретных лиц, чтобы они могли исполнять свои роли в проектах действенно и разумно (effectively and efficiently).

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

13. Задания для самопроверки

Создайте положение о работе для известного Вам проекта.

Сделайте предварительную оценку трудоемкости Вашего проекта на основе модели COCOMO, сравните эти оценки с реальными данными и объясните расхождения.

Определите структуру разбиения работ для этого проекта и обоснуйте ее.

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

1. пользовательский интерфейс должен быть дружественным;

2. система должна быть высоко функциональной;

3. радиосвязь должна отвечать спецификациям ST152D и ST204D;

4. тестовое оборудование должно быть совместимо по шине;

5. устройство должно быть совместимо с RS232;

6. должен применяться короткий производственный цикл;

7. каждый экран должен отображать номер и дату заказа;

8. Установка должна завершаться за 45 минут;

9. плотность дефектов должна быть меньше 5,7 сигма;

10. соединение должно быть через болт диаметром 6 типа А;

11. надпись «M&M» должна быть красного цвета №2;

12. дата должна быть в стандартном формате.

Возьмите какой-либо реальный проект и 20-30 требований из него, найдите в тексте этих требований все места неоднозначности и перепишите эти места так, чтобы найденные неоднозначности устранить. В качестве альтернативы можно взять следующий набор из 21 формулировки:

The network management system must provide the following capabilities:

1. Management applications to monitor, diagnose, and correct network faults. Real-time monitoring of network nodes requires standard topology and fault management functions, and a state-of-the-art user interface design to support those applications for very large networks.

2. Network data whether dynamic (e.g., events, status) or relatively static (e.g., configuration), must be stored in a flexible data base at the management system. This information must be employed by all management applications in an intelligent fashion, and must be available to standard PC, workstation, and/or mainframe reporting system.

3. As much integration of data bases and applications as possible should be provided, but not at the expense of time to market. At a minimum, a window between the systems must be provided, and data bases which are not consolidated should be compatible; i.e., share a common format or the ability to export to a common format.

4. The system will be based on a new management hardware and software platform. As such, it must be designed to support any network devices that will be integrated beyond the system’s nodes.

5. The system will be the only tool with the ability to test, check status, reconfigure, and gather statistics on the networks in real time. Therefore, these management applications are a critical element of the system.

6. The system must be able to accept inventory, configuration, and performance data from other systems since these systems are targeted to provide the nodal and network optimization functions. In addition, the system must be able to provide this information to these same systems to re-optimize the network or validate hypotheses.