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

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

챕터 01 소프트웨어 개발 방법론

1) 소프트웨어 생명주기(SDLC) : 시스템의 요구분석부터 유지보수까지 전 공정을 체계화 한 절차

모델	폭포수 모델	프로토 타이핑 모델	나선형 모델	반복적 모델
설명	각 단계를 확실히 마무리 지은 후 다음 단계로 넘어감	고객 요구 주요 기능을 프로토타입으로 구현	점진적으로 완벽한 시스템으로 개발	대상을 나누어 병렬 개발 후 통합하거나 반복 개발로 점증 완성(SDLC)
특징	선형 순차적, 가장 오래됨(고전적), 명확, 변경 어려움	피드백 반영, 프로토타입	위험 분석, 반복개발	병행 개발
절차	​	​	계획 및 정의 → 위험 분석 → 개발 → 고객평가	​

 

2) 소프트웨어 개발 방법론 : SW개발의  전 과정을 형상화한 방법론

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

종류	설명
구조적 방법론	기능에 따라 나누어 개발한 후 통합(분할 정복) 프로세스 중심, 하향식 방법론, 나씨-슈나이더만 차트 사용
정보공학 방법론	정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론 개발 주기 사용, 대형 프로젝트
객체지향 방법론	객체를 기본 단위로 시스템 분식 및 설계 객체, 클래스, 메시지 사용
컴포넌트 기반 방법론	컴포넌트를 조립해서 하나의 응용 프로그램 작성 개발 기간↓, 생산성↑, 확장성, 재사용
제품 계열 방법론	공통 기능을 정의하여 개발 임베디드 SW에 유용, 영역 공학과 응용공학으로 구분
애자일 방법론	절차보다 사람 중심, 유연하고 신속하게 효율적으로 개발 개발 시간↓, 폭포수에 대비, 즉시 피드백

 

3) 애자일 방법론의 유형

 - XP(eXtreme Programming) : 의사소통 개선과 즉각적 피드백으로 SW 품질을 높이는 방법론

   > 가치 : 용기, 단순성,의사소통,피드백,존중

   > 원리 : 짝 프로그래밍, 공통 코드 소유, 지속적 통합, 계획 세우기, 작은 릴리즈, 메타포어, 간단한 디자인

- 스크럼 : 매일 정해진 시간, 장소에서 짧은 시간 개발하는 팀을 위한 프로젝트 관리 중심 방법론

   > 백로그,  스프린트(짧은 개발 기간),  스크럼 미팅,  스크럼 마스터,  스프린트 회고,  번 다운 차트(남은 시간)

- 린(Lean) : 낭비요소를 제거하여 품질을 향상한 방법론 (도요타 관련)

   > 가치 : 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

4) 객체 지향 분석(OOA) : 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계 정의

 

5) 객체 지향 분석 방법론 종류

- OOSE(Object Oriented Software Engineering) : 유스케이스를 모든 모델의 근간으로 활용되는 방법론 (야콥슨)

- OMT(Object Modling Technoiogy): 그래픽 표기법을 이용하여 소프트웨어 구성요소 모델링 (럼바우)

   >  분석 절차 : 객체 모델링 -> 동적 모델링 - 기능 모델링

    > 객체 모델링 : 객체 간의 관계를 정의하여 ER 다이어그램을 만다는 과정까지의 모델링 (객체 다이어그램 활용)

    > 동적 모델링 : 시간 흐름에 따라 객체들의 동적인 행위를 표현하는 모델링(상태 다이어그램 활용)

    > 기능 모델링 : 프로세스들의 자료 흐름을 중심으로 처리 과정 표현하는 모델링(자료 흐름도(DFD 활용)

 

6) 비용 산정 모형 분류

분류	설명	종류
하향식	경험 많은 전문가에게 의뢰, 여러 전문가와 조정자를 통해 산정	전문가 판단, 델파이
상향식	세부 요구 사항과 기능에 따라 비용 계산	코드 라인 수(Loc),Man Month, COCOMO, 푸트남(putnam), 기능점수(FP)

- 델파이 기법 : 전문가의 경험적 지식을 통해 문제 해결 및 미래 예측을 위한 기법

