정보처리기사 필기_준비

개미는뚠뚠·2025년 1월 22일
0

정보처리기사

목록 보기
1/1
post-thumbnail

정보처리기사 필기 준비를 위해 기록합니다.
모든 자료는 시나공 공식 유튜브를 참조하였습니다.

System.out.println("2025-01-22 작성")

🍞소프트웨어 생명 주기

소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등 과정을 단계별로 나눈 것

  • 소프트웨어 개발단계와 단계별 주요활동, 그리고 활동의 결과에 대한 산출물로 표현.

  • 소프트웨어 생명 주기를 표현하는 형태는 소프트웨어 생명 주기 모형이라고 하며, 소프트웨어 프로세스 모형 혹은 소프트웨어 공학 패러다임이라고도 함

  • 개발자는 문제의 유형이나 개발 방법 등에 따라 특정 모형을 선택하여 사용할 수 있고, 개별적인 모형을 사용할 수 있다.

  • 일반적으로 사용되는 소프트웨어 생명 주기 모형에는 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등이 있음.

🍞소프트웨어 공학(SE)

소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문을 말하며 여러가지 방법론과 도구, 관리 기법들을 소프트웨어 품질과 생산성을 향상시킬 목적으로 함.

소프트웨어 공학의 형태

  • IEEE의 소프트웨어 공학 표준 용어사전 : 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안

  • Fairley : 지정된 비용과 기간 내에 소프트웨어를 체계적으로 생산하고 유지보수하는데 관련된 기술적이고 관리적인 원리

  • Boehm : 과학적인 지식을 소프트웨어 설계와 제작에 응용하는 것이며 이를 개발, 운용, 유지보수하는데 필요한 문서 작성 과정

소프트웨어 공학 기본 원칙

- 현대적인 프로그래밍 기술을 계속적으로 적용해야함

  • 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야함

  • 소프트웨어 개발 관련 사항 및 결과에 대해 명확한 기록을 유지

🍞소프트웨어 생명 주기 모형

1. 폭포수 모형(선형 순차적 모형)

폭포에서 물이 한번 떨어지면 다시 올라갈 수 없듯이 개발도 이전 단계로 돌아갈 수 없다는 전제로 각 단계를 매듭짓고 그 결과를 검토 및 승인하여 다음 단계를 진행하는 방법론

key

  • 이전단계로 돌아갈 수 없다
  • 가장 오래되고 폭넓게 사용된 전통적인 소프트웨어 생명주기 모형
  • 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출
  • 두 개 이상의 과정이 병행하여 수행되지 않음
  • ex)개발 단계로 넘어갔는데 추가 요구사항을 반영하기 어렵다.

과정

타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현(코딩) -> 시험(검사) -> 유지보수

2. 프로토타입 모형(원형 모형)

사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형

key

  • 폭포수 모형을 보완하기 위한 모형
  • 단기간 제작 목적으로 비효율적인 언어나 알고리즘이 사용될 수 있음
  • 견본(시제)품은 의뢰자나 개발자 모두에게 공동의 참조 모델이 됨
  • 새로운 요구사항이 도출될 때마다 이를 반영한 프로토타입을 새로 만들면서 구현하는 방법

과정

3. 나선형 모형(점진적 모형)

