본문 바로가기
  • Always Awake
정보처리기사/5과목

[정보처리기사 필기] 소프트웨어 개발 방법론 활용

by NerdyBoy 2022. 2. 25.
반응형

소프트웨어 개발 방법론


1. 개요

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

 

2. 종류

구조적 방법론

  • 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Process) 중심의 방법론.
  • 분할과 정복(Divide and Conquer)
  • 절차 : 타당성 검토 - 계획 - 요구사항 - 설계 - 구현 - 시험 - 운용/유지보수

정보공학 방법론

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

객체지향 방법론

현실세계의 개체를 기계의 부품처럼 하나의 객체로 만들어, 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법

  • 구성 요소 : 객체(Object), 클래스(Class), 메시지(Message) 등이 있다.
  • 기본 원칙 : 캡슐화, 정보 은닉, 추상화, 상속성, 다형성 등
  • 절차 : 요구 분석 - 설계 - 구현 - 테스트 및 검증 - 인도

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

기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론

  • 컴포넌트의 재사용이 가능하여 시간과 노력을 절감할 수 있다.
  • 확장성 보장, 유지 보수 비용 최소화 하고 생산성 및 품질 향상
  • 절차 : 개발 준비 - 분석 - 설계 - 구현 - 테스트 - 전개 - 인도

애자일(Agile) 방법론

민첩한, 기민한 이라는 뜻. 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행하는 방법론

  • 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합.
  • 종류 : 익스트림 프로그래밍(XP; eXtreme Programming), 스크럼(Scrum), 칸반(Kanban), 크리스탈(Crystal) 등
  • 절차 : 사용자 스토리 - 계획 - 개발 - 승인 테스트
  •     : 반복주기

제품 계열 방법론

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

  • 임베디드 소프트웨어를 만드는데 적합
  • 영역공학 : 영역 분석, 영역 설계, 핵심 자산 구현
  • 응용공학 : 제품 요구 분석, 제품 설계, 제품 구현하는 영역

 

3. CASE

CASE(Computer Aided Software Engineering)는 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화 하는 것이다.

  • 주요 기능 : 소프트웨어 생명 주기 전 단계의 연결, 다양한 소프트웨어 개발 모형 지원, 그래픽 자원, 모델들의 모순 검사 및 오류검증, 자료흐름도 작성 등
  • 원천 기술 : 구조적 기법, 프로토 타이핑, 자동 프로그래밍, 정보 저장소, 분산처리

 

 

비용 산정 기법


1. 개요

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

 

비용 결정 요소

  • 프로젝트 요소
    • 제품 복잡도
    • 시스템 크기
    • 요구되는 신뢰도
  • 자원 요소
    • 인적 자원
    • 하드웨어 자원
    • 소프트웨어 자원
  • 생산성 요소
    • 개발자 능력
    • 개발 기간

 

2. 하향식 기법

하향식 비용 산정 기법은 과거의 유사한 경험을 바탕으로 전문지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법

  • 종류 : 전문가 감정 기법, 델파이 기법 등

델파이 기법

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

  • 한명의 조정자와 여러 전문가로 구성

 

3. 상향식 기법

세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법

  • 종류 : LOC(원시 코드 라인 수) 기법, 개발 단계별 인월수 기법, 수학적 산정 기법 등

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

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

 

예측치 = (a+4m+b)/6 단, a : 낙관치, b : 비관치, m : 기대치(중간치)

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

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

기대치 : 측정된 모든 라인 수 평균

 

산정 공식

  • 노력(인월) = 개발기간 * 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수
  • 개발 비용 = 노력(인월) * 단위 비용(1인당 월평균 인건비)
  • 개발 기간 = 노력(인월) * / 투입 인원
  • 생산성 = LOC / 노력(인월)

 

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

LOC 기법을 보완하기 위한 것으로, 각 기능을 구현시키는데 필요한 비용을 생명 주기의 각 단계별로 산정

  • LOC기법 보다 더 정확

 

4. 수학적 산정 기법

상향식 비용 산정 기법으로, 경험적 추정 모형, 실험적 추정 모형이라고도 하며, 개발 비용 산정의 자동화를 목표로 한다.

  • 과거 유사한 프로젝트를 기반으로 경험적으로 유도된 것
  • 종류 : COCOMO 모형, Putnam 모형, 기능 점수(FP)모형 등이 있다.

COCOMO(COnstructive COst MOdel) 모형

보헴이 제안한 것으로, 원시 프로그램의 규모인 LOC에 의한 비용 산정 기법으로, 소프트웨어의 복잡도 혹은 원시 프로그램의 구조에 따라 다음과 같이 분리

 

