Меню

Требования сут

Онлайн-курсы профессиональной разработки ПО

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

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

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

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

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

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

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

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

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

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

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

Адаптируется ли она под процессы, уже сложившиеся в компании, или, наоборот, требует подстройки или даже ломки процессов под себя.

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

Если СУТ не соответствует их интересам, то она с большой вероятностью будет отторгнута компанией. Люди просто не станут её использовать.

Эти интересы влияют практически на все ключевые возможности СУТ. Это влияние в таблице отражено в описании возможностей. Часто эти описания пересекаются, особенно когда речь идёт об интеграции с другими системами. Те возможности, которые можно описательно отделить от остальных, вынесены в отдельный раздел таблицы — «Приживаемость системы».

Система управления требованиями (СУТ)

В современном мире успех разработки АЭС зависит от способности использовать накопленный поколениями опыт, который зафиксирован в различных стандартах, от международных до стандартов предприятия. Одним из ключевых стандартов по организации инженерной работы является стандарт ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем». Управление требованиями является частью технических процессов, предусмотренных этим стандартом.

Цели создания СУТ и способы их достижения

1. Обеспечение уверенности заказчика в том, что проектируемая АЭС соответствует требованиям технического задания.

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

3. Обеспечение прозрачности и управляемости проекта.

1. Сбор и анализ количественных показателей процесса и конечного результата. Например, общее количество требований, количество связанных, проверенных, удовлетворенных требований, в том числе в разрезах по исполнителям, элементам АЭС и экспертам.

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

3. Формальное закрепление ответственных исполнителей за каждым требованием.

4. Формальная организация приемки: описание критериев приемки, выдача заданий на экспертизу, формирование отчета о проведенной экспертизе.

Ключевые задачи при внедрении СУТ

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

2. Закрепление за каждым требованием исполнителя еще на этапе согласования и подписания ТЗ на АЭС.

3. Трассировка исполнителями требований ТЗ к своим проектным материалам. Без такой трассировки проверить объемное ТЗ на АЭС (более 400 стр.) по материалам технического проекта, содержащего более 200 000 стр., за 2-3 месяца практически невозможно.

4. Распределение всего объема требований ТЗ среди экспертов так, что бы за каждым требованием стоял конкретный эксперт.

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

6. Выдача индивидуальных заданий на проверку требований экспертам и получение от них формального отчета. Это гарантирует полноту проверки всех запланированных требований и обеспечивает понимание предмета выполненных проверок.

7. Использование современных информационных технологий для управления данными (предоставления доступа, обмена данными) и анализа информации.

АО «НТЦД» осуществляет работы по созданию СУТ поэтапно, согласно следующему плану:

Этап 1. Развертывание СУТ и ее компонентов

1. Развертывание портала.

2. Создание регламента работы с требованиями.

3. Создание регламента управления изменениями.

4. Создание регламента управления объектами конфигурации.

Этап 2. Формирование структуры требований

1. Внесение требований технического задания.

Читайте так же:  Каждый человек имеет право на одиночество

2. Внесение требований нормативно-технической документации.

3. Внесение требований надзорных органов.

Этап 3. Поддержка и управление изменениями

1. Поддержка IT-инфраструктуры.

2. Внесение изменений в соответствии с принятыми регламентами.

3. Трассировка требований с документацией проекта в портале.

4. Формирование отчетов для анализа текущего состояния проекта в части работы с требованиями.

Справочник строителя | Гидротехнический бетон

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ГИДРОТЕХНИЧЕСКОМУ БЕТОНУ

В зависимости от вида и условий работы устанавливают показатели качества бетона.

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

Срок твердения (возраст) бетона, отвечающий его классам по прочности на сжатие, осевому растяжению и марке по водонепроницаемости:

для массивных гидромелиоративных сооружений и конструкций речных гидротехнических сооружений 180 сут.;

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

Срок твердения (возраст) бетона, отвечающий его проектной марке по морозостойкости, принимается 28 сут., для массивных конструкций, возводимых в теплой опалубке, — 60 сут.

Класс бетона по прочности на сжатие В определяют по сопротивлению осевому сжатию куба размером 15x15x15 см, испытанного в возрасте 180 сут. или на момент загружения, если срок фактического загружения сооружения известен (для плотин обычно 1 год). Классы бетона по прочности на сжатие: В3,5; В5; В7,5; В10; В12.5; В15; В20; В25; ВЗО; В35; В40; В45; В50; В55; В60.

