Аккредитация ИТ-компаний -- бесплатно??!

Примерно неделю назад Правительство РФ приняло Постановление № 758 "О государственной аккредитации организаций, осуществляющих деятельность в области информационных технологий".

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

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

Приносишь в ФАИТ документы согласно установленному перечню, они определяют, действительно ли деятельность организации соответствует п.4 Постановления, если всё в порядке -- заносят организацию в реестр, и можно идти пользоваться налоговыми льготами. Пока, конечно, непонятно, как они будут выявлять "несоответствия деятельности организации, указанной в справке, деятельности, указанной в пункте 4 настоящего Положения", и даже не написано, кто должен разработать критерии, согласно которым будет определяться это соответствие. Ладно, постепенно выяснится, скорее всего ФАИТ и будет это делать -- ему аккредитовывать, вот пусть само и готовит критерии.

Но гораздо больше меня поразил п.9, вторая его половина:

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

Это же ФАИТ может попасть на немалые деньги! ИТ-компаний и так немало, а если этот механизм предоставления льгот реально будет работать, не-ИТ-компании вполне могут задуматься о том, не вычленить ли ИТ-подразделение в отдельную компанию, которая будет оказывать ИТ-услуги своей "маме", пользуясь при этом льготами. И тогда ИТ-компаний станет ещё больше. А если ещё учесть, что надо бы проводить время от времени проверки, чтобы отбирать аккредитацию у тех, кто сначала прошёл проверку на соответствие и получил льготы, а потом занялся неподобающей деятельностью. Это тоже кто-то должен оплатить.

Где тут секрет? На какие деньги будет вестись этот реестр? Загадка...

(А может быть они будут брать деньги за аннулирование аккредитации? Ведь про аннулирование не написано, что оно бесплатное. Ха-ха :) )

Контроль за процессом тестирования в TrackStudio

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

Процесс тестирования примерно таков:

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

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

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

Диаграмма процесса выглядит следующим образом:

Здесь всё достаточно очевидно, кроме, быть может, жёлтых промежуточных состояний. Смысл их заключается в том, что это точки, где происходит передача работы от одного человека к другому -- см. выше описание процесса. Жёлтое состояние нестабильное, оно означает, что предыдущий участник процесса уже работу сдал, а новый ещё не принял. Это состояние требует срочного реагирования и перехода в следующее состояние. Например, когда "контролёр" принимает новый релиз, он отдаёт его системному администратору, переводя задачу в состояние "На установку". Это сигнал -- системный администратор должен принять работу. Когда он переводит задачу в состояние "Установка", значит он принял работу. Передача установленной системы тестировщику происходит при посредничестве контролёра, из-за этого на этом участке имеется два нестабильных жёлтых состояния.

Настроенный в TrackStudio процесс выглядит так:

А текущее состояние дел отображается примерно так:

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

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