Декомпозиция задач – Декомпозиция цели — стандартный инструмент руководителя

Декомпозиция цели — стандартный инструмент руководителя

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

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

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

Первый — декомпозиция цели. Подходит для сложных и многоэтапных задач.

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

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

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

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

Не бойтесь потратить на это время. Это помогает последовательно прийти к итоговому результату, верному ответу.

Большие задачи очень часто обладают сложной структурой. А потому их можно разделить на несколько более мелких этапов.

Определите, какие знания, навыки необходимы для преодоления каждого этапа.

Ориентироваться здесь нужно не на срочность, а на важность этапов решения задач. Если срочность превалирует над важностью, то теряется инициатива, возможность эффективно решить проблему.

Далее следует расставить этапы задачи в порядке  их выполнения.

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

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

Далее идет распределение этапов между исполнителями согласно с их способностями.

Нужно выяснить, что конкретно и кто именно будет делать. Ре­шение вопроса, кто войдет в команду  —  один из важнейших пунктов в процессе достижения основной цели.

Поручите стоящие перед вами задачи настоящим специалистам, наделите их не­обходимыми полномочиями.

Не помешает поддержать чувство коллективизма.

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

Командный дух здесь — цемент, который все скрепляет.

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

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

Эти статьи блога Вам должны быть интересны:

berichnow.ru

это что? Декомпозиция целей. Значение слова «декомпозиция»

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

Определение

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

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

Особенности

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

1) Всегда должна быть соблюдена уровневая система.

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

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

Руководствуясь простой формальной алгеброй и логикой можно также строить «деревья И» и «деревья ИЛИ».

2) Расчленение целого на части должно происходить только по одному признаку.

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

В качестве признака можно использовать также временные рамки (сроки), предметные характеристики, структурные признаки, технологические характеристики и другие.

3) Все подсистемы декомпозиции должны раскрывать суть системы.

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

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

4) Глубина декомпозиционной проработки должна быть определена на начальном этапе.

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

Классификация

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

Как правило, все перечисленные процессы взаимосвязаны и в целом представляют полную декомпозиционную структуру.

Декомпозиция целей

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

Анализ действий

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

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

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

Классический прием

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

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

Применение в бизнесе

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

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

Пример декомпозиции

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

Далее следуют подразделы:

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

Разделы и подразделы проектной и рабочей документации – это подзадачи третьего уровня.

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

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

Коротко о главном

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

fb.ru

Достижение цели: декомпозиция по принципам SMART

Доброго времени суток, читатели блога Твое Решение!
Поздравляю вас с новым 2017 годом!

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

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

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

В тайм-менеджменте большие задачи и цели часто называют «слонами», а процесс ее декомпозиции — «съесть слона по кусочкам» или «нарезка слона».

Наиболее удобным инструментом для проведения декомпозиции цели являются интеллект-карты. Еще их называют ментальные карты или mind-maps. Я пользуюсь бесплатной программой XMind.  Хотя в принципе для проведения декомпозиции достаточно простого листа бумаги и ручки.

Итак, записываем нашу цель на листе бумаги или в программе и задаем себе два простых вопроса:

1. Что для этого необходимо сделать?
2. Могу ли я это сделать прямо сейчас?

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

Задаем себе второй вопрос: могу я выполнить это сейчас? Если да, то разбивка данной ветки окончена, если -нет, то снова задаем себе первый вопрос.
Дробим наши цели до тех пор, пока не получим конкретные выполнимые задачи — разовые или регулярные, выполнение которых займет от 15 минут до 1,5-2 часов.

В итоге может получиться следующий вариант декомпозиции цели

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

SMART:

S — конкретная, т.е постановка цели должна быть конкретна и ясна,

M — измеримая, т.е результат выполнения цели должен быть измеримым,

A — ориентированная на конкретные действия,

R — реалистичная, уместная, полезная и ориентированная на конкретные результаты,

T — на определенный период, своевременная, отслеживаемая. Срок выполнения цели должен быть определен конкретной датой или периодом.

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

1. формулируем намерение (S)
2. определяем критерии или показатели, по которым в будущем можно будет оценить достижение цели (M)
3. формулируем достижения, т.е конкретные параметры критериев или показателей (A)
4. определяем перечень задач (дело, разовое или регулярное, выполнение которого займет от 15 минут до 1,5-2 ч) для достижения конкретных параметров (R)
5. определяем временной ресурс (T)
6. запускаем цикл контроля, выстраивая систему измерения ключевых показателей.