Класс по прочности на осевое растяжение Вt принимают по сопротивлению-растяжению стандартных образцов, испытанных в возрасте 180 сут. при нормальном твердении. Бетон данного класса выбирают, когда работа конструкции определяется прочностью растянутого бетона или не допускается образование трещин. Классы тяжелого бетона, в том числе и гидротехнического, установлены следующие: Вt0,8; Bt1,2; Вt1 ,6; Вt2,0; напрягаемого мелкозернистого и легкого бетона: Вt2,4; Вt2,8; Вt3,2.

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

Циклом замораживания и оттаивания называется изменение термического состояния бетона, сопровождаемое фазовым переходом жидкости (вода — лед) в порах бетона.

Марки гидротехнического бетона по морозостойкости F — F50; F75; F100; F150; F200; F300; F400; F500; F600; F800; F1000 назначают с учетом климатических условий, характеризующихся среднемесячной температурой наиболее холодного месяца.

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

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

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

Установлены следующие марки по водонепроницаемости (кгс/см 2 ): W2, W4, W6, W8, W10, W12, W14, W16, W18, W20.

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

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

Таблица 1. Назначение марки бетона по водонепроницаемости

Использование системы управления требованиями Devprom в проектах заказной разработки по ГОСТ

Некоторое время назад мы анонсировали старт работ по исследованию возможностей внедрения СУТ Devprom в проектах заказной разработки по ГОСТ. В это статье описаны основные функции , а также общая метамодель системы.

Макет экрана работы с системой представлен ниже.

Точное название системы – Devprom ALM, но нас интересовал этот продукт только с точки зрения управления требованиями, по крайней мере, на начальном этапе.

Мы не хотели, да и не могли кардинально менять существующие процессы разработки, основная суть которых заключалась в требованиях ГОСТ 19, 34 и 2.105.

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

СУТ должна была позволить:

  • экспортировать/импортировать документы MS Word, содержащие форматирование стилями с использованием фильтров;
  • работать с атрибутами требований;
  • работать с запросами на изменение;
  • работать с версиями требований;
  • делать трассировки требований между собой и на задачи в Jira (в перспективе).

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

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

Варианты использования СУТ Devprom аналитиком в процессах разработки по ГОСТ

Ниже представлена диаграмма вариантов использования СУТ Devprom аналитиком в процессах разработки по ГОСТ, как мы эти варианты использования видим.

Общая метамодель Devprom

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

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

  • Проект – это область, в рамках которой ведется работа с требованиями (например, 3-я очередь развития системы).
  • Функция – это группа требований (например, модуль некой системы).
  • Требование – это собственно SMART требование, которое готовит аналитик. Мы введем типизацию и добавим необходимые атрибуты.
  • Пожелание – это кратко сформулированная «фича» для планирования итераций (в процессе Agile-разработки). В чистом виде нам не подойдет, но мы предложим, как ее можно использовать (либо можно совсем от нее отказаться).
  • Тест-кейс – сценарий проверки требования (для последующей вставки в ПМИ).

Метамодели для процессов разработки по ГОСТ

Ниже представлены варианты наших метамоделей, предлагаемых для использования в проектах разработки по ГОСТ.
Для начала будем рассматривать вариант, когда ТЗ уже есть, и аналитик привлекается для его детализации в рамках разработки техно-рабочего проекта (ТРП). Вариант, когда аналитик привлекается, когда еще нет ТЗ, также рассмотрим позже.

Использование сущности «Пожелание» для исходных требований ТЗ

Метамодель с использованием исходных требований ТЗ в качестве пожеланий представлена ниже.

ТЗ – это документ MS Word с заголовками, простыми фрагментами текста, списками, таблицами и изображениями (диаграммами и схемами).
Можно представить требования ТЗ как исходные пожелания заказчика. Возможен импорт пожеланий в СУТ, но только из MS Excel (такое ограничение только для пожеланий). Необходимо предварительно «причесать» ТЗ, преобразовав его в Excel-таблицу, выкинув все общие слова, оставив только требования к реализации (которые теперь будут называться пожеланиями).

Читайте так же:  Возврат денег от фссп

Пример таблицы с пожеланиями (формулировки из ТЗ):

