Оценка качества процессов создания программного обеспечения.
Использование CMM при оценке качества процессов создания программного обеспечения.
Использование стандартов ISO 9000 и SPICE при оценке качества процессов создания программного обеспечения.
существует несколько стандартов, связанных с оценкой качества этих процессов, кот. обеспечивает организация-разработчик. К наиболее известным относят:
· международные стандарты серии ISO 9000 (ISO 9000 - ISO 9004):
· СММ – Capability Maturity Model – модель зрелости (совершенствования) процессов создания программного обеспечения, предложенная SEI (Software Engineering Institute – институт программирования при университете Карнеги-Меллон);
· рабочая версия международного стандарта ISO 1ЕС 15504 более известна под названием SPICE – (Software Process Improvement and Capability dEtermination – определение возможностей и улучшение процесса создания программного обеспечения).
Серия стандартов ISO 9000.В серии ISO 9000 сформулированы необходимые условия для достижения некоторого минимального уровня организации процесса, но не дается никаких рекомендаций по дальнейшему совершенствованию процессов.
СММ.СММ представляет собой совокупность критериев оценки зрелости организации-разработчика и рецептов улучшения существующих процессов.
СММ определяет пять уровней зрелости организаций-разработчиков, причем каждый следующий уровень включает в себя все ключевые характеристики предыдущих.
1. Начальный уровень (initial level) – описан в стандарте в качестве основы для сравнения со следующими уровнями. На предприятии такого уровня организации не существует стабильных условий для создания качественного ПО. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если эти менеджеры или программисты уходят с предприятия, то резко снижается качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию.
|
|
|
2. Повторяемый уровень (repeatable level) – на предприятии внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое программное обеспечение (причем обеспечивается следование этим стандартам) и специальная группа обеспечения качества. В случае необходимости организация может взаимодействовать с субподрядчиками. В критических условиях процесс имеет тенденцию скатываться на начальный уровень.
3. Определенный уровень (defined level) – характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения полностью документирован (включая и разработку ПО, и управление проектами). Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания подобного стандарта в организации должна быть создана специальная группа. Наконец, обязательным условием для достижения данного уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестает зависеть от качеств конкретных разработчиков, и процесс не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.
|
|
|
4. Управляемый уровень (managed level) – в организации устанавливаются количественные показатели качества как на программные продукты, так и на процесс в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях.
5. Оптимизирующий уровень (optimizing level) – характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения, например с помощью создания и повторного использования компонентов.
|
|
|
Сертификационная оценка соответствия всех ключевых областей проводится по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области осуществляется по следующим показателям:
· заинтересованность руководства в данной области, например, планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т.д.;
· насколько широко данная область применяется в организации, например, оценке в 4 балла соответствует фрагментарное применение;
· успешность использования данной области на практике, например, оценке в 0 баллов соответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов выставляется при наличии систематического и измеримого положительного результата практически во всей организации.
|
|
|
SPICE.
Стандарт SPICE унаследовал многие черты более ранних стандартов, в том числе и ISO 9001 и СММ. Больше всего SPICE напоминает СММ. основной задачей организации является постоянное улучшение процесса разработки ПО. в SPICE используется схема с различными уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни применяются не только к организации в целом, но и к отдельно взятым процессам.
В основе - оценка процессов.-выполняется путем сравнения процесса разработки ПО, существующего в данной организации, с описанной в стандарте моделью. Анализ результатов, полученных на этом этапе, помогает определить сильные и слабые стороны процесса, а также внутренние риски, присущие данному процессу. Это помогает оценить эффективность процессов, определить причины ухудшения качества и связанные с этим издержки во времени или стоимости.
Затем выполняется определение возможностей процесса, т.е. возможностей его улучшения. В результате в организации может появиться понимание необходимости улучшения того или иного процесса. К этому моменту цели совершенствования процесса уже четко сформулированы и остается только техническая реализация поставленных задач. После этого весь цикл работ начинается сначала.
Безусловно, совершенствование процессов жизненного цикла программного обеспечения абсолютно необходимо. Однако следует иметь в виду, что построение «более зрелого» процесса разработки не обязательно обеспечивает создание более качественного программного обеспечения. Это хотя и связанные, но совершенно различные процессы.
Использование формальных моделей и методов позволяет создавать понятные, непротиворечивые спецификации на разрабатываемое ПО. внедрение таких методов имеет смысл, хотя оно весьма дорого и трудоемко, а возможности их применения весьма ограничены. Основная же проблема – проблема сложности разрабатываемого программного обеспечения с совершенствованием процессов разработки пока не разрешена. Создание ПО по-прежнему предъявляет повышенные требования к квалификации тех, кто этим занимается: проектировщикам программного обеспечения и непосредственно программистам.
Дата добавления: 2018-02-15; просмотров: 1018; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!