Модели и методологии разработки по

Мониторинг производственного оборудования: как с этим дела в России

Recovery Mode

Привет, Хабр! Наша команда занимается мониторингом станков и разных установок по всей стране. По сути, мы обеспечиваем возможность производителю не гонять лишний раз инженера, когда «ой, оно всё сломалось», а на деле надо нажать одну кнопку. Или когда сломалось не на оборудовании, а рядом.
Базовая проблема следующая. Вот вы производите установку для крекинга нефти, либо станок для машиностроения, либо какое-то другое устройство для завода. Как правило, продажа сама по себе крайне редко возможна: обычно это контракт на поставку и обслуживание. То есть вы гарантируете, что железяка будет работать лет 10 без перебоев, а за перебои отвечаете либо финансово, либо обеспечиваете жёсткие SLA, либо что-то подобное.
По факту это означает, что вам нужно регулярно отправлять инженера на объект. Как показывает наша практика, от 30 до 80 % выездов — лишние. Первый случай — можно было бы разобраться, что случилось, удалённо. Либо попросить оператора нажать пару кнопок — и всё заработает. Второй случай — «серые» схемы. Это когда инженер выезжает, ставит в регламент замену или сложные работы, а сам делит компенсацию пополам с кем-то с завода. Или просто наслаждается отдыхом с любовницей (реальный случай) и поэтому любит выезжать почаще. Завод не против.
Установка мониторинга требует модификации железа устройством передачи данных, самой передачи, какого-то озера данных для их накопления, разбора протоколов и среды обработки с возможностью всё посмотреть и сопоставить. Ну и с этим всем есть нюансы.

Этапы создания программных продуктов

Приведём все основные этапы создания программного продукта. Всего их пять. Они так или иначе характерны для любой методологии разработки ПО: будь то классическая водопадная, либо современные гибкие методологии (Agile software development) – во всех из них разработчики проходят через следующие этапы создания программного обеспечения:

Составление требований заказчика. На данном эта производится работа с заказчиком и документирование его видения и его требований к программе. В подавляющем большинстве случаев данный этап проходит трудно

Поскольку, слабо разбираясь в особенностях разработки ПО, заказчик плохо представляет себе, что нужно знать разработчикам и (самое главное!), что им нужно сообщить о продукте.Выработка требований чрезвычайно важное мероприятие. Убедитесь, что все требования полностью понятны вам и вашей команде.

Проектирование программного продукта

Разобравшись в предметной области, разработчики приступают к проектированию. На данном этапе создания программного продукта разрабатывается архитектура компонентов ПО, выбираются нужные шаблоны проектирования (паттерны) и составляется схема информационной базы данных системы.

Разработка. Когда требования сформулированы и архитектура готова – команда начинает разработку ПП. На этапе разработки также выполняется документирование системы.

Тестирование. После разработки необходимо произвести тестирование системы в целом, тем самым подтвердить её соответствие требованиям заказчика.
Здесь стоит сказать, что модульные тесты (unit-тесты; т.е. тесты отдельных частей программы) обычно выполняются на этапе разработки программистом, разрабатывавшем конкретный модуль.
Когда все тесты пройдены, программное обеспечение готово к выпуску.

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

Примечание 1: Следует как можно тщательнее подходить к формированию предварительных требований и проектированию, поскольку стоимость исправления ошибок после выпуска ПО, допущенных на этих этапах, обычно в 2-10 (!) раз выше, чем стоимость исправления ошибок сделанных на этапе программирования (Стив Макконнелл “Совершенный код”).

Примечание 2: Очень часто случается, что заказчик уже после составления требований к ПО (т.е. во время проектирования и разработки) объявляется и радостно сообщает исполнителю свои новые идеи или рассказывает о какой-нибудь “классной” функции, которую нужно добавить в приложение… Бывают случаи, когда это труднореализуемо и сопряжено с пересмотром архитектуры. В данной ситуации можно посоветовать сказать разработчику примерно следующее: “Отлично придумано! Мне нравится! Тогда я пересмотрю свою смету и сроки работы и потом сообщу Вам!”. Практически всегда это срабатывает и гасит пыл заказчика, и он отказывается от новых идей и изменений в проекте.

