IT 프로젝트를 성공으로 이끄는 요인들

Critical success factors for software projects: A comparative study

IT 프로젝트 성공률

IT 프로젝트의 성공률이 더디지만 조금씩 향상되고 있다. 미국의 유명한 리서치 기관인 스탠디쉬 그룹(The Standish Group)이 발행하는 Choas report에 따르면, 1994년 16%에 불과했던 프로젝트 성공률은 2008년에 32%로 증가하였다. 아울러 프로젝트 실패율은 같은 기간 동안 31%에서 24%로 줄어들었다는 것을 확인할 수 있다.

개발방법에 따른 프로젝트 성공률과 생산성 차이

대부분 IT 프로젝트는 여러 사람이 함께 작업하는 공동 개발 형태이다.

프로젝트에서 선택한 개발방법에 따라 프로젝트 수행절차, 관리체계 그리고 의사소통과 같은 협업방식에 차이가 생기게 마련이다. 가령, 폭포수(Waterfall) 개발방법에서는 이전 단계가 끝나야만 다음 단계를 시작할 수 있기 때문에 전체적인 설계 과정이 완벽하게 이루어져야만 개발을 수행할 수 있다. 반면 애자일(Agile) 개발방법에서는 짧은 주기를 반복하며 시스템을 점증적으로 개발하기 때문에 전체시스템을 쪼개서 설계, 설계, 테스트, 통합이 이루어지는 과정을 반복한다. 

IT 프로젝트 성공요인

위에서 프로젝트 성공률과 생산성에 개발방법이 중요한 역할을 한다는 점을 파악하였다. 그렇다면 특정 개발방법론만 적용하면 프로젝트가 성공할 수 있을까?

물론 그렇지 않다. 그 어떤 개발방법도 모든 문제를 해결하는 마법 탄환(magic bullet)은 아니다. 개발방법론은 IT 프로젝트의 성공요인을 얼마나 잘 다루고 효과적으로 향상시키는가라는 관점에서 이해하는 것이 타당할 것이다. Nasir와 Sahibuddin 교수는 Academic Journals에 "Critical success factors for software projects: comparative study"이라는 논문을 발표하였다. 

자세히 보기 →

하이브리드 솔루션, 애자일 방법론과 폭포수 방법론의 결합

많은 조직들은 수십 년 동안 소프트웨어 개발의 폭포수 모델, 소프트웨어 개발 라이프사이클(SDLC) 등과 같은 전통적인 소프트웨어 방법론을 사용해 왔습니다. 이러한 전통적 개발 방법론에서 애자일 개발로 개발부서들을 바꾸는 것은 말처럼 쉬운 일은 아닙니다. 이와 같이 수많은 개발조직에서 여전히 폭포수 방법론을 활용하고 있으나, 애자일 방법론이 급속히 확산되고 있는 추세입니다.

　

애자일 방법론은 많은 장점을 가지고 있지만, 전통적인 소프트웨어 개발 방법론의 몇몇 특성들이 부족하기 때문에 애자일 방법론만을 고집하기 보다는 하이브리드 솔루션이 오히려 조직을 위해 적합한 솔루션이 될 수 있습니다. 　

　

즉 애자일 방식의 수많은 장점에도 불구하고 때로는 완전한 해결방법이 될 수 없으며, 이러한 경우 애자일 방법론과 폭포수 방법론을 결합한 하이브리드 솔루션이 적절한 해결책이 될 수 있습니다. 여기에서는 애자일 방법론이 일부 조직에는 적합하지 않는 이유들과 하이브리드 솔루션이 적절한 솔루션이 될 수 있는 몇 가지 이유를 소개합니다.

Ⅰ. 애자일 방법론에 적합하지 않은 프로젝트와 문제

Ⅱ. 개발 조직에 관한 빠른 문화적 변화의 어려움

Ⅲ. 다른 이해 관계자에 관한 변화의 어려움

Ⅳ. 계약 의무

Ⅴ. 분산 개발 그룹

Ⅵ. 결론

자세히 보기 →

멀티코어 기반의 어플리케이션 소프트웨어 아키텍처 대안 간의 성능 비교 방안

