Надо думать не о том, как бежать за увеличением объема информации, а про ее упорядочение и фильтрацию. Когда постоянно репостят накачанные губы, никаких накопителей не хватит)
Просто статистика:
каждую минуту через Uber заказывают 45 787 машин, Spotify добавляет 13 новых песен, пользователи Twitter постят 456 000 постов, в Instagram появляется 46 740 новых фотографий, поисковик Google реагирует на 3,6 миллиона запросов, на Wikipedia появляется 600 новых правок.
Сейчас совокупный общемировой объем хранимой информации около 20 экзабайт (10 в 21-й степени), к 2025 году ожидается более 150 экзабайт. Из них только 60% будут промышленные данные, причем это в основном интернет вещей.
Проблема информационного мусора пока не слишком очевидна, но он скоро завалит нашу планету. Пора разрабатывать ИнфоВалли.
Хотя, чисто не там, где убирают, а там, где не мусорят...
Было изменено 6 ГОСТ'ов. В части РД 50-34.698-90 вместо него вышел ГОСТ Р 59795-2021. Содержание нового ГОСТа было изменено под текущие реалии, но не кардинально, т.к. основные требования к АС и ее компонентам, изложенные в других ГОСТ, сильно не изменились. Помимо этого ГОСТ, были откорректированы и другие. Атавизмы и архаизмы по возможности были удалены или изменены под современные реалии. Знаю об этом не понаслышке, довелось принять участие в этой работе.
Документация на создаваемые системы, стоящие гораздо дороже, чем современные поделки типа "Hello, world", нужна и важна не только для разработчиков, но и для последующих доработчиков, которые будут сопровождать и дорабатывать сложнейшие системы со сроком эксплуатации десяток лет, а также персонала на объекте автоматизации. Не говоря уже о массе контролирующих органов...
Тема создания автоматизированных систем в последнее время немного затухает. Наши отцы делали интересные вещи, многое работает до сих пор. И документация сохранилась, т.к. была обязательной.
Что будут читать наши дети, чтобы понять, как работает сделанная на коленке по Agile и как-то еще работающая софтверная поделка? Confluence? Canban? Или полезут в Git?
каждую минуту через Uber заказывают 45 787 машин, Spotify добавляет 13 новых песен, пользователи Twitter постят 456 000 постов, в Instagram появляется 46 740 новых фотографий, поисковик Google реагирует на 3,6 миллиона запросов, на Wikipedia появляется 600 новых правок.
Сейчас совокупный общемировой объем хранимой информации около 20 экзабайт (10 в 21-й степени), к 2025 году ожидается более 150 экзабайт. Из них только 60% будут промышленные данные, в основном интернет вещей.
Проблема информационного мусора пока не слишком очевидна, но он скоро завалит нашу планету. И никакие микросервисы не спасут...
Для чего это все? Чтобы хранить больше фоток в инсте с едой и шмотками?
Надо думать не о том, как бежать за увеличением объема информации, а про ее упорядочение и фильтрацию. Когда постоянно репостят накачанные губы, никаких накопителей не хватит)
Все именно так и есть. Практически во всех проектах возникает проблема исходных данных и их качества. Как правило, разработка в основном ведется на исходных данных типа "ООО "Ромашка" и "Иванов Иван Иванович" (или том, что придумает сам разработчик). А потом реальные данные в систему не лезут(
Частично решает проблему этап опытной эксплуатации, на котором разработчики сталкиваются с реальными данными и наконец начинают что-то осознавать. Но иногда это оказывается слишком поздно...
Весьма полезный материал, позволяющий учесть и избежать некоторых распространенных ошибок при подготовке и в ходе выполнения работ, предусматривающих взаимодействие с другими разработчиками. Регулярно сталкиваемся с такими проблемами. Решение в каждом конкретном случае свое, специфичное. Но в общем тенденции подмечены верно.
Очень хороший аналитический обзор по требованиям стандартов с уклоном на вопросы защиты информации. К сожалению, при корректировке упомянутых ГОСТ 34-й серии, в которой нам довелось принять участие, в составе экспертной группы не было специалистов по защите информации. Возможно, поэтому не все было учтено.
1. По первому замечанию хотелось бы отметить, что ничего «из ГОСТов 19, 34 и РВ, РД 50» в тексте нет. Автор этого замечания, похоже, не читал не только статью, но и эти ГОСТы и прочую «древнюю чушь», не говоря уже о современных нормативно-технических документах. Впрочем, общеизвестно, что кодеры НТД не читают (не все, были у меня интересующиеся ребята, выросли хорошо). Как правило, и проблемы создания систем кодеров тоже не интересуют.
Вы удивитесь, но во всех перечисленных вами НТД практически ничего нет про ИЛО и его разработку. Кроме терминов и требований к некоторым документам.
Проблема формирования нормальной нормативно-технической базы в части ИЛО давно назрела. В одном из закрытых ГОСТ РВ была попытка детализировать требования к ИЛО, но, по общему мнению разработчиков ИЛО, не совсем удачная.
2. Формат статей на Хабре не позволяет развернуто описать все тонкости и нюансы столь большой тематики, как ИЛО. По аналогии, можно предположить, что никто в здравом уме не возьмется здесь описать все проблемы создания ПО в одной статье. Изначально рассматривался вариант написания серии статей, последовательно раскрывающих проблематику создания ИЛО. Но потом возникло сомнение, что на данной площадке это может быть востребовано. Поэтому был выбран обзорный вариант освещения проблемы и путей ее решения.
Для упрощения навигации по материалу уточняю.
Ответ на вопрос «как» начинается с 15 абзаца. Ссылки на опыт и новые решения – с 21 абзаца.
Конкретных инструкций типа «делай раз, делай два» для выполнения действий по разработке ИЛО в статье нет. Это не литература «для чайников» и не онлайн-курсы.
3. Книга 1987 года, из которой приведена выдержка, была хороша для своего времени развития автоматизации. Мы в свое время с интересом читали все новое, что выходило по тематике автоматизации. Хабра в то время не было, интернета тоже. И многое из тех старых идей по-прежнему востребовано и широко используется, пусть и в современной обертке.
К сожалению, базы знаний так и не используются для обеспечения информационной интеграции автоматизированных систем.
Осталось непонятным, какое отношение это имеет к статье?
4. Целью статьи был не самопиар, а попытка заострить внимание на проблеме. Все что написано, результат опыта, полученного нашей командой разработчиков ИЛО в ходе реализации достаточно большого количества проектов в области автоматизации на уровнях ФГИС/ведомство/корпорация.
Повторюсь.
Надо думать не о том, как бежать за увеличением объема информации, а про ее упорядочение и фильтрацию. Когда постоянно репостят накачанные губы, никаких накопителей не хватит)
Просто статистика:
каждую минуту через Uber заказывают 45 787 машин, Spotify добавляет 13 новых песен, пользователи Twitter постят 456 000 постов, в Instagram появляется 46 740 новых фотографий, поисковик Google реагирует на 3,6 миллиона запросов, на Wikipedia появляется 600 новых правок.
Каждую минуту рассылается 103 447 520 спам-сообщений.
Сейчас совокупный общемировой объем хранимой информации около 20 экзабайт (10 в 21-й степени), к 2025 году ожидается более 150 экзабайт. Из них только 60% будут промышленные данные, причем это в основном интернет вещей.
Проблема информационного мусора пока не слишком очевидна, но он скоро завалит нашу планету. Пора разрабатывать ИнфоВалли.
Хотя, чисто не там, где убирают, а там, где не мусорят...
Было изменено 6 ГОСТ'ов. В части РД 50-34.698-90 вместо него вышел ГОСТ Р 59795-2021. Содержание нового ГОСТа было изменено под текущие реалии, но не кардинально, т.к. основные требования к АС и ее компонентам, изложенные в других ГОСТ, сильно не изменились. Помимо этого ГОСТ, были откорректированы и другие. Атавизмы и архаизмы по возможности были удалены или изменены под современные реалии. Знаю об этом не понаслышке, довелось принять участие в этой работе.
Документация на создаваемые системы, стоящие гораздо дороже, чем современные поделки типа "Hello, world", нужна и важна не только для разработчиков, но и для последующих доработчиков, которые будут сопровождать и дорабатывать сложнейшие системы со сроком эксплуатации десяток лет, а также персонала на объекте автоматизации. Не говоря уже о массе контролирующих органов...
Тема создания автоматизированных систем в последнее время немного затухает. Наши отцы делали интересные вещи, многое работает до сих пор. И документация сохранилась, т.к. была обязательной.
Что будут читать наши дети, чтобы понять, как работает сделанная на коленке по Agile и как-то еще работающая софтверная поделка? Confluence? Canban? Или полезут в Git?
Тоже не шибко умно.
Просто статистика:
каждую минуту через Uber заказывают 45 787 машин, Spotify добавляет 13 новых песен, пользователи Twitter постят 456 000 постов, в Instagram появляется 46 740 новых фотографий, поисковик Google реагирует на 3,6 миллиона запросов, на Wikipedia появляется 600 новых правок.
Каждую минуту рассылается 103 447 520 спам-сообщений.
Сейчас совокупный общемировой объем хранимой информации около 20 экзабайт (10 в 21-й степени), к 2025 году ожидается более 150 экзабайт. Из них только 60% будут промышленные данные, в основном интернет вещей.
Проблема информационного мусора пока не слишком очевидна, но он скоро завалит нашу планету. И никакие микросервисы не спасут...
Для чего это все? Чтобы хранить больше фоток в инсте с едой и шмотками?
Надо думать не о том, как бежать за увеличением объема информации, а про ее упорядочение и фильтрацию. Когда постоянно репостят накачанные губы, никаких накопителей не хватит)
Все именно так и есть. Практически во всех проектах возникает проблема исходных данных и их качества. Как правило, разработка в основном ведется на исходных данных типа "ООО "Ромашка" и "Иванов Иван Иванович" (или том, что придумает сам разработчик). А потом реальные данные в систему не лезут(
Частично решает проблему этап опытной эксплуатации, на котором разработчики сталкиваются с реальными данными и наконец начинают что-то осознавать. Но иногда это оказывается слишком поздно...
Весьма полезный материал, позволяющий учесть и избежать некоторых распространенных ошибок при подготовке и в ходе выполнения работ, предусматривающих взаимодействие с другими разработчиками. Регулярно сталкиваемся с такими проблемами. Решение в каждом конкретном случае свое, специфичное. Но в общем тенденции подмечены верно.
Очень хороший аналитический обзор по требованиям стандартов с уклоном на вопросы защиты информации. К сожалению, при корректировке упомянутых ГОСТ 34-й серии, в которой нам довелось принять участие, в составе экспертной группы не было специалистов по защите информации. Возможно, поэтому не все было учтено.
Пояснения по накопившимся вопросам.
1. По первому замечанию хотелось бы отметить, что ничего «из ГОСТов 19, 34 и РВ, РД 50» в тексте нет. Автор этого замечания, похоже, не читал не только статью, но и эти ГОСТы и прочую «древнюю чушь», не говоря уже о современных нормативно-технических документах. Впрочем, общеизвестно, что кодеры НТД не читают (не все, были у меня интересующиеся ребята, выросли хорошо). Как правило, и проблемы создания систем кодеров тоже не интересуют.
Вы удивитесь, но во всех перечисленных вами НТД практически ничего нет про ИЛО и его разработку. Кроме терминов и требований к некоторым документам.
Проблема формирования нормальной нормативно-технической базы в части ИЛО давно назрела. В одном из закрытых ГОСТ РВ была попытка детализировать требования к ИЛО, но, по общему мнению разработчиков ИЛО, не совсем удачная.
2. Формат статей на Хабре не позволяет развернуто описать все тонкости и нюансы столь большой тематики, как ИЛО. По аналогии, можно предположить, что никто в здравом уме не возьмется здесь описать все проблемы создания ПО в одной статье. Изначально рассматривался вариант написания серии статей, последовательно раскрывающих проблематику создания ИЛО. Но потом возникло сомнение, что на данной площадке это может быть востребовано. Поэтому был выбран обзорный вариант освещения проблемы и путей ее решения.
Для упрощения навигации по материалу уточняю.
Ответ на вопрос «как» начинается с 15 абзаца. Ссылки на опыт и новые решения – с 21 абзаца.
Конкретных инструкций типа «делай раз, делай два» для выполнения действий по разработке ИЛО в статье нет. Это не литература «для чайников» и не онлайн-курсы.
3. Книга 1987 года, из которой приведена выдержка, была хороша для своего времени развития автоматизации. Мы в свое время с интересом читали все новое, что выходило по тематике автоматизации. Хабра в то время не было, интернета тоже. И многое из тех старых идей по-прежнему востребовано и широко используется, пусть и в современной обертке.
К сожалению, базы знаний так и не используются для обеспечения информационной интеграции автоматизированных систем.
Осталось непонятным, какое отношение это имеет к статье?
4. Целью статьи был не самопиар, а попытка заострить внимание на проблеме. Все что написано, результат опыта, полученного нашей командой разработчиков ИЛО в ходе реализации достаточно большого количества проектов в области автоматизации на уровнях ФГИС/ведомство/корпорация.