정보시스템 개론 시험문제 Pool

 

 

A-1.

A-1-1). System을 정의하시오.

 

시스템은 어떤 목적과 기능을 수행하기 위하여 유기적인 관계를 맺으며 힘께 작용하는 요소들의 집합.

 

A-1-2). 시스템공학과 소프트웨어공학의 차이점을 라이프사이클을 중심으로 설명하라.(이상)

시스템공학

  • 시스템분석 or 요구사항분석
  • 시스템설계
  • 시스템구현
  • 시스템테스트,
  • 시스템유지보수 

소프트웨어공학

  • 요구사항분석
  • S/W 설계
  • S/W 구현
  • S/W 시험(Testing)
  • S/W 유지보수

 

 

A-1-3). 객체지향과 구조적 방법론의 차이점을 시스템 관점에서 설명하시오.

 

각 객체지행 방법론은 시스템에 객체를 정의한다. 

객체 사이의 연관을 규명한다. 

각 시스템 요소들을 독립적이고 수평적인 관점에서 정의한다.

 

이에 반해, 구조적 방법론은 시스템을 기능 중심으로 파악한다.

그리고 각 기능을 세분화 시칸다.

즉, top-down 의 형태로 분석하는 것이 특징이다.

 

A-2. 소프트웨어 개발에 사용되는 대표적인 패러다임 4가지를 설명하고 각 패러다임의 단계별 활동을 설명하시오.

소프트웨어 개발에 사용되는 대표적인 패러다임 4가지는

폭포수 모델,

원형 패러다임,

나선형 패러다임,

4세대 기법이 있다.

 

폭포수 모델은 하향식 접근 방법을 이용한다.

 

원형 패러다임은 고객에게 간단한 시제품을 만들어서 보여주면서 진행 하는 것을 말한다.

 

나선형 패러다임은 시스템을 개발하면서 생기는 위험을 관리하기 위해

위험 분석 단계를 추가한 것이다.

 

4세대 기법은 CASE를 비롯한 자동화 도구들을 이용하여 요구사항 명세서로부터 실행 코드

자동으로 생성할 수 있게 하는 방법이다.

 

각 패러다임의 단계는 다음과 같다.

1. 폭포수 모델

1) 요구사항 분석 - 사용자 요구사항을 정의하기 위해 시스템의 요구사항을 모은다.

2) 설계 - 요구사항을 설계도면에 옮기는 것이며 설계 과정은 물리적 실현의 첫 단계이다.

3) 구현 - 구현은 앞의 설계 단계에서 나온 결과를 시스템의 실제 모습으로 변환시키는 것이다.

4) 시험 - 품질보증 활동의 중요한 일부분이며 사용자 요구사항, 설계, 구현의 전 과정에 대한 최종 점검을 포함한다.

5) 유지보수 - 사용중 발생하는 여러 변경 사항에 대해 적응하는 활동이며 변화에 대비하는 과정이다. 수정 유지보수, 적응 유지보수, 기능 추가 유지보수, 관리 유지보수 등 4가지로 나뉜다.

 

2. 원형 패러다임

1) 요구사항 분석 - 폭포수 모델의 요구사항 분석단계와 비슷하나 고객으로부터 받은 일부 요구사항만 정의하고 완전하지 않은 요구사항에 대해 윤곽을 잡아놓는다.

2) 시제품 설계 - 원형에 대한 설계를 한다.

3) 시제품 개발 - 시제품 개발.

4) 고객의 시제품 평가 - 이 단계에서 시제품은 고객에 의해 평가되고, 개발될 소프트웨어의 요구사항을 구체적으로 정제한다.

5) 시제품 정제 - 고객이 원하는 것을 만족시키기 위해 시제품에 대한 조율을 한다.

6) 완제품 생산 - 원하는 시스템을 개발. 기존의 시제품을 확장하여 완제품을 만들 것인지 시제품을 버리고 완제품을 만들 것인지 결정한다. 만약 시제품을 버리고 완제품을 만든다면 이 단계에서 완전한 폭포수 모델, 4세대 기법의 적용이 가능하다.

 

 

 

3. 나선형 패러다임

1) 계획 및 정의 - 요구사항을 모으고 프로젝트 계획을 수립한다.

2) 위험 분석 - 초기 요구사항에 근거하여 위험을 규명한다.

