정보처리기사 실기 1과목 요약

1 단원 요구사항 확인

1. 소프트웨어 개발 방법론
   1. 소프트웨어 생명주기(SDLC)
      1. 시스템의 요구 분석부터 유지보수 까지 전 공정을 체계화한 절차
      2. 개발때부터 운용과 유지보수를 거쳐 생애를 마칠때까지의 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화
   2. 소프트웨어 생명주기 모델 프로세스
      1. 요구사항 분석 : 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계
      2. 설계 : 실제 수행할수 있도록 수행방법을 논리적으로 결정하는 단계
      3. 구현: 프로그램을 작성하는단계
      4. 테스트 : 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계
      5. 유지보수 : 시스템이 인수되고 설치된 후 일어나는 모든 활동
   3. 소프트웨어 생명주기 모델 종류
      1. 폭포수 모델
         1. 각 단계를 확실히 마무리 지은후에 다음 단계로 넘어가는 모델
         2. 가장 오래된 모델
         3. 고전적 생명주기 모형
         4. 산출물이 명확하고 요구사항 번경이 어려움
         5. 타당섬 검토 → 계획 → 요구사항 분석 → 설계- > 구현 → 테스트 → 유지보수
      2. 프로토타이핑 모델
         1. 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델
         2. 공동의 참조 모델을 제공
         3. 구현 단계의 구현 골격
      3. 나선형 모델
         1. 시스템 개발 시 위험을 최소화 하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
         2. 계획및 정의 → 위험 분석 → 개발 → 고객 평가
      4. 반복적 모델
         1. 개발후 통합, 반복적으로 개발하여 점증 완성시키는 모델
         2. 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델
   4. 소프트웨어 개발 방법론
      1. 소프트웨어 개발 전 과정에서 지속적으로 적용할 수 있는 방법, 절차 ,기법
      2. 하나의 생명체를 간주하고 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론
   5. 소프트웨어 개발 방법론 종류
      1. 구조적 방법론
         1. 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
         2. 하양식 방법론
         3. 나씨-슈나이더만 차트 사용
      2. 정보공학 방법론
         1. 정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
         2. 대형 프로젝트를 수행하는 체계적인 방법론
      3. 객체 지향 방법론
         1. 객체 라는 기본 단위로 시스템을 분석 및 설계하는 방법론
         2. 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론
      4. 컴포넌트 기반 방법론
         1. 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
         2. 개발 기간 단축으로 인한 생산성 향상
         3. 새로운 기능 추가 쉬움, 소프트웨어 재사용이 가능
      5. 애자일 방법론
         1. 절차보다는 사람이 중심, 변화에 유연, 신속 적응적 경량 개발 방법론
      6. 제품 계열 방법론
         1. 공통된 기능을 정의하여 개발하는 방법론
         2. 임베디드 소프트웨어를 작성하는데 유용
   6. 애자일(Agile)
      1. 절차보다는 사람이 중심이 되어 신속 적응적 경량 개발 방법론
      2. 짧고 신속하며 폭포수 모형에 대비되는 방법론
      3. 애자일 방법론 유형
         1. XP
            1. 의사 소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
            2. 1~3주의 반복 개발 주기
            3. 5가지의 가치 와 12개의 실천항목이 존재
            4. 5가지 가치(용단의피존) -
               1. 용기(Courage) : 용기를 가지고 자신감 있게 개발
               2. 단순성(Simplicity) : 필요한것만 하고, 그이상의 것들은 하지 않음
               3. 의사소통(Communication) : 개발자,관리자, 고객 간의 원할한 소통
               4. 피드백(Feedback) : 의사소통에 대한 빠른 피드백
               5. 존중(Respect) : 팀원 간의 상호 존중
            5. 12가지 기본 원칙
               1. 짝프로그래밍(Pair Programming) : 개발자 둘이서 짝으로 코딩하는 원리
               2. 공통 코드 소유(Collecitve Ownership) 언제라도 수정가능하다는 원리
               3. 지속적인 통합 : 매일 여러번씩 소프트웨어를 통합하고 빌드
               4. 계획 세우기 : 고객이 요구하는 비즈니스 가치를 정의, 개발자가 필요한것은 무엇이며 어떤 부분에서 지연될수있는지 알려 주어야 하는 원리
               5. 작은 릴리즈 : 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 한다는 원리
               6. 메타포어 : 고객과 개발자간의 의사소통을 원할하게 한다는 원리
               7. 간단한 디자인 : 가장 단순한 시스템을 설계한다는 원리
               8. 테스트 기반 개발 : 테스트를 먼저 수행하고, 실제 프로그램의 코드를 작성한다는 원리
               9. 리팩토링 : 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리
               10. 40시간 작업 : 일주일에 40시간 이상을 일하지 않아야한다는 원리
               11. 고객 상주 : 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
               12. 코드 표준 : 모든 코드에 대한 코딩 표준을 정의 해야 한다는 원리
         2. 스크럼
            1. 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
            2. 백로그 : 제품과 프로젝트에 대한 요구사항
            3. 스프린트 : 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상
            4. 스크럼 미팅 : 매일 15분정도 미팅으로 To-do list 계획 수립
            5. 스크럼 마스터 : 프로젝트 리더
            6. 스프린트 회고 : 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록
            7. 번 다운 차트 : 백로그 대비 시간을 그래픽적으로 표현한 차트
         3. 린
            1. 도요타의 린 시스템 품질 기법을 소프트웨어 개발 프로세스에 적용
            2. 낭비제거,품질 내재화, 지식창출, 늦은 확정,빠른 인도, 사람 존중, 전체 최적화
   7. 객체 지향 분석 방법론
      1. 객체 지향 분석의 개념
         1. 객체 지향 분석(OOA)은 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스,속성과 연산, 관계를 정의하여 모델링하는 기법
      2. 종류
         1. OOSE : 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용하는 방법론
            1. 분석,설계,구현 단계로 구성
            2. 기능적 요구사항 중심의 시스템
         2. OMT : 그래픽 표기법을 이용하여 소프트웨어 구성 요소를 모델링하는 방법론
            1. 객체모델링 → 동적 모델링 → 기능 모델링
            2. 객체 모델링(Object Modeling) : 정보 모델링 이라고도 함, 시스템에서 요구하는 객체를 찾고 객체들간의 관계를 정의하여 ER다이어그램을 만드는 과정
            3. 동적 모델링(Dynamic Modeling) : 제어흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링,상태 다이어그램을 활용
            4. 기능 모델링(Functional Modeling) : 자료 흐름을 중심으로 처리 과정 표현, 자료 흐름도를 활용하여 표현
         3. OOD : 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론
   8. 비용산정 모형
      1. 개념 : 소프트웨어 규모 파악을 통한 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식
      2. 분류
         1. 하향식 산정 방법
            1. 경험이 많은 전문가에게 비용산정을 의뢰하거나 여러 전문가와 조성자를 통해 산정하는 방식
            2. 전문가판단,델파이 기법
         2. 상향식 산정방법
            1. 세부적인 요구사항 과 기능에 따라 필요한 비용을 게산하는 방식
               1. LOC,Man Month, COCOMO,푸트남,기능점수 모형
      3. LOC(Lines Of Code)
         1. 원리 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정
         2. 예측치를 이용하여 생산성,노력,개발기간등의 비용을 산정
      4. Man Month
         1. 한사람이 1개월 동한 할수 있는 일의 양을 기준
         2. Man Month : LOC / 프로그래머의 월간 생산성
         3. 프로젝트 기간 = Man Month / 프로젝트 인력
      5. COCOMO 모형
         1. 보헴이 제한한 모형, 프로그램 규모에 따라 비용을 산정
         2. 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용
         3. 규모에 따라 조직형,반분리형,임베디드형으로 구분
         4. 조직형(Oragnic Mode) : 5만 라인 이하의 소프트웨어를 개발하는 유형
         5. 반분리형(Semi-Detached Mode) : 단순형과 임베디드형의 중간형, 30만 라인 이하의 소프트웨어를 개발하는 유형
         6. 임베디드형(Embedded Mode) : 초대형 규모, 30만 라인 이상의 소프트웨어를 개발하는 유형
      6. 푸트남 모형
         1. 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
         2. 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초
      7. 기능점수 모형
         1. 요구 기능을 증가시키는 인자별로 가중치를 부여, 요인별 가중치를 합산하여 총 기능의 점수를 계산
         2. 기능점수 = 총 기능 점수 * (0.65 + (0.1) * 총 영향도)
   9. 일정관리 모델
      1. 개념 : 일정 기한 내에 적절하게 완료될수 있도록 관리한느 모델
      2. 주공정법,PRET,중요 연쇄 프로젝트
      3. 주 공정법
         1. 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
         2. 시작과 끝을 나타내는 노드, 노드간을 연결을 통해 공정을 계산하기 위한 액티비티 표기법
      4. PERT
         1. 비관치,중간치,낙관치의 3점 추청 바식을 통해 일정을 관리하는기법
      5. 중요 연쇄 프로젝트 관리
         1. 주 공정 연쇄법으로 자원 제약 사항을 고려하여 일정을 작성하는 기법
