프로젝트 계획 수립 시 소프트웨어 범위(Scope) 결정의 주요 요소로 거리가 먼 것은?

1. 소프트웨어 개발 환경
2. 소프트웨어 성능
3. 소프트웨어 제약 조건
4. 소프트웨어 신뢰도

풀이보기

 

소프트웨어 품질 보증을 위한 정형 기술 검토의 지침사항으로 옳지 않은 것은?

1. 논쟁과 반박의 제한성
2. 의제의 무제한성
3. 제품 검토의 집중성
4. 참가인원의 제한성

풀이보기

 

자료 사전에서 반복을 의미하는 기호는?

1. ()
2. {}
3. []
4. +

풀이보기

 

럼바우의 객체지향 분석 모델링에 해당하지 않는 것은?

1. Relational Modeling
2. Object Modeling
3. Functional Modeling
4. Dynamic Modeling

풀이보기

 

소프트웨어 유지보수 유형 중 현재 수행 중인 기능의 수정, 새로운 기능의 추가, 전반적인 기능 개선 등의 요구를 사용자로부터 받았을 때 수행되는 유형으로서, 유지보수 유형 중 제일 많은 비용이 소요되는 것은?

1. Preventive Maintenance
2. Adaptive maintenance
3. Corrective Maintenance
4. Perfective Maintenance

풀이보기

 

소프트웨어 프로젝트 관리의 효과적 수행을 위한 3P에 해당하지 않는 것은?

1. Program
2. People
3. Problem
4. Process

풀이보기

 

블랙 박스 검사에 대한 설명으로 옳지 않은 것은?

1. 각 기능이 완전히 작동되는 것을 입증하는 검사이다.
2. 인터페이스 결함, 성능 결함, 초기화와 종료 이상 결함 등을 찾아 낸다.
3. 동치 분할 검사는 논리적인 조건과 대응하는 행동을 간략히 표현할 수 있도록 하는 검사 사례 설계 기법이다.
4. 경계값 분석은 입력의 경계값에서 발생하는 오류를 제거하기 위한 검사 기법이다.

풀이보기

2008년 2회

64. 소프트웨어 프로젝트 계획 수립 시 소프트웨어 영역(범위) 결정의 주요 요소로 거리가 먼 것은?

1. 기능

2. 인적자원

3. 인터페이스

4. 성능

풀이보기

 

66. 소프트웨어 재공학은 어떤 유지보수 측면에서 소프트웨어 위기를 해결하려고 하는 방법인가?

1. 수정(Corrective) 유지보수

2. 적응(Adaptive) 유지보수

3. 완전화(Perfective) 유지보수

4. 예방(Preventive) 유지보수

풀이보기

 

67. CASE에 대한 설명으로 거리가 먼 것은?

1. 소프트웨어 모듈의 재사용성이 향상된다.

2. 자동화된 기법을 통해 소프트웨어 품질이 향상된다.

3. 소프트웨어 사용자들이 소프트웨어 사용 방법을 신속히 숙지 할 수 있도록 개발된 자동화 패키지이다.

4. 소프트웨어 유지보수를 간편하게 수행할 수 있다.

풀이보기

 

71. 객체 지향 기법에서 다음 설명에 해당하는 것으로 가장 타당한 것은?

-다른 객체에게 자신의 정보를 숨기고 자신의 연산만을
 통하여 접근한다.
-유지보수와 소프트웨어 확장 시 오류를 최소화할 수
 있다.

1. Abstraction

2. Information Hiding

3. Inheritance

4. Polymorphism

풀이보기

 

73. 소프트웨어 품질 목표 중 새로운 요구사항에 접하여 쉽게 수정될 수 있는 시스템 능력을 의미하는 것은?

1. Reliability

2. Efficiency

3. Integrity

4. Flexibility

풀이보기

 

74. 응집도의 종류 중 서로 간의 어떠한 의미 있는 연관 관계도 지니지 않은 기능 요소로 구성되는 경우이며, 서로 다른 상위 모듈에 의해 호출되어 처리상의 연관성이 없는 서로 다른 기능을 수행하는 경우의 응집도는?

1. Coincidental Cohesion

2. functional Cohesion

3. Sequential Cohesion

4. Logical Cohesion

풀이보기

 

75. Software Project의 비용 결정 요소와 가장 관련이 적은 것은?

1. 개발자의 능력

2. 요구되는 신뢰도

3. 하드웨어의 성능

4. 개발 제품의 복잡도

풀이보기

 

78. 구조적 분석 도구와 거리가 먼 것은?

1. 자료 사전

2. 자료 흐름도

3. 프로그램 명세서

4. 소단위 명세서

풀이보기

 

79. 소프트웨어에 새로운 기능을 추가하거나 성능을 개선하는 활동으로서, 소프트웨어 유지보수 활동 중 가장 많은 비용이 소요되는 것은?

1. 수정(Corrective) 보수

2. 예방(Preventive) 보수

3. 완전화(Perfective) 보수

4. 적응(Adaptive) 보수

풀이보기

 

80. 프로젝트 일정을 관리하는 PERT 차트로 알 수 있는 사항이 아닌 것은?

1. 결정 경로

2. 태스크의 시작/종료 시간

3. 태스크에 대한 경계시간

4. 태스크간의 상호관련성

풀이보기

2008년 4회

61. 다음 사항과 관계되는 결합도는 무엇인가?

-한 모듈에서 다른 모듈의 내부로 제어 이동
-한 모듈이 다른 모듈 내부 자료의 조회 또는 변경
-두 모듈이 동일한 문자(Literals)의 공유

1. Data Coupling

2. Content Coupling

3. Control Coupling

4. Stamp Coupling

풀이보기

 

62. CASE 도구의 정보저장소(Repository)에 대한 설명으로 거리가 먼 것은?

