Требования к проекту по математике

Требования к проекту по математике

Наталья Чернявская, Юрий Чернявский, «Комиздат»

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

Лирическое вступление

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

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

Далее это зародившееся Нечто развивается, разукрашивается для Заказчика-Инвестора, обрастая все новыми и более четко очерченными (опять-таки) требованиями — и вырастает в Ого-го-что, пока не получит «путевку в жизнь» в виде финансирования и четко определенных сроков.

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

Выскочившее из передряг с требованиями, наше детище имеет вид «изрядно общипанного, но непобежденного» Чего-то — готового и даже работающего.

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

…И так до тех пор, пока какое-нибудь новое требование своими убийственными ограничениями не превратит наше детище в Ничто.

Но это — лирика эволюции требований. Пора приступить к физике их структуры и свойств.

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

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

Почему именно «область», а не класс, к примеру, или группа? Тут две причины:

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

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

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

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

Диаграмма областей требований


Простейший случай диаграмм

Итак, в простейшем случае на диаграмме имеем область всех мыслимых и «немыслимых» требований — наш аналог универсального множества в математике.

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


Рис. 1. Простейший случай диаграммы (вертикальное измерение — уровень компетенции)

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

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

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


Рис. 2. Возможность конструктивного диалога

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

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

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


Рис. 3. Возможность полноценного сотрудничества

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


Рис. 4. «Высокие договаривающиеся стороны» принимают решение и проводят две красные черты

Эти две руководящие директивные черты отрезают две небольшие, но очень интересные области:

  • излишние требования к автоматизации от особо грамотных сотрудников Заказчика;
  • излишняя формализация предметной области от особо рьяных аналитиков Разработчика.

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

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

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


Рис. 5. Результат встречи «в верхах»

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

Приступаем к воплощению… и с ужасом обнаруживаем: для реализации требования В необходима реализация требований, оставшихся за пределами внимания руководства,— А или C.


Рис. 6. Первые неожиданности: обнаружение новых, не учтенных в документах, но обязательных требований: B или C

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

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


Рис. 7. Область контекста реализации

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

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

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

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

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

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

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

Очевидными плодами такого подхода будут:

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

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

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

Существует еще одна область требований, реализация которых необходима для поддержания естественной и полноценной работы системы в соответствии со взаимно понятными и задокументированными требованиями (рис. 8). Изначально, требования из этой области не были замечены аналитиками Разработчика и считались в равной мере как очевидными, так и обязательными, с точки зрения экспертов Заказчика.

Если проигнорировать реализацию этих Требований, то Заказчик получит Систему, в которой функционирование автоматической части должно поддерживаться большим объемом окружающего ручного труда. Грубо говоря, придется заводить штат сотрудников, специалистов Предметной Области, работающих на Систему.


Рис. 8. Область контекста использования/функционирования

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

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

Но вернемся к нашей диаграмме и выделенной там области… и зададимся вопросом: «А почему, собственно, область поддерживающих требований должна иметь именно такой вид?» Почему не так, как на рис. 9?

Другой интересный вопрос: а какой смысл в двух различных подобластях данной области? Чем, по сути, отличаются требования A и C? Но об этом чуть далее.


Рис. 9. Та же область контекста реализации — но при более глубоком рассмотрении

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

Итак, имеем две зеркальные — как по расположению на диаграмме, так и по своим проявлениям в процессе разработки,— области:

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


Рис. 10. Семантика горизонтального измерения — стандартизация или уникальность разработки

Теперь настало время «показать семантику второго измерения». Проще говоря, ответить на поставленный ранее вопрос: а чем, собственно, отличается левая подобласть от симметричной ей правой? Если для полноценной работы Заказчика в соответствии с требованием E необходима реализация одного из поддерживающих требований D или F (рис. 9), то чем они между собой отличаются и что общего у них с зеркальными им требованиями A и C?

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

И не случайно стрелочка, указывающая стремление использовать стандартные методы, расположена в верхней части, соответствующей стремлениям Разработчика. Именно от него зачастую звучат размашистые предложения в стиле: да, для решения задач такой серьезной и представительной организации, как Заказчик, ну просто необходимы: СУБД — не меньше и не дешевле Oracle 9, CRM-системы — не ниже самого «Сибел-системз», а для решения задач коммуникации без приобретения спутника с антеннами вообще не обойтись.

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

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

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

