🎉 berenickt 블로그에 온 걸 환영합니다. 🎉
CS
소프트웨어공학
02-프로젝트 계획 및 분석

1. 프로젝트 계획

1.1 프로젝트 관리

1.1.1 프로젝트 관리의 개념

  • 특정한 목적을 가진 프로젝트를 한정된 기간, 예산, 자원 내에서 사용자가 만족할 만한 제품을 개발하도록 행하는 기술적, 관리적 활동

1.1.2 프로젝트 관리의 목적

  • 납기준수, 예산준수, 품질 준수를 통한 고객 만족 달성
  • 고품질의 제품 개발 및 개발 절차 준수

1.1.3 프로젝트 핵심 관리대상(3P)⭐

  • 사람(People) : 프로젝트 관리에서 가장 기본이 되는 요소
  • 문제(Problem) : 처리해야 할 내용을 분석하고 설계한다.
  • 프로세스(Process) : 소프트웨어 개발에 필요한 골격을 제공한다.

1.1.4 PMBOK(Project Management Body of Knowledge)

  • PMI(Project Management Institute)에서 제작한 프로젝트 관리 프로세스 및 지식 체계
  • PMBOK 5단계 프로세스 그룹⭐
    • 1단계 : 프로젝트 착수
      • 광범위한 프로젝트의 범위를 정하는 단계
    • 2단계 : 프로젝트 계획
      • 프로젝트의 세부 범위를 정의하고, 프로젝트 관리 계획을 만드는 단계
      • 비용, 품질, 기간 사용 가능한 자원이 포함됨
    • 3단계 : 프로젝트 실행
      • 프로젝트가 개발되고 완료되는 단계
    • 4단계 : 프로젝트 통제
      • 계획 대비 목표의 진척상황을 모니터링하고 성과를 측정하는 단계
    • 5단계 : 프로젝트 종료
      • 프로젝트가 요구사항을 만족하는지 검증하고, 고객으로부터 확인 받는 단계

1.2 개발 비용 산정⭐

1.2.1 하향식 산정 기법(Top-Down)

  • 전문가 기법
    • 조직 내 경험이 있는 전문가에게 비용 산정을 의뢰하여 산정하는 기법
  • 델파이 기법
    • 여러 전문가의 의견을 종합하여 판단하는 기법
    • 특정 전문가의 주관적인 편견을 보완하기 위해 여러 명의 전문가로 구성된다

1.2.2 상향식 산정 기법(Bottom-Up)

  • LOC(원시코드 라인수)
    • 각 기능의 원시 코드 라인 수의 비관치(가장 많은 라인 수), 낙관치(가장 적은 라인 수), 중간치(기대치, 평균 라인 수)를 측정 후 예측치를 구하고, 이를 이용해 비용을 산정하는 기법
    • 추정 LOC : (낙관치 + ( 4 * 중간치) + 비관치 ) / 6⭐
    • e.g. 낙관치 : 3 / 중간치 : 5 / 비관치 : 7
      • 3 + (20) + 7 / 6 = 30 / 6 = 5
  • 단계별 인원수(M/M) 기법
    • 소프트웨어 개발 생명주기 각 단계별로 적용시켜 모든 단계의 비용을 산정하는 기법
    • LOC보다 정확성을 기하기 위한 기법

1.2.3 수학적 산정 기법

1.2.3.1 COCOMO 기법

  • 개발할 S/W의 규모를 예측한 후 S/W 종류에 따라 각 비용 산정 공식에 대입하여 비용을 산정하는 기법
  • LOC 기법을 개발유형에 따라 다르게 적용한 기법
  • 개발 유형⭐
개발유형설명
조직형(Organic Mode)5만 라인 이하의 프로젝트(e.g. 일반 업무용 소프트웨어)
반분리형(Semidetached Mode)30만 라인 이하의 프로젝트(e.g. 운영체제, DBMS 등)
내장형(Embedded Mode)30만 라인 이상의 프로젝트(e.g. 미사일 유도 시스템, 신호기 제어 시스템 등)

1.2.3.2 Putnam 기법⭐

  • Putnam이 제안한 생명 주기 예측 모형
  • 소프트웨어 생명 주기의전 과정 동안의 노력의 분포를 가정해주는 모형
  • 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
  • 대형 프로젝트에서 이용되는 기법이다.
  • 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소한다.
  • SLIM : Rayleigh-Norden 곡선과 Putnam 예측 모형을 기초로 개발한 자동화 추정도구

