Computer Science/정보처리기사

[정보처리기사-실기] 1장 요구사항 확인

eyi-jin 2022. 4. 18. 14:48

순서
CH1 SW 개발 방법론
CH2 현행 시스템 분석
CH3 요구사항 확인
CH4 분석모델 확인하기

<CH1 SW개발 방법론>

소프트웨어 생명주기

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

모델 종류

폭포수 모델: 가장 오래됨, 각 단계 마무리 후 다음
프로토타이핑 모델 : 주요 기능 프로토타입으로 구현, 고객의 피드백 중심
나선형 모델 : 점진적 개발 → 위험 최소화
반복적 모델 : 구축 대상 나눠 병렬적 개발 후 통합

소프트웨어 개발 방법론

소프트웨어 개발부터 폐기까지 전과정을 형상화한 방법론

애자일 방법론
객체 지향 방법론
구조적 방법론
정보공학 방법론
컴포넌트 기반 방법론
제품 계열 방법론

애자일(Agile) 방법론

XP(eXtreme Programming)

스크럼(Scrum)

린(Lean)

객체 지향 방법론

객체 지향 분석(OOA)

사용자 요구사항 분석 → 클래스, 속성과 연산 정의

OOSE(Object Oriented Software Engineering): 야콥슨

OMT(Object Modeling Technology): 럼바우

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

객체 모델링 - ER 다이어그램
동적 모델링 - 상태 다이어그램
기능 모델링 - DFD(자료 흐름 다이어그램)

비용산정 모형

하향식 산정

전문가와 조정자를 통한 비용산정

델파이 기법 : 경험적 지식 → 문제 해결 및 예측

상향식 산정

요구사항, 기능에 따른 비용산정

LoC(Lines of Code) : 낙관치, 중간치, 비관치 → 예측치
Man Month : 1사람이 1개월 동안 하는 일을 기준
COCOMO : 보헴이 제안, 프로그램 규모 기준
- 조직형(Organic Mode) : 5만 라인 이하
- 반 분리형(Semi-Detached Mode) : 30만 라인 이하
- 임베디드형(Embedded Mode) : 30만 라인 이상
Putnam(푸트남) : 개발 단계별 인력의 분포를 가정
FP(기능 점수) : 기능별로 가중치 부여

비용산정 자동화 추정 도구

SLIM

Rayleigh-Norden 곡선, Putnam 예측 모델 → 자동화 추정 도구

ESTIMACS

FP모형 기초 → 자동화 추정 도구

일정 관리 모델

프로젝트가 일정 기한 내에 완료될 수 있도록 관리

CPM(Critical Path: 주 공정법)
PERT
CCPM(중요 연쇄 프로젝트 관리)

<CH2 현행 시스템 분석>

현행 시스템 파악

현행시스템의 기술 요소를 파악함

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

구성 : 기간업무와 지원업무 구별

⚠️명칭, 주요 기능 명시

기능 : 제공하는 기능

⚠️주요기능과 하부기능을 계층형으로 표시

인터페이스 : 데이터 종류, 형식, 프로토콜, 연계유형, 주기 명시

2. 아키텍처 및 소프트웨어 구성 파악

아키텍처 구성도 → 그림으로 파악

⚠️핵심기능을 중심으로 파악해야함

소프트웨어 구성도(시스템 명, SW제품명, 용도, 라이선스 적용방식, 라이선스 수)

⚠️보유한 라이선스 수량 파악 중요!(비용 문제)

3. 하드웨어 및 네트워크 구성 파악

하드웨어 구성도 : 이중화가 적용됐는지 여부

⚠️인프라 구축 기술 난이도, 비용 증가 가능성

네트워크 구성도 : 위치, 용도, 장비 제품명, 주요 사양, 수량

⚠️서버 위치, 연결 방식 고려

현행 시스템 분석서 작성

1.현행 시스템 관련 자료 수집
2. 수집한 자료 분석
3. 분석한 결과 → 산출물
4. 작성된 산출물 검토

💡 현행 시스템을 분석하기 위해서는 많은 시간과 비용이 들기 때문에 분석 범위와 수준을 정함

SW 아키텍처

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

SW 아키텍처 4+1 뷰

요구사항을 정리해놓은 시나리오를 4개의 관점에서 바라봄

유스케이스 뷰
논리 뷰
프로세스 뷰
구현 뷰
배포 뷰

SW 아키텍처 패턴

계층화 패턴
클라이언트-서버 패턴
파이프-필터 패턴
브로커 패턴
모델-뷰-컨트롤러 패턴

SW 아키텍처 비용 평가 모델

