New 병아리 개발자

*논리 데이터 모델 검증

1. 논리 데이터 모델링

- 데이터베이스 설계 프로세스의 기초 설계 단계로 비즈니스 정보의 구조와 규칙을 명확하게 표현할 수 있는 기법이다.

- 개념 모델로부터 업무 영역의 업무 데이터 및 규칙을 구체적으로 표현한 모델이다.

2. 논리 데이터 모델링 특성

- 논리 데이터 모델링의 특징으로는 포용성, 정규화, 완전성, 독집성을 가진다.

- 정규화 : 모든 데이터를 정규화하여 모델링

- 포용성 : 모든 엔티티 타입, 속성, 관계, 프로세스 등을 포함

- 완전성 : 모든 규칙과 관계를 완전하고 정확하게 표현

- 독립성 : 성능, 제약사항에 독립적인 모델, 특정 DBMS로부터 독립적인 성질

3. 논리 데이터 모델링 속성

- 논리 데이터 모델링의 속성은 개체, 속성, 관계로 구성된다.

- 개체 : 관리할 대상이 되는 실체

- 속성 : 관리할 정보의 구체적 항목

- 관계 : 개체 간의 대응 관계

4. 개체-관계(E-R) 모델

- 현실 세계에 존재하는 데이터와 그들 간의 관계를 사람이 이해할 수 있는 형태로 명확하게 표현하기 위해 가장 널리 사용되고 있는 모델이다.

- 논리 데이터 모델링에서는 모든 이해당사자와 의사소통의 보조 자료로 E-R모델을 활용한다.

- 요구사항으로부터 얻어낸 정보들을 개체, 속성, 관계로 기술한 모델이다.

4-1. 개체-관계(E-R) 다이어그램 기호

- 개체 : 사각형 ( □ )

- 관계 : 마름모 ( ◇ )

- 속성 : 타원 ( ○ )

- 다중 값 속성 : 이중 타원 ( ◎ )

- 관계-속성 연결 : 선  ( - )

5. 정규화

- 관계형 데이터베이스의 설계에서 중복을 최소화하여 데이터를 구조화하는 프로세스이다.

5-1. 이상 현상 (Anomaly)

- 데이터의 중복성으로 인해 릴레이션을 조작할 때 발생하는 비합리적 현상이다.

- 삽입, 삭제, 갱신 이상이 있다.

- 삽입 이상 : 정보 저장 시 해당 정보의 불필요한 세부정보를 입력해야 하는 경우

- 삭제 이상 : 정보 삭제 시 원치 않는 다른 정보가 같이 삭제되는 경우

- 갱신 이상 : 중복 데이터 중 특정 부분만 수정되어 중복된 값이 모순을 일으키는 경우

5-2. 정규화의 단계

- 1정규형 (1NF) : 원자값으로 구성

- 2정규형 (2NF) : 부분 함수 종속 제거 (완전 함수적 종속 관계)

- 3정규형 (3NF) : 이행함수 종속 제거

- 보이스-코드 정규형 (BCNF) : 결정자 함수이면서 후보키가 아닌 것 제거

- 4정규형 (4NF) : 다치 종속성 제거

- 5정규형 (5NF) : 조인 종속성 제거

*분석 모델의 시스템화 타당성 분석

- 업무 분석가가 제시한 분석 모델이 개발할 응용 소프트웨어에 미칠 영향을 검토하여 기술적인 타당성 조사를 하는 활동이다.

1. 분석 모델의 기술적 타당성 검토

- 유스케이스 모델의 개별 유스케이스에 대한 분석 모델을 작성한 후, 해당 분석 모델로 시스템을 개발할 경우에 대한 영향을 필요한 자원, 상호 운용성, 시장 성숙도, 기술적 위험 분석 측면으로 타당성 조사를 한다.

- 성능 및 용량 산정의 적정성 : 요구사항을 만족시키기 위한 분석 모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원 식별. 분석 클래스에서 불필요하고 지나치게 많은 속성들을 포함시키게 되면 객체 생성 시 시스템의 메모리 자원이 많이 요구되며, 전체 시스템의 성능 저하가 발생한다.

- 시스템 간 상호 운용성 : 분석 모델을 이용하여 보다 구체적으로, 시스템 간 상호 정보 및 서비스가 교환 가능한지 검토. 분석 모델에서 정의한 구체적인 정보의 존재 여부, 생성 가능성, 교환 방식 지원 등에 대해서 확인한다.

