미새문지

이전 글에 이어서 3. 물리 데이터 모델링 설계 단계에서 시스템의 설계적 및 정보 요건을 정확하고 완전하게 표현한 모델 (1) 데이터베이스 생성을 위한 물리구조로 변환한다 (2) 시스템 설계 요건 반영을 위해 아래와 같은 오브젝트를 추가한다 - 설계용 엔터티 타입 - 설계용 속성 (3) 설계와 성능을 고려한 조정을 수행한다 - 적용 DBMS 특성 고려 - 엔터티 타입의 분리 또는 통합 검토 - 반 정규화(Denormalization) - 관계의 해제 (4) 적용 DBMS에 적합한 성능조정을 수행한다 - 인덱스 추가 및 조정 - 테이블 스페이스 조정 - 인덱스 스페이스 조정 물리 데이터 저장소 설계 물리 데이터모델 설계 - 물리 데이터 모델링은 논리모델을 적용하고자 하는 기술에 맞도록 상세화 해가는 과정이..

논리 데이터모델 검증 일반적인 시스템 개발 절차 - 일반적으로 시스템 개발은 데이터 관점과 프로세스 관점의 두 가지로 진행되는데, 개념모델링을 통해 개발 범위를 파악, 업무중심의 분석단계를 거쳐 개발하고자 하는 환경을 고려한 설계단계로 구체화 되어 개발된다 데이터 모델링이란? - 기업의 정보 구조를 실체(Entity)와 관계(Relation)를 중심으로 명확하고 체계적으로 표현해 문서화하는 기법 데이터 모델링의 목적 (1) 연관 조직의 정보요구에 대한 정확한 이해가 가능 (2) 사용자, 설계자, 개발자 간에 효율적인 의사소통 수단을 제공한다 (3) 데이터 체계 구축을 통한 고품질 S/W와 유지보수 비용의 감소효과를 기대할 수 있다 (4) 신규 또는 개선 시스템의 개발 기초를 제공한다 데이터 모델링의 특성..

1. 분석 모델의 기술적 타당성 검토 - 유스케이스 모델의 개별 유스케이스에 대한 분석모델을 작성한 후, 해당 분석모델로 시스템을 개발할 때 어떤 영향을 미치는지 필요한 자원, 상호 운용성, 시장 성숙도, 기술적 위험 분석 측면에서 타당성을 조사한다 [성능 및 용량산정 적정성] -> [시스템 간 상호 운용성] -> [IT시장 성숙도 및 트렌드 부합성] -> [기술적 위험분석] 1. 성능 및 용량 - 요구사항을 만족시키기 위해 분석모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원을 식별한다 - 분석 클래스에서 불필요하거나 지나치게 많은 속성들을 포함시키면 객체 생성시 시스템의 메모리 자원을 많이 요구하게 되어, 전체 시스템의 성능 저하가 발생한다 2. 시스템간 상호 운용성 - 분석모델을 이용해 보다 ..

1. 검증 방법 - 사업 유형이 시스템 개발, 감리시점이 요구 분석, 감리영역이 응용시스템인 경우 "유스케이스 모형 상세화 수준 및 적정성"과 "개념수준의 분석클래스 도출"에 관한 점검 항목을 기준으로 검증한다 - 감리시점이 분석설계, 감리영역이 응용시스템인 경우 "유스케이스로부터 분석 클래스 도출 및 상세화"에 관한 점검항목을 기준으로 검증한다 2. 유스케이스 모델 검증 - 한국정보화진흥원의 정보시스템 감리지침에서는 시스템기능에 대한 유스케이스 모형 상세화 수준 및 적정성에 대해 다음과 같은 사항을 점검하도록 하고 있다 더보기 3. 개념수준의 분석 클래스 검증 - 시스템의 주요 도메인개념을 분석 클래스로 도출하여 유스케이스 분석에 활용하므로, 개념수준의 주요 분석 클래스를 적절히..

요구사항 확인 분석가가 요구사항을 이해했는지 확인하는 것이 필요하고, 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고 완전한지 검증하는 것이 중요하다 - 문서를 검토하고 요구사항 정의 문서들에 대해 형상관리를 해야 하기 때문에 일반적으로 요구사항 관리툴을 이용한다 - 리소스가 요구사항에 할당되기 전에 문제를 파악하기 위해 검증을 수행함 요구사항 확인 기법 (1) 요구사항 검토(Requirement Reviews) - 요구사항 검증의 가장 일반적인 방법으로, 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 등을 찾아내는 작업을 수행한다 - 예로 들면 고객중심 프로젝트에서는 검토자 그룹에 고객 대표자가 1명이상 포함되어야 한다 - 검토는 시스템 정의서, 시스템 사양서, 소프트웨어 ..

요구사항 분석 기법 요구사항 분석을 통해 요구사항을 기술할 때에는 - 요구사항의 확인 - 요구사항 구현의 검증 - 비용 추정 의 작업들이 가능하도록 충분하고 정확하게 기술하여야 한다 분석기법으로는 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석 등이 있다 1. 요구사항 분류(Requirement Classification) 요구사항을 다음과 같은 기준으로 분류 - 기능인지 비기능인지 분류 - 하나 이상의 고수준 요구사항으로부터 유도된 것인지 또는 이해관계자나 다른 원천으로부터 직접 발생한 것인지 - 제품에 관한 것인지 프로세스에 관한 것인지 - 우선순위가 더 높은 것인지의 여부 - 요구사항의 범위 - 소프트웨어 생명주기 동안에 변경이 발생하는지의 여부 < 비기능 요구사항의 분류 ..

요구공학 정의 요구공학이란 요구사항을 정의하고, 문서화하고, 관리하는 프로세스를 의미한다 ( 1 ) 요구사항 도출(Requirement Elicitation) - 소프트웨어가 해결해야 할 문제를 이해하는 첫 단계로 요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련되어 있다 - 이 단계에서 이해관계자가 식별되고, 개발 팀과 고객 사이의 관계가 만들어진다 - 이 단계에서는 다양한 이해관계자와 효율적인 의사소통이 중요하다 ( 2 ) 요구사항 분석(Requirement Analysis) - 요구사항들 간 상충되는 것을 해결, 소프트웨어의 범위를 파악, 소프트웨어가 환경과 어떻게 상호 작용하는지 이해하는 단계이다 - 시스템 요구사항을 정제하여 소프트웨어 요구사항을 도출한다 ( 3..

1. 기술 환경 정의를 위한 자료를 수집한다 - 수집할 자료의 목록을 정하고, 자료를 수집하기 위해 현행 시스템 담당자가 제시 한 자료와 면담 기록에 필요 자료의 존재 여부를 파악한다 - 시스템 사용 현황 파악을 위해 밑 표와 같은 자료를 조사한다 항목 설명 시스템 용도 및 서비스 형태 웹 페이지만 제공, 트랜잭션이 빈번하지 않은 웹 서비스, 트랜잭션이 빈번한 웹 서비스 시스템의 구성 형태 1계층, 2계층, 3계층 접속자 수 평균 접속자 수(24시간 기준), 최고 접속자 수(1시간), 연간 접속자 증가율 사용률 동시 사용자 수, 사용자당 오퍼레이션 수, 이미지 파일과 사운드 파일의 크기, 웹 페이지 크기, 허용 응답 시간 업무 중요도 및 긴급도 중요도(상중하), 긴급도(상중하) 백 엔드 상호 작용 형태 ..