Разработка требований к iOS-разработчику с помощью системы управления требованиями

Павличенков О. С.

Введение

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

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

И вот недавно я провел небольшой эксперимент, использовав Cradle для решения задачи анализа требований к соискателям на вакансии «iOS-разработчик». Получилось просто и интересно, поэтому я решил поделиться процессом и результатами.

Задача / контекст

Проработав 15 лет в области проектирования и создания инженерных систем, я решил значительно изменить свою карьерную траекторию: попробовать себя в разработке мобильных приложений под iOS (для iPhone/iPad).

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

Несколько месяцев я изучал онлайн-курсы и документацию для разработчиков Apple. Чтобы сфокусировать усилия на значимых для потенциального работодателя разделах, я решил проанализировать вакансии «iOS-разработчик» на одном популярном сайте и понять, какие навыки пользуются наибольшим спросом.

Вакансии содержат ТРЕБОВАНИЯ к кандидатам, поэтому к ним применима вся существующая практика разработки и управления требованиями, в том числе, соответствующий инструментарий. И, как это часто бывает, исходные требования плохо формализованы и сформулированы по-разному у разных заказчиков (в данном случае ­– работодателей), а потому их прямое сравнение и подсчет невозможен.

Для систематизации и анализа таких «некачественных» требований я воспользовался полученными на курсе [1] знаниями по формализации требований и использовал модель трассировки, которая вместе с дополнительными настройками Cradle, помогла мне элегантно решить эту задачу.

Модель трассировки требований

Для решения моей задачи достаточно было взять два типа требований из базовой модели трассировки [1], а именно:

• SR (Source Requirement) – для отражение исходных, плохо формализованных требований из вакансий;
• NFR (Non-Functional Requirement) – формализованные и структурированные требования к IOS-разработчику.

Для упорядочивания и формализации исходных требований, а также для их трассировки используются два типа связей [2]:

• HAS_PART (состоит из) — для структурирования требований внутри каждого типа элементов.
• MATCH (соответствует) — для отражения покрытия исходных требований формализованными требованиями;

Рисунок 1. Модель трассировки требований для анализа модели компетенций в вакансиях

Наполнение модели требований

В исходные требования (SR) была внесена двухуровневая структура исходных требований (содержание вакансий), где элементы верхнего уровня соответствуют одной вакансии, а элементы нижнего уровня – одной строчке из раздела «требования» данной вакансии.

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

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

Рисунок 2. Пример исходных требований из 1 вакансии

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

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

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

Рисунок 3. Разработанная модель компетенций IOS-разработчика

В ходе формализации исходных требований я проставлял связи MATCH между SR и соответствующими им NFR. Например, такие связи были созданы между одним исходным требованием SR: «Опыт работы с CoreData, MapKit, RestKit, CocoaPods» и  тремя требованиями  NFR:

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

Основные цифры:

• Обработано 50 описаний вакансий.
• Только 40 из них занесены в Cradle и подверглись детальному анализу.

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

• Выделено 418 исходных требования (SR нижнего уровня).
• Выделено 108 «атомарных» требований (NFR нижнего уровня) – элементов, составляющих разработанную модель компетенций.
• На анализ каждой вакансии уходило, в среднем, около 12 минут времени.

Количественный анализ полученной модели требований

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

Примечание: использованный метод позволяет решить данную задачу в версии Cradle Enterprise, т.к. в настольных версиях раздел Calculations в свойствах элементов недоступен.

Чтобы посчитать количество входящих связей (XRef) к одному типу элементов (NFR) от другого типа элементов  (SR), были выполнены следующие настройки:

1. Для элемента типа SR настроена калькуляция (вычисляемое поле), которое возвращает константу «1».
   В этом примере все связи рассматривались как равнозначные и меня интересовало только их количество. Но, например, в большинстве вакансий есть требования обязательные и желательные. Для построения более точной модели требований, обязательным требованиям можно присвоить «вес» = 2, а желательным = 1. Тогда  эти весовые коэффициенты будут учитываться при подсчете связей. В этом случае, требование, которое упоминалось реже, но при этом было в разделе «обязательно», может получить более высокий приоритет.
