Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Таблица 9.39. Рейтинги значения стоимостных атрибутов

Уровень оценки Атрибуты

Очень низкий Низкий Номинальный Высокий Очень высокий

Сложность и надежность

продукта (приложения)

(СЛНД)

Только клиентское

приложение,

не распределенное,

простые вычисле-

ния и I/O,

не требуется высо-

кая надежность

Клиент-серверное,

ограниченно рас-

пределенное,

стандартные вы-

числения, управле-

ние файлами, поте-

ри легко восстано-

вить

Клиент-серверное,

полностью распре-

деленное,

интегрированное,

с базами данных,

требуется обычное

восстановление

Клиент-серверное,

глобально распре-

деленное,

сложные вычисле-

ния,

высокая стоимость

потерь из-за оши-

бок

Клиент-серверное,

полностью распре-

деленное, тесное

взаимодействие,

робота в режиме

реального времени,

последствия оши-

бок критичны

Значения 0.63 0.85 1.00 1.3 1.67

Сложность программно-

аппаратной среды

(изменчивость ОС и се-

тевых серверов)

(СПАС)

Редкие изменения

платформы, скоро-

стная сеть, наи-

лучшая возможная

связь, нет ограни-

чений на ресурсы

(время и память)

Небольшие изме-

нения платформы,

быстрый сетевой

сервис, незначи-

тельные проблемы

с ресурсами

Стабильная плат-

форма, приемлемая

производитель-

ность сети; прием-

лемая связь, требу-

ется контроль ре-

сурсов

Частые изменения

платформы,

медленная сеть,

плохая связь, не-

достаточные ре-

сурсы приводят к

проблемам

Нестабильная

платформа, низкая

производитель-

ность, плохая

связь, ограничен-

ные ресурсы

Значения 0.75 0.87 1.00 1.21 1.41

Квалификация разработ-

чиков (ПЕРС)

15 проц

Большие простои

(текучесть кадров)

35 проц

Небольшие про-

стои

55 проц

Очень маленькие

простои

75 проц

Редкие простои

90 проц

Отсутствие про-

стоев

Значения 1.55 1.35 1.00 0.75 0.58

Опыт работы (ОРАБ) ≤ 2 мес ≤ 6 мес ≤ 1 год ≤ 3 года ≤ 6 лет

Значения 1.35 1.19 1.00 0.87 0.71

Инструментальная под-

держка и среда проекта

(ИСРП)

Международная

разработка, без

взаимодействия,

языковые средства,

базовые методы

Несколько городов,

частичное взаимо-

действие, базовые

CASE- средства,

базовые методы

Один город, мето-

ды для всего ЖЦ,

хорошие инстру-

менты, команды

разработки

Одно здание,

интегрированные

методы и инстру-

менты, объединен-

ные команды

Одна рабочая сре-

да, интегрирован-

ные методы и сред-

ства с поддержкой

взаимодействия

Значения 1.36 1.13 1.00 0.86 0.68

Уровень оценки Атрибуты

Очень низкий Низкий Номинальный Высокий Очень высокий

Ограничение сроков раз-

работки

(ОСР)

Требуется сокра-

щение до 75% от

номинального (на

25%)

Требуется сокра-

щение до

85 % от номиналь-

ного (на 15%)

Нет сокращения

100%

Можно увеличить

до

130%

Можно увеличить

до 160%

Значения 1.35 1.15 1.00 1.05 1.10

Требуемое повторное

использование

(ПИПС)

Не используется Не используется Не запланирован-

ное повторное ис-

пользование

Планируемое по-

вторное использо-

вание или библио-

течные компонен-

ты

Систематическое

повторное исполь-

зование, основан-

ное на архитектуре

Значения - - 1.00 1.25 1.48

Коллективизм

(степень сотрудничества)

(КОЛЛ)

Отсутствие едино-

го видения и со-

трудничества

Некоторое взаимо-

понимание и взаи-

модействие

Во многом общее

видение, группы по

функциональным

направлениям

Полное взаимопо-

нимание, тесное

взаимодействие

Исключительно

хорошее взаимо-

понимание

Значения 1.45 1.31 1.00 0.75 0.62

Эффективность процесса

(ЭФПР)

Полностью не

управляемый (ad

hoc) – «героиче-

ский»

Настроенный на

проект, основан-

ный на роли лиде-

ра

Четкий процесс,

основанный на

процессном подхо-

де

Эффективный про-

цесс, применение

эффективных прак-

