2016년 3월 31일 목요일

동료검토 계획서

동료검토 계획서란 연구 수행을 통해 창출된 연구결과물이 정의된 요구사항을 충족하는지 이해관계자들과 함께 검토하고 확인하는 동료검토 활동에 대한 계획 및 방법을 정의한 문서이다.

동료검토 계획서에 반드시 포함되어야 할 사항은 다음과 같음
① 개요: 동료검토 적용 범위, 목적, 관련 표준
② 동료검토 활동: 동료검토 절차, 절차 별 수행활동
③ 동료검토 대상 산출물


작성자: 댓글 없음 :

동료검토 결과 보고서 구성 항목별 작성 방법

※ 동료검토 결과서는 보통 MS Excel등의 툴을 이용하여 작성하므로 표지 및 목차, 테스트 개요 등을 작성하지 않고 한 면에 모든 구성을 표현한다.

1. 동료검토 일반 사항

○ 동료검토 수행 계획(동료검토 일시 및 장소, 참석자 및 참석자 별 역할)을 명시
○ 회의 전 준비자료(검토 대상 산출물, 사전 검토물이나 참조 자료)을 명시
○ 고려사항

  • 동료검토 결과 보고서를 작성하기 위한 표준(사용도구, 표준 표기법, 표준 양식 등)에 맞게 기술
  • 동료검토에 참여할 역할(검토 리더/서기/작성자/발표자/검토자 등)과 참여자를 기술
  • 동료검토회 참석자들의 기술적 검토 관점 및 기준을 기술


2. 동료검토 수행 결과

□ 검토 의견 기술
  • 결함이 발견된 검토 대상 산출물의 위치( 페이지 및 라인 수) 기록
  • 발견된 결함 내용 및 해결 방안을 상세히 기술
  • 결함을 발견한 검토자를 기록
  • 발견된 결함에 대해 검토자가 생각하는 심각성 및 프로젝트 일정 및 비용에 미치는 영향도를 상⋅중⋅하로 표기

□ 조치 결과 기술
  • 동료검토 결과 검토 의견 별 조치 결과 내용을 요약하여 기록
  • 검토 의견에 대해 조치 완료 예정일을 기록
  • 동료검토 의견에 따라 시정된 항목을 기술
  • 관련자들로부터 재작업, 사후조치 및 조치사항 완료에 대해 확인

□ 동료검토 수행 결과 작성 시 고려사항
  • 동료검토 결과 기술 내용은 결함 내용, 검토 처리 결과, 소요 공수, 검토 결과 승인을 포함
  • 결함내용 중 조치가 필요한 항목을 식별하고 담당자를 할당
  • 조치가 필요한 항목의 처리 완료 여부를 확인
  • 사전 검토, 검토 회의, 재작업, 사후조치 등의 동료검토에 소요된 공수를 명시
작성자: 댓글 없음 :

동료검토 결과 보고서

동료검토 결과 보고서는 연구수행을 통해 창출된 연구결과물이 정의된 요구사항을 충족하는지 이해관계자들과 함께 검토하고 확인하여 품질 보증 및 시정조치를 수행한 활동에 대한 결과물이다.

동료검토 결과 보고서에 반드시 포함되어야 할 사항은 다음과 같다.


  1. 동료검토 일반 사항: 동료검토 대상 산출물 명, 해당 프로젝트명, 일시, 장소, 참석자 및 역할, 참고자료(표준, 체크리스트) 등
  2. 동료검토 수행결과: 검토의견 및 조치 결과
작성자: 댓글 없음 :

2016년 3월 30일 수요일

소프트웨어 개발자가 읽어 볼 만한 40개 블로그

