기출문제풀이 요구공학 프로세스

7장 요구공학 프로세스

7장 Software Requirements

 

목표 : 시스템 요구사항 문서를 생성하고 관리하는 것

 

전체 프로세스는 4단계로 분리

1. 타당성 조사 (시스템이 비즈니스에 유용한지 평가)

2. 추출과 분석 (요구사항을 발견)

3. 명세화 (발견된 요구사항을 표준 형태로 변환)

4. 검증 (요구사항이 사용자가 원하는 시스템인지 검증)

 

요구 공학 프로세스에 대한 나선형 모델 - 3단계

1. Requirements specification (소프트웨어 명세)

2. Requirements validation (소프트웨어 검증)

3. Requirements elicitation

 

1. 타당성 조사

타당성 조사의 결과는 요구 공학과 시스템 개발 프로세스를 수행하는 것이 가치있는것인지

타당성 조사는 간결하고 다음과 같은 질문에 답을 하는 것에 초점을 맞춘다

1. 시스템이 조직의 전체 목표에 공헌을 하는가?

2. 시스템이 현재의 기술과 주어진 예산과 일정 내에서 개발될 수 있는가?‘

3. 시스템이 현재 사용되고 있는 다른 시스템과 통합될 수 있는가?

 

타당성 조사의 수행 : 정보평가->정보수집->보고서 작성 (2-3주내 완료)

 

즉, 타당성 조사는 개발하려는 시스템이 시간과 노력을 투자하여 개발할 만한 가치가 있는 것인지, 주어진 예산안에 개발될 수 있는 것인지, 현재 사용되고 있는 시스템의 대체용으로 개발된다면, 그 시스템과 통합이 될 수 있는 것인지 등에 대한 조사로서 개발하려는 시스템의 타당성을 조사하는 것이다.

 

2. 요구사항 추출 및 분석

조직의 다양한 부류의 사람이 참여한다. 참여자(Stakeholder)라는 용어는 시스템에 의해서 직접, 간접적으로 영향을 받은 사람을 의미한다.

 

요구사항 이해와 추출의 어려움

1. 일반적인 용어를 제외하고는 시스템으로부터 요구하는 것이 무엇인지 모른다.

2. 참여자는 자기들의 용어로 요구한다. -> 엔지니어는 경험없이 이해해야 한다.

3. 정치적 요소가 요구사항에 영향을 미칠 수 있다.

4. 분석이 이루어지는 동안 요구사항의 중요성이 변한다. 즉, 새로운 요구사항이 애초에 관여하지 않았던 새로운 참여자로부터 나올 수 있다.

요구사항 추출/분석 프로세스

1. 요구사항 발견 (요구사항을 모으기 위해 참여자와 대화)

2. 요구사항 분류와 구성 (모아진 요구사항을 분류하고 구성)

3. 요구사항 우선순위 설정과 협상 (상충되는 요구사항의 우선순위를 부여하고 협상)

4. 요구사항 문서화 (요구사항은 문서화 되고 다음 단계로 진입)

-> 나선형의 사이클을 통하여 계속적인 피드백을 받고 증진된다.

 

시나리오

1. 시나리오가 시작 되었을 때 시스템과 사용자가 기대하는 것에 대한 기술

2. 시나리오 내에서 사건의 정상적인 흐름

3. 잘못될 경우와 그에 대한 대처 방안

4. 동시에 진행될 수 있는 다른 활동에 관한 정보

5. 시나리오가 끝났을 때 시스템에 관한 사항

 

민속학(Ethonography)

민속학은 다음과 같은 두 가지 유형의 요구사항을 발견하는데 특히 효과적이다

1. 사람들이 실제로 작업하는 방식으로부터 요구사항을 유도한다.

2. 다른 사람들의 활동을 인식하여 협력하는 것으로부터 요구사항을 유도한다.

 

3. 요구사항 검증

요구사항 검증은 요구사항이 실제로 고객이 원하는 바를 정의했는지를 보이는 것과 관련