2. 현행 시스템 분석
   1. 현행 시스템 파악 개념 : 현행 시스템이 어떤 하위 시스템으로 구성되어있고, 제공 기능 및 연계 정보는 무엇이며 어떤 기술 요소를 사용하는지를 파악하는 활동
   2. 현행시스템 파악 절차
      1. 1단계 - 구성/기능/인터페이스 파악 : 시스템 구성현황,기능,인터페이스 현황 파악
      2. 2단계 - 아키텍처 및 소프트웨어 구성 파악 : 아키텍처 파악, 소프트웨어 구성 파악
      3. 3단계 - 하드웨어 및 네트워크 구성 파악 : 시스템 하드웨어 현황 파악,네트워크 구성파악
   3. 시스템 구성/기능 및 인터페이스 파악
      1. 현행 시스템 구성현황 파악
         1. 조직의 주요 업무를 처리하는 기간업부와 이를 지원하는 지원 업부로 구분하여 파악
         2. 정보 시스템들의 명칭, 주요 기능들을 명시
         3. 모든 정보시스템의 현황 파악이 가능하도록함
      2. 기능 현황 파악
         1. 단위 업무 시스템이 현재 제공하는 있는 기능 파악
         2. 기능등을 주요 기능과 하부 기능으로 구분하여 계층형으로 표시
      3. 인터페이스 현황 파악
         1. 다른 시스템과 주고 받는 데이터의 종류, 데이터의 형식,프로토콜, 연계유형,주기 파악
         2. 데이터형식을 주고받는지, 어떤 통신 규약을 사용하고 있고, 연계유형은 무엇인지 등을 표시
   4. 현행 시스템 아키텍처 및 소프트웨어 구성 파악
      1. 현행 시스템 아키텍처 구성 파악
         1. 계층별로 어떠한 기술요소들을 사용하고 있는지 최상위 수준에서 파악
         2. 아키텍처가 다른 경우에는 가장 핵심이 되는 기간 업부 처리 시스템을 기준으로 파악
      2. 소프트웨어 구성 파악
         1. 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도,라이선스 적용 방식, 라이선스 수 파악
         2. 라이선스 적용 방식의 기준과 보유한 라이선스 수량 파악 중요
   5. 하드웨어 및 네트워크 구성 파악
      1. 하드웨어 구성 파악
         1. 서버의 위치, 운용 서버의 주요 사항과 수향 이중화 구현 여부를 파악
      2. 네트워크 구성 파악
         1. 업무 처리 시스템을 위해 어떤 네트워크 장비를 사용하여 어떻게 구성되어있는지 파악
   6. 소프트웨어 아키텍처
      1. 개념 : 여러가지 소프트웨어 구성요소와 그 구성요소가 가진 특성중에서 외부에 드러나는 특성, 그리고 구성요소간의 관계를 표현하는 시스템의 구조나 구조체이다
      2. 소프트웨어 아키텍처 프레임워크
         1. 소프트웨어 집약적인 시스템에서 아키텍처가 표현해야하는 내용 및 이들간의 관계를 제공하는 아미텍처 기술 표준이다
      3. 구성요소
         1. 아키텍처 명세서 : 아키텍처를 기록하기 위한 산출물들
         2. 이해 관계자 : 시스템 개발에 관련된 모든 사람과 조직
         3. 관심사 : 시스템에 대해 이해관계자들의 서로 다른 의견과 목표
            1. 사용자 입장 : 기본적인 기능, 신뢰성,보안,사용성등의 품질
            2. 유지보수자 입장 : 유지보수의 용이성
            3. 개발자 입장 : 적은 비용과 인력으로 개발
         4. 관점 : 개별 뷰를 개발할때 토대가 되는 패턴이나 양식
            1. 이해 관계자들이 서로 다른 역할이나 책임으로 시스템이나 산출물들에 대해 보고싶은 관점
         5. 뷰
            1. 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템으로 표현
            2. 시스템 대한 아키텍쳐 설명에는 하나 이상의 뷰로 구성
         6. 근거
            1. 아키텍처 결정 근거
            2. 회의 결과, 보고 결과
         7. 목표
            1. 환경 안에서 한명 이상의 이해 관계자들이 의도하는 시스템의 목적,사용,운영 방법
         8. 환경
            1. 시스템에 영향을 주는 요인으로 개발, 운영등의 외부 요인등으로 시스템에 영향을 주는 요인
         9. 시스템
            1. 각 애플리케이션,서브 시스템, 시스템의 집합,제품군 등의 구혀네
      4. 소프트웨어 아키텍쳐 4+1뷰
         1. 개념 : 고객의 요구사항을 정리해 놓은 시나리오를4개의 관점에서 바라보는 소프트웨어 적인 접근 방법, 시스템의 요구사항을 충족시키는지를 증명하기 위해 체크방법으로 유스케이스를 사용
         2. 구성요소
            1. 4+1에서 1은 유스케이스뷰, 4는 논리뷰,구현뷰, 프로세스뷰, 배포뷰
            2. 유스케이스 뷰
               1. 유스케이스 또는 아키텍처를 도출하고 설계하며, 다른 뷰를 검증하는데 사용되는 뷰
               2. 사용자, 설계자, 개발자, 테스트 관점
            3. 논리 뷰
               1. 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
               2. 설계자, 개발자 관점
            4. 프로세스 뷰
               1. 시스템의 비 기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리등을 표현한 뷰
               2. 개발자, 시스템 통합자 관점
            5. 구현 뷰
               1. 소프트웨어 모듈의 구성을 보여주는 뷰
               2. 컴포넌트에 관한 부가적인 정보 정의
            6. 배포 뷰
               1. 아키텍처에 어떻게 배치되는가를 매칭해서 보여주는 뷰
      5. 소프트웨어 아키텍처 패턴
         1. 개념 : 소프트웨어를 설계할때 참조할수있는 전형적인 해결방식
         2. 유형 : 계층화 패턴, 클라이언트-서버 패턴, 파이트-필터 패턴, 브로커 패턴, 모델-뷰-컨트롤러 패턴
         3. 계층화 패턴
            1. 시스템을 계층으로 구분하여 구성하는 패턴
            2. 각 하위 모듈들은 특정한 수준의 추상화 제공, 다음 상위 계층에 서비스를 제공
            3. 서로 마주보는 두개의 계층 사이에서만 상호 작용이 이루어짐
         4. 클라이언트-서버 패턴
            1. 하나의 서버와 다수의 클라이언트로 구성된 패턴
            2. 서버에 서비스를 요청하면 서버는 클라이언트에게 서비스를 제공
         5. 파이프-필터 패턴
            1. 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴
            2. 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템을 넘겨주는 과정을 반복
            3. 재사용이 쉽고, 추가가 쉽기 때문에 확장이 용이
         6. 브로커 패턴
            1. 분산 시스템에서 사용, 원격 서비스를 실행을 통해 상호 작용이 가능한 패턴
         7. 모델-뷰-컨트롤러 패턴
            1. mvc 패넡이라고도 하는 패턴, 모델,뷰,컨트롤러 3개의 서브 시스템으로 구조화하는 패턴
            2. 각 부분이 컴포넌트로 분리되어있어서 서로 영향을 받지 않고 개발 작업 수행 가능
            3. 재사용 가능
      6. 소프트웨어 비용 평가 모델
         1. 아키텍쳐 접근법이 품질 속성에 미치는 영향을 판단하고, 아키텍쳐 의 적합성을 평가하는 모델
         2. SAAM : 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능한 비용 평가 모델
         3. ATAM : 아키텍쳐 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상층관계 까지 평가하는 모델
         4. CBAM : ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결젱에 대한 요구를 충족하는 비용 평가 모델
         5. ADR : 소프트웨어 아키텍처 구성요소간 응징도를 평가하는 모델
         6. ARID : 특정 부분에 대한 품질 요소에 집중하는 비용 평가 모델
      7. 디자인 패턴
         1. 개념
            1. 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계방법을 정리한 패턴
         2. 구성요소
            1. 패턴의 이름 : 사용하는 이름과 디자인 패턴의 유형
            2. 문제 및 배경 : 분야 또는 배경, 해결하는 문제를 의미
            3. 솔루션 : 요소들,관계,협동 과정
            4. 사례 : 간단한 적용 사례
            5. 결과 : 얻게되는 이점 이나 영향
            6. 샘플 코드 : 적용된 원시코드
         3. 유형
            1. 목적(생구행)
               1. 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화,캡슐화를 구생하는 패턴
               2. 구조 : 더큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
               3. 행위 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴
            2. 범위
               1. 클래스 : 클래스간 관련성,컴파일 타임에 정적으로 결정
               2. 객체 : 객체 간 관련성을 다루는 패턴, 런타임에 동적으로 결정
         4. 종류
            1. 생성 패턴(생빌 프로 팩앱싱)
               1. Builder : 복잡한 인스턴스를 조립하여 만드는 구조, 복합 객체를 생성할때는 객체를 생성하는 방법과 객체를 구현 하는 방법을 분리함으로써 동일한 생성 절차에서 서로 다은 표현결과를 만들수 있는 디자인 패턴
               2. Prototype : 일반적인 원형으로 만들어 놓고, 복사한후 필요한 부분만 수정하여 사용하는 패턴
               3. Factory Method : 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고 하위 클래스에서 인스턴스를 생성하는 방식
               4. Abstract Factory : 구체적인 클래스에 의존하지 않고, 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴
               5. Singleton : 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록하는 디자인 패턴
            2. 구조패턴(브데 퍼플 프록 컴어)
               1. Bridge : 기능의 클래스 계층과 구현의 클래스 계층을 연결
               2. Decorator : 클래스에 필요한 기능을 추가해 나가는 설계 패턴
               3. Facade : 복잡한 시스템에 대하여 단순한 인터페이스를 제공
               4. Flyweight : 모두가 갖는 본질적인 요소를 클래스 화 하여 공유, 메모리를 절약, 클래스의 경량화를 목적으로 하는 디자인 패턴
               5. Proxy : 실체 객체에 대한 대리 객체
               6. Composite : 객체들의 관게를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴
               7. Adapter : 클래스를 재사용 할 수 있도록 중간에 맞춰주는 역할을 하는 인터페이스를 만드는 패턴
            3. 행위 패턴(미인이 텝옵 스테 비커 스트메체)
               1. Mediatoer : 객체의 수가 너무 많아지면 서로간 통신을 위해 복잡해져서 객체 지향에서 가장 중요한 느슨한 결합의 특성을 해칠 수 있기 때문에 이를 해결하는 방법으로 중간에 이를 통제하고 지시할수있는 역할을 하는 중재자를 두고, 중재자에게 모든 것을 요구
               2. Interpreter : 언어의 다양한 해석, 구체적으로 구문을 나누고 분리된 구문의 해석을 맡는 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석할수있게 만드는 디자인 패턴
               3. Iterator : 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공하는 디자인 패턴
               4. Template Method : 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체일을 수행하는 구조를 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴
               5. Observer : 한객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락이가고 자동으로 내용이 갱신되는 방법
               6. State : 객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조하게 하는 방식
               7. Visitor : 데이터 구조로부터 처리 기능을 분리하여 별도의 클래스를 만들어 놓고 해당 클랫으의 메서드를 각 클래스를 돌아니면서 특정 작업을 수행하도목 만드는 패턴
               8. Command : 실행된 기능을 캡슐화함으로써 여러 기능을 실행할수있는 재사용성이 높은 클래스를 설게하는 패턴
               9. Strategy : 알고리즘 군을 정의하고 같은 알고리즘을 각각 하나의 클래스로 캡슐화
               10. Memeto : 설계관점에서 객체의 정보를 저장할 필요가 있을때 적용하는 디자인 패턴
               11. Chain Of Responsibility : 하드코딩 되어있을때 기능 처리의 연결이 불가능한데 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리 될수있도록 연결한 디자인 패턴
   7. 분석 산출물 종류
      1. 정보시스템 구성현황
      2. 정보시스템 기능 구성도
      3. 인터페이스 현황
      4. 현행 시스템 아키텍처 구성도
      5. 소프트웨어 구성도
      6. 하드웨어 구성도
      7. 네트워크 구성도
