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

1981. – 767 p. – Русский перевод: Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. - М.: Радио и связь, 1985. – 512 с.
2. Brooks F.P.Jr. The Mythical Man-Month. – S.L.: Addison-Wesley, 1975. Русские переводы: Брукс Ф.П.мл. Как проектируются и создаются программные комплексы. (Серия: "Библиотечка программиста"). – М.: Наука, 1979. – 152 с.; СПб.: Символ, 2000. – 298 с.
3. DeMarco T. Controlling Software Projects. – Englewood Cliffs: Prentice Hall, 1982. – 284 p.
4. Humphrey G. Managing the Software Process. – Reading: Addison-Wesley, 1989. – 494 p.
5. Florac W.A., Carlton A.D. Measuring the Software Process. -- Addison-Wesley, 1999
6. Ruskin A.M., Estes W.E. What Every Engineer Should Know about Project Management. – New York: Marcel Dekker, Inc., 1994. – 276 p.
7. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Процесс разработки программных изделий. – М.: Наука, 2000. – 176 с.

Electrical and Electronics Engineers (IEEE)
http://www.acm.org – Association for Computing Machinery (ACM)
http://www.itu.int/ITU-T/ – International Telecommunication Union (ITU)
http://www.w3.org – World Wide Web Consortium (W3C)
http://www.iso.org – International Organization for Standardization (ISO)
http://goststandarts.narod.ru/ – ГОССТАНДАРТ России

есть:
цели
важность для заказчика
элемент уникальности
критерии успешности
сроки
бюджет

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

Line Planning ) phase

Разработка бизнес-примера – Business Case Development Phase

Идея принята Idea Accepted

Концепция принята Concept Accepted

Решение принято Solution Accepted

M-15

M-14

M-13

Планирование портфеля – Portfolio Planning Phase

Портфель принят Portfolio Accepted

Решение закреплено Solution Lockdown

M-12

M-11

Разработка системы и продукта –
SPD ( System & Product Development ) phase

Определение проекта – Project Definition Phase

M-10

M-9

M-8

M-7

Запуск проекта Project Initiation

Системные требования собраны System Requirements Baselined

Системные требования разнесены System Requirements Allocated

Контрактная книга собрана Contract Book Baselined

M-6

M-5

M-4

M-3

Готовность проекта Design Readiness

Готовность к системн.тестир. System Test Readiness

Готов для натурных испытаний Ready for Field Test

Готов для контролируемого ввода в эксплуатацию Ready For Controlled Introduction

Запуск и закрытие – Launch and Closeout Phase

M-2

M-1

M-0

Массовое внедрение Volume Deployment

План вывода утвержден Retirement Plan Approved

Конец жизни End of Life

Реализация – Implementation Phase

M-шлюзы в жизненном цикле разработки

– измеряема
A – achievable – достижима
R – result-focused – нацелена на результат
T – time-framed – к конкретному сроку
ПРИМЕР. Не SMART: перейти на систему Х
SMART: за счет внедрения системы Х к 1 мая
сократить среднее время обслуживания
клиента на 15%

программы ожидаемому по спецификации
Ошибка [причина дефекта] – если дефект найден и его причина (ошибка) выявлена и устранена на той же фазе разработки, где она возникла (затраты на переделки – CPOQ – сравнительно низки)
Дефект – если дефект найден на одной из последующих фаз от места его причины; для ее устранения надо вернуться к фазе, где возникла ошибка, найти и устранить ее там, и повторить весь процесс разработки до места обнаружения, чтобы убедиться, что дефект исчез (затраты на переделки – CPOQ – растут экспоненциально)

исправление ошибки (причины дефекта)

Спецификация требований и проектирование продукта

Разработка кода продукта

Тестирование продукта

Barry Boehm

(R) постоянна и не зависит от объема программного продукта (KLOC)
B) Ошибки не зависят друг от друга

M=KLOC×R ожидаемое число дефектов

Качество: Q=(M−N)/KLOC

N – число найденных дефектов

Время

кода, не содержа-щих дефектов, попадает в интервал ±k сигм относи-тельно его математичес-кого ожидания m

Сигма – это среднеквадратическое отклонение случайной величины – количества дефектов в строках кода – от ее математического ожидания при нормаль-ном распределении

случайной величины xi лежит в интервале

относительно ее математического ожидания

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

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

Заказчик, исполнитель: Возможность вносить изменения!

Начальство исполнителя: Низкая стоимость, занятость людей!

Разработчик: Низкая стоимость, изменения не слишком часто!

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

субъективные – метрики проекта
Сравнивать результаты измерений с ожиданием и анализировать все отклонения от ожидаемых значений
На основании анализа вырабатывать рекомендации по поправочным действиям для данного проекта

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

SQA (Software Quality Assurance) Group
Наглядность представления результатов анализа

организаций и сообществ в промышленности

Lines of Code (KLOC)
Прохождение тестов (%) – Tests Passed
Степень покрытия тестами (%) – Test Coverage
Плотность дефектов (количество выявленных дефектов на 1 KLOC) – Defect Density
Качество кода (количество оставшихся в коде дефектов на 1 KLOC) – Product Quality
Завершенность проекта (% по объему кода или по количеству модулей) – Project Completion

результата от плана) – Schedule Accuracy
Точность поставок (% поставок, сделанных точно в срок, от всех) – On Time Delivery
Затраты на обеспечение качества (% от всех трудозатрат) – Cost of Quality
Затраты на переделки (% от всех трудозатрат) – Cost of Poor Quality
Удовлетворенность заказчика (баллы) – Customer Satisfaction

Jones (2000) Software Assessments, Benchmarks, and Best Practice, Addison-Wesley, p 339, System Software Baseline.
Источник данных по организации SPSD: 2Q’01 9-Up Report.
Преобразование данных: 320 AELOC за 1 функциональный балл.

операторов – число различных операторов языка программирования, включая символы-разделители, имена процедур и знаки операций, встречающихся в тексте программы
η2 – размер словаря операндов – число различных операндов, включая имена переменных и константы, встречающихся в тексте программы
η = η1 + η2 – размер словаря реализации
N1 – общее число всех операторов в программе
N2 – общее число всех операндов в программ
N = N1 + N2 – размер (длина) реализации
N ≈ Ñ = η1 log2 η1 + η2 log2 η2

Maurice Halstead

(control flow graph) с n вершинами, m дугами и p компонентами связности:
λ(G) = m – n + 2×p
Для односвязного графа G управления с n вершинами и m дугами
λ(G) =  m – n + 2
λ(G) – число линейно независимых контуров в сильно связном графе G

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

Владимирович Рабин
Copyright © Баранов С.Н. Рабин А.В., 2014

Тема 1. Введение. Основные понятия
Тема 2. Модели жизненного цикла разработки
Тема 3. Модель CMMI – общая характеристика
Тема 4. Модель CMMI – ключевые области 2-го уровня зрелости
Часть 1 – Планирование и отслеживание
Часть 2 – Требования
Часть 3 – Субподрядчики, конфигурация, качество
Тема 5. Модель CMMI – ключевые области 3-го уровня зрелости
Тема 6. Модель CMMI – ключевые области 4-го и 5-го уровней зрелости
Тема 7. Единый каркас и общие технологические приемы

рабочие продукты
Deliverables

Анализ
Analysis

Проектирование
Design

Реализация
Implementation

Обозрение
Review

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

– project planning
сбор и анализ требований – requirements
на шаге проектирования:
предварительное (высокоуровневое) проектирование – preliminary (high-level) design
подробное (детальное) проектирование – detailed design
на шаге реализации:
кодирование – coding
на шаге обозрения
тестирование – testing

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

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

их к ПО и к аппаратуре
Изготовить план разработки, включая определение поставляемых рабочих продуктов, оценки ресурсов, определение процессов поддержки
Специфицировать – Specify
Точно определить внешние характеристики будущей программы с точки зрения пользователя (напр., через прототипирование и предъявление пользователям)
Провести обзор спецификаций как минимум с участием инженера-проектировщика, основных пользователей и заказчика
Разработать – Develop
Выполнить детальный проект с точки зрения его реализации
Провести обзор детального проекта с участием разработчиков и тестировщиков
Выполнить кодирование этого проекта
Провести обзор кода с участием тех же лиц, что и в обзоре проекта
Скомпилировать программу, выявив синтакс. ошибки, не вскрытые на обзоре кода
Протестировать программу, выявив логич. ошибки, не вскрытые обзором кода
После завершения – Postmortem
Проанализировать проделанную работу, проверив что все плановые поставки завершены, сравнив результаты работ с требованиями пользователя по качеству
Сравнить фактические результаты с первоначальными оценками, объяснив все расхождения

