개발 방법론 (Development Methodology)에 대하여
: 시스템 개발의 이론적 기반
: 소프트웨어를 개발하는 방법에 대한 이론으로서, 소프트웨어 개발 과정, 절차, 방법, 산출물, 기법, 도구들을 체계적으로 정리하고 표준화시킨 것.
과거에 비해 개발 및 시스템 통합 작업이 복잡하고 긴 개발일정을 필요로 하게 됨.
⇒ 몇몇 개발자에 의존하기 보다 프로젝트의 관리와 이의 바탕이 되는 개발 방법론의 중요성이 부각되게 됨.
1. 구조적 방법론
: 절차 중심의 SW개발 방법론. 폭포수 모델이 대표적
DFD (Data Flow Diagram, 데이터 흐름도)
: 데이터의 흐름을 도식화한 지도.
Yourdon/DeMarco 표기법 
예시1: data storage와 data flows, function, interface가 포함된 data-flow diagram (출처: https://en.wikipedia.org/wiki/Data-flow_diagram) 
예시2 (출처: https://imgur.com/mWThNjS)
기업의 데이터 전산화 발전
MIS의 문제점.
기존의 정보시스템 개발 노력은 한마디로 임기응변적이라고 평가할 수 있다. 특정 사용 부서에서 정보시스템에 대한 요구가 있을 때만 이에 대응한 개발노력이 전개되는 단편적 방법을 취하였다. 그러다 보니 한 부서를 위해 개발해 준 시스템과 타부서의 시스템이 서로 자료를 공유할 수 있는 체제가 마련되지 못한다거나 동일한 내용의 정보가 여러 시스템에 중복 저장되어 있기도 하는 등 많은 문제점을 초래하였다.
ERP, 즉 통합 정보 시스템이 필요하게 됨.
실제 정보시스템은 경영방침 및 조직업무 등과 분리될 수 없다. 오늘날 필요한 것은 조직의 업무를 총괄적으로 분석하고 정보흐름을 파악하여 조직에 알맞은 정보구조를 도출한 다음, 이를 토대로 사용 부서의 요구를 만족시켜 나가는 방법이다. 즉, 조직의 전사적 정보시스템 계획의 수립이 요구된다고 하겠다.
(참고: https://www.reportshop.co.kr/biz/343622)
정보 시스템이 단순한 업무 지원의 도구를 넘어 경영 전략을 창출하는 경영정보 시스템(Management Information System, MIS)으로 진화. 여기서 다시 통합 정보 시스템(Enterprise Resource Planning, ERP)으로 진화.
바람직한 정보 체계를 설계하는 데 활용될 수 있는 기법으로 정보공학 방법론이 쓰인다.
정보 공학 방법론은 초기에는 생산성과 품질 개선에 초점을 둔 전략이었으나, 점차 기업 경영 전략을 창출하는 정보 전략 계획(Information Strategy Planning, ISP)으로 진화
(ISP ⇒ “정보를 이용해서 전략을 짜자”)
(https://www.lgcns.com/blog/cns-tech/solution/16499/)
참고: MIS와 ERP의 다른 점은?
MIS (Management Information System, 경영 정보 시스템)
: 필요한 소프트웨어를 구입하거나 직접 개발하여 자사의 업무 프로세스에 맞게 구축하여 사용하는 것. 업무별(회계, 인사, 급여관리 등)로 시스템이 쪼개져 있다.
장점: 업무 프로세스 표준화가 크게 요구되지 않음. 기술적 비용이 적게 듬.
단점: 통합 업무에 한계가 있음. 자료 중복이 발생.
⇒ 소규모 기업이나 ERP 적용의 선행단계로서 적합함.
ERP (Enterprise Resource Planning, 전사적 자원관리, 통합 정보 시스템)
: 재무, 인사, 생산, 물류, 마케팅 등 각 부서가 따로 놀던 전산 시스템을 하나의 시스템으로 통합한 것.
상품이 입고되면 물류 프로그램과 연동하여 재고량이 집계되고, 재무관리 프로그램과 연동하여 생산 비용과 판매된 금액을 입력하면 자동 계산 되는 식. ⇒ 한 부서에서 데이터를 입력하면 전 부서에 반영되어 즉시 처리할 수 있게 됨.
장점: 생산성 및 효율성, 정보 접근성, 확장성이 향상됨. 데이터 통계가 가능해짐. e-커머스와 연계가 원활해짐.
단점: 구축에 오랜 시간이 걸림. 그러다가 기업의 장기적 전략과 맞지 않게 될 수 있음.
(참고: https://m.blog.naver.com/junbeat/70015615108)
(참고: IT 경제 상식 사전 - 양재봉, 길벗 출판사)
참고: 시스템 통합(System Integration, SI) 사업
: 서로 다른 환경에 있는 기업이나 기관에 맞는 정보시스템을 기획하고 설계하며 유지 보수 및 운영을 해주는 IT 인프라 서비스
: 회사에서 사용하는 ERP 같은 프로그램을 만드는 회사. 소프트웨어 개발 회사와 다른 점은 ‘맞춤형 소프트웨어’를 개발한다는 것. 특정 회사 혹은 특정 운영시스템에 맞게 고치거나 새롭게 만드는 일을 함.
: 회사의 경영 정보, 물류, 생산 등의 과정을 컴퓨터로 처리할 수 있도록 하는 것. 시스템 통합(SI) 또는 전산화라고 함.
예) 지하철 공사에서, 건축과 토목 외에 지하철 자동화 시스템(지하철 운행 정보 등을 이용한 안전운행 설계)을 만드는 대규모 프로젝트
예) 고객관리 프로그램 등의 소규모 프로젝트
국내 대표 SI 업체: 삼성 SDS, LG CNS, SK CNC
2. 정보공학 방법론
: 업무에서 정보의 효율적 사용을 가능하게 하는 아키텍처를 정의하기 위해 사용되는 시스템 공학 접근 방식.
정보공학 개발 방법론은 비즈니스 시스템 규모 성장과 소프트웨어 공학 발전에 따라 1980년대 중반에 등장한 방법론으로 기업의 전사적인 관점에서 출발해 데이터 중심으로 시스템을 구축하는 방법론이다.
정보공학(Information Engineering)은 기존의 구조적 방법의 원리를 모두 수용하면서 소프트웨어 개발 공정 뿐만 아니라 프로젝트 및 품질관리를 비롯한 지원 공정까지를 포함 하는 가장 안정적인 방법론으로 평가를 받고 있다. 국내에서도 공공부문의 정보화 지원사업의 권장방법론으로 활용되는 등 현재까지 가장 보편적으로 사용되고 있는 개발방법론이다.
수행 순서
- ISP(Information Strategy Planning): 단계에서는 기업의 경영전략을 뒷받침할 수 있는 정보화 전략을 수립하기 위해 현행 업무프로세스와 시스템을 분석하고 미래 아키텍처와 전략계획을 수립하게 된다.
- BAA(Business Area Analysis) 단계는 기업의 업무 현황을 분석해서 개념 수준의 데이터와 프로세스를 설계하는 업무분석 단계이다. ⇒ 업무 영역별로 분석. 요구사항 명세서가 만들어짐.
- BSD(Business System Design) 단계는 실질적으로 시스템을 설계하는 단계로 우리가 많이 사용하고 있는 논리적 ER 다이어그램으로 데이터를 설계하고 분할 다이어그램, 액션 다이어그램, 의존 다이어그램을 사용해 프로세스를 설계한다. ⇒ 분석을 기반으로 구체적으로 업무 프로세스 구조도/흐름도 다이어그램 그리기.
- SC(System Construction) 단계에서는 물리적 데이터베이스를 설계하고 BSD 단계에서 작성한 산출물을 바탕으로 프로그램을 개발하게 된다. 대부분의 프로젝트에서는 설계문서만 만들고 코드는 개발자가 직접 만드는 방식으로 개발을 진행한다. ⇒ 실제로 데이터베이스 만들고 코드 짜기.
정리 및 요약:
“정보를 이용해서 전략을 짜자 (ISP)”
거시적. 데이터를 어떻게 하면 잘 쌓을지 그리고 어떻게 데이터를 활용해 기업의 생산성을 높일지 고민.
데이터의 중요성에 대해 눈을 뜬 많은 기업들이, 3~5년에 한 번씩 ISP 프로젝트를 수행해서 정보화 전략을 수립하고 정보시스템을 구축/수정함.
가장 안정적인 방법론으로 평가를 받고 있음. 국내 공공부문의 정보화 지원사업의 권장방법론으로 활용되는 등 현재까지 가장 보편적으로 사용되고 있는 개발방법론임.
장점:
일관성 있고 통일된 정보시스템 구축 가능
시스템의 장기적인 진화, 발전 허용
단점:
잘못된 작업을 보완하기 위한 이전 단계로 이행이 어려운 경직된 구조를 가지고 있음.
정보공학의 효과를 위해 장기간 필요, 특정 사업영역으로부터 독립된 시스템 개발에는 부적합.
참고 문서:
https://bigdown.tistory.com/372
3. 객체지향 방법론
: 현실 세계의 개체(Entity)를 속성(Attribute)과 메소드(Method)가 결합된 형태의 객체(Object)로 표현하고, 현실 세계의 문제를 이 객체와 객체 사이의 상호작용으로 해석한 방법론.
추상화, 캡슐화, 정보은폐, 상속, 다형성의 특징을 가지며, 계획 > 분석 > 설계 > 구현> 테스트 단계를 거쳐 개발
분석과 설계 과정의 전 단계를 데이터 중심(Data-Oriented)으로 개발함으로써, 데이터의 동적 측면을 강화하는 특징을 가지고 있음.
반복과 점증적(Iterative and Incremental) 모델을 사용.
데이터베이스가 객체형 DB라면 별다른 변환과정 없이 데이터 객체를 그대로 저장하면 되지만, 관계형 DB를 사용한다면 객체를 관계형 테이블로 변환하는 과정이 필요하여 ORM이 사용되게 됨.
4. 컴포넌트 기반 방법론 (CBD)
: 개발된 S/W 컴포넌트를 조립, 시스템을 개발하여 객체지향의 단점인 S/W 재사용성을 극대화한 개발 방법론
5. 애자일 방법론
: 기존 방법론들이 너무 절차를 중시한 나머지 변화에 대응하기 어려웠던 점, 그리고 과도한 문서화나 형식적인 절차에 상당한 비용을 치러야 하던 단점을 개선하기 위해 나왔다.
절차보다는 사람을, 문서보다는 작동하는 소프트웨어를, 미리 철저하게 계획하기 보다는 변화에 대한 민첩한 대응을, 계약과 협상에 얽매이기 보다는 고객과의 협력을 중요하게 생각함.
(참고: http://wiki.hash.kr/index.php/소프트웨어_개발방법론#cite_note-5)
(참고: https://www.lgcns.com/blog/cns-tech/solution/16499/)
(참고: https://blog.lgcns.com/22)
소프트웨어 개발방법론 비교
| 구분 | 구조적 | 정보공학 | 객체지향 | CBD |
| 개념 | 정형화된 분석절차, 프로세스 중심 | CASE도구 등 공학적 접근, 데이터 모델 중심 | 객체지향 개념 적용, 사용자 관점 분석 설계 | 컴포넌트 개발 및 조합을 통한 재사용 중심 |
| 시기 | 1970 년대 | 1980 년대 | 1990 년대 | 2000 년대 |
| 중점 | 기능 중심 | 자료구조 중심 | 객체 중심 | 컴포넌트 중심 |
| 특징 | 분할과 정복 하향식 기능 분해 | 데이터&프로세스 균형 기업정보 시스템 중심 | 갭슐화, 추상화, 다형화 정보은닉, 상속화 분석 초점이 명확 | 반복, 점진적 높은 재사용, 생산성/품질 향상, 유지보수 최소 |
| 장점 | 프로세스 중심 방식 개발 유용 | 자료중심으로 비교적 안정적 | 자연스럽고 유연함 재사용성 향상 | 생산성, 품질, 비용위험 개선 및 SW위기 극복 |
| 단점 | 기능 불안정 정보은닉 불가 낮은 재사용, 유지보수 | 어플리케이션은 기능적 설계 수행 유지보수, 재사용 낮음 | 실질적 재사용 어려움 기본적 SW 기술 필요 | 컴포넌트 유통 환경 개선 필요 테스트 환경 부족 |
| 목표 | 비즈니스 프로세스 자동화 | 경영전략적 정보시스템 구축 | 재사용 시스템 | 컴포넌트 개발 및 활용 |
| 산업 구조 | 소품종 다량생산 | 다품종 소량생산 | 인터넷 비즈니스 | 인터넷 비즈니스 |
| 접근 방법 | 프로세스 중심 | 데이터 중심 | 객체중심 (프로세스+데이터) | 컴포넌트 중심 |
| Life Cycle | 폭포수 모델 | 폭포수 모델, 프로토타입 | 반복적 개발 | 반복적 개발 |
| 모델링 | 기능 모델링 | 데이터모델링 프로세스 모델링 | 객체 모델링 | 객체 모델링 컴포넌트 모델링 |
| 개발 방식 | Top-Down | Top-Down | Bottom-Up | Bottom-Up |
| 자동화 | 수작업 가능 | 자동화 도구 요구 | 자동화 도구 필요 | 자동화 도구 필수 |
| 지원언어 | Cobol, C, VB, Pascal | Cobol, C, VB, Pascal | C++, Java, C#, VB | 개발언어 무관 |
(참고: https://m.blog.naver.com/roser111/221681015291)
※ 위 내용은 스스로 공부하며 적어둔 노트이며 불확실한 내용이 있을 수 있습니다. 학습용으로 적합하지 않음을 유념해주세요. ※
Uploaded by N2T