KR101332879B1 - 아키텍처 전술 지식 기반을 이용한 아키텍처 전술 선택 방법 - Google Patents

아키텍처 전술 지식 기반을 이용한 아키텍처 전술 선택 방법 Download PDF

Info

Publication number
KR101332879B1
KR101332879B1 KR1020120036811A KR20120036811A KR101332879B1 KR 101332879 B1 KR101332879 B1 KR 101332879B1 KR 1020120036811 A KR1020120036811 A KR 1020120036811A KR 20120036811 A KR20120036811 A KR 20120036811A KR 101332879 B1 KR101332879 B1 KR 101332879B1
Authority
KR
South Korea
Prior art keywords
tactic
architecture
architectural
tactics
cost
Prior art date
Application number
KR1020120036811A
Other languages
English (en)
Other versions
KR20130114438A (ko
Inventor
김순태
Original Assignee
강원대학교산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 강원대학교산학협력단 filed Critical 강원대학교산학협력단
Priority to KR1020120036811A priority Critical patent/KR101332879B1/ko
Publication of KR20130114438A publication Critical patent/KR20130114438A/ko
Application granted granted Critical
Publication of KR101332879B1 publication Critical patent/KR101332879B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/28—Error detection; Error correction; Monitoring by checking the correct order of processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45516—Runtime code conversion or optimisation
    • G06F9/45525—Optimisation or modification within the same instruction set architecture, e.g. HP Dynamo

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

본 발명은 소프트웨어 아키텍처 구축 방법에 관한 것으로서, 본 발명은 아키텍처 전술 지식 기반(Tactic knowledge base)을 이용한 아키텍처 전술 선택 방법에 있어서, 유스 케이스 포인트(Use case point)를 이용하여 전술(Tactic) 구현을 위한 비용을 측정하는 비용 측정 단계, 상기 비용 및 비기능 요구사항(Nonfunctional requirement)의 중요도를 기반으로 해당 비기능 요구사항을 만족하는 가장 낮은 비용의 아키텍처 전술을 선택하는 선택 팩터 분석(Selection Factor Analysis) 단계 및 상기 선택된 아키텍처 전술이 적절한지 여부를 검증하기 위한 감도 분석(Sensitivity analysis) 단계를 포함한다. 본 발명에 의하면 정량적인 방법으로 소프트웨어 아키텍처 전술을 선택하는 것이 가능하다는 효과가 있다.

Description

아키텍처 전술 지식 기반을 이용한 아키텍처 전술 선택 방법 {Method for selecting architectural tactics using tactics knowledge base}
본 발명은 소프트웨어 아키텍처 구축 방법에 관한 것으로서, 아키텍처 전술을 기반으로 아키텍처 전술의 비용과 요구사항의 중요도를 고려하여, 주어진 요구사항을 만족하는 정량적인 아키텍처 전술 선택 기법에 관한 것이다.
소프트웨어 아키텍처는 사용자의 성능, 가용성, 보안과 같은 비기능 요구사항(Non-Functional Requirements: NFR)을 만족하기 위하여 다양한 아키텍처 수준의 접근 방법들을 기반으로 소프트웨어의 구조와 주요 행위들을 개발 초기에 결정한다.
아키텍처는 개발 조직을 구성하거나, 개발 계획을 수립하고, 소요 비용 및 리스크 예측, 통합 계획등을 수립하는데 핵심적인 입력물로 사용된다. 그러므로, 개발 초기에 결정된 아키텍처 구축 방법은 소프트웨어 프로젝트의 성공에 있어서 중요한 고려사항이 된다. 그럼에도 불구하고, 소프트웨어 아키텍처 구축 방법의 결정은 전문가의 경험을 기반으로 임의의 방법으로 이루어 지고 있는 실정이다.
이 문제를 해결하기 위하여 종래 여러 연구가 진행되어 왔다. 이는 크게 두가지 종류로 나누어 볼 수 있다.
첫번째 접근 방법은 프로세스적 접근 방법으로 비기능 요구사항을 달성하기 위한 아키텍처 구축 방법을 선택하기 위한 절차와 산출물 등을 제안하고 있다. 이 방법은 후보 아키텍처 구축 기법들 중 보다 나은 방법을 선택하기 위한 아키텍트들의 활동은 제안하고 있으나, 후보 아키텍처 구축 방법에 대한 제안은 제공하고 있지 않다.
다른 접근 방법은 Analystic Hierarchy Process (AHP)를 통하여 정량적으로 품질 요구사항의 중요도와 아키텍처 구축 기법의 기여도를 계산하고, 품질 요구사항을 가장 잘 달성하기 위한 후보 구축 기법을 여러 수식을 통하여 계산하였다. 하지만, 이 방법은 후보 아키텍처 혹은 아키텍처 구축 방법의 상세한 특성에 대해서 고려하지 않은 채 아키텍트가 각 방법의 소요비용에 대해서 임의로 평가하고 있다는 단점이 있다.
본 발명은 상기와 같은 문제점을 해결하기 위하여 안출된 것으로서, 본 발명에서는 선행 연구인 아키텍처 전술 기반(Architecrtural Tactic Knowledge Base)으로부터 각 아키텍처 전술의 비용과 요구사항의 중요도를 고려하여, 주어진 요구사항을 만족하는 정량적인 아키텍처 전술 선택 기법을 제안하는데 그 목적이 있다.
본 발명의 목적은 이상에서 언급한 목적으로 제한되지 않으며, 언급되지 않은 또 다른 목적들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.
이와 같은 목적을 달성하기 위한 본 발명은 아키텍처 전술 지식 기반(Tactic knowledge base)을 이용한 아키텍처 전술 선택 방법에 있어서, 유스 케이스 포인트(Use case point)를 이용하여 전술(Tactic) 구현을 위한 비용을 측정하는 비용 측정 단계, 상기 비용 및 비기능 요구사항(Nonfunctional requirement)의 중요도를 기반으로 해당 비기능 요구사항을 만족하는 가장 낮은 비용의 아키텍처 전술을 선택하는 선택 팩터 분석(Selection Factor Analysis) 단계 및 상기 선택된 아키텍처 전술이 적절한지 여부를 검증하기 위한 감도 분석(Sensitivity analysis) 단계를 포함한다.
상기 비기능 요구사항의 중요도는 AHP(Analytic Hierarchy Process)를 사용하여 예측하는 것일 수 있다.
상기 비용 측정 단계는, 유스 케이스(Use case)를 사용하여 아키텍처 전술을 재 모델링하고, 유스 케이스 포인트를 이용하여 재 모델링된 각 아키텍처 전술의 비용을 측정할 수 있다.
상기 비용 측정 단계에서 유스 케이스 포인트는, UUCP(Unadjusted Use Case Point) 측정 단계, TCF(Technical Complexity Factor) 측정 단계 및 환경(Environmental) 측정 단계 순으로 측정할 수 있다.
상기 선택 팩터 분석 단계는, 상기 아키텍처 전술 기반 및 아키텍처 경험 기반을 이용하여 후보 아키텍처 전술을 선정하는 단계, 비기능 요구사항의 중요도 및 상기 선정된 후보 아키텍처 전술의 기여도를 측정하는 단계 및 상기 비기능 요구사항의 중요도 및 상기 선정된 후보 아키텍처 전술의 기여도를 이용하여 선택 팩터를 측정하는 단계를 포함하여 이루어질 수 있다.
상기 선택 팩터를 측정하는 단계에서, 선택 팩터(Selection Factor, SF) SFi가 비기능 요구사항의 n개의 후보 아키텍처 전술 중에서 i번째 아키텍처 전술 기여도이고, i번째 아키텍처 전술의 기여도(Architecture Technical Complexity Factor)를 ATCFi, i번째 전술 유스 케이스 포인트(Tactic Use Case Point)를 TUCPi라 할 때,
Figure 112013074920707-pat00001
의 수학식을 사용하여 선택 팩터를 계산할 수 있다.
본 발명에 의하면 정량적인 방법으로 소프트웨어 아키텍처 전술을 선택하는 것이 가능하다는 효과가 있다.
또한, 본 발명에 의하면, 선택된 소프트웨어 아키텍처 전술의 실체화 비용 산정이 가능하며, 아키텍처 전술 선택의 과정에서 전문가의 주관이 개입되는 요소에 대하여 이를 보정할 수 있는 메커니즘을 두어 선택에 대한 자신감의 정도를 정량적으로 보정할 수 있는 효과가 있다.
도 1은 본 발명의 일 실시예에 따른 아키텍처 전술 선택 방법의 개요를 보여주는 도면이다.
도 2는 본 발명의 일 실시예에 따른 비용 측정 단계를 보여주는 흐름도이다.
도 3은 본 발명의 일 실시예에 따른 선택 팩터 분석 단계를 보여주는 흐름도이다.
도 4는 본 발명의 일 실시예에 따른 아키텍처 전술 시멘틱으로부터 유스 케이스 다이어그램 추출 기법을 설명하기 위한 도면이다.
이하, 첨부된 도면을 참조해서 본 발명의 실시예를 상세히 설명하면 다음과 같다. 우선 각 도면의 구성 요소들에 참조 부호를 부가함에 있어서, 동일한 구성 요소들에 한해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 그리고, 본 발명을 설명함에 있어서, 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 명세서 전반에 걸쳐서, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라, 다른 구성요소를 더 포함할 수 있다는 것을 의미한다.
본 발명의 아키텍처 전술 기반을 이용한 아키텍처 전술 선택 방법은 크게 네 단계로 이루어진다. 그 방법은 첫째, 각 아키텍처 전술은 Use Case를 사용하여 재모델링하고, Use Case Point를 사용하여 그 비용을 측정한다. 둘째, 주어진 비기능 요구사항의 중요도는 AHP(Analytic Hierarchy Process)를 사용하여 예측한다. 셋째, 각 아키텍처 전술의 비용과 비기능 요구사항의 중요도를 기반으로 해당 비기능 요구사항을 만족하는 가장 저 비용의 아키텍처 전술을 선택한다. 넷째, 선택된 전술이 적절한지 감도 분석(Sensitivity Analysis) 기법을 사용하여 검증한다.
이제 본 발명에서의 아키텍처 전술 기반에 정의된 아키텍처 전술의 소요 비용을 Use Case Point를 사용하여 측정하고, 이를 바탕으로 정량적인 아키텍처 전술의 선택 기법을 설명하기로 한다.
도 1은 본 발명의 일 실시예에 따른 아키텍처 전술 선택 방법의 개요를 보여주는 도면이다.
도 1을 참조하면, 아키텍처 전술 선택 기법은 비기능 요구사항(10)과 아키텍처 전술 지식 기반(20)을 바탕으로 시작되며, 선택된 아키텍처 전술이 결과물이 된다.
본 발명에서는 아키텍처 전술을 선택하기 위하여 제안하는 방법은 세 단계로 이루어져 있다.
첫째, 유스 케이스 포인트(Use Case Point)를 사용한 전술(Tactic) 구현을 위한 비용을 측정하는 단계(S100)이다.
둘째, 선택된 후보 아키텍처 전술로부터 소요되는 노력과 비기능 요구사항의 만족성 여부를 평가하기 위한 선택 팩터(Selection Factor) 분석 단계(S200)이다.
셋째, 감도 분석(Sensitivity Analysis)을 통하여 비용과 만족성의 평가가 적절했는지를 검증하는 단계(S300)이다.
이렇게 검증 단계가 수행된 후에 최종적으로 아키텍처 전술을 선택한다(40).
이제 본 발명의 아키텍처 전술 선택 방법의 각 단계에 대해서 상세히 설명하기로 한다.
도 2는 본 발명의 일 실시예에 따른 비용 측정 단계를 보여주는 흐름도이다.
도 2를 참조하면, 본 발명의 비용 측정 단계(S100)는 아키텍처 전술 기반의 각 아키텍처 전술의 유스 케이스 포인트(Use Case Point)를 측정하는 단계이다.
Use Case Point는 시스템 개발 초기에 Use Case를 사용하여 소프트웨어의 비용을 측정하는 방법이다.
도 2에서 Use Case Point를 이용한 비용 측정 단계(S100)는 Unadjusted Use Case Point(UUCP)를 측정하는 단계(S101)와, Technical Complexity Factor(TCF)를 측정하는 단계(S103)와, 환경(Environmental) 측정 단계 (S105) 순으로 이루어진다.
Use Case Point는 Use Case 다이어그램과, Use Case 명세서를 필요로 한다. 아키텍처 전술 기반은 이미 Use Case 다이어그램과, Use Case 명세서보다 자세한 분석 모델을 이미 포함하고 있다. 그래서, 이를 사용하여 Use Case Point 식별에 필요한 정보를 역으로 이끌어 낼 수 있다.
본 발명에서 Use Case Point를 측정하기 위해서 Use Case와 Actor의 개수, 이들간의 Transaction 개수, 그리고 Actor의 Use Case와의 상호작용 방식에 대한 정의가 필요하다. 이러한 정보는 아키텍처 전술 기반의 구조를 명세하는 SPS(Structural Modeling Language)와 행위를 명세하는 IPS(Interaction Pattern Specification)로부터 식별이 가능하다.
다음은 아키텍처 전술 기반으로부터 유스 케이스를 추출하기 위한 가이드라인이다.
본 발명에서 유스 케이스(Use Case) 식별 과정은 다음과 같다.
IPS의 Interaction Fragment 당 하나의 Use Case를 식별한다.
하나의 Interaction Fragment 에 parallel combined fragment 가 존재하는 경우, 즉 병렬적으로 수행되는 경우 별도의 Use Case 로 식별한다.
본 발명에서 Actor 식별 과정은 다음과 같다.
IPS에 Time Event를 기반으로 주기적인 행위를 하는 경우 이를 Timer Actor 로 식별한다.
SPS에 개발 범위 이외의 타 시스템이 존재하면 이를 Actor로 식별한다.
Activation 하는 주체가 명확치 않으면 Client Actor를 식별한다.
본 발명에서 트랜잭션(Transaction) 개수 식별 과정은 다음과 같다.
IPS 의 모든 메시지(Message)는 트랜잭션(Transaction)이다.
IPS 내의 Reference(ref) Fragment 내의 메시지(Message)도 트랜잭션(Transaction)이다.
도 4는 본 발명의 일 실시예에 따른 아키텍처 전술 시멘틱으로부터 유스 케이스 다이어그램 추출 기법을 설명하기 위한 도면이다. 도 4는 본 발명의 가이드라인에 따라 아키텍처 전술 시멘틱으로부터 유스 케이tmUse Case) 다이어그램을 추출하는 과정을 보여준다.
도 4의 좌측의 SPS와 IPS는 가용성 품질 향상을 위한 아키텍처 전술인 Ping/Echo의 시맨틱이다.
전술한 가이드라인에 따라 Actor는 Fault Monitor와 Timer Actor가 식별을 할 수 있으며, 하나의 Interaction Fragment가 존재하므로 하나의 Use Case가 식별된다.
그리고, Ping/Echo의 시멘틱은 |ping()과 |echo() 두개의 메시지롤만 정의되어 있으나, NotifyException Reference내에 2개의 메시지가 더 존재하므로 총 4개의 Transaction이 존재한다.
이와 같은 방법으로 아키텍처 전술 시멘틱으로부터 식별된 Use Case, Actor 와 Transaction 을 사용하여 Use Case Point 기법으로 비용 측정이 가능하다.
각 아키텍처 전술의 Use Case Point를 계산하기 위한 다음 단계로 TCF를 계산한다(S103).
Factor Description Weight Ping/Echo 평가
T1 Distributed system 2 5
T2 High Response time 2 4
T3 End-user efficiency 1 2
T4 Complex processing 1 1
T5 Reusable code 1 0
T6 Easy to install 0.5 3
T7 Easy to use 0.5 3
T8 Protable 2 4
T9 Easy to change 1 0
T10 Concurrent use 1 5
T11 Security 1 1
T12 Access to third parties 1 1
T13 Training needs 1 0
Calculated TCF 0.95
TCF측정을 위하여 표 1과 같은 평가 항목을 제안한다.
각 항목에 대해서 0(irrelevant)부터 5(very important)까지의 6개 중 하나의 Scale Factor를 할당한 후, Weight과 Scale Factor를 곱하여 TFactor를 측정한다.
TCF는 특정 비기능 요구사항을 다루는 솔루션으로서의 아키텍처 전술의 특성을 반영하는 척도이다.
예를 들면, Ping/Echo 아키텍처 전술은 하나 이상의 프로세스가 구동되는 환경을 전제로 Ping과 Echo 메시지를 통하여 대상 시스템이 가용한지 여부를 파악하는 전술이고, 이는 일반적으로 분산 시스템과 유사한 환경이므로, T1 Factor인 ‘Distributed system’은 5로 평가하였다. 응답 시간의 지연은 곧 대상 시스템의 가용성 판단에 직접적인 영향을 미치지만, 이것이 시스템의 처리 중에서 가장 우선순위가 높은 대상이 아니기에 ‘High Response Time’ 항목에서는 4로 평가하였다. 또한, Ping/Echo 전술은 오류탐지 기법이므로, 원래 시스템이 처리해야 하는 일을 지원하는 기능이다.
그러므로, 별도의 Thread로 동작하는 것이 일반적이기 때문에 ‘Concurrent Use’ 항목은 5로 평가된다.
이와 같이 아키텍처전술의 특성을 기반으로 아키텍처 전술 기반에 위치한 모든 아키텍처 전술의 TCF를 계산한다. 전술한 Ping/Echo와 같이 가용성 아키텍처 전술이라면 보통 T1(Distributed System), T2(High Response Time), T8(Portable), T10(Concurrent Use)와 같은 TFactor가 중요하게 평가될 것이고, ID/Password, Maintain Data Confidentiality와 같은 보안 아키텍처 전술은 T11(Security)가 중요하게 여겨지는 것뿐만 아니라, 특성에 따라서 T1(Distributed System)과 T12(Access to third parties)가 중요하게 평가될 수 있다. [표 1]을 기반으로 TCF= 0.6 + (0.01×TFactor) = 0.6 + (0.01×39) = 0.95 가 계산된다.
아키텍처 전술마다의 특성을 일반화 할 수 있는 TCF와 다르게, Environmental Factor는 프로젝트의 참여자의 익숙함을 의미하므로, 이는 프로젝트 마다 상이하다. 본 발명에서는 Environmental Factor의 모든 항목을 중간 점수인 3으로 일괄적으로 할당하고, EF를 계산하여 0.995의 값을 얻는다.
이제 본 발명의 일 실시예에 따른 선택 팩터를 분석하는 단계(S200)에 대하여 상세히 설명하기로 한다.
도 3은 본 발명의 일 실시예에 따른 선택 팩터 분석 단계를 보여주는 흐름도이다.
본 발명에서 선택 팩터(Selection Factor) 측정 단계(S200)는 후보 아키텍처 전술의 Use Case Point를 고려하여, 주어진 비기능 요구사항을 만족하기 위한 저비용, 고 만족 아키텍처 전술을 정량적인 방법으로 선택하는 단계이다.
도 3을 참조하면, 선택 팩터 분석 단계(S200)는 후보 아키텍처 전술 선정 단계(S201)와, 비기능 요구사항(10)의 중요도 및 아키텍처 전술 기여도 측정 단계(S203)와, 선택 팩터(Selection factor) 측정 단계(S205)의 세 단계로 이루어진다.
먼저, 후보 아키텍처 전술 선정 단계(S201)는 다음과 같다.
후보 아키텍처 전술은 아키텍처 전술 기반과 아키텍트의 경험을 기반으로 선정한다. 기본적으로 특정 비기능 요구사항에 대하여 아키텍처 전술 기반에서 소개한 모든 아키텍처 전술이 비기능 요구사항을 해결하기 위한 후보 아키텍처 전술이 될 수 있다. 하지만, 이는 아키텍트의 경험에 따라서 그 후보가 축소될 수 있으며, 이는 후보 검색 대상을 줄이는데 기여한다. 예를 들어 가용성의 비기능 요구사항 중 Fault Detection에 대한 요구사항이 존재한다고 할 때, 가용성 아키텍처 전술 전체가 후보 아키텍처 전술로 선택될 수도 있고, 아키텍트의 경험에 의해서 Fault Detection에 존재하는 Exception, Ping/Echo와 Heartbeat 아키텍처 전술과 이들간의 조합인 Ping/Echo+Heartbeat 등이 후보 아키텍처 전술로 선택될 수도 있다.
만약 특정 비기능 요구사항을 달성하기 위한 후보 아키텍처 전술이 아키텍처 전술 기반에 존재하지 않는다면, 후보 아키텍처 전술을 확장할 수 있다.
다음, 비기능 요구사항의 중요도와 아키텍처 전술 기여도 측정 단계(S203)를 설명하면 다음과 같다.
S201 단계에서 선정된 아키텍처 전술들은 비기능 요구사항의 중요도와 아키텍처 전술이 해당 비기능 요구사항을 얼마나 만족할 수 있는지에 따라서 선택이 결정될 수도 있고, 아닐 수도 있다. 먼저 각 비기능 요구사항의 중요도를 측정하기 위하여 본 발명에서는 AHP(Analystic Hierarchy Process)를 사용하여 각 비기능 요구사항의 상대적인 중요도를 측정한다. AHP는 측정 대상간의 상대적인 가중치 또는 중요도 등을 정량적으로 평가하기 어려울 때, 대상 간의 쌍대 비교(Pair-wise comparison)를 통해서 이를 측정하는 기법이다.
본 발명에서 아키텍처 전술 기여도는 하나의 비기능 요구사항에 대하여 각각의 후보 아키텍처 전술을 사용하면 어느 정도 해당 비기능 요구사항을 달성할 수 있는지를 정성적으로 측정한 값이다.
다음, 선택 팩터(Selection Factor) 측정 단계(S205)를 설명하면 다음과 같다.
선택 팩터(Selection Factor)는 아키텍처 전술을 선택하기 위한 결과 값으로, 아키텍처 전술의 기여도, 아키텍처 전술별 Use Case Point를 사용하여 다음의 [수학식 1]을 사용하여 계산한다.
Figure 112012028227109-pat00002
수학식 1은 후보 아키텍처 전술마다 계산된다.
수학식 1에서 Selection Factor(SF)는 비기능 요구사항의 n개의 후보 아키텍처 전술 중에서 i번째 아키텍처 전술 기여도, 즉 아키텍처 전술의 기여도(Architecture Technical Complexity Factor, ATCFi)가 높을수록 SF는 높아지며, 아키텍처 전술, 즉 전술 유스 케이스 포인트(Tactic Use Case Point, TUCPi)이 낮을수록 SF는 높아진다.
수학식 1을 기반으로, n개의 후보 아키텍처 전술 중에서 SF가 가장 높은 아키텍처 전술을 선택하는 것이 가장 적은 비용(TUCP)으로 가장 높은 만족도(ATCF)를 달성할수 있는 아키텍처 전술이라고 평가할 수 있다. 또한, 선택한 아키텍처 전술을 사용하면 해당 시스템은 비기능 요구사항을 ATCF 만큼 만족할 수 있으리라 예상할 수 있다.
이제 본 발명의 일 실시예에 따른 감도 분석 단계(S300)을 상세히 설명하면 다음과 같다.
전술한 아키텍처 전술 선택 과정은 아키텍처 전술 기여도(ATCF)의 주관적인 측정 결과에 따라서 그 선택이 변할 수 있다는데 취약점이 있다. 이를 보완하기 위하여 감도 분석(Sensitivity Analysis)를 통하여 선택의 신뢰성을 높일 수 있다.
본 발명에서 감도 분석(Sensitivity Analysis)은 선택의 결과가 변하지 않는 상태에서 할당할 수 있는 아키텍처 전술 기여도의 범위를 측정할 수 있게 해준다. 즉, 이는 하나의 후보 아키텍처 전술에서 선택을 보장하는 아키텍처 전술 기여도 측정 범위를 제공하여, 얼마나 해당 아키텍처 전술 선택에 신뢰성이 있는지 파악할 수 있는 정량적인 근거를 제공해준다.
다음 [수학식 2]는 특정 NFR에 대하여 n개의 후보 아키텍처 전술(T1…Tn)이 있고, 이중 k번째 아키텍처 전술 Tk를 선택한 경우 Tk의 아키텍처 전술 기여도의 Sensitivity SensATCF(Tk)을 계산하기 위한 수식이다.
이때 SensATCF(Tk)은 선택한 아키텍처 전술 Tk가 최소한 값 SensATCF(Tk)이상의 아키텍처 전술 기여도를 할당한다면 아키텍처 전술 Tk의 선택에는 변함이 없다는 것을 확신시켜 준다.
Figure 112012028227109-pat00003
이상 본 발명을 몇 가지 바람직한 실시예를 사용하여 설명하였으나, 이들 실시예는 예시적인 것이며 한정적인 것이 아니다. 본 발명이 속하는 기술분야에서 통상의 지식을 지닌 자라면 본 발명의 사상과 첨부된 특허청구범위에 제시된 권리범위에서 벗어나지 않으면서 다양한 변화와 수정을 가할 수 있음을 이해할 것이다.
10 비기능 요구사항 20 전술 지식 기반
30 후보 아키텍처 전술 40 전술 선택