тических приемов

работы

Эффективный про-

цесс, стремление

рационально рас-

пределить время

Значения 1.36 1.20 1.00 0.86 0.65

466 Глава 8

9.4. Характеристика основных инструментов оценки затрат

В табл. 9.40 перечислены наиболее распространенные инструменты оценки

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

рассмотренных выше методах.

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

найти, например, по адресу: http://www.laatuk.com/tools/effort_estimation_tools.html,

а также с помощью поисковых серверов.

Таблица 9.40. Инструменты оценки затрат на разработку ПС

Название инструмента Фирма-изготовитель и адрес в Интернет

PRICE S

Lockheed - Martin PRICE Systems

http://www.pricesystems.com/

ESTIMACS

Computer Associates International Inc.

http://www.cai.com/products/estimacs.htm/

ESTIMATE Professional

Software Productivity Center

http://www.spc.com/

EstimatorPal

http://www.effortestimator.com/

EZEstimate

Strive Logic

http://www.openrage.com/main/ezestimate_full.htm/

KnowledgePlan

Software Productivity Research Inc.

http://www.spr.com/

SEER-SEM (System Evaluation and

Estimation of Resources - Software

Estimation Model)

Galorath Associates, Inc., SEER Technologies Division

http://www.galorath.com

SLIM (Software Life Cycle Model )

Quantitative Software Management, Inc. (QSM)

http://www.qsm.com/

SOFTCOST-R

Reifer Consultants, Inc (RCI)

www.reifer.com/

Function Point Workbench

Software Productivity Research Inc.

http://www.spr.com

COSTAR

Softstar Systems Inc.

http://www.softstarsystems.com/

SystemStar

SoftStar Systems

http://www.softstarsystems.com/

SCOPE IT

SCOPE IT Inc.

http://www.scopeit.com/

В работе [28] представлены результаты анализа применения разных мето-

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

ны такие основные характеристики современных инструментов:

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

ционального размера, функциях и др.;

– распределение затрат и продолжительности по стадиям и видам работ

применительно к разным моделям разработки;

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

Глава 9 467

– поддержка оценивания затрат на проекты новых ПС, а также на сопро-

вождение и развитие ПС.

Кроме того, как указано в [28], в результате анализа многих проектов выяв-

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

ментов, оказались более точными, чем полученные «ручными» методами оцени-

вания. Особенно это касается оценки затрат на «общесистемные работы» (анализ

требований, документирование, управление проектами и др.).

Для небольших проектов и работ по проектированию, программированию

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

одинакова.

Представляет определенный практический интерес предложенная в [28]

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

шести типов ПС:

- Web-проекты. К ним относят приложения, разрабатываемые для под-

держки корпоративных Web-сайтов,

- информационные системы (ИС). К ним относят ПС, поддерживающие

стандартные функции ввода, обработки и хранения информации,

- аутсорсинговые системы. К ним автор относит ПС, разрабатываемые

внешними организациями-разработчиками (вне страны-производителя ПС),

- коммерческие ПС. К ним относят ПС, разрабатываемые для продажи (а

не по заказу). Это любые пакетные продукты (так называемые COTS-продукты),

например, текстовые процессоры,

- встроенное ПО. Это ПО, разрабатываемое для управления физически-

ми устройствами (в частности, средствами телекоммуникации),

- военные ПС. К ним отнесены любые разработки систем, выполняемые в

соответствии с требованиями военных стандартов.

Структурная декомпозиция работ и процентное соотношение затрат для

указанных выше типов проектов представлены в таблице 9.41. Эти данные могут

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

Как видно из таблицы 9.41 в разных типах проектов состав работ значи-

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

оценивания.

Таблица 9.41. Долевое распределение затрат на создание разных типов

ПС в разрезе видов работ

Тип ПС

Виды работ

Web-

прое-

кты

ИС Аут-

сор-

синг

Ком-

мер-

ческие

Встро

енные

Во-

енны

е

Определение требований 5.0% 7.5% 9% 4% 4% 7%

Прототипирование 10.0% 2.0% 2.5% 1.0% 2.0% 2.0%

Разработка архитектуры 0.5% 1.0% 2.0% 1.5% 1.0%

Планирование проекта 1.0% 1.5% 1.0% 2.0% 1.0%

Предварительное проектирова-

ние

8.0% 7.0% 6.0% 7.0% 6.0%

468 Глава 9

Тип ПС

Виды работ

Web-

прое-

кты

