Что отражает описание системы

Описание системы

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

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

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

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

,

где — компоненты системы (элементы, подмножества), — множество отношений, заданных на этом множестве – математическая структура этой системы.

Использование для описания систем теоретико-множественного языка обусловлено не только лаконичностью записи, но и рядом более существенных причин. Первая из них заключается в преследуемых целях. Чаще всего описание систем используется не для того, чтобы показать, что они из себя представляют в целом, а для исследования их свойств, которые обусловлены определенными взаимосвязями (отношениями) между компонентами системы. Большинство выражаемых словесно фактов представляют собой описание лингвистических отношений, основу которых составляют термы и функторы. Вполне естественно, что их формализмом выступают теоретико-множественные отношения (термы – элементы, функторы – отношения).

На практике такого рода структуры приобретают более «приземленный», иногда называемый «рабочий» вид. Так в работе [41] приводится следующий вид обобщенного формализованного описания системы

– компоненты системы;

– свойства системы;

– связи между компонентами системы;

– цели системы;

– лицо, представляющее объект в виде системы для исследования или принятия решений (для искусственных систем);

– язык наблюдателя, описывающего систему.

Такого рода квазиматематическое описание целесообразно применять в целях некоторой базовой (исходной) структуризации. Можно рекомендовать его реализацию в виде следующей последовательности этапов:

1. Вначале важно установить границы системы, поэтому вначале производят разделение системы и окружающей ее среды. Здесь следует помнить, что в системе действуют законы, вообще говоря, отличные (хоть в чем-то) от законов окружающей ее среды;

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

3.Осуществляется содержательное описание системы. В первую очередь это описание выполняемых ею функций, причем функционирование системы должно представляться как нечто целое.

4.Затем формируется внутренняя структура системы, в результате чего должны будут выделены элементы система и связи между ними.

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

Источник

Как создать шаблон описания системы и начать его использовать

Когда в IT-компании работают 6 человек, которые пилят одну систему и обсуждают её в кулуарах, описание системы и документация кажутся ненужными. Но когда систем уже более 100, без описания не обойтись. Ведь непродуманное изменение UI может остановить создание заказов. Мы создали единый шаблон описания системы, чтобы документация стала максимально полезной.

Меня зовут Александра Камзеева, я работаю системным аналитиком уже 9 лет, из них 3.5 года в Lamoda. Я много читаю, анализирую текущую документацию и создаю новую. В работе я всегда структурирую информацию и делаю её максимально удобной.

Плюсы хорошего описания системы таковы:

Что такое шаблон и зачем он нужен

Для начала я опишу свое понимание шаблона. Давайте представим, что мне надо найти маленькую машинку в неприбранной комнате. Не факт, что я справлюсь. Зато могу случайно наступить на детальку Лего.

А теперь представим, что все игрушки разложены по своим местам и отсортированы. Я заранее вижу, в каком ящике лежат все машинки, найду нужную быстрее, проще и не буду тратить нервы на это.

Аналогично с документацией. Шаблон – и есть такой порядок. Мы сделали основу для описания системы, которую может использовать любая команда.

В каких условиях мы работаем с документацией

В Lamoda есть более 100 систем, которые автоматизируют доставку заказов, контакт-центр, склад, фотостудию, другие операционные и бизнес-процессы. Разработкой и поддержкой занимаются больше 300 инженеров. Любому из них может понадобиться описание любой из этих 100 систем.

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

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

Ниже я расскажу несколько случаев, когда запутанная документация или ее отсутствие приводили к проблемам.

Просто добавь две кнопки

Первая проблема, которая подтолкнула нас к созданию шаблона – у нас не было описания некоторых систем, что приводило к сбоям и доработкам.

У нас был проект Self Order Management (SOM). Мы решили добавить в личный кабинет клиента две кнопки: «Перенос даты доставки» и «Отмена заказа». До этого клиент мог отменить или перенести заказ только звонком в контакт-центр. Понятно, что у некоторых покупателей не было времени или желания общаться с оператором. В итоге торговый представитель мог привезти ненужный заказ или не застать клиента дома. В таких случаях Lamoda несет издержки. Проект был нужный и важный.

