소프트웨어공학센터 원-포인트 클리닉 Round Table 안내 (12/3(목)~4(금))

안녕하세요.

소프트웨어공학센터 원-포인트 클리닉 Round Table  안내 임시 페이지 입니다. 

아래 참가신청서를 다운로드 하신 후 접수처 담당자 이메일로 접수 하시기 바랍니다.

불편을 끼쳐드려 대단히 죄송합니다.

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

소프트웨어와 웹 서비스 그리고 플랫폼까지 글로벌한 최고의 경쟁력을 갖추고 있다는 미국이 온라인 건강보험 마켓플레이스 Health Care(www.healthcare.gov) 사이트를 10 월 1 일 오픈하고 현재까지 해결을 하지 못하고 큰 곤혹을 치루고 있습니다 . 오바마 행정부가 선진국으로는 뒤늦게 전 국민 의료보험 가입이라는 개혁 법안을 온갖 노력을 다해서 통과시켰는데 , 정작 가입자를 받기위한 웹사이트가 성능문제로 접속조차 어렵기 때문입니다 . 이처럼 기능이 동작하더라도 성능을 고려하지 못한다면 낭패를 겪을 수밖에 없다는 점을 잘 보여주는 사례라 할 수 있습니다 .

웹기반 시스템에서 성능은 분석 단계부터 서비스를 오픈하는 릴리즈 단계까지 정확한 목표를 기준으로 테스트되고 성능목표를 위해 튜닝 작업이 꾸준히 이루어져야 합니다 . 성능테스트는 웹 서비스에서의 병목지점을 파악하고 튜닝하여 성능을 향상시키는 것이 목적입니다 . 또한 시스템의 용량을 산정하고 시스템 확장 계획을 수립하도록 합니다 .

Ⅰ . 성능테스트의 목적 및 방법
Ⅱ . 성능테스트 요소와 지표
Ⅲ . 성능테스트 도구 및 진단
Ⅳ . 결어

자세히 보기 →

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

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

프로젝트 관리자에게 진행 중인 개발업무 외 또 다른 프로젝트를 수행할 수 있는 지 질문했을 때 그 자리에서 ‘ 네 ’ 라고 대답하기는 어려운 것이 보통일 것입니다. 대부분의 프로젝트 관리자에게 과다한 업무 , 불확실한 우선순위 , 비현실적인 출시일정 등에 대한 것들은 일상적인 상황일 것이기 때문입니다.

때때로 PPM(Project portfolio management) 이라고 불리는 프로젝트 포트폴리오 관리방안은 위의 문제 해결을 위한 하나의 방법일 수 있습니다.

본 원고에서는 프로젝트 관리 측면에서의 PPM 에 대해 설명할 것입니다.

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

자세히보기 →

스마트 단말의 감성 인터페이스

인간의 감성 특성을 이해하여 인간의 감성을 충족시키는 제품과 인터페이스를 개발하려는 노력은 그 동안 여러 분야에서 꾸준히 진행되어 왔습니다 . 그러나 “ 감성 ” 이라는 단어를 내세운 제품과 기술 개발의 많은 노력들에 비하여 실질적으로 사용자 감성을 만족시켜 성공한 결과는 많지 않습니다 . 이러한 결과를 분석해 보면 몇 가지 원인을 찾을 수 있습니다 .

• 첫 째 , 연구 개발자들이 “ 인간 감성 ” 의 발생과 변화를 제대로 이해하지 못하고 있다. 
• 둘 째 , 감성에 대한 연구가 인간의 “ 감성 ” 과 “ 감정 ” 의 차이를 명확하게 규명하지 못한 채 성급한 응용에 치우쳐 있다 . 
• 셋 째 , 기술이나 제품과 관련되는 사용자 감성을 명확하고 구체적으로 파악하지 못하고 있다. 

이렇게 감성의 올바른 이해라는 첫 단추를 제대로 끼우지 않은 우리나라의 감성공학은 “ 감성 ” 이라는 단어만 남발하고 있으면서 우리나라 기술과 제품에 대하여 소비자가 인식하는 감성 가치를 높이는 데에는 제대로 기여하지 못하는 상태로 남아있습니다 .

1. 개인용 제품으로서의 스마트 단말 특성
2. 감성의 올바른 이해
3. 스마트 단말의 감성 인터페이스

자세히 보기 →

모바일 애플리케이션 요구사항관리 : 동일한 프로세스, 새로운 도전

모바일 기기활용의 급격한 확산에 따라 모바일 애플리케이션에 대한 기능요구치가 테스크탑 앱 수준과 동일한 상황입니다 . 모바일 기기의 다양성 기반 하에 어떠한 기능이 필수적이며 , 비용효과적인지 등 요구사항분석이 어느 때보다 중요시되고 있음에 따라 , 모바일 애플리케이션 개발 시 직면하는 요구사항관리 측면의 새로운 이슈를 확인하여 제시하고자 합니다 .

• 어떤 디바이스를 지원할 것인가 ?
• 제품 호환성 : “ 지원 ” 의 재해석
• 다른 품질 요소
• 빨리 실패하고 , 빨리 바로잡기 (fail fast, fix fast)

자세히 보기 →

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

Ⅰ. 웹사이트 성능 이해

Ⅱ. 웹사이트 성능 분석

Ⅲ. 웹사이트 성능 최적화

인터넷의 대중화와 통신속도의 향상 그리고 모바일 기술 및 성능 향상은 언제 , 어디서나 웹을 통하여 정보를 얻고 콘텐츠를 소비하며 상거래를 즐길 수 있는 시대를 만들어 주었습니다 . 다만 좋은 콘텐츠와 편리한 사용자 인터페이스를 제공하더라고 기대하는 성능이 충족되지 않는다면 사용자들은 외면할 것입니다 . 일반적으로 웹과 같은 대화형 시스템에서 사용자가 반응을 기대하는 평균 시간은 1 초 이내이며 2~5 초가 걸린다면 시스템이 죽지 않았다는 것을 알려줄 필요가 있습니다 . 만약 웹사이트의 반응이 10 초를 넘어가면 사용자는 해당 사이트를 포기하게 됩니다 . 이처럼 웹사이트의 성능은 반드시 확보되어야만 하는 중요한 요소이라 할 수 있습니다 .

자세히 보기 →

애자일의 핵심성공요건 : 고위경영진의 지원과 리더십

애자일 프로젝트의 성공이 관리주도의 조직변화로부터 시작됨에 따라 애자일 방법론에 대한 고위경영진의 지원 부족은 프로젝트 실패의 가장 큰 요인 중 하나로 작용하게 됩니다. 이에 본 보고서에서는 애자일 기법 적용 시 나타나는 고위경영진의 공통된 오해는 무엇이고 , 이를 극복하고 애자일 프로젝트를 성공시키기 위해 필요한 지원요소는 무엇인지를 제시합니다.

• 고위경영진의 이해 / 참여 없이 적용되는 애자일
• 애자일에 대한 고위경영진의 일반적인 오해들
• 애자일의 성공을 위한 고위경영진의 역할
• CEO 의 지원을 필요로 하는 프로젝트 관리자를 위한 팁

자세히 보기 →

워크플로우 기반의 제품라인 소프트웨어 개발 지원 환경

최근 들어 자동차 , 의료 , 제조 등의 산업분야에서 ICT 기술을 적극적으로 활용한 융합소프트웨어 개발의 중요성이 강조되고 점차 많은 기업들이 세계시장으로 진출을 모색하고 있습니다 . 소프트웨어 개발에 반영해야 하는 휘처 (Feature) 의 수는 증가하고 그에 따라 필연적으로 따라오는 다양성 (Variation) 을 소프트웨어에 반영하기 위한 노력을 기울이고 있습니다 .

소프트웨어 제품라인 공학 (Software Product Line Engineering) 은 소프트웨어를 각각 개별적으로 개발하는 전통적인 소프트웨어 개발 방법의 단점을 보완하여 소프트웨어의 재사용에 따른 고품질과 빠른 시장적시성 (Time-to-Market) 을 보장하여 앞서 설명한 다양성 문제를 해결하는 방법을 제시하고 있습니다 . 개발자는 개발 대상 소프트웨어의 기능 및 비기능 측면을 고려한 공통점과 차이점 분석 (Commonality and Variability Analysis) 을 통해서 핵심 자산 (Core Asset) 을 확보하고 이후 자산들을 조합하여 원하는 소프트웨어 ( 제품 ) 을 개발할 수 있습니다 .

• 워크플로우 기반의 제품라인 소프트웨어 개발도구
• 활용예제

자세히 보기 →

신속한 SW테스트 커버리지 결정을 위한 5단계 가이드