1. 일반적으로 정보저장소는 도구들과 생명 주기 활동, 사용자들, 응용 소프트웨어들 사이의 통신과 소프트웨어 시스템 정보의 공유를 향상시킨다.

2. 초기의 소프트웨어 개발 환경에서는 사람이 정보저장소 역할을 했지만 오늘날에는 응용 프로그램이 정보저장소 역할을 담당한다.

3. 정보저장소는 도구들의 통합, 소프트웨어 시스템의 표준화, 소프트웨어 시스템 정보의 공유, 소프트웨어 재사용성의 기본이 된다.

4. 소프트웨어 시스템 구성 요소들과 시스템 정보가 정보저장소에 의해 관리되므로 소프트웨어 시스템의 유지보수가 용이해진다.

풀이보기

 

68. 어떤 프로그램을 재공학 기술을 적용하여 보수하고자 할 때 Flow Graph가 사용될 수 있다. 다음의 샘플 프로그램에 대한 Flow Graph가 다음 그림과 같을 때 McCabe 식의 Cyclomatic Complexity를 구하면?

1. 1

2. 2

3. 3

4. 4

풀이보기

 

70. 다음 설명에 해당하는 개체 지향 기법의 특징은?

-일반화된 객체를 이용해서 특정 객체가 가진 특성을
이용할 수 있다.
-일반화된 객체는 어떤 특정 객체를 지칭할 수 있기 때
문에 같은 동작을 하지만 다른 성질을 가질 수 있다.
-동일한 이름으로 지시된 오퍼레이션이 개개의 객체에
의하여 여러 모양을 가질 수 있다.

1. 추상화

2. 캡슐화

3. 다형성

4. 상속성

풀이보기

 

72. 자료 흐름도의 구성 요소가 아닌 것은?

1. 소단위 명세서

2. 단말

3. 프로세스

4. 자료 저장소

풀이보기

 

76. 프로젝트 일정 관리 시 사용하는 간트(Gant) 차트에 대한 설명으로 옳지 않은 것은?

1. 막대로 표시하며, 수평 막대의 길이는 각 태스크의 기간을 나타낸다.

2. 이정표, 기간, 작업, 프로젝트 일정을 나타낸다.

3. 시간선(Time-line) 차트라고도 한다.

4. 작업들 간의 상호 관련성, 결정 경로를 표시한다.

풀이보기

 

80. 소프트웨어 생명주기 모형에 대한 설명으로 옳은 것은?

1. 폭포수 모형을 점진적 모형이라고도 한다.

2. 나선형 모형은 반복적으로 개발이 진행되므로 소프트웨어의 강인성을 높일 수 있다.

3. 프로토타입 모형은 개발 단계에서 요구사항 변경이 불가능하므로 유지보수 비용이 많이 발생한다.

4. 폭포수 모형은 최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 모형을 볼 수 있다.

풀이보기

---

풀이보기

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

153 소프트웨어와 시스템/소프트웨어 위기

소프트웨어와 시스템

• 소프트웨어:H/W를 동작시켜 사용자가 작업을 편리하게 수행하도록 하는 프로그램과 자료 구조 등을 총칭하며, 프로그램 자체뿐만 아니라 프로그램의 개발, 운용 및 유지 보수에 관련된 모든 문서와 정보를 포함함
• 시스템:공통의 목적이나 목표를 달성하기 위하여 여러 가지 상호 관련된 요소들을 유기적으로 결합한 것으로 구성 요소는 입력, 처리, 출력, 제어, 피드백으로 나눌 수 있음

소프트웨어 위기(Crisis)

• 여러 가지 원인에 의해 S/W 개발 속도가 H/W 개발 속도를 따라가지 못해 S/W에 대한 사용자들의 요구사항을 처리할 수 없는 문제가 발생한 것을 의미

• S/W 위기의 원인과 결과

  원인	S/W의 특성에 대한 이해 부족 S/W의 관리 부재 프로그래밍만 치중
  결과	개발 인력의 부족과 그로 인한 인건비 상승 성능 및 신뢰성의 부족  유지보수가 어렵고, 이에 따른 비용 증가  S/W의 생산성 저하, S/W의 품질 저하

 

154 S/W 공학의 개념과 기본 원칙

소프트웨어 공학의 정의

신뢰성 있고, 교화적으로 작동하는 결제적인 소프트웨어 프로덕트를 생산하기 위해 소프트웨어의 개발과 운영 그리고 유지보수 활동에 체계적이고 숙달되고, 수량화된 프로세스(절차), 방법, 도구들을 적용하고, 또한 이러한 프로세스, 방법, 도구를 연구 개발하는 활동

S/W 공학의 개념

• IEEE의 S/W 공학 표준 용어사전:S/W의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안

• Fairley:지정된 비용과 기간 내에 S/W를 체계적으로 생산하고 유지보수하는 데 관련된 기술적이고 관리적인 원리

• Boehm:과학적인 지식을 S/W 설계와 제작에 응용하는 것이며 이를 개발, 운용, 유지보수하는 데 필요한 문서 작성 과정

• S/W 공학은 제품을 단지 생산하는 것이 아니라 가장 경제적인 방법으로 양질의 제품을 생산하는 것이다.

• S/W 공학은 안정적이며 효율적으로 작동하는 S/W를 생산하고, 유지보수 활동을 체계적이고 경제적으로 수행하기 위해 계층화 기술을 사용한다.

S/W 공학의 기본 원칙

• 현대적인 프로그래밍 기술을 계속적으로 적용해야

  한다.

• 개발된 S/W의 품질이 유지되도록 지속적으로 검증해야 한다.

• S/W 개발 관련 사항 및  결과에 대한 명확한 기록을 유지해야 한다.

 

155 일반적인 S/W 생명 주기

