본문으로 바로가기

소프트웨어 개발 방법론

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

 - 소프트웨어의 생산성과 품질 향상이 목적

 - 소프트웨어 개발 방법론의 종류는 구조적 방법론, 정보공학 방법론, 객체지향 방법론, 컴포넌트 기반(CBD) 방법론, 애자일(Agile) 방법론, 제품 계열 방법론 등이 있음


구조적 방법론

 - 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론

 - 쉬운 이해 및 검증이 가능한 프로그램 코드를 생성하는 것이 목적

 - 복잡한 문제를 다루기 위해 분할과 정복 원리를 적용

 - 구조적 방법론의 절차

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


정보공학 방법론

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

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

 - 정보공학 방법론의 절차

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


객체지향 방법론

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

 - 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택

 - 구성 요소에는 객체, 클래스, 메시지 등이 있음

 - 기본 원칙에는 캡슐화, 정보 은닉, 추상화, 상속성, 다형성 등이 있음

 - 객체지향 방법론의 절차

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


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

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

 - 컴포넌트의 재사용이 가능하여 시간과 노력을 절감

 - 유지 보수 비용을 최소화하고 생산성 및 품질을 향상

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

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


애자일(Agile) 방법론

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

 - 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합

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

애자일 방법론의 절차


소프트웨어 비용 산정

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

 - 소프트웨어 비용 산정 기법에는 하향식 비용 산정 기법과 상향식 비용 산정 기법이 있음


소프트웨어 비용 결정 요소

 - 프로젝트 요소

    - 제품 복잡도

    - 시스템 크기

    - 요구되는 신뢰도

 - 자원 요소

    - 인적 자원

    - 하드웨어 자원

    - 소프트웨어 자원

 - 생산성 요소

    - 개발자 능력

    - 개발 기간


하향식 비용 산정 기법

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

 - 전문가 감정 기법

    - 조직 내에 있는 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법

    - 개인적이고 주관적

 - 델파이 기법 등이 있음

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

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


상향식 비용 산정 기법

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

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

   - 측정이 용이하고 이해하기 쉬워 가장 많이 사용

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

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

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

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

 


수학적 산정 기법

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

 - 비용을 자동으로 산정하기 위해 사용되는 공식은 과거 유사한 프로젝트를 기반으로하여 경험적으로 유도된 것

 - COCOMO 모형, Putnam 모형, 기능 점수(FP) 모형 등이 있음


COCOMO 모형

 - 보헴(Boehm)이 제안한 것으로 원시 프로그램의 규모인 LOC(원시 코드 라인 수)에 의한 비용 산정 기법

 - 개발할 소프트웨어의 규모를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용산정
 - 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용
 - 같은 규모의 프로그램이라도 그 성격에 따라 비용이 다르게 산정
 - 비용 산정 결과는 프로젝트를 완성하는데 필요한 노력으로 나타남

- COCOMO모형의 소프트웨어 개발 유형 : 조직형(Organic) / 반분리형(Semi-Detached Mode) / 내장형(Embedded Mode)
  - 조직형(Organic) : 비즈니스 자료 처리용으로 5만라인 이하의 소프트웨어를 개발하는 유형
  - 반분리형(Semi-Detached Mode) : 트랜잭션 처리 시스템 및 운영체제, 데이터베이스 관리 시스템 등의 30만라인 이하의 소프트웨어를 개발하는 유형
  - 내장형(Embedded Mode) : 최대형 규모의 트랜잭션 처리 시스템이나 운영체제 등의 30만라인 이상의 소프트웨어를 개발하는 유형


Putnam모형

 - 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 가정해 주는 모형
 - 푸트남(Putnam)이 제안한 것으로 생명 주기 예측 모형이라고도 함
 - 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
 - 대형 프로젝트의 노력 분포 산정에 이용되는 기법
 - 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소


기능점수(FP) 모형

 - 알브레히트(Albrecht)가 제안한 것으로, 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며 총 기능점수와 영향도를 이용하여 기능 점수를 구한 후 이를 이용해서 비용을 산정하는 기법
 - 발표 초기에는 관심을 받지 못하였으나 최근에는 유용성과 간편성으로 비용 산정 기법 가운데 최선의 평가를 받음


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

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

 - 대표적인 소프트웨어 개발 표준에는 ISO/IEC 12207, CMMI, SPICE 등이 있음


ISO/IEC 12207

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

기본 생명 주기 프로세스 획득, 공급, 개발, 운영, 유지보수 프로세스
지원 생명 주기 프로세스 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상 관리, 문제 해결 프로세스
조직 생명 주기 프로세스 관리, 기반 구조, 훈련, 개선 프로세스

CMMI(Capability Maturity Model Integration)

 - S/W 생명주기 동안 품질향상과 공정관리 개념을 적용하여 만들어진 모델

 - 프로세스 평가를 위해 5단계의 성숙도로 구분한 모델

  - 레벨 1 : 초기 단계
  - 레벨 2 : 관리 단계
  - 레벨 3 : 정의 단계
  - 레벨 4 : 정량적 관리 단계
  - 레벨 5 : 최적화 단계


SPICE(Software Process Improvement and Capability dEtermination)

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

 - SPICE의 목적

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

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

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

 - SPICE의 프로세스

   - 고객-공급자 프로세스

   - 공학 프로세스

   - 지원 프로세스

   - 관리 프로세스

   - 조직 프로세스

 - SPICE 프로세스 수행 능력 6단계

   - 불완전 : 프로세스가 구현되지 않았거나 목적을 달성하지 못한 단계

   - 수행 : 프로세스가 수행되고 목적이 달성된 단계

   - 관리 : 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계

   - 확립 : 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행되는 단계

   - 예측 : 프로세스가 목적 달성을 위해 통제되고 양적인 측정을 통해서 일관되게 수행되는 단계

   - 최적화 : 프로세스 수행을 최적화하고 지속적인 개선을 통해 업무 목적을 만족시키는 단계


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

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

 - 소프트웨어 개발 방법론 테일러링 수행절차


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

 - 내부적 요건

   - 목표 환경

   - 요구사항

   - 프로젝트 규모

   - 보유 기술

 - 외부적 요건

   - 법적 제약사항

   - 표준 품질 기준


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

 - 프로젝트 규모와 복잡도에 따른 테일러링 기법

   : 가장 일반적인 기법으로 프로젝트 규모를 프로젝트 기간, 작업범위, 참여인원 등에 따라 대·중·소로 구분하고 프로젝트 업무의 난이도에 따라 복잡도를 상·중·하로 구분하는 기법

 - 프로젝트 구성원에 따른 테일러링 기법

   : 프로젝트에 참여하는 구성원들의 기술적 숙련도와 방법론의 이해 정도를 확인하여 테일러링 수준을 결정하는 기법

 - 팀내 방법론 지원에 따른 테일러링 기법

   : 프로젝트 수행 시 각 팀별로 방법론 담당 인력을 배정하여 팀의 방법론 교육과 프로젝트 전체의 방법론 운영을 위한 의사소통을 담당하도록 인력을 구성하는 기법

 - 자동화에 따른 테일러링 기법

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