(요구사항 문서에 있는 요류가 시스템을 개발하거나, 시스템이 서비스 중일 경우에 발견되면 방대한 재작업 비용이 들기 때문에 중요-시스템 설계와 구현 또한 변경되어야 하고 시스템을 다시 시험해야 하기 때문)

 

요구사항 검증 리스트

1. 유효성 점검(validity checks) : 사용자가 초기에 요구한 것과 다를 수 있다.

2. 일관성 점검(consistency checks) : 요구사항 끼리 상충되지 않아야 함. 모순이 되는 제약조건이나 같은 시스템 기능에 대한 기술을 포함하면 안됨

3. 완전성 점검(completeness checks) : 모든 기능을 정의하고 제약조건을 포함해야 함.

4. 실현성 점검(realism checks) : 기존 기술을 사용하여 요구사항이 실현될 수 있는가

5. 증명 가능성(verifiability) : 분쟁에 대한 소지를 줄이기 위하여 문서로 작성하여 증명가능 해야 함

 

※ 프로토타이핑 : 시스템의 실행가능한 모델을 최종 사용자와 고객에게 보여주는 것이다.

 

4. 요구사항 관리(변경 등)

문제에 대한 사용자 요구사항은 끊임없이 나타나며, 일단 시스템이 설치되면 새로운 요구사항이 필연적으로 나타난다.

문제분석과 변경 명세화 -> 변경 분석과 비용 산정 -> 변경 구현

 

진화적인 관점에서 요구사항은 두 가지 종류로 나뉘어진다.

1. 지속적 요구사항

- 이것은 조직의 핵심 활동이나, 시스템의 도메인과 직접적으로 관련된 비교적 안정적인 요구사항이다.

2. 비지속적(일시적) 요구사항

- 이것은 시스템 개발 프로세스 동안이나 시스템이 운영을 시작한 후에 변경될 수 있는 요구사항이다. 소프트웨어에 내제된 제약이 사회적인 시스템으로부터 유도된 것이라면 이 제약이 변경되었을 경우에 발생하는 요구사항이다.

8장 시스템 모델

8장 System Models

 

시스템 모델의 3가지 관점

1. 외부 관점 2. 행위 관점 3. 구조적 관점

 

시스템 모델의 가장 중요한 측면 - 상세한 내용을 다루지 않는다(추상적 표현)

 

분석 프로세스에서 생성될 수 있는 시스템 모델의 유형의 예

1. 데이터 흐름 모델 : 어떻게 데이터가 시스템에서 단계별로 처리되는 가를 보여준다.

2. 결합 모델 : 시스템에 있는 개체가 어떻게 다른 개체와 결합되는지를 보여준다.

3. 아키텍처 모델 : 시스템을 구성하는 중요한 서브시스템을 보여준다.

4. 분류 모델 : 객체 클래스/상속 다이어그램은 개체의 공통 특성을 보여준다.

5. 자극-반응 모델 : 상태 전이 다이어그램은 시스템이 내부 이벤트 및 외부 이벤트와 반응하는지를 보여준다.

 

1. 배경 모델(Context models)

어떤 것이 시스템이고 어떤 것이 시스템의 환경인지를 구분해야 한다.

아키텍처 모델을 통하여 시스템의 배경을 기술 한다(전체적인 구조)

 

2. 행위 모델(Behavioural models)

행위 모델은 시스템의 전체 행위를 기술하는데 사용된다.

2.1. 데이터 흐름 모델 : 시스템에서 데이터 처리를 위함

분석 단계에서 데이터가 기존 시스템에서 어떻게 처리되는가에 대한 방법을 모델링

하향식 프로세스

2.2. 상태 기계 모델 : 시스템이 어떻게 내/외부 이벤트에 반응하는지 나타냄

한 상태에서 다른 상태로 전이하는 시스템의 상태와 이벤트를 보여준다.

 

3. 데이터 모델(Data models)