Planning

Отслеживание и управление – Project Monitoring & Control

Управление качеством ПО – Software Quality Management

Проверка корректности и применимости – Verification and Validation

Управление конфигурацией – Configuration Mngmt

Разработка документации – Documentation Development

Concept Exploration

Привязка системы

System Allocation

Требо-вания

Require-ments

Проекти-рование

Design

Реали-зация

Imple-ment

Эксплуатация и поддержка

Уста-новка

Install

Operation & Support

Сопро-вождение

Mainte-nance

Уда-ление

Retire-ment

ЖЦ ПО

Повышение квалификации – Training

Взаимосвязь процессов разных типов

Разработка – Development

Управление – Management

Поддержка – Support

SW LC

сообщество

Разработчики

Проекти-рование

Кодирование

Тестиро-вание

Планиров.
требований

Описание для
пользователя

Построе-ние (через кодогене-рацию)

Трудозатраы

Время

Обычный жизненный цикл

Отчуж-дение

Отчуж-дение

Жизненный цикл быстрой разработки

Трудозатраы

Роль пользователей критична. В обычном ЖЦ большая часть работы – программирование и тестирование. В БРП за счет кодогенерации большая часть работы – планирование и проектирование.

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

Системное
тестирование

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

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

Упор на фазу верификации и валидации в водопадной модели. Не включает управление проектом и другие поддерживающие процессы

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

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

Системное тестирование

Приемочное тестирование готового продукта

Детальн.проект
(шаг 1)

Реализация
(шаг 1)

Сборка и демо
(шаг 1)

Детальн.проект
(шаг N)

Реализация
(шаг N)

Сборка и демо
(шаг N)

…..

…..

…..

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

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

Снижаются затраты на достижение начальной

след.
уровня

Оценить альтернативы,
выявить и решить риски

Планы по
треб.и ЖЦ

Концеп-ция

План разработки

Сборка и

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

АР

АР

Анализ

рисков

Анализ рисков

П1

П2

Прототип
3

Дейст-вующий

прототип

Суммарная

стоимость

Треб.
к ПО

Проверка
треб.

Проект
продукта

Проверка
проекта

Детальн.
проект

Коди-
ров.

Мод.
тестир.

Сбор-ка и тестир.

Реа-лиз.

Прием. тестир.

Также помогает выявлять ключевые риски в программной разработке

Разделение обязательств

поль-
зователей

Настрой-
ка

Подход состоит в построении «быстрой» частичной реализации системы до или во время фазы сбора требований

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

Затем по этим отзывам изменяются спецификации требований, чтобы отразить реальные потребности.

некоторая – ресурсы нельзя оценить или они недоступны; высокая – ресурсы можно определить и они доступны
Сложность проекта: низкая – все критерии сложности низкие; средняя – критерии сложности смешаны: 1-2 высокие, 1-2 низкие; высокая – все критерии сложности высокие
Стоимость приложения: низкая – оценка меньше некоторой суммы; средняя – оценка равна этой сумме; высокая – оценка больше этой суммы
Стоимость будущих обновлений: низкая – оценка меньше некоторой суммы; высокая – оценка стоимости больше этой суммы
Дискретное изменений требований: малое – задевает не более 5 интерфейсов и включает не более 10 процессов; большое – задевает более 5 интерфейсов и включает более 10 процессов
Легкость в использовании: просто – фазы и поставки понятны, процесс сфокусирован на разработку, а не на поддерживающие процессы; сложно – поддерживающие процессы требуют управления, наряду с разработкой
Функциональные потребности приложения: смутные – трудно определимые; разработчики формулируют их сами; специфицированные – хорошо определены, если они измеряемы и тестируемы
Постепенное изменение требований: малое – задевают небольшой объем системы; большое – требуют пересмотра большого числа интерфейсов
Время жизни приложения: краткое – краткосрочное решение, например, на несколько дней; среднее – от 3 до 5 лет; долгое – более 5 лет

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

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

Владимирович Рабин
Copyright © Баранов С.Н. Рабин А.В., 2014

Тема 1. Введение. Основные понятия
Тема 2. Модели жизненного цикла разработки
Тема 3. Модель CMMI – общая характеристика
Тема 4. Модель CMMI – ключевые области 2-го уровня зрелости
Часть 1 – Планирование и отслеживание
Часть 2 – Требования
Часть 3 – Субподрядчики, конфигурация, качество
Тема 5. Модель CMMI – ключевые области 3-го уровня зрелости
Тема 6. Модель CMMI – ключевые области 4-го и 5-го уровней зрелости
Тема 7. Единый каркас и общие технологические приемы

государственным финансированием из бюджета США при университете Карнеги-Меллон (г.Питтсбург)
Ориентирован на нужды Минобороны США
Объединил ученых и практиков в области разработки программного обеспечения

Стратегическая цель: обеспечить ведущие позиции организациям США в технологии программирования для улучшения качества систем, зависящих от программного обеспечения

http://www.sei.cmu.edu

модели:
Paulk M.C., Curtis B., Chrissis M.B., Weber Ch.V. Capability Maturity Model for Software, Version 1.1.
CMU/SEI-93-TR-24;
ESC-TR-93-177.
Key Practices of the Capability Maturity Model

(EIA/IS 731)

IPD-CMM*

SSE-CMM

ISO 15288*

DOD IPPD

IFIPD Guide

ISO 11011

Q9000

TickIT

ISO 15504* (SPICE)

Baldrige

TriThorm

DO 178B

MIL-STD- 498

MIL-Q- 9858

DOD-STD- 2168

MIL-STD- 1679

DOD-STD- 2167A

DOD-STD- 7935A

NATO ACAP1,4,9

BS 5750

EQA

ISO/IEC 12207

IEEE 1074

IEEE/EIA 12207

EIA/ IEEE J-STD-016

IEEE Standards 730,828,829, 830,1012,1016, 1028,1058,1063

SCE

SDCCR

Team
Improving processes for developing better products and services
(Улучшение процессов для разработки лучших продуктов и услуг)
Ноябрь 2010 г.
CMU/SEI-2010-TR-033
ESC-TR-2010-033

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

Инструментальные средства и оборудование

Процесс

CMM V1.1 (1995)

INCOSE Systems Engineering Capability Assessment Model (1996)

Software CMM V2 draft C (1997)

EIA 731 Software Engineering Capability Model (1998)

Integrated Product Development CMM (1997)

Software Acquisition CMM V1.03 (2002)

CMMI for Acquisition V1.2 (2007)

CMMI for Services V1.2 (2009)

CMMI for Acquisition V1.3 (2010)

CMMI for Development V1.3 (2010)

CMMI for Services V1.3 (2010)

CMMI for Development V1.2 (2006)

INCOSE – International Council on Systems Engineering
EIA – Electronic Industries Alliance

разрешение причин
CM – Configuration Management – управление конфигурацией
DAR – Decision Analysis and Resolution – анализ и принятие решений
IPM – Integrated Project Management – интегрированное управление проектом
MA – Measurement and Analysis – измерение и анализ
OPD – Organizational Process Definition – определение процесса организации
OPF – Organizational Process Focus – нацеленность процесса организации
OPM – Organizational Process Management – управление процессом организации
OPP – Organizational Process Performance – исполнение процесса организации
OT – Organizational Training – обучение в организации (повышение квалифик.)
PI – Product Integration – интеграция продукта

PMC – Project Monitoring and Control – наблюдение за процессом и контроль
PP – Project Planning – планирование в проекте
PPQA – Process and Product Quality Assurance – обеспечение качества в процессе и продукте
QPM – Quantitative Project Management – количественное управление проектом
RD – Requirements Development – разработка требований
REQM – Requirements Management – управление требованиями
RSKM – Risk Management – управление рисками
SAM – Supplier Agreement Management – управление договорами с поставщиками
TS – Technical Solution – техническое решение
VAL – Validation – валидация
VER – Verification – верификация

Процессная область

Notes – Описывают главные концепции данной процессной области
Related Process Areas – Ссылки на про-цессные области, связанные с данной
Example Work Product – примеры результатов, получаемых в конкретной специфической практике

Заявление о назначении

Вводные замечания

Примеры рабочих продуктов

Смежные процессные области

цели

Специфические цели

Общие цели

Специфические цели

Специ-фические практики

Общие практики

Специ-фические практики

Общие практики

Уровни способности

Уровни зрелости

Непрерывное представление Continuous representation

Стадийное представление Staged representation

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

