국가별 소프트웨어공학센터 현황 비교

미 국방성은 DoD-STD-2617과 같은 계약 표준에서 계약이행 시 각 마일스톤마다 관리자 검토, 비용 지불처리 및 보상비용을 서로 연계시키는 폭포수 모델의 사용을 강제함에 따라 능력 있는 SW 개발업체를 선정하는 기준이 필요하였다. 이를 해결하기 위해 미 국방성은 SW개발 조직의 SW프로 세스 성숙도를 평가하기 위한 방법론을 개발하기 시작하였으며, 미 국방성의 지원을 받은 SEI에서 SW-CMM20)을 개발하게 되었다. SW-CMM은 순차적인 폭포수 모델의 요소들을 유지하고 있기 는 하지만 특정 방법론에 독립적으로 구성되었으며, SW개발조직의 능력평가와 개선에 대한 효과적 인 틀을 제공하였다. 

SW-CMM으로 촉발된 SW프로세스 개선 활동은 재작업을 줄임으로써 생산성을 급속히 향상시켰 지만, SW개발 업무에 있어 업무 자체를 줄이게 되면 생산성이 파격적으로 향상될 것이라고 인식하 기 시작하였다. 그래서 미 국방부는 SW생산성 향상을 위해 STARS (Software Technology for Adaptable Reliable System) 프로그램을 추진하였으며, 이 프로그램에서 SW개발 시 불필요한 작업을 없애기 위한 혁신적이고 점진적인 방식을 발표하였다. 

1 혁신적인 방식으로는 1970년대 초반의 “자동 프로그래밍” 연구와 비슷하게 요구사항에서 코딩 까지의 정형적인 명세와 자동 변환 방식을 강조
2 점진적인 방식으로는 인력채용(Staffing), 재사용, 프로세스, 도구 그리고 통합 환경에 의해 지 원되는 관리활동을 강조
이를 본격적으로 연구하기 위해 카네기멜론 대학에 소프트웨어공학센터(SEI/CMU)를 설립 (1984년)하였으며, 유럽과 일본에서도 비슷한 움직임을 보였다. 각국의 주요 소프트웨어공학 센터 현황은 아래와 같다. 

더보기

'SW 위기(SW Crisis)'의 원인과 증상, 그리고 해결책

SW위기의 원인은 전반적으로 SW개발의 복잡성에 따른 것으로 이를 해결하기 위한 SW공학이 전문분야로서 상대적으로 미성숙했던 점과 관련되어 있음
1 SW규모의 대규모화, 복잡화에 따른 개발비용 증대
2 HW비용에 대한 SW가격 상승폭 증가
3 유지보수의 어려움과 개발적체 현상 발생 4 프로젝트 개발 및 소요예산 예측의 어려움 5 신기술에 대한 교육 및 훈련 부족 

위기는 여러 가지 증상으로 나타남
1 프로젝트 예산이 초과됨
2 프로젝트 일정이 지연되거나 SW가 고객의 손에 제대로 전달되지 못함
3 SW품질이 낮음(SW의 비효율성, 요구사항을 만족하지 못함 등)
4 프로젝트 관리가 불가능하고, 코드관리가 어려

SW의 위기를 타계하고자 다양한 방법론이 지난 수십 년간 개발되었지만 널리 공유된 견해는 “만병통치약은 없다(No silver bullet)”는 것임.

- 프로젝트 실패를 방지하기 위해 모든 경우에 통용될 수 있는 방법론은 없다는 견해가 일반적이며,
프로젝트가 규모가 크고, 복잡하며, 요구조건이 명확하지 않은 경우에는 사실상 예측 불가능한 여러 가지 위험에 노출되어 있음

HW와 SW의 차이점

특히, 1960년대는 대규모 시스템에 대한 수요와 그에 따른 SW에 대한 수요 급증으로 인해 SW 개발자 및 엔지니어가 부족하게 되어 인문학 및 사회과학 전공자 등 타 분야 전공자들을 고용해서 훈련하기 시작하였다. 이는 1950년대에 비해 상대적으로 좋아진 메인프레임 운영체제나 각종 유틸 리티, 특히 제2세대 언어인 포트란이나 코볼이 개발되면서 비전공자들의 SW분야 입문이 쉬워졌기 때문이었다. 하지만 당시 공학적인 개념이 부족한 인력들은 SW개발 시 선코딩-후수정 접근방식을 사용하게 되었으며 이는 창의적이기는 했으나, 수정사항이 과도하게 발생하는 스파게티 코드 (spaghetti code)를 양산하였다

