Разработка требований к 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 (соответствует) — для отражения покрытия исходных требований формализованными требованиями;
tracebility_model_pos

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

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

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

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

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

sr

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

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

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

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

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

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

sr-nfrr

Рисунок 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. В итоге, с учетом включенной сортировки, было получено представление вида:

    competence_order

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

Результат

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

Таблица 1. Итоговая таблица ранжированных по востребованности компетенций IOS-разработчика (нажмите, чтобы открыть)
Identity Name count Связанные элементы
2 Objective-C 34 PROGRAMMING LANGUAGES
162 Published App 24 EXPERIENCE
3 Swift 22 PROGRAMMING LANGUAGES
145 Git / SVN 17 TOOLS & METHODOLOGIES
115 Core Data 17 iOS SDK
68 Client-Server Architecture 15 PRINCIPLES & PATTERNS
70 GCD: Grand Central Dispatch 13 PRINCIPLES & PATTERNS
66 OOP: Object-Oriented Programming 13 PRINCIPLES & PATTERNS
132 RESTful API 12 WEB / NETWORK
83 Autolayout, Storyboards, Size classes 12 iOS SDK
133 JSON, XML 11 WEB / NETWORK
190 Experience: > 2 years 10 EXPERIENCE
135 HTTP/HTTPS 10 WEB / NETWORK
105 UIKit 10 iOS SDK
157 Team Work 9 MISC
113 Core Animations 9 iOS SDK
146 Unit-Tests 8 TOOLS & METHODOLOGIES
82 HIG: Human Interface Guidelines 8 UI
158 English Language 7 MISC
76 Multithreading 7 PRINCIPLES & PATTERNS
139 SQLite 6 DATABASES
191 Experience: > 3 years 5 EXPERIENCE
188 Experience: Indefinite or < 1 year 5 EXPERIENCE
149 Jira/Redmine 5 TOOLS & METHODOLOGIES
143 XCode 5 TOOLS & METHODOLOGIES
111 Core Graphics 5 iOS SDK
87 Push Notifications 5 iOS SDK
75 Blocks/Clousers 5 PRINCIPLES & PATTERNS
71 ARC: Automatic Reference Counting 5 PRINCIPLES & PATTERNS
67 SOLID (SRP, OCR, LSP, ISP, DIP) 5 PRINCIPLES & PATTERNS
9 Python 5 Additional programming languages
7 C 5 Additional programming languages
189 Experience: > 1 year 4 EXPERIENCE
169 C++ 4 Additional programming languages
155 High Education 4 MISC
148 Agile 4 TOOLS & METHODOLOGIES
144 Instruments 4 TOOLS & METHODOLOGIES
138 SQL (generic) 4 DATABASES
136 Network Protocols, ISO/OSI 4 WEB / NETWORK
134 SOCKETS 4 WEB / NETWORK
116 Map Kit 4 iOS SDK
114 Core Location 4 iOS SDK
107 NSOperation 4 Foundation
98 ReactiveCocoa 4 3rd-PARTY / PODS
84 Universal iPad/iPhone UI 4 UI
14 Shell/Bash 4 Additional programming languages
160 Algorythms & Data Structures 3 MISC
156 The ability to deal with someone’s else code 3 MISC
150 A/B Testing 3 TOOLS & METHODOLOGIES
97 RxSwift 3 3rd-PARTY / PODS
13 Perl 3 Additional programming languages
178 MVVM 2 PRINCIPLES & PATTERNS
173 OpenGL/GLES/OpenAL 2 3rd-PARTY / PODS
153 Highload optimization 2 TOOLS & METHODOLOGIES
152 Project Management 2 TOOLS & METHODOLOGIES
147 Debugging 2 TOOLS & METHODOLOGIES
122 Development for tvOS 2 MISC
119 Core Text 2 iOS SDK
118 Store Kit 2 iOS SDK
117 AVFoundation 2 iOS SDK
110 NSURLSession 2 Foundation
99 Crashlytics/fabric 2 3rd-PARTY / PODS
96 Typhoon 2 3rd-PARTY / PODS
95 VIPER 2 PRINCIPLES & PATTERNS
94 AFNetworking 2 3rd-PARTY / PODS
93 Alamofire 2 3rd-PARTY / PODS
79 Google Protocol Buffers/Apache Thrift 2 PRINCIPLES & PATTERNS
73 FRP: Functional-Reactive Programming 2 PRINCIPLES & PATTERNS
72 MRR: Manual Retain Release 2 PRINCIPLES & PATTERNS
10 Java 2 Additional programming languages
4 JavaScript 2 Additional programming languages
192 Experience: > 4 years 1 EXPERIENCE
181 GoogleAnalytics 1 3rd-PARTY / PODS
180 MagicalRecord 1 3rd-PARTY / PODS
179 EasyMapping 1 3rd-PARTY / PODS
176 Fastlane 1 MISC
175 iTunes Connect 1 TOOLS & METHODOLOGIES
174 NSThread 1 Foundation
172 Unity3D 1 Additional programming languages
171 Core Audio 1 iOS SDK
170 Objective-C++ 1 Additional programming languages
168 Development for Windows Phone 1 MISC
166 MongoDB 1 DATABASES
165 XPC interprocess communication 1
164 Development for Mac OS 1 MISC
159 Requirements analysis 1 MISC
151 MS Office 1 TOOLS & METHODOLOGIES
141 Oracle 1 DATABASES
140 T-SQL 1 DATABASES
109 NSNotification​Center 1 Foundation
103 FMDB (SQLite Wrapper) 1 3rd-PARTY / PODS
102 Google Maps 1 3rd-PARTY / PODS
101 VK SDK 1 3rd-PARTY / PODS
100 Facebook SDK 1 3rd-PARTY / PODS
92 Realm 1 3rd-PARTY / PODS
91 RestKit 1 3rd-PARTY / PODS
88 Material Design 1 UI
86 Keychain 1 iOS SDK
85 iCloud 1 iOS SDK
80 iOS Versions’ difference understanding 1
78 KVC/KVO 1 PRINCIPLES & PATTERNS
77 Data Serialization 1 PRINCIPLES & PATTERNS
74 Delegates 1 PRINCIPLES & PATTERNS
12 Golang 1 Additional programming languages
11 Scala 1 Additional programming languages
8 C# 1 Additional programming languages
5 Angular2 1 Additional programming languages
167 Development for Android 0 MISC

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

traceability_matrix

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

Выводы

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

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

1 Objective-C 34 PROGRAMMING LANGUAGES
2 Published App 24 EXPERIENCE
3 Swift 22 PROGRAMMING LANGUAGES
4 Git / SVN 17 TOOLS & METHODOLOGIES
5 Core Data 17 iOS SDK

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

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

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

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

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

Павличенков О.С. Разработка требований к iOS-разработчику с помощью системы управления требованиями. //Практика проектирования систем.-2017. [электронный ресурс] — Режим доступа: http://reqcenter.pro/ios-analysis/, свободный. — Загл. с экрана

Литература

  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