요구사항 확인

JungWooLee·2022년 5월 22일
0

클래스 다이어그램

정적 모델링

  • 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것
  • 시스템에 의해 처리되거나 생성될 객체들 사이에 어떤 관련이 있는지를 구조적인 관점에서 표현
  • 정적 모델링은 객체들을 클래스로 추상화하여 표현
  • UML 의 대표적인 정적 모델링은 클래스 다이어그램

클래스 다이어그램

  • 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것
  • 시스템을 구성하는 용소에 대해 이해할 수 있는 구조적 다이어그램

클래스 다이어그램의 구성 요소

  1. 클래스
    • 각각의 객체들이 갖는 속성과 오퍼레이션을 표현한것
    • 3개의 구획으로 나눠 클래스의 이름, 속성, 오퍼레이션(메서드)을 표기
    • 속성 : 클래스의 상태나 정보를 표현
    • 오퍼레이션 : 클래스가 수행할 수 있는 동작으로, 함수(메서드)라고도 함
  2. 제약조건
    • 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적음
    • 클래스 안에 제약조건을 기술할 때는 중괄호 {}를 이용
  3. 관계
    • 클래스와 클래스 사이의 연관성을 표현
    • 클래스 다이어그램에 표현하는 관계에는 연관, 집합, 포함, 일반화, 의존 관계가 있음

연관 클래스

  • 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스
  • 두 클래스의 연관 관계를 나타내는 선의 가운데로부터 점선을 연관 클래스로 이어 표시

시퀀스 다이어그램

동적 모델링

  • 시스템의 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호 작용을 표현한 것
  • 시스템 내부 구성 요소들 간에 이루어지는 동작이라는 관점(view)에서 표현
  • 동적 모델링의 종류 : 시퀀스 다이어그램, 커뮤니케이션 다이어그램, 상태 다이어그램

시퀀스 다이어그램

  • 시스템이나 객체들이 메시지를 주고받으며 상호 작용하는 과정을 그림으로 표현한 것
  • 시스템이나 객체들의 상호 작용 과정에서 주고받는 메시지를 표현
  • 각 동작에 참여하는 시스템이나 객체들의 수행 기간을 확인할 수 있다
  • 클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호 작용을 표현

시퀀스 다이어그램의 구성 요소

  1. 액터 : 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미 (주로 클라이언트)
  2. 객체 : 메시지를 주고받는 주체
  3. 생명선
    • 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현
    • 객체 소멸(X)이 표시된 기간까지 존재
  4. 실행 상자 : 객체가 메시지를 주고받으며 구동되고 있음을 표현
  5. 메시지 : 객체가 상호 작용을 위해 주고받는 메시지
  6. 객체 소멸 : 해당 객체가 더 이상 메모리에 존재하지 않음을 표현
  7. 프레임 : 다이어그램의 전체 또는 일부를 묶어 표현한 것

커뮤니케이션 다이어그램

커뮤니케이션 다이어그램

  • 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것
  • 동작에 참여하는 객체들 사이의 관계를 파악하는 데 사용
  • 클래스 다이어그램에서 관계가 제대로 표현됐는지 점검하는 용도로도 사용

커뮤니케이션 다이어그램의 구성 요소

  1. 액터 : 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미
  2. 객체 : 메시지를 주고받는 주체
  3. 링크
    • 객체들 간의 관계를 표현한 것
    • 액터와 객체, 객체와 객체 간에 실선을 그어 표현
  4. 메시지
    • 객체가 상호 작용을 위해 주고받는 내용
    • 화살표의 방향은 메시지를 받는 쪽으로 향하게 표현
    • 일정한 순서에 의해 처리되는 메시지의 경우 숫자로 순서를 표시

상태 다이어그램

상태(State) 다이어그램

  • 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것
  • 객체의 상태란 객체가 갖는 속성 값의 변화를 의미
  • 특정 객체가 어떤 이벤트에 의해 상태 변환 과정이 진행되는지 확인하는 데 사용

상태 다이어그램의 구성 요소

  1. 상태 : 객체의 상태를 표현
  2. 시작 상태 : 상태의 시작을 표현
  3. 종료 상태 : 상태의 종료를 표현
  4. 상태 전환 : 상태 사이의 흐름, 변화를 화살표로 표현
  5. 이벤트
    • 상태에 변화를 주는 현상
    • 이벤트에는 조건, 외부 신호, 시간의 흐름 등이 있음
  6. 프레임 : 상태 다이어그램의 범위를 표현

