728x90

개발 기술 환경 파악

개발 기술 환경의 정의

- 개발하고자 하는 소프트웨어와 관련된 O/S, DBMS, Middle Ware 등을 선정할 때 고려해야 할 사항을 기술하고 오픈 소스 사용 시 주의해야 할 내용을 제시

 

운영체제(Operating System)

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

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

    -> 2020 정보처리기사 필기 - 4.3 응용 SW 기초 기술 활용(1)

 

2020 정보처리기사 필기 - 4.3 응용 SW 기초 기술 활용(1)

운영체제의 개념 운영체제의 정의 - 컴퓨터 시스템의 자원들을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효과적으로 사용할 수 있도록 환경을 제공하는 여러 프로그램의 모임 운영체제의 목적 - 처리 능..

1d1cblog.tistory.com

데이터베이스 관리 시스템(DBMS)

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

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

 

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

- 사용자의 요구에 따라 변하는 동적인 컨텐츠를 처리하기 위해 사용되는 미들웨어

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

 

오픈 소스(Open Source)

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

- 라이선스를 만족하는 소프트웨어

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

 

요구사항 정의

요구사항의 개념과 특징

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

- 요구사항이 제대로 정의되어야 이를 토대로 이후 과정의 목표와 계획의 수립이 가능

 

요구사항의 유형

- 기술하는 내용에 따른 분류

    -> 기능 요구사항 : 시스템이 무엇을 하고 어떤 기능을 하는지에 대한 사항

 

    -> 비기능 요구사항 : 품질이나 제약사항에 대한 사항

- 기술 관점과 대상의 범위에 따른 분류

    -> 사용자 요구사항 : 사용자의 관점에서 본 시스템이 제공해야 할 사항

    -> 시스템 요구사항 : 개발자의 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 사항

 

요구사항 개발 프로세스

- 요구사항 도출

    -> 요구사항이 어디에 있고 어떻게 수집할지 식별하고 이해하는 과정

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

    -> 브레인스토밍 : 3인 이상이 자유롭게 아이디어를 산출해 내는 방법

    -> 유스케이스 : 사용자의 요구사항을 기능 단위로 표현

- 요구사항 분석

    -> 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 걸러내는 과정

- 요구사항 명세

    -> 요구사항을 분석한 후 승인될 수 있도록 문서화하는 과정

    -> 소프트웨어 요구사항 명세서 : 소프트웨어가 반드시 제공해야 하는 기능, 특징, 제약조건을 명시

- 요구사항 확인

    -> 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하게 작성되었는지 검토하는 과정

 

요구사항 분석 기법

요구사항 분류

- 요구사항을 명확히 확인할 수 있도록 정해진 기준으로 분류

    -> 기능/비기능 요구사항 분류

    -> 제품/과정으로 분류

    -> 우선순위로 분류

 

개념 모델링

- 요구사항의 현실 세계의 상황을 단순화하여 개념적으로 표현하는 과정 

- 실세계 문제에 대한 모델링은 요구사항 분석의 핵심

- 개체와 개체 간의 관계 및 종속성을 반영

- 개념 모델은 다양하게 표현

- 주로 UML을 사용

 

요구사항 할당

- 요구사항을 만족시키기 위한 구성 요소를 식별

 

요구사항 협상

- 요구사항이 서로 충돌될 경우 해결하는 과정

- 적절한 기준점을 찾아 합의하는게 좋음

- 서로 충돌하는 경우 우선순위를 부여하면 해결에 도움이 됨

 

정형 분석

- 구문과 의미를 같은 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현하고 분석하는 과정

 

요구사항 확인 기법

요구사항 검토

- 문서화된 요구사항을 훑어보면서 확인하는 과정

- 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서 등을 완성한 시점에 이루어짐

 

프로토타이핑

- 초기 도출된 요구사항을 토대로 프로토타입을 만든 후 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정

- 장점

    -> 빠르고 반복되는 제작을 할 수 있어 발전된 결과물을 얻을 수 있음

    -> 최종 시스템을 완성하기 전에 추가 또는 변경된 요구사항에 대한 피드백 가능

- 단점

    -> 사용자의 관심이 핵심에서 벗어나 프로토타입 제작에만 집중될 수 있음

    -> 지속적이고 반복적인 개선에 대한 비용이 부담될 수 있음

 

모델 검증

- 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족하는지 검증하는 과정

 

인수 테스트

- 사용자가 실제로 사용될 환경에서 요구사항이 모두 충족되는지 사용자 입장에서 확인하는 과정

 

