정보처리기사 필기 문제 유형 분석 (13)

안녕하세요. 소복냥입니다.
오늘도 달려봅니다.

* 트랜잭션의 특징

Atomicity 원자성	- 트랜잭션의 연산은 DB에 모두 반영되도록 완료 (commit)되든지, 전혀 반영되지 않도록 복구 (Rollback)해야 합니다. - 트랜잭션 내의 모든 명령은 반드시 완벽히 수행, 모두가 완벽히 수행되지 않고 어느 하나라도 오류발생시, 트랜잭션 전부가 취소되야 합니다.
Consistency 일관성	- 트랜잭션이 실행을 성공적으로 완료하면, 언제나 일관성 있는 DB 상태로 변환 합니다. - 시스템이 가지고 있는 고정요소는 트랜잭션 수행 전과 수행 완료 후의 상태가 같아야 합니다.
Isolation 독립성, 격리성, 순차성	- 둘 이상의 트랜잭션이 동시병행 수행될 경우, 어느 하나의 트랜잭션 실행 중에 다른 트랜잭션의 연산이 끼어들 수 없습니다. -수행중인 트랜잭션은 완료될 때까지 다른 트랜잭션에서 수행결과를 참조 할 수 없습니다.
Durability 영속성, 지속성	- 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영 되어야 합니다.

* 뷰 (view) 설계

뷰 특징

1. 사용자에게 접근이 허용된 자료만 제한적으로 보여주기 위해, 하나 이상의 기본 테이블로 유도된, 이름을 가지는 가상 테이블.
2. 임시적인 작업 (데이터 보정작업, 처리과정 시험)을 위한 용도로 활용.
3. 뷰는 기본 테이블과 같은 형태의 구조 사용, 조작도 거의 같습니다.
4. 가상 테이블이기 때문에, 저장장치 내에 물리적으로 존재(구현)되어있지 않습니다.
5. 데이터의 논리적 독립성 제공.
6. 필요한 데이터만 뷰로 정의해서 처리할 수 있기 때문에, 관리 용이, 명령문 간단.
7. 뷰를 통해서만 데이터에 접근하게 되면, 뷰에 나타나지 않는 데이터를 안전하게 보호하는 효율적인 기법으로 사용할 수 있습니다.
8. 기본 테이블의 기본키를 포함한 속성(열) 집합으로 뷰를 구성해야만 삽입, 삭제, 갱신 연산 가능.
9. 일단 정의된 뷰는 다른 뷰의 정의에 기초될 수 있습니다.
10. 뷰가 정의된 기본 테이블이나, 뷰를 삭제하면, 그 테이블이나 뷰를 기초로 정의된 다른 뷰도 자동 삭제.
11. 조인문 사용 최소화로 사용상의 편의성 최대화.
12. Create, Drop.

장점	단점
- 논리적 데이터 독립성 제공됩니다. - 동일 데이터에 대해 동시에 여러 사용자의 상이한 응용이나 요구를 지원해줍니다. - 사용자의 데이터 관리 간단해집니다. (사용자 데이터 관리 용이) - 접근제어를 통한 자동보안이 제공됩니다 - 데이터 보관이 용이 합니다.	- 독립적인 인덱스 가질수 없습니다. - 뷰의 정의 변경불가합니다. - 뷰로 구성된 내용에 대한 삽입, 삭제, 갱신, 연산에 제약 따릅니다.

* 소프트웨어 공학의 목적

• 소프트웨어 공학은 소프트웨어 위기를 극복하기 위해 개발한 학문으로, 소프트웨어 제품의 품질을 향상하고, 생산성과 작업 만족도 증대, 신뢰도 높은 소프트웨어의 생산 등을 목적으로 하는 학문.
• 소프트웨어를 개발 및 유지보수의 생산성 향상과 품질 향상.
• 유지 보수가 용이하도록 소프트웨어를 개발하여 재사용성을 높일 수 있는 소프트웨어 개발.
• 최소의(최적의) 비용과 자원 안에서 품질 좋은 소프트웨어를 기간 내에 생산하는 것이 소프트웨어의 주된 목적.

* CASE (Computer Aided Software Engineering)

• 소프트웨어 공학의 자동화를 의미하며, 소프트웨어 공학 작업 중 하나의 작업을 자동화한 소프트웨어 패키지를 CASE 도구라 한다. 이러한 도구를 한데 모아놓은 것을 소프트웨어 공학 환경 (Software Engineering Environment)이라 한다.
• CASE 도구들은 소프트웨어 관리들과 실무자들이 소프트웨어 프로세스와 관련된 활동을 지원한다. 즉, 프로젝트 관리 활동을 자동화하고, 프로세스에서 생상 된 결과물을 관리하며, 엔지니어들의 분석, 설계 및 코딩과 테스트 작업을 도와준다.
• CASE의 주요 기능 : 다양한 소프트웨어 개발 모형 지원, 그래픽 지원, 소프트웨어 생명주기 전 단계의 연결.

