ПРОВЕРИМ АЛГЕБРОЙ ГАРМОНИЮ В Н Лукин М В

ПРОВЕРИМ АЛГЕБРОЙ ГАРМОНИЮ В. Н. Лукин М. В. Бахиркин 2013

УПРАВЛЕНИЕ ПРОЕКТОМ Статистика Standish Group по программным проектам (проценты) Год Успешные Неудачные Провалившиеся 1994 16 53 31 1996 27 33 40 1998 26 46 28 2000 28 49 23 2004 29 53 18 2006 35 46 19 2009 32 44 24 2010 32 48 20

УПРАВЛЕНИЕ ПРОЕКТОМ Успешный проект – выполнен вовремя, в рамках бюджета Неудачный проект - выполнен либо с опозданием, либо с превышением затрат Провалившийся проект – закрыт в процессе реализации, не введён в действие

УПРАВЛЕНИЕ ПРОЕКТОМ Факторы, определяющие успех программного проекта: Персонал Методологии границы проекта Время разработки Критерии качества

УПРАВЛЕНИЕ ПРОЕКТОМ Выполнение проекта под угрозой – что делать? Количество разработчиков увеличивать нельзя Новые методологии только затормозят процесс Уменьшение границ проекта невозможно Остаётся пожертвовать временем или качеством

УПРАВЛЕНИЕ ПРОЕКТОМ Как нормальный проект стал неудачным? Плохо учитывались риски Не анализировалась выполнимость Использовалась неправильная методика оценки Ключевые параметры, такие, как время, назначались сверху

ЧТО, КАК И КОГДА НАДО ИЗМЕРЯТЬ В начале работы – для планирования В конце работы – для подведения итогов: учитывается как количественные показатели, так и сложность проекта В течение разработки – для контроля процесса проектирования и управления им

ЧТО, КАК И КОГДА НАДО ИЗМЕРЯТЬ Персонал (количество человек) Затраты (человеко-месяцы) Продолжительность разработки (месяцы) Стоимость работ

ЧТО, КАК И КОГДА НАДО ИЗМЕРЯТЬ Мера – количественная характеристика свойства объекта, которая может быть получена в результате непосредственного измерения Метрика – функция оценки характеристики объекта, которая зависит от значений опорных характеристик

ЧТО, КАК И КОГДА НАДО ИЗМЕРЯТЬ Метрики продукта метрики производительности; метрики качества; технические метрики. Метрики по способу вычисления размерно-ориентированные; функционально-ориентированные; человеко-ориентированные.

АНАЛИЗ РИСКОВ И ПЕРВИЧНАЯ ОЦЕНКА Примеры областей риска качество и стабильность требований пользователя; стабильность и полнота описания внешних интерфейсов; опыт и квалификация кадров; техническая новизна проекта.

АНАЛИЗ РИСКОВ И ПЕРВИЧНАЯ ОЦЕНКА Виды деятельности: идентификация риска; описание риска; оценка риска; управление риском.

АНАЛИЗ РИСКОВ И ПЕРВИЧНАЯ ОЦЕНКА Идентификация риска: риск проектирования; технический риск; деловой риск (бизнес-риск).

АНАЛИЗ РИСКОВ И ПЕРВИЧНАЯ ОЦЕНКА Описание риска: природа риска; область действия; время действия.

АНАЛИЗ РИСКОВ И ПЕРВИЧНАЯ ОЦЕНКА Оценка риска: вероятность проявления; возможные потери. Оценивается влияние риска на проектирование и на продукт

АНАЛИЗ РИСКОВ И ПЕРВИЧНАЯ ОЦЕНКА Управление риском устанавливаются приоритеты с точки зрения нарушения графика, превышения средств, нарушений требований пользователя определяются пути предотвращения наиболее опасных рисков

ЭКСПЕРТНЫЕ МЕТОДЫ применяются с давних времён; используется опыт экспертов; привлекательность – в простоте; риск применения – качество эксперта; несколько экспертов – проблема сведения различных оценок.

ЭКСПЕРТНЫЕ МЕТОДЫ Метод Дельфи разработан в конце 1940 -х годов для прогнозирования эксперты делают независимые заключения ответы обобщаются и возвращаются экспертам эксперты делают новые оценки на их основе формируется окончательная оценка

