최근 여러가지 기회를 통해서 알게된 지식들을 공유하고자 하며,
연재의 첫 시간으로, 저의 수십년 software역사에 있어, 아주 놀라운 발견이 되었던 내용을 소개드리고자 합니다.
Summary :
Software design에 영향을 주는 것은 기능적요구사항이 아니라 품질특성임.
그럼에도 불구하고 품질특성은 기존에 비기능적요구사항 이라고 알려졌고, 이런 오해로 인해 주목을 받지 못함.
기능적 요구사항은 단순 할당에 의해서 달성됨.
Software를 설계하는 데 있어서 가장 기본이 되는 3가지는
functional requirements(기능적 요구사항)
Quality attributes(품질 특성)
constraints(제약 사항)
입니다. functional requirement와 constraints는 많이 들어온 건 같은데, quality attribute는 매우 생소합니다. 그렇지만 그동안 우리가
종종 사용해 왔고, 사용하면서도 의문을 가졌던 용어의 다른 표현입니다.
Non functional requirement(이하 NFR) = Quality attribute.(이하 QA).
그럼 왜 이름이 바뀌었을까요?
거의 모든 NFR이 기능적 요구사항(functional requirements)에 관여가 되기 때문에 이름을 바꿀 필요가 있었고,
또한 이 NFR들이 software의 "구조"에 영향을 주고, 결론적으로 software의 품질과 직결이 되기 때문에 QA로 이름을 변경함.
그렇다면 QA에는 어떤 것들이 있고, 어떻게 기술하는 것이 적합할까요?
Availability
Interoperability
Modifiability
Performance
Security
Testability
Usability
Safety
Portability
Scalability
Development Distributability
등이 있습니다. 각각에 대해서는 관련된 design pattern/tactic, 그리고 trade off analysis와 함께 다시 revisit해보겠습니다.
이것을 기술하는 것은 아래와 같습니다.
적어도 위의 내용들이 기술이 되어야지만, 제대로된 QA의 역할을 할 수 있습니다. 이 QA를 통해서
Architect은 design을 할 수 있고, 그 design의 rationale을 만들 수 있습니다. ID부터 measure까지 모든 항목들이 매우 주의 깊게 생각하고 기술해야 하는
내용들입니다. 아래는 위의 표를 이용해서 만든 design의 예제입니다.
다시 위의 표를 보면 scenario라고 되어 있는 부분이 있습니다. 이 부분이 우리가 그동안, 매우 자주..
FR이라고 오해했던 NFR, 즉 QA입니다.
FR과 NFR은 혼돈을 줄 수 있으나, Software의 "구조"에 영향을 준다면 NFR, 즉 QA가 맞습니다.
그럼 FR은?..답은 너무 간단합니다. 그냥 할당(assignment)을 통해서 해결됩니다.
Legacy way와 Architecture driven design의 차이를 보면...
Legacy :
NFR과 FR을 제대로 구분하지 않고 설계를 진행. NFR보다는 FR의 "할당"관점에서 설계를 수행.
그러다 보니, 마지막에 NFR이슈가 발생하고(ex : 성능) 이는 전체 구조의 변경을 수반함. 혹은..
"구조가 너무 많이 바뀌어야 하니, 개선을 못하겠습니다.."라는 상황이 발생.
Architectude driven design
초기에 Software구조에 영향을 주는 요소를 식별.(QA)
QA관점에서 구조를 설계
새로운 QA가 요구사항으로 발생하지 않는 이상 legacy와 같은 문제 발생 우려 적음.
Reference
(1) BCK, Software Architecture in Practice, 2008
Learning by Doing, Smarter than Harder