답변

역사적으로 시스템 분석가는 회사 비즈니스 프로세스를 심층 분석하는 작업을 자주 시작했습니다. 이는 정보 시스템이 조직의 활동을 자동화하거나 최적화할 수 있는 방법과 곳을 이해하는 데 도움이 되었습니다. 그러나 비즈니스 프로세스 분석과 기술 설계 간의 경계가 종종 혼합되기도 합니다.

주요 특징:

• 비즈니스 프로세스 설명은 IT 도구를 통한 구현 세부사항은 고려하지 않고 조직 활동을 시스템으로서 식별하고 형식화하는 데 초점을 맞춥니다.
• 정보 시스템 설계는 요구 사항 형성이 이루어진 후에 시작하며, 아키텍처, 인터페이스, 통합, 데이터 형식 등을 포함합니다.
• 이러한 단계들을 분리하는 것이 중요합니다: 먼저 분석가는 "무엇을 할 것인지"를 정의하고 나서 "어떻게 할 것인지"를 정합니다.

질문의 역사

이전에는 이러한 단계 간의 경계가 더 명확했습니다: 비즈니스 분석가는 프로세스 모델링을 담당하고 시스템 분석가는 요구 사항을 기술 사양으로 변환하는 일을 맡았습니다. 현대의 관행에서는 이러한 작업이 종종 혼합됩니다.

문제

많은 분석가가 프로세스에 대한 완전한 분석 없이 시스템 설계를 시작하는데, 이것은 잘못된 요구 사항 정의와 과도한 기술적 세부 사항으로 이어집니다.

해결책

주제 영역 분석과 설계를 명확히 구분하고, 프로세스 설명을 위해 BPMN과 EPC를 사용하며, 설계를 위해 UML, 데이터 흐름 다이어그램(DFD) 등을 사용합니다.

트릭 질문들.

비즈니스 프로세스를 분석하는 것이 더 중요한가요 아니면 시스템을 설계하는 것이 더 중요한가요?

둘 중 하나를 강조할 수는 없습니다: 프로세스 분석은 올바른 요구 사항 생성을 위한 것이고, 설계는 이 요구 사항을 실현하는 것입니다. 이는 연속적인 단계입니다.

프로세스 설명과 시스템 설계에 동일한 다이어그램을 사용할 수 있나요?

아니요, BPMN/EPC는 프로세스에 적용되며, UML/DFD는 구조적 또는 객체 지향적 분석 및 설계에 사용됩니다.

어떤 경우에 비즈니스 프로세스를 모델링하지 않을 수 있나요?

프로젝트가 작고, 프로세스가 이미 문서나 표준으로 완전히 정형화된 경우에만 가능합니다. 대부분의 경우 모델링이 필요합니다.

일반적인 오류 및 안티 패턴

• 비즈니스 문제를 이해하지 않고 데이터 모델로 조기에 세부적으로 이동하는 것.
• 프로세스 설명과 기술 솔루션 혼합.
• 최종 사용자의 관심사를 무시하는 것.

사례

부정적 사례:
분석가는 직원들이 어떻게 일하는지와 그들이 원하는 것이 무엇인지 파악하지 않고 데이터베이스와 서비스를 즉시 설계하기 시작했습니다. 장점: 빠른 실행, 모두 첫 번째 버전에 만족.
단점: 시스템이 실제 문제를 해결하지 못하고, 사용자들이 불만족하며 추가 수정이 필요했습니다.

긍정적 사례:
분석가는 먼저 직원들과의 일련의 인터뷰를 실시하고 BPMN을 구성한 후 API 및 데이터베이스 설계로 넘어갔습니다. 장점: 요구 사항이 명확하고 시스템이 실제 프로세스를 충족합니다.
단점: 프로젝트 시작이 더 오래 걸리고, 분석 비용이 증가합니다.