소프트웨어공학 2

소프트웨어 개발 방법론

* 패러다임(paradigm): 어떠한 시대 사람들의 견해나 사고를 근복적으로 규정하고 있는 테두리로서의 인식 체계 또는 사물에 대한 이론적인 틀이나 체계 → 사물을 바라보는 관점, 기본 틀, 접근방법, 스타일 등

 

1. SW 공학 paradigm의 정의

- SW 개발 시 고려해야 하는 개발 방법, 개발 환경, 개발 관리 등에 대한 이론적인 체계나 접근 방법

SW 개발 방법	SW를 어떻게 만들 것인가를 결정하는 기술적인 요소를 제시. 프로젝트에 대한 계획과 추정, 요구사항 분석, 코딩 등 개발 프로젝트 진행 단계에서 요구되는 기법과 수행되어야 할 과제를 포함
SW 개발 환경	개발 방법론을 지원해 주기 위해 필요한 CASE(Computer-Alded Software Engineering), DBMS 등을 포함. CASE, DBMS 등은 개발 환경을 개선하지만, 논리적인 것을 결정하는 사람을 대체할 수 없음.
SW 개발 관리	SW 개발 방법과 개발 환경을 묶어 시스템을 효율적으로 적시에 개발할 수 있도록 공정 과정과 절차를 제시. ex. 개발에 필요한 공정 단계, 각 단계별로 요구되는 입력과 결과물(문서, 보고서, 회의 결과), 품질보증을 위한 검증과 제어 장치 등에 대한 정의 등이 필요

 

2. 소프트웨어 개발 방법론의 정의

- 소프트웨어 개발, 유지보수 등에 필요한 여러 가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것 이다.

분야	의미	사례
방법(method)	소프트웨어 제작에 사용하는 기법이나 절차	- 구조적 분석 - 객체지향 분석 - 설계 방법
도구(tool)	자동화된 시스템	- 설계 도구 - 프로그래밍 도구 - 테스트 도구
프로세스(process)	도구와 기법을 사용하여 작업하는 순서	- unified process (단일화된 절차) - eXtreme programming (원형·나선형 모형)
패러다임(paradigm)	접근 방법, 스타일	- 구조적 방법론 (c언어) - 객체지향 방법론 (java, c++, python)

 

* 시대별 개발 방법론 도입 현황

 

3. SW 개발 방법론의 종류

구분	구조적 방법론	정보공학 방법론	객체지향 방법론	CBD 방법론 (Component Based Development)
목표	비즈니스 프로세스 자동화	경영전략적 정보시스템 구축	재사용 시스템	컴포넌트 개발 및 활용
접근방법	프로세스 중심	데이터 중심	객체중심 (데이터+프로세스)	컴포넌트 중심
특징	- 분할과 정복의 원칙 - 하향식 접근 - 모형적 설계 - 추상화 → 정형화 → 구체화	- 기업 업무시스템 지원 방법론 - data 모델 중시 - 프로그램 로직은 data 구조에 종속(CRUD) - 전사적 통합 데이터 모델	- 반복적, 점증적 개발 방식 - 데이터와 로직을 통합(객체) - 공학적 접근 - 상속에 의한 재사용	- 객체지향 진화된 형태 - interface 중시 (구현에 제약 없음) - 인터페이스 구현이 컴포넌트 - Black Box Reuse 지향
산업구조	소품종 다량 생산	다품종 소량생산	인터넷 비지니스	모바일 비즈니스
SDLC 모델	폭포수	폭포수 / 프로토타이핑	반복적 개발	반복적 개발
개발방식 자동화	Top-down 수작업 가능	Top-down 자동화 도구 요구	Bottom-up 자동화 도구 필요	Bottom-up 자동화 도구 필수
모델링	기능 모델링	데이터 모델링 프로세스 모델링	객체 모델링	객체 모델링 컴포넌트 모델링
요구분석 산출물	DFD (데이터 흐름도)	ERD (개체-관계도)	Usecase Diagram	-

