Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Важность функциональных рассмотрений целевой системы
Частой ошибкой в разработке систем является игнорирование явного моделирования функциональной структуры системы, её принципиальных схем. В электронике и электрике, а также работе с непрерывными производствами (химические и энергетические предприятия) принято рисовать принципиальные схемы, на которых явно обозначаются компоненты, т.е. функциональные элементы системы. Но эта практика существует отнюдь не для всех видов систем. Так, в программной инженерии функциональных диаграмм в большинстве команд рисовать не принято. То есть программисты думают о функциональности своих программ, но принципиальных схем их работы программисты почему-то не делают, они держат обрывки этих принципиальных схем исключительно в уме – и поэтому в этих схемах нельзя найти пробелы, ошибки, поговорить о функционировании их систем с коллегами. В передовых кругах разработчиков софта это не так, и функциональные диаграммы документируются, но пока это ещё не общепринятая практика. Неработа с функциональностью – типичная ошибка объединившихся в проекте инженеров и менеджеров-маркетологов (проект кто-то принёс! значит маркетологи были!). «Техпредприниматели» или корпоративные менеджеры беседуют с внешними стейкхолдерами и выясняют обычно их потребности, требованиями не занимается вообще никто, а инженер потом создаёт модульную конструкцию «на вырост», соединяя через типовые интерфейсы типовые конструктивные элементы в надежде, что через восемь итераций всё как-то само-собой с функциональностью утрясётся, и проект получится. Ошибку такого рода в архитектурных диаграммах легко найти: в них при такой ошибке отсутствия функциональности нет отражения предметной области, для которой целевая система осуществляет сервис. Например, в архитектуре информационной системы магазина появляется просто «база данных», а не «цены товарных позиций, правила предоставления скидок, история покупок». Понятно, что всё это должно где-то храниться, но не факт, что в нарисованной программистом на первой же его диаграмме «базе данных» (часть, например, может браться на API какого-то сервиса, а правила представления скидок могут храниться в настроечном файле или вообще оказаться искусственной нейронной сетью), и не факт, что даже «база данных» будет одна. Объяснить программисту про необходимость рисовать функциональные диаграммы в составе архитектуры трудно, ибо он мыслит модулями, которые по его мнению абсолютно универсальны и поддержат «любую функцию». Любую-любую? Нет, конечно. Но разочарование будет не в начале проекта, а поближе к концу – когда окажется, что универсальных прикладных софтверных систем не бывает, так же, как и любых универсальных систем других.
Вот пример, иллюстрирующий происходящее у программистов на примере более понятной работе с «железной» системой – но того же класса, что и программы: кажущейся суперуниверсальной по форме, но весьма конкретной и уникальной по содержанию. У нас стоит задача тонкого химического синтеза диметилфторидметилхлорпентилбензолтитана для задач фармацевтической промышленности. Известно, что его трудно синтезировать, и при синтезе получается много примесей, от которых потом люди умирают. Поэтому мы предложим аптекам такой чистый продукт, от которого люди не будут умирать, а маркетинг будет оригинальный: через уборщиц медицинских учреждений, которые будут подбрасывать наши буклеты врачам, а также задушевно беседовать с пациентами в очередях ко врачам. Для того, чтобы получить чистый диметилфторидметилхлорпентилбензолтитан, мы будем использовать четыре стальных реактора, соединённых трубами диаметром 56мм, последняя труба с тефлоновым покрытием. Второй реактор закажем внешним контракторам. Чистоту получающегося диметилфторидметилхлорпентилбензолтитана будем отслеживать при помощи независимой экспертной службы. Все четыре реактора должны будут пройти проверку на выдерживание давления в 156 атмосфер. В этом описании нет никаких идей, какие именно примеси имеют максимально вредный эффект (а это архитектурное требование, самое важное!), как получить чистый именно от этих примесей (а не от любых – безвредные ведь не мешают) диметилфторидметилхлорпентилбензолтитан, какие нужны исходные вещества и доступны ли они, или их тоже нужно синтезировать в рамках проекта, далее химические реакции, начиная с доступных веществ – т.е. подробное разбирательство того, что происходит в реакторах.
Теперь представим инженера, которому маркетологи говорят, что ему нужно будет решить задачу химического синтеза, но непонятно ещё какую. И они когда-нибудь потом, но вот не прямо сейчас наймут химика, который всё уточнит. Инженер соглашается и берётся за дело: ему сразу понятно, что нужны будут реакторы и трубы. Реакторов непонятно сколько, ибо непонятно, сколько там в синтезе будет химических реакций. Поэтому лучше бы этих реакторов было побольше. Он выбирает цифру 4, как «не очень мало, но и ещё не очень дорого», догадывается, что в этом синтезе может быть хитрая эндотермическая реакция, но сам он для такой реакции реактор вряд ли спроектирует. Так что этот «хитрый реактор» он отдаёт проектировать внешним контракторам и честно об этом пишет. Хотя контракторы и спрашивали, что там с массами и температурой, ответ пока никто не может дать, поэтому контракт планируется без разговора о требованиях – но контрактор, разумеется, от заказа не отказывается и говорит, что «сделаю любой реактор». Слово «любой» никого не отпугивает, ибо нет химика, который бы сказал, что же будет в этом реакторе происходить. Есть только инженеры по железу, хорошо разбирающиеся в марках стали и сварке, и маркетологи, беседующие с врачами и фармацевтами. В случае железа реактора и труб всё тут очевидно: вероятность выпуска чистого диметилфторидметилхлорпентилбензолтитана в этой ситуации равна нулю. Но в случае софта почему-то кажется, что задачу так решать можно. И вот пишут про «сервера» и «базы данных», но каким образом там будет происходить обработка какой информации, и с чего бы эта обработка вдруг оказалась даже не лучше конкурентов, а вообще возможной, этого вопроса не возникает. Ровно как в предыдущей задаче, где нет химика, есть только сварщики и спецы по корпусам высокого давления. Они точно сделают софтверный «универсальный реактор», но вот что там с чистотой «информационного вещества» или даже просто запуском нужной «информационной реакции» (слова «обработка информации» или «расчёт» так и пишутся, без малейших уточнений, какой именно), и получить исходные данные (или исходную информацию? данные! ибо информация что-то означает, а данные тут как сырьё – можно игнорировать их содержание) – это не к ним. А поскольку в проекте получения чистого диметилфторидметилхлорпентилбензолтитана химика пока нет, про химию разговор поддержать некому, равно как сообразить, как же эта химия влияет на примеси, а примеси на здоровье пациента. За разговорами про реакторы и трубы к этому моменту уже можно забыть, что задачка про медицину, потребности тут в здоровье пациента. А делать приходится железную конструкцию. И нужно протянуть строгую логическую цепочку от одного к другому – через химические реакции, которые описывают функциональную структуру целевой системы, через ведущие к появлению вредных примесей отклонения от режимов проведения этих реакций. При этом предметная область функциональных (химических) рассмотрений – по факту клиентская, а итоговые модульные (труб и реакторов) рассмотрения – предметная область разработчика-контрактора. Увы, с первого раза получить функциональную диаграмму, в которой рассказывается о том, что содержательно происходит с клиентской информацией в корпоративных информационных системах, обычно не удаётся. Нужна пара-тройка итераций, но зато после её получения уже вполне осмысленно и существенно корректируется уже модульная диаграмма (в случае нашего «железного примера» – изменяется число реакторов, убираются лишние трубы, проводятся дополнительные исследования по наличию на рынке дешёвых датчиков чистоты продукта, находится контрактор, который пишет управляющий софт для закрытия-открытия задвижек на реакторах, чтобы управлять ходом синтеза на основе показаний датчиков и т.д.).
Потом нужно будет рассмотреть и модули, и размещения. Но это всё потом. Сначала же нужно разобраться с функционированием: что происходит в тот момент, когда система работает/функционирует (слово «функционирует» тут не случайно!), а не когда её собирают из размещаемых где-то частей-модулей. Это рассуждение про необходимость начального рассмотрения функций приложимо к любым создаваемым людьми конструкциям: сначала нужно обсудить подробно, зачем эти конструкции и как они будут работать, а уже потом рассматривать, из чего они будут собраны. Например, можно рассмотреть применение этих рассуждений к танцам. Просто махание ногами и руками (с запасом! Побольше махов, и сами махи пошире!) никого не устроит. Каждый мах должен быть понятен, зачем – какая там эмоция, что этим махом хотят сказать, что продемонстрировать. Тогда и мах будет подобран соответствующий (резкий, плавный, объёмный или короткий, рукой или ногой – ровно под необходимую функцию, а не «стандартный»). Мыслить только про конструкции нельзя. Отсутствие мышления о функциональности нужно как-то осознавать и исправлять. А это отсутствие мышления о функциональности заметно только в случае наличия системного мышления – оно позволяет заметить то, о чём вы забыли подумать, управляет вашим вниманием.
Предпринятия
В системах из людей модули – это прежде всего сами люди, с их аудио, зрительным, тактильным и прочими интерфейсами. Обратите внимание, что функции людей даже не делается попыток обсуждать, равно как и смысл и содержание информации или изменений окружающей среды, которое поступает к людям и уходит от них через интерфейсы. Следующий уровень – это команды и прочие организационные звенья (в предприятиях – подразделения), получаемые из организованных (то есть с понятными полномочиями по использованию труда друг друга и других ресурсов) людей. Сервисы команд, сервисы подразделений, оказываемые ими на их интерфейсах, обсуждение интерфейсов-каналов для общения с ними являются типичным предметом обсуждения, сервисы пытаются стандартизовать. Предприятие буквально составлено, собрано, сделано из своих подразделений – это конструктивные, а не функциональные подразделения. Из обсуждения организационной диаграммы не скажешь, как работает предприятия, какие функции подразделений по отношению друг ко другу, и именование оргзвеньев это часто отражает. Цех №5, палата №6 – простые номера в именах, из которых не следует функций, являются типичными указателями на конструктивное рассмотрение. Функций, исполняемых конструктивными элементами предприятия, может быть множество, и самых неожиданных. С другой стороны, если «подразделение переезжает в другое здание», то это описание связи ипостасей конструктивной и размещения. «Подразделение будет выполнять новые виды деятельности» – это обсуждение связи функциональной и конструктивной ипостасей подразделения.
|
|||||||
Последнее изменение этой страницы: 2021-01-14; просмотров: 79; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.129.23.30 (0.01 с.) |