1.2.3.3 기능 점수 기법(FP, Function Point)⭐

  • 개요
    • 소프트웨어가 가지는 기능의 개수를 기준으로, 소프트웨어의 규모를 측정하는 기법
    • 1979년 IBM사의 A.J.Albrecht가 고안한 방식이다.
    • 객관적이고 정량적인 소프트웨어의 규모를 산출 할 수 있게 되었다.
    • ESTIMACS : FP 모형을 기초로 개발된 자동화 추정 도구
  • 비용산정에 이용되는 요소
    • 자료 입력(입력 양식)
    • 정보 출력(출력 보고서)
    • 명령어(사용자 질의수)
    • 데이터 파일
    • 필요한 외부 루틴과의 인터페이스

1.3 개발 일정 산정

1.3.1 소프트웨어 개발 일정 계획

  • 소프트웨어를 개발하기 위해 어떤 작업이 필요한지 정의하고, 작업들의 우선순위를 정하여, 프로젝트 일정에 대한 계획을 세우는 것
  • 작업 순서
    • 작업분해(Work Breakdown Structure, WBS)
    • CPM 네트워크 작성
    • 최소 소요 기간을 구함
    • 소요 M/M, 기간 산정하여 CPM 수정
    • 간트 차트로 표현(네모는 일정을 표시)

1.3.2 WBS(Work Breakdown Structure)

  • 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화 하는 작업
  • WBS 작성방법
    • 전체를 큰 단위로 분할
    • 각각의 부분에 대해 좀 더 작은 단위로 분해하여 계층적으로 표현
    • 담당인원을 배치해 구성도 작성
  • WBS 역할
    • 프로젝트에서 수행할 업무를 식별
    • 일정계획과 산정
    • 전체일정 진행상황 파악
    • 이해당사자들 간의 의사소통

1.3.3 Network Chart(PERT/CPM)⭐

  • PERT
    • 미 해군의 Polaris 미사일 개발 프로젝트의 일정계획 및 진행과정을 효율적으로 관리하기 위해 개발됨
    • 전체 프로젝트의 시간단축을 목표로 함
    • 개발기간을 낙관치, 기대치, 비관치로 나누어 예측치를 구한다.
    • 예측치 = (낙관치 + (4 * 기대치) + 비관치) / 6
  • CPM
    • 미국의 듀폰(Du pont)사와 레밍톤(Remington)사의 화학공장 유지 및 관리를 위해 개발됨
    • 최소의 비용 추가 투입을 고려하여 전체 프로젝트의 시간단축을 목표로 함
  • PERT/CPM
    • 작업의 선/후행 관계를 고려하여 전체작업의 완료시간을 결정하고(PERT), 추가비용 투입을 고려하여 전체작업 완료시간을 단축하는(CPM) 네트워크 분석 기법
    • 복잡한 대형 프로젝트를 효율적으로 계획 및 통제하기 위해 개발된 기법
    • 임계경로(Critical Path) : 프로젝트를 끝내기 위해 필요한 최소 소요기간⭐

CPM 소작업 리스트

작업선행작업소요기간(일)
A-15
B-10
CA, B10
DB25
EC15

CPM 네트워크 작성

info-processing_2_1

소요기간 산정⭐

  • 임계경로(Critical Path) : 40일 (최대로 걸리는 기간)
  • D의 가장 빠른 착수일 : 10일⭐
  • D의 가장 늦은 착수일 : 15일 (10 + (40 - 35))
  • D의 여유기간 : 5일

1.3.4 간트 차트(Gantt chart)

  • 일정 계획의 최종 산출물
  • 프로젝트 일정관리를 위한 바(bar, 여기서는 일정을 의미)형태의 도구
  • 각 업무별로 일정의 시작과 끝을 그래픽으로 표시하여 전체 일정을 한눈에 볼 수 있다.
  • 각 업무(activities) 사이의 관계를 보여준다.

2. 요구사항 분석

2.1 현행 시스템 분석

2.1.1 현행 시스템 파악

