소프트웨어 생명주기(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가지 가치
- 용기(Courage): 용기를 가지고 자신감 있게 개발
- 단순성(Simplicity): 필요한 것만 하고 그 이상의 것들은 하지 않음
- 의사소통(Communication): 개발자, 관리자, 고객 간의 원활한 소통
- 피드백(Feedback): 의사소통에 대한 빠른 피드백
- 존중(Respect): 팀원 간의 상호 존중
- XP의 12가지 기본원리(실천항목)
- 짝프로그래밍(Pair Programming): 개발자 둘이서 짝으로 코딩하는 원리
- 공동 코드 소유(Collective Ownership): 시스템에 있는 코드는 누구든 언제라도 수정 가능하다는 원리
- 지속적인 통합(Continuous Integration): 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리
- 계획 세우기(Planning Process): 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리
- 작은 릴리즈(Small Release) 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리
- 메타포어(Metaphor): 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리
- 간단한 디자인(Simple Design): 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리
- 테스트 기반 개발(TDD; Test Driven Develop): 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 코드를 작성한다는 원리
- 리팩토링(Refactoring): 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리
- 40시간 작업(40 Hours Work): 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야 한다는 원리
- 고객 상주(On Site Customer): 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
- 코드 표준(Coding Standard): 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리
- XP의 5가지 가치
- 스크럼(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일)
'공부 > 정보처리기사' 카테고리의 다른 글
[6] 데이터 입출력 구현(논리 데이터 저장소) (0) | 2021.09.29 |
---|---|
[5] UI 설계 (0) | 2021.09.28 |
[4] UI 요구사항 확인 (0) | 2021.09.28 |
[3] 요구사항 (요구공학 Requirements Engineering) (0) | 2021.09.27 |
[2] 현행 시스템 분석 (현행 시스템 파악, 소프트웨어 아키텍처, 디자인 패턴, 개발 기술 환경 현행 시스템 분석) (0) | 2021.09.26 |
댓글