• 정의 단계:’무엇(What)’을 처리하는 S/W를 개발할 것인지 정의하는 단계로, 관리자와 사용자가 가장 많이 참여하는 단계

  • 타당성 검토 단계	개발할 S/W가 법적, 경제적, 기술적으로 실현 가능성이 있는지 조사하는 단계
    개발 계획 단계	S/W 개발에 사용될 자원과 비용을 측정하는 단계
    요구사항 분석 단계	사용자가 요구한 문제를 보다 상세하고 정확히 분석하는 단계

• 개발 단계:’어떻게(How)’에 초점을 두고 실제적으로 S/W를 개발하는 단계

  • 설계 단계	S/W의 구조, 알고리즘, 자료 구조 등을 작성하는 단계로, 에러가 가장 많이 발생하는 단계
    구현 단계	설계 단계에서 작성된 문서를 기초로 하여 코딩하고 번역 하는 단계
    테스트 단계	구현된 S/W에 내재되어 있는 오류를 찾는 단계

• 유지보수 단계:S/W를 직접 운용하며, ‘변경(Change)’에 초점을 두고 여러 환경 변화에 따라 S/W를 적응 및 유지시키는 단계로, 시간과 비용이 가장 많이 투입되는 단계

 

156 폭포수 모형(Waterfall Model)

• S/W 공학에서 가장 오래되고 가장 폭넓게 사용된 전통적인 S/W 생명 주기 모형(고전적 생명 주기 모형)이다.
• S/W 개발 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하며 이전 단계로 넘어갈 수 없는 방식이다.
• S/W 개발 과정의 앞 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형(Linear sequential model)이다.
• S/W의 일부가 될 매뉴얼을 작성해야 한다.
• 개발 순서:타당성 검토→계획→요구 분석→설계→구현(코딩)→시험(검사)→유지보수

  장점	모형의 적용 경험과 성공 사례가 많다 단계별 정의가 분명하고, 전체 공조의 이해가 용이하다 단계별 산출물이 정확하여 개발 공정의 기준점을 잘 제시한다
  단점	처음부터 사용자들이 모든 요구사항들을 명확하게 제시해야 한다 개발 과정 중에 발생하는 새로운 요구나 경험을 반영하기 어렵다 개발된 프로그램을 업무에 운용할 때 검출되지 않은 오류로 인하여 사용자들이 큰 인내심을 가져야 한다

 

157 프로토타입 모형(Prototype Model)

• 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형이다.
• 시스템의 일부 혹은 시스템의 모형을 만드는 과정으로서, 요구된 S/W의 일부를 구현하는데, 이는 추후 구현 단계에서 사용될 골격 코드가 된다.
• Prototype은 요구 분석 단계에서 사용하게 되며, Prototype의 평가가 끝나고 개발이 승인되면 다른 모형을 이용하여 본격적인 개발이 이루어진다.
• 개발 순서:요구 수집→빠른 설계→프로토타입 구축→고객 평가→프로토타입 조정→구현

  장점	요구사항을 충실히 반영하며, 요구사항의 변경이 용이하다 최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있다 Prototype은 의뢰자나 개발자 모두에게 공동의 참조 모델을 제공한다
  단점	미리 제작된 S/W를 사용할 경우 실제 S/W와의 차이가 발생할 수 있어 사용자에게 혼란을 줄 수 있다 단기간에 제작해야 하기 때문에 비효율적인 언어나 알고리즘을 사용할 수 있다

 

158 나선형 모형(Spiral Model), 점진적 모형

더보기

• Waterfall과 Prototype 모형의 장점에 위험 분석 기능을 추가한 모형이다.
• 나선을 다라 돌 듯이 여러 번의 S/W 개발 과정을 거쳐 점진적으로(Prototype을 지속적으로 발전시켜) 완벽한 최종 S/W를 개발하는 것이다.
• S/W를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 한다.
• 개발 순서:계획 및 정의(Planning)→위험 분석(Risk Analysis)→공학적 개발(Engineering)→고객 평가(Customer Evaluation)

  장점	가장 현실적인 모형으로, 대규모 시스템에 적합함 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없다
  단점	위험성 평가에 크게 의존하기 때문에 이를 발견하지 않으면 반드시 문제가 발생한다. 비교적 최신기법이므로 Waterfall 또는 Prototype Model 보다 널리 사용되지 않음

 

159 프로젝트 관리 대상

프로젝트 관리(Project Management)

• 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 전반적인 활동
• S/W 개발 계획을 세우고 분석, 설계, 수현 등의 작업을 통해 하는 것으로 S/W 생명 주기의 전 과정을 걸쳐 진행된다.

프로젝트 관리 대상

• 계획 관리:프로젝트 계획, 비용 산정, 일정 계획, 조직 계획
• 품질 관리:품질 통제, 품질 보증
• 위험 관리:위험 식별, 위험 분석 및 평가, 위험 관리 계획, 위험 감시 및 조치
• 효과적인 프로젝트 관리를 위한 3P(3대 요소)

  사람(People)	프로젝트 관리에서 가장 기본이 되는 인적 자원
  문제(Problem)	사용자 입장에서 문제를 분석하여 인식함
  프로세스(Process)	S/W 개발에 필요한 전체적인 작업 계획

 

더보기

 

160 프로젝트 계획 수립

S/W 개발 영역 결정

• 첫 번째 업무로 개발될 S/W의 영역을 결정하는 것
• S/W 개발 영역을 결정하는 주요 요소:처리될 데이터와 S/W에 대한 기능, 성능, 제약조건, 인터페이스 및 신뢰도 등

자원 추산:S/W 개발에 필요한 자원을 예측하는 것으로 인적, 재사용 S/W, 환경 자원으로 나눌 수 있다.