ИС Аут-

сор-

синг

Ком-

мер-

ческие

Встро

енные

Во-

енны

е

Техническое проектирование 7.0% 8.0% 5.0% 6.0% 7.0%

Проверки проекта 0.5% 1.5% 2.5% 1.0%

Программирование 30.0% 20.0% 16.0% 23.0% 20.0% 16.0%

Включение готовых компонен-

тов

5.0% 2.0% 2.0% 2.0% 2.0%

Приобретение пакетов 1.0% 1.0% 1.0 1.0

Инспекции кода 1.5% 1.5% 1.0%

Независимая верификация и

валидация

1.0%

Управление конфигурацией 3.0% 3.0% 1.0% 1.0% 1.5%

Формальная интеграция 2.0% 2.0% 1.5% % 2.0% 1.5%

Документация пользователя 10.0% 7.0% 9.0% 12.0% 10.0% 10.0%

Автономное тестирование 30.0% 4.0% 3.5% 2.5% 5.0% 3.0%

Функциональное тестирование 6.0% 5.0% 6.0% 5.0% 5.0%

Интеграционное тестирование 5.0% 5.0% 4.0% 5.0% 5.0%

Системное тестирование 7.0% 5.0% 7.0% 5.0% 6.0%

Опытная эксплуатация 6.00% 1.5% 3.0%

Приемочное тестирование 5.0% 3.0% 1.0% 3.0%

Независимое тестирование 1.0%

Обеспечение качества 1.0% 2.0% 2.0% 1.0%

Инсталляция/обучение 2.0% 3.0% 1.0% 1.0%

Управление проектом 10.0% 12.0% 12.0% 11.0% 12.0% 13.0%

Всего 100% 100% 100% 100% 100% 100%

Количество работ 7 18 21 20 23 25

Литература к главе 9

1. Боэм Б.У. Инженерное проектирование программного обеспечения. М., Радио и связь. -

1985. – 511 с.

2. Boehm B., Abts C., Chulani S. Software Development Cost Estimation Approaches – A Sur-

vey.-46р. /sunset.usc.edu/publications/TECHRPTS/2000/usccse2000-505/usccse2000-505.pdf

3. Putnam L. A General Empirical Solution to the Macro Software Sizing and Estimation Prob-

lem, IEEE Trans. Software Eng., SE-4, n.4, 1978, pp.345-361.

4. SLIM Suite. Tools for Software Project Management // http://www.qsm.com/SLIMSUITE.pdf

5. Fischman L., McRitchie K., Galorath D. Inside SEER-SEM. -http://www.stsc.hill.af.mil/

crossTalk/2005/04/0504Fischman.pdf

6. Wiegers K.E. Stop Promising Miracles - http://www.processimpact.com/

7. Kavoussanakis K, Terry Sloan UKHEC Report on Software Estimation. – 23р.

//www.ukhec.ac.uk/publications/reports/estimation.pdf

8. Cowderoy, A.J.C., Jenkins J.O. Cost estimation by analogy as a good management practice. //

Proc. Software Engineering 88, ed. Pyle I.C., Liverpool: IEE/BCS.- 1988.- p. 80-84.

Глава 9 469

9. Automated Project Cost Estimation: Using Analogies. The ANGEL Project -

http://dec.bournemouth.ac.uk/ESERG/ANGEL/

10. Shepperd M., Schofield C. Effort Estimation by Analogy: A Case Study // ESCOM’7, Wilms-

low, 1996, p.4. - http://www.ecfc.u-net.com/cost/index.htm

11. SPR KnowledgePLAN - http://www.spr.com/

12. Электронный учебник. – Словарь Н - http://www.statsoft.ru/home/textbook/glossary/

gloss_n.html

13. Gray A., MacDonell S. A Comparison of Techniques for Developing Predictive Models of

Software Metrics // Information and Software Technology.- V.39.- Nov. 6, - June 1997, pp.

425-437.

14. Neural Network - //www.statsoft.ru/home/products/neuralnetwork/details/master/default.htm

15. Stamelos I., Angelis L., Sakellaris E. On the Use of Bayesian Belief Networks for the Predic-

tion of Software Productivity // Information and Soft. Techn. - V.45. - N.1.-2003.- P.51-60.

16. Abdel-Hamid T. Adapting, Correcting, and Perfecting Software Estimates: a Maintenance

Metaphor // IEEE Computer.- 1993.- V.26.- N.3.

