정보처리기사 1과목 정리 (1)

1. 소프트웨어 설계

A. 요구사항 확인

① 소프트웨어 생명 주기 :

고객의 요구사항을 좀 더 완벽하게 만족시키기 위해 발전된 형태

• 폭포수 모델(Waterfall Model)
  폭포처럼 이전 단계로 돌아갈 수 없는 모델
  👉 각 단계를 확실히 매듭을 지어야함, 2개 이상의 과정을 병행할 수 없음
  개발의 방향을 바꿀 수 없기 때문에 초기에 계획된 그대로 프로그램을 사용해야 함
  ⭐ 개발 완료 후 발견된 오류 해결이 불가해 매뉴얼 작성 필요
  
  

• 프로토타입 모델(원형모델, Prototype Model)
  프로토타입 : 시제품 or 견본, 빠른 마감을 위해 기능적인 부분만 개발(인터페이스 중심으로 개발)
  프로토타입을 만들어서 문제점을 파악하고, 고객평가 후 이를 기초로 조정하여 완전한 소프트웨어를 개발하는 형태
  👉 폭포수 모델의 단점이 보완된 형태
  
  

• 나선형 모형(스파이럴 모델, Spiral Model)
  대규모 소프트웨어의 개발
  계획-분석-개발-평가의 반복, 여러번의 개발 과정을 거침
  ⭐ 유지보수를 할 필요가 없는 수준까지 완성도를 높이는게 목적(점진적 개발),위험관리하고 최소화하는게 목적
  
  

• 애자일 모델
  절차와 문서보다는 고객과의 상호작용과 협업에 중점
  변화에 빠르게 반응할 수 있도록 개발의 방향을 잡음
  여러 개발 방법을 아우루는 모델
  
  
  

② 스크럼기법 :

애자일 모델 중 하나

스크럼은 팀 중심으로 진행

• 제품책임자(PO) : 의사결정권이 있는 사람
• 스크럼 마스터(SM) : 개발팀을 지원,조율하기 위해 존재
• 개발팀(DT) : 디자이너 및 테스터 등을 전부 포함

백로그(Backlog) : 개발에 필요한 요구사항을 우선순위에 따라 모아놓은 목록, 개발자와 사용자들이 이해할 수 있는 형태라 스토리라고도 불림
⭐ 백로그의 우선순위는 제품 책임자에 의해서만 변경될 수 있음

스프린트 : 스크럼 마스터가 계획 회의를 주관, 이를 통해 개발자들은 일을 할당받음
개별 백로그를 스프린트 백로그라고 함 (개발자)

스크럼 마스터와 개발팀은 매일 회의를 열어, 개발팀은 계획에 방해가 되는 요소들을 스크럼 마스터에게 알리고, 스크럼 마스터는 장애요소 해결을 위해 노력, 제품책임자는 매주 검토회의를 통해 필요한 내용을 백로그에 기록

소멸차트 : 일의 진행도를 파악, 예상기간 대비 실제 작업진행량을 비교하여 문제점 파악 (스크럼 마스터) + 마지막으로 개선점을 찾고 지난 일정을 되돌아보는 회고

③ XP 기법 (eXtreme Programming) :

개발주기를 짧고 반복적으로 만들어 고객의 적극적인 참여를 유도
고객은 더 자주 프로그램의 개발과정을 직접 볼 수 있게 됨
👉 가시성 향상

클수록 비용이 많이 들어 주로 소규모 개발에 사용
⭐ 핵심가치 : 피드백,존중,용기,단순,의사소통(피존용단소)

• 사용자 스토리 : 고객의 요구사항

• 릴리즈 : 프로그램을 배포하는 단위, ex) 버전이 릴리즈 단위, 릴리즈 계획수립, 릴리즈 계획 수립(부분과 전체의 개발 일정 수립), 소규모 릴리즈(릴리즈별로 고객의 피드백 확인 가능)

• 스파이크 : 전체기능이 아닌 특정 기능 하나에 대한 테스트를 하기 위해서 작성되는 프로그램

• 이터레이션 :스파이크가 제대로 완성되면, 1-2주의 시간으로 완성가능한 기능을 모아 고객이 직접 평가할 수 있도록 프로그램을 만드는 과정 (릴리즈를 세분화한 단위)

• 고객 : 이터레이션을 통해 부분 소프트웨어가 릴리즈된 것을 보고 승인 검사를 통해 평가 진행

위 과정들이 정상적으로 진행되면, 앞서 계획해두었던 릴리즈 계획대로 소프트웨어 배포
👉 릴리즈 규모가 작을 수록 완성도 높은 소프트웨어 완성

④ 시스템 파악 :

시스템 개발 범위를 명확하게 설정

• 구 : 업무 시스템의 구성 파악, 각 시스템별 기능을 명시, 주요 업무 담당(기간업무), 지원업무 담당(지원업무)
  

• 기 : 시스템별 세부적인 기능 파악, 계층형으로 표시
  

• 인 : 시스템별 인터페이스 파악, 업무 시스템 간에 주고 받는 데이터의 종류 및 형식, 프로토콜 등
  

• 아 : 시스템 아키텍처 파악, 주요 업무를 기준으로 각 시스템이 동작하는 기술요소의 원리를 구성도 형식으로 표현 (계층적)
  