- 코드 라인 수(LOC Lines Of Code) : 원시 코드 라인수의 낙관치, 중간치, 비 관치를 측정하여 비용 산정

- Man Month : 한 사람이 한 달 동안 할 수 있는 일의 양을 기준으로 비용 산정

  > Man Month = Loc/프로그래머의 월간 생산성

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

- COCOMO모형 : 보헴이 제안한 비용 산정 방식으로 프로그램 규모에 따라 비용 산정

   > 조직형(Oranic) 5만 라인 이하

   > 반 분리형(Semi-Detached) 30만 라인 이하

   > 임베디드형(Embedded) 30만 라인 이상

- 푸트남(Putnam) 모형 : 개발 주기의 단계별로 인력 분포를 가정하는 방

   > 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함

- 기능 점수(FP) 모형 : 소프트웨어 기능을 증대시키는 요인의 가중치 부여하여 비용 산정

    > FP = 총 기능점수 * [0.65 + (0.1 * 총영향도)]

    > 단순, 보통, 복잡 정도에 따라 가중치 부여

- 비용 산정 자동화 추정 도구

  > SLIM : Rayleigh-Norden곡선과 푸트남 모델을 기초로 개발된 자동화 추정 도구

  > ESTIMACS : FP모형을 기초로 개발된 자동화 추정 도구

 

7) 일정 관리 모델 : 프로젝트가 기한 내에 완료될 수 있도록 관리하는 모델

모델	설명
주 공정법(CPM)	프로젝트 일정 계산법, 노드와 노드 간 연결을 통해 공정 계산 프로젝트 시작에서 종료까지 가장 긴 시간이 걸리는 경로 계산
PERT	일의 순서를 계획적으로 정리하기 위한 수렴 기법(비관·중간·낙관치로 일정 관리)
중요 연쇄 프로젝트 관리	주 공정 연쇄법으로 자원 제약 고려, 일정 작성

 

챕터 02. 현행 시스템 분석

1) 현행 시스템 파악 개념 : 사용하고 있는 SW, HW, NW구성 등 어떻게 되어 있는지 파악하는 활동

 

2) 절차 : 구성/기능/인터페이스 파악 → 아키텍처/소프트웨어 구성 파악 → 하드웨어/네트워크 구성 파악

 

- 구성/기능/인터페이스 파악

절차	설명
구성	기간업무(주)와 지원업무(보조)로 구분하여 파악 / 정보시스템들의 명칭, 주요 기능 명시
기능	현재 제공하고 있는 기능 파악, 계층형 표시
인터페이스	다른 시스템과 주고 받는 데티어 종류, 프로토콜 등 파악

- 아키텍처/소프트웨어 구성 파악

절차	설명
아키텍처	계층별로 어떠한 기술 요소를 사용하고 있는지 파악(기간 업무부터)
SW	소프트웨어들의 제품명, 용도, 라이선스 파악

- 하드웨어/네트워크 구성 파악

절차	설명
하드웨어	서버 위치, 운용 서버의 주요 사양, 이중화 구현 여부 파악
네트워크	어떤 네트워크 장비를 사용하여 어떻게 구성되어 있는지 파악

 

3) SW 아키텍처 : SW구성과 그 요소의 외부 특성과 관계 표현하는 시스템 구조

- SW 아키텍처 프레임워크 : 아키텍처의 내용 및 관계를 제공하는 아키텍처 기술 표준

- SW아키텍처 프레임워크 구성요소

구성 요소	설명
아키텍처 명세서	아키텍처를 기록하기 위한 산출물, 뷰로 표현
이해관계자	개발과 관련된 모든 사람, 조직
관심사	이해관계자들(사용자, 유지보수자, 개발자)의 의견, 목표
관점	뷰의 토대가 되는 패턴이나 양식
뷰	전체 시스템 표현
근거	아키텍처 결정 근거, 화의 결과
목표	이해관계자들의 목적, 사용, 운영 방법
환경	시스템에 영향을 주는 요인
시스템	각 애플리케이션, 서브 시스템, 시스템 집합 등 구현체

​

