1. 소프트웨어 설계(필기)

요구사항 개발 프로세스

• 도출 -> 분석 -> 명세 -> 확인
• 요구사항 도출
  • 요구사항 도출은 개발될 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계이다.
  • 소프트웨어 요구사항의 출처가 누구이며 어느 부서인지, 어디에 있는지 파악한다.
  • 소프트웨어 요구사항을 어떠한 방법으로 수집할 것인가를 파악한다.
  • 이해관계자가 식별되고, 개발팀과 고객 사이의 관계가 만들어지는 단계이다.
  • 다양한 이해관계자와 효율적이고 다양한 의사소통이 매우 중요하다.
  • 도출 기법에는 인터뷰, 스토리텔링, 프로토타이핑, 워크숍, 벤치마킹 등이 있다.
• 요구사항 분석
  • 요구사항의 타당성을 조사한다.
  • 소프트웨어 요구사항들 사이에 서로 다르거나 상충되는 것을 해결한다.
  • 소포트웨어의 범위를 파악한다.
  • 소프트웨어 개발 비용과 일정에 대한 제약을 설정한다.
  • 소프트웨어가 다른 환경과 어떻게 상호 작용하는지 이해한다.
  • 소프트웨어 요구사항을 최적화하여 정확히 분석한다.
  • 분석 기법에는 DFD, DD, Mini-Spec, ERD, UML 등이 있다.
  • 요구사항을 분석하고 정의해서 문서화 한다.
• 요구사항 명세
  • 파악된 요구사항을 체계적으로 검토, 평가하고 승인될 수 있는 문서를 작성한다.
  • 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 개발자뿐만 아니라 고객도 알 수 있을 정도로 쉽게 작성한다.
  • 요구사항 명세 기법 
    • 정형 명세기법
      
      • 사용자의 요구를 표현할 때 수학적인 원리와 표기법을 이용하여 서술한다.
      • 사용자의 요구 특성을 정확하게 표현할 수 있다.
      • 가장 강력한 표현 방법으로 두고 사용이 필수적이다.
      • 명세서가 간결하고, 명세와 구현이 일치된다.
      • 수학적인 이해가 필요하기 때문에 사용자와 개발자 간의 부담이 생긴다.
      • VDM, Z, CSP, CSS
    • 비정형 명세기법
      • 사용자의 요구를 표현할 때 자연어를 기반으로 서술한다.
      • 가장 일반적이고 친숙하지만 명세서로는 바람직하지 못하다.
      • 사용자의 요구를 표현할 때 상태, 기능, 객체 중심으로 서술한다.
      • 이해가 용이하며 사용자와 개발팀 간의 의사 전달 방법이 다양하다.
      • 불출붕한 명세서가 작성될 수 있으며, 모호성이 발생할 수 있다.
      • FSM, Decision Table, E-R, SADT
    • 요구사항 명세서 작성 시 고려사항
      • 고객과 개발자가 쉽게 이해할 수 있도록 작성한다.
      • 사용자와 개발자가 모두 동의한 내용을 작성한다.
      • 시스템의 모든 기능과 모든 제약조건을 기술한다. 
      • 요구사항 검증을 위해 품질 측정 및 검증 방법, 인수 테스트 기준 등을 기술한다.
      • 우선순위에 따른 중요도를 기술한다.
      • 요구사항을 쉽게 알아볼 수 있도록 식별자를 사용한다.
    • 요구사항 명세서 작성 원칙
      • 명확성 : 요구사항 명세 내용은 하나의 의미만을 부여한다.
      • 완전성 : 기능, 성능, 범위, 제약사항 등 모두 요구사항을 포함시킨다. 
      • 검증 가능성 : 요구사항의 충족 여부와 달성 여부를 확인할 수 있게 한다.
      • 일관성 : 명세 내용 간에 상호 모순이 발생하지 않도록 한다.
      • 수정 용이성 : 요구사항 변경을 쉽게 수정할 수 있도록 한다.
      • 추적 가능성 : 요구사항 명세 근거로 오류 추적이 가능해야 한다.
      • 개발 후 이용성 : 운영 및 유지보수를 효과적으로 사용할 수 있어야 한다.
  • 요구사항 확인
    • 분석가가 소프트웨어 요구사항을 이해했는지 확인이 필요하다.
    • 요구사항 명세서가 표준에 적합하고 이해가 가능한지 확인한다.
    • 요구사항 명세서가 일관성이 있고 완전한지 검증하는 것이 중요하다.
    • 이해관계자들이 문서를 검토해야 하므로 쉽게 작성되어있는지 확인한다.

요구사항 도출 기법