패키지 다이어그램

패키지 다이어그램

  • 유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것
  • 정적 모델링의 하나로, 관련있는 객체들을 하나로 묶어 클래스보다 상위 개념인 패키지로 추상화한 것
  • 대규모 시스템에서 주요 요소 간의 종속성을 파악하는 데 사용

패키지 다이어그램의 구성 요소

  1. 패키지
    • 객체들을 그룹화한 것
    • 단순 표기법 : 패키지 안에 패키지 이름만 표현
    • 확장 표기법 : 패키지 안에 요소까지 표현
  2. 객체 : 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들
  3. 의존 관계
    • 패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결하여 표현
    • 스테레오타입을 이용해 의존 관계를 구체적으로 표현
    • 의존 관계의 표현 형태는 사용자가 임의로 작성할 수 있고, 대표적으로 import, access가 사용됨
      • ⟪import⟫ : 패키지에 포함된 객체들을 직접 가져와서 이용하는 관계
      • ⟪access⟫ : 인터페이스를 통해 패키지 내의 객체에 접근하여 이용하는 관계

소프트웨어 개발 방법론

소프트웨어 개발 방법론

  • 소프트웨어 개발, 유지보수 등에 필요한 여러가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것
  • 목적 : 소프트웨어의 생산성과 품질 향상
  • 주요 소프트웨어 개발 방법론 : 구조적 방법론, 정보공학 방법론, 객체지향 방법론, 컴포넌트 기반(CBD) 방법론, 제품 계열 방법론, 애자일 방법론

구조적 방법론

  • 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Precess) 중심의 방법론
  • 쉬운 이해 및 검증이 가능한 프로그램 코드를 생성하는 것이 목적
  • 복잡한 문제를 다루기 위해 분할과 정복 원리를 적용
  • 개발 절차 : 타당성 검토 → 계획 → 요구사항 → 설계 → 구현 → 시험 → 운용/유지보수

정보공학 방법론

  • 정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료(Data) 중심의 방법론
  • 대규모 정보 시스템을 구축하는데 적합
  • 개발 절차 : 정보 전략 계획 수립 → 업무 영역 분석 → 업무 시스템 설계 → 업무 시스템 구축

객체지향 방법론

  • 현실 세계의 개체(Entity) 를 기계의 부품처럼 하나의 객체로 만들어, 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
  • 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책
  • 구성 요소 : 객체, 클래스, 메시지
  • 기본 원칙 : 캡슐화, 정보 은닉, 추상화, 상속성, 다형성
  • 개발 절차 : 요구 분석 → 설계 → 구현 → 테스트 및 검증 → 인도

컴포넌트(CBD) 기반 방법론

  • 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
  • 컴포넌트의 재사용이 가능하여 시간과 노력을 절감
  • 새 기능을 추가하는 것이 간단 → 확장성 보장
  • 유지 보수 비용을 최소화하고 생산성 및 품질을 향상 시킴
  • 개발 절차 : 개발 준비 → 분석 → 설계 → 구현 → 테스트 → 전개 → 인도

제품 계열 방법론

  • 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
  • 임베디드 소프트웨어를 만드는데 적합
  • 영역공학과 응용공학으로 구분
    • 영역공학 : 영역 분석, 영역 설계, 핵심 자산을 구현
    • 응용공학 : 제품 요구 분석, 제품 설계, 제품을 구현

S/W 공학의 발전적 추세

소프트웨어 재사용

  • 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것
  • 소프트웨어 개발의 품질과 생산성을 높이기 위한 방법
  • 기존 개발된 소프트웨어와 경험, 지식 등을 새로운 소프트웨어에 적용
  • 소프트웨어 재사용 방법
    • 합성 중심 : 전자 칩과 같은 부품, 즉 블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법, 블록 구성 방법이라고도 함
    • 생성 중심 : 추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법으로, 패턴 구성 방법이라고도 함

