목적
최근에 이직을 준비하는중에 자격증이 너무 없다고 생각이 들어서 준비를 하게되었다. 또한 내가 다시 봤을때 복습겸 이해하기 글을 작성한다.
1과목 소프트웨어 설계
소프트웨어 개발 방법론
상용 소프트웨어 분류체계
산업 범용 소프트웨어: 시스템SW, 미들웨어, 응용SW
산업 특화 소프트웨어: 자동차, 항공, 교육, 물류 등의 산업전용
응용 소프트웨어 분류체계(6가지)
기업용 소프트웨어: 오피스웨어, ERP, SCM, BI, CRM
영상 처리 소프트웨어: 영상인식, 스트리밍, 영상편집
CG/VR 소프트웨어: 3D 스캐닝과 프린팅, 모델링, 가상현실, 홀로그램
콘텐츠 배포 소프트웨어: 콘텐츠 보호, 관리, 유통
자연어 처리 소프트웨어: 정보 검색과 질의응답, 의사 결정 지원, 언어분석
음성 처리 소프트웨어: 음성 인식, 합성, 처리
기업용 소프트웨어(5가지)
오피스웨어: 워드, 엑셀, 그룹웨어 등의 일반 업무용
ERP: 경영 활동 프로세스 통합 관리
SCM: 물류의 흐름 파악 및 지원
BI: 데이터를 활용하여 의사 결정 지원
CRM: 고객 특성에 맞는 마케팅 활동 지원
시스템 소프트웨어
효율적으로 컴퓨터 시스템을 사용하도록 돕은 소프트웨어이다.
시스템의 기본요소(5가지)
입력(Input): 시스템 처리가 필요한 데이터, 제어 요소 등을 전달
처리(Process): 입력된 값을 정해진 방식에 맞게 처리하여 결과를 도출
출력(Output): 처리 결과를 출력장치(모니터, 프린터)및 저장 장치로 전달
제어(Control): 데이터 처리를 위해 각 장치들의 기능 수행을 제어
피드백(Feedback): 기능 수행이 잘못된 경우 적절한 경우 적절한 처리과정을 다시 반복
시스템의 성능평가 기준
처리능력(Throughput): 단위 시간 내 작업 처리량
반환 시간(Thrnaround Time): 작업 의뢰부터 처리까지의 시간
사용 가능도(Availavility): 필요할때 즉시 사용 가능한 정도(가용성)
신뢰도(Reliability): 주어진 문제를 정확하게 해결하는 정도
플랫폼(flatform)
특정 시스템을 바탕으로 제공되는 운영체제 및 운영환경을 말한다.
플랫폼의 성능을 측정하는 기준(4가지)
가용성(Availability): 필요할때 즉시 사용 가능한 정도(사용 가능도)
응답 시간(Response Time): 명령에 반응하는 시간(처리 시간과 다름)
정확성(Accuracy): 처리 결과가 기대한 값과 비교해서 정확한지 측정
사용률(Utilization): 데이터 처리에 시스템 자원을 상용하는 정도
소프트웨어 공학(효율)
최소의 비용과 개발 기간을 통해 높은 품질의 소프트웨어를 도출하기 위한 모든 수단과 도구들의 총칭이다.
소프트웨어 공학의 목적(3가지)
소프트웨어 개발에 필요한 비용과 기간의 예측
하드웨어어에 대한 소프트웨어의 상대적 비용 절감
급속하게 발전하는 하드웨어, 소프트웨어 기술 반영
소프트웨어 개발 프레임워크
모듈(Module)
프로그램을 기능별로 분할(부품)하여 재사용이 가능하게끔 부품화한 것이다.
라이브러리(Library)
관련 있는 모듈들을 모아놓은 것이다.
표준 라이브러리: 프로그래밍 언어에 내장
외부 라이브러리: 별도의 설치를 통해 사용 가능
디자인 패턴(Design Pattern)
특정 기능에 대한 문제해결을 위한 추상적인 가이드라인을 제시한 것이다.
소프트웨어 개발 프레임워크(Framework)
디자인 패턴에 모듈의 장점 및 기능을 결합하여 실제적인 개발의 틀(frame)을 제공한다.
개발자가 기능을 구체화하는 제어의 역 흐름이 발생한다.
구조를 잡아주는 코드의 모임이며 자연스럽게 특정 디자인 패턴을 유도한다.
이미 검증된 프레임워크를 사용함으로써 품질, 예산, 유지보수에 이점이 있다.
소프트웨어 아키텍처(Architecture)
다수의 프레임워크를 체계적으로 구성, 설명하는 구조체를 말한다.
컴포넌트(Component)
모듈의 형태로 재사용 가능한 확장된 소프트웨어 블럭이다.
컴포넌트 협약에 의한 설계조건(3가지)
선행조건: 컴포넌트 오퍼레이션 사용 전에 참이어야 하는 조건
결과조건: 컴포넌트 오퍼레이션 사용 후에 참이어야 하는 조건
불변조건: 컴포넌트 오퍼레이션 실행 중에 참이어야 하는 조건
재사용 가능한 소프트웨어 요소
소프트웨어의 부분 또는 전체 영역을 모두 재사용 요소로 볼 수 있다.
소프트웨어 재사용 방법
합성(Composition)중심: 모듈(블록)을 조립하여 소프트웨어를 완성시키는 블록 구성 방식
생성(Generation)중심: 추상적인 명세를 구체화하여 소프트웨어를 완성 시키는 패턴 구성 방식
중요
소프트웨어 개발 수명 주기(SDLC)
소프트웨어 개발 방법론의 바탕이된다.
소프트웨어 개발 과정을 단계별로 구성한 것으로 단계별 산출물이 존재한다.
폭포수(Waterfall) 모델
과거에 가장 폭넓게 사용되던 방식이다.
정해진 단계를 한 번씩만 진행하며 이전 단계로 돌아갈 수 없다.
단계별로 결과물이 명확하게 산출되어야 다음 단계로 넘어가는 방식이다.
제품의 기능 보완이 불가능하므로 매뉴얼 작성이 필수적이다.
계획 -> 요구분석 -> 설계 -> 구현 -> 테스트 -> 유지보수
폭포수의 단점은 문제를 발견해도 되돌릴 수 없다.
프로토타입(Prototype) 모델
폭포수 모델의 단점을 보완한 모델로 시제품(prototype) 을 통해 최종 결과물을 예측할 수 있다.
시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.
시제품은 추후 최종 구현 단계에서 골격으로 사용된다.
요구수집 -> 빠른 설계 -> 시제품 구현 -> 고객평가 -> 시제품 조정 -> 구현
구현전 계속반복한다.
나선형(Spiral) 모델
폭포수 모델과 프로토타입 모델의 장접에 위험 분석기능을 더한 모델이다.
나선을 돌듯이 여러 번의 지속적인 개발과정을 통해 점진적으로 개발하는 것이다.
개발 중 발생할 수 있는 위험을 최소화하는 것이 목적이며 유지보수가 필요없다.
누락 및 추가된 요구사항 반영이 가능하다.
고객 평가 계획및 목표설정
공학적 개발및 검증 위험 분석
중요
애자일 모델
소프트웨어를 사용할 고객과의 소통에 중심을 둔 방법론들의 통칭이다.
짧은 개발 주기를 반복하면서 고객의 피드백을 소프트웨어에 반영한다.
고객과의 소통을 통해 작업의 우선순위를 지정하여 개발을 진행한다.
개발 모델 종류
Scrum, XP, Kanban, crystal, FDD(기능 주도 개발), ASD(적응형 소프트웨어 개발), DSDM(동적 시스템 개발)
절차, 문서, 계획보다 소통, 협업, 변화 대응에 가치를 둔다.
스크럼 모델
스크럼 팀을 구성하여 팀을 중심으로 개발의 효율성을 높이는 개발 모델이다.
제품 책임자와 스크럼 마스터, 개발팀으로 구성된다.
반복적인 스프린트를 통해 제품을 완성시켜 나간다.
스프린트(sprint): 2 ~ 4주 정도의 기간 내에서 하나의 task를 개발하는 과정
테스크(task): 개발 요구사항(사용자 스토리)을 개발자(팀)별로 나눈것
스크럼의 가치: 확약, 전념, 정직, 존중, 용기
제품 책임자(Product Owner)
목표 제품에 대한 책임을 지고 의사를 결정하는 역할을 담당한다.
이해관계자(Stakeholder)들의 의견을 종합하여 요구사항을 백로그에 작성하고 우선순위를 조정한다.
제품 백로그(backlog): 우선 순위에 따라 개발에 필요한 사용자 스토리를 나열한 목록
스프린트 백로그: 해당 스프린트에서 개발해야 할 태스크를 나열한 목록
사용자 스토리: 사용자 요구사항을 단어의 나열이 아닌 이야기(시나리오)의 형태로 표현한것
릴리즈 계획: 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 개발일정 수립
팀원들은 백로그에 스토리 추가만 가능하고 우선수위 조정은 불가능한다.
스크럼 마스터(Scrum master)
개발팀원들의 원활한 업무를 위한 가이드 역할을 담당한다.
일일 스크럼 회의를 주관할 수 있으며 개발 과정에서 발생된 장애 요소를 공론화하여 해결할 수 있도록 처리한다.
스크럼 마스터의 역할은 팀원들이 상황에 유연하게 대응할 수 있도록 조력하는 역할이며 통제의 권한은 없다.
개발팀(Development Team)
제품 책임자와 스크럼 마스터 제외한 모든 개발에 참여하는 인원들이다.
개발팀에는 개발자뿐 아니라 디자이너와 테스터 등도 포함된다.
개발팀원들은 능동적으로 팀을 구성하고 문제를 해결할 수 있어야 한다.
스크럼 모델 개발 프로세스
1차 스프린트
스프린트 계획 회의 -> 스프린트 진행 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 산출물
스프린트 검토 회의 -> 스프린트 회고 -> 2차 스프린트
2차 스프린트
스프린트 계획 회의 -> 스프린트 진행 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 산출물
스프린트 검토 회의 -> 스프린트 회고 -> 3차 스프린트
3차 스프린트
스프린트 계획 회의 -> 스프린트 진행 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 산출물
스프린트 검토 회의 -> 스프린트 회고
XP(eXtreme Programming) 모델
XP 모델 특징
고객의 참여와 짧은 개발 과정의 반복을 극대화하여 개발 생산성을 높이는 개발 모델이다.
소규모 인원으로 진행하는 프로젝트에 효과적이며 단계별 단순한 설계를 통해 개발 속도를 향상시킨다.
XP의 가치
의사소통, 단순성, 용기, 존중, 피드백
XP모델 개발 프로세스
사용자 스토리에 기록된 내용을 바탕으로 릴리즈 계획을 수립하고 분석된 스토리에 따라 스파이크 또는 이터레이션을 진행한다.
소규모 릴리즈: 기능별로 고객의 피드백을 받을 수 있도록 릴리즈의 규모를 작게 분할한다.
스파이크: 특정 기술의 확인을 위해 다른 모든 조건을 무시하고 간단하게 개발하는 프로그램
이터레이션: 하나의 릴리즈를 1 ~ 3주의 개발 기간으로 세분화한 단위
스파이크를 통해 기술이 검증되면 해당 부분을 이터레이션으로 전달한다.
이터레이션 진행 도중에서 새로운 스토리가 작성될 수 있다.
이터레이션을 통해 부분 완료된 제품을 고객이 직접 사용자 스토리에 포함된 테스트 사항을 통해 승인 검사를 수행한다.
테스트 과정에서 새로운 요구사항, 오류 등이 발견되면 다음 이터레이션에 반영한다.
XP의 기본 원리(12가지)
Planning Game: 게임처럼 선수, 규칙, 목표 등을 설정하여 계획 수립
Small releases: 짧은 주기의 릴리즈로 고객의 피드백 최대화
System Metaphor: 개발고정에서 최종 목표 시스템의 구조를 조망
Simple Design: 가능한 가장 단순한 설계
Test Driven Development: 우선 단위 테스트 이후 실제 코드 작성
Design Improvement: 기능을 유지하면서 코드 개선 작업 수행
Pair Programming: 2명의 개발자가 코딩, 리뷰 공동 수행
Collective Ownership: 시스템의 코드는 언제나 개발자 누구나 수정 가능
Continuous Integration: 항상 빌드 및 배포가 가능한 상태유지
Sustainable Pace: 주당 일정 시간 이상을 일하지 않도록 오버타임 지양
Whole team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴
Coding Standards: 원할한 의사소통 위해 표준화된 관례에 따라 코드 작성
소프트웨어 개발 방법론
소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법을 말한다.
소프트웨어 개발 방법론의 절차
분석: 개발준비, 시스템 요구 사항 분석, 설계, 구현, 시험으로 나뉜다.
설계: 시스템 설계, 소프트웨어 구조 및 상세 설계
구현: 소프트웨어 코딩 및 단위 시험
시험: 소프트웨어와 시스템 통합 및 테스트, 소프트웨어 설치 및 인수 지원
소프트웨어 개발 방법론 선정
정형화된 소프트웨어 개발 방법론의 특징을 파악한다.
소프트웨어 개발 방법론의 특징을 고려하여 타당성과 적정성을 설정한다.
타당성: 개발 절차에 따라 설정
적정성: 개발 단계별 산출물에 따라 설정
개발 방법론 선정을 위한 계획서를 작성한다.
선정 계획서를 바탕으로 정성, 정량평가를 진행하여 개발 방법론을 선정한다.
소프트웨어 개발 방법론 종류
구조적 방법론
Yourdon에 의해 개발되어 1970년대까지 가장 많이 적용되었던 방법론이다.
구조적 분석을 통해 고객의 요구사항을 자료 흐름도(DFD)로 표현한다.
자료 흐름도(DFD): 프로그램을 기능 단위별 데이터의 흐름으로 표현한 구조도
자료 사전(DD): DFD에 표현된 자료 저장소를 구체화
모듈 중심의 설계를 통해 모듈 간 결합도를 낮춰 독립성을 높인다.
순차, 선택, 반복의 논리 구조 구성으로 프로그램 복잡성을 최소화한다.
요구사항 분석 -> 구조적 분석 -> 구조적 설계 -> 구조적 프로그래밍
정보공학 방법론
1980년대 등장한 방법론으로 개발 단계별 정형화된 기법들을 통합 적용한 데이터 중심 방법론이다.
현행 업무프로세스 및 시스템을 분석하여 정보 전략 계획을 수립한다.
업무 영역을 분석을 통해 개념적인 수준의 데이터와 프로세스를 설계한다.
데이터 모델링 도구: 개체 - 관계 다이어그램(ERD)
프로세스 모델링 도구: 자료 흐름도, 프로세스 의존도(PDD), 프로세스 계층도(PHD)
ERD를 기반으로 분할 다이어그램, 액션 다이어그램, 의존 다이어그램 등을 활용해 실질적인 시스템을 설계한다.
중요
객체지향 방법론
실제(Entity)를 독립된 형태의 객체(Object)로 표현하고, 객체들 간 메시지 교환을 통해 상호작용하도록 프로그램을 개발하는 방법론이다.
속성: 객체를 나타내는 성질, 값, 데이터
메소드: 객체의 속성을 이용한 일련의 동작들
데이터 객체를 저장하기 위해 관계형 데이블(우리가 사용하고있는 표)로 변환하는 과정(Object-Relation Mapping)이 필요하다.
객체지향 방법론의 기본 원칙
캡슐화: 데이터와 해당 데이터의 처리 기능을 하로 묶어냄
정보은닉: 다른 객체에게 자신의 정보를 숨김
추상화: 객체의 공통적인 속성을 상위 객체로 도출
상속성: 상위 객체의 속성을 하위 객체가 물려받아 사용
다형성: 하나의 수행 방법으로 여러 형태의 기능 수행
요구분석 -> 객체지향 분석 -> 객체 지향 설계 -> 객체지향 구현 -> 데이터객체, 기능객체
중요
컴포넌트 기반(CBD: Component Based Develoment) 방법론
컴포넌트들을 조립해서 하나의 새로운 프로그램을 개발하는 방법론이다.
개발 생산성, 이식성 및 호환성, 신속성, 유연성, 표준화 등의 장점이 있다.
일반적으로 프로세스 설계과정에선 객체지향 방법론을, 데이터 설계 과정에선 정보공학 방법론을 사용한다.
선행 투자 비용이 높고, 조립식 시스템에 따르는 책임 및 지적 재산권을 고려해야 한다.
컴포넌트 기반의 단계별 산출물
요구분석 -> 컴포넌트 설계 -> 컴포넌트 검색 -> 컴포넌트 구현 -> 컴포넌트 시험
분석단계: 사용자 요구사항 정의서, 유스케이스 명세서, 요구사항 추적표
설계단계: 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 아키텍처 설계서, 총괄시험 계획서, 시스템시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 단위시험 케이스, 데이터 전환 및 초기 데이터 설계서
구현단계: 프로그램 코드, 단위 시험 결과서, 데이터베이스 테이블
시험단계: 통합시험 결과서, 시스템시험 결과서, 사용자 지침서, 운영자 지침서, 시스템 설치 결과서, 인수시험 시나리오, 인수시험 결과서
애자일 방법론
수시로 변하는 상황과 고객의 요구사항을 바로바로 반영하는 개발하는 방법론이다.
제품 계열 방법론
특정 제품에 적용하고 싶은 공통된 기능을 개발하는 방법론이다.
임베디드 소프트웨어 작성하는 데 유영하며 영역공학과 응용공학으로 구분된다.
영역공학: 영역분석, 영역설계, 핵심 자산을 구현하는 영역
응용공학: 제품요구 분석, 제품 설계, 제품을 구현하는 영역
두 공학을 연계하기 위하 제품 요구사항, 제품 아키텍처, 제품의 조립생산이 필요하다.
소프트웨어 보안 개발 방법론
보안 개발 방법론
소프트웨어의 보안 취약점을 최소화하기 위한 지침 및 사례를 기반으로 개발하는 방법론이다.
시스템 환경에 따라 댜앙한 취약점이 발견되므로 다양한 보안 방법론들이 존재한다.
MS-SDL
마이크로소프트사가 자체적으로 수립한 소프트웨어 개발 모델이다.
Seven Touchpoints
실무적으로 검증된 소프트웨어 보안의 모범사례 8가지를 개발 모델에 통합한 것이다.
코드 검토(code review)
아키텍처 위험 분석(architectural risk analysis)
침투 테스트(penetration testing)
위험 기반 보안 테스트(risk-base security testing)
악용 사례(abuse cases)
보안 요구(security requirement)
보안 운영(security operation)
CLASP(Comprehensive, Lightweight Application Security Process)
소프트웨어 개발 초기 단계의 보안을 강화하기 위한 정형화된 절차이다.
활동 중심, 역할 기반의 프로세스로 구성되어 있으며 이비 운영중인 시스템에 적용하기 좋다.
개념, 역할 기반, 활동 평가, 활동 구현, 취약성의 5가지 관점에 따라 보안 절차를 진행한다.
CWE(Common Weakness Enumeration)
소프트웨어 보안 취약점을 유발하는 원인 7가지로 정리한 보안 개발 방법론이다.
입력 데이터 검증 및 표현: 입력값에 대한 잘못된 검증, 잘못된 형식 지정
보안 기능: 부적절한 보안 기능 구현
시간 및 상태: 병렬 시스템 환경에서 부적절한 시간 및 상태 관리
에러 처리: 에러 처리가 미흡하거나 처리 과정에서 중요 정보 포함
코드 오류: 인가되지 않은 사용자에게 데이터 유출
캡슐화: 중요한 데이터 등을 충분히 캡슐화하지 않아 데이터 누출
API오용: 보안에 취약한 API를 잘못된 방법으로 사용
마무리
처음으로 정보처리기사에대한 정리를 했는데 외워야할 부분이 정말 많은것같다. 아직 시험까지 시간이 있기때문에 천천히 외워보겠다.