Claims (6)

  1. 아키텍처 전술 지식 기반을 이용한 아키텍처 전술 선택 방법에 있어서,
    유스 케이스 포인트(Use case point)를 이용하여 전술 구현을 위한 비용을 측정하는 비용 측정 단계;
    상기 측정된 비용과 비기능 요구사항의 중요도를 기반으로 해당 비기능 요구사항을 만족하는 가장 낮은 비용의 아키텍처 전술을 선택하는 선택 팩터 분석(Selection Factor Analysis) 단계; 및
    상기 선택된 아키텍처 전술의 감도를 분석하기 위한 감도 분석 단계를 포함하되,
    상기 선택 팩터 분석 단계는,
    상기 아키텍처 전술 기반 및 아키텍처 경험 기반을 이용하여 후보 아키텍처 전술을 선정하는 단계;
    비기능 요구사항의 중요도 및 상기 선정된 후보 아키텍처 전술의 기여도를 측정하는 단계; 및
    상기 비기능 요구사항의 중요도 및 상기 선정된 후보 아키텍처 전술의 기여도를 이용하여 선택 팩터를 측정하는 단계를 포함하여 이루어지고,
    상기 선택 팩터를 측정하는 단계에서,
    선택 팩터(Selection Factor, SF) SFi가 비기능 요구사항의 n개의 후보 아키텍처 전술 중에서 i번째 아키텍처 전술 기여도이고, i번째 아키텍처 전술의 기여도(Architecture Technical Complexity Factor)를 ATCFi라 하고, i번째 전술 유스 케이스 포인트(Tactic Use Case Point)를 TUCPi라 할 때,
    Figure 112013074920707-pat00009

    의 수학식을 사용하여 선택 팩터를 계산하는 것을 특징으로 하는 아키텍처 전술 선택 방법.
  2. 제1항에 있어서,
    상기 비기능 요구사항의 중요도는 AHP(Analytic Hierarchy Process)를 사용하여 예측하는 것임을 특징으로 하는 아키텍처 전술 선택 방법.
  3. 제1항에 있어서,
    상기 비용 측정 단계는,
    유스 케이스(Use case)를 사용하여 아키텍처 전술을 재 모델링하고, 유스 케이스 포인트를 이용하여 재 모델링된 각 아키텍처 전술의 비용을 측정하는 것을 특징으로 하는 아키텍처 전술 선택 방법.
  4. 삭제
  5. 삭제
  6. 삭제
