시스템 분석과 설계 정리 Ⅱ

기능모델링

소프트웨어 시스템은 입력된 정보를 여러 단계에 걸쳐 새로운 정보로 변환시킨 뒤 출력해 주는 것이다.

이렇게 시스템을 기능 관점에서 바라보고 시스템에서 요구되는 정보의 흐름과 변환을 나타낸 것을 기능 모델링이라고 한다.

 

구조적 분석 방법론은 도식적 기호를 이용하여 1979년 드마르코가 소개했다.

이는 현재 요구사항 분석에 가장 많이 활용하는 기법이다.

- 특징

매우 간결함 : 자료흐름도를 작성하기 위해서는 단지 네 개의 기호만이 필요하며 정보기술 전문가가 아니더라도 누구나 쉽게 직관적으로 도형의 의미를 이해할 수 있다.

- 이해하기 쉽다

자료흐름도뿐만 아니라 자료사전의 경우도 낯익은 기호들(= + [] () {}) 만으로 자료의 의미를 기술하기 때문에 문서를 이해하기 쉽고 누구라도 쉽게 작성할 수 있다.

- 검증이 가능하다

자료흐름도나 자료사전에 사용되는 자료명이나 입력 자료명 출력 자료명 등은 실제 현업에서 사용하고 있는 그대로를 사용하고 있으므로 도형에 표현된 자료흐름이 실제 흐름과 맞는지를 검증할 수 있다.

- 체계적이다

자료흐름도 자료사전 소단위 명세서는 서로 유기적으로 연관되어 작성되므로 시스템에 대한 체계적인 접근이 가능하다.

또한 자료흐름도나 자료사전은 하향식으로 작성되어 상위의 개략적인 도형에서 하위의 구체적인 도형으로 단계적으로 접근하며 이해할 수 있도록 작성된다.

 

 

동적모델링이란? 많은 시스템들은 입력에 대한 반응이 요구되는 시간 안에 이루어져야 하기 때문에 시간에 종속되어 있다.

이러한 시간과 변화의 관점에서 시스템을 묘사한 것이 바로 동적 모델링이다.

동적 모델링에는 시스템의 제어흐름 상호작용 동작의 순서를 다루는 내용이 포함되어 있다.

 

정보모델링이란? 시스템에 사용되는 정보 데이터를 중심으로 시스템의 정적인 정보구조를 나타내는 데 사용한다.

즉 시스템에 필요한 엔티티를 정의하고 이들 엔티티 사이의 연관성을 규명한다.

이 모델은 시스템의 기능이나 동작에 초점을 맞추기보다는 시스템을 구성하고 있는 객체를 중심으로 객체의 특성을 정의한다.

 

 

요구사항 조사 방법

관찰 조사 : 실제 현업부서를 방문하여 부서의 작업 환경 현업의 처리 절차 개선할 사항 등을 관찰하며 정량적인 정보를 수집한다.

질문지 조사 : 체계적으로 설계된 질문지를 이용해 필요한 정보를 수집하는 방법. (직접 관찰하거나 면담하기 어려운 부서나 담당자에게서도 손쉽게 정보를 수집할 수 있다)

면담 조사 : 시스템 분석가와 현업부서 담당자 간의 직접 대화를 통해 현행 시스템의 문제점 및 개선 요구사항 등을 파악할 수 있는 방법이다.

 

 

요구사항 조사 내용

조직에 대한 정보 : 조직의 연혁 조직도 업무 분장 및 규정 등을 수집 분석한다. 이러한 과정을 통해 시스템에 포함되어야 할 핵심적인 기능 및 처리 조건을 파악할 수 있다.

현재 사용 중인 제반 서식 : 부서에서 현재 사용 중인 제반 서식을 빠짐없이 수집 분석하는 절차는 매우 중요하다 이러한 서식은 결국 데이터베이스 설계 및 입력과 출력 설계의 기본이 되는 정보를 제공한다.

시스템 인프라 : 서버의 가용 자원 성능 등을 비롯하여 네트워크 구축 상태 및 데이터베이스 사용 등을 조사 분석한다.

이를 통해 새로운 시스템의 구축 및 운영에 적합한 자원이 마련되어 있는지를 알 수 있다.

현재 운영 중인 시스템 : 시스템의 지원 범위를 비롯하여 운영자 매뉴얼 등을 수집하여 분석할 뿐만 아니라 시스템의 문제점 보완점 등을 면밀히 분석한다.

 

 

[요구사항 명세서의 구성요소]

기능 요구사항 : 시스템이 구현해야 할 기능에 대한 요구 명세를 기술한다.

