시스템 분석 / 설계 개요 2장.

Presentation on theme: "시스템 분석 / 설계 개요 2장."— Presentation transcript:

1 시스템 분석 / 설계 개요 2장

2 학습 목표 SDLC 모형의 첫 단계인 시스템 분석의 중요성 인식 시스템 분석 및 설계 방법론의 특징 및 장.단점 학습
시스템분석 단계의 주된 절차인 요구사항 분석 이해 시스템 분석 및 설계 과정의 주요 산출물 학습

3 시스템 분석의 중요성 소프트웨어 비용 ■ 시스템 분석단계는 개발하려고 하는 시스템에 대한 요구사항을 정의하는 단계.
- 어떻게(How) 개발할 것인가에 초점을 맞추기 보다는 무엇을(What) 개발할 것인가를 정의 하는 단계 오류의 발견 시점에 따른 비용 증가 개발비용 분포

4 시스템 분석의 중요성 이상적인 SDLC 모형 개선해야 할 SDLC모형의 단계별 인력소요
■ 시스템 분석단계로부터 설계, 구현단계를 향하여 인력 소요가 상향 곡선을 그린 뒤 유지보수 단계에서 하향곡선을 그으며 안정된 모델이다. ■ 실제로는 이와 달리 유지보수 단계에서 인력 소요가 상향 곡선을 그린 그린 이유는 불충분한 분석에 따른 시스템 구축이 주원인이다. ⇒ 바람직한 시스템 개발 : 초기분석과 설계에 좀 더 많은 시간과 인력을 투입하여 충분한 요구사항 분석 및 검토를 거친 후 설계를 함으로서 유지보수에 적은 비용이 소요 될 수 있도록 하는 것이 바람직한 모델임.

5 시스템 분석/설계 방법론 02 시스템 관점에서 본 설계 방법론 ■ 기능 모델링
- 시스템의 기능 관점에서 바라보고 시스템에서 요구되는 정보의 흐름과 정보의 변환을 나타내는 모델. ■ 동적 모델링 - 시간과 변화의 관점에서 시스템을 묘사한 것으로 시스템 제어 흐름, 상호작용, 동작의 순서를 나타내는 모델. ■ 정보 모델링 - 시스템에 사용되는 정보 데이터를 중심으로 시스템의 정적인 정보구조를 나타내는 모델.

6 시스템 분석/설계 방법론 02 (1) 기능 모델링(Function Modeling)
기능 모델링 방법론은 구조적 분석 방법론, SADT, PSL/PSA 등이 있다. 1) 구조적 분석 방법론(Structured System Analysis) ■ 1979년 DeMarco가 도식적 기초를 이용하여 소개, 1980년대부터 널리 활용되기 시작 현재 요구사항 분석에 가장 많이 활용하는 기법 ■ 구조적 분석 방법론에 사용되는 도구 - 자료 흐름도 - 자료사전 - 소단위 명세서 등 자료흐름도 (DFD) 자료사전 (DD) 소단위명세서 (Mini-pec) 구조적 분석 방법론의 3가지 도구

7 시스템 분석/설계 방법론 02 ■ 구조적 분석 특징 ① 매우 간결하다(Concise)
- 자료 흐름도를 작성하기 위해 단지 4개의 기호만 필요 - 정보 기술 전문가가 아니더라도 누구나 쉽게 직관적으로 도형 의미 이해 ② 이해하기가 쉽다(Understandability) - 자료 흐름도, 자료사전의 경우 낯익은 기호 사용으로 누구나 쉽게 이해하고 쉽게 작성 할 수 있음 ③ 검증이 가능하다(Verifiable) - 자료 흐름도, 자료사전에 사용되는 자료명이 실제 현업에서 사용하고 있는 그대로 사용하므로 실제 흐름과 맞는지를 검증할 수 있음. ④ 체계적이다(Organized) - 자료 흐름도, 자료사전, 소단위 명세서는 서로 유기적으로 연관되어 작성되므로 시스템에 대한 체계적인 접근이 가능.

