본문 바로가기

자격증/정보처리기사 자격증 공부

정처기 시험 요약 정리 (외울 것) - 1장

반응형
더보기

1장

 


001. 소프트웨어 생명주기

  • 나선형 모델의 4가지 주요 활동
    • 1) 계획수립 2) 위험 분석 3) 개발 및 검증 4) 고객 평가
  • 애자일 방법론에 해당하는 것은?
    • 1) 스크럼
    • 2) XP(eXtreme Programming)
    • 3) 칸반 (Kanban)
    • 4) Lean
    • 5) 기능 중심 개발 (FDD, Feature Driven Development)

002. 스크럼

  • 스크럼 개발 프로세스
    • 1) 스프린트 계획 회의
    • 2) 스프린트
    • 3) 일일 스크럼 회의
    • 4) 스프린트 검토 회의
    • 5) 스프린트 회고

003. XP

  • XP의 주요 실천 방법
    • 1) 짝 프로그래밍(Pair Programming)
    • 2) 공동 코드 소유 (Collective Ownership)
    • 3) 테스트 주도 개발 (Test-Driven Development)
    • 4) 전체 팀 (Whole Team)
    • 5) 계속적인 통합 (Continuous Integration)
    • 6) 리팩토링 (Refactoring)
    • 7) 소규모 릴리즈 (Small Releases)
  • 리팩토릭의 개념
    • 프로그램 기능의 변경 없이 시스템을 재구성하는 것
    • 목족 : 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함.
  • XP의 5가지 핵심 가치 -> 의사가 단순해야 용기를 얻고, 사람들이 존중을 하고 피드백을 하지!
    • 1) 의사소통
    • 2) 단순성
    • 3) 용기
    • 4) 존중
    • 5) 피드백

004 개발 기술 환경 파악

  • DBMS 관련 요구사항 식별 시 고려사항 -) 가성기가 상구만원이네
    • 1) 가용성
    • 2) 성능
    • 3) 기술 지원
    • 4) 상호 호환성
    • 5) 구축 비용
  • 오픈 소스
    • 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어이다.
    • 오픈 소스 관련 요구사항 식별 시 고려사항
      • 라이선스 종류
      • 사용자 수
      • 기술의 지속 가능성

005. 요구사항 정의 -> 요구사항의 정의에 대해 알았으니까 다음으로 요구사항 개발 프로세스(어떤 정규화된 방법에 따라 요구사항을 도출하는지 알아야겠지?)

  • 요구사항의 4가지 유형
    • 기능 요구사항
    • 비기능 요구사항
    • 사용자 요구사항
    • 시스템 요구사항
    006. 요구사항 개발 프로세스
    • 요구사항 개발 프로세스 -> 도수가 분명 확인을 했어
      • 1) 도출
        • 2) 분석
        • 3) 명세
        • 4) 확인
    • 요구사항을 도출하는 주요 기법
      • 청취와 인터뷰
        • 설문
        • 브레인스토밍
        • 워크샵
        • 유스케이스
        • 프로토타이핑
    • 요구사항 명세 단계에서는
      • 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미한다.
        • 기능 요구사항을 빠짐없이 기술한다.
        • 비기능 요구사항은 필요한 것만 기술한다.
        • 소단위 명세서가 사용될 수 있다.
    • 요구사항 명세 기법
      • 정형 명세 기법
        • 수학적 원리 기반
        • 도구 종류
          • VDM, Z , Petri-net, CSP등
            • 비정형 명세 기법
        • 상태/기능/객체 중심
        • 도구 종류
          • FSM, Decistion Tree, ER 모델링, State Chart(SADT)

007. 요구사항 분석

  • 주요 구조적 분석 기법 도구
    • 자료 흐름도
      • 자료 사전
      • 소단위 명세서
      • 개체 관계도
      • 상태 전이도
      • 제어 명세서
  • 자료 흐름도의 4가지 구성 요소
    • 프로세스
      • 자료 흐름
      • 자료 저장소
      • 단말

