Лаврищева Е.М., Грищенко В.Н. Сборочное программирование. Основы индустрии программных продуктов

Подождите немного. Документ загружается.

331

Метод критического пути СРМ (Critical Path Method ) разработан Уолкером –

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

путь в сети. Работы, которые лежат на этом пути, также называются критическими.

Именно продолжительность критического пути определяет наименьшую общую

продолжительность работ в проекте в целом.

Метод основан на графическом представлении задач (работ) и видов действий

на проекте и заданием ориентировочного времени их выполнения. Это

представление задается в виде графа (рис 10.11), в вершинах которого

располагаются работы и время выполнения каждой работы под вершинами либо на

дугах графа.

1 нед.

3 нед.

2 нед.

3 нед.

4 нед. 2 нед.

Начало

работ

Конец

работ

Рис.10.11. Граф со сроками выполнения работ

Граф строиться тогда, когда работы и время их выполнения являются

заданными (определенными).

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

на графе (от начальной работы до последней). При выполнении проекта

выбираются и выполняются работы, которые не влияют на время выполнения

других (независимых) работ проекта или на их продолжительность. Работы на

критическом пути могут сокращаться за счет изменения времени выполнения.

Время выполнения всего проекта может быть сокращено за счет уменьшения

времени выполнения задач, которые лежат на критическом пути. Таким образом,

любая задержка выполнения задач критического пути приводит к увеличению

времени выполнения проекта. Эта концепция концентрирует внимание менеджера

на критических работах.

Основным преимуществом метода критического пути является возможность

управления сроками выполнения задач, которые не лежат на критическом пути.

Этот метод разрешает рассчитать возможные календарные графики выполнения

комплекса работ на основе описанной логической структуры сети и оценок

времени выполнения каждой работы.

Представление работ в таком виде называется сетевой диаграммой и служит

для графического отображение работ проекта, их взаимосвязей, последова-

тельностей и времени выполнения. В графе вершины отображают работы, а

332

линии взаимные связи между работами. Такой граф является наиболее

распространенным представлением сети на сегодняшний день.

Метод анализа и оценки PERT основан на сетевых диаграммах в виде вершин–

событий, а работы – на линии между двумя событиями, отображающими начало и

конец данной работы (рис.10.12).

Дуге, выходящей из начальной вершины и входящей в заключительную

вершину, соответствует временная метка 0. С помощью этих меток задается время

выполнения процесса. В графе могут присутствовать также и циклические пути.

1 . 1

1 . 3

2 . 1

3 . 1

3 . 2

2 .4

2 .3

2 .2

1 .2

1 3

1 2

1 1

1 0

0 0

1 5

Рис.10.12. Граф номеров работ и сроков (на дугах)

На основе графа проводится анализ критических путей в выполнении работ,

т.е. определяется продолжительность каждого процесса. План проекта создается в

сроках этапов: планирование, проектирование, кодирование, тестирование и

сопровождение. Для первых двух методов планирование затрагивает: определение

спецификаций, бюджета и расписания, а также развития плана проекта в целом.

Представление более сложных связей между работами для задания узлами графа в

виде вершина–событие является более сложным и потому этот метод реже

используется на практике.

Между этими двумя методами сетевого представления графа работ имеются

незначительные расхождения. Данный метод, например, в отличие от CMP,

учитывает возникающие неопределенности во времени выполнения каждой

операции.

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

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

наблюдать виды деятельности, которые могут выполняться последовательно или

параллельно, или находиться на критическом пути (например, в системе Project

Management).

Таким образом, рассмотрены базовые стандартные положения PMBOK, серия

333

стандартов ISO 9001–9003, регламентирующие управление качеством проекта,

теория управления и планирования, а также методы управления проектами – базис

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

управления обеспечит стратегическое планирование работ по производству ПС

проектов и эффективную подготовку высококвалифицированных менеджеров

проектов, а также других специалистов в области организационного управления

по изготовлению и выпуску ПП на производственной основе.

10.3.4. ЭКОНОМИКА ИЗМЕРЕНИЯ И ОЦЕНКИ ПРОГРАММНЫХ

