2017년 1월 12일 목요일

A Requirement Specification Language for AADL



참석자
Suzanne Miller - principal researcher at the SEI (the Carnegie Mellon University Software Engineering Institute)
Peter Feiler - The researcher at the SEI
요약
AADL의 핵심은 자동차와 같은 필수 안전 소프트웨어 시스템에 있다. 우리가 다루고 있는 것은 임베디드 소프트웨어 시스템, 특히 필수 안전에 초점을 두고 있다. 상황이 잘못되어도 이 시스템이 작동할 때까지는 감지하기 어렵다.
90년대 연구가 시작되었고, 이를 모델링 아키텍처에 대한 업계 표준으로 바꾸고, 강력한 의미 체계를 사용하여 시스템 작동 방식을 분석적으로 평가할 수 있었다. 이를 가상 시스템 통합이라는 용어를 사용했다. 이 표준은 2004년에 처음 출판되고, 항공 산업 및 다른 산업 분야에서도 이를 채택했다.
임베디드 시스템을 다룰 때 AADL의 초점은 소프트웨어, 하드웨어 및 다루는 물리적 시스템 특성을 파악하여 상호 작용을 이해하는 데 집중할 수 있도록 하는 것이다. 발견 한 문제 중 80%가 단위 테스트를 끝낼 때까지 발생하지 않기 때문이다.
시스템 품질을 개선할 때 개발 품질은 잘 개선하지만 요구사항에 반하는 품질이 문제였다. 요구사항을 정의하는 방식을 개선해야 하고 최종 테스트뿐만 아니라 개발 프로세스 전반에 걸친 품질 활동을 수집해야 한다. ALISA라는 점진 보증(incremental assurance)을 다루는 프로젝트가 시작되었다.
전통적인 개발에서 요구사항으로 모든 것을 모델링하고 시스템으로 만들어져야 하는데 모호한 요구사항이 있다. 요구사항을 정의하는 방법은 텍스트 표기를 처리하고 이러한 부분을 시스템으로 추출하는 것이다. 그런 다음 누락되었는지 확인한다.
관건은 그 연구와 범위를 보완하는 것인데 발생한 문제의 80% 정도는 공식적인 부분이 아니라 단순히 놓치는 것이 많다는 것이다. 여기에 접근하는 방식이 있다. 아키텍처 주도형 요구 사양이라고 부른다.
우리는 건물을 다시 짓는 방식으로 요구 사양, ReqSpec 표기법을 사용했고 이를 기반으로 AADL 모델과 관련된 요구 사양에 대한 메타 모델이 나왔다. 이러한 메타 모델에서 수행하고자하는 작업은 요구 사항을 지정하는 기능에 초점을 맞추거나 목표를 수립한다. 요구 공학이란 목표 지향적이며 시스템에 대한 요구 사항이기 때문이다.
하지만, 두 가지 요구 사항을 명확하게 구분하려는 경우 가끔 서로 충돌 할 수 있지만 해결하지 않는다. 따라서 모든 것을 표현할 수 있는 공간을 제공해야하고, 모든 사람들이 모든 요구 사항과 가정에 대해 이야기하고 있는지 확인해야 한다.
그런 다음 시스템 요구 사항을 정의한 후 검증 할 필요가 있다. 경우에 따라 아키텍처 언어를 사용하여 내부 아키텍처를 설명하지 않고 시스템을 운영 컨텍스트로 설명한다.
첫번째는 수행 시나리오로 설명할 수 있다. 이 곳에서 모델을 발견한다. 여기에 시스템이 있고 모든 엔티티가 있다. 그리고 단순한 것의 각각을 덮어서 다양한 각도에서 덮어 씌웠을 것이다. 기본적으로 요구 사항 정의는 목표를 모델링하는 것뿐만 아니라 목표를 모델링하는 환경도 모델링하는 것이다.
수집된 요구사항 문서가 있는 경우 이를 바탕으로 시스템 요구 사항을 정의 할 수 있고, 아직 수집된 요구 사항이 없다면 그 시점에 아키텍처 맥락에서 정의하고 싶을 것이다. 기본적으로 요구 사항 적용에 대해 두 가지 형식을 가지고 있다. 하나는 문서 구조를 따르고 다른 하나는 아키텍처 요소를 따른다. 상호 연결하여 개별 이해 관계자에게 완전한 추적성을 제공할 수 있습니다.
두번째는 아키텍처를 발전시키는데 시스템 전체가 필요하다. 세부적인 아키텍처가 필요하지만 일반적으로 하지 않는 경향이 있다. 하지만 우리 표기법을 사용하면 매우 자연스럽다. 그것은 당신이 OK라고 말하는 것처럼 쉽고, 다음 단계 설계를 할 것이다.
이 모든 과정이 요구 사항을 정리하는 점진적 프로세스가 되는 것과 동시에 다음 단계 설계에 사용되고 다음 단계 설계를 마친 즉시 상위 레벨 요구 사항은 이 레벨에서 충족되기 때문에 점진 보증 활동을 받게 된다.
우리는 실제로 Joint Multi Role이라는 육군 기술 프로그램에 적용했다. 프로젝트를 수행하고 계약자의 요구 사항을 가져와서 이 표기법으로 정리했다. 초기에 몇 가지 구멍과 몇 가지 잠재적인 문제를 파악할 수 있는지 알아 보면서 검증하였다.