3) 개발 - 어떤 패러다임을 적용하여 시스템을 개발할 것인가 하는 개발 모델을 결정하고, 시제품을 개발하거나 최종 제품을 만든다.

4) 고객 평가 - 개발 과정에서 나온 결과를 사용자가 평가한다. 고객의 평가에 의해 다음 결과물이 계획된다.

 

 

 

4. 4세대 기법 - 단계 없음

 

 

A-3. 나선형 모델(spiral model)의 각 진행 과정에 대하여 설명하고, 프로토타입 기법과의 차이점을 설명하시오.

 

나선형 모델은 폭포수 모델과 원형 패러다음의 장점에 위험 분석을 추가하여 만든 것으로 나선형 모델은 나선을 돌면서 점진적으로 완벽한 모델을 구축하게 된다.

 

1) 계획 및 정의 단계에서 목표, 요구사항, 제약등을 규명

2) 위험 분석단계에서는 프로젝트의 중단을 결정한다.

3) 개발 단계에서 어떠한 패러다음으로 시스템을 개발할 것인지 결정해서 시제품을 만든다.

4) 고객 평가 단계에서 다음 나선의 목표 및 요구 사항이 반영된다.

 

겉으로 보기엔 비슷해 보이지만,

나선형 모델에는 위험 분석 단계가 들어가서 위험에 대한 평가가 가능해서 위험 분석을 필요로 하는 프로젝트에 적합하다.

 

A-4. 객체지향 질문

(a) 객체를 정의하고 객체지향을 설명하시오.

객체란 물리적으로 식별 가능한 것을 말한다,

 

객체의 표현은 두칸으로 이루어져 있는데, 첫째 칸은 객체를 구별할 수 있는 이름을 표시하고 둘째 칸은 각 속성에 대응하는 속성값을 표시한다.

 

 

객체 지향 방법론은 데이터행위를 하나로

묶어 객체를 정의내리고 객체를 추상화시키는 작업이다.

 

(b) 객체지향과 구조적 기법의 차이를 설명하시오.

[ 객채지향 방법론 ]

객체지향 방법은 시스템에 필요한 엔티티(객체)들을 정의하고

이들 엔티티 사이의 연관성을 규명.

시스템을 구성하고 있는 객체를 중심으로 객체의 특성을 정의.

시스템을 구성하는 요소들을 독립적이고 수평적인 관점에서 정의.

 

[ 구조적 방법론 ]

시스템을 기능 중심으로 파악하고 이를 세분화된 기능으로 나눈다.

시스템을 하향식(top-down)의 형태로 나타낸다.

 

(c) 개발 방법이 통합 기술이라는 이유를 설명하고 통합과정을 기술하시오.

객체지향 방법은 데이터와 행위를 통합하여 개발하기 때문에 통합 기술이라고 말한다.

또한 객체지향 방법은 소프트웨어 시스템의 3가지 관점을 체계적으로 통합하여

유연성과 적응력을 가진 우수한 품질의 소프트웨어를 만들 수 있는 최적의 방법으로 여겨진다.

 

객체지향 개발 방법의 통합 과정은 다음과 같다.

객체 모델(객체 규명 객체간의 관계 규명) +

동적 모델(객체의 행위와 상태를 규명) +

기능 모델(동적 모델에서 정의한 상태들의 동작들을 기술 한다.)

 

 

 

(d) 객체지향 개발 방법이 하향식 접근 방법을 택하는지 또는 상향식 접근 방법을 택하는지 (또는 혼합형인지) 그 이유를 들어 설명하시오.

객체지향 방법론은 객체 중심의 상향식 접근 방법이 도입된다. 객체지향 방법론은 기능 중심이 아닌 객체 중심, 데이터 중심으로 시스템 개발이 이루어진다.

 

 

A-5. 일정에 쫓기거나 눈 앞의 이익으로 인해 기술적 부채(technical debt)를 진 경험이 있으면 기술하시오. 또한 기술적 부채로 인하여 추후 새로운 기능을 개발하는데 어려움이 발생한 경험을 말하고 해결하려고 노력한 경험에 대하여 기술하시오.

 

A-6. 리팩토링(Refactoring)을 정의하고 기술적 부채(technical debt)와의 연관성을 설명하시오.