Типовые ситуации при непрерывной интеграции

• Перевод
• Tutorial

Вы изучили команды Git но хотите представлять, как непрерывная интеграция (Continuous Integration, CI) происходит в реальности? Или может вы хотите оптимизировать свои ежедневные действия? Этот курс даст вам практические навыки непрерывной интеграции с использованием репозитория на GitHub. Данный курс не задуман как некий визард, который можно просто прокликать, напротив, вы будете совершать те же действия, что люди на самом деле делают на работе, тем же способом, которым они это делают. Я буду объяснять теорию по мере прохождения вами имеющих к ней отношение шагов.

Что мы будем делать?

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

Этот GIF схематично показывает коммиты в вашем репозитории по мере продвижения по курсу. Как видите, тут нет ничего сложного и только самое необходимое.

Вы пройдёте такие стандартные для CI сценарии:

• Работа над фичей;
• Применение автотестов для обеспечения качества;
• Реализация приоритетной задачи;
• Разрешение конфликта при слиянии ветвей (merge conflict);
• Возникновение ошибки в продуктивной среде.

Разработка AI-продукта на основе машинного зрения. Промежуточная ретроспектива: мысли, боль, страдания

Здравствуйте, читатели. Я порывался написать эту статью уже несколько раз, но каждый раз откладывал, поскольку, при мысли о необходимости провести глубокую рефлексию по накопленному опыту, меня накрывало уныние и печаль. Однако, я укрепился в своем намерении сделать это, чтобы поделиться опытом с теми из вас, кто планирует заняться чем-то подобным в сфере AI. Все нижеописанное относится к весьма конкретной сфере деятельности: AI в части компьютерного зрения.

Disclaimer: Я не специалист в нейросетях, но выполняю роль владельца продукта, в котором ключевую роль занимают нейросетевые модели компьютерного зрения. Эта статья для тех, кто вынужден делать такую же работу, а так же для тех специалистов ML, которые хотят понять, как на их деятельность смотрят люди со стороны бизнеса.

В каком вузе Санкт-Петербурга можно получить профессию Руководителя разработки программного обеспечения

• от 61 000 / год
  Информация о стоимости года обучения предоставлена за 2020 год

  Санкт-ПетербургГосударственный

  программная инженерия; информационные системы и технологии; информатика и вычислительная техника и еще 34 направления

  Ср. балл ЕГЭ бюджет 2019от 60.3 бал.бюджет

  Ср. балл ЕГЭ платно 2019от 39.7 бал.платно

  Бюджетных мест 2020 1 231 место бюджет

  Платных мест 2020 906 мест платно

  Средний балл ЕГЭ на бюджет в 2019 году от 60.3

  Средний балл ЕГЭ на платные места в 2019 году от 39.7

  Количество бюджетных мест в 2020 году 1 231

  Количество платных мест в 2020 году 906

  Что такое средний проходной балл

  Бакалавриат, специалитет

  5 подразделений

• от 74 000 / год
  Информация о стоимости года обучения предоставлена за 2020 год

  Санкт-ПетербургГосударственный

  программная инженерия; прикладная информатика; информатика и вычислительная техника и еще 62 направления

  Ср. балл ЕГЭ бюджет 2019от 69.3 бал.бюджет

  Ср. балл ЕГЭ платно 2019от 50 бал.платно

  Бюджетных мест 2020 2 687 места бюджет

  Платных мест 2020 4 798 места платно

  Средний балл ЕГЭ на бюджет в 2019 году от 69.3

  Средний балл ЕГЭ на платные места в 2019 году от 50

  Количество бюджетных мест в 2020 году 2 687

  Количество платных мест в 2020 году 4 798

  Что такое средний проходной балл

  Бакалавриат, специалитетМагистратура

  10 подразделений