S/W 프로젝트 추산:프로젝트 수행에 필요한 비용을 예측하는 것으로, 신뢰할 만한 비용을 예측하기 위해서는 다음과 같은 방법을 사용한다.

• 프로젝트 관리의 후반까지 프로젝트 예측을 가능한 한 연기한다.
• 이미 수행된 유사 프로젝트를 참고한다.
• 프로젝트를 상대적으로 잘게 분리하여 예측하는 분해 기법을 사용한다.
• 하나 이상의 경험적 예측(실험) 모델을 활용한다.
• 자동화 도구를 도입하여 활용한다.

프로젝트 비용 결정 요소

프로젝트 요소	제품의 복잡도, 시스템의 크기, 요구되는 신뢰도
자원 요소	인적 지원, H/W지원, S/W지원
생산성 요소	개발자의 능력, 경험, 주어진 개발 기간

 

161 LOC(원시 코드 라인 수) 기법

• S/W 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측 치를 구하고 이를 이용하여 비용을 산정하는 기법이다.
• 측정이 용이하고, 이해가 쉬워 가장 많이 사용된다.
• 예측치=a+4m+b/6(단, a:낙관치, b:비관치, m:중간치(기대치))
• 산정공식

 

162 COCOMO

• Boehm이 제안한 것으로 원시 프로그램의 규모(LOC)에 의한 비용 산정 기법이다.
• 개발할 S/W의 규모를 예측한 후 이를 S/W 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 산정한다.
• 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 S/W 개발비 견적에 널리 통용되고 있다.
• 소프트웨어 개발 유형

  조직형(Organic Mode)	기관 내부에서 개발된 중ㆍ소규모의 S/W로 일괄 자료 처리나 과학 기술 계산용, 비즈니스 재료 처리용으로 5만(50KDSI) 라인 이하의 S/W를 개발하는 유형  사무 처리용, 업무용, 과학용, 응용 S/W 개발에 적합함
  반분리형(Semi-Detached Mode)	조직형과 내장형의 중간형으로 트랜잭션 처리 시스템이나 OS, DBMS 등의 30만(300KDSI) 라인 이하의 S/W 개발하는 유형  컴파일러, 일터프리터와 같은 유틸리티 개발에 적합함
  내장형(Embedded Mode)	초대형 규모의 트랜잭션 처리 시스템이나 OS 등의 30만(300KDSI) 라인 이상의 소프트웨어를 개발하는 유형  신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합함

 

 

163 COCOMO 모형의 종류

• 비용 산정 단계 및 적용 변수의 구체와 정도에 따라 기본(Basic), 중간(Intermediate), 발전(Detailed)형으로 구분할 수 있다.
• 기본(Basic)형 COCOMO:S/W의 크기와 개발 유형만을 이용하여 비용을 산정하는 모형
• 중간(Intermediate)형 COCOMO:기본 COCOMO 공식을 토대로 사용하나, 제품의 특성, 컴퓨터의 특성, 개발 요원의 특성, 프로젝트 특성에 의해 비용을 산정하는 모형
• 발전(Detailed)형 COCOMO:중간(Intermediate)형 COCOMO를 보완하여 만들어진 방법으로, 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용을 산정하는 모형

 

164 브룩스 법칙/PERT/CPM

브룩스(Brooks)의 법칙

• 프로젝트 진행 중에 새로운 인력을 투입할 경우 작업 적응 기간과 부작용으로 인해 일정을 더욱 지연시키고, 프로젝트에 혼란을 가져오게 된다는 법칙이다.

PERT/CPM

• 프로젝트의 지연을 방지하고 계획대로 진행되게 하기 위한 일정을 계획하는 것으로, 대단위 계획의 조직적인 추진을 위해 자원의 제약하에 비용을 적게 사용하면서 최단시간 내 계획 완성을 위한 프로젝트 일정 방법이다.
• 프로젝트 개발 기간을 결정하는 임계 경로(CP:Critical Path)를 제공한다.
• 통계적 모델을 적용해서 개별 작업에 대한 가장 근접한 시간 측정의 기준이 된다.
• 각 작업에 대한 시작 시간을 정의하여 작업들 간의 경계 시간을 계산할 수 있게 한다.

  PERT	프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크로 각 작업 별로 낙관적인 경우, 가능성이 있는 경우, 비관적인 경우로 나누어 각 단계별 종료 시기를 결정하는 방법 노드와 간선으로 구성되었으며 원 노드에는 작업을, 간선에는 낙관치, 기대치, 비관치를 표시함
  CPM	프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는 데 사용하는 기법 CPM은 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타낸다. 원 노드는 각 작업을 의미하며 각 작업 이름과 소요 기간을 표시하고, 박스 노드는 이정표를 의미하며 박스 노드 위에는 예상 완료 시간을 표시한다. 한 이정표에서 다른 이정표로 도달하려면 이전의 작업이 모두 완료되어야 한다.

 

165 간트 차트(Gantt Chart)

• 프로젝트의 각 작업들이 언제 시작하고 종료되었는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표로, 시간선(Time-Line)  차트라고도 한다.
• 막대로 표시하며, 수평 막대의 길이는 각 작업의 기간을 나타낸다.
• 중간 목표 미달성 시 이유와 기간을 예측할 수 있게 한다.
• 사용자와의 문제점이나 예산의 초과 지출 등도 관리할 수 있게 한다.
• 자원 배치와 인원 계획에 유용하게 사용된다.
• 다양한 형태로 변경하여 사용할 수 있다.
• 작업 경로는 표시할 수 없으며, 계획의 변화에 대한 적응성이 약하다.
• 이정표, 작업 일정, 작업 기간, 산출물로 구성되어 있다.

 

166 프로젝트 팀 구성