Наглядно это выглядит следующим образом:

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

 

Увеличенный вариант изображения можно скачать здесь.

Предложенная декомпозиция цели — улучшить свое здоровье- легла в основу моего личного проекта «Затачиваем пилу», который я реализую уже не первый год.

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

1. Четкий пошаговый план реализации цели от квартального плана до чек-листа на день

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

2. Организация эффективного контроля достижения цели

   Декомпозиция с использованием принципов SMART выстраивает взаимосвязь показателей целей и выполнения задач, задает критерии или показатели достижения цели

3. Расчет времени и прочих ресурсов, необходимых для достижения цели

   Четко определяет какой объем выполненных задач и какие конкретные показатели должны быть достигнуты к конкретному времени

4. Оценка реалистичности цели и ее корректировка

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

   Часто мы переоцениваем то, что можем сделать за день и недооцениваем то, что можем сделать за год

Надеюсь, предложенный метод декомпозиции цели по принципам SMART поможет вам в достижении своих целей. Рекомендую также для постановки и достижения своих целей воспользоваться сервисом Smart Progress.

Вспомните, какие обещания вы дали себе в Новый Год под бой курантов?

Самое время начать активные действия по их реализации. Превратите достижение цели в увлекательный процесс!

Начни прямо сейчас! И это будет ТВОЕ РЕШЕНИЕ!

Понравилась статья? Буду признательна, если поделитесь этой статьей в социальных сетях!

Подпишитесь на обновления блога, чтобы не упускать полезные знания!

Читайте еще:

tvoe-reshenie.com

Как workflow разработки влияет на декомпозицию задач / Блог компании Badoo / Хабр

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

Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.

Почему это важно?

Необходимо помнить о том, что процесс разработки – это не только непосредственно сеанс написания кода. Когда мы говорим о разработке, я призываю смотреть на весь процесс целиком, начиная от постановки задачи и заканчивая стабильной работой фичи у наших пользователей. Если не брать в расчёт все этапы, которые предшествуют кодированию и следуют за ним, то очень легко можно попасть в ситуацию, когда все что-то делают, выполняют свои KPI, получают бонусы, а результат получается плачевный. Бизнес загибается, конкуренты «душат», но при этом все – молодцы.

Почему так происходит? Всё просто: человеческая психология заставляет людей смотреть на ситуации с точки зрения собственного комфорта. Разработчику не всегда хочется думать о том, что будет с кодом после его написания. Решил задачу – и хорошо. Его крайне редко это интересует (именно поэтому мы, айтишники, и работаем в этой отрасли – наша мотивация в основном держится на интересности задач), ведь в отношениях с людьми столько неопределённости. Гораздо более комфортно многие разработчики чувствуют себя, сидя за компьютером и сосредоточившись на решении своей собственной интересной задачи – блокчейнах с нейросетями – им совсем не хочется отвлекаться и думать о каких-то продакт-менеджерах, дедлайнах, пользователях, которые потом будут использовать их гениальное произведение (а то ещё и критиковать начнут!).

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

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

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

Хороший пример – написание юнит-тестов. Зачем мне тратить своё драгоценное время на написание тестов, если у нас есть тестировщики, которые потом и так всё протестируют? А затем, что юнит-тесты необходимы не только для облегчения процесса кодинга – они нужны также и на последующих этапах. И нужны как воздух: с ними процесс интеграции и проверки регрессии ускоряется в десятки, сотни раз, на них базируется пирамида автоматизации. И это даже если не брать в расчёт ускорение вашей собственной работы: ведь «потрогав» код в каком-то месте, вам самому нужно убедиться в том, что вы ненароком что-нибудь не сломали. И один из самых быстрых способов это сделать – прогнать юнит-тесты.

Workflow

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

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

Говоря о workflow разработки, многие, кто использует Git, сразу вспоминают (всуе) о некоем «стандартном git-flow», считая его идеальным, правильным, и часто внедряют его у себя. Даже на конференциях, где я выступал, рассказывая про workflow в Badoo, меня несколько раз спрашивали: «Зачем вы изобрели своё, почему не используете стандартный git-flow?» Давайте разбираться.

Во-первых, обычно, говоря про этот флоу, имеют в виду вот эту картинку. Я взял её из статьи Vincent Driessen “A successful Git branching model”, в которой описывается схема, довольно успешно работавшая на нескольких его проектах (было это в далёком 2010 году).

Сегодня некоторые крупные игроки на рынке хостинга кода вообще предлагают свой флоу, критикуя «стандартный git-flow» и описывая его недостатки; дают свои схемы, рекомендации, приёмы.