- IT 시장 성숙도 및 트렌드 부합성 : 분석 모델이 과거의 문제를 해결하고 최근 많이 사용되는 트렌드에 부합되는지 확인. 분석 자동화 도구 활용 방안 고려.

- 기술적 위험 분석 : 분석 모델이 시스템의 기술 구조, 프레임워크, 사용되는 하드웨어 및 소프트웨어와 부합되는지 확인. 분석 모델이 검증되지 않은 기술의 사용을 가정으로 하고 있어 추가적인 비용 발생 가능성이 있는지 확인. 분석 모델을 구현하기 위해 특정 업체의 기술, 특허, 라이선스에 의존해야 하는지 확인한다.

2. 분석 모델의 시스템화 타당성 분석 프로세스

- 타당성 검토의견 컬럼 추가 : 분석 모델까지 요구사항 추적표를 작성하고, 타당성 검토의견 컬럼을 추가한다.

- 타당성 검토의견 작성 : 작성된 요구사항 추적표에 타당성 검토의견 작성. 타당성 검토의견을 제외한 나머지 속성들은 분석 모델 검증 수행 내용의 작성 절차와 동일하다. 유스케이스 모델, 개념 수준 분석 클래스 모델, 분석 클래스 모델의 기술적 타당성 검토를 위해 필요 지식에 명시된 바와 같이 성능 및 용량, 시스템 간 상호 운용성, 시장 성숙도 및 트렌드 부합성, 기술적 위험 분석을 참조하여 검토의견을 작성한다.

- 타당성 분석 결과 검증 : 타당성 분석 결과를 관련 이해관계자에게 배포하여 사전 검토를 요청. 관련 이해관계자가 모여 분석 모델 타당성 분석 결과를 검증. 타당성 분석 결과에 이견이 있는 경우 프로젝트 관리자의 중재 하에 합의를 도출한다.

- 타당성 분석 결과 확인 및 배포/공유 : 이해관계자가 검증을 거친 타당성 분석 결과를 의사 결정자 확인. 확정된 타당성 분석 결과를 이해관계자에게 배포하여 공유한다.

*분석 모델 검증

- 분석 모델 검증이란 요구사항 도출 기법을 활용하여 업무 분석가가 제시한 분석 모델에 대해 확인하는 활동이다.

1. 분석 모델 검증 방법

- 유스케이스 모델 검증 : 시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성 검증을 위해서 액터, 유스케이스, 유스케이스 명세서 점검을 진행한다.

- 개념 수준의 분석 클래스 검증 : 시스템의 주요 도메인 개념을 분석 클래스로 도출하여 유스케이스 분석에 활용하므로, 개념 수준의 주요 분석 클래스를 적절히 도출하였는지, 관련 정보가 명확한지 점검한다. 주요 클래스 도출 여부, 도출된 클래스 이름과 속성의 적절성, 올바른 클래스들 간의 관계 여부 점검

- 분석 클래스 검증 : 유스케이스 실현에 필요한 분석 클래스 도출 확인. 유스케이스 별로 도출된 분석 클래스들이 스테레오 타입으로 표시되었는지 확인. 경계와 제어 클래스의 도출 여부 및 상세화 정도 확인. 클래스 간의 관계, 클래스 정보의 상세화 정도를 확인 한다.

1-1. 분석 클래스의 스테레오 타입

- 경계 (Boundary) : 시스템과 외부 액터와의 상호작용을 담당하는 클래스

- 엔티티 (Entity) : 시스템이 유지해야 하는 정보를 관리하는 기능을 전담하는 클래스

- 제어 (Control) : 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스

- 스테레오 타입을 통해 분석 클래스 검증을 한다.

2. 분석 모델 검증 프로세스

- 검토의견 컬럼 추가 : 분석 모델까지 요구사항 추적표를 작성하고 검토의견 컬럼 추가

- 검토의견 작성 : 요구사항 목록을 참조하여 요구사항 ID와 요구사항명 입력. 유스케이스 모델에 대한 검토의견 작성. 개념 수준의 분석 클래스 모델에 대한 검토의견 작성. 분석 클래스 모델에 대한 검토의견 작성