(1) 현행 시스템 파악의 정의

  • 현행 시스템이 어떤 하위 시스템으로 구성되어 있는지
  • 제공하는 기능이 무엇인지
  • 다른 시스템들과 어떤 정보를 주고받는지
  • 어떤 기술요소를 사용하고 있는지
  • 사용하고 있는 소프트웨어 및 하드웨어는 무엇인지
  • 네트워크는 어떻게 구성되어 있는지

(2) 현행 시스템 파악의 목적

  • 향후 개발하고자 하는 시스템의 개발범위 및 이행 방향성 설정에 도움을 주는 것이 목적

(3) 현행 시스템 파악 절차

  • 1단계 - 현행 시스템의 구성, 기능, 인터페이스 현황을 파악하는 단계
  • 2단계 - 현행 시스템의 아키텍처 및 소프트웨어 구성 현황을 파악하는 단계
  • 3단계 - 현행 시스템의 하드웨어 및 네트워크 구성 현황을 파악하는 단계

2.1.2 플랫폼 기능 분석

(1) 플랫폼 정의

  • 어플리케이션을 구동시키는데 필요한 하드웨어와 소프트웨어의 결합
  • 공급자와 수요자 등 복수 그립이 참여하여 각 그룹이 얻고자 하는 가치를 공정한 거래를 통해 교환할 수 있도록 구축된 환경

(2) 플랫폼 기능

  • 소프트웨어 개발과 운영비용이 감소하고 생산성이 향상
  • 플랫폼 내의 커뮤니티를 형성하고 네트워크 효과를 유발

(3) 플랫폼의 유형 : 싱투멀⭐

  • 싱글 사이드 플랫폼(single-side platform) : 제휴 관계를 통해 소비자와 공급자를 연결하는 형태
  • 투 사이드 플랫폼(two-side platform) : 두 그룹을 중개하고 모두에게 개방하는 형태
  • 멀티 사이드 플랫폼(multi-side platform) ; 다양한 이해관계 그룹을 연결하는 형태

2.1.3 운영체제 분석

(1) 운영체제 개념

  • 컴퓨터 시스템 자원을 효율적으로 관리하여 사용자가 컴퓨터를 편리하게 사용할 수 있도록 환경을 제공해주는 시스템 소프트웨어
  • 컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 해줌
  • 사용자와 하드웨어간의 인터페이스를 담당

(2) 운영체제 종류

  • PC용

    • 유닉스(UNIX)
    • 리눅스(Linux)
    • 윈도우즈(Windows)
    • 맥 OS(Mac OS)

  • 모바일용

    • iOS
    • Android
    • 윈도우폰 OS

2.1.4 네트워크 분석

(1) 네트워크 개념

  • 노드(컴퓨터)들이 자원을 공유할 수 있게 하는 디지털 전기 통신망
  • 노드 간 연결을 통해 서로에게 데이터를 교환

(2) 프로토콜⭐

  • 데이터를 교환하기 위해 사용하는 통신 규칙
  • 프로토콜의 3요소 : 구의타⭐
    • 구문(Syntax) : 데이터의 형식이나 부호화 및 신호 레벨을 규정
    • 의미(Semantic) : 전송의 조작이나 오류 제어를 위한 제어 정보에 대한 규정
    • 타이밍(Timing) : 접속되어 있는 개체 간의 통신 속도의 조정이나 메시지의 순서 제어 규정

2.1.5 DBMS 분석

(1) DBMS(Database Management System) 개념

  • 사용자, 어플리케이션등의 상호 작용을 위해 데이터를 저장하고 분석하는 소프트웨어
  • 데이터베이스 생성, 조회, 변경 등의 관리

(2) 현행 시스템 데이터베이스 분석

  • DBMS의 종류, 버전, 구성방식, 스토리지 크기, 백업 주기 분석
  • 테이블 수량, 데이터 증가 추이, 백업 방식 등을 분석

2.1.6 미들웨어(Middleware)

2.1.6.1 미들웨어 개념

  • 양 쪽을 연결하여 데이터를 주고 받을 수 있도록 중간에서 매개 역할을 하는 소프트웨어

