Microsoft Word - Glossary_ver1.1_ _

Transcription

1 1 Glossary Version Fork

2 2 개정번호개정일자개정자개정사유개정내용승인일자비고 서오석신규제정문서의초안생성

3 지침서용어원문용어설명출처 3

4 작업산출물이나프로세스가명세서나 감사 audit 표준, 계약상의동의사항과일치되는지를 ISO 평가하기위해독립적으로시행되는 검사활동 개발주기비용 서브모델 life-cycle cost submodel 소프트웨어의유지보수단계에서초기에신속하게비용을예측하는데사용되는서브모델이다. 이모델은개발비용과설계변수를제공하는획득서브모델과함께사용된다. Abdel-Hamid, T., Lessons Learned from Modeling the Dynamics of Software Development, Abdel-Hamid, T., Communications of the ACM, December 개체 entity 데이터특성과이특성에대하여 수행되어야하는작업목록이수집될수 있는클래스의특정인스턴스. 검증 verification 해당프로덕트가해당단계의특정 IEEE Std 1012, "IEEE Standard 요구사항을만족하는지확인하는작업. for Software Verification and 올바른프로덕트를구현했는가 ("you built Validation, March", 1998 thing rightly") 를검증 소프트웨어개발기간동안다양한 Roger S. Pressman, Software 검토 Review 시점에서적용되며, 오류와결함을 Engineering: A Practitioner's 발견하는활동 Approach, 5th Edition 안전에관한것을포함하여의도된 결함 defect 요구사항이나기대사항에대한 IEEE Std 불충족하는것 ISO/IEC 14598, "Information 결함 Fault 컴퓨터프로그램내부의부정확한절차, 프로세스혹은데이터정의 Technology - Software product evaluation - Part 1, 2, 3, 4, 5, 6. 결함밀도 defect density 프로덕트사이즈 (1000 라인 ) 당결함개수 CMMI 고객 customer 제품이만든출력을요청하고, 지불하고, 명시하고, 사용하는프로덕트관련자들 조직의표준프로세스를 개조 (tailoring) 하여프로젝트에적합한 고급프로젝트 프로세스를만들어프로젝트를관리하는 관리영역 활동과관련당사자와의상호조정과 협업, 위험관리, 통합팀구성, 정량적인 프로젝트관리활동을포함하고있다.

5 필요한기능을수행하는어떤요소의 고장 Failure 기능종료혹은미리지정된제한시간 CMU_SEI-1996-HB-001 내에서의수행불능을말한다. 공약 commitment 문서화되고공개적으로발표된약속 5 공유비전 Shared vision 공유비전수립은미래에대한방향을새로정립하는것이다. 공유비전을통해구성원들은조직의미래상을분명히깨달으면서전략적우선순위를가늠하게된다. 공유비전은구성원과 Block, P. The Empowered 고객, 주주등이해당사자들에게새로운 Manager. Positive Political 행동양식과실행이필요함을일깨워 Skills at Work. SanFrancisco: 주고매일매일벌어지는의사결정 Jossey-Bass Inc., 과정에지침이된다. 공유비전은보통가치제시와차별화된역량, 고객등이해당사자, 조직구성원칙, 성과목표등 5 가지구성요소의결합으로만들어진다. 조직의표준프로세스에기초하여 공통측정항목 Common Measure 선택된측정항목의집합. 표준프로세스를수행하면서조직에서 CMMI 공통적으로특정해야하는항목. 관련자 Stakeholder 프로젝트결과의영향을받거나결과에영향을미칠수있는조직또는사람과그룹 SPI 프로그램을조직의비전및미션과 ISO/IEC 14598, "Information 관리조정 MSG(Management 연결하고스폰서쉽을소개하고, 자원을 Technology - Software 위원회 Steering Group) 할당하며, 진적도를모니터링하고 product evaluation - Part 1, 2, 가이드라인과시정을제시해주는그룹 3, 4, 5, 6. 관리검토 소프트웨어프로젝트의상태와진척상황, management review 문제점, 위험요소등을정기적으로 IEEE Std 모니터링하기위한체계적인평가활동 관리되는 프로세스 Managed process 관리되는프로세스는 수행되는프로세스 로서, (1) 회사정책에따라계획및실행되고, (2) 숙련된인력을고용하고 CMMI : Guidelines for Process 적절한자원을사용하여제어된 Integration and Product 산출물을만들고, (3) 적절한이해당사자가 Improvement 참여하고, (4) 감시, 제어및검토되며, (5) 프로세스에정의된바를준수하였는지

6 평가되는프로세스이다. 여기서, 수행되는프로세스 는작업산출물을 만드는데필요한작업을달성하는 프로세스를말한다. 구매자 Acquirer 소프트웨어공급자로부터시스템, 소프트웨어제품, 또는소프트웨어서비스를구매혹은조달하는조직을말한다. ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics 6 사회자나진행자가의사결정을하려는 집단을통제하고지시하는브레인스토밍 구조적브레인스토밍 기법을말한다. 대부분의구조적정철현, 행정의사결정론, 브레인스토밍의경우, 사회자나진행자가다산출판사, 2001 참여자에게정해진순서대로아이디어를 제시할것을요구하고참여자는모두 자기차례에아이디어를제시한다. 구조화된의사결정 이미설정된대안을기준으로일상적이며반복적으로이루어지는의사결정 정철현, 행정의사결정론, 다산출판사, 2001 IPPD 환경에서책임과권한의명확한 수립이특별히중요하다. 프로젝트와 조직내에서, 개인또는통합팀이너무 권한부여가이드라인 많은혹은너무적은권한을가지고있거나의사결정방법이모호한경우 CMMI 이슈가발생할수있다. 권한의정도를 결정하는가이드라인이그러한이슈를 예방할수있다. IPPD 환경에서통합팀이성공적으로 목표를달성하기위해서는권한이 위임되어야한다. 권한위임은팀레벨, 팀원레벨에서모두이루어져야한다. 권한위임 Empowerment 권한위임된팀은팀의업무를수행하고관리하는데상당한자율성을 부여받게된다. 팀은비즈니스목적의 달성과조직내부지침들을수행하는데 필요한방법을결정할수있는권한을 가진다. 팀이란팀의업무를수행하고관리하는 권한이위임된팀 Empowered Team 데상당한자율성이부여된팀을말한다. 팀은비즈니스목적의달성과조직내부지침들의수행에대한방법을결정할수 있는권한을가진다. 통합팀이