008. 요구사항 분석 CASE와 HIPO

  • CASE(자동화 도구) -> 요구사항에 대한 분석과 명세를 자동화 해주는 도구를 말합니다.
    • 대표적인 요구사항 분석용 CASE ( SS, ST, PPM,
      • SREM = RSL/REVS
        • TRW사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 도구
      • PSL / PSA
        • 미시간 대학에서 개발
      • TAGS
        • 시스템 공학 방법 응용에 대한 자동 접근 방법
        • 개발 주기의 전 과정에서 이용할 수 있는 통합 자동화 도구입니다.
    • - SADT - SoftTech 사에서 개발 - 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구입니다
  • HIPO (Hierarchy Input Process Output)
    • 시스템의 분석 및 설계 또는 문서화에 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 표현한 것입니다.
    • HIPO chart의 3가지 종류
      • 1) 가시적 도표, 도식목차
      • 2) 총체적 도표, 총괄 도표, 개요 도표
      • 3) 세부적 도표, 상세 도표
    009. UML (Unified Modeling Language) 의 개요
    • UML은 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어이다.
    • UML의 구성 요소
      • 사물
        • 관계
        • 다이어그램
  • 사물의 종류 (구행그주)
    • 구조 사물
    • 행동 사물
    • 그룹 사물
    • 주해 사물

10. UML - 관계

  • 관계는 사물과 사물 사이의 연관성을 표현하는 것이다.
  • 관계의 종류
    • 1) 연관 관계
    • 2) 집합 관계 -> 서로 독립되는 관계 ( 컴퓨터와 프린터 )
    • 3) 포함 관계 -> 서로 독립될 수 없는 관계 (문과 키)
    • 4) 일반화 관계
    • 5) 의존 관계
    • 6) 실체화 관계

11. UML - 다이어 그램

  • 사물과 관계를 두형으로 표현한 것이다.
  • 정적 모델링의 경우 -> 구조 다이어그램을 사용
  • 동적 모델링의 경우 -> 행위 다이어그램을 사용
  • 구조적 다이어그램의 종류
    • 1) 클래스 다이어그램
      • 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현함.
    • 2) 객체 다이어그램
      • 클래스에 속한 사물들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현함.
      • 럼바우 객체지향 분석 기법에서 객체 모델링에 사용됨.
    • 3) 컴포넌트 다이어그램
      • 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현함.
      • 구현 단계에서 사용됨 -> 구현단계는 코딩하는 단게!
    • 4) 배치 다어이그램
      • 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현함.
      • 코딩단계에서 사용됨
    • 5) 복합체 구조 다이어그램
      • 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현함.
    • 6) 패키지 다이어그램
      • 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현함.
  • 행위 다이어그램의 종류
    • 1) 유스케이스 다이어그램
      • 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용함.
      • 액터와 유스케이스로 구성됨
    • 2) 순차 다이어그램
      • 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현함.
    • 3) 커뮤니케이션 다이어그램
      • 동작에 참여하는 객체들이 주고 받는 메시지와 객체들 간의 연관관계를 표현함.
    • 4) 상태 다이어그램
      • 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현함.
      • 럼바우 객체지향 분석 기법에서 동적 모델링에 사용됨.
    • 5) 활동 다이어그램
      • 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현함.
        활동 다이어그램의 예시
    • 6) 상호작용 개요 다이어그램
      • 상호작용 다이어그램 간의 제어 흐름을 표현함.
    • 7) 타이밍 다이어그램
      • 객체 상태 변화와 시간 제약을 명시적으로 표현함.
  • 스테레오 타입
    • 길러멧 ( << >> )
    • 주료 표현되는 형태
    • - <<include>> : 연결된 다른 UML 요소에 대해 포함 관계에 있는 경우 - <<extends>> : 연결된 다른 UML 요소에 대해 확장 관계에 있는 경우

12. 유스케이스 다이어그램

  • 기능 모델링
    • 개발될 시스템이 갖춰야 할 기능을 정리한 후 사용자와 함께 정리된 내용을 공유하기 위해 그림으로 표현하는 것.
  • 기능 모델링의 종류
    • 유스케이스 다이어그램
    • 액티비티 다이어그램
  • 유스케이스 구성요소
    • 시스템 / 시스템 범위
    • 유스케이스
    • 액터
    • 관계
      • 포함 -> include -> 공통된 기능을 따로 분리해서, 만들면 이것을 사용하자. ex) 도서대출 -> (include) 도서검색
      • 확장 -> extends -> 유스케이스가 특정 조건에 맞으면, 다른 기능이 실행될 때 사용.
      • 일반화

