- •Содержание
- •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.Указатель
Рабочие документы и обстановка
Важным аспектом в подвижном программировании является минимизация документооборота, который, как правило, сводится к следующим документам:
перечень свойств/задач продукта – product backlog;
свойства/задачи для реализации в данном рабочем цикле – sprint backlog;
экран завершенности рабочего цикла – burndown chart;
экран препятствий – impediment backlog.
Эти документы создаются и поддерживаются в самом простом общедоступном формате, например, в виде Excel-таблиц, и регулярно вывешиваются в рабочей комнате для постоянного обозрения всеми членами команды. Примеры приведены на Рис. 57.
|
Рис. 57. Примеры рабочих документов в технологии SCRUM
В перечне свойств/задач продукта (Product Backlog) перечисляются все функциональности, которые могут быть реализованы в данном продукте (столбец “Requirement” – Требование). Для каждого требования указывается его индивидуальный номер (Num), категория (Category), текущее состояние (Status), приоритет (Priority) и оценка трудоемкости его реализации в человеко-часах (Estimate).
В перечне свойств/задач для реализации в данном рабочем цикле (Sprint Backlog) аналогичным образом перечисляются функциональности и задачи, выбранные командой разработчиков для реализации в данном рабочем цикле. В столбце «Описание задачи» (Task Description) стоят их формулировки, в столбцах Originator и Responsible – соответственно, кто является инициатором данной работы и ответственным за ее исполнение, в столбце «Текущее состояние» (Status) – ее текущее состояние (Completed – завершена, Not started – не начата, In progress – в работе).
Следующие 5 столбцов «Hours of work remaining» (Количество оставшихся рабочих человеко-часов) рассчитываются на текущую рабочую недели (5 дней). В каждом столбце с номером дня в текущем рабочем цикле (в данном примере это дни с номерами 6-10) указывается общее число оставшихся человеко-часов работы и их плановое число на выполнение каждой из запланированных работ на данный день. В случае завершенных работ планируется 0 человеко-часов, в остальных случаях – в соответствии с текущим распределением работ, которое может уточняться в зависимости от обстоятельств каждый день на утренних совещаниях. Таким образом, состояние этого перечня обновляется каждый день и вывешивается для всеобщего сведения и стимулирования хода работ в соответствии с принятыми командой разработчиков обязательствами.
Пример экрана завершенности рабочего цикла (Burndown Chart) приведен на Рис. 58. Он показывает расход оставшегося рабочего времени на работы данного цикла.
Рис. 58. Пример экрана завершенности рабочего цикла
Этот экран генерируется автоматически по данным о трудозатратах, сообщаемых всеми участниками разработки. В данном случае видны плоская часть в дни 8 и 9 (отсутствие расхода времени), связанная с выходными и всплеск на день 12, связанный, по-видимому, с работой сверх нормы. Экран завершенности также обновляется ежедневно и служит наглядным стимулом для исполнения запланированных задач в соответствии с плановыми сроками.
Особенностью технологии подвижного программирования является постоянное и тесное общение разработчиков друг с другом и с другими участниками проекта (представителями заказчика). Более результативному общению способствует нетрадиционное размещение разработчиков в одной рабочей комнате (Рис. 59).
|
|
|
|
|
|
|
|
|
|
|
|
Рабочие места |
|
|
|
Рабочие места |
|
|
|
Рабочие места |
Рабочие места |
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
||||
|
|
||||||||||
|
|
|
|
|
|
|
|||||
|
|
||||||||||
|
|
|
|
|
|
|
|
||||
|
|
|
|||||||||
а) Так хуже |
|
б) Так лучше |
Рис. 59. Размещение рабочих мест в общей комнате
При размещении по варианту б) стены остаются свободными для размещения на них экранов завершенности, перечней задач и других данных, отражающих ход проекта, а также для проведения дискуссий «у доски». Кроме того, разработчики видят друг друга и им легче задавать прямые вопросы друг другу по ходу работы.