[정보처리기사] Chapter 01. 정보시스템 구축 관리: 소프트웨어 개발 방법론 활용

1. 소프트웨어 개발 방법론

1.1. 소프트웨어 개발 방법론의 개요

 소프트웨어 개발 방법론은 소프트웨어 개발, 유지보수 등에 필요한 여러 가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것이다.

 소프트웨어 개발 방법론의 목적은 소프트웨어의 생산성과 품질 향상이다. 소프트웨어 개발 방법론의 종류에는 구조적 방법론, 정보공학 방법론, 객체지향 방법론, 컴포넌트 기반(CBD) 방법론, 애자일(Agile) 방법론, 제품 계열 방법론 등이 있다.

 

1.2. 구조적 방법론

 구조적 방법론은 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Process) 중심의 방법론이다.

 쉬운 이해 및 검증이 가능한 프로그램을 생성하는 것이 목적이다. 복잡한 문제를 다루기 위해 분할과 정복(Divide and Conquer) 원리를 적용한다.

 

▶ 구조적 방법론의 절차

타당성 검토 단계 → 계획 단계 → 요구사항 분석 단계 → 설계 단계 → 구현 단계 → 시험 단계 → 운용/유지보수 단계

 

1.3. 정보공학 방법론

 정보공학 방법론은 정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료중심의 방법론이다.

 정보 시스템 개발 주기를 이용하여 대규모 정보 시스템을 구축하는데 적합하다.

 

▶ 정보공학 방법론의 절차

정보 전략 계획 수립 단계 → 업무 영역 분석 단계 → 업무 시스템 설계 단계 → 업무 시스템 구축 단계

 

1.4. 객체지향 방법론

 객체지향 방법론은 현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체(Object)로 만들어, 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론이다. 객체지향 방법론은 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되었다.

 구성 요소에는 객체(Object), 클래스(Class), 메시지(Message) 등이 있으며, 기본 원칙에는 캡슐화, 정보 은닉, 추상화, 상속성, 다형성 등이 있다.

 

▶ 객체지향 방법론의 절차

요구 분석 단계 → 설계 단계 → 구현 단계 → 테스트 및 검증 단계 → 인도 단계

 

▶ 단어 의미 알기

◍ 객체(Object): 데이터와 함수(자료구조와 연산)를 묶어 놓은 하나의 소프트웨어 모듈 

◍ 클래스(Class): 공통된 속성과 연산을 갖는 객체의 집합

◍ 메시지(Message): 객체와 객체 간의 통신 수단

◍ 캡슐화(Encapsulation): 데이터와 함수를 하나로 묶는 것

◍ 정보 은닉(Information Hiding): 다른 객체에 자신의 정보를 숨기고 연산만을 통해 접근 허용하는 것

◍ 추상화(Abstraction): 불필요한 부분 생략, 가장 중요한 것에 중점을 두어 개략화하는 것

◍ 상속성(inheritance): 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것

◍ 추상화(Abstraction): 불필요한 부분 생략, 가장 중요한 것에 중점을 두어 개략화하는 것

◍ 다향성(Polymorphism): 다른형태로 응답

 

1.5. 컴포넌트 기반(CBD; Component Based Design) 방법론

 컴포넌트 기반 방법론은 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론이다. 컴포넌트의 재사용이 가능하여 시간과 노력을 절감할 수 있다. 유지 보수 비용을 최소화하고 생산성 및 품질을 향상시킬 수 있다.

 

▶ 컴포넌트 기반 방법론의 절차

개발 준비 단계 → 분석 단계 → 설계 단계 → 구현 단계 → 테스트 단계 → 전개 단계 → 인도 단계

 

＊컴포넌트(Component): 문서, 소스코드, 파일, 라이브러리 등과 같은 모듈화된 자원으로 재사용이 가능하다.

 

