[БЕЗ_ЗВУКА] Концепция системы и ее построение. В рамках данного курса мы будем называть концепцией системы то общее представление об ее облике, которое сложилось у вас как у разработчика. И именно это ваше представление вам потребуется донести до заказчика и согласовать с ним, прежде чем приступить к проектированию системы. Из анализа проблемы и требований к ее решению мы к этому моменту уже понимаем, что должна «уметь» система, какими «компетенциями» обладать. И мы должны также дать свои предложения по тому, какие средства для этого будут нужны и как они будут использоваться. Итак, за концепцию мы будем считать то, как система выглядит со стороны, ее как бы «внешний вид», а также то, как она ведет себя, как действует. При этом мы пока еще не берем в расчет ее внутреннее устройство. Важно, что никакой элемент системы не появляется просто так без явной на то необходимости. Поэтому когда мы описываем заказчику систему, из чего она состоит и что будет делать, это фактически обратный процесс по отношению к процессу разработки. Ведь там наоборот: мы сначала выясняем требования к системе (что и как она должна уметь делать) и представляем, из чего она должна для этого состоять. Поэтому, другими словами, можно сказать, что концепция — это перечень нескольких компетенций (или «умений») системы с описанием средств, которыми эти «умения» достигаются. К примеру, участникам чемпионата мира соревнований WorldSkills в компетенции «Мобильная робототехника» было необходимо создать складского робота. Это ведь обычная ситуация, когда, оплатив заказ в магазине или через Интернет, покупатель приходит к пункту выдачи, предъявляет квитанцию и хочет получить заказ. Соответственно, нам нужен робот, который получил бы от клиента список его покупок, взял бы нужные товары со стеллажей на складе и выдал бы их клиенту. Посмотрим, что должен уметь робот, осуществляющий такую деятельность. Во-первых, он должен уметь считать список заказанных товаров. Во-вторых, определить, где они находятся, и построить необходимую траекторию движения. В-третьих, осуществить необходимые перемещения в соответствии с этими траекториями. В-четвертых, суметь взять товар со стеллажа и положить его на стол выдачи заказов. При этом, если при анализе задачи мы понимаем, что эффективнее собрать весь заказ и привезти его сразу, чем возить к столу выдачи по одному товару, то, в-пятых, робот должен иметь «на борту» какой-то контейнер, куда он может эти товары собрать. Работая с этим перечнем умений, мы понимаем, какие средства нужны для выполнения соответствующей деятельности. Так, по пунктам выше. Если список заказанных товаров задан штрих-кодом, то робот должен иметь устройство для считывания штрих-кодов. Для определения положения товаров на стеллажах нужен доступ к базе размещения товаров, или она должна быть «на борту». Также нужен инструментарий для определения текущего положения робота и построения траектории. Для выполнения перемещений робот должен иметь соответствующие двигатели. Чтобы взять и положить товар, робот должен иметь соответствующий манипулятор. И наконец, некий контейнер для сбора и хранения товаров до выдачи. Из рассмотрения этого перечня у нас складывается концепция предлагаемого мобильного робота как некоего манипулятора на подвижном шасси, оснащенного считывателем штрих-кода, комплектом датчиков для определения своего местоположения, а также соответствующим управляющим устройством. Мы также можем описать, как будет действовать данный робот, используя указанные средства для решения поставленной задачи. Сначала с помощью считывателя штрих-кода робот определит перечень заказанных товаров, затем с помощью бортового вычислительного устройства он определит положение нужных товаров на стеллажах и выстроит траекторию движения. С помощью датчиков робот определяет свое текущее местоположение и с помощью подвижного шасси движется по нужной траектории. Достигнув требуемого стеллажа с товаров, робот манипулятором берет нужный товар и помещает его в контейнер, затем перемещается к следующему товару и забирает его тоже. Собрав все товары заказа, робот перемещается к столу выдачи и выгружает товары на него, после чего переходит к ожиданию следующего заказа. Таким образом, мы получили концепцию, которую после необходимой более детальной проработки можно согласовать с заказчиком. Концепция может быть реализована в разных вариантах. Так, в примере выше шасси может быть трехколесным, четырехколесным, шестиколесным, гусеничным и так далее. А вычислительное устройство может иметь базу данных по складу «на борту», а может обращаться к облачному хранилищу информации. Такие варианты реализации концепций обычно называют концептами. Важно, что концепция описывает не только образ системы, которую нужно создать, но и рамки, какие-то границы этого проекта. Скажем, в случае обращения упомянутого робота к облачному хранилищу информации, в концепции может быть оговорено, что разработка данного хранилища не является частью данного проекта, что для заказчика, к примеру, может быть совсем не очевидно. Ранее в курсе мы обсуждали структуру деятельности как последовательность следующих шагов: потребность, мотив, цель, средства, действие, результат. И в этом смысле концепция будет соответствовать заявлению цели, представлению о том ожидаемом результате, ради которого деятельность совершается. В разработке программного обеспечения аналогом концепции обычно является Документ об образе и границах (Vision and scope document). В некоторых организациях с этой же целью создают Устав проекта или Положение о бизнес-задачах. Концепция часто представляется и иллюстрируется контекстной диаграммой, которая показывает взаимосвязи системы с внешними объектами, и системные интерфейсы. Владельцем концепции обычно считается тот, кто финансирует проект или несет аналогичную ответственность, если, конечно, разработка концепции не является самостоятельной работой, например, на аутсорсе. Если вы выступаете в роли аналитика в проекте, то именно в этом качестве и с этим лицом вы будете согласовывать и дорабатывать концепцию или Документ об образе и границах проекта. Вот тут показан возможный шаблон концепции. Шаблоны стандартизируют структуру документов, создаваемых проектными командами каждой организации. И как в случае с любым шаблоном, его можно изменить в соответствии со спецификой конкретного проекта. Такой шаблон обычно содержит раздел бизнес-требований, концепций решения, масштабы и ограничения проекта, бизнес-контекст. Подробнее практику формирования концепции мы рассмотрим в следующем модуле, а сейчас остановимся на описании. Карл Вигерс приводит такие наборы ключевых слов для использования в описании компетенции: для (и мы говорим о целовой аудитории покупателей); который (и мы говорим о тех потребностях и возможностях); эта или этот (указываем имя продукта) и является (как категория продукта); который (указываем ключевое преимущество или основную причину для покупки и использования продукта); в отличие от (отмечаем, чем данный продукт отличается от основного конкурирующего); наш продукт (показываем преимущества нового продукта). Посмотрим, как может выглядеть описание концепции для приведенного выше примера по использованию такого подхода. Для клиентов, которым нужно получить заказанные товары в пункте выдачи, данный робот станет автоматической обслуживающей системой, которая обеспечивает формирование и выдачу заказа со склада. С помощью своего считывателя штрих-кода робот будет определять перечень заказанных товаров. С помощью бортового вычислительного устройства определит положение нужных товаров на стеллажах и выстроит траекторию движения. С помощью датчиков робот определит свое текущее положение и с помощью подвижного шасси переместится по нужной траектории к стеллажу с требуемым товаром. Там робот манипулятором возьмет нужный товар и поместит его в контейнер. Собрав все товары заказа, робот доставит заказ к столу выдачи, после чего перейдет к ожиданию следующего заказа. Это робот, который сэкономит компании 25 % затрат на обслуживание клиентов в первый год работы, позволив сократить число служащих на складе. В отличие от действующей сейчас системы выдачи заказов, обрабатываемых вручную, наш продукт обеспечит более высокое качество обслуживания клиентов при более низких затратах. Концепция обеспечивает единство конструктивных и поведенческих решений в системе. С другой стороны, концепция обеспечивает единство замысла разработчика и путей реализации. Принятая концепция будет определять последующий выбор подходов к реализации проекта, включая используемый инструментарий и методологии. Поэтому концепция и архитектура системы оказываются непосредственно взаимосвязаны, а свобода идей на этой стадии сочетается с техническим аудитом, контролирующим возможность их реализации. Итак, концепция — это то, как видит разработчик будущую систему, ее внешний облик и поведение. Концепция дает представление о том ожидаемом результате, ради которого создается система, и том способе, каким он будет достигаться. На этом этапе система пока является «черным ящиком», и мы не рассматриваем пока ее внутреннее устройство. Однако мы должны быть уверенными, что сможем сделать то, что пообещаем заказчику реально, поэтому сами уже должны внутреннее устройство в основном представлять. И в этом смысле разработка концепции прямо связана с разработкой архитектуры системы, о чем мы поговорим в следующем видео.
