Есть много акронимов и отдельных свойств архитектуры:
RASUI: reliability, availability, serviceability, usability and installability
Надежность, доступность, обслуживаемость, удобство использования и удобство установки.
FURPS: Functionality, usability, reliability, performance and supportability
Функциональность, удобство использования, надежность, производительность, поддерживаемость.
Agility (не путать с agile!): debuggability, extensibility, portability, scalability, securability, testability and understandability
Отлаживаемость, расширяемость, переносимость, масштабируемость, обеспечение безопасности, понятность(!)
С безопасностью есть нюанс: речь не о безопасности, как таковой, а о возможности обеспечить требуемый уровень безопасности. Кроме того, в переводах постоянно путают safety, security и protectability — всё называют "безопасность", но: если речь идёт о безопасности для пользователя (система ему не вредит) — это safety, о защищенности (чтобы систему никто не повредил) — security), о возможности обеспечить эту защищенность — securability, о защите от конкретных атак — protection и о возможности эту защиту в принципе организовать — securability (хороший термин "охраноcпособность", но зарезервирован в авторском праве).
Dependability: availability, reliability, safety, integrity and maintainability
Доступность, безотказность, безопасность, цельность и поддерживаемость.
Ещё одно сложное слово - по-русски это опять "надёжность". Reliability — это более техническая вещь, больше про отсутствие сбоев, а dependability — более широкая. В ГОСТ Р 27.102-2021 "НАДЕЖНОСТЬ ОБЪЕКТА. Термины и определения" dependability переведено как "надежность", а reliability как "безотказность".
Вы это, наверное, всё и так знаете, и знаете принцип разговора о качестве, как предлагает стандарт ISO 25000: сначала вид качества (или модель качества): качество продукта, качество данных, качество в использовании и качество ИТ-сервиса; затем — атрибуты качества (все эти -ilities); и, наконец, показатели качества — что мы объективно можем измерить. То есть, берём, к примеру, модель качества ИТ-сервиса, атрибут "доступность", а его показатели: вероятность того, что система в данный момент работоспособна, наработка на отказ, время восстановления, то есть все эти MTBF, MTTF, MTTR и т.д. Вот тут есть хорошая вводная статья (и даже с оговоркой, что MTTR может иметь 4 разных смысла!)
Говорят, что системные аналитики вообще нечасто задумываются о характеристиках качества. Мол, это всё области либо reliability engineers, либо девопсов, либо юзабилистов, либо безопасников. Или архитекторов, которые за всё отвечают.
Меня же всегда интересовали характеристики, не попадающие в распространенные классификации, но про которые может подумать аналитик. Это такие специфические вещи, которые как бы ничьи. Вот, например, доступность, но другая — та, что accessibility. Вроде кусочек из юзабилити, но на самом деле там в основном функциональные требования и требования к контенту. Или вот локализуемость, она же i18n. Там же бездны, особенно если с rtl-языками. И требования к контенту, опять же.
Дальше есть атрибуты, которые на самом деле ведут к функциональным требованиям:
1. Как мы систему развертываем, интегрируем, настраиваем и обновляем (может быть, это вопрос devops и организации deployment pipeline, а может быть у вас каждая установка у нового клиента — это отдельный проект на полгода).
Как мы приводим систему в нулевое состояние, готовое к работе? И что это за состояние — какие справочники должны быть загружены, какие первичные данные введены, что наоборот — удалено? Как мы организуем параллельную эксплуатацию, в случае надобности? (Hint: планируйте первичную загрузку данных и сброс "к нулю" как многократное действие)
2. Смежные характеристики: как мы систему можем менять и подгонять под конкретное окружение и задачу (расширяемость, интероперабельность, совместимость, наличие внешних интерфейсов, конфигурабельность, взаимозаменяемость частей)
RASUI: reliability, availability, serviceability, usability and installability
Надежность, доступность, обслуживаемость, удобство использования и удобство установки.
FURPS: Functionality, usability, reliability, performance and supportability
Функциональность, удобство использования, надежность, производительность, поддерживаемость.
Agility (не путать с agile!): debuggability, extensibility, portability, scalability, securability, testability and understandability
Отлаживаемость, расширяемость, переносимость, масштабируемость, обеспечение безопасности, понятность(!)
С безопасностью есть нюанс: речь не о безопасности, как таковой, а о возможности обеспечить требуемый уровень безопасности. Кроме того, в переводах постоянно путают safety, security и protectability — всё называют "безопасность", но: если речь идёт о безопасности для пользователя (система ему не вредит) — это safety, о защищенности (чтобы систему никто не повредил) — security), о возможности обеспечить эту защищенность — securability, о защите от конкретных атак — protection и о возможности эту защиту в принципе организовать — securability (хороший термин "охраноcпособность", но зарезервирован в авторском праве).
Dependability: availability, reliability, safety, integrity and maintainability
Доступность, безотказность, безопасность, цельность и поддерживаемость.
Ещё одно сложное слово - по-русски это опять "надёжность". Reliability — это более техническая вещь, больше про отсутствие сбоев, а dependability — более широкая. В ГОСТ Р 27.102-2021 "НАДЕЖНОСТЬ ОБЪЕКТА. Термины и определения" dependability переведено как "надежность", а reliability как "безотказность".
Вы это, наверное, всё и так знаете, и знаете принцип разговора о качестве, как предлагает стандарт ISO 25000: сначала вид качества (или модель качества): качество продукта, качество данных, качество в использовании и качество ИТ-сервиса; затем — атрибуты качества (все эти -ilities); и, наконец, показатели качества — что мы объективно можем измерить. То есть, берём, к примеру, модель качества ИТ-сервиса, атрибут "доступность", а его показатели: вероятность того, что система в данный момент работоспособна, наработка на отказ, время восстановления, то есть все эти MTBF, MTTF, MTTR и т.д. Вот тут есть хорошая вводная статья (и даже с оговоркой, что MTTR может иметь 4 разных смысла!)
Говорят, что системные аналитики вообще нечасто задумываются о характеристиках качества. Мол, это всё области либо reliability engineers, либо девопсов, либо юзабилистов, либо безопасников. Или архитекторов, которые за всё отвечают.
Меня же всегда интересовали характеристики, не попадающие в распространенные классификации, но про которые может подумать аналитик. Это такие специфические вещи, которые как бы ничьи. Вот, например, доступность, но другая — та, что accessibility. Вроде кусочек из юзабилити, но на самом деле там в основном функциональные требования и требования к контенту. Или вот локализуемость, она же i18n. Там же бездны, особенно если с rtl-языками. И требования к контенту, опять же.
Дальше есть атрибуты, которые на самом деле ведут к функциональным требованиям:
1. Как мы систему развертываем, интегрируем, настраиваем и обновляем (может быть, это вопрос devops и организации deployment pipeline, а может быть у вас каждая установка у нового клиента — это отдельный проект на полгода).
Как мы приводим систему в нулевое состояние, готовое к работе? И что это за состояние — какие справочники должны быть загружены, какие первичные данные введены, что наоборот — удалено? Как мы организуем параллельную эксплуатацию, в случае надобности? (Hint: планируйте первичную загрузку данных и сброс "к нулю" как многократное действие)
2. Смежные характеристики: как мы систему можем менять и подгонять под конкретное окружение и задачу (расширяемость, интероперабельность, совместимость, наличие внешних интерфейсов, конфигурабельность, взаимозаменяемость частей)