소프트웨어 재공학

  • 새로운 요구에 맞도록 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것
  • 유지보수 비용이 소프트웨어 개발 비용의 대부분을 차지하기 때문에 유지보수의 생산성 향상을 통해 소프트웨어 위기를 해결하는 방법
  • 기존 소프트웨어의 데이터와 기능들의 개조 및 개선을 통해 유지보수성과 품질을 향상시킴
  • 이점 : 소프트웨어 품질 향상, 생산성 증가, 수명 연장, 오류 감소

CASE ( Computer Aided Software Engineering )

  • 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것
  • 객체지향 시스템, 구조적 시스템 등 다양한 시스템에서 활용되는 자동화 도구
  • 소프트웨어 생명 주기의 전체 단계를 연결하고 자동화하는 통합된 도구를 제공
  • 주요 기능
    • 소프트웨어 생명 주기 전 단계의 연결
    • 다양한 소프트웨어 개발 모형 지원
    • 그래픽 지원

비용 산정 기법 (하향식)

하향식 비용 산정 기법

  • 과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법
  • 프로젝트의 전체 비용을 산정한 후 각 작업별로 비용을 세분화
  • 하향식 비용 산정 기법 : 전문가 감정 기법, 델파이 기법

전문가 감정 기법

  • 조직 내에 있는 경험이 많은 두명 이상의 전문가에게 비용 산정을 의뢰하는 기법
  • 가장 편리하고 신속하게 비용 산정 가능
  • 개인적이고 주관적

델파이 기법

  • 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법
  • 전문가들의 편견이나 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성

비용 산정 기법 (상햑식)

상향식 비용 산정 기법

  • 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
  • 주요 상향식 비용 산정 기법 : LOC(원시 코드 라인 수)기법, 개발 단계별 인원수 기법, 수학적 산정 기법

LOC 기법

  • 소프트웨어 각 기능의 코드라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
  • 측정이 용이하고 이해하기 쉬워 가장 많이 사용
  • 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정
    예측치 = a+4m+b/6, 단 a:낙관치, b:비관치, m:기대치(중간치)
  • 산정 공식
    • 노력(인월) = 개발 기간 * 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수
    • 개발 비용 = 노력(인월) * 단위 비용(1인당 월평균 인건비)
    • 개발 기간 = 노력(인월) / 투입 인원
    • 생산성 = LOC / 노력(인월)

개발 단계별 인월수 기법

  • 개발 단계별 인월수 기법은 LOC 기법을 보완하기 위한 기법으로, 각 기능을 구현시키는 데 필요한 노력을 생명 주기의 각 단계별로 산정
  • LOC 기법보다 정확

수학적 산정 기법

수학적 산정 기법

  • 상향식 비용 산정 기법으로, 경험적 추정 모형, 실험적 추정 모형이라고도 한다
  • 수학적 산정 기법은 개발 비용 산정의 자동화를 목표로 함
  • 비용의 자동산정을 위해 사용되는 공식은 과거의 유사한 프로젝트를 기반으로 유도된 것
  • 주요 수학적 산정 기법 : COCOMO 모형,Putnam 모형,기능 점수(FP) 모형

COCOMO 모형

  • 원시 프로그램의 규모인 **LOC(원시 코드 라인 수)에 의한 비용 산정 기법
  • 개발할 소프트웨어의 규모(LOC)를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 산정
  • 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 나타냄
  • 보헴이 제안

COCOMO의 소프트웨어 개발 유형

  1. 조직형 (Organic Mode)
    • 기관 내부에서 개발된 중∙소 규모의 소프트웨어
    • 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리용 등의 5만 (50KDSI) 라인 이하의 소프트웨어를 개발하는 유형
    • 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합
  2. 반분리형 (Semi-Detached Mode)
    • 조직형과 내장형의 중간형 소프트웨어
    • 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만 라인 이하의 소프트웨어를 개발하는 유형
    • 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합
  3. 내장형 (Embedded Mode)
    • 초대형 규모의 소프트웨어
    • 트랜잭션 처리 시슽메이나 운영체제 등의 30만 라인 이상의 소프트웨어를 개발하는 유형
    • 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합