• от 145 600 / год
  Информация о стоимости года обучения предоставлена за 2020 год

  Санкт-ПетербургГосударственный

  математика и компьютерные науки; прикладная математика и информатика; математическое обеспечение и администрирование информационных систем и еще 62 направления

  Ср. балл ЕГЭ бюджет 2019от 73 бал.бюджет

  Ср. балл ЕГЭ платно 2019от 55 бал.платно

  Бюджетных мест 2020 2 014 места бюджет

  Платных мест 2020 1 856 место платно

  Средний балл ЕГЭ на бюджет в 2019 году от 73

  Средний балл ЕГЭ на платные места в 2019 году от 55

  Количество бюджетных мест в 2020 году 2 014

  Количество платных мест в 2020 году 1 856

  Что такое средний проходной балл

  Бакалавриат, специалитетМагистратура

  24 подразделения

Проф.ориентация

Выбрать обучение

Моя ли это профессия

Наша огромная гордость: мирные советские роботы-комбайны убрали первый урожай в южных регионах

А ведь в прошлом году это делали senior-разработчики.
Возможно, вы помните, что мы говорили про то, как можно сильно улучшить работу обычного сельскохозяйственного комбайна, если использовать нейросетки для распознавания культур и препятствий и робота для автопилотирования. Всё это (кроме процессоров Nvidia и ещё части железа) — наша разработка. А радость в том, что в некоторых южных регионах страны закончилась уборочная страда, и наши комбайны показали себя лучше, чем ожидалось. Слава роботам!
В этом году мы поставили несколько сотен блоков из мощного графического ядра (для нейросетей), камер, гидравлических насосов или CAN-модулей для подруливания. Если в прошлом году агропилоты были в опытной эксплуатации, то сейчас речь идёт уже про серийные модели. И они справились.
Более того, они справились лучше, чем мы ждали. Кроме того, в релиз вошли далеко не все фичи. В релизе осталось, по сути, ядро, но одно только это позволило получить очень заметный экономический эффект.
Конечно, обошлось не без сюрпризов. Но давайте расскажу более конкретно, с числами и примерами.

Как мы хакнули умные подушки и запустили приложение для умной спальни «Асконы»

Привет! Меня зовут Сергей Солдатов, я директор по продукту в компании 65apps. Мы разрабатываем мобильные приложения, используем в работе продуктовый подход. Хочу поделиться с вами нашим недавним кейсом, где именно продуктовый подход помог погрузиться в непривычную предметную область и создать сервис с уникальной ценностью. Это наш совместный проект с компанией «Аскона» — приложение для управления умной спальней.
Для начала забавный факт: перед началом работы всей проектной группе, а это: директор по продукту, арт-директор, руководитель проекта, аналитик, дизайнер, разработчики iOS, Android и QA-специалист, «Аскона» передала свои умные девайсы, — видимо, чтобы мы лучше высыпались и продуктивнее работали. Прямиком с завода к нам в ижевский офис приехали подушки, трекеры сна, основание кровати — все это было необходимо подключить. Мы действительно спали на этих подушках — и это тот самый случай, когда я готов их неистово рекомендовать. Я уже не смог вернуться к своей старенькой синтепоновой, и после сдачи проекта купил всей семье «умные» подушки («Аскона» не платит мне за рекламу, а жаль).
Это тот самый случай, когда клиент позаботился о своих разработчиках и, в результате, мы сделали классное приложение. Но обо всем по порядку.

Классификация проектов

Модель и параметры процесса производства ПО в значительной мере зависит от типа проекта. У каждой команды есть свои заказчики, с которыми сложились те или иные отношения.

«Свой» заказчик

