[БЕЗ_ЗВУКА] В прошлом разделе курса мы разобрали общие принципы работы над проектом. Теперь разберем, как эта работа организуется практически. Но сначала еще раз очень коротко резюмируем, с каким процессом и именно какими стадиями будем иметь дело, с тем чтобы у нас был единый контекст для дальнейшего изложения. Если раньше архитектор отвечал за реализацию всего своего замысла от идеи до готового дворца или храма, а инженер — до готового моста, башни или машины, и результат был вопросом его таланта, то сейчас процесс создания сложных систем в достаточной степени формализован и является по сути ремеслом. Мы уже выяснили в прошлом разделе курса, что жизненный цикл системы — это стадии процесса, охватывающего различные состояния системы, начиная с момента возникновения необходимости в такой системе и заканчивая полным выводом ее из эксплуатации. Создание и использование приложения интернета вещей также проходит все стадии жизненного цикла. Но, как мы уже говорили, при единых общих принципах жизненный цикл и его этапы могут быть определены по-разному как для разных отраслей, так и даже для разных проектов. Например, в ГОСТ 15288 в качестве примера приведены такие стадии: стадия замысла, стадия разработки, стадия производства, стадия применения, стадия поддержки применения и стадия прекращения применения и списание. А ГОСТ 34, на который часто ориентируются при разработке приложений интернета вещей, определяет стадии создания автоматизированной системы так: формирование требований, разработка концепции, техническое задание, эскизный проект, технический проект, рабочая документация, ввод в действие, сопровождение в процессе эксплуатации. В зарубежной практике создания программного обеспечения работа над проектом начинается с выявления требований, разработки его концепции, вариантов использования и спецификации. Видно, как мы уже разобрали в прошлом разделе курса, что большинство такого рода моделей жизненного цикла начинается со стадии анализа и подготовки концепции. Это означает, что заказчик пришел к разработчику, уже выбрав способ решения своей проблемы и нуждается лишь в средствах для этого. То есть отсчет этапов жизненного цикла системы, регламентирующих документов такого рода начинается тогда, когда способ решения уже как-то определен, а внимание, соответственно, сконцентрировано в основном на подготовке средств деятельности. Соответственно, для заказчика все эти этапы окажутся внутри одного этапа «разработка», за которой последует приемка, основание, использование, возможно, модернизация, замена, инициализация и так далее. Поэтому, хотя разработчик движется по своей части цикла, ему важно видеть всю картину и понимать мотивы запуска проекта, изначальные потребности, которые он должен удовлетворять, что часто бывает необходимо для правильной организации деятельности. Понимать общие принципы тем более необходимо, что используемая терминология, понятия и даже онтология могут меняться в разных сферах деятельности, хотя суть остается одной и той же. Итак, в общем случае перед разработчиками стоит задача — понять, в чем состоит проблема и чья она (это важно). Представить, что должно делаться, чтобы эта проблема была решена. Представить, как должна выглядеть система, которая сможет делать то, что даст решение задачи. Определить, какой набор компетенций должен быть у системы, чтобы выполнить данную деятельность. Подобрать устройство и системы (физические и виртуальные), которые могли бы сделать эту работу. Распределить задания между этими устройствами и системой. И дать каждому инструкции, что именно, кому необходимо делать в этой ситуации, чтобы работа была выполнена.
