시나공 정보처리기사 실기 요약 1장 요구사항 확인 정리

SECTION 001

(2) 폭포수 모형(Waterfall Model)

각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론이다.

가장 오래되고 전통적인 소프트웨어 생명 주기 모형, 고전적 생명 주기 모형, 결과물이 명확하게 산출되어야 한다.

(4) 나선형 모형(Spiral Model, 점진적 모형)

보헴이 제안, 위험 분석 기능을 추가한 모형

4가지 주요 활동

계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가

(5) 애자일 모형(Agile Model)

고객의 요구사항 변화에 유연하게 대응, 일정한 주기를 반복하면서 개발하는 모형

스크럼, XP, 칸반, Lean, 기능 중심 개발(FDD)

 

SECTION 002

(1) 스크럼(Scrum)

팀이 중심이 되어 개발의 효율성을 높이는 기법, 팀원 스스로가 스크럼 팀을 구성

스프린트 계획 회의 -> 스프린트 수행 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회의

 

SECTION 003

(1) XP(eXtreme Programming)

XP의 5가지 핵심 가치

의사소통, 단순성, 용기, 존중, 피드백

(2) XP 개발 프로세스

소규모 릴리즈 : 요구사항에 유연하게 대응할 수 있도록 릴리즈 규모를 축소한 것

(3) XP의 주요 실천 방법(Practice)

Pair Programming(짝 프로그래밍)	다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성함
Collective Ownership(공동 코드 소유)	개발 코드에 대한 권한과 책임을 공동으로 소유함
Refactoring(리펙토링)	프로그램 기능의 변경 없이 시스템을 재구성함 목적 : 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함
Small Releases(소규모 릴리즈)	릴리즈 기간을 짧게 반복함으로서 고객의 요구 변화에 신속히 대응할 수 있음

 

SECTION 004 현행 시스템 파악

프로세스	현행 시스템	내용
1단계	시스템 구성 파악	조직의 주요 업무를 담당하는 기능 업무와 이를 지원하는 지원 업무로 구분하여 기술함
	시스템 기능 파악	현재 제공하는 기능들을 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시함
	시스템 인터페이스 파악	단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시함
2단계	아키텍처 구성 파악	최상위 수준에서 계층별로 표현한 아키텍처 구성도를 작성함
	소프트웨어 구성 파악	소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시함
3단계	하드웨어 구성 파악	단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 서버의 이중화 적용 여부를 명시함
	네트워크 구성 파악	서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성함

SECTION 005

(4) 웹 애플리케이션 서버(WAS; Web Application Server)

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

데이터 접근

주로 데이터베이스 서버와 연동

 

SECTION 006

(1) 요구사항

기능 요구사항

비기능 요구사항

(2) 비기능 요구사항

어떤 기능을 하는지

사용자가 시스템을 통해 제공받기를 원하는 기능

(3) 비기능 요구사항

시스템

 

SECTION 007

(2) 요구사항 도출(Requirement Elicitation, 요구사항 수집)

어떻게 수집할 것인지를 식별하고 이해하는 과정이다.

브레인스토밍, 유스케이스

(3) 요구사항 분석

요구사항 분석에 사용되는 대표적인 도구

- 자료 흐름도(DFD)

- 자료 사전(DD)

(4) 요구사항 명세(Requirement Specification)

요구사항 명세 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것

(7) 요구사항 명세 기법

구분	정형 명세 기법	비정형 명세 기법
기법	수학적 원리 기반, 모델 기반	상태/기능/객체 중심
작성 방법	수학적 기호, 정형화된 표기법	일반 명사, 동사 등의 자연어를 기반으로 서술 또는 다이어그램으로 작성
특징	요구사항을 정확하고 간결하게 표현할 수 있음 요구사항에 대한 결과가 작성자에 관계없이 일관성이 있으므로 완전성 검증이 가능함 표기법이 어려워 사용자가 이해하기 어려움	자연어의 사용으로 인해 요구사항에 대한 결과가 작성자에 따라 다를 수 있어 일관성이 떨어지고, 해석이 달라질 수 있음 내용의 이해가 쉬어 의사소통이 용이함
종류	VDM, Z, Petri-net, CSP 등	FSM, Decision Table, ER모델링, State Chart(SADT) 등

 