7 효율적으로할당된업무를수행하기 위해서는권한을가진팀이되어야한다. 기능요구사항 functional requirements 특정조건하에서시스템이보일기능의일부또는동작의일부에대한설명 7 기능성 Functionality 소프트웨어가특정조건에서사용될때, 명시된요구와내재된요구를만족하는기능을제공하는소프트웨어제품의능력 ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics 기능점수기본프로젝트관리영역기술검토 Function point technical review 기능점수는 1979 년 IBM 의 A. J. Albrecht 가소프트웨어의생산성을측정하기위하여개발한기법이다. Barry Boehm, Bradford Clark, 기능점수는소프트웨어시스템이갖는 Ellis Horowitz and Chris 기능을정량화한것으로, 원시코드가 Westland, Cost models for 작성되지않은상태에서는정확한라인 future software life cycle 수의측정이불가능하므로, 일반적인 processes: COCOMO 2.0, 소프트웨어가갖는기능의수로 Software Engineering Project 소프트웨어의규모와복잡도를나타내고, Management, 2nd ed., R.H. 이것을시스템개발에필요한기간과 Thayer, ed., IEEE Computer 소요인력산정의기준으로삼는 Society Press, Los Alamitos, 방법이다. Calif., 1997 기능점수분석은소프트웨어개발과유지보수프로젝트계획을수립하고공약을획득하며진도를관리하고공급계약을관리하는것과같은기본적인활동들을다룬다. 이들은프로젝트계획을수립하고관련당사자들을적절하게참여시키며계획에대한공약을획득하는과정을포함한다. 프로젝트계획은산출물에대한요구사항으로부터도출되며이와함께다양한프로젝트관리활동을수반한다. 관리를위해서측정활동을포함하고있으며형상관리계획등기타관련계획들을관련당사자들과함께검토하며함께공약사작업산출물이주어진명세서와일치하는지, 계획, 표준, 가이드라인을 NASA-STD-A201 준수하는지평가하는공식적인활동

8 Mary Beth Chrissis, Mike 제품과제품구성요소의형태에적합한 Konrad, Sandy Shrum, CMMI : 기술적데이터 technical data 제품아키텍처기술서, 제품특성, Guidelines for Process 패키지 package 인터페이스요구사항등을포함하는 Integration and Product 수집항목 Improvement, Addison-Wesley, 기술적요구사항 technical requirements 달성되거나부가되어야하는제품또는서비스의특성 속성 지정된측정방법으로한개의속성을 기초측정변수 Base Measure 측정하는것을말한다. 예를들어, 소프트웨어규모를측정하려고할때, 코드라인수를세는것이 Practical Software Measurement 기초측정변수에해당된다. 마일스톤차트 milestone chart 메트릭 metrics 명세요구사항 requirements specification 마일스톤이란프로젝트진행에서중요한의미가있는사건또는시점을의미한다. 프로젝트착수일, 주요산출물완료일 Richard H. Thayer, Edward 등이마일스톤이될수있는데, 마일스톤 Yourdon, Software Engineering 자체는수행기간이영 (0) 이라는점에서 Project Management, IEEE 태스크와구분된다. 마일스톤의차트의 Computer Society, 2000 장점은규모가큰프로젝트의전체적인현황을파악하기쉽다는점이다. 제품이가진특징, 품질, 특성, 속성을나타내는범위나등급을정량적으로 NASA-STD-A201 측정구조적이고공유가능하며관리가능한형식으로시스템의요구사항을문서로 만드는프로세스. 또한이프로세스에서 나오는산출물도포함. 독창적인특징을알기쉽게나타내기 위해실제를재현하고단순하게 모델링 modeling 축소하여보여주는모형을만드는과정이다. 해결하려는문제에따라많은모델링이이루어질수있고같은 정철현, 행정의사결정론, 다산출판사, 2001 문제라도누가작성하느냐에따라 판이하게다른모델링이만들어진다. 바차트 bar chart 바차트는간트차트 (Gantt chart) 라고도하는데, 일반적으로가장많이사용되는 Richard H. Thayer, Edward 일정형식이다. 바차트의특징은태스크 Yourdon, Software Engineering 하나하나의수행기간이시각적으로 Project Management, IEEE 표현되어파악하기쉽다는점이다. 또한 Computer Society, 2000 바차트는프로젝트의진행상황을

9 효과적으로나타낼수있기때문에 이해당사자에게프로젝트진행상황을 보고하는목적으로유용하게사용된다. 범위 scope 현재의프로덕트가해결할최종제품의 비전부분. 범위는프로젝트의안과밖의 경계를정의한다. 9 범위확장 scope creep 개발프로세스전체에서프로젝트의범위가통제되지않으며계속증가하는상황 변경관리 change control (=change management) 제품또는서비스의변경을효과적으로관리하기위한방법 CMMI 변경관리위원회 소프트웨어요구사항에서제안된변경을승인하거나거부하는의사결정을할수있는사람들의그룹 수행된업무에대해조직구성원에게 제공되는모든종류의보수를가리킨다. 주로임금과보장된이익을포함한다. 보상 Compensation IPPD 수행을지원하기위해서는팀기반보상시스템을구축해야한다. 개인에게 People CMM 제공할보상의정도를결정하기 위해서는개인의성과뿐만아니라팀 성과를고려해야한다. 조직의구성원들에게보상을하기위한 조직의이념과방법을포함한다. 조직의 보상전략은일반적으로아래사항들을 포함한다. - 보상전략에서결정된전략적판단에 대한근본적, 합리적이유 보상전략 Compensation Strategy - 보상을제공하는수단들과이러한수단들이사용되는방법 - 보상이이루어지는주기에대한정의 People CMM - 보상을결정하고조정하는기준 - 직책성격에따른보상을결정하는 기준과보상수단을사용하기위한 가이드라인 - 개인, 직책, 팀, 유닛을위한보상 결정이

