소프트웨어공학 포털 블로그: 2월 2016

2016년 2월 26일 금요일

SW 개발 산출물 작성 가이드(SW품질확보 방안)

SW 개발 산출물 작성 가이드는 SW 개발 단계에서 나오는 산출물 중 프로젝트 계획서, 위험관리 계획서 및 위험관리 문서, 요구사항 관리문서, SW 설계문서, 테스트 계획서 및 결과서, 동료검토 계획서 및 결과서에 대해서 작성법 및 실사례를 설명합니다.

SW 개발 산출물 작성 가이드(동료검토 계획서 및 결과서)

동료검토결과보고서 가이드.pdf (202.66KB)

동료검토계획서 가이드.pdf (249.16KB)

2016년 2월 25일 목요일

SATURN 2016: Software Engineering Institute (SEI) Architecture Technology User Network Conference

<입찰공고> GCS 2차 과제에 대한 공개SW 라이선스 검증

1. 사업명 : GCS 2차 과제에 대한 공개SW 라이선스 검증 용역

2. 사업배경 및 목적

가. 추진배경

GCS 2차 과제의 SW개발 시 공개SW가 활용이 예상되고 이로 인한 제품화․상용화 과정에서의 분쟁발생을 사전 예방하기 위해 공개SW 라이선스 및 소유권에 대한 정확한 이해 및 필요한 사전 조치가 요구됨

나. 사업목적

GCS 2차 과제의 개발 SW에 대한 공개SW 사용현황을 파악하고 라이선스 규정 준수에 대한 검증 및 해결 방안을 제시함으로써 공개SW의 효과적, 합법적 사용을 통한 개발 SW에 대한 신뢰성 확보

※ (공개SW 개념) 공개SW 개발자와 이용자 간에 사용방법 및 조건의 범위를 명시한 일종의 계약으로서 GPL, LGPL, BSD 등 OSI* 인증 라이선스는 67여종에 달함

* OSI(Open Source Initiative) : 공개SW 사용을 장려하기 위해 만들어진 단체

3. 사업범위 및 사업목표

정량적 목표	정성적 목표
공개SW 라이선스 검증 계획 수립 - 전체 통합 1건	◦과제의 핵심 성공요소와 대상과제 특성을 고려하여 효율적이고 효과적인 목표 달성 기반마련
공개SW 라이선스 검증 - 7개 과제 이상	◦개발 SW에 대한 공개SW 사용현황을 파악하여 제품화․상용화 과정에서의 분쟁 발생 가능성 사전 파악 ◦자동화 방식의 공개SW라이선스 검증 도구를 활용하여 효율적이고 신뢰성 있는 검증 수행
공개SW라이선스 검증결과 분석 및 개선 가이드 - 7개 과제 이상	◦과제 참여인력들의 공개SW 라이선스 및 소유권에 대한 정확한 이해 증진 ◦공개SW 사용현황 결과와 라이선스 규정 준수에 대한 검증 및 해결방안 제시를 통해 공개SW의 효과적․합법적 사용에 기여
개선 이행점검 - 7개 과제 이상	◦효과적․합법적 공개SW사용을 유도함으로써 개발 소프트웨어에 대한 신뢰성 확보에 기여
최종 결과 보고서 - 7개 과제 이상	◦최종 개선여부를 확인하고, 향후 위반 방지를 위한 점검결과와 예방 가이드 제시

4. 사업기간 및 추진일정

가. 사업 기간 : 계약체결일 ~ 2016년 8월 16일 (약 5개월)

나. 추진 일정

ㅇ 제안설명회 : 실시하지 않음

ㅇ 제안접수마감 : 2016년 03월 08일(화) 15시

ㅇ 제안평가 : 2016년 03월 11일(금) 예정

※ 제안업체수에 따라 일정이 변동될 수 있으며, 변동 시 사업담당자가 유선공지

ㅇ 협상 및 계약체결 : 2016년 3월 중순

※ 상기 일정은 진행 상황에 따라 조정될 수 있음

※ 사업 검수 평가 시, 사업수행 능력을 평가하여 차기 용역 제안 평가시 활용할 수 있음

※ 발표평가 시에는 반드시 업무수행인력 2명 이상 참석

※ 발표자료는 평가 전일까지 파일로 제출(업체명, 대표자명 등 표기 불가)

자세히 보기

2016년 2월 24일 수요일

SW 개발 산출물 작성 가이드(테스트 계획서 및 결과서)

공통_출력물 005_테스트계획서_가이드.pdf (217.58KB)