SECTION 008

(1) 요구사항 분석(Requirement Analysis)

타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.

(4) 자료 흐름도 기본 기호

기호	의미	표기법
		Yourdon/DeMacro	Gane/Sarson
프로세스(Process)	자료를 변환시키는 시스템의 한부분(처리, 과정)을 나타내며 처리, 기능, 변환, 버블이라고도함
자료 흐름(Data Flow)	자료의 이동(흐름)이나 연관관계를 나타냄
자료 저장소(Data Store)	시스템에서의 자료 저장소(파일, 데이터베이스)를 나타냄
단말(Terminator)	시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받음

(5) 자료 사전(DD; Data Dictionary)

데이터를 설명하는 데이터, 메타 데이터(Meta Data)

기호	의미
=	자료의 정의 : ~로 구성되어 있다(is composed of)
+	자료의 연결 : 그리고(and)
(  )	자료의 생략 : 생략 가능한 자료(Optional)
[  ]	자료의 선택 : 또는(or)
{  }	자료의 반복 : lteration of
* *	자료의 설명 : 주석(Comment)

 

SECTION 009

(2) HIPO(Hierarchy Input Process Output)

시스템의 분석 및 설계, 또는 문서화에 사용되는기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 표현한 것이다.

하향식 소프트웨어 개발을 위한 문서화 도구이다.

기호, 도표 등을 사용하므로 보기 쉽고 이행하기도 쉽다.

 

SECTION 010

(1) UML(Unified Modeling Language)

객체지향 모델링 언어

사물, 관계, 다이어그램

 

SECTION 011

(5) 일반화(Generalization) 관계

하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계

(6) 의존(Dependency) 관계

서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계

(7) 실체화(Realization) 관계

서로를 그룹화 할 수 있는 관계

 

SECTION 012 UML - 다이어그램

(1) 다이어그램(Diagram)

정적 모델링에서는 주로 구조적 다이어그램을 사용한다.

동적 모델링에서는 주로 행위 다이어그램을 사용한다.

(2) 구조적(Structural) 다이어그램의 종류

종류	내용
클래스 다이어그램	클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현함
객체 다이어그램	클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현함
컴포넌트 다이어그램	실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현함 구현 단계에서 사용됨
배치 다이어그램	결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현함 구현 단계에서 사용됨
복합체 구조 다이어그램	클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현함
패키지 다이어그램	유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지 들의 관계를 표현함

 

(3) 행위(Behavioral) 다이어그램의 종류

종류	내용
유스케이스 다이어그램	사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용함
시퀀스 다이어그램	상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현함
커뮤니케이션 다이어그램	동작에 참여하는 객체들이 주고받는 메시지와 객쳊들 간의 연관 관계를 표현함
상태 다이어그램	럼바우(Rumbaugh) 객체지향 분석 기법에서 동적 모델링에 활용됨
활동 다이어그램	시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현함

(4) 스테리오 타입(Stereotype)

길러멧(Guilemet)이라고 부르는 겹화살괄호(<<>>)상에 표현할 형태를 기술한다.

주로 표현하는 형태

표현 형태	의미
<<include>>	연결된 다른 UML 요소에 대해 포함 관계에 있는 경우
<<extend>>	연결된 다른 UML 요소에 대해 확장 관계에 있는 경우

 

SECTION 018 상태(State) 다이어그램

(1) 상태(State) 다이어그램

이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것이다.

 

SECTION 019 패키지(Package) 다이어그램

(2) 패키지 다이어그램의 구성 요소

ex) 다음은 회원이 상품 주문 시 패키지들 간의 의존 관계를 표현한 패키지 다이어그램이다.

 

SECTION 020 소프트웨어 개발 방법론

(2) 구조적 방법론

처리 (Process) 중심의 방법론

1960년대까지 가장 많이 적용되었던 소프트웨어 개발 방법론이다.

타당성 검토 단계 -> 계획 단계 -> 요구사항 단계 -> 설계 단계 -> 구현 단계 -> 시험 단계 -> 운용/유지보수 단계

(4) 객체지향 방법론

부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론

객체지향 방법론의 구성 요소 : 객체, 클래스, 메시지