KR1020120036811A 2012-04-09 2012-04-09 아키텍처 전술 지식 기반을 이용한 아키텍처 전술 선택 방법 KR101332879B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020120036811A KR101332879B1 (ko) 2012-04-09 2012-04-09 아키텍처 전술 지식 기반을 이용한 아키텍처 전술 선택 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020120036811A KR101332879B1 (ko) 2012-04-09 2012-04-09 아키텍처 전술 지식 기반을 이용한 아키텍처 전술 선택 방법

Publications (2)

Publication Number Publication Date
KR20130114438A KR20130114438A (ko) 2013-10-17
KR101332879B1 true KR101332879B1 (ko) 2013-11-25

Family

ID=49634478

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020120036811A KR101332879B1 (ko) 2012-04-09 2012-04-09 아키텍처 전술 지식 기반을 이용한 아키텍처 전술 선택 방법

Country Status (1)

Country Link
KR (1) KR101332879B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104575522B (zh) * 2015-01-14 2018-02-06 北京理工大学 一种用于语音质量网络主观测听的听音人等级评定方法

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
정창해 외 2인, "아키텍처 모델링을 위한 유스케이스 기반의 요구사항 정량화 기법", 한국컴퓨터종합학술대회 2005 논문집 Vol.32, No. 1(B), 2005 *
정창해 외 2인, "아키텍처 모델링을 위한 유스케이스 기반의 요구사항 정량화 기법", 한국컴퓨터종합학술대회 2005 논문집 Vol.32, No. 1(B), 2005*
최현숙, "규모 및 복잡도를 고려한 설계전술 선정 방법", 서강대학교 정보통신대학원 소프트웨어공학 전공, 공학석사 학위논문, 2010. *
최현숙, "규모 및 복잡도를 고려한 설계전술 선정 방법", 서강대학교 정보통신대학원 소프트웨어공학 전공, 공학석사 학위논문, 2010.*