리팩토링- 소프트 웨어를 보다 쉽게 이해 할수 있고, 적은 비용을호 수정할수 있도로록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것.

 

동작의 변화없이 내부 구조를 수정할시 코드를 처음부터 다시 작성해야 할때는 하지 않는 것이 좋으며, 또한 마감일이 얼마 남지 않은 시점에서는 리팩토링을 기술적 부채 개념으로 생각해야 한다.

 

 

A-7. 애자일 기법이 프로토타입이나 나선형 모델과 다른 점을 설명하시오.

애자일 이 추구하는 목적은 고객개발 팀원들이 서로 끊임없이 교류를 통하여 변화에 빠르고 유연하게 대응해야 한다는 것이다.

 

하지만 나선형 모델은 소프트웨어를 개발하면서 발생할수 있는 위험을 관리하고 최소화하는 것을 목적으로 둠 반복적으로 개발을 지원하며프로토타이밍 기법을 이용한다. 나선형 모델은 중앙에서 시작하여 나선형으로 진행 되는 반복 진화형의 확장 형태임. 대형 소프트웨어에 적합하다. 이것이 애자일 기법과 다른 점이다.

 

나선형 모델은 프로젝트 수행시 발생하는 위험을 관리하고 최소화 하려는 목적을 가지지만, 애자일 방법은 품질의 저하 없이 변화를 수용하고 협업을 강조하고 '제품의 빠른 인도'를 강조하는 반복적 방법이다.

 

요구사항 분석

 

B-1. 분석과 설계 질문

(a) 분석과 설계의 차이점 기술.

분석: 요구사항을 세분화하고, 결과를 통합하여 원하는 시스템을 기술하는 것이다.What에 초점을 맞춘 단계이다.

설계: 시스템을 어떻게 만들것인가에 초점을 맞춘 단계이다. How to에 초점을 둔 과정이라고 할 수 있다.

(b) 소프트웨어 요구사항 분석과 개발 업무의 차이점을 설명하시오.

요구사항 분석: 시스템의 목표를 확립하는 과정을 말하며, 행동을 취하기 전 문제에 대하여 상세화 하는 것을 말한다.  

개발: 이것은 설계와 코딩, 시험이 모두 포함된 것을 말하며, 요구사항을 정확하게 해결해 나가기만 하면 된다.

 

(c) 요구사항 분석에 요구되는 능력을 기술하시오.

고객들과 협상하여 공동의 목표를 끌어내야 하는데,

이 것을 잘하기위해서 의사소통 능력이 중요하다.

 

(d) 소프트웨어 요구사항을 분석하는 사람(직업군)을 일컷는 단어 .

 

시스템 분석가

 

B-2. 시스템 분석가가 진행하는 주요한 임무는 무엇이며 이러한 임무를 수행함에 있어서 소요되는 자질은 무엇인가?

 

시스템 분석가는 사용자와 전문가 사이에서 의사 소통을 원할하게 해주는 사람이다.

사용자의 요구사항과 전문가의 전문지식을 뽑아내는 것이 분석가의 임무이다.

 

 

 

시스템 분석가의 자질

1) 응용분야에 대한 지식

2) 컴퓨터에 대한 기술의 이해

3) 의사소통능력

4) 모순되는 요구사항 해결

5) 고객관점에서 문제를 볼 수 있는 눈이다.

 

1) 응용분야에 대한 전문지식 없이 요구사항 분석은 거의 불가능하다.

2) 현재의 컴퓨터 기술로 실현 가능한 수준을 알고 있어야 한다.

3) 분석가는 사용자, 고객, 전문가와 대화를 나눌 수 있어야 하므로, 의사소통 능력이 시스템 분석가의 첫 번째 요건이 된다.

 

 

B-3. 요구사항을 분석하는 모델링 작업 중에 빠져서는 안 될 중요한 요소는 도표를 사용해야 한다는 점이다. 모델링을 정의하고 모델링의 기본요소에 대해 기술하시오.

 

모델링이란 개발대상 시스템의 성능분석이나 동작과정 등을 알아보기 위하여 간단한 물리적 모형, 도해를 만들거나 또는 그 시스템의 특징을 수학적으로 표현하는 과정

 

모델링의 기본요소로서

Representation,

Convention,

Specification이 있으며,

내용은 다음과 같다.

 

