바로가기 메뉴
본문 바로가기
주메뉴 바로가기

SW중심사회

통합검색 이동
[SW공학 동영상 37화] Quality Attribute Refinement and Allocation
  • 작성자 SW중심사회 SW공학센터
  • 등록일2017-02-07
  • 조회수41,430

 

 

참석자

Suzanne Miller - Principal researcher at the SEI (the Carnegie Mellon University Software Engineering Institute)

Dr. Neil Ernst - A fellow researcher who works in the SEI’s Architectural Practices Initiative

 

요약

우리는 소프트웨어의 품질 속성에 대해 이야기한다. 이러한 것을 비 기능 요구 사항이라고 한다. 더 일반적인 것일 수도 있는데 품질 속성은 반응해야 하는 속도와 같은 것을 지정한다. 그리고 품질 속성은 시스템에 제약 조건을 추가한다.

성능 제약 조건은 보안 제약 조건, 사용 편의성 제약 조건 내에서 수행해야 하는데 이러한 것들이 모두 품질 속성이 되는 것이다. 품질 속성은 기능적 측면보다 관심을 덜 받는 경향이 있어 경영진은 더 관심이 있다.

아키텍처 측면에서 볼 때 품질 속성은 아키텍처 결정에 가장 큰 영향을 미칠 때가 있다. 예를 들어 로그인 화면을 구현하기 위해 여러 프레임워크 중에서 선택할 수 있지만 성능을 고려하면 선택의 폭을 좁힐 수 있다. (그것은 트레이드 오프 부분이다)

하지만 품질 속성은 잊혀지는 경향이 있다. 어떤 성능을 원하거나 보안을 원하는 것과는 다르다. 이 것은 절충점을 찾아야 한다. 이러한 절충점은 실제로 결정하기 어려운 경우가 많다.

암호를 보면, 모든 속성을 가진 14 자 암호를 사용해야 할 때 사용자로서 영숫자인 것을 기억하기가 쉽지 않다. 새 은행 사이트를 사용할 때 6자에서 8자로 제한되고 영숫자만 가능하다면 이것은 쉽게 해킹 당할 수 있다. 보안 측면을 고려하지 않았고 균형도 못 맞췄다.

아키텍처 관점에서 볼 때 시스템에 대한 기본적인 이해부터 시작하는 것이 중요하다. 그리고 시스템에서 중요한 품질 속성이 무엇인지 이해해야 한다. 반복적인 소프트웨어 개발에서 품질 속성을 정의하는데 문제는 다양한 기능을 교차 절단하는데 있다고 생각한다.

성능에 대한 우려가 있는 경우 누구에게 책임이 있는가? 모든 사람에게 책임이 있다면 아무도 책임을 지지 않는다는 것이고 나중에 고치겠다는 것이다. 이것은 잘못된 것이다. 왜냐하면 이것이 설계할 방법에 영향을 미칠 결정이기 때문이다.

품질 속성을 정제하는 방법은 우리가 아키텍처 분석을 수행하는 것과 같이 품질 속성에 대해 생각하는 방식이 유스케이스나 시스템 설계를 테스트하는 방법과 같다. 중요하다고 생각하는 요소가 구체화 시키거나 문제를 일으키는 원인이라고 생각한다.

반복 개발에서 볼 수 있는 것은 품질 속성을 완료라는 것에 합치는 것이다. 반복적인 개발과 애자일 개발에서는 기능에 대한 수용 기준을 갖게 된다. 수용 기준은 품질 속성의 비 기능적 요구 사항을 다루지 않는다. 하지만 사람들에게 권장하는 방식은 완료의 정의가 모든 것을 충족시킨다는 것이다. 성능 문제나 보안 문제가 있는 경우 그 문제를 파악하려면 테스트하거나 검증하거나 아니면 명백하다는 것을 확인해야 한다.

품질 특성을 조정하기 위해서는 이전으로 돌아가서 명시적으로 작성해야 한다고 생각하지만 반복적인 개발을 한다면 이 스프린트나 다음 스프린트에서 할 수 있는지 확인해야 하는데 이러한 반복 작업은 길이와 크기가 매우 다양하다. 사용자 스토리를 구체화하거나 슬라이스하는 다양한 방법이 있다. 이는 기능적, 비 기능적 품질 속성에서 공통적인 문제고 아직도 어렵다.

