- •Содержание
- •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.Указатель
Технологическая дорожная карта
Технологическая дорожная карта организации (Technology Roadmap) – это еще один инструмент для стратегического планирования, который требует постоянных усилий по определению направления развития организации в зависимости от меняющихся планов, потребностей рынка, влияния конкуренции, научно-технического прогресса, и стратегических задач развития организации. Как правило, дорожная карта составляется на несколько лет вперед и регулярно (минимум раз в полгода) пересматривается и меняется в соответствии с изменившимися внешними условиями. Различают дорожную карту продукта и дорожную карту организации или ее подразделения. Дорожная карта продукта обычно охватывает срок 1-2 года вперед.
На Рис представлена реальная дорожная карта инструментального средства Klocwork для статического анализа больших объемов кода, разделенная по 4 последовательным кварталам одного года. Строки задают классы функциональности, какую предполагается реализовать в этом продукте, а в столбцах отмечены календарные кварталы.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1QYY |
2QYY |
3QYY |
4QYY |
|
||||
|
Сбор дан-ных |
Дефекты |
Конструктивные модели поиска дефектов |
Проверка дефек-тов, задаваемая пользователем |
|
|
|
|
|
||
|
Выявление типичных шаблонов дефектов |
|
|
|
|
|
|||||
|
Метрики кач-ва |
Стандартные |
Пользовательские |
|
|
|
|
|
|||
|
Архитектура |
Анализ потоков данных |
|
|
|
|
|
||||
|
Ана-лиз |
Понимание |
Процессный срез UML |
Диаграм. классов /компон. UML 2.0 |
Сценарии вариантов использования |
|
|||||
|
Многопроцессный срез C++ |
|
|
|
|
|
|||||
|
Задание правил |
Импорт диаграмм классов UML |
|
|
|
|
|
||||
|
Отчеты |
|
|
|
|
|
|
|
|
|
|
|
Пре-зен-тации |
IDE |
Интеграция с ClearCase |
Интеграция с Telelogic |
|
||||||
|
Web |
Портал Klocwork |
|
|
|
|
|
|
|
||
|
GUI |
|
|
|
|
|
|
|
|
|
|
|
API |
Доступ к контей-нерной модели |
Доступ к диа-граммам классов |
Доступ к про-цессн. срезу |
Доступ к срезу по сценар.исп. |
|
|||||
|
Исх. код |
Языки |
C/C++/Java |
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 51. Пример дорожной карты для программного продукта на 1 год вперед
В первом столбце указаны более крупные области функциональности: сбор данных, анализ, презентация результатов и анализируемый исходный код. В следующем столбце эти области разделены на более частные подобласти. Например, сбор данных разделен на сбор данных по дефектам, метрикам качества и архитектуре анализируемого программного кода. В следующих клетках, относящихся к календарным кварталам, указывается какая именно тема (проект) будет исполняться для реализации данной функциональности.
Например, по разделу «Дефекты» на 1-й квартал запланирована тема «Конструктивные модели поиска дефектов», а на 2-й квартал – тема «Проверка дефектов, задаваемая пользователем». Параллельно с этими двумя работами запланирована тема «Выявление типичных шаблонов дефектов», которая будет продолжаться два квартала.
Зеленый цвет клетки означает, что для данной работы имеются все необходимые условия (бюджет, штат, оборудование, данные и т.д.), а желтый цвет – что не все необходимые условия для выполнения данной работы имеются в наличии, и требуются дополнительные усилия, чтобы данную работу запустить. Красный цвет клетки означает наличие только намерений на выполнение данной работы, не подкрепленный ни обязательствами (commitment to perform), ни необходимыми условиями (ability to perform), и служит сигналом к тому, что эти условия еще надо создать.
Пустые клетки означают отсутствие запланированных работ в указанные кварталы по данной тематике.
На Рис. 52 приведен пример дорожной карты научного подразделения НИИ. В ней выделены 4 направления работ: плановые темы НИИ, инициативные научные исследования, прикладная медицинская тематика и поддерживающие прикладные технологии. В каждой из этих областей затем выделены свои подобласти и по ним спланированы работы или заданы количественные показатели на перспективу.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
XXX4 |
XXX5 |
XXX6 |
XXX7 |
XXX8 |
|
|||||||||
|
По плану НИИ |
План.темы |
1 |
1 |
2 |
2 |
2 |
|
||||||||
|
Гранты |
1 |
1 |
2 |
2 |
2 |
|
|||||||||
|
Прикладн. |
2 |
2 |
2 |
3 |
3 |
|
|||||||||
|
Науч-ные иссле-дова-ния |
СВЧ-тех-нологии |
Исследование нейромеханизмов |
Исследов. физическ. эфф. |
Защита от СВЧ-полей |
|
||||||||||
|
Э/в карди-омиопат. |
Комплексные исследования |
Клинические приложения |
TBD |
TBD |
TBD |
|
|||||||||
|
Медсис-темы ИИ |
Защита канд.диссертациии |
ALTERA |
Прикладной симулятор |
Система управл. |
TBD |
|
|||||||||
|
Телеме-дицина |
Арктические телеконференции |
Консультации через сервер |
Консультации пациентов в Арктике |
TBD |
|
||||||||||
|
Публика-ции |
1 моно-графия |
3 статьи |
6 статей, 1 патент |
5 статей |
5 статей |
5 статей |
|
||||||||
|
Меди-цин-ская тема-тика |
Расшире-ние штата |
TBD |
TBD |
TBD |
TBD |
TBD |
|
||||||||
|
Сотрудни-чество |
СПбГУ |
3 партнера |
1 заруб.партнер |
TBD |
|
|
|||||||||
|
Скрининг диагност. |
Разработка программ и систем |
Внедрение |
Эксплуа-тация |
Эксплуа-тация |
Эксплуатация |
|
|||||||||
|
Обслед. больных |
500 |
500 |
500 |
500 |
500 |
|
|||||||||
|
Наполн.БД "Клиника" |
5000 |
5500 |
6000 |
6500 |
7000 |
|
|||||||||
|
Приклад-ные тех-нологии |
Разв. комп.базы |
12 |
2 |
2 |
2 |
2 |
|
||||||||
|
Website |
Англоязычный сайт |
Обновление сервера |
|
|
|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 52. Пример дорожной карты лаборатории НИИ на 5 лет
Как видим, часть работ обеспечена финансированием и заказами, а «красные» и «желтые» клетки показывают, что еще необходимо организовать.