4과목 소프트웨어 공학 강사 이 민 욱.

Presentation on theme: "4과목 소프트웨어 공학 강사 이 민 욱."— Presentation transcript:

1 4과목 소프트웨어 공학 강사 이 민 욱

2 요구분석 1. 요구 분석 (1) 요구 분석의 정의 요구 분석(Requirements analysis)이란 개발 요청자(사용자)의 하드웨어나 소프트웨어 에 대한 외부적 요구를 받아들여 개발하고자 하는 소프트웨어의 특성을 기술하는 단계 이다. (2) 요구 분석의 목적 ① 의사 교환 수단  ② 개발에 필요한 기본적인 자료를 제공  ③ 갖추어야 할 사항들을 정의 ④ 사용자와의 H/W, S/W 운영 상의 계약이다. (3) 요구 분석 단계의 특징 ① 사용자가 처음으로 참여 ② 가장 전문 인력을 필요 ③ 자연 언어  ④ 제어 구조가 포함되어서는 안 된다. (4) 요구 분석의 일반적인 순서 Needs 분석 → 개발자 준비 분석 →  자료 흐름도 작성 → 자료 사전 작성 → 미니 명세서 작성 → 요구 명세화 (5) 요구 분석가의 능력 ① 오랜 경험   ② 해박한 지식   ③ 요구를 정확히 수용   ④ 자료 제공 능력   ⑤ 프로그램 능력은 없어도 된다. (6) 요구 분석의 문제점 ① 대화의 장벽 ② 소프트웨어의 복잡성  ③ 요구의 변화   ④ 요구 명세화의 어려움  ⑤ 요구 분석에 대한 인식 부족  ⑥ 방법론 부족

3 2. 구조적 분석 구조적 분석의 기본 모형 3가지 :  ① 자료 흐름도(DFD)     ② 자료 사전(DD)     ③ 소단위 명세서(Mini-spec) (2) 구조적 분석의 세부 작업 순서 ① 배경도 작성 : 문제의 추상적인 개관만을 그린다.(대략적인 그림만 그린다.) ② 상위 자료 흐름도 작성 : 기본 모형을 그린다.(입력 → 처리 → 출력) ③ 하위 자료 흐름도 작성 : 하향식으로 자료 흐름도를 상세화한다. ④ 자료 사전 작성 : 자료를 구체적으로 정리한다. ⑤ 소단위 명세서 작성 : 자료 흐름도의 부족한 부분을 간략하게 서술한다. (3) 자료 흐름도(DFD)의 표기법 ① 외부 입출력(직사각형) : 자료의 생성지와 종착지, 정보의 생성지와 소비자 ② 처리 과정(원 모양) : 변환 과정, 모듈, 프로시저, 함수 ③ 자료 흐름(화살표) : 자료의 흐름, 인터페이스, 매개 변수  ④ 자료 저장소(두 줄) : 자료 저장, 파일, 데이터베이스, 디스크

4 (4) 자료 흐름도(DFD)의 작성 방법 ① 자료 흐름은 4가지의 기본 기호로 표시   ② 개별적인 상세화                         ③ 변환(처리)과정이 버블로 표현            ④ 한 페이지 단위                         ⑤ 단계마다 약 6～7개의 절차 버블           ⑥ 페이지 당 버블의 수가 12개 ⑦ 페이지의 단계는 2～3 단계    ⑧ 2～3 단계로 커지면 설계에 임할 수 있을 정도로 구체화한다. ⑨ 최종 단계의 버블은 프로그램으로 코딩이 가능   ⑩ 한번에 한 개의 버블만 세분화 (5) 자료 사전 표기법 ① 자료의 정의 : =  ② 자료의 연결 : +  ③ 자료의 선택 : [ | ]   ④ 자료의 반복 :{}n  ⑤ 자료의 생략 : (  )  ⑥ 자료의 설명 : ** (6) 요구 분석용 자동화 도구(CASE) ① SADT : SoftTect사에서 개발된 대규모 프로젝트용 요구 분석 방법론이다. ② PSL/PSA : 미시간 대학의 ISDOS 프로젝트에서 개발된 요구 분석용 자동화 도구이다.    ③ SREM(RSL/REVS) TRW사가 미 국방성의 의뢰에 의하여 개발한 실시간 시스템용 요구 분석 방법론 및 자동화 도구이다.

