аттестация. перечень вопросов для промежуточной аттестации. Перечень вопросов для промежуточной аттестации
 Скачать 285.33 Kb.
|
|
ПЕРЕЧЕНЬ ВОПРОСОВ ДЛЯ ПРОМЕЖУТОЧНОЙ АТТЕСТАЦИИ Жизненный цикл программного обеспечения Жизненный цикл ПО определяется как период времени, который начинается с момента принятия решения о необходимости ПО и заканчивается в момент его полного изъятия из эксплуатации. Стандарт определяет процессы, виды деятельности и задачи, которые используются при приобретении программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов. Каждый процесс разделен на набор действий, каждое действие – на набор задач. Модели жизненного цикла программного обеспечения Под моделью жизненного цикла ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям. Каскадная модель Каждая стадия каскадной модели заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Каскадная модель может использоваться при создании ПО, для которого в самом начал разработки можно достаточно точно и полно сформулировать все требования. Каскадная модель Уинстона Ройса учитывает взаимозависимости этапов и необходимости возврата на предыдущие ступени, что может быть вызвано, например, неполнотой требований или ошибками в формировании задания. Итеративный подход к разработке Итеративная модель - предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Итеративная модель подразумевает возможность не только сборки работающей версии системы - прототипа, но и её развертывания в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. Инкрементная модель - программную систему следует разрабатывать по принципу приращений, так, чтобы разработчик мог использовать данные, полученные при разработке более ранних версий ПО. Для организации инкрементной разработки обычно выбирается характерный временной интервал. V-образная модель Принцип V-образной модели -детализация проекта возрастает при движении слева направо, одновременно с течением времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы. V-модель – вариация каскадной модели, в которой задачи разработки идут сверху вниз по левой стороне буквы V, а задачи тестирования – вверх по правой стороне буквы V. Особенностью данной модели является разбиение стадий на три логических этапа: проектирование (детализация требований), реализация, тестирование. Спиральная модель жизненного цикла При использовании спиральной модели прикладное ПО создается в несколько итераций (витков спирали) методом прототипирования. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Основная проблема спирального цикла – определение момента перехода на следующую стадию. Для её решения необходимо ввести временные ограничения на каждую из стадий ЖЦ. Стандарты жизненного цикла Профиль стандартов - основной инструмент функциональной стандартизации. - Группа стандартов ISO - Группа стандартов IEEE - Группа стандартов CMM Группа стандартов ISO ISO/IEC 12207 Standard for Information Technology — Software Life Cycle Processes (процессы жизненного цикла ПО, есть его российский аналог ГОСТ Р-1999). Определяет общую структуру жизненного цикла ПО в виде 3-х ступенчатой модели, состоящей из процессов, видов деятельности и задач ISO/IEC 15288 StandardforSystemsEngineering — SystemLifeCycleProcesses (процессы жизненного цикла систем). Отличается от предыдущего нацеленностью на рассмотрение программно-аппаратных систем в целом. ISO/IEC 15504 (SPICE) Standard for Information Technology — Software Process Assessment (оценкапроцессовразработкииподдержкиПО). Определяет правила оценки процессов жизненного цикла ПО и их возможностей, опирается на модель CMMI (см. ниже) и больше ориентирован на оценку процессов и возможностей их улучшения. Группа стандартов IEEE IEEE 1074-1997 — IEEE Standard for Developing Software Life Cycle Processes (стандартнасозданиепроцессовжизненногоциклаПО). Нацелен на описание того, как создать специализированный процесс разработки в рамках конкретного проекта. Описывает ограничения, которым должен удовлетворять любой такой процесс, и, в частности, общую структуру процесса разработки. IEEE/EIA 12207-1997 — IEEE/EIA Standard: Industry Implementation of International Standard ISO/IEC 12207:1995 Software Life Cycle Processes (промышленное использование стандарта ISO/IEC 12207 на процессы жизненного цикла ПО). Аналог ISO/IEC 12207, сменил ранее использовавшиеся стандарты J-Std-016-1995 EIA/IEEE Interim Standard for Information Technology — Software Life Cycle Processes — Software Development Acquirer-Supplier Agreement (промежуточный стандарт на процессы жизненного цикла ПО и соглашения между поставщиком и заказчикам ПО) и стандарт министерства обороны США MIL-STD-498. Группа стандартов CMM Модель зрелости возможностей CMM (Capability Maturity Model) предлагает унифицированный подход к оценке возможностей организации выполнять задачи различного уровня. Для этого определяются 3 уровня элементов: уровни зрелости организации (maturity levels), ключевые области процесса (key process areas) и ключевые практики (key practices). Интегрированная модель зрелости возможностей CMMI (Capability Maturity Model Integration) Эта модель представляет собой результат интеграции моделей CMM для продуктов и процессов, а также для разработки ПО и разработки программно-аппаратных систем. Модульное программирование Модульное программирование основано на понятии модуля – программы или функционально завершенного фрагмента программы. Модули содержат описание исходных данных, операции обработки данных и структуры взаимосвязи с другими модулями. Структурное программирование В основу структурного программирования положено требование, чтобы каждый модуль алгоритма (программы) проектировался с единственным входом и единственным выходом. Программа представляется в виде множества вложенных модулей, каждый из которых имеет один вход и один выход. Метод объектно-ориентированное программирование Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого типа (класса), а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путём передачи сообщений. Инструментальное программное обеспечение. Основные понятия и определения В последнее время все большее внимание уделяется современным технологиям и инструментальным средствам, обеспечивающим автоматизацию процессов ЖЦ ПС (CASE-средствам). Использование таких инструментальных средств позволяет существенно сократить длительность и стоимость разработки систем и ПС при одновременном повышении качества процесса разработки и, как следствие, качества разработанных ПС. Базовые принципы построения CASE-средств. Основные функциональные возможности CASE-средств Большинство CASE-средств основано на парадигме метод – нотация –средство. Парадигма – это система изменяющихся форм некоторого понятия. В данном случае метод реализуется с помощью нотаций. Метод и нотации поддерживаются инструментальными средствами. Метод – это систематическая процедура или техника генерации описаний компонент ПС. Нотация – это система обозначений, предназначенная для описания структуры системы, элементов данных, этапов обработки. Назначение и виды инструментального по Все CASE-средства подразделяются на типы, категории и уровни. Классификация по типам отражает функциональное назначение CASE-средства в ЖЦ ПС и систем. Классификация по категориям отражает уровень интегрированности CASE-средств по выполняемым функциям. Классификация по уровням связана с областью действия CASE-средств в ЖЦ ПС, систем и организаций. Риск, событие, характеристики риска Риск — следствие влияния неопределённости на достижение поставленных целей; это следствие вероятности возникновения события, которое окажет отрицательное воздействие на достижение поставленных целей. Событие — возникновение или изменение специфического набора условий. Риск характеризуется двумя величинами: вероятность, которая характеризует наступление рискового события; цена потери и величина возможных негативных последствий. Подход к управлению рисками Оцениваемые характеристики риска позволяют говорить об управлении рисками. Управление рисками предприятия (Enterprise Risk Management, ERM) — это концепция, объединяющая методики и процессы, применяемые организациями для управления рисками и возможностями достижения поставленных целей. Как правило, первоочередные меры реагирования на риск — контроль за ходом деятельности и процессами организации. Стандарты управления рисками Существуют стандарты, непосредственно посвящённые управлению рисками. Прежде всего, это семейство стандартов 31000, которое включает: ГОСТ Р ИСО 31000:2010 «Менеджмент риска. Принципы и руководство» (идентичный международному стандарту ISO 31000:2009 Risk Management. Principles and Guidelines) описывает принципы, инфраструктуру (систему управления рисками) и процесс менеджмента риска; ГОСТ Р ИСО/МЭК 31010-2011 «Менеджмент риска. Методы оценки риска» (идентичный международному стандарту ISO/IEC 31010:2009 Risk Management — Risk Assessment) описывает вопросы и процесс оценки риска, а также выбор методов оценки риска. Стандарты семейства 31000 очень гибкие и универсальные, на их основе можно построить любую корпоративную систему управления рисками. Кроме того, существует еще короткий ГОСТ Р 51897-2011 «Менеджмент риска. Термины и определения». Система управления рисками Современный подход к управлению рисками рассматривает эту деятельность как непрерывный процесс, в котором риски регулярно выявляют и анализируют, измеряют, ищут способы работы с ними и оценивают эффективность уже принятых мер. Концепция управления рисками — формализация решений высшего руководства предприятия об общих намерениях, основных принципах и направлениях деятельности в области управления рисками. Концепция управления рисками должна в полной мере отражать цели и приоритеты организации в области риск-менеджмента и фиксировать обязательства по постоянному управлению рисками и улучшению этой деятельности. Ограничения управления рисками Управлять рисками можно только в том случае, если существует определённый уровень прогнозируемости событий и внутренних условий деятельности организации. В противном случае невозможно обоснованно оценить вероятность наступления рискового события и его последствия. Система управления ИТ-рисками ИТ-риск — это вероятность возникновения события, связанного с применением информационных технологий, которое окажет отрицательное воздействие на достижение поставленных целей. Для постановки системы управления ИТ-рисками целесообразно воспользоваться стандартом COBIT: инструкциями COBIT по аудиту ИТ-процесса «Оценка рисков», рекомендациями Risk Analysis Framework (COBIT) 3. К сожалению, вопрос выбора методологии управления ИТ-рисками в каждом конкретном случае — дело сложное, его нельзя свести к кратким советам. Виды тестирования  Автоматизация тестирования Автоматизированное тестирование программного обеспечения (Software Automation Testing) – это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования. Автоматизацию необходимо использовать совместно с ручным тестированием. В противном случае уровень качества программного продукта может быть снижен за счет наличия дефектов, пропущенных тестовыми скриптами. Управление тестированием Реестры заинтересованных лиц позволяют понять, кого нужно держать в курсе о результатах процесса тестирования, с кем нужно сотрудничать, чьи интересы необходимо учитывать при планировании тестирования, чьи цели наиболее приоритетны, кого необходимо информировать о возникающих проблемах и т. д. В общем случае планирование тестирования включает следующие основные действия: создание тест-плана; продумывание стратегии тестирования; оценка трудозатрат и рисков; прогнозирование сроков и составление графика проведения тестирования; определение используемых инструментов. При планировании тестирования важно определять критерий входа и критерий выхода. Критерий входа показывает, когда нужно начинать тестирование. |