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

Чтобы не тонуть в материале предлагаю тезисы соотносить с рамками контекстов. ИМХО можно рассматривать высказывания применительно к трем вложенным рамкам, ограничивающим контексты: Культура (наиболее общий контекст, в котором обсуждаются наиболее общие термины и понятия), рамка деятельности (с конкретизируемыми/измеримыми резцльтатми/показателеми), рамка бизнеса (допускает обсуждение в экономических показателях), рамка автоматизации.

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

Я благодарю господина Boatman за написанную статью. Поднятая тема о целеполагании заставила меня освежить в памяти много разных материалов; и покопаться среди своих "тараканов".

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

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

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

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

чтобы разобраться в сложной деятельности надо вытащить на свет ее каркас - иерархию целей

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

Но мне, как дипломированному психологу, понятно и другое:

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

• При конструировании новой деятельности следует учитывать баланс интересов.

  Разнообразие интересов (и целей) существует и у отдельного человека(!). Это тоже надо учитывать.
• И последнее. А откуда вообще берется априори принимаемое утверждение, что человек обязательно действует целенаправленно. С чего это Вы так уверены, что заказчик (у которого получаем требования) или  пользователь (при работе за компьютером), что-то планируют в своей деятельности? А как же спонтанность, интуитивность, как же эмоции ..?

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

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

ИМХО важно учитывать, что цели есть как у субъекта-разработчика, так и у субъекта-заказчика и не стоит сводить заказчика исключительно к объекту воздействия разработчика. Т.к. заказчик субъектен, и скорее даже "субъекктивен", то его "тараканы", интуиция и пр., о чем Вы пишете ниже, способно преподнести немало сюрпризов разработчику при реализации проектов. ОБъект тем и отличается от субъекта, что субъект осознанно воздействует на объект, а объект- нет.

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

Возможно, вы имели в виду, что мы не значем цели пользователя "до проектирования системы" ? Потому что проектирование без цели Заказчика ИМХО представить себе достаточно трудно (ну только если проектируем для себя, и то, для целей проектирования важно представлять себя как пользователя рефлексивно - в третьем лице).

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

Но мне, как дипломированному психологу, понятно и другое:

• Человек не является константой, его цели, мотивы, интересы постоянно(!) меняются. Не только меняются, но и переструктурируются.
• В иерархии целей человека, всегда найдутся надцели, находящиеся вовне. Вне компьютера, вне данной фирмы, вне рассматриваемой нами предметной области. И именно этой надцелью может определяться поведение и заказчика, и пользователя.
• Разнообразие интересов (и целей) существует и у отдельного человека(!). Это тоже надо учитывать.
• И последнее. А откуда вообще берется априори принимаемое утверждение, что человек обязательно действует целенаправленно. С чего это Вы так уверены, что заказчик (у которого получаем требования) или  пользователь (при работе за компьютером), что-то планируют в своей деятельности? А как же спонтанность, интуитивность, как же эмоции ..?

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

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

2 tolldo - отличное и важное замечание про субъект и объект. +1

Думаю тут стоит отметить еще один нюанс, который в дискуссии не был четко обозначен ( спасибо tolldo за пост, натолкнул на хорошую мысль).
Основной задачей при проектировании ПО является автоматизация существующих БИЗНЕС-ПРОЦЕССОВ (БП) предприятия или организации. Вопрос не в том, насколько полно и точно мы выявляем цели, потребности, мотивы и установки пользователей, а в том насколько точно и полно разрабатываемое ПО маппируется на существующие БП. Т.е. насколько полно разрабатываемое ПО автоматизирует БП (функции, задачи и операции). Пользователь является связующим элементом между БИЗНЕС-ПРОЦЕССОМ (любым) и ПО.
К примеру, у нас есть некая организация, которая занимается торговлей канцелярскими товарами со склада. Необходима разработка, ПО которое позволяет автоматизировать БИЗНЕС-ПРОЦЕССЫ закупки товара, отслеживания товара на складе, продажи товаров, управления отношением с клиентом и прочего. И уже в рамках этих конкретных процессов нужно выявлять конкретные цели и задачи конкретных пользователей.

 Скажу свою мысль проще: Невозможно разработать ПО, без знания и использования в качестве ориентира, существующих БИЗНЕС-ПРОЦЕССОВ организации.

