Конспект ISO/IEC 29110: Systems and Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs)

Польза применения ISO29110
- Согласованный набор проектных требований (техническая часть договора), согласованных с Приобретающей стороной
- Последовательный процесс управления, который обеспечивает прозрачность проекта и своевременные корректирующие действия
- Систематичное определение и воплощение продукта, отвечающего нуждам Приобретающей стороны

Назначение процесса управления проектом
Результат 1. План проекта, описание содержания и обязательства тщательно рассмотрены и приняты как Приобретающей стороной, так и руководителем проекта. Есть оценка задач и необходимых для их выполнения ресурсов.
Результат 2. Идет наблюдение за ходом проекта и его сравнение с планом проекта, результаты наблюдения записываются в отчет о ходе реализации. Если отклонения от планов проекта не позволяют достичь проектных целей, то предпринимаются корректирующие действия. Предпринимается закрытие проекта для получения задокументированной приемки продукта проекта Приобретающей стороной.

Результат 3. Принимаются и обрабатываются запросы на изменения. Команда проекта оценивает влияние от запрошенных изменений системных требований на стоимость, сроки, риски и технические решения.

Результат 4. Проводится защита результатов проекта с участием рабочей группы, приобретающей стороны и поставщиков. Соглашения записываются и их выполнение отслеживается.

Результат 6. Разработана стратегия управления продуктом. Определены элементы, составляющие продукт, для них задан базис. Изменения и выпуск этих элементов контролируются и доводятся до приобретающей стороны и рабочей группы. Контролируется хранение, передача и поставка этих элементов.

Результат 7. Для проекта обеспечивается качество. Рабочие продукты и процессы соответствуют плану проекта и спецификациям системных требований.

Результат 8. Разработан подход к снятию системы с эксплуатации.

Назначение процесса определения и воплощения системы

Результат 1. Выполняются задачи мероприятий текущего плана проекта.

Результат 2. Определены системные требования, они проверены на корректность и тестируемость, одобрены приобретающей стороной, внесены в базис и доведены до всех заинтересованных сторон.

Результат 3. Разработаны и внесены в базис архитектурные решения системы. Они описывают системные элементы, а также внешние и внутренние интерфейсы к ним. Установлена прослеживаемость между требованиями и архитектурными решениями.

Результат 4. Определенные системным дизайном системные элементы произведены или приобретены. Определены и проведены приемочные тесты, чтобы проверить преемственность и последовательность требований и дизайна. Установлена прослеживаемость системных элементов к требованиям и архитектурным решениям.

Результат 5. Системные элементы собраны, интегрированы. Исправлены дефекты сборки, последовательность и прослеживаемость сборки к системной архитектуре установлена и подтверждена.

Результат 6. Системная конфигурация, как она согласована в плане проекта, включая инженерные артефакты, собрана, внесена в базис и сохранена в репозитории проекта. Выявляется потребность в изменениях продукта и запускаются соответствующие изменения.

Результат 7. Исполняются задачи проверки и приемки всех необходимых рабочих продуктов с использованием заранее определенных критериев для достижения согласованности между продуктами на входе и выходе всех мероприятий. Выявляются и исправляются дефекты, записи сохраняются в отчетах о проверке и приемке.

Связь управления жизненного цикла и системной инженерии:

Шаблоны успеха в системной инженерии

Конспект

Задачей этой работы было определить шаблоны успешного использования системной инженерии в ИТ-проектах со значительной программной составляющей. Шаблоны выявлялись методом положительных отклонений (positive deviance, Gawande 2007) от принятых способов работы.
Вначале мы определили 30 госпрограмм, каждая из которых была в итоге признана успешной почти всеми участниками программы. Из этих 30 мы отобрали 12 для последующего изучения. Мы провели интервью с непосредственными участниками программ, у которых были полномочия положительно влиять на принятые способы работы.

Отчет описывает два больших шаблона успешного поведения. Каждый шаблон в свою очередь состоит из шаблонов поменьше. 
Шаблон "Балансирование сети поставок" описывает социальные зависимости между стейкхолдерами предприятия. У этих стейкхолдеров есть различные интересы в конечном результате программы.
Шаблон "Укрощение технической сложности" описывает технические зависимости между элементами системы. Эти элементы все вместе и дают желаемый эффект программы для всего предприятия в целом.

Эти два шаблона как две стороны монеты. Те программы, которые мы исследовали, стали успешными потому что их руководство умело лавировало между социальными и техническими зависимостями.

Главная претензия к практикам системной инженерии со стороны программ и заказчиков состоит в том, что она увязает в деталях. Люди называют такие причины как:
- избыточное госрегулирование;
- взаимозависимости и взаимосвязи систем;
- быстрое изменение потребностей госорганов;
- повышающиеся требования со стороны людей, которые разбираются в ИТ;
- неопределенность экономической ситуации и источников финансирования программ.

Метод положительных отклонений описан Гаванде в его книге Better, 2007 by Atul Gawande.

Разработчики AT&L System of Systems Engineering Guide при разработке руководства  использовали метод положительных отклонений.

Метод шаблонов (patterns) разрабатывал архитектор Кристофер Александер. Он опубликовал его в книге The Timeless Way of Building, Oxford U. Press 1979.

Шаблон состоит из трех частей:

1) Контекст. Определяет ту надсистему, частью которой является та система, которую вы проектируете. Надсистема накладывает ограничения на возможные архитектурные решения.
2) Действующие силы. Выражают отношения между элементами в заданном контексте.
3) Решение. Представляет дизайн или конфигурацию элементов, которая успешно использует действующие силы.

