2015년 12월 31일 목요일

애자일팀을 위한 무료 CI툴 10선

연속적인 빌드와 인티그레이션은 프로젝트의 성공 여부를 결정짓는 핵심 요소로 ,  지속적인 통합 (Continuous Integration) 툴은 프로젝트에 투입되는 시간과 노력을 효율화하는 데에 매우 중요한 사안입니다 .  본 원고에서는 애자일 프로젝트팀이 이용할 수 있는 무료  CI 툴  10 선을 소개합니다 .

애자일 팀을 위한 무료  CI 툴  10 선
 1. Hudson
 2. LuntBuild
 3. CruiseControl
 4. BuildBot
 5. Beebox
 6. Apache Gump
 7. Apache Continuum
 8. DarcoNet
 9. Cabie
10. ControlTIER

개인정보 보호를 위한 EAI시스템 설계 및 구현

인터넷의 활성화와 비즈니스에서  IT 기술의 도입이 가속화되면서 기업들은 업무 간 연계를 위해서 각각의 업무시스템을  Peer-to-Peer  형식으로 연결하기 시작했지만 ,  방대한 데이터에 대한 안정성 ,  성능 그리고 모니터링 등 여러 가지 고려사항이 여전히 존재하였습니다 .  이를 해결하기 위해 어플리케이션 간 연동만을 전문으로 하는 아키텍쳐와 솔루션이 필요하게 되었는데 ,  그것이  EAI(Enterprise Application Integration) 입니다 .  기업들은  EAI 를 통해 다수의 어플리케이션에 분산되어 있는 데이터 등을 전사적 차원에서 공유할 수 있을 뿐 아니라 비즈니스 프로세스를 단순화하고 자동화함으로써 기존 시스템의 효율성을 재고할 수 있으며 새로운 어플리케이션 개발 시 시간과 비용을 줄일 수 있게 되었습니다 .

● 키 교환 프로토콜
● 보안성이 적용된 키 교환 프로토콜 설계
   1. EAI보안 모델

EAI 보안 모델

   2. EAI를 위한 키 교환 프로토콜

● 키 교환 프로토콜 평가
   1. 알고리즘 지수승 연산 측면
   2. 통신 파라미터 측면
   3. 프로토콜 안정성 측면

린(Lean) SW개발: 낭비요소를 이해하고 애자일로 관리하기

SW 개발에 있어 린 (Lean)  개발 방식은 불필요한 것을 버리고 효율성을 기해 경량화하는 것이라면 애자일 (Agile) 은 개발에 있어 민첩성을 가해 문제를 끊임없이 해결하는 것 입니다 .  이에 따라 린 개발 방법에 있어 낭비적인 요소가 무엇이며 ,  이를 해결하기 위해 애자일 방식을 어떻게 적용해야 하는 지에 대한 방안을 제시합니다.

린 방법론의 애자일 적용요소
 - 협업 (Collaboration)
 - 제품 백로그 (Product backlog)
 - 지속적인 개발과 전달 (Continuous development and delivery)
 - 일의 추정 (Work estimation)
 - 줄어든 결함 (Reduced defects)
 - 스크럼마스터와 제품책임자 간 중요도 공유
 - 복합기능팀 (Cross-Functional Team) 내에서 대응되는 자원

2015년 12월 29일 화요일

ISO 26262 표준의 단계 별 안전분석 활동



웹에서의 성능테스트 이해와 진단

효과적인 SW자동화 테스팅 수행을 위한 FAQ

대부분의 SW품질관리 전문가들은 SW자동화 테스팅을 매우 효과적인 것으로 평가하고는 있으나, 자동화 테스팅과 수동 테스팅을 구분해서 수행해야 할 최적시기를 선택하는 것은
여전히 의문사항으로 남아 있습니다. 이를 위해 본 보고서에서는 SW자동화 테스팅의 수행에 있어 가장 많이 제기되는 질문들에 대한 적절한 답변을 제공하고자 합니다.

SW자동화 테스팅 수행을 위한 FAQ 
  1. SW자동화 테스팅이란?
  2. 자동화 테스트를 수행해야 하는 경우는 무엇인가?
  3. 테스트 자동화의 우선순위는 무엇인가?
  4. 수동 테스트에 적합한 테스트의 종류는 무엇인가?
  5. 자동화 테스트 선택 시 주의해야할 사항은 무엇인가?
  6. 팀의 지속적인 테스트 자동화 성공 방법은 무엇인가?