Representation: 문자가 아닌 시각적인 표현

예시:

 

 

 

 

Convention: 시각적인 표현에 대한 설명

 

 

 

Specification: 시각적인 표현을 문자로 확증하는 과정으로

모델링 과정에서 나타난 도표의 구체적인 정의

 

B-4. 소프트웨어 시스템을 바라보는 3가지 관점에 대해 설명하고, 현금자동인출기를 예로 3가지 관점에서 모델링하시오.

 

 

기능 관점은 시스템이 어떠한 기능을 수행하는가의 관점에서 시스템을 기술하고, 주어진 입력에 대하여 어떤 결과가 나오는가를 보여주는 관점이다.

동적관점은 시간에 변화에 따른 시스템의 동작과 제어에 초점을 맞추어 시스템의 상태를 변하게 하는 원인들을 묘사하는 것이다.

정보관점은 시스템에 사용되는 정보 객체를 찾아내고, 이들 객체의 특성, 객체들 사이의 연관성을 규명한다.

 

기능 모델(Activity Diagram)

동적 모델(Sequence Diagram)

정보 모델(Class Diagram)

3개의 다이어그램으로 모델링 한 것을 그린다.

 

B-8. 현금자동인출기(ATM)를 다음 순서에 의해 모델링 하시오.

(1) 문제설명서 (5줄 이내)

 

 

ATM은 은행직원의 도움없이 고객이 입금, 출금, 조회, 이체와 같은 은행 거래를 할 수 있게 해주는 장치이다.

ATM은 현금카드를 받아들여 고객이 가지고 있는 계좌를 바탕으로 위에서 언급한 네 가지 은행 거래중 하나를 수행 한다.

ATM은 은행 소속되어 있으며 고객의 계좌는 은행에서 관리 한다.

 

 

(2) Actor use-case 도출

 

 

 

 

 

 

 

Actor 1: Operator

Actor 2: Customer

Actor 3: Bank

 

(3) “현금인출에 대한 use-case 시나리오 작성

 

유발자: Customer

UseCase 개괄: customer가 자신의 account에서 현금을 인출 한다.

사건흐름

A. 기본 흐름

1) Bank Client는 자신의 account 정보가 기록된 Bank CardATM 기계에 삽입한다.

2) Bank ClientATM 기계에 자신의 account password를 입력한다.

3) Bank Client는 현금인출할 금액을 입력한다.

4) 전액 현금으로 출금 한다.

5) Bank Client는 현금과 Bank CardATM 기계에서 꺼내 온다.

 

B. 대안 흐름

4-1) 현금과 수표 중에 선택 한다.

1.1) 수표로 출금 한다.

 

C. 예외 흐름

2-1) password가 잘못 입력 된 경우

1.1) 다시 password를 입력하라는 메시지를 출력한다.

2-1) pawword3번 잘못 입력된 경우

1.1) 해당 account가 블록되었다는 메시지를 출력한다. 가까운 지점에가서 해결하라는 안내문을 출력 한다.

3-1) account가 보유한 balance보다 많은 금액을 withdraw할 경우

1.1) balance가 부족하다는 메시지를 출력한다.

 

 

(4) 객체(정보) 모델링(Class Diagram)

 

 

 

 

 

(5) “현금인출를 중심으로 동적 모델링(Sequence Diagram)

 

 

 

(6) “현금인출를 중심으로 기능 모델링 또는 Activity Diagram

 

 

 

 

설계(c)

 

1. 소프트웨어 설계단계에서 품질에 영향을 미치는 요소들에 대해 정의를 내리고 소프트웨어 품질과의 관계를 설명하라.

 

설계단계에서 품질에 영향을 미치는 요소들은 모듈 독립성, 응집도, 결합도, 이해도, 적응도가 있다.

 

모듈의 독립성은 각 모듈이 하나의 기능만을 수행하며 다른 모듈들과의 상호교류와 결합을 최소화 시킬 때 모듈의 기능적 독립성은 극대화 된다.

 

응집도모듈 내부가 얼마나 단단히 뭉쳐져 있는 성숙도의 측정치이다. 모듈의 응집도를 높이면 모듈사이의 낮은 결합도를 얻을수 있어 바람직하다.

 