ПРОДУКТОВ

Экономика ПИ – это самостоятельная дисциплина, определяющая экономические

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

объема работ и требуемых ресурсов для выполнения работ, составления планов и

распределение специалистов по этим работам, экспертизы результатов выполнения

работ, а также определение стоимости и производимых затрат на разработку и

сопровождение изготавливаемого продукта. Сюда относятся методы анализа ПрО

для построения ее модели, проектирования архитектуры будущей системы и

программирования отдельных компонентов.

Иными словами, в ее основе лежат экономические расчеты разных сторон

деятельности исполнителей проекта с учетом знаний всех экономических

факторов и текущих затрат в проекте. Эта дисциплина имеет свою теорию и

практику решения задач по проведению экспертизы проекта, оценке стоимости,

сроков и экономических показателей, устанавливаемых в требованиях к ПП при

заключении контракта на его разработку. В рамках этой дисциплины проводится

оценка требований, проектных решений, архитектуры, рисков разработки,

связанных с имеющимися материальными и человеческими ресурсами,

показателями качества ПП, а также оценка финансовых расчетов на всех процессах

выполняемых договоров с каждым исполнителем [6–9, 52, 54, 133, 140, 141].

Техника измерения ПП изложена в ряде стандартов (ISO/IEC 14143, 19761,

20926 и др.), а оценивания ПП отражена в ряде методов, некоторые из которых

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

размера ПП (Function Points Analyses, Feature Points, Mark-H Function Points, 3D

Function Points и др.), оценки трудозатрат на разработку ПП с помощью семейства

моделей COCOMO, набор математических моделей оценки трудозатрат на

разработку ПП (Angel, Slim, Seer-SEM и др.), а также интегрированная модель,

объединяющая экономические показатели жизнеспособности и качества ПС [6,

190, 141]. Рассмотрим некоторые из них.

Метод Function Points (FP) предназначен для определения элементарных

функций ПС и их внутренних и внешних информационных объектов. Экспертная

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

средняя, высокая) зависит от количества структурных элементов каждого объекта

данных и ссылок функций на эти объекты.. Каждому типа элемента объекта и

уровню сложности ставят в соответствие весовой коэффициент. Рассчитаем

показатель функциональности объектов – УОФ (отдельно для данных и функций),

результаты просуммируем по формуле:

334



  



iфa

WфSфWoSoУОФУOФУОФ

где So – количество внешних и внутренних информационных объектов, Wo –

весовые коэффициенты сложности; Sф – количество функций ввода, вывода;, Wф –

соответствующие весовые коэффициенты сложности.

Метод Mark-ІІ Function Points основан на выделении одного (а не пяти, как в

FP-методе) базового логического элемента – логической транзакции [231].

Функциональный размер ПС – это сумма размеров всех логических транзакций.

Каждая из них включает в себя: исходные данные и функцию обработки

сохраненных в ПС данных (например, в реляционных таблицах). Сложность

транзакций устанавливается экспертным путем. Метод применяется в системах

обработки данных, работающих с большими объемами данных.

Метод 3D Function Points (3D FP) основан на предположении, что сложность

любой ПС рассматривается в трех измерениях – сложность данных, функций и

управления [241]. Для получения общего размера ПС экспертным путем оценивают

уровень сложности одних-двух характеристик по каждому измерению. Для оценки

сложности данных (СкД) непосредственно используют FP-метод. Для оценки

сложности функций (СкФ) устанавливают число трансформаций (Nтранс) –

совокупность шагов процесса обработка данных (т.е. число операций, которые

преобразуют вход в выход) и семантических утверждений, которые руководят

выполнением операций. Каждая трансформация «решается» на трех уровнях

сложности (низкая, средняя и высокая). Для оценки сложности управления (СкУ)

определяют множество уникальных состояний (Nс), в которых может находиться

процесс, а также множество переходов (Nп) между состояниями. Значения СкУ

определяется по формуле:

NпNcСкУ





Расчетная формула для функционального размера имеет вид:

СкУСкФСкДУОФ





Метод измерения функционального размера представляет собой развитие FP-