이렇듯 1960년대는 대규모 시스템과 그에 따른 SW에 대한 수요가 급증하기 시작하였으나, 이를 구현하는 인력들의 경험과 능력, 수적인 부족으로 인해 수요와 공급에 커다란 차이가 존재하였다. 이로 인해 NATO 과학위원회가 SW공학 컨퍼런스(1968,1969)에서 ‘SW 위기(SW Crisis)'를 언 급하며 큰 프로젝트나 제품에 적용할 수 있는 보다 체계적인 방법과 원칙들이 필요함을 역설하게 되었으며, 이를 계기로 SW공학에 대한 연구가 본격적으로 시작하게 되었다. 이렇듯 SW공학은 SW 위기를 극복하고자 SW프로그램 개발에 공학적인 관점을 도입한 학제적인 산물로 SW공학의 모든 이슈는 고객의 기대(품질), 비용(예산), 납기(생산성)와 관련된 것이었다. 

더보기

21st SW Quality Insight Conference안내 (7/6(수))

자세히보기

스마트카 시장에서 주목해야 하는 소프트웨어의 역할

일반적으로, SI(System Integration)나 ITO(IT Outsourcing)에서 주로 만들어지던 소프트웨어는 최근 들어 다양한 산업으로 확대되고 있다. 소프트웨어가 기존에는 할 수 없는 기능을 지원할 수 있고 사람과의 상호작용(Interaction)을 더 원활하게 해주는 지능형 소프트웨어가 등장했기 때문이다. 이러한 이유로, 이미 오래전부터 더 똑똑한 자동차를 연구하던 자동차 업체와 함께 소프트웨어 업체가 스마트차에 관심을 가지게 되었다. 현재는 GM, 포드, 도요타 등의 자동차 회사는 물론 구글, 애플, 삼성전자 등도 소프트웨어 중심의 스마트차 연구에 몰두하고 있다.

새로운 플랫폼 스마트카
사람이 집과 회사 외에 가장 많이 있는 곳이 바로 자동차 속이라고 할만큼 자동차 사용 시간이 늘어나면서 자동차 속 시간을 효율적으로 사용하고 싶은 노력이 계속되고 있다. 올해 개최되었던 세계 최대 가전 박람회인 CES 2016 에는 가전보다 스마트카가 더 많이 등장하면서 대세였던 스마트폰을 몰아내고 있다. 가장 주목 받는 스마트카는 전기차와 자율주행 자동차이다. 전기차는 소프트웨어보다 장치 산업에 더 가깝지만 자율주행 자동차는 인공지능과 시각, 청각 등 인간의 오감을 대신할 수 있는 소프트웨어로 구현해야 한다.
수만개의 부품으로 만들어지는 자동차는 모든 부품을 완성차 업체에서 만들 수 없기 때문에 다양한 파트너와 함께 생태계를 구성한다. 이러한 생태계에 스마트카와 소프트웨어가 등장하면서 새로운 플랫폼을 갖게 되었다. 지금까지 자동차는 기능과 역할이 고정되어 폐기될 때까지 변경되지 않았지만 스마트카는 스마트폰과 같이 수시로 기능을 업데이트, 변경할 수 있고 기능을 확장할 수도 있다. 이러한 일을 위해서 하드웨어를 교체할 수도 있지만 앱과 같은 소프트웨어 교체로 쉽게 바꿀 수 있기 때문에 IT 업체에게 커다란 기회를 제공한다.

스마트카 관련 기술은 예전에도 있었다. 근접 센서로 사각지대에 물체가 있으면 알려주는 기능이나 후방 카메라를 통해 주차를 도와주는 기능도 스마트카 기술의 일종이라 볼 수 있다. 여기에, 더 우수한 디스플레이와 정보통신 기술이 접목되면서 성능이 더 좋은 스마트카가 나오고 있다. 스마트카 관련 기술은 크게 세 가지로 구분할 수 있다. 운전자의 안전성을 위한 기술, 운전자 편의성을 위한 기술, 조작성과 접근성을 높이는 기술이다.

더보기

대중화된 인포그래픽을 지원하는 웹기반의 프로그램

빅데이타 시대에 더 요구되는 정보의 시각화능력, 정보디자인

  귀에 꼽기만 하면 통역을 해주는 ‘파일럿 (Pilot)’이란 제품이 ‘웨어러블랩스’에서 개발되어 9월에 시판 될 예정이라고 한다. 이 제품이 나오면 힘들여 외국어를 공부하지 않아도 외국인과 자연스레 대화할 수 있다고 하니 언어에 어려움을 많이 느끼는 사람에게는 정말 획기적인 소식일 것이다. 또, BSA(The Software Alliance)의 보고서에서 따르면 “최근에는 이전보다 더욱 더 방대한 양의 데이터들이 생산되고 있다.