결합도모듈들 사이의 상호 연관성의 복잡도를 일컫는다. 결합도가 높을수록 한 모듈의 변화가 다른 모듈에도 영향을 주어 파문효과가 많이 일어 시스템을 유지보수하기가 어려워진다. 시스템 설계시 가능한 최하위의 결합도를 갖게 시스템을 설계하는 것이 이상적이다.

 

이해도다른 프로그램 요소나 정보를 참조하지 않고, 이해할 수 있는 용이성이다. 시스템의 응집도가 높을수록 쉽게 쉽게 이해 할 수 있게 해준다.

 

적응도새로운 환경에 적절히 대응할 수 있도록 소프트웨어를 변경시킬 수 있는 용이성이다. 적응도를 높이기 위해서는 결합도를 낮추고, 문서는 이해하기 쉽고 프로그램과 일치하게 관리하여야 한다.

 

 

 

2. 트랜잭션 흐름 중심의 설계변환(Transform) 흐름 중심 설계의 과정과 차이점을 기술하시오.

 

 

변환흐름중심설계는 시스템이 정보를 받아들여 이를 변환시키고 출력을 만들어 낸다. 출력은 입력이 변환된 가공물이라 볼 수 있다.

 

트랜잭션 흐름 중심 설계는 시스템이 정보를 받아들여 정보의 값을 기초로 어떤 특정 경로의 일을 진행시킬 것인가를 결정한다. 이 경우 입력값에 의해 어떤 임무를 수행 할 것인가가 결정된다.

 

변환흐름 중심 설계에서의 설계 과정은

첫째, 요구사항 명세서로부터 하나의 자료흐름도를 만든다.

둘째, 자료흐름도의 유형을 조사한다.

셋째, 입력 경계출력 경계를 정한다.

넷째, 최상위 수준에서 자료흐름 중심 프로그램 구조를 개발한다.

다섯째, 자료흐름도를 프로그램 구조로 전환한다.

여섯째, 프로그램 구조를 정제한다.

 

트랜잭션 흐름의 설계 과정은 변환흐름설계과정과 약간 차이가 있다.

두 번째에서 자료흐름이 트랜잭션 흐름으로 결정나면,

셋째 트랜잭션 흐름과 동작 경로를 파악한다.

넷째 트랜잭션 흐름의 프로그램을 개발한다.

다음단계는 다섯째, 자료흐름을 프로그램 구조로 매핑하여

여섯째, 프로그램 구조를 정제한다.

 

 

3. 소프트웨어 설계를 관리적 관점기술적 관점으로 나누어 각 관점에서 이루어지는 설계 기법을 기술하시오.

 

관리적 관점에서는 크게 기본 설계상세설계로 나눌 수 있다.

기본 설계에서는 시스템의 구조와 데이터를 규명하며, 사용자의 인터페이스를 정의하고,

상세설계에서는 각 모듈의 구체적인 알고리즘에 초점을 맞춘다.

 

기술자 관점은 크게 네가지로 나눌 수 있다.

첫째, 데이터 설계에서는 자료구조와 데이터 베이스를 설계한다.

둘째, 구조설계에서는 모델링 결과를 이용하여 각 모듈들 사이의 관계를 기술한다.

셋째, 프로시져 설계에서는 모듈 내부의 알고리즘을 선택한다.

넷째, 사용자 인터페이스 설계에서는 인터페이스 정의를 만족하기 위해 시스템의 기능분할이 필요할 것이라고 생각 할 수 있다. 인터페이스 설계는 구조설계 이전에 한다.

 

 

4. 상세설계에서 사용되는 기법들을 간략하게 설명하시오.

상세설계에서 알고리즘을 표현하는 기법으로는 순서도, N-S도표, 프로그램설계언어(PDL)등이 있다.

 

순서도는 직사각형, 다이아몬드 화살표를 기본요소로 제어흐름을 표시한다. 간단하고 표현력이 높지만, 복잡한 시스템을 설명하는데 부적합하다.

 

N-S도표의 특징은

순서도의 표현력을 높인 것으로

첫째, 순서, 조건분기, 순환 등 기본적 구조를 서로 다른 도표로 표시해 쉽게 이해 할 수 있다.

둘째, 프로그램을 구조적으로 작성해야만 한다.

셋째, 임의로 goto문을 작성 할 수 없다.

넷째, 순환 구조를 쉽게 표시할 수 있다.

 