метода в плане улучшения точности оценок функционального размера сложных

ПС, который использует базовые расчетные элементы FP–метода (внутренние и

внешние объекты данных, функции ввода, вывода, запроса) и функциональный

элемент – алгоритм. Сложность объектов, функций и алгоритмов устанавливается

экспертным путем, как и в методе FP. Метод применяется в системах реального

времени, ОС, системах управления процессами и др. Для учета сложности метод

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

первого до пятого и по суммарному уровню сложности характеристик определение

общего функционального размера ПС:

ПФРКсложFeP





Анализ методов оценивания функционального размера ПС показал, что

унифицированную оценку объема функциональных возможностей ПС в так

называемых Functional Points (FP) – условных единицах функциональности – на

протяжении всего ЖЦ ПС предоставляет методология Function Points Analysis

(FPA) [190, 229] на основе требований к ПС и сложности реализации функций

обработки данных.

Метод Object Points for ICASE использует для оценки объекты типа – экранные

формы, формы отчетов и модули. Метод применяют для расчета функционального

335

размера [6]. Для этого определяют число объектов каждого вида и экспертным путем

для каждого из них устанавливают уровень сложности (простой, средний и сложный)

в зависимости от количества полей в формах и количества и типа источников

данных (на сервере / клиенте). Затем определяют относительный вес элементов в

зависимости от уровня сложности. Функциональный размер вычисляют как сумму

полученных значений по всем объектам.

Оценка затрат. Среди основных категорий методов оценки затрат наиболее

широкое применение нашли методы экспертных оценок и методы параметрических

уравнений [141, 257]. Основным преимуществом методов первой категории

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

от компетентности экспертов. Преимущества методов второй категории –

возможность повторения оценок (выполнения расчетов по моделям), простота

модификации входных данных и корректировки формул с учетом условий

разработки проектов.

Наиболее известные модели – композиционные модели семейства COCOMO

(табл.10.2).

Т а б л и ц а 10.2

Название модели Назначение модели

COCOMO II – Constructive

Cost Model

Полная трехуровневая модель оценки затрат для новых

проектов ПС

COINCOMO – Constructive

Incremental COCOMO

Учет и распределение затрат при итеративной разработке с

интеграцией оценок для проекта

COPROMO – Constructive

Productivity-Іmprovement

Model

Оценка эффективности вложения ресурсов в новые технологии

для улучшения производительности.

COPLIMO – Constructive

Product Line Investment

Model

Поддержка оценивания стоимости линии продуктов и анализ

отдачи от инвестиций

COPSEMO – Constructive

Phased Schedule & Effort

Model

Распределение оценок затрат на процессах разработки.

Применяется совместно с CORADMO

CORADMO – Constructive

Rapid Application

Development Model

Оценивание и распределение затрат для небольших проектов,

которые разрабатываются согласно модели быстрой разработки

(RAD)

COCOTS – Constructive

Commercial-Off-The-Shelf

Cost Model

Оценка затрат, связанных с выбором и интеграцией готовых

(COTS) программных продуктов в ПС

COSOSIMO – Constructive

System Systems Integration

Cost Model

Оценка затрат, связанных с определением и интеграцией

крупномасштабных интегрированных распределенных ПС

WEBMO – Cost Model for

Web Application

Оценка трудозатрат и продолжительности разработки веб-

приложений

В данных моделях используются экспертные и алгоритмические методы оценки

[6–9, 29]. Их основные отличия – это учет разных видов работ, факторов, которые

влияют на затраты, а также распределение затрат по процессам и видам работ в

зависимости от модели ЖЦ.

Для расчета трудоемкости разработки ПС по моделям семейства COCOMO

сначала вычисляется функциональный размер ПС в FP, который конвертируется в

KSLOC.

336

