지침서 용어
|
원문 용어
|
설명
|
출처
|
| 감사 | audit | 작업 산출물이나 프로세스가 명세서나 표준, 계약상의 동의사항과 일치되는지를 평가하기 위해 독립적으로 시행되는 검사활동 | ISO 8402-1994 |
| 개발주기 비용 서브 모델 | life-cycle cost submodel | 소프트웨어의 유지 보수 단계에서 초기에 신속하게 비용을 예측하는데 사용되는 서브모델이다. 이 모델은 개발 비용과 설계 변수를 제공하는 획득 서브모델과 함께 사용된다. | Abdel-Hamid, T., Lessons Learned from Modeling the Dynamics of Software Development, Abdel-Hamid, T., Communications of the ACM, December 1989. |
| 개체 | entity | 데이터 특성과 이 특성에 대하여 수행되어야 하는 작업목록이 수집될 수 있는 클래스의 특정 인스턴스. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 검증 | verification | 해당 프로덕트가 해당 단계의 특정 요구사항을 만족하는지 확인하는 작업. 올바른 프로덕트를 구현했는가("you built thing rightly")를 검증 | IEEE Std 1012, "IEEE Standard for Software Verification and Validation, March", 1998 |
| 검토 | Review | 소프트웨어 개발기간동안 다양한 시점에서 적용되며, 오류와 결함을 발견하는 활동 | Roger S. Pressman, Software Engineering: A Practitioner's Approach, 5th Edition |
| 결함 | defect | 안전에 관한 것을 포함하여 의도된 요구사항이나 기대사항에 대한 불충족하는 것 | IEEE Std 1028-1997 |
| 결함 | Fault | 컴퓨터 프로그램 내부의 부정확한 절차, 프로세스 혹은 데이터 정의 | ISO/IEC 14598, "Information Technology - Software product evaluation - Part 1, 2, 3, 4, 5, 6. |
| 결함 밀도 | defect density | 프로덕트 사이즈(1000라인)당 결함개수 | CMMI |
| 고객 | customer | 제품이 만든 출력을 요청하고, 지불하고, 명시하고, 사용하는 프로덕트 관련자들 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 고급 프로젝트 관리 영역 | 조직의 표준 프로세스를 개조(tailoring)하여 프로젝트에 적합한 프로세스를 만들어 프로젝트를 관리하는 활동과 관련 당사자와의 상호조정과 협업, 위험 관리, 통합팀 구성, 정량적인 프로젝트 관리 활동을 포함하고 있다. | ||
| 고장 | Failure | 필요한 기능을 수행하는 어떤 요소의 기능 종료 혹은 미리 지정된 제한시간 내에서의 수행 불능을 말한다. | CMU_SEI-1996-HB-001 |
| 공약 | commitment | 문서화되고 공개적으로 발표된 약속 | |
| 공유비전 | Shared vision | 공유 비전 수립은 미래에 대한 방향을 새로 정립하는 것이다. 공유 비전을 통해 구성원들은 조직의 미래상을 분명히 깨달으면서 전략적 우선 순위를 가늠하게 된다. 공유 비전은 구성원과 고객, 주주 등 이해 당사자들에게 새로운 행동 양식과 실행이 필요함을 일깨워 주고 매일매일 벌어지는 의사결정 과정에 지침이 된다. 공유비전은 보통 가치 제시와 차별화 된 역량, 고객 등 이해 당사자, 조직 구성 원칙, 성과 목표 등 5가지 구성 요소의 결합으로 만들어진다. | Block, P. The Empowered Manager. Positive Political Skills at Work. SanFrancisco: Jossey-Bass Inc., 1987. |
| 공통 측정 항목 | Common Measure | 조직의 표준 프로세스에 기초하여 선택된 측정 항목의 집합. 표준 프로세스를 수행하면서 조직에서 공통적으로 특정해야 하는 항목. | CMMI® |
| 관련자 | Stakeholder | 프로젝트 결과의 영향을 받거나 결과에 영향을 미칠 수 있는 조직 또는 사람과 그룹 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 관리 조정 위원회 | MSG(Management Steering Group) | SPI프로그램을 조직의 비전 및 미션과 연결하고 스폰서 쉽을 소개하고, 자원을 할당하며, 진적도를 모니터링하고 가이드라인과 시정을 제시해주는 그룹 | ISO/IEC 14598, "Information Technology - Software product evaluation - Part 1, 2, 3, 4, 5, 6. |
| 관리검토 | management review | 소프트웨어 프로젝트의 상태와 진척상황, 문제점, 위험요소 등을 정기적으로 모니터링하기 위한 체계적인 평가활동 | IEEE Std 1028-1997 |
| 관리되는 프로세스 | Managed process | 관리되는 프로세스는 ‘수행되는 프로세스’로서, (1)회사 정책에 따라 계획 및 실행되고, (2)숙련된 인력을 고용하고 적절한 자원을 사용하여 제어된 산출물을 만들고, (3)적절한 이해당사자가 참여하고, (4)감시, 제어 및 검토 되며, (5)프로세스에 정의된 바를 준수하였는지 평가되는 프로세스이다. 여기서, ‘수행되는 프로세스’는 작업산출물을 만드는데 필요한 작업을 달성하는 프로세스를 말한다. | CMMI : Guidelines for Process Integration and Product Improvement |
| 구매자 | Acquirer | 소프트웨어 공급자로부터 시스템, 소프트웨어 제품, 또는 소프트웨어 서비스를 구매 혹은 조달하는 조직을 말한다. | ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics |
| 구조적 브레인스토밍 | 사회자나 진행자가 의사결정을 하려는 집단을 통제하고 지시하는 브레인스토밍 기법을 말한다. 대부분의 구조적 브레인스토밍의 경우, 사회자나 진행자가 참여자에게 정해진 순서대로 아이디어를 제시할 것을 요구하고 참여자는 모두 자기 차례에 아이디어를 제시한다. | 정철현, 행정의사결정론, 다산출판사, 2001 | |
| 구조화된 의사결정 | 이미 설정된 대안을 기준으로 일상적이며 반복적으로 이루어지는 의사결정 | 정철현, 행정의사결정론, 다산출판사, 2001 | |
| 권한 부여 가이드라인 | IPPD 환경에서 책임과 권한의 명확한 수립이 특별히 중요하다. 프로젝트와 조직 내에서, 개인 또는 통합팀이 너무 많은 혹은 너무 적은 권한을 가지고 있거나 의사 결정 방법이 모호한 경우 이슈가 발생할 수 있다. 권한의 정도를 결정하는 가이드라인이 그러한 이슈를 예방할 수 있다. | CMMI | |
| 권한위임 | Empowerment | IPPD 환경에서 통합팀이 성공적으로 목표를 달성하기 위해서는 권한이 위임되어야 한다. 권한 위임은 팀 레벨, 팀원 레벨에서 모두 이루어져야 한다. 권한 위임 된 팀은 팀의 업무를 수행하고 관리하는 데 상당한 자율성을 부여 받게 된다. 팀은 비즈니스 목적의 달성과 조직 내부 지침들을 수행하는 데 필요한 방법을 결정할 수 있는 권한을 가진다. | |
| 권한이 위임 된 팀 | Empowered Team | 팀이란 팀의 업무를 수행하고 관리하는 데 상당한 자율성이 부여된 팀을 말한다. 팀은 비즈니스 목적의 달성과 조직 내부 지침들의 수행에 대한 방법을 결정할 수 있는 권한을 가진다. 통합팀이 효율적으로 할당된 업무를 수행하기 위해서는 권한을 가진 팀이 되어야 한다. | |
| 기능 요구사항 | functional requirements | 특정 조건 하에서 시스템이 보일 기능의 일부 또는 동작의 일부에 대한 설명 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 기능성 | Functionality | 소프트웨어가 특정 조건에서 사용될 때, 명시된 요구와 내재된 요구를 만족하는 기능을 제공하는 소프트웨어 제품의 능력 | ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics |
| 기능점수 | Function point | 기능점수는 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 |
| 기본 프로젝트 관리 영역 | 프로젝트 계획을 수립하고 공약을 획득하며 진도를 관리하고 공급계약을 관리하는 것과 같은 기본적인 활동들을 다룬다. 이들은 프로젝트 계획을 수립하고 관련 당사자들을 적절하게 참여시키며 계획에 대한 공약을 획득하는 과정을 포함한다. 프로젝트 계획은 산출물에 대한 요구사항으로부터 도출되며 이와 함께 다양한 프로젝트 관리 활동을 수반한다. 관리를 위해서 측정활동을 포함하고 있으며 형상 관리 계획 등 기타 관련 계획들을 관련 당사자들과 함께 검토하며 함께 공약사 | ||
| 기술검토 | technical review | 작업 산출물이 주어진 명세서와 일치하는지, 계획, 표준, 가이드라인을 준수하는지 평가하는 공식적인 활동 | NASA-STD-A201 |
| 기술적 데이터 패키지 | technical data package | 제품과 제품 구성요소의 형태에 적합한 제품 아키텍처 기술서, 제품 특성, 인터페이스 요구사항 등을 포함하는 수집 항목 | Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003 |
| 기술적 요구사항 | technical requirements | 달성되거나 부가되어야 하는 제품 또는 서비스의 특성 | 속성 |
| 기초측정변수 | Base Measure | 지정된 측정 방법으로 한 개의 속성을 측정하는 것을 말한다. 예를 들어, 소프트웨어 규모를 측정하려고 할 때, 코드 라인 수를 세는 것이 기초측정변수에 해당된다. | Practical Software Measurement |
| 마일스톤 차트 | milestone chart | 마일스톤이란 프로젝트 진행에서 중요한 의미가 있는 사건 또는 시점을 의미한다. 프로젝트 착수일, 주요 산출물 완료일 등이 마일스톤이 될 수 있는데, 마일스톤 자체는 수행기간이 영(0)이라는 점에서 태스크와 구분된다. 마일스톤의 차트의 장점은 규모가 큰 프로젝트의 전체적인 현황을 파악하기 쉽다는 점이다. | Richard H. Thayer, Edward Yourdon, Software Engineering Project Management, IEEE Computer Society, 2000 |
| 메트릭 | metrics | 제품이 가진 특징, 품질, 특성, 속성을 나타내는 범위나 등급을 정량적으로 측정 | NASA-STD-A201 |
| 명세 요구사항 | requirements specification | 구조적이고 공유가능하며 관리가능한 형식으로 시스템의 요구사항을 문서로 만드는 프로세스. 또한 이 프로세스에서 나오는 산출물도 포함. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 모델링 | modeling | 독창적인 특징을 알기 쉽게 나타내기 위해 실제를 재현하고 단순하게 축소하여 보여주는 모형을 만드는 과정이다. 해결하려는 문제에 따라 많은 모델링이 이루어질 수 있고 같은 문제라도 누가 작성하느냐에 따라 판이하게 다른 모델링이 만들어진다. | 정철현, 행정의사결정론, 다산출판사, 2001 |
| 바 차트 | bar chart | 바 차트는 간트 차트(Gantt chart)라고도 하는데, 일반적으로 가장 많이 사용되는 일정 형식이다. 바 차트의 특징은 태스크 하나하나의 수행 기간이 시각적으로 표현되어 파악하기 쉽다는 점이다. 또한 바 차트는 프로젝트의 진행상황을 효과적으로 나타낼 수 있기 때문에 이해당사자에게 프로젝트 진행상황을 보고하는 목적으로 유용하게 사용된다. | Richard H. Thayer, Edward Yourdon, Software Engineering Project Management, IEEE Computer Society, 2000 |
| 범위 | scope | 현재의 프로덕트가 해결할 최종 제품의 비전 부분. 범위는 프로젝트의 안과 밖의 경계를 정의한다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 범위 확장 | scope creep | 개발 프로세스 전체에서 프로젝트의 범위가 통제되지 않으며 계속 증가하는 상황 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 변경 관리 | change control (=change management) | 제품 또는 서비스의 변경을 효과적으로 관리하기 위한 방법 | CMMI® |
| 변경관리 위원회 | 소프트웨어 요구사항에서 제안된 변경을 승인하거나 거부하는 의사결정을 할 수 있는 사람들의 그룹 | Karl E. Wiegers, Software requirements, Microsft, 2003 | |
| 보상 | Compensation | 수행된 업무에 대해 조직 구성원에게 제공되는 모든 종류의 보수를 가리킨다. 주로 임금과 보장된 이익을 포함한다. IPPD 수행을 지원하기 위해서는 팀기반 보상 시스템을 구축해야 한다. 개인에게 제공할 보상의 정도를 결정하기 위해서는 개인의 성과뿐만 아니라 팀 성과를 고려해야 한다. | People CMM |
| 보상 전략 | Compensation Strategy | 조직의 구성원들에게 보상을 하기 위한 조직의 이념과 방법을 포함한다. 조직의 보상 전략은 일반적으로 아래 사항들을 포함한다. - 보상 전략에서 결정된 전략적 판단에 대한 근본적, 합리적 이유 - 보상을 제공하는 수단들과 이러한 수단들이 사용되는 방법 - 보상이 이루어지는 주기에 대한 정의 - 보상을 결정하고 조정하는 기준 - 직책 성격에 따른 보상을 결정하는 기준과 보상 수단을 사용하기 위한 가이드라인 - 개인, 직책, 팀, 유닛을 위한 보상 결정이 | People CMM |
| 보상 활동 계획 | Compensation Plan | 보상 전략을 실행에 옮기기 위해 필요한 보상 활동들을 관리할 수 있도록 정기적으로 준비된 계획. 보상 계획은 일반적으로 다음을 포함한다. - 보상 결정을 가이드하고 보상 전략을 관리하기 위해 필요한 재정 데이터 - 보상 전략 관리에 참여하는 사람들을 위한 이벤트와 책임의 일정 - 보상 전략에 기술된 방법들을 보상 결정 시에 사용하는 방법 - 보상 결정이 검토되는 시기와 방법 | People CMM |
| 부서 | Home Organization | 통합팀의 팀원들이 통합팀에 속하지 않을 때 속해 있는 조직 내의 단위를 말한다. | People CMM |
| 부적합사항 | noncompliance issue | 명세된 표준, 절차, 계획, 요구사항, 디자인과의 편차 | Pressman |
| 분석 모델 | Analysis Model | 두 개 이상의 기초측정변수나 기초 및 유도측정변수와 관련된 계산방법이나 알고리즘이다. 예를 들어, 프로젝트 진행경과 인디케이터는 다음과 같은 함수를 이용하여 구했다. 진행경과 인디케이터 = 실제 프로젝트 진행경과 - 예상된 프로젝트 진행경과 여기서 분석모델은 두 값의 차로 나타내고 있다. 분석 모델의 다른 예로 평균과 표준편차를 들 수 있다. | ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics |
| 분석 요구사항 | analysis requirements | 요구사항 정보를 다양한 카테고리로 분류하고, 바람직한 품질에 대해 요구사항을 평가하고, 다양한 형식으로 요구사항을 표현하고, 고차원의 요구사항에서 상세한 요구사항을 추출하고, 우선순위를 협의하는 프로세스 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 불확실성 하에서의 의사결정 | 의사결정을 위한 여건의 예측이 불가능하거나 예측이 가능한 경우라도 신뢰도가 낮은 경우를 말한다. | 정철현, 행정의사결정론, 다산출판사, 2001 | |
| 브레인스토밍 | Brainstorming | 일정한 테마에 관하여 회의형식을 채택하고, 구성원의 자유발언을 통한 아이디어의 제시를 요구하여 발상을 찾아내려는 방법. 원리는, ① 한 사람보다 다수인 쪽이 제기되는 아이디어가 많다. ② 아이디어 수가 많을수록 질적으로 우수한 아이디어가 나올 가능성이 많다. ③ 일반적으로 아이디어는 비판이 가해지지 않으면 많아진다. 등의 원칙에서 구할 수 있다. | Scholtes, P. et al. The Team Handbook. Madison, Wisc.: Joiner Associates, Inc., 1988. |
| 비구조적 브레인스토밍 | 사회자나 진행자가 없고 참여자가 형식없이 자유롭게 이야기하는 브레인스토밍 기법을 말한다. 구성원은 차례에 상관없이 언제든지 아이디어를 내놓을 수 있다. | 정철현, 행정의사결정론, 다산출판사, 2001 | |
| 비구조화된 의사결정 | 사전에 알려진 대안이 없는 경우에 이루어지는 의사결정 | 정철현, 행정의사결정론, 다산출판사, 2001 | |
| 비기능 요구사항 | nonfunctional requirements | 소프트웨어 시스템이 보여주어야 하는 품질 속성이나 특징에 대한 설명, 또는 시스템이 관측 가능한 시스템 동작 이외에 따라야 하는 제약 조건에 대한 설명 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 비기술적 요구사항 | nontechnical requirements | 산출물이나 용역이 수용되는데 영향을 끼치는 계약 조항, 이행방침, 조건, 약정. 그 실례로 양도되는 산출물, 양도된 상용품 | COTS |
| 비전 | vision | 새 시스템의 최종 목적과 형태에 대한 장기적인 전략적 개념 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 비전과 범위 문서 | vision and scope document | 새 시스템에 대한 비즈니스 요구사항을 제시하는 문서로, 제품 비전 선언과 프로젝트 범위 설명을 포함하낟. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 비즈니스 규칙 | business rule | 비즈니스의 일부 영역을 정의하거나 제한하는 정책, 가이드라인, 표준 또는 규제 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 비즈니스 요구사항 | business requirements | 제품을 구축하는 조직 또는 제품을 구매하는 고객의 추상적인 비즈니스 목표 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 사용 품질 | Quality in use | 사용자 관점의 품질을 말하며 효율성, 생산성, 안전성 그리고 만족도 등 네 가지 특성을 갖는다. 사용 품질의 달성은 관련된 소프트웨어 제품의 품질 부특성에 대한 외부 측정의 기준치 도달 여부에 달려 있으며, 외부 측정은 다시 관련된 내부 측정의 연관 기준치 도달 여부에 달려 있다. | ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics |
| 사용성 | Usability | 명시된 조건에서 사용될 경우, 사용자에 의해 이해되고 학습되고 사용되고 선호될 수 있는 소프트웨어 제품의 능력 | ISO/IEC 12119, "Information Technology - Software Package - Quality requirement and testing" |
| 사용자 | user | 시스템과 직접 또는 간접적으로 상호작용할 고객(예를 들면, 시스템의 출력물을 사용하지만 이 출력물을 개인적으로 만들지 않는다). 일반 사용자라고도 부른다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 사용자 계층 | user class | 시스템에 대해 비슷한 특징과 요구사항을 가지고 있는 시스템 사용자 그룹, 사용자 계층 구성원은 시스템과 상호작용할 경우에는 동작자 역할을 한다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 사용자 문서 | User Documentation | 인쇄나 비인쇄 형태로 이용 가능한 모든 문서로 제품의 사용을 위해 제공되는 제품의 필수 부분을 말한다. 예를 들어, 책자 형태의 사용자 매뉴얼이나 파일 형태의 온라인 매뉴얼 등을 말한다. | ISO/IEC 14598, "Information Technology - Software product evaluation - Part 1, 2, 3, 4, 5, 6. |
| 사용자 요구사항 | user requirements | 사용자가 시스템을 사용해서 수행할 수 있어야 하는 사용자 목표 또는 작업 또는 시스템의 품질에 대한 사용자 기대에 대한 설명 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 사이즈 서브모델 | Sizing submodel | 소프트에어 크기 산정을 돕는 서브모델이다. 크기 단위는 소스코드라인(source line of code), 기능점수, 객체점수(object point)가 될 수 있다. 객체점수는 객체 지향 개발 프로젝트에서 크기를 산정하는 새로운 기법으로 [Minkiewicz 98]에서 소개되었다. | Abdel-Hamid, T., Lessons Learned from Modeling the Dynamics of Software Development, Abdel-Hamid, T., Communications of the ACM, December 1989. |
| 사전조건 | precondition | 유스케이스가 시작된기 전에 시스템이 있어야 하거나 충족되어야 하는 조건 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 사후조건 | postcondition | 유스케이스가 성공적으로 완료된 후에 시스템의 상태를 설명하는 조건 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 산정 | Estimation | 프로젝트 계획 수립 시에 프로젝트와 관련된 예측을 하는 것을 말한다. 산정이 필요한 주요 대상은 프로젝트의 규모, 공수, 스케줄, 품질 등이다. | Practical Software Measurement |
| 상위관리자 | Senior Management | 조직의 프로세스 개선 효과에서 자원의 할당에 직접적인 권한을 가지고 있으며, 충분히 높은 관리 역할을 수행한다. 이 역할은 장기적으로 지속된다. | Mary Beth Chrissis et Al., CMM®: Guidelines for Process Integration and Product Improvement |
| 상호운용성 | Compatibility | 제품 구성요소들이 서로 통합되어 목표된 기능을 제공할 수 있는 품질 특성 | Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003 |
| 생명주기 모델 | Life Cycle Model | 소프트웨어 제품의 개발, 운영, 유지보수에 포함되는 프로세스와 활동들을 담고 있는 프레임워크. 요구사항 정의에서 사용이 종결될 때 까지의 기간을 포함. | IEEE-EIA 12207 |
| 생명주기 비용 | life-cycle cost | 생명주기 비용이란 시스템의 생명주기 혹은 프로젝트의 생명주기 전반에 걸쳐 투입되는 비용을 의미한다. | A Guide to the Project Management Body of Knowledge, Project Management Institute, 2000 |
| 성과 분석 | 프로젝트가 계획과 목표를 잘 이행하고 있는지를 평가하는 것을 말한다. | ||
| 소프트웨어 개발 생명 주기 | Software development life cycle | 소프트웨어 개발 생명 주기는 소프트웨어가 계획, 요구 사항 분석, 시스템 및 프로그램의 설계, 코딩, 시험, 구현 및 평가 과정을 거쳐서 완성된 후 유지 보수를 통해서 활동하다가 폐기되는 과정을 말한다. | Alan M. Davis, “Software Life Cycle Models”, Software Engineering Project Management, 2nd ed., R.H. Thayer, ed., IEEE Computer Society Press |
| 소프트웨어 요구사항 명세 | software requirements specification | 소프트웨어 제품의 기능과 비기능 요구사항의 집합을 체계적으로 문서화 한 것. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 소프트웨어 제품 | Software Product | 컴퓨터 프로그램, 절차 또는 관련 문서 및 데이터의 집합 | ISO/IEC 14598, "Information Technology - Software product evaluation - Part 1, 2, 3, 4, 5, 6. |
| 소프트웨어 품질 | software quality | 기능, 성능 및 개발 표준들에 관련된 요구사항을 충족시키는 것 | IEEE Std 1028-1997 |
| 소프트웨어 프로세스 | software process | 소프트웨어나 프로덕트를 개발하고 유지하기 위해 사람들이 사용하는 활동이나, 방법 등의 조합 | "Software Process Framework in CMM, CMM-SPF" |
| 소프트웨어 프로세스 공학 메타모델 | Software Process Engineering Metamodel: SPEM | 프로세스 모델링을 위한 표준 메타모델로 OMG에서 2001년에 개발한 것으로 소프트웨어 개발 프로세스와 그에 관련된 사항들을 정의하기 위한 메타모델이다. SPEM은 UML 메타모델을 기반으로 하고 있어 UML을 이용하여 프로세스를 모델링 할 수 있도록 지원한다. | |
| 수직적 프로토타입 | vertical prototype | 아키텍처의 모든 계층을 포함하여 소프트웨어 시스템을 종으로 부분 구현하는 프로토타입, 기술 타당성과 성능을 평가하는 데 사용된다. 구조적 프로토타입 또는 개념검증이라고도 부른다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 수평적 프로토타입 | horizontal prototype | 소프트웨어 시스템의 사용자 인터페이스의 일부분 또는 가능한 구현. 유용성을 평가하고 요구사항의 완벽도와 정확도를 측정하는 데 사용된다. 또한 동작 프로토타입 또는 모크업이라고도 불린다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 스테이트 트랜지션 다이어그램 | state transition diagram | 시스템이 있을 수 있는 다양한 상태 또는 시스템의 개체가 가질 수 있는 상태와 상태 간에 발생될 수 있는 허용된 변이를 보여주는 분석 모델로 스테이트 차트 다이어그램과 비슷하다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 스테이트차트 다이어그램 | statechart diagram | 발생되는 특정이벤트에 대해 시스템의 개체가 거치는 상태의 순서 또는 시스템 전체의 가능한 상태를 보여주는 분석 모델 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 스폰서 | Sponsor | 스폰서는 프로젝트에 대해서 최종적으로 책임이 있는 사람으로써 통합팀의 스폰서는 통합팀에게 업무를 부여하거나 자원을 제공하는 개인 또는 단체를 말한다 | CMMI : Guidelines for Process Integration and Product Improvement |
| 스프레드 시트 | spread sheet | 컴퓨터 응용 프로그램의 하나로 숫자나 문자 데이터가 가로 세로로 펼쳐져 있는 표를 입력하고 이것을 조작하고 다루어 데이터 처리를 할 수 있게 된 프로그램을 말한다. | 전산용어사전편찬위원회, 컴퓨터 인터넷?IT 용어대사전, 일진사, 2005 |
| 승인기준 | acceptance criteria | 소프트웨어 제품이 사용자, 고객 또는 다른 관련자들에게 수용되려면 충족시켜야 하는 조건 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 시뮬레이션 | simulation | 실제와 똑같은 상황을 만들어 그 결과를 실제 경험할 수 있게 해주는 것이다. 시뮬레이션을 사용하면 어려운 통계분석을 사용하는 것보다 사람들을 이해시키기 쉽다는 장점을 갖는다. | 소프트웨어 개선 센터, 요구사항 관리(RM)지침서, 한국과학기술원(KAIST), 2004 |
| 시스템 | System | 명시된 요구나 목적을 충족시키는 능력을 제공하는 하나 이상의 프로세스, 하드웨어, 소프트웨어, 장비 및 사람으로 구성되는 결합체 | ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics |
| 시스템 요구사항 | system requirements | 여러가지 하위 시스템을 포함하고 잇는 최고 수준의 요구사항으로 소프트웨어와 하드웨어 등 모든 것을 포함할 수 있다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 시스템 테스트 | system test | 시스템이 요구사항에 맞게 잘 구현 되었는지 통합된 완전한 시스템을 대상으로 수행되는 테스트 | SW-TMM |
| 시정조치 | Corrective anction | 존재하는 부적합 사항, 결함, 다른 기대되지 않은 상황의 원인을 재발을 막기위해 취해지는 행동 | ISO 8402-1994 |
| 시퀀스 다이어그램 | sequence diagram | 시스템에서 한 활동을 완료하기 위해 개체 또는 컴포넌트 간에 메시지가 통과하는 순서를 보여주는 분석 모델 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 신뢰성 | Reliability | 명세된 조건에서 사용될 때 성능 수준을 유지할 수 있는 소프트웨어 제품의 능력 | ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics |
| 심사 | Appraisal | 프로세스의 강점과 약점을 결정하기 위한 심사 참조 모델을 사용하여 훈련된 전문가가 하나 이상의 프로세스를 시험하는 활동 | CMMI® |
| 아키텍처 | architecture | 시스템을 구성하는 소프트웨어와 하드웨어 컨포넌트, 이컨포넌트 간의 인터페이스와 관계, 다른 컴포넌트에 공개되는 컴포넌트 동작 등 소프트웨어를 가지고 있는 시스템의 구조 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 액티비티 다이어그램 | activity diagram | 한 활동에서 다른 활동으로의 흐름으로 묘사해서 동적인 시스템 동작을 보여주는 모델로 플로우차트와 비슷하다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 엔터티 릴레이션 다이어그램 | entity relation diagram | 한 쌍의 엔티티 간의 논리적인 관계를 파악해주는 분석 모델 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 예외 | exception | 각 에러상황에 대하여 테스트 케이스를 선정하여 테스트하는 기법 | IEEE Std 1012, "IEEE Standard for Software Verification and Validation, March", 1998 |
| 외부 메트릭 | External Metrics | 실행 가능한 소프트웨어나 시스템을 시험, 운영 또는 관찰해 봄으로써 그 소프트웨어가 한 부분을 이루고 있는 시스템 형태에 대한 측정에서 추출되는 소프트웨어 제품 측정 척도이다. 외부 메트릭은 사용자, 평가자, 시험자 및 개발자가 시험 수행이나 운영 중에 소프트웨어 제품 품질을 평가할 수 있도록 도와준다. | ISO/IEC 14598, "Information Technology - Software product evaluation - Part 1, 2, 3, 4, 5, 6. |
| 외부 인터페이스 요구사항 | external interface requirements | 소프트웨어 시스템과 사용자, 또 다른 소프트웨어 시스템, 또는 하드웨어 장비 간의 인터페이스를 설명 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 외부 측정 | External Measure | 해당 제품을 일부분으로 하는 시스템의 행위를 측정함으로써 유추되는 제품의 간접 측정을 말한다. | ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics |
| 외주 | supplier | 획득해야 하는 제품을 공급하거나 서비스를 수행하는 엔티티 | |
| 요구사항 | requirement | 고객 요구나 목표 또는 제품이 이런 요구나 목표를 충족시키기 위해 가져야 하는 조건 또는 능력에 대한 설명. 제품이 관련자에게 가치를 제공하기 위해 가지고 있어야 하는 속성 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 요구사항 개발 | requirements developement | 프로덕트의 범위를 정의하고, 사용자 계층과 사용자 대표를 파악하고, 요구사항을 유도하고 분석하고 명시하고 검증하는 프로세스, 요구사항 개발의 산출물은 구축될 제품을 정의하는 요구사항 기본내용이다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 요구사항 공학 | requirements engineering | 제품에서 필요한 기능과 특성을 이해하는 것과 관련된 모든 프로젝트 라이프 사이클을 포함하는 여역으로 요구사항 개발과 요구사항 관리가 포함된다. 시스템공학과 소프트웨어 공학의 하위 원칙이다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 요구사항 관리 | requirement management | 제품 개발 프로세스와 제품의 운영 기간 동안 정의된 제품 요구사항의 집합에 대한 작업을 하는 프로세스. 요구사항 상태 추적, 요구사항 변경과 요구사항 명세 버전의 관리, 다른 프로젝트 단계와 산출물로의 요구사항 추적 등이 포함된다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 요구사항 분석가 | requirements analyst | 관련자 대표와 협력해서 프로젝트의 요구사항을 유도하고 분석하고 명시하고 검증하고 관리하는 리드 책임을 가지고 있는 프로젝트 팀의 역할, 비즈니스 분석가, 시스템 분석가, 요구사항 엔지니어, 분석가라고도 부른다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 요구사항 속성 | requirements attribute | 의도한 기능에 대한 설명 이상의 정의를 보완하는 요구사항에 대한 설명식 정보. 발생원, 논리, 우선순위, 담당자, 버전 번호 등이 있다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 요구사항 추적 메트릭스 | requirements traceability matrix | 각각의 기능 요구사항과 다른 시스템 산출물 간의 논리적인 연결을 보여주는 표로 다른 기능 요구사항, 유스 케이스, 아키텍처와 설계요소, 코드 모듈, 테스트 사례와 비즈니스 규칙을 포함한다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 요구사항 할당 | requirements allocation | 고객 요구사항이나 제품 요구사항을 다양한 아키텍처 하위 시스템과 컴포넌트 또는 또다른 개발 산출물에 분할하는 프로세스. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 운영 시나리오 | operational scenario | 생산품간의 상호관계뿐만 아니라 생산품과 그 환경, 사용자와 간의 상호관계를 포함한 일련의 예상절차에 대한 기술로써 운영 시나리오는 시스템의 분석과 설계를 평가하거나 시스템의 타당성을 증명하는데 사용된다. | Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003 |
| 운영개념 | operational concept | 어떤 객체가 사용되거나 운영되는 방법에 대한 일반적인 기술 | Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003 |
| 워크스루 | walkthrough | 디자이너나 개발자가 개발팀과 다른 관심있는 사람들을 이끌며 진행하는 작업 산출물에 대한 정적인 분석 방법 | IEEE Std 1028-1997 |
| 웨이버 증서 | Waiver Paper | 제품 통합을 위해 인도받은 제품 구성요소가 통합이 불가능할 경우 해당 제품에 대한 방출을 표기하는 문서 | Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003 |
| 위험 | Risk | 발생 가능성이 있지만 현재까지 발생하지 않은 비정상적인 이벤트나 실패 | David Gluch, A Construct for Describing Software Development Risks |
| 위험 회피 | risk avoidance | 더 낮은 위험을 가지는 해결방법을 선택함으로써 소프트웨어 개발에 대한 높은 위험을 가지는 해결방법을 회피하는 것 | Richard H. Thayer, Richard E. Fairley, “Software Risk Management”, Software Engineering Project Management, 2nd ed., R.H. Thayer, ed., IEEE Computer Society Press, Los Alamitos, Calif., 1997 |
| 유도, 요구사항 | elicitation, requirements | 인터뷰, 워크샵, 워크플로우와 작업 분석, 문서 분석과 다른 메커니즘을 통해 다양한 소스로부터 소프트웨어 또는 시스템 요구사항을 파악하는 프로세스 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 유도측정변수 | Derived Measure | 두 개 이상의 기초측정변수의 조합이나 기초 및 유도측정변수의 조합으로 이루어진 함수로 정의된다. | Practical Software Measurement |
| 유스 케이스 | use case | 동작자에게 가치를 제공하는 결과를 가져오는 동작자와 시스템 간의 논리적으로 연결된 상호작용들에 대한 설명. 여러 시나리오를 포함할 수 있다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 유스 케이스 다이어그램 | use case diagram | 가치있는 목표를 달성하기 위해 시스템과 상호작용할 수 있는 동작자와 각각의 동작자가 수행할 다양한 유스케이스를 파악하는 분석 모델 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 유저 인터페이스 | user interface | 컴퓨터 또는 단말기와 사용자가 대화를 하기 위한 접촉으로 이 접촉에는 키보드나 마우스, 디스플레이 등의 입출력을 통해서 하는 소프트웨어적 접촉과 디스플레이의 모양, 키보드의 배열, 의자의 높이 등 인간 공학적인 물리적 접촉이 있는데 일반적으로는 소프트웨어적인 접촉을 말하는 경우가 많다. 아무리 기능이 좋은 시스템이나 소프트웨어도 유저 인터페이스가 나쁘면 사용하기 불편하고 상품 가치가 월등히 떨어진다. | 전산용어사전편찬위원회, 컴퓨터 인터넷?IT 용어대사전, 일진사, 2005 |
| 유지보수성 | Maintainability | 소프트웨어 제품이 변경되는 능력. 변경에는 환경과 요구사항 및 기능적 명세에 따른 소프트웨어의 수정, 개선, 혹은 개작 등이 포함된다. | ISO/IEC 9126, "Information Technology - Software Quality Characteristics and metrics |
| 의사결정 | 바람직한 상태를 달성하기 위하여 하나 또는 그 이상의 대안 중에서 하나를 선택하는 의식적인 과정을 말한다. | 정철현, 행정의사결정론, 다산출판사, 2001 | |
| 의사결정 규칙 | decision rule | 사람들이 의사결정에 도달하는 서로 합의된 방식 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 의사결정 트리 | decision tree | 시스템의 동작의 일부분에 영향을 미치는 요소들의 집합의 모든 결합에 반응하는 시스템 동작들을 그림으로 보여주는 분석 모델 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 의사결정 표 | decision table | 시스템 동작의 일부분에 영향을 미치는 요소들의 집합의 값들이 결합한 것을 보여주고 각각의 결합에 대해 예상되는 시스템 동작을 알려주는 표 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 이벤트 | event | 기능 동작 또는 상태 변경과 같이, 시스템 환경에서 발생되어 시스템의 반응을 이끌어내는 트리거 또는 자극 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 이송확인서 | Delivery Confirmation | 통합된 제품 인도 후 고객에게 제품 이송이 완료되었음을 증명하는 문서 | Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003 |
| 이슈 | Issue | 권한 부여가 잘 되어 있고 의사 결정 프로세스가 확립되어 있어도 정의된 의사 결정 프로세스에서 해결할 수 없는 이슈가 발생할 수 있다. 이러한 이슈는 상위 레벨의 의사 결정자에게 전달되어 해결되어야 한다. | CMMI |
| 이슈 관리 | 개인적인 차원에서 해결할 수 없는 이슈들을 해결하기 위한 프로세스를 말한다. 이슈 문서는 프로젝트에 대해서 발생하거나 영향 받는 모든 이슈들을 사전적으로 평가하고 보고하는 양식이다. 이는 문제점을 기록할 뿐만 아니라 그 영향을 평가하고 개선점을 제안하며 해결에 필요한 시간과 예산을 결정할 수 있다. 이슈 관리는 프로젝트가 종료될 때까지 계속적으로 수행된다 | ||
| 이식성 | Portability | 한 환경에서 다른 환경으로 전이될 수 있는 소프트웨어 제품의 능력을 말하며, 환경은 조직, 하드웨어 혹은 소프트웨어 환경을 말한다. | ISO/IEC 12119, "Information Technology - Software Package - Quality requirement and testing" |
| 이해관계자 | Stakeholder | 약정된 일의 결과에 대한 책임이 있거나 영향을 미치는 그룹 또는 개인. 이해 관계자는 프로젝트 구성원, 고객, 사용자 등이 될 수 있다. | Mary Beth Chrissis et Al., CMM®: Guidelines for Process Integration and Product Improvement |
| 인디케이터 | Indicator | 인디케이터는 분석모델로부터 유도된 구체적인 속성을 산정하고 평가를 가능하게 해주는 측정변수이다. 예를 들어, 실제 프로젝트 진행경과와 예상된 프로젝트 진행경과 간의 차이를 분석모델로 나타낼 수 있고 이 모델로부터 얻은 값을 인디케이터라고 한다. 인디케이터( = 실제 프로젝트 진행경과 - 예상된 진행경과 )가 어느 레벨 이상이면 실제 프로젝트 진행경과가 계획한 것보다 뒤쳐지지 때문에 적절한 조치를 취해야 한다. 이와 같이 인디케이터는 측정분석과 의사결정을 지원한다. | Practical Software Measurement |
| 인수테스트 | acceptance test | 제품 또는 제품의 컴포넌트를 인수할 지를 결정하기 위해 사용자, 고객, 또는 권한을 가진 사람이 수행할 수 있는 정형 테스팅 | CMMI® |
| 인스펙션 | inspection | 표준이나 명세서에 대한 편차와 에러를 포함한 결함을 발견하고 식별하기 위해 작업 산출물에 대해 수행하는 검사 | ISO 8402-1995 |
| 인정 | Recognition | 팀 또는 개인이 조직에게 가치 있는 성과를 기여했을 때 팀 또는 개인에게 주어지는 특별한 감사를 통해 이루어진다. | People CMM |
| 인터뷰 | interview | 이해당사자들과 직접적인 대화를 통하여 요구사항을 추출하는 가장 직접적인 기법이며 요구사항 추출단계에서 정보 수집을 위해 사용되는 가장 일반적인 기법이다. 인터뷰기법은 이해당사자들의 관점을 충분히 반영할 수 있고, 인터뷰를 진행하는 동안 질문자와 답변자간에 빠른 피드백이 가능하여 현문제와 그에 따른 해결책에 대한 이해를 공유할 수 있다는 장점을 갖는다. | 소프트웨어 개선 센터, 요구사항 관리(RM)지침서, 한국과학기술원(KAIST), 2004 |
| 인터페이스 완전성 | Interface Completeness | 제품 구성요소의 인터페이스의 기술서에 빠지거나 부족한 부족한 부분이 없는 것 | Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI : Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003 |
| 일회용 프로토타입 | throwaway prototype | 요구사항과 설계 대안을 분류하고 검증하는 목적을 달성한 후에는 폐기할 의도로 만들어진 프로토타입 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 작업 구조 분해 | WBS | 종합적으로 작업을 정의하고 관리 가능한 작업의 세부 단위로 분할을 가능하게 하는 기법이다. WBS는 프로세스나 제품의 구성요소를 구조적으로 표현하기 위한 방법으로 현재 대표적인 프로젝트 관리 도구의 하나로 여겨지고 있다. 프로젝트 관리에서 사용되는 WBS는 프로세스, 제품, 하이브리드 이렇게 세가지 유형으로 분류된다. | Richard E. Fairly and Richard H. Thayer, “Work Break Structures”, Software Project Management, IEEE Computer Society Press, 2000. |
| 작업그룹 | working group | 규모가 큰 그룹은 의욕과 능력 면에서는 규모가 작은 그룹보다 유리하지만 잘 정리된 결론을 이끌어내기에는 매우 힘들다는 단점을 갖는다. 이럴 경우 소규모의 작업그룹으로 나눈다. | 전산용어사전편찬위원회, 컴퓨터 인터넷?IT 용어대사전, 일진사, 2005 |
| 작업산출물 | Work Product | 활동과 태스크의 결과는 주로 소프트웨어 작업산출물이다. 소프트웨어 작업산출물은 소프트웨어 프로세스를 정의하고 유지하고 사용하는 과정에서 생성된 모든 산출물이다. 여기에는 프로세스 기술, 계획, 절차, 컴퓨터 프로그램, 관련 문서 등이 포함될 수 있다. 작업산출물은 프로세스에서 다음 단계의 입력이 되고 미래 프로젝트에서 사용하기 위해 소프트웨어 프로젝트에 대한 정보를 저장한다. | Royce, W.W., Managing the Development of Large Software Systems: Concepts and Techniques, Proc. 1970 WESCON Technical Papers, Vol. 14, 1970 |
| 컨텍스트 다이어그램 | context diagram | 추상적인 차원에서 시스템을 묘사하는 분석으로 모델 컨텍스트 다이아그램은 시스템과 상호작용하는 외부의 개체를 파악하지만, 시스템의 내부 구조 또는 동작에 대해서는 어떤 것도 보여주지 않는다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 컴포넌트 | 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 |
| 코코모 | COCOMO | Barry Boehm이 처음 발표한 COCOMO(constructive cost model)는 1980년대의 대표적인 매개변수 비용 산정 모형 중 하나이다. | 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 |
| 클래스 | class | 공통의 속성과 동작을 가지는 개체집합에 대한 설명으로, 일반적으로 비즈니스 또는 문제영역의 실제 환경 항목(사람, 장소, 물건) 에 대응된다. | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 클래스 다이어그램 | class daigram | 시스템 또는 문제영역의 클래스 집합과 그 관계를 보여주는 분석 모델 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 타당성 분석 | 프로젝트 계획의 정확성과 현실성을 평가하는 것이다. 프로젝트 계획이 타당하기 위해서는 프로젝트의 세부 계획들이 모두 기술적으로 실현 가능해야 하고 서로들간에 모순이 없어야 한다. | ||
| 태스크 | task | 수행되어야 할 작업은 태스크로 나누어진다. 태스크는 프로젝트의 상태에 대한 가시적인 체크포인트로 관리를 제공하는 소프트웨어 프로세스에서 잘 정의된 단위 작업이다. 태스크는 준비 기준(선조건)과 완료 기준(후조건)을 가지고 있다. | Fairley, R.E. and R.H. Thayer, “Work Breakdown Structure,” Software Engineering Project Management, 2nd ed., R.H. Thayer, ed., IEEE Computer Society Press, Los Alamitos, Calif., 1997 |
| 테스트 | test | 시스템이 정해진 요구를 만족하는지, 예상과 실제 경과가 어떤 차이를 보이는지 수동 또는 자동 방법을 동원하여 검사하고 평가하는 과정 | IEEE Std 829, "IEEE Standard for Software Test Documentation", 1983 |
| 테스트 계획 | test plan | 테스트 범위, 접근 방법, 자원, 테스트 스케줄 등의 테스트 관련 정보를 포함하는 문서 | IEEE Std 1012, "IEEE Standard for Software Verification and Validation, March", 1998 |
| 테스트 교육 | test training | 테스트 활동과 관련된 교육내용 혹은 관련 활동 | SW-TMM |
| 테스트 그룹 | test group | 소프트웨어 개발자와 독립적으로 테스트 케이스 및 테스트 절차를 준비하고 실행하는 책임을 가지는 사람들의 모임 | IEEE Std 829, "IEEE Standard for Software Test Documentation", 1983 |
| 테스트 기법 | test technique | 테스트 데이터를 선정하기 위한 기법 | SW-TMM |
| 테스트 대상 | test object | 요구사항과 관련하여 소프트웨어 요구명세서의 명시된 조건하에 측정되어야 할 소프트웨어 구성 요소 및 특징 | IEEE Std 1008, "",1987 |
| 테스트 메트릭 | test metric | 주어진 속성 내에서 어느 정도의 역량을 가지는지를 정량적으로 측정하는 수단 | |
| 테스트 설계 | test design | 소프트웨어 특성에 맞도록 관련 테스트의 명세 정보를 문서화 하는 것 | IEEE Std 610.12 "IEEE Standard for Glossary of Software Engineering Terminology",1990 |
| 테스트 절차 | test procedure | 해당 테스트의 셋업, 실행, 결과분석과 같은 세부 지침 사항을 정리한 것 | |
| 테스트 조직 | test organization | 테스트 관련 활동을 수행하고 모니터링 하는 조직 | |
| 테스트 커버리지 | test coverage | 테스트 수행 결과가 요구사항에 부합하는지를 결정하기 위한 기준 | IEEE Std 610.12 "IEEE Standard for Glossary of Software Engineering Terminology",1990 |
| 테스트 프로세스 | test process | 테스트 수행시 필요한 테스트 관련 활동, 환경 등의 조합 | IEEE Std 1012, "IEEE Standard for Software Verification and Validation, March", 1998 |
| 테스트 활동 | test activity | 테스트를 실행하거나 계획할 때 수행하는 관련 활동들의 조합 | |
| 테스트가능성 | testability | 시스템이나 컴포넌트의 구성 요소 중 어떤 것이 테스트 할 만한 것들인지를 결정하는 작업 | |
| 테스트데이터 | test data | 테스트하고자 하는 소프트웨어의 의미있는 입력 데이터 | TMM |
| 테스트케이스 | testcase | 테스트 입력물, 실행 조건, 특정 목적에 기대 되는 결과값 등의조합 | IEEE Std 610, "", |
| 템플릿 | template | 완벽한 문서 또는 다른 항목을 만드는 가이드로 사용될 패턴 | Karl E. Wiegers, Software requirements, Microsft, 2003 |
| 통합 계획 | Integrated Plan | 프로젝트 수행에 필요한 다양한 활동들에 대한 계획의 통합을 의미한다. 프로젝트 계획, 구매 계획, 형상관리 계획, 위험 계획, 품질 계획 등이 포함된다. | |
| 통합 제품 및 프로세스 개발 | IPPD(Integrated Product and Process Development) | 제품 개발에 필요한 모든 핵심 요소들을 동시에 통합하여 설계, 제조, 지원 프로세스를 최적화하는 관리 기법을 말한다. 즉 제품 컴포넌트 별로 그 완수에 필요한 모든 관련 당사자들이 하나의 팀으로 구성된 통합팀이 구성되고 이들이 맡은 산출물을 개발해내는 제품 개발 전략이다. IPPD는 제품 개념 확립 단계부터 생산 단계에까지 걸쳐서 비용과 품질 목표를 만족시키는 것을 촉진한다. | DoD Guide to Integrated Product and Process Development |
| 통합 테스트 | integration test | 소프트웨어 컴포넌트 간 혹은 하드웨어와 소프트웨어간의 인터랙션 활동을 대상으로 수행되는 테스트 | IEEE Std 1012, "IEEE Standard for Software Verification and Validation, March", 1998 |
| 통합업무환경 | Integrated Work Environment | IPPD의 효율적인 수행에 필요한 협력과 동시 개발을 가능케 하는 업무환경. 구축된 통합 업무환경은 사람들이 제품, 프로세스, 요구 사항에 대해 효과적이고 명확하게 의사 소통할 수 있게 해야 하며, 비즈니스 부서와 기술 부서간, 그리고 팀, 프로젝트, 조직간의 통합을 지원해야 한다. | CMMI |
| 통합팀 | Integrated team | 통합팀은 시기 적절한 협력으로 주어진 작업 산출물 완성을 위해 총력을 다하는 상호 보완적인 기술과 지식을 가진 사람들로 구성된다. 통합팀의 팀원들은 작업 산출물 생명 주기의 각 단계에서 필요한 기술과 의견을 제공하며 작업 산출물을 완성하는데 공동으로 책임이 있다. 통합팀은 작업산출물과 관련된 조직, 적용분야, 직능영역으로부터 적절한 권한을 부여 받은 대표를 포함해야 한다. | CMMI : Guidelines for Process Integration and Product Improvement |
| 팀 헌장 | Team charter | 팀 헌장은 임무를 달성하기 위해 제공되는 권위, 자원뿐만 아니라 팀의 임무의 명확한 기술이다. 팀 헌장은 보통 임무 기술, 목적, 또는 작업 기술, 권위, 한계 조건(범위, 제한사항, 자원, 일정), 팀원, 요구사항 또는 명세등을 포함한다. 헌장은 팀을 올바른 방향으로 이끌 수 있도록 구체적이어야 하나 너무 제한적이어서도 안된다. 팀이 일단 작업의 범위를 이해 하면 좀더 구체적인 목표를 설정할 것이며 초기 헌장은 스폰서와의 협의 아래 변경될 것이다. | DoD Guide to Integrated Product and Process Development |
| 형상 감사 | Configuration Audit | 실제 형상 항목들이 요구되는 물리적, 기능적 특성을 어느 정도까지 반영하는지 확인하기 위해 감독하고 검사하는 일련의 활동 | IEEE Standard Glossary of Software Configuration Management Plans(IEEE std-828-1990), IEEE Standards Collection (Software Engineering), Piscataway, NJ:IEEE, 1997 |
| 형상 관리 | Configuration Management | 시스템 형상 요소의 기능적 특성이나 물리적 특성을 문서화하고 그들 특성의 변경을 관리하며, 변경의 과정이나 실현 상황을 기록·보고하여 지정된 요건이 충족되었다는 사실을 검증하는 것, 또는 그 과정 | IEEE Standard Glossary of Software Engineering Terminology(IEEE std-610-1990), 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 |
| 형상 상태 보고 | Configuration Status Account | 형상 항목의 상태를 기록하고 보고하는 일련의 활동 | IEEE Standard Glossary of Software Configuration Management Plans(IEEE std-828-1990), IEEE Standards Collection (Software Engineering), Piscataway, NJ:IEEE, 1997 |
| 형상 식별 | Configuration Identification | 시스템을 구성하는 형상항목을 선별하여 기능적, 물리적 특성을 기술적으로 문서화 하는 활동 | IEEE std-828-1990 |
| 형상 통제 | Configuration Control | 형상 항목이 공식적으로 식별된 뒤에 형상 항목에 대한 변경을 평가, 조정, 승인 또는 기각, 적용하는 일련의 활동으로 정보의 변경을 통제하는 활동 | IEEE Standard Glossary of Software Configuration Management Plans(IEEE std-828-1990), IEEE Standards Collection (Software Engineering), Piscataway, NJ:IEEE, 1997 |
| 형상관리 위원회 | Configuration Control Board | 형상 항목의 변경 제어에 대한 전체적인 책임을 갖는 조직 | IEEE Standard Glossary of Software Configuration Management Plans(IEEE std-828-1990), IEEE Standards Collection (Software Engineering), Piscataway, NJ:IEEE, 1997 |
| 형상항목 | configuration item | 다른 시스템 구성요소와는 따로 개발되거나, 구입되거나, 제어되거나, 유지보수되는 시스템 구성요소 | ISO 8402-1994 |
댓글
댓글 쓰기