기능 분야에서 슬라이싱을 하기 위해서는 가지고 있는 다양한 접근 방식을 조사할 수 있다. 사람들의 일반적인 개념 기준은 수평 슬라이싱의 일종인데 대부분의 애자일 리더가 추천하지 않는다. walking skeleton idea는 중요하고, 아키텍처와도 관련이 있다. 정교화는 본질적으로 더 큰 품질 속성 요구 사항(QAR)을 작은 조각으로 분해한다.

시스템이 작동되는지 인증하는 조직 구성에는 수많은 보안 요구 사항이 있다. 전통적인 개발에서는 테스트가 끝나고 끝까지 처리되지 않는다. 구현하는데 유용하거나 검증하는 데 유용한 보안 요구사항을 어떻게 쪼갤 수 있는가? 내가 쪼갤 것인지 확인할 수 있을 때까지 그냥 두는 것이다.

수평 슬라이싱 방식의 위험은, 성능이 중요하다고 하면서도 그것을 다루지 않기 때문에 다른 그룹에 할당했다면 아무도 그 그룹을 인정하지 않는다. 하지만 그다지 많지는 않다. 왜냐하면 레이어를 훑어 보는 팀이 아니라 레이어를 둘러싼 팀이기 때문이다. 그들은 자신의 레이어를 가로 질러보고 있고 다른 종류의 팀 구성 환경을 만든다.

본질적으로 품질 속성 시나리오는 수직 슬라이스라고 생각한다. 문제는 이 조각이 얼마나 큰가 하는 것이다. 우리가 끝내기에 충분한 크기이여야 한다.

예가 금융 서비스 회사였다. 주문을 처리하려면 성능이 매우 중요하다. 임계 값 테스트나 이와 유사한 것으로 알아낸다. 반복을 하면서 매 반복 결과마다 성능 임계 값을 조정한다. 점차적으로 반복하여 성능의 임계 값 또는 필요로 하는 수치까지 도달 할 것이다. 전통적인 방식에서 반복적인 방식의 전략 중 하나다.

아키텍처 관점에서 볼 때 위험한 부분은 초기 값을 너무 높게 설정하면 효율적이지 못한 아키텍처 방식을 고를 수 있다. 여기서 핵심은 반응 곡선을 이해하는 것이다. 반응 곡선이 반드시 선형은 아니고 성능 측면에서는 거의 선형적이지 않다. 어떤 시점에서 기준에 도달하지 못하는지 찾을 수 있다.

이번에는 품질 속성 시나리오로 돌아가서 컨텍스트를 본다. 컨텍스트가 정상적이면 올바르게 작동한다. 그리고 정확히 무엇이 일어나는지 안 후에 프로토타입을 만들거나 할 말을 해야 한다. 하지만 신뢰를 받지 못한다면 말하기가 어려울 것이다.
만약 여러분이 대규모 조직에 있다면, 어떻게 하면 스프린트를 구조화 하는지 언제 계획을 세울 것인지 누가 있어야 하는지 명시적인 접근 방식이 있는지 알아야 한다. 이러한 것들을 명백하게 하는 것이 중요하다.

품질 속성 세분화는 어떻게 하는가? 현재 집중하고 있는 것은 기술적 부채라고 생각한다. 이러한 정제의 큰 부분이 제대로 수행되지 않으면 기술적 부채는 늘어난다. 우리는 기술적 부채 관리를 연구하고 있다.

이 주제에 대해서는 resources.sei.cmu.edu를 방문해라. 저자별로 찾아보기를 클릭하고 Neil을 입력해라. 이 팟캐스트는 SEI 웹 사이트 sei.cmu.edu/podcasts 및 Carnegie Mellon University의 iTunes U 사이트에서 제공된다.

첨부파일
고객만족도 설문조사이 페이지에서 제공하는 정보에 대하여 만족하시나요?