구조화된 시스템 분석 및 설계 방법

Structured systems analysis and design method

원래 방법론으로 발표된 구조화된 시스템 분석 및 설계 방법(SSADM)은 정보 시스템의 분석 및 설계에 대한 시스템 접근방식이다. SSADM은 1980년부터 정부의 기술 사용과 관련된 영국 정부 기관인 중앙 컴퓨터 통신국을 위해 생산되었다.

개요

SSADM은 정보시스템의 분석과 설계를 위한 폭포수법이다. SSADM은 시스템 설계에 대한 엄격한 문서 주도 방식의 정점을 나타낸다고 생각할 수 있으며, DSDM 또는 Scrum과 같은 보다 현대적인 민첩한 방법과 대조된다.

SSADM은 피터 체클랜드의 소프트 시스템 방법론, 래리 콘스탄티누스의 구조 설계, 에드워드 유던의 유던 구조화 방법론, 마이클 A와 같은 구조화 분석 및 개발 방법의 여러 학교의 작업을 기반으로 구축된 하나의 특별한 구현이다. 잭슨의 잭슨 구조 프로그래밍과 톰 드마코의 구조 분석.

'구조화된 시스템 분석 및 설계 방법'과 'SSADM'이라는 명칭은 영국 재무부의 사무소인 OGC(Office of Government Commerce)의 등록 상표다.[1]

역사

구조화 시스템 분석 및 설계 방법론 개발의 주요 단계는 다음과 같다.[2]

  • 1980: 중앙 컴퓨터통신국(CCTA)은 분석 및 설계 방법을 평가한다.
  • 1981: John Hall이 이끄는 Learmonth & Burchett Management Systems에서 일하는 컨설턴트들이 SSADM v1을 개발하도록 선택됨.
  • 1982: John Hall과 Keith Robinson은 Model Systems Ltd를 찾기 위해 떠났고, 후에 LBMS는 그들의 소유 버전인 LSDM을 개발했다.
  • 1983: SSADM은 모든 새로운 정보 시스템 개발에 대해 의무화됨
  • 1984: SSADM 버전 2 출시
  • 1986: NCC에서 채택한 SSADM 버전 3
  • 1988: SSADM 숙련도 인증서 출시, SSADM을 '개방형' 표준으로 승격
  • 1989: Euromethod, CASE 제품 인증제 출시
  • 1990: 버전 4 출시
  • 1993: SSADM V4 표준 및 도구 적합성 체계
  • 1995: SSADM V4+ 발표, V4.2 출시
  • 2000: CCTA는 SSADM을 "비즈니스 시스템 개발"로 변경했다. 이 방법은 15개의 모듈로 다시 포장되었고 6개의 모듈이 추가되었다.[3][4]

SSADM 기술

SSADM에서 사용되는 가장 중요한 세 가지 기법은 다음과 같다.

논리적 데이터 모델링
설계 중인 시스템의 데이터 요구사항을 식별, 모델링 및 문서화하는 프로세스. 그 결과는 기업(기업이 정보를 기록해야 하는 사항), 속성(기업들에 대한 사실), 관계(기업들 간의 관계)를 포함하는 데이터 모델이다.
데이터 흐름 모델링
정보 시스템 주위에서 데이터가 이동하는 방식을 식별, 모델링 및 문서화하는 프로세스. 데이터 흐름 모델링은 프로세스(데이터를 한 형태에서 다른 형태로 변환하는 활동), 데이터 저장소(데이터를 보관하는 영역), 외부 개체(데이터를 시스템으로 보내거나 시스템에서 데이터를 수신하는 경로) 및 데이터 흐름(데이터가 흐를 수 있는 경로)을 검사한다.
도면요소 사건 모델링
두 가닥으로 된 프로세스: 기업 행동 각 기업 및 이러한 사건이 발생하는 순서(또는 인생 이력)에 영향을 미치는 사건을 모델링, 식별, 모델링 및 문서화하고, 각 사건에 대해 기업 수명 이력을 조정하는 과정을 설계하는 이벤트 모델링.

단계

SSADM 방법은 다음과 관련된 일련의 분석, 문서화 및 설계 작업의 적용을 포함한다.

0단계 – 타당성 조사

주어진 사업의 실현 가능 여부를 판단하기 위해서는 사업의 목표와 시사점에 대한 조사 형태가 있어야 한다. 소규모 프로젝트의 경우 프로젝트의 범위를 쉽게 이해할 수 있기 때문에 이것은 전혀 필요하지 않을 수 있다. 더 큰 프로젝트에서, 실현 가능성은 이루어질 수 있지만, 비공식적인 의미로는, 공식적인 연구를 할 시간이 없기 때문이거나, 프로젝트가 "필수적"이기 때문에, 그리고 어떻게 해서든 이루어져야 할 것이기 때문이다. 데이터 흐름도는 현재 시스템의 작동 방식을 설명하고 알려진 문제를 시각화하는 데 사용된다.

