[정처기 - SW설계 A] 1. 요구사항 확인 (A단계)

0_0·2023년 4월 24일
정처기A정처기SW설계
0

정보처리기사

목록 보기
1/10

[ 1과목 ] 소프트웨어 설계

    1. 요구사항 확인 A단계
      001 소프트웨어 생명 주기
      003 XP(eXtreme Programming) 기법
      007 요구사항 분석
      009 UML(Unified Modeling Language)

1-1-001 소프트웨어 생명 주기

소프트웨어 생명 주기 (Software Life Cycle)

  • 소프트웨어 생명 주기 (Software Life Cycle)
    : 요구사항을 분석해서 설계하고, 그에 맞게 개발한 후 품질이 항상 최상의 상태를 유지할 수 있도록 관리하는 과정을 단계로 나눈 것.
    • = 소프트웨어 수명 주기
    • 소프트웨어 개발 방법론의 바탕.
    • 소프트웨어 생명 주기 모형 : 폭포수 모형, 프로토타입 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등
  • 소프트웨어 공학 (SE: Software Engineering)
    : 여러가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상이 목적.

  • 소프트웨어 공학의 기본 원칙

    1. 현대적인 프로그래밍 기술을 계속적으로 적용해야 합니다.
    2. 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 합니다.
    3. 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 합니다.

폭포수 모형 (Waterfall Model)

  • 한 단계가 완전히 끝나야만 다음 단계로 넘어가는 방법론. (선형 순차적)
    • = 고전적 생명 주기 모형
    • 매뉴얼 작성 필요.
    • 단점 : 개발 완료 시점에서 오류 발견
  • 계획 > 요구분석 > 설계 > 구현 > 시험(검사) > 유지보수

프로토타입 모형 (Prototype Model)

  • 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측.
    • = 원형 모형
    • 목적 : 사용자의 요구사항을 정확히 파악
    • prototype은 구현 단계에서 골격 코드로 사용
    • 설계 완료 시점에서 오류 발견되는 폭포수 모형의 단점을 보완.

나선형 모형 (Spiral Model)

  • 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발.
    • = 점진적 모형
    • 목적 : 발생가능한 위험을 관리하고 최소화
    • 폭포수 모형 장점 + 프로토타입 모형의 장점 + 위험 분석 기능
      • 누락되거나 추가된 요구사항 첨가 가능
      • 유지보수 과정 필요없음
      • 초기에 위험 요소 누락시 제거를 위해 많은 비용 소요 가능.

애자일 모형 (Agile Model)

  • 애자일 모형 (Agile Model)
    • 고객과의 소통에 초점을 맞춘 방법론을 통칭.
      • 목적 : 좋은 것을 빠르고 낭비 없게 만들기
    • 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복.
      • 주기 = 스프린트 (Sprint) = 이터레이션 (Iteration)
      • 주기마다 만들어지는 결과물에 대한 고객의 요구사항에 우선순위를 부여.
      • 기업 활동 전반에 걸쳐 사용됨.
    • 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합.
    • 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), ASD(Adaprive Software Development), 기능 중심 개발(FDD: Feature Driven Development), DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery) 등
  • 애자일 개발 4가지 핵심 가치
    1. 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
    2. 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
    3. 계약 협상보다는 고객과 협업에 더 가치를 둔다.
    4. 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둔다.

폭포수 모형과 애자일의 비교






1-1-003 XP(eXtreme Programming) 기법

XP (eXtreme Programming)

  • 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법.

    • 방법 : 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여
    • 목적 : 소프트웨어를 빠르게 개발. 고객의 요구사항에 유연한 대응.
    • 릴리즈 테스트마다 고객이 직접 참여 -> 고객이 직접 확인 가능
    • 릴리즈 기간을 짧게 반복 -> 고객의 요구사항 반영에 대한 가시성 높임.
    • 비교적 소규모 인원의 개발 프로젝트에 효과적.

  • XP의 5가지 핵심 가치

    : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)

