Home

Автор: Новичков Александр

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

Основные вопросы:

• Действительно ли надо проходить сертификацию?
• Что даст сертификация?
• Какие средства инструментальной поддержки выбрать?
• Можем ли мы сами достичь уровня 3?

Введение

По роду деятельности нам приходится отвечать на вопросы своих клиентов о востребованности СММI для них. Нам очень приятно, что в последнее время резко возрос интерес в России к стандартам качества, к процессам и методологиям. Уже никому (почти никому) не нужно доказывать, что для получения качественной продукции в компании должны быть качественные процессы. Нам приятно, что многие важные процессы разработки ПО (конфигурационного управления и тестирования), необходимость которых приходилось ранее доказывать, сейчас активно начинают внедряться во многих компаниях.

В последнее время также возрос интерес к модели зрелости процессов создания ПО. Причина ясна — отечественные компании перестали вариться в собственном соку и выходят на запад. Здесь и нужны показатели качественности собственных процессов

В данной статье мы попытаемся рассмотреть некоторые стандартные вопросы, связанные с СММI. Статья в дальнейшем будет расширяться и дополняться. Следите за анонсами.

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

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

Давайте ответим на риторический вопрос: зачем нашей компании СММI?

Несмотря на кажущуюся простоту, вопрос скрывает в себе массу проблем:
1) Действительно ли надо проходить сертификацию?
2) Что даст сертификация?
3) Какие средства инструментальной поддержки выбрать?
4) Можем ли мы сами достичь уровня 3

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

Действительно ли надо проходить сертификацию?

Здесь нужно определить вашу область деятельности:

Если ВЫ компания, которая привлекает западные заказы , которая ищет выход на западный рынок, то ВАМ сертификация просто необходима!

Для всех остальных компаний, с точки зрения логики, нужно иметь качественные процессы, для снижения издержек, повышения качества продукции и т.д.. В этом случае вам необходимо иметь процессы, соответствующие уровню 3 (это минимум, позволяющий получать качественные процессы за не очень большие деньги. В идеале, конечно, необходимо стремиться к уровню #5) по шкале СММI, но сертификация уже не нужна.

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

Что даст сертификация?

Сертификация, как красный диплом уважаемого института, позволит привлечь западные инвестиции. Западные компании, в большинстве своем, готовы размещать свои заказы в любой стране мира, в России и странах СНГ в том числе, но только в том случае, если есть гарантии возврата денег (и, естественно, реализации проекта в надлежащем виде). Общепризнанным мерилом гарантии качественного исполнения заказа является СММI. Соответственно, с сертификатом СММ уровня 3 и выше можно смело искать проекты на западе.

Какие средства инструментальной поддержки выбрать?

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

Применение специальных средств позволит повысить эффективность процессов (всех процессов жизненного цикла разработки ПО).
Здесь кроется один подводный камень. Одними инструментами, даже самыми умными, нельзя сделать процессы качественными (автоматизировать бардак никому еще не удавалось). Чтобы начать внедрять инструменты сначала нужно найти методологию, которая позволит это сделать. Наиболее распространенная методология сейчас — это IBM RUP , которая поддерживается инструментальными средствами. Но ничто не мешает взять международный стандарт (например, ISO 12207), требования СММI, конкурирующую с Rational методологию и инструментальные средства от других производителей. Такой путь, при правильной реализации тоже приведет к СММI.

Можем ли мы сами достичь уровня 3?

Сложно сказать. Здесь масса проблем. Как трудно сделать хирургу самому себе операцию, так трудно самому себе что-то внедрять. Есть удачные примеры достижения должного качества процессов своими силами, но это скорее исключения чем правила. Для достижения 3 уровня, нужно сначала выполнить все требования уровня 2. Требования к 3 уровню приведены ниже:

1. Все процессы создания ПО, документированы, стандартизованы и представляют собой единую технологическую систему, обязательную для всех подразделений организации
2. Используется опробованная утвержденная и возведенная в статус стандарта единая технология как создания, так и сопровождения программного обеспечения
3. Основным критерием использования и корректировки процессов является помощь звену управления и техническим специалистам в повышении эффективности выполнения проектов
4. Есть группа по разработке процессов создания программного обеспечения (software engineering process group — SEPG)
5. Имеются специальные программы обучения и подготовки персонала
6. На основе единой технологической системы и согласованно с ней для каждого проекта могут разрабатываться свои процессы с учетом его особенностей («проектно-ориентированные процессы создания программного обеспечения» (project's defined software process)
7. Описание каждого процесса включает в себя условия его выполнения, входные данные, стандарты и процедуры выполнения, механизмы проверки (например, экспертные оценки), выходные данные и условия завершения
8. Документированная единая технологическая система облегчает обучение персонала, гарантирует повышение качества создаваемого программного обеспечения и является фундаментом третьего уровня
9. Интеграция процессов обеспечивает преемственность результатов выполнения задач без каких-либо преобразований