Чек-листы и онтологика

Чек-листы используются для сверки целевой и обеспечивающей системы против определения системы. Для этого и нужна вся команда при их прогоне, а не просто аналитик, который к каждому пункту прикрепит выгрузку из PLM.

Поэтому все пункты чек-листа делятся на:
1) Дисциплинарные. Проверка причинного вывода по основным дисциплинам. Должны быть предоставлены свидетельства, которые по микротеории дисциплины сдвигают оценку вероятности успешности _проекта_. Например "Архитектурные требования выделены и запланирована их проверка", "Скорость при посадке больше 200 узлов".
2) Технологические. Проверка готовности технологий к использованию. Должны быть предоставлены свидетельства того, что технология способна реализовать практику жизненного цикла. Например, "производственная линия выпускает продукцию по спецификациям с выходом годных 99.5% на пиковом времени такта в течение минимум трех производственных смен".
3) Архитектурные. Проверка правильности реализации архитектуры. Должны быть предоставлены свидетельства того, что архитектура системы соответствует определению архитектуры. Например, "команда согласна, что продукт реализован в соответствии с замыслом".
4) Надежности человека. Проверка минимум на skills based/rules based/knowledge based ошибки в ходе работ. Например, "аудит безопасности не выявил критических нарушений в технике безопасности на производственной линии, процесс обеспечения безопасности постоянно улучшается".

Например:

Запуск проекта

1. Команда запуска проекта сформирована, как минимум из представителей научно-исследовательского отдела, профильных разработчиков по специальностям, проектного офиса, отдела системной инженерии, финансового аналитика, маркетолога.
2. В команде запуска назначены руководитель программы и главный конструктор/системный инженер, это должны быть разные люди.
3. Все участники команды запуска получают резервирование 20-40-60-80-100% в системе управления проектными ресурсами на время запуска и обязаны еженедельно списывать зарезервированное рабочее время на задачи проекта. Руководитель программы одобряет и закрывает отчеты команды запуска.
4. Системный архитектор и инженер по требованиям разрабатывают концепцию эксплуатации и высокоуровневую архитектуру системы и защищают ее перед рабочей группой. Рабочая группа оценивает способность предлагаемых архитектур решить поставленные задачи.
5. Проводится анализ аналогичных проектов в базе проектов, с упором на интеграцию и платформенную разработку. Из базы проектов берутся шаблоны ИСР системы, работ по интеграции, расписания, установочные документы по аналогичным проектам, оценки трудозатрат и стоимости и закрывающие отчеты по ранее выполненным проектам.
6. Команда запуска определяет модель жизненного цикла и готовит верхнеуровневую оценку стоимости жизненного цикла системы. Главный конструктор и руководитель программы защищают эту оценку у генерального директора и готовят предварительное технико-экономическое обоснование разработки.
7. Команда запуска определяет модель жизненного цикла проекта и вносит его в систему управления проектами.
8. Разрабатываются альтернативные концепции системы, минимум три варианта. Проводится анализ альтернатив, эти концепции сравниваются по возможным техническим характеристикам, стоимости жизненного цикла.
9. Главный конструктор собирает совещание команды запуска и собирает предположения по физическому и оперативному окружению системы.
10. Рабочая группа определяет функциональные характеристики системы, которые помогают ей эффективно работать в этом окружении.
11. Главный конструктор при общении с заказчиком выявляет сложности и препятствия работе системы в месте предполагаемой обстановки, при необходимости выезжает в составе группы обследования объектов и обследует местность. Руководитель программы по результатам обследования обновляет план управления рисками.
12. Анализ альтернатив оформляется документально и вносится на рассмотрение группе запуска. Группа запуска изучает результаты изучения альтернатив и дает рекомендации по исправлению. После согласования с группой запуска результаты изучения альтернативных концепций системы вносится спонсору проекта и главный конструктор и руководитель программы защищают рекомендованный вариант.
13. Анализ альтернатив дает информацию для составления расписания программы, оценки ее стоимости. Профильные специалисты проводят предварительную оценку стоимости и сроков реализации элементов системы, передают эти оценки руководителю проекта, который готовит постепенно уточняющееся расписание и бюджет проекта.
14. Маркетологи проводят сегментацию рынка и определяют потенциальные ниши, в которых можно продавать продукт после первой пробной установки у заказчика. Рассчитывают емкость рыночных сегментов, готовят различные сценарии продаж и продвижения, задают ограничения на предельную себестоимость разработки и единичного экземпляра системы. Берут у группы запуска результаты расчета полной стоимости владения и готовят финальное предложение по анализу рынка. Оформляют результаты анализа рынка документально и защищают его у генерального директора.
15. Руководитель программы объединяет документы с расчетом стоимости жизненного цикла системы с анализом рынка, проверяет, что анализ рынка учитывает необходимость поддерживать заменяемые элементы системы, уточняет у заказчика текущие методики измерения эффективности системы, и узнает текущие методики оценки эффективности аналогичных систем. Собирает совещание по началу разработки технико-экономического обоснования. Вносит документы по анализу рынка в систему управления проектами, далее при продажах системы будет проводиться сравнение результатов анализа с фактическими продажами.
16. Руководитель программы и главный конструктор готовят предварительное описание этапов и стадий разработки системы, порядка разработки ее функциональности. Определяют количество экспериментальных и опытных образцов, которые можно построить в рамках программы. Уточняют критические характеристики этих образцов у Заказчика, которые необходимы для приемки и испытания.
17. Руководитель программы готовит план по управлению рисками с участием представителей Заказчика и поставщиков компонентов системы.
18. Главный конструктор проверяет результаты анализа рынка и говорит, учитывает ли проведенный анализ появление новых технологий и решений за время разработки программы. Получившиеся результаты руководитель программы учитывает в плане управления программой.
19. Разработчики ПО разрабатывают показатели надежности программного обеспечения системы.
20. Системный архитектор определяет режимы работы и системное окружение системы во время производства, функционирования и технической поддержки.
21. Главный конструктор проводит серию совещаний с производственным подразделением и руководителями отделов разработки, на которых выявляет ограничения по инженерным и производственным мощностям. Руководитель программы учитывает составленный список ограничений по производству и разработке в плане программы.
22. Главный конструктор уточняет у инженера по требованиям, какими методами он пользуется при подготовке требований к системы и дает рекомендации по изменению процесса сбора и анализа требований.
23. Инженер по требованиям проводит интервью у разработчиков ПО и собирает требования к тестированию программного обеспечения, передает их руководителю программы, который учитывает их в плане программы.
24. Главный конструктор и руководитель программы собирают архитектурные описания и документацию по требованиям и проверяют, что они не противоречат друг другу, проработаны на одинаковом уровне и обсуждены в достаточной мере для этой стадии.
25. Главный конструктор проверяет, что нефункциональные требования зафиксированы.

