[정보처리기사 필기] 1과목 정리 - 방법론

소프트웨어 개발 방법론

소프트웨어 프로세스의 각 작업을 어떻게 수행하느냐(방법)를 정의프로세스와 혼동하는 경우도 있으나 같은 의미는 아님

• 프로세스는 일반적으로 개발할 때 해야 할 작업만을 명시, 어떤 관계에 있는지는 나타내지 않음
• SW 개발 조직이 방법론을 선택하도록 자유를 준 것
• 방법론은 프로세스의 구현이라 생각할 수 있음
• 개발에는 프로세스와 방법론이 중요함

방법론은 각 단계와 입력 자료 및 산출물, 이들의 표현 방법까지 명시

산출물의 표현 방법은 패러다임(소프트웨어를 보는 관점)에 따라 다름

SW 프로세스는 하나 이상의 방법론으로 구현될 수 있음

구조적 방법론

 

실세계의 문제를 처리(Process)라는 관점으로 모델링

DFD - 출처 : https://ko.wikipedia.org/wiki/데이터_흐름도

모델링은 자료 흐름도(Data Flow Diagram, DFD)를 사용

• 각 노드에는 외부 엔티티, 프로세스, 자료 저장소를 표현
• 이들 사이의 자료 흐름 관계를 간선으로 나타냄

구조도 예시 - 출처 : https://ko.wikipedia.org/wiki/구조도

자료 흐름도를 구조도로 변경하는 과정

• 구조도는 모듈 사이의 관계를 나타내는 그래프
• 각 노드는 모듈을 나타냄
• 간선은 상위층의 모듈이 서브 루틴을 함수로 호출하는 의미

장점

• 오래 사용되어 검증된 방법
• 프로젝트의 계획과 모니터링이 비교적 쉬움
• 요구 분석에 대한 방법이 이해하기 쉬움

단점

• 분석 설계 과정에 대한 전환이 쉽지 않음

 

정보공학 방법론

정보시스템은 기업의 비즈니스와 밀접하게 관련됨

• SW 프로젝트의 계획, 분석, 설계, 구축 등의 기술 집합이 기업의 부문과 연계 통합하는 방법이 필요

1990년대 초 James Martin은 구조적 방법의 문제점인 기업 전체의 조망과 데이터 통합의 어려움을 극복하기 위해 정보공학 방법론 고안

특징

• 기업 중심
  • 적용 대상이 기업의 비즈니스 중심으로 단순한 SW 개발이 아님
  • 기업의 전략경영을 지원하기 위해 전략 정보 시스템에 초점을 맞춤
• 전략적 시스템 계획 중심
  • 시스템 개발에 경영층의 요구와 견해를 반영하기 위하여 전략적인 계획으로 시작
• 데이터 중심
  • 기업의 비즈니스 프로세스는 수시로 변함
  • 데이터는 대부분 변하지 않기 때문에 유지보수를 줄이고 잦은 변화에 적극 대응하고자 데이터 중심 설계 진행
  • 프로세스와 데이터를 분리하여 분석하고 설계하되 상관 분석을 통해 검증하는 방식
• 분할과 정복
  • 비즈니스 문제 영역을 세분화 즉 분할과 정복 원리를 적용, 이해하고 구현
  • 톱다운 방식으로 문제 영역으로 부터 비즈니스 영역으로 다음은 비즈니스 시스템으로 발전시키고 최종 구현 시스템으로 완성
• 공학적 접근
  • 분석, 설계 등 초기 단계에 철저하게 작업
  • 후속 단계에서는 CASE 도구를 이용하여 소스 코드를 자동으로 생성하는 접근 방법
• 사용자의 적극적 참여
  • 작업 초기 단계부터 사용자를 참여시키고 프로토타이핑을 도입하여 불명확한 요구 사항을 없앰
  • 개발 완료 후 사용자 불만을 최소화하기 위함

산출물

• 설계
  • 스토리보드
  • 데이터 설계서
  • UI 설계서
• 개발 과정
  • 물리적 테이블
  • 프로그램 코드
• 요구 분석 단계(BAA 비즈니스 영역 분석)
  • 요구 사항 명세서
• 시스템 설계 단계(BSD 비즈니스 시스템 설계)
  • 논리 ERD
  • 비즈니스 프로세스를 설명하는 프로세스 구조도와 흐름도
• 개발 단계(SC 시스템 구축)
  • 물리 ERD
  • UI
  • 프로그램 코드

장점

• 데이터 중심으로 업무절차 및 환경변화에 유연함
• 정보 전략 계획, 업무 영역 분석 등 기업에 맞는 접근법

단점

• 효과를 위해 장기간 필요
• 소규모 자동화 사업영역에는 시간이 오래 걸림
• 특정 사업영역으로부터 독립된 시스템 개발에는 부적합

 

객체지향 방법론

실세계를 객체라는 눈으로 보고 객체 사이의 인터랙션을 모델링하는 방법론

• 자료와 함수를 가까운 곳에 정의하여 객체로 묶고 객체 사이에 메시지를 호출하여 원하는 기능을 담당하게 하는 것

복잡한 대규모 시스템을 클래스로 모듈화하고 캡슐화할 수 있는 방법

객체지향 패러다임

객체지향 패러다임(소프트웨어를 보는 관점)

• 주어진 작업을 수행하기 위하여 협력하는 객체들의 모임 == 시스템

대표적인 객체지향 방법론

• OMT(Object Modeling Technique)
• Booch 방법론
• 유즈케이스 접근법

UML(Unified Modeling Language)와 UP(Unified Process)의 탄생 동기

• 서로 다른 방법론 사용 시 시스템 통합, 유지보수가 불편하고 비효율적임
• 서로 다른 방법론을 지원하는 도구들을 사용하는 것도 비용이 많이 듦.

장점

• 실세계와 밀접한 모델링
• 유지보수 쉬움
• 코딩으로의 전환이 쉬움
• 신뢰성과 융통성, 코드 재사용성 증가

단점

• 광범위한 응용 분야에 효용이 증명되지 못함
• 충분히 훈련된 프로그래머 부족

 

세 가지 방법론 비교