Также аналитик может заносить пожелания в систему сразу, минуя Excel. Это весьма удобно, так как аналитик может оперативно фиксировать все пожелания/уточнения заказчика для дальнейшей проработки.
Далее аналитик пишет свои постановки на одно или несколько пожеланий в обычных документах MS Word, после чего импортирует эти документы в СУТ и связывает их с конкретными пожеланиями. Трассировку можно делать как целыми постановками, так и отдельными требованиями в постановках (они автоматически вычленяются по заголовкам при импорте документа). По мере разработки постановок можно смотреть покрытие пожеланий постановками.
Аналитик или тестировщик также может писать тест-кейсы для программы и методики испытаний (как в отдельных документах MS Word, так и непосредственно в web-интерфейсе СУТ) и также смотреть покрытие пожеланий/постановок/требований тест-кейсами.
После импорта постановок и тест-кейсов в СУТ возможна доработка их непосредственно в web-интерфейсе СУТ. При необходимости возможна выгрузка обратно в Word по фильтрам.
Пожелания также могут использоваться для фиксации запросов на изменение.

Использование сущности «Требование» для исходных требований ТЗ

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

Мы планируем продолжить исследования возможностей использования системы управления требованиями Devprom применительно к заказной разработке по ГОСТ.
Однако мы столкнулись с некоторыми трудностями, касающимися импорта и экспорта документов MS Word со стилями. Дело в том, что требования к оформлению документов по ГОСТ 2.105 предполагают точное стилевое оформление документов. Многочисленные стили заголовков, списков, таблиц и текста таких документов тяжело обрабатывать автоматическими анализаторами, которые разрабатывают специалисты Devprom.
Частично эту проблему удалось решить. Специалисты Devprom доработали по нашей просьбе коннектор импорта/экспорта документов в части возможности использования собственного стилевого шаблона.

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

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


Борис Сторонкин

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

7 декабря 2011 г. Президентом Российской Федерации был подписан «многострадальный» Федеральный закон № 416-ФЗ «О водоснабжении и водоотведении» (далее — Федеральный закон № 416-ФЗ), который является первым в истории законодательства Российской Федерации отраслевым законом в сфере водоснабжения и водоотведения. Данный нормативно-правовой акт предъявляет серьезные требования к предприятиям, осуществляющим сброс в канализацию сточных вод. Одним из таких требований согласно ч. 6 ст. 27 Федерального закона № 416-ФЗ является обязательное наличие локальных очистных сооружений (далее — ЛОС) у абонентов, которым установлены нормативы допустимых сбросов загрязняющих веществ, иных веществ и микроорганизмов (далее — НДС).

Ранее необходимость очистки сточных вод на очистных сооружениях была условием получения решения о предоставлении водного объекта в пользование для сброса сточных и (или) дренажных вод , типовая форма которого утверждена Приказом Минприроды России от 14.03.2007 № 56 (в ред. от 26.06.2009) (см. подп. 8, 14 п. 2.3 Приложения 1 к типовой форме). Теперь очищать сточные воды до их отведения (сброса) в централизованную систему водоотведения (далее — ЦСВ) в целях соблюдения установленных НДС должны будут и отдельные абоненты ЦСВ с использованием принадлежащих им сооружений и устройств, предназначенных для этих целей, т.е. ЛОС.

Напомним, что в соответствии с ч. 1 ст. 27 Федерального закона № 416-ФЗ в целях предотвращения негативного воздействия на окружающую среду (далее — НВОС) для объектов абонентов, категории которых определены Правительством Российской Федерации, устанавливаются НДС, а также лимиты на сбросы.

Так, согласно Постановлению Правительства РФ от 18.03.2013 № 230 «О категориях абонентов, для объектов которых устанавливаются нормативы допустимых сбросов загрязняющих веществ, иных веществ и микроорганизмов» (далее — Постановление № 230) к абонентам, для объектов которых устанавливаются НДС, относятся юридические лица, которые заключили или обязаны заключить договор водоотведения , единый договор холодного водоснабжения и водоотведения , осуществляют деятельность, связанную с производством, переработкой продукции, и которым принадлежат на праве собственности или на ином законном основании канализационные выпуски в ЦСВ. При этом среднесуточный объем отводимых (принимаемых) сточных вод с указанных объектов составляет более 200 м 3 /сут. суммарно по всем выпускам в одну ЦСВ.

