Вопросы Место задач управления функциональной безопасностью при решении задач реализации положений доктрины Industry 0

• Название: Вопросы Место задач управления функциональной безопасностью при решении задач реализации положений доктрины Industry 0
• Дата: 02.07.2022
• Размер: 478.57 Kb.
• Имя файла: OKiTPO_teoria.docx
• Тип: Документы; #623165
• страница: 2 из 4

10. Место моделей жизненного цикла в управлении программными проектами. Область применимости модели Stagewise Model Модели жизненного цикла помогают разработчикам: 1) распределять обязанности, 2) позволяет примерно оценить сложность проекта и возможность его реализации, 3) помогает понять, где и как применять доступный инструментарий разработки, 4) позволяет грамотно организовать управление проектом и выделенными ему ресурсами. Таким образом, модели ЖЦ обеспечивают более высокое качество управления программными проектами. Модели ЖЦ упрощают жизнь разработчиков и менеджеров проекта. Итеративная разработка ПО — это процесс создания программного обеспечения, который осуществляется небольшими этапами, в ходе которых ведется анализ полученных промежуточных результатов, выдвигаются новые требования и корректируются предыдущие этапы работы. В рамках одной итерации разрабатывается не весь проект, а только его версия или отдельная часть. Как правило, цель каждой итерации — это создание новой версии ПО на основе старой, с добавлением нового или переработка старого функционала. Результат же финальной итерации содержит всю требуемую функциональность продукта. Только очень простые задачи проходят все этапы без каких-либо итераций — возвратов на предыдущие шаги производственного процесса. При программировании, например, может обнаружиться, что реализация некоторой функции очень громоздка, неэффективна и вступает в противоречие с требуемой от системы производительностью. В этом случае необходимо перепроектирование, а может быть, и переделка спецификаций. При разработке больших нетрадиционных систем итеративность возникает регулярно на любом этапе жизненного цикла как из-за допущенных на предыдущих шагах ошибок и неточностей, так и из-за изменений внешних требований к условиям эксплуатации системы. Разработка программного продукта по этой модели сводится к следующей последовательности действий: ● Планирование разработки. ● Разработка операционной спецификации. ● Кодирование. ● Параметрическое тестирование модулей. ● Тестирование сборки. ● Опытную эксплуатацию. ● Оценку системы пользователем. Область применения: итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.

11. Место моделей жизненного цикла в управлении программными проектами. Область применимости водопадной (Waterfall) модели Модели жизненного цикла помогают разработчикам: 1) распределять обязанности, 2) позволяет примерно оценить сложность проекта и возможность его реализации, 3) помогает понять, где и как применять доступный инструментарий разработки, 4) позволяет грамотно организовать управление проектом и выделенными ему ресурсами. Таким образом, модели ЖЦ обеспечивают более высокое качество управления программными проектами. Модели ЖЦ упрощают жизнь разработчиков и менеджеров проекта. Существенной особенностью водопадной модели, является однопроходная разработка без циклических повторений. Другим существенным аспектом, как мы видим, на каждой стадии является непременное условие верификации. То есть, что происходит при подобного рода разработке: разработчик и заказчик по завершении каждой стадии подписывают документ, который называется, например, архитектурный проект, эскизный проект, детальный проект, техническое задание и т. д. И в результате, после того как данная стадия закрыта, мы переходим к следующей стадии — первичное проектирование, детальное проектирование, реализация, интеграция, сопровождение и к предыдущим стадиям мы уже не возвращаемся. То есть проверка происходит даже при переходе от первой стадии ко второй (от User Requirements к Software Requirements) , назначение этой проверки - отлавливать ошибки перевода из языка User к языку Software. Достоинства модели: 1) Проект, выполняемый по этой модели очень предсказуем. По окончании проекта вы получаете именно тот продукт, который был изначально запланирован. 2) Требования к квалификации программистов снижены. Только этапы проектирования требуют наличия высококвалифицированных специалистов, реализация может осуществляться начинающими программистами. 3) Проект хорошо масштабируется. После завершения высокоуровневого проектирования работа по созданию разных модулей может проходить независимо друг от друга. Их могут реализовывать разные группы программистов, в том числе существенно разделенные географически 4) водопадная модель очень экономна. В ней отсутствует необходимость дважды делать одну и ту же работу, и это существенно сокращает и время, и материальные затраты. Недостатки модели: 1) заказчик получает готовый продукт только в самом конце разработки. Причем типичный проект может занимать от одного года до нескольких лет. 2) заранее сформулировать требования может далеко не каждый заказчик; даже если он сможет это сделать, он сделает это на своем языке, который отличается от языка разработчиков. Область применения: применяют для создания программ, к качеству которых предъявляются высокие требования: авионика, системы управления критическими производствами, высококачественные системы информационной безопасности. 5 этапов модели: - аналитика. Команда собирает требования к будущему продукту. Потом пишет подробное техническое задание, планирует график работ и возможные риски. Переходит к следующему этапу, только когда все требования прописаны и есть план. А в плане — инструкции, что и когда делать. - проектирование. Команда создаёт прототип и готовит дизайн-макеты. Когда это готово, подключаются разработчики. - разработка. На этом этапе пишут код продукта согласно плану, макетам и требованиям. Ни шагу в сторону, всё четко по ТЗ. - тестирование. Код готов, начинается тестирование. Тут могут появиться проблемы. Например, команда обнаружит серьёзные ошибки в коде и потратит много времени, чтобы их исправить. Это главный минус каскадной модели разработки. - эксплуатация и поддержка. Проект передают заказчику и следят заранее определённое время, чтобы всё работало.

