[정보처리기사 실기/내용 정리] 01. 요구사항 확인

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

반응형

01 소프트웨어 개발 방법론

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

* 소프트웨어 생명주기 모델 종류

 - 폭포수 모델 : 가장 오래된 모델로, 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어감

 - 프로토타이핑 모델 : 주요 기능을 프로토타입으로 구현해, 고개의 피드백을 반영하여 SW 만듦

 - 나선형 모델 : 위험을 최소화하기 위해 점진적으로 시스템 개발

 - 반복적 모델 : 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발

 

* 소프트웨어 개발 방법론 : 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화

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

 - 구조적 방법론 : 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합

(나 씨-슈나이더만 차트:논리의 기술에 중점을 둔 도형식 표현방법)

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

 - 객체 지향 방법론 :  '객체'라는 기본 단위로 시스템을 분석 및 설계

 - 컴포넌트 기반 방법론(CBD) : 컴포넌트를 조립해서 하나의 새로운 응용 프로그램 작성

 - 애자일 방법론 : 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적인 시스템 개발할 수 있는 신속 적응적 개량 개발

 - 제품 계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발하는 방법론, 임베디드, SW작성에 유용

 

* 애자일(Agile) 방법론 유형

 - XP(eXtreme Programming) : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론 

   [ XP 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존중]

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

 - 린(Lean) : 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요구를 제거하여 품질을 향상

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

* 객체 지향 분석 방법론 종류

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

 - OMT(Object Modeling Technology) : 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링, 럼바우 제작

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

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

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

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

 

* 비용 산정 모형 분류

 - 하향식 산정방법 : 경험이 많은 전문가에게 비용 산정 의뢰 또는 전문가와 조정자를 통해 비용 산정.

  → 전문가 판단

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

 - 상향식 산정방법 : 세부적인 요구 사항과 기능에 따라 필요한 비용 산정

  → 코드 라인 수 (LoC ;Lines of Code) : 원시 코드 라인 수의 낙관치, 중간치, 비 관치를 측정하여 예측치를 구해 비용 산정

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

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

     > 조직형 (Organic Mode) : 5만 (50 KDSI) 라인 이하

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

     > 임베디드형 (Embedded Mode) : 30만 (3000 KDSI) 라인 이상

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

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

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

 - SLIM : Rayleigh-Norden곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구

 - ESTIMACS : 다양한 프로젝트와 개인별 요소를 수용하도록 FP모형을 기초로 하여 개발된 자동화 추정 도구

 

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

 -  주 공정법(CPM) : 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법.

     >  주 공정(Critical Path: 임계 경로) : 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로

 - PERT : 일의 순서를 계획적으로 정리하기 위한 수렴 기법, 비관치, 중간치, 낙관치 이용

 - 중요 연쇄 프로젝트 관리 (CCPM) : 주 공정 연쇄법으로 자원 제약사항을 고려하여 일정을 작성하는 기법

 

 

 

02 현행 시스템 파악

현행 시스템 파악 절차란, 새로 개발하려는 시스템의 개발 범위를 명확히 설정하기 위한 절차로,

1단계.

 - 시스템 구성 파악  :  기간 업무, 지원 업무

 - 시스템 기능 파악  :  제공하는 기능 파악, 계층형 표시

(좀 더 세부적으로 들어감. 1-1에서 돈을 보관하는 시스템,으로 끝났다면, 1-2에서 돈 세기, 돈 저장할 곳 찾기.. 등)

 - 시스템 인터페이스 파악 : 데이터 종류, 통신규약, 연계 유형 (시스템 간 주고받는 데이터의 속성들 명시)

2단계. 

 - 아키텍처 구성 파악 : 업무 수행 기술 요소들이 사용되는지 최상위 수준에서 파악 (계층별로 표현한 구성도 작성)

 - 소프트웨어 구성 파악 : 소프트웨어 제품명, 용도, 라이선스 수, 적용 방식 명시

