[БЕЗ_ЗВУКА] Прежде чем пройти по процедурам разработки, скажем несколько слов о команде и ролях проекта. Современные технологии и платформы, в том числе те, которые мы рассматривали в предыдущих частях курса, позволяют выполнять разработку приложений Интернета вещей исключительно эффективно. Для небольшого и даже среднего проекта все эти этапы от получения задачи до выдачи готовой системы может выполнить даже один квалифицированный разработчик или небольшая команда универсалов. Но часто можно видеть, как при всей этой простоте и эффективности процесса разработки проблема начинается при масштабировании проекта, когда усилий одного разработчика или малой команды перестает хватать. И возникает проблема распределения ролей и, соответственно, функций и зон ответственности. Чтобы понять, какие роли есть в проекте, давайте еще раз посмотрим, какие в цикле проектирования присутствуют виды деятельности. Конечно, детализация может быть разной, тем более, что у конкретного проекта может быть своя специфика. Но нам сейчас важно, что некоторые виды деятельности принципиально между собой отличны, причем настолько, что их выполнение может требовать не только разных компетенций и, соответственно, разной подготовки, но, возможно, даже и разных личных качеств того, кто берет на себя такую роль. Пройдем по нашему списку работ еще раз, но сначала надо выяснить, в чем именно состоит проблема. Причем мы уже останавливались на том, что задача может быть некорректно поставлена, плохо формализована, а иногда заказчик даже сам неверно формулирует свои требования, вот как в сказке о рыбаке и рыбке, которую мы и разбирали. Там заказчик желал достойного выкупа, а заказал корыто, остался недоволен. Таким образом, налицо задача выявления требований заказчика, понимание того результата, который он ожидает от разработчика. Далее, должно быть предложено решение, которое обеспечивает такой результат, и суметь представить и предложить его, и это отдельный навык. Если взять аналогию с медициной, то там есть диагностика как отдельный раздел клинической медицины, и лишь после постановки диагноза можно сделать необходимые назначения. Тут есть принципиальная разница в том, что врачу известен требуемый результат лечения — пациент должен вернуться в состояние без болезни. А вот разработчику требуется понять, каков должен быть результат, и это разработчику еще не известно. Ведь если бы результат был известен, то заказчик обратился бы к продавцу, у которого можно его купить, а не к разработчику. Итак, выяснение требований к решению, диагностика, самостоятельный процесс и предложение решения проблемы тоже. Но поскольку правильного решения на момент постановки диагноза не существует, предложение варианта решения, уточнение требований, уточнение решения становится итеративным процессом, элементы которого бывает трудно разделить. В рамках данного курса мы будем условно называть человека, выполняющего, формализующего требования к решению, аналитиком. Но важно, что аналитик в данном случае, это роль в проекте, а не позиция или должность. Кроме того, разные позиции в разных методологических практиках, в разных стандартах, в разных странах и даже организациях могут называться по-разному. К примеру, требования к системе верхнего уровня могут разрабатывать и системный алитик, и бизнес-аналитик, и менеджер по требованиям, и руководитель проекта и так далее. А иногда требования формирует даже сам заказчик. С другой стороны, человек на позиции «аналитик» совершенно не обязательно работает с требованиями. Так в некоторых проектах аналитик-программист обеспечивает коммуникацию в команде, формирует алгоритмы работы с требованиями и так далее. Системный аналитик может работать на техподдержке, например, разбираться с причинами претензий, а институциональный аналитик вообще не работает с проектом, а разрабатывает IT-стратегию и формирует IT-ландшафты в компании. Наконец, как уже было сказано, в команде может просто не быть аналитика, а его функцию выполняет менеджер проекта и ведущие разработчики. Тем не менее, есть ли такая позиция в организации или команде или нет, но выявлением требований в явном или неявном виде все равно кто-то занимается. И в этот момент человек играет роль аналитика. Аналогично мы будем называть архитектором того, кто по своей роли предлагает образ, видение, концепцию возможного решения. И снова это может быть кто угодно по должности: тот же системный аналитик или руководитель проекта, или архитектор программного обеспечения. Бывает, что разработкой концепции новых продуктов занимаются дизайнеры или маркетологи. А из советских времен мы знаем, что именно главные (генеральные) конструктора помимо общего управления конструкторским подразделением предприятия, известны разработкой концепции своих продуктов. В человеко-ориентированных системах ключевым будет то, какую информацию, в каком виде и когда должен получить пользователь, ведь проектирование такого рода взаимодействия становится важной частью разработки, соответственно может появиться самостоятельная позиция архитектора по взаимодействиям или дизайнера по таким взаимодействиям. Итак, мы осмыслили проблему и представили способы ее решения. Что нужно, чтобы это решение реализовать? Нужны исполнители — те, кто подготовят необходимые средства, запрограммируют компьютеры, контроллеры, изготовят необходимые электронные модули и так далее. Но кто, имея концепцию решения, сможет исполнителям сказать, кому что конкретно делать? И в прошлом разделе курса мы выяснили, что это будет человек, которого мы условно называем проектировщик. Мы договорились, что это именно он трансформирует, конвертирует преставления об ожидаемом результате в перечень работ, необходимых, чтобы его получить. Мы также говорили, что у проектирования могут быть два аспекта. С одной стороны, это детализация потребительских качеств, за которую обычно отвечает дизайнер, тогда как инженер занимается созданием спецификаций продукта, соответствующего данной концепции, такого, чтобы он был правильным: надежным, безопасным, рентабельным и так далее. И чтобы было понятно, как его сделать. Естественно, роли проектировщика, дизайнера и инженера в таком понимании могут совершенно не соответствовать должностям с теми же названиями. Скажем, если в машиностроении позиция промышленного дизайнера или инженера-конструктора достаточно близко соответствует описанным выше ролям, то какой-нибудь инженер по технике безопасности не будет иметь никакого отношения к разработке спецификаций, а некий дизайнер может быть лишь по факту иллюстратором или оформителем, не имеющим отношения к процессу проектирования. Резюмируем. В дальнейшем, описывая процесс разработки приложений Интернета вещей, мы будем ориентироваться на такие этапы работы и роли тех, кто их обычно выполняет. Выявление проблемы, требований и ограничений к способам ее решения, диагностика — это аналитик. Предложение образа результата проблемы, ее концепции — это архитектор. Причем мы говорили, что концепция может включать и представление об архитектуре, то есть общих принципов устройства той системы, которая будет решать заявленную проблему. Далее идет проектирование системы — переход от общего представления системы к деталям ее устройства, таким чтобы люди, обладающие необходимыми для этого компетенциями, могли ее практически изготовить и запустить в эксплуатацию. И этим занимаются проектировщики, дизайнеры и инженеры. Наконец, стадия реализация, воплощение системы. Необходимая для этого компетенция зависит от конкретной реализации системы. К примеру, Международной система сертификации разработчиков приложений компании PTC определяет такие специализации, как построение моделей, организацию связей, разработку пользовательских интерфейсов. И постоянно приходится говорить, что данные роли в проекте могут соответствовать самым разным должностям в организации или проектной команде и позициям в проекте. Тем не менее, попробуем соотнести упомянутые роли в проекте с действующими профессиональными стандартами. Аналитика, ну здесь относительно просто. Этому виду соответствует профессиональный стандарт системный аналитик № 06.022. Стандарт определяет, что основная цель этого вида профессиональной деятельности — разработка, восстановление и сопровождение требований к программному продукту, средству, обеспечению, программно-аппаратному комплексу, автоматизированной информационной системе или автоматизированной системе управления на протяжении их жизненного цикла. С разработкой архитектуры системы связан прежде всего архитектор программного обеспечения. Это профстандарт 06.003. Стандарт говорит, что основная цель этой деятельности — создание и сопровождение архитектуры программных средств, заключающихся в синтезе и документировании решений о структуре, о компонентном устройстве, об основных показателях назначения, порядке и способах реализации программных средств в рамках системной архитектуры. Реализация требований к программным средствам и контроль реализации и ревизия решений. Но видно, что эта деятельность относится именно к программному обеспечению, тогда как система Интернета вещей содержит также разного рода физические и виртуальные объекты. Поэтому здесь может подойти еще один стандарт. Это стандарт 06.041 — специалист по интеграции прикладных решений. Его основной целью профессиональной деятельности является определение архитектурных и реализационных решений по интеграции приложений информационных систем и облачных сервисов. Стоит иметь в виду, что на уровне построения архитектуры может работать и промышленный дизайнер (эргономист). Это профстандарт 40.059. Кстати, к проектированию можно отнести также такие специальности, как специалист по информационным системам (стандарт 06.015); специалист по дизайну графических и пользовательских интерфейсов (06.025); системный программист (06.028). Реализацией проекта будет заниматься в первую очередь программист (это стандарт 06.001); специалист по информационным ресурсам (06.013); разработчик Web и мультимедийных приложений (06.035); специалист по контролю качества информационно-коммуникационных систем (06.040); или, к примеру, графический дизайнер (11.013). А процесс проектирования будут обеспечивать: менеджер продуктов в области информационных технологий (это профстандарт 06.012); руководитель проектов в области информационных технологий (06.016); руководитель разработки программного обеспечения (06.017); или менеджер по продажам информационно-коммуникационным систем (06.029). Таким образом, определив общие принципы работы над проектом и роль участников этого процесса, мы можем детально перейти ко всем его этапам.