Ситуация, при которой команда разработчиков в течение длительного времени обслуживает единственного заказчика. Как правило, подобный вариант характеризуется великолепными отношениями между заказчиком и разработчиками. Зачастую такие команды располагаются на территории заказчика. Основные характеристики этого типа проекта:

• доступность заказчика в любое время;
• устойчивое представление о нуждах и потребностях заказчика, сформировавшееся за годы сотрудничества;
• достаточно низкие требования к качеству программного обеспечения;
• постоянное сопровождение своих продуктов, их доработка и совершенствование;
• устойчивые финансовые взаимоотношения между заказчиком и разработчиками;
• долгосрочные планы по сотрудничеству.

Продукт под заказ

Ситуация, при которой команда разработчиков находит стороннего заказчика и договаривается с ним о разработке программного продукта, призванного решить те или иные проблемы заказчика. Основные характеристики такого типа проекта:

• доступность заказчика можно охарактеризовать как «периодическую»;
• представление о нуждах и потребностях заказчика формируется на базе произведенного обследования;
• заранее оговоренные требования к программному обеспечению, согласно которым производится приемка готового продукта;
• разработчик в течение заранее оговоренного периода времени поддерживает поставленный продукт;
• финансовые отношения оформляются в виде разового контракта;
• планы по дальнейшему сотрудничеству в значительной мере зависят от качества и устойчивости продукта, который разработчик поставил заказчику.

Тиражируемый продукт

Ситуация, при которой команда разработчиков либо вообще не имеет конкретных заказчиков («коробочный продукт»), либо довольно значительное количество заказчиков на один и тот же продукт. Основные характеристики такого типа проекта:

• конкретного заказчика, формирующего требования к продукту, не существует;
• представление о нуждах и потребностях настоящих и потенциальных пользователей формируются на основе анализа рынка и контактах с типовыми представителями пользователей. Обратная связь с пользователями продукта осуществляется в основном посредством электронной почты;
• качество программного обеспечения контролируется только внутренним отделом качества + обратная связь с пользователями. Широко используется бета-тестирование;
• разработчик в течение заранее оговоренного периода времени поддерживает поставленный продукт;
• финансовые отношения существуют в виде фиксированной цены на продукт;
• планы по развитию продукта формируются на основе анализа рынка.

Аутсорсинг

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

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

Жизненный цикл программы

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

• Процесс приобретения. Данный процесс представляет собой действия заказчика разработки ПО, и обычно включает в себя такие мероприятия, как: формирование требований и ограничений к программному продукту (ограничения могут быть связаны с выбором программной архитектуры, а также с приемлемым быстродействием системы и т.д.); заключение договора на разработку; анализ и аудит работы исполнителя. В конце данного процесса заказчик осуществляет приёмку готового программного продукта.
• Процесс поставки включает в себя мероприятия, проводимые исполнителем по поставке ПО. Исполнитель анализирует требования заказчика, выполняет проектирование и анализ работ, решает, как будет происходить процесс конструирования (программирования): своими силами, либо же с привлечением сторонних команд разработки (подрядчика), также осуществляет оценку и контроль качества готового программного продукта и выполняет непосредственно поставку продукта и сопутствующие завершающие мероприятия.
• Процесс разработки. Его мы подробно рассмотрим в разделе .
• Процесс эксплуатации. После того, как программное обеспечение будет готово, начинается процесс его эксплуатации организацией-заказчиком и её операторами.
• Процесс сопровождения. Фирма-разработчик осуществляет поддержку пользователей программного продукта в случае возникновения у них каких-либо вопросов или проблем. Если в процессе эксплуатации будет обнаружена ошибка в ПП, разработчики должны её устранить. Процесс эксплуатации и процесс сопровождения идут параллельно.

Вспомогательные процессы

Технология разработки программ в рамках жизненного цикла программного обеспечения включает в себя ряд вспомогательных процессов. Рассмотрим их.