- 소프트웨어 아키텍처 4+1 뷰 : 시나리오를 4개의 관점에서 바라보는 SW접근 방법, 유스 케이스 사용

뷰	설명
유스케이스	다른 뷰를 검증하는 데 사용되는 뷰
논리	기능 요구사항이 어떻게 제공되는지 설명
프로세스	비기능적 속성 표현 뷰
구현	정적인 소프트웨어 모듈 구성을 보여주는 뷰
배포	컴포넌트가 물리적인 아키텍처에 어떻게 배치되는 가를 보여주는 뷰

4) 아키텍처 패턴 : 소프트웨어 설계 시 참조할 수 있는 전형적인 해결 방식

 

유형	설명
계층화	시스템을 계층으로 구분하여 구성 각 하위 모듈은 추상화 제공, 서로 마주보는 계층끼리 상호작용
클라이언트-서버	하나의 서버와 다수의 클라이언트로 구성 사용자가 클라이언트에 서비스 요청, 서버가 클라이언트에 서비스 제공, 클라이언트가 사용자에게 전달
파이프-필터	서브 시스템이 입력 데이터 처리, 결과를 넘겨줌(반복) 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능
브로커	서버의 기능을 브로커 컴포넌트가 가짐, 클라이언트가 브로커에 서비스 요청하면 적합한 것으로 연결해 줌 분산시스템에서 사용, 원격 서비스 실행 통해 상호작용 가능
모델-뷰-컨트롤러(MVC)	대화형 애플리케이션을 모델, 뷰, 컨트롤러로 구조화 모델 : 핵심 기능, 데이터 보관 뷰 : 사용자에게 정보 표시 컨트롤러 : 요청을 입력받아 처리아키텍처 비용 평가 모델 : 아키텍처 적합성 평가

5) SW 아키텍처 비용 평가 모델

종류	설명
SAAM	변경 용이, 기능성에 집중
ATAM	아키텍처 품질 속성을 만족시키는지 판단
CBAM	ATAM + 경제적 의사결정에 대한 요구 충족 판단
ADR	구성 요소 간 응집도 평가
ARID	전체가 아닌 특정 부분에 대한 품질 요소에 집중하여 평가

 

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

​

   - 구성 요소 : 이름, 문제 및 배경, 설루션, 적용 사례, 결과, 샘플 코드

   - 유형 : 목적(생성, 구조, 행위) / 범위(클래스, 객체)

​

생성 패턴

패턴	설명
Builder	복잡한 인스턴스를 조립하여 만드는 구조, 객체 생성과 구현을 분리함으로써 동일한 절차에 다른 결과를 만드는 것이 가능
Prototype	일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요 부분만 수정하여 사용
Factory Method	상위 클래스에서 객체 생성 인터페이스 정의, 하위 클래스에서 인스턴스 생성
Abstract Factory	서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스 제공 구체적인 구현은 Con-crete Product 클래스에서 이루어짐
Singleton	전역 변수 사용x, 객체 하나만 생성, 생성된 객체는 어디서든지 참조 가능 한 클래스에 한 객체만 존재

​

구조 패턴

패턴	설명
Bridge	기능 클래스 계층과 구현 클래스 계층 연결, 구현부에서 추상층 분리 실제 구현 부분을 독립적으로 확장할 수 있음
Decorator	기존에 구현되어 있는 클래스에 필요 기능을 추가해나감
Facade	단순 인터페이스 제공, 사용자와 시스템 간 결합도 낮춤 → 쉬운 구조 파악 가능, 접근성 높일 수 있음
Flyweight	모두가 갖는 본질적 요소를 클래스 화하여 공유 → 메모리 절약, 클래스의 경량화
Proxy	실제 객체에 대한 대리 객체를 사용 → 메모리 용량↓, 정보은닉
Composite	객체들의 관계를 트리 구조로 구성, 부분-전체 계층을 표현하는 패턴
Adapter	기존에 생성된 클래스를 재사용할 수 있도록 맞춰주는 인터페이스 패턴 클래스 패턴, 인스턴스 패턴 두 가지 형태로 사용

 행위 패턴

