- •Содержание
- •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.Указатель
Примерная форма еженедельного отчета
Обычно еженедельный отчет о ходе проекта (project weekly status report) составляется каждым участником проекта и рассылается по электронной почте в установленный день, например, среда до конца рабочего дня (в исключительных случаях – на следующий день до начала рабочего дня) по установленному списку адресатов. В этот список, как правило, входят руководитель проекта, непосредственный руководитель, коллеги автора по проекту, заказчик, представитель группы качества. В поле такого «Тема» электронного письма указывается акроним проекта и «Еженедельный отчет» и дата отчета. Привычный шрифт текста – Ариэль, длина строки не должны превышать 65 символов, общая длина отчета – 1 или 1,5 страницы.
<Уровень секретности>
<Название подразделения>
<Акроним проекта> Еженедельный отчет о ходе проекта <должность> <ФИО>
<Дата отчета в формате дд-МММ-гггг>
----------------------------------------------------------------------------------------------------------------------------
Приветствуются любые замечания, вопросы, проблемы или действия.
** Красные флажки – проблемы
·····
** Главные проблемы заказчика
·····
** Новости продукта
·····
** «Разведка донесла»
·····
** Прочее
·····
ОБЗОР ПРОДУКТА:
<описание>
НОВЫЕ ПРОБЛЕМЫ и МЕРЫ ПО НИМ:
1) Проблема: …
Флажок: <красный/желтый>
Области воздействия и последствия: <описание>
Предложенные действия: <описание>
2) ...
НОВЫЕ РИСКИ И УПРАВЛЕНИЕ РИСКАМИ:
1) РИСК: <описание>
Серьезность риска: <высокая/средняя/низкая>
Триггер: <событие и его срок>
Действие: <описание>
2) ...
СВОДКА О ПРОДВИЖЕНИИ В ПРОЕКТЕ:
<описание>
СОСТОЯНИЕ ГЛАВНЫХ ЭТАПОВ (только жесткие этапы, не более 20):
Описание Срок : Фактич.
---------------------------------------------------------------------- ----------------------
1) <описание> <дата>:<дата>
2) …
СОСТОЯНИЕ ГРАФИКА РАБОТ: <+/–> <количество дней>
ПОПРАВОЧНЫЕ ДЕЙСТВИЯ ПО СНИЖЕНИЮ ОТСТАВАНИЯ:
<описание>
ОБЕСПЕЧЕННОСТЬ КАДРАМИ:
По плану: <количество человек>
По факту: <количество человек>
В стандартной «шапке» отчета указывается уровень секретности данного документа (например, «Только для внутреннего использования в данной организации»), название подразделения, акроним проекта, должность и имя автора и дата составления отчета. В качестве напоминания всем читателям отчета в шапке стоит стандартная фраза: «Приветствуются любые замечания, вопросы, проблемы или действия» (Any comments, questions, issues, or action items would be appreciated).
Далее перечисляются так называемые «красные флажки» (red flags) – проблемы в проекте, с которыми автор не может справиться самостоятельно в пределах выделенных ему ресурсов, и ему нужна помощь или иная форма поддержки.
Затем указываются известные автору главные проблемы на стороне заказчика, которые могут повлиять на ход проекта, новости, имеющие отношение к разрабатываемому продукту, которые появились на прошедшей неделе, и некоторая информация, представляющая интерес для проекта или всей организации в целом.
В разделе «ОБЗОР ПРОДУКТА» (PRODUCT OVERVIEW) приводится аннотация разрабатываемого программного продукта и его краткий обзор – обычно 1-2 абзаца, которые, как правило, не меняются в течение всей разработки.
В следующем разделе «НОВЫЕ ПРОБЛЕМЫ и МЕРЫ ПО НИМ» (NEW ISSUES and ISSUE MANAGEMENT) перечисляются выявленные ранее риски, которые за истекшую неделю стали проблемами, и новые проблемы, возникшие в течение этой недели: название проблемы, последствия, области воздействия, воздействие на будущие этапы проекта и предложенные действия для «красных проблем».
В разделе «НОВЫЕ РИСКИ и УПРАВЛЕНИЕ РИСКАМИ» (NEW RISKS and RISK MANAGEMENT) указывается название нового риска, выявленного в течение истекшей недели, ожидаемое время наступления этого риска, области его воздействия, триггер и действия в случае срабатывания триггера для рисков, имеющих серьезность «высокая».
В разделе «СВОДКА О ПРОДВИЖЕНИИ В ПРОЕКТЕ» (SUMMARY OF PROGRESS) кратко перечисляются достижения автора в проекте за истекшую неделю.
В следующей таблице «СОСТОЯНИЕ ГЛАВНЫХ ЭТАПОВ» (KEY MILESTONE STATUS) перечисляются основные этапы проекта, по аналогии с «жестким реальным временем», называемые «жесткими», т.е., срок которых не может быть изменен, и к которым в той или иной степени имеет отношение автор отчета.
В позиции «СОСТОЯНИЕ ГРАФИКА РАБОТ» (SCHEDULE STATUS) указывается максимальное отставание от графика из числа текущих заданий и работ по проекту, за которые отвечает автор; если же все работы выполнены в срок или с опережением графика, то указывается минимальное из всех опережение. Данные указываются в календарных днях или неделях со знаком «+» для опережения или «–» для отставания. Если работы идут строго по графику, то обычно пишут «ОК». При наличии отставания, в следующем разделе «ПОПРАВОЧНЫЕ ДЕЙСТВИЯ ПО СНИЖЕНИЮ ОТСТАВАНИЯ» (CORRECTIVE ACTIONS TAKEN FOR SLIPPAGE) перечисляются меры, которые автор принимает для снижения или преодоления этого отставания (включая пересмотр графика работ).
Раздел «ОБЕСПЕЧЕННОСТЬ КАДРАМИ» (STAFFING) присутствует в отчетах руководителя проекта или какой-либо группы сотрудников, в нем указывается количество сотрудников по плану (Estimated) и по факту (Actual), которые планировались к работам по проекту и фактически участвовали в них в течение прошедшей недели.