• Процесс документирования. В процессе разработки и далее исполнитель пишет документацию и руководства пользователя к разрабатываемому программному продукту. Данные документы помогут разработчикам [вспомнить/разобраться] структуру и код ПО (ибо со временем всё забывается, особенно в больших проектах), а пользователям освоить работу с программой.
• Процесс управления конфигурацией. Данный процесс включается в себя работы по управлению наборами разрабатываемых компонентов ПО и по управлению версиями ПП.
• Процесс обеспечения качества. Он отвечает за то, чтобы разрабатываемый программный продукт соответствовал предварительным требованиям к разработке, а также стандартам организаций исполнителя и заказчика.
• Процесс верификации. Нужен для того, чтобы выявить ошибки внесённые в ПО во время конструирования, а также выявить несоответствия разрабатываемого ПО выработанной архитектуре.
• Процесс аттестации. Процесс направлен на подтверждение соответствия получаемых величин эталонным. То есть, выходные данные должны иметь погрешность, удовлетворяющую требованиям и установленным стандартам.
• Процесс совместной оценки. Нужен для контроля и проверки состояния персонала и разрабатываемого программного продукта. Выполняется обеими сторонами (заказчиком и исполнителем) на протяжении времени всех работ по проекту.
• Процесс аудита. Аудит направлен на независимую оценку текущих положений, состояния проекта, документации и отчетов. При аудите выполняется сравнение с договором и документами, определяющими стандарты. Может выполняться также обеими сторонами.
• Процесс разрешения проблем. Реализует устранение недочётов, выявленных во время всех процессов связанных к контролем и оценкой.

Управление задачами

Цели

Примечание.Пример.Примечание:http://www.forbes.ru/kompanii/245905-v-kakikh-otraslyakh-rabotayut-samye-neeffektivnye-rossiiskie-kompaniiПример. Пример.Примечание (Василина Абу-Навас, бизнес-консультант, объединение «Практик»):Пример.

Описание

Таблица 1. Список задач для мобильной навигационной системы GPS

Параметры

Примеры:

• Добавить экран поиска перекрёстков. (Примечание: Проверяемый критерий – экран. Он либо есть, либо его нет.)
• Разобраться, почему не строится маршрут через кольцевую дорогу в Санкт-Петербурге. (Примечание: Проверяемый критерий – построение маршрута через кольцевую дорогу.)

Примеры:Рисунок 1. Объём работы над мобильной навигационной системой GPSПример.

ПО

• Электронные таблицы Excel или Google Docs
• Redmine – http://www.redmine.org
• Jira – https://www.atlassian.com/software/jira
• BugZilla — http://www.bugzilla.org
• DropTask – http://www.droptask.com
• Hansoft – http://www.hansoft.com

Организация управления IT-проектом

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

Самое грубое деление классической модели ролей:

• Владельцы.
• Исполнители.
• Потребители.

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

Внешние:

• Поставщики.
• Посредники.
• Потребитель (клиенты).

Для организации управления проектом в ИТ такое разделение слишком топорно, здесь нужна другая градация полномочий.

Все участники проекта, причастные к его созданию и потреблению, разделяются на:

• Заказчик. Главный. Принимает все ключевые решения.
• Собственник. Владелец всех прав собственности на продукт проекта. Часто — заказчик.
• Инициатор. Его идея становится проектом. Любой участник проекта может им быть. Права у заказчика.
• Родительская (головная, материнская, постоянная) организация. Организация, в которой возник и будет проект.
• Спонсор. Предоставляет финансирование. Обеспечивает материальные ресурсы.
• Инвестор. Вкладывает финансирование ради личной прибыли от реализации проекта.
• Управляющий (менеджер проекта). Лично ответственный за проект перед заказчиком. Имеет право принимать решения сам.
• Команда управления. Руководители среднего звена.
• Команда. Исполнители. Создают продукт.
• Контрактор, Субконтрактор, Подрядчик. Исполнитель по контракту.
• Клиент. Потребитель продукта.