보햄(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점위험분석 기능을 추가한 모형

key

  • 대규모 프로젝트 진행 시 유리
  • 나선을 따라 돌듯이 여러번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것으로, 점진적 모형이라고도 함
  • 개발 과정 중 발생할 수 있는 위험을 관리하고 최소화 하는 것을 목적으로 함
  • 점진적으로 개발과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하여 유지보수 과정이 필요 없음

과정


🍞 애자일 모형

고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행함.

key

- 어느 특정 개발방법론이 아니라 좋은 것을 빠르고, 낭비없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론

  • 스프린트 또는 이터레이션이라고 불리는 짧은 개발주기를 반복
  • 스크럼, XP, 칸반, 크리스탈 등 애자일 모형을 기반으로 하는 소프트웨어 개발 모형들이 있다

과정

애자일 선언

애자일 전문 개발자가 공통의 관점을 정리해 "애자일 SW 개발 선언문"을 만들었다. 선언문에는 애자일 개발 철학이 담겨있는 4가지 핵심 가치와 실무 적용 기준이 되는 12가지 실행지침이 있다.

애자일 개발 4가지 핵심 가치

  1. 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다
  2. 방대한 문서보다는 실행되는 SW에 더 가치를 둔다
  3. 계약 협상보다는 고객과 협업에 더 가치를 둔다.
  4. 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

애자일 개발 12가지 지침

🍞 애자일 모형_스크럼

럭비에서 반칙으로 경기가 중단된 경우 양팀 선수들이 럭비공을 가운데 두고 상대팀을 밀치기 위해 서로 대치해 있는 대형을 말한다. ==> 스크럼은 이처럼 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어

구성

  • 스크럼은 팀원 스스로가 스크럼 팀을 구성해야하며, 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야함.
  • 스크럼 팀은 제품 책임자(PO - 고객과의 소통, 제품에 이해도가 높고 의사 결정할 사람, 백로그 우선순위 지정), 스크럼 마스터(SM - 객관적인 시각에서 조언을 해주는, 팀원을 통제하는 것이 목표가 아닌, 스프린트 계획 회의 주최), 개발팀(DT - 제품책임자와 스크럼 마스터를 제외한 모든 팀원으로 실제 개발자, 디자이너, 테스터 등 모든 사람이 해당)으로 구성됨.

백로그

  • 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록
  • 개발과정 중 새롭게 도출되는 요구사항으로 인해 지속적으로 업데이트 됨

스프린트 계획 회의

  • 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것
  • 스프린트에서 처리할 요구사항을 개발자들이 나눠서 작업할 수 있도록 태스크(task)라는 작업 단위로 분할한 후 개발자별로 수행할 작업 목록인 스프린트 백로그를 작성함

스프린트

  • 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간내에서 진행함
  • 스프린트 백로그에 작성된 태스크를 대상으로 개발자에게 할당
  • 개발 담당자에게 할당된 태스크는 보통할일(Todo), 진행중(InProgress), 완료(Done) 상태를 갖는다.

일일 스크럼 회의

  • 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행상황을 점검함
  • 회의는 보통 서서 진행하며, 남은 작업시간은 소멸차트에 표시함.
  • 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와줌

스프린트 검토 회의

  • 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅을 진행함
  • 스프린트의 한 주당 한시간 내에 진행함
  • 제품책임자는 개선할 사항에 대한 피드백을 정리한 후 다음 스프린트에 반영할 수 있도록 제품 백로그를 업데이트함

스프린트 검토 회의

  • 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록함
  • 해당 스프린트가 끝난 시점에서 수행하거나 일정 주기로 수행함.

System.out.println("2025-01-23 작성")

🍞 애자일 모형_XP(eXtreme Programming)

수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

key

  • 소규모 프로젝트에 적합
  • XP는 짧고 반복적인 개발주기, 단순한 설계, 고객의 적극적인 참여
  • 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 가시성을 높임

XP의 5가지 핵심 가치

  1. 의사소통
  2. 단순성
  3. 용기
  4. 존중
  5. 피드백

XP 개발 프로세스

사용자 스토리

  • 고객의 요구사항을 간단히 시나리오로 표현한 것
  • 내용은 기능단위로 구성, 간단한 테스트 사항도 기재

릴리즈 계획 수립

  • 몇개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라 함
  • 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립함

스파이크

  • 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
  • 처리할 문제 외 다른 조건은 모두 무시하고 작성

이터레이션

  • 하나의 릴리즈를 더 세분화한 단위
  • 일반적으로 1~3주 정도의 기간으로 진행
  • 이 기간 중 새로운 스토리가 작성될 수 있으며, 작성된 스토리는 진행 중인 이터레이션 혹은 다음 이터레이션에 포함될 수 있음

승인 검사

  • 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트
  • 사용자 스토리 작성 시 함께 기재한 테스트 사항에 대해 고객이 직접 수행함
  • 테스트 과정에서 발견한 오류사항은 다음 이터레이션에 포함
  • 테스트 이후 새로운 요구사항이 작성되거나 요구사항의 상대적 우선순위가 변경될 수 있음
  • 테스트가 완료되면 다음 이터레이션을 진행함.

소규모 릴리즈

  • 릴리즈를 소규모로 하게 되면 고객의 반응을 기능별로 확인할 수 있어 고객의 요구사항에 좀 더 유연하게 대응할 수 있음.
  • 이터레이션이 모두 완료되면 고객에 의한 최종 테스트를 수행한 후, 최종 결과물을 고객에게 전달
  • 릴리즈가 최종 완성품이 아닌 경우 다음 릴리즈 일정에 맞게 개발을 진행함.

XP 기법


System.out.println("2025-02-02 작성")

🍞 현행 시스템 파악 절차

새로 개발하려는 시스템의 개발 범위를 명확히 설정하기 위해 현행 시스템의 구성과 기능, 시스템 간의 전달 정보, 사용되는 기술 요소, SW/HW 그리고 네트워크 구성 등을 파악함

단계별 시스템 파악 절차

구기인...(알)아소...하네... 로 외우면 편함
[내가 적은 거 아님....시나공이 그랬음]

1단계_시스템 구성 파악

  • 주요업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술함
  • 조직 내 모든 정보시스템 현황을 파악할 수 있도록 각 업무에 속하는 단위 업무 정보 시스템들의 명칭, 주요 기능들을 명시
  • ex) 금융기관의 여신과리 업무와 고객관리 업무시스템 현황