패턴	설명
Mediator	중재자를 만들어 중재자에게 모든 것을 요구하여 통신 빈도수를 낮추는 패턴
Interpreter	언어의 다양한 해석을 맞는 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석할 수 있게 만드는 패턴
Iterator	컬렉션 구현 방법을 노출하지 않으면서 그 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공
Template Method	작업 처리 일부분을 서브 클래스로 캡슐화해 전체 수행 구조는 바꾸지 않으면서 특정 단계 수행 내역을 바꾸는 패턴 (상위 작업 구조를 바꾸지 않으면서 서브 클래스로 작업 일부분 수행)
Observer	한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에 연락이 가고, 자동으로 내용이 갱신되는 방법(일대 다)
State	객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조하게 하는 방식 상태에 따라 다르게 처리할 수 있도록 행위 내용 변경 가능
Visitor	각 클래스에서 처리 기능을 분리, 별도 클래스 생성 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하도록 만드는 패턴
Command	실행될 기능을 캡슐화, 여러 기능 실행 가능한 재사용성이 높은 클래스를 설계 추상 클래스에 메서드 생성, 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행
Strategy	알고리즘 정의 후 각각 하나의 클래스로 캡슐화, 필요할 때 서로 교환해서 사용할 수 있게 하는 패턴 → 행위 객체를 클래스로 캡슐화 해 동적으로 자유롭게 변환
Memento	클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용
Chain of Responsibility	정적으로 어떤 기능에 대한 처리의 연결이 하드코딩 되어 있을 때 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 것

7) 현행 시스템 분석서 작성 및 검토

• 분석한 결과를 기반으로 산출물 작성

산출물(구성도) : 정보시스템 기능, 인터페이스 현황, 현행 시스템 아키텍처, 소프트웨어 구성도, 하드웨어 구성도, 네트워크 구성도

8) 개발기술 환경 정의 : 운영 처제(OS), 네트워크(NW), DBMS, 미들웨어, 오픈소스

 ​순서 : 정의 → 자료 수집 → 분석 및 환경 설정 → 요구사항 정의서 및 목표 반영 및 검토

• ​OS : 컴퓨터와 하드웨어 간의 인터페이스를 담당하는 프로그램

      - 분석 시 고려사항 : 신뢰도, 성능, 기술 지원, 주변 기기, 구축 비용

구분	종류	특징
PC	윈도즈(Window)	중소 규모의 서버, 일반 PC 등에서 주로 사용
	유닉스(UNIX)	대용량 처리, 안정성 높음
	리눅스(Linux)	중/대규모 서버 대상, 보안성 높음
모바일	Android	리눅스 기반 모바일 운영 체제, 자바와 코틀린 이용
	iOS	스마트폰, 태블릿PC의 높은 보안성과 고성능

​

• 네트워크 : 컴퓨터의 노드 간 연결을 통해 서로에게 데이터를 교환할 수 있도록 하는 기술

     - OSI 7 계층 : 네트워크 기본 모델

계층	설명	프로토콜	전송단위
응용	사용자와 네트워크간 응용 서비스 연결	HTTP, FTP	​ 데이터
표현	데이터 형식 설정, 부효교환, 암호화 · 복호화	JPEG, MPEG
세션	연결 접속 및 동기 제어	SSH, TLS
전송	데이터 분할, 재조립, 흐름 · 오류 · 혼잡 제어	TCP, UDP	세그먼트
네트워크	단말 간 데이터 전송을 위한 최적화 경로 제공	IP, ICMP	패킷
데이터 링크	인접 시스템 간 데이터 전송, 오류 제어	이더넷	프레임
물리	0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환	RS-232C	비트

• DBMS : DB 생성, 저장 및 관리 제공 응용 프로그램

         - 분석 시 고려사항 : 가용성, 성능, 상호 호환성, 기술지원, 구축비용

기능	설명
중복 제어	동일한 데이터가 여러 위치에 중복으로 저장되는 현상 방지
접근 통제	권한에 따라 데이터 접근 제어
인터페이스 제공	사용자에게 인터페이스 제공(CLI, GUI)
관계 표현	데이터간의 다양한 관계 표현
샤딩/파티셔닝	작은 단위로 나누는 기능
무결성 제약 조건	무결성에 관한 제약 조건을 정의/검사
백업 및 회복	DB 장애 시 데이터 보존 기능

