정보처리기사 실기 - 요구사항확인 (10~12일차)

Ⅰ요구사항 확인

Chapter 01 소프트웨어 개발 방법론
1. 소프트웨어 개발 방법론
2. 프로젝트 관리
Chapter 02 현행 시스템 분석
1. 현행 시스템 파악
2. 개발 기술 환경 정의
Chapter 03 요구사항 확인
1. 요구사항
2. 요구사항의 시스템화 타당성 분석

 

Chapter 01 소프트웨어 개발 방법론

●소프트웨어 생명주기(SDLC)

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

- 실무예시 : 고객의 요구사항 및 과제전달 - 과제 분석 및 설계 -  개발 - 테스트 - 반영 - 유지보수

 

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

폭포수 모델 : 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어간다.

프로토타이핑 모델 : 프로토타입을 구현해, 고객의 피드백을 방영하며 만들어 간다.

나선형 모델 : 위험을 최소화하기 위해 점진적으로 개발한다.

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

 

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

구조적 방법론 : 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합한다. 나씨-슈나이더만 차트 사용

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

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

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

애자일 방법론 : 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템 개발제품 개발 제품 계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발, 임베디드

 

 

●애자일 방법론의 유형

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

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

LEAN :  도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해 낭비 요소를 제거하는 방법론

 

●XP의 5가지 가치  

용기

단순성

의사소통

존중

피드백

 

●XP의 12가지 기본원리

⦁ 짝 프로그래밍 : 개발자 둘이서 짝으로 코딩하는 원리

⦁ 지속적인통합(CI) : 매일 여러번씩 소프트웨어를 통합하고 빌드

⦁ 메타포어(Metaphor) : 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게 한다.

⦁ 테스트 기반 개발(TDD) : 만들 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다.

⦁ 리팩토링(Refactoring) : 프로그램의 기능은 바꾸지 않고 중복제거, 단순화 등을 위해 시스템 재구성을 한다.

 

●객체 지향 구성요소

⦁ 클래스

⦁ 객체

⦁ 메서드

⦁ 메시지

⦁ 인스턴스

⦁ 속성

 

● 객체지향 기법 (캡상다추정관)

캡슐화(Encapsulation) : 필요한 인터페이스만 밖으로 드러내는 기법

상속성(Inheritance) : 상위 클래스의 속성과 메서드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법

다형성(Polymorphism) : 상속받은 여러개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질

추상화(Abstraction): 공통 성질을 추출하여 추상 클래스를 설정하는 기법

정보은닉(Information Hiding): 코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술

관계성(RelationShip) : 두개이상의 엔터티 형에서 데이터를 참조하는 관계를 나타내는 기법

 

● 객체지향 설계 원칙

⦁단일 책임의 원칙(SRP; Single Responsibility Principle) : 하나의 클래스는 하나의 목적을 위해서 생성

⦁개방 폐쇄 원칙(OCP; Open Close Principle): 소프트웨어 구성요소는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원칙

⦁리스코프 원칙(LSP; Liskov Substitution Principle) : 서브 타입은 어디서나 자신의 기반 타입으로 교체 할 수 있어야 한다는 원칙

⦁인터페이스 분리 원칙(ISP; Interface Segregation Principle): 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙

⦁의존성 역전의 원칙(DIP; Dependency Inversion Principle) :  관계를 최대한 느슨하게 만드는 원칙

 

●델파이 기법

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

 

●비용 산정 모형 종류

⦁ LOC(Line of codd) 모형 : 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정해 예측치를 구해 비용을 산정하는 방식

⦁ Man Month 모형 :  한사람이 1개월동안 할 수 있는 일의 양을 기준으로 프로젝트 비용 산정하는 방식

  Man Month = LOC /  생산성 

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

⦁ COCOMO 모형 : 보헴이 제한, 프로그램 규모에 따른 비용 산정 

- 조직형(Organic Mode) : 5만라인 이하 

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

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

⦁ 푸트남 모형 : 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식, 생명주기 예측 모형, Reyleigh - Norden 곡선

⦁ 기능점수(FP; Function Point) : 요구 기능에 따른 가중치 부여

 

●일정관리 모델

⦁ 일정 기한 내에 적절하게 완료될 수 있도록 관리

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

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

⦁ 주 공정 연쇄법 : 자원제약사항을 고려해 일정 작성

---

Chapter 02 현행 시스템 분석

▶ 현행 시스템 파악

구성/기능/인터페이스 파악 -> 아키텍처 및 소프트웨어 구성 파악 -> 하드웨어 및 네트워크 구성 파악

 

▶ 소프트웨어 아키텍처

여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구초체이다.

 

▶ 소프트웨어 아키텍처 4+1 뷰

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

⦁  유스케이스 뷰 : 다른 뷰를 검증하는데 사용

⦁  논리 뷰 : 시스템의 기능적 요구사항 설명

⦁  프로세스 뷰 : 시스템의 비기능적 요구사항 설명

⦁  구현 뷰 : 모듈의 구성, 컴포넌트 구조, 의존성

⦁  배포 뷰 : 어떻게 배치되는가.

 

▶ 유스케이스(Usecase)

시스템 요구사항이자, 사용자의 입장에서 바라본 시스템의 기능

 

▶ 소프트웨어 아키텍처 패턴

소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식

 

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

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

⦁  클라이언트-서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성된 패턴

⦁  파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용

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

⦁  모델-뷰-컨트롤러 패턴(MVC)

        - 모델 : 핵심 기능과 데이터 보관

        - 뷰 : 사용자에게 정보 표시

        - 컨트롤러 : 사용자로부터 요청 입력 받아 처리

 

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

⦁  SAAM : 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능

⦁  ATAM : 아키텍처 품질 속성을 만족시키는지 판단

⦁  CBAM : ATAM 바탕의 시스템, 경제적 의사결정에 대한 요구 총족

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

⦁  ARID : 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중

 

▶ 디자인 패턴

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

 

▶ 디자인 패턴의 유형

⦁  목적 

- 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식 구조화, 캡슐화 수행

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

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

⦁  범위 : 클래스, 객체

 

▶ 디자인 패턴 종류

◇ 생성 패턴

⦁  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 : Undo 기능 개발

⦁  Chain of Responsibility : 정적으로 어떤 기능에 대한 처리의 연결이 하드 코딩 되어 있을 때, 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 디자인

 

▶ 운영체제

컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스 담당

 

▶ 운영체제 종류

윈도즈, 유닉스, 리눅스, 안드로이드, iOS

 

▶ 미들웨어

분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어

 

---

03 요구사항 확인

▶ 요구공학(Requirements Engineering)

사용자의 요구가 반영된 시스템을 개발하기 위해서 사용자의 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동

 

▶ 기능적 요구사항 : 시스템이 제공하는 기능, 서비스에 대한 요구사항(기능성, 완전성, 일관성)

 

▶ 비기능적 요구사항 : 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항, 품질, 시스템 환경, 프로젝트 계획에 관한 요구사항

 

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

⦁  인터뷰, 워크숍, 브레인스토밍, 설문 조사

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

⦁  롤 플레잉 : 현실에서 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함

 

▶ 정형 기술 검토(요구사항 확인 및 검증 단계의 주요 기법)

⦁  동료 검토(Peer Review) : 2~3명이 진행, 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견

⦁  워크 스루(Walk Through) : 회의 전에 검토 자료를 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태

⦁  인스펙션(Inspection) : 원시 코드 등을 저작자 외의 다른 전문가 또는 팀이 검사해 오류를 찾아내는 공식적 검토 방법