SW 공학수준 조사 (모바일 쿠폰 지급)

정보통신산업진흥원 소프트웨어공학센터에서는 국내 SW업계의 공학 수준을 파악하고
이를 업계발전과 정책에 반영하고자, 매년 SW공학수준 조사를 실시하고 있습니다.

본 조사는 2010년부터 매년 발간되는 SW공학백서의 기초자료로 활용되며,
SW공학백서는 SW개발 프로젝트를 성공으로 이끌기 위한 가이드를 제공하고 있습니다.

1. 참여대상: SW개발자 및 SW품질부서 담당자
2. 주관기관: 정보통신산업진흥원(NIPA) 소프트웨어공학센터
3. 조사기간: 2016년 2월 15일까지
4. 설문조사 작성내용: 2015년에 종료된 SW개발 프로젝트 경험에 근거하여 작성
5. 설문에 참여하신 분들에게는 3만원 상당의 (백화점) 모바일 쿠폰 지급

설문 참여 >>>

제60회 SW공학 Technical 세미나 안내(1/28(목)

SW Quality Insights 제 60회 소프트웨어 공학 Technicl 세미나에 여러분을 모십니다.
본 세미나는 국내외 SW전문가를 초빙하여 SW개발 관련 최신 기술 동양을 파악하고 개발과정에서의 경험을 공유하는 등 SW개발자와 관리자의 역량강화를 위해 매월 지속적으로 개최하고 있습니다.

세미나 신청하러 가기 →

애자일 회고를 가능하게 하는 7가지 팁

애자일 회고(Agile Retrospective)는 애자일 방법에서 말하는 한 주기나 출시를 완료한 뒤, 관련 팀이 모여서 다음 주기나 출시를 위한 개선점과 시사점을 도출하는 과정을 말합니다.

효과적인 애자일 회고는 프로젝트 기간 중에 발생한 이슈나 문제점을 파악하고 이에 대한 대응을 통해 제품의 품질을 증진시켜나가는 필수적인 프레임웍으로 효과적인 애자일 회고를 위한 방안을 제시합니다.

애자일 회고(Agile retrospective)란?

애자일 회고는 애자일 소프트웨어 개발의 각 주기(iteration) 마지막에 열리는 회의로 회고 동안에 팀은 주기에서 발생한 것을 반성하고 향후 프로젝트 개선을 위한 액션들을 규저합니다.

애자일 회고 동안 각 팀원들은 다음의 질문에 답을 하도록 합니다.

이처럼 애자일 회고는 '습득된 교훈(Lessons Learned)'회의라고 생각 할 수 있는데, 이를 통해 애자일 개발 팀은 각 주기 간 발생한 모든 일들이 어떻게 진행되었는지를 반영하고 다음 주기에 어떤 변화를 이끌 것인지를 결정합니다.

애자일 회고를 원활하게 하는 7가지 팁

1. 형식을 설명하고 수행(Explain ans Enforce format)
2. 모든 것을 말하는 대로 기록(Write Everything Down Verbatim)
3. 주의 깊게 분류(Categorize carefully)
4. 조치 항목들은 의도를 가지고 있어야 함(Action Items Should Have Intent)
5. 조치 항목들은 명확해야 함(Action Items Should Be Falsifiable)
6. 조치 항목들은 한명의 책임감 있는 담당자가 필요(Action Items Need a Single Partty)
7. 회고에서 무엇이 발생하고 유지 되는가 확인(What Happens In Retro, Stays In Retro)

자세히 보기 →

대규모 애자일기반 소프트웨어 개발하기 Part 1

소프트웨어 응용시스템의 크기 측정응ㄹ 위해서는 많은 종류의 분석 및 의사결정이 필요합니다. 작업공수 및 크기를 측정하기 위해 소프트웨어 프로젝트 팀이 사용한 세 가지 대중적인 방법SP(Story Point, 스토리 점수), UCP(Uses Case Point, 유즈 케이스 점수), FP(Fuction Point, 기능 점수)를 살펴보고자 하는데, 세 가지 측정 방법 중에서 FP 만이 유일하게 국제표준인 ISO/IEC20926:2009에 기반을 두고 있습니다.

유즈 케이스 점수(UCP)는 Clem와 Cohn 그리고 Schneider와 Winters에 의해 기술된 논문에 기반을 두고 있으며, 스토리 점수는 스크럼 방법론에서 벗어나 개발 타스크의 완성에 대한 복잡도 수준을 정하며 애자일 SW개발에 있어 구현 난이도와 추정기간을 포함하는 등 매우 높은 연관성을 보이고 있습니다.

이러한 세 가지 측정방법의 비교는 문헌에서 제한적인데다 측정방법들이 왜 비교되지 말아야 되는지에 관하여 이유는 많습니다. 그러나 프로젝트, 산출물, 조직을 비교하고 대조하여 그 필요성 여부를 따져보는 것은 자연스러운 일일 것입니다.

비교를 위해 코드라인을 FP로 전환하는 작업을 하는 것은 주의가 필요합니다. 그러나 측정방법들이 다소 다른 목적으로 독립적으로 개발된다고 해서 그것들이 유용하게 결합되어 질 수 없다는 것을 의미하는 것은 아닙니다. 연구가 진행되어온 이후 줄곧 측정방법들 사이에 의미 있는 관련성의 가능성을 간과 할 수 없습니다.

• 스토리 점수에 대한 고찰
• 유즈 케이스 점수에 대한 고찰
• 기능 점수에 대한 고찰

자세히 보기 →

특징 선택을 이용한 소프트웨어 재사용의 성공 및 실패 요인 분류 정확도 향상

특징 선택은 기계 학습 및 패턴 인식 분야에서 중요한 이슈 중 하나로, 분류 정확도를 향상시키기 위해 원본 데이터가 주어졌을 때 가장 좋은 성능을 보여줄 수 있는데 데이터의 부분집합을 찾아내는 방법입니다. 즉, 분류기의 분류 목적에 가장 밀접하게 연관되어 있는 특징들만을 추출하여 새로운 데이터를 생성하는 것입니다. 소프트웨어 재사용의 성공 요인과 실패 요인에 대한 분류 정확도를 향상 시키기 위해 특징 부분 집합을 찾는 실험을 하였습니다. 기존 연구들과 비교 분석한 결과, 본 원고에서 찾은 특징 부분 집합으로 분류했을 때 가장 좋은 분류 정확도가  보이는 것을 확인하였습니다.

분류 알고리즘(Classification algorithm)

• SVM
• RBFNetwork
• NaiveBayes
• BatesNet

특징 선택(Feature Selection)

특징선택이란 전체 속성 집합에서 분류에 결정적인 영향을 미치는 부분 집합의 조합을 찾는 기법입니다.

자세히 보기 →

자동화 보안툴을 이용한 데브옵스와 보안의 공존 보안

정보보안은 대부분의 기업들에게 있어 SW출시를 지연시키는 등 이윤은 내지못하고 비용만을 발생시키는 코스트 센터(cost center)로 인식하고 있는 반면, 데브옵스(DevOps)는 SW개발, 출시 등의 시간을 절감하는 측면에서 각광받고 있습니다. 그러나, 데브옵스의 신속성이라는 특성은 보안을 일부 희생시킬 수 있는 여지가 있음에 따라 데브옵스가 성공하기 위해서는 보안성이 더욱 중요시되고 있으며 문제를 해결할 수 있는 대안 중 하나가 될 수 있습니다.

기업 경영측과 IT리더들은 현재 부각되고 있는 데브옵스가 소프트웨어 개발과 제품을 릴리즈하기 위해 필요한 시간을 감소시키는데 있어 최상인 반면, 정보 보안은 소프트웨어 개발과 출시를 늦추는 등의 코스트 센터로 인식하고 있는 등 두 관계가 상반되는 견해를 보입니다.

데브옵스 전문가인 데이비드 그린슈타인에 의하면 데브옵스는 최근 IT 기업에서 경쟁사보다 빠르게 제품이나 기능을 소개해야 할 필요성이 증가하기 때문에 추진될 수 밖에 없는 문화적 변화의 산물이라고 밝힙니다.

• 보안 툴의 자동화 필요성
• 최상의 보안 실행에 위한 데브옵스의 새로운 관점

자세히 보기 →

코드 품질을 향상시키는 6가지 코드 리팩토링 패턴

소프트웨어 공학에 있어 코드 리팩토링은 컴퓨터 프로그램의 소스 코드를 수정하는 것을 말하는데, 복잡한 소스를 유지보수 측면에서 편리하게 하거나 내부 구조를 개선하여 확장성을 높이거나 능률을 향상시킬 수 있도록 하는 것입니다. 이에 대해 코드품질을 향상시키기 위해 패턴으로 정규화 시키고 궁극적으로 더 좋은 설계를 얻을 수 있도록 하는 6가지 코드 리팩토링 패턴을 소개합니다.

다섯 가지의 코드 악취(Code Smell)

과거 개발코드를 검토해 본 결과, 코드 품질이 이슈를 가지고 있는 이들 대부분의 코드에 걸쳐 다음과 같은 공통적인 5가지 코드 품질 저하 요인을 발견하게 되었습니다.

1. 거대한 클래스(Large Class)
2. 긴 메서드(Long Method)
3. 몇 개의 메서드 인수(Several Method Parameters)
4. 전역에 사용된 리터럴 상수(Literal Constants Used Everywhere)
5. 애매한 메서드 이름(Vague Method Names)

코드 악취를 다루기 위한 6가지 리팩토링 패턴

1. 클래스 추출 / 메서드 이동(Extract Class / Move Method)
2. 메서드 추출(Extract Method)
3. 조건문 분해(Decompose Conditional)
4. 파라메터 객체 소개/모든 객체보존(Introduce Parameter Objet / Preserve Whole Objet)
5. 매직 넘버를 기호 상수로 대체(Replace Megic Nember with Symbolic Constants)
6. 메서드 네임변경(Rename Method)

자세히 보기 →