성능 요구사항 : 시스템이 수행할 응답시간 등의 성능에 대한 요구 명세를 기술한다.

인터페이스 요구사항 : 사용자의 편의성을 고려한 인터페이스와 인터넷 환경에서의 접근성 등에 대한 요구 명세를 기술한다.

운영 요구사항:  시스템 운영에 필요한 환경을 명시한다. 하드웨어 환경은 서버의 용량 성능 등을 의미하며 소프트웨어 환경은 OS버전 DB최대 동시 접속자수등을 의미한다.

자원 요구사항 : 운영에 필요한 자원의 제약 등에 대한 요구 명세를 기술한다.

검증 요구사항 : 시스템의 검증을 위한 조건 절차 검증 문서 등에 대한 요구 명세를 기술한다.

인수 테스트 요구사항 : 최종 사용자를 위한 인수 테스트의 조건 절차 등에 대해 요구 명세를 기술한다.

문서화 요구사항 : 사용자 매뉴얼 운영자 매뉴얼 등 시스템의 사용과 운영을 위해 필수적인 문서들에 대한 문서화 요구사항을 기술한다.

보안 요구사항 : 시스템의 안전한 운영을 위해 요구되는 보안 기능에 대한 요구 명세를 기술한다.

이식성 요구사항 : 시스템 설치에 필요한 조건 등에 대한 요구 명세를 기술한다.

품질 요구사항 : 시스템의 품질기준 및 지침을 제시하고 품질관리를 위한 절차 등에 대한 요구 명세를 기술한다.

신뢰성 요구사항 : 시스템의 제반 요구사항 가운데 신뢰성에 대한 요구사항의 중요성은 중대되고 있다.

유지보수성 요구사항 : 시스템의 개발비용과 더불어 운영에 따른 비용의 증가는 소프트웨어 위기를 자초한 커다란 이슈라고 할수 있다. 시스템의 유지보수성을 높이는 것은 소프트웨어 비중 증가를 최소화할 수 있는 방편이다.

안전 요구사항 : 소프트웨어 보안 요구사항이 시스템의 내부 사용자 및 외부 사용자로부터 보호를 목적으로 한 것이라면, 안전 요구사항은 시스템의 내부적 문제로부터 보호를 목적으로 한다. 즉 적절한 시점에서의 자료 백업 시스템 자원이 임계치에 도달했을 때의 적절한 초치 등은 안전을 위한 최소한의 요구라 할 수 있다.

 

 

구조적 분석 방법론 : 요던(Yourdon) 등에 의해 개발되어 보급된 이후 널리 사용된방법론이다. 하향식 기능 분해 기법을 사용하며 구조적 프로그래밍 기법에 활용된다.

구조적 분석의 기본원리 : 추상화 원칙, 정형화 원칙, 분할 정복의 개념, 계층적 구조의 개념 등의 네 가지 원리로 요약할 수있다.

모형화 도구의 특성 : 도형적 모형, 하향식 분할 모형, 최소 중복 모형, 투명적 모형, 다양한 모형 등으로 요약할 수 있다.

구조적 분석 모형화 도구 : 구조적 분석 방법론의 모형화 도구로는 자료흐름도 자료사전 소단위 명세서등 세 가지가 있다.

구조적 분석 절차 : 현 물리적 모형화 -> 현 논리적 모형화 -> 신 논리적 모형화 -> 신 물리적 모형화

 

 

자료흐름도 : 구조적 분석 방법론의 모형화 도구 중 가장 보편적으로 사용되는 자료흐름도는 네 가지 심볼만으로 작성할 수 있으며 시스템 개발자와 사용자의 커뮤니케이션을 용이하게 해준다.

자료흐름도 구성요소 : 처리, 자료흐름, 자료저장소, 단말 등이 있다.

자료흐름도 작성 원칙 : 자료 보존의 원칙, 최소 자료 입력의 원칙, 독립성의 원칙, 지속성의 원칙, 순차 처리의 원칙, 영구성의 원칙, 자료 변환의 원칙 등이 있다.

자료흐름도의 작성 절차 : 시스템 경계의 입출력을 식별한 후 시스템 경계 내부의 작성 자료흐름의 명명 처리의 명명 순으로 진행된다.

자료흐름도 작성 시 주의사항 : 초기화와 종료화는 고려하지 않는 것이 일반적이며 사소한 오류는 생략한다. 제어흐름은 표시하지 않는게 원칙이다.

자료흐름도 검토 및 개선 : 자신이 직접 다양한 사례들을 작성해 보며 반복적인 검토와 개선을 하다 보면 만족할만한 결과를 얻을 수 있게 된다.

 

 

