Хорошая вводная статья об отличиях работы исполнителя по схемам ин-хаус, аутсорс, аутстаф. Уместно описать подробнее организационную составляющую для исполнителя (эскалация, отчетность, согласования, командировки, обучение). Возможно, в отдельной статье. Интересен аспект наставничества, менторства, как в роли наставника, так и в роли подопечного. Полезно также рассмотреть те же схемы найма, но с точки зрения непосредственного руководителя таких сотрудников. Видится цикл статей.
Спасибо за Ваш отклик! По Вашим вопросам. Мы извлекаем требования заказчика в разных формах. В зависимости от условий проекта. Чаще в форме разного рода документации от заказчика, глубинных интервью, обсуждения макетов, прототипов, аналогов. При автоматизации мы опираемся как на проф.стандарты заказчика, так и на отечественные. О взаимодействии бизнес- и системного аналитиков во всех проектах нашей Компании не скажу. При заказной разработке мы не делим аналитиков на бизнес- и системных. Но требования разделяем на бизнес- и системные. Мы видим аналитика на проекте скорее как роль с конкретными задачами (в том числе, собирательную), а не как должность с функциями. В случае необходимости деления аналитиков на бизнес- и системного, взаимодействие строится на базе артефактов бизнес-требований. В форме одного документа или совокупности моделей. Задачи стандартизации в нашей Компании возложены на центры компетенций. Функции контроля качества (в частности требований) возложены на специалистов Quality Assurance в каждой проектной команде.
Согласен. Барометр, сторонний сервис, маршруты других спортсменов и т.п. позволяют существенно улучшить вычисления. Имеет смысл развивать приложение (и систему) в этом направлении.
Постоянный (или регулярный), чтобы показывать данные в ходе тренировки. Как это сделано в ведущих беговых мобильных приложениях. Для разового постпроцессинга вариант хорош.
Хороший вариант. Рассматривался. Но есть ограничения: санкции, необходимость постоянного доступа в Интернет, условия пользования сервисами Strava. Кроме того, маршрут может отсутствовать или совадать частично.
Вы правы. Наложить несколько профилей на один график не такой уж трудоемкий процесс. Если эти профили имеются. В данном случае, мобильное приложение располагает только "гражданскими" координатами. Вы правы, это "причесывание", если можно так выразиться. Эта статья - не открытие и не изобретение. И такой задачи не ставилось. Предложенный алгоритм дает результат не хуже вычисления по исходным (не обработанным) данным. И к тому же критерий "чтобы пользователь не скандалил" не последний в современной индустрии.
Соглашусь. Это - перспективный вариант. Хотя и у него есть свои недостатки. Требуется постоянный доступ мобильного приложения в Интернет в ходе тренировки. Дополнительная нагрузка на сервер.
Результаты обработки сравнивались с заведомо более точными данными из разных источников (картографических информационных систем, более точных трекеров на тех же маршрутах, результатов анализа рельефа местности и т.п.). Изучались возможные причины "выбросов". Процесс довольно трудоемкий и не описан, чтобы не перегружать статью. Этому вопросу можно посвятить отдельную стстью. Исходные данные (до обработки) приведены для иллюстрации.
Хорошая вводная статья об отличиях работы исполнителя по схемам ин-хаус, аутсорс, аутстаф. Уместно описать подробнее организационную составляющую для исполнителя (эскалация, отчетность, согласования, командировки, обучение). Возможно, в отдельной статье. Интересен аспект наставничества, менторства, как в роли наставника, так и в роли подопечного. Полезно также рассмотреть те же схемы найма, но с точки зрения непосредственного руководителя таких сотрудников. Видится цикл статей.
Спасибо за Ваш отклик!
По Вашим вопросам. Мы извлекаем требования заказчика в разных формах. В зависимости от условий проекта. Чаще в форме разного рода документации от заказчика, глубинных интервью, обсуждения макетов, прототипов, аналогов. При автоматизации мы опираемся как на проф.стандарты заказчика, так и на отечественные.
О взаимодействии бизнес- и системного аналитиков во всех проектах нашей Компании не скажу. При заказной разработке мы не делим аналитиков на бизнес- и системных. Но требования разделяем на бизнес- и системные. Мы видим аналитика на проекте скорее как роль с конкретными задачами (в том числе, собирательную), а не как должность с функциями. В случае необходимости деления аналитиков на бизнес- и системного, взаимодействие строится на базе артефактов бизнес-требований. В форме одного документа или совокупности моделей.
Задачи стандартизации в нашей Компании возложены на центры компетенций. Функции контроля качества (в частности требований) возложены на специалистов Quality Assurance в каждой проектной команде.
Согласен. Барометр, сторонний сервис, маршруты других спортсменов и т.п. позволяют существенно улучшить вычисления. Имеет смысл развивать приложение (и систему) в этом направлении.
Постоянный (или регулярный), чтобы показывать данные в ходе тренировки. Как это сделано в ведущих беговых мобильных приложениях. Для разового постпроцессинга вариант хорош.
Хороший вариант. Рассматривался. Но есть ограничения: санкции, необходимость постоянного доступа в Интернет, условия пользования сервисами Strava. Кроме того, маршрут может отсутствовать или совадать частично.
Вы правы. Наложить несколько профилей на один график не такой уж трудоемкий процесс. Если эти профили имеются. В данном случае, мобильное приложение располагает только "гражданскими" координатами. Вы правы, это "причесывание", если можно так выразиться. Эта статья - не открытие и не изобретение. И такой задачи не ставилось. Предложенный алгоритм дает результат не хуже вычисления по исходным (не обработанным) данным. И к тому же критерий "чтобы пользователь не скандалил" не последний в современной индустрии.
Соглашусь. Это - перспективный вариант. Хотя и у него есть свои недостатки. Требуется постоянный доступ мобильного приложения в Интернет в ходе тренировки. Дополнительная нагрузка на сервер.
Результаты обработки сравнивались с заведомо более точными данными из разных источников (картографических информационных систем, более точных трекеров на тех же маршрутах, результатов анализа рельефа местности и т.п.). Изучались возможные причины "выбросов". Процесс довольно трудоемкий и не описан, чтобы не перегружать статью. Этому вопросу можно посвятить отдельную стстью. Исходные данные (до обработки) приведены для иллюстрации.