1단계_시스템 기능 파악

  • 현행 시스템의 기능은 단위업무 시스템이 제공하는 기능들을 주요기능, 하부기능, 세부기능으로 구분하여 계층형으로 표시함
  • ex) 여신상담 관리 시스템의 주요기능과 하부, 세부 기능

1단계_시스템 인터페이스 파악

  • 현행 시스템 인터페이스에는 단위 업무 시스템 간에 주고 받는 데이터 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시함.
  • ex) 여신상담 관리 시스템의 인터페이스 현황

2단계_아키텍처 구성 파악

  • 현행 시스템의 아키텍쳐 구성은 업무 수행 간 어떤 기술 요소들이 사용되는지, 최상위 수준에서 계층별로 표현한 아키텍쳐 구성도로 작성함.
  • 업무별로 다른 경우 가장 핵심이 되는 기간 업무 처리 시스템을 기준으로 표현
  • ex) 회원 정보 관리 시스템 아키텍쳐 구성도

2단계_소프트웨어 구성 파악

  • 단위 업무 시스템별로 업무처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이센스 적용 방식, 라이센스 수 등을 명시함
  • 시스템 구축 비용이 적지 않은 비중을 차지하므로, 상용 소프트웨어의 경우 라이센스 파악이 중요
  • ex) 단위 업무 시스템별 소프트웨어 현황

3단계_하드웨어 구성 파악

  • 단위 업무 시스템들이 운영되는 서버의 주요 사양, 수량, 이중화의 적용 여부를 명시함
  • 서버 이중화는 기간 업무의 서비스 기간 및 장애 대응 정책에 따라 필요여부가 결정됨
  • 서버 이중화로 인한 비용 증가와 시스템 구축 난이도가 높아질 가능성을 고려해야함
  • ex) 단위 업무 시스템별 하드웨어 현황

3단계_네트워크 구성 파악

  • 업무시스템들의 네트워크 구성을 파악할 수 있도록 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성함.
  • 네트워크 구성도를 통해 서버들의 물리적인 위치 관계를 파악할 수 있고, 보안취약성을 분석하여 적절한 대응을 할 수 있음.
  • 네트워크에 장애가 발생한 경우 발생원인을 찾아 복구하기 위한 용도로 활용될 수 있음.
  • ex) 네트워크 구성도

🍞 개발 기술 환경 파악

개발하고자 하는 소프트웨어와 관련된 운영체제(OS), DBMS, 미들웨어 등을 선정할 때 고려할 사항을 기술하고, 오픈소스 사용 시 주의 사항을 기재

0개의 댓글