3. 개발 기술 환경 정의
   1. 운영체제 현행 시스템 분석
      1. 운영체제 : 컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할수있도록 해주고, 컴퓨터 사용자와 컴퓨터 하드웨어간의 인터페이스를 담당하는 프로그램
      2. 고려사항
         1. 품질 측면
            1. 신뢰도 : 장기간 운영시 장애 발생 가능성
            2. 성능 : 대규모 및 대량 파일 작업 처리
         2. 지원 측면
            1. 기술 지원 : 안정적인 기술지원,오픈소스 여부
            2. 주변 기기 : 설치 가능한 하드웨어
               1. 주변 기기 지원 여부
            3. 구축 비용
               1. 지원 가능한 하드웨어 비용
               2. 라이선스 정책 및 비용
               3. 유지 및 관리 비용
      3. 운영체제 종류
         1. PC
            1. 윈도즈 : 중/소규모 서버, 일반 PC
            2. 유닉스 : 대용량 처리,안정성 높은 엔터프라이즈급 서버
            3. 리눅스 : 중/대규모 서버 대상, 높은 보안성 제공
         2. 모바일
            1. 안드로이드
               1. 리눅스 운영체제 위에서 구동하며 휴대폰 전화를 비롯한 휴대용 장치를 위한 운영체제와 미들웨어,
            2. IOS
               1. 스마트폰,태플릿PC의 높은 보안성과 고성능 제공
   2. 네트워크 현행 시스템
      1. 네트워크
         1. 컴퓨터 장치들의 노드간 연결을 사용하여 서로에게 데이터를 교환할수 있도록 하는 기술
      2. OSI 7계층
         1. 네트워크 통신에서 생긴 여러 가지 충돌 문제를 안화하기 위해 제시한 네트워크 기본 모델
         2. 응용 계층 : 사용자와 네트워크 간 응용 서비스 연결,데이터 생성(HTTP,FTP)
         3. 표현 계층 : 데이터 형식 설정과 부호 교환, 암/복호화 (JPEG,MPEG)
         4. 세션 계층 : 연결 접속 및 동기제어(SSH,TLS)
         5. 전송 계층 : 신뢰성 있는 통신보장, 분할과 재조립, 흐름 제어, 오류 제어, 혼잡제어(TCP,UDP)
         6. 네트워크 계층 : 최적화된 경로 제공(IP,ICMP)
         7. 데이터링크 계층 : 인접 시스템 간 데이터 전송, 전송 오류 제어(이더넷)
         8. 물리 계층 : 0과1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환(RS-232C)
   3. DBMS 현행 시스템 분석
      1. DBMS : 데이터의 집합을 만들고, 저장 및 관리할수있는 기능들을 제공하는 응용프로그램
      2. 기능 : 중복제어,접근 통제, 인터페이스 제공, 관계 표현등을 제공
         1. 중복 제어 : 중복으로 저장되는 현상 방지
         2. 접근 통제 : 권한에 따라 데이터에 대한 접근제어
         3. 인터페이스 제공 : SQL 및 CLI,GUI등 다양한 인터페이스 제공
         4. 관계 표현 : 다양한 관계를 표현할수 있는 기능 제공
         5. 샤딩/파티셔닝 구조 최적화를 위해 작은 단위로 나누는 기능 제공
         6. 무결성 제약 조건 : 제약 조건을 정의/검사하는 기능 제공
         7. 백업 및 회복 : 발생시 데이터의 보존 기능 제공
      3. 성능 측면
         1. 가용성
            1. 장애 발생 가능성
            2. 백업 및 복구 편의성
            3. 이중화 및 복제 지원 여부
         2. 성능
            1. 대규모 데이터 처리 성능
            2. 대량 거래 처리 성능
            3. 다양한 튜닝 옵션 지원 어뷰
         3. 상호 호환성
            1. 설치 가능한 운영체제 종류
      4. 지원 측면
         1. 기술 지원
            1. 안정적인 기술 지원 여부
            2. 사용자 간의 정보 공유 여부
         2. 구축 비용
            1. 라이선스 정책 및 비용
            2. 유지 및 관리 비용
   4. 미들웨어 현행 시스템분석
      1. 미들웨어 : 응용 프로그램 과 프로그램이 운영되는 환경간에 원만한 통신이 이루어질수있도록 제어해주는 소프트웨어
      2. 운영체제 와 소프트웨어 애플리케이션 사이에 위치
      3. WAS : 서버계층에서 애플리케이션이 동작할수있는 환경을 제공하고 안정적인 트랜잭션 처리 와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버
      4. 성능 측면
         1. 가용성
            1. 운영할때 장애 발생 가능성
            2. 트랜잭션 처리 능력
         2. 성능
            1. 데이터 처리 성능
            2. 가비지컬렉션의 다양한 옵션 기능 여부
      5. 지원 측면
         1. 기술지원
            1. 안정적인 기술 지원 여부,오픈 소스 여부
         2. 구축 비용
            1. 라이선스 정책 및 비용