분산형 팀	팀원 모두가 의사 결정에 참여하는 비이기적인 구성 방식(민주주의식 팀) 의사 결정을 민주주의식으로 하며 팀 구성원의 참여도와 작업 만족도를 높이고 이직률을 낮게 함 팀 구성원 각자가 서로의 일을 검토하고 다른 구성원이 일한 결과에 대하여 같은 그룹의 일원으로 책임을 지며, 장기 프로젝트 개발에 적합함 의사소통 경로의 수 = n(n-1)/2 (n:팀원 수)
중앙 집중형 팀	한 관리자가 의사결정을 하고, 팀 구성원들은 그 결정을 따르는 구성 방식(책임 프로그래머 팀) 프로젝트 수행에 따른 모든 권한과 책임을 한 관리자에게 위임하고, 기술 및 관리 지원을 위해 인력을 투입하는 형태 의사결정이 빠르고, 의사 교환 경로를 줄일 수 있음 한 사람에 의하여 통제할 수 있는 비교적 소규모 문제에 적합함 책임 프로그래머 역할:요구 분석 및 설계, 중요한 기술적 판단, 프로그래머에게 작업 지시 및 배분 등 프로그래머 역할:책임 프로그래머의 지시에 따른 원시코드 작성, 테스트, 디버깅, 문서 작성 등 프로그램 사서 역할:프로그램 리스트, 설계 문서, 테스트 계획 등을 관리 보조 프로그래머 역할:책임 프로그래머의 업무 지원, 여러 가지 기술적인 문제에 대한 자문, 사용자, 품질 보증 담당자 등의 헙외 책임 프로그래머 감독하에 분석, 설계, 구현 담당
계층적팀	분산형 팀 구성과 중앙 집중형 팀 구성을 혼합한 형태(혼합형 팀) 5~7명의 초보 프로그래머를 작은 그룹으로 만들어 각 그룹을 고급 프로그래머가 관리하게 함 경험자(고급 프로그래머)와 초보자를 구별함 프로젝트 리더와 고급 프로그래머에게 지휘 권한을 부여하고, 의사 교환은 초급 프로그래머와 고급 프로그래머로 분산함

 

167 품질 표준

• 명확하게 정의된 S/W의 특성을 의미하며, S/W의 품질을 평가하는 기준 항목이다.

• 종류

  종류	의 미
  정확성	사용자의 요구 기능을 충족시키는 정도
  (Correctness)
  신뢰성	정확하고 일관된 결과를 얻기 위해 요구된 기능을 오류 없이 수행하는 정도
  (Reliability)
  효율성	요구되는 기능을 수행하기 위해 필요한 자원의 소요 정도
  (Efficiency)
  무결성	허용되지 않는 사용이나 자료의 변경을 제어하는 정도
  (Integrity)
  사용 용이성	사용에 필요한 노력을 최소화하고 쉽게 사용할 수 있는 정도
  (Usability)
  유지보수성	변경 및 오류 사항의 교정에 대한 노력을 최소화 하는 정도
  (Maintainability)
  유연성	S/W를 얼마만큼 쉽게 수정할 수 있는가 하는 정도
  (Flexibility)
  시험 역량	의도된 기능을 수행하도록 보장받기 위해 프로그램을 시험할 수 있는 정도
  (Testability)
  이식성	다양한 H/W 환경에서도 운용 가능하도록 쉽게 수정할 수 있는 정도
  (Portability)
  재사용성	전체나 일부 S/W를 다른 목적으로 사용할 수 있는가 하는 정도
  (Reusability)
  상호 운용성	다른 S/W와 정보를 교환할 수 있는 정도
  (Interoperability)

 

168 품질 보증/정형 기술 검토/검토 회의/검열

169 위험 관리

• 프로젝트 추진 과정에서 예상되는 각종 돌발 상황(위험)을 미리 예상하고 이에 대한 적절한 대책을 수립하는 일련의 활동이다.
• S/W 개발 시 일반적인 위험 요소에는 인력 부족, 예산 관리, 일정 관리, 사용자 요구변경 등이 있으며, 이중 가장 대표적인 위험 요소는 사용자 요구 변경이다.
• 위험은 불확실성과 손실을 내재하고 있으며, 위험 관리는 이러한 위험의 불확실성을 감소시키고, 손실에 대비하는 작업니다.
• 위험 관리의 절차

 

170 형상 관리(SCM)

• S/W 개발 과정에서 S/W의 생산물을 확인하고 S/W 통제, 변경 상태를 기록하고 보관하는 일련의 관리 작업이다.
• S/W 변경의 원인을 알아내고 제어하며 적절히 변경되고 있는지 확인하여 해당 담당자에게 통보하는 작업이다.
• S/W 개발의 전 단계에 적용되는 활동으로, 유지보수 단계에서 수행된다.
• S/W 개발의 전체 비용을 줄이고, 개발 과정의 여러 문제점을 해결하여 방해 요인을 최소화하는 것을 목적으로 한다.
• S/W 형상 항목:정의 단계의 문서, 개발 단계의 문서와 프로그램, 유지보수 단계의 변경 사항 등

 

171 요구사항 분석

요구사항 분석 작업

요구사항 분석의 어려움

요구사항 분석가의 자질

 

172 자료 흐름도(DFD)

 

173 자료 사전(DD)

 

174 HIPO

• 시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타낸다.
• 기본 시스템 모델은 입력, 처리, 출력으로 구성되며, 하향식 S/W 개발을 위한 문서화 도구이다.
• 체계적인 문서 관리가 가능하고, 기호, 도표 등을 사용하므로 보기 쉬우며 이해하기도 쉽다.
• 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
• HIPO의 종류
  • 가식적 도표(도식 목차):시스템의 전체적인 기능과 흐름을 보여주는 계층(Tree) 구조도
  • 총체적 도표(개요 도포,총괄 도표):프로그램을 구성하는 기능을 제고하는 도표
  • 세부적 도표(상세 도표):총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

 

