먼저, Spring 프레임워크에 대해서 다음 세 정도의 주제를 잡으면 좋을 듯 합니다.
1. 내부 backbone 인 OSGi 소개
2. Spring Framework을 통한 개발 Process/개발 지원 툴
3. Spring Framework을 적용한 금융권 사례(Enterprise 규모의 적용 사례 및 Tip)
이상입니다.
제1주제는 정확한 이해가 없이 활용만 하는 현실 상황에서, spring 의 내부 핵심 구조에 대한 설명 필요(결국, Spring의 아키텍처에 대한 설명이 될 것 입니다.)
제2주제는 좀 더 활발한 대화 주제가 될 것 같습니다. 어떻게(How) 적용/구현할 것인지의 주제 입니다.
제3주제는 이런 Open Source를 대규모/Real--time 요구에 대해서 적용한 사례가 있는지.. 에 대한 내용 입니다.
아마도, 이 주제에서, 아키텍처 요구사항 분석에 의해서 결정되었는지, 오픈소스이기 때문에 적용한 것인지의 이야기 즉, 어제 내용의 연장선상에서 이야기가 될 듯 합니다.
(이상은 삼성SDS 임성현 책임께서 주신 의견입니다)
윤태권

11월 정기 세미나 내용을 요약합니다.

감사합니다.

SW 아키텍트 연합회 11월 정기 세미나

주제: SW 아키텍처의 품질속성, ATAM/Feature의 정의와 상호 관계성

일시 : 2008년 11월 19일 19:00 ~ 22:00 ~ 24:00

장소 : 강남역 비트 교육센터(본관)

참여 인원 : 대략 15명 규모

주요 내용

Track 1 : 홈 네트워크 시스템 사례에서의 품질속성, ATAM, Feature의 정의와 상호 관계성(삼성전자 김선형 책임)

-         ATAM, Feature 사례 중심 설명 : S사 HV(Apt내의 기기제어, 화상통화, 출입통제 시스템)

* 성장 과장

-         1.0(제품화) -> 2.0(RUP기반 구조화) -> 2.5(Layer세분화, Product Line 적용)

-         2.5에서 비로소 건설사 요구사항, 외부 환경변화에 빠른 대응 가능

* Feature 선정 과정

-         기존 Feature(사례)는 단순 제어(기기 on/off) -> 복잡한 제어 필요

-         이에 따른 요구사항을 Actor(거주자:활용 , 경비원:방범, 관리자:검침제어)별로 세분화 -> 총 59개 유스케이스

-         이슈 : 공통 컴포넌트 작성을 위해서 Feature를 잘 나눠야 한다(시행착오 다수)

* Feature 예시

* ATAM 통한 선정된 품질 속성(정의 단어에 대한 의미해석 동일화 진행함)

-         하기 내용은 담당자(개발자) 투표를 통해서 선정함.

-         (1) Flexibility: 건설사 요구

-         (2) Availability: 서버 다운시에도 서비스 제공 이슈

-         (3) Performance: 신속한 응답(3초 이내…)

* Feature 관리

-         초기 선정 이후 지속적으로 개선 수행(버전업 때 마다)

-         각 시나리오 별로 수행함

* 수행원 들의 소감

-         너무 논리위주로, 분석/구현시 지속 보완 필요함

-         Pjt 초기부터 전체적 총괄 필요함

-         아키텍처에 대한 생각(idea)를 토론하고 구체화 하는 과정으로 매우 유익

Track 2 : 현장 프로젝트 사례에서의 품질속성, 시나리오 정의 사례와 ATAM, Feature와의 상호 관계성(SDS 장세영 책임)

-         SI측면 사례

* 각 사이트의 특성(품질 속성상 유형)

-         A사 : 다수 인터넷 사용자/ 성능은 수입과 직결

-         B사: IT부서의 유지보수 용의성

* 공통적 어려움 

-         비기능 요구사항은 ‘수집’이 가장 어렵다(고객 의견: 품질은 모두 최고이어야 한다)

-         비기능 요구사항의 계량화 실시도 어렵다(내부 사용자, 외부 사용자, 서버관리자 등 이해 관계에 따른 해석이 다름)

-         따라서, 가시화 필요 -> 품질속성 시나리오를 통한 근저자료 확보

-         비기능 요구사항(지루한 인터뷰) 아키텍처 속성(기술적 이슈)선별 à 의사결정에 영향을 주는 것/ 가능선을 기준으로 선별 작업 수행

* 품질 유스케이스 활용

-         품질 시나리오 작성시 유스케이스 시나리오 기법을 활용함

-         유스케이스와 품질 유스케이스를 멥핑 -> 기능에 따른 품질을 연관 지어 파악 가능

* 상관관계의 어려움

-         각 품질속성은 상호 연관성(양면성)이해가 매우 어렵고, 기준이 모호함

-         따라서, 유틸리티 Tree 활용(업무 중요도| 기술 난이도)

-         본 팀에서는 투표 실시에서 벗어나 통계학적 접근 수행(상관관계 검증 중: 모델 수립 후 논문 준비중)

* 결론

-         이해관계들간의 완정한 이해/공감수립을 위한 가시화는 필수적

-         Tip 1: 품질속성 워크샵(중/대규모 pjt 의사결정을 전적 지원. 공감/합의 형성)

-         Tip 2: 현상보다는 해당 회사의 비전/목표에 맞는 아키텍처 수립을 권장(경험적 충고)

-         하지만, SI사업에서 ATAM 완벽한 적용은 어려움

Track 3: SW 아키텍처의 품질속성, ATAM Feature의 정의와 상호 관계성(C&C 김정호 과장)

-         아키텍처 작용의 이론 및 C&C 적용 사례 보고

-         특이점 : 각 아키텍트에 따라서 ATAM 문서의 접근방법, 대응방안 등이 다르다.

-         아키텍트의 역할 : 아키텍처 디자인 10% / 대안 평가 90% <- 이권 다툼에서 논리적 대응 필요

Track 4: 기능/비기능 및 품질에 대한 토의(최성운 교수)

-         ATAM : 임베디드 SW용으로 기업 환경에서 맞지 않음을 인정 -> 현실 적용을 위해서 보다 쉽게 변형 필요(예: 6하원칙 준수)

* 기능/비기능 구분 (전제: 고객의 관점이 있어야 함!)

-         기능(Client의): Input이 있을 때 변형시키는(동사) output 규칙(작업)

-         비기능(Stakeholder의): 어떻게(부사)

* 비기능/아키텍처/품질 연관성

-         비기능 요구사항은 구조에 지대한 영향을 줌(그릇)

-         품질은 비기능의 결과 현상

* 기업 환경에서 ATAM 적용의 세 가지 관점 

-         (1)비즈니스 관점: 이익 최우선

-         (2)관리 관점

-         (3)엔지니어링 관점: 본질 우선

-         하지만, 대부분의 의사결정은 비즈니스 관점에서 좌우됨(비용이 가장 큰 이슈가 됨)

* 권고 사항

-         Stakeholder를 최대한 아키텍처 정의 시 합류 시킴(고객,마케팅 담당자등)

-         Stakeholder의 가중치 적용 제안(사장님과 사원 100명 중 누구 의견을 따를 것인가)

-         위험도는 비용으로 대체 표현 권고