공통_출력물 006_테스트결과서_가이드.pdf (137.95KB)

2016년 2월 23일 화요일

SW 고품질을 위한 Model 기반의 SW Visualization (하)

※ 참고: SW 고품질을 위한 Model 기반의 SW Visualization (상)

프로젝트 성공의 가장 큰 조건은 풍부한 경험을 가진 팀원이 프로젝트를 이끌어 나가는 것이지만 모든 프로젝트에 우수한 경험자를 투입하는 것은 어려운 것이 현실이다. 경험이 많은 회사에서는 다른 프로젝트에서도 공유할 수 있도록 축적한 경험을 체계적 기법으로 정리하여 전파하고 관리한다. 기법의 종류와 깊이가 회사의 역량으로 간주될 정도로 기법의 중요도는 시간이 흐를수록 높아졌고, 기법의 자산화는 프로젝트 종료의 필수 프로세스가 되었다.

기법은 다양한 형태로 정리된다. 프로젝트 산출물을 정리하여 재사용이 가능한 자산으로 활용하기도 하고, 소프트웨어 개발 로직을 체계화하여 프레임워크로 발전시키기도 한다. 액티비티(Activity)나 태스크(Task)의 수행 방법을 정리해 놓은 개발방법론, 가이드, 툴 등도 있다. 효율적인 프로젝트 수행을 위해서는 이러한 기법 활용이 필수적이다.

SI(System Integration) 중심에서 애자일과 UI/UX를 강조하는 솔루션 형 소프트웨어로 변화하고 있는 요즘에는 새로운 기법들이 주목을 받고 있다. 고객(사용자)의 요구사항을 개발자 관점으로 정리하던 SI와 달리 고객의 관점으로 정리하는 것과 소프트웨어를 시스템 관점이 아닌 비즈니스 관점으로 설계하는 것이 그것이다. 이번 회에서는 고객의 관점으로 요구사항을 정리하는 기법과 소프트웨어를 비즈니스 관점으로 설계하는 기법에 대해 살펴보고자 한다.

고객 관점의 요구사항 정리 기법

SI와 솔루션에서 개발 방법은 크게 다른 점은 없다. 기획 단계나 완성 후에 릴리이즈 하는 방법이 다르기 때문에 개발방법론 혹은 프로세스에서 다소 차이가 있다고 볼 수 있다. 하지만, 개발자가 고객의 요구사항을 정리하는 방법은 SI와 많은 차이를 보이고 있다. 이번 절에서는 개발자가 고객 관점으로 요구사항을 정리하는 기법에 대해 살펴보도록 한다. 전통적인 소프트웨어 개발 프로젝트는 SI가 많다. 고객의 요구사항에 맞춰 약속된 일정에 개발해야 하기 때문에 요구사항을 어떻게 정리하고 관리할 것인지가 매우 중요한 포인트였다(그림 1 참조).

<그림 1> 고객 요구사항의 흐름

<그림 1>를 살펴보자. RFP(Request for Proposal 혹은 Reference for Proposal)는 제안을 받기 위한 고객 요구사항을 명시한 문서다. 제안서는 RFP를 참고해서 작성하는 것이 정석이고, RFP에 포함된 요구사항을 제안서에 모두 반영해야 한다. 고객의 지식으로 RFP를 작성하기 어려울 경우 더 쉽게 기술된 RFI(Request for Information)를 작성한다.

개발자는 고객의 요구사항을 구두나 문서로 확인하고 제안서를 작성한다. 고객은 개발자에게 “난 잘 모르니까 알아서 잘 만들어 주세요!”라고 하면, 개발자는 경험과 상상에 의존하여 제안서을 제출한다. 바로 여기서 문제가 발생한다. 고객이 원하는 것이 무엇인지 확인하면서 정리해야 하는데 이 과정이 간과되는 것이다.

사용자스토리 워크샵

최근에는 소프트웨어를 기획하는 단계부터 고객과 함께 고객의 용어로 정리하는 사용자스토리 워크샵이 확산되는 추세다. 고객과 함께 의사소통하며 기획하기 때문에 요구사항에 대한 명확한 정리가 가능하다. 커뮤니케이션을 중요시하는 애자일 기반 프로젝트에서 처음 알려진 사용자스토리 워크샵은 소프트웨어 기획 단계부터 고객을 참여시켜 고객이 원하는 바를 체계적으로 정리하는데 목적이 있다.

<참조사이트 소개>

