맨날 정리해봐야지 하면서도, 기술적인 요소들 익히는데 급급해 가장 기초적인 것들을 놓치고 있었다.
누군가에게는 기술적인 것들이 더 중요할 수 도 있지만, 내가 맡은 역할 기준에서는 고객과의 커뮤니케이션을 하는 데 있어서
이런 부분도 꼭 알아두어야 할 사항이다.
차근히 하나씩 공부하고 정리해봐야겠다!
# 소프트웨어 개발방법론
1. 방법론?
- 방법론이란, 무엇을 어떻게 해야 하는지 제시하는 것
- 특정한 목적을 달성하기 위해 사용되는 일련의 효율적인 기술 절차
- 방법론(Methodology) = 방법(Method) + 지식과 경험(Knowledge How)
2. 소프트웨어 개발방법론?
- 소프트웨어를 생산하는 데 필요한 반복적인 과정들을 정리한 것
- 소프트웨어 개발 계획 부터 구축, 운영에 이르기까지의 절차, 도구, 기법, 산출물 표준들의 체계적인 집합.
- 소프트웨어 공학 원리를 소프트웨어 생명주기에 적용한 개념으로, 정보시스템을 개발하기 위한 작업활동, 절차, 산출물, 기법 등을 체계화 한 것.
3. 소프트웨어 개발방법론 왜 쓰는건지?
(1) 작업의 표준화로 인한 프로젝트 관리 용이
- 프로젝트의 시작, 중간 과정, 종료의 기준이 명확해짐
- 관리 포인트를 지정할 수 있고, 전체 개발과정이 가시화 됨
(2) 효율적인 의사소통
- 표준 방법과 양식에 의거한 체계적인 요구사항 유지, 활용
- 정형화된 절차와 표준용어 사용을 통해 의사소통의 오류를 최소화.
- 고객 뿐만 아니라 프로젝트 팀 내부적으로도 효율적인 의사소통 가능
(3) 소프트웨어의 품질 관리
- 표준 산출물, 표준 절차를 통한 작업 기준 제시
- 도구와 기법 활용을 통한 작업 효율 극대화
- 각 단계별 검증과 종결승인을 통해 일정 수준의 품질 보증
- 소프트웨어 프로젝트가 대형화되면서, 개발기간의 장기화로 예산, 기간, 품질 상 복합적인 문제가 대두되었고, 이를 해결하기 위한
방법으로 소프트웨어 개발방법론 사용
4. 소프트웨어 개발방법론 구성요소
5. 소프트웨어 개발방법론의 변화
구조적 방법론 (Structured Development) |
정보공학 방법론 |
객체지향 방법론 |
CBD 방법론 (Component Based Development) | 서비스 지향 방법론 (Service Oriented Development) |
|
sum up | 업무활동 중심 절차중심 | 데이터 중심 모델링기반 | 객체, 클래스 및 이들의 관계를 식별하여 설계모델로 변환 | 재사용 가능한 컴포넌트를 사용한 개발 | |
역사 | 1970~1980년대 - 민간영역으로 컴퓨터가 사 용되면서 고객의 요구사항 발생 시작 - 체계적인 대응책 필요 - 1968, 소프트웨어 위기론 - 폭포수 방법론 등장 | - 과거의 소규모 프로그램 을 벗어나 기업 전사적 차 원의 대규모 시스템 구축 을 위한 체계적인 절차가 필요 | 1990년대 주류 - 대형 프로젝트 증가 - 객체지향언어(JAVA, C++) 전성기 - 반복과 통합 프로세스 탄생 | ||
대표적인 방법론 | 폭포수 방법론 | - 프로토타입 - 정보공학방법론 | - CBD - 반복적 개발 | - RUP - XP - Agile - 마르미 | |
프로세스 | 추상화 > 구체화 > 단계적 상세화 > 모듈화 | 정보전략계획 > 업무영역 분석 > 업무시스템 설계 > 시스템 구축 | 요건정의 > 객체지향 분석 > 객체지향 설계 > 테스트 / 배포 | 요구사항 분석 > 설계 > 개발 > 개발 및 테스트 > 릴리즈 > 교육 | |
특징 | - 프로그램 로직 중심 - 정보와 정보, 기능과 기능간의 구조화 - 하향식 - 프로세스 중심 - 절차적 프로그래밍 | - 프로그램 로직은 데이터 구조에 종속 - 데이터 모델 중시 - 기업의 전략경영에 맞는 시스템 구축을 중시함 - 공학적 접근 방식: 분석, 설계 등 초기 단계에서 철 저하게 작업 - 초기 단계 부터 사용자를 참여시켜 불명확한 요구사 항을 없애고자 함 | - 객체중심 - 사용자 참여 중시 - 데이터와 로직 통합(객체) - 고도의 모듈화 - 기업정보시스템 중심 | - 컴포넌트 기반 - 반복과 통합 중시 - 객체방법론의 진화된 형태 - 인터페이스 중시 - 프레임워크 지향 프로그래 밍 | |
관련언어 | - COBOL, C, VB, PASCAL | - C++, JAVA, C#, VB | |||
장점 | - 구조적 방법론에서는 상하 관계가 명확하고, 결합도가 | - 각 객체는 독립적이다. 즉, 응집도는 높고 결합도는 낮다 - 개별적인 객체의 작동은 파악하기 쉽다 - 각 객체가 독립적이여서 새로운 기능을 추가하거나 재활용 시, 기존 구조에 큰 영향을 주지않고 수정 가능 하다 | |||
단점 | - 폭포수모형의 특성처럼 잘 못된 작업에 대해서는 거 스르기가 어려운 경직된 구조 - 데이터 설계 방법의 결여 - 대규모의 복잡합 시스템에 비효율적 - 새로운 기능을 추가하거나 재활용하려면 각 기능들을 다시 뜯어내야 하므로 비용 이 많이 든다. | - 객체 전체의 작동 원리를 알기 위해서는 객체간의 관 계 정립이 필요하다
| |||
기타 | - 시스템의 대표적인 기능을 찾아내고, 대표적인 기능을 수행하기 위한 서브 기능을 찾아가는 식으로 분석 - 예를 들어, '사람'을 구조적으로 분석하면 대표기능: 밥먹기 서브기능: 이빨로 씹는다 > 목구멍으로 넘긴다 > 위에서 녹인다 > 장에서 흡수한다
| - 컴포넌트: 인터페이스를 통 해 서비스를 제공하는 소프 트웨어 패키지 - 세부에서 전체를 만들어가 는 상향식 방법 - 시스템의 구성요소들을 찾 아내고, 구성 요소들간의 연관성을 증명해내는 과정 - 예를 들어, '사람'을 객체지 향적 분석을 해보면 1. 객체모델링: 뇌, 눈, 코, 귀, 입, 치아, 심장, 근육 등 2. 기능모델링: 이빨로 자른 다, 목구멍을 통해 넘긴다, 위에서 녹인다 등 | |||
Q. 어느 방법론이 가장 잘 만들어진 방법론인지? 방법론 선택 기준은?
--> A. 최고의 방법론이 무엇인지에 대한 답은 없다. 프로젝트 특성, 규모, 가용자원, 요구사항의 명확도, 프로젝트 참여자의 수준, 프로젝트 기간 등의
프로젝트 환경을 고려했을 때 가장 적합한 방법론을 찾는 것이 해당 프로젝트에게는 최고의 방법론이 된다.
Q. 객체지향방법론과 CBD 방법론의 차이는?
--> A. 우선, 두 방법론은 재사용의 범위나 규모가 다른 만큼 기본 개념이나 개발 방식에 있어 많은 차이가 있다.
단순히 객체를 재사용하느냐, 컴포넌트를 재사용하느냐의 차이는 아니다.
컴포넌트 역시 객체 재사용을 통해 만들어지고, 객체가 만들어지면서 컴포넌트화 되기 때문에 재사용 대상만을 놓고 비교하기엔 애매하다.
1. 소스코드 재사용 vs binary 파일 재사용
: 객체지향방법론은 소스코드 레벨의 표준만 가지고 있었다. 하지만 CBD는 binary 파일 형태의 재사용을 가능하게 해주었다.
2. 클래스(class) vs 컴포넌트(component)
: class는 시스템 분석/설계의 모델링 활동의 결과이고, component는 프로그램된 결과물이다.
class는 논리적 측면의 재사용이라 볼 수 있고, component는 물리적 측면의 재사용이라 볼 수 있다.
component의 활용규모가 더 크므로, 재사용 효과도 더 크다고 볼 수 있다.
3. 접근 방법
: component는 interface를 통해 접근 가능하다. 따라서 요구사항에 부합하는 component를 시장에서 구입/활용 가능하다.
표준화된 아키텍처만 준수한다면, 다른 컴포넌트로 쉽게 교체도 가능하며, 높은 유지보수성과 호환성을 보장한다.
4. 개발 vs 조립
: 객체지향방법론이 재사용을 통한 효과적인 '개발'에 초점을 맞춘다면, CBD는 개발보다는 '조립'에 초점을 맞춘다.
component를 식별하고 정의하는 것이 CBD의 핵심.
Q. 구조적방법론과 정보공학방법론의 차이는?
-->
__________________________________________________________________________________________________________________________________________________________
** 본 포스팅에 대해 수정해야할 부분이나 추가 의견 등이 있으신 분들은 댓글 달아주세요. 언제나 환영입니다 :)
** 본 포스팅은 아래의 reference 들을 참고하여 내용을 덧붙인 글입니다. 혹시, 문제가 되는 경우 알려주시면 조치하도록 하겠습니다.
** 본 포스팅을 reference 자료로 참고하실 분들은 출처를 꼭 밝혀주시기 바랍니다.
- http://zakarum.tistory.com/
- http://m.blog.naver.com/seilius/130185981952
- ttps://ko.wikipedia.org/wiki/
- http://blog.naver.com/neovader/150015541094
- http://imp17.com/tc/myevan/185
- http://m.blog.naver.com/jvioonpe/220246556042