객체지향 방법론의 기본 원칙 : 캡슐화, 정보 은닉, 추상화, 상속성, 다형성

(5) 컴포넌트 기반(CBD; Component Based Design) 방법론

컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론이다.

유지 보수 비용을 최소화하고 생산성 및 품질을 향상 시킬 수 있다.

 

SECTION 021 S/W 공학의 발전적 추세

(1) 소프트웨어 재사용(Software Reuse)

합성 중심

합성 중심	블록을 만들어서 끼워 맞춰 소프트웨어를 완성, 블록 구성 방법이라고도 함
생성 중심	추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 ㅂ방법, 패턴 구성 방법

(3) CASE(Somputer Aided Software Engineering)

요구 분석, 설계, 구형 검사 및 디버깅 과정 전체 또는 일부를 전용 소프트웨어 도구를 사용하여 자동화

() CASE의 주요 기능

- 소프트웨어 생명 주기 전 단계의 연결

- 다양한 소프트웨어 개발 모형 지원

- 그래픽 지원

 

SECTION 023 비용 산정 기법 - 하향식

(2) 전문가 감정 기법

두 명 이사의 전문가에게 비용 산정을 의뢰

개인적이고 주관적일 수 있다.

(3) 델파이 기법

주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법

 

SECTION 024 비용 산정 기법 - 상향식

(2) LOC(원시 코드 라인 수, source Line Of Code) 기법

비관치, 낙관치, 기대치

예측치 = (a+4m+b)/6 단, a : 낙관치, b : 비관치, m : 기대치(중간치)

() 산정 공식

- 노력(인월) = 개발 기간 * 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수

 

SECTION 025 수학적 산정 기법

(2) COCOMO(COnstructive COst MOdel) 모형

LOC(원시 코드 라인 수)에 의한 비용 산정 기법

LOC를 예측한 후 비용을 산정한다.

(3) COCOMO의 소프트웨어 개발 유형

유형	특징
조직형	중*소 규모의 소프트웨어, 5만(50KDSI) 라인 이하
반분리형	중간형 소프트웨어 30만(30KDSI) 라인 이하의 소프트웨어를 개발
내장형	초대형 소프트웨어 30만(300KDSI) 라인 이상의 소프트웨어를 개발

(5) Putnam 모형

노력의 분포를 예상하는 모형

푸트남(Putnam)이 제안

곡선의 노력 분포도를 기초로 한다.

(6) 기능 점수(FP; Function Point) 모형

소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여

기능 점수(FP)를 구한 후 이를 이용해서 비용을 산정

알브레히트(Albrecht)가 제안

 

SECTION 026

(4) 간트 차트

가트 차트 프로젝트의 각 작업들이 언제 시작되고 언제 종료되는지에 대한 작업 일정을 막대 도표를 이용.

시간선(Time-Line) 차트

수평 막대의 길이는 각 작업(Task)의 기간을 나타낸다.

 

SECTION 030 소프트웨어 개발 프레임워크

(1) 소프트웨어 개발 프레임워크

소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구형

반제품 형태의 소프트웨어 시스템

(2) 스프링 프레임워크(Spring Framework)

자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크

(3) 전자정부 프레임워크

공공부문 정보화 사업 시 효율적인 정보 시스템의 구축을 지원하기 위해 필요한 기능 및 아키텍처를 제공하는 프레임워크

(4) 닷넷 프레임워크(.NET Framework)

Windows 프로그램의 개발 및 실행 환경을 제공하는 프레임워크

(5) 소프트웨어 개발 프레임워크의 특성

특성	내용
모듈화(Modularity)	프레임워크는 캡슐화를 통해 모듈화를 강화하고 설계 및 구형의 변경에 따른 영향을 최소함으로써 소프트웨어의 품질을 향상시킴 프레임워크는 개발 표준에 의한 모듈화로 인해 유지 보수가 용이함
재사용성(Reusability)	프레임워크는 재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증이 가능함
확장성(Extensibility)	프레임워크는 다형성(Polymorphism)을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 가진 애플리케이션 개발이 가능함
제어의 역흐름(Inversion of Control)	개발자가 관리하고 통제해야 하는 객체들의 제어를 프레임워크에 넘김으로서 생산성을 향상시킴