Also Published As

Publication number Publication date
KR20130114438A (ko) 2013-10-17

Similar Documents

Publication Publication Date Title
US8700418B2 (en) Method and system for acquiring high quality non-expert knowledge from an on-demand workforce
US7904270B2 (en) System for estimating and improving test case generation
Spinner et al. Evaluating approaches to resource demand estimation
Meneely et al. Predicting failures with developer networks and social network analysis
US9529700B2 (en) Method of optimizing execution of test cases and a system thereof
Rahmandad et al. Modeling the rework cycle: capturing multiple defects per task
Cuellar et al. Ideational influence, connectedness, and venue representation: Making an assessment of scholarly capital
Wickramanayake et al. Building interpretable models for business process prediction using shared and specialised attention mechanisms
Borrego et al. Diagnosing correctness of semantic workflow models
Foucault et al. On the usefulness of ownership metrics in open-source software projects
González-Huerta et al. Non-functional requirements in model-driven software product line engineering
Potts et al. A network perspective on assessing system architectures: Robustness to cascading failure
Ullah A method for predicting open source software residual defects
Erdoğan et al. More effective sprint retrospective with statistical analysis
Malathi et al. Analysis of size metrics and effort performance criterion in software cost estimation
Silva Ouriques et al. Revealing influence of model structure and test case profile on the prioritization of test cases in the context of model-based testing
KR101332879B1 (ko) 아키텍처 전술 지식 기반을 이용한 아키텍처 전술 선택 방법
Sehgal et al. Predicting faults before testing phase using Halstead’s metrics
Alghamdi et al. BPR: evaluation of existing methodologies and limitations
Aktaş et al. An introduction to software testing methodologies
Ferme et al. Performance comparison between BPMN 2.0 workflow management systems versions
Walworth et al. Estimating project performance through a system dynamics learning model
Mishra et al. Multi release cost model—a new perspective
Hou et al. Using hierarchical scenarios to predict the reliability of component-based software
Jakhar et al. Measuring complexity, development time and understandability of a program: A cognitive approach

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20160927

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20181219

Year of fee payment: 6