정보시스템 분석 - 개발 과정, 방법론, 프로세스

정보시스템

비즈니스 업무를 처리하기 위하여 정보를 모으고 처리하고 저장하고 제공하기 위한 관련 있는 컴포넌트의 집합체

 

정보시스템 요소

• 시스템 경계
• 입·출력 
• 서브시스템 - 복잡한 내부를 잘 구성할 수 있음
• 제어 메커니즘 
• 저장 장치 
• 통신장치

 

정보시스템과 비즈니스

제품과 서비스를 제공하고 이윤을 추구하는 합리적 활동

-> 비즈니스 비용절감, 효율적인 작업 통한 경쟁력 확보위해 정보시스템 도입

-> 정보시스템이 비즈니스 목표의 구현 / 달성 기여

 

정보시스템 종류

• ERP 시스템
• 트랜잭션 처리 시스템
• 의사결정 지원 시스템

● ERP 시스템

기업 전반에 걸친 운용과 관리정보 지원

회사 여러 기능 통합하여 전사적인 프레임워크 구축

 

● 트랜잭션 처리 시스템

매일 발생하는 비즈니스 거래에 의해 생성되는 데이터 처리

대규모 데이터 처리, 미션 중심 시스템

 

● 의사결정 지원 시스템

기업의 모든 수준에서의 직무관련 정보 제공

의사결정지원 도구 제공

- 경영정보시스템(MIS), IoT, 빅데이터 ...

 

---

분석과 설계

• 시스템 분석 - "무엇을" 해야 하는지 이해하고 명세로 나타내는 작업
• 시스템 설계 - "어떻게" 구현되야 하는지 나타내는 작업
• 소프트웨어 개발 - 비즈니스 니즈에 맞도록 설계, 구축하여 사용자에게 배포 과정

 

시스템 개발 과정

• 계획
• 분석
• 설계
• 구현

 

● 계획

개발의 목표, 방향 설정 ( 왜 구축? )

일정, 비용, 조직 ..  타당성 분석, 작업 계획 수립, 팀 조직 수립, 프로젝트 관리 계획

결과물 : 프로젝트 계획서

 

● 분석

시스템에 대한 요구 찾아내고 분석하여 정리(문서화)

분석 전략 수립 - SWOT 분석

요구 수집

결과물 : 시스템 제안서

 

● 설계

시스템이 어떻게 구성되고 동작해야 하는지 자세한 명세 작성

결과물 : 시스템 설계 명세서

 

● 구현

설계에 따라 프로그래밍하고 검증

결과물 : 새 시스템, 유지보수 계획

---

방법론

정보시스템을 구현하기 위해 따라야할 절차, 가이드라인, 정형화된 접근 방법의 집합

 

> 방법론 구성 요소

• 모델 : 실세계를 특정한 관점으로 표현
• 도구 : 프로그램에 필요한 컴포넌트 생산 도움을 주는 소프트웨어
• 기술 : 작업 단계에 사용하는 기술

 

개발 방법론

• 구조적 방법론 : 프로세스
• 정보 공학 방법론 : 자료 저장 구조
• 객체지향 방법론 : 객체
• 컴포넌트 방법론 : 컴포넌트(모듈화된 자원)

● 구조적 방법론

시스템과 관련된 처리 => 프로세스 관심

시스템의 개념을 프로세스의 집합으로 나타내되 각 프로세스에 들어가는 입력과 출력 자료를 같이 표시

장점	단점
오래됨 -> 검증된 방법 프로젝트 계획, 모니터링, 요구 분석에 대한 방법 이해 쉬움	분석에서 설계 과정에 대한 전환 어려움

 

 

● 정보 공학 방법론

자료 저장 구조에 초점

데이터 모델을 시스템 컨셉트 중심에 놓고 이를 기초로 설계

장점	단점
데이터 중심으로 업무절치 및 환경변화 유연 정보 전략 계획, 업무 영역 분석 ... 기업에 맞는 접근법	효과위해 장기간 필요 독립된 시스템 개발에는 부적합

 

● 객체지향 방법론

데이터와 그 데이터에 대하여 작동하는 프로세스를 객체 안에 묶어 놓음