사용자스토리 워크샵은 고객의 요구사항을 정확히 이해하고 명확히 소프트웨어에 반영하기 위한 도구라고 할 수 있다. 개발자는 소프트웨어를 개발하기 위해 요소기술만 알아서는 품질이 높고 사용자가 편한 소프트웨어를 개발할 수 없다는 것을 명심해야 한다. 사용자스토리 워크샵을 통해 고객의 요구사항을 잘 정리해도 소프트웨어에 잘 반영하지 못하면 소프트웨어의 품질과 고객의 만족도는 떨어질 것이다. SI에서도 많이 활용되던 요구사항추적표는 정리된 요구사항이 언제, 어떻게 반영되었는지 확인할 수 있게 한다.

더 보기 >>>

품질향상을 위한 TCOE(Test Center Of Excellence) 구현방법

성공적인 비즈니스 운영을 위해, 기업은 효율적이고 안정적이면서 복잡한 비즈니스 프로세스를 지원할 수 있는 소프트웨어 시스템을 필요로 한다. 그러한 인프라를 바탕으로 기업들은 신속하게 새로운 기술/기능을 지원하는 애플리케이션을 제공해 시장에서 경쟁 우위를 얻고, 고객들로부터 좋은 평가를 받고자 하는 것이다.

하지만 이를 위해서는 기존의 품질관리 체계의 변화가 필요하다. 기존의 프로젝트 수준의 품질 보증(QA)은 더 이상 이러한 변화와 속도를 유지하는 데 필요한 추진력과 효율성을 제공하는 데 한계가 있기 때문이다. 이를 해결하기 위한 테스트 프로세스의 개선과 인력 확보 등을 위해 노력하고 있는 STA테스팅컨설팅의 조호행 수석을 통해, 테스트 역량을 높일 수 있는 방법에 대한 살펴본다.

<STA테스팅컨설팅 조호행 수석컨설턴트>

Q: 최근 소프트웨어 시장에서 나타나는 QA 문제점은 뭘까요? 개선 필요 사항이 있다면 어떤 것이 있나요?

오늘날의 많은 기업들은 그 어느 때보다 빠른 속도로 혁신적인 기술과 새로운 시스템을 도입하고 있습니다. 그리고 이러한 노력 이면에는 IT 팀으로 하여금 더 높은 시스템의 효율성을 강조하게 되는데요. 이러한 압박은 기술 변화가 도입될 때 비즈니스의 중단을 최소화하기 위해, QA팀에게 ‘엔드-투-엔드’ 관점의 비즈니스 프로세스 유효성을 검증할 것을 요구합니다.

이에 따라, 품질의 이슈와 운영상의 문제를 피하기 위해서 체계화된 테스트가 필요해진 것이죠. 이전에는 이와 같은 품질관리가 프로젝트 단위로 이뤄졌다면, 최근에는 좀 더 체계화된 형태의 ‘그 무엇’을 요구하게 된 것입니다.

많은 기업이 운영하는 시스템(서비스)에 대한 품질불만을 해결하느라 고심하고 있습니다. 기술변화는 급격하게 이뤄지는데, 테스트 역량은 부족하고 체계적이지 않으며, 품질에 대한 불만은 지속적으로 발생되고 있는 것이죠. 반면, 테스트를 위해 투입되는 돈은 적지 않은 상황입니다.

이를 해결하기 위해 테스트 프로세스를 개선하고, 테스터들의 역량 향상과 전문적인 역량을 갖춘 인력의 확보가 필요할 수 있으며, 때로는 테스트 업무(공정)의 분리와 전담운영을 통해 (도메인 별) 테스트 역량을 확보해야 할 수 있습니다. 그리고 정량적 결함 관리로 유사 결함 예방 체계를 운영하는 노력도 필요할텐데요. 그러한 고민의 결과로 ‘TCOE(Test Center Of Excellence)’가 만들어졌다고 볼 수 있습니다.

더 보기 >>>

2016년 2월 22일 월요일

SW 개발 산출물 작성 가이드(위험관리 계획서 및 위험관리 문서)

자료 다운로드

SW 개발 산출물 작성 가이드(프로젝트 계획서)

자료 다운로드

2016년도 SW공학기술 현장적용 지원사업 공고

2016년 2월 19일 금요일

SW개발 단계별 수행사례(항공)

SW개발 단계별 수행사례는 소프트웨어공학센터에서 개발된 SW R&D 품질검증 기준을 기반으로 SW 개발시 단계별, 역할별 활동과 방법을 실사례와 함께 제공합니다. 실사례는 공통 및 8개 분야(자동차, 의료기기, 홈네트워크, 지식정보보안, 차세대 이동통신, 빅데이터, 항공, 스마트 그리드)에 대해 산업특성이 반영된 사례를 제공합니다.