COCOMO 모형의 종류

  1. 기본형 : 소프트웨어의 크기와 개발 유형만을 이용하여 비용 산정
  2. 중간형 : 기본형 COCOMO의 공식을 토대로 사용하나 제품의 특성, 컴퓨터의 특성, 개발 요원의 특성, 프로젝트 특성에 의해 비용을 산정
  3. 발전형
    • 중간형 COCOMO를 보완하여 만들어진 모형
    • 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용 산정
    • 소프트웨어 환경과 구성 요소가 사전에 정의되어 있어야 하며, 개발 과정의 후반부에 주로 적용

Putnam 모형

  • 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
  • 푸트남이 제안한 것, 생명 주기 예측 모형이라고도 함
  • 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
  • 대형 프로젝트의 노력 분포 산정에 이용

기능점수 모형

  • 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며, 총 기능 점수와 영향도를 이용하여 기능 점수를 구한 후 이를 이용해서 비용을 산정하는 기법
  • 소프트웨어 기능 증대 요인 : 자료입력(입력 양식), 정보출력(출력 보고서), 명령어(사용자 질의수), 데이터 파일, 필요한 외부 루틴과의 인터페이스

비용 산정 자동화 추정 도구

  1. SLIM : Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구
  2. ESTIMACS : 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구

프로젝트 일정 계획

프로젝트 일정 계획

  • 프로젝트 일정 계획은 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하여 소작업의 순성와 일정을 정하는 것
  • 프로젝트 일정 계획에 사용되는 기능 : WBS, PERT/CPM, 간트 차트 등

PERT ( Program Evaluation and Review Technique, 프로그램 평가 및 검토 기술 )

  • 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크
  • 각 작업별로 단계를 나누어 종료 시기를 결정
    • 낙관적인 경우
    • 가능성이 있는 경우
    • 비관적인 경우
  • 개발 경험이 없어 소요 기간 예측이 어려운 프로젝트 일정 계획에 사용
  • 노드와 간선으로 구성되며 원 노드에는 작업, 간선에는 낙관치, 기대치, 비관치를 표시
  • 경정 경로, 작업에 대한 경계 시간, 작업 간의 상호 관련성 등을 알 수 있다
  • 작업 예측치 계산 공식
    작업 예측치 = 비관치+4*기대치+낙관치/6, 평방 편차=[(비관치-낙관치)/6]^2

CPM (Critical Path Method, 임계 경로 기법 )

  • 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
  • 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타냄
  • 원형 노드는 각각의 작업을 의미, 작업 이름과 소요 기간을 표시
  • 박스 노드는 이정표를 의미, 이정표 이름과 예상 완료 시간을 표시

간트 차트

  • 프로젝트의 각 작업들이 언제 시작하고 언제 종료되는지에 대한 작업 일정을 막대 도표를 잉요하여 표시하는 프로젝트 일정표
  • 시간선 차트라고도 함
  • 중간 목표 미달성 시 그 이유와 기간을 예측 가능
  • 사용자와의 문제점이나 예산의 초과 지출 등도 관리할 수 있게 한다
  • 자원 배치와 인원 계획에 유용하게 사용
  • 이정표, 작업 일정, 작업 기간, 산출물로 구성
  • 수평 막대의 길이는 각 작업의 기간을 나타냄

소프트웨어 개발 표준

소프트웨어 개발 표준

  • 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준을 의미
  • 주요 소프트웨어 개발 표준 : ISO/IEC 12207, CMMI, SPICE