시스템에서 처리될 데이터의 논리적 형태를 정의 -> 의미적 데이터 모델

가장 널리 사용되는 데이터 모델 : ERA모델링(데이터 개체, 그들과 관계된 속성과 개체사이의 관계를 나타낸다)

UML은 객체지향 개발 프로세스에서 사용되나 이 모델을 여기에서 사용할 수도 있다.

상세하지 않게 기술한다.

데이터 사전(Data Dictionary) : 시스템 모델에 포함된 이름의 리스트

이름 뿐 아니라, 개체와 관계된 설명을 포함한다.

장점

- 이름을 체계적으로 관리할 수 있게 해 준다 : 유일성 검사->중복 제거

- 조직 정보의 저장소로 사용될 수 있다 : 시스템이 개발됨에 따라, 분석, 설계 구현, 진화를 연결시키는 정보가 데이터 사전에 추가되어 개체에 관한 모든 정보가 한곳에 모인다.

4. 객체 모델(Object models)

- 전체 소프트웨어 개발 프로세스에서 객체지향 방법이 공통적으로 사용되는데, 특히 대화형 시스템 개발에 자주 사용된다.

- 객체 모델은 시스템에 있는 개체가 어떻게 분류되고 다른 개체와 어떻게 구성되는 지를 보여주는 데 사용된다.

- 객체 클래스는 공통의 속성과 각 객체에 의해서 제공하는 오퍼레이션 혹은 서비스를 가진 객체의 집합에 대한 추상화이다.

- 상속 모델

객체 클래스가 공통적인 속성과 서비스에 의해 다른 클래스와 관련이 있는지 보여줌

가장 일반적인 객체 클래스를 계층의 맨 위에 놓는다. 좀 더 구체적인 객체는 그들 자신의 속성과 서비스를 가진다. 이러한 구체화된 객체는 그들 자신의 속성과 서비스를 가진다.

위로가면 일반화, 아래로 가면 구체화(실체화)

- 다중 상속의 문제점

객체가 상속 받지 않아도 되는 불필요한 속성이 있는 상속이 행해질 수 있다.

같은 이름이지만 다른 의미의 속성를 가진 이름들의 충돌 해결 문제

- 객체 집합

객체는 다른 객체로부터 상속 관계를 속성과 서비스를 받음과 동시에 다른 객체의 그룹이 될 수 있다.

- 객체 행위 모델

객체에서 제공된 오퍼레이션이 어떻게 사용되는가

 

5. 구조적 방법(Structured method)

- 만들어질 시스템 혹은 기존 시스템의 모델을 만드는 체계적인 방법

구조적 방법은 요구사항 추출과 분석의 일부분인 상세 시스템 모델링에 대한 틀을 제공

장점 : 표준 기호를 사용하고 표준 설계 문서가 만들어지는 것이 확인됨

단점

1. 비기능적 시스템 요구사항을 이해하거나 모델링하는데 효율적인 지원이 안됨

2. 어떤 문제가 특정 문제에 대해 적절한 지를 사용자가 결정하는데 도움이 안됨

3. 너무나 많은 문서를 생산(상세한 사항 때문에 본질이 감추어짐)

4. 만들어진 모델이 너무 상세하여 사용자가 이해하기 힘들다.

11장 아키텍처 설계

11장 Architectural design

 

14장 객체지향 설계

14장 Object-oriented Design

 

객체지향 시스템은 자신의 상태를 관리하고 그 상태에 오퍼레이션을 제공하는, 상호작용하는 객체들로 구성된다. 상태의 표현은 공개되지 않으므로 객체 외부에서 직접 접근할 수 없다.

 

객체지향 분석 : 개체와 오퍼레이션을 분석하고 식별한다.

객체지향 설계 : 식별된 요구사항을 구현하기 위해 시스템의 객체지향 모델을 개발한다.

객체지향 프로그래밍 : Java와 같은 객체지향 언어를 사용하여 소프트웨어를 실제 구현한다.

 