12. Место моделей жизненного цикла в управлении программными проектами. Область применимости модели эволюционного развития (инкрементальной модели) Модели жизненного цикла помогают разработчикам: 1) распределять обязанности, 2) позволяет примерно оценить сложность проекта и возможность его реализации, 3) помогает понять, где и как применять доступный инструментарий разработки, 4) позволяет грамотно организовать управление проектом и выделенными ему ресурсами. Таким образом, модели ЖЦ обеспечивают более высокое качество управления программными проектами. Модели ЖЦ упрощают жизнь разработчиков и менеджеров проекта Предпосылками к её созданию являлось совершенствование аппаратных средств, потребность в реализации более сложных ИС. Возникла проблема - система очень сложна и имеющимися ресурсами реализовать её сразу было невозможно, поэтому решили создавать систему по частям. Инкрементная (эволюционная) разработка представляет собой процесс частичной реализации всей системы и медленного наращивания функциональных возможностей. Этот подход позволяет уменьшить затраты, понесенные до момента достижения уровня исходной производительности. С помощью этой модели ускоряется процесс создания функционирующей системы. Этому способствует применяемый принцип компоновки из стандартных блоков, благодаря которому обеспечивается контроль над процессом разработки изменяющихся требований. При использовании инкрементной модели рано формируются пригодные к эксплуатации функциональные возможности. Для реализации проекта необходимо заранее сформулировать требования, а в ходе разработки их уточнять и реализовывать. Область применения инкрементной модели: ● если большинство требований можно сформулировать заранее, но их появление ожидается через определенный период времени; ● если рыночное окно слишком "узкое" и существует потребность быстро поставить на рынок продукт, имеющий функциональные базовые свойства; ● для проектов, на выполнение которых предусмотрен большой период времени разработки, как правило, один год; ● при равномерном распределении свойств различной степени важности. Модель включает в себя процессы: - определение требований - разработка (проектирование, конструирование) - верификация, валидация, тестирование - изготовление - эксплуатация - сопровождение

