metoda_2013

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

ГОСТы как и CMM, не являются методологиями. Они, как правило, не описывают сами процессы разработки ПО. Но они формулируют определенные требования к процессам, которым в той или иной степени соответствуют различные методологии.

Модели зрелости процесса разработки (CMM, CMMI) – модель зрелости процессов создания ПО, которая предназначена для оценки уровня зрелости процесса разработки в конкретной компании.

В соответствие с этой моделью есть пять уровней зрелости процесса разработки. Первый уровень соответствует разработке «как получится», когда на каждый проект разработчики идут как на подвиг. Второй уровень соответствует более-менее налаженным процессам, когда можно с достаточной уверенностью надеяться на положительный исход проекта. Третий уровень соответствует наличию разработанных и хорошо описанных процессов, используемых при разработке. Четвертый

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

После появления CMM стали разрабатываться специализированные модели зрелости для разработки информационных систем, для процесса выбора поставщиков и некоторые другие. На их основе была разработана интегрированная модель CMMI (Capability Maturity Model Integration). Кроме того, в CMMI была предпринята попытка преодолеть проявившиеся к тому времени недостатки CMM. А именно, преувеличение роли формальных описаний процессов, когда наличие определенной документации оценивалось значительно выше, чем просто хорошо налаженный, но не описанный процесс. Тем не менее, CMMI также ориентирован на использование весьма формализованного процесса.

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

RUP – итеративная методология. (см вопрос 16 в ТРПО) Хотя выполнение всех фаз или какого-то минимального числа итераций нигде в RUP не оговаривается, весь подход ориентирован на то, что их достаточно много. Только при этом можно настроить процесс для последующих итераций, основываясь на результатах начальных. Ограниченное количество итераций не позволяет использовать в полной мере

70

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

Что касается формальности методологии, то здесь RUP представляет пользователю весьма широкий диапазон возможностей. Если выполнять все работы и задачи, создавать все артефакты и достаточно формально (то есть с официальным назначением рецензента, с предоставлением рецензентом достаточно полной рецензии в виде электронного или бумажного документа и т.д.) проводить все рецензирования, RUP представляет собой крайне формальную, тяжеловесную методологию. С другой стороны, RUP позволяет разрабатывать только те артефакты и выполнять только те работы и задачи, которые необходимы в конкретном проекте. А выбранные артефакты могут выполняться и рецензироваться с произвольной степенью формальности. Можно требовать детальной проработки и тщательного оформления каждого документа. Можно требовать предоставления столь же тщательно выполненной и оформленной рецензии. А, кроме того, всегда остается еще одна возможность — сформировать документ «в голове». Попросту говоря, продумать соответствующий вопрос, принять соответствующее решение. И, если это решение касается только Вас, то ограничиться, например, комментарием в коде программы.

71

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Схематично можно представить так ^ ^ ^

5. Модели жизненного цикла (ЖЦ).

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

В рамках методологии Института управления проектами ЖЦ проекта включает: Инициация; Планирование; Выполнение; Контроль и мониторинг; Завершение.

Каскадная (водопадная) модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к ПС. В каскадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы -> накопление возможных ошибок на ранних этапах. Кроме того, эта модель не способна гарантировать необходимую скорость отклика и внесение соответствующих изменений в ответ на быстро меняющиеся потребности пользователей, для которых программная система является одним из инструментов исполнения бизнес-функций.

72

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Существует каскадная модель жизненного цикла с возможными возвратами на предыдущий уровень (при изменении требований происходит возврат в нужную фазу разработки).

Итеративная и инкрементальная модель – эволюционный подход

Итеративная модель - выполнение работ паралельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы; предполагает разбиение ЖЦ проекта на последовательность итераций,

каждая из которых напоминает “мини-проект”, и проходит цикл Планирование - Реализация - Проверка – Оценка в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии ПС, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально.

73

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Преимущества итеративного подхода:

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

*организация эффективной обратной связи проектной команды с потребителем (заказчиками) и создание продукта, реально отвечающего его потребностям;

*акцент усилий на наиболее важные и критичные направления проекта;

*непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

*раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

*более равномерная загрузка участников проекта; *эффективное использование накопленного опыта; *реальная оценка текущего состояния проекта и, как