휴대용 전자 제품 ( 스마트 폰 , 고성능 카메라 , 휴대용 멀티미디어 기기 ) 에 대한 이미지 처리 소프트웨어를 포함하는 멀티미디어 소프트웨어와 3D 게임과 같은 소프트웨어의 성능 개선 요구가 증대되고 있습니다 . 스마트 폰의 경우 , 디스플레이 및 저장 장치의 대형화와 카메라의 발달로 인해 , 사용자는 고품질의 콘텐츠를 생산하고 , 이를 소비할 수 있게 되어 있습니다 . 하지만 이러한 고품질 , 대용량의 콘텐츠를 처리하는 소프트웨어들은 사용자의 요구에 미치지 못하는 성능을 보여주고 있습니다 . 현재까지는 하드웨어의 성능이 발전함에 따라 , 시스템의 성능이 개선되어 왔습니다 . 하지만 휴대용 전자 제품에 들어가는 프로세서의 발전이 과거에는 코어의 클럭을 향상시키는 방향에서 현재는 코어의 개수를 늘리는 방향으로 전환되었습니다 . 즉 , 데이터를 처리하는 프로세서가 싱글코어에서 멀티코어로 변경되었지만 , 싱글 쓰레드로 구성된 기존의 소프트웨어는 하나의 코어만을 사용함으로 인해 하드웨어 발전의 덕을 보지 못하게 되었습니다 . 따라서 제품의 성능 개선을 위해서는 기존의 소프트웨어를 멀티코어를 지원하도록 수정해야 합니다 .

본 연구에서는 멀티코어 기반의 소프트웨어개발 비용을 줄이기 위해 소프트웨어 아키텍처 작성 단계 ( 소프트웨어를 쓰레드로 나누어 설계하고 , 이들 간의 통신을 정의한 시점 ) 에서 , 각 구성에 대한 상대적 우위의 성능을 보여줄 수 있는 구성을 선택하는 기법을 제안합니다 . 제안하는 기법에는 성능 측정을 위한 성능 모형을 제안하며 성능 모형을 작성하기 위한 정보와 성능 모형의 시뮬레이션 기법에 대해 설명합니다 .

자세히 보기 →

SW 안전성 컨퍼런스 안내 (2015.10.21. 수)

안녕하세요.
SW공학센터의 조지만입니다.

저희 SW공학센터에서는 SW기능 안전성에 관려하여 컨퍼런스를 개최하고자 합니다.
이번 행사는 SW안전성 확보 방안 및 사례발표 등을 통하여 SW안전성 인식 제고하는데 목적으로 하고 있습니다.

행사는 크게 2개의 파트로 구성되어 있습니다. 파트 1에서는 SW안전성 확보 방안을 주제 진행하고 있으면 파트 2에서는 주요 산업분야 기능 안전 사례 발표로 진행됩니다. 파트 1에서는 SW안전성 보증 연구 센터장이신 상명대학교 한혁수 교수님과 현대자동차의 이기춘 연구개발기획실장님께서 강의를 해 주실 예정입니다. 파트 2에서는 의료, 철도, 에너지(원자력), 자동차의 SW기능 안전 사례를 들을 수 있습니다.

올해 처음으로 열리는 SW안전성 컨퍼런스라 부족한 부분이 많이 있을 것으로 예상됩니다. 그러나 우리나라 SW안전성에 관한 것을 한 자리에서 볼 수 있는 좋은 자리라고 생각이 됩니다. 이에 관심있으신 분들의 많은 참여 부탁 드립니다.

신청하러 가기 →

본 컨퍼런스는 무료이며 웹사이트를 통해서 사전등록이 가능합니다. (사전등록 선착순 마감)

컨퍼런스 참석하신 분 중 선착순 200분께 자료집과 기념품 교환권을 드립니다. (사전등록자에 한함)

등록데스크에서 행사 종료 후 기념품 교환권을 기념품으로 교환에 드립니다.

문의처: SW안전성 컨퍼런스 담당 (02-2132-1366 / kidjoji@nipa.kr)

만약 처음 SW안전성에 대하여 들어보셨다면, SW안전성이 무엇인지 궁금하실 것으로 생각됩니다. SW안전성에 대하여 궁금하시면 아래의 링크를 클릭해 보세요.

고신뢰 융합SW를 위한 필수 SW공학기술 연구용역 보고서 소개 -> 

반복적인 시스템 개발환경에서 적절한 시기에 요구사항 수집하기

전통적인 ALM (Application Lifecycle Management)은 프로젝트 시작부터 끝까지 지속적으로 소프트웨어를 관리할 것을 요구합니다. 요구사항, 아키텍처, 코딩, 테스팅, 릴리스, 결함 관리 등 그것은 소프트웨어 개발의 모든 측면을 포함하고 있습니다. 그러나 관건은 시작 방법, 요구사항 수집 방법, 수집해야 하는 분량 등 세부사항에 있습니다.