17. Stellman A., Greene J. Applied Software Project Management. Estimation -

http://www.stellman-greene.com/images/stories/LectureNotes/03%20estimation.pdf

18. COCOMO Suite Methodology and Evolution / Barry Boehm, Ricardo Valerdi, Jo Ann Lane,

and Winsor Brown // University of Southern California Center for Software Engineering -

http://www.stsc.hill.af.mil/crossTalk/2005/04/0504Boehm.html

19. ISO/IEC 15288: 2002 Systems engineering. Systems life cycle processes (ДСТУ ISO/IEC

15288: 2005 Інженерія систем. Процеси життєвого циклу системи)

20. Banker D. et al., Automation Output Size and Reuse Metrics in a Repository-Based CASE

Environment // IEEE Trans. Soft.Eng. - 1994.- SE 20.- N.3.- P.169-186.

21. СOCOMO II Model Definition Manual (Version 1.4), USC, 1997, 78 p.

22. http://www.sunset.usc.edu/research/COCOMOII/cocomo_main.htm

23. Model-Based Architecting & Software Engineering (MBASE) - http://sunset.usc.edu/

research/MBASE

24. Jacobson I., Booch G., Rumbaugh J. The Unified Software Development Process. // Addison-

Wesley, 1999. – 463 p.

25. Reifer D. J. Web Development: Estimating Quick-to-Market Software // IEEE Software.-

2000.-V.17.- N.6.-P.57-64.

26. Reifer, D. J. SoftCost-OO Reference Manual, Reifer Consultants, Inc.- 1993.

27. Cleary D. Web-Based Development and Functional Size Measurement // Proc. of IFPUG An-

nual Conf., San Diego, USA, Sept. 2000 – www.charismatek.com.au/_public1/pdf/webfsm.pdf

28. Jones C. Software Cost Estimating Methods for Large Projects//

http://www.stsc.hill.af.mil/crossTalk/2005/04/0504Jones.pdf

470

Глава 10. УПРАВЛЕНИЕ РИСКОМ ПРОЕКТОВ

10.1. Парадигма управления риском проекта

10.1.1. Элементы парадигмы управления риском SEI

Понятие риск проекта связывается с возможностью понести потери в ходе

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

го продукта, превышении стоимости его разработки, задержке окончания разработ-

ки или в срыве проекта (то есть, отказе заказчика от проекта).

Величина риска определяется произведением серьезности последствий не-

желательного события в проекте (уровнем потерь) и вероятности наступления

этого события.

Серьезность последствий оценивается с позиций влияния нежелательного

события, с одной стороны, на характеристики ПС и сложность ее последующего

сопровождения, а, с другой, - на эффективность, стоимость и продолжительность

процесса разработки ПС.

Вероятность оценивается по степени определенности, с которой можно про-

гнозировать проявление каждого риска в проекте, заключающееся в перерастании

этого риска в проблему для проекта.

Здесь мы использовали определение риска в трактовке института SEI (Soft-

ware Engineering Institute), который предложил четкую парадигму, программу и ряд

практических методов управления риском разработки проектов ПС [1].

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

касающиеся управления риском в области программной инженерии (рисунок 10.1).

Р

е

г

у

л

и

р

о

в

а

н

и

е

Идентификация

А

н

а

л

и

з

П

л

а

н

и

р

о

в

а

н

и

е

У

ч

е

т

и

к

о

н

т

р

о

л

ь

Коммуникация

Рис. 10.1. Парадигма управления риском

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

чается в непрерывности процесса управления риском. Ориентация стрелок указы-

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

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

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

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

Глава 10 471

Краткий обзор основных функций парадигмы представлен в таблице 10.1, а

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

содержится в разделе 10.4.

Таблица 10.1. Функции парадигмы управления риском

Функции па-

радигмы

Цель

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

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

пользоваться ЛПР для принятия адекватных решений: определить

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

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

рисков по областям риска и приоритезировать риски по степени важ-

ности.

Планирование Использовать проанализированную информацию о рисках для выра-

ботки решений и плана действий по каждому риску. Интегрировать

эти решения и планы в единый план управления риском проекта ПС.

Учет и кон-

троль

Наладить учет и контроль состояния каждого риска и действий по его

устранению (или снижению его величины), используя для этого мет-

рики риска. Контролировать соблюдение представленного в плане

графика действий по риску и эффективность самого плана действий.

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

своевременную и эффективную коррекцию отклонений в запланиро-

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