4. 요구사항
   1. 요구 공학 개념
      1. 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출,분석,명세, 확인 및 검증하는 구조화된 활동
   2. 요구 공학 목적
      1. 의사 소통수단을 제공, 시스템 개발의 요구사항에 대한 공통된 이해를 설정
   3. 분류
      1. 기능적 요구사항과 비기능적 요구사항으로 분류
      2. 기능적 요구사항
         1. 개념 : 시스템이 제공하는 기능,서비스에 대한 요구사항
         2. 도출방법 : 특정 시스템이 어떻게 반응해야 하는지에 대한 기술
         3. 특성 : 기능성,완전성,일관성
      3. 비기능적 요구사항
         1. 개념 : 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항
         2. 도출방법 : 시스템이 갖춰야할 사항에 관한 기술,제한 조건에 관한 기술
         3. 특성: 신뢰성,사용성,효율성,유지보수성, 이식성,보안성 및 품질관련 요구사항, 제약사항
   4. 요구사항 개발 단계 구성
      1. 도출 : 요구사항 소스,도출 기법
         1. 수집방법결정,수집돈 요구사항을 구체적으로 표현하는 단계, 이해관계자와 효율적인 의사소통이 중요
      2. 분석 : 요구사항분류,개념모델링
         1. 도출도니 요구사항에 대해 충돌,중복,누락등의 분석을 통해 완정성과 일관성을 확보하는 단계
      3. 명세 : 시스템 정의서,요구사항 명세서
         1. 체계적으로 검토,평가,승인이 될수 있는 문서를 작성하는 단계
      4. 확인 : 검토,프로토타이핑,모델검증,인수테스트
         1. 요구사항을 이해했는지 확인,요구사항 문서가 회사이 표준에 적합하고,일관성이 있고 완전한지 검증
   5. 요구사항 도출 단계
      1. 인터뷰 : 이해관계자와 직접 대화를 통해 정보를 구하는 공식적,비공식적 정보 수집방법
      2. 브레인스토밍 : 말을꺼내기 쉬운 분위기를 만들어, 회의 참석자들이 내놓은 아이디어들을 비판없이 수용할수있도록 하는 회의
      3. 델파이 기법 : 전문가의 경험적시직을 통한 문제 해결 및 미래예측을 위한 방법
      4. 롤플레잉 : 현실에 일어나는 장면을 설정하고, 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법
      5. 워크숍 : 단기간 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법
      6. 설문조사 : 설문지 또는 여론조사등을 이용
   6. 요구사항 분석 단계
      1. 요구사항 분류 : 요구항이 기능인지 비기능인지 확인하는 활동
      2. 개념 모델링 생성및 분석 : 요구사항을 더 쉽게 이해할수있도록 현실 세계의 상황을 단순화,개념적으로 표현
      3. 요구사항 할당 : 요구사항을 만족시키기 위한 아키텍쳐 구성요소를 식별하는 활동
      4. 요구사항 협상 : 두명의 이해관계자가 서로 상충되는 내용을 요구하는 경우 합의하는 활동
      5. 정형 분석 : 구문 과 의미를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현
      6. 분석 단계 기법
         1. 자료 흐름 지향 분석 : 데이터 흐름도 및 자료 사전으로부터 소프트웨어 구조를 유도하는 방법
         2. 객체 지향 분석 : 시스템의 기능과 데이터를 함께 분석, UML로 표준화
   7. 요구사항 명세 단계
      1. 비정형 명세 기법 : 사용자의 요구를 표현할때 자연어 기반으로 설수하는 기법
      2. 정형 명세 기법 : 수학적인 원리와 표기법으로 서술하는 기법
      3. 검증 항목(명완검 일수 추개)
         1. 명확성 : 하나의 의미만 부여해야함
         2. 완정성 : 기능,성능,속성,인터페이스,설계 제약등에 관한 모든 시스템 요구사항이 포함되어야함
         3. 검증 가능성 : 충족 여부와 달성 정도에 대한 확인이 가능해야함
         4. 일관성 : 상호 모순이 없어야함
         5. 수정 용이성 : 쉽게 수성이 가능해야함
         6. 추적 가능성 : 추적과 상호참조가 가능해야함
         7. 개발 후 이용성 : 운영 및 유지보수에 효과적인 이용이 가능해야함
   8. 요구사항 확인 및 검증 단계
      1. 정형 기술 검토 활용
         1. 동료 검토 : 2~3명이 진행하는 리뷰의 형태,이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행
         2. 워크 스루 : 오류를 조기에 검출하는데 목적, 검토 자료를 회의전에 배포
         3. 인스펙션 : 소프트웨어 요구,설계,원시코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법
         4. 관리 리뷰 : 범위,일정,인력 등에 대한 통제 및 의사결정을 지원하는 리뷰
         5. 기술 리뷰 : 계획 및 명세를 준수하고 있는지에 대한 검토를 수행하는 리뷰
         6. 감사 : 규제,표준,가이드라인,계획,절차를 준수하고 있는지 독립적으로 평가하는 기법