PDL은 고급언어와 저급언어를 통합하여 사용 할 수 있는 알고리즘 표기언어이다.

, PDL은 프로그램의 알고리즘 구조를 정확히 표기하기 때문에 자동적으로 다른 표기법으로

변환 할 수 있다.

 

 

5. 분석에서 설계로 넘어가며 나타나는 문제점어려움의 원인에 대하여 기술하고 이를 극복할 수 있는 방법을 설명하시오.

요구사항 분석 단계에서는 응용분야의 관점, 사용자 관점에서 시스템을 기술한 반면,

설계 단계에서는 소프트웨어의 관점, 엔지니어의 관점에서 시스템을 기술하게 된다.

 

즉, 요구사항은 분석하는 단계는 개념적인 것이라면,

설계과정은 물리적인 것이라 할 수 있다.

 

또한 요구사항 분석에서 생긴 문제점들을 해결하기 위한 방법을 설계 단계에서 구상하여야 하므로 최소한 한가지 이상의 해결 방법을 고안해 내야 하는 어려움이 있다. 따라서 설계를 하기 위해선 문제에 대해 여러 가지 각도에서 문제를 바라볼 수 있는 눈이 있어야 하며 날카로운 안목을 기르기 위해 많은 훈련과 경험을 쌓아야 한다. 또한 추상화와 모듈화 기법을 적용하여 초기 설계과정에서 나타나는 시스템의 추상적인 모습을 계속 정제하여 구체적인 설계 모습이 나올 수 있도록 세련화 시키는 방법을 통해 고품질의 설계를 이룩할 수 있다.

 

구현

D-1 코드검사의 목적을 설명하고 검사팀의 역할 5가지를 기술하시오.

 

코드 검사의 목적은 오류를 적은 비용을 들여 신속하게 찾아내고, 유지보수 비용을 줄이는데 있다. 검사팀은 저자, 사회자 , 낭독자, 기술자, 검사자가 있다.

1) 저자는 코드 저자로 코드에 대한 정보를 제공하고 문제점에 대한 답변을 한다.

2) 사회자는 제시간에 검토가 이루어지도록 준비한다.

3) 낭독자는 코드를 읽으면서 이를 해석한다.

4) 기록자는 검토도중 문제점이나 오류를 기록하고, 결과를 배포한다

5) 검사자는 사전과 진행 중에 코드를 구체적으로 검사한다.

 

시험

 

E-1 검증과 확인을 정의하고 그 기법을 설명하시오. 또한 이 기법들이 소프트웨어 분석 및 개발과정에서 어떻게 적용되는지 설명하라.

 

a) 차이점

검증이란 소프트웨어가 고객의 요구사항을 만족시키는가의 여부를 밝히는 활동이고

(검증이란 사용자가 원하는 올바른 제품을 만들었는지, 요구사항 분석의 결과가 사용자가 바라는 요구를 반영한 만족할 만한 것인지를 검사하는 것이다.)

 

확인이란 소프트웨어가 요구사항 명세서에 지정된 기능 혹은 성능을 정확히 수행하는지 조사하는 것이다.

 

b) 검증과 확인에 사용되는 기법

 

블랙박스(예: 통합시험 등), 화이트박스(예: 단위 시험 등)

 

C) 또한 이 기법들이 소프트웨어 분석 및 각 개발 과정에서 어떻게 적용되는지 단계별로 설명하시오.

소프트웨어 개발의 세 단계

1) 요구사항 분석: 검증 시험

2) 설계: 통합 시험

3) 코딩: 단위 시험

 

설계와 코딩 단계: 화이트 박스 시험을 주로 사용 한다.

설계 단계: 블랙박스

 

검증을 위해 시제품 개발, 기술적 검토, 시뮬레이션을 이용해 고객의 요구사항을 명확히 한다. 확인은 개발주기상에서 현제 단계의 산출물이 바로 이전 단계의 산출물과 일치하는가를 결정하는 과정 (책참조)

 

 

품질

 

F-1. 소프트웨어의 품질 질문

(a) 생산자 관점, 고객 관점에서 각각 정의하시오.(책참조)

 

품질은 사용자만족 사용하기에 적합함,규격에 맞음,등과 같이 다양하게 정의를 내릴수 있다. 품질은 구체적인 기능 및 성능에 만족해야하고 소프트웨어에 기대되는 사용자의 요구 수준을 만족시키는 것이다.