SW 공학기술 적용 및 SW 현장적용


추진배경 및 필요성




사업수행 및 목표






Golang와 Go의목적


Go의목적



Go의디자인철학


  • performant
  • multiple-cores
  • concurrency
  • compiled
  • network





Go 언어의목적은? -> Concurrency!!


Go의핵심컴포넌트





2017년 1월 11일 수요일

Node.js와 Benchmark 사례

Node.js Production 레벨에서는 CPU 갯수+@ 만큼 Single Thread를 뛰워요!




가장많은 모듈을 가진 언어!



Benchmark : 간단한http 요청




Benchmark: HTTP & CPU Task





소프트웨어 개발 품질 이슈 발생에 따른 대처 방법

소프트웨어를 개발하면서 공통적으로 가장 많이 듣는 얘기는 소프트웨어 품질일 만큼 소프트웨어 개발 회사나 개발자의 가장 큰 고민거리다. 이미 오래 전부터 다양한 방법으로 품질 확보에 노력해왔지만 언제나 똑 같은 고민거리로 다시 나타나는 품질에 대한 문제는 개발의 일부분 정도였던 것을 넘어 개발과 동등하게 고려되는 요소로 인식되고 있다. 이번 회에서는 소프트웨어 개발 품질 이슈를 어떻게 해결해야 하는지 대형 시스템통합 프로젝트에서 오랫동안 품질 관리를 해온 호윤시스템 김기향 팀장에게 얘기를 들어본다.

Q: 안녕하세요. 소프트웨어를 개발하면서 품질은 아주 오래전부터 지금까지도 반드시 해결하고 지켜야하는 숙제인 것 같습니다. 소프트웨어 개발 품질에 대한 정의부터 설명해 주시죠.

소프트웨어는 제조업에서 만드는 제품과는 많이 다릅니다. 제품은 만들어 놓으면 잘 돌아가는지 여러가지 검사를 통해 확인도 하고 육안으로도 찾을 수 있는 부분들이 많습니다. 그런데, 소프트웨어는 만들어 놓고도 이것이 잘 돌아갈 것인지 잘 돌아가고 있는지 육안 확인은 물론이고 도구를 써도 알아내는 것이 쉽지 않죠. 그래서, 소프트웨어를 개발할 때 품질을 어떻게 확보할 것이냐에 대한 고민을 많이 합니다.
소프트웨어의 품질은 이렇게 해야한다고 미리 정해 놓을 수는 없습니다. 만들어야 하는 소프트웨어의 종류에 따라 확인해야 하는 부분들이 모두 다르기 때문이죠. 제품을 만들 때도 제품의 특성이나 사용되는 부품에 따라 점검해봐야 하는 요소가 다른 것처럼 소프트웨어도 마찬가지 입니다.
그렇다면, 언제 소프트웨어의 품질 요소를 결정해야 하는지에 대해 고민하게 되는데요. 그림1은 소프트웨어를 설계할 때 고민해야 하는 요소들을 나타내는 것입니다. 만들고자 하는 소프트웨어를 설계하면서 설계에 따라 확인해야 하는 품질 요소를 결정하는 것이죠.

