소프트웨어 개발을 위한 의미 있는 품질 속성을 작성하는 방법 - brightwindee/Architecture-study GitHub Wiki

[원문: How to Write Meaningful Quality Attributes for Software Development]

품질 속성(QA, Quality attribute)은 시스템이 이해관계자의 요구를 얼마나 잘 충족시키는지를 나타내는 데 사용되는 시스템의 측정 가능하거나 테스트 가능한 속성입니다.

다시 말해, 품질 속성(비기능 요구 사항이라고도 함)은 특정 이해 관계자와 관련하여 시스템을 좋게 만드는 요소입니다. QA의 예로는 기능이 얼마나 빨리 수행되어야 하는지, 잘못된 입력에 대한 복원력(resilience), 제품 배포 시간 또는 운영 비용에 대한 제한 등이 있습니다. 몇 가지 QA 목록입니다:

  1. 성능 (Performance)
  2. 보안 (Security)
  3. 수정 가능성 (Modifiability)
  4. 신뢰성 (Reliability)
  5. 사용성 (Usability)
  6. 보정 가능성 (Calibrateability)
  7. 가용성 (Availability)
  8. 웹화 가능성 (Webifyability)
  9. 처리량 (Throughput)
  10. 구성 가능성 (Configurability)
  11. 하위 집합 가능성 (Subsetability)
  12. 재사용 가능성(Reusability)

품질속성(Quality Attribute)은 대부분 문서화되지 않습니다. 기능적 요구 사항과 함께 구두로만 언급됩니다. 대부분의 경우 이러한 속성은 암묵적이거나 별다른 생각 없이 언급됩니다.

실제 예를 들어 특정 기능 개발을 담당하고 있는 사람이 상사에게 시스템에서 어떤 작업을 완료해야 하는데 걸리는 시간을 물어본다고 가정해 보겠습니다. 상사는 아마도 "가능한 최소한의 시간"이라고 대답할 것입니다.

보안도 마찬가지입니다. 누구나 보안이 보장되어야 한다고 말할 것입니다.

하지만 약간의 노력과 준비를 통해 이러한 상황을 피할 수 있습니다. 우선, 모든 품질 속성은 어떤 식으로든 측정할 수 있어야 합니다. 이를 통해 특정 작업을 구현하는 팀은 해당 요구 사항을 완료하기 위해 언제 잘 수행했는지 알 수 있습니다.

가시적인 품질 속성을 정의하려면 품질 속성 시나리오(Quality Attribute Scenario)를 작성하는 것이 좋은 출발점입니다. 품질 속성 시나리오는 테스트 가능한 품질 속성을 명확하게 지정하는 방법입니다. 품질 속성 시나리오는 다음 그림과 같이 6가지 요소로 구성됩니다:

QA

  • 자극 유발원(Source of Stimulus): 자극을 생성할 수 있는 개체(내부 또는 외부 사람, 컴퓨터 시스템 등)

  • 자극(Stimulus): 자극은 시스템에 도착했을 때 반응을 요구하는 조건입니다.

  • 환경(Environment): 자극이 발생하는 환경입니다. 예를 들어 시스템이 정상 상태에서 실행 중이거나, 트래픽이 많은 상태(heavy traffic)이거나, 지연 시간이 길거나(high latency), 기타 관련 상태일 수 있습니다.

  • 아티팩트(Artifact): 자극을 수신하는 아티팩트입니다. 이는 시스템의 구성 요소(component), 전체 시스템 또는 여러 시스템일 수 있습니다.

  • 반응(Response): 수신된 자극에 따른 아티팩트의 반응입니다.

  • 응답 측정(Response Measure): 요구 사항이 잘 구현되었는지 테스트하기 위해 응답에 대해 테스트해야 하는 측정입니다.


Example of a quality attribute scenario

Source of Stimulus: 시스템 외부의 자극
Stimulus: 예상치 못한 메시지
Artifact: 프로세스
Environment: 정상 작동
Response: 운영자에게 알림, 계속 작동
Response Measure: 다운타임 없음

다음과 같이 읽을 수 있습니다:

정상 작동 중 프로세스가 예기치 않은 외부 메시지를 수신했습니다. 프로세스는 운영자에게 메시지 수신 사실을 알리고 시스템은 다운타임 없이 계속 작동합니다.



Getting started writing Quality Attribute Scenarios

품질 속성과 관련된 측정 항목 및 특성들을 모를 수도 있기 때문에 작성을 시작하는 것이 어려울 수 있습니다.

다행히도 가장 일반적인 품질 속성(가용성, 상호 운용성interoperability, 수정 가능성, 성능, 보안, 테스트 가능성testability, 사용성)의 경우 가장 일반적인 면들을 고려해야 하는 일반적인 품질 속성 시나리오(Generic quality attribute scenarios)가 있다는 것이 다행입니다.

일반 시나리오는 특정 품질속성에 대한 일반적인 stimulus, response 및 response measure가 포함된 시스템 독립적인 시나리오입니다.

몇 가지 품질 일반 시나리오는 여기에서 찾을 수 있습니다. 또한 이 정보에 대한 참조는 이 문서의 각주에 나와 있습니다.

이 기법은 비즈니스 상황에 맞는 도메인별 시스템으로 확장할 수도 있습니다.

일반적인 품질 속성 시나리오(Quality attribute scenario)를 사용하는 방법은 다음과 같습니다:

  1. 특정 QA에 대한 일반 시나리오를 선택합니다.
  2. 이해 관계자의 필요에 따라 결정 요인(determinant factor)을 선택합니다.
  3. 모두가 동의할 수 있는 품질 속성 시나리오를 작성합니다.