Если же поискать на git-scm.com (хорошо бы вообще погуглить), то с удивлением можно обнаружить, что никакого рекомендованного (и уж тем более «стандартного») workflow не существует. Всё потому, что Git – это, по сути, фреймворк для систем хранения версий кода, и то, как вы организуете это самое хранение и совместную работу, зависит только от вас самих. Всегда нужно помнить о том, что, если какой-то флоу «взлетел» на каких-то проектах, это вовсе не означает, что вам он тоже полностью подойдёт.

Во-вторых, даже у нас в компании у разных команд разный флоу. Флоу разработки серверного кода на PHP, демонов на С/ С++ и Go, флоу мобильных команд – они разные. И пришли мы к этому не сразу: пробовали разные варианты, прежде чем остановиться на чём-то конкретном. К слову, отличается в этих командах не только workflow, но ещё и методологии тестирования, постановки задач, релизы и сам принцип доставки: то, что поставляется на ваши личные серверы и на компьютеры (смартфоны) конечных пользователей, не может разрабатываться одинаково по определению.

В-третьих, даже принятый workflow является скорее рекомендацией, чем непререкаемым правилом. Задачи у бизнеса бывают разные, и хорошо, если вам удалось выбрать процесс, покрывающий 95% случаев. Если же ваша текущая задача не вписывается в выбранный флоу, имеет смысл посмотреть на ситуацию с прагматической точки зрения: если правила мешают вам сделать эффективно, к чёрту такие правила! Но обязательно посоветуйтесь с вашим менеджером перед принятием окончательного решения – иначе может начаться бардак. Вы можете банально не учесть какие-то важные моменты, которые известны вашему руководителю. А, возможно, всё пойдёт как по маслу – и вы сумеете изменить существующие правила так, что это приведёт к прогрессу и станет залогом роста для всех.

Если всё так сложно, да ещё и флоу – это не догма, а всего лишь рекомендация, то почему бы не использовать одну ветку для всего: Master для Git или Trunk для SVN? Зачем усложнять?

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

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

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

Feature branches

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

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

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

Ещё опаснее конфликты, связанные с логикой кода, когда SCM сливает код без проблем (ведь по строкам в файлах конфликтов нет), но из-за изоляции разработки какие-то общие методы и функции в коде изменили своё поведение или вообще удалены из кода. В компилируемых языках проблема, как может показаться, стоит менее остро – компилятор валидирует код. Но ситуации, когда сигнатуры методов не поменялись, а логика изменилась, никто не отменял. Такие проблемы сложно обнаруживать, и они ещё более отдаляют счастливый релиз и заставляют перетестировать код много раз после каждого слияния. А когда разработчиков много, кода много, файлов много и конфликтов много, всё превращается в сущий ад, ибо пока мы исправляли код и перепроверяли его, основная версия кода уже ушла далеко вперёд, и надо всё повторять заново. Вы всё ещё не верите в юнит-тесты? Хе-хе-хе!

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

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

Параллельная работа

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

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

Если цикл релизов быстрый (несколько раз в день вы выкладываетесь на свои серверы), то вполне можно сделать фичи зависимыми друг от друга по стадиям готовности. В примере с Петей и Васей выше создаём не две задачи, а три. Соответственно, первая звучит как «меняем общий метод так, чтобы он работал в двух вариантах» (или заводим новый метод для Пети), а две другие задачи – это задачи Васи и Пети, которые могут начать работу после завершения первой задачи, не пересекаясь и не мешая друг другу.

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

В этом случае можно использовать промежуточную ветку, общую для нескольких разработчиков, но ещё недостаточно стабильную, чтобы быть выложенной на продакшн (Master или Trunk). В нашем флоу для мобильных приложений такая ветка называется Dev, на схеме Vincent Driessen она называется develop.

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

Тут вы можете заметить, что можно ведь тестировать только один раз – после слияния. Зачем тестировать до него, в отдельной ветке? Верно, можно. Но, если задача в ветке не работает или ломает логику, этот неработоспособный код попадёт в общее хранилище и мало того, что помешает коллегам работать над своими задачами, ломая какие-то участки продукта, так ещё и может подложить бомбу, если на неправильных изменениях кто-то решит базировать новую логику. А когда таких задач десятки, очень тяжело искать источник проблемы и чинить баги.

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

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

Feature flags

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