175 구조적 설계의 주요 기본 원리

모듈화(Modularity)	S/W를 모듈 단위로 나누는 것
추상화 (Abstraction)	문제의 세부 사항을 먼저 설계하기보다는 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 설계 방법 기능 추상화:입력 자료를 출력 자료로 변환하는 과정을 추상화하는 방법 제어 추상화:제어의 정확한 메커니즘(절차, 방법)을 정의하지 않고 원하는 효과를 정하는 데 이용하는 방법 자료 추상화:자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법
정보 은닉 (Information Hiding)	한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법 모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이함
프로그램 구조	S/W의 구성 요소인 모듈의 계층적 구성을 나타내는 것(제어 계층 구조) 프로그램의 순서, 선택, 반복과 같은 S/W의 절차적인 처리 과정을 나타내지 않음 공유도(Fan-In):어떤 모듈을 제어(호출)하는 모듈의 수 제어도(Fan-Out):어떤 모듈에 의해 제어(호출)되는 모듈의 수 주종적 모듈(Superordinate):다른 모듈을 제어(호출)하는 모듈 종속적 모듈(Subordinate):어떤 모듈에 의해 제어되는 모듈
자로 구조	자료 사이의 논리적인 관계를 표현한 것으로 자료의 구성, 결합 정도, 접근 방법 등을 나타냄

 

176 바람직한 설계의 특징

• 설계는 S/W 구조를 나타내야 한다.
• 독립적인 기능적 특성을 가진 요소(모듈)로 구성되어야 한다.
• 모듈 구조, 즉 특정 기능 또는 부기능을 수행하는 논리적 요소들로 분리되는 구조를 가져야 한다.
• S/W 요소(모듈)간의 효과적인 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 한다.
• 자료와 프로시저에 대한 분명하고 분리된 표현을 포함해야 한다.
• 모듈 간과 외부 개체 간의 연결 복잡성을 줄이는 인터페이스를 가져야 한다.
• 요구사항 분석에서 얻어진 정보를 이용하여 반복적인 방법으로 이루어져야 한다.

 

177 결합도(Coupling)

• 모듈 간에 상호 의존하는 정도를 나타낸다.
• 독립적인 모듈이 되기 위해서는 각 모듈 간의 결합도가 약해야 하며 의존하는 모듈이 적어야 한다.
• 결합도의 종류:자료 결합도<스탬프 결합도<제어 결합도<외부 결합도<공통 결합도<내용 결합도)
• 결합도
  • 자료 결합도(Data Coupling):모듈간의 인터페이스가 자료로만 구성될 때
  • 스탬프 결합도(Stamp Coupling):배열이나 레코드 등의 자료 구조가 전달될 때
  • 제어 결합도(Control Coupling):논리적인 흐름을 제어하는 데 사용하는 제어 요소(Function code, switch, tag, flag)가 전달될 때
  • 외부 결합도(External Coupling):외부로 선언한 데이터(변수)를 다른 모듈이 사용할 때
  • 공통 결합도(Common Coupling):공유되는 데이터 영역을 여러 모듈이 사용할 때
  • 내용 결합도(Content Coupling):한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때

178 응집도(Cohesion)

• 정보 은닉 개념을 확장한 것으로 모듈 안의 요소들이 서로 관련되어 있는 정도, 즉 모듈이 독립적인 기능으로 정의되어 있는 정도를 나타낸다.
• 독립적인 모듈이 되기 위해서는 각 모듈의 응집도가 강해야 한다.
• 응집도 종류:우연적 응집도<논리적 응집도<시간적 응집도<절차적 응집도<교환적 응집도<순차적 응집도<기능적 응집도)

  응집도 종류	설 명
  기능적	모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
  (Functional)
  순차적	모듈 내의 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도
  (Sequential)
  교환(통신)적	동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
  (Communication)
  절차적	모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
  (Procedual)
  시간적	특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
  (Temporal)
  논리적	유사한 성격을 갖거나 특정 형태로 분류되는 처리요소들로 하나의 모듈이 형성되는 경우의 응집도
  (Logical)
  우연적	모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도
  (Coincidental)

 

179 효과적인 모듈화 설계 방안

• 결합도는 줄이고 응집도는 높여서 모듈의 독립성을 높인다.
• 모듈의 제어 영역 안에서 그 모듈의 영향 영역을 유지시킨다.
• 복잡도와 중복성을 줄이고 일관성을 유지시킨다.
• 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안 된다.
• 유지보수가 용이해야 한다.
• 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해한다.
• 하나의 입구와 하나의 출구를 갖도록 해야 한다.
• 인덱스 번호나 기능 코드들이 전반적인 처리 논리 구조에 예기치 못한 영향을 끼치지 않도록 모듈 인터페이스를 설계해야 한다.

 

180 N-S 차트(Nassi-Schneiderman Chart)

• 논리의 기술에 중점을 둔 도형을 이용한 표현 방법(박스 다이어그램, Chapin Chart)이다.
• 순차(연속, Sequence) 구조, 반복(While, Do~Until) 구조, 선택(If~Then~else) 구조, 다중 선택(Cause) 구조 등을 표현한다.
• GOTO나 화살표를 사용하지 않으며, 선택과 반복 구조를 시각적으로 표현한다.
• 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합하다.
• 이해하기 쉽고, 코드 변환이 용이하다.
• 읽기는 쉽지만 작성하기가 어려우며, 임의로 제어를 전이하는 것이 불가능하다.

 

181 구현/프로그래밍 언어 선정 기준/구조적 프로그래밍

구현

프로그래밍 또는 코딩 단계라고도 하며, 각 모듈을 특정 프로그래밍 언어를 이용하여 원시 코드로 작성하고 문서화하는 작업

