Системная инженерия: ее должно быть много, и она должна балансировать agile с плановостью.
Системная инженерия главным образом выигрывает в потерях на масштабе (diseconomy-of-scale) проекта -- она уменьшает крутизну экспоненты. Так, при каком-нибудь незначительном проекте коэффициент потерь будет 1.05, что означает при удвоении объема системы (например, в тысячах строк кода для софтверных проектов -- при всей нелепости этой оценки) будет потрачено (1*2)^1.05 = 2.07 работы (то есть 0.07 количества строк придется написать и потом выкинуть за счет допущенных ошибок). А вот для критических проектов коэффициент будет уже 1.20, что даст (1*2)^1.20=2.3.
Далее берем базу данных из 161 проекта компании TRW, делаем расчет зависимости этого коэффициента от количества работы, потраченного на системную инженерию (работа над требованиями, архитектурные рассмотрения, управление конфигурацией, верификация и прочая "непроизводительная" деятельность, не ведущая напрямую к коду) и узнаем, что системная инженерия позволяет отнимать от коэффициента потерь на масштабе 0.0707. Другими словами, по опыту TRW отсутствие системной инженерии для маленького проекта в 10Кстрок ведет к дополнительным 18% работы, а для большого проекта в 10Мстрок -- к дополнительным 92% работы.
Теперь можно посчитать, сколько работы (в процентах) нужно оптимально тратить на системную инженерию изо всего проекта: для небольших проектов 5%, для средних -- 17%, для больших -- порядка 37%. Если тратить больше, то это как раз будут "излишние расходы на бюрократизм", а если тратить меньше, то будут дополнительные затраты на неминуемое исправление архитектурных ошибок, обнаруженных слишком поздно. Это, конечно, не столько количественные, сколько качественные результаты, но это хороший ориентир.
Это было краткое изложение статьи, ссылку на которую я приводил еще позавчера: http://sunset.usc.edu/csse/TECHRPTS/2008/usc-csse-2008-808/usc-csse-2008-808.pdf
* * *
Какие бывают опорные описания жизненного цикла системной инженерии? Водопадное описание, противостоящее ей спиральное описание (предложенная в незапамятные времена Boehm), RUP. А вот последная из разработок того же Boehm -- Incremental Commitment Model (ICM), объединяющая кучу других risk-driven (читай: agile) нормативных описаний процесса разработки системы (необязательно софтверной). The ICM builds on the strengths of current process models: early verification and validation concepts in the V-model, concurrency concepts in the Concurrent Engineering model, lighter-weight concepts in the Agile and Lean models, risk-driven concepts in the spiral model, the phases and anchor points in the RUP [8, 9, 10], and recent extensions of the spiral model to address SoS acquisition. The ICM uses the critical success factor principles to extend several current spiral-related processes such as RUP, Win-Win Spiral, and Lean Development, in ways that more explicitly incorporate human-system factors into the system life cycle process.
Жизненный цикл по ICM:
Синхронизация распараллеленного (concurrent) инжиниринга:
http://sunset.usc.edu/events/2008/ARR/materials/Incremental_Commitment_Model(ICM)_Process_Decision_Table.ppt
http://sunset.usc.edu/csse/TECHRPTS/2007/usc-csse-2007-715/usc-csse-2007-715.pdf
Про необходимость более тесной интеграции в рамках системной инженерии софтовой инженерии и работы с людскими системами (что непосредственно адресует CIM) --
http://csse.usc.edu/events/2008/ARR/materials/3-IS&SE%20Workshop%20Summary%20Report.doc
http://csse.usc.edu/events/2008/ARR/materials/2-IS&SE%20Final%20Report%20Charts%20123107.ppt
Про dependability и противоречия в моделях от того автора (Boehm):
https://www.softwaretechnews.com/stn_view.php?stn_id=43&article_id=87
Книжка этой же группы товарищей про интеграцию людей в системы и систем в людей (2007): http://books.nap.edu/openbook.php?record_id=11893&page=1
Далее берем базу данных из 161 проекта компании TRW, делаем расчет зависимости этого коэффициента от количества работы, потраченного на системную инженерию (работа над требованиями, архитектурные рассмотрения, управление конфигурацией, верификация и прочая "непроизводительная" деятельность, не ведущая напрямую к коду) и узнаем, что системная инженерия позволяет отнимать от коэффициента потерь на масштабе 0.0707. Другими словами, по опыту TRW отсутствие системной инженерии для маленького проекта в 10Кстрок ведет к дополнительным 18% работы, а для большого проекта в 10Мстрок -- к дополнительным 92% работы.
Теперь можно посчитать, сколько работы (в процентах) нужно оптимально тратить на системную инженерию изо всего проекта: для небольших проектов 5%, для средних -- 17%, для больших -- порядка 37%. Если тратить больше, то это как раз будут "излишние расходы на бюрократизм", а если тратить меньше, то будут дополнительные затраты на неминуемое исправление архитектурных ошибок, обнаруженных слишком поздно. Это, конечно, не столько количественные, сколько качественные результаты, но это хороший ориентир.
Это было краткое изложение статьи, ссылку на которую я приводил еще позавчера: http://sunset.usc.edu/csse/TECHRPTS/2008/usc-csse-2008-808/usc-csse-2008-808.pdf
* * *
Какие бывают опорные описания жизненного цикла системной инженерии? Водопадное описание, противостоящее ей спиральное описание (предложенная в незапамятные времена Boehm), RUP. А вот последная из разработок того же Boehm -- Incremental Commitment Model (ICM), объединяющая кучу других risk-driven (читай: agile) нормативных описаний процесса разработки системы (необязательно софтверной). The ICM builds on the strengths of current process models: early verification and validation concepts in the V-model, concurrency concepts in the Concurrent Engineering model, lighter-weight concepts in the Agile and Lean models, risk-driven concepts in the spiral model, the phases and anchor points in the RUP [8, 9, 10], and recent extensions of the spiral model to address SoS acquisition. The ICM uses the critical success factor principles to extend several current spiral-related processes such as RUP, Win-Win Spiral, and Lean Development, in ways that more explicitly incorporate human-system factors into the system life cycle process.
Жизненный цикл по ICM:
Синхронизация распараллеленного (concurrent) инжиниринга:
http://sunset.usc.edu/events/2008/ARR/materials/Incremental_Commitment_Model(ICM)_Process_Decision_Table.ppt
http://sunset.usc.edu/csse/TECHRPTS/2007/usc-csse-2007-715/usc-csse-2007-715.pdf
Про необходимость более тесной интеграции в рамках системной инженерии софтовой инженерии и работы с людскими системами (что непосредственно адресует CIM) --
http://csse.usc.edu/events/2008/ARR/materials/3-IS&SE%20Workshop%20Summary%20Report.doc
http://csse.usc.edu/events/2008/ARR/materials/2-IS&SE%20Final%20Report%20Charts%20123107.ppt
Про dependability и противоречия в моделях от того автора (Boehm):
https://www.softwaretechnews.com/stn_view.php?stn_id=43&article_id=87
Книжка этой же группы товарищей про интеграцию людей в системы и систем в людей (2007): http://books.nap.edu/openbook.php?record_id=11893&page=1