8 시스템 분석/설계 방법론 02 2) SADT(Structured Analysis and Design Technique) = 구조적 분석 설계 기법 ■ 하드웨어의 생산에 청사진이 있듯이 소프트웨어의 생산에도 청사진을 만들어 사용하자 는 데서 고안된 시스템 분석 기법. ■ Softech사에서 개발된 그래프 언어이며 자연어의 이름과 그 외 다른 표기법을 첨가한 요구기술 방법론으로서 시스템 구조를 계층적으로 기술 하도록 되어 있음 ■ SADT는 아래의 사항을 수행하기 위한 방법론을 제공함 ① 대규모의 복잡한 문제를 구조적으로 생각하게 함 ② 각 작업자의 노력과 역할을 효과적으로 나누고 또 통합해서 팀으로서 효과적으로 활동하게 함 ③ 명료하고 정확한 표기법에 의해서 인터뷰, 분석, 설계의 결과를 전달하게 함

9 시스템 분석/설계 방법론 02 3) PSL/PSA(Problem Statement Language/Problem Statement Analyzer) ■ 미시간 대학의 다니엘 타이초로우 교수에 의해 미시간 대학의 ISDOS 프로젝트에서 개발된 정보처리 시스템에 대한 요구사항 분석과 문서화를 지원하는 시스템. ■ 개발해야 할 목적 시스템의 요구사항 명세서를 기계처리가 가능한 요구 정의 언어인 PSL로 기술하고 나서 이 언어의 처리기인 PSA에 입력한다. ■ 단점 - PSL/PSA는 수많은 예약어와 문법구조를 가지고 있어 매우 복잡함 - IBM 시스템에 적합하게 설계되어 있어 범용으로 사용하기에 부적합 함.

10 시스템 분석/설계 방법론 02 (2) 동적 모델링(Dynamic Modeling)
- 시간과 변화의 관점에서 시스템을 묘사한 것으로 시스템 제어 흐름, 상호작용, 동작의 순서를 나타내는 모델. 1) 실시간 시스템(Real-Time System) - 동적 모델링이 중요시 여겨지는 시스템을 일반적으로 실시간 시스템이라 부른다. ■ 실시간 시스템의 특징 - 여러 프로세스를 동시에 병행으로 수행. - 프로세스 처리에 우선순위를 가짐. - 자원에 대한 동시 접근 및 할당 제어 기능을 가짐. ■ 대표적인 실시간 시스템 예 - 통신 시스템 -비행기 운행 관리 시스템 -자동차 속도 조절장치 -원자력 발전소의 원자로 제어장치 -군사용 미사일 시스템 등

11 시스템 분석/설계 방법론 02 2) 상태 변화도(STD) = State Transition Diagram
■ 시스템의 제어 흐름, 동작 순서를 나타낸다. ■ 상태변화도의 중요한 개념 - 시스템이 가지고 있는 값을 표시하는 = 상태 - 상태에 가해는 외부적 = 사건 ■ 상태와 사건에 의해 시스템에 의해 시스템의 제어를 나타내는 유한 오토마타(finite automata; 유한 집합)를 확장해 도식적으로 표시한 것이 상태 변화도 이다. ■ 유한 오토마타 : 시스템의 동작을 표시해 주는 추상적인 모델.