10 보상활동 계획 부서 부적합사항 분석모델 Compensation Plan Home Organization noncompliance issue Analysis Model 분석요구사항 analysis requirements 보상전략을실행에옮기기위해필요한보상활동들을관리할수있도록정기적으로준비된계획. 보상계획은일반적으로다음을포함한다. - 보상결정을가이드하고보상전략을관리하기위해필요한재정데이터 People CMM - 보상전략관리에참여하는사람들을위한이벤트와책임의일정 - 보상전략에기술된방법들을보상결정시에사용하는방법 - 보상결정이검토되는시기와방법통합팀의팀원들이통합팀에속하지않을때속해있는조직내의단위를 People CMM 말한다. 명세된표준, 절차, 계획, 요구사항, Pressman 디자인과의편차두개이상의기초측정변수나기초및유도측정변수와관련된계산방법이나알고리즘이다. 예를들어, 프로젝트 진행경과인디케이터는다음과같은 ISO/IEC 9126, "Information 함수를이용하여구했다. Technology - Software Quality 진행경과인디케이터 = 실제프로젝트 Characteristics and metrics 진행경과 - 예상된프로젝트진행경과여기서분석모델은두값의차로나타내고있다. 분석모델의다른예로평균과표준편차를들수있다. 요구사항정보를다양한카테고리로분류하고, 바람직한품질에대해요구사항을평가하고, 다양한형식으로 요구사항을표현하고, 고차원의 요구사항에서상세한요구사항을추출하고, 우선순위를협의하는프로세스 10 불확실성 하에서의 의사결정 의사결정을위한여건의예측이 불가능하거나예측이가능한경우라도 신뢰도가낮은경우를말한다. 정철현, 행정의사결정론, 다산출판사, 2001 브레인스토밍 Brainstorming 일정한테마에관하여회의형식을채택하고, 구성원의자유발언을통한 Scholtes, P. et al. The Team 아이디어의제시를요구하여발상을 Handbook. Madison, Wisc.: 찾아내려는방법. 원리는, Joiner Associates, Inc., 한사람보다다수인쪽이제기되는아이디어가많다.

11 2 아이디어수가많을수록질적으로우수한아이디어가나올가능성이많다. 3 일반적으로아이디어는비판이가해지지않으면많아진다. 등의원칙에서구할수있다. 11 비구조적 브레인스토밍 비구조화된 의사결정 비기능 nonfunctional 요구사항 requirements 비기술적 nontechnical 요구사항 requirements 비전 vision 비전과범위 vision and scope 문서 document 비즈니스규칙 business rule 비즈니스 business 요구사항 requirements 사회자나진행자가없고참여자가형식없이자유롭게이야기하는브레인스토밍기법을말한다. 구성원은차례에상관없이언제든지아이디어를내놓을수있다. 사전에알려진대안이없는경우에이루어지는의사결정소프트웨어시스템이보여주어야하는품질속성이나특징에대한설명, 또는시스템이관측가능한시스템동작이외에따라야하는제약조건에대한설명산출물이나용역이수용되는데영향을끼치는계약조항, 이행방침, 조건, 약정. 그실례로양도되는산출물, 양도된상용품새시스템의최종목적과형태에대한장기적인전략적개념새시스템에대한비즈니스요구사항을제시하는문서로, 제품비전선언과프로젝트범위설명을포함하낟. 비즈니스의일부영역을정의하거나제한하는정책, 가이드라인, 표준또는규제제품을구축하는조직또는제품을구매하는고객의추상적인비즈니스목표 정철현, 행정의사결정론, 다산출판사, 2001 정철현, 행정의사결정론, 다산출판사, 2001 COTS 사용품질 Quality in use 사용자관점의품질을말하며효율성, 생산성, 안전성그리고만족도등네가지특성을갖는다. 사용품질의달성은 ISO/IEC 9126, "Information 관련된소프트웨어제품의품질 Technology - Software Quality 부특성에대한외부측정의기준치도달 Characteristics and metrics 여부에달려있으며, 외부측정은다시관련된내부측정의연관기준치도달여부에달려있다.

12 사용성 Usability 명시된조건에서사용될경우, 사용자에의해이해되고학습되고사용되고선호될수있는소프트웨어제품의능력 ISO/IEC 12119, "Information Technology - Software Package - Quality requirement and testing" 시스템과직접또는간접적으로 12 사용자 user 상호작용할고객 ( 예를들면, 시스템의출력물을사용하지만이출력물을개인적으로만들지않는다 ). 일반 사용자라고도부른다. 시스템에대해비슷한특징과 사용자계층 user class 요구사항을가지고있는시스템사용자그룹, 사용자계층구성원은시스템과상호작용할경우에는동작자역할을 한다. 사용자문서사용자요구사항사이즈서브모델사전조건사후조건산정 인쇄나비인쇄형태로이용가능한모든 ISO/IEC 14598, "Information 문서로제품의사용을위해제공되는 Technology - Software User Documentation 제품의필수부분을말한다. 예를들어, product evaluation - Part 1, 2, 책자형태의사용자매뉴얼이나파일 3, 4, 5, 6. 형태의온라인매뉴얼등을말한다. 사용자가시스템을사용해서수행할수 user requirements Sizing submodel precondition postcondition Estimation 있어야하는사용자목표또는작업 또는시스템의품질에대한사용자 기대에대한설명소프트에어크기산정을돕는서브모델이다. 크기단위는 Abdel-Hamid, T., Lessons 소스코드라인 (source line of code), Learned from Modeling the 기능점수, 객체점수 (object point) 가될수 Dynamics of Software 있다. 객체점수는객체지향개발 Development, Abdel-Hamid, 프로젝트에서크기를산정하는새로운 T., Communications of the 기법으로 [Minkiewicz 98] 에서 ACM, December 소개되었다. 유스케이스가시작된기전에시스템이 있어야하거나충족되어야하는조건 유스케이스가성공적으로완료된후에 시스템의상태를설명하는조건 프로젝트계획수립시에프로젝트와관련된예측을하는것을말한다. 산정이 Practical Software 필요한주요대상은프로젝트의규모, Measurement 공수, 스케줄, 품질등이다.