В данном случае особенно к месту оказывается следующий пример из области делопроизводства. Существует обязательное требование E: система должна автоматически реагировать на состояние счета клиента и конфигурацию платежных документов. Существуют особые случаи, в которых необходим перерасчет сумм по платежным документам и реализация требования E нуждается в удовлетворении одного из требований D или F. Пример для требования F — наличие какого-то удобного и логичного механизма для перерасчета. Требование D — ужесточение (стандартизация) требований на платежные документы, исключающие возникновение запутанных ситуаций.

Для зеркальных требований A, B, C можно привести такой пример. B — набор отчетов, генерируемых из БД. Особенность — один или несколько из них не реализуются в виде единственного, пусть и сложного, SQL-запроса. Необходимы хранимые процедуры. Для реализации этого требования следует реализовать либо требование A — использовать Т-SQL с соответствующими механизмами MS-SQL Server (стандартное решение — и никакой головной боли Разработчику) либо требование С — использовать ODBC-интерфейс к файлу MS Access, на чем настаивает Заказчик. Но тогда Разработчику придется засучить рукава — и разрабатывать собственный эмулятор хранимых процедур. Вот вам и уникальность, и специфичность разработки.

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

Требования к Экспертному заключению по проекту СЗЗ

При оформлении экспертного заключения по результатам проведённой санитарно-эпидемиологической экспертизы проекта СЗЗ в содержательной части целесообразно предусмотреть изложение следующей информации:

1. Наименование хозяйствующего субъекта, для промышленной площадки (далее — промплощадка) которого представлен проект расчётной СЗЗ, реквизиты хозяйствующего субъекта, наименование проекта СЗЗ.

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

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

4. Количество всех земельных участков, на которых размещён или предполагается к размещению объект, с указанием их соответствия положениям пункта 3.3 СанПиН 2.2.1/2.1.1.1200-03 «Санитарно-защитные зоны и санитарная классификация предприятий, сооружений и иных объектов» (в части вида хозяйственной деятельности на земельном участке, принадлежащем промышленному производству и объекту и оформленному в установленном порядке). Для обеспечения последующей идентификации границ промплощадки, от которой обосновывается размер и границы СЗЗ, рекомендуем указывать кадастровые номера упомянутых земельных участков.

В случае, если земельный участок не оформлен для ведения хозяйственной деятельности в установленном порядке, проект СЗЗ не может быть признан соответствующим пункту 3.3 СанПиН 2.2.1/2.1.1.1200-03. При этом доводы разработчиков проекта СЗЗ или хозяйствующих субъектов о том, что проект СЗЗ разработан как основание для внесения изменяя в утверждённую в градостроительную документацию или для изменения разрешённого вида использования земельного участка не является основанием для согласования таких проектов, т.к. установленная Градостроительным Кодексом Российской Федерации процедура изменения разрешённого вида использования земельного участка и состав представляемой для этого документации не предусматривают наличие согласованной расчётной СЗЗ для объекта, предполагаемого к размещению на этом земельном участке.

5. Класс опасности объекта согласно санитарной классификации, предусмотренной СанПиН 2.2.1/2.1.1.1200-03. В случае, если в состав объекта входят вспомогательные (обеспечивающие) структурные подразделения, имеющие свой класс опасности, перечислить все такие подразделения с указанием класса опасности и соответствующего пункта в санитарной классификации. В случае, если объект не внесён в санитарную классификацию, указать соответствующую информацию.

6. Информацию о расстояниях от границ земельного участка объекта до границ существующих территорий и до ближайших границ перспективных к застройке территорий с нормируемыми показателями среды обитания (жилой застройки, образовательных учреждений, зон рекреации и др.), размещение которых предусмотрено Правилами землепользования и застройки населённых пунктов (в целях оценки соблюдения положений пунктов 5.1, 5.2 и 5.3 СанПиН 2.2.1/2.1.1.1200-03).

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