А вот и будем! В этом нет ничего страшного. Подход, который может быть применён в этой ситуации, – feature flags. Он основан на внедрении в код «выключателей» (или «флагов»), которые включают/ выключают поведение определённой фичи. К слову, подход не зависит от вашей модели ветвления и может использоваться в любой из возможных.

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

Последней задачей в процессе разработки новой большой фичи в этом случае будет задача «включить фичефлаг» (или «добавить пункт меню» в примере с новой страницей).

Единственное, что нужно иметь в виду, используя фичефлаги, – это увеличение времени тестирования фичи. Ведь продукт необходимо протестировать два раза: с включённым и выключенным фичефлагом. Сэкономить тут можно, но действовать следует крайне деликатно: например, тестировать только то состояние флага, которое выкладывается пользователю. Тогда в процессе разработки (и выкладки по частям) задачи её тестировать вообще не будут, а проведут тестирование только во время проверки последней задачи «включить фичефлаг». Но тут надо быть готовым к тому, что интеграция кусков фичи после включения флага может пройти с проблемами: могут обнаружиться баги, допущенные на ранних этапах, и в этом случае поиск источника проблемы и устранение ошибок могут дорого стоить.

Заключение

Итак, при декомпозиции задач важно помнить три простых правила:

1. Задачи должны быть в виде логически завершённых кусочков кода.
2. Эти кусочки кода должны быть маленькими и должны максимально быстро попадать в общий код.
3. Эти кусочки должны разрабатываться параллельно и выкладываться независимо друг от друга.

Куда уж проще? Кстати, независимая выкладка, на мой взгляд, — самый важный критерий. Из него так или иначе проистекают остальные пункты.

Желаю удачи в разработке новых фич!

habr.com

Декомпозиция задач — Энциклопедия по экономике

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

Современные программные средства в большинстве используют специальные методы решения с разложением (декомпозицией) задачи на Р подзадач, например, метод декомпозиции Данцига-Вульфа. По этому методу каждый блок матрицы формируется и отлаживается автономно как отдельная подзадача с последующим объединением блоков общими ограничениями на этапе окончательного составления задачи. Такие задачи экономически интерпретируются как задачи многоуровневой иерархической структуры.  [c.139]

В иерархической структуре системы планирования и управления технологическими комплексами непрерывного действия (типа нефтеперерабатывающих и нефтехимических) выделяются уровни текущего планирования, календарного планирования, оперативного планирования и управления. Такая схема временной декомпозиции задачи управления порождается объективно существующей организационной иерархией и динамикой производства. Нефтеперерабатывающие комплексы и предприятия подразделяются на ряд технологических процессов, цехов или блоков, состоящих в свою очередь из технологических установок, агрегатов или производств, имеющих локальные органы управления, систему технике-экономических показателей и критериев, по которым оценивается эффективность их функционирования. Указанные составные элементы технологической сети связаны между собой большим числом материальных и энергетических потоков, рассматриваемых при формализации как внутренние связи предприятия. Кроме того, НПП и комплексы функционируют в тесной взаимосвязи с поставщиками сырья и полуфабрикатов, потребителями товарной продукции, вышестоящими организациями, определяющими, в конечном счете, внешние связи.  [c.10]

Временная декомпозиция задачи управления 10, 15 Время  [c.226]

Медницкий Ю.В. О декомпозиции задачи линейного программирования со  [c.264]

Декомпозиция задачи. С учетом всех ограничений опти-  [c.120]

При решении осуществляется декомпозиция задачи (5) на два  [c.158]

Если посмотреть на линейную диаграмму предварительного плана проекта-примера (см. рис. 3.24), то из нее видно, что в первую очередь целесообразно подвергнуть декомпозиции задачу 2 «Подготовка к ремонту квартиры», которая должна начать выполняться первой.  [c.218]

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

В соответствии с установленной последовательностью выполнения задач на следующем шаге целесообразно подвергнуть декомпозиции задачу с кодом  [c.231]

Метод сценариев необходим не только в экологической или социально-экономической области. Например, при разработке методологического, программного и информационного обеспечения анализа риска химико-технологических проектов необходимо составить детальный каталог сценариев аварий, связанных с утечками токсических химических веществ. Каждый из таких сценариев описывает аварию своего типа, со своим индивидуальным происхождением, развитием, последствиями, возможностями предупреждения. Таким образом, метод сценариев — это метод декомпозиции задачи прогнозирования, предусматривающий выделение набора отдельных вариантов развития событий (сценариев), в совокупности охватывающих все возможные варианты развития. При этом каждый отдельный сценарий должен допускать возможность достаточно точного прогнозирования, а общее число сценариев должно быть обозримо.  [c.304]