자료사전 : 자료흐름도에 나타난 모든 자료에 대한 정의를 기술한 문서로써 구조적 분석 방법론에서 자료 흐름도 소단위 명세서와 더불어 중요한 분석 문서 중 하나이다.

자료사전에 기술해야 할 자료 : 자료흐름을 구성하는 자료항목 자료저장소를 구성하는 자료항목 자료원소의 단위 및 값 뿐만 아니라 그 의미 등을 기술한다.

자료의 하향식 분할 : 자료사전을 기술할 때는 하향식 분할원칙에 맞추어 구성요소를 재정의하는 방법이 이해도를 높이는데 좋다.

자료사전 기호 : = 정의 + 구성 {} 반복 [|] 선택 () 생략 가능 * * 주석 등이 있다.

 

 

소단위 명세서 : 소단위 명세서를 작성하는 목적은 자료흐름도에 표시된 처리에 대한 상세한 절차를 표현하기 위함이다.

자료흐름도상 처리 수만큼 소단위 명세서가 필요하다.

소단위 명세서는 자료흐름도의 최하위 단계 분할도를 대상으로 작성하며, 한 페이지 이내의 크기로 정의할 수 있어야 적절한 분할이 이루어졌다고 볼 수 있다.

구조적 언어 : 자연어의 특성과 구조적 프로그래밍 특성 중 장점을 채택해 제한된 언어를 사용해 제한된 문형과 제한된 구조로 작성하는 특징이 있다.

* 구조적 언어의 제한된 구조는 순서 선택 반복으로 표현한다.

의사결정표 : 복잡한 조건에 따라 다양한 처리가 가능한 경우에는 의사결정표를 활용하는 것이 바람직하다.

 

 

소단위 명세서 작성

이용자 등록

BEGIN

1.1 이용자 등록 신청서의 소속대학명, 신분구분, 코드, 성명을 읽는다

1.2 신분확인상태 = FALSE

1.3 IF 신분구분 = "재학생" OR 신분구분 = "동문" THEN

1.3.1 IF 소속대학별 학적 DB의 학번 = 코드 AND 학적 DB의 성명 = 성명 THEN

1.3.1.1 신분확인상태 =  TRUE

ENDIF

ENDIF

.... 방식으로 진행

 

 

방법론의 필요성 : 방법론의 도입 목적은 작업방법의 표준화 커뮤니케이션 향상 정보시스템 품질 수준의 목표달성 프로젝트 위험의 최소화 주어진 기간과 비용 내에서 시스템 완성 등으로 요약할 수 있다.

정보공학 방법론 : 기업 전체의 관점에서 기업 활동을 기업모델로 분석하고 이를 다이어그램 형태로 표현하여 정보시스템의 계획 분석 설계 구축 등의 전 과정을 공학적으로 적용한 방법론이다.

관계형 DB 설계 과정 : 엔티티 정의, 관계 정의, 식별자 정의, 속성 정의, 정규화 등으로 나누어 단계적으로 진행된다.

엔티티 : 하나 이상의 속성을 가지며 구별이 가능하도록 식별자를 가져야 하고 다른 엔티티와 관계를 가지는 유용한 정보를 제공해야 한다.

식별자 : 한 엔티티 내의 특정 인스턴스를 구분할 수 있는 단일속성 또는 속성 그룹을 의미한다.

 

 

소프트웨어 품질 : 제품에 대한 사용자의 요구사항을 충족시켜줄 뿐만 아니라 결함이 없는 소프트웨어를 보충한다.

소프트웨어 품질요인 : 효율성 융통성 무결성 상호운용성 유지보수성 이식성 신뢰성 정확성 재사용성 테스트용이성 사용용이성 등이 있다.

소프트웨어 품질 목표 : ISO가 제시한 소프트웨어 품질목표로는 기능성 신뢰성 사용성 효율성 유지보수성 이식성 등이 있다.

소프트웨어 품질공학의 구조 : 최상위 품질목표와 하위 계층에는 품질기준이 있으며 각각의 품질기준을 측정하기 위한 체크리스트 항목으로 구성되어 있다.

소프트웨어 품질보증 : 소프트웨어의 품질보증을 위한 절차는 소프트웨어의 개발 생명주기 전 과정에 걸쳐 이루어져야 하며 사용자가 원하는 올바른 제품을 만들고 있는지를 검사하는 검증과 각 단계에서 산출된 산출물이 바로 이전 단계의 산출물과 일치하는지를 결정하는 확인 등으로 구별된다.