SAAM
ATAM
CBAM
ADR
ARID

디자인 패턴

SW 설계에서 공통적으로 발생하는 문제를 자주 쓰이는 설계 방법으로 정리함

디자인 패턴 유형

목적

생성 패턴	구조 패턴	행위 패턴
객체의 생성과 관련된 패턴	클래스나 객체들을 조합하여 더 큰구조로 만들 수 있게 해주는 패턴	클래스나 객체들이 상호작용 하는 방법이나 책임 분배 방법을 정의하는 패턴
- 추상 팩토리(Abstract Factory) - 팩토리 메소드(Factory Method) - 빌더(Builder) - 프로토타입(Prototype) - 싱글톤(Singleton)	- 어댑터(Adapter) - 브리지(Bridge) - 컴포지트(Composite) - 데코레이터(Decorator) - 퍼사드(Facade) - 플라이웨이트(Flyweight) - 프록시(Proxy)	- 책임 연쇄(Chain of Responsibility) - 커맨드(Command) - 인터프리터(Interpreter) - 반복자(Iterator) - 중재자(Mediator) - 메멘토(Memento) - 옵서버(Observer) - 상태(State) - 전략(Strategy) - 템플릿 메소드(Template Method) - 방문자(Visitor)

생성 패턴

추상 팩토리
동일한 주제의 다른 팩토리를 묶어줌
구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴
빌더
생성과 표기를 분리해 복잡한 객체를 생성
팩토리 메소드
생성할 객체의 클래스를 국한하지 않고 객체를 생성
객체 생성 처리를 서브 클래스로 분리해 처리하도록 캡슐화하는 패턴
프로토타입
기존 객체를 복제함으로써 객체를 생성
싱글톤
한 클래스에 한 객체만 존재하도록 제한
전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며,
생성된 객체를 어디서든지 참조할 수 있도록 하는 패턴

구조 패턴

어댑터
인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록,
타 클래스의 인터페이스를 기존 인터페이스에 덧씌움
브리지
추상화와 구현을 분리해 둘을 각각 따로 발전시킬 수 있음
컴포지트
0개, 1개 혹은 그 이상의 객체를 묶어 하나의 객체로 이용할 수 있음
복합 객체와 단일 객체를 클라이언트에서 구별없이 다루게 해주는 패턴
퍼사드
많은 분량의 코드에 접근할 수 있는 단순한 인터페이스 제공
프록시
접근 조절, 비용 절감, 복잡도 감소를 위해 접근이 힘든 객체에 대한 대역을 제공함

행위 패턴

커맨드
위의 명령어를 각각 구현하는 것보다는 하나의 추상 클래스에 메서드를 하나 만들고
각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행하는 것
실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계
옵저버
어떤 클래스에 변화가 일어났을 때, 이를 감지하여 다른 클래스에 통보해주는 것
한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들의 내용이 자동으로 갱신되는 패턴
템플릿 메소드
상위 클래스에서는 추상적으로 표현하고, 그 구체적인 내용은 하위 클래스에서 결정되는 디자인 패턴
작업 처리 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 동일하게하고, 특정 단계에서 수행하는 내역을 바꾸는 패턴

범위

클래스 패턴
상속 관계, 컴파일 타임에 정적으로 결정
객체 패턴
객체 간 관련성, 런타임에 동적으로 결정

디자인 패턴 종류

생성패턴 : Builder, Prototype, Factory Method, Abstract Factory, Singleton
구조패턴 : Bridge, Decorator, Facade, Flyweight, Proxy, Composite, Adapter
행위패턴 : Mediator, Interpreter, Iterator, Template Method, Observer, State, Visitor, Command, Strategy, Memento, Chain of Responsibility

OSI 계층

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