8. Количество источников по каждому из факторов, итоговый перечень вредных веществ с учётом совокупности всех технологических процессов, по которым произведены расчёты рассеивания, с указанием применённых в расчётах разработанных в установленном порядке методик, что соответствует положениям пункта 3.12 СанПиН 2.2.1/2.1.1.1200-03.

9. Формируемые загрязняющими веществами расчётные концентрации на границе расчётной СЗЗ и за ее пределами (с целью проверки возможного формирования максимальных значений ПДК за пределами расчётной СЗЗ при наличии на объекте источников средних и высоких нагретых выбросов).

10. Наличие или отсутствие, с позиций гигиенической безопасности, необходимости выполнения мероприятий по защите населения от воздействия выбросов вредных химических примесей в атмосферный воздух, биологического и физического воздействия (пункт 3.10 СанПиН 2.2.1/2.1.1.1200-03), а также мероприятий и средств на организацию СЗЗ, включая отселения жителей, в случае необходимости (пункт 3.2 СанПиН 2.2.1/2.1.1.1200-03).

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

12. Ориентирующую информацию для хозяйствующего субъекта о том, что установление окончательной СЗЗ осуществляется в порядке, предусмотренном главой IV СанПиН 2.2.1/2.1.1.1200-03, с указанием конкретного номера пункта, в соответствии с которым установление окончательной СЗЗ будет проведено для данного объекта. Отдельно обратить внимание хозяйствующего субъекта на то, что натурные исследования и измерения в целях подтверждения расчётных размеров СЗЗ и установления окончательной СЗЗ должны быть проведены после достижения объектом той проектной мощности, для которой была обоснована расчётная СЗЗ данного объекта.

13. Выводы о соответствии (несоответствии) расчётной СЗЗ требованиям санитарного законодательства, регулирующего вопросы установления СЗЗ.

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

1. Сведения об оценённых документах, позволивших установить соответствие земельного участка, от границ которого устанавливается окончательная санитарно-защитная зона, положениям пункта 3.3 СанПиН 2.2.1/2.1.1.1200-03.

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

3. Анализ выполнения мероприятий по защите населения от воздействия выбросов вредных химических примесей в атмосферный воздух и физического воздействия, а также по организации СЗЗ, если необходимость проведения таковых была установлена ранее при согласовании расчётной СЗЗ.

4. Анализ соответствия объёма выполненных натурных исследований и измерений программе наблюдений, ранее представляемой и оценённой в составе проекта СЗЗ, а также анализ сопоставления расчётных (ожидаемых) значений ПДК загрязняющих веществ и ПДУ физических факторов фактическим результатам проведённых исследований и измерений. Отдельно привести информацию о том, является ли представленный объем натурных исследований и измерений выполненным после достижения объектом проектной мощности и/или ввода в эксплуатацию после его технического перевооружения или реконструкции.

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

6. Информацию о результатах оценки риска здоровью населения.

7. Вывод о размере окончательной СЗЗ, который по итогам совокупного анализа расчётов, представленных в проекте СЗЗ, результатов оценки риска здоровью населения (для объектов 1 и 2 классов опасности) и выполненных натурных исследований и измерений признан территориальным органом Роспотребнадзора безопасным и соответствующим положениям пункт 2.1 СанПиН 2.2.1/2.1.1.1200-03. В случае несовпадения размеров СЗЗ, полученных на сновании вышеуказанных данных, решение по окончательному размеру данной 333 должно приниматься по варианту, обеспечивающему наибольшую Безопасность для населения согласно пункту 3.6 СанПиН 2.2.1/2.1.1.1200-03, чем также должно быть указано в предварительном заключении.

В отношении положений пункта 4.5 СанПиН 2.2.1/2.1.1.1200-03 дополнительно обращаем внимание на недопустимость предъявления к хозяйствующим субъектам требований о временном периоде, в течение которого этот объем исследований (50 или 30 дней исследований в зависимости от класса опасности объекта) должен быть сформирован. СанПиН 2.2.1/2.1.1.1200-03 не устанавливает таких требований, равно как и требований о проведении исследований посезонно. Вместе с тем, целесообразно рекомендовать хозяйствующему субъекту проведение лабораторных исследований содержания в атмосферном воздухе загрязняющих веществ в условиях наихудшего рассеивания выбросов данных загрязняющих веществ.