조직형(Organic Mode)

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

  • 사무 처리용, 업무용, 과학용 응용소프트웨어 개발에 적합
  • 노력(MM) : 2.4 * (KDSI)¹ᐧ⁰⁵
  • 개발 기간(TDEV) = 2.5 * (MM)⁰ᐧ³⁸

반분리형(Semi-Detached Mode)

조직형과 내장형의 중간형으로 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만(300KDSI) 라인 이하의 소프트웨어를 개발하는 유형이다.

  • 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합
  • 노력(MM) = 3.0 * (KDSI)¹ᐧ¹²
  • 개발 기간(TDEV) = 2.5 * (MM)⁰ᐧ³⁸

내장형(Embedded Mode)

초대형 규모의 트랜잭션 처리 시스템이나 운영체제 등의 30만(300KDSI)라인 이상의 소프트웨어를 개발하는 유형

  • 신호기 제어 시스템, 미사일 유도 시스템 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합
  • 노력(MM) = 3.6 * (KDSI)¹ᐧ²⁰
  • 개발 기간(TDEV) = 2.5 * (MM)⁰ᐧ³²

 

COCOMO 모형의 종류

기본(Basic)형 COCOMO 

소프트웨어의 크기(생산 코드 라인 )와 개발 유형만을 이용하여 비용을 산정하는 모형

  • 산정 공식
    • 개발 노력(Effort, MM, PM) = a * (KDSI)ᵇ
    • 개발 기간(TDEV) = c * (MM)ᵈ
    • 적정 투입 인원(FPS) = MM / TDEV
    • 인적 비용(COST) = MM * 1인당 월평균 급여

중간(Intermediate)형 COCOMO

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

  • 제품의 특성 : 요구되는 신뢰도, 데이터베이스 크기, 제품의 복잡도
  • 컴퓨터의 특성 : 수행 시간의 제한, 기억장소의 제한, 가상 세계의 안정성, Trun Around Time
  • 개발 요원의 특성 : 분석가의 능력, 개발 분야의 경험, 가상 기계의 경험, 프로그래머의 능력, 프로그래밍 언어의 경험
  • 프로젝트 특성 : 소프트웨어 도구의 이용, 프로젝트 개발 일정, 최신 프로그래밍 기법의 이용
  • 산정 공식
    • 개발 노력(MM) : 기본 COCOMO의 MM * 요인별 노력 승수
    • 개발 기간(TDEV) = c * (MM)ᵈ
    • 적정 투입 인원(FPS) = MM / TDEV
    • 인적 비용(COST) = MM * 1인당 월평균 급여

 

발전형(Detailed)형 COCOMO

중간(Intermediate)형 COCOMO를 보완하여 만들어진 방법으로 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용을 산정하는 모형이다.

  • 소프트웨어 환경과 구성요소가 사전에 정의 되어있어야 하며, 개발 과정의 후반부에 주로 적용
  • 산정 공식 : 노력 승수 = 개발 공정별 노력 승수 * 개발 공정별 가중치

Putnam 모형

소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 가정해 주는 모형

  • 푸트남이 제안한 것으로 생명 주기 예측 모형이라고도 한다.
  • 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력분포도를 기초로 한다
  • 대형 프로젝트의 노력 분포 산정에 이용
  • 개발 기간 늘수록 프로젝트 적용 인원의 노력감소

기능 점수(FP) 모형

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

* COCOMO 나 Putnam 모형은 LOC를 중심으로, 기능 점수 모형은 FP를 중심으로 비용산정

  • 기능별 가중치 
    • 자료 입력(입력 양식)
    • 정보 출력(출력 보고서)
    • 명령어(사용자 질의수)
    • 데이터 파일
    • 필요한 외부 루틴과의 인터페이스

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

 

 

 

소프트웨어 개발 표준


소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준

1. ISO/IEC 12207

ISO(International Oraganization for Standardization, 국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스

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

 

 

2. CMMI(Capability Maturity Integration)

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

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

 

3. SPICE(Software Process Improvement and Capability dEtermination)

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

목적

  • 프로세스 개선을 위해 개발 기관이 스스로 평가하는것
  • 기관에서 지정한 요구조건의 만족 여부를 개발 조직이 스스로 평가하는 것
  • 계약 체결을 위해 수탁 기관의 프로세스를 평가하는 것

구성

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

프로세스 수행단계

SPICE는 프로세스 수행단계를 다음과 같이 6단계로 구분한다

  • Level 0 - 불완전(Incomplete)
  • Level 1 - 수행(Performed)
  • Level 2 - 관리(Managed)
  • Level 3 - 확립(Established)
  • Level 4 - 예측(Predictable)
  • Level 5 - 최적화(Optimizing)

 


 

출처

자료 참고: 

시나공 정보처리기사 필기 2022를 참고하여 작성되었습니다

표지

 

반응형

댓글