소프트웨어 개발 방법론

반응형
  • 소프트웨어 개발 방법론의 필요성
    • 개발 경험 축적 및 재활용을 통한 개발 생산성 향상(작업의 표준화/모듈화)
    • 효과적인 프로젝트 관리(수행 공정의 가시화 포함)
    • 정형화된 절차와 표준 용어의 제공으로 의사소통 수단 제공
    • 각 단계별 검증 및 종결 승인을 통한 일정 수준의 품질 보증
         
  • 소프트웨어 개발 방법론의 구성 요소
구성요소 내용 비고
작업절차
  • 프로젝트 수행 시 이루어지는 작업 단계의 체계
  • 단계별 활동 및 활동별 세부 작업 열거, 활동의 순서 명시
단계.활동.작업
작업방법
  • 각 단계별로 수행해야 하는 일
  • 절차/작업 방법(누가, 언제, 무엇을 작업하는지를 기술)
작업방법
산출물
  • 각 단계별로 만들어야 하는 산출물의 목록 및 양식
설계서 등
관리
  • 프로젝트의 진행 기록
  • 계획 수립, 진행 관리, 품질, 외주, 예산, 인력 관리 등 기록
계획서, 실적, 품질보증 등
기법
  • 각 단계별로 작업 수행 시 기술 및 기법의 설명
구조적, 객체지향,ERD, DFD
도구
  • 기법에서 제시된 각 기법별 지원 도구에 대한 구체적인 사용 표준 방법
CASE 등

   

  • 소프트웨어 개발 방법론의 분류별 비교
   구조적 방법론 정보 공학 방법론 객체지향 방법론 CBD 방법론
시기 1970년대 1980년대 1990년대 2000년대
중점 기능중심 자료구조 중심 객체 중심 컴포넌트 중심
장점
  • Batch 방식 개발에 유용함
  • 자료 중심으로 비교적 안정적임
  • 자연스럽고 유연함
  • 재사용이 용이함
  • 생산성, 품질, 비용, 위험 개선
  • 소프트웨어 위기 극복
단점
  • 기능은 불안정한 요소
  • 데이터가 정보 은닉이 안됨
  • 유지보수, 재사용성이 낮음
  • 애플리케이션은 여전히 기능적 설계
  • 기능의 유지보수, 재사용성이 낮음
  • 전문가 부족
  • 기본적인 소프트웨어 기술이 필요
  • 컴포넌트 유통환경 개선
  • 테스트 환경의 부족
  • 컴포넌트의 평가, 인증 환경의 미흡

   

  • 소프트웨어 개발 방법론의 분류별 비교
   구조적 방법론 정보 공학 방법론 객체지향 방법론 CBD 방법론
시기 1970년대 1980년대 1990년대 2000년대
중점 기능중심 자료구조 중심 객체 중심 컴포넌트 중심
장점
  • Batch 방식 개발에 유용함
  • 자료 중심으로 비교적 안정적임
  • 자연스럽고 유연함
  • 재사용이 용이함
  • 생산성, 품질, 비용, 위험 개선
  • 소프트웨어 위기 극복
단점
  • 기능은 불안정한 요소
  • 데이터가 정보 은닉이 안됨
  • 유지보수, 재사용성이 낮음
  • 애플리케이션은 여전히 기능적 설계
  • 기능의 유지보수, 재사용성이 낮음
  • 전문가 부족
  • 기본적인 소프트웨어 기술이 필요
  • 컴포넌트 유통환경 개선
  • 테스트 환경의 부족
  • 컴포넌트의 평가, 인증 환경의 미흡

   

  • 소프트웨어 개발 방법론 적용 시 문제점 및 개선 대책
    • 문제점
      • 프로젝트 특성을 무시한 특정 방법론 강요
      • 형식적인 적용으로 무용지물인 문서만 양산
      • 소규모 프로젝트에 방대한 규모의 방법론 적용
    • 개선 대책
      • 기업 차원의 품질 관리 인식 제고 및 교육과 효과적 활용 도모
      • 융통성이 있는 개발 방법론 적용
      • CMM, SPICE 등과 연계
    • 개발 방법론 선택 기준
      • 프로젝트 환경 고려(응용 분야, 시스템 규모, 복잡도, 성격 등)
      • 수작업을 최소화하고 자동화되어 있을수록 좋음(시간과 비용)
      • 성공을 위한 가이드라인, 함정에 대한 경고 및 실제 활동에서 잊기 쉬운 점들을 검사(통제 수단과 산출물 인도 방식)
      • 개발자들의 공감 하에 적절히 이용할 수 있어야 함(방법과 도구 및 경험)
       
  • CMM(Capability Maturity Model)
    • CMM은 독립적인 평가를 통해 소프트웨어 개발 조직이 얼마나 정의된 프로세스를 잘 지키는지에 대한 등급을 매기는 모델이며, 이는 프로세스 자체의 품질이나 결과물인 소프트웨어 대한 평가 우선하여 이루어짐
    • CMM은 서서히 CMMI(Capability Maturity Model Integration)로 대체됨
       
  • SPICE(Software Process Improvements Capability dEtermination, ISO15504)
    • SPICE는 소프트웨어 개발 프로세스의 평가를 위한 프레임워크로서, CMM이나, CMMI 만큼 널리 사용됨
    • SPICE를 이용하여 프로세스를 관리하고, 제어하고, 안내하며, 소프트웨어 개발 과정을 모니터링 할 수 있는 모델을 세울 수 있고, 세워진 모델을 이용하여 실제로 소프트웨어 개발 조직이나 개발팀이 소프트웨어 개발을 위해 수행하여야 하는 활동을 측정 할 수 있음
반응형

'밥벌이 > 소프트웨어 공학' 카테고리의 다른 글

프로젝트 규모 추정  (1) 2010.09.20
SOA(Service Oriented Architecture)  (0) 2010.09.20
구조적 방법론  (0) 2010.08.30
정보 공학 방법론  (0) 2010.08.30
객체 지향 방법론  (0) 2010.08.30