소프트웨어 설계

chapter 01. 요구사항 확인

1. 현행 시스템 분석

• 플랫폼 기능 분석
  • 플랫폼의 개념
    • 플랫폼은 애플리케이션을 구동시키는 데 필요한 소프트웨어의 환경이다.
  • 플랫폼 성능 특성 분석
    • 플랫폼 성능 분석을 통해 사용자의 서비스 이용 시 속도의 적정성을 알 수 있다.
  • 플랫폼 성능 특성 측정 항목
    • 경과 시간, 사용률, 응답시간, 가용성이 있다.

경사응가: 경과시간 사용률 응답시간 가용성

• 운영체제 분석
  • 운영체제의 개념
    • 하드웨어 및 소프트웨어 자원을 효율적으로 관리하며 공통된 기능을 제공하는 소프트웨어.
  • 운영체제 현행 시스템 분석
    • 품질 측면과 지원 측면 등을 고려해야 한다.
    • 품질측면 - 신뢰도, 성능
    • 지원측면 - 기술 지원, 주변 기기, 구축 비용
• 네트워크 분석
  • 네트워크의 개념
    • 컴퓨터 장치들이 노드 간 연결을 사용하여 서로에게 데이터를 교환하는 기술
  • 네트워크 현행 시스템 분석
    • 네트워크 구성도를 통해 분석
• DBMS 분석
  • DBMS의 개념
    • DBMS는 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램이다.
  • DBMS 현행 시스템 분석
    • DBMS의 가용성, 성능, 상호 호환성, 기술 지원, 구축 비용 등을 분석한다.

가성호기구 - 가용성 성능 상호 호환성 기술 지원 구출 비용

2. 요구사항 확인

• 요구분석 기법
  • 요구분석의 개념
    • 사용자의 요구를 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지 결정하는 단계.
  • 요구분석의 특징
    • 소프트웨어 개발의 실제적인 첫 단계로 사용자의 요구에 대해 이해하는 단계.
    • 보다 구체적인 명세를 위해 소단위 명세서가 활용될 수 있다.
  • 요구사항 분석 단계 절차
    • 요구사항의 확인, 요구사항 구현의 검증, 비용 추정이 가능하도록 충분하고 정확하게 기술해야 한다.
  • 요구사항 분석 기술
    • 청취 기술, 인터뷰와 질문 기술, 분석 기술, 중재 기술, 관찰 기술, 작성 기술, 조직 기술, 모델 작성 기술이 있다.
  • 요구사항 분석에 사용하는 기능 모델링 기법
    • 데이터 흐름도
      • 데이터 흐름도는 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림.
    • 자료 사전
      • 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료 저장소의 의미와 그들 간의 관계, 관계 값, 범위, 단위들을 구체적으로 명시하는 사전.
  • 요구사항 분석이 어려운 이유
    • 개발자와 사용자 간의 지식이나 표현의 차이가 커서 상호 이해가 쉽지 않다.
    • 사용자의 요구사항이 모호하고 불명확하다.
    • 소프트웨어 개발 과정 중에 요구사항이 계속 변할 수 있다.
    • 사용자의 요구는 예외가 많아 열거와 구조화가 어려운 편이다.
• UML
  • UML의 개념
    • UML은 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어이다.
  • UML의 특징
    • UML은 방법론을 통합한 것으로, 표준화된 모델링 기법을 제공한다.
  • UML 구성요소
    • 사물, 관계 다이어그램
  • UML 사물
    • 구조 사물
    • 행동 사물
    • 그룹 사물
    • 주해 사물
  • UML 다이어그램
    • UML 다이어그램 개념
      • 사물과 관계를 모아 그림으로 표현한 형태이다.
    • UML 다이어그램 구분
      • 구분에 따라 구조적 다이어그램, 행위적 다이어그램으로 구분된다.
  • UML의 관계
    • UML의 관계는 사물과 사물 사이의 연관성을 표현하는 것으로서 연관 관계, 의존 관계, 일반화 관계, 실체화 관계, 포함 관계, 집합 관계 등이 있다.
• 애자일
  • 애자일 방법론의 개념
    • 소프트웨어 개발방법론의 하나로서 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법이다.
  • 애자일 방법론 등장 배경
    • 기존 개발방법론의 한계를 극복하기 위해 등장
  • 애자일 방법론 특징
    • 요구사항은 기능 중심으로 정의
    • 절차와 도구보다 개인과 소통을 중요하게 생각
    • 작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응 가능
    • 소프트웨어가 잘 실행되는 데 가치를 둔다.
    • 고객과의 피드백을 중요하게 생각
  • 애자일 선언문
    • 애자일 방법론을 실천하기 위한 주요 원칙
      • 공정과 도구보다 개인과 상호 작용
      • 계획을 따르기보다 변화에 대응하기
      • 포괄적인 문서보다 동작하는 소프트웨어
      • 계약 협상보다 고객과의 협력
  • 애자일 방법론 유형
    • 대표적으로 XP, 린, 스크럼 등이 있다.
    • XP
      • 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론.
      • 기존의 방법론에 비해 실용성을 강조한 방법론.
    • 스크럼
      • 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
    • 린
      • 도요타의 린 시스템 품질 기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론.
      • JIT, 칸반 보드를 사용한다.
    • 크리스탈
      • 일반적으로 프로세스나 도구보다는 사람에게 더 많은 중점을 두는 방법론
    • ASD, FDD