13. Место моделей жизненного цикла в управлении программными проектами. Область применимости V- модели Модели жизненного цикла помогают разработчикам: 1) распределять обязанности, 2) позволяет примерно оценить сложность проекта и возможность его реализации, 3) помогает понять, где и как применять доступный инструментарий разработки, 4) позволяет грамотно организовать управление проектом и выделенными ему ресурсами. Таким образом, модели ЖЦ обеспечивают более высокое качество управления программными проектами. Модели ЖЦ упрощают жизнь разработчиков и менеджеров проекта Основной принцип V-образной модели заключается в том, что детализация проекта возрастает при движении слева направо, одновременно с течением времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы. Применительно к разработке информационных систем V-Model — вариация каскадной модели, в которой задачи разработки идут сверху вниз по левой стороне буквы V, а задачи тестирования — вверх по правой стороне буквы V. Внутри V проводятся горизонтальные линии, показывающие, как результаты каждой из фаз разработки влияют на развитие системы тестирования на каждой из фаз тестирования. Модель базируется на том, что приёмо-сдаточные испытания основываются, прежде всего, на требованиях, системное тестирование — на требованиях и архитектуре, комплексное тестирование — на требованиях, архитектуре и интерфейсах, а компонентное тестирование — на требованиях, архитектуре, интерфейсах и алгоритмах Цели: V-модель обеспечивает поддержку в планировании и реализации проекта. В ходе проекта ставятся следующие задачи: Минимизация рисков: V-образная модель делает проект более прозрачным и повышает качество контроля проекта путём стандартизации промежуточных целей и описания соответствующих им результатов и ответственных лиц. Это позволяет выявлять отклонения в проекте и риски на ранних стадиях и улучшает качество управления проектов, уменьшая риски. Повышение и гарантии качества: V-Model — стандартизованная модель разработки, что позволяет добиться от проекта результатов желаемого качества. Промежуточные результаты могут быть проверены на ранних стадиях. Универсальное документирование облегчает читаемость, понятность и проверяемость Уменьшение общей стоимости проекта: ресурсы на разработку, производство, управление и поддержку могут быть заранее просчитаны и проконтролированы. Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает затраты на последующие стадии и проекты. Повышение качества коммуникации между участниками проекта: Универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта. Таким образом, уменьшаются неточности в понимании между пользователем, покупателем, поставщиком и разработчиком. Достоинства: Пользователи V-Model участвуют в разработке и поддержке V-модели. Комитет по контролю за изменениями поддерживает проект и собирается раз в год для обработки всех полученных запросов на внесение изменений в V-Model На старте любого проекта V-образная модель может быть адаптирована под этот проект, так как эта модель не зависит от типов организаций и проектов V-model позволяет разбить деятельность на отдельные шаги, каждый из которых будет включать в себя необходимые для него действия, инструкции к ним, рекомендации и подробное объяснение деятельности Ограничения: Следующие моменты не учитываются в V-модели, но могут быть рассмотрены отдельно, либо возможно адаптировать модель под них: - Не регулируется размещение контрактов на обслуживание. - Организация и выполнение управления, обслуживания, ремонта и утилизации системы не учитываются в V-модели. Однако, планирование и подготовка к этим операциям моделью рассматриваются. - V-образная модель больше касается разработки программного обеспечения в проекте, чем всей организации процесса

14. Концептуальные основы тестирования: 50-60- е гг. В это время в основном решали вычислительные задачи, ориентировались на реализацию вычислительных алгоритмов. Это сказалось на подходах тестирования. Поэтому в 50–60-х годах прошлого века процесс тестирования был предельно формализован, отделён от процесса непосредственной разработки ПО и «математизирован» Фактически тестирование представляло собой скорее отладку программ (debugging). Существовала концепция т. н. «исчерпывающего тестирования (exhaustive testing)» — проверки всех возможных путей выполнения кода со всеми возможными входными данными. Серьезно ставился вопрос, как малым числом тестов обеспечить исчерпывающее тестирование (рассматривались подходы к тестированию на основе аппарата теории графов, на основе аппарата конечных автоматов). Но очень скоро было выяснено, что исчерпывающее тестирование невозможно, т.к. количество возможных путей и входных данных очень велико. Если в программе достаточно много переходов, т.е. операторов типа if, то для того, чтобы покрыть все переходы нужно астрономическое время. Примером может послужить программа из монографии Г. Майерса, где сама программа несложная, количество переходов визуально небольшое, но при этом, чтобы перебрать все возможные комбинации переходов нужно время, превышающее возраст вселенной. А также при подходе исчерпывающего тестирования сложно найти проблемы в документации. (т.к. в это время разработкой программы занимался отдельный программист и естественно он не вел сам для себя документации – нет документации – невозможно найти ошибку).