↓ 요구분석 산출물 그림 (더보기 클릭)

 

DFD

ERD

Usecase Diagram

 

4. SW 개발 방법론 구성 요소

구성 요소	내용	비고
작업 절차	- 프로젝트 수행시 이루어지는 작업단계의 체계 - 단계별 활동, 활동별 세부 작업 나열, 활동의 순서 명시	작업순서 명시
작업 방법	- 각 단계별 수행해야 하는 작업 - 절차/작업 방법(누가, 언제, 무엇을 작업하는지 기술)	작업 절차
산출물	- 각 단계별 만들어야 하는 산출물의 목록 및 양식
관리	- 프로젝트의 진행 기록 - 계획 수립, 진행 관리, 품질, 외주, 예산, 인력 관리 등을 기록	일정 및 위험관리
기법	- 각 단계별 작업 수행시 기술 및 기법의 설명
도구	- 각 기법별 지원 도구에 대한 구체적인 사용 표준 및 방법	CASE, tool 등

 

소프트웨어 개발 생명주기(SDLC: Software Development Life Cycle)

1. SW 개발 생명주기(SDLC)의 정의

- SW 개발 방법론의 바탕이 되는 것으로 SW를 개발하기 위해 과정을 각 단계별로 나눈 것

→
요구사항 정의	소프트웨어 구현	유지보수	폐기

 

2. SW 개발 생명주기의 역할★

① 프로젝트의 비용 산정과 개발 계획을 수립할 수 있는 기본 골격이 된다.

② 용어 및 기술의 표준화를 가능하게 한다.

③ 문서화가 충실한 프로젝트 관리를 가능하게 한다.

④ 여러 소프트웨어 간에 상호 일관성을 유지하게 한다.

⑤ 프로젝트 진행 방향을 명확히 파악하게 한다.

 

3. SW 개발 생명주기의 일반적 공정 과정

1. 정의 단계 (what)	↓	1) 타당성 검토 단계	RFP
		2) 개발 계획 단계	수행계획서
		3) 요구사항 분석 단계	요구사항 명세서
2. 개발 단계 (how)		4) 설계 단계	설계 문서
		5) 구현 단계	실행 코드
		6) 테스트 단계	테스트 계획서, 결과서
3. 유지보수 단계 (change)		7) 유지보수 단계	유지보수 계획서, 폐기승인서

 

4. 타당성 검토 및 개발 계획

- 타당성 검토 단계: 개발할 SW가 법적·경제적·기술적으로 실현 가능성이 있는지 조사

- 개발 계획 단계: SW 개발에 사용될 일정, 인력과 비용을 측정하고 개발 문서를 만드는 과정

프로젝트 개요	프로젝트의 목표와 배경, 범위 등을 기술하며, 시스템 구성 및 시스템 배경도가 포함될 수 있다.
추진 전략	프로젝트 목적 달성을 위한 추진 전략 및 구축 방안을 제시한다.
위험 분석	프로젝트를 수행하며 예상되는 위험과 해결 방법을 기술한다.
자원 요구사항	시스템 구성과 개발에 요구되는 하드웨어, 소프트웨어 및 네트워크 구축장비 등의 자원 기술을 기술한다.
조직	프로젝트에 참여할 사람 및 역할 정의, 개발팀 구성과 업무 분할에 대해 기술한다.
관리	개발관리 방법, 추진 일정 계획, 품질보증 및 시험, 교육훈련계획 등을 기술한다.

① 공급자 기준

- 주문생산 제품(customized products): 구매할 고객이 확정, 일반적으로 고객이 많은 비용 부담

- 상업화될 제품(commercial products): 구매할 고객이 미정, 개발회사가 개발 비용을 부담

 

② 수요자 기준: 정보요청서 → 제안요청서 → 제안서 → 입찰 순으로 진행

