9. 요구사항 설계 개발/운영 자세
가장 큰 문제는
Vasa호 이야기 1000 피트의 뷰 정경유착
기술이 아니다.
아키텍팅은 균형 A와 B의 사이의 반복 작업과 싸
고객의 고객
에 관한 것. 결정 워라!
구현 가능한 것 드워프.엘프, 마 사과와 컨설팅
걸어다니는 해골
만 설계해라. 법사 그리고 왕 이야기
12. Vasa호 이야기
스웨덴 왕실의 위엄을
온 세계에 알리고
덴마크와 동유럽을 침공하기 위해
국왕이 직접 Vasa호의 설계에 참여.
아돌프 구스타프 2세
13. 국왕으로 인해 변경된 요구사항
하는 김에 화려한 사람을 많이 태워야
함포 64문
장식도 달자! 겠어! 갑판 확장!!
금으로 도금한 병
호화로운 장식 채
원래는 32문! 사 조각상 1000여
우기
개!
스웨던 왕실 상
세계최초로 상하 많은 탑승인원
징!! 두마리의 사
2열로 함포 배치 450명!
자 등..
28. 사례.
경영 이론 시스템을 적용해
의사 결정 도구 시스템을
구축하는 프로젝트
신사웅님 - 요구사항이 명확하지 않을 때..
29. 문제 발생
고객
• 경영 이론을 시스템으로 구축한
경험 전무
• 단지 경영진으로부터 방향성만
제시 받음
전산팀
• 안정화된 시스템에 새로운 기능
/프로세스를 추가해본 경험밖에
없다.
• 구체적인 요구사항이 없어 설명
한 경영 이론에만 의존해 시스
템 구축
30. 갈등 발생!!
• 진행과정을 리뷰 하면서, 갈등 시작
• 전산팀은 나름대로 요구사항 정리 후 개발
– 시연을 하게 되면 전혀 다른 요구사항이 발생
– 고객이 원하는 시스템이 아니었다는 결론
– 전산팀에서 아이디어를 고민해 제시해 달라!!
• 업무적인 갈등을 넘어 감정의 갈등으로..
31. 상황정리.
고객의 입장에서는 최종 보이는 결과는 UI
실제 필요한 요구사항 파악 불가
QoS – (비기능적인 요구사항) 파악 불가
선정한 Framework의 사용성, 적합성 모름.
비즈니스 도메인에 대한 정보 예측 불가
구축 후 발생하는 여러 문제들을 파악 불가
45. Instability
•패키지의 움직일 수 있는 여력을 판단하는
지표
•다른 패키지에 영향을 미치지 않고,
해당 패키지를 쉽게 변경 할 수 있는가?
•Instability I = Ce / (Ca+Ce)
•Ce = Efferent Coupling (Ingoing Dependencies)
•Ca = Afferent Coupling (Outgoing Dependencies )
46. Instability
Instability I = Ce / (Ca+Ce)
당신의 패키지가 다른 사람이 많이 쓴다면,
즉 Outgoing, Ca가 많다면, 여러분의 패키지는 변경하기 어렵다.
반대로 Outgoing하는 Ca가 적고, Ingoing(다른 패키지만 사용만 하는) Ce,
여러분의 패키지는 쉽게 변경해도 된다.
즉 0.0에서 0.3이면 안정적인 버전, 0.7에서 1.0이면 불안정적인 상태다
47. Abstractness
Interface(Abstract) 와 Concrete Class를 비교
A = (#abstract classes / total # of classes)
•Abstract class = interface, abstract다 포함
•Total # class = abstract class + concrete class
•0 이면 concrete class만 있다.
•1 이면 abstract class만 있다.
48. 다시 보는 그래프
다른데서 많이 쓰는
녀석이니 조금 더
abstract를 높여야
돼!
49. 그 외 용어
•Tangled Complexity
•순환 참조가 있어 Boundary를 깰 때
•Cyclomatic Complexity
•분기 문이 많아 hotspot이 될 가망성이 높은 곳
50. 경고!!!
환자의 외부 증상만
고치는 의사가 되지 말자!!
이러한 정보는 좋은 가이드일뿐!!
숫자에 의존하다가
오히려 문제가 보이지 않게 된다.
62. 기술을 모르는 영업 상무
• 기술을 모르는 영업 상무
– 비행기에서 유명 컨설턴트와 만나다.
• CBD에 대해서 이야기를 나눔.
• 당신의 솔루션이 재사용, 확장 가능해 진다.
– 귀국 후 차세대 시스템 구축
• 기존 시스템 유지보수에 지친 개발자들도 환호
• 개발자의 추천으로 전문가 A를 아키텍트로 섭외.
63. 전문가 A 컨설턴트와의 마찰!
• 새로운 신기술을 적용해야 밴더 사에 잘 보이겠지.
– 맞지 않는 패턴 적용
• Enterprise Pattern을 임베디드 시스템에 적용.
– 정식 버전이 나오지 않은 신기술을 적용
• 실시간성이 보장되어야 하는 시스템에서 첫 통신시 14초가 걸
림.
• 개발자들 왈: “임베디드 시스템 특성을 몰라? … “
– 기존 기술에 익숙한 개발자들의 반발
• 무엇이 좋아질지 모르는데 왜 바꿔?
• 과연 이렇게 잘게 나누면 좋아질까?
64. 결과!
• PM은 왜 일정이 연기되냐며 개발자 윽박
지르기!
• 컨설턴트 조직은 계약만료 후 나 몰라라 사
라짐.
• 결국 프로젝트 6개월 연기!
• 시스템 오픈 후 여기 저기 문제 떠짐.
68. 대화를 해라.
• 대화의 기술
– 정면 대결이 아니라 대화라는 관점에서 접근해라
• 사람들의 장점을 고려하고 대화해라.
– 여러분의 태도가 올바로 갖춰진 후에만 대화를 시
도해라
• 화가 나거나 짜증난 상태에서 대화하지 말아라
– 회의 시 침묵하는 사람들의 의견을 이끌어 내라.
• 특정 사람에게만 발언권이 모이지 않게 해라.
• 모든 사람의 관점을 다 들어보아라.
73. EA의 간략한 소개.
• UML 2.1 Full 지원
• 모델링 정보를 다양한 DBMS와 연동하여 저장가능
• 형식을 파괴하는 모델링 지원
– Use Case에서도 Class Diagram의 요소들을 사용가능
• 다양한 언어를 지원
– C++, C#, Delphi, Java, VB, VB.NET, PHP, Python
• 강력한 코드 탬플릿 생성 기능
• 테스팅 생성및 관리 (기존 Unit Testing 과 연동됨)
• 강력한 역공학 기능
• 다양한 Plug-in 지원
• 가장 저렴한 가격 1 Copy당 20만원 ~ 30만원 사이
73
74. EA의 장점.
강력한 코드 템플릿 생성 기능
몇 가지 Plug-in 소개
Legacy System을 위한 역 공학
문서 자동 생성 템플릿 소개
통합 개발 환경 구축 방법
74
100. 반지의 제왕 캐릭터.
드워프 - 근면한 일꾼 ,
동굴 속의 어두운 고독 속에서
꾸준히 산출물을 만드는 자
엘프 – 천부적인 재능
우아, 교양있으며, 다른 종족이
하지 못하는 마법을 만들어 냄.
101. 반지의 제왕 캐릭터.
마법사 – 강력한 종족,
엘프와 달리 마법의 강력함과
속성을 깊이 파악해, 놀라운 능
력을 발휘
왕 – 보잘 것 없는 왕
단, 다른 종족과 무엇을 해야 할
지 아는 몽상가 (비전을 제시)
102. 왕의 역할
• 왕 (아키텍트)는 모든 종족과 친해야 함
• 아키텍쳐가 하나의 캐릭터(팀원)에게만 흘
러가지 않도록 균형을 맞추어야 함
• 한가지 퀘스트(도전과제)를 위해 모든 종족
(이해 당사자)를 이끌어, 같이 일할수 있도
록 도와야 한다.
103. 서로 보완적인 능력을
가진 팀 만들기.
Bill Gross : http://bit.ly/u4AV3r
참고자료- 에스티마님의 글
104. Bill Gross
• 미국에서 가장 유명한 Serial Entrepreneur (연속
해서 새 사업체를 설립하는 기업가).
• 많은 Startup을 창업하면서, 얻은 그가 보는 성공
하는 팀의 조건
• 4가지 유형의 성격을 가진 사람들이 서로 조화를
이룬 팀은 성공한다.
105. 사람의 유형.
Entrepreneur – 창업가
새로운 것을 발명하는 사람. 큰 그림을 볼 수 있는
사람. 미래를 미리 준비하는 사람.
Administrator – 관리자
질서를 만드는 사람. 관료적일 수는 있지만 일이
제대로 되도록 룰을 만들고 실행하는 사람
106. 사람의 유형.
Producer - 실제 제품을 만드는 사람
Integrator - 다른 세가지 유형의 사람들을
잘 이해하고 그들이 잘 지낼 수 있도록 도
와주는 사람.
114. 아키텍트의 정치
• 아키텍트는 비즈니스 목표에 맞는 시스템
을 만들기 위해,기술과 관련된 수많은 의사
결정을 하는 사람입니다.
• 이해관계자 사이에서 정당성(rightness), 타
당성(rational)을 바탕으로 이해관계를 조율
하고 설득해야함.
115. 제품 영업 담당자
• 효과적인 마케팅과 판매활동을 통해 이윤
을 창출해야 하는 "경제"적인 역할을 담당.
• 맨발로 지내온 아프리카 원주민에게 구두
를 팔고, 에스키모 인에게 냉장고를 파는 영
업인에게 '사기 쳤다'고 이야기 하지는 않습
니다.
• 오히려 새로운 시장을 개척했다고 말함.
117. 영업 부장의 압력.
• EJB 기반의 WAS
– EJB와 관계형 기반의 DB 시스템에 유리
– 요구사항
• CORBA도 넣어라
• 최신제품이니, 객체 지향 DB도 쓰자
– 결론 “넣긴 넣었다. 하지만..”
• CORBA를 어디에 적용했는지 기억도 안남.
• 객체지향 DB일부만 적용
118. 또 다른 Vasa호
• 미션이 완전히 동일한 시스템은 없다.
• 모든 시스템의 목표를 만족시켜줄 아키텍
쳐 , 솔루션은 존재하지 않는다.
• 만들수 있겠지만, 새로운 장애물이 나올경
우 침몰하는 또다른 Vasa호가 될 뿐이다.
119. 결론.
• 아키텍트는
올바른 “정치”를 하기 위해,
정경유착의 고리를 끊고,
특정 제품에 자유로울 필요가 있습니다.
126. Google Powermeter의 파트너들..
San Diego Gas & Electric? (California)
TXU Energy (Texas)
JEA (Florida)
Reliance Energy (India)
Wisconsin Public Service Corporation (Wisconsin)
White River Valley Electric Cooperative (Missouri)
Toronto Hydro Electric System Limited (Canada)
Glasgow EPB (Kentucky)