ЭКСПЕРТНЫЕ МЕТОДЫ Метод декомпозиции работ декомпозиция работ на компоненты, каждый из которых поддаётся оценке; оценка компонента – случайная величина; оценка минимального (mi), максимального (Mi) и вероятного (pi) значения; ожидаемая оценка: Ei = (mi + 4 pi + Mi) / 6; С. К. О. : Si = (Mi - mi) / 6.

РАЗМЕРНО-ОРИЕНТИРОВАННЫЕ МЕТРИКИ Основаны на оценках количества строк кода программ или подобных характеристиках; Нет единственного подхода к оценке для различных языков и ориентированного на универсальное применение.

РАЗМЕРНО-ОРИЕНТИРОВАННЫЕ МЕТРИКИ Выполнение предварительной оценки: оценка показателя по аналогии; оценка «снизу-вверх» экспертным методом; использование метрической базы проектов: Проект Затраты Стоимость Объём Документация Ошибки Персонал

РАЗМЕРНО-ОРИЕНТИРОВАННЫЕ МЕТРИКИ Метрики: Производительность = объём / затраты Качество = ошибки / объём Удельная стоимость = стоимость / объём Удельная документированность = документация / объём

РАЗМЕРНО-ОРИЕНТИРОВАННЫЕ МЕТРИКИ Процесс оценки проекта: Выполняется декомпозиция проекта на функции. Для каждой функции оценивается минимальное, максимальное и вероятное значение объёма и вычисляется ожидаемый объём. По производительности вычисляются затраты. По удельной стоимости вычисляется стоимость.

ПРИМЕР Поступил заказ на проект «Билет» для учёта проданных билетов авиакомпании Подберём из базы проекты, сходные по параметрам Объём проекта оценим экспертным методом Используя значение ожидаемого объёма проекта и средние значения метрик, получаем оценки для нового проекта

ПРИМЕР: МЕТРИЧЕСКАЯ БАЗА ПРОЕКТОВ Проект Затра. Стои- Объём Доку. Пер- Произ- Каче- Удельная Докуты Ошибки мость мент. сонал водит. ство стоим. ментир. Биолаб-М 16 45 33, 5 37 3 2 2, 09 0, 09 1, 34 1, 11 СТАН 1, 5 2 4 10 1 2 2, 67 0, 25 0, 50 2, 50 Натали 3 4 14 65 3 2 4, 67 0, 21 0, 29 4, 64 Адлер-2 8 10 20 21 7 3 2, 50 0, 35 0, 50 1, 05 Адлер-3 7 1 21, 5 43 0 1 3, 07 0, 00 0, 05 2, 00 Формус 4 20 21 36 10 2 5, 25 0, 48 0, 95 1, 71 Прогноз 6 15 18 10 10 2 3, 00 0, 56 0, 83 0, 56 Среднее 18, 86 3, 32 0, 28 0, 64 1, 94

ПРИМЕР: ЭКСПЕРТНАЯ ОЦЕНКА ОБЪЁМА Функции лучший худший вероятный ожидаемый Агенты 0, 700 0, 800 0, 75 Арендодатели 0, 700 0, 800 0, 717 Касса 1, 000 1, 500 1, 417 Справочники 0, 600 0, 800 0, 7 Отчет о продажах 0, 300 0, 400 0, 383 Дисконтные карты 0, 600 0, 700 0, 65 Склад бланков 1, 500 2, 000 1, 800 1, 783 6, 4 Всего

ПРИМЕР: СРАВНЕНИЕ РАСЧЁТНЫХ И РЕАЛЬНЫХ ХАРАКТЕРИСТИК ПРОЕКТА Название проекта Билет (расчёт) Билет (реально) Затраты Стоим Объем Докум. Ошибки страниц шт. /год чел. -мес. тыс. $ СК 1, 93 4, 01 6, 4 12, 4 1, 77 4 4 6, 14

ФУНКЦИОНАЛЬНЫЕ ТОЧКИ Учитывается структурная сложностьпроекта; оценки не зависят от языков программирования; оценка на ранней стадии проектирования. Основной мерой метода служит не размер, а функциональность продукта, которая оценивается на основе информационных характеристик.

ФУНКЦИОНАЛЬНЫЕ ТОЧКИ Информационные характеристики: внешний ввод; внешний вывод; внешний запрос; внутренний логический файл; внешний интерфейсный файл.