13. 활동 다이어그램

  • 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
  • 활동 다이어그램의 구성요소
    • 1) 액션과 액티비티
    • - 액션 : 더 이상 분해할 수 없는 단일 작업 - 액티비티 : 몇 개의 액션으로 분해할 수 있는 작업
    • 2) 포크 노드 -> 1개가 두개
    • 3) 조인 노드 -> 2개가 -> 한개
    • 4) 병합 노드 -> 여러 제어흐름이 한 곳으로 합쳐짐 -> 다이아몬드

14. 클래스 다이어그램

  • 클래스 다이어그램 특징
    • 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램이다.
    • 시스템을 구성하는 요소를 문서화하는 데 사용된다.
    • 코딩에 필요한 객체의 속성, 함수 등의 정보를 잘 표현하고 있어 시스템을 모델링하는 데 자주 사용된다.
    • 클래스, 제약조건, 관계 등으로 구성된다.
  • 클래스란?
    • 클래스는 각각의 객체들이 갖는 속성과 메소드를 표현한 것으로 3개의 구획으로 나눠 이름, 속성, 메서드를 표기한다.
  • 연관 클래스란?
    • 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스

연관 클래스의 예시

15. 순차 다이어그램

  • 동적 모델링
    • 시스템의 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호 작용을 표현한 것이다.
    • 시스템 내부 구성 요소들 간에 이루어지는 동작이라는 관점에서 표현한다.
    • 시스템이 실행될 때 구성 요소들 간의 메시지 호출, 즉 오퍼레이션을 통한 상호 작용에 초점을 둔다.
  • 동적 모델링의 종류
    • 순차 다이어그램
    • 커뮤니케이션 다이어그램
    • 상태 다이어그램
  • 순차 다이어그램이란?
    • 순차 다이어그램은 시스템이나 객체들이 메시지를 주고 받으며 상호 작용하는 과정을 그림으로 표현한 것이다.
  • 순차 다이어그램 요소
    • 메시지 : 객체가 상호 작용을 위해 주고받는 메시지
    • 실행 상자 : 객체가 메시지를 주고 받으며 구동되고 있음을 표현함.
    • 생명선 : 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현함. , 객체 소멸이 표시된 기간까지 존재함.

16. 커뮤니케이션 다이어그램

  • 커뮤니케이션 다이어그램
    • 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호작용하는 과정을 액터, 객체, 링크, 메시지 등의 요소를 사용하여 그림으로 표현한 것이다.
    • 동작에 참여하는 객체들이 주고받는 메시지를 표현하는데, 메시지뿐만 아니라 객체들 간의 관계까지 표현한다.
    • 동작에 참여하는 객체들 사이의 관계를 파악하는데 사용된다.
    • 클래스 다이어그램에서 관계가 제대로 표현됐는지 점검하는 용도로도 사용된다.
    • 초기에는 협업 다이어그램이라고 불렸다.
  • 커뮤니케이션 다이어그램 구성요소
    • 액터
    • 객체
    • 링크
    • 메시지17. 상태 다이어그램
  • 상태 다이어그램
    • 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것이다.
    • 어떤 이벤트에 의해 객체 자신이 속한 클래스의 상태 변화나 객체가 다른 객체와 상호 작용하는 과정에서의 상태 변화를 표현한다.
    • 특정 객체가 어떤 이벤트에 의해 상태 변환 과정이 진행되는지 확인하는 데 사용된다.
    • 시스템에서 상태 변환 이벤트를 확인할 필요가 있는 객체만을 대상으로 그린다.
  • 상태 다이어그램의 구성요소
    • 상태 (State)
    • 시작상태
    • 종료 상태
    • 상태 전환
    • 이벤트 (Event)
    • 프레임 (Frame)

18. 패키지 다이어그램

  • 패키지 다이어그램
    • UML 정적 모델링 중 하나이다.
    • 관련있는 객체들을 하나로 묶어 상위 개념으로 추상화한 것이다.
    • 유스케이스나 클래스 등의 요소들을 그룹화하여 의존 관계를 표현한다.
    • 대규모 시스템에서 주요 요소 간의 종속성을 파악하는 데 사용한다.
    • 시스템의 구조를 간략하게 표현할 수 있다
    • 의존 관계를 명확하게 파악할 수 있어서, 불필요한 의존 관계를 제거하거나 간략화함으로써 시스템의 복잡도를 낮출 수 있다.
  • 패키지 다이어그램의 구성 요소
    • 패키지
    • 객체
    • 의존관계
      • import : 패키지에서 가져온 객체들을 직접 사용할 때 쓴다.
      • access : 인터페이스를 통해 패키지 내부 객체에 접근할 때 사용한다.