Оценки трудозатрат Тп определяются по формуле









)( ,

где





)(

K – произведение коэффициентов стоимостных атрибутов, оценки

которых могут быть получены экспертным путем на ранних процессах разработки

ПС; А = 2.45 константа, полученная по результатам статистического анализа

фактических данных для 80 реальных проектов; V – предвиденный размер ПС или

его компонента в KSLOC







01.091.0

ФВ ;

Фj – значение соответствующих коэффициентов масштаба, которые

характеризуют сложность и условия разработки ПС. Равенство их рейтингов

устанавливаются экспертным путем.

Оценка рисков. Экспертным путем может оцениваться риск проекта

разработка ПС – SRE (Software Risk Evaluation), рекомендованный специалистами

SEI [6– 9, 141, 230]. Он регламентирует выполнение процесса идентификации,

анализа и разработки стратегий ослабления рисков создания ПС. Процесс SRE

включает пять шагов:

– идентификация целей проекта, достижения договоренностей относительно

SRE и координация ресурсов на проведение оценивания по SRE;

– оценка по методу SRE путем опроса участников проекта в целях

формулирования утверждений о рисках, их анализ, упорядочение по приоритетам в

контексте последствий для проекта и группировка рисков по областям рисков;

– повторный анализ области рисков, описание рекомендаций по тем рискам,

которые должны быть охвачены при планировании ослабления рисков и

согласование их с менеджером проекта;

– определение целей, стратегий и действий, связанных с рисками, создание

планов верхнего уровня по ослаблению рисков в выбранном подмножестве

областей рисков, а также обсуждение с участниками проекта, руководства и

командой оценщиков;

– формирование заключительного отчета по информации о рисках в проекте.

Для получения экспертных оценок участников проекта относительно рисков

используется вопросник, основанный на таксономии риска TBQ (Taxonomy Based

Questionnaire), которая охватывает области риска в категориях, связанных с

продуктом, процессом и источниками ограничений проекта.

Одной из сфер применения экспертных методологий в программной инженерии

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

организации-разработчика ПС [6, 7], среди которых наиболее популярные модели

семейства CMMs (Capability Maturity Models).

Семейство моделей CMM включает: SW-CMM (CMM for Software) – модель

зрелости процесса разработки программных продуктов; SE-CMM (System

Engineering CMM) – модель зрелости процесса системной инженерии; SSE-CMM

(System Security Engineering CMM) – модель зрелости процесса обеспечения

безопасности системы; SA-CMM (Software Acquisition CMM) – модель зрелости

337

процесса закупок ПО; People CMM – модель зрелости процесса управления

кадрами.

Модель SW-CMM [5-10] (CММ for Software) идентифицирует 5 уровней

зрелости организации и распределенных 18 обязательных ключевых направлений

деятельности КРА (Key Process Area). В структуре описания каждого KPA выделен

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

действий. Один из разделов KPA – предназначен для описания требований к

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

Таким образом, алгоритм установления уровня зрелости (от 2 до 5) на основе

анализа результатов измерений СММ пока отсутствует. Он находится на стадии

разработки.

Метод оценки стоимости. Оценка стоимости затрат на разработку ПС можно

осуществить, используя семейство моделей СОСОМО [6–8, 29], отличающихся

друг от друга элементами, определяющими количество дефектов, отдачу от

инвестиций, затраты на стадиях разработки, интеграции составляющих системы и

др. Эта модель объединила три техники оценки проекта. В первой модели

СОСОМО1 используются показатели цены, персонал и свойства проекта, продукта

и среды. Эти показатели определяются на трех стадиях ведения проекта. На первой

стадии строится прототип системы для задач повышенного риска и проводится

оценка затрат (например, число таблиц в БД, экраны и отчетные формы др.). На

второй стадии оцениваются затраты на проектирование и реализацию

функциональных точек проекта согласно требованиям к проекту. На третьей стадии

проводится оценка размера системы в готовых строках программ и с учетом

других факторов.

Для этой оценки применяют следующее уравнение: E=bS

m(X), где первичная

оценка bS

корректируется с помощью вектора стоимости m(X) и учета числа

старых и новых объектов. Параметр с изменяется от 0 до 1.0 для первой стадии и

от 1.01 до 1.26 для остальных стадий.

Стоимость проекта можно определить по формуле

E = (a+bS

) m (X),

где S – оценка размера системы, а, в, с – эмпирические константы, Х[n] – вектор

факторов стоимости, m – регулирующий множитель, основанный на затратных

факторах.

В работе [29] предложена модель оценки, полученная экспериментальным

путем: E = 5.25S

0.91

. Эта модель применялась при оценке проекта, в котором

программы имели размер от 4000 до 467000 строк кода и были написаны на 28

различных ЯП для 66 компьютеров. На разработку было затрачено от 12 до 11758

человеко–месяцев. В [8] предложено такое уравнение затрат организации–

разработчика: E = 5.5+0.73S

1.16

Таким образом, сущность экономической дисциплины определяется

фундаментальными методами экспертной и количественной оценок экономических

показателей продукта и процессов. Оценка зависит от принципов распределения и

проведения экспертиз в сложных системах, а также от методов расчета стоимости

отдельных частей систем с учетом их размера, существующих стандартов по

измерению и оценке готового продукта.

Иными словами, систематическое использование методов экономических

расчетов и экспертиз продуктов и процессов – основополагающие элементы

338

экономики в ПИ. Такие методы должны использоваться в индустриальном цикле

производства продуктов и процессов.

10.3.5. ОСНОВНЫЕ АСПЕКТЫ ИНДУСТРИИ ПРОГРАММНЫХ

ПРОДУКТОВ

Главным вопросом индустрии, как таковой, является не только изготовление и

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

области ПИ продукты массового производства, создаваемые известными фирмами

Microsoft, IBM, Intel и др., а также результаты аутсорсинга (обновление

устаревшего, унаследованного ПО), приносят владельцам большие прибыли. Этим

подтверждается (в соответствии с толкованием понятия «производство»), что виды

ПП этих фирм выпускаются на индустриальной основе. Производство ПП

базируется на технологических процессах изготовления определенных видов

продуктов с применением теории проектирования и инструментальных сред

поддержки выпуска ПП.

Первые образцы индустриального производства – технологическая подготовка

разработки ПП (ТПР) [119–121], линия продукта (Product line) Института

программной инженерии (SEI) США [224], обеспечивающая удовлетворение

рыночных потребностей пользователей на некоторые виды программной

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

инженерия приложений, доменов, семейств систем, средства поддержки их

производства (ОС, общесистемные средства, новые языки, интегральные среды и

т.п.), а также современные инструментальные системы и среды (Microsoft Visual

Studio System Teams, MSF и др.), которые поддерживают весь производственный

цикл работ по изготовлению ПП.

ТПР применялась при разработке АІС ”Юпитер” для производства программ

обработки данных на нескольких объектах этой системы. В последние годы ТПР не

развивалась из-за отсутствия такого рода систем. Производство ПП на упомянутой

линии продуктов осуществляется из готовых программ, информационных ресурсов,

ПИК, средств и инструментов по ТЛ, в которую включаются необходимые методы

разработки, тестирования и оценивания конечного результата. Технология

конструирования ПП на ТЛ выполняется на основе каркаса ПП и применения

готовых КПИ. Инструментальная среда их разработки должна содержать

необходимые средства и инструменты производства, а также механизмы

отслеживания процесса изготовления продукта в соответствии с установленным

заказчиком требованиями и планом.

Для производства программных продуктов по ТЛ требуется инженерная,

технологическая и экономическая дисциплины для нормативного и

регламентированного проведения работ как это происходит в любой

производственной деятельности. Эту организационно-управленческую работу

выполняют такие специалисты, как менеджеры, эксперты, оценщики и др. В их

функции входит управление, проведение экспертиз, измерение и оценивание

разных видов объектов на ТЛ.

Формальное описание дисциплин производства ПП. В предметной области

ПИ выделены дисциплины (Di), которые обеспечивают основные аспекты

организационно-управленческой деятельности организации-разработчика ПП:

ПИ = {DiSc, DiEn, DiEc, DsMa},

339

где DiSi – научная, DiEn – инженерная, DiEc – экономичная, DiMa –

управленческая дисциплины, которыми должны владеть участники процессов

производства ПП (аналитики – Sciences, инженеры – Engineers, экономисты –

Economics, управленцы – Managers).

Производственную деятельность (РА – product activity) участников процесса

производства ПП зададим кортежем:

PA = < ТЛ, Ap, Rp >,

где ТЛ = {Tp



CP}, Tp – учебный процесc и процесс управления СP (Control

process); Ap = { DiSi



DiEn



DiEc



DiMa} – подобласти (дисциплин) ПрО; Rp

– квалификационные требования к участникам ТЛ при производстве ПП;

Сопоставление нормативно-методического обеспечения процессов ТЛ и

принципов стратегического управления [179] позволяет их рассматривать

единообразно как процесс управления изготовлением ПП согласно целевым

требованиям и подходов к усовершенствованию. При этом предполагается, что на

ТЛ будут многократно выполняться оценочные действия для установления

значений актуальных критериев достижения заданных целей (или целевых

характеристик) для управляемых (контролируемых) объектов и элементов

деятельности по управлению ими (называемых оцениваемыми объектами ПрО).

Инженерия индустриального производства программных продуктов

К настоящему времени разработано много подходов и методов производства

ПП [46, 105, 109, 205, 209]. Они сыграли важную роль в формировании

производственного характера изготовления ПП. На смену пришли

усовершенствованные или новые методы и технологии, которые соответствуют

производству ПП. Например, ряд зарубежных фирм занимаются выпуском

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

инструментальных инструментах и средствах автоматизированного производства

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

технологические линии изготовления продуктов. Фирмы–изготовители проводят

мониторинг для определения запроса на выпуск некоторого вида программной

продукции.

Для организации производства готовятся несколько команд разработчиков.

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

информационного, технологического и технического состояний среды для

изготовления продукта. Вторая команда – это разработчики ПС. Третья команда –

это служба контроля хода разработки и оценки объектов производства: простых,

готовых КПИ и сложных, создаваемые из них продуктов.

Известными средами с такой организацией изготовления ПП являются линии

производства (Product Line Practice), система Microsoft Visual Studio Teams

Systems, Microsoft MSF, CORBA и т.п. [82, 133, 140, 241]. Рассмотрим их

детальнее.

Технология изготовления ПП в системе Microsoft

Основное назначение данной технологии – управление проектом предприятия

EPM (Enterprise Project Management). Основные инструменты технологии такие:

– пакет инструментов VSTS (Visual Studio Teams Systems) для разработки

340

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

тестировщиков, программистов, кодировщиков и др.), которые могут выполнять