областям процесса достигается уровень 1 – процессы в этих областях просто исполняются
Достигается уровень 2 – создаются политика, требующая исполнения этих областей, и планы их исполнения; выделя-ются необходимые ресурсы, распределяются ответственнос-ти, обеспечивается необходимое обучение, ведется конт-роль рабочих продуктов – процесс планируется и отслежива-ется, как и все проекты или деятельности по его поддержке
Достигается уровень 3 – в организации устанавливается стандартный процесс в данных областях, который может подгоняться под требования конкретного проекта. Процессы в проектах более согласованы и устойчивы, поскольку строятся на базе стандартных процессов организации.
Выбираются следующие области, например, CAR и OPM, и процесс повторяется

(ad hoc), в организации нет устойчивой среды для их поддержки; успех зависит от компетенции и героических усилий людей, а не от использования проверенных процессов; бюджет и график обычно превышают начальные оценки
2 – управляемый – процессы в проектах планируются и исполняются в соответствии с политикой даже в ситуациях стресса. Процессы управляются в соответствии с задокументированными планами. Состояние проекта видимо для руководства в определенных точках (по завершении основных этапов). Обязательства всех прикосновенных лиц устанавливаются и пересматриваются по мере необходимости. Рабочие продукты контролируются надлежащим образом и отвечают своим описаниям, стандартам и процедурам

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

Process Definition – определение процесса организации – 3
OPF – Organizational Process Focus – нацеленность процесса организации – 3
OT – Organizational Training – обучение в организации – 3
OPP – Organizational Process Performance – исполнение процесса организации – 4
OPM – Organizational Process Management – управление процессом организации – 5
Управление проектом:
PMC – Project Monitoring and Control – наблюдение за проектом и его контролирование – 2
PP – Project Planning – планирование в проекте – 2
REQM – Requirements Management – управление требованиями – 2
SAM – Supplier Agreement Management – управление договорами с поставщиками – 2
IPM – Integrated Project Management – интегрированное управление проектом – 3
RSKM – Risk Management – управление рисками – 3
QPM – Quantitative Project Management – количественное управление проектом – 4
Инженерные:
PI – Product Integration – интеграция продукта – 3
RD – Requirements Development – разработка требований – 3
TS – Technical Solution – техническое решение – 3
VAL – Validation – валидация – 3
VER – Verification – верификация – 3

Управление проектом

Управление процессом

Инженерная

– Measurement and Analysis – измерение и анализ – 2
PPQA – Process and Product Quality Assurance – обеспечение качества в процессе и продукте – 2
DAR – Decision Analysis and Resolution – анализ и принятие решений – 3
CAR – Causal Analysis and Resolution – анализ и разрешение причин – 5

Поддержка

2 должны достичь уровня способностей 1 или 2
Для уровня 3 – все 7+11=18 процессных областей уровней 2 и 3 должны достичь уровня способностей 3
Для уровня 4 – все 7+11+2=20 процессных областей уровней 2, 3 и 4 должны достичь уровня способностей 3
Для уровня 5 – все 7+11+2+2=22 процессные области должны достичь уровней 2, 3, 4 и 5 способностей 3

по верификации
Выходные данные
Критерии на выходе

GG1 – исполняемый процесс – выполняется работа, необходимая для достижения специфических целей данной процессной области
GG2 – управляемый процесс – это исполняемый процесс, планируемый и исполняемый по политике и в соответствии с его описанием
GG3 – определенный процесс – это управляемый процесс, который задает для своих подпроцессов:

Выполнять специфические практики для достижения специфических целей данной процессной области

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

GG – Generic Goal GP – Generic Practice

Устанавливать и поддерживать политику организации для планирования и исполнения процесса
GP2.2 Устанавливать и поддерживать план по исполнению процесса
GP2.3 Обеспечивать адекватные ресурсы для исполнения процесса, разработки его рабочих продуктов и предоставления его услуг
GP2.4 Распределять ответственности и полномочия для исполнения процесса, разработки его рабочих продуктов и предоставления его услуг
GP2.5 Проводить переподготовку людей, исполняющих или поддерживающих процесс по мере необходимости
GP2.6 Контролировать выбранные рабочие продукты процесса по соответствующим уровням контроля

Процесс реализуется и воплощается как управляемый

GG – Generic Goal GP – Generic Practice

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

Процесс реализуется и воплощается как управляемый

GG – Generic Goal GP – Generic Practice

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

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

GG – Generic Goal GP – Generic Practice

Владимирович Рабин
Copyright © Баранов С.Н. Рабин А.В., 2014

Тема 1. Введение. Основные понятия
Тема 2. Модели жизненного цикла разработки
Тема 3. Модель CMMI – общая характеристика
Тема 4. Модель CMMI – ключевые области 2-го уровня зрелости
Часть 1 – Планирование и отслеживание проекта
Часть 2 – Сбор и анализ требований
Тема 5. Модель CMMI – ключевые области 3-го уровня зрелости
Тема 6. Модель CMMI – ключевые области 4-го и 5-го уровней зрелости

планы, определяющие проектные деятельности
SG1 – Создаются и поддерживаются оценки параметров проектного плана
SP1.1 Устанавливать высокоуровневую структуру разбиения работ для оценки области приложения проекта
SP1.2 Устанавливать и поддерживать оценки атрибутов рабочих продуктов и задач
SP1.3 Определять фазы жизненного цикла проекта, куда вкладываются запланированные трудозатраты
SP1.4 Оценивать трудозатраты и стоимость рабочих продуктов и задач с обоснованием оценок

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

проектный план как основа для управления проектом
SP2.1 Устанавливать и поддерживать бюджет и график проекта
SP2.2 Выявлять и анализировать проектные риски
SP2.3 Планировать управление данными проекта
SP2.4 Планировать ресурсы для исполнения проекта
SP2.5 Планировать знания и умения, необходимые для исполнения проекта
SP2.6 Планировать вовлечение выявленных прикосновенных лиц
SP2.7 Устанавливать и поддерживать общий проектный план

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

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

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

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

типа проектов:
Органический: маленькая команда с опытом и нежесткими требованиями
Полуразделенный: средний размер команды, смешанные опыт и требования
Встроенный: много жестких требований
Трудоемкость = ab(KLOC)**bb [человеко-месяцев]
Срок разработки = cb(Трудоемкость)**db [месяцев]
Число разработчиков = Трудоемкость/ Срок разработки [человек]

2

http://csse.usc.edu/tools/COCOMOII.php

Входные данные по предполагаемому размеру кода:

– получение продукта с нуля Inception – начальная фаза, запуск проекта Elaboration – уточнение и проработка ТЗ Construction – собственно создание продукта Transition – переход продукта к заказчику

уточнение и проработка ТЗ

Construction – собственно создание продукта

Transition – переход продукта к заказчику

– масштабирующий мно-житель, зависящий от Size):

2.По исторической БД проектов находим B(Size) в n точках и затем определяем productivity:

3.По уже известным теперь B и productivity определяем Effort:

2006 г.) наблюдений по 7000 законченных проектов

переиспользуемого кода
D – staffing complexity – скорость добавления персонала
Ctech – effective technology – действенность технологии

обеспечивать понимание продвижения проекта для принятия поправочных мер в случае существенного отклонения хода проекта от плана
SG1 – Ведется наблюдение за фактическим продвижением проекта и его исполнением в сравнении с проектным планом
SP1.1 Вести наблюдение за фактическими значениями параметров проектного плана в сравнении с плановыми
SP1.2 Вести наблюдение за обязательствами в сравнении с проектным планом
SP1.3 Вести наблюдения за рисками в сравнении с проектным планом
SP1.4 Вести наблюдение за управлением проектными данными в сравнении с проектным планом
SP1.5 Вести наблюдение за вовлеченностью прикосновенных лиц в сравнении с проектным планом
SP1.6 Регулярно проводить обзоры продвижения, исполнения и проблем проекта
SP1.7 Проводить обзоры достижений и результатов проекта на выбранных этапах проекта

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

– Ведется управление поправочными действиями до их завершения в тех случаях, когда исполнение или результаты проекта существенно отклоняются от плана
SP2.1 Собирать и анализировать проблемы и определять в отношении их необходимые поправочные действия
SP2.2 Предпринимать поправочные действия в отношении выявленных проблем
SP3.3 Управлять поправочными действиями до их завершения

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

новом оборудовании и ПО
3. Цикл заказчика по обзору/утверждению документов дольше, чем предполагалось

9

10

Аннотация:. Проект – часть программы Телематика и входит как подпроект в проект заказчика по переносу программного приложения GM/UA1 (Gen5) на новую платформу (Gen6). Задача проекта – разработка драйверов для высокоуровневого программного обеспечения TCU.

8

