cyphen156
정보처리기사-소프트웨어 설계/요구사항 분석 본문
정보처리기사 1과목은 소프트웨어 설계에 있어서 공학적인 내용을 다룬다. 이전에 학교에서 학습했던 소프트웨어공학, 프로젝트 설계 실습과목과 연계하여 학습하여 굵직한 내용들은 이해하는 것이 편했다.
모든 내용을 서술하지 않고 필요하다 싶은 부분만 간략하게 서술합니다.
1. 소프트웨어 생명 주기
소프트웨어는 영원하지 않다.
필요에 따라 새로 만들고 사라지며 오류가 발생하면 수정하는 과정이 반복되는데 이것을 소프트웨어의 생명 주기라고 한다.
개발 프로세스 모델
소프트웨어의 개발 과정에 있어 공학적인 특징에 따라 분류한 다양한 과정들
- 폭포수 모형 : 각 개발 과정을 확실하게 매듭짓고 다음단계로 나아가는 절차적, 고전적 방법론, 가장 오래된 설계 모형, 매뉴얼 작성이 필요하다.
- 프로토타입 모형 : 사용자의 요구사항을 일부 반영하여 견본품을 기준으로 최종 결과물을 예측하는 방법론, 견본을 통해 설계 오류와 요구 변경을 빠르게 잡아낼 수 있다.
- 나선형 모형 : Boehm이 제안한 폭포수와 프로토타입의 장점을 합쳐 위험 분석을 추가한 모형, 엄격한 관리가 필요한 프로그램의 설계(Mission Critical)시 사용, 설계가 가장 자세하며 개발 시간이 가장 길다.
- 애자일 모형 : 사용자와 개발자 사이의 소통을 중요시하며 빠른 의견교환을 통해 실시간으로 요구사항의 변경을 개발프로세스에 반영한 모델. 민첩한(Agile) 특징이 있다. 현대 개발 프로세스의 중심이 되어가고 있다.
- 익스트림 프로그래밍(eXtream Programming), 스크럼(Scrum), 기능중심개발(Feature Driven Dev), 칸반, DSDM, DAD등의 개발 방법이 있다.
2. 스크럼(Scrum)
팀이 중심이 되어 개발 효율성을 높이는 애자일 방법론
프로젝트 팀에는 제품 책임자(Product Owner), 스크럼 마스터와 개발 팀이 있다.
- 제품 책임자(PO) : 제품 개발에 있어 요구사항을 책임지고 의사를 결정할 책임자. 주로 사용자가 담당한다.
요구사항이 담긴 백로그를 작성하고 우선순위를 지정한다. - 스크럼 마스터 : 스크럼이 잘 수행될 수 있도록 객관적 시각에서 조언을 해줄 팀장의 역할이 아닌 일종의 가이드, 일일 회의를 주관하여 진행사항을 점검, 장애 요소를 공론화하여 처리한다.
- 개발팀 : 스크럼 마스터와 제품 책임자를 제외한 모든 팀원, 제품 개발을 위해 참여하는 모든 인원을 통칭한다.
개발 프로세스
- 백로그 : 제품 개발에 필요한 요구사항을 우선순위에 따라 나열한 목록
- 스프린트 계획 : 백로그를 분석하여 요구사항 단위로 처리할 작업을 분할하는 것,
분석된 요구사항을 개발자가 나눠서 작업할 수 있도록 스프린트 백로그(Task 작성)로 작성한다 - 스프린트 : 실제 개발을 진행하는 과정, 각 개발자는 스프린트 백로그를 선택하여 작업하고 일일 스크럼 회의에서 태스크 경과를 보고한다.
- 일일 스크럼 회의 : 제픔의 개발 과정을 파악하고 장애 요소를 제거하기 위해 매일 수행하는 짧은 회의
- 검토 : 부분 또는 전체 완성 제품이 요구사항에 부합하는지 사용자를 포함하여 테스팅을 수행하는 과정 한 주에 한번정도 한다.
- 회고 : 스프린트 주기를 되돌아보며 개선할 점을 찾아 다음 스프린트에 반영한다.
3. 익스트림 프로그래밍(eXtream Programming)
고객과의 소통을 극대화 시킨 개발 프로세스
스크럼 기법보다 훨씬 짧고 간결하게 개발 주기가 반복된다.
핵심 5원칙
- 의사소통
- 단순성
- 용기
- 존중
- 피드백
XP 개발 프로세스
- 사용자 스토리 : 요구사항을 간단한 시나리오로 표현한 것
- 릴리즈 계획 : 스토리를 통해 개발된 기능을 추가하여 제품을 제공하는 것
- 스파이크 : 요구사항에 대한 신뢰성을 높이고 기술 문제의 위험을 감소시키기 위한 프로토타이핑 프로그램
- 이터레이션 : 릴리즈를 더 세분화한 단위, 스크럼의 테스크에 대응됨
- 승인검사(인수테스트) : 각 이터레이션이 개발 완료되엇을때 수행되는 테스팅 기법
XP 주요 실천 방법
- 페어 프로그래밍 : 두 사람 이상이 하나의 기능 개발에 대해 짝을 이루어 기능개발-테스팅을 검증하는 방법
- 공동 코드 소유 : 개발 코드에 대해 권한과 책임을 공동으로 소유하여 좀 더 책임감 있는 기능을 개발하는 방법
- 테스트 주도 개발 : 실제 코드 작성 전 테스트 케이스를 생각하고 테스트를 자동화 할수 있도록 하는것
블로그 주인장 의견- TDD는 그렇다 쳐도 테스트 코드 작성은 쓰레기라고 생각한다.
- 기능 개발을 해놓고 테스트를 위한 코드를 왜 또 짜나? 디버깅을 그렇게 하기 싫은가?
- 프로그램 버그를 찾기 위해 테스트를 진행하는 것은 당연한 것이고, 이후 발생하는 버그 수정은 사용자가 개발자가 예측하지 못한 행동을 했을 때 이에 대한 대응책을 작성하는것이라 생각한다.
- 솔직하게 TDD라는 기법이라는것 자체를 따로 생각해야 된다는 것이 마구잡이로 예외처리를 남발하는 개발자의 무책임성에서 비롯된 문제라고 생각한다.
- 전체 팀 : 개발 구성원이 모두 역할에 대한 책임감을 가져야 한다는 것
- 계속적인 통합 : 모듈 단위로 개발된 코드들이 작업이 마무리 될 때 마다 지속적으로 하나의 프로그램으로 합쳐지는 것
- 디자인 개선/리팩토링 : 유지 보수를 위해 끊임없이 시스템/코드를 재구성하는 것
- 소규모 릴리즈 : 짧은 릴리즈 주기를 통해 변경사항을 적용하고, 오류를 최소화하며 고객의 변경 요구에 신속하게 대응하는것
4. 현행 시스템 파악
- 시스템 파악
- 구성 : 시스템의 명칭, 주요 기능들을 명시
- 기능 : 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시
- 인터페이스 : 데이터 종류와 형식, 프로토콜과 연계 유형, 주기 등을 표시한다.
- 아키텍처 및 소프트웨어 구성 파악
- 아키텍처 구성 파악 : 가장 핵심이 업무를 기준으로 어떤 기술 요소들이 사용되는지 계층별로 표현
- 소프트웨어 구성 파악 : 설치되어 있는 소프트웨어들의 제품, 용도, 라이센스 적용 방식, 라이센스 수 등을 명시
- 하드웨어 및 네트워크 구성 파악
- 하드웨어 구성 파악 : 서버의 주요 사양과 수량, 이중화 적용 여부를 명시
- 네트워크 구성 파악 : 서버의 물리적 위치, 연결 방식 등을 네트워크 구성도 작성
5. 개발 기술 환경 파악
개발 기술 환경을 파악할 때 가용성, 성능, 기술 지원, 주변 기기, 상호 호환성, 구축 비용 등을 고려해야 한다
운영체제, DMBS, 웹 애플리케이션 서버(WAS), 오픈 소스 사용시 고려사항은 기술하지 않습니다. 대강 문제 풀어보는게 훨씬 빠릅니다.
6. 요구사항 정의
소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다.
요구사항의 유형
- 기능 요구사항 : 시스템이 무엇을 하는지, 어떤 기능을 하는지 수행해야 하는 일에 대한 내용
- 비기능 요구사항 : 시스템이 기능을 수행하기 위해 필요한 요구사항들
- 사용자 요구사항 : 사용자 관점에서 시스템이 제공해야 할 기능들
- 시스템 요구사항 : 개발자 관점에서 본 시스템의 전반적인 기능들 / 소프트웨어 요구사항
요구사항 개발 프로세스
도출 - 분석 - 명세 - 확인의 순으로 진행한다.
- 도출 : 시스템 개발에 관련된 사람들이 의견을 교환하는 의사소통 단계
- 분석 : 사용자의 요구사항 중 명확하지 않거나 모호한 표현을 걸러내는 과정
- 명세 : 분석을 바탕으로 모델을 작성화하고 문서를 작성하는 과정
- 정형명세서 : 수학적 원리, 모델에 기반한 명세서
- 비정형명세서 : 상태, 기능, 객체 중심의 명세서, 자연어를 기반으로 서술 또는 다이어그램 작성
- 확인 : 명세가 정확하고 안전하게 작성되었는지 확인하는 과정
7. 요구사항 분석
- 구조적 분석 기법 : 자료의 흐름과 처리를 중심으로 하는 분석 방법
- 자료 흐름도(Data Flow Diagram) : 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
- 프로세스(처리)
- 자료 흐름
- 자료저장소
- 단말
- 자료 사전 : 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
8. 요구사항 분석 CASE와 HIPO
대충 이런거 있다만 알고 갑시다. 그냥 나오면 틀려도되요
- CASE(자동화 도구)
- SADT : SoftTech에서 개발한 구조화된 블록 다이어그램 분석 & 설계 기술
- SREM : TRW가 개발한 소프트웨어 요구 공학 방법론
- RSL : SREM에서 사용되는 요구사항 기술 언어
- REVS : RSL을 자동으로 분석하여 명세서를 출력하는 분석기
- PSL/PSA : 미시간 대학에서 개발한 PSL(문제 기술 언어)을 사용해 요구사항을 분석하는 분석기
- TAGS : 통합 자동화 도구
- HIPO : 시스템의 실행 과정인 입력-처리-출력의 기능을 나타내는 하향식 분석 & 설계기법
- 도식 목차(가시적 도표) : 시스템의 전체적인 기능과 흐름을 보여주는 계층 구조표
- 총체적 도표 : 프로그램을 구성하는 기능을 기술한 것
- 세부적 도표 : 총체적 도표의 기능들을 좀 더 세분화하여 기술한 것
9. UML(Unified Modeling Language)
객체 지향 설계를 잘 설명할 수 있기 때문에 자주 사용된다. 꼭 알고가자
예시프로그램으로는 starUML이 있다.
OMG에서 표준으로 지정한 시스템 분석 & 설계를 위해 널리 사용되는 객체지향 모델링 언어
사물, 관계, 다이어그램 등이 있다.
- 사물 : 모델을 구성하는 기본요소, 관계를 형성할 수 있다.
- 구조 사물 : 시스템의 개념적, 물리적 요소를 표현(클래스, 유스케이스, 컴포넌트, 노드 등)
- 행동 사물 : 시간과 공간에 따른 요소들의 행위를 표현(상호작용, 상태 머신 등)
- 그룹 사물 : 요소들을 그룹으로 묶어서 표현(패키지)
- 주해 사물 : 부연설명이나 제약 조건을 표현(노트)
- 관계 : 사물과 사물 사이의 연관성을 표현한 것
- 연관 관계 : 2개 이상의 사물이 서로 관련이 있음, 다중도를 통해 표현한다.
- 집합 관계 : 하나의 사물이 다른 사물에 포함된 관계
- 포함 관계 : 특수한 집합 관계, 한쪽이 종속성을 갖는다
- 일반화 관계 : 사물을 추상화 한것,
- 의존 관계 : 서로 연관은 있으나 필요에 따라 짧은 주기만 연관을 유지하는 관계, 단어때문에 포함관계와 헷갈리기 쉽다. 좀 더 자세히 설명하자면 포함관계는 한쪽이 없으면 아예 다른 한쪽이 존재할 수 없지만, 의존관계는 연관된 기능을 못쓰는것이지 존재는 할 수 있다.(매개 변수의 예)
- 실체화 관계 : 추상화된 사물을 구체화 한것
- 다이어그램 : 사물과 관계를 도형으로 표현한 것
- 구조적(정적) 다이어그램 : 클래스/객체/컴포넌트/배치/복합체 구조/패키지 다이어그램이 있다.
- 행위(동적) 다이어그램 : 순차/의사소통/상태(이벤트를 통해 상호작용/state는 지역변수)/활동/상호작용 개요/타이밍 다이어그램이 있다.
- 스테레오 타입 : 기본기능 외에 추가 기능을 표현하기 위해 사용된다
<< include / extend / interface / exception / constructor >>
10. 주요 UML 다이어그램
유스케이스 : 사용자 관점에서 객체의 관계를 정리한 다이어그램
시스템-액터-유스케이스/관계 로 구성된다.
클래스 : 시스템을 구성하는 클래스의 관점에서 객체의 관계를 정리한 다이어그램
클래스, 제약조건, 관계로 구성된다.
순차 다이어그램 : 시스템이나 객체들이 메세지를 주고받으며 시간의 흐름에 따라 상호작용한 것을 나타낸 다이어그램
액터 - 객체, 생명선, 실행상자, 메세지, 회귀 메세지, 제어블록으로 구성된다.
저는 상태 다이어그램과 클래스 다이어그램만 그려봤습니다.
어우 많다;;;
본 글은 길벗 시나공 유튜브영상과 기본서를 바탕으로 공부한 내용으로 작성되었습니다.
책정보, 2024 시나공 정보처리기사 필기 기본서 : 길벗, 이지톡 (gilbut.co.kr)
2024 시나공 정보처리기사 필기 기본서
[기출문제집 + 동영상 강의]
www.gilbut.co.kr