프로그래밍 언어 선정 기준

 

구조적 프로그래밍

• Dijkstra에 의해 제안된 것으로, 신뢰성 있는 S/W의 생산과 코딩의 표준화 등을 위해 개발된 방법이다.
• 구조적 프로그래밍의 기본적인 제어 구조
  • 순차(Sequence):명령을 순서적으로 나열함
  • 선택(Selection):특정 논리에 기초하여 명령을 선택함
  • 반복(Iteration):순환을 제공함

 

182 화이트 박스 테스트(White Box Test)

• 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 검사하여 검사 사례를 설계하는 방법이다.
• 설계된 절차에 초점을 둔 구조적 테스트로, 프로시저 설계의 제어 구조를 사용하여 검사 사례를 설계하며, 테스트 과정의 초기에 적용된다.
• 모듈 안의 작동을 직접 관찰할 수 있다.
• 원시 코드의 모든 문장을 한 번 이상 수행함으로써 수행된다.
• 프로그램의 제어 구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적 경로를 제어한다.
• 각 조건에서의 참과 거짓의 모든 논리적 결정이 적어도 한 번 이상 실행된다.
• 논리 흐름도, 루프 구조, 순환 복잡도에 관한 오류를 찾을 수 있다.
• 종류
  • 기초 경로 검사(Basic Path Testing)
  • 조건 검사(Condition Testing)
  • 루프 검사(Loop Testing)
  • 데이터 흐름 검사(Data Flow Testing)

 

183 제어 흐름도/순환 복잡도

 

184 블랙 박스 테스트(Black Box Test)

• S/W 인터페이스에서 실시되는 검사로, S/W가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 검사로, 기능 검사라고도 한다.
• 부정확하거나 누란 된 기능, 인터페이스 오류, 자료 구조나 외부 DB 접근에 따른 오류, 행위나 성능 오류, 초기화와 종료 오류 등을 발견하기 위해 사용되며 테스트 과정의 후반부에 적용된다.
• S/W 산물의 각 기능별로 적절한 정보 영역(입ㆍ출력)을 정하여 적합한 입력에 대한 출력의 정확성을 점검한다.
• 종류
  • 동치 분할(Equivalence Partitioning) 검사
  • 경계값 분석(Boundary Value Analysis)
  • 원인-효과 그래프(Cause-Effect Graghing) 검사
  • 오류 예측 검사(Fault Based)
  • 비교(Comparison) 검사 등

 

185 검사 전략

단위검사

• 코딩이 이루어진 후 S/W 설계의 최소 단위인 모듈에 초점을 맞추어 검사하는 것.
• 화이트 박스 검사 기법을 사용하며, interface, 외부적 I/O, 자료 구조, 경계 조건 등을 검사

하향식 통합 검사

• P/G의 상위 모듈에서 하위 모듈 방향으로 통합하면서 검사하는 기법이다
• 일시적 필요한 조건만을 가지는 임시로 제공되는 시험용 모듈 스터브(Stub)가 필요하다.

상향식 통합 검사

• P/G의 하위 모듈에서 상위 모듈 방향으로 통합하면서 검사하는 기법이다.
• 가장 하위 단계의 모듈부터 통합 및 검사가 수행되므로 스터브(Stub)는 필요하지 않지만, 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터가 필요하다.

검증(확인, 인수) 검사

• S/W가 사용자의 요구사항을 충족시키는가에 중점을 두고 검사하는 방법이다.
• 통합 검사가 끝난 후 전체가 하나씩 S/W 단위로 통합되어 요구사항 명세서를 토대로 진행하며, 블랙 박스 테스트 기법을 사용한다.
• 검증 검사의 종류
  • 형상 검사(구성 검토, 감사):S/W 구성 요소, 목록, 유지보수를 지원하기 위해 필요한 모든 사항들이 제대로 표현되었는지를 검사하는 기법
  • 알파 검사
    • 개발자의 장소에서 사용자가 개발자 앞에서 행하는 검사 기법
    • 통제된 환경에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 기록함
  • 베타 검사
    • 선정된 최종 사용자가 여러 명의 사용자 앞에서 수행하는 검사 기법
    • 실제 업무를 가지고 사용자가 직접 시험하는 것으로, 개발자에 의해 제어되지 않은 상태에서 검사가 행해지며, 발견된 오류와 사용상의 문제점을 기록하고 개발자에게 주기적으로 보고함

시스템 검사/디버깅

• 시스템 검사:개발된 S/W가 해당 컴퓨터 시스템에서 완벽하게 수행하는가를 검사하는 것으로 종류에는 복구 검사, 보안 검사, 강도 검사, 성능 검사 등이 있음
• 디버깅:검사 단계에서 검사 사례에 의해 오류를 찾은 후 그 오류를 수정하는 과정으로, 디버깅 접근법에는 맹목적 강요, 역추적, 원인 제거 등이 있다.

 

186 유지보수

• 개발된 S/W의 품질을 항상 최상의 상태로 유지하기 위한 것으로 S/W 개발 단계 중 가장 많은 노력과 비용이 투입되는 단계이다.
• S/W가 사용자에게 인수되고, 설치된 후 발생하는 모든 공학적 작업이다.
• S/W 유지보수를 용이하게 하려면 시험 용이성, 이해성, 수정 용이성, 이식성 등이 고려되어야 한다.
• 유지보수의 유형
  • 수정(Corrective) 보수=수리ㆍ교정ㆍ정정ㆍ하자 보수
    • 시스템을 운영하면서 검사 단계에서 발견하지 못한 오류를 찾아 수정하는 활동
  • 적응(Adaptive) 보수=환경 적응, 조정 보수
    • S/W의 수명 기간 중에 발생하는 환경의 변화(H/W, OS 등)를 기존의 S/W 산물에 반영하기 위하여 수행하는 활동
  • 완전화(Perfective) 보수=기능 개선, 기능 보수
    • S/W의 본래 기능에 새로운 기능을 추가하거나 성능을 개선하기 위해 S/W를 확장시키는 활동
    • 유지보수 활동 중 가장 큰 업무 및 비용을 차지하는 활동
  • 예방(Preventive) 보수
    • 미래에 유지보수를 용이하게 하거나 기능을 향상시키기 위해 소프트웨어를 변경하는 활동

 