SW 개발 후 테스트를 충분히 수행할 시간여유는 없는 것이 일반적이라고 볼 수 있으며 , 이러한 상황 하에서 신속하게 SW 테스트 커버리지를 결정하는 것은 테스트 수행시간을 확보할 수 있는 방법 중 하나입니다 . 신속한 SW 테스트 커버리지 결정을 위해 FIBLOTS 모델을 활용하고 테스트 범위와 특성을 결정하고 작업리스트를 만드는 등의 방안을 단계별로 제시합니다.

• STEP 1 : 테스트의 범위를 계산하기
• STEP 2 : 테스트하는 각 요소들을 자세히 이해하기
• STEP 3 : 테스트 과업을 합리적인 방법으로 구조화하기
• STEP 4 : 테스트 대상 소프트웨어를 빠른 시간 내 검토해볼 것
• STEP 5 : 기능요소에서부터 테스트를 시작할 것

자세히 보기 →

[SW공학 동영상 10화] SW 아키텍처 설계예시편_Part 1

1. 아키텍처 설계절차
2. 수강 시스템-(예시)
3. 아키텍처 결정요인 추출

동영상 보러 가기 →

소프트웨어 생산성 향상 - 형상관리 편

소프트웨어 생산성 향상을 위한 두 번째로 형상관리에 대해 살펴본다. 소프트웨어 개발 프로젝트는 여러 명이 참여하여 소프트웨어를 만들게 된다. 그러다 보면, 수정한 오류가 다시 나타나고, 며칠 전에 지웠는데 오늘은 다시 보이는 경우가 발생하기도 한다.  하나의 소프트웨어를 여러 사이트에서 따로 사용하기 위해 다수의 버전을 만들기도 한다. 시스템의 기능과 물리적 특성을 고려하여 소프트웨어로 만들고 변경 관리하는 것을 소프트웨어 형상관리(Software Configuration Management)라고 한다.

소프트웨어 형상관리는 생산성을 직접 높이지는 않지만, 프로젝트가 계획대로 진행되고 있는지 확인하고, 개발 환경과 빌드 구조를 관리하여 소프트웨어를 구체화 하는데 도움을 준다. 초기 단계의 형상관리는 단순한 버전관리 정도였지만 점점 복잡해지는 소프트웨어 개발을 위해 프로젝트에서 반드시 필요한 요소로 자리잡고 있다.

이번 회에서는 소프트웨어 형상관리의 정의와 종류에 대해 살펴보고, 소프트웨어 개발 프로젝트에서 형상관리 활동에 대해 알아본다. 마지막으로, 형상관리가 소프트웨어 생산성에 미치는 영향에 대해 살펴본다.

• 형상관리의 정의와 역할
• 소프트웨어 형상관리 수행 활동
• 소프트웨어 형상관리가 소프트웨어 생산성에 미치는 영향

자세히 보기 →

소프트웨어 개발 역량 향상을 위한 SW개발지원서비스(Q-Clinic)

1. 소프트웨어 개발지원센터의 역할

2. 소프트웨어 공학 현장 멘토링

3. Q-Clinic (큐-클리닉) 서비스 - 테스팅프론티어, 코드닥터, SW Visualization 

4. 주요 서비스 사례

5. 제 20회 ‘SW Quality Insight 컨퍼런스’ 안내

'Q-Clinic'서비스의 구성

자세히 보기 →

정부지원 중소형 프로젝트의 PMO 적용 사례 Part 2

[중소형 프로젝트 PMO 의 리스크 관리 방안 및 성공요인]

지난 Part 1 에서는 NIPA 발주 프로젝트 중 『 공개 SW 개발 지원사업 』 산출물 SW 품질검증 프로젝트를 수행하는 검증 기업이 어떻게 PMO 를 조직하고 운영했는지 사례를 살펴보았습니다 . Part 2 에서는 PMO 의 관리 주요 영역에 대한 설명 및 기능 그리고 그 가치에 대해 알아보도록 하겠습니다 .

Ⅰ . PMO 주요 관리 영역

PMO 의 관리 영역은 [ 그림 1] 과 같이 크게 9 가지로 구분할 수 있다 . 프로젝트 상황과 PMO 의 모델 특성에 따라 관리 영역은 조금씩 차이가 있다 .

본 SW 품질 검증 프로젝트에서는 통합관리 , 일정관리 , 자원관리 , 이슈관리 , 위험관리는 PMO 가 직접 관리했으며 , 나머지 영역은 프로젝트 리더에게 위임했다 .

9 대 관리 영역 중 협력사관리는 프로젝트 특성 상 제외했다 .

Ⅱ . 프로젝트 일정 및 자원관리

Ⅲ . 프로젝트 이슈 및 위험관리

Ⅳ . PMO 조직의 주요 기능

Ⅴ . 프로젝트 핵심 성공 요인과 PMO 의 가치

자세히 보기 →

SW개발에 있어 효과적인 유저스토리 생성 방안

최근 , 유저스토리 (user story) 는 SW 개발 프로세스 상 전반부와 중앙에 자리 잡고 있습니다 . 이에 따라 개발팀들은 불필요한 유저스토리를 지나치게 많이 생성해 자원과 시간을 소모하여 팀의 초점이 비즈니스 가치에서 멀어지고 있는 것으로 나타납니다 . 유저스토리 과잉에 대해 살펴보고 , 프로젝트의 요구사항과 궁극적인 목표의 이해를 기반으로 가치 있고 효과적인 유저스토리를 생성하는 방안을 제시하고자 합니다 .

• 예로 살펴본 유저스토리 과잉
• 효과적인 유저스토리를 위한 단계
• 효과적인 회의를 위한 유저스토리 준비
• 유저스토리 관리

자세히 보기 →

성공적인 SW요구사항 개발의 5가지 핵심이슈

소프트웨어 요구사항 개발은 사람과 연관되어 있어 잦은 실수가 우려되는 분야입니다 . 소프트웨어 요구사항 개발에 대한 5 가지 핵심이슈를 통해 어떤 종류의 실수가 발생하는지 , 어떤 이슈들이 반복되고 있는 지를 확인하고 이에 대한 대응방안을 모색해봄으로써 비즈니스 분석가 , 프로젝트 매니저 , 개발자 , 테스터들이 더 나은 요구사항을 개발할 수 있는 실질적인 조언을 제공합니다.

우소프트웨어 요구사항 개발의 5 가지 핵심이슈

1. 요구사항에 대한 두 용어의 관점 차이
2. 요구사항 개발을 위한 두 가지 기법
3. 고위 클라이언트의 참여 유도
4. 불필요한 기능의 배제
5. 빠르면 빠를수록 좋은 테스터의 참여

자세히 보기 →

정부지원 중소형 프로젝트의 PMO 적용 사례 Part 1

중소형 프로젝트 PMO 구성 방안

최근 공공사업 부문 대기업 참여제한법 및 전자정부사업관리 위탁제도 도입으로 중소기업은 사업관리의 전문적 역량을 요구받고 있습니다 . 그 동안 사업관리는 대기업 SI 사들의 영역이었으며 , 중소기업은 역량에서 한계를 보이며 경쟁력을 확보하지 못했습니다 . 정부는 이러한 중소기업들이 사업관리 영역으로 전문성을 확대하고 그 역량을 증진시킬 수 있도록 다양한 관련 교육과 세미나 등을 장려하고 있습니다 . 하지만 무엇보다 중소기업 스스로 다양한 경험을 통해 사업관리 역량을 내재화시켜야 합니다 .

이에 중소기업이 정부지원 SW 개발 사업의 프로젝트에서 어떻게 PMO(Project Management Office) 를 조직하고 사업관리를 수행했는지를 실무 사례를 중심으로 소개하고자 합니다 . 일반적으로 품질검증 프로젝트에 PMO 를 적용한 사례는 없었으나 24 개 프로젝트를 동시에 관리해야하는 특수한 상황으로 PMO 체계를 적용하게 되었습니다 .

Part 1 에서는 해당 SW 개발 사업 및 SW 품질검증 프로젝트 개요와 PMO 구성 전략에 대해 이야기합니다 . Part 2 에서는 과제 수행 시 발생한 이슈들을 어떻게 처리하고 대응했는지 예시를 통해 소개하며 , 과제를 성공적으로 이끈 핵심 성공 요인과 PMO 의 가치에 대해 공유합니다 .

Ⅰ. 프로젝트 개요
Ⅱ. 프로젝트 조직 및 역할
Ⅲ. 프로젝트 특성별 PMO 모델
Ⅳ. 프로젝트 단계별 PMO 역할

자세히 보기 →

효과적 애자일 프로젝트 수행관리를 위한 우수 칸반(Kanban)툴 12선

칸반 (Kanban) 은 애자일 개발프로세스 전반에 걸친 적시개발 (Just in time Development) 을 지원하는 방법론입니다 . 칸반툴은 칸반에 기반 한 프로젝트 관리 지원시스템으로 웹기반으로 활용되며 사용자 규모에 따라 무료 또는 상용버전이 제공됩니다 . 본 지에서는 소프트웨어 개발 라이프사이클의 각 범주에 해당하는 툴 중에서 현재 시장에 출시된 최고 칸반툴 12 선을 소개함합니다 . 

