Software Engineering Network

1. APPLE - iPhone 3Gs

  아이폰!!! 요놈 때문에, 지난번 바닷가 놀러갔다가 스카이(돌핀)폰을 물에 빠뜨려서 집에 굴러다니는 애니콜 블루블랙을 여태 쓰고 있지요. 뭐 지금 쓰고 있는 폰이 워낙 탱크라서 막 집어던져도 전혀 안깨짐..(문근영폰ㅠ)  어쨌건!! 아이폰에 대한 떡밥기사들은 줄기차게 나오는데 아직까지 공식적인 언급이 없으니 9월에 나온다고는 하지만, 불안불안 하네요. 

  뭐 솔직히 전파인증도 받았는데, 안나오면 KT 븅신. -_- 문제는 SKT쪽에서도 아이폰 도입을 검토하고 있다는데, 저는 쌍수를 들어 대환영입니다. 뭐 굳이 번호이동하고 싶지를 않아서 말이죠 크흠. 문제는 KT 진영쪽에서 WI-FI에 대한 사업전략을 어떻게 구축할지 아주 흥미롭습니다. 뭐 정말로 Wi-Fi가 빠진다면 심각하게 다시 고민하지 않을까 생각됩니다. Wi-Fi가 빠진 아이폰은 단순히 뽀대용에 지나지 않으니까요.


2. OLYMPUS - PEN E-P1

  결국은 나왔습니다. 뭐 나오자마자 2시간만에 전량 매진. 매진.. 처음에는 마이크로 포서드(이하 마포)에는 별로 관심이 없다가 막상 뚜껑을 열고보니 너무 이쁘잖아!!!ㅠ 다행히 국내 판매가격이 14-45mm번들킷으로 995,000원이라는 군요. 아 근데, 뷰 파인더가 외장이라니...뭐, 물론 라이브뷰가 있지만, 뷰파인더로 보고 찍는게 익숙한 유저들은 약점으로 생각될 수 있겠네요.
  지금 이놈을 심각하게 구입을 할까 말까 고민중입니다. 올림푸스에서는 앞으로 꾸준하게 Pen 시리즈에서의 렌즈군을 계속 내놓는다고 하니.. 아아~ 돈걱정 안하고 바로 지르는 날은 진정 오지 않는 것인가. 일단 DSLR급(?)의 심도표현에 컴팩트함. 역시 너무나 매력적이라는 생각이 듭니다. 올림푸스는 아직 죽지 않았다!!!


3. KIA Motors - Forte KOUP

  현재 저의 상황에서는 진정한 wish item. 아직 제대로 된 수입이 없기 때문이죠.ㅠ 뭐 차 매니아들 사이에서는 포르테가 좋다, 아니다. 말들이 참 많은 것 같은데, 쿠페버전이 나오면서 그냥 점찍었습니다. 너무 이쁘게 잘 나온 것 같아요.ㅠ 평소 빨간색이 어울리는 날렵한 차에다가(페라리의 영향일지도..), 개인적으로 2도어를 선호합니다(아직 젊기 때문인가요..). 게다가 프레임리스라니!!!


  피터 슈라이아 아저씨께서는 참 능력이 있는 분 같습니다. 우리나라에 이런 자동차를 하사해주시다니.. 스포츠 버켓시트에 버튼식 시동장치(완전 선호)!!! 무엇보다도 가장 눈에 띄었던 것은.."라이팅 스피커!!" 뭐 어떻게 보면 제일 쓸데 없는 기능일지는 모르겠습니다만, 개인적으로 드라이브하면서 음악듣는걸 굉장히 좋아하는 저로서는 음악에 맞춰 스피커 부분에 LED 조명이 바뀌는 그 분위기를 상상하면 어우..

  뭐, 지금은 이렇게 포르테 쿱에 완전 꽂혔지만, 혹시 압니까 추후에 소울스터(SOUL의 컨버터블형 컨셉트카)가 양산될지.

  살다보면 공적인 자리에서든, 사적인 자리에서든 난감한 질문을 받을 때가 있다. 그 상황만 되면 질문을 받은 사람은 난감하고 애처롭기 그지 없다. 그때마다 발휘해야 하는건 바로 센스. 센스는 순발력과 타이밍이 적절할 수록 그 빛을 발하는 법.

  나는 군면제자이다. 본 포스팅은 전적으로 내 경험담에서 우러나왔음을 밝힌다. -_-; 사석에서 삼삼오오 사람들이 모여 이야기 꽃을 피우다 보면 군대 병역에 대한 얘기가 자주 나오곤 한다. 특히 술자리에서 그러하다!!


  요즘 세상이 어떠한가. 많이 병역에 대해 많이 관대해지지 않았는가. 나는 자랑스레는 아니지만, 스스럼없이 말하곤 한다.


  이럴 때마다 꼭!! 꼭!! 다음 질문은 다음과 같다. 열이면 열, 백이면 백.

  개발과 관련된 산출물에 대해 포스팅을 해보고자 한다. 먼저 IT 분야에서 말하는 개발 산출물에 대한 정의를 살펴보면, [2]에서 발췌한 IEEE에서의 SWEBOK 프로젝트에서는 다음과 같이 정의하고 있다.

  시점은 유지보수. 유지보수 환경에서는 이해관계자 별로 어떠한 필요 정보들이 있을까. 그리고 이해관계자 별로 필요로 하는 문서정보의 경계선은 어떻게 나누어질 수 있는가? 시스템 개발 이후, 소프트웨어와 시스템. 이들을 유지보수 하기위한 환경도 매우 중요하다. 대부분의 유지보수 환경에서는 이전 시스템 개발에 참여했던 이해관계자들이 변경되기 때문이다. 특히, 외주를 주게되는 하청 구조에서는 더욱 그러하다. 

   
  물론, 중소기업 및 벤처기업의 경우 시스템의 유지보수를 1~2명이서 유지보수를 담당하는 형태에서는 본 포스팅에 대한 내용이 별로 필요가 없을 수 있다. 본 포스팅은 전적으로 참조된 [1]의 내용에 근거한다. 참조된 [1]의 내용에서는 다음과 같이 유지보수 환경에서 이해관계자 별 필요 문서정보의 경계를 나누고 있다.

관리자(Manager)
- 측정비용, 유지보수 가능성, 프로그램 크기(LOC, FP)

분석가(Analyst)
- 문제 도메인, 기능/비기능 요구사항, 시스템과 환경요소와의 관계, 시스템 변경에 의해 끼치는 영향요소, UML, Context Diagram

설계자(Designer)
- 컴포넌트, 데이터구조, DFD, 상세 알고리즘, 데이터 표식/구조, 인터페이스

개발자(Developer)
- 컴포넌트의 기능정보, 데이터 객체, 프로그램 기능과 구조

[1] Penny Grubb, Armstrong A. Takang, Software Maintenance - Concepts and Practice 2/E, World Scientific Press. 2003.
[2] Pete Sawyer, Gerald Kotonya, SWEBOK: Software Requirements Engineering Knowledge Area Description - Version 0.5, Lancaster University, UK, 1999.