The ATAM helps a system's stakeholders understand the consequences of architectural decisions with respect to the system's quality attribute requirements and business goals. It helps stakeholders determine where the risks and tradeoffs exist in elicited architectural strategies with rather low investment. However, because the ATAM doesn't provide any guidance for understanding economic benefits, it needs to be complemented by another quantitative approach such as CBAM (Cost Benefit Analysis Method) to permit deterministic reasoning in making architectural decisions.
The CBAM helps software architects consider the return on investment of any architectural decision and provides guidance on the economic tradeoffs involved. Its purpose is to give an economic framework within which the stakeholders can make a rational architectural decision, through the elicitation and documentation of the costs, benefits, and uncertainty for their architectural investments.
In this dissertation, the ATAM process we conducted in our studio project was analyzed to evaluate flow we properly adjusted it to our project situation and to analyze what we did well and what could have done better. The analysis shows that if the ATAM process can be properly adjusted, the ATAM can give its own benefit to a small case like a studio project that has limited resources in terms of time and workforce, as well as to a large project. The analysis here will help us to adapt the ATAM more effectively in the future and guide beginners to maximize the benefit of their first ATAM evaluation.
In addition, the CBAM evaluation for PMCenter system was conducted on the outputs of the ATAM in the studio project. The goals of this evaluation are primarily to experience the CBAM process itself and to justify our decision of .Net over J2EE for the architecture framework in out studio project. Though the evaluation was performed with several restrictions and assumptions, the whole experience showed how the application of economic techniques can effectively complement the ad-hoc qualitative approach by providing disciplined processes to frame and structure qualitative discussions.
The evaluation process shows how the CBAM can be applied to the ATAM outputs, how some process steps can be customized to fit far the case, and finally how the CBAM concludes. The intention of this trial is not to deliver another good practice to apply the CBAM. This evaluation is focused on showing how the CBAM can be adapted to give the economic advice in the architectural decision with low investment. In addition, this evaluation shows the possibility that key stakeholders such as an architect can use the CBAM with low effort investment to support and confirm their decisions, as well as persuade upper-level decision makers to accept them.
ATAM은 시스템 이해관계자들은 개발 초기에 비교적 적은 노력의 투자로 고려중인 아키텍처에 내재된 위험요소나 트레이드오프를 식별할 수 있도록 도와준다. 그러나, 이는 정성적인 분석으로 아키텍처 결정에 따른 비용과 효과 측면을 정확하게 비교하기 어려우므로 CBAM 과 같은 정량적 분석으로 보완하는 것이 바람직하다.
CBAM은 시스템 이해관계자들이 아키텍처를 결정하는데 있어 ROI를 고려할 수 있는 체계적인 프로세스를 제공한다. 이는 아키텍처에 대한 투자에 있어 비용과 효과, 불확실성들을 도출하고 문서화함으로써 시스템 이해관계자들이 합리적인 의사결정을 하는데 토대가 될 경제적인 모델을 제공하는 것이다.
이 논문에서는 우리가 스튜디오 프로젝트에서 수행했던 ATAM 프로세스를 되짚어 봄으로써 ATAM프로세스를 프로젝트 상황에 적절하게 적용하였는지를 평가하고 잘 되었던 점과 부족했던 점을 분석해 보았다. 이 결과는 ATAM프로세스를 적절히 커스터마이징 한다면 큰 프로젝트뿐만이 아니라 시간과 인력 면에서 제약이 심한 스튜디오 프로젝트와 같은 소규모의 프로젝트에도 ATAM의 이점을 충분히 활용할 수 있음을 보여 주었다. 이런 분석 과정은 우리가 향후 다른 사례에서 ATAM를 적용할 때 보다 효과적인 접근이 가능하게 하는 토대가 될 것이고, 다른 ATAM초보자들이 ATAM을 시도할 때 참조하여 ATAM의 효과를 최대화할 수 있으리라 기대된다.
또한 이 논문에서는 ATAM 결과를 토대로 CBAM프로세스를 수행해 보고 그 과정과 결과를 분석하였다. 이는 크게 CBAM 프로세스 자체를 경험하는 것과 우리가 스튜디오 프로젝트에서 J2EE 대신 .Net 을 주요 아키텍처 프레임워크로 선택했던 것이 적절했는지를 역으로 확인해 보기 위한 것이었다. 즉, CBAM이 ATAM의 정성적인 분석 결과를 어떻게 보완할 수 있는지 직접 경험하는 것과 CBAM 을 적용해서 아키텍처 결정을 보다 합리적으로 할 수 있는지를 검증해 보기 위한 것이다. 이 평가는 실험 환경에서 이미 많은 제약사항과 가정들을 요구했지만 평가 프로세스를 한단계씩 수행하는 과정은 ad-hoc한 정성적 접근법에 비해 보다 체계적이며 구조화된 형태의 접근법을 보여준다는 데 의의가 크다.
전체적인 평가 프로세스는 CBAM이 어떻게 ATAM결과에 적용될 수 있는지와 몇몇 프로세스 절차들이 주어진 사례에 적절하게 커스터마이징될 수 있는지를 보여준다. 이 논문은 CBAM을 적용한 또 하나의 사례를 제공하는 것이 목적이 아니라 CBAM 이 어떻게 적은 투자로 아키텍처 결정에 있어 합리적인 경제적 제언을 제공할 수 있는가를 보이고자 한다. 또한 이러한 시도는 아키텍트와 같은 아키텍처 평가에 있어 핵심 이해관계자가 자신들의 결정을 지지하고 확신하기 위한 목적이나 상위 의사결정자들을 설득하는 도구로 저렴하게 사용할 수 있음을 시사한다.