따라서 반복적인 시스템 개발 (iterative development)이 어떻게 소프트웨어 팀들이 적절한 시기에 적절한 요구사항을 얻도록 돕는지를 소개하고자 합니다. 전통적인 개발방법론 하에서 개발프로세스 상의 요구사항 수집은 개발 초에 시행되고 반복되지 않고 있습니다. 그러나 애자일 방법론에 있어서는 지속적으로 프로세스가 반복되고 요구사항이 주기적으로 수집됨에 따라 적절한 시기에 요구사항을 반영하는 것이 중요합니다.

요구되는 세부사항의 정도

• 요구사항에 있어 애로점은 첨부할 수 있는 세부적인 사항들이 항상 있기 때문에 필요로 하지도 않는 많은 것들을 수집하기 쉽다는 것임.
• 애자일방법론 관점에 비춰 볼 때 많은 요구사항들이 실제로 도움이 되지 않는다는 것을 말해 줌.

적절한 시기의 요구사항

• 애자일 방식을 전통적인 ALM방법론들로부터 구분해야 할 필요가 있음. 
• 요구사항은 단지 수집되는 것만이 아니라, 프로젝트를 위해서 충분히 질문하고, 질문들을 반복해서 클라이언트로부터 대답을 얻는 것임.

중간 수정을 가능하게 하는 반복

• 반복의 개념은 여러 가지 애자일 방법론 중에 하나인 스크럼(Scrum) 방법론에서 볼 수 있음.
• 많은 기존의 방법론은 정확한 요구사항을 발견해서 작업 계획을 세우고 계획에 따라 작업하기를 요구함.

타임박스(timebox)의 중요성

• 애자일 방법론에서 살펴 볼 때 반복적인 시스템 개발 중에서도 단호하게 일정을 준수하는 타임박스가 중요함.
• 스크럼방법론에서 2주간 반복으로 한정했을 때, 이것이 의미하는 바가 있음.

자세히 보기 →

코드닥터- 알고리즘 가이드

개요

• Software의 개발은 부가가치가 높은 창조적인 활동
• 분야별 Software의 전문성의 차이는 매우 크다 (db , security , game 등)
• Software의 바른 동작을 위해서는 알고리즘 작성이 중요
• 알고리즘이란 작업을 수행하기 위한 과정 
• 복잡하고 어려운 작업일수록 높은 수준의 알고리즘 아키텍처 필요
• 쉽고 단순한 작업이라면 간단한 알고리즘의 경제성 활용 
• 알고리즘의 어려움 ？ 사람이 하는 일을 기계가 대신하기 위해서는 논리적이고 단순한 작업으로 분할 및 결합 필요 
• Software를 개발하기 위해서는 이와같은 알고리즘들에 대한 총체적인 관리가 필요

알고리즘 기법 소개

• 정렬
• 통신 프로토콜
• UI 프로그래밍
• 데이터 프로그래밍
• 스케쥴링
• 클라우드 분산 프로그래밍(GFS , mapreduce , big table)

자세히 보기 →

빅데이터 확산을 위한‘스케일 아웃 NAS' 아키텍처 구축의 5가지 기본원리

비정형 데이터를 실행 가능한 비즈니스 인텔리전스(Business Intelligence, 이하 BI)로 변환하고자 한다면, 첫 번째 단계는 데이터의 페타바이트(Petabyte, 이하 PB)를 처리할 수 있는 스토리지 아키텍처를 구축하는 것입니다. EMC 아이실론(Isilon)의 닉커쉬(Nick Kirsch)는 스케일 아웃(Scale-out) NAS(Network Attached Storage)가 가장 좋은 솔루션이라고 언급합니다. 빅데이터는 지금까지와는 다른 저장방식을 요구함에 따라 데이터의 빠른 증가속도를 따라갈 수 있도록 선형적 확장을 지원하는 스케일 아웃 NAS가 주목받고 있습니다. 이에 기업/공공기관에서 효과적인 스케일 아웃 NAS 아키텍처 구축을 위한 기본원리를 소개합니다. 

스케일 아웃 NAS의 개요

기업은 실행 가능한 BI를 위해 데이터 마이닝(mining)에 대한 기대와 더불어, 종이문서를 디지털화하고 이메일, 워드 문서, 엑셀 파일 등 모든 다른 비정형 데이터들을 저장하는 빅데이터의 세계로 가고자 합니다.

기업의 정보는 급작스럽게 페타바이트급으로 늘어나 축적되고 있기 때문에, 그들이 해결해야 할 가장 큰 문제는 스토리지입니다.

스케일 아웃 NAS의 5가지 기본원리

1. 단순한 구성을 할 것
2. 예측 가능할 것
3. 효율적으로 구성할 것
4. 항상 사용가능할 것
5. 기업 환경에 맞출 것

자세히 보기 →