2.1.6.2 미들웨어 종류

  • RPC(Remote Procedure Call) : 클라이언트가 원격에서 동작하는 프로시저를 호출하는 시스템

  • MOM(Message Oriented Middleware)

    • 응용 소프트웨어 간의 데이터 통신을 위한 소프트웨어
    • 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어

  • ORB (Object Request Broker) : 객체지향 시스템에서 객체 및 서비스를 요청하고 전송할 수 있도록 지원하는 미들웨어

  • DB 접속 미들웨어 : 애플리케이션과 데이터베이스 서버를 연결해주는 미들웨어

  • TP 모니터 : 온라인 트랜잭션을 처리 및 감시하는 미들웨어

  • WAS(Web Application Server) : 동적인 콘텐츠를 처리하기 위한 미들웨어

    • e.g.) WebLogic, Jeus, Tomcat

  • ESB(Enterprise Service Bus)

    • 메시지 기반으로 느슨한 결합형태의 표준 인터페이스 통신을 지원하는 미들웨어
    • 기업 안팎에 있는 모든 시스템 환경을 연동하는 미들웨어
    • ESB를 구성하는 요소 : SOAP(실제 통신), UDDI(도서관), WSDL(설명서, XML로 구성됨)

2.2 요구공학

2.2.1 요구공학 개념

  • 고객 요구를 체계적으로 수집, 분석, 명세화, 검증하고 추적, 변경되는 요구사항을 도출하고 관리하는 기법

2.2.2 요구공학의 필요성

  • 분석의 어려움 : 이해부족, 의사소통, 잦은 요구사항의 변경
  • 요구사항 변화 : 요구사항은 개발초기에 불완전하고, 개발 동안 지속적으로 변화
  • 관점별 차이 발생 : 묵시적 요구사항, 변경과 추적에 대한 문제, 해당 업무에 대한 지식

2.2.3 요구사항의 분류⭐

  • 참여자 관점
    • 사용자 요구사항 : 사용자의 관점에서 소프트웨어에 대해 원하는 사항들
    • 시스템 요구사항 : 설계자의 관점에서 하드웨어와 소프트웨어가 갖춰야 하는 것들
    • 소프트웨어 요구 사항 : 개발자의 관점에서 소프트웨어가 갖춰야 하는 사항들
  • 요구사항 내용의 종류⭐
    • 기능적 요구사항 : 소프트웨어를 구성하는 기능들이 무엇인지를 정의한 것
    • 비기능적 요구사항
      • 소프트웨어의 기능들에 대한 조건과 제약 사항들이 무엇인지 정의한 것
      • 보안, 성능, 품질, 안정성 등

2.2.4 요구사항 개발 프로세스 : 도분명확⭐

info-processing_2_1

  • 도출

    • 소프트웨어가 해결해야 할 문제를 이해하고 요구사항이 어디에 있고, 어떻게 수집할 것인가를 확인
    • 요구사항 도출 기법 :
      • 이해 관계자 분석 / 브레인 스토밍 / 인터뷰 / 문서 분석 및 검토
      • 포커스 그룹 / 인터페이스 분석 / 관찰 / 프로토타이핑 / 요구사항 워크숍 / 설문 조사

  • 분석

    • 요구사항들 간에 상충 되는 것을 해결
    • 소프트웨어의 범위를 파악
    • 업무환경과의 상호작용 파악(도메인 분석)
    • 구조적 분석 도구
      • DFD(Data Flow Diagram) : 자료 흐름도
      • Data Dictionary : 자료 사전
      • Mini-Spec : 소단위 명세서
      • ERD(Entity Relationship Diagram) : 개체 관계도
      • STD(State Transition Diagram) : 상태 전이도
    • 객체지향 분석 도구
      • UML(Unified Modeling Language)
      • 모델링

  • 명세

    • 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성
    • 시스템정의, 시스템 요구사항, 소프트웨어 요구사항을 작성
    • 요구사항 명세 기법
    • 산출물
      • 시스템 정의서 / 시스템 요구사항 명세서 / 소프트웨어 요구사항 명세서
구분정형 명세 기법⭐비정형 명세 기법⭐
기반수학, 논리학자연어, 그림 중심
작성기법수학적 기호, 정형화된 표기법일반 명사, 동사 등의 자연어를 기반으로서술하거나 다이어그램으로 작성
장점명세 오류 및 모호성 쉽게 파악사용자/개발자간 의사전달 용이
단점작성이 어렵고, 시간이 많이 소모내용이 모호하고, 완전한 검증이 곤란
언어 종류VDM, Z, Petri-net, CSPFSM, Decision Table, ER 모델링, State Chart(SADT) 등
  • 확인
    • 분석가가 요구사항을 이해했는지 확인(Validation)
    • 요구사항 문서가 일관성 있고 완전한지 검증(Verification)
    • 이해 관계자들이 문서를 검토하고, 형상관리를 수행