타당성 조사를 실시할 때 고려해야 할 분야는 크게 네 가지다.

기술 – 기술적으로 프로젝트가 가능한가?
재무 – 기업이 프로젝트를 수행할 여유가 있는가?
조직 – 새로운 시스템이 기존 관행과 호환될 것인가?
윤리적 – 새로운 시스템의 영향이 사회적으로 용인될 수 있는가?

이러한 질문에 답하기 위해 타당성 조사는 사실상 포괄적인 시스템 분석 및 설계의 축약형 버전이다. 요구사항과 사용 현황은 어느 정도 분석되며, 일부 비즈니스 옵션은 작성되며, 심지어 기술 구현의 세부사항도 작성된다. 이 단계의 산물은 공식적인 타당성 조사 문서다. SSADM은 연구가 포함되어야 하는 섹션에 구성된 모든 예비 모델과 거부된 옵션의 세부사항 및 거부 이유를 명시한다.

1단계 – 현재 환경 조사

SSADM 개발자들은 거의 모든 경우에, 비록 그것이 완전히 사람과 종이로 구성된다 하더라도 현재의 시스템에는 어떤 형태가 있다는 것을 이해했다. 분석가는 면접 직원, 순환 설문지, 관찰 및 기존 문서 등의 조합을 통해 프로젝트의 시작 단계와 마찬가지로 시스템을 완전히 이해하게 된다. 이것은 많은 목적에 도움이 된다(예시처럼?).

2단계 – 비즈니스 시스템 옵션

현재의 시스템을 조사한 후, 분석가는 새로운 시스템의 전반적인 설계를 결정해야 한다. 이를 위해 이전 단계의 출력을 이용하여 일련의 비즈니스 시스템 옵션을 개발한다. 이것들은 아무것도 하지 않는 것에서부터 낡은 시스템을 완전히 버리고 완전히 새로운 시스템을 구축하는 것에 이르기까지 새로운 시스템이 만들어질 수 있는 다른 방법들이다. 분석가는 가능한 많은 다양한 아이디어가 창출되도록 브레인스토밍 세션을 열 수 있다.

그런 다음 아이디어는 사용자에게 제공되는 옵션에 수집된다. 옵션은 다음을 고려한다.

  • 자동화 정도
  • 시스템과 사용자 사이의 경계
  • 예를 들어, 시스템의 분배는 하나의 사무실로 집중화 되어 있는가, 아니면 여러 곳에 분산되어 있는가?
  • 비용/비용
  • 새 제도의 영향

필요한 경우 옵션을 논리적 데이터 구조와 수준 1 데이터 흐름도로 문서화한다.

사용자와 분석가가 함께 단일 비즈니스 옵션을 선택하십시오. 이는 이미 정의된 옵션 중 하나일 수도 있고 기존 옵션의 다른 측면을 종합한 것일 수도 있다. 이 단계의 산출물은 모든 타당성 단계의 산출물과 함께 선택된 단일 사업 옵션이다.

3단계 – 요구 사항 사양

이것은 아마도 SSADM에서 가장 복잡한 단계일 것이다. 분석가는 1단계에서 개발된 요구사항을 사용하고 선택된 비즈니스 옵션의 프레임워크 내에서 작업함으로써 새로운 시스템이 해야 할 일에 대한 완전한 논리적 규격을 개발해야 한다. 규격에는 오류, 모호성 및 불일치가 없어야 한다. 논리적으로, 우리는 명세서가 시스템이 어떻게 구현될 것인지 말하는 것이 아니라 시스템이 무엇을 할 것인지를 기술한다는 것을 의미한다.

논리적 규격을 생산하기 위해 분석가는 데이터 흐름도(DFD)와 논리적 데이터 모델(LDM) 모두를 위해 필요한 논리 모델을 구축하며, 논리적 데이터 구조(다른 방법에서는 엔티티 관계 다이어그램이라고 함)와 데이터 및 그 관계에 대한 완전한 설명을 구성한다. 이것들은 사용자가 시스템에 요구할 모든 기능의 기능 정의, 기업의 수명을 통하여 모든 사건을 기술하는 기업생명사(ELHs), 그리고 각 사건이 모든 관련 기업과 어떻게 상호작용하는지를 기술하는 효과 대응도(ECDs)를 작성하는 데 사용된다. 이러한 요구사항은 요구사항과 지속적으로 일치하며 필요한 경우 요구사항을 추가 및 완료한다.