[우수 칸반툴 12 선]

1. TargetProcess
2. LeanKitKanban
3. Hansoft
4. Kanbanery
5. AgileZen
6. KanbanTool
7. SmartQ
8. KanbanPad
9. Simple-Kanban
10. TRICHORD
11. JAM Circle
12. Lino

자세히 보기 →

정형 기법을 이용한 테스트 오라클 생성

융합 시대를 맞이하여 IT 소프트웨어 기술이 항공 , 자동차 , 철도 , 원전 등 안전이 중시되는 (safety-critical) 산업분야에 폭넓게 활용되고 있습니다 . 이들 산업 분야는 안전을 중시하기 때문에 , 높은 수준의 소프트웨어 품질을 요구하고 있습니다 . 산업 분야마다 국제 표준인 DO-178B( 항공 ), ISO 26262( 자동차 ) 등을 제정하고 이를 준수하게 함으로서 소프트웨어의 품질을 높이려고 노력하고 있습니다 .

소프트웨어 품질을 높이기 위해 모든 국제 표준에서 예외 없이 소프트웨어 테스팅을 언급하고 있습니다 . 즉 , 산업 분야와 관계없이 안전이 중요한 경우에는 테스팅을 통해서 실제 시스템을 철저히 검증할 것을 요구합니다 . 성공적인 테스팅이 있기 위해서는 도구 , 교육 등의 지원이 있어야 하지만 , 정확한 오라클 (oracle) 의 존재가 중요합니다 . 소프트웨어공학에서 오라클이란 “ 수행한 테스트가 합격인지 또는 실패인지를 판단하는 메커니즘 ” 입니다 .

1. 선형 시제 논리 합성

2. 테스트 오라클 생성 및 정형적 정의

                              합성 기법을 통한 테스팅 과정의 전체 과정

                                        테스트 오라클 생성 과정

3. 사례 연구 및 분석 

                                                            테스트 환경 구성

                                                 알람 로봇의 테스트 오라클 모델                                          

자세히 보기 →

20th SW Quality Insight Conference안내 (12/2(수))

정보통신산업진흥원에서는 SW개발 시 SW공학기술 및 가시화된 SW품질관리 방안, 사례 등을 통한 SW품질 경쟁력 강화 및 인식 제고를 위해 20회 SW Quality Insight를 개최합니다.

여러분의 많은 참여 부탁 드립니다.

신청하러 가기 →

테스트 자동화 실패를 극복할 수 있는 4 가지 요인

테스트자동화 툴은 비용과 시간을 절감하여 SW 품질향상에 기여하는 것으로 평가되어 왔으나 테스트 자동화가 모든 문제를 해결하는 만능 열쇠는 아닙니다 . 오히려 이를 과신했을 경우 픔질관리 측면에서 프로젝트가 실패하는 경우가 발생하기도 함에 따라 이에 대한 요인을 분석하여 제공하고자 합니다 .

1. 테스트 자동화 프로젝트는 소프트웨어 개발
2. 먼저 수동 테스트에 성공하기
3. 단순히 자동화가 추가된 테스트를 뜻하지 않음
4. 오토파일럿 (autopilot) 을 피하라

마이크 코언( Mike Cohn)의 테스트 자동화 피라미드

자세히 보기 →

성공적인 애자일 데브옵스(DevOps) 적용으로 인도하는 세 가지 핵심요소

최근 많은 전문가들 사이에서 데브옵스 (DevOps) 는 기업 애플리케이션 개발 및 운영 프로세스에 근본적인 변화를 제공하고 있다는 평가를 받고 있습니다 . 그러나 수많은 기업들이 데브옵스 (DevOps) 를 적용하는데 1 년 가까운 시간이 걸리며 , 그 중 일부는 적용에 실패하는 것으로 나타나고 있습니다 . 따라서 데브옵스 (DevOps) 를 효과적으로 적용하는 세 가지 방안 ( 프로세스 흐름 , 지속적인 피드백 , 끊임없는 학습 ) 을 제시하고자 합니다 .

• 첫 번째 방법 : 흐름(The flow)
• 두 번째 방법 : 지속적인 피드백(Consistent feedback)
• 세 번째 방법 : 끊임없는 학습(Continual learning)

자세히 보기 →

제23차 SP인증을 중심으로 한 SW프로세스 교육안내(11/25(수)~11/26(목) 대전)

지역 SW기업 및 방산SW기업의 SW개발품질관리 선진화 및 역량강화 일환으로, 마련된 [제23차 SP인증을 중심으로 한 SW프로세스 교육]에 여러분을 모십니다.

본 교육은 국내 중소 SW기업과 개발 조직의 SW프로세스 품질 향상과 신뢰성 확보에 목적이 있습니다. SW개발자, 품질 담당자, 테스트 담당자 등을 대상으로 SW프로세스 개념과 SP인증 기준 이해를 바탕으로 실제 업무에 필요한 SW 프로세스 교육을 진행합니다.

• 교육대상: 충남소재 중소SW기업 또는 방산SW기업 소속 엔지니어(관리자, 실무자 포함)
• 교육일시: 2015.11.25(수)~26(목), 2일간 09:00~17:50
• 신청기한: 2015.11.23(월)18:00
• 교육장소: 대전정보문화산업진흥원 영상특수효과타운 3층 지역스토리랩 강의실
• 교육비용: 무료(다과 및 중식, 교재/가이드 제공)

신청 하러가기 →

왜 창의적인 요구사항이 나오지 않을까?

최근 기업들은 무한경쟁 시대에 살고 있습니다 . 따라서 혁신적 제품을 출시해야만 글로벌 생태계에서 살아남을 수 있습니다 . 일반적으로 혁신적 제품을 개발하기 위해서는 개발초기에 창의적인 요구사항이 도출되어야 합니다 . 그러나 안타깝게도 대부분의 기업에서 창의적인 요구사항을 도출해 내기가 쉽지 않은 것이 현실입니다 . 물론 국내에서는 삼성전자를 비롯한 소수의 몇몇 기업처럼 창의적인 요구사항 도출을 위해 과거부터 다방면으로 꾸준하게 활동 해온 결과 실제로 많은 성과를 이루어낸 성공사례도 있습니다 . 따라서 본 원고에서 제시하고 있는 현장의 문제점과 제안에 대한 내용은 앞서 제시한 극소수의 성공사례의 기업들을 제외하고 현재 창의적 요구사항을 효과적으로 도출하지 못하고 있는 벤처나 , 중소기업을 포함한 대부분의 기업들을 대상으로 합니다 . 

그러면 왜 기업에서 창의적인 요구사항이 나오지 않는 걸까 ?

본 원고에서는 위의 문제를 개선하기 위해 일반기업들의 개발 현장에서 창의적인 요구사항이 도출되지 않고 있는 근본적인 원인에 대해 면밀히 살펴보고 효과적으로 도출 할 수 있는 방법에 대해 고민하여 개선방안을 제안 하고자 합니다 .

개발 현장의 문제점

• 첫째, 촉박한 개발일정을 꼽을 수 있다. 
• 둘째, 수직적 의사 결정 구조도 창의성을 저해하는 한 원인이다.
• 셋째, 요구사항 도출 시 원활하지 못한 협업문제를 들 수 있다.
• 넷째, 실패를 두려워하는 조직문화라 할 수 있다.
• 다섯째, 내부적으로 다양한 의사결정을 거쳐야 한다는 점을 꼽을 수 있다. 
• 여섯째, 적절한 평가와 보상이 제대로 이루어지지 않고 있다는 점이다.
• 마지막으로, 한국사회의 문화적 특징을 들 수 있다. 

창의적인 요구사항 도출을 위한 제안

• 첫째, 근무시간 중에 일정시간을 창의적인 요구사항을 도출 할 수 있도록 여유 시간을 구성원들에게 부여해야 한다. 
• 둘째, 창의적 요구사항 제안에 대한 적절한 평가와 보상제도 마련이라 할 수 있다. 
• 셋째, 창의적 요구사항 아이디어 수집과 수평적인 토론의 장으로 인트라넷을 활용함으로서 요구 사항 도출의 협업 문제를 개선한다.

고려해야 할 점

• 첫째, 기존 요구사항 관리시스템과 유기적으로 연동되게 해야 한다. 
• 둘째, 요구사항 도출 과정이 지나치게 오래 걸려서는 안 된다.
• 셋째, 소수의 결정권자의 획일적인 의사결정은 지양해야 한다.

자세히 보기 →

모바일 애플리케이션 성능향상을 위한 품질관리적용 FAQ

