정보처리기사/실기 정리

정보처리기사 실기 정리 - 1. 요구사항 확인

CUBE 2021. 10. 4. 20:05

1. 요구사항 확인

 

소프트웨어 생명주기

 

시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

 

 

소프트웨어 생명주기 프로세스

 

요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수

 

 

소프트웨어 생명주기 모델

 

1. 폭포수 모델

  • 각 단계를 확실히 마무리 지은 다음 단계로 넘어가는 모델
  • 가장 오래된 모델이자 성공사례가 가장 많은 모델
  • 산출물이 명확하나 요구사항 변경이 어려움

 

2. 나선형 모델

  • 점진적으로 완벽한 시스템으로 개발해 나가는 모델
  • 계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가

 

 

소프트웨어 개발 방법론

 

소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법

 

 

소프트웨어 개발 방법론 종류

 

1. 구조적 방법론

  • 전체 시스템을 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
  • 프로세스 중심의 방법론
  • 나씨-슈나이더만 차트 사용

 

2. 정보공학 방법론

  • 정보시스템 개발에 필요한 관리 절차와 작업 기반을 체계화한 방법론

 

3. 객체지향 방법론

  • 객체라는 기본단위로 시스템을 분석하는 방법론

 

4. 컴포넌트 기반 방법론

  • 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 프로그램을 작성하는 방법론

 

5. 애자일 방법론 

  • 절차보다는 사람이 중심, 변화에 유연하고 신속

 

 

애자일 방법론의 유형

 

1. XP

  • 의사소통 개선과 즉각적 피드백
  • XP의 5가지 가치와 12가지의 기본원리

XP의 5가지 가치

  • 용기, 단순성, 의사소통, 피드백, 존중

XP의 12가지 원리 (중요한 것만)

  • 짝 프로그래밍: 개발자 둘이서 짝으로 코딩
  • 지속적인 통합: 매일 여러 번씩 소프트웨어를 통합하고 빌드
  • 작은 릴리즈: 작은 시스템을 먼저 제작, 짧은 단위로 업데이트
  • 메타포어: 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 함
  • 테스트 기반 설계(TDD): 일단 테스트를 먼저 수행, 그 후 테스트를 통과할 수 있도록 코드 작성
  • 리팩토링: 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화등을 위해 시스템 재구성

 

2. 스크럼

  • 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 방법론
  • 백로그, 스프린트, 번 다운 차트 등

 

3. 린

  • 도요타의 린 시스템 품질기법을 적용한 방법론

 

 

비용 산정 모형

 

1. 하향식 산정 방법

  • 델파이 기법: 전문가의 경험적 지식을 통해 미래를 예측하여 산정

 

2. 상향식 산정 방법

  • LoC 모형: 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 비용을 산정
  • Man Month : 한사람이 1개월 동안 할 수 있는 양 (LoC)/(프로그래머의 월간 생산성)
  • COCOMO 모형: 보헴이 제안한 모형으로 프로그램 규모에 따라 비용 산정, 조직형, 반 분리형, 임베디드형
  • Putnam 모형: 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 방식
  • FP 모형: 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 산정

* 참고

프로젝트 기간= Man Month / 프로젝트 인력

 

 

일정 관리 모델

 

1. 주 공정법(CPM)

  • 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
  • Node(노드) 간의 연결을 통해 계산

 

2. PERT

  • 일의 순서를 계획적으로 정리하기 위해 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리

 

 

현행 시스템 파악 절차

 

구성/기능/인터페이스 파악 -> 아키텍처 및 소프트웨어 구성 파악 -> 하드웨어 및 네트워크 구성 파악

 

 

소프트웨어 아키텍처

 

소프트웨어의 구성요소나 구성요소의 특성, 관계를 표현하는 시스템의 구조

 

 

소프트웨어 아키텍처 4+1 뷰

 

  • 논리 뷰: 기능적인 요구사항 설명
  • 프로세스 뷰: 비기능적인 속성(자원 효율적 사용, 이벤트 처리 등)을 표현한 뷰
  • 구현 뷰: 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
  • 배포 뷰: 물리적인 아키텍처에 어떻게 배치되는가 매핑해서 보여주는 뷰
  • 유스케이스 뷰: 사용자, 설계자, 개발자, 테스트 관점에서 보여주는 뷰

 

 

소프트웨어 아키텍처 패턴

 

  • 계층화 패턴: 시스템을 계층으로 구분하여 구성, 하위 모듈은 추상화하고, 상위 계층에 서비스 제공
  • 클라이언트-서버 패턴: 하나의 서버와 다수의 클라이언트로 구성, 서버는 계속해서 요청 대기
  • 파이프-필터 패턴: 데이터 스트림을 생성하고 처리하는 시스템에서 사용, 서브 시스템이 입력 받아 처리하고, 결과를 다음 서브 시스템이 처리하고를 반복
  • 브로커 패턴: 분산 시스템에서 사용, 브로커 컴포넌트는 컴포넌트 간 통신을 조정하는 역할
  • MVC 패턴: 모델, 뷰, 컨트롤러로 3개의 서브 시스템으로 구성, 각 컴포넌트는 서로 영향받지 않음, 대화형 애플리케이션에 적합