12 시스템 분석/설계 방법론 02 (3) 정보 모델링(Information Modeling)
시스템에 사용되는 정보 데이터를 중심으로 시스템의 정적인 정보구조를 나타내는 모델. 시스템에 필요한 엔티티(Entity)를 정의하고 이들 엔티티 사이의 연관성을 규명하는 작업. ■ 정보 모델링은 객체모델링, 개념적 데이터 모델링, 의미 데이터 모델링이라고 함. ■ 정보 모델링 사용 도구 - EER 모델(Enhanced Entity Relationship) ■ ERR(Enhanced Entity-Relationship Diagram) - 1976년 Peter Chen에 의해 제안된 ER 모델에 데이터의 계층 구조를 추가하여 확장시킨 것 판매보고서 도서 구매 프린터 고객 주문서 출력 [전형적인 ERD(Entity Relationship Diagram]

13 시스템 분석/설계 방법론 02 (4) 객체지향 모델링(Object-Oriented Modeling)
■ 객체지향 개발 방법론은 소프트웨어 위기를 극복하기 위한 개발 방법 중 가장 최근에 나타난 것으로 현재까지 나타난 소프트웨어 개발의 문제점을 해결해 줄 많은 장점들을 보유하고 있음. ■ 객체지향 모델의 분석 3관점 - 기능관점 - 객체(정보) 관점 - 동적 관점

14 요구사항 분석 03 (1) 조사 방법 ■ 시스템 분석 단계의 주된 목적 - 시스템에 대한 요구 사항을 정의 하는 작업이다.
- 요구사항 분석은 사용자의 추상적이고 비정형화된 요구를 정형화 하는 과정임. ■ 요구사항 분석을 위한 조사방법 및 조사내용은 다음과 같다. (1) 조사 방법 ■ 조사 방법은 관찰조사, 질문조사, 면담조사가 있다. 1) 관찰 조사 - 실제 현업부서를 방문하여 부서의 작업환경, 현업의 처리 절차, 개선할 사항 등을 관찰하여 정량적(빈도, 수량, 비용 등)인 정보를 수집하는 것. 2) 질문지 조사 - 체계적으로 설계된 질문지에 필요로 하는 정보를 수집하는 절차 - 직접 관찰, 면담이 어려운 부서나 담당자에게도 손 쉬운 정보를 수집할 수 있음. - 단점 : 질문지의 구성에 따라 필요한 정보를 정확하게 수집하기 어려울 수 있음 3) 면담(인터뷰) 조사 - 시스템 분석가와 현업 부서 담당자 간의 직접 대화를 통해 현행 시스템의 문제점 및 개선 요구사항 등을 명확히 파악할 수 있음.

15 요구사항 분석 03 (2) 조사 내용 ■ 조사 내용은 [조직에 대한 정보], [현재 사용중인 제반 서식], [시스템 인프라], [현재 운영 중인 시스템]에 대하여 실시한다. 1) 조직에 대한 정보 - 조직의 연혁, 조직도, 업무분장, 제 규칙 등을 수집 분석함. ⇒ 시스템에 포함 되어야 할 핵심적인 기능 및 처리 조건을 파악 할 수 있음 2) 현재 사용중인 제반 서식 - 부서에서 현재 사용중인 제반 서식을 빠짐없이 수집, 분석하는 절차는 매우 중요함. ⇒ DB 설계 및 입력, 출력 설계의 기본이 되는 정보를 제공함. 3) 시스템 인프라 - 서버의 가용자원, 성능 등을 비롯하여 네트워크 구축 상태 및 데이터베이스 사용 등을 조사 분석하여 새로운 시스템 구축 및 운영에 필요한 환경에 적합한지의 여부를 조사함. 4) 현재 운영 중인 시스템 - 시스템의 지원 범위를 비롯하여 운영자 매뉴얼 등을 수집하여 분석할 뿐만 아니라 시스템의 문제점, 보완점 등을 면밀히 분석함.

16 구조적 검토회의 04 (1) 종래 검토회의의 문제점 ■ 검토회의는 개발에 관련된 요원들이 작성된 산출물의 품질을 평가하기
위한 목적으로 개최하는 기술 평가 모임. ■ 종래 검토회의의 문제점 ① 참석자 역할과 책임의 불명확 - 참석자는 다른 사람에게 의존하게 되어 그 결과 아무런 조치도 취하지 않음. ② 효율적인 검토회의의 진행법 부재 - 참석자는 많은 시간을 낭비 함. ③ 산출물 보다 사람 평가 경향 - 사람을 평가 하므로 시간 낭비가 있음 ④ 검토회의 목적의 불분명 - 종종 프로젝트의 진척 상황이나 문제점을 토론하는 자리가 될 수 있음