Иначе получаются какие то "сферические" пользователи в вакууме. Которые хотят непонятно что и непонятно как.


2 Galogen - тоже очень верно подмечено

В данном примере все ясно и достаточно очевидно, я бы сказал даже стереотипно. Хорошо или нет действовать стереотипно - безусловно - это благо, такова сущность человеческого разума. Вопрос почему же при реализации ИТ проектов стереотипность не срабатывает, может ответ в том, что просто не накоплен тот эволюционный опыт, который дает выверенные стереотипные решения, а приходится действовать революционно пока. Ясно, что Сергей высказал здравую мысль, что при революции шаблоны не слишком хороши, более того они вредны, так как имеют лишь кажущуюся подобность (хотя мы кажется имели подобные шаблоны в Грузии и на Украине с их "оранжевыми" революциями)

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

Идеальный вариант:  На предприятии имеется "полная и адекватная" модель БИЗНЕС-ПРОЦЕССОВ предприятия. Соответственно, когда начинается проектная деятельность по внедрению ПО, разработчик в лице Системного аналитика используя формализованную модель БП Заказчика пишет требования к ПО и согласовывает их с Заказчиком ( итерационный процесс).
В таком варианте особенных проблем и трудностей нет.


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


ИМХО. При постановке целей и задач Разработчику строго обязательно необходимо использовать в качестве базы - БП Заказчика и идти сверху – вниз.

Хм . . . тогда вопрос в том есть ли какие методы (применяемые и работающие) для выявления требований Заказчика в "типичном варианте"?

Необходима разработка, ПО которое позволяет автоматизировать БИЗНЕС-ПРОЦЕССЫ закупки товара, отслеживания товара на складе, продажи товаров, управления отношением с клиентом и прочего. И уже в рамках этих конкретных процессов нужно выявлять конкретные цели и задачи конкретных пользователей.

 Скажу свою мысль проще: Невозможно разработать ПО, без знания и использования в качестве ориентира, существующих БИЗНЕС-ПРОЦЕССОВ организации.

Правильно ли я Вас понимаю: первичны бизнес-процессы, цели вторичны? Т.е. в жизни сначала появляется бизнес-процесс, и для порождения этого бизнес-процесса его создателям/пользователям цели не нужны?

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

Т.е. наличие описания бизнес-процесса уже гарантирует возможность укзания цели Заказчика ("чего хочет Заказчик")?

Правильно ли я Вас понимаю: первичны бизнес-процессы, цели вторичны? Т.е. в жизни сначала появляется бизнес-процесс, и для порождения этого бизнес-процесса его создателям/пользователям цели не нужны?

Если речь идет о целях пользователей то Вы понимаете правильно. Цели пользователей вторичны по отношению к БИЗНЕС-ПРОЦЕССАМ.

Т.е. наличие описания бизнес-процесса уже гарантирует возможность указания цели Заказчика ("чего хочет Заказчик")?

Да безусловно.

Я просто не понимаю как можно говорить о выявлении целей пользователей в отрыве от БИЗНЕС-ПРОЦЕССОВ (БП).
Есть компания, у нее деятельность, которая состоит из БП, и которые в конечном итоге приносят ей прибыль. Любой БП можно декомпозировать сверху - вниз до самого нижнего (требуемого) уровня, до уровня конкретных задач конкретных пользователей. Например БИЗНЕС-ПРОЦЕСС "Закупка товара" можно декомпозировать до уровня конкретных задач, когда работнику необходимо сделать: 1. Найти контрагента. 2. Выяснить условия поставок. 3. Провести предварительные переговоры. и т.д. Это задачи со стороны пользователя!

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

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

С одной стороны, (стороны Заказчика) имеются БИЗНЕС-ПРОЦЕССЫ которые декомпозируются до уровня конкретных задач, конкретных пользователей (работников). Сами БП есть и будут независимо от ПО.