На основании ч. 8 ст. 42 Федерального закона № 416-ФЗ НДС указанных абонентов и лимиты на сбросы для объектов таких абонентов должны быть установлены до 1 января 2015 г. До этого дня данные абоненты должны также обеспечить ввод в эксплуатацию ЛОС и (или) разработать планы снижения сбросов в соответствии с Положением о плане снижения сбросов загрязняющих веществ, иных веществ и микроорганизмов в поверхностные водные объекты, подземные водные объекты и на водосборные площади, утвержденным Постановлением Правительства РФ от 10.04.2013 № 317 (далее — Положение о плане снижения сбросов), и утвердить такие планы (ч. 9 ст. 42 Федерального закона № 416-ФЗ).

Однако стоит отметить, что в соответствии с п. 116 действующих на сегодняшний момент Правил холодного водоснабжения и водоотведения, утвержденных Постановлением Правительства РФ от 29.07.2013 № 644 (в ред. от 30.12.2013; далее — Правила ХВиВ), абоненты ЦСВ обязаны иметь и надлежащим образом эксплуатировать ЛОС и обеспечивать предварительную очистку сточных вод, отводимых в ЦСВ, в случаях:

  • если абоненты отнесены к определенным Правительством Российской Федерации категориям абонентов, для объектов которых устанавливаются НДС (см. Постановление № 230);
  • если на объектах абонентов осуществляются производственные процессы, указанные в приложении № 4 к Правилам ХВиВ:

В соответствии с п. 116 Правил ХВиВ абоненты, указанные в данном пункте, не имеющие ЛОС, обязаны обеспечить их строительство (создание) в течение 2 лет после вступления в силу указанных Правил, если иной срок не предусмотрен планом снижения сбросов сточных вод на объектах такого абонента, который разрабатывается и утверждается абонентом по согласованию с территориальным органом Росприроднадзора на срок до 7 лет (пп. 4, 7 Положения о плане снижения сбросов). Таким образом, указанный пункт Правил ХВиВ не только существенно расширяет круг природопользователей, обязанных иметь ЛОС, но и устанавливает другие временные границы исполнения вышеуказанных условий — до 14.08.2015 (Правила ХВиВ вступили в силу 14.08.2013).

Согласно п. 108 Правил ХВиВ отведение (прием) в ЦСВ сточных вод абонентов, обязанных в соответствии с п. 116 данных Правил использовать ЛОС, допускается только при условии обеспечения такими абонентами очистки сточных вод до их отведения в ЦСВ с использованием принадлежащих абонентам ЛОС.

Требование о наличии у абонентов ЛОС содержится также в типовом договоре водоотведения и едином типовом договоре холодного водоснабжения и водоотведения , формы которых утверждены Постановлением Правительства РФ от 29.07.2013 № 645:

А согласно пп. 36 и, соответственно, 39 данных договоров при отсутствии у абонента устройств по усреднению сточных вод и (или) ЛОС (или при их неэффективной работе) значения фактических концентраций и фактические свойства сточных вод в составе декларации о составе и свойствах сточных вод[1] определяются абонентом в интервале от среднего до максимального значения (но не ниже среднего), при этом в обязательном порядке:

Читайте так же:  Какой налог на приору в год

а) учитываются результаты, полученные в ходе осуществления контроля состава и свойств сточных вод[2], проводимого организацией водопроводно-канализационного хозяйства в порядке, утверждаемом Правительством Российской Федерации;

б) исключаются значения любого залпового или запрещенного сброса загрязняющих веществ;

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

Кроме того, в соответствии с п. 4 ч. 3 ст. 21 Федерального закона № 416-ФЗ отсутствие у абонента ЛОС или плана снижения сбросов в случаях, предусмотренных ч. 1 ст. 27 данного Федерального закона, либо неисполнение абонентом плана снижения сбросов может стать основанием для прекращения или ограничения холодного водоснабжения и (или) водоотведения, транспортировки воды и (или) сточных вод. А согласно подп. «в» п. 9 Правил осуществления контроля состава и сточных вод, утвержденных Постановлением Правительства РФ от 21.06.2013 № 525, обнаружение осуществления абонентом сбросов сточных вод без применения ЛОС либо работы ЛОС с нарушением условий их эксплуатации является основанием для проведения внепланового контроля состава и свойств сточных вод.

