핵심적인 부분만 요약하였습니다.
◆시스템 소프트웨어
●시스템 소프트웨어의 정의
▷사용자가 손쉽고 효율적으로 컴퓨터 시스템을 사용하도록 돕는 소프트웨어이다
●시스템 정의(기본 요소 포함)
▷컴퓨터 시스템과 같은 의미로 쓰이며, 특정 업무를 수행하기 위해 중앙 처리 장치를 중심으로 구성된 하드웨어 및 소프트웨어의 총칭이다.
▷컴퓨터 시스템은 기본적으로 입력, 처리, 출력, 제어, 피드백의 기능을 수행하기 위한 장치들이 존재한다.
◆소프트웨어 개발 프레임워크
●모듈(Module)
▷프로그램을 기능별로 분할하여 재사용이 가능하게끔 부품화한 것이다.
▷개발자가 프로그램의 기본 틀을 제공하고, 모듈을 활용하여 기능을 구체화한다.
●라이브러리(Library)
▷툴킷이라고도 하며, 관련 있는 모듈들을 모아놓은 것이다.
▷라이브러리에 존재하는 각 모듈이 반드시 독립적인 것은 아니다.
-표준 라이브러리 : 프로그래밍 언어에 내장
-외부 라이브러리 : 별도의 설치를 통해 사용 가능
●디자인 패턴(Design Pattern)
▷특정 기능에 대한 문제해결을 위한 추상적인 가이드라인을 제시한 것이다.
▷프로그램의 세부적인 구현 방안을 위해 참조하는 해결 방식을 제시한것이다.
●소프트웨어 개발 프레임워크(FrameWork)
▷디자인 패턴에 모듈의 장점 및 기능을 결합하여 실제적인 개발의 틀을 제공한다.
▷프레임워크가 프로그램의 기본 틀을 제공하고, 개발자가 기능을 구체화하는 제어의 역 흐름이 발생한다.
▷프로그램의 기반, 구조를 잡아주는 코드의 모임이며 자연스럽게 특정 디자인 패턴을 유도한다.
▷이미 검증된 프레임워크를 사용함으로써 품질, 예산, 유지보수에 이점이 있다
▷프로그램 구성의 복잡도가 감소하여 상호 운용성과 개발 및 변경이 용이해진다.
●소프트웨어 아키텍쳐(Architecture)
▷다수의 프레임 워크를 체계적으로 구성, 설명하는 구조체를 말한다.
▷소프트웨어의 설계와 업그레이드를 통제하는 지침과 원칙을 제공한다.
●컴포넌트(Component)
▷모듈의 형태로 재사용 가능한 확장된 소프트웨어 블럭이다.
▷일반적인 코딩을 벗어나 마치 레고를 쌓아 올리듯이 개발하는 기법을 말한다.
▷프레임워크 및 아키텍쳐가 적용되어 있어 안정적이다.
▷협약에 의한 설계를 따를 경우에 포함되어야 할 조건은 아래와 같다.
-선행조건 : 컴포넌트 오퍼레이션 사용 전에 참이여야 하는 조건
-결과조건 : 컴포넌트 오퍼레이션 사용 후에 참이여야 하는 조건
-불변조건 : 컴포넌트 오퍼레이션 사용 중에 참이여야 하는 조건
◆소프트웨어 개발 수명 주기 (SDLC)
●소프트웨어 개발 수명 주기 정의
▷소프트웨어 개발 과정을 단계별로 구성한 것으로 단계별 산출물이 존재한다,
●폭포수 모델
▷계획 → 요구분석 → 설계 → 구현 → 테스트 → 유지보수
▷정해진 단계를 한 번씩만 진행하며 이전 단계로 돌아갈 수 없다.
▷단계별로 결과물이 명확하게 산출되어야 다음 단계로 넘어가는 방식이다.
●프로토타입 모델
요구수집 → 빠른 설계 → 시제품 구현 → 고객평가(만족시 구현) → 시제품 조정 → 다시 요구수집
▷시제품을 통해 최종 결과물을 예측할 수 있다
▷시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.
▷시제품은 추후 최종 구현 단계에서 골격으로 사용된다.
●나선형 모델
▷폭포수 모델과 프로토타입 모델의 장점에 위험 분석기능을 더한 모델이다.
▷나선을 돌듯이 여러번의 지속적인 개발 과정을 통해 점진적으로 개발하는것이다.
▷개발 중 발행할 수 있는 위험을 최소화하는 것이 목적이며 유지보수가 필요 없다.
▷누락 및 추가된 요구사항 반영이 가능하다.
●애자일 모델
▷소프트웨어를 사용할 고객과의 소통에 중심을 둔 방법론들의 통칭이다.
▷짧은 개발 주기를 반복하면서 고객의 피드백을 소프트웨어에 반영한다.
▷고객과의 소통을 통해 작업의 우선순위를 지정하여 개발을 진행한다.
▷애자일 모델을 기반으로 하는 개발 모델은 Scrum, XP, Kanban, crystal, FDD(기능 주도 개발), ASD(적응형 소프트웨어 개발), DSDM(동적 시스템 개발)등이 있다.
▷절차, 문서, 계획보다 소통 협업, 변화 대응에 가치를 둔다.
◆스크럼 모델
●스크럼 모델 특징
▷스크럼 팀을 구성하여 팀을 중심으로 개발의 효율성을 높이는 개발 모델이다.
▷제품 택임자와 스크럼 마스터, 개발팀으로 구성된다
▷반복적인 스프린트를 통해 제품을 완성시켜 나간다.
- 스프린트(sprint) 2~4주 정도의 기간 내에서 하나의 task를 개발하는 과정
- 태스크(task) : 개발 요구사항(사용자 스토리)을 개발자(팀)별로 나눈 것
▷스크럼의 가치는 확약, 전념, 존중, 용기 등이 있다.
●제품 책임자(Product Owner)
▷목표 제품에 대한 택임을 지고 의사를 결정하는 역할을 담당한다.
●스크럼 마스터(Scrum Master)
▷개발팀원들의 원활한 업무를 위한 가이드 역할을 한다.
▷일일 스크럼 회의를 주관할 수 있으며 개발 과정에서 발생된 장애 요소를 공론화하여 해결할 수 있도록 처리한다.
▷스크럼 마스터의 역할은 팀원들이 상황에 유연하게 대응할 수 있도록 조력하는 역할이며 통제의 권한은 없다.
●개발팀(Development Team)
▷개발에 참여하는 모든 인원이다.
●스크럼 모델 개발 프로세스
스프린트 계획 회의 → 스프린트 진행 → 일일 스크럼 회의 → 스프린트 검토 회의 → 스프린트 회고 : n차 스프린트 시작
ㄴ → 산출물
◆XP(eXtreme Programming) 모델
●XP모델 특징
▷고객의 참여와 짧은 개발 과정의 반복을 극대화하여 개발 생산성을 높이는 개발 모델이다.
▷소규모 인원으로 진행하는 프로젝트에 효과적이며 단계별 단순한 설계를 통해 개발 속도를 향상시킨다.
▷XP의 가치는 의사소통, 단순성, 용기, 존중, 피드백이 있다.
●XP 모델 개발 프로세스
▷사용자 스토리에 기록된 내용을 바탕으로 릴리즈 계획을 수립하고 분석된 스토리에 따라 스파이크 또는 이터레이션을 ▷진행한다.
- 소규모 릴리즈 : 기능별로 고객의 피드백을 받을 수 있도록 릴리즈의 규모를 작게 분할한다.
- 스파이크 : 특정 기술의 확인을 위해 다른 모든 조건을 무시하고 간단하게 개발하는 프로그램
- 이터레이션 : 하나의 릴리즈를 1~3주의 개발 기간으로 세분화한 단위
▷스파이크를 통해 기술이 검증되면 해당 부분을 이터레이션으로 전달한다.
▷이터레이션 진행 도중에서 새로운 스토리가 작성될 수 있다.
▷이터레이션을 통해 부분 완료된 제품을 고객이 직접 사용자 스토리에 포함된 테스트 사항을 통해 승인 검사를 수행한다.
▷테스트 과정에서 새로운 요구사항, 오류 등이 발견되면 다음 이터레이션에 반영한다.
●XP 기본 원리
▷XP의 실천 사항은 12개 사항으로 나뉜다.
| 항목 | 설명 |
| Planning Game | 게임처럼 선수, 구칙, 목표 등을 설정하여 계획 수립 |
| Small Releases | 짧은 주기의 릴리즈로 고객의 피드백 최대화 |
| System Metaphor | 개발 과정에서 최종 목표 시스템의 구조를 조망 |
| Simple Design | 가능한 가장 단순한 설계 |
| Test Driven Developement | 우선 단위 테스트 이후 실제 코드 작성 |
| Design improvement | 기능을 유지하면서 코드 개선 작업 수행 |
| Pair Programming | 2명의 개발자가 코딩, 리뷰 공동 수행 |
| Collective Ownership | 시스템의 코드는 언제나 개발자 누구나 수정 가능 |
| Contiunuous Integration | 항상 빌드 및 배포가 가능한 상태 유지 |
| Sustainable Pace | 주당 일정 시간 이상을 일하지 않도록 오버타임 지양 |
| Whole Team | 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴 |
| Coding Standards | 원활한 의사소통 위해 표준화된 관례에 따라 코드 작성 |
◆소프트웨어 개발 방법론
●소프트웨어 개발 방법론 정의
▷소프트웨어 개발 모든 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법을 말한다.
▷소프트웨어를 개발함에 있어 생산성과 소프트웨어 품질을 향상시킨다.
▷소프트췌어 공학에서 가장 많이 사용하는 방법론이다.
●소프트웨어 개발 방법론의 절차
▷소프트웨어 개발 방법론의 절차는 분석, 설계, 구현, 시험으로 나뉜다.
- 분석 : 개발 준비, 시스템 요구사항 분석, 소프트웨어 요구사항 분석
- 설계 : 시스템 설계, 소프트웨어 구조 및 상세 설계
- 구현 : 소프트웨어 코딩 및 단위 시험
- 시험 : 소프트웨어와 시스템 통합 및 테스트, 소프트웨어 설치 및 인수 지원
●소프트웨어 개발 방법론 선정
▷정형화된 소프트웨어 개발 방법론의 특징을 파악한다.
▷소프트웨어 개발 방법론의 특징을 고려하여 타당성과 적정성을 설정한다.
- 타당성 : 개발 절차에 따라 설정
- 적정성 : 개발 단계별 산출물에 따라 설정
▷개발 방법론 선정을 위한 계획서를 작성한다.
▷선정 계획서를 바탕으로 정성, 정량평가를 진행하여 개발 방법론을 선정한다.
◆소프트웨어 개발 방법론 종류
●구조적 방법론
▷Yourdon에 의해 개발되어 1970년대까지 가장 많이 적용되었던 방법론이다.
▷구조적 분석을 통해 고객의 요구사항을 자료 흐름도(DFD)로 표현하였다.
- 자료 흐름도(DFD) : 프로그램을 기능 단위별 데이터의 흐름으로 표현한 구조도
- 자료 사전(DD) : DFD에 표현된 자료 저장소를 구체화
▷모듈 중심의 설계를 통해 모듈 간 결합도를 낮춰 독립성을 높인다.
▷순차, 선택, 반복의 논리 구조 구성으로 프로그램 복잡성을 최소화한다.
●정보공학 방법론
▷1980년대 등장한 방법론으로 개발 단계별 정형화된 기법들을 통합 적용한 데이터 중심 방법론이다.
▷현행 업무 프로세스 및 시스템을 분석하여 정보 전략 계획을 수립한다.
▷업무 영역 분석을 통해 개념적인 수준의 데이터와 프로세스를 설계한다.
- 데이터 모델링 도구 : 개체-관계 다이어그램(ERD)
- 프로세스 모델링 도구 : 자료 흐름도, 프로세스 의존도(PDD), 프로세스 계층도(PHD)
▷ERD를 기반으로 분할 다이어그램, 액션 다이어그램, 의존 다이어그램 등을 활용해 실질적인 시스템을 설계한다.
정보 전략 계획(Information Strategy Planning)
↓
업무 영역 분석(Business Area Analysis)[데이터, 상관관계(상호작용), 프로세스]
↓
업무 시스템 설계(Business System Design)
↓
업무 시스템 구축(Business System Construction)
●객체지향 방법론
▷실체(Entity)를 독립된 형태으 객체(Object)로 표현하고, 객체들 간 메세지 교환을 통해 상호작용하도록 프로그램을 개발하는 방법론이다.
- 속성 : 객체를 나타내는 성질, 값, 데이터
- 메소드 : 객체의 속성을 이용한 일련의 동작들
▷데이터 객체를 저장하기 위해서 관계형 테이블로 변환하는 과정(Object-Relation Mapping)이 필요하다.
▷객체지향 방법론의 기본 원칙은 캡슐화, 정보은닉, 추상화, 상속성, 다형성이 있다.
- 캡슐화 : 데이터와 해당 데이터의 처리 기능을 하나로 묶어냄
- 정보은닉 : 다른 객체에게 자신의 정보를 숨김
- 추상화 : 객체의 공통적인 속성을 상위 객체로 도출
- 상속성 : 상위 객체의 속성을 하위 객체가 물려받아 사용
- 다형성 : 하나의 수행 방법으로 여러 형태의 기능 수행
●컴포넌트 기반(CBD : Component Based Develoment) 방법론
▷컴포넌트들을 조립해서 하나의 새로운 프로그램을 개발하는 방법론이다.
▷개발 생산성, 이식성 및 호환성, 신속성, 유연성, 표준화 등의 장점이있다.
▷일반적으로 프로세스 설계과정에선 객체지향 방법론을, 데이터 설계 과정에선 정보공학 방법론을 사용한다.
▷선행 투자 비용이 높고, 조립식 시스템에 따르는 책임 및 지적 재산권을 고려해야 한다.
▷컴포넌트 기반의 단계별 산출물은 아래와 같다.
- 분석 단계 : 사용자 요구사항 정의서, 유스케이스 명세서, 요구사항 추적표 등
- 설계 단계 : 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 아키텍처 설계서, 총괄시험 계획서, 시스템시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 단위시험 케이스, 데이터 전환 및 초기 데이터 설계서 등
- 구현 단계 : 프로그램 코드, 단위 시험 결과서, 데이터베이스 테이블
- 시험 단계 : 통합시험 결과서, 시스템 시험 결과서, 사용자 지침서, 운영자 지침서, 시스템 설치 결과서, 인수시험 시나리오, 인수시험 결과서
●애자일 방법론
▷수시로 변하는 상황과 고객의 요구사항을 바로바로 반영하여 개발하는 방법
●제품 계열 방법론
▷특정 제품에 적용하고 싶은 공통된 기능을 개발하는 방법론이다.
▷임베디드 소프트웨어를 작성하는 데 유용하며 영역공학과 응용공학으로 구분된다.
- 영역공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역
- 응용공학 : 제품 요구 분석, 제품 설계, 제품을 구현하는 영역
▷두 공학을 연계하기 위한 제품 요구사항, 제품 아키텍쳐, 제품의 조립생산이 필요하다.
◆소프트웨어 보안 개발 방법론
●보안 개발 방법론 정의
▷소프트웨어의 보안 취약점을 최소화하기 위한 지침 및 사례를 기반으로 개발하는 방법론이다.
▷시스템 환경에 따라 다양한 취약점이 발견되므로 다양한 보안 방법론들이 존재한다.
●MS-SDL
▷마이크로소프트사가 자체적으로 수립한 소프트웨어 개발 모델이다.
●Seven Touchpoints
▷실무적으로 검증된 소프트웨어 보안의 모범 사례 7가지를 개발 모델에 통합한 것이다.
- 코드 검토(code review)
- 아키텍쳐 위험 분석(architectural risk analysis)
- 침투 테스트(penetration testing)
- 위험 기반 보안 테스트(risk-base security testing)
- 악용 사례(abuse cases)
- 보안 요구(security requirement)
- 보안 운영(security operation)
●CLASP(Comperhensive, Lightweight Application Security Process)
▷소프트웨어 개발 초기 단계의 보안을 강화하기 위한 정형화된 절차이다.
▷활동 중심, 역할 기반의 프로세스로 구성되어 있으며 이미 운영중인 시스템에 적용하기 좋다
▷개념, 역할 기반, 활동 평가, 활동 구현, 취약성의 5가지 관점에 따라 보안 절차를 진행한다.
●CEW(Common Weakness Enumeration)
▷소프트웨어 보안 취약점을 유발하는 원인을 7가지로 정리한 보안 개발 방법론이다.
- 입력 데이터 검증 및 표현 : 입력값에 대한 잘못된 검증, 잘못된 형식 지정
- 보안 기능 : 부적절한 보안 기능 구현
- 시간 및 상태 : 병렬 시스템 환경에서 부적절한 시간 및 상태 관리
- 에러 처리 : 에러 처리가 미흡하거나 처리 가정에서 중요 정보 포함
- 코드 오류 : 인가되지 않은 사용자에게 데이터 유출
- 캡슐화 : 중요한 데이터 등을 충분히 캡슐화하지 않아 데이터 누출
- API 오용 : 보안에 취약한 API를 잘못된 방법으로 사용
'정보처리기사 > 정처기 요약' 카테고리의 다른 글
| 23년도 정처기 필기 합격 후기 (0) | 2023.03.06 |
|---|---|
| 정처기 필기 개념 블로그 (0) | 2023.03.04 |