17 구조적 검토회의 04 (2) 구조적 검토회의의 효과 ■ 구조적 검토회의는 프로젝트에 참여한 사람들이 개발 단계에서 작성된 문서와 프로그램을 조사하고 버그와 문제점을 찾아내는 과정임. ■ 구조적 검토회의는 다음과 같은 점에서 종래 검토회의 방식과 차이점. ① 역할과 책임이 분명히 정의 된다. ② 검토회의의 이전 단계, 진행단계, 이후 단계로 구분되어 작업이 수행된다. ③ 참여자들의 심리적 갈등이 해소된다. ④ 목표가 분명하다

18 구조적 검토회의 04 (2) 구조적 검토회의의 효과 ■ 구조적 검토회의 효과
① 개발 초기 산출물이 안고 있는 문제점의 발견 가능 ② 산출물의 완전성, 일관성, 이해 가능도 확인 가능 ③ 각자가 가지고 있는 개념, 기법의 상호 교환 가능 ④ 프로젝트 진척도 측정 가능 ⑤ 모든 참석자들이 프로젝트에 대해 공동 책임

19 구조적 검토회의 04 (3) 검토회의 참석자 ■ 검토회의 참석자의 역할
① 산출물 발표자(Presenter) 검토회의 참석자들에게 산출에 대한 설명 ② 중재자(Moderator) 검토회의가 효율적이고 순조롭게 진행되도록 계획 및 조정. ③ 서기(Scribe) 검토회의에서 발견된 오류나 기타 문제점들을 기록. ④ 산출물 검토자 장래의 유지 관점에서 산출물을 검토 - 산출물 검토 자는 유지보수 요원이거나 표준화 요원일 수 있다. ▶ 유지보수 요원 ▶ 표준화 요원 ⑤ 사용자 대표(User Representative) 자신의 요구사항이 충족되었는지를 확인하고 프로젝트 진행 사항에서의 피드백과 질적 문제에 대한 조언을 함.

20 시스템 분석/설계 문서 05 ■ 소프트웨어 개발 과정에서 수많은 문서들이 산출됨.
■ 소프트웨어 개발 과정에서 수많은 문서들이 산출됨. ■ 문서(산출물)의 중요성을 인식하지 못하거나 소홀히 여긴 나머지 소프트웨어 시스템의 유지보수에 애로를 겪고 있는 경우가 많음. ■ 소프트웨어 개발 과정의 주요 문서 ① 제안 요청서 ② 제안서 ③ 사업 수행 계획서 ④ 요구 사항 명세서 ⑤ 설계명세서 등

21 시스템 분석/설계 문서 05 (1) 제안 요청서(RFP: Request for Proposal)
■ 제안서는 조직 내부, 전문개발 업체에 의뢰할 것인가? 또는 개발기간, 소요되는 예산규모, 개발범위 등을 점검한 후 이를 정리한 것 ▶ 제안요청서에 포함되는 항목들 ① 사업명 ② 사업기간 ③ 사업목적 ④ 사업범위 ⑤ 예산규모 등

22 시스템 분석/설계 문서 05 ■ 사업 명 : 개발 프로젝트의 내용을 함축하고 있는 사업명칭을 기술
■ 사업기간 : 시작일부터 종료일까지 명시 ■ 사업목적 : 추상적이 아닌 실질적인 개발 프로젝트를 진행하게 된 배경 및 목적을 간략히 기술 ■ 사업의 범위 : 제안 요청서의 가장 중요한 부분으로 프로젝트에 포함 되어야 할 개발의 범위를 명시 → 가능한 상세히 작성하는 것이 바람직하다. ■ 예산규모 : 사업에 참여하기를 원하는 업체들이 참고할 수 있도록 대략적인 예산규모를 제시하는 것이 바람직하다. ■ 개발환경(기존 시스템 환경) : 현재 운영중인 시스템의 일반적인 환경을 명시함. ■ 제안서 작성시 고려사항 : 제안서 작성시 우선 고려해야 할 사항 있으면 이를 제시함. ■ 제안서 작성 기준(목차 등) : 제안서 규칙, 제출부수, 요약본의 제출부수 등을 명시. ■ 제출기한 및 제출방법 : 제안서의 제출일과 시간을 명시/ 경쟁업체간의 사전 정보 누출 방지 을 위하여 제안 금액 작성 문서는 별도 봉인하여 제출하도록 제시함. ■ 제안서 평가기준 : 공정한 심사 및 평가 기준 제시 - 기술력, 사업 수행능력, 제안금액 등

