Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Цели -- сначала, требования -- потом.

Вид жизненного цикла* моделеориентированной системной инженерии существенно отличается от типичного вида жизненного цикла традиционной системной инженерии. По традиции (см. любую V-диаграмму) все начинается с требований, а заканчивается тестированием (валидацией и верификацией). Моделеориентированная системная инженерия ставит все с ног на голову: требования появляются в середине, а тестирование идет чуть ли не сразу (test-driven development).

Я уже приводил ориентировочную V-диаграмму моделеориентированной системной инженерии (http://ailev.livejournal.com/820662.html, комментарии можно услышать на первом часу шестой лекции введения в системную инженерию http://ailev.livejournal.com/818816.html). Теперь этот вид жизненного цикла нужно описать, встав на плечи гигантов.

В качестве первого гиганта выступил Cezsr Gonzales-Perez http://www.verdewek.com/openmetis/Download/OPENMetisWhitePaper.zip. В качестве второго гиганта выступает Ian Alexander, написавший статью "Выявление требований из развилок" (Discovering Requirements by Trade-Offs) -- http://easyweb.easynet.co.uk/~iany/consultancy/goals/reqts_by_tradeoffs.htm

В этой статье (вариант которой был опубликован с заголовком "From wish list to want list" -- от списка пожеланий к списку требований**) Ian Alexander описывает практику выявления требований из анализа альтернативных проектных решений.

Цикл прохождения развилок*** (trade-off cycle) у Ian Alexander начинается с людей: заинтересованных в вашей системе (вашем проекте) сторон. Каждый из них декларируют свои цели: для отдельных функций; для работоспособности; для эксплуатационных характеристик; для безопасности, защищенности, надежности; для соответствия стандартам; для низких цен, низкого веса, низкого энергопотребления и т.д.

Затем архитекторы (у Ian Alexander -- проектировщики, designers) начинают работать, предлагая проектные решения-кандидаты (candidate solutions) -- архитектуры, специфические алгоритмы в случае софта, альтернативные платформы, покупные компоненты. Вполне вероятно, что можно предложить более чем один подход. Если так, то подходы будут отличаться в том, как они удовлетворяют различным целям. Тем самым нужно будет пройти важные развилки (trade-offs), выборы в которых существенно зависят от контекста. Если проектируется что-то для целей безопасности, то надежность крайне важна. А если что-то для развлечений, то дизайн может существенно перевесить надежность.

Когда у вас есть цели заинтересованных сторон и проектные решения-кандидаты, вы должны оценить развилки. Математически такие цели, как эксплуатационные характеристики, работоспособность, надежность и т.д. представляют собой различные измерения (dimensions). Далее Ian Alexander говорит о том, что всяко нужно свести размерность до маленького числа -- два или три. Мне лично сомнительно, что в больших проектах такое поможет, но сейчас меня интересует не столько метод прохождения развилок (в статье критикуется простое взвешивание и непростое взвешивание Analytic Hierarchy Process за то, что они "складывают яблоки с апельсинами", но предлагается Principal Component Analysis с анализом его результатов людьми -- хотя и этот метод работает не всегда), а общая последовательность работ по получению требований. В этой последовательности развилки определяют как подход с наилучшим проектным решением, так и какие проектные цели являются достижимыми требованиями (выполнимыми, экономичными, измеримыми, верифицируемыми, с приемлемыми рисками). Некоторые цели могут быть ослаблены или вообще выкинуты. Прохождение развилок является наиважнейшим шагом в выявлении требований.

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

Книжка Ian Alexander и Ljerka Beus-Dukic, которая описывает это все в подробностях: http://avaxhome.ws/ebooks/engeneering_technology/discovering_requirements_products.html. Книжка сама по себе восхитительна и полна практических советов. Например, приложение про инструменты начинается с того, что они могут вредить (стр.411): инструменты создают круто выглядящие диаграммы, которые могут создать ошибочное впечатление правильности и завершенности, и что они созданы Тем, Кто Знает. Дается совет: намеренно делайте грубые модели, даже если используете инструменты -- оставляйте пустые прямоугольнички, стрелки, идущие в никуда и т.д.. Делайте что угодно, лишь бы было ясно, что модель не закончена! И таких советов в книжке очень и очень много.

Список моделей выявления требований (главы вышеприведенной книжки):
Requirements discovery models:
– stakeholder onion models (Chapter 2)
– stakeholder influence diagrams (Chapter 2)
– goal models (Chapter 3)
– use cases (Chapter 5)
– Checkland-style rich pictures (Chapter 4)
– rationale models (Chapter 7)

Веб-ресурсы для этой книжки: http://www.scenarioplus.org.uk/dr_book/books_and_websites.htm

* Вид жизненного цикла = ВидВременногоЦикла, TimeCycleKind в ISO 24744. Шаблон последовательности стадий, в том числе с их выходными продуктами.
**want list -- передал как "список требуемого" (want list -- a list of stamps, books, recordings, or similar items required by a collector).
*** trade-off -- передаю традиционно как "развилки" или "прохождение развилок", а не "компромиссы".
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 5 comments