13 조직의프로세스개선효과에서자원의할당에직접적인권한을가지고있으며, 충분히상위관리자 Senior Management 높은관리역할을수행한다. 이역할은장기적으로지속된다. 제품구성요소들이서로통합되어 상호운용성 Compatibility 목표된기능을제공할수있는품질 특성 소프트웨어제품의개발, 운영, 유지보수에포함되는프로세스와 생명주기모델 Life Cycle Model 활동들을담고있는프레임워크. 요구사항정의에서사용이종결될때 까지의기간을포함. 생명주기비용이란시스템의생명주기 생명주기비용 life-cycle cost 혹은프로젝트의생명주기전반에걸쳐 투입되는비용을의미한다. 성과분석 소프트웨어 Software 개발생명 development life 주기 cycle software 소프트웨어 requirements 요구사항명세 specification 소프트웨어제품 Software Product 소프트웨어품질 software quality 소프트웨어프로세스 software process 프로젝트가계획과목표를잘이행하고있는지를평가하는것을말한다. 소프트웨어개발생명주기는소프트웨어가계획, 요구사항분석, 시스템및프로그램의설계, 코딩, 시험, 구현및평가과정을거쳐서완성된후유지보수를통해서활동하다가폐기되는과정을말한다. 소프트웨어제품의기능과비기능요구사항의집합을체계적으로문서화한것. 컴퓨터프로그램, 절차또는관련문서및데이터의집합기능, 성능및개발표준들에관련된요구사항을충족시키는것소프트웨어나프로덕트를개발하고유지하기위해사람들이사용하는 Mary Beth Chrissis et Al., CMM : Guidelines for Process Integration and Product Improvement Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003 IEEE-EIA A Guide to the Project Management Body of Knowledge, Project Management Institute, 2000 Alan M. Davis, Software Life Cycle Models, Software Engineering Project Management, 2nd ed., R.H. Thayer, ed., IEEE Computer Society Press ISO/IEC 14598, "Information Technology - Software product evaluation - Part 1, 2, 3, 4, 5, 6. IEEE Std "Software Process Framework in CMM, CMM-SPF" 13

14 활동이나, 방법등의조합 프로세스모델링을위한표준메타모델로 OMG 에서 2001 년에개발한것으로소프트웨어개발프로세스와소프트웨어 Software Process 그에관련된사항들을정의하기위한프로세스공학 Engineering 메타모델이다. SPEM 은 UML 메타모델을메타모델 Metamodel: SPEM 기반으로하고있어 UML 을이용하여프로세스를모델링할수있도록지원한다. 아키텍처의모든계층을포함하여소프트웨어시스템을종으로부분수직적구현하는프로토타입, 기술타당성과 vertical prototype 프로토타입성능을평가하는데사용된다. 구조적 프로토타입또는개념검증이라고도부른다. 소프트웨어시스템의사용자인터페이스의일부분또는가능한구현. 수평적유용성을평가하고요구사항의완벽도와 horizontal prototype 프로토타입정확도를측정하는데사용된다. 또한 동작프로토타입또는모크업이라고도불린다. 시스템이있을수있는다양한상태스테이트또는시스템의개체가가질수있는 state transition 트랜지션상태와상태간에발생될수있는 diagram 다이어그램허용된변이를보여주는분석모델로스테이트차트다이어그램과비슷하다. 발생되는특정이벤트에대해시스템의스테이트차트개체가거치는상태의순서또는시스템 statechart diagram 다이어그램전체의가능한상태를보여주는분석 모델스폰서는프로젝트에대해서최종적으로책임이있는사람으로써통합팀의 CMMI : Guidelines for Process 스폰서 Sponsor 스폰서는통합팀에게업무를부여하거나 Integration and Product 자원을제공하는개인또는단체를 Improvement 말한다컴퓨터응용프로그램의하나로숫자나문자데이터가가로세로로펼쳐져있는전산용어사전편찬위원회, 스프레드시트 spread sheet 표를입력하고이것을조작하고다루어컴퓨터인터넷?IT 용어대사전, 데이터처리를할수있게된일진사, 2005 프로그램을말한다. 14