마이크 콘의 테스트 자동화 피라미드

적절한 SW 프로젝트 포트폴리오 관리방안을 위한 네 가지 팁

SW 프로젝트 수행 시 일정시간에 단일 프로젝트를 수행하는 경우 외에도 다중 프로젝트를 수행하는 경우가 흔히 발생합니다 . 이에 따라 각 프로젝트에 상호 간섭을 최소화하고 목표한 결과물을 산출할 수 있는 프로젝트 포트폴리오 관리방안을 제시합니다 .

프로젝트 관리자에게 진행 중인 개발업무 외 또 다른 프로젝트를 수행할 수 있는 지 질문했을 때 그 자리에서 ‘ 네 ’ 라고 대답하기는 어려운 것이 보통일 것입니다.
대부분의 프로젝트 관리자에게 과다한 업무 , 불확실한 우선순위 , 비현실적인 출시일정 등에 대한 것들은 일상적인 상황일 것이기 때문입니다.
때때로 PPM(Project portfolio management) 이라고 불리는 프로젝트 포트폴리오 관리방안은 위의 문제 해결을 위한 하나의 방법일 수 있습니다.
본 원고에서는 프로젝트 관리 측면에서의 PPM 에 대해 설명할 것입니다.


Tip 1. 프로젝트 포트폴리오 관리방안이란
Tip 2. IT 부서 수준의 경우
Tip 3. 문제해결을 위한 다른 방법
Tip 4. 앞으로 어떻게 할 것인가

자세히 보기 →

2015년 12월 28일 월요일

소프트웨어 생산성 향상 - 개발 프레임 워크 편

소프트웨어는 시간이 흐를수록 더 복잡해졌고 오픈 소스와 클라우드의 영향으로 다른 시스템과 연계도 많아졌다.  소프트웨어 개발이 점점 어려워지면서 설계와 구현 산출물을 다시 사용할 수 있는 개발 프레임워크가 나타나기 시작했다.

초기에는 자주 사용하는 소스 코드를 모아둔 라이브러리 형태였지만 최근에는 타 시스템과 연계나 다양한 개발 언어 등을 서로 연결하기도 한다. 개발 프레임워크는 오랜 소프트웨어 개발 경험을 가진 개발자일수록 더 필요성을 느끼게 된다. 모듈이나 라이브러리, 개발 환경 등을 재활용하여 새로 개발 할 코드의 시간과 비용을 줄일 수 있기 때문이다.

하지만, 개발 프레임워크를 만드는 것은 깊은 지식과 경험을 필요로 하고 많은 인원과 시간이 소요된다. 처음부터 개발 프레임워크를 만들려고 만드는 것이 아니라 기존에 만든 소프트웨어를 재사용하다가 개발 프레임워크로 구성되는 경우가 많기 때문이다.

  • 개발 프레임워크의 목적과 필요성
  • 개발 프레임워크의 구성 방법과 실행 환경
  • 프레임워크의 최근 동향과 발전 방향


헬스케어 분야 소프트웨어 기술 동향

헬스케어 서비스를 위해서는 시설, 장비, 소프트웨어를 포함한 IT 기술 등 다양한 차원의 기능과 도구가 필요하다. 노령화 사회가 되면서 헬스케어 시장, 특히 IT 융합 의료기기 신사업의 시장이 크게 증폭하고 있다. 이에 따라 헬스케어 소프트웨어의 품질과 안정성도 이슈가 되고 있으며, 그 기술의 변화 또한 빠르게 일어나고 있다. 

현재 헬스케어는 IoT와 연계하여 일상에서 기초적으로 쉽게 수행할 수 있는 건강관리부터 원격진료에 이르기까지 솔루션이 속속 현실화되고 있고, 향후 성장 잠재력 또한 매우 높다고 할 수 있다.

헬스케어 소프트웨어 기술 동향

GE: 중소기업의 헬스케어 투자를 지원하는 협의체를 조직하여 이를 통해 자사 생산 의료기기와 연동되는 사용자 대상 서비스와 어플리케이션을 제공한다.

Apple: iOS8부터 ‘HealthKit’라는 개인건강정보(PHI) 플랫폼을 기본적으로 탑재했다. 사용자들은 하나의 플랫폼 안에서 각종 헬스케어 웨어러블 디바이스와 앱을 사용해 맥박수, 체중, 혈압 등 건강 데이터를 측정할 수 있다. 최근에는 IBM과 B2B형 헬스케어 협력 계획도 발표했다.

