- •Содержание
- •1.13. Задания для самопроверки 59
- •1.17. Задания для самопроверки 88
- •1.19. Задания для самопроверки 108
- •1.23. Задания для самопроверки 116
- •1.27. Задания для самопроверки 125
- •1.37. Задания для самопроверки 144
- •1.48. Задания для самопроверки 159
- •Перечень рисунков
- •Перечень таблиц
- •Введение
- •Принятые сокращения
- •1.Жизненный цикл разработки по
- •Программные проект и его атрибуты
- •Ролевые модели в программном проекте
- •Размер и сложность программного проекта
- •Характеристики программного проекта
- •Качество программного продукта
- •Экран проекта и сводка о подходе
- •Критерий smart для формулирования целей
- •Критерии успешности программного проекта
- •Модели жизненного цикла
- •Водопадная модель
- •Модель быстрой разработки приложения
- •Пошаговая модель
- •Спиральная модель Боэма
- •Прототипная модель
- •Выбор модели жизненного цикла
- •Задания для самопроверки
- •2.Типовой каркас для разработки по
- •Программная разработка
- •Планирование проекта
- •Модель cocomo для оценки трудозатрат в проекте
- •Модель slim для оценки трудозатрат в проекте
- •Разработка спецификации требований
- •Отслеживание и контроль
- •Верификация и валидация
- •Обеспечение качества
- •Конфигурационное управление
- •Метрики
- •Повышение квалификации
- •Задания для самопроверки
- •3. Модели зрелости способностей cmm/cmmi
- •Ключевые области процесса в модели cmm
- •Характеристика уровней зрелости в модели cmm
- •Интегрированная модель зрелости способностей cmmi
- •История возникновения
- •Уровни зрелости и области процесса
- •Уровни способностей процесса в модели cmmi
- •Специальные и общие цели и практики процессных областей
- •Характеристики уровней зрелости в модели cmmi
- •Задания для самопроверки
- •4.Управление рисками в программном проекте
- •Модели esi и pmi управления рисками
- •Выявление рисков
- •Анализ рисков
- •Расстановка приоритетов для рисков
- •Планирование рисков
- •Исполнение ответных стратегий
- •Оценивание результатов исполнение ответных стратегий
- •Документирование действий по рискам
- •Заключительное оценивание рисков
- •Задания для самопроверки
- •5.Стандарты качества iso в применении к по
- •Структура и принципы семейства стандартов iso 9000
- •Модели iso 9000 на базе процессов
- •Самооценивание по ключевым элементам iso 9000
- •Задания для самопроверки
- •6.Формальные методы в разработке по
- •Инструменты формализации и верификации
- •Взаимодействие функциональностей
- •Интегрированная технология анализа и верификации
- •Задания для самопроверки
- •7.Некоторые общие технологические приемы
- •Инспекции по Фейгану
- •Диаграммы Исикавы («рыбий скелет»)
- •Инструменты
- •Swot-анализ
- •Сбалансированный экран результативности
- •Технологическая дорожная карта
- •Метод Дельфи
- •Деревья решений
- •Сравнительное ранжирование
- •Методология подвижного программирования
- •Принципы подвижного программирования
- •Рабочий цикл и роли участников
- •Рабочие документы и обстановка
- •Задания для самопроверки
- •8.Сертификация программного обеспечения в авиации
- •История создания серии документов do-178 и ed-12
- •Уровни программного обеспечения
- •Процессы жизненного цикла по авиационных систем
- •Цели процессных деятельностей
- •Рабочие документы и категории их контроля
- •Процесс планирования по
- •Процессы разработки по
- •Определение требований
- •Проектирование
- •Кодирование
- •Верификация
- •Конфигурационное управление
- •Обеспечение качества
- •Контакт с органом сертификации
- •Выводы и рекомендации
- •Задания для самопроверки
- •9.Задания для самостоятельной работы
- •Темы, связанные с единым каркасом для разработки по
- •Перечень тем
- •Краткое описание каждой темы
- •Тема 2. Программная архитектура базового инструмента для распределенного управления программными проектами
- •Тема 3. Профили типовых рабочих компонентов для разработки приложений
- •Тема 1. Прототип метрической базы данных для управления разработкой приложений
- •Тема 5. Репозиторий повторно используемых компонентов
- •Тема 6. Сквозной пример для единого каркаса разработки приложений
- •Темы, связанные применением формальных методов перечень тем
- •Тема 1. Сравнительный анализ систем верификации
- •Тема 2. Формализация протоколов связи краткое описание каждой темы
- •Тема 1. Сравнительный анализ систем верификации
- •Тема 2. Формализация протоколов связи
- •10.Литература
- •11.Приложения
- •Шаблон для одностраничного экрана проекта
- •Примерная структура положения о работе и тз
- •Примерная форма еженедельного отчета
- •Примерная форма презентации на ежемесячном операционном обзоре
- •12.Указатель
Характеристика уровней зрелости в модели cmm
Чем выше уровень зрелости данной организации в модели CMM, тем выше вероятность успешного завершения программного проекта в срок, с заданным качеством поставляемого продукта и рамках установленного бюджета. Соответственно, тем выше производительность труда разработчиков и качество поставляемого продукта, и ниже себестоимость разработки и риск неуспеха по причинам, в той или иной мере зависящим от разработчика. Эта сравнительная характеристика уровней зрелости представлена на Рис. 22. В столбце «Структура процесса» схематично представлена структура процесса каждого уровня, а в столбце «Вероятность успеха» дан качественный график распределения вероятности успешного завершения проекта в зависимости от времени, причем вертикальная пунктирная линия означает планируемый срок завершения проекта.
Уровень зрелости |
Характерис-тика |
Структура процесса |
Вероятность успеха |
Резуль-таты |
5. Опти-мизиру-ющий – Optimizing |
Процесс улучшения встроен в сам процесс разработки |
|
|
Произ-води-тель-ность
и ка-чест-во |
4. Управ-ляемый – Managed |
Количествен-но / Измеряемый процесс на базе метрик |
|
|
|
3. Опреде-ленный – Defined |
Качественно / Процесс определен и внедрен |
|
|
|
2. Повто-ряемый – Repeatable |
Интуитивно / Процесс пред-сказуем и за-висит от от-дельных лиц |
|
|
|
1. На-чальный – Initial |
Ad hoc / Процесс хаотичный и непредсказу-емый |
|
|
Рис. 22. Характеристика уровней зрелости в модели CMM
На первом (начальном) уровне явного и внятного процесса разработки просто нет, но это не значит, что в процессе первого уровня нельзя сделать хороший проект. Такие проекты были и некоторые из них получили хорошие результаты. Но их беда в том, что они непредсказуемы. До момента, пока проект не закончился, неизвестно, закончится ли он вообще или нет, а когда закончится, только тогда можно будет узнать результат. Поэтому в столбце «Структура процесса» представлено отсутствие явной структуры, а кривая распределения вероятности успеха говорит о том, что огромная часть проектов заканчивается с большим превышением срока или не заканчивается вообще.
Второй (повторяемый) уровень говорит о том, что если исполнитель берется за новый проект, похожий на прежний, то результаты, затраты и сроки окажутся примерно такими же. Отличие второго уровня от первого еще в и том, что на первом уровне процесс вообще не имеет никакой структуры, а на втором он уже структурирован – разделен на фазы и, кроме самого процесса, есть еще и некоторое управление процессом, выделенное отдельной линией, взаимодействующей с собственно разработкой.
Если на втором уровне фазы процесса замкнуты, то на третьем (определенном) уже и они имеют некоторую структуру и управление ими более сложное; оно включает в себя дополнительные элементы, адресующиеся к структурным элементам фаз. Благодаря этому обстоятельству проекты на третьем уровне, как правило, всегда заканчиваются, хотя большинство все же по разным причинам в срок не успевают. Качественное отличие в распределении вероятности успеха на третьем уровне от предыдущего уровня в том, что пик распределения очень близок к планируемому сроку, и практически нет незаконченных проектов.
На четвертом уровне (управляемом) проекты заканчиваются в срок, только есть еще отклонения от цели. Точность планирования зависит от ряда причин, вполне возможно завышение требований или их недооценка. Но зато проекты заканчивается с приемлемым качеством. Как и на предыдущем уровне, внутренние элементы процесса имеют свою структуру, но что важно, управление процессом взаимодействует активно уже и с ними. Если на третьем уровне ведется только наблюдение за фазами разработки и снимаются необходимые метрики процесса для их ретроспективного анализа по окончании проекта, то на четвертом уровне разработчики активно воздействуют на процесс в ходе разработки по результатам регулярного анализа этих метрик.
На пятом (оптимизирующем) уровне пик распределения вероятности очень тонкий, т.е. пятый уровень идеален по части точности планирования. В процесс разработки встроена такая малоизученная вещь, как постоянное самосовершенствование процесса, что схематично представлено в столбце «Структура процесса».
Суммируя все предыдущее, можно сказать, что на первом уровне результат не предсказуем. Разные находки и удачные решения для реализации сделаны только для данного случая – ad hoc. Нет массовости и повторяемости в производстве продукта, нет продуманности: как правило, реализуется первое решение, какое приходит в голову разработчикам. Оно может оказаться удачным для данного случая, но совершенно не годящимся для общего случая. На втором уровне результат предсказуем и имеет место управление процессом. На третьем уровне технология разработки программного продукта и управление существуют, определены и согласованно объединены. На четвертом уровне процесс и продукты, создаваемые в этом процессе, постоянно контролируются измерениями и управляются через эти измерения. Именно поэтому четвертый уровень называется управляемым измерениями, результаты которых регулярно анализируются, по ним предпринимаются определенные управляющие воздействия на сам процесс разработки. Наконец, на пятом уровне имеет место постоянное встроенное и автоматизированное совершенствование процесса разработки.