소프트웨어공학 포털 블로그

2016년 11월 30일 수요일

애자일과 전통적 개발방식의 조화

제품개발 패러다임의 변화

Project Management 목표

SW개발프로젝트사례

•프로젝트개요
–건축설계관련솔루션개발, 개발기간2년

•주요이슈및문제점
–업무회의는많으나팀원들간에실질적인의사소통이되지않음
–제품기획의불안정으로불명확한목표및일정관리
–불필요하다고느껴지는산출물이많음
–업무성과및품질불량으로관리자와팀원간의갈등발생
–수동적인팀원의자세
–팀원들간의소통및협력부재(자기업무에만집중

2016년 11월 29일 화요일

동영상 : An Open Source Tool for Fault Tree Analysis

동영상 보기

참석자

Suzanne Miller - principal researcher at the SEI (the Carnegie Mellon University Software Engineering Institute)

Dr. Neil Ernst - a Fellow researcher who works in the SEI’s Architectural Practices Initiative

요약

기술 채무 (Technical Debt)
소프트웨어 개발 프로젝트를 진행할 때, 초기에 제대로 처리하지 않은 일이 반복 주기에서는 문제점으로 나타나고, 이러한 문제점이 다른 수정사항이나 또 다른 문제를 나타낼 수 있어 원금에 이자까지 지불해야 하는 상황이 온다는 개념

소프트웨어 개발을 시작한지 오래된 우리나라에서는 단순 개발이나 공통 개발이 필요한 분야를 한데 모아 효율적으로 관리하고자 노력하고 있다. 이에 대한 대안으로 원격 개발센터 모델이 제시되었는데 많은 투자와 노력에 비해 성공률이 높지는 않은 것이 현실이다. 이번 회에서는 원격 개발센터에 필요한 프로세스나 방법론을 정비하여 적용한 경험이 있는 ㈜Coocon의 한용만 박사와 단국대학교 소프트웨어공학센터 김규억 박사를 만나 원격 개발센터에 대한 이야기를 들어보도록 한다.

Q: 안녕하세요. 원격 개발센터를 위한 프로세스와 방법론을 아시아권에 일부 적용한 것으로 알고 있습니다. 원격 개발센터는 어떤 기업들이 고민하는 것인가요?

처음부터 개발자들을 분리하여 원격 개발센터를 만들 수는 없습니다. 같은 분야의 개발 업무를 오래도록 하다 보면, 단순 개발 업무가 나타나게 되는데 이런 업무를 인건비가 비싼 우리나라 개발자에게 계속 맡기면 비용 대비 효과가 많지 않습니다. 그래서, 인건비가 싼 중국이나 아시아권의 다른 지역에 개발 업무를 넘기는 것입니다. 그림1을 보면, 개발에 필요한 설계, 개발, 테스트를 원격 개발센터에 넘겨 업무를 수행하게 되는데, 경우에 따라 설계 업무는 넘기지 않는 경우도 많습니다.

<그림1> 원격 개발센터의 예

원격 개발센터를 운영하는 또 다른 중요한 이유는 다수의 사이트에서 공통으로 사용되는 부분을 원격 개발센터에서 담당하는 것입니다. SI를 예로 들면, 각 사이트마다 개발자들이 파견을 가게 되는데, 공통적으로 개발되는 부분은 한 곳에 모여서 개발하는 것이 훨씬 효율적이지요. 공통 개발을 위한 원격 개발센터는 기업의 본사에 위치해서 빠른 의사결정 하에 운영하는 경우가 많습니다.

UX 사례 연구 - 멀티 디바이스의 UX

1인 다(多) 디바이스의 시대가 도래했다. PC 위주였던 과거에서 스마트폰, 테블릿PC에 이어 TV나 스마트홈까지 장소나 크기에 제한 받지 않고 스마트 디바이스를 사용하는 시대인 것이다. 다수의 디바이스를 장소나 상황에 따라 동시에 사용할 수 있는 것을 멀티 디바이스라고 하는데 한 사람이 다수의 디바이스를 사용하지만 컨텐츠는 디바이스에 맞춰 보여줘야 하는 요구사항이 있다. 이번 회에서는 멀티 디바이스를 위한 UX에 대해 알아보기로 한다. 멀티 디바이스를 위한 UX를 이해하여 소프트웨어 사용성과 편리성을 높여주길 기대한다.

사례 연구 전 확인 사항

한 명의 사용자가 다수의 디바이스를 사용하지만 컨텐츠는 끊김 없이 보여줘야 하기 때문에 UX의 역할이 점점 더 중요해지고 있다. PC, 테블릿이나 스마트폰 단위로 따로 UX를 설계했던 과거와는 달리, 개인이 보유한 디바이스의 수도 늘어나고 IoT까지 발전하고 있어 멀티 디바이스의 요구가 점점 늘어나고 있다(그림1).

<그림1> 멀티 디바이스와 멀티 스크린의 개념

출처: Etri

그림1을 살펴보면, 멀티 디바이스는 하나의 컨텐츠를 다양한 디바이스에서 동시에 나타나도록 하는 것, 하나의 디바이스에서 사용된 정보는 모든 디바이스에서 사용된 것처럼 공유하고, 디바이스 간 정보 교환 등이 가능하도록 해주고 있다. 구글(Google)에서는 멀티 디바이스를 위한 UX 설계에 기본적인 사용자 경험을 여러 디바이스에 복제하는 일관성(Consistent), 한 디바이스에서 다른 디바이스로 사용자 경험을 전달하는 연속성(Continuous), 여러 디바이스가 합쳐지면서 새로운 사용자 경험을 만들어 내는 상호보완성(Complementary)을 고려 하도록 가이드하고 있다.

2016년 11월 28일 월요일

SI 프로젝트와 개발 문화

Q: 문화를 바꿔야 SI 프로젝트 수행이 쉬워진다는 것으로 정리하겠습니다. SI 프로젝트 수행이 어려운 두 번째 이유를 말씀해주시죠.

SI 프로젝트는 고객의 요구사항을 정확히 적용해야 하기 때문에 처음부터 모든 것을 새로 개발하는 경우가 많았습니다. 이렇게 되면, 가장 큰 문제가 검증입니다. 아무리 능력이 뛰어난 개발자가 개발해도 단 한번에 성공하는 시스템은 없습니다. 반복해서 테스트해야 하고 문제가 없는지 되돌아 봐야 하기 때문에, 반복되는 작업에 점점 지쳐가는 것이죠. 그나마도 이젠 끝이라고 확신을 가질 수도 없습니다.

저는 금융 프로젝트를 많이 했는데, 검증의 문제는 언제 어디서든 터질 수 있는 이슈사항이었지요. 이런 이유 때문에, 많은 SI 회사에서 품질이나 지원도구 같은 검증 도구를 많이 사용했지만, 우리가 인스펙션(Inspection), 워크스루(Walkthroghs), 통합 테스트 등을 하면서도 문제를 근본적으로 해결하기는 어려웠습니다(표1). 안타깝지만, 새로 만들었기 때문에 이러한 문제가 다소 발생하는 것을 인정해야 한다는 것입니다.

<표1> 워크스루와 인스펙션의 정의

Q: SI 프로젝트를 하면서 새로 개발하는 것은 어떻게 보면 당연한 일인데, 어떤 해결 방법이 있을까요?

그림2에서 보는 것처럼, 유사한 기능을 가진 완성된 것들을 활용하자는 겁니다. 어떻게 보면, SI 프로젝트는 무조건 새로 개발해야 한다는 것은 우리가 만든 규칙인지 모릅니다. 새로 만드는 소프트웨어의 개수에 따라 비용이 지불된다는 암묵적인 약속 때문이겠지요. 비용 산정을 위해 LOC(Line of Code)나 기능점수(Function Point), 코코모(CoCoMo)를 찾는 것도 SI 프로젝트는 코딩의 규모만 반영되었다는 단편적인 증거가 될 것입니다. SI 프로젝트는 고객이 시스템을 이용해 업무를 원활히 할 수 있도록 해주는 것입니다. 컨설팅과 개발을 함께 갖고 있다고 생각해야 합니다.

SI 프로젝트의 요구 사항과 필요 역량

Q: 시장과 사업 관점에서는 SI 프로젝트가 힘들 수 밖에 없다는 것을 인정해야 한다는 말씀으로 들립니다. 그렇다면, 프로젝트를 수행하면서 힘들 수 밖에 없는 근본적인 이유는 어디에 있을까요?

얼마 전에 이 문제에 대해 모 대학의 소프트웨어공학 연구소와 분석해 본적이 있습니다. 두 가지 이유로 요약을 해보면, 첫 번째는 SI 프로젝트의 고객들은 소프트웨어를 너무 모르는데 개발자들은 너무 많은 것을 알려달라고 한다는 것이었습니다. 그리고, 두 번째는 고객들이 요구하는 것을 무조건 새로 만든다는 것이었습니다.

Q: 고객들이 소프트웨어를 너무 모르는데 많은 것을 물어본다고요?

네, 그렇습니다. 요구사항을 고객한테 받게 되는데, 개발자들은 전문 용어를 섞어가면서 물어보는데 고객은 잘 모르는 상태에서 대답하는 경우가 많다는 것이지요. 사실, 프로젝트 초기에는 개발자도 업무를 모르게 때문에 양쪽 모두 서로 모르는 상태에서 제일 중요한 요구사항을 정리하는 것입니다.

Q: 이전 인사이드이슈에서도 다뤘던 것 같습니다. 요구사항을 고객의 용어로 정리해야 한다는 말씀이지요?

고객의 용어로 정리하는 것은 매우 중요한 포인트입니다. 시스템을 완성하고 확인을 해줘야 하는 사람이 고객이기 때문에 고객의 용어로 정리하라는 것입니다. 어떻게 보면, 당연한 이야기인데 그 동안의 SI 프로젝트에서는 고객이 자꾸 요구사항을 변경한다고 싫어했던 기억이 있습니다. 이러한 문제를 해결하기 위해, 애자일이나 사용자 스토리 워크샵 같은 활동이 최근에는 활발히 적용되고 있습니다. 개발자에게 개발 역량뿐만 아니라 고객(사용자)를 이해하는 능력도 필요하다는 얘기입니다(그림4).

<그림4> 소프트웨어 개발자의 필요 역량 변화

침체된 SI 시장과 극복 방안

Q: SI가 시장 관점이나 개발자 관점 모두 어려운 것이 현실이라면 SI 프로젝트를 왜 하는 것인가요?

이 것도 두 가지로 볼 수 있습니다. 먼저, 매출이 매우 크다는 점이지요. 단기간에 대형 시스템을 구축하려면, 많은 소프트웨어를 개발해야 하고 구동이 가능하도록 하드웨어도 설치해야 하지요. 이렇게 많은 매출을 발생시키기 때문에 회사의 규모를 키우기 위해서는 SI 프로젝트가 필요합니다. 하지만, 더 큰 이유가 두 번째인데요. SI 프로젝트는 소프트웨어 생명주기(Software Life Cycle)을 모두 포함하기 때문에 짧은 시간에 개발 역량을 성장시키는데 매우 적합합니다. 교육을 따로 시키지 않아도 실전으로 경험과 지식을 쌓을 수 있는 것이지요. 누가 뭐래도 IT 서비스 산업의 성장은 SI 프로젝트가 이끌었다는 것은 부정할 수 없을 겁니다.

하지만, SI 시장에 뛰어드는 업체가 점점 많아지고 있고, 진입 장벽은 높지 않다 보니 대형 SI 업체들은 해외로 눈을 돌리거나 다른 부문으로 전환을 하는 추세입니다(그림3).

<그림3> SI 업체의 사업부문 매출 현황

출처: CEO 스코어

피드 구독하기: 글 ( Atom )