Руководство по адаптации. С. Руководство по процессам и организациям
 Скачать 257.61 Kb.
|
|
Процессы повторного применения ПС – предназначены для поддержки возможности повторного использования программных элементов в различных проектах, выполняемых в организации. 7. ISO/IEC 12207: 2008. Процессы организационного обеспечения проекта. Процессы организационного обеспечения проекта управляют возможностью организации приобретать или поставлять продукты или услуги с помощью инициализации, поддержки и управления проектами. Эти процессы обеспечивают ресурсы и инфраструктуру, необходимую для поддержки проектов и гарантируют достижения организационных целей и имеющихся договоренностей. Процессы организационного обеспечения проекта 1. Процесс менеджмента модели жизненного цикла; 2. Процесс менеджмента инфраструктуры; 3. Процесс менеджмента портфеля проектов; 4. Процесс менеджмента людских ресурсов; 5. Процесс менеджмента качества. 8. ISO/IEC 12207: 2008. Процессы проекта. Процессы проекта связаны с планированием, оценкой и управлением проекта. Процессы проекта 1) Процессы менеджмента проекта 1. Процесс планирования проекта; 2. Процесс управления и оценки проекта. 2) Процессы поддержки проекта 1. Процесс менеджмента решений; 2. Процесс менеджмента рисков; 3. Процесс менеджмента конфигурации; 4. Процесс менеджмента информации; 5. Процесс измерений. 1) Процессы менеджмента проекта используются для планирования, выполнения, оценки и управления хода проекта. Эти процессы применяются для создания и отслеживания планов проекта, для оценки фактического выполнения хода проекта, для управления выполнением проекта до его завершения. 2) Процессы поддержки проекта поддерживают специализированные цели управления; они необходимы при управлении любым проектом от его организации в целом и до отдельных процессов жизненного цикла. 9. ISO/IEC 12207: 2008.Технические процессы. Предназначены для определения требований к системе, преобр. треб. к системе в эффект. продукт, эксплуатации продукта, ликвидации продута при его снятии к эксплуатации. Эти процессы обеспечивают возможность достижения высоких характеристик качества продукта, его доступность, своевременность и результативность затрат. 1. Процесс определения требований правообладателя (цель-определить требования к системе которые позволяют обеспечить предоставление услуг необходимых пользователям или другим правообладателям в заданной среде окружения) 2. Процесс анализа системных требований (цель-преобразование сформированных требований правообладателя в набор технических требований к системе) 3. Процесс проектирования архитектуры системы(распределение системных требований межу элементами системы) 4. Процесс реализации (цель-реализация заданного элемента системы) 5. Процесс сборки системы ( цель-объединение системных элементов для создания полной системы удовлетворяющей проекту системы и ожидаемых результатов потребителя) 6. Процесс квалификационного тестирования (цель-подтверждение того что реализация каждого системного элемента протестирована на соответствие и готова к поставке) 7. Процесс инсталляции ПС (цель- установка программного продукта соответствующего заданным требованиям в целевой среде окружения) 8. Процесс поддержки приемки ПС ( цель- содействие заказчика в достижение уверенности что продукт соответствует требованиям) 9. Процесс эксплуатации (цель-эксплуатация программного продукта в заданной среде окружения и обеспечение поддержки потребителя) 10. Процесс сопровождения (цель- обеспечение эффективной по затратам поддержки поставляемого программного продукта) 11. Процесс снятия ПС с эксплуатации (цель: завершение существования системного программного элемента. Инсталлирует и выводит из работы программный продукт в среде окружения, оставляя среду в приемлемом состоянии.) 10. ISO/IEC 12207: 2008. Процессы реализации программных средств. Используются для изготовления заданного элемента системы реализованного в виде ПС. Эти процессы преобразуют заданные свойства интерфейса и ограничения на реализованные действия по разработке. Результат этих действий – системный элемент удовлетворяет соответствующим требованиям. Процессы 2-7 являются процессами нижнего уровня. Работа стратегия реализации ПС (осуществляется выбор или разработка модели ЖЦ, в данную модель встраивают стадии разработки, выбираются работы и задачи, адаптация стандартов, методы, языки программирования и т.д.) 1. Процесс анализа требования к ПС (установка требований к программным элементам системы) 2. Процесс проектирования архитектуры (создание проекта реализации ПС который может быть верифицирован по отношению к требованиям) 3. Процесс детального проектирования (создание проекта реализации ПС который может быть верифицирован по отношению к требованиям и архитектуре ПС и достаточно детализирован чтобы позволить дальнейшее тестирование и кодирование) 4. Процесс конструирования ПС (создание исполнимых программных модулей соответствующих плану ПС) 5. Процесс сборки ПС (сборка программных модулей и компонентов полученных при сборке в соответствии с проектов ПС и демонстрация того что функциональные и нефункциональные требования к ПС удовлетворяются в эквивалентной или заданной среде окружения) 6. Процесс квалификационного тестирования (доказательство того что собранный программный продукт соответствует заданным требованиям) 11. Качество программных средств. Основные понятия и определения (атрибут, качество, метрика, модель качества, характеристика качества программных средств, подхарактеристика качества программных средств, ошибка, отказ, ранжирование, уровень ранжирования, шкала). На процесс разработки и деятельность по оценке качества ПС оказывают влияние следующие обобщённые показатели ПС: 1. Область применения и назначение ПС; 2. Тип решаемых задач; 3. Объём и сложность ПС; 4. Необходимый состав и требуемые значения характеристик качества ПС и величина допустимого ущерба из-за их недостаточного качества; 5. Степень связи решаемых задач с реальным масштабом времени или допустимой длительностью эксплуатации и перспектива создания множества версий ПС; 6. Предполагаемый тираж производства и применения ПС; 7. Степень необходимости документированности ПС. Атрибут – измеримое физическое или абстрактное свойство продукта. Могут быть внешними или внутренними. Качество – совокупность характеристик программного продукта, относящихся к его способности удовлетворять установленным и подразумеваемым потребностям. Метрика – метод и шкала измерения. Могут быть внутренними, внешними или метриками качества в использовании; прямыми или косвенными. Включают методы для категоризации качественных данных. Модель качества – набор характеристик и связей между ними обеспечивающих основу для определения требований к качеству и для оценки качества. Характеристика качества программных средств – набор свойств программного средства, с помощью которых описывается и оценивается его качество. Подхарактеристика качества программных средств – характеристика качества программного средства, входящая в состав другой характеристики. Ошибка – некорректный шаг процесс или определение данных в программе. Отказ– прекращение способности продукта выполнять требуемую функцию или его неспособность работать в пределах заданных ограничений. Ранжирование– действие по отнесение измеренного значения к соответствующему уровню ранжирования. Уровень ранжирования – точка на порядковой школе которая используется для категории шкалы измерения. Шкала – набор значений с определенными свойствами. 12. Типы шкал. Примеры шкал. Шкала – набор значений с определёнными свойствами. При оценке качества ПС обычно используется 4 типа шкал: номинальная, порядковая (упорядоченная),интервальная, шкала отношений. 1. Номинальная шкала соответствует набору категорий. Целью является классификация измеренных атрибутов, упорядочивание значений не предполагается. Пример: классификация дефектов ПС по их типам без упорядочивания. 2. Порядковый тип шкал: соответствует упорядоченному набору значений шкалы. Целью является назначение порядка или ранга измеренным атрибутам. Обычно содержит небольшое кол-во значений. Пример: упорядочивание программного продукта по серьёзности. 3. Интервальный тип шкалы: соответствует упорядоченной шкале с равноудаленными делениями; обычно содержит достаточно большое количество делений с количественными значениями. Пример: шкала с делениями (0,1,2,…,10) 4. Относительная шкала: соответствует упорядоченной шкале с равноудаленными делениями, оцененными в относительных единицах относительно некоторой абсолютной величины (обычно в диапазоне от 0 до 1) Два первых типа шкал применяются для оценки качественных атрибутов ПС, которые нельзя измерить количественно, и для ранжирования измеренных значение, третий и четвертый типы – для оценки количественных атрибутов. 13. СТБ ИСО/МЭК 9126-2003. Модель качества программных средств (характеристики и подхарактеристики). В соответствии со стандартом 28806 и 9126 модель качества ПС имеет трехуровневую структуру. На верхнем уровне 6 характеристик качеств, каждая характеристика делится на подхарктеристики (2 уровень), на 3 уровне метрики. 1. Функциональность (Functionality) – совокупность свойств ПС, определяемая наличием и конкретными особенностями набора функций, способных удовлетворять заданные или подразумеваемые потребности. 1. пригодность 2. правильность 3. способность к взаимодействию 4. согласованность 5. защищённость 2. Надежность (Reliability) – совокупность свойств, характеризующая способность ПС сохранять заданный уровень пригодности в заданных условиях в течение заданного интервала времени. 1. завершённость 2. устойчивость к ошибке 3. восстанавливаемость 3. Удобство использования (практичность, Usability) – совокупность свойств программного средства, характеризующая усилия, необходимые для его использования, и индивидуальную оценку результатов его использования заданным или подразумеваемым кругом пользователей. 1. понятность 2. обучаемость 3. простота использования 4. Эффективность (Efficiency) – совокупность свойств программного средства, характеризующая те аспекты его уровня пригодности, которые связаны с характером и временем использования ресурсов, необходимых при заданных условиях функционирования. 1. времяёмкость 2. ресурсоёмкость 5. Сопровождаемость (Maintainability) – совокупность свойств программного средства, характеризующая усилия, которые необходимы для его модификации. 1. анализируемось 2. изменяемость 3. стабильность 4. тестируемость 6. Мобильность (Portability) – совокупность свойств программного средства, характеризующая приспособленность для переноса из одной среды функционирования в другие. 1. адаптируемость 2. простота установки 3. соответствие 4.взаимозаменяемость 14. СТБ ИСО/МЭК 9126-2003. Метод оценки качества программных средств. Определяет метод оценки качества ПС, основанный на трёхуровневой иерархической модели качества. На верхнем уровне 6 характеристик качеств, каждая характеристика делится на подхарктеристики (2 уровень), на 3 уровне метрики.  Процесс оценки состоит из трех стадий: определение требований к качеству ПС, подготовка к оцениванию и процедура оценивания. Данный процесс может применяться после любой подходящей работы жизненного цикла для каждого компонента программного продукта. Определение требований к качеству ПС Цель: установка требований в терминах характеристик и подхарактеристик качества. Подготовка к оцениванию Цель: подготовка основы для оценивания. Этапы: 1. Выбор метрик качества. 2. Определение уровней ранжирования. 3. Определение критерия оценки. Процедура оценивания Этапы: 1. Измерение 2. Ранжирование 3. Оценка К недостаткам данного метода следует отнести отсутствие рекомендуемых вариантов метрик и представление метода лишь в общем виде (в виде модели), что затрудняет его контекстное использование. 15. Классификация методов определения показателей качества программных средств по ГОСТ 28195-99. Стандарт ГОСТ 28195–99 и его предыдущая версия ГОСТ 28195–89 классифицируют методы определения показателей качества ПС следующим образом: 1) по способам получения информации о показателе качества: 1. измерительный; 2. регистрационный; 3. органолептический; 4. расчетный; 2) по источникам получения информации о показателе качества: 1. экспертный; 2. социологический; 3. традиционный. Измерительный метод – это метод получения информации о свойствах и характеристиках ПС путем измерений с помощью инструментальных средств (например, так может определяться количество операторов в программе, количество выполненных операторов, количество операндов, время выполнения программы при определенных наборах исходных данных и т.д.). Регистрационный метод – это метод получения информации о свойствах и характеристиках ПС во время его испытания или функционирования, когда регистрируются некоторые события (например количество сбоев и отказов). Органолептический метод – это метод получения информации о свойствах и характеристиках ПС, основанный на восприятии органов чувств (зрения и слуха) человека. Так могут определяться, например, свойства ПС, связанные с удобством его использования. Расчетный метод – это метод получения информации о свойствах и характеристиках ПС, основанный на использовании эмпирических и теоретических зависимостей (на ранних этапах разработки), статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении ПС. Так может определяться, например, точность вычислений. Экспертный метод – это метод получения информации о свойствах и характеристиках ПС на основании мнений группы экспертов–специалистов, компетентных в решении данной задачи. Экспертный метод применяется в том случае, когда невозможно или слишком трудоемко выполнить оценку показателей качества с помощью других методов. Данным методом рекомендуется определять, например, показатели понимаемости и осваиваемости ПС. Социологический метод – это метод получения информации о свойствах и характеристиках ПС на основе обработки специальных анкет-опросников. Так могут определяться, например, отдельные показатели удобства использования. Традиционный метод – это метод получения информации о свойствах и характеристиках ПС на основе непосредственного наблюдения за их функционированием в процессе работы. Так могут определяться, например, некоторые из показателей функциональности и удобства использования. 16. ГОСТ 28195-99. Иерархическая модель качества программных средств (характеристики и подхарактеристики). ГОСТ 28195-99 регламентирует выполнение оценки качества программных средств и систем на основе иерархической модели качества. В соответствии с данной моделью совокупность свойств, отражающих качество программного средства, представляется в виде многоуровневой структуры. ГОСТ 28195-99 определяет четырёхуровневую иерархическую модель оценки качества ПС. На первом уровне модели находятся факторы качества (соответствуют характеристикам качества), на втором уровне – критерии качества (подхарактеристики качества), на 3-м метрики, на 4-м - оценочные элементы. Номенклатура факторов и критериев является обязательной, а номенклатура метрик и оценочных элементов - рекомендуемой. Для каждого из выбранных факторов качества составляется четырёхуровневая иерархическая модель, отражающая взаимосвязь факторов, критериев, метрик и оценочных элементов. 1. надёжность 1. устойчивость функционирования 2. работоспособность 2. сопровождаемость 1. структурность 2. простота конструкции 3. наглядность 4. повторяемость 5. полнота документации 3. удобство использования 1. лёгкость освоения 2. доступность программных документов 3. удобство эксплуатации и обслуживания 4. эффективность 1. уровень автоматизации 2. временная эффективность 3. ресурсоёмкость 5. универсальность 1. гибкость 2. мобильность 3. модифицируемость 6. функциональность 1. полнота реализации 2. согласованность 3. логическая корректность 4. проверенность 5. защищённость Характеристика качества программного средства – категория свойств программного средства, с помощью которого выражается его качество. Характеристики качества ПС могут быть определены с помощью подхарактеристик и, в конечном итоге, атрибутов качества ПС. |