Начало: 14-мар-ХХ Окончание: 31-дек-ХХ Продукт: Услуга:

ЗАКАЗЧИК: <Организация или лицо> Контактное лицо из руководства: <ФИО> <эл.почта>, <тел.> Контактное лицо по техническим вопросам: <ФИО> <эл.почта>, <тел.>

ТЕХНОЛОГИИ/ИНСТРУМЕНТЫ: • Wireless communication • CDMA • RTXC RTOS • MGT5100 platform • CAN, GMLAN, Class2

АППАРАТНЫЕ РЕСУРСЫ: Сервера: Персональные компьютеры: 10 Платы: Другое:

ПРОЕКТНАЯ ГРУППА: Руководитель: <ФИО> Отв.разработчик: <ФИО> Рук.тестирования: <ФИО>, 0.5 Разработчик: <ФИО> Разработчик: <ФИО> Разработчик: <ФИО> Разработчик: <ФИО> Разработчик: <ФИО> Тестировщик: <ФИО> Инж.по качеству: <ФИО>, 0.5

ЦЕЛИ: 1. Удовлетворение заказчика не менее, чем на 7.0 баллов из 10 2. COQ – 27.4%
3. COPQ – 4.8%
4. Качество 5.1 sigma
5. Экономия на автоматизации - $K 6. <…> - <…>

Экран проекта <проект> на <дата>

software sample – инженерный образец ПО
RP – release product – окончательный релиз продукта

3>: …
<Риск 4>: …

…

<список деятельностей/состояние>
Отложенные поправочные действия: <список>

у заказчика
Поставка требований

Замечания по состоянию каждой метрики
Отклонение от плана: <факт/цель>
Анализ: <проведен «дата»/планируется «дата»>
Причины: <список>
Поправочные действия: <список деятельностей/состояние>
Отложенные поправочные действия: <список>

следованию графику

Total Quality Gate Effectiveness, Major Fault Containment Analysis
1.

Schedule Accuracy Analysis
1.

Нужны пояснения!!!

Security defects:

% Security faults:

phase is completed.
CR Average age is not meeting its goal due to high complexity of features.

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

Владимирович Рабин
Copyright © Баранов С.Н. Рабин А.В., 2014

Тема 1. Введение. Основные понятия
Тема 2. Модели жизненного цикла разработки
Тема 3. Модель CMMI – общая характеристика
Тема 4. Модель CMMI – ключевые области 2-го уровня зрелости
Часть 1 – Планирование и отслеживание проекта
Часть 2 – Сбор и анализ требований
Тема 5. Модель CMMI – ключевые области 3-го уровня зрелости
Тема 6. Модель CMMI – ключевые области 4-го и 5-го уровней зрелости

их компонентам и обеспечивать соответствие между этими требованиями, с одной стороны, и проектными планами и рабочими продуктами, с другой стороны
SG1 – Ведется управление требованиями и выявление их несогласованностей с проектными планами и рабочими продуктами
SP1.1 Развивать понимание с поставщиками требований об их смысле
SP1.2 Получать обязательства по требованиям от участников проекта
SP1.3 Управлять изменениями требований по мере их возникновения в ходе проекта
SP1.4 Поддерживать отслеживаемость между требованиями и рабочими продуктами в обе стороны
SP1.5 Обеспечивать пребывание проектных планов и рабочих продуктов в соответствии с требованиями

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

в течение практически всего жизненного цикла проекта

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

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

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

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

функциональности в формулировке требований: наличие глагола в положительной или отрицательной форме
Функциональность документируется через перекрестную верификационную матрицу
Примеры функциональности в требованиях:
Продукт должен обеспечивать напряжение 220 вольт на выходном разъеме
Продукт должен обеспечивать передачу стандартных контейнеров
Продукт должен отображать свое состояние оператору

в формулировке требований: наличие прилагательных или наречий и измеряемость ответами на вопросы: сколько? как часто? и т.п.
Атрибутивность документируется через таблицу описания атрибутов
Примеры атрибутивности в требованиях:
Дружественный по отношению к пользователю
Легко продаваемый
Сильный
Нетоксичный
Переносимый

несколько независимых кандидатов на отдельные требования
Элементарность
Ясное, точное, тестируемое и однозначное
Условность
Имеет другие (выводимые) требования как необходимые предусловия
Выводимость
Выведено как необходимое предусловие для другого требования

символов 6×9 пикселей
Условность
Обратная совместимость с версией 2.1
Выводимость
Продукт должен использовать интерфейс XYZ (потому что его использует версия 2.1)

быть высоко функциональной
Р-связь должна отвечать спецификациям ST152D и ST204D
Тестовое оборудование должно быть совместимо по шине
Устройство должно быть совместимо с RS232
Должен применяться короткий производственный цикл
Каждый экран должен отображать номер и дату заказа
Установка должна завершаться за 45 минут
Плотность дефектов должна быть меньше 5,7 сигма
Соединение должно быть через болт диаметром 6 типа А
Надпись «M&M» должна быть красного цвета №2
Дата должна быть в стандартном формате

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

Обычные инструменты анализа – стандартные формы, таблицы, карточки требований и т.д. – и 4 шага: 1) форматирование; 2) группирование; 3) приоритизация; 4) выбор

кандидата
Дата возникновения – дата, когда данный кандидат был создан
Категория – используется для группировки требований
Приоритет – используется для указания важности кандидата
Статус – положение кандидата (напр.: активный, выбран, отложен, пересмотрен)
Описание – формулировка кандидата в требования

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

конкурентов
Доступность ресурсов

Учесть прежний опыт и знания
Установить тип продукта:
Совершенно новый
Зрелый
Собрать документацию по проекту:
Область и размер проекта
Сложность проекта
Обновить стандартный формат кандидатов

степени реализованности данного требования в продукте – функция от рейтинга заказчика
Удовлетворитель (Satisfier) – то, что было явно затребовано заказчиком; если этого нет, то заказчик будет очевидным образом недоволен
Разочарователь (Dissatisfier) – если этого нет или уровень реализации недостаточен, то заказчик будет разочарован; но он не будет особенно доволен, если уровень реализации достаточен
Восторгатель (Delighter) – заказчик этого не ожидал, но будет приятно удивлен наличием этого свойства в продукте

20 до 60 миль в час – заказчик будет недоволен, если разгоняется вяло, но будет рад, если разгоняется живо
Разочарователь (Dissatisfier) – если автомобиль глохнет в луже, то заказчик с дождливым климатом будет серьезно недоволен, но не будет кричать от радости, если не глохнет, принимая это как должное
Восторгатель (Delighter) – заказчик из города с густыми туманами придет в восторг от радара, сообщающего о других автомобилях на его пути, но не будет разочарован отсутствием такого радара

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

Требования в окончательном документе должны удовлетворять ряду критериев

особенностей, возможностей, ограничений и других свойств целевой системы
Тестируемость – testability – требование должно быть сформулировано так, чтобы его можно было протестировать (напр., нетестируемое: «система должна отвечать на запрос в разумное время»; тестируемое: «система должна отвечать на любой запрос в течение 10 секунд»)
Согласованность – consistency – согласованное использование терминов для избегания конфликта в определениях
Краткость – conciseness – вся дополнительная информация (история проекта, стоимости, график и т.д.) содержится в других документах
Читаемость – readability – документ легко читается и понимается однозначно
Отслеживаемость – traceability – система нумерации для проверки того, что все требования, на которые есть ссылки, учтены в проекте и коде
Реализуемость – feasibility – повторное обоснование достаточности инструментов, методик, штата и бюджета для реализации требований
Изменяемость – changeability – способность принимать изменения в процессе исполнения проекта

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

можно использовать следующие 3 слайда)
Отыскать в тексте требований все места неоднозначности
Переписать эти места так, чтобы устранить неоднозначности

provide the following capabilities:
Management applications to monitor, diagnose, and correct network faults. Real-time monitoring of network nodes requires standard topology and fault management functions, and a state-of-the-art user interface design to support those applications for very large networks
Network data whether dynamic (e.g., events, status) or relatively static (e.g., configuration), must be stored in a flexible data base at the management system. This information must be employed by all management applications in an intelligent fashion, and must be available to standard PC, workstation, and/or mainframe reporting system
As much integration of data bases and applications as possible should be provided, but not at the expense of time to market. At a minimum, a window between the systems must be provided, and data bases which are not consolidated should be compatible; i.e., share a common format or the ability to export to a common format
The system will be based on a new management hardware and software platform. As such, it must be designed to support any network devices that will be integrated beyond the system’s nodes
The system will be the only tool with the ability to test, check status, reconfigure, and gather statistics on the networks in real time. Therefore, these management applications are a critical element of the system
The system must be able to accept inventory, configuration, and performance data from other systems since these systems are targeted to provide the nodal and network optimization functions. In addition, the system must be able to provide this information to these same systems to re-optimize the network or validate hypotheses