구분	내용
정보요청서 (RFI: Request For Information)	- SW 개발사들의 회사소개, 시장동향, 경쟁사 정보 등을 받아 진행하고자 하는 프로젝트에 대한 정보를 미리 수집, 분석하는 준비단계 - 요청: 발주사(수요자) → 개발사(RFI) → 발주사
제안요청서 (REF: Request For Proposal)	- SW를 필요로 하는 회사에서 해결해야 할 문제들과 해결책에 대한 요구사항들을 설명하여 SW 개발 회사에 보내는 문서 - 필요로 하는 SW를 개발할 회사를 선택하지 않았을 때 사용 - 원하는 SW를 개발할 능력이 있다고 판단되는 회사에 보내지는 문서 또는 인터넷 등을 이용하여 공지 - 발주사(REP) → 개발사들
제안서 (Proposal)	- SW를 개발할 회사들은 제안요청서를 기초로 SW 개발계획을 담은 제안서를 작성 - 제안에 참여하는 목적과 배경, 프로젝트 추진 전략, 사업 수행 범위, 제안의 특징, 장점 및 차별성, 프로젝트를 수행하기 위한 조직, 기술, 관리, 결과물 등을 기술 - 개발사 → 발주사
입찰	- 제안서를 받아 심사하고, 선정 후 계약하는 과정

 

5. 요구사항 분석 단계

- 품질과 밀접한 관계이므로 사용자의 요구 사항을 보다 상세하고 정확하게 분석하는 단계

→
요구사항의 규명	타당성 조사 (feasibility study)	비용과 일정에 대한 제약 설정	요구사항 정의 문서화

① 요구사항의 규명

- 사용자의 관점에서 시스템의 요구사항을 모으는 것

- 기능(function) 요구, 성능(performance) 요구, 인터페이스(interface) 등의 예

- 업무 분석(요구 원인, 배경, 환경 등에 대한 분석) / 시스템이 필요하게 된 고객의 환경 분석

- 환경 분석

  내적 요소(인력 규모 축소, 생산성 증대, 기술력 향상, 서비스 향상)

  외적 요소(경쟁력 강화, 시장 여건의 변화, 법규나 제도의 변화)

 

② 타당성 조사

- 계획 단계나 분석 단계에서 수행

- 시스템 개발에 요구되는 시간, 비용, 인력 등의 자원 → 시스템의 타당성에 직접적인 영향

  경제적 타당성, 기술적 타당성, 법적 타당성, 대체 방안 등에 집중

 

③ 비용과 일정에 대한 제약 설정

- 요구사항을 분석하는 분석가는 응용 분야에 대한 해박한 지식이 요구된다. 개발 비용, 개발 일정, 시스템 성능 등에 대해서도 정확한 예측을 해야 하며, 프로젝트 관리가 매우 중요

관리 활동

- 요구되는 자원과 성취해야 할 임무 - 소요 기간 - 추적해야 할 이정표 등

 

④ 요구사항 정의 문서화

- 사용자의 요구사항과 시스템의 기능이 문서화되어야 한다. 고객과 개발 회사의 약속 문서(계약서).

- 고객과 함께 만드는 경우가 있으며, 프로젝트와 관계된 모든 사람이 읽고, 이해하기 쉽도록 작성되어야 함.

- 추후에 발생하는 문제와 변화에 대해 책임이 명확히 규명되어야 하고, 시스템에 연관된 당사자들이 동의하여 서명

* 주요 산출물: 요구사항 명세서 (= 기능 명세서, 기능 요구서)

중요한 산출물

요구사항 명세서 (requirements specification) - 기능 명세서, 목표 문서, 기능 요구서라고도 한다.

 

6. 설계 단계

- 설계(design): 요구사항 분석 과정에서 모아진 요구사항을 설계 도면에 옮기는 것

 

1) 설계 단계: SW의 구조, 알고리즘, 자료구조 등을 작성하는 단계 (에러가 가장 많이 발생)

- 무엇(what), 어떻게(how), 서브시스템(subsystem)들로 이루어지는 시스템 구조를 결정하고, 서브시스템들을 하드웨어 및 소프트웨어 등의 구성요소에 할당.