* 참고

Model: 핵심 기능과 데이터 보관

View: 사용자에게 정보 표시

Controller: 사용자로부터 요청을 입력 받아 처리

 

 

소프트웨어 아키텍처 비용 평가 모델

 

  • SAAM: 경험이 없는 조직에서도 활용
  • ATAM: 아키텍처 품질 속성을 만족시키는지 평가하는 모델
  • CBAM: ATAM을 바탕으로 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델
  • ADR: 응집도를 평가하는 모델
  • ARID: 전체 아키텍처가 아닌 특정 부분에 대해 평가하는 모델

 

 

디자인 패턴

 

소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

 

 

디자인 패턴의 종류

 

1. 생성 패턴

  • Builder: 복잡한 인스턴스를 조립하여 만드는 구조
  • Prototype: 처음부터 일반적인 원형을 만들어 놓고, 필요한 부분만 수정해 사용하는 패턴
  • Factory Method: 상위 클래스에서 객체를 생성하는 인터페이스 정의, 하위 클래스에서 인스턴스 생성
  • Abstract Factory: 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스 제공
  • Singleton: 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하고, 생성된 객체를 어디에서든지 참조할 수 있도록하는 패턴

 

2. 구조 패턴

  • Bridge: 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리
  • Decorator: 기존에 구현되어있는 클래스에 필요한 기능 추가
  • Facade: 복잡한 시스템에 대해 단순한 인터페이스 제공
  • Flyweight: 메모리 절약, 클래스의 경량화 목적
  • Proxy: 실제 객체에 대한 대리 객체, 실체 객체를 드러나지 않게 정보 은닉
  • Composite: 객체들의 관계를 트리 구조로 구성, 부분-전체 계층 표현
  • Adapter: 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할

 

3. 행위 패턴

  • Mediator: 중재자
  • Interpreter: 언어의 다양한 해석, 구문의 해석
  • Iterator: 컬렉션 구현 방법을 노출시키지 않고 집합체 안에 들어있는 모든 항목에 접근할 방법 제공
  • Template Method: 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화, 추상클래스 구체화
  • Observer: 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락
  • State: 상태에 따라 다르게 처리할 수있도록 행위 내용 변경
  • Visitor: 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업 수행
  • Command: 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행
  • Strategy: 알고리즘 군 정의, 행위를 클래스로 캡슐화, 동적으로 행위 자유롭게 변환
  • Memento: Undo 기능 개발
  • Chain of Responsibility: 정적으로 어떤 기능에 대한 처리의 연결이 하드 코딩되어 있을 때, 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 디자인

 

 

운영체제

 

사용자와 하드웨어 간의 인터페이스 담당, 사용자가 컴퓨터를 좀 더 쉽게 사용하기 위해 지원

 

 

운영체제의 종류

 

  • Windows: 중/소규모 서버
  • 유닉스: 대용량 처리, 엔터프라이즈급 서버
  • 리눅스: 중/대규모 서버, 높은 보안성
  • 안드로이드
  • iOS

 

 

DBMS

 

데이터 관리의 복잡성을 해결해주는 소프트웨어

 

 

미들웨어

 

분산 컴퓨팅 환경에서 원만한 통신이 이루어질 수 있도록 제어

 

 

웹 어플리케이션 서버(WAS)

 

서버 계층에서 애플리케이션이 동작할 수 있는 환경 제공

 

 

요구공학

 

사용자의 요구가 반영된 시스템을 개발하기 위해서 구조화한 활동

 

 

기능적 요구사항

 

시스템이 제공하는 기능 / 기능성, 완전성, 일관성

 

 

비기능적 요구사항

 

시스템 구축에 대한 제약사항에 관한 요구사항 / 신뢰성, 사용성, 효율성 등

 

 

요구사항 개발 단계

 

도출 -> 분석 -> 명세 -> 확인

 

 

요구사항 도출 단계 주요 기법

 

  • 인터뷰: 이해관계자와 직접 대화
  • 브레인스토밍: 말을 꺼내기 쉬운 분위기로 만드는 것
  • 델파이 기법: 전문가의 경험을 토대로 한 미래 예측 기법
  • 롤 플레잉: 현실에 일어나는 장면을 설정하고 연기하는 방법
  • 워크숍: 단기간의 집중적인 노력을 통해 참여
  • 설문조사: 설문지 또는 여론 조사

 

 

요구사항 명세 단계 주요 기법

 

  • 비정형 명세 기법: 자연어 기반, 사용자와 개발자의 이해가 용이, 명확성 및 검증에 문제
  • 정형 명세 기법: 수학적인 원리와 표기법, 표현이 간결, 기법의 이해 어려움

 

 

상세 정형 기술 검토 기법

 

  • 인스펙션: 원시 코드 등을 저작자 외의 다른 전문가 또는 팀이 검사해 오류를 찾는 방법, 동료검토라고도 함
  • 워크 스루: 회의 전에 검토 자료를 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행

 

 

Next

2. 화면 설계