the system must:
Prioritize graphical application implementations over text-based displays wherever possible and appropriate. A particular example is selecting a physical or logical component below the node level in order to perform a snapshot, create a trouble ticket, run a test, etc.; the operator should be able to click on the component (or representation) rather than typing in component identifiers
Window multiple active applications simultaneously, without restrictions; any performance issues relative to multiple applications must be clearly documented for uses
Support active applications as icons; i.e., running without an active window
Support cut and paste between all management applications; e.g., the ability to paste test results, event text, snapshot data, or configuration information into a trouble ticket
Synchronize real-time data between applications; i.e., if multiple status windows are active simultaneously, a parameter of status change in one window will be immediately updated in all other windows
Update all windows while displayed, even though only one window will accept user input
Allow simultaneous access to any and all system capabilities for multiple operators at one or many locations

the system must:
Minimize the use of «locking » features, which restrict multiple operators from using the same applications
Support an optional text-entry interface with scripting and programming capability
Demonstrate a common look and feel for all funcions without the use of text-based files
Provide a customer-usable audit trial of all operator actions, with the option to save and view multiple session files; the trial must not be limited to disruptive operations, but rather must contain a listing of all operator activity
«Tutor mode» with simulation
Provide status of ongoing actions and background tasks such as downloads, uploads, and archives
Multiple device actions (views, aggregates, and multiple mouse selections); use for event logs and queries, tests on multiple devices, stats collection setups, trouble tickets, extraction filters, etc.
Support customization where possible (help text, event text, tags and priorities, icons, screens, etc.)

Владимирович Рабин
Copyright © Баранов С.Н. Рабин А.В., 2014

Тема 1. Введение. Основные понятия
Тема 2. Модели жизненного цикла разработки
Тема 3. Модель CMMI – общая характеристика
Тема 4. Модель CMMI – ключевые области 2-го уровня зрелости
Часть 1 – Планирование и отслеживание
Часть 2 – Требования
Часть 3 – Субподрядчики, конфигурация, качество
Тема 5. Модель CMMI – ключевые области 3-го уровня зрелости
Тема 6. Модель CMMI – ключевые области 4-го и 5-го уровней зрелости
Тема 7. Единый каркас и общие технологические приемы

и услуг от поставщиков
SG1 – Создаются и поддерживаются соглашения с поставщиками
SP1.1 Определять тип приобретения для каждого приобретаемого продукта или компонента*
SP1.2 Выбирать поставщиков путем оценивания их способности удовлетворить заказанные требования и установленные критерии*
SP1.3 Создать и поддерживать соглашения с поставщиками
SG2 –Соглашения с поставщиками выполняются как проектом, так и поставщиком
SP2.1 Исполнять деятельности с поставщиком, как указано в договоре
SP2.2 Убеждаться в выполнении условий договора до приемки приобретаемого продукта
SP2.3 Обеспечивать передачу приобретенных у поставщика продуктов

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

рабочих продуктов, используя конфигурационную идентификацию, конфигурационный контроль, отчетность по состоянию конфигурации и аудиты конфигурации
SG1 – Создаются базовые версии определенных рабочих продуктов
SP1.1 Выявлять элементы конфигурации, компоненты и связанные с ними рабочие продукты, помещаемые под конфигурационное управление
SP1.2 Создавать и поддерживать конфигурационное управление и систему управления изменениями для контроля рабочих продуктов
SP1.3 Создавать и(или) выпускать базовые версии для внутреннего использования и для поставок заказчику

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Поддержка

изменения в рабочих продуктах, входящих в конфигурацию
SP2.1 Отслеживать запросы на изменения для элементов конфигурации
SP2.2 Контролировать изменения в элементах конфигурации
SG3 – Устанавливается и поддерживается целостность базовых версий
SP3.1 Создавать поддерживать записи об элементах конфигурации
SP3.2 Проводить аудиты конфигурации для поддержания целостности базовых версий конфигураций

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Поддержка

документа
Золотое правило: Невозможно поддерживать полную тождественность никаких двух отдельных экземпляров одного и того же документа
Ведение записей по управлению конфигураций
Каждое предложение по изменениям должно пройти утверждение до своей реализации
Все предложения, разрешенные и отклоненные изменения регистрируются;
Идентификация конфигураций
Правила именования составляющих компонентов в проекте
Каждый элемент разработки получает свое уникальное имя

способность измерять для поддержки потребностей в управленческой информации
SG1 – Цели и деятельности по измерениям выстраиваются в соответствии с выявленными информационными целями и потребностями
SP1.1 Устанавливать и поддерживать цели измерений, выведенные из выявленных информационных целей и потребностей*
SP1.2 Специфицировать метрики, отвечающие целям измерений*
SP1.3 Специфицировать процедуры сбора и хранения данных
SP1.4 Специфицировать способы сообщения данных измерений и результатов их анализа

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Поддержка

измерений, отвечающих выявленными информационным потребностям и целям
SP2.1 Ведется сбор специфицированных данных измерений
SP2.2 Выполняется анализ и интерпретация данных измерений
SP2.3 Ведется управление и хранение данных измерений, спецификаций измерений и результатов их анализа
SP2.4 Результаты деятельностей по измерениям и анализу сообщаются всем значимым прикосновенным лицам

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Поддержка

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

Метрики должны быть:

defect containment effectiveness
эффективность отсеивания дефектов – defect screening effectiveness
себестоимость программной разработки – cost of SW development
Продукта – для улучшения программного продукта
размер исходного кода
сложность проекта
объем разработанной документации
Проекта – для улучшения данного проекта
количество разработчиков и тестировщиков
методы и инструменты, используемые в разработке
область приложений

Три типа метрик:

руководство объективным пониманием процессов и их рабочих продуктов
SG1 – Ведется объективное оценивание соответствия исполняемых процессов и их рабочих продуктов описаниям процесса, стандартам и процедурам
SP1.1 Объективно оценивать выбранные исполняемые процессы на их соответствие описаниям процесса, стандартам и процедурам
SP1.2 Объективно оценивать выбранные рабочие продукты на их соответствие описаниям процесса, стандартам и процедурам
SG2 – Проблемы несоответствия объективно отслеживаются и сообщаются, и обеспечивается их разрешение
SP2.1 Сообщать о проблемах с качеством штату и руководству и обеспечивать разрешение ими проблем несоответствия
SP2.2 Устанавливать и поддерживать ведение записей о деятельностях по обеспечению качества

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Поддержка

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

Владимирович Рабин
Copyright © Баранов С.Н. Рабин А.В., 2014

Тема 1. Введение. Основные понятия
Тема 2. Модели жизненного цикла разработки
Тема 3. Модель CMMI – общая характеристика
Тема 4. Модель CMMI – ключевые области 2-го уровня зрелости
Тема 5. Модель CMMI – ключевые области 3-го уровня зрелости
Тема 6. Модель CMMI – ключевые области 4-го и 5-го уровней зрелости

набор процессных активов организации, стандартов рабочей среды, правил и руководств для команд разработчиков
SG1 – Создается и поддерживается набор процессных активов организации
SP1.1 Создавать и поддерживать набор стандартных процессов организации
SP1.2 Создавать и поддерживать описания моделей жизненного цикла, утвержденных к использованию в данной организации
SP1.3 Создавать критерии и руководства по подгонке процессов
SP1.4 Создавать и поддерживать в организации хранилище для данных измерений
SP1.5 Создавать и поддерживать библиотеку процессных активов организации
SP1.6 Создавать и поддерживать стандарты рабочей среды
SP1.7 Создавать и поддерживать правила и руководства организации по структуре, формированию и деятельности команд разработчиков

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление процессом

и внедрять улучшения процесса организации через глубокое понимание текущих сильных и слабых сторон процессов и процессных активов организации
SG1 – Периодически и по мере необходимости выявляются сильные и слабые стороны организации и возможности для улучшения
SP1.1 Создавать и поддерживать описание потребностей и целей процесса для организации
SP1.2 Периодически и по мере необходимости оценивать процессы организации для поддержания понимания их сильных и слабых сторон
SP1.3 Выявлять возможности для улучшения процессов и процессных активов организации

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление процессом