Казалось бы, добавить две кнопочки! На самом деле, за ними скрывалось много логики в четырех системах. Изменение заказа проходит через систему процессинга – огромный монолит, где можно тронуть что-то в одном месте, а выстрелит в другом. К сожалению, тонкости её работы не были описаны в документации, на это не обратили внимания во время проектирования проекта. После релиза кнопки работали не так, как ожидалось, и его откатили обратно. В итоге вместо двух человеко-месяцев на этот проект ушло полгода.

Конечно, мы получили такой результат не только из-за отсутствия документации. Но если бы у нас существовало понятное описание процессов отмены и переноса заказа, то, возможно, исход был бы другим.

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

В этом случае не получилось сделать онбординг легче. Такая документация не помогала передать знания коллегам, которые не сталкивались с нашей системой ранее.

Проблема чистого листа

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

Как мы создавали шаблон и что получилось

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

Сначала мы определили признаки хорошего шаблона:

В разделе проектов и фич лежали спецификации для разработки проектов. В разделах Development и QA находилась специфическая информация для разработки и тестировщиков. В разделе инцидентов были описаны происшествия, которые возникали в системе, и их решения.

Мы поделились идеей шаблона с другими коллегами на неформальных встречах (обеды на кухне, стенд-апы, команды-соседи, с которыми периодически разговариваешь) и создали рабочую группу добровольцев. Ими были представители разных компетенций: два менеджера, три техлида и два тестировщика. Они добавили в шаблон следующие разделы:

Далее мы проверили шаблон описания систем с коллегами с широкой компетенцией: руководителями IT-подразделений, опытными техлидами и тестлидами больших интеграционных проектов. В итоге они добавили еще немного полезных разделов:

Проверяем качество шаблона

Полученный документ мы проверили на наше определение хорошего шаблона в Lamoda:

Самые полезные разделы шаблона

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

Описание основных процессов системы. Да, кажется очевидным, что этот раздел нужен. Но почему-то он не всегда существует, как было у нас на примере с кнопочками отмены и переноса заказа. Если бы мы заранее описали процессы отмены и переноса заказа, уменьшился бы риск провала проекта.

Чек-листы – раздел, который напоминает о самом важном в регулярном процессе. Например, у нас есть “Чек-лист подключения нового метода оплаты” в описании системы управления методами оплаты. Там прописано, что мы должны согласовывать добавление или изменение метода оплаты с бухгалтерией, с контакт-центром, с доставкой и с другими бизнес-подразделениями.

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

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

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

Как я начала использовать шаблон в своей системе

Вторая кучка – это нужное, но неактуальное. Мы помечали страницы как неактуальные, заводили задачу в Jira и дальше актуализировали эту информацию в соответствии с нашим бэклогом.

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

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

За 6 часов встреч мы получили отличный результат. Из хаоса у нас образовались структура и порядок. Теперь в ней можно понять, где найти описание процессов, информацию об архитектуре и об инцидентах. И что немаловажно, у нас появилась домашняя страница. Здесь было написано, зачем нужна система процессинга заказа и кто её стейкхолдер.

Наша большая система участвует почти во всех бизнес-направлениях. Но собственного стейкхолдера у нас раньше не было. Пока мы делали home page, обсудили с CTO, с кем согласовывать изменения системы. Таким образом, определился коллега, который приоритезировал доработки. Теперь это выглядит забавным фактом, что создание домашней страницы привело к появлению стейкхолдера.

Как мы распространяли шаблон

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

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

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

Обратная связь о шаблоне

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

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

Мы в Lamoda любим обмениваться знаниями. У нас есть большие интеграционные проекты, которые мотивируют на это. Мы высылаем ссылки на актуальное описание систем, и коллеги получают нужную информацию без дополнительных вопросов и так загруженным техлидам.