ФУНКЦИОНАЛЬНЫЕ ТОЧКИ сложность оценивается по шкале: высокая, средняя, низкая; подсчитываются количества элементов с соответствующим уровнем сложности; вычисляется сумма В произведений этих величин и их весов; вычисляется оценка в функциональных точках: ФТ = B(0, 65 + 0, 01Σi=114 Fi).

ФУНКЦИОНАЛЬНЫЕ ТОЧКИ Метрики: Производительность = ФТ / затраты Качество = ошибки / ФТ Удельная стоимость = стоимость / ФТ Удельная документированность = документация / ФТ

ФУНКЦИОНАЛЬНЫЕ ТОЧКИ 1 ФТ – простая программа, выполняется за день. 10 ФТ – типичное настольное приложение, месяц. 100 ФТ – предел программиста-одиночки. 6 мес. 1000 ФТ – приложение для команды 10 чел. , год. 10 000 ФТ – 100 человек, 1, 5 -5 лет, обычно не укладывается в срок. 100 000 ФТ – 100 человек, 5 -8 лет, обычно безнадёжный проект.

МОДЕЛЬ БОЭМА Конструктивная модель стоимости – COCOMO базовая; промежуточная; усовершенствованная. Применима к проектам трёх типов: органичный (до 50 СК); сблокированный (50 -300 СК); внедрённый (свыше 300 СК).

МОДЕЛЬ БОЭМА Модель COCOMO II – разделы: модель композиции приложения; модель раннего этапа проектирования; модель пост-архитектуры.

МОДЕЛЬ БОЭМА Модель композиции приложения строится макет пользовательских интерфейсов; определяется взаимодействие существующего ПО и компонентов будущей системы; оценивается производительность; определяется степень зрелости технологии.

МОДЕЛЬ БОЭМА Модель раннего этапа проектирования Затраты = А VB Me + Затратыавто А = 2, 5; B = 1, 01 + 0, 01 i=15 Wi, интервал [1, 01. . 1, 26]; V – объём кода (тыс. строк); Me = i=17 EMi – учитывает формирователи затрат (продукт, процесс, персонал); Затратыавто – затраты на автоматическую генерацию кода.

МОДЕЛЬ БОЭМА Модель пост-архитектуры Затраты = А K-req VB Mp + Затратыавто K-req = 1 + (брак / 100) – брак – процент отброшенного кода; Mp = i=117 EMi – учитаваются формирователи затрат (продукт, платформа, персонал, проект); V – объём кода (тыс. строк), V = Vнов + Vповт Vнов – объём вновь написанного кода; Vповт – объём повторно используемого кода

МОДЕЛЬ БОЭМА = Затраты Раб. Коэфф Длительность = (3, 0 Затраты(0, 33 + 0, 2(B – 1, 01))) SCED / 100 Раб. Коэфф принимается равным $15000 в человеко-месяц SCED – процент изменения графика работ. Стоимость

ТОЧКИ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ Определение весовых показателей действующих лиц, показатель A; Определение весовых показателей вариантов использования, показатель UUCP; Определение технической сложности TCF; Определение уровня квалификации разработчиков EF; Вычисление UCP = UUCP TCF EF.

КОНУС НЕОПРЕДЕЛЁННОСТИ Предложен Б. Боэмом в 1981 году; описывает изменение уровня неопределенности в течение проекта; используется в разработке программного обеспечения, где окружение проекта меняется очень быстро

ПРЕДЛОЖЕНИЕ ни один подход нельзя считать достаточным; в начале лучше использовать метод декомпозиции; каждый фрагмент оценивается экспертами; качество экспертов должно влиять на вес оценок; для оценки в целом выбрать метод Дельфи; для контроля проекта разработки стоит воспользоваться конусом неопределённости.

ЛИТЕРАТУРА Бек К. Экстремальное программирование. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. Гецци К. , Джазайери М. , Мандриоли Д. Основы инженерии программного обеспечения. Гласс Р. Факты и заблуждения профессионального программирования. Демарко Т. , Листер Т. и др. Балдеющие от адреналина и зомбированные шаблонами. . Йордон Э. Путь камикадзе. .

1 СЕТЕВОЙ ГРАФИК 2 3 4 7 5 6 8 9 11 12 10 13 14 15 18 16 19 17 20 21 22 23 24 26 25

ДИАГРАММА ГАНТА