ISO/IEC 12207

  • ISO(국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스
  • 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준을 제공
  • ISO/IEC 12207 구분
    • 기본 생명 주기 프로세스 : 획득, 공급, 개발, 운영 유지보수 프로세스
    • 지원 생명 주기 프로세스 : 품질 보증, 검증, 확인, 호라동 검토, 감사, 문서화, 형상관리, 문제 해결 프로세스
    • 조직 생명 주기 프로세스 : 관리, 기반 구조, 훈련, 개선 프로세스

CMMI

  • 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델
  • CMMI 의 소프트웨어 프로세스 성숙도
    1. 초기 : 정의된 프로세스 없음, 작업자 능력에 따라 성공 여부 결정
    2. 관리 : 규칙화된 프로세스, 특정한 프로젝트 내의 프로세스 정의 및 수행
    3. 정의 : 표준화된 프로세스, 조직의 표준 프로세스를 활용하여 업무 수행
    4. 정량적 관리 : 예측 가능한 프로세스, 프로젝트를 정량적으로 관리 및 통제
    5. 최적화 : 지속적 개선 프로세스, 프로세스 역량 향상을 위해 지속적인 프로세스 개선

SPICE

  • 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
  • ISO/IEC 15504

SPICE 의 구성

  • 고객-공급자 프로세스
    • 소프트웨어를 개발하여 고객에게 전달하는 것을 지원하고, 소프트웨어의 정확한 운용 및 사용을 위한 프로세스로 구성
    • 구성 용소 : 인수, 공급, 요구 도출, 운영
    • 프로세스 수 : 10개
  • 공학 프로세스
    • 시스템과 소프트웨어 제품의 명세화, 구현, 유지보수를 하는데 사용되는 프로세스로 구성
    • 구성 요소 : 개발, 소프트웨어 유지보수
    • 프로세스 수 : 9개
  • 자원 프로세스
    • 소프트웨어 생명 주기에서 다른 프로세스에 의해 이용되는 프로세스로 구성
    • 구성 요소 : 문서화, 형상, 품질 보증, 확인, 리뷰, 감사, 품질 문제 해결
    • 프로세스 수 : 8개
  • 관리 프로세스
    • 소프트웨어 생명 주기에서 프로젝트 관리자에 의해 사용되는 프로세스로 구성
    • 구성 요소 : 관리, 프로젝트 관리, 품질 및 위험 관리
    • 프로세스 수 : 4개
  • 조직 프로세스
    • 조직의 업무 목적 수립과 조직의 업무 목표를 달성을 위한 프로세스로 구성
    • 구성 요소 : 조직 배치, 개선 활동 프로세스, 인력 관리, 기반 관리, 측정 도구, 재사용
    • 프로세스 수 : 9개

SPICE 수행 능력 단계

  1. 불완전 : 프로세스가 구현되지 않았거나 목적을 달성하지 못한 단계
  2. 수행 : 프로세스가 수행되고 목적이 달성된 단계
  3. 관리 : 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계
  4. 확립 : 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행되는 단계
  5. 예측 : 프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계
  6. 최적화 : 프로세스 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계

소프트웨어 개발 프레임 워크

소프트웨어 개발 프레임워크

  • 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템
  • 선행 사업자의 기술에 의존하지 않는 표준화된 개발 기반으로 인해 사업자 종속성 해소
  • 소프트웨어 개발 프레임워크의 주요 기능 : 예외 처리, 트랜잭션 처리, 메모리 공유, 데이터 소스 관리, 서비스 관리, 쿼리 서비스, 로깅 서비스, 사용자 인증 서비스
  • 소프트웨어 개발 프레임워크의 종류 : 스프링, 전자정부, 닷넷

스프링 프레임워크

  • 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크
  • 동적인 웹 사이트의 개발을 위해 다양한 서비스를 제공
  • 전자정부 표준 프레임워크의 기반 기술로 사용

전자정부 프레임워크

  • 대한민국의 공공부문 정보화 사업 시 효율적인 정보 시스템의 구축을 지원하기 위해 필요한 기능 및 아키텍처를 제공하는 프레임워크
  • 개발 프레임워크의 표준 정립으로 응용 소프트웨어의 표준화, 품질 및 재사용성의 향상을 목적으로 함
  • 오픈 소스 기반의 범용화를 이룰 수 있음

닷넷 프레임워크

  • Windows 프로그램의 개발 및 실행 환경을 제공하는 프레임워크
  • Microsoft 사에서 통합 인터넷 전략을 위해 개발
  • 코드 실행을 관리하는 CLR (Common Language Runtime, 공용 언어 런타임) 이라는 이름의 가상머신 상에서 작동

소프트웨어 개발 프레임워크의 특성

  • 모듈화
    • 프레임워크는 캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소화함으로써 소프트웨어의 품질을 향상시킴
    • 프레임워크는 개발 표준에 의한 모듈화로 인해 유지 보수가 용이
  • 재사용성 : 프레임 워크는 재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증이 가능
  • 확장성 : 프레임워크는 다형성을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발이 가능
  • 제어의 역흐름 : 개발자가 관리하고 통제해야 하는 객체들의 제어를 프레임워크에 넘김으로써 생산성을 향상시킴

0개의 댓글