23 시스템 분석/설계 문서 05 (2) 제안서(Proposal)
■ 제안서는 제안 요청서를 받고 제안에 참여하는 개발 업체들이 요구 사향에 맞게 작성하는 것. ■ 제안서는 개발 업체의 사업 수행 능력을 간접적으로 보여주는 자료임 ■ 제안서에 포함되는 항목들 ① 제안업체 일반사항 회사명 대표자 회사연혁 자본금 등 ② 제안목적 ③ 사업명 ④ 사업기간 ⑤ 사업목적 등

24 시스템 분석/설계 문서 05 제안서(Proposal) 구성 ■ 제안 업체의 일반사항(회사명, 회사연혁, 자본금 등)
- 객관적으로 회사의 사업 수행 능력을 가늠해 볼 수 있는 중요한 자료 . - 개발연혁, 회사의 자본 규모, 관련 분야 개발 인력 현황 등 ■ 제안 목적 : 참여 목적을 설득력 있게 작성 ■ 사업 명 : 제안 요청서와 동일하게 작성 ■ 사업기간 : 제안 업체에 따라 가감이 가능하다. ■ 사업범위 : 제안요청서의 제시된 사업 범위를 기준으로 작성 ■ 사업추진체계 : 사업을 추진하기 위한 조직 및 지원체계를 제시한다. ■ 개발방법론 : 사업의 특성 및 규모에 따라 최적의 개발 방법론을 적용함. ■ 일정계획 : 프로젝트 추진 일정 계획을 수립하여 제안서에 제시한다. - 주요 사업 추진 단위 별로 소프트웨어 수명주기 모형에 입각한 단계별 추진 일정을 간트 차트 형태로 작성하여 제시한다.

25 시스템 분석/설계 문서 05 제안서(Proposal) 구성
■ 투입인력 계획 항상 : 소프트웨어 개발 비용의 대부분은 투입 이력에 대한 인건비 항목을 차지하고, 소프트웨어의 품질을 결정 하는 중요 인자임 ■ 기술이전 계획 : 개발 프로젝트가 완료되면 기술이전을 해야 한다. 만약 기술이전이 원만하게 이뤄지지 못하면 개발업체가 종속적으로 운영하게 되어 도산이나 심각한 운영위기를 맞는다. ■ 제안업체의 사업수행 실적 : 개발업체가 프로젝트를 수행할 능력을 갖추고 있는지를 객관으로 보여주는 중요한 항목이다. ■ 제안금액(별지) : 공개 입찰 시 제안 금액은 가장 중요한 선택항목이나 최우선 고려 해서는 안 된다. 왜냐하면 인력 투입 비용이 주된 비용요소를 차지하기 때문에 양질의 고급인력을 투입하여 좋은 품질의 결과물을 산출하는 것이 매우 중요함.

26 시스템 분석/설계 문서 05 (3) 사업수행 계획서(Project Plan)
■ 계약 체결 후 가정 먼저 작성하는 것으로 제안 요청서를 바탕으로 사업 수행에 필요한 제반 계획서 사항들을 명확히 기술하는 문서 ■ 사업수행계획서에 포함되는 항목들 ① 사업명 ② 사업기간 ③ 사업목적 ④ 사업범위 ⑤ 사업추진체계 ⑥ 개발방법론 ⑦ 산출물 계획 ⑧ 일정 계획 ⑨ 품질관리 계획 ⑩ 보고서 계획 ⑪ 위기관리 및 보안대책 등