деятельности по улучшению процессов и процессных активов организации планируются и реализуются
SP2.1 Создавать и поддерживать процессные планы действий по улучшению процессов и процессных активов организации
SP2.2 Реализовывать процессные планы действий
SG3 – Процессные активы организации внедряются по всей организации и процессный опыт включается в процессные активы организации
SP3.1 Внедрять процессные активы организации по всей организации
SP3.2 Внедрять набор стандартных процессов организации в проекты при их запуске и внедрять в них подходящие изменения в течение всего жизненного цикла каждого проекта
SP3.3 Вести наблюдение за реализацией набора стандартных процессов организации и использованием процессных активов во всех проектах
SP3.4 Включать процессный опыт, полученный при планировании и исполнении процессов, в процессные активы организации

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление процессом

так, чтобы они могли выполнять свои роли результативно и экономно
SG1 – В организации создается и поддерживается механизм обучения, поддерживающий должностные обязанности в данной организации
SP1.1 Создавать и поддерживать в организации перечень стратегических потребностей в обучении
SP1.2 Определять, какие потребности в обучении являются ответственностью организации, а какие относятся к отдельным проектам или группе поддержки
SP1.3 Создавать и поддерживать тактический план организации по обучению
SP1.4 Создавать и поддерживать механизм обучения для потребностей организации по обучению
SG2 – Предоставляется обучение отдельным лицам для того, чтобы они выполняли свои должностные обязанности результативно
SP2.1 Предоставлять обучение в соответствии с тактическим планом организации
SP2.2 Создавать и поддерживать записи об обучении в организации
SP2.3 Оценивать результативность программы обучения в организации

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление процессом

и вовлечение в него значимых прикосновенных лиц и управлять проектом и этими лицами в соответствии с интегрирован-ным и определенным процессом, полученным подгонкой из набора стандартных процессов организации
SG1 – Вести проект, используя определенный процесс, полученный подгонкой из набора стандартных процессов организации
SP1.1 Создавать и поддерживать определенный процесс проекта от начала проекта в течение всего жизненного цикла проекта
SP1.2 Использовать процессные активы организации и хранилище данных измерений для расчетов и планирования деятельностей в проекте
SP1.3 Создавать и поддерживать рабочую среду проекта на основе стандартов рабочей среды организации
SP1.4 Интегрировать проектный план и другие планы, влияющие на проект, для описания определенного процесса проекта
SP1.5 Управлять проектом, используя проектный план, другие планы, влияющие на проект, и определенный процесс проекта
SP1.6 Создавать и поддерживать команды разработчиков
SP1.7 Вносить процессный опыт в процессные активы организации

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

координация и сотрудничество между проектом и значимыми прикосновенными лицами
SP2.1 Управлять вовлечением в проект значимых прикосновенных лиц
SP2.2 Участвовать вместе со значимыми прикосновенными лицами в выявлении, обсуждении и отслеживании критических зависимостей
SP2.3 Разрешать проблемы со значимыми прикосновенными лицами

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

прежде их появления, чтобы можно было планировать и исполнять деятельности по рискам по мере необходимости в течение всего жизненного цикла продукта или проекта для смягчения неблагоприятных воздействий на достижение целей
SG1 – Проводится подготовка к управлению рисками
SP1.1 Определять источники и категории рисков
SP1.2 Определять параметры, используемые для анализа и категоризации рисков, и контролировать трудозатраты на управление рисками
SP1.3 Устанавливать и поддерживать стратегию, используемую для управления рисками

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

и анализ рисков для определения их относительной важности
SP2.1 Выявлять и документировать риски
SP2.2 Оценивать и присваивать категорию каждому выявленному риску, используя определенные категории и параметры рисков, и определять их относительные приоритеты
SP2.3 Устанавливать и поддерживать стратегию, используемую для управления рисками
SG3 – Проводится работа с рисками и их смягчение, смотря по обстоятельства, для снижения неблагоприятных воздействий на достижение целей
SP3.1 Разработать план смягчения рисков в соответствии со стратегией управления рисками
SP3.2 Регулярно вести наблюдение за состоянием каждого риска и реализовывать план смягчения рисков, смотря по обстоятельствам

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

устанавливать требования заказчика, продукта и его компонентов
SG1 – Потребности, ожидания, ограничения и интерфейсы прикосновенных лиц собираются и переводятся в требования заказчика
SP1.1 Выявлять потребности, ожидания, ограничения и интерфейсы прикосновенных лиц для всех фаз жизненного цикла продукта
SP1.2 Преобразовать потребности, ожидания, ограничения и интерфейсы прикосновенных лиц в требования заказчика и дать им приоритеты
SG2 – Требования заказчика уточняются и разрабатываются для создания требований к продукту и его компонентам
SP2.1 Создавать и поддерживать требования к продукту и его компонентам, основанные на требованиях заказчика
SP2.2 Приписать требования к каждому компоненту продукта
SP2.3 Выявить требования к интерфейсам

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Инженерная

и проверяются на пригодность
SP3.1 Создавать и поддерживать концепции работы продукта и соответствующие им сценарии
SP3.2 Создавать и поддерживать определение требуемой функциональности и атрибутов качества
SP3.3 Анализировать требования на необходимость и достаточность
SP3.4 Анализировать требования для достижения баланса потребностей прикосновенных лиц с ограничениями
SP3.5 Проводить проверку пригодности требований, чтобы увериться, что конечный продукт будет работать в среде конечного пользователя так, как предполагается

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Инженерная

реализовать решения для требований; решения, проекты и реализации касаются продуктов, их компонентов и процессов их жизненного цикла по отдельности или в сочетании, смотря по обстановке
SG1 – решения для продукта и его компонентов выбираются из альтернативных решений
SP1.1 Разрабатывать альтернативные решения и критерии выбора
SP1.2 Выбирать решения для компонентов продукта на основе критериев выбора

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Инженерная

продукта и его компонентов
SP2.1 Разрабатывать проект для продукта или его компонента
SP2.2 Создавать и поддерживать пакет технических данных
SP2.3 Спроектировать интерфейсы компонентов продукта, используя установленные критерии
SP2.4 На основе установленных критериев проводить расчеты, следует ли разрабатывать компоненты продукта или приобретать их, или повторно использовать
SG3 – компоненты продукта и документация к ним создаются исходя из их проектов
SP3.1 Реализовывать проекты компонентов продукта
SP3.2 Разрабатывать и поддерживать документацию для конечного пользователя

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Инженерная

его компонентов, убедиться, что собранный продукт функционирует правильно (т.е., имеет требуемую функциональность и атрибуты качества) и доставить продукт
SG1 – проводится подготовка к интеграции продукта
SP1.1 Создавать и поддерживать стратегию интеграции продукта
SP1.2 Создавать и поддерживать среду, необходимую для поддержки интеграции компонентов продукта
SP1.3 Создавать и поддерживать процедуры и критерии для интеграции компонентов продукта

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Инженерная

продукта, как внутренние, так и внешние, совместимы
SP2.1 Проводить обзоры описаний интерфейсов на покрытие и полноту
SP2.2 Управлять определениями внутренних и внешних интерфейсов, проектами и изменениями в продукте и его компонентах
SG3 – верифицированные компоненты продукта собираются и интегрированный, верифицированный и проверенный на пригодность продукт доставляется
SP3.1 Подтверждать до сборки, что каждый компонент продукта, требующийся для сборки продукта, был надлежащим образом идентифицирован, работает в соответствии со своим описанием, и что интерфейсы компонентов продукта соответствуют их описаниям
SP3.2 Проводить сборку из компонентов продукта в соответствии со стратегией и процедурами интеграции продукта
SP3.3 Оценивать собранные компоненты продукта на совместимость интерфейсов
SP3.4 Упаковывать собранный продукт или его компоненты и доставлять их заказчику

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Инженерная

продукты отвечают своим специфицированным требованиям
SG1 – проводится подготовка к верификации
SP1.1 Выбирать рабочие продукты для верификации и используемые методы верификации
SP1.2 Создавать и поддерживать среду, необходимую для осуществления верификации
SP1.3 Создавать и поддерживать процедуры и критерии верификации для выбранных рабочих продуктов
SG2 – для выбранных рабочих продуктов проводятся товарищеские обзоры
SP2.1 Подготавливаться для товарищеских обзоров по выбранным рабочим продуктам
SP2.2 Проводить товарищеские обзоры выбранных рабочих продуктов и выявлять проблемы в результате этих обзоров
SP2.3 Анализировать данные по подготовке, проведению и результатам товарищеских обзоров

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Инженерная

верифицируются по своим специфицированным требованиям
SP3.1 Выполнять верификацию по выбранным рабочим продуктам
SP3.2 Анализировать результаты всех деятельностей по верификации

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Инженерная