​

• 미들웨어 : 응용 프로그램과 프로그램 운영 환경이 원만한 통신을 이루도록 제어해주는 소프트웨어

        - 분석 시 고려사항 : 가용성, 성능, 기술지원, 구축 비용

        - WAS(웹 애플리케이션 서버) : 서버 계층에서 앱이 동작할 수 있는 환경 제공

 

챕터 3 요구사항 확인

1) 요구 공학 : 사용자 요구 반영 시스템 개발을 위해 요구사항에 대한 도출-분석-명세-확인 및 검증하는 활동

- 요구 사항 분류 : 기능적 요구사항, 비기능적 요구사항

 

• 도출 : 수집 방법 결정, 요구 사항 구체적 표현

       - 방법 : 인터뷰, 브레인스토밍, 델파이 기법, 롤플레잉(연기), 워크숍, 설문 조사

​

• 분석 : 도출된 요구 사항 분석, 완전성과 일관성 확보 / 우선순위 부여

      - 단계 : 분류 → 개념 모델링 생성 및 분석 → 요구 사항 할당 → 협상 → 정형 분석

      - 분석 기법 : 자료 흐름 지향 분석(데이터 흐름도, 자료 사전) / 객체지향 분석(UML)

     - 분석 기술 : 청취, 인터뷰와 질문, 분석, 중재, 관찰, 작성, 조직, 모델 작성

​

• 명세 : 문서 작성

      - 주요 기법 : 비정형(자연어, 이해, 명확) / 정형(수학적 원리, Z-스키마, 상태 차트)

      - 검증 항목 : 명확, 완전, 검증 가능, 일관, 수정 용이, 추적 가능, 개발 후 이용성(유지 보수)

​

• 확인

      - 절차 : 요구 사항 목록 확인 → 정의서 작성 여부 확인 → 비기능 요구 사항 확인 → 인터페이스 요구 사항 확인

기법	설명
검토	검토
정형 기술 검토	동료 검토	명세서 작성자가 설명, 동료들이 설명 들으며 결함 발견
	워크 스루	오류 조기 검출 목적 자료를 회의 전 미리 배포, 검토 후 회의 때 오류 검출
	인스펙션	다른 전문가가 검사하여 오류를 찾아내는 방법
	관리 리뷰	통제 및 의사결정을 지원하는 리뷰
	기술 리뷰	정의된 계획 및 명세를 준수하고 있는지 검토 수행
프로토 타이핑	주요 기능이나 일부분을 개발하여 사용자 대상으로 시연, 요구 사항 확인
모델 검증	개발된 모델의 품질 검증
테스트 케이스 및 테스트	테스트 케이스 작성 후 테스트
CASE 도구 활용 검증	자동화 분석 도구인 CASE도구 활용(대규모 프로젝트)
베이스 라인	요구 사항 변경 추적, 통제 시점인 베이스라인을 통한 검증
요구 사항 추적표	개발 단계별 최종 산출물이 어떻게 반영되고, 변경되었는지 확인 가능 문서를 통해 요구 사항 검증

챕터 04. 분석 모델 확인하기

 

1) 분석 모델 검증 : 요구 사항 도출을 활용해 분석 모델에 대해서 확인하는 활동

프로세스 : 추적 표 작성 후 검토 의견 칼럼 추가 → 검토의견 작성(요구 사항 작성) → 검토의견 정제(의견 추가)

검증 방법	설명
유스케이스 모델	액터, 유스케이스, 유스케이스 명세서 점검
개념 수준의 분석 클래스	개념 수준의 주요 분석 클래스를 적절히 도출했는지, 명확한지 점검
분석 클래스	유스케이스 실현에 필요한 분석 클래스 도출 확인

 

2)요구사항 시스템화 타당성 분석

포로세스 : 타당성 분석 결과 기록 - 이해관계자 검증 - 타당성 분석 결과 확인 및 배표(공유)

검토 : 성능 및 용량 적정성 판단, 시스템 간 상호 운용성 여부 확인,  IT시장 성숙도 및 트렌드 부합성 확인, 기술 위험 분석