패키지 다이어그램

19. 소프트웨어 개발 방법론

  • 소프트웨어 방법론은 소프트웨어 개발, 유지보수 등에 필요한 여러 가지 일들의 수행방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것이다.
  • 주요 소프트웨어 개발 방법론
    1. 구조적 방법론
      • 절차
        1. 타당성 검토 단계
        2. 계획 단계
        3. 요구사항 단계
        4. 설계 단계
        5. 구현 단계
        6. 시험 단계
        7. 운용/유지보수 단계
    2. 정보공학 방법론
      • 절차
        1. 정보 전략 계획 수립 단계
        2. 업무 영역 분석 단계
        3. 업무 시스템 설계 단계
        4. 업무 시스템 구축 단계
    3. 객체지향 방법론
      • 절차
        1. 요구 분석 단계
        2. 설계 단계
        3. 구현 단계
        4. 테스트 및 검증 단계
        5. 인도 단계
    4. 컴포넌트 기반 (CBD, Component Based Design) 방법론
      • 절차
        1. 개발 준비 단계
        2. 분석 단계
        3. 설계 단계
        4. 구현 단계
        5. 테스트 단계
        6. 전개 단계
        7. 인도 단계
    5. 제품 계열 방법론
      • 임베디드 소프트웨어를 만드는데 적합한 방법론
      • 영역 공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역이다.
      • 응용 공학 : 제품 요구 분석, 제품 설계, 제품을 구현하는 영역이다.

20. S/W 공학의 발전적 추세

  • 소프트웨어 재사용
    • 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지보수에 사용하는 행위를 말한다.
      • 소프트웨어 재사용 방법
        • 합성 중심 방법 : 블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법이다.
        • 생성 중심 방법 : 추상화 형태로 쓰여진 명세를 구체화하여 프로그램을 만드는 방법
  • 소프트웨어 재공학
    • 기존 시스템을 이용해 보다 나은 시스템을 구축하고, 새로운 기능을 추가해 소프트웨어의 성능을 향상시키는 것
    • 소프트웨어 재공학의 장점
      • 품질 향상
      • 생산성 증가
      • 수명 연장
      • 오류 감사
  • CASE(Computer Aided Software Engineering)
    • 소프트웨어 개발 과정에서 사용되는 1) 요구분석, 2)설계, 3) 구현, 4)검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 소프트웨어 도구를 사용하여 자동화하는 것이다.

21. 비용 산정 기법 - 하향식

  • 하향식 산정 기법
    • 과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법이다.
  • 전문가 감정 기법
  • 델파이 기법

22. 비용 산정 기법 - 상향식

  • 상향식 비용 산정 기법은 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법이다.
  • 주요 상향식 비용 산정 기법
    1. LOC (원시 코드 라인 수) 기법
    2. 개발 단계별 인월수 기법
    3. 수학적 산정 기법
  • LOC 기법
    • 산정 공식
      • 노력 (인월) = 개발 기간 x 투입 인원 = LOC / 1인당 월평균 생산코드 라인 수
      • 개발 비용 = 노력(인월) x 단위 비용(1인당 월평균 인건비)
      • 생산성 = LOC / 노력(인월)
  • 개발 단계별 인원수(Effort Per Task)기법
    • 각 기능을 구현시키는데 필요한 노력을 생명 주기의 각 단계별로 산정한다.

23. 수학적 산정 기법

  • 상향식 비용 산정 기법으로, 경험적 추정 모형, 실험적 추정 모형이라고도 한다.
  • 주요 수학적 산정 기법
    • COCOMO 모형 ( boehm이 제안)
      • 소프트웨어 개발 유형
        1. 조직형
        2. 반분리형
        3. 내장형
      • COCOMO 모형의 종류
        1. 기본형
        2. 중간형
        3. 발전형
    • Putnam 모형
      • 소프트웨어 생명주기의 전과정 동안에 사용될 노력의 분포를 예상하는 모형이다.
    • 기능점수 모형
      • 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며, 총 기능 점수와 영향도를 이용하여 기능점수를 구한 후 이를 이용해서 비용을 산정하는 기법이다.
  • 비용 산정 자동화 추정 도구
    • SLIM (Putnam 모형 기반)
    • ESTIMACS ( FP 모형 기반)

