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

Обновлено: 19.05.2024

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

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

Особенности работы менеджера проектов

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

Однако руководить проектами достаточно сложно. Настоящий профессионал в данной области никогда не будет скучать. Project manager полностью занимается проектом: инициирует его, планирует, исполняет, контролирует и завершает.

Особенности работы менеджера проектов

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

Успешный проектный менеджер – это лидер, коллега и в то же время руководитель. Если возникнут сложности, коллектив обратится прежде всего к этому специалисту, который должен быстро принять верное решение. Занимаясь такой работой, профессионал будет всегда находиться в тонусе и никогда не потеряет интерес к своей деятельности.

Полезные материалы для
увеличения продаж с
вашего сайта!

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

Поэтому мы подготовили конкретные инструкции, внедрив которые, вы увеличите количество заявок с сайта более чем 2 раза без увеличения бюджетов на рекламу!

Основатель агентства
интернет-маркетинга TFA,
автор курса “Взлом конверсии”

5 случаев, когда цену на сайте указывать необходимо Когда и как указывать цену, чтобы не отпугнуть потенциального клиента

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

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

План создания лид-магнита с конверсией 69% Чек-лист с примерами по выбору и оформлению продающего лид-магнита

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

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

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

Стоящие перед менеджером проектов стратегические и тактические задачи

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

Стратегические задачи

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

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

Тактические задачи

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

В обязанности менеджера по управлению проектами входит:

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

ТОП-5 ПОПУЛЯРНЫХ СТАТЕЙ

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

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

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

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

Сформулировать идею проекта

Заказчик нанимает проектного менеджера, чтобы реализовать идею. На этом этапе профессионал должен провести переговоры, чтобы узнать требования заказчика и приступить к запуску проекта.

Начать работать

На этом этапе обязанности менеджера проектов следующие:

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

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

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

Реализовать проект

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

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

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

Завершить проект

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

3 группы навыков менеджера проекта

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

17 источников клиентов на маркетинг, 6 из которых бесплатные

Одной из самых популярной проблем, с которой сталкиваются начинающие специалисты в маркетинге, это как найти себе адекватных клиентов в достаточном количестве:

Этап 1. Как найти первых клиентов на свои услуги
На курсе Взлом Конверсии мы разбираем этот ключевой вопрос в первом модуле, так как каждый участник проходит обучение на собственном проекте, и более половины окупают курс до его окончания.

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

Этап 2. Клиенты есть, но они выносят мозг, и лучше было вообще не браться за проект, чем потратить море сил и энергии

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

Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.

Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.

А потом увидел статью от камрада altern, в которой он начал рассказывать про СМ. Речь у него пошла несколько в другом ключе — о конкретных инструментах и именовании конфигураций. Поэтому, списавшись с ним, чтобы не пересекаться по тематике наших статей, решил написать об основах того, что называется управлением конфигурацией программных средств.

Сейчас у меня уже написан материал примерно на 50 тысяч знаков — это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.

Задача — дать обзор того, чем же вообще является CM, какие задачи он решает и какие техники при этом используются. Речь не будет идти о конкретных системах контроля версий или вообще инструментах — этого добра навалом в сети. Задача — показать универсальные для всех инструментов основы.

Что такое CM и зачем он нужен

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

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

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

Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия CM.

Схема 1. Элементы, их версии и срезы-конфигурации.

CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.

Так в чем же заключается такая ценность CM?

Направления ответственности CM

Управление конфигурацией работает на всех этапах жизненного цикла проекта. Появился рабочий продукт (например, файл с исходниками) – он попадает в поле деятельности CM’а. Продукт начал изменяться (мы пишем функциональность) – значит CM должен предоставить средства для контроля над изменениями и автоматически провести сам контроль, где это требуется. Потребовалось разбить работу на команду разработчиков, а то и на несколько – проектный CM предоставляет правила и инструменты для работы. Есть, что предложить заказчику – тогда CM определяет правила стабилизации продуктов разработки и их выпуска. Надо откатиться на произвольный релиз – опять в работе CM. Понадобились метрики по изменениям или документированные политики – ну, вы поняли, к кому обратиться.

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

Продукты выделили, дальше команда начинает работу. По ходу работы нужно периодически стабилизировать полученные результаты, подводить некоторую черту под наработками, а также определять тот базис, на основе которого будет идти разработка. Это всё также входит в сферу деятельности CM’а.

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

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

Итак, каковы задачи управления конфигурацией?

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

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

Для введения в этот раздел, относительно редко выносимый на отдельное рассмотрение, дадим определение ключевым терминам.

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

Элемент конфигурации - результат проекта или компонент результата, контролируемый в рамках процесса управления конфигурацией.

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

В должностные обязанности менеджера по управлению конфигурацией обязательно входит:

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

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

Работы по идентификации конфигураций

определяют контролируемые элементы,

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

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

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

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

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

Процедура создания нового элемента конфигурации

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

Основные понятия управления рисками

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

Риски подразделяются на известные и неизвестные.

Известные риски идентифицируются и подлежат управлению - создаются планы реагирования на риски и резервы на возможные потери.

Неизвестные риски нельзя определить, и, следовательно, невозможно спланировать действия по реагированию на такой риск.

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

Вероятность возникновения риска - вероятность того, что событие риска наступит. Все риски имеют вероятность больше нуля и меньше 100%. Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 100% также не является риском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта.

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

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

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

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

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

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

Роли и обязанности - раздел содержит описание, кто какую работу выполняет в ходе управления рисками проекта.