객체지향 시스템은 객체들이 독립적이기 때문에 다른 접근법을 사용하여 개발된 시스템보다 변경하기가 용이하다.

또한 잠재적으로 객체들은 상태와 오퍼레이션들의 독립적인 캡슐화이기 때문에 재사용 가능한 컴포넌트이다.

또한 표준 객체의 이용을 유도할 수 있고 소프트웨어 개발에 내재된 위험을 줄인다.

 

유즈케이스 이용

- 설계가 분명히 사용자 중심이고 사용자와 시스템과의 상호작용에 기반을 둔다는 의미

 

객체는 상태와 그 상태에 적용되는 오퍼레이션들의 정의된 집합을 가지는 개체이다. 상태는 객체들의 속성들의 집합으로 표현된다. 객체에 연관된 오퍼레이션들은 어떤 연산이 요구될 때 서비스를 요청하는 다른 객체(클라이언트)들에게 서비스를 제공한다.

 

객체들 사이의 통신은 동기적이나, 객체들이 병행 프로세스나 스레드로 구현된다면 객체들 사이의 통신은 비동기적일 수 있다.

 

객체 클래스의 멤버로 객체 클래스를 사용할 수 있다. 멤버 객체는 다른 객체와 관계를 맺고 있다. 이런 관계는 객체 클래스 사이의 연관으로 모델링 할 수 있다.

 

능동 객체(active object) : 객체의 상태가 객체 자신을 실행시키는 내부 오퍼레이션에 의해서 변경될 수 있다. 객체를 나타내는 프로세스는 이러한 오퍼레이션을 계속해서 실행하므로, 객체 자신을 결코 중단시키지 않는다.

 

객체지향 설계 프로세스

1. 시스템 배경(context)과 시스템 사용에 대한 모델을 이해하고 정의한다.

2. 시스템 구조를 설계한다.

3. 시스템의 주요 객체를 식별한다.

4. 설계 모델을 개발한다.

5. 객체 인터페이스를 명세화 한다.

시스템과 환경과의 상호작용을 모델링할 때에는, 상호작용에 대해 너무 상세한 내용을 포함하지 않는 추상 기법을 사용해야 한다. (유스케이스 모델 개발)

객체지향 설계를 나타내게 위해 보통 생성해야 하는 두 가지 유형의 설계 모델이 있다.

- 정적 모델 : 시스템의 정적인 구조를 시스템 객체 클래스와 객체 클래스간의 관계로서 묘사

- 동적 모델 : 시스템의 동적인 구조를 묘사하고, 시스템 객체 사이의 상호작용을 보여줌

 

서브시스템 모델 : 객체들을 논리적으로 그룹화 하여 서브시스템으로 보여준다. 서브시스템 모델은 각 서브시스템이 패키지로 표현되는 클래스 다이어그램 형식으로 나타낸다(동적)

순차모델 : 객체 상호작용의 순서를 보여준다.(동적)

상태기계모델 : 개별적인 객체가 이벤트에 응답하여 자신의 상태를 바꾸는 방법을 보여줌(동적)

 

객체 인터페이스 명세

- 설계 구성 요소들 사이의 인터페이스를 명세화, 각 객체들과 서브시스템들이 병행해서 설계될 수 있도록 인터페이스를 명세화 한다.

17장 신속한 소프트웨어 개발

17장 Rapid Software Development

 

소프트웨어는 모든 비즈니스 운영의 일부이므로 새로운 기회가 가지는 장점을 획득하고 경쟁에 의한 압력에 대처하기 위해 새로운 소프트웨어를 빠르게 개발하는 것이 필수적

신속한 소프트웨어 개발 프로세스는 유용한 소프트웨어를 빠르게 작성하기 위해 고안됨

-> 요구분석, 설계, 개발, 시험이 서로 중첩된 반복적인 프로세스이다. 소프트웨어가 전체적으로 개발되어 설치되는 것이 아니라 각 증분(increment)이 새로운 기능을 가지는 일련의 증분들이 개발되어 설치된다.

 