Спустя 2 года после создания шаблона я опросила коллег и получила у большинства хорошую обратную связь. Они используют шаблон, редактируя структуру так, как им нужно.

Но есть и люди, считающие, что нам не нужна документация и шаблон. В основном, так рассуждают команды тех систем, в которых сейчас нет острой необходимости что-то документировать.

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

Я думаю, перед началом большого проекта наша культура и набитые шишки напомнят о необходимости документировать основные процессы, и они поменяют мнение.

Советы себе и желающим повторить наш путь

Источник

Что отражает описание системы

Главное отличие подхода к изучению любого объекта как системы состоит в том, что исследователь не ограничивается рассмотрением и описанием только вещественной и энергетической его сторон, но и (прежде всего) проводит исследование его информационных аспектов: целей, информационных потоков, управления, организации и т.д. Создание новых и совершенствование существующих объектов (систем) зависят от решения вопросов, позволяющих анализировать имеющуюся информацию, отсеивать ее избыточную часть, выделять основную, производить оценку и обеспечивать формирование альтернатив для принятия решений.

Любая более или менее сложная экономическая система в процессе своего существования потребляет и вырабатывает большой объем информации. Более того, сегодня можно однозначно утверждать, что объем информации, необходимый для нормального функционирования экономических объектов, и требования к скорости восприятия информации экономической системой неуклонно возрастает. Предприятия производят обмен информацией как внутри себя, так и во вне (в «горизонтальном» и «вертикальном» направлении). Ни для кого не секрет, что в рамках достаточно крупного промышленного предприятия годовой оборот документированных данных может достигать двухмиллионного рубежа и содержать совершенно фантастическую цифру показателей — более ста миллионов единиц. Однако сразу отметим, что количество данных в отчетах не адекватно содержащейся в них информации. Обычно под информацией понимают только те данные, которые способствуют решению задач, поставленных перед исследователем. Из литературных источников известно, что только 10-30% данных, циркулирующих в экономических системах, непосредственно используются при решении задач. Остальные данные не используются вообще.

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

Информационное описание должно давать представление об организации и управлении системой.

Термин информация имеет несколько значений:

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

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

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

Физически информация определяет предсказуемость свойств и поведения объекта во времени. Чем выше уровень организации (больше информации), тем менее подвержен объект действию среды.

Возможно, что формы организации взаимно преобразуются в строгих количественных соотношениях, выражаемых при помощи информации. Доказать это можно только экспериментально (как и для количественных форм движения, т.е. энергетических эквивалентов). Количество и ценность информации — взаимодополняющие категории. Можно говорить о количестве ценной информации применительно к заданной цели подобно тому, как мы говорим о количестве ценного вида энергии или вещества.

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

Организованность, упорядоченность системы — способность предопределять свою перспективу, свое будущее. Разумеется, перспектива системы зависит и от среды. Но ведь и способность системы совершать работу зависит от среды, что не влияет на определение энергии.

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

Таким образом, меру организованности можно понимать как потенциальную меру предсказуемости будущего системы, количественную характеристику возможности предвидения состояния (поведения) системы. Информация об организации системы — это количественная характеристика возможности предвидения ее состояния (поведения) на соответствующем уровне детализации системы. Информация о среде — количественная характеристика возможности предвидения воздействия среды. Информация об организации системы составляет часть ее внутренней информации.

В теории информации рассматривают синтаксический, семантический и прагматический аспекты информации.

На синтаксическом уровне рассматриваются внутренние свойства текста (структура), т.е. отношение между знаками (алфавита), отражающие структуру данной знаковой системы.

На семантическом уровне анализируются отношения между знаками и обозначаемыми ими предметами, действиями, качествами, т.е. смысловое содержанием текста.

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

Часто ценность информации выражается через приращение вероятности достижения цели: если до получения информации вероятность достижения цели была p₀, а после получения информации — p₁, то величина ценности информации определяется по формуле Харкевича:

Очевидно, что она может быть и отрицательной, если p₁

Источник