한이아지와 함께하는 정보처리기사 1과목 1번째) 요구사항 설계

내년 3월 정보처리기사 합격을 목표로 열심히 공부하고 있습니다!

여러분들에게도 제가 정리한 자료를 공유하기 위해 글을 쓰려고 합니다!!

저는 중요하다고 생각되는 부분만 정리하기 때문에 저를 100% 신뢰하시면 안됩니다 ㅠㅠ 

우리 다 같이 합격합시다!!!

(☆ 중요도 0.5 / ★ 중요도 1)

---

PART1. 소프트웨어 설계

• Chap01) 요구사항 설계
  • 현행 시스템 분석
  • 요구사항 확인 
  • 분석 모델 확인
• Chap02) 화면설계 
  • UI 요구사항 확인
  • UI 설계
• Chap03) 애플리케이션 설계
  • 공통 모듈 설계
  • 객체지향 설계
• Chap04) 인터페이스 설계
  • 인터페이스 요구사항 확인
  • 인터페이스 대상 식별
  • 인터페이스 상세 설계

---

Chap01) 요구사항 설계

---

1. 현행 시스템 분석

1.1. 소프트웨어 생명주기 모형 (★★)

(1) 폭포수 모형 (Waterfall)

 폭포수 모형은 가장 오랫동안 사용되었던 모형 == 고전적 생명 모형
 한 단계가 끝나야 다음 단계로 넘어가는 순차적 단계로 진행. 따라서 단계 별 결과가 명확

 개발이 시작되면 개발 중간에 요구사항 변경 불가능!  마지막에 결과 테스트

 

 진행 과정 : 타계분설구테보

 타당성 검토 -> 계획 수립 -> 요구 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수 <- 책으로 한번 읽어보세요!

 

(2) 프로토타입 모형 (ProtoType)

 시제품을 만들어 최종 결과물을 예측하는 모형  ※ 개발 시 인터페이스에 중점

 개발 중간에 요구사항 변경이 용이!

 

(3) 나선형 모형 (Spiral)

 폭포수 모형 + 프로토타입 모형 + 위험 분석 기능

 여러번의 반복 작업을 거쳐 점진적으로 개발을 완성해가는 모형 -> 위험을 관리해서 최소화하는 것이 목적

 정밀하고 유지보수가 필요 없는 장점을 지님

 

진행 과정 : 계위개평

계획 및 정의 -> 위험 분석 -> 공학적 개발 -> 고객 평가 <- 책으로 한번 읽어보세요!

 

(4) 애자일 모형 (Agile)

 애자일 모형은 고객의 요구사항에 유연하게 대응 So, 고객과의 소통이 중요

 일정한 주기를 반복하여 개발을 진행 and 요구사항에 우선순위를 부여하여 개발을 진행

 예시) XP / 스크럼 / 칸반 / 크리스탈 / 린

---

1.2. XP 기법 : eXtreme Programming (★)

 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하는 기법

 핵심은 짧고 반복적인 개발주기 + 단순한 설계 + 고객 참여

 

 XP의 5가지 핵심가치 :  용단의피존

 용기 / 단순성 / 의사소통 / 피드백 / 존중

 XP 개발 프로세스 : 스계소이검소
 사용자 스토리 -> 계획 수립 -> 스파이크 -> 이터레이션 -> 승인 검사 -> 소규모 릴리즈

---

1.3. 스크럼 기법 (★☆)

 팀이 중심이 되어 개발의 효율성을 높임 
 팀원 스스로가 '스크럼' 팀을 구성하고 모든 업무를 스스로 해결

 

 스크럼 팀 구성 
 - 제품 책임자 (Product Owner)

   요구 사항을 책임지고 의사 결정하는 사람
   주로 개발 의뢰자나 사용자가 담당

   이해관계자들의 요구사항을 종합하여 요구사항을 작성하는 주체

   요구사항이 담긴 백로그를 작성
     ▶ 백로그 : 모든 요구사항을 우선순위에 따라 작성한 목록

 - 스크럼 마스터 (Scrum Master)

   객관적인 조언을 해주는 역할

   스크럼 회의를 주관하고 진행사항을 점검하며 장애요소 공론화

 

 - 개발팀 (Development Team)

   제품 개발을 참여하는 모든 사람을 다 포함

 스크럼 개발 프로세스 : 백계스일검회

 제품 백로그 -> 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고

