소프트웨어 설계 - 1.요구사항 확인

Wintering·2022년 2월 11일
0

정보처리기사

목록 보기
1/3

1. 소프트웨어 생명주기

  • 소프트웨어 생명주기 (= 소프트웨어 프로세스 모형 / 소프트웨어 공학 패러다임)
  • 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 단계별로 나눈 것
  • 문제의 유형이나 개발 방법 등에 따라 특정 모형을 선택하여 사용할 수도 있고, 개별적 모형을 사용하기도 함
    • 폭포수 모형
    • 프로토 타입 모형
    • 나선형 모형
    • 애자일 모형
※소프트웨어 공학의 개념
  • IEEE : 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안
  • Fairley : 지정된 비용과 기간 내에 소프트웨어를 체계적으로 생산하고 유지보수하는데 관련된 기술적이고 관리적인 원리
  • Boehm : 과학적인 지식을 소프트웨어 설계와 제작에 응용 / 개발, 운용, 유지 보수하는 데 필요한 문서작성

🔖출제 (소프트웨어 공학의 특징)

  • 현대적 프로그래밍 기술을 계속적으로 적용
  • 개발된 품질이 유지되도록 지속적으로 검증
  • 개발 관련 사항 및 결과에 대한 명확한 기록 유지

1-1.폭포수모형 (🔖출제)

  • 소프트웨어 개발은 이전 단계로 돌아갈 수 없다 / 단계를 확실히 매듭짓고 결과를 철저히 검토후 승인을 거친 후 다음단계 개발
  • = 고전적 생명주기 모형
  • 모형을 적용한 경험과 성공사례가 많음
  • 제품의 일부가 될 메뉴얼을 작성
  • 두개 이상의 과정이 병행되지 X
  • 현재 소프트웨어 공학에서 가장 폭넓게 사용되고 있음

타당성 검토 > 계획 > 요구분석 > 설계 > 구현 > 시험 > 유지보수

1-2. 프로토타입 모형(원형 모형)

  • 사용자의 요구사항을 정확히 파악하기 위해 견본품을 만들어 최종 결과물을 예측
  • 사용자와 시스템 사이의 인터페이스에 중점
  • 폭포수 모형의 단점을 보완하기 위함

1-3. 나선형 모형(점진적 모형)

  • 폭포수 모형 + 프로토타입 모형 + 위험분석기능
  • 여러번의 소프트웨어 개발 과정을 거침
  • 위험을 관리하고 최소하하는 것을 목적
  • 계획 → 분석 → 개발 → 평가 (반복) (🔖출제)

1-4. 애자일 모형(🔖출제)

  • 일정한 주기 (스프린트 / 이터레이션)를 반복하며 개발 과정 진행 ( = 고객의 요구사항과 변화에 유연하게 대처)

  • 고객과의 소통에 초점을 맞춘 방법론을 통칭

  • 기업활동 전반에 걸쳐 사용 / 소규모 프로젝트, 고도의 숙달된 개발자 / 급변하는 요구사항에 적합

  • 폭포수 모형과 대조적

    • 스크림

      • 제품 책임자 / 스크림 마스터 / 개발팀으로 구성 (팀을 구성하여 업무를 처리하는 기법)
      • 제품 책임자 : 요구사항의 주체 / 백로그를 작성하고 백로그에 대한 우선순위를 지정 / 주기적으로 우선순위 갱신
      • 스크림 마스터 : 팀원을 통제하지 X / 일일스크럼 회의 주관 / 장애 요소를 공론화 하여 처리
      • 개발팀 : 나머지
        • 스프린트 계획 회의 → 스프린트 → 스프린트 일일회의 → 스프린트 검토 회의 → 스프린트 회고
    • XP(eXtreme Programming) (🔖출제)

      • 짧고 반복적인 개발 주기 / 단순한 설계 / 고객의 적극적 참여
      • 릴리즈의 기간을 짧게 -> 가시성을 높임
      • 릴리즈 테스트마다 고객이 직접 참여 / 소규모 프로젝트에 효과적
        • 핵심가치 : 의사소통 , 존중, 용기, 단순성, 피드백
        • (사용자스토리 / 스파이크) → 릴리즈 → 주기(iteration) → 승인검사 → 소규모릴리즈
          • 스파이크 : 기술문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
        • XP의 주요 실천방법
          • Pair Programming / Collective Ownership / Test-Driven Development(테스트 케이스 먼저 작성)
          • Whole Team / Continuous Integration / Design Improvement / Small Release
    • 칸반

    • Lean

    • 크리스탈

    • ASD

    • 기능중심개발

    • DSMD

    • DAD

