SW프로젝트 요구사항 수집을 위한 맥락조사 기법

소프트웨어에 대한 요구사항 수집( Gathering Requirement)은 소프트웨어 개발자가 직면한 가장 큰 어려움 중에 하나입니다. 이를 해결하기 위한 방법 가운데 하나인 맥락조사(Contextual Inquiry) 기술은 애플리케이션이 실행된 과정을 관찰, 추적해 사용자의 요구사항을 수집하는 것입니다. 우리는 이 기술을 통해 요구사항 수집으로 인해 발생되는 전형적인 문제들을 극복할 수 있습니다.

• 1980 년대 중반 시작된 맥락조사 (Contextual Inquiry) 기법은 사용자의 업무를 파악하고 , 이에 대한 요구사항을 수집하고 보강하는 데 이용되는 방법임
• 요구사항 정보 수집에 있어 나타나는 전형적인 문제점
• 맥락조사 과정은 다음의 세 단계로 진행됨
• 요구사항 수집 기법으로서 맥락조사의 장점
• 맥락조사는 단지 사용자 기능상의 제한된 요구로부터 발생할 수 있는 오류를 방지하고 , 사용자 프로세스 기반의 전반적인 요구사항을 이끌어 냄에 따라 수준 높은 SW 품질을 이끌어내는 기반이 됨

자세히 보기 →

NoSQL 데이터베이스로서 MySQL

최근 NoSQL 이 데이터베이스 영역에 한 축으로 자리잡고 있지만 , 기존 관계형 데이터베이스 (RDB) 사용자들에게 NoSQL 은 아직 낯설기만 합니다 . 이런 상황을 반영해 데이터 정합성이 중시되는 서비스에서 RDB 의 장점을 활용하면서 NoSQL 특징을 결합하려는 시도들이 이어지고 있습니다 . NoSQL 의 특징들을 추가하면서 RDB 기능을 보완하는 방법과 이왕 NoSQL 을 사용하려면 제대로 한번 해보는 차원에서 모델링까지 살펴보기로 했습니다 .

첫 번째 연재에서는 'MySQL as a NoSQL' 이라는 제목으로 MySQL 의 장점에 HandlerSocket Plugin 이나 Memcached Plugin 을 활용해 NoSQL 의 특성을 가미하는 방법과 성능에 대해 알아봅니다 . 2 회차 연재에서는 'MySQL 의 스케일 아웃 (Scale Out)' 에 대해 알아봅니다 . MySQL 의 Scale Out 기능의 약점을 보완하는 차원에서 대안적 스케일 아웃 방법들에 대해 살펴볼 계획입니다 . 3 회에서는 'NoSQL 데이터 모델일 ' 이라는 주제로 MySQL 을 본격적인 NoSQL 로 DB 로 사용하기 위한 모델링 방법 대해 소개할 계획입니다 .

데이터베이스 분야는 최근 클라우드 컴퓨팅과 소셜 네트워크 서비스의 등장 , 스마트 기기의 확산 등 컴퓨팅 환경 변화에 대처하고 내부적으로 데이터의 폭증과 원활한 서비스 지원을 위해 다음과 같은 과제를 해결해야 하는 환경에 놓여있습니다 .

자세히 보기 →

Architecture Visualization(아키텍쳐 시각화) Part 2

지표란 직접 경험을 하지 않아도 현재의 상황을 알 수 있는 도구를 말합니다 . 옛날 제주도에서는 물이 귀해 빗물을 식수로 사용을 했습니다 . 빗물의 오염도를 파악하기 위한 지표로 , 개구리 ( 수놈끼리만 넣거나 , 암놈끼리만 넣거나 ) 를 사용했습니다 . 개구리들이 벌레들을 잡아먹어 물이 항상 청결한 상태를 유지할 수 있었으며 , 또한 개구리의 생존 여부로 물 오염도를 파악 할 수 있었습니다 .

이러한 지표의 한 예로 , Dependency Structure Matrix (DSM) 을 지난 호에 소개했습니다 . 이번 호는 또 다른 지표로써 , Clean Code 의 저자이자 객체 지향의 SOLID 원칙으로 유명하신 Robert C. Martin( 줄여서 Uncle. Bob) 님이 만드신 Instability/Abstractness Graph 를 설명하겠습니다 .

• Instability
• Abstractness
• Main Sequence 와 Distance
• STAN4J 와 그 외의 지표들

자세히 보기 →

MS社, 윈도우10 출시 관련 주요 이슈 보고

MS 社 의 신규 운영체제인 윈도우 10 이 올해 7.29 일 ( 수 ) 출시 * 예정 인 바 , 이에 따른 국내 S/W 및 인터넷 이용환경 변화에 대한 이슈 분석

1. 새로운 브라우저 (‘Edge’) 출시 관련 이슈

윈도우 10 에서는 기존의 ‘ 익스플로러 11 ’ 과 신규 웹브라우저 인 ‘ 엣지 (Edge) ’ 를 동시 탑재하여 출시하나 엣지의 경우 ActiveX 등 플러그인 기술을 지원하지 않아 * 웹사이트 이용시 정상 동작이 되지 않을 수 있음

- 다만 , 동시 탑재된 익스플로러 11 의 경우 종전과 같이 ActiveX 를 지원 하므로 브라우저 설정 변경 ** 을 통하여 큰 문제 없이 웹사이트 이용 가능

* 엣지의 ActiveX 미지원 정책은 여러 차례 이슈화되어 대부분의 국내 개발자 및 이용자들은 인지

2. 운영체제 ( 윈도우 10) S/W 설치 관련 이슈