Коммуникация Обеспечить непрерывную эффективную передачу информации и об-

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

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

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

и внешние для проекта источники информации о риске.

10.1.2. Таксономия риска

Базис для организации данных и управления риском в парадигме SEI обеспе-

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

риска проекта ПС [2].

Таксономия риска охватывает наиболее общие области риска проекта, ка-

сающиеся характеристик ПС, среды и процессов разработки и ограничений проек-

та

1

(рисунок 10.2).

Эта таксономия имеет иерархическую структуру и систематизирует источни-

ки (области) риска по трем уровням (рисунок 10.3):

• класс,

• элемент класса,

• атрибут элемента

2

.

1

Таксономия риска SEI была проверена на более чем 30 проектах ПС.

На практике

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

2

Сохранено название уровней, предложенное SEI

472 Глава 10

А. Технические аспекты В. Среда и технология С. Внешние ограничения

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

1. Требования 6. Процесс разработки 11. Ресурсы

а) Стабильность а) Формализованность а) Сроки разработки

б) Полнота б) Укомплектованность б) Штат проекта

в) Однозначность в) Контролируемость в) Финансирование

г) Достоверность процесса г) Средства разработки

д) Реализуемость г) Опыт применения

е) Новизна д) Контролируемость 12. Условия договора

ж) Масштабность продукта а) Тип договора

2. Проект 7. Система поддержки б) Ограничения

а) Функциональность разработки договора

б) Сложность а) Мощность в) Договорные

г) Интерфейсы б) Укомплектованность зависимости

д) Производительность в) Удобство применения

е) Тестопригодность г) Опыт применения 13. Интерфейсы проекта

ж) Аппаратные д) Надежность а) Заказчик

ограничения е) Сопровождаемость б) Смежники

з) Приобретаемое ПО ж) Поставка в) Соисполнители

3. Кодирование и автономное 8. Процесс управления г) Головной

тестирование а) Планирование исполнитель

а) Реализуемость б) Организация проекта д) Высшее

б) Автономное тестирование в) Опыт управления руководство

в) Кодирование/реализация г) Организация взаимодействия е) Продавцы

4. Интеграция и интегра- 9. Методы управления ж) Политические

ционное тестирование а) Мониторинг принципы

а) Среда б) Управление персоналом

б) Интеграция продукта в) Обеспечение качества

в) Интеграция системы г) Управление конфигурацией

5. Нефункциональные 10. Рабочая обстановка

характеристики а) Качество работы

а) Удобство сопровождения б) Кооперация

б) Надежность в) Коммуникация

в) Защищенность г) Моральный климат

г) Безопасность

д) Человеческие факторы

е) Спецификации

Рис. 10.2. Таксономия риска

Класс определяет сферу деятельности по программной инженерии, с кото-

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

область риска в соответствующей сфере деятельности.

Атрибут элемента определяет фактор риска в определенной области риска, с

которым может быть связано нежелательное событие, действие или факт, являю-

щиеся источником риска.

Основные классы областей риска таковы:

Глава 10 473

Риски проекта ПC

Технические аспекты Среда и технология Внешние

разработки разработки ограничения проекта

Требования ... Нефункциональные Процесс ... Рабочая Ресурсы ... Интерфейсы

характеристики разработки обстановка проекта

Стабильность ... Масштабность Формализованность ... Контролируемость Сроки

продукта разработки...

Класс

Элемент

Атрибут

Рис. 10.3. Структура таксономии риска

1.

Технические аспекты разработки (инженерия программного продукта).

В этот класс входят области риска, отождествляемые с процессами (работами) на

стадиях ЖЦ ПС (разработка требований, проектирование, кодирование, тестирова-

ние и др.) и характеристиками рабочих продуктов (требований, проекта, кода и др.)

на этих стадиях;

2.

Среда и технология разработки. В этот класс входят области риска, ото-

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

разработки ПС;

3.

Внешние ограничения проекта. В этот класс входят области риска, ото-

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

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

вия организаций-участников проекта ПС и др.

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

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

работки методов идентификации источников риска путем интервьюирования чле-

нов проекта с использованием вопросника, согласующегося с этой таксономией.

Вопросник, основанный на таксономии риска (для краткости, TBQ, от Taxon-

omy-Based Questionnaire), является инструментом, применение которого гаранти-

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

касающихся нижнего уровня таксономии риска - атрибутов. Количество и форма

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

выбранного метода интервьюирования и обработки его результатов. В любом слу-

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

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

Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

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