공통점

1. 요구분석, 설계, 구현 프로세스가 동시에 진행

2. 시스템은 일련의 증분으로 개발된다.

3. 시스템 사용자 인터페이스는 대개 대화식 개발 시스템을 이용하여 개발

대화식? - 인터페이스 설계를 그림으로 그리고 인터페이스에 아이콘을 위치시킴으로서 빠르게 생성할 수 있다.

장점

1. 고객 서비스의 신속한 인도

- 우선순위가 높은 순서대로 고객에게 전달된다. 고객은 자신의 요구사항을 실제로 볼 수 있고 시스템 후반부의 릴리스에 수용될 변경을 명세화 할 수 있다.

2. 사용자가 시스템 개발에 참여

- 인도된 증분에 대한 피드백을 개발팀에게 제공하므로 최종 결과물의 질이 상대적으로 우수

 

프로세스

시스템 요구분석 -> 시스템 설계 -> 증분 명세화 -> 증분 개발 -> 증분 검증

yes ↑no ↓

최종 시스템 인도 <- 시스템 완료? <- 시스템 검증 <- 증분 통합

 

문제점

1. 관리문제 : 점증적으로 개발되는 시스템은 너무 빨라서 문서를 생성하는 것이 비효율적

2. 계약문제

3. 검증문제 : 증명과 검증(v&v)의 독립이 힘들다

4. 유지보수문제 : 게속적인 변경은 시스템의 구조를 변형/파괴 시킨다.

 

프로토타이핑 : 고객이 의도하는 개발이 아닌 실험적인 시스템을 개발하는 반복적인 프로세스를 의미하기 위해 사용. 소프트웨어 개발자와 고객이 무엇이 개발되는지 이해하는 것을 돕기 위해 시스템 프로토 타입이 개발된다.

진화되는 프로토타이핑 : 점증적인 소프트웨어 개발의 동의어로도 사용되며, 프로토타입이 폐기되는 것이 아니라 고객의 요구사항을 만족하기 위해 진화된다.

※ 잘 동작되는 시스템을 최종적으로 전달해야 하므로, 가장 높은 우선순위를 가진 사용자 요구사항을 가지고 시작해야 한다는 의미가 됨.

쓰고 버리는 프로토타이핑(throw-away prototyping)의 목표 : 시스템 요구사항을 검증하거나 유도하는 것. 잘 이해되지 않는 요구사항을 가지고 시작해야 한다. 이유는 요구사항에 관한 더 많은 것을 발견할 필요가 있기 때문

 

1. 애자일 방법(Agile method)

- 설계와 문서화 보다는 소프트웨어 자체에 초점을 맞춘다. 반복적인 접근법에 의존하며 동작 가능한 소프트웨어를 고객에게 빠르게 인도하기 위한 것이 최종 목표. 고객은 그 다음에 새로운 요구사항과 변경된 요구사항이 시스템의 후반부 반복에 포함되도록 제안 가능 하다.

2. 익스트림 프로그래밍(eXtreme Programming)

- 가장 잘 알려져 있고 가장 널리 이용되는 애자일 기법

- 반복적인 개발과 같이 인식된 좋은 실무관행과 고객의 참여를 극한(extreme) 수준까지 밀고 나가기 때문

- 페어프로그래밍(pair-programming)

장점 : 검증에 근거한 프로그래밍이 가능해지므로, 오류를 줄이고 문제 해결에 도움이 된다, 교육의 효과가 있다. 관리상의 리스크를 줄일 수 있다. 실험 결과로 15%의 시간적 오버헤드가 발생하나, 15%의 버그를 줄일 수 있다. 서로가 서로에게 테스터가 될 수 있다.

단점 : 초보자를 너무 거만하게 키울 수 있다. 조금 실력 있는 사람을 실험해 보려고 pair-programming에 투입하는 부작용이 발생할 수 있다. 하나의 문제에 대한 해결방안을 두고서 다툼이 발생할 수 있다.