이 단계의 제품은 다음과 같이 구성된 완전한 요구사항 명세서 문서다.

  • 업데이트된 자료 목록
  • 갱신된 요구 사항 목록
  • 다음으로 구성되는 처리 사양
  • 사용자 역할/기능 매트릭스
  • 함수 정의
  • 필요한 논리 데이터 모델
  • 실생활사.
  • 통신 도표를 작성하다.

4단계 – 기술 시스템 옵션

이 단계는 새로운 시스템의 물리적 구현을 향한 첫 번째 단계다. 비즈니스 시스템 옵션과 마찬가지로, 이 단계에서는 새로운 시스템 구현을 위한 많은 옵션이 생성된다. 이는 최종 옵션을 선택하거나 합성하는 사용자에게 표시하기 위해 두 개 또는 세 개로 좁혀진다.

그러나 고려사항들은 다음과 같이 상당히 다르다.

  • 철물 구조
  • 사용할 소프트웨어
  • 시행 비용
  • 필요한 인력
  • 시스템이 점유하고 있는 공간과 같은 물리적 한계
  • 필요한 네트워크를 포함한 배포
  • 인간 컴퓨터 인터페이스의 전체적인 형식

또한 이러한 모든 측면은 가용 자금과 하드웨어 및 소프트웨어의 표준화 등 기업이 부과하는 제약조건에 부합해야 한다.

이 단계의 출력은 선택된 기술 시스템 옵션이다.

5단계 – 논리적 설계

이전 레벨은 구현의 세부사항을 명시하지만, 이 단계의 산출물은 구현에 독립적이며 인간 컴퓨터 인터페이스의 요건에 집중한다. 논리 설계는 메뉴 구조와 명령 구조 측면에서 주요 상호작용 방법을 지정한다.

활동 영역 중 하나는 사용자 대화 상자의 정의다. 이것들은 사용자들이 시스템과 상호작용하는 주요 인터페이스들이다. 다른 활동은 시스템 업데이트에 있어 이벤트의 영향과 시스템에 대한 데이터에 대한 문의의 필요성 모두를 분석하는 것과 관련이 있다. 이 두 가지 모두 3단계에서 생성된 이벤트, 기능 설명 및 효과 대응 다이어그램을 사용하여 일관되고 안전한 방식으로 데이터를 업데이트하고 읽는 방법을 정밀하게 결정한다.

이 단계의 산물은 다음과 같이 구성된 논리적 설계다.

  • 데이터 카탈로그
  • 필요한 논리적 데이터 구조
  • 논리적 프로세스 모델 - 업데이트 및 조회 프로세스를 위한 대화 상자 및 모델 포함
  • 스트레스 & 벤딩 모멘트.

6단계 – 물리적 설계

이것은 시스템의 모든 논리적 사양을 실제 하드웨어와 소프트웨어 측면에서 시스템의 설명으로 변환하는 최종 단계다. 이것은 매우 기술적인 단계로서 간단한 개요가 여기에 제시되어 있다.

논리적 데이터 구조는 데이터베이스 구조 측면에서 물리적 구조로 변환된다. 기능의 정확한 구조와 구현 방법을 명시한다. 물리적 데이터 구조는 크기와 성능 요구사항을 충족하기 위해 필요한 경우 최적화된다.

이 제품은 소프트웨어 엔지니어에게 하드웨어와 소프트웨어의 구체적인 세부 사항과 적절한 표준에 따라 시스템을 구축하는 방법을 알려줄 수 있는 완전한 물리적 설계다.

참조

  1. ^ "OGC – Annex 1". Office of Government Commerce (OGC). Retrieved 2010-12-17.
  2. ^ Mike Goodland; Karel Riha (20 January 1999). "History of SSADM". SSADM – an Introduction. Archived from the original on 2013-02-19. Retrieved 2010-12-17.
  3. ^ "Model Systems and SSADM". Model Systems Ltd. 2002. Archived from the original on April 2, 2009. Retrieved 2009-04-02.{{cite web}}: CS1 maint : 부적합한 URL(링크)
  4. ^ SSADM foundation. Business Systems Development with SSADM. The Stationery Office. 2000. p. v. ISBN 0-11-330870-1.

5. 키스 로빈슨, 그레이엄 베리스포드: 객체지향 SSADM, 프렌티스 홀 인터내셔널(영국), 헤멜 헴프스테드, ISBN 0-13-3094444-8

외부 링크