본문 바로가기
공부/정보처리기사

[1] 소프트웨어 개발 방법론

by Lagooni 2021. 9. 24.

소프트웨어 생명주기(SDLC: Software Development Life Cycle) : 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다.

소프트웨어 생명주기 모델 프로세스

순서 프로세스 설명 활동
1 요구사항 분석 개발할 소프트웨어의 기능과 제약조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계 기능 요구사항
비기능 요구사항
2 설계 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계 시스템 구조 설계
프로그램 설계
사용자 인터페이스 설계
3 구현 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계 인터페이스 개발
자료 구조 개발
오류 처리
4 테스트 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계 단위 테스트
통합 테스트
시스템 테스트
인수 테스트
5 유지보수 시스템이 인수되고 설치된 후 일어나는 모든 활동 예방, 완전, 교정, 적응 유지보수

소프트웨어 생명주기 모델 종류 (폭프나반): 

  • 폭포수 모델:
    • 장단점: 가장 오래된 모델, 선형 순차적 모형으로 사례가 많음. 단계별 정의와 산출물이 명확하지만 요구사항 변경이 어려움
    • 절차: 계획 - 요구사항 분석 - 설계 - 구현 - 테스트- 유지보수
  • 프로토타이핑 모델
    • 장단점: 요구분석 용이 타당성 검증 가능, 프로토타입 생성 및 폐기에 대한 비용 증가
    • 절차: 요구사항 분석 - 프로토타입 개발 - 프로토타입 평가 - 구현 - 테스트
  • 나선형 모델
    • 시스템 개발 시 위험을 최소화 하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
    • 장단점: 위험성 감소와 변경에 대한 유연한 대처, 단계 반복에 따른 관리의 어려움
    • 절차(계위개고): 계획 및 정의 - 위험분석 - 개발 - 고객 평가
  • 반복적 모델
    • 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 모델
    • 장단점: 병행 개발로 인한 일정 단축, 병행 개발에 따른 관리 비용 증가

소프트웨어 개발 방법론(Software Development Methodology): 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법이다. 소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지 전 과정을 형상화한 방법론.

소프트웨어 개발 방법론의 종류:

  • 구조적 방법론(Structured Development)
    • 전체 시스템을 기능에 따라 나누어 개발하고 이를 통합하는 분할과 정복 접근 방식의 방법론
    • 프로세스 중심의 하향식 방법론
    • 나 씨-슈나이더만(Nassi-Shneiderman)차트 사용
    • 나씨-슈나이더만 차트 특징: 논리의 기술에 중점을 둔 도형식 표현 방법, 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는데 적합
  • 정보공학 방법론(Information Engineering Development)
    • 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
  • 객체지향 방법론(Object Oriented Development)
    • 객체라는 기본단위로 시스템을 분석 및 설계하는 방법론
    • 복잡한 현실세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론
  • 컴포넌트 기반 방법론(Component Based Development)
    • 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
    • 개발기간 단축으로 인한 생산성 향상, 확장성 용이, 소프트웨어 재사용 가능
  • 애자일 방법론(Agile Development)
    • 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
    • 기존 개발과정의 어려움(한계)을 극복하기 위해 적극적으로 모색한 방법론이다.
    • 개발기간이 짧고 신속하며 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아 유동적으로 개발할 수 있다.
  • 제품 계열 방법론(Product Line Development)
    • 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
    • 임베디드 소프트웨어를 작성하는데 유용
    • 영역 공학과 응용공학으로 구분
      • 영역 공학: 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역
      • 응용공학: 제품 요구분석, 제품 설계, 제품을 구현하는 영역

애자일 방법론의 유형

  • XP(eXtreme Programming)
    • 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
    • 5가지 가치와 12개의 실천항목이 존재
      • XP의 5가지 가치
        1. 용기(Courage): 용기를 가지고 자신감 있게 개발
        2. 단순성(Simplicity): 필요한 것만 하고 그 이상의 것들은 하지 않음
        3. 의사소통(Communication): 개발자, 관리자, 고객 간의 원활한 소통
        4. 피드백(Feedback): 의사소통에 대한 빠른 피드백
        5. 존중(Respect): 팀원 간의 상호 존중
      • XP의 12가지 기본원리(실천항목)
        1. 짝프로그래밍(Pair Programming): 개발자 둘이서 짝으로 코딩하는 원리
        2. 공동 코드 소유(Collective Ownership): 시스템에 있는 코드는 누구든 언제라도 수정 가능하다는 원리
        3. 지속적인 통합(Continuous Integration): 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리
        4. 계획 세우기(Planning Process): 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리
        5. 작은 릴리즈(Small Release) 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리
        6. 메타포어(Metaphor): 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리
        7. 간단한 디자인(Simple Design): 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리
        8. 테스트 기반 개발(TDD; Test Driven  Develop): 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 코드를 작성한다는 원리
        9. 리팩토링(Refactoring): 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리
        10. 40시간 작업(40 Hours Work): 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야 한다는 원리
        11. 고객 상주(On Site Customer): 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
        12. 코드 표준(Coding Standard): 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리
  • 스크럼(SCRUM)
    • 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
  • 린(Lean)
    • 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상한 방법론
    • JIT(Just In Time), 칸반(Kanban) 보드 사용
    • 7가지 원칙: 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

