[5과목]
01. 소프트웨어 개발방법론 활용
1. 소프트웨어 개발방법론 선정
(1) 소프트웨어 생명주기 모델
- 1. 소프트웨어 생명주기(SDLC; Software Development Life Cycle) 모델 개념
- 소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다.
- 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한
작업 프로세스를 모델화한 것이다.
- 2. 소프트웨어 생명주기 모델 프로세스
| 순서 | 프로세스 | 설명 | 활동 |
| 1 | 요구사항 분석 | - 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계 - 개발할 소프트웨어의 기능과 제약조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계 |
기능 요구사항 비기능 요구사항 |
| 2 | 설계 | - 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행방법을 논리적으로 결정하는 단계 |
시스템 구조 설계 프로그램 설계 사용자 인터페이스 설계 |
| 3 | 구현 | - 설계 단계에서 논리적으로 결정한 문제해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계 - 프로그래밍 언어 선택, 기법, 스타일, 순서 등을 결정하는 단계 |
인터페이스 개발 자료 구조 개발 오류 처리 |
| 4 | 테스트 | - 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계 |
단위 테스트 통합 테스트 시스템 테스트 인수 테스트 |
| 5 | 유지보수 | - 시스템이 인수되고 설치된 후 일어나는 모든 활동을 수행하는 단계 | 예방 완전 교정 적응 유지보수 |
- 3. 소프트웨어 생명주기 모델 종류
소프트웨어 생명주기 모델 종류로는
폭포수 모델 , 프로토타이핑 모델 , 나선형 모델 , 반복적 모델이 있다.
| 종류 | 설명 | 절차도 |
| 폭포수 모델 (Waterfall Model) |
(특징) 순차적 접근(고전적 생명주기 모델, 하향식 모델) - 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델 - 가장 오래된 모델 - 선형 순차적 모형으로, 고전적 생명주기 모형이라고도 함 - 모형의 적용 경험과 성공 사례가 많음 (장점) 이해가 용이, 관리가 편리 - 단계별 정의와 산출물이 명확 (단점) 요구사항 변경이 어려움 |
1. 타당성 검토 2. 계획 3. 요구사항 분석 4. 설계 5. 구현 6. 테스트 7. 유지보수 |
| 프로토타이핑 모델 (Prototyping Model) |
(특징) 프로토타입 개발 - 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델 (장점) 요구분석 용이, 타당성 검증 가능 - 프로토타입은 발주자나 개발자 모두에게 공동의 참조 모델을 제공 - 포로토타입은 구현 단계의 구현 골격 (단점) 프로토타입 폐기에 따른 비용 증가 |
1. 요구사항 분석 2. 프로토타입 개발 3. 프로토타입 평가 > 1. 4. 구현 5. 테스트 |
| 나선형 모델 (Spiral Model) |
(특징) 위험분석, 반복개발 - 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델 (장점) 위험성 감소와 변경에 대한 유연한 대처 (단점) 단계 반복에 따른 관리 어려움 |
1. 계획 및 정의 2. 위험 분석 3. 개발 4. 고객 평가 > 1. |
| 반복적 모델 (lteration Model) |
(특징) 증분방식으로 병행 개발 - 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델 (장점) 병행 개발로 인한 일정 단축 가능 - 사용자의 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델 (단점) 병행 개발에 따른 관리 비용 증가 |
>분석 설계 구현 개발 >분석 설계 구현 대상 >분석 설계 구현 >분석 설계 구현 |
(2) 소프트웨어 개발방법론
- 1. 소프트웨어 개발방법론(Software Development Methodology) 개념
- 소프트웨어 개발방법론은 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법이다.
- 소프트웨어를 하나의 생명체로 간주하고
소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론이다.
2. 소프트웨어 개발방법론 종류
- 소프트웨어 개발방법론 종류로는 (구정객컴애제)
구조적 방법론, 정보공학 방법론, 객체지향 방법론, 컴포넌트 기반 방법론(CBD), 애자일 방법론, 제품계열방법론 있다
| 종류 | 설명 |
| 구조적 방법론 (Structured Development) |
- 전체 시스템을 기능에 따라 나누어 개발하고 이를 통합하는 분할과 정복 접근 방식의 방법론 - 프로세스 중심의 하향식 방법론 - 구조적 프로그래밍 표현을 위해 나씨-슈나이더만(Nassi-Shneiderman) 차트 사용 ** 나씨-슈나이더만(Nassi-Shneiderman) 차트 특징 : 논리의 기술에 중점을 둔 도형식 표현 방법 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조로 표현 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합 |
| 정보공학 방법론 (Information Engineering Development) |
- 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론 - 개발주기를 이용해 대형 프로젝트를 수행하는데 체계적인 방법론 |
| 객체지향 방법론 (Object-Oriented Development) |
- "객체"라는 기본 단위로 시스템을 분석 및 설계하는 방법론 - 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론 - 객체, 클래스, 메세지 사용 |
| 컴포넌트 기반 방법론 (CBD; Component Based Development) |
- 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론 - 개발 기간 단축으로 인한 생산성 향상 - 새로운 기능 추가 쉬움(확장성) - 소프트웨어 재사용이 가능 |
| 애자일 방법론 (Agile Development) |
- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적용하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발방법론 - 애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론 |
| 제품 계열 방법론 (Product Line Delvelopment) |
- 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론 - 임베디드 소프트웨어를 작성하는 데 유용한 방법론 - 영역 공학과 응용 공학으로 구분 ** 영역 공학 : 영역분석, 영역설계, 핵심자산을 구현하는 영역 응용 공학 : 제품 요구분석, 제품설계, 제품을 구현하는 영역 |
(3) 요구공학 방법론
- 1. 요구공학 방법론(Requirements Engineering Methodology) 개념
- 요구공학 방법론은 사용자의 요구가 반영된 시스템을 개발하기 위해여
사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 방법임
- 요구공학 프로세스는 요구사항 개발단계와 요구사항 관리단계로 구성됨
- 2. 요구공학 특징
- 고객과 개발자가 요구사항의 의미를 서로 다르게 이해하는 경우, 시스템 개발이 실패할 가능성이 증대됨
- 시스템이 사용되는 동안 발견되는 오류의 상당 부분은 요구사항의 오류에서 파생됨
- 구조적 요구분석을 하기 위해 블록 다이어그램을 채택한 자동화도구로 SADT가 있음
- 3. 요구사항 개발 프로세스
| 순서 | 단계 | 기법 | 설명 | 내용 |
| 1 | 요구사항 도출 |
인터뷰 | - 1:1 관계에서 사용자 및 의사결정권자와 시스템에 대한 요구사항을 추출하는 기법 - 철저한 사전 준비 작업 필요 |
소프트웨어가 해결해야할 문제를 이해하고 고객으로부터 제시된 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체화함 (주요활동) 고객분석 조직 환경 분석 후보 유구사항 분류 후보 요구사항 정제 요구사항 소스 관리 |
| 설문조사 | - 설문지 또는 여론조사 등을 이용해 간접적으로 정보 수집 - 개발될 시스템의 사용자가 다수일 때 의견 수렴에 용이 |
|||
| 브레인스토밍 | - 말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판없이 수용 |
|||
| 워크숍 | - 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법 - 프로젝트에 참여하는 모든 핵심 인물의 참여가 필요 - 참석자들은 해당 전문 영역별로 팀 협력이 필요함 - 사전 준비가 요구 |
|||
| 2 | 요구사항 분석 |
자료흐름 지향분석 |
- 데이터 흐름도(DFD; Data Flow Diagram)으로부터 소프트웨어 구조를 유도하는 방법 |
도출된 요구사항의 충돌, 중복, 누락 등의 분석을 통해 완전성과 일과성을 확보하는 단계 (주요활동) 비용과 일정에대한 제약설정 타당성 조사 요구사항 정의문서화 |
| 객체지향분석 | - 시스템의 기능과 데이터를 함께 분석하는 기법 - UML로 표준화 |
|||
| 요구사항 체계화를 위한 분석 |
- 요구사항 분류, 요구사항 협상, 요구사항 할당 - 개념 모델링, 정형 분석 |
|||
| 3 | 요구사항 명세 |
자연어에 의한 방법 |
- 사용자와 개발자의 이해가 용이한 방법 - 명확성 및 검증에 문제 |
체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계 (주요활동) 요구사항 명세기준정의 요구사항 명세서 작성 요구사항 추적정보저장 |
| 정형화 기법 사용 방법 |
- 명확성 및 검증이 용이한 방법 - 기법의 이해가 어려움 |
|||
| 4 | 요구사항 확인 및 검증 |
리뷰 | - 동료와 기술 전문가가 참여하는 요구사항 검증을 위한 문서화되고 정의된 프로세스 존재 - 관리자 개입이 없는 동료 검토 형태로 수행 가능 |
분석가가 요구사항을 이해했는지 호가인하고 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 형상관리를 수행 및 검증하는 단계 리소스가 요구사항에 할당되기 전에 문제를 파악하기 위해 검증 수행 (주요활동) 요구사항 명세서 검토 요구사항 용어 검증 요구사항 베이스라인 수립 |
| 워크스루 | - 시간 및 인원수 등에 제한이 없고 상황에 따라 변경할 수 있는 세션 - 미팅 전 준비과정 수행 |
|||
| 인스펙션 | - 역할 정의, 체크리스트와 규칙 기반의 정식 프로세스존재 - 미팅 전 준비과정 필요, 후속 처리 절차 프로세스 존재 |
- 5. 요구사항 관리 프로세스
(4) 비용산정 모델
(5) 일정관리 모델
2. 소프트웨어 개발방법론 테일러링