정보처리기사

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

례지 2022. 9. 16. 21:59
728x90

01. 소프트웨어 생명 주기

 

1) 소프트웨어 생명 주기(Software Life Cycle): 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것.

 

2) 폭포수 모형(Waterfall Model)

- 각 단계를 확실히 매듭짓고, 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행함.

- 이전 단계로 돌아갈 수 없고, 고전적 생명 주기 모형이라고도 함.

 

3) 프로토타입 모형(Prototype Model)

- 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측함.

 

4) 나선형 모형(Spiral Model)

- 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 개발하는 모형.

- 계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가

- 고객의 요구가 추가되면 다시 돌아감.

 

5) 애자일 모형(Agile Model)

- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형.

- 스크럼(Scrum)

     - 팀이 중심이 되어 개발의 효율성을 높이는 기법.

     - 계획하여 진행(스프린트)한 후 회의와 검토를 거쳐 회고.

- XP(eXtreme Programming)

     - 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복 극대화 → 생산성 향상

     - 계획하고 진행(이터레이션)한 후 검사하고 출시(릴리즈)

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

     - Pair Programming(짝 프로그래밍): 개발자 둘이서 짝으로 코딩.

     - Collective Ownership(공동 소유): 개발 코드에 대한 권한과 책임을 공동으로 소유함.

     - Continuous Integration(지속적인 통합): 매일 여러 번씩 소프트웨어를 통합하고 빌드함.

     - Test-Driven Development(테스트 주도 개발): 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악함.

     - Whole Team(전체 팀): 개발에 참여하는 모든 구성원(고객 포함)은 각자 자신의 역할이 있고, 그 역할에 대한 책임을 가져야 함.

     - Small Release(소규모 릴리즈): 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속하게 대응할 수 있음.

     - Refactoring(리팩토링): 프로그램 기능의 변경 없이 시스템을 재구성함.

          - 리팩토링 목적: 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함.


02. 현행 시스템 파악

 

1) 절차

- 1단계: 시스템 구성 파악, 시스템 기능 파악, 시스템 인터페이스 파악

- 2단계: 아키텍처 구성 파악, 소프트웨어 구성 파악

- 3단계: 하드웨어 구성 파악, 네트워크 구성 파악

* 구기인 아소 하네


03. 개발 기술 환경 파악

 

1) 운영체제(OS, Operating System)

- 컴퓨터 시스템의 자원을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어

- 운영체제 관련 요구사항 식별 시 고려사항: 가용성, 성능, 기술지원, 주변 기기, 구축 비용

 

2) 데이터베이스 관리 시스템(DBMS, DataBase Management System)

- 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해주는 소프트웨어

- DBMS 관련 요구사항 식별 시 고려사항: 가용성, 성능, 기술지원, 상호 호환성, 구축 비용

 

3) 웹 애플리케이션 서버(WAS, Web Application Server)

- 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어

- WAS 관련 요구사항 식별 시 고려사항: 가용성, 성능, 기술 지원, 구축 비용

 

4) 오픈 소스(Open source)

- 누구나 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어

- 오픈 소스 관련 요구사항 식별 시 고려사항: 라이선스의 종류, 사용자 수, 기술의 지속 가능성


04. 요구사항 정의

 

1) 요구사항

- 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 운영되는데 필요한 제약조건

- 기능 요구사항(Functional requirements): 기능이나 수행과 관련된 요구사항

- 비기능 요구사항(Non-Functional requirements): 품질이나 제약사항과 관련된 요구사항

- 사용자 요구사항(User requirements): 사용자 관점에서 본 시스템이 제공해야 할 요구사항

- 시스템 요구사항(System requirements): 개발자 관점에서 본 시스템 전체가 제공해야 할 요구사항


05. 요구사항 개발 프로세스

 

1) 요구사항 개발 프로세스

- 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 활동

* 도분명확

- 도출: 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 식별하고 이해하는 과정

     - 청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스

- 분석: 요구사항 중 이해되지 않는 부분을 걸러내기 위한 과정

     - 구조적 분석 기법: 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법

          - 자료 흐름도(DFD, Data Flow Diagram): 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방

          - 자료 사전(DD, Data Dictionary): 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것(메타 데이터)