1.6. 애자일(Agile) 방법론

 애자일 방법론은 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행하는 방법론이다. 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합하다.

 애자일 방법론의 대표적인 종류로는 익스트림 프로그래밍(XP), 스크럼(Scrum), 칸반(Kanban), 크리스탈(Crystal) 등이 있다.

 

▶ 애자일 방법론의 절차

사용자 스토리 → (계획 → 개발 → 승인 테스트)(반복)

 

1.7. 제품 계열 방법론

 제품 계열 방법론은 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법이다. 

 임베디드 소프트웨어를 만드는데 적합하다. 제품 계열 방법론은 영역공학과 응용공학으로 구분된다. 영역공학과 응용공학의 연계를 위해 제품의 요구사항, 아키텍처, 조립 생산이 필요하다.

 

◍ 영역공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역이다.

◍ 응용공학 : 제품 요구 분석, 제품 설계, 제품을 구현하는 영역이다.

 

 

---

2. 비용 산정 기법 

2.1. 소프트웨어 비용 산정의 개요

 소프트웨어 비용 산정은 소프트웨어의 개발 규모를 소요되는 인원, 자원, 기간 등으로 확인하여 실행 가능한 계획을 수립하기 위해 필요한 비용을 산정하는 것이다.

 하향식 비용 산정 기법과 상향식 비용 산정 기법이 있다.

 

2.2. 소프트웨어 비용 결정 요소

 소프트웨어 비용은 개발하는 소프트웨어, 소프트웨어 개발에 투입되는 자원, 소프트웨어 생산성에 따라 결정된다. 소프트웨어 비용을 결정하는 요소에는 프로젝트 요소, 자원 요소, 생산성 요소가 있다.

 

1) 프로젝트 요소

◍ 제품 복잡도: 소프트웨어 종류에 따라 발생할 수 있는 문제점들의 난이도

◍ 시스템 크기: 소프트웨어의 규모에 따라 개발해야 할 시스템 크기

◍ 요구되는 신뢰도: 일정 기간 내 주어진 조건에서 프로그램이 필요 기능을 수행하는 정도

​

2) 자원 요소

◍ 인적 자원: 소프트웨어 개발 관련자들이 갖춘 능력과 자질

◍ 하드웨어 자원: 소프트웨어 개발 시 필요한 장비

◍ 소프트웨어 자원: 소프트웨어 개발 시 필요한 개발 지원 도구

​

3) 생산성 요소

◍ 개발자 능력: 개발자의 전문 지식, 경험, 이해도, 책임감, 창의력 등

◍ 개발 기간: 소프트웨어 개발에 필요한 기간

 

 

---

3. 비용 산정 기법-하향식 

3.1. 하향식 비용 산정 기법의 개요

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

 

3.2. 전문가 감정 기법

 조직 내에 경험 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법이다. 가장 편리하고 신속하게 비용 결정이 가능하다.

 다만, 새로운 프로젝트에는 과거의 프로젝트와 다른 요소들이 있다는 것을 간과할 수도 있으며, 새로운 프로젝트와 유사한 프로젝트에 대한 경험이 없을 수 있다. 개인적이고 주관적인 감정으로 정확한 금액이 산정되지 않을 수도 있다.

 

3.3. 델파이 기법

 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법이다.

 전문가들의 편견이나 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성된다. 

 

▶ 비용 산정 순서

① 조정자는 각 비용 산정 요원에게 시스템 정의서와 산정한 비용 내역을 기록할 서식을 제공한다.

② 산정 요원들은 정의서를 분석하여 익명으로 그들 나름대로의 비용을 정한다.

③ 조정자는 산정 요원들의 반응을 요약하여 배포한다.

④. 산정 요원들은 이전에 산정한 결과를 이용해 다시 익명으로 산정한다.

⑤ 요원들 간의 의견이 거의 일치할 때까지 이 과정을 반복한다.

 

 

---

4. 비용 산정 기법 -상향식