애자일 개발 4가지 핵심가치 (🔖출제)

  1. 개인과의 상호작용에 가치를 둔다
  2. 문서보다는 실행되는 SW에 가치를 둔다
  3. 고객과의 협업에 가치를 둔다
  4. 계획보다는 변화에 반응하는 것에 가치를 둔다

2. 현행 시스템 파악

  1. 시스템 구성 파악 : 주요업무인 기간업무 / 이를 지원하는 지원업무로 구분하여 기술
  2. 시스템 기능 파악 : 단위 업무 시스템을 주요 기능/ 하위 기능/ 세부 기능으로 나눠 계층형으로 표시
  3. 시스템 인터페이스 파악 : 데이터의 종류 / 형식 / 프로토콜 / 연계 유형 / 주기 등을 명시
  4. 아키텍쳐 파악 : 사용되고 있는 기술 요소 파악
  5. 소프트웨어 구성 파악 : 소프트웨어의 제품명, 용도, 라이선스 적용 방식, 라이선스 수
  6. 하드웨어 구성 파악 : CPU 사양, Core / 서버의 주요 사양과 수량/ 이중화 여부
  7. 네트워크 구성 파악 : 서버의 위치, 서버간의 네트워크 연결방식을 네트워크 구성도로 작성 (물리적 위치관계 파악)

3. 개발 기술 환경 파악

  • 운영체제
  • 데이터베이스 관리 시스템(DBMS) (🔖출제)
    • 가용성 : 백업이나 복구의 편의성 / 장시간 운용으로 인한 장애 발생 가능성 / DBMS 복제 지원 / 패치설치
    • 성능 : 대규모 데이터 처리 / 대규모 트랜젝션 / 튜닝옵션지원? / 최소화 된 설정과 비용 기반질의 최적화
    • 상호 호환성 : 설치 가능한 운영체제 종류 / JDBC, ODBC와의 호환성
  • 웹 애플리케이션 서버(WAS) (🔖출제)
    • 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어 (정적인 콘텐츠 : 웹서버)
    • Tomcat / GlassFish / JBoss / Jetty / JEUS / Resin / WebLogic / WebSphere
  • 오픈 소스
    • 라이선스의 수, 사용자 수, 기술의 지속 가능성등을 고려
  • 각각에 대해 가용성 / 성능 / 기술지원 / 주변기기 / 상호호환성 / 구축비용 등을 고려

4. 요구사항 정의 (🔖출제,🏷️중요)

  • 요구사항 : 문제를 해결하기 위해 제공하는 서비스에 대한 설명 or 필요한 제약조건

4-1. 요구사항의 유형

  • 기술한 내용 : 기능 요구사항 / 비기능 요구사항(🔖출제)
    • 기능 요구사항
      • 시스템이 무엇을 하고 어떤 기능을 하는지 / 입출력에 포함되는 것 / 어떤 데이터를 연산하고 수행할지
      • 사용자가 시스템을 통해 제공받기를 원하는 기능들
    • 비기능 요구사항
      • 시스템 장비 구성 요구사항 / 성능 요구사항 / 인터페이스 요구사항 / 데이터 요구사항
      • 테스트 요구사항 / 보안 요구사항 / 품질 요구사항 / 제약사항 / 프로젝트 관리 요구사항 / 프로젝트 지원 요구사항
  • 기술 관점, 대상범위 : 사용자 요구사항 / 시스템 요구사항
    • 사용자 요구사항 : 사용자를 위한 것으로 이해하기 쉽게 작성
    • 시스템 요구사항 (= 소프트웨어 요구사항) : 개발자의 관점, 기술적 용어로 표현됨

4-2. 요구사항 개발 프로세스(🔖출제 )

  • 도출

    • 청취나 인터뷰 등 질문기술
    • 이해관계자가 식별되고, 그들간의 효율적 의사소통이 중요 / 개발 생명주기 동안 지속적으로 반복
    • 청취, 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스
  • 분석

    • 분석과 중재기술
    • 타당성 조사, 비용과 일정에 대한 제약 설정 / 상충되는 의견 중재
    • 소프트웨어 범위 파악 / 소프트웨어와 주변환경의 상호작용법 이해
    • 자료 흐름도 (DFD) , 자료사전 (DD) 사용
  • 명세

    • 관찰 및 모델 작성 기술 (문서화)

    • 기능 요구사항은 완벽히 기술 / 비기능 요구사항은 필요한 것만 명확히 기술

    • 요구사항 명세 기법 : 정형 명세 / 비정형명세

      • 정형명세 : 수학적 원리 기반 모델 기반 / 간결한 표현, 일관성이 있어 완전성 검증 가능, 어려움

        ​ VDM, Z, Petri-net, CSP

      • 비정형명세 : 상태/기능/객체 중심 / 일반 명사, 동사등 자연어 기반 / 쉬움, 일관성이 떨어져 해석이 달라질 수 있음

        ​ FSM, Decision Table, ER모델링, STATE Chart(SADT)

  • 확인

    • 명세서를 검토하는 과정