С другой стороны, (стороны Разработчика) имеются потребности Заказчика в автоматизации части своих БП. И задача Разработчика состоит в понимании протекания БП Заказчика, выяснения требований Заказчика в части автоматизации БП (какие именно БП, какие задачи) и маппировании их на конкретное ПО. И вот тут Самое Главное !!!

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

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

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

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

А в самом деле - как выявить? Какие вопросы нужно задать, например?

Основной задачей при проектировании ПО является автоматизация существующих БИЗНЕС-ПРОЦЕССОВ (БП) предприятия или организации. Вопрос не в том, насколько полно и точно мы выявляем цели, потребности, мотивы и установки пользователей, а в том насколько точно и полно разрабатываемое ПО маппируется на существующие БП. Т.е. насколько полно разрабатываемое ПО автоматизирует БП (функции, задачи и операции). Пользователь является связующим элементом между БИЗНЕС-ПРОЦЕССОМ (любым) и ПО.

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

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

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

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

А в самом деле - как выявить? Какие вопросы нужно задать, например?

В этом и заключается профессионализм и мастерство разработчиков ПО.
Насколько я знаю существуют как методологии так и стандарты. В этом вопросе следует ориентироваться на западные методологии, т.к. сами прекрасно понимаете что у нас как таковой теоретической и опытной базы нет в стране. Навскидку вспомню методологию RUP, и наши  ГОСТы 19 и 34 серии. Есть еще забугорный стандарт на описание ТЗ к ПО, но сейчас его названия не помню.


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

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

Я не автоматизатор. Я работаю с другой стороны "барикад".
БП важны: 1. Заказчику для четкого понимания происходящих в его компании/предприятии процессов. Т.е. что, где, когда и как происходит. Чем больше компания - тем важнее иметь описание БП.
2. В процессе выявления требований Заказчика к разрабатываемому ПО.


Мне вот все интересно: о каких таких целях утверждает  bas ?
Есть компания, в ней есть должности - бухгалтера, директора, продавца и прочих. Эти должности имеют свои должностные инструкции - кто что делать должен и за что отвечает.  Должности и инструкции не появляются на пустом месте. Они не абстрактны. Они появляются в силу необходимости реализации БИЗНЕС-ПРОЦЕССОВ.

2Rocket:
Вы к сожалению, ушли от ответа на оба мои вопроса . Несмотря на их кажущуюся тривиальность, в жизни ответ на них полчается не всегда просто.
Если решения по тому - какое ПО, принимает ШеФ, то важно Шеф - кто? Разработчик или Заказчик?

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

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

Могу ответить точнее.

Вы к сожалению, ушли от ответа на оба мои вопроса . Несмотря на их кажущуюся тривиальность, в жизни ответ на них полчается не всегда просто.
Если решения по тому - какое ПО, принимает ШеФ, то важно Шеф - кто? Разработчик или Заказчик?

Решение по выбору ПО принимает ШеФ - Заказчик. Кто платит деньги, тот и танцует. Вроде всегда было именно так.

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

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

Непонятная формулировка.

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

Изначально БП возникают в процессе создания организации или предприятия. Для обеспечения протекания этих БП нужны определенные работники, которые выполняют фиксированный перечень должностных задач. Например есть БП - "Закупки" который состоит из следующих стадий:
      1. Определение потребности в материале
      2. Выбор поставщиков:
             2.1 Подготовка списка возможных поставщиков.
             2.2 Отправка запроса в соответствии с заявкой на материал.
             2.3 Выбор поставщиков.
      3. Обработка заказов
      4. Контроль выполнения условий договора
      5. Поступление материала
      6. Оприходование материала
      7. Контроль счетов
В этом примере БП "Закупка" декомпозирован на конкретные задачи (функции или подпроцессы) "1-7", и для примера задача "2. Выбор поставщиков" разложена вниз на более мелкие  задачи. "2.1, 2.2, 2.3". Далее возможна декомпозия на еще более мелкие задачи, вплоть до примитивных задач - взять ручку, взять бумагу и т.д.
Просто хочу донести мысль, что любой БП в компании может быть разложен на ряд совсем простых задач, автоматизация которых и позволит в сумме автоматизировать весь БП, или ту его часть которую требовал Заказчик.