15 승인기준 acceptance criteria 소프트웨어제품이사용자, 고객또는다른관련자들에게수용되려면충족시켜야하는조건 실제와똑같은상황을만들어그결과를 실제경험할수있게해주는것이다. 소프트웨어개선센터, 15 시뮬레이션 simulation 시뮬레이션을사용하면어려운 요구사항관리 (RM) 지침서, 통계분석을사용하는것보다사람들을 한국과학기술원 (KAIST), 2004 이해시키기쉽다는장점을갖는다. 시스템 System 명시된요구나목적을충족시키는능력을제공하는하나이상의프로세스, 하드웨어, 소프트웨어, 장비및사람으로구성되는결합체 ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics 시스템요구사항 system requirements 여러가지하위시스템을포함하고잇는최고수준의요구사항으로소프트웨어와하드웨어등모든것을포함할수있다. 시스템이요구사항에맞게잘구현 시스템테스트 system test 되었는지통합된완전한시스템을 SW-TMM 대상으로수행되는테스트 존재하는부적합사항, 결함, 다른 시정조치 Corrective anction 기대되지않은상황의원인을재발을 ISO 막기위해취해지는행동 시퀀스다이어그램 sequence diagram 시스템에서한활동을완료하기위해개체또는컴포넌트간에메시지가통과하는순서를보여주는분석모델 신뢰성 Reliability 명세된조건에서사용될때성능수준을유지할수있는소프트웨어제품의능력 ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics 프로세스의강점과약점을결정하기 심사 Appraisal 위한심사참조모델을사용하여훈련된전문가가하나이상의프로세스를 CMMI 시험하는활동 아키텍처 액티비티 다이어그램 architecture activity diagram 시스템을구성하는소프트웨어와하드웨어컨포넌트, 이컨포넌트간의인터페이스와관계, 다른컴포넌트에 공개되는컴포넌트동작등 소프트웨어를가지고있는시스템의구조한활동에서다른활동으로의흐름으로 묘사해서동적인시스템동작을 보여주는모델로플로우차트와비슷하다.

16 엔터티 릴레이션 다이어그램 entity relation diagram 한쌍의엔티티간의논리적인관계를파악해주는분석모델 예외 exception 각에러상황에대하여테스트케이스를선정하여테스트하는기법 IEEE Std 1012, "IEEE Standard for Software Verification and Validation, March", 실행가능한소프트웨어나시스템을 시험, 운영또는관찰해봄으로써그 외부메트릭 External Metrics 소프트웨어가한부분을이루고있는시스템형태에대한측정에서추출되는소프트웨어제품측정척도이다. 외부메트릭은사용자, 평가자, 시험자및개발자가시험수행이나운영중에 ISO/IEC 14598, "Information Technology - Software product evaluation - Part 1, 2, 3, 4, 5, 6. 소프트웨어제품품질을평가할수 있도록도와준다. 외부 인터페이스 요구사항 external interface requirements 소프트웨어시스템과사용자, 또다른소프트웨어시스템, 또는하드웨어장비간의인터페이스를설명 해당제품을일부분으로하는시스템의 ISO/IEC 9126, "Information 외부측정 External Measure 행위를측정함으로써유추되는제품의 Technology - Software Quality 간접측정을말한다. Characteristics and metrics 외주 supplier 획득해야하는제품을공급하거나서비스를수행하는엔티티 고객요구나목표또는제품이이런 요구사항 requirement 요구나목표를충족시키기위해가져야하는조건또는능력에대한설명. 제품이관련자에게가치를제공하기 위해가지고있어야하는속성 프로덕트의범위를정의하고, 사용자 계층과사용자대표를파악하고, 요구사항개발 requirements developement 요구사항을유도하고분석하고명시하고검증하는프로세스, 요구사항개발의 산출물은구축될제품을정의하는 요구사항기본내용이다. 제품에서필요한기능과특성을 이해하는것과관련된모든프로젝트 요구사항공학 requirements engineering 라이프사이클을포함하는여역으로요구사항개발과요구사항관리가 포함된다. 시스템공학과소프트웨어 공학의하위원칙이다.

17 요구사항관리 requirement management 요구사항 분석가 requirements analyst 요구사항속성 requirements attribute 요구사항추적 메트릭스 requirements traceability matrix 요구사항할당 requirements allocation 제품개발프로세스와제품의운영기간동안정의된제품요구사항의집합에대한작업을하는프로세스. 요구사항 상태추적, 요구사항변경과요구사항 명세버전의관리, 다른프로젝트단계와산출물로의요구사항추적등이포함된다. 관련자대표와협력해서프로젝트의요구사항을유도하고분석하고명시하고검증하고관리하는리드책임을가지고 있는프로젝트팀의역할, 비즈니스 분석가, 시스템분석가, 요구사항엔지니어, 분석가라고도부른다. 의도한기능에대한설명이상의정의를보완하는요구사항에대한설명식정보. 발생원, 논리, 우선순위, 담당자, 버전 번호등이있다. 각각의기능요구사항과다른시스템산출물간의논리적인연결을보여주는 표로다른기능요구사항, 유스케이스, 아키텍처와설계요소, 코드모듈, 테스트사례와비즈니스규칙을포함한다. 고객요구사항이나제품요구사항을다양한아키텍처하위시스템과 컴포넌트또는또다른개발산출물에 분할하는프로세스. 17 생산품간의상호관계뿐만아니라 Mary Beth Chrissis, Mike 생산품과그환경, 사용자와간의 Konrad, Sandy Shrum, CMMI : 상호관계를포함한일련의예상절차에 Guidelines for Process 운영시나리오 operational scenario 대한기술로써운영시나리오는 Integration and Product 시스템의분석과설계를평가하거나 Improvement, Addison-Wesley, 시스템의타당성을증명하는데사용된다 Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : 어떤객체가사용되거나운영되는 Guidelines for Process 운영개념 operational concept 방법에대한일반적인기술 Integration and Product Improvement, Addison-Wesley, 2003 디자이너나개발자가개발팀과다른 워크스루 walkthrough 관심있는사람들을이끌며진행하는 IEEE Std 작업산출물에대한정적인분석방법

