Chapter 01. 소프트웨어 개발방법론 활용
1. 소프트웨어 개발방법론 선정
(1) 소프트웨어 생명주기 모델
소프트웨어 생명주기(SDLC : Software Development Life Cycle) 모델 개념
소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다.
소프트웨어 생명주기 모델 프로세스 = 요설구테유
| 순서 | 프로세스 | 설명 | 활동 |
| 1 | 요구사항 분석 | 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계 | 기능 요구사항 비기능 요구사항 |
| 2 | 설계 | 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계 | 시스템 구조 설계 프로그램 설계 사용자 인터페이스 설계 |
| 3 | 구현 | 설계 단계에서 논리적으로 결정한 문제해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계 | 인터페이스 개발 자료 구조 개발 오류 처리 |
| 4 | 테스트 | 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이느지 검사하고 평가하는 단계 | 단위 테스트 통합 테스트 시스템 테스트 인수 테스트 |
| 5 | 유지보수 | 시스템이 인수되고 설치된 후 일어나는 모든 활동을 수행하는 단계 | 예방, 완전, 교정, 적응 유지보수 |
소프트웨어 샐명주기 모델 종류 = 폭프나반
| 종류 | 설명 |
| 폭포수 모델 (Waterfall Model) |
소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델 가장 오래된 모델 고전적 생명주기 모형 요구사항 변경이 어려움 절차 : 타당성 검토 > 계획 > 요구사항 분석 > 설계 > 구현 > 테스트 > 유지보수 |
| 프로토타이핑 모델 (Prototyping Model) |
고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델 프로토타입은 구현 단계의 구현 골격 |
| 나선형 모델 (Spiral Model) |
시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델 절차 : 계획 및 정의 > 위험 분석 > 개발 > 고객 평가 |
| 반복적 모델 (Iteration Model) |
구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델 |
(2) 소프트웨어 개발방법론
소프트웨어 개발방법론(Software Development Methodology) 개념
소프트웨어 개발방법론은 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법이다.
소프트웨어 개발방법론 종류
| 종류 | 설명 |
| 구조적 방법론 (Structured Development) |
전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론 나씨-슈나이더만 차트 특징(Nassi-Shneiderman) : 논리의 기술에 중점을 둔 도형식 표현 방법 |
| 정보공학 방법론 (Information Engineering Development) |
정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론 |
| 객체지향 방법론 (Object-Oriented Development) |
객체라는 기본 단위로 시스템을 분석 및 설계하는 방법론 |
| 컴포넌트 기반 방법론 (CBD : Component Based Development) |
소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론 소프트웨어 재사용이 가능 |
| 애자일 방법론 (Agile Development) |
절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 자율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발방법론 |
| 제품 계열 방법론 (Product Line Development) |
특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론 |
(3) 요구공학 방법론
요구공학 방법론(Requirements Engineering Methodology) 개념
요구공학 방법론은 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 방법이다.
요구사항 개발 프로세스 = 도분명확
요구사항 도출
요구사항 분석
요구사항 명세
요구사항 확인 및 검증
요구사항 개발 프로세스 상세
도출 = 인터뷰, 설문조사, 브레인스토밍, 워크숍
분석 = 자료 흐름 지향 분석, 객체지향 분석, 요구사항 체계화를 위한 분석
명세 = 자연어에 의한 방법, 정형화 기법 사용 방법
확인 및 검증 = 리뷰, 워크 스루, 인스펙션
요구사항 관리 프로세스 = 협기변확
| 순서 | 프로세스 | 내용 | 기법/산출물 |
| 1 | 요구사항 협상 | 가용한 자원과 수용 가능한 위험 수준에서 구현 가능한 기능을 협상하기 위한 기법 | 우선순위 결정, 시뮬레이션 |
| 2 | 요구사항 기준선 설정 | 공식적으로 검토되고 합의된 요구사항 명세서 | 공식 회의, 형상 관리 |
| 3 | 요구사항 변경 관리 | 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법 | 형상통제 위원회, 영향도 분석 |
| 4 | 요구사항 확인 및 검증 | 구축된 시스템이 이해관계자가 기대한 요구사항에 부합하는지 확인하기 위한 방법 | 확인 및 검증 |
(4) 비용산정 모델
비용산정 모델 개념
소프트웨어 규모파악을 통한 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 기법이다.
비용산정 모델 분류
| 분류 | 설명 | 종류 |
| 하향식 산정방법 | 경험이 많은 전문가에게 비용 산정을 의뢰하거나 여러 저눈가와 조정자를 통해 산정하는 방식 | 전문가 판단 델파이 기법 |
| 상향식 산정방법 | 세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식 | 코드 라인 수 LOC(Lines of Code) Man Month COCOMO 모형 Putnam 모형 FP(Function Point) 모형 |
비용산정 모델
| 모델 | 설명 |
| 코드 라인 수 LOC(Lines of Code) |
소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정 |
| Man Month | 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 기법 |
| COCOMO (COnstructive COst MOdel) |
보헴(Bohem)이 제안한 모형으로 프로그램 규모에 따라 비용을 산정 조직형(Organic Mode) : 기관 내부에서 개발된 중 소규모의 소프트웨어로 일괄 자료 처리나 과학 기술 계산용, 비즈니스 자료 처리 개발에 적용 반분리형(Semi-Detached Mode) : 트랜잭션 처리 시스템이나 데이터베이스 관리 시스템, 컴파일러, 인터프리터와 같은 유틸 개발에 적용 임베디드형(Embedded Mode) : 초대형 규모의 트랜잭션 처리 시스템이나 운영체제, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적용 |
| 푸트남(Putnam) 모형 | 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 모형 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소됨 |
| 기능점수(FP : Function Point) 모형 | 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식 |
(5) 일정관리 모델
일정관리 모델 개념
일정관리 모델은 프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델이다.
일정관리 모델 종류
| 모델 | 설명 |
| 주 공정법 (CPM : Critical Path Method) |
여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법 |
| PERT(Program Evaluation and Review Technique) | 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법 |
| 중요 연쇄 프로젝트 관리(CCPM : Critical Chain Project Management) | 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법 |
CPM에서 임계 경로 기간 계산
CPM 네트워크를 그려서 가장 긴 경로를 찾는다.
임계 경로는 시작 > 가 > 나 > 바 > 종료이다.
| 경로 | 기간 |
| 시작 > 가 > 나 > 바 > 종료 | 8+10+2+4=24일 |
| 시작 > 가 > 다 > 사 > 종료 | 8+5+1+4=18일 |
| 시작 > 라 > 사 > 종료 | 3+1+4=8일 |
| 시작 > 마 > 아 > 종료 | 7+6+4=17일 |
2. 소프트웨어 개발방법론 테일러링
(1) 소프트웨어 개발 표준
ISO/IEC 12207 구성 = 기조지
| 구분 | 주요 프로세스 |
| 기본 공정 프로세스 | 획득 프로세스, 공급 프로세스, 개발 프로세스, 운영 프로세스, 유지보수 프로세스 |
| 조직 공정 프로세스 | 기반 구조 프로세스, 관리 프로세스, 개선 프로세스, 훈련 프로세스 |
| 지원 공정 프로세스 | 문서화 프로세스, 품질 보증 프로세스, 형상 관리 프로세스, 검증 프로세스, 확인 프로세스, 문제 해결 프로세스, 활동 검토 프로세스, 감사 프로세스 |
CMMI
CMMI(Capability Maturity Model Integration) 개념
CMMI는 기존 능력 성숙도 모델을 발전시킨 것으로서, 기존에 소프트웨어 품질 보증 기준으로 사용되던 SW-CMM과 시스템 엔지니어링 분야의 품질 보증 기준으로 사용되던 SE-CMM을 통합하여 개발한 품질 개선 모델이다.
CMMI 모델
단계적 모델
연속적 모델
CMMI 단계적 표현 모델의 성숙도 레벨 = 초관정관최
| 수준 | 레벨 | 설명 |
| 1 | 초기화 단계 | 정의된 프로세스가 없고 작업자 능력에 따라 성과가 좌우되는 단계 |
| 2 | 관리 단계 | 특정한 프로젝트 내의 프로세스가 정의되고 수행되는 단계 |
| 3 | 정의 단계 | 조직의 표준 프로세스를 활용하여 업무를 수행하는 상태 표준화, 일관된 프로세스가 존재하는 단계 |
| 4 | 정량적 관리 단계 | 정량적 기법을 활용하여 핵심 프로세스를 통제하는 단계 |
| 5 | 최적화 단계 | 프로세스 역량 향상을 위해 신기술 도입, 프로세스 혁신 활동 수행하는 단계 |
SPICE
SPICE(Software Process Improvement and Capability dEtermination) 모델 개념
SPICE는 소프트웨어 프로세스에 대한 개선 및 능력측정 기준에 대한 국제 표준이다.
SPICE 프로세스 수행 능력 수준 단계 구성 = 불수관확예최
| 레벨 | 수준 | 설명 |
| 0 | 불안정 단계 | 프로세스가 구현되지 않았거나, 프로세스가 그 목적을 달성하지 못한 단계 |
| 1 | 수행 단계 | 프로세스의 목적이 전반적으로 이루어진 단계 |
| 2 | 관리 단계 | 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도 |
| 3 | 확립 단계 | 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행 |
| 4 | 예측 단계 | 프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행 |
| 5 | 최적화 단계 | 프로세스 수행을 최적화하고, 지속적으로 업무 목적을 만족 |
(2) 테일러링 기준
테일러링 개념
테일러링은 조직의 표준 프로세스를 커스터마이징하여 프로젝트의 비즈니스적으로 또는 기술적인 요구에 맞게 적합한 프로세스를 얻는 과정이다.
테일러링 프로세스 = 정표상세문
| 순서 | 프로세스 | 설명 |
| 1 | 프로젝트 특징 정의 | 사업목표, 현황확인, 프로젝트에 대한 이해 |
| 2 | 표준 프로세스 선정 및 검증 | 표준 프로세스 선정 표준 프로세스 검증 |
| 3 | 상위 수준의 커스터마이징 | 비즈니스 니즈에 따른 생명주기 정의 |
| 4 | 세부 수준의 커스터마이징 | 테일러링 매트릭스를 활용해 세부 WBS 적용 |
| 5 | 테일러링 문서화 | 결정 사항 문서화 검토 및 승인 |
테일러링 개발방법론의 기준 = 목요프구국법
| 구분 | 기준 | 설명 |
| 내부적 기준 | 목표환경 | 시스템의 개발 유형 및 기술 환경의 상이한 부분 조정 |
| 요구사항 | 프로젝트의 생명주기 활동 측면에서 개발/운영/요지보수 등 프로젝트에서 우선적으로 고려할 요구사항이 상이하므로 최적화 필요 | |
| 프로젝트 특성 | 사업비, 참여 인력, 납품 기간 등 프로젝트 특성이 서로 다르기 때문에 조정 필요 | |
| 구성원 능력 | 프로세스, 산출물, 방법론 등에 대한 참여 인력의 숙련도, 능력 등이 서로 다르기 때문에 조정 필요 | |
| 외부적 기준 | 국제 표준 품질 기준 | 프로젝트의 대상 도메인에 따라 산출물의 국제적 품질기준이 서로 다르기 때문에 조정 필요 |
| 법적 규제 | 프로젝트의 대상 도메인에 따라 적용되는 컴플라이언스가 서로 다르기 때문에 조정 필요 |
(3) 소프트웨어 개발 프레임워크
소프트웨어 개발 프레임워크(Software Development Framework) 개념
정보 시스템을 요구분석, 설계, 개발, 테스트하는 과정에 대한 기본 골격 또는 틀이다.
소프트웨어 개발 프레임워크 단계
개발준비 > 분석 > 설계 > 구현 > 시험 > 전개 > 인도
소프트웨어 개발 프레임워크 적용 시 기대효과
개발할 소프트웨어에 대한 품질 보증이 가능하다
소프트웨어 개발 용이성 증가
개발표준에 의한 모듈화로 유지보수가 용이하고 개발하고자 하는 소프트웨어의 복잡도 감소
https://book.naver.com/bookdb/book_detail.nhn?bid=15910265
수제비 정보처리기사 필기
NCS
'IT 자격증 > 정보처리기사' 카테고리의 다른 글
| 정보처리기사 필기 5주차 Day-3 정리 (0) | 2021.08.03 |
|---|---|
| 정보처리기사 필기 5주차 Day-2 정리 (0) | 2021.08.02 |
| (추가)정보처리기사 필기 4주차 Day-3 정리(추가) (0) | 2021.07.31 |
| 정보처리기사 필기 4주차 Day-2 정리 (0) | 2021.07.29 |
| 정보처리기사 필기 4주차 Day-1 정리 (0) | 2021.07.29 |