동료검토 계획서란 연구 수행을 통해 창출된 연구결과물이 정의된 요구사항을 충족하는지 이해관계자들과 함께 검토하고 확인하는 동료검토 활동에 대한 계획 및 방법을 정의한 문서이다.
동료검토 계획서에 반드시 포함되어야 할 사항은 다음과 같음
① 개요: 동료검토 적용 범위, 목적, 관련 표준
② 동료검토 활동: 동료검토 절차, 절차 별 수행활동
③ 동료검토 대상 산출물
2016년 3월 31일 목요일
동료검토 결과 보고서 구성 항목별 작성 방법
※ 동료검토 결과서는 보통 MS Excel등의 툴을 이용하여 작성하므로 표지 및 목차, 테스트 개요 등을 작성하지 않고 한 면에 모든 구성을 표현한다.
1. 동료검토 일반 사항
○ 동료검토 수행 계획(동료검토 일시 및 장소, 참석자 및 참석자 별 역할)을 명시
○ 회의 전 준비자료(검토 대상 산출물, 사전 검토물이나 참조 자료)을 명시
○ 고려사항
1. 동료검토 일반 사항
○ 동료검토 수행 계획(동료검토 일시 및 장소, 참석자 및 참석자 별 역할)을 명시
○ 회의 전 준비자료(검토 대상 산출물, 사전 검토물이나 참조 자료)을 명시
○ 고려사항
- 동료검토 결과 보고서를 작성하기 위한 표준(사용도구, 표준 표기법, 표준 양식 등)에 맞게 기술
- 동료검토에 참여할 역할(검토 리더/서기/작성자/발표자/검토자 등)과 참여자를 기술
- 동료검토회 참석자들의 기술적 검토 관점 및 기준을 기술
2. 동료검토 수행 결과
□ 검토 의견 기술
- 결함이 발견된 검토 대상 산출물의 위치( 페이지 및 라인 수) 기록
- 발견된 결함 내용 및 해결 방안을 상세히 기술
- 결함을 발견한 검토자를 기록
- 발견된 결함에 대해 검토자가 생각하는 심각성 및 프로젝트 일정 및 비용에 미치는 영향도를 상⋅중⋅하로 표기
□ 조치 결과 기술
- 동료검토 결과 검토 의견 별 조치 결과 내용을 요약하여 기록
- 검토 의견에 대해 조치 완료 예정일을 기록
- 동료검토 의견에 따라 시정된 항목을 기술
- 관련자들로부터 재작업, 사후조치 및 조치사항 완료에 대해 확인
□ 동료검토 수행 결과 작성 시 고려사항
- 동료검토 결과 기술 내용은 결함 내용, 검토 처리 결과, 소요 공수, 검토 결과 승인을 포함
- 결함내용 중 조치가 필요한 항목을 식별하고 담당자를 할당
- 조치가 필요한 항목의 처리 완료 여부를 확인
- 사전 검토, 검토 회의, 재작업, 사후조치 등의 동료검토에 소요된 공수를 명시
동료검토 결과 보고서
동료검토 결과 보고서는 연구수행을 통해 창출된 연구결과물이 정의된 요구사항을 충족하는지 이해관계자들과 함께 검토하고 확인하여 품질 보증 및 시정조치를 수행한 활동에 대한 결과물이다.
동료검토 결과 보고서에 반드시 포함되어야 할 사항은 다음과 같다.
동료검토 결과 보고서에 반드시 포함되어야 할 사항은 다음과 같다.
- 동료검토 일반 사항: 동료검토 대상 산출물 명, 해당 프로젝트명, 일시, 장소, 참석자 및 역할, 참고자료(표준, 체크리스트) 등
- 동료검토 수행결과: 검토의견 및 조치 결과
2016년 3월 30일 수요일
소프트웨어 개발자가 읽어 볼 만한 40개 블로그
출처: Security Innovation Europe
- Code Simplicity
- Joel on Software
- Scott Berkun
- Coding Horror
- Scott Hanselman
- /\ndy
- Paul Graham’s Essays
- Federico Cargnelutti
- DailyJS
- David Walsh
- Pontikis
- Six Revisions
- Web Appers
- Ajaxian
- ProgrammableWeb
- Martin Fowler
- Eric Sink
- The Daily WTF
- UIE Brainsparks
- PragDave
- Silk and Spinach
- YTechie
- Bit-Player
- Exploration Through Example
- Clarke Ching Rolls Rocks
- Jonathan Kohl
- Word Aligned
- Technology, Strategy, People & Projects
- David Chelimsky
- Ruminations of a Programmer
- Herding Cats
- My Secret Life as a Spaghetti Coder
- Software by Rob
- Implementing Scrum
- Succeeding with Agile
- Regular Geek
- Good Coders Code, Great Reuse
- secretGeek
- Otaku, Cedric’s Blog
- 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억달러 규모에 달할 것으로 예상된다.
시스템 라이프사이클에 따른 소프트웨어 아키텍트의 3가지 역할
John Klein (Architecture Practices Initiative)
"아키텍처는 구조들의 결합체로서 시스템을 설명하는 논리를 제공한다. 각 구조는 구성요소, 요소들간의 관계, 그리고 요소와 관계의 특성으로 구성된다."
그리고, 아키텍처 전문가는 3가지 역할을 수행할 수 있어야 한다.
시스템 디자인을 시작할 때, 아키텍트는 구조적으로 중요한 기능과 품질 요구사항을 정의해야 한다. 그리고, 요구사항을 활용해서 개념적으로 통합된 개요도를 디자인한다. 시스템 디자인에서 가장 중요한 것은 개념 통합이 내부 일관성, 즉 구축과 운영에서 동일한 결과가 동일한 방법에 의해서 만들어지는 로직을 제공해야 한다는 것이다. 이 역할은 소프트웨어 개발 프로젝트의 초기 단계에서 매우 중요하다. 특히, 여러 팀을 도와 효과적으로 협업을 이끌어내야 할 경우 더욱 중요하다.
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개의 동향으로 정리할 수 있다.
모바일 앱 개발의 보안강화를 위한 스프링 시큐리티 프레임워크
‘스프링 프레임워크 (Spring Framework)’ 는 자바 플랫폼 을 위한 오픈소스 애플리케이션 프레임워크 로서 간단히 스프링 (Spring) 이라고도 불린다. 아키텍처의 중요성이 강조되면서 조명받기 시작하여 엔터프라이즈 어플리케이션 개발의 복잡성을 줄여주고 , 모든 기능을 종합적으로 제공하는 경량화된 솔루션이다 . 우리나라 전자정부의 웹 서비스 개발 시, 사용을 권장하고 있는 전자정부 표준프레임워크 의 기반 기술로도 쓰이고 있다.
그 중에서도 ‘스프링 시큐리티’ 는 스프링 프레임워크의 하위 개념으로, ‘웹 보안’ 에 관련된 프레임워크이다. 스프링 시큐리티는 강력하면서도 사용하기가 쉽고, 게다가 단 몇 십줄의 코드만으로도 대형 웹 서비스사와 비슷한 수준의 보안을 유지할 수 있다는 장점이 있다. 물론 기업에서 필요한 시스템에 적합한 시스템을 만들기위해서는 적절한 튜닝이 필요하겠지만 그에 따른 스프링 시큐리티는 정말최상 중 최상의 선택이 아닐 수 없다. 스프링 시큐리티는 수 년간의 오픈소스 개발로 인하여 많은 노하우가 녹아있지만, 국내에서는 상대적으로 유명하지 않고 소개되어 있는 곳도 많지 않은 편인 ‘ 스프링 시큐리티 ’ 에 대해 KBS 기술본부 시스템운용부 강자원 기술사로부터 조언을 구할 수 있었다.
< KBS 기술본부 시스템운용부 강자원 기술사 >
1. 스프링 시큐리티 프레임워크의 정의와 역할
2. 스프링 프레임워크의 핵심
3. 스프링 시큐리티 프레임워크 사용방법
4. 스프링 시큐리티 프레임워크 아키텍처
|
Q) 스프링 시큐리티 프레임워크를 한마디로 정의하자면 무엇인가요?
스프링 시큐리티 프레임워크는 필요한 인증, 권한 및 보안관련 기능들을 손쉽게 사용할 수 있게 지원해주는 프레임워크입니다. 구현은servlet filter 및 Spring AOP 기반이며 유연한 설계로 다양한 확장 및 커스터마이징이 가능합니다. 또한, 비즈니스 로직과 인증, 권한로직을 90% 이상 분리가 가능하며 구축된 프레임워크의 재활용과 기존 스프링 기반의 레거시 시스템에 적용할 때 매우 유용한 장점이있습니다.
Q) 왜 스프링 시큐리티 프레임워크를 사용하는 건가요?
보안강화를 위해서 어떤 역할을 하는지 궁금합니다.
기본 설정만으로도 일반적인 기업 인증 시스템과의 연동이 바로 가능하고 설정을 제외하고 아주 적은 노력만으로도 각 상황에 보안을 적용할 수 있습니다.
또한, 스프링 시큐리티를 사용하면 다음과 같은 일들을 할 수 있습니다.
- 시스템 사용자를 개별 사용자를 세분화 한다.
- 사용자 역할에 따라 권한부여 레벨을 부여한다.
- 사용자 군에 사용자 역할을 부여한다.
- 애플리케이션 리소스에 대해 전역으로 인증규칙을 적용한다.
- 모든 애플리케이션 아키텍처 레벨에서 권한 부여 규칙을 적용한다.
피드 구독하기:
글
(
Atom
)