18 Mary Beth Chrissis, Mike 웨이버증서 Waiver Paper 제품통합을위해인도받은제품구성요소가통합이불가능할경우해당제품에대한방출을표기하는문서 Konrad, Sandy Shrum, CMMI : Guidelines for Process Integration and Product Improvement, Addison-Wesley, 발생가능성이있지만현재까지 David Gluch, A Construct for 위험 Risk 발생하지않은비정상적인이벤트나 Describing Software 실패 Development Risks Richard H. Thayer, Richard E. Fairley, Software Risk 더낮은위험을가지는해결방법을 Management, Software 위험회피 risk avoidance 선택함으로써소프트웨어개발에대한높은위험을가지는해결방법을 Engineering Project Management, 2nd ed., R.H. 회피하는것 Thayer, ed., IEEE Computer Society Press, Los Alamitos, Calif., 1997 인터뷰, 워크샵, 워크플로우와작업분석, 유도, 요구사항 elicitation, requirements 문서분석과다른메커니즘을통해다양한소스로부터소프트웨어또는 시스템요구사항을파악하는프로세스 유도측정변수 Derived Measure 두개이상의기초측정변수의조합이나기초및유도측정변수의조합으로이루어진함수로정의된다. Practical Software Measurement 동작자에게가치를제공하는결과를 유스케이스 use case 가져오는동작자와시스템간의논리적으로연결된상호작용들에대한 설명. 여러시나리오를포함할수있다. 가치있는목표를달성하기위해 유스케이스다이어그램 use case diagram 시스템과상호작용할수있는동작자와각각의동작자가수행할다양한 유스케이스를파악하는분석모델 컴퓨터또는단말기와사용자가대화를 하기위한접촉으로이접촉에는 키보드나마우스, 디스플레이등의 유저인터페이스 user interface 입출력을통해서하는소프트웨어적접촉과디스플레이의모양, 키보드의배열, 의자의높이등인간공학적인 전산용어사전편찬위원회, 컴퓨터인터넷?IT 용어대사전, 일진사, 2005 물리적접촉이있는데일반적으로는 소프트웨어적인접촉을말하는경우가 많다. 아무리기능이좋은시스템이나

19 소프트웨어도유저인터페이스가나쁘면 사용하기불편하고상품가치가월등히 떨어진다. 유지보수성 Maintainability 소프트웨어제품이변경되는능력. 변경에는환경과요구사항및기능적명세에따른소프트웨어의수정, 개선, 혹은개작등이포함된다. ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics 19 의사결정 바람직한상태를달성하기위하여하나또는그이상의대안중에서하나를선택하는의식적인과정을말한다. 정철현, 행정의사결정론, 다산출판사, 2001 의사결정규칙 decision rule 사람들이의사결정에도달하는서로합의된방식 시스템의동작의일부분에영향을 의사결정트리 decision tree 미치는요소들의집합의모든결합에반응하는시스템동작들을그림으로 보여주는분석모델 시스템동작의일부분에영향을미치는 의사결정표 decision table 요소들의집합의값들이결합한것을보여주고각각의결합에대해예상되는 시스템동작을알려주는표 이벤트 event 기능동작또는상태변경과같이, 시스템환경에서발생되어시스템의반응을이끌어내는트리거또는자극 Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : 이송확인서 Delivery Confirmation 통합된제품인도후고객에게제품이송이완료되었음을증명하는문서 Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003 권한부여가잘되어있고의사결정 프로세스가확립되어있어도정의된 이슈 Issue 의사결정프로세스에서해결할수없는이슈가발생할수있다. 이러한이슈는 CMMI 상위레벨의의사결정자에게전달되어 해결되어야한다. 개인적인차원에서해결할수없는 이슈관리 이슈들을해결하기위한프로세스를말한다. 이슈문서는프로젝트에대해서 발생하거나영향받는모든이슈들을

20 사전적으로평가하고보고하는양식이다. 이는문제점을기록할뿐만아니라그 영향을평가하고개선점을제안하며 해결에필요한시간과예산을결정할수 있다. 이슈관리는프로젝트가종료될 20 때까지계속적으로수행된다 한환경에서다른환경으로전이될수 ISO/IEC 12119, "Information 이식성 Portability 있는소프트웨어제품의능력을말하며, 환경은조직, 하드웨어혹은소프트웨어 Technology - Software Package - Quality requirement 환경을말한다. and testing" 약정된일의결과에대한책임이있거나 Mary Beth Chrissis et Al., 영향을 CMM : 이해관계자 Stakeholder 미치는그룹또는개인. 이해관계자는 Guidelines for Process 프로젝트구성원, 고객, 사용자등이될 Integration and Product 수있다. Improvement 인디케이터는분석모델로부터유도된 구체적인속성을산정하고평가를 가능하게해주는측정변수이다. 예를 들어, 실제프로젝트진행경과와예상된 프로젝트진행경과간의차이를 분석모델로나타낼수있고이 인디케이터 Indicator 모델로부터얻은값을인디케이터라고한다. 인디케이터 ( = 실제프로젝트 Practical Software Measurement 진행경과 - 예상된진행경과 ) 가어느 레벨이상이면실제프로젝트 진행경과가계획한것보다뒤쳐지지 때문에적절한조치를취해야한다. 이와 같이인디케이터는측정분석과 의사결정을지원한다. 제품또는제품의컴포넌트를인수할 인수테스트 acceptance test 지를결정하기위해사용자, 고객, 또는권한을가진사람이수행할수있는 CMMI 정형테스팅 표준이나명세서에대한편차와에러를 인스펙션 inspection 포함한결함을발견하고식별하기위해 ISO 작업산출물에대해수행하는검사 팀또는개인이조직에게가치있는 인정 Recognition 성과를기여했을때팀또는개인에게주어지는특별한감사를통해 People CMM 이루어진다.