이미지 출처:[https://shlee0882.tistory.com/110]
(22.04.08확인)

응용 계층(Application Layer)
사용자와 네트워크 간 응용서비스 연결, 데이터 생성
표현 계층(Presentation Layer)
데이터 형식 설정과 부호교환, 암/복호화
세션 계층(Session Layer)
연결 접속 및 동기 제어
전송 계층(Transport Layer)
신뢰성 있는 통신 보장, 데이터 분할과 재조립, 흐름제어, 혼잡제어
네트워크 계층(Network Layer)
단말 간 데이터 전송을 위한 최적화된 경로 제공
데이터 링크 계층(Data Link Layer)
인접 시스템 간 데이터 전송, 전송 오류 제어
물리 계층(Physical Layer)
0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환

개발 기술 환경

1.운영체제
2. DBMS
3. 미들웨어
4. 오픈소스

1. 운영체제

HW와 SW 리소스 관리

신뢰도 : 장애 발생 가능성

성능 : 대규모 동시 사용자 처리

기술지원 : 안정적 기술지원

주변기기 : 설치 가능한 HW

구축비용 : 유지 및 관리 비용

2. DBMS

사용자, 애플리케이션, 데이터베이스와 상호작용하여 데이터 저장 및 분석함

가용성 : 장애 발생 가능성

성능 : 데규모 데이터 처리

기술지원 : 안정적 기술지원

상호 호환성 : 설치 가능한 운영체제

구축비용

3. 미들웨어

종류

RPC(Remote Procedure Call) : 원격 동작 프로시저 호출

MOM(Message Oriented Middleware) : 메시지 송수신

ORB(Object Request Broker) : 객체지향 시스템에서 객체 및 서비스 요청 및 전송

DB 접속 미들웨어 : app과 DB 서버 연결

TR 모니터(Transaction Processing) : 분산 시스템 app 지원, 트랜잭션 처리 감시 및 제어

웹 애플리케이션 서버 : 웹 앱 지원

OS 와 SW 애플리케이션 사이, 운영체제 제공서비스를 확장

가용성

성능

기술지원

구축비용

4. 오픈소스

소스코드 공개하여 제한없이 코드 보고 사용가능
오픈소스 라이선스를 만족하는 SW

라이선스 종류

사용자 수

기술의 지속 가능성

개발 기술 환경 정의

1.기술 환경 정의를 위한 자료 수집
2. 조사자료 분석, 개발 기술 환경 설정

1. 기술 환경 정의를 위한 자료 수집

시스템 구축 형태
사용자 수
트랜잭션 수
온라인 업무
배치 업무
데이터베이스
데이너 벡업
운영시간

2. 조사자료 분석, 개발 기술 환경 결정

운영체제 - 리눅스, 유닉스, 윈도우
DBMS - 상용 DBMS, 오픈 소스 DBMS
웹 앱 서버 - 개발용 , 운영용
시스템 용량 산정 = 온라인 트랜잭션 처리(OLTP:Online Transaction Processing), web/was기초 자료 조사 항목 값 이용

<CH3 요구사항 확인>

요구사항

기능적 요구사항
- 시스템이 제공하는 기능, 서비스 요구사항
- 기능성, 완전성, 일관성
비기능적 요구사항
- 품질과 관련된 사항
- 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성, 제약사항

요구사항 개발 프로세스

요구사항 도출, 분석, 명세, 확인 및 검증하는 일련의 구조화된 활동

1. 도출(Eliciation: 요수사항 수집)
- stakeholder들이 의견 교환하여 요구사항 식별 및 이해
- SDLC(SW Development Life Cycle)동안 지속적 반복
- 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑 유스케이스
2. 분석(Analysis)
- 개발 대상의 사용자 요구사항 이해
- 모호한 요구사항 발견하기 위한 과정
- 상충되는 요구사항 중재
3. 명세(Specification)
- 분석된 요구사항 바탕으로 모델 작성 및 문서화
- 기능 요구사항 전부, 비기능 요구사항 필요한 것만 작성
4. 확인(Validation: 요구사항 검증)
- 요구사항 할당 전, 요구사항 명세서가 정확 안전하게 작성됐는지 검토
- 이해관계자들이 검토
- 요구사항 관리 도구로 요구사항 정의 문서에 대해 형상관리(SCM) 수행

요구사항 도출 기법

인터뷰, 브레인스토밍, 델파이기법 (경험적 지식으로 문제해결 & 예측), 롤 플레잉, 워크숍, 설문조사

요구사항 확인 및 검증 기법

정형 기술 검토(FTR- Formal Technical Review)
- 동료 검토 : 2~3명 리뷰 진행, 요구 명세서 설명하며 이해관계자들이 들으면서 결함 발견
- 워크 스루 : 회의 전 검토 자료 배포, 짧은 회의
- 인스펙션 : 외부 전문가가 검사하여 오류를 찾아냄
프로토타이핑 활용
모델 검증
테스트 케이크 및 테스트
CASE 도구 활용 검증
베이스라인 검증
요구사항 추적표(RTM) 이용한 검증

<CH4 분석모델 확인하기>

분석 모델 검증 방법

유스케이스 모델

개념수준의 분석 클래스

분석 클래스

💡 참고 블로그

https://dustink.tistory.com/152

https://velog.io/@mrnglory/정처기-요약-요구사항

디자인 패턴: https://ss-o.tistory.com/141?category=1013696