<그림1> 소프트웨어 설계 시 고려해야 하는 품질 요소

Q: 소프트웨어 품질을 높이려면 이런 부분을 확인해야 한다고 정해져 있는 줄 알았는데 그게 아니었군요. 소프트웨어마다 어떻게 품질을 확인할 것인지를 매번 만들어야 하는 건가요?

말한 것처럼 처음부터 끝까지 다시 만드는 것은 아닙니다. 기본적으로 확인해야 하는 요소들은 있습니다. 다만, 그러한 요소를 기반으로 어떤 항목을, 언제, 어떻게, 누가 할 것인지, 또 어느 정도 결과를 기대해야 하는지, 기대에 못 미쳤을 때 어떻게 대처해야 하는지, 이런 것들을 소프트웨어 설계하면서 함께 만드는 것입니다.
품질 속성을 평가하고 확인할 수 있는 다양한 가이드나 기법들이 알려져 있습니다. 그림2는 모바일 소프트웨어의 품질을 확인할 수 있는 속성에 대해 어떤 기법으로 확인할 수 있는지를 보여주고 있습니다. 물론, 이것은 하나의 예시입니다.



강의영상 : 국제표준 및 SW공학도구 적용을 자동차 전장SW개발 품질향상 성과사례

22nd SW Quality Insight 컨퍼런스 

트랙2-4. 김경욱 상무(에스피아이디) 강의영상 

주제 : 국제표준 및 SW공학도구 적용을 자동차 전장SW개발 품질향상 성과사례




2017년 1월 10일 화요일

헬스케어 사례 연구 - 빅데이터와 연계

헬스케어는 개인의 의료 데이터를 생성하기 때문에 빅데이터 관점의 접근이 반드시 필요하다. 게다가 치료 중심의 의료 서비스에서 예방 중심의 헬스케어로의 변화는 예측하기 어려울 정도의 빅데이터를 생성하고 있다. 분당 서울대병원에서는 빅데이터 연구원을 설립하여 다양한 의료 서비스에 접목시키고 있고 괄목할 만한 효과를 보이고 있다. 이번 회에서는 빅데이터 기반의 헬스케어에 대해 살펴보도록 한다. 예방 중심의 헬스케어 서비스에 빅데이터가 차지하는 역할이 무엇인지 이해하기를 기대한다.
사례 연구 전 확인 사항

빅데이터의 활용

빅데이터는 ICT 뿐만 아니라 다양한 산업 분야에서 최대 경쟁력으로 인식되고 있고, 제대로 된 자료 수집과 분석이 이루어진다면 재해, 의료 등의 서비스에서 안전과 질 높은 삶을 영위하도록 도와줄 수 있다.
기존에 사용하던 데이터는 미리 정의된 기준에 따라 수집, 관리되었기 때문에 정보 가치가 제한적이었다. 빅데이터는 무제한으로 수집할 수 있어 자료의 양과 복잡성은 매우 높지만 필요에 의해 수집된 데이터이기 때문에 기존 데이터보다 정보의 질은 높다. 이렇게 수집된 데이터를 목적에 따라 분석하여 정보를 정리하면 정보의 질은 높고 복잡성은 낮은 정제된 빅데이터가 된다(그림1).

< 그림 1> 데이터의 복잡성과 질의 관계

데이터를 수집해서 바로 활용할 수는 없다. 다양한 매체를 통해 데이터를 수집하고, 불필요한 데이터를 걸러내면서 적절한 기준에 맞춰 정제를 한다. 그리고, 데이터를 분석하면서 의미 있는 지식으로 정보화 또는 시각화 한다(그림2).

<그림2> 빅데이터의 활용 단계

헬스케어 서비스에서 목표 달성을 위해서는 어떠한 전략으로 서비스를 구성해야 하는지 빅데이터 플랫폼을 통해 얻고 있다(그림3). 아래 그림은 가독성을 위해 큰 그림으로 표시되었지만 실제 서비스를 위해서는 데이터의 수집, 정제, 분석 방법과 지식화된 데이터를 어떻게 시각화할 것인지에 대한 방법 등을 세부적으로 더 정의되어야 한다.

<그림3> 헬스케어 빅데이터 플랫폼의 예시
출처: 한국보건산업진흥원