幻想之客 3rd - Bladed Soul

WARNING!! 어디까지나 제가 소화한 내용을 다시 풀어내는 것이기 때문에, 오류가 있을 수 있습니다. 이 점을 유의하시고 읽어주시길 바라며, 만약 문제점을 발견하시거나 수정사항을 지적하고 싶으시다면 언제나 태클을 환영합니다. 단, 무의미한 인신공격 및 악플은 경고 없이 삭제 됩니다.

소분설에 배운 내용을 간략히 정리해 보는 첫 번째 시간이 되겠습니다-_-)/

이 수업은 큰 맥락에서 보면 소프트웨어 공학의 범주 내에 들어가는 수업입니다.
따라서 기본적으로 소공에 대한 지식이 많이 필요합니다. 관심이 없는 분은 읽지 않으시는 게 현명한 판단이라고 생각됩니다.(...)
이 수업은 Unified Process(이하 UP)를 이용한 실제 프로젝트에서의 요구사항 분석 및 설계, 구현까지의 단계를 중점적으로 다룹니다. 그렇다면 UP는 무엇인가?가 오늘의 포스팅의 주제가 되겠습니다.

UP를 해석하자면 '통합된 프로세스'입니다. 그렇다면 과연 어떠한 것들이 통합된 걸까요?
  아마 소프트웨어 개발 프로세스에 대한 지식이 조금이라도 있는 사람이라면 Waterfall Model(폭포수 모델이라고들 하죠)에 대해서 들어보셨을 겁니다. 크게 SW 개발 프로세스를 나누자면 방금 말한 폭포수 모델과 Iteratation Model(반복 모델이라고 합시다)의 두가지로 나눌 수 있는데, 또 반복 모델은 Prototyping 방법과 Incremental한 방법, 두 가지로 나뉘어 집니다.
  각각의 모델에는 장, 단점이 있는데, 먼저 폭포수 모델은 프로세스를 이루는 Activity(이후 활동이라고 칭하겠습니다)를 행함에 있어서 한 단계를 완벽히 행하고 나서 다음 단계로 진행하는 방법입니다. 이 방법은 프로세스의 진행상황을 명확하게 알기 쉽다는 장점이 있는 대신, 전 단계에서 수행해야 하는 어떠한 오류사항이 차후에 발견되더라도 전 단계로 돌아가서 수정을 할 수 없다는 단점을 지니고 있습니다. 즉, 디자인 단계에서 열심히 디자인을 하다가 빠진요구사항이 있다는 것을 알아챘더라도 이미 디자인 단계에 들어와버렸다면 그걸 수정할 수 없습니다. 어떻게든 디자인 단계에서 그걸 메꿔보려 노력은 하겠지만 말이죠.
  반복 모델은 모든 활동들을 쭉 실행하고 나서 다시 처음부터 반복적으로 행하는 모델로, 반복을 통해서 식별된 문제점들을 다시 수정이 가능하다는 장점이 있습니다. 하지만 지금 개발이 어느 단계에 와 있는지, 또 무엇을 개발하고 있는지를 알아보기가 힘들다는 단점이 있습니다. 이는 위에서 말한 두 가지 방법 중에서 어느 것을 사용하더라도 동일하게 적용됩니다.

  이러한 두 가지 프로세스들의 단점 때문에 나타난 것이 UP입니다. UP는 위의 두 프로세스를 통합한 형태를 지니고 있습니다. 즉, 전체적으로는 폭포수 모델처럼 하나의 단계가 진행되면 그 전 단계로 절대로 돌아가지 않는 형태를 취하고 있지만, 그 각각의 단계(UP에서는 Phase라고 칭합니다)내부에는 계속적인 반복이 이루어지는 형태입니다. 간단히 표로 나타내 보면

이러한 형태가 됩니다. 각각의 단계(Phase)는 각각 Inception(도입), Elaboration(전개), Construction(구축), Transition(이행)이라고 이름 붙여져 있으며 각각의 Phase마다 중요한 목표는 각기 다르게 지정되어 있습니다. 하나의 단계마다 정해져 있는 반복의 횟수는 없으며, 그 때 그 때 상황에 따라서 분석, 설계, 구현, 테스트가 선형적으로 반복됩니다. 이러한 형태로 이루어져 있기 때문에 UP는 위의 두가지 프로세스의 장점을 모두 다 지니게 됩니다. 가장 유명한 UP는 미국의 Rational사가 만든(지금은 IBM에 흡수된 것 같습니다) Rational Unified Process(RUP)죠. 좀 가격이 쎈(...)

  여기까지 간략하게 UP에 대해서 알아보았습니다. 여담이지만 이러한 형태를 떠나서, 분석 및 설계에 들어가는 오버헤드를 줄여보고자 하는 생각에 출발한 프로세스도 있습니다. 그러한 형태를 에자일(Agile)기법이라고 하며, 가장 널리 알려진 에자일 기법 중 하나는 익스트림 프로그래밍(Extreme Programming)입니다. 이는 개발을 할 때 최대한 유저의 참여도를 이끌어 내는 방법으로, 소프트웨어를 매우 조그마한 조각으로 나눈 후 그것을 개발해서 유저에게 전달, 유저의 의견을 피드백을 받아서 수정 및 보안을 해나가는 방법입니다. 아마 유저가 꽤나 귀찮으리라고 생각합니다. 쥐똥만큼 개발하고 나서 괜찮냐고 맨날 물어보니까요-_-);;;

  후, 생각보다 시간이 걸리는군요. 다음 포스팅을 언제 할지 기약은 없지만, 아마 과제가 없으면 내일쯤 올라올 듯 하네요. 그리고 위에 적어놓은대로 태클을 환영합니다. 저도 배우는 입장이기 때문에 아마 여기저기 구멍이 있을 듯 합니다.^^; 그리고 이 일천한 글을 혹여라도 퍼가실 분은 어디에 쓰실 건지 명확하게 저에게 이야기 하신 후 허락을 받고 퍼가십시오. 무단 도용은 용납하지 않습니다.