Шаблоны предлагают только принципиальные, архитектурные решения. Шаблоны основаны на практиках.

Формат описания шаблона:

Краткое описание.
Контекст.
Проблема.
Рисунок.
Силы.
Решение.
Примеры.
Результат или итоговый контекст.
Ссылки.

Иногда кажется, что реализовать программу в рамках бюджетных, регуляторных ограничений и в требуемые сроки невозможно. Все мешает этому, начиная со стейкхолдеров и заканчивая технчиеской сложностью проблем.
При этом ресурсы программ крайне ограничены и за них ведется постоянная борьба. Проектный офис часто становится посредником, который пытается решить ресурсные конфликты.
При этом как государственная среда, так и сами процессы системной инженерии зарегулированы. И вокруг есть много других программ, которые постоянно меняют ИТ-ландшафт организаций.
В результате большинство проектных офисов едва выживают в этой среде. Но есть проектные офисы, которые процветают в среде, где другие едва могут выжить. Они используют описанные здесь шаблоны.

Понятие успеха в госпрограммах

Стейкхолдеры систем, которые создаются и закупаются в госпрограммах, ищут способы получения практической пользы как ее воспринимают пользователи этих закупаемых систем. Кроме того, они ожидают, что системы будут поставлены в срок и будут отвечать требованиям регулятора, надзирающего за этой системой и смежными системами.
Мы намеренно оставили определение успешности системы на усмотрение тех, кто давал нам интервью.

Мы определяли сложность по 8 критериям:

- окружение миссии
- объем работ
- масштаб работ
- окружение госзакупки
- вовлеченность стейкхолдеров
- отношения между стейкхолдерами
- желаемые результаты
- поведение системы

Мы провели краткие интервью с руководством успешных программ, обработали результаты и обсудили их с руководством программ еще раз. 

Итогом нашей работы стали 12 шаблонов.

Эти шаблоны не "серебрянные пули" и не "змеиное масло", но мы видели, что большинство из этих шаблонов применялись в каждой успешной программе. Эти шаблоны дополняют друг друга и работают совместно.

"Балансирование сети поставок"

Краткое описание. 
Балансирует взаимодействие между стейкхолдерами в сложных программах по разработке и госзакупке.
Контекст.
- Сеть поставок вместо цепи поставок.
- Деньги текут от Конгресса и дотекают до подрядчиков.
- Регулирование и стандарты идут от госорганов.
- Оргспособность (capability) появляется не от одиночной целевой системы, которую вы создаете и поставляете, а от множества систем, которые находятся под контролем различных организаций.
Проблема.
- Надо иметь сбалансированную стратегию, чтобы удовлетворить правомочные потребности стейкхолдеров.
- Нужно справляться с множественными потребностями в условиях ограниченных ресурсов.

Силы.
- Противоречивые определения успеха у конкурирующих стейкхолдеров
- Стейкхолдеры используют свои ресурсы и влияние в конкуренции
- Конечные ресурсы проектного офиса
- Текущие практики госзакупок ориентированы на цепочки поставок
Решение.
- Моделировать и отслеживать сеть стейкхолдеров и их взаимодействие в течение всей программы
- Применять ограниченные ресурсы программы крайне аккуратно, чтобы постоянно балансировать потребности стейкхолдеров
- Использовать ресурсы одних стейкхолдеров для удовлетворения потребностей других
- Разруливать контекст госзакупки параллельно с разработкой системы
Результат или итоговый контекст.
- Система привела к появлению оргспособности у приобретающей стороны в сбалансированной сети поставок
- Создали функционирующую оргспособность и изменили контекст предприятия.

"Укрощение технической сложности"

Краткое описание.
Упрощает техническое взаимодействие между взаимодействующими системами в цепочке или сети производственной кооперации.
- N-уровневая (слоеная) архитектура является ключевой системной моделью
- Инновации начинаются внутри уровней (слоев)
- Интеграция обеспечивается стандартными интерфейсами между уровнями
Проблема.
- Проектный офис должен создать новую оргспособность, которая встраивается в уже существующие ИТ-системы предприятия
- Не все программы согласны с определением слоев и протоколов интерфейсов между слоями
- Финансирование и руководство программами ориентировано на единичные программы, а не улучшение всего ИТ-ландшафта и системного окружения.

Силы.
- Механизмы корпоративного управления определяют стандарты предприятия
- Независимые проектные офисы используют свои уникальные стандарты и технологии для решения локальных проблем и хотят использовать свои разработки
- Есть давление в сторону всеобщей стандартизации
- Существующая инфраструктура не оптимальна для разрабатываемых компонентов
- Стандарты предприятия постоянно изменяются
Решение.
- Формализовать небольшое количество соглашений в стратегическом плане по технологиям
- Согласовать стандарты (слои и интерфейсы между ними) на основе наиболее распространенных практик, реализовать наиболее простые решения
- Стратегический план по технологиям гарантирует некоторый уровень интероперабельности на предприятии
- Позволять инновации внутри слоев
- Заставлять интегрироваться посредством стандартных интерфейсов
Результат или итоговый контекст.
- Небольшое количество стандартов обеспечивает большую часть интероперательности
- Со сложностью предприятия справляются, использую интеграцию в точках основного взаимодействия и инновацию внутри уровней
- Предприятие может приспосабливаться к меняющимся технологиям и операционным потребностям и не погрязать в бесконечных изменениях.