• 사용자 그룹 인터뷰
  • 사용자를 대상으로 인터뷰를 수행하여 요구사항을 도출한다.
  • 가능한 많은 사용자로부터 인터뷰하는 것이 좋다.
  • 회의록 작성은 필수적이며 가능하면 인터뷰 내용은 녹음하여 반복 청휘하는 것이 좋다.
• 이해관계자 설문 조사
  • 사용자와 직접 만나면 좋지만, 어려울 때는 설문 형식으로 조사한다.
  • 현행 시스템의 문제점, 개선할 점 등을 끌어낼 수 있는 설문을 준비한다.
• 문헌 조사
  • 유사한 소프트웨어의 업무 문서나 양식을 조사하여 현행 시스템 정보에 대한 이해를 충분히 한다.
  • 산업 기술 표준, 정부 정책, 규제, 법규 등을 조사한다.
  • 개발팀은 개발 업체의 업무 교육이나 듀토리얼에 참가한다.
• 프로토타이핑
  • 기본적인 기능만 빠르게 구현해서 사용자에게 피드백을 받는다.
  • 개발자의 의도를 사용자로부터 빠르게 피드백 받고자 할 때 사용한다.
  • 프로토타입을 위한 프로그램 전용 언어로 가상적인 사용자 인터페이스 환경을 만들어 사용한다.
• 스토리텔링
  • 이야기 형식으로 요구사항을 기술하여 자연스럽게 개발자가 요구사항에 대한 이해가 되도록 구성하는 기법이다.
  • 스토리텔링은 애자일 방법에서 주로 사용하는 방법으로 개발자와 사용자 간의 대화를 화면서 함께 요구사항을 분석해내는 방법이다.
• 분석과 중재 기술
  • 사용자의 요구사항을 철저하게 분석하여 오류와 이상 여부를 판단한다.
  • 사용자의 요구가 무리하거나 합리적이지 않을 경우 사용자를 이해시키고 설득시킬 수 있는 중재 기술이 필요하다.
• 관찰과 모델 작성 기술
  • 업무 특성이나 사용자의 업무 처리를 자세히 관찰하여 업무의 흐름을 모델링할 수 있어야 한다.

 

CASE(Computer Aided Software Engineering)

• CASE는 소프트웨어를 개발하는 시점부터 요구분석, 설계, 개발, 유지보수에 이르기까지 소프트웨어의 생명주기 전반을 지원하는 프로그램 또는 소프트웨어 개발을 지원하는 도구 혹은 방법론의 결합이다.
• 소프트웨어 개발 과정의 일부 또는 전체를 자동화하기 위한 도구
• 표준화된 개발 환경 구축 및 문서 자동화 기능을 제공
• 작업 과정 및 데이터 공유를 통해 작업자 간의 커뮤니케이션을 증대
• CASE는 객체지향 시스템뿐만 아니라 구조적인 시스템을 포함해 모든 분야에 적용
• 분산된 환경에서 다양한 이해관계자가 공동 작업할 수 있으며 테스트 연계 및 결함 관리 등의 기능을 제공하기 때문에 시스템 구축 업무를 효율적으로 수행할 수 있다.
• 자동화된 일관성 분석을 제공하는 CASE 도구를 활용할 수 있다.
• 대규모 시스템에서는 다양한 이해관계자들이 요구사항 명세서를 검토해야 하고 복잡한 형상 관리를 수행해야 하기 때문에 요구사항 관리 도구인 CASE를 이용한다.
• CASE  분류
  • 상위 CASE : 요구분석과 설계를 지원한다.
  • 하위 CASE : 코드 작성, 검사를 지원한다.
  • 통합 CASE : 개발 주기의 전 과정을 지원한다.
• CASE  구성요소
  • 상위부 : 원하는 결과를 얻기 위한 명령 입력 부분
  • 중위부 : 입력된 결과를 처리하는 부분으로 데이터베이스의 통계적 정보를 의뢰
  • 후위부 : 처리된 결과를 출력
  • 다중 정보 : 다양한 정보를 체계적으로 저장하고 있는 데이터베이스 부분
• CASE 특징
  • 소프트웨어 생명주기의 전 단계를 연결
  • CASE의 Tool 가격은 비싸지만 소프트웨어를 개발할 수 있는 기간이나 인력을 줄일 수 있기 때문에 전체 개발 비용은 절감
  • CASE는 스스로 동작하는 것이 아니므로 분석가의 지원이 필요
  • 수정이 용이하며 정확
  • 개발을 신속하게 할 수 있어 개발 기간이 단축
  • 프로그램 유지보수 간략
  • 생산성 상승
  • 재사용성 상승
  • 자동화된 검사를 통해 품질 향상
  • 그래픽 지원
  • 다양한 소프트웨어 개발 모형 지원
  • CASE 툴 간의 호환성이 없다.
  • 요구사항 변경 사항을 추적하고 분석 및 관리 가능