В случае ДА, В) дополнительного изучения с целью упорядочения требуют только объекты 8 и 9. В случае ДА, С) кластер 5, 7 появился не потому, что относительно объектов 5 и 7 имеется противоречие, а потому, что в обеих исходных ранжировках эти объекты не различаются. В случае ДВ, С) объекты 1, 2, 3, 4 объединились в один кластер, т. е. кластеризованные ранжировки оказались настолько противоречивыми, что процедура согласования не позволила провести достаточно полную декомпозицию задачи нахождения итогового мнения экспертов.  [c.329]

Декомпозиция задачи и условия оптимальности решения. Будем решать задачу в два этапа, на первом из которых объем ресурса G предполагаем фиксированным, и определим Ui(t) и /2(2), отвечающие решению задач  [c.261]

Разложимость. Формальный анализ решения требует, чтобы было найдено количественное выражение, как предпочтений руководителя относительных последствий, так и его суждений о неоднозначно оцениваемых событиях. При использовании п критериев это означает, что необходимо построить w-мерную функцию предпочтения. Для задач с большим числом критериев полезно произвести декомпозицию задачи и разложить ее на подзадачи, каждая из которых содержит меньшее число критериев. То есть желательно, чтобы набор критериев был разложимым.  [c.229]

При проведении анализа выполняются три возможных вида декомпозиции декомпозиция задач, информационная и функциональная декомпозиция. Содержание информационной декомпозиции включает выделение функций, обрабатывающих уникальные типы информации. Функциональная декомпозиция включает разбиение задачи на функции, осуществляющие трансформацию данных.  [c.137]

Информационная и функциональная декомпозиции во многом чисто интуитивные процессы и слабо поддаются формализации. Декомпозиция задач используется для разбиения задач на модули и выполняется при помощи следующих шагов  [c.137]

Перечислите и охарактеризуйте шаги декомпозиции задач на модули  [c.138]

Декомпозиция задач 137 Документация системы 52 Допуск ошибок 69  [c.268]

Применение такого критерия требует декомпозиции задачи по видам ресурсов. Такая декомпозиция не нарушает условий получения оптимального решения, поскольку во-первых, все предложенные критерии эффективности аддитивны по отношению к видам ресурсов, т. е. суммарный эффект от перераспределения всех видов ресурсов равен сумме эффектов от перераспределения каждого из них во-вторых, в ограничениях решения поставленной задачи отсутствуют требования взаимосвязи распределений различных видов ресурсов. В результате такой декомпозиции исходная модель представляется набором моделей по каждому из видов ресурса te i она может быть записана следующим образом.  [c.175]

Создание гибких автоматизированных производственных систем ведется на основе системного подхода, предполагающего учет иерархических структур, декомпозицию задачи и использование блочно-мо-дульного принципа анализа и синтеза химико-технологических систем или комплексов [102, 103]. В соответствии с этим при создании гибких автоматизированных производственных систем или переналадке  [c.108]

Основная задача IV уровня управления- координация работы ИСУ предприятий. Предполагается, что максимизация критерия оптимальной работы подотрасли может быть достигнута путем декомпозиции его в иерархическую систему локальных критериев. Для эффективного управления отраслью необходимо провести декомпозицию задач с учетом как функциональной иерархии (подотрасль — предприятие -гибкая система), так и временной (год — квартал — месяц — сутки -смена).  [c.114]

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

Если проектировщик использовал библиотеку стандартных подпрограмм, то в состав операций по проектированию должны входить такие операции, как декомпозиция задачи на функциональные блоки выбор типовых процедур и состава стандартных подпрограмм разработка принципов связи программных модулей, списков передаваемых параметров разработка алгоритмов оригинальных программных модулей выбор языка программирования, написание и отладка кодов программ соединение ти-  [c.200]

Структура разбиения работ (СРР) — иерархическая структура последовательной декомпозиции задач проекта на подзадачи. Структура разбиения работ является изначальным инструментом для организации работ, обеспечивающим разделение общего объема работ по проекту в соответствии с порядком их выполнения в организации. На нижнем уровне детализации выделяются работы, соответствующие детализированным элементам деятельности, отображаемым в сетевой модели. СРР представляет иерархическую композицию, которая помогает разработчику для достижения следующих целей  [c.466]

