[개발방법론] 전통적인 개발 방법론

• 전통적(고전적) 소프트웨어 개발방법
• (= 구조적 소프트웨어 개발방법)
• 과거의 개발 경험을 토대로하여 제안한 것
  
  

• 요구사항 분석
• 특징
• 소프트웨어 개발의 실제 첫 단계
• 개발 대상에 대한 사용자의 요구사항 이해 및 문서화
• 분석 작업 단계
• 문제 인식 : 사용자와 회의, 설문조사, 각종 문서 검토 등을 통해 요구사항 파악
• 평가와 종합 : 요구사항에 대한 정보 평가 및 해결책 종합
• 모델 제작
• 문서화 및 검토 : 요구사항 분석 명세서 작성
• 요구사항 분석의 한계
• 대화 장벽
• 사용자와 개발자 간의 의사소통 어려움
• 솔루션 : 다이어그램, 프로토타입
• 시스템 복잡도
• 소프트웨어 체계화에 따른 새로운 개념 요구
• 시스템 규모와 대상이 광범위해짐에 따른 소프트웨어 복잡화
• 솔루션 : 구조적 분석, 객체지향 분석
• 요구 변경
• 요구 명세화
• 요구사항 분석가의 자질
• 요구사항 분석가 : 요구사항을 효율적으로 분석하고 정확한 명세화 제공
  
  
• 구조적 분석 기법
• 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
• 특징
• 도형 기반 분석용 도구와 분석 절차 이용하여 사용자의 요구사항 파악 및 문서화
• 도형을 이용하므로 사용자와의 대화 용이
• 하향식 방법을 이용한 시스템 세분화 (분석의 중복 피할 수 있음)
• 요구사항이 논리적으로 표현됨 --> 시스템을 일관성 있게 이해할 수 있음
• 분석의 질 향상. 개발 전 단계에서 필요한 명세 작성 용이
• 모델링에 사용되는 도구들 (구조적 분석 도구)
• 자료 흐름도(DFD, data flow diagram)
• (= 자료흐름 그래프, 버블 차트)
• 특징
• 요구사항 분석에서 사용
• 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술
• 자료 흐름과 기능을 자세히 표현하기 위하여 단계적으로 세분화
• 자료는 처리(process)를 거쳐 변환될 때마다 새로운 이름 부여, 처리(process)는 입력 자료가 발생하면 기능 수행 후 출력 자료 산출
• 자료 흐름도의 세분화(상세화)
• 요구 사항 분석이 진행됨에 따라 하나의 자료 흐름도를 보다 자세히 표현하기 위해 다른 자료 흐름도를 생성하는 것
• 세분화 단계가 많아질수록 소프트웨어 설계와 구현이 용이
• 단계(레벨) 0의 자료 흐름도 --> 기본 시스템 모델 (배경도)
• 예) 단계 N 이 이름짓기라면 n+1 단계에는 이름짓기를 세분화하여 성 고르기, 이름 고르기 이런 식으로...
• 자료 흐름도 구성요소 표기법
• 프로세스(process)
• 처리 과정을 나타냄.
• = 처리/기능/변환/버블
• 원 또는 둥근 사각형으로 표시
• 자료 흐름(flow)
• 자료의 이동(흐름) 표시
• 화살표 이로 자료 이름 기입
• 자료 저장소(data store)
• 시스템의 자료(파일, 데이터베이스) 표시
• 단말(terminator)
• 시스템과 교신하는 외부 개체
• 입력 데이터가 만들어지고 출력 데이터를 받음
• 자료사전 (DD, Data dictionary)
• = 데이터의 데이터, 메타데이터
• 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것. 데이터를 설명하는 데이터. 
• 자료사전에 사용하는 기호
• = : 자료의 정의.
• + : 자료의 연결 (그리고)
• ( ) : 자료의 생략(옵션)
• [ | ] : 자료의 선택
• { } : 자료의 반복
• * * : 자료의 주석
• 소단위 명세서(Mini spec)
• 세분화된 자료 흐름도에서 최하위 단계의 프로세스(버블)의 처리 절차를 기술
• = 프로세스 명세서
• 분석가의 문서. DFD 지원하기위한 문서
• 구조적언어, 의사 결정표(판단표, decision table) 이용
• 개체관계도 (ERD, Entitiy relationship diagram)
• 개체 관계도 기호
• 개체 - 사각형, 속성 - 타원, 관계 - 다이아몬드
• 작성 순서
• 주요키를 포함한 개체 속성 파악
• 기본 개체와 주요키 정의 및 개체 사이의 관계 파악
• 1:M 관계를 단순화하기위해 속성 개체 추가, 연관 관계 정의하여 M:N 관계로 표현
• 각 개체를 정규화, 누락된 개체 점검 및 클래스 구조 필요성 파악
• 상태전이도 (STD, State Transition Diagram)
• 시스템에 어떤 일이 발생할 경우, 시스템의 상태와 상태 간의 전이를 모델화 한 것
• 상태전이도를 통하여 개발자는 시스템의 행위를 정의할 수 있음
• 제어명세서 등...
  
  