- 품질에 직접적인 영향을 주게 되며, 설계가 제대로 되지 않으면 안정감이 없는 시스템이 제공된다. 이런 시스템은 유지보수가 어렵고, 변경 사항 발생 시 재개발 가능성이 높다.

 

2) 설계 원칙 [잘 보기]

① 시스템을 구성 요소로 적절하게 분할

② 시스템의 구성요소들 사이에 주고받는 정보의 소통이 최소화되고, 각 구성요소의 독립성이 유지될 수 있도록 시스템을 분할한다.

③ 요구되는 성능과 자원에 대한 예측을 할 수 있어야 한다.

 

3) 분석단계 vs 설계단계

분석 단계	설계 단계
- 개념적(conceptual) 단계 - 무엇(what)을 제공할 것인가에 초점 - 무엇은 사용자나 시스템의 기능을 사용자의 관점에서 봄	- 물리적(physical) 실현의 첫 단계 - 어떻게(how to) 그 문제를 해결할 것인가를 결정 - 어떻게는 그 기능의 수행 방법을 엔지니어의 관점에서 봄

 

7. 구현 및 테스트 단계

1) 구현 단계: 설계 단계에서 작성된 문서를 기초로 프로그래밍(코딩) 하여 사용자가 이용할 수 있게 변환

- 시스템의 기능이 수행 가능한 모습으로 나타나게 됨. SW의 경우 설계가 제대로 이루어지면 시스템 구현은 상대적으로 단순하고, 기계적인 과정이 되어 효율적

 

8. 테스트 단계: 구현된 SW 제품의 내제된 오류를 발견하고, 수정하는 단계

 

9. 유지보수 단계: SW를 직접 사용하며, 변화에 초점을 두고 SW를 적용 및 유지시키는 단계로 시간과 비용이 가장 많이 투입되는 단계

- 시스템 변경에 의한 재요구 분석, 재설계, 재구현, 재테스트가 필요하게 되고, 관련된 문서의 수정까지도 수반하기 때문에 체계적인 관리 기능이 필요.

- 소프트웨어 시스템은 개발할 때부터 유지보수에 대비하여 만들어져야 함.

 

* 유지보수의 종류

① 잘못된 것을 수정하는 유지보수

② 시스템을 새 환경에 적응시키는 유지보수

③ 새로운 기능을 추가하는 유지보수 - 완전 유지보수

④ 미래의 시스템 관리를 위한 유지보수 - 예방 유지보수

 

* SW 품질보증(QA)을 위한 조건

- SW 일반 공정 과정인 계획, 분석, 설계, 구현, 테스트 및 유지보수 단계에 적용될 수 있는 기법과 도구들이 확립되어야 하며, 각 공정 과정의 임무, 입력물, 산출물, 사용도구 등도 정의

 

- SW 품질보증 활동 충족 조건★

① 사용자가 요구하는 기능적인 요구사항들이 만족되어야 함

② 요구사항에 대한 부합여부가 시스템 구축 전 과정에 걸쳐 확인되어야 함

③ 시스템의 성능에 관한 사양이 만족되어야 함

④ 정해진 비용과 기간의 목표가 만족되어야 함

 

10. SDLC 장·단점

- 장점

SW 개발 과정을 쉽게 이해하기 위한 효과적인 도구

SW 유형, 관점, 개발 방침, 요구 사항, 표준 정책에 따라 다양한 방법이 존재

요구사항 정의, 설계, 프로그래밍 등에 대한 기법들을 활용한 템플릿이 제공될 수 있음

체계적인 문서화, 단계별 산출물 체크를 통한 프로젝트 진행의 명확화

 

- 단점

문서 중심의 개발 접근 방식으로 개발자가 문서화에 대한 부담 가중

개발 초기에 사용자의 요구사항을 명확하게 찾아내기 어려움

완벽한 분석이 요구되며 피드백 과정이 없어 변경이 어려움