XP 개발 프로세스

  • XP 개발 프로세스
    : 릴리즈 계획 수립 => 주기 => 승인 검사 => 소규모 릴리즈
  • 사용자 스토리 (User Strory)
    • 고객의 요구사항을 간단한 시나리오로 표현.
    • 기능 단위로 내용 구성. 필요하면 간단한 테스트 사항(Test Case) 기재.
  • 릴리즈 계획 수립 (Release Planning)
    • 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립.
    • 릴리즈 : 부분적으로 기능이 완료된 제품을 제공하는 것
  • 스파이크 (Spike)
    • 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
    • 처리할 문제 외의 다른 조건은 모두 무시하고 작성.
  • 이터레이션 (Iteration) = 주기
    • 하나의 릴리즈를 더 세분화 한 단위
      • 일반적으로 1~3주 정도의 기간
    • 새로운 스토리 작성 가능. -> 작성된 스토리는 진행 중인 이터레이션이나 다음 이터레이션에 포함 가능.
  • 승인 검사 (Acceptance Test, 인수 테스트)
    • 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트.
      • 사용자 스토리 작성 시 기재한 테스트 사항을 고객이 직접 수행.
      • 테스트 중 발견한 오류는 다음 이터레이션에 포함.
      • 테스트 이후 새로운 요구사항 작성이나 요구사항의 상대적 우선순위 변경 가능.
      • 테스트 완료시 다음 이터레이션 진행
  • 소규모 릴리즈 (Small Release)
    • 소규모 -> 고객의 반응을 기능별 확인 가능 -> 요구사항에 더 유연한 대응 가능.
    • 이터레이션 모두 완료시 고객의 최종 테스트 수행 후 최종 결과물(릴리즈)을 고객에게 전달.
      • 릴리즈가 최종 완제품이 아니면, 다음 릴리즈 일정에 따라 개발을 계속 진행.

  • XP의 주요 실천 방법(Practice)

    • Pair Programming (짝 프로그래밍)
      : 다른 사람과 함께 프로그래밍
      -> 개발에 대한 책임을 공동으로 갖는 환경 조성.

    • Collective Ownership (공동 코드 소유)
      : 개발 코드에 대한 권한과 책임을 공동으로 소유.

    • Test-Driven Development (테스트 주도 개발)
      : 실제 코드 작성 전 테스트 케이스 먼저 작성 -> 무엇을 할지 정확히 파악.
      자동화된 테스팅 도구(구조, 프레임워크) -> 테스트 지속적 시행.

    • Whole Team (전체 팀)
      : 모든 구성원들은 각자 자신의 역할이 있고, 그에 책임을 져야 함.

    • Continuous Integration (계속적인 통합)
      : 모듈 단위로 나눠서 코드 개발 -> 작업 하나 마무리마다 지속적으로 통합.

    • Design Improvement (디자인 개선) 또는 Refactoring (리팩토링)
      : 기능 변경 없이 단순화, 유연성 강화 등을 통해 시스템을 재구성.

    • Small Releases (소규모 릴리즈)
      : 릴리즈 기간을 짧게 반복 -> 고객의 요구변화에 신속히 대응 가능.






1-1-007 요구사항 분석

요구사항 분석의 개요

  • 요구사항 분석
    • : 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동.
      • 소프트웨어 개발의 실제적인 첫 단계
      • 소프트웨어 분석가에 의해 수행.
      • 사용자 요구의 타당성을 조사, 비용과 일정에 대한 제약을 설정.
      • 사용자의 요구를 정확하게 추출하여 목표를 정하고, 어떤 방식으로 해결할 것인지 결정.
    • 사용자의 요구를 정확하고 일관성있게 분석하여 문서화
      -> 분석 결과는 소프트웨어 설계 단계에서 필요한 기본적인 자료.

구조적 분석 기법

  • 구조적 분석 기법
    • : 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법.
      • 도형 중심의 도구 사용
        -> 분석가와 사용자의 대화 용이.
      • 도형 중신의 분석용 도구와 분석 절차 이용
        -> 사용자의 요구사항 파악 및 문서화.
      • 하향식 방법 사용
        -> 시스템 세분화 가능. 분석의 중복 배제 가능.
      • 사용자의 요구사항을 논리적으로 표현
        -> 전체 시스템을 일관성있게 이해 가능.
      • 시스템 분석의 질 향상, 모든 단계에서 필요한 명세서 작성 가능.
    • 모델링 도구 : 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec.), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 등

