1. 소프트웨어 개발 방법론의 정의
소프트웨어 개발 방법론은 소프트웨어를 어떻게 만들지에 대한 관심을 가지게 된다.
따라서 개발 방법론에는 단계별 산출물뿐만 아니라 산출물을 누가 어떤 순서로 어떻게 만들어야 하는지, 그리고 어떤 도구를 사용해야 하는지를 구체적으로 정의하고 있다.
2. 소프트웨어 개발 방법론의 종류
소프트웨어의 개발 방법론은 크게 5가지로 나뉘며,
-
구조적 개발 방법론
-
정보공학 개발 방법론
-
객체지향 개발 방법론
-
컴포넌트 기반(
CBD) 개발 방법론 -
애자일, 폭포수 모델, 프로토타입 개발 방법론
등이 있다.
3. 구조적 개발 방법론
구조적 방법론은 구조, 흐름, 간결, 간단 이 구조적 개발 방법의 특징이다.
요구사항 분석 -> 구조적 분석 -> 구조적 설계 -> 구조적 프로그래밍 순서로 이루어져 있다.
3-1. 구조적 개발 방법론의 특징
3-1-1. 구조적 개발 방법론의 단계
위의 그림을 참고하면,
-
요구사항 분석 단계
-
데이터, 시스템 환경, 사용자 요구기능 등을 분석하는 단계이다.
-
고객이 원하는 요구사항을 끌어내 명세화한다.
-
-
구조적 분석 단계
-
DFD,DD,Minispec등을 작성하고DB를 분석하는 단계이다. -
고객이 원하는 기능/시스템 환경/데이터를 종합하여 데이터 흐름도(
DFD)를 작성한다.데이터 흐름도(
DFD,Data Flow Diagram)란?
데이터 흐름도는 유구사항 분석에서 데이터의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법으로 데이터 흐름 그래프, 버블 차트라고도 하며, 데이터 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화된다.데이터 사전(
DD,Data Dictionary)이란?
데이터 사전은 데이터 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것으로, 이처럼 데이터를 설명하는 데이터를 데이터의 데이터 또는 메타 데이터(Meta Data)라고 한다.소단위 명세서(
Minispec)란?
소단위 명세서는 세분화된 데이터 흐름도에서 최하위 단계 버블(프로세스)의 처리 절차를 기술한 것으로 프로세스 명세서라고도 하며, 분석가의 문서이며 데이터 프름도(DFD)를 지원하기 위해 작성한다.
-
-
구조적 설계 단계
-
구조적 분석 단계에서의
DB분석을 통해DB설계 및 어플리케이션을 설계하는 단계이다. -
모듈 중심으로 설계를 진행하며, 재활용 가능하도록, 결합도를 낮춰서 독립성을 높이기 위한 목적으로 진행한다.
-
-
구조적 프로그래밍 단계
-
위의 3단계의 논리적인 구조를 통해 실질적인 프로그래밍을 진행하는 단계이다.
-
순차, 선택, 반복의 논리 구조 구성으로 프로그램 복잡성을 최소화한다.
-
3-2. 구조적 개발 방법론의 장/단점
3-2-1. 구조적 개발 방법론의 장점
-
명확한 요구사항을 추출하여 설계에 반영이 가능하며, 정형화/체계화가 가능하다.
-
효율적인 재사용 및 유지보수가 용이한 모듈화가 가능하다.
3-2-2. 구조적 개발 방법론의 단점
-
거시적 관점의 인식이 부족하며, 방법론에 대한 다양한 시도를 하고 있지 않다는 뜻으로 프로젝트에서만 사용하는 추세이다.
-
실제 사례를 기반으로 하는 자료 부족으로 데이터 모델링 방법과 명확한 방법론적 지침이 미흡하다.
-
유지보수성 및 재사용성이 낮기 때문에 기능이 불완전하고 자주 변한다.
4. 정보공학 개발 방법론
정보공학 개발 방법론은 비지니스 시스템 규모 성장과 소프트웨어 공학 발전에 따라 1980년대 중반에 등장한 방법론이다.
기업 전체 또는 기업의 주요 부분을 계획, 분석, 설계 및 구축에 정형화된 기법들을 상호 연관성있게 통합, 적용하는 데이터 중심 방법론이다.
4-1. 정보공학 개발 방법론의 특징
4-1-1. 정보공학 개발 방법론의 단계
위의 그림을 참고하면,
-
정보 전략 계획 수립 단계 (
ISP,Information Strategy Planning)-
기업의 경영 전략을 뒷받침할 수 있는 정보화 전략을 수립하기 위해 현행 업무 프로세스와 시스템을 분석하고 미래 아키텍처와 전략 계획을 수립하는 단계이다.
-
경영 전략, 관련 조직, 업무 자료를 거시적으로 분석하며, 현행 시스템을 평가한다.
-
-
업무영역 분석단계(
BAA,Business Area Analysis)-
기업의 업무 현황을 분석해서 개념 수준의 데이터와 프로세스를 설계하는 업무 분석 단계이다.
-
ERD를 통해 데이터 모델링을 진행하며, 프로세스 계층도(PHD), 프로세스 의존도(PDD), 데이터 흐름도(DFD) 등의 프로세스 모델링을 진행한다.
-
-
업무 시스템 설계단계(
BSD,Business System Design)- 실질적으로 시스템을 설계하는 단계로 우리가 많이 사용하고 있는 논리적
ER다이어그램으로 데이터를 설계하고 분할 다이어그램, 액션 다이어그램, 의존 다이어그램을 사용해 프로세스를 설계한다.
- 실질적으로 시스템을 설계하는 단계로 우리가 많이 사용하고 있는 논리적
-
시스템 구축단계(
SC,System Construction)- 확정된 설계 명세서로부터 데이터 베이스 생성기와 프로그램 코드 생성기를 이용해 데이터 베이스와 실행 가능한 프로그램 코드를 생성한다.
4-1-2. 정보공학 개발 방법론의 개념
설계할 때는 스토리 보드, 데이터 설계서,
UI설계서 정도를 작성하고 개발 과정에서는 이를 바탕으로 물리적 테이블과 프로그램 코드가 만들어 진다.이런 관점에서 정보공학 방법론을 바라 본다면
BAA에 해당하는 요구분석 단계에서는 요구사항 명세서가 만들어지고BSD에 해당하는 시스템 설계 단계에서는 논리ERD와 업무 프로세서를 설명하는 프로세스 구조도/흐름도가 만들어 진다.그리고
SC에 해당하는 개발 단계에서는 물리ERD,UI, 프로그램 코드가 개발된다.
4-2. 정보공학 개발 방법론의 장/단점
4-2-1. 정보공학 개발 방법론의 장점
-
경쟁 우위 전략적 기회를 식별할 수 있으며, 방안 또한 제공이 가능하다.
-
일관/통일된 정보 시스템을 구축할 수 있다.
-
데이터 중심으로 업무의 절차가 진행되며 환경 변화에 유연하다.
4-2-2. 정보공학 개발 방법론의 단점
-
정보 공학의 효과를 위해 장기간이 소요된다.
-
특정 사업 영역으로부터 독립된 시스템의 개발에 부적합하다.
-
소규모 자동화 요구 사업에는 부적합하다.
5. 객체지향 개발 방법론
객체지향 개발 방법론은 현실 세계의 개체(
Entity)를 속성(Attribute)과 메소드(Method)가 결합된 형태의 객체(Object)로 표현한다.이를 통해 현실 세계에 존재하는 실체 및 개념들을 객체(
Object)라는 독립된 단위로 구성하고 이 객체들이 메시지 교환을 통해 상호작용함으로써 전체 시스템이 운영되는 개념이다.
5-1. 객체지향 개발 방법론의 특징
객체지향 개발 방법론에서는 분석, 설계, 구현의 전 과정을 객체 중심으로 진행한다.
심지어 데이터를 저장하는 테이블도 따로 설계하지 않고 데이터 객체로 설계하며, 데이터는 결국 데이터 베이스에 저장되는데 만일 데이터 베이스가 객체형
DB라면 별다른 변환 과정 없이 데이터 객체를 그대로 저장하면 되지만, 관계형DB를 사용한다면 객체를 관계형 테이블로 변환하는 과정이 필요하다.이 과정을 객체-관계 매핑(
Object Relation Mapping)이라 하며 현재 대부분의 회사에서 관계형 데이터 베이스를 사용하고 있기 때문에 객체-관계 매핑은 필수적인 과정이라 할 수 있다.
5-1-1. 객체지향 개발 방법론의 특성
- 추상화 (
Abstraction)
객체지향 이전에도 많이 다뤘던 설계 개념으로, 불필요한 세부 사항은 배제하고 핵심이 되는 공통 사항을 묶어 개략화하는 작업을 말한다.
- 캡슐화 (
Encapsulation)
객체지향 그 자체를 설명하는 개념으로 볼 수 있으며, 속성과 메소드와 같은 각 알맹이들을 하나의 캡슐 안에 넣어서, 안에 무엇이 들어있는지 모르게 할수도, 한 입 크기로 먹어 삼키게 할 수도 있는 작업이다.
- 정보은닉 (
Information Hiding)
캡슐화된 객체 내부에 자료 구조나 함수의 기능을 외부의 영향을 받거나 주지 않도록 설계하는 방법이다.
- 상속성 (
Inheritance)
객체지향만의 특정으로 볼 수 있으며, 이 객체를 만드는 클래스들을 PC의 폴더(트리) 구조와 같이 부모/자식 계층으로 구성하여, 자식(하위) 계층에서는 부모(상위) 계층의 성질을 물려받을 수 있도록 하는 특성으로, 객체 간 메시지 전달을 통해 프로그래밍하는 방법이다.
- 다형성 (
Polymorphism)
같은 메시지에 대해 클래스에 따라 다른 행위를 하게 하는 특성으로, 부모로부터 상속받은 메소드를 자식이 재정의할 수 있다. (오버라이딩)
5-1-2. 객체지향 개발 방법론의 구성요소
| 구분 | 내용 |
|---|---|
| 클래스 | - 같은 종류(또는 문제 해결을 위한)의 집단에 속한 속성(Attribute)과 행위(Behavior)이다. |
- 객체 지향 프로그램의 기본적인 사용자 정의 데이터형 (user define data type)이다. | |
| 객체 | - 자신 고유의 데이터(Attribute)를 가지며 클래스에서 정의한 행위(Behavior)를 수행한다. |
- 객체는 클래스의 한 인스턴스(instance)가 된다. | |
| - 데이터(실체)와 그 데이터에 관련되는 동작(절차, 방법, 기능)을 모두 포함한 개념이다. | |
| 메소드 | - 클래스로부터 생성된 객체를 사용하는 방법 |
| 메시지 | - Sender 와 Receiver 객체들간의 상호작용의 수단으로 다른 객체에 특정 작업을 요청하는 신호이다. |
| - 수신 객체 이름, 오퍼레이션 이름, 매개 변수로 구성된다. |
5-1-3. 객체지향 개발 방법론의 단계
위의 그림을 참고하면,
-
개념화 단계(
Inception Phase)-
시스템에 대한 비즈니스 사례(
Business Case)를 만들고 프로젝트 범위(Scope)를 정의한다. -
시스템과 상호작용을 하는 모든 외부 엔티티(
Actor)를 명시하고, 상위 레벨(High Level)에서 상호작용의 특징을 정의한다. -
모든 유즈케이스(
Use Case)를 명시하고 중요한 몇 가지를 설명하는 것도 포함된다. -
비즈니스 사례는 성공기준(
Success Criteria), 위험관리(RiskManagement), 필요한 자원의 평가, 주요한 이정표 날짜를 보여주는 단계별 계획을 포함한다. -
개념화 단계의 마지막에는 프로젝트 목적을 검사하고 개발 진행 여부를 결정한다.
-
-
상세화 단계(
Elaboration Phase)-
문제영역(
Problem Domain)을 분석하고 견고한 아키텍처 토대를 마련하고 프로젝트 계획을 개발하며 프로젝트에서 가장 위험한 요소를 제거하는 것이다. -
아키텍처에 대한 결정은 전체 시스템의 충분한 이해를 통하여 이루어져야 하며, 이것은 유즈케이스를 기술하고 추가적인 요구사항과 같은 제약사항을 고려하는 것을 의미한다.
-
아키텍처를 검증하기 위해서는 선정된 아키텍처를 실현하고(
demonstrates) 중요한 유즈케이스를 실행하는 시스템을 구현하는 것이다. -
상세화 단계의 마지막에는 상세한 시스템의 목적과 범위 및 아키텍처 선정과 주요 위험을 검사한다.
-
-
구축 단계(
Construction Phase)-
구축 단계에서는 사용자들(
User Community)에게 전이할 수 있도록 반복 및 점증적으로 제품을 완전히 개발하는 것으로, 이것은 나머지 유즈케이스를 기술하고 설계 부문을 더욱 충실하게 하며, 구현을 완전히 끝내고 소프트웨어를 테스트하는 것을 의미한다. -
구축 단계의 마지막에는 소프트웨어와 환경과 사용자들이 운영될 준비가 되었는지를 결정한다.
-
-
전이 단계(
Transition Phase)-
소프트웨어를 사용자들(
User Community)에게 전달하는 것이다. -
제품이 사용자의 손에 전해졌을 때에는, 시스템에 적합하도록 추가적인 개발 및 발견되지 않은 문제점을 수정하고 미루어 놓은 사항들(
Features)을 마무리 짓는다. -
일반적으로 이 단계는 시스템의 "베타 릴리즈(
Beta Release)"로 시작된다. -
전이 단계의 마지막에는 생명주기 목적의 충족여부 및 또 다른 개발 주기의 시작여부를 결정해야 하며, 또한 프로세스를 개선하기 위해 프로젝트에서 경험한 것을 여기서 정리한다.
-
5-2. 객체지향 개발 방법론의 장/단점
5-2-1. 객체지향 개발 방법론의 장점
-
규모가 큰 대형 프로젝트에 적합하다.
-
소프트웨어의 재사용률/확장성/유지보수성이 향상된다.
-
신속하게 개발이 가능하다.
-
사용자 타입을 중심으로 개발된다.
-
대화식 프로그램 개발에 용이하다.
5-2-2. 객체지향 개발 방법론의 단점
-
설계 단계가 어렵다.
-
규모가 크기 때문에 실행 속도가 저하된다.
6. CBD 개발 방법론
CBD개발 방법론(Component Base Development) 은 개발된 S/W 컴포넌트를 조립, 시스템을 개발하여 객체지향의 단점인 S/W 재사용성을 극대화한 개발 방법론이다.컴포넌트는 인터페이스로 접근 가능하고 독립적인 기능을 수행하는 모듈로써 교체가 가능한 소프트웨어 부품이다.
6-1. CBD 개발 방법론의 특징
CBD개발 방법론은 크게 컴포넌트를 개발하는CD(Component Development) 단계와 개발된 컴포넌트를 사용해서 개발을 진행하는CBD(Component Base Development) 단계로 나눌 수 있다.
CD단계에서는 도메인을 분석해 컴포넌트 대상 업무를 선별하고 컴포넌트를 개발해 저장소에 입력한다.
CBD단계에서는 요구 분석을 통해 컴포넌트 기반으로 설계하고 필요한 컴포넌트를 저장소에서 찾아서 조립하는 방식으로 프로그램 개발을 진행한다.만일 필요한 컴포넌트가 저장소에 없다면
CD단계로 돌아가서 컴포넌트를 개발하고 이를 사용해 개발을 계속 진행한다.
6-1-1. CBD 개발 방법론의 단계
위의 그림을 참고하면,
-
요구 파악
-
사용자 요구사항을 수집, 도메인을 분석하며, 요구사항 기술서, 용어 사전, 개념 모델등을 이해한다.
-
요구사항 이해를 기반으로 유즈케이스를 작성하며 요구사항을 정의한다.
-
-
분석 및 설계
-
객체 모델의 프로토타이핑 및
UI를 시획하여 객체 모델과UI설계서를 제작하며 요구사항을 분석한다. -
아키텍쳐 기술서를 작성하며 소프트웨어 컴포넌트 아키택처를 정의한다.
-
아키택처를 기반으로
I/D명세화와 모델링을 진행하며, 인터페이스 명세서와 컴포넌트 명세서를 작성하며 컴포넌트 설계를 한다. -
객체 모델의 텐티티 클래스를 대상으로
DB를 모델링하며,ERD,DB설계서를 작성하며 데이터 베이스를 설계한다.
-
-
구현
- 플랫폼 특성을 검토하며, 표준을 수립하고 명명 규칙, 코딩 규칙, 프로그래밍 가이드 등의 개발 표준 정의를 한다.
- 플랫폼에 따른 전용
Compiler를 이용하며 코드를 구현한다.
-
테스트
-
테스트의 목표와 대상, 방법, 절차 등을 수립하며 테스트 계획을 진행하고 계획서를 작성한다.
-
테스트의 수행, 절차 기록 및 승인을 진행하며, 컴포넌트 테스트, 통합 테스트, 인수 테스트 등의 보고서를 작성하며 테스트에 대한 수행/보고를 진행한다.
-
6-2. CBD 개발 방법론의 장/단점
6-2-1. CBD 개발 방법론의 장점
-
반복적인 활용에 의한 수익성 제고 및 개발 기간과 개발 비용이 감소한다.
-
검증된
Component사용으로 S/W의 품질 수준을 향상시킨다. -
지적 자산의 재활용 범위가 확대된다.
-
소프트웨어 개발, 유지보수 부문의 생산성을 극대화시킬 수 있다.
6-2-2. CBD 개발 방법론의 단점
-
파라다임 변화에 따른 시행 착오가 따른다.
-
고객과의 문제제로 인해 프로젝트의 잦은 범위 변경 요청에 취약하다.
-
초기 선행에 투자가 필요하다.
-
조립식 정보 시스템 구축에 따른 각각의 책임이 따른다.
7. 애자일 개발 방법론
애자일 개발 방법론은 기존 방법론들이 너무 절차를 중시한 나머지 변화에 대응하기 어려웠던 단점을 개선하기 위해 나왔다.
애자일 방법론은 절차보다는 사람을, 문서보다는 작동하는 소프트웨어를, 미리 철저하게 계획하기 보다는 변화에 대한 민첩한 대응을, 계약과 협상에 얽매이기 보다는 고객과의 협력을 중요하게 생각한다.
7-1. 애자일 개발 방법론의 특징
애자일 방법론에서는 먼저 개발 범위 안에 있는 요구사항을 분석해 우선 순위가 높은 요구사항을 먼저 개발한다.
개발된 부분에 대해 실행하는 모습을 보여줘서 고객의 평가를 받고 고객의 요구사항과 개선사항을 반영해 다음 요구사항 개발에 참고한다.
이런 방식을 계속 반복하면서 소프트웨어 개발 범위를 점진적으로 늘려가게 되는데, 여기에서 가장 핵심이 되는 사항은 단계별로 고객에게 동작하는 소프트웨어를 계속 보여주고 요구사항에 대한 변경을 적극적으로 수용한다는 것이다.
7-1-1. 애자일 소프트웨어 개발 12대 원칙
-
고객 만족
-
변화 수용
-
자주 납품
-
팀으로 작업
-
동기부여
-
대면 소통
-
가독성 측정
-
속도 일정 유지
-
품질 최우선
-
복잡하지 않도록
-
설계 진화
-
규칙적 반영
7-1-2. 애자일 개발 방법론의 단계
위의 그림을 참고하면,
-
계획 및 분석
- 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 S/W 기능과 제약 조건을 정의하는 명세서 작성, 대상이 되는 문제 영역과 사용자가 원하는
Task를 이해하는 단계이다.
- 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 S/W 기능과 제약 조건을 정의하는 명세서 작성, 대상이 되는 문제 영역과 사용자가 원하는
-
설계 (디자인)
- 기획 의도에 맞는 설계 및 디자인 추가 및 수정하는 단계이다.
-
개발 (발전)
- 설계 단계에서 만들어진 설계서를 바탕으로 프로그램을 작성, 코딩, 디버깅, 단위/통합 테스트를 수행한다.
-
테스트
- 발생할 수 있는 실행 프로그램 오류를 발견, 수정하는 단계이다.
-
검토 (피드백)
- 기획 의도를 파악하고 시험 결과와 기획에 따라 수정할 부분을 제시하는 단계이다.
7-2. 애자일 개발 방법론의 장/단점
7-2-1. 애자일 개발 방법론의 장점
-
프로젝트 계획에 걸리는 시간을 최소화할 수 있다.
-
점진적으로 테스트할 수 있어서 버그를 쉽고 빠르게 발견할 수 있다.
-
계획 혹은 기능에 대한 수정과 변경에 유연하다.
-
고객 요구사항에 대한 즉각적인 피드백에 유연하며 프로토타입 모델을 빠르게 출시할 수 있다.
-
빠듯한 기한의 프로젝트를 빠르게 출시할 수 있다.
7-2-2. 애자일 개발 방법론의 단점
-
확정되지 않은 계획 및 요구사항으로 인한 반복적인 유지보수 작업이 많다.
-
고객의 요구사항 및 계획이 크게 변경되면 모델이 무너질 수 있다.
-
개인이 아닌 팀이 중심이 되다 보니 공통으로 해야 할 작업이 많을 수 있다. (회의, 로그 등)
-
반복적인 업무로 속도는 빠를 수 있으나 미흡한 기능들에 대한 대처가 필요하다.
-
확정되지 않은 계획으로 개발 진행 시 이해하지 못하고 진행하는 부분이 많을 수 있다.
8. 결론
-
구조적 개발 방법론
정형화 된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화 하는 처리 중심의 방법론
-
정보공학 개발 방법론
정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료 중심의 방법론
-
객체지향 개발 방법론
객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
-
CBD개발 방법론정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료 중심의 방법론
-
애자일 개발 방법론
고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행하는 방법론
참고 사이트
해시넷 - 소프트웨어 개발방법론
공대생의 차고 - 기술사 준비/SW공학 - 개발 방법론
My LifeChronicle - [소프트웨어공학] 객체지향 개발 방법론
인코덤 - 소프트웨어 개발 방법론
log.log.log.log.log.log - 개발 방법론
AI IMPACTS - [개발방법론] 객체지향방법론이란?
느리게 생각하기 - 구조적 분석 도구