3단계.

 - 하드웨어 구성 파악 : 서버의 주요 사양, 서버의 이중화, 수량 

[서버의 이중화는 서비스 기간, 대응 정책에 따라 필요 여부 결정되며, 대기 서버로 서비스를 계속 유지할 수 있도록 동일하게 복제되도록 관리하는 것을 의미]

 - 네트워크 구성 파악 : 네트워크 구성 파악을 위해 네트워크 연결 방식을 구성도로 작성

(서버들의 물리적인 위치 관계를 파악 및 보안 취약성을 분석 후 적절한 대응 가능)

 

소프트웨어 아키텍처 : 관계를 표현하는 시스템 구조

소프트웨어 아키텍처 프레임워크 : 아키텍처 표준 기술

* 소프트웨어 프레임워크의 특징

 - 모듈화(Modularity)      : 프레임워크는 인터페이스에 의한 캡슐화를 통해서 모듈화를 강화하고 설계와 구현의 변경에 따르는 영향을 극소화하여 소프트웨어의 품질을 향상한다.

 - 재사용성(Reusability)   : 반복적으로 사용할 수 있는 컴포넌트를 정의할 수 있게 하여 재사용성을 높인다. ->개발자의 생산성도 높여주며, 소프트웨어의 품질을 향상해줌.

 - 확장성(Extensibility)    : 프레임워크는 다형성을 통해 넓게 사용할 수 있게 한다. 애플리케이션의 가변성으로부터 분리함으로써 재사 용서의 이점을 얻게 한다.

 - 제어의 역 흐름(Inversion of  control) : 프레임워크 코드가 전체 애플리케이션의 처리 흐름을 제어하여 특정 이벤트가 발생할 때 활 장한 메서드를 호출함으로써 제어가 프레임워크로부터 APP으로 반대로 흐르게 한다.

 

*소프트웨어 아키텍처 4+1 뷰 : 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법

 - 유스 케이스 뷰 : 유스 케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는 데 사용되는 뷰

 - 논리 뷰 : 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰

 - 프로세스 뷰 : 시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰

 - 구현 뷰 : 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰, 컴포넌트 구조와 의존성을 보여주고 부가적인 정보 정의

 -  배포 뷰 : 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는 가를 매핑해서 보여주는 뷰