Отдельным вопросом рассмотрения и установления размеров СЗЗ, как зон с особым режимом использования территорий, является необходимость на основании закреплённого СанПиН 2.2.1/2.1.1.1200-03 режима СЗЗ накладывать ограничения на землепользование через внесение сведений об установлении СЗЗ в государственный кадастр недвижимости Российской Федерации.

В соответствии с требованиями статьи 15 Федерального закона от 24.07.2007 № 221-ФЗ «О государственном кадастре недвижимости» (далее -Федеральный закон № 221-ФЗ), пунктов 4, 17 Правил направления органами государственной власти и органами местного самоуправления документов, необходимых для внесения сведений в государственный кадастр недвижимости, в федеральный орган исполнительной власти, уполномоченный в области государственной регистрации прав на недвижимое имущество и сделок с ним, кадастрового учёта и ведения государственного кадастра недвижимости, а также о требованиях к формату таких документов в электронной форме, утверждённых постановлением Правительства Российской Федерации от 03.02.2014 № 71 (далее — Правила), органы государственной власти и органы местного самоуправления должны обеспечить направление в установленном порядке сведений в государственный кадастр недвижимости в случае принятия ими решений об установлении или изменении границ зон с особыми условиями использования территорий, в том числе санитарно-защитных зон.

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

Объекты III категории: нормирование, разрешительная документация, отчетность.

Все объекты 1 категории после 2019 года должны разработать и согласовать КЭР

Организации, осуществляющие деятельность на объектах II категории, обязаны

Требования к результатам обучения технологии в начальной школе

В результате обучения технологии ученик должен

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

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

Для практической учебной работы учащимся необходимы:

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

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

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

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

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

Рассмотренная выше программа [21] определяет основы технологической подготовки школьников на современном этапе отечественной школы. В целях обеспечения вариативности обучения с учетом потребностей учащихся и особенностями системы образования могут использоваться различные примерные программы по технологии, в основу большинства которых положено разделение по направлениям подготовки учащихся [23, 24, 32]. Наряду с ними предлагаются программы обучения технологии, отличительной особенностью которых выступает совместное обучение учащихся с 5 по 9 класс без разделения по направлениям подготовки. [8,10] Они включают в себя ряд традиционных разделов обучения, входивших в основные направления технологической подготовки и дополненных технологиями социальных, медицинских, транспортных и других областей деятельности. Такого рода технологическая подготовка в зарубежных школах носит название «Домашняя экономика» и осуществляется с 1 по 6 класс с последующим переходом на специализированное обучение по выбору учащихся, по одному из направлений деятельности.

Предлагаемое расширение спектра изучаемых отраслей на весь период основной школы может способствовать решению задач профессионального самоопределения и создавать возможность достижения непрерывности технологической подготовки в 8—9-х классах, не обеспеченной объемами учебного времени в существующем Базисном учебном плане для основной школы. Данная программа может быть также использована для организации совместного обучения детей технологии в малокомплектных школах, наиболее распространенных в условиях сельской местности. С другой стороны, расширение спектра изучаемых областей и отказ от специализации обучения приводит к снижению уровня практической подготовки учащихся, переходу от технологического обучения к просвещению, с учетом заявленных требований к результатам, которые определены здесь как ознакомление и формирование представлений о рассматриваемых процессах и технологиях.

В соответствии с Примерной программой по предмету «Технология» [23], составленной согласно требованиям Федерального Государственного образовательного стандарта общего образования, обучение технологии в основной школе строится на основе освоения конкретных процессов преобразования и использования объектов природной и социальной среды. Обязательный минимум содержания образовательных программ по технологии изучается в рамках одного из трех направлений: «Индустриальные технологии», «Технологии ведения дома» и «Сельскохозяйственные технологии». Выбор направления обучения должен исходить из образовательных потребностей и интересов учащихся.

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

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

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

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

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

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

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

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

Читайте так же:  Про налог на прибыль