следствие, большая уверенность в его успешном завершении. Эволюционная модель подразумевает не только сборку

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

•можно очень рано начать тестирование пользователями

•можно принять стратегию разработки в соответствии с бюджетом, полностью защищающую от перерасхода времени или средств.

74

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Таким образом, значимость эволюционного подхода на основе организации итераций особо проявляется в снижении неопределенности с завершением каждой итерации. Идея эволюционного подхода, предполагает, что итеративному разбиению может быть подвержен не только ЖЦ в целом, включающий перекрывающиеся фазы – формирование требований, проектирование, конструирование и т.п., но и каждая фаза может, в свою очередь, разбиваться на уточняющие итерации, связанные, например, с детализацией архитектуры модулей системы.

Спиральная модель

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

Преимущества:

Модель уделяет специальное внимание раннему анализу возможностей повторного использования.

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

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

Модель не проводит различий между разработкой нового продукта и расширением (или сопровождением) существующего.

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

75

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

6 ключевых характеристик, обеспечивающих успешное применение СМ:

1.Паралельное, а не последовательное определение артефактов проекта

2.Согласие в том, что на каждом цикле уделяется внимание:

•целям и ограничениям, важным для заказчика

•альтернативам организации процесса и технологических

решений, закладываемых в продукт

•идентификации и разрешению рисков

•оценки со стороны заинтересованных лиц (в первую очередь заказчика)

•достижению согласия в том, что можно и необходимо двигаться дальше

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

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

5.Управление ЖЦ в контексте обязательств всех заинтересованных лиц на основе трех контрольных точек: Life Cycle Objectives (LCO) - цели и содержание жизненного цикла, Life Cycle Architecture (LCA), Initial Operational Capability (IOC)

6.Уделение специального внимания проектным работам и артефактам создаваемой системы (включая непосредственно

76

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

разрабатываемое ПО, ее окружение, эксплуатационные характеристики) и ЖЦ разработки и использ-я.

Набор контрольных точек в сегодняшней спиральной модели: •Concept of Operations (COO) – концепция использования

системы;

•Life Cycle Objectives (LCO) – цели и содержание ЖЦ;

•Life Cycle Architecture (LCA) – архитектура ЖЦ; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

•Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации;

•Final Operational Capability (FOC) – готовый продукт,

развернутый (установленный и настроенный) для реальной эксплуатации.

6. Качество программной системы. Модель характеристик качества. Характеристики качества ПО

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

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

Сейчас существует несколько определений качества, которые в целом совместимы друг с другом. Приведем наиболее распространенные:

Определение ISO: Качество - это полнота свойств и характеристик продукта, процесса или услуги, которые

77

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям.

Определение IEEE: Качество программного обеспечения - это степень, в которой оно обладает требуемой комбинацией свойств.

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

1.Качество накапливается в продукте, вклад на ранних стадиях имеет более сильное влияние.

2.Чем выше качество процесса разработки, тем выше качество разработанного в этом процессе ПО.

QA – инспектирование (“белый ящик”; проводится коллегами на уровне модулей ПО) и тестирование.

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

Составляющие качества информационной системы:

Качество инфраструктуры: качество аппаратного и поддерживающего программного обеспечения (например, качество операционных систем, компьютерных сетей и т.п.).

Качество программного обеспечения: качество ПО информационной системы.

Качество данных: качество данных, использующихся инфор-ой системой на входе.

Качество информации: качество информации, продуцируемое инф-ой системой.

Качество административного управления – качество менеджмента, включая качество бюджетирования, планирования и календарного контроля.

Качество сервиса – качество обучения, системной поддержки и т.п.

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

Модель характеристик качества: Стандарты ISO определяют модель характеристик качества ПС, которая состоит из нескольких видов атрибутов качества:

внутренние атрибуты качества (требования к качеству кода и внутренней архитектуре);

внешние атрибуты качества (требования к функциональным возможностям и т.д.);

78

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

атрибуты «качества в использовании»(данные атрибуты качества относятся не только к ПС, а ко всей информационной системе)

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

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

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

1.1.пригодностью для применения;

1.2.корректностью (правильностью, точностью);

1.3.способностью к взаимодействию;

1.4.защищенностью;

2.надежность - набор атрибутов, относящихся к способности ПО

сохранять свой уровень качества функционирования в

79