개요
소프트웨어 개발 방법론은 소프트웨어를 어떻게 만들지에 대한 관심이다.
따라서 개발 방법론에는 단계별 산출물뿐만 아니라 누가 어떤 순서로 어떻게 만들어야 하는지, 그리고 어떤 도구를 사용할 건지에 대한 구체적인 정의이다.
소프트웨어 개발방법론의 구성은 아래 표와 같다.
작업 절차 | 소프트웨어를 진행할 때 이루어지는 작업의 순서 |
작업 방법 | 각 단계별 작업마다 수행해야 할 일(누가, 언제, 무엇을) |
산출물 | 단계별로 나오는 산출물(설계서, 명세서) |
관리 | 개발 진행을 어떻게 제어하고 감독할 것인지 |
기법 | 단계별 작업 시 사용하는 기술 또는 기법(DFD, ERD, Use Case) |
도구 | 사용하는 기법 별 지원 도구 |
종류
소프트웨어의 개발 방법론은 크게 정보공학 방법론, 객체지향 방법론, CBD 방법론, 애자일 방법론으로 나눌 수 있다.
상기 4가지 방법론의 단점을 보완하거나 각각의 방법론의 장점을 따온 개발론도 있다.
1. 구조적 방법론
구조, 흐름, 간결, 간단 이 4개의 요소가 구조적 개발방법의 특징이다.
개발 과정은 '요구사항 분석' -> '구조적 분석' -> '구조적 설계' -> '구조적 프로그래밍 순서'로 구성되어 있다.
먼저 '요구사항 분석'은 고객이 원하는 요구사항을 명세화 하는것이다.
'구조적 분석'은 고객이 원하는 기능 / 시스템 환경 / 데이터를 종합하여 데이터 흐름도를 작성한다.
'구조적 설계'는 모듈 중심 설계 단계로 그 목적은 재활용, 결합도를 낮춰 독립성을 확보하는 데에 있다.
'구조적 프로그래밍'은 순차, 선택, 반복의 논리 구조 구성으로 프로그램 복잡성을 최소화한다.
구성요소는 아래 표와 같다.
종류 | 내용 |
데이터흐름도 DFD(Data Flow Diagram) | 각 기능을 분할하여 표현한 구조도 |
자료사전 DD(Data Dictionary) | 자료나 의나 자료의 단위 및 값에 대한 사항을 정의하는 도구로 DFD에 표현된 자료 저장소를 구체적으로 명시하기 위해 사용 |
상태전이도 STD(State Transition Diagram) | 보통 어떤 상태에서 다른 상태로 변경되는 과정 및 해당 과정의 프로세스를 명세 |
소단위명세 Minispec(Mini Specification) | 쪼갤 수 없을 정도로 기능을 분리한 다음 명세 |
장점
- 정형화/체계와 : 명확한 요구사항을 추출하여 설계에 반영
- 모듈화: 효율적인 재사용 및 유지보수 기능
단점
- 거시적 관점 인식 부족: 방법론에 대한 다양한 시도 하지 않음
- 실제 사례 자료 부족으로 데이터 모델링 방법과 명확한 방법론적 지침이 미흡
- 유지보수성 및 재사용성이 낮음으로 기능이 불완전하고 변경이 빈번함
2. 정보공학 개발 방법론
정보공학 개발 방법론은 비즈니스 시스템 규모 성장과 소프트웨어 공학 발전에 따라 1980년대 중반에 등장한 방법론으로 기업 전체, 또는 기업의 주요 부분을 계획, 분석, 설계 및 구축에 정형화된 기법들을 통합하여 적용하는 데이터 중심 방법론이다.
개발 과정은 '정보전략계획 수립단계' -> '업무영역 분석 단계' -> '시스템 설계단계' -> '시스템 구축 단계'로 구성되어 있다.
'정보전략계획 수립단계, ISP(Informaion Strategy Planning)'는 기업의 경영전략을 뒷받침할 수 있는 정보화 전략을 수립하기 위해 현행 업무 프로세스와 시스템을 분석하고 미래 아키텍처와 전략 계획을 수립하게 된다.
'업무영역 분석 단계, BAA(Business Area Analysis)'는 기업의 업무 현황을 분석하여 개념 수준의 데이터와 프로세스를 설계하는 업무분석 단계이다.
'시스템 설계단계, BSD(System Design)'는 실질적으로 시스템을 설계하는 단계로 우리가 많이 사용하고 있는 논리적 ER 다이어그램으로 데이터를 설계하고 분할 다이어그램, 액션 다이어그램, 의존 다이어그램을 사용해 프로세스를 설계한다.
'시스템 구축 단계, SC(System Construction)'는 확정된 설계 명세서로부터 데이터베이스 생성기와 프로그램 코드 생성기를 통해 데이터베이스와 실행 가능한 프로그램 코드를 생성한다.
구성요소는 아래 표와 같다.
종류 | 내용 |
정보전략계획 (ISP) | 경영전략, 관련조직, 업무자료 거시적 분석, 현행시스템 평가 |
업무영역 분석 (BAA) | 데이터 모델링 : ERD, 프로세스 모델링 : DFD |
업무시스템 설계 (BSD) | 업무절차 정의, Presentation 설계 , 분산설계 |
시스템 구축 (SC) | 응용 프로그램 작성 |
장점
- 경쟁우위 확보의 전략적 기회 식별 및 방안을 제공한다.
- 일관성 있고 통일된 정보시스템 구축 가능하다.
- 시스템의 장기적인 진화, 발전을 허용한다.
- 데이터 중심으로 업무절차 및 환경변화에 유연하다.
단점
- 정보공학의 효과를 위해 장기간 필요하다.
- 소규모의 자동화 요구 사업영역에서는 시간이 오래 걸린다.
- 특정 사업영역으로부터 독립된 시스템 개발에는 부적합하다.
3. 객체지향 개발 방법론
객체지향 개발 방법론은 현실 세계의 개체를 속성과 메소드로 결합된 형태의 객체로 표현하고, 현실세계에 존재하는 실체나 개념들을 객체라는 독립된 단위로 구성하고 이 객체들의 상호작용으로 운영되는 개념이다.
개발 방법은 '개념화 단계' -> '상세화 단계' -> '구축 단계' -> '전이 단계'로 구성되어 있다.
'개념화 단계'는 시스템에 대한 비즈니스 사례와 상호작용할 모든 외부 엔티티를 명시하고 상위 레벨에서 상호작용의 특징을 정의한다. 비즈니스 사례는 성공 기준, 위험관리, 필요한 자원의 평가, 주요한 이정표 날짜를 보여주는 단계별 계획을 포함하고 마지막에는 프로젝트 목적을 검사하고 개발 진행 여부를 결정한다.
'상세화 단계'는 문제 영역을 분석하고, 견고한 아키텍처 토대를 마련하고, 프로젝트 계획을 개발하며 프로젝트에서 가장 위험한 요소를 제거한다. 아키텍처에 대한 결정은 전체적인 시스템의 이해를 통해 이루어져야 하고, 유즈 케이스를 기술하여 추가적인 요구사항과 제약사항을 고려해야 한다.
'구축 단계'는 사용자들에게 배포할 수 있도록 반복 및 점증적으로 제품을 완전히 개발하는 단계이다. 나머지 유즈케이스를 기술하고 설계부문에 충실하여 구현을 완전히 끝내고 소프트웨어를 테스트해야 한다.
'전이 단계'는 소프트웨어를 사용자들에게 배포하는 것으로, 제품을 상용화하였을 때에는 시스템에 적합하도록 추가적인 개발 및 발견되지 않은 이슈들을 수정하고 미루어 놓는 사항들을 마무리 짓는다.
구성요소는 아래 표와 같다.
클래스 | * 같은 종류(또는 문제 해결을 위한)의 집단에 속한 속성(attribute)과 행위(behavior)이다. * 객체 지향 프로그램의 기본적인 사용자 정의 데이터형 (user define data type)이다. |
객체 | * 자신 고유의 데이터(attribute)를 가지며 클래스에서 정의한 행위(behavior)를 수행한다. * 객체는 클래스의 한 인스턴스(instance)가 된다. * 데이터(실체)와 그 데이터에 관련되는 동작(절차, 방법, 기능)을 모두 포함한 개념이다. |
메소드 | * 클래스로부터 생성된 객체를 사용하는 방법 |
메시지 | * Sender 와 Receiver 객체들간의 상호작용의 수단으로 다른 객체에 특정 작업을 요청하는 신호이다. * 수신객체이름, 오퍼레이션 이름, 매개변수로 구성된다. |
장점
- 객체 중심 모형은 인간의 사고방식과 유사하다.
- 뚜렷하게 구별되는 객체로 나누고 객체들의 메시지는 상호 작용 수단으로 활용한다.
- 클래스의 재사용과 확장에 의한 빠른 개발이 가능
- 상속(inheritance), 다형성(polymorphism) 등이 있다.
- 개발 각 단계의 전환이 자연스럽고 신속하다.
단점
- 개발 수준이 저 수준의 추상화 개념이므로 실제로 재사용 가능한 소프트웨어 개발은 기대하기 어렵다.
- 개발의 생산성 및 유지보수성을 위한 아키텍처 및 표준 적용이 어렵다.
- 대규모 프로젝트에서의 확장성이 떨어진다.
3. CBD 개발 방법론
CBD(Component Base Development) 개발 방법론은 개발된 소프트웨어의 컴포넌트를 조립, 시스템을 개발하여 객체지향의 단점인 재사용성을 극대화한 개발 방법론이다. 컴포넌트는 인터페이스로 접근 가능하고 독립적인 기능을 수행하는 모듈로써 교체가 가능한 소프트웨어 부품이다.
개발 방법은 '요구 파악' -> '분석 및 설계' -> '구현' -> '테스트'로 구성되어 있다.
'요구 파악'은 사용자 요구사항을 수집하여 이를 기반으로 유즈 케이스를 작성하고 개념 모델들을 정의한다
'분석 및 설계'는 요구사항을 분석하여 아키텍처를 정의하고 컴포넌트를 설계하여 객체 모델의 엔티티 클래스를 대상으로 DB를 모델링한다.
'구현'은 명명규칙, 코딩규칙, 프로그래밍 가이드 등 개발 표준을 정의하여 표준을 수립하고, 플랫폼 특성을 검토한다.
'테스트'는 테스트 목표, 대상, 방법, 절차를 기반으로 테스트 계획서를 만들고 테스트를 수행을 통해 절차 기록 및 승인을 받는다.
장점
- 재사용을 통한 생산성 향상 à 반복적 활용에 의한 수익성 제고 및 개발 기간 단축, 개발 비용 감소
- 소프트웨어 개발, 유지보수 부문의 생산성 극대화 가능
- 검증된 Component 사용으로 S/W 품질 수준 향상
단점
- 조립식 정보시스템 구축에 따른 책임 소재
- 초기 선행 투자
- 패러다임 변화에 따른 시행착오
4. 애자일 개발 방법론
애자일 개발 방법론은 기존 방법들의 절차가 까다롭고 중시되어 나머지 변화에 대응하기 어렵다는 단점을 개선하기 위해 고안되었다.
애자일 방법론은 절차보다는 사람을, 문서보다는 동작하는 소프트웨어를, 미리 철저하게 계획하기보다는 변화에 유연함을, 계약과 협상에 얽매이기보다는 고객과의 협력을 중요시한다.
애자일 개발 방법론의 핵심은 '협력'과 '피드백'이다.
'협력'에는 내부적인 협력이 있다.
내부적인 협력이란 소프트웨어를 개발한 팀 안에서 하는 협력을 말하며 직무, 역할을 넘어선 협력을 말한다.
협력을 통해 다른 사람의 좋은 의견을 수용할 수 있고, 생각하지 못한 구멍을 발견할 수 있기 때문이다.
'피드백'에는 내부적 피드백과 외부적 피드백이 있다.
먼저 내부적 피드백은 직접 개발한 프로젝트가 얼마만큼 진행되었고 작동이 완성되었는지 확인하는 것이다.
외부적 피드백은 고객이나 다른 부서가 사용해보고 그것을 통해 분석된 문제점이나 미비한 부분을 확인하고 수정하는 것이다.
장점
- 점진적인 테스트를 통해 버그를 빠르게 발견할 수 있다.
- 수정과 변경에 유연하다.
- 프로젝트를 시작할 때 계획에 소모되는 시간을 줄일 수 있다.
- 서비스 출시일을 앞당길 수 있다.
단점
- 작업에 우선순위를 두는 경우 일부 항목에 일정상 구멍이 생길 수 있다.
- 하이 레벨의 팀원을 필요로 한다.
- 최종 제품이 요구사항과 다르게 도출될 수 있다.
'CS' 카테고리의 다른 글
Garbage Collection (0) | 2022.05.25 |
---|---|
Process와 Thread (0) | 2022.05.17 |
임계 영역 동시접근 해결 방안 (0) | 2021.12.21 |
임계 구역과 경쟁 상태 (0) | 2021.12.21 |
객체 지향 프로그래밍 및 설계 5가지 원칙 (0) | 2021.03.22 |