Example

Choosing a general scenario: Availability

Source of Stimulus: 내부/외부: 사람, 하드웨어, 소프트웨어, 물리적 인프라 또는 환경
Stimulus: 결함 (omission, crash, incorrect timing, incorrect response)
Artifact(s): 프로세서, 통신 채널, 퍼시스턴트 스토리지, 프로세스
Environment: 정상 작동(normal operation), 시작(startup), 종료(shutdown), 복구 모드(repair mode), 성능 저하(degraded operaton), 과부하 작동(overloaded operation)
Response: 결함이 장애로 이어지지 않도록 방지합니다.

  1. 결함을 감지:
    1. 결함을 로깅.
    2. 적절한 대상(사람 또는 시스템)에 노티.
  2. 결함에서 복구:
    1. 장애를 일으킨 이벤트의 원인을 비활성화합니다.
    2. 복구가 진행되는 동안 일시적으로 서비스를 이용할 수 없게 합니다.
    3. 결함/장애를 수정하거나 숨기거나 그로 인한 손상을 억제합니다.
    4. 수리가 진행되는 동안 성능 저하 모드(degraded mode)로 작동합니다.

Response Measure:

  1. 시스템을 사용할 수 있어야 하는 시간 또는 시간 간격.
  2. 가용성 백분율(예: 99.999%).
  3. 오류를 감지한 시간/오류를 복구하는 데 걸린 시간.
  4. 시스템이 성능 저하 모드 상태에 있을 수 있는 시간 또는 시간 간격.
  5. 시스템이 결함을 방지하거나 장애 없이 처리하는 결함 종류 비율(예: 99%) 또는 속도(예: 초당 최대 100회).

Choosing the determinant factors

Source of Stimulus: 내부/외부: 사람, 하드웨어, 소프트웨어, 물리적 인프라 또는 환경
Stimulus: 결함 (omission, crash, incorrect timing, incorrect response)
Artifact(s): 프로세서, 통신 채널, 퍼시스턴트 스토리지, 프로세스
Environment: 정상 작동, 시작, 종료, 복구 모드, 성능 저하, 과부하 작동
Response: 결함이 장애로 이어지지 않도록 방지합니다.

  1. 결함을 감지:
    1. 결함을 로깅.
    2. 적절한 대상(사람 또는 시스템)에 통지.
  2. 결함에서 복구:
    1. 장애를 일으킨 이벤트의 원인을 비활성화합니다.
    2. 복구가 진행되는 동안 일시적으로 서비스를 이용할 수 없게 합니다.
    3. 결함/장애를 수정하거나 숨기거나 그로 인한 손상을 억제합니다.
    4. 수리가 진행되는 동안 성능 저하 모드(degraded mode)로 작동합니다.

Response Measure:

  1. 시스템을 사용할 수 있어야 하는 시간 또는 시간 간격.
  2. 가용성 백분율(예: 99.999%).
  3. 오류를 감지한 시간/오류를 복구하는 데 걸린 시간.
  4. 시스템이 성능 저하 모드 상태에 있을 수 있는 시간 또는 시간 간격.
  5. 시스템이 결함을 방지하거나 장애 없이 처리하는 결함 종류 비율(예: 99%) 또는 속도(예: 초당 최대 100회).

Resulting Quality Attribute Scenario for Availability

Source of Stimulus: Internal hardware
Stimulus: crash
Artifact(s): communications channels
Environment: normal operation
Response:

  1. 오류를 로그에 기록
  2. 해당 대상(사람 또는 시스템)에게 알림.
  3. 결함/장애를 수정하거나 숨기거나 그로 인한 피해를 최소화.

Response Measure:

  1. 결함(오류)을 감지하고 복구하는 데 걸리는 시간은 10분 미만이어야 합니다.


Summary

이 접근 방식을 사용하면 모든 소프트웨어 개발팀은 여러 이해관계자와 관련된 품질 속성에 대한 테스트 가능한 요구 사항을 갖게 됩니다.

이 템플릿은 여기에 명시된 것 외에 특정 도메인 품질 속성을 캡처하는 데에도 사용할 수 있습니다. 다만 개발 프로세스에서 팀이 품질 속성을 충족하는지 확인하려면 어떤 식으로든 품질 속성이 측정되어야 한다는 점을 기억하세요.

이는 구축 중인 소프트웨어 시스템의 관련 품질 속성 요구 사항을 문서화하는 방법에 대한 출발점입니다. 또한 이 방법을 사용하면 다양한 종류의 이해관계자가 대화에 참여하여 특정 품질 속성에 합의할 수 있습니다.

시스템이 달성해야 하는 일련의 품질 속성에 합의하기 위해 다음 포스트에서 소개할 Quality Attribute Workshop(QAW)이라는 방법이 있습니다.

이 자료의 대부분은 다음에서 가져왔습니다:

  1. "소프트웨어 아키텍처 원칙 및 실무"에 대한 SEI 교육 과정
  2. 그리고 책 "Bass, Len. 소프트웨어 아키텍처 실무(소프트웨어 엔지니어링의 SEI 시리즈). Pearson Education. 킨들 에디션."

https://swingswing.tistory.com/249 https://medium.com/@anil.goyal0057/quality-attribute-scenario-a-way-to-define-software-quality-requirements-71dd82f4be1b

⚠️ **GitHub.com Fallback** ⚠️