Ⅰ. 소프트웨어 설계 : 요구사항 확인

1. 소프트웨어 생명 주기

소프트웨어 생명 주기(Software Life Cycle)
소프트웨어 개발 방법론의 바탕이 되며, 프로젝트 관리를 용이하게 하기 위해 사용한다. 소프트웨어를 개발하기 위한 정의, 운용, 유지보수 등의 과정을 단계별로 나눈 것이다.

 

2. 소프트웨어 생명 주기 모형

소프트웨어 생명 주기 모형
소프트웨어 생명 주기를 표현하는 형태를 말하며, 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임이라고도 한다.

 

1. 폭포수 모형 (Waterfall Model)
   이전 단계를 확실하게 마무리하고 다음 단계로 진행하는 개발 방법론으로 가장 오래된 모형이다. 선형 순차적 모형이며, 매뉴얼을 작성하여야 한다. 또한 각 단계가 끝난 후에는 결과물이 명확히 나와야 한다.
   

   

   폭포수 모형

2. 프로토타입 모형 (Prototype Model)
   사용자의 요구사항을 정확하게 파악하기 위해 시제품을 만들어 최종 결과물을 예측하는 모형으로 개발이 완료된 시점에 오류가 발견되는 폭포수 모델의 단점을 보완하기 위해 만들어졌다. 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두고 개발한다.
   

   

   프로토타입 모형