2. Для элемента типа NFR настроена калькуляция, которая считает все связи от NFR по направлению (навигации) upwards (наверх). Cradle помогает составить выражение, выбирая доступные элементы. Итоговое выражение для расчета количества связей имеет следующий вид: [@AGGR:COUNT(SR:Upwards:SYSTEM:@CALC:One_Const)]Где:
   • @AGGR:COUNT – функция агрегации, также доступны: MEAN, MIN, MAX, TOTAL, RANGE;
   • SR – название элемента, к которому считаем связи;
   • Upward – направление навигации, по которой нужно фильтровать связи.
3. Далее использовался встроенный запрос (Query) NFR-ALL, возвращающий все элементы NFR.
   Напомню, что в моей модели предполагалась двухуровневая иерархия NFR, в которой верхний уровень – это группа требований (например «Языки программирования» или «Фреймворки»), а нижний уровень NFR – конкретное требование по знанию того или иного языка программирования или фреймворка. В такой иерархии для выявления популярности требований лучше подходит запрос, возвращающий только конкретные требования – NFR-bottom.  Но, к сожалению, в вакансиях достаточно «общих» требований вида «знать основные фреймворки» или «опыт разработки не менее 2 лет». Такие исходные требования я связывал с элементом NFR верхнего уровня.
4. Создано представление (View), в которое выводится:
   • Имя элемента;
   • Количество связей;
   • Имя родительского элемента (для возможности дальнейшей сортировки/группировки);
5. В итоге, с учетом включенной сортировки, было получено представление вида:
   

   Рисунок 4. Фрагмент итоговой таблицы ранжированных требований

Результат

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

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

Рисунок 5. Фрагмент матрицы распределения требований к компетенциям по компаниям

Выводы

1. Использование специализированного инструмента для работы с требованиями Cradle упростило анализ и систематизацию большого объема исходных неформализованных требований. Некоторые результаты были для меня очевидны и до начала анализа, некоторые – удивили.
2. Опробованная технология может быть использована для управления требованиями к компетенциям персонала в рамках любой организации.
3. Анализ исходных требований показал их слабую формализацию и ранжированность. В списке требований часто соседствуют достаточно глобальные пункты (требующие годы конкретного опыта), с требованиями, для соответствия которым достаточно потратить два-три часа.
4. Наиболее востребованными требованиями к iOS-разработчику оказались:

Таблица 2. Топ-5 востребованных компетенций iOS-разработчика на основе анализа 40 вакансий в российском сегменте рынка труда

Дальнейшие планы

Очевидно, что использование Cradle для построения моделей с двумя типами элементов является полезной, но слишком простой задачей. Далее интересно было бы развить ее следующим образом:

1. Для time management добавить элементы типа Task, в которые заводить задачи по изучению той или иной темы и отмечать ход их выполнения.
2. Одним из основных требований к iOS-разработчику является наличие опубликованного в AppStore приложения. Cradle позволяет непосредственно в этой модели разработать требования к этому приложению, которые будут непосредственно связаны с исходными требованиями работодателей. В модель будут добавлены такие элементы, как:
   1. FUNCTION – для описания необходимых функций;
   2. SBS (System Breakdown Structure) — для описания компонентов приложения;
   3. DATA – для описания схем/моделей данных, необходимых в приложении;
   4. TEST – для описания необходимых тестов.

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

Хотите сослаться на эту статью? Используйте правильную ссылку:

Литература

1. Мадорская Ю.М.. Профессиональная разработка требований в ИТ-проектах. Онлайн-курс  http://saturs.ru/index.php?r=eduprograms/viewprogram/id/144
2. Мадорская Ю.М., Тимофеев А.Н.. Базовый курс по 3SL Cradle. Онлайн-издание. http://saturs.ru/index.php?r=block/plain&label=cradle-book