Модель жизненного цикла разработки ПО. SLCM

 

Модель жизненного цикла разработки ПО (Software life cycle model, SLCM) является единственным видом процесса, в котором представлен порядок его осуществления, объясняет, каким образом будут выполняться действия по разработке программного продукта, посредством описания "последовательности" этих действий

Модель SLCM — это схема (или основа) используемая разработчиком ПО для определения повторяющегося процесса при создании программного продукта. Она определяет точные инструкции, которые разработчик может использовать для создания только высококачественных программных систем.

Тут наверно про модели ЖЦ ввкратце надо?

 

SLCM. Обобщенная структура процесса. Целевая структура инжиниринга ПО.

Тут конкретно что необходимо?

Исходя из "целевой структуры инжиниринга ПО"  успешная разработка ПО зависит не только от получения удачного программного продукта, но также от получения удачных процессов разработки ПО. (Boehm. Software Engineering Economics)

Причина стандартизации процесса разработки ПО.

Причины стандартизации процесса

Улучшение и обеспечение качества:

o с помощью стандартизированной процедуры можно наилучшим образом гарантировать завершенность результатов, которые необходимо предоставить;

o определение промежуточных результатов обеспечивает возможность ускорить выполнение оценочных процедур;

o контекст однородных продуктов облегчает их восприятие, а также работу с процедурами оценки..

Возможность проверки затрат на выполнение полного жизненного цикла:

o упрощается процесс создания стандартов разработки для определенного проекта и его оценка;

o стандартизированные процедуры повышает степень "прозрачности" операций по определению затрат и позволяют более эффективно распознавать возможные риски, связанные с затратами;

o одинаковые стандарты уменьшают риск возникновения разногласий между клиентом и разработчиком, а также между главным разработчиком и субподрядчиком;

o в случае применения стандартизированной процедуры становятся "прозрачными" универсальные походы к методам решения, а следовательно, их можно использовать повторно;

o нежелательный ход процесса разработки возможно выявить на ранней стадии;

o уменьшаются затраты на подготовку персонала.

Улучшается обмен информацией между различными сторонами, участвующими в процессе разработки; происходит снижение зависимости клиента от подрядчика:

o использование определенных терминов уменьшает разногласия, возникающие между всеми задействованными в проекте сторонами;

o пользователь, покупатель и разработчик получают поддержку при формулировании своих требований, а также при описании своих ролей или полученных результатов;

o промежуточные/окончательные результаты стандартизируются таким образом, что другие задействованные в проекте стороны или персонал других компаний могут в случае необходимости подключиться к процессу разработки, не прилагая при этом больших дополнительных усилий.

Модель SEI СММ

Модель SEI СММ

Менеджмент качества программных проектов основывается на знаниях из трех источников:

o  программный инжиниринг (ACM, IEEE),

o  менеджмент проекта (PMI)

o  качество (ASQ).

Институт программного инжиниринга (SEI, Software Engineering Institute) в Университете Карнеги Мэллон à Модель зрелости функциональных возможностей (Capability Maturity Model, СММ),

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

Модель СММ

этапы разработки соответствуют пяти уровням развития функциональных возможностей, на основе этих этапов осуществляется непрерывное усовершенствование процесса разработки.

Каждый уровень зрелости разбивается на несколько ключевых областей процесса (какие действия еще необходимо предпринять) Каждая ключевая область процесса (Key process area, KPA) определяет набор взаимосвязанных действий (для оптимизации этого процесса)

Уровни СММ

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

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

Определенный. Во всех проектах используется испытанная, адаптированная версия стандартного процесса разработки ПО данной организации.

Управляемый. Собираются детальные показатели процесса разработки ПО и качественные характеристики продукта. Управление процессом разработки программных продуктов осуществляется на количественном уровне.

Уровень оптимизации. Непрерывное усовершенствование процесса разработки достигается с помощью количественной обратной связи, достигаемой при осуществлении самого процесса, а также на базе новаторских идей и технологий