187 외계인 코드

• 아주 오래 전에 개발되어 유지보수 작업이 매우 어려운 프로그램이다.
• 일반적으로 15년 전 또는 그 전에 개발된 프로그램을 의미하며, 프로그램 내에 문서화(Documentation)를 철저하게 해두면 외계인 코드를 방지할 수 있다.

 

188 객체지향 기법

 

189 객체지향 기법의 주요 기본 원칙

캡슐화

• 데이터와 데이터를 처리하는 함수를 하나로 묶는 것
• 캡슐화된 객체의 세부 내용이 외부에 은폐되어, 변경이 발생해도 오류의 파급 효과가 적음
• 캡슐화된 객체들은 재사용이 용이함
• 인터페이스가 단순해지고 객체 간의 결합도가 낮아짐

정보 은닉(은폐)

• 각 객체의 수정이 다른 객체에게 주는 영향을 최소화하는 기술

상속성

• 이미 정의된 상위 클래스(슈퍼 클래스나 부모 클래스)의 모든 속성과 연상을 하위 클래스가 물려 받는 것
• 상속성을 이용하면 하위 클래스는 상위 클래스의 모든 속성과 연산을 자신의 클래스 내에서 다시 정의하지 않고서도 즉시 자신의 속성으로 사용할 수 있음
• 다중 상속성(Multiple Inheritance):한 개의 클래스가 2개 이상의 상위 클래스로부터 속성과 연산을 상속받는 것

추상화

• 불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에만 중점을 두어 개략화하는 것, 즉 모델화하는 것
• 인간이 복잡한 문제를 다루는 데 가장 기본이 되는 방법으로, 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러 가지 요인들을 테스트할 수 있음

다형성(Polymorphism)

• 메시지에 의해 객체(클래스)가 연산을 수행하게 될 때 하나의 메시지에 대해 각 객체(클래스)가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
• 객체(클래스)들은 동일한 메소드 명을 이용하여 같은 의미의 응답을 함

 

190 럼바우(Rumbaugh)의 분석 기법

• 모든 S/W 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법이다.
• 분석 활동은 객체 모델링, 동적 모델링, 기능 모델링 순으로 이루어진다.
  • 객체(Object) 모델링:시스템에서 요구되는 객체를 찾아내어 속성과 연산식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표현한 것
  • 동적(Dynamic) 모델링:상태도를 이용하여 시간의 흐름에 따른 객체들 사이의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현한 것
  • 기능(Functional) 모델링:자료 흐름도(DFD)를 이용하여 다수의 프로세스들간의 자료 흐름을 중심으로 처리 과정을 표현한 것

 

191 객체지향 프로그래밍

 

192 S/W의 재사용

• 이미 개발된 인정받은 S/W의 전체 혹은 일부분을 다른 소프트웨어 개발이나 유지에 사용하는 것이다.
• S/W 개발의 품질과 생산성을 높이기 위한 방법으로, 기존에 개발한 S/W와 경험, 지식 등을 새로운 S/W에 적용한다.
• 클래스, 객체 등의 S/W 요소는 S/W 재사용성을 크게 향상시켰다.
• 재사용이 가능한 요소:소스 코드(가장 많이 이용됨), 응용 분야에 관한 지식, 논리적인 데이터 모형, 프로세스 구조, 시험 계획, 설계에 관한 결정, 시스템 구조에 관한 지식, 요구 분석 사항, 문서화, 전문적인 기술과 개발 경험, 품질 보증, 응용 분야 지식 등
• S/W 부품(모듈)의 크기가 작고 일반적인 설계일수록 재사용률이 높다.
• 소프트웨어 재사용의 이점:개발 시간과 비용 단축, S/W 품질 및 생산성 향상, 프로젝트 실패 위험 감소, 시스템 구축 방법에 대한 지식 공유, 시스템 명세, 설계, 코드 등 문서 공유

 

193 S/W 재공학

 

194 CASE

• S/W 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 S/W 도구를 사용하여 자동화하는 것이다.
• 소프트웨어 생명 주기의 전체 단계를 연결해 주고 자동화 해주는 통합된 도구를 제공해주는 기술이다.
• 소프트웨어 개발 도구와 방법론이 결합된 것으로, 정형화된 구조 및 방법(메커니즘)을 소프트웨어 개발에 적용하여 생산성 향상을 구현하는 공학  기법이다.
• 소프트웨어 개발의 모든 단계에 걸쳐 일관된 방법론을 지원한다.
• CASE 사용의 이점:소프트웨어 개발 기간 단축 및 비용 절감, 품질 향상, 유지보수 용이, 생산성 향상, 재사용성 향상 등
• CASE의 분류
  • 상위(Upper) CASE:소프트웨어 생명 주기의 전반부에서 사용되는 것으로, 문제를 기술(Description)하고 계획하며 요구 분석과 설계 단계를 지원하는 CASE
  • 하위(Lower) CASE:소프트웨어 생명 주기의 하반부에서 사용되는 것으로 코드의 작성과 테스트, 문서화하는 과정을 지원하는 CASE
  • 통합(Integrate) CASE:소프트웨어 생명 주기에 포함되는 전체 과정을 지원하기 위한 CASE

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.