Тема10(ФормирСтандПроцесса)-К
.pdfФормирование стандартизированного процесса
1.Набор персонала (как правило, на конкурсной основе)
2.Отбор членов общей команды проекта (Project Team) и общее обучение
3.Создание команд (Project Groups) проекта и распределение ответственности
4.Оценка потенциальных возможностей участников проекта
5.Оценка производительности команды в целом и отдельных участников
6.Взаимодействие и общение на уровне групп и команды в целом
30
Формирование стандартизированного процесса
7.Целевое обучение проектных команд для получения оптимальных результатов
8.Эффективное представление и использование навыков
9.Успешное ведение переговоров с внешними и внутренними участниками проекта, совместные обсуждения и оценки
10.Организация эффективных встреч для планирования совместных работ
11.Вопросы интеллектуальной индивидуальной и коллективной собственности
31
Формирование стандартизированного процесса
Конфликт из-за интеллектуальной собственности: пример
Федеральный суд США в июле 2009 г. принял решение, согласно которому компания Microsoft обязана выплатить более 290 миллионов долларов в качестве компенсации за умышленное посягатель- ство на патент канадской фирмы i4i.
Фирме i4i принадлежит патент, касающийся использования XML – программного языка, который позволяет форматировать тексты и делает файлы читаемыми для различных программ.
XML – интегральная часть программы Word, разработанной компанией Microsoft и широко использующейся по всему миру.
Отдельно было издано постановление, запрещающее Microsoft продажу или импорт в Соединенные Штаты любого программного обеспечения, которое способно открывать XML-файлы с расширениями .xml, .docx или .docm.
На то, чтобы изъять эти программы из продажи, Microsoft отведено 60 дней,
однако адвокаты компании заявили, что будут обжаловать это постановление суда
32
Формирование стандартизированного процесса
Конфликт из-за интеллектуальной собственности: ещё пример
33
Формирование стандартизированного процесса
Организация управления процессом/проектом
Менеджер проектов |
|
|
Главный системный |
||
разработки ПО |
|
|
архитектор |
||
|
|
|
|
|
|
Руководитель |
|
|
Технологический |
||
команды |
|
|
руководитель |
||
разработчиков |
|
|
разработки |
||
|
|
|
|
|
|
|
|
|
|
|
|
Стандартизированный процесс разработки ПО
34
Формирование стандартизированного процесса
Общие компетенции руководителей
Базовые знания в области разработки ПО
Процесс и жизненные циклы разработки ПО Человеческий фактор при разработке ПО Оценка проекта и планирование Управление требованиями и изменениями Проектирование• ПО Инструментальные средства Управление конфигурацией продукта Организация версионного контроля Оценка качества процессов и продуктов
35
|
|
Формирование стандартизированного процесса |
|
|
Персональные компетенции руководителей |
||
|
• Управление командами разработчиков |
Руководитель |
|
|
• Методы разработки ПО |
||
|
команды |
||
|
• Анализ артефактов ПО |
||
|
• Управление ожиданиями |
разработчиков |
|
|
заинтересованных лиц |
|
|
|
• Разработка требований |
|
|
|
• Мониторинг и контроль проекта |
|
|
|
• Управление рисками |
|
|
|
• Модель процессов• |
MSF на практике |
|
|
• Visual Studio Team System, Team |
|
|
|
Foundation Server |
|
|
|
• Проектирование пользовательских |
|
|
|
интерфейсов |
|
|
|
• Управление временем при разработке |
|
|
|
• Введение в персональную и командную |
|
|
|
разработку (PSP/TSP) |
|
|
36 |
• Взаимодействие с поставщиками ПО |
|
Формирование стандартизированного процесса |
||
Персональные компетенции руководителей |
||
• Управление командами разработчиков |
Технологический |
|
• Архитектура ПО |
||
руководитель |
||
• Конструирование ПО |
||
• Анализ артефактов ПО |
разработки |
|
• Объектно-ориентированный анализ и |
|
|
дизайн |
|
|
• Разработка с использованием |
|
|
коммерческих компонент (COTS) |
|
|
• Компьютерные• сети |
|
|
• Информационная безопасность |
|
|
• Базы данных (углубленный курс) |
|
|
• Системы реального времени |
|
|
• Инженерия систем |
|
|
• Бизнес анализ и моделирование с |
|
|
использованием UML/RUP |
|
|
• Разработка встраиваемого ПО |
|
|
37 |
|
|
Формирование стандартизированного процесса |
|
|
Персональные компетенции руководителей |
|
|
• Модели программных систем |
Менеджер |
|
• Межличностные коммуникации |
|
|
проектов |
|
|
• Организационное поведение |
|
|
• Управление рисками |
разработки ПО |
|
• Построение процесса разработки |
|
|
• Бизнес аспекты разработки ПО |
|
|
• CMM & CMMI для практиков |
|
|
• Управление распределенными командами |
|
|
• Модели ROI для оценки эффективности |
|
|
компаний-разработчиков |
|
|
• Гибкие модели разработки ПО (Agile Tech.) |
|
|
• Группы/офисы по управление разработкой |
|
|
процессов |
|
|
• Управление работой с субподрядчиками |
|
|
(SLA – Service Licence Agreements) |
|
|
• Управление портфелем проектов |
|
38 |
• Управление знаниями |
|
Формирование стандартизированного процесса |
||
Персональные компетенции руководителей |
||
• Эволюция сложных систем (сопровождение |
Главный |
|
системный |
||
ПО, реинжиниринг) |
||
архитектор |
||
• Методы разработки ПО |
||
|
||
• Архитектуры сложных систем |
|
|
• Документирование архитектуры |
|
|
• Управление линейками продуктов |
|
|
• Методы анализа архитектурных компромиссов |
|
|
• Высокопроизводительные вычисления (HPC) |
|
|
• Исследования и публикации по разработке ПО |
|
|
• Управление портфелем проектов |
|
|
• Управление знаниями |
|
|
39 |
|
Формирование стандартизированного процесса |
PRACTICE |
THEORY |
Каким путем? |
40 |
Формирование стандартизированного процесса
|
|
|
|
Marketing |
|
|
|
|
|
|
|
|
|
|
Типичный путь |
|
|
|
|
|
manager |
|
|
|
|
|
|
||||
|
|
|
|
|
|
Logistic |
|
|
|
|
|
|
|
|
|
|
|
|
|
manager |
|
|
|
|
|
|
|
|
|
|
|
|
HR manager |
|
|
|
|
|
|
|
|
Safety manager |
|
реализации |
|||
|
|
|
|
|
|
|
|
|
|
|
manager |
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Security |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
процесса |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Communication |
|
|
|
|
|
|
|||
|
|
|
|
|
|
manager |
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
director |
|
Project |
|
|
разработки ПО |
||
|
|
|
|
|
|
|
|
|
manager |
|
|
||||
|
|
|
|
|
|
|
|
General |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
х |
|
|
|
|
|
|||||||
|
|
|
|
Public |
|
в российской |
|||||||||
|
|
|
|
relation |
|
||||||||||
|
|
|
|
|
|
|
|||||||||
|
Developer |
|
|
|
|
|
компании |
||||||||
|
manager |
|
|||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
QA/QM |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
41
Формирование стандартизированного процесса
А как надо?
42
Формирование стандартизированного процесса
Вот так уже лучше!
43
Формирование стандартизированного процесса
А так совсем хорошо!
44
|
Формирование стандартизированного процесса |
SOFT |
HARD |
WARE |
WARE |
BRAIN |
|
WARE |
|
Company Standard Unified Process (CMM) |
|
45 |
|
Общая схема формирования стандартного процесса разработки ПО в соответствии с требованиями СММ
46
Формирование стандартизированного процесса
Соотношение ширины и глубины требований стандартов
Total
CMM Quality
Maturity Management
Levels
ISO 9001:2000
ISO 12207 |
Manufacturing, |
|
Software materials, services
Корпоративные
стандарты
47
Формирование стандартизированного процесса
Практическая схема реализации
Если исходить из соотношения «трудозатраты / эффективность / результат», то, как показывает практика, наиболее оправданный путь заключается в следующей стратегии (с экономической, методологической и практической точек зрения):
1. Для небольших проектов применять методологию MSF
2. Привести существующие процессы (As Is) в соответствия с требованиями модели ISO 9001:2000 (As To Be)
3. Начать формировать стандартизированный унифицированный процесс в масштабах компании, используя модель SW-CMM
для реинжиниринга и улучшения существующих процессов
4. Проводить аудит и оценку зрелости процесса на базе стандартов
48 ISO 15504 (SPICE) и SEI-CMMI
Формирование стандартизированного процесса
Почему именно такой подход наиболее рационален?
Во-первых, совокупность практик MSF методически очень удобна для организации процесса в небольших,
раздельно работающих группах, так как в нём есть эффективные процедуры для организации планирования,
разработки, тестирования и внедрения программного
продукта.
49
Формирование стандартизированного процесса
Почему именно такой подход наиболее рационален?
Во-вторых, сертификация по модели ISO 9000 наиболее известна в мире и имеет широкое применение. Вследствие этого большинству европейских заказчиков сертификат по модели ISO 9001:2000 будет служить достаточным основанием для начала разговора о возможном сотрудничестве.
Cтандарты ISO серии 9000 признаны в качестве национальных более чем в 100 странах мира – в том числе и в России.
50
Формирование стандартизированного процесса
Почему именно такой подход наиболее рационален?
Во-третьих, затраты компании на привлечение консультантов и аудиторов по моделям ISO 9000 на порядок меньше
стоимости экспертов по модели SEI SW-CMM.
Не существует языкового барьера. Многие ведущие организации, занимающиеся сертификацией по моделям ISO 9000, имеют свои представительства в России (BVQI, DNV, TUV-CERT, LRQA), вследствие чего полностью реализована потребность в русскоязычных аудиторах.
51
Формирование стандартизированного процесса
Почему именно такой подход наиболее рационален?
В-четвертых, внедрив требования модели ISO 9001:2000,
организация на 70-80% закроет требования к процессам второго уровня зрелости, и создаст необходимые предпосылки для внедрения требований третьего и выше уровня зрелости процессов по модели SEI SW-CMM.
И, наконец,, по оценкам экспертов организация зачастую быстрее достигает третьего уровня зрелости процессов по SEI SW-СММ, проходя через сертификацию по ISO 9001:2000,
чем напрямую занимающиеся совершенствованием процессов по СММ, Level 3.
52
Формирование стандартизированного процесса
Соотношение содержания ключевых областей процесса СММ и требований ISO 9000:2000
54
Формирование стандартизированного процесса
Достижение 3-го и 4-го уровней СММ через требования ISO 9000:2000
55
Формирование стандартизированного процесса
Соотношение стандартов СММ и ISO 9000:2000 в удовлетворении требований потребителя
56
Формирование стандартизированного процесса
Установление стандартного процесса разработки ПО в масштабах компании
Цель – формирование качественного процесса и реальное достижение компанией 3-го уровня зрелости в соответствии с требованиями стандарта СММ, последующая сертификация SEI на этот и более высокие уровни.
Задача – создание и установление стандартного процесса организации (СПО) по разработке программного обеспечения, включающего управленческие, производственные и ресурсные составляющие.
Необходимость – компания вышла на уровень работы по проектам, когда установление стандартного процесса разработки ПО стало насущной необходимостью для большей части сотрудников компании.
53
Формирование стандартизированного процесса
Осуществимость – в компании есть необходимые предпосылки достижения поставленной цели:
–накопленные материалы и опыт выполненных проектов;
–зрелые специалисты в области проектирования, специфицирования, разработки и тестирования программного обеспечения;
–сотрудники, прошедшие обучение, в том числе и по стандарту СММ;
–начальные методологические разработки;
–достаточная материально-техническая и инструментальная база (CASE-средства) для проектирования и разработки элементов стандартного процесса.
54
Формирование стандартизированного процесса
Команда – работа выполняется двумя основными группами:
–группой разработки единого процесса, которая формирует элементы СПО, документированные политики в соответствии с требованиями ключевых областей процесса, проводит стандартизацию процесса, разрабатывает методологии его применения, оптимизации и совершенствования;
–группой проектной СММ-поддержки и сопровождения, которая решает вопросы настройки основного процесса на конкретные проекты и их сопровождения в соответствии с требованиями СММ, разрабатывает текущие методологии, проектные метрики и базы данных, пополняет межпроектную БД.
55
Формирование стандартизированного процесса
Группа разработки процесса работает на постоянной основе, состав группы проектного СММ-сопровождения может изменяться в зависимости от требований проекта. Группы работают по согласованным планам, черпая необходимые материалы из текущих проектов.
Проект – разработка и установление СППО является реальным проектом, выполняемым по единому плану работ за запланированный период с использованием запланированных ресурсов.
56