애자일 방법론과 전통적 방법론 비교

비교 대상 애자일 방법론 전통적 방법론
계획수립 유동적 범위 설정 확정적 범위 설정
업무수행 팀 중심 업무 수행 관리자 주도적 명령과 통제, 개인 단위로 업무 수행
개발/검증 반복 주기 단위로 소프트웨어를 개발 검증 분석/설계/구현/테스트를 순차적으로 수행
팀 관리 업무 몰입, 팀 평가 경쟁, 개별 평가
문서화 문서화보다는 코드를 강조 상세한 문서화를 강조
성공요소 고객 가치 전달 계획/일정 준수
유형  XP, 스크럼, 린 폭포수, 프로토타입, 나선형

비용 산정 모형 개념: 소프트웨어 규모 파악을 통한 투입자원, 소요시간을 파악하여 실행 가능한 계획을 세우기 위한 방식

비용 산정 모형 분류

  • 하향식 산정방법
    • 경험이 많은 전문가에게 비용 산정을 의뢰하거나 전문가와 조정자를 통해 산정하는 방식
    • 전문가 판단, 델파이 기법(전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법)
  • 상향식 산정방법
    • 세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식
    • 코드 라인 수(LoC), Man Month, COCOMO모형, 푸트남(Putnam) 모형, 기능점수(FP) 모형

비용 산정 모형 종류

LoC(Lines of Code) 모형

  • 소프트웨어 각 기능의 원시 코드 라인수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하여 비용을 산정하는 방식
  • 측정이 쉽고 이해하기 쉬워 많이 사용함
  • 예측치 = (낙관치 + 4*중간치 + 비관치)/6
    • 비관치: 가장 많이 측정된 코드 라인 수
    • 중간치: 측정된 모든 코드 라인 수의 평균
    • 낙관치: 가장 적게 측정된 코드 라인 수

Man Month 모형

  • 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 비용을 산정하는 방식
  • Man Month = LoC/프로그래머의 월간 생산성
  • 프로젝트 기간 = Man Month/프로젝트 인력

COCOMO(COnstructive COst MOdel) 모형

  • 보헴(Bohem)이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식이다.
  • 비용 산정 결과는 필요한 노력(Man Month)으로 산정한다.
  • 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 널리 통용된다.
  • COCOMO의 소프트웨어 개발 유형
    • 조직형(Organic Mode): 기관 내부에서 개발된 중 소규모의 소프트웨어로 일괄 자료처리나 과학 기술 계산용, 비즈니스 자료처리 개발에 적용 (5만 라인 이하의 소프트웨어를 개발하는 유형)
    • 반 분리형(Semi-Detached Mode): 단순형과 임베디드형의 중간형. 트랜젝션 처리 시스템이나 데이터베이스 관리 시스템, 컴파일러, 인터프리터와 같은 유틸 개발에 적용(30만 라인 이하의 소프트웨어를 개발하는 유형)
    • 임베디드형(Embedded Mode): 초대형 규모의 트랜잭션 처리 시스템이나 운영체제, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적용(30만 라인 이상의 소프트웨어를 개발하는 유형)

푸트남(Putnam) 모형

  • 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 방식
  • 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.

기능점수(Function Point) 모형

  • 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 비용을 산정하는 방식이다.
  • 기능점수(FP) = 총 기능점수 X [0.65 + (0.1 + 총영향도)]

일정관리 모델 개념: 프로젝트가 일정 기한 내에 적절하게 완수될 수 있도록 관리하는 모델

일정관리 모델 종류

모델 설명
주 공정법(CPM; Critical Path Method) 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
모든 자원 제약사항을 배제한 상태로 프로젝트의 시작과 끝을 나타내는 노드와 노드간의 연결을 통해 공정을 계산하기 위한 액티비티 표기법
PERT(Program Evaluation and Review Technique) 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법
중요 연쇄 프로젝트 관리(CCPM; Critical Chain Project Management) 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법
주 공정(Critical Path; 임계 경로)이란? 
프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로이다.

주 공정법(CPM)을 이용한 일정 계산

시작 지점부터 종료까지 가장 긴 경우는 A-C-F를 거치는 경우이다. (7일)

댓글