24. 프로젝트 일정 계획

  • PERT (Program Evaluation and Review Technique, 프로그램 평가 및 검토 기술)
    • 필요한 전체 작업의 상호 관계를 표시하는 네트워크이다.
    • 각 작업별로 다음에 따라 기간을 예상한다.
      • 낙관적인 경우 -> Ex) 1
      • 가능성이 있는 경우 -> ex) 2
      • 비관적인 경우 -> ex) 3
  • CPM (Critical Path Method, 임계 경로 기법)
    • 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법이다.
  • 간트 차트
    • 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표이다.

25. 소프트웨어 개발 방법론 결정

  • 소프트웨어 개발 방법론을 결정한다는 의미는 ?
    -> 프로젝트 관리와 재사용 현황을 소프트웨어 개발 방법론에 반영시키고, 확정된 소프트웨어 생명 주기와 개발 방법론에 맞추어 소프트웨어 개발 단계, 활동, 작업, 절차 등을 정의하는 것이다.
  • 즉 소프트웨어 개발 방법론을 결정하기 위해서는 "프로젝트 관리"에 대한 내용과 "소프트웨어 재사용에 대한" 내용이 만들어져있어야 한다.
  • 프로젝트 관리?
    • 주어진 기간 내에 최소한의 비용으로 사용자를 만족시키는 시스템을 만들기 위한 전반적인 활동.
      • 프로젝트 관리 유형 (일, 비, 인, 위, 품)
        • 일정 관리
        • 비용 관리
        • 인력 관리
        • 위험 관리
        • 품질 관리26. 소프트웨어 개발 표준
  • 소프트웨어 개발 단계에서 수행하는 "품질 관리"에 사용되는 국제 표준을 의미합니다.
  • 주요 소프트웨어 개발 표준
    1. ISO/IEC 12207
    2. CMMI(능력 성숙도 통합 모델)
    3. SPICE(소프트웨어 처리 개선 및 능력 평가 기준)
  • ISO / IEC 12207 -> 프로세스 관리를 위한 것.
    • ISO에서 만든 소프트웨어 생명 주기 프로세스이다.
      • 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명주기 표준을 제공한다.
    • ISO / IEC 12207 구분
      • 기본 생명 주기 프로세스
      • 지원 생명 주기 프로세스
      • 조직 생명 주기 프로세스
  • CMMI (Capability Maturity Model Integration) -> 프로세스 개발 팀 평가
    • 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델이다.
    • CMMI 소프트웨어 프로세스 성숙도
      1. 초기
        1. 관리
      2. 정의
      3. 정량적 관리
      4. 최적화
  • SPICE (Software Process Improvement and Capability dEtermination) -> 소프트웨어 프로세스 자체를 평가 및 개선
    • 정보 시스템 분야에서 소프트웨어의 품질 및 생산성을 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준이다.
      • 공식 명칭 = ISO/IEC 15504
      • SPICE의 구성
        1. 고객 - 공급자 프로세스
        2. 공학 프로세스
        3. 지원 프로세스
        4. 관리 프로세스
        5. 조직 프로세스
      • SPICE의 프로세스 수행 능력 단계
        1. 불완전
        2. 수행
        3. 관리
        4. 확립
        5. 예측
        6. 최적화

27. 소프트웨어 개발 방법론 테일러링

  • 프로젝트 상황에 맞도록 정의된 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업이다.
  • 테일러링의 수행 절차
    1. 프로젝트 특징 정의
    2. 표준 프로세스 선정 및 검증
    3. 상위 수준의 커스터마이징
    4. 세부 커스터마이징
    5. 테일러링 문서화
  • 테일러링 수행 시 고려사항
    1. 내부적 기준
      • 시스템의 개발 환경과 유형이 서로 다른 경우 테일러링이 필요하다.
      • 요구사항
      • 프로젝트 규모
      • 보유기술
    2. 외부적 기준
      • 법적 제약사항
      • 표준 품질 기준
    28. 소프트웨어 개발 프레임워크
    • 소프트웨어 개발에 공통적으로 사용되는 구성요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러가지기능들을 제공해주는 반제품 형태의 소프트웨어 시스템이다.
    • 스프링 프레임워크
    • 전자정부 프레임워크
    • 닷넷 프레임워크