---

운영체제 분석 (★★)

운영체제는 사용자가 컴퓨터를 좀 더 쉽게 사용하기 위해 지원하는 소프트웨어

운영체제 시스템 분석 시 고려사항 

 - 품질 측면 : 신뢰도, 성능

 - 지원 측면 : 기술 지원, 주변 기기, 구축 비용

운영체제 종류

 - 컴퓨터 : Windows, UNIX, Linux

 - 모바일 : Android, iOS   

---

네트워크 분석 (★★☆)

네트워크는 노드 간 연결을 사용하여 서로에게 데이터를 교환하는 기술

백본망, 라우터, 스위치, 게이트웨이, 방화벽 등을 대상으로 분석

---

DBMS 분석 (★★)

DBMS는 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램

 

DBMS 현행 시스템 분석 : 가성호기구 (가성비 좋은 호떡 만드는 기구)

가용성, 성능, 상호 호환성, 기술 지원, 구축 비용

비즈니스 융합 분석 (★)

비즈니스 융합은 융합 기술이 제공하는 기회나 융합의 원리를 이용하여 기존 제품을 혁신하기 위한 기업 활동

 

비즈니스 융합 유형 : 고시가공생 (고시라는 아이가 공부해서 유생이 된다)

고객 가치, 시장 유통, 가치 제안, 공급 역량, 생산 방식

WAS 분석 (★)

사용자에 요구에 따라 변하는 동적인 컨텐츠를 만들기 위해 미들웨어

WAS 현행 시스템 분석 : 가성호기구 (가성비 좋은 호떡 만드는 기구)

가용성, 성능, 상호 호환성, 기술 지원, 구축 비용

오픈소스 분석 (★)

누구나 사용할 수 있도록 소스 코드를 무료로 공개한 자료, 라이센스를 만족하는 소프트웨어

 

오픈소스 현행 시스템 분석 : 라수지 (나(라) 수지야)

라이선스의 종류, 사용자의 수, 기술의 지속 가능성

---

2. 요구사항 확인

2.1. 요구분석 기법 (★★★)

요구분석이란?
요구분석은 도출된 요구사항 간 상충을 해결하고 SW의 범위를 파악하여 외부 환경과의 상호작용 분석하는 과정

 

[1] 요구사항의 유형

 - 기능 요구사항 : 어떤 기능 사용하고 어떤 데이터를 저장 or 연산하는 지, 입·출력은 어떻게 되는 지

 - 비기능 요구사항 : 품질이나 제약사항 그리고 성능과 보안 등

 - 사용자 요구사항 : 사용자 관점에서 시스템이 제공해야할 요구사항

 - 시스템 요구사항 : 개발자 관점에서 시스템이 제공해야할 요구사항

 

[2]요구사항 개발 프로세스

 (1) 도출 : 요구사항을 식별하고 이해하는 과정 (인터뷰, 설문, 브레인스토밍, 유스 케이스, 워크샵 등)
      ※브레인 스토밍 : 3인 이상이 자유롭게 아이디어를 산출 ※ 유스케이스 : 사용자의 요구사항을 기능 단위로 표현 

 (2) 분석 : 명확하지 않거나 모호한 부분들을 찾아내고 걸러내는 과정

 (3) 명세 : 요구사항을 분석한 후 승인될 수 있도록 문서화하는 과정

     (이 때 비기능적 요구사항은 필요한 부분만, 기능적 요구사항은 전부)

 (4) 확인 : 요구사항 명세서가 정확하고 완전한 지 분석하고 검토

 

[3]요구분석 기법 : 분모할협정

요구사항 분류 -> 개념 모델링 생성 및 분석 -> 요구사항 할당 -> 요구사항 협상 -> 정형 분석

 

[4]요구사항 분석기술 : 청인분중관작조모

