Оценка качества процессов создания программного обеспечения Составитель: Шаповалова С.В.

Презентация:



Advertisements
Похожие презентации
Управление качеством Качество ПО – его соответствие потребностям Заказчика Самый верный путь повышения качества – улучшение процессов создания и сопровождения.
Advertisements

Современные модели качества программного обеспечения.
Технология внедрения CASE- средств Технология внедрения CASE-средств базируется в основном на стандартах IEEE (IEEE - Institute of Electrical and Electronics.
Лекция 1 Учебные вопросы : Вопрос 1. История возникновения и понятие CASE- технологии. Вопрос 2. Особенности внедрения CASE- технологии. Вопрос 3. Основные.
Разработка программного обеспечения (Software Engineering) Часть 2. Создание ПО.
ЛЕКЦИЯ 1 Автоматизированное проектирование информационных систем с использованием CASE-технологии Учебные вопросы: Вопрос 1. История возникновения и понятие.
Этапы планирования потребности в персонале
Непрерывный рост требований к качеству ПС стимулирует создание и активное применение международных стандартов и регламентированных технологий, автоматизирующих.
УПРАВЛЕНИЕ ПРОЕКТАМИ - ПОНЯТИЯ И ПРОЦЕССЫ Либерзон В.И.
УПРАВЛЕНИЕ ПРОЕКТАМИ - ПОНЯТИЯ И ПРОЦЕССЫ Либерзон В.И.
Технологии конструирования программного обеспечения.
МОДЕЛЬ ОЦЕНКИ КАЧЕСТВА ОБРАЗОВАНИЯ Критерий 3: Менеджмент персонала.
Тема. Стандарты ISO и СМК (системы менеджмента качества)
Технологии конструирования программного обеспечения.
Внутренний аудит в ТПУ1 ПРАКТИЧЕСКИЙ ОПЫТ ВНУТРЕННИХ АУДИТОВ ТПУ.
Разработка программного обеспечения (Software Engineering) Ian Sommervillle Часть 8. Управление качеством.
Система управления проектами и задачами JIRA Выполнили: Студентки 5 курса БГУ отделения «Финансы и кредит» Грамотнева Анна Гуреева Ирина.
8. Федеральные критерии безопасности информационных технологий.
Дисциплина «Технология разработки программного обеспечения» Тема 1 « Основы разработки Тема 1 « Основы разработки программного продукта » программного.
CMM Capability Maturity Model CMM Capability Maturity Model Круглый стол, Мариотт Гранд Отель Москва, 16 апреля 2002.
Транксрипт:

Оценка качества процессов создания программного обеспечения Составитель: Шаповалова С.В.

переход от штучного ремесленного производства программных продуктов к их промышленному созданию рост требований к качеству разрабатываемого программного обеспечения совершенствование процессов разработки ПО Требования к средствам разработки современного программного обеспечения

Стандарты, связанные с оценкой качества процессов создания ПО международные стандарты серии ISO 9000 (ISO ISO 9004); СММ - Capability Maturity Model - модель зрелости (совершенствования) процессов создания ПО, предложенная SEI (Software Engineering Institute - институт программирования при университете Карнеги- Меллон); рабочая версия международного стандарта ISO/IEC 15504: Information Technology - Software Process Assessment; эта версия более известна под названием SPICE - (Software Process Improvement and Capability dEtermination - определение возможностей и улучшение процесса создания программного обеспечения).

В серии ISO 9000 сформулированы необходимые условия для достижения некоторого минимального уровня организации процесса, но не дается никаких рекомендаций по дальнейшему совершенствованию процессов СММ представляет собой совокупность критериев оценки зрелости организации- разработчика и рецептов улучшения существующих процессов

СММ разрабатывалась и развивалась как методика, позволяющая крупным правительственным организациям США выбирать наилучших поставщиков ПО. Предполагалось создать исчерпывающее описание способов оценки процессов разработки ПО и методики их дальнейшего усовершенствования. В итоге, стандарт оказался пригодным и для обычных компаний-разработчиков, желающих качественно улучшить существующие процессы разработки, привести их к определенным стандартам.

СММ определяет пять уровней зрелости организаций-разработчиков Каждый следующий уровень включает в себя все ключевые характеристики предыдущих

1. Начальный уровень (initial level) - основа для сравнения со следующими уровнями На предприятии такого уровня организации не существует стабильных условий для создания качественного ПО. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Если эти менеджеры или программисты уходят с предприятия, то резко снижается качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию.

2. Повторяемый уровень (repeatable level) - на предприятии внедрены технологии управления проектами Планирование и управление проектами основывается на накопленном опыте. Существуют стандарты на разрабатываемое ПО (причем обеспечивается следование этим стандартам) и специальная группа обеспечения качества. В случае необходимости организация может взаимодействовать с субподрядчиками. В критических условиях процесс имеет тенденцию скатываться на начальный уровень.

3. Определенный уровень (defined level) - стандартный процесс создания и сопровождения ПО полностью документирован (включая и разработку ПО, и управление проектами) В процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания стандарта в организации должна быть создана специальная группа. Обязательным условием является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестает зависеть от качеств конкретных разработчиков, и процесс не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.

4. Управляемый уровень (managed level) - в организации устанавливаются количественные показатели качества как на программные продукты, так и на процесс в целом Более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. Осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях

5. Оптимизирующий уровень (optimizing level) - мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий Основной задачей всей организации является постоянное улучшение существующих процессов. Улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Должны вестись работы по уменьшению стоимости разработки ПО, например с помощью создания и повторного использования компонентов. Сертификационная оценка соответствия всех ключевых областей проводится по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов.

Оценка ключевой области осуществляется по следующим показателям: заинтересованность руководства в данной области, например, планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т. д.; насколько широко данная область применяется в организации, например, оценке в 4 балла соответствует фрагментарное применение; успешность использования данной области на практике, например, оценке в 0 баллов соответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов выставляется при наличии систематического и измеримого положительного результата практически во всей организации.

Можно сертифицировать только один процесс или подразделение организации, например, подразделение разработки ПО компании IBM сертифицировано на пятый уровень. В мире существует совсем немного компаний, которые могут похвастаться наличием у них пятого уровня СММ хотя бы в одном из подразделений - таких всего около 50-ти. Насчитывается несколько тысяч компаний, сертифицированных по третьему или четвертому уровням, т. е. существует колоссальный разрыв между оптимизированным уровнем зрелости и предыдущими уровнями. Еще больший разрыв наблюдается между количеством организаций начального уровня и числом более продвинутых компаний - по некоторым оценкам, свыше 70 % всех компаний-разработчиков находится на первом уровне СММ.

SPICE. Стандарт SPICE унаследовал многие черты более ранних стандартов, в том числе ISO 9001 и СММ. Больше всего SPICE напоминает СММ. Как и в СММ, основной задачей организации является постоянное улучшение процесса разработки ПО. В SPICE используется схема с различными уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни применяются не только к организации в целом, но и к отдельно взятым процессам.

В основе стандарта лежит оценка процессов Эта оценка выполняется путем сравнения процесса разработки ПО, существующего в данной организации, с описанной в стандарте моделью. Анализ результатов, полученных на этом этапе, помогает определить сильные и слабые стороны процесса, а также внутренние риски, присущие данному процессу. Это помогает оценить эффективность процессов, определить причины ухудшения качества и связанные с этим издержки во времени или стоимости.

Затем выполняется определение возможностей процесса, т. е. возможностей его улучшения. В результате в организации может появиться понимание необходимости улучшения того или иного процесса. К этому моменту цели совершенствования процесса уже четко сформулированы и остается только техническая реализация поставленных задач. После этого весь цикл работ начинается сначала.

Совершенствование процессов жизненного цикла программного обеспечения абсолютно необходимо. Однако, следует иметь в виду, что построение «более зрелого» процесса разработки не обязательно обеспечивает создание более качественного ПО. Это хотя и связанные, но совершенно различные процессы.

Использование формальных моделей и методов позволяет создавать понятные, непротиворечивые спецификации на разрабатываемое ПО. Внедрение таких методов имеет смысл, хотя оно весьма дорого и трудоемко, а возможности их применения весьма ограничены. Основная проблема - проблема сложности разрабатываемого ПО, с совершенствованием процессов разработки пока не разрешена. Создание ПО по-прежнему предъявляет повышенные требования к квалификации тех, кто этим занимается: проектировщикам ПО и непосредственно программистам.

Литература Калянов Г.Н. CASE-технологии. Консалтинг при автоматизации бизнес-процессов. 2-е изд. перераб. и доп. – М.: Горячая линия – Телеком, – 320 с.