5. 요구사항 분석 (🔖출제,🏷️중요)

  • 구조적 분석기법

    • 도형 중심의 분석용 도구와 분석 절차 (사용자간의 대화가 용이)

    • 하향식 방법을 사용, 시스템 세분화 및 분석 중복 배제

    • 자료흐름도(DTD : Data Flow Diagram), 자료사전 (DD : Data Dictionary), 소단위 명세서(Mini-spec.)

      개체관계도(ERD), 상태전이도(STD), 제어 명세서 등의 도구를 이용

5-1. 자료흐름도 (DFD)(🔖출제)

  • 자료흐름그래프, 버블차트
  • 시스템 안의 프로세스와 자료 저장소 사이의 자료 흐름을 나타내는 그래프
기호의미
프로세스(Process)- 자료를 변환 시키는 시스템의 한 부분(처리과정) / 처리, 기능, 버블이라고도 함
- 원이나 둥근 사각형으로 표시 (원 : Yourdon/DeMacro 사각형 : Gane/Sarson)
자료 흐름(Data Flow)-자료의 이동(흐름)이나 연관관계를 나타낸다
-화살표 위에 자료의 이름을 기입
자료 저장소(Data Store)- 시스템에서의 자료 저장소(파일, 데이터베이스)를 나타냄
-도형 안에 자료 저장소의 이름을 기입
단말(Terminator)- 시스템과 교신하는 외부 개체, 입력데이터가 만들어지고 출력데이터를 받음
-도형 안에 이름을 기입

5-2. 자료사전

  • 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록, ( 데이터를 설명하는 데이터 = 메타 데이터)
기호의미
=자료의 정의 : ~로 구성되어있다.
+자료의 연결 : 그리고(and)
()자료의 생략 : 생략가능한 자료(Optional)
[|]자료의 선택 : 또는(or)
{}자료의 반복 : Iteration of / {}(아래첨자) : n번이상반복 / {}(윗첨자) : n번까지반복 / {} : 아래첨자이상 윗첨자이하로 반복
* *자료의 설명 : 주석

6. 요구사항 분석 CASE와 HIPO(🔖출제)

6-1. 요구사항 분석을 위한 CASE(자동화기구)

  • SADT
    • SoftTech사에서 개발
    • 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구
  • SREM
    • TRW 사, 우주 국방 시스템 그룹
    • RSL(Requirement Statement Language)과 REVS를 사용하는 자동화 도구
      • RSL : 요소, 속성, 관계, 구조를 기술하는 요구사항 기술 언어
      • REVS : RSL을 사용하여 요구사항 분석 명세서를 출력
  • PSL/PSA
    • 미시간 대학 ,
      • PSL (Problem Statement Language) : 문제(요구사항) 기술 언어
      • PSA(Problem Statement Analyzer) : PSL로 기술한 요구사항을 자동 분석, 다양한 보고서를 출력
  • TAGS(Technology for Automated Generation of Systems)
    • 시스템 공학 방법을 응용한 자동 접근 방법, 개발 주기의 전 과정에 이용
    • IORL(요구사항 명세 언어), 요구사항 분석과 IORL 처리를 위한 도구, 기초적인 TAGS 방법론
  • EPOS

6-2. HIPO(Hierarchy Input Process Output)

  • 시스템의 분석 및 설계나 문서화에 사용 / 입력, 처리, 출력의 기능을 나타냄
  • 시스템의 기능을 여러개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라 함
  • HIPO의 종류
    • 가시적 도표(도식 목차) : 시스템의 전체적 기능과 흐름을 보여주는 계층 구조
    • 총체적 도표(총괄도표, 개요 도표) : 프로그램을 구성하는 기능을 기술
    • 세부적 도표(상세 도표) : 총체적 도표에 표시된 기능을 구성하는 기본요소를 상세히 기술