21 이해당사자들과직접적인대화를통하여 요구사항을추출하는가장직접적인 기법이며요구사항추출단계에서정보 인터뷰 interview 수집을위해사용되는가장일반적인소프트웨어개선센터, 기법이다. 인터뷰기법은이해당사자들의요구사항관리 (RM) 지침서, 관점을충분히반영할수있고, 인터뷰를한국과학기술원 (KAIST), 2004 진행하는동안질문자와답변자간에 21 빠른피드백이가능하여현문제와그에 따른해결책에대한이해를공유할수 있다는장점을갖는다. Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : 인터페이스 Interface 제품구성요소의인터페이스의기술서에 Guidelines for Process 완전성 Completeness 빠지거나부족한부족한부분이없는것 Integration and Product Improvement, Addison-Wesley, 2003 일회용프로토타입 throwaway prototype 요구사항과설계대안을분류하고검증하는목적을달성한후에는폐기할의도로만들어진프로토타입 종합적으로작업을정의하고관리 가능한작업의세부단위로분할을 작업구조분해 WBS 가능하게하는기법이다. WBS 는프로세스나제품의구성요소를구조적으로표현하기위한방법으로현재대표적인프로젝트관리도구의하나로여겨지고있다. 프로젝트관리에서사용되는 WBS 는프로세스, Richard E. Fairly and Richard H. Thayer, Work Break Structures, Software Project Management, IEEE Computer Society Press, 제품, 하이브리드이렇게세가지 유형으로분류된다. 규모가큰그룹은의욕과능력면에서는 규모가작은그룹보다유리하지만잘 전산용어사전편찬위원회, 작업그룹 working group 정리된결론을이끌어내기에는매우 컴퓨터인터넷?IT 용어대사전, 힘들다는단점을갖는다. 이럴경우 일진사, 2005 소규모의작업그룹으로나눈다. 작업산출물 Work Product 활동과태스크의결과는주로소프트웨어작업산출물이다. 소프트웨어작업산출물은소프트웨어프로세스를정의하고유지하고사용하는과정에서생성된모든산출물이다. 여기에는프로세스기술, 계획, 절차, 컴퓨터프로그램, 관련문서등이포함될수 Royce, W.W., Managing the Development of Large Software Systems: Concepts and Techniques, Proc WESCON Technical Papers, Vol. 14, 1970

22 있다. 작업산출물은프로세스에서다음단계의입력이되고미래프로젝트에서사용하기위해소프트웨어프로젝트에대한정보를저장한다. 22 추상적인차원에서시스템을묘사하는 분석으로모델컨텍스트다이아그램은 컨텍스트다이어그램 context diagram 시스템과상호작용하는외부의개체를파악하지만, 시스템의내부구조또는 동작에대해서는어떤것도보여주지 않는다. 컴포넌트 component 하드웨어나소프트웨어의단위. 혹은기능을이루는그들의조합 IEEE Std 1012, "IEEE Standard for Software Verification and Validation, March", 1998 컴포넌트테스트 component test, unit test 하드웨어나소프트웨어의단위혹은단위조합을대상으로수행되는테스트 IEEE Std 1012,"IEEE Standard for Software Verification and Validation, March", 1998 Barry Boehm, Bradford Clark, Ellis Horowitz and Chris Westland, Cost models for Barry Boehm 이처음발표한 future software life cycle 코코모 COCOMO COCOMO(constructive cost model) 는 1980 년대의대표적인매개변수비용 processes: COCOMO 2.0, Software Engineering Project 산정모형중하나이다. Management, 2nd ed., R.H. Thayer, ed., IEEE Computer Society Press, Los Alamitos, Calif., 1997 공통의속성과동작을가지는 클래스 class 개체집합에대한설명으로, 일반적으로비즈니스또는문제영역의실제환경 항목 ( 사람, 장소, 물건 ) 에대응된다. 클래스다이어그램 class daigram 시스템또는문제영역의클래스집합과그관계를보여주는분석모델 프로젝트계획의정확성과현실성을 평가하는것이다. 프로젝트계획이 타당성분석 타당하기위해서는프로젝트의세부계획들이모두기술적으로실현 가능해야하고서로들간에모순이 없어야한다.

23 수행되어야할작업은태스크로 Fairley, R.E. and R.H. Thayer, 나누어진다. 태스크는프로젝트의상태에 Work Breakdown Structure, 대한가시적인체크포인트로관리를 Software Engineering Project 태스크 task 제공하는소프트웨어프로세스에서잘 Management, 2nd ed., R.H. 정의된단위작업이다. 태스크는준비 Thayer, ed., IEEE Computer 23 기준 ( 선조건 ) 과완료기준 ( 후조건 ) 을 Society Press, Los Alamitos, 가지고있다. Calif., 1997 테스트 test 시스템이정해진요구를만족하는지, 예상과실제경과가어떤차이를보이는지수동또는자동방법을동원하여검사하고평가하는과정 IEEE Std 829, "IEEE Standard for Software Test Documentation", 1983 테스트범위, 접근방법, 자원, 테스트 IEEE Std 1012, "IEEE Standard 테스트계획 test plan 스케줄등의테스트관련정보를 for Software Verification and 포함하는문서 Validation, March", 1998 테스트교육 test training 테스트활동과관련된교육내용혹은관련활동 SW-TMM 소프트웨어개발자와독립적으로테스트 IEEE Std 829, "IEEE Standard 테스트그룹 test group 케이스및테스트절차를준비하고 for Software Test 실행하는책임을가지는사람들의모임 Documentation", 1983 테스트기법 test technique 테스트데이터를선정하기위한기법 SW-TMM 요구사항과관련하여소프트웨어 테스트대상 test object 요구명세서의명시된조건하에측정되어야할소프트웨어구성요소및 IEEE Std 1008, "",1987 특징 테스트메트릭 test metric 주어진속성내에서어느정도의역량을 가지는지를정량적으로측정하는수단 IEEE Std "IEEE Standard 테스트설계 test design 소프트웨어특성에맞도록관련테스트의명세정보를문서화하는것 for Glossary of Software Engineering Terminology",1990 테스트절차 test procedure 해당테스트의셋업, 실행, 결과분석과같은세부지침사항을정리한것 테스트조직 test organization 테스트관련활동을수행하고모니터링하는조직 IEEE Std "IEEE Standard 테스트커버리지 test coverage 테스트수행결과가요구사항에부합하는지를결정하기위한기준 for Glossary of Software Engineering Terminology",1990 테스트 프로세스 test process 테스트수행시필요한테스트관련활동, IEEE Std 1012, "IEEE Standard 환경등의조합 for Software Verification and