- XP에서의 시험

반복적인 개발과, 계획-기반의 개발 사이의 중요한 차이점 중의 하나가 시스템이 시험되는 방식에 있음. 반복적인 개발에서, 외부 시험팀이 시스템 시험을 개발하기 위히 사용할 수 있는 시스템 명세서가 존재하지 않는다.

XP는 다른 애자일 기법보다 시험 프로세스를 더 강조한다.

1. 시험 우선 개발 - xp의 가장 중요한 혁신 중 하나임

2. 시나리오로부터 점증적인 시험 개발

3. 시험 개발가 검증에 사용자 참여

4. 자동화된 시험 장치의 사용

시험을 먼저 작성하면, 개발중인 기능에 가한 인터페이스와 동작 명세서 모두를 묵시적으로 정의하게 된다. 따라서 요구사항과 인터페이스를 잘못 이해하는 문제점 감소

 

 

3. 신속한 응용시스템 개발(Rapid application development) - RAD

- RAD 환경에 포함되는 도구

- 데이터베이스 프로그래밍 언어 : DB를 조직하고 SQL을 통해 데이터에 대한 연산 용이

- 인터페이스 생성기 : 입력과 표시를 위한 폼을 손쉽게 생성(또다른 면의 Resue)

- 오피스 응용 프로그램과 연결 : 수치정보 분석과 조작을 위한 스프레드시트 또는 보고서 템플릿 생성을 위한 워드프로세서와 같은 오피스 응용 프로그램과의 연결

- 보고서 생성기 : 데이터베이스에 있는 정보로부터 보고서를 정의하고 생성하는데 이용

RAD 시스템의 성공적인 이유

- 비즈니스 응용 시스템 간에 많은 공통점 존재

 

현재 대부분의 RAD 시스템은 시스템을 대화식으로 개발할 수 있도록 하는 비주얼 프로그래밍 도구를 포함한다(재사용 포함). 재사용 가능한 컴포넌트를 이용하여 화면, 필드 버튼 등을 통하여 인터페이스를 정의하여 시스템을 대화식으로 구축한다.

 

시각적 개발(visual development)

- 단위가 작은 재사용 가능 소프트웨어 컴포넌트 통합에 의존하는 RAD기법. 때로는 COTS 기반 개발이라 부르기도 한다(COST : Commercial Off-the-Shelf : 상용 기성품), 장점은 많은 응용 시스템의 기능이 매우 낮은 비용으로 구현될 수 있다는 점.

 

4. 소프트웨어 프로토타이핑(Software Prototyping)

- 프로토타입은 개념을 나타내고, 설계 선택 방안을 시험하고, 일반적으로 문제점에 대한 해결책을 찾기 위해 사용하는 소프트웨어 시스템의 초기 버전이다.

- 이용 방법

1. 요구공학 프로세스에서 시스템 요구사항의 유도와 검증을 도움

2. 특정 소프트웨어 해결책을 조사하고 인터페이스 설계를 지원

3. 고객에게 인도될 시스템을 가지고 연속적인 시험을 실시하기 위해 사용될 수 있음

- 장점

1. 개선된 시스템 유용성

2. 시스템과 사용자 요구와의 밀접한 일치

3. 개선된 설계 품질

4. 개선된 유지보수성

5. 감소된 설계 노력

18. 소프트웨어 재사용

18. Software Resue

이미 다른 시스템에서 시도되고 시험된 컴포넌트에 기초하여 개발 프로세스가 기존의 소프트웨어를 재사용하는 전략, 소프트웨어 제작 및 유지보수 비용의 절감, 시스템의 더 빠른 인도와 소프트웨어 품질 향상

1. 응용 시스템 재사용

2. 컴포넌트 재사용

3. 객체와 함수 재사용

장점 : 전체적인 개발 비용 감소, 신뢰성의 증가, 프로세스 위험의 감소, 전문가의 효과적인 이용, 표준의 준수, 개발 속도의 증가