7. UML(Unified Modeling Language)

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

  • RumBaught(ORM), Booch, Jacobson 등의 장점을 통합, OMG에서 표준으로 지정

  • 시스템의 구조를 표현하는 6개의 구조 다이어 그램 + 시스템의 동작을 표현하는 7개의 행위 다이어 그램

  • 사물(Things), 관계(RelationShip), 다이어그램(Diagram)

7-1. 사물(Things)

사물내용
구조 사물시스템의 개념적 물리적 요소
- 클래스(Class), 유스케이스(Use case), 컴포넌트(Component), 노드(Node)
행동 사물시간과 공간에 따른 요소들의 행위 표현
- 상호작용(Interaction), 상태 머신(State Machine) 등
그룹 사물요소들을 그룹으로 묶어서 표현
-Package
주해 사물부가적인 설명이나 제약조건
- 노트(Note)

7-2. 관계(RelationShip)

  • 연관관계, 집합관계, 포함관계, 일반화관계, 의존관계, 실체화관계 등

    img
    • 연관관계

      • 실선 / 방향성은 화살표로 표현
      • 서로에게 영향을 주는 경우 화살표를 생략하고 선만으로 표현
      • 다중도를 선위에 표현
    • 집합관계

      • 하나의 사물이 다른쪽 사물에 포함
      • 포함하는 쪽과 포함되는 쪽은 서로 독립적
      • 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마름모를 연결하여 표현
    • 포함관계

      • 집합관계의 한 형태 , 포함하는 사물의 변화가 포함되는 사물의 변화에 영향을 미치는경우
      • 속이 채워진 마름모를 연결하여 표현
    • 일반화관계

      • 하나의 사물이 다른 사물에 비해 더 일반적이고 구체적인지
      • 보다 일반적인 개념(상위관계:부모), 보다 구체적 개념(하위관계:자식)
      • 자식에서 부모의 방향으로속이 빈 화살표를 연결하여 표현
    • 의존관계

      • 연관관계와 같이 사물 사물 사이의 연관은 있으나, 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
      • 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사요하는 경우에 나타남
      • 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결
    • 실체화관계

      • 사물이 할수있거나 해야하는 기능 으로 서로를 그룹화 할 수 있는 관계
      • 속이 빈 점선 화살표로 표현

7-3. 다이어그램(Diagram)

  • 정적 모델링에서는 주로 구조 다이어그램을 사용하고, 동적 모델링에서는 주로 행위 다이어그램을 사용한다
  • 구조적 다이어그램(🔖출제)
종류기능
클래스 다이어그램믈래스와 클래스가 가지는 속성, 클래스 사이의 관계 표현
-시스템 구조 파악, 구조성 문제점 도출
객체 다이어그램인스턴스(클래스에 속한 사물)를 특정 시점의 객체와 객체 사이의 관계로 표현
-럼바우(Rumbaugh) 객체지향 분석 기법에서 객체모델링에 활용
컴포넌트 다이어그램실제 구현 모들인 컴포넌트 간의 관계나 컴포넌트간의 인터페이스
-구현 단계에서 사용
배치 다이어그램결과물 프로세스, 컴포넌트 등의 물리적 요소 표현
노드와 의사소통(통신) 경로로 표현 / 구현 단계에서 사용
복합체 구조 다이어그램클래스나 컴포넌트가 복잡한 경우, 그 내부 구조를 표현
패키지 다이어그램유스케이스나 클래스등의 모델 요소들을 그룹화
  • 행위 다이어그램(🔖출제)
종류기능
유스케이스 다이어그램사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용
시퀀스 다이어그램상호 작용하는 시스템이나 객체들이 주고받는 메시지
커뮤니케이션 다이어그램메세지 + 객체들간의 연관까지 표현
상태 다이어그램하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호작용에 따라
상태가 어떻게 변화하는지 표현, 럼바우 객체지향 분석 기법에서 동적 모델링 활용
활동 다이어그램시스템이 어떤 기능을 수행하는지, 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
상호작용 개요 다이어그램상호작용 다이어그램 간의 제어 흐름
타이밍 다이어그램객체 상태 변화와 시간 제약을 명시적 표현
  • 스테레오 타입(🔖출제)
    • 길러멧이라고 부르는 겹화살괄호 사이에 표현할 형태 기술
타입내용
<>포함 관계에 있는 경우
<>확장 관계에 있는 경우
<>인터페이스를 정의하는 경우
<>예외 정의
<>생성자 역할 수행

0개의 댓글