- •Содержание
- •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.Указатель
Критерий smart для формулирования целей
Формулирование целей (целеполагание) в производственном процессе является очень важным шагом для дальнейшего успеха проекта. Большую проблему в практической работе представляет неумение разработчиков четко формулировать поставленные цели и критерии их достижения в объективно измеряемых показателях.
Для четкого и ясного формулирования цели используется так называемый критерий SMART (англ. – умный, удачный, красивый), представляющий англоязычный акростих (краегранение) из пяти требований к формулировке цели:
Specific – конкретна в своей формулировке;
Measurable – измеряема в каких-либо единицах объективным образом;
Achievable – достижима (реалистична) в данных условиях;
Result-focused – нацелена на ощутимый и очевидный результат;
Time-framed – должна быть достигнута к определенному сроку.
Например, если целью разработки программной системы X является переход организации-заказчика на эту систему, то очевидно несоответствие данной формулировки критерию SMART. Другой формулировкой той же цели, но уже удовлетворяющей критерию SMART, могла бы быть такая: «За счет внедрения системы Х к 1 мая сократить среднее время обслуживания клиента на 15%». В такой формулировке цели видны конкретность (внедрение системы X), ожидаемый результат (сокращение среднего времени обслуживания клиентов) и его объективная измеряемость (15% от известного текущего значения), достижимость (за счет внедрения системы X) и конкретный срок (1 мая).
В искусстве целеполагания применяется иерархия целей: каждая цель может быть рассмотрена как средство для достижения еще более высокой цели. Такая лестница целей, аналогичная иерархии (пирамиде) потребностей по Маслоу (Abraham H. Maslow) [16], помогает лучше оценить и понять место каждой частной цели в общей структуре деятельностей по достижению «главных целей» данного программного проекта.
Критерии успешности программного проекта
Все закончившиеся программные проекты можно разделить на две группы: успешные и неуспешные (неудачные), причем успех или неудача проекта должны быть понятны уже в момент его завершения. Для этого необходимы четкие и объективные критерии успешности, согласованные с заказчиком, поскольку решение об успешности или неудаче проекта в модели «Заказчик-исполнитель» принимается обеими сторонами согласно во время приемки-сдачи программного продукта – в конце заключительного этапа его разработки; в случае их разногласия окончательное решение может быть вынесено незаинтересованной третьей стороной (арбитром), в достаточной степени объективной, на основании представленных документов о проекте, включающих эти самые критерии успешности.
Например, критерий: «Программный продукт поставлен в срок, демонстрирует всю заказанную функциональность и правильность своей работы» не подходит, так как и сроки поставки, и состав функциональности, и правильность работы предполагаются к безусловному выполнению – это обязательства, взятые на себя исполнителем, выполнение которых в полном объеме заказчик принимает как должное. Сами по себе эти требования даже не могут обсуждаться как критерии успешности. Вместе с тем, для заказчика проект может оказаться неудачным даже при полном выполнении всех исходных требований и поставках в срок, так как конечная цель, ради которой проект был запущен, оказалась в конечном итоге не достигнутой. Поэтому указанные положения даже не рассматриваются при формулировании критериев, поскольку любое их нарушение противоречит принятым на себя обязательствам исполнителя.
Следует учитывать, что определение того, достигнута ли конечная цель, как она видится заказчику, может потребовать значительного времени уже после завершения разработки и ряда таких деятельностей как внедрение, обучение персонала, завоевание соответствующей доли рынка и т.д., которые от исполнителя никак не зависят. Поэтому критерии успешности проекта должны располагаться несколько ниже по шкале иерархии целей, чем главная цель заказчика в разработке данного ПО, и в своих определяющих моментах зависеть исключительно от исполнителя.