Google: 헬스케어 플랫폼 Google Fit을 선보임. 구글핏은 러닝, 사이클, 피트니스 등 다양한 운동 데이터를 측정하여 개인건강정보를 관리한다. 또한, 자체 의료 DB를 포함하여 3rd-party가 제공하는 DNA 정보를 동시에 제공하는 Google Genomics 서비스를 상용화한다.

삼성전자: IT제품, SW기술, 의료DB에 기반한 스마트 헬스케어 5대 신수종 사업 선정. 헬스케어 플랫폼 SAMI와 손목밴드 형태의 웨어러블 디바이스 SimBand에 적극 투자중이다. 이들은 웨어러블 기기와의 연동을 통해 다양한 생체 신호를 실시간 분석하는 개방형 데이터 분석 플랫폼이다. 

Microsoft는 인텔리전스 엔진을 기반으로 하는 Microsoft Health 플랫폼을 2014년 10월에 발표했다. 페이스북은 같은 병을 앓고 있는 페이스북 사용자들을 연결시켜주는 온라인 서포트(Support) 커뮤니티를 시작으로 헬스케어 시장 진출을 계획하고 있다.

그룹 포스팅 그룹에 초대합니다.


  SW공학센터 블로그에 정기적으로 글을 게재하고 싶은 분을 찾습니다. 

  • SW공학 현장에서 본인이 수행하는 업무를 소개하고 다른 사람과 공유하면서 본인과 회사의 역량을 알릴 수 있는 기회가 될 것입니다. 
  • 1주에 5회의 포스팅을 3개월 이상 진행하는 분께는 소정의 원고료를 지급합니다. 
  • 신청마감: 2015. 09. 20 까지
  • 참여하고 싶은 분은 아래 이메일로 약력을 보내주시기 바랍니다.
  • 문의: nipasec@gmail.com


2015년 12월 23일 수요일

성공, 도전, 실패 프로젝트의 주요 요소 비교


Standish Group


Forbes: The world's most valuable brands


자료: http://www.forbes.com/powerful-brands/list/

세계 SW 시장 규모 및 전망

2014년 세계 SW 시장(패키지 + IT서비스) 규모는 전년 대비 5.5% 성장한 1조 671억 달러로 추정된다.

  • 2015년 세계 SW 시장 규모는 2014년 대비 4.3% 성장한 1조 1,128억 달러에 이를 것으로 예상 

  • 세계 SW 시장은 2014년부터 연평균 4.5%씩 성장하여 2017년 1조 2,183억 달러 규모에 달할 전망

2015년 12월 22일 화요일

Dev & ops cooperation at Flickr: "10 deploys per day"

Flickr의 John Allspaw(Ops head)와 Paul Hammond(Dev head)가 
Velocity 2009년에서 발표한 영상

왜 DevOps를 해야 할까요?

DevOps는 소프트웨어 개발자와 정보 기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 방법론. 데브옵스는 소프트웨어 개발 조직과 운영 조직간의 상호 의존적 대응 이며 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

그럼, Amazon, Google, Netflix, Facebook, Twitter는 얼마나 자주 배포할까요?








2015년 12월 21일 월요일

DevOps 소프트웨어 딜리버리 하기



DevOps Process

Endless Possibilities: DevOps can create an infinite loop of release and feedback for all your code and deployment targets.




FaceBook, Flickr, Netflix, Etsy은 어떻게 DevOps를 할까요?

배포 주기
  • 매일 마이너 업데이트 
  • 메이저 업데이트 (매주 화요일 오후)

DeploymentAPipeline


출처: http://ieeexplore.ieee.org/xpl/article Details.js p?arnumbe r=644 9236


소스 버젼 관리
  • 모든 FB 개발자는 Single stable branch에서 작업
  • 따라서, long-lived branche들을 머징하는 데 시간 소비 하지 않도록 함 