자료 흐름도 (DFD)

  • 자료 흐름도 (DFD; Data Flow Diagram)
    = 자료 흐름 그래프 = 버블 차트
    • : 시스템 안의 프로세스와 자료 저장소 사이의 자료의 흐름을 나타내는 그래프.
    • : 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법.
      • 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용.
      • 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화.
      • 자료 : 처리(Process)를 거쳐 변환될 때마다 새로운 이름이 부여.
      • 처리 : 입력 자료 발생시 기능 수행 후 출력 자료를 산출.
  • 자료의 흐름을 네 가지 기본 기호로 표시.

자료 사전 (DD)

  • 자료 사전 (DD; Data Dictionary)
    • 자료 흐름도에 시작적으로 표시된 자료에 대한 정보를 체계적이고 조직적으로 모음.
      • 메타 데이터 (Meta Data)
        : 데이터를 설명하는 데이터 (= 데이터의 데이터)
      • 체계적이고 조직적으로 모아 개발자나 사용자가 편리하게 사용 가능.
    • 자료 사전에서 사용되는 표기 기호





1-1-009 UML (Unified Modeling Language)

UML의 개요

  • UML (Unified Modeling Language)
    : 시스템 개발 과정(시스템 분석, 설계, 구현 등)에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
    • 공통된 표현법을 사용해 개발할 대상물을 다이어그램으로 표현하는 도구
      • UML을 이용하여 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램 작성 가능.
    • UML의 구성 요소
      : 사물 (Things), 관계 (Relationships), 다이어그램 (Diagram) 등이 있다.

사물 (Things)

  • 사물 (Things)
    : 다이어그램 안에서 관계가 형성될 수 있는 대상들
    • 모델을 구성하는 가장 중요한 기본 요소
    • 구조 사물, 행동 사물, 그룹 사물, 주해 사물

관계 (Relationships)

  • 관계 (Relationships)
    : 사물과 사물 사이의 연관성을 표현하는 것.
    • 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계 등
  • 연관 관계 (Association Relationships)
    : 2개 이상의 사물이 서로 관련되어 있음을 표현.
    • 표현 방법 : 실선으로 사물 연결. 화살표로 방향성 표현.
      • 양방향 관계 : 화살표 생략 가능.
      • 다중도 (Multiplicity) : 연관에 참여하는 객체의 개수. 선 위에 표기.
      • 예시
  • 집합 관계 (Aggregation Relationships)
    : 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현.
    • 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적
    • 표현 방법 : 부분에서 전체 방향으로 속이 빈 마름모를 연결.
      • 예시
  • 포함 관계 (Composition Relationships)
    : 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현.
    • 집합 관계의 특수한 형태
    • 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 의존적
      • 생명주기를 함께 함.
      • 전체가 사라지면 부분은 필요하지 않음.
    • 표현 방법 : 부분에서 전체 방향으로 속이 채워진 마름모를 연결.
      • 예시
  • 일반화 관계 (Generalization Relationships)
    : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현.
    • 보다 일반적인 개념이 상위(부모), 보다 구체적인 개념이 하위(자식)
    • 표현 방법 : 하위에서 상위 방향으로 속이 빈 화살표를 연결.
      • 예시
  • 의존 관계 (Dependency Relationship)
    : 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현.
    • 소유 관계는 아니지만 하나의 사물의 변화가 다른 사물에도 영향을 끼치는 관계.
    • 표현 방법 : 영향을 주는 사물(이용자)에서 영향을 받는 사물(제공자) 방향으로 점선 화살표를 연결.
      • 예시
  • 실체화 관계 (Realization Relationship)
    : 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현.
    • 표현 방법 : 사물에서 기능 방향으로 속이 빈 점선 화살표를 연결.
      • 예시

다이어그램 (Diagram)

  • 다이어그램
    : 사물과 관계를 도형으로 표현한 것.
    • 여러 관점에서 시스템을 가시화한 뷰(View)를 제공
      -> 의사소통에 도움.
    • 정적 모델링에서는 주로 구조적 다이어그램을 사용.
      동적 모델링에서는 주로 행위 다이어그램을 사용.
  • 구조적(Structural) 다이어그램의 종류
  • 행위(Behavioral) 다이어그램의 종류

+) 럼바우(Rumbaugh) 객체지향 분석 기법 : 객체는 객체 모델링에 활용. 상태는 동적 모델링에 활용.

profile
0_0
다음 포스트

[정처기 - SW설계 A] 2. 화면 설계 (A단계)

0개의 댓글