*소프트웨어 아키텍처 패턴 유형

 - 계층화 패턴(Layered Pattern): 시스템을 계층으로 구분하여 구성하는 패턴

 - 클라이언트-서버 패턴(Client-Server Pattern): 하나의 서버와 다수의 클라이언트로 구성된 패턴

 - 파이프-필터 패턴(Pipe-Filter Pattern: 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴, 재사용성이 좋고 추가가 쉬워 확장에 용이 

 - 브로커 패턴(Broker Pattern): 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌트 원격 서비스 실행을 통해 상호작용이 가능

 - 모델-뷰-컨트롤러 패턴(MVC, Model-View-Controller Pattern): 대형 애플리케이션을 3개의 서브 시스템으로 구조화한 패턴, 컴포넌트로 분리되어있어 서로 영향을 받지 않고 개발 작업 수행 가능

       + 모델 (Model) : 핵심 기능과 데이터 보관

       + 뷰 (View): 사용자에게 정보 표시

       + 컨트롤러(Controller): 사용자로부터 요청을 입력받아 처리

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

 - SAAM : 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능 비용평가 모델

 - ATAM : 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상층 관계까지 평가하는 모델

 - CBAM : ATAM바탕의 시스템으로 경제적 의사결정에 대한 요구를 충족하여 평가 모델

 - ADR : 소프트웨어 아키텍처 구성요소 간 응집도 평가 모델

 - ARID : 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하여 비용 평가 모델

 

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

* 디자인 패턴 유형

 - 목적 

    + 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴

    + 구조 : 클래스나 객체의 조합을 다루는 패턴

    + 행위 : 클래스나 객체들이 상호작용하는 방법과 역할 분담을 다루는 패널

 - 범위 

    + 클래스 : 상속 관계를 다루는 패턴, 컴파일 타임에 정적으로 결정

    + 객체 : 객체 간 관련성을 다루는 패턴, 런타임 동적으로 결정

* 디자인 패턴 종류

  - 생성 패턴 : Builder, Prototype, Factory Method, Abstract Factory, Singleton 

  - 구조 패턴 : Bridge, Decorator, Facade, Flyweight, Proxy, Composite, Adapter

  - 행위패턴 : Mediator, Interpreterm Iterator, Template Method, Observer, State, Visitor, Command, Strategy, Memento, Chain of Responsibillity

 

03 개발 기술 환경 파악

개발기술환경은 개발하고자 하는 소프트웨어와 관련된 운영체제, 데이터베이스 관리 시스템, 미들웨어 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈 소스 사용 시 주의해야 할 내용을 제시.

 

* 운영체제란. 

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

컴퓨터 운영체제로는 Windows, UNIX, Linux, Max OS 등이, 모바일에서는 iOS, Android, Tizen 등이 있다.

 

os 요구사항 식별 시 고려사항 

 - 가용성     : 메모리 누수로 인한 성능 저하 및 재가동

 - 성능        : 지원 가능한 메모리 크기

 - 기술 지원 : 오픈 소스 여부 및 여러 사용자들 간의 정보 공유

 - 주변 기기 : 설치 가능한 하드웨어 및 여러 기기 지원 여부

 - 구축 비용 : 지원 가능한 하드웨어 비용, 라이선스 정책 및 비용, 유지관리 비용, 총 소유 비용(TCO) 

 

* DBMS 데이터베이스 관리 시스템

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

DBMS는 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템.

종류로는 Oracle, IBM DB2, Microsoft SQL Server, MySQL, SQLite, MongoDB, Redis 등이 있다.

 - 가용성        : 백업이나 복구의 편의성, DBMS 이중화 및 복제 지원

 - 성능           : 대규모 데이터 처리 성능, 최소화된 설정과 비용 기반 질의 최척화 지원

 - 기술 지원    : 오픈 소스 여부 및 여러 사용자들 간의 정보 공유

 - 상호 호환성 : JDBC, ODBC와의 호환 여부

 - 구축 비용    : 라이선스 정책 및 비용, 유지관리 비용, 총 소유 비용(TCO)

JDBC : JAVA에서 DB에 접근하여 관리할 수 있는 인터페이스

ODBC : 응용프로그램에서 DB에 접근하여 데이터를 관리할 수 있는 표준 인터페이스

 

* 미들웨어 종류

 - DB (DataBase) : 데이터베이스 벤더(Vendor)에서 제공하는 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어

 - RPC (Remote Procedure Call) : 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식의 미들웨어

 - MOM (Message Oriented Middleware) : 메시지 기반의 비동기형 메시지를 전달

 - TP-Monitor(Transaction Processing Monitor) : 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션을 처리 및 감시

 - ORB (Object Request Broker) : 객체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어

 - WAS (Web Application Server) : 사용자의 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어

(종류 : Tomcat, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 등)

 

* OSI계층 : 네트워크 통신에서 충돌 문제를 완화하기 위해 국제 표준화 기구 (ISO)에서 제시한 모델

 - 응용 계층(Applicatoin Layer) : 사용자와 네트워크 간 응용서비스 연결, 데이터 생성

 - 표현 계층(Presentation Layer) : 데이터 형식 설정과 부호 교환, 암/복호화

 - 세션 계층(Session Layer) : 연결 접속 및 동기제어

 - 전송 계층(Transport Layer) : 신뢰성 있는 통신보장. 데이터 분할과 재조립, 흐름 제어, 혼잡 제어 등 담당

 - 네트워크 계층(Network Layer) : 단말 간 데이터 전송을 위한 최적화된 경로 제공

 - 데이터 링크 계층(Data Link Layer) : 인접 시스템 간 데이터 전송, 전송 오류 제어

 - 물리 계층(Physical Layer) : 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환

 

04 요구사항 정의

* 요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타내며, 이해관계자(개발 의뢰자, 개발자, 사용자 등)들 간의 의사소통을 원할 하게 하는 데 도움을 준다.

* 요구 공학(Requirements Engineering): 사용자의 요구가 반영된 시스템을 개발하기 위해 사용자 요구사항에 대한 도출, 분석, 명세, 호가인 및 검증하는 구조화된 활동

 

* 요구사항의 유형

 - 기능 요구사항(Functional requirement) ; 시스템이 제공하는 기능, 서비스에 대한 요구사항

    + 특정 입력/상황에 대해 시스템이 어떻게 반응/동작해야 하는지에 대한 기술

    + 특성 : 기능성, 완전성, 일관성

 - 비기능 요구사항(Non-functional requirement) : 시스템 구축에 대한 제약사항에 관한 요구사항

    + 품 직속 성에 관련하여 시스템이 갖춰야 할 사항에 관한 기술, 시스템이 준수해야 할 제한 조건에 관한 기술

    + 특성 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항

 

* 요구사항 개발 프로세스 : 도출(Elicitation) --> 분석(Analysis) --> 명세(Specification) --> 확인(Validation)

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

 - 인터뷰, 설문, 브레인스토밍, 워크숍, 프로토타이핑, 유스 케이스, 델파이 기법 등

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

* 요구사항 분석 기법

 - 개념 모델링 : 요구사항을 보다 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화하여 개념적으로 표현한 것을 모델이라 하며, 이러한 모델을 만드는 과정을 모델링이라고 한다.

   + 개념 모델은 문제의 주체인 개체(Entity)들과 그들 간의 관계 및 종속성을 반영한다.

   + 종류 : 유스 케이스 다이어그램. 데이터 흐름 모델, 상태 모델, 목표 기반 모델, 사용자 인터액션, 객체 모델, 데이터 모델 등이 있다.

 - 정형 분석 : 구문(syntax)과 의미(Semantics)를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 수 이를 분석하는 과정

   + 수학적 기호로 기술하는 것.

* 요구사항 확인 단계 주요 기법

 - 요구사항 문서는 이해관계자들이 검토해야 하며, 일반적으로 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리를 수행한다.

    + 형상관리(SCM) : 소프트웨어의 개발 과정에서 만들어지는 형상들의 변경사항을 관리하는 활동

 - 요구사항 검토 : 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토

 - 정형 기술 검토 활용

    + 동료 검토 : 2~3명 리뷰 진행, 요구사항 명세서를 설명하고 이해관계자들이 들으면서 결함을 발견하는 형태로 진행

    + 워크 스루 : 검토 자료를 회의 전에 배포하여 짧은 시간 동안 회의를 진행하는 형태로 리뷰, 오류를 검출하고 문서화

    + 인스펙션 : 소프트웨어 요구, 설계 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 찾아내는 공식적 검토 방식

 - 프로토타이핑 활용 : 프로토타입(견본품)을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출하는 작업

 - 모델 검증 : 분석 단계에서 개발된 모델의 품질 검증 필요

 - 인수 테스트 : 사용자 입장에서 확인하는 과정 

    + 인수 테스트 종류 : 사용자 인수 테스트, 운영상의 인수 테스트, 계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타 검사

 - 테스트 케이스 및 테스트를 통한 확인 : 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 수립하고 테스트 케이스 작성

 - CASE 도구 활용 검증 : 자동화된 일관성 분석을 제공하는 CASE도구 활용

 - 베이스라인을 통한 검증 : 요구사항 변경을 체계적으로 추적하고 통제하는 시점인 베이스라인을 통한 요구사항에 대한 지속적 검증 수행

 - 요구사항 추적 표(RTM)를 통한 검증 : 요구사항 정의서를 기준으로 개발 단계별 최종 산출물이 어떻게 반영되고, 변경되었는지 확인이 가능한 문서