UML(Unified Modeling Language)

UML의 개요

- 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 객체지향 모델링 언어

- 객체지향 방법론의 장점을 통합하였으며 OMG(Object Management Group)에서 표준으로 지정

- 구성 요소 : 사물, 관계, 다이어그램

 

사물

- 모델을 구성하는 가장 중요한 기본 요소

- 다이어그램 안에서 관계가 형성될 수 있는 대상

- 구조 사물

    -> 시스템의 개념적, 물리적 요소 표현

    -> 클래스, 유스케이스, 컴포넌트, 노드 등

- 행동 사물

    -> 시간과 공간에 따른 요소들의 행위 표현

    -> 상호작용, 상태 머신 등

- 그룹 사물

    -> 요소들의 그룹으로 묶어서 표현

    -> 패키지

- 주해 사물

    -> 부가적인 설명이나 제약조건 등 표현

    -> 노트

 

관계

- 사물과 사물 사이의 연관성 표현

- 연관 관계

    -> 2개 이상의 사물이 서로 관련되어 있음을 표현

    -> 실선과 화살표로 연결하여 표현하지만 양방향 관계의 경우 화살표 없이 실선으로 연결하여 표현

사람과 집이 1:1 관계
교수는 1명 이상의 학생을 가르치고 학생은 1명 이상의 교수에게 가르침을 받음

- 집합 관계

    -> 하나의 사물이 다른 사물에 포함되어 있는 관계

    -> 부분(포함되는 쪽)에서 전체(포함하는 쪽)로 속이 빈 마름모를 연결하여 표현

프린터는 컴퓨터에 연결해서 사용할 수 있음

- 포함 관계

    -> 집합 관계의 특수한 형태로 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

    -> 부분(포함되는 쪽)에서 전체(포함하는 쪽)로 속이 채워진 마름모를 연결하여 표현

문을 열 수 있는 키는 하나이고 해당 키로 다른 문은 열 수 없음

- 의존 관계

    -> 사물 사이에 연관은 있으나 필요에 의해서 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계

    -> 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표 연결

출석률은 학점을 낼 때 영향을 미침

- 일반화 관계

    -> 하나의 사물이 다른 사물에 비해 일반적인지 구체적인지 표현

    -> 구체적인 사물에서 일반적인 사물 쪽으로 속이 빈 화살표를 연결

- 실체화 관계

    -> 사물이 할 수 있거나 해야 하는 기능으로 서로를 그룹화할 수 있는 관계

    -> 사물에서 기능 쪽으로 속이 빈 점선 화살표 연결

다이어그램

- 사물과 관계를 도형으로 표현

- 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램 사용

- 구조적 다이어그램

    -> 클래스 다이어그램 : 클래스, 클래스가 가지는 속성, 클래스 사이 관계 표현

    -> 객체 다이어그램 : 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현

    -> 컴포넌트 다이어그램 : 구현 단계에서 사용되며 컴포넌트 간의 관계나 인터페이스를 표현

    -> 배치 다이어그램 : 구현단계에서 사용되며 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치 표현

    -> 복합체 구조 다이어그램 : 복잡한 구조를 가지는 클래스 혹은 컴포넌트의 내부 구조 표현

    -> 패키지 다이어그램 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계 표현

- 행위 다이어그램

    -> 유스케이스 다이어그램 : 사용자의 요구를 분석하여 기능 모델링 작업에 사용됨

    -> 시퀀스 다이어그램 : 상호 작용하는 시스템이나 객체들이 주고받는 메시지 표현

    -> 커뮤니케이션 다이어그램 : 객체들이 주고받는 메시지를 표현할 뿐 아니라 객체들 간의 연관까지 표현

    -> 상태 다이어그램 : 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 어떻게 변화하는지 표현

    -> 활동 다이어그램 : 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현

    -> 상호작용 개요 다이어그램 : 상호작용 다이어그램 간의 제어 흐름 표현

    -> 타이밍 다이어그램 : 객체 상태 변화와 시간 제약을 명시적으로 표현

필기 정리

 

2020 정보처리기사 필기 정리

본 정리 글은 시나공 정보처리기사 필기책과 학교 특강을 참고하여 작성하였습니다. -> 책 정보 확인하기 시나공 정보처리기사 필기 2020년 정보처리기사 NCS기반 전면 개편!정보처리기사 시험은 NCS 학습 모듈 중..

1d1cblog.tistory.com

 

728x90

+ Recent posts