5 (7) 구조적 설계 표기법 ① N-S(Nassi-Schneiderman Chart) 도표   ․논리적 기술에 중점을 둔 도형   ․그리기가 어렵다.   ․연속, 선택, 다중 선택, 반복의 표현   ․ 임의의 제어 이동이 어렵다.             ․그래픽 설계 도구이다.              ․ 상자 도표라고도 한다.   ․프로그램으로 구현이 쉽다.               ․조건이 복합되어 있는 곳의 처리를 명확히 식별하기에 적합하다. ② HIPO 도표    ․도식 목차(가시적 도표) : 전체적인 흐름과 구조를 나타내는 도표    ․총괄 도표(총체적 도표) : 입력, 처리, 출력 등의 기능을 명확히 표현한 도표 (사용자 관점)    ․상세 도표(세부적 도표) : 총괄 도표를 구체적으로 표현한 모듈 도표(개발자 관점) ■ HIPO의 특징 ․분석 및 설계 도구로 사용된다. ․기본 시스템 모델은 입력, 처리, 출력으로 구성된다. ․하향식(Top-Down) 개발에 적당하다. ․문서가 보기 좋게 체계화된다.(보고서 용) ․기능과 자료의 관계를 동시에 표현할 수 있다. ․수정 및 유지 보수 시에 좋다. ․소규모 프로젝트에 적당하다.

6 3. 소프트웨어 설계 (1) 소프트웨어 설계 절차 DFD, DD 분석 → 외부 설계 → 내부 설계(기본 설계 → 상세 설계) → 설계 명세서     (2) 구조적 설계의 기본 원칙 ① 모듈화(Modularization)     전체 프로그램을 한 번에 설계하지 않고 단일 기능을 갖출 수 있도록 부분적으로 묶어서 처리하는 기술을 말하며 단위 프로그램, 함수, 서브 프로그램을 작성하기 위한 설계 기법이다. ② 추상화(Abstraction)     세부적인 설계를 배제하고 전체 흐름과 구조를 한눈에 알아볼 수 있도록 개괄적인 설계부터 점차 세부적으로 진행하는 설계 기법이다. ③ 구조화(Structured)      모듈의 수행하기 위한 위치나 시기를 전체 구조에 적절하게 배치시키는 설계 기법이다. ④ 정보 은닉(Information hiding)     모듈 내부의 정보들이 노출이 되고 모듈 간에 정보를 공동으로 사용하게 될 경우 모듈 변경 시 정보를 공동으로 사용한 모든 모듈에 부작용을 주게 되므로 소프트웨 어의 견고성은 유실된다. 따라서 정보의 은익은 부작용을 최소화하는 기술이다.

7 (3) 추상화의 3가지 기법 ① 기능 추상화 : 입력 자료를 출력 자료로 변환하는 과정을 추상화하는 경우 ② 제어 추상화 : 제어의 정확한 알고리즘은 정의하지 않고 원하는 효과만을 정의하는 경우 ③ 자료 추상화 : 자료와 자료에 적용될 수 있는 기능을 함께 정의하는 경우 (4) 바람직한 설계의 기준 ① 요구 사항을 모두 구현           ② 이해하기 쉬어야 한다. ③ 구현 관점에서 데이터, 기능, 행위 영역을 설명하는 완전한 그림을 제공 ④ 모듈적이어야 한다.                ⑤ 독립적인 기능의 특성을 갖는 모듈 ⑥ 계층적 조직이 제시                ⑦ 특정한 기능과 부 기능을 수행하는 요소들로 분할 ⑧ 자료와 프로시저에 대한 분명하고 분리된 표현 ⑨ 데이터와 제어 추상화를 모두 포함 ⑩ 복잡도를 감소시키는 인터페이스