o 윈도우 10 OS 의 커널구조 * 가 변경 되어 HW 를 활용하는 일부 SW** 의 경우 수정개발이 필요하나 윈도우 10 출시 이후에나 개발 작업 완료 예정

* 커널 (kernel) : OS 를 구성하는 주요 뼈대로 하드웨어 관련 입  ·  출력과 명령어 처리를 담당

** 동영상 · 음성 편집프로그램 , 채팅 · 메신저 프로그램 , 스캐너 · USB 제어 프로그램 등

자세히 보기 →

분산된 애자일 팀 간의 명확히 공유된 이해 제공

대부분의 애자일 개발관련 참고서적들은 동일 장소에 배치된(co-located) 팀들과 대면(face-to-face) 의사소통의 장점에 대해 말합니다. 기본적으로 동일 장소에 배치된 팀들은 의사소통이 더 쉽고 강한 유대관계를 형성하는 장점을 가집니다. 그러나 기술과 SW개발/관리도구(tool)들의 발전과 더불어 분산된 애자일 팀들(distributed Agile teams)이 많아짐에 따라 애자일 방법론상의 대면활동에 대한 강조는 SW개발 조직운영에 있어 부작용이 발생시킬 여지가 있습니다. 현재 SW개발/관리 툴들은 더 많은 유연성과 이동성을 보장함에 따라, 문서화를 통한 효과적인 의사소통 체계를 구축하는 것이 필요합니다.

• SW 개발 프로젝트에 있어 문서화는 개발팀간의 오해가 없는 명확히 공유된 이해를 제공한다.
• 문서화는 대면 의사소통에 비해 공유하기 쉬우며 분산된 개발팀의 기본적인 의사소통 수단으로 활용하는 것이 바람직하다.
• 그럼에도 불구하고 대면 의사소통은 여전히 중요하다.

자세히 보기 →

대량 스트림 데이터 처리 솔루션인 Oracle Complex Event Proces

오늘날 다양한 IT 환경에서 수많은 데이터가 쏟아지고 있습니다 . RFID 리더 , 바코드 스캐너 , 기계 장치의 센서는 물론 최근에는 중요 자원의 위치를 알려주는 GPS(Global Positioning Systems) 정보까지 다양한 데이터가 끊임없이 쏟아지고 있습니다 . 이렇듯 지속적으로 데이터를 발생시키는 시스템들이 많아지고 , 발생하는 데이터량 또한 점점 늘어가고 있는 상황에서 중요한 것은 어떻게 이 많은 양의 데이터 중에서 비즈니스적으로 의미 있는 데이터를 신속하게 추출하고 처리하느냐입니다 . 이러한 상황에서 복잡한 데이터를 처리하는 솔루션인 CEP(Complex Event Processing) 에 대해 설명하고자 합니다 .

Complex Event Processing 는 여러 이벤트 소스로부터 발생한 이벤트를 대상으로 실시간으로 의미 있는 데이 터를 추출하여 대응되는 액션을 수행하는 것을 말합니다 . 이때 이벤트 데이터는 스트림 데이터로써 대량으로 지 속적으로 입력되는 데이터 , 시간 순서가 중요한 데이 터 , 끝이 없는 데이터입니다 . 이러한 스트림 데이터는 전 통적인 관계형 데이터 베이스에서는 실시간 처리 및 분 석이 불가능합니다 . CEP 는 바로 이런 스트림 데이터를 실시간으로 분석하는 이벤트 데이터 처리 솔루션입니다 .  

자세히 보기 →

Architecture Visualization(아키텍쳐 시각화) Part 1

변화의 충격을 감지해라 - Dependency Structure Matrix

소프트웨어는 사용자에게 유용해야 된다는 명백한 외부적인 관점도 있지만 , 품질이라는 내부적인 관점도 존재합니다 . 즉 소프트웨어가 잘 개발되고 있는지 품질을 파악할 수 있는 지표가 필요합니다 . 이번 연구에서는 소프트웨어의 품질을 평가할 수 있는 몇몇 시각화 기법을 전달합니다 .  

시각화의 필요성 (1000 피트의 관점 )

아키텍처의 품질을 평가하기 위해 , UML 로 그려진 아키텍처 다이어그램을 볼 수 있습니다 . 하지만 아키텍처 다이어그램의 작은 상자들은 전체 시스템을 나타내며 상자 간의 선은 시스템 간의 의존성 , 데이터 흐름 , 버스와 같은 공유자원인지 파악할 수 없습니다 . 이것은 비행기 밖 풍경과 같이 과도하게 추상화되어 있는 30,000 피트의 뷰 입니다 .

반면에 소스코드를 보며 품질을 평가 할 수 있는데 , 이것은 0 피트와 같은 바닥 레벨의 뷰로 비유할 수 있습니다 . 소스 레벨에서는 연관성 있는 몇 개의 객체의 구조도 보지 못할 만큼 많은 정보를 제공합니다 .

이 두 뷰는 소프트웨어 품질에 대한 올바른 정보를 제공하지 못하므로 , 0 피트와 30,000 사이인 , 1000 피트의 뷰를 보아야 합니다 . 1000 피트의 뷰는 메서드 개수 , 클래스 팬 아웃 , 순환 의존도와 같은 다양한 지표와 많은 양의 데이터를 접할 수 있습니다 .

의존성 분석 도구 DSM(Dependency Structure Matrix)

• DSM 으로 보는 계층화
• Change Propagator 를 주의해라
• 의존성을 끊는 방법
• 실 사례로 보는 DSM

자세히 보기 →