пятница, 7 сентября 2018 г.

Конспект 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. Исполняются задачи проверки и приемки всех необходимых рабочих продуктов с использованием заранее определенных критериев для достижения согласованности между продуктами на входе и выходе всех мероприятий. Выявляются и исправляются дефекты, записи сохраняются в отчетах о проверке и приемке.
Связь управления жизненного цикла и системной инженерии:

четверг, 6 сентября 2018 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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