- 검토의견 정제 : 요구사항 추적표에서 요구사항에 대한 검토의견 정제. 누락된 유스케이스 모델/개념 수준 분석 클래스/분석 클래스가 존재하는 경우, 검토의견 추가

*비용산정 모델

1. 비용산정 모델이란

- 소프트웨어 규모 파악을 통한 투입자원, 소요 시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 기법이다.

2. 비용산정 모델의 분류

- 하향식 산정방법 : 경험이 많은 전문가에게 비용산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식이다. 종류에는 전문가 판단, 델파이 기법이 있다.

- 상향식 산정방법 : 세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식이다. 종류에는 코드 라인 수(Loc), Man Month, COCOMO 모형, Putnam 모형, FP(Function Point) 모형이 있다.

3. 하향식 비용산정 모델

3-1. 전문가 판단

- 조직 내에 있는 경험이 많은 두 명 이상의 전문가에게 비용산정을 의뢰하는 기법이다.

3-2. 델파이 기법

- 전문가의 경험적 지식을 통한 문제해결 및 미래 예측을 위한 기법이다.

- 전문가들의 편견이나 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성한다.

- 전문가들은 익명으로 의견을 제출 및 비용을 산정하고, 조정자는 전문가들의 의견을 요약하여 배포하면, 전문가들은 조정자가 요약한 의견을 보고 다시 익명으로 의견을 제출 및 비용을 산정ㅎ한다. 전문가들 간의 의견과 산정된 비용이 거의 일치할 때까지 과정을 반복한다.

4. 상향식 비용산정 모델

4-1. LoC (Lines of Code)

- 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정한다.

- 측정이 쉽고 이해하기 쉬워 많이 사용되며, 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정한다.

- 예측치 = (낙관치 + (4 * 중간치) + 비관치) / 6

(비관치 : 가장 많이 측정된 코드 라인 수 / 중간치 : 측정된 모든 코드 라인 수의 평균 / 낙관치 : 가장 적게 측정된 코드 라인 수)

4-2. Man Month

- 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 기법

- Man Month = LoC / 프로그래머의 월간 생산량

- 프로젝트 기간 = Man Month / 프로젝트 인력

4-3. COCOMO (COnstructive COst MOdel)

- 보헴이 제안, 프로그램 규모에 따라 비용을 산정한다.

- 개발 노력 승수를 결정한다.

- COCOMO 유형에는 규모에 따라 단순형, 중간형, 임베디드형으로 나뉜다.

- 단순형 (Organic Mode) : 기관 내부에서 개발된 중, 소규모의 소프트웨어로 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리 개발에 적용된다. 5만( 50 KDSI : 소스 코드를 1,000라인으로 묶은 단위 ) 라인 이하의 소프트웨어를 개발하는 유형

- 중간형 (Semi-Detached Mode) : 단순형과 임베디드형의 중간형이다. 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 개발에 적용한다. 30만( 300KDSI ) 라인 이하의 소프트웨어를 개발하는 유형

- 임베디드형 (Embedded Mode) : 초대형 규모의 트랜잭션 처리 시스템이나 운영체제 개발에 적용한다. 30만( 300KDSI ) 라인 이상의 소프트웨어를 개발하는 유형

4-4. 푸트남 (Putnam) 모형

- 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 모형이다. 자동화 추정 도구로 SLIM이 있다.

4-5. 기능점수 (FP : Function Point) 모형

- 요구 기능을 증가시키는 인자별로 가중치를 부여하여 기능 점수를 계산하여 비용을 산정하는 방식이다.

- 입력, 출력, 질의, 파일, 인터페이스의 개수로 소프트웨어의 규모를 표현한다.

- 원시 코드의 구현에 이용되는 프로그래밍 언어에 독립적이다.

- 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여한다.

- 프로젝트의 영향도와 가중치의 합을 이용하여 기능점수를 계산한다.

- 정규법 : 각 기능의 속성을 정의하여 기능별 복잡도 매트릭에 의한 기능 점수를 산정하는 방식으로 상세한 기능점수 측정이 가능하다.

- 간이법 : 개략적인 사용자 요구사항을 바탕으로 기능점수를 도출하여 평균 복잡도에 의한 기능점수를 산정하는 방식으로 프로젝트 초기에 개발 비용 측정이 가능하다.