실세계의 비즈니스 프로세스나 오퍼레이션을 객체로 모델링

• 클래스 : 같은 객체들이 가지고 있는 공통의 자료와 오퍼레이션 정의
• 객체 : 클래스의 멤버
• 객체의 자료값 : 속성을 결정하는 고유값  <- 메소드 : 객체 속성값을 바꿈

장점	단점
실세계와 밀접한 모델링 유지보수, 코딩으로 전환 쉬움 신뢰성, 융통성, 코드 재사용 증가	광범위한 분야에 효용 증명 X 훈련된 프로그래머 부족

 

방법론 비교

	구조적 방법론	정보공학 방법론	객체지향 방법론
프로그램에 대한 관점	프로그램 = 함수 + 자료	프로그램 = 자료 + 함수	프로그램 = 클래스 + 클래스 클래스 = 자료 + 함수
설계 관심사	함수	자료	클래스
설계 핵심	모듈	엔티티	객체
중심 방법	프로그래밍 기법	기업의 전략 및 산출물 중심	설계의 표현

 

---

프로세스

생명주기 = 개발주기

개발과정을 여러 단계로 나누고 각 단계에 필요한 일과 방법을 정의

명확한 작업 단계, 손에 잡히는 결과, 작업의 검토, 다음 단계 명시

 

생명주기 모델

• 폭포수 모델
• 프로토타입 모델
• 나선형 모델
• 진화적 모델
• 애자일 모델

 

● 폭포수 모델

한 단계의 작업이 끝난 뒤 다음 단계로 넘어가는 순차적인 개발 프로세스

이전단계로 돌아갈 수 없다는 전제 하, 각 단계 확실히 매듭짓고 결과 철저히 검토 승인과정

 

→ 특징

전통적 모델, 모든 작업 문서 중심

순서적 - 각 단계 사이에 중복, 상호작용 X

각 단계 결과는 다음 단계 시작 전에 점검 ~ 시간 많이 걸림

 

→ 요건

각 단계가 끝난 후 다음 단계 수행을 위한 결과물이 명확하게 산출되야 함

 

→ 적합

크고 복잡, 오래 지속, 변화 적은 프로젝트

개발자는 경험과 지식 있고, 고객의 요구사항을 잘 알고, 그 요구사항이 크게 변하지 않을 때

현재 시스템을 개선하는데 주로 쓰임

 

장점	단점
프로세스 단순 -> 초보자 쉽게 적용 가능 중간 산출물 명확, 각 단계별로 문서화 코드 생성 전 충분한 연구, 분석 단계	중요한 요구 빠뜨리면 작업비용 큼 각 단계의 전환에 많은 노력 필요 앞단계로 되돌아가거나 큰폭 변경 어려움 분석 단계 종료 후 시스템 완성 설치까지 많은 시간 소요

 

 

+) 병렬 개발 모델

폭포수 모델의 변형

대규모 시스템을 쪼개어 병렬로 진행

시스템을 위한 종합 설계 먼저 하고, 프로젝트를 작은 규모로 쪼개어 서브 프로젝트가 각각 설계하고 구현하는 작업 병행

---

● 프로토타이핑 모델

요구사항에 대한 피드백을 받기 위해 시스템을 실험적으로 만들어 사용자에게 보여주고 평가

분석, 설계, 구현 단계 병행으로 이루어져 시스템이 완성될 때까지 반복

→ 목적

시제품을 빨리 만들어 봄

사용자의 요구를 더 정확히 추출

단순한 요구 추출 - 만들고 버림

제작 가능성 타진 - 개발 단계에서 유지보수 이루어짐

 

→ 적합

개발 착수 시점에 요구 불투명할 때

실현 가능성 타진

혁신적인 기술 사용

 

장점	단점
사용자 의견 반영 good 사용자 관심 가지고 참여, 개발자 요구 정확 도축 사용자가 체험할 수 있는 시스템 빨리 제공	오해, 기대심리 유발 관리가 어려움 (중간 산출물 정의 난해)

 

+) 쓰고 버리는 프로토타이핑 모델

프로토타이핑 모델의 변형

프로토타입을 기반으로 최종 시스템 구축 X,