SW개발 단계별 수행사례(빅데이터)

SW개발 단계별 수행사례(차세대이동통신)

2016년 2월 18일 목요일

SW개발 단계별 수행사례(지식정보보안)

SW개발 단계별 수행사례(홈네트워크)

SW개발 단계별 수행사례(의료기기)

SW개발 단계별 수행사례는 소프트웨어공학센터에서 개발된 SW R&D 품질검증 기준을 기반으로 SW 개발시 단계별, 역할별 활동과 방법을 실사례와 함께제공합니다. 실사례는 공통 및 8개 분야(자동차, 의료기기, 홈네트워크, 지식정보보안, 차세대 이동통신, 빅데이터, 항공, 스마트 그리드)에 대해 산업특성이 반영된 사례를 제공합니다.

2016년 2월 17일 수요일

SW개발 단계별 수행사례(자동차)

SW개발 단계별 수행 사례(공통)

SW개발 단계별 수행사례란(스마트그리드)

2016년 2월 16일 화요일

프로젝트 수행 - 팀 구성

소프트웨어 개발을 할 때 가장 고민되는 것이 “몇 명을 몇 개월이나 투입해야 하는가”이다. 초기에는 프로그래밍 라인 수에 의존했지만 최근에는 기능점수(Function Point), 코코모(Cocomo; COnstructive COst MOdel) 등을 통해 보완하고 있다.

Function Point: https://en.wikipedia.org/wiki/Function_point
Cocomo: https://en.wikipedia.org/wiki/COCOMO

하지만, FP나 Cocomo를 통해서도 근본적인 고민은 해결할 수 없다. 소프트웨어의 규모를 이용해 개발 비용을 예측하는 방법이기 때문에 프로젝트 성공을 위한 팀 구성은 알 수가 없다. FP나 Cocomo는 견적을 위해서는 필수라고 할 수 있지만 팀 구성에서는 참고로만 활용하는 것이 좋다.

일반적으로, 팀을 구성하는 이유는 비슷한 일을 하는 사람들끼리 함께 일하며 의사결정이나 협업이 원활하도록 하는데 목적이 있다. 하나의 개발팀도 다양한 세부 팀으로 나누어 구성된다.

세부 시스템 단위로 개발하던 클라이언트/서버 환경에서는 세부 시스템 별로 세부 팀을 구성하였고, 레이어(Layer) 단위로 개발하는 웹 환경에서는 역할에 따라 세부 팀을 구성(그림 1 참조)한다. 최근에는 애자일 팀, 데브옵스(DevOps) 팀과 같이 프로젝트 성격을 구분하여 구성하는 팀도 많아지고 있다.

<그림 1> 역할에 따라 팀을 구성

앞에서도 말한 것처럼, 팀 구성의 가장 큰 목적은 의사결정과 협업이다. 프로젝트를 수행하다 보면 협업이 잘 되지 않아 의사결정이 느려지고 문제가 발생하는 경우가 많다.

예를 들어, 세 명의 팀원이 프로젝트를 수행하고 있는 도중에 작업은 지연되고 납기는 다가오고 있어서 한 명의 팀원을 추가 투입했다. 상식적으로는 프로젝트가 원활해져야 하지만 오히려 더 지연되는 경우가 많다(그림 2 참조).

<그림 2> 프로젝트에 1명이 추가되는 경우 커뮤니케이션 채널의 변화

<그림 2>를 살펴보면, 기존 팀원 간의 커뮤니케이션 채널(실선)에 새로운 팀원은 커뮤니케이션 채널을 추가(점선)로 만들어야 한다. 현재까지 달성한 것이 무엇인지, 지금까지 완성하지 못한 것은 무엇인가를 파악해야 하기 때문이다. 이러한 문제를 정리하여 ‘Brooks의 법칙’이 만들어졌다.

소프트웨어 개발에 사람을 늦게 투입하면 더 지연시킨다.

하지만, Brooks의 법칙이 있다고 납기가 늦어지는 프로젝트에 추가 팀원 투입을 늦출 수는 없다. 프로젝트의 성격을 잘 파악해서 팀을 구성해야 하고, 추가 팀원이 필요한 경우 팀 구성에 따라 적절하게 투입할 수 있어야 한다. 더 보기 >>>

피드 구독하기: 글 ( Atom )