Метод максимума удельных приращений можно применить для трехуровневой системы — например, посредством декомпозиции задачи. На нижнем уровне можно минимизировать затраты при готовности пользователей (достаточность запаса по всем номенклатурам) не ниже заданной. Для единственного депо будем искать минимум затрат на запас в нем при ограничении на ожидаемые задержки из-за дефицита (запасы на первом уровне уже фиксированы). Дефицит в депо покрывается посредством экстренных поставок. На третьем уровне (центральный склад) максимизируется готовность пользователей при ограничении на стоимость запасов в нем. Расчет готовности выполняется как на первом уровне, запас и спрос по всем номенклатурам считаются суммарными.  [c.339]

ДЕРЕВО РЕШЕНИЙ» — структурная модель процесса принятия решений, включающая его элементы по уровням (цели, задачи, рабочие мероприятия) и связи между ними (включение или подчиненность). Является инструментом программно-целевого управления. Формирование Д.р. включает выбор главной цели и ее декомпозицию до уровня рабочих мероприятий, с решения которых можно начинать работу по достижению поставленной цели. Количественная оценка элементов Д.р. с использованием коэффициентов значимости (весомости) позволяет рационально распределить ресурсы, выделяемые для достижения заданной цели.  [c.67]

При рассмотрении внутренней структуры ЕСГ, отдельного газового промысла, газопровода, компрессорной станции, отдельной технологической установки, а также отдельных машин и агрегатов все они — многоуровневые иерархические системы со своими элементами нижних уровней. Глубина декомпозиции объекта на элементы зависит от целей и задач исследования.  [c.15]

Необходимость формирования в требуемом объеме разнообразной нормативной информации, обеспечивающей решение всего комплекса задач функциональных подсистем отраслевых АСУ предопределяет декомпозицию комплексной АСН Газпром на ряд подсистем, Подсистемы выделяются таким образом, чтобы в каждой- из них формировалась нормативная информация по определенному виду ресурсов.  [c.76]

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

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

Метод системного анализа является, по утверждению Ю.И. Черняка, такой областью исследований, где еще нет установившейся системы понятий, общепринятой терминологии и единства мнений исследователей и практиков по многим принципиальным вопросам. В известных публикациях, посвященных системному анализу, как отечественные, так и зарубежные авторы правомерно используют свои собственные определения системных категорий (объектов), способы декомпозиции этих объектов и решаемых проблем, поскольку применяют этот метод для поисков решения разноплановых задач [13]. Однако общий признак всех работ — использование метода системного анализа для решения сложных неформализуемых в явном виде проблем, какой является и проблема познания производственных отношений, условий функционирования производственно-экономических систем.  [c.104]

Определение долгосрочной стратегии компании с количественно выраженными целями происходило путем выявления и формулирования миссии компании, целей и задач компании, затем проводилась функциональная декомпозиция целей по центрам прибыли или ответственности, выраженная в количественных показателях эффективности деятельности структурных подразделений компании.  [c.77]

Связь между системами управления различных иерархических уровней осуществляется по каналам прямой и обратной связи. Таким образом, экономико-математическое моделирование добычи природного газа представляет собой многоуровневую систему моделей, характеризуемую прежде всего неоднородностью информации, которой обмениваются экономико-математические модели различных уровней. Верхний уровень газовой подотрасли имеет приоритет действий (право вмешиваться в функционирование экономико-математических моделей нижних уровней), и действия его подсистемы зависят от фактического исполнения подсистемы нижнего уровня. В терминах экономико-математического моделирования этот обмен информацией эквивалентен корректировке параметров моделей всех уровней [6]. Применение метода декомпозиции экономико-математической модели газовой промышленности на нескольких локальных моделях показало его перспективность для решения практических задач управления на всех уровнях иерархии.  [c.49]

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

Декомпозиция модулей, выделение задач  [c.65]

Выделить задачу, следующую за подлежащей декомпозиции задачей «Закупка материалов» (значение ИСР для нее равно 3). Так как в файле Смета.хк на листе Смета материалов для перечня позиций сметы отведены строки с 3 по 46 включительно, в файле графика реализации проекта соответственно необходимо предусмотреть 38 задач. Чтобы вставить в файл Proje t 38 пустых строк, можно, например, 38 раз нажать клавишу .  [c.225]