работы, находясь в разных географических точках;

– методология MSF (Microsoft Solution Arhitecture) для построения

производственной архитектуры предприятия с помощью ЖЦ (Software Development

Life Cycle), стандарта PMBOK, моделей перспектив и процессов [133, 140, 219] ;

– система Professional Studio и Foundation Server для поддержки процессов

проектирования, кодирования, тестирования, формирования версий ПП и т.п.;

– система CMMI Process Impovement для регулирования сроками разработки с

помощью технологии Agile.

Пакет VSTS – это семейство продуктов для проектирования ПС, в котором

разные члены команды распределены на разных работах проекта в зависимости от

их квалификации и категории (рис.10.13).

Рис.10.13. Категории разработчиков в пакете VSTS

Согласно приведенной схемы переход исполнителей в более высшую

категорию возможен по мере роста его знаний и выполненных работ.

Инструментами разработки разных программных продуктов являются: IDE

(Integrated Development Environment), Microsoft Office Project и Microsoft Office

Excel, а также:

– Microsoft SQL Server 2005 для ведения результатов, исходного кода и данных

через инструменты Analysis и Reporting Services и SharePoint Portal Services;

– Microsoft Project 2003 и Microsoft Excel 2003 для управления и

планирования работ в проекте.

Таким образом, среда VSTS служит примером коллективного изготовления ПП.

В ней имеются инструменты для поддержки процессов ЖЦ с учетом плановых

работ согласно графику, отслеживания хода разработки, оценки качества и сроков

выполнения проекта.

Средства и инструменты методологии MSF

Методология MSF – это система стратегий, принципов и методов управления

проектом производственной архитектуры предприятия. с учетом заданных