4.1. 상향식 비용 산정 기법의 개요

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

 

4.2. LOC(원시 코드 라인 수, source Line Of Code) 기법

 LOC 기법은 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법이다.

 

 측정이 용이하고 이해하기 쉬워 가장 많이 사용한다. 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정한다.

 

1) 예측치 = (a + 4m + b) / 6

◍ 비관치: 가장 많이 측정된 코드 라인 수, a

◍ 낙관치: 가장 적게 측정된 코드 라인 수, b

◍ 기대치: 측정된 모든 코드 라인 수의 평균, m (중간치)

 

2) 산정 공식

◍ 노력(인월) = 개발 기간 x 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수

◍ 개발 비용 = 노력(인월) x 단위 비용(1인당 월평균 인건비)

◍ 개발 기간 = 노력(인원) / 투입 인원

◍ 생산성 = LOC / 노력(인월)

 

4.3. 개발 단계별 인월수(Effort Per Task) 기법

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

 

 

---

5. 수학적 산정 기법 

5.1. 수학적 산정 기법의 개요

 상향식 비용 산정 기법으로, 경험적 추정 모형, 실험적 추정 모형 이라고도 하며, 개발 비용 산정의 자동화를 목표로 한다. 비용을 자동으로 산정하기 위해 사용되는 공식은 과거 유사한 프로젝트를 기반으로하여 경험적으로 유도된 것이다.

 수학적 산정 기법에는 COCOMO 모형, Putnam 모형, 기능 점수(FP) 모형 등이 있으며 각 모형에서는 지정된 공식을 사용하여 비용을 산정한다.

 

5.2. COCOMO 모형 개요

 COCOMO(Constructive COst Model) 모형은 보헴(Bohem)이 제안한 것으로 원시 프로그램 규모인 LOC(원시 코드 라인 수)에 의한 비용 산정 기법이다. 개발할 소프트웨어의 규모(LOC)를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 산정한다.

 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용되고 있다. COCOMO 모형은 같은 규모의 프로그램이라도 그 성격에 따라 비용이 다르게 산정된다.

 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 나타난다.

 

5.3. COCOMO의 소프트웨어 개발 유형

 소프트웨어 개발 유형은 소프트웨어의 복잡도 혹은 원시 프로그램의 규모에 따라 조직형, 반분리형, 내장형을 분류할 수 있다.

 

1) 조직형(Organic Mode)

 조직형은 기관 내부에서 개발된 중소 규모의 소프트웨어로 일괄 자료 처리나 과학 기술 계산용, 비즈니스자료 처리용으로 5만(50KDSI)라인 이하의 소프트웨어를 개발하는 유형이다. 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합하다.

 

2) 내장형(Embedded Mode)

 내장형은 최대형 규모의 트랜잭션 처리 시스템이나 운영체제 등의 30만(300KDSI)라인 이상의 소프트웨어를 개발하는 유형이다. 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합하다.

 

3) 반분리형(Semi-Detached Mode)

 반분리형은 조직형과 내장형의 중간형으로 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만(300KDSI)라인 이하의 소프트웨어를 개발하는 유형이다. 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합하다.

 

5.4. COCOMO 모형의 종류

 COCOMO는 비용 산정 단계 및 적용 변수의 구체화 정도에 따라 기본(Basic), 중간(Intermediate), 발전(Detailed)형으로 구분할 수 있다.

 

1) 기본(Basic) 형 COCOMO

 기본형 COCOMO는 소프트웨어의 크기와 개발 유형만을 이용하여 비용을 산정한다.

 

2) 중간(Intermediate)형 COCOMO

 중간형은 기본형의 공식을 토대로 사용하나, 다음 4가지 특성의 15가지 요인에 의해 비용을 산정하는 모형이다.

◍ 제품의 특성: 요구되는 신뢰도, 데이터베이스 크기, 제품의 복잡도