24 Validation, March", 1998 테스트활동 test activity 테스트를실행하거나계획할때수행하는관련활동들의조합시스템이나컴포넌트의구성요소중 24 테스트가능성 testability 어떤것이테스트할만한것들인지를 결정하는작업 테스트데이터 test data 테스트하고자하는소프트웨어의의미있는입력데이터 TMM 테스트케이스 testcase 테스트입력물, 실행조건, 특정목적에기대되는결과값등의조합 IEEE Std 610, "", 템플릿통합계획통합제품및프로세스개발통합테스트통합업무환경 template 완벽한문서또는다른항목을만드는 가이드로사용될패턴 프로젝트수행에필요한다양한 활동들에대한계획의통합을의미한다. Integrated Plan 프로젝트계획, 구매계획, 형상관리 계획, 위험계획, 품질계획등이 포함된다. 제품개발에필요한모든핵심요소들을 동시에통합하여설계, 제조, 지원 프로세스를최적화하는관리기법을 말한다. 즉제품컴포넌트별로그 IPPD(Integrated 완수에필요한모든관련당사자들이 DoD Guide to Integrated Product and Process 하나의팀으로구성된통합팀이 Product and Process Development) 구성되고이들이맡은산출물을 Development 개발해내는제품개발전략이다. IPPD 는 제품개념확립단계부터생산 단계에까지걸쳐서비용과품질목표를 만족시키는것을촉진한다. integration test 소프트웨어컴포넌트간혹은하드웨어와소프트웨어간의인터랙션활동을대상으로수행되는테스트 IEEE Std 1012, "IEEE Standard for Software Verification and Validation, March", 1998 IPPD 의효율적인수행에필요한협력과 동시개발을가능케하는업무환경. 구축된통합업무환경은사람들이제품, Integrated Work Environment 프로세스, 요구사항에대해효과적이고 CMMI 명확하게의사소통할수있게해야하며, 비즈니스부서와기술부서간, 그리고팀, 프로젝트, 조직간의통합을지원해야한다.

25 통합팀은시기적절한협력으로주어진 작업산출물완성을위해총력을다하는 상호보완적인기술과지식을가진 사람들로구성된다. 통합팀의팀원들은 작업산출물생명주기의각단계에서 CMMI : Guidelines for Process 25 통합팀 Integrated team 필요한기술과의견을제공하며작업 Integration and Product 산출물을완성하는데공동으로책임이 Improvement 있다. 통합팀은작업산출물과관련된 조직, 적용분야, 직능영역으로부터 적절한권한을부여받은대표를 포함해야한다. 팀헌장은임무를달성하기위해 제공되는권위, 자원뿐만아니라팀의 임무의명확한기술이다. 팀헌장은보통 임무기술, 목적, 또는작업기술, 권위, 팀헌장 Team charter 한계조건 ( 범위, 제한사항, 자원, 일정 ), 팀원, 요구사항또는명세등을포함한다. 헌장은팀을올바른방향으로이끌수있도록구체적이어야하나너무 DoD Guide to Integrated Product and Process Development 제한적이어서도안된다. 팀이일단 작업의범위를이해하면좀더구체적인 목표를설정할것이며초기헌장은 스폰서와의협의아래변경될것이다. IEEE Standard Glossary of 형상감사 Configuration Audit 실제형상항목들이요구되는물리적, 기능적특성을어느정도까지반영하는지확인하기위해감독하고검사하는일련의활동 Software Configuration Management Plans(IEEE std ), IEEE Standards Collection (Software Engineering), Piscataway, NJ:IEEE, 1997 형상관리 Configuration Management 시스템형상요소의기능적특성이나물리적특성을문서화하고그들특성의변경을관리하며, 변경의과정이나실현상황을기록 보고하여지정된요건이충족되었다는사실을검증하는것, 또는그과정 IEEE Standard Glossary of Software Engineering Terminology(IEEE std ), IEEE Standards Collection (Software Engineering), Piscataway, NJ:IEEE, 1997 형상관리계획 Configuration Management Plan 형상관리시스템을정의하고형상관리가 Davis, A.M., 201 Principles of 프로젝트에서어떻게실행되는지에대해 Software Development, New 미리생각하여일의순서나배치를대강 York: MaGraw-Hill, 1995 잡아보는일또는그문서

26 형상상태보고형상식별형상통제형상관리위원회형상항목 IEEE Standard Glossary of Software Configuration Management Plans(IEEE std- Configuration Status 형상항목의상태를기록하고보고하는 ), IEEE Standards Account 일련의활동 Collection (Software Engineering), Piscataway, NJ:IEEE, 1997 시스템을구성하는형상항목을선별하여 Configuration 기능적, 물리적특성을기술적으로 IEEE std Identification 문서화하는활동 IEEE Standard Glossary of Software Configuration 형상항목이공식적으로식별된뒤에 Management Plans(IEEE std- Configuration 형상항목에대한변경을평가, 조정, ), IEEE Standards Control 승인또는기각, 적용하는일련의 Collection (Software 활동으로정보의변경을통제하는활동 Engineering), Piscataway, NJ:IEEE, 1997 IEEE Standard Glossary of Software Configuration Management Plans(IEEE std- Configuration 형상항목의변경제어에대한전체적인 ), IEEE Standards Control Board 책임을갖는조직 Collection (Software Engineering), Piscataway, NJ:IEEE, 1997 다른시스템구성요소와는따로 configuration item 개발되거나, 구입되거나, 제어되거나, ISO 유지보수되는시스템구성요소 26