[논문]소프트웨어 개발 성공의 정의와 평가기준

이상운; 최명복

doi:10.7236/jiwit.2012.12.2.233

소프트웨어 개발 성공의 정의와 평가기준
A Definition and Evaluation Criteria for Software Development Success 원문보기

한국인터넷방송통신학회 논문지 = The journal of the Institute of Internet Broadcasting and Communication, v.12 no.2, 2012년, pp.233 - 241

이상운 (강릉원주대학교 멀티미디어공학과) , 최명복 (강릉원주대학교 멀티미디어공학과)

초록
AI-Helper

프로젝트 관리의 목표는 프로젝트를 성공하기 위함이다. 그러나 프로젝트 수행 결과가 성공이라고 명확히 판단할 수 있는가? 또한 판단 결과에 고객과 개발자 모두 동의하는가? 성공과 실패에 대한 정의와 판단 척도들에 대해 다양하게 제시되고 있으나 명확한 분류 기준이 없다. 본 논문은 개발 성공을 결정하기 위한 판단척도들을 살펴보고, 프로젝트의 성공과 실패에 대해 재정의한다. 이러한 정의에 의해 프로젝트 수행 결과를 판단하는 척도와 기준을 제시한다. 제시된 판단 척도와 기준을 적용할 경우, 성공과 실패를 분류하는데 고객과 개발자간의 불협화음을 줄일 수 있을 것이다.

Abstract ▼ AI-Helper

The object of the project management is to succeed in the project. However, could you definitely judge that the result of project performance is a success? In addition, do both customer and developer agree with the result of your judgement? There are a lot of definitions and measure for the success and failure of the software development suggested, but there is no definite standard for the classification. This paper examines the measures in order to decide the development success and re-defines the success and the failure of the project. We suggest the measure and the standard that judge the project achievement based on these definitions. Applying the suggested measure and standard, it is possible to reduce arguments between the customer and the developer on the classification of the success and the failure.

주제어

AI 본문요약
AI-Helper

* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.

문제 정의

