[정보처리기사 실기] 요구사항 및 UML 정리

자격증 준비하면서 내가 이해하기 편하게, 다시 보기 좋게 정리하는 정보처리기사의 내용 (자격증 상세 내용은 아래)

http://www.q-net.or.kr/crf005.do?id=crf00505&gSite=Q&gId= 

http://www.q-net.or.kr/crf005.do?gId=&gSite=Q&id=crf00505

요구사항 및 UML 정리 부분을 정리한 내용

---

소프트웨어 생명 주기

• 소프트웨어를 개발하기 위한 설계, 운용 유지보수 등의 과정을 각 단계별로 나눈 것
• 대표적인 생명 주기 모형 폭포수, 프로토타입, 나선형, 애자일 모형

폭포수 모형

• 고전적 생명 주기 모형이라고도 부름
• 각 단계를 확실히 끝내고 결과를 검토하여 승인 과정을 거친 후 다음 단계를 진행하는 개발 방법론

프로토타입 모형

• 실제 개발될 소프트 웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형
• 사용자와 시스템 사이의 인터페이스에 중점에 두고 개발

나선형 모형

• 보헴이 제안한 모형으로 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 최종 소프트웨어를 개발하는 모형
• 폭포수 모형과 프로토타입 모형의 장점 + 위험 분석 기능
• 계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가 순으로 반복

애자일 모형

• 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
• 대표적으로 스크럼, XP, 칸반, Lean, 기능 중심 개발(FDD)

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

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

소프트웨어 공학

• 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
• 소프트웨어의 품질과 생산성 향상을 목적으로 함

스크럼

팀이 중심이 되어 개발의 효율성을 높이는 기법

• 스크럼팀
  • 제품 책임자(PO) : 요구사항이 담긴 백로그를 작성하는 주체로 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사람으로 선정
  • 스크럼 마스터 : 스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할 수행
  • 개발팀 : 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 제품 개발을 수행

스크럼 개발 프로세스

1. 스프린트 계획 회의 : 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의
2. 스프린트 : 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행
3. 일일 스크럼 회의 : 모든 팀원이 매일 약속된 시간에 진행 상황을 점검하는 회의
4. 스프린트 검토 회의 : 부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅하는 회의
5. 스프린트 회고 : 정해놓은 규칙 준수 여부 및 개선할 점을 확인하고 기록하는 것

XP(eXtreme Programming)

• 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 생산성을 향상하는 방법
• 핵심 가치 : 의사소통, 단순성, 용기, 존중, 피드백

XP 개발 프로세스

1. 릴리즈 계획 수립 : 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립하는 것
2. 이터레이션 : 실제 개발 작업을 진행하는 과정으로, 보통 1~3주 정도의 기간으로 진행
3. 승인 검사 : 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트
4. 소규모 릴리즈 : 요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것

XP의 주요 실천 방법

• 짝 프로그래밍(Pair Programming)
• 공동 소유 코드(Collective Ownership)
• 테스트 주도 개발 (Test-Driven Development)
• 전체 팀 (Whole Team)
• 계속적인 통합 (Continuous Integeration)
• 리팩토링 (Refactoring)
• 소규모 릴리즈(Small Releases)

서버의 이중화

운용 서버에 장애가 발생했을 때 대기 서버에서 서비스를 계속 유지되도록, 운용 서버의 자료 변경이 대기 서버에도 동일하게 복제되도록 관리하는 것

현행 시스템 파악 절차

• 1단계 : 시스템 구성, 시스템 기능, 시스템 인터페이스 파악
• 2단계 : 아키텍처 구성, 소프트웨어 구성 파악
• 3단계 : 하드웨어 구성, 네트워크 구성 파악

운영체제

• 컴퓨터 시스템의 자원을 효율적으로 관리
• 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어
• 가용성, 성능, 기술 지원, 주변 기기, 구축 비용 등 고려

데이터베이스 관리 시스템 (DBMS)

• 사용자와 데이터베이스 사이에서 요구사항에 맞는 정보를 생성
• 데이터베이스를 관리하는 소프트웨어
• 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용 등 고려

웹 애플리케이션 서버(WAS)

• 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
• 가용성, 성능, 기술 지원, 구축 비용 등 고려

오픈 소스

• 누구나 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어
• 라이선스의 종류, 사용자의 수, 기술의 지속 가능성 등 고려