Отметим, что произошедшие в законодательстве изменения предусматривают не только обязательное наличие ЛОС в ряде случаев, а также финансовые, правовые или иные последствия их отсутствия, но и возможность зачета потраченных на строительство (создание) ЛОС средств в счет платы за НВОС. Так, Правила уменьшения платы за негативное воздействие на окружающую среду в случае проведения организациями, осуществляющими водоотведение, абонентами таких организаций природоохранных мероприятий, утвержденные Постановлением Правительства РФ от 17.04.2013 № 347 (далее — Правила уменьшения платы), устанавливают порядок уменьшения платы за НВОС в случае проведения абонентами организаций, осуществляющих водоотведение, природоохранных мероприятий, в т.ч. по строительству, реконструкции и модернизации очистных сооружений.

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

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

В заключение отметим, что на сегодняшний момент в сети Интернет представлен достаточно широкий выбор поставщиков и производителей ЛОС, в которых применяются разнообразные методы очистки сточных вод[3].

[1] См. разд. VIII Правил ХВиВ.

[2] Подробнее об этом см.: Севрюгина В.В. Контроль за качеством сточных вод // Справочник эколога. 2014. № 5. С. 36–42.

[3] О биологической очистке сточных вод см.:

Большаков Н.Ю. Математическое моделирование и внедрение эффективных биотехнологий очистки сточных вод от азота и фосфора на действующих очистных сооружениях канализации // Справочник эколога. 2013. № 7. С. 81–89;

Харькин С.В. Канализационные очистные сооружения: вопросы эксплуатации, экономики, реконструкции // Справочник эколога. 2013. № 8. С. 87–96;

Куликов Н.И., Куликова Е.Н., Ножевникова А.Н., Приходько Л.Н. Биотехнология очистки городских сточных вод сообществами прикрепленных микроорганизмов (биоценоз анаммокс) // Справочник эколога. 2013. № 9. С. 71–75;

Большаков Н.Ю. Глубокая биологическая очистка городских сточных вод от фосфора // Справочник эколога. 2013. № 10. С. 14–19;

Харькин С.В. Базовые подходы к разработке технологического регламента эксплуатации канализационных очистных сооружений // Справочник эколога. 2013. № 10. С. 82–96;

Большаков Н.Ю. Обеспечение эффективного биологического удаления биогенных элементов на городских очистных сооружениях // Справочник эколога. 2014. № 11. С. 92–96.

О.Н. Лаврухина, специалист по экологии и охране труда

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

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

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

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

Did you like this article? Share it with your friends!

Читайте так же:

  • Образец заявления соседей на установку забора Установка забора Здравствуйте! Как примерно выглядит письменное согласие соседей на строительство глухого забора высотой 2метра Ответы юристов (1) На самом деле, по этому вопросу существуют строительные нормы и правила РФ (СНиП 30-02-97 с изменениями от 12.03.2001г.). В этом документе, […]
  • Договор между застройщиком и инвестором Договор инвестирования в строительство Необходимым условием нового строительства выступает наличие землеотвода. По этой причине «ключевой фигурой» строительной деятельности выступает лицо, обладающее правом на земельный участок, предназначенный для этой цели. В Градостроительном кодексе […]
  • Куда можно пожаловаться анонимно Жалоба на работодателя - иногда необходимая мера Если не оплачивают больничный, не предоставляют отпуск, заставляют трудиться сверхурочно, задерживают зарплату, вы можете пожаловаться на работодателя. Ведь в его обязанность входит, к примеру, хотя бы раз в полмесяца в одно и то же число […]
  • Штраф за несделанный паспорт Штраф за несделанный паспорт Как только юному гражданину Российской Федерации исполняется 14 лет, с этого момента свидетельство о рождении больше не может служить подтверждением его личности: оно становится недействительным, и ему на смену необходимо оформлять паспорт. Паспорт – это […]
  • Приказ росаэронавигации 119 2007 Законодательная база Российской Федерации Бесплатная консультация Федеральное законодательство Главная ПРИКАЗ Росаэронавигации от 28.11.2007 N 119 "ОБ УТВЕРЖДЕНИИ ФЕДЕРАЛЬНЫХ АВИАЦИОННЫХ ПРАВИЛ "РАЗМЕЩЕНИЕ МАРКИРОВОЧНЫХ ЗНАКОВ И УСТРОЙСТВ НА ЗДАНИЯХ, СООРУЖЕНИЯХ, ЛИНИЯХ СВЯЗИ, […]