1. 요구사항 확인 (정보처리기사 실기)

01 소프트웨어 개발 방법론

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

 

▶ 애자일 방법론의 유형

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

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

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

 

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

 

▶ XP의 12가지 기본원리

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

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

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

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

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

 

▶ 델파이 기법

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

 

▶ 비용 산정 모형 종류

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

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

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

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

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

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

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

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

 

▶ 일정관리 모델 : 일정 기한 내에 적절하게 완료될 수 있도록 관리

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

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

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

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

 

 

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) : 원시 코드 등을 저작자 외의 다른 전문가 또는 팀이 검사해 오류를 찾아내는 공식적 검토 방법