35. 소프트웨어 개발 방법론 활용
소프트웨어 개발 방법론 선정
소프트웨어 공학 | Software Engineering
정의
소프트웨어 위기를 극복하고 효율적으로 품질 높은 소프트웨어를 개발하기 위한 학문
소프트웨어를 개발하는데 있어서 어떻게 개발할지, 무엇을 개발할지와 같은 방법 도구, 이론을 모두 포함한 포괄적 개념
원인
소프트웨어 특성에 대한 이해 부족
소프트웨어 관리 방법론 부재
올바른 설계 없이 프로그래밍에만 치중
소프트웨어 개발에 대한 전문적 교육 부족
작업일정과 비용의 추정치가 부정확
결과
개발 인력의 부족과 인건비 상승
소프트웨어 성능 및 신뢰성 부족
개발 기간 및 비용의 증가
소프트웨어 품질저하 및 유지보수 비용 증가
소프트웨어의 생산성 저하
소프트웨어 공학의 3R
정의
- 완성된 소프트웨어를 기반으로 역공학, 재공학, 재사용을 통해 소프트웨어의 생산성을 극대화하는 기법
필요성
소프트웨어 유지보수 효율성 향상 및 비용 절감
소프트웨어 개발 생산성 향상
소프트웨어 이해, 변경, 테스트 용이
소프트웨어 변경 요구사항에 대한 신속한 대응
소프트웨어 위기 극복
역공학 | Reverse Engineering
기존 개발된 시스템을 CASE 도구를 이용하여 사양서, 설계서 등의 문서로 추출하는 작업
개발 단계를 역으로 올라가 기존 개발된 시스템의 코드나 데이터로부터 설계 명세서나 요구 분석서 등을 도출하는 작업
특징
상용화되거나 기 개발된 소프트웨어의 분석을 도움
기존 시스템의 자료와 정보를 설계 수준에서 분석 가능해 유지보수성 향상
기존 시스템 정보를 Repository에 보관하여 CASE의 사용을 용이하게 함
재공학 | Re-engineering
- 기존 시스템을 널리 사용되는 프로그래밍 표준에 맞추거나 고수준의 언어로 재구성하고, 이기종에서 사용할 수 있도록 변환하는 작업
특징
현 시스템의 유지보수성 향상
시스템의 이해와 변형을 용이하게 하며, 유지보수 비용 및 시간 절감
표준 준수 및 CASE의 사용이 용이
과정
분석 Analysis 재구성 Restructuring 역공학 Reverse Engineering 이관 Migration
재사용 | Reuse
- 이미 개발되어 그 기능, 성능 및 품질을 인정받았던 소프트웨어의 전체 또는 일부분을 다시 사용
특징
소프트웨어 생산의 TCO(Total Cost Overhead) 절감
높은 품질의 소프트웨어 생산을 위한 공유 및 활용 효과
범위
함수와 객체 재사용 : 클래스나 함수 단위로 구현한 소스코드를 재사용
컴포넌트 재사용
애플리케이션 재사용
방법
합성 중심 | Composition Based: 전자 침과 같은 소프트웨어 부품, 즉 블록(모듈)을 만들어서 끼워 맞추어 소프트웨어를 완성시키는 방법생성 중심 | Generation Based: 추상화 형태로 쓰여진 명세를 구체화하여 프로그램을 만드는 방법
소프트웨어 개발 단계
1. 계획
무엇을 개발할 것인지 명확하게 정의
개발 범위를 결정
시스템의 성격을 파악하여 비용과 기간을 예측
2. 요구사항 분석 | Requirements Analysis
개발할 소프트웨어의 기능과 제약조건, 목표 등을 고객과 함께 정의
요구사항의 정확한 이해 및 요구사항 유도
과다하거나 불필요한 요구사항에 대한 협상 및 조율
요구사항의 적합성 검토 및 향후 예측
현재 실행 환경에 대한 분석
3. 소프트웨어 설계 | Design
시스템이 어떻게 동작하는지를 정의
요구사항 분석 단계에서 산출된 요구사항을 기준으로 입력자료, 처리내용, 출력자료 등을 정의
설계 구분
시스템 구조 설계 : 모듈 간의 관계와 구조 설계
프로그램 설계 : 각 모듈의 처리 절차나 알고리즘 설계
사용자 인터페이스 설계 : 사용자가 시스템을 사용하기 위해 보여지는 부분을 설계
4. 구현 | Development
프로그래밍 언어를 이용하여 실제로 프로그램을 작성
코딩과 디버깅이 이루어지며, 단위(모듈) 테스트를 진행
5. 테스트 | Testing
구현된 소프트웨어가 요구사항을 만족하는지 검사
실행 결과가 예상 결과와 맞는지 검사하고 평가
테스트 계획, 통합 텧스트 결과서 등을 작성
6. 유지보수 | Maintenance
소프트웨어를 사용하며 문제점을 수정하고 새로운 기능을 추가
소프트웨어를 좀 더 발전시키는 단계
소프트웨어 개발 단계에서 가장 많은 비용이 소요되는 단계
수정 보수 | Corrective Maintenance
- 소프트웨어 구축 시 테스트 단계에 미처 발견하지 못한 잠재적인 오류를 찾아 수정
- 수리 보수, 수정 보수, 정정 보수, 하자 보수라고도 함
적응 보수 | Adaptive Maintenance
- 운영체제, 하드웨어와 같은 프로그램 환경변화에 맞추기 위해 수행하는 유지보수
향상 보수 | Perfective Maintenance
- 기존 기능과 다른 새로운 기능을 추가하거나, 기존 기능을 개선
- 소프트웨어 확장 및 리모델링
- 유지보수 활동 중 가장 자원이 많이 소모되는 활동
예방 보수 | Preventive Maintenance
- 장래에 유지보수성 또는 신뢰성을 보장하기 위해 선제적으로 하는 유지보수
- 소프트웨어의 잠재적인 오류발생에 대비하여 미리 예방수단을 강구해 두는 유지보수
- 소프트웨어 재공학과 관련된 유지보수
소프트웨어 개발 방법론
개념
- 소프트웨어 개발에 필요한 과정(절차, 방법, 산출물, 기법, 도구)들을 체계적으로 정리한 것
발전 과정
1960년대
컴퓨터는 대용량 계산을 하거나 주로 군사적으로 사용하던 시절
주로 기계어를 사용하였으며 개발방법론이 없음
1970년대
고급언어를 사용
컴퓨터가 점차 전문영역으로 확대
민간 영역으로 컴퓨터가 활용되며 고객의 요구사항이 발생
소프트웨어 위기론이 대두
1980년대
PC의 대중화
고객의 요구사항이 복잡해지며 생명주기 관점으로 소프트웨어 개발 방법론이 대두
1990년대
프로젝트의 효율성과 생산성에 초점
객체지향언어가 많이 사용
컴포넌트 기반 방법론인 CBD가 기반
2000년대
웹 어플리케이션 중심으로 변화
쉬운 개발을 선호하게 되면서 자동화 도구가 발전
현재
고객의 요구사항뿐 아니라 개발자의 편의성 고려
툴의 비약적인 발전으로 여러 개발 언어들이 하나의 플랫폼 아래에서 작성
종류
구조적 방법론
절차지향 소프트웨어 개발 방법론
제한된 구조에서 코드 생성 및 순차적 실행
구성요소 : 데이터 흐름도(DFD), 자료사전(DD), 상태전이도(STD), 소단위 명세서(Mini-spec)
대표적 모델링 : 폭포수 모델
개발 과정
요구사항 분석
- 고객의 요구사항을 끌어내어 명세화 하는 과정
구조적 분석
- 고객이 원하는 기능, 환경 데이터를 종합하여 데이터 흐름도 작성
구조적 설계
- 모듈 중심 설계 과정
구조적 프로그래밍
- 순차, 선택, 반복의 논리 구조 구성으로 프로그램 작성
정보공학 방법론
기업의 주요 부분을 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합, 적용하는 데이터 중심 방법론
빠른 결과물 확인이 가능하며 단순 S/W개발이 아닌 기업의 경영전략에 초점
개발 과정
정보전략계획 수립단계
- 현행 업무프로세스와 시스템을 분석하고 미래 아키텍처와 전략계획을 수립
업무영역 분석단계
- 기업의 업무 현황을 분석해서 개념 수준의 데이터와 프로세스를 설계하는 업무분석 단계
- 데이터 모델링 : 개체-관계 모델(ERD)
- 프로세스 모델링 : 프로세스 계층도(PHD), 프로세스 의존도(PDD), 자료흐름도(DFD)
시스템 설계단계
- 실질적으로 시스템을 설계하는 단계
- 논리적 ER 다이어그램으로 데이터를 설계하고 분할 다이어그램, 액션 다이어그램, 의존 다이어그램을 사용해 프로세스를 설계
시스템 구축단계
- 설계명세서를 토대로 DB를 생성하고, 소스코드를 구현
객체지향 개발 방법론
현실세계의 개체를 속성과 메서드 형태로 표현
객체, 클래스 간의 관계를 식별하여 설계 모델로 변환하는 방법론
분석과 설계, 구현의 전 과정을 객체 중심으로 개발
전체 프로세스 방향성 유지와 상속에 의한 재사용성 향상
특징 : 캡슐화, 정보은닉, 상속, 다형성, 추상화
CBD 분석 방법론 | Component Based Development
재사용 가능한 컴포넌트의 개발 또는 상용 컴포넌트를 조합해 어플리케이션 개발
새로운 기능 추가가 쉬운 확장성
생산성 및 품질이 향상
시스템 유지보수 비용 최소화
애자일 방법론
기존 방법론들의 절차를 중시한 나머지 변화에 빠른 대응을 할 수 없는 단점 개선을 위해 등장
애자일 방법론 종류 : XP, SCRUM, FDD, Crystal 방법론 등
개발 방법론 선택 기준
프로젝트 특성 및 규모
프로젝트 참여자의 수준
가용 자원의 정도(인력, 장비, 시간, 비용)
요구사항의 명확도
위험도
소프트웨어 개발 수명 주기 | Software Development Life Cycle
소프트웨어를 제작하는 과정
소프트웨어 기획, 개발부터 폐기까지의 전 과정
정의 단계
- 개발할 소프트웨어가 경제적, 기술적으로 구축이 가능한지, 가치가 있는지 검토
- 개발에 필요한 인력, 기간, 비용 등 대략적인 계획 수립
- 고객의 요구사항 분석
개발 단계
- 설계와 구현, 테스트를 진행
유지보수 단계
- 개발된 소프트웨어에 대한 수정 및 변경사항을 처리
- 가장 오랜 시간을 가지며, 비용이 가장 많이 들어가는 단계
소프트웨어 개발 모델
폭포수 모델 | Waterfall Model
계획, 분석, 설계, 구현, 테스트, 운영 등 전 과정을 순차적으로 접근하는 개발 모델
각 단계의 검증 후에 다음 단계를 진행
각 단계가 순차적으로 진행되며, 병행되거나 거슬러 반복 진행되지 않음
가장 오래된 모형으로 적용 경험과 성공사례가 많음
요구사항의 변경이 어려움
단계별 정의가 분명하고, 단계별 산출물이 명확
프로토타이핑 모델 | Prototyping Model
고객이 요구한 주요 기능을 프로토타입으로 구현하여 완성해가는 모델
개발자가 구축할 소프트웨어의 모델을 사전에 만들어 요구사항을 효과적으로 유도하고 수집
프로토타이핑에 의해 만들어진 프로토타입은 폐기될 수 있고, 재사용될 수도 있음
순서
- 계획 수립
- 프로토타입 개발
- 사용자 평가
- 구현
- 인수
장점
사용자의 요구사항을 충실히 반영
비교적 빠른 기간 안에 사용자가 평가할 수 있는 결과물 제작
오류를 초기에 발견 가능
변경이 용이
단점
최종적으로 시간과 비용이 훨씬 많이 들 수 있음
사용자가 실제 제품과 혼동할 수 있음
문서작성이 소홀해질 수 있음
프로토타입 폐기에 따른 비용 발생
나선형 모델 | Sprial Model
폭포수 모델과 프로토타이핑 모델의 장점을 수용하고, 위험 분석을 추가한 점증적 개발 모델
프로젝트 수행 시 발생하는 위험을 관리하고 최소화하려는 것이 목적
대규모 프로젝트 및 위험 부담이 큰 시스템 개발에 적합
순서
- 계획 및 요구분석
- 위험 분석
- 개발(구현) 및 테스트
- 사용자 평가
장점
위험분석 과정으로 위험성이 큰 프로젝트를 수행할 수 있음
고객의 요구사항을 보다 더 상세히 적용 가능
단점
시간과 비용이 많이 소요
반복 단계가 길어질수록 프로젝트 관리가 어려움
RAD Model | Rapid Application Development
매우 짧은 개발 주기를 강조하는 점진적 소프트웨어 개발 방식
강력한 소프트웨어 개발 도구를 이용하여 매우 짧은 주기로 개발을 진행하는 순차적 소프트웨어 개발 프로세스
CASE 도구를 이용해 시스템을 개발
개발 기간이 60~90일 정도 짧음
기술적으로 위험이 적고 빠른 개발이 요구될 때 사용이 적합
V Model
폭포수 몯레에 시스템 검증과 테스트 작업을 강조
높은 신뢰성이 요구되는 분야에 적합
단계
- 요구 분석
- 아키텍처 설계
- 모듈 설계
- 구현
- 단위 테스트
- 통합 테스트
- 시스템 테스트
- 인수 테스트
4세대 기법 | 4th Generation Techniques
- CASE 등의 자동화도구를 이용하여 요구사항 명세로부터 원시코드를 자동으로 생성
소프트웨어 개발 비용 계획
- 개발에 소요되는 인원, 자원, 기간 등으로 소프트웨어의 규모를 파악하여, 필요한 비용을 산정
결정 요소
개발자의 역량
소프트웨어의 복잡도
소프트웨어의 크기
개발 기간
요구되는 신뢰도 수준
기술 수준
하향식 산정 기법
- 과거의 유사 경험을 바탕으로 회의를 통해 비용을 산정
전문가 판단 기법
- 조직 내 경험이 있는 전문가에게 비용 산정을 의뢰한 것
델파이 기법
- 여러 전문가의 의견을 종합하여 판단하는 기법
- 특정 전문가의 주관적인 편견을 보완하기 위해 여러 명의 전문가로 구성
상향식 산정 기법
- 프로젝트의 세부 작업 단위별로 비용을 산정한 후 전체 비용을 합산하는 기법
개발 단계별 노력 기법 | Effort Per Task
- LOC 기법을 확장한 기법
- 코딩 단계뿐만 아니라 SW 개발 생명주기 각 단계별로 적용시켜 모든 단계의 비용을 산정하는 기법
원시 코드 라인 수 기법 | Line Of Code
- 각 기능의 원시 코드 라인 수의 비관치(가장 많은 라인 수), 낙관치(가장 적은 라인 수), 중간치(기대치, 평균 라인 수)를 측정 후 예측치를 구하고, 이를 이용해 비용을 산정하는 기법
- 추정 LOC : (낙관치 + (4 * 중간치) + 비관치) / 6
LOC 기법의 4가지 비용 산정
노력(M/M) = 개발기간 + 투입인원(추정 LOC / 1인당 월 평균 생산 코드)
개발 비용 = 노력(M/M) * 단위비용(1인당 월평균 인건비)
개발 기간 = 노력(M/M) / 투입인원
생산성 = LOC / 노력(M/M)
수학적 산정 기법
COCOMO 기법
개발할 S/W의 규모를 예측한 후 S/W 종류에 따라 각 비용 산정 공식에 대입하여 비용을 산정
LOC 기법을 S/W 종류에 따라 다르게 적용
개발 유형
조직형 | Organic Mode
- 5만 라인 이하의 프로젝트
- 일반 업무용 소프트웨어
반분리형 | Semidetached Mode
- 30만 라인 이하의 프로젝트
- 운영체제, DBMS 등
내장형 | Embedded Mode
- 30만 라인 이상의 프로젝트
- 미사일 유도 시스템, 신호기 제어 시스템 등
모델
기본형 | Basic COCOMO
- S/W 크기(LOC) + 개발유형만을 이용하여 비용 산정
- LOC에 의존
중간형 | Intermediate COCOMO
- 기본형 모델 + 가중치
- 가중치
- 제품 속성 : 신뢰도, DB 크기, 복잡도
- H/W 속성 : 수행시간 등
- 개발자 속성 : 개발자의 경험과 역량
- 프로젝트 속성 : 개발 기간, 개발 도구, 방법론
발전형 | Detailed COCOMO
- 중간형 모델 + 시스템 세분화
Putnam 기법
Putnam이 제안한 생명 주기 예측 모형
소프트웨어 생명 주기의 전 과정 동안의 노력의 분포를 가정해주는 모형
시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
대형 프로젝트에서 이용되는 기법
개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소
SLIM : Rayleigh-Norden 곡선과 Putnam 예측 모형을 기초로 개발한 자동화 추정도구
기능 점수 기법 | Function Point
소프트웨어가 가지는 기능의 개수를 기준으로, 소프트웨어의 규모를 측정하는 기법
1979년 IBM사의 A.J.Albrecht가 고안한 방식
객관적이고 정량적인 소프트웨어의 규모를 산출할 수 있게 됨
ESTIMACS : FP모형을 기초로 개발된 자동화 췅 도구
소프트웨어 기능 분류
기능점수
- 데이터 기능
내부논리파일 ILF
외부연계파일 EIF - 트랜잭션 기능
외부입력 EI
외부출력 EQ
외부조회 EQ 비용 산정에 이용되는 요소
- 자료 입력(입력 양식)
- 정보 출력(출력 보고서)
- 명령어(사용자 질의수)
- 데이터 파일
- 필요한 외부 루틴과의 인터페이스
소프트웨어 개발 일정 계획
- 소프트웨어를 개발하기 위해 어떤 작업이 필요한지 정의하고, 작업들의 우선순위를 정하여 프로젝트 일정에 대한 계획을 세우는 것
작업 순서
작업 분해 Work Breakdown Structure - CPM 네트워크 작성
- 최소 소요 기간을 계산
- 소요 M/M, 기간 산정하여 CPM 수정
- 간트 차트로 표현
WBS | Work Breakdown Structure
- 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화 하는 작업
작성 방법
전체를 큰 단위로 분할
각각의 부분에 대해 좀 더 작은 단위로 분해하여 계층적으로 표현
담당인원을 배치해 구성도 작성
역할
프로젝트에서 수행할 업무를 식별
일정계획과 산정
전체일정 진행상황 파악
이해당사자들 간의 의사소통
Network Chart | PERT / CPM
PERT
미 해군의 Polaris 미사일 개발 프로젝트의 일정계획 및 진행과정을 효율적으로 관리하기 위해 개발
전체 프로젝트의 시간단축을 목표
개발기간을 낙관치, 기대치, 비관치로 나누어 예측치를 계산
예측치 = (낙관치 + (4 * 기대치) + 비관치) / 6
CPM
미국의 듀폰사와 레밍톤 사의 화학공장 유지 및 관리를 위해 개발
최소의 비용 추가 투입을 고려하여 전체 프로토콜의 시간단축을 목표
PERT / CPM
작업의 선/후행 관계를 고려하여 전체작업의 완료시간을 결정하고(PERT), 추가비용 투입을 고려하여 전체작업 완료시간을 단축하는(CPM) 네트워크 분석 기법
복잡한 대형 프로젝트를 효율적으로 계획 및 통제하기 위해 개발된 기법
임계경로 Critical Path : 프로젝트를 끝내기 위해 필요한 최소 소요기간
Gantt Chart
일정 계획의 최종 산출물
프로젝트 일정관리를 위한 바형태의 도구
각 업무별로 일정의 시작과 끝을 그래픽으로 표시하여 전체 일정을 한눈에 볼 수 있음
각 업무 사이의 관계를 보여줌
소프트웨어 개발 방법론 테일러링
소프트웨어 테일러링
개요
- 프로젝트 특성 및 상황에 맞게, 이미 정의된 개발 방법론의 절차, 기법, 산출물 등을 수정하여 적용하는 기법
필요성
내부적 요인
개발 환경 : 시스템 개발 유형 및 환경이 다를 경우
요구사항 : 프로젝트별 우선적으로 고려할 사항이 다를 경우
프로젝트 규모 : 비용, 인력, 기간 등 프로젝트 규모가 다를 경우
보유 기술 : 프로세스, 개발 방법론, 산출물, 인력의 순력도 등이 다를 경우
외부적 요인
법적 제약사항 : 프로젝트별로 적용될 IT Compliance가 서로 다른 경우
표준 품질기준 : 업종별 표준 품질 기준이 서로 다른 경우
절차 항목
프로젝트 특성 파악
베이스라인 방법론 산정
테일러링 수행
테일러링 프로세스 교육
기법
규모와 복잡도에 따른 테일러링
- 프로젝트 기간, 작업범위, 참여인원
프로젝트 구성원에 따른 테일러링
- 구성원의 기술적 성숙도
팀내 방법론 지원에 따른 테일러링
- 각 팀별로 방법론 및 모델링 지원인력을 선정하여 개별 교육
자동화에 따른 테일러링
- 중간 산출물 자동화 도구 사용
테일러링을 위한 소프트웨어 개발 프레임워크
ISO / IEC 12207
CMMI 모델
SPICE
소프트웨어 개발 표준
국제 프로세스 품질 표준
ISO / IEC 9001
- 조직의 품질 경영 및 품질 보증
ISO / IEC 12207
소프트웨어 개발 관련 생명주기
ISO 국제표준화기구에서 만든 표준 소프트웨어 생명주기 프로세스
기본 생명주기 프로세스
- 획득, 공급, 개발, 운영, 유지보수
지원 생명주기 프로세스
- 문서화, 형상관리, 품질보증, 검증, 확인, 활동검토, 감사, 문제해결
조직 생명주기 프로세스
- 관리, 기반구조, 개선, 교육훈련
ISO / IEC 15504 | SPICE
소프트웨어 개발 관련해 선정된 프로세스 평가 모델
ISO에서 표준으로 지정된 프로세스 수행능력 평가 표준 프레임워크
0 | 불안정 단계 | Incomplete
- 미구현 또는 목표 미달성
1 | 수행 단계 | Performed
- 프로세스 수행 및 목적 달성
2 | 관리 단계 | Managed
- 프로세스 수행 계획 및 관리
3 | 확립 단계 | Established
- 표준 프로세스의 사용
4 | 예측 단계 | Predictable
- 프로세스의 정량적 이해 및 통제
5 | 최적화 단계 | Optimizing
- 프로세스의 지속적인 개선
CMM | Capability Maturity Model
조직의 소프트웨어 개발 관련 전체 프로세스 평가
소프트웨어 개발 업체들의 업무능력평가 기준을 세우기 위한 평가 모형
1991년 미국 국방부의 의뢰를 받아 카네기멜론 대학이 만든 평가 모델
소프트웨어 개발능력 측정 기준과 소프트웨어 개발 조직의 성숙도 수준을 평가
1 | 초기 단계 | Initial
- 소프트웨어를 개발하고 있으나 관리는 하고 있지 않은 상태
- 프로세스의 성과를 예측할 수 없는 상태
2 | 반복 단계 | Repeatable
- 이전의 성공적인 프로젝트의 프로세스를 반복하고 있는 상태
- 같은 것을 반복적으로 실행하며 어느 정도의 통계적 관리가 가능한 상태
3 | 정의 단계 | Defined
- 프로세스 작업이 잘 정의 / 이해되고, 프로세스 데이터에 의한 프로젝트 관리도 실행하고 있는 상태
- 프로세스의 기초가 정립되어 계속 진보되고 있는 상태
4 | 관리 단계 | Managed
- 프로세스 성과를 측정 / 분석하여 개선시키고, 이를 바탕으로 관리하고 있는 상태
- 정량적 프로세스 관리, 소프트웨어 품질 관리
5 | 최적화 단계 | Optimizing
- 질적, 양적으로 지속적인 개선이 이루어지고 있는 상태
CMMI | Capability Maturity Model Integration
다양한 CMM 모델을 통합한 프로세스 개선 프레임워크
시스템과 소프트웨어 영역을 하나의 프로세스 개선 툴로 통합시켜 기업의 프로젝트 개선활동에 광범위한 적용성을 제공하는 모델
소프트웨어, 시스템, 프로덕트를 포함하는 세 분야를 통합 평가하는 모델
1 | 초기 단계 | Initial
- 구조화된 프로세스를 갖고 있지 않는 조직
2 | 관리 단계 | Managed
- 기본적인 프로세스를 갖고 있는 조직
- 기본 프로세스에 따라 업무가 수행되고 기본적인 관리활동들로부터 구체적인 특정 영역으로 프로세스의 체계가 확대 발전하는 조직
3 | 정의 단계 | Defined
- 조직 차원의 표준 프로세스를 보유하고 있으며 프로젝트를 수행할 경우 프로젝트의 특성에 따라 적절하게 조정하여 사용
4 | 정량적 관리 단계 | Quantitatively Managed
- 프로세스들을 통계적이고 정량적으로 관리하는 조직
5 | 최적화 단계 | Optimizing
- 질적, 양적으로 지속적인 개선이 이루어지고 있는 상태
소프트웨어 개발 프레임워크
개념
소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것
소프트웨어 개발에 바탕이 되는 템플릿과 같은 역할을 하는 클래스들과 인터페이스의 집합
소프트웨어 개발 시 공통적인 부분을 제공
특징
모듈화 | Modularity
프레임워크는 구현을 인터페이스 뒤에 감추는 캡슐화를 통해서 모듈화를 강화
설계와 구현의 변경에 따르는 영향을 최소화시킴으로써 쉽게 소프트웨어의 품질을 향상시킴
재사용성 | Reusability
프레임워크가 제공하는 인터페이스는 여러 어플리케이션에서 반복적으로 사용할 수 있는 일반적인 컴포넌트를 정의할 수 있게 함으로써 재사용성을 높여줌
소프트웨어의 품질, 성능, 신뢰성, 상호 운용성을 향상시키고, 프로그래머의 생산성을 높여줌
확장성 | Extensibility
- 다형성을 통해 어플리케이션의 프레임워크의 인터페이스를 확장할 수 있게 함
제어의 역흐름 | Inversion of control
- 프레임워크가 외부의 이벤트에 대해 어플리케이션이 어떠한 메소드들을 수행해야 하는지 결정
구분
Java 프레임워크
전자정부 표준 프레임워크
스트릿츠
스프링
ORM 프레임워크
iBatis
myBatis
Hibernate
JS 프레임워크
AngularJS
ReactJS
ExtJS
Front-end 프레임워크
Bootstrap
Foundation
MDL