기호 의미
프로세스(Process) 자료를 변환시키는 시스템의 한 부분(처리 과정)
자료 흐름(Data Flow) 자료의 이동(흐름)이나 연관관계를 나타냄.
자료 저장소(Data Store) 시스템에서의 자료 저장소(파일, 데이터베이스)를 나타냄.
단말(Terminator) 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받음.

          - 요구사항 분석용 CASE(자동화 도구): 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구

          - HIPO(Hierachy Input Process Output): 시스템 실행 과정인 입력, 처리, 출력의 기능을 표현한 것

          - HIPO Chart: 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것

- 명세: 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것

     - 정형 명세 기법: 수학적 원리 기반, 일관성 있음. → 완전성 검증 가능, 사용자 이해 어려움.

     - 비정형 명세 기법: 자연어를 기반으로 서술 또는 다이어그램으로 작성. 일관성 떨어짐. → 해석이 달라짐. 사용자 이해 쉬움.

- 확인(검증): 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토.

 

2) 요구공학: 요구사항을 정의하고 분석 및 관리하는 프로세스를 연구하는 학문


06. UML(Unified Modeling Language)

 

1) UML: 시스템 개발 과정에서 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어

- 사물(Things): 다이어그램 안에서 관계가 형성될 수 있는 대상들

- 관계(Relationship): 사물과 사물 사이의 연관성을 표현하는 것

     - 연관 관계(Association): 2개 이상의 사물이 서로 관련되어 있는 관계. (실선, 방향성은 화살표, 양방향은 실선만)

     - 집합 관계(Aggregation): 하나의 사물이 다른 사물에 포함되어 있는 관계(부분이 전체에게 속이 빈 마름모로 연결)

     - 포함 관계(Composition): 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계, 전체와 부분은 서로 독립될 수 없음.(부분이 전체에게 속이 찬 마름모로 연결)

     - 일반화 관계(Generalization): 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계, 자식이 부모에게 속이 빈 화살표로 연결

     - 의존 관계(Dependency): 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계(이용자가 제공자에게 점선 화살표로 연결)

     - 실체화 관계(Realization): 할 수 있거나 해야 하는 기능으로, 서로를 그룹화할 수 있는 관계(사물이 기능에게 속이 빈 점선 화살표로 연결)

- 다이어그램(Diagram): 사물과 관계를 도형으로 표현한 것

     - 정적모델링: 사용자가 요구한 기능을 구현하는 데 필요한 자료들의 논리적인 구조를 표현

     - 구조적 다이어그램

클래스(Class) 클래스와 클래스가 가지는 속성 클래스 사이의 관계를 표현
객체(Object) 클래스에 속한 사물들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
컴포넌트(Component) 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
배치(Deployment) 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
복합체 구조(Composite Structure) 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
패키지(Package) 모델 요소들을 그룹화한 패키지 간의 의존 관계를 표현

* 클객컴배복패

     - 동적 모델링: 시스템 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호작용을 표현

     - 기능모델링: 개발될 시스템이 갖춰야 할 기능을 사용자와 공유하기 위해 그림으로 표현

     - 행위 다이어그램

유스케이스(UseCase) 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현
시퀀스(Sequence) 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 그림으로표현
커뮤니케이션(Communication) 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현
상태(State) 객체들 사이에서 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현
활동(Activity) 시스템이 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현
타이밍(Timing) 객체 상태 변화와 시간 제약을 명시적으로 표현

* 유시커상활타

 

2) 스테레오 타입: UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것

<<include>> 포함 관계 <<interface>> 인터페이스 정의 <<constructor>> 생성자 역할 수행
<<extend>> 확장 관계 <<exception>> 예외 정의    

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

 

1) 소프트웨어 개발 방법론: 소프트웨어 개발, 유지보수 등에 필요한 수행 방법과 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것.

 

2) 구조적 방법론: 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론.

     - 타당성 검토 → 계획 → 요구사항 → 설계 → 구현 → 시험 → 운영 및 유지보수

 

3) 정보공학 방법론: 계획, 분석, 설계, 구축에 정형화된 기법들을 통합 및 적용하는 자료 중심의 방법론

     - 정보 전략 게획 수립 → 업무 영역 분석 → 업무 시스템 설계 → 업무 시스템 구축

 

4) 객체 지향 방법론: 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론

- 구성 요소: 객체, 클래스, 메시지

- 기본 원칙: 캡슐화, 정보 은닉, 추상화, 상속성, 다형성

- 요구 분석 → 설계 → 구현 → 테스트 및 검증 → 인도

 

5) 컴포넌트 기반 방법론: 컴포넌트를 조합하여 새로운 애플리케이션을 만드는 방법론