Бюджетирование - определяет бюджет для управления рисками проекта.

Временные рамки - устанавливают частоту процессов управления рисками.

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

Контроль - раздел, определяющий формат плана реагирования на риски.

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

Примером методологии является дисциплина управления рисками MSF (Microsoft Solutions Framework). MSF описывает процесс непрерывного выявления и оценки рисков, их приоритизации и реализации стратегий по превентивному управлению рисками на протяжении всех фаз жизненного цикла проекта.

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

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

На этапе планирования в соответствии с принятой политикой и процедурами в процессе управления рисками организация должна осуществлять следующие действия:

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

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

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

Задача процесса управления конфигурациями — предотвратить неконтролируемое развитие проекта. Для регламентации процесса управления конфигурациями в различных отраслях принят ряд международных и национальных стандартов.

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

При разработке программных систем создается множество взаимосвязанных объектов: требований, исходных текстов, объектных файлов, описаний тестов и т. п. — согласованные совокупности которых принято называть конфигурациями, а процесс поддержки их изменений и целостности в течение жизненного цикла проекта — управлением конфигурациями. Основная цель введения в проект процесса управления конфигурациями — предотвратить неконтролируемое развитие проекта и дать гарантии того, что все вносимые изменения будут учитываться и санкционироваться. Управление конфигурациями включает в себя процедуры по идентификации элементов проекта, по управлению изменениями и поддержке трассируемости объектов, а также деятельность по поддержке аудитов состояния и контролю статуса конфигурации.

Объект конфигурации (Configuration Item, CI): исходные тексты, скомпилированные программы, исходные коды программ, документация, элементы аппаратуры, процедуры и материалы обучения и т.п. — базовое понятие процесса управления конфигурациями Однако обычно под управление конфигурациями попадают только результаты проектной деятельности: программное обеспечение и сопутствующая документация, требования к интерфейсам и документация, выходные файлы, полученные при использовании инструментов проекта, технико-экономические документы и записи пользовательских требований, планы управления проектом, инструменты и руководства пользователя, записи об истории проекта, тест-планы, процедуры и отдельные тестовые примеры.

При объединении объектов конфигурации образуется их конфигурация — любая структурированная совокупность объектов разработки программной системы, представленных в виде CI, или совокупность процессов и технологических цепочек проекта по разработке программной системы, описания которых также могут быть представлены в виде CI. Процесс управления конфигурациями в различных отраслях регламентируется международными и национальными стандартами: ГОСТ Р 51904, DO-178, AS9100, AS9006, ISO10007, ISO/IEC TR 15846, ISO/IEC 15408, IEEE 1042 и пр. При разработке высококритичных систем применение процесса управления конфигурациями строго обязательно — цена исправления дефектов в таких системах может быть очень высока.

Стандарт ГОСТ Р 51904 был принят Госстандартом России в 2002 году и регламентирует требования к разработке и документированию встроенных систем. В нем процесс управления конфигурациями отнесен к группе интегральных процессов, необходимых для обеспечения качества выполнения процессов разработки и их выходных данных. Интегральные процессы выполняются одновременно с процессами разработки и обеспечивают непрерывную поддержку разработки. Основные цели процесса управления конфигурациями согласно ГОСТ 51904 состоят в том, чтобы обеспечить:

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

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

Кроме этого, имеются еще подпроцессы ведения отчетности о состоянии конфигурации, необходимые

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

Практически все процессы управления конфигурациями, определенные стандартом ГОСТ Р 51904, требуют отслеживания состояний жизненного цикла объектов, помещенных в конфигурацию. Так, контроль конфигурации подразумевает, что режим доступа к CI может изменяться в зависимости от их состояния. Создание базовых линий происходит только по достижении всех входящих в нее CI определенного состояния. Управление отчетностью о дефектах производится на основании информации о том, в каком состоянии находится отчет о дефекте и сам дефект, устранен ли он. Отчет о состоянии конфигурации в обязательном порядке включает в себя информацию о состояниях CI. Архивирование конфигураций также может изменять их состояние. Процесс контроля загрузки ПО автоматизируется при помощи создания базовой линии из CI, достигших определенного состояния. Контроль среды жизненного цикла производится на основании информации о том, в каком состоянии находятся инструменты проекта, не требуется ли их обновление.

По своей сути ГОСТ Р 51904, область применения которого — любые встроенные системы, базируется на международном стандарте DO-178, используемом при разработке авиационных систем. Системы, разработанные в соответствии с этим стандартом, могут быть сертифицированы согласно требованиям летной годности.

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

С точки зрения стандарта ISO 10007 управление конфигурациями — это управленческая дисциплина, применяемая на протяжении всего жизненного цикла изделия для обеспечения наглядности функциональных и физических характеристик и управления ими. Данная деятельность является способом удовлетворения определенных требований, содержащихся в других международных стандартах серии ИСО 9000. Согласно данному стандарту, процесс управления конфигурациями включает в себя следующие виды деятельности: идентификацию конфигураций, контроль конфигураций, представление отчетности о статусе конфигураций, проверку конфигураций. Охват данного стандарта шире, чем у предыдущих двух, — это не только разработка программного обеспечения, но и все результаты деятельности компании, управление которыми может вестись в соответствии с принципами управления конфигурациями.

Существуют также стандарты AS 9100/AS9006, специально адаптирующие требования системы менеджмента качества ISO к авиационной отрасли.

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

Читайте также: