클래스 다이어그램
정적 모델링
- 사용자가 요구한 기능을 구현하는데 필요한 자료들의
논리적
인 구조를 표현한 것
- 시스템에 의해 처리되거나 생성될 객체들 사이에 어떤 관련이 있는지를 구조적인 관점에서 표현
- 정적 모델링은 객체들을 클래스로 추상화하여 표현
- UML 의 대표적인 정적 모델링은 클래스 다이어그램
클래스 다이어그램
- 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것
- 시스템을 구성하는 용소에 대해 이해할 수 있는 구조적 다이어그램
클래스 다이어그램의 구성 요소
- 클래스
- 각각의 객체들이 갖는 속성과 오퍼레이션을 표현한것
- 3개의 구획으로 나눠 클래스의 이름, 속성, 오퍼레이션(메서드)을 표기
- 속성 : 클래스의 상태나 정보를 표현
- 오퍼레이션 : 클래스가 수행할 수 있는 동작으로, 함수(메서드)라고도 함
- 제약조건
- 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적음
- 클래스 안에 제약조건을 기술할 때는 중괄호
{}
를 이용
- 관계
- 클래스와 클래스 사이의 연관성을 표현
- 클래스 다이어그램에 표현하는 관계에는 연관, 집합, 포함, 일반화, 의존 관계가 있음
연관 클래스
- 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스
- 두 클래스의 연관 관계를 나타내는 선의 가운데로부터 점선을 연관 클래스로 이어 표시
시퀀스 다이어그램
동적 모델링
- 시스템의 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호 작용을 표현한 것
- 시스템 내부 구성 요소들 간에 이루어지는 동작이라는 관점(
view
)에서 표현
- 동적 모델링의 종류 :
시퀀스 다이어그램
, 커뮤니케이션 다이어그램
, 상태 다이어그램
시퀀스 다이어그램
- 시스템이나 객체들이 메시지를 주고받으며 상호 작용하는 과정을 그림으로 표현한 것
- 시스템이나 객체들의 상호 작용 과정에서 주고받는 메시지를 표현
- 각 동작에 참여하는 시스템이나 객체들의 수행 기간을 확인할 수 있다
- 클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호 작용을 표현
시퀀스 다이어그램의 구성 요소
액터
: 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미 (주로 클라이언트)
객체
: 메시지를 주고받는 주체
생명선
- 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현
- 객체 소멸(
X
)이 표시된 기간까지 존재
실행 상자
: 객체가 메시지를 주고받으며 구동되고 있음을 표현
메시지
: 객체가 상호 작용을 위해 주고받는 메시지
객체 소멸
: 해당 객체가 더 이상 메모리에 존재하지 않음을 표현
프레임
: 다이어그램의 전체 또는 일부를 묶어 표현한 것
커뮤니케이션 다이어그램
커뮤니케이션 다이어그램
- 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것
- 동작에 참여하는 객체들 사이의 관계를 파악하는 데 사용
- 클래스 다이어그램에서 관계가 제대로 표현됐는지 점검하는 용도로도 사용
커뮤니케이션 다이어그램의 구성 요소
액터
: 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미
객체
: 메시지를 주고받는 주체
링크
- 객체들 간의 관계를 표현한 것
- 액터와 객체, 객체와 객체 간에 실선을 그어 표현
메시지
- 객체가 상호 작용을 위해 주고받는 내용
- 화살표의 방향은 메시지를 받는 쪽으로 향하게 표현
- 일정한 순서에 의해 처리되는 메시지의 경우 숫자로 순서를 표시
상태 다이어그램
상태(State) 다이어그램
- 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것
- 객체의 상태란 객체가 갖는 속성 값의 변화를 의미
- 특정 객체가 어떤 이벤트에 의해 상태 변환 과정이 진행되는지 확인하는 데 사용
상태 다이어그램의 구성 요소
상태
: 객체의 상태를 표현
시작 상태
: 상태의 시작을 표현
종료 상태
: 상태의 종료를 표현
상태 전환
: 상태 사이의 흐름, 변화를 화살표로 표현
이벤트
- 상태에 변화를 주는 현상
- 이벤트에는 조건, 외부 신호, 시간의 흐름 등이 있음
프레임
: 상태 다이어그램의 범위를 표현
패키지 다이어그램
패키지 다이어그램
- 유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것
- 정적 모델링의 하나로, 관련있는 객체들을 하나로 묶어 클래스보다 상위 개념인 패키지로 추상화한 것
- 대규모 시스템에서 주요 요소 간의 종속성을 파악하는 데 사용
패키지 다이어그램의 구성 요소
패키지
- 객체들을 그룹화한 것
- 단순 표기법 : 패키지 안에 패키지 이름만 표현
- 확장 표기법 : 패키지 안에 요소까지 표현
객체
: 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들
의존 관계
- 패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결하여 표현
- 스테레오타입을 이용해 의존 관계를 구체적으로 표현
- 의존 관계의 표현 형태는 사용자가 임의로 작성할 수 있고, 대표적으로 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의 소프트웨어 개발 유형
- 조직형 (Organic Mode)
- 기관 내부에서 개발된 중∙소 규모의 소프트웨어
- 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리용 등의 5만 (50KDSI) 라인 이하의 소프트웨어를 개발하는 유형
- 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합
- 반분리형 (Semi-Detached Mode)
- 조직형과 내장형의 중간형 소프트웨어
- 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만 라인 이하의 소프트웨어를 개발하는 유형
- 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합
- 내장형 (Embedded Mode)
- 초대형 규모의 소프트웨어
- 트랜잭션 처리 시슽메이나 운영체제 등의 30만 라인 이상의 소프트웨어를 개발하는 유형
- 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합
COCOMO 모형의 종류
- 기본형 : 소프트웨어의 크기와 개발 유형만을 이용하여 비용 산정
- 중간형 : 기본형 COCOMO의 공식을 토대로 사용하나 제품의 특성, 컴퓨터의 특성, 개발 요원의 특성, 프로젝트 특성에 의해 비용을 산정
- 발전형
- 중간형 COCOMO를 보완하여 만들어진 모형
- 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용 산정
- 소프트웨어 환경과 구성 요소가 사전에 정의되어 있어야 하며, 개발 과정의 후반부에 주로 적용
Putnam 모형
- 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
- 푸트남이 제안한 것, 생명 주기 예측 모형이라고도 함
- 시간에 따른 함수로 표현되는
Rayleigh-Norden 곡선
의 노력 분포도를 기초로 함
- 대형 프로젝트의 노력 분포 산정에 이용
기능점수 모형
- 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며, 총 기능 점수와 영향도를 이용하여 기능 점수를 구한 후 이를 이용해서 비용을 산정하는 기법
- 소프트웨어 기능 증대 요인 : 자료입력(입력 양식), 정보출력(출력 보고서), 명령어(사용자 질의수), 데이터 파일, 필요한 외부 루틴과의 인터페이스
비용 산정 자동화 추정 도구
- SLIM : Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구
- 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 의 소프트웨어 프로세스 성숙도
- 초기 : 정의된 프로세스 없음, 작업자 능력에 따라 성공 여부 결정
- 관리 : 규칙화된 프로세스, 특정한 프로젝트 내의 프로세스 정의 및 수행
- 정의 : 표준화된 프로세스, 조직의 표준 프로세스를 활용하여 업무 수행
- 정량적 관리 : 예측 가능한 프로세스, 프로젝트를 정량적으로 관리 및 통제
- 최적화 : 지속적 개선 프로세스, 프로세스 역량 향상을 위해 지속적인 프로세스 개선
SPICE
- 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
- ISO/IEC 15504
SPICE 의 구성
- 고객-공급자 프로세스
- 소프트웨어를 개발하여 고객에게 전달하는 것을 지원하고, 소프트웨어의 정확한 운용 및 사용을 위한 프로세스로 구성
- 구성 용소 : 인수, 공급, 요구 도출, 운영
- 프로세스 수 : 10개
- 공학 프로세스
- 시스템과 소프트웨어 제품의 명세화, 구현, 유지보수를 하는데 사용되는 프로세스로 구성
- 구성 요소 : 개발, 소프트웨어 유지보수
- 프로세스 수 : 9개
- 자원 프로세스
- 소프트웨어 생명 주기에서 다른 프로세스에 의해 이용되는 프로세스로 구성
- 구성 요소 : 문서화, 형상, 품질 보증, 확인, 리뷰, 감사, 품질 문제 해결
- 프로세스 수 : 8개
- 관리 프로세스
- 소프트웨어 생명 주기에서 프로젝트 관리자에 의해 사용되는 프로세스로 구성
- 구성 요소 : 관리, 프로젝트 관리, 품질 및 위험 관리
- 프로세스 수 : 4개
- 조직 프로세스
- 조직의 업무 목적 수립과 조직의 업무 목표를 달성을 위한 프로세스로 구성
- 구성 요소 : 조직 배치, 개선 활동 프로세스, 인력 관리, 기반 관리, 측정 도구, 재사용
- 프로세스 수 : 9개
SPICE 수행 능력 단계
- 불완전 : 프로세스가 구현되지 않았거나 목적을 달성하지 못한 단계
- 수행 : 프로세스가 수행되고 목적이 달성된 단계
- 관리 : 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계
- 확립 : 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행되는 단계
- 예측 : 프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계
- 최적화 : 프로세스 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계
소프트웨어 개발 프레임 워크
소프트웨어 개발 프레임워크
- 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템
- 선행 사업자의 기술에 의존하지 않는 표준화된 개발 기반으로 인해 사업자 종속성 해소
- 소프트웨어 개발 프레임워크의 주요 기능 : 예외 처리, 트랜잭션 처리, 메모리 공유, 데이터 소스 관리, 서비스 관리, 쿼리 서비스, 로깅 서비스, 사용자 인증 서비스
- 소프트웨어 개발 프레임워크의 종류 :
스프링
, 전자정부
, 닷넷
스프링 프레임워크
- 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크
- 동적인 웹 사이트의 개발을 위해 다양한 서비스를 제공
- 전자정부 표준 프레임워크의 기반 기술로 사용
전자정부 프레임워크
- 대한민국의 공공부문 정보화 사업 시 효율적인 정보 시스템의 구축을 지원하기 위해 필요한 기능 및 아키텍처를 제공하는 프레임워크
- 개발 프레임워크의 표준 정립으로 응용 소프트웨어의 표준화, 품질 및 재사용성의 향상을 목적으로 함
- 오픈 소스 기반의 범용화를 이룰 수 있음
닷넷 프레임워크
- Windows 프로그램의 개발 및 실행 환경을 제공하는 프레임워크
- Microsoft 사에서 통합 인터넷 전략을 위해 개발
- 코드 실행을 관리하는 CLR (Common Language Runtime, 공용 언어 런타임) 이라는 이름의 가상머신 상에서 작동
소프트웨어 개발 프레임워크의 특성
- 모듈화
- 프레임워크는 캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소화함으로써 소프트웨어의 품질을 향상시킴
- 프레임워크는 개발 표준에 의한 모듈화로 인해 유지 보수가 용이
- 재사용성 : 프레임 워크는 재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증이 가능
- 확장성 : 프레임워크는 다형성을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발이 가능
- 제어의 역흐름 : 개발자가 관리하고 통제해야 하는 객체들의 제어를 프레임워크에 넘김으로써 생산성을 향상시킴