검색결과 리스트
글
방법론(methodology)
방법론로그/OOAD
2011. 4. 12. 15:17
소프트웨어 방법론의 개발 프로세스이자 일반적인 문제 해결 과정을 알아보자.
아래 내용은 박병준 선생님의 가르침을 바탕으로 정리한 내용들이다!! 감솨합니다 샘!!
이것을 이해하고 자기의 것으로 어떻게 만드느냐는 개인의 몫!
아래 그림은 일반적인 개발 프로세스들과 그 프로세스를 지원하기 위해 작성하는 문서들이다.
물론 이런 문서들이 항상 고정되어 있는 것은 아니다. 개발하고자는 업무영역에 따라 도움이 된다면 더 많은 문서들을
작성할 수도 있고, 간소화 할수도 있다. 중요한 것은 대상을 얼마나 "다각도에서 이해하는냐" 이지 "무엇을 작성하느냐" 가
아니다.
프로그램이란 해야할 일을 다른 사람에게 대신하게 하는 것이라는 느낌으로 , 단계별로 "주인과 종"을 예로 들어 설명했다.
물론 이런 문서들이 항상 고정되어 있는 것은 아니다. 개발하고자는 업무영역에 따라 도움이 된다면 더 많은 문서들을
작성할 수도 있고, 간소화 할수도 있다. 중요한 것은 대상을 얼마나 "다각도에서 이해하는냐" 이지 "무엇을 작성하느냐" 가
아니다.
프로그램이란 해야할 일을 다른 사람에게 대신하게 하는 것이라는 느낌으로 , 단계별로 "주인과 종"을 예로 들어 설명했다.
1. 문제인식(Problem Recognition)
개발 프로세스의 가장 첫번째 과정이다. "누가, 무엇을 원하는가" 를 정의하는 단계이다.
"누구" 는 반드시 한 사람이라고 할 수 없다. 문제에 연관되어 있는 다양한 사람들을 도출하는 하는 것이 첫번째 단계이고,
이들이 각각 무엇을 원하는지 도출하는 것이 두 번째 단계이다.
"누구" 는 반드시 한 사람이라고 할 수 없다. 문제에 연관되어 있는 다양한 사람들을 도출하는 하는 것이 첫번째 단계이고,
이들이 각각 무엇을 원하는지 도출하는 것이 두 번째 단계이다.
누구를 만족시킬 것인가? 그 누구가들이 바라는 것들은 무엇인가? 를 도출하는 과정
그렇다면 문제는 어떻게 인식하는가? 앞서 문제는 왜 생기는가? 그것은 사람이기 때문이다.
사람이기 때문에 필연적으로 문제는 생기기 마련이다. 즉 사람이 모든 문제의 시작점이 되야 한다.
하지만 누군가는 모든 사람들을 의미하는 것은 아니다. 수많은 사람들의 범주 가운데서, 좁혀지고 좁혀져
특정 집합에 속하는 사람들만이 우리가 만족시켜야 하는 사람군에 속한다. 이 집한군은 여러 군이 존재할 수 있으며
이렇게 이익과 해를 보는 사람들을 Stakeholder (이해당사자)라고 한다.
ex) twitter를 예로 들어보자.
사람들은 커뮤니케이션을 할 수 있는 수단을 필요로 했다. 가장먼저 대화를 하기 시작했으며, 공간의 제약을 극복하기위해
편지라는 것이 등장했다. 하지만 더빠른 전달을 위해 전보가 등장했다. 송수신을 더 잘하기 위해 전화가 등장했다. 나아가
언제 어디서든 가능하게 하기 위해 핸드폰 또는 SMS가 등장하고 결국 twitter 에 이르게 된것이다.
요약하면 Stakeholder를 도출하고, 그들이 원하는 기능을 도출하는 과정이 문제인식이라 정의할 수 있다.
2. 정보수집(Requirement Gathering)
기존에 (오프라인에서) 업무가 어떤 절차에 의해 진행되어 왔는지를 파악하는 단계이다. 문제인식에서 도출한 기능별로
실제업무가 어떤 절차로 진행되는지를 시나리오 방식으로 기술하되 잠재적으로 데이터가 될수 있는 항목들을 명시한다.
절차와 데이터를 함께 고려하면 혼선을 가져올 수 있기 때문에, 절차를 기준으로 먼저 기술하고 난후 데이터를 도출하는 것이
도움이 된다.
실제업무가 어떤 절차로 진행되는지를 시나리오 방식으로 기술하되 잠재적으로 데이터가 될수 있는 항목들을 명시한다.
절차와 데이터를 함께 고려하면 혼선을 가져올 수 있기 때문에, 절차를 기준으로 먼저 기술하고 난후 데이터를 도출하는 것이
도움이 된다.
기존에 행해져 왔던 일의 전체과정을 보는 단계이다.
즉 절차에 집중하는 단계이며, 데이터 또한 그 절차안에서만 의미를 갖는다.
(Stakeholder 가 기존에 해당 목적을 달성해왔던 과정을 훑어 보는 과정)
ex) 인사관리시스템을 만들기 위해서는 인사관리 업무가 무엇인자 알아야 하지 않겠는가?
3. 분석(Analysis)
오프라인 업무에 시스템이 적용되기 위한 접합점이다. 정보수집 단계에서 작성한 시나리오를 바탕으로 사용자가
수행할 업무와 시스템이 수행할 업무를 분리하여 기술한다. 사용자의 절차, 시스템의 절차가 분리되어 기술하는 것이
좋으며 그 절차와 더불어 데이터 항목들을 도출해야 한다. 정보수집 단계에서는 없었던 데이터들이 시스템이 적용되면서
추가되거나, 데이터들에 대한 조건(유효성 검사)들이 추가된다.
수행할 업무와 시스템이 수행할 업무를 분리하여 기술한다. 사용자의 절차, 시스템의 절차가 분리되어 기술하는 것이
좋으며 그 절차와 더불어 데이터 항목들을 도출해야 한다. 정보수집 단계에서는 없었던 데이터들이 시스템이 적용되면서
추가되거나, 데이터들에 대한 조건(유효성 검사)들이 추가된다.
절차에서 어떤부분을 대신 시스템화 할 수 있는지 고민하는 과정이다.
어디서부터 어디까지 대신 시킬 것인지에 따라 결과가 달라진다.
종과의 약속 => 인터페이스
종에게 물어본후 답에 따라 그 일을 다르게 행하게 할 수 있다. => 입력
(Stackholder 에 따라 물어보는 부분이 달라 질 수 있다. )
종에게 대신 시킬 과정을 찾는 단계이며, 전체 절차는 변하지 않는다것에 주의한다.
4. 아키텍처(Architecture)
인프라가 있더라도 이를 사용할 수 있는 기술이 있어야 한다.
ex) 대리 운전기사가 차를 운적할 수 있어야 함
종에게 대신 시키기 위해서 주인이 준비물을 지정하는 단계이다. 준비물에 무엇이냐에 따라서 종이 받아들이는 것과
대신 수행한 일의 결과가 달라질 것이다.
아키텍처는 Infra 와 Technology로 구성된다. 인프라는 하드웨어적인 준비물을 의미한다.
ex) 대리운전을 호출했다면, 차와 키, 톨비가 인프라아키텍처는 Infra 와 Technology로 구성된다. 인프라는 하드웨어적인 준비물을 의미한다.
인프라가 있더라도 이를 사용할 수 있는 기술이 있어야 한다.
ex) 대리 운전기사가 차를 운적할 수 있어야 함
5. 설계(Design)
종에게 준비물을 사용하게 했을 때의 절차이다.
전체 절차는 동일하지만, 준비물이 바뀜에 따라 절차가 조금씩 바뀌게 된다.
=> 모든 생각이 끝나야 하는 단계. 생각을 안해도 되게끔 설계 단계까지 모든 것이 이루어져야 한다.
6. 구현(Implementation)
7. 테스트(Test)
미리 예측한 결과를 확인하는 단계이다. 그렇다면 어느단계에서 예측하는가? => 바로 분석단계!
작은 단위로 하나하나 테스트 하는 것을 단위 테스트(Unit test) 라고 한다.
전체시스템을 놓고 테스트 하는 것을 통합 (Integretaion test) 라고 한다.
Close test는 개발사 자체조직 내에서의 테스트
Open test는 서비스 이전에 일정한 사용자에 의한 테스트
8. 배포(Deployment)
유기적인 장소에 하드웨어/소프트웨어들을 설치하는 단계
9. 서비스(Service)
10. 유지보수(Maintenance)
'방법론로그 > OOAD' 카테고리의 다른 글
| 방법론(methodology) (0) | 2011.04.12 |
|---|---|
| 2011.03.08.Tues 아키텍처 발전역사 (0) | 2011.03.08 |
| [OOAD] 요구사항 수집부터 분석까지 (0) | 2010.12.13 |
| [OOAD] 아키텍처, IA , 화면기준안, 스토리보드 (1) | 2010.12.13 |