생산자의 관점에서는 사용자가 만족할 수 있는 품질의 소프트웨어를 가장 경제적으로 만드는 것이 목표이고, 고객의 관점에서는 각 공정과정을 이해하고 감독하는 것이 필요하다. 즉 내용을 모르고 좋은 품질의 제품을 만들어 달라고 할 수만은 없다. 고객 만족은 고객이 내용을 잘 알아야 비로소 가능하다.

 

(b) 소프트웨어 품질 요소에 대하여 설명하시오.

 

 

 

 

소프트웨어 품질요소로는

운영측면에서 정확성, 신뢰성, 효율성, 유용성, 무결성이 있다.

수정측면에서는 유연성, 시험성, 유지보수성이 있다.

적응측면에서는 이식성, 재사용성, 상호운용성이 있다.

 

(c) 소프트웨어의 품질을 보증하기 위해 요구되는 중요한 작업(활동)들을 5 가지만 기술하시오.

 

1) 각 공정과정의 결과물에 대한 공식적인 기술검토가 이루어져야 한다.

2) 다단계 시험전략이 필요하다.

3) 문서화 과정과 문서관리를 확실히 한다.

4) 기록유지와 보고가 체게적으로 이뤄져야한다.

5) 개발표준의 확립이 이루어져야 한다.

 

(d) 품질에 드는 비용을 설명하는 지랫대의 효과에 대하여 기술하시오.

 

1온스를 들여 예방을 하면 치료에 드는 1파운드를 절약할 수 있다.는 말처럼 예방 활동을 강화할수록 소프트웨어의 실패비용을 크게 줄일 수 있다는 말이다.

 

 

F-2. ISO 9001, 9002, 9003 인증에 대하여 차이점을 중심으로 설명하고 적용 가능한 분야의 예를 하나씩 드시오.

 

ISO 9001 : 제품설계 개발에서부터 제조, 설치, 서비스에 이르는 품질보증체제 (소프트웨어 적용 가능)

ISO 9002 : 설계, 개발 부문의 품질시스템이 존재하지 않는 품질보증체제, 한마디로 제조, 설치, 서비스만 존재한다.

ISO 9003 : 최종검사 및 시험에 관한 품질보증체제

 

간단한 제품은 출하시 확인만 하면 되는 ISO 9003만으로도 충분하며,

제품의 설계에서부터 출하까지의 전 과정에 대한 체제인증이 필요한 경우는 ISO 9001을 선택하면 된다.

일반적으로는 ISO 9002 규격에 의한 인증이 가장 많다.

 

적용분야

ISO9001 은 설계/개발,제조,부대서비스에 관한 보증품질 ,

ISO9002 제조 설치에 관한 품질체제

ISO 9003 지극히 단순한 제품의 최종검사 의 품질보증 ,

 

F-3. CMMI(관리하는거)에 대한 질문

(a) 5단계 성숙도를 기술하시오.

 

   

성숙도 수준 5단계는 소프트웨어프로세스를 정의하거나 개선하기 위하여 조직에 의하여 수행되는 활동, 각 프로젝트에 수행되는 활동, 얻어지는 프로세스 능력들로 특징짓는다.

 

1단계는 초기(Initial) 단계로 가장 낮은 성숙도 수준을 나타낸다. 초기 단계에서 조직은 소프트웨어의 개발과 유지에 안정적인 환경을 제공하지 못한다.

 

2단계는 반복(Repeatable) 단계로, 1단계에서와 같이 프로세스에 대한 가시성(Visibility)이 전혀 없는 상태에서 개선되어야 할 프로젝트 관리(Project Management)를 포함한다.

 

 