요구사항

소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영하는데 필요한 제약 조건

• 기능 요구사항
  • 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항
  • 사용자가 시스템을 통해 제공받기를 원하는 기능
• 비기능 요구사항
  • 품질이나 제약사항과 관련된 요구사항
  • 시스템 장비 구성, 성능, 인터페이스, 테스트 요구사항 등
  • 품질 요구사항 : 가용성, 정합성, 상호 호환성, 대응성, 이식성, 확장성, 보안성
• 사용자 요구사항
  • 사용자 관점에서 본 시스템이 제공해야 할 요구사항
• 시스템 요구 사항
  • 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항

요구사항 개발 프로세스

도출 → 분석 → 명세 → 확인

• 도출
  • 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 식별하고 이해하는 과정
  • 청취와 인터뷰, 설문, 브레인스토밍, 워크숍, 프로토타이핑, 유스케이스 등의 기법
• 분석
  • 요구사항 중 명확하지 않은 부분을 걸러내는 과정
  • 자료 흐름도(DFD), 자료 사전(DD) 등의 도구 사용
• 명세
  • 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것
  • 기능 요구사항은 빠짐없이, 비기능 요구사항은 필요한 것만 기술
• 확인
  • 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동
  • 이해관게자들이 검토

요구공학

요구사항을 정의하고, 분석 및 관리하는 프로세스를 요구하는 학문

요구사항 분석

개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동

구조적 분석 기법

• 자료의 흐름과 처리를 중심으로 요구하는 분석 기법
• 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Specv.), 개체 관계도(ERD)., 상태 전이도(STD), 제어 명세서 등의 도구 사용

자료 흐름도(DFD)

• 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
• 자료 흐름 그래프, 버블 차트라고도함

자료 사전(DD)

• = : ~로 구성되어 있다
• + : 그리고
• ( ) : 생략 가능한 자료
• [ ] : 또는
• { } : 자료의 반복
• **: 주석

요구사항 분석용 CASE(자동화 도구)

요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구

• SADT : SoftTech 사에서 개발한 것으로 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구
• SREM(RSL/REVS) : TRW 사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 도구
• PSL/PSA : PSL과 PSA를 사용하는 자동화 도구
• TAGS : 시스템 공학 방법 응용에 대한 자동 접근 방법

HIPO(Hierarchy Input Process Output)

• 시스템 실행 과정인 입력, 처리, 출력의 기능을 표현한 것
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 가시적 도표, 총체적 도표, 세부적 도표 등의 종류

UML(Unified Modeling Language)

시스템 개발 과정에서 의사소통이 원활하게 이루어지도록 표준화한 대표적 객체지향 모델링 언어

• 사물 : 다이어그램 안에서 관계가 형성될 수 있는 대상들
  • 구조 사물 : 시스템의 개념적, 물리적 요소를 표현 (클래스, 유스케이스, 컴포넌트, 노드 등)
  • 행동 사물 : 시간과 공간에 따른 요소들의 행위를 표현 (상호작용, 상태머신 등)
  • 그룹 사물 : 요소들을 그룹으로 묶어서 표현 (패키지 등)
  • 주해 사물 : 부가적인 설명이나 제약조건 등을 표현 (노트 등)
• 관계 : 사물과 사물 사이의 연관성을 표현하는 것
  • 연관 관계
    • 2개 이상의 사물이 서로 관련되어 있는 관계
    • 방향성은 화살표로 표현하고, 다중도를 선 위에 표기
    • 1, n, 0.. 1, 0..* 등
  • 집합 관계
    • 하나의 사물이 다른 사물에 포함되어 있는 관계
    • 포함하는 쪽과 포함되는 쪽은 서로 독립적
    • 포함되는 쪽에서 포함하는 쪽으로 빈 마름모로 연결 표현
  • 포함 관계
    • 포함되는 사물의 변화가 포함되는 사물에 영향을 미치는 관계
    • 포함하는 쪽과 포함되는 쪽은 서로 독립될 수 없고 생명 주기를 함께함
    • 포함되는 쪽에서 포함하는 쪽으로 마름모를 연결하여 표현
  • 일반화 관계
    • 하나의 사물이 다른 사물에 비해 더 일관적이거나 구체적인 관계
    • 더 일반적인 개념을 부모, 더 구체적인 개념을 자식이라고 부름
  • 의존 관계
    • 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
    • 하나의 사물과 다른 사물이 소유관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계
  • 실체화 관계
    • 사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화할 수 있는 관계