27 시스템 분석/설계 문서 05 (3) 사업수행 계획서(Project Plan)
■ 산출물계획 : 교재 73쪽 (표 2-1 참조) ■ 일정계획 : 다음 페이지 간트 차트 (그림2-12 참조) ■ 품질관리계획 : 교재 74쪽 (표 2-2 참조) ■ 보고계획 : 교재 75쪽 (표 2-3 참조) ■ 위기관리 및 보안대책 : 개발 과정에서 많은 위기 요인이 발생하므로 제안업체는 별도의 위기관리 및 보안 대책을 위한 명문화된 계획서를 작성하여 고객과 고유함. ■ 교육계획 : 사용자 그룹별로 기술이전을 위한 교육 훈련 계획 일정을 작성한다. ■ 주관기관 협조요청사항 : 개발 업체 측에서 주관기관에게 사업 수행과 관련한 협조요청 사항을 기술한다.

28

29 시스템 분석/설계 문서 05 (4) 요구사항 명세서(Requirements Specification)
■ 향후 프로젝트 추진 범위가 되며 시스템 설계 ,구현, 테스트 등의 과정에서 참조, 최종 검수를 위해서도 매우 중요한 문서임 ■ 요구사항 명세서에 포함되는 내용들 ① 기능 요구사항 ② 성능 요구사항 ③ 인터페이스 요구사항 ④ 운영 요구사항 ⑤ 자원 요구사항 ⑥ 검증 요구사항 ⑦ 인수테스트 요구사항 등

30 시스템 분석/설계 문서 05 요구사항 명세서(Requirements Specification) 구성요소
■ 기능 요구사항 : 시스템이 구현해야 할 기능에 대한 요구명세를 기술함. ■ 성능 요구사항 : 시스템에서 수행할 응답시간 등의 성능에 대한 요구 명세를 기술 함 ■ 인터페이스 요구사항 : 사용자의 사용 편리성을 고려한 유저 인터페이스, 인터넷 환경에서의 접근성 등에 대한 대한 요구 명세를 기술 함 ■ 운영 요구사항 : 시스템 운영 필요한 환경을 명시함 ■ 자원 요구사항 : 운영에 필요한 자원에 대한 제약 등에 대한 요구 명세를 기술 함 ■ 검증 요구사항 : 시스템 검증을 위한 조건, 절차 검증문서 등에 대한 요구 명세를 기술 함 ■ 인수 테스트 요구사항 : 최종 사용자를 위한 인수 테스트에 대한 요구 명세를 기술 함 ■ 문서화 요구사항 : 사용자 매뉴얼, 운영자 매뉴얼 등 시스템의 사용과 운영을 위해 필수적인 문서들에 대한 요구 명세를 기술 함

31 시스템 분석/설계 문서 05 요구사항 명세서(Requirements Specification) 구성요소
■ 보안 요구사항 : 시스템의 안전한 운영을 위해 요구되는 보안 기능에 대한 요구 명세를 기술 함 ■ 이식성 요구사항 : 시스템 설치에 필요한 조건 등에 대한 요구 명세를 기술 함 ■ 품질 요구사항 : 시스템 품질 기준 및 지침을 제시하고, 품질관리를 위한 절차 등에 대한 요구 명세를 기술 함 ■ 신뢰성 요구사항 : 시스템 검증이나 품질 요구사항 등은 모든 시스템의 신뢰성 확보를 위한 요구 명세를 기술 함 ■ 유지보수성 요구사항 : 시스템의 유지 보수성을 높이는데 필요한 요구 명세를 기술 함 ■ 안전 요구사항 : 시스템의 내부적인 문제로부터 안전하게 운영할 요구사항 대한 요구

32 시스템 분석/설계 문서 05 (5) 설계 명세서(Design Specification)
■ 설계 과정에서 산출 각종 설계 문서를 의미한다. ■ 설계 명세서에 포함되어야 할 문서들 ① 시스템 구조도 ② 데이터베이스 설계문서 ③ 프로그램 작성지침 ④ 인터페이스 설계문서 등