2.2.5 요구사항 분석 도구

(1) 요구사항 분석 CASE(Computer Aided Software Engineering) 도구

  • 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하는 도구

  • 소프트웨어 개발 전반에 걸쳐 적용된다.

  • CASE 도구의 분류

    분류설명
    상위 CASE- 생명주기 전반부에 사용되며, 소프트웨어의 계획과 요구분석, 설계 단계를 지원한다.
    - 모순검사, 오류검사, 자료흐름도 작성 등의 기능을 수행
    하위 CASE- 생명 주기 후반부에 사용되며, 코드의 작성과 테스트, 문서화 하는 과정을 지원한다.
    - 구문 편집기, 코드 생성기 등의 기능을 수행한다.
    통합 CASE소프트웨어 생명주기에 포함되는 전체 과정을 지원한다

  • 종류

    종류설명
    SADT- Structured Analaysis and Design Technique- SoftTech 사에서 개발
    - 시스템 정의, 요구사항 분석, 시스템/소프트웨어 설계를 이용되는 구조적 분석 및 설계도구
    SREM- Software Requirements Engineering Methodology
    - 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발
    PSL/PSA- 미시간 대학에서 개발한 것으로 PSL과 PSA를 사용하는 자동화 도구
    - PSL(Problem Statement Language) : 문제 기술언어
    - PSA(Problem Statement Analyzer) : PSL로 기술한 요구사항을 자동으로 분석해 다양한 보고서를 출력하는 문제 분석기
    TAGS- Technology for Automated Generation of Systems
    - 시스템 공학 방법 응용에 대한 자동 접근 방법
    - 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구

(2) HIPO(Hierarchy Inut Process Output)⭐

  • HIPO 의 개념
    • 하향식 소프트웨어 개발을 위한 문서화 도구
    • 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 계층구조를 표현한 도표
  • HIPO 의 기능
    • 분석 및 설계 도구로 사용된다.
    • 하향식 개발에 적합하다.
    • 체계적인 문서관리에 효율적이다.
    • 기능과 자료의 의존관계를 명시할 수 있다.
  • HIPO Chart 종류
종류설명
가시적 도표 (Visual Table of Content)- 시스템의 전체 기능과 흐름을 보여주는 Tree(계층) 구조
- 가시적 도표에는 입력, 처리, 출력 없음
총체적 도표 (Overview Diagram)- 프로그램을 구성하는 기능을 기술한 것
- 입력, 처리, 출력에 대한 전반적인 정보 제공
세부적 도표 (Detail Diagram)- 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표
- 총체적 도표와 같은 모양이지만 내용만 좀 더 복잡하게 들어간 형태

(3) NS chart(Nassi-Shneiderman / 나시 슈나이더만 차트)

info-processing_2_4

  • NS chart 의 개념
    • 논리의 기술에 중점을 두고 도형을 이용한 표현 방법이다
    • 프로그램의 처리 흐름을 상자 형태의 그림으로 나타낸 그림
    • 연속, 선택, 반복 등의 제어 논리 구조를 표현한다
  • 특징
    • 논리의 기술에 중점을 둔 도형을 이용한 표현 방법이다
    • 그리기가 어렵다.(전문성이 있어야 한다)
    • 순차, 선택, 반복으로 표현한다
    • 임의의 제어 이동이 어렵다(GOTO 구조 불가)
    • 이해하기 쉽고 코드 변환이 용이하다

2.3 요구사항 분석 모델링

2.3.1 모델링의 개념⭐

  • 복잡한 시스템을 쉽게 이해하기 위해 불필요한 부분을 생략하고 추상화하여 간단한 모델로 표현하는 것을 의미
  • 소프트웨어를 구성하는 모듈들을 식별하고, 이것들의 연결을 그림으로 표현
  • 요구분석 과정에 의해 수집된 개념과 정보를 분석하여 UML과 같은 방법을 이용하여 모델로 비주얼화

2.3.2 모델링이 주는 도움

  • 소프트웨어를 이해하는 데 도움
  • 이해관계자들 사이에서 문제를 해결 할 수 있도록 해준다.
  • 파악한 개념을 사용자와 고객에게 전달할 때 도움을 준다.
  • 설계, 구현, 테스팅, 유지보수에 개념적인 기준을 제공한다.

