Tmax ProFrame vs. 형상관리 연동 동영상 - 체크아웃 + Lock and More...
![]() |
|---|
| Tmax ProFrame Stuudio vs. 실루엣 연동 동영상 |
동영상을 제작했었습니다만. 지금은 소실되어 없습니다.
최근 국내 금융권 솔루션 전문 개발사인 Tmax의 개발도구 ProFrame Studio와 형상관리 솔루션 실루엣의 연동작업이 마무리 되었기에 간단한 소개 차원에서 참고 동영상을 공유 해 봅니다.
주요 연동 범위는 다음과 같습니다. (소스변경 관련 내용만 )
- 실루엣에서 체크아웃(Lock 옵션) > ProFrame 체크아웃 연동
- ProFrame 소스변경 상태 > 실루엣 소스변경 상태 연동
- 실루엣 체크인(Lock 유지) > ProFrame 체크아웃 Lock 유지 연동
- 실루엣 체크인(Lock 해지) > ProFrame 체크아웃 해지
동영상을 살펴보시면 아시겠지만, 최대한 개발자 작업에 편리하도록 연동 설계를 추진하였습니다.
카노 노리아키 교수의 카노 모델(Kano Model)
전자신문을 읽다가. 공감하는 부분이 있어서 스크랩합니다.
상품(제품)에 대한 평가 기준으로
- TGW: 잘못된 기능으로 인한 (-) 마이너스 요인
- TGW: 잘된 기능으로 인한 (+) 플러스 요인
- QSI: 사용자가 스트레스를 받는 요인. (그런 상황들)
제품의 기능, HCI를 고려 한 Spec 작성이 필요 한 시점입니다. 상품기획이론 관련 자료나 도서를 구하고 있지만, 원활하지 않은 것 같습니다.
http://www.etnews.co.kr/news/detail.html?id=200806240057
카노 노리아키 교수의 카노 모델(Kano Model)에 따르면 품질에 따라 소비자 만족 수준이 달라진다. 어떤 품질요소는 반드시 충족해야만 소비자가 만족감을 느낄 수 있지만, 어떤 부분은 충족되지 않더라도 소비자 불만이 크지 않다. 흔히 제품의 문제점이나 결함·하자 등이 전자에, 디자인·기능들은 후자에 포함된다. 따라서 기업은 고객의 요구 수준과 비교해 자신들이 제공하는 제품과 서비스 품질이 어느 수준인지 정기적으로 조사하고 대응하는 체계적인 시스템 구축이 필요하다 K리서치가 진행할 품질평가는 구체적으로 TGW(Things Gone Wrong), TGR(Things Gone Right), QSI(Quality Stress Index)의 세 가지 측정지표를 사용하게 된다. TGW가 문제·결함·하자 경험률을 측정하는 것이라면 TGR는 매력품질 점수와 차원(기능·성능·디자인 등)별 평가 및 중요도를, 그리고 QSI는 스트레스 상황 경험률을 지칭한다.
IBM Jazz Concert vs. CodeInside2 = 협업도구
- 동영상은 Kakao TV를 통해 제공되었습니다만. 현재는 제공되지 않습니다.
IBM Jazz - Concert 관련 내용을 검토하다가, 탐이나는 UI를 발견하고는 몇번을 되돌려 보았습니다. 일견 EverNote의 카테고리 필터정도의 수준이 아니었나 생각했지만, 잠시 확인해 보고는 아주 부럽게 바라보고 있습니다. ^^;
동영상을 유심히 보시면
- 하나의 Article이 HTML 속성을 가지고 있다는 것을 아실것입니다. 이정도는 흔한 UI이지만, Article 본문에서 특정 영역을 Expand하면, Comment를 추가 할 수 있는 UI가 나타납니다.
- 물론 Add Commnet를 수행하면, Comment를 입력 할 수 있는 입력필드가 나타나고 입력 할 수 있습니다.
여기에서 만약 Article이 출력되는 Control이 WebBrowser Control이라면, 뭐, 그럴수도 있겠구나 하겠는데..
애자일 이야기... 그리고 전산실...
이 글은 비공식 Jazz 커뮤니티에 트렉벡하기 위해서 쓴 글입니다.
사실 얼마전에 에릭감마가 직접 시연하는 IBM Jazz 소개가 있었습니나다. 팀원들이랑 회의실에서 빔프로젝트를 통해서 함께 리얼타임으로 감마씨가 스위스 자신의 작업실 (혹은 침실?)에서 보여주는 Jazz를 보면서, 즐거운 시간을 가졌습니다. (물론 실루엣팀도 어서 빨리 제주도에 연구소를… 이라며 웃기도 했습니다만.)
그 이후에 Jazz에 대한 분석은 잠시 이과장에게 일러두었는데, 모니터링 하는 Feed에 jazz.pe.kr에서 등록 한 글이 보이더군요.
그리고는 조금 씁쓸했습니다. 2005년도에 실루엣 팀을 시작 할 때, 우리에게 큰 힘이되는 부분은 Agile Expo였습니다. 그네들 스스로가 자신들의 정체성을 정의해 가면서 보여주는 미래에 대한 비전은 어떻게 일을 하면되는지, 무엇을 하면 되는지, 어떤 일들이 일어 날 것인지 였습니다.
영향분석 vs. 형상관리 시스템에 대해서.
오늘은 타 시스템 인터페이스에 대한 회의를 오전, 오후로 2건이나 진행하고 사무실에 돌아왔더니 집중이 않되고 있습니다.
진행하고 있던 SDSM2008 Specification을 계속 작성할까? 하다가. 떡본김에 제사 지낸다고 영향분석과 형상관리의 연동에 대해서 이야기 해 볼까 합니다.
주) 영향분석이 Impact Analysis인지, Visualization인지, Insight인지는 정의하지 않겠습니다. 여러 벤더에서 조금씩 다른 Concept으로 정의하고 비지니스를 하고 있기 때문에 조금씩 다릅니다. 통칭해서, (한국형으로) 소스중에 “이것” 바꾸면 어떻게 되는지 알려 줄 수 있는 시스템을 지칭하겠습니다.
관심의 초점이 되는 것은 두가지 관점에서 이야기 할 수 있습니다.
파일 버전관리 vs. 프로젝트 버전관리
![]() |
|---|
| 버전관리 솔루션 실루엣 |
전통적인 버전관리툴들, 그것이 Lock 중심의 것들(PVCS, SourceSafe…)이던지, Update 중심의 것들(CVS…) 이던지 상관없이 파일 중심의 버전관리 도구들입니다. 즉, 하나의 파일에 대한 버전변경을 추적하는 기능을 가지고 있는 것이지요.
실제 개발팀에서는 파일 하나의 버전에 대한 추적도 중요하지만, 변경셋(Change Set)에 대한 이력을 추적하고 관리하는 것이 무엇보다도 중요합니다.
CVS를 대체하겠다고 만든 SVN은 그런 의미에서 뉴트랜드에 부합하는 버전관리도구라고 할 만합니다.
몇몇 외산 버전관리 도구들이 Snap Shot이름으로 그 변경내용을 저장하는 방법을 제공 하기는 합니다만, 자동으로 저장되는 것이 아니라 사용자가 필요시점에 Snap을 작성하는 것이라 불편한 점이 많았습니다.
2008 국내/외 형상관리 시장분석
2008 국내/외 형상관리 시장분석 전문보기- PDF File
2008 형상관리 시장 분석
-
대형 SI시장과 소형 SI시장에는 외국산 벤더 특히 마이크로 소프트의 약진이 두드러진 가운데 IBM의 Rational시리즈가 선전하고 있음.
-
MS계열의 개발도구(.NET기반)을 사용하는 프로젝트에서는 MSVSTS가, JAVA계열의 Eclipse기반은 CVS, Buggilra등의 오픈 소스가 강세였으나 IBM의 RTC(Rational Team Concert)가 출시됨에 따라 시장 변화가 예상됨.
-
외국산 벤더들은 ALM의 통합을 추구하며 ALM전반에 걸친 다양한 도구를 Integrate하여 판매하는 추세. 따라서 유명 벤더의 포지셔닝은 “통합형 ALM솔루션” 으로 축약할 수 있음.
Ajax + Web 2.0이 대단한 기술이지만...
Ajax + Web2.0이 대단한 기술이지만. 미션크리티컬 영역에 있어서는 여전히 Desktop Application이 필요 하다. (Informatiion Week, MS Remix08 컨퍼런스, 김재우 부장)
회자되는 이야기지만, 제안서쓸때 스프링노트에 대고 하지는 않는다. (물론 제안서 아이디어 모을때 이동하면서 워드에 대고 하지도 않는다. 그런분을 보기는 했지만 ^^;)
S+S도 좋고, RIA도 좋지만, MS가 실버라이트에서 Win32 Local 리소스에 대한 접근을 허락하지 않는 한(그럴리는 없을것 같다) RIA는 일반 대중을 위한 유용한 도두일 뿐이다.
그 풍부한 UI를 바탕으로 집에있는 mp3 File을 웹으로 올려주는 제품이라도 하나 만들고 싶지만… ^^; Local에 대한 접근과 웹의 편리성을 모두 달라..! (ActiveX 반대론자들의 야유가…)
테스트의 종류 - 아름다운 이야기
Ship It 57 Page에 나오는 주옥같은 이야기 입니다.
단위 테스트(Unit Test)
단위 테스트는 개별 클래스나 객체를 테스트하기 위해 고안되었습니다 단위 테스트는 독립형이고 일반적으로 작동시키기 위해 다른 클래스나 객체가 필요하지 않습니다. 단위 테스트의 삶의 유일한 목적은 한 뭉치의 코드 내에 논리가 적절히 작동하는지 확인하는 것입니다.
기능 테스트(Functional Test)
기능 테스트는 제품 전체의 적절한 동작(또는 기능)을 테스트하기 위해 작성됩니다. 기능 테스트는 제품 전체 또는 한 제품 내의 주요 하부 시스템을 다룰 수 있습니다. 기능 테스트는 시스템 내에 많은 객체를 갖습니다.
CuteFlow - 아주 흥미로운 컨셉의 Workflow
[CuteFlow] 이름까지 아주 앙증맞은 Workflow제품을 발견했습니다. http://www.cuteflow.org
![]() |
|---|
| CuteFlow 설명 다이어그램 |
위 이미지가 CuteFlow를 아주 잘 표현하는 컨셉입니다. Sender가 Form을 Define해서 Email로 배포를 하면, 등록된 사용자가 Form에 데이터를 입력하고, 마지막으로 Archive되는… 재미 있는 시스템이군요.
Opensource입니다.
아래는 Form을 Define하는 화면입니다. Workflow의 가장 핵심적인 [정의]부분을 충실하게 반영하고 있는 솔루션이라고 할 수 있겠습니다만..
한국시장에서의 효용은 글쎄요? 그리고 각 수신자의 입력 값에 따른 비지니스 로직의 처리가 어렵겠군요 ^^;
![]() |
|---|
| CuteFlow 실행 화면 |