^[18]그러나 현실적으로 고객이 요구하는 모든 범위와 품질을 만족시키기 위해 충분한 비용과 시간이 주어지지 않기 때문에 비용, 일정, 범위와 품질 모두를 만족시킬 수 없으며, 불균형 상태가 발생한다. 계약과정에서 이들 제약사항이 어떻게 결정되는지를 살펴보자. 여기서 개발 범위는 소프트웨어가 갖추어야 할 기능 (Features 또는 Functions, Requirements, Users' Needs 등)을 의미한다.
그러나 소프트웨어 개발 프로젝트 성공 여부는 고객 관점과 개발자 관점이 동시에 요구되며, 상호 이익이 되어야만 성공하였다고 볼 수 있다. 따라서 본 장에서는 고객과 개발자 모두의 관점을 포함한 성공 척도를 제안한다.
본 장에서는 프로젝트 성공 여부를 판단할 수 있는 주된 성공 척도 (프로젝트 제약사항)들이 무엇이며, 이들 제약사항들 모두를 만족시킬 수 없는 상황을 살펴본다. 또한, 프로젝트 성공의 정의와 성공과 실패를 명확히 분류하는 기준과 관련된 연구 결과와 문제점을 살펴본다.
이 제약사항들이 계약과정에서 어떻게 확정되며 근본적으로 균형을 이룰 수 없는 불합리성을 살펴본다. 마지막으로, 소프트웨어가 성공하였는지 실패하였는지를 명확히 구분할 수 없는 현실을 살펴본다. 3장에서는 먼저, 프로젝트 성공 척도를 재 정의하여, 일반화된 프로젝트 제약사항을 결정한다.
먼저, 프로젝트의 성공을 평가하는 척도들에 대한 용어를 통일시켜 보자. 표 1에서 프로젝트 성공을 평가하는 척도들에 대해 다양한 용어로 표현되어 있다.
그러나 이들 항목 모두를 만족시킬 수는 없으며, 3개 중 2개 항목만을 선택할 수 있다는 격언이 있다. 이 제약사항들이 계약과정에서 어떻게 확정되며 근본적으로 균형을 이룰 수 없는 불합리성을 살펴본다. 마지막으로, 소프트웨어가 성공하였는지 실패하였는지를 명확히 구분할 수 없는 현실을 살펴본다.
개발 초기에 프로젝트 성공에 대한 기준을 명확히 설정하지 못하면, 프로젝트 완료 시점에서 고객과 개발자 간에 프로젝트 수행 결과가 성공인가 실패인가를 판단하는데 이견이 발생할 수 있다. 이러한 문제점을 해결하고자, 본 논문에서는 프로젝트 성공에 영향을 미치는 척도들을 살펴보고, 소프트웨어의 비가시성, 복잡성과 유연성 (변경 가능성) 특징을 반영하여 프로젝트 성공에 대한 정의를 명확히 한 후 성공과 실패를 분류하는 방법을 제시한다. 이러한 연구 결과는 고객과 개발자 쌍방 모두에 이익이 될 수 있는 전략 (Win-Win Strategy)으로 활용하여 프로젝트 성공을 명확히 판단하는 결과를 얻을 수 있을 것이다.
이러한 연구 결과를 반영하여 본 논문은 4중 제약사항을 기본으로 하고, 5번째 제약사항인 고객 만족을 Shenhar와 Renier^[35]가 제안한 쌍방 이익으로 평가하고자 한다. 쌍방 이익에 대한 구체적인 평가방법은 그림 5와 같이 일정 지연과 비용 상승에 따른 고객의 투자이익률과 개발자의 개발이익에 대한 손익분기점 (Break-even Point)으로 평가하여 프로젝트 성공 여부를 분류한다.

가설 설정

만약 위약금을 환수할 경우 고객의 손익분기점은 새로운 납품시점이 된다. 프로젝트 개발 납품지연이나 비용 상승에 따른 손실은 개발자 보다는 고객이 크게 입는다고 가정한다. 이러한 분류 기준에 따라 프로젝트 수행 결과를 분류하여 표 6에 제시하였다.

제안 방법

다음으로 프로젝트 성공에 대한 정의를 명확히 정의하였다. 마지막으로 프로젝트의 성공과 실패를 명확히 분류하는 기준을 제시하였다.
는 고객과 개발자의 쌍방 이익을 제시하고 있다. 본 장에서는 이 두 가지 이론을 결합시켜 프로젝트의 성공 척도를 정의하고 프로젝트를 분류하고자 한다.
또한, 성공과 실패를 명확히 분류할 수 있는 기준도 정의되어 있지 않다. 이러한 문제점을 해결하고자 본 논문은 먼저, 소프트웨어 프로젝트의 성공을 측정하기 위한 척도를 정의하였다. 다음으로 프로젝트 성공에 대한 정의를 명확히 정의하였다.
3장에서는 먼저, 프로젝트 성공 척도를 재 정의하여, 일반화된 프로젝트 제약사항을 결정한다. 이에 기반하여 개발 성공과 실패 기준을 재 정의하고, 마지막으로 프로젝트 수행 결과 성공과 실패로 분류할 수 있는 기준을 제안한다.

성능/효과

Standish Group은 표 3과 같이 취소, 의심과 성공에 따른 프로젝트 분류의 애매모호함을 보였다. 반면에, 제안된 이론은 프로젝트 성공 평가 척도로 품질, 기능, 일정, 비용과 더불어 쌍방 이익을 활용하여 프로젝트를 취소, 성공, 의심과 실패로 명확히 분류할 수 있었다.

후속연구

개발범위 변경에 따른 영향을 반영하여 프로젝트 제약사항들에 대해 다시 정의하여 보자. 먼저, 품질을 무시하면 주어진 시간과 비용으로 개발을 성공하기 위해 가장 먼저 시험기간을 줄이며, 이는 결국 품질에 영향을 미쳐 고객이 만족하지 못한다.^[12] 따라서 품질은 처음에 합의된 사항이 불변하여 Quality_NEW = Quality_ORG가 된다.
본 논문에서 제시하는 기준을 적용시 프로젝트 성공을 보다 명확히 정의할 수 있으며, 또한 성공과 실패를 분류하는데 따른 고객과 개발자간의 불협화음을 줄일 수 있을 것이다.
이러한 문제점을 해결하고자, 본 논문에서는 프로젝트 성공에 영향을 미치는 척도들을 살펴보고, 소프트웨어의 비가시성, 복잡성과 유연성 (변경 가능성) 특징을 반영하여 프로젝트 성공에 대한 정의를 명확히 한 후 성공과 실패를 분류하는 방법을 제시한다. 이러한 연구 결과는 고객과 개발자 쌍방 모두에 이익이 될 수 있는 전략 (Win-Win Strategy)으로 활용하여 프로젝트 성공을 명확히 판단하는 결과를 얻을 수 있을 것이다.

질의응답

핵심어	질문	논문에서 추출한 답변
	소프트웨어 개발 성공 요인인 4중 제약조건은 무슨 사항인가?	소프트웨어 개발 성공 요인인 4중 제약조건은 모두 고객 관점에서 평가되는 사항이다. 즉, 고객이 투자한 일정과 비용내에서 고객이 요구하는 기능과 품질 수준을 만족시키는 제품을 개발하느냐 여부로 결정된다.
	프로젝트 관리의 목표는?	프로젝트 관리의 목표는 프로젝트를 성공하기 위함이다. 그러나 프로젝트 수행 결과가 성공이라고 명확히 판단할 수 있는가? 또한 판단 결과에 고객과 개발자 모두 동의하는가? 성공과 실패에 대한 정의와 판단 척도들에 대해 다양하게 제시되고 있으나 명확한 분류 기준이 없다.
	프로젝트 성공 판단은 어떠한 경우 가능한가?	그러면 프로젝트 성공을 어떻게 정의할 수 있으며, 성공하였다고 판단할 수 있는 척도는 무엇인가? 또한, 프로젝트 성공과 실패를 명확히 구분하는 기준은 존재하는가? 이 모든 관심사항에 대해 많은 연구가 수행되었지만 아직까지 명확하게 정의된 결과가 없는 실정이다. 최종적으로는 이해당사자들 (Stakeholders)인 고객 (획득자)과 개발자 (공급자) 모두 만족하였을 경우 프로젝트가 성공하였다고 판단할 수 있을 것이다. 즉, 프로젝트 개발에 투입된 비용 (Cost)과 일정 (Time)으로 고객이 원하는 제품을 개발 완료하고 이를 통해 고객은 투자이익률 (ROI, Return-On-Investment)을, 개발자는 개발 이익 (Profit)을 얻을 수 있어야 한다.

참고문헌 (43)

J. Marasco, "Software Development Productivity and Project Success Rates: Are We Attacking the Right Problem?," http://www-128.ibm.com/ developerworks/rational/ library/feb06 /marasco/in dex.html, 2006.
R. B. Sheridan, "Regarding Executive Sponsorship," Menlo Institute, 2005.
G. P. Kessler, "Why Technical Projects fail: Avoiding Disaster," Project Management, Vol. 1, No. 2, Elementk Journals, 2001.
R. M. Wideman, "Progressive Acquisition and the RUP Part II: Contracts That Work," The Rational Edge E-zine on-line magazine, 2003, http://www.maxwideman.com/papers/ acquisition/overview.htm
Standish group, "The CHAOS Report," http://www.standishgroup.com/sample/PDFpages/chaos1994.pdf, 1994.
R. Frese and V. Sauter, "Project Success and Failure: What is Success, What is Failure, and How Can You Improve Your Odds for Success?," http://www.umsl.edu/-sauter/analy sis/6840_f03_papers/frese/, 2003.
J. Johnson, K. D., Boucher, K. Connors, and J. Robinson, "Collaboration: Development & Manage ment: Collaborating on Project Success," http://www.SOFT WAREMAG.COM/ ARCHIVE/2001FEB/Collaborativemgt.html, Software Magazine and Wiesner Publishing, 2001.
K. R. Linberg, "Software developer perceptions about software project failure: a case study," The Journal of Systems and Software, Elsevier, www.lelsevier.com/locate/ jss, 1999.
Welcom, "PM Glossary, Project Management Solutions, Internet," Deltek Systems Inc, 1998.
R. Atkinson, "Project management: cost, time and quality, tow best guesses and a phenomenon, its time to accept other success criteria," International Journal of Project Management, Elsevier Science Ltd and IPMA, vol17, No 6, pp 337-342, 1999.

상세보기
J. Marasco, "The Project Pyramid," http://www-128.ibm.com/developerworks/rational/library/4291.html, 2004.
S. Keogh, "What is Success and Failures in Computing," http://computin g.unn.ac.uk/staff/cglh1/balck hole of lost resource s.doc, School of Informatics, 2001.
D. Fenny, "Managing Large Information Techno logy Projects in the Public Sector," OECD Meeting, 2000.
K. Dugardyn, "Develop High Quality e-business Applications - Test Smarter, Finish Faster," QWE, 2002.
S. K. Baker, "On Time/On Budget," Prentice Hall, Englewood Cliffs, NJ, 1992.
M. J. Hillelsohn, "Been There, Done That: Some Lessons Learned on Software Development Contracts," Software Management, 5th ed., IEEE Computer Society, 1997.
D. F. Redmiles, "UC IRVINE - ICS 121 Software Tools and Methods," Department of Information and Computer Science, University of California, http://www.ics.uci.edu/ -redm iles/ics121-FQ99/lecture/one/sld001.htm, 1999.
E. Burris, 'Project Management," School of Interdisplinary Computing and Engineering, Univer sity of Missouri, 1984.
J. Marasco, "The Project Pyramid," The Rational Edge E-zine on-line magazine, http://www-128.ibm.com/ developerw orks/ration al/library/4291.html, 2004.
R. M. Wideman, "Progressive Acquisition and the RUP Part I: Defining the Problem and Common Terminology," The Rational Edge E-zine on-line magazine, http://www. maxwideman.com/pap ers/acquisition/intro.htm, 2002.
K. E. Wiegers, "Creating a Software Engineering Culture." Dorset House Publishing, 1996.
M. B. Patel and P. M. G. Morris, "Centre for Research in the Management of Projects (CRMP)," University of Manchester, UK, 1999.
Project Management (UK), "A Bridged Glossary of Project Management Terms," APMP Syllabus, 2nd Edition, 2000.
British Standard Institute (BSI), "BS6079: Standard Guide to Project Management, 1996.
R. M. Wideman, "Cost Control of Capital Projects," BiTech Publishers Ltd, Richmond, BC, Canada, 1995.
Private BC Corporation, "Project Management Guidelines," 1995.
PMI, "Project Management Body of Knowledge Glossary of Terms," Project Management Institute, 1987.
D. M. Cartwright, "Success and Failure in IT Projects," School of Design, Engineering & Computing Business Information Technology, Bournemouth University, 2004.
B. Baker, "Great Expectations: Turning Failure into Success - and Visa Versa," PM Network, pp. 25 - 28, 1997.
Standish group, "CHAOS: A Recipe for Success," http://www.standishgroup.com/sample/PDFpages/chaos1999.pdf, 1999.
Standish group, "Extreme CHAOS," http://www.sta ndishgroup. com/sample/PDFpa ges/extreme_chaos.pdf, 2001.
Standish group, "CHAOS Demographics and Project Resolution," http://www.standishgrou p.com/sample/PDFpages/ q3_spo tlight.pdf, 2004.
R. Frese and V. Sauter, 'Project Success and Failure: What is Success, What is Failure, and How can You Improve Your Odds for Success?," http://www.umsl.edu/ -sauter/a nalysis/6840_f03_papers/frese/, 2003.
B. Lewis, "The 70-Percent Failure," Infoworld. http:// archive.infowor ld.com/articles/op/xml /01/10/29/011029/opservival.html, 2003.
A. J. Shenhar and J. J. Renier, "Improving PM: Linking Success Criteria to Project Type," Southern Alberta Chapter, Project Management Institute, Symposium "Creating Canadian Advantage Through Project Management", Calgary, 1996.
D. Leffingwell, "Features, Use cases, Requirements, Oh My!," The Rational E-zine, 2000.
M. R. Hulme, "Procurement Reform and MIS Project Success", Journal of Supply Chain Management, Winter 1997; 33, 1; pg 2., 1997.
S. Gurlen, "Scope Creep," IS 6840-Information Systems Analysis Section G01 Syllabus, University of Missouri, http://www.ums l.edu/-sauter/a nalysis/6840_f03_papers/gurlen/, 2003.
Mangione, "Software Project Failure: The Reasons, The Costs," http://w ww.cioupdate.co m/reports/article.php/ 1563701, Jupitermedia Corporation, 2003.
Projectnet, "What is Project Management?," Project Management Today, 2005.
Sang-Won Kang, Pyung-Hyung Park, Hae-Sool Ynag "Security Quality Measurement Model of M-Commerce software" Proceedings of the KAIS Fall Conference, pp.789-792, 2009
Suk-Hee Kim1, Jong-Hun Kim "The Development of an easy a simple of Parameter Estimation Method for Reliability Evaluation of Application Software System"Journal of the Korea Academia-Industrial Cooperation Society, v.11, no.2, pp.540-549, 2010

원문보기 상세보기
Dae-Soung Kim, Hee-Cheul Kim2 "The Study of Software Reliability Model from the Perspective of Learning Effects for Burr Distribution" Journal of the Korea Academia-Industrial Cooperation Society, v.12, no.10, pp.4543-4549, 2011

원문보기 상세보기

저자의 다른 논문 :

표제어: PCR

동의어: Packet Collision Rate

용어 설명 출처 목록 (6)

용어 설명: PCR은 세균 특이성이 있는 primer를 이용하여 적은 수의 세균이 있을지라도 쉽게 검출할 수 있는 유용한 방법이며, 이를 이용하여 구강 내 치면세균막이나 타액에서 직접 세균을 검출할 수 있게 되었다[8].

내보내기 구분	파일저장 인쇄 메일전송
구성항목	기본정보 상세정보 관리번호, 논문명, 저널/프로시딩명, 저자 , 발행년, 권, 호, 시작페이지, 끝페이지, 발행기관 관리번호, 논문명, 대등논문명, 저자 , 저널/프로시딩명, 발행기관, 발행년, 발행언어, 권, 호, 시작페이지, 끝페이지, ISBN, ISSN, 주제분야, 키워드, 초록(한글), 초록(영문), 저자(소속기관)
저장형식	Text(ASCII format) Excel format RefWorks Direct Export RIS format (for Reference Manager, ProCite, EndNote), Scholar's Aids, Mendeley
메일정보	받는사람 (필수) @ 보내는사람 (선택) @ 제목 내용 KISTI 검색결과 이메일 서비스
안내	총 건의 자료가 검색되었습니다. 다운받으실 자료의 인덱스를 입력하세요. (1-10,000) 검색결과의 순서대로 최대 10,000건 까지 다운로드가 가능합니다. 데이타가 많을 경우 속도가 느려질 수 있습니다.(최대 2~3분 소요) 다운로드 파일은 UTF-8 형태로 저장됩니다. 파일의 내용이 제대로 보이지 않을실 때는 웹브라우저 상단의 보기 -> 인코딩 -> 자동선택 여부를 확인하십시오. ~ Text(ASCII format) Excel format

연합인증