2.3.3 모델링 구분

  • 기능적 모델링 / 정적 모델링 / 동적 모델링

2.3.4 분석 모델의 종류

  • 구조적 분석 모델
  • 객체 지향 분석 모델
  • 정보공학 분석 모델
  • 정형화 분석 모델

2.3.5 구조적 분석 모델

(1) 구조적 분석 방법론

  • 도형화된 도구를 이용해 정형화된 분석 절차에 따라 사용자 요구사항을 파악하고 문서화하는 분석 기법
  • 하향식 기능 분해 기법 등을 사용하는 특성

(2) 구조적 분석 도구

(2-1) 자료 흐름도(DFD, Data Flow Diagram)⭐
  • 가장 보편적으로 사용되는 시스템 모델링 도구로서, 기능 중심의 시스템을 모델링 하는데 적합
  • 자료의 흐름과 처리 과정을 도형 중심으로 기술
  • 자료 흐름 그래프 또는 버블 차트라고도 함
  • 자료 흐름도 구성요소 : 프플스터⭐
    • Process / Data Flow / Data Store / Terminator

info-processing_2_5

(2-2) 자료사전(Data Dictionary, DD)⭐
  • 자료흐름도에 기술된 모든 자료들에 대한 사항을 자세히 정의
  • 자료사전 사용 기호

info-processing_2_6

(2-3) 소단위 명세서(Mini-Specification)
  • 자료 흐름도에서 어떤 일이 수행되는지를 정의하기 위해 각 처리들이 수행하는 업무를 상세하게 작성
  • 프로세스 명세서라고도 한다.
  • 소단위 명세서는 구조적 언어이고, 선후 조건문, 의사결정표 등이 사용
(2-4) 개체 관계도(Entity Relationship Diagram, ERD)⭐
  • 시스템에서 처리되는 개체(자료)와 개체의 구성과 속성, 개체 간의 관계를 표현하여 자료를 모델화 하는데 사용
  • 개체 관계도 구성 : 개속관
    • 개체 / 속성 / 관계

info-processing_2_7

(2-5) 상태 전이도(State Transition Diagram, STD)⭐
  • 시스템에 어떤 일이 발생할 경우 시스템의 상태와 상태 간의 전이를 모델화한 것으로, 상태 전이도를 통해 개발자는 시스템의 행위를 정의

2.3.6 객체 지향 분석 모델

(1) 객체 지향 분석

  • 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스, 이와 연관된 속성과 연산, 그들 간의관계등을 정의하여 모델링하는 작업
  • 상향식
  • UML 이용

(2) 객체지향 분석 방법론

(2-1) Rumbaugh(럼바우) 방법 : 객동기⭐
  • 가장 일반적으로 사용되는 방법, 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행
  • 분석 절차
종류설명
객체 모델링 (Object Modeling)- 시스템에서 요구되는 객체를 찾아내 속성과 연산 식별 및 객체들 간의 관계를 규정해 객체 다이어그램으로 표현⭐
- 세 가지 모델 중 가장 선행되어야 함
동적 모델링 (Dynamic Modeling)- 상태 다이어그램을 이용하여 시간의 흐름에 따라 제어 흐름, 동작 순서 등동적인 행위 표현⭐
- 객체나 클래스의 상태, 사건을 중심으로 표현
기능 모델링 (Functional Modeling)- 자료 흐름도(DFD)를 이용해 다수의 프로세스들 간의 자료 흐름을 중심으로치리 과정 표현⭐
- 어떤 데이터를 입력하여 어떤 결과를 구할 것인지를 표현
(2-2) Booch(부치) 방법

미시적 개발 프로세스와 거시적 개발 프로세스를 모두 사용하는 분석 방법

(2-3) Jacobson 방법

Use case를 강조하여 사용하는 분석 방법

(2-4) Coad와 Yourdon 방법

E-R 다이어그램을 사용하여 객체의 행위를 모델링, 객체 식별, 구조 식별, 주제 정의 등의 과정으로 구성하는 기법

(2-5) Wirfs-Brock 방법
  • 분석과 설계간 구분 없음
  • 고객 명세서를 평가해서 설계 작업까지 연속 적으로 수행
01-소프트웨어 공학03-소프트웨어 설계