|
Quality Attribute |
작성자 : 김종현 |
작성일 : 2011-04-23 | |
주 제 : CBD 개발 방법론의 품질 속성에 대해서… |
◎ 비기능 요구사항과 품질 속성(Quality Attribute)
* 소프트웨어 시스템의 구축에 관여하는 많은 이해당사자들은 소프트웨어 시스템에 대하여 서로 다른
관점과 요구사항들을 갖는다고 하였다. 이해당사들이 갖고 있는 요구사항 중에는 시스템에 반드시 구
현되어야만 하는 소프트웨어의 기능에 대한 요구 사항 뿐만 아니라 비기능적인 요구사항도 포함된다.
우리는 비기능적인 요구사항들 중에서 특별히 소프트웨어 아키텍처에 많은 영향을 미치게 되는 요구사
항을 품질 속성이라고 부른다.
* 소프트웨어 시스템에서 기능성이란 원하는 대로 시스템이 제대로 작업을 해주는 능력을 말한다. 따라
서 우리가 기능적인 요구사항만 강조한다면 소프트웨어 아키텍처가 그다지 중요하지 않을 수 있다. 소
프트웨어 아키텍처란 소프트웨어 시스템의 구조를 정의한 것이기 때문에 다른 비기능적인 요구사항
즉, 품질 속성이 중요할 때 비로소 그 가치를 이야기 할 수 있는 것이 된다.
* 품질 속성을 소프트웨어 시스템에 실현하는데 있어서 소프트웨어 아키텍처는 중요한 역할을 담당한
다. 따라서 품질 속성은 아키텍처 레벨에서 설계되고 평가되어야만 한다. 그러나 소프트웨어 아키텍처
그 자체로만 품질 속성을 실현할 수는 없다. 품질 속성을 실현하기 위한 고려는 설계와 구현, 테스트, 배
포 등의 소프트웨어 시스템 개발의 전 작업에서 이루어져야 한다. 소프트웨어 아키텍처는 품질 속성을
실현하기 위한 논리적이며 기술적인 기반을 제공하게 되며, 다른 작업에서는 이것을 바탕으로 세부적
으로 품질 속성을 실현하는 일을 수행해야 한다.
◎ 품질 속성의 3가지 분류
* 시스템 품질 속성 (System Quality Attribute)
* 비즈니스 품질 속성 (Business Quality Attribute)
* 아키텍처 품질 속성 (Architectural Quality Attribute)
◎ 6개의 공통적이며 중요한 시스템 품질 속성 (System Quality Attribute)
* 가용성 (Availability)
→ 가용성이란 시스템이 필요할 때 작동하게 될 가능성의 정도를 의미한다.
이때, 정기 점검 시간은 실패에 포함되지 않는다. 그것은 정기 점검이 이미 예약된 작업이며 따라서 시
스템이 필요한 시간이 아닌 것으로 간주되기 때문이다.
* 변경 가능성(Modifiability)
→ 변경 가능성은 시스템을 변경하는데 소요되는 시간과 노력 등의 비용과 관련된다. 우리가 시스템을
변경한다. 일단 이와 같은 변경이 필요하게 되면 새롭게 설계하고 구현 및 테스트, 배포 등의 작업이
필요하다. 이러한 모든 행위는 비용과 직결되므로 측정되어야 한다.
* 성능(Performance)
→ 성능이란 시스템이 얼마나 빠르고 효율적으로 원하는 기능을 수행하는가 하는 문제와 관련된다.
* 보안(Security)
→ 보안은 적법한 사용자에 대해서는 서비스를 제공하지만 권한이 없는 사용에 대해서는 서비스를 거
부하는 시스템의 능력을 측정한다. 보안에 고려해야 할 요소는 인증, 권한, 기밀성, 무결성, 부인방지가
있다.
* 테스트 가능성(Testability)
→ 테스트 가능성은 테스트를 통해 소프트웨어가 결함을 가지고 있음을 얼마나 쉽게 증명할 수 있는가
를 나타낸다.
* 사용성(Usability)
→ 사용성은 사용자가 얼마나 손쉽게 원하는 작업을 할 수 있는가와 관련되어 있으며, 시스템의 기능
학습, 효율적인 시스템 사용, 에러 영향의 최소화, 사용자 필요 충족, 신뢰와 만족의 증가가 포함된다.
◎ 비즈니스 품질 속성 (Business Quality Attribute)
* 적시성(Time to Market)
→ 만약 서비스 개시일이 이미 공시적으로 발표되어 소프트웨어 시스템을 런칭해야 하는 일정이 고정
되어 변경될 수 없다거나, 시장의 주도권을 잡기 위해 경쟁사의 제품보다 먼저 출시해야 한다고 할 때
개발 일정을 맞추는 일이 중요해지며, 이것은 아키텍처에 영향을 미치게 된다.
* 비용과예산(Cost and Budget)
→ 아키텍처마다 서로 다른 개발 비용을 산출하게 된다. 일반적으로 유연성이 높은 아키텍처는 그렇지
않은 아키텍처 보다 더 많은 예산이 필요하게 된다.
* 시스템의 내구 연한(Projected Lifetime of the System)
→ 시스템을 얼마나 오랫동안 사용하느냐 하는 것도 아키텍처에 영향을 미친다.
* 목표 시장(Target Market)
→ 범용성을 갖는 소프트웨어라면 기능 뿐만 아니라 시스템이 실행하는 플랫폼도 잠재적인 시장의 크
기를 결정하는 요소가 된다.
* 첫 공개 일정(Rollout Schedule)
→ 첫 버전에서는 기본적인 기능만을 제공하고, 많은 다른 기능들을 이후 버전에서 릴리즈하기로 했다
면 유연성과 확장성이 시스템의 중요한 품질 속성이 될 것이다.
* 기존 시스템과의 통합
→ 새로운 시스템이 기존 시스템과 통합해야 한다면 적절한 통합 메커니즘을 정의하는데 많은 노력을
기울여야 하며, 이것은 아키텍처를 결정하는데 있어서 제약사항으로 작용하게 될 것이다.
◎ 아키텍처 품질 속성 (Architectural Quality Attribute)
* 개념적 무결성(Conceptual Integrity)
→ 모든 레벨에서 시스템의 설계를 단일화하는 주제나 비전을 의미한다. 다시 말해 아키텍처는 유사한
방법으로 유사한 일을 해야 한다는 것이다.
* 정확성과 완료성(Correctness and Completeness)
→ 아키텍처가 시스템의 모든 요구사항과 런타임 자원 제약을 충족시키는 것은 모든 아키텍트가 가지
고 있는 최선의 바람이다.
* 빌드 가능성(Buildability)
→ 적시에 가용 팀에 의해 시스템이 완료되고 개발 진행에 따라 일정한 변경이 허용되도록 한다. 이것은
최대한 병렬식 개발을 통해 원하는 시스템을 손쉽게 구축하는 것을 가리킨다. 이를 위해서는 시스템을
적절하게 모듈로 분할하고, 분할 된 모듈을 적절하게 개발 팀에 분배하고, 모듈과 팀 사이의 종속성을
제한해야 한다.