компонент работает, как предполагается, когда он помещен в соответствующую среду
SG1 – проводится подготовка к валидации
SP1.1 Выбирать продукты и их компоненты для валидации и используемые методы валидации
SP1.2 Создавать и поддерживать среду, необходимую для осуществления валидации
SP1.3 Создавать и поддерживать процедуры и критерии для валидации
SG2 – продукт или его компоненты проверяются на пригодность к использованию в предполагаемой операционной среде
SP2.1 Проводить валидацию выбранных продуктов и их компонентов
SP2.2 Анализировать результаты деятельностей по валидации

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Инженерная

используя формальный процесс оценивания, который оценивает выявленные альтернативы по установленным критериям
SG1 – решения основаны на оценивании альтернатив, используя установленные критерии
SP1.1 Создавать и поддерживать руководства по определению, какие проблемы подлежат процессу формального оценивания
SP1.2 Создавать и поддерживать оценочные критерии для альтернатив и относительную значимость этих критериев
SP1.3 Выявлять альтернативные решения для проблем
SP1.4 Выбирать методы оценивания
SP1.5 Оценивать альтернативные решения, используя установленные критерии и методы
SP1.6 Выбирать решения из альтернатив на основе оценочных критериев

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Инженерная

Владимирович Рабин
Copyright © Баранов С.Н. Рабин А.В., 2014

Тема 1. Введение. Основные понятия
Тема 2. Модели жизненного цикла разработки
Тема 3. Модель CMMI – общая характеристика
Тема 4. Модель CMMI – ключевые области 2-го уровня зрелости
Тема 5. Модель CMMI – ключевые области 3-го уровня зрелости
Тема 6. Модель CMMI – ключевые области 4-го и 5-го уровней зрелости

понимание хода выбранных процессов из набора стандартных процессов организации для поддержки целей по качеству и исполнению процессов и для обеспечения данных по ним, базовым версиям и моделям в целях количественного управления проектами организации
SG1 – устанавливаются и поддерживаются базовые версии и модели, описывающие ожидаемый ход процессов из набора стандартных процессов организации
SP1.1 Создавать и поддерживать количественные цели организации по качеству и исполнению процессов, отслеживаемые к бизнес-целям организации
SP1.2 Выбирать процессы и подпроцессы из набора стандартных процессов организации для включения в анализ исполнения процессов организации и поддерживать их отслеживаемость к бизнес-целям организации
SP1.3 Создавать и поддерживать определения метрик, включаемых в анализ исполнения процессов организации
SP1.4 Анализировать исполнение выбранных процессов, создавать и поддерживать базовые версии исполнения процессов
SP1.5 Создавать и поддерживать модели исполнения процессов для набора стандартных процессов организации

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление процессом

достижения установленных целей проекта по качеству и исполнению процессов
SG1 – проводится подготовка к количественному управлению
SP1.1 Создавать и поддерживать цели проекта по качеству и исполнению процессов
SP1.2 Используя статистические и количественные методы, составлять определенный процесс, обеспечивающий проекту достижение его целей по качеству и исполнению процессов
SP1.3 Выбирать подпроцессы и атрибуты, критичные для оценивания исполнения, и способствующие достижению целей проекта по качеству и исполнению процессов
SP1.4 Выбирать метрики и аналитические методы для применения в количественном управлении
SG2 – проект управляется количественно
SP2.1 Вести наблюдение за исполнением выбранных подпроцессов, используя статистические и другие количественные методы
SP2.2 Управлять проектом, используя статистические и другие количественные методы для определения, будут ли достигнуты цели проекта по качеству и исполнению процессов
SP2.3 Выполнять анализ причин выбранных проблем для устранения недостатков в достижении целей проекта по качеству и исполнению процессов

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление проектом

исполнением процессов организации для достижения ее бизнес-целей
SG1 – исполнение производственных процессов организации управляется, используя статистические и другие количественные методы для понимания недостатков в исполнении процессов и для выявления областей для их улучшения
SP1.1 Поддерживать бизнес-цели на основе понимания стратегий бизнеса и фактических результатов исполнения процессов
SP1.2 Анализировать данные по исполнению процессов для определения способности организации достичь выявленных бизнес-целей
SP1.3 Выявлять потенциальные области для улучшения, которые могут способствовать достижению бизнес-целей

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление процессом

проактивно выявляются, оцениваются с применением статистических и других количественных методов и выбираются для внедрения на основе их вклада в достижение целей по качеству и исполнению процессов
SP2.1 Выявлять предлагаемые улучшения и давать им категории
SP2.2 Анализировать предлагаемые улучшения на их возможное воздействие на достижение целей организации по качеству и исполнению процессов
SP2.3 Проводить валидацию выбранных улучшений
SP2.4 Выбирать и реализовывать улучшения для внедрения по всей организации на основе оценивания затрат, выгод и других факторов
SG3 – измеряемые улучшения процессов и технологий организации внедряются и оцениваются, используя статистические и другие количественные методы
SP3.1 Создавать и поддерживать планы по внедрению выбранных улучшений
SP3.2 Управлять внедрением выбранных улучшений
SP3.3 Оценивать эффект внедренных улучшений на качество и исполнение процессов, используя статистические и другие количественные методы

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Управление процессом

результатов и предпринимать действия по улучшению исполнения процессов
SG1 – глубинные причины выбранных результатов систематически выявляются
SP1.1 Выбирать результаты для анализа
SP1.2 Выполнять анализ причин выбранных результатов и предлагать действия для их устранения
SG2 – глубинные причины выбранных результатов систематически рассматриваются
SP2.1 Реализовывать выбранные предложения, разработанные в ходе анализа причин
SP2.2 Оценивать эффект реализованных действий по исполнению процесса
SP2.3 Вести записи по анализу причин и данных по разрешению для использования в проектах и организации

ML– Maturity Level SG – Specific Goal SP – Specific Practice

Поддержка

effectus

Следствие – Effect

Причина – Cause

Проблема

Оборудование

Процесс

Персонал

Управление

Среда

Материалы

Первичная причина

Вторичная причина

по затратам/преимуществам отсутствуют или непонятны

Не поддерживается историческая БД

Люди

Нет обучения по ролям и проведению инспекций

Принимающие решения не видят результатов

Успехи не сообщаются

Вводные

Нет четких целей

Нет целей по повышению качества

Методы

Нет стандартов

Процесс инспекций не определен

- ОК

Коллеги по работе - OK

Наставники - ОК

Процесс обучения

Личное

Прочтения материалов недостаточно

Незадавание вопросов по изученному материалу

Отсутствие четкой отчетности о продвижении по активностям с привязкой ко времени

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

Не задаю вопросы, типа «правильно ли я понял, что...»

Слишком самоуверен; не проверяю понимание самоконтролем или объясняя, что понял, кому-либо

Рассмотрение проблемы - Fishbone

внутри и вовне

Планирование Ad Hoc – плани-рование разными группами плат-форм и продуктов без полного согласования между собой
Увязание в переговорах – Трата времени на переговоры в цикле выпуска продукта
Растрата ресурсов – 50% заяв-ленной функциональности не созда-ется, многое пересоздается заново

Ответственны все – Разные груп-пы платформ и продуктов принима-ют решения независимо друг от друга

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

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

AI Progress

Distribution of DP AI by DP Activity

audits: ,
Delayed AF Status:
- : ,
- …
AF Status:
- Backlog: ,

Comments required!!!

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

д.т.н. Сергей Николаевич Баранов,
Доц., к.т.н. Алексей Владимирович Рабин
Copyright © Баранов С.Н. Рабин А.В., 2014

Тема 1. Основные понятия
Тема 2. Методы анализа данных и представления его результатов
Тема 3. Сводка о проекте и предотвращение дефектов
Тема 4. Инструменты стратегического планирования

стратегию

Скоммуници-ровать и исполнять

1 2 3 4

Пред-план

Анализ окружения

Разработка стратегического плана

1 2 3

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

Сбалансированный экран результативности организации – Organization Balanced Scorecard

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

Измерение производительности

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

Экран результативности как инструмент

ВЗГЛЯД НАЗАД НА ПЛАНЫ ПРОШЛЫХ ЛЕТ И ИХ ИСПОЛНЕНИЕ
ВЗГЛЯД ВОКРУГ НА КОНКУРЕНТНОЕ ОКРУЖЕНИЕ
ВЗЛЯД ВПЕРЕД НА ОЖИДАЕМЫЕ ИЗМЕНЕНИЯ НА РЫНКЕ
“В чем проблемы? Что надо сделать?”
ИНИЦИАТИВЫ Программы текущего года, которые приведут к достижению стратегических целей
“Что будем делать в этом году?”
БИЗНЕС-РЕЗУЛЬТАТЫ Конкретные, измеряемые результаты, достижения которых ожидаем; они напрямую переходят в критерии ежегодного премиального поощрения “Как узнать, что стратегии, цели и инициативы работают?”
ПРОЦЕСС ОБНОВЛЕНИЯ Оценивание сильных сторон наших бизнес-процессов; выявление базовых компетенций, требующих развития или улучшения чтобы обеспечить нашу продолжающуюся конкурентоспособность
“Будем ли мы в состоянии поддерживать и постоянно улучшать нашу производительность?”