출처:  Security Innovation Europe


  1. Code Simplicity
  2. Joel on Software
  3. Scott Berkun
  4. Coding Horror
  5. Scott Hanselman
  6. /\ndy
  7. Paul Graham’s Essays
  8. Federico Cargnelutti
  9. DailyJS
  10. David Walsh
  11. Pontikis
  12. Six Revisions
  13. Web Appers
  14. Ajaxian
  15. ProgrammableWeb
  16. Martin Fowler
  17. Eric Sink
  18. The Daily WTF
  19. UIE Brainsparks
  20. PragDave
  21. Silk and Spinach
  22. YTechie
  23. Bit-Player
  24. Exploration Through Example
  25. Clarke Ching Rolls Rocks
  26. Jonathan Kohl
  27. Word Aligned
  28. Technology, Strategy, People & Projects
  29. David Chelimsky
  30. Ruminations of a Programmer
  31. Herding Cats
  32. My Secret Life as a Spaghetti Coder
  33. Software by Rob
  34. Implementing Scrum
  35. Succeeding with Agile 
  36. Regular Geek
  37. Good Coders Code, Great Reuse
  38. secretGeek
  39. Otaku, Cedric’s Blog
  40. A Geek with a Hat

작성자: 댓글 없음 :

소프트웨어 정의 WAN(Software-Defined WAN) 시장의 성장

IDC에 따르면, 소프트웨어 정의 네트워킹(Software-Defined Networking)은 기업이 클라우드 전략를 최적화 하려는 노력에 맞춰서 크게 성장할 것으로 예측된다. SDN은 데이터센터에 활발하게 적용되고 있고 네트워크에 민첩성(agility)과 대응성(responsiveness)을 기대만큼 제공하고 있다. 또한, 클라우드 애플리케이션과 서비스 요구사항을 최적화할 수 있도록 광대역 네트워크(WAN)로 중심이 이동하고 있다. 

IDC의 연구조사에 따르면, 전세계 소프트웨어정의 WAN (SD-WAN) 시장은 연평균(CAGR) 90% 이상 성장세를 보이며 2020년 60억달러 규모에 달할 것으로 예상된다. 

SD-WAN의 등장은 최근의 형성된 시장으로 이전에는 Hybrid WAN 아키텍처가 존재했다. SD-WAN을 도입하면 비즈니스 어플리케이션을 비용  효과 높게 제공할 수 있고, 원격 사이트에서 발생하는 다양한 운영 요구사항을 해결할 수 있고, SaaS(software-as-a-service)나 클라우드 기반 서비스를 최적화 시키며, 자동화를 통해 연결된 소단위 IT의 효율성을 향상시킬 수 있다.

작성자: 댓글 없음 :

시스템 라이프사이클에 따른 소프트웨어 아키텍트의 3가지 역할

John Klein (Architecture Practices Initiative)

"아키텍처는 구조들의 결합체로서 시스템을 설명하는 논리를 제공한다. 각 구조는 구성요소, 요소들간의 관계, 그리고 요소와 관계의 특성으로 구성된다."
그리고, 아키텍처 전문가는 3가지 역할을 수행할 수 있어야 한다.

1. 초기 디자이너(Initial Designer)
시스템 디자인을 시작할 때, 아키텍트는 구조적으로 중요한 기능과 품질 요구사항을 정의해야 한다. 그리고, 요구사항을 활용해서 개념적으로 통합된 개요도를 디자인한다. 시스템 디자인에서 가장 중요한 것은 개념 통합이 내부 일관성, 즉 구축과 운영에서 동일한 결과가 동일한 방법에 의해서 만들어지는 로직을 제공해야 한다는 것이다. 이 역할은 소프트웨어 개발 프로젝트의 초기 단계에서 매우 중요하다. 특히, 여러 팀을 도와 효과적으로 협업을 이끌어내야 할 경우 더욱 중요하다.
2. 확장자(Extender)
최초 출시 후에는 일반적으로 빠르게 가치를 부가하려는 압력이 있기 마련이다. 예를 들어, 상업 제품의 초기 출시는 중요한 선행투자에 의해 이루어지며, 시스템 확장 단계에서 그 투자 자금을 빨리 회수하려는 경향이 있다. Facebook, Dropbox, PayPal 처럼 상업용 시스템의 대부분은 다른 시스템과 통합하여 상대적으로 적은 개발 비용을 들이고도 큰 자금회수에 성공할 수 있었다. 마찬가지로, 기업의 IT 환경에서 새로운 시스템을 다른 기업 시스템들과 통합하는 것은 자동화를 향상시키고 가치를 빠르게 높인다.