Параметризация задачи оптимального управления. В ряде случаев задачу оптимального управления удобно решать в два этапа. На первом этапе оптимальное решение находится с точностью до набора неопределенных параметров. После такого решения задача сводится к конечномерной задаче условной оптимизации относительно вектора неопределенных параметров. Введение неопределенных параметров представляет собой реализацию известного из школьной математики принципа не знаем — обозначим , согласно которому неизвестную величину обозначают через х и по условиям задачи составляют уравнение относительно этой неизвестной. В экстремальных задачах неопределенные параметры позволяют провести декомпозицию задачи, т.е. разбиение ее на несколько подзадач, решение каждой из которых зависит от значения параметра, входящего в другие подзадачи. Так было сделано, например, при исследовании тепловых машин с источниками конечной емкости (гл. 4). В ряде случаев введение параметра позволяет найти форму оптимального решения с точностью до неизвестного параметра, как это было сделано в гл. 5 при определении идеальной рабочей линии процесса ректификации.  [c.402]

Развитие методики приводит к дальнейшей декомпозиции задач, теперь уже на отдельных этапах. Декомпозиц»я способствует тому, что на определенной ее ступени задачи переход г в разряд алгоритмических. В этой связи уместно отметить одно из направлений изучения работы мозга, а именно изучение алгоритмов мыслительной деятельности.  [c.25]

В основе предлагаемого метода решения лежит идея декомпозиции задачи. Предположим, что нам известны нормативные требования к СУПБ всех предприятий в периоде Т. Обозначим их  [c.15]

Так, изложение ограничено однозначными отображениями, в то время как многие приложения приводят к задачам с отображениями точечно-множественного характера, анализ которых более сложен и требует большого числа новых понятий. Не рассмотрены также спорные и не до конца проработанные вопросы двойственности для перечисленных математических постановок, а также вопросы их устойчивости и параметрического анализа. Из всего разнообразия вычислительных методов решения нелинейных задач в основном отобраны те, что апеллируют к свойствам монотонности тех или иных отображений. Не описаны другие (кроме метода Лемке и Данцига—Коттла) конечные методы решения линейной задачи о дополнительности и матричные классы, связанные с ними. Не отмечены важные в прикладном отношении методы декомпозиции задач большой размерности.  [c.89]

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

АИС и АИТ реализуют решение функциональных задач управления, совокупность которых составляет так называемую, функциональную часть деятельности экономического объекта как системы. Состав, порядок и принципы взаимодействия функциональных подсистем, задач и их комплексов устанавливаются исходя и с учетом достижения стоящей перед экономическим объектом цели функционирования. Основными принципами декомпозиции — выделения самостоятельных функциональных подсистем комплексов задач — являются относительная самостоятельность каждой из них, т.е. наличие конкретного объекта управления наличие соответствующего набора функций и функциональных задач с четко выраженной локальной целью функционирования минимизация состава включенных в подсистему элементов наличие одного или нескольких локальных критериев, способствующих оптимизации режима работы подсистемы и согласующихся с глобальным критерием оптимизации функциойирования АИС и системы в целом.  [c.52]

economy-ru.info

Декомпозиция — это… Что такое декомпозиция: суть и виды

Добавлено в закладки: 0

Что такое декомпозиция? Описание и определение термина

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

В конечном итоге эти задачи решаются гораздо проще.

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

Системой могут служить не только материальные предметы, но и явления и процессы. Разделение системы должно при этом проводится только по одному определенному признаку, одинаковому для всех уровней системы -это важно.

Рассмотрим более детально, что значит термин декомпозиция.

Суть декомпозиции

Декомпозиция является основой любого аналитического процесса или просто анализа.

Это процесс упрощения чего-либо без потери целостности.

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

Декомпозиция позволяет рассматривать предстоящую деятельность по частям, при этом каждая деталь процесса важна и учитывается.

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

Виды декомпозиции

Декомпозиция бывает разных видов: объектная, функциональная, структурная, по физическому процессу.

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

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

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

Мы коротко рассмотрели термин декомпозиция, постарались  раскрыть его  главные особенности и  виды.

Оставляйте свои комментарии или дополнения к материалу.

biznes-prost.ru

Software Design: Проектирование: как выполнять декомпозицию задачи?

Нередко формулировка задачи, полученная от заказчика, вызывает у проектировщика шок:

• «Спроектируйте графический редактор».
• «Спроектируйте игру для девочек 4 – 8 лет».
• «Спроектируйте GPS-навигационную систему для мобильного телефона».

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

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

1. выполнить декомпозицию задачи на подзадачи;

2. оценить объём полученных подзадач;

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

Рассмотрим эту процедуру на примере проектирования графического редактора.

Шаг 1. Определение назначения системы

Укажите назначение проектируемой системы.