3. 나선형 모형 (Spiral Model)
   폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형이다. 나선을 따라 돌듯이 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 소프트웨어를 개발하는 것으로 점진적 모형이라고도 한다. 따라서 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며 유지보수 과정이 필요 없다. 대규모 프로젝트에서 많이 사용된다.
   

   

   나선형 모형 (출처: https://itwiki.kr/w/%EB%82%98%EC%84%A0%ED%98%95_%EB%AA%A8%EB%8D%B8)

4. 애자일 모형 (Agile Model)
   고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행하는 모형이다. 고객과의 소통에 초점을 맞춘 모든 방법론을 통칭하며, 애자일 모형을 기반으로 하는 모형에는 스크럼, XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM 등이 있다. 
   스프린트(Sprint) 또는 이터레이션(Iteration)이라고 불리는 짧은 개발 주기를 반복하며, 각 개발주기에서는 고객이 요구사항에 우선 순위를 부여하여 개발을 진행한다.
   

   

   애자일 모형 (출처: http://fpost.co.kr/board/bbs/board.php?wr_id=122&bo_table=special)

   1. 스크럼(Scrum) 기법
      스크럼이란 럭비 용어에서 파생된 언어로 팀이 중심이 되어 개발을 하는 것을 의미한다.
      • 스크럼의 구성 요소
        • 제품 책임자 (Product Owner) : 요구사항을 책임지고 의사 결정할 사람으로 주로 개발 의뢰자나 사용자가 담당한다. 요구사항이 담긴 백로그를 작성하고, 백로그에 대한 우선 순위를 지정한다. 테스트를 수행하며 우선순위를 주기적으로 갱신한다.
          백로그 : 제품 개발에 필요한 요구 사항을 모아 우선 순위를 부여한 목록으로 프로젝트의 네비게이터라고 할 수 있다.
        • 스트럼 마스터 : 팀의 가이드 역할을 수행한다.
        • 개발팀 : 제품 책임자와 스크럼 마스터를 제외한 팀원을 말한다. 개발자 외에도 제품 개발을 위해 참여하는 모든 사람이 대상이 된다.
      • 스크럼 개발 프로세스
        • 제품 백로그 : 개발에 필요한 요구사항을 우선순위에 따라 나열한 목록으로, 작성된 스토리를 기반으로 릴리즈 계획을 수립한다.
        • 스프린트 계획 회의 : 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립한다. 처리할 요구사항을 Task라는 작업 단위로 분할 후 개발자 별로 수행할 작업 목록인스프린트 백로그를 작성한다.
        • 스프린트 : 실제 개발 작업을 진행하는 과정이다. 개발 담당자에게 할당된 테스크는 보통 할 일, 진행 중, 완료의 상태를 갖는다.
        • 일일 스크럼 회의 : 진행 상황을 점검하는 회의호 남은 작업 시간은 소멸 차트에 표시한다.
        • 스프린트 검토 회의 : 부분 또는 전체 완성 제품이 요구사항에 부합하는지 테스팅을 진행한다.
        • 스프린트 회고 : 스프린트 후 정해 놓은 규칙 준수 여부, 개선점 여부 등을 점검한다.
   2. XP(eXtreme Programming) 기법
      고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 기법이다. 짧고 반복적인 개발 주기단순한 설계, 고객의 적극적인 참여를 통해 빠르게 개발하는 것이 목적이다. 릴리즈의 기간을 짧게 반복하며 요구사항 반영에 대한 가시성을 높인다. 
      릴리즈 : 부분적으로 요구사항이 적용된 제품을 제공하는 것을 말한다.
      XP의 핵심 가치 : 의사소통, 단순성, 용기, 존중, 피드백
      
      • XP 개발 프로세스
        

        

        XP 개발 프로세스 (출처: https://funyphp.com/archive/knowledge/158?sfl=mb_id%2C1&stx=webmaster&sst=wr_datetime&sod=desc&sop=and)

        •  사용자 스토리 : 고객의 요구사항을 간단한 시나리오로 표현한 것으로 내용은 기능 단위로 구성한다.
        • 릴리즈 계획 수립 : 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립한다.
        • 스파이크 : 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 프로그램이다.
        • 이터레이션 : 하나의 릴리즈를 세분화한 단위이다.
        • 승인 검사 : 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트이다. 고객이 직접 수행한다.
        • 소규모 릴리즈 : 고객의 반응을 기능 별로 확인하고 고객의 요구사항에 유연하게 대응하는 것이다. 
      • XP의 주요 실천 방법
        • Pair Programming
        • Test-Driven Development
        • Whole Team
        • Continuous Integration
        • Design Improvemwnt / Refactoring
        • Small Release

 

3. 현행 시스템 파악

현행 시스템 파악
개발하려는 시스템의 개발 범위를 명확히 설정하기 위해 현행 시스템의 구성과 제공 기능, 시스템 간의 전달 정보, 사용되는 기술 요소 등을 파악한다.

 

현행 시스템 파악 절차

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

1단계

• 시스템 구성 파악 : 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술한다.
• 시스템 기능 파악 : 현재 제공하는 기능들을 주요, 하부, 세부 기능으로 구분하여 계층형으로 표시한다.
• 시스템 인터페이스 파악 : 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시한다.

2단계

• 아키텍쳐 구성 파악 : 기간 업무 수행에 어떤 기술 요소들이 사용되는지 계층별로 표현한 구성도를 작성한다. 아키텍처가 단위 업무 시스템 별로 상이한 경우에는 가장 핵심이 되는 것을 기준으로 한다.
• 소프트웨어 구성 파악 : 소프트웨어의 베품명, 용도, 라이선스 적용 방식 등을 명시한다.

3단계

• 하드웨어 구성 파악 : 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량 및 서버의 이중화 적용 여부를 명시한다.
  서버의 이중화 : 운용 서버의 자료 변경이 예비 서버에도 동일하게 복제되도록 관리하는 것을 의미하며, 운용 서버의 장애 시 예비 서버를 사용해야 하는 경우에 적용한다.
• 네트워크 구성 파악 : 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성한다.

 

4. 개발 기술 환경 파악

개발 기술 환경 파악
개발하고자 하는 소프트웨어와 관련된 운영체제, 데이터베이스 관리 시스템, 미들웨어 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈소스 사용 시 주의해야 할 내용을 제시한다.

 

1. 운영체제 (OS; Operating System) : 컴퓨터 시스템의 자원(CPU, 주기억장치, 보조기억장치 등)들을 효율적으로 관리하며, 사용자가 컴퓨터를 편하게 사용할 수 있는 환경을 제공하는 소프트웨어이다. Window, Linux, Max OS, Android 등이 있다.
   ※ 운영체제 요구사항 식별 시 고려 사항 : 가용성, 성능, 기술 지원, 주변 기기, 구축 비용
   가용성 : 프로그램이 주어진 시점에서 요구사항에 따라 운영될 수 있는 능력을 말한다.
2. 데이터베이스 관리 시스템 (DBMS) : 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어를 말한다. Oracle, MySQL, SQLite, MongoDB 등이 있다.
   ※ 데이터베이스 요구사항 식별 시 고려 사항 : 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용
3. 웹 애플리케이션 서버 (WAS; Web Application Server) : 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어이다. Tomcat, GlassFish, JBoss, WebSphere 등이 있다.
   미들웨어 : 컴퓨터 제작 회사가 사용자의 요구대로 만들어 제공하는 프로그램으로 운영 체제와 응용 소프트웨어의 중간에서 조정과 중개 역할을 수행하는 소프트웨어이다.
   ※ 웹 애플리케이션 서버 요구사항 식별 시 고려 사항 : 가용성, 성능, 기술 지원, 구축 비용
4. 오픈 소스 : 누구나 제한 없이 사용할 수 있도록 공개한 소스코드이다. 오픈 소스를 사용하는 경우에는 라이선스의 종류, 사용자 수, 기술의 지속 가능성 등을 고려하여야 한다.

5. 요구사항 정의

요구사항
소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는 데 필요한 제약조건 등을 나타내는 것이다. 요구사항이 제대로 정의되어야 이후 과정의 목표와 계획 수립이 가능하다.

 

요구사항의 유형

• 기술하는 내용에 따른 분류
  • 기능 요구사항 : 시스템이 어떤 기능을 하는지에 대한 사항을 의미한다.
  • 비기능 요구사항 : 품질이나 제약사항에 대한 사항을 의미한다.
• 기술 관점과 대상의 범위에 따른 분류
  • 사용자 요구사항 : 사용자의 관점에서 본 시스템이 제공해야 할 사항을 의미한다.
  • 시스템 요구사항 : 개발자의 관점에서 본 시스템 전체가 사용자와 다른 시스템에게 제공해야 할 사항을 의미하며, 소프트웨어 요구사항이라고도 한다.

요구사항 개발 프로세스

요구사항 개발 프로세스

1. 요구사항 도출 : 요구사항이 어디에 있고 어떻게 수집할 것인지를 식별하고 이해하는 과정이다. 다음과 같은 기법을 이용하여 요구사항을 도출한다.
   • 브레인 스토밍 : 3인 이상이 자유룝게 아이디어를 내는 방식이다.
   • 워크샵
   • 프로토 타이핑
   • 유스케이스 : 사용자 측면에서의 요구사항으로 사용자가 원하는 목표를 달성하기 위해 사용자 요구사항을 기능 단위로 정리한 시나리오이다.
2. 요구사항 분석 : 요구사항 중 명확하지 않은 것을 걸러내는 과정이다.
   ※ 요구사항 분석 기법
   • 요구사항 분류 : 요구사항을 명확하게 확인할 수 있도록 정해진 기준으로 분류한다. (기능/비기능, 제품/과정, 우선순위 등)
   • 개념 모델링 : 요구사항을 쉽게 이해할 수 있도록 단순화하여 개념적으로 표현하는 과정이다. 개체와 개체 간의 관계 및 종속성을 반영하여 개념 모델을 만들며, 주로 UML을 사용해 표기한다.
   • 요구사항 할당 : 요구사항을 만족시키기 위한 구성 요소를 식별하는 것이다.
   • 요구사항 협상 : 요구사항이 서로 충돌될 경우 해결하는 과정으로 주로 우선 순위를 정해 해결한다.
   • 정형 분석 : 구문과 의미를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정이다. 요구사항 분석의 마지막 단계에서 이루어진다.
3. 요구사항 명세 : 요구사항 분석 후 승인될 수 있도록 이를 문서화하는 과정을 말한다.
4. 요구사항 확인 : 개발 자원을 요구사항에 할당하기 전 요구사항 명세서가 정확하게 작성되었는지 검토하는 과정이다.
   ※ 요구사항 확인 기법
   
   • 요구사항 검토 : 문서화된 요구사항을 훑어보며 확인하는 방법이다. 시스템 정의서, 시스템 사양서 등을 완성한 시점에 이루어진다.
   • 프로토타이핑 : 개발이 진행되는 동안 도출되는 요구사항을 반영하며 지속적으로 프로토타입을 재작성하는 과정이다. 발전된 결과물을 얻을 수 있다는 장점이 있으나, 사용자의 관점이 핵심에서 벗어나 프로토타입 제작에만 집중될 우려가 있다.
   • 모델 검증 : 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족하는지 검증하는 것이다.
   • 인수 테스트 : 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정이다.

 

6. UML (Unified Modeling Language)

UML (Unified Modeling Language)
시스템 개발 과정에서 개발자와 고객, 또는 개발자 상호 간의 의사 소통이 원활하게 이루어지도록 표준화한 객체 지향 모델링 언어이다.

 

UML 구성 요소

• 사물 : 모델을 구성하는 기본 요소로 관계가 형성될 수 있는 대상을 의미한다. 사물에는 구조 사물, 행동 사물, 그룹 사물, 주해 사물이 있다.
• 관계 : 사물과 사물 간의 연관성을 표현하는 것이다.
  • 연관 관계 : 2개 이상의 사물이 서로 관련된 관계이다. 실선과 화살표로 표현하나, 양방향 관계의 경우 화살표를 생략한다. 관계에 참여하는 객체의 개수를 의미하는 다중도를 선 위에 표기한다.
    

    다중도	의미
    1	1개의 객체가 연관되어 있다.
    n	n개의 객체가 연관되어 있다.
    0..1	연관된 객체가 없거나 1개만 존재한다.
    0..* 또는 *	연관된 객체가 없거나 다수일 수 있다.
    1..*	연관된 객체가 적어도 1개 이상이다.
    n..*	연관된 객체가 적어도 n개 이상이다.
    n..m	연관된 객체가 최소 n개에서 최대 m개이다.

    

    방향성이 존재하는 연관 관계

    

    방향성이 존재하지 않는 연관 관계

  • 집합 관계 : 하나의 사물이 다른 사물에 포함되어 있는 관계로 부분(포함되는 쪽)에서 전체(포함하는 쪽)로 속이 빈 마름모를 연결해 표현한다.
    

    

    집합 관계

  • 포함 관계 : 집합 관계의 특수한 형태로 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계이다. 해당 관계는 서로 독립될 수 없고, 생명주기를 함께한다.
    

    

    포함 관계

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

    

    일반화 관계

  • 의존 관계 : 사물 사이에 연관은 있으나 짧은 시간 동안만 연관을 유지하는 관계를 의미한다. 소유 관계는 아니지만, 사물의 변화가 다른 사물에도 영향을 미치며, 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결해 표현한다.
    

    

    의존 관계

  • 실체화 관계 : 기능으로 서로를 그룹화할 수 있는 관계이다. 사물에서 기능쪽으로 속이 빈 점선 화살표를 연결해 표현한다.
    

    

    실체화 관계

• 다이어그램 : 사물 간의 관계를 도형으로 표현한 것으로 정적 모델링에는 주로 구조적 다이어그램을 사용하고, 동적 모델링에서는 행위 다이어그램을 사용한다.
  • 구조적 다이어그램
    

    클래스 다이어그램	클래스, 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 다이어그램이다.
    객체 다이어그램	인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현한다.
    컴포넌트 다이어그램	구현 단계에서 사용되며, 컴포넌트 간의 관계나 인터페이스를 표현한다.
    배치 다이어그램	구현 단계에서 사용되며, 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현한다.
    복합체 구조 다이어그램	클래스나 컴포넌트가 복잡 구조를 갖는 경우 그 내부 구조를 표현한다.
    패키지 다이어그램	유스케이스, 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현한다.

  • 행위 다이어그램
    

    유스케이스 다이어그램	사용자의 요구를 분석하는 것으로 기능 모델링 작업에서 사용한다.
    시퀀스 다이어그램	상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현한다.
    커뮤니케이션 다이어그램	시퀀스 다이어그램에 추가적으로 객체들 간의 연관까지 표현한다.
    상태 다이어그램	하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지를 표현한다.
    활동 다이어그램	객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현한다.
    상호작용 개요 다이어그램	상호작용 다이어그램 간의 제어 흐름을 표현한다.
    타이밍 다이어그램	객체 상태 변화와 시간 제약을 명시적으로 표현한다.