3단계는 정의(Defined) 단계로서, 2단계에서 관리되는 프로세스 중 효율적이고 조직과 잘 맞는 프로세스들을 선택하여 조직 차원의 표준소프트웨어프로세스(Organization's Standard Software Process)정의 한다.

 

관리(Managed) 단계인 4단계에서는, 소프트웨어 제품과 프로세스에 대한 정량적인 품질목표(Quantitative Quality Goals)를 설정하고 관리한다.

 

마지막 5단계인 최적화(Optimizing) 단계는, 프로세스개선이 전조직구성원으로 확대되고, 지속적 프로세스개선(Continuous Process Improvement)을 위해 노력한다.

 

 

(b) 프로세스 영역 4가지를 기술하시오.

프로세스 관리영역,

프로젝트 관리영역,

엔지니어링 영역,

지원영역

 

(c) 각 단계의 성숙도에 요구되는 Key Process Area 를 각 단계(level 2에서 level 5 까지) 별로 2 가지씩 드시오.

 

2단계: 요구사항관리, 프로젝트계획수립, 프로젝트추적관리 , 외주관리, 품질보증등

3단계: 조직프로세스 포커스, 조직프로세스 정의, 교육훈련, 통합소프트웨어 관리 등

4단계: 계량적 프로세스관리, 소프트웨어 품질 관리

5단계: 결함예방관리, 기술변화관리, 프로세스 변화 관리

 

(d) 단계적 표현(Staged Representation) 과 연속적 표현(Continuous Representation)의 차이점을 설명하시오.

단계적 표현은 5단계의 성숙도를 나타내며 연속적 표현은 6단계의 능력으로 나누고 있다. 단계적인 표현은 점진적으로 ProcessArea(PA)단계를 수행하며 연속적 표현은 선택적으로 PA를 수행하는 방법이다. 또한 표현구조는 단계적인 표현방법은 Bottom-up 구조이며 연속적 표현방법은 TOP-DOWN 구조이다.

 

(e) specific goal generic goal 의 차이점을 기술하시오.

 

Specific Goal 은 해당 프로세스 영역을 만족하기 위해 수행해야 하는 유일한 특성을 정의 하며 Generic Goal 프로세스 분야를 구현하는 프로세스를 체계화하기 위해 존재해야 하는 특성의 활동을 기술한다.

 

F-4. ISO 9000 인증과 CMM을 비교하여 인증 수준을 평가하여 보시오.

 

ISO9001에서는 간략한 요구사항만을 평가하지만 CMM은 매우 엄격한 평가 지침을 갖고 있다. ISO9001의 기업은 CMMI 레벨2를 대부분 만족하고있으며, 레벨3의 많은 부분을 축족시키지만 CMM의 모든 부분은 충족시키지는 못하기 때문에 때로는 레벨1 조직이 ISO9001 인증을 받기도한다. 레벨2또는 레벨3의 조직은 ISO 9001에 대부분 만족하나 CMM에 존재하지 않는 ISO 특성의 요구사항을 만족해아만 한다.

 

F-5. 소프트웨어 형상관리(software configuration management) 질문

(a). 소프트웨어의 형상을 정의하시오.

 

소프트웨어의 개발유지보수 과정에서 발생하는 각종 결과(문서)에 대한

계획, 개발, 운용 등을 종합하여 시스템의 형상을 만들고 이에 대한 변경

체계적으로 관리 제어하기 위한 활동이다.

 

(b) 형상항목을 설명하고 그 예를 드시오.

 

원래 형상이란 사물의 형체나 생긴 모양을 의미한다.

소프트웨어 개발 라이플 사이클 각 단계마다 만들어지는 문서를 포함한다.

소프트웨어 형상 항목은 형상관리의 목표물이 된다.

소프트웨어를 구성하는 소프트웨어 형상 항목에는 정의 단계의 문서,

개발단계의 문서프로그램, 시험계획과 절차, 사용자 매뉴얼,유지보수 단계의 변경사항,

표준 및 절차 등이 있다.

 

(c) 문서의 Baseline 에 대하여 설명하시오.

 

소프트웨어 개발의 특정 시점에서 형상 항목이 소프트웨어 개발에 하나의 완전한 산출물로써

쓰여질 수 있는 상태의 집합을 말하며, 책임이 있는 관리를 통해 공식적으로 검토 및

동의 되었고, 추후 개발의 기초가 되며, 오직 공식적인 변경 통제 절차에 의해서만

변경될 수 있는 상태를 나타낸다.

 

(d) 형상항목의 변경 과정에 대하여 Flowchart 를 이용하여 기술하시오.

 

 

 

 


'Computer Science > 소프트웨어 공학' 카테고리의 다른 글

Coverage domian과 Criterion  (0) 2014.04.14
시험 대비  (0) 2012.06.11

+ Recent posts