◍ 컴퓨터의 특성: 수행시간의 제한, 기억장소의 제한, 가상 기계의 안정성, Turn Around Time

◍ 개발 요원의 특성: 분석가의 능력, 개발 분야의 경험, 가상 기계의 경험, 프로그래머의 능력, 프로그래밍 언어의 경험

◍ 프로젝트 특성: 소프트웨어 도구의 이용, 개발 일정, 최신 기법 이용

 

3) 발전(Detailed)형 COCOMO

 발전형 COCOMO는 중간형 COCOMO를 보완하여 만들어진 방법으로 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용을 산정하는 모형이다. 소프트웨어 환경과 구성 요소가 사전에 정의되어 있어야 하며, 개발 과정의 후반부에 주로 적용한다.

◍ 산정 공식 : 개발 공정별 노력 승수 X 개발 공정별 가중치

 

5.5. Putnam 모형

 Putnam 모형은 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 가정해 주는 모형이다. 푸트남(Putnam)이 제안한 것으로 생명 주기 예측 모형이라고도 한다.

 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다. Putnam 모형은 대형 프로젝트의 노력 분포 산정에 이용되는 기법이다. 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소한다.

 

5.6. 기능 점수(FP) 모형

 기능 점수(Function Point) 모형은 알브레히트(Albrecht)가 제안한 것으로, 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며 총 기능 점수와 영향도를 이용하여 기능 점수(FP)를 구한 후 이를 이용해서 비용을 산정하는 기법이다.

  발표 초기에는 관심을 받지 못했으나 최근에는 그 유용성과 간편성으로 비용 선정 기법 가운데 최선의 평가를 받고 있다. COCOMO나 Putnam 모형은 LOC 를 중심으로 비용을 산정하는데 반해 기능 점수 모형은 FP를 이용하여 비용을 산정한다.

 

◍ 산정 공식: FP = (총 기능 점수) x [0.65 + (0.1 x 총 영향도)]

 

5.7. 자동화 추정 도구

비용 산정의 자동화를 위해 개발된 도구로는 SLIM과 ESTIMACS가 있다.

◍ SLIM: Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구이다.

◍ ESTIMACS: 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구이다.

 

 

---

6. 소프트웨어 개발 방법론 결정

6.1. 소프트웨어 개발 방법론 결정의 개요

 소프트웨어 개발 방법론의 결정은 프로젝트 관리와 재사용 현황을 소프트웨어 개발 방법론에 반영하고, 확정된 소프트웨어 생명 주기와 개발 방법론에 맞춰 소프트웨어 개발 단계, 활동 작업, 절차 등을 정의하는 것이다.

 

◍ 프로젝트 관리 유형 : 일정 관리, 비용 관리, 인력 관리, 위험 관리, 품질 관리 (비품위일인)

 

관리 유형	주요 내용
일정 관리	작업 순서, 작업 기간 산정, 일정 개발, 일정 통제
비용 관리	비용 산정, 비용 예산 편성, 비용 통제
인력 관리	프로젝트 팀 편성, 자원 산정, 프로젝트 조직 정의, 프로젝트 팀 개발, 자원 통제, 프로젝트 팀 관리
위험 관리	위험 식별, 위험 평가, 위험 대처, 위험 통제 (위험 관리 순서)
품질 관리	품질 계획, 품질 보증 수행, 품질 통제 수행

 

6.2. 소프트웨어 개발 방법론 결정 절차

1) 프로젝트 관리와 재사용 현황을 소프트웨어 개발 방법론에 반영 한다.

◍ 소프트웨어 개발 방법론에 프로젝트 관리와 재사용 현황을 반영하는 방법을 프로젝트 관련자들에게 설명한다.

◍ 소프트웨어 개발 방법론에 프로젝트 관리와 재사용 현황을 반영하고 그 결과를 프로젝트 관련자들에게 설명한 후 결정한다.

 