Определения и термины

НАПРАВЛЕНИЕ

ИЗМЕРЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ

Ключевые бизнес-процессы

Бизнес-результаты текущего года

Лидерство

Заказчики и рынок

Специальные для подразделений

Финансы

Управление процессом

Стратегическое планирование

Кадры

__________
__________
__________
__________

Видение
Миссия
Культура

Каркас для стратегии

Software Products, and Systems Solutions to customers worldwide
Be the world’s best software provider leading the communications industry in technology and innovation
Миссия – Mission
Enable software as a competitive advantage to deliver solutions and superb commercial value to our customers

inclusive environment based on:
The Highest Principles and Team Spirit
Creativity and Learning
Winning and Can-do attitude
Technical, Business, and Entrepreneurial IQ
Risk taking and Courage to make the tough calls
Transparent and sustaining communication
Partnership based approach working with business teams promoting one goal

руководство и условия труда
Winning Financials – делать упор на усиление баланса и оборота
Winning with Customers – неустанно добиваться конкурентных преимуществ по затратам, качеству и удовлетворенности заказчика
Winning Innovations – расти через инновационные продукты, системы, ПО и отношения с заказчиками
Winning Strategies – постоянно оценивать и улучшать наши стратегии бизнеса и портфель продуктов/заказов
Отрывные (Breakaway) и обязательные (Make or Break)

и будущих руководителей
Вырастить двух новых руководителей группы
Ежеквартально проводить общие собрания с высшим руководством
Стратегическое планирование
Разработать и поддерживать технологическую дорожную карту организации
Нарастить экспертизу по <предметная область>

сокращения затрат за счет переиспользования компонентов
Выйти на соответствие стандартам TL9000 / ISO9000-2001
Реализовать инициативы по безопасному программированию
Ввести систему самоаудита для процедур внутреннего контроля

с исходным
Добиться 80% роста оборота, по сравнению с предыдущим годом
Получить 2 млн руб. прибыли за счет стимулирования инноваций

Business Results

Leadership

Customer and Market

Business Specific

Financial

Version 1.0

February 10, 2006

Global Software Group

Networks
On time delivery of CDMA R18 and R19; Deliver a Low-Tier O&M solution for WiMax
Mobile Devices
Software for Moto Q Phone
Component Technologies for P2K, Linux / Java, iDEN & CDMA phones
Government & Enterprise
Enterprise solutions (security/VoIP), VoIP Phone/SIP client
SW for TETRA and DoITT Broadband
Connected Home
Presentation engine for ICEbox client ported with Opera browser and QTe
IPR Portfolio & Standards
40 GSG Filings + 40 BU Pursues,1 leadership role in a standard, 3 external publications
Software Technology Groups
Provide agreed TG deliverables to Businesses

Process Management

Strategic Planning

Human Resources

Meet operational cost goals at each Site
GSG Organizational Performance to Plan

2006 Scorecard

Achieve high derived Feedback Scores on Key (High-Importance) Factors in the Business Partner Feedback Surveys
On-time delivery for all GSG programs
Establish baselines and track relevant measures of end-customer defects
Align with business partners to lower end-user defects and increase productivity

Recruit, develop, and retain staff, including diverse talent
Perform rigorous successor planning
Transform GSG per Software Task Force
Meet the goals of the software task force on a quarterly basis
Strengthen the GSG org structure to optimize for TG execution
Align Scorecards and PM dialogs/evaluations

Drive the Quality IQ program into GSG and work with corporate Quality to develop SW BB capabilities across GSG and Motorola

Drive the 2006 asset management and reuse initiative and achieve 10% cost saving due to reuse
Drive the 2006 security initiative
Reduce the mean and variation of GSG project COQ and COPQ by reducing the COQ in continued projects against baselines from previous releases and achieving planned COQ levels for new projects
Increase the number of new GSG sites operating at CMMI Maturity Level 5 or compatible with TL9000 / ISO9000-2001, while maintaining current levels, based on the Motorola recertification rules, at other sites
Defined data from all GSG projects is included in the central metrics data warehouse and available in a dashboard
Drive the increased use of code and test automation in each Division
Drive use of IPMS above the “basic” level, while maintaining full use of EPMS
Implement effective tools to improve business, portfolio, and resource planning
Update and audit GSG policies

Create and deploy technology competency strategies and roadmaps (TGs, Div, Sites)
Establish a strategy & plan for geographically locating TGs, COEs, and projects
Continue to build momentum and meet Seamless Mobility Architecture targets and deliverables approved by the GTC
Gain agreement for TG roadmaps from BU’s

Blue – changes in this version

Discover & Create
Create new competencies to increase value to Motorola and our customers
Identify and nurture Centers of Technological Excellence globally
Build broader skill sets in critical areas
Connect & Drive
Architectural leadership of Seamless Mobility
Align Technology Group Roadmaps with Seamless Mobility Architecture
Align Technology Group Roadmaps with Corporate Platf. reduction goals
Identify key assets and common components for Technology Groups
Cross Business Forums for Collaboration, Value Creation and Consensus building
Software & Technology Incubation & acceleration
Protect & Promote
Technology licensing into ecosystems, partnerships and investments
Software licensing into ecosystems, partnerships and investments
Develop explicit program to accelerate adoption of key software assets into multiple business unit applications;
Promote reuse of strategic assets and architectures
Operational Excellence
Doing more with less (e.g., components, platforms, common architectures, automation)
Manage initial Technology Group Seed funding efficiently and effectively
Process & organizational improvement

Vision
Be the world’s best software provider leading the communications industry in technology and innovation
Mission
Enable software as a competitive advantage for Motorola to deliver Seamless Mobility solutions, superb commercial value and technological innovation to our consumer, government, and enterprise customers
Culture
Model a stimulating, diverse, and inclusive environment based on:
The Highest Principles, Team spirit and Climate of Collaboration
Creativity and Learning
Winning and Can-do attitude
Technical, Business and Entrepreneurial IQ
Risk taking and Courage to make the tough calls
Transparent and sustaining communication
Partnership based approach working with business teams promoting one Motorola goal

Strategy Framework
Build the next generation internet around the enablement of seamless mobility: Discover and Create disruptions by helping accelerate adoption of lab technologies; Connect and Drive competencies internally leveraging existing assets; Protect and Promote thought leadership externally by direct customer engagement; Deliver through Operational Excellence building on our legacy

группы
План развития
Деятельности по саморазвитию
Сформулировать 1-5 деятельностей по собственному развитию
Повышение квалификации
План по дополнительному обучению и переподготовке
Ожидания карьерного роста

Вам организации-разработчика программного обеспечения
Спроецировать экран результативности на личный план известного Вам инженера-разработчика (например, на себя)

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

Shelf

Asset Inventory
From all BUs

T3 DEMO with ESA

DRM Xlator,
SSL/VPN,
Motowallet

NFC SDK

Motowallet

Unified Threat Mgt Appliance
For Converged/Wireless/Mobility

POC Phase 1
Std UTM

POC Phase 2
W/M UTM

Security Products

NAC

DRM Fmwk
& Translator

UTM
Product

Security Plan & Collateral

2006 Motorola
Security Plan

Security
Summit

Whitepaper

Whitepaper

Architecture

Spec
Rev 1

Spec
Rev 2

Spec
Rev 3

Spec
V1 Final

Strategy presentation

Whitepaper

S

S

S

S

Reusable
Components

S

S

S

A

A

S

S

S

S

S

S

Reusable
Components

S

Reusable
Components

S

Training

Training

Training

A

A

A

A

A

A

A

A

A

A

A

A

1.0 (Release at Jun. 21, 2002)
(QT)

ADE Version 1.5 (Release at Dec. 11,2003)

ADE Version 2.0 (Release at Dec. 31,2004)

0.2

1.0

1.5

2.0

Version

Year

ADE Version 1.1 (Release at Nov. 21, 2002)
(QT/P2K)

ADE Version 1.2 (Release at March. 21, 2002)
(QT/iDEN)

ADE Version 1.3 (Release at July. 31, 2002)
(QT, iDEN,KJava)