Tools
  • 코드 리뷰: Phabricator (http://phabricator.org/)
  • 테스트 자동화: Watir (http://watir.com/)
  • 테스트 자동화: Selenium (https://github.com/seleniumhq/selenium)
  • 성능 테스트: Perflab 

커뮤니케이션
  • 자체 IRC서버로 배포할 때 관련자들 다같이 IRC로 커뮤니케이션 (평균 700명)
  • 개발자가 몇 분 내로 답변하지 않을 때는 해당 개발자 개발한 건 빼고 배포 

서비스 모니터링
  • 배포 이후에 트래픽의 변화, 자원 사용량, 프로덕션 환경의 각각 세그먼트들 등
  • 심지어 Facebook에 대한 트윗들까지 모니터링함

Global Public Internet Companies, Ranked by Market Capitalizatiion

자료: http://www.kpcb.com





2015년 12월 18일 금요일

Supplier의 ISO 26262 대응을 위한 개발 환경 구축 사례




철도분야 SW 품질보증 실현 방안

최근 첨단 전자 산업의 발전과 함께 IT와 제조업 간의 융합이 가속화 되면서 철도 분야에서도 하드웨어에 소프트웨어가 결합된 철도시스템 사용이 증가하고 있다. 철도는 신속한 이동과 안전한 교통수단이지만 열차 사고 발생 시 자칫 대형사고로 인한 많은 인명 사상에 이를 수 있는 교통수단이기 때문에 안전에 대한 요구사항이 대단히 높다. 지난 5월, 국내에서 250여 명이 중경상 피해를 입은 지하철 2호선 추돌사고도 신호 시스템의 오류에 의한 것으로 밝혀진 바 있다. 이와 같은 소프트웨어 결함은 심각한 문제를 일으킬 소지가 있기 때문에 오늘날의 SW 품질은 과거와는 비교할 수 없을 정도로 중요한 영역이다.
  1. 철도분야 안전표준 -  IEC 62278/ IEC 62425/ IEC 62279/ IEC 62280 
  2. 안전무결성수준(SIL)의 설정
  3. 철도분야 SW 수명주기
  4. 철도분야 SW 품질보증
  5. (주) 세화 SW품질보증 사례

2015년 12월 15일 화요일

업무 시스템에 기존 소스로 프로세스를 탑재하고 시스템을 매핑하여 관리하기


  • 기 구축된 시스템 분석을 통한 설계 정보 생성과 분석 모델과의 연계를 통해 시스템 운영 기반 구축
  • 시스템과 관련된 모든 정보는 통합 저장소에 탑재되어 관리




정보시스템의 효율적인 운영을 위한 SW공학적 운영 프로세스 적용 방안






ISO 26262 2nd Edition 개정 동향

ISO 26262 1st Edition 제정

  • WG 16에서 IEC 61508 표준을 기반으로 자동차 업계의 요구사항들을 반영하여 개발



1차 개정판 준비 – ISO 26262 2nd Edition
  • 2015년부터 ISO 26262 2nd Edition 작업 시작 --> 2018년 개정판 배포 예정
  • 버스, 트럭(3.5t 이상의 차량) 및 다른 상용 차량에 적용할 수 있도록 확장 (PAS 19284)
  • 4개 미만의 바퀴를 가진 모터사이클이나 기타 다른 차량에 적용할 수 있도록 확장 (PAS 19695)
  • 반도체(Semiconductor) 분야 포함 (PAS 19451)
  • SW Safety Analysis의 표준화된 방법론 제시

2015년 12월 14일 월요일

새로운 SW개발과 가치 창출을 위한 접근 방식



소프트웨어공학적 사고란?



ISO 26262 구조



  • ISO 26262는 총 10개의 파트 / 43개의 조항/ 190개의 요구 활동 / 500 여 페이지로 구성
  • 개발 초기부터 생산, 폐기에 이르는 전체 생명주기에서의 안전 관련 요구사항을 제시
  • System과 HW, SW 모두 V모델 개발 프로세스를 따름
  • 시스템을 설계한 후 HW와 SW 개발이 독립적으로 병행될 수 있는 구조로 구성

2015년 12월 11일 금요일

타 산업 대비 자동차 산업에서의 기능안전 차이점


  • IEC 61508 : 철도, 원자력 등 전 산업 분야의 E/E/PE 에 적용 가능한 기능 안전 표준
  • ISO 26262 : IEC 61508을 근간으로 자동차 산업 분야의 E/E 시스템에 적용되는 기능 안전 표준





기능안전 개념 : 산업별 기능안전 표준

기능안전이란?
전자 제어 시스템에서 기능의 오류로 인한 잠재적 위험상황을 분석하고, 이에 대한 대책을
수립하여 위험을 제거 혹은 최소화 함으로써 사람의 안전을 확보 하는 것


기능안전의 사전적 정의 (ISO 26262 Part 1 Vocabulary)


  • Functional safety (기능안전) : absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems 전기/전자 시스템의 오작동에 의한 위험 요소에 기인한 불합리한 위험이 없는 상태
  • Unreasonable risk (불합리한 위험) : risk judged to be unacceptable in a certain context according to valid societal moral concepts 유효한 사회 도덕적 관념에 따라 특정 상황에서 허용할 수 없을 만한 것으로 판단되는 위험

SW 개발 가시성 확보를 통한 품질관리 개념도(SW Visualization)




2015년 12월 10일 목요일

SW 안전성 보증 프로세스




Safety 국제표준



SW 요구사항 명세서 중점 점검사항



  • 1개의 시스템 안전요구사항은 반드시 1개 이상의 SW Safety Requirement로 대응
  • Safety Functional Requirement 명세 시 “must do” 혹은 “must not do”로 간명하게 표시
  • SW가 HW를 직접 control 하는 경우 인터페이스 정의필요
  • Fault, error, failure handling and system recovery 절차 명세필요

2015년 12월 9일 수요일

SW 통합시험 절차서 중점 점검사항



  • 시스템 통합시험 시나리오 및 시험절차 상세 명세
  • 시험통과 및 실패기준 정의
  • 중단 및 재개 기준 정의: 버전의 차이로 시험항목이나 시험사례에 변경이 발생하는 경우 시험계획서, 시험 절차서를 수정한 후 시험을 재개함

SW 구현 명세서 중점 점검사항



  • Code logic이 설계단계의 safety requirement를 정확히 구현하는가?
  • Safety critical data가 예기치 않은 수단으로 변경되는 경우는 없는가?
  • Code module 사이에 송수신하는 파라미터값이 설계의도와 같이 이행되는가?(structure, physical unit, number & order parameter)

SW 설계 명세서 중점 점검사항



  • 요구사항추적성 분석(시스템 레벨의 안전요구사항에서 SW설계 요구사항으로 상속)
  • SRS 의 요구사항이 누락없이 SDS요구사항으로 trace 되었는가?




Design Safety Analysis 수행내용이 명세 되어야 함.

  • 목적: 모든 safety requirement가 누락없이 명세되고 각 safety requirement에 대한 protection system(failure recover & diagnostic)이 적정하게 설계되었는가?
  • SRS 단계 이전에 Safety analysis가 충분히 수행되었다면 safety critical function 과 normal operating function이 용이하게 구분
  • Safety critical function 과 normal operating function 간의 인터페이스 명세필요



2015년 12월 4일 금요일

제59회 SW공학 Technical 세미나 안내(12/22(화))

안녕하세요.
소프트웨어공학센터 제59회 SW공학 Technical 세미나 안내  임시 페이지 입니다.
사전참가신청 등록이 마감 되었습니다.

감사합니다.

소프트웨어 Verification & Validation 적용기술 - 국제표준 최근 동향


  • 시스템의 개념이 하드웨어, 소프트웨어, 인간작용 등이 복잡하게 연계된 개념으로 확장 
  • 시스템의 생명주기 전 과정을 포괄하는 공통의 프로세스 Framework을 제공 
  • 2012년에 적용범위가 SW에서 System and SW로 변경



발표자료 내려받기 >>>

SW V&V 국내 적용 현황과 수행 목적

SW V&V 국내 적용 현황

 SW V&V 산업체 현황
 - SW safety life cycle 개발 프로세스 적용경험 부족
 - SW safety V&V 시범적용 및 도입단계 6

 SW V&V 적용을 위한 실무적 참조 가이드라인 부재

 공급주체와 관리주체 사이의 SW V&V 결과수준에 대한 인식차이 존재

SW V&V 수행 목적 이해 

 SW V&V는 개발자들간 방법/과정에 대한 상호 약속.
- 다수개발자가 정의된 약속에 따라 개발한 결과물 검토

 SW V&V는 Life cycle 모든 단계 Task 결과물 완전성 검증 7
- 따라서 개발시작 단계부터 V&V 는 시작되어야 함.

 타인에게 검사를 받기 위하여 SW V&V를 수행하는 것이 아니라 일관성 있는 개발을 위한 작업 프레임이다.

 개발속도가 느려지는 것 같지만 결과적으로 원하는 결과물 수준에 최대한 근접 할 수 있음