세계에 존재하는 전체 데이터의 90 퍼센트를 초과하는 양의 데이터가 최근 2 년 동안에 만들어진 것이며, 매 2 년마다 데이터가 생산되는 속도가 두 배씩 빨라지고 있다.”고 한다. 데이터가 생산되는 속도는 기하급수적으로 빨라져 현재를 살아가는 우리에게는 머릿속에 지식을 담아두는 것도 필요하지만, 필요한 지식을 더 빨리 찾아내는 검색능력이 더 많이 요구되기도 한다. 정보의 공급자와 수요자들의 생태계도 변화하고 있는데 정보의 공급자는 자신의 정보를 “빠르고 정확하게 전달”해야 하는 지에 대해 끊임없이 연구해야하고 정보의 수요자는 넘쳐나는 정보 속에서 자신이 필요한 정보를 잘 찾아내야 하는 것 바로 그것이다.

 이런 정보의 흐름 속에서 주목받게 되는 분야가 바로 정보 시각화 분야이다. 정보의 시각화는 얼마 전까지만 해도 데이터 시각화 (data visualization) 전문가들 고유의 영역이라고 인식되어 왔는데 이제는 누구에게나 필요한 능력으로 인식이 바꿔지고 있다. 이러한 정보시각화와 프레젠테이션 분야를 전국의 많은 대학에서 강의하는 굿프레지 엄혜경 대표와 정보 시각화의 최근 동향에 대해 이야기 나눠봤다.

Q. 정보의 시각화란 어떤 의미인가요?

예를 들어 커피숍에서 아메리카노가 팔리는 양을 매일 매일 적어 놓는 다면 이것은 바로 “데이터” 입니다. 가공되지 않는 데이터가 되는 것이죠. 이 데이터를 표나 그래프로 만들어 보여주는 것을 데이터의 시각화라 합니다. 그럼 이 데이터를 이용해 오전, 오후, 야간에 팔리는 아메리카노의 양을 또는 판매되는 패턴을 분석하여 직장이 많이 찾는 시간대, 학생들이 많이 찾는 시간대로 분류한다면 그건 “정보”가 되는 것이죠. 데이터를 목적에 맞도록 분류하고, 패턴을 찾고, 조직화를 한 것이 정보입니다. 이러한 정보를 시각화 하는 것이 “정보의 시각화” 입니다. 여기에 시각적으로 눈에 띄게 그래픽을 적극적으로 이용하여 스토리텔링 형식으로 표현하면 “인포그래픽”이 되는 것입니다. 정보시각화는 데이터시각화와 인포그래픽을 포함한 큰 범주입니다. 이런 전체 프로세서를 정보디자인이라고 부릅니다.

더보기

핀테크 사례 연구 - 개발 기법 편

핀테크는 기존 금융 시스템에 서비스 방법을 추가하는 것이기 때문에 기존 금융 시스템 자체는 변하지 않는다. 따라서, 핀테크 서비스를 위해 기존 금융 시스템에서 서비스를 호출할 수 있는 API와 제대로 동작하는지 확인하는 테스트 환경이 필요하다. 추가되는 핀테크 서비스의 구동 방법이나 환경은 핀테크 서비스 업체에서 자체적으로 구성하여 개발한다.
이번 회에서는 기존 금융 서비스를 호출할 수 있는 API를 제공하는 금융 플랫폼에 대해 살펴보도록 한다. 표준화된 금융 플랫폼을 이해하기 위해 서비스를 호출하고 동작을 확인하는 방법에 대해 알아보고 필요한 환경 구성에 대해 살펴보기로 한다.

사례 연구 전 확인 사항
핀테크 서비스를 위해서는 핀테크 업체가 금융 시스템의 서비스 모듈을 개발하는 것이 아니고 금융 업체가 가지고 있는 서비스를 호출해서 사용해야 하기 때문에 금융 업체는 핀테크 업체가 원하는 금융 서비스를 반드시 오픈 API형태로 제공해야 한다.
금융 서비스를 제공하기 위해 핀테크 업체에서는 새로운 서비스 제공 방법을 정리하여 사업 아이디어를 만들고, 금융 시스템과 오픈 API를 통해 연결한다. 개발된 API는 테스트 환경(Test Bed)을 통해 정상적으로 동작하는지 확인하고, 목표로 하는 기기에서 테스트 한다. 이상이 없다면 제품을 출시하게 된다(그림1).

더보기