다이어그램

• 기능 모델링 : 개발될 시스템이 갖춰야 할 기능을 정리한 후 상용자와 공유하기 위해 그림으로 표현하는 것
• 유스케이스 다이어그램
  • 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것
  • 시스템(시스템범위) : 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현한 것
  • 액터 : 시스템과 상호작용을 하는 모든 외부 요소로 주로 사람이나 외부 시스템을 의미
  • 유스 케이스 : 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것
  • 관계 : 액터와 유스케이스, 유스케이스와 유스케이스 사이의 관계
• 활동 다이어그램 : 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
  • 활동다이어그램 구성 요소
    • 액션 : 더 이상 분해 할 수 없는 단일 작업
    • 액티비티 : 몇 개의 액션으로 분리될 수 있는 작업
    • 시작 노드 : 액션이나 액티비티가 시작됨을 표현한 것
    • 종료 노드 : 액티비티 안의 모든 흐름이 종료됨을 표현한 것
    • 조건 노드 : 조건에 따라 제어의 흐름이 분리됨을 표현한 것
    • 병합 노드 : 여러 경로의 흐름이 하나로 합쳐짐을 표현한 것
    • 포크 노드 : 액티비티의 흐름이 분리되어 수행됨을 표현한 것
    • 조인 노드 : 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현한 것
    • 스웜 레인 : 액티비티 수행을 담당하는 주체를 구분하는 선
• 클래스 다이어그램 : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것
  • 정적 모델링
    • 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것
    • 객체들 사이의 연관성을 구조적 관점(view)에서 표현
    • 객체(object)들을 클래스(class)로 추상화하여 표현
  • 클래스 다이어그램 구성요소
    • 클래스 : 각각의 객체들이 갖는 속성과 오퍼레이션을 표현한 것
    • 제약조건 : 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적는 것
    • 관계 : 클래스와 클래스 사이의 연관성을 표현
  • 연관 클래스
    • 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스
• 시퀀스 다이어그램 : 시스템 안 객체들이 메시지를 주고받으며 상호 작용하는 과정을 그림으로 표현한 것
  • 동적 모델링
    • 시스템 내부 구성 요소들의 상태 변환 과정과 과정에서 발생하는 상호 작용을 표현하는 것
    • 시스템 내부 구성 요소들 간에 이루어지는 동작을 관점(view)에서 표현
  • 시퀀스 다이어그램의 구성 요소
    • 액터 : 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미
    • 객체 : 메시지를 주고받는 주체
    • 생명선 : 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현
    • 실행 상자 : 객체가 메시지를 주고받으며 구동되고 있음을 표현
    • 메시지 : 객체가 상호 작용을 위해 주고받는 메시지
    • 객체 소멸 : 해당 객체가 더 이상 메모리에 존재하지 않음을 표현한 것
    • 프레임 : 다이어그램의 전체 도는 일부를 묶어 표현한 것
• 커뮤니케이션 다이어그램 : 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것
  • 커뮤니케이션 다이어그램 구성 요소
    • 액터 : 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 시스템을 의미
    • 객체 : 메시지를 주고받는 주체
    • 링크 : 객체들 간의 관계를 표현한 것
    • 메시지 : 객체가 상호 작용을 위해 주고받는 내용
• 상태 다이어그램 : 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것
  • 상태 : 객체의 상태를 표현한 것
  • 시작 상태 : 상태의 시작을 표현한 것
  • 종료 상태 : 상태의 종료를 표현한 것
  • 상태 전환 : 상태 사이의 흐름, 변화를 화살표로 표현한 것
  • 이벤트 : 상태에 변화를 주는 현상으로 조건, 외부신호, 시간의 흐름 등
  • 프레임 : 상태 다이어그램의 범위를 표현한 것
• 패키지 다이어그램 : 요소들을 그룹화한 패키지간의 의존 관계를 표현한 것
  • 패키지 다이어그램 구성 요소
    • 패키지 : 객체들을 그룹화한 것
    • 객체 : 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들
    • 의존 관계 : 패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결하여 표현

---

뒤로 이어지는 내용

https://edder773.tistory.com/172

[정보처리기사 실기] 비용 산정 기법 & 소프트웨어 개발 정리