15. Концептуальные основы тестирования: 70-е гг. Философия методов «белого» и «черного» ящиков Возникли две фундаментальные идеи тестирования в 70-е гг: a. Доказательство работоспособности программ в некоторых заданных условиях (positive testing) b. Доказательство неработоспособности программ в некоторых заданных условиях (negative testing) Ограничения: необходимо заранее четко определить условия использования Можно предъявлять требования к низкому качеству, если только заранее определены условия, в которых должна работать эта программа. Никто не будет гарантировать, что программа будет давать положительный результат. Доказательство работоспособности и неработоспособности программ в некоторых заданных условиях – проверяет, выполняет ли программа требования функций с ограничениями на время решения выполнения задач, но только в заранее определенных условиях. Концепции тестирования 1 концепция: доказать, что программа всегда правильно работает в заданных условиях. 2 концепция: цель тестирования – доказательство что программа плохая, если доказать не удается, то она хорошая. Разработчик не может выступать тестировщиком своей собственной программы, только чужой программы, так как цель разработки и цель испытания противоположны. Цель разработчика – доказать, что программа хорошая, цель тестировщика – доказать, что программа плохая. Ограничением данного подхода является необходимость заранее четко определять условия использования. Белый ящик — цель: проверить каждый путь алгоритма Черный ящик — цель: проверить поведение программы при всех возможных сочетаниях входных данных Способы тестирования белого ящика: - метод покрытия операторов. Проверка выполнения каждого оператора хотя бы 1 раз - метод покрытия решений. Покрытие направления переходов - метод покрытия условий. Проверка выполнения условия хотя бы один раз - метод комбинаторного покрытия условий. Покрытие комбинации всех условий Способы тестирования черного ящика: - эквивалентное разбиение. Разбиение множества входных данных из классы эквивалентности и тестирование этих классов - анализ граничных значений. Тестирование на границах классов эквивалентности и за их пределами - анализ причинно-следственных связей. Идея метода заключается в отнесении всех следствий (входных условий) к причинам (выходные условия) - предложение об ошибке (подход, основанный из интуиции)

16. Концептуальные основы тестирования: 80-е гг. 1. Ключевое изменение места тестирования в разработке ПО: вместо финальной стадии реализации проекта тестирование стало применяться в течение всего жизненного цикла разработки, что позволило не только сократить «латентный период» ошибки, но и в известной степени предотвратить их появление. Тестирование, существовавшее до начала 1980-х, относилось только к скомпилированной, готовой системе (сейчас это обычно называется системное тестирование), но в дальнейшем тестировщики стали вовлекаться во все аспекты жизненного цикла разработки. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. 2. Бурное развитие и формализация методов тестирования 3. Первые попытки автоматизации тестирования. В середине 1980-х появились первые инструменты для автоматизированного тестирования. Предполагалось, что компьютер сможет выполнить больше тестов, чем человек, и сделает это более надёжно. Поначалу эти инструменты были крайне простыми и не имели возможности написания сценариев на скриптовых языках.

17. Концептуальные основы тестирования: 90е - гг. В 80-х годах пришли к заключению, что отсутствие дефектов гарантировать невозможно, допустимы не проявляющиеся дефекты. Целью стало найти как можно больше дефектов или доказать, что программа соответствует потребностям заказчика. От тестирования стали переходить к понятию управления, доказательству, подтверждению качества. - Во-первых, считали, что не нужно стараться исправить все дефекты, главное, чтобы они не появлялись. - Во-вторых, стали исходить из того, что разработка программного продукта это многомерный процесс (параллельная разработка, испытания, обеспечения). Произошел переход от тестирования к более всеобъемлющему процессу, именуемому “Управление качеством” который охватывает весь цикл разработки ПО и захватывает процесс планирования, проектирования и реализации ПО. PMBOK - Project Management Body Of Knowledge - одно из направлений, которое в 90-е годы получило широкое развитие. Здесь подчеркивалось единство основного, вспомогательного и обеспечивающего процессов. Т.е. конечное качество, которое поставляется заказчику, зависит не только от того КАК его делали, но и от того КАК его обеспечивали всеми необходимыми ресурсами (временем, деньгами, расходными материалами), а также от того КАК осуществлялся промежуточный контроль качества. Хоть и потребителя интересует только конечный результат, но только за счет грамотного-изощренного тестирования, качественный результат в больших системах в принципе обеспечить невозможно. Поэтому нужно качественно организовывать все 3 процесса. Также важной составляющей любого проекта в 90-е годы являлось планирование (сложная большая система)