• CASE (자동화 도구)
• 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구
• 장점
• 표준화
• 보고를 통한 문서화 품질 개선
• DB를 모두가 이용할 수 있기에 분석자들 간 적절한 조정 가능
• 교차 참조도와 보고서를 통한 결함, 생략, 불일치 발견 용이
• 종류
• SADT (Structured Analysis and Design Technique)
• softtech사에서 개발. 구조적 분석 및 설계 도구
• 구조적 요구 분석을 위한 블록 다이어그램 사용 
• SREM (Software Requirements Engineering Methodology)
• trw사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확하게 하기위해 개발
• RSL 및 REVS 이용
• RSL (Requirement Statement Language) : 요구사항 기술 언어
• REVS(Requirement Engineering and Validation System) : RSL로 작성된 요구사항을 자동으로 분석하여 분석 명세서 출력
• PSL(Problem Statement Language) /PSA(Program Statement Analyzer)
• 미시건 대학에서 개발
• PSL : 문제(요구사항) 기술 언어
• PSA : PSL 로 작성된 요구사항 자동 분석
• TAGS (Technology for Automated Generation of Systems)
• 시스템 공학 방법 응용에 대한 자동 접근법
• 개발 주기 전과정에서 이용 할 수 있음 (통합 자동화 도구)
• IORL : 요구사항 명세 언어
  
  
• HIPO(hierarchy input process output)
• 시스템 분석 및 설계, 문서화 시 사용되는 기법
• 특징
• 시스템 실행 과정 (입력/처리/출력) 기능 수행
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 체계적 문서관리
• 기호, 도표를 이용 --> 이해하기 쉬움
• 기능과 자료의 의존관계 표현 가능
• 변경, 유지보수 용이
• 종류
• 가시적 도표 (도식 목차)
• 전체적 기능 및 흐름 파악 --> 트리(계층) 구조
• 총체적 도표 (총괄 도표, 개요 도표)
• 기능(입출력, 처리)에 대한 전반적 정보 제공
• 세부적 도표 (상세 도표)
• 총체적 도표에 표현된 기능을 구성하는 기본요소를 상세하게 서술

• 설계
• 구조적 설계 기법 (전통적!)
• 자료의 흐름을 중심으로 설계 (= 자료 흐름 중심 설계 기법)
• 자료 흐름도, 자료사전, 개체관계도, 소단위 명세서 등이 준비된 이후에 설계
• 개요
• 요구사항 분석 명세서의 기능이 실현되도록 알고리즘가 해당 자료구조를 문서화하는 것
• 좋은 소프트웨어 개발을 위한 핵심 기술. 품질 평가를 위한 지침이 됨
• 소프트웨어 설계 모형 (기술적 관점)
• 데이터 설계 - 요구사항을 바탕으로 하여 필요한 자료 구조 설계
• 구조설계 - 모듈 간 관계 및 프로그램 구조 정의
• *구조적 설계.
• 정보 흐름의 유형 >> 흐름의 경계 표시 >> 흐름도를 이용하여 프로그램 구조도 작성 >> 제어계층을 분해하여 정의 >> 경험적 방법을 통한 구체화
• 인터페이스 설계
• 절차 설계 - 모듈이 수행할 기능을 절차적 기술로 변환
• 그래픽 설계 표기
• 흐름도 (flowchart) : 순차,선택,반복 으로 구성
• N-S 차트 : 순차, 선택, 반복 + 선택 + 다중 
• 프로그램 설계 언어 (PDL)
• cf. 사용자적 관점 : 내부설계 vs. 외부 설계
• cf. 관리적 관점 : 기본설계 vs. 상세 설계
• 설계의 기본 원리
• 모듈화 (Modularity)
• 추상화 (Abstraction, 개념화)
• 기능 추상화
• 제어 추상화
• 자료 추상화
• 단계적 정제 (Stepwise Refinement)
• 정보은닉 (Information Hiding)
• 프로그램 구조 (Program Structure, 제어 계층 구조)
• 모듈의 계층적 구조를 나타냄.  (트리구조)
• 용어
• 공유도 (fan-in, 팬-입력) : 어떤 모듈을 제어(호출)하는 모듈의 수
• 제어도 (fan-out, 팬-출력) : 어떤 모듈을 제어(호출)하는 모듈의 수
• 깊이(depth), 넓이(width), 주종적모듈, 종속적모듈
• 자료 구조
• 바람직한 설계의 특징 ( 소프트웨어 설계의 지침, 좋은 설계의 기준)
• --> 모듈단위로 구성하는 것!
• 소프트웨어 구조를 나타냄
• 요소(모듈) 간의 효과적인 제어를 위해 계층적 자료 조직이 제시되어야 함
• 자료아 프로시저 간의 분리된 표현 필요
• 적당한 모듈크기, 모듈관의 상관성(결합도)낮추기, 응집도 높이기
• 포괄적 개념 설계 후 세부 개념 구체화