Примечание: Необходимо избегать размытых формулировок вида: «Система для хранения данных».

ПРИМЕР. Назначение графического редактора – создание/редактирование поздравительных открыток.

Шаг 2. Описание модели функционирования системы

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

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

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

ПРИМЕР. Построим модель функционирования графического редактора.

На первой итерации она будет выглядеть так:

А) в виде списка:

1. Загрузка документа (из файла).
2. Редактирование документа.
3. Сохранение документа (в файле).

Б) в виде рисунка:

На второй итерации детализируем функции «загрузка» и «сохранение», т.к. это сделать проще всего.

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

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

На третьей итерации попробуем детализировать функцию «редактирование». Для этого рассмотрим, как пользователь редактирует документ.

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

Далее, заметим, что устройство ввода тоже влияет на документ не напрямую, а через различные GUI-элементы, такие как: меню, тулбары, selection’ы, различные модификаторы (например, для масштабирования фигуры используется рамка с точками, за которые можно потянуть мышью).

Эти GUI-элементы вызывают команды редактирования, которые уже непосредственно изменяют документ.

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

Наконец, пользователь не «видит» документ напрямую. Для него документ визуализируется с помощью устройства вывода. Чтобы устройство вывода могло визуализировать документ, документ следует сначала растеризовать.

Шаг 3. Составление списка задач

Составьте список задач. Для его составления следует использовать модель функционирование системы.

При этом нужно руководствоваться такими правилами:

1. Если действие сформулировано чётко и понятно, то оно переносится в список задач без изменений.
2. Если действие трудно назвать или его название выглядит слишком общо, то следует проверить, не является ли это действие преобразованием из одного в другое (например, преобразование команд от устройства ввода в команды от элементов GUI).

ПРИМЕР. Для графического редактора получаем:

1. Редактирование документа (== составить список операций над документом и его элементами).
2. Растеризация документа.
3. Загрузка документа из файла.
4. Сохранение документа в файле.
5. Преобразование документа из неродного формата в родной.
6. Преобразование документа в неродной формат из родного.
7. Преобразование действий пользователя в команды от устройства ввода.
8. Преобразование команд от устройств ввода в команды от элементов GUI.
9. Преобразование команд от элементов GUI в команды редактирования.

Шаг 4. Объединение задач в группы

Объедините задачи в группы, если:

Например, задача «загрузка» противоположна по смыслу задаче «сохранение». Эти задачи можно объединить в группу «загрузка/сохранение».

ПРИМЕР. После группировки получаем такой список задач:

1. Редактирование.
2. Растеризация.
3. Загрузка/сохранение.
4. Преобразование из формата в формат.
5. Преобразование действий пользователя в команды от устройства ввода.
6. Преобразование команд от устройств ввода в команды от элементов GUI.
7. Преобразование команд от элементов GUI в команды редактирования.

Шаг 5.  Упорядочение задач во времени и пространстве

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

ПРИМЕР. Самой главной задачей в нашем примере является задача «редактирование». Чтобы выполнить остальные задачи, нам нужно знать либо перечень операций над документом, либо структуры данных, которые будут использованы для представления документа. Поэтому задачу «редактирование»  расположим в самом начале.

Следующей по важности задачей является задача «преобразование действий пользователя в команды от устройств ввода». Эту задачу мы ставим раньше задачи 6 («преобразование команд от устройств ввода в команды от элементов GUI «) и задачи 7 («преобразование команд от элементов GUI в команды редактирования «), т.к. вид и функции GUI-элементов нередко определяются возможностями устройств ввода.

На пятое место ставим сразу три задачи:

1. загрузка и сохранение;
2. преобразование из/в;
3. растеризация.

Эти задачи могут выполняться параллельно.

В виде графической схемы план разработки графического редактора выглядит так:

Задачи, которые могут выполняться параллельно, можно делегировать сразу нескольким разработчикам. Более сложные задачи (например, «редактирование») следует отдавать более опытным разработчикам.

Примечание: После составления схемы плана разработки можно ещё раз взглянуть на задачи и, если получится, объединить некоторые из них в группы. В нашем случае задачи «преобразование действий пользователя в команды от устройств ввода» и «преобразование команд от устройств ввода в команды GUI» можно объединить в задачу «проектирование ввода». А задачу «преобразование команд от GUI в команды редактирования» можно назвать по-другому – «проектирование GUI».

С учётом изменений получится:

Резюме

В данном посте предложен алгоритм, который позволяет:

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

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

askofen.blogspot.com