- 개발 준비 → 분석 → 설계 → 구현 → 테스트 → 전개 → 인도

 

6) 제품 계열 방법론: 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론


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

 

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

- 합성 중심: 블록을 만들고 끼워 맞춰 소프트웨어를 완성시키는 방법.(블록 구성 방법)

- 생성 중심: 추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법.(패턴 구성 방법0

 

2) 소프트웨어 재공학: 기존 시스템을 이용하여, 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것

 

3) CASE(Computer Aided Software Engineering): 소프트웨어 개발 과정에서 사용되는 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것


09. 비용 산정 기법

 

1) 소프트웨어 비용 결정 요소

- 프로젝트 요소: 제품 복잡도, 시스템 크기, 요구되는 신뢰도

- 자원 요소: 인적 자원, 하드웨어 자원, 소프트웨어 자원

- 생산성 요소: 개발자 능력, 개발 기간

 

2) 하향식 비용 산정 기법

- 과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적 기법

- 전문가 감정 기법: 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법

- 델파이 기법: 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정

 

3) 상향식 비용 산정 기법

- 세부적인 작업 단위 별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법

- LOC(원시 코드 라인 수, Line Of Code) 기법: 각 기능의 원시 코드 라인 수의 비관치(최댓값), 낙관치(최솟값), 기대치(평균)를 측정하여 예측치를 구함.

     - 예측치 = (낙관치 + (4 * 기대치) + 비관치) / 6

- 수학적 산정 기법: 개발 비용 산정의 자동화를 목표.

     - COCOMO 모형: 보헴이 제안한 LOC에 의한 비용 산정 기법

          - 조직형: 기관 내부에서 개발된 중, 소 규모의 소프트웨어(5만(50KDSI)라인 이하)

          - 반분리형: 조직형과 내장형의 중간형 소프트웨어(30만(300KDSI)라인 이하)

          - 내장형: 초대형 규모의 소프트웨어(30만(300KDSI)라인 이상)

     - Putnam 모형: 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형

          - Rayleigh-Norden 곡선의 노력 분포도를 기초로 함. (개발 기간 ↑ → 노력 ↓)

     - 기능 점수(FP, Function Point) 모형: 소프트웨어의 기능을 증대시키는 요인 별로 기능 점수를 구한 후 비용 산정

     - 비용 산정 자동화 추정 도구: SLIM, ESTIMACS


10. 프로젝트 일정 계획

 

1) PERT(Program Evaluation and Review Technique, 프로그램 평가 및 검토 기술)

- 전체 작업의 상호 관계를 표시하는 네트워크

- 개발 경험이 없어 소요 기간 예측이 어려운 프로젝트 일정 계획에 사용함.

- 노드(작업), 간선(낙관치, 기대치, 비관치)으로 구성됨.

 

2) CPM(Cirical Path Method, 임계 경로 기법)

- 작업을 나열하고 작업에 필요한 소요 기간을 예측하는 데 사용하는 기법

- 가장 소요 기간이 오래 걸리는 경로를 찾으면 됨.

- 노드(작업), 간선(작업 사이의 전후 의존 관계)으로 구성됨.

 

3) 간트 차트

- 프로젝트의 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표


11. 소프트웨어 개발 표준

 

- 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준

 

1) ISO/IEC 12207: ISO에서 만든 표준 소프트웨어 생명 주기 프로세스

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

 

2) CMMI(Capability Maturity Model Integration): 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델

 

3) SPICE(Software Process Improvement and Capability Etermination): 소프트웨어 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준(ISO/IEC 15504)


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

 

- 소프트웨어 개발 방법론의 절차, 사용 기법 등을 수정 및 보완하는 작업

- 내부적 기준: 목표 환경, 요구사항, 프로젝트 규모, 보유 기술

- 외부적 기준: 법적 제약사항, 표준 품질 기준


13. 소프트웨어 개발 프레임워크

 

- 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 제공해주는 소프트웨어 시스템

- 스프링 프레임워크: 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크

- 전자정부 프레임워크: 대한민국의 공공부문 정보화 사업 시 정보 시스템의 구축을 위해 기능 및 아키텍처를 제공

- 닷넷 프레임워크(.NET Framework): 윈도우 프로그램의 개발 및 실행 환경을 제공하는 프레임워크

- 특성: 모듈화, 재사용성, 확장성, 제어의 역흐름

728x90