• 소 : 소프트웨어 구성 파악 (소프트웨어의 용도, 라이선스 적용방식, 라이선스 개수 등)
  

• 하 : 하드웨어(서버) 구성 파악, 서버의 주요 사양과 수량, 이중화(복사본, 백업) 적용 여부
  

• 네 : 네트워크 구성 파악, 네트워크의 물리적 위치 구성도로 작성, 물리적 위치 및 보완 취약점 분석에 용이 -> 유지보수 등에 활용
  
  
  

⑤ 개발 기술 환경 파악 :

• 운영체제(Operating System) : 컴퓨터 시스템 자원 관리, 하드웨어 관리, 사용자와 하드웨어 사이의 인터페이스 제공
  ex) 윈도우, 안드로이드, 리눅스, IOS 등
  ⭐ 특별하게 고려할 사항 : 주변기기 지원여부
  
  
• 데이터베이스 관리 시스템(DBMS) : 사용자가 데이터를 좀 더 쉽고 체계적으로 다룰 수 있고 종속성과 중복성을 해결할 수 있게 함, DB에 모든 권한과 책임이 있음
  ex) 오라클, My-SQL, MongDB 등
  ⭐ 특별하게 고려할 사항 : 서버와 크라이언트 상호 호환성, 이중화
  
  
• 웹 어플리케이션 서버(WAS) : 서버와 클라이언트 사이에 작동하여 미들웨어라고 불리기도 함, 동적 콘텐츠 처리를 위한 미들웨어(실시간), 클라이언트는 좀 더 가벼운 로직을 사용할 수 있으며 DB서버와 연동하여 사용
  ex) Tomcat, Websphere 등
  ⭐ 특별하게 고려할 사항 : 다양한 옵션
  
  

⭐ 위에 있는 것 중 하나를 선택하기 위해 고려할 다섯가지 : 가성비기오

• 가용성 : 현재 내가 하고 싶은 작업을 진행할 수 있는지
  

• 성능

• 기술지원 : 개발에 필요한 참고자료, 관련 커뮤니티 등을 아우르는 개념, 해결가능한 루트가 얼마나 풍부한지

• 비용

• 오픈소스 : 오픈의 개념이 라이선스별로 다르기 때문에 정확하게 파악해야 함, 해당 기술이 지속 가능성이 있는지
  
  
  

⑥ 요구사항 정의/분석/확인 :

요구사항 : 원하는 서비스에 대한 설명 및 운영에 필요한 제약조건

• 기능

• 비기능 : 기능에 대한 품질, 제약사항 서술

• 사용자 : 사용자 입장에서 쉬운 표현

• 시스템 : 개발자 입장에서 전문 용어
  
  
  ⭐ 요구사항 개발 프로세스

• 도출 : 요구사항 수집, 이해관계자간의 의사소통 중요
  ex) 인터뷰, 유스케이스, 프로토타이핑 등

• 분석 : 요구사항 분석, 도출된 요구사항의 타당성 조사, 내용정리 (중복제거, 요구사항 통합 등)
  👉 요구사항분석 -> 요구사항 분류 -> 개념 모델링(단순화, 종속성 분석, 다양, UML) -> 요구사항 할당 -> 요구사항 협상(우선순위) -> 정형분석(구문,의미,수학적 기호)

• 명세 : 요구사항 문서화, 개발 승인을 위해 문서화로 빠짐없이 명확하고 이해하기 쉽게 기록

• 확인 : 요구사항 검증, 명세서 검증, 형상관리 수행(작업 결과물 정리와 관리)

  • 요구사항 검토 : 고객대표 포함
  • 프로토타이핑 : 지속적으로 프로토타입 재작성, 사전 피드백 / 프로토타입에만 집중 ,비용부담
  • 모델 검증 : 정적분석(논리적, 실행 X), 요구사항 충족 여부 검증
  • 인수 테스트 : 사용자 입장, 계획 필요

⑦ UML(Unifide Modeling Language) :

원활한 의사소통을 위해 표준화된 모델링 언어
👉 6개의 구조적 다이어그램 : 클래스 - 구조/ 객체 - 관계/ 컴포넌트 - 구현, 인터페이스/ 배치 - 구현,위치/ 복합체 구조 - 내부 구조/ 패키지 - 그룹
👉 7개의 행위 다이어그램 : 유스케이스 - 모델링, 시퀀스 - 메시지, 커뮤니케이션 - 메시지+ 연관관계, 상태 - 상태변화, 활동- 로직 흐름, 상호작용 개요 - 제어 흐름, 타이밍 - 시간제약

• 사물 : 특정 대상, 사물을 기준으로 관계 형성
  👉 구조(요소), 행동(행위), 주해(설명), 그룹(묶음)

• 관계 :
  👉 연관,의존/ 일반화,실체화 구분 : 일시적인가?
  • 연관 (실선 화살표, 다중도) ex. 자동차-타이어
  • 의존 (점선 화살표) ex. 고객등급-사은품
  • 일반화 (여러 사물의 공통적인 상위 개념을 실선 화살표)
  • 실체화 (여러 사물의 공통적인 상위 개념을 점선 화살표)
  • 집합 (전체쪽에 가운데가 비어 있는 마름모)
  • 포함 (전체쪽에 가운데가 채워져 있는 마름모)

• 다이어그램
  

참고한 영상 : 정보처리기사 필기