• 모듈화
• 소프트웨어를 각 기능별로 분할
• 소프트웨어의 복잡도 감소
  
  
• 모듈의 속성
• 입출력 요소/ 기능 요소/ 기관요소/ 내부자료 요소
• 구성 - 호출, 피호출 모듈
  
  
• 모듈의 기능적 독립성
• 모듈의 기능이 독립 <-- 모듈화, 추상화, 정보은닉의 결과물
• 독립성 측정은 결합도(coupling)과 응집도(cohension) 바탕으로 이루어짐
• 높은 독립성 --> 낮은 결합도, 높은 응집도, 작은 크기의 모듈
  
  
• 결합도(coupling)
• 모듈 간의 상호 의존 정도, 혹은 연관 관게
• 결합도가 강하면 구현 및 유지보수가 어려움.
• 결합도 종류 (강함 ---> 낮은 순서)
• 내용 결합도 (아주강함)
• 한 모듈이 다른 모듈의 내부 기능 및 자료를 직접 참고
• 참고) 한 모듈에서 다른 모듈의 중간 지점으로 분기되는 경우에도 해당
• 공통 결합도
• 공유되는 공통데이터 영역을 여러 모듈이 사용할 때
• 공통 데이터가 변경되면 모든 모듈에 영향을 미침. 모듈의 독립성 저하
• 외부 결합도
• 모듈에서 외부로 선언한 변수를 다른 모듈에서 참조할 때
• 참조되는 데이터의 범위는 각 모듈에서 제한할 수 있음
• 제어 결합도
• 한 모듈에서 다른 모듈로 논리적 흐름을 제어하는 데 사용하는 제어 요소가 전달될 때
• 함수, 스위치, 태그, 플래그 등
• 상위 모듈에서 하위 모듈에 대한 이해가 필요. 기능이 두 모듈로 분리된 경우
• 스탬프 결합도
• 모듈 간 인터페이스로 자료구조(배열 등)가 전달될 때
• 두 모듈이 동일한 자료구조 조회. 자료구조의 변화가 다른 모듈에 영향 미침 (call by reference 느낌 ?)
• 자료 결합도 (아주 약함)
• 인터페이스가 자료 요소로만 구성
• 다른 모듈 호출 시 매개 변수 넘겨주고 결과값 돌려받음 (call by value 느낌 ?)
• 모듈 간의 내용을 전혀 알 필요 없는 상태. 모듈 변경이 다른 모듈에 영향 없음
  
  
  
  
• 응집도 (cohesion)
• 정보 은닉 개념의 확장
• 모듈 안의 요소들의 관련 정도. 모듈이 얼마나 독립적인 기능을 갖고 있는 지
• 응집도가 강하다 --> 모듈의 독립성이 높다
• 응집도 종류 (강함 --> 약함)
• 기능적 응집도 (매우 강함)
• 모듈 내 기능 요소가 단일 문제와 연관
• 순차적 응집도
• 모듈 내 하나의 처리로 나온 결과가 그 다음 처리 순서의 입력 데이터로 사용
• 교환(통신)적 응집도
• 동일한 입출력을 사용하여 서로 다른 기능을 수행하는 구성 요소가 모임
• 절차적 응집도
• 하나의 모듈이 다수의 관련 기능을 가질 때, 모듈 안의 구성 요소들이 기능을 순차적으로 수행할 경우
• 시간적 응집도
• 특정 시간에 처리되는 몇개의 기능을 모아 하나의 모듈로 작성
• 논리적 응집도
• 유사한 성격을 갖거나 특정 형태로 분류되는 요소들로 하나의 모듈 형성
• 우연적 응집도 (매우 약함)
• 모듈 내 요소가 관련이 없는 것들로 구성
  
  
• 효과적인 모듈화
• 낮은 결합도, 높은 응집도!
• 제어 영역 안에서 영향 영역 유지

출처: http://emzei.tistory.com/207 [emzei]