Как писать ТЭО?

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

24-я серия отменена в связи с вводом 34-ой. Поэтому пользоваться ей все же не стОит:)

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

Эврика!

Снова петербуржцы выручают!
Вот, нашел ссылочку: http://www.aanet.ru/guap/standart/tema_newpage25.shtml

Если им верить, ГОСТ 24.202-80 отменен аж с развалом Союза:

ГОСТ 24.202-80 Система технической документации на АСУ. Требования к содержанию документа"Технико-экономическое обоснование создания АСУ" (Группа Т52)-с 01.01.92 отменен, действует РД 50-34.698-90 (ИУС 4-91);

Судя по всему, теперь вместо отдельного документа "ТЭО" нужно заполнять разделы отчета, разрабатываемого на стадии "Формирование требований к АС" (требования к содержанию, в основном, соответствуют ГОСТ 24.202)

Не нашел я такого документа в ГОСТ.34. Пусть меня Алексей поправит, если не так.

Спасибо, Вадим!

Я тоже делал поиск в Технорме, и по "24.202" ничего не получил.
Сейчас сделал запрос просто по "24"
Вроде даже побольше ГОСТов 24 серии получилось, чем Вы говорите (одиннадцать насчитал). Кстати, на gost.ru карточки всех этих ГОСТ также можно найти

Насчет Вашего замечания к ГОСТ 24.104 позволю себе поправить Вас:
он не заменяет, а заменяется ГОСТом 34.603 в части разд. 3 (ГОСТ 34.603 - заменяющий)
Заменяющие пьют до дна , заменяемые тоже

Так значит, технико-экономическое обоснование ушло в прошлое? Нет закона на этот счет?

База данных «Технорма — Библиография» от апреля 2007 года дает сведения о том, что из всех ГОСТов 24. остались действующими всего четыре — 101, 501, 701 и 702. Применять ГОСТы этой серии к АС некорректно, поскольку АСУ — частный вид АС.

Да и применять-то из оставшихся стандартов 24 серии практически нечего, разве что ГОСТ 24.104-85 Единая система стандартов автоматизированных систем управления. Автоматизированные системы управления. Общие требования.

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

Он, как пишется в его аннотации, лишь заменяет ГОСТ 34.603-92 в части разд. 3.

Уважаемые коллеги!

Подскажите, плз, действует ли в настоящее время ГОСТ 24.202-80?

Пытался найти информацию на официальном сайте Федерального агентства по техническому регулированию и метрологии (http://www.gost.ru/wps/portal/pages.CatalogOfStandarts), поиск не дает результата, как, впрочем и по другим стандартам 24 серии

При этом поиск у них вроде бы работает исправно

Кроме того, этот ГОСТ относится к АСУ, поэтому корректно ли применять его в отношении автоматизированных систем, не являющихся АСУ?
И нет ли других нормативных документов, регламентирующих содержание и/или подходы к разработке "Технико-экономического обоснования" для автоматизированных систем либо программных средств?

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

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

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

Давайте более точно поставим вопрос, поскольку к информационной системе или к интернет-порталу экологию прикрутить нелегко.

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

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

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

накатал кое что, но боюсь не хватит,
вообще что можно написать при создании портала ?

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

темка уже давнишняя, но все таки попытаюсь поднять её!
Есть такой вопрос: "Что писать в Экологическом разделе?",
начинается разработка информационной системы, можно сказать портал ?!

Скорее всего, точного ответа не знает никто. Но можно пойти указанным выше путем, благо есть объекты-аналоги - предыдущие версии софтинки.

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

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

А как быть с ТЭО на апгрейд софта? Что должно быть в таком документе?

Это все от переутомления

Не факт, что имеются объекты-аналоги, НТД на них уж точно нет. А если нет объектов-аналогов, следовательно, нет и исходных данных. Нет исходных данных - откуда взяться разделам и подразделам?
А это из РД 50-34.698-90

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

Характеристики бывают количественные и качественные. Например, временные характеристики, массогабаритные и пр.
Характеристикой реализации функции может быть время ее реализации, в качественном смысле - функция может реализовываться параллельно с другой функцией, вслед за реализацией еще какой-то функции.
Допустим, функция заполнения бассейна технопарка может выполняться параллельно с функцией запирания ворот, но не ранее начала реализации функции запирания ворот. И обе функции д.б. реализованы не более, чем за 30 секунд.
Что-то вроде диаграммы Ганта в MS Project

Завис на данном разделе. Толи к вечеру активность аксоно-дендритных связей упало толи просто тупняк поймал.

2.5. Раздел «Функции и задачи создаваемой АСУ» должен содержать:

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

Сделал декомпозитцию текста, пример:

требования к характеристикам реализации функций
требования к задачам управления
требования к соответствии с действующими нормативно-техническими документами
требования, определяющими общие технические
требования к АСУ конкретного вида;

Чем заполнять не пойму.

2. Куда можно скинуть драфт ТЭО на вивисекцию.
3. Проект связан с созданием виртуального технопарка на них я не нашел НТД и сомневаюсь что есть, стоит ли это прописывать.

Хорошие вопросы

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

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

В контексте автоматизации разработки техдокументации ( http://ergd.ru/HTML/?c=8&b=1&t=sutd/toc12506.htm&o=sutd/1251.htm&n=sutd/1251.htm#o1265 ) все это должно звучать примерно так.

Как все плохо

- отсутствует типовая техническая документация согласно требованиям ГОСТ;
- не соответствует требованиям ГОСТ 2 существующая ТД на изделия;
- не соответствует требованиям ГОСТ 19 существующая ТД на программные изделия;
- нет единой электронной библиотеки типовой ТД на АС, изделия, программные изделия;
- нет жестких взаимосвязей между типовыми разделами различных документов для автоматизации внесения изменений и сквозного согласования всех видов документов;
- затруднительно внесение изменений в библиотеку типовой ТД при изменении требований ГОСТ, технических регламентов и пр.;
- невозможно централизованное внесение требуемых изменений в ТЗ, проектно-сметные, эксплуатационные документы;
- не обеспечено единство обозначений документов;
- не обеспечено единое оформления публикуемой ТД согласно ГОСТ;
- не обеспечен нормоконтроль;
- невозможна централизованная публикация (выпуск) технической документации для Заказчика и согласующих организаций;
- невозможна привязка к системе управления проектами компании.

Будет еще хуже, поскольку вот-вот потребуется проводить платную экспертизу ТЗ и ПСД в сторонних организациях (большие сроки и немыслимые деньги).

Ожидаемые преимущества после ввода системы в действие

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

Если все это еще и перевести в живые деньги (высвобождаем людей – снижаем фонд зарплаты, выгоняем субподрядчиков – получаем 100% с заказа вместо 30%), то должно все быть замечательно.