2) 개발 단계별 작업 및 절차를 소프트웨어 생명 주기에 맞춰 수립한다.

◍ 소프트웨어의 기본 생명 주기, 지원 생명 주기, 조직 생명 주기별로 주요 프로세스를 확인한다.

◍ 소프트웨어의 개발 프로세스, 개발 생명 주기 프로세스 모형을 정리한다.

 

3) 결정된 소프트웨어 개발 방법론의 개발 단계별 활동 목적, 작업 내용, 산출물에 대한 매뉴얼을 작성한다.

 

 

---

7. 소프트웨어 개발 표준

7.1. 소프트웨어 개발 표준의 개요

 소프트웨어 개발 표준은 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준을 의미한다. 대표적인 소프트웨어 개발 표준에는 ISO/IEC 12207, CMMI, SPICE 등이 있다.

 

7.2. ISO/IEC 12207

 ISO/IEC 12207은 ISO에서 만든 표준 소프트웨어 생명 주기 프로세스로, 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준을 제공한다.

 

◍ 기본 생명 주기 프로세스: 획득, 공급, 개발, 운영, 유지보수 프로세스

 

◍ 지원 생명 주기 프로세스: 품질 보증, 검증, 확인, 활동 검토, 문제 해결 프로세스

◍ 조직 생명 주기 프로세스: 관리, 기반 구조, 훈련, 개선 프로세스

 

7.3. CMMI(Capability Maturity Model Integration)

 CMMI(능력 성숙도 통합 모델)는 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델로, 미국의 소프트웨어 공학연구소(SEI)에서 개발하였다.

 CMMI의 소프트웨어 프로세스 성숙도는 초기, 관리, 정의, 정량적 관리, 최적화의 5단계로 관리한다.

 

단계	프로세스	특징
초기(Initial)	정의된 프로세스 없음	작업자 능력에 따라 성공 여부 결정
관리(Managed)	규칙화 된 프로세스	특정 프로젝트 내 프로세스 정의 및 수행
정의(Defined)	표준화 된 프로세스	조직의 표준 프로세스를 활용하여 업무 수행
정량적 관리 (Quantitatively Managed)	예측 가능한 프로세스	프로젝트를 정량적으로 관리 및 통제
최적화(Optimizing)	지속적 개선 프로세스	프로세스 역량 향상을 위해 지속적 프로세스 개선

​

7.4. SPICE(Software Process Improvement and Capability dEtermination)

 SPICE(소프트웨어 처리 개선 및 능력 평가 기준)는 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준으로, 공식 명칭은 ISO/IEC 15504이다.

 

1) SPICE의 목적

◍ 프로세스 개선을 위해 개발 기관이 스스로 평가하는 것

◍ 기관에서 지정한 요구조건의 만족여부를 개발 조직이 스스로 평가하는 것

◍ 계약 체결을 위해 수탁 기관의 프로세스를 평가하는 것

 

2) 프로세스 범주의 구성

 SPICE는 5개의 프로세스 범주와 40개의 세부 프로세스로 구성된다.

 

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

 

3) 프로세스 수행 능력 단계

 SPICE는 프로세스 수행 능력 단계를 불완전, 수행, 관리, 확립, 예측, 최적화의 6단계로 구분한다

 

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

 

 

---

8. 소프트웨어 개발 방법론 테일러링 

8.1. 소프트웨어 개발 방법론 테일러링의 개요

 소프트웨어 개발 방법론 테일러링은 프로젝트 상황 및 특성에 맞도록 정의된 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업

 

▶ 절차

프로젝트 특징 정의 → 표준 프로세스 선정 및 검증 

→ 상위 수준의 커스터마이징 → 세부 커스터마이징 → 테일러링 문서화

 

* 테일러링(Tailoring): 표준을 기반으로 실제 업무에서 여건에 맞게 수정/보완하는 것

 