잘 모르겠는 문제 써놓기


  1. 다음은 현행 시스템을 파악하는 과정에서 수행하는 작업들을 그룹별로 묶어 놓은 것이다. 그룹을 작업 순서대로 나열하시오.

A : 아키텍처 구성 파악, 소프트웨어 구성 파악
B : 하드웨어 구성 파악, 네트워크 구성 파악
C : 시스템 구형 현황 파악, 시스템 기능 파악, 시스템 인터페이스 현황 파악

 

  1. 다음은 현행 시스템 파악 절차 중 하드웨어 구성 파악에 대한 설명이다. 괄호에 공통적으로 들어갈 가장 적절한 용어를 쓰시오.
  • 하드웨어 구성에는 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 ( ) =의 적용 여부를 명시한다.
  • 서버의 ( )란 운용 서버의 장애 시 대기 서버로 서비스를 게속 유지할 수 있도록 운용 서버의 자료 변경이 예비 서버에도 동일하게 복제되도록 관리하는 것으로, 서버의 ( )는 기간 업무의 서비스 기간과 장애 대응 정책에 따라 필요 여부가 결정된다.
더보기

이중화

3. 요구공학(Requirements Engineering)의 개념을 간략히 서술하시오.

더보기

무엇을 개발해야할지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문

4. 요구사항 개발 프로세스 중 요구사항 확인 단계에서의 활동을 간략히 서술하시오.

더보기

요구사항 확인은 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동이다.

5. 다음 설명에 해당하는 요구사항 분석 방법을 쓰시오

- 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법이다.

- 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화한다.

- 자료 흐름도, 자료 사전, 소단위 명세서 등의 도구를 이용하여 모델링한다.

더보기

구조적 분석 기법

6. 요구사항 분석용 CASE에 대해 간략히 서술하시오. 

더보기

요구사항을 자동으로 분석하고, 요구 명세를 기술하도록 개발된 도구

7. 클래스 다이어그램에서 사용되는 연관 클래스의 개념을 간략히 서술하시오.

더보기

연관 클래스는 연관 관계에 있는 클래스 사이에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스이다.

8. 다음은 정보공학 개발 방법론의 수행절차를 나열한 것이다. 괄호에 들어갈 알맞은 답을 쓰시오.

더보기

1. 정보전략 계획 수립 단계

2. 업무 영역 분석

3. 업무 시스템 설계

4. 업무 시스템 구축 단계

9. 소프트웨어 재사용의 개념을 간략히 서술하시오

더보기

소프트웨어 재사용이란 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것이다.

10. 소프트웨어 개발 표준 중 SPICE의 개념을 간략히 서술하시오.

더보기

SPICE는 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준이다.

11. 소프트웨어 프로젝트 관리의 개념을 간략히 서술하시오.

더보기

주어진 기간 내에 최소한의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 전반적인 활동이다.

12. 다음은 CMMI의 소프트웨어 프로세스 성숙도의 단계를 순서대로 나열한 것이다. 괄호에 들어갈 알맞은 단계를 쓰시오.

초기 -> ( ) -> ( ) -> ( ) -> 최적화

더보기

관리, 정의, 정량적 관리

13. 다음이 설명하고 있는 소프트웨어 개발 표준을 쓰시오.

- 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준으로, ISO에서 만들었다.

- 기본 생명 주기 프로세스, 지원 생명 주기 프로세스, 조직 생명주기 프로세스로 구분한다.

더보기

ISO/IEC 12207

14. CMMI(능력 성숙도 통합 모델)의 개념을 간략히 서술하시오

더보기

소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델이다.

15. 소프트웨어 개발 방법론 테일러링이란? 

더보기

프로젝트 상황 및 특성에 맞도록 정의된 소프트웨어 개발 방법론의 절차, 사용기법등을 수정 및 보완하는 작업이다.

 

반응형