단지 사용자의 피드백을 받기 위하여 프로토타입 만든 후 버리고 최종 시스템 별도 구축

분석 설계 충분 (폭포수 모델) + (프로토타이핑) 통해 주요 이슈 해결

프로토타이핑보다 기간은 더 걸리지만, 안정적이고 신뢰성 높은 시스템

 

---

 

● 진화적 모델

전체 시스템을 여러 개의 버전으로 나누고 각 버전을 순차적으로 개발

시스템 핵심 부분에 대해 기능이 명확하고 개발 효과 좋은 부분 우선적으로 개발 ~ 개선 ~ 진화

요구분석, 설계, 구현, 테스트 사이클 반복

여러번의 사이클 나누어 개발 초기 단계 모든 요구사항 파악 확정 X

 

장점	단점
유용한 시스템 빠른 기간 내에서 사용자 손에 들려줌 중요한 추가 사용자 요구를 조기에 발견 릴리스마다 다른 영역에 집중 가능	사용자가 의도적인 미완성 시스템을 가지고 작업하기 시작

 

---

● 나선형 모델

여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어 개발

폭포수 장점 + 프로토타입 장점 + 위험 분석 기능

누락, 추가된 요구사항 첨가 -> 실패의 위험 줄임

테스트 용이, 피드백, 여러번의 점증적 릴리스

→ 적합

재정적 / 기술적 위험 부담 큰 경우

요구사항 / 아키텍처 이해 여러운 경우

대규모 시스템 개발

 

장점	단점
반복적인 개발 및 테스트 -> 강인성 향상 한 사이클에 추가 못한 기능은 다음 단계에서 추가 가능	관리 복잡 초기 위험 분석을 잘못하여 지나처 버린 경우 피해 큼 성공 사례 적음

 

---

● 애자일 모델

과도한 모델링, 문서화 생략 -> 개발 작업 집중

고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정 주기를 반복하면서 개발

↔ 폭포수 모델과 대조적

 

→ 가치

프로세스, 도구 < 개인과 상호작용

문서 < 실행되는 SW

계약협상 < 고객과 협업

계획 < 변화에 반응

 

→ 대표적인 개발 모델

• XP
• 스크럼

○ 익스트림 프로그래밍(XP)

고객의 참여와 개별과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

- 릴리즈 : 몇 개의 요구사항 적용되어 부분적으로 기능이 완료된 제품 제공

- 사용자 스토리 : 고객의 요구사항을 간단한 시나리오로 표현

- 스파이크 : 별도로 만드는 간단한 프로그램

 

○ 스크럼

팀이 중심이 되어 효율성 높임 -> 소통, 짧은 주기 반복

- 제품 백로그 : 개발 제품 요구사항 우선순위 따라 나열한 목록

- 스프린트 : 반복적인 개발주기

- 스프린트 백로그 : 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

 

장점	단점
소프트웨어 빠르게 배포 가능 요구처리 시간 ↓  피드백, 변화 빠르게 대응 계층적인 관료주의, 문서화 X 아이디어 빨리 실험 테스트	문서화가 등한시 모든 사람에게 많은 에너지, 시간 요구

 

 

개발 모델 선택

---

팀 역할

● 시스템 분석가

시스템 개발에서 제기된 이슈 다룸

비즈니스 프로세스 개선

분석, 설계 작업에 대한 훈련 경험

 

→  능력

기술, 비즈니스, 분석, 의사소통, 관리, 윤리

 

● 프로젝트 관리자

팀 관리

계획 수립, 모니터링

인원, 예산, 시간 조절 및 관리

제안서 작성 및 추진

 

● 사용자 지원

헬프데스크, 고객센터 ~ 사용자 교육

 

● 품질 보증

소프트웨어 테스트

개발팀과 별도의 조직으로 구성

 

● 데이터베이스 관리자

데이터베이스 설계, 보안, 백업, 사용자 접근 제어

 

● 네트워크 관리자

사용자 접근 제어

네트워크 관리, 모니터링,  유지보수

 

 

 

 

---

참고 도서 : 최은만, UML로 배우는 시스템분석설계, 생능출판사, 2020년 3월 (제2판)