현재 모바일 애플리케이션 사용자들은 과거 형편없던 시절을 뒤로 하고 데스크톱 애플리케이션에 준하는 성능을 기대하고 있습니다 . 모바일 애플리케이션 성능 보장을 위해서는 기능 (functionality), 성능 (performance), 사용성 (usability) 테스트 등의 전통적인 품질관리 프로세스를 적용해야하며 , 이의 적용을 위한 핵심이슈에 대한 질문과 답변을 FAQ 형태로 제공합니다 .

본 원고에서는 FAQ형식을 통해 기업 모바일 개발 프로젝트에 테스트 프로세스를 적용하고, 모바일 애플리케이션 개발에 있어서 흔히 저지를 수 있는 실수를 피하며, 모바일 전략을 세우는 것에 대해 조언합니다.

[품질관리적용 FAQ]

1. 모바일 애플리케이션 개발 전략을 실행에서 기업들이 직면하게 되는 문제들은 무엇인가 ?
2. 품질보증 설정측면에서 모바일의 상기 이슈를 해결할 수 있는 방법은 무엇인가 ?
3. 모바일 애플리케이션 개발 과정에서 모바일 테스팅이 중요한 이유는 무엇인가 ?
4. 모바일 전략을 개발하고 수립하는 핵심적인 단계들은 무엇인가 ?
5. 기업 모바일 애플리케이션을 위한 최고의 ROI( 투자대비효과 ) 보장 방법은 무엇인가 ?
6. 기업 모바일 애플리케이션을 위한 개발 프로젝트에서 발생되는 일반적인 실수들은 무엇인가 ?

자세히 보기 →

디자인 패턴 자동화 Part 2

디자인패턴 자동화 프레임 워크

Ⅰ . 디자인 패턴을 자동화하고 강화하기 위한 포괄적 프레임워크

솔루션으로써 동적 언어 , 오픈 컴파일러 (Roslyn 와 같은 ), 혹은 재컴파일러 (Cecil 과 같은 ) 것들은 매우 상세한 구문 트리 (syntex tree) 를 노출하기 때문에 이들을 알기 위해 유혹을 받을 수 있습니다 .

그러나 이러한 기술들은 모든 변형을 이행하는 것을 매우 복잡하게 만들면서 과도한 추상화 수준으로 운영됩니다 .

우리가 필요로 하는 것은 다음과 같은 원칙에 기반을 둔 컴파일러 확장을 위한 상위 수준의 프레임워크입니다 .

1. 일련의 변형 기본 요소의 제공 , 예를 들면

• 메소드 호출을 차단
• 메소드 실행 이전 이후 실행 코드
• 필드 , 속성 , 이벤트로의 접근 차단
• 기존 클래스에 대한 인터페이스 , 속성 이벤트들의 소개

Ⅱ . 영역지향 프로그래밍
Ⅲ . AOP 의 불리한 면
Ⅳ . PostSharp 라이브러리로 기성품인 디자인 패턴 이행
Ⅴ . 요약

자세히 보기 →

품질관리 및 개발자를 위한 오픈소스 버그추적시스템 10선

버그추적시스템은 개발 중 발생하는 SW 오류 ( 버그 ) 를 추적 / 관리하는 품질관리 지원 시스템의 일종으로 버그추적시스템의 활용은 SW 개발시 매우 유용하며 , 오류와 이슈추적 시스템의 지속적 관리는 역량 있는 SW 개발팀이라는 증거가 될 수 있습니다 . 여기서 소개되는 열 가지 버그추적시스템은 PC 및 웹기반으로 활용될 수 있으며 오픈소스로 개발되어 접근성이 높습니다 .

1. 버그질라 (Bugzilla)
2. 맨티스 비티 (Mantis BT)
3. 트랙 (Trac)
4. 레드마인 (Redmine)
5. 오티알에스 (OTRS)
6. 리퀘스트 트렉커 (Request Tracker)
7. 이븐툼 (Eventum)
8. 버그지니 (BugGenie)
9. 웹이슈스 (WebIssues)
10. 파슬 (Fossil)

자세히 보기 →

컨테이너 기술에 대한 이해

이제 세상에 나온 지 채 3년이 안 된 ‘컨테이너 기술’에 전세계 개발자들의 이목이 집중되고 있다.  구글을 비롯한 아마존 등의 클라우드 컴퓨팅 기업들이 컨테이너 서비스를 한다고 이미 소리 높여 외치고 있을 정도이다. 뿐만 아니라, 클라우드 운영플랫폼의 표준으로 자리 잡아 가고 있는 오픈소스 클라우드 프로젝트 ‘오픈스택’에서도 차세대 트렌드는 ‘컨테이너’임을 최근 밝힌 바 있다.  이미 알려진 대로, 컨테이너 기술은 소프트웨어 정의 데이터센터 구현을 위한 핵심 기술 중 하나로써 이와 관련해 다양한 기술과 솔루션이 속속 등장하고 있다.

이러한 컨테이너 기술의 개념과 컨테이너 기술을 리드하고 있는 Docker, 다양한 에코시스템들, 그리고 클라우드 서비스 환경에서의 적용 사례들에 대해 한국 레드햇의 김호중 부장으로부터 자세한 설명을 들을 수 있었다.

1. 컨테이너 주요기술 설명 2. Docker, 에코시스템 3. 적용 사례 및 방안

도커  아키텍처

자세히 보기 →

소프트웨어 생산성 향상 - 원격개발센터 편

SW개발에서 많은 비용과 노력이 필요함에도 '소프트웨어 개발 프로세스'를 적용하는 이유 중에는 산출물과 코드의 재활용, 품질관리를 통한 개발 생산성 향상이라는 점이 있기 때문이다. 개발 생산성은 다양한 형태로 해석할 수 있는데 인건비 대비 개발 결과물의 규모를 나타내는 것이 일반적이다. 우리나라 소프트웨어 개발자의 인건비가 상승하는 추세이고 개발 기간이 짧아지면서 생산성을 고민하지 않을 수 없다.  

생산성 향상과 관련하여 우선 원격개발센터에 대해 살펴보자. 최근 들어, 많은 기업에서 도입하고 있는 원격개발센터는 단순 개발 부분에 대해 인건비가 낮은 해외 거주 개발자에게 위탁함으로써 비용 절감과 함께 야간(새벽) 지원도 가능하게 한다. 또한, 핵심 개발자들을 한 곳에 모아 다양한 개발 사이트를 지원하는 것도 원격개발센터의 목적으로 볼 수 있다. 초기에는 일부 대기업에서만 운영되었으나 최근에는 중견 기업에도 확대되는 추세다.

• 원격개발센터의 배경과 목적
• 원격개발센터의 구성
• 원격개발센터에서 필요한 소프트웨어공학적 요소
• 원격개발센터 사례

Eyefax에서 제시하는 원격개발센터의 장단점

구분	내용
장점	- 기존 개발에 비해 40~60%의 비용 절감 효과를 제공 - 다른 프로젝트 수행 모델에 비해 30%의 비용 절감 - 매월 고정 비용 지출 - 지적 재산권 보호 - 개발 과정을 통합 관리 - 저 위험, 고수익 - 일관된 절차에 따라 개발팀을 관리
단점	- 1년 365일 지속적인 운영 - 최소 2명 이상의 팀 멤버 필요

자세히 보기 →