Разработка концепции и планирование

1. На базе собранной информации составляется расписание работ, которое отражает техническую сложность рекомендованного решения, объем НИР и ресурсы, необходимые для проведения НИОКР. Формирует запросы на выделение ресурсов, получает предварительные одобрения, закладывает оценку стоимости ресурсов в проектные планы.
2. Руководитель программы готовит документ с описанием потребности в финансировании и поддерживает его в актуальном состоянии, регулярно обсуждает его с планово-экономическим отделом и главным бухгалтером. В случае серьезных изменений обсуждает его в генеральным директором. Проверяет потребности финансирования и расписание программы, чтобы они не расходились.
3. Во время анализа альтернатив руководитель программы оценивает различные варианты исполнения работ с участием разных подрядчиков, планирует стоимость командировок команды программы и ее обучения работе с системы. Согласует эти планы по персоналу с начальником отдела кадров и генеральным директором по необходимым компетенциям и планам развития, вносит назначения на проект в личные дела сотрудников. Готовит пояснения по тому, какая квалификация персонала нужна, какие обязанности они будут исполнять и какая у них будет ответственность. Готовит документ “Организационная структура проекта” и согласует его у начальника отдела кадров и генерального директора, доводит его до группы запуска и назначенных сотрудников.
4. Главный конструктор совместно с руководителем проекта оценивает технические риски, связанные с требуемыми характеристиками системы, готовностью технологий, стоимостью, сроками, имеющимися ресурсами, учитывает их в плане управления рисками.
5. Руководитель программы оценивает влияние рисков на стоимость и сроки программы и готовит предложение по размеру управленческого резерва, утверждает его размер у генерального директора.
6. Руководитель программы доводит до команды запуска свое понимание рисков, и их влияние на программу, команда запуска согласна со списком рисков и планами реагирования.
7. Руководитель программы постоянно сверяет, что стоимость программы соответствует уровню проработки документации по требованиям.
8. Руководитель программы организует серию совещаний, на котором обсуждается какие разделы программы (программное, аппаратное обеспечение, персонал) находятся под риском удорожания при более детальном планировании работ.
9. Руководитель программы организует серию совещаний, на которых обсуждает иерархическую структуру работ по всем альтернативным вариантам, и выявляет от чего в наибольшей степени зависит стоимость и риски рекомендованного решения, вносит эти пункты в реестр рисков проекта.
10. Главный конструктор собирает совещание разработчиков, на котором обсуждается, достаточно ли информации, чтобы начать разработку системы.
11. В ходе проработки проектных решений инженер по требованиям собирает и анализирует требования стейкхолдеров, трассирует их к потребностям стейкхолдеров, оформляет документацию по требованиям.
12. Руководитель программы собирает совещание, на котором обсуждается бюджет разработки технического проекта по модульным домам, формирует итоговое предложение по финансированию разработки технического проекта, которое защищает у спонсора программы. Руководитель программы вносит защищенную сумму в план проекта и распределяет ее по бюджетам рабочих групп.
13. Руководитель программы проверяет, что стоимость разработки, приобретения и тестирования программного обеспечения учтена в общей оценке стоимости программы, а стоимость приобретения программного обеспечения включает приобретение, разработку, поставку, развертывание.
14. Руководитель программы проверяет, что аспекты обеспечения безопасности и соблюдения законодательства при разработке программного обеспечения учтены.
15. Руководитель программы и главный конструктор проверяют реестр изменений и процесс управления изменениями и убеждаются, что изменения анализируются с учетом их влияния на весь жизненный цикл системы.
16. Главный конструктор проверяет, что есть технические планы разработки по системы, датчикам, каналам коммуникации и планы по интеграции комплекса и дает подтверждение руководителю проекта о том, что дальнейшая разработка возможна.
17. Подготовлены следующие документы: черновик плана по системной инженерии, предварительные расчеты технических характеристик, стоимости и сроков разработки минимум трех альтернативных концепций продукта, расписание работ, иерархическая структура работ предпочитаемого варианта, оценка стоимости и рисков реализации, план финансирования программы и детальный план финансирования этапа разработки технического проекта, анализ рынков сбыта и черновик маркетингового плана.
18. Все документы, необходимые для проведения оценки концепции продукта заведомо рассылаются всем проверяющим.
19. Все дополнительные документы, необходимые для проведения оценки концепции продукта, такие как изучение реализуемости, исследования рынка, предварительная стратегия программы были заведомо разосланы всем проверяющим.
20. Для рекомендуемого технического решения подготавливает документ с техническими и экономическими показателями, по которым оно будет оцениваться. Документ подписывается генеральным директором, главным конструктором и руководителем программы.
21. Все документы внесены в систему управления проектами и контролируются их версии. Настроены маршруты документооборота, права доступа к папкам проекта, всем участникам присвоены проектные роли в системе управления проектами.