따라서, 소프트웨어 아키텍트는 구축한 시스템에 대한 이해와 함께 인터페이스에 대해서도 이해하는 것이 중요하다. 그리고, 중요한 미들웨어, API, 커뮤니케이션 프로토콜 등 시스템 통합에 필요한 기술들을 이해하고 있어야 한다.

이런 이해를 통해 아키텍트는 어떤 통합 유형이 쉽고 빠를 수 있는지 정할 수 있다. 그리고 어느 특정 외부 시스템과 통합되는 것이 최선인지도 알 수 있다. 시스템 확장 단계에서 흔히 성공한 개인들은 초기 개발팀의 구성원으로서 그 시스템이 어떻게 만들어졌는지, 명시되지는 않았지만 어떤 기능을 발휘할 수 있는지, 그리고 부작용이 무엇인지 등을 잘 이해하는 사람이다.

3. 지속하게 하는 사람(Sustainer)
시스템이 상당시간 운영되고 나면 이후는 유지보수 비용이 올라가게 된다. 따라서, 관심은 장기유지로 이동하게 되고 가치를 계속 제공하면서 아키텍처나 운영에 거의 변화가 없도록 하는 것이 목표가 된다.

아키텍트 입장에서는, 이런 유지보수 단계에서의 초점은 시스템 가치를 지속하기 위한 분석, 변호, 소통이 된다. 세부 역할에는 최근의 사례와 일치하는 새로운 패턴을 활용하여 시스템에서 그 기술과 유형을 모델링하는 것도 포함된다. 

따라서, 이 단계에서는 이해관계자들(의사결정권자 포함)에게  시스템의 지속적인 적합성과 새로운 환경에서 가치를 어떻게 부여할 것인지를 설명할 수 있는 문서를 작성하는 스킬이 요귀된다. 
작성자: 댓글 없음 :

2016년 3월 29일 화요일

2016년 SW 테스트 자동화 동향

소프트웨어 개발 전체에서 테스팅이 차지하는 비중은 50% 정도 된다. 따라서, 자동화를 통해 테스팅 비용을 줄이고 효과를 향상시키는 것이 매우 필요하며, 그로 인해 프로젝트 시작 단계에서부터 어떤 테스팅 도구를 사용할 것인가를 결정하는 것 또한 중요한 이슈가 되고 있다.

가트너그룹에서는 SW테스팅 도구 우수성을 3가지 조건으로 판단하고 있다. 

 

이 기준에 따르면, 선두를 달리는 SW테스팅 도구를 제공하는 업체를 Leaders, Challengers, Visionaries, Niche Players의 4개 영역으로 구분할 수 있다.
 

최근에 32개국 1,560명의 테스팅 전문가와 IT 책임자를 대상으로 한 설문조사에서 SW 테스팅은 크게 4가지 방향으로 갈 것으로 예측된다.

- 지속적이고 자동화된 시큐리티 테스팅이 핵심 전략이 될 것이다.
- 애자일과 데브옵스 (DevOps)가 테스팅에서 중요한 위치를 차지할 것이다.
- 정시에 효율적으로 어플리케이션을 출시하는 것에 대해 예측분석이 주요 역할을 수행할 것이다.
- 고객과 비즈니스 품질이 중요한 영역이 될 것이다.

설문으로 파악한 4가지 방향 외에 다른 전문가들의 의견, 주요 지표, 산업보고서 등을 기초로 다시 15개의 동향으로 정리할 수 있다.
 

작성자: 댓글 없음 :
피드 구독하기: 글 ( Atom )