원포인트 클리닉 Round Table 안내(12/3(목)~4(금)

중소기업의 SW개발 생산성, 품질향상을 위한 SW공학센터의 원포인트 클리닉 Round Table행사와 다양한 오퍼링 서비스에 여러분을 모십니다.

본 행사는 국내외 SW전문가를 초빙하여 SW개발 관련 최신 기술 동향을 파악하고, 기업이 직면한 SW품질개선, 생산성제고를 위한 이슈에 대하여, 함께 토의하고, SW공학적용의 해결 방향을 제시하는 국내 최초의 SW공학 전문 Counseling 무료 행사입니다.

• 일정: 2015.12.03(목)~12.04(금)/2일간
• 시간: 09:30~17:00(세션별 1시간 30분 이내 진행)
• 장소: 베스트웨스턴 프리미어 구로호텔 지하 1층 로즈홀
• 신청: 국내기업(신청방법: 접수처를 통한 일정협의 및 신청서 접수/선착순)

참가 신청서 다운받기 →

SDN 분야 소프트웨어 개발 동향

‘소프트웨어 정의 네트워크’로 알려진 SDN(Software Defined Networking)이 등장한 지 10년 정도 된다. SDN은 기존 네트워크 장비에서 하드웨어 기능과 소프트웨어 기능을 분리하여 직접 프로그래밍을 지원하는 새로운 네트워크 아키텍처 개념이다. 

데스크탑과 같은 컴퓨터는 칩이나 운영체제가 바뀌어도 다른 부품을 사용할 수 있지만, 네트워크 장비는 프로토콜이 바뀌면 해당 장비를 모두 바꿔야 한다. 하지만, SDN을  통해 이제 기업은 자신들의 구미에 맞는 네트워크 인프라를 구성할 수 있게 되었다. 

SDN and the Future of Service Provider Networks,

Fujitsu network communications Inc., 2013

SDN 적용시 비용절감과 관리의 편리, 그리고 확장성 등 기존 네트워크 구조에서는 누릴 수 없는 다양한 혜택을 기대할 수 있다.

• 애플리케이션과 네트워크 인프라 사이의 성능을 높이는 제어 가능
• 좀 더 신속한 프로비져닝과 정책 기반의 중앙화 
• 프로그램이 가능한 네트워크 구조 변경과 관리
• 다른 데이터센터 인프라를 관리하는 오케스트레이션 시스템과 호환
• 네트워크 운영유지보수 비용과 설비투자비용 절감

자세히 보기 →

지속적 통합을 손쉽게 적용하는 다섯 가지 방안

지속적 통합은 SW 통합에서 발생할 수 있는 중요한 문제들을 줄여주고 보다 빠르게 응집력 높은 소프트웨어를 개발할 수 있다는 점에서 널리 쓰이고 있습니다 . 본 원고에서는 지속적 통합 시 오류 발생을 억제하고 피할 수 있는 효과적인 방안 ( 빌드 관리 전략 수립 , 빌드 / 배포시기 관리 , 인수테스트 통과 후 탐색테스트 수행 등 ) 을 제공합니다. 

소프트웨어 공학에서 , 지속적인 통합 (continuous integration, CI) 은 지속적으로 품질관리를 적용하는 프로세스를 실행하는 것을 의미하며, 작은 단위의 작업 , 빈번한 적용 , 지속적인 통합은 모든 개발을 완료한 뒤에 품질관리를 적용하는 고전적인 방법을 대체하는 방법으로서 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는데 초점이 맞추어져 있습니다.

지속적 통합 시 발생하는 문제점 확인 및 보완 할 수 있는 방안

1. 빌드 관리 전략 수립
2. 잘못된 오류에 대한 근절
3. 빌드 / 배포 시기 관리
4. 인수테스트 통과 후 탐색테스트 수행
5. 분산된 팀을 위한 명확한 기대 설정

자세히 보기 →

디자인 패턴 자동화 Part 1

디자인패턴 자동화 개념 및 디자인 패턴 적용

소프트웨어 개발 프로젝트의 규모는 점점 커지며 복잡해지고 있다 . 전문가들은 프로젝트가 복잡해질수록 소프트웨어 개발 비용과 유지보수 비용은 더욱 증가하며 , 하드웨어 비용을 초과하게 될 것으로 예상하고 있다.

소프트웨어 규모와 개발 및 유지보수 비용간의 관계는 초선형 (Super-liner) 관계에 있다 . 결국 소프트웨어 규모가 크고 복잡할수록 개발과 유지보수를 위한 우수한 엔지니어를 필요한 반면 우수한 엔지니어를 고용하고 지속적으로 보유하는 것은 어렵게 된다 .

디자인 패턴은 이러한 문제점을 해결할 수 있는 SW 공학을 위한 강력한 도구의 일종으로 , SW 설계에서 자주 나타나는 문제를 위해 이미 개발되어 있는 해결 방법이며 , 많은 디자인 패턴들이 축적되면서 그 효용성이 증대되고 있다 .

• 보일러판 코드의 문제점
• 디자인 패턴 자동화 및 컴파일러 확장

자세히 보기 →

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

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

- SW 자동화 테스팅 수행을 위한 FAQ - 

1. SW 자동화 테스팅이란 ?

2. 자동화 테스트를 수행해야 하는 경우는 무엇인가 ?

3. 테스트 자동화의 우선순위는 무엇인가 ?

4. 수동 테스트에 적합한 테스트의 종류는 무엇인가 ?

5. 자동화 테스트 선택 시 주의해야할 사항은 무엇인가 ?

6. 팀의 지속적인 테스트 자동화 성공 방법은 무엇인가 ?

마이크 콘의 테스트 자동화 피라미드

자세히 보기 →

프로그래머 행위 메트릭스(Programmer Behavior Metrics, PBM)

프로그래머의 코딩 역량은 소스코드의 품질에 직접적인 영향을 미치며 , 결과적으로 프로젝트의 성공에 영향을 끼치게 된다 . 따라서 코딩 역량이 뛰어난 프로그래머 ( 고급 ) 의 행위를 분석하거나 다른 프로그래머와 비교하여 강 / 약점을 파악할 수 있다면 , 코딩 역량 제고의 시작점이 되며 궁극적으로 프로젝트의 성공 가능성을 높이는 방법이 될 것이다 .

일반적으로 고급 프로그래머들은 단위 시간에 더 많은 코드를 작성하고 더 적은 양의 결함을 발생시킬 것이라 기대된다 . LOC(Line of Code) 나 결함은 소프트웨어 메트릭스 [1] 를 통해 측정이 가능하며 이것들을 프로그래머의 명시적 행위 (Programmer Explicit Behaviors) 라고 규정하겠다 . 또한 고급 프로그래머들은 더 많은 시간을 디버깅하며 , 개발 도구를 더 효율적으로 사용하고 , 더 몰입 (flow)[2] 하여 코딩을 할지도 모른다 . 아직 측정하는 방법이 명확히 제시되지 않은 이러한 것들을 프로그래머의 암묵적 행위 (Programmer Implicit Behaviors) 라고 하겠다 .

본 원고에서는 프로그래머의 암묵적 행위 측정 방법에 대해 중점을 두고 있다 . 프로그래머의 행위와 측정 방법을 정의하고 , 구현된 측정 시스템 (PBMS) 의 주요 아키텍처에 대해 논의하며 , 약 1 개 월 간의 시범 적용 사례를 소개하겠다 .

1. 프로그래머 행위
2. PBMS 구축
3. 시범 적용 사례
4. 결론

자세히 보기 →

사용자 경험 설계 프로세스의 핵심이 되는 UEM(사용자 경험 관리)

최근 SW 개발자 및 품질관리 전문가들은 기존의 UX( 사용자 경험 ) 설계에서 초점을 두고 있는 애플리케이션의 외양 디자인 , 손쉬운 활용을 위한 기능 배치 등에서 벗어나 실제 UX 등에 초점을 두고 있는 UEM( 사용자 경험 관리 ) 에 관심을 두고 있습니다 . 사용자 경험은 애플리케이션 성능과 매우 깊은 관련이 있으며 , UEM 을 통해 사용자 경험 설계 프로세스 개선을 추구할 수 있습니다.

소프트웨어 품질 전문가들은 ‘UX(user experience, 사용자 경험 )’ 란 용어를 애플리케이션 성능보다 설계와 연관을 맺는 경향이 있습니다. 이러한 기존의 UX 가 개발자와 품질관리 ( 테스터를 포함한 ) 전문가들 사이에서 UEM(user experience management, 사용자 경험 관리 ) 이라는 개념을 도입하게 된다면 기존 UX 의 설계중심 측면은 변화할 것입니다.

현행 사용자 경험 설계 프로세스에 있어 한계에 직면한 조직들은 UEM 개념을 추가함으로써 성능적 측면까지 향상될 수 있을 것으로 기대합니다.

▶ UEM 이란 무엇인가

▶ 사용자 경험 설계에서 UEM 의 중요성

▶ UX 설계 프로세스를 어떻게 개선하는가 

자세히 보기 →

최소한의 시간, 비용, 인력으로 SW품질테스트를 수행하는 4가지 Tip

소프트웨어 품질테스트는 최소한의 시간 , 비용 , 인력을 투입하여 시작하였다가 비즈니스에 가치를 증명하면서 자원 투입을 늘리는 것이 통상적인 방법입니다 . 따라서 본 원고에서는 자원이 한정되어 있는 조직에서 테스트를 효과적으로 수행함으로써 품질을 달성하기 위한 네 가지 방안을 제시하고 있습니다.

소프트웨어 품질 테스트 방안

1. 시간이 없다면 , 휴리스틱 활용을 통해 소프트웨어 품질 테스트 수행할 것
2. 자금이 없다면 , 모바일 테스팅을 위한 BYOD 파티를 개회하라
3. 테스트 수행자가 없다면 , 적절한 특성을 지닌 사람들을 모집하라
4. 위험기반 및 역량 기반 자원조달 방법을 사용하라

자세히 보기 →

파라미터를 고려한 컴포넌트 인터페이스의 최적 테스트 시퀀스 생성 기법

컴포넌트의 외부 행위는 파라미터를 가진 인터페이스로 정의됩니다 . 소프트웨어 개발자는 컴포넌트를 테스트하기 위해 인터페이스를 통해 각기 다른 파라미터의 값을 반복적으로 입력하고 , 입력 값에 따른 출력 값을 관찰합니다 . 테스팅에 소요되는 시간을 줄이기 위해 테스트 케이스를 자동으로 실행하는 테스팅 자동화 도구가 효율적이지 않은 테스트 시퀀스를 수행한다면 테스팅 자동화의 효과는 줄어듭니다 . 유한 상태 머신을 기반으로 하는 기존의 테스트 시퀀스 생성 기법들은 파라미터를 가진 인터페이스 테스팅에 최적화된 테스트 시퀀스를 제공하지 않습니다 . 본 원고에서는 컴포넌트 인터페이스를 파라미터를 고려한 상태 모델로 표현하고 최적의 시퀀스 생성 기법을 제안합니다 . 최적의 시퀀스 생성 기법은 파라미터를 가진 상태 기반의 행위 모델에서 특정 간선을 원하는 회수만큼 수행을 보장하는 시퀀스를 생성하며 , 생성된 시퀀스는 최적의 테스트 수행 시간을 갖습니다 .

최적 테스트 시퀀스 생성 기법

1. 테스트 시퀀스 생성 프로세스와 모델
2. 테스트 케이스 맵핑
3. 최적 테스트 시퀀스 생성
4. 최적 테스트 시퀀스 생성 알고리즘 평가

자세히 보기 →

스크럼 프로젝트 관리: 스토리 포인트로 추정하기

애자일 철학을 실천하기 위한 구체적 방법론이자 애자일 프로세스 중 가장 널리 사용되고 있는 스크럼 프로젝트 관리에서 사용되는 스토리 포인트에 대해 프로젝트 관리자가 적절하게 사용해야 할 필요성이 증가하고 있습니다 .  프로젝트 관리자가 알아야 할 스토리 포인트에 대한 개념 및 장단점 등을 소개합니다.

1. 스토리 포인트란 무엇인가 ?
2. 속도란 무엇인가 ?
3. 스토리 포인트 사용의 단점
4. 스토리 포인트 사용의 장점
5. 스토리 포인트의 사용 시기

스크럼 용어정리

자세히 보기 →

[SW공학 동영상 9화] Patterns Distilled

pattern이란?

• 소프트웨어 아키텍처, 분석, 설계나 코딩 측면에서 반복되는 문제점에 대한 해결방안
• 건축에서 시작해서 S/W공학으로 확대
• S/W 생산성을 제고하기 위한 방안 중 하나로 등장

Pattern 가치
Pattern 분류
Pattern Language
Pattern Catalog
Framework 소개

SI와 솔루션 개발의 차이 - 프로세스 편

SI와 솔루션 개발의 차이 중에서 가장 큰 부분은 프로세스입니다. SI는 요구사항을 중심으로 개발하고 솔루션은 기획을 중심으로 개발합니다. 따라서 SI는 요구사항을 어떻게 시스템으로 만드는지에 초점이 맞춰집니다. 전통적인 소프트웨어 개발 프로세스, 개발방법론, 툴 등은 요구사항을 분석하고 기술적인 설계를 한 후 코딩 하기 때문에 SI에 잘 맞춰졌다고 볼 수 있습니다. 하지만 솔루션의 경우, 불특정 사용자를 대상으로 하기 때문에 사용자 분석에 많은 시간을 할애합니다. 사용자 분석에 따라 솔루션 개발의 성패가 좌우되는 것이 일반적입니다. 

SI와 솔루션 개발의 차이, 마지막 시간으로 프로세스의 차이를 살펴봅니다. 먼저, SI와 솔루션 개발 프로세스의 목적이 무엇인지 알아보고, SI와 솔루션 개발 프로세스를 비교해보면서 차이점을 살펴봅니다. 마지막으로, SI와 솔루션 개발이 끝난 후 유지보수 프로세스는 어떻게 되는지 알아봅니다.

• SI와 솔루션 개발 프로세스의 목적
• SI와 솔루션 개발 프로세스의 비교
• SI와 솔루션 개발의 유지보수 프로세스

SI 프로젝트 프로세스

솔루션 개발 프로세스

자세히 보기 →

스타트업의 소프트웨어 품질 향상을 위한 소프트웨어 개발 프로세스

흔히 생각하기에, 스타트업은 중소 중견/대기업에 비해 규모가 작고 민첩하여 새로운 아이디어를 비교적 쉽고 빠르게 구현할 수 있을 것이라 기대한다. 하지만 현실적으로는 되려 어려움에 직면하기 쉬울 수 있다. 그 이유는 스타트업이 이미 성숙한 회사들에 비해 자금, 인력, 시간이 부족한 데다가 개발 프로세스가 잘 정립되어있지 않을 확률이 높기 때문이다. 더불어 개발하는 SW의 규모가 더 작다고 해서 필수적인 과정이 줄어드는 것은 아니라는 것도 한 몫 한다.

이러한 문제를 해결하기 위해 나름의  프로세스를 구축하고, 이를 활용해 매일 업무를 진행하고 있는 P-ful Inc.의 주대연 대표로부터 현재 운영하고 있는 스타트업에서 직접 구축한 프로세스 소개와 앞으로의 개선 방향에 대해 조언을 얻었다.

1. 스타트업에 있어 SW개발 프로세스 구축의 필요성 2. 적용 방안 3. 기대효과 4. 개선 방향

소프트웨어의 개발 주기

자세히 보기 →

제22차 SP인증을 중심으로 한 SW프로세스 교육안내(11/19(목)~11/20(금) 창원)

지역 SW기업 및 방산SW기업의 SW개발품질관리 선진화 및 역량강화 일환으로, 마련된 [제22차 SP인증을 중심으로 한 SW프로세스 교육 및 공개 SW적용 세미나]에 여러분을 모십니다.

• SP를 중심으로 한 SW프로세스 교육
• 공개 SW를 활용한 SW개발품질관리체계 구축적용사례 세미나

신청기한: 2015.11.16(월)18:00

교육비용: 무료(다과 및 중식, 교재/가이드 제공)

신청하러 가기 →

Devops의 이해와 구현 Part 2

Devops 구현하기 ( 품질 , 프로세스 , 도구 관점에서 )

전통적인 폭포수 개발 모델에서는 코드가 개발이 완료되어야 빌드와 테스트가 이루어질 수 있다 . 코드가 최종 단계에 이르러야 테스트가 수행되므로 테스트 결과는 프로젝트 후반에서 파악할 수 있다 . 테스트를 통과하지 못할 경우 , 변경된 사항과 해결할 문제 사이에 상관관계를 파악하기 어려워 문제 해결에 많은 시간을 낭비하게 된다 . 그나마도 프로젝트 일정과 비용 등의 제약으로 아직 해결하지 못한 문제가 남아 있지만 운영 단계로 넘어가야 하는 경우 품질에 상당한 악영향을 미칠 수밖에 없다 .

저명한 컴퓨터 과학자인 Gerald M. Weinberg 는 품질은 사용자의 요구사항에 부합하는 것이라고 정의하였다 . 즉 , 품질이라는 것은 정도가 있는 것으로 ‘ 얼마나 잘 ’ 이라는 것이 사용자에 따라 달라질 수 있다 . 가령 , 시스템 성능은 얼마나 많은 사용자가 동시에 사용하는지 , 어떤 기능을 주로 사용하는지에 따라 그 기준이 달라진다 . 이는 품질이 절대적인 기준 값이 있는 것이 아니라 전체적 맥락 (context) 하에서 정의되고 주요 품질 속성과 아닌 것을 구분하는 것이 필요하다는 것을 말해준다 .

품질속성 시나리오

자세히 보기 →

SW개발주기상에서 Just-in-time 요구사항 정의

요구관리는 SW 개발주기에서 가장 중요한 첫 번째 단계임이 분명하나 , 문서화된 요구사항은 자주 변경되며 시간낭비에 불과할 때가 많습니다 . 제조업에 적용되는 just-in-time 컨셉은 SW 개발에도 매우 유효함에 따라 , 요구관리가 SW 개발에 있어 시기적절한 역할을 하기 위한 just-in-time 요구관리에 대한 정의와 역할을 제시합니다.

• 요구사항 정의는 소프트웨어 개발 주기 상 최초단계로서 아주 중요한 의미를 가지나 , 변경되거나 버려질 요구사항을 기록하는 것인 시간을 낭비하는 것에 불과함
• 제조분야에서 시간낭비를 피하는 기본적 기술은 “just-in-time” 으로 알려져 있는데 이 Just-in-time 개념이 소프트웨어 요구관리에 적용될 수 있음
• 본 보고서에서는 just in time 요구사항 관리가 제공하는 합리적이고 시간낭비를 없애는 방법을 설명하고자 함

▶ 소프트웨어 개발 주기 : Just-in-time 요구사항

▶ Just-in-time 요구사항은 무엇과 비슷한가 ?

▶ Three Amigos

▶ 예측의 필요성

▶ 조정

▶ 함께 모여 작업

자세히 보기 →

애플리케이션 보안테스팅 전략 수립을 위한 10단계 절차

대부분의 SW 개발 및 테스팅 전문가들은 보안 테스트를 SW 개발주기 상 마지막 단계로 생각하고 있는 경향이 있습니다 . 그러나 SW 보안성 테스트는 제품의 수명과 기업의 비즈니스 전략에 영향을 미치는 중요한 단계임에 따라 품질보증 팀과 함께 개발의 전주기에 걸쳐 전략을 수립하고 이의 실효성 있는 적용이 요구됩니다 .

보안테스팅 전략수립을 위한 10 단계

1. 애플리케이션 개발 프로젝트 초기에 위협 모델링을 수행
2. 보안 관리의 기본적 요구사항을 정의
3. 악용사례를 찾아냄
4. 입력 확인을 위한 규칙을 정의
5. 소스코드 분석기를 이용
6. 소스코드를 기록하기 위해 개발자들을 가이드
7. QA 주기 동안 공격을 자극하기 위한 동적 스캐너를 사용
8. 배포환경에 대비하여 애플리케이션을 테스트
9. 일반적 리질리언시 (resiliency: 탄성 ) 를 테스트
10. 생산과정에서 정기적으로 애플리케이션을 재 테스트

자세히 보기 →

Devops의 이해와 구현 Part 1

Devops 이해하기 ( 개발과 운영은 남이 아니다 !)

Devops 란 무엇인가 ?

매일 새로운 용어가 등장하는 IT 분야에서 요즘 Devops 란 말이 자주 등장하고 있다 . IT 관리자 및 전문가에게 널리 알려진 CIO 전문지에서 “ 놓치지 말아야 할 필수 IT 프로젝트 ” 경력중 하나로 Devops 를 꼽기도 하였다 . Devops 란 무엇인지 살펴보기 위해 위키피디아 (wikipedia) 에서 정의한 내용을 먼저 살펴보자 .

DevOps 란 ?

DevOps(Devops = Development + Operations) 라는 합성어는 소프트웨어 개발자들과 IT 종사자들 사이의 의사소통 , 협업 , 융합을 강조한 소프트웨어 개발 방법론이며 , 소프트웨어 개발과 IT 운영간의 상호 의존관계에 대한 산물이다 . DevOps 는 조직에서 소프트웨어 상품과 서비스를 신속히 생산하는 것에 도움이 되는 것을 목적으로 한다 .

Devops 가 아닌것은 ?

Devops는 새로운 부서가 아니다

새로운 개발문화로써의 Devops

Devops는 개발과 운영을 자동화해주는 도구를 설치한다고 해서 만들어지지 않는다. Devops를 새로운 개발 문화로써 인정하고 이를 조직에 정착시키는 핵심이다. 개발자와 운영자는 서로 존중하며, 신뢰를 해야 한다. 각자의 전문성과 책임을 인정해야 한다. 운영자는 새로운 기능을 배포하는데 개발자를 믿어줘야 하고, 개발자는 운영자가 제안하는 인프라를 신뢰하고 따라야 한다. 서로가 투명하게 공유하고 협력해 나가는 것이다. 개발자는 자신의 코드가 어떠한 영향을 주는지 알려야 하고, 운영자는 개발자에게 운영할 시스템에서 배포할 방법을 제공하는 것이다.

자세히 보기 →

소프트웨어 개발주기에서 위협모델링의 적용

위협모델링이란 시스템이 직면할 수 있는 보안 위협을 고려할 수 있도록 도와주는 것으로 , 즉 , 시스템의 잠재적인 취약점 제거 전략을 수립할 수 있도록 하며 , 제한된 리소스에 초점을 맞추고 주의를 기울이게 합니다 . 이에 개발중인 애플리케이션에 대해서 위협 모델링 개발의 기본 요소를 제시합니다 .

• 소프트웨어 개발 주기상 , 초기에 누가 어플리케이션을 공격할지 어떠한 방법으로 공격하는지를 고려하는 것은 중요함
• 이러한 프로세스는 위협모델링 (threat modeling) 으로 알려져 있으며 , 대부분의 개발팀들에게 이 개념이 익숙하지만 위협 모델링의 많은 기초적인 사항들에 대하여는 전문가들의 비밀 작업장처럼 숨겨져 있음
• 위협모델링은 복잡하거나 굳이 공식적일 필요는 없는데 , 본 원고에서는 위협 모델링이 무엇이고 어떻게 수행하는지를 다룰 것임

▶ 개요

▶ 위협 모델링 프로세스

▶ STRIDE 에 대한 이해

▶ 결론

자세히 보기 →

요약기반 대규모 소스 코드 유사성 평가

소프트웨어의 개발이 활발해짐에 따라 소스코드 복제 , 도용이 증가하고 있으며 , 이로 인한 분쟁도 증가하고 있습니다 . 따라서 소스코드 복제에 대한 유사도 검사 또한 매우 중요시되고 있습니다 . 개발 시간 단축 , 성능 향상을 위해 소스코드 복제가 일어나고 다른 기업 , 개인 간의 분쟁을 유도하게 됩니다 . 분쟁을 결정짓거나 사전에 방지하기 위해 소프트웨어 유사도 검사가 필요합니다 .

유사성을 측정하는 기존의 도구는 대부분 텍스트 / 토큰 비교 [1, 2, 3, 4] 방법을 사용한다 . 텍스트 / 토큰 비교는 소스코드의 텍스트나 토큰을 나열하여 비교하는 방법으로 다른 비교 방법에 비해 수행속도가 빠르다는 장점이 있습니다 . 하지만 기존의 툴들은 불필요한 소스 코드에 대해서 잘못된 유사성을 감정하는 한계가 있습니다 . 예를 들어 프로그램 개발 툴에 의해 자동으로 삽입된 소스코드 , 주석 , 변수 선언문의 위치 등은 유사도 측정에 있어 방해요소가 될 수 있습니다 . 대규모 소프트웨어의 소스코드를 그대로 비교하면 수행시간의 증가로 인해 기존 툴에 직접 사용하기에는 어려움이 있습니다 . 또한 소스코드를 도용 시 소스코드를 의도적으로 변형을 하게 되면 복제한 소스코드이지만 검출도구에서는 유사하지 않다고 판단 할 수 있습니다 .

• 대규모 소프트웨어의 유사도 검사 방법
• 소스코드 요약 기법과 유사도 비교 방법
• 대규모 소프트웨어의 유사성 비교

요약기반 유사성 평가 절차

자세히 보기 →

제21차 SP인증을 중심으로 한 SW프로세스 교육안내 (11/12(목)~13(금), 경북 포항)

지역SW기업의 SW개발품질관리 선진화 및 역량강화 일환으로 마련된 [제21차 SP인증을 중심으로 한 SW 프로세스 교육]에 여러분을 모십니다.

본 교육은 국내 중소SW기업과 개발 조직의 SW프로세스 품질 향상과 신뢰성 확보에 목적이 있습니다. SW개발자, 품질 담당자, 테스트 담당자 등을 대상으로 SW프로세스 개념과 SP인증 기준 이해를 바탕으로 실제 업무에 필요한 SW프로세스 교육을 진행합니다.

신청하러 가기 →

사용자 경험(UX)과 품질 관리(QA)에 따른 사용성 확보

SW 사용성 (usability) 은 SW 사용자 입장에서 원하는 기능과 서비스를 손쉽게 찾아서 활용할 수 있도록 기능을 제공하는지를 의미합니다 . 최근 들어 SW 사용성은 SW 가치의 중심축 역할을 함에 따라 애자일 개발에서는 전체 개발팀이 제품의 사용성을 함께 고려하는 것이 중요합니다 . 따라서 여기서는 사용자 경험 (UX) 와 품질 관리 (QA) 측면에서 사용성 확보를 위한 기획 - 개발 - 테스팅 - 배포 등의 단계별 고려사항을 제시합니다 .

사용성의 원칙은 망치와 같은 물리적 품목들에서 소프트웨어 애플리케이션에 이르기까지 모든 유형에 적용되는데 , 소프트웨어의 사용성은 SW 가치의 중심 역할을 합니다.

애자일 소프트웨어 개발측면에서 제품의 사용성은 팀 전체의 공유되는 관심사이자만 , 본 보고서에서는 기획 , 개발 , 테스트 및 배포라는 애자일 개발의 네 가지 단계를 통해 품질 관리와 사용자 경험 사용자경험이 사용성을 확보하는 방법에 초점을 맞추고자 합니다.

애자일 개발의 네 가지 단계별 고려사항

1. 기획 (Research)
2. 개발 (Development)
3. 테스팅 (Testing)
4. 배포 (Release)

자세히 보기 →

최적의 클라우드 테스팅 툴을 찾아내는 4가지 Tip

최근 SW 개발에 있어 클라우드 기반의 테스팅 툴은 이동성 , 확장성 , 유연한 가격정책에 의해 점차 부각되고 있습니다 . 이에 따라 클라우드 테스팅 툴에 대한 투자 이전에 고려해야 할 네 가지 팁을 제공하여 , 각 프로젝트 환경에 적합한 최적의 테스팅 툴을 확보할 수 있도록 도움을 주고자 합니다 .

클라우드 기반의 테스팅 툴은 이동성 , 확장성 , 유연한 가격 모델과 같은 이점을 제공하면서 소프트웨어 개발 산업을 이끌어 옴.

테스트 전문조직들 또한 이러한 흐름에 편승하고 있으나 , 클라우드 테스팅 툴에 투자하기 전에 고려해야 할 네 가지 팁을 살펴보는 것이 유익함.

테스팅 툴을 확보하는 4 가지 Tip

1. 위험요소와 문제점 인식하기
2. 최적의 서비스 선택하기
3. 퍼블릭 클라우드 또는 프라이빗 클라우드 서비스 선택하기
4. SLA 이해하기

 클라우드 테스팅 툴 7 선

자세히 보기 →

제20차 SP인증을 중심으로 한 SW프로세스 교육안내 (11/5(목)~6(금), 전남 광양)

지역SW기업의 SW개발품질관리 선진화 및 역량강하 일환으로 마련된 [제20차 SP인증을 중심으로 한 SW 프로세스 교육]에 여러분을 모십니다.

본 교육은 국내 중소SW기업과 개발 조직의 SW 프로세스 품질 향상과 신뢰성 확보에 목적이 있습니다. SW개발자, 품질 담당자, 테스트 담당자 등을 대상으로 SW프로세스 개념과 SP인증 기준 이해를 바탕으로 실제 업무에 필요한 SW프로세스 교육을 진행합니다.

신청하러 가기 →

빅데이터와 데이터사이언스

정보통신기술의 빠른 발전과 소셜미디어 활성화는 그간 상상하지 못한 거대한 데이터를 만들어내고 있다. 어느새 Petabyte를 넘어서는  데이터는 이제 단순히 저장과 조회의 대상이 아니다. 다양한 채널을 통해 수집하고 분석하며 가치를 창출하는 그야말로 소중한 자산이고 기업의 흥망을 좌지우지하는 위상에 올라서 있다.

데이터사이언스 구성요소

• 산업과 일상에 위력을 발휘하고 있는 데이터사이언스
• 데이터과학자(Data Scientist)가 되려면?
• 데이터사이언스와 데이터과학자의 미래

자세히 보기 →

정형기법의 실제 적용 절차

‘정형기법’의 역사는 1970년대 영국의 Oxford 대학과 Edinburough대학의 수학명제를 자동 증명할 수 있는 증명 개발로부터 시작한다. 특히 소프트웨어 공학에서의 정형 기법(formal methods)은 소프트웨어와 하드웨어 시스템의 명세, 개발, 형식 검증을 위한 특정한 종류의 수학적 기반 기술이다. 그만큼 새로운 기법은 아니라는 뜻도 된다. 하지만 최근 들어 각종 기능안전성(Functional Safety) 관련 국제표준의 권고에 따라 정형기법을 적용해야 하는 소프트웨어가 급격히 증가함에 따라, 효과적인 적용 방법에 대한 관심이 증가되고 있는 상황이다. 그럼에도 불구하고 정형기법(정형명세+정형검증)은 안전최우선(Safety-Critical) 시스템/소프트웨어의 검증(V&V : Verification & Validation) 기법으로서, 적용 대상이 한정되고 비용이 많이 소요되는 특징으로 인해, 그 구체적인 적용 방법과 사례가 널리 알려져 있지 않다. 때문에 여러 다양한 개발 현장에서 정형기법을 실제로 적용할 때 어려운 점이 많아, 건국대학교 유준범 교수로 부터 일반적으로 널리 사용되는 정형기법의 방법/절차에 대한 조언을 구했다.

1. 정형기법의 적용범위 2. 정형기법의 이상적인 적용방법 3. 정형명세 및 정형검증 4. 실제 적용사례

캡션 추가이상적인 정형기법 적용 방법

자세히 보기 →

SI와 솔루션 개발의 차이 - 개발 편

SI와 솔루션의 개발 방향

SI는 고객의 요구사항을 분석하여 아키텍처로 나타낸다. 아키텍처는 소프트웨어를 구성하는 소프트웨어 아키텍처, 시스템을 구성하는 인프라 아키텍처, 그리고 데이터를 구성하는 소프트웨어 아키텍처, 시스템을 구성하는 인프라 아키텍처, 그리고 데이터를 구성하는 데이터 아키텍처를 포함한다. 이 밖에 애플리케이션 아키텍처 등과 같은 다양한 아키텍처들이 더 존재 할 수 있다. 여기서 중요한 포인트는 고객의 요구사항을 아키텍처로 정의한다는 것이다. 고객은 자신이 만들고자 하는 시스템이나 소프트웨어가 어떤 모습인지 대부분 알지 못한다. 따라서 고객이 원하는 모습을 미리 보여줄 필요가 있으며, 이러한 모습을 기준으로 개발을 진행한다. SI 프로젝트에서 가장 중요한 역할은 아키텍처라고 말하는 이유가 바로 여기에 있다.

아키텍처를 크게 고민하지 않던 초기 SI에서는 프로세스, 이벤트, 데이터 모델을 만들어 내고, 이 모델을 기준으로 개발이 진행되었지만 고객이나 개발자도 이해하기 어려웠기 때문에 개발에 적극 활용되지는 못했다. 아키텍처는 고객이나 개발자가 한눈에 보기에 매우 용이했기 때문에 커뮤니케이션이나 개발에 중요한 자료로 활용되었다. <그림 1>은 SI 프로젝트의 개발 방향을 나타낸다. 요구사항을 분석한 후, 해당 내용을 아키텍처를 정의하고 점진적인 개발을 하게 된다.

 SI 프로젝트의 개발 방향

SI 개발의 또 다른 특징은 기능의 대부분이 입력, 수정, 조회, 삭제이라는 것이다. SI개발이 3D 업종이라고 얘기하는 이유가 단순 기능의 반복적인 개발이 많기 때문이다. 하지만, 이러한 것은 처음부터 필요에 의해서 시스템이나 소프트웨어를 만드는 SI에서는 어쩔 수 없이 나타나는 현상이다. 솔루션 개발은 이처럼 단순 기능 개발에서 탈피하고자 하는 소프트웨어 개발 회사를 중심으로 발전 되었다.

솔루션은요구사항이 미리 정해진 SI와는 다르게 소프트웨어를 사용하는 사람의 입장을 조사하여 소프트웨어를 정의해 나간다. 솔루션이 '고객'이라고 하지 않고, '사용자'라고 하는 이유도 여기에 있다. 사용자가 직접 요구사항을 전달하는 것이 아니라, 사용자가 무엇이 필요할지 조사하고 고민해서 명확히 정리하는 것이 솔루션의 성공 요인이다. 따라서 솔루션은 사용자 중심으로 개발 방향을 맞춰야 한다. <그림 3>은 솔루션의 사용자 중심 개발 단계를 나타내고 있다.

솔루션의 사용자 중심 개발 단계

자세히 보기 →

SW공학센터 신임 소장에 심현택 전 오픈타이드코리아 전무 선임

 심현택 신임 소프트웨어공학센터 소장

정보통신산업진흥원은 공모를 거쳐 심현택 전 오픈타이드코리아 전무를 소프트웨어공학센터 소장으로 선임했다고 26 일 밝혔다 .

□ 임기는 3 년이며 11 월 1 일부터 정식으로 업무를 수행한다 .

ㅇ NIPA 측은 “ 심현택 신임 소장은 삼성 SDS 에서 20 여년간 재직하면서 SW 를 활용한 프로세스혁신 전문가일뿐 아니라 정보전략 , 6 시그마 , 경영혁신에서 주요 보직을 맡아 기업혁신에도 풍부한 경험을 보유해 SW 산업의 발전과 SW 품질 제고를 위한 SW 공학센터 소장에 적임자 ” 라고 밝혔다 .

ㅇ 또 “ 삼성그룹 계열사에 차세대 정보화추진 계획 수립과 실행을 지원한 경험을 활용하여 SW 중심사회를 실현을 위한 SW 품질혁신은 물론 글로벌 수준의 SW 경쟁력 확보도 추진하여 SW 공학센터의 위상을 강화할 수 있을 것 ” 으로 기대했다 .

□ 심현택 소장은 “SW 기업에게 품질수준 향상을 위한 혁신활동을 지원하고 우수사례 확산 , SW 생태계 시너지 향상을 위한 다양한 SW 공학 방법론의 개발과 보급 등을 통해 세계적인 SW 공학 전문기관으로 발돋움할 수 있도록 노력할 계획 ” 이라고 말했다 .