Критерии прохождения контрольной точки "Запуск проекта"

1. Предлагаемое техническое решение по системы по мнению команды запуска решает все поставленные задачи в рамках установленных ограничений, это мнение оформлено документально и принято генеральным директором.
2. Архитектуры и требований для системы по мнению команды запуска достаточно для начала разработки.
3. НИР можно провести в том виде, в котором они запланированы.
4. Критические аспекты разработки программного обеспечения поняты разработчикам в достаточной мере, чтобы начать работу и уровень риска разработки приемлем.
5. Технологические риски известны и есть планы по их уменьшению, есть ответственные за эти планы люди.
6. Руководитель программы и системный инженер согласны с тем, что проект укомплектован персоналом, и продукт можно сделать в срок, решить все критические задачи разработки.
7. Руководитель программы считает расписание программы реалистичным в рамках бюджета и технических рисков.
8. Первичные технические характеристики системы зафиксированы в спецификации на поставку и поставлены под контроль конфигурации.
9. Спецификации на системы соответствуют уровню готовности технологии к использованию, расписанию программы и бюджету.
10. План программы и спецификация на системы соответствуют условия договора поставки заказчику.

План по системной инженерии содержит следующие разделы:
1. Введение - назначение документа и таблица версий
2. Технические требования к программе
2.1 Контроль архитектуры и интерфейсов
2.2 Сертификация
3. Инженерные ресурсы и управление разработкой и испытаниями
3.1 Расписание разработки и испытаний и оценка рисков расписания
3.2 Инженерные ресурсы и отчетность по стоимости и срокам
3.3 Управление рисками разработки и интеграции
3.4 Техническая организация
3.5 Взаимодействие с внешними техническими организациями
3.6 Технические параметры и характеристики
4. Технические задачи и продукты
4.1 Результаты системной инженерии предыдущей стадии
4.2 Планируемые работы по системной инженерии на следующую стадию
4.3 Процесс разработки и изменения требований
4.4 Защиты проектной документации
4.5 Процесс управления конфигурацией и изменениями
4.6 Варианты конструкции
4.7 Инженерные инструменты