* 소프트웨어 생명 주기

• 소프트웨어 제작 공정 과정이다.
• 시스템 개발 주기 (System Development Life Cycle : SDLC)라 부른다.
• 개발 단계에서 점차 변화해 가면서 나오는 소프트웨어 형상 (Configuration)을 가시화한다.
• 소프트웨어가 개발되기 위해 정의되고 사용이 완전히 끝나 폐기될 때까지의 전 과정이다.

* 정의 단계

• 무엇 (What)을 개발한 것인지를 명확히 밝히는 단계.
• 시스템 정의와 프로젝트 계획 및 사용자 요구분석을 하는 단계.
• 관리자와 사용자의 참여가 가장 높은 단계.

* 개발 단계

• 어떻게 (How) 개발할 것인지에 대한 절차를 밝히는 단계.
• 설계와 구현, 시험 단계.
• 설계는 품질에 많은 영향을 미치는 단계.

* 지원 단계 (유지보수 단계)

• 수정 및 변경에 관한 문제를 다루는 단계.
• 가장 오랜 시간이 들며 비용이 가장 많이 들어가는 단계.
• 유지보수의 유형 : 완전, 수정, 적응, 예방 유지보수.

* 폭포 수형 모형 (선형순 차 모형, 전형적인 생명주기 모형 : Boehm, 1979)

• 소프트웨어의 개발 시 프로세스에 체계적인 원리를 도입할 수 있는 첫 방법론이다.
• 적용사례가 많고 널리 사용된 방법이다.
• 단계별 산출물이 명확하다.
• 각 단계의 결과가 확인된 후에 다음 단계로 진행하는 단계적, 순차적, 체계적인 접근 방식이다.
• 기존 시스템 보완에 좋다.
• 응용 분야가 단순하거나 내용을 잘 알고 있는 경우 적용한다.
• 비전문가가 사용할 시스템을 개발하는 데 적합하다.

* 계획 단계

• 문제를 파악하고 시스템의 특성을 파악하여 비용과 기간을 예측한다.
• 개발의 타당성을 분석하고 전체 시스템이 갖추어야 할 기본 기능과 성능 요건을 파악한다.

* 요구 분석 단계

• 사용자 요구를 정확히 분석, 이해하는 과정으로 구현될 시스템의 기능이나 목표, 제약사항 등 정확히 파악한다.
• 소프트웨어의 기능, 성능, 신뢰도 등 목표 시스템의 품질을 파악하는 것이다.
• 개발자 (분석가)와 사용자 간의 의사소통이 중요하며, 명확한 기능 정의를 해야 한다.

* 설계 단계

• 요구사항을 하드웨어 또는 소프트웨어 시스템으로 분배하는 과정이다.
• 모든 시스템의 구조를 결정하게 되는데, 소프트웨어 설계는 프로그램의 데이터 구조, 소프트웨어 구조, 인터페이스 표현, 알고리즘의 세부 사항들에 초점을 맞춰 진행한다.

* 구현 단계

• 설계의 각 부분을 실제로 프로그래밍 언어를 이용하여 코드 화하는 단계이다.
• 각 모듈 (module) 단위로 코딩을 한다.

* 시험단계

• 각 프로그램 단위의 내부적으로 이상 여부 및 입력에 따라 요구되는 결과로 작동하는지의 여부를 확인한다.

* 운용 (operation) 및 유지보수 (maintenance) 단계

• 사용자에게 전달되어 실제로 사용되며, 전달 이후에 발생하는 변경이 있다면 변경 요구를 수용하고 계속적인 유지를 해주어야 한다.

* 폭포수 모형의 문제점

• 단계별로 구현되지만, 병행되어 진행되거나 다시 거슬러 올라갈 수 없으며, 반복을 허용하지 않는다.
• 실제 프로젝트가 순차적이라기보다는 반복적인 성향을 가지므로 개발 모델로 적합하지 않은 경우가 많다. 그래서 실제 프로젝트 수행 시 이 모델의 연속적 단계를 따르는 경우가 드물다.
• 시초에 사용자들의 모든 요구사항들을 명확히 설명하는 것이 어렵다.
• 모든 분석은 프로젝트가 시작되기 전에 완성되어야 한다. 즉, 프로그램의 모든 요구사항을 초기에 완전히 파악하도록 요구하므로 개발 프로젝트의 불명확성을 미연에 방지할 수 없다.
• 개발 과정 중에 발생하는 새로운 요구나 경험을 설계에 반영하기 힘들다.

끝까지 읽어주셔서 감사합니다!

정보처리기사 필기 문제 유형 분석 (12)