단점 : 재사용에 적합한 컴포넌트인지의 여부를 이해하고, 해당 컴포넌트가 확실성을 보장하는지 시험하는데 관련된 중요한 비용이 존재함. 유지보수 비용의 증가, 도구 지원의 결여, NIH(Not invented here)증후군, 컴포넌트 라이브러리 생성과 유지, 재사용 가능한 컴포넌트의 검색, 이해, 수정

설계 패턴

- 실행 가능한 컴포넌트를 재사용 하려 할 때, 개발하려는 시스템과 컴포넌트 사잉의 인터페이스나 일부 설계 등의 충돌이 생길 수 있다. 이러한 경우 컴포넌트의 재사용은 불가능하거나 시스템에 비효율성을 야기하게 되므로, 세부 구현 내역을 포함하지 않는 추상 설계를 이용하는 것이다. “패턴과 패턴 언어는 최선의 실무 관행, 좋은 설계를 기술하고, 경험을 정리하여 다른 사람들이 경험을 재사용하는 것을 가능하게 하는 방안이다”

생성기 기반의 재사용

- 개념을 추상적으로 기술하고, 구현을 소프트웨어 개발자에게 맡긴다.

응용 프레임워크

- 프레임워크는 추상클래스와 구체클래스 그리고 이들간의 인터페이스의 모임으로 구성되는 서브시스템 설계이다. 프레임 워크의 모임->응용 시스템

- 프레임워크는 더욱 구체적인 서브시스템이나 응용 시스템을 생성하기 위해 확장될 수 있는 일반 구조이다.

응용 시스템 재사용

- 응용 시스템의 재사용은 새로운 응용 시스템을 생성하기 위해 특정 환경에 관해 시스템을 설정하거나 둘 이상의 시스템을 통합함으로써 전체 응용 시스템을 재사용하는 것을 포함

- 새로운 시스템을 생성하기 위해 빠르게 구성될 수 있는 단위가 큰 자산의 재사용을 포함

- COTS 제품 재사용

- 상용기성품은 구입자가 변경하지 않고 사용할 수 있는 소프트웨어 시스템이다. 실제로 모든 탁상용 소프트웨어와 매우 다양한 범위의 서버 제품들이 COTS소프트웨어이다.

- 문제점

1. 인터페이스는 필요한 기능을 제공하는 것처럼 보여도 잘못 구현/수행될 수 있다.

2. COTS 시스템의 상호 운영성 문제 : COTS 시스템 끼리의 통합이 어려움

3. 시스템 진화에 대한 제어 부재

4. COTS는 판매되는 제품이므로 문제 발견시 소스코드에 접근할 수 없다.

22장 증명과 검증

22장 Verification and Validation

 

- 구현 프로세스 동안, 그리고 그 이후에, 개발중인 소프트웨어가 명세서를 만족하고 소프트웨어의 비용을 지불하는 사람이 기대하는 기능을 인도하도록 보장하는지 점검해야 함.

- 증명과 검증(v&v)은 이러한 점검과 분석 프로세스에 주어진 이름이다. 증명과 검증은 소프트웨어 프로세스 각 단계에서 일어난다.

 

검증(validation) : 올바른 제품을 생성하고 있는가.

- 소프트웨어 시스템이 고객의 기대를 만족하는지 점검

증명(verification) : 제품이 올바르게 생성되고 있는가.

- 소프트웨어가 명세서와 일치하는지 점검(명세화된 기능적 요구사항 & 비기능적 요구사항)

 

즉, 증명의 역할이란 소프트웨어가 명세서와 일치하는지 점검하는 것을 포함한다.

소프트웨어가 명세화된 기능적 요구사항과 비기능적 요구사항을 만족하는지 점검해야 한다.

검증은 소프트웨어 시스템이 고객의 기대를 만족하는지 점검하는 것이다.

v&v의 목적 : 소프트웨어 시스템이 ‘목적에 적합하다’라는 신뢰를 형성