- •24. Процеси стандарту іеее 1074.Процеси після розробки
- •Життєвий цикл пз
- •Процеси. Загальне поняття
- •20. Культура інженерії пз. Загальні концепції
- •14.Культура інженерії програмного забезпечення. Модель Константіноса.
- •15.Культура інженерії програмного забезпечення. Модель де Грака
- •16.Зв’язок культури з організацією,яка розроблює пз.
- •12,13. См модель, р-смм модель.
- •18.Домен пз: дві точки зору.
- •19.Еволюція індустрії пз
- •33.Проект
- •34.Задача,сумарна задача.
- •35.Логічні взаємозвязки.
- •36.Контрольні точки проекту, критичні операції.
- •37. Метод pert
- •38.Призначення опису вимог
- •39,40,41.Wbs osb і двонаправлена модель
12,13. См модель, р-смм модель.
Зрілість процесу програмного забезпечення визначається як ступінь, з яким процес явно визначений, управляється, вимірюється і контролюється.
В даний час для оцінки культури персоналу розроблений кодекс етики інженера програмного забезпечення, а для оцінки рівня зрілості культури організацій використовується широко відома модель, розроблена в SEI Capability Matuvity Model (CMM) і її подальшому розвитку СММІ
-
Предствник організації замовника перевіряє працюючу організацію
-
Замовник звертається до незалежно оцінювача. Недолік- кожен замовник звертається до оцінювача
-
Розробник отримує сертифікат якості в органзіції оцінювача з хорошою довірою як у замовника так і у розробника. Результат- довіра замовника
Міратек 3+ Софтвер лайн4
Capability Maturity Model - модель зрелости процессов создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение.
CMM определяет пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или понижаться. Здесь хочется отметить, что каждый следующий уровень включает в себя все ключевые характеристики предыдущих.
Начальный уровень (initial level) описан в стандарте в качестве основы для сравнения со следующими уровнями. На предприятии начального уровня организации не существует стабильных условий для созданий качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если такие менеджеры или программисты уходят с предприятия, то с их уходом резко падает качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию.
Повторяемый уровень (repeatable level). Для его внедрения на предприятии должны быть внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое программное обеспечение (причем обеспечивается следование этим стандартам) и существует специальная группа обеспечения качества. В случае необходимости организация может взаимодействовать с субподрядчиками. В критических условиях процесс имеет тенденцию скатываться на начальный уровень.
Определенный уровень (defined level). Он характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения задокументирован (включая и разработку ПО, и управление проектами). Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания подобного стандарта в организации должна быть создана специальная группа. Наконец, обязательным условием для достижения данного уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестает зависеть от качеств конкретных разработчиков, и процесс не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.
Управляемый уровень (managed level) в организации устанавливаются количественные показатели качества – как на программные продукты, так и на процесс в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях.
Оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения, например с помощью создания и повторного использования компонент.
Сертификационная оценка соответствия всех ключевых областей проводится по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям:
Заинтересованность руководства в данной области (планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т.д.).
Насколько широко данная область применяется в организации (например, оценке в 4 балла соответствует фрагментарное применение).
Успешность использования данной области на практике (например, оценке в 0 баллов соответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов выставляется при наличии систематического и измеримого положительного результата практически во всей организации).
Р-СММ