Вопросы Место задач управления функциональной безопасностью при решении задач реализации положений доктрины Industry 0
 Скачать 478.57 Kb.
|
Вопросы1. Место задач управления функциональной безопасностью при решении задач реализации положений доктрины Industry 4.0. Industry 4.0 является основой для четвертой промышленной революции – переворота в мире производства и цифровых технологий. Все технологические процессы, которые реализуются на базе Industry 4.0, должны быть гибкими, адаптивными, надежными и бережливыми. То есть производственные системы в рамках этой концепции легко перестраиваются и изменяются, но при этом сохраняют стабильность деятельности и не требуют вмешательства человека. Итак, с каждой последующей промышленной революцией рос уровень сложности, в конце концов, сегодня, в эпоху Industry 4.0 мы оказались в такой ситуации, что, промышленные системы усложняется, а их неотъемлемыми составляющими становятся программные и электронные компоненты. Последствия отказа такого оборудования тоже становятся серьезнее, так как мы все чаще доверяем функции защиты от вредных последствий этих отказов программному обеспечению и электронным элементам в составе этих систем. И, как результат, многокомпонентные и сложные системы из-за наличия даже маленькой ошибки в вычислениях, способны повлечь за собой огромные финансовые потери и настоящие техногенные катастрофы, а всё потому, что нынешние системы сильно связаны между собой. Наличие ошибки “на выходе” одной функции (подсистемы) может повлечь за собой куда большую ошибку “на входе” другой, поэтому необходимо четко определять функциональные возможности каждого блока и проверять их безопасность как по отдельности, так и в целостности, а также учитывать факторы окружающей систему среды. Также стоит вопрос цифровизации и общедоступности всей необходимой информации. Это одновременно увеличивает вероятность хищения данных и способствует “деградации” пользователей этой информации (а нехватка реальных, самостоятельных знаний, способна, в свою очередь, повлечь за собой ошибки, вызванные человеческим фактором, либо человек будет не готов в достаточной степени взять на себя работу отказавшей подсистемы). Подытоживая вышесказанное, можно с уверенностью сказать, что управление функциональной безопасностью играет важную роль в реализации доктрины Industry 4.0. 2. Место программных систем в управлении сложными системами Эффективность информационной системы (ИС) в равной степени зависит от программного обеспечения, аппаратного обеспечения и персонала. Однако ПО занимает особое место и является непосредственным центром ИС, объединяя и связывая компоненты ИС в единое целое. Это неудивительно, ведь программа – это комбинация инструкций и данных, позволяющая аппаратному обеспечению выполнять вычисления и/или функции управления. Сложные системы определяются своей структурой и целью управления. Цель же ИС - передача и обработка информации. А информация нужна для повышения качества управления этими сложными системами. То есть ИС предоставляет нам формализованную модель, благодаря которой мы можем принимать решения. Информационная система - посредник в процессе управления. Через ИС Управляющая система получают необходимую формализованную модель объекта и информацию о нём, а данные о состоянии объекта управления контролируется ИС и корректируются в соответствии с нуждами управляющей системы. Благодаря программным системам внутри ИС человеку или внешней системе потребуется меньше ресурсов для выполнения поставленной задачи, так как большую часть рутинной работы возьмёт на себя программный комплекс. Персоналу останется лишь контролировать процесс и принимать критические решения (например, об остановке работы системы или способах её починки). ПО связывает компоненты системы и определяет способы их взаимодействия между собой. Именно поэтому качество и тестирование ПО - одна из важнейших проблем, на которую стоит обращать внимание при разработке информационных систем. Потому как от качества ПО зависит качества ИС, а от качества ИС зависит функционирование сложных систем, ошибка в ПО может обойтись слишком дорого. 3. Содержание основных классов задач обеспечения безопасности программных систем Существует 3 основных класса задач обеспечения безопасности программных систем: 1) Защита от криминальных воздействий - защита информации от использования её личностями со злым умыслом. Виды: вирусы; фишинг(попытка мошенническим способом завладеть конфиденциальной информацией); Кража личности. Для защиты информации следует применять шифрование данных и проводить организационные мероприятия по повышению компьютерной грамотности сотрудников. 2) Функциональная безопасность - защита программного обеспечения от ошибок и сбоев, способных подвергнуть не приемлемому риску здоровье человека. Цель обеспечения функциональной безопасности считается достигнутой, когда каждая определённая функция обеспечения функциональной безопасности системы осуществляется практически и обеспечивает выполнение требуемых показателей. Существуют два типа отказов: - систематические отказы из-за ошибок при проектировании - случайные отказы аппаратных средств Для обеспечения информационной безопасности используются: 1. грамотное проектирование 2. тестирование всех компонентов, как порознь, так и в целом. 3) Инсайдерология - защита информации от утечки путём получения её (обычно бывшими) сотрудниками. Более 60% инцидентов нарушений связано с инсайдерологией. Для устранения проблемы “на корню”, были созданы методики для проверки природных способностей студентов, но, к примеру, результаты методики Дж. Баррета выявили, что почти 42% подготавливаемых специалистов по направлению “Информационная безопасность” не соответствовало требованиям методики. При трудоустройстве производят отбор по профессиональным(a) и моральным(b) качествам. Моральные качества оцениваются по состоянию духовной среды. Существует технология оценки моральных качеств. Проведенное исследование показало сильную связь моральных качеств с числом зарегистрированных компьютерных преступлений (корреляция более 0.7). Для борьбы с инсайдерологией используются: минимальный доступ; мониторинг интернет-трафика; системы мониторинга рабочих станций и электронной почты; организационные меры; комплексные решения. 4. Признаки и последствия кризиса в IT Причина: недостаточно развитые технологии в вопросах психологии субъектов (психология программирования, проблемы коммуникации между заказчиком и исполнителем и т.д.). Причина кризиса: Кризис - приход к тому, что существующую проблему известными способами решить нельзя. Перед IT стоят задачи, которые она пытается решить, но старыми способами. В результате эти задачи не решаются или решаются плохо. В настоящее время недочетов в программных проектах больше, чем было 5-10 лет назад, несмотря на радикальное повышение зрелости инструментальных средств и реализаций технологий программных продуктов. Примеры: ● отсутствие научных разработок; ● недостаточная вовлеченность пользователей; ● нечеткие цели и нереалистичные временные границы; ● отсутствие новых идей; ● низкое качество ПО; ● полученный опыт, перенесенный в другую проектную область. Последствия: 37% проектов завершается успешно, 42% выбиваются из бюджета/сроков и 21% проваливаются. Примеры последствий: ● могут потребоваться значительные переделки проекта, сроки и бюджет будут значительно превышены; ● проект не будет соответствовать потребностям заказчика, если часть целей проекта не будет достигнута, либо будет, но не как планировалось. Это приводит к неуспешному завершению проекта. 5. Содержание основных факторов провала программных проектов Основными факторами провала программных средств являются: 1) Недостаточная вовлеченность пользователей. Очень часто ответственность за ИТ-проект полностью перекладывается на ИТ-отдел. Порой ИТ-проекты значительного размера заканчиваются практически без какого-либо вмешательства функциональных заказчиков, потому что заказчики ждут, пока проект будет завершен, и только потом дают ему какие-либо оценки. 2) Неполные требования и спецификации. Большинство заказчиков ИТ-проектов не готовы платить за полноценный сбор и анализ требований те деньги, которых это действительно стоит. Это приводит к тому, что оценить проект исполнителю по тем требованиям, которые есть для оценки крайне сложно, и он оценивает прогнозную трудоемкость проекта слишком оптимистично. 3) Изменения в требованиях и спецификациях. Проявляется этот фактор в том, что на стороне заказчика хотят сразу сделать идеальный продукт и не принимают позицию, связанную с тем, что пользователям все равно что-то не понравится в программном продукте, поэтому важно максимально быстро запустить ключевой функционал, а потом потихоньку дорабатывать другие функции. По статистике, 20% от оплаченного функционала приобретенной ИТ-системы используются пользователями часто, еще 30% функций используются редко и 50% от приобретенного функционала ИТ-системы не используются практически никогда. 4) Недостаточная поддержка со стороны руководства. Зачастую бывает так, что руководство проекта недостаточно или даже почти не вовлечено в процесс разработки, что приводит к недопониманию и недоверию между руководством и разработчиками. 5) Низкая квалификация сотрудников. Недостаток квалификации сотрудников приводит к ухудшению качества готового продукта. 6) Недостаток ресурсов. Проявляется в недостатке денежных средств, сотрудников, времени и т.д. 7) Нереалистичные ожидания. Нереалистичные ожидания приводят к неправильной оценке временных границ, завышенным требованиям к продукту. 8) Нечеткие цели. Это проявляется на уровне самих формулировок целей проекта 9) Нереалистичные временные границы проекта. Являются по большей части следствием других факторов 10) Новые технологии. Проявляются в изменении программно-аппаратных средств, подходов к разработке и тестированию. Как видно, основными факторами провала являются психологические, а не технические. 6. Содержание основных факторов успеха программных проектов 1. Вовлеченность пользователей - если приложение полезно и интересно определённому(широкому) кругу лиц, то эти люди примут активное участие в разработке и тестировании приложения. Они будут помогать отлавливать ошибки и предлагать идеи по улучшению качества старой или внедрению новой функциональности. Вовлеченность пользователей происходит, когда пользователи участвуют в процессе принятия решений и сбора информации о проекте. Сюда также входят отзывы пользователей, анализ требований, базовые исследования, создание прототипов и другие инструменты для достижения консенсуса. 2. Участие кураторов - если высшее руководство заинтересовано в обеспечении качества продукта, оно обязательно должно предоставить комфортные условия труда и все необходимые блага и ресурсы своим разработчикам. Участие кураторов когда руководитель или группа руководителей соглашаются оказать финансовую и эмоциональную поддержку разработчикам. Руководитель или руководители будут поощрять и помогать им в успешном завершении проекта. 3. Ясные бизнес-цели. Бизнес-цели - то ради чего и создаётся система и относительно чего и должны формироваться требования к ней. Наличие чётко поставленных бизнес-целей помогает сформулировать начальные требования, уменьшить неопределённость проекта на начальных этапах и точнее спрогнозировать предполагаемые расходы и временные затраты. Ясные бизнес-цели - это понимание всеми заинтересованными сторонами и участниками бизнес-целей для реализации проекта. Четкие бизнес-цели также могут означать, что проект соответствует целям и стратегии организации. 4. Эмоциональная зрелость - это совокупность базовых моделей поведения людей. В любой группе, организации или компании — это как сумма их навыков, как сильных, так и слабых сторон, которые определяют уровень эмоциональной зрелости. 5. Организация проекта - грамотное планирование сроков и времени выполнения, выделение подзадач и формирование к ним требований - всё это признаки хорошей организации проекта. Уровень организации определяется совокупностью интегрированных практик, сервисов и программных продуктов для разработки, внедрения и эксплуатации программных приложений. 6. Скорость реализации процессов - важнее представить проект вовремя, чем просто представить его. Если затянуть сроки реализации, то полученный проект будет соответствовать устаревшим требованиям, либо, в худшем случае, сам проект уже будет не нужен. 7. Управление проектом - процесс планирования, организации, обеспечения персоналом, отслеживания состояния, контроля и лидерства в программном проекте. 8. Квалификация персонала - наличие опыта в разработке, в том числе похожих проектов. 9. Контроль управления - общая оценка качества и надзор за соблюдением поставленных требований и ограничений. 10. Инструменты и инфраструктура - аппаратно-программные, технические средства и их качество 7. Модель «конус неопределенности» и её интерпретация Конус неопределённости - это модель, которая отражает то, что в течение жизненного цикла программного продукта изначально высокий уровень неопределенности, относительно его свойств, уменьшается до нуля. В начале разработки любого ПО имеется некая неопределённость, которая отражает объективную сложность проекта. Эта неопределённость выражается в затрачиваемых времени и ресурсах (бюджет), а также в том, какой результат мы ожидаем. То есть мы не можем точно сказать, сколько времени и денег мы потратим на создание программного продукта и не знаем, понравится ли заказчику то, что мы сделаем. Разная степень неопределённости приводит к тому, что на разных стадиях жизненного цикла программного продукта нужно использовать разные подходы к формированию требований и разные формы их представлений. Каждая фаза жизненного цикла достаточно условна, но должна быть логически завершённой, а её результатом должно быть нечто, имеющее самостоятельную ценность. И тогда, после каждой фазы я могу осуществить контроль качества результата. Из этого можно сделать следующие вывод, что на каждой фазе жизненного цикла ПО: я могу привлекать различных специалистов; могу привлекать этих специалистов, когда это необходимо, для каждого этапа я могу сформировать критерии качества. В ходе разработки желательно на каждом этапе жизненного цикла общаться с заказчиком, уточнять требования, поскольку формирование “хороших” требований - итерационная процедура, причём эти же требования могут по-разному восприниматься заказчиком и разработчиком. 8. Роль дисциплины при проектировании сложных программных систем (слайд 37) При проектировании сложных программных систем в условиях неопределённости можно выделить 2 основных подхода: 1) Подход 1: руководителем проекта является человек, который хорошо разбирается в том, как создавать локальные проекты, но имеет мало опыта в разработке больших, многокомпонентных систем. В сложном проекте с большой неопределённостью он не знает, за что взяться и поэтому решает реализовывать то, что ему и его команде понятно на данный момент. В результате программируется множество блоков кода, для которых никто не определяет требования по входам и выходам. И в конечном итоге очень сложно или попросту невозможно объединить эти “кусочки” в единое целое и выпустить готовый программный продукт. 2) Подход 2: в начале тщательно планируется ход проекта и разрабатывается система управления, к каждому блоку предъявляются требования по входам и выходам. Тесты прогоняются от простого к сложному, т.е. сначала тестируем локальные блоки кода, а потом тестируются их взаимодействие на внешнем уровне. — Если “дисциплина” - трудовая дисциплина Таким образом, отсутствие дисциплины в разработке и планировании проекта, как это показано в первом подходе, порождает большое количество проблем, на решение которых может уйти куда больше времени, нежели если бы мы изначально всё продумали, проанализировали и спланировали. Спешка, неопытность и желание получить всё и сразу зачастую приводят к тому, что все недовольны: и заказчик, и сам разработчик, а результата как не было, так и нет, и поэтому приходится начинать разработку заново либо признать проект провальным и закрыть его. — Если “дисциплина” - предмет (оценка качества и тестирование ПО) Таким образом, можно сказать, что обеспечить качество разрабатываемого программного продукта можно только путём тщательного планирования и тестирования. При втором подходе руководитель определил систему управления, предъявил требования к оценке качества как каждого блока по отдельности, так и всей системы, чем не только упростил процесс отладки продукта, но и повысил надёжность своей разработки. 9. Место моделей жизненного цикла в управлении программными проектами. Область применения модели Code-and-fix Модели жизненного цикла помогают разработчикам: 1) распределять обязанности, 2) позволяет примерно оценить сложность проекта и возможность его реализации, 3) помогает понять, где и как применять доступный инструментарий разработки, 4) позволяет грамотно организовать управление проектом и выделенными ему ресурсами. Таким образом, модели ЖЦ обеспечивают более высокое качество управления программными проектами. Модели ЖЦ упрощают жизнь разработчиков и менеджеров проекта. На рисунке — это модель проб и ошибок. В данной модели приходится строить продукт заново каждый раз до тех пор, пока клиент не будет доволен, не будет удовлетворен. Цикл «модифицировать до удовлетворения клиента» представляет собой наибольшую сложность. Характерной особенностью данной модели разработки программного обеспечения является то, что первичным условием является разработка детальных спецификаций, и реализация программного продукта без существенной концептуальной проработки решения, без архитектурного проектирования, без первичного проектирования. Тут возникает проблема трудности модификации и развития ПП из-за недостаточно проработанной проектной стадии. Вследствие того, что задача кодировалась, как понималась, то есть стадия изучения и согласования пользовательских требований реализовывалась посредством экспериментирования с уже готовой программой, функциональные возможности редко полностью согласуются с требованиями заказчика. То есть нам нужно повторить полный цикл разработки до тех пор, пока не будет получен тот продукт, который заказчика удовлетворяет. Тогда этот продукт, вместе с документацией, которая в данном случае тоже является достаточно сокращенной, передается заказчику и наступает стадия сопровождения. Но важным вопросом остается, сколько раз придется разработчикам этот цикл разработки повторять? В этом существенная сложность и проблема данного подхода. Поскольку полный цикл разработки — это достаточно дорогостоящее мероприятие, может получиться так, что те затраты, которые мы понесем в итоге, не окупятся за счет той экономии на первичных стадиях, анализ и первичное проектирование, архитектурное проектирование, которое нам придется из этого жизненного цикла в данном случае выбросить. Используя Code-and-Fix, мы только пишем код. Здесь все очень просто: нет необходимости что-либо планировать, нет необходимости что-либо документировать. Поэтому Code-and-Fix требует минимальной квалификации разработчиков. Но как показал опыт, такой подход очень скоро приводит к коду, который невозможно поддерживать: исправление одной ошибки приводит к появлению нескольких новых; внесение минимальных изменений в одну из частей программы, приводит к разрушению функций, реализуемых другими частями. Таким образом данная модель подходит для разработки небольших программных продуктов(примерно до 1000 строк кода). Область применения этой модели невелика, однако она подойдет стартапам, где команда невелика, нет особых конфликтов, вы знаете, что хотите сделать и имеете представление, как это сделать. |