8.2. 소프트웨어 개발 방법론 테일러링 고려사항

 소프트웨어 개발 방법론 테일러링 작업 시 고려해야 할 사항에는 내부적 요건과 외부적 요건이 있다.

 

1) 내부적 요건

◍ 목표 환경: 시스템의 개발 환경과 유형이 서로 다른 경우 테일러링이 필요하다.

◍ 요구 사항: 프로젝트의 생명 주기 활동에서 개발, 운영, 유지보수 등 프로젝트에서 우선적으로 고려할 요구사항이 서로 다른 경우 테일러링이 필요하다.

◍ 프로젝트 규모: 비용, 인력, 기간 등 프로젝트의 규모가 서로 다른 경우 테일러링이 필요하다.

◍ 보유 기술: 프로세스, 개발 방법론, 산출물 등이 서로 다른 경우 테일러링이 필요하다.

 

2) 외부적 요건

◍ 법적 제약사항: 프로젝트별로 적용될 IT Compliance(법적 규제)가 서로 다른 경우 테일러링이 필요하다.

◍ 표준 품질 기준: 금융, 제도 등 분야별 표준 품질 기준이 서로 다른 경우 테일러링이 필요하다.

 

8.3. 소프트웨어 개발 방법론 테일러링 기법

1) 프로젝트 규모와 복잡도에 따른 테일러링 기법: 가장 일반적인 기법으로, 프로젝트 규모를 대중소로 구분하고, 업무의 난이도에 따라 복잡도를 상중하로 구분하는 기법

 

2) 프로젝트 구성원에 따른 테일러링 기법: 참여 구성원들의 기술적 숙련도를 확인하여 테일러링 수준을 결정하는 기법

 

3) 팀내 방법론 지원에 따른 테일러링 기법: 프로젝트 수행 시 각 팀별로 방법론 담당 인력을 배정하여 팀의 방법론 교육 을 담당하도록 인력을 구성하는 기법

 

4) 자동화에 따른 테일러링 기법: 프로젝트 수행 시 작업 부하를 줄이기 위해 중간 단계에서의 산출물을 자동화 도구를 사용하여 산출할 수 있도록 지원하는 기법

 

＊IT Compliance: 기업 운영 시 IT 분야에서 내.외부적으로 반드시 지켜야 하는 법적 규제 사항이나 지침

 

 

---

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

9.1. 소프트웨어 개발 프레임워크의 개요

 프레임워크(Framework)는 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러 가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템이다.

 프레임워크의 주요 기능에는 예외 처리, 트랜잭션 처리, 메모리 공유, 데이터 소스관리, 서비스 관리, 쿼리 서비스, 로깅 서비스, 사용자 인증 서비스 등이 있다.

 프레임워크의 종류에는 스프링 프레임워크, 전자정부 프레임워크, 닷넷 프레임워크 등이 있다.

 

9.2. 스프링 프레임워크(Spring Framework)

 스프링 프레임워크는 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크이다. 동적인 웹 사이트의 개발을 위해 다양한 서비스를 제공한다.

 전자정부 표준 프레임워크의 기반 기술로 사용되고 있다.

 

9.3. 전자정부 프레임워크

 전자정부 프레임워크는 우리나라의 공공부문 정보화 사업 시 효율적인 정보 시스템의 구축을 지원하기 위해 필요한 기능 및 아키텍처를 제공하는 프레임워크이다. 전자정부 프레임워크는 개발 프레임워크의 표준 정립으로 응용 소프트웨어의 표준화, 품질 및 재사용성의 향상을 목적으로 한다.

 오픈소스 기반의 범용화가 되고 공개된 기술을 활용함으로써 특정 업체의 종속성을 배제하고 사업별 공통 컴포넌트의 중복 개발을 방지한다.

 

​9.4. 닷넷 프레임워크(.NET Framework)

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

 메모리 관리, 유형 및 메모리 안정성, 보안, 네트워크 작업 등 여러 가지 서비스를 제공한다.