...
Основной задачей при проектировании ПО является автоматизация существующих БИЗНЕС-ПРОЦЕССОВ (БП) предприятия или организации.

Да что вы говорите )
Я вот сходу могу назвать следующие нечёткие классы ПО:
* Заказное ПО
* Встраиваемое ПО
* Публичные массовые веб-системы
* Персональное коробочное ПО
* Корпоративное коробочное ПО
* Игры
* «Одноразовые» приложения
* Системные приложения

И бизнес-процессы как таковые нужны только для 2-3 из них.

Кроме того, тема, затронутая Boatman, более широкая, чем проекты по автоматизации, целеполагание нужно и в несвязанных с IT-проектами - например, развитие бизнеса.

Вопрос не в том, насколько полно и точно мы выявляем цели, потребности, мотивы и установки пользователей, а в том насколько точно и полно разрабатываемое ПО маппируется на существующие БП. Т.е. насколько полно разрабатываемое ПО автоматизирует БП (функции, задачи и операции).

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

К примеру, у нас есть некая организация, которая занимается торговлей канцелярскими товарами со склада. Необходима разработка, ПО которое позволяет автоматизировать БИЗНЕС-ПРОЦЕССЫ закупки товара, отслеживания товара на складе, продажи товаров, управления отношением с клиентом и прочего. И уже в рамках этих конкретных процессов нужно выявлять конкретные цели и задачи конкретных пользователей.

Вы про фазу ПРОЕКТИРОВАНИЯ систем и цели ПОЛЬЗОВАТЕЛЕЙ в рамках целевых бизнес-процессов, мы же - про фазу ИНИЦИАЦИИ и цели ЗАИНТЕРЕСОВАННЫХ ЛИЦ (прежде всего, Заказчика, но не только). Такое ощущение, что вы презентацию Boatman не смотрели.

Хм . . . тогда вопрос в том есть ли какие методы (применяемые и работающие) для выявления требований Заказчика в "типичном варианте"?

Эта тема уже раскрывалась мной.

Могу ответить точнее.Решение по выбору ПО принимает ШеФ - Заказчик. Кто платит деньги, тот и танцует. Вроде всегда было именно так.

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

Изначально БП возникают в процессе создания организации или предприятия. Для обеспечения протекания этих БП нужны определенные работники, которые выполняют фиксированный перечень должностных задач. Например есть БП - "Закупки" который состоит из следующих стадий:
      1. Определение потребности в материале
      2. Выбор поставщиков:
             2.1 Подготовка списка возможных поставщиков.
             2.2 Отправка запроса в соответствии с заявкой на материал.
             2.3 Выбор поставщиков.
      3. Обработка заказов
      4. Контроль выполнения условий договора
      5. Поступление материала
      6. Оприходование материала
      7. Контроль счетов
В этом примере БП "Закупка" декомпозирован на конкретные задачи (функции или подпроцессы) "1-7", и для примера задача "2. Выбор поставщиков" разложена вниз на более мелкие  задачи. "2.1, 2.2, 2.3". Далее возможна декомпозия на еще более мелкие задачи, вплоть до примитивных задач - взять ручку, взять бумагу и т.д.
Просто хочу донести мысль, что любой БП в компании может быть разложен на ряд совсем простых задач, автоматизация которых и позволит в сумме автоматизировать весь БП, или ту его часть которую требовал Заказчик.

Насчет разложимости БП по задачам я думаю, никто врзражать не будет.
Вопрос в том, можете ли Вы указать, в каких именно показателях Вы определяет потребности в материалах, какими показателями характеризуется результат обработки,  какие именно показатели необходимо должны быть результатом выполнения перечисленных Вами задач 1-7?
Ведь названия задач не раскрывают точно, что именно требуется получить в результате их выполнения.