청취, 인터뷰와 질문, 분석, 중재, 관찰, 작성, 조작, 모델 작성

 

[5] 요구사항 분석에 사용하는 기능 모델링 기법

 

데이터 흐름도(DFD) : 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림 

시스템 분석과 설계에서 매우 유용하게 사용되는 다이어그램

구조적 분석에 사용되고 데이터의 흐름에 중심을 두는 반면 제어의 흐름에는 중심을 두지 않음

출처 : https://sparxsystems.com/enterprise_architect_user_guide/14.0/guidebooks/tech_data_flow_diagrams.html

 

자료 사전 : 자료와 관련된 사항들을 구체적으로 명시하는 사전

 

자료 사전 원칙

 - 자료의 의미는 주석을 통해서 기술, 대상 시스텡메서 사용되는 적합한 뜻을 사용

 - 자료 구성항목들을 그룹으로 묶음, 그룹에 대하여 의미 있는 이름 부여

 - 동의어 규정을 준수

 - 자료 정의의 중복 제거

 

자료 사전 기호

https://colomy.tistory.com/122

2.2. UML (★★★)

UML이란?

UML은 시스템 개발자와 고객 또는 개발자 간의 의사소통이 원할하게 이루어지도록 표준화한 객체지향 모델링 언어

 

[1] UML 구성요소 : 사관다

사물, 관계, 다이어그램

 

[2] 사물 : 모델을 구성하는 가장 중요한 요소

 

사물 구성요소 : 구행그주

 - 구조 사물 : 개념적 그리고 물리적 요소 표현 (클래스, 유스케이스, 컴포넌트, 코드 등)

 - 행동 사물 : 시간과 공간에 따른 요소들의 행위 표현 (상호작용, 상태 머신 등)

 - 그룹 사물 : 요소들의 그룹으로 묶어서 표현 (패키지)

 - 주해 사물 : 부가적인 설명이나 제약조건 표현 (노트)

 

[3] 관계 : 사물과 사물 사이의 연관성을 표현

 

관계 구성요소 : 연집포일의실

 - 연관 관계 : 2개 이상의 사물이 서로 관련되어 있음을 표현

 - 집합 관계 : 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현

 - 포함 관계 : 집합 관계의 특수한 형태로 포함되는 사물의 변화가 포함하는 사물에게 영향을 미치는 관계를 표현

 - 의존 관계 : 사물 사이에 연관은 있으나 필요에 의해서 서로에게 영향을 주는 짧은 시간 동안만 유지되는 관계를 표현

 - 일반화 관계 : 하나의 사물이 다른 사물에 비해 일반적인지 구체적인지 표현

 - 실체화 관계 : 사물이 할 수 있거나 해야 하는 기능으로 서로를 그룹화할 수 있는 관계를 표현

 

[4] 다이어그램  : 사물과 관계를 도형으로 표현한 것

 

구조적 다이어그램 : 클객컴배복패

 - 클래스 : 클래스 사이의 관계 표현, 시스템 내 클래스의 정적 구조를 표현, 속성과 동작으로 구성

 - 객체 : 클래스에 속한 사물들 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현

 - 컴포넌트 : 컴포넌트 간의 관계와 인터페이스, 코드 컴포넌트 기반의 물리적 구조 표현 (구현 단계)

 - 배치 : 노드와 의사소통 경로의 위치 표현, 컴포넌트 사이의 종속성을 표현 (구현 단계)

 - 복합체 구조 : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현

 - 패키지 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

 

행위적 다이어그램 : 유시커상활타

 - 유스케이스 : 사용자 관점에서 시스템의 활동을 표현

 - 시퀀스 : 객체 간 상호작용을 메시지로 표현

 - 커뮤니케이션 : 객체 간 상호작용을 메시지뿐만 아니라 객체 간의 연관 관계까지 표현

 - 상태 : 상호 작용에 따른 상태변화 표현

 - 활동 : 객체의 처리 로직이나 조건에 따른 처리의 흐름으로 순서대로 표현

 - 타이밍 : 객체 상태 변화와 시간 제약을 명시적으로 표현